* [PATCH net-next] cnic: Fix build error on powerpc.
From: Michael Chan @ 2009-10-13 5:42 UTC (permalink / raw)
To: davem; +Cc: netdev, sfr, Michael Chan
Add missing #include <net/ip6_checksum.h>
Problem noted by Stephen Rothwell.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/cnic.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 6e7af7b..333b1d1 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -33,6 +33,7 @@
#include <net/route.h>
#include <net/ipv6.h>
#include <net/ip6_route.h>
+#include <net/ip6_checksum.h>
#include <scsi/iscsi_if.h>
#include "cnic_if.h"
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH] [NIU] VLAN does not work with niu driver
From: Joyce Yu @ 2009-10-13 5:41 UTC (permalink / raw)
To: netdev
From 0bb77e878758bd72051577bcc568e2b95c87c203 Mon Sep 17 00:00:00 2001
From: Joyce Yu <joyce.yu@sun.com>
Date: Mon, 12 Oct 2009 11:03:54 -0700
Subject: [PATCH] VLAN does not work with niu driver
Signed-off-by: Joyce Yu <joyce.yu@sun.com>
---
drivers/net/niu.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index f9364d0..9559e42 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -3480,6 +3480,7 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
unsigned int index = rp->rcr_index;
struct sk_buff *skb;
int len, num_rcr;
+ struct vlan_ethhdr *veth;
skb = netdev_alloc_skb(np->dev, RX_SKB_ALLOC_SIZE);
if (unlikely(!skb))
@@ -3545,7 +3546,15 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
rp->rcr_index = index;
skb_reserve(skb, NET_IP_ALIGN);
- __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
+ __pskb_pull_tail(skb, min(len, VLAN_ETH_HLEN));
+
+ veth = (struct vlan_ethhdr *)skb->data;
+ if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) {
+ skb->tail -= 4;
+ skb->data_len += 4;
+ skb_shinfo(skb)->frags[0].page_offset -= 4;
+ skb_shinfo(skb)->frags[0].size += 4;
+ }
rp->rx_packets++;
rp->rx_bytes += skb->len;
--
1.6.4
--
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-10-13 6:22 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AD41310.7040209@Sun.COM>
From: Joyce Yu <Joyce.Yu@Sun.COM>
Date: Mon, 12 Oct 2009 22:41:36 -0700
> +++ b/drivers/net/niu.c
> @@ -3480,6 +3480,7 @@ static int niu_process_rx_pkt(struct napi_struct
> *napi, struct niu *np,
Your email client is still breaking up long lines.
Take your time and fix your setup correctly. Read
'linux/Documentation/email-clients.txt' for tips.
^ permalink raw reply
* Re: [PATCH 1/1] net: Introduce recvmmsg socket syscall
From: David Miller @ 2009-10-13 6:40 UTC (permalink / raw)
To: acme
Cc: netdev, caitlin.bestler, vanhoof, williams, nhorman, nir.tzachar,
niv, paul.moore, remi.denis-courmont, steve
In-Reply-To: <1255364440-23271-1-git-send-email-acme@redhat.com>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Mon, 12 Oct 2009 13:20:40 -0300
> Meaning receive multiple messages, reducing the number of syscalls and
> net stack entry/exit operations.
>
> Next patches will introduce mechanisms where protocols that want to
> optimize this operation will provide an unlocked_recvmsg operation.
>
> This takes into account comments made by:
...
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
You missed the syscall entry addition for arch/sparc/kernel/systbls_32.S
but I fixed that up while applying this to net-next-2.6
Thanks.
^ permalink raw reply
* Re: [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: David Miller @ 2009-10-13 6:42 UTC (permalink / raw)
To: rakib.mullick; +Cc: netdev, akpm, zbr, linux-kernel
In-Reply-To: <b9df5fa10910122227r710d6782m89fc9ec4273487b8@mail.gmail.com>
From: Rakib Mullick <rakib.mullick@gmail.com>
Date: Tue, 13 Oct 2009 11:27:49 +0600
> On 10/12/09, David Miller <davem@davemloft.net> wrote:
>> From: Rakib Mullick <rakib.mullick@gmail.com>
>> Date: Mon, 12 Oct 2009 08:44:33 +0600
>>
>>
>> > */
>> > -static void cn_proc_mcast_ctl(struct cn_msg *msg)
>> > +static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
>> > netlink_skb_parms *nsp)
>>
>>
>> Your patches are unusable because your email client corrupts the
>> patch, here you can see it is splitting up long lines.
>>
>> Please fix this up and resubmit.
> Oops..... sorry for that. This is the second time I'm facing this
> problem. I'll try to fix it.
> I'm resubmitting the patch. Here I've recreate the patch to split the
> line into two.
> And it just reaches its 80 line mark. Hopefully it will be okay.
Upstream and my net-next-2.6 tree both have this function with
the proper parameters, maybe Andrew's -mm tree had some conflicts
and they weren't dealt with correctly.
^ permalink raw reply
* Re: [PATCH 0/8] gianfar: Add support for hibernation
From: David Miller @ 2009-10-13 6:57 UTC (permalink / raw)
To: avorontsov; +Cc: scottwood, linuxppc-dev, netdev, afleming
In-Reply-To: <20091012160000.GA32406@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Mon, 12 Oct 2009 20:00:00 +0400
> Here are few patches that add support for hibernation for gianfar
> driver.
>
> Technically, we could just do gfar_close() and then gfar_enet_open()
> sequence to restore gianfar functionality after hibernation, but
> close/open does so many unneeded things (e.g. BDs buffers freeing and
> allocation, IRQ freeing and requesting), that I felt it would be much
> better to cleanup and refactor some code to make the hibernation [and
> not only hibernation] code a little bit prettier.
I applied all of this, it's a really nice patch set. If there are any
problems we can deal with it using follow-on fixups.
I noticed something, in patch #3 where you remove the spurious wrap
bit setting in startup_gfar(). It looks like that was not only
spurious but it was doing it wrong too.
It's writing garbage into the status word, because it's not using the
BD_LFLAG() macro to shift the value up 16 bits.
^ permalink raw reply
* Re: [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: Rakib Mullick @ 2009-10-13 7:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, akpm, zbr, linux-kernel
In-Reply-To: <20091012.234214.110950674.davem@davemloft.net>
On 10/13/09, David Miller <davem@davemloft.net> wrote:
> From: Rakib Mullick <rakib.mullick@gmail.com>
>
> Date: Tue, 13 Oct 2009 11:27:49 +0600
>
>
> > On 10/12/09, David Miller <davem@davemloft.net> wrote:
> >> From: Rakib Mullick <rakib.mullick@gmail.com>
> >> Date: Mon, 12 Oct 2009 08:44:33 +0600
> >>
> >>
> >> > */
> >> > -static void cn_proc_mcast_ctl(struct cn_msg *msg)
> >> > +static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
> >> > netlink_skb_parms *nsp)
> >>
> >>
> >> Your patches are unusable because your email client corrupts the
> >> patch, here you can see it is splitting up long lines.
> >>
> >> Please fix this up and resubmit.
> > Oops..... sorry for that. This is the second time I'm facing this
> > problem. I'll try to fix it.
> > I'm resubmitting the patch. Here I've recreate the patch to split the
> > line into two.
> > And it just reaches its 80 line mark. Hopefully it will be okay.
>
>
> Upstream and my net-next-2.6 tree both have this function with
> the proper parameters, maybe Andrew's -mm tree had some conflicts
> and they weren't dealt with correctly.
>
Ah, sorry again. I should've check the upstream first. Sorry for noise.
Thanks,
^ permalink raw reply
* Re: [PATCH 1/3] mdio: Advertise pause (flow control) settings even if autoneg is off
From: David Miller @ 2009-10-13 7:01 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1255375577.2931.11.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 12 Oct 2009 20:26:17 +0100
> Currently, if pause autoneg is off we do not set either pause
> advertising flag. If autonegotiation of speed and duplex settings is
> enabled, there is no way for the link partner to distinguish this from
> our refusing to use pause frames.
>
> We should instead set the advertising flags according to the forced
> mode so that the link partner can follow our lead. This is consistent
> with the behaviour of other drivers.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/3] mdio: Expose pause frame advertising flags to ethtool
From: David Miller @ 2009-10-13 7:02 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1255375597.2931.13.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 12 Oct 2009 20:26:37 +0100
> In mdio45_ethtool_gset_npage() and mdio45_ethtool_gset(), check MDIO
> pause frame advertising flags and set the corresponding ethtool flags.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/3] sfc: 10Xpress: Initialise pause advertising flags
From: David Miller @ 2009-10-13 7:02 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1255375627.2931.15.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 12 Oct 2009 20:27:07 +0100
> The mdio module now handles reconfiguration of pause advertising
> through ethtool, but not initialisation. Add the necessary
> initialisation to tenxpress_phy_init().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] Fix IXP 2000 network driver building.
From: David Miller @ 2009-10-13 7:03 UTC (permalink / raw)
To: vince; +Cc: netdev
In-Reply-To: <1255376775-21390-1-git-send-email-vince@simtec.co.uk>
From: Vincent Sanders <vince@simtec.co.uk>
Date: Mon, 12 Oct 2009 20:46:15 +0100
> The IXP 2000 network driver was failing to build as it has its own
> statistics gathering which was not compatible with the recent network
> device operations changes. This patch fixes the driver in the obvious
> way and has been compile tested. I have been unable to get the ixp2000
> maintainer to comment or test this fix.
>
> Signed-off-by: Vincent Sanders <vince@simtec.co.uk>
Looks good enough for me, applied, thanks!
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-13 7:11 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20091013050705.GA2194@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 13 Oct 2009 07:07:06 +0200
> But in tcp_minisocks.c, this counter is only checked. And in
> fact, I have found no location which updates it. So I think
> that what was intended was to decrease it in tcp_minisocks
> whenever it is checked, which the trivial patch below does :
>
> diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> index f8d67cc..1b443b0 100644
> --- a/net/ipv4/tcp_minisocks.c
> +++ b/net/ipv4/tcp_minisocks.c
> @@ -645,6 +645,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
> if (inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
> TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
> + inet_csk(sk)->icsk_accept_queue.rskq_defer_accept--;
> inet_rsk(req)->acked = 1;
> return NULL;
> }
>
> Is there anything I am missing ?
Your logic looks sound and I can't come to any other conclusion
after going over this code, even going back to 2.4.x
Feel free to make a formal patch submission, thanks Willy.
^ permalink raw reply
* Re: [PATCH 2.6.32-rc4] net: VMware virtual Ethernet NIC driver: vmxnet3
From: David Miller @ 2009-10-13 7:16 UTC (permalink / raw)
To: sbhatewara
Cc: pv-drivers, netdev, linux-kernel, virtualization, chrisw, greg,
shemminger
In-Reply-To: <alpine.LRH.2.00.0910121447090.13205@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Mon, 12 Oct 2009 15:18:42 -0700 (PDT)
>
> Ethernet NIC driver for VMware's vmxnet3
>
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> This patch adds driver support for VMware's virtual Ethernet NIC: vmxnet3
> Guests running on VMware hypervisors supporting vmxnet3 device will thus have
> access to improved network functionalities and performance.
>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
> Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> Signed-off-by: Ronghua Zhang <ronghua@vmware.com>
Ok, looks good, applied to net-2.6, thanks!
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Willy Tarreau @ 2009-10-13 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091013.001106.226276168.davem@davemloft.net>
On Tue, Oct 13, 2009 at 12:11:06AM -0700, David Miller wrote:
> Your logic looks sound and I can't come to any other conclusion
> after going over this code, even going back to 2.4.x
>
> Feel free to make a formal patch submission, thanks Willy.
Ok, here it comes (I used my explanation as the commit message).
Thanks David,
Willy
>From da80c99a503bab1256706ed8d967e2ab3f71afe0 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 13 Oct 2009 07:26:54 +0200
Subject: tcp: fix tcp_defer_accept to consider the timeout
I was trying to use TCP_DEFER_ACCEPT and noticed that if the
client does not talk, the connection is never accepted and
remains in SYN_RECV state until the retransmits expire, where
it finally is deleted. This is bad when some firewall such as
netfilter sits between the client and the server because the
firewall sees the connection in ESTABLISHED state while the
server will finally silently drop it without sending an RST.
This behaviour contradicts the man page which says it should
wait only for some time :
TCP_DEFER_ACCEPT (since Linux 2.4)
Allows a listener to be awakened only when data arrives
on the socket. Takes an integer value (seconds), this
can bound the maximum number of attempts TCP will
make to complete the connection. This option should not
be used in code intended to be portable.
Also, looking at ipv4/tcp.c, a retransmit counter is correctly
computed :
case TCP_DEFER_ACCEPT:
icsk->icsk_accept_queue.rskq_defer_accept = 0;
if (val > 0) {
/* Translate value in seconds to number of
* retransmits */
while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
val > ((TCP_TIMEOUT_INIT / HZ) <<
icsk->icsk_accept_queue.rskq_defer_accept))
icsk->icsk_accept_queue.rskq_defer_accept++;
icsk->icsk_accept_queue.rskq_defer_accept++;
}
break;
==> rskq_defer_accept is used as a counter of retransmits.
But in tcp_minisocks.c, this counter is only checked. And in
fact, I have found no location which updates it. So I think
that what was intended was to decrease it in tcp_minisocks
whenever it is checked, which the trivial patch below does.
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/ipv4/tcp_minisocks.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index f8d67cc..2f676f3 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -644,6 +644,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
/* If TCP_DEFER_ACCEPT is set, drop bare ACK. */
if (inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
+ inet_csk(sk)->icsk_accept_queue.rskq_defer_accept--;
inet_rsk(req)->acked = 1;
return NULL;
}
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH 0/2] Build fixes for todays next tree
From: David Miller @ 2009-10-13 7:21 UTC (permalink / raw)
To: alan; +Cc: netdev, linux-kernel
In-Reply-To: <20091012152247.5694.77290.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Date: Mon, 12 Oct 2009 16:27:17 +0100
> Couple of networking warns/build fails
I'll apply these, thanks Alan.
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Eric Dumazet @ 2009-10-13 7:23 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20091013050705.GA2194@1wt.eu>
Willy Tarreau a écrit :
> Hello,
>
> I was trying to use TCP_DEFER_ACCEPT and noticed that if the
> client does not talk, the connection is never accepted and
> remains in SYN_RECV state until the retransmits expire, where
> it finally is deleted. This is bad when some firewall such as
> netfilter sits between the client and the server because the
> firewall sees the connection in ESTABLISHED state while the
> server will finally silently drop it without sending an RST.
>
> This behaviour contradicts the man page which says it should
> wait only for some time :
>
> TCP_DEFER_ACCEPT (since Linux 2.4)
> Allows a listener to be awakened only when data arrives
> on the socket. Takes an integer value (seconds), this
> can bound the maximum number of attempts TCP will
> make to complete the connection. This option should not
> be used in code intended to be portable.
>
> Also, looking at ipv4/tcp.c, a retransmit counter is correctly
> computed :
>
> case TCP_DEFER_ACCEPT:
> icsk->icsk_accept_queue.rskq_defer_accept = 0;
> if (val > 0) {
> /* Translate value in seconds to number of
> * retransmits */
> while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
> val > ((TCP_TIMEOUT_INIT / HZ) <<
> icsk->icsk_accept_queue.rskq_defer_accept))
> icsk->icsk_accept_queue.rskq_defer_accept++;
> icsk->icsk_accept_queue.rskq_defer_accept++;
> }
> break;
>
> ==> rskq_defer_accept is used as a counter of retransmits.
>
> But in tcp_minisocks.c, this counter is only checked. And in
> fact, I have found no location which updates it. So I think
> that what was intended was to decrease it in tcp_minisocks
> whenever it is checked, which the trivial patch below does :
>
> diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> index f8d67cc..1b443b0 100644
> --- a/net/ipv4/tcp_minisocks.c
> +++ b/net/ipv4/tcp_minisocks.c
> @@ -645,6 +645,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
> if (inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
> TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
> + inet_csk(sk)->icsk_accept_queue.rskq_defer_accept--;
> inet_rsk(req)->acked = 1;
> return NULL;
> }
>
I dont understand why you want to decrement rskq_defer_accept here.
We receive a pure ACK (wihout DATA).
We should receive exactly one such ACK.
(This is the third packet of the three way TCP handshake)
How this can solve the problem you mention ?
(ie, not sending an RST when we timeout the SYN_RECV session)
^ permalink raw reply
* Re: [PATCHv3] netxen: fix pci bar mapping
From: David Miller @ 2009-10-13 7:26 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255329573-17701-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 23:39:33 -0700
> Use resource_size_t for PCI resource remapping instead
> of unsigned long. Physical addresses can exceed range of
> long data type (e.g with PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-13 7:27 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20091013071955.GA3587@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 13 Oct 2009 09:19:55 +0200
> On Tue, Oct 13, 2009 at 12:11:06AM -0700, David Miller wrote:
>> Your logic looks sound and I can't come to any other conclusion
>> after going over this code, even going back to 2.4.x
>>
>> Feel free to make a formal patch submission, thanks Willy.
>
> Ok, here it comes (I used my explanation as the commit message).
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] Teach pegasus driver to ignore bluetoother adapters with clashing Vendor:Product IDs
From: David Miller @ 2009-10-13 7:31 UTC (permalink / raw)
To: rankincj-/E1597aS9LQAvxtiuMwx3w
Cc: petkan-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <910710.29413.qm-7brg08ZX0I2B9c0Qi4KiSl5cfvJIxWXgQQ4Iyu8u01E@public.gmane.org>
From: Chris Rankin <rankincj-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date: Sun, 11 Oct 2009 06:57:50 -0700 (PDT)
> I submitted this patch months ago and then forgot about it, but I've
> noticed that it hasn't been picked up so I've regenerated it against
> 2.6.31.
>
> Short description:
>
> The Belkin F8T012xx1 bluetooth adaptor has the same vendor and product
> IDs as the Belkin F5D5050, so we need to teach the pegasus driver to
> ignore adaptors belonging to the "Wireless" class 0xE0. For this one
> case anyway, seeing as pegasus is a driver for "Wired" adaptors.
Applied, but please put your Signed-off-by: here at the end
of your commit message rather than after the patch.
Putting it after the patch makes it more difficult for
automated tools to pick it up, thanks!
--
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 kernel 2.6.32-rc3] 3c574_cs: spin_lock the set_multicast_list function
From: David Miller @ 2009-10-13 7:33 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20091011211225.35e6fb4a.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 11 Oct 2009 21:12:25 +0900
> 3c574_cs:
> spin_lock the set_multicast_list function.
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks!
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Willy Tarreau @ 2009-10-13 7:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AD42B0F.8010809@gmail.com>
On Tue, Oct 13, 2009 at 09:23:59AM +0200, Eric Dumazet wrote:
> Willy Tarreau a écrit :
> > Hello,
> >
> > I was trying to use TCP_DEFER_ACCEPT and noticed that if the
> > client does not talk, the connection is never accepted and
> > remains in SYN_RECV state until the retransmits expire, where
> > it finally is deleted. This is bad when some firewall such as
> > netfilter sits between the client and the server because the
> > firewall sees the connection in ESTABLISHED state while the
> > server will finally silently drop it without sending an RST.
> >
> > This behaviour contradicts the man page which says it should
> > wait only for some time :
> >
> > TCP_DEFER_ACCEPT (since Linux 2.4)
> > Allows a listener to be awakened only when data arrives
> > on the socket. Takes an integer value (seconds), this
> > can bound the maximum number of attempts TCP will
> > make to complete the connection. This option should not
> > be used in code intended to be portable.
> >
> > Also, looking at ipv4/tcp.c, a retransmit counter is correctly
> > computed :
> >
> > case TCP_DEFER_ACCEPT:
> > icsk->icsk_accept_queue.rskq_defer_accept = 0;
> > if (val > 0) {
> > /* Translate value in seconds to number of
> > * retransmits */
> > while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
> > val > ((TCP_TIMEOUT_INIT / HZ) <<
> > icsk->icsk_accept_queue.rskq_defer_accept))
> > icsk->icsk_accept_queue.rskq_defer_accept++;
> > icsk->icsk_accept_queue.rskq_defer_accept++;
> > }
> > break;
> >
> > ==> rskq_defer_accept is used as a counter of retransmits.
> >
> > But in tcp_minisocks.c, this counter is only checked. And in
> > fact, I have found no location which updates it. So I think
> > that what was intended was to decrease it in tcp_minisocks
> > whenever it is checked, which the trivial patch below does :
> >
> > diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> > index f8d67cc..1b443b0 100644
> > --- a/net/ipv4/tcp_minisocks.c
> > +++ b/net/ipv4/tcp_minisocks.c
> > @@ -645,6 +645,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
> > if (inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
> > TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
> > + inet_csk(sk)->icsk_accept_queue.rskq_defer_accept--;
> > inet_rsk(req)->acked = 1;
> > return NULL;
> > }
> >
>
>
> I dont understand why you want to decrement rskq_defer_accept here.
Because the "timeout" as set by setsockopt() is converted into number
of retransmits.
> We receive a pure ACK (wihout DATA).
> We should receive exactly one such ACK.
No, we will receive other ones because the socket remains in SYN_RECV
and since the local system ignores this ACK, it will send a SYN-ACK
again, triggering a new ACK from the client.
Although the concept looks strange at first, I think its implementation
is in fact very smart because it manages to defer acceptation with an
approximate timeout without using another timer.
The most common requirement should only be to wait for an HTTP request
to come in, and setting the timeout to anything non-zero is enough to
just drop the first empty ACK and immediately accept on the data
segment, so this method fits this purpose perfectly.
Regards,
Willy
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-13 7:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: w, netdev
In-Reply-To: <4AD42B0F.8010809@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 13 Oct 2009 09:23:59 +0200
> I dont understand why you want to decrement rskq_defer_accept here.
> We receive a pure ACK (wihout DATA).
> We should receive exactly one such ACK.
> (This is the third packet of the three way TCP handshake)
>
> How this can solve the problem you mention ?
> (ie, not sending an RST when we timeout the SYN_RECV session)
I'll hold off on this patch until Eric's comments are
addressed, thanks.
^ permalink raw reply
* Re: [PATCH netnext-2.6] bonding: change bond_create_proc_entry() to return void
From: David Miller @ 2009-10-13 7:45 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: fubar, netdev, bonding-devel, rakib.mullick
In-Reply-To: <1255207307-5976-1-git-send-email-nicolas.2p.debian@free.fr>
From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Date: Sat, 10 Oct 2009 22:41:47 +0200
> The function bond_create_proc_entry is currently of type int.
>
> Two versions of this function exist:
>
> The one in the ifdef CONFIG_PROC_FS branch always return 0.
> The one in the else branch (which is empty) return nothing.
>
> When CONFIG_PROC_FS is undef, this cause the following warning:
>
> drivers/net/bonding/bond_main.c: In function `bond_create_proc_entry':
> drivers/net/bonding/bond_main.c:3393: warning: control reaches end of
> non-void function
>
> No caller of this function use the returned value.
>
> So change the returned type from int to void and remove the
> useless return 0; .
>
> Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-13 7:54 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091009220546.GB7618@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Sat, 10 Oct 2009 00:05:46 +0200
> Hi,
>
> Digging list archives I suspect the current value of size_max is the
> remnant of the zero-copy mode that was not merged. So I propose the
> following patch that IMHO makes the value of size_max consistent with
> how the frame is actually handled in tpacket_fill_skb().
>
> If the zero-copy mode is ever to be resurrected, then the user should
> explicitely request it, and either the length of the extra padding
> should be the same for 32-bit and 64-bit kernels or there must be a way
> to query the value at run time.
Johann, please take a look at this.
Gabor, please resubmit your patch with a proper Signed-off-by:
tag so I can apply it if it is correct.
Thanks.
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Olaf van der Spek @ 2009-10-13 8:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <20091013073410.GA3792@1wt.eu>
On Tue, Oct 13, 2009 at 9:34 AM, Willy Tarreau <w@1wt.eu> wrote:
>> We receive a pure ACK (wihout DATA).
>> We should receive exactly one such ACK.
>
> No, we will receive other ones because the socket remains in SYN_RECV
> and since the local system ignores this ACK, it will send a SYN-ACK
> again, triggering a new ACK from the client.
Why does it ignore the ACK? Just because that's the simplest
implementation of defer_accept?
^ 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