summaryrefslogtreecommitdiffstats
path: root/net/netlink/genetlink.c
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2016-10-24 14:40:02 +0200
committerDavid S. Miller <davem@davemloft.net>2016-10-27 16:16:09 -0400
commita07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5 (patch)
tree52d22e6ed0079bb5a78d610c2ee33a783f070553 /net/netlink/genetlink.c
parentc90c39dab3e02ce45427a214746711f33ad13be6 (diff)
downloadlinux-a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5.tar.gz
linux-a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5.tar.bz2
linux-a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5.zip
genetlink: no longer support using static family IDs
Static family IDs have never really been used, the only use case was the workaround I introduced for those users that assumed their family ID was also their multicast group ID. Additionally, because static family IDs would never be reserved by the generic netlink code, using a relatively low ID would only work for built-in families that can be registered immediately after generic netlink is started, which is basically only the control family (apart from the workaround code, which I also had to add code for so it would reserve those IDs) Thus, anything other than GENL_ID_GENERATE is flawed and luckily not used except in the cases I mentioned. Move those workarounds into a few lines of code, and then get rid of GENL_ID_GENERATE entirely, making it more robust. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/netlink/genetlink.c')
-rw-r--r--net/netlink/genetlink.c37
1 files changed, 22 insertions, 15 deletions
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 01291b7a27bb..f19ec969edee 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -349,8 +349,6 @@ static int genl_validate_ops(const struct genl_family *family)
*
* Registers the specified family after validating it first. Only one
* family may be registered with the same family name or identifier.
- * The family id may equal GENL_ID_GENERATE causing an unique id to
- * be automatically generated and assigned.
*
* The family's ops array must already be assigned, you can use the
* genl_register_family_with_ops() helper function.
@@ -359,13 +357,7 @@ static int genl_validate_ops(const struct genl_family *family)
*/
int __genl_register_family(struct genl_family *family)
{
- int err = -EINVAL, i;
-
- if (family->id && family->id < GENL_MIN_ID)
- goto errout;
-
- if (family->id > GENL_MAX_ID)
- goto errout;
+ int err, i;
err = genl_validate_ops(family);
if (err)
@@ -378,8 +370,27 @@ int __genl_register_family(struct genl_family *family)
goto errout_locked;
}
- if (family->id == GENL_ID_GENERATE) {
- u16 newid = genl_generate_id();
+ if (family == &genl_ctrl) {
+ family->id = GENL_ID_CTRL;
+ } else {
+ u16 newid;
+
+ /* this should be left zero in the struct */
+ WARN_ON(family->id);
+
+ /*
+ * Sadly, a few cases need to be special-cased
+ * due to them having previously abused the API
+ * and having used their family ID also as their
+ * multicast group ID, so we use reserved IDs
+ * for both to be sure we can do that mapping.
+ */
+ if (strcmp(family->name, "pmcraid") == 0)
+ newid = GENL_ID_PMCRAID;
+ else if (strcmp(family->name, "VFS_DQUOT") == 0)
+ newid = GENL_ID_VFS_DQUOT;
+ else
+ newid = genl_generate_id();
if (!newid) {
err = -ENOMEM;
@@ -387,9 +398,6 @@ int __genl_register_family(struct genl_family *family)
}
family->id = newid;
- } else if (genl_family_find_byid(family->id)) {
- err = -EEXIST;
- goto errout_locked;
}
if (family->maxattr && !family->parallel_ops) {
@@ -419,7 +427,6 @@ int __genl_register_family(struct genl_family *family)
errout_locked:
genl_unlock_all();
-errout:
return err;
}
EXPORT_SYMBOL(__genl_register_family);