On 05/22/2014 12:21 PM, Sascha Hauer wrote: > On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote: >> On 05/22/2014 09:30 AM, Sascha Hauer wrote: >>> Hi all, >>> >>> The wish to have persistent MMC block device names for passing a suitable >>> root=/dev/mmcblkX option came up several times already and has been discussed >>> at least in these threads: >>> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html >>> https://www.mail-archive.com/linux-mmc@xxxxxxxxxxxxxxx/msg22104.html >>> http://comments.gmane.org/gmane.linux.kernel.mmc/21519 >>> >>> Several patches have been proposed to nail the slot index to a known number. >>> Arguments against these patches were: >>> >>> - Use an initrd and locate the correct root device there >>> even Thomas who suggested this admitted this would be painful to do >>> - use root=UUID= or root=PARTUUID= >>> This generally works but has an important downside. With the UUID >>> approach devices which should boot from the internal eMMC may start >>> booting from an external SD slot when somebody deliberately inserts >>> a SD card with the same UUID. >>> >>> The following patches should have the technical issues fixed. It works >>> by counting the mmc aliases in the devicetree during initialization of >>> the mmc framework. Those slot numbers will never be assigned to other >>> hosts. >> >> Does it solve the following, which AFAIK has always been the primary >> argument against aligning block device IDs with controller IDs: >> >> - User inserts SD card into MMC controller ID (or alias) 1. >> - /dev/mmcblk1 now exists >> - Mount /dev/mmcblk1 on /mnt/tmp >> - User removes that SD card >> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted >> after the card removal. >> - User inserts SD card into MMC controller ID (or alias) 1. >> - /dev/mmcblkN (N is something other than 1) now exists >> >> Now, the block device ID must be != the original ID, since two block >> devices exist. > > No, it shouldn't solve that, but it's out of scope for this patch. All > it solves is to reliably find the rootfs. If the card containing your > rootfs is removed you are in trouble anyway and it won't help if it gets > the same mmcblkno once it's plugged again. For other devices which don't > contain the rootfs there are enough possibilities to find them in userspace. I don't think there should be any special cases for the root fs. I don't think the disadvantage of the UUID= or PARTUUID= issue you mention enough is really an issue in general. If it is for some platform, then the root fs should be cryto-signed and validated to prevent someone from using the wrong root fs. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
