Messages in this thread | | | Date | Tue, 19 Nov 2013 14:20:58 -0800 | From | Andrew Morton <> | Subject | Re: [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..
| |