open(O_ASYNC) sets futile flag

From: M.J. Pomraning (
Date: Wed Nov 14 2001 - 02:18:18 EST


sys_open() doesn't meaningfully respect the O_ASYNC flag -- the resulting
fd/filp has the flag set, but f_op->fasync() is not invoked. Worse yet,
fcntl()/ioctl() only call f_op->fasync() if FASYNC changes, so one must
presently undo and then redo the O_ASYNC before it works.

This contradicts fcntl(2)'s explicit remarks under the F_SETOWN section. (Man
page is excerpting glibc manual.) Behavior can be seen with ttys open()d
O_ASYNC or, as I noticed it, with a FIFO using Jeremy Elson's excellent
pipe-fasync patch on 2.4.14 (hope to see that in 2.5!). [1]

Two tempting corrections:
  A. open() implies FASYNCery
     (fasync() called if defined)
  B. open() unconditionally clears O_ASYNC
     (FASYNC must be manually F_SETFL'd/FIOASYNC'd)

Obviously A follows the man page and common sense. Jeremy was kind enough to
do some preliminary investigation of modifying sys_open() to accomplish this,
noting that f_op->release would have to be called if fasync failed [2] (and
that this might pose some subtle difficulties).

OTOH, B is simple and agreeable. Sockets and (even patched) unnamed pipes
don't have the luxury of an atomic O_ASYNC upon initialization AFAIK.
Further, the merit of fasync() alongside open() is debatable -- one still must
separately F_SETOWN before signals start rolling in.

Time to solicit more input. Are there serious implementation barriers to A?
Are there better alternatives to A and B that correct the obstinate O_ASYNC
flag upon open() problem?

Pls. CC me in any replies.



[1] Jeremy Elson: "[PATCH] SIGIO for FIFOs (fs/pipe.c, kernel 2.4.x)"

[2] open() could return the fd and unset O_ASYNC on f_op->fasync failure,
    but that's rather awkward -- little better than manual fcntl()ing.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Nov 15 2001 - 21:00:38 EST