linux-kernel - Re: [PATCH v4] erofs: lazily initialize per-CPU workers and CPU hotplug hooks

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: <aced334a-e542-42b9-ade4-00f6773c2d45@kernel.org>
Date: Tue, 29 Apr 2025 14:05:53 +0800
From: Chao Yu <chao@...nel.org>
To: Sandeep Dhavale <dhavale@...gle.com>
Cc: chao@...nel.org, linux-erofs@...ts.ozlabs.org,
 Gao Xiang <xiang@...nel.org>, Yue Hu <zbestahu@...il.com>,
 Jeffle Xu <jefflexu@...ux.alibaba.com>, hsiangkao@...ux.alibaba.com,
 kernel-team@...roid.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] erofs: lazily initialize per-CPU workers and CPU
 hotplug hooks

Hi Sandeep,

On 4/29/25 05:49, Sandeep Dhavale wrote:
> Hi Chao,
> 
>>
>> - mount #1                              - mount #2
>>  - z_erofs_init_pcpu_workers
>>   - atomic_xchg(, 1)
>>                                          - z_erofs_init_pcpu_workers
>>                                           - atomic_xchg(, 1)
>>                                           : return 0 since atomic variable is 1
>>                                           it will run w/o percpu workers and hotplug
>>   : update atomic variable to 1
>>   - erofs_init_percpu_workers
>>   : fail
>>   - atomic_set(, 0)
>>   : update atomic variable to 0 & fail the mount
>>
>> Can we add some logs to show we succeed/fail to initialize workers or
>> hotplugs? As for mount #2, it expects it will run w/ them, but finally
>> it may not. So we'd better have a simple way to know?
>>
>> Thanks,
>>
> What you have laid out as race, indeed can happen if
> erofs_init_percpu_workers() fails with ENOMEM. For me that is still
> not catastrophic as workqueue fallback is in place so the filesystem
> is still functional.  And at the next mount, the logic will be
> reattempted as the atomic variable is reset to 0 after failure.

Yeah, correct.

> 
> If you still think we need to have a log message, I will be happy to
> spin up the next revision with logging for ENOMEM.

I guess it will be good to add log for such case, thanks. :)

Thanks,

> 
> Thanks for the review!
> 
> Regards,
> Sandeep.