On Fri, Aug 12, 2016 at 2:35 PM, Bart Van Assche
[off-list ref] wrote:

On 08/12/2016 02:29 PM, Dan Williams wrote:

quoted

...or, for that matter, any block device driver on a bus that supports
hotplug?

In 4.8 Jens merged the following fix for a crash that was triggered by
repeatedly reconfiguring a libnvdimm namespace causing it to destroy
and create disks (rapid hotplug).

    df08c32ce3be block: fix bdi vs gendisk lifetime mismatch

At the time I realized that the fix only addressed block device
drivers that use a dynamic devt and theorized that we still have a
problem with static devt drivers like sd.  Lo and behold Dave was
bitten by this exact scenario:

 WARNING: CPU: 23 PID: 9672 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
 sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:16'
 [..]
 CPU: 23 PID: 9672 Comm: kworker/u66:2 Tainted: G          I
4.6.3-300.fc24.x86_64 #1
[ ... ]

Before spending effort trying to flush the destruction of old bdi
instances before new ones are registered, is it rather time to
complete the conversion of sd to only use dynamically allocated devt?

Hello Dan,

Sorry but I'm not familiar with dynamically allocated devt's. But I would
appreciate it if Dave could test the following patch: "Fix an sd
reregistration race, v5" (https://patchwork.kernel.org/patch/9178155/).

Hi Bart,

See the BLOCK_EXT_MAJOR paths in blk_{alloc|free}_devt() and the
bdi_register_owner() helper. I think bdi_register_owner() addresses
this problem in a way that easier to comprehend than attempting
heroics in scsi to manipulate reference counts as that patch is doing.
If sd can tolerate being dynamic all the time then perhaps we can
abandon static block device devts across the board?  The concern is if
we have legacy userspace that is not prepared for a scsi disk to be at
a major number other than 8.