* Re: [PATCH net-next-2.6 00/17] netdev: Fix queue count initialisation
From: David Miller @ 2010-09-28 5:12 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 27 Sep 2010 19:23:11 +0100
> This adds the functions:
> - netif_set_real_num_rx_queues() - set actual number of RX queues used
> - netif_copy_real_num_queues() - copy queue counts from another device
>
> and changes all drivers that currently set
> net_device::real_num_tx_queues to use netif_set_real_num_tx_queues()
> and/or these functions.
>
> The changes are compile-tested only, except that:
> - sfc and 8021q have been briefly tested
> - gianfar and mv643xx_eth have not been compiled, since they are
> platform-specific
>
> I noticed that the bonding driver sets its numbers of queues without
> regard to its slave devices. This makes some sense since a bond device
> initially has no slave devices. However, it seems to mean that a bond
> device can pass up an skb with an out-of-range queue_index, triggering a
> warning in get_rps_cpu().
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next-2.6 16/17] tg3: Use netif_set_real_num_{rx,tx}_queues()
From: David Miller @ 2010-09-28 5:13 UTC (permalink / raw)
To: mcarlson; +Cc: bhutchings, netdev, linux-net-drivers, mchan
In-Reply-To: <20100927214416.GA32384@mcarlson.broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Mon, 27 Sep 2010 14:44:16 -0700
> On Mon, Sep 27, 2010 at 02:41:07PM -0700, Matt Carlson wrote:
>> This should be tp->irq_cnt - 1, not tp->irq_cnt. The first MSI-X vector
>> only handles link interrupts and device errors.
>
> I need to correct myself. If the irq_cnt > 1, then it needs to be
> tp->irq_cnt - 1. If the irq_cnt == 1, then it should be 1.
I fixed this when I applied Ben's patch, thanks!
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-28 5:12 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev
In-Reply-To: <20100927232857.GA23803@gondor.apana.org.au>
On Tue, Sep 28, 2010 at 08:28:57AM +0900, Herbert Xu wrote:
> Willy Tarreau <w@1wt.eu> wrote:
> >
> > Two quick facts :
> > - HTTP allows the client to send whatever it wants whenever it wants
> > and allows the server to close after whatever response it wants.
> > Thus the server cannot predict that the client will talk.
>
> No it does not. Only buggy HTTP clients do that.
I don't agree Herbert. Pipelining consists exactly in that, and is an
encouraged practice. If you say that only buggy clients send an extra
CRLF, then yes I agree. But you might very well get a new request you
can't predict at all, and the arrival of this new request must not
destroy the end of last response's data.
Once again, for now, I will only handle this precise case of the extra
CRLF, but this will not fix the issue with pipelined requests.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH v2 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar SANGHVI @ 2010-09-28 5:31 UTC (permalink / raw)
To: David Miller
Cc: remi.denis-courmont@nokia.com, netdev@vger.kernel.org,
STEricsson_nomadik_linux, Sudeep DIVAKARAN, Gulshan KARMANI,
Linus WALLEIJ
In-Reply-To: <20100927.215059.39193491.davem@davemloft.net>
On Tue, Sep 28, 2010 at 06:50:59 +0200, David Miller wrote:
> Applied, thanks.
>
> Please resubmit patch 2/2 if you want me to apply it.
Thanks David.
I will re-submit the patch 2/2.
Best regards,
Kumar.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-28 5:32 UTC (permalink / raw)
To: w; +Cc: herbert, netdev
In-Reply-To: <20100928051258.GB12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 28 Sep 2010 07:12:58 +0200
> Once again, for now, I will only handle this precise case of the extra
> CRLF, but this will not fix the issue with pipelined requests.
You might want to read server/connection.c in the apache httpd
sources.
It does exactly what Eric Dumazet and I have suggested to you.
But, I guess the entire world is wrong and you're right Willy.
^ permalink raw reply
* [PATCH 2/2] Documentation: Update Phonet doc for Pipe Controller implementation
From: Kumar A Sanghvi @ 2010-09-28 5:35 UTC (permalink / raw)
To: remi.denis-courmont, davem, netdev
Cc: STEricsson_nomadik_linux, sudeep.divakaran, gulshan.karmani,
Kumar Sanghvi, Linus Walleij
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Updates the Phonet document with description related to Pipe controller
implementation
Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
Documentation/networking/phonet.txt | 53 +++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt
index cf76608..cccf5ff 100644
--- a/Documentation/networking/phonet.txt
+++ b/Documentation/networking/phonet.txt
@@ -182,6 +182,59 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level:
or zero if encapsulation is off.
+Phonet Pipe-controller Implementation
+-------------------------------------
+
+Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig
+option. It is useful when communicating with those Nokia Modems which do not
+implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson
+U8500 platform.
+
+The implementation is based on the Data Connection Establishment Sequence
+depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf'
+document.
+
+It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection
+between itself and a remote pipe-end point (e.g. modem).
+
+The implementation adds socket options at SOL_PNPIPE level:
+
+ PNPIPE_CREATE
+ It accepts an integer argument where-in
+ lower order 16 bits: pn_dev and pn_port pair for remote pep.
+ higher order 16 bits: 8 bit pipe-handle
+
+ It sends a PNS_PEP_CONNECT_REQ on sequenced socket itself. On getting
+ PNS_PEP_CONNECT_RESP, it sends PNS_PEP_CONNECT_REQ to remote pep. On
+ getting response from remote pep, it selects the best possible Flow
+ control mechanism supported by remote-pep (modem) and then it sends
+ PNS_PEP_CREATED_IND to the sequenced socket and to the remote pep.
+
+ It then updates the pipe state associated with the sequenced socket to
+ be PIPE_DISABLED.
+
+ PNPIPE_ENABLE
+ It follows the same sequence as above for enabling a pipe by sending
+ PNS_PEP_ENABLE_REQ initially and then sending PNS_PEP_ENABLED_IND after
+ getting responses from sequenced socket and remote-pep.
+ It will also update the pipe state associated with the sequenced socket
+ to PIPE_ENABLED.
+
+ PNPIPE_DESTROY
+ This will send out PNS_PEP_DISCONNECT_REQ on the sequenced socket and
+ the remote pep.
+ It will also update the pipe state associated with the sequenced socket
+ to PIPE_IDLE
+
+ PNPIPE_INQ
+ This getsocktopt allows the user-space running on the sequenced socket
+ to examine the pipe state associated with that socket ie. whether the
+ pipe is created (PIPE_DISABLED) or enabled (PIPE_ENABLED) or disabled
+ (PIPE_DISABLED) or no pipe exists (PIPE_IDLE).
+
+After a pipe has been created and enabled successfully, the Pipe data can be
+exchanged between the host-pep and remote-pep (modem).
+
Authors
-------
--
1.7.2.dirty
^ permalink raw reply related
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-28 5:37 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20100927.223231.179927955.davem@davemloft.net>
On Mon, Sep 27, 2010 at 10:32:31PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Tue, 28 Sep 2010 07:12:58 +0200
>
> > Once again, for now, I will only handle this precise case of the extra
> > CRLF, but this will not fix the issue with pipelined requests.
>
> You might want to read server/connection.c in the apache httpd
> sources.
>
> It does exactly what Eric Dumazet and I have suggested to you.
I've seen that. Though nginx, squid, thttpd, haproxy and lighttpd all
make use of the standard orphans and are all affected by the same issue.
> But, I guess the entire world is wrong and you're right Willy.
Given the figures above, that's not how I analyze it, I'm sorry.
Willy
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: Update Phonet doc for Pipe Controller implementation
From: David Miller @ 2010-09-28 6:30 UTC (permalink / raw)
To: kumar.sanghvi
Cc: remi.denis-courmont, netdev, STEricsson_nomadik_linux,
sudeep.divakaran, gulshan.karmani, linus.walleij
In-Reply-To: <1285652106-29966-1-git-send-email-kumar.sanghvi@stericsson.com>
From: Kumar A Sanghvi <kumar.sanghvi@stericsson.com>
Date: Tue, 28 Sep 2010 11:05:06 +0530
> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>
> Updates the Phonet document with description related to Pipe controller
> implementation
>
> Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-28 6:34 UTC (permalink / raw)
To: M. Warner Losh
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, johnstul-r/Jw6+rmf7HQT0dZR+AlfA,
giometti-k2GhghHVRtY, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khc-9GfyWEdoJtJmR6Xm/wNWPw
In-Reply-To: <20100927.101423.702773873740300798.imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
On Mon, Sep 27, 2010 at 10:14:23AM -0600, M. Warner Losh wrote:
>
> This is a common error that I've seen repeated in this thread. The
> only reason that it has historically been important is because when
> you are doing timestamping in software based on an interrupt, that
> stuff does matter.
Yes, thanks for your helpful explanation.
To further illustrate how small the effect of running the servo in
user space is, consider the following.
It is true that delays and jitter in the time to process the received
packet negatively affect the clock servo loop. However, the effect in
our case will be quite small.
John Eidson's book [1] presents a rigorous servo model that includes
an analysis of the delay from the time the samples (timestamps) are
taken until the corrective action is performed by the PTP software.
For PTP, the sample time is at the sender (the remote host, the master
clock). The master sends *two* packets, where the second one (the so
called follow-up packet) contains the hardware time stamp of the first
one. So, the computational delay includes the time spent by the sender
in its PTP stack preparing the second packet, the time the packet
spends in transit, and the time in the receiver's PTP stack and servo.
According to Eidson's analysis, a delay of up to 10 milliseconds would
be acceptable, even with a sample rate of 10 Hz. Therefore, saving a
few dozen microseconds by placing the servo (and PTP stack) into the
kernel is not worth the effort.
Richard
[1] title = {Measurement, control, and communication using IEEE 1588},
author = {J. C. Eidson},
year = 2006,
publisher = {Springer-Verlag},
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-28 6:47 UTC (permalink / raw)
To: Alan Cox
Cc: Christoph Lameter, linux-kernel, devicetree-discuss, linux-api,
linux-arm-kernel, linuxppc-dev, netdev, Arnd Bergmann,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100927180558.52817d5f@lxorguk.ukuu.org.uk>
On Mon, Sep 27, 2010 at 06:05:58PM +0100, Alan Cox wrote:
> On Mon, 27 Sep 2010 10:56:09 -0500 (CDT)
> Christoph Lameter <cl@linux.com> wrote:
>
> >
> > On Fri, 24 Sep 2010, Alan Cox wrote:
> >
> > > Whether you add new syscalls or do the fd passing using flags and hide
> > > the ugly bits in glibc is another question.
> >
> > Use device specific ioctls instead of syscalls?
>
> Some of the ioctls are probably not device specific, the job of the OS in
> part is to present a unified interface. We already have a mess of HPET
> and RTC driver ioctls.
Yes, and the whole point of introducing a PTP hardare clock API was to
avoid each new clock driver introducing yet another ioctl interface.
I had proposed a standard ioctl interface for PTP hardware clocks, but
that interface was rightly criticized for duplicating the posix clock
API. It does not make sense to have multiple interfaces with the exact
same functionality.
It is impossible to support every last feature of every possible
hardware clock with a generic interface, so there will always need to
be special ioctls for such features.
However, some clock functions *are* completely generic and apply to
every clock:
- set time
- get time
- adjust the frequency by N ppb
- shift the time by a given offset
The first two are provided by the posix clock interface, the third by
the NTP adjtimex call, which also can support (by a single mode
extension) the last item.
Richard
^ permalink raw reply
* [PATCH net-next-2.6] dummy: percpu stats and lockless xmit
From: Eric Dumazet @ 2010-09-28 6:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Converts dummy network device driver to :
- percpu stats
- 64bit stats
- lockless xmit (NETIF_F_LLTX)
- performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/dummy.c | 58 ++++++++++++++++++++++++++++++++++--
include/linux/netdevice.h | 1
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index 37dcfdc..ff2d29b 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -36,6 +36,7 @@
#include <linux/moduleparam.h>
#include <linux/rtnetlink.h>
#include <net/rtnetlink.h>
+#include <linux/u64_stats_sync.h>
static int numdummies = 1;
@@ -55,21 +56,69 @@ static void set_multicast_list(struct net_device *dev)
{
}
+struct pcpu_dstats {
+ u64 tx_packets;
+ u64 tx_bytes;
+ struct u64_stats_sync syncp;
+};
+
+static struct rtnl_link_stats64 *dummy_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
+{
+ int i;
+
+ for_each_possible_cpu(i) {
+ const struct pcpu_dstats *dstats;
+ u64 tbytes, tpackets;
+ unsigned int start;
+
+ dstats = per_cpu_ptr(dev->dstats, i);
+ do {
+ start = u64_stats_fetch_begin(&dstats->syncp);
+ tbytes = dstats->tx_bytes;
+ tpackets = dstats->tx_packets;
+ } while (u64_stats_fetch_retry(&dstats->syncp, start));
+ stats->tx_bytes += tbytes;
+ stats->tx_packets += tpackets;
+ }
+ return stats;
+}
static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
{
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
+ struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
+
+ u64_stats_update_begin(&dstats->syncp);
+ dstats->tx_packets++;
+ dstats->tx_bytes += skb->len;
+ u64_stats_update_end(&dstats->syncp);
dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
+static int dummy_dev_init(struct net_device *dev)
+{
+ dev->dstats = alloc_percpu(struct pcpu_dstats);
+ if (!dev->dstats)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void dummy_dev_free(struct net_device *dev)
+{
+ free_percpu(dev->dstats);
+ free_netdev(dev);
+}
+
static const struct net_device_ops dummy_netdev_ops = {
+ .ndo_init = dummy_dev_init,
.ndo_start_xmit = dummy_xmit,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_multicast_list = set_multicast_list,
.ndo_set_mac_address = dummy_set_address,
+ .ndo_get_stats64 = dummy_get_stats64,
};
static void dummy_setup(struct net_device *dev)
@@ -78,14 +127,17 @@ static void dummy_setup(struct net_device *dev)
/* Initialize the device structure. */
dev->netdev_ops = &dummy_netdev_ops;
- dev->destructor = free_netdev;
+ dev->destructor = dummy_dev_free;
/* Fill in device structure with ethernet-generic values. */
dev->tx_queue_len = 0;
dev->flags |= IFF_NOARP;
dev->flags &= ~IFF_MULTICAST;
+ dev->features |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
+ dev->features |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
random_ether_addr(dev->dev_addr);
}
+
static int dummy_validate(struct nlattr *tb[], struct nlattr *data[])
{
if (tb[IFLA_ADDRESS]) {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 83de0eb..6cff445 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1054,6 +1054,7 @@ struct net_device {
void *ml_priv;
struct pcpu_lstats __percpu *lstats; /* loopback stats */
struct pcpu_tstats __percpu *tstats; /* tunnel stats */
+ struct pcpu_dstats __percpu *dstats; /* dummy stats */
};
/* GARP */
struct garp_port *garp_port;
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2010-09-28 7:22 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) AF_ROSE digi count signedness fix
2) On 64-bit, send() with iov_len >= 4GB can fail on TCP.
3) qlcnic assumes NET_IP_ALIGN is 2, use the macro instead of assuming.
From Eric Dumazet.
4) ip_gre needs to check both CONFIG_IPV6 and CONFIG_IPV6_MODULE,
also from Eric.
5) qlcnic and netxen corrupt skb->truesize breaking socket level and
system-wide net buffer memory accounting. Also from Eric Dumazet.
6) IP fragmentation can corrupt skb->truesize resulting in corrupt
socket memory accounting, and stuck sockets (since the memory
charge goes negative). From Eric Dumazet.
7) 3c59x WOL support added some regressions (assumes PCI, which not
all 3c59x are, also tries to erroneously hit the card when in D3)
Fix from Jan Beulich.
8) Memory leak in wext private ioctls, fix from Johannes Berg.
9) Fix ATM br2684 scheduling-while-atomic, was invoking atomic notifier
chain unregister with locks held and irqs disabled, from Karl Hiramoto.
10) Fix drivers using kfree() on a netdev which is always wrong,
need to always use free_netdev(). From Kulikov Vasiliy and
Vasiliy Kulikov.
11) Fix broken resume, and forgetting to clear CMB and SBM in ring
release, in atl1 driver. From Luca Tettamanti.
12) Missing unregister_pernet_subsys call in ipv6, from Neil Horman.
13) "struct net" needs __KERNEL__ guard, from Ollie Wild.
14) Several de2104x tulip link handling fixes from Ondrej Zary.
15) net/9p virtio code string comparison is busted, fix from Sven Eckelmann.
16) IPSEC xfrm code uses wrong address family sometimes, from Thomas Egerer.
17) Traversing a tunnel requires resetting the RX queue setting, since
downstream device might have different number of queues. From
Tom Herbert.
18) Fix hopefully the last race in our lockless tcp_poll, from
Tom Marshall.
19) ipv4 ipsec code erroneously include ECN bits in the TOS it uses,
which will cause route failures since those bits have internal
meaning in the ipv4 routing code. From Ulrich Weber.
20) Both ipv4 and ipv6 routing code spew "Neighbour table overflow"
making it impossible to tell which of the two the notification is
about. Fix the log messages to be prefixed with "ipv{4,6}:"
From Ulrich Weber.
21) ip_route_newport() needs to handle tproxy just as
ip_route_connect() does, also from Ulrich Weber.
22) smsc911x missing module alias, from Vincent Stehlé.
23) Don't force a reset during scan in iwlwif, from Wey-Yi Guy.
24) tcp_mark_head_lost() mismarks segmented packets when doing FACK,
fix from Yuchung Cheng.
25) e1000e bug fixes from Bruce Alan:
a) Handle bugs in Sx state.
b) Device reset leaves LEDs and SMBUS address in wrong state
c) 82566DC link failure
d) jumbo frames erroneously generate CRC errors
26) Netfilter bug fixes via Patrick McHardy
a) ipt_REJECT mis-routes when indev==outdev (Changli Gao)
b) nf_ct_ext_create() can race (Eric Dumazet)
c) fix dangerous blind test of ->nodefrag (Jiri Olsa)
d) nf_nat_snmp incorrect csums (Patrick McHardy)
e) sip_help_tcp() should default to NF_ACCEPT (Simon Horman)
27) vhost bug fixes from Michael S. Tsirkin
a) vhost-net range checking fix
b) log ctx signalling inadvertantly in dead code
Please pull, thanks a lot!
The following changes since commit 252a52aa4fa22a668f019e55b3aac3ff71ec1c29:
Fix pktcdvd ioctl dev_minor range check (2010-09-27 16:29:06 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Bruce Allan (6):
e1000e: 82577/8/9 issues with device in Sx
e1000e: 82579 SMBus address and LEDs incorrect after device reset
e1000e: 82566DC fails to get link
e1000e: 82579 unaccounted missed packets
e1000e: 82579 jumbo frame workaround causing CRC errors
e1000e: 82579 do not gate auto config of PHY by hardware during nominal use
Changli Gao (1):
netfilter: fix ipt_REJECT TCP RST routing for indev == outdev
David S. Miller (5):
Merge branch 'vhost-net' of git://git.kernel.org/.../mst/vhost
rose: Fix signedness issues wrt. digi count.
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'vhost-net' of git://git.kernel.org/.../mst/vhost
tcp: Fix >4GB writes on 64-bit.
Eric Dumazet (8):
qlcnic: dont assume NET_IP_ALIGN is 2
ip_gre: CONFIG_IPV6_MODULE support
qlcnic: dont set skb->truesize
netxen: dont set skb->truesize
ip: fix truesize mismatch in ip fragmentation
netfilter: tproxy: nf_tproxy_assign_sock() can handle tw sockets
netfilter: fix a race in nf_ct_ext_create()
net: fix a lockdep splat
Jan Beulich (1):
3c59x: fix regression from patch "Add ethtool WOL support"
Jiri Olsa (1):
netfilter: nf_conntrack_defrag: check socket type before touching nodefrag flag
Johannes Berg (1):
wext: fix potential private ioctl memory content leak
Karl Hiramoto (1):
br2684: fix scheduling while atomic
Kulikov Vasiliy (3):
ibm_newemac: use free_netdev(netdev) instead of kfree()
rionet: use free_netdev(netdev) instead of kfree()
sgiseeq: use free_netdev(netdev) instead of kfree()
Luca Tettamanti (2):
atl1: fix resume
atl1: zero out CMB and SBM in atl1_free_ring_resources
Michael S. Tsirkin (2):
vhost-net: fix range checking in mrg bufs case
vhost: fix log ctx signalling
Neil Horman (1):
ipv6: add a missing unregister_pernet_subsys call
Ollie Wild (1):
net: Move "struct net" declaration inside the __KERNEL__ macro guard
Ondrej Zary (4):
de2104x: disable autonegotiation on broken hardware
de2104x: fix power management
de2104x: fix TP link detection
de2104x: fix ethtool
Patrick McHardy (1):
netfilter: nf_nat_snmp: fix checksum calculation (v4)
Simon Horman (1):
netfilter: nf_ct_sip: default to NF_ACCEPT in sip_help_tcp()
Sven Eckelmann (1):
net/9p: Mount only matching virtio channels
Thomas Egerer (1):
xfrm: Allow different selector family in temporary state
Tom Herbert (1):
net: reset skb queue mapping when rx'ing over tunnel
Tom Marshall (1):
tcp: Fix race in tcp_poll
Ulrich Weber (3):
xfrm4: strip ECN bits from tos field
ipv6: add IPv6 to neighbour table overflow warning
tproxy: check for transparent flag in ip_route_newports
Vasiliy Kulikov (1):
s390: use free_netdev(netdev) instead of kfree()
Vincent Stehlé (1):
smsc911x: Add MODULE_ALIAS()
Wey-Yi Guy (1):
iwlwifi: do not perferm force reset while doing scan
Yuchung Cheng (1):
tcp: fix TSO FACK loss marking in tcp_mark_head_lost
drivers/net/3c59x.c | 10 ++
drivers/net/atlx/atl1.c | 11 ++-
drivers/net/e1000e/hw.h | 1 +
drivers/net/e1000e/ich8lan.c | 197 +++++++++++++++++++++++++-----
drivers/net/e1000e/netdev.c | 29 +++--
drivers/net/ibm_newemac/core.c | 4 +-
drivers/net/netxen/netxen_nic_init.c | 3 -
drivers/net/qlcnic/qlcnic_init.c | 7 +-
drivers/net/rionet.c | 2 +-
drivers/net/sgiseeq.c | 2 +-
drivers/net/smsc911x.c | 1 +
drivers/net/tulip/de2104x.c | 43 ++++++-
drivers/net/wireless/iwlwifi/iwl-core.c | 5 +
drivers/s390/net/ctcm_main.c | 4 +-
drivers/vhost/net.c | 2 +-
drivers/vhost/vhost.c | 7 +-
include/linux/netlink.h | 4 +-
include/linux/socket.h | 2 +-
include/net/addrconf.h | 1 +
include/net/dst.h | 1 +
include/net/route.h | 2 +
include/net/xfrm.h | 4 +-
net/9p/trans_virtio.c | 3 +-
net/atm/br2684.c | 12 +--
net/core/iovec.c | 5 +-
net/core/sock.c | 8 +-
net/ipv4/ip_gre.c | 8 +-
net/ipv4/ip_output.c | 19 ++-
net/ipv4/netfilter/ipt_REJECT.c | 1 +
net/ipv4/netfilter/nf_defrag_ipv4.c | 4 +-
net/ipv4/netfilter/nf_nat_snmp_basic.c | 6 +-
net/ipv4/route.c | 2 +-
net/ipv4/tcp.c | 9 +-
net/ipv4/tcp_input.c | 5 +-
net/ipv4/xfrm4_policy.c | 2 +-
net/ipv4/xfrm4_state.c | 33 +++--
net/ipv6/addrconf.c | 11 ++-
net/ipv6/addrlabel.c | 5 +
net/ipv6/ip6_output.c | 18 ++-
net/ipv6/route.c | 2 +-
net/ipv6/xfrm6_state.c | 33 +++--
net/netfilter/nf_conntrack_extend.c | 4 +-
net/netfilter/nf_conntrack_sip.c | 2 +-
net/netfilter/nf_tproxy_core.c | 6 +-
net/rds/tcp_connect.c | 4 +-
net/rds/tcp_listen.c | 4 +-
net/rds/tcp_recv.c | 4 +-
net/rds/tcp_send.c | 4 +-
net/rose/af_rose.c | 4 +-
net/sunrpc/xprtsock.c | 28 ++--
net/wireless/wext-priv.c | 2 +-
net/xfrm/xfrm_policy.c | 5 +-
net/xfrm/xfrm_state.c | 45 ++++---
53 files changed, 444 insertions(+), 196 deletions(-)
^ permalink raw reply
* Re: [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries
From: Yuri Chislov @ 2010-09-28 7:40 UTC (permalink / raw)
To: David Miller; +Cc: damian, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20100927.215241.246534990.davem@davemloft.net>
What is advantage in the replace compare by calculation?
Please clarify, if possible.
Thanks.
Yuri.
--- linux-2.6.31.14/net/ipv4/tcp_timer.c 2010-07-05 17:11:43.000000000
+0000
+++ linux-2.6.32.15/net/ipv4/tcp_timer.c 2010-06-01 16:56:03.000000000
+0000
@@ -137,13 +137,14 @@
{
struct inet_connection_sock *icsk = inet_csk(sk);
int retry_until;
+ bool do_reset;
if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
if (icsk->icsk_retransmits)
dst_negative_advice(&sk->sk_dst_cache);
retry_until = icsk->icsk_syn_retries ? :
sysctl_tcp_syn_retries;
} else {
- if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
+ if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
/* Black hole detection */
tcp_mtu_probing(icsk, sk);
@@ -155,13 +156,15 @@
const int alive = (icsk->icsk_rto < TCP_RTO_MAX);
retry_until = tcp_orphan_retries(sk, alive);
+ do_reset = alive ||
+ !retransmits_timed_out(sk, retry_until);
- if (tcp_out_of_resources(sk, alive || icsk-
>icsk_retransmits < retry_until))
+ if (tcp_out_of_resources(sk, do_reset))
return 1;
}
}
- if (icsk->icsk_retransmits >= retry_until) {
+ if (retransmits_timed_out(sk, retry_until)) {
/* Has it gone just too far? */
tcp_write_err(sk);
return 1;
@@ -279,7 +282,7 @@
* The TCP retransmit timer.
*/
-static void tcp_retransmit_timer(struct sock *sk)
+void tcp_retransmit_timer(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -385,7 +388,7 @@
out_reset_timer:
icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto,
TCP_RTO_MAX);
- if (icsk->icsk_retransmits > sysctl_tcp_retries1)
+ if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1))
__sk_dst_reset(sk);
out:;
@@ -499,8 +502,7 @@
elapsed = tcp_time_stamp - tp->rcv_tstamp;
if (elapsed >= keepalive_time_when(tp)) {
- if ((!tp->keepalive_probes && icsk->icsk_probes_out >=
sysctl_tcp_keepalive_probes) ||
- (tp->keepalive_probes && icsk->icsk_probes_out >= tp-
>keepalive_probes)) {
+ if (icsk->icsk_probes_out >= keepalive_probes(tp)) {
tcp_send_active_reset(sk, GFP_ATOMIC);
tcp_write_err(sk);
goto out;
On Tuesday, September 28, 2010 06:52:41 am David Miller wrote:
> From: Damian Lukowski <damian@tvk.rwth-aachen.de>
> Date: Mon, 27 Sep 2010 22:00:08 +0200
>
> > My suggestion for solving this issue:
> > Introducing a third boolean parameter for retransmits_timed_out()
> > indicating whether the socket is in SYN state or not. In the SYN case,
> > TCP_TIMEOUT_INIT will be used for the calculation instead of
> > TCP_RTO_MIN.
> >
> > Is that ok?
>
> Sounds fine to me, please prepare a patch.
>
> Thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6] dummy: percpu stats and lockless xmit
From: Stephen Hemminger @ 2010-09-28 7:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller
In-Reply-To: <1285656633.10438.35.camel@edumazet-laptop>
> Converts dummy network device driver to :
>
> - percpu stats
>
> - 64bit stats
>
> - lockless xmit (NETIF_F_LLTX)
>
> - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
> NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
IFB device could use many of these enhancements.
^ permalink raw reply
* Re: [PATCH net-next-2.6] dummy: percpu stats and lockless xmit
From: Eric Dumazet @ 2010-09-28 8:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Miller
In-Reply-To: <636709308.22102.1285660327977.JavaMail.root@tahiti.vyatta.com>
Le mardi 28 septembre 2010 à 00:52 -0700, Stephen Hemminger a écrit :
> > Converts dummy network device driver to :
> >
> > - percpu stats
> >
> > - 64bit stats
> >
> > - lockless xmit (NETIF_F_LLTX)
> >
> > - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
> > NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> IFB device could use many of these enhancements.
Yes, probably ;)
I was considering the NETIF_F_NETNS_LOCAL, should we set it for dummy
device ?
^ permalink raw reply
* Re: [PATCH] ip_gre: CONFIG_IPV6_MODULE support
From: Herbert Xu @ 2010-09-28 8:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1284987700.3420.333.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> ipv6 can be a module, we should test CONFIG_IPV6 and CONFIG_IPV6_MODULE
> to enable ipv6 bits in ip_gre.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
To do this safely, we also need to disallow IPV6=m and GRE=y.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ip_gre: CONFIG_IPV6_MODULE support
From: Eric Dumazet @ 2010-09-28 8:48 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev
In-Reply-To: <20100928084139.GA26793@gondor.apana.org.au>
Le mardi 28 septembre 2010 à 17:41 +0900, Herbert Xu a écrit :
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > ipv6 can be a module, we should test CONFIG_IPV6 and CONFIG_IPV6_MODULE
> > to enable ipv6 bits in ip_gre.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> To do this safely, we also need to disallow IPV6=m and GRE=y.
>
> Cheers,
Hmm you are right, I'll cook a patch.
Thanks
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Julian Anastasov @ 2010-09-28 9:01 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20100927192450.GU12373@1wt.eu>
Hello,
On Mon, 27 Sep 2010, Willy Tarreau wrote:
>> - add this FD in some list for monitoring instead of keeping
>> large connection state
>> - use shutdown SHUT_WR to add FIN after response
>> - use setsockopt SO_RCVBUF with some low value to close the
>> RX window, we do not want the body
>> - wait for POLLHUP (FIN), not for POLLIN because we want to
>> ignore data, not to read it. Still, data can be read and
>> dropped if needed to release the socket memory
>> - use timer to limit the time we wait our data to be acked
>> - use SIOCOUTQ to know if everything is received in peer and
>> then close the fd
>
> Thanks very much for this suggestion. I was looking for something
> like this and even looked at the tcp_info struct, but it did not
> look very easy to use.
>
> Still, I think that polling on POLLIN and checking with SIOCOUTQ
> on every read to see if the out queue is now empty would do the
> trick, without forcing to read huge amounts of unnecessary data.
>
> I'll simply enclose that inside a #ifdef LINUX and that should be
> OK. It kinda sucks to be able to workaround low level issues at the
> application level but at least this workaround is acceptable.
I think for another option but I don't know the TCP details
well:
- If SO_RCVBUF=0 really closes RX window
and
- while (read() > 0) {} gets all unread data
- just call close() to convert socket to orphan without a risk
of RST
Now when we are orphan socket I'm not sure what has
priority:
- if new DATA is flying to us, is it considered out of window,
do we send RST in FIN_WAIT1/CLOSING/LAST_ACK state in this case?
If we do not send RST then our goal is achieved: send everything
reliably without accepting data that needs RST. And we do not
need to keep fd in user space.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net-next-2.6] ip_gre: lockless xmit
From: Eric Dumazet @ 2010-09-28 9:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
GRE tunnels can benefit from lockless xmits, using NETIF_F_LLTX
Note: If tunnels are created with the "oseq" option, LLTX is not
enabled :
Even using an atomic_t o_seq, we would increase chance for packets being
out of order at receiver.
Bench on a 16 cpus machine (dual E5540 cpus), 16 threads sending
10000000 UDP frames via one gre tunnel (size:200 bytes per frame)
Before patch :
real 3m0.094s
user 0m9.365s
sys 47m50.103s
After patch:
real 0m29.756s
user 0m11.097s
sys 7m33.012s
Last problem to solve is the contention on dst :
38660.00 21.4% __ip_route_output_key vmlinux
20786.00 11.5% dst_release vmlinux
14191.00 7.8% __xfrm_lookup vmlinux
12410.00 6.9% ip_finish_output vmlinux
4540.00 2.5% ip_push_pending_frames vmlinux
4427.00 2.4% ip_append_data vmlinux
4265.00 2.4% __alloc_skb vmlinux
4140.00 2.3% __ip_local_out vmlinux
3991.00 2.2% dev_queue_xmit vmlinux
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_gre.c | 4 ++++
1 files changed, 4 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index a1b5d5e..035db63 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1557,6 +1557,10 @@ static int ipgre_newlink(struct net *src_net, struct net_device *dev, struct nla
if (!tb[IFLA_MTU])
dev->mtu = mtu;
+ /* Can use a lockless transmit, unless we generate output sequences */
+ if (!(nt->parms.o_flags & GRE_SEQ))
+ dev->features |= NETIF_F_LLTX;
+
err = register_netdevice(dev);
if (err)
goto out;
^ permalink raw reply related
* [PATCH] Phonet: Correct header retrieval after pskb_may_pull
From: Kumar A Sanghvi @ 2010-09-28 9:10 UTC (permalink / raw)
To: netdev, davem, remi.denis-courmont, eric.dumazet
Cc: gulshan.karmani, Kumar Sanghvi, Linus Walleij
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Retrieve the header after doing pskb_may_pull since, pskb_may_pull
could change the buffer structure.
This is based on the comment given by Eric Dumazet on Phonet
Pipe controller patch for a similar problem.
Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
net/phonet/pep.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index 7bf23cf..9746c6d 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -507,12 +507,13 @@ static void pipe_grant_credits(struct sock *sk)
static int pipe_rcv_status(struct sock *sk, struct sk_buff *skb)
{
struct pep_sock *pn = pep_sk(sk);
- struct pnpipehdr *hdr = pnp_hdr(skb);
+ struct pnpipehdr *hdr;
int wake = 0;
if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
return -EINVAL;
+ hdr = pnp_hdr(skb);
if (hdr->data[0] != PN_PEP_TYPE_COMMON) {
LIMIT_NETDEBUG(KERN_DEBUG"Phonet unknown PEP type: %u\n",
(unsigned)hdr->data[0]);
--
1.7.2.dirty
^ permalink raw reply related
* RE: [PATCH net-next-2.6 04/17] bnx2x: Use netif_set_real_num_{rx,tx}_queues()
From: Vladislav Zolotarov @ 2010-09-28 9:26 UTC (permalink / raw)
To: Ben Hutchings, David Miller
Cc: netdev@vger.kernel.org, linux-net-drivers@solarflare.com,
Eilon Greenstein
In-Reply-To: <1285611927.2263.296.camel@achroite.uk.solarflarecom.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Ben Hutchings
> Sent: Monday, September 27, 2010 8:25 PM
> To: David Miller
> Cc: netdev@vger.kernel.org; linux-net-drivers@solarflare.com; Eilon
> Greenstein
> Subject: [PATCH net-next-2.6 04/17] bnx2x: Use
> netif_set_real_num_{rx,tx}_queues()
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/bnx2x/bnx2x_cmn.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_cmn.c
> b/drivers/net/bnx2x/bnx2x_cmn.c
> index efc7be4..05c05a4 100644
> --- a/drivers/net/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/bnx2x/bnx2x_cmn.c
> @@ -1207,8 +1207,8 @@ static int bnx2x_set_num_queues(struct bnx2x *bp)
> bp->num_queues = 1;
> break;
> }
> - bp->dev->real_num_tx_queues = bp->num_queues;
> - return rc;
> + netif_set_real_num_tx_queues(bp->dev, bp->num_queues);
> + return netif_set_real_num_rx_queues(bp->dev, bp->num_queues);
> }
>
> static void bnx2x_release_firmware(struct bnx2x *bp)
> @@ -1240,6 +1240,8 @@ int bnx2x_nic_load(struct bnx2x *bp, int
> load_mode)
> bp->state = BNX2X_STATE_OPENING_WAIT4_LOAD;
>
> rc = bnx2x_set_num_queues(bp);
> + if (rc)
> + return rc;
>
> if (bnx2x_alloc_mem(bp)) {
> bnx2x_free_irq(bp, true);
> --
> 1.7.2.1
>
This patch breaks our interrupt enablement flow. I'll send the new one that incorporates the netif_set_real_num_rx_queues() shortly.
Thanks,
vlad
>
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
> --
> 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: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-28 9:26 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1009281139430.1506@ja.ssi.bg>
Hello Julian,
On Tue, Sep 28, 2010 at 12:01:42PM +0300, Julian Anastasov wrote:
> I think for another option but I don't know the TCP details
> well:
>
> - If SO_RCVBUF=0 really closes RX window
I've been wondering what happens to an incoming data after the RX window
is closed. Is the packet just dropped or may it still be queued. In fact,
my concerns are : if SO_RCVBUF=0 just advertises a zero window, we can
only be sure about the flush after an RTT. However, if it really prevents
the receive side from accepting new data, then I agree we're safe.
> and
>
> - while (read() > 0) {} gets all unread data
During my tests on other products, I found that squid does that without
the zero window, possibly resulting in an infinite loop when the sender
is faster than the receiver. In our case, if the zero window works, it
should not be an issue.
> - just call close() to convert socket to orphan without a risk
> of RST
>
> Now when we are orphan socket I'm not sure what has
> priority:
>
> - if new DATA is flying to us, is it considered out of window,
> do we send RST in FIN_WAIT1/CLOSING/LAST_ACK state in this case?
> If we do not send RST then our goal is achieved: send everything
> reliably without accepting data that needs RST. And we do not
> need to keep fd in user space.
>From what I have observed, the issue is only for data present before
the close. Upon FIN_WAIT1/CLOSING/LAST_ACK, we get the expected reset
once the ACK acknowledges the last data sent, but I've not observed
it for new data.
Best regards,
Willy
^ permalink raw reply
* Re: [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries
From: Ilpo Järvinen @ 2010-09-28 9:47 UTC (permalink / raw)
To: Yuri Chislov
Cc: David Miller, damian, Andrew Morton, Netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <201009280940.53153.yuri@itinteg.net>
On Tue, 28 Sep 2010, Yuri Chislov wrote:
> What is advantage in the replace compare by calculation?
> Please clarify, if possible.
> Thanks.
> Yuri.
If you did take this from kernel history, reading the particular log
message might have helped?!?
> --- linux-2.6.31.14/net/ipv4/tcp_timer.c 2010-07-05 17:11:43.000000000
> +0000
> +++ linux-2.6.32.15/net/ipv4/tcp_timer.c 2010-06-01 16:56:03.000000000
> +0000
> @@ -137,13 +137,14 @@
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> int retry_until;
> + bool do_reset;
>
> if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> if (icsk->icsk_retransmits)
> dst_negative_advice(&sk->sk_dst_cache);
> retry_until = icsk->icsk_syn_retries ? :
> sysctl_tcp_syn_retries;
> } else {
> - if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
> + if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
> /* Black hole detection */
> tcp_mtu_probing(icsk, sk);
>
> @@ -155,13 +156,15 @@
> const int alive = (icsk->icsk_rto < TCP_RTO_MAX);
>
> retry_until = tcp_orphan_retries(sk, alive);
> + do_reset = alive ||
> + !retransmits_timed_out(sk, retry_until);
>
> - if (tcp_out_of_resources(sk, alive || icsk-
> >icsk_retransmits < retry_until))
> + if (tcp_out_of_resources(sk, do_reset))
> return 1;
> }
> }
>
> - if (icsk->icsk_retransmits >= retry_until) {
> + if (retransmits_timed_out(sk, retry_until)) {
> /* Has it gone just too far? */
> tcp_write_err(sk);
> return 1;
> @@ -279,7 +282,7 @@
> * The TCP retransmit timer.
> */
>
> -static void tcp_retransmit_timer(struct sock *sk)
> +void tcp_retransmit_timer(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> struct inet_connection_sock *icsk = inet_csk(sk);
> @@ -385,7 +388,7 @@
> out_reset_timer:
> icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto,
> TCP_RTO_MAX);
> - if (icsk->icsk_retransmits > sysctl_tcp_retries1)
> + if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1))
> __sk_dst_reset(sk);
>
> out:;
> @@ -499,8 +502,7 @@
> elapsed = tcp_time_stamp - tp->rcv_tstamp;
>
> if (elapsed >= keepalive_time_when(tp)) {
> - if ((!tp->keepalive_probes && icsk->icsk_probes_out >=
> sysctl_tcp_keepalive_probes) ||
> - (tp->keepalive_probes && icsk->icsk_probes_out >= tp-
> >keepalive_probes)) {
> + if (icsk->icsk_probes_out >= keepalive_probes(tp)) {
> tcp_send_active_reset(sk, GFP_ATOMIC);
> tcp_write_err(sk);
--
i.
^ permalink raw reply
* Re: [PATCH] Phonet: Correct header retrieval after pskb_may_pull
From: Eric Dumazet @ 2010-09-28 9:47 UTC (permalink / raw)
To: Kumar A Sanghvi
Cc: netdev, davem, remi.denis-courmont, gulshan.karmani,
Linus Walleij
In-Reply-To: <1285665042-20548-1-git-send-email-kumar.sanghvi@stericsson.com>
Le mardi 28 septembre 2010 à 14:40 +0530, Kumar A Sanghvi a écrit :
> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>
> Retrieve the header after doing pskb_may_pull since, pskb_may_pull
> could change the buffer structure.
>
> This is based on the comment given by Eric Dumazet on Phonet
> Pipe controller patch for a similar problem.
>
> Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
> ---
> net/phonet/pep.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/phonet/pep.c b/net/phonet/pep.c
> index 7bf23cf..9746c6d 100644
> --- a/net/phonet/pep.c
> +++ b/net/phonet/pep.c
> @@ -507,12 +507,13 @@ static void pipe_grant_credits(struct sock *sk)
> static int pipe_rcv_status(struct sock *sk, struct sk_buff *skb)
> {
> struct pep_sock *pn = pep_sk(sk);
> - struct pnpipehdr *hdr = pnp_hdr(skb);
> + struct pnpipehdr *hdr;
> int wake = 0;
>
> if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> return -EINVAL;
>
> + hdr = pnp_hdr(skb);
> if (hdr->data[0] != PN_PEP_TYPE_COMMON) {
> LIMIT_NETDEBUG(KERN_DEBUG"Phonet unknown PEP type: %u\n",
> (unsigned)hdr->data[0]);
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: BUG - qdev - partial loss of network connectivity
From: Michael S. Tsirkin @ 2010-09-28 9:50 UTC (permalink / raw)
To: Leszek Urbanski; +Cc: netdev, linux-nfs, qemu-devel, virtualization
In-Reply-To: <20100927213203.GA28089@moo.pl>
On Mon, Sep 27, 2010 at 11:32:03PM +0200, Leszek Urbanski wrote:
> <20100926154324.GD21843@redhat.com>; from Michael S. Tsirkin on Sun, Sep 26, 2010 at 17:43:24 +0200
>
> > > > >It's vanilla 2.6.32.22, but I also reproduced this on Debian's 2.6.32-23
> > > > >(based on 2.6.32.21).
> > > > >
> > > > >If offload is the only difference, I'll play with different offload
> > > > >options and check which one causes it.
> > > > >
> > > >
> > > > It's not technically the only difference but it's the most likely
> > > > culprit IMHO.
> > >
> > > udp fragmentation offload is definitely the culprit.
> >
> > I see. Most likely guest bug - won't be the first bug around UFO.
> > If so pls copy netdev linux-nfs and virtualization.
> > Do you see anything in dmesg? Can try 2.6.36-rc5?
>
> (for reference: first post is at:
> http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01685.html )
>
> I can't reproduce it on 2.6.36-rc5. Do you have an idea which patch may have
> fixed it, or should I dissect?
bisect, yes: there were many UFO related patches since 2.6.32.
--
MST
^ 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