you patch "block: push down BKL into .open and .release" and its changes to xen-blkfront.c

you patch "block: push down BKL into .open and .release" and its changes to xen-blkfront.c

[Jan Beulich]

Arnd,

what was the point of adding {,un}lock_kernel() to blkif_open() and
blkif_release()? Afaict, the associated bdev is protected by a mutex
anyway, so even without Daniel's addition of a mutex to these
paths I don't see the need for the BKL here.

Thanks, Jan

Re: you patch "block: push down BKL into .open and .release" and its changes to xen-blkfront.c

[Jens Axboe]

On 2010-08-25 12:59, Jan Beulich wrote:
> Arnd,
> 
> what was the point of adding {,un}lock_kernel() to blkif_open() and
> blkif_release()? Afaict, the associated bdev is protected by a mutex
> anyway, so even without Daniel's addition of a mutex to these
> paths I don't see the need for the BKL here.

I'll let Arnd answer for himself, but at least in general it's
much easier to let this sort of auditing and final cleanup
be done my the maintainer(s) of the driver in question, as they
are best positioned to verify that the BKL in fact isn't
really necessary in that path anymore.

-- 
Jens Axboe

Re: you patch "block: push down BKL into .open and .release" and its changes to xen-blkfront.c

[Arnd Bergmann]

On Wednesday 25 August 2010, Jens Axboe wrote:
> 
> On 2010-08-25 12:59, Jan Beulich wrote:
> > Arnd,
> > 
> > what was the point of adding {,un}lock_kernel() to blkif_open() and
> > blkif_release()? Afaict, the associated bdev is protected by a mutex
> > anyway, so even without Daniel's addition of a mutex to these
> > paths I don't see the need for the BKL here.
> 
> I'll let Arnd answer for himself, but at least in general it's
> much easier to let this sort of auditing and final cleanup
> be done my the maintainer(s) of the driver in question, as they
> are best positioned to verify that the BKL in fact isn't
> really necessary in that path anymore.

Traditionally, we were holding the BKL in common code while calling
block device open/release functions. In order to remove the BKL from
the block layer itself, I blindly pushed it into all the block
device drivers to make sure I don't break any driver that has a
hidden dependency on being called under a global lock.

The next step is to go through all drivers one by one and remove
the BKL from them, either by replacing it with a mutex or dropping
it entirely.

The only reason why you might need it is that you might be accessing
global state of the driver that is not protected by the per-device
mutex. If you know that this is not the case for a driver, then please
submit a patch to remove the BKL there.

	Arnd