This is the first completed effort to improve badblocks code to handle
multiple ranges in bad block table.
There is neither in-memory nor on-disk format change in this series, all
existing API and data structures are consistent. This series just only
improve the code algorithm to handle more corner cases, the interfaces
are same and consistency to all existing callers (md raid and nvdimm
The original motivation of the change is from the requirement from our
customer, that current badblocks routines don't handle multiple ranges.
For example if the bad block setting range covers multiple ranges from
bad block table, only the first two bad block ranges merged and rested
ranges are intact. The expected behavior should be all the covered
ranges to be handled.
All the patches are tested by modified user space code and the code
logic works as expected. Kernel space testing and debugging is on the
way while I am asking help for code review at the same time.
The whole change is divided into 6 patches to make the code review more
clear and easier. If people prefer, I'd like to post a single large
patch finally after the code review accomplished.
Thank you in advance for any review comment and suggestion.
Coly Li (6):
badblocks: add more helper structure and routines in badblocks.h
badblocks: add helper routines for badblock ranges handling
badblocks: improvement badblocks_set() for multiple ranges handling
badblocks: improve badblocks_clear() for multiple ranges handling
badblocks: improve badblocks_check() for multiple ranges handling
badblocks: switch to the improved badblock handling code
block/badblocks.c | 1591 ++++++++++++++++++++++++++++++-------
include/linux/badblocks.h | 32 +
2 files changed, 1332 insertions(+), 291 deletions(-)
On Wed, Mar 03, 2021 at 09:41:54AM +0000, ruansy.fnst(a)fujitsu.com wrote:
> > >
> > > if (dirty)
> > > __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> > I still think the __mark_inode_dirty should just be moved into the one
> > caller that needs it.
> I found that the dirty flag will be used in the next few lines, so I keep
> this function inside. If I move it outside, the drity flag should be passed
> in as well.
> @@ -774,6 +780,9 @@ static void *dax_insert_entry(struct xa_state *xas,
> if (dirty)
> xas_set_mark(xas, PAGECACHE_TAG_DIRTY);
> + if (cow)
> + xas_set_mark(xas, PAGECACHE_TAG_TOWRITE);
> return entry;
> So, may I ask what's your purpose for doing in that way?
Oh, true. We can't just move that out as the xas needs to stay