From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E120C04AB4 for ; Sun, 12 May 2019 16:09:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D43F2173E for ; Sun, 12 May 2019 16:09:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="i3YEIaQI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726878AbfELQJ6 (ORCPT ); Sun, 12 May 2019 12:09:58 -0400 Received: from mail-yw1-f74.google.com ([209.85.161.74]:53037 "EHLO mail-yw1-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726478AbfELQJ5 (ORCPT ); Sun, 12 May 2019 12:09:57 -0400 Received: by mail-yw1-f74.google.com with SMTP id b189so20545585ywa.19 for ; Sun, 12 May 2019 09:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=pNYDYF29KQTiDsLTir5ePdeguGYagzUQEsurF8lSHbY=; b=i3YEIaQIHO/PR2+mMIFIpaGHrsGtdYQBTKhgEeVGdXy6IjrQUWW5WGYFsXSjxoy4Qa 5xlboHTgv9cyDLZ9V2BO/jEBAklDBwaVlu3TrXjcaV9JkSH4r/P/p1LzRbEzXM8NGGqh aRossIettQVPYRP2lRDcOH67U+qYdSZGyj8FX4IOWj8uCAckk7xaZVr5GB9pAj4t4hz5 tsXRN5yNqBGxFb7yJ9dJbrVjuLxoYHIHNy5JGiw3cCLlaZQjNXt/bf4IpwEQgLEKf8BV SFS4JqfbN/IHML9PTuVHjyceb1Le0/n+fA3YtuBOVoJ7+b6QgRQjGdnyBJBvvSOkAeon Uifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=pNYDYF29KQTiDsLTir5ePdeguGYagzUQEsurF8lSHbY=; b=pk7+FaA3p7SioqOIr68V5Am6I3PUZZ32ZSmg4heEc/lDSTaR1iNUlhtYruj9yUbhde 6LcXS2rjdZA2HnOXb9r5yxQ4m+vcSTX+mT3KemK+x34dw6G6vZf+RoRLHiz3xuEFHvZO L8Xy79aWCw+aT3dcmHxQVj/2ytogy+wCTVLK8QCkWyHt9ueprVeEHtC4PYVgvImh72gD 10D0fW569/gFsfxK75CCY4ZgSsgvB3XQZ+V6sqJ0kC2MD4XgUz+wrLfYScMw8n1M0537 hhlOuaQoB2SqfjM/XOaAhl3g9ndBV3jdeoBAUkJlyvHPP11sGVoDUuxTVPZiDtpj1/IU 0fhw== X-Gm-Message-State: APjAAAXIx36YEB1f6utsQmtp8UuV4mu9E7lv0xxPAYiAtkF7aMQbJi2t Nhe5Ru5eI9UeSbWHvyk3cSsnkT0Dcy+2DA== X-Google-Smtp-Source: APXvYqwFjUEgIaKr0kbwdw7yEWcBwWFgnrXBu4fdjexDy0pGsGSbQmVSEDWFzUFaVoq6HIRtK7D5ckxThWerQA== X-Received: by 2002:a25:585:: with SMTP id 127mr10890358ybf.60.1557677396951; Sun, 12 May 2019 09:09:56 -0700 (PDT) Date: Sun, 12 May 2019 09:09:27 -0700 In-Reply-To: <20190512160927.80042-1-shakeelb@google.com> Message-Id: <20190512160927.80042-2-shakeelb@google.com> Mime-Version: 1.0 References: <20190512160927.80042-1-shakeelb@google.com> X-Mailer: git-send-email 2.21.0.1020.gf2820cf01a-goog Subject: [RESEND PATCH v2 2/2] memcg, fsnotify: no oom-kill for remote memcg charging From: Shakeel Butt To: Johannes Weiner , Vladimir Davydov , Michal Hocko , Andrew Morton , Roman Gushchin , Jan Kara , Amir Goldstein Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Reviewed-by: Roman Gushchin --- 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