linux-kernel - Re: Re: [PATCH] block: 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] [day] [month] [year] [list]

Message-Id: <20240619063847.588031-1-xue01.he@samsung.com>
Date: Wed, 19 Jun 2024 14:38:47 +0800
From: hexue <xue01.he@...sung.com>
To: axboe@...nel.dk
Cc: hch@...radead.org, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] block: Avoid polling configuration errors

On 6/16/24 2:39 AM,, Jens Axboe wrote:
>On 6/13/24 2:07 AM, Christoph Hellwig wrote:
>>> We happily allow polled IO for async polled IO, even if the destination
>>> queue isn't polled (or it doesn't exist). This is different than the old
>>> sync polled support.
>> 
>> Yes, and for that to work we can't start returning -EOPNOTSUPP as in
>> this patch, as BLK_QC_T_NONE an be cleared for all kinds of reasons.
>> 
>> So if we want some kind of error handling that people don't even
>> bother to poll for devices where it is not supported we need that
>> check much earlier (probably in io_uring).
>
>There's just no way we can do that, who knows if you'll run into a
>polled queue or not further down the stack.
>
>IMHO there's nothing wrong with the current code. If you do stupid
>things (do polled IO without having polled queues), then you get to
>collect stupid prizes (potentially excessive CPU usage).

I think the problem is that when the user makes this incorrect configuration,
but doesn't have any error feedback, user is unware and easy to get some wrong
performance information. So I hope to add some feedback for the user to help
them more easily modify the configuration.

I got your point, therefore, I'm considering whether it would be more
resonable to not return -EOPNOTSUPP directly to stop the operation.
Instead, we could detect this information and provide a prompt (like 
warining?), allowing user to be aware without disrupting the original
flow. Do you think this approach is more reasonable?