linux-kernel - Re: [PATCH v2 2/3] block: don't hide inode from block

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 for Android: free password hash cracker in your pocket

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

Message-ID: <YWe3QZD+g8MSoCtT@infradead.org>
Date:   Thu, 14 Oct 2021 05:51:13 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Pavel Begunkov <asml.silence@...il.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] block: don't hide inode from block_device users

On Wed, Oct 13, 2021 at 07:44:20PM +0100, Pavel Begunkov wrote:
> Mildly hot in io_uring w/o fixed files, but that's not peak perf,
> but would also be great to get rid of bdev->bd_inode dereference,
> e.g. lots of in fops.c.
> 
> Are you going to just hid the dereference in helpers or kill it
> with some offseting magic?

The only real hot path uses I found is the size (which you and Jens
already seem to have moved to use something out of the inode for the
fast path),  and maybe the blkbits for which we could do the same.

So basically the idea is to not touch the inode in the hot path,
and use accessors helpers in bdev.c that could do the offsetof trick.