From: Peter Zijlstra
> Sent: 16 April 2021 15:19
>
> On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> > On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
>
> > > int perf_event_task_enable(void)
> > > {
> > > + DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_mutex);
> >
> > There is nothing in C forcing developers to actually use DEFINE_MUTEX_GUARD. So
> > someone may simply forget (or not know that they need) to lock
> > current->perf_event_mutex and directly access some field protected by it. This
> > is unlikely to happen when one first writes the code, but over time as different
> > people modify the code and invariants change, it is possible for this to happen.
> >
> > In Rust, this isn't possible: the data protected by a lock is only accessible
> > when the lock is locked. So developers cannot accidentally make mistakes of this
> > kind. And since the enforcement happens at compile time, there is no runtime
> > cost.
> >
> > This, we believe, is fundamental to the discussion: we agree that many of these
> > idioms can be implemented in C (albeit in this case with a compiler extension),
> > but their use is optional, people can (and do) still make mistakes that lead to
> > vulnerabilities; Rust disallows classes of mistakes by construction.
>
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
>
> That's a semi common scheme in the kernel, but not something that's
> expressible by, for example, the Java sync keyword.
>
> It also very much doesn't work for RCU, where modification must be done
> under a lock, but access is done essentially lockless.
...
Or the cases where the locks are released in the 'wrong' order.
Typically for:
lock(table)
item = lookup(table, key)
lock(item)
unlock(table)
...
unlock(item)
(In the kernel the table lock might be RCU.)
Or, with similar data:
write_lock(table);
foreach(item, table)
lock(item)
unlock(item)
/* No items can be locked until we release the write_lock.
...
unlock(table)
You can also easily end up with a 'fubar' we have at work where
someone wrote a C++ condvar class that inherits from mutex.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
