On Wed, Dec 23, 2015 at 12:32 PM, Verma, Vishal L <vishal.l.verma@xxxxxxxxx> wrote: > On Wed, 2015-12-23 at 12:28 -0800, Dan Williams wrote: >> On Sun, Dec 20, 2015 at 1:18 AM, <vishal@xxxxxxxxxx> wrote: >> > From: Vishal Verma <vishal.l.verma@xxxxxxxxx> >> > >> > Enable the gendisk badblocks feature for pmem namespaces. >> > If the pmem namespace being created has any known poison associated >> > with >> > its physical address space, convert the poison ranges to bad sectors >> > exposed using the badblocks interface. >> > >> > Signed-off-by: Vishal Verma <vishal.l.verma@xxxxxxxxx> >> > --- >> > drivers/nvdimm/pmem.c | 124 >> > ++++++++++++++++++++++++++++++++++++++++++++++++++ >> > 1 file changed, 124 insertions(+) >> > >> > diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c >> > index 8ee7989..462570f 100644 >> > --- a/drivers/nvdimm/pmem.c >> > +++ b/drivers/nvdimm/pmem.c >> [..] >> > @@ -196,6 +311,15 @@ static int pmem_attach_disk(struct device *dev, >> > set_capacity(disk, (pmem->size - pmem->data_offset) / 512); >> > pmem->pmem_disk = disk; >> > >> > + ret = disk_alloc_badblocks(disk); >> > + if (ret) >> > + return ret; >> >> I think we should skip allocating a bad block list in the case we find >> no poison. Then we can do a simple "if (disk->bb)" to check if there >> are any bad blocks. > > Sounds good - I'll move this allocation into the (what will be a core) > routine that traverses the list, and make it such that we allocate > disk->bb iff a poison entry is found for _this_ pmem range. > > It will mean a check at every list node, but that shouldn't matter as > this is just init-time overhead. > ...or free it on "no poison found". -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
