* Reported regression against commit a05d2ad
@ 2011-06-21 20:15 Herton Ronaldo Krzesinski
2011-06-21 20:38 ` Tim Gardner
2011-06-21 20:49 ` Eric W. Biederman
0 siblings, 2 replies; 6+ messages in thread
From: Herton Ronaldo Krzesinski @ 2011-06-21 20:15 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: lamont, sconklin, tim.gardner, netdev
Hi,
after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
got a regression report about timeout in tcp connections
(https://launchpad.net/bugs/791512).
We tried help reporter with a bisect process, but it was taking some
time, so we reverted some suspect commits, until we isolated it to
commit "af_unix: Only allow recv on connected seqpacket sockets."
With only commit a05d2ad reverted, testing results so far indicate the
issue doesn't happen.
I'm unfamiliar with unix sockets code, so can't see at first why this
commit in particular is causing problems, for now I can only say may be
something at application level using unix sockets regressed with it (?).
I'm just reporting it right now, and we plan to revert it for that kernel
until more info is found about it.
I'm adding reporter to CC (Lamont), in case more details are necessary
etc.
--
[]'s
Herton
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reported regression against commit a05d2ad
2011-06-21 20:15 Reported regression against commit a05d2ad Herton Ronaldo Krzesinski
@ 2011-06-21 20:38 ` Tim Gardner
2011-06-21 20:54 ` Eric W. Biederman
2011-06-21 20:49 ` Eric W. Biederman
1 sibling, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2011-06-21 20:38 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: Eric W. Biederman, lamont, sconklin, netdev
On 06/21/2011 02:15 PM, Herton Ronaldo Krzesinski wrote:
> Hi,
>
> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
> got a regression report about timeout in tcp connections
> (https://launchpad.net/bugs/791512).
>
> We tried help reporter with a bisect process, but it was taking some
> time, so we reverted some suspect commits, until we isolated it to
> commit "af_unix: Only allow recv on connected seqpacket sockets."
>
> With only commit a05d2ad reverted, testing results so far indicate the
> issue doesn't happen.
>
> I'm unfamiliar with unix sockets code, so can't see at first why this
> commit in particular is causing problems, for now I can only say may be
> something at application level using unix sockets regressed with it (?).
> I'm just reporting it right now, and we plan to revert it for that kernel
> until more info is found about it.
>
> I'm adding reporter to CC (Lamont), in case more details are necessary
> etc.
>
I believe we're also homing in on the same regression in 2.6.38.6
('af_unix: Only allow recv on connected seqpacket sockets.'). The
functional part of the patch is:
+
+ if (sk->sk_state != TCP_ESTABLISHED)
+ return -ENOTCONN;
+
+ return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
What happens with out of order receives? Would fragmentation have an impact?
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reported regression against commit a05d2ad
2011-06-21 20:15 Reported regression against commit a05d2ad Herton Ronaldo Krzesinski
2011-06-21 20:38 ` Tim Gardner
@ 2011-06-21 20:49 ` Eric W. Biederman
2011-06-22 17:32 ` Tim Gardner
1 sibling, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2011-06-21 20:49 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: lamont, sconklin, tim.gardner, netdev
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> writes:
> Hi,
>
> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
> got a regression report about timeout in tcp connections
> (https://launchpad.net/bugs/791512).
>
> We tried help reporter with a bisect process, but it was taking some
> time, so we reverted some suspect commits, until we isolated it to
> commit "af_unix: Only allow recv on connected seqpacket sockets."
>
> With only commit a05d2ad reverted, testing results so far indicate the
> issue doesn't happen.
>
> I'm unfamiliar with unix sockets code, so can't see at first why this
> commit in particular is causing problems, for now I can only say may be
> something at application level using unix sockets regressed with it (?).
> I'm just reporting it right now, and we plan to revert it for that kernel
> until more info is found about it.
The only thing commit a05d2ad will prevent is a non-sense use of a
af_unix socket, and on recent enough kernels a NULL pointer deference.
I respectfully suggest that the bug is elsewhere perhaps a broken user
space application out there that needs to be fixed, or you have a kernel
memory stomp that removing patch a05d2ad happens to shift the memory
layout to be harmful in a different way.
af_unix sockets have nothing to do with tcp and only happen to use
the TCP_ESTABLISHED flag to indicated connected or non-connected
sockets.
Eric
> I'm adding reporter to CC (Lamont), in case more details are necessary
> etc.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reported regression against commit a05d2ad
2011-06-21 20:38 ` Tim Gardner
@ 2011-06-21 20:54 ` Eric W. Biederman
0 siblings, 0 replies; 6+ messages in thread
From: Eric W. Biederman @ 2011-06-21 20:54 UTC (permalink / raw)
To: tim.gardner; +Cc: Herton Ronaldo Krzesinski, lamont, sconklin, netdev
Tim Gardner <tim.gardner@canonical.com> writes:
> On 06/21/2011 02:15 PM, Herton Ronaldo Krzesinski wrote:
>> Hi,
>>
>> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
>> got a regression report about timeout in tcp connections
>> (https://launchpad.net/bugs/791512).
>>
>> We tried help reporter with a bisect process, but it was taking some
>> time, so we reverted some suspect commits, until we isolated it to
>> commit "af_unix: Only allow recv on connected seqpacket sockets."
>>
>> With only commit a05d2ad reverted, testing results so far indicate the
>> issue doesn't happen.
>>
>> I'm unfamiliar with unix sockets code, so can't see at first why this
>> commit in particular is causing problems, for now I can only say may be
>> something at application level using unix sockets regressed with it (?).
>> I'm just reporting it right now, and we plan to revert it for that kernel
>> until more info is found about it.
>>
>> I'm adding reporter to CC (Lamont), in case more details are necessary
>> etc.
>>
>
> I believe we're also homing in on the same regression in 2.6.38.6 ('af_unix:
> Only allow recv on connected seqpacket sockets.'). The functional part of the
> patch is:
>
> +
> + if (sk->sk_state != TCP_ESTABLISHED)
> + return -ENOTCONN;
> +
> + return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
>
> What happens with out of order receives? Would fragmentation have an
> impact?
That code path has absolutely nothing to do with packets that come in
over the wire. Zilch, zero, nada. Fragments don't matter because
fragments can not possibly hit that code path. IP packets can not
possibly hit that code path.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reported regression against commit a05d2ad
2011-06-21 20:49 ` Eric W. Biederman
@ 2011-06-22 17:32 ` Tim Gardner
2011-06-22 18:00 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2011-06-22 17:32 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Herton Ronaldo Krzesinski, lamont, sconklin, netdev
On 06/21/2011 02:49 PM, Eric W. Biederman wrote:
<snip>
> I respectfully suggest that the bug is elsewhere perhaps a broken user
> space application out there that needs to be fixed, or you have a kernel
> memory stomp that removing patch a05d2ad happens to shift the memory
> layout to be harmful in a different way.
>
OK, I'm remembering how PF_UNIX Unix domain sockets are used, so I think
your theory about a misbehaving user space application is more likely.
However, I am a bit confused about how an application can attempt to
receive before the socket is fully opened. Some kind of race condition
with socketpair() ?
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reported regression against commit a05d2ad
2011-06-22 17:32 ` Tim Gardner
@ 2011-06-22 18:00 ` Eric W. Biederman
0 siblings, 0 replies; 6+ messages in thread
From: Eric W. Biederman @ 2011-06-22 18:00 UTC (permalink / raw)
To: tim.gardner; +Cc: Herton Ronaldo Krzesinski, lamont, sconklin, netdev
Tim Gardner <tim.gardner@canonical.com> writes:
> On 06/21/2011 02:49 PM, Eric W. Biederman wrote:
> <snip>
>> I respectfully suggest that the bug is elsewhere perhaps a broken user
>> space application out there that needs to be fixed, or you have a kernel
>> memory stomp that removing patch a05d2ad happens to shift the memory
>> layout to be harmful in a different way.
>>
>
> OK, I'm remembering how PF_UNIX Unix domain sockets are used, so I think your
> theory about a misbehaving user space application is more likely. However, I am
> a bit confused about how an application can attempt to receive before the socket
> is fully opened. Some kind of race condition with socketpair() ?
The case that is relevant is a listening SOCK_SEQPACKET socket.
The case that is affected is when you call receive on a listening
socket.
It isn't that the socket isn't fully opened. It is that accept is the
only legitimate operation at that point.
It took a mistake while someone was developing an application for this
kernel bug to be found.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-06-22 18:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-21 20:15 Reported regression against commit a05d2ad Herton Ronaldo Krzesinski
2011-06-21 20:38 ` Tim Gardner
2011-06-21 20:54 ` Eric W. Biederman
2011-06-21 20:49 ` Eric W. Biederman
2011-06-22 17:32 ` Tim Gardner
2011-06-22 18:00 ` Eric W. Biederman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).