Thread (39 messages) 39 messages, 10 authors, 2020-02-12

Re: RFC: hold i_rwsem until aio completes

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2020-01-15 14:49:52
Also in: linux-fsdevel, linux-mm, linux-xfs, lkml

On Wed, Jan 15, 2020 at 03:33:47PM +0100, Peter Zijlstra wrote:
On Wed, Jan 15, 2020 at 09:24:28AM -0400, Jason Gunthorpe wrote:
quoted
I was interested because you are talking about allowing the read/write side
of a rw sem to be held across a return to user space/etc, which is the
same basic problem.
No it is not; allowing the lock to be held across userspace doesn't
change the owner. This is a crucial difference, PI depends on there
being a distinct owner. That said, allowing the lock to be held across
userspace still breaks PI in that it completely wrecks the ability to
analyze the critical section.
I'm not sure what you are contrasting?

I was remarking that I see many places open code a rwsem using an
atomic and a completion specifically because they need to do the
things Christoph identified:
(1) no unlocking by another process than the one that acquired it
(2) no return to userspace with locks held
As an example flow: obtain the read side lock, schedual a work queue,
return to user space, and unlock the read side from the work queue.

If we can make some general primative that addresses this then maybe
those open coded places can convert as well?

Regards,
Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help