* Re: [PATCH] iproute2: ss - change default filter to include all socket types
From: David Miller @ 2012-12-11 17:45 UTC (permalink / raw)
To: contyk; +Cc: shemminger, netdev
In-Reply-To: <1355244172-32071-1-git-send-email-contyk@redhat.com>
From: Petr Šabata <contyk@redhat.com>
Date: Tue, 11 Dec 2012 17:42:52 +0100
> Currently the default filter lists TCP sockets only which is
> rather confusing especially when the '-a/--all' flag is used.
> This patch changes the default to include all sockets, imitating
> netstat(8) behavior.
>
> Signed-off-by: Petr Šabata <contyk@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] tun: allow setting ethernet addresss while running
From: David Miller @ 2012-12-11 17:50 UTC (permalink / raw)
To: shemminger; +Cc: netdev, jasowang
In-Reply-To: <1355188560-8388-1-git-send-email-shemminger@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 10 Dec 2012 17:16:00 -0800
> This is a pure software device, and ok with live address change.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix a race in gro_cell_poll()
From: David Miller @ 2012-12-11 17:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: dmitry, netdev
In-Reply-To: <1355178723.27891.85.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Dec 2012 14:32:03 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Dmitry Kravkov reported packet drops for GRE packets since GRO support
> was added.
>
> There is a race in gro_cell_poll() because we call napi_complete()
> without any synchronization with a concurrent gro_cells_receive()
>
> Once bug was triggered, we queued packets but did not schedule NAPI
> poll.
>
> We can fix this issue using the spinlock protected the napi_skbs queue,
> as we have to hold it to perform skb dequeue anyway.
>
> As we open-code skb_dequeue(), we no longer need to mask IRQS, as both
> producer and consumer run under BH context.
>
> Bug added in commit c9e6bc644e (net: add gro_cells infrastructure)
>
> Reported-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: use netdev_alloc_frag()
From: David Miller @ 2012-12-11 17:51 UTC (permalink / raw)
To: dmitry; +Cc: eric.dumazet, netdev, eilong
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1BFC4273@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 10 Dec 2012 22:57:44 +0000
>> -----Original Message-----
>> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: Tuesday, December 11, 2012 12:16 AM
>> To: David Miller
>> Cc: netdev; Eilon Greenstein; Dmitry Kravkov
>> Subject: [PATCH net-next] bnx2x: use netdev_alloc_frag()
>>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Using netdev_alloc_frag() instead of kmalloc() permits better GRO or
>> TCP coalescing behavior, as skb_gro_receive() doesn't have to fallback
>> to frag_list overhead.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Dmitry Kravkov <dmitry@broadcom.com>
>> Cc: Eilon Greenstein <eilong@broadcom.com>
>
> Thanks a lot, Eric!
>
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: dev_gro_receive() cleanup
From: David Miller @ 2012-12-11 17:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1355182096.27891.93.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Dec 2012 15:28:16 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> __napi_gro_receive() is inlined from two call sites for no good reason.
>
> Lets move the prep stuff in a function of its own, called only if/when
> needed. This saves 300 bytes on x86 :
>
> # size net/core/dev.o.after net/core/dev.o.before
> text data bss dec hex filename
> 51968 1238 1040 54246 d3e6 net/core/dev.o.before
> 51664 1238 1040 53942 d2b6 net/core/dev.o.after
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: remove obsolete simple_strto<foo>
From: David Miller @ 2012-12-11 17:51 UTC (permalink / raw)
To: abhi.c.pawar
Cc: pablo, kaber, kuznet, jmorris, yoshfuji, linville, johannes,
amwang, edumazet, nhorman, joe, netdev, linux-kernel,
netfilter-devel, netfilter, coreteam, linux-wireless
In-Reply-To: <1355203852-12749-1-git-send-email-abhi.c.pawar@gmail.com>
From: Abhijit Pawar <abhi.c.pawar@gmail.com>
Date: Tue, 11 Dec 2012 11:00:52 +0530
> This patch removes the redundant occurences of simple_strto<foo>
>
> Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 04/10] net: smc911x: use io{read,write}*_rep accessors
From: David Miller @ 2012-12-11 17:51 UTC (permalink / raw)
To: will.deacon
Cc: linux-kernel, linux-arch, benh, arnd, james.hogan, matthew,
netdev
In-Reply-To: <20121211144949.GD16759@mudshark.cambridge.arm.com>
From: Will Deacon <will.deacon@arm.com>
Date: Tue, 11 Dec 2012 14:49:49 +0000
> On Mon, Dec 10, 2012 at 08:47:05PM +0000, David Miller wrote:
>> This misses the two uses in smsc911x_tx_writefifo and
>> smsc911x_rx_readfifo.
>
> Well spotted, updated patch below.
Although I'd like to take credit, the compiler told me :-)
> From b46e33465e755e945136d19938c9a8331cbafce7 Mon Sep 17 00:00:00 2001
> From: Matthew Leach <matthew@mattleach.net>
> Date: Tue, 6 Nov 2012 14:51:11 +0000
> Subject: [PATCH v3] net: smc911x: use io{read,write}*_rep accessors
>
> The {read,write}s{b,w,l} operations are not defined by all
> architectures and are being removed from the asm-generic/io.h
> interface.
>
> This patch replaces the usage of these string functions in the smc911x
> accessors with io{read,write}{8,16,32}_rep calls instead.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Matthew Leach <matthew@mattleach.net>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Applied, thanks.
^ permalink raw reply
* [ANNOUNCE] iproute2 3.7.0
From: Stephen Hemminger @ 2012-12-11 18:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Just in time for the holidays, an update to iproute2 for v3.7 kernel.
In addition to lots of build and documentation fixes, this
version includes support for tcp_metrics and vxlan
documentation and minor bugfixes,
If you have been sitting on changes to iproute2 that are in
net-next for 3.8 merge window, please submit them now.
Iproute2 package is available at:
http://kernel.org/pub/linux/utils/net/iproute2/iproute2-3.7.0.tar.gz
You can download the source from:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Stay Warm!
---
Andreas Henriksson (2):
iproute2: avoid errors from double-installing manpages
iproute2: drop libresolv
Julian Anastasov (1):
iproute2: add support for tcp_metrics
Matt Burgess (1):
iproute2-3.6.0 assumes presence of iptables
Mike Frysinger (1):
allow pkg-config to be customized
Nicolas Dichtel (4):
iproute2: inform user when a neighbor is removed
ip/ip6tunnel: fix help for TCLASS
ip/ip6tunnel: reset encap limit flag on change
ip/ip6tunnel: fix update of tclass and flowlabel
Or Gerlitz (1):
iplink: Added support for the kernel IPoIB RTNL ops
Pavel Emelyanov (4):
ss: Rename some tcp- names into inet-
ss: Split inet_show_netlink into parts
ss: Support sock-diag
ss: Get udp sockets info via sock-diag
Petr Písař (1):
iproute2: List interfaces without net address by default
Petr Sabata (1):
iproute2: ss - change default filter to include all socket types
Rostislav Lisovy (1):
tc: add canid ematch to ematch_map
Stephen Hemminger (12):
vxlan support
bridge: manage VXLAN based forwarding tables
l2tp: remove references to old bridge utils
Update headers to 3.7-pre-rc
vxlan: add support for port range
vxlan: only send group address if defined
Update kernel headers to 3.7-rc1
iplink: add vxlan to man page
bridge: remove trailing whitespace
bridge: use rta_getattr_xxx wrappers
man: fix incorrect use of "it's"
v3.7.0
Vincent Bernat (1):
ip: fix "ip -6 route add ... nexthop"
Wookey (1):
configure: respect $CC environment var override
^ permalink raw reply
* Re: [PATCH RFC 0/5] Containerize syslog
From: Eric W. Biederman @ 2012-12-11 18:22 UTC (permalink / raw)
To: Glauber Costa
Cc: Rui Xiang, Andrew Morton,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <50C6EDF0.5060108-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
> On 12/07/2012 10:05 PM, Eric W. Biederman wrote:
>> Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>>
>>> I keep asking myself if it isn't the case of forwarding to a container
>>> all messages printed in process context. That will obviously exclude all
>>> messages resulting from kthreads - that will always be in the initial
>>> namespace anyway, interrupts, etc. There is no harm, for instance, in
>>> delivering the same message twice: one to the container, and the other
>>> to the host system.
>>
>> Except that there is harm in double printing. One of the better
>> justifications for doing something with the kernel log is that it is
>> possible to overflow the kernel log with operations performed
>> exclusively in a container.
>>
> I don't agree with you here.
>
> If we are double printing, we are using up more memory, but we also have
> an extra buffer anyway. The messages are print on behalf of the user,
> but still, by the kernel.
>
> So one of the following will necessarily hold:
>
> 1) There is no way that the process can overflow the main log, and as a
> consequence, the container log, that has less messages than it.
>
> 2) The process will overflow the main log. But since we are not printing
> anything extra to the main log compared to the scenario in which the
> process lives in the main namespace, this would already be a problem
> independent of namespaces. And needs to be fixed.
Well mounts, brining network interfaces up and down, running packets
through our own choice of firewall rules, possibly enabling debug
messages on network interfaces has the potential to create messages we
aren't seeing today.
> IOW, double printing should not print anything *extra* to the main log.
> It just prints to the container log, and leaves a copy to the box admin
> to see. I think it is very reasonable to imagine that the main admin
> would like to see anything the kernel has to tell him about the box.
The only reason that I have seen for doing anything with printks is
because we are generating messages that would not be generated in a
non-container environment. At which point double printing is scary
because it allows a container user to flood the kernel log ring buffer
and suppress interesting messages.
>> I do think the idea of process context printks going to the current
>> container one worth playing with.
>>
>
> It still leaves the problem of prinkts outside process context that
> should go to a namespace open. But it is easy to extend this idea to do
> both.
Hmm. For printks from process context I think I can see a point where
double printing makes sense, because that is a rather indiscriminate grab
of printk messages.
Eric
^ permalink raw reply
* Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: David Miller @ 2012-12-11 18:30 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-arm-kernel, linux-omap, s.hauer
In-Reply-To: <1355197433-7492-1-git-send-email-mugunthanvnm@ti.com>
You cannot do this.
After your changes the driver no longer does any TX flow control.
It never stops the TX queue and never wakes it up later.
It just drops packets on the floor when it runs out of descriptors.
This breaks everything, and in particular packet schedulers and
TCP.
I'm not applying this.
^ permalink raw reply
* Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: David Miller @ 2012-12-11 18:34 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-arm-kernel, linux-omap, s.hauer
In-Reply-To: <20121211.133058.2238010228178961245.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 11 Dec 2012 13:30:58 -0500 (EST)
>
> You cannot do this.
>
> After your changes the driver no longer does any TX flow control.
>
> It never stops the TX queue and never wakes it up later.
>
> It just drops packets on the floor when it runs out of descriptors.
>
> This breaks everything, and in particular packet schedulers and
> TCP.
>
> I'm not applying this.
And yes I mean that the "fail_tx" path of the transmit method
is bogus too.
You can't signal "out of descriptors" and stop the queue after the
fact. NETDEV_TX_BUSY is for handling exceptional and extraordinary
conditions, not for the normal queue full handling.
You have to stop the queue before you run out of descriptors. When
the queue is not stopped, you are telling the core networking that you
absoultely will be able to successfully queue a packet and enough
descriptors are available.
This means the other CPDMA driver needs to be reworked too.
^ permalink raw reply
* [PATCH net-next] net: gro: avoid double copy in skb_gro_receive()
From: Eric Dumazet @ 2012-12-11 18:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
__copy_skb_header(nskb, p) already copied p->cb[], no need to copy
it again.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ccbabf5..ac9e44a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3028,7 +3028,6 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
memcpy(skb_mac_header(nskb), skb_mac_header(p),
p->data - skb_mac_header(p));
- *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
skb_shinfo(nskb)->frag_list = p;
skb_shinfo(nskb)->gso_size = pinfo->gso_size;
pinfo->gso_size = 0;
^ permalink raw reply related
* Re: [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink
From: Thomas Graf @ 2012-12-11 18:40 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: David Miller, David.Laight, netdev
In-Reply-To: <50C74B5D.9050708@6wind.com>
On 12/11/12 at 04:03pm, Nicolas Dichtel wrote:
> In fact, it seems not so easy because most users of nlmsg_new() calculate
> the exact needed length, thus if we add an unpredicted attribute,
> the message will be too small.
True, we would either need to fix the calculations by accounting
for an additional 4 bytes for each 64bit arg or just reserve an
additional fixed amount for padding per message in nlmsg_new().
^ permalink raw reply
* Re: netdevice wanrouter: Convert directly reference of netdev->priv
From: David Miller @ 2012-12-11 18:43 UTC (permalink / raw)
To: dan.carpenter; +Cc: wangchen, netdev
In-Reply-To: <20121203090405.GA12089@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 3 Dec 2012 12:04:05 +0300
> I suspect we should just revert the patch?
That is absolutely something we cannot do.
netdev->priv no longer exists, first of all.
And the whole point of this change was to allow us to
remove any and all references to netdev->priv, exactly
so that we could remove it altogether.
If you look at the commit in question, the idea is to
allocate the netdev in the ->new_if() callback.
And that's in fact what happens.
What's missing at the top level is something like:
dev = wandev->dev;
And perhaps removing the 'dev' argument to the ->new_if()
method since it obviously is always NULL and never actually
used.
Thanks.
^ permalink raw reply
* Re: [Patch net-next] bridge: fix seq check in br_mdb_dump()
From: David Miller @ 2012-12-11 18:45 UTC (permalink / raw)
To: amwang; +Cc: netdev, herbert, shemminger, tgraf, brouer
In-Reply-To: <1355197772.13991.1.camel@cr0>
From: Cong Wang <amwang@redhat.com>
Date: Tue, 11 Dec 2012 11:49:32 +0800
> On Mon, 2012-12-10 at 13:46 -0500, David Miller wrote:
>> From: Cong Wang <amwang@redhat.com>
>> Date: Mon, 10 Dec 2012 20:15:35 +0800
>>
>> > From: Cong Wang <amwang@redhat.com>
>> >
>> > In case of rehashing, introduce a global variable 'br_mdb_rehash_seq'
>> > which gets increased every time when rehashing, and assign
>> > net->dev_base_seq + br_mdb_rehash_seq to cb->seq.
>> >
>> > In theory cb->seq could be wrapped to zero, but this is not
>> > easy to fix, as net->dev_base_seq is not visible inside
>> > br_mdb_rehash(). In practice, this is rare.
>> >
>> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> > Cc: Stephen Hemminger <shemminger@vyatta.com>
>> > Cc: "David S. Miller" <davem@davemloft.net>
>> > Cc: Thomas Graf <tgraf@suug.ch>
>> > Cc: Jesper Dangaard Brouer <brouer@redhat.com>
>> > Signed-off-by: Cong Wang <amwang@redhat.com>
>>
>> No synchronization at all is applied to this variable, I can't
>> see how this is OK.
>
> br_mdb_rehash() is protected by the multicast spinlock, so increasing
> this variable is protected by it, and reading the variable doesn't need
> locking. Am I missing anything? Or should we use atomic_t?
I missed that locking, ok, looks good.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: avoid double copy in skb_gro_receive()
From: David Miller @ 2012-12-11 18:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1355251109.27891.114.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 11 Dec 2012 10:38:29 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> __copy_skb_header(nskb, p) already copied p->cb[], no need to copy
> it again.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: netdevice wanrouter: Convert directly reference of netdev->priv
From: David Miller @ 2012-12-11 18:46 UTC (permalink / raw)
To: dan.carpenter; +Cc: wangchen, netdev
In-Reply-To: <20121211.134310.1757064654502486858.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 11 Dec 2012 13:43:10 -0500 (EST)
> What's missing at the top level is something like:
>
> dev = wandev->dev;
>
> And perhaps removing the 'dev' argument to the ->new_if()
> method since it obviously is always NULL and never actually
> used.
And for the record, wangchen's email bounces so it's very
unlikely we'll see any response from him.
^ permalink raw reply
* Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: Eric Dumazet @ 2012-12-11 18:54 UTC (permalink / raw)
To: David Miller; +Cc: mugunthanvnm, netdev, linux-arm-kernel, linux-omap, s.hauer
In-Reply-To: <20121211.133426.484976995112519196.davem@davemloft.net>
On Tue, 2012-12-11 at 13:34 -0500, David Miller wrote:
>
> You can't signal "out of descriptors" and stop the queue after the
> fact. NETDEV_TX_BUSY is for handling exceptional and extraordinary
> conditions, not for the normal queue full handling.
This reminds me an idea I had about MQ/MQPRIO qdisc and BQL interaction
(BQL btw makes less probable a NETDEV_TX_BUSY event or
__QUEUE_STATE_DRV_XOFF state, but more probable a
__QUEUE_STATE_STACK_XOFF)
We dequeue a packet from qdisc, then we realize tx queue is in XOFF
state, and we have to hold the skb into gso_skb for later.
This shows in stats (tc -s qdisc dev eth0) as requeues.
Problem of these requeues is that high priority packets can not be
dequeued as long as this (possibly low prio and big TSO packet) is not
removed from gso_skb.
At 1Gbps speed, a full size TSO packet is 500 us of extra latency.
Suggested fix : add a TCQ_F_MQSLAVE flag to allow dequeue_skb() to test
the netif_xmit_frozen_or_stopped() status _before_ dequeing packet from
qdisc.
(For other qdiscs, we dont really know which tx queue will use the next
packet before dequeueing it)
^ permalink raw reply
* Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: David Miller @ 2012-12-11 18:57 UTC (permalink / raw)
To: erdnetdev; +Cc: mugunthanvnm, netdev, linux-arm-kernel, linux-omap, s.hauer
In-Reply-To: <1355252096.27891.130.camel@edumazet-glaptop>
From: Eric Dumazet <erdnetdev@gmail.com>
Date: Tue, 11 Dec 2012 10:54:56 -0800
> Suggested fix : add a TCQ_F_MQSLAVE flag to allow dequeue_skb() to test
> the netif_xmit_frozen_or_stopped() status _before_ dequeing packet from
> qdisc.
This sounds fine to me.
^ permalink raw reply
* Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: Eric Dumazet @ 2012-12-11 19:07 UTC (permalink / raw)
To: David Miller; +Cc: mugunthanvnm, netdev, linux-arm-kernel, linux-omap, s.hauer
In-Reply-To: <20121211.135759.1010213285970148974.davem@davemloft.net>
On Tue, 2012-12-11 at 13:57 -0500, David Miller wrote:
> From: Eric Dumazet <erdnetdev@gmail.com>
> Date: Tue, 11 Dec 2012 10:54:56 -0800
>
> > Suggested fix : add a TCQ_F_MQSLAVE flag to allow dequeue_skb() to test
> > the netif_xmit_frozen_or_stopped() status _before_ dequeing packet from
> > qdisc.
>
> This sounds fine to me.
> --
By the way we also could set this 'flag' for non multi queue devices.
^ permalink raw reply
* Re: [PATCH 6/6] netfilter: nf_nat: Handle routing changes in MASQUERADE target
From: Andrew Collins @ 2012-12-11 19:43 UTC (permalink / raw)
To: kadlec; +Cc: netfilter-devel, netdev
In-Reply-To: <1354642293-4114-7-git-send-email-pablo@netfilter.org>
On Tue, Dec 4, 2012 at 10:31 AM, <pablo@netfilter.org> wrote:
>
> From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
>
> When the route changes (backup default route, VPNs) which affect a
> masqueraded target, the packets were sent out with the outdated source
> address. The patch addresses the issue by comparing the outgoing interface
> directly with the masqueraded interface in the nat table.
>
> Events are inefficient in this case, because it'd require adding route
> events to the network core and then scanning the whole conntrack table
> and re-checking the route for all entry.
>
> Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Jozsef, a small question about this change. Should this same check
not exist here:
case IP_CT_NEW:
/* Seen it before? This can happen for loopback, retrans,
* or local packets.
*/
if (!nf_nat_initialized(ct, maniptype)) {
unsigned int ret;
ret = nf_nat_rule_find(skb, hooknum, in, out, ct);
if (ret != NF_ACCEPT)
return ret;
- } else
+ } else {
pr_debug("Already setup manip %s for ct %p\n",
maniptype == NF_NAT_MANIP_SRC ? "SRC" : "DST",
ct);
+ if (nf_nat_oif_changed(hooknum, ctinfo, nat, out)) {
+ nf_ct_kill_acct(ct, ctinfo, skb);
+ return NF_DROP;
+ }
+ }
break;
as well? It's *significantly* less common than the case you fixed,
and perhaps just letting the state time out is acceptable, but I've
seen TCP connections get stuck with the wrong source address if we
haven't hit ESTABLISHED at the point when the routing change occurs
(most reproducible on high latency links).
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: ethtool: Add destination MAC address to flow steering API
From: Or Gerlitz @ 2012-12-11 19:55 UTC (permalink / raw)
To: Alexander Duyck
Cc: Amir Vadai, David S. Miller, netdev, Or Gerlitz, Yan Burman,
Ben Hutchings
In-Reply-To: <50C76F6E.2010600@intel.com>
On Tue, Dec 11, 2012 at 7:37 PM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
>
> Is there any special reason why you need to change the size of this
> structure? It seems like you could probably just replace the data
> section with a union containing either 8 bytes of user specified data or
> your MAC address data. Then we wouldn't need all of the changes to the
> rest of the flow specifier.
basically, we followed Ben's suggestions made here
http://marc.info/?t=134977576500003
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: ethtool: Add destination MAC address to flow steering API
From: Alexander Duyck @ 2012-12-11 20:57 UTC (permalink / raw)
To: Or Gerlitz
Cc: Amir Vadai, David S. Miller, netdev, Or Gerlitz, Yan Burman,
Ben Hutchings
In-Reply-To: <CAJZOPZJfqdrxKp8ZPTXs_-07XSdPoKu+bNQNZzkeTRgP-R2XnQ@mail.gmail.com>
On 12/11/2012 11:55 AM, Or Gerlitz wrote:
> On Tue, Dec 11, 2012 at 7:37 PM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>>
>> Is there any special reason why you need to change the size of this
>> structure? It seems like you could probably just replace the data
>> section with a union containing either 8 bytes of user specified data or
>> your MAC address data. Then we wouldn't need all of the changes to the
>> rest of the flow specifier.
>
>
> basically, we followed Ben's suggestions made here
> http://marc.info/?t=134977576500003
>
After looking over Ben's suggestion it makes sense.
Since I am pretty much responsible for the ixgbe implementation of this
I will do a few quick tests once the patches are applied to make certain
that there were no issues introduced on our end.
Thanks,
Alex
^ permalink raw reply
* Re: netconsole fun
From: Neil Horman @ 2012-12-11 21:19 UTC (permalink / raw)
To: Peter Hurley; +Cc: Cong Wang, netdev
In-Reply-To: <1355246272.2694.27.camel@thor>
On Tue, Dec 11, 2012 at 12:17:52PM -0500, Peter Hurley wrote:
> On Tue, 2012-12-11 at 11:45 -0500, Neil Horman wrote:
> > On Tue, Dec 11, 2012 at 10:16:51AM -0500, Peter Hurley wrote:
> > > On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> > > > On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > > > > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > > > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > > > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > > > > recommended method of running netconsole on a machine that has a slaved
> > > > > > > device?
> > > > > > >
> > > > > >
> > > > > > Yes, running it on the master device instead.
> > > > >
> > > > > Thanks for the suggestion, but:
> > > > >
> > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.10.99/br0,30000@192.168.10.100/xx:xx:xx:xx:xx:xx
> > > > > ...
> > > > > [ 5.289869] netpoll: netconsole: local port 6665
> > > > > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > > > > [ 5.289892] netpoll: netconsole: interface 'br0'
> > > > > [ 5.289898] netpoll: netconsole: remote port 30000
> > > > > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > > > > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > > > > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > > > > [ 5.289929] netconsole: cleaning up
> > > > > ...
> > > > > [ 9.392291] Bridge firewalling registered
> > > > > [ 9.396805] device eth1 entered promiscuous mode
> > > > > [ 9.418350] eth1: setting full-duplex.
> > > > > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > > > > [ 9.423354] br0: port 1(eth1) entered forwarding state
> > > > >
> > > > >
> > > > > Is there a way to control or associate network device names prior to
> > > > > udev renaming?
> > > > >
> > > > That looks like a systemd problem (or more specifically a boot dependency
> > > > problem). You need to modify your netconsole unit/service file to start after
> > > > all your networking is up. NetworkManager provides a dummy service file for
> > > > this purpose, called networkmanager-wait-online.service
> > >
> > > Ok. So with a single physical network interface that will be bridged,
> > > netconsole cannot used for kernel boot messages.
> > >
> > > With a machine with multiple nics, is there a way to control device
> > > naming so that the interface name to be used by netconsole specified on
> > > the boot command line will actually corresponding to the intended
> > > device. For example,
> > >
> > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.1.123/eth0,30000@192.168.1.139/xx:xx:xx:xx:xx:xx
> > > ....
> > > [ 4.092184] 3c59x: Donald Becker and others.
> > > [ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
> > > [ 4.094035] tg3.c:v3.125 (September 26, 2012)
> > > ....
> > > [ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > > [ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > [ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > > [ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
> > >
> > > This is attaching netconsole to the wrong device because bus
> > > enumeration, and therefore load order, is not consistent from boot to
> > > boot.
> > >
> > No, theres no way to do that. As you note device ennumeration isn't consistent
> > accross boots, thats why udev creates rules to rename devices based on immutable
> > (or semi-immutable) data, like mac addresses, or pci bus locations). Once that
> > happens, you'll have consistent names for your interfaces, and that work will be
> > guaranteed to be done after networkmanager has finished opening all the
> > interfaces that it needs (hence my suggestion to make netconsole service
> > dependent on networkmanager service startup completing).
> >
> > Neil
>
> Thanks for all your help here, Neil. Very much appreciated.
>
> Happy Holidays,
> Peter Hurley
>
No problem, anytime!
Happy Holidays
Neil
>
>
^ permalink raw reply
* pull request: wireless-next 2012-12-11
From: John W. Linville @ 2012-12-11 21:55 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
This is a roll-up of some late-breaking activity intended for 3.8.
The extra week of waiting for 3.7 left people a bit restless!
There are two pull requests...
For the mac80211 pull, Johannes says:
"Please pull my mac80211-next tree to get a few updates: I mostly have
fixes for code that's currently in the -next trees, but there are still
a few improvements as well."
For the iwlwifi pull, Johannes says:
"Please pull to get a few small fixes, some improvements and a bit of
infrastructure work in iwlwifi."
Otherwise, there is nothing too unusual here -- some normal levels
of attention paid to brcmfmac, and ath9k, a couple of late fixes for
some new bcma code, and a handful of other bits.
Please let me know if there are problems!
John
---
The following changes since commit 75be437230b06fca87908a787f70de0ce7fbab8c:
net: gro: avoid double copy in skb_gro_receive() (2012-12-11 13:44:09 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to f9c4d420c12de65e58a1a14ccee03e8b5cf99f5b:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2012-12-11 16:24:55 -0500)
----------------------------------------------------------------
Arend van Spriel (10):
brcmfmac: rework bus interface
brcmsmac: fix uninitialized variable warning on arm architecture
brcmfmac: use one list of event defintions
brcmfmac: error messages should not be suppressed
brcmfmac: consolidate debug macros in wl_cfg80211
brcmfmac: replace WL_ERR() with brcmf_err()
brcmfmac: replace WL_INFO() macro
brcmfmac: remove WL_TRACE() macro
brcmfmac: remove WL_SCAN() macro
brcmfmac: remove WL_CONN() macro
Chaitanya (1):
mac80211: warn only once if ampdu_action isn't assigned
Christian Lamparter (1):
carl9170: fix copy and paste mishap in carl9170_handle_mpdu
Cong Ding (1):
ssb: use WARN in main.c
Emmanuel Grumbach (7):
iwlwifi: read the Rx write pointer only once
iwlwifi: clear trans->op_mode pointer when it is leaving
iwlwifi: return real info in probe failure
iwlwifi: move prph handling into the transport
iwlwifi: reset_ict in stop_hw
iwlwifi: silently ignore fw flaws in Tx path
iwlwifi: don't handle masked interrupt
Eytan Lifshitz (1):
iwlwifi: Change define and struct names in iwl-eeprom-parse.h
Felix Fietkau (4):
Revert "ath9k_hw: Update AR9003 high_power tx gain table"
ath9k_hw: Fix signal strength / channel noise reporting
ath5k: fix tx path skb leaks
b43: fix tx path skb leaks
Gabor Juhos (6):
ath9k: ar9003: fix OTP register offsets for AR9340
ath9k: move duplicated debug message to 'ath9k_hw_nvram_read'
ath9k: add EEPROM offset to debug message
ath9k: use 'struct ath_hw *' as the first argument for 'ath9k_hw_nvram_read'
ath9k: allow to load EEPROM content via firmware API
ath9k: check pdata variable before dereferencing it
Hauke Mehrtens (3):
brcmsmac: add support for cores with revision 17
brcmsmac: do a read after the write of the objmem on broken PCIe controllers
brcmsmac: add support for BCM43224 with PCI id of 14e4:a8d8
Helmut Schaa (1):
mac80211: skip radiotap space calculation if no monitor exists
Johannes Berg (7):
cfg80211: check no-OFDM flag for channels wider than 20 MHz
wireless: fix VHT max AMPDU exponent definition
mac80211: cancel work instead of waiting for it to do nothing
iwlwifi: change TX code to suppress smatch warning
wext: explicitly cast -110 to u8
mac80211: a few whitespace fixes
minstrel: update stats after processing status
John W. Linville (4):
rt2800usb: reorganize 2001:3c1e in usb id table Wi-Fi adapter
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge branch 'for-john' of git://git.sipsolutions.net/mac80211-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Larry Finger (1):
b43legacy: Fix firmware loading when driver is built into the kernel
Maia Kozheva (1):
rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter
Marco Porsch (1):
mac80211: don't drop mesh peering frames from unknown STA
Rafał Miłecki (2):
bcma: unify naming schema for clock functions
bcma: mips: fix clearing device IRQ
Saravana (1):
mac80211: add debug file for mic failure
Simon Wunderlich (1):
mac80211: adapt slot time in IBSS mode
Stanislaw Gruszka (2):
mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
Sujith Manoharan (10):
ath9k: Fix regression in 'xmit' debugfs file
ath9k_hw: Fix PAPRD registers for AR9485
ath9k_hw: Fix PAPRD training
ath9k: Add a few debug messages for PAPRD
ath9k: Fix redundant PS wrappers
ath9k_hw: Various trivial fixes for PAPRD
ath9k_hw: Fix PAPRD retraining for AR9485
ath9k_hw: Add HW cap for PAPRD
ath9k_hw: Calculate the correct training power for PAPRD
ath9k_hw: Update intivals for AR9340
Thomas Pedersen (3):
ath9k: RX timestamp is reported at end of frame
ath9k_htc: RX timestamp is reported at end of frame
ath5k: RX timestamp is reported at end of frame
Tim Gardner (1):
iwlwifi: iwlagn_request_scan: Fix check for priv->scan_request
drivers/bcma/bcma_private.h | 4 +-
drivers/bcma/driver_chipcommon.c | 10 +-
drivers/bcma/driver_chipcommon_pmu.c | 39 +-
drivers/bcma/driver_mips.c | 4 +-
drivers/net/wireless/ath/ath5k/base.c | 17 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 172 ++---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 66 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 87 ++-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 29 +-
drivers/net/wireless/ath/ath9k/ar9340_initvals.h | 6 +-
drivers/net/wireless/ath/ath9k/calib.c | 1 +
drivers/net/wireless/ath/ath9k/calib.h | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 29 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 8 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 9 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 10 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 4 +
drivers/net/wireless/ath/ath9k/hw.h | 7 +-
drivers/net/wireless/ath/ath9k/init.c | 60 +-
drivers/net/wireless/ath/ath9k/link.c | 22 +-
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/b43/dma.c | 7 +-
drivers/net/wireless/b43/main.c | 12 +-
drivers/net/wireless/b43/pio.c | 4 +-
drivers/net/wireless/b43legacy/b43legacy.h | 5 +
drivers/net/wireless/b43legacy/main.c | 37 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 15 +-
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 44 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 1 -
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 92 ++-
drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c | 25 +-
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 40 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c | 5 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h | 35 +-
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 57 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 205 +++---
drivers/net/wireless/brcm80211/brcmfmac/fweh.c | 84 +--
drivers/net/wireless/brcm80211/brcmfmac/fweh.h | 142 ++--
drivers/net/wireless/brcm80211/brcmfmac/fwil.c | 14 +-
.../net/wireless/brcm80211/brcmfmac/sdio_chip.c | 14 +-
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 91 +--
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 817 +++++++++++----------
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.h | 70 +-
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 2 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 1 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 13 +-
drivers/net/wireless/iwlwifi/dvm/calib.c | 14 +-
drivers/net/wireless/iwlwifi/dvm/debugfs.c | 12 +-
drivers/net/wireless/iwlwifi/dvm/dev.h | 2 +-
drivers/net/wireless/iwlwifi/dvm/devices.c | 8 +-
drivers/net/wireless/iwlwifi/dvm/lib.c | 8 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 12 +-
drivers/net/wireless/iwlwifi/dvm/main.c | 57 +-
drivers/net/wireless/iwlwifi/dvm/rs.c | 44 +-
drivers/net/wireless/iwlwifi/dvm/rxon.c | 4 +-
drivers/net/wireless/iwlwifi/dvm/scan.c | 13 +-
drivers/net/wireless/iwlwifi/dvm/sta.c | 12 +-
drivers/net/wireless/iwlwifi/dvm/tx.c | 67 +-
drivers/net/wireless/iwlwifi/dvm/ucode.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-config.h | 8 +-
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 34 +
drivers/net/wireless/iwlwifi/iwl-drv.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 84 ++-
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.h | 45 +-
drivers/net/wireless/iwlwifi/iwl-io.c | 40 +-
drivers/net/wireless/iwlwifi/iwl-io.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 22 +-
drivers/net/wireless/iwlwifi/pcie/1000.c | 8 +-
drivers/net/wireless/iwlwifi/pcie/2000.c | 16 +-
drivers/net/wireless/iwlwifi/pcie/5000.c | 12 +-
drivers/net/wireless/iwlwifi/pcie/6000.c | 28 +-
drivers/net/wireless/iwlwifi/pcie/drv.c | 11 +-
drivers/net/wireless/iwlwifi/pcie/rx.c | 14 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 18 +
drivers/net/wireless/mac80211_hwsim.c | 2 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 3 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +-
drivers/ssb/main.c | 3 +-
include/linux/ath9k_platform.h | 2 +
include/linux/ieee80211.h | 54 +-
include/net/mac80211.h | 5 +
net/mac80211/agg-tx.c | 2 +-
net/mac80211/debugfs_key.c | 17 +
net/mac80211/ibss.c | 14 +
net/mac80211/iface.c | 2 +-
net/mac80211/key.h | 3 +
net/mac80211/mlme.c | 4 +-
net/mac80211/rc80211_minstrel.c | 9 +-
net/mac80211/rx.c | 9 +-
net/mac80211/scan.c | 2 +-
net/mac80211/status.c | 6 +-
net/mac80211/wpa.c | 5 +-
net/wireless/chan.c | 3 +
net/wireless/wext-compat.c | 2 +-
101 files changed, 1741 insertions(+), 1472 deletions(-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ 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