On 10/2/18 10:30 AM, Jiri Benc wrote:

On Tue, 2 Oct 2018 08:57:24 -0600, David Ahern wrote:

quoted

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.

quoted

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.