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,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 AE9F0C433E0 for ; Mon, 15 Feb 2021 14:29:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E69064E40 for ; Mon, 15 Feb 2021 14:29:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E69064E40 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E8A38D0107; Mon, 15 Feb 2021 09:29:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 872768D00FD; Mon, 15 Feb 2021 09:29:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73AB28D0107; Mon, 15 Feb 2021 09:29:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 5804E8D00FD for ; Mon, 15 Feb 2021 09:29:38 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 13DDD1803F9C2 for ; Mon, 15 Feb 2021 14:29:38 +0000 (UTC) X-FDA: 77820735636.26.wool11_41123a42763b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id D5C53180D96D5 for ; Mon, 15 Feb 2021 14:29:37 +0000 (UTC) X-HE-Tag: wool11_41123a42763b X-Filterd-Recvd-Size: 4866 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Mon, 15 Feb 2021 14:29:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C4E2BB1AC; Mon, 15 Feb 2021 14:29:35 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 8D22C1E6305; Mon, 15 Feb 2021 15:29:35 +0100 (CET) Date: Mon, 15 Feb 2021 15:29:35 +0100 From: Jan Kara To: Tetsuo Handa Cc: Jan Kara , 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 Subject: Re: possible deadlock in start_this_handle (2) Message-ID: <20210215142935.GB22417@quack2.suse.cz> References: <000000000000563a0205bafb7970@google.com> <20210211104947.GL19070@quack2.suse.cz> <20210215124519.GA22417@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Mon 15-02-21 23:06:15, Tetsuo Handa wrote: > 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. a) I think that syzbot reboots the VM between executing different tests to get reproducible conditions. But in theory I agree the test may have contained one image with and one image without a journal. *but* b) as I wrote in the email you are replying to, the jbd2_handle key is private per filesystem. Thus for lockdep to complain about jbd2_handle->fs_reclaim->jbd2_handle deadlock, those jbd2_handle lockdep maps must come from the same filesystem. *and* c) filesystem without journal doesn't use jbd2_handle lockdep map at all so for such filesystems lockdep creates no dependency for jbd2_handle map. Honza > > > > > 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. > -- Jan Kara SUSE Labs, CR