From: Dan Carpenter <dan.carpenter@oracle.com>
To: kbuild@lists.01.org, Steve Sistare <steven.sistare@oracle.com>
Cc: lkp@intel.com, kbuild-all@lists.01.org,
Linux Memory Management List <linux-mm@kvack.org>,
Alex Williamson <alex.williamson@redhat.com>,
Cornelia Huck <cohuck@redhat.com>
Subject: [kbuild] [linux-next:master 6931/12022] drivers/vfio/vfio_iommu_type1.c:1093 vfio_dma_do_unmap() warn: impossible condition '(size > (~0)) => (0-u32max > u32max)'
Date: Mon, 22 Feb 2021 17:10:43 +0300 [thread overview]
Message-ID: <20210222141043.GW2222@kadam> (raw)
[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 37dfbfbdca66834bc0f64ec9b35e09ac6c8898da
commit: 0f53afa12baec8c00f5d1d6afb49325ada105253 [6931/12022] vfio/type1: unmap cleanup
config: i386-randconfig-m021-20210222 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
drivers/vfio/vfio_iommu_type1.c:1093 vfio_dma_do_unmap() warn: impossible condition '(size > (~0)) => (0-u32max > u32max)'
vim +1093 drivers/vfio/vfio_iommu_type1.c
73fa0d10d077d9 Alex Williamson 2012-07-31 1071 static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
331e33d2960c82 Kirti Wankhede 2020-05-29 1072 struct vfio_iommu_type1_dma_unmap *unmap,
331e33d2960c82 Kirti Wankhede 2020-05-29 1073 struct vfio_bitmap *bitmap)
73fa0d10d077d9 Alex Williamson 2012-07-31 1074 {
c086de818dd81c Kirti Wankhede 2016-11-17 1075 struct vfio_dma *dma, *dma_last = NULL;
331e33d2960c82 Kirti Wankhede 2020-05-29 1076 size_t unmapped = 0, pgsize;
0f53afa12baec8 Steve Sistare 2021-01-29 1077 int ret = -EINVAL, retries = 0;
331e33d2960c82 Kirti Wankhede 2020-05-29 1078 unsigned long pgshift;
0f53afa12baec8 Steve Sistare 2021-01-29 1079 dma_addr_t iova = unmap->iova;
0f53afa12baec8 Steve Sistare 2021-01-29 1080 unsigned long size = unmap->size;
^^^^^^^^^^^^^^^^^^
73fa0d10d077d9 Alex Williamson 2012-07-31 1081
cade075f265b25 Kirti Wankhede 2020-05-29 1082 mutex_lock(&iommu->lock);
cade075f265b25 Kirti Wankhede 2020-05-29 1083
331e33d2960c82 Kirti Wankhede 2020-05-29 1084 pgshift = __ffs(iommu->pgsize_bitmap);
331e33d2960c82 Kirti Wankhede 2020-05-29 1085 pgsize = (size_t)1 << pgshift;
cade075f265b25 Kirti Wankhede 2020-05-29 1086
0f53afa12baec8 Steve Sistare 2021-01-29 1087 if (iova & (pgsize - 1))
cade075f265b25 Kirti Wankhede 2020-05-29 1088 goto unlock;
cade075f265b25 Kirti Wankhede 2020-05-29 1089
0f53afa12baec8 Steve Sistare 2021-01-29 1090 if (!size || size & (pgsize - 1))
cade075f265b25 Kirti Wankhede 2020-05-29 1091 goto unlock;
73fa0d10d077d9 Alex Williamson 2012-07-31 1092
0f53afa12baec8 Steve Sistare 2021-01-29 @1093 if (iova + size - 1 < iova || size > SIZE_MAX)
size is unsigned long and SIZE_MAX is ULONG_MAX so "size > SIZE_MAX"
does not make sense.
Is the " - 1" intentional on the other overflow check? As in it's okay
to wrap around to zero but not further than that? Sometimes this is
intentional but it requires more subsystem expertise than I possess.
cade075f265b25 Kirti Wankhede 2020-05-29 1094 goto unlock;
73fa0d10d077d9 Alex Williamson 2012-07-31 1095
331e33d2960c82 Kirti Wankhede 2020-05-29 1096 /* When dirty tracking is enabled, allow only min supported pgsize */
331e33d2960c82 Kirti Wankhede 2020-05-29 1097 if ((unmap->flags & VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP) &&
331e33d2960c82 Kirti Wankhede 2020-05-29 1098 (!iommu->dirty_page_tracking || (bitmap->pgsize != pgsize))) {
331e33d2960c82 Kirti Wankhede 2020-05-29 1099 goto unlock;
331e33d2960c82 Kirti Wankhede 2020-05-29 1100 }
73fa0d10d077d9 Alex Williamson 2012-07-31 1101
331e33d2960c82 Kirti Wankhede 2020-05-29 1102 WARN_ON((pgsize - 1) & PAGE_MASK);
331e33d2960c82 Kirti Wankhede 2020-05-29 1103 again:
1ef3e2bc04223f Alex Williamson 2014-02-26 1104 /*
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 41675 bytes --]
[-- Attachment #3: Type: text/plain, Size: 149 bytes --]
_______________________________________________
kbuild mailing list -- kbuild@lists.01.org
To unsubscribe send an email to kbuild-leave@lists.01.org
next reply other threads:[~2021-02-22 14:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 14:10 Dan Carpenter [this message]
2021-02-22 22:51 ` [kbuild] [linux-next:master 6931/12022] drivers/vfio/vfio_iommu_type1.c:1093 vfio_dma_do_unmap() warn: impossible condition '(size > (~0)) => (0-u32max > u32max)' Alex Williamson
2021-02-22 23:17 ` Alex Williamson
2021-02-23 13:56 ` Steven Sistare
2021-02-23 17:45 ` Alex Williamson
2021-02-23 20:37 ` Steven Sistare
2021-02-23 21:10 ` Alex Williamson
2021-02-23 21:52 ` Steven Sistare
2021-02-23 23:58 ` Steven Sistare
2021-02-24 22:55 ` Alex Williamson
2021-02-25 15:25 ` Steven Sistare
2021-02-25 18:00 ` Alex Williamson
2021-02-25 18:52 ` Steven Sistare
2021-02-25 19:12 ` Alex Williamson
2021-02-23 13:20 ` Steven Sistare
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=20210222141043.GW2222@kadam \
--to=dan.carpenter@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=kbuild-all@lists.01.org \
--cc=kbuild@lists.01.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=steven.sistare@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).