Re: [PATCH] Re: Race in fs/proc/generic.c:make_inode_number()

Maneesh Soni wrote: > > Just a couple of points: > > On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote: > [...] > > +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED; > > + > Why not make this static? > Initializer should be SPIN_LOCK_UNLOCKED. > Thanks, you're right on both counts.

Re: [PATCH] Re: Race in fs/proc/generic.c:make_inode_number()

Just a couple of points: On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote: [...] > +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED; > + Why not make this static? Initializer should be SPIN_LOCK_UNLOCKED. Maneesh Soni Linux Technology Center, IBM Bangalore. - To unsubscribe from this

[PATCH] Re: Race in fs/proc/generic.c:make_inode_number()

I wrote: > > The proc_alloc_map bitfield is unprotected by any lock, and > find_first_zero_bit() is not atomic. Concurrent module loading can race > here. Hello, Here is a patch for this. It looks like callers are always in user context (kmalloc flag GFP_KERNEL), so I used a light spinlock. Ch