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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 DCB98C433DB for ; Mon, 15 Feb 2021 14:07:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6026764DCF for ; Mon, 15 Feb 2021 14:07:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6026764DCF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA6898D0106; Mon, 15 Feb 2021 09:07:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C57C78D00FD; Mon, 15 Feb 2021 09:07:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6E088D0106; Mon, 15 Feb 2021 09:07:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id 9F6A48D00FD for ; Mon, 15 Feb 2021 09:07:05 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 650BC1808E33A for ; Mon, 15 Feb 2021 14:07:05 +0000 (UTC) X-FDA: 77820678810.11.women25_0b024342763b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 3E4F118039521 for ; Mon, 15 Feb 2021 14:07:05 +0000 (UTC) X-HE-Tag: women25_0b024342763b X-Filterd-Recvd-Size: 4539 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Mon, 15 Feb 2021 14:07:04 +0000 (UTC) Received: from fsav301.sakura.ne.jp (fsav301.sakura.ne.jp [153.120.85.132]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 11FE6HGh009237; Mon, 15 Feb 2021 23:06:17 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav301.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav301.sakura.ne.jp); Mon, 15 Feb 2021 23:06:17 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav301.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 11FE6HwJ009225 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Feb 2021 23:06:17 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: possible deadlock in start_this_handle (2) To: Jan Kara Cc: jack@suse.com, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, tytso@mit.edu, mhocko@suse.cz, linux-mm@kvack.org, syzbot References: <000000000000563a0205bafb7970@google.com> <20210211104947.GL19070@quack2.suse.cz> <20210215124519.GA22417@quack2.suse.cz> From: Tetsuo Handa Message-ID: Date: Mon, 15 Feb 2021 23:06:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210215124519.GA22417@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 2021/02/15 21:45, Jan Kara wrote: > On Sat 13-02-21 23:26:37, Tetsuo Handa wrote: >> Excuse me, but it seems to me that nothing prevents >> ext4_xattr_set_handle() from reaching ext4_xattr_inode_lookup_create() >> without memalloc_nofs_save() when hitting ext4_get_nojournal() path. >> Will you explain when ext4_get_nojournal() path is executed? > > That's a good question but sadly I don't think that's it. > ext4_get_nojournal() is called when the filesystem is created without a > journal. In that case we also don't acquire jbd2_handle lockdep map. In the > syzbot report we can see: Since syzbot can test filesystem images, syzbot might have tested a filesystem image created both with and without journal within this boot. > > kswapd0/2246 is trying to acquire lock: > ffff888041a988e0 (jbd2_handle){++++}-{0:0}, at: start_this_handle+0xf81/0x1380 fs/jbd2/transaction.c:444 > > but task is already holding lock: > ffffffff8be892c0 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x30 mm/page_alloc.c:5195 > > So this filesystem has very clearly been created with a journal. Also the > journal lockdep tracking machinery uses: While locks held by kswapd0/2246 are fs_reclaim, shrinker_rwsem, &type->s_umount_key#38 and jbd2_handle, isn't the dependency lockdep considers problematic is Chain exists of: jbd2_handle --> &ei->xattr_sem --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&ei->xattr_sem); lock(fs_reclaim); lock(jbd2_handle); where CPU0 is kswapd/2246 and CPU1 is the case of ext4_get_nojournal() path? If someone has taken jbd2_handle and &ei->xattr_sem in this order, isn't this dependency true? > > rwsem_acquire_read(&journal->j_trans_commit_map, 0, 0, _THIS_IP_); > > so a lockdep key is per-filesystem. Thus it is not possible that lockdep > would combine lock dependencies from two different filesystems. > > But I guess we could narrow the search for this problem by adding WARN_ONs > to ext4_xattr_set_handle() and ext4_xattr_inode_lookup_create() like: > > WARN_ON(ext4_handle_valid(handle) && !(current->flags & PF_MEMALLOC_NOFS)); > > It would narrow down a place in which PF_MEMALLOC_NOFS flag isn't set > properly... At least that seems like the most plausible way forward to me. You can use CONFIG_DEBUG_AID_FOR_SYZBOT for adding such WARN_ONs on linux-next.