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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
