[jgunthorpe:pr/3 63/70] drivers/vfio/vfio.c:905:56: error: 'noiommu' undeclared

[jgunthorpe:pr/3 63/70] drivers/vfio/vfio.c:905:56: error: 'noiommu' undeclared

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 5299 bytes --]

tree:   https://github.com/jgunthorpe/linux pr/3
head:   deb80fed324d3a7b8d738e71cf4e6d16bdfdbced
commit: 4417a603d536dbd59b2b259d1a9acb531b3332f8 [63/70] vfio/mdev: Move vfio_iommu_group_get() to vfio_register_group_dev()
config: powerpc64-randconfig-p001-20210305 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/jgunthorpe/linux/commit/4417a603d536dbd59b2b259d1a9acb531b3332f8
        git remote add jgunthorpe https://github.com/jgunthorpe/linux
        git fetch --no-tags jgunthorpe pr/3
        git checkout 4417a603d536dbd59b2b259d1a9acb531b3332f8
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/vfio/vfio.c: In function 'vfio_unregister_group_dev':
>> drivers/vfio/vfio.c:905:56: error: 'noiommu' undeclared (first use in this function)
     905 |      iommu_group_get_iommudata(group->iommu_group) == &noiommu)
         |                                                        ^~~~~~~
   drivers/vfio/vfio.c:905:56: note: each undeclared identifier is reported only once for each function it appears in


vim +/noiommu +905 drivers/vfio/vfio.c

   829	
   830	/*
   831	 * Decrement the device reference count and wait for the device to be
   832	 * removed.  Open file descriptors for the device... */
   833	void vfio_unregister_group_dev(struct vfio_device *device)
   834	{
   835		struct vfio_group *group = device->group;
   836		struct vfio_unbound_dev *unbound;
   837		unsigned int i = 0;
   838		bool interrupted = false;
   839		long rc;
   840	
   841		/*
   842		 * When the device is removed from the group, the group suddenly
   843		 * becomes non-viable; the device has a driver (until the unbind
   844		 * completes), but it's not present in the group.  This is bad news
   845		 * for any external users that need to re-acquire a group reference
   846		 * in order to match and release their existing reference.  To
   847		 * solve this, we track such devices on the unbound_list to bridge
   848		 * the gap until they're fully unbound.
   849		 */
   850		unbound = kzalloc(sizeof(*unbound), GFP_KERNEL);
   851		if (unbound) {
   852			unbound->dev = device->dev;
   853			mutex_lock(&group->unbound_lock);
   854			list_add(&unbound->unbound_next, &group->unbound_list);
   855			mutex_unlock(&group->unbound_lock);
   856		}
   857		WARN_ON(!unbound);
   858	
   859		mutex_lock(&group->device_lock);
   860		list_del(&device->group_next);
   861		group->dev_counter--;
   862		mutex_unlock(&group->device_lock);
   863	
   864		vfio_device_put(device);
   865		rc = try_wait_for_completion(&device->comp);
   866		while (rc <= 0) {
   867			if (device->ops->request)
   868				device->ops->request(device, i++);
   869	
   870			if (interrupted) {
   871				rc = wait_for_completion_timeout(&device->comp,
   872								 HZ * 10);
   873			} else {
   874				rc = wait_for_completion_interruptible_timeout(
   875					&device->comp, HZ * 10);
   876				if (rc < 0) {
   877					interrupted = true;
   878					dev_warn(device->dev,
   879						 "Device is currently in use, task"
   880						 " \"%s\" (%d) "
   881						 "blocked until device is released",
   882						 current->comm, task_pid_nr(current));
   883				}
   884			}
   885		}
   886	
   887		/*
   888		 * In order to support multiple devices per group, devices can be
   889		 * plucked from the group while other devices in the group are still
   890		 * in use.  The container persists with this group and those remaining
   891		 * devices still attached.  If the user creates an isolation violation
   892		 * by binding this device to another driver while the group is still in
   893		 * use, that's their fault.  However, in the case of removing the last,
   894		 * or potentially the only, device in the group there can be no other
   895		 * in-use devices in the group.  The user has done their due diligence
   896		 * and we should lay no claims to those devices.  In order to do that,
   897		 * we need to make sure the group is detached from the container.
   898		 * Without this stall, we're potentially racing with a user process
   899		 * that may attempt to immediately bind this device to another driver.
   900		 */
   901		if (list_empty(&group->device_list))
   902			wait_event(group->container_q, !group->container);
   903	
   904		if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
 > 905		    iommu_group_get_iommudata(group->iommu_group) == &noiommu)
   906			iommu_group_remove_device(device->dev);
   907	
   908		/* Matches the get in vfio_group_create_device() */
   909		vfio_group_put(group);
   910	}
   911	EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
   912	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 24555 bytes --]