linux-kernel - Re: [PATCH v8 0/2] gpiolib: don't allow user-space to crash the kernel with hot-unplugs

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: <CAMRc=MeMA+11Gdb2kaCrS5G+05PONT7i9Nw0VH+B7bJA3apydw@mail.gmail.com>
Date:   Mon, 5 Dec 2022 14:27:32 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Kent Gibson <warthog618@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nick Hainke <vincent@...temli.org>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v8 0/2] gpiolib: don't allow user-space to crash the
 kernel with hot-unplugs

On Mon, Dec 5, 2022 at 2:17 PM Kent Gibson <warthog618@...il.com> wrote:
>
> On Mon, Dec 05, 2022 at 03:01:13PM +0200, Andy Shevchenko wrote:
> > On Mon, Dec 05, 2022 at 02:59:42PM +0200, Andy Shevchenko wrote:
> > > On Mon, Dec 05, 2022 at 01:39:01PM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > > >
> > > > Linus Torvalds pointed out that using trylock here is wrong. This iteration
> > > > drops it in favor of unconditional locks but keeps all the fixes that came
> > > > later.
> > > >
> > > > I will also not send it for this release but make it part of the updates PR
> > > > for v6.2 to give it some time in next.
> > > >
> > > > v7 -> v8:
> > > > - don't use down_read_trylock(), just go straight for a full lock
> > >
> > > Yep, it was a good wrap-up explanation.
> >
> > But he also suggested to fold NULL check into call_*_locked(). Any points why
> > you decided not to go that way?
> >
>
> He also mentioned making it more back-portable.
> Does that mean splitting out the patches for uAPI v1 and v2, if not for
> each of the Fixes? Or does he mean back-porting it to 6.1?

I think he mentioned not sending it for v6.1 that late in the cycle
and instead sending it for v6.2 and backporting it to v6.1. I'm afraid
that backporting of this fix will require some manual labor anyway.
We'll want to backport it to branches that don't have v2 yet after
all, where that code resided elsewhere.

Bartosz