linux-kernel - Re: [PATCH] [WIP] configfs: improve item creation performance

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]

Date:   Thu, 12 Oct 2023 16:59:34 -0700
From:   Seamus Connor <sconnor@...estorage.com>
To:     Seamus Connor <sconnor@...estorage.com>,
        Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [WIP] configfs: improve item creation performance

>
> This is subtle.  Your patch description of course describes why we are
> partitioning the items and attributes, but that will get lost into the
> memory hole very quickly.  Please add a comment.
>

Will do. And thanks for taking a look at the patch.

> Plus, aren't the pinned/not-pinned checks redundant?  Can't we avoid the
> extra conditional?
>
>
> ```
>         spin_lock(&configfs_dirent_lock);
>         list_for_each_entry(sd, &parent_sd->s_children, s_sibling) {
> -               if ((sd->s_type & CONFIGFS_NOT_PINNED) &&
> -                   !strcmp(configfs_get_name(sd), dentry->d_name.name)) {

Unfortunately they are not. CONFIGFS_IS_PINNED and CONFIGFS_NOT_PINNED
are asymmetrical. There is the readdir cursor (s_type == 0) that might
be anywhere in the list and should not be treated as a pinned item,
but should also not be treated as an unpinned attribute.

Is there any testing that you could recommend for this change? So far
I've gone through testing of our internal components that depend on
configfs, but I haven't done anything targeted.

Thanks,
Seamus