* [PATCH v2] drivers/net/ppp: use standard array-copy-function
From: Philipp Stanner @ 2023-11-06 9:16 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Stanislav Fomichev, Greg Kroah-Hartman, Benjamin Tissoires,
Al Viro
Cc: linux-ppp, netdev, linux-kernel, Philipp Stanner, Dave Airlie
In ppp_generic.c, memdup_user() is utilized to copy a userspace array.
This is done without an overflow-check, which is, however, not critical
because the multiplicands are an unsigned short and struct sock_filter,
which is currently of size 8.
Regardless, string.h now provides memdup_array_user(), a wrapper for
copying userspace arrays in a standardized manner, which has the
advantage of making it more obvious to the reader that an array is being
copied.
The wrapper additionally performs an obligatory overflow check, saving
the reader the effort of analyzing the potential for overflow, and
making the code a bit more robust in case of future changes to the
multiplicands len * size.
Replace memdup_user() with memdup_array_user().
Suggested-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
---
Changes in v2:
- Rename the commit and rephrase its message completely so that it
becomes a) obvious that we're not fixing an actual overflow here and
b) emphasize that the goal is increasing readability. (Al Viro)
---
drivers/net/ppp/ppp_generic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index a9beacd552cf..0193af2d31c9 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -570,8 +570,8 @@ static struct bpf_prog *get_filter(struct sock_fprog *uprog)
/* uprog->len is unsigned short, so no overflow here */
fprog.len = uprog->len;
- fprog.filter = memdup_user(uprog->filter,
- uprog->len * sizeof(struct sock_filter));
+ fprog.filter = memdup_array_user(uprog->filter,
+ uprog->len, sizeof(struct sock_filter));
if (IS_ERR(fprog.filter))
return ERR_CAST(fprog.filter);
--
2.41.0
^ permalink raw reply related
* Re: [PATCH net] nfsd: regenerate user space parsers after ynl-gen changes
From: patchwork-bot+netdevbpf @ 2023-11-06 9:10 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, edumazet, pabeni, chuck.lever, lorenzo
In-Reply-To: <20231102185227.2604416-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Thu, 2 Nov 2023 11:52:27 -0700 you wrote:
> Commit 8cea95b0bd79 ("tools: ynl-gen: handle do ops with no input attrs")
> added support for some of the previously-skipped ops in nfsd.
> Regenerate the user space parsers to fill them in.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: chuck.lever@oracle.com
> CC: lorenzo@kernel.org
>
> [...]
Here is the summary with links:
- [net] nfsd: regenerate user space parsers after ynl-gen changes
https://git.kernel.org/netdev/net/c/d93f9528573e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net PATCH] octeontx2-pf: Free pending and dropped SQEs
From: patchwork-bot+netdevbpf @ 2023-11-06 9:00 UTC (permalink / raw)
To: Geetha sowjanya
Cc: netdev, linux-kernel, bpf, kuba, davem, pabeni, edumazet, ast,
daniel, hawk, sgoutham, sbhatta, hkelam
In-Reply-To: <20231031112345.25291-1-gakula@marvell.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Tue, 31 Oct 2023 16:53:45 +0530 you wrote:
> On interface down, the pending SQEs in the NIX get dropped
> or drained out during SMQ flush. But skb's pointed by these
> SQEs never get free or updated to the stack as respective CQE
> never get added.
> This patch fixes the issue by freeing all valid skb's in SQ SG list.
>
> Fixes: b1bc8457e9d0 ("octeontx2-pf: Cleanup all receive buffers in SG descriptor")
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
>
> [...]
Here is the summary with links:
- [net] octeontx2-pf: Free pending and dropped SQEs
https://git.kernel.org/netdev/net/c/3423ca23e08b
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 1/1] net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config
From: patchwork-bot+netdevbpf @ 2023-11-06 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, kuba, edumazet, pabeni, jiri, xiyou.wangcong, daniel,
idosch, netdev
In-Reply-To: <20231028171610.28596-1-jhs@mojatatu.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Sat, 28 Oct 2023 13:16:10 -0400 you wrote:
> Getting the following splat [1] with CONFIG_DEBUG_NET=y and this
> reproducer [2]. Problem seems to be that classifiers clear 'struct
> tcf_result::drop_reason', thereby triggering the warning in
> __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0).
>
> Fixed by disambiguating a legit error from a verdict with a bogus drop_reason
>
> [...]
Here is the summary with links:
- [net,1/1] net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config
https://git.kernel.org/netdev/net/c/40cb2fdfed34
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] tcp: Fix SYN option room calculation for TCP-AO.
From: patchwork-bot+netdevbpf @ 2023-11-06 9:00 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, dsahern, noureddine, 0x7f454c46,
fruggeri, kuni1840, netdev
In-Reply-To: <20231102210548.94361-1-kuniyu@amazon.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Thu, 2 Nov 2023 14:05:48 -0700 you wrote:
> When building SYN packet in tcp_syn_options(), MSS, TS, WS, and
> SACKPERM are used without checking the remaining bytes in the
> options area.
>
> To keep that logic as is, we limit the TCP-AO MAC length in
> tcp_ao_parse_crypto(). Currently, the limit is calculated as below.
>
> [...]
Here is the summary with links:
- [v1,net] tcp: Fix SYN option room calculation for TCP-AO.
https://git.kernel.org/netdev/net/c/0a8e987dcc13
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 v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY
From: Ramón Nordin Rodriguez @ 2023-11-06 8:59 UTC (permalink / raw)
To: Parthiban.Veerasooran
Cc: davem, edumazet, kuba, pabeni, robh+dt, krzysztof.kozlowski+dt,
conor+dt, corbet, Steen.Hegelund, rdunlap, horms, casper.casan,
andrew, netdev, devicetree, linux-kernel, linux-doc,
Horatiu.Vultur, Woojung.Huh, Nicolas.Ferre, UNGLinuxDriver,
Thorsten.Kummermehr
In-Reply-To: <aa175902-560c-4fad-9e0b-aa4efa0482c2@microchip.com>
> I understand that you are using two LAN8650, isn't it? if so are they
> both running simultaneously? or you are doing the testing with one alone?
Currently we've only got one running, hopefully we've wrapped up the
board bring up in the next few days and will be able to run the second
mac/phy as well.
> > With this setup I'm getting a maximum throughput of about 90kB/s.
> > If I increase the chunk size / oa-cps to 64 I get a might higher
> > throughput ~900kB/s, but after 0-2s I get dump below (or similar).
> Did you or possible to try a test case with below configuration?
>
> - Single LAN8650 enabled
> - UDP
> - oa_cps = 64
> - spi-max-frequency = 15000000,
I'll set that up and will get back to you, all testing I have performed
has been with tcp.
>
> Did you run iperf3 test? or any other tool?
> If iperf3 then can you share the configuration you used?
I just tried copying a file over the network with rsync, but I'll run some
udp tests with iperf.
I'll do my best to get back to you with results today.
>
> I don't know whether these may audiences are needed in the CC for this
> thread. Let's see what's Andrew Lunn thinks about it?
No opinions on my end at least.
BR
Ramón
^ permalink raw reply
* Re: [RFC v1 6/8] vdpa: change the map/unmap process to support iommufd
From: Yi Liu @ 2023-11-06 8:54 UTC (permalink / raw)
To: Cindy Lu, jasowang, mst, jgg, linux-kernel, virtualization,
netdev
In-Reply-To: <20231103171641.1703146-7-lulu@redhat.com>
On 2023/11/4 01:16, Cindy Lu wrote:
> Add the check for iommufd_ictx,If vdpa don't have the iommufd_ictx
> then will use the Legacy iommu domain pathway
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
> ---
> drivers/vhost/vdpa.c | 43 ++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index dfaddd833364..0e2dba59e1ce 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -1067,9 +1067,6 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct vhost_iotlb *iotlb,
> /* Legacy iommu domain pathway without IOMMUFD */
> r = iommu_map(v->domain, iova, pa, size,
> perm_to_iommu_flags(perm), GFP_KERNEL);
> - } else {
> - r = iommu_map(v->domain, iova, pa, size,
> - perm_to_iommu_flags(perm), GFP_KERNEL);
> }
> if (r) {
> vhost_iotlb_del_range(iotlb, iova, iova + size - 1);
> @@ -1095,8 +1092,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v,
> if (ops->set_map) {
> if (!v->in_batch)
> ops->set_map(vdpa, asid, iotlb);
> + } else if (!vdpa->iommufd_ictx) {
> + /* Legacy iommu domain pathway without IOMMUFD */
> + iommu_unmap(v->domain, iova, size);
> }
> -
> }
>
> static int vhost_vdpa_va_map(struct vhost_vdpa *v,
> @@ -1149,7 +1148,36 @@ static int vhost_vdpa_va_map(struct vhost_vdpa *v,
>
> return ret;
> }
> +#if 0
> +int vhost_pin_pages(struct vdpa_device *device, dma_addr_t iova, int npage,
> + int prot, struct page **pages)
> +{
> + if (!pages || !npage)
> + return -EINVAL;
> + //if (!device->config->dma_unmap)
> + //return -EINVAL;
> +
> + if (0) { //device->iommufd_access) {
> + int ret;
> +
> + if (iova > ULONG_MAX)
> + return -EINVAL;
>
> + ret = iommufd_access_pin_pages(
> + device->iommufd_access, iova, npage * PAGE_SIZE, pages,
> + (prot & IOMMU_WRITE) ? IOMMUFD_ACCESS_RW_WRITE : 0);
> + if (ret) {
> +
> + return ret;
> + }
> +
> + return npage;
> + } else {
> + return pin_user_pages(iova, npage, prot, pages);
> + }
> + return -EINVAL;
> +}
> +#endif
Is above code needed or not?
> static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
> struct vhost_iotlb *iotlb,
> u64 iova, u64 size, u64 uaddr, u32 perm)
> @@ -1418,9 +1446,13 @@ static void vhost_vdpa_free_domain(struct vhost_vdpa *v)
> struct device *dma_dev = vdpa_get_dma_dev(vdpa);
>
> if (v->domain) {
> - iommu_detach_device(v->domain, dma_dev);
> + if (!vdpa->iommufd_ictx) {
> + iommu_detach_device(v->domain, dma_dev);
> + }
> iommu_domain_free(v->domain);
> }
> + if (vdpa->iommufd_ictx)
> + vdpa_iommufd_unbind(vdpa);
>
> v->domain = NULL;
> }
> @@ -1645,6 +1677,7 @@ static int vhost_vdpa_probe(struct vdpa_device *vdpa)
> }
>
> atomic_set(&v->opened, 0);
> + atomic_set(&vdpa->iommufd_users, 0);
> v->minor = minor;
> v->vdpa = vdpa;
> v->nvqs = vdpa->nvqs;
--
Regards,
Yi Liu
^ permalink raw reply
* Re: [RFC v1 2/8] Kconfig: Add the new file vhost/iommufd
From: Yi Liu @ 2023-11-06 8:53 UTC (permalink / raw)
To: Cindy Lu, jasowang, mst, jgg, linux-kernel, virtualization,
netdev
In-Reply-To: <20231103171641.1703146-3-lulu@redhat.com>
On 2023/11/4 01:16, Cindy Lu wrote:
> Change the makefile and Kconfig, to add the
> new file vhost/iommufd.c
why not merge it with patch 1?
> Signed-off-by: Cindy Lu <lulu@redhat.com>
> ---
> drivers/vhost/Kconfig | 1 +
> drivers/vhost/Makefile | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index b455d9ab6f3d..a4becfb36d77 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -72,6 +72,7 @@ config VHOST_VDPA
> select VHOST
> select IRQ_BYPASS_MANAGER
> depends on VDPA
> + depends on IOMMUFD || !IOMMUFD
> help
> This kernel module can be loaded in host kernel to accelerate
> guest virtio devices with the vDPA-based backends.
> diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> index f3e1897cce85..cda7f6b7f8da 100644
> --- a/drivers/vhost/Makefile
> +++ b/drivers/vhost/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_VHOST_RING) += vringh.o
>
> obj-$(CONFIG_VHOST_VDPA) += vhost_vdpa.o
> vhost_vdpa-y := vdpa.o
> +vhost_vdpa-$(CONFIG_IOMMUFD) += iommufd.o
>
> obj-$(CONFIG_VHOST) += vhost.o
>
--
Regards,
Yi Liu
^ permalink raw reply
* Re: [RFC v1 4/8] vdpa: Add new vdpa_config_ops to support iommufd
From: Yi Liu @ 2023-11-06 8:52 UTC (permalink / raw)
To: Cindy Lu, jasowang, mst, jgg, linux-kernel, virtualization,
netdev
In-Reply-To: <20231103171641.1703146-5-lulu@redhat.com>
On 2023/11/4 01:16, Cindy Lu wrote:
> Add 4 new vdpa_config_ops function to support iommufd
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
> ---
> include/linux/vdpa.h | 38 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 0e652026b776..233d80f9d910 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -5,6 +5,7 @@
> #include <linux/kernel.h>
> #include <linux/device.h>
> #include <linux/interrupt.h>
> +#include <linux/iommufd.h>
> #include <linux/vhost_iotlb.h>
> #include <linux/virtio_net.h>
> #include <linux/if_ether.h>
> @@ -97,6 +98,12 @@ struct vdpa_device {
> struct vdpa_mgmt_dev *mdev;
> unsigned int ngroups;
> unsigned int nas;
> + struct iommufd_access *iommufd_access;
> + struct iommufd_device *iommufd_device;
> + struct iommufd_ctx *iommufd_ictx;
> + unsigned long *vq_bitmap;
> + atomic_t iommufd_users;
> + bool iommufd_attached;
> };
>
> /**
> @@ -332,6 +339,17 @@ struct vdpa_map_file {
> * @vdev: vdpa device
> * @free: Free resources that belongs to vDPA (optional)
> * @vdev: vdpa device
> + * @bind_iommufd: use vdpa_iommufd_physical_bind for an IOMMU
> + * backed device.
> + * otherwise use vdpa_iommufd_emulated_bind
> + * @unbind_iommufd: use vdpa_iommufd_physical_unbind for an IOMMU
> + * backed device.
> + * otherwise, use vdpa_iommufd_emulated_unbind
> + * @attach_ioas: use vdpa_iommufd_physical_attach_ioas for an
> + * IOMMU backed device.
> + * @detach_ioas: Opposite of attach_ioas
> + * @free: Free resources that belongs to vDPA (optional)
> + * @vdev: vdpa device
duplicated kdoc.
> */
> struct vdpa_config_ops {
> /* Virtqueue ops */
> @@ -402,6 +420,13 @@ struct vdpa_config_ops {
>
> /* Free device resources */
> void (*free)(struct vdpa_device *vdev);
> + /* IOMMUFD ops */
> + int (*bind_iommufd)(struct vdpa_device *vdev, struct iommufd_ctx *ictx,
> + u32 *out_device_id);
> + void (*unbind_iommufd)(struct vdpa_device *vdev);
> + int (*attach_ioas)(struct vdpa_device *vdev, u32 *pt_id);
> + int (*detach_ioas)(struct vdpa_device *vdev);
> +
> };
>
> struct vdpa_device *__vdpa_alloc_device(struct device *parent,
> @@ -570,4 +595,15 @@ struct vdpa_mgmt_dev {
> int vdpa_mgmtdev_register(struct vdpa_mgmt_dev *mdev);
> void vdpa_mgmtdev_unregister(struct vdpa_mgmt_dev *mdev);
>
> -#endif /* _LINUX_VDPA_H */
> +int vdpa_iommufd_physical_bind(struct vdpa_device *vdpa,
> + struct iommufd_ctx *ictx, u32 *out_device_id);
> +void vdpa_iommufd_physical_unbind(struct vdpa_device *vdpa);
> +int vdpa_iommufd_physical_attach_ioas(struct vdpa_device *vdpa, u32 *pt_id);
> +int vdpa_iommufd_physical_detach_ioas(struct vdpa_device *vdpa);
> +int vdpa_iommufd_emulated_bind(struct vdpa_device *vdpa,
> + struct iommufd_ctx *ictx, u32 *out_device_id);
> +void vdpa_iommufd_emulated_unbind(struct vdpa_device *vdpa);
> +int vdpa_iommufd_emulated_attach_ioas(struct vdpa_device *vdpa, u32 *pt_id);
> +int vdpa_iommufd_emulated_detach_ioas(struct vdpa_device *vdpa);
> +
> +#endif
--
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH net v2] virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()
From: Stefano Garzarella @ 2023-11-06 8:42 UTC (permalink / raw)
To: Shigeru Yoshida
Cc: stefanha, davem, edumazet, kuba, pabeni, kvm, virtualization,
netdev, linux-kernel, syzbot+0c8ce1da0ac31abbadcd
In-Reply-To: <20231104150531.257952-1-syoshida@redhat.com>
On Sun, Nov 05, 2023 at 12:05:31AM +0900, Shigeru Yoshida wrote:
>KMSAN reported the following uninit-value access issue:
>
>=====================================================
>BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421
> virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421
> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
> process_one_work kernel/workqueue.c:2630 [inline]
> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
> kthread+0x3cc/0x520 kernel/kthread.c:388
> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>
>Uninit was stored to memory at:
> virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline]
> virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415
> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
> process_one_work kernel/workqueue.c:2630 [inline]
> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
> kthread+0x3cc/0x520 kernel/kthread.c:388
> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>
>Uninit was created at:
> slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767
> slab_alloc_node mm/slub.c:3478 [inline]
> kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523
> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559
> __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650
> alloc_skb include/linux/skbuff.h:1286 [inline]
> virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline]
> virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58
> virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline]
> virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387
> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
> process_one_work kernel/workqueue.c:2630 [inline]
> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
> kthread+0x3cc/0x520 kernel/kthread.c:388
> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>
>CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3
>Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
>Workqueue: vsock-loopback vsock_loopback_work
>=====================================================
>
>The following simple reproducer can cause the issue described above:
>
>int main(void)
>{
> int sock;
> struct sockaddr_vm addr = {
> .svm_family = AF_VSOCK,
> .svm_cid = VMADDR_CID_ANY,
> .svm_port = 1234,
> };
>
> sock = socket(AF_VSOCK, SOCK_STREAM, 0);
> connect(sock, (struct sockaddr *)&addr, sizeof(addr));
> return 0;
>}
>
>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_init_hdr()`. This patch resolves the issue by
>initializing these fields during allocation.
>
>Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
>Reported-and-tested-by: syzbot+0c8ce1da0ac31abbadcd@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=0c8ce1da0ac31abbadcd
>Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
>---
>v1->v2:
>- Rebase on the latest net tree
>https://lore.kernel.org/all/20231026150154.3536433-1-syoshida@redhat.com/
>---
> net/vmw_vsock/virtio_transport_common.c | 2 ++
> 1 file changed, 2 insertions(+)
The patch remained the same, so you could bring back my R-b ;-)
In any case:
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Thanks,
Stefano
>
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index e22c81435ef7..dc65dd4d26df 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -130,6 +130,8 @@ static void virtio_transport_init_hdr(struct sk_buff *skb,
> hdr->dst_port = cpu_to_le32(dst_port);
> hdr->flags = cpu_to_le32(info->flags);
> hdr->len = cpu_to_le32(payload_len);
>+ hdr->buf_alloc = cpu_to_le32(0);
>+ hdr->fwd_cnt = cpu_to_le32(0);
> }
>
> static void virtio_transport_copy_nonlinear_skb(const struct sk_buff *skb,
>--
>2.41.0
>
^ permalink raw reply
* Re: [PATCH net-next 9/9] mptcp: refactor sndbuf auto-tuning
From: Eric Dumazet @ 2023-11-06 8:18 UTC (permalink / raw)
To: Paolo Abeni
Cc: Mat Martineau, Matthieu Baerts, David S. Miller, Jakub Kicinski,
netdev, mptcp
In-Reply-To: <1831224a48dfbf54fb45fa56fce826d1d312700f.camel@redhat.com>
On Mon, Nov 6, 2023 at 8:22 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hi,
>
> On Thu, 2023-11-02 at 18:19 +0100, Eric Dumazet wrote:
> > On Mon, Oct 23, 2023 at 10:45 PM Mat Martineau <martineau@kernel.org> wrote:
> > >
> > > From: Paolo Abeni <pabeni@redhat.com>
> > >
> > > The MPTCP protocol account for the data enqueued on all the subflows
> > > to the main socket send buffer, while the send buffer auto-tuning
> > > algorithm set the main socket send buffer size as the max size among
> > > the subflows.
> > >
> > > That causes bad performances when at least one subflow is sndbuf
> > > limited, e.g. due to very high latency, as the MPTCP scheduler can't
> > > even fill such buffer.
> > >
> > > Change the send-buffer auto-tuning algorithm to compute the main socket
> > > send buffer size as the sum of all the subflows buffer size.
> > >
> > > Reviewed-by: Mat Martineau <martineau@kernel.org>
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > Signed-off-by: Mat Martineau <martineau@kernel.org
> >
> > ...
> >
> > > diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> > > index df208666fd19..2b43577f952e 100644
> > > --- a/net/mptcp/subflow.c
> > > +++ b/net/mptcp/subflow.c
> > > @@ -421,6 +421,7 @@ static bool subflow_use_different_dport(struct mptcp_sock *msk, const struct soc
> > >
> > > void __mptcp_set_connected(struct sock *sk)
> > > {
> > > + __mptcp_propagate_sndbuf(sk, mptcp_sk(sk)->first);
> >
> > ->first can be NULL here, according to syzbot.
>
> I'm sorry for the latency on my side, I had a different kind of crash
> to handle here.
>
> Do you have a syzkaller report available? Or the call trace landing
> here?
Sure, let me release the report.
^ permalink raw reply
* [PATCH net] virtio_net: fix missing dma unmap for resize
From: Xuan Zhuo @ 2023-11-06 8:18 UTC (permalink / raw)
To: netdev
Cc: Michael S. Tsirkin, Jason Wang, Xuan Zhuo, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, virtualization
For rq, we have three cases getting buffers from virtio core:
1. virtqueue_get_buf{,_ctx}
2. virtqueue_detach_unused_buf
3. callback for virtqueue_resize
But in commit 295525e29a5b("virtio_net: merge dma operations when
filling mergeable buffers"), I missed the dma unmap for the #3 case.
That will leak some memory, because I did not release the pages referred
by the unused buffers.
If we do such script, we will make the system OOM.
while true
do
ethtool -G ens4 rx 128
ethtool -G ens4 rx 256
free -m
done
Fixes: 295525e29a5b ("virtio_net: merge dma operations when filling mergeable buffers")
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
---
drivers/net/virtio_net.c | 43 ++++++++++++++++++++--------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d16f592c2061..6423a3a007ce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -408,6 +408,17 @@ static struct page *get_a_page(struct receive_queue *rq, gfp_t gfp_mask)
return p;
}
+static void virtnet_rq_free_buf(struct virtnet_info *vi,
+ struct receive_queue *rq, void *buf)
+{
+ if (vi->mergeable_rx_bufs)
+ put_page(virt_to_head_page(buf));
+ else if (vi->big_packets)
+ give_pages(rq, buf);
+ else
+ put_page(virt_to_head_page(buf));
+}
+
static void enable_delayed_refill(struct virtnet_info *vi)
{
spin_lock_bh(&vi->refill_lock);
@@ -634,17 +645,6 @@ static void *virtnet_rq_get_buf(struct receive_queue *rq, u32 *len, void **ctx)
return buf;
}
-static void *virtnet_rq_detach_unused_buf(struct receive_queue *rq)
-{
- void *buf;
-
- buf = virtqueue_detach_unused_buf(rq->vq);
- if (buf && rq->do_dma)
- virtnet_rq_unmap(rq, buf, 0);
-
- return buf;
-}
-
static void virtnet_rq_init_one_sg(struct receive_queue *rq, void *buf, u32 len)
{
struct virtnet_rq_dma *dma;
@@ -1764,7 +1764,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
pr_debug("%s: short packet %i\n", dev->name, len);
DEV_STATS_INC(dev, rx_length_errors);
- virtnet_rq_free_unused_buf(rq->vq, buf);
+ virtnet_rq_free_buf(vi, rq, buf);
return;
}
@@ -4034,14 +4034,15 @@ static void virtnet_sq_free_unused_buf(struct virtqueue *vq, void *buf)
static void virtnet_rq_free_unused_buf(struct virtqueue *vq, void *buf)
{
struct virtnet_info *vi = vq->vdev->priv;
+ struct receive_queue *rq;
int i = vq2rxq(vq);
- if (vi->mergeable_rx_bufs)
- put_page(virt_to_head_page(buf));
- else if (vi->big_packets)
- give_pages(&vi->rq[i], buf);
- else
- put_page(virt_to_head_page(buf));
+ rq = &vi->rq[i];
+
+ if (rq->do_dma)
+ virtnet_rq_unmap(rq, buf, 0);
+
+ virtnet_rq_free_buf(vi, rq, buf);
}
static void free_unused_bufs(struct virtnet_info *vi)
@@ -4057,10 +4058,10 @@ static void free_unused_bufs(struct virtnet_info *vi)
}
for (i = 0; i < vi->max_queue_pairs; i++) {
- struct receive_queue *rq = &vi->rq[i];
+ struct virtqueue *vq = vi->rq[i].vq;
- while ((buf = virtnet_rq_detach_unused_buf(rq)) != NULL)
- virtnet_rq_free_unused_buf(rq->vq, buf);
+ while ((buf = virtqueue_detach_unused_buf(vq)) != NULL)
+ virtnet_rq_free_unused_buf(vq, buf);
cond_resched();
}
}
--
2.32.0.3.g01195cf9f
^ permalink raw reply related
* Re: [RFC v1 0/8] vhost-vdpa: add support for iommufd
From: Yi Liu @ 2023-11-06 8:05 UTC (permalink / raw)
To: Jason Wang, Cindy Lu; +Cc: mst, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <CACGkMEvaKw9g0EmNdFh3=iZm3rD-mo_BtaBA3F5bwqNq4NV3Dw@mail.gmail.com>
On 2023/11/6 12:11, Jason Wang wrote:
> On Sat, Nov 4, 2023 at 1:16 AM Cindy Lu <lulu@redhat.com> wrote:
>>
>>
>> Hi All
>> This code provides the iommufd support for vdpa device
>> This code fixes the bugs from the last version and also add the asid support. rebase on kernel
>> v6,6-rc3
>> Test passed in the physical device (vp_vdpa), but there are still some problems in the emulated device (vdpa_sim_net),
>> I will continue working on it
>>
>> The kernel code is
>> https://gitlab.com/lulu6/vhost/-/tree/iommufdRFC_v1
>>
>> Signed-off-by: Cindy Lu <lulu@redhat.com>
>
> It would be better to have a change summary here.
yeah, the version number is also incorrect.
> Thanks
>
>>
>>
>> Cindy Lu (8):
>> vhost/iommufd: Add the functions support iommufd
>> Kconfig: Add the new file vhost/iommufd
>> vhost: Add 3 new uapi to support iommufd
>> vdpa: Add new vdpa_config_ops to support iommufd
>> vdpa_sim :Add support for iommufd
>> vdpa: change the map/unmap process to support iommufd
>> vp_vdpa::Add support for iommufd
>> iommu: expose the function iommu_device_use_default_domain
>>
>> drivers/iommu/iommu.c | 2 +
>> drivers/vdpa/vdpa_sim/vdpa_sim.c | 8 ++
>> drivers/vdpa/virtio_pci/vp_vdpa.c | 4 +
>> drivers/vhost/Kconfig | 1 +
>> drivers/vhost/Makefile | 1 +
>> drivers/vhost/iommufd.c | 178 +++++++++++++++++++++++++
>> drivers/vhost/vdpa.c | 210 +++++++++++++++++++++++++++++-
>> drivers/vhost/vhost.h | 21 +++
>> include/linux/vdpa.h | 38 +++++-
>> include/uapi/linux/vhost.h | 66 ++++++++++
>> 10 files changed, 525 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/vhost/iommufd.c
>>
>> --
>> 2.34.3
>>
>
--
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH net] tcp: Fix -Wc23-extensions in tcp_options_write()
From: Christoph Hellwig @ 2023-11-06 7:49 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Christoph Hellwig, edumazet, davem, dsahern, kuba, pabeni,
ndesaulniers, trix, 0x7f454c46, fruggeri, noureddine, netdev,
linux-kernel, llvm, patches
In-Reply-To: <20231103165312.GA3670349@dev-arch.thelio-3990X>
Normally the kernel keeps the ifdef outside the function body and adds
a stub. But this already looks like a huge imrpovement over the
existing version to me.
^ permalink raw reply
* Re: [RFC v1 3/8] vhost: Add 3 new uapi to support iommufd
From: Jason Wang @ 2023-11-06 7:30 UTC (permalink / raw)
To: Cindy Lu; +Cc: mst, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <20231103171641.1703146-4-lulu@redhat.com>
On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu <lulu@redhat.com> wrote:
>
> VHOST_VDPA_SET_IOMMU_FD: bind the device to iommufd device
>
> VDPA_DEVICE_ATTACH_IOMMUFD_AS: Attach a vdpa device to an iommufd
> address space specified by IOAS id.
>
> VDPA_DEVICE_DETACH_IOMMUFD_AS: Detach a vdpa device
> from the iommufd address space
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
> ---
[...]
> diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
> index f5c48b61ab62..07e1b2c443ca 100644
> --- a/include/uapi/linux/vhost.h
> +++ b/include/uapi/linux/vhost.h
> @@ -219,4 +219,70 @@
> */
> #define VHOST_VDPA_RESUME _IO(VHOST_VIRTIO, 0x7E)
>
> +/* vhost_vdpa_set_iommufd
> + * Input parameters:
> + * @iommufd: file descriptor from /dev/iommu; pass -1 to unset
> + * @iommufd_ioasid: IOAS identifier returned from ioctl(IOMMU_IOAS_ALLOC)
> + * Output parameters:
> + * @out_dev_id: device identifier
> + */
> +struct vhost_vdpa_set_iommufd {
> + __s32 iommufd;
> + __u32 iommufd_ioasid;
> + __u32 out_dev_id;
> +};
> +
> +#define VHOST_VDPA_SET_IOMMU_FD \
> + _IOW(VHOST_VIRTIO, 0x7F, struct vhost_vdpa_set_iommufd)
> +
> +/*
> + * VDPA_DEVICE_ATTACH_IOMMUFD_AS -
> + * _IOW(VHOST_VIRTIO, 0x7f, struct vdpa_device_attach_iommufd_as)
> + *
> + * Attach a vdpa device to an iommufd address space specified by IOAS
> + * id.
> + *
> + * Available only after a device has been bound to iommufd via
> + * VHOST_VDPA_SET_IOMMU_FD
> + *
> + * Undo by VDPA_DEVICE_DETACH_IOMMUFD_AS or device fd close.
> + *
> + * @argsz: user filled size of this data.
> + * @flags: must be 0.
> + * @ioas_id: Input the target id which can represent an ioas
> + * allocated via iommufd subsystem.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +struct vdpa_device_attach_iommufd_as {
> + __u32 argsz;
> + __u32 flags;
> + __u32 ioas_id;
> +};
I think we need to map ioas to vDPA AS, so there should be an ASID
from the view of vDPA?
Thanks
> +
> +#define VDPA_DEVICE_ATTACH_IOMMUFD_AS \
> + _IOW(VHOST_VIRTIO, 0x82, struct vdpa_device_attach_iommufd_as)
> +
> +/*
> + * VDPA_DEVICE_DETACH_IOMMUFD_AS
> + *
> + * Detach a vdpa device from the iommufd address space it has been
> + * attached to. After it, device should be in a blocking DMA state.
> + *
> + * Available only after a device has been bound to iommufd via
> + * VHOST_VDPA_SET_IOMMU_FD
> + *
> + * @argsz: user filled size of this data.
> + * @flags: must be 0.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +struct vdpa_device_detach_iommufd_as {
> + __u32 argsz;
> + __u32 flags;
> +};
> +
> +#define VDPA_DEVICE_DETACH_IOMMUFD_AS \
> + _IOW(VHOST_VIRTIO, 0x83, struct vdpa_device_detach_iommufd_as)
> +
> #endif
> --
> 2.34.3
>
^ permalink raw reply
* Re: [RFC v1 3/8] vhost: Add 3 new uapi to support iommufd
From: Jason Wang @ 2023-11-06 7:27 UTC (permalink / raw)
To: Cindy Lu; +Cc: mst, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <20231103171641.1703146-4-lulu@redhat.com>
On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu <lulu@redhat.com> wrote:
>
> VHOST_VDPA_SET_IOMMU_FD: bind the device to iommufd device
>
> VDPA_DEVICE_ATTACH_IOMMUFD_AS: Attach a vdpa device to an iommufd
> address space specified by IOAS id.
>
> VDPA_DEVICE_DETACH_IOMMUFD_AS: Detach a vdpa device
> from the iommufd address space
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
As discussed in the previous version, any reason/advantages of this
compared to just having a single VDPA_DEVICE_ATTACH_IOMMUFD_AS?
Thanks
^ permalink raw reply
* Re: [RFC v1 8/8] iommu: expose the function iommu_device_use_default_domain
From: Jason Wang @ 2023-11-06 7:26 UTC (permalink / raw)
To: Cindy Lu; +Cc: mst, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <20231103171641.1703146-9-lulu@redhat.com>
On Sat, Nov 4, 2023 at 1:18 AM Cindy Lu <lulu@redhat.com> wrote:
>
> Expose the function iommu_device_use_default_domain() and
> iommu_device_unuse_default_domain()，
> While vdpa bind the iommufd device and detach the iommu device,
> vdpa need to call the function
> iommu_device_unuse_default_domain() to release the owner
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
This is the end of the series, who is the user then?
Thanks
> ---
> drivers/iommu/iommu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 3bfc56df4f78..987cbf8c9a87 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -3164,6 +3164,7 @@ int iommu_device_use_default_domain(struct device *dev)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(iommu_device_use_default_domain);
>
> /**
> * iommu_device_unuse_default_domain() - Device driver stops handling device
> @@ -3187,6 +3188,7 @@ void iommu_device_unuse_default_domain(struct device *dev)
> mutex_unlock(&group->mutex);
> iommu_group_put(group);
> }
> +EXPORT_SYMBOL_GPL(iommu_device_unuse_default_domain);
>
> static int __iommu_group_alloc_blocking_domain(struct iommu_group *group)
> {
> --
> 2.34.3
>
^ permalink raw reply
* Re: [RFC v1 7/8] vp_vdpa::Add support for iommufd
From: Jason Wang @ 2023-11-06 7:25 UTC (permalink / raw)
To: Cindy Lu; +Cc: mst, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <20231103171641.1703146-8-lulu@redhat.com>
On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu <lulu@redhat.com> wrote:
>
> Add new vdpa_config_ops function to support iommufd
>
> Signed-off-by: Cindy Lu <lulu@redhat.com>
> ---
> drivers/vdpa/virtio_pci/vp_vdpa.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c b/drivers/vdpa/virtio_pci/vp_vdpa.c
> index 281287fae89f..dd2c372d36a6 100644
> --- a/drivers/vdpa/virtio_pci/vp_vdpa.c
> +++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
> @@ -460,6 +460,10 @@ static const struct vdpa_config_ops vp_vdpa_ops = {
> .set_config = vp_vdpa_set_config,
> .set_config_cb = vp_vdpa_set_config_cb,
> .get_vq_irq = vp_vdpa_get_vq_irq,
> + .bind_iommufd = vdpa_iommufd_physical_bind,
> + .unbind_iommufd = vdpa_iommufd_physical_unbind,
> + .attach_ioas = vdpa_iommufd_physical_attach_ioas,
> + .detach_ioas = vdpa_iommufd_physical_detach_ioas,
For the device that depends on the platform IOMMU, any reason we still
bother a per device config ops here just as an indirection?
Thanks
> };
>
> static void vp_vdpa_free_irq_vectors(void *data)
> --
> 2.34.3
>
^ permalink raw reply
* Re: [PATCH net-next 9/9] mptcp: refactor sndbuf auto-tuning
From: Paolo Abeni @ 2023-11-06 7:21 UTC (permalink / raw)
To: Eric Dumazet, Mat Martineau
Cc: Matthieu Baerts, David S. Miller, Jakub Kicinski, netdev, mptcp
In-Reply-To: <CANn89iLZUA6S2a=K8GObnS62KK6Jt4B7PsAs7meMFooM8xaTgw@mail.gmail.com>
Hi,
On Thu, 2023-11-02 at 18:19 +0100, Eric Dumazet wrote:
> On Mon, Oct 23, 2023 at 10:45 PM Mat Martineau <martineau@kernel.org> wrote:
> >
> > From: Paolo Abeni <pabeni@redhat.com>
> >
> > The MPTCP protocol account for the data enqueued on all the subflows
> > to the main socket send buffer, while the send buffer auto-tuning
> > algorithm set the main socket send buffer size as the max size among
> > the subflows.
> >
> > That causes bad performances when at least one subflow is sndbuf
> > limited, e.g. due to very high latency, as the MPTCP scheduler can't
> > even fill such buffer.
> >
> > Change the send-buffer auto-tuning algorithm to compute the main socket
> > send buffer size as the sum of all the subflows buffer size.
> >
> > Reviewed-by: Mat Martineau <martineau@kernel.org>
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > Signed-off-by: Mat Martineau <martineau@kernel.org
>
> ...
>
> > diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> > index df208666fd19..2b43577f952e 100644
> > --- a/net/mptcp/subflow.c
> > +++ b/net/mptcp/subflow.c
> > @@ -421,6 +421,7 @@ static bool subflow_use_different_dport(struct mptcp_sock *msk, const struct soc
> >
> > void __mptcp_set_connected(struct sock *sk)
> > {
> > + __mptcp_propagate_sndbuf(sk, mptcp_sk(sk)->first);
>
> ->first can be NULL here, according to syzbot.
I'm sorry for the latency on my side, I had a different kind of crash
to handle here.
Do you have a syzkaller report available? Or the call trace landing
here?
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH iwl-net] ice: fix DDP package download for packages without signature segment
From: Maciej Fijalkowski @ 2023-11-06 7:13 UTC (permalink / raw)
To: Paul Greenwalt
Cc: intel-wired-lan, netdev, jesse.brandeburg, anthony.l.nguyen,
davem, kuba, horms, tony.brelinski, Dan Nowlin
In-Reply-To: <20231104182908.15389-1-paul.greenwalt@intel.com>
On Sat, Nov 04, 2023 at 02:29:08PM -0400, Paul Greenwalt wrote:
> From: Dan Nowlin <dan.nowlin@intel.com>
>
> Commit 3cbdb0343022 ("ice: Add support for E830 DDP package segment")
> incorrectly removed support for package download for packages without a
> signature segment. These packages include the signature buffer inline
> in the configurations buffers, and do not in a signature segment.
>
> Fix package download by providing download support for both packages
> with (ice_download_pkg_with_sig_seg()) and without signature segment
> (ice_download_pkg_without_sig_seg()).
>
> Fixes: 3cbdb0343022 ("ice: Add support for E830 DDP package segment")
> Reported-by: Fijalkowski, Maciej <maciej.fijalkowski@intel.com>
s/Fijalkowski, Maciej/Maciej Fijalkowski
> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
Tested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Thanks a lot for the quick fix!
> ---
> drivers/net/ethernet/intel/ice/ice_ddp.c | 106 ++++++++++++++++++++++-
> 1 file changed, 103 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c b/drivers/net/ethernet/intel/ice/ice_ddp.c
> index cfb1580f5850..3f1a11d0252c 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ddp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
> @@ -1479,14 +1479,14 @@ ice_post_dwnld_pkg_actions(struct ice_hw *hw)
> }
>
> /**
> - * ice_download_pkg
> + * ice_download_pkg_with_sig_seg
> * @hw: pointer to the hardware structure
> * @pkg_hdr: pointer to package header
> *
> * Handles the download of a complete package.
> */
> static enum ice_ddp_state
> -ice_download_pkg(struct ice_hw *hw, struct ice_pkg_hdr *pkg_hdr)
> +ice_download_pkg_with_sig_seg(struct ice_hw *hw, struct ice_pkg_hdr *pkg_hdr)
> {
> enum ice_aq_err aq_err = hw->adminq.sq_last_status;
> enum ice_ddp_state state = ICE_DDP_PKG_ERR;
> @@ -1519,6 +1519,106 @@ ice_download_pkg(struct ice_hw *hw, struct ice_pkg_hdr *pkg_hdr)
> state = ice_post_dwnld_pkg_actions(hw);
>
> ice_release_global_cfg_lock(hw);
> +
> + return state;
> +}
> +
> +/**
> + * ice_dwnld_cfg_bufs
> + * @hw: pointer to the hardware structure
> + * @bufs: pointer to an array of buffers
> + * @count: the number of buffers in the array
> + *
> + * Obtains global config lock and downloads the package configuration buffers
> + * to the firmware.
> + */
> +static enum ice_ddp_state
> +ice_dwnld_cfg_bufs(struct ice_hw *hw, struct ice_buf *bufs, u32 count)
> +{
> + enum ice_ddp_state state = ICE_DDP_PKG_SUCCESS;
> + struct ice_buf_hdr *bh;
> + int status;
> +
> + if (!bufs || !count)
> + return ICE_DDP_PKG_ERR;
> +
> + /* If the first buffer's first section has its metadata bit set
> + * then there are no buffers to be downloaded, and the operation is
> + * considered a success.
> + */
> + bh = (struct ice_buf_hdr *)bufs;
> + if (le32_to_cpu(bh->section_entry[0].type) & ICE_METADATA_BUF)
> + return ICE_DDP_PKG_SUCCESS;
> +
> + status = ice_acquire_global_cfg_lock(hw, ICE_RES_WRITE);
> + if (status) {
> + if (status == -EALREADY)
> + return ICE_DDP_PKG_ALREADY_LOADED;
> + return ice_map_aq_err_to_ddp_state(hw->adminq.sq_last_status);
> + }
> +
> + state = ice_dwnld_cfg_bufs_no_lock(hw, bufs, 0, count, true);
> + if (!state)
> + state = ice_post_dwnld_pkg_actions(hw);
> +
> + ice_release_global_cfg_lock(hw);
> +
> + return state;
> +}
> +
> +/**
> + * ice_download_pkg_without_sig_seg
> + * @hw: pointer to the hardware structure
> + * @ice_seg: pointer to the segment of the package to be downloaded
> + *
> + * Handles the download of a complete package without signature segment.
> + */
> +static enum ice_ddp_state
> +ice_download_pkg_without_sig_seg(struct ice_hw *hw, struct ice_seg *ice_seg)
> +{
> + struct ice_buf_table *ice_buf_tbl;
> + enum ice_ddp_state state;
> +
> + ice_debug(hw, ICE_DBG_PKG, "Segment format version: %d.%d.%d.%d\n",
> + ice_seg->hdr.seg_format_ver.major,
> + ice_seg->hdr.seg_format_ver.minor,
> + ice_seg->hdr.seg_format_ver.update,
> + ice_seg->hdr.seg_format_ver.draft);
> +
> + ice_debug(hw, ICE_DBG_PKG, "Seg: type 0x%X, size %d, name %s\n",
> + le32_to_cpu(ice_seg->hdr.seg_type),
> + le32_to_cpu(ice_seg->hdr.seg_size), ice_seg->hdr.seg_id);
> +
> + ice_buf_tbl = ice_find_buf_table(ice_seg);
> +
> + ice_debug(hw, ICE_DBG_PKG, "Seg buf count: %d\n",
> + le32_to_cpu(ice_buf_tbl->buf_count));
> +
> + state = ice_dwnld_cfg_bufs(hw, ice_buf_tbl->buf_array,
> + le32_to_cpu(ice_buf_tbl->buf_count));
> +
> + return state;
> +}
> +
> +/**
> + * ice_download_pkg
> + * @hw: pointer to the hardware structure
> + * @pkg_hdr: pointer to package header
> + * @ice_seg: pointer to the segment of the package to be downloaded
> + *
> + * Handles the download of a complete package.
> + */
> +static enum ice_ddp_state
> +ice_download_pkg(struct ice_hw *hw, struct ice_pkg_hdr *pkg_hdr,
> + struct ice_seg *ice_seg)
> +{
> + enum ice_ddp_state state;
> +
> + if (hw->pkg_has_signing_seg)
> + state = ice_download_pkg_with_sig_seg(hw, pkg_hdr);
> + else
> + state = ice_download_pkg_without_sig_seg(hw, ice_seg);
> +
> ice_post_pkg_dwnld_vlan_mode_cfg(hw);
>
> return state;
> @@ -2083,7 +2183,7 @@ enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8 *buf, u32 len)
>
> /* initialize package hints and then download package */
> ice_init_pkg_hints(hw, seg);
> - state = ice_download_pkg(hw, pkg);
> + state = ice_download_pkg(hw, pkg, seg);
> if (state == ICE_DDP_PKG_ALREADY_LOADED) {
> ice_debug(hw, ICE_DBG_INIT,
> "package previously loaded - no work.\n");
>
> base-commit: 016b9332a3346e97a6cacffea0f9dc10e1235a75
> --
> 2.41.0
>
^ permalink raw reply
* Re: [PATCH] staging: Revert "staging: qlge: Retire the driver"
From: Greg Kroah-Hartman @ 2023-11-06 6:54 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Kira, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Manish Chopra, GR-Linux-NIC-Dev, Coiby Xu,
James E.J. Bottomley, Helge Deller, Sven Joachim, Ian Kent,
netdev, linux-doc, linux-kernel, linux-parisc, linux-staging
In-Reply-To: <20231030150400.74178-1-benjamin.poirier@gmail.com>
On Tue, Oct 31, 2023 at 02:04:00AM +1100, Benjamin Poirier wrote:
> This reverts commit 875be090928d19ff4ae7cbaadb54707abb3befdf.
>
> On All Hallows' Eve, fear and cower for it is the return of the undead
> driver.
>
> There was a report [1] from a user of a QLE8142 device. They would like for
> the driver to remain in the kernel. Therefore, revert the removal of the
> qlge driver.
>
> [1] https://lore.kernel.org/netdev/566c0155-4f80-43ec-be2c-2d1ad631bf25@gmail.com/
<snip>
> --- /dev/null
> +++ b/drivers/staging/qlge/TODO
> @@ -0,0 +1,28 @@
> +* commit 7c734359d350 ("qlge: Size RX buffers based on MTU.", v2.6.33-rc1)
> + introduced dead code in the receive routines, which should be rewritten
> + anyways by the admission of the author himself, see the comment above
> + qlge_build_rx_skb(). That function is now used exclusively to handle packets
> + that underwent header splitting but it still contains code to handle non
> + split cases.
> +* truesize accounting is incorrect (ex: a 9000B frame has skb->truesize 10280
> + while containing two frags of order-1 allocations, ie. >16K)
> +* while in that area, using two 8k buffers to store one 9k frame is a poor
> + choice of buffer size.
> +* in the "chain of large buffers" case, the driver uses an skb allocated with
> + head room but only puts data in the frags.
> +* rename "rx" queues to "completion" queues. Calling tx completion queues "rx
> + queues" is confusing.
> +* struct rx_ring is used for rx and tx completions, with some members relevant
> + to one case only
> +* the flow control implementation in firmware is buggy (sends a flood of pause
> + frames, resets the link, device and driver buffer queues become
> + desynchronized), disable it by default
> +* the driver has a habit of using runtime checks where compile time checks are
> + possible (ex. qlge_free_rx_buffers())
> +* reorder struct members to avoid holes if it doesn't impact performance
> +* use better-suited apis (ex. use pci_iomap() instead of ioremap())
> +* remove duplicate and useless comments
> +* fix weird line wrapping (all over, ex. the qlge_set_routing_reg() calls in
> + qlge_set_multicast_list()).
> +* remove useless casts (ex. memset((void *)mac_iocb_ptr, ...))
> +* fix checkpatch issues
In looking at this again, are you sure you all want this in the tree?
I'm glad to take the revert but ONLY if you are willing to then take a
"move this to drivers/net/" patch for the code as well, WITH an actual
maintainer and developer who is willing to do the work for this code.
In all the years that this has been in the staging tree, the listed
maintainers have not been active at all from what I can remember, and
obviously the above list of "things to fix" have not really been worked
on at all.
So why should it be added back? I understand there is at least one
reported user, but for drivers in the staging tree, that's not a good
reason to keep them around if there is not an actual maintainer that is
willing to do the work.
Which reminds me, we should probably sweep the drivers/staging/ tree
again to see what we can remove given a lack of real development.
Normally we do that every other year or so, and this driver would fall
into the "no one is doing anything with it" category and should be
dropped.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH iwl-net] ice: fix DDP package download for packages without signature segment
From: Jacob Keller @ 2023-11-06 5:39 UTC (permalink / raw)
To: Paul Greenwalt, intel-wired-lan
Cc: netdev, jesse.brandeburg, anthony.l.nguyen, davem, kuba, horms,
tony.brelinski, Dan Nowlin, Fijalkowski, Maciej
In-Reply-To: <20231104182908.15389-1-paul.greenwalt@intel.com>
On 11/4/2023 11:29 AM, Paul Greenwalt wrote:
> From: Dan Nowlin <dan.nowlin@intel.com>
>
> Commit 3cbdb0343022 ("ice: Add support for E830 DDP package segment")
> incorrectly removed support for package download for packages without a
> signature segment. These packages include the signature buffer inline
> in the configurations buffers, and do not in a signature segment.
>
> Fix package download by providing download support for both packages
> with (ice_download_pkg_with_sig_seg()) and without signature segment
> (ice_download_pkg_without_sig_seg()).
>
> Fixes: 3cbdb0343022 ("ice: Add support for E830 DDP package segment")
> Reported-by: Fijalkowski, Maciej <maciej.fijalkowski@intel.com>
> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* Re: [PATCH net-next v2 4/5] virtio-net: support rx netdim
From: kernel test robot @ 2023-11-06 5:13 UTC (permalink / raw)
To: Heng Qi, netdev, virtualization
Cc: llvm, oe-kbuild-all, Jason Wang, Michael S. Tsirkin, Eric Dumazet,
Paolo Abeni, Jesper Dangaard Brouer, John Fastabend,
Alexei Starovoitov, Simon Horman, Jakub Kicinski, Liu, Yujie
In-Reply-To: <12c77098b73313eea8fdc88a3d1d20611444827d.1698929590.git.hengqi@linux.alibaba.com>
Hi Heng,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Heng-Qi/virtio-net-returns-whether-napi-is-complete/20231103-040818
base: net-next/main
patch link: https://lore.kernel.org/r/12c77098b73313eea8fdc88a3d1d20611444827d.1698929590.git.hengqi%40linux.alibaba.com
patch subject: [PATCH net-next v2 4/5] virtio-net: support rx netdim
config: arm-vexpress_defconfig (https://download.01.org/0day-ci/archive/20231106/202311061237.I4bMaa06-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231106/202311061237.I4bMaa06-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311061237.I4bMaa06-lkp@intel.com/
All errors (new ones prefixed by >>):
>> ld.lld: error: undefined symbol: net_dim_get_rx_moderation
>>> referenced by virtio_net.c:3529 (drivers/net/virtio_net.c:3529)
>>> drivers/net/virtio_net.o:(virtnet_rx_dim_work) in archive vmlinux.a
--
>> ld.lld: error: undefined symbol: net_dim
>>> referenced by virtio_net.c:2176 (drivers/net/virtio_net.c:2176)
>>> drivers/net/virtio_net.o:(virtnet_poll) in archive vmlinux.a
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v9 17/17] bpf,selinux: allocate bpf_security_struct per BPF token
From: Paul Moore @ 2023-11-06 5:01 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, brauner
Cc: linux-fsdevel, linux-security-module, keescook, kernel-team,
sargun
In-Reply-To: <20231103190523.6353-18-andrii@kernel.org>
On Nov 3, 2023 Andrii Nakryiko <andrii@kernel.org> wrote:
>
> Utilize newly added bpf_token_create/bpf_token_free LSM hooks to
> allocate struct bpf_security_struct for each BPF token object in
> SELinux. This just follows similar pattern for BPF prog and map.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
> security/selinux/hooks.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
Thanks Andrii, we'll need some additional code to fully enable the
BPF tokens on a SELinux system but I can help provide that if you'd
like. Although I might not be able to get to that until after the
merge window closes.
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 002351ab67b7..1501e95366a1 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -6828,6 +6828,29 @@ static void selinux_bpf_prog_free(struct bpf_prog *prog)
> prog->aux->security = NULL;
> kfree(bpfsec);
> }
> +
> +static int selinux_bpf_token_create(struct bpf_token *token, union bpf_attr *attr,
> + struct path *path)
> +{
> + struct bpf_security_struct *bpfsec;
> +
> + bpfsec = kzalloc(sizeof(*bpfsec), GFP_KERNEL);
> + if (!bpfsec)
> + return -ENOMEM;
> +
> + bpfsec->sid = current_sid();
> + token->security = bpfsec;
> +
> + return 0;
> +}
> +
> +static void selinux_bpf_token_free(struct bpf_token *token)
> +{
> + struct bpf_security_struct *bpfsec = token->security;
> +
> + token->security = NULL;
> + kfree(bpfsec);
> +}
> #endif
>
> struct lsm_blob_sizes selinux_blob_sizes __ro_after_init = {
> @@ -7183,6 +7206,7 @@ static struct security_hook_list selinux_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(bpf_prog, selinux_bpf_prog),
> LSM_HOOK_INIT(bpf_map_free, selinux_bpf_map_free),
> LSM_HOOK_INIT(bpf_prog_free, selinux_bpf_prog_free),
> + LSM_HOOK_INIT(bpf_token_free, selinux_bpf_token_free),
> #endif
>
> #ifdef CONFIG_PERF_EVENTS
> @@ -7241,6 +7265,7 @@ static struct security_hook_list selinux_hooks[] __ro_after_init = {
> #ifdef CONFIG_BPF_SYSCALL
> LSM_HOOK_INIT(bpf_map_create, selinux_bpf_map_create),
> LSM_HOOK_INIT(bpf_prog_load, selinux_bpf_prog_load),
> + LSM_HOOK_INIT(bpf_token_create, selinux_bpf_token_create),
> #endif
> #ifdef CONFIG_PERF_EVENTS
> LSM_HOOK_INIT(perf_event_alloc, selinux_perf_event_alloc),
> --
> 2.34.1
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v9 11/17] bpf,lsm: add BPF token LSM hooks
From: Paul Moore @ 2023-11-06 5:01 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, brauner
Cc: linux-fsdevel, linux-security-module, keescook, kernel-team,
sargun
In-Reply-To: <20231103190523.6353-12-andrii@kernel.org>
On Nov 3, 2023 Andrii Nakryiko <andrii@kernel.org> wrote:
>
> Wire up bpf_token_create and bpf_token_free LSM hooks, which allow to
> allocate LSM security blob (we add `void *security` field to struct
> bpf_token for that), but also control who can instantiate BPF token.
> This follows existing pattern for BPF map and BPF prog.
>
> Also add security_bpf_token_allow_cmd() and security_bpf_token_capable()
> LSM hooks that allow LSM implementation to control and negate (if
> necessary) BPF token's delegation of a specific bpf_cmd and capability,
> respectively.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
> include/linux/bpf.h | 3 ++
> include/linux/lsm_hook_defs.h | 5 +++
> include/linux/security.h | 25 +++++++++++++++
> kernel/bpf/bpf_lsm.c | 4 +++
> kernel/bpf/token.c | 13 ++++++--
> security/security.c | 60 +++++++++++++++++++++++++++++++++++
> 6 files changed, 107 insertions(+), 3 deletions(-)
...
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 08fd777cbe94..1d6edbf45d1c 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -60,6 +60,7 @@ struct fs_parameter;
> enum fs_value_type;
> struct watch;
> struct watch_notification;
> +enum bpf_cmd;
Yes, I think it's fine to include bpf.h in security.h instead of the
forward declaration.
> /* Default (no) options for the capable function */
> #define CAP_OPT_NONE 0x0
> @@ -2031,6 +2032,11 @@ extern void security_bpf_map_free(struct bpf_map *map);
> extern int security_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> struct bpf_token *token);
> extern void security_bpf_prog_free(struct bpf_prog *prog);
> +extern int security_bpf_token_create(struct bpf_token *token, union bpf_attr *attr,
> + struct path *path);
> +extern void security_bpf_token_free(struct bpf_token *token);
> +extern int security_bpf_token_allow_cmd(const struct bpf_token *token, enum bpf_cmd cmd);
> +extern int security_bpf_token_capable(const struct bpf_token *token, int cap);
> #else
> static inline int security_bpf(int cmd, union bpf_attr *attr,
> unsigned int size)
> @@ -2065,6 +2071,25 @@ static inline int security_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *
>
> static inline void security_bpf_prog_free(struct bpf_prog *prog)
> { }
> +
> +static inline int security_bpf_token_create(struct bpf_token *token, union bpf_attr *attr,
> + struct path *path)
> +{
> + return 0;
> +}
> +
> +static inline void security_bpf_token_free(struct bpf_token *token)
> +{ }
> +
> +static inline int security_bpf_token_allow_cmd(const struct bpf_token *token, enum bpf_cmd cmd)
> +{
> + return 0;
> +}
> +
> +static inline int security_bpf_token_capable(const struct bpf_token *token, int cap)
> +{
> + return 0;
> +}
Another nitpick, but I would prefer to shorten
security_bpf_token_allow_cmd() renamed to security_bpf_token_cmd() both
to shorten the name and to better fit convention. I realize the caller
is named bpf_token_allow_cmd() but I'd still rather see the LSM hook
with the shorter name.
> diff --git a/kernel/bpf/token.c b/kernel/bpf/token.c
> index 35e6f55c2a41..5d04da54faea 100644
> --- a/kernel/bpf/token.c
> +++ b/kernel/bpf/token.c
> @@ -7,11 +7,12 @@
> #include <linux/idr.h>
> #include <linux/namei.h>
> #include <linux/user_namespace.h>
> +#include <linux/security.h>
>
> bool bpf_token_capable(const struct bpf_token *token, int cap)
> {
> /* BPF token allows ns_capable() level of capabilities */
> - if (token) {
> + if (token && security_bpf_token_capable(token, cap) == 0) {
> if (ns_capable(token->userns, cap))
> return true;
> if (cap != CAP_SYS_ADMIN && ns_capable(token->userns, CAP_SYS_ADMIN))
We typically perform the capability based access controls prior to the
LSM controls, meaning if we want to the token controls to work in a
similar way we should do something like this:
bool bpf_token_capable(...)
{
if (token) {
if (ns_capable(token, cap) ||
(cap != ADMIN && ns_capable(token, ADMIN)))
return security_bpf_token_capable(token, cap);
}
return capable(cap) || (cap != ADMIN && capable(...))
}
> @@ -28,6 +29,7 @@ void bpf_token_inc(struct bpf_token *token)
>
> static void bpf_token_free(struct bpf_token *token)
> {
> + security_bpf_token_free(token);
> put_user_ns(token->userns);
> kvfree(token);
> }
> @@ -172,6 +174,10 @@ int bpf_token_create(union bpf_attr *attr)
> token->allowed_progs = mnt_opts->delegate_progs;
> token->allowed_attachs = mnt_opts->delegate_attachs;
>
> + err = security_bpf_token_create(token, attr, &path);
> + if (err)
> + goto out_token;
> +
> fd = get_unused_fd_flags(O_CLOEXEC);
> if (fd < 0) {
> err = fd;
> @@ -216,8 +222,9 @@ bool bpf_token_allow_cmd(const struct bpf_token *token, enum bpf_cmd cmd)
> {
> if (!token)
> return false;
> -
> - return token->allowed_cmds & (1ULL << cmd);
> + if (!(token->allowed_cmds & (1ULL << cmd)))
> + return false;
> + return security_bpf_token_allow_cmd(token, cmd) == 0;
I'm not sure how much it really matters, but someone might prefer
the '!!' approach/style over '== 0'.
> }
>
> bool bpf_token_allow_map_type(const struct bpf_token *token, enum bpf_map_type type)
--
paul-moore.com
^ 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