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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 69BB7C3F2D1 for ; Tue, 3 Mar 2020 23:22:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1A0D82072D for ; Tue, 3 Mar 2020 23:22:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F6sFC+AA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A0D82072D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A64E06B000D; Tue, 3 Mar 2020 18:22:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A168F6B000E; Tue, 3 Mar 2020 18:22:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92B216B0010; Tue, 3 Mar 2020 18:22:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 7BE716B000D for ; Tue, 3 Mar 2020 18:22:13 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 361D1180AD802 for ; Tue, 3 Mar 2020 23:22:13 +0000 (UTC) X-FDA: 76555626546.26.voice90_6aa51981ed441 X-HE-Tag: voice90_6aa51981ed441 X-Filterd-Recvd-Size: 7675 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 23:22:12 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id p125so147974oif.10 for ; Tue, 03 Mar 2020 15:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/3m9TjUuaLJSZKDd0TO4MBQAvkJs9RUE0aq5GXVp48k=; b=F6sFC+AAfWd26SYvJFw2REg9MgJcSEGHa/GN/vh0r6KcEHtl/vGV31y0QNFCzYircg BpRiKorrqB0DS8PdXdU5FSmSlbOqCRpGjqXbbZt4V7P5zfHQcgd2Szzj15Upm5xhObGk /vzyR9NLiUSJzone5kVm1hqTEdUrUQIOlx62ExZIpA+1+FrEJJj4tzmU/u0DS9coOPP8 bEuIjNrj5uIhPA+dCY3a1HsS0zRqjOkrguSwKlY0mv0w7UB7WZDgo+YWXW1XDeBEFsTW inz9BO4W18Ry7t9wjvFLTkvCxCLPIu+elMeNc5WZPI+TUMMysiZK2O4Hytuhan0wMnWv +qqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/3m9TjUuaLJSZKDd0TO4MBQAvkJs9RUE0aq5GXVp48k=; b=lmCttSEtghTgljZxKENXPGQYmDnOs2tzUVcT/bbFk75a1O5CujCZ56Wb5+gZh4cT92 wetkDd0We/sr4LBZPTDGb6q6FY8Bxaq4Phfdawg0WEjkPswkXMK02GF+sbi2D4pcIP3j sAjsGb5PQOdO4SR/gSpWZT3V1RuaziGtthbyElwTj6mGkGO4P/+/CAIkHw/BlVzM7P67 xnHvAFVKk4I5INBzO8KgNAstnTRA3d4ApeNFzxtuBkLeNw9Wa7JaD3D0bCB5/9FNp/va pPhNKmqRyO6EfzErQzoAg6KLOWAsnWrMLJYiRYVgWd50n+Y2u7DVRzNwvaFHzUcCjYxs esww== X-Gm-Message-State: ANhLgQ3RSbHQCy++BPzrAzJPylPJAzMX7TnwcwB/YRAmNeabcszcHUZK 4st/RVsJ26iMX3Bx1FFv2GIgF6+oJNQ8aA9txdmnxA== X-Google-Smtp-Source: ADFU+vs5zBXj+97qYj30im1oVDXdj9+YIU/bAhcXEZQMCpT97KtLFDZtrTEcLsLCUZjGBVsG8rZ09SSXiB0mrPxIHh8= X-Received: by 2002:aca:d03:: with SMTP id 3mr671084oin.69.1583277731644; Tue, 03 Mar 2020 15:22:11 -0800 (PST) MIME-Version: 1.0 References: <0a37bb7d-18a7-c43c-52a5-f13a34decf69@i-love.sakura.ne.jp> <20200303202623.GA68565@cmpxchg.org> <20200303210632.GC68565@cmpxchg.org> In-Reply-To: <20200303210632.GC68565@cmpxchg.org> From: Shakeel Butt Date: Tue, 3 Mar 2020 15:22:00 -0800 Message-ID: Subject: Re: fs/buffer.c: WARNING: alloc_page_buffers while mke2fs To: Johannes Weiner Cc: Yang Shi , Tetsuo Handa , Naresh Kamboju , linux-mm , Andrew Morton , Mel Gorman , Michal Hocko , Dan Schatzberg Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 3, 2020 at 1:06 PM Johannes Weiner wrote: > > On Tue, Mar 03, 2020 at 12:40:33PM -0800, Shakeel Butt wrote: > > On Tue, Mar 3, 2020 at 12:26 PM Johannes Weiner wrote: > > > From e0e5ace069af5a36e41eafe3bf21a67966127c04 Mon Sep 17 00:00:00 2001 > > > From: Johannes Weiner > > > Date: Tue, 3 Mar 2020 15:15:39 -0500 > > > Subject: [PATCH] mm: support nesting memalloc_use_memcg() > > > > > > The memalloc_use_memcg() function to override the default memcg > > > accounting context currently doesn't nest. But the patches to make the > > > loop driver cgroup-aware will end up nesting: > > > > > > [ 98.137605] alloc_page_buffers+0x210/0x288 > > > [ 98.141799] __getblk_gfp+0x1d4/0x400 > > > [ 98.145475] ext4_read_block_bitmap_nowait+0x148/0xbc8 > > > [ 98.150628] ext4_mb_init_cache+0x25c/0x9b0 > > > [ 98.154821] ext4_mb_init_group+0x270/0x390 > > > [ 98.159014] ext4_mb_good_group+0x264/0x270 > > > [ 98.163208] ext4_mb_regular_allocator+0x480/0x798 > > > [ 98.168011] ext4_mb_new_blocks+0x958/0x10f8 > > > [ 98.172294] ext4_ext_map_blocks+0xec8/0x1618 > > > [ 98.176660] ext4_map_blocks+0x1b8/0x8a0 > > > [ 98.180592] ext4_writepages+0x830/0xf10 > > > [ 98.184523] do_writepages+0xb4/0x198 > > > [ 98.188195] __filemap_fdatawrite_range+0x170/0x1c8 > > > [ 98.193086] filemap_write_and_wait_range+0x40/0xb0 > > > [ 98.197974] ext4_punch_hole+0x4a4/0x660 > > > [ 98.201907] ext4_fallocate+0x294/0x1190 > > > [ 98.205839] loop_process_work+0x690/0x1100 > > > [ 98.210032] loop_workfn+0x2c/0x110 > > > [ 98.213529] process_one_work+0x3e0/0x648 > > > [ 98.217546] worker_thread+0x70/0x670 > > > [ 98.221217] kthread+0x1b8/0x1c0 > > > [ 98.224452] ret_from_fork+0x10/0x18 > > > > > > where loop_process_work() sets the memcg override to the memcg that > > > submitted the IO request, and alloc_page_buffers() sets the override > > > to the memcg that instantiated the cache page, which may differ. > > > > > > Make memalloc_use_memcg() return the old memcg and convert existing > > > users to a stacking model. Delete the unused memalloc_unuse_memcg(). > > > > > > Signed-off-by: Johannes Weiner > > > > Reviewed-by: Shakeel Butt > > Thanks Shakeel > > > > @@ -316,31 +316,26 @@ static inline void memalloc_nocma_restore(unsigned int flags) > > > * __GFP_ACCOUNT allocations till the end of the scope will be charged to the > > > * given memcg. > > > * > > > - * NOTE: This function is not nesting safe. > > > - */ > > > -static inline void memalloc_use_memcg(struct mem_cgroup *memcg) > > > -{ > > > - WARN_ON_ONCE(current->active_memcg); > > > - current->active_memcg = memcg; > > > -} > > > - > > > -/** > > > - * memalloc_unuse_memcg - Ends the remote memcg charging scope. > > > + * NOTE: This function can nest. Users must save the return value and > > > + * reset the previous value after their own charging scope is over: > > > > Should we mention that this is still not irq safe? At the moment other > > than skmem we don't do memcg charging in the interrupt and skmem has a > > memcg already associated with it. Maybe in future there might be a > > case where we want a specific memcg be charged for kmem in the > > interrupt context. Until then we can mark that this function should > > not be used in interrupt. > > Is it actually unsafe? It's not an RMW operation, being interrupted > doesn't corrupt its state. > > I.e. this is safe: > > process: interrupt: > old = current->active_memcg > old = current->active_memcg > current->active_memcg = new > allocate > current->active_memcg = old > current->active_memcg = new > return old > > This is safe as well: > > process: interrupt: > old = current->active_memcg > current->active_memcg = new > old = current->active_memcg > current->active_memcg = new > allocate > current->active_memcg = old > return old Yes, you are right. Thanks for the explanation.