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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ