* Re: [PATCH v7 net-next 0/5] add PLCA RS support and onsemi NCN26000
From: Jakub Kicinski @ 2022-12-17 4:45 UTC (permalink / raw)
To: Piergiorgio Beruto
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev, Oleksij Rempel
In-Reply-To: <cover.1671234284.git.piergiorgio.beruto@gmail.com>
On Sat, 17 Dec 2022 01:48:09 +0100 Piergiorgio Beruto wrote:
> This patchset adds support for getting/setting the Physical Layer
> Collision Avoidace (PLCA) Reconciliation Sublayer (RS) configuration and
> status on Ethernet PHYs that supports it.
# Form letter - net-next is closed
We have already submitted the networking pull request to Linus
for v6.2 and therefore net-next is closed for new drivers, features,
code refactoring and optimizations. We are currently accepting
bug fixes only.
Please repost when net-next reopens after Jan 2nd.
RFC patches sent for review only are obviously welcome at any time.
^ permalink raw reply
* Re: [PATCH v7 net-next 2/5] drivers/net/phy: add the link modes for the 10BASE-T1S Ethernet PHY
From: Jakub Kicinski @ 2022-12-17 4:48 UTC (permalink / raw)
To: Piergiorgio Beruto
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev, Oleksij Rempel
In-Reply-To: <fb30ee5dae667a5dfb398171263be7edca6b6b87.1671234284.git.piergiorgio.beruto@gmail.com>
On Sat, 17 Dec 2022 01:48:33 +0100 Piergiorgio Beruto wrote:
> +const int phy_basic_t1s_p2mp_features_array[2] = {
> + ETHTOOL_LINK_MODE_TP_BIT,
> + ETHTOOL_LINK_MODE_10baseT1S_P2MP_Half_BIT,
> +};
> +EXPORT_SYMBOL_GPL(phy_basic_t1s_p2mp_features_array);
Should this be exported? It's not listed in the header.
^ permalink raw reply
* Re: [PATCH v2 2/4] sched/isolation: Improve documentation
From: Leonardo Brás @ 2022-12-17 5:04 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Bjorn Helgaas,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Daniel Bristot de Oliveira, Valentin Schneider, Tejun Heo,
Lai Jiangshan, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Phil Auld, Antoine Tenart, Christophe JAILLET, Wang Yufen,
mtosatti, linux-crypto, linux-kernel, linux-pci, netdev
In-Reply-To: <20221129115439.GA1715045@lothringen>
On Tue, 2022-11-29 at 12:54 +0100, Frederic Weisbecker wrote:
> On Thu, Oct 13, 2022 at 03:40:27PM -0300, Leonardo Bras wrote:
> > Improve documentation on housekeeping types and what to expect from
> > housekeeping functions.
> >
> > Signed-off-by: Leonardo Bras <leobras@redhat.com>
> > ---
> > include/linux/sched/isolation.h | 25 ++++++++++++++++---------
> > 1 file changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h
> > index 762701f295d1c..9333c28153a7a 100644
> > --- a/include/linux/sched/isolation.h
> > +++ b/include/linux/sched/isolation.h
> > @@ -7,18 +7,25 @@
> > #include <linux/tick.h>
> >
> > enum hk_type {
> > - HK_TYPE_TIMER,
> > - HK_TYPE_RCU,
> > - HK_TYPE_MISC,
> > - HK_TYPE_SCHED,
> > - HK_TYPE_TICK,
> > - HK_TYPE_DOMAIN,
> > - HK_TYPE_WQ,
> > - HK_TYPE_MANAGED_IRQ,
> > - HK_TYPE_KTHREAD,
> > + HK_TYPE_TIMER, /* Timer interrupt, watchdogs */
>
> More precisely:
>
> /* Unbound timer callbacks */
>
> > + HK_TYPE_RCU, /* RCU callbacks */
>
> More generally, because it's more than just about callbacks:
>
> /* Unbound RCU work */
Both updated, thanks!
Out of curiosity, what does 'Unbound' means in this context?
>
> > + HK_TYPE_MISC, /* Minor housekeeping categories */
> > + HK_TYPE_SCHED, /* Scheduling and idle load balancing */
> > + HK_TYPE_TICK, /* See isolcpus=nohz boot parameter */
>
> Yes or nohz_full=
>
> > + HK_TYPE_DOMAIN, /* See isolcpus=domain boot parameter*/
> > + HK_TYPE_WQ, /* Work Queues*/
>
> /* Unbound workqueues */
>
> > + HK_TYPE_MANAGED_IRQ, /* See isolcpus=managed_irq boot parameter */
> > + HK_TYPE_KTHREAD, /* kernel threads */
>
> /* Unbound kernel threads */
>
>
> > HK_TYPE_MAX
> > };
> >
> > +/* Kernel parameters like nohz_full and isolcpus allow passing cpu numbers
> > + * for disabling housekeeping types.
> > + *
> > + * The functions bellow work the opposite way, by referencing which cpus
> > + * are able to perform the housekeeping type in parameter.
> > + */
>
> *below
>
> Thanks!
Done, done, done, done.
Thanks a lot for reviewing!
Best regards,
Leo
>
> > +
> > #ifdef CONFIG_CPU_ISOLATION
> > DECLARE_STATIC_KEY_FALSE(housekeeping_overridden);
> > int housekeeping_any_cpu(enum hk_type type);
> > --
> > 2.38.0
> >
>
^ permalink raw reply
* Re: KASAN: use-after-free Read in ___bpf_prog_run
From: Yonghong Song @ 2022-12-17 5:07 UTC (permalink / raw)
To: Hao Sun, bpf
Cc: Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, David Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Linux Kernel Mailing List,
netdev
In-Reply-To: <CACkBjsbS0jeOUFzxWH-bBay9=cTQ_S2JbMnAa7V2sHpp_19PPw@mail.gmail.com>
On 12/14/22 11:49 PM, Hao Sun wrote:
> Hi,
>
> The following KASAN report can be triggered by loading and test
> running this simple BPF prog with a random data/ctx:
>
> 0: r0 = bpf_get_current_task_btf ;
> R0_w=trusted_ptr_task_struct(off=0,imm=0)
> 1: r0 = *(u32 *)(r0 +8192) ;
> R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
> 2: exit
>
> I've simplified the C reproducer but didn't find the root cause.
> JIT was disabled, and the interpreter triggered UAF when executing
> the load insn. A slab-out-of-bound read can also be triggered:
> https://pastebin.com/raw/g9zXr8jU
>
> This can be reproduced on:
>
> HEAD commit: b148c8b9b926 selftests/bpf: Add few corner cases to test
> padding handling of btf_dump
> git tree: bpf-next
> console log: https://pastebin.com/raw/1EUi9tJe
> kernel config: https://pastebin.com/raw/rgY3AJDZ
> C reproducer: https://pastebin.com/raw/cfVGuCBm
I I tried with your above kernel config and C reproducer and cannot
reproduce the kasan issue you reported.
[root@arch-fb-vm1 bpf-next]# ./a.out
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
0: (85) call bpf_get_current_task_btf#158 ;
R0_w=trusted_ptr_task_struct(off=0,imm=0)
1: (61) r0 = *(u32 *)(r0 +8192) ;
R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
2: (95) exit
processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0
prog fd: 3
[root@arch-fb-vm1 bpf-next]#
Your config indeed has kasan on.
>
> ==================================================================
> BUG: KASAN: use-after-free in ___bpf_prog_run+0x7f35/0x8fd0
> kernel/bpf/core.c:1937
> Read of size 4 at addr ffff88801f1f2000 by task a.out/7137
>
> CPU: 3 PID: 7137 Comm: a.out Not tainted
> 6.1.0-rc8-02212-gef3911a3e4d6-dirty #137
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux
> 1.16.1-1-1 04/01/2014
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
> print_address_description mm/kasan/report.c:284 [inline]
> print_report+0x167/0x46c mm/kasan/report.c:395
> kasan_report+0xbf/0x1e0 mm/kasan/report.c:495
> ___bpf_prog_run+0x7f35/0x8fd0 kernel/bpf/core.c:1937
> __bpf_prog_run32+0x9d/0xe0 kernel/bpf/core.c:2045
> bpf_dispatcher_nop_func include/linux/bpf.h:1082 [inline]
> __bpf_prog_run include/linux/filter.h:600 [inline]
> bpf_prog_run include/linux/filter.h:607 [inline]
> bpf_test_run+0x38e/0x980 net/bpf/test_run.c:402
> bpf_prog_test_run_skb+0xb67/0x1dc0 net/bpf/test_run.c:1187
> bpf_prog_test_run kernel/bpf/syscall.c:3644 [inline]
> __sys_bpf+0x1293/0x5840 kernel/bpf/syscall.c:4997
> __do_sys_bpf kernel/bpf/syscall.c:5083 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:5081 [inline]
> __x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:5081
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7fb8adae4469
> Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
> RSP: 002b:00007fff514ad148 EFLAGS: 00000203 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb8adae4469
> RDX: 0000000000000025 RSI: 0000000020000200 RDI: 000000000000000a
> RBP: 00007fff514ae2f0 R08: 00007fb8adb2dd70 R09: 00000b4100000218
> R10: e67c061720b91d86 R11: 0000000000000203 R12: 000055ed87c00760
> R13: 00007fff514ae3d0 R14: 0000000000000000 R15: 0000000000000000
> </TASK>
>
> Allocated by task 7128:
> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
> kasan_set_track+0x25/0x30 mm/kasan/common.c:52
> __kasan_slab_alloc+0x84/0x90 mm/kasan/common.c:325
> kasan_slab_alloc include/linux/kasan.h:201 [inline]
> slab_post_alloc_hook mm/slab.h:737 [inline]
> slab_alloc_node mm/slub.c:3398 [inline]
> kmem_cache_alloc_node+0x166/0x410 mm/slub.c:3443
> alloc_task_struct_node kernel/fork.c:171 [inline]
> dup_task_struct kernel/fork.c:966 [inline]
> copy_process+0x5db/0x6f40 kernel/fork.c:2084
> kernel_clone+0xe8/0x980 kernel/fork.c:2671
> __do_sys_clone+0xc0/0x100 kernel/fork.c:2812
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Freed by task 0:
> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
> kasan_set_track+0x25/0x30 mm/kasan/common.c:52
> kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:511
> ____kasan_slab_free mm/kasan/common.c:236 [inline]
> ____kasan_slab_free+0x15e/0x1b0 mm/kasan/common.c:200
> kasan_slab_free include/linux/kasan.h:177 [inline]
> slab_free_hook mm/slub.c:1724 [inline]
> slab_free_freelist_hook+0x10b/0x1e0 mm/slub.c:1750
> slab_free mm/slub.c:3661 [inline]
> kmem_cache_free+0xee/0x5b0 mm/slub.c:3683
> put_task_struct include/linux/sched/task.h:119 [inline]
> delayed_put_task_struct+0x274/0x3e0 kernel/exit.c:178
> rcu_do_batch kernel/rcu/tree.c:2250 [inline]
> rcu_core+0x835/0x1980 kernel/rcu/tree.c:2510
> __do_softirq+0x1f7/0xaf6 kernel/softirq.c:571
>
> Last potentially related work creation:
> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
> __kasan_record_aux_stack+0xbf/0xd0 mm/kasan/generic.c:481
> call_rcu+0x9e/0x790 kernel/rcu/tree.c:2798
> put_task_struct_rcu_user kernel/exit.c:184 [inline]
> put_task_struct_rcu_user+0x83/0xc0 kernel/exit.c:181
> release_task+0xe9e/0x1ae0 kernel/exit.c:234
> wait_task_zombie kernel/exit.c:1136 [inline]
> wait_consider_task+0x17d8/0x3e70 kernel/exit.c:1363
> do_wait_thread kernel/exit.c:1426 [inline]
> do_wait+0x75f/0xdc0 kernel/exit.c:1543
> kernel_wait4+0x153/0x260 kernel/exit.c:1706
> __do_sys_wait4+0x147/0x160 kernel/exit.c:1734
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Second to last potentially related work creation:
> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
> __kasan_record_aux_stack+0xbf/0xd0 mm/kasan/generic.c:481
> call_rcu+0x9e/0x790 kernel/rcu/tree.c:2798
> put_task_struct_rcu_user kernel/exit.c:184 [inline]
> put_task_struct_rcu_user+0x83/0xc0 kernel/exit.c:181
> release_task+0xe9e/0x1ae0 kernel/exit.c:234
> wait_task_zombie kernel/exit.c:1136 [inline]
> wait_consider_task+0x17d8/0x3e70 kernel/exit.c:1363
> do_wait_thread kernel/exit.c:1426 [inline]
> do_wait+0x75f/0xdc0 kernel/exit.c:1543
> kernel_wait4+0x153/0x260 kernel/exit.c:1706
> __do_sys_wait4+0x147/0x160 kernel/exit.c:1734
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> The buggy address belongs to the object at ffff88801f1f1d80
> which belongs to the cache task_struct of size 7240
> The buggy address is located 640 bytes inside of
> 7240-byte region [ffff88801f1f1d80, ffff88801f1f39c8)
>
> The buggy address belongs to the physical page:
> page:ffffea00007c7c00 refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x1f1f0
> head:ffffea00007c7c00 order:3 compound_mapcount:0 compound_pincount:0
> memcg:ffff888013b2c081
> flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
> raw: 00fff00000010200 ffffea00005e4200 dead000000000002 ffff88801322a000
> raw: 0000000000000000 0000000080040004 00000001ffffffff ffff888013b2c081
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 3, migratetype Unmovable, gfp_mask
> 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC),
> pid 16, tgid 16 (kworker/u17:1), ts 3731671201, free_ts 0
> prep_new_page mm/page_alloc.c:2539 [inline]
> get_page_from_freelist+0x10ce/0x2db0 mm/page_alloc.c:4291
> __alloc_pages+0x1c8/0x5c0 mm/page_alloc.c:5558
> alloc_pages+0x1a9/0x270 mm/mempolicy.c:2285
> alloc_slab_page mm/slub.c:1794 [inline]
> allocate_slab+0x24e/0x340 mm/slub.c:1939
> new_slab mm/slub.c:1992 [inline]
> ___slab_alloc+0x89a/0x1400 mm/slub.c:3180
> __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279
> slab_alloc_node mm/slub.c:3364 [inline]
> kmem_cache_alloc_node+0x12e/0x410 mm/slub.c:3443
> alloc_task_struct_node kernel/fork.c:171 [inline]
> dup_task_struct kernel/fork.c:966 [inline]
> copy_process+0x5db/0x6f40 kernel/fork.c:2084
> kernel_clone+0xe8/0x980 kernel/fork.c:2671
> user_mode_thread+0xb4/0xf0 kernel/fork.c:2747
> call_usermodehelper_exec_work kernel/umh.c:175 [inline]
> call_usermodehelper_exec_work+0xcb/0x170 kernel/umh.c:161
> process_one_work+0xa33/0x1720 kernel/workqueue.c:2289
> worker_thread+0x67d/0x10e0 kernel/workqueue.c:2436
> kthread+0x2e4/0x3a0 kernel/kthread.c:376
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
> page_owner free stack trace missing
>
> Memory state around the buggy address:
> ffff88801f1f1f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88801f1f1f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88801f1f2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88801f1f2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88801f1f2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
^ permalink raw reply
* Re: [PATCH net] devlink: protect devlink dump by the instance lock
From: patchwork-bot+netdevbpf @ 2022-12-17 5:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, jacob.e.keller, jiri, moshe
In-Reply-To: <20221216044122.1863550-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 15 Dec 2022 20:41:22 -0800 you wrote:
> Take the instance lock around devlink_nl_fill() when dumping,
> doit takes it already.
>
> We are only dumping basic info so in the worst case we were risking
> data races around the reload statistics. Also note that the reloads
> themselves had not been under the instance lock until recently, so
> the selection of the Fixes tag is inherently questionable.
>
> [...]
Here is the summary with links:
- [net] devlink: protect devlink dump by the instance lock
https://git.kernel.org/netdev/net/c/214964a13ab5
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: am65-cpsw: fix CONFIG_PM #ifdef
From: patchwork-bot+netdevbpf @ 2022-12-17 5:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: davem, edumazet, kuba, pabeni, arnd, rogerq, s-vadapalli, jiri,
netdev, linux-kernel
In-Reply-To: <20221215163918.611609-1-arnd@kernel.org>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 15 Dec 2022 17:39:05 +0100 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The #ifdef check is incorrect and leads to a warning:
>
> drivers/net/ethernet/ti/am65-cpsw-nuss.c:1679:13: error: 'am65_cpsw_nuss_remove_rx_chns' defined but not used [-Werror=unused-function]
> 1679 | static void am65_cpsw_nuss_remove_rx_chns(void *data)
>
> [...]
Here is the summary with links:
- net: ethernet: ti: am65-cpsw: fix CONFIG_PM #ifdef
https://git.kernel.org/netdev/net/c/078838f5b9c9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] octeontx2_pf: Select NET_DEVLINK when enabling OCTEONTX2_PF
From: Jakub Kicinski @ 2022-12-17 5:29 UTC (permalink / raw)
To: Paul Gazzillo
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Randy Dunlap,
Zheng Bin, Yang Yingliang, Suman Ghosh, netdev, linux-kernel
In-Reply-To: <20221216215509.821591-1-paul@pgazz.com>
On Fri, 16 Dec 2022 16:54:48 -0500 Paul Gazzillo wrote:
> This fix adds "select NET_DEVLINK" link to OCTEONTX2_PF's Kconfig
> specification to match OCTEONTX2_AF.
Where was the use of devlink introduced in OCTEONTX2_PF?
Could you provide a Fixes tag?
^ permalink raw reply
* Re: [PATCH net v2] skbuff: Account for tail adjustment during pull operations
From: patchwork-bot+netdevbpf @ 2022-12-17 5:30 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: davem, edumazet, kuba, pabeni, shmulik, willemb, alexanderduyck,
netdev, daniel, quic_stranche
In-Reply-To: <1671084718-24796-1-git-send-email-quic_subashab@quicinc.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 14 Dec 2022 23:11:58 -0700 you wrote:
> Extending the tail can have some unexpected side effects if a program uses
> a helper like BPF_FUNC_skb_pull_data to read partial content beyond the
> head skb headlen when all the skbs in the gso frag_list are linear with no
> head_frag -
>
> kernel BUG at net/core/skbuff.c:4219!
> pc : skb_segment+0xcf4/0xd2c
> lr : skb_segment+0x63c/0xd2c
> Call trace:
> skb_segment+0xcf4/0xd2c
> __udp_gso_segment+0xa4/0x544
> udp4_ufo_fragment+0x184/0x1c0
> inet_gso_segment+0x16c/0x3a4
> skb_mac_gso_segment+0xd4/0x1b0
> __skb_gso_segment+0xcc/0x12c
> udp_rcv_segment+0x54/0x16c
> udp_queue_rcv_skb+0x78/0x144
> udp_unicast_rcv_skb+0x8c/0xa4
> __udp4_lib_rcv+0x490/0x68c
> udp_rcv+0x20/0x30
> ip_protocol_deliver_rcu+0x1b0/0x33c
> ip_local_deliver+0xd8/0x1f0
> ip_rcv+0x98/0x1a4
> deliver_ptype_list_skb+0x98/0x1ec
> __netif_receive_skb_core+0x978/0xc60
>
> [...]
Here is the summary with links:
- [net,v2] skbuff: Account for tail adjustment during pull operations
https://git.kernel.org/netdev/net/c/2d7afdcbc9d3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] mctp: serial: Fix starting value for frame check sequence
From: Jeremy Kerr @ 2022-12-17 6:44 UTC (permalink / raw)
To: Alexander H Duyck, netdev
Cc: Matt Johnston, David S. Miller, Jakub Kicinski, Eric Dumazet,
Paolo Abeni, Harsh Tyagi
In-Reply-To: <2eecaca2d1066d51d136a8d95b5cd2fd19e5e111.camel@gmail.com>
Hi Alexander.
> Since the starting value isn't unique would it possibly be worthwhile
> to look at adding a define to include/linux/crc-ccitt.h to be used to
> handle the cases where the initial value is 0xffff? I notice there
> seems to only be two starting values 0 and 0xffff for all callers so
> it might make sense to centralize it in one place.
Yep, that would make sense if they're commonly used values, but I'm not
sure that would be suitable to include that in this fix, as it would
just add disruption to any backport work.
Cheers,
Jeremy
^ permalink raw reply
* Re: KASAN: use-after-free Read in ___bpf_prog_run
From: Hao Sun @ 2022-12-17 6:54 UTC (permalink / raw)
To: Yonghong Song
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, David Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Linux Kernel Mailing List,
netdev
In-Reply-To: <52379286-960e-3fcd-84a2-3cab4d3b7c4e@meta.com>
> On 17 Dec 2022, at 1:07 PM, Yonghong Song <yhs@meta.com> wrote:
>
>
>
> On 12/14/22 11:49 PM, Hao Sun wrote:
>> Hi,
>> The following KASAN report can be triggered by loading and test
>> running this simple BPF prog with a random data/ctx:
>> 0: r0 = bpf_get_current_task_btf ;
>> R0_w=trusted_ptr_task_struct(off=0,imm=0)
>> 1: r0 = *(u32 *)(r0 +8192) ;
>> R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
>> 2: exit
>> I've simplified the C reproducer but didn't find the root cause.
>> JIT was disabled, and the interpreter triggered UAF when executing
>> the load insn. A slab-out-of-bound read can also be triggered:
>> https://pastebin.com/raw/g9zXr8jU
>> This can be reproduced on:
>> HEAD commit: b148c8b9b926 selftests/bpf: Add few corner cases to test
>> padding handling of btf_dump
>> git tree: bpf-next
>> console log: https://pastebin.com/raw/1EUi9tJe
>> kernel config: https://pastebin.com/raw/rgY3AJDZ
>> C reproducer: https://pastebin.com/raw/cfVGuCBm
>
> I I tried with your above kernel config and C reproducer and cannot reproduce the kasan issue you reported.
>
> [root@arch-fb-vm1 bpf-next]# ./a.out
> func#0 @0
> 0: R1=ctx(off=0,imm=0) R10=fp0
> 0: (85) call bpf_get_current_task_btf#158 ; R0_w=trusted_ptr_task_struct(off=0,imm=0)
> 1: (61) r0 = *(u32 *)(r0 +8192) ; R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
> 2: (95) exit
> processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
>
> prog fd: 3
> [root@arch-fb-vm1 bpf-next]#
>
> Your config indeed has kasan on.
Hi,
I can still reproduce this on a latest bpf-next build: 0e43662e61f25
(“tools/resolve_btfids: Use pkg-config to locate libelf”).
The simplified C reproducer sometime need to be run twice to trigger
the UAF. Also note that interpreter is required. Here is the original
C reproducer that loads and runs the BPF prog continuously for your
convenience:
https://pastebin.com/raw/WSJuNnVU
>
>> ==================================================================
>> BUG: KASAN: use-after-free in ___bpf_prog_run+0x7f35/0x8fd0
>> kernel/bpf/core.c:1937
>> Read of size 4 at addr ffff88801f1f2000 by task a.out/7137
>> CPU: 3 PID: 7137 Comm: a.out Not tainted
>> 6.1.0-rc8-02212-gef3911a3e4d6-dirty #137
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux
>> 1.16.1-1-1 04/01/2014
>> Call Trace:
>> <TASK>
>> __dump_stack lib/dump_stack.c:88 [inline]
>> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
>> print_address_description mm/kasan/report.c:284 [inline]
>> print_report+0x167/0x46c mm/kasan/report.c:395
>> kasan_report+0xbf/0x1e0 mm/kasan/report.c:495
>> ___bpf_prog_run+0x7f35/0x8fd0 kernel/bpf/core.c:1937
>> __bpf_prog_run32+0x9d/0xe0 kernel/bpf/core.c:2045
>> bpf_dispatcher_nop_func include/linux/bpf.h:1082 [inline]
>> __bpf_prog_run include/linux/filter.h:600 [inline]
>> bpf_prog_run include/linux/filter.h:607 [inline]
>> bpf_test_run+0x38e/0x980 net/bpf/test_run.c:402
>> bpf_prog_test_run_skb+0xb67/0x1dc0 net/bpf/test_run.c:1187
>> bpf_prog_test_run kernel/bpf/syscall.c:3644 [inline]
>> __sys_bpf+0x1293/0x5840 kernel/bpf/syscall.c:4997
>> __do_sys_bpf kernel/bpf/syscall.c:5083 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:5081 [inline]
>> __x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:5081
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>> RIP: 0033:0x7fb8adae4469
>> Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48
>> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
>> 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
>> RSP: 002b:00007fff514ad148 EFLAGS: 00000203 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb8adae4469
>> RDX: 0000000000000025 RSI: 0000000020000200 RDI: 000000000000000a
>> RBP: 00007fff514ae2f0 R08: 00007fb8adb2dd70 R09: 00000b4100000218
>> R10: e67c061720b91d86 R11: 0000000000000203 R12: 000055ed87c00760
>> R13: 00007fff514ae3d0 R14: 0000000000000000 R15: 0000000000000000
>> </TASK>
>> Allocated by task 7128:
>> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
>> kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>> __kasan_slab_alloc+0x84/0x90 mm/kasan/common.c:325
>> kasan_slab_alloc include/linux/kasan.h:201 [inline]
>> slab_post_alloc_hook mm/slab.h:737 [inline]
>> slab_alloc_node mm/slub.c:3398 [inline]
>> kmem_cache_alloc_node+0x166/0x410 mm/slub.c:3443
>> alloc_task_struct_node kernel/fork.c:171 [inline]
>> dup_task_struct kernel/fork.c:966 [inline]
>> copy_process+0x5db/0x6f40 kernel/fork.c:2084
>> kernel_clone+0xe8/0x980 kernel/fork.c:2671
>> __do_sys_clone+0xc0/0x100 kernel/fork.c:2812
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>> Freed by task 0:
>> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
>> kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>> kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:511
>> ____kasan_slab_free mm/kasan/common.c:236 [inline]
>> ____kasan_slab_free+0x15e/0x1b0 mm/kasan/common.c:200
>> kasan_slab_free include/linux/kasan.h:177 [inline]
>> slab_free_hook mm/slub.c:1724 [inline]
>> slab_free_freelist_hook+0x10b/0x1e0 mm/slub.c:1750
>> slab_free mm/slub.c:3661 [inline]
>> kmem_cache_free+0xee/0x5b0 mm/slub.c:3683
>> put_task_struct include/linux/sched/task.h:119 [inline]
>> delayed_put_task_struct+0x274/0x3e0 kernel/exit.c:178
>> rcu_do_batch kernel/rcu/tree.c:2250 [inline]
>> rcu_core+0x835/0x1980 kernel/rcu/tree.c:2510
>> __do_softirq+0x1f7/0xaf6 kernel/softirq.c:571
>> Last potentially related work creation:
>> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
>> __kasan_record_aux_stack+0xbf/0xd0 mm/kasan/generic.c:481
>> call_rcu+0x9e/0x790 kernel/rcu/tree.c:2798
>> put_task_struct_rcu_user kernel/exit.c:184 [inline]
>> put_task_struct_rcu_user+0x83/0xc0 kernel/exit.c:181
>> release_task+0xe9e/0x1ae0 kernel/exit.c:234
>> wait_task_zombie kernel/exit.c:1136 [inline]
>> wait_consider_task+0x17d8/0x3e70 kernel/exit.c:1363
>> do_wait_thread kernel/exit.c:1426 [inline]
>> do_wait+0x75f/0xdc0 kernel/exit.c:1543
>> kernel_wait4+0x153/0x260 kernel/exit.c:1706
>> __do_sys_wait4+0x147/0x160 kernel/exit.c:1734
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>> Second to last potentially related work creation:
>> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
>> __kasan_record_aux_stack+0xbf/0xd0 mm/kasan/generic.c:481
>> call_rcu+0x9e/0x790 kernel/rcu/tree.c:2798
>> put_task_struct_rcu_user kernel/exit.c:184 [inline]
>> put_task_struct_rcu_user+0x83/0xc0 kernel/exit.c:181
>> release_task+0xe9e/0x1ae0 kernel/exit.c:234
>> wait_task_zombie kernel/exit.c:1136 [inline]
>> wait_consider_task+0x17d8/0x3e70 kernel/exit.c:1363
>> do_wait_thread kernel/exit.c:1426 [inline]
>> do_wait+0x75f/0xdc0 kernel/exit.c:1543
>> kernel_wait4+0x153/0x260 kernel/exit.c:1706
>> __do_sys_wait4+0x147/0x160 kernel/exit.c:1734
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>> The buggy address belongs to the object at ffff88801f1f1d80
>> which belongs to the cache task_struct of size 7240
>> The buggy address is located 640 bytes inside of
>> 7240-byte region [ffff88801f1f1d80, ffff88801f1f39c8)
>> The buggy address belongs to the physical page:
>> page:ffffea00007c7c00 refcount:1 mapcount:0 mapping:0000000000000000
>> index:0x0 pfn:0x1f1f0
>> head:ffffea00007c7c00 order:3 compound_mapcount:0 compound_pincount:0
>> memcg:ffff888013b2c081
>> flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
>> raw: 00fff00000010200 ffffea00005e4200 dead000000000002 ffff88801322a000
>> raw: 0000000000000000 0000000080040004 00000001ffffffff ffff888013b2c081
>> page dumped because: kasan: bad access detected
>> page_owner tracks the page as allocated
>> page last allocated via order 3, migratetype Unmovable, gfp_mask
>> 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC),
>> pid 16, tgid 16 (kworker/u17:1), ts 3731671201, free_ts 0
>> prep_new_page mm/page_alloc.c:2539 [inline]
>> get_page_from_freelist+0x10ce/0x2db0 mm/page_alloc.c:4291
>> __alloc_pages+0x1c8/0x5c0 mm/page_alloc.c:5558
>> alloc_pages+0x1a9/0x270 mm/mempolicy.c:2285
>> alloc_slab_page mm/slub.c:1794 [inline]
>> allocate_slab+0x24e/0x340 mm/slub.c:1939
>> new_slab mm/slub.c:1992 [inline]
>> ___slab_alloc+0x89a/0x1400 mm/slub.c:3180
>> __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279
>> slab_alloc_node mm/slub.c:3364 [inline]
>> kmem_cache_alloc_node+0x12e/0x410 mm/slub.c:3443
>> alloc_task_struct_node kernel/fork.c:171 [inline]
>> dup_task_struct kernel/fork.c:966 [inline]
>> copy_process+0x5db/0x6f40 kernel/fork.c:2084
>> kernel_clone+0xe8/0x980 kernel/fork.c:2671
>> user_mode_thread+0xb4/0xf0 kernel/fork.c:2747
>> call_usermodehelper_exec_work kernel/umh.c:175 [inline]
>> call_usermodehelper_exec_work+0xcb/0x170 kernel/umh.c:161
>> process_one_work+0xa33/0x1720 kernel/workqueue.c:2289
>> worker_thread+0x67d/0x10e0 kernel/workqueue.c:2436
>> kthread+0x2e4/0x3a0 kernel/kthread.c:376
>> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
>> page_owner free stack trace missing
>> Memory state around the buggy address:
>> ffff88801f1f1f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88801f1f1f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>> ffff88801f1f2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ^
>> ffff88801f1f2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88801f1f2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
^ permalink raw reply
* Re: [PATCH 4.19 000/338] 4.19.238-rc1 review
From: Michael Nazzareno Trimarchi @ 2022-12-17 9:01 UTC (permalink / raw)
To: Trond Myklebust
Cc: Neil Brown, Naresh Kamboju, Greg Kroah-Hartman,
Linux Kernel Mailing List, stable@vger.kernel.org, Linus Torvalds,
Andrew Morton, linux@roeck-us.net, shuah@kernel.org,
patches@kernelci.org, lkft-triage@lists.linaro.org, pavel@denx.de,
jonathanh@nvidia.com, f.fainelli@gmail.com,
sudipm.mukherjee@gmail.com, slade@sladewatkins.com, Netdev,
David S. Miller, Jakub Kicinski, Paolo Abeni,
linux-nfs@vger.kernel.org, Anna Schumaker
In-Reply-To: <332A0C50-D53E-4C86-9795-6238C961C869@hammerspace.com>
Hi
On Fri, Dec 16, 2022 at 10:25 PM Trond Myklebust
<trondmy@hammerspace.com> wrote:
>
>
>
> > On Dec 16, 2022, at 13:31, Michael Trimarchi <michael@amarulasolutions.com> wrote:
> >
> > [You don't often get email from michael@amarulasolutions.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Neil
> >
> > On Tue, Apr 26, 2022 at 12:29:55PM +1000, NeilBrown wrote:
> >> On Thu, 21 Apr 2022, Naresh Kamboju wrote:
> >>> On Mon, 18 Apr 2022 at 14:09, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >>>>
> >>>> On Thu, 14 Apr 2022 at 18:45, Greg Kroah-Hartman
> >>>> <gregkh@linuxfoundation.org> wrote:
> >>>>>
> >>>>> This is the start of the stable review cycle for the 4.19.238 release.
> >>>>> There are 338 patches in this series, all will be posted as a response
> >>>>> to this one. If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>>
> >>>>> Responses should be made by Sat, 16 Apr 2022 11:07:54 +0000.
> >>>>> Anything received after that time might be too late.
> >>>>>
> >>>>> The whole patch series can be found in one patch at:
> >>>>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.238-rc1.gz
> >>>>> or in the git tree and branch at:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> >>>>> and the diffstat can be found below.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>
> >>>>
> >>>> Following kernel warning noticed on arm64 Juno-r2 while booting
> >>>> stable-rc 4.19.238. Here is the full test log link [1].
> >>>>
> >>>> [ 0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
> >>>> [ 0.000000] Linux version 4.19.238 (tuxmake@tuxmake) (gcc version
> >>>> 11.2.0 (Debian 11.2.0-18)) #1 SMP PREEMPT @1650206156
> >>>> [ 0.000000] Machine model: ARM Juno development board (r2)
> >>>> <trim>
> >>>> [ 18.499895] ================================
> >>>> [ 18.504172] WARNING: inconsistent lock state
> >>>> [ 18.508451] 4.19.238 #1 Not tainted
> >>>> [ 18.511944] --------------------------------
> >>>> [ 18.516222] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> >>>> [ 18.522242] kworker/u12:3/60 [HC0[0]:SC0[0]:HE1:SE1] takes:
> >>>> [ 18.527826] (____ptrval____)
> >>>> (&(&xprt->transport_lock)->rlock){+.?.}, at: xprt_destroy+0x70/0xe0
> >>>> [ 18.536648] {IN-SOFTIRQ-W} state was registered at:
> >>>> [ 18.541543] lock_acquire+0xc8/0x23c
> >>
> >> Prior to Linux 5.3, ->transport_lock needs spin_lock_bh() and
> >> spin_unlock_bh().
> >>
> >
> > We get the same deadlock or similar one and we think that
> > can be connected to this thread on 4.19.243. For us is a bit
> > difficult to hit but we are going to apply this change
> >
> > net: sunrpc: Fix deadlock in xprt_destroy
> >
> > Prior to Linux 5.3, ->transport_lock needs spin_lock_bh() and
> > spin_unlock_bh().
> >
> > Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > ---
> > net/sunrpc/xprt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > index d05fa7c36d00..b1abf4848bbc 100644
> > --- a/net/sunrpc/xprt.c
> > +++ b/net/sunrpc/xprt.c
> > @@ -1550,9 +1550,9 @@ static void xprt_destroy(struct rpc_xprt *xprt)
> > * is cleared. We use ->transport_lock to ensure the mod_timer()
> > * can only run *before* del_time_sync(), never after.
> > */
> > - spin_lock(&xprt->transport_lock);
> > + spin_lock_bh(&xprt->transport_lock);
> > del_timer_sync(&xprt->timer);
> > - spin_unlock(&xprt->transport_lock);
> > + spin_unlock_bh(&xprt->transport_lock);
> >
> > /*
> > * Destroy sockets etc from the system workqueue so they can
> > —
>
> Agreed. When backporting to kernels that are older than 5.3.x, the transport lock needs to be taken using the bh-safe spin lock variants.
>
> Reviewed-by: Trond Myklebust <trond.myklebust@hammerspace.com <mailto:trond.myklebust@hammerspace.com>>
>
Seems already applied, but for some reason I miss it. I will re-align
to stable again
Michael
> _________________________________
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com
^ permalink raw reply
* WARNING in nla_get_range_unsigned
From: Wei Chen @ 2022-12-17 9:24 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <CAO4mrffa_3PhjfA9hxTq_U9GjC++0suGnme9oNcKE=Gn+g1iRg@mail.gmail.com>
Dear Linux Developers,
Recently, when using our tool to fuzz kernel, the following crash was
triggered. Although this crash has been reported by syzbot
https://syzkaller.appspot.com/bug?id=32e20c07949c6d6006f26466022469e33ae69108
and fixed in commit netlink: policy: correct validation type check
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c30a3c957c885e618ddffc065f888be4f8d5a9bd,
it still happens in the latest kernel version.
HEAD commit: 76dcd734eca
git tree: linux-next
compiler: clang 12.0.0
console output:
https://drive.google.com/file/d/1reeOfFkfJp4-GUz_uMTh-uWXPLBJDcA6/view?usp=share_link
kernel config: https://drive.google.com/file/d/1jH4qV5XblPADvMDUlvS7DwtW0FroMoVB/view?usp=share_link
syz repro: https://drive.google.com/file/d/1Ong8vQn675RFU7R1O5HfiwWxp4UhnaIF/view?usp=share_link
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: Wei Chen <harperchen1110@gmail.com>
------------[ cut here ]------------
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Code: 8d ff 49 8b 75 08 ba 10 00 00 00 4c 89 f7 e8 0f d8 f8 02 5b 41
5c 41 5d 41 5e 41 5f 5d c3 e8 0f 57 7a ff eb 05 e8 08 57 7a ff <0f> 0b
e9 a9 fe ff ff 90 55 41 57 41 56 41 54 53 49 89 f6 49 89 fc
RSP: 0018:ffffc90002df39b8 EFLAGS: 00010287
RAX: ffffffff81ad2f51 RBX: ffffffff85364d28 RCX: 0000000000040000
RDX: ffffc90000add000 RSI: 0000000000000268 RDI: 0000000000000269
RBP: 000000000000f940 R08: ffffffff81ad2dd8 R09: 0000000000000000
R10: 0001ffffffffffff R11: ffff888045136780 R12: ffff88803e174000
R13: ffffffff85364d20 R14: ffffc90002df3a30 R15: ffffffff85364d21
FS: 00007fab1e5c8700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000073f8d0 CR3: 000000004a789000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
<TASK>
__netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x38f/0x500 net/socket.c:2482
___sys_sendmsg net/socket.c:2536 [inline]
__sys_sendmsg+0x197/0x230 net/socket.c:2565
__do_sys_sendmsg net/socket.c:2574 [inline]
__se_sys_sendmsg net/socket.c:2572 [inline]
__x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4697f9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fab1e5c7c48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80
R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffd7c0e6920
</TASK>
---[ end trace 0000000000000000 ]---
Best,
Wei
^ permalink raw reply
* Re: [PATCH v7 net-next 0/5] add PLCA RS support and onsemi NCN26000
From: Piergiorgio Beruto @ 2022-12-17 10:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev, Oleksij Rempel
In-Reply-To: <20221216204538.75ee3846@kernel.org>
On Fri, Dec 16, 2022 at 08:45:38PM -0800, Jakub Kicinski wrote:
> On Sat, 17 Dec 2022 01:48:09 +0100 Piergiorgio Beruto wrote:
> > This patchset adds support for getting/setting the Physical Layer
> > Collision Avoidace (PLCA) Reconciliation Sublayer (RS) configuration and
> > status on Ethernet PHYs that supports it.
>
> # Form letter - net-next is closed
>
> We have already submitted the networking pull request to Linus
> for v6.2 and therefore net-next is closed for new drivers, features,
> code refactoring and optimizations. We are currently accepting
> bug fixes only.
>
> Please repost when net-next reopens after Jan 2nd.
>
> RFC patches sent for review only are obviously welcome at any time.
Hello Jakub, sorry for asking dumb questions, but what exactly "RFC"
means? I understand you cannot accept new submissions at this time, but
does this means the patchset I just submitted can still be reviewd so
they are ready for integration on Jan 2nd?
Thanks,
Piergiorgio
^ permalink raw reply
* Re: [PATCH v7 net-next 2/5] drivers/net/phy: add the link modes for the 10BASE-T1S Ethernet PHY
From: Piergiorgio Beruto @ 2022-12-17 10:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev, Oleksij Rempel
In-Reply-To: <20221216204808.4299a21e@kernel.org>
On Fri, Dec 16, 2022 at 08:48:08PM -0800, Jakub Kicinski wrote:
> On Sat, 17 Dec 2022 01:48:33 +0100 Piergiorgio Beruto wrote:
> > +const int phy_basic_t1s_p2mp_features_array[2] = {
> > + ETHTOOL_LINK_MODE_TP_BIT,
> > + ETHTOOL_LINK_MODE_10baseT1S_P2MP_Half_BIT,
> > +};
> > +EXPORT_SYMBOL_GPL(phy_basic_t1s_p2mp_features_array);
>
> Should this be exported? It's not listed in the header.
In my understanding PHY drivers can be compiled as modules, therefore
this should be exported? I see other features arrays being exported as
well. But If I'm overlooking something I'll be happy to change this.
Thanks,
Piergiorgio
^ permalink raw reply
* Re: [PATCH v7 net-next 2/5] drivers/net/phy: add the link modes for the 10BASE-T1S Ethernet PHY
From: Russell King (Oracle) @ 2022-12-17 10:32 UTC (permalink / raw)
To: Piergiorgio Beruto
Cc: Jakub Kicinski, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev, Oleksij Rempel
In-Reply-To: <Y52V/l2BG1WlHdft@gvm01>
On Sat, Dec 17, 2022 at 11:12:14AM +0100, Piergiorgio Beruto wrote:
> On Fri, Dec 16, 2022 at 08:48:08PM -0800, Jakub Kicinski wrote:
> > On Sat, 17 Dec 2022 01:48:33 +0100 Piergiorgio Beruto wrote:
> > > +const int phy_basic_t1s_p2mp_features_array[2] = {
> > > + ETHTOOL_LINK_MODE_TP_BIT,
> > > + ETHTOOL_LINK_MODE_10baseT1S_P2MP_Half_BIT,
> > > +};
> > > +EXPORT_SYMBOL_GPL(phy_basic_t1s_p2mp_features_array);
> >
> > Should this be exported? It's not listed in the header.
> In my understanding PHY drivers can be compiled as modules, therefore
> this should be exported? I see other features arrays being exported as
> well. But If I'm overlooking something I'll be happy to change this.
If something wants to make use of it, it needs a prototype in a header
file. An EXPORT_SYMBOL* only makes it visible to modules at run-time,
it doesn't make it build-time visible.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH] net: alx: Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
From: Christoph Heiss @ 2022-12-17 10:40 UTC (permalink / raw)
To: Chris Snook, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
Using these macros allows to remove an #ifdef-guard on CONFIG_PM_SLEEP.
No functional changes.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
---
drivers/net/ethernet/atheros/alx/main.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
index d30d11872719..306393f8eeca 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1905,7 +1905,6 @@ static void alx_remove(struct pci_dev *pdev)
free_netdev(alx->dev);
}
-#ifdef CONFIG_PM_SLEEP
static int alx_suspend(struct device *dev)
{
struct alx_priv *alx = dev_get_drvdata(dev);
@@ -1951,12 +1950,7 @@ static int alx_resume(struct device *dev)
return err;
}
-static SIMPLE_DEV_PM_OPS(alx_pm_ops, alx_suspend, alx_resume);
-#define ALX_PM_OPS (&alx_pm_ops)
-#else
-#define ALX_PM_OPS NULL
-#endif
-
+static DEFINE_SIMPLE_DEV_PM_OPS(alx_pm_ops, alx_suspend, alx_resume);
static pci_ers_result_t alx_pci_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
@@ -2055,7 +2049,7 @@ static struct pci_driver alx_driver = {
.probe = alx_probe,
.remove = alx_remove,
.err_handler = &alx_err_handlers,
- .driver.pm = ALX_PM_OPS,
+ .driver.pm = pm_sleep_ptr(&alx_pm_ops),
};
module_pci_driver(alx_driver);
--
2.39.0
^ permalink raw reply related
* Re: WARNING in nla_get_range_unsigned
From: Ido Schimmel @ 2022-12-17 14:19 UTC (permalink / raw)
To: Wei Chen, johannes.berg
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, netdev,
Paolo Abeni, linux-kernel, syzkaller-bugs, syzbot
In-Reply-To: <CAO4mrffa_3PhjfA9hxTq_U9GjC++0suGnme9oNcKE=Gn+g1iRg@mail.gmail.com>
On Sat, Dec 17, 2022 at 05:21:24PM +0800, Wei Chen wrote:
> Dear Linux Developers,
>
> Recently, when using our tool to fuzz kernel, the following crash was
> triggered. Although this crash has been reported by syzbot
> https://syzkaller.appspot.com/bug?id=32e20c07949c6d6006f26466022469e33ae69108
> and fixed in commit netlink: policy: correct validation type check
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c30a3c957c885e618ddffc065f888be4f8d5a9bd>,
> it still happens in the latest kernel version.
>
> HEAD commit: 76dcd734eca
> git tree: linux-next
> compiler: clang 12.0.0
> console output:
> https://drive.google.com/file/d/1reeOfFkfJp4-GUz_uMTh-uWXPLBJDcA6/view?usp=share_link
> kernel config:
> https://drive.google.com/file/d/1jH4qV5XblPADvMDUlvS7DwtW0FroMoVB/view?usp=share_link
> syz repro:
> https://drive.google.com/file/d/1Ong8vQn675RFU7R1O5HfiwWxp4UhnaIF/view?usp=share_link
Can be reproduced with:
# tc action add mpls push label 3
Assuming you patch iproute2 to encode a wrong label length. For example:
diff --git a/tc/m_mpls.c b/tc/m_mpls.c
index 9b39d8533c21..2a43ca6c4dd3 100644
--- a/tc/m_mpls.c
+++ b/tc/m_mpls.c
@@ -191,7 +191,7 @@ static int parse_mpls(struct action_util *a, int *argc_p, char ***argv_p,
tail = addattr_nest(n, MAX_MSG, tca_id | NLA_F_NESTED);
addattr_l(n, MAX_MSG, TCA_MPLS_PARMS, &parm, sizeof(parm));
if (label != 0xffffffff)
- addattr_l(n, MAX_MSG, TCA_MPLS_LABEL, &label, sizeof(label));
+ addattr_l(n, MAX_MSG, TCA_MPLS_LABEL, &label, 8);
if (proto)
addattr_l(n, MAX_MSG, TCA_MPLS_PROTO, &proto, sizeof(proto));
if (tc != 0xff)
It does not seem valid to use NLA_POLICY_VALIDATE_FN() without
NLA_BINARY. Fixed for me by:
diff --git a/net/sched/act_mpls.c b/net/sched/act_mpls.c
index ff47ce4d3968..6b26bdb999d7 100644
--- a/net/sched/act_mpls.c
+++ b/net/sched/act_mpls.c
@@ -134,6 +134,11 @@ static int valid_label(const struct nlattr *attr,
{
const u32 *label = nla_data(attr);
+ if (nla_len(attr) != sizeof(*label)) {
+ NL_SET_ERR_MSG_MOD(extack, "Invalid MPLS label length");
+ return -EINVAL;
+ }
+
if (*label & ~MPLS_LABEL_MASK || *label == MPLS_LABEL_IMPLNULL) {
NL_SET_ERR_MSG_MOD(extack, "MPLS label out of range");
return -EINVAL;
@@ -145,7 +150,8 @@ static int valid_label(const struct nlattr *attr,
static const struct nla_policy mpls_policy[TCA_MPLS_MAX + 1] = {
[TCA_MPLS_PARMS] = NLA_POLICY_EXACT_LEN(sizeof(struct tc_mpls)),
[TCA_MPLS_PROTO] = { .type = NLA_U16 },
- [TCA_MPLS_LABEL] = NLA_POLICY_VALIDATE_FN(NLA_U32, valid_label),
+ [TCA_MPLS_LABEL] = NLA_POLICY_VALIDATE_FN(NLA_BINARY,
+ valid_label),
[TCA_MPLS_TC] = NLA_POLICY_RANGE(NLA_U8, 0, 7),
[TCA_MPLS_TTL] = NLA_POLICY_MIN(NLA_U8, 1),
[TCA_MPLS_BOS] = NLA_POLICY_RANGE(NLA_U8, 0, 1),
But please test with your reproducer as well.
For net-next we can try to remove the first argument from
NLA_POLICY_VALIDATE_FN() and set NLA_BINARY which is what everyone is
passing anyway.
Adding Johannes in case he has a better idea.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: Wei Chen <harperchen1110@gmail.com>
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
> nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
> Modules linked in:
> CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
> RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
> Code: 8d ff 49 8b 75 08 ba 10 00 00 00 4c 89 f7 e8 0f d8 f8 02 5b 41 5c 41
> 5d 41 5e 41 5f 5d c3 e8 0f 57 7a ff eb 05 e8 08 57 7a ff <0f> 0b e9 a9 fe
> ff ff 90 55 41 57 41 56 41 54 53 49 89 f6 49 89 fc
> RSP: 0018:ffffc90002df39b8 EFLAGS: 00010287
> RAX: ffffffff81ad2f51 RBX: ffffffff85364d28 RCX: 0000000000040000
> RDX: ffffc90000add000 RSI: 0000000000000268 RDI: 0000000000000269
> RBP: 000000000000f940 R08: ffffffff81ad2dd8 R09: 0000000000000000
> R10: 0001ffffffffffff R11: ffff888045136780 R12: ffff88803e174000
> R13: ffffffff85364d20 R14: ffffc90002df3a30 R15: ffffffff85364d21
> FS: 00007fab1e5c8700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000073f8d0 CR3: 000000004a789000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
> Call Trace:
> <TASK>
> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
> netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
> netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
> netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
> netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
> rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
> netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
> netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
> sock_sendmsg_nosec net/socket.c:714 [inline]
> sock_sendmsg net/socket.c:734 [inline]
> ____sys_sendmsg+0x38f/0x500 net/socket.c:2482
> ___sys_sendmsg net/socket.c:2536 [inline]
> __sys_sendmsg+0x197/0x230 net/socket.c:2565
> __do_sys_sendmsg net/socket.c:2574 [inline]
> __se_sys_sendmsg net/socket.c:2572 [inline]
> __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x4697f9
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fab1e5c7c48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9
> RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000003
> RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80
> R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffd7c0e6920
> </TASK>
> ---[ end trace 0000000000000000 ]---
>
> Best,
> Wei
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/CAO4mrffa_3PhjfA9hxTq_U9GjC%2B%2B0suGnme9oNcKE%3DGn%2Bg1iRg%40mail.gmail.com.
^ permalink raw reply related
* [bpf-next 0/3] samples/bpf: fix LLVM compilation warning with
From: Daniel T. Lee @ 2022-12-17 15:38 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
Yonghong Song
Cc: bpf, netdev
Currently, compiling samples/bpf with LLVM emits several warning. They
are only small details, but they do not appear when compiled with GCC.
Detailed compilation command and warning logs can be found from bpf CI.
Daniel T. Lee (3):
samples/bpf: remove unused function with test_lru_dist
samples/bpf: replace meaningless counter with tracex4
samples/bpf: fix uninitialized warning with
test_current_task_under_cgroup
samples/bpf/test_current_task_under_cgroup_user.c | 6 ++++--
samples/bpf/test_lru_dist.c | 5 -----
samples/bpf/tracex4_user.c | 4 ++--
3 files changed, 6 insertions(+), 9 deletions(-)
--
2.34.1
^ permalink raw reply
* [bpf-next 1/3] samples/bpf: remove unused function with test_lru_dist
From: Daniel T. Lee @ 2022-12-17 15:38 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
Yonghong Song
Cc: bpf, netdev
In-Reply-To: <20221217153821.2285-1-danieltimlee@gmail.com>
Currently, compiling samples/bpf with LLVM warns about the unused
function with test_lru_dist.
./samples/bpf/test_lru_dist.c:45:19:
warning: unused function 'list_empty' [-Wunused-function]
static inline int list_empty(const struct list_head *head)
^
1 warning generated.
This commit resolve this compiler warning by removing the abandoned
function.
Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
---
samples/bpf/test_lru_dist.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/samples/bpf/test_lru_dist.c b/samples/bpf/test_lru_dist.c
index 5efb91763d65..1c161276d57b 100644
--- a/samples/bpf/test_lru_dist.c
+++ b/samples/bpf/test_lru_dist.c
@@ -42,11 +42,6 @@ static inline void INIT_LIST_HEAD(struct list_head *list)
list->prev = list;
}
-static inline int list_empty(const struct list_head *head)
-{
- return head->next == head;
-}
-
static inline void __list_add(struct list_head *new,
struct list_head *prev,
struct list_head *next)
--
2.34.1
^ permalink raw reply related
* [bpf-next 2/3] samples/bpf: replace meaningless counter with tracex4
From: Daniel T. Lee @ 2022-12-17 15:38 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
Yonghong Song
Cc: bpf, netdev
In-Reply-To: <20221217153821.2285-1-danieltimlee@gmail.com>
Currently, compiling samples/bpf with LLVM warns about the unused but
set variable with tracex4_user.
./samples/bpf/tracex4_user.c:54:14:
warning: variable 'i' set but not used [-Wunused-but-set-variable]
int map_fd, i, j = 0;
^
1 warning generated.
This commit resolve this compiler warning by replacing the meaningless
counter.
Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
---
samples/bpf/tracex4_user.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/tracex4_user.c b/samples/bpf/tracex4_user.c
index 227b05a0bc88..dee8f0a091ba 100644
--- a/samples/bpf/tracex4_user.c
+++ b/samples/bpf/tracex4_user.c
@@ -51,7 +51,7 @@ int main(int ac, char **argv)
struct bpf_program *prog;
struct bpf_object *obj;
char filename[256];
- int map_fd, i, j = 0;
+ int map_fd, j = 0;
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
obj = bpf_object__open_file(filename, NULL);
@@ -82,7 +82,7 @@ int main(int ac, char **argv)
j++;
}
- for (i = 0; ; i++) {
+ while (1) {
print_old_objects(map_fd);
sleep(1);
}
--
2.34.1
^ permalink raw reply related
* [bpf-next 3/3] samples/bpf: fix uninitialized warning with test_current_task_under_cgroup
From: Daniel T. Lee @ 2022-12-17 15:38 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
Yonghong Song
Cc: bpf, netdev
In-Reply-To: <20221217153821.2285-1-danieltimlee@gmail.com>
Currently, compiling samples/bpf with LLVM warns about the uninitialized
use of variable with test_current_task_under_cgroup.
./samples/bpf/test_current_task_under_cgroup_user.c:57:6:
warning: variable 'cg2' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (setup_cgroup_environment())
^~~~~~~~~~~~~~~~~~~~~~~~~~
./samples/bpf/test_current_task_under_cgroup_user.c:106:8:
note: uninitialized use occurs here
close(cg2);
^~~
./samples/bpf/test_current_task_under_cgroup_user.c:57:2:
note: remove the 'if' if its condition is always false
if (setup_cgroup_environment())
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./samples/bpf/test_current_task_under_cgroup_user.c:19:9:
note: initialize the variable 'cg2' to silence this warning
int cg2, idx = 0, rc = 1;
^
= 0
1 warning generated.
This commit resolve this compiler warning by pre-initialize the variable
with error for safeguard.
Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
---
samples/bpf/test_current_task_under_cgroup_user.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/test_current_task_under_cgroup_user.c b/samples/bpf/test_current_task_under_cgroup_user.c
index ac251a417f45..6fb25906835e 100644
--- a/samples/bpf/test_current_task_under_cgroup_user.c
+++ b/samples/bpf/test_current_task_under_cgroup_user.c
@@ -14,9 +14,9 @@
int main(int argc, char **argv)
{
pid_t remote_pid, local_pid = getpid();
+ int cg2 = -1, idx = 0, rc = 1;
struct bpf_link *link = NULL;
struct bpf_program *prog;
- int cg2, idx = 0, rc = 1;
struct bpf_object *obj;
char filename[256];
int map_fd[2];
@@ -103,7 +103,9 @@ int main(int argc, char **argv)
rc = 0;
err:
- close(cg2);
+ if (cg2 != -1)
+ close(cg2);
+
cleanup_cgroup_environment();
cleanup:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6] vmxnet3: Add XDP support.
From: William Tu @ 2022-12-17 15:42 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, tuc, gyang, doshir
In-Reply-To: <CAKgT0UehKpZMhcCgDPg00BoajxaZ23L9OzZ9GAgQd74xW6zkqw@mail.gmail.com>
On Fri, Dec 16, 2022 at 4:37 PM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
>
> On Fri, Dec 16, 2022 at 2:53 PM William Tu <u9012063@gmail.com> wrote:
> >
Hi Alexander,
Thanks for taking a look at this patch!
> > > > Single core performance comparison with skb-mode.
> > > > 64B: skb-mode -> native-mode (with this patch)
> > > > XDP_DROP: 932Kpps -> 2.0Mpps
> > > > XDP_PASS: 284Kpps -> 314Kpps
> > > > XDP_TX: 591Kpps -> 1.8Mpps
> > > > REDIRECT: 453Kpps -> 501Kpps
> > > >
> > > > 512B: skb-mode -> native-mode (with this patch)
> > > > XDP_DROP: 890Kpps -> 1.3Mpps
> > > > XDP_PASS: 284Kpps -> 314Kpps
> > > > XDP_TX: 555Kpps -> 1.2Mpps
> > > > REDIRECT: 670Kpps -> 430Kpps
> > > >
> > >
> > > I hadn't noticed it before. Based on this it looks like native mode is
> > > performing worse then skb-mode for redirect w/ 512B packets? Have you
> > > looked into why that might be?
> >
> > yes, I noticed it but don't know why, maybe it's due to extra copy and page
> > allocation like you said below. I will dig deeper.
I've fixed the issue like you mentioned, and now the redirect shows
better performance.
I will update in next version.
> >
> > >
> > > My main concern would be that you are optimizing for recyling in the Tx
> > > and Redirect paths, when you might be better off just releasing the
> > > buffers and batch allocating new pages in your Rx path.
> >
> > right, are you talking about using the page pool allocator, ex: slide 8 below
> > https://legacy.netdevconf.info/0x14/pub/slides/10/add-xdp-on-driver.pdf
> > I tried it before but then I found I have to replace lots of existing vmxnet3
> > code, basically replacing all the rx/tx buffer allocation code with new
> > page pool api, even without XDP. I'd love to give it a try, do you think it's
> > worth doing it?
>
> It might be. It is hard for me to say without knowing more about the
> driver itself. However if i were doing a driver from scratch that
> supported XDP I would probably go that route. Having to refactor an
> existing driver is admittedly going to be more work.
>
I see, thanks.
>
> >
> > >
> > > > + __netif_tx_unlock(nq);
> > > > + return err;
> > > > +}
> > > > +
> > > > +int
> > > > +vmxnet3_xdp_xmit(struct net_device *dev,
> > > > + int n, struct xdp_frame **frames, u32 flags)
> > > > +{
> > > > + struct vmxnet3_adapter *adapter;
> > > > + struct vmxnet3_tx_queue *tq;
> > > > + struct netdev_queue *nq;
> > > > + int i, err, cpu;
> > > > + int nxmit = 0;
> > > > + int tq_number;
> > > > +
> > > > + adapter = netdev_priv(dev);
> > > > +
> > > > + if (unlikely(test_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state)))
> > > > + return -ENETDOWN;
> > > > + if (unlikely(test_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state)))
> > > > + return -EINVAL;
> > > > +
> > > > + tq_number = adapter->num_tx_queues;
> > > > + cpu = smp_processor_id();
> > > > + tq = &adapter->tx_queue[cpu % tq_number];
> > > > + if (tq->stopped)
> > > > + return -ENETDOWN;
> > > > +
> > > > + nq = netdev_get_tx_queue(adapter->netdev, tq->qid);
> > > > +
> > > > + __netif_tx_lock(nq, cpu);
> > > > + for (i = 0; i < n; i++) {
> > > > + err = vmxnet3_xdp_xmit_frame(adapter, frames[i], tq);
> > > > + if (err) {
> > > > + tq->stats.xdp_xmit_err++;
> > > > + break;
> > > > + }
> > > > + nxmit++;
> > > > + }
> > > > +
> > > > + tq->stats.xdp_xmit += nxmit;
> > > > + __netif_tx_unlock(nq);
> > > > +
> > >
> > > Are you doing anything to free the frames after you transmit them? If I
> > > am not mistaken you are just copying them over into skbs aren't you, so
> > > what is freeing the frames after that?
> >
> > The frames will be free at vmxnet3_tq_cleanup() at dev_kfree_skb_any(tbi->skb);
> > Because at the vmxnet3_xdp_xmit_frame the allocated skb is saved at tbi->skb,
> > so it can be freed at tq cleanup.
>
> The frames I am referring to are the xdp_frame, not the skb.
> Specifically your function is copying the data out. So in the redirect
> case I think you might be leaking pages. That is one of the reasons
> why I was thinking it might be better to just push the data all the
> way through.
Got it, you're right, it's leaking memory there.
>
> In the other email you sent me the call xdp_return_frame was used to
> free the frame. That is what would be expected in this function after
> you cleaned the data out and placed it in an skbuff in
> vmxnet3_xdp_xmit_frame.
OK! will do it.
>
> > >
> > > > + return nxmit;
> > > > +}
> > > > +
> > > > +static int
> > > > +__vmxnet3_run_xdp(struct vmxnet3_rx_queue *rq, void *data, int data_len,
> > > > + int headroom, int frame_sz, bool *need_xdp_flush,
> > > > + struct sk_buff *skb)
> > > > +{
> > > > + struct xdp_frame *xdpf;
> > > > + void *buf_hard_start;
> > > > + struct xdp_buff xdp;
> > > > + struct page *page;
> > > > + void *orig_data;
> > > > + int err, delta;
> > > > + int delta_len;
> > > > + u32 act;
> > > > +
> > > > + buf_hard_start = data;
> > > > + xdp_init_buff(&xdp, frame_sz, &rq->xdp_rxq);
> > > > + xdp_prepare_buff(&xdp, buf_hard_start, headroom, data_len, true);
> > > > + orig_data = xdp.data;
> > > > +
> > > > + act = bpf_prog_run_xdp(rq->xdp_bpf_prog, &xdp);
> > > > + rq->stats.xdp_packets++;
> > > > +
> > > > + switch (act) {
> > > > + case XDP_DROP:
> > > > + rq->stats.xdp_drops++;
> > > > + break;
> > > > + case XDP_PASS:
> > > > + /* bpf prog might change len and data position.
> > > > + * dataring does not use skb so not support this.
> > > > + */
> > > > + delta = xdp.data - orig_data;
> > > > + delta_len = (xdp.data_end - xdp.data) - data_len;
> > > > + if (skb) {
> > > > + skb_reserve(skb, delta);
> > > > + skb_put(skb, delta_len);
> > > > + }
> > > > + break;
> > > > + case XDP_TX:
> > > > + xdpf = xdp_convert_buff_to_frame(&xdp);
> > > > + if (!xdpf ||
> > > > + vmxnet3_xdp_xmit_back(rq->adapter, xdpf)) {
> > > > + rq->stats.xdp_drops++;
> > > > + } else {
> > > > + rq->stats.xdp_tx++;
> > > > + }
> > > > + break;
> > > > + case XDP_ABORTED:
> > > > + trace_xdp_exception(rq->adapter->netdev, rq->xdp_bpf_prog,
> > > > + act);
> > > > + rq->stats.xdp_aborted++;
> > > > + break;
> > > > + case XDP_REDIRECT:
> > > > + page = alloc_page(GFP_ATOMIC);
> > > > + if (!page) {
> > > > + rq->stats.rx_buf_alloc_failure++;
> > > > + return XDP_DROP;
> > > > + }
> > >
> > > So I think I see the problem I had questions about here. If I am not
> > > mistaken you are copying the buffer to this page, and then copying this
> > > page to an skb right? I think you might be better off just writing off
> > > the Tx/Redirect pages and letting them go through their respective
> > > paths and just allocating new pages instead assuming these pages were
> > > consumed.
> >
> > I'm not sure I understand, can you elaborate?
> >
> > For XDP_TX, I'm doing 1 extra copy, copying to the newly allocated skb
> > in vmxnet3_xdp_xmit_back.
> > For XDP_REDIREC, I allocate a page and copy to the page and call
> > xdp_do_redirect, there is no copying to skb again. If I don't allocate a
> > new page, it always crashes at
> > [62020.425932] BUG: Bad page state in process cpumap/0/map:29 pfn:107548
> > [62020.440905] kernel BUG at include/linux/mm.h:757!
> > VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
>
> What I was referring to was one copy here, and then another copy in
> your vmxnet3_xdp_xmit_frame() function with the page you allocated
> here possibly being leaked.
>
> Though based on the other trace you provided it would look like you
> are redirecting to something else as your code currently doesn't
> reference xdp_return_frame which is what I was referring to earlier in
> terms of missing the logic to free the frame in your transmit path.
yes, I tried a couple ways and now it's working.
basically I have to call get_page to increment the refcnt then call
xdp_return_frame. I will update performance number and send
next version.
Thanks
William
^ permalink raw reply
* [PATCH] usbnet: jump to rx_cleanup case instead of calling skb_queue_tail
From: Leesoo Ahn @ 2022-12-17 16:18 UTC (permalink / raw)
To: lsahn
Cc: Oliver Neukum, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-usb, linux-kernel
The current source pushes skb into dev->done queue by calling
skb_queue_tail() and then, call skb_dequeue() to pop for rx_cleanup state
to free urb and skb next in usbnet_bh().
It wastes CPU resource with extra instructions. Instead, use return values
jumping to rx_cleanup case directly to free them. Therefore calling
skb_queue_tail() and skb_dequeue() is not necessary.
The follows are just showing difference between calling skb_queue_tail()
and using return values jumping to rx_cleanup state directly in usbnet_bh()
in Arm64 instructions with perf tool.
----------- calling skb_queue_tail() -----------
│ if (!(dev->driver_info->flags & FLAG_RX_ASSEMBLE))
7.58 │248: ldr x0, [x20, #16]
2.46 │24c: ldr w0, [x0, #8]
1.64 │250: ↑ tbnz w0, #14, 16c
│ dev->net->stats.rx_errors++;
0.57 │254: ldr x1, [x20, #184]
1.64 │258: ldr x0, [x1, #336]
2.65 │25c: add x0, x0, #0x1
│260: str x0, [x1, #336]
│ skb_queue_tail(&dev->done, skb);
0.38 │264: mov x1, x19
│268: mov x0, x21
2.27 │26c: → bl skb_queue_tail
0.57 │270: ↑ b 44 // branch to call skb_dequeue()
----------- jumping to rx_cleanup state -----------
│ if (!(dev->driver_info->flags & FLAG_RX_ASSEMBLE))
1.69 │25c: ldr x0, [x21, #16]
4.78 │260: ldr w0, [x0, #8]
3.28 │264: ↑ tbnz w0, #14, e4 // jump to 'rx_cleanup' state
│ dev->net->stats.rx_errors++;
0.09 │268: ldr x1, [x21, #184]
2.72 │26c: ldr x0, [x1, #336]
3.37 │270: add x0, x0, #0x1
0.09 │274: str x0, [x1, #336]
0.66 │278: ↑ b e4 // branch to 'rx_cleanup' state
Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
---
drivers/net/usb/usbnet.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 64a9a80b2309..924392a37297 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -555,7 +555,7 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
/*-------------------------------------------------------------------------*/
-static inline void rx_process (struct usbnet *dev, struct sk_buff *skb)
+static inline int rx_process(struct usbnet *dev, struct sk_buff *skb)
{
if (dev->driver_info->rx_fixup &&
!dev->driver_info->rx_fixup (dev, skb)) {
@@ -576,11 +576,11 @@ static inline void rx_process (struct usbnet *dev, struct sk_buff *skb)
netif_dbg(dev, rx_err, dev->net, "rx length %d\n", skb->len);
} else {
usbnet_skb_return(dev, skb);
- return;
+ return 0;
}
done:
- skb_queue_tail(&dev->done, skb);
+ return -1;
}
/*-------------------------------------------------------------------------*/
@@ -1528,13 +1528,14 @@ static void usbnet_bh (struct timer_list *t)
entry = (struct skb_data *) skb->cb;
switch (entry->state) {
case rx_done:
- entry->state = rx_cleanup;
- rx_process (dev, skb);
+ if (rx_process(dev, skb))
+ goto cleanup;
continue;
case tx_done:
kfree(entry->urb->sg);
fallthrough;
case rx_cleanup:
+cleanup:
usb_free_urb (entry->urb);
dev_kfree_skb (skb);
continue;
--
2.34.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in ___bpf_prog_run
From: Yonghong Song @ 2022-12-17 16:57 UTC (permalink / raw)
To: Hao Sun
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, David Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Linux Kernel Mailing List,
netdev
In-Reply-To: <5B270DBF-E305-4C86-B246-F5C8A5D942CA@gmail.com>
On 12/16/22 10:54 PM, Hao Sun wrote:
>
>
>> On 17 Dec 2022, at 1:07 PM, Yonghong Song <yhs@meta.com> wrote:
>>
>>
>>
>> On 12/14/22 11:49 PM, Hao Sun wrote:
>>> Hi,
>>> The following KASAN report can be triggered by loading and test
>>> running this simple BPF prog with a random data/ctx:
>>> 0: r0 = bpf_get_current_task_btf ;
>>> R0_w=trusted_ptr_task_struct(off=0,imm=0)
>>> 1: r0 = *(u32 *)(r0 +8192) ;
>>> R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
>>> 2: exit
>>> I've simplified the C reproducer but didn't find the root cause.
>>> JIT was disabled, and the interpreter triggered UAF when executing
>>> the load insn. A slab-out-of-bound read can also be triggered:
>>> https://pastebin.com/raw/g9zXr8jU
>>> This can be reproduced on:
>>> HEAD commit: b148c8b9b926 selftests/bpf: Add few corner cases to test
>>> padding handling of btf_dump
>>> git tree: bpf-next
>>> console log: https://pastebin.com/raw/1EUi9tJe
>>> kernel config: https://pastebin.com/raw/rgY3AJDZ
>>> C reproducer: https://pastebin.com/raw/cfVGuCBm
>>
>> I I tried with your above kernel config and C reproducer and cannot reproduce the kasan issue you reported.
>>
>> [root@arch-fb-vm1 bpf-next]# ./a.out
>> func#0 @0
>> 0: R1=ctx(off=0,imm=0) R10=fp0
>> 0: (85) call bpf_get_current_task_btf#158 ; R0_w=trusted_ptr_task_struct(off=0,imm=0)
>> 1: (61) r0 = *(u32 *)(r0 +8192) ; R0_w=scalar(umax=4294967295,var_off=(0x0; 0xffffffff))
>> 2: (95) exit
>> processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
>>
>> prog fd: 3
>> [root@arch-fb-vm1 bpf-next]#
>>
>> Your config indeed has kasan on.
>
> Hi,
>
> I can still reproduce this on a latest bpf-next build: 0e43662e61f25
> (“tools/resolve_btfids: Use pkg-config to locate libelf”).
> The simplified C reproducer sometime need to be run twice to trigger
> the UAF. Also note that interpreter is required. Here is the original
> C reproducer that loads and runs the BPF prog continuously for your
> convenience:
> https://pastebin.com/raw/WSJuNnVU
>
I still cannot reproduce with more than 10 runs. The config has jit off
so it already uses interpreter. It has kasan on as well.
# CONFIG_BPF_JIT is not set
Since you can reproduce it, I guess it would be great if you can
continue to debug this.
>>
>>> ==================================================================
>>> BUG: KASAN: use-after-free in ___bpf_prog_run+0x7f35/0x8fd0
>>> kernel/bpf/core.c:1937
>>> Read of size 4 at addr ffff88801f1f2000 by task a.out/7137
>>> CPU: 3 PID: 7137 Comm: a.out Not tainted
>>> 6.1.0-rc8-02212-gef3911a3e4d6-dirty #137
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux
>>> 1.16.1-1-1 04/01/2014
>>> Call Trace:
[...]
^ permalink raw reply
* Re: [bpf-next 0/3] samples/bpf: fix LLVM compilation warning with
From: Yonghong Song @ 2022-12-17 17:48 UTC (permalink / raw)
To: Daniel T. Lee, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, Yonghong Song
Cc: bpf, netdev
In-Reply-To: <20221217153821.2285-1-danieltimlee@gmail.com>
On 12/17/22 7:38 AM, Daniel T. Lee wrote:
> Currently, compiling samples/bpf with LLVM emits several warning. They
> are only small details, but they do not appear when compiled with GCC.
> Detailed compilation command and warning logs can be found from bpf CI.
Could you change the subject line to
samples/bpf: fix LLVM compilation warning
>
> Daniel T. Lee (3):
> samples/bpf: remove unused function with test_lru_dist
> samples/bpf: replace meaningless counter with tracex4
> samples/bpf: fix uninitialized warning with
> test_current_task_under_cgroup
>
> samples/bpf/test_current_task_under_cgroup_user.c | 6 ++++--
> samples/bpf/test_lru_dist.c | 5 -----
> samples/bpf/tracex4_user.c | 4 ++--
> 3 files changed, 6 insertions(+), 9 deletions(-)
>
^ 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