* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: David Miller @ 2010-09-27 1:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, xiaosuo, socketcan, mst, netdev
In-Reply-To: <1285311660.2380.62.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:01:00 +0200
> af_packet (tx with mmap) is broken. I wonder who really uses it ?
I suspect now that af_packet supports VNET headers on transmit,
there are some things using this tx+mmap thing for sure.
> To properly cope with paged skbs, it should not try to fit several
> packets per page.
>
> The mmap api should change so that one mmaped page belongs to at most
> one skb, or else we need invasive changes in net/core
>
> This probably makes this stuff less interesting, unless the need is to
> send big packets. In this case, why splice was not used instead of
> custom mmap ?
I don't really see what the big issue is.
When the data destructor runs it means that packet's part of the pages
are available for reuse for the tx mmap client. And if I read it
correctly, that's exactly what tpacket_destruct_skb() is in fact doing.
There seems to be no conflict with that rule and reusing a page for
multiple packets.
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Changli Gao @ 2010-09-27 1:24 UTC (permalink / raw)
To: Jarek Poplawski, xiaohui.xin
Cc: David S. Miller, Eric Dumazet, Oliver Hartkopp,
Michael S. Tsirkin, netdev
In-Reply-To: <20100924063623.GA6359@ff.dom.local>
On Fri, Sep 24, 2010 at 2:36 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On 2010-09-23 12:15, Changli Gao wrote:
>> Since skb->destructor() is used to account socket memory, and maybe called
>> before the skb is sent out, a corrupt skb maybe sent out finally.
>>
>> A new destructor is added into structure skb_shared_info(), and it won't
>> be called until the last reference to the data of an skb is put. af_packet
>> uses this destructor instead.
>
> IMHO, we shouldn't allow for fixing the bad design of one protocol at
> the expense of others by adding more and more conditionals. The proper
> way of handling paged skbs (splice compatible) exists. And the current
> patch doesn't even fix the problem completely against things like
> pskb_expand_head or pskb_copy.
pskb_expand_head is handled in my patch, but not pskb_copy().
indeed, there are many issues to fix, and xiaohui's patch may have the
same issues. The proper way may put the destruct handler in pages
instead.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: David Miller @ 2010-09-27 1:22 UTC (permalink / raw)
To: jarkao2; +Cc: xiaosuo, eric.dumazet, socketcan, mst, netdev
In-Reply-To: <20100924063623.GA6359@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 24 Sep 2010 06:36:23 +0000
> af_packet could check some flag which guarantees the queued dev can do
> skb_orphan after the real xmit and copy buffers otherwise.
Jarek, we pre-orphan SKBs in the core way before device even gets
the packet.
So talking about device-specific situations where this could behave
differently has no sense.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-27 1:12 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926232530.GK12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 27 Sep 2010 01:25:30 +0200
> Agreed. But that's not a reason for killing outgoing data that is
> being sent when there are some data left in the rcv buffer.
What alternative notification to the peer do you suggest other than a
reset, then? TCP gives us no other.
That's the thing, data integrity is full duplex, thus once it has been
compromised in one direction everything currently in flight must be
zapped.
^ permalink raw reply
* RE: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
From: Xin, Xiaohui @ 2010-09-27 0:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100926170142.GA24196@redhat.com>
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Monday, September 27, 2010 1:02 AM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
>
>On Sat, Sep 25, 2010 at 12:27:18PM +0800, xiaohui.xin@intel.com wrote:
>> We provide an zero-copy method which driver side may get external
>> buffers to DMA. Here external means driver don't use kernel space
>> to allocate skb buffers. Currently the external buffer can be from
>> guest virtio-net driver.
>>
>> The idea is simple, just to pin the guest VM user space and then
>> let host NIC driver has the chance to directly DMA to it.
>> The patches are based on vhost-net backend driver. We add a device
>> which provides proto_ops as sendmsg/recvmsg to vhost-net to
>> send/recv directly to/from the NIC driver. KVM guest who use the
>> vhost-net backend may bind any ethX interface in the host side to
>> get copyless data transfer thru guest virtio-net frontend.
>> patch 01-10: net core and kernel changes.
>> patch 11-13: new device as interface to mantpulate external buffers.
>> patch 14: for vhost-net.
>> patch 15: An example on modifying NIC driver to using napi_gro_frags().
>> patch 16: An example how to get guest buffers based on driver
>> who using napi_gro_frags().
>> patch 17: It's a patch to address comments from Michael S. Thirkin
>> to add 2 new ioctls in mp device.
>> We split it out here to make easier reiewer.
>
>
>
>I commented on how to avoid mm semaphore on data path separately, and
>since you didn't have time to review that yet, I won't repeat that here.
>
I think I did avoid that in data path to use mm semaphore. I stored the value
in mp structures and check with that.
>At this point what are the plans on macvtap integration?
>You indicated this is the interface you intend to use longterm.
I'm now working on that.
Thanks
Xiaohui
^ permalink raw reply
* RE: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
From: Xin, Xiaohui @ 2010-09-27 0:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100926115018.GA19655@redhat.com>
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Sunday, September 26, 2010 7:50 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>
>On Thu, Sep 23, 2010 at 08:56:33PM +0800, Xin, Xiaohui wrote:
>> >-----Original Message-----
>> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >Sent: Wednesday, September 22, 2010 7:55 PM
>> >To: Xin, Xiaohui
>> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >jdike@linux.intel.com
>> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >
>> >On Wed, Sep 22, 2010 at 07:41:36PM +0800, Xin, Xiaohui wrote:
>> >> >-----Original Message-----
>> >> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >> >Sent: Tuesday, September 21, 2010 9:14 PM
>> >> >To: Xin, Xiaohui
>> >> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >> >jdike@linux.intel.com
>> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >> >
>> >> >On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
>> >> >> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >> >> >Sent: Monday, September 20, 2010 7:37 PM
>> >> >> >To: Xin, Xiaohui
>> >> >> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >> >> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >> >> >jdike@linux.intel.com
>> >> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >> >> >
>> >> >> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
>> >> >> >> From: Xin Xiaohui <xiaohui.xin@intel.com>
>> >> >> >>
>> >> >> >> ---
>> >> >> >> Michael,
>> >> >> >> I have move the ioctl to configure the locked memory to vhost
>> >> >> >
>> >> >> >It's ok to move this to vhost but vhost does not
>> >> >> >know how much memory is needed by the backend.
>> >> >>
>> >> >> I think the backend here you mean is mp device.
>> >> >> Actually, the memory needed is related to vq->num to run zero-copy
>> >> >> smoothly.
>> >> >> That means mp device did not know it but vhost did.
>> >> >
>> >> >Well, this might be so if you insist on locking
>> >> >all posted buffers immediately. However, let's assume I have a
>> >> >very large ring and prepost a ton of RX buffers:
>> >> >there's no need to lock all of them directly:
>> >> >
>> >> >if we have buffers A and B, we can lock A, pass it
>> >> >to hardware, and when A is consumed unlock A, lock B
>> >> >and pass it to hardware.
>> >> >
>> >> >
>> >> >It's not really critical. But note we can always have userspace
>> >> >tell MP device all it wants to know, after all.
>> >> >
>> >> Ok. Here are two values we have mentioned, one is how much memory
>> >> user application wants to lock, and one is how much memory locked
>> >> is needed to run smoothly. When net backend is setup, we first need
>> >> an ioctl to get how much memory is needed to lock, and then we call
>> >> another ioctl to set how much it want to lock. Is that what's in your mind?
>> >
>> >That's fine.
>> >
>> >> >> And the rlimt stuff is per process, we use current pointer to set
>> >> >> and check the rlimit, the operations should be in the same process.
>> >> >
>> >> >Well no, the ring is handled from the kernel thread: we switch the mm to
>> >> >point to the owner task so copy from/to user and friends work, but you
>> >> >can't access the rlimit etc.
>> >> >
>> >> Yes, the userspace and vhost kernel is not the same process. But we can
>> >> record the task pointer as mm.
>> >
>> >So you will have to store mm and do device->mm, not current->mm.
>> >Anyway, better not touch mm on data path.
>> >
>> >> >> Now the check operations are in vhost process, as mp_recvmsg() or
>> >> >> mp_sendmsg() are called by vhost.
>> >> >
>> >> >Hmm, what do you mean by the check operations?
>> >> >send/recv are data path operations, they shouldn't
>> >> >do any checks, should they?
>> >> >
>> >> As you mentioned what infiniband driver done:
>> >> down_write(¤t->mm->mmap_sem);
>> >>
>> >> locked = npages + current->mm->locked_vm;
>> >> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>> >>
>> >> if ((locked > lock_limit) && !capable(CAP_IPC_LOCK)) {
>> >> ret = -ENOMEM;
>> >> goto out;
>> >> }
>> >>
>> >> cur_base = addr & PAGE_MASK;
>> >>
>> >> ret = 0;
>> >> while (npages) {
>> >> ret = get_user_pages(current, current->mm, cur_base,
>> >> min_t(unsigned long, npages,
>> >> PAGE_SIZE / sizeof (struct page
>*)),
>> >> 1, !umem->writable, page_list,
>vma_list);
>> >>
>> >> I think it's a data path too.
>> >
>> >in infiniband this is used to 'register memory' which is not data path.
>> >
>> >> We do the check because get_user_pages() really pin and locked
>> >> the memory.
>> >
>> >Don't do this. Performance will be bad.
>> >Do the check once in ioctl and increment locked_vm by max amount you will use.
>> >On data path just make sure you do not exceed what userspace told you
>> >to.
>>
>> What's in my mind is that in the ioctl which to get the memory locked needed to run
>smoothly,
>> it just return a value of how much memory is needed by mp device.
>> And then in the ioctl which to set the memory locked by user space, it check the rlimit and
>> increment locked_vm by user want.
>
>Fine.
>
>> But I'm not sure how to "make sure do not exceed what
>> userspace told to". If we don't check locked_vm, what do we use to check? And Is it
>another kind of check on data path?
>
>An example: on ioctl we have incremented locked_vm by say 128K.
>We will record this number 128K in mp data structure and on data path
>verify that amount of memory we actually lock with get_user_pages_fast
>does not exceed 128K. This is not part of mm and so can use
>any locking scheme, no need to take mm semaphore.
>
>
Thanks, and later, I did do that in v11 patches.
>
>> >
>> >>
>> >> >> So set operations should be in
>> >> >> vhost process too, it's natural.
>> >> >>
>> >> >> >So I think we'll need another ioctl in the backend
>> >> >> >to tell userspace how much memory is needed?
>> >> >> >
>> >> >> Except vhost tells it to mp device, mp did not know
>> >> >> how much memory is needed to run zero-copy smoothly.
>> >> >> Is userspace interested about the memory mp is needed?
>> >> >
>> >> >Couldn't parse this last question.
>> >> >I think userspace generally does want control over
>> >> >how much memory we'll lock. We should not just lock
>> >> >as much as we can.
>> >> >
>> >> >--
>> >> >MST
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 23:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100926.160838.246540910.davem@davemloft.net>
On Sun, Sep 26, 2010 at 04:08:38PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 27 Sep 2010 00:54:40 +0200
>
> > On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
> >> From: Willy Tarreau <w@1wt.eu>
> >> Date: Mon, 27 Sep 2010 00:34:48 +0200
> >>
> >> > I don't see what is being violated nor what reliability has been
> >> > compromised.
> >>
> >> The TCP protcol's obligation to reliably deliver data between
> >> two applications, that is what has been violated.
> >
> > Once again, I don't see why, due to the orphans mechanism. Please
> > consider for a minute that the application-level close() is distinct
> > from the protocol-level close. The application-level close() just
> > instructs the lower layer to turn the connection into an orphan.
>
> A close() is equivalent to a shutdown() with both the send and
> receive masks set.
>
> You are telling TCP that you expect no more data to be received.
Agreed. But that's not a reason for killing outgoing data that is
being sent when there are some data left in the rcv buffer.
Honnestly David, after some thinking, could you still find a valid use
of the orphans as they are now ? I personally fail to do so. And what
drove me to the kernel on this issue is that I found the behaviour
inconsistent with the principle of the orphan itself.
Willy
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 23:08 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926225440.GH12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 27 Sep 2010 00:54:40 +0200
> On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> Date: Mon, 27 Sep 2010 00:34:48 +0200
>>
>> > I don't see what is being violated nor what reliability has been
>> > compromised.
>>
>> The TCP protcol's obligation to reliably deliver data between
>> two applications, that is what has been violated.
>
> Once again, I don't see why, due to the orphans mechanism. Please
> consider for a minute that the application-level close() is distinct
> from the protocol-level close. The application-level close() just
> instructs the lower layer to turn the connection into an orphan.
A close() is equivalent to a shutdown() with both the send and
receive masks set.
You are telling TCP that you expect no more data to be received.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 22:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100926.153832.115943505.davem@davemloft.net>
On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 27 Sep 2010 00:34:48 +0200
>
> > I don't see what is being violated nor what reliability has been
> > compromised.
>
> The TCP protcol's obligation to reliably deliver data between
> two applications, that is what has been violated.
Once again, I don't see why, due to the orphans mechanism. Please
consider for a minute that the application-level close() is distinct
from the protocol-level close. The application-level close() just
instructs the lower layer to turn the connection into an orphan. Any
pending data is sent. Incoming data may accumulate until the receive
buffer is full, but at least the other end regularly acks what is
being sent. Then once the other end has acked the orphaned data, we
perform the protocol-level close, which consists in either switching
the connection to TIME_WAIT if there are no pending data, or to send
an RST if there are pending data.
> You don't have to like this, but you certainly must cope with it
> in your applications :-)
It's not a matter of liking it or not, but to use something reliable.
Orphans are supposed to be (as long as there aren't any memory shortage).
But they're not. And my concern is that the information that my app
could make use for a reliable close exists in the kernel but is not
usable from the application level.
In fact, the end result is that we're observing exactly the opposite
of what RFC2525 wanted to achieve : their goal was to perform early
resets on aborts in order not to have to transfer too many data, but
the way we have it makes it mandatory to read everything because some
information is lost between the kernel and the application.
Willy
^ permalink raw reply
* Re: [PATCH] de2104x: fix TP link detection
From: David Miller @ 2010-09-26 22:52 UTC (permalink / raw)
To: jgarzik; +Cc: linux, netdev, linux-kernel
In-Reply-To: <AANLkTikasuZbf6ymCWBjAW3oq7+BBox1N06jPZqTBQr4@mail.gmail.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Sat, 25 Sep 2010 16:58:10 -0400
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
Applied, thanks guys.
^ permalink raw reply
* Re: de2104x: fix power management
From: David Miller @ 2010-09-26 22:49 UTC (permalink / raw)
To: jgarzik; +Cc: linux, netdev, linux-kernel
In-Reply-To: <4C9E2E88.3080101@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Sat, 25 Sep 2010 13:16:56 -0400
> On 09/25/2010 05:57 AM, Ondrej Zary wrote:
>> At least my 21041 cards come out of suspend with bus mastering
>> disabled so
>> they did not work after resume(no data transferred).
>> After adding pci_set_master(), the driver oopsed immediately on resume
>> -
>> because de_clean_rings() is called on suspend but de_init_rings() call
>> was missing in resume.
>>
>> Also disable link (reset SIA) before sleep (de4x5 does this too).
>>
>> Signed-off-by: Ondrej Zary<linux@rainbow-software.org>
...
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
I'll apply this, thanks guys.
> IMO suspend/resume could use another look; if netif_running is false
> (interface is down), de2104x does not put the PCI device to sleep,
> which seems strange.
TG3 does the same.
The reason is that until we bringing the device up (and thus
netif_running becomes true) the device is left in the most appropriate
powered down state.
At least that is my understanding.
What is appropriate for any driver in this situation depends upon how
it programs the device before ->open() occurs.
> I also wonder if rtnl_lock() couldn't be eliminated, as other net
> drivers don't need it in suspend/resume.
I suspect the RTNL stuff here can be safely removed.
I think it's using it to guard the netif_running() check but that
isn't necessary.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 22:38 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926223448.GF12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 27 Sep 2010 00:34:48 +0200
> I don't see what is being violated nor what reliability has been
> compromised.
The TCP protcol's obligation to reliably deliver data between
two applications, that is what has been violated.
You don't have to like this, but you certainly must cope with it
in your applications :-)
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 22:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100926.151346.112585478.davem@davemloft.net>
Hi David,
On Sun, Sep 26, 2010 at 03:13:46PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Sun, 26 Sep 2010 15:17:17 +0200
>
> > I've read RFC 2525 #2.17 and it shows quite interesting examples of what
> > it wanted to protect against. However, the recommendation did not consider
> > the fact that there could be some unacked pending data in the outgoing
> > buffers.
>
> It doesn't matter if there is any pending data still outgoing when
> we received this data after close().
>
> The issue is that the reliable transport nature of TCP has been
> violated, and as such the entire connection's reliability has
> been compromised.
I don't see what is being violated nor what reliability has been
compromised. Some data has reliably been delivered to the kernel,
a shutdown() has reliably been performed, followed by a close()
which then makes use of the orphans mechanism to deliver the data
to the other side.
> The only appropriate response is a full reset.
I'm not against the full reset, I really want it, but I don't want
it to be sent before the previous data. The reset here is being sent
out of order and kills the data that were previously going to be
delivered. It's all about a timing issue BTW. If the other side sends
its data slightly later, it reliably receives its response followed by
a reset it understands and respects. So this is a valid working
mechanism. I'm just trying to ensure that the reset does not break
ordering and is delivered after the pending data.
> As Eric said, your only option is to fully sync the data coming
> from the peer.
The why are we keeping the orphans feature and not get rid of it then ?
It becomes completely useless, and we can as well disable all the
lingering options which have no use beyond that.
The lingering controls how long unacked data remains in an orphaned
socket, which precisely is my case. If the application has no way to
know whether it can close, all this becomes useless.
I can easily admit I'm doing something wrong, but here we have a
feature that I think I'm correctly using and it does not always
work, and I can't know when I can use it, so I should not use it.
Obviously, either I'm missing something or there's something wrong.
And that's what I'd like to find out.
Thanks,
Willy
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 22:19 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, netdev
In-Reply-To: <20100926214614.GD12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 26 Sep 2010 23:46:14 +0200
> Eventhough we optimize for the most common cases, that doesn't save us
> from having to support the legacy cases.
There is nothing "legacy" about performing a proper reset when data
was lost.
Otherwise the peer has every right to believe that the data it sent
was sinked all the way to the remote application.
Which it wasn't.
Reset is the only appropriate action in this situation.
If the application layer protocol you're dealing with is so broken
that a multi-megabyte transfer happens even when it gets an error
indication, that really isn't the kernels problem and it is very clear
where the "fix" lies and that in the application layer proptocol and
handling.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 22:14 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, netdev
In-Reply-To: <20100926191632.GB13046@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 26 Sep 2010 21:16:32 +0200
> On Sun, Sep 26, 2010 at 07:40:15PM +0200, Willy Tarreau wrote:
>> 3) when an ACK comes from the other side, either it's below our last
>> seq, and we simply ignore it, just as if we were in TIME_WAIT, or
>> it is equal to the last seq and indicates that it's now safe to
>> reset ; we would then just send the RST to notify the other side
>> that the data it sent were not read. The connection can then either
>> be destroyed or put in TIME_WAIT. It's the point where the connection
>> normally switches from FIN_WAIT1 to FIN_WAIT2, since the FIN has been
>> acked. The only difference is that we don't need a FIN_WAIT2 state
>> for an orphan.
>
> In fact, the following patch seems to provide the expected result :
There is no way I'm applying this.
Pending outgoing data means nothing, and not sending out the RST is
wrong because there will be no notification to the peer that you
decided to close and ignore the data stream the peer sent, and thus
data was lost.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 22:13 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926131717.GA13046@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 26 Sep 2010 15:17:17 +0200
> I've read RFC 2525 #2.17 and it shows quite interesting examples of what
> it wanted to protect against. However, the recommendation did not consider
> the fact that there could be some unacked pending data in the outgoing
> buffers.
It doesn't matter if there is any pending data still outgoing when
we received this data after close().
The issue is that the reliable transport nature of TCP has been
violated, and as such the entire connection's reliability has
been compromised.
The only appropriate response is a full reset.
As Eric said, your only option is to fully sync the data coming
from the peer.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 22:10 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, netdev
In-Reply-To: <20100926184914.GC12373@1wt.eu>
TCP is a reliable transport.
If you choose to close before the data from the peer has been fully
received, you've subverted the reliability of the data transport.
Reset is the only reasonable action in this situation.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 21:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1285534871.2357.19.camel@edumazet-laptop>
On Sun, Sep 26, 2010 at 11:01:11PM +0200, Eric Dumazet wrote:
> Le dimanche 26 septembre 2010 à 20:49 +0200, Willy Tarreau a écrit :
> > On Sun, Sep 26, 2010 at 08:35:15PM +0200, Eric Dumazet wrote:
> > > I was referring to this code. It works well for me.
> > >
> > > shutdown(fd, SHUT_RDWR);
> > > while (recv(fd, buff, sizeof(buff), 0) > 0)
> > > ;
> > > close(fd);
> >
> > Ah this one yes, but it's overkill. We're actively pumping data from the
> > other side to drop it on the floor until it finally closes while we only
> > need to know when it has ACKed the FIN. In practice, doing that on a POST
> > request which causes a 302 or 401 will result in the whole amount of data
> > being transferred twice. Not only this is bad for the bandwidth, this is
> > also bad for the user, as we're causing him to experience a complete upload
> > twice, just to be sure it has received the FIN, while it's pretty obvious
> > that it's not necessary in 99.9% of the cases.
> >
>
> I dont understand how recv() could transfert data twice.
That's not what I said, I said the client would have to retransfer. Here's
what typically happens, for instance with an authentication requirement :
Client Server
SYN ----------->
<----------- SYN/ACK
ACK ----------->
POST /some_url HTTP/1.1
Host: xxx
Content-length: 10 meg
------ headers are sent ---->
xxxxxxxxxxxxx
xxxxxxxxxxxxx ----- data are being sent -> HTTP/1.1 401 forbidden
xxxxxxxxxxxxx WWW-Authenticate: basic realm="xxx"
... Connection: close
<----------------------------
xxxxxxxxxxxxx
<---------------------------- FIN
xxxxxxxxxxxxx
...
10 megs of data being sent and drained by the server
xxxxxxxxxxxxx
FIN --------------->
<-------------- ACK
second attempt with credentials this time
SYN ----------->
<----------- SYN/ACK
ACK ----------->
POST /some_url HTTP/1.1
Host: x
authorization: basic xyz
Content-length: 10 meg
------ headers are sent ---->
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
etc...
So in this case the data is effectively transmitted twice. With an
RST once the client acks the FIN, the first transfer aborts very
early instead, saving half of the bandwidth.
> You only read from the socket receive queue to null buffer, and in most
> cases a single recv() call will be enough to drain the queue.
Indeed, in *most* cases, and just as right now in most cases there is no
problem. As I said, that's the first reported issue in 10 years and hundreds
of billions of connections cumulated on various sites. But instead of really
fixing the issue, it just reduces its occurrences. Also, it does only work
for low bandwidth clients (most common case too). That's what I'm going to
implement anyway, but this is an unreliable workaround. All I know is that
it will probably divide by 10 the number of times this problem is encountered
but it will not fix it.
> > Since this method is the least efficient one and clearly not acceptable
> > for practical cases, I wanted to dig at the root, where the information
> > is known. And the TCP recv code is precisely the place where we know
> > exactly when it's safe to reset.
> >
>
> And its safe to reset exactly when application just does close(), if
> unread data was not drained. Not only its safe, but required. A new RFC
> might be needed ?
I'm not requesting a new RFC, but I'm just trying to make a correct use
of orphans as implemented in the Linux stack, and I'm realizing that
since RFC2525 was implemented, orphans cannot be relied on at all anymore.
We can simply delete all the orphans code and emit an RST immediately upon
close(), there is no safe use of them now. And that's my concern. In my
opinion, the code is there and was written precisely for that usage. Since
I'm seeing that it can't be used for what it's designed for, I'm naturally
interested in trying to get it usable again. And in fact, when I really
want an RST, I can already have one by disabling lingering before the
close(). This too shows that the default close() by default protects
orphaned data.
> > Also there's another issue in doing this. It requires polling of the
> > receive side for all requests, which adds one epoll_ctl() syscall and
> > one recv() call, which have a much noticeable negative performance
> > impact at high rates (at 100000 connections per second, every syscall
> > counts). For now I could very well consider that I do this only for
> > POST requests, which currently are the ones exhibiting the issue the
> > most, but since HTTP browsers will try to enable pipelining again
> > soon, the problem will generalize to all types of requests. Hence my
> > attempts to do it the optimal way.
>
> This might be overkill but is a portable way of doing this, on all
> versions of linux.
I'm not discussing the portability at all. You see, right now, Linux is
by some margin the fastest platform to run haproxy, and the one I always
recommend for that. Some people experience good performance on FreeBSD
too, but the fine-grained control we have on Linux helps maintaining a
high level of performance by avoiding many unnecessary steps when we
can trust the OS to do some things correctly. Having workarounds for
some versions that we know don't work as expected is not an issue, and
it's even a good reason to sometimes make people upgrade. But having to
cut performance in half under Linux on some workloads because the user
land can't know something obvious that the OS knows is a bit of a waste.
> Sure, you could patch kernel to add a new system call
>
> close_proper(fd);
That would just be the normal close() (the one with lingering enabled)
in theory.
> As shutdown() only uses two bits, you can eventually add another bit to
> flush receive queue as well (to avoid the copy of it)
This is a good idea, but it will still leave some incorrectly handled
cases where the other side has the time to send a few packets between
the shutdown() and the close().
> Another question, is : why the server closes the socket, if you believe
> more pipelining is coming soon ?
There are quite a bunch of situations in HTTP where you have no other
solution than closing. All responses that don't advertise a length must
terminated by a close. Haproxy is a reverse-proxy, so it sits between
the client and the server. When a server sends such responses, haproxy
must forward the close to the client, regardless of what's in the request
buffer. Also, some response codes require a close. The 400 bad request
for instance, implies a mandatory close (as well as many 4xx or 5xx).
All redirects (301/302/303/307) should lead to a close if the target is
another site.
Eventhough we optimize for the most common cases, that doesn't save us
from having to support the legacy cases.
Regards,
Willy
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Eric Dumazet @ 2010-09-26 21:01 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20100926184914.GC12373@1wt.eu>
Le dimanche 26 septembre 2010 à 20:49 +0200, Willy Tarreau a écrit :
> On Sun, Sep 26, 2010 at 08:35:15PM +0200, Eric Dumazet wrote:
> > I was referring to this code. It works well for me.
> >
> > shutdown(fd, SHUT_RDWR);
> > while (recv(fd, buff, sizeof(buff), 0) > 0)
> > ;
> > close(fd);
>
> Ah this one yes, but it's overkill. We're actively pumping data from the
> other side to drop it on the floor until it finally closes while we only
> need to know when it has ACKed the FIN. In practice, doing that on a POST
> request which causes a 302 or 401 will result in the whole amount of data
> being transferred twice. Not only this is bad for the bandwidth, this is
> also bad for the user, as we're causing him to experience a complete upload
> twice, just to be sure it has received the FIN, while it's pretty obvious
> that it's not necessary in 99.9% of the cases.
>
I dont understand how recv() could transfert data twice.
Once you issued shutdown(RDWR), socket rx buffer is freezed and no more
incoming data should be accepted/queued.
You only read from the socket receive queue to null buffer, and in most
cases a single recv() call will be enough to drain the queue.
> Since this method is the least efficient one and clearly not acceptable
> for practical cases, I wanted to dig at the root, where the information
> is known. And the TCP recv code is precisely the place where we know
> exactly when it's safe to reset.
>
And its safe to reset exactly when application just does close(), if
unread data was not drained. Not only its safe, but required. A new RFC
might be needed ?
> Also there's another issue in doing this. It requires polling of the
> receive side for all requests, which adds one epoll_ctl() syscall and
> one recv() call, which have a much noticeable negative performance
> impact at high rates (at 100000 connections per second, every syscall
> counts). For now I could very well consider that I do this only for
> POST requests, which currently are the ones exhibiting the issue the
> most, but since HTTP browsers will try to enable pipelining again
> soon, the problem will generalize to all types of requests. Hence my
> attempts to do it the optimal way.
This might be overkill but is a portable way of doing this, on all
versions of linux.
Sure, you could patch kernel to add a new system call
close_proper(fd);
As shutdown() only uses two bits, you can eventually add another bit to
flush receive queue as well (to avoid the copy of it)
Another question, is : why the server closes the socket, if you believe
more pipelining is coming soon ?
^ permalink raw reply
* 2.6.36-rc5-git7: Reported regressions 2.6.34 -> 2.6.35
From: Rafael J. Wysocki @ 2010-09-26 20:29 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.34 regressions introduced before
2.6.35, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.34 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-09-26 139 24 21
2010-09-20 137 27 25
2010-09-12 135 26 25
2010-08-30 124 38 34
2010-08-01 100 27 23
2010-07-23 94 33 25
2010-07-09 79 45 37
2010-06-21 46 37 26
2010-06-09 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18732
Subject : Radeon HD 4700 needs MSI disabled
Submitter : Rafael Gandolfi <kaillasse91-PkbjNfxxIARGWvitb5QawA@public.gmane.org>
Date : 2010-09-18 12:06 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18522
Subject : [REGRESSION] cdrom drive doesn't detect removal
Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-12 9:49 (15 days old)
First-Bad-Commit: http://git.kernel.org/linus/6b4517a7913a09d3259bb1d21c9cb300f12294bd
Message-ID : <1284284969.2928.18.camel@maxim-laptop>
References : http://marc.info/?l=linux-kernel&m=128428499013930&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18202
Subject : Microphone levels too low
Submitter : Alexander Hunziker <alex.hunziker-Mds7TqofYmjt3F02DXVmkw@public.gmane.org>
Date : 2010-09-09 22:20 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18032
Subject : No sound on headphone jack
Submitter : Alexander Hunziker <alex.hunziker-Mds7TqofYmjt3F02DXVmkw@public.gmane.org>
Date : 2010-09-07 21:45 (20 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17812
Subject : Kernel completely frozen when memory is full
Submitter : Mickey86 <mikael.cordon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-05 13:09 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17772
Subject : Unable to locate IOAPIC for GSI *
Submitter : zersaa <zersaa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-04 21:28 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17261
Subject : Freezes on bootup
Submitter : Dan Dart <dandart-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date : 2010-08-29 09:00 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16691
Subject : IPW5100: iwlagn broken with 2.6.34.x to 2.6.35.2 update
Submitter : Can Celasun <dcelasun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-21 08:28 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16633
Subject : ath5k + 2.6.35 x86 + hostapd - Failed to set channel
Submitter : NiTr0 <nitr0-z9XQkeP78BxUq1AO9QMCaQ@public.gmane.org>
Date : 2010-08-19 19:37 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16614
Subject : [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[<ffffffffa004fbc5>] [<ffffffffa004fbc5>] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Submitter : Sander Eikelenboom <linux-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
Date : 2010-08-10 22:12 (48 days old)
Message-ID : <61936849.20100811001257-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128152075830927&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16562
Subject : 2.6.35: cpu_idle bug report / on i7 870 cpu (x86_64)
Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date : 2010-08-06 22:09 (52 days old)
Message-ID : <alpine.DEB.2.00.1008061800530.5241-0qmrozcXWo8bm2hyYBkBBg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128113260904048&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16549
Subject : 2.6.35: suspicious rcu_dereference_check() usage
Submitter : Vladislav Bolkhovitin <vst-d+Crzxg7Rs0@public.gmane.org>
Date : 2010-08-04 10:56 (54 days old)
Message-ID : <4C594740.1090608-d+Crzxg7Rs0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128091938215177&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16525
Subject : unexpected high load since 2.6.35
Submitter : MadLoisae-hi6Y0CQ0nG0@public.gmane.org <MadLoisae-hi6Y0CQ0nG0@public.gmane.org>
Date : 2010-08-02 20:53 (56 days old)
Message-ID : <4C573041.1070103-hi6Y0CQ0nG0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128078243726655&w=2
http://lkml.org/lkml/2010/9/14/105
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16515
Subject : [bisected] Radeon rv280 can't boot on kernel 2.6.35.
Submitter : Albert Gall <ss3vdr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-04 16:10 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/https://bugzilla.kernel.org/attachment.cgi?id=27350
Handled-By : Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16488
Subject : [i915] Framebuffer ID error after suspend/hibernate leading to X crash
Submitter : Milan Bouchet-Valat <nalimilan-pqIVbhRXszc@public.gmane.org>
Date : 2010-08-01 08:55 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channel 13
Submitter : Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 17:06 (64 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <attila123456-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 09:33 (64 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2010-07-13 23:21 (76 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16322
Subject : WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()
Submitter : boris64 <bugzilla.kernel.org-ro/BP3KN3ujR7s880joybQ@public.gmane.org>
Date : 2010-07-01 13:54 (88 days old)
Handled-By : H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Date : 2010-06-09 18:36 (110 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <E1OMQ88-0002a1-Gb-UK71uKi2zisAobODsErMgNi2O/JbrIOy@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4
http://bugs.freedesktop.org/show_bug.cgi?id=29536
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-11 20:31 (108 days old)
Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16396
Subject : [bisected] resume from suspend freezes system
Submitter : tomas m <tmezzadra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-15 02:32 (74 days old)
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31422
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-28 9:40 (91 days old)
Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/00884.html
Handled-By : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=30282
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <brian.bloniarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-16 17:57 (103 days old)
Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Patch : https://patchwork.kernel.org/patch/189182/
https://patchwork.kernel.org/patch/189232/
https://patchwork.kernel.org/patch/189242/
https://patchwork.kernel.org/patch/189252/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.34 and 2.6.35, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16055
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 2.6.36-rc5-git7: Reported regressions from 2.6.35
From: Rafael J. Wysocki @ 2010-09-26 19:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.35,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.35, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19082
Subject : fs/fs-writeback.c to dump
Submitter : Pavel Vasilyev <pavel-wkUsHEiXLHUox3rIn2DAYQ@public.gmane.org>
Date : 2010-09-25 15:52 (2 days old)
Message-ID : <201009251952.58749.pavel-wkUsHEiXLHUox3rIn2DAYQ@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128543035026659&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19072
Subject : [2.6.36-rc regression] occasional complete system hangs on sparc64 SMP
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2010-09-23 17:02 (4 days old)
Message-ID : <19611.34846.813757.309183-tgku4HJDRZih8lFjZTKsyTAV6s6igYVG@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128526136531048&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19062
Subject : Dirtiable inode bdi default != sb bdi btrfs
Submitter : Cesar Eduardo Barros <cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org>
Date : 2010-09-23 0:54 (4 days old)
Message-ID : <4C9AA546.6050201-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128520328929595&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-22 23:47 (5 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19002
Subject : Radeon rv730 AGP/KMS/DRM kernel lockup
Submitter : Duncan <1i5t5.duncan-j9pdmedNgrk@public.gmane.org>
Date : 2010-09-23 16:48 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18992
Subject : warn_slow_path_common in iwlagn/mac80211 in 2.6.36-rc5
Submitter : rocko <rockorequin-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
Date : 2010-09-23 03:07 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18342
Subject : [regression] i915 incorrectly detects bogus LVDS connection instead of LVDS1
Submitter : Woody Suwalski <terraluna977-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-08 15:10 (19 days old)
Message-ID : <AANLkTim2mrVRCKg-2couMTFV7krHQp0+2e_cbaiT_KYW-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128395866331382&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17722
Subject : 2.6.36-rc3: WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed
Submitter : Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date : 2010-08-31 20:14 (27 days old)
Message-ID : <201008312214.52473.thomas-VsYtu1Qij5c@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128328580504227&w=2
http://www.spinics.net/lists/netdev/msg140769.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17361
Subject : Watchdog detected hard LOCKUP in jbd2_journal_get_write_access
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2010-08-29 19:59 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette-GANU6spQydw@public.gmane.org>
Date : 2010-08-26 17:24 (32 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-08-21 15:24 (37 days old)
Message-ID : <20100821152445.GA1536-+ZI9xUNit7I@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
Date : 2010-08-19 21:03 (39 days old)
Message-ID : <alpine.SOC.1.00.1008192359310.19654-ptEonEWSGqKptlylMvRsHA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date : 2010-08-18 6:18 (40 days old)
Message-ID : <1282112318.21202.8.camel-sz7BYL/Y5Hu/P+R7jlPCFVaTQe2KTcn/@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18962
Subject : screen failes in kde
Submitter : Hans de Bruin <jmdebruin-agH9qYG3oEhmR6Xm/wNWPw@public.gmane.org>
Date : 2010-09-22 15:42 (5 days old)
First-Bad-Commit: http://git.kernel.org/linus/e259befd9013e212648c3bd4f6f1fbf92d0dd51d
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31042
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18742
Subject : PROBLEM: Kernel panic on 2.6.36-rc4 when loading intel_ips on Core i3 laptop
Submitter : infernix <infernix-ZHiucA87ovfk1uMJSBkQmQ@public.gmane.org>
Date : 2010-09-15 14:35 (12 days old)
Message-ID : <4C90D998.6050103-ZHiucA87ovfk1uMJSBkQmQ@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128456187928496&w=2
Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31112
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.35,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 19:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <20100926174014.GA12373@1wt.eu>
On Sun, Sep 26, 2010 at 07:40:15PM +0200, Willy Tarreau wrote:
> 3) when an ACK comes from the other side, either it's below our last
> seq, and we simply ignore it, just as if we were in TIME_WAIT, or
> it is equal to the last seq and indicates that it's now safe to
> reset ; we would then just send the RST to notify the other side
> that the data it sent were not read. The connection can then either
> be destroyed or put in TIME_WAIT. It's the point where the connection
> normally switches from FIN_WAIT1 to FIN_WAIT2, since the FIN has been
> acked. The only difference is that we don't need a FIN_WAIT2 state
> for an orphan.
In fact, the following patch seems to provide the expected result :
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index f1813bc..ee5fa5d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1879,7 +1880,7 @@ void tcp_close(struct sock *sk, long timeout)
* advertise a zero window, then kill -9 the FTP client, wheee...
* Note: timeout is always zero in such a case.
*/
- if (data_was_unread) {
+ if (data_was_unread && !tcp_sk(sk)->packets_out) {
/* Unread data was tossed, zap the connection. */
NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
tcp_set_state(sk, TCP_CLOSE);
Here's what I get if I call it that way :
$ (echo "req1";usleep 200000;echo "req2") | nc6 10.8.3.4 8000
(excuse me for the long lines, I've disabled timestamps for better readability
but they're still long).
21:11:43.379465 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [S], seq 210901267, win 5840, options [mss 1460,sackOK,TS val 305301003 ecr 0,nop,wscale 7], length 0
21:11:43.379514 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [S.], seq 3131672819, ack 210901268, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
21:11:43.379866 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [.], ack 3131672820, win 46, length 0
21:11:43.379922 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [P.], ack 3131672820, win 46, length 5
21:11:43.379946 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [.], ack 210901273, win 92, length 0
21:11:43.581305 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [P.], ack 3131672820, win 46, length 5
21:11:43.581331 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [.], ack 210901278, win 92, length 0
21:11:44.380442 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [P.], ack 210901278, win 92, length 7
21:11:44.380506 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [FP.], seq 3131672827:3131672834, ack 210901278, win 92, length 7
21:11:44.380649 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [.], ack 3131672827, win 46, length 0
21:11:44.380672 IP 10.8.3.1.59244 > 10.8.3.4.8000: Flags [F.], seq 210901278, ack 3131672835, win 46, length 0
21:11:44.380685 IP 10.8.3.4.8000 > 10.8.3.1.59244: Flags [.], ack 210901279, win 92, length 0
Here we have correctly got a FIN+PUSH for the last data instead of the reset.
The other side ACKs and after the last ACK, the socket is correctly in
TIME_WAIT state.
If I try to push more data after the connection closes, I correctly get
a reset to be sent :
$ (echo "req1";usleep 1200000;echo "req2"; usleep 200000; echo "req3") | nc6 --half-close 10.8.3.4 8000
21:15:00.068376 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [S], seq 3284326660, win 5840, options [mss 1460,sackOK,TS val 305350241 ecr 0,nop,wscale 7], length 0
21:15:00.068428 IP 10.8.3.4.8000 > 10.8.3.1.60849: Flags [S.], seq 1933854189, ack 3284326661, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
21:15:00.068779 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [.], ack 1933854190, win 46, length 0
21:15:00.068830 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [P.], ack 1933854190, win 46, length 5
21:15:00.068854 IP 10.8.3.4.8000 > 10.8.3.1.60849: Flags [.], ack 3284326666, win 92, length 0
21:15:01.069238 IP 10.8.3.4.8000 > 10.8.3.1.60849: Flags [P.], ack 3284326666, win 92, length 7
21:15:01.069300 IP 10.8.3.4.8000 > 10.8.3.1.60849: Flags [FP.], seq 1933854197:1933854204, ack 3284326666, win 92, length 7
21:15:01.069448 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [.], ack 1933854197, win 46, length 0
21:15:01.109938 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [.], ack 1933854205, win 46, length 0
21:15:01.270509 IP 10.8.3.1.60849 > 10.8.3.4.8000: Flags [P.], ack 1933854205, win 46, length 5
21:15:01.270542 IP 10.8.3.4.8000 > 10.8.3.1.60849: Flags [R], seq 1933854205, win 0, length 0
I had already tested that previously but unfortunately the test was
combined with an attempt to zero the rx window, which had corrupted my
tests.
Would you have any problem with the proposed change above ?
Thanks,
Willy
^ permalink raw reply related
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 18:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1285526115.2530.12.camel@edumazet-laptop>
On Sun, Sep 26, 2010 at 08:35:15PM +0200, Eric Dumazet wrote:
> I was referring to this code. It works well for me.
>
> shutdown(fd, SHUT_RDWR);
> while (recv(fd, buff, sizeof(buff), 0) > 0)
> ;
> close(fd);
Ah this one yes, but it's overkill. We're actively pumping data from the
other side to drop it on the floor until it finally closes while we only
need to know when it has ACKed the FIN. In practice, doing that on a POST
request which causes a 302 or 401 will result in the whole amount of data
being transferred twice. Not only this is bad for the bandwidth, this is
also bad for the user, as we're causing him to experience a complete upload
twice, just to be sure it has received the FIN, while it's pretty obvious
that it's not necessary in 99.9% of the cases.
Since this method is the least efficient one and clearly not acceptable
for practical cases, I wanted to dig at the root, where the information
is known. And the TCP recv code is precisely the place where we know
exactly when it's safe to reset.
Also there's another issue in doing this. It requires polling of the
receive side for all requests, which adds one epoll_ctl() syscall and
one recv() call, which have a much noticeable negative performance
impact at high rates (at 100000 connections per second, every syscall
counts). For now I could very well consider that I do this only for
POST requests, which currently are the ones exhibiting the issue the
most, but since HTTP browsers will try to enable pipelining again
soon, the problem will generalize to all types of requests. Hence my
attempts to do it the optimal way.
Regards,
Willy
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Eric Dumazet @ 2010-09-26 18:35 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20100926174014.GA12373@1wt.eu>
Le dimanche 26 septembre 2010 à 19:40 +0200, Willy Tarreau a écrit :
> Hi Eric,
>
> On Sun, Sep 26, 2010 at 07:02:47PM +0200, Eric Dumazet wrote:
> > How could we delay the close() ? We must either send a FIN or RST.
>
> I don't mean to delay the close(), but I'm aware that my description
> was not very clear.
>
> Here's what I would find normal :
>
> 1) upon close(), we send a FIN, whether there are incoming pending
> data or not (after all, the only difference is only a timing
> issue, as the data in the rx buffer might very well come just
> after the FIN, as it almost always does, BTW). The connection
> then becomes FIN_WAIT1 just as now.
>
> 2) mark the socket as orphaned
>
> 3) when an ACK comes from the other side, either it's below our last
> seq, and we simply ignore it, just as if we were in TIME_WAIT, or
> it is equal to the last seq and indicates that it's now safe to
> reset ; we would then just send the RST to notify the other side
> that the data it sent were not read. The connection can then either
> be destroyed or put in TIME_WAIT. It's the point where the connection
> normally switches from FIN_WAIT1 to FIN_WAIT2, since the FIN has been
> acked. The only difference is that we don't need a FIN_WAIT2 state
> for an orphan.
>
> > I would say, fix the program, so that RST is avoided ?
>
> Not that easy, see below.
>
> > The program does :
> >
> > recv() // read the request
> > send() // queue the answer
> > close() // could work if world was perfect...
> >
> > Change it to
> >
> > recv()
> > send()
> > shutdown()
> > recv() // read & flush in excess data
>
> New data arrives now, close() below will cause an RST again.
>
> > close()
> >
> > This for sure will send FIN after all queued data is sent.
> > I am not sure the final rcv() is even needed, its Sunday after all ;)
>
> Currently the real code (ie: not the poc I posted) does :
>
> recv()
> send()
> shutdown()
> close()
>
> The extra CRLF almost always happens between the recv() and send(). What
> I intend to do as a workaround is exactly what you described above, but
> I'm well aware it's not enough. It will only reduce the rate at which this
> case happens. Well, in fact, in 10 years of production at many sites, it's
> the first time such an issue is reported and it could be tracked down to
> these two extra bytes. But the workaround will not prevent the two extra
> bytes from coming after the last recv().
>
> Also, the issue remains when processing large POST requests. Let's suppose
> the application is receiving a massive POST (eg: 10 MB) but the request is
> not authenticated, so the application returns an HTTP 401 response to
> require the client to authenticate. There's no way for the application to
> be notified that the small response was completely read by the client and
> that it's safe to close().
>
> For these reasons, I concluded that the application can't get everything
> right and needs help from the kernel (said differently, I think that the
> RFC2525 fix is causing harm in addition to goods). In my opinion, this
> section in the RFC was added based on a few observations of trivial cases
> but was but its impact was not completely explored.
>
> I'm willing to experiment, but I'm not much familiar with the code itself
> and sometimes I'm not sure about what I'm doing, probably that some help
> would be welcome. What I'd like to do is to implement the step 3 above,
> which is to only send the RST upon receipt of an ACK on an orphan that
> would switch a normal socket from FIN_WAIT1 to FIN_WAIT2.
>
> Also, I'm not sure about what other OSes are doing. For instance, I tried
> on Solaris and did not observe the issue at all, though I think that
> Solaris simply does not implement the RFC2525 recommendation.
>
> Have a nice sunday evening ;-)
> Willy
>
I was referring to this code. It works well for me.
shutdown(fd, SHUT_RDWR);
while (recv(fd, buff, sizeof(buff), 0) > 0)
;
close(fd);
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 17:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1285520567.2530.8.camel@edumazet-laptop>
Hi Eric,
On Sun, Sep 26, 2010 at 07:02:47PM +0200, Eric Dumazet wrote:
> How could we delay the close() ? We must either send a FIN or RST.
I don't mean to delay the close(), but I'm aware that my description
was not very clear.
Here's what I would find normal :
1) upon close(), we send a FIN, whether there are incoming pending
data or not (after all, the only difference is only a timing
issue, as the data in the rx buffer might very well come just
after the FIN, as it almost always does, BTW). The connection
then becomes FIN_WAIT1 just as now.
2) mark the socket as orphaned
3) when an ACK comes from the other side, either it's below our last
seq, and we simply ignore it, just as if we were in TIME_WAIT, or
it is equal to the last seq and indicates that it's now safe to
reset ; we would then just send the RST to notify the other side
that the data it sent were not read. The connection can then either
be destroyed or put in TIME_WAIT. It's the point where the connection
normally switches from FIN_WAIT1 to FIN_WAIT2, since the FIN has been
acked. The only difference is that we don't need a FIN_WAIT2 state
for an orphan.
> I would say, fix the program, so that RST is avoided ?
Not that easy, see below.
> The program does :
>
> recv() // read the request
> send() // queue the answer
> close() // could work if world was perfect...
>
> Change it to
>
> recv()
> send()
> shutdown()
> recv() // read & flush in excess data
New data arrives now, close() below will cause an RST again.
> close()
>
> This for sure will send FIN after all queued data is sent.
> I am not sure the final rcv() is even needed, its Sunday after all ;)
Currently the real code (ie: not the poc I posted) does :
recv()
send()
shutdown()
close()
The extra CRLF almost always happens between the recv() and send(). What
I intend to do as a workaround is exactly what you described above, but
I'm well aware it's not enough. It will only reduce the rate at which this
case happens. Well, in fact, in 10 years of production at many sites, it's
the first time such an issue is reported and it could be tracked down to
these two extra bytes. But the workaround will not prevent the two extra
bytes from coming after the last recv().
Also, the issue remains when processing large POST requests. Let's suppose
the application is receiving a massive POST (eg: 10 MB) but the request is
not authenticated, so the application returns an HTTP 401 response to
require the client to authenticate. There's no way for the application to
be notified that the small response was completely read by the client and
that it's safe to close().
For these reasons, I concluded that the application can't get everything
right and needs help from the kernel (said differently, I think that the
RFC2525 fix is causing harm in addition to goods). In my opinion, this
section in the RFC was added based on a few observations of trivial cases
but was but its impact was not completely explored.
I'm willing to experiment, but I'm not much familiar with the code itself
and sometimes I'm not sure about what I'm doing, probably that some help
would be welcome. What I'd like to do is to implement the step 3 above,
which is to only send the RST upon receipt of an ACK on an orphan that
would switch a normal socket from FIN_WAIT1 to FIN_WAIT2.
Also, I'm not sure about what other OSes are doing. For instance, I tried
on Solaris and did not observe the issue at all, though I think that
Solaris simply does not implement the RFC2525 recommendation.
Have a nice sunday evening ;-)
Willy
^ 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