linux-kernel - Re: [GIT PULL] gpio: updates for v5.13

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: <CAHk-=whSWp3exv8tZ2th5im_P7HF=c6iuOOVb9iSrNrd6405WA@mail.gmail.com>
Date:   Mon, 3 May 2021 11:03:57 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Bartosz Golaszewski <brgl@...ev.pl>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] gpio: updates for v5.13

Al,
 would you mind taking a look at this part:

On Sun, May 2, 2021 at 12:32 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> You'll notice that we have a bunch of configfs commits in our tree not acked by
> the configfs maintainers. These commits implement the concept of committable
> items in configfs - something that was well defined in the documentation for
> years but has remained unimplemented. Despite the first submission of these
> patches back in November 2020[1] and repeated pings & resending, configfs
> maintainers have remained unresponsive. After reviewing these on the GPIO
> mailing list, we decided to pick them up ourselves and send them your way
> together with the first user: the new GPIO simulator.

It doesn't look huge to me, and I don't care all that deeply about
configfs, and honestly, I'm not seeing huge amounts of actual
development there, with recent commits all being about cleanup of vfs
changes (eg things like the new idmapping changes etc).

That said, I really don't want to pull that with some core sanity checking.

So Al, do you see anything horrendous in how that configfs thing uses
a rename to do kind of an "atomic swap" of configfs state?

                       Linus