Re: [PATCH 4/4] mm: use the cached page for filemap_fault

2018-12-07 Thread Jan Kara
> difference do you want me to drop this? Thanks, If there's no difference, I'd like to drop this as well. It just complicates the fault state handling which is already complex enough. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 3/4] filemap: drop the mmap_sem for all blocking operations

2018-12-07 Thread Jan Kara
econd time we get to filemap_fault(), we will not have FAULT_FLAG_ALLOW_RETRY set and thus do blocking locking. So I think your code needs to catch common cases you observe in practice but not those super-rare corner cases... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 2/4] filemap: kill page_cache_read usage in filemap_fault

2018-12-07 Thread Jan Kara
On Fri 07-12-18 10:57:50, Jan Kara wrote: > On Fri 30-11-18 14:58:10, Josef Bacik wrote: > > If we do not have a page at filemap_fault time we'll do this weird > > forced page_cache_read thing to populate the page, and then drop it > > again and loop around and find it. Thi

Re: [PATCH 2/4] filemap: kill page_cache_read usage in filemap_fault

2018-12-07 Thread Jan Kara
lock again the page... And you can still delete all the code you've deleted. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] fanotify: Make sure to check event_len when copying

2018-12-05 Thread Jan Kara
har > > __user *buf, > > continue; > > } > > > > - ret = copy_event_to_user(group, kevent, buf); > > + ret = copy_event_to_user(group, kevent, buf, count); > > if (unlikely(ret == -EOPENSTALE)) { > > /* > > * We cannot report events with stale fd so drop it. > > -- > > 2.17.1 > > > > > > -- > > Kees Cook -- Jan Kara SUSE Labs, CR

Re: [PATCH] fanotify: Make sure to check event_len when copying

2018-12-05 Thread Jan Kara
if (unlikely(ret == -EOPENSTALE)) { > /* >* We cannot report events with stale fd so drop it. > -- > 2.17.1 > > > -- > Kees Cook -- Jan Kara SUSE Labs, CR

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

2018-12-05 Thread Jan Kara
till applies), and the > dma_pinned_count. So single page bit could help you with performance. In 99% of cases there's just one reference from GUP. So if you could store that info in page flags, you could safe yourself a relatively expensive removal from LRU and putting it back to make space in struct page for proper refcount. But since you report that the performance isn't that horrible, I'd leave this idea on a backburner. We can always implement it later in case we find in future we need to improve the performance. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH RFC 12/15] inotify: replace **** with a hug

2018-12-05 Thread Jan Kara
sn't shaming conflict with the CoC? > Just remove this sentence - it adds no valuable information. > While at it, please fix grammar "a mark". Agreed, just send a patch to remove that sentence and fixup the article. Btw, for the fun of it Eric has added this comment himself so I don't think this would really qualify as a CoC violation ;) Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH V2] namei: free new_dentry late

2018-11-27 Thread Jan Kara
On Tue 27-11-18 17:57:12, PanBian wrote: > On Tue, Nov 27, 2018 at 10:25:51AM +0100, Jan Kara wrote: > > On Sun 25-11-18 08:15:23, Pan Bian wrote: > > > After calling dput(new_dentry), new_dentry is passed to fsnotify_move. > > > This may result in a use-after-free bu

Re: [PATCH] ext4: clean up indentation issues, remove extraneous tabs

2018-11-27 Thread Jan Kara
On Fri 23-11-18 16:30:43, Colin King wrote: > From: Colin Ian King > > There are several lines that are indented too far, clean these > up by removing the tabs. > > Signed-off-by: Colin Ian King The patch looks good. You can add: Rev

Re: [PATCH V2] namei: free new_dentry late

2018-11-27 Thread Jan Kara
new_is_dir, NULL, new_dentry); > } > } > + dput(new_dentry); > release_dentry_name_snapshot(_name); > > return error; > -- > 2.7.4 > > -- Jan Kara SUSE Labs, CR

Re: [PATCH] ext2: fix potential use after free

2018-11-27 Thread Jan Kara
; > if (!(bh && header == HDR(bh))) > kfree(header); > + brelse(bh); > up_write(_I(inode)->xattr_sem); > > return error; > -- > 2.7.4 > > -- Jan Kara SUSE Labs, CR

Re: [PATCH] ext4: fix possible use after free in ext4_quota_enable

2018-11-27 Thread Jan Kara
n Bian > Fixes: daf647d2dd5("ext4: add lockdep annotations for i_data_sem") Thanks for the fix! The patch looks good. You can add: Reviewed-by: Jan Kara Honza > --- > fs/ext4/super.c | 2 +- > 1 file changed, 1 insert

Re: [PATCH] jbd2: clean up indentation issue, replace spaces with tab

2018-11-26 Thread Jan Kara
On Fri 23-11-18 16:40:53, Colin King wrote: > From: Colin Ian King > > There is a statement that is indented with spaces, replace it with > a tab. > > Signed-off-by: Colin Ian King Looks good. You can add: Rev

Re: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps

2018-11-20 Thread Jan Kara
internface. While this has been worked on and it will be fixed properly, > it seems that our wording could see some refinement and be more vocal > about semantic aspect of these flags as well. > > Cc: Jan Kara > Cc: Dan Williams > Cc: David Rientjes > Signed-off-by:

Re: [PATCH] udf: fix dvd mounting error

2018-11-19 Thread Jan Kara
On Fri 16-11-18 14:33:14, Sudip Mukherjee wrote: > > From e1a7680b960fe25821f2419b4c0b1215f8ab2f9b Mon Sep 17 00:00:00 2001 > > From: Jan Kara > > Date: Fri, 16 Nov 2018 13:43:17 +0100 > > Subject: [PATCH] udf: Allow mounting volumes with incorrect identification >

Re: [PATCH] udf: fix dvd mounting error

2018-11-16 Thread Jan Kara
pr_err("incorrect dstring lengths (%d/%d)\n", > - s_len, i_len); > - return -EINVAL; > - } > - } > > return udf_name_from_CS0(sb, utf_o, o_len, ocu_i, s_len, 0); > } > -- &

Re: [Ksummit-discuss] [RFC PATCH 3/3] libnvdimm, MAINTAINERS: Subsystem Profile

2018-11-16 Thread Jan Kara
t creates unneeded negative feelings to those who wanted to be in > > > > this list, but for any reason they don't. Those reviewers will feel > > > > "untrusted". > > > > > > Yeah, perhaps something like "most active reviewers" would sound > > > better. > > > > I would recommend to remove this section at all. > > New maintainers won't come out of blue, but will be come > > from existing community and such individuals for sure will see > > and judge by themselves to whom they trust and to whom not. > > I see your point, but, on the other hand, having a list with the ones > that are actively doing reviews helps newcomers. How exactly? Do you expect people to CC patches to these directly? And if yes, why is not picking patches from the mailing list good enough? Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v2 6/6] mm: track gup pages with page->dma_pinned_* fields

2018-11-12 Thread Jan Kara
gt; > Cc: Matthew Wilcox > Cc: Michal Hocko > Cc: Christopher Lameter > Cc: Jason Gunthorpe > Cc: Dan Williams > Cc: Jan Kara > Signed-off-by: John Hubbard > --- > include/linux/mm.h | 19 +-- > mm/gup.c | 55

Re: [PATCH] mm: cleancache: fix corruption on missed inode invalidation

2018-11-12 Thread Jan Kara
On Mon 12-11-18 14:40:06, Andrey Ryabinin wrote: > > > On 11/12/18 2:31 PM, Jan Kara wrote: > > On Mon 12-11-18 12:57:34, Pavel Tikhomirov wrote: > >> If all pages are deleted from the mapping by memory reclaim and also > >> moved to the cleancache: &

Re: [PATCH] mm: cleancache: fix corruption on missed inode invalidation

2018-11-12 Thread Jan Kara
dy ready for > nrpages == 0 && nrexceptional == 0 case and just invalidates inode. > > Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache") > To: Andrew Morton > Cc: Johannes Weiner > Cc: Mel Gorman > Cc: Jan Kara > Cc: Matth

Re: [PATCH 6/7] ext4: lost brelse in ext4_xattr_move_to_block()

2018-11-07 Thread Jan Kara
On Wed 31-10-18 22:13:00, Vasily Averin wrote: > Fixes 3f2571c1f91f ("ext4: factor out xattr moving") > cc: Jan Kara > however issue was present in original ext4_expand_extra_isize_ea() > Fixes 6dd4ee7cab7e ("ext4: Expand extra_inodes space per ...") # 2.6.23 &g

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

2018-11-06 Thread Jan Kara
On Tue 06-11-18 13:47:15, Dave Chinner wrote: > On Mon, Nov 05, 2018 at 04:26:04PM -0800, John Hubbard wrote: > > On 11/5/18 1:54 AM, Jan Kara wrote: > > > Hmm, have you tried larger buffer sizes? Because synchronous 8k IO isn't > > > going to max-out NVME iops by far

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

2018-11-05 Thread Jan Kara
return 1; > } > char *filename = argv[1]; > unsigned iterations = strtoul(argv[2], 0, 0); > > /* Not using O_SYNC for now, anyway. */ > int fd = open(filename, O_DIRECT | O_RDWR); > if (fd < 0) { > printf("Failed to open %s: %m\n", filename); > return 2; > } > > printf("File: %s, data size: %u, interations: %u\n", > filename, FULL_DATA_SIZE, iterations); > > for (int count = 0; count < iterations; count++) { > read_and_write(fd, FULL_DATA_SIZE, buf); > } > > close(fd); > return 0; > } > > > thanks, > -- > John Hubbard > NVIDIA -- Jan Kara SUSE Labs, CR

Re: [PATCH] mm: fix uninitialized variable warnings

2018-11-05 Thread Jan Kara
s change the code like struct dirty_throttle_control * const mdtc = _stor; And then replace checks for !mtdc in the function to !mdtc_valid(mdtc)? That is the same thing as currently and it should make it obvious to the compiler as well as human what is going on... Tejun? Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-11-05 Thread Jan Kara
On Sun 04-11-18 23:17:58, John Hubbard wrote: > On 10/22/18 12:43 PM, Jason Gunthorpe wrote: > > On Thu, Oct 11, 2018 at 06:23:24PM -0700, John Hubbard wrote: > >> On 10/11/18 6:20 AM, Jason Gunthorpe wrote: > >>> On Thu, Oct 11, 2018 at 10

Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-25 Thread Jan Kara
l would matter (correct me if I'm wrong here). So I'd rather see these tables and associated functions in some C file. > +static inline unsigned char fs_dtype(int filetype) This function name is not very descriptive and consistent with the other two. It should be like fs_ftype_to_dtype(), right? > +{ > + if (filetype >= FT_MAX) > + return DT_UNKNOWN; > + > + return fs_dtype_by_ftype[filetype]; > +} Otherwise the patch looks good to me. Honza -- Jan Kara SUSE Labs, CR

Re: [RFC][PATCH 00/11] common implementation of dirent file types

2018-10-25 Thread Jan Kara
ook at the patches which is a good sign ;) and if patches are reviewed by respective fs maintainers. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-18 Thread Jan Kara
On Thu 11-10-18 20:53:34, John Hubbard wrote: > On 10/11/18 6:23 PM, John Hubbard wrote: > > On 10/11/18 6:20 AM, Jason Gunthorpe wrote: > >> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote: > >> > >>>> This is a real worry. If s

Re: statx(2) API and documentation

2018-10-18 Thread Jan Kara
s is how we plan to solve it: > https://github.com/amir73il/linux/commit/8c2b1acadb88ee4505ccc8bfdc665863111fb4cc Yeah, after fanotify experience I find foo_ALL constants useless if not dangerous for userspace. Kernel internal constants like this are IMO useful. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count

2018-10-16 Thread Jan Kara
gt; > get_user_pages(), > > unceremoniously rips the pages out of the LRU, as a prerequisite to using > > either of the page->dma_pinned_* fields. > > How is that safe? If you've ripped the page out of the LRU, it's no > longer being tracked by the page cache aging and reclaim algorithms. > Patch 6 doesn't appear to put these pages back in the LRU, either, > so it looks to me like this just dumps them on the ground after the > gup reference is dropped. How do we reclaim these page cache pages > when there is memory pressure if they aren't in the LRU? Yeah, that's a bug in patch 6/6 (possibly in ClearPageDmaPinned). It should return the page to the LRU from put_user_page(). Honza -- Jan Kara SUSE Labs, CR

Re: INFO: task hung in fanotify_handle_event

2018-10-15 Thread Jan Kara
Hi Dmirty! On Mon 15-10-18 14:29:14, Dmitry Vyukov wrote: > On Mon, Oct 15, 2018 at 2:15 PM, Jan Kara wrote: > > Hello, > > > > On Mon 15-10-18 04:32:02, syzbot wrote: > >> syzbot found the following crash on: > >> > >> HEAD commit:90ad18418c2

Re: INFO: task hung in fanotify_handle_event

2018-10-15 Thread Jan Kara
lags.h:57 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches -- Jan Kara SUSE Labs, CR

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-11 Thread Jan Kara
inimum for given user pin count which would be able to catch some issues but it won't be 100% reliable. So at this point I'm more leaning towards making get_user_pages() return a different type than just struct page * to make it much harder for refcount to go wrong... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-11 Thread Jan Kara
On Wed 10-10-18 16:23:35, John Hubbard wrote: > On 10/10/18 1:59 AM, Jan Kara wrote: > > On Tue 09-10-18 17:42:09, John Hubbard wrote: > >> On 10/8/18 5:14 PM, Andrew Morton wrote: > >>> Also, maintainability. What happens if someone now uses put_page() by > &

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-10 Thread Jan Kara
So this way we could maintain reasonable confidence that refcounts didn't get mixed up. Thoughts? Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v5 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-10 Thread Jan Kara
ser_page(pages[index]); > +} > +EXPORT_SYMBOL(put_user_pages); > + > /* > * get_kernel_pages() - pin kernel pages in memory > * @kiov:An array of struct kvec structures > -- > 2.19.1 > -- Jan Kara SUSE Labs, CR

Re: [PATCH v4 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-09 Thread Jan Kara
have to propagate this different type e.g. through the IO path so that IO completion routines could properly call put_user_pages(). So I'm not sure it's really worth it. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v3 3/3] infiniband/mm: convert put_page() to put_user_page*()

2018-10-08 Thread Jan Kara
gt; CC: Doug Ledford > CC: Jason Gunthorpe > CC: Mike Marciniszyn > CC: Dennis Dalessandro > CC: Christian Benvenuti > > CC: linux-r...@vger.kernel.org > CC: linux-kernel@vger.kernel.org > CC: linux...@kvack.org > Signed-off-by: John Hubbard Looks good to me. You can

Re: [PATCH v3 2/3] mm: introduce put_user_page*(), placeholder versions

2018-10-08 Thread Jan Kara
.cz > Follow-up discussions. > > CC: Matthew Wilcox > CC: Michal Hocko > CC: Christopher Lameter > CC: Jason Gunthorpe > CC: Dan Williams > CC: Jan Kara > CC: Al Viro > CC: Jerome Glisse > CC: Christoph Hellwig > CC: Ralph Campbell > Signed-of

Re: KASAN: use-after-free Write in jbd2_log_do_checkpoint

2018-10-04 Thread Jan Kara
I'll send a fix. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v9 5/5] lib/dlock-list: Scale dlock_lists_empty()

2018-10-04 Thread Jan Kara
gt; spin_unlock(>lock); > @@ -212,6 +250,15 @@ void dlock_lists_del(struct dlock_list_node *node) > spin_lock(>lock); > if (likely(head == READ_ONCE(node->head))) { > list_del_init(>list); > + > + if (unlikely(list_empty(>list))) { > + struct dlock_list_heads *dlist; > + dlist = node->head->dlist; > + > + atomic_dec(>used_lists); > + smp_mb__after_atomic(); > + } > + > WRITE_ONCE(node->head, NULL); > retry = false; > } else { > -- > 1.8.3.1 > > -- Jan Kara SUSE Labs, CR

Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call

2018-10-03 Thread Jan Kara
furthermore it makes the code author think more whether he needs set_page_dirty() or set_page_dirty_lock(), rather than just passing 'true' and hoping the function magically does the right thing for him. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 2/4] mm: introduce put_user_page(), placeholder version

2018-10-03 Thread Jan Kara
his put_user_pages() for symmetry with put_user_page()? I don't really care too much but it would look natural to me. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps

2018-10-03 Thread Jan Kara
AX is new and it was never really used with RDMA and stuff. > > I'm also pretty sure we already explained this a long time ago when the > > issue came up last year, so I'm not sure why this is even still > > contentious. > > I suspect that it's simply because these discussions have been > spread across different groups and not everyone is aware of what the > other groups are discussing... Yes, I have the same feeling. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps

2018-10-03 Thread Jan Kara
, > the blocking free buffer maybe not. Well, as John wrote, these page refcount are fragile (and actually filesystem dependent as some filesystems hold page reference from their page->private data and some don't). So I think we really need a new reliable mechanism for tracking page references from GUP. And John works towards that. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] mm/filemap.c: Use vmf_error()

2018-10-01 Thread Jan Kara
On Thu 27-09-18 22:44:12, Souptick Joarder wrote: > These codes can be replaced with new inline vmf_error(). > > Signed-off-by: Souptick Joarder Looks good. You can add: Reviewed-by: Jan Kara Honza > --- > m

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

2018-10-01 Thread Jan Kara
ify_marks if they happen to be cache cold. Or it could be just code layout differences (i.e., compiler is not able to optimize resulting code as good or the code layout just happens to align with cache lines in a wrong way or something like that). Anyway, without being able to reproduce this and do detailed comparison of perf profiles I don't think we'll be able to tell. Honza -- Jan Kara SUSE Labs, CR

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

2018-10-01 Thread Jan Kara
reached > the extra fsnotify_first_mark() call. > Can you confirm or disprove the assumption that an fanotify mount mark > is present during the test? This would be good to know. Honza > > diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c > index 422fbc6dffde..8d45d82e09ff 100644 > --- a/fs/notify/fsnotify.c > +++ b/fs/notify/fsnotify.c > @@ -246,6 +246,9 @@ static struct fsnotify_mark > *fsnotify_first_mark(struct fsnotify_mark_connector > struct fsnotify_mark_connector *conn; > struct hlist_node *node = NULL; > > + if (!*connp) > + return NULL; > + > conn = srcu_dereference(*connp, _mark_srcu); > if (conn) > node = srcu_dereference(conn->list.first, > _mark_srcu); -- Jan Kara SUSE Labs, CR

Re: kernel BUG at include/linux/page-flags.h:LINE!

2018-09-19 Thread Jan Kara
path: path = > '/devices/virtual/block/loop3' > CR2: 001b3202d000 CR3: 0001cad9f000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is gene

Re: [BUG] mm: direct I/O (using GUP) can write to COW anonymous pages

2018-09-18 Thread Jan Kara
Properly dealing with private mappings should not be that hard once the infrastructure is there I hope but I didn't seriously look into that. I've added Miklos and John to CC as they are interested as well. John was working on fixing this problem - https://lkml.org/lkml/2018/7/9/158 - but I didn't hear from him for quite a while so I'm not sure whether it died off or what's the current situation. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] docs: fix some broken documentation references

2018-09-18 Thread Jan Kara
> Signed-off-by: Mauro Carvalho Chehab Looks good to me. Thanks for fixing this up. You can add: Reviewed-by: Jan Kara Honza > --- > Documentation/filesystems/dax.txt | 2 +- > Documentation/filesy

Re: possible deadlock in start_this_handle

2018-09-07 Thread Jan Kara
:4154 >__do_sys_symlink fs/namei.c:4173 [inline] >__se_sys_symlink fs/namei.c:4171 [inline] >__x64_sys_symlink+0x59/0x80 fs/namei.c:4171 >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 >entry_SYSCALL_64_after_hwframe+0x49/0xbe Honza -- Jan Kara SUSE Labs, CR

Re: [UDF] BUG: KASAN: slab-out-of-bounds in iput+0x8df/0xa80

2018-09-06 Thread Jan Kara
010839] R13: R14: 7ffdd66b1a58 R15: > > [ 24.011020] > [ 24.011147] Allocated by task 0: > [ 24.011209] (stack is not available) > [ 24.011277] > [ 24.011314] Freed by task 0: > [ 24.011359] (stack is not available) > [ 24.011413] > [ 24.011457] The buggy address belongs to the object at 880067e82100 > [ 24.011457] which belongs to the cache kmalloc-16 of size 16 > [ 24.011662] The buggy address is located 0 bytes inside of > [ 24.011662] 16-byte region [880067e82100, 880067e82110) > [ 24.011839] The buggy address belongs to the page: > [ 24.012064] page:ea00019fa080 count:1 mapcount:0 > mapping:88006c001b40 index:0x0 > [ 24.012318] flags: 0x1000100(slab) > [ 24.012614] raw: 01000100 dead0100 dead0200 > 88006c001b40 > [ 24.012744] raw: 80800080 0001 > > [ 24.012991] page dumped because: kasan: bad access detected > [ 24.013105] > [ 24.013162] Memory state around the buggy address: > [ 24.013453] 880067e82000: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 > fc fc > [ 24.013581] 880067e82080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 24.013700] >880067e82100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 24.013851]^ > [ 24.013912] 880067e82180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 24.014012] 880067e82200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 24.014132] > == > [ 24.014250] Disabling lock debugging due to kernel taint > mount: mounting /dev/sda on /mnt failed: Invalid argument > [ 24.027931] exe (1090) used greatest stack depth: 19824 bytes left > > > > BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > /bin/sh: can't access tty; job control turned off > / #  -- Jan Kara SUSE Labs, CR

Re: linux-next test error

2018-09-06 Thread Jan Kara
nce which are interesting. One solution for passing error codes we could use with vm_fault_t is a scheme similar to ERR_PTR. So we can store full error code in vm_fault_t and still have a plenty of space for the special VM_FAULT_ return codes... With that scheme converting block_page_mkwrite() would be trivial. Honza -- Jan Kara SUSE Labs, CR

Re: linux-next test error

2018-09-06 Thread Jan Kara
On Thu 06-09-18 00:37:06, Souptick Joarder wrote: > On Wed, Sep 5, 2018 at 2:25 PM Jan Kara wrote: > > > > On Wed 05-09-18 00:13:02, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit

Re: linux-next test error

2018-09-05 Thread Jan Kara
On Wed 05-09-18 15:20:16, Souptick Joarder wrote: > On Wed, Sep 5, 2018 at 2:25 PM Jan Kara wrote: > > > > On Wed 05-09-18 00:13:02, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit

Re: linux-next test error

2018-09-05 Thread Jan Kara
Souptick, can I ask you to run 'fstests' for at least common filesystems like ext4, xfs, btrfs when you change generic filesystem code please? That would catch a bug like this immediately. Thanks. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v2] fs/posix_acl.c: fix kernel-doc warnings, formatting, and typo

2018-09-04 Thread Jan Kara
Clear SGID bit when setting file > permissions") > > Signed-off-by: Randy Dunlap > Cc: Jan Kara > Cc: Andreas Gruenbacher > Cc: Alexander Viro > Cc: linux-fsde...@vger.kernel.org > Acked-by: Andreas Gruenbacher Looks good to me. You can add: Reviewed-by: Jan

Re: KASAN: stack-out-of-bounds Read in __schedule

2018-08-29 Thread Jan Kara
; > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > -- Jan Kara SUSE Labs, CR

Re: [PATCH] udf: remove unused variables group_start and nr_groups

2018-08-29 Thread Jan Kara
tmapDesc) << 3); > block_group = block >> (sb->s_blocksize_bits + 3); > - group_start = block_group ? 0 : sizeof(struct spaceBitmapDesc); > > bitmap_nr = load_block_bitmap(sb, bitmap, block_group); > if (bitmap_nr < 0) > -- > 2.17.1 > > -- Jan Kara SUSE Labs, CR

Re: [PATCH 1/2] fs/quota: Replace XQM_MAXQUOTAS usage with MAXQUOTAS

2018-08-22 Thread Jan Kara
On Wed 22-08-18 18:05:51, Jan Kara wrote: > On Tue 31-07-18 01:37:30, Jeremy Cline wrote: > > XQM_MAXQUOTAS and MAXQUOTAS are, it appears, equivalent. Replace all > > usage of XQM_MAXQUOTAS and remove it along with the unused XQM_*QUOTA > > definitions. > > >

Re: [PATCH 0/2] fs/quota: Fix potential spectre v1 gadgets

2018-08-22 Thread Jan Kara
onstant from the number of quota types generic infrastructure supports... So here I agree with Andreas. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 2/2] fs/quota: Fix spectre gadget in do_quotactl

2018-08-22 Thread Jan Kara
> > if (type >= MAXQUOTAS) > return -EINVAL; > + type = array_index_nospec(type, MAXQUOTAS); > /* >* Quota not supported on this fs? Check this before s_quota_types >* since they needn't be set if quota is not supported at all. > -- > 2.17.1 > > -- Jan Kara SUSE Labs, CR

Re: [PATCH 1/2] fs/quota: Replace XQM_MAXQUOTAS usage with MAXQUOTAS

2018-08-22 Thread Jan Kara
counting/enforcement */ > #define Q_XGETQUOTA XQM_CMD(3) /* get disk limits and usage */ Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] fanotify: use killable wait for waiting response for permission events

2018-08-21 Thread Jan Kara
On Tue 21-08-18 16:42:26, Konstantin Khlebnikov wrote: > On 20.08.2018 13:53, Jan Kara wrote: > > > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c > > > index eb4e75175cfb..7a0c37790c89 100644 > > > --- a/fs/notify/fanotify/fanotify.c

Re: [PATCH] fanotify: use killable wait for waiting response for permission events

2018-08-20 Thread Jan Kara
t;fanotify_data.access_waitq, event->response); > + } > > /* userspace responded, convert to something usable */ > switch (event->response & ~FAN_AUDIT) { > -- Jan Kara SUSE Labs, CR

Re: [BUG] mm: truncate: a possible sleep-in-atomic-context bug in truncate_exceptional_pvec_entries()

2018-08-13 Thread Jan Kara
() only if we are operating on DAX mapping. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-08-08 Thread Jan Kara
On Wed 08-08-18 08:57:13, cgxu519 wrote: > On 08/07/2018 09:54 PM, Jan Kara wrote: > > On Mon 06-08-18 15:59:27, Andrew Morton wrote: > > > On Mon, 6 Aug 2018 12:22:03 +0200 Jan Kara wrote: > > > > > > > On Fri 20-07-18 16:14:29, Andrew Morton wrote: >

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-08-07 Thread Jan Kara
On Mon 06-08-18 15:59:27, Andrew Morton wrote: > On Mon, 6 Aug 2018 12:22:03 +0200 Jan Kara wrote: > > > On Fri 20-07-18 16:14:29, Andrew Morton wrote: > > > On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara wrote: > > > > > > > On Thu 19-07-18 16:17:26,

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-08-06 Thread Jan Kara
On Fri 20-07-18 16:14:29, Andrew Morton wrote: > On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara wrote: > > > On Thu 19-07-18 16:17:26, Chengguang Xu wrote: > > > When we try to truncate read count in generic_file_buffered_read(), > > > should deliver (sb->s_ma

Re: INFO: task hung in generic_file_write_iter

2018-08-06 Thread Jan Kara
get_block() is failing > forever. Any idea? Looks like some kind of a race where device block size gets changed while getblk() runs (and creates buffers for underlying page). I don't have time to nail it down at this moment can have a look into it later unless someone beats me to it. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-07-19 Thread Jan Kara
On Thu 19-07-18 16:17:26, Chengguang Xu wrote: > When we try to truncate read count in generic_file_buffered_read(), > should deliver (sb->s_maxbytes - offset) as maximum count not > sb->s_maxbytes itself. > > Signed-off-by: Chengguang Xu Looks good to me. You can add:

Re: [PATCH] reiserfs: fix buffer overflow with long warning messages

2018-07-16 Thread Jan Kara
Eric Biggers Looks good to me. You can add: Reviewed-by: Jan Kara I'd just note that I'd prefer some lines not to exceed 80 chars like: - sprintf_le_key(p, va_arg(args, struct reiserfs_key *)); + p += scnprintf_le_key(p, end - p, +

Re: [PATCH 0/2] mm/fs: put_user_page() proposal

2018-07-10 Thread Jan Kara
On Mon 09-07-18 13:00:49, Matthew Wilcox wrote: > On Mon, Jul 09, 2018 at 09:47:40PM +0200, Jan Kara wrote: > > On Mon 09-07-18 10:16:51, Matthew Wilcox wrote: > > > > 2) What to do when some page is pinned but we need to do e.g. > > > > clear_page_dirty_for_io().

Re: [PATCH 0/2] mm/fs: put_user_page() proposal

2018-07-10 Thread Jan Kara
On Mon 09-07-18 13:56:57, Jason Gunthorpe wrote: > On Mon, Jul 09, 2018 at 09:47:40PM +0200, Jan Kara wrote: > > On Mon 09-07-18 10:16:51, Matthew Wilcox wrote: > > > On Mon, Jul 09, 2018 at 06:08:06PM +0200, Jan Kara wrote: > > > > On Mon 09-07-18 1

Re: [PATCH 0/2] mm/fs: put_user_page() proposal

2018-07-09 Thread Jan Kara
On Mon 09-07-18 10:16:51, Matthew Wilcox wrote: > On Mon, Jul 09, 2018 at 06:08:06PM +0200, Jan Kara wrote: > > On Mon 09-07-18 18:49:37, Nicholas Piggin wrote: > > > The problem with blocking in clear_page_dirty_for_io is that the fs is > > > holding the page lock (or

Re: [PATCH 0/2] mm/fs: put_user_page() proposal

2018-07-09 Thread Jan Kara
> or, the same thread on LKML if it's working for you: > > https://lkml.org/lkml/2018/7/4/368 Yeah, but as Nick pointed out we have some more work to do in step 4 to avoid deadlocks. Still there's a lot of work to do on which the direction to progress is clear :). Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 1/2] mm: introduce put_user_page(), placeholder version

2018-07-09 Thread Jan Kara
mp; !defined(CONFIG_SPARSEMEM_VMEMMAP) > > #define SECTION_IN_PAGE_FLAGS > > #endif > > Just as question: Do you think it is worthwhile to have a > release_user_page_dirtied() helper as well? > > Ie to indicate that a pages that were grabbed under GUP FOLL_WRITE > were actually written too? > > Keeps more of these unimportant details out of the drivers.. Yeah, I think that would be nice as well. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 0/2] mm/fs: put_user_page() proposal

2018-07-09 Thread Jan Kara
how we identify pinned pages, just waiting in clear_page_dirty_for_io() is going to cause deadlocks. So I agree with you that the solution (but even for short term GUP users) will need filesystem changes. I don't see a need for fs callbacks on pin time (as I don't see much fs-specific work to do there) but we will probably need to provide a way to wait for outstanding pins & preventing new ones for given mapping range while writeback / unmapping is running. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v2 5/6] mm: track gup pages with page->dma_pinned_* fields

2018-07-09 Thread Jan Kara
On Thu 05-07-18 14:17:19, Christopher Lameter wrote: > On Wed, 4 Jul 2018, Jan Kara wrote: > > > > So this seems unsolvable without having the caller specify that it knows > > > the > > > page type, and that it is therefore safe to decrement > > > page

Re: [PATCH v2 5/6] mm: track gup pages with page->dma_pinned_* fields

2018-07-04 Thread Jan Kara
a page. It is not. "pinned" is a property of a page reference (i.e., a kind of reference that can be used for DMA access) and page gets into "pinned" state if it has any reference of "pinned" type. And when you realize this, it is obvious that you just have to have a special api for getting and dropping references of this "pinned" type. For getting we already have get_user_pages(), for putting we have to create the api... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

2018-07-03 Thread Jan Kara
ure of +ve and -ve dentries? > Should we have a separate LRU for -ve dentries? Are we appropriately > aging the various dentries? etc. > > It could be that tuning/fixing the current code will fix whatever > problems inspired this patchset. What I think is contributing to the problems and could lead to reclaim oddities is the internal fragmentation of dentry slab cache. Dentries are relatively small, you get 21 per page on my system, so if trivial to reclaim negative dentries get mixed with a small amount of unreclaimable positive dentries, you can get a lot of pages in dentry slab cache that are unreclaimable. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v2 1/6] mm: get_user_pages: consolidate error handling

2018-07-02 Thread Jan Kara
es its true role. > This also gets rid of two shadowed variable declarations, as a > tiny beneficial a side effect. > > Signed-off-by: John Hubbard This looks nice! You can add: Reviewed-by: Jan Kara Honza > --- >

Re: [PATCH v2 6/6] mm: page_mkclean, ttu: handle pinned pages

2018-07-02 Thread Jan Kara
tables, you check PageDmaPinned() and wait if needed. Page cannot be faulted in again as we hold page lock and so races with concurrent GUP are fairly limited. So with some careful ordering & memory barriers you should be able to get away without any locking. Ditto for the unmap path... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH v2 5/6] mm: track gup pages with page->dma_pinned_* fields

2018-07-02 Thread Jan Kara
GPUs, for example) that set up direct access to a chunk > of system (CPU) memory, so that they can DMA to/from that memory. > > CC: Matthew Wilcox > CC: Jan Kara > CC: Dan Williams > Signed-off-by: John Hubbard ... > @@ -904,12 +907,24 @@ static inline void get_page(struct

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-07-02 Thread Jan Kara
On Sun 01-07-18 23:10:04, John Hubbard wrote: > On 07/01/2018 10:52 PM, Leon Romanovsky wrote: > > On Thu, Jun 28, 2018 at 11:17:43AM +0200, Jan Kara wrote: > >> On Wed 27-06-18 19:42:01, John Hubbard wrote: > >>> On 06/27/2018 10:02 AM, Jan Kara wrote: > >

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-07-02 Thread Jan Kara
On Mon 02-07-18 08:52:51, Leon Romanovsky wrote: > On Thu, Jun 28, 2018 at 11:17:43AM +0200, Jan Kara wrote: > > On Wed 27-06-18 19:42:01, John Hubbard wrote: > > > On 06/27/2018 10:02 AM, Jan Kara wrote: > > > > On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote: >

Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg

2018-06-29 Thread Jan Kara
On Thu 28-06-18 12:21:26, Shakeel Butt wrote: > On Thu, Jun 28, 2018 at 12:03 PM Jan Kara wrote: > > > > On Wed 27-06-18 12:12:49, Shakeel Butt wrote: > > > A lot of memory can be consumed by the events generated for the huge or > > > unlimited queues if th

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-28 Thread Jan Kara
On Wed 27-06-18 19:42:01, John Hubbard wrote: > On 06/27/2018 10:02 AM, Jan Kara wrote: > > On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote: > >> On Wed, Jun 27, 2018 at 02:42:55PM +0200, Jan Kara wrote: > >>> On Wed 27-06-18 13:59:27, Michal Hocko wrote: > >&g

Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg

2018-06-28 Thread Jan Kara
ep = Why don't you setup also fanotify_event_cachep and fanotify_perm_event_cachep caches with SLAB_ACCOUNT and instead specify __GFP_ACCOUNT manually? Otherwise the patch looks good to me. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-27 Thread Jan Kara
On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote: > On Wed, Jun 27, 2018 at 02:42:55PM +0200, Jan Kara wrote: > > On Wed 27-06-18 13:59:27, Michal Hocko wrote: > > > On Wed 27-06-18 13:53:49, Jan Kara wrote: > > > > On Wed 27-06-18 13:32:21, Michal Hocko wrote: >

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-27 Thread Jan Kara
On Wed 27-06-18 13:59:27, Michal Hocko wrote: > On Wed 27-06-18 13:53:49, Jan Kara wrote: > > On Wed 27-06-18 13:32:21, Michal Hocko wrote: > [...] > > > Appart from that, do we really care about 32b here? Big DIO, IB users > > > seem to be 64b only AFAIU. > >

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-27 Thread Jan Kara
On Wed 27-06-18 13:32:21, Michal Hocko wrote: > On Tue 26-06-18 18:48:25, Jan Kara wrote: > > On Tue 26-06-18 15:47:57, Michal Hocko wrote: > > > On Mon 18-06-18 12:21:46, Dan Williams wrote: > > > [...] > > > > I do think we should explore a page flag for pa

Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg

2018-06-27 Thread Jan Kara
claim which trigger fsnotify > events. Though I would like Amir or Jan to confirm there is no nesting > possible. You are correct. Fsnotify events are generated only as a result of some syscall, not due to reclaim or stuff like that. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-26 Thread Jan Kara
er to keep this discussion separate from 'how to identify pinned pages'. Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH] writeback: update stale account_page_redirty() comment

2018-06-26 Thread Jan Kara
; WB_DIRTIED > BDI_WRITTEN => WB_WRITTEN > > Signed-off-by: Greg Thelen Looks good. You can add: Reviewed-by: Jan Kara Honza > --- > mm/page-writeback.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-26 Thread Jan Kara
On Mon 25-06-18 23:31:06, John Hubbard wrote: > On 06/25/2018 08:21 AM, Jan Kara wrote: > > On Thu 21-06-18 18:30:36, Jan Kara wrote: > > So I think the Matthew's idea of removing pinned pages from LRU is > > definitely worth trying to see how complex that would end up b

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-26 Thread Jan Kara
On Mon 25-06-18 12:03:37, John Hubbard wrote: > On 06/25/2018 08:21 AM, Jan Kara wrote: > > On Thu 21-06-18 18:30:36, Jan Kara wrote: > >> On Wed 20-06-18 15:55:41, John Hubbard wrote: > >>> On 06/20/2018 05:08 AM, Jan Kara wrote: > >>>> On Tue 19-06-1

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-25 Thread Jan Kara
On Thu 21-06-18 18:30:36, Jan Kara wrote: > On Wed 20-06-18 15:55:41, John Hubbard wrote: > > On 06/20/2018 05:08 AM, Jan Kara wrote: > > > On Tue 19-06-18 11:11:48, John Hubbard wrote: > > >> On 06/19/2018 03:41 AM, Jan Kara wrote: > > >>> O

  1   2   3   4   5   6   7   8   9   10   >