From: Stefan Nuernberger <snu@amazon.com>
To: stable@vger.kernel.org
Cc: Amit Shah <aams@amazon.com>, David Woodhouse <dwmw@amazon.com>,
Will Woods <wwoods@redhat.com>
Subject: [PATCH] fanotify: fix -EOVERFLOW with large files on 64-bit
Date: Thu, 16 Nov 2017 20:43:53 +0100 [thread overview]
Message-ID: <20171116194353.20100-1-snu@amazon.com> (raw)
From: Will Woods <wwoods@redhat.com>
commit 1e2ee49f7f1b79f0b14884fe6a602f0411b39552 upstream.
On 64-bit systems, O_LARGEFILE is automatically added to flags inside
the open() syscall (also openat(), blkdev_open(), etc). Userspace
therefore defines O_LARGEFILE to be 0 - you can use it, but it's a
no-op. Everything should be O_LARGEFILE by default.
But: when fanotify does create_fd() it uses dentry_open(), which skips
all that. And userspace can't set O_LARGEFILE in fanotify_init()
because it's defined to 0. So if fanotify gets an event regarding a
large file, the read() will just fail with -EOVERFLOW.
This patch adds O_LARGEFILE to fanotify_init()'s event_f_flags on 64-bit
systems, using the same test as open()/openat()/etc.
Addresses https://bugzilla.redhat.com/show_bug.cgi?id=696821
Signed-off-by: Will Woods <wwoods@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[snu: Backported to 3.2 / 3.10: adjusted context]
Signed-off-by: Stefan Nuernberger <snu@amazon.com>
Reviewed-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Simon Veith <sveith@amazon.de>
Cc: <stable@vger.kernel.org> # 3.2.x and 3.10.x
---
fs/notify/fanotify/fanotify_user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index d57995e1cfd7..dd3d9d13a4c4 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -712,6 +712,9 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
group->fanotify_data.user = user;
atomic_inc(&user->fanotify_listeners);
+ if (force_o_largefile())
+ event_f_flags |= O_LARGEFILE;
+
group->fanotify_data.f_flags = event_f_flags;
#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
mutex_init(&group->fanotify_data.access_mutex);
--
2.15.0
next reply other threads:[~2017-11-16 19:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 19:43 Stefan Nuernberger [this message]
2017-11-16 20:28 ` [PATCH] fanotify: fix -EOVERFLOW with large files on 64-bit Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171116194353.20100-1-snu@amazon.com \
--to=snu@amazon.com \
--cc=aams@amazon.com \
--cc=dwmw@amazon.com \
--cc=stable@vger.kernel.org \
--cc=wwoods@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.