From: kernel test robot <lkp@intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>, will@kernel.org, jgg@nvidia.com
Cc: oe-kbuild-all@lists.linux.dev, jean-philippe@linaro.org,
robin.murphy@arm.com, joro@8bytes.org, balbirs@nvidia.com,
miko.lenczewski@arm.com, peterz@infradead.org,
kevin.tian@intel.com, praan@google.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters
Date: Sat, 18 Oct 2025 00:03:27 +0800 [thread overview]
Message-ID: <202510172340.XyneWIPI-lkp@intel.com> (raw)
In-Reply-To: <14d76eebae359825442a96c0ffa13687de792063.1760555863.git.nicolinc@nvidia.com>
Hi Nicolin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v6.18-rc1 next-20251016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nicolin-Chen/iommu-arm-smmu-v3-Explicitly-set-smmu_domain-stage-for-SVA/20251016-034754
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/14d76eebae359825442a96c0ffa13687de792063.1760555863.git.nicolinc%40nvidia.com
patch subject: [PATCH v3 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters
config: arm64-randconfig-r123-20251017 (https://download.01.org/0day-ci/archive/20251017/202510172340.XyneWIPI-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 754ebc6ebb9fb9fbee7aef33478c74ea74949853)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251017/202510172340.XyneWIPI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510172340.XyneWIPI-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3208:33: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct arm_smmu_invs **invs_ptr @@ got struct arm_smmu_invs [noderef] __rcu ** @@
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3208:33: sparse: expected struct arm_smmu_invs **invs_ptr
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3208:33: sparse: got struct arm_smmu_invs [noderef] __rcu **
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3226:33: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct arm_smmu_invs **invs_ptr @@ got struct arm_smmu_invs [noderef] __rcu ** @@
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3226:33: sparse: expected struct arm_smmu_invs **invs_ptr
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3226:33: sparse: got struct arm_smmu_invs [noderef] __rcu **
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3247:9: sparse: sparse: incompatible types in comparison expression (different address spaces):
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3247:9: sparse: struct arm_smmu_invs [noderef] __rcu *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3247:9: sparse: struct arm_smmu_invs *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3305:9: sparse: sparse: incompatible types in comparison expression (different address spaces):
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3305:9: sparse: struct arm_smmu_invs [noderef] __rcu *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3305:9: sparse: struct arm_smmu_invs *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c: note: in included file (through arch/arm64/include/asm/atomic.h, include/linux/atomic.h, include/asm-generic/bitops/atomic.h, ...):
arch/arm64/include/asm/cmpxchg.h:168:1: sparse: sparse: cast truncates bits from constant value (ffffffff80000000 becomes 0)
arch/arm64/include/asm/cmpxchg.h:168:1: sparse: sparse: cast truncates bits from constant value (ffffffff80000000 becomes 0)
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c: note: in included file:
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_head [noderef] __rcu * @@
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: expected struct callback_head *head
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: got struct callback_head [noderef] __rcu *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: sparse: cast removes address space '__rcu' of expression
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_head [noderef] __rcu * @@
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: expected struct callback_head *head
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: got struct callback_head [noderef] __rcu *
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:1056:9: sparse: sparse: cast removes address space '__rcu' of expression
vim +3208 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
3174
3175 /*
3176 * During attachment, the updates of the two domain->invs arrays are sequenced:
3177 * 1. new domain updates its invs array, merging master->build_invs
3178 * 2. new domain starts to include the master during its invalidation
3179 * 3. master updates its STE switching from the old domain to the new domain
3180 * 4. old domain still includes the master during its invalidation
3181 * 5. old domain updates its invs array, unreferencing master->build_invs
3182 *
3183 * For 1 and 5, prepare the two updated arrays in advance, handling any changes
3184 * that can possibly failure. So the actual update of either 1 or 5 won't fail.
3185 * arm_smmu_asid_lock ensures that the old invs in the domains are intact while
3186 * we are sequencing to update them.
3187 */
3188 static int arm_smmu_attach_prepare_invs(struct arm_smmu_attach_state *state,
3189 struct arm_smmu_domain *new_smmu_domain)
3190 {
3191 struct arm_smmu_domain *old_smmu_domain =
3192 to_smmu_domain_devices(state->old_domain);
3193 struct arm_smmu_master *master = state->master;
3194 ioasid_t ssid = state->ssid;
3195
3196 /* A re-attach case doesn't need to update invs array */
3197 if (new_smmu_domain == old_smmu_domain)
3198 return 0;
3199
3200 /*
3201 * At this point a NULL domain indicates the domain doesn't use the
3202 * IOTLB, see to_smmu_domain_devices().
3203 */
3204 if (new_smmu_domain) {
3205 struct arm_smmu_inv_state *invst = &state->new_domain_invst;
3206 struct arm_smmu_invs *build_invs;
3207
> 3208 invst->invs_ptr = &new_smmu_domain->invs;
3209 invst->old_invs = rcu_dereference_protected(
3210 new_smmu_domain->invs,
3211 lockdep_is_held(&arm_smmu_asid_lock));
3212 build_invs = arm_smmu_master_build_invs(
3213 master, state->ats_enabled, ssid, new_smmu_domain);
3214 if (!build_invs)
3215 return -EINVAL;
3216
3217 invst->new_invs =
3218 arm_smmu_invs_merge(invst->old_invs, build_invs);
3219 if (IS_ERR(invst->new_invs))
3220 return PTR_ERR(invst->new_invs);
3221 }
3222
3223 if (old_smmu_domain) {
3224 struct arm_smmu_inv_state *invst = &state->old_domain_invst;
3225
3226 invst->invs_ptr = &old_smmu_domain->invs;
3227 invst->old_invs = rcu_dereference_protected(
3228 old_smmu_domain->invs,
3229 lockdep_is_held(&arm_smmu_asid_lock));
3230 /* For old_smmu_domain, new_invs points to master->build_invs */
3231 invst->new_invs = arm_smmu_master_build_invs(
3232 master, master->ats_enabled, ssid, old_smmu_domain);
3233 }
3234
3235 return 0;
3236 }
3237
3238 /* Must be installed before arm_smmu_install_ste_for_dev() */
3239 static void
3240 arm_smmu_install_new_domain_invs(struct arm_smmu_attach_state *state)
3241 {
3242 struct arm_smmu_inv_state *invst = &state->new_domain_invst;
3243
3244 if (!invst->invs_ptr)
3245 return;
3246
> 3247 rcu_assign_pointer(*invst->invs_ptr, invst->new_invs);
3248 /*
3249 * We are committed to updating the STE. Ensure the invalidation array
3250 * is visable to concurrent map/unmap threads, and acquire any racying
3251 * IOPTE updates.
3252 */
3253 smp_mb();
3254 kfree_rcu(invst->old_invs, rcu);
3255 }
3256
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-10-17 16:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 19:42 [PATCH v3 0/7] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 1/7] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 2/7] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 3/7] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2025-10-16 19:18 ` kernel test robot
2025-10-16 21:31 ` Nicolin Chen
2025-10-17 13:47 ` kernel test robot
2025-10-17 20:12 ` Nicolin Chen
2025-10-20 12:10 ` Jason Gunthorpe
2025-10-20 19:16 ` Nicolin Chen
2025-10-27 12:06 ` kernel test robot
2025-10-27 16:38 ` Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 4/7] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-10-17 16:03 ` kernel test robot [this message]
2025-10-17 21:11 ` Nicolin Chen
2025-10-20 12:12 ` Jason Gunthorpe
2025-10-20 19:05 ` Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2025-10-15 19:42 ` [PATCH v3 7/7] 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=202510172340.XyneWIPI-lkp@intel.com \
--to=lkp@intel.com \
--cc=balbirs@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--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=oe-kbuild-all@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=will@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.