From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Zijun Hu <zijun_hu@icloud.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
Zijun Hu <zijun.hu@oss.qualcomm.com>
Subject: Re: [PATCH RFC] char: misc: Enforce simple minor space division
Date: Tue, 24 Jun 2025 16:50:30 +0100 [thread overview]
Message-ID: <2025062445-procedure-latch-9421@gregkh> (raw)
In-Reply-To: <20250620-rfc_miscdev-v1-1-fda25d502a37@oss.qualcomm.com>
On Fri, Jun 20, 2025 at 10:53:32PM +0800, Zijun Hu wrote:
> From: Zijun Hu <zijun.hu@oss.qualcomm.com>
>
> Enforce simple minor space division related to macro MISC_DYNAMIC_MINOR
> defined as 255 currently:
>
> < 255 : Fixed minor codes
> == 255 : Indicator to request dynamic minor code
> > 255 : Dynamic minor codes requested
Is this the rule today? If so, does the now-added tests we have for
misc device properly test for this?
> This enforcing division also solves misc_register() reentry issue below:
>
> // Suppose both static @dev_A and @dev_B want to request dynamic minors.
> @dev_A.minor(255) @dev_B.minor(255)
>
> // Register @dev_A then de-register it.
> @dev_A.minor(255) -> registered -> @dev_A.minor(500) -> de-registered
> -> @dev_A.minor(500)
>
> // Register @dev_B
> @dev_B.minor(255) -> registered -> @dev_B.minor(500)
>
> // Register @dev_A again
> @dev_A.minor(500) -> encounter -EBUSY error since @dev_B has got 500.
Does this ever really happen?
And with the recent changes in the last dev cycle in this code area, is
it still an issue?
> Side effects:
> It will be refused to register device whose fixed minor > 255.
Do we have any in-kernel users that are > 255?
thanks,
greg k-h
next prev parent reply other threads:[~2025-06-24 15:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 14:53 [PATCH RFC] char: misc: Enforce simple minor space division Zijun Hu
2025-06-24 15:50 ` Greg Kroah-Hartman [this message]
2025-06-25 23:29 ` Zijun Hu
2025-06-26 12:37 ` Thadeu Lima de Souza Cascardo
2025-06-26 14:54 ` Zijun Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025062445-procedure-latch-9421@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=zijun.hu@oss.qualcomm.com \
--cc=zijun_hu@icloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).