From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:33410 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbeEQJhy (ORCPT ); Thu, 17 May 2018 05:37:54 -0400 Date: Thu, 17 May 2018 11:37:36 +0200 From: Greg KH To: ethanwu Cc: stable@vger.kernel.org, dsterba@suse.com Subject: Re: [PATCH] btrfs: Take trans lock before access running trans in check_delayed_ref Message-ID: <20180517093736.GA10421@kroah.com> References: <1525566942228124@kroah.com> <1526547911-32169-1-git-send-email-ethanwu@synology.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1526547911-32169-1-git-send-email-ethanwu@synology.com> Sender: stable-owner@vger.kernel.org List-ID: On Thu, May 17, 2018 at 05:01:45PM +0800, ethanwu wrote: > commit 998ac6d21cfd6efd58f5edf420bae8839dda9f2a upstream > > In preivous patch: > Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist > We avoid starting btrfs transaction and get this information from > fs_info->running_transaction directly. > > When accessing running_transaction in check_delayed_ref, there's a > chance that current transaction will be freed by commit transaction > after the NULL pointer check of running_transaction is passed. > > After looking all the other places using fs_info->running_transaction, > they are either protected by trans_lock or holding the transactions. > > Fix this by using trans_lock and increasing the use_count. > > Fixes: e4c3b2dcd144 ("Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist") > CC: stable@vger.kernel.org # 4.14+ > Signed-off-by: ethanwu > Signed-off-by: David Sterba > --- > fs/btrfs/extent-tree.c | 7 +++++++ > 1 file changed, 7 insertions(+) Thanks for the backport, now queued up. greg k-h