Bug 5731
Summary: | Zero-length write() does not generate a datagram on connected socket | ||
---|---|---|---|
Product: | Networking | Reporter: | Michael Kerrisk (michael.kerrisk) |
Component: | Other | Assignee: | Stephen Hemminger (stephen) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.14 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
Sender
receiver |
Description
Michael Kerrisk
2005-12-12 06:08:42 UTC
You marked this bug as RESOLVED, but I still see the same problem in kernel 2.6.17. What was the fix, and what kernel version was it made in? This bug is still present in 2.6.19-rc5. My concern is that we would break applications that depend on existing behaviour. Is there something in Single Unix Standard or Posix about this? Created attachment 12827 [details]
Sender
Created attachment 12828 [details]
receiver
This appears to work fine with 2.6.23-rc6 $ ./rcv0 0.0.0.0 & [1] 20322 $ ./snd0 127.0.0.1 0 0 from 127.0.0.1,32816 Stephen, your test programs do not test the case that I am reporting! The problem occurs with write(2) -- your program uses send(2). Please try the test program I supplied -- it demonstrates the problem, which still exists in 2.6.23-rc7. SuSv3 says Before any action described below is taken, and if nbyte is zero and the file is a regular file, the write() function may detect and return errors as described below. In the absence of errors, or if error detection is not performed, the write() function shall return zero and have no other results. If nbyte is zero and the file is not a regular file, the results are unspecified. Thus a standards compliant application should use send(), which doesn't make our behaviour neccessarily the right thing to do for non-regular files. OTOH changing it would expose a lot of device driver code to a new and previously "can't happen" case and that might have fallout. But in this case that comment doesn't apply since the file in question is a socket not a regular file. Changing it doesn't expose device drivers to changes only protocols. The protocols already get the same thing when send() is used, and the mapping from write() to sendmsg happens in socket.c before the protocols see it. This is really a splitting hairs thing. Alan, I'm not sure these SUSv3 quote are really relevant. One has always been able to use write on sockets, on all systems I've known of. But Linux behavior differs from every other system I know of (as noted in the initial report). The question is, do we want to make Linux the same for the sake of portability? To be weighed against, what are the risks of breaking existing userland apps on Linux? Davem fixed this for 2.6.23 |