-EINVAL if no fasync op for file
Subsystems (2)
PATCH 1/1 -EINVAL if no fasync op for file
This patch proposes an additional error checking performed within setfl().
As a result, fcntl (fd, F_SETFL, O_ASYNC) will return -1 and set errno to -EINVAL if filp->f_op->fasync is NULL for file specified by fd. This is possible, for example, if fd is a descriptor returned by inotify_init().
Dmitry
fs/fcntl.c +3 -0
@@ -240,6 +240,9 @@ error = filp->f_op->fasync (fd, filp, (arg &FASYNC ) !=0 );if (error <0 ) goto out; + }else { + error = -EINVAL ; + goto out; } }
Quoted 17 lines · On Thu, 18 Oct 2007 13:35:51 +0400 Dmitry Antipov <[email protected]> wrote:
This patch proposes an additional error checking performed within
setfl().As a result, fcntl (fd,
F_SETFL,O_ASYNC) will return -1 and set errno to-EINVALiffilp->f_op->fasyncis NULL for file specified by fd. This is possible, for example, if fd is a descriptor returned byinotify_init().Dmitry
[2.6.23-fcntl-fasync-check.patch text/x-patch (353B)]Signed-off-by Dmitry Antipov <[email protected]>
fs/fcntl.c line 247
Quoted 8 lines
fs/fcntl.c +3
-0@@ -240,6 +240,9 @@ error = filp->f_op->fasync (fd, filp, (arg &FASYNC ) !=0 );if (error <0 ) goto out; + }else { + error = -EINVAL ; + goto out; } }
This would have made sense whent he code was originally written but it now has a (small) potential to break existing applications.
I guess if the _only_ fd's which don't implement fasync are inotify, signalfd and other such new-and-obscure things then the risk is probably acceptably low.
But is the proposed change actually very useful?