From: Ewan D. Milne on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2504#note_1438567452 I presented about this at LSF/MM in May. The problem basically is that Bart Van Assche's change to use the driver core for asynchronous SCSI disk ("sd") probing had a side effect that resulted in the previously (mostly) consistent ordering of minor device number assignments to become unpredictable. commit f049cf1a7b6737c75884247c3f6383ef104d255a Author: Bart Van Assche <bvanassche@xxxxxxx> Date: Tue Apr 30 14:39:18 2019 -0700 scsi: sd: Rely on the driver core for asynchronous probing drivers/scsi/sd.c used to assign minor numbers in the synchronous probing path, and then use its own asynchronous ("..part2") mechanism to issue the commands to obtain the device attributes. Now that everything is asynchronous with the above change, the minor # assignment is too. This is causing major problems for our customers. We had a discussion at LSF/MM, and, as I expected, they rejected doing anything about this. Their response was to "use udev". The problem is that the behavior change is a perceived longstanding behavior regression in RHEL 9. And there are cases (e.g. w/virtualization) where there were implicit expectations about how device numbering would be done. Also, subsequent *synchronous* calls to scsi_add_device() e.g. from the mpt3sas driver, do not result in ordered minor number assignments, which breaks LSI's functionality. We do document in the RHEL documentation that customers are supposed to use persistent device names (e.g. /dev/by-id/xxx) rather that minor numbers, especially for SAN- attached devices, but the unpredictability of minor # (/dev/sda, /dev/sdb) now happens even for *locally attached disks*. Hence, the module option to force synchronous probing for people who really need it. I do welcome any discussion on the desirability of a RHEL-only change, though. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
