On Sun, 27 Jul 2025 at 18:29, Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > It would be great if Klara's patch at > https://lore.kernel.org/lkml/20250725164334.9606-1-klarasmodin@xxxxxxxxx/ > could follow just after this pull: I had been bisecting -next to find out > why "losetup /dev/loop0 tmpfsfile" was failing, and that patch fixes it - > and presumably other odd failures for anyone without BLK_DEV_INTEGRITY=y. Bah. I *hate* this "call blk_get_meta_cap() first" approach. There is absolutely *NO* way it is valid for that strange specialized ioctl to override any proper traditional ioctl numbers, so calling that code first and relying on magic error numbers is simply not acceptable. I'm going to fix this in my merge by just putting the call to blk_get_meta_cap() inside the "default:" case for *after* the other ioctl numbers have been checked. Please don't introduce new "magic error number" logic in the ioctl path. The fact that the traditional case of "I don't support this" is ENOTTY should damn well tell everybody that we have about SIX DECADES of problems in this area. Don't repeat that mistake. And don't let new random unimportant ioctls *EVER* override the normal default ones. Linus
