Re: SMP, barriers, etc.

2009-12-27 Thread Samuel Thibault
Da Zheng, le Mon 28 Dec 2009 10:31:26 +0800, a écrit : > On 09-12-27 下午6:38, Samuel Thibault wrote: > > Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : > >> Is the process above correct? > > > > I have never actually programmed the architectures where things work > > like this (powerpc & su

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Samuel Thibault
Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit : > OK, I think I have a vague picture of what is going on: > ports_interrupt_self_on_port_death > ports_interrupt_self_on_notification > ports_interrupt_rpc_on_notification, > which requests notification (to the same port as > auth_se

Re: SMP, barriers, etc.

2009-12-27 Thread Da Zheng
On 09-12-27 下午6:38, Samuel Thibault wrote: > Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : >> Is the process above correct? > > I have never actually programmed the architectures where things work > like this (powerpc & such), but that's what I have understood from the > code and explanat

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Samuel Thibault
Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit : > If the notification request is canceled before auth_user_authenticate > returns there should be no problem. I tried a crude error_t err2 = mach_port_request_notification(mach_task_self(), rendezvous, MACH_NOTIFY_DEAD_N

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Samuel Thibault
Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit : > If the notification request is canceled before auth_user_authenticate > returns there should be no problem. Ok, I see. Samuel

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Samuel Thibault
Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit : > AFAICT, after auth_server_authenticate_reply returns _hurdsig_abort_rpcs > can not hijack it, so your solution should work. I've checked more in the kernel internals, maybe there is a race window, even if very unlikely. ext2fs is

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Carl Fredrik Hammar
On Sun, Dec 27, 2009 at 08:56:21PM +0100, Carl Fredrik Hammar wrote: > On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote: > > I've checked again the result > > > > Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit : > > > > There is this issue as well, which I have fixe

Re: SMP, barriers, etc.

2009-12-27 Thread Samuel Thibault
Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : > Is the process above correct? I have never actually programmed the architectures where things work like this (powerpc & such), but that's what I have understood from the code and explanations here and there, yes. It's a sort of transactiona

Re: Reauthentication implementation flaw due to EINTR

2009-12-27 Thread Carl Fredrik Hammar
On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote: > I've checked again the result > > Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit : > > > There is this issue as well, which I have fixed already in commit > > > 041baa80 (and indeed seen cases where it helped), but

Re: SMP, barriers, etc.

2009-12-27 Thread Da Zheng
Hi, Samuel Thibault wrote: >> After I read this introduction, I checked some atomic operations >> implementation such as atomic_add_return in Linux for Aphla processors. >> Before and after these operations change the variable, they put memory >> barriers. So it's something like this: >> smp_mb