Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp431281pxb; Thu, 13 Jan 2022 09:17:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwLtjRasIvSN11/c1/EVFnG19cZHiHlT/B8j1/duYR5YtQz324hSE+MyxlgPaB2YqBSEeEN X-Received: by 2002:a17:903:2311:b0:14a:8068:a6d with SMTP id d17-20020a170903231100b0014a80680a6dmr2671714plh.70.1642094250123; Thu, 13 Jan 2022 09:17:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642094250; cv=none; d=google.com; s=arc-20160816; b=m3E9HjciAhhGDxbkWyd36P2SLR7SUTYij5KoGehUQKScfhJ1Sry7HRjYvUQIqZmDv6 StoMAdqKLj5IGX7YV94q2JfAH+yHWbVQ0jJkMIPPKvfEOXWz5HmJ9E568uRwgkd/AZpW UxLMsAgiGSSEC8wzmgRXAd4n+0P1+gb2wUg40HP/X0L5UYVKGIJKhlyNmssQ12Fv5Tf0 OpIoZ4PzUd2QoAD9/fENhQ70fFqsOBZa/Ocw48K/dI26X1Y6PpJmubDdCC4k8eZeE+Kg JEpvcMiVryrRqr8LM4b9+JEk0EyGXlyPFUA2MMIC2AkcFzftC+4wStu62ONR/kCxqFiQ ioXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TCNkeFEK71+LV6A7k+ZbeQqGlDkwam6mXnXbXpILn2s=; b=hQjUUt2CtEQGLyMgqIx2PZvNL+CqbATJzWwMDQzYyF56vUVHAn8J/MegOFsJS8N0dT ZpNZGQ00V4pb2/wD5xe5drxmYsk3cyNZqRAkqZwVVgysqXoJa/Q99l2XPVy4hDsRLiCc eqBZcI9L5E2pLcrBKux5Mas5svHsJcX+OCGHecTeOaHBb/f62AH+1oPfKuhhmM7dQ/z+ PM8oJduoeoGrz25icqgJ9DG5N6j6EZMewHg8XYg2S73+bcoYwMITm/NUWSsG3XhbYijY RA+VJ47e6KmJ0BNZ0g6JyICPY6F7oLKFQUN7jETy+I3Tb4YEi9e2B4Bx542Ud++vG9HC 59iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L1QUmLBS; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si3641268pgd.559.2022.01.13.09.17.15; Thu, 13 Jan 2022 09:17:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L1QUmLBS; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233781AbiAMMIR (ORCPT + 99 others); Thu, 13 Jan 2022 07:08:17 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:33729 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232873AbiAMMIQ (ORCPT ); Thu, 13 Jan 2022 07:08:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642075695; 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=TCNkeFEK71+LV6A7k+ZbeQqGlDkwam6mXnXbXpILn2s=; b=L1QUmLBSQA2cCN83VEfi9bkQfCr5ncpBZA3cwlflyrrfRuXnG4Rn+LpzftbwbhhtRd45Yd BBj/2WKh6X8jYadOG1+iHZI9SRxFxVGEJ7C/+5UMiooxOWI3HoiF527hN4FL7MyiXF6jLE ziq0fxBn+TxDEVmzy71VUWOm0qNzlTA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-57-jwoGwns4MtiJQq0oalNNIQ-1; Thu, 13 Jan 2022 07:08:14 -0500 X-MC-Unique: jwoGwns4MtiJQq0oalNNIQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2564F10247B4; Thu, 13 Jan 2022 12:08:13 +0000 (UTC) Received: from work (unknown [10.40.194.158]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D203D7A8C7; Thu, 13 Jan 2022 12:08:11 +0000 (UTC) Date: Thu, 13 Jan 2022 13:08:07 +0100 From: Lukas Czerner To: Jon Hunter Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, linux-fsdevel@vger.kernel.org, "linux-tegra@vger.kernel.org" Subject: Re: [PATCH v3 12/13] ext4: switch to the new mount api Message-ID: <20220113120807.xlyg4wmbbhajuftu@work> References: <20211021114508.21407-1-lczerner@redhat.com> <20211021114508.21407-13-lczerner@redhat.com> <286d36c9-e9ab-b896-e23c-2a95c6385817@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <286d36c9-e9ab-b896-e23c-2a95c6385817@nvidia.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Jan 13, 2022 at 11:29:24AM +0000, Jon Hunter wrote: > Hi Lukas, > > On 21/10/2021 12:45, Lukas Czerner wrote: > > Add the necessary functions for the fs_context_operations. Convert and > > rename ext4_remount() and ext4_fill_super() to ext4_get_tree() and > > ext4_reconfigure() respectively and switch the ext4 to use the new api. > > > > One user facing change is the fact that we no longer have access to the > > entire string of mount options provided by mount(2) since the mount api > > does not store it anywhere. As a result we can't print the options to > > the log as we did in the past after the successful mount. > > > > Signed-off-by: Lukas Czerner > > > I have noticed the following error on -next on various ARM64 platforms that > we have ... > > ERR KERN /dev/mmcblk1: Can't open blockdev > > I have bisected this, to see where this was introduced and bisect is > pointing to this commit. I have not looked any further so far, but wanted to > see if you had any ideas/suggestions? Hi, this error does not come from the ext4, but probably rather from vfs. More specifically from get_tree_bdev() bdev = blkdev_get_by_path(fc->source, mode, fc->fs_type); if (IS_ERR(bdev)) { errorf(fc, "%s: Can't open blockdev", fc->source); return PTR_ERR(bdev); } I have no idea why this fails in your case. Do you know what kind of error it fails with? Any oher error or warning messages preceding the one you point out in the logs? I assume that this happens on mount and the device that you're trying to mount contains ext4 file system? Ext4 is not the only file system utilizing the new mount api, can you try the same with xfs on the device? Does this happen only on some specific devices? I see that the error is mentioning /dev/mmcblk1. Is it the case that it only affects MMC ? Does this happen when you try to mount a different type of block device with ext4 on it? Any specific mount options you're using? Is it rw mount? If so, any chance the device is read only? Do you have any way of reliably reproducing this? Thanks! -Lukas > > Cheers > Jon > > -- > nvpublic >