-----Original Message-----
From: Jiri Pirko <jiri@resnulli.us>
Sent: Saturday, July 23, 2022 8:42 AM
To: Keller, Jacob E <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org; Jakub Kicinski <kuba@kernel.org>
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update

Fri, Jul 22, 2022 at 11:12:27PM CEST, jacob.e.keller@intel.com wrote:

quoted

quoted

-----Original Message-----
From: Jiri Pirko <jiri@resnulli.us>
Sent: Thursday, July 21, 2022 11:19 PM
To: Keller, Jacob E <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org; Jakub Kicinski <kuba@kernel.org>
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash

update

quoted

quoted

Thu, Jul 21, 2022 at 10:32:25PM CEST, jacob.e.keller@intel.com wrote:

quoted

quoted

-----Original Message-----
From: Jiri Pirko <jiri@resnulli.us>
Sent: Wednesday, July 20, 2022 10:55 PM
To: Keller, Jacob E <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org; Jakub Kicinski <kuba@kernel.org>
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash

update

quoted

<...>

quoted

quoted

struct devlink_region;
struct devlink_info_req;

diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index b3d40a5d72ff..e24a5a808a12 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h

@@ -576,6 +576,14 @@ enum devlink_attr {

	DEVLINK_ATTR_LINECARD_TYPE,		/* string */
	DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES,	/* nested */

+	/* Before adding this attribute to a command, user space should

check

quoted

quoted

quoted

quoted

quoted

+	 * the policy dump and verify the kernel recognizes the attribute.
+	 * Otherwise older kernels which do not recognize the attribute

may

quoted

quoted

quoted

quoted

quoted

+	 * silently accept the unknown attribute while not actually

performing

quoted

quoted

quoted

quoted

quoted

+	 * a dry run.

Why this comment is needed? Isn't that something generic which applies
to all new attributes what userspace may pass and kernel may ignore?

Because other attributes may not have such a negative and unexpected side

effect. In most cases the side effect will be "the thing you wanted doesn't
happen", but in this case its "the thing you didn't want to happen does". I

think

quoted

quoted

that deserves some warning. A dry run is a request to *not* do something.

Hmm. Another option, in order to be on the safe side, would be to have a
new cmd for this...

I think that the warning and implementation in the iproute2 devlink userspace is

sufficient. The alternative would be to work towards converting devlink over to
the explicit validation which rejects unknown parameters.. but that has its own
backwards compatibility challenges as well.

quoted

I guess we could use the same code to implement the command so it wouldn't

be too much of a burden to add, but that also means we'd have a pattern of
using a new command for every future devlink operation that wants a "dry run".
I was anticipating we might want this  kind of option for other commands such as
port splitting and unsplitting.

quoted

If we were going to add new commands, I would rather we go to the extra

trouble of updating all the commands to be strict validation.

I think it is good idea. We would prevent many surprises.

I'm not sure exactly what the process would be here. Maybe something like:

1. identify all of the commands which aren't yet strict
2. introduce new command IDs for these commands with something like _STRICT as a suffix? (or something shorter like _2?)
3. make all of those commands strict validation..

but now that I think about that, i am not sure it would work. We use the same attribute list for all devlink commands. This means that strict validation would only check that its passed existing/known attributes? But that doesn't necessarily mean the kernel will process that particular attribute for a given command does it?

Like, once we introduce DEVLINK_ATTR_DRY_RUN support for flash, if we then want to introduce it later to something like port splitting.. it would be a valid attribute to send from kernels which support flash but would still be ignored on kernels that don't yet support it for port splitting?

Wouldn't we want each individual command to have its own validation of what attributes are valid?

I do think its probably a good idea to migrate to strict mode, but I am not sure it solves the problem of dry run. Thoughts? Am I missing something obvious?

Would we instead have to convert from genl_small_ops to genl_ops and introduce a policy for each command? I think that sounds like the proper approach here....

Thanks,
Jake