The patch titled
Subject: memcg, fsnotify: no oom-kill for remote memcg charging
has been added to the -mm tree. Its filename is
memcg-fsnotify-no-oom-kill-for-remote-memcg-charging.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/memcg-fsnotify-no-oom-kill-for-remote-memcg-charging.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/memcg-fsnotify-no-oom-kill-for-remote-memcg-charging.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Shakeel Butt <shakeelb@xxxxxxxxxx>
Subject: memcg, fsnotify: no oom-kill for remote memcg charging
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.
Link: http://lkml.kernel.org/r/20190514212259.156585-2-shakeelb@xxxxxxxxxx
Signed-off-by: Shakeel Butt <shakeelb@xxxxxxxxxx>
Reviewed-by: Roman Gushchin <guro@xxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Vladimir Davydov <vdavydov.dev@xxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Jan Kara <jack@xxxxxxx>
Cc: Amir Goldstein <amir73il@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/notify/fanotify/fanotify.c | 5 ++++-
fs/notify/inotify/inotify_fsnotify.c | 8 ++++++--
2 files changed, 10 insertions(+), 3 deletions(-)
--- a/fs/notify/fanotify/fanotify.c~memcg-fsnotify-no-oom-kill-for-remote-memcg-charging
+++ a/fs/notify/fanotify/fanotify.c
@@ -288,10 +288,13 @@ struct fanotify_event *fanotify_alloc_ev
/*
* 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. For the limited size queues, avoid OOM killer in the
+ * target monitoring memcg as it may have security repercussion.
*/
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);
--- a/fs/notify/inotify/inotify_fsnotify.c~memcg-fsnotify-no-oom-kill-for-remote-memcg-charging
+++ a/fs/notify/inotify/inotify_fsnotify.c
@@ -99,9 +99,13 @@ int inotify_handle_event(struct fsnotify
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. Do not
+ * trigger OOM killer in the target monitoring memcg as it may have
+ * security repercussion.
+ */
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)) {
_
Patches currently in -mm which might be from shakeelb@xxxxxxxxxx are
memcg-oom-no-oom-kill-for-__gfp_retry_mayfail.patch
memcg-fsnotify-no-oom-kill-for-remote-memcg-charging.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work-v3.patch
