[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170204030842.GL27291@ZenIV.linux.org.uk>
Date: Sat, 4 Feb 2017 03:08:42 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nfs@...r.kernel.org, ceph-devel@...r.kernel.org,
lustre-devel@...ts.lustre.org,
v9fs-developer@...ts.sourceforge.net,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jan Kara <jack@...e.cz>,
Chris Wilson <chris@...is-wilson.co.uk>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Jeff Layton <jlayton@...hat.com>
Subject: Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to
allocate more pages per call
On Thu, Feb 02, 2017 at 09:51:25AM +0000, Al Viro wrote:
> * fuse_copy_fill(). I'm not at all sure that iov_iter_get_pages()
> is a good idea there - fuse_copy_do() could bloody well just use
> copy_{to,from}_iter().
Miklos, could you explain why does lock_request() prohibit page faults until
the matching unlock_request()? All it does is setting FR_LOCKED on
our request and the only thing that even looks at that is fuse_abort_conn(),
which doesn't (AFAICS) wait for anything.
Where does the deadlock come from, and if it's not a deadlock - what is
it? Or is that comment stale since "fuse: simplify request abort"?
Powered by blists - more mailing lists