linux-kernel - Re: [PATCH v2] io_uring: Avoid polling configuration errors

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: <7aba7c09-9c21-46cc-95fc-d2b9b5bbcd3b@kernel.dk>
Date: Mon, 15 Jul 2024 04:59:44 -0600
From: Jens Axboe <axboe@...nel.dk>
To: hexue <xue01.he@...sung.com>
Cc: asml.silence@...il.com, hch@...radead.org, io-uring@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] io_uring: Avoid polling configuration errors

On 7/14/24 8:39 PM, hexue wrote:
>> My stance is still the same - why add all of this junk just to detect a
>> misuse of polled IO? It doesn't make sense to me, it's the very
>> definition of "doctor it hurts when I do this" - don't do it.
> 
>> So unless this has _zero_ overhead or extra code, which obviously isn't
>> possible, or extraordinary arguments exists for why this should be
>> added, I don't see this going anywhere.
> 
> Actually, I just want users to know why they got wrong data, just a
> warning of an error, like doctor tell you why you do this will hurt. I
> think it's helpful for users to use tools accurately. and yes, this
> should be as simple as possible, I'll working on it. I'm not sure if I
> made myself clear and make sense to you?

Certainly agree that that is an issue and a much more worthy reason for
the addition. It's the main reason why -EOPNOTSUPP return would be more
useful, and I'd probably argue the better way then to do it. It may
indeed break existing use cases, but probably only because they are
misconfigured.

That then means that it'd be saner to do this on the block layer side,
imho, as that's when the queue is resolved anyway, rather than attempt
to hack around this on the issuing side.

-- 
Jens Axboe