summaryrefslogtreecommitdiff
path: root/fs/ioprio.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2010-04-07 13:53:59 +0400
committerJens Axboe <jens.axboe@oracle.com>2010-04-27 12:57:54 +0400
commit6b4517a7913a09d3259bb1d21c9cb300f12294bd (patch)
treea79a1a95c0ef193b20fc004b575f65826f2a85cc /fs/ioprio.c
parent1a3cbbc5a5e8a66934aa0947896a4aca6fd77298 (diff)
downloadlinux-6b4517a7913a09d3259bb1d21c9cb300f12294bd.tar.xz
block: implement bd_claiming and claiming block
Currently, device claiming for exclusive open is done after low level open - disk->fops->open() - has completed successfully. This means that exclusive open attempts while a device is already exclusively open will fail only after disk->fops->open() is called. cdrom driver issues commands during open() which means that O_EXCL open attempt can unintentionally inject commands to in-progress command stream for burning thus disturbing burning process. In most cases, this doesn't cause problems because the first command to be issued is TUR which most devices can process in the middle of burning. However, depending on how a device replies to TUR during burning, cdrom driver may end up issuing further commands. This can't be resolved trivially by moving bd_claim() before doing actual open() because that means an open attempt which will end up failing could interfere other legit O_EXCL open attempts. ie. unconfirmed open attempts can fail others. This patch resolves the problem by introducing claiming block which is started by bd_start_claiming() and terminated either by bd_claim() or bd_abort_claiming(). bd_claim() from inside a claiming block is guaranteed to succeed and once a claiming block is started, other bd_start_claiming() or bd_claim() attempts block till the current claiming block is terminated. bd_claim() can still be used standalone although now it always synchronizes against claiming blocks, so the existing users will keep working without any change. blkdev_open() and open_bdev_exclusive() are converted to use claiming blocks so that exclusive open attempts from these functions don't interfere with the existing exclusive open. This problem was discovered while investigating bko#15403. https://bugzilla.kernel.org/show_bug.cgi?id=15403 The burning problem itself can be resolved by updating userspace probing tools to always open w/ O_EXCL. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Matthias-Christian Ott <ott@mirix.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Diffstat (limited to 'fs/ioprio.c')
0 files changed, 0 insertions, 0 deletions