linux-kernel - Re: [f2fs-dev] [PATCH v2] f2fs: fix wrong inflight page stats for directIO

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] [day] [month] [year] [list]

Message-ID: <311ab257-2d67-fd73-8359-af5b44e1447c@kernel.org>
Date:   Thu, 22 Jul 2021 21:18:43 +0800
From:   Chao Yu <chao@...nel.org>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     jaegeuk@...nel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org, Chao Yu <chao.yu@...ux.dev>
Subject: Re: [f2fs-dev] [PATCH v2] f2fs: fix wrong inflight page stats for
 directIO

On 2021/7/22 9:42, Eric Biggers wrote:
> On Wed, Jul 21, 2021 at 05:46:26PM -0700, Eric Biggers wrote:
>> On Mon, Jul 19, 2021 at 04:45:48PM +0800, Chao Yu wrote:
>>> Previously, we use sbi->nr_pages[] to account direct IO, the count should
>>> be based on page granularity rather than bio granularity, fix it.
>>>
>>> Fixes: 02b16d0a34a1 ("f2fs: add to account direct IO")
>>> Signed-off-by: Chao Yu <chao@...nel.org>
> 
> Also, do we have to do this, as opposed to just moving F2FS_DIO_WRITE and
> F2FS_DIO_READ out of ->nr_pages[] and into separate counters that are clearly
> defined to be per-request?  As Christoph pointed out
> (https://lkml.kernel.org/r/YPU+3inGclUtcSpJ@infradead.org), these counters are
> only used to check whether there is any in-flight direct I/O at all.  (They're
> also shown in /sys/kernel/debug/f2fs/status, but that doesn't really matter.)
> 
> As Christoph mentioned, there is a way to avoid needing f2fs_dio_submit_bio()
> (which would save a memory allocation for every bio, which can fail).  But it
> will only work if the counters remain per-request.
> 
> Can we leave these as per-request?

I updated the patch, could you please check that?

Thanks,

> 
> - Eric
>