* 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
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Willy Tarreau @ 2009-10-13 8:12 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20091013.003506.67125018.davem@davemloft.net>
On Tue, Oct 13, 2009 at 12:35:06AM -0700, David Miller wrote:
> 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.
I have replied, but let's wait for Eric's response.
Willy
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: Eric Dumazet @ 2009-10-13 8:29 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20091013073410.GA3792@1wt.eu>
Willy Tarreau a écrit :
> 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.
>
Indeed, thanks for this detailed explanation, I missed the SYN-ACK timer
and retransmits.
I played some years ago with TCP_DEFER_ACCEPT and got some unexpected results
on transmitted packets (server was consuming more bandwidth), and I know understand
it was very broken until today !
Thanks again Willy
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-13 8:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: w, netdev
In-Reply-To: <4AD43A4F.1090800@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 13 Oct 2009 10:29:03 +0200
> Indeed, thanks for this detailed explanation, I missed the SYN-ACK timer
> and retransmits.
>
> I played some years ago with TCP_DEFER_ACCEPT and got some unexpected results
> on transmitted packets (server was consuming more bandwidth), and I know understand
> it was very broken until today !
>
> Thanks again Willy
Ok, and with that I put Willy's patch back in.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-13 9:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Fenghua Yu, Greg Kroah-Hartman, linux-ia64, Tony Luck, x86,
netdev, linux-kernel, linux-altix, Yevgeny Petrilin,
FUJITA Tomonori, linuxppc-dev, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, sparclinux, Thomas Gleixner, linux-usb,
David S. Miller, Lothar Wassmann
In-Reply-To: <20091013021818.GA3898@localhost.localdomain>
My user space testing exposed off-by-one error find_next_zero_area
in iommu-helper. Some zero area cannot be found by this bug.
Subject: [PATCH] Fix off-by-one error in find_next_zero_area
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
lib/iommu-helper.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index 75dbda0..afc58bc 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -19,7 +19,7 @@ again:
index = (index + align_mask) & ~align_mask;
end = index + nr;
- if (end >= size)
+ if (end > size)
return -1;
for (i = index; i < end; i++) {
if (test_bit(i, map)) {
--
1.5.4.3
^ permalink raw reply related
* Re: [Bug #14378] Problems with net/core/skbuff.c
From: Massimo Cetra @ 2009-10-13 9:23 UTC (permalink / raw)
To: Massimo Cetra; +Cc: David Miller, rjw, linux-kernel, kernel-testers, netdev
In-Reply-To: <4AD44435.3050703@navynet.it>
Massimo Cetra ha scritto:
> David Miller ha scritto:
>> From: "Rafael J. Wysocki" <rjw@sisk.pl>
>> Date: Mon, 12 Oct 2009 00:22:04 +0200 (CEST)
>>
>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
>>> Subject : Problems with net/core/skbuff.c
>>> Submitter : Massimo Cetra <mcetra@navynet.it>
>>> Date : 2009-10-08 14:51 (4 days old)
>>> References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
>>>
>>
>> I don't know what to do about this one.
>>
>> The user indicates that they have the vserver patches applied,
>> so maybe there is some interaction with that stuff.
>>
> Actually i found another oops which is very similar to the previous one.
And here it is another one, this time triggered by postfix, where mor
drbd nor vserver are involved.
This is not the same server where the other oopses were grabbed.
Max
^ 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