* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Eric W. Biederman @ 2013-10-17 19:28 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: Stephen Hemminger, David Miller, yamato, netdev
In-Reply-To: <52600ABC.1030701@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 16/10/2013 21:53, Eric W. Biederman a écrit :
>> The age old question why can't we have global identifiers for
>> namespaces?
>>
>> The answer is that I don't want to implement a namespace for namespaces.
> Sorry, but I don't understand the problem. This ID is owned by the kernel, like
> the netns list (for_each_net()) is owned by it.
The scenario where problem are likely to show up is something like this.
For testing it would be reasonable to setup two linux containers that
look like full linux systems. In those containers you run one instance
of your virtual router managment daemons, and you arrange to synchronize
between the two linux containers for testing.
It becomes even more interesting when we want to migrate one of those
linux containers to another physical machine.
Global identifiers start breaking the first scenario, and really trash
the second scenario.
At the same time migration of configuration and replication of
configuration are essentially the same problem, so it would be very
silly to design such that will cause problems.
>> While the proc inode does work today across different mounts of proc, I
>> reserve the right at some future date (if it solves a technical problem)
>> to give each namespace a different inode number in each different mount
>> of proc. So the inode number is not quite the unique identifier you
>> want. The inode number is a close as I am willing to get to a namespace
>> of namespaces.
>>
>> I think the simplest solution is to just not worry about which namespace
>> the other half of a veth pair is in. But I have not encountered the
>> problem where I need to know exactly which namespace we are worrying
>> about.
> Ok, let's start by explaining our usecase.
>
> We are using namespaces only to implement virtual routers (VR), ie only
> the networking stack is virtualized. We don't care about other namespaces, we
> just want to run several network stacks and beeing able to manage them.
>
> For example, providers use this feature to isolate clients, one VR is opened
> for each client. You can have a large number of clients (+10 000) and thus the
> same number of netns.
> Considering these numbers, we don't want to run one instance per VR for all of
> our network daemons, but have only one instance that manage all VR.
>
> You also have daemons that monitor the system and synchronize network objects
> (interfaces, routes, etc.) on another linux. Goal is to implement an high
> availablity system: it's possible to switch to the other linux to avoid service
> interruption.
> This kind of daemon wants to have the full information about interfaces to be
> able to build/configure them on the other linux.
>
>>
>> Global identifiers are easy until you hit the cases where they make
>> things impossible.
> I don't want specially to use ID, but I fear that the solution with file
> descriptors will be a nightmare.
I can certainly see challenges. In asking for symmetry between set and
get the solution with file descriptors is the obvious answer and the
first answer I have been able to come up with so far.
My original answer was that the ifindex happened to be unique across
namespaces but that actually turned out to be a problem for migration
so that abandoned.
Namespace file descriptors are the solution that I know semantically
will work. Beyond that I don't have any good ideas right now.
I just know that local names (aka file descriptors) are much easier to
work with semantically than global names.
Eric
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-17 19:32 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <525CFCAF.2000605@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 15 Oct 2013 16:28:31 +0800
> The Patch Set convert the xmit of 3ad and alb mode to use rcu lock.
> dd rtnl lock and remove read lock for bond sysfs.
>
> v2 because the bond_for_each_slave_rcu without rcu_read_lock() will occurs one warming, so
> add new function for alb xmit path to avoid warming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] xen-netback: IPv6 offload support
From: David Miller @ 2013-10-17 19:36 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev
In-Reply-To: <1381942232-26268-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 16 Oct 2013 17:50:27 +0100
> This patch series adds support for checksum and large packet offloads into
> xen-netback.
> Testing has mainly been done using the Microsoft network hardware
> certification suite running in Server 2008R2 VMs with Citrix PV frontends.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] Stmmac: fix a bug when clk_csr is euqal to 0x0
From: David Miller @ 2013-10-17 19:39 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, peppe.cavallaro
In-Reply-To: <CAKT61h9Cv=g5stPBnp25XiUyfPy_NxBKxtAABUHm+GajCHMGWA@mail.gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Sat, 12 Oct 2013 10:04:20 +0800
> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
> the MDC clock. So this patch is to add other judge condition.
>
> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
There are still many problems with this patch.
Do not capitalize "Stmmac" in the subject prefix, use plain "stmmac: "
There is a typo in "equal" in the subject line.
> @@ -148,6 +149,8 @@ Where:
> GMAC also enables the 4xPBL by default.
> o fixed_burst/mixed_burst/burst_len
> o clk_csr: fixed CSR Clock range selection.
> + o dynamic_mdc_clk_en: If it is set to >=1 MDC clk will be selected
> dynamically,
> + or else you must set a fixed CSR Clock range to clk_src.
> o has_gmac: uses the GMAC core.
> o enh_desc: if sets the MAC will use the enhanced descriptor structure.
> o tx_coe: core is able to perform the tx csum in HW.
The patch has been corrupted by your email client.
^ permalink raw reply
* Re: [PATCH] usbnet: fix error return code in usbnet_probe()
From: David Miller @ 2013-10-17 19:40 UTC (permalink / raw)
To: weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w
Cc: oneukum-l3A5Bk7waGM, yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAPgLHd9jQfT2Kzi5o+3KPy0hFrkHL135K2aYp7OXcbLX4Cmkcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, 12 Oct 2013 14:24:08 +0800
> From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
>
> Fix to return -ENOMEM in the padding pkt alloc fail error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Applied, thanks Wei.
--
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] bnx2x: record rx queue for LRO packets
From: David Miller @ 2013-10-17 19:43 UTC (permalink / raw)
To: dmitry; +Cc: eric.dumazet, netdev, eilong, willemb
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F20DD4605@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 13 Oct 2013 06:23:31 +0000
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Eric Dumazet
>> Sent: Sunday, October 13, 2013 12:09 AM
>> To: David Miller
>> Cc: netdev; Eilon Greenstein; Willem de Bruijn
>> Subject: [PATCH] bnx2x: record rx queue for LRO packets
>>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> RPS support is kind of broken on bnx2x, because only non LRO packets get
>> proper rx queue information. This triggers reorders, as it seems bnx2x like to
>> generate a non LRO packet for segment including TCP PUSH flag : (this might
>> be pure coincidence, but all the reorders I've seen involve segments with a
>> PUSH)
>>
>> 11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985797>
>> 11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>>
>> We must call skb_record_rx_queue() to properly give to RPS (and more
>> generally for TX queue selection on forward path) the receive queue
>> information.
>>
>> Similar fix is needed for skb_mark_napi_id(), but will be handled in a
>> separate patch to ease stable backports.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
...
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: refactor sk_page_frag_refill()
From: David Miller @ 2013-10-17 19:46 UTC (permalink / raw)
To: eric.dumazet
Cc: mwdalton, dborkman, netdev, ffusco, ycheng, ncardwell,
digitaleric
In-Reply-To: <1381639591.3392.31.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 12 Oct 2013 21:46:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While working on virtio_net new allocation strategy to increase
> payload/truesize ratio, we found that refactoring sk_page_frag_refill()
> was needed.
>
> This patch splits sk_page_frag_refill() into two parts, adding
> page_frag_refill() which can be used without a socket.
>
> While we are at it, add a minimum frag size of 32 for
> sk_page_frag_refill()
>
> Michael will either use netdev_alloc_frag() from softirq context,
> or page_frag_refill() from process context in refill_work() (GFP_KERNEL
> allocations)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please rename this to something like "skb_page_frag_refill" so that it
is clear that this is a networking interface.
Thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: David Miller @ 2013-10-17 19:47 UTC (permalink / raw)
To: paul; +Cc: seif, netdev, thomas.petazzoni, dima
In-Reply-To: <3511324.zOrNRFllMJ@sifl>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 14 Oct 2013 11:12:47 -0400
> On Saturday, October 12, 2013 10:21:50 PM Seif Mazareeb wrote:
>> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could
>> loop forever in the main loop if opt[opt_iter +1] == 0, this will causing a
>> kernel crash in an SMP system, since the CPU executing this function will
>> stall /not respond to IPIs.
>>
>> This problem can be reproduced by running the IP Stack Integrity Checker
>> (http://isic.sourceforge.net) using the following command on a Linux machine
>> connected to DUT:
>>
>> "icmpsic -s rand -d <DUT IP address> -r 123456"
>> wait (1-2 min)
>>
>> Signed-off-by: Seif Mazareeb <seif@marvell.com>
>
> Thanks for sticking with this.
>
> Acked-by: Paul Moore <paul@paul-moore.com>
This patch, like all the others Seif submitted, has been corrupted by
his email client and is this unusable.
^ permalink raw reply
* Re: [PATCH] net/ethernet: cpsw: Bugfix interrupts before enabling napi
From: David Miller @ 2013-10-17 19:48 UTC (permalink / raw)
To: mpa; +Cc: florian, mugunthanvnm, peter, linux-arm-kernel, netdev, kernel
In-Reply-To: <1381691821-25498-1-git-send-email-mpa@pengutronix.de>
From: Markus Pargmann <mpa@pengutronix.de>
Date: Sun, 13 Oct 2013 21:17:01 +0200
> If interrupts happen before napi_enable was called, the driver will not
> work as expected. Network transmissions are impossible in this state.
> This bug can be reproduced easily by restarting the network interface in
> a loop. After some time any network transmissions on the network
> interface will fail.
>
> This patch fixes the bug by enabling napi before enabling the network
> interface interrupts.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Julian Anastasov @ 2013-10-17 19:52 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1382028894-14236-1-git-send-email-kristian.evensen@gmail.com>
Hello,
On Thu, 17 Oct 2013, Kristian Evensen wrote:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> When a link is set as down using for example "ip link set dev X down", routes
> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
> removed, and makes rtnelink route deletion behavior consistent across commands.
> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
> include required information otherwise unavailable in trie_flush_list().
>
> One use case that is simplified by this patch is IPv4 WAN connection monitoring.
> Instead of listening for and handling both RTM_*ROUTE and RTM_*LINK-messages, it
> is sufficient to handle RTM_*ROUTE.
IIRC, such notifications were not implemented
to avoid storms to routing daemons. Not sure if this is
still true.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [patch] yam: integer underflow in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014121931.GI6247@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:28:38 +0300
> We cap bitrate at YAM_MAXBITRATE in yam_ioctl(), but it could also be
> negative. I don't know the impact of using a negative bitrate but let's
> prevent it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] yam: remove a no-op in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014123726.GA17034@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:46:15 +0300
> We overwrite the ->bitrate with the user supplied information on the
> next line.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <1381807139-3450-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:58 +0800
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1381807139-3450-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:59 +0800
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
>
> The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
> (virtio-net: fix the race between channels setting and refill)
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled
From: David Miller @ 2013-10-17 19:57 UTC (permalink / raw)
To: rdunlap; +Cc: thierry.reding, linux-next, linux-kernel, broonie, netdev
In-Reply-To: <525C47C0.2000907@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 14 Oct 2013 12:36:32 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix (a few hundred) build errors due to missing semi-colon when
> KMEMCHECK is enabled:
>
> include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
> include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [net-next REPOST] 8390 ei_debug : Reenable the use of debugging in 8390 based chips
From: David Miller @ 2013-10-17 19:59 UTC (permalink / raw)
To: tedheadster; +Cc: netdev
In-Reply-To: <1381805161-18833-1-git-send-email-tedheadster@gmail.com>
From: Matthew Whitehead <tedheadster@gmail.com>
Date: Mon, 14 Oct 2013 22:46:01 -0400
> Ethernet boards based on the 8390 chip had an '#ifdef notdef' disabling the
> use of the debug variable ei_debug. Reenable it for those of us who still
> occasionally use it.
>
> Also handle the case of the 'ne' driver which uses 8390p.o rather than
> 8390.o. In that case ei_debug is aliased to eip_debug so it doesn't clash
> with the previously exported ei_debug.
>
> Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
I'd rather not encourage the use of things like this.
We have a standard, run time, way to enable and disable debugging
output on a per-netdevice basis. And the "default" value of which can
be controlled by a module parameter if need be.
Please convert the driver to this method instead.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: David Miller @ 2013-10-17 20:01 UTC (permalink / raw)
To: mrkiko.rs
Cc: gregkh, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel, anto.pellizzari83
In-Reply-To: <1381842408-10800-2-git-send-email-mrkiko.rs@gmail.com>
From: Enrico Mioso <mrkiko.rs@gmail.com>
Date: Tue, 15 Oct 2013 15:06:48 +0200
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
> Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] X.25: Fix address field length calculation
From: David Miller @ 2013-10-17 20:04 UTC (permalink / raw)
To: GKelleter; +Cc: andrew.hendry, linux-x25, netdev, linux-kernel
In-Reply-To: <525D5131.9070007@datus.com>
From: Kelleter, Günther <GKelleter@datus.com>
Date: Tue, 15 Oct 2013 14:29:06 +0000
> Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
>
> Signed-off-by: Guenther Kelleter <gkelleter@datus.com>
> ---
> Wrong length calculation leads to rejection of CALL ACCEPT packets.
This patch doesn't apply because it was severely corrupted by your
email client, turn off all encodings etc. in your client, send
a test patch to yourself, and do not submit this patch again until
you can successfully apply the patch you receive in those test emails.
Thanks.
^ permalink raw reply
* Re: pull request: wireless 2013-10-15
From: David Miller @ 2013-10-17 20:06 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131015175611.GA15706-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 15 Oct 2013 13:56:12 -0400
> Please pull this batch of fixes intended for the 3.12 stream!
>
> For the mac80211 bits, Johannes says:
>
> "Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
> probing on VLANs."
>
> And also:
>
> "This time I have two fixes from Emmanuel for RF-kill issues, and fixed
> two issues reported by Evan Huus and Thomas Lindroth respectively."
>
> On top of those...
>
> Avinash Patil adds a couple of mwifiex fixes to properly inform cfg80211
> about some different types of disconnects, avoiding WARNINGs.
>
> Mark Cave-Ayland corrects a pointer arithmetic problem in rtlwifi,
> avoiding incorrect automatic gain calculations.
>
> Solomon Peachy sends a cw1200 fix for locking around calls to
> cw1200_irq_handler, addressing "lost interrupt" problems.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 1/2] tcp: must unclone packets before mangling them
From: David Miller @ 2013-10-17 20:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381863270.2045.62.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 11:54:30 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP stack should make sure it owns skbs before mangling them.
>
> We had various crashes using bnx2x, and it turned out gso_size
> was cleared right before bnx2x driver was populating TC descriptor
> of the _previous_ packet send. TCP stack can sometime retransmit
> packets that are still in Qdisc.
>
> Of course we could make bnx2x driver more robust (using
> ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.
>
> We have identified two points where skb_unclone() was needed.
>
> This patch adds a WARN_ON_ONCE() to warn us if we missed another
> fix of this kind.
>
> Kudos to Neal for finding the root cause of this bug. Its visible
> using small MSS.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 2/2] tcp: remove the sk_can_gso() check from tcp_set_skb_tso_segs()
From: David Miller @ 2013-10-17 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381865094.2045.69.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 12:24:54 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> sk_can_gso() should only be used as a hint in tcp_sendmsg() to build GSO
> packets in the first place. (As a performance hint)
>
> Once we have GSO packets in write queue, we can not decide they are no
> longer GSO only because flow now uses a route which doesn't handle
> TSO/GSO.
>
> Core networking stack handles the case very well for us, all we need
> is keeping track of packet counts in MSS terms, regardless of
> segmentation done later (in GSO or hardware)
>
> Right now, if tcp_fragment() splits a GSO packet in two parts,
> @left and @right, and route changed through a non GSO device,
> both @left and @right have pcount set to 1, which is wrong,
> and leads to incorrect packet_count tracking.
>
> This problem was added in commit d5ac99a648 ("[TCP]: skb pcount with MTU
> discovery")
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Also applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net bridge: remove unused field
From: David Miller @ 2013-10-17 20:10 UTC (permalink / raw)
To: jhs; +Cc: shemminger, netdev
In-Reply-To: <525C5DED.1080406@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 14 Oct 2013 17:11:09 -0400
> Trivial patch
I know it seems rediculous, but anything we export to userspace, as we
do in this UAPI header, could be potentially be used by some piece of
source out there.
I'd rather just leave it be, you can add a comment saying it's unused
if you wish, but I'd really rather not remove it and run the risk of
breaking someone's build out there.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: shrink rt_cache_stat
From: David Miller @ 2013-10-17 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381916944.2045.124.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Oct 2013 02:49:04 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Half of the rt_cache_stat fields are no longer used after IP
> route cache removal, lets shrink this per cpu area.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Kristian Evensen @ 2013-10-17 20:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Network Development
In-Reply-To: <alpine.LFD.2.03.1310172245440.2016@ssi.bg>
Hi,
On Thu, Oct 17, 2013 at 9:52 PM, Julian Anastasov <ja@ssi.bg> wrote:
> IIRC, such notifications were not implemented
> to avoid storms to routing daemons. Not sure if this is
> still true.
Thanks for letting me know. I was wondering if this was the case, but
then I saw that the deletion of IPv6 routes are announced (when
running "ip link set dev X down") and assumed that message storms was
(is?) not considered a problem.
-Kristian
^ permalink raw reply
* Re: [PATCH] bridge: Correctly clamp MAX forward_delay when enabling STP
From: David Miller @ 2013-10-17 20:12 UTC (permalink / raw)
To: herbert; +Cc: vyasevic, netdev, shemminger
In-Reply-To: <20131016005657.GA5394@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 16 Oct 2013 08:56:57 +0800
> On Tue, Oct 15, 2013 at 02:57:45PM -0400, Vlad Yasevich wrote:
>> Commit be4f154d5ef0ca147ab6bcd38857a774133f5450
>> bridge: Clamp forward_delay when enabling STP
>> had a typo when attempting to clamp maximum forward delay.
>>
>> It is possible to set bridge_forward_delay to be higher then
>> permitted maximum when STP is off. When turning STP on, the
>> higher then allowed delay has to be clamed down to max value.
>>
>> CC: Herbert Xu <herbert@gondor.apana.org.au>
>> CC: Stephen Hemminger <shemminger@vyatta.com>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>
> Good catch!
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks.
^ 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