(
Jump to the original submission)
Fri 12 Jun 2009 06:18:38 PM UTC, comment #6:
The last messages I saw on the subject (unfortunately can't find them) suggested this may have been a kernel bug which has since been fixed. Closing until I hear otherwise.
|
Sun 24 May 2009 09:56:13 PM UTC, comment #5:
Linux-2.6.30-rc7 changes condition when the warning is emitted:
Ilpo Järvinen (1):
tcp: fix MSG_PEEK race check
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=775273131810caa41dfc7f9e552ea5d8508caf40)
Maybe it will solve this problem.
FYI, I still get discussed message occasionally on 2.6.29-gentoo-r4 (almost 2.6.29.4).
|
Wed 06 May 2009 01:48:26 AM UTC, comment #4:
this happens to me while running jigdo-light
from dmesg:
[ 5255.160842] TCP(wget:11285): Application bug, race in MSG_PEEK.
[ 5621.207702] TCP(wget:11746): Application bug, race in MSG_PEEK.
[ 5673.838217] TCP(wget:11746): Application bug, race in MSG_PEEK.
[ 5780.043410] TCP(wget:12055): Application bug, race in MSG_PEEK.
[ 5912.309538] TCP(wget:12055): Application bug, race in MSG_PEEK.
uname -a
Linux AVA-333782 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
wget --version
GNU Wget 1.11.4
http://savannah.gnu.org/bugs/?25418#postcomment
|
Wed 28 Jan 2009 08:41:46 AM UTC, comment #3:
You are right. Doing strace on simple wget transfer I can see bunch of recv(,MSG_PEEK) followed by recv(,0) reading the same data twice. I think it's only matter of reading HTTP header and FTP control connection.
Basic fix is synchronizing threads around recv() not to read packet at the same time. However I can't see any thread switching in wget. So maybe it's a bogus warning.
|
Wed 28 Jan 2009 06:40:36 AM UTC, comment #2:
Well that's... weird. We're not using OOB data.
We do use MSG_PEEK, but I wonder whether we couldn't just work around that or something...
|
Tue 27 Jan 2009 09:25:54 AM UTC, comment #1:
This message comes from net/ipv4/tcp.c:
if ((flags & MSG_PEEK) && peek_seq != tp->copied_seq) {
if (net_ratelimit())
printk(KERN_DEBUG "TCP(%s:%d): Application bug, race in MSG_PEEK.\n",
current->comm, task_pid_nr(current));
peek_seq = tp->copied_seq;
}
Digging through Linux GIT log (http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=MSG_PEEK) did not help.
I guess the linux code tests race between recv()ing OOB packet and recv()ing standard packet.
There is explanation at <http://lkml.indiana.edu/hypermail/linux/kernel/0309.2/1347.html>.
|
Tue 27 Jan 2009 05:29:41 AM UTC, original submission:
Reported at http://article.gmane.org/gmane.comp.web.wget.general/8547
I have a sinking feeling this could be a pain to reproduce :\
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 4 latest changes.