linux-kernel - Re: [PATCH 1/2] pid: tighten pidmap spinlock critical section by removing kfree()

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: <b8bf37780911230726x7ec9b8b4s9adec2202de5fb87@mail.gmail.com>
Date:	Mon, 23 Nov 2009 13:26:09 -0200
From:	André Goddard Rosa <andre.goddard@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 1/2] pid: tighten pidmap spinlock critical section by 
	removing kfree()

Hi, Oleg!

On Mon, Nov 23, 2009 at 12:03 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 11/23, Pekka Enberg wrote:
>> (Adding some CC's.)
>>
>> On Sat, Nov 21, 2009 at 2:16 PM, André Goddard Rosa
>> <andre.goddard@...il.com> wrote:
>> > Avoid calling kfree() under pidmap spinlock, calling it afterwards.
>> >
>> > Normally kfree() is very fast, but sometimes it can be slow, so avoid
>> > calling it under the spinlock if we can.
>
> kfree() is called when we race with another process which also
> finds map->page == NULL, allocs the new page and takes pidmap_lock
> before us. This is extremely unlikely case, right?

Right, somehow.

>> > @@ -141,11 +141,12 @@ static int alloc_pidmap(struct pid_namespace *pid_ns)
>> >                         * installing it:
>> >                         */
>> >                        spin_lock_irq(&pidmap_lock);
>> > -                       if (map->page)
>> > -                               kfree(page);
>> > -                       else
>> > +                       if (!map->page) {
>> >                                map->page = page;
>> > +                               page = NULL;
>> > +                       }
>> >                        spin_unlock_irq(&pidmap_lock);
>> > +                       kfree(page);
>
> And this change pessimizes (a little bit) the likely case, when
> the race doesn't happen. And imho this change doesn't make the
> code more readable.
>
> But this is subjective, and technically the patch is correct
> afaics.

It does not affect the likely case which happens when the pidmap is
already allocated.

In the unlikely case where the pidmap must be allocated, if we think
that we could have
let's say 8 processes contending for that spinlock, while one process
got it first and allocated
the page, having the kfree() out of the spinlock would make those
other 7 processes doing
useful work (performing the release of the page) before, because it
would avoid all of them
spinning around waiting until the all the others also free their
allocated pages.

>> >                        if (unlikely(!map->page))
>> >                         �
>
> Hmm. Off-topic, but why alloc_pidmap() does not do this right
> after kzalloc() ?

Hmm... I would say that it's an optimistic best effort. We avoid
failing right away
hoping that another process (racing) had success allocating the page.
That is unlikely! :)

Thank you,
André
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/