* Re: [PATCH v2 iproute2-next 05/11] devlink: Add devlink health show command
From: Jiri Pirko @ 2019-02-21 14:25 UTC (permalink / raw)
To: Aya Levin; +Cc: David Ahern, netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1550756567-18227-6-git-send-email-ayal@mellanox.com>
Thu, Feb 21, 2019 at 02:42:41PM CET, ayal@mellanox.com wrote:
>Add devlink health show command which displays status and configuration
>info on a specific reporter on a device or dump the info on all
>reporters on all devices. The patch also contains helper functions to
What "patch"? Please format the description as you would command the
codebase what to do.
>display status and dump's time stamp.
[...]
>+static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
>+{
>+ struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
>+ enum devlink_health_reporter_state state;
>+ const struct nlattr *attr;
>+ uint64_t time_ms;
>+ int err;
>+
>+ state = DEVLINK_HEALTH_REPORTER_STATE_HEALTHY;
Pointless assignment.
>+
>+ err = mnl_attr_parse_nested(tb_health[DEVLINK_ATTR_HEALTH_REPORTER],
>+ attr_cb, tb);
>+ if (err != MNL_CB_OK)
>+ return;
>+
>+ if (!tb[DEVLINK_ATTR_HEALTH_REPORTER_NAME] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_STATE])
>+ return;
>+
>+ pr_out_handle_start_arr(dl, tb_health);
>+
>+ pr_out_str(dl, "name",
>+ mnl_attr_get_str(tb[DEVLINK_ATTR_HEALTH_REPORTER_NAME]));
>+ if (!dl->json_output) {
>+ __pr_out_newline();
>+ __pr_out_indent_inc();
>+ }
>+ state = mnl_attr_get_u8(tb[DEVLINK_ATTR_HEALTH_REPORTER_STATE]);
>+ pr_out_str(dl, "state", health_state_name(state));
>+ pr_out_u64(dl, "error",
>+ mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT]));
>+ pr_out_u64(dl, "recover",
>+ mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT]));
>+ if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS]) {
>+ char dump_date[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
>+ char dump_time[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
Newline here please.
>+ attr = tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS];
>+ time_ms = mnl_attr_get_u64(attr);
>+ format_logtime(time_ms, dump_date, dump_time);
>+
>+ pr_out_str(dl, "last_dump_date", dump_date);
>+ pr_out_str(dl, "last_dump_time", dump_time);
>+ }
[...]
>@@ -5776,7 +5958,11 @@ static int dl_cmd(struct dl *dl, int argc, char **argv)
> } else if (dl_argv_match(dl, "region")) {
> dl_arg_inc(dl);
> return cmd_region(dl);
>+ } else if (dl_argv_match(dl, "health")) {
>+ dl_arg_inc(dl);
>+ return cmd_health(dl);
> }
>+
Please avoid newlines like this. Unrelated to the patch.
> pr_err("Object \"%s\" not found\n", dl_argv(dl));
> return -ENOENT;
> }
>--
>2.14.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Masahiro Yamada @ 2019-02-21 14:34 UTC (permalink / raw)
To: Joel Fernandes
Cc: Alexei Starovoitov, Networking, Linux Kernel Mailing List,
Andrew Morton, Alexei Starovoitov, atish patra, Daniel Colascione,
Dan Williams, Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour,
Kees Cook, kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <20190219151652.GA110907@google.com>
On Wed, Feb 20, 2019 at 12:17 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> Firstly, I want to apologize for not testing this and other corner cases you
> brought up. I should have known better. Since my build was working, I assumed
> that the feature is working. For that, I am very sorry.
You do not need to apologize. 0day bot usually catches build errors.
I guess 0day bot performs compile-tests only incrementally
and that is why we did not get any report.
> Secondly, it turns out Module.symvers circularly dependency problem also
> exists with another use case.
> If one does 'make modules_prepare' in a base kernel tree and then tries to
> build modules with that tree, a warning like this is printed but the module
> still gets built:
>
> WARNING: Symbol version dump ./Module.symvers
> is missing; modules will have no dependencies and modversions.
>
> CC [M] /tmp/testmod/test.o
> Building modules, stage 2.
> MODPOST 1 modules
> CC /tmp/testmod/test.mod.o
> LD [M] /tmp/testmod/test.ko
>
> So, I am thinking that at least for first pass I will just drop the inclusion
> of Module.symvers in the archive and allow any modules built using
> /proc/kheaders.tar.xz to not use it.
>
> Kbuild will print a warning anyway when anyone tries to build using
> /proc/kheaders.tar.xz, so if the user really wants module symbol versioning
> then they should probably use a full kernel source tree with Module.symvers
> available. For our usecase, kernel symbol versioning is a bit useless when
> using /proc/kheaders.tar.gz because the proc file is generated with the same
> kernel that the module is being built against, and subsequently loaded into
> the kernel. So it is not likely that the CRC of a kernel symbol will be
> different from what the module expects.
Without Module.symver, modpost cannot check whether references are
resolvable or not.
You will see "WARNING ... undefined" for every symbol referenced from
the module.
I am not an Android developer.
So, I will leave this judge to other people.
One more request if you have a chance to submit the next version.
Please do not hide error messages.
I wondered why you redirected stdout/stderr from the script.
I applied the following patch, and I tested. Then I see why.
Please fix your code instead of hiding underlying problems.
diff --git a/kernel/Makefile b/kernel/Makefile
index 1d13a7a..a76ccbd 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -148,7 +148,7 @@ $(obj)/kheaders.o: $(obj)/kheaders_data.h
targets += kheaders_data.txz
quiet_cmd_genikh = GEN $(obj)/kheaders_data.txz
-cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^ >/dev/null 2>&1
+cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^
$(obj)/kheaders_data.txz: $(ikh_file_list) FORCE
$(call cmd,genikh)
masahiro@grover:~/workspace/linux-yamada$ make
CALL scripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
GEN kernel/kheaders_data.txz
find: ‘FORCE’: No such file or directory
70106 blocks
Can't do inplace edit: kernel/kheaders_data.txz.tmp is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86 is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86/include
is not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/uapi is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/uapi/asm is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi/asm is
not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/asm is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/xen is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/uv is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/numachip is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/e820 is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/fpu is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/crypto is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/trace is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/genksyms
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/ksymoops
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb is not
a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb/linux
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/basic is
not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc is not
a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc/libfdt
is not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes is not a
regular file.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm64:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/xtensa:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/openrisc:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/nios2:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/mips:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/microblaze:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arc:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/sh:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/powerpc:
No such file or directory.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/dt-bindings
is not a regular file.
[ massive amount of error messages continues ]
> I can't think any other ways at the moment to break the circular dependency
> so I'm thinking this is good enough for now especially since Kbuild will
> print a proper warning. Let me know what you think?
>
> thanks,
>
> - Joel
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply related
* Re: [PATCH] bpfilter: remove extra header search paths for bpfilter_umh
From: Guenter Roeck @ 2019-02-21 14:42 UTC (permalink / raw)
To: Masahiro Yamada
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, netdev,
linux-kernel
On Thu, Jan 31, 2019 at 12:15:35PM +0900, Masahiro Yamada wrote:
> Currently, the header search paths -Itools/include and
> -Itools/include/uapi are not used. Let's drop the unused code.
>
> We can remove -I. too by fixing up one C file.
>
This patch reintroduces the problem last fixed with commit ae40832e53c3
("bpfilter: fix a build err"). Seen (at least) with gcc 7.4.0, 8.2.0.
binutils version is 2.31.1. Reverting this patch fixes the problem.
Guenter
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/bpfilter/Makefile | 1 -
> net/bpfilter/main.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index 0947ee7f70d5..5d6c7760142d 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -5,7 +5,6 @@
>
> hostprogs-y := bpfilter_umh
> bpfilter_umh-objs := main.o
> -KBUILD_HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
> HOSTCC := $(CC)
>
> ifeq ($(CONFIG_BPFILTER_UMH), y)
> diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c
> index 1317f108df8a..61ce8454a88e 100644
> --- a/net/bpfilter/main.c
> +++ b/net/bpfilter/main.c
> @@ -6,7 +6,7 @@
> #include <sys/socket.h>
> #include <fcntl.h>
> #include <unistd.h>
> -#include "include/uapi/linux/bpf.h"
> +#include "../../include/uapi/linux/bpf.h"
> #include <asm/unistd.h>
> #include "msgfmt.h"
>
> --
> 2.7.4
^ permalink raw reply
* [PATCH] mdio_bus: Fix use-after-free on device_register fails
From: Yue Haibing @ 2019-02-21 14:42 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
KASAN has found use-after-free in fixed_mdio_bus_init,
commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call
put_device on device_register() failure") call put_device()
while device_register() fails,give up the last reference
to the device and allow mdiobus_release to be executed
,kfreeing the bus. However in most drives, mdiobus_free
be called to free the bus while mdiobus_register fails.
use-after-free occurs when access bus again, this patch
revert it to let mdiobus_free free the bus.
KASAN report details as below:
BUG: KASAN: use-after-free in mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
Read of size 4 at addr ffff8881dc824d78 by task syz-executor.0/3524
CPU: 1 PID: 3524 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xfa/0x1ce lib/dump_stack.c:113
print_address_description+0x65/0x270 mm/kasan/report.c:187
kasan_report+0x149/0x18d mm/kasan/report.c:317
mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
fixed_mdio_bus_init+0x283/0x1000 [fixed_phy]
? 0xffffffffc0e40000
? 0xffffffffc0e40000
? 0xffffffffc0e40000
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6215c19c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00007f6215c19c70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6215c1a6bc
R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
Allocated by task 3524:
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
kmalloc include/linux/slab.h:545 [inline]
kzalloc include/linux/slab.h:740 [inline]
mdiobus_alloc_size+0x54/0x1b0 drivers/net/phy/mdio_bus.c:143
fixed_mdio_bus_init+0x163/0x1000 [fixed_phy]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3524:
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
slab_free_hook mm/slub.c:1409 [inline]
slab_free_freelist_hook mm/slub.c:1436 [inline]
slab_free mm/slub.c:2986 [inline]
kfree+0xe1/0x270 mm/slub.c:3938
device_release+0x78/0x200 drivers/base/core.c:919
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put+0x146/0x240 lib/kobject.c:708
put_device+0x1c/0x30 drivers/base/core.c:2060
__mdiobus_register+0x483/0x560 drivers/net/phy/mdio_bus.c:382
fixed_mdio_bus_init+0x26b/0x1000 [fixed_phy]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881dc824c80
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 248 bytes inside of
2048-byte region [ffff8881dc824c80, ffff8881dc825480)
The buggy address belongs to the page:
page:ffffea0007720800 count:1 mapcount:0 mapping:ffff8881f6c02800 index:0x0 compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 0000000000000000 0000000500000001 ffff8881f6c02800
raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881dc824c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881dc824c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8881dc824d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881dc824d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881dc824e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes: 0c692d07842a ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/mdio_bus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index debc74c..4be4cc0 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -373,7 +373,6 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
err = device_register(&bus->dev);
if (err) {
pr_err("mii_bus %s failed to register\n", bus->id);
- put_device(&bus->dev);
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* general protection fault in dev_get_by_index_rcu
From: syzbot @ 2019-02-21 14:46 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: c433570458e4 ax25: fix a use-after-free in ax25_fillin_cb()
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1352f84b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=4b137b8ba637eb77
dashboard link: https://syzkaller.appspot.com/bug?extid=48127bec5a5cd81411e3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+48127bec5a5cd81411e3@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3229 Comm: syz-executor0 Not tainted 4.20.0+ #255
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:dev_get_by_index_rcu+0x9a/0x360 net/core/dev.c:840
Code: f2 c7 40 0c 00 f2 f2 f2 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0
e8 64 82 5f fb 48 8d bb c0 01 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00
0f 85 7e 02 00 00 0f b6 85 34 ff ff ff 48 8b 93 c0
RSP: 0018:ffff8880ae706c50 EFLAGS: 00010207
RAX: 001ffffffffbd5e1 RBX: 00ffffffffdead4e RCX: ffffffff8697b590
RDX: 0000000000000100 RSI: ffffffff8622238c RDI: 00ffffffffdeaf0e
RBP: ffff8880ae706d30 R08: ffff888060b26340 R09: ffffed1015ce5b8f
R10: ffffed1015ce5b8f R11: ffff8880ae72dc7b R12: dffffc0000000000
R13: 0000000000000000 R14: ffff88806556b6f0 R15: ffff88808e08b95d
FS: 00007eff2e401700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fb2c000 CR3: 000000008a036000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
netif_index_is_l3_master include/net/l3mdev.h:138 [inline]
ip_send_unicast_reply+0x10fd/0x1740 net/ipv4/ip_output.c:1588
tcp_v4_send_reset+0x14be/0x2ae0 net/ipv4/tcp_ipv4.c:775
tcp_v4_rcv+0x1dfa/0x3b10 net/ipv4/tcp_ipv4.c:1936
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
ip_local_deliver_finish+0x234/0x380 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:255
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_rcv+0xed/0x600 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
process_backlog+0x217/0x760 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x7c5/0x1950 net/core/dev.c:6412
__do_softirq+0x30c/0xb2e kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
</IRQ>
do_softirq.part.13+0x126/0x160 kernel/softirq.c:337
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:696 [inline]
ip_finish_output2+0xabc/0x1a20 net/ipv4/ip_output.c:231
ip_finish_output+0x7f7/0xf90 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip_output+0x217/0x8d0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
__ip_queue_xmit+0x9af/0x1f40 net/ipv4/ip_output.c:505
ip_queue_xmit+0x56/0x70 include/net/ip.h:198
__tcp_transmit_skb+0x1b9f/0x3b90 net/ipv4/tcp_output.c:1160
tcp_transmit_skb net/ipv4/tcp_output.c:1176 [inline]
tcp_send_syn_data net/ipv4/tcp_output.c:3495 [inline]
tcp_connect+0x2271/0x4690 net/ipv4/tcp_output.c:3534
tcp_v4_connect+0x19bb/0x1df0 net/ipv4/tcp_ipv4.c:315
__inet_stream_connect+0x992/0x1150 net/ipv4/af_inet.c:655
tcp_sendmsg_fastopen net/ipv4/tcp.c:1161 [inline]
tcp_sendmsg_locked+0x2890/0x3f30 net/ipv4/tcp.c:1208
tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1443
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457ec9
Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007eff2e400c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000457ec9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 000000000073bf00 R08: 00000000200002c0 R09: 0000000000000010
R10: 00000400200007fe R11: 0000000000000246 R12: 00007eff2e4016d4
R13: 00000000004c5278 R14: 00000000004d8b90 R15: 00000000ffffffff
Modules linked in:
---[ end trace 67e073c62a96b1a3 ]---
RIP: 0010:dev_get_by_index_rcu+0x9a/0x360 net/core/dev.c:840
Code: f2 c7 40 0c 00 f2 f2 f2 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0
e8 64 82 5f fb 48 8d bb c0 01 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00
0f 85 7e 02 00 00 0f b6 85 34 ff ff ff 48 8b 93 c0
RSP: 0018:ffff8880ae706c50 EFLAGS: 00010207
RAX: 001ffffffffbd5e1 RBX: 00ffffffffdead4e RCX: ffffffff8697b590
RDX: 0000000000000100 RSI: ffffffff8622238c RDI: 00ffffffffdeaf0e
RBP: ffff8880ae706d30 R08: ffff888060b26340 R09: ffffed1015ce5b8f
R10: ffffed1015ce5b8f R11: ffff8880ae72dc7b R12: dffffc0000000000
R13: 0000000000000000 R14: ffff88806556b6f0 R15: ffff88808e08b95d
FS: 00007eff2e401700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fb2c000 CR3: 000000008a036000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in ip6_hold_safe
From: syzbot @ 2019-02-21 14:47 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1672a39b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76
dashboard link: https://syzkaller.appspot.com/bug?extid=ec03ae3a032901d10434
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ec03ae3a032901d10434@syzkaller.appspotmail.com
kernel msg: ebtables bug: please report to author: EBT_ENTRY_OR_ENTRIES
shouldn't be set in distinguisher
==================================================================
BUG: KASAN: slab-out-of-bounds in atomic_read
include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: slab-out-of-bounds in atomic_fetch_add_unless
include/linux/atomic.h:575 [inline]
BUG: KASAN: slab-out-of-bounds in atomic_add_unless
include/linux/atomic.h:597 [inline]
BUG: KASAN: slab-out-of-bounds in dst_hold_safe include/net/dst.h:308
[inline]
BUG: KASAN: slab-out-of-bounds in ip6_hold_safe+0xca/0x620
net/ipv6/route.c:1021
Read of size 4 at addr ffff88806b399ccc by task ksoftirqd/1/16
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.20.0+ #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x123/0x190 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
atomic_add_unless include/linux/atomic.h:597 [inline]
dst_hold_safe include/net/dst.h:308 [inline]
ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021
rt6_get_pcpu_route net/ipv6/route.c:1241 [inline]
ip6_pol_route+0x3a3/0x1490 net/ipv6/route.c:1890
ip6_pol_route_input+0x65/0x80 net/ipv6/route.c:1909
fib6_rule_lookup+0x12f/0x870 net/ipv6/fib6_rules.c:118
ip6_route_input_lookup+0xb7/0xd0 net/ipv6/route.c:1921
ip6_route_input+0x79b/0xe00 net/ipv6/route.c:2056
ip6_rcv_finish_core.isra.0+0x204/0x720 net/ipv6/ip6_input.c:63
ip6_rcv_finish+0x109/0x330 net/ipv6/ip6_input.c:74
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ipv6_rcv+0x113/0x650 net/ipv6/ip6_input.c:272
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc mm/kasan/kasan.c:553 [inline]
kasan_kmalloc+0xce/0xf0 mm/kasan/kasan.c:531
kasan_slab_alloc+0xf/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x700 mm/slab.c:3554
getname_flags fs/namei.c:140 [inline]
getname_flags+0xd6/0x5b0 fs/namei.c:129
user_path_at_empty+0x2f/0x50 fs/namei.c:2608
do_readlinkat+0x141/0x400 fs/stat.c:397
__do_sys_readlink fs/stat.c:430 [inline]
__se_sys_readlink fs/stat.c:427 [inline]
__x64_sys_readlink+0x78/0xb0 fs/stat.c:427
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3760
putname+0xef/0x130 fs/namei.c:261
filename_lookup+0x359/0x530 fs/namei.c:2357
user_path_at_empty+0x43/0x50 fs/namei.c:2608
do_readlinkat+0x141/0x400 fs/stat.c:397
__do_sys_readlink fs/stat.c:430 [inline]
__se_sys_readlink fs/stat.c:427 [inline]
__x64_sys_readlink+0x78/0xb0 fs/stat.c:427
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff88806b398440
which belongs to the cache names_cache of size 4096
The buggy address is located 2188 bytes to the right of
4096-byte region [ffff88806b398440, ffff88806b399440)
The buggy address belongs to the page:
page:ffffea0001ace600 count:1 mapcount:0 mapping:ffff88812c2bec40 index:0x0
compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0002310008 ffffea0002a06988 ffff88812c2bec40
raw: 0000000000000000 ffff88806b398440 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88806b399b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88806b399c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88806b399c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88806b399d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88806b399d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [RFC] coallocating struct socket and struct socket_wq
From: Al Viro @ 2019-02-21 14:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <20190221081523.GZ2217@ZenIV.linux.org.uk>
On Thu, Feb 21, 2019 at 08:15:23AM +0000, Al Viro wrote:
> All instances of struct socket are embedded into some
> bigger structure - most into struct socket_alloc (with struct inode
> following struct socket), some into struct tun_file or struct
> tap_queue.
>
> In the last two cases the corresponding struct socket_wq
> (the one whose address goes into socket->wq) is in the same
> containing structure, right after struct socket.
>
> In case of struct socket_alloc, we allocate struct
> socket_wq separately and set socket->wq before anyone sees
> either (in sock_alloc_inode()). In sock_destroy_inode()
> they are both freed (struct sock_alloc immediately,
> struct socket_wq - RCU-delayed).
>
> AFAICS, nothing ever reassigns socket->wq. Could we
> simply embed struct socket_wq into struct socket? RCU delay
> is not an issue - net/socket.c is non-modular, so call_rcu()-based
> variant freeing both together is not horrible. sock_alloc_inode()
> would be simplified, tun/tap uses would simply lose the separate
> socket_wq members.
>
> The only problem I see here is ____cacheline_aligned_in_smp
> we have on struct socket_wq. Could we simply make it the first
> field in struct socket? Without lockdep they are reasonably small -
> on amd64 socket_wq is 64 bytes, while the rest of struct socket is
> 48 (and pointer to wq would obviously disappear).
>
> Or is there something subtle I'm missing here?
Put it another way, what was the reason for "net: sock_def_readable()
and friends RCU conversion" not to put RCU delay into freeing of
struct socket itself? Separating the write-often fields from
mostly read-only ones? I hadn't been able to find in archives
the discussion from back in 2010, unfortunately ;-/
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 07/11] devlink: Add devlink health diagnose command
From: Jiri Pirko @ 2019-02-21 14:28 UTC (permalink / raw)
To: Aya Levin; +Cc: David Ahern, netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1550756567-18227-8-git-send-email-ayal@mellanox.com>
Thu, Feb 21, 2019 at 02:42:43PM CET, ayal@mellanox.com wrote:
>Add devlink health diagnose command: enabling retrieval of diagnostics data
>by the user on a reporter on a device. The command's output is a
>free text defined by the reporter.
>
>This patch also introduces an infra structure for flexible format
>output. This allow the command to display different data fields
>according to the reporter.
>Example:
>$ devlink health diagnose pci/0000:00:0a.0 reporter tx
>SQs:
> sqn: 4403 HW state: 1 stopped: false
> sqn: 4408 HW state: 1 stopped: false
> sqn: 4413 HW state: 1 stopped: false
> sqn: 4418 HW state: 1 stopped: false
> sqn: 4423 HW state: 1 stopped: false
>
>$ devlink health diagnose pci/0000:00:0a.0 reporter tx -jp
>{
> "SQs":[
> {
> "sqn":4403,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4408,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4413,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4418,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4423,
> "HW state":1,
> "stopped":false
> }
> ]
>}
>
>Signed-off-by: Aya Levin <ayal@mellanox.com>
>Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net v2 1/2] ipv6: route: enforce RCU protection in rt6_update_exception_stamp_rt()
From: David Ahern @ 2019-02-21 14:57 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <fe784e447b956d111d61d8dbc3386d7bb95a8d89.1550684182.git.pabeni@redhat.com>
On 2/21/19 5:19 AM, Paolo Abeni wrote:
> We must access rt6_info->from under RCU read lock: move the
> dereference under such lock, with proper annotation.
>
> v1 -> v2:
> - avoid using multiple, racy, fetch operations for rt->from
>
> Fixes: a68886a69180 ("net/ipv6: Make from in rt6_info rcu protected")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for fixing.
^ permalink raw reply
* Re: [PATCH net v2 2/2] ipv6: route: enforce RCU protection in ip6_route_check_nh_onlink()
From: David Ahern @ 2019-02-21 14:57 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <0bf24707358ef15ab42b44037da4dc46e3e63acb.1550684182.git.pabeni@redhat.com>
On 2/21/19 5:19 AM, Paolo Abeni wrote:
> We need a RCU critical section around rt6_info->from deference, and
> proper annotation.
>
> Fixes: 4ed591c8ab44 ("net/ipv6: Allow onlink routes to have a device mismatch if it is the default route")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for the fixing.
^ permalink raw reply
* [PATCH iproute2 1/1] man: Document COLORFGBG environment variable
From: Petr Vorel @ 2019-02-21 15:04 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel, Stephen Hemminger
Default colors are not contrast enough on dark backround
and this functionality, which uses more suitable colors
is hidden in the code.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
man/man8/ip.8 | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 84ade110..133d40d5 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -189,6 +189,12 @@ precedence. This flag is ignored if
.B \-json
is also given.
+Used color palette can be influenced by
+.BR COLORFGBG
+environment variable
+(see
+.BR ENVIRONMENT ).
+
.TP
.BR "\-t" , " \-timestamp"
display current time when using monitor option.
@@ -330,6 +336,17 @@ Usually it is
or, if the objects of this class cannot be listed,
.BR "help" .
+.SH ENVIRONMENT
+.TP
+.B COLORFGBG
+If set, it's value is used for detection whether background is dark or light and use contrast colors for it.
+
+COLORFGBG environment variable usually contains either two or three
+values separated by semicolons; we want the last value in either case.
+If this value is 0-6 or 8, chose colors suitable for dark background:
+
+COLORFGBG=";0" ip -c a
+
.SH EXIT STATUS
Exit status is 0 if command was successful, and 1 if there is a syntax error.
If an error was reported by the kernel exit status is 2.
--
2.12.3
^ permalink raw reply related
* Re: [PATCH net v2] ipv6: route: purge exception on removal
From: David Ahern @ 2019-02-21 15:10 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <1cf1aef01dd9294347df6e339d2f8f042172fb54.1550679150.git.pabeni@redhat.com>
On 2/20/19 12:18 PM, Paolo Abeni wrote:
> When a netdevice is unregistered, we flush the relevant exception
> via rt6_sync_down_dev() -> fib6_ifdown() -> fib6_del() -> fib6_del_route().
>
> Finally, we end-up calling rt6_remove_exception(), where we release
> the relevant dst, while we keep the references to the related fib6_info and
> dev. Such references should be released later when the dst will be
> destroyed.
>
> There are a number of caches that can keep the exception around for an
> unlimited amount of time - namely dst_cache, possibly even socket cache.
> As a result device registration may hang, as demonstrated by this script:
>
> ip netns add cl
> ip netns add rt
> ip netns add srv
> ip netns exec rt sysctl -w net.ipv6.conf.all.forwarding=1
>
> ip link add name cl_veth type veth peer name cl_rt_veth
> ip link set dev cl_veth netns cl
> ip -n cl link set dev cl_veth up
> ip -n cl addr add dev cl_veth 2001::2/64
> ip -n cl route add default via 2001::1
>
> ip -n cl link add tunv6 type ip6tnl mode ip6ip6 local 2001::2 remote 2002::1 hoplimit 64 dev cl_veth
> ip -n cl link set tunv6 up
> ip -n cl addr add 2013::2/64 dev tunv6
>
> ip link set dev cl_rt_veth netns rt
> ip -n rt link set dev cl_rt_veth up
> ip -n rt addr add dev cl_rt_veth 2001::1/64
>
> ip link add name rt_srv_veth type veth peer name srv_veth
> ip link set dev srv_veth netns srv
> ip -n srv link set dev srv_veth up
> ip -n srv addr add dev srv_veth 2002::1/64
> ip -n srv route add default via 2002::2
>
> ip -n srv link add tunv6 type ip6tnl mode ip6ip6 local 2002::1 remote 2001::2 hoplimit 64 dev srv_veth
> ip -n srv link set tunv6 up
> ip -n srv addr add 2013::1/64 dev tunv6
>
> ip link set dev rt_srv_veth netns rt
> ip -n rt link set dev rt_srv_veth up
> ip -n rt addr add dev rt_srv_veth 2002::2/64
>
> ip netns exec srv netserver & sleep 0.1
> ip netns exec cl ping6 -c 4 2013::1
> ip netns exec cl netperf -H 2013::1 -t TCP_STREAM -l 3 & sleep 1
> ip -n rt link set dev rt_srv_veth mtu 1400
> wait %2
>
> ip -n cl link del cl_veth
>
> This commit addresses the issue purging all the references held by the
> exception at time, as we currently do for e.g. ipv6 pcpu dst entries.
>
> v1 -> v2:
> - re-order the code to avoid accessing dst and net after dst_dev_put()
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
I am surprised this was not found by the existing pmtu script which
creates exceptions. Please add this test case to selftests to capture
this specific set of events.
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for the resolving.
^ permalink raw reply
* Re: [PATCH RFC 4/5] sched/topology: Annonate RCU pointers properly
From: Joel Fernandes @ 2019-02-21 15:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
rcu, Song Liu, Steven Rostedt, xdp-newbies, Yonghong Song
In-Reply-To: <20190221091944.GY32477@hirez.programming.kicks-ass.net>
Hi Peter,
Thanks for taking a look.
On Thu, Feb 21, 2019 at 10:19:44AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 21, 2019 at 12:49:41AM -0500, Joel Fernandes (Google) wrote:
>
> > Also replace rcu_assign_pointer call on rq->sd with WRITE_ONCE. This
> > should be sufficient for the rq->sd initialization.
>
> > @@ -668,7 +668,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
> >
> > rq_attach_root(rq, rd);
> > tmp = rq->sd;
> > - rcu_assign_pointer(rq->sd, sd);
> > + WRITE_ONCE(rq->sd, sd);
> > dirty_sched_domain_sysctl(cpu);
> > destroy_sched_domains(tmp);
>
> Where did the RELEASE barrier go?
>
> That was a publish operation, now it is not.
Funny thing is, initially I had written this patch with smp_store_release()
instead of WRITE_ONCE, but checkpatch complaints with that since it needs a
comment on top of it, and I wasn't sure if RELEASE barrier was the intent of
using rcu_assign_pointer (all the more reason to replace it with something
more explicit).
I will replace it with the following and resubmit it then:
/* Release barrier */
smp_store_release(&rq->sd, sd);
Or do we want to just drop the "Release barrier" comment and live with the
checkpatch warning?
(my same response applies to patch 5/5).
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH] drivers: net: phy: mdio-mux: Add support for Generic Mux controls
From: Andrew Lunn @ 2019-02-21 15:17 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Leo Li, Peter Rosin, Florian Fainelli, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <VI1PR0401MB2496D9119F5639278CB14965F17E0@VI1PR0401MB2496.eurprd04.prod.outlook.com>
> > > config MDIO_BUS_MUX
> > > tristate
> > > depends on OF_MDIO
> > > + select MULTIPLEXER
> > > help
> > > This module provides a driver framework for MDIO bus
> > > multiplexers which connect one of several child MDIO busses
> >
> > Hi Pankaj
> >
> > Please add a MDIO_BUS_MUX_MULTIPLEXER and put all the code into mdio-
> > mux-multiplexer.c
>
> Isn't MUX short for MULTIPLEXER ? wouldn't this be more confusing ?
Look at the pattern:
config MDIO_BUS_MUX
config MDIO_BUS_MUX_BCM_IPROC
config MDIO_BUS_MUX_GPIO
config MDIO_BUS_MUX_MMIOREG
You are adding another sort of MUX, A Mux that uses a kernel
Multiplexer. Hence the name should be MDIO_BUS_MUX_MULTIPLEXER.
You can try to avoid confusion by using good help text:
help This module provides a driver for MDIO bus multiplexer
that is controlled via the kernel multiplexer subsystem. The
bus multiplexer connects one of several child MDIO busses to
a parent bus. Child bus selection is under the control of
the kernel multiplexer subsystem.
This test basically follows the other MDIO multiplexers.
Andrew
^ permalink raw reply
* Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state
From: Eric Dumazet @ 2019-02-21 15:17 UTC (permalink / raw)
To: Devi Sandeep Endluri V V; +Cc: netdev, subashab, sharathv, ssaha, stranche
In-Reply-To: <20190221110118.GA24747@dendluri-linux.qualcomm.com>
On Thu, Feb 21, 2019 at 3:01 AM Devi Sandeep Endluri V V
<dendluri@codeaurora.org> wrote:
>
> On Wed, Feb 20, 2019 at 07:47:59AM -0800, Eric Dumazet wrote:
> > On Wed, Feb 20, 2019 at 6:28 AM Devi Sandeep Endluri V V
> > <dendluri@codeaurora.org> wrote:
> > >
> > > Userspace sends tcp connection (sock) destroy on network permission
> > > change. Kernel though doesn't send reset for the connections in
> > > SYN-SENT state and these connections continue to remain. Even as
> > > per RFC 793, there is no hard rule to not send RST on ABORT in
> > > this state. Change to make sure RST are send for connections in
> > > syn-sent state to avoid lingering connections on network switch.
> > >
> > > References from RFC 793
> > >
> > > ABORT Call
> > >
> > > SYN-SENT STATE
> > >
> > > All queued SENDs and RECEIVEs should be given "connection reset"
> > > notification, delete the TCB, enter CLOSED state, and return.
> > >
> > > SEGMENT ARRIVES
> > >
> > > If the state is SYN-SENT then
> > > If the RST bit is set
> > >
> > > If the ACK was acceptable then signal the user "error:
> > > connection reset", drop the segment, enter CLOSED state,
> > > delete TCB, and return. Otherwise (no ACK) drop the segment
> > > and return.
> > >
> > > Signed-off-by: Devi Sandeep Endluri V V <dendluri@codeaurora.org>
> > > ---
> > > net/ipv4/tcp.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git net/ipv4/tcp.c net/ipv4/tcp.c
> > > index cf3c509..8569dc5e 100644
> > > --- net/ipv4/tcp.c
> > > +++ net/ipv4/tcp.c
> > > @@ -2495,7 +2495,7 @@ static inline bool tcp_need_reset(int state)
> > > {
> > > return (1 << state) &
> > > (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_FIN_WAIT1 |
> > > - TCPF_FIN_WAIT2 | TCPF_SYN_RECV);
> > > + TCPF_FIN_WAIT2 | TCPF_SYN_RECV | TCPF_SYN_SENT);
> > > }
> > >
> > > static void tcp_rtx_queue_purge(struct sock *sk)
> >
> > Hi
> >
> > 1) I do not believe this patch is complete :
> > You have not changed tcp_disconnect() which seems to have dead code
> > if we apply your patch.
> >
> > 2) I am not sure we want to send yet another packet if the prior SYN
> > packets elect no answer.
> > (It is not clear if your patch applies to this case)
> >
> > 3) If we do not RESET, the other side has not seen the 3rd packet and
> > should eventually exit from SYN_RECV state and die.
> >
> > 4) A RESET can be lost on the network, and nothing will retransmit it.
> >
> > Can you describe the use case more precisely, because it seems in
> > contradiction of a feature that we plan to upstream.
> > (TCP_SILENT_CLOSE : do not send flood of RST/FIN when a gigantic
> > server process prematurely dies)
> >
> > Thanks.
>
> The algorithm for our network switch needs to have all TCP sessions
> on the previous network cleaned up. So, we are trying to reset the
> connections in SYN-SENT state as well. Is there any other way to
> forcefully reset these connections immediately rather than waiting
> for the other side to eventually exit and die?
There is no way we can make sure all TCP sessions are cleaned up.
For example, we can not make sure no machine eventually crashes or is
unexpectedly powered down.
What is the "algorithm for your network switch" exactly.
Sorry, I am not convinced we want to add more RST packets on the network,
most SRE closely look at RST packets as some proxy of 'badness'.
^ permalink raw reply
* Re: [PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers
From: Luis Chamberlain @ 2019-02-21 15:18 UTC (permalink / raw)
To: Eric Sandeen, Andrew Morton
Cc: Eric Sandeen, Linux Kernel Mailing List, fsdevel, netdev,
Kees Cook
In-Reply-To: <76eca432-8dfc-18f3-4977-567ac1707ff5@sandeen.net>
On Wed, Feb 20, 2019 at 05:35:04PM -0600, Eric Sandeen wrote:
> Here's a pretty hacky test script to test this code via
> ip_local_reserved_ports
Thanks Eric!
So /proc/sys/net/ipv4/ip_local_reserved_ports is a production knob, and
if we wanted to stress test it with a selftest it could break other self
tests or change the system behaviour. Because of this we have now have
lib/test_sysctl.c, and we test this with the script:
tools/testing/selftests/sysctl/sysctl.sh
Any chance you can extend lib/test_sysctl.c with a new respective bitmap
knob, and add a respective test? This will ensure we don't regress
later. 0-day runs sysctl.sh so it should catch any regressions in the
future.
If you can think of other ways to test the knob that would be great too.
Luis
^ permalink raw reply
* Re: [PATCH net-next 1/2] xdp: Always use a devmap for XDP_REDIRECT to a device
From: Jesper Dangaard Brouer @ 2019-02-21 15:19 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Daniel Borkmann, Alexei Starovoitov, brouer
In-Reply-To: <155075021399.13610.12521373406832889226.stgit@alrua-x1>
You forgot at cover letter describing why we are doing this...
even-though is should be obvious from the performance results ;-)
On Thu, 21 Feb 2019 12:56:54 +0100 Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> Before patch:
> xdp_redirect: 5426035 pkt/s
> xdp_redirect_map: 8412754 pkt/s
>
> After patch:
> xdp_redirect: 8314702 pkt/s
> xdp_redirect_map: 8411854 pkt/s
>
> This corresponds to a 53% increase in xdp_redirect performance, or a
> reduction in per-packet processing time by 64 nanoseconds.
(1/5426035-1/8314702)*10^9 = 64.0277 almost exactly 64 nanosec
(1/8412754-1/8411854)*10^9 = -0.012 => no regression for xdp_redirect_map
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH RFC 3/5] sched/cpufreq: Fix incorrect RCU API usage
From: Joel Fernandes @ 2019-02-21 15:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
rcu, Song Liu, Steven Rostedt, xdp-newbies, Yonghong Song
In-Reply-To: <20190221091805.GX32477@hirez.programming.kicks-ass.net>
On Thu, Feb 21, 2019 at 10:18:05AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 21, 2019 at 12:49:40AM -0500, Joel Fernandes (Google) wrote:
> > @@ -34,8 +34,12 @@ void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
> > if (WARN_ON(!data || !func))
> > return;
> >
> > - if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
> > + rcu_read_lock();
> > + if (WARN_ON(rcu_dereference(per_cpu(cpufreq_update_util_data, cpu)))) {
> > + rcu_read_unlock();
> > return;
> > + }
> > + rcu_read_unlock();
> >
> > data->func = func;
> > rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
>
> This doesn't make any kind of sense to me.
>
As per the rcu_assign_pointer() line, I inferred that
cpufreq_update_util_data is expected to be RCU protected. Reading the pointer
value of RCU pointers generally needs to be done from RCU read section, and
using rcu_dereference() (or using rcu_access()).
In this patch, I changed cpufreq_update_util_data to be __rcu annotated to
avoid the sparse error thrown by rcu_assign_pointer().
Instead of doing that, If your intention here is RELEASE barrier, should I
just replace in this function:
rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
with:
smp_store_release(per_cpu(cpufreq_update_util_data, cpu), data))
?
It would be nice IMO to be explicit about the intention of release/publish
semantics by using smp_store_release().
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH iproute2-next v1 02/19] rdma: Remove duplicated print code
From: David Ahern @ 2019-02-21 15:23 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20190220072136.3840-3-leon@kernel.org>
On 2/20/19 2:21 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> There is no need to keep same print functions for
> uint32_t and uint64_t, unify them into one function.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res.c | 22 +++++++---------------
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/rdma/res.c b/rdma/res.c
> index 6b0f5fe3..87865ec8 100644
> --- a/rdma/res.c
> +++ b/rdma/res.c
> @@ -808,28 +808,20 @@ static int res_cq_parse_cb(const struct nlmsghdr *nlh, void *data)
> return MNL_CB_OK;
> }
>
> -static void print_key(struct rd *rd, const char *name, uint32_t val)
> +static void print_key(struct rd *rd, const char *name, uint64_t val)
> {
> if (rd->json_output)
> jsonw_xint_field(rd->jw, name, val);
> else
> - pr_out("%s 0x%x ", name, val);
> + pr_out("%s 0x%" PRIx64 " ", name, val);
> }
what's the plan to move rdma tool to iproute2's json functions?
I realize rdma tool inherited this from devlink, but this command does
not need to continue managing this.
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: Jesper Dangaard Brouer @ 2019-02-21 15:23 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Daniel Borkmann, Alexei Starovoitov, brouer
In-Reply-To: <155075021407.13610.6656977312753058829.stgit@alrua-x1>
On Thu, 21 Feb 2019 12:56:54 +0100
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> The default maps used by xdp_redirect() are changed to use the new map
> type, which means that xdp_redirect() is no longer limited to ifindex < 64,
> but instead to 64 total simultaneous interfaces per network namespace. This
> also provides an easy way to compare the performance of devmap and
> devmap_idx:
>
> xdp_redirect_map (devmap): 8394560 pkt/s
> xdp_redirect (devmap_idx): 8179480 pkt/s
>
> Difference: 215080 pkt/s or 3.1 nanoseconds per packet.
(1/8394560-1/8179480)*10^9 = -3.13239 ns
But was the xdp_redirect_map code-path affected from patch 1/1?
(1/8412754-1/8394560)*10^9 = -0.2576 ns
It doesn't look like any performance regression to xdp_redirect_map
from these code changes :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH iproute2-next v1 00/19] Export object IDs to users
From: David Ahern @ 2019-02-21 15:26 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20190220072136.3840-1-leon@kernel.org>
On 2/20/19 2:21 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog:
> v0->v1:
> * Rebased to latest iproute2-next
> * Added latest rdma_netlink.h and updated commit message to point
> to kernel SHA commit.
>
> This series adds ability to present and query all known to rdmatool
> object by their respective, unique IDs (e.g. pdn. mrn, cqn e.t.c).
> All objects which have "parent" object has this information too.
>
> Thanks
>
I would prefer someone from the rdma world review this as well. Thanks
^ permalink raw reply
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Joel Fernandes @ 2019-02-21 15:29 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Alexei Starovoitov, Networking, Linux Kernel Mailing List,
Andrew Morton, Alexei Starovoitov, atish patra, Daniel Colascione,
Dan Williams, Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour,
Kees Cook, kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <CAK7LNAQ7GqCNc008ZZ4K0_BdTVMdwwVUgnfqBO-kDBmw4ikr3w@mail.gmail.com>
On Thu, Feb 21, 2019 at 11:34:41PM +0900, Masahiro Yamada wrote:
> On Wed, Feb 20, 2019 at 12:17 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> >
> > Firstly, I want to apologize for not testing this and other corner cases you
> > brought up. I should have known better. Since my build was working, I assumed
> > that the feature is working. For that, I am very sorry.
>
>
> You do not need to apologize. 0day bot usually catches build errors.
> I guess 0day bot performs compile-tests only incrementally
> and that is why we did not get any report.
Oh ok :) thanks.
> > Secondly, it turns out Module.symvers circularly dependency problem also
> > exists with another use case.
> > If one does 'make modules_prepare' in a base kernel tree and then tries to
> > build modules with that tree, a warning like this is printed but the module
> > still gets built:
> >
> > WARNING: Symbol version dump ./Module.symvers
> > is missing; modules will have no dependencies and modversions.
> >
> > CC [M] /tmp/testmod/test.o
> > Building modules, stage 2.
> > MODPOST 1 modules
> > CC /tmp/testmod/test.mod.o
> > LD [M] /tmp/testmod/test.ko
> >
> > So, I am thinking that at least for first pass I will just drop the inclusion
> > of Module.symvers in the archive and allow any modules built using
> > /proc/kheaders.tar.xz to not use it.
> >
> > Kbuild will print a warning anyway when anyone tries to build using
> > /proc/kheaders.tar.xz, so if the user really wants module symbol versioning
> > then they should probably use a full kernel source tree with Module.symvers
> > available. For our usecase, kernel symbol versioning is a bit useless when
> > using /proc/kheaders.tar.gz because the proc file is generated with the same
> > kernel that the module is being built against, and subsequently loaded into
> > the kernel. So it is not likely that the CRC of a kernel symbol will be
> > different from what the module expects.
>
>
> Without Module.symver, modpost cannot check whether references are
> resolvable or not.
>
> You will see "WARNING ... undefined" for every symbol referenced from
> the module.
>
>
> I am not an Android developer.
> So, I will leave this judge to other people.
IMO I don't see a way around this limiation but it would be nice if there was
a way to make it work. Since the kernel modules being built by this mechanism
are for tracing/debugging purposes, it is not a major concern for us.
> One more request if you have a chance to submit the next version.
> Please do not hide error messages.
Actually it was intended to suppress noise, not hide errors as such. I have
fixed all the errors in the next version and will be submitting it soon.
Thanks a lot for the review!
- Joel
> I wondered why you redirected stdout/stderr from the script.
>
> I applied the following patch, and I tested. Then I see why.
>
> Please fix your code instead of hiding underlying problems.
>
>
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 1d13a7a..a76ccbd 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -148,7 +148,7 @@ $(obj)/kheaders.o: $(obj)/kheaders_data.h
> targets += kheaders_data.txz
>
> quiet_cmd_genikh = GEN $(obj)/kheaders_data.txz
> -cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^ >/dev/null 2>&1
> +cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^
> $(obj)/kheaders_data.txz: $(ikh_file_list) FORCE
> $(call cmd,genikh)
>
>
>
>
>
>
> masahiro@grover:~/workspace/linux-yamada$ make
> CALL scripts/checksyscalls.sh
> DESCEND objtool
> CHK include/generated/compile.h
> GEN kernel/kheaders_data.txz
> find: ‘FORCE’: No such file or directory
> 70106 blocks
> Can't do inplace edit: kernel/kheaders_data.txz.tmp is not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch is not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86 is not a
> regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86/include
> is not a regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/uapi is not a regular
> file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/uapi/asm is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/generated is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi/asm is
> not a regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/generated/asm is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm is not a regular
> file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/xen is not a regular
> file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/uv is not a regular
> file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/numachip is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/e820 is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/fpu is not a regular
> file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/crypto is not a
> regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/arch/x86/include/asm/trace is not a
> regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts is not a
> regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/genksyms
> is not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/ksymoops
> is not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb is not
> a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb/linux
> is not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/basic is
> not a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc is not
> a regular file.
> Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc/libfdt
> is not a regular file.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes is not a
> regular file.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm64:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/xtensa:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/openrisc:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/nios2:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/mips:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/microblaze:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arc:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/sh:
> No such file or directory.
> Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/powerpc:
> No such file or directory.
> Can't do inplace edit:
> kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/dt-bindings
> is not a regular file.
>
> [ massive amount of error messages continues ]
>
>
>
>
>
>
> > I can't think any other ways at the moment to break the circular dependency
> > so I'm thinking this is good enough for now especially since Kbuild will
> > print a proper warning. Let me know what you think?
> >
> > thanks,
> >
> > - Joel
> >
> --
> Best Regards
> Masahiro Yamada
^ permalink raw reply
* [PATCH] tcp: detect use sendpage for slab-based objects
From: Vasily Averin @ 2019-02-21 15:30 UTC (permalink / raw)
To: Eric Dumazet, netdev
There was few incidents when XFS over network block device generates
IO requests with slab-based metadata. If these requests are processed
via sendpage path tcp_sendpage() calls skb_can_coalesce() and merges
neighbour slab objects into one skb fragment.
If receiving side is located on the same host tcp_recvmsg() can trigger
following BUG_ON
usercopy: kernel memory exposure attempt detected
from XXXXXX (kmalloc-512) (1024 bytes)
This patch helps to detect the reason of similar incidents on sending side.
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
---
net/ipv4/tcp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 2079145a3b7c..cf9572f4fc0f 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -996,6 +996,7 @@ ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
goto wait_for_memory;
if (can_coalesce) {
+ WARN_ON_ONCE(PageSlab(page));
skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy);
} else {
get_page(page);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH RFC 4/5] sched/topology: Annonate RCU pointers properly
From: Peter Zijlstra @ 2019-02-21 15:29 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
rcu, Song Liu, Steven Rostedt, xdp-newbies, Yonghong Song
In-Reply-To: <20190221151057.GA19213@google.com>
On Thu, Feb 21, 2019 at 10:10:57AM -0500, Joel Fernandes wrote:
> Hi Peter,
>
> Thanks for taking a look.
>
> On Thu, Feb 21, 2019 at 10:19:44AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 21, 2019 at 12:49:41AM -0500, Joel Fernandes (Google) wrote:
> >
> > > Also replace rcu_assign_pointer call on rq->sd with WRITE_ONCE. This
> > > should be sufficient for the rq->sd initialization.
> >
> > > @@ -668,7 +668,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
> > >
> > > rq_attach_root(rq, rd);
> > > tmp = rq->sd;
> > > - rcu_assign_pointer(rq->sd, sd);
> > > + WRITE_ONCE(rq->sd, sd);
> > > dirty_sched_domain_sysctl(cpu);
> > > destroy_sched_domains(tmp);
> >
> > Where did the RELEASE barrier go?
> >
> > That was a publish operation, now it is not.
>
> Funny thing is, initially I had written this patch with smp_store_release()
> instead of WRITE_ONCE, but checkpatch complaints with that since it needs a
> comment on top of it, and I wasn't sure if RELEASE barrier was the intent of
> using rcu_assign_pointer (all the more reason to replace it with something
> more explicit).
>
> I will replace it with the following and resubmit it then:
>
> /* Release barrier */
> smp_store_release(&rq->sd, sd);
>
> Or do we want to just drop the "Release barrier" comment and live with the
> checkpatch warning?
How about we keep using rcu_assign_pointer(), the whole sched domain
tree is under rcu; peruse that destroy_sched_domains() function for
instance.
Also check how for_each_domain() uses rcu_dereference().
^ permalink raw reply
* Re: [PATCH RFC 3/5] sched/cpufreq: Fix incorrect RCU API usage
From: Peter Zijlstra @ 2019-02-21 15:31 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
rcu, Song Liu, Steven Rostedt, xdp-newbies, Yonghong Song
In-Reply-To: <20190221152139.GB19213@google.com>
On Thu, Feb 21, 2019 at 10:21:39AM -0500, Joel Fernandes wrote:
> On Thu, Feb 21, 2019 at 10:18:05AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 21, 2019 at 12:49:40AM -0500, Joel Fernandes (Google) wrote:
> > > @@ -34,8 +34,12 @@ void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
> > > if (WARN_ON(!data || !func))
> > > return;
> > >
> > > - if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
> > > + rcu_read_lock();
> > > + if (WARN_ON(rcu_dereference(per_cpu(cpufreq_update_util_data, cpu)))) {
> > > + rcu_read_unlock();
> > > return;
> > > + }
> > > + rcu_read_unlock();
> > >
> > > data->func = func;
> > > rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
> >
> > This doesn't make any kind of sense to me.
> >
>
> As per the rcu_assign_pointer() line, I inferred that
> cpufreq_update_util_data is expected to be RCU protected. Reading the pointer
> value of RCU pointers generally needs to be done from RCU read section, and
> using rcu_dereference() (or using rcu_access()).
>
> In this patch, I changed cpufreq_update_util_data to be __rcu annotated to
> avoid the sparse error thrown by rcu_assign_pointer().
>
> Instead of doing that, If your intention here is RELEASE barrier, should I
> just replace in this function:
> rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
> with:
> smp_store_release(per_cpu(cpufreq_update_util_data, cpu), data))
> ?
>
> It would be nice IMO to be explicit about the intention of release/publish
> semantics by using smp_store_release().
No, it is RCU managed, it should be RCU. The problem is that the hunk
above is utter crap.
All that does is read the pointer, it never actually dereferences it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox