[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090517.154137.104422195.davem@davemloft.net>
Date: Sun, 17 May 2009 15:41:37 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: ilpo.jarvinen@...sinki.fi
Cc: elendil@...net.nl, matthias.andree@....de, netdev@...r.kernel.org
Subject: Re: [PATCH v2] tcp: fix MSG_PEEK race check
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Mon, 11 May 2009 09:32:34 +0300 (EEST)
> [PATCH v2] tcp: fix MSG_PEEK race check
>
> Commit 518a09ef11 (tcp: Fix recvmsg MSG_PEEK influence of
> blocking behavior) lets the loop run longer than the race check
> did previously expect, so we need to be more careful with this
> check and consider the work we have been doing.
>
> I tried my best to deal with urg hole madness too which happens
> here:
> if (!sock_flag(sk, SOCK_URGINLINE)) {
> ++*seq;
> ...
> by using additional offset by one but I certainly have very
> little interest in testing that part.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
> Tested-by: Frans Pop <elendil@...net.nl>
Ok, now that I've looked at this, the urg_hole part of this change has
to be removed.
That case being accounted for with urg_hole is exactly what the
debugging message is trying to catch, where we are doing MSG_PEEK and
tcp_check_urg() advances ->copied_seq on us during one of those
"release_sock();/lock_sock();" sequences (which thus invoke TCP input
processing).
Could you please respin this patch with the URG bits removed?
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists