On 08/01/2016 01:54 AM, Dan Williams wrote:

On Sun, Jul 31, 2016 at 10:19 AM, yizhan [off-list ref] wrote:

quoted

On 07/30/2016 11:52 PM, Dan Williams wrote:

quoted

On Thu, Jul 28, 2016 at 8:50 AM, Dan Williams [off-list ref]
wrote:

quoted

[ adding linux-block ]

On Wed, Jul 27, 2016 at 8:20 PM, Yi Zhang [off-list ref] wrote:

quoted

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

Thank you!

quoted

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

This test is racing block device registration versus teardown.  These
messages are expected and are likely coming from the block queue
percpu ref being marked dead while the partition scan runs.  When this
happens blk_queue_enter() in generic_make_request() returns errors for
every new I/O submission while blk_cleanup_queue() runs.

OK, thanks for your explanation.

Best Regards
Yi Zhang