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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8200C433FE for ; Mon, 20 Dec 2021 11:58:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 172236B0071; Mon, 20 Dec 2021 06:58:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1206E6B0073; Mon, 20 Dec 2021 06:58:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00F116B0074; Mon, 20 Dec 2021 06:58:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id E737B6B0071 for ; Mon, 20 Dec 2021 06:58:27 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9416C181AC9C6 for ; Mon, 20 Dec 2021 11:58:27 +0000 (UTC) X-FDA: 78938025054.04.048215C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id AEDA240022 for ; Mon, 20 Dec 2021 11:58:26 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 41FF321116; Mon, 20 Dec 2021 11:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1640001504; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lyu92K3KNUQI+miSQ0I6NCto7SdzSqFDwh12c/n/tyA=; b=JvGdUX+E8HT3To2fRqgrKwt3CPvrj5pR4S7g4TQ4sCsK27gzgZHGyfPYBAh8bKhpvBjrsd Yk1zF+vA2IibW3X5kFzHFKwGVKlW+TyurchWpoZqyDOxN7TeEMvtsb9ah4EvP7rNwms9QX zEce2u13vqAjfGKS8rdSXp17W7uZLy0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1640001504; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lyu92K3KNUQI+miSQ0I6NCto7SdzSqFDwh12c/n/tyA=; b=wd81YJ/ZaqTiPx57/r/zITbr8MA250oIhRsRTj50znOJ+06QuVtJc7zjc//YbrszfNUKLc /4KvWXupviVQAxBg== Received: from quack2.suse.cz (unknown [10.163.28.18]) by relay2.suse.de (Postfix) with ESMTP id 07ED7A3B89; Mon, 20 Dec 2021 11:58:23 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 93E841E1649; Mon, 20 Dec 2021 12:58:23 +0100 (CET) Date: Mon, 20 Dec 2021 12:58:23 +0100 From: Jan Kara To: Tetsuo Handa Cc: kernel test robot , Jens Axboe , syzbot , Christoph Hellwig , Jan Kara , Christoph Hellwig , LKML , Linux Memory Management List , lkp@lists.01.org, lkp@intel.com Subject: Re: [loop] 322c4293ec: xfstests.xfs.049.fail Message-ID: <20211220115823.GB20005@quack2.suse.cz> References: <20211219150933.GJ14057@xsang-OptiPlex-9020> 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-Rspamd-Queue-Id: AEDA240022 X-Stat-Signature: npus54tnwtgaucjc3n6ak34t9kaanmxd Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=JvGdUX+E; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="wd81YJ/Z"; dmarc=none; spf=pass (imf04.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz X-Rspamd-Server: rspam02 X-HE-Tag: 1640001506-683633 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 20-12-21 00:45:46, Tetsuo Handa wrote: > On 2021/12/20 0:09, kernel test robot wrote: > > @@ -13,3 +13,5 @@ > > --- clean > > --- umount ext2 on xfs > > --- umount xfs > > +!!! umount xfs failed > > +(see /lkp/benchmarks/xfstests/results//xfs/049.full for details) > > ... > > (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/049.out /lkp/benchmarks/xfstests/results//xfs/049.out.bad' to see the entire diff) > > Yes, we know this race condition can happen. > > https://lkml.kernel.org/r/16c7d304-60ef-103f-1b2c-8592b48f47c6@i-love.sakura.ne.jp > https://lkml.kernel.org/r/YaYfu0H2k0PSQL6W@infradead.org > > Should we try to wait for autoclear operation to complete? So I think we should try to fix this because as Dave writes in the changelog for a1ecac3b0656 ("loop: Make explicit loop device destruction lazy") which started all this, having random EBUSY failures (either from losetup or umount) is annoying and you need to work it around it lots of unexpected places. We cannot easily wait for work completion in the loop device code without reintroducing the deadlock - whole lo_release() is called under disk->open_mutex which you also need to grab in __loop_clr_fd(). So to avoid holding backing file busy longer than expected, we could use task_work instead of ordinary work as I suggested - but you were right that we need to be somewhat careful and in case we are running in a kthread, we would still need to offload to a normal work (but in that case we don't care about delaying file release anyway). Honza -- Jan Kara SUSE Labs, CR