Hello, I tried my best to be concise. It's my first time reaching out to a maintainer so if this is not the proper channel for this type of thing please correct me. I'm trying to learn about device drivers from https://lwn.net/Kernel/LDD3/, and I read that a large-enough requested minor range might spill over to the next major number when using register_chrdev_region (chapter 3 page 45) I decided to verify this claim on a toy module (basic c sample module and makefile): https://github.com/cdhg/module-minor-spill The code requests 2 devices starting from the last available minor, which overflows by one. The module will use alloc_chrdev_region or register_chrdev_region depending on whether 'alloc' was #defined. register_chrdev_region just works, and I can see two major entries in /proc/devices for "mydevice" (with the code above, that would be majors 400 and 401 if available). The unregister code cleanly removes those two entries as well. alloc_chrdev_region, however, fails on my recent (5.4) kernel with: CHRDEV "mydevice" minor range requested (1048575-1048576) is out of range of maximum range (0-1048575) for a single major Which led me to this patch from just last year: https://lore.kernel.org/patchwork/patch/1042784/ If I'm reading this correctly, the patch claims that register_chrdev_region was already doing such a check, so it would make sense to add the same check to alloc_chrdev_region via __register_chrdev_region. But register_chrdev_region seems to handle this cleanly, as the book I'm reading suggests. I don't understand why alloc_chrdev_region was modified to fail then. I tried on an earlier kernel (4.19) that I believe doesn't have this patch, and the same call to alloc_chrdev_region succeeded. However, I did notice only one major appears on /proc/devices and that unregistering does not seem to make the entry go away. So perhaps that was already broken in another way? Are these differences in behavior intentional? It almost seems like the above patch introduced a bug (or partially fixed an older bug) but I suppose it's likely that I just misunderstand something. I also suppose nobody's exercising the overflowing behavior so it's likely nobody has cared even if it was a real bug. At least the current behavior fails which seems cleaner than passing and not letting me unregister later. But register_chrdev_region just works everywhere, so this felt like a bug. I wasn't able to find any reports about this either. Thanks, -Cesar
