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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Oct 2021 11:16:08 -0600 From: Jens Axboe <axboe@...nel.dk> To: Christoph Hellwig <hch@....de> Cc: Coly Li <colyli@...e.de>, Mike Snitzer <snitzer@...hat.com>, Song Liu <song@...nel.org>, David Sterba <dsterba@...e.com>, Josef Bacik <josef@...icpanda.com>, Theodore Ts'o <tytso@....edu>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, Dave Kleikamp <shaggy@...nel.org>, Ryusuke Konishi <konishi.ryusuke@...il.com>, Anton Altaparmakov <anton@...era.com>, Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Kees Cook <keescook@...omium.org>, Phillip Lougher <phillip@...ashfs.org.uk>, Jan Kara <jack@...e.com>, linux-block@...r.kernel.org, dm-devel@...hat.com, drbd-dev@...ts.linbit.com, linux-bcache@...r.kernel.org, linux-raid@...r.kernel.org, linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org, target-devel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org, jfs-discussion@...ts.sourceforge.net, linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net, ntfs3@...ts.linux.dev, reiserfs-devel@...r.kernel.org Subject: Re: don't use ->bd_inode to access the block device size v3 On 10/18/21 4:11 AM, Christoph Hellwig wrote: > Hi Jens, > > various drivers currently poke directy at the block device inode, which > is a bit of a mess. This series cleans up the places that read the > block device size to use the proper helpers. I have separate patches > for many of the other bd_inode uses, but this series is already big > enough as-is, This looks good to me. Followup question, as it's related - I've got a hacky patch that caches the inode size in the bdev: https://git.kernel.dk/cgit/linux-block/commit/?h=perf-wip&id=c754951eb7193258c35a574bd1ccccb7c4946ee4 so we don't have to dip into the inode itself for the fast path. While it's obviously not something being proposed for inclusion right now, is there a world in which we can make something like that work? -- Jens Axboe
Powered by blists - more mailing lists