[dm-devel] [PATCH 25/45] block: reference struct block_device from struct hd_struct

2020-11-24 Thread Christoph Hellwig
To simplify block device lookup and a few other upcoming areas, make sure that we always have a struct block_device available for each disk and each partition. The only downside of this is that each device and partition uses a little more memory. The upside will be that a lot of code can be simpl

Re: [dm-devel] [PATCH 25/45] block: reference struct block_device from struct hd_struct

2020-11-24 Thread Tejun Heo
Hello, Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits on the previous version. On Tue, Nov 24, 2020 at 02:27:31PM +0100, Christoph Hellwig wrote: > To simplify block device lookup and a few other upcoming areas, make sure > that we always have a struct block_device a

Re: [dm-devel] [PATCH 25/45] block: reference struct block_device from struct hd_struct

2020-11-25 Thread Christoph Hellwig
On Tue, Nov 24, 2020 at 04:18:49PM -0500, Tejun Heo wrote: > Hello, > > Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits > on the previous version. Thanks, I've addressed the mapping_set_gfp mask nit and updated the commit log. As Jan pointed also pointed out I think

Re: [dm-devel] [PATCH 25/45] block: reference struct block_device from struct hd_struct

2020-11-25 Thread Tejun Heo
Hello, On Wed, Nov 25, 2020 at 05:45:15PM +0100, Christoph Hellwig wrote: > On Tue, Nov 24, 2020 at 04:18:49PM -0500, Tejun Heo wrote: > > Hello, > > > > Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits > > on the previous version. > > Thanks, I've addressed the mappi

Re: [dm-devel] [PATCH 25/45] block: reference struct block_device from struct hd_struct

2020-11-26 Thread Christoph Hellwig
On Wed, Nov 25, 2020 at 03:20:23PM -0500, Tejun Heo wrote: > Agreed. It'd be nice to replace the stale comment. I've updated the comment. > > Jan added lookup_sem in commit 56c0908c855afbb to prevent a three way > > race between del_gendisk and blkdev_open due to the weird bdev vs > > gendisk lif