From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
jean-philippe@linaro.org, miko.lenczewski@arm.com,
balbirs@nvidia.com, peterz@infradead.org, smostafa@google.com,
kevin.tian@intel.com, praan@google.com, zhangzekun11@huawei.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array
Date: Tue, 26 Aug 2025 16:50:03 -0300 [thread overview]
Message-ID: <20250826195003.GA2151485@nvidia.com> (raw)
In-Reply-To: <fbec39124b18c231d19a9b2b05551b131ac14237.1755131672.git.nicolinc@nvidia.com>
On Wed, Aug 13, 2025 at 06:25:35PM -0700, Nicolin Chen wrote:
> +/**
> + * arm_smmu_invs_add() - Combine @old_invs with @add_invs to a new array
> + * @old_invs: the old invalidation array
> + * @add_invs: an array of invlidations to add
> + *
> + * Return: a newly allocated and sorted invalidation array on success, or an
> + * ERR_PTR.
> + *
> + * This function must be locked and serialized with arm_smmu_invs_del/dec(),
> + * but do not lockdep on any lock for KUNIT test.
> + *
> + * Caller is resposible for freeing the @old_invs and the returned one.
> + *
> + * Entries marked as trash can be resued if @add_invs wants to add them back.
> + * Otherwise, they will be completely removed in the returned array.
> + */
> +VISIBLE_IF_KUNIT
> +struct arm_smmu_invs *arm_smmu_invs_add(struct arm_smmu_invs *old_invs,
> + struct arm_smmu_invs *add_invs)
> +{
> + size_t need = old_invs->num_invs + add_invs->num_invs;
> + struct arm_smmu_invs *new_invs;
> + size_t deletes = 0, i, j;
> + u64 existed = 0;
> +
> + /* Max of add_invs->num_invs is 64 */
> + if (WARN_ON(add_invs->num_invs > sizeof(existed) * 8))
> + return ERR_PTR(-EINVAL);
Since this is driven off of num_streams using a fixed bitmap doesn't
seem great since I suppose the dt isn't limited to 64.
Given how this is working now I think you can just add a new member to
the struct:
struct arm_smmu_inv {
/* invalidation items */
struct arm_smmu_device *smmu;
u8 type;
u8 size_opcode;
u8 nsize_opcode;
/* Temporary bits for add/del functions */
u8 reuse:1;
u8 todel:1;
And use reuse as the temporary instead of the bitmap.
> + for (i = 0; i != old_invs->num_invs; i++) {
> + struct arm_smmu_inv *cur = &old_invs->inv[i];
missing newline
> + /* Count the trash entries to deletes */
> + if (cur->todel) {
> + WARN_ON_ONCE(refcount_read(&cur->users));
> + deletes++;
> + }
Just do continue here.
todel should only be used as a temporary. Use refcount_read() ==
0. Then you don't need a WARN either.
> + for (j = 0; j != add_invs->num_invs; j++) {
> + if (!same_op(cur, &add_invs->inv[j]))
> + continue;
> + /* Found duplicated entries in add_invs */
> + if (WARN_ON_ONCE(existed & BIT_ULL(j)))
> + continue;
inv[j].reuse
> + /* Revert the todel marker for reuse */
> + if (cur->todel) {
> + cur->todel = false;
> + deletes--;
This wil blow up the refcount_inc() below because users is 0..
There is no point in trying to optimize like this just discard the
old entry and add a new one.
> + new_invs = arm_smmu_invs_alloc(need);
> + if (IS_ERR(new_invs)) {
> + /* Don't forget to revert all the todel markers */
> + for (i = 0; i != old_invs->num_invs; i++) {
> + if (refcount_read(&old_invs->inv[i].users) == 0)
> + old_invs->inv[i].todel = true;
> + }
Drop as well
> + return new_invs;
> + }
> +
> + /* Copy the entire array less all the todel entries */
> + for (i = 0; i != old_invs->num_invs; i++) {
> + if (old_invs->inv[i].todel)
> + continue;
refcount_read
> + new_invs->inv[new_invs->num_invs++] = old_invs->inv[i];
> + }
> +
> + for (j = 0; j != add_invs->num_invs; j++) {
> + if (existed & BIT_ULL(j)) {
inv[j]->reuse
> + unsigned int idx = add_invs->inv[j].id;
Similar remarks for del, use users to set todel, don't expect it to be
valid coming into the function.
Jason
next prev parent reply other threads:[~2025-08-26 19:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 1:25 [PATCH rfcv1 0/8] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 1/8] iommu/arm-smmu-v3: Clear cmds->num after arm_smmu_cmdq_batch_submit Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 2/8] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 3/8] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2025-08-26 19:50 ` Jason Gunthorpe [this message]
2025-08-27 0:49 ` Nicolin Chen
2025-08-27 16:48 ` Jason Gunthorpe
2025-08-27 17:19 ` Nicolin Chen
2025-08-28 12:37 ` Jason Gunthorpe
2025-08-27 20:00 ` Jason Gunthorpe
2025-09-06 8:16 ` Nicolin Chen
2025-09-08 15:51 ` Jason Gunthorpe
2025-09-08 18:20 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 5/8] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2025-08-26 19:56 ` Jason Gunthorpe
2025-09-06 7:45 ` Nicolin Chen
2025-09-08 15:36 ` Jason Gunthorpe
2025-08-14 1:25 ` [PATCH rfcv1 6/8] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-08-27 18:21 ` Jason Gunthorpe
2025-09-06 7:52 ` Nicolin Chen
2025-09-06 8:20 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 7/8] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2025-08-27 18:49 ` Jason Gunthorpe
2025-09-06 8:12 ` Nicolin Chen
2025-09-08 15:39 ` Jason Gunthorpe
2025-09-08 18:19 ` Nicolin Chen
2025-09-08 18:24 ` Jason Gunthorpe
2025-09-08 18:45 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 8/8] iommu/arm-smmu-v3: Perform per-domain invalidations using arm_smmu_invs Nicolin Chen
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=20250826195003.GA2151485@nvidia.com \
--to=jgg@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
--cc=zhangzekun11@huawei.com \
/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.