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
| ||
|
Message-ID: <20230825134756.o3wpq6bogndukn53@quack3> Date: Fri, 25 Aug 2023 15:47:56 +0200 From: Jan Kara <jack@...e.cz> To: Al Viro <viro@...iv.linux.org.uk> Cc: Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org, Christoph Hellwig <hch@...radead.org>, Alasdair Kergon <agk@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, Anna Schumaker <anna@...nel.org>, Chao Yu <chao@...nel.org>, Christian Borntraeger <borntraeger@...ux.ibm.com>, "Darrick J. Wong" <djwong@...nel.org>, Dave Kleikamp <shaggy@...nel.org>, David Sterba <dsterba@...e.com>, dm-devel@...hat.com, drbd-dev@...ts.linbit.com, Gao Xiang <xiang@...nel.org>, Jack Wang <jinpu.wang@...os.com>, Jaegeuk Kim <jaegeuk@...nel.org>, jfs-discussion@...ts.sourceforge.net, Joern Engel <joern@...ybastard.org>, Joseph Qi <joseph.qi@...ux.alibaba.com>, Kent Overstreet <kent.overstreet@...il.com>, linux-bcache@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-mm@...ck.org, linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org, linux-nvme@...ts.infradead.org, linux-pm@...r.kernel.org, linux-raid@...r.kernel.org, linux-s390@...r.kernel.org, linux-scsi@...r.kernel.org, linux-xfs@...r.kernel.org, "Md. Haris Iqbal" <haris.iqbal@...os.com>, Mike Snitzer <snitzer@...nel.org>, Minchan Kim <minchan@...nel.org>, ocfs2-devel@....oracle.com, reiserfs-devel@...r.kernel.org, Sergey Senozhatsky <senozhatsky@...omium.org>, Song Liu <song@...nel.org>, Sven Schnelle <svens@...ux.ibm.com>, target-devel@...r.kernel.org, Ted Tso <tytso@....edu>, Trond Myklebust <trond.myklebust@...merspace.com>, xen-devel@...ts.xenproject.org, Jens Axboe <axboe@...nel.dk>, Christian Brauner <brauner@...nel.org> Subject: Re: [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle On Fri 25-08-23 02:58:43, Al Viro wrote: > On Fri, Aug 11, 2023 at 01:04:31PM +0200, Jan Kara wrote: > > Hello, > > > > this is a v2 of the patch series which implements the idea of blkdev_get_by_*() > > calls returning bdev_handle which is then passed to blkdev_put() [1]. This > > makes the get and put calls for bdevs more obviously matching and allows us to > > propagate context from get to put without having to modify all the users > > (again!). In particular I need to propagate used open flags to blkdev_put() to > > be able count writeable opens and add support for blocking writes to mounted > > block devices. I'll send that series separately. > > > > The series is based on Christian's vfs tree as of yesterday as there is quite > > some overlap. Patches have passed some reasonable testing - I've tested block > > changes, md, dm, bcache, xfs, btrfs, ext4, swap. This obviously doesn't cover > > everything so I'd like to ask respective maintainers to review / test their > > changes. Thanks! I've pushed out the full branch to: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git bdev_handle > > > > to ease review / testing. > > Hmm... Completely Insane Idea(tm): how about turning that thing inside out and > having your bdev_open_by... return an actual opened struct file? > > After all, we do that for sockets and pipes just fine and that's a whole lot > hotter area. > > Suppose we leave blkdev_open()/blkdev_release() as-is. No need to mess with > what we have for normal opened files for block devices. And have block_open_by_dev() > that would find bdev, etc., same yours does and shove it into anon file. > > Paired with plain fput() - no need to bother with new primitives for closing. > With a helper returning I_BDEV(bdev_file_inode(file)) to get from those to bdev. > > NOTE: I'm not suggesting replacing ->s_bdev with struct file * if we do that - > we want that value cached, obviously. Just store both... > > Not saying it's a good idea, but... might be interesting to look into. > Comments? I can see the appeal of not having to introduce the new bdev_handle type and just using struct file which unifies in-kernel and userspace block device opens. But I can see downsides too - the last fput() happening from task work makes me a bit nervous whether it will not break something somewhere with exclusive bdev opens. Getting from struct file to bdev is somewhat harder but I guess a helper like F_BDEV() would solve that just fine. So besides my last fput() worry about I think this could work and would be probably a bit nicer than what I have. But before going and redoing the whole series let me gather some more feedback so that we don't go back and forth. Christoph, Christian, Jens, any opinion? Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists