linux-kernel - Re: [PATCH RESEND] cpu/hotplug: Wait for cpu_hotplug to be enabled in cpu

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: <87o8uf1r3w.fsf@nanos.tec.linutronix.de>
Date:   Mon, 03 Feb 2020 19:08:03 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@...ia.com>,
        linux-kernel@...r.kernel.org
Cc:     "Sverdlin\, Alexander \(Nokia - DE\/Ulm\)" 
        <alexander.sverdlin@...ia.com>
Subject: Re: [PATCH RESEND] cpu/hotplug: Wait for cpu_hotplug to be enabled in cpu_up/down

Matija,

Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@...ia.com> writes:

> Heavier user of cpu_hotplug_enable/disable is pci_device_probe yielding
> errors on bringing cpu cores up/down if pci devices are getting probed.
> Situation in which pci devices are getting probed and having cpus going
> down/up is valid situation.

So what?. User space has to handle -EBUSY properly and it was possible
even before that PCI commit that the online/offline operation request
returned -EBUSY. 

> Problem was observed on x86 board by having partitioning of the system
> to RT/NRT cpu sets failing (of which part is to bring cpus down/up via
> sysfs) if pci devices would be getting probed at the same time. This is

I have no idea why you need to offline/online CPUs to partition a
system. There are surely more sensible ways to do that, but that's not
part of this discussion.

> confusing for userspace as dependency to pci devices is not clear.

What's confusing about a EBUSY return code? It's pretty universaly used
in situations where a facility is temporarily busy. If it's not
sufficiently documented, why EBUSY can be returned and what that means,
then this needs to be improved.

> Fix this behavior by waiting for cpu hotplug to be ready. Return -EBUSY
> only after hotplugging was not enabled for about 10 seconds.

There is nothing to fix here, really. Fix the user space handling which
fails to handle EBUSY. Just because this commit made it more likely that
EBUSY is returned does not justify this horrid hack.

Thanks,

        tglx