linux-kernel - Re: Re : Query on UFS Lun detection

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] [day] [month] [year] [list]

Date:   Thu, 10 Jun 2021 07:51:58 -0700
From:   Rob Clark <robdclark@...il.com>
To:     vhiren@...eaurora.com
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        adrian.hunter@...el.com, Rob Herring <robh+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Asutosh Das <asutoshd@...eaurora.org>, stummala@...eaurora.org,
        sayalil@...eaurora.org, rampraka@...eaurora.org,
        vbadigan@...eaurora.org, Stephen Boyd <sboyd@...nel.org>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        linux-mmc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Andy Gross <agross@...nel.org>,
        linux-mmc-owner@...r.kernel.org, nitirawa@...eaurora.org
Subject: Re: Re : Query on UFS Lun detection

On Thu, Jun 10, 2021 at 6:28 AM <vhiren@...eaurora.com> wrote:
>
> Hi Community,
>
> We are using UFS as a boot device, and we encountered an error,
> mentioned below while booting through UFS.
>
>
> APPS Crash - Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(8,7)
>
> Here in Kernel command line we are passing "root=sda7", this is our
> Filesystem partition to be mounted.
>
> While debugging the same we observed the partition which is suppose to
> be mounted as Filesystem is not enumerated  itself.
> The reason behind not enumerating of partition is, the other Lun got
> detected first instead of one which is having FS partition.

Use the UUID or PARTUUID instead, ie:

  root=UUID=13846802-672b-4a5d-9f0a-22d13957add3

(but you'd have to check the actual UUID of your partition with a tool
like blkid

BR,
-R

> We are using async probe, hence we know the detection will happen in
> async way,
>
>
> In working case :  it looks like below
>
> sd 0:0:0:0: sda1 sda2 sda3 sda4 …..sda8
>
> sd 0:0:0:1: sdb1 sdb2
> Here, sd 0:0:0:0 Lun got detected first and enumerated as "sdaN", we
> have FS partition as "sda7" and so we don’t see above mentioned error.
>
>
> In non working case : it looks like below
>
> sd 0:0:0:0: sdb1 sdb2 sdb3 sdb4 …..sdb8
>
> sd 0:0:0:1: sda1 sda2
> Here, sd 0:0:0:1 Lun got detected first and enumerated as "sdaN" but we
> don’t have FS partition in this Lun. Instead FS partition now became
> "sdb7".
>
>
> Observation here is, which ever Lun gets detected first it will have
> "sda" enumeration and so on.
> However, sdx’s driver scsi/sd.c uses async probe to improve performance,
> meaning sdx disks are created in parallel. Whoever calls
> device_add_disk() first becomes sda, the next become sdb….
>
>
> Is there any way, where we can fix this in the Lun detection part of
> code?
>
> Thank You,
> Regards,
> Hiren Gohel