* [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spider-pci.c b/arch/powerpc/platforms/cell/spider-pci.c
index d1e61e2..82aa3f7 100644
--- a/arch/powerpc/platforms/cell/spider-pci.c
+++ b/arch/powerpc/platforms/cell/spider-pci.c
@@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct pci_controller *phb,
dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!dummy_page_va) {
pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
- return -1;
+ return -ENOMEM;
}
dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
@@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)
if (!priv) {
pr_err("SPIDERPCI-IOWA:"
"Can't allocate struct spiderpci_iowa_private");
- return -1;
+ return -ENOMEM;
}
if (of_address_to_resource(np, 0, &r)) {
--
2.7.4
^ permalink raw reply related
* [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/crypto/omap-aes-gcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 7d4f8a4..2542224 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -186,7 +186,7 @@ static int do_encrypt_iv(struct aead_request *req, u32 *tag, u32 *iv)
sk_req = skcipher_request_alloc(ctx->ctr, GFP_KERNEL);
if (!sk_req) {
pr_err("skcipher: Failed to allocate request\n");
- return -1;
+ return -ENOMEM;
}
init_completion(&result.completion);
--
2.7.4
^ permalink raw reply related
* [PATCH 03/10] driver:gpu: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/gpu/drm/gma500/mid_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c
index d75ecb3..1fa1633 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -237,7 +237,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
if (!gct)
- return -1;
+ return -ENOMEM;
gct_virtual = ioremap(addr + sizeof(vbt),
sizeof(*gct) * vbt.panel_count);
--
2.7.4
^ permalink raw reply related
* [PATCH 04/10] drivers:mpt: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/message/fusion/mptbase.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 84eab28..7920b2b 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -4328,15 +4328,15 @@ initChainBuffers(MPT_ADAPTER *ioc)
if (ioc->ReqToChain == NULL) {
sz = ioc->req_depth * sizeof(int);
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ReqToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ReqToChain alloc @ %p, sz=%d bytes\n",
ioc->name, mem, sz));
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->RequestNB = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "RequestNB alloc @ %p, sz=%d bytes\n",
@@ -4402,8 +4402,8 @@ initChainBuffers(MPT_ADAPTER *ioc)
sz = num_chain * sizeof(int);
if (ioc->ChainToChain == NULL) {
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ChainToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ChainToChain alloc @ %p, sz=%d bytes\n",
--
2.7.4
^ permalink raw reply related
* [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/net/bonding/bond_alb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index c02cc81..89df377 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -864,7 +864,7 @@ static int rlb_initialize(struct bonding *bond)
new_hashtbl = kmalloc(size, GFP_KERNEL);
if (!new_hashtbl)
- return -1;
+ return -ENOMEM;
spin_lock_bh(&bond->mode_lock);
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/net/ethernet/sun/cassini.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index 382993c..fc0ea3a 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int ring)
size = RX_DESC_RINGN_SIZE(ring);
for (i = 0; i < size; i++) {
if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
- return -1;
+ return -ENOMEM;
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 07/10] driver:megaraid: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/scsi/megaraid/megaraid_mbox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c
index ec3c438..b09a0a6 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -724,8 +724,8 @@ megaraid_init_mbox(adapter_t *adapter)
* controllers
*/
raid_dev = kzalloc(sizeof(mraid_device_t), GFP_KERNEL);
- if (raid_dev == NULL) return -1;
-
+ if (!raid_dev)
+ return -ENOMEM;
/*
* Attach the adapter soft state to raid device soft state
--
2.7.4
^ permalink raw reply related
* [PATCH 08/10] driver:cxgbit: return -NOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/target/iscsi/cxgbit/cxgbit_target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 514986b..47127d6 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -399,7 +399,7 @@ cxgbit_map_skb(struct iscsi_cmd *cmd, struct sk_buff *skb, u32 data_offset,
if (padding) {
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (!page)
- return -1;
+ return -ENOMEM;
skb_fill_page_desc(skb, i, page, 0, padding);
skb->data_len += padding;
skb->len += padding;
--
2.7.4
^ permalink raw reply related
* [PATCH 09/10] driver:video: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
index f6a0b9a..5cd238d 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -2058,7 +2058,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm
minfo = kzalloc(sizeof(*minfo), GFP_KERNEL);
if (!minfo)
- return -1;
+ return -ENOMEM;
minfo->pcidev = pdev;
minfo->dead = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
fs/btrfs/check-integrity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 7d5a9b5..efa4c23 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
state = kvzalloc(sizeof(*state), GFP_KERNEL);
if (!state) {
pr_info("btrfs check-integrity: allocation failed!\n");
- return -1;
+ return -ENOMEM;
}
if (!btrfsic_is_initialized) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ravb: document R8A77970 bindings
From: Simon Horman @ 2017-09-13 7:39 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, netdev, devicetree, Mark Rutland, linux-renesas-soc
In-Reply-To: <20170912200228.015376134@cogentembedded.com>
On Tue, Sep 12, 2017 at 11:02:08PM +0300, Sergei Shtylyov wrote:
> R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB
> device, so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
> applied to 'net.git' instead. :-)
Personally I would prefer net-next, but I don't feel strongly about this.
If you want it considered for net then I think it is likely that you will
need to repost it with the appropriate patch prefix.
>
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
> ===================================================================
> --- net-next.orig/Documentation/devicetree/bindings/net/renesas,ravb.txt
> +++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
> @@ -17,6 +17,7 @@ Required properties:
>
> - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
> - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
> + - "renesas,etheravb-r8a77970" for the R8A77970 SoC.
> - "renesas,etheravb-rcar-gen3" as a fallback for the above
> R-Car Gen3 devices.
>
> @@ -40,7 +41,7 @@ Optional properties:
> - interrupt-parent: the phandle for the interrupt controller that services
> interrupts for this device.
> - interrupt-names: A list of interrupt names.
> - For the R8A779[56] SoCs this property is mandatory;
> + For the R-Car Gen 3 SoCs this property is mandatory;
> it should include one entry per channel, named "ch%u",
> where %u is the channel number ranging from 0 to 24.
> For other SoCs this property is optional; if present
>
^ permalink raw reply
* Re: [PATCH] VSOCK: fix uapi/linux/vm_sockets.h incomplete types
From: Jorgen S. Hansen @ 2017-09-13 7:55 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev@vger.kernel.org, David S . Miller
In-Reply-To: <20170912163435.4049-1-stefanha@redhat.com>
> On Sep 12, 2017, at 6:34 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> This patch fixes the following compiler errors when userspace
> applications use the vm_sockets.h header:
>
> include/uapi/linux/vm_sockets.h:148:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’
> unsigned char svm_zero[sizeof(struct sockaddr) -
> ^~~~~~
> include/uapi/linux/vm_sockets.h:149:18: error: ‘sa_family_t’ undeclared here (not in a function)
> sizeof(sa_family_t) -
> ^~~~~~~~~~~
>
> Two issues:
> 1. In the kernel struct sockaddr comes in via <linux/socket.h> but in
> userspace <sys/socket.h> is required.
> 2. struct sockaddr_vm has a __kernel_sa_family_t field so let's be
> consistent and use the same type for the sizeof(sa_family_t)
> calculation.
>
> Currently userspace applications work around this broken header by first
> including <sys/socket.h>. In the kernel there is no compiler error
> because <linux/socket.h> provides everything. It's worth fixing the
> header file though.
>
> Cc: Jorgen Hansen <jhansen@vmware.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> include/uapi/linux/vm_sockets.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
> index b4ed5d895699..4ae5c625ac56 100644
> --- a/include/uapi/linux/vm_sockets.h
> +++ b/include/uapi/linux/vm_sockets.h
> @@ -18,6 +18,10 @@
>
> #include <linux/socket.h>
>
> +#ifndef __KERNEL__
> +#include <sys/socket.h> /* struct sockaddr */
> +#endif
> +
> /* Option name for STREAM socket buffer size. Use as the option name in
> * setsockopt(3) or getsockopt(3) to set or get an unsigned long long that
> * specifies the size of the buffer underlying a vSockets STREAM socket.
> @@ -146,7 +150,7 @@ struct sockaddr_vm {
> unsigned int svm_port;
> unsigned int svm_cid;
> unsigned char svm_zero[sizeof(struct sockaddr) -
> - sizeof(sa_family_t) -
> + sizeof(__kernel_sa_family_t) -
> sizeof(unsigned short) -
> sizeof(unsigned int) - sizeof(unsigned int)];
> };
> --
> 2.13.5
>
Thanks for fixing this.
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
^ permalink raw reply
* Re: [PATCH] ravb: document R8A77970 bindings
From: Geert Uytterhoeven @ 2017-09-13 7:56 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, netdev@vger.kernel.org, devicetree@vger.kernel.org,
Mark Rutland, Linux-Renesas
In-Reply-To: <20170912200228.015376134@cogentembedded.com>
On Tue, Sep 12, 2017 at 10:02 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB
> device, so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Memory leaks in conntrack
From: Florian Westphal @ 2017-09-13 8:05 UTC (permalink / raw)
To: Cong Wang; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpWvO3L1JOrCMvAvqduWH5pt_9-=GEx+eOFQyOt5Z5prrA@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> While testing my TC filter patches (so not related to conntrack), the
> following memory leaks are shown up:
>
> unreferenced object 0xffff9b19ba551228 (size 128):
> comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
> hex dump (first 32 bytes):
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
> backtrace:
> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
> [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
> [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
> [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> unreferenced object 0xffff9b19a69b3340 (size 336):
> comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
> hex dump (first 32 bytes):
> 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
> ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
> backtrace:
> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
> [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
> [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
>
> I don't touch chronyd in my VM, so I have no idea why it sends out UDP
> packets, my guess is it is some periodical packet.
>
> I don't think I use conntrack either, since /proc/net/ip_conntrack
> does not exist.
You probably do, can you try "cat /proc/net/nf_conntrack" instead?
(otherwise there should be no ipv4_conntrack_local() invocation
since we would not register this hook at all).
I tried to reproduce this but so far I had no success.
If you can identify something that could give a hint when this
is happening (only once after boot, periodically, only with udp, etc)
please let us know.
(A reproducer would be even better of course ;-) )
Is this with current net tree?
Thanks!
^ permalink raw reply
* Re: Regression in throughput between kvm guests over virtual bridge
From: Jason Wang @ 2017-09-13 8:13 UTC (permalink / raw)
To: Matthew Rosato, netdev; +Cc: davem, mst
In-Reply-To: <bdd417dc-9e2f-4a2e-534b-c6aa38f002f2@redhat.com>
On 2017年09月13日 09:16, Jason Wang wrote:
>
>
> On 2017年09月13日 01:56, Matthew Rosato wrote:
>> We are seeing a regression for a subset of workloads across KVM guests
>> over a virtual bridge between host kernel 4.12 and 4.13. Bisecting
>> points to c67df11f "vhost_net: try batch dequing from skb array"
>>
>> In the regressed environment, we are running 4 kvm guests, 2 running as
>> uperf servers and 2 running as uperf clients, all on a single host.
>> They are connected via a virtual bridge. The uperf client profile looks
>> like:
>>
>> <?xml version="1.0"?>
>> <profile name="TCP_STREAM">
>> <group nprocs="1">
>> <transaction iterations="1">
>> <flowop type="connect" options="remotehost=192.168.122.103
>> protocol=tcp"/>
>> </transaction>
>> <transaction duration="300">
>> <flowop type="write" options="count=16 size=30000"/>
>> </transaction>
>> <transaction iterations="1">
>> <flowop type="disconnect"/>
>> </transaction>
>> </group>
>> </profile>
>>
>> So, 1 tcp streaming instance per client. When upgrading the host kernel
>> from 4.12->4.13, we see about a 30% drop in throughput for this
>> scenario. After the bisect, I further verified that reverting c67df11f
>> on 4.13 "fixes" the throughput for this scenario.
>>
>> On the other hand, if we increase the load by upping the number of
>> streaming instances to 50 (nprocs="50") or even 10, we see instead a
>> ~10% increase in throughput when upgrading host from 4.12->4.13.
>>
>> So it may be the issue is specific to "light load" scenarios. I would
>> expect some overhead for the batching, but 30% seems significant... Any
>> thoughts on what might be happening here?
>>
>
> Hi, thanks for the bisecting. Will try to see if I can reproduce.
> Various factors could have impact on stream performance. If possible,
> could you collect the #pkts and average packet size during the test?
> And if you guest version is above 4.12, could you please retry with
> napi_tx=true?
>
> Thanks
Unfortunately, I could not reproduce it locally. I'm using net-next.git
as guest. I can get ~42Gb/s on Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
for both before and after the commit. I use 1 vcpu and 1 queue, and pin
vcpu and vhost threads into separate cpu on host manually (in same numa
node).
Can you hit this regression constantly and what's you qemu command line
and #cpus on host? Is zerocopy enabled?
Thanks
^ permalink raw reply
* Re: [PATCH] ipv4: Namespaceify tcp_fastopen knob
From: 严海双 @ 2017-09-13 8:49 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, edumazet, netdev, linux-kernel
In-Reply-To: <20170912.205709.130426973112637232.davem@davemloft.net>
> On 2017年9月13日, at 上午11:57, David Miller <davem@davemloft.net> wrote:
>
> From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> Date: Tue, 12 Sep 2017 18:30:57 +0800
>
>> Different namespace application might require enable TCP Fast Open
>> feature independently of the host.
>>
>> Reported-by: Luca BRUNO <lucab@debian.org>
>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> ...
>> diff --git a/samples/bpf/test_ipip.sh b/samples/bpf/test_ipip.sh
>> index 1969254..7bbc521 100755
>> --- a/samples/bpf/test_ipip.sh
>> +++ b/samples/bpf/test_ipip.sh
>> @@ -173,6 +173,8 @@ function cleanup {
>> cleanup
>> echo "Testing IP tunnels..."
>> test_ipip
>> +sleep 1
>> test_ipip6
>> +sleep 1
>> test_ip6ip6
>> echo "*** PASS ***"
>
> This seems like a completely unrelated change.
>
Sorry, I make a mistake for including my local test changes in this patch.
I will remove this change in v2 commit. Thanks David for reviewing.
^ permalink raw reply
* (unknown),
From: kindergartenchaos2 @ 2017-09-13 8:56 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 9675261.doc --]
[-- Type: application/msword, Size: 76537 bytes --]
^ permalink raw reply
* Re: [iproute PATCH] ipaddress: Fix segfault in 'addr showdump'
From: Phil Sutter @ 2017-09-13 9:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Hangbin Liu
In-Reply-To: <20170912145812.15380-1-phil@nwl.cc>
On Tue, Sep 12, 2017 at 04:58:12PM +0200, Phil Sutter wrote:
> Obviously, 'addr showdump' feature wasn't adjusted to json output
> support. As a consequence, calls to print_string() in print_addrinfo()
> tried to dereference a NULL FILE pointer.
Please ignore this patch - it generates incorrect json output. I'll send
a v2 which fixes that.
Thanks, Phil
^ permalink raw reply
* RE: [PATCH] qed: remove unnecessary call to memset
From: Kalluru, Sudarsana @ 2017-09-13 9:15 UTC (permalink / raw)
To: Himanshu Jha, Mintz, Yuval
Cc: Elior, Ariel, Dept-Eng Everest Linux L2, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1505215162-3917-1-git-send-email-himanshujha199640@gmail.com>
-----Original Message-----
From: Himanshu Jha [mailto:himanshujha199640@gmail.com]
Sent: 12 September 2017 16:49
To: Mintz, Yuval <Yuval.Mintz@cavium.com>
Cc: Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Himanshu Jha <himanshujha199640@gmail.com>
Subject: [PATCH] qed: remove unnecessary call to memset
call to memset to assign 0 value immediately after allocating memory with kzalloc is unnecesaary as kzalloc allocates the memory filled with 0 value.
Semantic patch used to resolve this issue:
@@
expression e,e2; constant c;
statement S;
@@
e = kzalloc(e2, c);
if(e == NULL) S
- memset(e, 0, e2);
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index eaca457..8f6ccc0 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -1244,7 +1244,6 @@ int qed_dcbx_get_config_params(struct qed_hwfn *p_hwfn,
if (!dcbx_info)
return -ENOMEM;
- memset(dcbx_info, 0, sizeof(*dcbx_info));
rc = qed_dcbx_query_params(p_hwfn, dcbx_info, QED_DCBX_OPERATIONAL_MIB);
if (rc) {
kfree(dcbx_info);
--
2.7.4
Acked-by: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
^ permalink raw reply related
* [PATCH net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: Dan Carpenter @ 2017-09-13 9:20 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Neil Horman, David S. Miller, linux-sctp, netdev, kernel-janitors
This code causes a static checker warning because Smatch doesn't trust
anything that comes from skb->data. I've reviewed this code and I do
think skb->data can be controlled by the user here.
The sctp_event_subscribe struct has 13 __u8 fields and we want to see
if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range.
We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
either before the start of the struct or after the end.
This is a very old bug and it's surprising that it would go undetected
for so long but my theory is that it just doesn't have a big impact so
it would be hard to notice.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
I'm not terribly familiar with sctp and this is a static checker fix.
Please review it carefully.
diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
index 1060494ac230..e6873176bea7 100644
--- a/include/net/sctp/ulpevent.h
+++ b/include/net/sctp/ulpevent.h
@@ -154,7 +154,11 @@ static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
struct sctp_event_subscribe *mask)
{
char *amask = (char *) mask;
- return amask[sn_type - SCTP_SN_TYPE_BASE];
+ int offset = sn_type - SCTP_SN_TYPE_BASE;
+
+ if (offset >= sizeof(struct sctp_event_subscribe))
+ return 0;
+ return amask[offset];
}
/* Given an event subscription, is this event enabled? */
^ permalink raw reply related
* [iproute PATCH v2] ipaddress: Fix segfault in 'addr showdump'
From: Phil Sutter @ 2017-09-13 9:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Hangbin Liu, netdev, Julien Fortin
Obviously, 'addr showdump' feature wasn't adjusted to json output
support. As a consequence, calls to print_string() in print_addrinfo()
tried to dereference a NULL FILE pointer.
Cc: Julien Fortin <julien@cumulusnetworks.com>
Fixes: d0e720111aad2 ("ip: ipaddress.c: add support for json output")
Signed-off-by: Phil Sutter <phil@nwl.cc>
--
Changes since v1:
Align json output with that of 'ip -j addr show':
- Interface index label is 'ifindex', not 'index' and it doesn't belong
to 'addr_info' array.
- Create one 'addr_info' array per dumped address, not one for all.
---
ip/ipaddress.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 9797145023966..4c47809570410 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1801,17 +1801,33 @@ static int show_handler(const struct sockaddr_nl *nl,
{
struct ifaddrmsg *ifa = NLMSG_DATA(n);
- printf("if%d:\n", ifa->ifa_index);
+ open_json_object(NULL);
+ print_int(PRINT_ANY, "ifindex", "if%d:\n", ifa->ifa_index);
+
+ open_json_array(PRINT_JSON, "addr_info");
+ open_json_object(NULL);
+
print_addrinfo(NULL, n, stdout);
+
+ close_json_object();
+ close_json_array(PRINT_JSON, NULL);
+
+ close_json_object();
return 0;
}
static int ipaddr_showdump(void)
{
+ int err;
+
if (ipadd_dump_check_magic())
exit(-1);
- exit(rtnl_from_file(stdin, &show_handler, NULL));
+ new_json_obj(json, stdout);
+ err = rtnl_from_file(stdin, &show_handler, NULL);
+ delete_json_obj();
+
+ exit(err);
}
static int restore_handler(const struct sockaddr_nl *nl,
--
2.13.1
^ permalink raw reply related
* Re: [oss-drivers] Re: [PATCH/RFC net-next 2/2] net/sched: allow flower to match tunnel options
From: Simon Horman @ 2017-09-13 9:25 UTC (permalink / raw)
To: Or Gerlitz
Cc: Jiri Pirko, Jamal Hadi Salim, Cong Wang, Linux Netdev List,
oss-drivers
In-Reply-To: <CAJ3xEMgfkpJCfZX-7jaeYtoWTSQQZ6gu8_jSFgcXpzTBpdijQw@mail.gmail.com>
On Tue, Sep 12, 2017 at 11:23:55PM +0300, Or Gerlitz wrote:
> On Tue, Sep 12, 2017 at 5:20 PM, Simon Horman
> <simon.horman@netronome.com> wrote:
> > Allow matching on options in tunnel headers.
> > This makes use of existing tunnel metadata support.
>
> Simon,
>
> This patch is about matching on tunnel options, right? but
>
> > Options are a bytestring of up to 256 bytes.
> > Tunnel implementations may support less or more options,
> > or no options at all.
> >
> > # ip link add name geneve0 type geneve dstport 0 external
> > # tc qdisc add dev eth0 ingress
> > # tc qdisc del dev eth0 ingress; tc qdisc add dev eth0 ingress
> > # tc filter add dev eth0 protocol ip parent ffff: \
> > flower indev eth0 \
> > ip_proto udp \
> > action tunnel_key \
> > set src_ip 10.0.99.192 \
> > dst_ip 10.0.99.193 \
> > dst_port 4789 \
> > id 11 \
> > opts 0102800100800022 \
> > action mirred egress redirect dev geneve0
>
> the example here is on how to use tunnel options in the tunnel set key actions..
>
> And the other way around in the other patch... the patch is about the
> tunnel key set action and the example shows how to match that in
> flower... I guess you want to swap the relevant of the change log.
Yes, it seems so. Sorry about that.
> Anyway, is there any human readable/understandable representation of
> these options? e.g what does 0102800100800022 means for geneve?
Thanks, I had not thought of that. My feeling is that could
be added to the tc tool as follow-up work.
^ permalink raw reply
* Re: [PATCH iproute2 1/2] lib/libnetlink: re malloc buff if size is not enough
From: Hangbin Liu @ 2017-09-13 9:26 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Phil Sutter, netdev, Stephen Hemminger
In-Reply-To: <20170912090926.j7vwhq6a57c5d6wx@unicorn.suse.cz>
Hi Michal,
Thanks a lot for all your explains. Phil has helped update the patch to support
return a newly allocated buffer. I will post it soon.
Thanks
Hangbin
On Tue, Sep 12, 2017 at 11:09:26AM +0200, Michal Kubecek wrote:
> >
> > I checked again and arpd indeed isn't a problem. It doesn't seem to call
> > any of the two functions (directly or indirectly) and while it's linked
> > with "-lpthread", it's not really multithreaded.
> >
> > But my concern was rather about other potential users of libnetlink
> > (i.e. those which are not part of iproute2). I must admit, though, that
> > I'm not sure if libnetlink code is reentrant as of now. (And people are
> > discouraged from using it in its own manual page.)
> >
> > That being said, I still like Phil's idea for a different reason. While
> > investigating the issue with "ip link show dev eth ..." which led me to
> > commit 6599162b958e ("iplink: check for message truncation in
> > iplink_get()"), I quickly peeked at some other callers of rtnl_talk()
> > and I'm afraid there may be others which wouldn't handle truncated
> > message correctly. I assume the maxlen argument was always chosen to be
> > sufficient for any expected messages but as the example of iplink_get()
> > shows, messages returned by kernel my grow over time.
> >
> > That's why I like the idea of __rtnl_talk() returning a pointer to newly
> > allocated buffer (of sufficient size) rather than copying the response
> > into a buffer provided by caller and potentially truncating it.
>
> I'm sorry, I managed to forget that your patch 2 does already address
> this problem. But the fact that any caller must keep in mind that he
> must not call the same function again until the previous response is no
> longer needed still feels like a trap. It's something you need to keep
> in mind (where "you" in fact means any future contributor) and it's
> easy to forget. That's why I prefer the reentrant functions like
> strerror_r() or localtime_r() even in code which is not intended to be
> multithreaded. Getting an object which is "mine" to do with whatever
> I want until I no longer need it feels like a cleaner interface to me.
>
> Michal Kubecek
>
^ permalink raw reply
* [PATCHv2 iproute2 0/2] libnetlink: malloc correct buff at run time
From: Hangbin Liu @ 2017-09-13 9:59 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Michal Kubecek, Phil Sutter, Hangbin Liu
With commit 72b365e8e0fd ("libnetlink: Double the dump buffer size") and
460c03f3f3cc ("iplink: double the buffer size also in iplink_get()"), we
extend the buffer size to avoid truncated message with large numbers of
VFs. But just as Michal said, this is not future-proof since the NIC
number is increasing. We have customer even has 220+ VFs now.
This is not make sense to hard code the buffer and increase it all the time.
So let's just malloc the correct buff size at run time.
Tested with most ip cmds and all look good.
---
Changes since v1 by Phil:
* rtnl_recvmsg():
* Rename output buffer pointer arg to 'answer'.
* Use realloc() and make sure old buffer is freed on error.
* Always return a newly allocated buffer for caller to free.
* Retry on EINTR or EAGAIN so caller doesn't have to.
* Return well-known negative error codes instead of just -1 on error.
* Simplify goto label names.
* If no answer pointer was passed, just free the buffer.
* rtnl_dump_filter_l():
* Don't retry if rtnl_recvmsg() returns 0 as this can't happen
anymore.
* Free buffer returned by rtnl_recvmsg().
* __rtnl_talk():
* Don't retry if rtnl_recvmsg() returns 0 as this can't happen
anymore.
* Free buffer returned by rtnl_recvmsg().
* Return a newly allocated buffer for callers to free.
* genl_ctrl_resolve_family()
* Replace 'ghdr + GENL_HDRLEN' to 'answer + NLMSG_LENGTH(GENL_HDRLEN)'
* tc_action_gd()
* Call print_action() only if cmd == RTM_GETACTION
* Change callers of rtnl_talk*() to always free the answer buffer if
they passed one.
* Drop extra request buffer space in callers if only used for holding
output data.
* Drop initialization of answer pointer if not necessary.
* Change callers to pass NULL instead of answer pointer if they don't
use it afterwards.
Hangbin Liu (2):
lib/libnetlink: re malloc buff if size is not enough
lib/libnetlink: update rtnl_talk to support malloc buff at run time
bridge/fdb.c | 2 +-
bridge/link.c | 2 +-
bridge/mdb.c | 2 +-
bridge/vlan.c | 2 +-
genl/ctrl.c | 19 +++++---
include/libnetlink.h | 6 +--
ip/ipaddress.c | 4 +-
ip/ipaddrlabel.c | 4 +-
ip/ipfou.c | 4 +-
ip/ipila.c | 4 +-
ip/ipl2tp.c | 8 ++--
ip/iplink.c | 38 +++++++--------
ip/iplink_vrf.c | 44 ++++++++---------
ip/ipmacsec.c | 2 +-
ip/ipneigh.c | 2 +-
ip/ipnetns.c | 23 +++++----
ip/ipntable.c | 2 +-
ip/iproute.c | 26 ++++++----
ip/iprule.c | 6 +--
ip/ipseg6.c | 8 ++--
ip/iptoken.c | 2 +-
ip/link_gre.c | 11 +++--
ip/link_gre6.c | 11 +++--
ip/link_ip6tnl.c | 11 +++--
ip/link_iptnl.c | 10 ++--
ip/link_vti.c | 11 +++--
ip/link_vti6.c | 11 +++--
ip/tcp_metrics.c | 8 ++--
ip/xfrm_policy.c | 25 +++++-----
ip/xfrm_state.c | 30 ++++++------
lib/libgenl.c | 9 +++-
lib/libnetlink.c | 132 +++++++++++++++++++++++++++++++++------------------
misc/ss.c | 2 +-
tc/m_action.c | 12 ++---
tc/tc_class.c | 2 +-
tc/tc_filter.c | 8 ++--
tc/tc_qdisc.c | 2 +-
37 files changed, 296 insertions(+), 209 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCHv2 iproute2 1/2] lib/libnetlink: re malloc buff if size is not enough
From: Hangbin Liu @ 2017-09-13 9:59 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Michal Kubecek, Phil Sutter, Hangbin Liu
In-Reply-To: <1505296780-8444-1-git-send-email-liuhangbin@gmail.com>
With commit 72b365e8e0fd ("libnetlink: Double the dump buffer size")
we doubled the buffer size to support more VFs. But the VFs number is
increasing all the time. Some customers even use more than 200 VFs now.
We could not double it everytime when the buffer is not enough. Let's just
not hard code the buffer size and malloc the correct number when running.
Introduce function rtnl_recvmsg() to always return a newly allocated buffer.
The caller need to free it after using.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/libnetlink.c | 112 ++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 78 insertions(+), 34 deletions(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index be7ac86..e3fa7cf 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -402,6 +402,62 @@ static void rtnl_dump_error(const struct rtnl_handle *rth,
}
}
+static int rtnl_recvmsg(int fd, struct msghdr *msg, char **answer)
+{
+ struct iovec *iov;
+ int len = -1, buf_len = 32768;
+ char *bufp, *buf = NULL;
+
+ int flag = MSG_PEEK | MSG_TRUNC;
+
+realloc:
+ bufp = realloc(buf, buf_len);
+
+ if (bufp == NULL) {
+ fprintf(stderr, "malloc error: not enough buffer\n");
+ free(buf);
+ return -ENOMEM;
+ }
+ buf = bufp;
+ iov = msg->msg_iov;
+ iov->iov_base = buf;
+ iov->iov_len = buf_len;
+
+recv:
+ len = recvmsg(fd, msg, flag);
+
+ if (len < 0) {
+ if (errno == EINTR || errno == EAGAIN)
+ goto recv;
+ fprintf(stderr, "netlink receive error %s (%d)\n",
+ strerror(errno), errno);
+ return len;
+ }
+
+ if (len == 0) {
+ fprintf(stderr, "EOF on netlink\n");
+ return -ENODATA;
+ }
+
+ if (len > buf_len) {
+ buf_len = len;
+ flag = 0;
+ goto realloc;
+ }
+
+ if (flag != 0) {
+ flag = 0;
+ goto recv;
+ }
+
+ if (answer)
+ *answer = buf;
+ else
+ free(buf);
+
+ return len;
+}
+
int rtnl_dump_filter_l(struct rtnl_handle *rth,
const struct rtnl_dump_filter_arg *arg)
{
@@ -413,31 +469,18 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
.msg_iov = &iov,
.msg_iovlen = 1,
};
- char buf[32768];
+ char *buf;
int dump_intr = 0;
- iov.iov_base = buf;
while (1) {
int status;
const struct rtnl_dump_filter_arg *a;
int found_done = 0;
int msglen = 0;
- iov.iov_len = sizeof(buf);
- status = recvmsg(rth->fd, &msg, 0);
-
- if (status < 0) {
- if (errno == EINTR || errno == EAGAIN)
- continue;
- fprintf(stderr, "netlink receive error %s (%d)\n",
- strerror(errno), errno);
- return -1;
- }
-
- if (status == 0) {
- fprintf(stderr, "EOF on netlink\n");
- return -1;
- }
+ status = rtnl_recvmsg(rth->fd, &msg, &buf);
+ if (status < 0)
+ return status;
if (rth->dump_fp)
fwrite(buf, 1, NLMSG_ALIGN(status), rth->dump_fp);
@@ -462,8 +505,10 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
if (h->nlmsg_type == NLMSG_DONE) {
err = rtnl_dump_done(h);
- if (err < 0)
+ if (err < 0) {
+ free(buf);
return -1;
+ }
found_done = 1;
break; /* process next filter */
@@ -471,19 +516,23 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
if (h->nlmsg_type == NLMSG_ERROR) {
rtnl_dump_error(rth, h);
+ free(buf);
return -1;
}
if (!rth->dump_fp) {
err = a->filter(&nladdr, h, a->arg1);
- if (err < 0)
+ if (err < 0) {
+ free(buf);
return err;
+ }
}
skip_it:
h = NLMSG_NEXT(h, msglen);
}
}
+ free(buf);
if (found_done) {
if (dump_intr)
@@ -543,7 +592,7 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
.msg_iov = &iov,
.msg_iovlen = 1,
};
- char buf[32768] = {};
+ char *buf;
n->nlmsg_seq = seq = ++rtnl->seq;
@@ -556,22 +605,12 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
return -1;
}
- iov.iov_base = buf;
while (1) {
- iov.iov_len = sizeof(buf);
- status = recvmsg(rtnl->fd, &msg, 0);
+ status = rtnl_recvmsg(rtnl->fd, &msg, &buf);
+
+ if (status < 0)
+ return status;
- if (status < 0) {
- if (errno == EINTR || errno == EAGAIN)
- continue;
- fprintf(stderr, "netlink receive error %s (%d)\n",
- strerror(errno), errno);
- return -1;
- }
- if (status == 0) {
- fprintf(stderr, "EOF on netlink\n");
- return -1;
- }
if (msg.msg_namelen != sizeof(nladdr)) {
fprintf(stderr,
"sender address length == %d\n",
@@ -585,6 +624,7 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
if (l < 0 || len > status) {
if (msg.msg_flags & MSG_TRUNC) {
fprintf(stderr, "Truncated message\n");
+ free(buf);
return -1;
}
fprintf(stderr,
@@ -611,6 +651,7 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
if (answer)
memcpy(answer, h,
MIN(maxlen, h->nlmsg_len));
+ free(buf);
return 0;
}
@@ -619,12 +660,14 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
rtnl_talk_error(h, err, errfn);
errno = -err->error;
+ free(buf);
return -1;
}
if (answer) {
memcpy(answer, h,
MIN(maxlen, h->nlmsg_len));
+ free(buf);
return 0;
}
@@ -633,6 +676,7 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
status -= NLMSG_ALIGN(len);
h = (struct nlmsghdr *)((char *)h + NLMSG_ALIGN(len));
}
+ free(buf);
if (msg.msg_flags & MSG_TRUNC) {
fprintf(stderr, "Message truncated\n");
--
2.5.5
^ permalink raw reply related
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