linux-kernel - Re: [PATCH v2 6.6] io_uring/rw: ensure reissue path is correctly handled for IOPOLL

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: <2025081248-kinswoman-deserving-59c0@gregkh>
Date: Tue, 12 Aug 2025 12:49:33 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Sumanth Gavini <sumanth.gavini@...oo.com>
Cc: axboe@...nel.dk, asml.silence@...il.com, lkp@...el.com,
	io-uring@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, skhan@...uxfoundation.org,
	david.hunter.linux@...il.com, oe-kbuild-all@...ts.linux.dev,
	John Garry <john.g.garry@...cle.com>
Subject: Re: [PATCH v2 6.6] io_uring/rw: ensure reissue path is correctly
 handled for IOPOLL

On Sat, Aug 09, 2025 at 03:54:18PM -0500, Sumanth Gavini wrote:
> commit bcb0fda3c2da9fe4721d3e73d80e778c038e7d27 upstream.
> 
> The IOPOLL path posts CQEs when the io_kiocb is marked as completed,
> so it cannot rely on the usual retry that non-IOPOLL requests do for
> read/write requests.
> 
> If -EAGAIN is received and the request should be retried, go through
> the normal completion path and let the normal flush logic catch it and
> reissue it, like what is done for !IOPOLL reads or writes.
> 
> Fixes: d803d123948f ("io_uring/rw: handle -EAGAIN retry at IO completion time")
> Reported-by: John Garry <john.g.garry@...cle.com>
> Link: https://lore.kernel.org/io-uring/2b43ccfa-644d-4a09-8f8f-39ad71810f41@oracle.com/
> Signed-off-by: Jens Axboe <axboe@...nel.dk>
> Signed-off-by: Sumanth Gavini <sumanth.gavini@...oo.com>
> ---
> Changes in v2:
> - Removed the extra space before commit-id in message, No codes changes
> - Link to v1:https://lore.kernel.org/all/20250809182636.209767-1-sumanth.gavini@yahoo.com/

We can not take patches ONLY for older kernel trees and not newer ones,
otherwise you will have a regression when moving to a newer one.  I've
dropped this now, please submit for all relevant trees.

thanks,

greg k-h