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,INCLUDES_PATCH, MAILING_LIST_MULTI,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 9E0C7C3F2C6 for ; Tue, 3 Mar 2020 20:26:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4BB9120CC7 for ; Tue, 3 Mar 2020 20:26:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="k3ScIMnu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4BB9120CC7 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 EB6106B0006; Tue, 3 Mar 2020 15:26:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E678F6B000C; Tue, 3 Mar 2020 15:26:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7D156B000D; Tue, 3 Mar 2020 15:26:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id B67AB6B0006 for ; Tue, 3 Mar 2020 15:26:16 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DD47C181AC9BF for ; Tue, 3 Mar 2020 20:26:15 +0000 (UTC) X-FDA: 76555183110.09.knot87_1989e0034aa11 X-HE-Tag: knot87_1989e0034aa11 X-Filterd-Recvd-Size: 6209 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 20:26:15 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id d62so4394707oia.11 for ; Tue, 03 Mar 2020 12:26:15 -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=HpAIDIa1wBI6Ov5z+jjt5lVZpEypL7R5bjGGKXYnlac=; b=k3ScIMnuNv2/HBsTQMA6XD06XHBa12PNSnWInqgiYEz7Ugu/JSxO/ydiaE79rQIFK1 fTTvtofKAdwHoLETWZsvZaUhr+o7Fv294Z/48B7A/N4upgqyHUCnI1WemcVQdHAMf2Wl o6PkwcOoyInxHT25DAp69CmUshlpXgZ1ig+okUOjgcEunKUeSFUCJHOv6aL3MixdMZIW 2AFGqeXFdg8Cy+4bOF7Sz3w4abcI6VdTRp5lcmA4SL07LXOA2usEQmpISFBSmGiPgEBa yyxh27PMb8FBl2PSbdaRhuRiJbtF8fJT9zIK1NKZAundoDx3Ap3qEfcGzOOHmnG08BVZ x0xQ== 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=HpAIDIa1wBI6Ov5z+jjt5lVZpEypL7R5bjGGKXYnlac=; b=GXicfLjZoavtGs03fhY9dHo2lRxhrFnBrw1Al3lLcQD2Rrddz3uzyM8ZmXN1ATh3aP hnIRrGKRECxqV0Rq3yV0YctlyGLGeU3fhAi11T8gNldT3fzThcNufUrbJD3r3sn9CxUV HDulyWyADU/cHQSSZdFs7c60rUKSCtIlNP3D14YTu+xyWzYL4MQQopwdBzwV2NrW8bvc cN/OLDkDvpQtlK5vlpYpbvzmqIllYi3SM6ut58J5W5DpJJqgQ79aoiF9eu4tKk3+82QJ 7O2Bh7gtgdzTYyn2xROSH7VxenTrelOGH0gOT/zzHY02vEmHDuJ4IEgTDIbHfo/2fhAz g9eQ== X-Gm-Message-State: ANhLgQ3u5Rh2CTqqa6wLIgCF5qLweFuXHWgW3zhSr8eayDuelC5zgiPf NvY1sOvwO1bVXfcbs4QQYrq2AvVzXD3zd0SdtohW2w== X-Google-Smtp-Source: ADFU+vsmLnUJDjreR1hVwHC5m5pFwfoHKzu0tVZ8VY1CPvCtdFsCyo9/rjJz0Ky3wQKS0mqtTC6sRyxABxIzG2VB/sg= X-Received: by 2002:aca:4183:: with SMTP id o125mr202926oia.125.1583267174592; Tue, 03 Mar 2020 12:26:14 -0800 (PST) MIME-Version: 1.0 References: <0a37bb7d-18a7-c43c-52a5-f13a34decf69@i-love.sakura.ne.jp> In-Reply-To: From: Shakeel Butt Date: Tue, 3 Mar 2020 12:26:03 -0800 Message-ID: Subject: Re: fs/buffer.c: WARNING: alloc_page_buffers while mke2fs To: Yang Shi Cc: Tetsuo Handa , Naresh Kamboju , linux-mm , Andrew Morton , Mel Gorman , Michal Hocko , Dan Schatzberg , Johannes Weiner 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 11:42 AM Yang Shi wrote: > > On Tue, Mar 3, 2020 at 10:15 AM Shakeel Butt wrote: > > > > On Tue, Mar 3, 2020 at 9:47 AM Yang Shi wrote: > > > > > > On Tue, Mar 3, 2020 at 2:53 AM Tetsuo Handa > > > wrote: > > > > > > > > Hello, Naresh. > > > > > > > > > [ 98.003346] WARNING: CPU: 2 PID: 340 at > > > > > include/linux/sched/mm.h:323 alloc_page_buffers+0x210/0x288 > > > > > > > > This is > > > > > > > > /** > > > > * memalloc_use_memcg - Starts the remote memcg charging scope. > > > > * @memcg: memcg to charge. > > > > * > > > > * This function marks the beginning of the remote memcg charging scope. All the > > > > * __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; > > > > } > > > > > > > > which is about memcg. Redirecting to linux-mm. > > > > > > Isn't this triggered by ("loop: use worker per cgroup instead of > > > kworker") in linux-next, which converted loop driver to use worker per > > > cgroup, so it may have multiple workers work at the mean time? > > > > > > So they may share the same "current", then it may cause kind of nested > > > call to memalloc_use_memcg(). > > > > > > Could you please try the below debug patch? This is not the proper > > > fix, but it may help us narrow down the problem. > > > > > > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h > > > index c49257a..1cc1cdc 100644 > > > --- a/include/linux/sched/mm.h > > > +++ b/include/linux/sched/mm.h > > > @@ -320,6 +320,10 @@ static inline void > > > memalloc_nocma_restore(unsigned int flags) > > > */ > > > static inline void memalloc_use_memcg(struct mem_cgroup *memcg) > > > { > > > + if ((current->flags & PF_KTHREAD) && > > > + current->active_memcg) > > > + return; > > > + > > > WARN_ON_ONCE(current->active_memcg); > > > current->active_memcg = memcg; > > > } > > > > > > > Maybe it's time to make memalloc_use_memcg() nesting safe. > > Need handle the below case: > > CPU A CPU B > memalloc_use_memcg > memalloc_use_memcg > memalloc_unuse_memcg > memalloc_unuse_memcg > > > They may manipulate the same task->active_memcg, so CPU B may still > see wrong memcg, and the last call to memalloc_unuse_memcg() on CPU B > may not restore active_memcg to NULL. And, some code depends on > correct active_memcg. Sorry for asking a simple question. What does it mean that more than one kworkers share the same 'current'?