Re: [RFC v2 16/83] Initialize block map and free lists in nova_init().

On 10.03.2018 20:17, Andiry Xu wrote: > From: Andiry Xu > > NOVA divides the pmem range equally among per-CPU free lists, > and format the red-black trees by inserting the initial free range. > > Signed-off-by: Andiry Xu > --- > fs/nova/balloc.c | 161

Re: [RFC v2 16/83] Initialize block map and free lists in nova_init().

On 10.03.2018 20:17, Andiry Xu wrote: > From: Andiry Xu > > NOVA divides the pmem range equally among per-CPU free lists, > and format the red-black trees by inserting the initial free range. > > Signed-off-by: Andiry Xu > --- > fs/nova/balloc.c | 161 >

Re: [RFC v2 05/83] Add NOVA filesystem definitions and useful helper routines.

[Adding Herbert Xu to CC since he is the maintainer of the crypto subsys maintainer] On 10.03.2018 20:17, Andiry Xu wrote: > +static inline u32 nova_crc32c(u32 crc, const u8 *data, size_t len) > +{ > + u8 *ptr = (u8 *) data; > + u64 acc = crc; /* accumulator, crc32c value in lower 32b

Re: [RFC v2 05/83] Add NOVA filesystem definitions and useful helper routines.

[Adding Herbert Xu to CC since he is the maintainer of the crypto subsys maintainer] On 10.03.2018 20:17, Andiry Xu wrote: > +static inline u32 nova_crc32c(u32 crc, const u8 *data, size_t len) > +{ > + u8 *ptr = (u8 *) data; > + u64 acc = crc; /* accumulator, crc32c value in lower 32b

Re: [RFC v2 14/83] Add range node kmem cache.

On 10.03.2018 20:17, Andiry Xu wrote: > From: Andiry Xu > > Range node specifies a range of [start, end]. and is managed by a red-black > tree. > NOVA uses range node to manage NVM allocator and inodes being used. > > Signed-off-by: Andiry Xu > --- >

Re: [RFC v2 14/83] Add range node kmem cache.

On 10.03.2018 20:17, Andiry Xu wrote: > From: Andiry Xu > > Range node specifies a range of [start, end]. and is managed by a red-black > tree. > NOVA uses range node to manage NVM allocator and inodes being used. > > Signed-off-by: Andiry Xu > --- > fs/nova/nova.h | 8 >

[RFC PATCH] btrfs: Fix memory ordering of unlocked dio reads vs truncate

Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- Hello, Sending it as an RFC for the time being to see how people are going to react and also I'd like some feedback on the mb semantics. For this purposed I've CC'ed some memory ordering people :) fs/btrfs/btrfs_inode.

[RFC PATCH] btrfs: Fix memory ordering of unlocked dio reads vs truncate

Signed-off-by: Nikolay Borisov --- Hello, Sending it as an RFC for the time being to see how people are going to react and also I'd like some feedback on the mb semantics. For this purposed I've CC'ed some memory ordering people :) fs/btrfs/btrfs_inode.h | 17 - fs/btrfs

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 3.03.2018 02:24, Andrew Morton wrote: > On Mon, 26 Feb 2018 11:54:30 +0200 Nikolay Borisov <nbori...@suse.com> wrote: > >> We already get the block counts and the calculate the end block at the >> beginning of the function. Let's use the local variables for consis

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 3.03.2018 02:24, Andrew Morton wrote: > On Mon, 26 Feb 2018 11:54:30 +0200 Nikolay Borisov wrote: > >> We already get the block counts and the calculate the end block at the >> beginning of the function. Let's use the local variables for consistency and >> re

Re: GPF in wb_congested due to null bdi_writeback

On 27.02.2018 18:05, Nikolay Borisov wrote: > Hello Tejun, > > So while running some fs tests I hit the following GPF. Btw the > warning taint flag was due to a debugging WARN_ON in btrfs 100 or so > tests ago so is unrelated to this gpf: > > [ 4255.628110] general p

Re: GPF in wb_congested due to null bdi_writeback

On 27.02.2018 18:05, Nikolay Borisov wrote: > Hello Tejun, > > So while running some fs tests I hit the following GPF. Btw the > warning taint flag was due to a debugging WARN_ON in btrfs 100 or so > tests ago so is unrelated to this gpf: > > [ 4255.628110] general p

GPF in wb_congested due to null bdi_writeback

Hello Tejun, So while running some fs tests I hit the following GPF. Btw the warning taint flag was due to a debugging WARN_ON in btrfs 100 or so tests ago so is unrelated to this gpf: [ 4255.628110] general protection fault: [#1] SMP PTI [ 4255.628303] Modules linked in: [ 4255.628446]

GPF in wb_congested due to null bdi_writeback

Hello Tejun, So while running some fs tests I hit the following GPF. Btw the warning taint flag was due to a debugging WARN_ON in btrfs 100 or so tests ago so is unrelated to this gpf: [ 4255.628110] general protection fault: [#1] SMP PTI [ 4255.628303] Modules linked in: [ 4255.628446]

[PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

We already get the block counts and the calculate the end block at the beginning of the function. Let's use the local variables for consistency and readability. No functional changes Signed-off-by: Nikolay Borisov <nbori...@suse.com> Reviewed-by: Jeff Moyer <jmo...@redhat.com>

[PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

We already get the block counts and the calculate the end block at the beginning of the function. Let's use the local variables for consistency and readability. No functional changes Signed-off-by: Nikolay Borisov Reviewed-by: Jeff Moyer --- Andrew, Sending to you since this has been

Re: Reasoning about memory ordering

On 23.02.2018 19:31, Andrea Parri wrote: > On Fri, Feb 23, 2018 at 02:30:22PM +0200, Nikolay Borisov wrote: >> Hello, >> >> I'm cc'ing a bunch of people I know are well-versed in >> the black arts of memory ordering! >> >> Currently in btrfs we have ro

Re: Reasoning about memory ordering

On 23.02.2018 19:31, Andrea Parri wrote: > On Fri, Feb 23, 2018 at 02:30:22PM +0200, Nikolay Borisov wrote: >> Hello, >> >> I'm cc'ing a bunch of people I know are well-versed in >> the black arts of memory ordering! >> >> Currently in btrfs we have ro

Re: Reasoning about memory ordering

On 23.02.2018 17:38, Alan Cox wrote: >> Given this is the current state of the code (it's part of btrfs) I believe >> the following could/should be done: > > Is there benchmarking data to show that a custom lock is justified > (especiaally given it's going to mean btrfs and rtlinux don't play

Re: Reasoning about memory ordering

On 23.02.2018 17:38, Alan Cox wrote: >> Given this is the current state of the code (it's part of btrfs) I believe >> the following could/should be done: > > Is there benchmarking data to show that a custom lock is justified > (especiaally given it's going to mean btrfs and rtlinux don't play

Reasoning about memory ordering

Hello, I'm cc'ing a bunch of people I know are well-versed in the black arts of memory ordering! Currently in btrfs we have roughly the following sequence: T1: T2: i_size_write(inode,

Reasoning about memory ordering

Hello, I'm cc'ing a bunch of people I know are well-versed in the black arts of memory ordering! Currently in btrfs we have roughly the following sequence: T1: T2: i_size_write(inode,

[PATCH 1/2] direct-io: Remove unused DIO_ASYNC_EXTEND flag

This flag was added by 6039257378e4 ("direct-io: add flag to allow aio writes beyond i_size") to support XFS. However, with the rework of XFS' DIO's path to use iomap in acdda3aae146 ("xfs: use iomap_dio_rw") it became redundant. So let's remove it. Signed-off-by: Ni

[PATCH 2/2] direct-io: Remove unused DIO_SKIP_DIO_COUNT logic

unused. So let's remove it. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- fs/direct-io.c | 6 ++ include/linux/fs.h | 3 --- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index 99a81c49bce9..a8131087aa1c 100644 --- a/fs/dir

[PATCH 1/2] direct-io: Remove unused DIO_ASYNC_EXTEND flag

This flag was added by 6039257378e4 ("direct-io: add flag to allow aio writes beyond i_size") to support XFS. However, with the rework of XFS' DIO's path to use iomap in acdda3aae146 ("xfs: use iomap_dio_rw") it became redundant. So let's remove it. Signed-off-by: Nikolay Bor

[PATCH 2/2] direct-io: Remove unused DIO_SKIP_DIO_COUNT logic

unused. So let's remove it. Signed-off-by: Nikolay Borisov --- fs/direct-io.c | 6 ++ include/linux/fs.h | 3 --- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index 99a81c49bce9..a8131087aa1c 100644 --- a/fs/direct-io.c +++ b/fs/direc

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 2.08.2017 10:10, Nikolay Borisov wrote: > We already get the block counts and the calculate the end block at the > beginning of the function. Let's use the local variables for consistency and > readability. No functional changes > > Signed-off-by: Nikolay Borisov <

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 2.08.2017 10:10, Nikolay Borisov wrote: > We already get the block counts and the calculate the end block at the > beginning of the function. Let's use the local variables for consistency and > readability. No functional changes > > Signed-off-by: Nikolay Borisov > ---

[tip:locking/core] memory-barriers: Fix description of data dependency barriers

Commit-ID: 51de78892b1294d1521c41226a5ef215a910c25f Gitweb: https://git.kernel.org/tip/51de78892b1294d1521c41226a5ef215a910c25f Author: Nikolay Borisov <nbori...@suse.com> AuthorDate: Tue, 20 Feb 2018 15:25:08 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed,

[tip:locking/core] memory-barriers: Fix description of data dependency barriers

Commit-ID: 51de78892b1294d1521c41226a5ef215a910c25f Gitweb: https://git.kernel.org/tip/51de78892b1294d1521c41226a5ef215a910c25f Author: Nikolay Borisov AuthorDate: Tue, 20 Feb 2018 15:25:08 -0800 Committer: Ingo Molnar CommitDate: Wed, 21 Feb 2018 09:58:14 +0100 memory-barriers: Fix

[PATCH] memory-barriers: Make sentence more clear.

Rewrite the final sentence of data dependency memory barrier to express the 'after' relationship in simpler words. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/

[PATCH] memory-barriers: Make sentence more clear.

Rewrite the final sentence of data dependency memory barrier to express the 'after' relationship in simpler words. Signed-off-by: Nikolay Borisov --- Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/memory-barriers.txt b

[PATCH] fs: Improve comment of inode_dio_begin

the requirement of a lock being held while bumping i_dio_count. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- include/linux/fs.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index 511fbaabf624..90ac851930ae

[PATCH] fs: Improve comment of inode_dio_begin

the requirement of a lock being held while bumping i_dio_count. Signed-off-by: Nikolay Borisov --- include/linux/fs.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index 511fbaabf624..90ac851930ae 100644 --- a/include/linux/fs.h +++ b

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

On 8.02.2018 13:43, Tetsuo Handa wrote: >>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. > > Dave Jones reported

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

On 8.02.2018 13:43, Tetsuo Handa wrote: >>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. > > Dave Jones reported fs_reclaim lockdep warnings. > >

Re: [PATCH] net: bridge: Fix uninitialized error in br_fdb_sync_static()

t ndmsg *ndm, struct nlattr *tb[], > int br_fdb_sync_static(struct net_bridge *br, struct net_bridge_port *p) > { > struct net_bridge_fdb_entry *f, *tmp; > - int err; > + int err = 0; > > ASSERT_RTNL(); > > Thanks, Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH] net: bridge: Fix uninitialized error in br_fdb_sync_static()

, > int br_fdb_sync_static(struct net_bridge *br, struct net_bridge_port *p) > { > struct net_bridge_fdb_entry *f, *tmp; > - int err; > + int err = 0; > > ASSERT_RTNL(); > > Thanks, Acked-by: Nikolay Aleksandrov

Re: [PATCH 0/3] ftrace, orc, x86, tracing: Fix stack traces again

On 23.01.2018 20:32, Steven Rostedt wrote: > With the new ORC unwinder, ftrace stack tracing became disfunctional. > > One was that ORC didn't know how to handle the ftrace callbacks in > general (which Josh fixed). The other was that ORC would just bail > if it hit a dynamically allocated

Re: [PATCH 0/3] ftrace, orc, x86, tracing: Fix stack traces again

On 23.01.2018 20:32, Steven Rostedt wrote: > With the new ORC unwinder, ftrace stack tracing became disfunctional. > > One was that ORC didn't know how to handle the ftrace callbacks in > general (which Josh fixed). The other was that ORC would just bail > if it hit a dynamically allocated

Re: [RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

On 23.01.2018 01:16, Steven Rostedt wrote: > On Mon, 22 Jan 2018 15:50:04 +0200 > Nikolay Borisov <nbori...@suse.com> wrote: > > >> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c >> index 27f7ad12c4b1..b721f1f3f3c0 100644 >>

Re: [RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

On 23.01.2018 01:16, Steven Rostedt wrote: > On Mon, 22 Jan 2018 15:50:04 +0200 > Nikolay Borisov wrote: > > >> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c >> index 27f7ad12c4b1..b721f1f3f3c0 100644 >> --- a/kernel/trace/trace_fun

[RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

ilp_open (811b8a8a) => do_sys_open (811a64a7) => SyS_open (811a659e) => entry_SYSCALL_64_fastpath (8180009b) Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- Strange why __trace_stack and __ftrace_trace_stack are not part of the stack an

[RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

ilp_open (811b8a8a) => do_sys_open (811a64a7) => SyS_open (811a659e) => entry_SYSCALL_64_fastpath (8180009b) Signed-off-by: Nikolay Borisov --- Strange why __trace_stack and __ftrace_trace_stack are not part of the stack and don't need to be filtered,

Re: Linux 4.15-rc7

On 11.01.2018 13:29, Olivier Galibert wrote: > Wasn't/Isn't the 4G/4G memory layout for 32 bits essentially KPTI? 4g/4g was never accepted upstream > > OG. > > > On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek wrote: >> Hi! >> >>> The one thing I want to do now that

Re: Linux 4.15-rc7

On 11.01.2018 13:29, Olivier Galibert wrote: > Wasn't/Isn't the 4G/4G memory layout for 32 bits essentially KPTI? 4g/4g was never accepted upstream > > OG. > > > On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek wrote: >> Hi! >> >>> The one thing I want to do now that Meltdown and Spectre

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

On 8.01.2018 12:21, Timofey Titovets wrote: > 2018-01-08 12:45 GMT+03:00 Nikolay Borisov <nbori...@suse.com>: >> So here is a small 2 patch set which removes btrfs' manual initialisation of >> the lower level crc32c module. Explanation why is ok can be found in Patch &g

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

On 8.01.2018 12:21, Timofey Titovets wrote: > 2018-01-08 12:45 GMT+03:00 Nikolay Borisov : >> So here is a small 2 patch set which removes btrfs' manual initialisation of >> the lower level crc32c module. Explanation why is ok can be found in Patch >> 2/2. >> >&g

[PATCH 2/2] btrfs: Remove custom crc32c init code

y btrfs was switched to late_initcall which comes after the generic crc32c implementation is initiliased. The latter commit superseeded the former. Now that we don't have to maintain our own code let's just remove it and switch to using the generic implementation. Signed-off-by: Nikolay Boriso

[PATCH 2/2] btrfs: Remove custom crc32c init code

y btrfs was switched to late_initcall which comes after the generic crc32c implementation is initiliased. The latter commit superseeded the former. Now that we don't have to maintain our own code let's just remove it and switch to using the generic implementation. Signed-off-by: Nikolay Borisov -

[PATCH 0/2] Remove custom crc32c init code from btrfs

or hw-accelerated) to retain current btrfs behavior. This is mainly used for debugging purposes and is independent. Nikolay Borisov (2): libcrc32c: Add crc32c_impl function btrfs: Remove custom crc32c init code fs/btrfs/Kconfig | 3 +-- fs/btrfs/Makefile | 2 +- fs/btrfs

[PATCH 0/2] Remove custom crc32c init code from btrfs

or hw-accelerated) to retain current btrfs behavior. This is mainly used for debugging purposes and is independent. Nikolay Borisov (2): libcrc32c: Add crc32c_impl function btrfs: Remove custom crc32c init code fs/btrfs/Kconfig | 3 +-- fs/btrfs/Makefile | 2 +- fs/btrfs

[PATCH 1/2] libcrc32c: Add crc32c_impl function

This function returns a string with the currently in-use implementation of the crc32c algorithm, i.e crc32c-generic (for unoptimised, generic implementation) or crc32c-intel for the sse optimised version. This will be used by btrfs. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- i

[PATCH 1/2] libcrc32c: Add crc32c_impl function

This function returns a string with the currently in-use implementation of the crc32c algorithm, i.e crc32c-generic (for unoptimised, generic implementation) or crc32c-intel for the sse optimised version. This will be used by btrfs. Signed-off-by: Nikolay Borisov --- include/linux/crc32c.h | 1

Re: Bricked x86 CPU with software?

On 4.01.2018 02:47, Tim Mouraveiko wrote: > Hi, > > In all my years of extensive experience writing drivers and kernels, I never > came across a situation > where you could brick an x86 CPU. Not until recently, when I was working on > debugging a piece of > code and I bricked an Intel CPU.

Re: Bricked x86 CPU with software?

On 4.01.2018 02:47, Tim Mouraveiko wrote: > Hi, > > In all my years of extensive experience writing drivers and kernels, I never > came across a situation > where you could brick an x86 CPU. Not until recently, when I was working on > debugging a piece of > code and I bricked an Intel CPU.

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 12:40, Nikolay Aleksandrov wrote: > On 16/12/17 11:29, Nikolay Aleksandrov wrote: >> On 16/12/17 11:17, Nikolay Aleksandrov wrote: >>> On 16/12/17 02:37, Andrei Vagin wrote: >>>> Hi, >>>> >>>> We run criu tests for linux-next a

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 12:40, Nikolay Aleksandrov wrote: > On 16/12/17 11:29, Nikolay Aleksandrov wrote: >> On 16/12/17 11:17, Nikolay Aleksandrov wrote: >>> On 16/12/17 02:37, Andrei Vagin wrote: >>>> Hi, >>>> >>>> We run criu tests for linux-next a

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:29, Nikolay Aleksandrov wrote: > On 16/12/17 11:17, Nikolay Aleksandrov wrote: >> On 16/12/17 02:37, Andrei Vagin wrote: >>> Hi, >>> >>> We run criu tests for linux-next and today we get this bug: >>> >>> The kernel version

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:29, Nikolay Aleksandrov wrote: > On 16/12/17 11:17, Nikolay Aleksandrov wrote: >> On 16/12/17 02:37, Andrei Vagin wrote: >>> Hi, >>> >>> We run criu tests for linux-next and today we get this bug: >>> >>> The kernel version

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:17, Nikolay Aleksandrov wrote: > On 16/12/17 02:37, Andrei Vagin wrote: >> Hi, >> >> We run criu tests for linux-next and today we get this bug: >> >> The kernel version is 4.15.0-rc3-next-20171215 >> >> [ 235.397328] BUG: una

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:17, Nikolay Aleksandrov wrote: > On 16/12/17 02:37, Andrei Vagin wrote: >> Hi, >> >> We run criu tests for linux-next and today we get this bug: >> >> The kernel version is 4.15.0-rc3-next-20171215 >> >> [ 235.397328] BUG: una

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 02:37, Andrei Vagin wrote: > Hi, > > We run criu tests for linux-next and today we get this bug: > > The kernel version is 4.15.0-rc3-next-20171215 > > [ 235.397328] BUG: unable to handle kernel NULL pointer dereference > at 000c > [ 235.398624] IP:

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 02:37, Andrei Vagin wrote: > Hi, > > We run criu tests for linux-next and today we get this bug: > > The kernel version is 4.15.0-rc3-next-20171215 > > [ 235.397328] BUG: unable to handle kernel NULL pointer dereference > at 000c > [ 235.398624] IP:

Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

On 11.12.2017 18:00, Scott Bauer wrote: > Signed-off-by: Scott Bauer > --- > Documentation/device-mapper/dm-unstripe.txt | 82 > + > 1 file changed, 82 insertions(+) > create mode 100644 Documentation/device-mapper/dm-unstripe.txt > > diff

Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

On 11.12.2017 18:00, Scott Bauer wrote: > Signed-off-by: Scott Bauer > --- > Documentation/device-mapper/dm-unstripe.txt | 82 > + > 1 file changed, 82 insertions(+) > create mode 100644 Documentation/device-mapper/dm-unstripe.txt > > diff --git

Re: [PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

On 9.12.2017 21:25, Tejun Heo wrote: > After the recent updates to use generation number and state based > synchronization, we can easily replace REQ_ATOM_STARTED usages by > adding an extra state to distinguish completed but not yet freed > state. > > Add MQ_RQ_COMPLETE and replace

Re: [PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

On 9.12.2017 21:25, Tejun Heo wrote: > After the recent updates to use generation number and state based > synchronization, we can easily replace REQ_ATOM_STARTED usages by > adding an extra state to distinguish completed but not yet freed > state. > > Add MQ_RQ_COMPLETE and replace

Re: [PATCH 0/8] make some functions return bool

On 12.12.2017 09:21, Yaowei Bai wrote: > On Mon, Dec 11, 2017 at 09:50:03PM -0800, David Rientjes wrote: >> On Mon, 11 Dec 2017, Yaowei Bai wrote: >> >>> This patchset makes some *_is_* like functions return bool because >>> these functions only use true or false as their return values. >>> >>>

Re: [PATCH 0/8] make some functions return bool

On 12.12.2017 09:21, Yaowei Bai wrote: > On Mon, Dec 11, 2017 at 09:50:03PM -0800, David Rientjes wrote: >> On Mon, 11 Dec 2017, Yaowei Bai wrote: >> >>> This patchset makes some *_is_* like functions return bool because >>> these functions only use true or false as their return values. >>> >>>

Re: [PATCH 3/3] VFS: close race between getcwd() and d_move()

On 9.11.2017 15:08, Matthew Wilcox wrote: > On Thu, Nov 09, 2017 at 01:41:24PM +0200, Nikolay Borisov wrote: >> On 9.11.2017 05:22, NeilBrown wrote: >>> @@ -493,12 +496,18 @@ void __d_drop(struct dentry *dentry) >>> } else >>>

Re: [PATCH 3/3] VFS: close race between getcwd() and d_move()

On 9.11.2017 15:08, Matthew Wilcox wrote: > On Thu, Nov 09, 2017 at 01:41:24PM +0200, Nikolay Borisov wrote: >> On 9.11.2017 05:22, NeilBrown wrote: >>> @@ -493,12 +496,18 @@ void __d_drop(struct dentry *dentry) >>> } else >>>

Re: [PATCH 3/3] VFS: close race between getcwd() and d_move()

On 9.11.2017 05:22, NeilBrown wrote: > d_move() will call __d_drop() and then __d_rehash() > on the dentry being moved. This creates a small window > when the dentry appears to be unhashed. Many tests > of d_unhashed() are made under ->d_lock and so are safe > from racing with this window,

Re: [PATCH 3/3] VFS: close race between getcwd() and d_move()

On 9.11.2017 05:22, NeilBrown wrote: > d_move() will call __d_drop() and then __d_rehash() > on the dentry being moved. This creates a small window > when the dentry appears to be unhashed. Many tests > of d_unhashed() are made under ->d_lock and so are safe > from racing with this window,

Re: [PATCH 3/5] userns: Don't read extents twice in m_start

[CCing some memory-barriers people + checkpatch maintainers] On 1.11.2017 13:08, Eric W. Biederman wrote: > Nikolay Borisov <nbori...@suse.com> writes: > >> On 1.11.2017 01:48, Eric W. Biederman wrote: >>> >>> This is important so reading /proc//{uid_map,g

Re: [PATCH 3/5] userns: Don't read extents twice in m_start

[CCing some memory-barriers people + checkpatch maintainers] On 1.11.2017 13:08, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> On 1.11.2017 01:48, Eric W. Biederman wrote: >>> >>> This is important so reading /proc//{uid_map,gid_map,projid_map} whil

Re: [PATCH 3/5] userns: Don't read extents twice in m_start

On 1.11.2017 01:48, Eric W. Biederman wrote: > > This is important so reading /proc//{uid_map,gid_map,projid_map} while > the map is being written does not do strange things. > > Signed-off-by: "Eric W. Biederman" > --- > kernel/user_namespace.c | 6 -- > 1 file

Re: [PATCH 3/5] userns: Don't read extents twice in m_start

On 1.11.2017 01:48, Eric W. Biederman wrote: > > This is important so reading /proc//{uid_map,gid_map,projid_map} while > the map is being written does not do strange things. > > Signed-off-by: "Eric W. Biederman" > --- > kernel/user_namespace.c | 6 -- > 1 file changed, 4

Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct

On 23.10.2017 09:39, Nikolay Borisov wrote: > > > On 19.10.2017 22:11, Christian Brauner wrote: >> - Add a struct containing two pointer to extents and wrap both the static >> extent >> array and the struct into a union. This is done in preparation for bumping &g

Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct

On 23.10.2017 09:39, Nikolay Borisov wrote: > > > On 19.10.2017 22:11, Christian Brauner wrote: >> - Add a struct containing two pointer to extents and wrap both the static >> extent >> array and the struct into a union. This is done in preparation for bumping &g

Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct

On 19.10.2017 22:11, Christian Brauner wrote: > - Add a struct containing two pointer to extents and wrap both the static > extent > array and the struct into a union. This is done in preparation for bumping > the > {g,u}idmap limits for user namespaces. > - Add brackets around anonymous

Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct

On 19.10.2017 22:11, Christian Brauner wrote: > - Add a struct containing two pointer to extents and wrap both the static > extent > array and the struct into a union. This is done in preparation for bumping > the > {g,u}idmap limits for user namespaces. > - Add brackets around anonymous

Re: [PATCH] btrfs: use appropriate replacements for __sb_{start,end}_write calls

On 10.10.2017 13:48, Rakesh Pandit wrote: > Commit a53f4f8e9c8eb ("btrfs: Don't call btrfs_start_transaction() on > frozen fs to avoid deadlock.") started using internal calls and we > replace them with more suitable ones. > > Signed-off-by: Rakesh Pandit > --- >

Re: [PATCH] btrfs: use appropriate replacements for __sb_{start,end}_write calls

On 10.10.2017 13:48, Rakesh Pandit wrote: > Commit a53f4f8e9c8eb ("btrfs: Don't call btrfs_start_transaction() on > frozen fs to avoid deadlock.") started using internal calls and we > replace them with more suitable ones. > > Signed-off-by: Rakesh Pandit > --- > fs/btrfs/super.c | 4 ++-- >

Re: [PATCH] btrfs: use appropriate replacements for __sb_{start,end}_write calls

action(root, 0); The non __ versions are just wrappers around the __ specific calls. So the code is identical. Reviewed-by: Nikolay Borisov <nbori...@suse.com>

Re: [PATCH] btrfs: use appropriate replacements for __sb_{start,end}_write calls

versions are just wrappers around the __ specific calls. So the code is identical. Reviewed-by: Nikolay Borisov

Re: [PATCH 03/12] buffer: eliminate the need to call free_more_memory() in __getblk_slow()

also the last user of free_more_memory(), kill > it off completely. > > Signed-off-by: Jens Axboe <ax...@kernel.dk> Reviewed-by: Nikolay Borisov <nbori...@suse.com> > --- > fs/buffer.c | 23 --- > 1 file changed, 23 deletions(-) > > diff

Re: [PATCH 03/12] buffer: eliminate the need to call free_more_memory() in __getblk_slow()

also the last user of free_more_memory(), kill > it off completely. > > Signed-off-by: Jens Axboe Reviewed-by: Nikolay Borisov > --- > fs/buffer.c | 23 --- > 1 file changed, 23 deletions(-) > > diff --git a/fs/buffer.c b/fs/buffer.c > index 3b60cd84

Re: [PATCH 01/12] buffer: have alloc_page_buffers() use __GFP_NOFAIL

igned-off-by: Jens Axboe <ax...@kernel.dk> Reviewed-by: Nikolay Borisov <nbori...@suse.com> > --- > drivers/md/bitmap.c | 2 +- > fs/buffer.c | 33 ++--- > fs/ntfs/aops.c | 2 +- > fs/ntfs/mft.c

Re: [PATCH 01/12] buffer: have alloc_page_buffers() use __GFP_NOFAIL

igned-off-by: Jens Axboe Reviewed-by: Nikolay Borisov > --- > drivers/md/bitmap.c | 2 +- > fs/buffer.c | 33 ++--- > fs/ntfs/aops.c | 2 +- > fs/ntfs/mft.c | 2 +- > include/linux/buffer_head.h | 2

Re: [PATCH 02/12] buffer: grow_dev_page() should use __GFP_NOFAIL for all cases

On 27.09.2017 23:13, Jens Axboe wrote: > We currently it it for find_or_create_page(), which means that it nit: Perhaps you wanted to write "We currently use it for find_..." otherwise: Reviewed-by: Nikolay Borisov <nbori...@suse.com> > cannot fail. Ensure we also

Re: [PATCH 02/12] buffer: grow_dev_page() should use __GFP_NOFAIL for all cases

On 27.09.2017 23:13, Jens Axboe wrote: > We currently it it for find_or_create_page(), which means that it nit: Perhaps you wanted to write "We currently use it for find_..." otherwise: Reviewed-by: Nikolay Borisov > cannot fail. Ensure we also pass i

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 2.08.2017 10:10, Nikolay Borisov wrote: > We already get the block counts and the calculate the end block at the > beginning of the function. Let's use the local variables for consistency and > readability. No functional changes > > Signed-off-by: Nikolay Borisov <

Re: [PATCH] direct-io: Minor cleanups in do_blockdev_direct_IO

On 2.08.2017 10:10, Nikolay Borisov wrote: > We already get the block counts and the calculate the end block at the > beginning of the function. Let's use the local variables for consistency and > readability. No functional changes > > Signed-off-by: Nikolay Borisov > ---

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

On 11 September 2017 19:07:33 EEST, "Mahesh Bandewar (महेश बंडेवार)" <mahe...@google.com> wrote: >On Sat, Sep 9, 2017 at 4:28 AM, Nikolay Aleksandrov ><niko...@cumulusnetworks.com> wrote: >> On 07/09/17 01:47, Kosuke Tatsukawa wrote: >>> Commit cbf

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

On 11 September 2017 19:07:33 EEST, "Mahesh Bandewar (महेश बंडेवार)" wrote: >On Sat, Sep 9, 2017 at 4:28 AM, Nikolay Aleksandrov > wrote: >> On 07/09/17 01:47, Kosuke Tatsukawa wrote: >>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > This fix is simpler and more suitable for -net, it fixes the case where we switch to ALB mode with tlb_dynamic_lb = 0. After it is in I'll fix the default tlb_dynamic_lb issue and restore the original behaviour. Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

s(+), 0 deletions(-) > This fix is simpler and more suitable for -net, it fixes the case where we switch to ALB mode with tlb_dynamic_lb = 0. After it is in I'll fix the default tlb_dynamic_lb issue and restore the original behaviour. Acked-by: Nikolay Aleksandrov

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

On 09/09/17 13:29, Nikolay Aleksandrov wrote: > On 09/09/17 02:54, Mahesh Bandewar (महेश बंडेवार) wrote: >> On Fri, Sep 8, 2017 at 7:30 AM, Nikolay Aleksandrov >> <niko...@cumulusnetworks.com> wrote: >>> On 08/09/17 17:17, Kosuke Tatsukawa wrote: [snip] >&

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

On 09/09/17 13:29, Nikolay Aleksandrov wrote: > On 09/09/17 02:54, Mahesh Bandewar (महेश बंडेवार) wrote: >> On Fri, Sep 8, 2017 at 7:30 AM, Nikolay Aleksandrov >> wrote: >>> On 08/09/17 17:17, Kosuke Tatsukawa wrote: [snip] >>> >> I think the underlying iss

<    1   2   3   4   5   6   7   8   9   10   >