On 07/30/2016 11:52 PM, Dan Williams wrote:
On Thu, Jul 28, 2016 at 8:50 AM, Dan Williams <[email protected]> wrote:
[ adding linux-block ]

On Wed, Jul 27, 2016 at 8:20 PM, Yi Zhang <[email protected]> wrote:
Hello everyone

Could you help check this issue, thanks.

Steps I used:
1. Reserve 4*8G of memory for pmem by add kernel parameter "memmap=8G!4G 
memmap=8G!12G memmap=8G!20G memmap=8G!28G"
2. Execute below script
#!/bin/bash
pmem_btt_switch() {
         sector_size_list="512 520 528 4096 4104 4160 4224"
         for sector_size in $sector_size_list; do
                 ndctl create-namespace -f -e namespace${1}.0 --mode=sector -l 
$sector_size
                 ndctl create-namespace -f -e namespace${1}.0 --mode=raw
         done
}

for i in 0 1 2 3; do
         pmem_btt_switch $i &
done
Thanks for the report.  This looks like del_gendisk() frees the
previous usage of the devt before the bdi is unregistered.  This
appears to be a general problem with all block drivers, not just
libnvdimm, since blk_cleanup_queue() is typically called after
del_gendisk().  I.e. it will always be the case that the bdi
registered with the devt allocated at add_disk() will still be alive
when del_gendisk()->disk_release() frees the previous devt number.

I *think* the path forward is to allow the bdi to hold a reference
against the blk_alloc_devt() allocation until it is done with it.  Any
other ideas on fixing this object lifetime problem?
Does the attached patch solve this for you?
Hi Dan
This patch works and the issue cannot be reproduced after several times' test, thanks

Another thing is during the bug verifying, I found below error message, could you check whether it is reasonable:
[  150.464620] Dev pmem1: unable to read RDB block 0
[  150.486897]  pmem1: unable to read partition table
[  150.486901] pmem1: partition table beyond EOD, truncated
[ 151.133287] Buffer I/O error on dev pmem3, logical block 2, async page read [ 151.164620] Buffer I/O error on dev pmem3, logical block 2, async page read


Best Regards
Yi Zhang

_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to