Re: [PATCH net-next v4 04/12] net: netlink: add NLM_F_BULK delete request modifier
From: Nicolas Dichtel <hidden>
Date: 2022-09-20 07:50:53
Also in:
bridge
Le 13/04/2022 à 12:51, Nikolay Aleksandrov a écrit :
quoted hunk ↗ jump to hunk
Add a new delete request modifier called NLM_F_BULK which, when supported, would cause the request to delete multiple objects. The flag is a convenient way to signal that a multiple delete operation is requested which can be gradually added to different delete requests. In order to make sure older kernels will error out if the operation is not supported instead of doing something unintended we have to break a required condition when implementing support for this flag, f.e. for neighbors we will omit the mandatory mac address attribute. Initially it will be used to add flush with filtering support for bridge fdbs, but it also opens the door to add similar support to others. Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org> --- include/uapi/linux/netlink.h | 1 + 1 file changed, 1 insertion(+)diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h index 4c0cde075c27..855dffb4c1c3 100644 --- a/include/uapi/linux/netlink.h +++ b/include/uapi/linux/netlink.h@@ -72,6 +72,7 @@ struct nlmsghdr { /* Modifiers to DELETE request */ #define NLM_F_NONREC 0x100 /* Do not delete recursively */ +#define NLM_F_BULK 0x200 /* Delete multiple objects */
Sorry to reply to an old patch, but FWIW, this patch broke the uAPI. One of our applications was using NLM_F_EXCL with RTM_DELTFILTER. This is conceptually wrong but it was working. After this patch, the kernel returns an error (EOPNOTSUPP). Here is the patch series: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=92716869375b We probably can't do anything now, but to avoid this in the future, I see only two options: - enforce flags validation depending on the operation (but this may break some existing apps) - stop adding new flags that overlap between NEW and DEL operations (by adding a comment or defining dummy flags). Any thoughts? Regards, Nicolas