Linus Torvalds wrote:
quoted text
> 
> On Wed, 14 May 2008, Alan Cox wrote:
>> That in itself is a problem Ingo's stuff won't help with: We have lots of
>> "magic" accidental, undocumented and pot luck BKL locking semantics
>> between subsystems that are not even visible.
> 
> The good news is that I suspect they are going away. It probably is mainly 
> tty and /proc by now, and /proc is pretty close to done.

Character devices in general.

And what's pretty nasty is that some interfaces force BKL still, so
not even new code can opt out.

quoted text
> In the VFS layer, we still have 
> 
>  - the ioctl thing, obviously. That's just mind-numbing "move things 
>    down", not hard per se. But there's a *lot* of them (and I suspect the 
>    huge majority of them don't actually need it, since they'd already be 
>    racing against read/write anyway if they did).
> 
>  - default_llseek(). Probably the same, just a lot less of it.

I had some patches for those.

quoted text
> 
>  - superblock read/write.
> 

- fasync

[had some patches for "fasync_locked", not sure if it's worth it]

- character device open

That's a nasty one. Either open_unlocked or a special cdev_init?

quoted text
> and the latter one in particular is really dubious (we already have 
> "[un]lock_super()" around it all, I think).
> 
> The core kernel, VM and networking already don't really do BKL. And it's 
> seldom the case that subsystems interact with other unrelated subsystems 
> outside of the core areas.
> 
> So it's a lot of work, no doubt, but I do think we should be able to do 
> it. The most mind-numbing part is literally all the ioctl crud. There's 
> more ioctl points than there are lock_kernel() calls left anywhere else.

I tried to recruit kernel janitors some time ago to just do all the
ioctl -> ioctl_unlocked/explicit lock_kernel changes. There were a few
patches generated but the effort died down then.

BTW for ioctl the dynamic instrumentation method proposed also won't
work because it's basically impossible to exercise all these ioctls

-Andi


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/