linux-ext4 - Re: [PATCH v3 12/13] ext4: switch to the new mount api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0535c04a-db7c-fa10-149e-91110eb18804@nvidia.com>
Date:   Thu, 13 Jan 2022 15:06:43 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     linux-ext4@...r.kernel.org, tytso@....edu,
        linux-fsdevel@...r.kernel.org,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v3 12/13] ext4: switch to the new mount api


On 13/01/2022 12:08, Lukas Czerner wrote:
> 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 <lczerner@...hat.com>
>>
>>
>> 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);
>          }

Yes, obviously this warning has been there for a while but only seen 
after this change was made.

> 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?

No only this one.

> 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?

This is happening on a board in the test farm and so not easy to 
reformat. Looking some more /dev/mmcblk1 is not a valid device, I only 
see /dev/mmcblk0 from the bootlogs on this board. Hmmm, OK I will have 
to take a closer look to see where this is coming from.

> 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?

So far I have only seen this with the MMC, but I have not tried others.
> Any specific mount options you're using? Is it rw mount? If so, any
> chance the device is read only?

Interestingly we are booting with NFS and so not mounting any MMC by 
default.

> Do you have any way of reliably reproducing this?

I see it on every boot and this is causing a warning test to fail. This 
is a new failure and I have not seen this before. I don't see it on the 
mainline with the same hardware, only on -next.

Cheers
Jon

-- 
nvpublic