Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, 2017-02-02 at 09:51 +, Al Viro wrote: > On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > > Small respin of the patch that I sent yesterday for the same thing. > > > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > > end up iterating past the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, 2017-02-02 at 09:51 +, Al Viro wrote: > On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > > Small respin of the patch that I sent yesterday for the same thing. > > > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > > end up iterating past the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 13, 2017 at 1:56 AM, Steve Capper wrote: > > Okay so looking at what we have for access_ok(.) on arm64, my > understanding is that we perform a 65-bit add/compare (in assembler) to > see whether or not the range is below the current_thread_info->addr_limit. >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 13, 2017 at 1:56 AM, Steve Capper wrote: > > Okay so looking at what we have for access_ok(.) on arm64, my > understanding is that we perform a 65-bit add/compare (in assembler) to > see whether or not the range is below the current_thread_info->addr_limit. > So I think this is a

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 11:28:48AM -0800, Linus Torvalds wrote: > On Fri, Feb 3, 2017 at 11:08 AM, Al Viro wrote: > > > > On x86 it does. I don't see anything equivalent in mm/gup.c one, and the > > only kinda-sorta similar thing (access_ok() in __get_user_pages_fast() >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 11:28:48AM -0800, Linus Torvalds wrote: > On Fri, Feb 3, 2017 at 11:08 AM, Al Viro wrote: > > > > On x86 it does. I don't see anything equivalent in mm/gup.c one, and the > > only kinda-sorta similar thing (access_ok() in __get_user_pages_fast() > > there) is vulnerable

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Wed, Feb 8, 2017 at 6:54 AM, Al Viro wrote: > On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote: >> > Another thing: what guarantees that places in writepages-related paths >> > where we store a reference into req->ff won't hit a request with already >> >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Wed, Feb 8, 2017 at 6:54 AM, Al Viro wrote: > On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote: >> > Another thing: what guarantees that places in writepages-related paths >> > where we store a reference into req->ff won't hit a request with already >> > non-NULL ->ff? >> >>

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote: > > Another thing: what guarantees that places in writepages-related paths > > where we store a reference into req->ff won't hit a request with already > > non-NULL ->ff? > > Well, it is set before being sent (queued onto

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote: > > Another thing: what guarantees that places in writepages-related paths > > where we store a reference into req->ff won't hit a request with already > > non-NULL ->ff? > > Well, it is set before being sent (queued onto

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Tue, Feb 07, 2017 at 07:19:09AM +, Al Viro wrote: > Speaking of refcounting - what's going on with fuse_file one? My reading > of that code is that you have 4 states of that thing: > * new (just created, fallback request allocated, use fuse_file_free() > to kill). Refcount is 0. >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Tue, Feb 07, 2017 at 07:19:09AM +, Al Viro wrote: > Speaking of refcounting - what's going on with fuse_file one? My reading > of that code is that you have 4 states of that thing: > * new (just created, fallback request allocated, use fuse_file_free() > to kill). Refcount is 0. >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 06, 2017 at 03:18:42PM +0100, Miklos Szeredi wrote: > But I think it's breakable in the same way: if the deadlocked request > is aborted, the fault will release the page lock as well as mmap_sem, > and from there things will resolve themselves. Right you are - original holder of

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 06, 2017 at 03:18:42PM +0100, Miklos Szeredi wrote: > But I think it's breakable in the same way: if the deadlocked request > is aborted, the fault will release the page lock as well as mmap_sem, > and from there things will resolve themselves. Right you are - original holder of

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 6, 2017 at 10:57 AM, Al Viro wrote: > On Mon, Feb 06, 2017 at 10:08:06AM +0100, Miklos Szeredi wrote: > >> Yes, I think only page lock can be used to deadlock inside >> fuse_dev_read/write(). So requests that don't have locked pages >> should be okay with

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 6, 2017 at 10:57 AM, Al Viro wrote: > On Mon, Feb 06, 2017 at 10:08:06AM +0100, Miklos Szeredi wrote: > >> Yes, I think only page lock can be used to deadlock inside >> fuse_dev_read/write(). So requests that don't have locked pages >> should be okay with just waiting until

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 06, 2017 at 10:08:06AM +0100, Miklos Szeredi wrote: > Yes, I think only page lock can be used to deadlock inside > fuse_dev_read/write(). So requests that don't have locked pages > should be okay with just waiting until copy_to/from_user() finishes > and only then proceeding with

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 06, 2017 at 10:08:06AM +0100, Miklos Szeredi wrote: > Yes, I think only page lock can be used to deadlock inside > fuse_dev_read/write(). So requests that don't have locked pages > should be okay with just waiting until copy_to/from_user() finishes > and only then proceeding with

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 6, 2017 at 4:05 AM, Al Viro wrote: > Some observations regarding the arguments: > * stack footprint is atrocious. Consider e.g. fuse_mknod() - you > get 16 bytes of fuse_mknod_in + 120 bytes of struct fuse_args + 128 bytes > of fuse_entry_out. All

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Mon, Feb 6, 2017 at 4:05 AM, Al Viro wrote: > Some observations regarding the arguments: > * stack footprint is atrocious. Consider e.g. fuse_mknod() - you > get 16 bytes of fuse_mknod_in + 120 bytes of struct fuse_args + 128 bytes > of fuse_entry_out. All on stack, and that's on

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 11:04 PM, Al Viro wrote: > On Sun, Feb 05, 2017 at 10:19:20PM +0100, Miklos Szeredi wrote: > >> Then we can't break out of that deadlock: we wait until >> fuse_dev_do_write() is done until calling request_end() which >> ultimately results in

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 11:04 PM, Al Viro wrote: > On Sun, Feb 05, 2017 at 10:19:20PM +0100, Miklos Szeredi wrote: > >> Then we can't break out of that deadlock: we wait until >> fuse_dev_do_write() is done until calling request_end() which >> ultimately results in unlocking page. But

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 10:04:45PM +, Al Viro wrote: > Sure, you need to hit a fairly narrow window, especially if you are to > cause damage in A, but AFAICS it's not impossible. Consider e.g. the > situation when you lose CPU on preempt on the way to memcpy(); in that > case server might

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 10:04:45PM +, Al Viro wrote: > Sure, you need to hit a fairly narrow window, especially if you are to > cause damage in A, but AFAICS it's not impossible. Consider e.g. the > situation when you lose CPU on preempt on the way to memcpy(); in that > case server might

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 10:19:20PM +0100, Miklos Szeredi wrote: > Then we can't break out of that deadlock: we wait until > fuse_dev_do_write() is done until calling request_end() which > ultimately results in unlocking page. But fuse_dev_do_write() won't > complete until the page is unlocked.

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 10:19:20PM +0100, Miklos Szeredi wrote: > Then we can't break out of that deadlock: we wait until > fuse_dev_do_write() is done until calling request_end() which > ultimately results in unlocking page. But fuse_dev_do_write() won't > complete until the page is unlocked.

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 10:01 PM, Al Viro wrote: > On Sun, Feb 05, 2017 at 09:15:24PM +0100, Miklos Szeredi wrote: > >> That case is fine. But nothing guarantees that fuse_abort_conn() >> won't be called (in the non-deadlock case) when data is being copied >> to the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 10:01 PM, Al Viro wrote: > On Sun, Feb 05, 2017 at 09:15:24PM +0100, Miklos Szeredi wrote: > >> That case is fine. But nothing guarantees that fuse_abort_conn() >> won't be called (in the non-deadlock case) when data is being copied >> to the request args. Ending the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 09:15:24PM +0100, Miklos Szeredi wrote: > That case is fine. But nothing guarantees that fuse_abort_conn() > won't be called (in the non-deadlock case) when data is being copied > to the request args. Ending the request at such a point could easily > lead to use after

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 09:15:24PM +0100, Miklos Szeredi wrote: > That case is fine. But nothing guarantees that fuse_abort_conn() > won't be called (in the non-deadlock case) when data is being copied > to the request args. Ending the request at such a point could easily > lead to use after

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 01:51:49AM +, Al Viro wrote: > IDGI. Your request is marked aborted and should presumably fail, so > that when request_wait_answer() wakes up and finds it screwed, fuse_readpage() > would just return an error and filemap_fault() will return VM_FAULT_SIGBUS, > with

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 05, 2017 at 01:51:49AM +, Al Viro wrote: > IDGI. Your request is marked aborted and should presumably fail, so > that when request_wait_answer() wakes up and finds it screwed, fuse_readpage() > would just return an error and filemap_fault() will return VM_FAULT_SIGBUS, > with

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 2:51 AM, Al Viro wrote: > On Sat, Feb 04, 2017 at 11:11:27PM +0100, Miklos Szeredi wrote: > >> Well, it's not historical; at least not yet. The deadlock is there >> alright: mmap fuse file to addr; read byte from mapped page -> page >> locked; this

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sun, Feb 5, 2017 at 2:51 AM, Al Viro wrote: > On Sat, Feb 04, 2017 at 11:11:27PM +0100, Miklos Szeredi wrote: > >> Well, it's not historical; at least not yet. The deadlock is there >> alright: mmap fuse file to addr; read byte from mapped page -> page >> locked; this triggeres read request

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 04, 2017 at 11:11:27PM +0100, Miklos Szeredi wrote: > Well, it's not historical; at least not yet. The deadlock is there > alright: mmap fuse file to addr; read byte from mapped page -> page > locked; this triggeres read request served in same process but > separate thread; write

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 04, 2017 at 11:11:27PM +0100, Miklos Szeredi wrote: > Well, it's not historical; at least not yet. The deadlock is there > alright: mmap fuse file to addr; read byte from mapped page -> page > locked; this triggeres read request served in same process but > separate thread; write

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 4, 2017 at 8:26 PM, Al Viro wrote: > On Sat, Feb 04, 2017 at 03:08:42AM +, Al Viro wrote: > What am I missing here? Looks like those checks in fuse_copy_page() are > dead code... They had been there since the initial merge, but AFAICS > they were just

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 4, 2017 at 8:26 PM, Al Viro wrote: > On Sat, Feb 04, 2017 at 03:08:42AM +, Al Viro wrote: > What am I missing here? Looks like those checks in fuse_copy_page() are > dead code... They had been there since the initial merge, but AFAICS > they were just as useless in 2.6.14.

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 4, 2017 at 4:08 AM, Al Viro wrote: > On Thu, Feb 02, 2017 at 09:51:25AM +, 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 >>

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 4, 2017 at 4:08 AM, Al Viro wrote: > On Thu, Feb 02, 2017 at 09:51:25AM +, 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

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 04, 2017 at 03:08:42AM +, Al Viro wrote: > On Thu, Feb 02, 2017 at 09:51:25AM +, 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(). > >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Sat, Feb 04, 2017 at 03:08:42AM +, Al Viro wrote: > On Thu, Feb 02, 2017 at 09:51:25AM +, 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(). > >

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 +, 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

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 +, 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

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 3, 2017 at 11:08 AM, Al Viro wrote: > > On x86 it does. I don't see anything equivalent in mm/gup.c one, and the > only kinda-sorta similar thing (access_ok() in __get_user_pages_fast() > there) is vulnerable to e.g. access via kernel_write(). Yeah,

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 3, 2017 at 11:08 AM, Al Viro wrote: > > On x86 it does. I don't see anything equivalent in mm/gup.c one, and the > only kinda-sorta similar thing (access_ok() in __get_user_pages_fast() > there) is vulnerable to e.g. access via kernel_write(). Yeah, access_ok() is bogus. It needs to

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 10:29:23AM -0800, Linus Torvalds wrote: > On Thu, Feb 2, 2017 at 11:29 PM, Al Viro wrote: > > > > get_user_pages() relies upon find_extend_vma() to reject kernel > > addresses; the fast side of get_user_pages_fast() doesn't have anything > > of

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 10:29:23AM -0800, Linus Torvalds wrote: > On Thu, Feb 2, 2017 at 11:29 PM, Al Viro wrote: > > > > get_user_pages() relies upon find_extend_vma() to reject kernel > > addresses; the fast side of get_user_pages_fast() doesn't have anything > > of that sort > > It is

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 2, 2017 at 11:29 PM, Al Viro wrote: > > get_user_pages() relies upon find_extend_vma() to reject kernel > addresses; the fast side of get_user_pages_fast() doesn't have anything > of that sort It is *supposed* to have it. See pte_allows_gup(), for example.

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 2, 2017 at 11:29 PM, Al Viro wrote: > > get_user_pages() relies upon find_extend_vma() to reject kernel > addresses; the fast side of get_user_pages_fast() doesn't have anything > of that sort It is *supposed* to have it. See pte_allows_gup(), for example. In particular, it requires

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu 02-02-17 18:28:02, Al Viro wrote: > On Thu, Feb 02, 2017 at 03:48:17PM +0100, Jan Kara wrote: > > > > * ->page_mkwrite() instances sometimes return VM_FAULT_RETRY; AFAICS, > > > it's only (ab)used there as 'not zero, but doesn't contain any error > > > bits'; > > > VM_FAULT_RETRY from

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu 02-02-17 18:28:02, Al Viro wrote: > On Thu, Feb 02, 2017 at 03:48:17PM +0100, Jan Kara wrote: > > > > * ->page_mkwrite() instances sometimes return VM_FAULT_RETRY; AFAICS, > > > it's only (ab)used there as 'not zero, but doesn't contain any error > > > bits'; > > > VM_FAULT_RETRY from

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 08:54:15AM +, Al Viro wrote: > Hmm... Reuse part is really nasty ;-/ OTOH, it might make sense to have > a "fill bio_vec array" as separate primitive - having that sucker come > from bio looks like an artificial restriction. Or just the only usecase :) But yes, it

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Fri, Feb 03, 2017 at 08:54:15AM +, Al Viro wrote: > Hmm... Reuse part is really nasty ;-/ OTOH, it might make sense to have > a "fill bio_vec array" as separate primitive - having that sucker come > from bio looks like an artificial restriction. Or just the only usecase :) But yes, it

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 11:49:01PM -0800, Christoph Hellwig wrote: > On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > > Yeah, that might work. You could kmalloc the buffer array according to > > the maxsize value. For small ones we could even consider using an on- > > stack buffer. >

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 11:49:01PM -0800, Christoph Hellwig wrote: > On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > > Yeah, that might work. You could kmalloc the buffer array according to > > the maxsize value. For small ones we could even consider using an on- > > stack buffer. >

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 08:00:52AM -0500, Jeff Layton wrote: > Yeah, that might work. You could kmalloc the buffer array according to > the maxsize value. For small ones we could even consider using an on- > stack buffer. For the block direct I/O code we defintively want to avoid any allocations

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 08:00:52AM -0500, Jeff Layton wrote: > Yeah, that might work. You could kmalloc the buffer array according to > the maxsize value. For small ones we could even consider using an on- > stack buffer. For the block direct I/O code we defintively want to avoid any allocations

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 08:00:52AM -0500, Jeff Layton wrote: > > I'm not sure we need to touch any get_user_pages_fast() at all; let it > > fill a medium-sized array and use that as a buffer. In particular, > > I *really* don't like the idea of having the callbacks done in an > > inconsistent

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 08:00:52AM -0500, Jeff Layton wrote: > > I'm not sure we need to touch any get_user_pages_fast() at all; let it > > fill a medium-sized array and use that as a buffer. In particular, > > I *really* don't like the idea of having the callbacks done in an > > inconsistent

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 03:48:17PM +0100, Jan Kara wrote: > > * ->page_mkwrite() instances sometimes return VM_FAULT_RETRY; AFAICS, > > it's only (ab)used there as 'not zero, but doesn't contain any error bits'; > > VM_FAULT_RETRY from that source does *not* reach handle_mm_fault() callers, >

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 03:48:17PM +0100, Jan Kara wrote: > > * ->page_mkwrite() instances sometimes return VM_FAULT_RETRY; AFAICS, > > it's only (ab)used there as 'not zero, but doesn't contain any error bits'; > > VM_FAULT_RETRY from that source does *not* reach handle_mm_fault() callers, >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu 02-02-17 09:51:25, Al Viro wrote: > I'm massaging that code (along with a lot of RTFS); the interesting questions > related to VM side of things are > * what are the relative costs of doing small vs. large batches? Some > of get_user_pages_fast() instances have comments along the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu 02-02-17 09:51:25, Al Viro wrote: > I'm massaging that code (along with a lot of RTFS); the interesting questions > related to VM side of things are > * what are the relative costs of doing small vs. large batches? Some > of get_user_pages_fast() instances have comments along the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, 2017-02-02 at 11:16 +, Al Viro wrote: > On Thu, Feb 02, 2017 at 02:56:51AM -0800, Christoph Hellwig wrote: > > > I really wonder if this is the right approach. Most of the users of > > > iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want > > > something like > > >

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, 2017-02-02 at 11:16 +, Al Viro wrote: > On Thu, Feb 02, 2017 at 02:56:51AM -0800, Christoph Hellwig wrote: > > > I really wonder if this is the right approach. Most of the users of > > > iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want > > > something like > > >

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 02:56:51AM -0800, Christoph Hellwig wrote: > > I really wonder if this is the right approach. Most of the users of > > iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want > > something like > > iov_iter_for_each_page(iter, size, f, data) > > with int

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 02:56:51AM -0800, Christoph Hellwig wrote: > > I really wonder if this is the right approach. Most of the users of > > iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want > > something like > > iov_iter_for_each_page(iter, size, f, data) > > with int

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 +, Al Viro wrote: > On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > > Small respin of the patch that I sent yesterday for the same thing. > > > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > > end up iterating

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 +, Al Viro wrote: > On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > > Small respin of the patch that I sent yesterday for the same thing. > > > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > > end up iterating

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > Small respin of the patch that I sent yesterday for the same thing. > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > end up iterating past the max size we'll use anyway when trying to > determine the

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > Small respin of the patch that I sent yesterday for the same thing. > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > end up iterating past the max size we'll use anyway when trying to > determine the

[PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

Small respin of the patch that I sent yesterday for the same thing. This moves the maxsize handling into iov_iter_pvec_size, so that we don't end up iterating past the max size we'll use anyway when trying to determine the pagevec length. Also, a respun patch to make ceph use

[PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

Small respin of the patch that I sent yesterday for the same thing. This moves the maxsize handling into iov_iter_pvec_size, so that we don't end up iterating past the max size we'll use anyway when trying to determine the pagevec length. Also, a respun patch to make ceph use