Re: CVS commit: src/sys/compat/sa

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Bill Stouder-Studenmund wrote:
> On Mon, Oct 27, 2008 at 11:25:37AM -0700, Bill Stouder-Studenmund wrote:
>> On Mon, Oct 27, 2008 at 06:56:21PM +0100, Christoph Egger wrote:
>>> Bill Stouder-Studenmund wrote:
>>>> Module Name:       src
>>>> Committed By:      wrstuden
>>>> Date:              Mon Oct 27 16:52:04 UTC 2008
>>>>
>>>> Modified Files:
>>>>    src/sys/compat/sa: compat_sa.c
>>>>
>>>> Log Message:
>>>> Ok. Some calls to sa_upcall() pass in an 'l' that is not the current
>>>> lwp. Our "no-upcall" flagging however accesses l_pflag, and so we
>>>> can't access l->l_pflag. So access curlwp for the no-upcall-blocking
>>>> part.
>>> If you want to be kernel preemptible safe, you must cache curlwp.
>> Huh?
>>

[...]

> I realize I just went into a lot of detail. Also, I'll admit I think I'm 
> right. However the reason for the detail isn't to beat you down, it's so 
> that if I'm wrong, you can PLEASE PLEASE point out where I'm wrong. ;-)
> 
> If I'm wrong, I think the thing to do is disable kernel preemption in 
> sa_upcall().

With kernel preemption enabled, curlwp may unlock a different lwp than
the one you locked.

If you are sure, curlwp never changes between lock and unlock, then
my complaint is pointless. But if it can, then you have to either cache
curlwp in a variable or disable kernel preemption for this code section.

Christoph