* Re: [PATCH] br2684: don't send frames on not-ready vcc
From: David Woodhouse @ 2012-11-28 17:09 UTC (permalink / raw)
To: David Miller; +Cc: chas, krzysiek, netdev, linux-kernel, nathan
In-Reply-To: <20121128.120415.778262714601372592.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
On Wed, 2012-11-28 at 12:04 -0500, David Miller wrote:
> Do you want me to pull that tree into net-next or is there a plan to
> repost the entire series of work for a final submission?
I think it needs a little more testing/consensus first. I'd like an ack
from Chas on the atm ->release_cb() thing, at least. And I wouldn't mind
confirmation from Nathan's customer that they're no longer seeing the
panics.
And then I'll either send an explicit pull request, or submit it as
patches — whichever you prefer.
Hopefully in the next day or so; the merge window is approaching...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: TCP and reordering
From: Benjamin LaHaise @ 2012-11-28 17:08 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Vijay Subramanian, David Miller, saku, rick.jones2,
netdev
In-Reply-To: <1354120887.21562.87.camel@shinybook.infradead.org>
On Wed, Nov 28, 2012 at 04:41:27PM +0000, David Woodhouse wrote:
> Absolutely. But in the cases where they *do* connect to the congested
> link, and the packets are backing up on the *same* host, there's no
> excuse for not actually knowing that and behaving appropriately :)
Agreed.
> And even if the congested link is somewhere upstream, you'd hope that
> something exists (like ECN) to let you know about it.
>
> In the LNS case that I'm most familiar with, the LNS *does* know about
> the bandwidth of each customer's ADSL line, and limits the bandwidth of
> each session appropriately. It's much better to decide at the LNS which
> packets to drop, than to let the telco decide. Or worse, to have the
> ADSL link drop one ATM cell out of *every* packet when it's
> overloaded...
I'm speaking from experience: the telcos I've dealt with (2 different
companies here in Canada) do *not* know the speed of the ADSL link being
fed with PPPoE at the customer premises that a LAC receives as an incoming
session. The issue is that the aggregation network does not propagate
that information from the DSLAM to the LAC. It's a big mess where the
aggregation network has a mix of ATM and L2 ethernet switches, and much
of the gear has no support for protocols that can carry that information.
> > This sort of chaining of destructors is going to be very expensive in
> > terms of CPU cycles. If this does get implemented, please ensure there is
> > a way to turn it off.
>
> You asked that before, and I think we agreed that it would be acceptable
> to use the existing CONFIG_BQL option?
No, that would not be sufficient, as otherwise there is no means to control
the behaviour of distribution vendor kernels -- they would most likely
default to on.
> I'm looking at adding ppp-channel equivalents of
> netdev_{reset,sent,completed}_queue, and having the PPP channels call
> them as appropriate. For some it's trivial, but in the PPPoE/L2TP cases
> because we want to install destructors without stomping on TSQ it'll be
> substantial enough that it should be compiled out if CONFIG_BQL isn't
> enabled.
This sounds like overhead. That said, I'd like to measure it to see what
sort of actual effect this has on performance before passing any judgement.
I'd be happy to put together a test setup to run anything you've come up
with through.
> > That said, if there is local congestion, the benefits of BQL would be
> > worthwhile to have.
>
> If there is local congestion... *or* if you have proper bandwidth
> management on the link to the clients; either by knowing the bandwidth
> and voluntarily limiting to it, or by something like ECN.
Improved ECN support is a very good idea.
> > > But I wish there was a nicer way to chain destructors. And no, I don't
> > > count what GSO does. We can't use the cb here anyway since we're passing
> > > it down the stack.
> >
> > I think all the tunneling protocols are going to have the same problem
> > here, so it deserves some thought about how to tackle the issue in a
> > generic way without incurring a large amount of overhead.
>
> Right. There are a few cases of skb->destructor being used at different
> levels of the stack where I suspect this might already be an issue, in
> fact. And things like TSQ will silently be losing track of packets
> because of skb_orphan, even before they've left the box.
>
> Hah, and I note that l2tp is *already* stomping on skb->destructor for
> its own purposes. So I could potentially just use its existing callback
> and pretend I hadn't seen that it screws up TSQ, and leave the issue of
> chaining destructors to be Someone Else's Problem???.
*nod*
> Actually, I think it overwrites the destructor without calling
> skb_orphan() first ??? which will *really* upset TSQ, won't it?
Yes, that would defeat things.
> > This exact
> > problem is one of the reasons multilink PPP often doesn't work well over
> > L2TP or PPPoE as compared to its behaviour over ttys.
>
> Another fun issue with tunnelling protocols and BQL... packets tend to
> *grow* as they get encapsulated. So you might end up calling
> netdev_sent_queue() with a given size, then netdev_completed_queue()
> with a bigger packet later...
Oh fun!
Ultimately, we want to know about congestion as early as possible in the
packet processing. In the case of L2TP, it would be helpful to use the
knowledge of the path the packet will be sent out on to correclty set the
ECN bits on the packet inside the L2TP encapsulation. The L2TP code does
not appear to do this at present, so this needs work.
-ben
> --
> dwmw2
>
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH] br2684: don't send frames on not-ready vcc
From: David Miller @ 2012-11-28 17:04 UTC (permalink / raw)
To: dwmw2; +Cc: chas, krzysiek, netdev, linux-kernel, nathan
In-Reply-To: <1354122070.21562.89.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 28 Nov 2012 17:01:10 +0000
> On Wed, 2012-11-28 at 11:41 -0500, David Miller wrote:
>>
>> Please:
>>
>> if (X ||
>> Y ||
>> Z)
>>
>> not:
>>
>> if (X
>> || Y
>> || Z)
>
> Thanks. Fixed in both Krzysztof's original pppoatm version, and my
> br2684 patch, in the git tree at git://git.infradead.org/~dwmw2/atm.git
>
> I knew there was something else that offended me about the original,
> other than just the whitespace (which is also fixed).
Do you want me to pull that tree into net-next or is there a plan to
repost the entire series of work for a final submission?
^ permalink raw reply
* Re: [PATCH v2 net-next] net: move inet_dport/inet_num in sock_common
From: David Miller @ 2012-11-28 17:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ling.ma.program, joe, bhutchings
In-Reply-To: <20121128.114835.1005932954047935079.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 28 Nov 2012 11:48:35 -0500 (EST)
> I like this a lot, applied, thanks Eric!
And I'd like it even more if it was build tested :-/
net/ipv4/inet_hashtables.c: In function ‘__inet_lookup_established’:
net/ipv4/inet_hashtables.c:242:7: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:246:8: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:267:7: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:274:8: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:226:2: warning: unused variable ‘acookie’ [-Wunused-variable]
net/ipv4/inet_hashtables.c: In function ‘__inet_check_established’:
net/ipv4/inet_hashtables.c:326:7: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:341:7: error: expected expression before ‘)’ token
net/ipv4/inet_hashtables.c:307:2: warning: unused variable ‘acookie’ [-Wunused-variable]
net/ipv4/inet_hashtables.c:306:6: warning: unused variable ‘dif’ [-Wunused-variable]
This is with gcc-4.7.2-2 on Fedora 17 on an allmodconfig build.
^ permalink raw reply
* Re: [PATCH] br2684: don't send frames on not-ready vcc
From: David Woodhouse @ 2012-11-28 17:01 UTC (permalink / raw)
To: David Miller; +Cc: chas, krzysiek, netdev, linux-kernel, nathan
In-Reply-To: <20121128.114153.737074131307295783.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
On Wed, 2012-11-28 at 11:41 -0500, David Miller wrote:
>
> Please:
>
> if (X ||
> Y ||
> Z)
>
> not:
>
> if (X
> || Y
> || Z)
Thanks. Fixed in both Krzysztof's original pppoatm version, and my
br2684 patch, in the git tree at git://git.infradead.org/~dwmw2/atm.git
I knew there was something else that offended me about the original,
other than just the whitespace (which is also fixed).
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [net-next RFC] pktgen: don't wait for the device who doesn't free skb immediately after sent
From: Stephen Hemminger @ 2012-11-28 16:53 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, netdev, linux-kernel, virtualization, davem
In-Reply-To: <50B5B3D4.1070106@redhat.com>
On Wed, 28 Nov 2012 14:48:52 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 11/28/2012 12:49 AM, Stephen Hemminger wrote:
> > On Tue, 27 Nov 2012 14:45:13 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> On 11/27/2012 01:37 AM, Stephen Hemminger wrote:
> >>> On Mon, 26 Nov 2012 15:56:52 +0800
> >>> Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>>> Some deivces do not free the old tx skbs immediately after it has been sent
> >>>> (usually in tx interrupt). One such example is virtio-net which optimizes for
> >>>> virt and only free the possible old tx skbs during the next packet sending. This
> >>>> would lead the pktgen to wait forever in the refcount of the skb if no other
> >>>> pakcet will be sent afterwards.
> >>>>
> >>>> Solving this issue by introducing a new flag IFF_TX_SKB_FREE_DELAY which could
> >>>> notify the pktgen that the device does not free skb immediately after it has
> >>>> been sent and let it not to wait for the refcount to be one.
> >>>>
> >>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> >>> Another alternative would be using skb_orphan() and skb->destructor.
> >>> There are other cases where skb's are not freed right away.
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> Hi Stephen:
> >>
> >> Do you mean registering a skb->destructor for pktgen then set and check
> >> bits in skb->tx_flag?
> > Yes. Register a destructor that does something like update a counter (number of packets pending),
> > then just spin while number of packets pending is over threshold.
> > --
>
> Not sure this is the best method, since pktgen was used to test the tx
> process of the device driver and NIC. If we use skb_orhpan(), we would
> miss the test of tx completion part.
There are other places that delay freeing and your solution would mean finding
and fixing all those. Code that does that already has to use skb_orphan() to
work, and I was looking for a way that could use that. Introducing another flag
value seems like a long term burden.
Alternatively, virtio could do cleanup more aggressively. Maybe in response to
ring getting half full, or add a cleanup timer or something to avoid the problem.
^ permalink raw reply
* Re: Specific question about packet dropping
From: Javier Domingo @ 2012-11-28 16:52 UTC (permalink / raw)
To: Shan Wei, netdev
In-Reply-To: <50B60244.9020605@gmail.com>
I have been reviewing and I think I must have confused terms.
Then, inside the kernel, there are no packet drops for legitime ones.
And I suppose that if an app doesn't read from its socket queue, the
kernel will drop them in the socket queue?
Javier Domingo
2012/11/28 Shan Wei <shanwei88@gmail.com>:
> Javier Domingo said, at 2012/11/28 19:50:
>> Thank you very much, I (don't know why) thought the packets were being
>> smashed in the dma memory.
>
> Maybe your kernel/application handles the packets so slower than that
> NIC receives.
>
>>> Best Regards
>>> Shan Wei
>>>
>>>>
>>>> Javier Domingo
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [patch net] team: fix hw_features setup
From: David Miller @ 2012-11-28 16:48 UTC (permalink / raw)
To: jiri; +Cc: netdev
In-Reply-To: <1354119190-16100-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 28 Nov 2012 17:13:10 +0100
> Do this in the same way bonding does. This fixed setup resolves performance
> issues when using some cards with certain offloading.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: move inet_dport/inet_num in sock_common
From: David Miller @ 2012-11-28 16:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ling.ma.program, joe, bhutchings
In-Reply-To: <1354107378.14302.149.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Nov 2012 04:56:18 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> commit 68835aba4d9b (net: optimize INET input path further)
> moved some fields used for tcp/udp sockets lookup in the first cache
> line of struct sock_common.
>
> This patch moves inet_dport/inet_num as well, filling a 32bit hole
> on 64 bit arches and reducing number of cache line misses.
>
> Also change INET_MATCH()/INET_TW_MATCH() to perform the ports match
> before addresses match, as this check is more discriminant.
>
> Remove the hash check from MATCH() macros because we dont need to
> re validate the hash value after taking a refcount on socket, and
> use likely/unlikely compiler hints, as the sk_hash/hash check
> makes the following conditional tests 100% predicted by cpu.
>
> Introduce skc_addrpair/skc_portpair pair values to better
> document the alignment requirements of the port/addr pairs
> used in the various MATCH() macros, and remove some casts.
>
> The namespace check can also be done at last.
>
> This slightly improves TCP/UDP lookup times.
>
> With help from Ben Hutchings & Joe Perches.
>
> Idea of this patch came after Ling Ma proposal to move skc_hash
> to the beginning of struct sock_common, and should allow him
> to submit a final version of his patch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I like this a lot, applied, thanks Eric!
^ permalink raw reply
* [PATCH v2] bonding: make arp_ip_target parameter checks consistent with sysfs
From: Nikolay Aleksandrov @ 2012-11-28 16:44 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, davem
The module can be loaded with arp_ip_target="255.255.255.255" which makes it
impossible to remove as the function in sysfs checks for that value, so we make
the parameter checks consistent with sysfs.
v2: Fix formatting
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5f5b69f..d29159a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4706,12 +4706,13 @@ static int bond_check_params(struct bond_params *params)
arp_ip_count++) {
/* not complete check, but should be good enough to
catch mistakes */
- if (!isdigit(arp_ip_target[arp_ip_count][0])) {
+ __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
+ if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
+ ip == 0 || ip == htonl(INADDR_BROADCAST)) {
pr_warning("Warning: bad arp_ip_target module parameter (%s), ARP monitoring will not be performed\n",
arp_ip_target[arp_ip_count]);
arp_interval = 0;
} else {
- __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
arp_target[arp_ip_count] = ip;
}
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net-next] gro: Handle inline VLAN tags
From: David Miller @ 2012-11-28 16:46 UTC (permalink / raw)
To: gallatin; +Cc: eric.dumazet, bhutchings, netdev, linux-net-drivers, herbert
In-Reply-To: <50B3850C.4070902@myri.com>
From: Andrew Gallatin <gallatin@myri.com>
Date: Mon, 26 Nov 2012 10:04:44 -0500
> How do you feel about the patchset I posted on 11/14/2012
> ([PATCH net-next 0/3] myri10ge: LRO to GRO conversion,
> http://marc.info/?l=linux-netdev&m=135289838223920&w=2)
> which moves myri10ge from LRO to GRO?
>
> Specifically, if doing vlan decap in GRO is not OK, then how
> about doing it in the driver?
I'm going to trust Eric's judgment on this one, as he has been
thinking more about the long term GRO issues than I have.
Thanks.
^ permalink raw reply
* Re: [PATCH] br2684: don't send frames on not-ready vcc
From: David Miller @ 2012-11-28 16:41 UTC (permalink / raw)
To: dwmw2; +Cc: chas, krzysiek, netdev, linux-kernel, nathan
In-Reply-To: <1354058916.2534.25.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Tue, 27 Nov 2012 23:28:36 +0000
> + if (test_bit(ATM_VF_RELEASED, &atmvcc->flags)
> + || test_bit(ATM_VF_CLOSE, &atmvcc->flags)
> + || !test_bit(ATM_VF_READY, &atmvcc->flags)) {
Please:
if (X ||
Y ||
Z)
not:
if (X
|| Y
|| Z)
Thanks.
^ permalink raw reply
* Re: TCP and reordering
From: David Woodhouse @ 2012-11-28 16:41 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Eric Dumazet, Vijay Subramanian, David Miller, saku, rick.jones2,
netdev
In-Reply-To: <20121128161930.GB19042@kvack.org>
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
On Wed, 2012-11-28 at 11:19 -0500, Benjamin LaHaise wrote:
> On Wed, Nov 28, 2012 at 03:47:15PM +0000, David Woodhouse wrote:
> > On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> > > BQL is nice for high speed adapters.
> >
> > For adapters with hugely deep queues, surely? There's a massive
> > correlation between the two, of course ??? but PPP over L2TP or PPPoE
> > ought to be included in the classification, right?
>
> Possibly, but there are many setups where PPPoE/L2TP do not connect to
> the congested link directly.
Absolutely. But in the cases where they *do* connect to the congested
link, and the packets are backing up on the *same* host, there's no
excuse for not actually knowing that and behaving appropriately :)
And even if the congested link is somewhere upstream, you'd hope that
something exists (like ECN) to let you know about it.
In the LNS case that I'm most familiar with, the LNS *does* know about
the bandwidth of each customer's ADSL line, and limits the bandwidth of
each session appropriately. It's much better to decide at the LNS which
packets to drop, than to let the telco decide. Or worse, to have the
ADSL link drop one ATM cell out of *every* packet when it's
overloaded...
> This sort of chaining of destructors is going to be very expensive in
> terms of CPU cycles. If this does get implemented, please ensure there is
> a way to turn it off.
You asked that before, and I think we agreed that it would be acceptable
to use the existing CONFIG_BQL option?
I'm looking at adding ppp-channel equivalents of
netdev_{reset,sent,completed}_queue, and having the PPP channels call
them as appropriate. For some it's trivial, but in the PPPoE/L2TP cases
because we want to install destructors without stomping on TSQ it'll be
substantial enough that it should be compiled out if CONFIG_BQL isn't
enabled.
> That said, if there is local congestion, the benefits of BQL would be
> worthwhile to have.
If there is local congestion... *or* if you have proper bandwidth
management on the link to the clients; either by knowing the bandwidth
and voluntarily limiting to it, or by something like ECN.
> > But I wish there was a nicer way to chain destructors. And no, I don't
> > count what GSO does. We can't use the cb here anyway since we're passing
> > it down the stack.
>
> I think all the tunneling protocols are going to have the same problem
> here, so it deserves some thought about how to tackle the issue in a
> generic way without incurring a large amount of overhead.
Right. There are a few cases of skb->destructor being used at different
levels of the stack where I suspect this might already be an issue, in
fact. And things like TSQ will silently be losing track of packets
because of skb_orphan, even before they've left the box.
Hah, and I note that l2tp is *already* stomping on skb->destructor for
its own purposes. So I could potentially just use its existing callback
and pretend I hadn't seen that it screws up TSQ, and leave the issue of
chaining destructors to be Someone Else's Problem™.
Actually, I think it overwrites the destructor without calling
skb_orphan() first — which will *really* upset TSQ, won't it?
> This exact
> problem is one of the reasons multilink PPP often doesn't work well over
> L2TP or PPPoE as compared to its behaviour over ttys.
Another fun issue with tunnelling protocols and BQL... packets tend to
*grow* as they get encapsulated. So you might end up calling
netdev_sent_queue() with a given size, then netdev_completed_queue()
with a bigger packet later...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [patch] atm: forever loop loading ambassador firmware
From: David Miller @ 2012-11-28 16:38 UTC (permalink / raw)
To: chas; +Cc: dan.carpenter, dwmw2, linux-atm-general, netdev, kernel-janitors
In-Reply-To: <20121128104044.785f1041@thirdoffive.cmf.nrl.navy.mil>
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Wed, 28 Nov 2012 10:40:44 -0500
> On Tue, 27 Nov 2012 20:29:35 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
>> There was a forever loop introduced here when we converted this to
>> request_firmware() back in 2008.
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> This certainly does seem to be the case.
>
> Acked-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 1/1] ip6tnl/sit: drop packet if ECN present with not-ECT
From: David Miller @ 2012-11-28 16:37 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, shemminger
In-Reply-To: <1354021631-13602-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 27 Nov 2012 14:07:11 +0100
> This patch reports the change made by Stephen Hemminger in ipip and gre[6] in
> commit eccc1bb8d4b4 (tunnel: drop packet if ECN present with not-ECT).
>
> Goal is to handle RFC6040, Section 4.2:
>
> Default Tunnel Egress Behaviour.
> o If the inner ECN field is Not-ECT, the decapsulator MUST NOT
> propagate any other ECN codepoint onwards. This is because the
> inner Not-ECT marking is set by transports that rely on dropped
> packets as an indication of congestion and would not understand or
> respond to any other ECN codepoint [RFC4774]. Specifically:
>
> * If the inner ECN field is Not-ECT and the outer ECN field is
> CE, the decapsulator MUST drop the packet.
>
> * If the inner ECN field is Not-ECT and the outer ECN field is
> Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the
> outgoing packet with the ECN field cleared to Not-ECT.
>
> The patch takes benefits from common function added in net/inet_ecn.h.
>
> Like it was done for Xin4 tunnels, it adds logging to allow detecting broken
> systems that set ECN bits incorrectly when tunneling (or an intermediate
> router might be changing the header). Errors are also tracked via
> rx_frame_error.
>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ewrk3: remove outdated comment
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: pebolle; +Cc: netdev, linux-kernel, richard.weinberger
In-Reply-To: <1354009714.1420.52.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Tue, 27 Nov 2012 10:48:34 +0100
> Remove an outdated comment, that should have been removed in the
> patch named "MODULE_PARM conversions" from early 2005.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ewrk3: silence GCC warning
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: pebolle; +Cc: netdev, linux-kernel, richard.weinberger
In-Reply-To: <1354009637.1420.50.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Tue, 27 Nov 2012 10:47:17 +0100
> Building ewrk3.o triggers this GCC warning:
> drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
> drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible pointer type [enabled by default]
>
> This can be trivially fixed by changing the 'irq' parameter from int to
> byte (which is an alias for unsigned char for module parameters).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix INTx ISR for interrupt behaviour on BE2
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <d856540b-bacc-45e3-a7cc-49e7febafb95@CMEXHTCAS1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 28 Nov 2012 11:20:02 +0530
> On BE2 chip, an interrupt may be raised even when EQ is in un-armed state.
> As a result be_intx()::events_get() and be_poll:events_get() can race and
> notify an EQ wrongly.
>
> Fix this by counting events only in be_poll(). Commit 0b545a629 fixes
> the same issue in the MSI-x path.
>
> But, on Lancer, INTx can be de-asserted only by notifying num evts. This
> is not an issue as the above BE2 behavior doesn't exist/has never been
> seen on Lancer.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: Nikolay Aleksandrov @ 2012-11-28 16:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andy, fubar
In-Reply-To: <20121128.112316.33060261620694469.davem@davemloft.net>
Actually I did see it from kernel/module.c and didn't come up with it
myself.
Anyway I will re-post with the change and will take a note for the future.
Thanks for the review
On 28/11/12 17:23, David Miller wrote:
> From: Nikolay Aleksandrov<nikolay@redhat.com>
> Date: Sat, 24 Nov 2012 13:21:15 +0100
>
>> @@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
>> arp_ip_count++) {
>> /* not complete check, but should be good enough to
>> catch mistakes */
>> - if (!isdigit(arp_ip_target[arp_ip_count][0])) {
>> + __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
>> + if (!isdigit(arp_ip_target[arp_ip_count][0])
>> + || ip == 0
>> + || ip == htonl(INADDR_BROADCAST)) {
> Please format this properly, put the connecting operators at the end,
> not the beginning, of the lines of the if statement, like so:
>
> if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
> ip == 0 ||
> ip == htonl(INADDR_BROADCAST)) {
>
> Where else did you see the layout you used? It's not a prevalent
> construct, so as far as I can tell you came up with it on your own.
>
> Please don't do this, and instead use existing practice as your guide.
>
> Thanks.
^ permalink raw reply
* Re: pull-request: can-next 2012-11-27
From: David Miller @ 2012-11-28 16:31 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <50B4807E.8010607@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 27 Nov 2012 09:57:34 +0100
> this is pull request is for net-next. Contains a patch by Andreas
> Larsson, which enables the sja1000 of driver to work under sparc.
> AnilKumar Ch contributed a patch to improve the c_can support under
> omap, Olivier Sobrie's patch brings support for the CAN/USB dongles
> from Kvaser. In a bunch of patches by me missing MODULE_ALIAS and/or
> MODULE_DEVICE_TABLE entries were added to the CAN drivers.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter updates for net (3.7-rc7)
From: David Miller @ 2012-11-28 16:30 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1353978185-3564-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 27 Nov 2012 02:03:04 +0100
> From: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Hi David,
>
> This update contains one patch to fix an overflow via the interface
> name attribute in the ipset infrastructure, from Florian Westphal.
>
> You can pull this change from:
>
> git://1984.lsi.us.es/nf master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: Move an interface to init_ne
From: Eric W. Biederman @ 2012-11-28 16:28 UTC (permalink / raw)
To: David Shwatrz; +Cc: Renato Westphal, netdev
In-Reply-To: <CAJJAcofHM+D8_2u-w5jPJZKfeA0A7QOxX1gxTQ2vOgx-L9aZhQ@mail.gmail.com>
David Shwatrz <dshwatrz@gmail.com> writes:
> But when I run "modprobe 8139too" on namespace1, a device named "eth1"
> is created on the initial network namespace and not on namesapce1.
> I expected that in such a case, a device named "eth0" will be created
> on namespace1, since it was called from namespace1. Or maybe modprobe
> does
> not consider the namespace from which it was called ?
modprobe has no concept of the namespace from which it was called.
Eric
^ permalink raw reply
* Re: [PATCH] vhost: fix length for cross region descriptor
From: David Miller @ 2012-11-28 16:27 UTC (permalink / raw)
To: mst; +Cc: netdev, jasowang, linux-kernel
In-Reply-To: <20121126155727.GA21716@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 26 Nov 2012 17:57:27 +0200
> If a single descriptor crosses a region, the
> second chunk length should be decremented
> by size translated so far, instead it includes
> the full descriptor length.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] irda: irttp: fix memory leak in irttp_open_tsap() error path
From: David Miller @ 2012-11-28 16:25 UTC (permalink / raw)
To: tt.rantala; +Cc: netdev, samuel, davej
In-Reply-To: <1353939404-19264-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Mon, 26 Nov 2012 16:16:44 +0200
> Cleanup the memory we allocated earlier in irttp_open_tsap() when we hit
> this error path. The leak goes back to at least 1da177e4
> ("Linux-2.6.12-rc2").
>
> Discovered with Trinity (the syscall fuzzer).
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: add Huawei E173
From: David Miller @ 2012-11-28 16:24 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1353859439-18260-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 25 Nov 2012 17:03:59 +0100
> The Huawei E173 is a QMI/wwan device which normally appear
> as 12d1:1436 in Linux. The descriptors displayed in that
> mode will be picked up by cdc_ether. But the modem has
> another mode with a different device ID and a slightly
> different set of descriptors. This is the mode used by
> Windows like this:
>
> 3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
> Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
> Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
> PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
>
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
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