From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755131AbdFXQ1E (ORCPT ); Sat, 24 Jun 2017 12:27:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:54966 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755028AbdFXQ06 (ORCPT ); Sat, 24 Jun 2017 12:26:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A7B022B68 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jaegeuk@kernel.org Date: Sat, 24 Jun 2017 09:26:54 -0700 From: Jaegeuk Kim To: Chao Yu Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH] f2fs: fix ref of discard command Message-ID: <20170624162654.GA38959@jaegeuk-macbookpro.roam.corp.google.com> References: <20170612030449.79290-1-jaegeuk@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/23, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/6/12 11:04, Jaegeuk Kim wrote: > > This patch resolves kernel panic for xfstests/081, caused by recent f2fs_bug_on > > > > f2fs: add f2fs_bug_on in __remove_discard_cmd > > > > Signed-off-by: Jaegeuk Kim > > --- > > fs/f2fs/segment.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > > index 86a0c1095939..a6d77388a806 100644 > > --- a/fs/f2fs/segment.c > > +++ b/fs/f2fs/segment.c > > @@ -1025,6 +1025,8 @@ static void __wait_discard_cmd(struct f2fs_sb_info *sbi, bool wait_cond) > > list_for_each_entry_safe(dc, tmp, wait_list, list) { > > if (!wait_cond || (dc->state == D_DONE && !dc->ref)) { > > wait_for_completion_io(&dc->wait); > > + if (dc->state == D_DONE && dc->ref) > > + dc->ref--; > > How about using ("f2fs: stop discard thread in prior during umount") instead of > this one? As dereference of dc here will lead use-after-free of real referrer. Yup, I'll also verify that. Thank you. :) > > Thanks, > > > __remove_discard_cmd(sbi, dc); > > } else { > > dc->ref++; > >