[PATCH v2] memcg, fsnotify: no oom-kill for remote memcg charging

[PATCH v2] memcg, fsnotify: no oom-kill for remote memcg charging

[Shakeel Butt]

The commit d46eb14b735b ("fs: fsnotify: account fsnotify metadata to
kmemcg") added remote memcg charging for fanotify and inotify event
objects. The aim was to charge the memory to the listener who is
interested in the events but without triggering the OOM killer.
Otherwise there would be security concerns for the listener. At the
time, oom-kill trigger was not in the charging path. A parallel work
added the oom-kill back to charging path i.e. commit 29ef680ae7c2
("memcg, oom: move out_of_memory back to the charge path"). So to not
trigger oom-killer in the remote memcg, explicitly add
__GFP_RETRY_MAYFAIL to the fanotigy and inotify event allocations.

Signed-off-by: Shakeel Butt <shakeelb@google.com>
---
Changelog since v1:
- Fixed usage of __GFP_RETRY_MAYFAIL flag.

 fs/notify/fanotify/fanotify.c        | 5 ++++-
 fs/notify/inotify/inotify_fsnotify.c | 7 +++++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 6b9c27548997..f78fd4c8f12d 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -288,10 +288,13 @@ struct fanotify_event *fanotify_alloc_event(struct fsnotify_group *group,
 	/*
 	 * For queues with unlimited length lost events are not expected and
 	 * can possibly have security implications. Avoid losing events when
-	 * memory is short.
+	 * memory is short. Also make sure to not trigger OOM killer in the
+	 * target memcg for the limited size queues.
 	 */
 	if (group->max_events == UINT_MAX)
 		gfp |= __GFP_NOFAIL;
+	else
+		gfp |= __GFP_RETRY_MAYFAIL;
 
 	/* Whoever is interested in the event, pays for the allocation. */
 	memalloc_use_memcg(group->memcg);
diff --git a/fs/notify/inotify/inotify_fsnotify.c b/fs/notify/inotify/inotify_fsnotify.c
index ff30abd6a49b..17c08daa1ba7 100644
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@ -99,9 +99,12 @@ int inotify_handle_event(struct fsnotify_group *group,
 	i_mark = container_of(inode_mark, struct inotify_inode_mark,
 			      fsn_mark);
 
-	/* Whoever is interested in the event, pays for the allocation. */
+	/*
+	 * Whoever is interested in the event, pays for the allocation. However
+	 * do not trigger the OOM killer in the target memcg.
+	 */
 	memalloc_use_memcg(group->memcg);
-	event = kmalloc(alloc_len, GFP_KERNEL_ACCOUNT);
+	event = kmalloc(alloc_len, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL);
 	memalloc_unuse_memcg();
 
 	if (unlikely(!event)) {
-- 
2.21.0.1020.gf2820cf01a-goog

Re: [PATCH v2] memcg, fsnotify: no oom-kill for remote memcg charging

[Roman Gushchin]

On Sat, May 04, 2019 at 07:52:42AM -0700, Shakeel Butt wrote:
> The commit d46eb14b735b ("fs: fsnotify: account fsnotify metadata to
> kmemcg") added remote memcg charging for fanotify and inotify event
> objects. The aim was to charge the memory to the listener who is
> interested in the events but without triggering the OOM killer.
> Otherwise there would be security concerns for the listener. At the
> time, oom-kill trigger was not in the charging path. A parallel work
> added the oom-kill back to charging path i.e. commit 29ef680ae7c2
> ("memcg, oom: move out_of_memory back to the charge path"). So to not
> trigger oom-killer in the remote memcg, explicitly add
> __GFP_RETRY_MAYFAIL to the fanotigy and inotify event allocations.
> 
> Signed-off-by: Shakeel Butt <shakeelb@google.com>
> ---
> Changelog since v1:
> - Fixed usage of __GFP_RETRY_MAYFAIL flag.
> 
>  fs/notify/fanotify/fanotify.c        | 5 ++++-
>  fs/notify/inotify/inotify_fsnotify.c | 7 +++++--
>  2 files changed, 9 insertions(+), 3 deletions(-)

Hi Shakeel,

the patch looks good to me!

Reviewed-by: Roman Gushchin <guro@fb.com>

Thanks!