All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.