Message ID | 20231224002820.20234-1-colyli@suse.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | badblocks: avoid checking invalid range in badblocks_check() | expand |
> 2023年12月24日 08:28,Coly Li <colyli@suse.de> 写道: > > If prev_badblocks() returns '-1', it means no valid badblocks record > before the checking range. It doesn't make sense to check whether > the input checking range is overlapped with the non-existed invalid > front range. > > This patch checkes whether 'prev >= 0' is true before calling > overlap_front(), to void such invalid operations. > > Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") > Reported-and-tested-by: Ira Weiny <ira.weiny@intel.com> > Signed-off-by: Coly Li <colyli@suse.de> > Link: https://lore.kernel.org/nvdimm/3035e75a-9be0-4bc3-8d4a-6e52c207f277@leemhuis.info/ > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Geliang Tang <geliang.tang@suse.com> > Cc: Hannes Reinecke <hare@suse.de> > Cc: Jens Axboe <axboe@kernel.dk> > Cc: NeilBrown <neilb@suse.de> > Cc: Vishal L Verma <vishal.l.verma@intel.com> > Cc: Xiao Ni <xni@redhat.com> > --- > block/badblocks.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) Hi Jens, Is it possible to take this fix into 6.7 still? Thanks in advance. Coly Li [snipped]
On Sun, 24 Dec 2023 08:28:20 +0800, Coly Li wrote: > If prev_badblocks() returns '-1', it means no valid badblocks record > before the checking range. It doesn't make sense to check whether > the input checking range is overlapped with the non-existed invalid > front range. > > This patch checkes whether 'prev >= 0' is true before calling > overlap_front(), to void such invalid operations. > > [...] Applied, thanks! [1/1] badblocks: avoid checking invalid range in badblocks_check() commit: 146e843f6b09271233c021b1677e561b7dc16303 Best regards,
On 12/23/23 5:32 PM, Coly Li wrote: >> 2023?12?24? 08:28?Coly Li <colyli@suse.de> ??? >> >> If prev_badblocks() returns '-1', it means no valid badblocks record >> before the checking range. It doesn't make sense to check whether >> the input checking range is overlapped with the non-existed invalid >> front range. >> >> This patch checkes whether 'prev >= 0' is true before calling >> overlap_front(), to void such invalid operations. >> >> Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") >> Reported-and-tested-by: Ira Weiny <ira.weiny@intel.com> >> Signed-off-by: Coly Li <colyli@suse.de> >> Link: https://lore.kernel.org/nvdimm/3035e75a-9be0-4bc3-8d4a-6e52c207f277@leemhuis.info/ >> Cc: Dan Williams <dan.j.williams@intel.com> >> Cc: Geliang Tang <geliang.tang@suse.com> >> Cc: Hannes Reinecke <hare@suse.de> >> Cc: Jens Axboe <axboe@kernel.dk> >> Cc: NeilBrown <neilb@suse.de> >> Cc: Vishal L Verma <vishal.l.verma@intel.com> >> Cc: Xiao Ni <xni@redhat.com> >> --- >> block/badblocks.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) > > Hi Jens, > > Is it possible to take this fix into 6.7 still? Thanks in advance. Yep, we're still a few weeks out, so not a problem.
> 2023年12月24日 09:38,Jens Axboe <axboe@kernel.dk> 写道: > > On 12/23/23 5:32 PM, Coly Li wrote: >>> 2023?12?24? 08:28?Coly Li <colyli@suse.de> ??? >>> >>> If prev_badblocks() returns '-1', it means no valid badblocks record >>> before the checking range. It doesn't make sense to check whether >>> the input checking range is overlapped with the non-existed invalid >>> front range. >>> >>> This patch checkes whether 'prev >= 0' is true before calling >>> overlap_front(), to void such invalid operations. >>> >>> Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") >>> Reported-and-tested-by: Ira Weiny <ira.weiny@intel.com> >>> Signed-off-by: Coly Li <colyli@suse.de> >>> Link: https://lore.kernel.org/nvdimm/3035e75a-9be0-4bc3-8d4a-6e52c207f277@leemhuis.info/ >>> Cc: Dan Williams <dan.j.williams@intel.com> >>> Cc: Geliang Tang <geliang.tang@suse.com> >>> Cc: Hannes Reinecke <hare@suse.de> >>> Cc: Jens Axboe <axboe@kernel.dk> >>> Cc: NeilBrown <neilb@suse.de> >>> Cc: Vishal L Verma <vishal.l.verma@intel.com> >>> Cc: Xiao Ni <xni@redhat.com> >>> --- >>> block/badblocks.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> Hi Jens, >> >> Is it possible to take this fix into 6.7 still? Thanks in advance. > > Yep, we're still a few weeks out, so not a problem. Jes and Ira, Thank you all for fast response during holidays. Happy holidays and merry Christmas! Coly Li
diff --git a/block/badblocks.c b/block/badblocks.c index fc92d4e18aa3..db4ec8b9b2a8 100644 --- a/block/badblocks.c +++ b/block/badblocks.c @@ -1312,12 +1312,14 @@ static int _badblocks_check(struct badblocks *bb, sector_t s, int sectors, prev = prev_badblocks(bb, &bad, hint); /* start after all badblocks */ - if ((prev + 1) >= bb->count && !overlap_front(bb, prev, &bad)) { + if ((prev >= 0) && + ((prev + 1) >= bb->count) && !overlap_front(bb, prev, &bad)) { len = sectors; goto update_sectors; } - if (overlap_front(bb, prev, &bad)) { + /* Overlapped with front badblocks record */ + if ((prev >= 0) && overlap_front(bb, prev, &bad)) { if (BB_ACK(p[prev])) acked_badblocks++; else
If prev_badblocks() returns '-1', it means no valid badblocks record before the checking range. It doesn't make sense to check whether the input checking range is overlapped with the non-existed invalid front range. This patch checkes whether 'prev >= 0' is true before calling overlap_front(), to void such invalid operations. Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") Reported-and-tested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Coly Li <colyli@suse.de> Link: https://lore.kernel.org/nvdimm/3035e75a-9be0-4bc3-8d4a-6e52c207f277@leemhuis.info/ Cc: Dan Williams <dan.j.williams@intel.com> Cc: Geliang Tang <geliang.tang@suse.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: NeilBrown <neilb@suse.de> Cc: Vishal L Verma <vishal.l.verma@intel.com> Cc: Xiao Ni <xni@redhat.com> --- block/badblocks.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)