public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Tianyu Lan <ltykernel@gmail.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC PATCH V3] x86/VMBus: Confidential VMBus for dynamic DMA transfers
Date: Fri, 27 Mar 2026 14:05:33 +0800	[thread overview]
Message-ID: <202603271353.0O7DBbvf-lkp@intel.com> (raw)
In-Reply-To: <20260325075649.248241-1-tiala@microsoft.com>

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

           reply	other threads:[~2026-03-27  6:05 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20260325075649.248241-1-tiala@microsoft.com>]

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=202603271353.0O7DBbvf-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=ltykernel@gmail.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox