lkml.org 
[lkml]   [2013]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/3] set_dumpable: fix the theoretical race with itself
On Tue, 19 Nov 2013 15:43:15 +0100 Oleg Nesterov <oleg@redhat.com> wrote:

> set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
> ensure that get_dumpable() can't observe the intermediate state,
> but this all can't help if multiple threads call set_dumpable()
> at the same time.
>
> And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
> with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
> SUID_DUMP_USER.
>
> Change this code to update both bits atomically via cmpxchg().
>
> Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
> if, say, an architecture implements cmpxchg() using the locking
> (like arch/parisc/lib/bitops.c does), then it should use the same
> locks for set_bit/etc.

I suppose that is reasonable - atomic operations on memory should be
atomic wrt other classes of atomic operations on the same memory. So
set_bit() has to "know" about concurrent cmpxchg(). It *has* to be
this way to fully emulate the hardware-based RMW operations.

parisc got that right. I wonder if all other architectures did, and
how on earth we can communicate this to future arch developers..



\
 
 \ /
  Last update: 2013-11-20 00:01    [W:0.073 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site