Netdev List
 help / color / mirror / Atom feed
* [PATCH] net:ipvs: add rcu read lock in some parts
From: sunsuwan @ 2022-08-12  9:34 UTC (permalink / raw)
  To: horms, ja, pablo, kadlec, netdev, lvs-devel
  Cc: chenzhen126, yanan, liaichun, caowangbao, sunsuwan3

We founf a possible UAF if rmmod pe_sid or schedule,
when packages in hook and get pe or sched.

Signed-off-by: sunsuwan <sunsuwan3@huawei.com>
Signed-off-by: chenzhen <chenzhen126@huawei.com>
---
 net/netfilter/ipvs/ip_vs_core.c | 6 ++++++
 net/netfilter/ipvs/ip_vs_ctl.c  | 3 +++
 net/netfilter/ipvs/ip_vs_dh.c   | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 51ad557a525b..d289f184d5c1 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -235,7 +235,9 @@ ip_vs_conn_fill_param_persist(const struct ip_vs_service *svc,
 {
 	ip_vs_conn_fill_param(svc->ipvs, svc->af, protocol, caddr, cport, vaddr,
 			      vport, p);
+	rcu_read_lock();
 	p->pe = rcu_dereference(svc->pe);
+	rcu_read_unlock();
 	if (p->pe && p->pe->fill_param)
 		return p->pe->fill_param(p, skb);
 
@@ -346,7 +348,9 @@ ip_vs_sched_persist(struct ip_vs_service *svc,
 		 * template is not available.
 		 * return *ignored=0 i.e. ICMP and NF_DROP
 		 */
+		rcu_read_lock();
 		sched = rcu_dereference(svc->scheduler);
+		rcu_read_unlock();
 		if (sched) {
 			/* read svc->sched_data after svc->scheduler */
 			smp_rmb();
@@ -521,7 +525,9 @@ ip_vs_schedule(struct ip_vs_service *svc, struct sk_buff *skb,
 		return NULL;
 	}
 
+	rcu_read_lock();
 	sched = rcu_dereference(svc->scheduler);
+	rcu_read_unlock();
 	if (sched) {
 		/* read svc->sched_data after svc->scheduler */
 		smp_rmb();
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index efab2b06d373..91e568028001 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -580,6 +580,7 @@ bool ip_vs_has_real_service(struct netns_ipvs *ipvs, int af, __u16 protocol,
 	/* Check for "full" addressed entries */
 	hash = ip_vs_rs_hashkey(af, daddr, dport);
 
+	rcu_read_lock();
 	hlist_for_each_entry_rcu(dest, &ipvs->rs_table[hash], d_list) {
 		if (dest->port == dport &&
 		    dest->af == af &&
@@ -587,9 +588,11 @@ bool ip_vs_has_real_service(struct netns_ipvs *ipvs, int af, __u16 protocol,
 		    (dest->protocol == protocol || dest->vfwmark) &&
 		    IP_VS_DFWD_METHOD(dest) == IP_VS_CONN_F_MASQ) {
 			/* HIT */
+			rcu_read_unlock();
 			return true;
 		}
 	}
+	rcu_read_unlock();
 
 	return false;
 }
diff --git a/net/netfilter/ipvs/ip_vs_dh.c b/net/netfilter/ipvs/ip_vs_dh.c
index 5e6ec32aff2b..3e4b9607172b 100644
--- a/net/netfilter/ipvs/ip_vs_dh.c
+++ b/net/netfilter/ipvs/ip_vs_dh.c
@@ -219,7 +219,9 @@ ip_vs_dh_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
 	IP_VS_DBG(6, "%s(): Scheduling...\n", __func__);
 
 	s = (struct ip_vs_dh_state *) svc->sched_data;
+	rcu_read_lock();
 	dest = ip_vs_dh_get(svc->af, s, &iph->daddr);
+	rcu_read_unlock();
 	if (!dest
 	    || !(dest->flags & IP_VS_DEST_F_AVAILABLE)
 	    || atomic_read(&dest->weight) <= 0
-- 
2.30.0


^ permalink raw reply related

* Re: [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support
From: Martin Habets @ 2022-08-12  9:38 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Bjorn Helgaas, davem, Paolo Abeni, Eric Dumazet, netdev,
	ecree.xilinx, linux-pci, virtualization, mst
In-Reply-To: <CACGkMEt1qLsSf2Stn1YveW-HaDByiYFdCTzdsKESypKNbF=eTg@mail.gmail.com>

FYI, during my holiday my colleagues found a way to use the vdpa tool for this.
That means we should not need this series, at least for vDPA.
So we can drop this series.

Thanks,
Martin

On Wed, Aug 03, 2022 at 03:57:34PM +0800, Jason Wang wrote:
> On Fri, Jul 15, 2022 at 12:05 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Thu, 14 Jul 2022 12:32:12 +0100 Martin Habets wrote:
> > > > Okay. Indeed, we could easily bolt something onto devlink, I'd think
> > > > but I don't know the space enough to push for one solution over
> > > > another.
> > > >
> > > > Please try to document the problem and the solution... somewhere, tho.
> > > > Otherwise the chances that the next vendor with this problem follows
> > > > the same approach fall from low to none.
> > >
> > > Yeah, good point. The obvious thing would be to create a
> > >  Documentation/networking/device_drivers/ethernet/sfc/sfc/rst
> > > Is that generic enough for other vendors to find out, or there a better place?
> >
> > Documentation/vdpa.rst ? I don't see any kernel level notes on
> > implementing vDPA perhaps virt folks can suggest something.
> 
> Not sure, since it's not a vDPA general thing but a vendor/parent
> specific thing.
> 
> Or maybe Documentation/vdpa/sfc ?
> 
> Thanks
> 
> > I don't think people would be looking into driver-specific docs
> > when trying to implement an interface, so sfc is not a great option
> > IMHO.
> >
> > > I can do a follow-up patch for this.
> >
> > Let's make it part of the same series.

^ permalink raw reply

* [syzbot] linux-next boot error: kernel BUG in __phys_addr
From: syzbot @ 2022-08-12  9:36 UTC (permalink / raw)
  To: bpf, davem, edumazet, fw, harshit.m.mogalapalli, kuba,
	linux-kernel, linux-next, netdev, pabeni, sfr, syzkaller-bugs

Hello,

syzbot found the following issue on:

HEAD commit:    7bb4fa8a025a Add linux-next specific files for 20220812
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15ddd587080000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a5ae8cfa8d7075d1
dashboard link: https://syzkaller.appspot.com/bug?extid=c257efdd53a617c7caf7
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c257efdd53a617c7caf7@syzkaller.appspotmail.com

udevd[2975]: starting eudev-3.2.10
------------[ cut here ]------------
kernel BUG at arch/x86/mm/physaddr.c:28!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 2975 Comm: udevd Not tainted 5.19.0-next-20220812-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
RIP: 0010:__phys_addr+0xd3/0x140 arch/x86/mm/physaddr.c:28
Code: e3 44 89 e9 31 ff 48 d3 eb 48 89 de e8 56 21 45 00 48 85 db 75 0f e8 6c 24 45 00 4c 89 e0 5b 5d 41 5c 41 5d c3 e8 5d 24 45 00 <0f> 0b e8 56 24 45 00 48 c7 c0 10 50 cb 8b 48 ba 00 00 00 00 00 fc
RSP: 0018:ffffc90002dbf8b8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff000000000000 RCX: 0000000000000000
RDX: ffff88807cd11d80 RSI: ffffffff8136e1c3 RDI: 0000000000000006
RBP: ffff000080000000 R08: 0000000000000006 R09: ffff000080000000
R10: ffff778000000000 R11: 0000000000000000 R12: ffff778000000000
R13: ffffc90002dbf920 R14: ffff000000000000 R15: 0000000000000000
FS:  00007f9b90cd2840(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055e07825a388 CR3: 000000002641b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 virt_to_folio include/linux/mm.h:856 [inline]
 virt_to_slab mm/kasan/../slab.h:175 [inline]
 qlink_to_cache mm/kasan/quarantine.c:131 [inline]
 qlist_free_all+0x86/0x170 mm/kasan/quarantine.c:184
 kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:294
 __kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:447
 kasan_slab_alloc include/linux/kasan.h:224 [inline]
 slab_post_alloc_hook mm/slab.h:727 [inline]
 slab_alloc_node mm/slub.c:3243 [inline]
 kmem_cache_alloc_node+0x2b1/0x3f0 mm/slub.c:3293
 __alloc_skb+0x210/0x2f0 net/core/skbuff.c:418
 alloc_skb include/linux/skbuff.h:1257 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1191 [inline]
 netlink_sendmsg+0x9a2/0xe10 net/netlink/af_netlink.c:1896
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:734
 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f9b90935163
Code: 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 89 54 24 1c 48
RSP: 002b:00007ffd32cf5c38 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000055e078203db0 RCX: 00007f9b90935163
RDX: 0000000000000000 RSI: 00007ffd32cf5c48 RDI: 0000000000000004
RBP: 000055e0782390e0 R08: 0000000000000001 R09: 000055e07822f540
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000070 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__phys_addr+0xd3/0x140 arch/x86/mm/physaddr.c:28
Code: e3 44 89 e9 31 ff 48 d3 eb 48 89 de e8 56 21 45 00 48 85 db 75 0f e8 6c 24 45 00 4c 89 e0 5b 5d 41 5c 41 5d c3 e8 5d 24 45 00 <0f> 0b e8 56 24 45 00 48 c7 c0 10 50 cb 8b 48 ba 00 00 00 00 00 fc
RSP: 0018:ffffc90002dbf8b8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff000000000000 RCX: 0000000000000000
RDX: ffff88807cd11d80 RSI: ffffffff8136e1c3 RDI: 0000000000000006
RBP: ffff000080000000 R08: 0000000000000006 R09: ffff000080000000
R10: ffff778000000000 R11: 0000000000000000 R12: ffff778000000000
R13: ffffc90002dbf920 R14: ffff000000000000 R15: 0000000000000000
FS:  00007f9b90cd2840(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055d17224b028 CR3: 000000002641b000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

^ permalink raw reply

* [syzbot] KASAN: global-out-of-bounds Read in macvlan_hard_header (3)
From: syzbot @ 2022-08-12  9:35 UTC (permalink / raw)
  To: davem, edumazet, kuba, linux-kernel, netdev, pabeni,
	syzkaller-bugs

Hello,

syzbot found the following issue on:

HEAD commit:    8eaa1d110800 net/mlx5e: xsk: Discard unaligned XSK frames ..
git tree:       net
console output: https://syzkaller.appspot.com/x/log.txt?x=1317f1c1080000
kernel config:  https://syzkaller.appspot.com/x/.config?x=467d6845c5dcb05f
dashboard link: https://syzkaller.appspot.com/bug?extid=f98474db42abaf86c7b5
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f98474db42abaf86c7b5@syzkaller.appspotmail.com

IPv6: ADDRCONF(NETDEV_CHANGE): team1: link becomes ready
==================================================================
BUG: KASAN: global-out-of-bounds in dev_hard_header include/linux/netdevice.h:3043 [inline]
BUG: KASAN: global-out-of-bounds in macvlan_hard_header+0x12b/0x150 drivers/net/macvlan.c:594
Read of size 8 at addr ffffffff8f2bd590 by task kworker/1:1/32

CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.19.0-rc8-syzkaller-00130-g8eaa1d110800 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
Workqueue: mld mld_ifc_work
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0xf/0x495 mm/kasan/report.c:313
 print_report mm/kasan/report.c:429 [inline]
 kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
 dev_hard_header include/linux/netdevice.h:3043 [inline]
 macvlan_hard_header+0x12b/0x150 drivers/net/macvlan.c:594
 dev_hard_header include/linux/netdevice.h:3046 [inline]
 neigh_resolve_output net/core/neighbour.c:1523 [inline]
 neigh_resolve_output+0x4b3/0x840 net/core/neighbour.c:1508
 neigh_output include/net/neighbour.h:549 [inline]
 ip6_finish_output2+0x564/0x1520 net/ipv6/ip6_output.c:134
 __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
 ip6_finish_output+0x844/0x1170 net/ipv6/ip6_output.c:206
 NF_HOOK_COND include/linux/netfilter.h:296 [inline]
 ip6_output+0x1ed/0x540 net/ipv6/ip6_output.c:227
 dst_output include/net/dst.h:451 [inline]
 NF_HOOK include/linux/netfilter.h:307 [inline]
 NF_HOOK include/linux/netfilter.h:301 [inline]
 mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820
 mld_send_cr net/ipv6/mcast.c:2121 [inline]
 mld_ifc_work+0x71c/0xdc0 net/ipv6/mcast.c:2653
 process_one_work+0x996/0x1610 kernel/workqueue.c:2289
 worker_thread+0x665/0x1080 kernel/workqueue.c:2436
 kthread+0x2e9/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 </TASK>

The buggy address belongs to the variable:
 nr_zapped_lock_chains+0x10/0x40

Memory state around the buggy address:
 ffffffff8f2bd480: 00 00 00 00 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
 ffffffff8f2bd500: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>ffffffff8f2bd580: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
                         ^
 ffffffff8f2bd600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffff8f2bd680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

^ permalink raw reply

* [Patch net] net: dsa: microchip: ksz9477: fix fdb_dump last invalid entry
From: Arun Ramadoss @ 2022-08-12  9:34 UTC (permalink / raw)
  To: linux-kernel, netdev
  Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vivien Didelot,
	Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Russell King, Tristram Ha

In the ksz9477_fdb_dump function it reads the ALU control register and
exit from the timeout loop if there is valid entry or search is
complete. After exiting the loop, it reads the alu entry and report to
the user space irrespective of entry is valid. It works till the valid
entry. If the loop exited when search is complete, it reads the alu
table. The table returns all ones and it is reported to user space. So
bridge fdb show gives ff:ff:ff:ff:ff:ff as last entry for every port.
To fix it, after exiting the loop the entry is reported only if it is
valid one.

Fixes: c2e866911e25 ("net: dsa: microchip: break KSZ9477 DSA driver into two files")
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
---
 drivers/net/dsa/microchip/ksz9477.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 4b14d80d27ed..aa961dc03ddf 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -613,15 +613,17 @@ int ksz9477_fdb_dump(struct ksz_device *dev, int port,
 			goto exit;
 		}
 
-		/* read ALU table */
-		ksz9477_read_table(dev, alu_table);
+		if (ksz_data & ALU_VALID) {
+			/* read ALU table */
+			ksz9477_read_table(dev, alu_table);
 
-		ksz9477_convert_alu(&alu, alu_table);
+			ksz9477_convert_alu(&alu, alu_table);
 
-		if (alu.port_forward & BIT(port)) {
-			ret = cb(alu.mac, alu.fid, alu.is_static, data);
-			if (ret)
-				goto exit;
+			if (alu.port_forward & BIT(port)) {
+				ret = cb(alu.mac, alu.fid, alu.is_static, data);
+				if (ret)
+					goto exit;
+			}
 		}
 	} while (ksz_data & ALU_START);
 

base-commit: f86d1fbbe7858884d6754534a0afbb74fc30bc26
-- 
2.36.1


^ permalink raw reply related

* RE: [PATCH net 1/2] dt: ar803x: Document disable-hibernation property
From: Wei Fang @ 2022-08-12  9:02 UTC (permalink / raw)
  To: Krzysztof Kozlowski, andrew@lunn.ch, hkallweit1@gmail.com,
	linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, f.fainelli@gmail.com,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <0cd22a17-3171-b572-65fb-e9d3def60133@linaro.org>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: 2022年8月12日 15:28
> To: Wei Fang <wei.fang@nxp.com>; andrew@lunn.ch; hkallweit1@gmail.com;
> linux@armlinux.org.uk; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; f.fainelli@gmail.com;
> netdev@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net 1/2] dt: ar803x: Document disable-hibernation
> property
> 
> On 12/08/2022 17:50, wei.fang@nxp.com wrote:
> > From: Wei Fang <wei.fang@nxp.com>
> >
> 
> Please use subject prefix matching subsystem.
> 
Ok, I'll add the subject prefix.

> > The hibernation mode of Atheros AR803x PHYs is default enabled.
> > When the cable is unplugged, the PHY will enter hibernation mode and
> > the PHY clock does down. For some MACs, it needs the clock to support
> > it's logic. For instance, stmmac needs the PHY inputs clock is present
> > for software reset completion. Therefore, It is reasonable to add a DT
> > property to disable hibernation mode.
> >
> > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/net/qca,ar803x.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> > b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> > index b3d4013b7ca6..d08431d79b83 100644
> > --- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> > +++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> > @@ -40,6 +40,12 @@ properties:
> >        Only supported on the AR8031.
> >      type: boolean
> >
> > +  qca,disable-hibernation:
> > +    description: |
> > +    If set, the PHY will not enter hibernation mode when the cable is
> > +    unplugged.
> 
> Wrong indentation. Did you test the bindings?
> 
Sorry, I just checked the patch and forgot to check the dt-bindings.

> Unfortunately the property describes driver behavior not hardware, so it is not
> suitable for DT. Instead describe the hardware
> characteristics/features/bugs/constraints. Not driver behavior. Both in property
> name and property description.
> 
Thanks for your review and feedback. Actually, the hibernation mode is a feature of hardware, I will modify the property name and description to be more in line with the requirements of the DT property. 

> Best regards,
> Krzysztof

^ permalink raw reply

* Re: [PATCH net-next v2] net: skb: prevent the split of kfree_skb_reason() by gcc
From: Miguel Ojeda @ 2022-08-12  8:50 UTC (permalink / raw)
  To: menglong8.dong
  Cc: kuba, ojeda, ndesaulniers, davem, edumazet, pabeni, asml.silence,
	imagedong, luiz.von.dentz, vasily.averin, jk, linux-kernel,
	netdev
In-Reply-To: <20220812025015.316609-1-imagedong@tencent.com>

On Fri, Aug 12, 2022 at 4:50 AM <menglong8.dong@gmail.com> wrote:
>
>  #define __noreturn                      __attribute__((__noreturn__))
>
> +#define __nofnsplit                     __attribute__((__optimize__("O1")))

This is still in the wrong place...

Also, from what the bot says, Clang does not support it. I took a
look, and that seems to be the case. ICC doesn't, either. Thus you
would need to guard it and also add the docs as needed, like the other
attributes.

(Not saying that solving the issue with the attribute is a good idea,
but if you really wanted to add one, it should be done properly)

Cheers,
Miguel

^ permalink raw reply

* Re: [PATCH bpf-next] libbpf: making bpf_prog_load() ignore name if kernel doesn't support
From: Quentin Monnet @ 2022-08-12  8:38 UTC (permalink / raw)
  To: Hangbin Liu, netdev
  Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
	Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
	KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, bpf
In-Reply-To: <20220812024038.7056-1-liuhangbin@gmail.com>

On 12/08/2022 03:40, Hangbin Liu wrote:
> Similar with commit 10b62d6a38f7 ("libbpf: Add names for auxiliary maps"),
> let's make bpf_prog_load() also ignore name if kernel doesn't support
> program name.
> 
> To achieve this, we need to call sys_bpf_prog_load() directly in
> probe_kern_prog_name() to avoid circular dependency. sys_bpf_prog_load()
> also need to be exported in the bpf.h file.
> 
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
>  tools/lib/bpf/bpf.c    |  6 ++----
>  tools/lib/bpf/bpf.h    |  3 +++
>  tools/lib/bpf/libbpf.c | 11 +++++++++--
>  3 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 6a96e665dc5d..575867d69496 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -84,9 +84,7 @@ static inline int sys_bpf_fd(enum bpf_cmd cmd, union bpf_attr *attr,
>  	return ensure_good_fd(fd);
>  }
>  
> -#define PROG_LOAD_ATTEMPTS 5
> -
> -static inline int sys_bpf_prog_load(union bpf_attr *attr, unsigned int size, int attempts)
> +int sys_bpf_prog_load(union bpf_attr *attr, unsigned int size, int attempts)
>  {
>  	int fd;
>  
> @@ -263,7 +261,7 @@ int bpf_prog_load(enum bpf_prog_type prog_type,
>  	attr.prog_ifindex = OPTS_GET(opts, prog_ifindex, 0);
>  	attr.kern_version = OPTS_GET(opts, kern_version, 0);
>  
> -	if (prog_name)
> +	if (prog_name && kernel_supports(NULL, FEAT_PROG_NAME))
>  		libbpf_strlcpy(attr.prog_name, prog_name, sizeof(attr.prog_name));
>  	attr.license = ptr_to_u64(license);
>  
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index 9c50beabdd14..125c580e45f8 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -35,6 +35,9 @@
>  extern "C" {
>  #endif
>  
> +#define PROG_LOAD_ATTEMPTS 5
> +int sys_bpf_prog_load(union bpf_attr *attr, unsigned int size, int attempts);
> +

bpf.h is the user-facing header, should these go into libbpf_internal.h
instead?

By the way, I observe that libbpf_set_memlock_rlim() in bpf.h (below) is
not prefixed with LIBBPF_API, although it is exposed in the libbpf.map,
Andrii is this expected?

>  int libbpf_set_memlock_rlim(size_t memlock_bytes);
>  
>  struct bpf_map_create_opts {
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 3f01f5cd8a4c..1bcb2735d3f1 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -4419,10 +4419,17 @@ static int probe_kern_prog_name(void)
>  		BPF_MOV64_IMM(BPF_REG_0, 0),
>  		BPF_EXIT_INSN(),
>  	};
> -	int ret, insn_cnt = ARRAY_SIZE(insns);
> +	union bpf_attr attr = {
> +		.prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
> +		.prog_name = "test",
> +		.license = ptr_to_u64("GPL"),
> +		.insns = ptr_to_u64(insns),
> +		.insn_cnt = (__u32)ARRAY_SIZE(insns),
> +	};

I think you cannot initialise "attr" directly, you need a "memset(&attr,
0, sizeof(attr));" first, in case the struct contains padding between
the fields.

> +	int ret;
>  
>  	/* make sure loading with name works */
> -	ret = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, "test", "GPL", insns, insn_cnt, NULL);
> +	ret = sys_bpf_prog_load(&attr, sizeof(attr), PROG_LOAD_ATTEMPTS);
>  	return probe_fd(ret);
>  }
>  


^ permalink raw reply

* [PATCH iproute2]rdma: modify the command output message of rdma statistic help based on man manual
From: jiangheng @ 2022-08-12  7:53 UTC (permalink / raw)
  To: netdev


From 4ce8d60f34c5cdcff8b25e3c3891fc053736225b Mon Sep 17 00:00:00 2001
From: jinag <jinag12138@gmail.com>
Date: Fri, 12 Aug 2022 15:48:07 +0800
Subject: [PATCH] rdma: modify the command output message of rdma statistic help
 based on man manual


---
 rdma/stat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/rdma/stat.c b/rdma/stat.c
index aad8815c..1e869c25 100644
--- a/rdma/stat.c
+++ b/rdma/stat.c
@@ -24,10 +24,10 @@ static int stat_help(struct rd *rd)
    pr_out("       %s statistic mode [ supported ] link [ DEV/PORT_INDEX ]\n", rd->filename);
    pr_out("       %s statistic set link [ DEV/PORT_INDEX ] optional-counters [ OPTIONAL-COUNTERS ]\n", rd->filename);
    pr_out("       %s statistic unset link [ DEV/PORT_INDEX ] optional-counters\n", rd->filename);
-   pr_out("where  OBJECT: = { qp }\n");
-   pr_out("       CRITERIA : = { type }\n");
+   pr_out("where  OBJECT: = { qp | mr }\n");
+   pr_out("       CRITERIA : = { type | pid }\n");
    pr_out("       COUNTER_SCOPE: = { link | dev }\n");
-   pr_out("       FILTER_NAME: = { cntn | lqpn | pid }\n");
+   pr_out("       FILTER_NAME: = { cntn | lqpn | pid | qp_type }\n");
    pr_out("Examples:\n");
    pr_out("       %s statistic qp show\n", rd->filename);
    pr_out("       %s statistic qp show link mlx5_2/1\n", rd->filename);
--
2.23.0

^ permalink raw reply related

* Re: [PATCH] wifi: p54: Fix comment typo
From: Christian Lamparter @ 2022-08-12  7:50 UTC (permalink / raw)
  To: Jason Wang, kvalo
  Cc: chunkeey, davem, edumazet, kuba, pabeni, linux-wireless, netdev,
	linux-kernel
In-Reply-To: <20220811120340.12968-1-wangborong@cdjrlc.com>

On 11/08/2022 14:03, Jason Wang wrote:
> The double `to' is duplicated in the comment, remove one.

Oh, there might be more errors... much more.

If you can, please aggregated spelling and grammar errors.

Acked-by: Christian Lamparter <chunkeey@gmail.com>

> 
> Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
> ---
>   drivers/net/wireless/intersil/p54/main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intersil/p54/main.c b/drivers/net/wireless/intersil/p54/main.c
> index b925e327e091..e127453ab51a 100644
> --- a/drivers/net/wireless/intersil/p54/main.c
> +++ b/drivers/net/wireless/intersil/p54/main.c
> @@ -635,7 +635,7 @@ static int p54_get_survey(struct ieee80211_hw *dev, int idx,
>   				/*
>   				 * hw/fw has not accumulated enough sample sets.
>   				 * Wait for 100ms, this ought to be enough to
> -				 * to get at least one non-null set of channel
> +				 * get at least one non-null set of channel
>   				 * usage statistics.
>   				 */
>   				msleep(100);


^ permalink raw reply

* [PATCH iproute2] genl: modify the command output message of genl -h
From: jiangheng @ 2022-08-12  7:21 UTC (permalink / raw)
  To: netdev

From f4709a324870822066b449bab89980dba8c8af79 Mon Sep 17 00:00:00 2001
From: jinag <jinag12138@gmail.com>
Date: Thu, 14 Oct 2021 15:13:03 +0800
Subject: [PATCH] genl: modify the command output of genl -h

after the modification, the command output is the same as that of man 8 genl and more readable.
---
 genl/genl.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/genl/genl.c b/genl/genl.c
index 6557e6bc..977e9db7 100644
--- a/genl/genl.c
+++ b/genl/genl.c
@@ -99,9 +99,11 @@ static void usage(void) __attribute__((noreturn));
 static void usage(void)
 {
        fprintf(stderr,
-               "Usage: genl [ OPTIONS ] OBJECT [help] }\n"
-               "where  OBJECT := { ctrl etc }\n"
-               "       OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -V[ersion] | -h[elp] }\n");
+               "Usage: genl [ OPTIONS ] OBJECT [help]\n"
+               "where  OBJECT := { ctrl CTRL_OPTS }\n"
+               "       OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -V[ersion] | -h[elp] }\n"
+               "       CTRL_OPTS := { help | list | monitor | get PARMS }\n"
+               "       PARMS := { name NAME | id ID }\n");
        exit(-1);
 }

--
2.23.0

^ permalink raw reply related

* Re: [PATCH net 1/2] dt: ar803x: Document disable-hibernation property
From: Krzysztof Kozlowski @ 2022-08-12  7:27 UTC (permalink / raw)
  To: wei.fang, andrew, hkallweit1, linux, davem, edumazet, kuba,
	pabeni, robh+dt, krzysztof.kozlowski+dt, f.fainelli, netdev,
	devicetree, linux-kernel
In-Reply-To: <20220812145009.1229094-2-wei.fang@nxp.com>

On 12/08/2022 17:50, wei.fang@nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
> 

Please use subject prefix matching subsystem.

> The hibernation mode of Atheros AR803x PHYs is default enabled.
> When the cable is unplugged, the PHY will enter hibernation
> mode and the PHY clock does down. For some MACs, it needs the
> clock to support it's logic. For instance, stmmac needs the PHY
> inputs clock is present for software reset completion. Therefore,
> It is reasonable to add a DT property to disable hibernation mode.
> 
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> ---
>  Documentation/devicetree/bindings/net/qca,ar803x.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> index b3d4013b7ca6..d08431d79b83 100644
> --- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> +++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
> @@ -40,6 +40,12 @@ properties:
>        Only supported on the AR8031.
>      type: boolean
>  
> +  qca,disable-hibernation:
> +    description: |
> +    If set, the PHY will not enter hibernation mode when the cable is
> +    unplugged.

Wrong indentation. Did you test the bindings?

Unfortunately the property describes driver behavior not hardware, so it
is not suitable for DT. Instead describe the hardware
characteristics/features/bugs/constraints. Not driver behavior. Both in
property name and property description.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH] bonding: return -ENOMEM on rlb_initialize() allocation failure
From: Christophe JAILLET @ 2022-08-12  7:14 UTC (permalink / raw)
  To: Jiapeng Chong, j.vosburgh
  Cc: vfalico, andy, davem, edumazet, kuba, pabeni, netdev,
	linux-kernel, Abaci Robot
In-Reply-To: <20220812032059.64572-1-jiapeng.chong@linux.alibaba.com>

Le 12/08/2022 à 05:20, Jiapeng Chong a écrit :
> drivers/net/bonding/bond_alb.c:861 rlb_initialize() warn: returning -1 instead of -ENOMEM is sloppy.
> 
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1896
> Reported-by: Abaci Robot <abaci@linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
> ---
>   drivers/net/bonding/bond_alb.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index 60cb9a0225aa..96cb4404b3c7 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -858,7 +858,7 @@ static int rlb_initialize(struct bonding *bond)
>   
>   	new_hashtbl = kmalloc(size, GFP_KERNEL);
>   	if (!new_hashtbl)
> -		return -1;
> +		return -ENOMEM;
>   
>   	spin_lock_bh(&bond->mode_lock);
>   

Hi,

Nit: if of any use, the only call chain leads to [1]:
bond_open()
--> bond_alb_initialize()
   --> rlb_initialize()

So, the error in bond_open() could be changed to ret instead of a hard 
coded -ENOMEM.

Just my 2c,


Other than that, for what it worth,
Reviewed-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

CJ

[1]: 
https://elixir.bootlin.com/linux/v5.19/source/drivers/net/bonding/bond_main.c#L4163

^ permalink raw reply

* Re: [PATCH 4/4] dt-bindings: net: dsa: mediatek,mt7530: update json-schema
From: Krzysztof Kozlowski @ 2022-08-12  7:01 UTC (permalink / raw)
  To: Arınç ÜNAL, Andrew Lunn, Vivien Didelot,
	Florian Fainelli, Vladimir Oltean, David S . Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
	Matthias Brugger, Sean Wang, Landen Chao, DENG Qingfang,
	Frank Wunderlich, Luiz Angelo Daros de Luca, Sander Vanheule,
	René van Dorst, Daniel Golle, erkin.bozoglu,
	Sergio Paracuellos
  Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel
In-Reply-To: <8a665b7a-bbd0-99ce-658e-bc78568bdca2@linaro.org>

On 12/08/2022 09:57, Krzysztof Kozlowski wrote:
> On 12/08/2022 01:09, Arınç ÜNAL wrote:
>>>> -patternProperties:
>>>> -  "^(ethernet-)?ports$":
>>>> -    type: object
>>>
>>> Actually four patches...
>>>
>>> I don't find this change explained in commit msg. What is more, it looks
>>> incorrect. All properties and patternProperties should be explained in
>>> top-level part.
>>>
>>> Defining such properties (with big piece of YAML) in each if:then: is no
>>> readable.
>>
>> I can't figure out another way. I need to require certain properties for 
>> a compatible string AND certain enum/const for certain properties which 
>> are inside patternProperties for "^(ethernet-)?port@[0-9]+$" by reading 
>> the compatible string.
> 
> requiring properties is not equal to defining them and nothing stops you
> from defining all properties top-level and requiring them in
> allOf:if:then:patternProperties.
> 
> 
>> If I put allOf:if:then under patternProperties, I can't do the latter.
> 
> You can.
> 
>>
>> Other than readability to human eyes, binding check works as intended, 
>> in case there's no other way to do it.
> 
> I don't see the problem in doing it and readability is one of main
> factors of code admission to Linux kernel.

One more thought - if your schema around allOf:if:then grows too much,
it is actually a sign that it might benefit from splitting. Either into
two separate schemas or into common+two separate.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH 4/4] dt-bindings: net: dsa: mediatek,mt7530: update json-schema
From: Krzysztof Kozlowski @ 2022-08-12  6:57 UTC (permalink / raw)
  To: Arınç ÜNAL, Andrew Lunn, Vivien Didelot,
	Florian Fainelli, Vladimir Oltean, David S . Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
	Matthias Brugger, Sean Wang, Landen Chao, DENG Qingfang,
	Frank Wunderlich, Luiz Angelo Daros de Luca, Sander Vanheule,
	René van Dorst, Daniel Golle, erkin.bozoglu,
	Sergio Paracuellos
  Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel
In-Reply-To: <bb60608a-7902-99fa-72aa-5765adabd300@arinc9.com>

On 12/08/2022 01:09, Arınç ÜNAL wrote:
>>> -patternProperties:
>>> -  "^(ethernet-)?ports$":
>>> -    type: object
>>
>> Actually four patches...
>>
>> I don't find this change explained in commit msg. What is more, it looks
>> incorrect. All properties and patternProperties should be explained in
>> top-level part.
>>
>> Defining such properties (with big piece of YAML) in each if:then: is no
>> readable.
> 
> I can't figure out another way. I need to require certain properties for 
> a compatible string AND certain enum/const for certain properties which 
> are inside patternProperties for "^(ethernet-)?port@[0-9]+$" by reading 
> the compatible string.

requiring properties is not equal to defining them and nothing stops you
from defining all properties top-level and requiring them in
allOf:if:then:patternProperties.


> If I put allOf:if:then under patternProperties, I can't do the latter.

You can.

> 
> Other than readability to human eyes, binding check works as intended, 
> in case there's no other way to do it.

I don't see the problem in doing it and readability is one of main
factors of code admission to Linux kernel.

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH net 2/2] net: phy: at803x: Add disable hibernation mode support
From: wei.fang @ 2022-08-12 14:50 UTC (permalink / raw)
  To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, robh+dt,
	krzysztof.kozlowski+dt, f.fainelli, netdev, devicetree,
	linux-kernel
In-Reply-To: <20220812145009.1229094-1-wei.fang@nxp.com>

From: Wei Fang <wei.fang@nxp.com>

When the cable is unplugged, the Atheros AR803x PHYs will enter
hibernation mode after about 10 seconds if the hibernation mode
is enabled and will not provide any clock to the MAC. But for
some MACs, this feature might cause unexpected issues due to the
logic of MACs.
Taking SYNP MAC (stmmac) as an example, if the cable is unplugged
and the "eth0" interface is down, the AR803x PHY will enter
hibernation mode. Then perform the "ifconfig eth0 up" operation,
the stmmac can't able to complete the software reset operation
and fail to init it's own DMA. Therefore, the "eth0" interface is
failed to ifconfig up. Why does it cause this issue? The truth is
that the software reset operation of the stmmac is designed to
depend on the input clock of PHY.
So, this patch offers an option for the user to determine whether
to disable the hibernation mode of AR803x PHYs.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 drivers/net/phy/at803x.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 59fe356942b5..3efc6df4eb97 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -115,6 +115,7 @@
 #define AT803X_DEBUG_REG_HIB_CTRL		0x0b
 #define   AT803X_DEBUG_HIB_CTRL_SEL_RST_80U	BIT(10)
 #define   AT803X_DEBUG_HIB_CTRL_EN_ANY_CHANGE	BIT(13)
+#define   AT803X_DEBUG_HIB_CTRL_PS_HIB_EN	BIT(15)
 
 #define AT803X_DEBUG_REG_3C			0x3C
 
@@ -192,6 +193,9 @@
 #define AT803X_KEEP_PLL_ENABLED			BIT(0)
 #define AT803X_DISABLE_SMARTEEE			BIT(1)
 
+/* disable hibernation mode */
+#define AT803X_DISABLE_HIBERNATION		BIT(2)
+
 /* ADC threshold */
 #define QCA808X_PHY_DEBUG_ADC_THRESHOLD		0x2c80
 #define QCA808X_ADC_THRESHOLD_MASK		GENMASK(7, 0)
@@ -730,6 +734,9 @@ static int at803x_parse_dt(struct phy_device *phydev)
 	if (of_property_read_bool(node, "qca,disable-smarteee"))
 		priv->flags |= AT803X_DISABLE_SMARTEEE;
 
+	if (of_property_read_bool(node, "qca,disable-hibernation"))
+		priv->flags |= AT803X_DISABLE_HIBERNATION;
+
 	if (!of_property_read_u32(node, "qca,smarteee-tw-us-1g", &tw)) {
 		if (!tw || tw > 255) {
 			phydev_err(phydev, "invalid qca,smarteee-tw-us-1g\n");
@@ -999,6 +1006,20 @@ static int at8031_pll_config(struct phy_device *phydev)
 					     AT803X_DEBUG_PLL_ON, 0);
 }
 
+static int at803x_hibernation_config(struct phy_device *phydev)
+{
+	struct at803x_priv *priv = phydev->priv;
+
+	/* The default after hardware reset is hibernation mode enabled. After
+	 * software reset, the value is retained.
+	 */
+	if (!(priv->flags & AT803X_DISABLE_HIBERNATION))
+		return 0;
+
+	return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_HIB_CTRL,
+					 AT803X_DEBUG_HIB_CTRL_PS_HIB_EN, 0);
+}
+
 static int at803x_config_init(struct phy_device *phydev)
 {
 	struct at803x_priv *priv = phydev->priv;
@@ -1051,6 +1072,10 @@ static int at803x_config_init(struct phy_device *phydev)
 	if (ret < 0)
 		return ret;
 
+	ret = at803x_hibernation_config(phydev);
+	if (ret < 0)
+		return ret;
+
 	/* Ar803x extended next page bit is enabled by default. Cisco
 	 * multigig switches read this bit and attempt to negotiate 10Gbps
 	 * rates even if the next page bit is disabled. This is incorrect
-- 
2.25.1


^ permalink raw reply related

* [PATCH net 1/2] dt: ar803x: Document disable-hibernation property
From: wei.fang @ 2022-08-12 14:50 UTC (permalink / raw)
  To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, robh+dt,
	krzysztof.kozlowski+dt, f.fainelli, netdev, devicetree,
	linux-kernel
In-Reply-To: <20220812145009.1229094-1-wei.fang@nxp.com>

From: Wei Fang <wei.fang@nxp.com>

The hibernation mode of Atheros AR803x PHYs is default enabled.
When the cable is unplugged, the PHY will enter hibernation
mode and the PHY clock does down. For some MACs, it needs the
clock to support it's logic. For instance, stmmac needs the PHY
inputs clock is present for software reset completion. Therefore,
It is reasonable to add a DT property to disable hibernation mode.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 Documentation/devicetree/bindings/net/qca,ar803x.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
index b3d4013b7ca6..d08431d79b83 100644
--- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
+++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
@@ -40,6 +40,12 @@ properties:
       Only supported on the AR8031.
     type: boolean
 
+  qca,disable-hibernation:
+    description: |
+    If set, the PHY will not enter hibernation mode when the cable is
+    unplugged.
+    type: boolean
+
   qca,smarteee-tw-us-100m:
     description: EEE Tw parameter for 100M links.
     $ref: /schemas/types.yaml#/definitions/uint32
-- 
2.25.1


^ permalink raw reply related

* [PATCH net 0/2] Add DT property to disable hibernation mode
From: wei.fang @ 2022-08-12 14:50 UTC (permalink / raw)
  To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, robh+dt,
	krzysztof.kozlowski+dt, f.fainelli, netdev, devicetree,
	linux-kernel

From: Wei Fang <wei.fang@nxp.com>

The patches add the ability to disable the hibernation mode of AR803x
PHYs. Hibernation mode defaults to enabled after hardware reset on
these PHYs. If the AR803x PHYs enter hibernation mode, they will not
provide any clock. For some MACs, they might need the clocks which
provided by the PHYs to support their own hardware logic.
So, the patches add the supoort to disable hibernation mode by adding
a boolean:
	qca,disable-hibernation
If one wished to disable hibernation mode to better match with the
specifical MAC, just add this property in the phy node of DT.

Wei Fang (2):
  dt: ar803x: Document disable-hibernation property
  net: phy: at803x: Add disable hibernation mode support

 .../devicetree/bindings/net/qca,ar803x.yaml   |  6 +++++
 drivers/net/phy/at803x.c                      | 25 +++++++++++++++++++
 2 files changed, 31 insertions(+)

-- 
2.25.1


^ permalink raw reply

* [PATCH] ip6_tunnel: Fix the type of functions
From: Hongbin Wang @ 2022-08-12  3:38 UTC (permalink / raw)
  To: davem
  Cc: yoshfuji, dsahern, edumazet, sahern, kuba, pabeni, netdev,
	linux-kernel

Functions ip6_tnl_change, ip6_tnl_update and ip6_tnl0_update do always
return 0, change the type of functions to void.

Signed-off-by: Hongbin Wang <wh_bin@126.com>
---
 net/ipv6/ip6_tunnel.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 3fda5634578c..79c6a827dea9 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1517,7 +1517,7 @@ static void ip6_tnl_link_config(struct ip6_tnl *t)
  *   ip6_tnl_change() updates the tunnel parameters
  **/
 
-static int
+static void
 ip6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p)
 {
 	t->parms.laddr = p->laddr;
@@ -1531,29 +1531,25 @@ ip6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p)
 	t->parms.fwmark = p->fwmark;
 	dst_cache_reset(&t->dst_cache);
 	ip6_tnl_link_config(t);
-	return 0;
 }
 
-static int ip6_tnl_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
+static void ip6_tnl_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
 {
 	struct net *net = t->net;
 	struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
-	int err;
 
 	ip6_tnl_unlink(ip6n, t);
 	synchronize_net();
-	err = ip6_tnl_change(t, p);
+	ip6_tnl_change(t, p);
 	ip6_tnl_link(ip6n, t);
 	netdev_state_change(t->dev);
-	return err;
 }
 
-static int ip6_tnl0_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
+static void ip6_tnl0_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
 {
 	/* for default tnl0 device allow to change only the proto */
 	t->parms.proto = p->proto;
 	netdev_state_change(t->dev);
-	return 0;
 }
 
 static void
@@ -1667,9 +1663,9 @@ ip6_tnl_siocdevprivate(struct net_device *dev, struct ifreq *ifr,
 			} else
 				t = netdev_priv(dev);
 			if (dev == ip6n->fb_tnl_dev)
-				err = ip6_tnl0_update(t, &p1);
+				ip6_tnl0_update(t, &p1);
 			else
-				err = ip6_tnl_update(t, &p1);
+				ip6_tnl_update(t, &p1);
 		}
 		if (!IS_ERR(t)) {
 			err = 0;
@@ -2091,7 +2087,8 @@ static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[],
 	} else
 		t = netdev_priv(dev);
 
-	return ip6_tnl_update(t, &p);
+	ip6_tnl_update(t, &p);
+	return 0;
 }
 
 static void ip6_tnl_dellink(struct net_device *dev, struct list_head *head)
-- 
2.25.1


^ permalink raw reply related

* Re: [PATCH bpf-next v2 1/3] bpf: Add skb dynptrs
From: kernel test robot @ 2022-08-12  5:57 UTC (permalink / raw)
  To: Joanne Koong, bpf
  Cc: kbuild-all, kafai, kuba, andrii, daniel, ast, netdev, kernel-team,
	Joanne Koong
In-Reply-To: <20220811230501.2632393-2-joannelkoong@gmail.com>

Hi Joanne,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Joanne-Koong/Add-skb-xdp-dynptrs/20220812-070634
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-defconfig (https://download.01.org/0day-ci/archive/20220812/202208121318.MVYzenNA-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
        # https://github.com/intel-lab-lkp/linux/commit/ecab09dda7739b27ffd6ed6c93753f6dfd9bdcb2
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Joanne-Koong/Add-skb-xdp-dynptrs/20220812-070634
        git checkout ecab09dda7739b27ffd6ed6c93753f6dfd9bdcb2
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   ld: net/core/filter.o: in function `bpf_dynptr_from_skb':
>> filter.c:(.text+0x84eb): undefined reference to `bpf_dynptr_init'
>> ld: filter.c:(.text+0x8511): undefined reference to `bpf_dynptr_set_rdonly'
>> ld: filter.c:(.text+0x8521): undefined reference to `bpf_dynptr_set_null'

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

^ permalink raw reply

* [PATCH] Bluetooth: L2CAP: Elide a string overflow warning
From: Palmer Dabbelt @ 2022-08-12  5:52 UTC (permalink / raw)
  To: marcel, johan.hedberg
  Cc: luiz.dentz, davem, edumazet, kuba, pabeni, linux-bluetooth,
	netdev, linux-kernel, linux, Palmer Dabbelt

From: Palmer Dabbelt <palmer@rivosinc.com>

Without this I get a string op warning related to copying from a
possibly NULL pointer.  I think the warning is spurious, but it's
tripping up allmodconfig.

In file included from /scratch/merges/ko-linux-next/linux/include/linux/string.h:253,
                 from /scratch/merges/ko-linux-next/linux/include/linux/bitmap.h:11,
                 from /scratch/merges/ko-linux-next/linux/include/linux/cpumask.h:12,
                 from /scratch/merges/ko-linux-next/linux/include/linux/mm_types_task.h:14,
                 from /scratch/merges/ko-linux-next/linux/include/linux/mm_types.h:5,
                 from /scratch/merges/ko-linux-next/linux/include/linux/buildid.h:5,
                 from /scratch/merges/ko-linux-next/linux/include/linux/module.h:14,
                 from /scratch/merges/ko-linux-next/linux/net/bluetooth/l2cap_core.c:31:
In function 'memcmp',
    inlined from 'bacmp' at /scratch/merges/ko-linux-next/linux/include/net/bluetooth/bluetooth.h:347:9,
    inlined from 'l2cap_global_chan_by_psm' at /scratch/merges/ko-linux-next/linux/net/bluetooth/l2cap_core.c:2003:15:
/scratch/merges/ko-linux-next/linux/include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
   44 | #define __underlying_memcmp     __builtin_memcmp
      |                                 ^
/scratch/merges/ko-linux-next/linux/include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
  420 |         return __underlying_memcmp(p, q, size);
      |                ^~~~~~~~~~~~~~~~~~~
In function 'memcmp',
    inlined from 'bacmp' at /scratch/merges/ko-linux-next/linux/include/net/bluetooth/bluetooth.h:347:9,
    inlined from 'l2cap_global_chan_by_psm' at /scratch/merges/ko-linux-next/linux/net/bluetooth/l2cap_core.c:2004:15:
/scratch/merges/ko-linux-next/linux/include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
   44 | #define __underlying_memcmp     __builtin_memcmp
      |                                 ^
/scratch/merges/ko-linux-next/linux/include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
  420 |         return __underlying_memcmp(p, q, size);
      |                ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 net/bluetooth/l2cap_core.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index cbe0cae73434..be7f47e52119 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2000,11 +2000,13 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
 			}
 
 			/* Closest match */
-			src_any = !bacmp(&c->src, BDADDR_ANY);
-			dst_any = !bacmp(&c->dst, BDADDR_ANY);
-			if ((src_match && dst_any) || (src_any && dst_match) ||
-			    (src_any && dst_any))
-				c1 = c;
+			if (c) {
+				src_any = !bacmp(&c->src, BDADDR_ANY);
+				dst_any = !bacmp(&c->dst, BDADDR_ANY);
+				if ((src_match && dst_any) || (src_any && dst_match) ||
+				    (src_any && dst_any))
+					c1 = c;
+			}
 		}
 	}
 
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH bpf-next 05/15] bpf: Fix incorrect mem_cgroup_put
From: Muchun Song @ 2022-08-12  5:33 UTC (permalink / raw)
  To: Yafang Shao
  Cc: Shakeel Butt, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song,
	john fastabend, KP Singh, Stanislav Fomichev, Hao Luo, jolsa,
	Johannes Weiner, Michal Hocko, Roman Gushchin, Muchun Song,
	Andrew Morton, netdev, bpf, Linux MM
In-Reply-To: <CALOAHbCXfRKDEt7jsUBsf-pQ-A7TpXPxGKYxu_GZN-8BUe2auw@mail.gmail.com>



> On Aug 12, 2022, at 08:27, Yafang Shao <laoar.shao@gmail.com> wrote:
> 
> On Thu, Aug 11, 2022 at 11:47 PM Shakeel Butt <shakeelb@google.com> wrote:
>> 
>> On Thu, Aug 11, 2022 at 10:49:13AM +0800, Yafang Shao wrote:
>>> On Thu, Aug 11, 2022 at 1:07 AM Shakeel Butt <shakeelb@google.com> wrote:
>>>> 
>>>> On Wed, Aug 10, 2022 at 03:18:30PM +0000, Yafang Shao wrote:
>>>>> The memcg may be the root_mem_cgroup, in which case we shouldn't put it.
>>>> 
>>>> No, it is ok to put root_mem_cgroup. css_put already handles the root
>>>> cgroups.
>>>> 
>>> 
>>> Ah, this commit log doesn't describe the issue clearly. I should improve it.
>>> The issue is that in bpf_map_get_memcg() it doesn't get the objcg if
>>> map->objcg is NULL (that can happen if the map belongs to the root
>>> memcg), so we shouldn't put the objcg if map->objcg is NULL neither in
>>> bpf_map_put_memcg().
>> 
>> Sorry I am still not understanding. We are not 'getting' objcg in
>> bpf_map_get_memcg(). We are 'getting' memcg from map->objcg and if that
>> is NULL the function is returning root memcg and putting root memcg is
>> totally fine.
> 
> When the map belongs to root_mem_cgroup, the map->objcg is NULL, right ?
> See also bpf_map_save_memcg() and it describes clearly in the comment -
> 
> static void bpf_map_save_memcg(struct bpf_map *map)
> {
>        /* Currently if a map is created by a process belonging to the root
>         * memory cgroup, get_obj_cgroup_from_current() will return NULL.
>         * So we have to check map->objcg for being NULL each time it's
>         * being used.
>         */
>        map->objcg = get_obj_cgroup_from_current();
> }
> 
> So for the root_mem_cgroup case, bpf_map_get_memcg() will return
> root_mem_cgroup directly without getting its css, right ? See below,
> 
> static struct mem_cgroup *bpf_map_get_memcg(const struct bpf_map *map)
> {
> 
>        if (map->objcg)
>                return get_mem_cgroup_from_objcg(map->objcg);
> 
>        return root_mem_cgroup;   // without css_get(&memcg->css);
> }
> 
> But it will put the css unconditionally.  See below,
> 
> memcg = bpf_map_get_memcg(map);
> ...
> mem_cgroup_put(memcg);
> 
> So we should put it *conditionally* as well.

Hi,

No. We could put root_mem_cgroup unconditionally since the root css
is treated as no reference css. See css_put().

static inline void css_put(struct cgroup_subsys_state *css)
{
	// The root memcg’s css has been set with CSS_NO_REF.
        if (!(css->flags & CSS_NO_REF))
                percpu_ref_put(&css->refcnt);
}

Muchun,
Thanks.

> 
>  memcg = bpf_map_get_memcg(map);
>   ...
> + if (map->objcg)
>       mem_cgroup_put(memcg);
> 
> Is it clear to you ?
> 
>> Or are you saying that root_mem_cgroup is NULL?
>> 
> 
> No
> 
> -- 
> Regards
> Yafang


^ permalink raw reply

* Re: [PATCH v2 net-next] net: ethernet: ti: davinci_mdio: Add workaround for errata i2329
From: Ravi Gunasekaran @ 2022-08-12  4:36 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: davem, edumazet, kuba, pabeni, linux-omap, netdev, linux-kernel,
	linux-arm-kernel, kishon, vigneshr
In-Reply-To: <YvT8ovgHz2j7yOQP@lunn.ch>


>> There is atleast one device sh_eth, which is not configured for autosuspend
>> but uses the bit bang core in sh_mdiobb_read() and invokes regular runtime
>> PM functions.
> 
> And that is the point of moving it into the core. It would of just
> worked for you.
> 
> If you don't feel comfortable with making this unconditional, please
> put runtime pm enabled version of mdiobb_read/mdiobb_write() in the
> core and swap sh_eth and any other drivers to using them.
> 

sh_eth is not configured for autosuspend and uses only pm_runtime_put().
davinci_mdio is configured for autosuspend and it must invoke 
pm_runtime_mark_last_busy() before calling pm_runtime_put_autosuspend().
So it looks like, there needs to be a runtime PM version of 
mdiobb_read/mdiobb_write() for each pm_runtime_put_*(). As of now, it's 
only sh_eth which is currently using runtime PM and davinci_mdio would 
be the next one. So at least in this case, two variants of 
mdiobb_read/mdiobb_write() could be added at the moment. By checking 
against the dev->power.use_autosuspend flag, it is possible to support 
both via a single version.

That being said, I'm quite inclined towards the existing implementation, 
where drivers can have wrappers written around 
mdiobb_read/mdiobb_write(). But I might be failing to see the broader 
picture. If having multiple runtime PM versions of 
mdiobb_read/mdiobb_write() benefits many other future drivers, then I 
will go ahead and add the variant(s) in the bitbang core.

Please provide your views on this. Your inputs on the next course of 
action would be helpful.

-- 
Regards,
Ravi

^ permalink raw reply

* Re: [PATCH bpf-next v2 1/3] bpf: Add skb dynptrs
From: kernel test robot @ 2022-08-12  4:16 UTC (permalink / raw)
  To: Joanne Koong, bpf
  Cc: kbuild-all, kafai, kuba, andrii, daniel, ast, netdev, kernel-team,
	Joanne Koong
In-Reply-To: <20220811230501.2632393-2-joannelkoong@gmail.com>

Hi Joanne,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Joanne-Koong/Add-skb-xdp-dynptrs/20220812-070634
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: um-i386_defconfig (https://download.01.org/0day-ci/archive/20220812/202208121214.urSMKXgE-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
        # https://github.com/intel-lab-lkp/linux/commit/ecab09dda7739b27ffd6ed6c93753f6dfd9bdcb2
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Joanne-Koong/Add-skb-xdp-dynptrs/20220812-070634
        git checkout ecab09dda7739b27ffd6ed6c93753f6dfd9bdcb2
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 O=build_dir ARCH=um SUBARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   /usr/bin/ld: net/core/filter.o: in function `bpf_dynptr_from_skb':
>> filter.c:(.text+0x4e87): undefined reference to `bpf_dynptr_set_null'
>> /usr/bin/ld: filter.c:(.text+0x4e9e): undefined reference to `bpf_dynptr_init'
>> /usr/bin/ld: filter.c:(.text+0x4eae): undefined reference to `bpf_dynptr_set_rdonly'
   collect2: error: ld returned 1 exit status

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

^ permalink raw reply

* Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Sudip Mukherjee @ 2022-08-12  4:09 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Luiz Augusto von Dentz, Johan Hedberg, Marcel Holtmann,
	David S. Miller, Eric Dumazet, Paolo Abeni, linux-kernel, netdev,
	linux-bluetooth, linux-next, Thomas Bogendoerfer, linux-mips
In-Reply-To: <20220811124637.4cdb84f1@kernel.org>

On Thu, Aug 11, 2022 at 8:46 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 11 Aug 2022 19:53:04 +0100 Sudip Mukherjee (Codethink) wrote:
> > Not sure if it has been reported, builds of csky and mips allmodconfig
> > failed to build next-20220811 with gcc-12.
>
> I can't repro with the cross compiler from kernel.org.
> Can you test something like this?

With this patch I get new failure:

In file included from net/bluetooth/l2cap_core.c:37:
./include/net/bluetooth/bluetooth.h: In function 'ba_is_any':
./include/net/bluetooth/bluetooth.h:346:16: error: returning 'void *'
from a function with return type 'int' makes integer from pointer
without a cast [-Werror=int-conversion]
  346 |         return memchr_inv(ba, sizeof(*ba), 0);

So for a quick test, I modified it a little (just a typecast) which worked.

diff --git a/include/net/bluetooth/bluetooth.h
b/include/net/bluetooth/bluetooth.h
index e72f3b247b5e..19bdd2520070 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -341,6 +341,11 @@ static inline bool bdaddr_type_is_le(u8 type)
 #define BDADDR_ANY  (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
 #define BDADDR_NONE (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})

+static inline int ba_is_any(const bdaddr_t *ba)
+{
+       return (int) memchr_inv(ba, sizeof(*ba), 0);
+}
+
 /* Copy, swap, convert BD Address */
 static inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
 {
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index cbe0cae73434..67c5d923bc6c 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2000,8 +2000,8 @@ static struct l2cap_chan
*l2cap_global_chan_by_psm(int state, __le16 psm,
                        }

                        /* Closest match */
-                       src_any = !bacmp(&c->src, BDADDR_ANY);
-                       dst_any = !bacmp(&c->dst, BDADDR_ANY);
+                       src_any = !ba_is_any(&c->src);
+                       dst_any = !ba_is_any(&c->dst);
                        if ((src_match && dst_any) || (src_any && dst_match) ||
                            (src_any && dst_any))
                                c1 = c;



-- 
Regards
Sudip

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox