Received: by 10.192.165.156 with SMTP id m28csp138373imm; Tue, 10 Apr 2018 18:17:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+j5nzBfEg8YZyPrGUWzPBZEV/V1NTYrQki6mAItuS8NgT7s08O+WVymcfUE44D7pkLnHQo X-Received: by 2002:a17:902:6547:: with SMTP id d7-v6mr2740518pln.253.1523409423892; Tue, 10 Apr 2018 18:17:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523409423; cv=none; d=google.com; s=arc-20160816; b=w6fKltQeg3RjNfj4mTrQsxXn3ksyCv/pww1kcJspVjj7aYwyiHV2KVPERDu+jwdq54 lXufREqVjiJ29Qy6aFJtYD7axIEMPgDCF1LqAOY4EjRZnKYSYc/oQTWsXN/Ze22i32yn Ftu6rNT+23eJG/y/iL+ieOfU5trrcB0C+mUHu3iOY1py5wytPJfJQn1AFh920xl4Qq5k pCUPjwSA7n9JFumrPvauUZ4i/TR3wBoCkfUSpEbH3GWkKwhMRhRArKHJI76vCQQUl5t0 iwNlxUB8n9CGsOxGdQysn8+YrkWsEvYyu7c1SStsxtrqHmWF760S5df2pHMMXzRWi3tM FZRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=0a78iP7XyVohawnYUaG2KLlblV0/SbekkANO4IDhfEE=; b=Pro55vIiKKtznjyf9RreOYHd00sY/J9ZrGNEwqS7FwrFiWMQ1dGOKPLmlIlIcvQAF/ V78j5iVza7F09bk33YS27/XrLD3UtiTYQ5iPrdFNsts/JynNtpxgiS08r1jCLIyhoeEp 4uZqTaOqywNDW16rGRsGRSXupVN+Nhj0ewmiW3Ii2qByNIVihjrGUjxhGRFNUWZXEUzp rB+bqmWX1WYLELo4rW/KkOgM2z8OA2q0Wxt/wSo8496dBS/NNk7Vy14SKnH17cNG5SV5 UMAb6eZMJa2nVbN3NCbrBMQZov4WZ9mvUXVGmuMRZUsikGZSzD1EFcrb94cilUdUf51b cwlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=l9stHfRA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10-v6si3924464plt.616.2018.04.10.18.16.27; Tue, 10 Apr 2018 18:17:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=l9stHfRA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753042AbeDKBD6 (ORCPT + 99 others); Tue, 10 Apr 2018 21:03:58 -0400 Received: from mail-yw0-f194.google.com ([209.85.161.194]:35336 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753013AbeDKBDz (ORCPT ); Tue, 10 Apr 2018 21:03:55 -0400 Received: by mail-yw0-f194.google.com with SMTP id c20so54875ywa.2 for ; Tue, 10 Apr 2018 18:03:55 -0700 (PDT) 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=0a78iP7XyVohawnYUaG2KLlblV0/SbekkANO4IDhfEE=; b=l9stHfRADDhmFZmBAi50VnNpMYTDPTc7SrfI7WLg+foeeSyS7J5EE8d8svy/FpR8N+ I0A+D/QVvrQ//IoyOhwnOkLaNWoR/+oYJH1/4vnHTVSImpK78hPENwV6PngXGqrgifXA X+K0eCVdfp50EoyhpgO3bT/I+Wn4blq2FBPpjL+2tEwSUaercx9i5IsTYDLCarB9Dxv1 7yJgpFztPaFn4DBJ3+Wiy5DNsRWLEo0s+C6DhQBd7aapfbLivz1Wgg3SqqNLkFuO7l6m iJH4qIKURJmEsr7SGfizOOcsfsOF29qTFMIfCwxAl29BCyDEBIFTHvC4BpwexhWQN1rT vR/g== 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=0a78iP7XyVohawnYUaG2KLlblV0/SbekkANO4IDhfEE=; b=ZaTg/nE3R16iuFu3NwkI6Sh/m03o1jg99uG1g28cDj3raGU30NcHt4RriBZQMwwOW1 ZhrSUC5sa71uU6xeIsZgj3JO9e1smLEkKGmz0yitwO4B6BkQKUI/rNXhyLwp0vxijH7c x+Q9p20uYwfTlHGAq4oGcvqGagTwcJ5Gtl3AqVE3SCbA2Blaydl/SFRqwSysPSD0V/Uc ANZuVJXbYKC5Al80CoWhOHzRnQ07HlXaCXoxkdCQNJQ7li1GqhTo3ZrYk7eglmWV3QOA l0Mhb558IXDGvgFNFYsA5oUNekHP/XGnfmya6N3M9+1CotTLoqfLV8yaHzPIIslKSLu4 5+5w== X-Gm-Message-State: ALQs6tDR4fUM2XXBV36LtH26aRtvMGQMvLVAN8/3XBp+MMYaNieOKL6O ZJ74047wdSugwwnCIK8a/dXBQO+64HwGZAHAhgq/nw== X-Received: by 10.129.108.67 with SMTP id h64mr1398011ywc.500.1523408634627; Tue, 10 Apr 2018 18:03:54 -0700 (PDT) MIME-Version: 1.0 References: <201804080259.VS5U0mKT%fengguang.wu@intel.com> <20180410005908.167976-1-gthelen@google.com> <20180410133759.8ffd3170e5aaa7eb7eddcba6@linux-foundation.org> In-Reply-To: <20180410133759.8ffd3170e5aaa7eb7eddcba6@linux-foundation.org> From: Greg Thelen Date: Wed, 11 Apr 2018 01:03:43 +0000 Message-ID: Subject: Re: [PATCH v3] writeback: safer lock nesting To: Andrew Morton Cc: Wang Long , Michal Hocko , Johannes Weiner , Tejun Heo , npiggin@gmail.com, LKML , Linux MM 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 On Tue, Apr 10, 2018 at 1:38 PM Andrew Morton wrote: > On Mon, 9 Apr 2018 17:59:08 -0700 Greg Thelen wrote: > > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > > the page's memcg is undergoing move accounting, which occurs when a > > process leaves its memcg for a new one that has > > memory.move_charge_at_immigrate set. > > > > unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the > > given inode is switching writeback domains. Switches occur when enough > > writes are issued from a new domain. > > > > This existing pattern is thus suspicious: > > lock_page_memcg(page); > > unlocked_inode_to_wb_begin(inode, &locked); > > ... > > unlocked_inode_to_wb_end(inode, locked); > > unlock_page_memcg(page); > > > > If both inode switch and process memcg migration are both in-flight then > > unlocked_inode_to_wb_end() will unconditionally enable interrupts while > > still holding the lock_page_memcg() irq spinlock. This suggests the > > possibility of deadlock if an interrupt occurs before > > unlock_page_memcg(). > > > > truncate > > __cancel_dirty_page > > lock_page_memcg > > unlocked_inode_to_wb_begin > > unlocked_inode_to_wb_end > > > > > > end_page_writeback > > test_clear_page_writeback > > lock_page_memcg > > > > unlock_page_memcg > > > > Due to configuration limitations this deadlock is not currently possible > > because we don't mix cgroup writeback (a cgroupv2 feature) and > > memory.move_charge_at_immigrate (a cgroupv1 feature). > > > > If the kernel is hacked to always claim inode switching and memcg > > moving_account, then this script triggers lockup in less than a minute: > > cd /mnt/cgroup/memory > > mkdir a b > > echo 1 > a/memory.move_charge_at_immigrate > > echo 1 > b/memory.move_charge_at_immigrate > > ( > > echo $BASHPID > a/cgroup.procs > > while true; do > > dd if=/dev/zero of=/mnt/big bs=1M count=256 > > done > > ) & > > while true; do > > sync > > done & > > sleep 1h & > > SLEEP=$! > > while true; do > > echo $SLEEP > a/cgroup.procs > > echo $SLEEP > b/cgroup.procs > > done > > > > Given the deadlock is not currently possible, it's debatable if there's > > any reason to modify the kernel. I suggest we should to prevent future > > surprises. > > > > ... > > > > Changelog since v2: > > - explicitly initialize wb_lock_cookie to silence compiler warnings. > But only in some places. What's up with that? I annotated it in places where my compiler was complaining about. But you're right. It's better to init all 4. > > > > ... > > > > --- a/include/linux/backing-dev.h > > +++ b/include/linux/backing-dev.h > > @@ -346,7 +346,7 @@ static inline struct bdi_writeback *inode_to_wb(const struct inode *inode) > > /** > > * unlocked_inode_to_wb_begin - begin unlocked inode wb access transaction > > * @inode: target inode > > - * @lockedp: temp bool output param, to be passed to the end function > > + * @cookie: output param, to be passed to the end function > > * > > * The caller wants to access the wb associated with @inode but isn't > > * holding inode->i_lock, mapping->tree_lock or wb->list_lock. This > > @@ -354,12 +354,11 @@ static inline struct bdi_writeback *inode_to_wb(const struct inode *inode) > > * association doesn't change until the transaction is finished with > > * unlocked_inode_to_wb_end(). > > * > > - * The caller must call unlocked_inode_to_wb_end() with *@lockdep > > - * afterwards and can't sleep during transaction. IRQ may or may not be > > - * disabled on return. > > + * The caller must call unlocked_inode_to_wb_end() with *@cookie afterwards and > > + * can't sleep during transaction. IRQ may or may not be disabled on return. > > */ > Grammar is a bit awkward here, > > > > ... > > > > --- a/mm/page-writeback.c > > +++ b/mm/page-writeback.c > > @@ -2501,13 +2501,13 @@ void account_page_redirty(struct page *page) > > if (mapping && mapping_cap_account_dirty(mapping)) { > > struct inode *inode = mapping->host; > > struct bdi_writeback *wb; > > - bool locked; > > + struct wb_lock_cookie cookie = {0}; > Trivia: it's better to use "= {}" here. That has the same effect and > it doesn't assume that the first field is a scalar. And indeed, the > first field is a bool so it should be {false}! Nod. Thanks for the tip. > So... > --- a/include/linux/backing-dev.h~writeback-safer-lock-nesting-fix > +++ a/include/linux/backing-dev.h > @@ -355,7 +355,8 @@ static inline struct bdi_writeback *inod > * unlocked_inode_to_wb_end(). > * > * The caller must call unlocked_inode_to_wb_end() with *@cookie afterwards and > - * can't sleep during transaction. IRQ may or may not be disabled on return. > + * can't sleep during the transaction. IRQs may or may not be disabled on > + * return. > */ > static inline struct bdi_writeback * > unlocked_inode_to_wb_begin(struct inode *inode, struct wb_lock_cookie *cookie) > --- a/mm/page-writeback.c~writeback-safer-lock-nesting-fix > +++ a/mm/page-writeback.c > @@ -2501,7 +2501,7 @@ void account_page_redirty(struct page *p > if (mapping && mapping_cap_account_dirty(mapping)) { > struct inode *inode = mapping->host; > struct bdi_writeback *wb; > - struct wb_lock_cookie cookie = {0}; > + struct wb_lock_cookie cookie = {}; > wb = unlocked_inode_to_wb_begin(inode, &cookie); > current->nr_dirtied--; > @@ -2613,7 +2613,7 @@ void __cancel_dirty_page(struct page *pa > if (mapping_cap_account_dirty(mapping)) { > struct inode *inode = mapping->host; > struct bdi_writeback *wb; > - struct wb_lock_cookie cookie = {0}; > + struct wb_lock_cookie cookie = {}; > lock_page_memcg(page); > wb = unlocked_inode_to_wb_begin(inode, &cookie); > @@ -2653,7 +2653,7 @@ int clear_page_dirty_for_io(struct page > if (mapping && mapping_cap_account_dirty(mapping)) { > struct inode *inode = mapping->host; > struct bdi_writeback *wb; > - struct wb_lock_cookie cookie = {0}; > + struct wb_lock_cookie cookie = {}; > /* > * Yes, Virginia, this is indeed insane. > But I wonder about the remaining uninitialized wb_lock_cookies? Yeah, I'll post an v4 with everything folded in.