linux-kernel - Re: [PATCH 11/12] rwsem: wake all readers when first waiter is a reader

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:	Wed, 13 Mar 2013 04:03:40 -0700
From:	Michel Lespinasse <walken@...gle.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Alex Shi <alex.shi@...el.com>, Ingo Molnar <mingo@...nel.org>,
	David Howells <dhowells@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/12] rwsem: wake all readers when first waiter is a reader

On Tue, Mar 12, 2013 at 8:23 PM, Dave Chinner <david@...morbit.com> wrote:
> On Mon, Mar 11, 2013 at 11:43:34PM -0700, Michel Lespinasse wrote:
>> I find the name 'barrier' actually confusing when used to describe
>> synchronous operations.  To me a barrier is usualy between
>> asynchronous operations, and it is well defined which operations
>> are ahead or behind of the barrier (either because they were
>> queued by the same thread, or they were queued by different
>> threads which may have synchronized together some other way).
>
> When you have hundreds or thousands of threads doing IO to the one
> file, it doesn't matter if the IO is issued synchronously or
> asynchronously by the threads - you simply have a huge amount of
> data IO concurrency and very, very deep pipelines.
>
> Inserting a metadata modification (truncate, preallocation,
> holepunch, etc) into that pipeline currently causes all new
> submissions to queue behind the metadata modification, waits for
> everything submitted before the metadata modification to complete
> and then runs the metadata modification. Once it completes, it then
> allows everything queued up to the next metadata modification to
> run....
>
> That matches your definition of a barrier pretty well, I think.

The difference I see is that with async operations one can easily tell
when the desired operations made it into the queue:

t1()
async_submit(request X)
t2()
..
..
..
(eventually) request X completes

After t2 we know the operation is queued, and thus we can legitimately
expect that new operations submitted after t2 should logically run
after request X.


With sync operations we can't make that observation as the caller
thread is blocked:

t1()
begin system call
..
..
request X gets queued
..
..
request X completes
..
..
system call completes
t2()

Userspace can't pinpoint exactly when did the request get onto the queue.

If another request Y gets submitted between t1 and t2, userspace can
never know for sure if Y was before of after X in the queue, so the
proposed reordering should be (my claim) not observable by userspace,
in the sense that it never produces a result that wasn't already
possible before.




Anyway, I didn't intend for the proposed change to warrant a thread of
this size. I will abandon patch 10 and propose a different (slightly
longer, but without reordering) change to replace patch 11.

Thanks,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/