On 10/2/18 10:30 AM, Jiri Benc wrote: > On Tue, 2 Oct 2018 08:57:24 -0600, David Ahern wrote: >> You can when you introduce a new option or a new flag that is required >> to get new behavior like kernel side filtering. > > Yes. That was what I tried with the patchset a few years back. It would > be nice to revive the effort. > >> I chose a netlink flag for consistency with NLM_F_DUMP_INTR and >> NLM_F_DUMP_FILTERED. Both are netlink flags. This patch set fixes only >> what is broken -- dumps. > > When we're introducing better input checking in netlink (which is a > good thing!), it would be good to do it consistently and have it > generic across all operations. >
Thinking about this some more... a setsockopt to enable the new checks would provide a definitive way for userspace to know if the feature is supported or not. As for expanding the scope to NEW (and maybe DEL) commands (which was the point of your patch set 3 years ago), I think is an idealistic goal that is not practical to implement. Trying to go through all commands and cover all options and valid combinations to report back errors is a herculean effort with little return on the time investment. New commands and new features should certainly add rigid checks for valid combinations, but a retrospective audit on existing commands is a time sink. Perhaps new attributes can be checked (new command on old kernel); seems like that can be covered by a simple change to nla_parse to handle type > maxtype based on a new input flag. Once the flag goes in, all of the commands to be affected by it have to be done in the same release. I have done that for the dump commands which is fairly easy considering the existing code.
