Re: [PATCH RFC 05/20] ctlv: Prepare message input handling

Mon, Oct 26, 2026 at 03:07:54PM +0100, jgg@nvidia.com wrote:

quoted

[ ... 38 lines skipped ... ]

--- /dev/null
+++ b/drivers/ctlv/Kconfig

@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig CTLV
+	tristate "CTLV character device TLV UAPI"
+	help
+	  CTLV provides character device UAPIs described by a checked-in YAML
+	  specification. It owns the character device lifetime, the strict TLV
+	  message format, request validation, reply serialization, the large
+	  payloads a request describes rather than carries, per-open event
+	  queues and runtime schema introspection, so families only implement
+	  semantics.
+
+	  If you don't know what to do here, say N.

This should probably just be a simple selectable config instead of a
full blown menuconfig. ie one with no description. Since this is
really just a tool for subsystems to use every subsystem that uses it
should just select it.

So:

config CTLV
  bool

Makes sense.

quoted

[ ... 159 lines skipped ... ]
+static bool ctlv_message_nest_index_ok(const struct ctlv_cursor *nest)
+{
+	const struct ctlv_message_input_index *index = nest->msg->index;
+	const struct ctlv_message_input_nest *indexed;
+	const struct ctlv_message_input_scope *scope;
+	const struct ctlv_attr *attr;
+
+	if (WARN_ON_ONCE(!nest->msg->request || !index ||
+			 nest->index_nest_scope >= index->scopes_count))
+		return false;
+	scope = &index->scopes[nest->index_nest_scope];
+	if (WARN_ON_ONCE(scope->nest >= index->nests_count))
+		return false;
+	indexed = &index->nests[scope->nest];
+	attr = (const void *)((const u8 *)nest->msg->root + indexed->offset);
+	if (WARN_ON_ONCE(attr != nest->attr))
+		return false;
+	return !WARN_ON_ONCE(scope->tree != nest->tree || scope->node != nest->node);

Maybe wrap these invariant assertions in a helper and we can compile
them out?

 #ifdef CONFIG_CTLV_DEBUG
 #define CTLV_ASSERT(xxx) WARN_ON_ONCE(xxx)
 #endif

Well, yeah, that would probably make sense.

It helps manage expectations around WARN_ON. I assume these have all
been checked to guarentee they cannot be triggered by users space?

Sure.

-- 
Jason