Re: [RFC PATCH 1/4] fs: new infrastructure for writeback error handling and reporting

On 31.03.2017 22:26, Jeff Layton wrote: > Most filesystems currently use mapping_set_error and > filemap_check_errors for setting and reporting/clearing writeback errors > at the mapping level. filemap_check_errors is indirectly called from > most of the filemap_fdatawait_* functions and from >

Re: [PATCHv2] fs: Handle register_shrinker failure

On 24.03.2017 10:25, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object. This &

Re: [PATCHv2] fs: Handle register_shrinker failure

On 24.03.2017 10:25, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object. This &

[PATCH] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- fs/super.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/sup

[PATCH] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov --- fs/super.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/super.c b/fs/super.c in

[PATCHv2] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov <nbori...@suse.com> Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Link: lkml.kernel.org/r

[PATCHv2] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Link: lkml.kernel.org/r/CACT4Y+b-purC3HHbw=sctms3ma8fkqtnyz

[PATCH] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- fs/super.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/sup

[PATCH] fs: Handle register_shrinker failure

red is referenced. Fix this by failing to register the filesystem in case there is not enough memory to fully construct the shrinker object. Signed-off-by: Nikolay Borisov --- fs/super.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/super.c b/fs/super.c in

Re: kasan behavior when built with unsupported compiler

On 9.03.2017 11:46, Andrey Ryabinin wrote: > On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > >> >> So apparently this is indeed a false positive, resulting from using the old >> compiler. I used the attached patch to verify it. >> >> And what it prints is

Re: kasan behavior when built with unsupported compiler

On 9.03.2017 11:46, Andrey Ryabinin wrote: > On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > >> >> So apparently this is indeed a false positive, resulting from using the old >> compiler. I used the attached patch to verify it. >> >> And what it prints is

Re: Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 9.03.2017 03:58, Theodore Ts'o wrote: > On Tue, Mar 07, 2017 at 10:40:53PM +0200, Nikolay Borisov wrote: >> So this is wrong, the reason why the issues seemed fix is because I >> switched my compiler to version 5.4.0. So this manifests only if I'm >> using gcc 4.7.4. W

Re: Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 9.03.2017 03:58, Theodore Ts'o wrote: > On Tue, Mar 07, 2017 at 10:40:53PM +0200, Nikolay Borisov wrote: >> So this is wrong, the reason why the issues seemed fix is because I >> switched my compiler to version 5.4.0. So this manifests only if I'm >> using gcc 4.7.4. W

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 17:54, Dmitry Vyukov wrote: > On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov > <n.borisov.l...@gmail.com> wrote: >> Hello, >> >> I've been chasing a particular UAF as reported by kasan >> (https://www.spinics.net/lists/kernel/msg2458136.html)

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 17:54, Dmitry Vyukov wrote: > On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov > wrote: >> Hello, >> >> I've been chasing a particular UAF as reported by kasan >> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >> thing

Re: net: BUG in unix_notinflight

>> >> >> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9 >> >> [ cut here ] >> kernel BUG at net/unix/garbage.c:149! >> invalid opcode: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 1806

Re: net: BUG in unix_notinflight

>> >> >> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9 >> >> [ cut here ] >> kernel BUG at net/unix/garbage.c:149! >> invalid opcode: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 1806

Re: Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 7.03.2017 16:33, Nikolay Borisov wrote: > > > On 7.03.2017 11:38, Nikolay Borisov wrote: >> >> >> On 7.03.2017 00:35, Rafael J. Wysocki wrote: >>> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov >>> <n.borisov.l...@gmail.com> wrote

Re: Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 7.03.2017 16:33, Nikolay Borisov wrote: > > > On 7.03.2017 11:38, Nikolay Borisov wrote: >> >> >> On 7.03.2017 00:35, Rafael J. Wysocki wrote: >>> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov >>> wrote: >>>> Hello, >&g

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 19:51, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov > <n.borisov.l...@gmail.com> wrote: >> >> >> On 7.03.2017 18:05, Alexander Potapenko wrote: >>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyu...@g

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 19:51, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov > wrote: >> >> >> On 7.03.2017 18:05, Alexander Potapenko wrote: >>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov wrote: >>>> On Tue, Mar 7,

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 18:05, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >> <n.borisov.l...@gmail.com> wrote: >>> Hello, >>> >>> I

Re: kasan behavior when built with unsupported compiler

On 7.03.2017 18:05, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov wrote: >> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >> wrote: >>> Hello, >>> >>> I've been chasing a particular UAF as reported by kasan >>&g

kasan behavior when built with unsupported compiler

. Is this valid behavior ? Regards, Nikolay

kasan behavior when built with unsupported compiler

. Is this valid behavior ? Regards, Nikolay

Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 7.03.2017 11:38, Nikolay Borisov wrote: > > > On 7.03.2017 00:35, Rafael J. Wysocki wrote: >> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov >> <n.borisov.l...@gmail.com> wrote: >>> Hello, >>> >>> Booting 4.11-rc1 with kasan enabled

Race condition in ext4 (was Re: 4.11-rc1 acpi stomping ext4 slabs)

On 7.03.2017 11:38, Nikolay Borisov wrote: > > > On 7.03.2017 00:35, Rafael J. Wysocki wrote: >> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov >> wrote: >>> Hello, >>> >>> Booting 4.11-rc1 with kasan enabled and "slub_debug=F"

Re: 4.11-rc1 acpi stomping ext4 slabs

On 7.03.2017 00:35, Rafael J. Wysocki wrote: > On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov > <n.borisov.l...@gmail.com> wrote: >> Hello, >> >> Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the

Re: 4.11-rc1 acpi stomping ext4 slabs

On 7.03.2017 00:35, Rafael J. Wysocki wrote: > On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov > wrote: >> Hello, >> >> Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the >&g

4.11-rc1 acpi stomping ext4 slabs

Hello, Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the following errors: [7.070797] == [7.071724] BUG: KASAN: slab-out-of-bounds in filldir+0xc3/0x160 at addr 88006bc2b0ae [7.071724] Read of

4.11-rc1 acpi stomping ext4 slabs

Hello, Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the following errors: [7.070797] == [7.071724] BUG: KASAN: slab-out-of-bounds in filldir+0xc3/0x160 at addr 88006bc2b0ae [7.071724] Read of

[PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

_FS when PF_MEMALLOC_NOIO is set") Signed-off-by: Nikolay Borisov <nbori...@suse.com> --- kernel/locking/lockdep.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Changes since v2: * Incorporate Michal's suggestion of using memalloc_noio_flags explicitly.

[PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

_FS when PF_MEMALLOC_NOIO is set") Signed-off-by: Nikolay Borisov --- kernel/locking/lockdep.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Changes since v2: * Incorporate Michal's suggestion of using memalloc_noio_flags explicitly. * Tune the commit message to ma

Re: [PATCH] lockdep: Teach lockdep about memalloc_noio_save

On 1.03.2017 12:31, Michal Hocko wrote: > On Wed 01-03-17 11:22:51, Vlastimil Babka wrote: >> On 03/01/2017 08:48 AM, Nikolay Borisov wrote: >>> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O >>> during memory allocation")

Re: [PATCH] lockdep: Teach lockdep about memalloc_noio_save

On 1.03.2017 12:31, Michal Hocko wrote: > On Wed 01-03-17 11:22:51, Vlastimil Babka wrote: >> On 03/01/2017 08:48 AM, Nikolay Borisov wrote: >>> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O >>> during memory allocation")

Re: [PATCH v2] lockdep: Teach lockdep about memalloc_noio_save

On 1.03.2017 11:46, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 09:59:00AM +0200, Nikolay Borisov wrote: >> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O >> during memory allocation") added the memalloc_noio_(save|restore) functions >

Re: [PATCH v2] lockdep: Teach lockdep about memalloc_noio_save

On 1.03.2017 11:46, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 09:59:00AM +0200, Nikolay Borisov wrote: >> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O >> during memory allocation") added the memalloc_noio_(save|restore) functions >

[PATCH v2] lockdep: Teach lockdep about memalloc_noio_save

rsing back into the filesystem without explicitly changing the flags for every allocation site. Yet, lockdep not being aware of that is prone to showing false positives. Fix this by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not going to issue any I/O Signed-off-by: Nikolay Borisov <nbor

[PATCH v2] lockdep: Teach lockdep about memalloc_noio_save

rsing back into the filesystem without explicitly changing the flags for every allocation site. Yet, lockdep not being aware of that is prone to showing false positives. Fix this by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not going to issue any I/O Signed-off-by: Nikolay Borisov --- kern

[PATCH] lockdep: Teach lockdep about memalloc_noio_save

rsing back into the filesystem without explicitly changing the flags for every allocation site. Yet, lockdep not being aware of that is prone to showing false positives. Fix this by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not going to issue any I/O Signed-off-by: Nikolay Borisov <nbor

[PATCH] lockdep: Teach lockdep about memalloc_noio_save

rsing back into the filesystem without explicitly changing the flags for every allocation site. Yet, lockdep not being aware of that is prone to showing false positives. Fix this by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not going to issue any I/O Signed-off-by: Nikolay Borisov --- kern

Re: [PATCH][net-next] net: bridge: remove redundant check to see if err is set

return err; > } > > return err; > Actually that code can be reduced further, I'll follow up with a patch later. Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH][net-next] net: bridge: remove redundant check to see if err is set

> Actually that code can be reduced further, I'll follow up with a patch later. Reviewed-by: Nikolay Aleksandrov

Re: [PATCH net-next v5] bridge: multicast to unicast

1 + > include/uapi/linux/if_link.h | 1 + > net/bridge/br_forward.c | 39 ++++++- > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 90 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 3 +- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 114 insertions(+), 29 deletions(-) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH net-next v5] bridge: multicast to unicast

| 39 ++- > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 90 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 3 +- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 114 insertions(+), 29 deletions(-) > Reviewed-by: Nikolay Aleksandrov

Re: namespace: deadlock in dec_pid_namespaces

On 20.01.2017 20:05, Eric W. Biederman wrote: > Nikolay Borisov <n.borisov.l...@gmail.com> writes: > >> On 20.01.2017 15:07, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following deadlock report while running syzkaller fuzzer >>>

Re: namespace: deadlock in dec_pid_namespaces

On 20.01.2017 20:05, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> On 20.01.2017 15:07, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following deadlock report while running syzkaller fuzzer >>> on eec0d3d065bfcdf9cd5f56dd2a36

Re: namespace: deadlock in dec_pid_namespaces

000 2820a478 > [] el1_irq+0xb8/0x130 arch/arm64/kernel/entry.S:486 > [< inline >] arch_local_irq_restore > ./arch/arm64/include/asm/irqflags.h:81 > [] rcu_idle_exit+0x64/0xa8 kernel/rcu/tree.c:1030 > [< inline >] cpuidle_idl

Re: namespace: deadlock in dec_pid_namespaces

000 2820a478 > [] el1_irq+0xb8/0x130 arch/arm64/kernel/entry.S:486 > [< inline >] arch_local_irq_restore > ./arch/arm64/include/asm/irqflags.h:81 > [] rcu_idle_exit+0x64/0xa8 kernel/rcu/tree.c:1030 > [< inline >] cpuidle_idle_ca

Re: [PATCH net-next v4] bridge: multicast to unicast

2 +- > net/bridge/br_multicast.c| 96 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 8 ++-- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 121 insertions(+), 31 deletions(-) > Looks good to me, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH net-next v4] bridge: multicast to unicast

gned-off-by: Felix Fietkau [...]" > --- > include/linux/if_bridge.h| 1 + > include/uapi/linux/if_link.h | 1 + > net/bridge/br_forward.c | 37 - > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 96 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 8 ++-- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 121 insertions(+), 31 deletions(-) > Looks good to me, Reviewed-by: Nikolay Aleksandrov

Re: [PATCH net-next] bridge: multicast to unicast

On 02/01/17 20:32, Linus Lüssing wrote: Implements an optional, per bridge port flag and feature to deliver multicast packets to any host on the according port via unicast individually. This is done by copying the packet per host and changing the multicast destination MAC to a unicast one

Re: [PATCH net-next] bridge: multicast to unicast

On 02/01/17 20:32, Linus Lüssing wrote: Implements an optional, per bridge port flag and feature to deliver multicast packets to any host on the according port via unicast individually. This is done by copying the packet per host and changing the multicast destination MAC to a unicast one

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

On 28.12.2016 18:00, Michal Hocko wrote: > On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: >> >> >> On 28.12.2016 17:30, Michal Hocko wrote: >>> From: Michal Hocko <mho...@suse.com> >>> >>> mm_vmscan_lru_isolate currently prints only wh

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

On 28.12.2016 18:00, Michal Hocko wrote: > On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: >> >> >> On 28.12.2016 17:30, Michal Hocko wrote: >>> From: Michal Hocko >>> >>> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

On 28.12.2016 17:30, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well.

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

On 28.12.2016 17:30, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change Maybe you

Re: [PATCH] ipv4: Namespaceify tcp_tw_reuse knob

On 24.12.2016 14:43, Haishuang Yan wrote: > Signed-off-by: Haishuang Yan <yanhaishu...@cmss.chinamobile.com> Reviewed-by: Nikolay Borisov <n.borisov.l...@gmail.com>

Re: [PATCH] ipv4: Namespaceify tcp_tw_reuse knob

On 24.12.2016 14:43, Haishuang Yan wrote: > Signed-off-by: Haishuang Yan Reviewed-by: Nikolay Borisov

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 18.12.2016 16:45, Jiri Slaby wrote: > Moreover, with some modules, __put_user_1 and others are reported > instead of mcount. nm vmlinux | grep __fentry__ nm vmlinux | grep mcount What do these report ? I bet you that in your vmlinux the first one would return something like :

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 18.12.2016 16:45, Jiri Slaby wrote: > Moreover, with some modules, __put_user_1 and others are reported > instead of mcount. nm vmlinux | grep __fentry__ nm vmlinux | grep mcount What do these report ? I bet you that in your vmlinux the first one would return something like :

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 18.12.2016 13:03, Arend Van Spriel wrote: > On 18-12-2016 11:49, Jiri Slaby wrote: >> On 12/18/2016, 12:59 AM, Linus Torvalds wrote: >>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote: Yes, disk drivers won't load: [2.141973] virtio_pci: disagrees about

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 18.12.2016 13:03, Arend Van Spriel wrote: > On 18-12-2016 11:49, Jiri Slaby wrote: >> On 12/18/2016, 12:59 AM, Linus Torvalds wrote: >>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote: Yes, disk drivers won't load: [2.141973] virtio_pci: disagrees about version of

Re: default 0 if KASAN expression not working in kbuild

On 16.12.2016 09:50, Nikolay Borisov wrote: > > > On 15.12.2016 23:32, Randy Dunlap wrote: >> On 12/15/16 10:09, Nikolay Borisov wrote: >>> Hello, >>> >>> I was doing some kasan-related debugging and when I enabled it I started >>> getting w

Re: default 0 if KASAN expression not working in kbuild

On 16.12.2016 09:50, Nikolay Borisov wrote: > > > On 15.12.2016 23:32, Randy Dunlap wrote: >> On 12/15/16 10:09, Nikolay Borisov wrote: >>> Hello, >>> >>> I was doing some kasan-related debugging and when I enabled it I started >>> getting w

Re: default 0 if KASAN expression not working in kbuild

On 15.12.2016 23:32, Randy Dunlap wrote: > On 12/15/16 10:09, Nikolay Borisov wrote: >> Hello, >> >> I was doing some kasan-related debugging and when I enabled it I started >> getting warnings for large stackframes. So CONFIG_FRAME_WARN has : >> >> int &q

Re: default 0 if KASAN expression not working in kbuild

On 15.12.2016 23:32, Randy Dunlap wrote: > On 12/15/16 10:09, Nikolay Borisov wrote: >> Hello, >> >> I was doing some kasan-related debugging and when I enabled it I started >> getting warnings for large stackframes. So CONFIG_FRAME_WARN has : >> >> int &q

default 0 if KASAN expression not working in kbuild

. And even this is erroneous since it's a 64bit kernel, so it should be 2k. I haven't manually set the limit to 1k either. Regards, Nikolay

default 0 if KASAN expression not working in kbuild

. And even this is erroneous since it's a 64bit kernel, so it should be 2k. I haven't manually set the limit to 1k either. Regards, Nikolay

Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer_corrupt

On 13.12.2016 20:51, Eric W. Biederman wrote: > Nikolay Borisov <n.borisov.l...@gmail.com> writes: > >> So this thing resurfaced again and I took a hard look into the code but >> couldn't find anything suspicious. So the allocating and freeing >> contexts lea

Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer_corrupt

On 13.12.2016 20:51, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> So this thing resurfaced again and I took a hard look into the code but >> couldn't find anything suspicious. So the allocating and freeing >> contexts leads me to believe it's the 'tb

Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer_corrupt

So this thing resurfaced again and I took a hard look into the code but couldn't find anything suspicious. So the allocating and freeing contexts leads me to believe it's the 'tbl' pointer that is being corrupted. The only thing which I do with it is to increase it by two. Perhaps some liveness

Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer_corrupt

So this thing resurfaced again and I took a hard look into the code but couldn't find anything suspicious. So the allocating and freeing contexts leads me to believe it's the 'tbl' pointer that is being corrupted. The only thing which I do with it is to increase it by two. Perhaps some liveness

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 8.12.2016 08:58, Nikolay Borisov wrote: > > > On 8.12.2016 03:40, Eric W. Biederman wrote: >> Nikolay Borisov <ker...@kyup.com> writes: >> >>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully >>> resolved. >>

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 8.12.2016 08:58, Nikolay Borisov wrote: > > > On 8.12.2016 03:40, Eric W. Biederman wrote: >> Nikolay Borisov writes: >> >>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully >>> resolved. >> >> After getting sl

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 8.12.2016 03:40, Eric W. Biederman wrote: > Nikolay Borisov <ker...@kyup.com> writes: > >> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully >> resolved. > > After getting slowed down by some fixes I am now taking a hard look at > y

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 8.12.2016 03:40, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully >> resolved. > > After getting slowed down by some fixes I am now taking a hard look at > your patch in the hopes

list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

e root cause. Under what conditions is it "expected" to have list/count mismatch when running the rcu callbacks? Is it plausible that a memory corruption, induced by btrfs can have such an effect on core RCU data structures? So what exactly does the warning mean? Regards, Nikolay

list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

e root cause. Under what conditions is it "expected" to have list/count mismatch when running the rcu callbacks? Is it plausible that a memory corruption, induced by btrfs can have such an effect on core RCU data structures? So what exactly does the warning mean? Regards, Nikolay

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 10/11/2016 10:36 AM, Nikolay Borisov wrote: > This patchset converts inotify to using the newly introduced > per-userns sysctl infrastructure. > > Currently the inotify instances/watches are being accounted in the > user_struct structure. This means that in setups where m

Re: [PATCH v2] inotify: Convert to using per-namespace limits

On 10/11/2016 10:36 AM, Nikolay Borisov wrote: > This patchset converts inotify to using the newly introduced > per-userns sysctl infrastructure. > > Currently the inotify instances/watches are being accounted in the > user_struct structure. This means that in setups where m

[PATCHv2] cephfs: Fix scheduler warning due to nested blocking

with the mutex locking code, since they both fiddle with the task state. Fix the issue by using the newly-added nested blocking infrastructure in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with nested blocking") Link: https://lwn.net/Articles/628628/ Signed-off-by: Nikolay Bo

[PATCHv2] cephfs: Fix scheduler warning due to nested blocking

with the mutex locking code, since they both fiddle with the task state. Fix the issue by using the newly-added nested blocking infrastructure in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with nested blocking") Link: https://lwn.net/Articles/628628/ Signed-off-by: Nikolay Borisov --

[PATCH] cephfs: Fix scheduler warning due to nested blocking

with the mutex locking code, since they both fiddle with the task state. Fix the issue by using the newly-added nested blocking infrastructure in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with nested blocking") Link: https://lwn.net/Articles/628628/ Signed-off-by: Nikolay Bo

[PATCH] cephfs: Fix scheduler warning due to nested blocking

with the mutex locking code, since they both fiddle with the task state. Fix the issue by using the newly-added nested blocking infrastructure in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with nested blocking") Link: https://lwn.net/Articles/628628/ Signed-off-by: Nikolay Borisov --

[PATCH v2] inotify: Convert to using per-namespace limits

limits, which can further be tuned inside every individual user namespace. Additionally, in order to preserve the sysctl ABI make the existing inotify instances/watches sysctls modify the values of the initial user namespace. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- So here is a r

[PATCH v2] inotify: Convert to using per-namespace limits

limits, which can further be tuned inside every individual user namespace. Additionally, in order to preserve the sysctl ABI make the existing inotify instances/watches sysctls modify the values of the initial user namespace. Signed-off-by: Nikolay Borisov --- So here is a revised version which

Re: [PATCH] inotify: Convert to using per-namespace limits

On Mon, Oct 10, 2016 at 11:49 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Jan Kara <j...@suse.cz> writes: > >> On Mon 10-10-16 09:44:19, Nikolay Borisov wrote: >>> On 10/07/2016 09:14 PM, Eric W. Biederman wrote: >>> > Nikolay Borisov <ker

Re: [PATCH] inotify: Convert to using per-namespace limits

On Mon, Oct 10, 2016 at 11:49 PM, Eric W. Biederman wrote: > Jan Kara writes: > >> On Mon 10-10-16 09:44:19, Nikolay Borisov wrote: >>> On 10/07/2016 09:14 PM, Eric W. Biederman wrote: >>> > Nikolay Borisov writes: >>> > >>> >>

Re: [PATCHv2] ceph: Fix error handling in ceph_read_iter

On 10/10/2016 04:11 PM, Yan, Zheng wrote: > >> On 10 Oct 2016, at 20:56, Nikolay Borisov <ker...@kyup.com> wrote: >> >> In case __ceph_do_getattr returns an error and the retry_op in >> ceph_read_iter is not READ_INLINE, then it's possible to invoke >&

Re: [PATCHv2] ceph: Fix error handling in ceph_read_iter

On 10/10/2016 04:11 PM, Yan, Zheng wrote: > >> On 10 Oct 2016, at 20:56, Nikolay Borisov wrote: >> >> In case __ceph_do_getattr returns an error and the retry_op in >> ceph_read_iter is not READ_INLINE, then it's possible to invoke >> __free_page on a page wh

[PATCHv2] ceph: Fix error handling in ceph_read_iter

this by explicitly checking whether the page is set or not. Signed-off-by: Nikolay Borisov <ker...@kyup.com> Link: http://www.spinics.net/lists/ceph-users/msg31592.html --- Inverted the condition, so resending with correct condition this time. fs/ceph/file.c | 3 ++- 1 file changed, 2 insertions

[PATCHv2] ceph: Fix error handling in ceph_read_iter

this by explicitly checking whether the page is set or not. Signed-off-by: Nikolay Borisov Link: http://www.spinics.net/lists/ceph-users/msg31592.html --- Inverted the condition, so resending with correct condition this time. fs/ceph/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH] ceph: Fix error handling in ceph_read_iter

this by explicitly checking whether the page is set or not. Signed-off-by: Nikolay Borisov <ker...@kyup.com> Link: http://www.spinics.net/lists/ceph-users/msg31592.html --- fs/ceph/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 3c68e6

[PATCH] ceph: Fix error handling in ceph_read_iter

this by explicitly checking whether the page is set or not. Signed-off-by: Nikolay Borisov Link: http://www.spinics.net/lists/ceph-users/msg31592.html --- fs/ceph/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 3c68e6aee2f0..7413313ae6c8

Re: [PATCH] inotify: Convert to using per-namespace limits

On 10/07/2016 09:14 PM, Eric W. Biederman wrote: > Nikolay Borisov <ker...@kyup.com> writes: > >> This patchset converts inotify to using the newly introduced >> per-userns sysctl infrastructure. >> >> Currently the inotify instances/watches are being accou

Re: [PATCH] inotify: Convert to using per-namespace limits

On 10/07/2016 09:14 PM, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> This patchset converts inotify to using the newly introduced >> per-userns sysctl infrastructure. >> >> Currently the inotify instances/watches are being accounted in the >&g

[PATCH] inotify: Convert to using per-namespace limits

limits, which can further be tuned inside every individual user namespace. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- Hello Eric, I saw you've finally sent your pull request for 4.9 and it includes your implementatino of the ucount infrastructure. So here is my respin of the i

[PATCH] inotify: Convert to using per-namespace limits

limits, which can further be tuned inside every individual user namespace. Signed-off-by: Nikolay Borisov --- Hello Eric, I saw you've finally sent your pull request for 4.9 and it includes your implementatino of the ucount infrastructure. So here is my respin of the inotify patches using

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/06/2016 03:45 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 05:18:09PM +0300, Nikolay Borisov wrote: >> >> >> On 10/05/2016 05:03 PM, Paul E. McKenney wrote: >>> On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >>>> Explic

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