Date: Tue, 30 Sep 2008 01:33:12 +0400 From: Chagin Dmitry <dchagin@freebsd.org> To: Roman Divacky <rdivacky@freebsd.org> Cc: freebsd-emulation@freebsd.org Subject: Re: firefox & flash9 patches Message-ID: <20080929213312.GA71793@dchagin.dialup.corbina.ru> In-Reply-To: <20080929211303.GB7605@freebsd.org> References: <20080929200237.GA68300@dchagin.dialup.corbina.ru> <20080929211303.GB7605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 29, 2008 at 11:13:03PM +0200, Roman Divacky wrote:
> On Tue, Sep 30, 2008 at 12:02:37AM +0400, Chagin Dmitry wrote:
> >
> > Hi,
> >
> > please, test following patches (just -current).
> > with them firefox && flash9 forks for me,
> > I tested only on ia32@amd64 with 2.6.16 enabled,
> > firefox 2.0.0.16 and flash9 plugin.
> >
> > If all is good, I will ask des@ and kib@ to review&commit them. thnx!
> >
> > diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
> > index 585c853..073bedb 100644
> > --- a/src/sys/compat/linux/linux_misc.c
> > +++ b/src/sys/compat/linux/linux_misc.c
> > @@ -1831,9 +1831,9 @@ linux_sched_getaffinity(struct thread *td,
> > cga.level = CPU_LEVEL_WHICH;
> > cga.which = CPU_WHICH_PID;
> > cga.id = args->pid;
> > - cga.cpusetsize = sizeof(cpumask_t);
> > + cga.cpusetsize = sizeof(cpuset_t);
>
> this makes sense... in linux this is called "cpumask_t" but it is
> in fact our cpuset_t so I belive this change is correct
>
> > cga.mask = (cpuset_t *) args->user_mask_ptr;
> > -
> > +
> > if ((error = cpuset_getaffinity(td, &cga)) == 0)
> > td->td_retval[0] = sizeof(cpumask_t);
> >
> >
> >
> > diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
> > index 646d6b2..bbb0556 100644
> > --- a/src/sys/compat/linprocfs/linprocfs.c
> > +++ b/src/sys/compat/linprocfs/linprocfs.c
> > @@ -873,14 +873,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
> > static int
> > linprocfs_doprocmaps(PFS_FILL_ARGS)
> > {
> > - char mebuffer[512];
> > vm_map_t map = &p->p_vmspace->vm_map;
> > vm_map_entry_t entry, tmp_entry;
> > vm_object_t obj, tobj, lobj;
> > vm_offset_t saved_end;
> > vm_ooffset_t off = 0;
> > char *name = "", *freename = NULL;
> > - size_t len;
> > ino_t ino;
> > unsigned int last_timestamp;
> > int ref_count, shadow_count, flags;
> > @@ -898,13 +896,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> > if (uio->uio_rw != UIO_READ)
> > return (EOPNOTSUPP);
> >
> > - if (uio->uio_offset != 0)
> > - return (0);
> > -
> > error = 0;
> > vm_map_lock_read(map);
> > - for (entry = map->header.next;
> > - ((uio->uio_resid > 0) && (entry != &map->header));
> > + for (entry = map->header.next; entry != &map->header;
> > entry = entry->next) {
> > name = "";
> > freename = NULL;
> > @@ -953,7 +947,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> > * format:
> > * start, end, access, offset, major, minor, inode, name.
> > */
> > - snprintf(mebuffer, sizeof mebuffer,
> > + error = sbuf_printf(sb,
> > "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
> > (u_long)entry->start, (u_long)entry->end,
> > (entry->protection & VM_PROT_READ)?"r":"-",
> > @@ -969,18 +963,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> > );
> > if (freename)
> > free(freename, M_TEMP);
> > - len = strlen(mebuffer);
> > - if (len > uio->uio_resid)
> > - len = uio->uio_resid; /*
> > - * XXX We should probably return
> > - * EFBIG here, as in procfs.
> > - */
> > last_timestamp = map->timestamp;
> > vm_map_unlock_read(map);
> > - error = uiomove(mebuffer, len, uio);
> > + if (error == -1)
> > + return (0);
> > vm_map_lock_read(map);
> > - if (error)
> > - break;
> > if (last_timestamp + 1 != map->timestamp) {
> > /*
> > * Look again for the entry because the map was
>
> I dont understand this change.... you just changed it from stack-based
> to using sbufs? can you explain how/why this fixes the problem?
>
pthread_getattr_np() uses /proc/<pid>/maps for some strange
thread stack size? calculation. it reads maps chunk by chunk, but current
version linprocfs_doprocmaps() disallow this:
> > - if (uio->uio_offset != 0)
> > - return (0);
also, please, see kern/101453 for explanation :)
thnx!
--
Have fun!
chd
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080929213312.GA71793>