lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 10 Sep 2017 22:14:30 +0300 From: Rakesh Pandit <rakesh@...era.com> To: Matias Bjørling <mb@...htnvm.io> CC: <linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Javier González <jg@...htnvm.io> Subject: Re: [PATCH] lightnvm: prevent bd removal if busy On Fri, Sep 08, 2017 at 12:42:47PM +0200, Matias Bjørling wrote: > On 09/07/2017 03:58 PM, Rakesh Pandit wrote: > > Removal of virtual block device by "nvm lnvm remove..." undergoing IO > > and created by "nvme lnvm create... -t pblk" results in following and > > is annoying. > > > > 446416.309757] bdi-block not registered > > [446416.309773] ------------[ cut here ]------------ > > [446416.309780] WARNING: CPU: 3 PID: 4319 at fs/fs-writeback.c:2159 __mark_inode_dirty+0x268/0x340 > > ..... > > > > This patch solves this by checking bd_openers for each partition > > before removal can continue. Note that this isn't full proof as > > device can become busy as soon as it's bd_mutex is unlocked but it > > needn't be full proof either. It does work for general case where > > device is mounted and removal can be prevented. > > > > Signed-off-by: Rakesh Pandit <rakesh@...era.com> [..] > > + while ((part = disk_part_iter_next(&piter))) { > > A race condition can occur where disk_part_next tries to pblk (in > block/genhd.c), and it in the meantime has been set to NULL. Leading to a > kernel crash. Is there a better way to do it? > > [root@...alhost ~]# nvme lnvm remove -n pblk0 > [ 5262.338647] BUG: unable to handle kernel NULL pointer dereference at > 0000000000000010 > [ 5262.340769] IP: disk_part_iter_next+0xd3/0xf0 Thanks, indeed partition can go away from our feet if we don't lock the whole thing from changing and not just individual partition locks. I have given it another go which should avoid taking mutex locks on bdev. Posted V2.
Powered by blists - more mailing lists