linux-kernel - Re: [PATCH v1] ACPI / scan: Acquire device_hotplug_lock in acpi_scan

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: <45c9f942-fe67-fa60-b62f-31867f9c6e53@redhat.com>
Date:   Fri, 26 Jul 2019 10:57:52 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-acpi@...r.kernel.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>
Subject: Re: [PATCH v1] ACPI / scan: Acquire device_hotplug_lock in
 acpi_scan_init()

On 26.07.19 10:44, Michal Hocko wrote:
> On Fri 26-07-19 10:36:42, David Hildenbrand wrote:
>> On 26.07.19 10:31, Michal Hocko wrote:
> [...]
>>> Anyway, my dislike of the device_hotplug_lock persists. I would really
>>> love to see it go rather than grow even more to the hotplug code. We
>>> should be really striving for mem hotplug internal and ideally range
>>> defined locking longterm. 
>>
>> Yes, and that is a different story, because it will require major
>> changes to all add_memory() users. (esp, due to the documented race
>> conditions). Having that said, memory hotplug locking is not ideal yet.
> 
> I am really happy to hear that we are on the same page here. Do we have
> any document (I am sorry but I am lacking behind recent development in
> this area) that describes roadblocks to remove device_hotplug_lock?

Only the core-api document I mentioned (I documented there quite some
current conditions I identified back then).

I am not sure if we can remove it completely from
add_memory()/remove_memory(): We actually create/delete devices which
can otherwise create races with user space.

Besides that:
- try_offline_node() needs the lock to synchronize against cpu hotplug
- I *assume* try_online_node() needs it as well

Then, there is the possible race condition with user space onlining
memory avoided by the lock. Also, currently the lock protects the
"online_type" when onlining memory.

Then, there might be other global variables (eventually
zone/node/section related) that might need this lock right now - no
details known.

IOW, we have to be very carefully and it is more involved than it might
seem.

Locking is definitely better (and more reliably!) than one year ago, but
there is definitely a lot to do. (unfortunately, just like in many areas
in memory hotplug code :( - say zone handling when offlining/failing to
online memory).

-- 

Thanks,

David / dhildenb