lkml.org 
[lkml]   [2018]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: write_lock_irq(&tasklist_lock)
> Yeah, lemme put some details here:
>
> So we have three cases:
>
> Case #1 (from Will)
>
> P0: P1: P2:
>
> spin_lock(&slock) read_lock(&rwlock)
> write_lock(&rwlock)
> read_lock(&rwlock) spin_lock(&slock)
>
> , which is a deadlock, and couldn't not be detected by lockdep yet. And
> lockdep could detect this with the patch I attach at the end of the
> mail.
>
> Case #2
>
> P0: P1: P2:
>
> <in irq handler>
> spin_lock(&slock) read_lock(&rwlock)
> write_lock(&rwlock)
> read_lock(&rwlock) spin_lock_irq(&slock)
>
> , which is not a deadlock, as the read_lock() on P0 can use the unfair
> fastpass.
>
> Case #3
>
> P0: P1: P2:
>
> <in irq handler>
> spin_lock_irq(&slock) read_lock(&rwlock)
> write_lock_irq(&rwlock)
> read_lock(&rwlock) spin_lock(&slock)
>
> , which is a deadlock, as the read_lock() on P0 cannot use the fastpass.

Mmh, I'm starting to think that, maybe, we need a model (a tool) to
distinguish these and other(?) cases (sorry, I could not resist ;-)

[...]


> ------------------->8
> Subject: [PATCH] locking: More accurate annotations for read_lock()
>
> On the archs using QUEUED_RWLOCKS, read_lock() is not always a recursive
> read lock, actually it's only recursive if in_interrupt() is true. So

Mmh, taking the "common denominator" over archs/Kconfig options and
CPU states, this would suggest that read_lock() is non-recursive;

it looks like I can say "good-bye" to my idea to define (formalize)
consistent executions/the memory ordering of RW-LOCKS "by following"
the following _emulation_:

void read_lock(rwlock_t *s)
{
r0 = atomic_fetch_inc_acquire(&s->val);
}

void read_unlock(rwlock_t *s)
{
r0 = atomic_fetch_sub_release(&s->val);
}

void write_lock(rwlock_t *s)
{
r0 = atomic_cmpxchg_acquire(&s->val, 0, -1);
}

void write_unlock(rwlock_t *s)
{
atomic_set_release(&s->val, 0);
}

filter (~read_lock:r0=-1 /\ write_lock:r0=0)

[...]


> The code is done, I'm just working on the rework for documention stuff,
> so if anyone is interested, could try it out ;-)

Any idea on how to "educate" the LKMM about this code/documentation?

Andrea

\
 
 \ /
  Last update: 2018-05-24 23:14    [W:0.089 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site