https://bugs.winehq.org/show_bug.cgi?id=35781
Bug ID: 35781 Summary: kernel32/pipe test fails Product: Wine Version: 1.7.14 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: austinenglish@gmail.com
Created attachment 47776 --> https://bugs.winehq.org/attachment.cgi?id=47776 WINEDEBUG=relay,seh,tid,process,sync
Looking at test.winehq.org, this fails on every linux/wine platform:
pipe.c:1853: Test failed: WaitForSingleObject returned 102 pipe.c:1855: Test failed: completion routine not called
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #1 from Austin English austinenglish@gmail.com --- I noticed that wine-1.4 does not have this issue. Running a bisect, I found that 982153605a0835993b3b6b10d826377fbe4e2b9a was the first commit, but that commit was when the test was added, so it's not actually a regression, but never worked in the first place (on my machine, at least) :(
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Austin English from comment #0)
pipe.c:1853: Test failed: WaitForSingleObject returned 102 pipe.c:1855: Test failed: completion routine not called
These particular test failures were always present here, and I was thinking that it's some kind of a misconfiguration on my end. Apparently I'm not alone.
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- Is there any chance this has a kernel dependency? It succeeds for me on a box with a 3.10 kernel, but fails on a different one with a 3.12 kernel, although that's hardly the only difference between those two setups. And e.g. http://test.winehq.org/data/ecd24b5a874ead368c8f6e9d6981bb0e02472f9d/linux_Y... is on a 3.2 kernel.
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Henri Verbeet from comment #3)
Is there any chance this has a kernel dependency? It succeeds for me on a box with a 3.10 kernel, but fails on a different one with a 3.12 kernel, although that's hardly the only difference between those two setups. And e.g. http://test.winehq.org/data/ecd24b5a874ead368c8f6e9d6981bb0e02472f9d/ linux_Yuanchen/kernel32:pipe.html is on a 3.2 kernel.
Good point, pipe.ok fails for me with 3.13.6, but succeeds with 3.10.33. This is a 64-bit system, with 32-bit wine build.
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #5 from Austin English austinenglish@gmail.com --- This machine is 3.12.9-201.fc19.x86_64, wine32.
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #6 from Austin English austinenglish@gmail.com --- Also fails on Linux aw25 3.12.0-gentoo-1 #1 SMP Mon Nov 4 19:37:36 Local time zone must be set--see zic m x86_64 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux , wine32
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #7 from Austin English austinenglish@gmail.com --- I've got a debian VM that works with 3.2 and fails with 3.12 (from upstream git).
I'm running a bisect on it now, but it'll be a bit..
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #8 from Austin English austinenglish@gmail.com --- Created attachment 48042 --> https://bugs.winehq.org/attachment.cgi?id=48042 kernel commit
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #9 from Austin English austinenglish@gmail.com --- Created attachment 48043 --> https://bugs.winehq.org/attachment.cgi?id=48043 bisect log
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #10 from Austin English austinenglish@gmail.com --- Bisecting the kernel, I found it was introduced by: root@debian:/mnt/spare_hdd/linux# git bisect good ^[[21;3~eea86af6b1e18d6fa8dc959e3ddc0100f27aff9f is the first bad commit commit eea86af6b1e18d6fa8dc959e3ddc0100f27aff9f Author: Daniel Borkmann dborkman@redhat.com Date: Wed Jun 19 12:51:20 2013 +0200
net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF
The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff)) while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for sk_{r,w}mem_alloc accounting, we should have both sizes adjusted via defining a TCP_SKB_MIN_TRUESIZE.
Further, as Eric Dumazet points out, the minimal skb truesize in transmit path is SKB_TRUESIZE(2048) after commit f07d960df33c5 ("tcp: avoid frag allocation for small frames"), and tcp_sendmsg() tries to limit skb size to half the congestion window, meaning we try to build two skbs at minimum. Thus, having SOCK_MIN_SNDBUF as 2048 can hit a small regression for some applications setting to low SO_SNDBUF / SO_RCVBUF. Note that we define a TCP_SKB_MIN_TRUESIZE, because SKB_TRUESIZE(2048) adds SKB_DATA_ALIGN(sizeof(struct skb_shared_info)), but in case of TCP skbs, the skb_shared_info is part of the 2048 bytes allocation for skb->head.
The minor adaption in sk_stream_moderate_sndbuf() is to silence a warning by using a typed max macro, as similarly done in SOCK_MIN_RCVBUF occurences, that would appear otherwise.
https://bugs.winehq.org/show_bug.cgi?id=35781
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.kernel.org | |/show_bug.cgi?id=73811
--- Comment #11 from Austin English austinenglish@gmail.com --- Kernel bug is at https://bugzilla.kernel.org/show_bug.cgi?id=73811
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #12 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #11)
Kernel bug is at https://bugzilla.kernel.org/show_bug.cgi?id=73811
From upstream:
=== Hm, I really don't see through this whole Windows style source code. :(
Is it possible that you could demonstrate the problem in a very simple and as minimal as possible stand-alone C program? That would be great.
This change only affects memory accounting, and says that the minimum sizes for that are SOCK_MIN_SNDBUF resp. SOCK_MIN_RCVBUF, so it simply clamps the limits slightly.
Perhaps you do a setsockopt() somewhere in wine code and account for memory additionally in user space? So that your assumptions about the actual available memory in kernel space are not correct anymore?
Thanks,
Daniel ===
if someone has/can make a testcase, I'll forward it upstream.
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #13 from Austin English austinenglish@gmail.com ---
From upstream:
====== I have no idea why you think its a kernel bug.
Kernel is free to enforce a minimum SO_SNDBUF value, without any notice.
SO_SNDBUF is advisory only.
We want being able to switch kernel allocator for skbs to whatever granularity we want in the future.
A conformant application would autodiscover what is the _current_ minimum value if it really cares. ======
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #14 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #13)
From upstream:
I have no idea why you think its a kernel bug.
Kernel is free to enforce a minimum SO_SNDBUF value, without any notice.
SO_SNDBUF is advisory only.
We want being able to switch kernel allocator for skbs to whatever granularity we want in the future.
A conformant application would autodiscover what is the _current_ minimum value if it really cares. ======
======= +1, agreed to all the above.
strace helps, e.g. setting buffer space to 256 etc, will for sure be clamped to the new minimum. =======
https://bugs.winehq.org/show_bug.cgi?id=35781
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com --- This is the only place I see that uses SO_RCVBUF / SO_SNDBUF related to pipes: http://source.winehq.org/source/server/named_pipe.c#L837
Reminds me of a test case in BSD where the test for setting these values always fail as seen in: http://test.winehq.org/data/7e874aed75765f3c017673178cfd64301b7ba3ed/bsd_fg-... (last test)
Would fixing bug 17195 solve this?
https://bugs.winehq.org/show_bug.cgi?id=35781
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=35781
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5a6cda458d07435ba7dbe3434df | |6bff0804b0982 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #16 from Austin English austinenglish@gmail.com --- http://source.winehq.org/git/wine.git/commitdiff/5a6cda458d07435ba7dbe3434df...
appears to have helped here, and looking at https://test.winehq.org/data, today is clean on all machines: http://test.winehq.org/data/fa685fc353adf73d8783d8d29a72a78486fd64d2/index_L...
whereas yesterday, every single one failed: http://test.winehq.org/data/31d51d4865d0f361ea739ee097902444e604d035/index_L...
Thanks Alexandre!
https://bugs.winehq.org/show_bug.cgi?id=35781
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.38.
-
wine-bugs＠winehq.org