linux-kernel - Re: [PATCH 0/5] x86: Cleanups around slow_down

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: <bff8626d-161e-4470-9cbd-7bbda6852ec3@suse.com>
Date: Mon, 15 Dec 2025 07:36:57 +0100
From: Jürgen Groß <jgross@...e.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 virtualization@...ts.linux.dev, kvm@...r.kernel.org,
 linux-hwmon@...r.kernel.org, linux-block@...r.kernel.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, Ajay Kaher <ajay.kaher@...adcom.com>,
 Alexey Makhalov <alexey.makhalov@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Paolo Bonzini
 <pbonzini@...hat.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 xen-devel@...ts.xenproject.org, Jean Delvare <jdelvare@...e.com>,
 Guenter Roeck <linux@...ck-us.net>, Denis Efremov <efremov@...ux.com>,
 Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

On 14.12.25 09:05, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@...e.com> wrote:
> 
>> While looking at paravirt cleanups I stumbled over slow_down_io() and
>> the related REALLY_SLOW_IO define.
>>
>> Especially REALLY_SLOW_IO is a mess, which is proven by 2 completely
>> wrong use cases.
>>
>> Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the
>> io_delay() paravirt function hook.
>>
>> Patches 2 and 3 are not changing any functionality, but maybe they
>> should? As the potential bug has been present for more than a decade
>> now, I went with just deleting the useless "#define REALLY_SLOW_IO".
>> The alternative would be to do something similar as in patch 5.
>>
>> Juergen Gross (5):
>>    x86/paravirt: Replace io_delay() hook with a bool
>>    hwmon/lm78: Drop REALLY_SLOW_IO setting
>>    hwmon/w83781d: Drop REALLY_SLOW_IO setting
>>    block/floppy: Don't use REALLY_SLOW_IO for delays
>>    x86/io: Remove REALLY_SLOW_IO handling
>>
>>   arch/x86/include/asm/floppy.h         | 27 ++++++++++++++++++++++-----
>>   arch/x86/include/asm/io.h             | 12 +++++-------
>>   arch/x86/include/asm/paravirt.h       | 11 +----------
>>   arch/x86/include/asm/paravirt_types.h |  3 +--
>>   arch/x86/kernel/cpu/vmware.c          |  2 +-
>>   arch/x86/kernel/kvm.c                 |  8 +-------
>>   arch/x86/kernel/paravirt.c            |  3 +--
>>   arch/x86/xen/enlighten_pv.c           |  6 +-----
>>   drivers/block/floppy.c                |  2 --
>>   drivers/hwmon/lm78.c                  |  5 +++--
>>   drivers/hwmon/w83781d.c               |  5 +++--
>>   11 files changed, 39 insertions(+), 45 deletions(-)
> 
> I think we should get rid of *all* io_delay hacks, they might have been
> relevant in the days of i386 systems, but we don't even support i386
> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
> There's been enough changes around all these facilities that the
> original timings are probably way off already, so we've just been
> cargo-cult porting these to newer kernels essentially.

Fine with me.

Which path to removal of io_delay would you (and others) prefer?

1. Ripping it out immediately.

2. Hiding it behind a default-off config option for a few kernel versions
    before removing it.

3. Using CONFIG_IO_DELAY_NONE as the default io_delay_type before ripping it
    out.

4. Using CONFIG_IO_DELAY_NONE as the default io_delay_type before hiding it
    behind a default-off config option, then rip it out later.

In cases 2-4 I'd still like to have patch 1 of my series applied, as it will
make paravirt rework easier.

Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)