linux-kernel - Re: [PATCH] mm/filemap: invalidating pages is still necessary when io with IOCB

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: <c66ca795-da93-437c-bb11-718801f8114a@kernel.dk>
Date: Thu, 30 May 2024 10:33:04 +0800
From: Liu Wei <liuwei09@...tc.cn>
To: liuwei09@...tc.cn
Cc: akpm@...ux-foundation.org,
	hch@....de,
	jack@...e.cz,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	rgoldwyn@...e.com,
	willy@...radead.org,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH] mm/filemap: invalidating pages is still necessary when io with IOCB_NOWAIT

From: Jens Axboe <axboe@...nel.dk>

On 5/27/24 4:09 AM, Liu Wei wrote:
> > I am a newer, thanks for the reminder.
> > 
> >>
> >> I don't think WB_SYNC_NONE tells it not to block, it just says not to
> >> wait for it... So this won't work as-is.
> > 
> > Yes, but I think an asynchronous writex-back is better than simply
> > return EAGAIN. By using __filemap_fdatawrite_range to trigger a
> > writeback, subsequent retries may have a higher chance of success. 
> 
> And what's the application supposed to do, just hammer on the same
> IOCB_NOWAIT submission until it then succeeds? The only way this can
> reasonably work for that would be if yo can do:
> 
> 1) Issue IOCB_NOWAIT IO
> 2) Get -EAGAIN
> 3) Sync kick off writeback, wait for it to be done
> 4) Issue IOCB_NOWAIT IO again
> 5) Success
> 
> If you just kick it off, then you'd repeat steps 1..2 ad nauseam until
> it works out, not tenable.
> 
> And this doesn't even include the other point I mentioned, which is
> __filemap_fdatawrite_range() IO issue blocking in the first place.
> 
> So no, NAK on this patch.
>

I know, thanks for your patient explanation.