[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