* 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: [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: [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: 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
* [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
* [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 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 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 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 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 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 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 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 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
* Re: [PATCH] tcp: TCP_USER_TIMEOUT can not work in tcp_probe_timer()
From: liujian @ 2017-09-13 7:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuznet, yoshfuji, edumazet, ycheng, hkchu, netdev,
weiyongjun1, wangkefeng 00227729
In-Reply-To: <b72fefba-e701-2ec8-0e7b-3bba6ed25205@huawei.com>
在 2017/9/13 14:56, liujian 写道:
>
>
> 在 2017/9/12 23:38, Eric Dumazet 写道:
>> On Tue, 2017-09-12 at 08:05 -0700, Eric Dumazet wrote:
>>> On Tue, 2017-09-12 at 14:08 +0800, liujian wrote:
>>>> Hi,
>>>>
>>>> In the scenario, tcp server side IP changed, and at that memont,
>>>> userspace application still send data continuously;
>>>> tcp_send_head(sk)'s timestamp always be refreshed.
>>>>
>>>> Here is the packetdrill script:
>>>>
>>>> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>>>> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>>> +0 bind(3, ..., ...) = 0
>>>> +0 listen(3, 1) = 0
>>>>
>>>> +0 < S 0:0(0) win 0 <mss 1460,sackOK,nop,nop,nop,wscale 7>
>>>> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
>>>>
>>>> +.1 < . 1:1(0) ack 1 win 65530
>>>> +0 accept(3, ..., ...) = 4
>>>>
>>>> +0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0
>>>> +0 write(4, ..., 24) = 24
>>>> +0 > P. 1:25(24) ack 1 win 229
>>>> +.1 < . 1:1(0) ack 25 win 65530
>>>>
>>>> //change the ipaddress
>>>> +1 `ifconfig tun0 192.168.0.10/16`
>>>>
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>>
>>>> +0 `ifconfig tun0 192.168.0.1/16`
>>>> +0 < . 1:1(0) ack 1 win 1000
>>>> +0 write(4, ..., 24) = -1
>>>>
>>>>
>>>
>>> This has nothing to do with the code patch you have changed.
>>>
>>> How have you tested your patch exactly ?
>>>
> I tested the patch, it can work.
>
> [root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
> test.pkt:24: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
>
> real 0m5.356s
> user 0m0.026s
> sys 0m0.104s
>
> [root@localhost ~]# ss -toenmi src :8080
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> ESTAB 0 48 192.168.0.1:8080 192.0.2.1:39559 timer:(persist,186ms,2) ino:37178 sk:6 <->
> skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:2 rtt:100.253/37.643 mss:1460 cwnd:10 bytes_acked:24 segs_out:5 segs_in:3 send 1.2Mbps lastsnd:976 lastrcv:4082 lastack:3982 pacing_rate 2.3Mbps rcv_space:29200
>
>
> if change the TCP_USER_TIMEOUT to 30s, test result as below:
>
> [root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
> test.pkt:37: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
>
> real 0m44.362s
> user 0m0.018s
> sys 0m0.110s
>
> ESTAB 0 360 192.168.0.1:8080 192.0.2.1:47577 timer:(persist,516ms,6) ino:18806 sk:5 <->
> skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:6 rtt:100.228/37.623 mss:10 bytes_acked:24 segs_out:22 segs_in:3 send 1.2Mbps lastsnd:2343 lastrcv:40450 lastack:40350 pacing_rate 2.3Mbps rcv_sp
>
>>
>> lpaa23:~# ss -toenmi src :8080
>> State Recv-Q Send-Q Local Address:Port Peer
>> Address:Port
>> ESTAB 0 144 192.168.134.161:8080
>> 192.0.2.1:51165 timer:(persist,8.262ms,5) ino:1
>> 82083 sk:3 <->
>> skmem:(r0,rb359040,t0,tb46080,f1792,w2304,o0,bl0,d0) sack cubic
>> wscale:7,8 rto:301 backoff:5 rtt:100.127/37.576
>> mss:1460 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:24 segs_out:12
>> segs_in:3 data_segs_out:12 send 1.2Mbps lastsnd:1370 l
>> astrcv:13348 lastack:13248 pacing_rate 2.3Mbps delivery_rate 116.7Kbps
>> app_limited busy:11346ms rcv_space:29200 notsent:1
>> 44 minrtt:100.043userspace application still send data continuously
>>
>> This is the typical RTO timer, not zero window probe.
>>
> with the script, it is not zero window; but the code enter tcp_probe_timer.
> ->tcp_sendmsg
> -->tcp_push
> ---->__tcp_push_pending_frames
> ------>tcp_write_xmit
> -------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
> ---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
> -------->tcp_transmit_skb (send fail, do not advance send head)
> ------->tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
sorry, change to
->tcp_sendmsg
-->tcp_push
---->__tcp_push_pending_frames
------>tcp_write_xmit
-------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
------>tcp_write_xmit (send fail, do not advance send head)
------>tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
> Here userspace application still send data continuously,
> it triggered ICSK_TIME_PROBE0 timer and tcp_send_head(sk)'s timestamp refresh.
>
>
^ permalink raw reply
* Re: [PATCH] tcp: TCP_USER_TIMEOUT can not work in tcp_probe_timer()
From: liujian @ 2017-09-13 6:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuznet, yoshfuji, edumazet, ycheng, hkchu, netdev,
weiyongjun1, wangkefeng 00227729
In-Reply-To: <1505230686.15310.141.camel@edumazet-glaptop3.roam.corp.google.com>
在 2017/9/12 23:38, Eric Dumazet 写道:
> On Tue, 2017-09-12 at 08:05 -0700, Eric Dumazet wrote:
>> On Tue, 2017-09-12 at 14:08 +0800, liujian wrote:
>>> Hi,
>>>
>>> In the scenario, tcp server side IP changed, and at that memont,
>>> userspace application still send data continuously;
>>> tcp_send_head(sk)'s timestamp always be refreshed.
>>>
>>> Here is the packetdrill script:
>>>
>>> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>>> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>> +0 bind(3, ..., ...) = 0
>>> +0 listen(3, 1) = 0
>>>
>>> +0 < S 0:0(0) win 0 <mss 1460,sackOK,nop,nop,nop,wscale 7>
>>> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
>>>
>>> +.1 < . 1:1(0) ack 1 win 65530
>>> +0 accept(3, ..., ...) = 4
>>>
>>> +0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0
>>> +0 write(4, ..., 24) = 24
>>> +0 > P. 1:25(24) ack 1 win 229
>>> +.1 < . 1:1(0) ack 25 win 65530
>>>
>>> //change the ipaddress
>>> +1 `ifconfig tun0 192.168.0.10/16`
>>>
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>>
>>> +0 `ifconfig tun0 192.168.0.1/16`
>>> +0 < . 1:1(0) ack 1 win 1000
>>> +0 write(4, ..., 24) = -1
>>>
>>>
>>
>> This has nothing to do with the code patch you have changed.
>>
>> How have you tested your patch exactly ?
>>
I tested the patch, it can work.
[root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
test.pkt:24: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
real 0m5.356s
user 0m0.026s
sys 0m0.104s
[root@localhost ~]# ss -toenmi src :8080
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 48 192.168.0.1:8080 192.0.2.1:39559 timer:(persist,186ms,2) ino:37178 sk:6 <->
skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:2 rtt:100.253/37.643 mss:1460 cwnd:10 bytes_acked:24 segs_out:5 segs_in:3 send 1.2Mbps lastsnd:976 lastrcv:4082 lastack:3982 pacing_rate 2.3Mbps rcv_space:29200
if change the TCP_USER_TIMEOUT to 30s, test result as below:
[root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
test.pkt:37: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
real 0m44.362s
user 0m0.018s
sys 0m0.110s
ESTAB 0 360 192.168.0.1:8080 192.0.2.1:47577 timer:(persist,516ms,6) ino:18806 sk:5 <->
skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:6 rtt:100.228/37.623 mss:10 bytes_acked:24 segs_out:22 segs_in:3 send 1.2Mbps lastsnd:2343 lastrcv:40450 lastack:40350 pacing_rate 2.3Mbps rcv_sp
>
> lpaa23:~# ss -toenmi src :8080
> State Recv-Q Send-Q Local Address:Port Peer
> Address:Port
> ESTAB 0 144 192.168.134.161:8080
> 192.0.2.1:51165 timer:(persist,8.262ms,5) ino:1
> 82083 sk:3 <->
> skmem:(r0,rb359040,t0,tb46080,f1792,w2304,o0,bl0,d0) sack cubic
> wscale:7,8 rto:301 backoff:5 rtt:100.127/37.576
> mss:1460 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:24 segs_out:12
> segs_in:3 data_segs_out:12 send 1.2Mbps lastsnd:1370 l
> astrcv:13348 lastack:13248 pacing_rate 2.3Mbps delivery_rate 116.7Kbps
> app_limited busy:11346ms rcv_space:29200 notsent:1
> 44 minrtt:100.043userspace application still send data continuously
>
> This is the typical RTO timer, not zero window probe.
>
with the script, it is not zero window; but the code enter tcp_probe_timer.
->tcp_sendmsg
-->tcp_push
---->__tcp_push_pending_frames
------>tcp_write_xmit
-------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
-------->tcp_transmit_skb (send fail, do not advance send head)
------->tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
Here userspace application still send data continuously,
it triggered ICSK_TIME_PROBE0 timer and tcp_send_head(sk)'s timestamp refresh.
^ permalink raw reply
* Re: [Patch net v3 0/3] net_sched: fix filter chain reference counting
From: Jiri Pirko @ 2017-09-13 6:13 UTC (permalink / raw)
To: David Miller; +Cc: xiyou.wangcong, netdev, jiri, jakub.kicinski, jhs
In-Reply-To: <20170912.204118.1990439437521288402.davem@davemloft.net>
Wed, Sep 13, 2017 at 05:41:18AM CEST, davem@davemloft.net wrote:
>From: Cong Wang <xiyou.wangcong@gmail.com>
>Date: Mon, 11 Sep 2017 16:33:29 -0700
>
>> This patchset fixes tc filter chain reference counting and nasty race
>> conditions with RCU callbacks. Please see each patch for details.
>
>Series applied, thanks Cong.
Ha, so after :)
^ permalink raw reply
* Re: [Patch net v3 1/3] net_sched: get rid of tcfa_rcu
From: Jiri Pirko @ 2017-09-13 6:13 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jiri Pirko, Jakub Kicinski,
Jamal Hadi Salim, Eric Dumazet
In-Reply-To: <CAM_iQpUwC6cMBOVuwgCsE+wL88OeL04qw2vSN7_Ng6_GCA5A=g@mail.gmail.com>
Tue, Sep 12, 2017 at 11:53:09PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, Sep 12, 2017 at 2:36 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Sep 12, 2017 at 11:10:22PM CEST, xiyou.wangcong@gmail.com wrote:
>>>On Tue, Sep 12, 2017 at 3:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> This patch helps:
>>>
>>>Looks good to me. Please feel free to submit a formal patch.
>>
>> Okay, I will send the patch to you formally so you can add it as a first
>> patch of your patchset.
>
>I can carry it by myself if it fits to this patchset. However, I believe it
>should be independent since it has to be backported much further
>than this patchset. I don't know why no one triggered the crash
>before call_rcu() was introduced there.
>
>Anyway, I believe you should submit your patch alone, either before
>or after this patchset, there should be no conflict.
Okay. Will to it before the patchset. Thanks!
^ permalink raw reply
* Dear Talented
From: Kim Sharma @ 2017-09-13 2:33 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Anubis (Anubis 2018) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: Blueskyanimatedstudio@usa.com
All Reply to: Blueskyanimatedstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.
Talent Scout
Kim Sharma
^ permalink raw reply
* Re: [PATCH] w90p910_ether: include linux/interrupt.h
From: David Miller @ 2017-09-13 3:59 UTC (permalink / raw)
To: arnd; +Cc: mcuos.com, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20170912123227.3418786-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 12 Sep 2017 14:31:48 +0200
> A randconfig build caused a compile failure:
>
> drivers/net/ethernet/nuvoton/w90p910_ether.c: In function 'w90p910_ether_close':
> drivers/net/ethernet/nuvoton/w90p910_ether.c:580:2: error: implicit declaration of function 'free_irq'; did you mean 'free_uid'? [-Werror=implicit-function-declaration]
>
> Adding the correct include fixes the problem.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: bonding: fix tlb_dynamic_lb default value
From: David Miller @ 2017-09-13 3:59 UTC (permalink / raw)
To: nikolay; +Cc: netdev, j.vosburgh, vfalico, andy, maheshb
In-Reply-To: <1505218205-2637-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 12 Sep 2017 15:10:05 +0300
> Commit 8b426dc54cf4 ("bonding: remove hardcoded value") changed the
> default value for tlb_dynamic_lb which lead to either broken ALB mode
> (since tlb_dynamic_lb can be changed only in TLB) or setting TLB mode
> with tlb_dynamic_lb equal to 0.
> The first issue was recently fixed by setting tlb_dynamic_lb to 1 always
> when switching to ALB mode, but the default value is still wrong and
> we'll enter TLB mode with tlb_dynamic_lb equal to 0 if the mode is
> changed via netlink or sysfs. In order to restore the previous behaviour
> and default value simply remove the mode check around the default param
> initialization for tlb_dynamic_lb which will always set it to 1 as
> before.
>
> Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: Namespaceify tcp_fastopen knob
From: David Miller @ 2017-09-13 3:57 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, netdev, linux-kernel
In-Reply-To: <1505212257-13386-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
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.
^ permalink raw reply
* RE: [PATCH v3] iproute2: add support for GRE ignore-df knob
From: Michele Lucini @ 2017-09-13 3:56 UTC (permalink / raw)
To: Philip Prindeville, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <C28C1CD8-95FD-43C6-86DA-0C89D3776668@redfish-solutions.com>
Guys, thanks heaps for this, much appreciated!
Cheers.
Mike
-----Original Message-----
From: Philip Prindeville [mailto:philipp@redfish-solutions.com]
Sent: Friday, 21 July 2017 10:35 AM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org; Michele Lucini <mlucini@safearea.com.au>
Subject: Re: [PATCH v3] iproute2: add support for GRE ignore-df knob
> On Jul 20, 2017, at 6:26 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Thu, 20 Jul 2017 13:06:10 -0600
> "Philip Prindeville" <philipp@redfish-solutions.com> wrote:
>
>> From: Philip Prindeville <philipp@redfish-solutions.com>
>>
>> In the presence of firewalls which improperly block ICMP Unreachable
>> (including Fragmentation Required) messages, Path MTU Discovery is
>> prevented from working.
>>
>> The workaround is to handle IPv4 payloads opaquely, ignoring the DF
>> bit.
>>
>> Kernel commit 22a59be8b7693eb2d0897a9638f5991f2f8e4ddd ("net: ipv4:
>> Add ability to have GRE ignore DF bit in IPv4 payloads") is
>> complemented by this user-space changeset which exposes control of
>> this setting.
>>
>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
>
> Applied, thanks Philip
Thanks! Sorry I didn’t realize that the first submission a year ago hadn’t been applied and it took me this long to redux and resubmit it.
Michele: hopefully this comes out in your distro-of-choice fairly soon. Like I said, I thought this had already been rolled in.
-Philip
^ permalink raw reply
* Re: [PATCH v4 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode
From: David Miller @ 2017-09-13 3:45 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, yoshfuji, netdev, linux-kernel, ast
In-Reply-To: <1505209677-12728-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 12 Sep 2017 17:47:57 +0800
> In collect_md mode, if the tun dev is down, it still can call
> __ip6_tnl_rcv to receive on packets, and the rx statistics increase
> improperly.
>
> When the md tunnel is down, it's not neccessary to increase RX drops
> for the tunnel device, packets would be recieved on fallback tunnel,
> and the RX drops on fallback device will be increased as expected.
>
> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
> Cc: Alexei Starovoitov <ast@fb.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode
From: David Miller @ 2017-09-13 3:45 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, yoshfuji, netdev, linux-kernel, pshelar
In-Reply-To: <1505209677-12728-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 12 Sep 2017 17:47:56 +0800
> In collect_md mode, if the tun dev is down, it still can call
> ip_tunnel_rcv to receive on packets, and the rx statistics increase
> improperly.
>
> When the md tunnel is down, it's not neccessary to increase RX drops
> for the tunnel device, packets would be recieved on fallback tunnel,
> and the RX drops on fallback device will be increased as expected.
>
> Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
> Cc: Pravin B Shelar <pshelar@nicira.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ 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