From: kernel test robot <lkp@intel.com>
To: Linlin Zhang <linlin.zhang@oss.qualcomm.com>,
mst@redhat.com, jasowangio@gmail.com, axboe@kernel.dk,
ebiggers@kernel.org, stefanha@redhat.com
Cc: oe-kbuild-all@lists.linux.dev, pbonzini@redhat.com,
eperezma@redhat.com, xuanzhuo@linux.alibaba.com,
virtualization@lists.linux.dev, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] virtio_blk: Add control virtqueue support
Date: Sat, 10 Oct 2026 09:13:29 +0800 [thread overview]
Message-ID: <202610100905.au1oY0vX-lkp@intel.com> (raw)
In-Reply-To: <20261009041727.3170811-2-linlin.zhang@oss.qualcomm.com>
Hi Linlin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on axboe/for-next]
[also build test WARNING on mst-vhost/linux-next linus/master v7.3-rc6 next-20261008]
[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/Linlin-Zhang/virtio_blk-Add-control-virtqueue-support/20261008-211713
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git for-next
patch link: https://lore.kernel.org/r/20261009041727.3170811-2-linlin.zhang%40oss.qualcomm.com
patch subject: [PATCH v4 1/2] virtio_blk: Add control virtqueue support
config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20261010/202610100905.au1oY0vX-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261010/202610100905.au1oY0vX-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/202610100905.au1oY0vX-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/block/virtio_blk.c:1000:12: warning: 'virtblk_ctrl_vq_request' defined but not used [-Wunused-function]
1000 | static int virtblk_ctrl_vq_request(struct virtio_blk *vblk,
| ^~~~~~~~~~~~~~~~~~~~~~~
vim +/virtblk_ctrl_vq_request +1000 drivers/block/virtio_blk.c
998
999 /* Submit a control-queue request and wait for completion. */
> 1000 static int virtblk_ctrl_vq_request(struct virtio_blk *vblk,
1001 struct virtblk_ctrl_request *creq,
1002 struct scatterlist *sgs[],
1003 unsigned int out_sgs, unsigned int in_sgs)
1004 {
1005 struct virtblk_ctrl_completion *comp;
1006 unsigned long flags;
1007 int err;
1008
1009 /*
1010 * GFP_NOIO: this may be reached on the bio-submission path
1011 * (memory reclaim writing back dirty pages to this same device),
1012 * so GFP_KERNEL could self-deadlock.
1013 */
1014 comp = kmalloc_obj(*comp, GFP_NOIO);
1015 if (!comp)
1016 return -ENOMEM;
1017 init_completion(&comp->done);
1018 comp->abandoned = false;
1019
1020 mutex_lock(&vblk->ctrl_vq.mutex);
1021 creq->compl = comp;
1022
1023 spin_lock_irqsave(&vblk->ctrl_vq.lock, flags);
1024 if (vblk->ctrl_vq.dead) {
1025 spin_unlock_irqrestore(&vblk->ctrl_vq.lock, flags);
1026 mutex_unlock(&vblk->ctrl_vq.mutex);
1027 kfree(comp);
1028 creq->compl = NULL;
1029 return -ENODEV;
1030 }
1031 err = virtqueue_add_sgs(vblk->ctrl_vq.vq, sgs, out_sgs, in_sgs, creq, GFP_ATOMIC);
1032 if (!err) {
1033 vblk->ctrl_vq.inflight++;
1034 virtqueue_kick(vblk->ctrl_vq.vq);
1035 }
1036 spin_unlock_irqrestore(&vblk->ctrl_vq.lock, flags);
1037 if (err) {
1038 mutex_unlock(&vblk->ctrl_vq.mutex);
1039 kfree(comp);
1040 creq->compl = NULL;
1041 return err;
1042 }
1043
1044 if (wait_for_completion_timeout(&comp->done, VIRTBLK_CTRL_VQ_TIMEOUT)) {
1045 mutex_unlock(&vblk->ctrl_vq.mutex);
1046 kfree(comp);
1047 creq->compl = NULL;
1048 return 0;
1049 }
1050
1051 /*
1052 * The host hasn't responded within the timeout. @creq is still
1053 * owned by the device, so don't touch its DMA-target fields or
1054 * free it here. Mark it abandoned and hand ownership of both @creq
1055 * and @comp to whichever of virtblk_ctrlq_callback() or
1056 * virtblk_ctrl_vq_drain() retrieves the buffer later; unlock the
1057 * mutex so subsequent requests aren't serialized behind an
1058 * unresponsive host.
1059 */
1060 spin_lock_irqsave(&vblk->ctrl_vq.lock, flags);
1061 comp->abandoned = true;
1062 spin_unlock_irqrestore(&vblk->ctrl_vq.lock, flags);
1063 mutex_unlock(&vblk->ctrl_vq.mutex);
1064
1065 dev_warn(&vblk->vdev->dev,
1066 "control queue request timed out, abandoning\n");
1067 return -ETIMEDOUT;
1068 }
1069
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-10-10 1:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 4:17 [PATCH v4 0/2] FBE virtualization: inline encryption for virtio-blk guests Linlin Zhang
2026-10-09 4:17 ` [PATCH v4 1/2] virtio_blk: Add control virtqueue support Linlin Zhang
2026-10-09 4:28 ` sashiko-bot
2026-10-10 1:13 ` kernel test robot [this message]
2026-10-09 4:17 ` [PATCH v4 2/2] virtio_blk: add inline encryption support Linlin Zhang
2026-10-09 4:33 ` sashiko-bot
2026-10-10 4:58 ` kernel test robot
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=202610100905.au1oY0vX-lkp@intel.com \
--to=lkp@intel.com \
--cc=axboe@kernel.dk \
--cc=ebiggers@kernel.org \
--cc=eperezma@redhat.com \
--cc=jasowangio@gmail.com \
--cc=linlin.zhang@oss.qualcomm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/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.