From: Jean-Philippe Brucker <jpb@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: Ryan Roberts <ryan.roberts@arm.com>, dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH v1 5/8] misc/arm-cla: Accelerator context save and restore
Date: Wed, 30 Sep 2026 12:55:47 +0100 [thread overview]
Message-ID: <20260930115547.GE480985@myrica> (raw)
In-Reply-To: <20260717105811.4B1F71F000E9@smtp.kernel.org>
On Fri, Jul 17, 2026 at 10:58:10AM +0000, sashiko-bot@kernel.org wrote:
> > + regstate_size = FIELD_GET(CLA_SRSTATE_0_REGSTATE, srstate[0]);
> > + if (WARN_ON(*regstate_off + regstate_size * 8 > dev->iassizes))
> > + return -ENOSPC;
>
> [Severity: High]
> Does this bounds check correctly handle the units for *regstate_off?
>
> *regstate_off is incremented by regstate_size (which is a register count),
> so it is also a register count.
>
> If dev->iassizes is in bytes, this check improperly adds a register count
> (*regstate_off) to a byte count (regstate_size * 8) and compares it against
> a byte count.
Yes this should be WARN_ON((*regstate_off + regstate_size) * 8 > dev->iassizes)
> > +int cla_regs_switch_out(struct cla_dev *dev, struct cla_regs *regs,
> > + bool save_regs)
> > +{
> [ ... ]
> > + if (save_regs) {
> > + for (i = 0; i < CLA_NUM_DATA_REGS; i++)
> > + regs->data[i] = cla_reg_read(dev, CLA_REG_DATA(i));
> > +
> > + cla_for_each_accid(dev, accid) {
> > + ret = cla_regs_save_accel(dev, accid, regs, ®state_off);
> > + if (ret)
> > + return ret;
>
> [Severity: Medium]
> If cla_regs_save_accel() fails here, the function returns without clearing
> regs->accel_valid.
>
> Since regs is allocated once per domain and reused, accel_valid might
> already be true from a previous successful save. Returning an error here
> leaves the structure partially overwritten (a mix of old and new accelerator
> states) but still marked as valid.
>
> If the caller handles this switch-out failure non-fatally and retries the
> context later, will cla_regs_switch_in() restore this corrupted state to
> the hardware?
Switch-out failure is fatal, requires at least module reload
> > + }
> > +
> > + regs->accel_valid = true;
> > + }
> [ ... ]
> > +struct cla_regs **cla_regs_alloc_domain(struct cla_domain *domain)
> > +{
> [ ... ]
> > + for (i = 0; i < domain->nr_devs; i++) {
> > + struct cla_regs *regs;
> > + struct cla_dev *dev = domain->devs[i];
> > +
> > + /*
> > + * The regs structures are only ever accessed from the CLA
> > + * device's CPU, so try to allocate them on the right NUMA node
> > + */
> > + size = sizeof(*regs) + dev->iassizes;
>
> [Severity: High]
> If dev->iassizes represents a register count rather than a byte count,
> should it be scaled by sizeof(u64) here?
iassizes is a byte count
next prev parent reply other threads:[~2026-09-30 11:55 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 10:47 [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver Ryan Roberts
2026-07-17 10:47 ` [RFC PATCH v1 1/8] misc/arm-cla: Add driver skeleton and documentation Ryan Roberts
2026-07-17 10:56 ` sashiko-bot
2026-09-30 11:51 ` Jean-Philippe Brucker
2026-07-17 13:49 ` Arnd Bergmann
2026-07-17 15:44 ` Ryan Roberts
2026-07-17 16:10 ` Arnd Bergmann
2026-07-20 9:54 ` Ryan Roberts
2026-07-17 10:47 ` [RFC PATCH v1 2/8] misc/arm-cla: Add launch operation helpers Ryan Roberts
2026-07-17 11:01 ` sashiko-bot
2026-09-30 11:52 ` Jean-Philippe Brucker
2026-07-17 12:16 ` Arnd Bergmann
2026-08-04 11:03 ` Jean-Philippe Brucker
2026-07-17 10:47 ` [RFC PATCH v1 3/8] misc/arm-cla: Probe firmware-described devices Ryan Roberts
2026-07-17 10:57 ` sashiko-bot
2026-09-30 11:53 ` Jean-Philippe Brucker
2026-07-17 12:25 ` Arnd Bergmann
2026-07-17 12:36 ` Ryan Roberts
2026-07-17 10:47 ` [RFC PATCH v1 4/8] misc/arm-cla: Initialize devices on CPU bringup Ryan Roberts
2026-07-17 10:58 ` sashiko-bot
2026-09-30 11:54 ` Jean-Philippe Brucker
2026-07-17 10:47 ` [RFC PATCH v1 5/8] misc/arm-cla: Accelerator context save and restore Ryan Roberts
2026-07-17 10:58 ` sashiko-bot
2026-09-30 11:55 ` Jean-Philippe Brucker [this message]
2026-07-17 10:47 ` [RFC PATCH v1 6/8] misc/arm-cla: Set up memory translation context Ryan Roberts
2026-07-17 11:02 ` sashiko-bot
2026-09-30 11:56 ` Jean-Philippe Brucker
2026-07-17 10:47 ` [RFC PATCH v1 7/8] misc/arm-cla: Manage domain contexts Ryan Roberts
2026-07-17 11:01 ` sashiko-bot
2026-09-30 11:57 ` Jean-Philippe Brucker
2026-07-17 10:47 ` [RFC PATCH v1 8/8] misc/arm-cla: Add userspace interface Ryan Roberts
2026-07-17 11:10 ` sashiko-bot
2026-09-30 11:58 ` Jean-Philippe Brucker
2026-07-17 12:54 ` Arnd Bergmann
2026-07-17 14:35 ` Ryan Roberts
2026-07-17 15:31 ` Arnd Bergmann
2026-07-17 16:21 ` Ryan Roberts
2026-07-17 20:11 ` Arnd Bergmann
2026-08-19 16:08 ` Ryan Roberts
2026-07-17 11:33 ` [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver Will Deacon
2026-07-17 12:09 ` Marc Zyngier
2026-07-17 12:33 ` Ryan Roberts
2026-07-19 7:47 ` Marc Zyngier
2026-07-17 12:30 ` Ryan Roberts
2026-07-17 13:32 ` Jason Gunthorpe
2026-07-17 13:42 ` Ryan Roberts
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=20260930115547.GE480985@myrica \
--to=jpb@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.