Device "minor overflow" behavior differences in register_chrdev_region vs alloc_chrdev_region

Device "minor overflow" behavior differences in register_chrdev_region vs alloc_chrdev_region

[César DH]

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