linux-kernel - Requesting help in understanding commit 7cccd8, i.e. disabling preemption in slub.c:slab_alloc

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>] [day] [month] [year] [list]

Message-ID: <CA+C-WL8FD7hwXPTHdhjbRZ5j0bg3HZ_jgVhX_KoX6GzpjsEmew@mail.gmail.com>
Date:	Thu, 24 Jul 2014 08:10:25 -0400
From:	Patrick Palka <patrick@...cs.ath.cx>
To:	linux-mm@...ck.org
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Requesting help in understanding commit 7cccd8, i.e. disabling
 preemption in slub.c:slab_alloc_node

Hi everybody,

I am trying to figure out the race condition that commit 7cccd8 fixes.
The commit disables preemption in between the retrieval of the per-cpu
slab and the subsequent read of the slab's tid. According to the
commit message, this change helps avoid allocating from the wrong node
in slab_alloc. But try as I might, I can't see how allocating from the
wrong node, let alone the wrong cpu, could ever happen with or without
preemption. Isn't the globally-unique per-cpu tid the mechanism that's
supposed to guard against allocating from the wrong cpu or node? In
what way does this mechanism fail in slab_alloc_node, and how does
disabling preemption during the retrieval of the tid mitigate this
failure? Would really appreciate if somebody took the time to explain
this to a newbie like me.

Thanks,
Patrick
--
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/