linux-kernel - Re: [RFC PATCH 1/3] filemap: convert page_endio to folio

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: <ZBHcl8Pz2ULb4RGD@infradead.org>
Date:   Wed, 15 Mar 2023 07:56:23 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Pankaj Raghav <p.raghav@...sung.com>
Cc:     hubcap@...ibond.com, senozhatsky@...omium.org, martin@...ibond.com,
        willy@...radead.org, minchan@...nel.org, viro@...iv.linux.org.uk,
        brauner@...nel.org, axboe@...nel.dk, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        gost.dev@...sung.com, mcgrof@...nel.org, devel@...ts.orangefs.org
Subject: Re: [RFC PATCH 1/3] filemap: convert page_endio to folio_endio

Can we take a step back and figure out if page_endio is a good
idea to start with?

The zram usage seems clearly wrong to me.  zram is a block driver
and does not own the pages, so it shouldn't touch any of the page
state.  It seems like this mostly operates on it's own
pages allocated using alloc_page so the harm might not be horrible
at least.

orangefs uses it on readahead pages, with ret known for the whole
iteration.  So one quick loop for the success and one for the
failure case would look simpler an more obvious.

mpage really should use separate end_io handler for read vs write
as well like most other aops do.

So overall I'd be happier to just kill the helper.