[OpenAFS-devel] [PATCH] fix openafs crashes on linux 2.6.10-2.6.12, and all RHEL4 kernels

Christopher Allen Wing wingc@engin.umich.edu
Wed, 18 Apr 2007 16:01:53 -0400 (EDT)


On Wed, 18 Apr 2007, Derrick J Brashear wrote:

> On Wed, 18 Apr 2007, Chaskiel M Grundman wrote:
>
>> --On Wednesday, April 18, 2007 02:45:36 PM -0400 Christopher Allen Wing 
>> <wingc@engin.umich.edu> wrote:
>> 
>>> I don't understand the usage of AFS_GLOCK(); why is it safe to drop and
>>> re-acquire it in cases like this?  Is AFS_GLOCK intended to serialize all
>>> AFS calls coming from vnode methods in the kernel?
>> 
>> AFS_GLOCK is intended to prevent smp concurrency (and preemption). It also 
>> provides mutual exclusion for ObtainXXXLock. AFS_GLOCK is dropped almost 
>> any time the cache manager is going to sleep.
>
> Of course that doesn't make it necessarily safe to drop and reacquire. In 
> practice we've just attempted to make it safe every time it's cropped up that 
> it's not.
>
> The __vmalloc approach would be safer if we were even vaguely sure that it 
> was exported in enough cases.

__vmalloc() is exported from linux-2.4.0 up to and including today's 
source tree.  GFP_NOFS didn't exist until midway through 2.4 anyway, so 
it's a moot point if we have to use vmalloc() instead for <= 2.4.

(actually, in 2.4 kernels vmalloc() is an inline function in a header file 
and only __vmalloc() is exported; in 2.6, both are symbols)


The way that vmalloc() calls __vmalloc() hasn't ever changed, so it should 
be a relatively safe change.  (might need to include another kernel header 
though to get the correct defines and typedefs)


-Chris Wing
wingc@engin.umich.edu