* [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
* 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
* 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: [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 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] 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 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] 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: [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 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 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: [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: [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: [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 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 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] 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-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
* [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
* [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 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 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 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 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
* 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox