Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 135942 - Possible problems with O_NONBLOCK
Summary: Possible problems with O_NONBLOCK
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Malcolm
QA Contact:
URL:
Whiteboard:
: 136075 (view as bug list)
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
 
Reported: 2004-10-15 20:26 UTC by Dave Malcolm
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-13 05:04:33 UTC


Attachments (Terms of Use)
Don't set O_NONBLOCK on regular files. (deleted)
2004-10-17 20:47 UTC, David Woodhouse
no flags Details | Diff

Description Dave Malcolm 2004-10-15 20:26:33 UTC
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 20:28:18 UTC
FWIW, a similar grep of the evolution-data-server source comes back empty

Comment 2 David Woodhouse 2004-10-17 18:44:47 UTC
*** Bug 136075 has been marked as a duplicate of this bug. ***

Comment 3 David Woodhouse 2004-10-17 20:47:36 UTC
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 17:22:55 UTC
(Adding to FC4 target tracker for now)

Comment 5 Dave Malcolm 2006-01-12 01:08:13 UTC
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-12 01:18:43 UTC
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 05:04:33 UTC
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.