* Re: [patch net-next] team: add support for non-ethernet devices
From: David Miller @ 2012-08-20 9:42 UTC (permalink / raw)
To: jiri; +Cc: netdev
In-Reply-To: <1345212048-1378-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 17 Aug 2012 16:00:48 +0200
> This is resolved by two things:
> 1) allow dev_addr of different length than ETH_ALEN
> 2) during port add, check for dev->type and change it if necessary
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Looks good, applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH v1.1] af_packet: don't emit packet on orig fanout group
From: David Miller @ 2012-08-20 9:37 UTC (permalink / raw)
To: eric; +Cc: netdev
In-Reply-To: <1345190578-28722-1-git-send-email-eric@regit.org>
From: Eric Leblond <eric@regit.org>
Date: Fri, 17 Aug 2012 10:02:58 +0200
> If a packet is emitted on one socket in one group of fanout sockets,
> it is transmitted again. It is thus read again on one of the sockets
> of the fanout group. This result in a loop for software which
> generate packets when receiving one.
> This retransmission is not the intended behavior: a fanout group
> must behave like a single socket. The packet should not be
> transmitted on a socket if it originates from a socket belonging
> to the same fanout group.
>
> This patch fixes the issue by changing the transmission check to
> take fanout group info account.
>
> Reported-by: Aleksandr Kotov <a1k@mail.ru>
> Signed-off-by: Eric Leblond <eric@regit.org>
Applied, thanks a lot Eric.
^ permalink raw reply
* Re: [PATCH 0/3] fix error return code
From: David Miller @ 2012-08-20 9:33 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1345189618-13758-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Fri, 17 Aug 2012 09:46:55 +0200
> These patches fix cases where the return code appears to be unintentially
> nonnegative.
All applied, thanks Julia.
^ permalink raw reply
* Re: [net-next 0/9][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-08-20 9:31 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: netdev, gospo, sassmann
In-Reply-To: <1345157318-23731-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Thu, 16 Aug 2012 15:48:29 -0700
> This series contains multiple updates to the ixgbe driver.
>
> The following are changes since commit 02644a17457414f38e29f32d5c640b06d08fa092:
> sctp: fix bogus if statement in sctp_auth_recv_cid()
>
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ppwaskie/net-next master
Pulled, thanks a lot PJ.
^ permalink raw reply
* Re: regression with poll(2)
From: Eric Dumazet @ 2012-08-20 9:30 UTC (permalink / raw)
To: Mel Gorman
Cc: Sage Weil, davem, netdev, linux-kernel, ceph-devel, neilb,
a.p.zijlstra, michaelc, emunson, sebastian, cl, akpm, torvalds
In-Reply-To: <20120820090443.GA3275@suse.de>
On Mon, 2012-08-20 at 10:04 +0100, Mel Gorman wrote:
> Can the following patch be tested please? It is reported to fix an fio
> regression that may be similar to what you are experiencing but has not
> been picked up yet.
>
> -
This seems to help here.
Boot your machine with "mem=768M" or a bit less depending on your setup,
and try a netperf.
-> before patch :
# netperf
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
localhost.localdomain () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 14.00 6.05
-> after patch :
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 18509.73
^ permalink raw reply
* Re: [RFC PATCH net-next 0/9] tipc: misc updates for 3.7
From: David Miller @ 2012-08-20 9:27 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, jon.maloy, ying.xue
In-Reply-To: <1345154954-12526-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 16 Aug 2012 18:09:05 -0400
> This series gets some more largely trivial things out of
> the way. Most interesting are:
>
> 1) fix lockdep splat from bearer init by pushing the setup
> off to schedule_work.
>
> 2) simplification of configuration by removal of a couple of
> tuning knobs which used to have low default values.
>
> The remainder are largely innocuous, I think. I did wonder
> if there was an alternate/better way to handle the splat though.
>
> I've done my own local testing of this series on today's net-next
> commit 2ea214929d601 ("Merge branch 'for-davem' ... wireless-next")
>
> I'll wait a couple of days to allow for any possible feedback and
> change requests, and then send a pull request after that.
All applied, thanks Paul.
It's less useful for you to build the GIT tree "later", at least for
me.
If the patches are good and there is no feedback asking for changes,
I want to be able to just pull them into my tree immediately as I
did here.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/2] packet: Report fanout and rings via diag
From: David Miller @ 2012-08-20 9:23 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <502D125A.40701@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 16 Aug 2012 19:31:38 +0400
> After this the packet diag module reports everything that can be
> configured on a packet socket via AF_PACKET-specific API.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [patch] gre: information leak in ip6_tnl_ioctl()
From: David Miller @ 2012-08-20 9:21 UTC (permalink / raw)
To: dan.carpenter
Cc: xeb, kuznet, jmorris, yoshfuji, kaber, netdev, kernel-janitors
In-Reply-To: <20120816131404.GA23188@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 16 Aug 2012 16:14:04 +0300
> There is a one byte hole between p->hop_limit and p->flowinfo where
> stack memory is leaked to the user. This was introduced in c12b395a46
> "gre: Support GRE over IPv6".
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH] smsc75xx: add missing entry to MAINTAINERS
From: David Miller @ 2012-08-20 9:20 UTC (permalink / raw)
To: steve.glendinning; +Cc: linux-kernel, netdev, trivial
In-Reply-To: <1345103618-22753-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Thu, 16 Aug 2012 08:53:38 +0100
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Applied.
^ permalink raw reply
* Re: [PATCH 001/001] smsc95xx: Fix hard_header_len
From: David Miller @ 2012-08-20 9:19 UTC (permalink / raw)
To: steve; +Cc: bhutchings, jimbob.betts, netdev
In-Reply-To: <CAKh2mn6fr8WjT-2h_A3zmKv3xs26AamXcpJgtK5wFPQ1BXuheg@mail.gmail.com>
From: Steve Glendinning <steve@shawell.net>
Date: Fri, 17 Aug 2012 09:35:04 +0100
>> hard_header_len is set to ETH_HLEN by alloc_etherdev() (in the
>> ether_setup() callback). Any extra headroom you want before the
>> Ethernet header should indeed be specified in needed_headroom.
>
> Thanks Ben, looks like this patch is doing it the right way then.
>
> Acked-By: Steve Glendinning <steve.glendinning@shawell.net>
This patch needs to be submitted with a proper signoff.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: new devices: UML290 and K5006-Z
From: David Miller @ 2012-08-20 9:17 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
dcbw-H+wXaHxf7aLQT0dZR+AlfA, tschaefer-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <1345038177-29189-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Wed, 15 Aug 2012 15:42:57 +0200
> Newer firmware versions for the Pantech UML290 use a different
> subclass ID. The Windows driver match on both IDs, so we do
> that as well.
>
> The ZTE (Vodafone) K5006-Z is a new device.
>
> Cc: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Thomas Schäfer <tschaefer-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Add eth support for R8A7779 device
From: David Miller @ 2012-08-20 9:17 UTC (permalink / raw)
To: phil.edworthy
Cc: netdev, linux-sh, kuninori.morimoto.gx, yoshihiro.shimoda.uh
In-Reply-To: <1345012409-12915-1-git-send-email-phil.edworthy@renesas.com>
From: Phil Edworthy <phil.edworthy@renesas.com>
Date: Wed, 15 Aug 2012 07:33:29 +0100
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] [v2] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-20 9:16 UTC (permalink / raw)
To: timur; +Cc: grant.likely, david.daney, netdev, devicetree-discuss
In-Reply-To: <1344986424-14360-2-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 18:20:24 -0500
> The mdio-mux driver scans all child mdio nodes, without regard to whether
> the node is actually used. Some device trees include all possible
> mdio-mux nodes and rely on the boot loader to disable those that are not
> present, based on some run-time configuration. Those nodes need to be
> skipped.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] dt: introduce for_each_available_child_of_node, of_get_next_available_child
From: David Miller @ 2012-08-20 9:16 UTC (permalink / raw)
To: timur; +Cc: grant.likely, david.daney, netdev, devicetree-discuss
In-Reply-To: <1344986424-14360-1-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 18:20:23 -0500
> Macro for_each_child_of_node() makes it easy to iterate over all of the
> children for a given device tree node, including those nodes that are
> marked as unavailable (i.e. status = "disabled").
>
> Introduce for_each_available_child_of_node(), which is like
> for_each_child_of_node(), but it automatically skips unavailable nodes.
> This also requires the introduction of helper function
> of_get_next_available_child(), which returns the next available child
> node.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied.
^ permalink raw reply
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Cong Wang @ 2012-08-20 9:06 UTC (permalink / raw)
To: Michal Kubeček
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Shan Wei, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <1826853.rak2U42CMU@alaris>
Hi, Michal!
On Fri, 2012-08-17 at 19:05 +0200, Michal Kubeček wrote:
> On Friday 17 of August 2012 16:02EN, Cong Wang wrote:
> > Two years ago, Shan Wei tried to fix this:
> > http://patchwork.ozlabs.org/patch/43905/
> >
> ...
> >
> > As Herbert suggested, we could actually use the standard IPv6
> > reassembly code which follows RFC2460.
>
> I tested the patch and I ran into a problem in this place in
> ip6_expire_frag_queue():
>
> > net = container_of(fq->q.net, struct net, ipv6.frags);
>
> For frag queues coming from IPv6 conntrack, fq->q.net points to
> nf_init_frags which is not embedded into struct net so that the
> following device lookup leads to reading from an invalid address.
> The same problem has been discussed on the page linked above.
>
> I didn't test with current net-next source but as far as I can tell,
> this hasn't changed. Did I miss something?
>
No, you don't miss anything. I missed that piece of code, you are right
that nf_init_frags is not actually embedded, so that container_of()
doesn't work. I think we probably can save the struct net pointer in
struct netns_frags during inet_frags_init_net(), so that container_of()
can be eliminated.
Thanks for testing! I tried to test it too, but seems I can't trigger a
defragment. Any hints?
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: regression with poll(2)
From: Mel Gorman @ 2012-08-20 9:04 UTC (permalink / raw)
To: Sage Weil
Cc: davem, netdev, linux-kernel, ceph-devel, neilb, a.p.zijlstra,
michaelc, emunson, eric.dumazet, sebastian, cl, akpm, torvalds
In-Reply-To: <alpine.DEB.2.00.1208191051150.15570@cobra.newdream.net>
On Sun, Aug 19, 2012 at 11:49:31AM -0700, Sage Weil wrote:
> I've bisected and identified this commit:
>
> netvm: propagate page->pfmemalloc to skb
>
> The skb->pfmemalloc flag gets set to true iff during the slab allocation
> of data in __alloc_skb that the the PFMEMALLOC reserves were used. If the
> packet is fragmented, it is possible that pages will be allocated from the
> PFMEMALLOC reserve without propagating this information to the skb. This
> patch propagates page->pfmemalloc from pages allocated for fragments to
> the skb.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: David S. Miller <davem@davemloft.net>
> Cc: Neil Brown <neilb@suse.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: Eric B Munson <emunson@mgebm.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Christoph Lameter <cl@linux.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
Ok, thanks.
> I've retested several times and confirmed that this change leads to the
> breakage, and also confirmed that reverting it on top of -rc1 also fixes
> the problem.
>
> I've also added some additional instrumentation to my code and confirmed
> that the process is blocking on poll(2) while netstat is reporting
> data available on the socket.
>
> What can I do to help track this down?
>
Can the following patch be tested please? It is reported to fix an fio
regression that may be similar to what you are experiencing but has not
been picked up yet.
---8<---
From: Alex Shi <alex.shi@intel.com>
Subject: [PATCH] mm: correct page->pfmemalloc to fix deactivate_slab regression
commit cfd19c5a9ec (mm: only set page->pfmemalloc when
ALLOC_NO_WATERMARKS was used) try to narrow down page->pfmemalloc
setting, but it missed some places the pfmemalloc should be set.
So, in __slab_alloc, the unalignment pfmemalloc and ALLOC_NO_WATERMARKS
cause incorrect deactivate_slab() on our core2 server:
64.73% fio [kernel.kallsyms] [k] _raw_spin_lock
|
--- _raw_spin_lock
|
|---0.34%-- deactivate_slab
| __slab_alloc
| kmem_cache_alloc
| |
That causes our fio sync write performance has 40% regression.
This patch move the checking in get_page_from_freelist, that resolved
this issue.
Signed-off-by: Alex Shi <alex.shi@intel.com>
---
mm/page_alloc.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 009ac28..07f1924 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1928,6 +1928,17 @@ this_zone_full:
zlc_active = 0;
goto zonelist_scan;
}
+
+ if (page)
+ /*
+ * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
+ * necessary to allocate the page. The expectation is
+ * that the caller is taking steps that will free more
+ * memory. The caller should avoid the page being used
+ * for !PFMEMALLOC purposes.
+ */
+ page->pfmemalloc = !!(alloc_flags & ALLOC_NO_WATERMARKS);
+
return page;
}
@@ -2389,14 +2400,6 @@ rebalance:
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
if (page) {
- /*
- * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
- * necessary to allocate the page. The expectation is
- * that the caller is taking steps that will free more
- * memory. The caller should avoid the page being used
- * for !PFMEMALLOC purposes.
- */
- page->pfmemalloc = true;
goto got_pg;
}
}
@@ -2569,8 +2572,6 @@ retry_cpuset:
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
- else
- page->pfmemalloc = false;
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 09/18] netfilter: ipv6: add IPv6 NAT support
From: Jan Engelhardt @ 2012-08-20 9:03 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-10-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>+static struct nf_hook_ops nf_nat_ipv6_ops[] __read_mostly = {
>+ /* Before packet filtering, change destination */
>+ {
>+ .hook = nf_nat_ipv6_in,
>+ .owner = THIS_MODULE,
>+ .pf = NFPROTO_IPV6,
>+ .hooknum = NF_INET_PRE_ROUTING,
>+ .priority = NF_IP_PRI_NAT_DST,
NF_IP6_PRI_NAT_DST
>+ .hook = nf_nat_ipv6_out,
>+ .owner = THIS_MODULE,
>+ .pf = NFPROTO_IPV6,
>+ .hooknum = NF_INET_POST_ROUTING,
>+ .priority = NF_IP_PRI_NAT_SRC,
IP6 too... (2 more occurrences)
>+static void nf_nat_ipv6_csum_recalc(struct sk_buff *skb,
>+ u8 proto, void *data, __sum16 *check,
>+ int datalen, int oldlen)
>+{
>+ const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
>+ struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
>+
>+ if (skb->ip_summed != CHECKSUM_PARTIAL) {
Maybe invert to == CHECKSUM_PARTIAL like in p06/18.
^ permalink raw reply
* Re: [PATCH 06/18] netfilter: add protocol independant NAT core
From: Jan Engelhardt @ 2012-08-20 8:57 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-7-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>
> enum ctattr_nat {
> CTA_NAT_UNSPEC,
>- CTA_NAT_MINIP,
>- CTA_NAT_MAXIP,
>+ CTA_NAT_V4_MINIP,
>+#define CTA_NAT_MINIP CTA_NAT_V4_MINIP
>+ CTA_NAT_V4_MAXIP,
>+#define CTA_NAT_MAXIP CTA_NAT_V4_MAXIP
> CTA_NAT_PROTO,
> __CTA_NAT_MAX
> };
One could also
enum ctattr_nat {
...
__CTA_NAT_MAX,
CTA_NAT_MINIP = CTA_NAT_V4_MINIP,
CTA_NAT_MAXIP = CTA_NAT_V4_MAXIP,
};
to provide the old names.
>diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
>index fcc543c..33372a1 100644
>--- a/net/ipv4/netfilter/Kconfig
>+++ b/net/ipv4/netfilter/Kconfig
[...]
>
>-config NF_NAT_NEEDED
>- bool
>- depends on NF_NAT
>- default y
>-
Could add "if NF_NAT_IPV4".."endif" block as appropriate around here,
to save on all the extra "depend on NF_NAT_IPV4" clauses.
> config IP_NF_TARGET_MASQUERADE
> tristate "MASQUERADE target support"
>- depends on NF_NAT
>+ depends on NF_NAT_IPV4
> default m if NETFILTER_ADVANCED=n
> help
> Masquerading is a special case of NAT: all outgoing connections are
>+static int nf_nat_ipv4_in_range(const struct nf_conntrack_tuple *t,
>+ const struct nf_nat_range *range)
>+{
>+ return ntohl(t->src.u3.ip) >= ntohl(range->min_addr.ip) &&
>+ ntohl(t->src.u3.ip) <= ntohl(range->max_addr.ip);
>+}
static bool ..
>+static bool nf_nat_ipv4_manip_pkt(struct sk_buff *skb,
>+ unsigned int iphdroff,
>+ const struct nf_nat_l4proto *l4proto,
>+ const struct nf_conntrack_tuple *target,
>+ enum nf_nat_manip_type maniptype)
>+{
>+ struct iphdr *iph;
>+ unsigned int hdroff;
>+
>+ if (!skb_make_writable(skb, iphdroff + sizeof(*iph)))
>+ return false;
>+
>+ iph = (void *)skb->data + iphdroff;
Is iph = ip_hdr(skb), hdroff = iphdroff+skb_iphdrlen(iph) not usable here?
>+ hdroff = iphdroff + iph->ihl * 4;
>+
>+ if (!l4proto->manip_pkt(skb, &nf_nat_l3proto_ipv4, iphdroff, hdroff,
>+ target, maniptype))
>+ return false;
>+ iph = (void *)skb->data + iphdroff;
Is trying to avoid some GNU extensions a worthwhile goal? If so,
iph = (struct iphdr *)(skb->data + iphdroff) should be used, like in:
>+static void nf_nat_ipv4_csum_update(struct sk_buff *skb,
>+ unsigned int iphdroff, __sum16 *check,
>+ const struct nf_conntrack_tuple *t,
>+ enum nf_nat_manip_type maniptype)
>+{
>+ struct iphdr *iph = (struct iphdr *)(skb->data + iphdroff);
>[...]
>+}
>+static void nf_nat_ipv4_csum_recalc(struct sk_buff *skb,
>+ u8 proto, void *data, __sum16 *check,
>+ int datalen, int oldlen)
>+{
>+ const struct iphdr *iph = ip_hdr(skb);
>+ struct rtable *rt = skb_rtable(skb);
>+
>+ if (skb->ip_summed != CHECKSUM_PARTIAL) {
>+ if (!(rt->rt_flags & RTCF_LOCAL) &&
>+ (!skb->dev || skb->dev->features & NETIF_F_V4_CSUM)) {
>+ skb->ip_summed = CHECKSUM_PARTIAL;
>+ skb->csum_start = skb_headroom(skb) +
>+ skb_network_offset(skb) +
>+ ip_hdrlen(skb);
>+ skb->csum_offset = (void *)check - data;
>+ *check = ~csum_tcpudp_magic(iph->saddr, iph->daddr,
>+ datalen, proto, 0);
>+ } else {
>+ *check = 0;
>+ *check = csum_tcpudp_magic(iph->saddr, iph->daddr,
>+ datalen, proto,
>+ csum_partial(data, datalen,
>+ 0));
>+ if (proto == IPPROTO_UDP && !*check)
>+ *check = CSUM_MANGLED_0;
>+ }
>+ } else
>+ inet_proto_csum_replace2(check, skb,
>+ htons(oldlen), htons(datalen), 1);
>+}
Here is a style factory trick: invert the condition such that the
simple case is first, and the big one becomes an else if
with a reduced indent:
if (skb->ip_summed == CHECKSUM_PARTIAL) {
inet_proto_csum_replace2(check, skb,
htons(oldlen), htons(datalen), 1);
} else if (!(rt->rt_flags & RTCF_LOCAL) &&
(!skb->dev || skb->dev->features & NETIF_F_V4_CSUM)) {
skb->ip_summed = CHECKSUM_PARTIAL;
skb->csum_start = skb_headroom(skb) +
skb_network_offset(skb) +
ip_hdrlen(skb);
skb->csum_offset = (void *)check - data;
*check = ~csum_tcpudp_magic(iph->saddr, iph->daddr,
datalen, proto, 0);
} else {
*check = 0;
*check = csum_tcpudp_magic(iph->saddr, iph->daddr,
datalen, proto,
csum_partial(data, datalen,
0));
if (proto == IPPROTO_UDP && !*check)
*check = CSUM_MANGLED_0;
}
>+static void __exit nf_nat_l3proto_ipv4_exit(void)
>+{
>+ nf_nat_l3proto_unregister(&nf_nat_l3proto_ipv4);
>+ nf_nat_l4proto_unregister(NFPROTO_IPV4, &nf_nat_l4proto_icmp);
>+}
>+
>+MODULE_LICENSE("GPL");
>+MODULE_ALIAS("nf-nat-" __stringify(AF_INET));
Technically, this would have to be NFPROTO_IPV4, though GNU C has yet
to gain an extension to stringify enum constants..
>+ /* 1) If this srcip/proto/src-proto-part is currently mapped,
>+ * and that same mapping gives a unique tuple within the given
>+ * range, use that.
>+ *
>+ * This is only required for source (ie. NAT/masq) mappings.
>+ * So far, we don't do local source mappings, so multiple
>+ * manips not an issue.
manips are not an issue.
>- /* nf_conntrack_alter_reply might re-allocate extension area */
>+ /* nf_conntrack_alter_reply might re-allocate exntension aera */
extension was correct :)
>+ {
>+ .name = "SNAT",
>+ .revision = 1,
>+ .target = xt_snat_target_v1,
>+ .targetsize = sizeof(struct nf_nat_range),
>+ .table = "nat",
>+ .hooks = (1 << NF_INET_POST_ROUTING) |
>+ (1 << NF_INET_LOCAL_OUT),
>+ .me = THIS_MODULE,
.family = NFPROTO_UNSPEC,
Just for completeness.
^ permalink raw reply
* APPROVED OF PAYMENT
From: BARCLAYS BANK UNITED KINGDOM @ 2012-08-20 8:37 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: BARCLAYS BANK UNITED KINGDOM RE CONFIRMATION OF PAYMENT FUND.doc --]
[-- Type: application/msword, Size: 80896 bytes --]
^ permalink raw reply
* [PATCH] iproute: Fix errno propagation from rtnl_talk
From: Pavel Emelyanov @ 2012-08-20 8:08 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
Callers of rtnl_talk check errno value for their needs. In particular, the addrs
and routes restoring code validly reports success if the EEXISTS is in there.
However, the errno value can be sometimes screwed up by the perror call. Thus
we should only set it _after_ the message was emitted.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 878911e..8e8c8b9 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -360,13 +360,14 @@ int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n, pid_t peer,
if (l < sizeof(struct nlmsgerr)) {
fprintf(stderr, "ERROR truncated\n");
} else {
- errno = -err->error;
- if (errno == 0) {
+ if (!err->error) {
if (answer)
memcpy(answer, h, h->nlmsg_len);
return 0;
}
- perror("RTNETLINK answers");
+
+ fprintf(stderr, "RTNETLINK answers: %s\n", strerror(-err->error));
+ errno = -err->error;
}
return -1;
}
^ permalink raw reply related
* Re: regression with poll(2)
From: Eric Dumazet @ 2012-08-20 8:07 UTC (permalink / raw)
To: Sage Weil
Cc: mgorman, davem, netdev, linux-kernel, ceph-devel, neilb,
a.p.zijlstra, michaelc, emunson, sebastian, cl, akpm, torvalds
In-Reply-To: <alpine.DEB.2.00.1208191051150.15570@cobra.newdream.net>
On Sun, 2012-08-19 at 11:49 -0700, Sage Weil wrote:
> I've bisected and identified this commit:
>
> netvm: propagate page->pfmemalloc to skb
>
> The skb->pfmemalloc flag gets set to true iff during the slab allocation
> of data in __alloc_skb that the the PFMEMALLOC reserves were used. If the
> packet is fragmented, it is possible that pages will be allocated from the
> PFMEMALLOC reserve without propagating this information to the skb. This
> patch propagates page->pfmemalloc from pages allocated for fragments to
> the skb.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: David S. Miller <davem@davemloft.net>
> Cc: Neil Brown <neilb@suse.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: Eric B Munson <emunson@mgebm.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Christoph Lameter <cl@linux.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> I've retested several times and confirmed that this change leads to the
> breakage, and also confirmed that reverting it on top of -rc1 also fixes
> the problem.
>
> I've also added some additional instrumentation to my code and confirmed
> that the process is blocking on poll(2) while netstat is reporting
> data available on the socket.
>
> What can I do to help track this down?
>
> Thanks!
> sage
>
>
> On Wed, 15 Aug 2012, Sage Weil wrote:
>
> > I'm experiencing a stall with Ceph daemons communicating over TCP that
> > occurs reliably with 3.6-rc1 (and linus/master) but not 3.5. The basic
> > situation is:
> >
> > - the socket is two processes communicating over TCP on the same host, e.g.
> >
> > tcp 0 2164849 10.214.132.38:6801 10.214.132.38:51729 ESTABLISHED
> >
> > - one end writes a bunch of data in
> > - the other end consumes data, but at some point stalls.
> > - reads are nonblocking, e.g.
> >
> > int got = ::recv( sd, buf, len, MSG_DONTWAIT );
> >
> > and between those calls we wait with
> >
> > struct pollfd pfd;
> > short evmask;
> > pfd.fd = sd;
> > pfd.events = POLLIN;
> > #if defined(__linux__)
> > pfd.events |= POLLRDHUP;
> > #endif
> >
> > if (poll(&pfd, 1, msgr->timeout) <= 0)
> > return -1;
> >
> > - in my case the timeout is ~15 minutes. at that point it errors out,
> > and the daemons reconnect and continue for a while until hitting this
> > again.
> >
> > - at the time of the stall, the reading process is blocked on that
> > poll(2) call. There are a bunch of threads stuck on poll(2), some of them
> > stuck and some not, but they all have stacks like
> >
> > [<ffffffff8118f6f9>] poll_schedule_timeout+0x49/0x70
> > [<ffffffff81190baf>] do_sys_poll+0x35f/0x4c0
> > [<ffffffff81190deb>] sys_poll+0x6b/0x100
> > [<ffffffff8163d369>] system_call_fastpath+0x16/0x1b
> >
> > - you'll note that the netstat output shows data queued:
> >
> > tcp 0 1163264 10.214.132.36:6807 10.214.132.36:41738 ESTABLISHED
> > tcp 0 1622016 10.214.132.36:41738 10.214.132.36:6807 ESTABLISHED
> >
In this netstat output, we can see some data in output queues, but no
data on receive queues. poll() is OK.
Some TCP frames are not properly delivered, even after a retransmit.
( to see useful stats/counters : ss -emoi dst 10.214.132.36)
For loopback transmits, skbs are taken from the output queue, cloned and
feeded to local stack.
If they have the pfmemalloc bit, they wont be delivered to normal
sockets, but dropped.
tcp_sendmsg() seems to be able to queue skbs with pfmemalloc set to
true, and this makes no sense to me.
^ permalink raw reply
* Re: [PATCH 1/2] iproute: Add magic cookie to route dump file
From: Pavel Emelyanov @ 2012-08-20 8:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <20120817134943.6f26a75e@nehalam.linuxnetplumber.net>
On 08/18/2012 12:49 AM, Stephen Hemminger wrote:
> On Fri, 27 Jul 2012 08:55:41 +0400
> Pavel Emelyanov <xemul@parallels.com> wrote:
>
>> In order to somehow verify that a blob contains route dump a
>> 4-bytes magic is put at the head of the data and is checked
>> on restore.
>>
>> Magic digits are taken from Portland (OR) coordinates :) Is
>> there any more reliable way of generating such?
>>
>> Signed-of-by: Pavel Emelyanov <xemul@parallels.com>
>
> I am planning on putting this in because there were no objections.
> Any followup updates?
Yes, I've recently found that errno propagation from rtnl_talk up to
addrs/routes restore doesn't work on some libc-s. I will post a fixing
patch soon.
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH 01/18] ipv4: fix path MTU discovery with connection tracking
From: Jan Engelhardt @ 2012-08-20 8:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-2-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>IPv4 conntrack defragments incoming packet at the PRE_ROUTING hook and
>(in case of forwarded packets) refragments them at POST_ROUTING
>independant of the IP_DF flag.
"independent". (also in 06/18)
^ permalink raw reply
* Re: [PATCH 05/18] netfilter: nf_nat: add protoff argument to packet mangling functions
From: Jan Engelhardt @ 2012-08-20 8:02 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-6-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>index 0bb5a69..4b59a15 100644
>--- a/include/linux/netfilter/nf_conntrack_amanda.h
>+++ b/include/linux/netfilter/nf_conntrack_amanda.h
>@@ -4,6 +4,7 @@
>
> extern unsigned int (*nf_nat_amanda_hook)(struct sk_buff *skb,
> enum ip_conntrack_info ctinfo,
>+ unsigned int protoff,
> unsigned int matchoff,
> unsigned int matchlen,
> struct nf_conntrack_expect *exp);
What about using a structure to collect all the accumulating parameters,
like we do for xtables match functions?
^ permalink raw reply
* Re: [PATCH 01/18] ipv4: fix path MTU discovery with connection tracking
From: Eric Dumazet @ 2012-08-20 7:41 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-2-git-send-email-kaber@trash.net>
On Mon, 2012-08-20 at 05:39 +0200, Patrick McHardy wrote:
> IPv4 conntrack defragments incoming packet at the PRE_ROUTING hook and
> (in case of forwarded packets) refragments them at POST_ROUTING
> independant of the IP_DF flag. Refragmentation uses the dst_mtu() of
> the local route without caring about the original fragment sizes,
> thereby breaking PMTUD.
>
> This patch fixes this by keeping track of the largest received fragment
> with IP_DF set and generates an ICMP fragmentation required error during
> refragmentation if that size exceeds the MTU.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> ---
Acked-by: Eric Dumazet <edumazet@google.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