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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAB=BE-Ru31S1Qq0Gmi9UXtaL6k4dcLdTUa-CJbmhuXb7a2dSeQ@mail.gmail.com>
Date: Mon, 28 Apr 2025 14:49:25 -0700
From: Sandeep Dhavale <dhavale@...gle.com>
To: Chao Yu <chao@...nel.org>
Cc: 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 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.

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.

Thanks for the review!

Regards,
Sandeep.