lkml.org 
[lkml]   [2021]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 00/13] [RFC] Rust support
    Date
    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, &current->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)

    \
     
     \ /
      Last update: 2021-04-17 14:41    [W:3.700 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site