[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd6db786ff5758914c77add4d7a9391886038c84.camel@intel.com>
Date: Thu, 16 May 2019 00:29:15 +0000
From: "Verma, Vishal L" <vishal.l.verma@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>
CC: "cai@....pw" <cai@....pw>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
"Jiang, Dave" <dave.jiang@...el.com>,
"Busch, Keith" <keith.busch@...el.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"Weiny, Ira" <ira.weiny@...el.com>
Subject: Re: [RESEND PATCH] nvdimm: fix some compilation warnings
On Wed, 2019-05-15 at 17:26 -0700, Dan Williams wrote:
> On Wed, May 15, 2019 at 5:25 PM Verma, Vishal L
> <vishal.l.verma@...el.com> wrote:
> > On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote:
> > > > diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
> > > > index 4671776f5623..9f02a99cfac0 100644
> > > > --- a/drivers/nvdimm/btt.c
> > > > +++ b/drivers/nvdimm/btt.c
> > > > @@ -1269,11 +1269,9 @@ static int btt_read_pg(struct btt *btt,
> > > > struct bio_integrity_payload *bip,
> > > >
> > > > ret = btt_data_read(arena, page, off, postmap,
> > > > cur_len);
> > > > if (ret) {
> > > > - int rc;
> > > > -
> > > > /* Media error - set the e_flag */
> > > > - rc = btt_map_write(arena, premap,
> > > > postmap, 0, 1,
> > > > - NVDIMM_IO_ATOMIC);
> > > > + btt_map_write(arena, premap, postmap, 0,
> > > > 1,
> > > > + NVDIMM_IO_ATOMIC);
> > > > goto out_rtt;
> > >
> > > This doesn't look correct to me, shouldn't we at least be logging
> > > that
> > > the bad-block failed to be persistently tracked?
> >
> > Yes logging it sounds good to me. Qian, can you include this in your
> > respin or shall I send a fix for it separately (since we were always
> > ignoring the failure here regardless of this patch)?
>
> I think a separate fix for this makes more sense. Likely also needs to
> be a ratelimited message in case a storm of errors is encountered.
Yes good point on rate limiting - I was thinking WARN_ONCE but that
might mask errors for distinct blocks, but a rate limited printk should
work best. I'll prepare a patch.
Powered by blists - more mailing lists