All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Pratyush Yadav <p.yadav@ti.com>,
	 Michael Walle <michael@walle.cc>,
	MTD Maling List <linux-mtd@lists.infradead.org>,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH] mtd: Introduce an expert mode for forensics and debugging purposes
Date: Thu, 27 Jan 2022 12:07:31 +0100	[thread overview]
Message-ID: <CAMuHMdW0hKqk8aGiNy1Pd50aTu_rb_ewdiV9GXTkPJOm=zA+HA@mail.gmail.com> (raw)
In-Reply-To: <20220127114647.0ec44ced@xps13>

Hi Miquel,

On Thu, Jan 27, 2022 at 11:46 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
> geert@linux-m68k.org wrote on Mon, 10 Jan 2022 14:15:27 +0100:
> > On Thu, Nov 18, 2021 at 12:47 PM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> > > When developping NAND controller drivers or when debugging filesystem
> > > corruptions, it is quite common to need hacking locally into the
> > > MTD/NAND core in order to get access to the content of the bad
> > > blocks. Instead of having multiple implementations out there let's
> > > provide a simple yet effective specific MTD-wide debugfs entry to fully
> > > disable these checks on purpose.
> > >
> > > A warning is added to inform the user when this mode gets enabled.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >
> > Thanks for your patch, which is now commit 67b967ddd93d0ed5 ("mtd:
> > Introduce an expert mode for forensics and debugging purposes")
> > in mtd/next.
> >
> > > --- a/drivers/mtd/mtdcore.c
> > > +++ b/drivers/mtd/mtdcore.c
> > > @@ -2365,6 +2365,14 @@ static struct backing_dev_info * __init mtd_bdi_init(const char *name)
> > >         return ret ? ERR_PTR(ret) : bdi;
> > >  }
> > >
> > > +char *mtd_expert_analysis_warning =
> >
> > const
> >
> > > +       "Bad block checks have been entirely disabled.\n"
> > > +       "This is only reserved for post-mortem forensics and debug purposes.\n"
> > > +       "Never enable this mode if you do not know what you are doing!\n";
> > > +EXPORT_SYMBOL_GPL(mtd_expert_analysis_warning);
> >
> > Shouldn't this depend on CONFIG_DEBUG_FS?
> >
> > > +bool mtd_expert_analysis_mode;
> > > +EXPORT_SYMBOL_GPL(mtd_expert_analysis_mode);
> >
> > Do you really need to export these two symbols?
> >
> > > +
> > >  static struct proc_dir_entry *proc_mtd;
> > >
> > >  static int __init init_mtd(void)
> > =
> > > --- a/drivers/mtd/nand/core.c
> > > +++ b/drivers/mtd/nand/core.c
> > > @@ -21,6 +21,9 @@
> > >   */
> > >  bool nanddev_isbad(struct nand_device *nand, const struct nand_pos *pos)
> > >  {
> > > +       if (WARN_ONCE(mtd_expert_analysis_mode, mtd_expert_analysis_warning))
> > > +               return 0;
> > > +
> > >         if (nanddev_bbt_is_initialized(nand)) {
> > >                 unsigned int entry;
> > >                 int status;
> > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> > > index 3d6c6e880520..b3a9bc08b4bb 100644
> > > --- a/drivers/mtd/nand/raw/nand_base.c
> > > +++ b/drivers/mtd/nand/raw/nand_base.c
> > > @@ -321,6 +321,9 @@ static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs)
> > >         if (nand_region_is_secured(chip, ofs, mtd->erasesize))
> > >                 return -EIO;
> > >
> > > +       if (WARN_ONCE(mtd_expert_analysis_mode, mtd_expert_analysis_warning))
> > > +               return 0;
> > > +
> > >         if (chip->legacy.block_bad)
> > >                 return chip->legacy.block_bad(chip, ofs);
> > >
> > > diff --git a/drivers/mtd/nand/raw/nand_bbt.c b/drivers/mtd/nand/raw/nand_bbt.c
> > > index b7ad030225f8..ab630af3a309 100644
> > > --- a/drivers/mtd/nand/raw/nand_bbt.c
> > > +++ b/drivers/mtd/nand/raw/nand_bbt.c
> > > @@ -1455,6 +1455,9 @@ int nand_isbad_bbt(struct nand_chip *this, loff_t offs, int allowbbt)
> > >         pr_debug("nand_isbad_bbt(): bbt info for offs 0x%08x: (block %d) 0x%02x\n",
> > >                  (unsigned int)offs, block, res);
> > >
> > > +       if (WARN_ONCE(mtd_expert_analysis_mode, mtd_expert_analysis_warning))
> > > +               return 0;
> > > +
> >
> > These are all the same.
> >
> > What about letting drivers/mtd/mtdcore.c export a simple function
> > mtd_check_expert_analysis_mode() that calls the WARN_ONCE(...) if
> > CONFIG_DEBUG_FS=y, else providing a dummy?
> > The backtrace will identify the caller anyway.
>
> I took the time to address your comments. You're right a single exported
> function is better.
>
> However I don't see the need for a CONFIG_DEBUG_FS check here, if unset
> the boolean will stay false forever, I believe we don't need to bother
> with it.

If CONFIG_DEBUG_FS=n, there is no need for the code or the export,
so the check can become a dummy.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-01-27 11:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 11:46 [PATCH] mtd: Introduce an expert mode for forensics and debugging purposes Miquel Raynal
2021-12-03 13:37 ` Miquel Raynal
2022-01-10 13:15 ` Geert Uytterhoeven
2022-01-10 14:41   ` Miquel Raynal
2022-01-10 14:57     ` Geert Uytterhoeven
2022-01-10 15:01       ` Miquel Raynal
2022-01-27 10:46   ` Miquel Raynal
2022-01-27 11:07     ` Geert Uytterhoeven [this message]
2022-01-27 11:18       ` Miquel Raynal
2022-01-27 11:57         ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdW0hKqk8aGiNy1Pd50aTu_rb_ewdiV9GXTkPJOm=zA+HA@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.