Re: FS-specified FSID for non-device based filesystems?

[Al Viro <viro@ftp.linux.org.uk>]

On Thu, Apr 20, 2006 at 01:58:43PM +0200, Miklos Szeredi wrote:
> > Speaking of obvious holes, what is
> >         /* Setting file->private_data can't race with other mount()
> >            instances, since BKL is held for ->get_sb() */
> >         if (file->private_data)
> >                 return -EINVAL;
> > doing, seeing that the next thing you do is GFP_KERNEL allocations, which
> > would kill all hope to use BKL-based protection here?
> 
> Why?  I didn't know BKL is incompatible with allocations.

BKL is dropped when you give up CPU.  It is reacquired when you get scheduled
again.  It's not a mutex; it's not a spinlock.  The right way to look at it
is the following:
	* task has dumbness counter; lock_kernel() increments it,
unlock_kernel() decrements.
	* at most one dumb task can have CPU at any given time
	* dumb tasks are not preempted
That's it.  You are only protected against other dumb tasks and *only* as long
as you don't block.  Blocking won't make you any less dumb, so the same
warranties resume once you do get CPU again.  However, anything might have
happened while you were blocked.

On UP boxen with PREEMPT disabled it's simply a no-op - it's all about
emulating that situation.