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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06BE6C04A94 for ; Mon, 14 Aug 2023 15:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232905AbjHNPYQ (ORCPT ); Mon, 14 Aug 2023 11:24:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232665AbjHNPXo (ORCPT ); Mon, 14 Aug 2023 11:23:44 -0400 Received: from out-106.mta1.migadu.com (out-106.mta1.migadu.com [IPv6:2001:41d0:203:375::6a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21AD6DA for ; Mon, 14 Aug 2023 08:23:43 -0700 (PDT) Date: Mon, 14 Aug 2023 11:23:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1692026621; h=from:from:reply-to:subject:subject: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=odVIt/5wqGAJeOs9uVdPC5bYWm2C36UtqikhKqjhgQs=; b=av8xoPF9Wxv45SXZf6WLQK5/Fb+dKBpiRouCaSh6qZkGuACL8mMMX2ostiNTehpbQS4XkV wpzk93WJrZRnVsWYao+xq+CHAlHERowZiwmJtb9da9Cg+KOtv7mLackqHPTAsFGBPpToXc nv6TeaSEaZL8I/AKljssQXQ0t+Hs+7c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Christian Brauner Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, djwong@kernel.org, dchinner@redhat.com, sandeen@redhat.com, willy@infradead.org, josef@toxicpanda.com, tytso@mit.edu, bfoster@redhat.com, jack@suse.cz, andreas.gruenbacher@gmail.com, peterz@infradead.org, akpm@linux-foundation.org, dhowells@redhat.com, snitzer@kernel.org, axboe@kernel.dk Subject: Re: [GIT PULL] bcachefs Message-ID: <20230814152335.oiroowt2co2kj4xx@moria.home.lan> References: <20230626214656.hcp4puionmtoloat@moria.home.lan> <20230706155602.mnhsylo3pnief2of@moria.home.lan> <20230712025459.dbzcjtkb4zem4pdn@moria.home.lan> <20230810155453.6xz2k7f632jypqyz@moria.home.lan> <20230811-neigt-baufinanzierung-4c9521b036c6@brauner> <20230811125801.g3uwnouefoleq4nx@moria.home.lan> <20230814-funknetz-dreikampf-196dd2545dd9@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230814-funknetz-dreikampf-196dd2545dd9@brauner> X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 14, 2023 at 09:25:54AM +0200, Christian Brauner wrote: > On Fri, Aug 11, 2023 at 08:58:01AM -0400, Kent Overstreet wrote: > > I don't see the justification for the delay - every cycle there's some > > amount of vfs/block layer refactoring that affects filesystems, the > > super work is no different. > > So, the reason is that we're very close to having the super code > massaged in a shape where bcachefs should be able to directly make use > of the helpers instead of having to pull in custom code at all. But not > all that work has made it. Well, bcachefs really isn't doing anything terribly unusual here; we're using sget() directly, same as btrfs, and we have to because we're both multi device filesystems. Jan's restructing of mount_bdev() got me thinking that it should be possible to do a mount_bdevs() that both btrfs and bcachefs could use - but we don't need to be blocked on that, sget()'s been a normal exported interface since forever. Somewhat related, I dropped this patch from my tree: block: Don't block on s_umount from __invalidate_super() https://evilpiepirate.org/git/bcachefs.git/commit/?h=bcachefs-v6.3&id=1dd488901bc025a61e1ce1a0f54999a2b221bd78 and instead, for now we're closing block devices later in the shutdown path like other filesystems do (after calling generic_shutdown_super(), not in put_super()). But now I've got some test failures, e.g. https://evilpiepirate.org/~testdashboard/c/040e910f7f316ea6273c895dcc026b9f1ad36a8e/xfstests.generic.604/log.br and since you guys are switching block device opens to use a real holder, I suspect you'll be seeing the same issue soon. The bug is that the mount appears to be gone - generic_shutdown_super() is finished - so as far as userspace can tell everything is shutdown and we should be able to start using the block device again, but the unmount path hasn't actually called blkdev_put() yet. So that patch I posted is one way to solve the self-deadlock from calling blkdev_put() where we really want to be calling it... not the prettiest way, but I think this is something we do need to get fixed.