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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 13 Jan 2022 16:10:29 +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 15:06, Jon Hunter wrote:
> 
> 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.


OK, I see what is happening. It appears that our test harness always 
tries to mount a device called /dev/mmcblk1. Prior to this change there 
was not kernel error generated and looking at the logs I would see ...

mount: /mnt: special device /dev/mmcblk1 does not exist.

Following this change, now a kernel warning is generated and I see ...

[  137.078994] /dev/mmcblk1: Can't open blockdev
mount: /mnt: special device /dev/mmcblk1 does not exist.

So there is a change in behaviour but at the same time the error looks 
correct. So sorry for the false-positive.

Cheers
Jon



-- 
nvpublic