public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
* Re: [RFC PATCH V3] x86/VMBus: Confidential VMBus for dynamic DMA transfers
       [not found] <20260325075649.248241-1-tiala@microsoft.com>
@ 2026-03-27  6:05 ` kernel test robot
  0 siblings, 0 replies; only message in thread
From: kernel test robot @ 2026-03-27  6:05 UTC (permalink / raw)
  To: Tianyu Lan; +Cc: llvm, oe-kbuild-all

Hi Tianyu,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v7.0-rc5 next-20260326]
[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/Tianyu-Lan/x86-VMBus-Confidential-VMBus-for-dynamic-DMA-transfers/20260325-162853
base:   linus/master
patch link:    https://lore.kernel.org/r/20260325075649.248241-1-tiala%40microsoft.com
patch subject: [RFC PATCH V3] x86/VMBus: Confidential VMBus for dynamic DMA transfers
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20260327/202603271353.0O7DBbvf-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260327/202603271353.0O7DBbvf-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/202603271353.0O7DBbvf-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/hv/vmbus_drv.c:2194:3: error: call to undeclared function 'swiotlb_dev_disable'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2194 |                 swiotlb_dev_disable(&child_device_obj->device);
         |                 ^
   1 error generated.


vim +/swiotlb_dev_disable +2194 drivers/hv/vmbus_drv.c

  2172	
  2173	/*
  2174	 * vmbus_device_register - Register the child device
  2175	 */
  2176	int vmbus_device_register(struct hv_device *child_device_obj)
  2177	{
  2178		struct kobject *kobj = &child_device_obj->device.kobj;
  2179		int ret;
  2180	
  2181		dev_set_name(&child_device_obj->device, "%pUl",
  2182			     &child_device_obj->channel->offermsg.offer.if_instance);
  2183	
  2184		child_device_obj->device.bus = &hv_bus;
  2185		child_device_obj->device.parent = vmbus_root_device;
  2186		child_device_obj->device.release = vmbus_device_release;
  2187	
  2188		child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
  2189		child_device_obj->device.dma_mask = &child_device_obj->dma_mask;
  2190		dma_set_mask(&child_device_obj->device, DMA_BIT_MASK(64));
  2191	
  2192		device_initialize(&child_device_obj->device);
  2193		if (child_device_obj->channel->co_external_memory)
> 2194			swiotlb_dev_disable(&child_device_obj->device);
  2195	
  2196		/*
  2197		 * Register with the LDM. This will kick off the driver/device
  2198		 * binding...which will eventually call vmbus_match() and vmbus_probe()
  2199		 */
  2200		ret = device_add(&child_device_obj->device);
  2201		if (ret) {
  2202			pr_err("Unable to register child device\n");
  2203			put_device(&child_device_obj->device);
  2204			return ret;
  2205		}
  2206	
  2207		/*
  2208		 * If device_register() found a driver to assign to the device, the
  2209		 * driver's probe function has already run at this point. If that
  2210		 * probe function accesses or operates on the "channels" subdirectory
  2211		 * in sysfs, those operations will have failed because the "channels"
  2212		 * subdirectory doesn't exist until the code below runs. Or if the
  2213		 * probe function creates a /dev entry, a user space program could
  2214		 * find and open the /dev entry, and then create a race by accessing
  2215		 * the "channels" subdirectory while the creation steps are in progress
  2216		 * here. The race can't result in a kernel failure, but the user space
  2217		 * program may get an error in accessing "channels" or its
  2218		 * subdirectories. See also comments with vmbus_add_dynid() about a
  2219		 * related race condition.
  2220		 */
  2221		child_device_obj->channels_kset = kset_create_and_add("channels",
  2222								      NULL, kobj);
  2223		if (!child_device_obj->channels_kset) {
  2224			ret = -ENOMEM;
  2225			goto err_dev_unregister;
  2226		}
  2227	
  2228		ret = vmbus_add_channel_kobj(child_device_obj,
  2229					     child_device_obj->channel);
  2230		if (ret) {
  2231			pr_err("Unable to register primary channel\n");
  2232			goto err_kset_unregister;
  2233		}
  2234		hv_debug_add_dev_dir(child_device_obj);
  2235	
  2236		return 0;
  2237	
  2238	err_kset_unregister:
  2239		kset_unregister(child_device_obj->channels_kset);
  2240	
  2241	err_dev_unregister:
  2242		device_unregister(&child_device_obj->device);
  2243		return ret;
  2244	}
  2245	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-03-27  6:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20260325075649.248241-1-tiala@microsoft.com>
2026-03-27  6:05 ` [RFC PATCH V3] x86/VMBus: Confidential VMBus for dynamic DMA transfers kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox