linux-kernel - Re: [PATCH -next] cgroup: Use descriptor table to unify mount flag management

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: <3ffe4fbd-5748-42ef-8148-c7dfc149493f@huaweicloud.com>
Date: Fri, 5 Dec 2025 09:44:26 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: tj@...nel.org, hannes@...xchg.org, cgroups@...r.kernel.org,
 linux-kernel@...r.kernel.org, lujialin4@...wei.com, chenridong@...wei.com
Subject: Re: [PATCH -next] cgroup: Use descriptor table to unify mount flag
 management



On 2025/12/5 0:23, Michal Koutný wrote:
> On Tue, Dec 02, 2025 at 09:53:11PM +0800, Chen Ridong <chenridong@...weicloud.com> wrote:
>> What do you think about this approach? If you have any suggestions for further improvement, I'd be
>> happy to incorporate them.
> 
> Yes, it's better due to the single place of definition.
> It made me to look around at some other filesystems from a random sample
> (skewed towards ones with more options) and I see:
> - many of them simply use the big switch/case in .parse_param,
> - ext4 has its specialized ext4_mount_opts array whose order needn't
>   match ext4_param_specs thanks to dynamic search.
> 
> All in all, I appreciate your effort, however, I'm not sure it's worth
> to deviate from the custom of other FS implementations.
> 
> Michal

Thank you for your feedback.

I also examined other filesystems, and you are correct—most do use a large switch/case structure in
.parse_param. However, none seem to have to maintain logic across three different functions like
cgroup does.

My intention was to avoid further expanding the if/switch chains, but given how many options we
already handle, perhaps a refactor isn't immediately necessary. We can leave it as is for now. If
mount options continue to increase, we might reconsider refactoring in the future.

Thank you again.

-- 
Best regards,
Ridong