linux-kernel - [PATCH 0/7] block: reread partitions improvements

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1428474226-27386-1-git-send-email-jarod@redhat.com>
Date:	Wed,  8 Apr 2015 02:23:39 -0400
From:	Jarod Wilson <jarod@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	Jarod Wilson <jarod@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Markus Pargmann <mpa@...gutronix.de>,
	Stefan Weinhuber <wein@...ibm.com>,
	Stefan Haberland <stefan.haberland@...ibm.com>,
	Sebastian Ott <sebott@...ux.vnet.ibm.com>,
	Fabian Frederick <fabf@...net.be>,
	Ming Lei <ming.lei@...onical.com>,
	David Herrmann <dh.herrmann@...il.com>,
	Mike Galbraith <bitbucket@...ine.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	nbd-general@...ts.sourceforge.net, linux-s390@...r.kernel.org
Subject: [PATCH 0/7] block: reread partitions improvements

For loop, the root cause is one ABBA and one AA lock dependency
issue, and the two are fixed by patch 2 and patch 3 each.

Another reason is from the trylock in blkdev_reread_part(), which
may cause partition scanning failure too sometimes when another task
is holding the bd_mutex. In the discussion[1], both Tejun and Christoph
suggests to replace the trylock with mutex_lock in blkdev_reread_part(),
also Christoph suggests to export blkdev_reread_part.

Following the discussion, this patchset exports blkdev_reread_part(), and
introduces lockless __blkdev_reread_part() for fixing loop's AA lock issue.
Then ioctl_by_bdev(BLKRRPART) in loop, nbd and dasd is replaced with
blkdev_reread_part(). In the last patch, trylock in blkdev_reread_part()
is replaced with mutex_lock, and some analysis is provided about the
conversion.

This is a slightly reworked set from what Ming sent a few days ago,
based on Christoph's feedback. I've tested this out quite succesfully
in the scenario that prompted my first patch as well.


[1], https://lkml.org/lkml/2015/1/26/137
[2], https://lkml.org/lkml/2015/3/31/888

Jarod Wilson (3):
  block: export blkdev_reread_part() and __blkdev_reread_part()
  block: loop: fix another reread part failure
  s390/block/dasd: remove obsolete while -EBUSY loop

Ming Lei (4):
  block: loop: don't hold lo_ctl_mutex in lo_open
  block: nbd: convert to blkdev_reread_part()
  block: dasd_genhd: convert to blkdev_reread_part
  block: replace trylock with mutex_lock in blkdev_reread_part()

 block/ioctl.c                   | 34 +++++++++++++++++++----
 drivers/block/loop.c            | 60 ++++++++++++++++++++++++++++++++++-------
 drivers/block/loop.h            |  1 +
 drivers/block/nbd.c             |  2 +-
 drivers/s390/block/dasd_genhd.c | 22 +++++----------
 include/linux/fs.h              |  3 +++
 6 files changed, 90 insertions(+), 32 deletions(-)

CC: Christoph Hellwig <hch@...radead.org>
CC: Jens Axboe <axboe@...nel.dk>
CC: Tejun Heo <tj@...nel.org>
CC: Alexander Viro <viro@...iv.linux.org.uk>
CC: Markus Pargmann <mpa@...gutronix.de>
CC: Stefan Weinhuber <wein@...ibm.com>
CC: Stefan Haberland <stefan.haberland@...ibm.com>
CC: Sebastian Ott <sebott@...ux.vnet.ibm.com>
CC: Fabian Frederick <fabf@...net.be>
CC: Ming Lei <ming.lei@...onical.com>
CC: David Herrmann <dh.herrmann@...il.com>
CC: Mike Galbraith <bitbucket@...ine.de>
CC: Andrew Morton <akpm@...ux-foundation.org>
CC: Peter Zijlstra <peterz@...radead.org>
CC: nbd-general@...ts.sourceforge.net
CC: linux-s390@...r.kernel.org

-- 
1.8.3.1

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