linux-kernel - Re: [PATCH/RFC -nxt] mtd_blkdevs: Set GENHD_FL_NO

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]

Message-ID: <CAMuHMdV7PbXwuBNBn4TtjXUvjzWiOQTYoOJTEACyN-k4DUj5-Q@mail.gmail.com>
Date:   Wed, 1 Dec 2021 11:08:40 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Michael Walle <michael@...le.cc>,
        Pratyush Yadav <p.yadav@...com>,
        MTD Maling List <linux-mtd@...ts.infradead.org>,
        linux-block@...r.kernel.org,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH/RFC -nxt] mtd_blkdevs: Set GENHD_FL_NO_PART

Hi Christoph,

On Wed, Dec 1, 2021 at 8:23 AM Christoph Hellwig <hch@....de> wrote:
> On Tue, Nov 30, 2021 at 05:23:46PM +0100, Geert Uytterhoeven wrote:
> > When DT declares the partitions of an spi-nor device using
> > "fixed-partitions", the individual mtdblockN partitions are now scanned
> > for partitition tables, which should not happen.
> >
> > Fix this by setting the GENHD_FL_NO_PART flag in the MTD block layer
> > interface.
> >
> > Fixes: 1ebe2e5f9d68e94c ("block: remove GENHD_FL_EXT_DEVT")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > ---
> > Seen with e.g. arch/arm/boot/dts/r8a7791-koelsch.dts.
> > I only noticed because I have debug code to measure QSPI performance,
> > which informed me about 8 x 512 bytes being read from each partition
> > detected.
> >
> > RFC as I'm not sure this is correct in all cases.
> > I did verify that in the absence of "fixed-partitions", the spi-nor
> > device is not scanned for partitions before and after commit
> > 1ebe2e5f9d68e94c.
>
> As far as I can tell mtd fixed partitions have nothing to do with
> the block layer concept of partitions.  What kind of behavior change
> did you see?

After the aforementioned commit, 8 x 512 bytes are being read from
the start of each partition described by "fixed-partitions".
Dmesg difference with debug print added to spi_nor_spimem_read_data():

  renesas_spi e6b10000.spi: registered master spi0
  spi spi0.0: setup mode 3, 8 bits/w, 30000000 Hz max --> 0
  spi-nor spi0.0: s25fl512s (65536 Kbytes)
  3 fixed-partitions partitions found on MTD device spi0.0
  Creating 3 MTD partitions on "spi0.0":
  0x000000000000-0x000000080000 : "loader"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 0 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 512 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 1024 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 1536 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 2048 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 2560 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 3072 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 3584 len 512
  0x000000080000-0x000000600000 : "user"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 524288 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 524800 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 525312 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 525824 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 526336 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 526848 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 527360 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 527872 len 512
  0x000000600000-0x000004000000 : "flash"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6291456 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6291968 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6292480 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6292992 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6293504 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6294016 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6294528 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6295040 len 512
  renesas_spi e6b10000.spi: registered child spi0.0
  renesas_spi e6b10000.spi: probed

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds