Re: Problems with signal delivery
At Thu, 2 Sep 2010 19:52:42 -0700 (PDT), Roland McGrath wrote: > > > Do you mean that there is some code relying on these Hurd semantics, and > > that therefore we should not try to change them to match POSIX, except > > maybe when the pthread functions are used? > > I mean the semantics are the semantics and have been for 15+ years, and we > can't assume it's OK to just go changing them and call it a "fix". POSIX > only specifies anything about any kind of multithreadedness when pthread > functions are used. What's going to break? I suspect that the software that relies on the Hurd's signal semantics (if any) is software that is directly related to the Hurd and developed by Hurd people. As such, it should be relatively easy to fix and to have those fixes integrated; I see no convincing reason to not adopt POSIX/Linux signal semantics and abandon Hurd signal semantics. Thanks, Neal
Re: GNU Mach: disabling all network device drivers
Hello, It's strange. I thought the problem doesn't exist any more after I made some changes in the kernel. Are you using the latest gnumach in the master-user_level_drivers branch? Best, Zheng Da On 8/30/10 12:15 AM, Diego Nieto Cid wrote: > Hello, > > Short story: something is clearing kernel_page_dir. > > Long story follows. :) > > On Wed, Jun 09, 2010 at 08:24:55AM +0200, Samuel Thibault wrote: >> >> These are correct. So that must the the pagetable that is incorrect. >> Check out cr3 and such. >> > > While trying DDE I came across this problem too. I run a few tests and > your guess is apparently correct: > > +---+++-+--+-+-+ > | Test# | eip | *esp | kpd | kpd' | CR3 | CR3' | > + --+++-+--+-+-+ > | 1 | 107e92 | 1436c7 | --- | --- | --- | --- | > +---+++-+--+-+-+ > | 2 | 1051f9 | --- | 1371000 | --- | kpd | 2e8f000 | > +---+++-+--+-+-+ > | 3 | 107e92 | 1436c7 | 1371000 | 0 | kpd | 219a000 | > +---+++-+--+-+-+ > | 4 | 107e92 | 1436c7 | 1371000 | 0 | kpd | 2d18000 | > +---+++-+--+-+-+ > > Where kpd is the contraction of kernel_page_dir, ' means after the > trap and --- that there is no available information. > > Meaning of some addresses: > > # addr2line -e /boot/gnumach 0x107392 0x1436c7 0x1051f9 > ...gnumach/i386/i386/spl.S:217 > ...gnumach/i386/i386at/interrupt.S:40 > ...gnumach/i386/i386at/kdasm.S:113 > > CR3 value was taken from qemu's monitor console: > > (qemu) info registers > > And this is where kpd was read from: > > # nm /boot/gnumach | grep kernel_page_dir > 001aa2b0 B kernel_page_dir > > All the test were done by running the following commands: > > # settrans -acfgp /servers/drivers/eth0 /hurd/dde/dde_ne2k_pci > ... > # settrans -acfgp /dev/eth0 /hurd/dde/devnode eth0 \ > > -M /servers/drivers/eth0 > ... > # settrans -acfgp /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 \ > > -a 10.0.2.16 -g 10.0.2.2 -m 255.255.255.0 > ... > # wget www.google.com > --2010-08-30 02:18:19-- http://www.google.com/ > Resolving www.google.com... > During the first test I collected the values of the registers. > They are similar to what Zheng Da showed before. > - > Kernel General protection trap, eip 0x107e92 > kernel: General protection (13), code=25a > Stopped at 0x107e92: ret > db> trace > 0x107e92(646565,656b6f70,6761705f,66007365,5f656572) > > no memory is assigned to address 6c610077 > db> show registers > cs0x8 > ds 0x10 > es 0x10 > fs 0x10 > gs 0x10 > ss 0x10 > eax 0x5 > ecx 0x1c > edx 0x5 > ebx 0x44520 > esp 0x1a9f20 > ebp 0x12dbd1c > esi 0x44560 > edi 0x3c > eip 0x107e92 > efl 0x297 > db> examine 0x1a9f20 >1436c7 > db> > - > > The second test went really wrong for some reason and I couldn't get > all the information. > --- > Kernel General protection trap, eip 0x1051f9rotection trap, eip 0x107e92 > kernel: General protection (13), code=202 > Stopped at 0x1051f9: repe movsw (%esi),%es:(%edi) > db> trace > Bad character ']' > ? > db> show registers > Bad character ']' > ? > db> > - >
Re: [PATCH] libthreads: mutex_lock holder debugging
Hello, Sergio Lopez, le Fri 14 May 2010 12:35:41 +0200, a écrit : > The original WAIT_DEBUG code in libthreads records the > thread which is holding the lock, but this is not really usefull in > Hurd's translators, since that thread is probably waiting for another > message just as everyone else, thus hiding the path that forgot to > unlock the mutex. > > This patch changes mutex_lock/mutex_unlock macros to hold a pointer to > the name of the function that holds the mutex. As the old behavior may still be useful, I have preferred to rewrite this to let the programmer decide one way or the other. Samuel
Re: New procfs implementation
Samuel Thibault, le Thu 02 Sep 2010 01:00:14 +0200, a écrit :
> Jeremie Koenig, le Wed 01 Sep 2010 13:04:33 +0200, a écrit :
> > On Wed, Sep 01, 2010 at 01:06:32AM +0200, Samuel Thibault wrote:
> > > > { "anonymous-owner", 'a', "USER", 0,
> > > > "Make USER the owner of files related to processes without one.
> > > > "
> > > > "Be aware that USER will be granted access to the environment
> > > > and "
> > > > "other sensitive information about the processes in question. "
> > > > "(default: use uid 0)" },
> > >
> > > Which use do you envision?
> >
> > You may want to add an entry to /etc/passwd (say, "noone"), used only to
> > distinguish the anonymous processes from those owned by root, though as
> > the comment suggests you would have to be careful not to use it for
> > anything else.
>
> Ah, so it's really not like "nobody", that's for tasks whose owner is
> yet unknown, but potentially root-owned or such, or something like this?
>
> I don't know exactly the rules, but I feel like (uid_t) -1 might be
> exactly what we need here.
I don't find anything giving me assurance of this, so I guess making it
an option that defaults to 0 should be fine for now. You should however
probably rephrase: rather than "anonymous-owner", which could be
understood as "anybody can read it, that's fine", it should probably be
called for instance "unknown-user", as it belongs to somebody, we just
don't know whom.
Samuel
Re: Packaging Hurd translators for Debian (was: Source repositories, unionmount code)
Hello, Thomas Schwinge, le Sun 08 Nov 2009 10:36:16 +0100, a écrit : > On Sat, Oct 24, 2009 at 07:56:30AM +0200, olafbuddenha...@gmx.net wrote: > > On Mon, Sep 28, 2009 at 10:16:15AM +0200, Thomas Schwinge wrote: > > > On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafbuddenha...@gmx.net > > > wrote: > > > > On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote: > > > > > I'm rather inclined to consider that shipping unionfs and nsmux > > > > > with LiveCDs and QEMU images is not an imperative to encourage > > > > > their testing. Potential users could just as well download the > > > > > code or clone the repositories locally. > > > > > > > > How about instead actively looking for someone to do this small Debian > packaging work? Perhaps we could even ask on some Debian beginners' > mailing list if there is a (yet unknown) person who wants to do it for > us, sponsored by Michael, Guillem, Samuel, etc.? It'd be a _lot_ easier to do if hurdextras was maintained in a git repository, as it permits to update extremely easily. Could we perhaps still move the source to some other savannah repository? Samuel
Re: Problems with signal delivery
Roland McGrath, le Thu 02 Sep 2010 19:52:42 -0700, a écrit : > > Do you mean that there is some code relying on these Hurd semantics, and > > that therefore we should not try to change them to match POSIX, except > > maybe when the pthread functions are used? > > I mean the semantics are the semantics and have been for 15+ years, and we > can't assume it's OK to just go changing them and call it a "fix". POSIX > only specifies anything about any kind of multithreadedness when pthread > functions are used. Right, I believe it should be feasible to keep the signal sematic of libthreads and give the posix semantic to libpthread. Samuel
Re: GNU Mach: disabling all network device drivers
Hello, 2010/9/3 Da Zheng : > > It's strange. I thought the problem doesn't exist any more after I made some > changes in the kernel. > It is, indeed. It did work once. But since I lost the binaries, I couldn't properly build it again. Theese are the last lines of code I can reach while stepping in gdb: dde_ne2k_pci/lib8390.c: __ei_start_xmit 408 /* Turn 8390 interrupts back on. */ 409 ei_local->irqlock = 0; 410 ei_outb_p(ENISR_ALL, e8390_base + EN0_IMR); I couldn't go further as I don't understand how ei_outb_p works, yet. Is this somehow related to the changes you made? > > Are you using the latest gnumach in the > master-user_level_drivers branch? > Yes. Actually I tried a few alternatives: 1. master-user_level_drivers 2. master-user_level_drivers merged with current master 3. master-user_level_drivers + 10_cdromlock.patch + 13_ide_dma.patch + 24_pci_irq_fix.patch + 40_iopl_mmap.patch Unfortunately, I didn't take note of what I was doing. I have the vague idea that when it worked 2. helped somehow. 3. is how the current Arch's package is built. I should probably rebuild everything while carefully taking notes. -- diego
Re: New procfs implementation
Hi, sorry I did not answer that one earlier. On Fri, Sep 03, 2010 at 09:16:50PM +0200, Samuel Thibault wrote: (...) > > Ah, so it's really not like "nobody", that's for tasks whose owner is > > yet unknown, but potentially root-owned or such, or something like this? These tasks (for instance the login shells) don't have any uid associated to them, and no owner either. So it's kindof like running as "nobody", as far as these processes are concerned. However, the uid we publish for the procfs files determines who can read the "environ" and "stat" files (though the latter is made world-readable in compat mode), and we don't want to allow "nobody" to do that. > > I don't know exactly the rules, but I feel like (uid_t) -1 might be > > exactly what we need here. (uid_t) -1 is what the proc server reports for tasks without an owner, but it's not really legitimate for filesystem use (unlike the Hurd processes, inodes have exactly one uid associated to them.) > (...) > You should however probably rephrase: rather than "anonymous-owner", > which could be understood as "anybody can read it, that's fine", it > should probably be called for instance "unknown-user", as it belongs > to somebody, we just don't know whom. How about "--default-owner" or "--default-uid" ? -- Jeremie Koenig http://jk.fr.eu.org
Re: Problems with signal delivery
On Fri, Sep 03, 2010 at 09:04:08PM +0200, Samuel Thibault wrote: > Right, I believe it should be feasible to keep the signal sematic of > libthreads and give the posix semantic to libpthread. Yes, we should make libc manage a set of "process signal receiving" threads, which would include the initial one and those created through pthread_create(). They would also need to have a common set of signal handlers. I'll try to come up with a patch this week-end. -- Jeremie Koenig http://jk.fr.eu.org
