[PATCH] bfq: silence lockdep for bfqd/ioc lock inversion

2021-03-18 Thread Khazhismel Kumykov
verted orderings should never conflict. Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") Signed-off-by: Khazhismel Kumykov --- block/bfq-iosched.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) Noticed this lockdep running xfstests

Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE

2020-09-01 Thread Khazhismel Kumykov
On Sat, Aug 29, 2020 at 6:00 PM Bart Van Assche wrote: > > From https://www.kernel.org/doc/man-pages/linux-api-ml.html: > "all Linux kernel patches that change userspace interfaces should be CCed > to linux-...@vger.kernel.org" > > So I have added the linux-api mailing list to the Cc-list. Anyway:

[PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE

2020-08-24 Thread Khazhismel Kumykov
CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping. Retain CAP_SYS_ADMIN permission for backwards compatibility. Signed-off-by: Khazhismel Kumykov --- block/ioprio.c | 2 +- include/uapi/linux/capability.h | 2 ++ 2 files changed, 3 insertions(

Re: [PATCH] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE

2020-08-24 Thread Khazhismel Kumykov
On Mon, Aug 24, 2020 at 1:45 PM Khazhismel Kumykov wrote: > > CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping. > > Retain CAP_SYS_ADMIN permission for backwards compatibility. > > Signed-off-by: Khazhismel Kumykov > --- > block/

Re: IOPRIO_CLASS_RT without CAP_SYS_ADMIN?

2020-08-24 Thread Khazhismel Kumykov
On Sat, Aug 22, 2020 at 7:14 PM Jens Axboe wrote: > > On 8/22/20 7:58 PM, Bart Van Assche wrote: > > On 2020-08-20 17:35, Khazhismel Kumykov wrote: > >> It'd be nice to allow a process to send RT requests without granting > >> it the wide capabilities of C

[PATCH] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE

2020-08-24 Thread Khazhismel Kumykov
CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping. Retain CAP_SYS_ADMIN permission for backwards compatibility. Signed-off-by: Khazhismel Kumykov --- block/ioprio.c | 2 +- include/uapi/linux/capability.h | 2 ++ 2 files changed, 3 insertions(

IOPRIO_CLASS_RT without CAP_SYS_ADMIN?

2020-08-20 Thread Khazhismel Kumykov
It'd be nice to allow a process to send RT requests without granting it the wide capabilities of CAP_SYS_ADMIN, and we already have a capability which seems to almost fit this priority idea - CAP_SYS_NICE? Would this fit there? Being capable of setting IO priorities on per request or per thread ba

Re: [PATCH 1/1] epoll: call final ep_events_available() check under the lock

2020-05-05 Thread Khazhismel Kumykov
On Tue, May 5, 2020 at 1:04 PM Andrew Morton wrote: > > On Tue, 05 May 2020 10:42:05 +0200 Roman Penyaev wrote: > > > May I ask you to remove "epoll: ensure ep_poll() doesn't miss wakeup > > events" from your -mm queue? Jason lately found out that the patch > > does not fully solve the problem an

[PATCH v4] fuse: kmemcg account fs data

2019-09-17 Thread Khazhismel Kumykov
account per-file, dentry, and inode data blockdev/superblock and temporary per-request data was left alone, as this usually isn't accounted Reviewed-by: Shakeel Butt Signed-off-by: Khazhismel Kumykov --- fs/fuse/dir.c | 3 ++- fs/fuse/file.c | 5 +++-- fs/fuse/inode.c | 2 +- 3

Re: [PATCH v3 2/2] fuse: kmemcg account fs data

2019-09-17 Thread Khazhismel Kumykov
On Tue, Sep 17, 2019 at 12:52 AM Miklos Szeredi wrote: > > On Tue, Sep 17, 2019 at 1:56 AM Khazhismel Kumykov wrote: > > struct fuse_forget_link *fuse_alloc_forget(void) > > { > > - return kzalloc(sizeof(struct fuse_forget_link), GFP_KERNEL); > > +

[PATCH v3 1/2] fuse: on 64-bit store time in d_fsdata directly

2019-09-16 Thread Khazhismel Kumykov
utt Signed-off-by: Khazhismel Kumykov --- v3: reapplied on fuse/for-next, droping the fuse_request_alloc refactor it was already done :) (and account new per-file alloc) fs/fuse/dir.c | 36 ++-- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/fs/fuse/dir

[PATCH v3 2/2] fuse: kmemcg account fs data

2019-09-16 Thread Khazhismel Kumykov
account per-file, dentry, and inode data blockdev/superblock and temporary per-request data was left alone, as this usually isn't accounted Signed-off-by: Khazhismel Kumykov Reviewed-by: Shakeel Butt --- fs/fuse/dir.c | 3 ++- fs/fuse/file.c | 5 +++-- fs/fuse/inode.c | 3 ++- 3

Re: [PATCH v2 1/3] fuse: on 64-bit store time in d_fsdata directly

2019-09-03 Thread Khazhismel Kumykov
On Thu, Aug 22, 2019 at 1:00 PM Khazhismel Kumykov wrote: > > Implements the optimization noted in f75fdf22b0a8 ("fuse: don't use > ->d_time"), as the additional memory can be significant. (In particular, > on SLAB configurations this 8-byte alloc becomes 32 bytes).

[PATCH v2 3/3] fuse: kmemcg account fs data

2019-08-22 Thread Khazhismel Kumykov
account per-file, dentry, and inode data accounts the per-file reserved request, adding new fuse_request_alloc_account() blockdev/superblock and temporary per-request data was left alone, as this usually isn't accounted Signed-off-by: Khazhismel Kumykov --- fs/fuse/dir.c | 3 ++- fs

[PATCH v2 2/3] fuse: pass gfp flags to fuse_request_alloc

2019-08-22 Thread Khazhismel Kumykov
Instead of having a helper per flag Signed-off-by: Khazhismel Kumykov --- fs/fuse/dev.c| 16 +++- fs/fuse/file.c | 6 +++--- fs/fuse/fuse_i.h | 4 +--- fs/fuse/inode.c | 4 ++-- 4 files changed, 9 insertions(+), 21 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c

[PATCH v2 1/3] fuse: on 64-bit store time in d_fsdata directly

2019-08-22 Thread Khazhismel Kumykov
utt Signed-off-by: Khazhismel Kumykov --- fs/fuse/dir.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index dd0f64f7bc06..f9c59a296568 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -24,6 +24,18 @@ static void fuse_advise_use_readdirplus

Re: [PATCH 3/3] fuse: pass gfp flags to fuse_request_alloc

2019-08-22 Thread Khazhismel Kumykov
On Wed, Aug 21, 2019 at 5:18 PM Shakeel Butt wrote: > > On Wed, Aug 21, 2019 at 5:10 PM Khazhismel Kumykov wrote: > > > > Instead of having a helper per flag > > > > Signed-off-by: Khazhismel Kumykov > > I think it would be better to re-order the patch 2 a

[PATCH 2/3] fuse: kmemcg account fs data

2019-08-21 Thread Khazhismel Kumykov
account per-file, dentry, and inode data accounts the per-file reserved request, adding new fuse_request_alloc_account() blockdev/superblock and temporary per-request data was left alone, as this usually isn't accounted Signed-off-by: Khazhismel Kumykov --- fs/fuse/dev.c| 6 +

[PATCH 3/3] fuse: pass gfp flags to fuse_request_alloc

2019-08-21 Thread Khazhismel Kumykov
Instead of having a helper per flag Signed-off-by: Khazhismel Kumykov --- fs/fuse/dev.c| 22 +++--- fs/fuse/file.c | 6 +++--- fs/fuse/fuse_i.h | 6 +- fs/fuse/inode.c | 4 ++-- 4 files changed, 9 insertions(+), 29 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse

[PATCH 1/3] fuse: on 64-bit store time in d_fsdata directly

2019-08-21 Thread Khazhismel Kumykov
Implements the optimization noted in f75fdf22b0a8 ("fuse: don't use ->d_time"), as the additional memory can be significant. (In particular, on SLAB configurations this 8-byte alloc becomes 32 bytes). Per-dentry, this can consume significant memory. Signed-off-by: Khazhismel Kum

[PATCH v2] ext4: cond_resched in work-heavy group loops

2019-04-23 Thread Khazhismel Kumykov
These functions may take a long time looping over many groups, which may cause issues for non-preempt kernels. ext4_mb_init_backend() ext4_setup_system_zone() ext4_mb_release() Signed-off-by: Khazhismel Kumykov --- v2: - a few other places that in testing showed to be slow fs/ext4

Re: [PATCH] ext4: add cond_resched() to ext4_mb_init_backend()

2019-04-18 Thread Khazhismel Kumykov
On Thu, Apr 18, 2019 at 4:53 AM Jan Kara wrote: > > On Mon 15-04-19 19:59:34, Khazhismel Kumykov wrote: > > on non-preempt kernels for filesystems with large number of groups we > > may take a long time (>50 ticks) initializing all the groups. > > > > Signed-off-b

[PATCH] ext4: add cond_resched() to ext4_mb_init_backend()

2019-04-15 Thread Khazhismel Kumykov
on non-preempt kernels for filesystems with large number of groups we may take a long time (>50 ticks) initializing all the groups. Signed-off-by: Khazhismel Kumykov --- fs/ext4/mballoc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c in

Re: WARNING in notify_change

2019-04-15 Thread Khazhismel Kumykov
I was able to reproduce this by setting security.capability xattr on a blockdev file, then writing to it - when writing to the blockdev we never lock the inode, so when we clear the capability we hit this lockdep warning. Is the issue here that we can set this xattr in the first place so we have t

[PATCH] fs/fat: add cond_resched to fat_count_free_clusters

2018-10-10 Thread Khazhismel Kumykov
On non-preempt kernels this loop can take a long time (more than 50 ticks) processing through entries. Signed-off-by: Khazhismel Kumykov --- fs/fat/fatent.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c index defc2168de91..f58c0cacc531 100644 --- a/fs/fat

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

2018-04-16 Thread Khazhismel Kumykov
On Sun, Apr 15, 2018 at 3:34 PM, Al Viro wrote: > On Sun, Apr 15, 2018 at 10:54:55PM +0100, Al Viro wrote: >> On Sun, Apr 15, 2018 at 09:40:54PM +0100, Al Viro wrote: >> >> > BTW, the current placement of cond_resched() looks bogus; suppose we >> > have collected a lot of victims and ran into need

[PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

2018-04-13 Thread Khazhismel Kumykov
s Torvalds Signed-off-by: Khazhismel Kumykov --- fs/dcache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/dcache.c b/fs/dcache.c index 591b34500e41..3507badeb60a 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1489,6 +1489,7 @@ void shrink_dcache_parent(struct dent

[PATCH] block/compat_ioctl: fix range check in BLKGETSIZE

2018-04-06 Thread Khazhismel Kumykov
kernel ulong and compat_ulong_t may not be same width. Use type directly to eliminate mismatches. This would result in truncation rather than EFBIG for 32bit mode for large disks. Signed-off-by: Khazhismel Kumykov --- block/compat_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [dm-devel] [PATCH] dm mpath selector: more evenly distribute ties

2018-01-24 Thread Khazhismel Kumykov
On Wed, Jan 24, 2018 at 11:09 AM, Martin Wilck wrote: > On Wed, 2018-01-24 at 10:44 -0800, Khazhismel Kumykov wrote: >> On Wed, Jan 24, 2018 at 2:57 AM, Martin Wilck >> wrote: >> > On Fri, 2018-01-19 at 15:07 -0800, Khazhismel Kumykov wrote: >> > > Move the l

Re: [dm-devel] [PATCH] dm mpath selector: more evenly distribute ties

2018-01-24 Thread Khazhismel Kumykov
On Wed, Jan 24, 2018 at 2:57 AM, Martin Wilck wrote: > On Fri, 2018-01-19 at 15:07 -0800, Khazhismel Kumykov wrote: >> Move the last used path to the end of the list (least preferred) so >> that >> ties are more evenly distributed. >> >> For example, in case

[PATCH] dm mpath selector: more evenly distribute ties

2018-01-19 Thread Khazhismel Kumykov
) -> best path 'a' (b, c, a) -> best path 'b' (c, a, b) -> best path 'a' (c, b, a) -> best path 'b' ... Signed-off-by: Khazhismel Kumykov --- drivers/md/dm-queue-length.c | 6 +++--- drivers/md/dm-service-time.c | 6 +++--- 2 files changed, 6

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-18 Thread Khazhismel Kumykov
On Mon, Dec 18, 2017 at 1:01 PM, Vivek Goyal wrote: > On Mon, Dec 18, 2017 at 12:39:50PM -0800, Khazhismel Kumykov wrote: >> On Mon, Dec 18, 2017 at 10:29 AM, Vivek Goyal wrote: >> > On Mon, Dec 18, 2017 at 10:16:02AM -0800, Khazhismel Kumykov wrote: >> >> O

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-18 Thread Khazhismel Kumykov
On Mon, Dec 18, 2017 at 10:29 AM, Vivek Goyal wrote: > On Mon, Dec 18, 2017 at 10:16:02AM -0800, Khazhismel Kumykov wrote: >> On Mon, Nov 20, 2017 at 8:36 PM, Khazhismel Kumykov >> wrote: >> > On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: >> >> On T

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-18 Thread Khazhismel Kumykov
On Mon, Nov 20, 2017 at 8:36 PM, Khazhismel Kumykov wrote: > On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: >> On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >>> On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: >>> > On Tue, No

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-06 Thread Khazhismel Kumykov
On Mon, Nov 20, 2017 at 8:36 PM, Khazhismel Kumykov wrote: > On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: >> On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >>> On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: >>> > On Tue, No

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-11-20 Thread Khazhismel Kumykov
On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: > On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >> On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: >> > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> >> Allows con

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-11-16 Thread Khazhismel Kumykov
On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> Allows configuration additional bytes or ios before a throttle is >> triggered. >> >> This allows implementation of a bucket style rate-limit/th

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-11-14 Thread Khazhismel Kumykov
(Botched the to line, sorry) smime.p7s Description: S/MIME Cryptographic Signature

[RFC PATCH] blk-throttle: add burst allowance.

2017-11-14 Thread Khazhismel Kumykov
uld be earned back. trim_slice still does progress slice_start as before and decrements *_disp as before, and tgs continue to get bytes/ios in throtl_slice intervals. Signed-off-by: Khazhismel Kumykov --- block/Kconfig| 11 +++ block/blk-thr

[RFC PATCH] blk-throttle: add burst allowance

2017-10-26 Thread Khazhismel Kumykov
: Khazhismel Kumykov --- block/Kconfig| 11 +++ block/blk-throttle.c | 185 --- 2 files changed, 186 insertions(+), 10 deletions(-) diff --git a/block/Kconfig b/block/Kconfig index 3ab42bbb06d5..16545caa7fc9 100644 --- a/block/Kconfig +++ b

Re: [Patch v2 1/2] libiscsi: Fix use-after-free race during iscsi_session_teardown

2017-09-29 Thread Khazhismel Kumykov
Noticed these don't seem to be in 4.14/scsi-queue On Tue, Aug 29, 2017 at 6:45 PM, Martin K. Petersen wrote: > > Chris, > >> Looks good to me, fixes up the code given that the comment there about >> calling iscsi_remove_session wasn't being followed. > > Applied these two to 4.14/scsi-queue. > >

[PATCH v2] generic: Add nocheck shutdown stress test

2017-09-22 Thread Khazhismel Kumykov
ff-by: Khazhismel Kumykov --- v2: drop defrag, use "silence is golden" tests/generic/999 | 83 +++ tests/generic/999.out | 2 ++ tests/generic/group | 1 + 3 files changed, 86 insertions(+) create mode 100755 tests/generic/999 cre

[PATCH] generic: Add nocheck shutdown stress test

2017-09-21 Thread Khazhismel Kumykov
Most shutdown tests only run on filesystems with metadata journaling, so we lose coverage. Add a shutdown stress test that doesn't check for consistency, so does not require journaling. Signed-off-by: Khazhismel Kumykov --- tests/generic/999

Re: [Patch v2 1/2] libiscsi: Fix use-after-free race during iscsi_session_teardown

2017-08-24 Thread Khazhismel Kumykov
On Thu, Jul 13, 2017 at 9:11 AM, Khazhismel Kumykov wrote: Ping in case this was missed smime.p7s Description: S/MIME Cryptographic Signature

[Patch v2 1/2] libiscsi: Fix use-after-free race during iscsi_session_teardown

2017-07-13 Thread Khazhismel Kumykov
Session attributes exposed through sysfs were freed before the device was destroyed, resulting in a potential use-after-free. Free these attributes after removing the device. Signed-off-by: Khazhismel Kumykov --- drivers/scsi/libiscsi.c | 8 1 file changed, 4 insertions(+), 4 deletions

[Patch v2 2/2] libiscsi: Remove iscsi_destroy_session

2017-07-13 Thread Khazhismel Kumykov
iscsi_session_teardown was the only user of this function. Function currently is just short for iscsi_remove_session + iscsi_free_session. Signed-off-by: Khazhismel Kumykov --- drivers/scsi/scsi_transport_iscsi.c | 16 include/scsi/scsi_transport_iscsi.h | 1 - 2 files changed

[PATCH] libiscsi: Remove iscsi_destroy_session

2017-07-12 Thread Khazhismel Kumykov
iscsi_session_teardown was the only user of this function. Function currently is just short for iscsi_remove_session + iscsi_free_session. Signed-off-by: Khazhismel Kumykov --- with "libiscsi: Fix use after free race during iscsi_session_teardown" removing the last user. dr

[PATCH] libiscsi: Fix use-after-free race during iscsi_session_teardown

2017-07-12 Thread Khazhismel Kumykov
Session attributes exposed through sysfs were freed before the device was destroyed, resulting in a potential use-after-free. Free these attributes after removing the device. Signed-off-by: Khazhismel Kumykov --- drivers/scsi/libiscsi.c | 8 1 file changed, 4 insertions(+), 4 deletions

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

2017-06-23 Thread Khazhismel Kumykov
On Fri, Jun 23, 2017 at 2:36 PM, Andreas Dilger wrote: > On Jun 23, 2017, at 6:26 AM, Theodore Ts'o wrote: >> >> The problem is that if we continue, successive reads may all take >> seconds or minutes to fail, thus tieing up the process for a long >> time. > > Sorry, I don't understand where the

[PATCH] ext4: Return EIO on read error in ext4_find_entry

2017-06-22 Thread Khazhismel Kumykov
Previously, a read error would be ignored and we would eventually return NULL from ext4_find_entry, which signals "no such file or directory". We should be returning EIO. Signed-off-by: Khazhismel Kumykov --- fs/ext4/namei.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-06-12 Thread Khazhismel Kumykov
On Fri, Jun 2, 2017 at 11:47 PM, Khazhismel Kumykov wrote: > On Fri, Jun 2, 2017 at 11:20 PM, Al Viro wrote: >> The thing is, unlike shrink_dcache_parent() we *can* bugger off as >> soon as we'd found no victims, nothing mounted and dentry itself >> is unhashed

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-06-02 Thread Khazhismel Kumykov
On Fri, Jun 2, 2017 at 11:20 PM, Al Viro wrote: > The thing is, unlike shrink_dcache_parent() we *can* bugger off as > soon as we'd found no victims, nothing mounted and dentry itself > is unhashed. We can't do anything in select_collect() (we would've > broken shrink_dcache_parent() that way), b

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-06-02 Thread Khazhismel Kumykov
On Fri, Jun 2, 2017 at 6:12 PM, Al Viro wrote: > Part of that could be relieved if we turned check_and_drop() into > static void check_and_drop(void *_data) > { > struct detach_data *data = _data; > > if (!data->mountpoint && list_empty(&data->select.dispose)) > __d

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-05-25 Thread Khazhismel Kumykov
On Mon, May 22, 2017 at 11:18 AM, Khazhismel Kumykov wrote: > On Wed, May 17, 2017 at 2:58 PM Khazhismel Kumykov wrote: >> >> On Mon, May 15, 2017 at 5:05 PM, Khazhismel Kumykov >> wrote: >> > Hi, >> > >> > I'm seeing behavior in d_inval

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-05-22 Thread Khazhismel Kumykov
On Wed, May 17, 2017 at 2:58 PM Khazhismel Kumykov wrote: > > On Mon, May 15, 2017 at 5:05 PM, Khazhismel Kumykov wrote: > > Hi, > > > > I'm seeing behavior in d_invalidate, if multiple threads call d_invalidate > > on > > the same tree at the same, beha

Re: Hang/soft lockup in d_invalidate with simultaneous calls

2017-05-17 Thread Khazhismel Kumykov
On Mon, May 15, 2017 at 5:05 PM, Khazhismel Kumykov wrote: > Hi, > > I'm seeing behavior in d_invalidate, if multiple threads call d_invalidate on > the same tree at the same, behavior time blows up and all the calls hang with > large enough trees/enough simultaneous callers.

Hang/soft lockup in d_invalidate with simultaneous calls

2017-05-15 Thread Khazhismel Kumykov
Hi, I'm seeing behavior in d_invalidate, if multiple threads call d_invalidate on the same tree at the same, behavior time blows up and all the calls hang with large enough trees/enough simultaneous callers. (e.g. a directory w/ 100k entries in d_subdir, and 5 or so threads calling d_invalidate wa