Bug 135942 - Possible problems with O_NONBLOCK
Possible problems with O_NONBLOCK
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
:
: 136075 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-10-15 16:26 EDT by Dave Malcolm
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-13 00:04:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Don't set O_NONBLOCK on regular files. (954 bytes, patch)
2004-10-17 16:47 EDT, David Woodhouse
no flags Details | Diff

  None (edit)
Description Dave Malcolm 2004-10-15 16:26:33 EDT
Description of problem:
I'm hearing reports that Evolution doesn't work very well with
kernel-2.6.8-1.624; the behaviour of O_NONBLOCK has apparently
changed, and this is showing up bugs in applications.

Here's a grep for O_NONBLOCK within the evolution-2.0.2 source;
appears to be confined to the camel code:
[dmalcolm@cassandra evolution-2.0.2]$ grep -R O_NONBLOCK *
camel/camel-tcp-stream-raw.c:           fcntl (fd, F_SETFL, flags |
O_NONBLOCK);
camel/camel-tcp-stream-raw.c:           data->value.non_blocking =
flags & O_NONBLOCK ? TRUE : FALSE;
camel/camel-tcp-stream-raw.c:           set = data->value.non_blocking
? O_NONBLOCK : 0;
camel/camel-tcp-stream-raw.c:           flags = (flags & ~O_NONBLOCK)
| set;
camel/camel-tcp-stream-ssl.c:           /* get O_NONBLOCK options */
camel/camel-tcp-stream-ssl.c:           /* restore O_NONBLOCK options */
camel/camel-tcp-stream-ssl.c:           /* get O_NONBLOCK options */
camel/camel-tcp-stream-ssl.c:           /* restore O_NONBLOCK options */
camel/ChangeLog:        O_NONBLOCK flag along with any previously set
flags.
camel/ChangeLog:        * camel-filter-search.c (run_command): Don't
set O_NONBLOCK on the
camel/ChangeLog:        O_NONBLOCK|prev_flags but we weren't, and so
the pipe got
camel/ChangeLog:        O_RDONLY|O_NONBLOCK even tho we wanted to
write to it).
camel/camel-tcp-stream-openssl.c:               fcntl
(openssl->priv->sockfd, F_SETFL, flags | O_NONBLOCK);
camel/camel-tcp-stream-openssl.c:               fcntl
(openssl->priv->sockfd, F_SETFL, flags | O_NONBLOCK);
camel/camel-tcp-stream-openssl.c:               fcntl (fd, F_SETFL,
flags | O_NONBLOCK);
camel/camel-tcp-stream-openssl.c:              
data->value.non_blocking = flags & O_NONBLOCK ? TRUE : FALSE;
camel/camel-tcp-stream-openssl.c:               set =
data->value.non_blocking ? O_NONBLOCK : 0;
camel/camel-tcp-stream-openssl.c:               flags = (flags &
~O_NONBLOCK) | set;
camel/camel-gpg-context.c:              fcntl (gpg->passwd_fd,
F_SETFL, flags | O_NONBLOCK);
camel/camel-gpg-context.c:      fcntl (gpg->stdin_fd, F_SETFL, flags |
O_NONBLOCK);
camel/camel-gpg-context.c:      fcntl (gpg->stdout_fd, F_SETFL, flags
| O_NONBLOCK);
camel/camel-gpg-context.c:      fcntl (gpg->stderr_fd, F_SETFL, flags
| O_NONBLOCK);
camel/camel-gpg-context.c:      fcntl (gpg->status_fd, F_SETFL, flags
| O_NONBLOCK);
camel/camel-file-utils.c:               fcntl (fd, F_SETFL, flags |
O_NONBLOCK);
camel/camel-file-utils.c:               fcntl (fd, F_SETFL, flags |
O_NONBLOCK);
camel/ChangeLog.pre-1-4:        connect right away, unset O_NONBLOCK
so it doesn't mess us up
Comment 1 Dave Malcolm 2004-10-15 16:28:18 EDT
FWIW, a similar grep of the evolution-data-server source comes back empty
Comment 2 David Woodhouse 2004-10-17 14:44:47 EDT
*** Bug 136075 has been marked as a duplicate of this bug. ***
Comment 3 David Woodhouse 2004-10-17 16:47:36 EDT
Created attachment 105355 [details]
Don't set O_NONBLOCK on regular files.

I'm not sure entirely how O_NONBLOCK on regular files is supposed to work. Evo
gets stuck in select(). It seems safest not to do it at all, rather than to try
to make it work as expected. That's certainly the portable option. This fixes
the case that actually bit me.
Comment 4 Dave Malcolm 2004-11-09 12:22:55 EST
(Adding to FC4 target tracker for now)
Comment 5 Dave Malcolm 2006-01-11 20:08:13 EST
Is this actually an issue anymore?  My understanding is that setting O_NONBLOCK
ought not to hurt when opening a regular file.
From man 2 open:
O_NONBLOCK or O_NDELAY
              When possible, the file is opened in non-blocking mode. Neither
the open() nor any subsequent operations on the file descriptor
              which is returned will cause the calling process to wait.  For the
handling of FIFOs (named pipes),  see  also  fifo(4).   This
              mode need not have any effect on files other than FIFOs.
Comment 6 David Woodhouse 2006-01-11 20:18:43 EST
I think the standard theoretically allows for the behaviour which rawhide
kernels once briefly exhibited. But there's just too much buggy software out
there, perhaps encouraged by the man pages you quoted. I think that strictly
speaking, it's still wrong -- but it's unlikely to become an issue because I
don't think there'll be another attempt to make the kernel do whatever it was
doing before for O_NONBLOCK files.
Comment 7 Dave Malcolm 2006-01-13 00:04:33 EST
Thanks for the clarification.  For now I'm going to close this as WONTFIX, so as
to avoid diverging from upstream and to keep bugzilla a bit cleaner.  Feel free
to reopen if need be.

Note You need to log in before you can comment on or make changes to this bug.