* Re: [PATCH 2/3] [TCP]: Comment fastpath_cnt_hint off-by-one trap
From: David Miller @ 2007-10-08 6:37 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: legoater, netdev
In-Reply-To: <11914092181600-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 3 Oct 2007 14:00:17 +0300
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] [TCP]: "Annotate" another fackets_out state reset
From: David Miller @ 2007-10-08 6:38 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: legoater, netdev
In-Reply-To: <11914092182230-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 3 Oct 2007 14:00:18 +0300
> This should no longer be necessary because fackets_out is
> accurate. It indicates bugs elsewhere, thus report it.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.24] [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
From: David Miller @ 2007-10-08 6:39 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: clg, netdev
In-Reply-To: <Pine.LNX.4.64.0710041911400.17326@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 4 Oct 2007 23:20:34 +0300 (EEST)
> Dave should apply both the three patch series fix and this one as well to
> net-2.6.24 (Dave, in case you want me to resubmit, just ask... :-)). I'll
> send one against .23-rc9 soon after this (sadly enough, it will cause a
> conflict...).
Ok, all the net-2.6.24 bits are in, I'll take care of -stable...
^ permalink raw reply
* Re: [PATCH] Fix rose.ko oops on unload
From: David Miller @ 2007-10-08 6:44 UTC (permalink / raw)
To: adobriyan; +Cc: ralf, netdev, pidoux
In-Reply-To: <20071003185413.GA16242@martell.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed, 3 Oct 2007 22:54:13 +0400
> Quick'n'dirty fix to 100% oops on "rmmod rose". Do you want me to
> properly unwind everything before .24?
Patch applied, thanks Alexey.
^ permalink raw reply
* Re: [NET] IPv6 oops bisected
From: David Miller @ 2007-10-08 6:46 UTC (permalink / raw)
To: den; +Cc: herbert, jeff, netdev, linux-kernel, akpm, den
In-Reply-To: <4709CF6F.60102@sw.ru>
From: "Denis V. Lunev" <den@sw.ru>
Date: Mon, 08 Oct 2007 10:34:23 +0400
> OK. I am installing Fedora 7 right now...
You don't need to install Fedora, just read the code! :-)
The bug is obvious and it's been explained thoroughly in this
thread.
When 'dev' is NULL in ip6_route_add() we need to figure out what
namespace and/or loopback device you want to use.
There is no reason to do an entire dist install to work on fixing this
bug, yikes!
^ permalink raw reply
* Re: [NET] IPv6 oops bisected
From: Denis V. Lunev @ 2007-10-08 7:00 UTC (permalink / raw)
To: David Miller; +Cc: herbert, jeff, netdev, linux-kernel, akpm
In-Reply-To: <20071007.234606.111182047.davem@davemloft.net>
David Miller wrote:
> From: "Denis V. Lunev" <den@sw.ru>
> Date: Mon, 08 Oct 2007 10:34:23 +0400
>
>> OK. I am installing Fedora 7 right now...
>
> You don't need to install Fedora, just read the code! :-)
>
> The bug is obvious and it's been explained thoroughly in this
> thread.
>
> When 'dev' is NULL in ip6_route_add() we need to figure out what
> namespace and/or loopback device you want to use.
>
> There is no reason to do an entire dist install to work on fixing this
> bug, yikes!
I do understand the conditions when the bug happens. Its completely
clear :) Though I do not understand how to trigger it from command line
to test that the problem is resolved. Jeff was not kind enough to give
exact command line :(
The unfortunate thing with this place is that original Eric's code is
also broken here. I was too optimistic working on the original patchset.
In other way, but broken :(
So, I must stop and think...
^ permalink raw reply
* Re: [PATCH net-2.6.24] net: sparse warning fixes
From: David Miller @ 2007-10-08 6:59 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20071005171407.19c65258@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 5 Oct 2007 17:14:07 -0700
> Fix a bunch of sparse warnings. Mostly about 0 used as
> NULL pointer, and shadowed variable declarations.
>
> The two noteable changes are:
> * hash size should have been unsigned
> * cls_u32 had a case where error code wasn't been
> propogated properly, so it could return 0 but still
> have an error.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied, and I stuffed the cls_u32 fix into net-2.6 as well.
But please fix the following, this is the second time I've
had to remove this bit from one of your patches.
> @@ -6,7 +6,7 @@
> *
> * Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> * Ben Greear <greearb@candelatech.com>
> - * Jens Låås <jens.laas@data.slu.se>
> + * Jens Låås <jens.laas@data.slu.se>
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
Please please please please, for the second time, fix the encoding
your editor uses when you save copies of this source file, this hunk
of your patches never applies cleanly.
Thanks.
^ permalink raw reply
* Re: [RFC net-2.6.24] skbuff: change skb_frag_struct to scatterlist
From: David Miller @ 2007-10-08 7:04 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20071005174322.0a13c173@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 5 Oct 2007 17:43:22 -0700
> Replace the skb frag list with the common scatterlist definition.
> This allows device drivers to use dma_scatter/gather operations which
> may be faster on some platforms. As a side benefit, it is easier to
> handle dma mapping error unwind.
>
> This idea came up long ago, just never got implemented.
> Reimplemented against net-2.6.24. This version is for comment, not
> tested yet.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Thanks for keeping this idea alive.
But this isn't the hard part. The issue is that skb->data is still
seperate, and as long as that's true DMA mapping error recovery is
still a complete mess because we still have to do two seperate DMA
mappings on transmit, one of which is conditional, instead of one call
which is easy to handle properly.
We could do something cute like have the packet building routines use
skb_shinfo(skb)->frags[1] and onward, and then right before
->hard_start_xmit() we fill in skb_shinfo(skb)->frags[0] with
virt_to_page(skb->data) etc.
No page refcount bumps on this magic first entry, in order for it to
be as near zero cost as possible.
Anyways, just one idea.
^ permalink raw reply
* Re: [PATCH] net/core: split dev_ifsioc() according to locking
From: David Miller @ 2007-10-08 7:06 UTC (permalink / raw)
To: arnd; +Cc: jeff, netdev, linux-kernel, akpm
In-Reply-To: <200710070217.09073.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 7 Oct 2007 02:17:08 +0200
> On Saturday 06 October 2007, Jeff Garzik wrote:
> >
> > This always bugged me: dev_ioctl() called dev_ifsioc() either inside
> > read_lock(dev_base_lock) or rtnl_lock(), depending on the ioctl being
> > executed.
> >
> > This change moves the ioctls executed inside dev_base_lock to a new
> > function, dev_ifsioc_locked(). Now the locking context is completely
> > clear to the reader.
> >
> > Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>
> Great idea!
I think so too, applied, thanks!
^ permalink raw reply
* Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3
From: David Miller @ 2007-10-08 7:12 UTC (permalink / raw)
To: brian.haley; +Cc: yoshfuji, netdev, dlstevens
In-Reply-To: <4703AAC1.3040500@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Wed, 03 Oct 2007 10:44:17 -0400
> When the ICMPv6 Target address is multicast, Linux processes the
> redirect instead of dropping it. The problem is in this code in
> ndisc_redirect_rcv():
>
> if (ipv6_addr_equal(dest, target)) {
> on_link = 1;
> } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
> ND_PRINTK2(KERN_WARNING
> "ICMPv6 Redirect: target address is not
> link-local.\n");
> return;
> }
>
> This second check will succeed if the Target address is, for example,
> FF02::1 because it has link-local scope. Instead, it should be checking
> if it's a unicast link-local address, as stated in RFC 2461/4861 Section
> 8.1:
>
> - The ICMP Target Address is either a link-local address (when
> redirected to a router) or the same as the ICMP Destination
> Address (when redirected to the on-link destination).
>
> I know this doesn't explicitly say unicast link-local address, but it's
> implied.
>
> This bug is preventing Linux kernels from achieving IPv6 Logo Phase II
> certification because of a recent error that was found in the TAHI test
> suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the
> multicast address in the Destination field instead of Target field, so
> we were passing the test. This won't be the case anymore.
>
> The patch below fixes this problem, and also fixes ndisc_send_redirect()
> to not send an invalid redirect with a multicast address in the Target
> field. I re-ran the TAHI Neighbor Discovery section to make sure Linux
> passes all 245 tests now.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
I believe everyone's concerns have been addressed in this
version of the patch, so I have applied it to net-2.6
Thanks everyone!
^ permalink raw reply
* Re: [Devel] [PATCH][NETNS] Move some code into __init section when CONFIG_NET_NS=n
From: David Miller @ 2007-10-08 7:17 UTC (permalink / raw)
To: adobriyan; +Cc: xemul, netdev, devel
In-Reply-To: <20071004140202.GA6180@localhost.sw.ru>
From: Alexey Dobriyan <adobriyan@sw.ru>
Date: Thu, 4 Oct 2007 18:02:02 +0400
> On Thu, Oct 04, 2007 at 05:54:11PM +0400, Pavel Emelyanov wrote:
> > With the net namespaces many code leaved the __init section,
> > thus making the kernel occupy more memory than it did before.
> > Since we have a config option that prohibits the namespace
> > creation, the functions that initialize/finalize some netns
> > stuff are simply not needed and can be freed after the boot.
> >
> > Currently, this is almost not noticeable, since few calls
> > are no longer in __init, but when the namespaces will be
> > merged it will be possible to free more code. I propose to
> > use the __net_init, __net_exit and __net_initdata "attributes"
> > for functions/variables that are not used if the CONFIG_NET_NS
> > is not set to save more space in memory.
>
> > +#ifdef CONFIG_NET_NS
> > +#define __net_init
> > +#define __net_exit
> > +#define __net_initdata
> > +#else
> > +#define __net_init __init
> > +#define __net_exit __exit
> > +#define __net_initdata __initdata
> > +#endif
>
> Yet another set of double-underscored section annotations is the last thing
> that is needed, methinks. :)
I'm not so sure. I think double-underscores are a powerful deterrant
for developers. Over time folks have learned that this prefix
in an interface name means "semantics are non-trivial, use with
care" and that definitely applies to init sections.
I'm going to apply Pavel's patch, if you want to touch it up do so
as a followon patch, thanks!
^ permalink raw reply
* Re: [PATCH][NETNS] Move some code into __init section when CONFIG_NET_NS=n
From: David Miller @ 2007-10-08 7:18 UTC (permalink / raw)
To: xemul; +Cc: ebiederm, netdev, devel
In-Reply-To: <4704F083.7090203@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 04 Oct 2007 17:54:11 +0400
> With the net namespaces many code leaved the __init section,
> thus making the kernel occupy more memory than it did before.
> Since we have a config option that prohibits the namespace
> creation, the functions that initialize/finalize some netns
> stuff are simply not needed and can be freed after the boot.
>
> Currently, this is almost not noticeable, since few calls
> are no longer in __init, but when the namespaces will be
> merged it will be possible to free more code. I propose to
> use the __net_init, __net_exit and __net_initdata "attributes"
> for functions/variables that are not used if the CONFIG_NET_NS
> is not set to save more space in memory.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel.
^ permalink raw reply
* Re: [PATCH 2/4][TG3]: ASIC decoding and basic CPMU support.
From: Christoph Hellwig @ 2007-10-08 7:18 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, andy, mcarlson
In-Reply-To: <1191641858.17453.7.camel@dell>
On Fri, Oct 05, 2007 at 08:37:38PM -0700, Michael Chan wrote:
> [TG3]: ASIC decoding and basic CPMU support.
>
> Newer products change the way the ASIC revision is obtained. This patch
> implements how the driver will extract the revision number.
Just curious: is there a diagram somewhere that shows the relation of
the various tg3 chips to each other and what families exist?
^ permalink raw reply
* Re: [Devel] [PATCH][NETNS] Move some code into __init section when CONFIG_NET_NS=n
From: David Miller @ 2007-10-08 7:30 UTC (permalink / raw)
To: adobriyan; +Cc: xemul, netdev, devel
In-Reply-To: <20071008.001716.116377615.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 08 Oct 2007 00:17:16 -0700 (PDT)
> I'm going to apply Pavel's patch, if you want to touch it up do so
> as a followon patch, thanks!
Actually, I take that back, it doesn't even build, I'm therefore
removing the patch:
LD .tmp_vmlinux1
`.exit.text' referenced in section `.init.data' of fs/built-in.o: defined in discarded section `.exit.text' of fs/built-in.o
`.exit.text' referenced in section `.init.data' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.init.data' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `.init.data' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `.init.data' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `.init.data' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `.init.data' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
make: *** [.tmp_vmlinux1] Error 1
Please fix this up and resubmit if you like.
^ permalink raw reply
* [PATCH] libertas link error due to gcc `smartness'
From: Geert Uytterhoeven @ 2007-10-08 7:43 UTC (permalink / raw)
To: Marcelo Tosatti, Jeff Garzik, Andrew Morton, netdev,
linux-wireless
Cc: Linux Kernel Development
Some versions of gcc replace strstr() calls with a single-character `needle'
parameter by strchr() behind our back. This causes a link error if strchr() is
defined as an inline function in <asm/string.h> (e.g. on m68k):
| drivers/built-in.o: In function `libertas_parse_chan':
| linux/drivers/net/wireless/libertas/debugfs.c:209: undefined reference to `strchr'
| drivers/built-in.o: In function `libertas_parse_ssid':
| linux/drivers/net/wireless/libertas/debugfs.c:260: undefined reference to `strchr'
Avoid this by explicitly calling strchr() instead.
Also include <linux/string.h>, because this file calls lots of str*() routines.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Due to the lack of hardware, I could not test the functionality of this change.
I was just trying to compile a kernel with a much enabled as possible.
drivers/net/wireless/libertas/debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/libertas/debugfs.c
+++ b/drivers/net/wireless/libertas/debugfs.c
@@ -3,6 +3,7 @@
#include <linux/debugfs.h>
#include <linux/delay.h>
#include <linux/mm.h>
+#include <linux/string.h>
#include <net/iw_handler.h>
#include "dev.h"
@@ -205,7 +206,7 @@ static int libertas_parse_chan(char *buf
if (!start)
return -EINVAL;
start += 5;
- end = strstr(start, " ");
+ end = strchr(start, ' ');
if (!end)
end = buf + count;
hold = kzalloc((end - start)+1, GFP_KERNEL);
@@ -256,7 +257,7 @@ static void libertas_parse_ssid(char *bu
if (!hold)
return;
hold += 5;
- end = strstr(hold, " ");
+ end = strchr(hold, ' ');
if (!end)
end = buf + count - 1;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] IrDA: Oops fix for ksdazzle
From: David Miller @ 2007-10-08 8:07 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
a_villacis-5itmuRygkZmgSpxsJD1C4w, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070930232138.GA5669-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Mon, 1 Oct 2007 02:21:38 +0300
> Hi Dave,
>
> This is the last remaining patch for IrDA, against net-2.6.24.
>
> It fixes a kernel oops triggered by the ksdazzle SIR driver.
> We need more space for input frames, and 2048 should be plenty of it.
>
> Signed-off-by: Alex Villacís Lasso <a_villacis-5itmuRygkZmgSpxsJD1C4w@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied, thanks!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [PATCH 2.6.24] tg3: fix ethtool autonegotiate flags
From: David Miller @ 2007-10-08 8:09 UTC (permalink / raw)
To: mchan; +Cc: andy, jeff, netdev
In-Reply-To: <1191362576.5961.15.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 15:02:56 -0700
> On Tue, 2007-10-02 at 16:16 -0400, Andy Gospodarek wrote:
> > Adding that flag in tg3_set_settings seemed like the most logical
> > place
> > since the driver works fine on boot. This is just an issue when
> > re-enabling autonegotiation, so we should probably nip it there.
> >
> > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>
> We also noticed this issue recently, but didn't pay too much attention
> to it since it was more of a "cosmetic" issue. The driver behaves the
> same since we rely on cmd->autoneg to decide whether to enable autoneg
> or not. Your fix seems reasonable to me. Thanks.
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied, thanks everyone!
^ permalink raw reply
* [patch 0/2] [AF_IUCV] fixes for net-2.6.24 - cleanup resend
From: Ursula Braun @ 2007-10-08 8:51 UTC (permalink / raw)
To: davem, netdev, linux-s390; +Cc: heicars2
--
Dave,
this is the resend of my patches from last week built against net-2.6.24.
> the following 2 patches are intended for 2.6.24 and contain:
> - removal of static declarations in af_iucv header file
> - postpone receival of inbound packets in af_iucv
Regards, Ursula
^ permalink raw reply
* [patch 2/2] af_iucv: postpone receival of iucv-packets
From: Ursula Braun @ 2007-10-08 8:51 UTC (permalink / raw)
To: davem, netdev, linux-s390; +Cc: heicars2
In-Reply-To: <20071008085119.805528000@linux.vnet.ibm.com>
[-- Attachment #1: 712-afiucv-throttle.diff --]
[-- Type: text/plain, Size: 8613 bytes --]
From: Ursula Braun <braunu@de.ibm.com>
AF_IUCV socket programs may waste Linux storage, because af_iucv
allocates an skb whenever posted by the receive callback routine and
receives the message immediately.
Message receival is now postponed if data from previous callbacks has
not yet been transferred to the receiving socket program. Instead a
message handle is saved in a message queue as a reminder. Once
messages could be given to the receiving socket program, there is
an additional checking for entries in the message queue, followed
by skb allocation and message receival if applicable.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
include/net/iucv/af_iucv.h | 7 +
net/iucv/af_iucv.c | 215 ++++++++++++++++++++++++++-------------------
2 files changed, 134 insertions(+), 88 deletions(-)
Index: net-2.6.24-uschi/include/net/iucv/af_iucv.h
===================================================================
--- net-2.6.24-uschi.orig/include/net/iucv/af_iucv.h
+++ net-2.6.24-uschi/include/net/iucv/af_iucv.h
@@ -50,6 +50,12 @@ struct sockaddr_iucv {
/* Common socket structures and functions */
+struct sock_msg_q {
+ struct iucv_path *path;
+ struct iucv_message msg;
+ struct list_head list;
+ spinlock_t lock;
+};
#define iucv_sk(__sk) ((struct iucv_sock *) __sk)
@@ -65,6 +71,7 @@ struct iucv_sock {
struct iucv_path *path;
struct sk_buff_head send_skb_q;
struct sk_buff_head backlog_skb_q;
+ struct sock_msg_q message_q;
unsigned int send_tag;
};
Index: net-2.6.24-uschi/net/iucv/af_iucv.c
===================================================================
--- net-2.6.24-uschi.orig/net/iucv/af_iucv.c
+++ net-2.6.24-uschi/net/iucv/af_iucv.c
@@ -224,6 +224,8 @@ static struct sock *iucv_sock_alloc(stru
INIT_LIST_HEAD(&iucv_sk(sk)->accept_q);
spin_lock_init(&iucv_sk(sk)->accept_q_lock);
skb_queue_head_init(&iucv_sk(sk)->send_skb_q);
+ INIT_LIST_HEAD(&iucv_sk(sk)->message_q.list);
+ spin_lock_init(&iucv_sk(sk)->message_q.lock);
skb_queue_head_init(&iucv_sk(sk)->backlog_skb_q);
iucv_sk(sk)->send_tag = 0;
@@ -673,6 +675,90 @@ out:
return err;
}
+static int iucv_fragment_skb(struct sock *sk, struct sk_buff *skb, int len)
+{
+ int dataleft, size, copied = 0;
+ struct sk_buff *nskb;
+
+ dataleft = len;
+ while (dataleft) {
+ if (dataleft >= sk->sk_rcvbuf / 4)
+ size = sk->sk_rcvbuf / 4;
+ else
+ size = dataleft;
+
+ nskb = alloc_skb(size, GFP_ATOMIC | GFP_DMA);
+ if (!nskb)
+ return -ENOMEM;
+
+ memcpy(nskb->data, skb->data + copied, size);
+ copied += size;
+ dataleft -= size;
+
+ skb_reset_transport_header(nskb);
+ skb_reset_network_header(nskb);
+ nskb->len = size;
+
+ skb_queue_tail(&iucv_sk(sk)->backlog_skb_q, nskb);
+ }
+
+ return 0;
+}
+
+static void iucv_process_message(struct sock *sk, struct sk_buff *skb,
+ struct iucv_path *path,
+ struct iucv_message *msg)
+{
+ int rc;
+
+ if (msg->flags & IPRMDATA) {
+ skb->data = NULL;
+ skb->len = 0;
+ } else {
+ rc = iucv_message_receive(path, msg, 0, skb->data,
+ msg->length, NULL);
+ if (rc) {
+ kfree_skb(skb);
+ return;
+ }
+ if (skb->truesize >= sk->sk_rcvbuf / 4) {
+ rc = iucv_fragment_skb(sk, skb, msg->length);
+ kfree_skb(skb);
+ skb = NULL;
+ if (rc) {
+ iucv_path_sever(path, NULL);
+ return;
+ }
+ skb = skb_dequeue(&iucv_sk(sk)->backlog_skb_q);
+ } else {
+ skb_reset_transport_header(skb);
+ skb_reset_network_header(skb);
+ skb->len = msg->length;
+ }
+ }
+
+ if (sock_queue_rcv_skb(sk, skb))
+ skb_queue_head(&iucv_sk(sk)->backlog_skb_q, skb);
+}
+
+static void iucv_process_message_q(struct sock *sk)
+{
+ struct iucv_sock *iucv = iucv_sk(sk);
+ struct sk_buff *skb;
+ struct sock_msg_q *p, *n;
+
+ list_for_each_entry_safe(p, n, &iucv->message_q.list, list) {
+ skb = alloc_skb(p->msg.length, GFP_ATOMIC | GFP_DMA);
+ if (!skb)
+ break;
+ iucv_process_message(sk, skb, p->path, &p->msg);
+ list_del(&p->list);
+ kfree(p);
+ if (!skb_queue_empty(&iucv->backlog_skb_q))
+ break;
+ }
+}
+
static int iucv_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t len, int flags)
{
@@ -684,8 +770,9 @@ static int iucv_sock_recvmsg(struct kioc
int err = 0;
if ((sk->sk_state == IUCV_DISCONN || sk->sk_state == IUCV_SEVERED) &&
- skb_queue_empty(&iucv->backlog_skb_q) &&
- skb_queue_empty(&sk->sk_receive_queue))
+ skb_queue_empty(&iucv->backlog_skb_q) &&
+ skb_queue_empty(&sk->sk_receive_queue) &&
+ list_empty(&iucv->message_q.list))
return 0;
if (flags & (MSG_OOB))
@@ -724,16 +811,23 @@ static int iucv_sock_recvmsg(struct kioc
kfree_skb(skb);
/* Queue backlog skbs */
- rskb = skb_dequeue(&iucv_sk(sk)->backlog_skb_q);
+ rskb = skb_dequeue(&iucv->backlog_skb_q);
while (rskb) {
if (sock_queue_rcv_skb(sk, rskb)) {
- skb_queue_head(&iucv_sk(sk)->backlog_skb_q,
+ skb_queue_head(&iucv->backlog_skb_q,
rskb);
break;
} else {
- rskb = skb_dequeue(&iucv_sk(sk)->backlog_skb_q);
+ rskb = skb_dequeue(&iucv->backlog_skb_q);
}
}
+ if (skb_queue_empty(&iucv->backlog_skb_q)) {
+ spin_lock_bh(&iucv->message_q.lock);
+ if (!list_empty(&iucv->message_q.list))
+ iucv_process_message_q(sk);
+ spin_unlock_bh(&iucv->message_q.lock);
+ }
+
} else
skb_queue_head(&sk->sk_receive_queue, skb);
@@ -975,99 +1069,44 @@ static void iucv_callback_connack(struct
sk->sk_state_change(sk);
}
-static int iucv_fragment_skb(struct sock *sk, struct sk_buff *skb, int len,
- struct sk_buff_head *fragmented_skb_q)
-{
- int dataleft, size, copied = 0;
- struct sk_buff *nskb;
-
- dataleft = len;
- while (dataleft) {
- if (dataleft >= sk->sk_rcvbuf / 4)
- size = sk->sk_rcvbuf / 4;
- else
- size = dataleft;
-
- nskb = alloc_skb(size, GFP_ATOMIC | GFP_DMA);
- if (!nskb)
- return -ENOMEM;
-
- memcpy(nskb->data, skb->data + copied, size);
- copied += size;
- dataleft -= size;
-
- skb_reset_transport_header(nskb);
- skb_reset_network_header(nskb);
- nskb->len = size;
-
- skb_queue_tail(fragmented_skb_q, nskb);
- }
-
- return 0;
-}
-
static void iucv_callback_rx(struct iucv_path *path, struct iucv_message *msg)
{
struct sock *sk = path->private;
struct iucv_sock *iucv = iucv_sk(sk);
- struct sk_buff *skb, *fskb;
- struct sk_buff_head fragmented_skb_q;
- int rc;
-
- skb_queue_head_init(&fragmented_skb_q);
+ struct sk_buff *skb;
+ struct sock_msg_q *save_msg;
+ int len;
if (sk->sk_shutdown & RCV_SHUTDOWN)
return;
- skb = alloc_skb(msg->length, GFP_ATOMIC | GFP_DMA);
- if (!skb) {
- iucv_path_sever(path, NULL);
- return;
- }
+ if (!list_empty(&iucv->message_q.list) ||
+ !skb_queue_empty(&iucv->backlog_skb_q))
+ goto save_message;
+
+ len = atomic_read(&sk->sk_rmem_alloc);
+ len += msg->length + sizeof(struct sk_buff);
+ if (len > sk->sk_rcvbuf)
+ goto save_message;
- if (msg->flags & IPRMDATA) {
- skb->data = NULL;
- skb->len = 0;
- } else {
- rc = iucv_message_receive(path, msg, 0, skb->data,
- msg->length, NULL);
- if (rc) {
- kfree_skb(skb);
- return;
- }
- if (skb->truesize >= sk->sk_rcvbuf / 4) {
- rc = iucv_fragment_skb(sk, skb, msg->length,
- &fragmented_skb_q);
- kfree_skb(skb);
- skb = NULL;
- if (rc) {
- iucv_path_sever(path, NULL);
- return;
- }
- } else {
- skb_reset_transport_header(skb);
- skb_reset_network_header(skb);
- skb->len = msg->length;
- }
- }
- /* Queue the fragmented skb */
- fskb = skb_dequeue(&fragmented_skb_q);
- while (fskb) {
- if (!skb_queue_empty(&iucv->backlog_skb_q))
- skb_queue_tail(&iucv->backlog_skb_q, fskb);
- else if (sock_queue_rcv_skb(sk, fskb))
- skb_queue_tail(&iucv_sk(sk)->backlog_skb_q, fskb);
- fskb = skb_dequeue(&fragmented_skb_q);
- }
-
- /* Queue the original skb if it exists (was not fragmented) */
- if (skb) {
- if (!skb_queue_empty(&iucv->backlog_skb_q))
- skb_queue_tail(&iucv_sk(sk)->backlog_skb_q, skb);
- else if (sock_queue_rcv_skb(sk, skb))
- skb_queue_tail(&iucv_sk(sk)->backlog_skb_q, skb);
- }
+ skb = alloc_skb(msg->length, GFP_ATOMIC | GFP_DMA);
+ if (!skb)
+ goto save_message;
+ spin_lock(&iucv->message_q.lock);
+ iucv_process_message(sk, skb, path, msg);
+ spin_unlock(&iucv->message_q.lock);
+
+ return;
+
+save_message:
+ save_msg = kzalloc(sizeof(struct sock_msg_q), GFP_ATOMIC | GFP_DMA);
+ save_msg->path = path;
+ save_msg->msg = *msg;
+
+ spin_lock(&iucv->message_q.lock);
+ list_add_tail(&save_msg->list, &iucv->message_q.list);
+ spin_unlock(&iucv->message_q.lock);
}
static void iucv_callback_txdone(struct iucv_path *path,
--
^ permalink raw reply
* [patch 1/2] af_iucv: remove static declarations from header file.
From: Ursula Braun @ 2007-10-08 8:51 UTC (permalink / raw)
To: davem, netdev, linux-s390; +Cc: heicars2, Heiko Carstens
In-Reply-To: <20071008085119.805528000@linux.vnet.ibm.com>
[-- Attachment #1: 711-afiucv-statics.diff --]
[-- Type: text/plain, Size: 2497 bytes --]
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
include/net/iucv/af_iucv.h | 20 --------------------
net/iucv/af_iucv.c | 3 +++
2 files changed, 3 insertions(+), 20 deletions(-)
Index: net-2.6.24-uschi/include/net/iucv/af_iucv.h
===================================================================
--- net-2.6.24-uschi.orig/include/net/iucv/af_iucv.h
+++ net-2.6.24-uschi/include/net/iucv/af_iucv.h
@@ -74,28 +74,8 @@ struct iucv_sock_list {
atomic_t autobind_name;
};
-static void iucv_sock_destruct(struct sock *sk);
-static void iucv_sock_cleanup_listen(struct sock *parent);
-static void iucv_sock_kill(struct sock *sk);
-static void iucv_sock_close(struct sock *sk);
-static int iucv_sock_bind(struct socket *sock, struct sockaddr *addr,
- int addr_len);
-static int iucv_sock_connect(struct socket *sock, struct sockaddr *addr,
- int alen, int flags);
-static int iucv_sock_listen(struct socket *sock, int backlog);
-static int iucv_sock_accept(struct socket *sock, struct socket *newsock,
- int flags);
-static int iucv_sock_getname(struct socket *sock, struct sockaddr *addr,
- int *len, int peer);
-static int iucv_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, size_t len);
-static int iucv_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, size_t len, int flags);
unsigned int iucv_sock_poll(struct file *file, struct socket *sock,
poll_table *wait);
-static int iucv_sock_release(struct socket *sock);
-static int iucv_sock_shutdown(struct socket *sock, int how);
-
void iucv_sock_link(struct iucv_sock_list *l, struct sock *s);
void iucv_sock_unlink(struct iucv_sock_list *l, struct sock *s);
int iucv_sock_wait_state(struct sock *sk, int state, int state2,
Index: net-2.6.24-uschi/net/iucv/af_iucv.c
===================================================================
--- net-2.6.24-uschi.orig/net/iucv/af_iucv.c
+++ net-2.6.24-uschi/net/iucv/af_iucv.c
@@ -41,6 +41,9 @@ static struct proto iucv_proto = {
.obj_size = sizeof(struct iucv_sock),
};
+static void iucv_sock_kill(struct sock *sk);
+static void iucv_sock_close(struct sock *sk);
+
/* Call Back functions */
static void iucv_callback_rx(struct iucv_path *, struct iucv_message *);
static void iucv_callback_txdone(struct iucv_path *, struct iucv_message *);
--
^ permalink raw reply
* Re: [patch 0/2] [AF_IUCV] fixes for net-2.6.24 - cleanup resend
From: David Miller @ 2007-10-08 9:03 UTC (permalink / raw)
To: braunu; +Cc: netdev, linux-s390, heicars2
In-Reply-To: <20071008085119.805528000@linux.vnet.ibm.com>
From: Ursula Braun <braunu@de.ibm.com>
Date: Mon, 08 Oct 2007 10:51:19 +0200
> --
> Dave,
>
> this is the resend of my patches from last week built against net-2.6.24.
>
> > the following 2 patches are intended for 2.6.24 and contain:
> > - removal of static declarations in af_iucv header file
> > - postpone receival of inbound packets in af_iucv
All applied, thanks!
^ permalink raw reply
* Re: [PATCH 1/3] [NET_BATCH] Introduce batching interface
From: Krishna Kumar2 @ 2007-10-08 9:59 UTC (permalink / raw)
To: hadi
Cc: David Miller, gaagaan, general, herbert, jagana, jeff, johnpol,
kaber, kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rdreier, rick.jones2, Robert.Olsson, shemminger,
sri, tgraf, xma
In-Reply-To: <1191782183.4394.62.camel@localhost>
Hi Jamal,
If you don't mind, I am trying to run your approach vs mine to get some
results
for comparison.
For starters, I am having issues with iperf when using your infrastructure
code with
my IPoIB driver - about 100MB is sent and then everything stops for some
reason.
The changes in the IPoIB driver that I made to support batching is to set
BTX, set
xmit_win, and dynamically reduce xmit_win on every xmit and increase
xmit_win on
every xmit completion. Is there anything else that is required from the
driver?
thanks,
- KK
J Hadi Salim <j.hadi123@gmail.com> wrote on 10/08/2007 12:06:23 AM:
> This patch introduces the netdevice interface for batching.
>
> cheers,
> jamal
>
>
> [attachment "oct07-p1of3" deleted by Krishna Kumar2/India/IBM]
^ permalink raw reply
* Re: [BNX2X][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.
From: Eliezer Tamir @ 2007-10-08 10:35 UTC (permalink / raw)
To: Matti Aarnio
Cc: davem@davemloft.net, jeff@garzik.org, netdev@vger.kernel.org,
Michael Chan, eilong, eliezert
In-Reply-To: <20071007205055.GG6372@mea-ext.zmailer.org>
Matti Aarnio wrote:
> Your patch-posting procedure is yet in a bit problem state..
>
> +{
> +static const u32 EVST_TSEM_FAST_MEMORY_COMMON_MEMORY_INIT_EMULATION_7[] = {
> +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0,
> +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0,
> +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0,
>
> It does look like your Thunderbird 2.0 did wrap long text lines when you
> included the texts into the posts.
>
>
Sorry about that, will fix and resubmit shortly.
Thanks
Eliezer
^ permalink raw reply
* Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
From: Ilpo Järvinen @ 2007-10-08 11:11 UTC (permalink / raw)
To: TAKANO Ryousei; +Cc: Netdev, y-kodama
In-Reply-To: <20071007.145100.00679926.takano@axe-inc.co.jp>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2312 bytes --]
On Sun, 7 Oct 2007, TAKANO Ryousei wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
> Date: Fri, 5 Oct 2007 13:02:07 +0300 (EEST)
>
> > On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
> >
> > In case sacktag uses fastpath, this code won't be executed for the skb's
> > that we would like to check (those with SACKED_RETRANS set, that are
> > below the fastpath_skb_hint). We will eventually deal with the whole queue
> > when fastpath_skb_hint gets set to NULL, with the next cumulative ACK that
> > fully ACKs an skb at the latest. Maybe there's a need for a larger surgery
> > than this to fix it. I think we need additional field to tcp_sock to avoid
> > doing a full-walk per ACK:
>
> I think the problem occurs in slowpath. For example, in case when the receiver
> detects and sends back a new SACK block, the sender may fail to detect loss
> of a retransmitted packet.
...No, the slow path is very likely to _correct_ the problem! The problem
occurs because fastpath _skips_ processing of skbs below fastpath_skb_hint
whereas slowpath starts from tcp_write_queue_head. The retransmitted skbs
we're interested in reside exactly on that skipped range.
Currently fastpath_skb_hint is cleared rather often when it would not be
mandatory, e.g., when a cumulative ACK arrives, thus slow-path is forced
often enough for this problem to not show up too often in any real
scenario, yet it's broken as is and should be fixed. ...It's actually
something which is on a way for any solution which reduces the number of
walked skb per ACK.
> > In future, please base your work to current development tree instead of
> > linus' tree (net-2.6.24 at this point of time, there's also tcp-2.6 but
> > it's currently a bit outdated).
>
> Thanks for your suggestion. SACK processing has a heavy workload and
> it is complex. I agree to make efforts toward a more generic solution.
> Your recv_sack_cache patch seems valuable.
Agreed, and as is, it's getting more and more expensive to do. The current
code is doing more and more processing compared to how much new SACK
information was actually received. ...However, doing a large surgery like
that and maintaining full correctness at the same time scares me a bit...
--
i.
^ permalink raw reply
* Re: [RFC][PATCH 2/2] TCP: skip processing cached SACK blocks
From: Ilpo Järvinen @ 2007-10-08 11:20 UTC (permalink / raw)
To: TAKANO Ryousei; +Cc: Netdev, y-kodama
In-Reply-To: <20071007.151145.32909699.takano@axe-inc.co.jp>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1177 bytes --]
On Sun, 7 Oct 2007, TAKANO Ryousei wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> > On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
> >
> > > @@ -1083,6 +1104,9 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
> > > int fack_count;
> > > int dup_sack = (found_dup_sack && (i == first_sack_index));
> > >
> > > + if (sack_block_skip[i])
> > > + continue;
> >
> > By doing this skipping here, you actually end up crippling lost_retrans
> > detection even more than it was broken before. ...You probably didn't just
> > notice that during tests because of unrelated suboptimal behavior (in
> > fastpath_skb_hint handling). ...Anyway, correctness of this should be
> > evaluated against the fixed lost_retrans, rather than the already
> > broken one.
>
> You can find the result that the average goodput slightly improves
> against the only PATCH #1 (fixed lost_retrans) applied kernel.
...Yeah, sorry, I was mistaken when the slow-path is taken and when it's
not, thought that the old (current) fastpath_skb_hint code was more
intelligent than it currently is... :-) That continue should not be
a problem.
--
i.
^ 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