Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-07 Thread Jan Kara
On Wed 06-05-20 21:38:40, Souptick Joarder wrote: > On Wed, May 6, 2020 at 6:29 PM Jan Kara wrote: > > > > On Wed 06-05-20 17:51:39, Souptick Joarder wrote: > > > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote: > > > > > > > > On Wed 06-05-20 02

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-06 Thread Jan Kara
On Wed 06-05-20 17:51:39, Souptick Joarder wrote: > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote: > > > > On Wed 06-05-20 02:06:56, Souptick Joarder wrote: > > > On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote: > > > > > > > > On 2020-05-05 12

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-06 Thread Jan Kara
e behavior of < 0 return on error or > 0 return if we mapped some pages. Callers that can possibly ask to map 0 pages can get 0 pages back - kind of expected - and I don't see any benefit in trying to rewrite these callers to handle -EINVAL instead...

Re: [RFC] errno.h: Provide EFSCORRUPTED for everybody

2019-10-31 Thread Jan Kara
ntly 6 filesystems that have the same #define. Move it > into errno.h so it's defined in just one place. > > Signed-off-by: Valdis Kletnieks Looks good to me. You can add: Reviewed-by: Jan Kara Honza > --- > drivers/stag

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-09 Thread Jan Kara
, rdma, ext4, and xfs. MM tree would be one candidate for routing but there are other options that would make sense as well - Dan's tree, VFS tree, or even I can pickup the patches to my tree if needed. But let's worry about the routing after we have working and reviewed patches...

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-09 Thread Jan Kara
t; pretty bad... So Thanks Jan... ;-) For your function, I'd choose a name like vaddr_pin_leased_pages() so that association with a lease is clear from the name :) Also I'd choose the counterpart to be vaddr_unpin_leased_page[s](). Especially having put_page in the name looks confusing to me... Honza -- Jan Kara SUSE Labs, CR ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-07 Thread Jan Kara
On Fri 02-08-19 12:14:09, John Hubbard wrote: > On 8/2/19 7:52 AM, Jan Kara wrote: > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote: > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote: > > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote: > > >

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-02 Thread Jan Kara
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote: > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote: > > On Fri 02-08-19 11:12:44, Michal Hocko wrote: > > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote: > > > [...] > > > > 2) Convert a

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-02 Thread Jan Kara
put_page()) but I suppose it would be a high enough barrier for missed conversions... Thoughts? Honza -- Jan Kara SUSE Labs, CR ___ devel mailing list de...@linuxdriverproject.org http:

Re: [PATCH v5 12/24] erofs: introduce tagged pointer

2019-07-31 Thread Jan Kara
ptr = (_ptptr); \ > + const typeof(_tags) tags = (_tags); \ > + if (__builtin_constant_p(tags) && (tags & ~__tagptr_mask(*ptptr))) \ > + __bad_tagptr_tags(); \ > + ptptr->v |= tags; \ > +*ptptr; }) > + > +#define tagptr_clear_tags(

Re: [PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

2017-07-31 Thread Jan Kara
hose filesystems this is a straightforward conversion from calling > filemap_write_and_wait_range in their fsync operation to calling > file_write_and_wait_range. > > Signed-off-by: Jeff Layton <jlay...@redhat.com> This all looks rather

Re: [lustre-devel] [PATCH 030/124] staging: lustre: llite: Replace write mutex with range lock

2016-09-19 Thread Jan Kara
e threads writing a single shared > >> + * file given each thread is writing to a non-overlapping portion of the > >> + * file. > >> + * > >> + * Refer to the possible upstream kernel version of range lock by > >> + * Jan Kara <j...@suse.cz>: https://lkml.org