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
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:
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(
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/
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
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(
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
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
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
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);
> > +
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
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
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).
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
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
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
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
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 +
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
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
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
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
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
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
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
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
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
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
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
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
) -> 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
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
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
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
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
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
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
(Botched the to line, sorry)
smime.p7s
Description: S/MIME Cryptographic Signature
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
: 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
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.
>
>
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
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
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
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
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
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
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
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
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(-)
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
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
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
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
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
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.
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
57 matches
Mail list logo
