Bug 135942

Summary: Possible problems with O_NONBLOCK
Product: [Fedora] Fedora Reporter: Dave Malcolm <dmalcolm>
Component: evolutionAssignee: Dave Malcolm <dmalcolm>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dwmw2, jeff, marius.andreiana, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-13 05:04:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150221    
Attachments:
Description Flags
Don't set O_NONBLOCK on regular files. none

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.