* Re: memory leak in pppoe_sendmsg
From: syzbot @ 2019-06-28 18:58 UTC (permalink / raw)
To: davem, linux-kernel, mostrows, netdev, syzkaller-bugs
In-Reply-To: <000000000000d981f1058a26e1a8@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: c84afab0 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=164241d9a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=1db8bd6825f9661c
dashboard link: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=126c5f8da00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17cdd4eba00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6bdfd184eac7709e5cc9@syzkaller.appspotmail.com
executing program
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.150s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.150s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.140s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.050s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.220s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.220s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.210s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.120s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.290s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.290s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.280s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.190s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.350s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.350s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.340s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.250s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.420s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.420s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.410s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.320s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.480s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.480s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.470s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.380s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.550s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.550s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.540s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.450s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.610s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.610s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.600s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.510s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* Re: [PATCH 2/4] lpfc: reduce stack size with CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
From: James Smart @ 2019-06-28 18:57 UTC (permalink / raw)
To: Arnd Bergmann, Kees Cook, Dick Kennedy, James E.J. Bottomley,
Martin K. Petersen
Cc: Larry Finger, Florian Schilhabel, Greg Kroah-Hartman,
David S . Miller, Wensong Zhang, Simon Horman, Julian Anastasov,
Pablo Neira Ayuso, James Morris, linux-scsi, linux-kernel, devel,
netdev, lvs-devel, netfilter-devel, coreteam, Ard Biesheuvel,
Hannes Reinecke, Willy Tarreau, Silvio Cesare
In-Reply-To: <20190628123819.2785504-2-arnd@arndb.de>
On 6/28/2019 5:37 AM, Arnd Bergmann wrote:
> The lpfc_debug_dump_all_queues() function repeatedly calls into
> lpfc_debug_dump_qe(), which has a temporary 128 byte buffer.
> This was fine before the introduction of CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
> because each instance could occupy the same stack slot. However,
> now they each get their own copy, which leads to a huge increase
> in stack usage as seen from the compiler warning:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debug_dump_all_queues':
> drivers/scsi/lpfc/lpfc_debugfs.c:6474:1: error: the frame size of 1712 bytes is larger than 100 bytes [-Werror=frame-larger-than=]
>
> Avoid this by not marking lpfc_debug_dump_qe() as inline so the
> compiler can choose to emit a static version of this function
> when it's needed or otherwise silently drop it. As an added benefit,
> not inlining multiple copies of this function means we save several
> kilobytes of .text section, reducing the file size from 47kb to 43.
>
> It is somewhat unusual to have a function that is static but not
> inline in a header file, but this does not cause problems here
> because it is only used by other inline functions. It would
> however seem reasonable to move all the lpfc_debug_dump_* functions
> into lpfc_debugfs.c and not mark them inline as a later cleanup.
I agree with this cleanup.
>
> Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/scsi/lpfc/lpfc_debugfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Reviewed-by: James Smart <james.smart@broadcom.com>
-- james
^ permalink raw reply
* Re: [PATCH 24/39] docs: driver-model: move it to the driver-api book
From: Jeff Kirsher @ 2019-06-28 18:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski, Jean Delvare, Guenter Roeck,
Harry Wei, Alex Shi, Greg Kroah-Hartman, Rafael J. Wysocki,
David S. Miller, David Kershner, Julia Lawall, Gilles Muller,
Nicolas Palix, Michal Marek, linux-gpio, linux-hwmon,
intel-wired-lan, netdev, sparmaintainer, devel, cocci
In-Reply-To: <920ff36c66233113b1825ab504fe675ed5a5bd7b.1561724493.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]
On Fri, 2019-06-28 at 09:30 -0300, Mauro Carvalho Chehab wrote:
> The audience for the Kernel driver-model is clearly Kernel hackers.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
For the 'ice' driver changes.
> ---
> Documentation/{ => driver-api}/driver-model/binding.rst | 0
> Documentation/{ => driver-api}/driver-model/bus.rst | 0
> Documentation/{ => driver-api}/driver-model/class.rst | 0
> .../{ => driver-api}/driver-model/design-patterns.rst | 0
> Documentation/{ => driver-api}/driver-model/device.rst | 0
> Documentation/{ => driver-api}/driver-model/devres.rst | 0
> Documentation/{ => driver-api}/driver-model/driver.rst | 0
> Documentation/{ => driver-api}/driver-model/index.rst | 2 --
> Documentation/{ => driver-api}/driver-model/overview.rst | 0
> Documentation/{ => driver-api}/driver-model/platform.rst | 0
> Documentation/{ => driver-api}/driver-model/porting.rst | 2 +-
> Documentation/driver-api/gpio/driver.rst | 2 +-
> Documentation/driver-api/index.rst | 1 +
> Documentation/eisa.txt | 4 ++--
> Documentation/filesystems/sysfs.txt | 2 +-
> Documentation/hwmon/submitting-patches.rst | 2 +-
> Documentation/translations/zh_CN/filesystems/sysfs.txt | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/gpio/gpio-cs5535.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> drivers/staging/unisys/Documentation/overview.txt | 4 ++--
> include/linux/device.h | 2 +-
> include/linux/platform_device.h | 2 +-
> scripts/coccinelle/free/devm_free.cocci | 2 +-
> 24 files changed, 16 insertions(+), 17 deletions(-)
> rename Documentation/{ => driver-api}/driver-model/binding.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/bus.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/class.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/design-patterns.rst
> (100%)
> rename Documentation/{ => driver-api}/driver-model/device.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/devres.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/driver.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/index.rst (96%)
> rename Documentation/{ => driver-api}/driver-model/overview.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/platform.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/porting.rst (99%)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 02/12] net: hns3: enable DCB when TC num is one and pfc_en is non-zero
From: Willem de Bruijn @ 2019-06-28 18:47 UTC (permalink / raw)
To: Huazhong Tan
Cc: David Miller, Network Development, linux-kernel, salil.mehta,
yisen.zhuang, linuxarm, Yunsheng Lin, Peng Li
In-Reply-To: <1561722618-12168-3-git-send-email-tanhuazhong@huawei.com>
On Fri, Jun 28, 2019 at 7:53 AM Huazhong Tan <tanhuazhong@huawei.com> wrote:
>
> From: Yunsheng Lin <linyunsheng@huawei.com>
>
> Currently when TC num is one, the DCB will be disabled no matter if
> pfc_en is non-zero or not.
>
> This patch enables the DCB if pfc_en is non-zero, even when TC num
> is one.
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> index 9edae5f..cb2fb5a 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> @@ -597,8 +597,10 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
> hdev->tm_info.prio_tc[i] =
> (i >= hdev->tm_info.num_tc) ? 0 : i;
>
> - /* DCB is enabled if we have more than 1 TC */
> - if (hdev->tm_info.num_tc > 1)
> + /* DCB is enabled if we have more than 1 TC or pfc_en is
> + * non-zero.
> + */
> + if (hdev->tm_info.num_tc > 1 || hdev->tm_info.pfc_en)
small nit: comments that just repeat the condition are not very informative.
More helpful might be to explain why the DCB should be enabled in both
these cases. Though such detailed comments, if useful, are better left
to the commit message usually.
> hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> else
> hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
> @@ -1388,6 +1390,19 @@ void hclge_tm_schd_info_update(struct hclge_dev *hdev, u8 num_tc)
> hclge_tm_schd_info_init(hdev);
> }
>
> +void hclge_tm_pfc_info_update(struct hclge_dev *hdev)
> +{
> + /* DCB is enabled if we have more than 1 TC or pfc_en is
> + * non-zero.
> + */
> + if (hdev->tm_info.num_tc > 1 || hdev->tm_info.pfc_en)
> + hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> + else
> + hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
> +
> + hclge_pfc_info_init(hdev);
> +}
Avoid introducing this code duplication by defining a helper?
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Matthew Garrett @ 2019-06-28 18:47 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Smalley, James Morris, linux-security, LKML, Linux API,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, LSM List
In-Reply-To: <CALCETrXwt43w6rQY6zt0J_3HOaad=+E5PushJNdSOZDBuaYV+Q@mail.gmail.com>
On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski <luto@kernel.org> wrote:
> They're really quite similar in my mind. Certainly some things in the
> "integrity" category give absolutely trivial control over the kernel
> (e.g. modules) while others make it quite challenging (ioperm), but
> the end result is very similar. And quite a few "confidentiality"
> things genuinely do allow all kernel memory to be read.
>
> I agree that finer-grained distinctions could be useful. My concern is
> that it's a tradeoff, and the other end of the tradeoff is an ABI
> stability issue. If someone decides down the road that some feature
> that is currently "integrity" can be split into a narrow "integrity"
> feature and a "confidentiality" feature then, if the user policy knows
> about the individual features, there's a risk of breaking people's
> systems. If we keep the fine-grained control, do we have a clear
> compatibility story?
My preference right now is to retain the fine-grained aspect of things
in the internal API, simply because it'll be more annoying to add it
back later if we want to. I don't want to expose it via the Lockdown
user facing API for the reasons you've described, but it's not
impossible that another LSM would find a way to do this reasonably.
Does it seem reasonable to punt this discussion out to the point where
another LSM tries to do something with this information, based on the
implementation they're attempting?
^ permalink raw reply
* Re: [net-next 1/4] gve: Add basic driver framework for Compute Engine Virtual NIC
From: Jakub Kicinski @ 2019-06-28 18:46 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <CAH_-1qzzWVKxDX3LaorsgYPjT5uhDgqdN3oMZtJ2p6AzDqRyXA@mail.gmail.com>
On Fri, 28 Jun 2019 10:52:27 -0700, Catherine Sullivan wrote:
> > > +if NET_VENDOR_GOOGLE
> > > +
> > > +config GVE
> > > + tristate "Google Virtual NIC (gVNIC) support"
> > > + depends on (PCI_MSI && X86)
> >
> > We usually prefer for drivers not to depend on the platform unless
> > really necessary, but IDK how that applies to the curious new world
> > of NICs nobody can buy :)
>
> This is the only platform it will ever need to run on so we would really
> prefer to not have to support others :)
I think the motivation is partially to force the uniform use of generic
APIs across the drivers, so that re-factoring of core code is easier.
Do you have any specific pain-points in mind where x86 dependency
simplifies things? If not I think it's a better default to not have it.
Not a big deal, though.
^ permalink raw reply
* Re: [PATCH 1/2] tls: remove close callback sock unlock/lock and flush_sync
From: Jakub Kicinski @ 2019-06-28 18:31 UTC (permalink / raw)
To: John Fastabend; +Cc: daniel, ast, netdev, edumazet, bpf
In-Reply-To: <5d1620374694e_26962b1f6a4fa5c4f2@john-XPS-13-9370.notmuch>
On Fri, 28 Jun 2019 07:12:07 -0700, John Fastabend wrote:
> Yeah seems possible although never seen in my testing. So I'll
> move the test_bit() inside the lock and do a ctx check to ensure
> still have the reference.
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk)
> lock(sk)
> set_bit()
> cancel_work()
> release
> ctx = tls_get_ctx(sk)
> unlikely(!ctx) <- we may have free'd
> test_bit()
> ...
> release()
>
> or
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk)
> lock(sk)
> ctx = tls_get_ctx(sk)
> unlikely(!ctx)
> test_bit()
> ...
> release()
> set_bit()
> cancel_work()
> release
Hmm... perhaps it's cleanest to stop the work from scheduling before we
proceed?
close():
while (!test_and_set(SHED))
flush();
lock(sk);
...
We just need to move init work, no?
FWIW I never tested his async crypto stuff, I wonder if there is a way
to convince normal CPU crypto to pretend to be async?
^ permalink raw reply
* [PATCH net-next 2/2] tc-testing: updated mirred action tests with batch create/delete
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1561746618-29349-1-git-send-email-mrv@mojatatu.com>
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
.../tc-testing/tc-tests/actions/mirred.json | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
index 6e5fb3d25681..2232b21e2510 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
@@ -459,5 +459,99 @@
"teardown": [
"$TC actions flush action mirred"
]
+ },
+ {
+ "id": "4749",
+ "name": "Add batch of 32 mirred redirect egress actions with cookie",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred egress redirect dev lo index \\$i cookie aabbccddeeff112233445566778800a1 \\\"; args=\"\\$args\\$cmd\"; done && $TC actions add \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "32",
+ "teardown": [
+ "$TC actions flush action mirred"
+ ]
+ },
+ {
+ "id": "5c69",
+ "name": "Delete batch of 32 mirred redirect egress actions",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ],
+ "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred egress redirect dev lo index \\$i \\\"; args=\\\"\\$args\\$cmd\\\"; done && $TC actions add \\$args\""
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred index \\$i \\\"; args=\"\\$args\\$cmd\"; done && $TC actions del \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "d3c0",
+ "name": "Add batch of 32 mirred mirror ingress actions with cookie",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred ingress mirror dev lo index \\$i cookie aabbccddeeff112233445566778800a1 \\\"; args=\"\\$args\\$cmd\"; done && $TC actions add \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "32",
+ "teardown": [
+ "$TC actions flush action mirred"
+ ]
+ },
+ {
+ "id": "e684",
+ "name": "Delete batch of 32 mirred mirror ingress actions",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ],
+ "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred ingress mirror dev lo index \\$i \\\"; args=\\\"\\$args\\$cmd\\\"; done && $TC actions add \\$args\""
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred index \\$i \\\"; args=\"\\$args\\$cmd\"; done && $TC actions del \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "0",
+ "teardown": []
}
]
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/2] net sched: update mirred action for batched events operations
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1561746618-29349-1-git-send-email-mrv@mojatatu.com>
Add get_fill_size() routine used to calculate the action size
when building a batch of events.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
net/sched/act_mirred.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 58e7573dded4..2857c8dd4c04 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -411,6 +411,11 @@ static void tcf_mirred_put_dev(struct net_device *dev)
dev_put(dev);
}
+static size_t tcf_mirred_get_fill_size(const struct tc_action *act)
+{
+ return nla_total_size(sizeof(struct tc_mirred));
+}
+
static struct tc_action_ops act_mirred_ops = {
.kind = "mirred",
.id = TCA_ID_MIRRED,
@@ -422,6 +427,7 @@ static struct tc_action_ops act_mirred_ops = {
.init = tcf_mirred_init,
.walk = tcf_mirred_walker,
.lookup = tcf_mirred_search,
+ .get_fill_size = tcf_mirred_get_fill_size,
.size = sizeof(struct tcf_mirred),
.get_dev = tcf_mirred_get_dev,
.put_dev = tcf_mirred_put_dev,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/2] Fix batched event generation for mirred action
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
When adding or deleting a batch of entries, the kernel sends upto
TCA_ACT_MAX_PRIO entries in an event to user space. However it does not
consider that the action sizes may vary and require different skb sizes.
For example :
% cat tc-batch.sh
TC="sudo /mnt/iproute2.git/tc/tc"
$TC actions flush action mirred
for i in `seq 1 $1`;
do
cmd="action mirred egress redirect dev lo index $i "
args=$args$cmd
done
$TC actions add $args
%
% ./tc-batch.sh 32
Error: Failed to fill netlink attributes while adding TC action.
We have an error talking to the kernel
%
patch 1 adds callback in tc_action_ops of mirred action, which calculates
the action size, and passes size to tcf_add_notify()/tcf_del_notify().
patch 2 updates the TDC test suite with relevant test cases.
Roman Mashak (2):
net sched: update mirred action for batched events operations
tc-testing: updated mirred action tests with batch create/delete
net/sched/act_mirred.c | 6 ++
.../tc-testing/tc-tests/actions/mirred.json | 94 ++++++++++++++++++++++
2 files changed, 100 insertions(+)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v2 bpf-next 4/4] selftests/bpf: convert legacy BPF maps to BTF-defined ones
From: Song Liu @ 2019-06-28 18:26 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-5-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Convert selftests that were originally left out and new ones added
> recently to consistently use BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> .../selftests/bpf/progs/get_cgroup_id_kern.c | 26 ++---
> tools/testing/selftests/bpf/progs/pyperf.h | 90 +++++++-------
> .../selftests/bpf/progs/sample_map_ret0.c | 24 ++--
> .../bpf/progs/sockmap_verdict_prog.c | 48 ++++----
> .../testing/selftests/bpf/progs/strobemeta.h | 68 +++++------
> .../selftests/bpf/progs/test_map_in_map.c | 30 ++---
> .../testing/selftests/bpf/progs/test_obj_id.c | 12 +-
> .../selftests/bpf/progs/test_xdp_loop.c | 26 ++---
> .../selftests/bpf/progs/xdp_redirect_map.c | 12 +-
> .../testing/selftests/bpf/progs/xdping_kern.c | 12 +-
> .../selftests/bpf/test_queue_stack_map.h | 30 ++---
> .../testing/selftests/bpf/test_sockmap_kern.h | 110 +++++++++---------
> 12 files changed, 240 insertions(+), 248 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 bpf-next 3/4] selftests/bpf: convert selftests using BTF-defined maps to new syntax
From: Song Liu @ 2019-06-28 18:25 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-4-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Convert all the existing selftests that are already using BTF-defined
> maps to use new syntax (with no static data initialization).
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
This looks cleaner!
> ---
> tools/testing/selftests/bpf/progs/bpf_flow.c | 28 +++----
> .../testing/selftests/bpf/progs/netcnt_prog.c | 20 ++---
> .../selftests/bpf/progs/socket_cookie_prog.c | 13 ++-
> .../selftests/bpf/progs/test_btf_newkv.c | 13 ++-
> .../bpf/progs/test_get_stack_rawtp.c | 39 ++++-----
> .../selftests/bpf/progs/test_global_data.c | 37 ++++-----
> tools/testing/selftests/bpf/progs/test_l4lb.c | 65 ++++++---------
> .../selftests/bpf/progs/test_l4lb_noinline.c | 65 ++++++---------
> .../selftests/bpf/progs/test_map_lock.c | 26 +++---
> .../bpf/progs/test_select_reuseport_kern.c | 67 ++++++---------
> .../bpf/progs/test_send_signal_kern.c | 26 +++---
> .../bpf/progs/test_sock_fields_kern.c | 78 +++++++-----------
> .../selftests/bpf/progs/test_spin_lock.c | 36 ++++-----
> .../bpf/progs/test_stacktrace_build_id.c | 55 +++++--------
> .../selftests/bpf/progs/test_stacktrace_map.c | 52 +++++-------
> .../selftests/bpf/progs/test_tcp_estats.c | 13 ++-
> .../selftests/bpf/progs/test_tcpbpf_kern.c | 26 +++---
> .../selftests/bpf/progs/test_tcpnotify_kern.c | 28 +++----
> tools/testing/selftests/bpf/progs/test_xdp.c | 26 +++---
> .../selftests/bpf/progs/test_xdp_noinline.c | 81 +++++++------------
> 20 files changed, 300 insertions(+), 494 deletions(-)
^ permalink raw reply
* Re: [PATCHv2 next 0/3] blackhole device to invalidate dst
From: Michael Chan @ 2019-06-28 18:22 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Netdev, Eric Dumazet, David Miller, Daniel Axtens,
Mahesh Bandewar
In-Reply-To: <20190627194250.91296-1-maheshb@google.com>
On Thu, Jun 27, 2019 at 12:42 PM Mahesh Bandewar <maheshb@google.com> wrote:
> However, Michael Chan <michael.chan@broadcom.com> had a setup
> where these fixes helped him mitigate the issue and not cause
> the crash.
>
Our lab has finished testing these patches. The patches work in the
sense that no oversize packets are now passed to the driver with the
patches applied. But I'm not seeing these bad packets reaching the
blackhole device and getting dropped there. So they get dropped in
some other code paths. I believe we saw the same results with your
earlier patches.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/4] selftests/bpf: add __int and __type macro for BTF-defined maps
From: Song Liu @ 2019-06-28 18:17 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-3-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Add simple __int and __type macro that hide details of how type and
> integer values are captured in BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 1a5b1accf091..aa5ddf58c088 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -8,6 +8,9 @@
> */
> #define SEC(NAME) __attribute__((section(NAME), used))
>
> +#define __int(name, val) int (*name)[val]
> +#define __type(name, val) val *name
> +
> /* helper macro to print out debug messages */
> #define bpf_printk(fmt, ...) \
> ({ \
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] libbpf: capture value in BTF type info for BTF-defined map defs
From: Song Liu @ 2019-06-28 18:17 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-2-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Change BTF-defined map definitions to capture compile-time integer
> values as part of BTF type definition, to avoid split of key/value type
> information and actual type/size/flags initialization for maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++----------------------
> 1 file changed, 28 insertions(+), 30 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 6e6ebef11ba3..9e099ecb2c2b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1028,40 +1028,40 @@ static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
> }
> }
>
> -static bool get_map_field_int(const char *map_name,
> - const struct btf *btf,
> +/*
> + * Fetch integer attribute of BTF map definition. Such attributes are
> + * represented using a pointer to an array, in which dimensionality of array
> + * encodes specified integer value. E.g., int (*type)[BPF_MAP_TYPE_ARRAY];
> + * encodes `type => BPF_MAP_TYPE_ARRAY` key/value pair completely using BTF
> + * type definition, while using only sizeof(void *) space in ELF data section.
> + */
> +static bool get_map_field_int(const char *map_name, const struct btf *btf,
> const struct btf_type *def,
> - const struct btf_member *m,
> - const void *data, __u32 *res) {
> + const struct btf_member *m, __u32 *res) {
> const struct btf_type *t = skip_mods_and_typedefs(btf, m->type);
> const char *name = btf__name_by_offset(btf, m->name_off);
> - __u32 int_info = *(const __u32 *)(const void *)(t + 1);
> + const struct btf_array *arr_info;
> + const struct btf_type *arr_t;
>
> - if (BTF_INFO_KIND(t->info) != BTF_KIND_INT) {
> - pr_warning("map '%s': attr '%s': expected INT, got %u.\n",
> + if (BTF_INFO_KIND(t->info) != BTF_KIND_PTR) {
> + pr_warning("map '%s': attr '%s': expected PTR, got %u.\n",
> map_name, name, BTF_INFO_KIND(t->info));
> return false;
> }
> - if (t->size != 4 || BTF_INT_BITS(int_info) != 32 ||
> - BTF_INT_OFFSET(int_info)) {
> - pr_warning("map '%s': attr '%s': expected 32-bit non-bitfield integer, "
> - "got %u-byte (%d-bit) one with bit offset %d.\n",
> - map_name, name, t->size, BTF_INT_BITS(int_info),
> - BTF_INT_OFFSET(int_info));
> - return false;
> - }
> - if (BTF_INFO_KFLAG(def->info) && BTF_MEMBER_BITFIELD_SIZE(m->offset)) {
> - pr_warning("map '%s': attr '%s': bitfield is not supported.\n",
> - map_name, name);
> +
> + arr_t = btf__type_by_id(btf, t->type);
> + if (!arr_t) {
> + pr_warning("map '%s': attr '%s': type [%u] not found.\n",
> + map_name, name, t->type);
> return false;
> }
> - if (m->offset % 32) {
> - pr_warning("map '%s': attr '%s': unaligned fields are not supported.\n",
> - map_name, name);
> + if (BTF_INFO_KIND(arr_t->info) != BTF_KIND_ARRAY) {
> + pr_warning("map '%s': attr '%s': expected ARRAY, got %u.\n",
> + map_name, name, BTF_INFO_KIND(arr_t->info));
> return false;
> }
> -
> - *res = *(const __u32 *)(data + m->offset / 8);
> + arr_info = (const void *)(arr_t + 1);
> + *res = arr_info->nelems;
> return true;
> }
>
> @@ -1074,7 +1074,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> const struct btf_var_secinfo *vi;
> const struct btf_var *var_extra;
> const struct btf_member *m;
> - const void *def_data;
> const char *map_name;
> struct bpf_map *map;
> int vlen, i;
> @@ -1131,7 +1130,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> pr_debug("map '%s': at sec_idx %d, offset %zu.\n",
> map_name, map->sec_idx, map->sec_offset);
>
> - def_data = data->d_buf + vi->offset;
> vlen = BTF_INFO_VLEN(def->info);
> m = (const void *)(def + 1);
> for (i = 0; i < vlen; i++, m++) {
> @@ -1144,19 +1142,19 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> }
> if (strcmp(name, "type") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.type))
> + &map->def.type))
> return -EINVAL;
> pr_debug("map '%s': found type = %u.\n",
> map_name, map->def.type);
> } else if (strcmp(name, "max_entries") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.max_entries))
> + &map->def.max_entries))
> return -EINVAL;
> pr_debug("map '%s': found max_entries = %u.\n",
> map_name, map->def.max_entries);
> } else if (strcmp(name, "map_flags") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.map_flags))
> + &map->def.map_flags))
> return -EINVAL;
> pr_debug("map '%s': found map_flags = %u.\n",
> map_name, map->def.map_flags);
> @@ -1164,7 +1162,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found key_size = %u.\n",
> map_name, sz);
> @@ -1207,7 +1205,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found value_size = %u.\n",
> map_name, sz);
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v4 03/13] dt-bindings: net: Add a YAML schemas for the generic MDIO options
From: Rob Herring @ 2019-06-28 18:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190628134553.l445r5idtejwlryl@flea>
On Fri, Jun 28, 2019 at 7:46 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Jun 27, 2019 at 10:06:57AM -0600, Rob Herring wrote:
> > On Thu, Jun 27, 2019 at 9:57 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > +
> > > > > + reset-gpios = <&gpio2 5 1>;
> > > > > + reset-delay-us = <2>;
> > > > > +
> > > > > + ethphy0: ethernet-phy@1 {
> > > > > + reg = <1>;
> > > >
> > > > Need a child node schema to validate the unit-address and reg property.
> > >
> > > This should be already covered by the ethernet-phy.yaml schemas
> > > earlier in this series.
> >
> > Partially, yes.
> >
> > > Were you expecting something else?
> >
> > That would not prevent having a child node such as 'foo {};' or
> > 'foo@bad {};'. It would also not check valid nodes named something
> > other than 'ethernet-phy'.
>
> Right, but listing the nodes won't either, since we can't enable
> additionalProperties in that schema. So any node that wouldn't match
> ethernet-phy@.* wouldn't be validated, but wouldn't generate a warning
> either.
Perhaps I wasn't clear, but it was missing or incorrect 'reg' property
and unit-address format checks that I was thinking about. Just like we
have for SPI.
Rob
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Andrii Nakryiko @ 2019-06-28 18:15 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <20190628181414.GC24308@mini-arch>
On Fri, Jun 28, 2019 at 11:14 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/28, Andrii Nakryiko wrote:
> > On Fri, Jun 28, 2019 at 11:00 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> > >
> > > On 06/27, Andrii Nakryiko wrote:
> > > > bpf_program__attach_perf_event allows to attach BPF program to existing
> > > > perf event hook, providing most generic and most low-level way to attach BPF
> > > > programs. It returns struct bpf_link, which should be passed to
> > > > bpf_link__destroy to detach and free resources, associated with a link.
> > > >
> > > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > > ---
> > > > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > > > tools/lib/bpf/libbpf.h | 3 +++
> > > > tools/lib/bpf/libbpf.map | 1 +
> > > > 3 files changed, 62 insertions(+)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 455795e6f8af..606705f878ba 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -32,6 +32,7 @@
> > > > #include <linux/limits.h>
> > > > #include <linux/perf_event.h>
> > > > #include <linux/ring_buffer.h>
> > > > +#include <sys/ioctl.h>
> > > > #include <sys/stat.h>
> > > > #include <sys/types.h>
> > > > #include <sys/vfs.h>
> > > > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > > > return err;
> > > > }
> > > >
> > > > +struct bpf_link_fd {
> > > > + struct bpf_link link; /* has to be at the top of struct */
> > > > + int fd; /* hook FD */
> > > > +};
> > > > +
> > > > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > > > +{
> > > > + struct bpf_link_fd *l = (void *)link;
> > > > + int err;
> > > > +
> > > > + if (l->fd < 0)
> > > > + return 0;
> > > > +
> > > > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > > > + close(l->fd);
> > > > + return err;
> > > Why not return -errno from ioctl here (as you do elsewhere)?
> >
> > Good catch, will fix, thanks!
> >
> > As an aside, this whole returning error on close/destroy is a bit
> > moot, as there is little one can do if any of teardown steps fail
> > (except crash, which is not great response :) ). So the strategy would
> > be to still free all memory and try to close all FDs, before returning
> > error (again, which one, first, last? eh..).
> Agreed, it's like nobody cares about close() return code. So don't
> bother with this fix unless you'd do another respin for a different
> reason.
I still want something more meaningful than -1 :) Will renamed bpf_fd as well.
>
> > > > +}
> > > > +
> > > > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > > > + int pfd)
> > > > +{
> > > > + char errmsg[STRERR_BUFSIZE];
> > > > + struct bpf_link_fd *link;
> > > > + int bpf_fd, err;
> > > > +
> > > > + bpf_fd = bpf_program__fd(prog);
> > > > + if (bpf_fd < 0) {
> > > > + pr_warning("program '%s': can't attach before loaded\n",
> > > > + bpf_program__title(prog, false));
> > > > + return ERR_PTR(-EINVAL);
> > > > + }
> > > > +
> > > > + link = malloc(sizeof(*link));
> > > > + if (!link)
> > > > + return ERR_PTR(-ENOMEM);
> > > > + link->link.destroy = &bpf_link__destroy_perf_event;
> > > > + link->fd = pfd;
> > > > +
> > > > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > > > + err = -errno;
> > > > + free(link);
> > > > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > > > + bpf_program__title(prog, false), pfd,
> > > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > > + return ERR_PTR(err);
> > > > + }
> > > > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > > > + err = -errno;
> > > > + free(link);
> > > > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > > > + bpf_program__title(prog, false), pfd,
> > > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > > + return ERR_PTR(err);
> > > > + }
> > > > + return (struct bpf_link *)link;
> > > > +}
> > > > +
> > > > enum bpf_perf_event_ret
> > > > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > > > void **copy_mem, size_t *copy_size,
> > > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > > index 5082a5ebb0c2..1bf66c4a9330 100644
> > > > --- a/tools/lib/bpf/libbpf.h
> > > > +++ b/tools/lib/bpf/libbpf.h
> > > > @@ -169,6 +169,9 @@ struct bpf_link;
> > > >
> > > > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > > >
> > > > +LIBBPF_API struct bpf_link *
> > > > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > > > +
> > > > struct bpf_insn;
> > > >
> > > > /*
> > > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > > index 3cde850fc8da..756f5aa802e9 100644
> > > > --- a/tools/lib/bpf/libbpf.map
> > > > +++ b/tools/lib/bpf/libbpf.map
> > > > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > > > global:
> > > > bpf_link__destroy;
> > > > bpf_object__load_xattr;
> > > > + bpf_program__attach_perf_event;
> > > > btf_dump__dump_type;
> > > > btf_dump__free;
> > > > btf_dump__new;
> > > > --
> > > > 2.17.1
> > > >
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Stanislav Fomichev @ 2019-06-28 18:14 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <CAEf4BzZ_1-uSNRco91yZ4OJ2dV+G-yZ_uFPTbQDmPHoNLX9sPw@mail.gmail.com>
On 06/28, Andrii Nakryiko wrote:
> On Fri, Jun 28, 2019 at 11:00 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 06/27, Andrii Nakryiko wrote:
> > > bpf_program__attach_perf_event allows to attach BPF program to existing
> > > perf event hook, providing most generic and most low-level way to attach BPF
> > > programs. It returns struct bpf_link, which should be passed to
> > > bpf_link__destroy to detach and free resources, associated with a link.
> > >
> > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > ---
> > > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > > tools/lib/bpf/libbpf.h | 3 +++
> > > tools/lib/bpf/libbpf.map | 1 +
> > > 3 files changed, 62 insertions(+)
> > >
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > index 455795e6f8af..606705f878ba 100644
> > > --- a/tools/lib/bpf/libbpf.c
> > > +++ b/tools/lib/bpf/libbpf.c
> > > @@ -32,6 +32,7 @@
> > > #include <linux/limits.h>
> > > #include <linux/perf_event.h>
> > > #include <linux/ring_buffer.h>
> > > +#include <sys/ioctl.h>
> > > #include <sys/stat.h>
> > > #include <sys/types.h>
> > > #include <sys/vfs.h>
> > > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > > return err;
> > > }
> > >
> > > +struct bpf_link_fd {
> > > + struct bpf_link link; /* has to be at the top of struct */
> > > + int fd; /* hook FD */
> > > +};
> > > +
> > > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > > +{
> > > + struct bpf_link_fd *l = (void *)link;
> > > + int err;
> > > +
> > > + if (l->fd < 0)
> > > + return 0;
> > > +
> > > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > > + close(l->fd);
> > > + return err;
> > Why not return -errno from ioctl here (as you do elsewhere)?
>
> Good catch, will fix, thanks!
>
> As an aside, this whole returning error on close/destroy is a bit
> moot, as there is little one can do if any of teardown steps fail
> (except crash, which is not great response :) ). So the strategy would
> be to still free all memory and try to close all FDs, before returning
> error (again, which one, first, last? eh..).
Agreed, it's like nobody cares about close() return code. So don't
bother with this fix unless you'd do another respin for a different
reason.
> > > +}
> > > +
> > > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > > + int pfd)
> > > +{
> > > + char errmsg[STRERR_BUFSIZE];
> > > + struct bpf_link_fd *link;
> > > + int bpf_fd, err;
> > > +
> > > + bpf_fd = bpf_program__fd(prog);
> > > + if (bpf_fd < 0) {
> > > + pr_warning("program '%s': can't attach before loaded\n",
> > > + bpf_program__title(prog, false));
> > > + return ERR_PTR(-EINVAL);
> > > + }
> > > +
> > > + link = malloc(sizeof(*link));
> > > + if (!link)
> > > + return ERR_PTR(-ENOMEM);
> > > + link->link.destroy = &bpf_link__destroy_perf_event;
> > > + link->fd = pfd;
> > > +
> > > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > > + err = -errno;
> > > + free(link);
> > > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > > + bpf_program__title(prog, false), pfd,
> > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > + return ERR_PTR(err);
> > > + }
> > > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > > + err = -errno;
> > > + free(link);
> > > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > > + bpf_program__title(prog, false), pfd,
> > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > + return ERR_PTR(err);
> > > + }
> > > + return (struct bpf_link *)link;
> > > +}
> > > +
> > > enum bpf_perf_event_ret
> > > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > > void **copy_mem, size_t *copy_size,
> > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > index 5082a5ebb0c2..1bf66c4a9330 100644
> > > --- a/tools/lib/bpf/libbpf.h
> > > +++ b/tools/lib/bpf/libbpf.h
> > > @@ -169,6 +169,9 @@ struct bpf_link;
> > >
> > > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > >
> > > +LIBBPF_API struct bpf_link *
> > > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > > +
> > > struct bpf_insn;
> > >
> > > /*
> > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > index 3cde850fc8da..756f5aa802e9 100644
> > > --- a/tools/lib/bpf/libbpf.map
> > > +++ b/tools/lib/bpf/libbpf.map
> > > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > > global:
> > > bpf_link__destroy;
> > > bpf_object__load_xattr;
> > > + bpf_program__attach_perf_event;
> > > btf_dump__dump_type;
> > > btf_dump__free;
> > > btf_dump__new;
> > > --
> > > 2.17.1
> > >
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] gve: Add ethtool support
From: Stephen Hemminger @ 2019-06-28 18:10 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <20190628175633.143501-5-csully@google.com>
On Fri, 28 Jun 2019 10:56:33 -0700
Catherine Sullivan <csully@google.com> wrote:
> +static void
> +gve_get_ethtool_stats(struct net_device *netdev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct gve_priv *priv = netdev_priv(netdev);
> + u64 rx_pkts, rx_bytes, tx_pkts, tx_bytes;
> + int ring;
> + int i;
> +
> + ASSERT_RTNL();
> +
> + for (rx_pkts = 0, rx_bytes = 0, ring = 0;
> + ring < priv->rx_cfg.num_queues; ring++) {
> + if (priv->rx) {
> + rx_pkts += priv->rx[ring].rpackets;
> + rx_bytes += priv->rx[ring].rbytes;
> + }
> + }
> + for (tx_pkts = 0, tx_bytes = 0, ring = 0;
> + ring < priv->tx_cfg.num_queues; ring++) {
> + if (priv->tx) {
> + tx_pkts += priv->tx[ring].pkt_done;
> + tx_bytes += priv->tx[ring].bytes_done;
> + }
> + }
> + memset(data, 0, GVE_MAIN_STATS_LEN * sizeof(*data));
memset here is unnecessary since ethtool_get_stats allocates
and zeros the memory already.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Stanislav Fomichev @ 2019-06-28 18:05 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: andrii.nakryiko, ast, daniel, netdev, bpf, kernel-team
In-Reply-To: <20190628055303.1249758-4-andriin@fb.com>
On 06/27, Andrii Nakryiko wrote:
> bpf_program__attach_perf_event allows to attach BPF program to existing
> perf event hook, providing most generic and most low-level way to attach BPF
> programs. It returns struct bpf_link, which should be passed to
> bpf_link__destroy to detach and free resources, associated with a link.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> tools/lib/bpf/libbpf.h | 3 +++
> tools/lib/bpf/libbpf.map | 1 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 455795e6f8af..606705f878ba 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -32,6 +32,7 @@
> #include <linux/limits.h>
> #include <linux/perf_event.h>
> #include <linux/ring_buffer.h>
> +#include <sys/ioctl.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/vfs.h>
> @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> return err;
> }
>
> +struct bpf_link_fd {
> + struct bpf_link link; /* has to be at the top of struct */
> + int fd; /* hook FD */
> +};
> +
> +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> +{
> + struct bpf_link_fd *l = (void *)link;
> + int err;
> +
> + if (l->fd < 0)
> + return 0;
> +
> + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> + close(l->fd);
> + return err;
> +}
> +
> +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> + int pfd)
> +{
> + char errmsg[STRERR_BUFSIZE];
> + struct bpf_link_fd *link;
> + int bpf_fd, err;
nit: maybe prog_fd instead of bpf_fd? Should be more consistent with
other places in libbf:
$ grep -Iriw bpf_fd | wc -l
2
$ grep -Iriw prog_fd | wc -l
39
> +
> + bpf_fd = bpf_program__fd(prog);
> + if (bpf_fd < 0) {
> + pr_warning("program '%s': can't attach before loaded\n",
> + bpf_program__title(prog, false));
> + return ERR_PTR(-EINVAL);
> + }
> +
> + link = malloc(sizeof(*link));
> + if (!link)
> + return ERR_PTR(-ENOMEM);
> + link->link.destroy = &bpf_link__destroy_perf_event;
> + link->fd = pfd;
> +
> + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> + err = -errno;
> + free(link);
> + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> + bpf_program__title(prog, false), pfd,
> + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> + return ERR_PTR(err);
> + }
> + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> + err = -errno;
> + free(link);
> + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> + bpf_program__title(prog, false), pfd,
> + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> + return ERR_PTR(err);
> + }
> + return (struct bpf_link *)link;
> +}
> +
> enum bpf_perf_event_ret
> bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> void **copy_mem, size_t *copy_size,
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 5082a5ebb0c2..1bf66c4a9330 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -169,6 +169,9 @@ struct bpf_link;
>
> LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
>
> +LIBBPF_API struct bpf_link *
> +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> +
> struct bpf_insn;
>
> /*
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index 3cde850fc8da..756f5aa802e9 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> global:
> bpf_link__destroy;
> bpf_object__load_xattr;
> + bpf_program__attach_perf_event;
> btf_dump__dump_type;
> btf_dump__free;
> btf_dump__new;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Andrii Nakryiko @ 2019-06-28 18:04 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <20190628180010.GA24308@mini-arch>
On Fri, Jun 28, 2019 at 11:00 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/27, Andrii Nakryiko wrote:
> > bpf_program__attach_perf_event allows to attach BPF program to existing
> > perf event hook, providing most generic and most low-level way to attach BPF
> > programs. It returns struct bpf_link, which should be passed to
> > bpf_link__destroy to detach and free resources, associated with a link.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > tools/lib/bpf/libbpf.h | 3 +++
> > tools/lib/bpf/libbpf.map | 1 +
> > 3 files changed, 62 insertions(+)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 455795e6f8af..606705f878ba 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -32,6 +32,7 @@
> > #include <linux/limits.h>
> > #include <linux/perf_event.h>
> > #include <linux/ring_buffer.h>
> > +#include <sys/ioctl.h>
> > #include <sys/stat.h>
> > #include <sys/types.h>
> > #include <sys/vfs.h>
> > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > return err;
> > }
> >
> > +struct bpf_link_fd {
> > + struct bpf_link link; /* has to be at the top of struct */
> > + int fd; /* hook FD */
> > +};
> > +
> > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > +{
> > + struct bpf_link_fd *l = (void *)link;
> > + int err;
> > +
> > + if (l->fd < 0)
> > + return 0;
> > +
> > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > + close(l->fd);
> > + return err;
> Why not return -errno from ioctl here (as you do elsewhere)?
Good catch, will fix, thanks!
As an aside, this whole returning error on close/destroy is a bit
moot, as there is little one can do if any of teardown steps fail
(except crash, which is not great response :) ). So the strategy would
be to still free all memory and try to close all FDs, before returning
error (again, which one, first, last? eh..).
>
> > +}
> > +
> > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > + int pfd)
> > +{
> > + char errmsg[STRERR_BUFSIZE];
> > + struct bpf_link_fd *link;
> > + int bpf_fd, err;
> > +
> > + bpf_fd = bpf_program__fd(prog);
> > + if (bpf_fd < 0) {
> > + pr_warning("program '%s': can't attach before loaded\n",
> > + bpf_program__title(prog, false));
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + link = malloc(sizeof(*link));
> > + if (!link)
> > + return ERR_PTR(-ENOMEM);
> > + link->link.destroy = &bpf_link__destroy_perf_event;
> > + link->fd = pfd;
> > +
> > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > + err = -errno;
> > + free(link);
> > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > + bpf_program__title(prog, false), pfd,
> > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > + return ERR_PTR(err);
> > + }
> > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > + err = -errno;
> > + free(link);
> > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > + bpf_program__title(prog, false), pfd,
> > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > + return ERR_PTR(err);
> > + }
> > + return (struct bpf_link *)link;
> > +}
> > +
> > enum bpf_perf_event_ret
> > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > void **copy_mem, size_t *copy_size,
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index 5082a5ebb0c2..1bf66c4a9330 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -169,6 +169,9 @@ struct bpf_link;
> >
> > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> >
> > +LIBBPF_API struct bpf_link *
> > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > +
> > struct bpf_insn;
> >
> > /*
> > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > index 3cde850fc8da..756f5aa802e9 100644
> > --- a/tools/lib/bpf/libbpf.map
> > +++ b/tools/lib/bpf/libbpf.map
> > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > global:
> > bpf_link__destroy;
> > bpf_object__load_xattr;
> > + bpf_program__attach_perf_event;
> > btf_dump__dump_type;
> > btf_dump__free;
> > btf_dump__new;
> > --
> > 2.17.1
> >
^ permalink raw reply
* [Patch net 3/3] selftests: add a test case for cls_lower handle overflow
From: Cong Wang @ 2019-06-28 18:03 UTC (permalink / raw)
To: netdev; +Cc: dcaratti, chrism, willy, Li Shuang, Cong Wang
In-Reply-To: <20190628180343.8230-1-xiyou.wangcong@gmail.com>
From: Davide Caratti <dcaratti@redhat.com>
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
.../tc-testing/tc-tests/filters/tests.json | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
index e2f92cefb8d5..16559c436f21 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
@@ -38,6 +38,25 @@
"$TC qdisc del dev $DEV1 clsact"
]
},
+ {
+ "id": "2ff3",
+ "name": "Add flower with max handle and then dump it",
+ "category": [
+ "filter",
+ "flower"
+ ],
+ "setup": [
+ "$TC qdisc add dev $DEV2 ingress"
+ ],
+ "cmdUnderTest": "$TC filter add dev $DEV2 protocol ip pref 1 parent ffff: handle 0xffffffff flower action ok",
+ "expExitCode": "0",
+ "verifyCmd": "$TC filter show dev $DEV2 ingress",
+ "matchPattern": "filter protocol ip pref 1 flower.*handle 0xffffffff",
+ "matchCount": "1",
+ "teardown": [
+ "$TC qdisc del dev $DEV2 ingress"
+ ]
+ },
{
"id": "d052",
"name": "Add 1M filters with the same action",
--
2.21.0
^ permalink raw reply related
* [Patch net 2/3] idr: introduce idr_for_each_entry_continue_ul()
From: Cong Wang @ 2019-06-28 18:03 UTC (permalink / raw)
To: netdev; +Cc: dcaratti, chrism, willy, Cong Wang, Li Shuang, Vlad Buslov
In-Reply-To: <20190628180343.8230-1-xiyou.wangcong@gmail.com>
Similarly, other callers of idr_get_next_ul() suffer the same
overflow bug as they don't handle it properly either.
Introduce idr_for_each_entry_continue_ul() to help these callers
iterate from a given ID.
cls_flower needs more care here because it still has overflow when
does arg->cookie++, we have to fold its nested loops into one
and remove the arg->cookie++.
Fixes: 01683a146999 ("net: sched: refactor flower walk to iterate over idr")
Fixes: 12d6066c3b29 ("net/mlx5: Add flow counters idr")
Reported-by: Li Shuang <shuali@redhat.com>
Cc: Davide Caratti <dcaratti@redhat.com>
Cc: Vlad Buslov <vladbu@mellanox.com>
Cc: Chris Mi <chrism@mellanox.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
.../ethernet/mellanox/mlx5/core/fs_counters.c | 10 ++++---
include/linux/idr.h | 14 ++++++++++
net/sched/cls_flower.c | 27 +++++--------------
3 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
index c6c28f56aa29..b3762123a69c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
@@ -102,13 +102,15 @@ static struct list_head *mlx5_fc_counters_lookup_next(struct mlx5_core_dev *dev,
struct mlx5_fc_stats *fc_stats = &dev->priv.fc_stats;
unsigned long next_id = (unsigned long)id + 1;
struct mlx5_fc *counter;
+ unsigned long tmp;
rcu_read_lock();
/* skip counters that are in idr, but not yet in counters list */
- while ((counter = idr_get_next_ul(&fc_stats->counters_idr,
- &next_id)) != NULL &&
- list_empty(&counter->list))
- next_id++;
+ idr_for_each_entry_continue_ul(&fc_stats->counters_idr,
+ counter, tmp, next_id) {
+ if (!list_empty(&counter->list))
+ break;
+ }
rcu_read_unlock();
return counter ? &counter->list : &fc_stats->counters;
diff --git a/include/linux/idr.h b/include/linux/idr.h
index 68528a72d10d..4ec8986e5dfb 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -216,6 +216,20 @@ static inline void idr_preload_end(void)
entry; \
++id, (entry) = idr_get_next((idr), &(id)))
+/**
+ * idr_for_each_entry_continue_ul() - Continue iteration over an IDR's elements of a given type
+ * @idr: IDR handle.
+ * @entry: The type * to use as a cursor.
+ * @tmp: A temporary placeholder for ID.
+ * @id: Entry ID.
+ *
+ * Continue to iterate over entries, continuing after the current position.
+ */
+#define idr_for_each_entry_continue_ul(idr, entry, tmp, id) \
+ for (tmp = id; \
+ tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \
+ tmp = id, ++id)
+
/*
* IDA - ID Allocator, use when translation from id to pointer isn't necessary.
*/
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index eedd5786c084..fdeede3af72e 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -524,24 +524,6 @@ static struct cls_fl_filter *__fl_get(struct cls_fl_head *head, u32 handle)
return f;
}
-static struct cls_fl_filter *fl_get_next_filter(struct tcf_proto *tp,
- unsigned long *handle)
-{
- struct cls_fl_head *head = fl_head_dereference(tp);
- struct cls_fl_filter *f;
-
- rcu_read_lock();
- while ((f = idr_get_next_ul(&head->handle_idr, handle))) {
- /* don't return filters that are being deleted */
- if (refcount_inc_not_zero(&f->refcnt))
- break;
- ++(*handle);
- }
- rcu_read_unlock();
-
- return f;
-}
-
static int __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f,
bool *last, bool rtnl_held,
struct netlink_ext_ack *extack)
@@ -1691,20 +1673,25 @@ static int fl_delete(struct tcf_proto *tp, void *arg, bool *last,
static void fl_walk(struct tcf_proto *tp, struct tcf_walker *arg,
bool rtnl_held)
{
+ struct cls_fl_head *head = fl_head_dereference(tp);
+ unsigned long id = arg->cookie, tmp;
struct cls_fl_filter *f;
arg->count = arg->skip;
- while ((f = fl_get_next_filter(tp, &arg->cookie)) != NULL) {
+ idr_for_each_entry_continue_ul(&head->handle_idr, f, tmp, id) {
+ /* don't return filters that are being deleted */
+ if (!refcount_inc_not_zero(&f->refcnt))
+ continue;
if (arg->fn(tp, f, arg) < 0) {
__fl_put(f);
arg->stop = 1;
break;
}
__fl_put(f);
- arg->cookie++;
arg->count++;
}
+ arg->cookie = id;
}
static struct cls_fl_filter *
--
2.21.0
^ permalink raw reply related
* [Patch net 1/3] idr: fix overflow case for idr_for_each_entry_ul()
From: Cong Wang @ 2019-06-28 18:03 UTC (permalink / raw)
To: netdev; +Cc: dcaratti, chrism, willy, Cong Wang, Li Shuang
In-Reply-To: <20190628180343.8230-1-xiyou.wangcong@gmail.com>
idr_for_each_entry_ul() is buggy as it can't handle overflow
case correctly. When we have an ID == UINT_MAX, it becomes an
infinite loop. This happens when running on 32-bit CPU where
unsigned long has the same size with unsigned int.
There is no better way to fix this than casting it to a larger
integer, but we can't just 64 bit integer on 32 bit CPU. Instead
we could just use an additional integer to help us to detect this
overflow case, that is, adding a new parameter to this macro.
Fortunately tc action is its only user right now.
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Reported-by: Li Shuang <shuali@redhat.com>
Tested-by: Davide Caratti <dcaratti@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Chris Mi <chrism@mellanox.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/linux/idr.h | 7 +++++--
net/sched/act_api.c | 9 ++++++---
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/idr.h b/include/linux/idr.h
index ee7abae143d3..68528a72d10d 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -191,14 +191,17 @@ static inline void idr_preload_end(void)
* idr_for_each_entry_ul() - Iterate over an IDR's elements of a given type.
* @idr: IDR handle.
* @entry: The type * to use as cursor.
+ * @tmp: A temporary placeholder for ID.
* @id: Entry ID.
*
* @entry and @id do not need to be initialized before the loop, and
* after normal termination @entry is left with the value NULL. This
* is convenient for a "not found" value.
*/
-#define idr_for_each_entry_ul(idr, entry, id) \
- for (id = 0; ((entry) = idr_get_next_ul(idr, &(id))) != NULL; ++id)
+#define idr_for_each_entry_ul(idr, entry, tmp, id) \
+ for (tmp = 0, id = 0; \
+ tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \
+ tmp = id, ++id)
/**
* idr_for_each_entry_continue() - Continue iteration over an IDR's elements of a given type
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 5567af5d7cb5..835adde28a7e 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -221,12 +221,13 @@ static int tcf_dump_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
struct idr *idr = &idrinfo->action_idr;
struct tc_action *p;
unsigned long id = 1;
+ unsigned long tmp;
mutex_lock(&idrinfo->lock);
s_i = cb->args[0];
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
index++;
if (index < s_i)
continue;
@@ -292,6 +293,7 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
struct idr *idr = &idrinfo->action_idr;
struct tc_action *p;
unsigned long id = 1;
+ unsigned long tmp;
nest = nla_nest_start_noflag(skb, 0);
if (nest == NULL)
@@ -300,7 +302,7 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
goto nla_put_failure;
mutex_lock(&idrinfo->lock);
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
ret = tcf_idr_release_unsafe(p);
if (ret == ACT_P_DELETED) {
module_put(ops->owner);
@@ -533,8 +535,9 @@ void tcf_idrinfo_destroy(const struct tc_action_ops *ops,
struct tc_action *p;
int ret;
unsigned long id = 1;
+ unsigned long tmp;
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
ret = __tcf_idr_release(p, false, true);
if (ret == ACT_P_DELETED)
module_put(ops->owner);
--
2.21.0
^ permalink raw reply related
* [Patch net 0/3] idr: fix overflow cases on 32-bit CPU
From: Cong Wang @ 2019-06-28 18:03 UTC (permalink / raw)
To: netdev; +Cc: dcaratti, chrism, willy, Cong Wang
idr_get_next_ul() is problematic by design, it can't handle
the following overflow case well on 32-bit CPU:
u32 id = UINT_MAX;
idr_alloc_u32(&id);
while (idr_get_next_ul(&id) != NULL)
id++;
when 'id' overflows and becomes 0 after UINT_MAX, the loop
goes infinite.
Fix this by eliminating external users of idr_get_next_ul()
and migrating them to idr_for_each_entry_continue_ul(). And
add an additional parameter for these iteration macros to detect
overflow properly.
Please merge this through networking tree, as all the users
are in networking subsystem.
Cong Wang (2):
idr: fix overflow case for idr_for_each_entry_ul()
idr: introduce idr_for_each_entry_continue_ul()
Davide Caratti (1):
selftests: add a test case for cls_lower handle overflow
---
.../ethernet/mellanox/mlx5/core/fs_counters.c | 10 ++++---
include/linux/idr.h | 21 +++++++++++++--
net/sched/act_api.c | 9 ++++---
net/sched/cls_flower.c | 27 +++++--------------
.../tc-testing/tc-tests/filters/tests.json | 19 +++++++++++++
5 files changed, 57 insertions(+), 29 deletions(-)
--
2.21.0
^ 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