All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org,
	linux-doc@vger.kernel.org, jgg@ziepe.ca, david.quigley@intel.com,
	lukas@wunner.de, ksinyuk@kernel.org, rodrigo.vivi@intel.com,
	cedric.xing@intel.com, sameo@meta.com, drdeeglaze@gmail.com,
	James.Bottomley@HansenPartnership.com, aik@amd.com,
	jpiotrowski@nvidia.com, qinkun@google.com, pgonda@google.com,
	alistair.francis@wdc.com, ankita@nvidia.com,
	suzuki.poulose@arm.com, kas@kernel.org,
	rick.p.edgecombe@intel.com, elena.reshetova@intel.com,
	dave.hansen@linux.intel.com,
	sathyanarayanan.kuppuswamy@linux.intel.com, peter.fang@intel.com
Subject: Re: [PATCH RFC 10/20] ctlv: Prepare event queue support
Date: Wed, 21 Oct 2026 02:12:08 +0100	[thread overview]
Message-ID: <20261021021208.6909d4e3@jic23-hlaptop> (raw)
In-Reply-To: <20261015145053.3664509-11-jiri@resnulli.us>

On Thu, 15 Oct 2026 16:50:43 +0200
Jiri Pirko <jiri@resnulli.us> wrote:

> From: Jiri Pirko <jiri@nvidia.com>
> 
> Add per-open subscriptions, bounded event queues and event creation for
> CTLV families. Add the generated root family kernel bindings now that their
> message and event helpers are available.
> 
> The event and generated root objects can be compile-checked here.
> CONFIG_CTLV remains unwired until device dispatch completes the module.
> 
> Assisted-by: Cursor: GPT-5.6 Sol
> Assisted-by: Cursor: Claude Opus 5.5
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Nothing fundamental - just a few passing comments.

I'm running low on time, so will take a closer look at
this in a future revision.

> diff --git a/drivers/ctlv/event.c b/drivers/ctlv/event.c
> new file mode 100644
> index 000000000000..0f68d33e031c
> --- /dev/null
> +++ b/drivers/ctlv/event.c
> @@ -0,0 +1,713 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES
> + *
> + * Per-open event queues and loss reporting.
> + */
> +
> +#include <linux/bitmap.h>
> +#include <linux/build_bug.h>

cleanup.h given you are making quite a bit of use
of guard() in here.

> +#include <linux/ctlv.h>
> +#include <linux/ctlv_gen.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/list.h>
> +#include <linux/minmax.h>
> +#include <linux/overflow.h>
> +#include <linux/poll.h>
> +#include <linux/sizes.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/string.h>
> +#include <linux/uaccess.h>
> +#include <linux/wait.h>
> +
> +#include "builder.h"
> +#include "device.h"
> +#include "event.h"
> +#include "internal.h"
> +#include "message.h"
> +#include "schema.h"

> +
> +struct ctlv_op_ctx *ctlv_event_create(struct ctlv_device *ctlvdev, u64 op_id,
> +				      struct ctlv_cursor **reply, gfp_t gfp)
> +{
> +	const struct ctlv_op_entry *op;
> +	struct ctlv_op_ctx *ctx;
> +	void *out;
> +	u32 room;
> +	int ret;
> +
> +	ctx = kzalloc_obj(*ctx, gfp);
> +	if (!ctx)
> +		return ERR_PTR(-ENOMEM);
> +	scoped_guard(spinlock, &ctlvdev->events_lock) {

Generally mixing anything cleanup.h with gotos is
a bad idea. Tends to get Linus saying your code needs
restructuring even if it isn't an actual bug.

> +		const struct ctlv_family *family;
> +
> +		if (!ctlvdev->events_live) {
> +			ret = -ENODEV;
> +			goto err_free_ctx;
> +		}
> +		if (WARN_ON_ONCE(ctlvdev->active_event_contexts == U32_MAX)) {
> +			ret = -EOVERFLOW;
> +			goto err_free_ctx;
> +		}
> +		/* Admission pins the op until emit or abort. */
> +		family = READ_ONCE(ctlvdev->family);
> +		if (!family) {
> +			ret = -ENODEV;
> +			goto err_free_ctx;
> +		}
> +		get_device(&ctlvdev->dev);
> +		ctlvdev->active_event_contexts++;
> +		ctx->ctlvdev = ctlvdev;
> +		ctx->family = family;
> +	}
> +
> +	op = ctlv_op_find(ctlvdev, op_id);
> +	if (WARN_ON_ONCE(!op) || WARN_ON_ONCE(op->schema->type != CTLV_OP_TYPE_EVENT)) {
> +		ret = -EINVAL;
> +		goto err_put_ctx;
> +	}
> +	room = ctlv_event_len(op) - sizeof(struct ctlv_event_hdr);
> +	out = kmalloc(room, gfp);
> +	if (!out) {
> +		ret = -ENOMEM;
> +		goto err_put_ctx;
> +	}
> +
> +	ctx->gfp = gfp;
> +	ctx->op = op;
> +	ctlv_message_output_init(&ctx->output, ctx, out, room, &op->schema->reply);
> +	ctlv_message_root(&ctx->output_root, &ctx->output);
> +	ctx->deepest = &ctx->output_root;
> +	*reply = &ctx->output_root;
> +	return ctx;
> +
> +err_put_ctx:
> +	ctlv_event_free(ctx);
> +	return ERR_PTR(ret);
> +err_free_ctx:
> +	kfree(ctx);
> +	return ERR_PTR(ret);

Two different error paths also tend to indicate code needs
a rethink and maybe splitting into a couple of functions for the
different stages.

> +}
> +EXPORT_SYMBOL_NS_GPL(ctlv_event_create, "CTLV");



> +
> +ssize_t ctlv_event_file_read(struct ctlv_file *cfile, char __user *buf, size_t len, bool blocking)
> +{
> +	struct ctlv_device *ctlvdev = cfile->ctlvdev;
> +	struct ctlv_event_record *rec;
> +	ssize_t ret;
> +
> +	/* dup() and SCM_RIGHTS share one serialized queue. */
> +	if (mutex_lock_interruptible(&cfile->reading))
> +		return -ERESTARTSYS;

	ACQUIRE() magic should work here and let you do direct returns on error.

> +
> +	while (!(rec = ctlv_event_queue_take(cfile))) {
> +		/* Drained, and the device is gone. */
> +		if (READ_ONCE(ctlvdev->dead_announced)) {
> +			ret = -ENODEV;
> +			goto out_unlock;
> +		}
> +		if (!blocking) {
> +			ret = -EAGAIN;
> +			goto out_unlock;
> +		}
> +		ret = wait_event_interruptible(cfile->readers, ctlv_event_waiting(cfile));
> +		if (ret) {
> +			ret = -ERESTARTSYS;
> +			goto out_unlock;
> +		}
> +	}
> +
> +	if (rec->len > len) {
> +		ctlv_event_queue_untake(cfile, rec);
> +		ret = -EMSGSIZE;
> +		goto out_unlock;
> +	}
> +	if (copy_to_user(buf, &rec->hdr, rec->len)) {
> +		ctlv_event_queue_untake(cfile, rec);
> +		ret = -EFAULT;
> +		goto out_unlock;
> +	}
> +	ret = rec->len;
> +	ctlv_event_queue_consumed(cfile, rec);
> +
> +out_unlock:
> +	mutex_unlock(&cfile->reading);
> +	return ret;
> +}

> +static int ctlv_event_subscriptions_set(struct ctlv_op_ctx *ctx, const struct ctlv_cursor *request,
> +					struct ctlv_input_ref ref, bool subscribe)
> +{
> +	struct ctlv_device *ctlvdev = ctx->ctlvdev;
> +	struct ctlv_cursor attr;
> +
> +	for (ctlv_input_attr(&attr, request, ref); ctlv_attr_ok(&attr); ctlv_attr_next(&attr)) {
> +		u64 op_id = ctlv_attr_u64(&attr);
> +
> +		if (!ctlv_event_subscription_find(ctlvdev, op_id))
> +			return ctlv_op_errorf(ctx, -EOPNOTSUPP,
> +					      "op %#llx is not an event this device emits",
> +					      (unsigned long long)op_id);
> +	}
> +
> +	guard(spinlock)
> +		(&ctlvdev->events_lock);

That looks odd. 
	guard(spinlock)(&ctlvdev->events_lock);
is more familiar form to me anyway.

> +	for (ctlv_input_attr(&attr, request, ref); ctlv_attr_ok(&attr); ctlv_attr_next(&attr)) {
> +		u64 op_id = ctlv_attr_u64(&attr);
> +		const struct ctlv_op_entry *op = ctlv_event_subscription_find(ctlvdev, op_id);
> +
> +		if (subscribe)
> +			set_bit(op->event_index, ctx->file->subscribed);
> +		else
> +			clear_bit(op->event_index, ctx->file->subscribed);

		assign_bit()

> +	}
> +	return 0;
> +}


  parent reply	other threads:[~2026-10-21  1:12 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 14:50 [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 01/20] ctlv: Add the schema language and generator Jiri Pirko
2026-10-15 14:58   ` sashiko-bot
2026-10-20 22:31   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 02/20] ctlv: Add the UAPI wire format and family API Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 12:26     ` Jiri Pirko
2026-10-20 23:00   ` Jonathan Cameron
2026-10-20 23:39     ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 03/20] ctlv: Add the root family specification and generated files Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 12:28     ` Jiri Pirko
2026-10-20 12:55       ` Jason Gunthorpe
2026-10-20 14:07         ` Jiri Pirko
2026-10-20 23:30   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 04/20] Documentation: ctlv: Add userspace ABI Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 14:06     ` Jiri Pirko
2026-10-21  0:11   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 05/20] ctlv: Prepare message input handling Jiri Pirko
2026-10-15 15:06   ` sashiko-bot
2026-10-21  0:43   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 06/20] ctlv: Prepare blob descriptor validation Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 07/20] ctlv: Prepare schema validation Jiri Pirko
2026-10-15 15:14   ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 08/20] ctlv: Prepare message output handling Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 09/20] ctlv: Prepare VA blob handling Jiri Pirko
2026-10-15 15:14   ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 10/20] ctlv: Prepare event queue support Jiri Pirko
2026-10-15 15:22   ` sashiko-bot
2026-10-21  1:12   ` Jonathan Cameron [this message]
2026-10-15 14:50 ` [PATCH RFC 11/20] ctlv: Prepare runtime introspection Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 12/20] ctlv: Add device and operation dispatch Jiri Pirko
2026-10-15 15:28   ` sashiko-bot
2026-10-21  1:25   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 13/20] Documentation: ctlv: Describe how to write a family Jiri Pirko
2026-10-15 15:20   ` sashiko-bot
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 14/20] attestation: Add the base family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 15/20] attestation: Prepare provider and instance core Jiri Pirko
2026-10-15 15:30   ` sashiko-bot
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 16/20] attestation: Prepare measurement register journal Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 17/20] attestation: Add CTLV operation handling Jiri Pirko
2026-10-15 15:33   ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 18/20] tdx-guest: Expose the native attestation service API Jiri Pirko
2026-10-15 15:40   ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 19/20] attestation: Add the TDX family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 20/20] attestation: Add the TDX family implementation Jiri Pirko
2026-10-15 15:40   ` sashiko-bot
2026-10-16 23:43 ` [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jason Gunthorpe
2026-10-17 18:16   ` Dionna Glaze
2026-10-17 19:06     ` Jarkko Sakkinen
2026-10-17 19:08       ` Jarkko Sakkinen
2026-10-17 19:22         ` Jarkko Sakkinen
2026-10-17 20:55       ` Jason Gunthorpe
2026-10-17 21:14         ` Jarkko Sakkinen
2026-10-17 20:34     ` Jason Gunthorpe
2026-10-17 20:55       ` Jarkko Sakkinen
2026-10-17 23:10         ` Jason Gunthorpe
2026-10-18 23:53           ` Dionna Glaze
2026-10-19 12:08             ` Jiri Pirko
2026-10-19 16:10               ` Dionna Glaze
2026-10-19 22:56                 ` Jason Gunthorpe
2026-10-20  9:26                 ` Jiri Pirko
2026-10-20 13:45                 ` Mimi Zohar
2026-10-20 14:06                   ` Jason Gunthorpe
2026-10-20 15:22                     ` Mimi Zohar
2026-10-20 16:11                       ` Yeoreum Yun
2026-10-20 16:52                         ` Jason Gunthorpe
2026-10-19 12:40             ` Jarkko Sakkinen
2026-10-19 23:11             ` Jason Gunthorpe
2026-10-20 12:49       ` James Bottomley
2026-10-20 13:13         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261021021208.6909d4e3@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=aik@amd.com \
    --cc=alistair.francis@wdc.com \
    --cc=ankita@nvidia.com \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.quigley@intel.com \
    --cc=drdeeglaze@gmail.com \
    --cc=elena.reshetova@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=jpiotrowski@nvidia.com \
    --cc=kas@kernel.org \
    --cc=ksinyuk@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=peter.fang@intel.com \
    --cc=pgonda@google.com \
    --cc=qinkun@google.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sameo@meta.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=suzuki.poulose@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.