Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] [PATCH net] tg3: power down device only on SYSTEM_POWER_OFF
From: Pavan Chebbi @ 2023-11-02  7:04 UTC (permalink / raw)
  To: George Shuklin; +Cc: netdev, Andrew Gospodarek, Michael Chan
In-Reply-To: <31a5cfe8-133d-4548-9814-cf3e61d89307@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On Thu, Nov 2, 2023 at 1:28 AM George Shuklin <george.shuklin@gmail.com> wrote:
>
> On 01/11/2023 17:20, Pavan Chebbi wrote:
> > On Wed, Nov 1, 2023 at 6:34 PM George Shuklin <george.shuklin@gmail.com> wrote:
> >> Dell R650xs servers hangs if tg3 driver calls tg3_power_down.
> >>
> >> This happens only if network adapters (BCM5720 for R650xs) were
> >> initialized using SNP (e.g. by booting ipxe.efi).
> >>
> >> This is partial revert of commit 2ca1c94ce0b.
> >>
> >> The actual problem is on Dell side, but this fix allow servers
> >> to come back alive after reboot.
> > How are you sure that the problem solved by 2ca1c94ce0b is not
> > reintroduced with this change?
>
> I contacted the author of original patch, no reply yet (1st day). Also,
> I tested it on few generations of available Dell servers (R330, R340,
> R350 and R650sx, for which this fix should help). It does produce log
> message from
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917471, but, at
> least, it reboots without issues.
>
> Actually, original patch is regression: 5.19 rebooting just fine, 6.0
> start to hang. I also reported it to dell support forum, but I'm not
> sure if they pick it up or not.
>
> What would be the proper course of actions for such problem (outside of
> fixing UEFI SNP, for which I don't have access to sources)?
>
Thanks for the explanation. I am not sure if we should make this
change unless we are 100pc sure that this patch won't cause
regression.
I feel Dell is in the best position to debug this and they can even
contact Broadcom if they see any problem in UEFI.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4209 bytes --]

^ permalink raw reply

* [PATCH 1/2][net-next] skbuff: move netlink_large_alloc_large_skb() to skbuff.c
From: Li RongQing @ 2023-11-02  6:28 UTC (permalink / raw)
  To: netdev

move netlink_alloc_large_skb and netlink_skb_destructor to skbuff.c
and rename them more generic, so they can be used elsewhere large
non-contiguous physical memory is needed

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 include/linux/skbuff.h   |  3 +++
 net/core/skbuff.c        | 40 ++++++++++++++++++++++++++++++++++++++++
 net/netlink/af_netlink.c | 41 ++---------------------------------------
 3 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 4174c4b..774a401 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -5063,5 +5063,8 @@ static inline void skb_mark_for_recycle(struct sk_buff *skb)
 ssize_t skb_splice_from_iter(struct sk_buff *skb, struct iov_iter *iter,
 			     ssize_t maxsize, gfp_t gfp);
 
+
+void large_skb_destructor(struct sk_buff *skb);
+struct sk_buff *alloc_large_skb(unsigned int size, int broadcast);
 #endif	/* __KERNEL__ */
 #endif	/* _LINUX_SKBUFF_H */
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 4570705..20ffcd5 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6917,3 +6917,43 @@ ssize_t skb_splice_from_iter(struct sk_buff *skb, struct iov_iter *iter,
 	return spliced ?: ret;
 }
 EXPORT_SYMBOL(skb_splice_from_iter);
+
+void large_skb_destructor(struct sk_buff *skb)
+{
+	if (is_vmalloc_addr(skb->head)) {
+		if (!skb->cloned ||
+		    !atomic_dec_return(&(skb_shinfo(skb)->dataref)))
+			vfree(skb->head);
+
+		skb->head = NULL;
+	}
+	if (skb->sk)
+		sock_rfree(skb);
+}
+EXPORT_SYMBOL(large_skb_destructor);
+
+struct sk_buff *alloc_large_skb(unsigned int size,
+					       int broadcast)
+{
+	struct sk_buff *skb;
+	void *data;
+
+	if (size <= NLMSG_GOODSIZE || broadcast)
+		return alloc_skb(size, GFP_KERNEL);
+
+	size = SKB_DATA_ALIGN(size) +
+	       SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+
+	data = vmalloc(size);
+	if (!data)
+		return NULL;
+
+	skb = __build_skb(data, size);
+	if (!skb)
+		vfree(data);
+	else
+		skb->destructor = large_skb_destructor;
+
+	return skb;
+}
+EXPORT_SYMBOL(alloc_large_skb);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 642b9d3..1d50b68 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -369,24 +369,11 @@ static void netlink_rcv_wake(struct sock *sk)
 		wake_up_interruptible(&nlk->wait);
 }
 
-static void netlink_skb_destructor(struct sk_buff *skb)
-{
-	if (is_vmalloc_addr(skb->head)) {
-		if (!skb->cloned ||
-		    !atomic_dec_return(&(skb_shinfo(skb)->dataref)))
-			vfree(skb->head);
-
-		skb->head = NULL;
-	}
-	if (skb->sk != NULL)
-		sock_rfree(skb);
-}
-
 static void netlink_skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
 {
 	WARN_ON(skb->sk != NULL);
 	skb->sk = sk;
-	skb->destructor = netlink_skb_destructor;
+	skb->destructor = large_skb_destructor;
 	atomic_add(skb->truesize, &sk->sk_rmem_alloc);
 	sk_mem_charge(sk, skb->truesize);
 }
@@ -1204,30 +1191,6 @@ struct sock *netlink_getsockbyfilp(struct file *filp)
 	return sock;
 }
 
-static struct sk_buff *netlink_alloc_large_skb(unsigned int size,
-					       int broadcast)
-{
-	struct sk_buff *skb;
-	void *data;
-
-	if (size <= NLMSG_GOODSIZE || broadcast)
-		return alloc_skb(size, GFP_KERNEL);
-
-	size = SKB_DATA_ALIGN(size) +
-	       SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
-
-	data = vmalloc(size);
-	if (data == NULL)
-		return NULL;
-
-	skb = __build_skb(data, size);
-	if (skb == NULL)
-		vfree(data);
-	else
-		skb->destructor = netlink_skb_destructor;
-
-	return skb;
-}
 
 /*
  * Attach a skb to a netlink socket.
@@ -1882,7 +1845,7 @@ static int netlink_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
 	if (len > sk->sk_sndbuf - 32)
 		goto out;
 	err = -ENOBUFS;
-	skb = netlink_alloc_large_skb(len, dst_group);
+	skb = alloc_large_skb(len, dst_group);
 	if (skb == NULL)
 		goto out;
 
-- 
2.9.4


^ permalink raw reply related

* [PATCH 2/2][net-next] rtnetlink: using alloc_large_skb in rtnl_getlink
From: Li RongQing @ 2023-11-02  6:28 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20231102062836.19074-1-lirongqing@baidu.com>

if a PF has 256 or more VFs, ip link command will allocate a order 3
memory and maybe trigger OOM due to memory fragement, rtnl_vfinfo_size
is used to compute the VFs needed memory size

so using alloc_large_skb in which vmalloc is used for large memory,
to avoid the failure of allocating memory

    ip invoked oom-killer: gfp_mask=0xc2cc0(GFP_KERNEL|__GFP_NOWARN|\
	__GFP_COMP|__GFP_NOMEMALLOC), order=3, oom_score_adj=0
    CPU: 74 PID: 204414 Comm: ip Kdump: loaded Tainted: P           OE
    Call Trace:
    dump_stack+0x57/0x6a
    dump_header+0x4a/0x210
    oom_kill_process+0xe4/0x140
    out_of_memory+0x3e8/0x790
    __alloc_pages_slowpath.constprop.116+0x953/0xc50
    __alloc_pages_nodemask+0x2af/0x310
    kmalloc_large_node+0x38/0xf0
    __kmalloc_node_track_caller+0x417/0x4d0
    __kmalloc_reserve.isra.61+0x2e/0x80
    __alloc_skb+0x82/0x1c0
    rtnl_getlink+0x24f/0x370
    rtnetlink_rcv_msg+0x12c/0x350
    netlink_rcv_skb+0x50/0x100
    netlink_unicast+0x1b2/0x280
    netlink_sendmsg+0x355/0x4a0
    sock_sendmsg+0x5b/0x60
    ____sys_sendmsg+0x1ea/0x250
    ___sys_sendmsg+0x88/0xd0
    __sys_sendmsg+0x5e/0xa0
    do_syscall_64+0x33/0x40
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7f95a65a5b70

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 net/core/rtnetlink.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 4a2ec33..be43044 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -3813,7 +3813,8 @@ static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr *nlh,
 		goto out;
 
 	err = -ENOBUFS;
-	nskb = nlmsg_new(if_nlmsg_size(dev, ext_filter_mask), GFP_KERNEL);
+	nskb = alloc_large_skb(
+			nlmsg_total_size(if_nlmsg_size(dev, ext_filter_mask)), 0);
 	if (nskb == NULL)
 		goto out;
 
-- 
2.9.4


^ permalink raw reply related

* [PATCH net v1 3/3] net/smc: put sk reference if close work was canceled
From: D. Wythe @ 2023-11-02  5:52 UTC (permalink / raw)
  To: kgraul, wenjia, jaka, wintera; +Cc: kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <1698904324-33238-1-git-send-email-alibuda@linux.alibaba.com>

From: "D. Wythe" <alibuda@linux.alibaba.com>

Note that we always hold a reference to sock when attempting
to submit close_work. Therefore, if we have successfully
canceled close_work from pending, we MUST release that reference
to avoid potential leaks.

Fixes: 42bfba9eaa33 ("net/smc: immediate termination for SMCD link groups")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
---
 net/smc/smc_close.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/smc/smc_close.c b/net/smc/smc_close.c
index 449ef45..10219f5 100644
--- a/net/smc/smc_close.c
+++ b/net/smc/smc_close.c
@@ -116,7 +116,8 @@ static void smc_close_cancel_work(struct smc_sock *smc)
 	struct sock *sk = &smc->sk;
 
 	release_sock(sk);
-	cancel_work_sync(&smc->conn.close_work);
+	if (cancel_work_sync(&smc->conn.close_work))
+		sock_put(sk);
 	cancel_delayed_work_sync(&smc->conn.tx_work);
 	lock_sock(sk);
 }
-- 
1.8.3.1


^ permalink raw reply related

* [PATCH net v1 2/3] net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc
From: D. Wythe @ 2023-11-02  5:52 UTC (permalink / raw)
  To: kgraul, wenjia, jaka, wintera; +Cc: kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <1698904324-33238-1-git-send-email-alibuda@linux.alibaba.com>

From: "D. Wythe" <alibuda@linux.alibaba.com>

This patch re-fix the issues mentioned by commit 22a825c541d7
("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()").

Blocking sending message do solve the issues though, but it also
prevents the peer to receive the final message. Besides, in logic,
whether the sndbuf_desc is NULL or not have no impact on the processing
of cdc message sending.

Hence that, this patch allows the cdc message sending but to check the
sndbuf_desc with care in smc_cdc_tx_handler().

Fixes: 22a825c541d7 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
---
 net/smc/smc_cdc.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/smc/smc_cdc.c b/net/smc/smc_cdc.c
index 01bdb79..3c06625 100644
--- a/net/smc/smc_cdc.c
+++ b/net/smc/smc_cdc.c
@@ -28,13 +28,15 @@ static void smc_cdc_tx_handler(struct smc_wr_tx_pend_priv *pnd_snd,
 {
 	struct smc_cdc_tx_pend *cdcpend = (struct smc_cdc_tx_pend *)pnd_snd;
 	struct smc_connection *conn = cdcpend->conn;
+	struct smc_buf_desc *sndbuf_desc;
 	struct smc_sock *smc;
 	int diff;
 
+	sndbuf_desc = conn->sndbuf_desc;
 	smc = container_of(conn, struct smc_sock, conn);
 	bh_lock_sock(&smc->sk);
-	if (!wc_status) {
-		diff = smc_curs_diff(cdcpend->conn->sndbuf_desc->len,
+	if (!wc_status && sndbuf_desc) {
+		diff = smc_curs_diff(sndbuf_desc->len,
 				     &cdcpend->conn->tx_curs_fin,
 				     &cdcpend->cursor);
 		/* sndbuf_space is decreased in smc_sendmsg */
@@ -114,9 +116,6 @@ int smc_cdc_msg_send(struct smc_connection *conn,
 	union smc_host_cursor cfed;
 	int rc;
 
-	if (unlikely(!READ_ONCE(conn->sndbuf_desc)))
-		return -ENOBUFS;
-
 	smc_cdc_add_pending_send(conn, pend);
 
 	conn->tx_cdc_seq++;
-- 
1.8.3.1


^ permalink raw reply related

* [PATCH net v1 1/3] net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT
From: D. Wythe @ 2023-11-02  5:52 UTC (permalink / raw)
  To: kgraul, wenjia, jaka, wintera; +Cc: kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <1698904324-33238-1-git-send-email-alibuda@linux.alibaba.com>

From: "D. Wythe" <alibuda@linux.alibaba.com>

Considering scenario:

				smc_cdc_rx_handler
__smc_release
				sock_set_flag
smc_close_active()
sock_set_flag

__set_bit(DEAD)			__set_bit(DONE)

Dues to __set_bit is not atomic, the DEAD or DONE might be lost.
if the DEAD flag lost, the state SMC_CLOSED  will be never be reached
in smc_close_passive_work:

if (sock_flag(sk, SOCK_DEAD) &&
	smc_close_sent_any_close(conn)) {
	sk->sk_state = SMC_CLOSED;
} else {
	/* just shutdown, but not yet closed locally */
	sk->sk_state = SMC_APPFINCLOSEWAIT;
}

Replace sock_set_flags or __set_bit to set_bit will fix this problem.
Since set_bit is atomic.

Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
---
 net/smc/af_smc.c    | 4 ++--
 net/smc/smc.h       | 5 +++++
 net/smc/smc_cdc.c   | 2 +-
 net/smc/smc_close.c | 2 +-
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index abd2667..da97f94 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -275,7 +275,7 @@ static int __smc_release(struct smc_sock *smc)
 
 	if (!smc->use_fallback) {
 		rc = smc_close_active(smc);
-		sock_set_flag(sk, SOCK_DEAD);
+		smc_sock_set_flag(sk, SOCK_DEAD);
 		sk->sk_shutdown |= SHUTDOWN_MASK;
 	} else {
 		if (sk->sk_state != SMC_CLOSED) {
@@ -1743,7 +1743,7 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
 		if (new_clcsock)
 			sock_release(new_clcsock);
 		new_sk->sk_state = SMC_CLOSED;
-		sock_set_flag(new_sk, SOCK_DEAD);
+		smc_sock_set_flag(new_sk, SOCK_DEAD);
 		sock_put(new_sk); /* final */
 		*new_smc = NULL;
 		goto out;
diff --git a/net/smc/smc.h b/net/smc/smc.h
index 24745fd..e377980 100644
--- a/net/smc/smc.h
+++ b/net/smc/smc.h
@@ -377,4 +377,9 @@ void smc_fill_gid_list(struct smc_link_group *lgr,
 int smc_nl_enable_hs_limitation(struct sk_buff *skb, struct genl_info *info);
 int smc_nl_disable_hs_limitation(struct sk_buff *skb, struct genl_info *info);
 
+static inline void smc_sock_set_flag(struct sock *sk, enum sock_flags flag)
+{
+	set_bit(flag, &sk->sk_flags);
+}
+
 #endif	/* __SMC_H */
diff --git a/net/smc/smc_cdc.c b/net/smc/smc_cdc.c
index 89105e9..01bdb79 100644
--- a/net/smc/smc_cdc.c
+++ b/net/smc/smc_cdc.c
@@ -385,7 +385,7 @@ static void smc_cdc_msg_recv_action(struct smc_sock *smc,
 		smc->sk.sk_shutdown |= RCV_SHUTDOWN;
 		if (smc->clcsock && smc->clcsock->sk)
 			smc->clcsock->sk->sk_shutdown |= RCV_SHUTDOWN;
-		sock_set_flag(&smc->sk, SOCK_DONE);
+		smc_sock_set_flag(&smc->sk, SOCK_DONE);
 		sock_hold(&smc->sk); /* sock_put in close_work */
 		if (!queue_work(smc_close_wq, &conn->close_work))
 			sock_put(&smc->sk);
diff --git a/net/smc/smc_close.c b/net/smc/smc_close.c
index dbdf03e..449ef45 100644
--- a/net/smc/smc_close.c
+++ b/net/smc/smc_close.c
@@ -173,7 +173,7 @@ void smc_close_active_abort(struct smc_sock *smc)
 		break;
 	}
 
-	sock_set_flag(sk, SOCK_DEAD);
+	smc_sock_set_flag(sk, SOCK_DEAD);
 	sk->sk_state_change(sk);
 
 	if (release_clcsock) {
-- 
1.8.3.1


^ permalink raw reply related

* [PATCH net v1 0/3] bugfixs for smc
From: D. Wythe @ 2023-11-02  5:52 UTC (permalink / raw)
  To: kgraul, wenjia, jaka, wintera; +Cc: kuba, davem, netdev, linux-s390, linux-rdma

From: "D. Wythe" <alibuda@linux.alibaba.com>

This patches includes bugfix following:

1. hung state
2. sock leak
3. potential panic 

We have been testing these patches for some time, but
if you have any questions, please let us know.

--
v1:
Fix spelling errors and incorrect function names in descriptions

D. Wythe (3):
  net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT
  net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc
  net/smc: put sk reference if close work was canceled

 net/smc/af_smc.c    |  4 ++--
 net/smc/smc.h       |  5 +++++
 net/smc/smc_cdc.c   | 11 +++++------
 net/smc/smc_close.c |  5 +++--
 4 files changed, 15 insertions(+), 10 deletions(-)

-- 
1.8.3.1


^ permalink raw reply

* Re: [PATCH net-next] net: xscale: Drop unused PHY number
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: Linus Walleij
  Cc: khalasa, davem, edumazet, kuba, pabeni, hharte, netdev,
	linux-kernel
In-Reply-To: <20231028-ixp4xx-eth-id-v1-1-57be486d7f0f@linaro.org>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Sat, 28 Oct 2023 22:48:35 +0200 you wrote:
> For some cargoculted reason on incomplete cleanup, we have a
> PHY number which refers to nothing and gives confusing messages
> about PHY 0 on all ports.
> 
> Print the name of the actual PHY device instead.
> 
> Reported-by: Howard Harte <hharte@magicandroidapps.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> 
> [...]

Here is the summary with links:
  - [net-next] net: xscale: Drop unused PHY number
    https://git.kernel.org/netdev/net/c/d280783c3ad9

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] hsr: Prevent use after free in prp_create_tagged_frame()
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: m-karicheri2, davem, edumazet, kuba, pabeni, bigeasy, yuehaibing,
	william.xuanziyang, netdev, kernel-janitors
In-Reply-To: <57af1f28-7f57-4a96-bcd3-b7a0f2340845@moroto.mountain>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 27 Oct 2023 15:19:01 +0300 you wrote:
> The prp_fill_rct() function can fail.  In that situation, it frees the
> skb and returns NULL.  Meanwhile on the success path, it returns the
> original skb.  So it's straight forward to fix bug by using the returned
> value.
> 
> Fixes: 451d8123f897 ("net: prp: add packet handling support")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> 
> [...]

Here is the summary with links:
  - [net] hsr: Prevent use after free in prp_create_tagged_frame()
    https://git.kernel.org/netdev/net/c/876f8ab52363

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 v3] tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: Shigeru Yoshida
  Cc: jmaloy, ying.xue, netdev, tipc-discussion, linux-kernel,
	syzbot+5138ca807af9d2b42574, syzbot+9425c47dccbcb4c17d51
In-Reply-To: <20231030075540.3784537-1-syoshida@redhat.com>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 30 Oct 2023 16:55:40 +0900 you wrote:
> syzbot reported the following uninit-value access issue [1]:
> 
> =====================================================
> BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
> BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
>  strlen lib/string.c:418 [inline]
>  strstr+0xb8/0x2f0 lib/string.c:756
>  tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
>  genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
>  genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
>  genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
>  netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
>  genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
>  netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
>  netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
>  netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
>  sock_sendmsg_nosec net/socket.c:730 [inline]
>  sock_sendmsg net/socket.c:753 [inline]
>  ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
>  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
>  __sys_sendmsg net/socket.c:2624 [inline]
>  __do_sys_sendmsg net/socket.c:2633 [inline]
>  __se_sys_sendmsg net/socket.c:2631 [inline]
>  __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> [...]

Here is the summary with links:
  - [net,v3] tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
    https://git.kernel.org/netdev/net/c/19b3f72a41a8

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 v2] llc: verify mac len before reading mac header
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: Willem de Bruijn
  Cc: netdev, davem, kuba, edumazet, pabeni, stable, willemb,
	syzbot+a8c7be6dee0de1b669cc
In-Reply-To: <20231025234251.3796495-1-willemdebruijn.kernel@gmail.com>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 25 Oct 2023 19:42:38 -0400 you wrote:
> From: Willem de Bruijn <willemb@google.com>
> 
> LLC reads the mac header with eth_hdr without verifying that the skb
> has an Ethernet header.
> 
> Syzbot was able to enter llc_rcv on a tun device. Tun can insert
> packets without mac len and with user configurable skb->protocol
> (passing a tun_pi header when not configuring IFF_NO_PI).
> 
> [...]

Here is the summary with links:
  - [net,v2] llc: verify mac len before reading mac header
    https://git.kernel.org/netdev/net/c/7b3ba18703a6

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] rxrpc: Fix two connection reaping bugs
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: David Howells
  Cc: linux-afs, marc.dionne, davem, edumazet, kuba, pabeni, netdev,
	linux-kernel
In-Reply-To: <783911.1698364174@warthog.procyon.org.uk>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 27 Oct 2023 00:49:34 +0100 you wrote:
> Fix two connection reaping bugs:
> 
>  (1) rxrpc_connection_expiry is in units of seconds, so
>      rxrpc_disconnect_call() needs to multiply it by HZ when adding it to
>      jiffies.
> 
>  (2) rxrpc_client_conn_reap_timeout() should set RXRPC_CLIENT_REAP_TIMER if
>      local->kill_all_client_conns is clear, not if it is set (in which case
>      we don't need the timer).  Without this, old client connections don't
>      get cleaned up until the local endpoint is cleaned up.
> 
> [...]

Here is the summary with links:
  - [net] rxrpc: Fix two connection reaping bugs
    https://git.kernel.org/netdev/net/c/61e4a8660002

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] net/tcp_sigpool: Fix some off by one bugs
From: patchwork-bot+netdevbpf @ 2023-11-02  5:51 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: 0x7f454c46, edumazet, davem, dsahern, kuba, pabeni,
	Steen.Hegelund, netdev, kernel-janitors
In-Reply-To: <ce915d61-04bc-44fb-b450-35fcc9fc8831@moroto.mountain>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 31 Oct 2023 12:51:09 +0300 you wrote:
> The "cpool_populated" variable is the number of elements in the cpool[]
> array that have been populated.  It is incremented in
> tcp_sigpool_alloc_ahash() every time we populate a new element.
> Unpopulated elements are NULL but if we have populated every element then
> this code will read one element beyond the end of the array.
> 
> Fixes: 8c73b26315aa ("net/tcp: Prepare tcp_md5sig_pool for TCP-AO")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> 
> [...]

Here is the summary with links:
  - [net] net/tcp_sigpool: Fix some off by one bugs
    https://git.kernel.org/netdev/net/c/74da77921333

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* RE: [Intel-wired-lan] [PATCH net-next 2/2] i40e: Fix devlink port unregistering
From: Pucha, HimasekharX Reddy @ 2023-11-02  5:33 UTC (permalink / raw)
  To: ivecera, netdev@vger.kernel.org
  Cc: intel-wired-lan@lists.osuosl.org, Brandeburg, Jesse,
	linux-kernel@vger.kernel.org, Eric Dumazet, Nguyen, Anthony L,
	Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <20231024125109.844045-2-ivecera@redhat.com>

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Ivan Vecera
> Sent: Tuesday, October 24, 2023 6:21 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Brandeburg, Jesse <jesse.brandeburg@intel.com>; linux-kernel@vger.kernel.org; Eric Dumazet <edumazet@google.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH net-next 2/2] i40e: Fix devlink port unregistering
>
> Ensure that devlink port is unregistered after unregistering
> of net device.
>
> Reproducer:
> [root@host ~]# rmmod i40e
> [ 4742.939386] i40e 0000:02:00.1: i40e_ptp_stop: removed PHC on enp2s0f1np1
> [ 4743.059269] ------------[ cut here ]------------
> [ 4743.063900] WARNING: CPU: 21 PID: 10766 at net/devlink/port.c:1078 devl_port_unregister+0x69/0x80
> ...
>
> Fixes: 9e479d64dc58 ("i40e: Add initial devlink support")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)


^ permalink raw reply

* RE: [Intel-wired-lan] [PATCH net-next 1/2] i40e: Do not call devlink_port_type_clear()
From: Pucha, HimasekharX Reddy @ 2023-11-02  5:30 UTC (permalink / raw)
  To: ivecera, netdev@vger.kernel.org
  Cc: intel-wired-lan@lists.osuosl.org, Brandeburg, Jesse,
	linux-kernel@vger.kernel.org, Eric Dumazet, Nguyen, Anthony L,
	Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <20231024125109.844045-1-ivecera@redhat.com>

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Ivan Vecera
> Sent: Tuesday, October 24, 2023 6:21 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Brandeburg, Jesse <jesse.brandeburg@intel.com>; linux-kernel@vger.kernel.org; Eric Dumazet <edumazet@google.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH net-next 1/2] i40e: Do not call devlink_port_type_clear()
>
> Do not call devlink_port_type_clear() prior devlink port unregister
> and let devlink core to take care about it.
>
> Reproducer:
> [root@host ~]# rmmod i40e
> [ 4539.964699] i40e 0000:02:00.0: devlink port type for port 0 cleared without a software interface reference, device type not supported by the kernel?
> [ 4540.319811] i40e 0000:02:00.1: devlink port type for port 1 cleared without a software interface reference, device type not supported by the kernel?
>
> Fixes: 9e479d64dc58 ("i40e: Add initial devlink support")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_devlink.c | 1 -
>  1 file changed, 1 deletion(-)
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)


^ permalink raw reply

* Re: [PATCH 2/2] tg3: Fix the TX ring stall
From: alexey.pakhunov @ 2023-11-02  5:29 UTC (permalink / raw)
  To: michael.chan
  Cc: alexey.pakhunov, linux-kernel, mchan, netdev, prashant,
	siva.kallam, vincent.wong2
In-Reply-To: <CACKFLi=Eh2ase5qnQ0ioYL+yS6-oSeZreHsaqAn9Zgwkv_d-Bw@mail.gmail.com>

> > Let me re-test the goto version and resubmit it as v2. Please let me know
> > which version of the patch you prefer more.
> >
> 
> I did not realize the goto version is almost as big.  In that case,
> your original version is fine.
> 
> You might want to declare the variables in reverse Xmas tree style for
> any new code.  This driver is old and most of the existing code does
> not follow that style.

Copy, thanks. I'll reorder the locals in tg3_start_xmit() and resubmit that
as v2.

Alex.

^ permalink raw reply

* RE: [Intel-wired-lan] [PATCH iwl-next v5] ice: read internal temperature sensor
From: Pucha, HimasekharX Reddy @ 2023-11-02  5:25 UTC (permalink / raw)
  To: Knitter, Konrad, intel-wired-lan@lists.osuosl.org
  Cc: jdelvare@suse.com, netdev@vger.kernel.org, Knitter, Konrad,
	Joyner, Eric, Marcin Szycik, Marcin Domagala, Kitszel, Przemyslaw,
	linux@roeck-us.net
In-Reply-To: <20231024110041.23687-1-konrad.knitter@intel.com>

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Konrad Knitter
> Sent: Tuesday, October 24, 2023 4:31 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: jdelvare@suse.com; netdev@vger.kernel.org; Knitter, Konrad <konrad.knitter@intel.com>; Joyner, Eric <eric.joyner@intel.com>; Marcin Szycik <marcin.szycik@linux.intel.com>; Marcin Domagala <marcinx.domagala@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; linux@roeck-us.net
> Subject: [Intel-wired-lan] [PATCH iwl-next v5] ice: read internal temperature sensor
>
> Since 4.30 firmware exposes internal thermal sensor reading via admin
> queue commands. Expose those readouts via hwmon API when supported.
>
> Datasheet:
>
> Get Sensor Reading Command (Opcode: 0x0632)
>
> +--------------------+--------+--------------------+-------------------------+
> | Name               | Bytes  | Value              |          Remarks        |
> +--------------------+--------+--------------------+-------------------------+
> | Flags              | 1-0    |                    |                         |
> | Opcode             | 2-3    | 0x0632             | Command opcode          |
> | Datalen            | 4-5    | 0                  | No external buffer.     |
> | Return value       | 6-7    |                    | Return value.           |
> | Cookie High        | 8-11   | Cookie             |                         |
> | Cookie Low         | 12-15  | Cookie             |                         |
> | Sensor             | 16     |                    | 0x00: Internal temp     |
> |                    |        |                    | 0x01-0xFF: Reserved.    |
> | Format             | 17     | Requested response | Only 0x00 is supported. |
> |                    |        | format             | 0x01-0xFF: Reserved.    |
> | Reserved           | 18-23  |                    |                         |
> | Data Address high  | 24-27  | Response buffer    |                         |
> |                    |        | address            |                         |
> | Data Address low   | 28-31  | Response buffer    |                         |
> |                    |        | address            |                         |
> +--------------------+--------+--------------------+-------------------------+
> 
> Get Sensor Reading Response (Opcode: 0x0632)
> 
> +--------------------+--------+--------------------+-------------------------+
> | Name               | Bytes  | Value              |          Remarks        |
> +--------------------+--------+--------------------+-------------------------+
> | Flags              | 1-0    |                    |                         |
> | Opcode             | 2-3    | 0x0632             | Command opcode          |
> | Datalen            | 4-5    | 0                  | No external buffer      |
> | Return value       | 6-7    |                    | Return value.           |
> |                    |        |                    | EINVAL: Invalid         |
> |                    |        |                    | parameters              |
> |                    |        |                    | ENOENT: Unsupported     |
> |                    |        |                    | sensor                  |
> |                    |        |                    | EIO: Sensor access      |
> |                    |        |                    | error                   |
> | Cookie High        | 8-11   | Cookie             |                         |
> | Cookie Low         | 12-15  | Cookie             |                         |
> | Sensor Reading     | 16-23  |                    | Format of the reading   |
> |                    |        |                    | is dependent on request |
> | Data Address high  | 24-27  | Response buffer    |                         |
> |                    |        | address            |                         |
> | Data Address low   | 28-31  | Response buffer    |                         |
> |                    |        | address            |                         |
> +--------------------+--------+--------------------+-------------------------+
>
> Sensor Reading for Sensor 0x00 (Internal Chip Temperature):
> 
> +--------------------+--------+--------------------+-------------------------+
> | Name               | Bytes  | Value              |          Remarks        |
> +--------------------+--------+--------------------+-------------------------+
> | Thermal Sensor     | 0      |                    | Reading in degrees      |
> | reading            |        |                    | Celsius. Signed int8    |
> | Warning High       | 1      |                    | Warning High threshold  |
> | threshold          |        |                    | in degrees Celsius.     |
> |                    |        |                    | Unsigned int8.          |
> |                    |        |                    | 0xFF when unsupported   |
> | Critical High      | 2      |                    | Critical High threshold |
> | threshold          |        |                    | in degrees Celsius.     |
> |                    |        |                    | Unsigned int8.          |
> |                    |        |                    | 0xFF when unsupported   |
> | Fatal High         | 3      |                    | Fatal High threshold    |
> | threshold          |        |                    | in degrees Celsius.     |
> |                    |        |                    | Unsigned int8.          |
> |                    |        |                    | 0xFF when unsupported   |
> | Reserved           | 4-7    |                    |                         |
> +--------------------+--------+--------------------+-------------------------+
>
> Driver provides current reading from HW as well as device specific
> thresholds for thermal alarm (Warning, Critical, Fatal) events.
>
> $ sensors
> 
> Output
> =========================================================
> ice-pci-b100
> Adapter: PCI adapter
> temp1:        +62.0°C  (high = +95.0°C, crit = +105.0°C)
>                        (emerg = +115.0°C)
>
> Tested on Intel Corporation Ethernet Controller E810-C for SFP
>
> Co-developed-by: Marcin Domagala <marcinx.domagala@intel.com>
> Signed-off-by: Marcin Domagala <marcinx.domagala@intel.com>
> Co-developed-by: Eric Joyner <eric.joyner@intel.com>
> Signed-off-by: Eric Joyner <eric.joyner@intel.com>
> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Signed-off-by: Konrad Knitter <konrad.knitter@intel.com>
> ---
> v5: additional documentation, fix CONFIG_ICE=y, CONFIG_HWMON=m
> v4: added dependency config_hwmon, cleanups
> v3: add SPDX identification to ice_hwmon files
> v2: fix formmating issues, added hwmon maintainers to Cc
> ---
>  drivers/net/ethernet/intel/Kconfig            |  11 ++
>  drivers/net/ethernet/intel/ice/Makefile       |   1 +
>  drivers/net/ethernet/intel/ice/ice.h          |   1 +
>  .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  28 ++++
>  drivers/net/ethernet/intel/ice/ice_common.c   |  54 +++++++-
>  drivers/net/ethernet/intel/ice/ice_common.h   |   2 +
>  drivers/net/ethernet/intel/ice/ice_hwmon.c    | 126 ++++++++++++++++++
>  drivers/net/ethernet/intel/ice/ice_hwmon.h    |  15 +++
>  drivers/net/ethernet/intel/ice/ice_main.c     |   5 +
>  drivers/net/ethernet/intel/ice/ice_type.h     |   7 +
>  10 files changed, 249 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/net/ethernet/intel/ice/ice_hwmon.c
>  create mode 100644 drivers/net/ethernet/intel/ice/ice_hwmon.h
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)


^ permalink raw reply

* Re: [PATCH net] virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()
From: Jakub Kicinski @ 2023-11-02  5:20 UTC (permalink / raw)
  To: Shigeru Yoshida
  Cc: stefanha, sgarzare, davem, edumazet, pabeni, kvm, virtualization,
	netdev, linux-kernel
In-Reply-To: <20231026150154.3536433-1-syoshida@redhat.com>

On Fri, 27 Oct 2023 00:01:54 +0900 Shigeru Yoshida wrote:
> This issue occurs because the `buf_alloc` and `fwd_cnt` fields of the
> `struct virtio_vsock_hdr` are not initialized when a new skb is allocated
> in `virtio_transport_alloc_skb()`. This patch resolves the issue by
> initializing these fields during allocation.

We didn't manage to apply this before the merge window, and now the
trees have converged. Patch no longer applies cleanly to net.
Please rebase & repost.
-- 
pw-bot: cr

^ permalink raw reply

* Re: [patch net] netlink: specs: devlink: add forgotten port function caps enum values
From: patchwork-bot+netdevbpf @ 2023-11-02  5:20 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, kuba, pabeni, davem, edumazet, jacob.e.keller
In-Reply-To: <20231030161750.110420-1-jiri@resnulli.us>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 30 Oct 2023 17:17:50 +0100 you wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> Add two enum values that the blamed commit omitted.
> 
> Fixes: f2f9dd164db0 ("netlink: specs: devlink: add the remaining command to generate complete split_ops")
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> 
> [...]

Here is the summary with links:
  - [net] netlink: specs: devlink: add forgotten port function caps enum values
    https://git.kernel.org/netdev/net/c/05f0431bb90f

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-next] tools: ynl-gen: don't touch the output file if content is the same
From: patchwork-bot+netdevbpf @ 2023-11-02  5:20 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: davem, netdev, edumazet, pabeni, jiri
In-Reply-To: <20231027223408.1865704-1-kuba@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 27 Oct 2023 15:34:08 -0700 you wrote:
> I often regenerate all YNL files in the tree to make sure they
> are in sync with the codegen and specs. Generator rewrites
> the files unconditionally, so since make looks at file modification
> time to decide what to rebuild - my next build takes longer.
> 
> We already generate the code to a tempfile most of the time,
> only overwrite the target when we have to.
> 
> [...]

Here is the summary with links:
  - [net-next] tools: ynl-gen: don't touch the output file if content is the same
    https://git.kernel.org/netdev/net/c/2b7ac0c87d98

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 v1 net-next 0/2] Add missing MODULE_DESCRIPTIONS
From: patchwork-bot+netdevbpf @ 2023-11-02  5:10 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: netdev, hkallweit1, rmk+kernel, f.fainelli, richardcochran, joel,
	andrew
In-Reply-To: <20231028184458.99448-1-andrew@lunn.ch>

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Sat, 28 Oct 2023 20:44:56 +0200 you wrote:
> Fixup PHY and MDIO drivers which are missing MODULE_DESCRIPTION.
> 
> Andrew Lunn (2):
>   net: phy: fill in missing MODULE_DESCRIPTION()s
>   net: mdio: fill in missing MODULE_DESCRIPTION()s
> 
>  drivers/net/mdio/acpi_mdio.c    | 1 +
>  drivers/net/mdio/fwnode_mdio.c  | 1 +
>  drivers/net/mdio/mdio-aspeed.c  | 1 +
>  drivers/net/mdio/mdio-bitbang.c | 1 +
>  drivers/net/mdio/of_mdio.c      | 1 +
>  drivers/net/phy/bcm-phy-ptp.c   | 1 +
>  drivers/net/phy/bcm87xx.c       | 1 +
>  drivers/net/phy/phylink.c       | 1 +
>  drivers/net/phy/sfp.c           | 1 +
>  9 files changed, 9 insertions(+)

Here is the summary with links:
  - [v1,net-next,1/2] net: phy: fill in missing MODULE_DESCRIPTION()s
    https://git.kernel.org/netdev/net/c/dd9d75fcf0f4
  - [v1,net-next,2/2] net: mdio: fill in missing MODULE_DESCRIPTION()s
    https://git.kernel.org/netdev/net/c/031fba65fc20

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-next 0/3] net: sched: Fill in missing MODULE_DESCRIPTIONs for net/sched
From: patchwork-bot+netdevbpf @ 2023-11-02  5:10 UTC (permalink / raw)
  To: Victor Nogueira
  Cc: davem, edumazet, kuba, pabeni, jhs, xiyou.wangcong, jiri,
	vinicius.gomes, stephen, netdev, kernel
In-Reply-To: <20231027155045.46291-1-victor@mojatatu.com>

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 27 Oct 2023 08:50:42 -0700 you wrote:
> W=1 builds now warn if module is built without a MODULE_DESCRIPTION().
> 
> Fill in the missing MODULE_DESCRIPTIONs for net/sched
> 
> Victor Nogueira (3):
>   net: sched: Fill in MODULE_DESCRIPTION for act_gate
>   net: sched: Fill in missing MODULE_DESCRIPTION for classifiers
>   net: sched: Fill in missing MODULE_DESCRIPTION for qdiscs
> 
> [...]

Here is the summary with links:
  - [net-next,1/3] net: sched: Fill in MODULE_DESCRIPTION for act_gate
    https://git.kernel.org/netdev/net/c/49b02a19c23a
  - [net-next,2/3] net: sched: Fill in missing MODULE_DESCRIPTION for classifiers
    https://git.kernel.org/netdev/net/c/a9c92771fa23
  - [net-next,3/3] net: sched: Fill in missing MODULE_DESCRIPTION for qdiscs
    https://git.kernel.org/netdev/net/c/f96118c5d86f

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,v2] hv_netvsc: fix race of netvsc and VF register_netdevice
From: Jakub Kicinski @ 2023-11-02  5:07 UTC (permalink / raw)
  To: Haiyang Zhang
  Cc: linux-hyperv, netdev, kys, wei.liu, decui, edumazet, pabeni,
	davem, linux-kernel, stable
In-Reply-To: <1698355354-12869-1-git-send-email-haiyangz@microsoft.com>

On Thu, 26 Oct 2023 14:22:34 -0700 Haiyang Zhang wrote:
> And, move register_netdevice_notifier() earlier, so the call back
> function is set before probing.

Are you sure you need this? I thought the netdev notifier "replays"
registration events (i.e. sends "fake" events for already present
netdevs).

If I'm wrong this should still be a separate patch from the rtnl
reorder.
-- 
pw-bot: cr

^ permalink raw reply

* Re: [GIT PULL] io_uring support for get/setsockopt
From: patchwork-bot+netdevbpf @ 2023-11-02  5:01 UTC (permalink / raw)
  To: Jens Axboe; +Cc: torvalds, io-uring, netdev, leitao
In-Reply-To: <7a0893f0-bae8-4aee-9e05-7c81354fc829@kernel.dk>

Hello:

This pull request was applied to netdev/net.git (main)
by Linus Torvalds <torvalds@linux-foundation.org>:

On Mon, 30 Oct 2023 08:36:04 -0600 you wrote:
> Hi Linus,
> 
> On top of the core io_uring changes, this pull request adds support for
> using getsockopt and setsockopt via io_uring. The main use cases for
> this is to enable use of direct descriptors, rather than first
> instantiating a normal file descriptor, doing the option tweaking
> needed, then turning it into a direct descriptor. With this support, we
> can avoid needing a regular file descriptor completely.
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] io_uring support for get/setsockopt
    https://git.kernel.org/netdev/net/c/f5277ad1e976

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* [PATCH net] netlink: fill in missing MODULE_DESCRIPTION()
From: Jakub Kicinski @ 2023-11-02  4:57 UTC (permalink / raw)
  To: davem; +Cc: netdev, edumazet, pabeni, Jakub Kicinski

W=1 builds now warn if a module is built without
a MODULE_DESCRIPTION(). Fill it in for sock_diag.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 net/netlink/diag.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netlink/diag.c b/net/netlink/diag.c
index 9c4f231be275..1eeff9422856 100644
--- a/net/netlink/diag.c
+++ b/net/netlink/diag.c
@@ -257,5 +257,6 @@ static void __exit netlink_diag_exit(void)
 
 module_init(netlink_diag_init);
 module_exit(netlink_diag_exit);
+MODULE_DESCRIPTION("Netlink-based socket monitoring/diagnostic interface (sock_diag)");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 16 /* AF_NETLINK */);
-- 
2.41.0


^ 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