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: <CALvZod5aTh6ZfQfkHiOhrdRKVxEaMVJ-ixbvD6j9JTLpcQWKzQ@mail.gmail.com>
Date:   Tue, 4 Jan 2022 10:20:05 -0800
From:   Shakeel Butt <shakeelb@...gle.com>
To:     Manfred Spraul <manfred@...orfullife.com>
Cc:     Jiri Slaby <jirislaby@...nel.org>, cgel.zte@...il.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        stable <stable@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        chi.minghao@....com.cn, Davidlohr Bueso <dbueso@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Randy Dunlap <rdunlap@...radead.org>, unixbhaskar@...il.com,
        Vasily Averin <vvs@...tuozzo.com>, zealci@....com.cn
Subject: Re: [PATCH v2] ipc/sem: do not sleep with a spin lock held

On Mon, Jan 3, 2022 at 9:18 AM Manfred Spraul <manfred@...orfullife.com> wrote:
>
> Hi Jiri,
>
> On 1/3/22 10:27, Jiri Slaby wrote:
> > On 23. 12. 21, 4:12, cgel.zte@...il.com wrote:
> >> From: Minghao Chi <chi.minghao@....com.cn>
> >>
> >> We can't call kvfree() with a spin lock held, so defer it.
> >
> > Sorry, defer what?
> >
> First drop the spinlock, then call kvfree().
>
>
> > There are attempts to fix kvfree instead, not sure which of these
> > approaches (fix kvfree or its callers) won in the end?
> >
> Exactly. We have three options - but noone volunteered yet to decide:
>
> - change ipc/sem.c [minimal change]

Let's go with the minimal change for now which can easily be
cherry-picked for the stable tree. It seems other approaches need more
work/discussion.

>
> - change kvfree() to use vfree_atomic() [would also fix other changes
> that did s/kfree/kvfree/]
>
> - Modify the vma handling so that it becomes safe to call vfree() while
> holding a spinlock. [perfect approach, but I'm concerned about side effects]
>
>
> --
>
>      Manfred
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ