Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

[Stefan Haberland]

Am 05.05.20 um 14:44 schrieb Christoph Hellwig:
> On Mon, May 04, 2020 at 10:45:33AM +0200, Stefan Haberland wrote:
>>> findthe corresponding device for example. Not sure if this is that easy.
>> I did some additional research on this.
>> What I could imagine:
>>
>> The gendisk->private_data pointer currently contains a pointer to
>> the dasd_devmap structure. This one is also reachable by iterating
>> over an exported dasd_hashlist.
>> So I could export the dasd_hashlist symbol, iterate over it and try
>> to find the dasd_devmap pointer I have from the gendisk->private_data
>> pointer.
>> This would ensure that the gendisk belongs to the DASD driver and I
>> could use the additional information that is somehow reachable through
>> the gendisk->private_data pointer.
>>
>> But again, I am not sure if this additional code and effort is needed.
>> From my point of view checking the gendisk->major for DASD_MAJOR is
>> OK to ensure that the device belongs to the DASD driver.
> With CONFIG_DEBUG_BLOCK_EXT_DEVT you can't rely on major numbers.

OK, thanks for the hint.I did not have this in mind. And I still have
to look up how this is working at all.
But isn't this only a real issue for devices with more than 16 minors
or partitions? So it should not be a problem for DASDs with our limit
of 3 partitions and the fixed amount of minors, right?

Just tested with CONFIG_DEBUG_BLOCK_EXT_DEVT enabled and about 1000
unlabeled devices. Did not see an issue.

While I see the SCSI devices with MAJOR 259 and quite a random MINOR
all the DASD devices keep their MAJOR 94 and ascending MINOR.

>
> And compared to all the complications I think the biodasdinfo method
> is the least of all those evils.

Are you talking about your first patch suggestion?Then I disagree.
I still do not like to force the driver to be built in if there is an
alternative.

If the major number is an issue also for DASD device than I prefer
to implement the devmap lookup to ensure that the device belongs to
the DASD driver.

But I am open to alternatives as well.

Side note: I am planning to deprecate the implicit DASD partition for
unlabeled devices so we might get rid of this stuff at all at some point
in time. We just have to discuss how this might be done properly.


> Jens, any opinion?