On 2019/05/16 21:32, Jan Kara wrote: > On Thu 16-05-19 21:17:14, Tetsuo Handa wrote: >> On 2019/05/16 20:48, Jan Kara wrote: >>> OK, so non-racy fix was a bit more involved and I've ended up just >>> upgrading the file reference to an exclusive one in loop_set_fd() instead >>> of trying to hand-craft some locking solution. The result is attached and >>> it passes blktests. >> >> blkdev_get() has corresponding blkdev_put(). >> bdgrab() does not have corresponding bdput() ? > > Yes, and that's hidden inside blkdev_put() (or failing blkdev_get()). Don't > get me started on calling conventions of these functions... I've wasted half > an hour trying to figure out where I'm leaking inode references in my patch > ;). Ah, found tricky comment. Please apply the patch. Thank you. /** * blkdev_get - open a block device * @bdev: block_device to open * @mode: FMODE_* mask * @holder: exclusive holder identifier * * Open @bdev with @mode. If @mode includes %FMODE_EXCL, @bdev is * open with exclusive access. Specifying %FMODE_EXCL with %NULL * @holder is invalid. Exclusive opens may nest for the same @holder. * * On success, the reference count of @bdev is unchanged. On failure, * @bdev is put. * * CONTEXT: * Might sleep. * * RETURNS: * 0 on success, -errno on failure. */
