linux-kernel - Re: [PATCH 0/2] convert mmap_sem to a scalable rw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 May 2007 10:50:45 +0200 (CEST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Eric Dumazet <dada1@...mosbay.com>
cc:	Esben Nielsen <nielsen.esben@...glemail.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...sign.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: [PATCH 0/2] convert mmap_sem to a scalable rw_mutex



On Sat, 12 May 2007, Eric Dumazet wrote:

> Esben Nielsen a écrit :
>>
>>
>>  On Sat, 12 May 2007, Peter Zijlstra wrote:
>> 
>> >  On Sat, 2007-05-12 at 11:27 +0200, Esben Nielsen wrote:
>> > > 
>> > >  On Fri, 11 May 2007, Peter Zijlstra wrote:
>> > > 
>> > > > 
>> > > >  I was toying with a scalable rw_mutex and found that it gives ~10% 
>> > > >  reduction in
>> > > >  system time on ebizzy runs (without the MADV_FREE patch).
>> > > > 
>> > > 
>> > >  You break priority enheritance on user space futexes! :-(
>> > >  The problems is that the futex waiter have to take the mmap_sem. And 
>> > >  as
>> > >  your rw_mutex isn't PI enabled you get priority inversions :-(
>> > 
>> >  Do note that rwsems have no PI either.
>> >  PI is not a concern for mainline - yet, I do have ideas here though.
>> > 
>> >
>>  If PI wasn't a concern for mainline, why is PI futexes merged into the
>>  mainline?
>
> If you really care about futexes and mmap_sem, just use private futexes, 
> since they dont use mmap_sem at all.
>

futex_wait_pi() takes mmap_sem. So does futex_fd(). I can't see a code 
path into the PI futexes which doesn't use mmap_sem.

There is another way to avoid problems with mmap_sem:
Use shared memory for data you need to share with high priority tasks and
normal low priority tasks there. The high priority task(s) run(s) in 
an isolated high priority process having its own mmap_sem. This high 
priority process is mlock'ed and doesn't do any operations write locking 
mmap_sem.

But it would be nice if you can avoid such a cumbersome workaround...

Esben