* [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-22 19:14 ` Dexuan Cui via iommu
0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui @ 2022-06-22 19:14 UTC (permalink / raw)
To: hch, m.szyprowski, robin.murphy, iommu, linux-kernel
Cc: linux-hyperv, mikelley, Andrea.Parri, Tianyu.Lan, Dexuan Cui
The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.
Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
kernel/dma/direct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index e978f36e6be8..8d0b68a17042 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -357,7 +357,7 @@ void dma_direct_free(struct device *dev, size_t size,
} else {
if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
- if (dma_set_encrypted(dev, cpu_addr, 1 << page_order))
+ if (dma_set_encrypted(dev, cpu_addr, size))
return;
}
@@ -392,7 +392,6 @@ void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir)
{
- unsigned int page_order = get_order(size);
void *vaddr = page_address(page);
/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
@@ -400,7 +399,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
dma_free_from_pool(dev, vaddr, size))
return;
- if (dma_set_encrypted(dev, vaddr, 1 << page_order))
+ if (dma_set_encrypted(dev, vaddr, size))
return;
__dma_direct_free_pages(dev, page, size);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-22 19:14 ` Dexuan Cui via iommu
0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui via iommu @ 2022-06-22 19:14 UTC (permalink / raw)
To: hch, m.szyprowski, robin.murphy, iommu, linux-kernel
Cc: Dexuan Cui, linux-hyperv, Tianyu.Lan, Andrea.Parri, mikelley
The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.
Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
kernel/dma/direct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index e978f36e6be8..8d0b68a17042 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -357,7 +357,7 @@ void dma_direct_free(struct device *dev, size_t size,
} else {
if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
- if (dma_set_encrypted(dev, cpu_addr, 1 << page_order))
+ if (dma_set_encrypted(dev, cpu_addr, size))
return;
}
@@ -392,7 +392,6 @@ void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir)
{
- unsigned int page_order = get_order(size);
void *vaddr = page_address(page);
/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
@@ -400,7 +399,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
dma_free_from_pool(dev, vaddr, size))
return;
- if (dma_set_encrypted(dev, vaddr, 1 << page_order))
+ if (dma_set_encrypted(dev, vaddr, size))
return;
__dma_direct_free_pages(dev, page, size);
}
--
2.25.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
2022-06-22 19:14 ` Dexuan Cui via iommu
@ 2022-06-23 5:43 ` Christoph Hellwig
-1 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 5:43 UTC (permalink / raw)
To: Dexuan Cui
Cc: hch, m.szyprowski, robin.murphy, iommu, linux-kernel,
linux-hyperv, mikelley, Andrea.Parri, Tianyu.Lan
On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
>
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
see:
commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag: dma-mapping-5.19-2022-05-25)
Author: Robin Murphy <robin.murphy@arm.com>
Date: Fri May 20 18:10:13 2022 +0100
dma-direct: don't over-decrypt memory
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23 5:43 ` Christoph Hellwig
0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 5:43 UTC (permalink / raw)
To: Dexuan Cui
Cc: linux-hyperv, Tianyu.Lan, Andrea.Parri, linux-kernel, mikelley,
iommu, robin.murphy, hch
On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
>
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
see:
commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag: dma-mapping-5.19-2022-05-25)
Author: Robin Murphy <robin.murphy@arm.com>
Date: Fri May 20 18:10:13 2022 +0100
dma-direct: don't over-decrypt memory
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
2022-06-23 5:43 ` Christoph Hellwig
@ 2022-06-23 7:00 ` Dexuan Cui via iommu
-1 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui @ 2022-06-23 7:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: m.szyprowski, robin.murphy, iommu, linux-kernel, linux-hyperv,
Michael Kelley (LINUX),
Andrea Parri, Tianyu Lan
> From: Christoph Hellwig <hch@lst.de>
> Sent: Wednesday, June 22, 2022 10:44 PM
> To: Dexuan Cui <decui@microsoft.com>
> ...
> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> > The third parameter of dma_set_encrypted() is a size in bytes rather than
> > the number of pages.
> >
> > Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
> helpers")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
>
> see:
>
> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
> dma-mapping-5.19-2022-05-25)
> Author: Robin Murphy <robin.murphy@arm.com>
> Date: Fri May 20 18:10:13 2022 +0100
>
> dma-direct: don't over-decrypt memory
It looks like commit 4a37f3dd9a831 fixed a different issue?
Here my patch is for the latest mainline:
In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
out_encrypt_pages:
if (dma_set_encrypted(dev, page_address(page), size))
However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23 7:00 ` Dexuan Cui via iommu
0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui via iommu @ 2022-06-23 7:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
Michael Kelley (LINUX),
iommu, robin.murphy
> From: Christoph Hellwig <hch@lst.de>
> Sent: Wednesday, June 22, 2022 10:44 PM
> To: Dexuan Cui <decui@microsoft.com>
> ...
> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> > The third parameter of dma_set_encrypted() is a size in bytes rather than
> > the number of pages.
> >
> > Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
> helpers")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
>
> see:
>
> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
> dma-mapping-5.19-2022-05-25)
> Author: Robin Murphy <robin.murphy@arm.com>
> Date: Fri May 20 18:10:13 2022 +0100
>
> dma-direct: don't over-decrypt memory
It looks like commit 4a37f3dd9a831 fixed a different issue?
Here my patch is for the latest mainline:
In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
out_encrypt_pages:
if (dma_set_encrypted(dev, page_address(page), size))
However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
Thanks,
-- Dexuan
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
2022-06-23 7:00 ` Dexuan Cui via iommu
@ 2022-06-23 9:01 ` Robin Murphy
-1 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2022-06-23 9:01 UTC (permalink / raw)
To: Dexuan Cui, Christoph Hellwig
Cc: m.szyprowski, iommu, linux-kernel, linux-hyperv,
Michael Kelley (LINUX),
Andrea Parri, Tianyu Lan
On 2022-06-23 08:00, Dexuan Cui wrote:
>> From: Christoph Hellwig <hch@lst.de>
>> Sent: Wednesday, June 22, 2022 10:44 PM
>> To: Dexuan Cui <decui@microsoft.com>
>> ...
>> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
>>> The third parameter of dma_set_encrypted() is a size in bytes rather than
>>> the number of pages.
>>>
>>> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
>> helpers")
>>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>>
>> see:
>>
>> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
>> dma-mapping-5.19-2022-05-25)
>> Author: Robin Murphy <robin.murphy@arm.com>
>> Date: Fri May 20 18:10:13 2022 +0100
>>
>> dma-direct: don't over-decrypt memory
>
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
> out_encrypt_pages:
> if (dma_set_encrypted(dev, page_address(page), size))
>
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
I think technically you're both right - these instances clearly have a
history tracing back to the original bug that my patch addressed, but
the refactoring then made them into their own distinct bug in terms of
the internal dma_set_encrypted() interface, per the commit message here.
Apparently I failed to spot this when forward-porting 4a37f3dd9a831 from
5.10 (as the commit message says, don't ask... ;) ) - I guess I was only
looking at where the set_memory_*() callsites had moved to. For this patch,
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks
Robin.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23 9:01 ` Robin Murphy
0 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2022-06-23 9:01 UTC (permalink / raw)
To: Dexuan Cui, Christoph Hellwig
Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
Michael Kelley (LINUX),
iommu
On 2022-06-23 08:00, Dexuan Cui wrote:
>> From: Christoph Hellwig <hch@lst.de>
>> Sent: Wednesday, June 22, 2022 10:44 PM
>> To: Dexuan Cui <decui@microsoft.com>
>> ...
>> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
>>> The third parameter of dma_set_encrypted() is a size in bytes rather than
>>> the number of pages.
>>>
>>> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
>> helpers")
>>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>>
>> see:
>>
>> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
>> dma-mapping-5.19-2022-05-25)
>> Author: Robin Murphy <robin.murphy@arm.com>
>> Date: Fri May 20 18:10:13 2022 +0100
>>
>> dma-direct: don't over-decrypt memory
>
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
> out_encrypt_pages:
> if (dma_set_encrypted(dev, page_address(page), size))
>
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
I think technically you're both right - these instances clearly have a
history tracing back to the original bug that my patch addressed, but
the refactoring then made them into their own distinct bug in terms of
the internal dma_set_encrypted() interface, per the commit message here.
Apparently I failed to spot this when forward-porting 4a37f3dd9a831 from
5.10 (as the commit message says, don't ask... ;) ) - I guess I was only
looking at where the set_memory_*() callsites had moved to. For this patch,
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
2022-06-23 7:00 ` Dexuan Cui via iommu
@ 2022-06-23 13:28 ` Christoph Hellwig
-1 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 13:28 UTC (permalink / raw)
To: Dexuan Cui
Cc: Christoph Hellwig, m.szyprowski, robin.murphy, iommu,
linux-kernel, linux-hyperv, Michael Kelley (LINUX),
Andrea Parri, Tianyu Lan
On Thu, Jun 23, 2022 at 07:00:58AM +0000, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
> out_encrypt_pages:
> if (dma_set_encrypted(dev, page_address(page), size))
>
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
Indeed. I've applied the patch now.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23 13:28 ` Christoph Hellwig
0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 13:28 UTC (permalink / raw)
To: Dexuan Cui
Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
Michael Kelley (LINUX),
iommu, robin.murphy, Christoph Hellwig
On Thu, Jun 23, 2022 at 07:00:58AM +0000, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
> out_encrypt_pages:
> if (dma_set_encrypted(dev, page_address(page), size))
>
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?
Indeed. I've applied the patch now.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-28 22:07 kernel test robot
0 siblings, 0 replies; 11+ messages in thread
From: kernel test robot @ 2022-06-28 22:07 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 21693 bytes --]
::::::
:::::: Manual check reason: "low confidence static check warning: kernel/dma/direct.c:325:15: warning: Value stored to 'page_order' during its initialization is never read [clang-analyzer-deadcode.DeadStores]"
::::::
CC: llvm(a)lists.linux.dev
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <20220622191424.15777-1-decui@microsoft.com>
References: <20220622191424.15777-1-decui@microsoft.com>
TO: Dexuan Cui <decui@microsoft.com>
Hi Dexuan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.19-rc4 next-20220628]
[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]
url: https://github.com/intel-lab-lkp/linux/commits/Dexuan-Cui/dma-direct-use-the-correct-size-for-dma_set_encrypted/20220623-031721
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git de5c208d533a46a074eb46ea17f672cc005a7269
:::::: branch date: 6 days ago
:::::: commit date: 6 days ago
config: s390-randconfig-c005-20220625 (https://download.01.org/0day-ci/archive/20220629/202206290627.5IxYSe6J-lkp(a)intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project b0d6dd3905db145853c7c744ac92d49b00b1fa20)
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
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# https://github.com/intel-lab-lkp/linux/commit/2288b269c064b0b811fcb34ef45a306690456a7a
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Dexuan-Cui/dma-direct-use-the-correct-size-for-dma_set_encrypted/20220623-031721
git checkout 2288b269c064b0b811fcb34ef45a306690456a7a
# save the config file
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 clang-analyzer
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
clang-analyzer warnings: (new ones prefixed by >>)
^~~~~~~~~~~~~~~~
mm/memory.c:5465:5: note: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11
copy_to_user_page(vma, page, addr,
^
include/asm-generic/cacheflush.h:108:3: note: expanded from macro 'copy_to_user_page'
memcpy(dst, src, len); \
^~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
__underlying_##op(p, q, __fortify_size); \
^~~~~~~~~~~~~~~~~
note: expanded from here
include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
#define __underlying_memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
mm/memory.c:5469:5: warning: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
copy_from_user_page(vma, page, addr,
^
include/asm-generic/cacheflush.h:115:2: note: expanded from macro 'copy_from_user_page'
memcpy(dst, src, len)
^~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
__underlying_##op(p, q, __fortify_size); \
^~~~~~~~~~~~~~~~~
note: expanded from here
include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
#define __underlying_memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
mm/memory.c:5469:5: note: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11
copy_from_user_page(vma, page, addr,
^
include/asm-generic/cacheflush.h:115:2: note: expanded from macro 'copy_from_user_page'
memcpy(dst, src, len)
^~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
__underlying_##op(p, q, __fortify_size); \
^~~~~~~~~~~~~~~~~
note: expanded from here
include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
#define __underlying_memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
mm/memory.c:5530:25: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]
struct mm_struct *mm = current->mm;
^
arch/s390/include/asm/current.h:17:45: note: expanded from macro 'current'
#define current ((struct task_struct *const)S390_lowcore.current_task)
^~~~~~~~~~~~~~~~~~~~~~~~~
arch/s390/include/asm/lowcore.h:213:22: note: expanded from macro 'S390_lowcore'
#define S390_lowcore (*((struct lowcore *) 0))
^
mm/memory.c:5530:25: note: Dereference of null pointer
struct mm_struct *mm = current->mm;
^
arch/s390/include/asm/current.h:17:45: note: expanded from macro 'current'
#define current ((struct task_struct *const)S390_lowcore.current_task)
^~~~~~~~~~~~~~~~~~~~~~~~~
arch/s390/include/asm/lowcore.h:213:22: note: expanded from macro 'S390_lowcore'
#define S390_lowcore (*((struct lowcore *) 0))
^
Suppressed 65 warnings (53 in non-user code, 12 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
42 warnings generated.
Suppressed 42 warnings (42 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
55 warnings generated.
Suppressed 55 warnings (43 in non-user code, 12 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
58 warnings generated.
kernel/dma/direct.c:302:2: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
memset(ret, 0, size);
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
kernel/dma/direct.c:302:2: note: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11
memset(ret, 0, size);
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
>> kernel/dma/direct.c:325:15: warning: Value stored to 'page_order' during its initialization is never read [clang-analyzer-deadcode.DeadStores]
unsigned int page_order = get_order(size);
^~~~~~~~~~ ~~~~~~~~~~~~~~~
kernel/dma/direct.c:325:15: note: Value stored to 'page_order' during its initialization is never read
unsigned int page_order = get_order(size);
^~~~~~~~~~ ~~~~~~~~~~~~~~~
kernel/dma/direct.c:383:2: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
memset(ret, 0, size);
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
kernel/dma/direct.c:383:2: note: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11
memset(ret, 0, size);
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
Suppressed 55 warnings (43 in non-user code, 12 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
85 warnings generated.
arch/s390/kernel/diag.c:130:2: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]
this_cpu_inc(diag_stat.counter[nr]);
^
include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
#define this_cpu_inc(pcp) this_cpu_add(pcp, 1)
^
include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
#define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp, val)
^
include/linux/percpu-defs.h:379:11: note: expanded from macro '__pcpu_size_call'
case 4: stem##4(variable, __VA_ARGS__);break; \
^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/asm-generic/percpu.h:44:31: note: expanded from macro 'arch_raw_cpu_ptr'
#define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
^
include/linux/percpu-defs.h:231:2: note: expanded from macro 'SHIFT_PERCPU_PTR'
RELOC_HIDE((typeof(*(__p)) __kernel __force *)(__p), (__offset))
^
include/linux/compiler.h:170:28: note: expanded from macro 'RELOC_HIDE'
(typeof(ptr)) (__ptr + (off)); })
^
arch/s390/kernel/diag.c:217:2: note: Calling 'diag_stat_inc'
diag_stat_inc(DIAG_STAT_X26C);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/s390/kernel/diag.c:130:2: note: Loop condition is false. Exiting loop
this_cpu_inc(diag_stat.counter[nr]);
^
include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
#define this_cpu_inc(pcp) this_cpu_add(pcp, 1)
^
include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
#define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp, val)
^
include/linux/percpu-defs.h:375:2: note: expanded from macro '__pcpu_size_call'
__verify_pcpu_ptr(&(variable)); \
^
include/linux/percpu-defs.h:217:37: note: expanded from macro '__verify_pcpu_ptr'
#define __verify_pcpu_ptr(ptr) \
^
arch/s390/kernel/diag.c:130:2: note: Control jumps to 'case 4:' at line 130
this_cpu_inc(diag_stat.counter[nr]);
^
include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
#define this_cpu_inc(pcp) this_cpu_add(pcp, 1)
^
include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
#define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp, val)
^
include/linux/percpu-defs.h:376:2: note: expanded from macro '__pcpu_size_call'
switch(sizeof(variable)) { \
^
arch/s390/kernel/diag.c:130:2: note: Loop condition is false. Exiting loop
this_cpu_inc(diag_stat.counter[nr]);
^
include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
#define this_cpu_inc(pcp) this_cpu_add(pcp, 1)
^
include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
#define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp, val)
^
include/linux/percpu-defs.h:379:11: note: expanded from macro '__pcpu_size_call'
case 4: stem##4(variable, __VA_ARGS__);break; \
^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
arch/s390/include/asm/percpu.h:33:10: note: expanded from macro 'arch_this_cpu_to_op_simple'
ptr__ = raw_cpu_ptr(&(pcp)); \
^
vim +/page_order +325 kernel/dma/direct.c
a8463d4b0e47d1f lib/dma-noop.c Christian Borntraeger 2016-02-02 321
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 322 void dma_direct_free(struct device *dev, size_t size,
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 323 void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
a8463d4b0e47d1f lib/dma-noop.c Christian Borntraeger 2016-02-02 324 {
c10f07aa27dadf5 lib/dma-direct.c Christoph Hellwig 2018-03-19 @325 unsigned int page_order = get_order(size);
080321d3b3139b3 lib/dma-direct.c Christoph Hellwig 2017-12-22 326
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 327 if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
f4111e39a52aa5d kernel/dma/direct.c Claire Chang 2021-06-19 328 !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 329 /* cpu_addr is a struct page cookie, not a kernel address */
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 330 dma_free_contiguous(dev, cpu_addr, size);
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 331 return;
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 332 }
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 333
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 334 if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 335 !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 336 !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
3de18c865f504ab kernel/dma/direct.c Linus Torvalds 2021-09-03 337 !dev_is_dma_coherent(dev) &&
f4111e39a52aa5d kernel/dma/direct.c Claire Chang 2021-06-19 338 !is_swiotlb_for_alloc(dev)) {
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 339 arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 340 return;
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 341 }
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig 2020-08-17 342
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 343 if (IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 344 !dev_is_dma_coherent(dev)) {
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 345 if (!dma_release_from_global_coherent(page_order, cpu_addr))
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 346 WARN_ON_ONCE(1);
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 347 return;
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 348 }
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig 2021-06-23 349
76a19940bd62a81 kernel/dma/direct.c David Rientjes 2020-04-14 350 /* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
849facea92fa68d kernel/dma/direct.c Christoph Hellwig 2020-10-07 351 if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
76a19940bd62a81 kernel/dma/direct.c David Rientjes 2020-04-14 352 dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
76a19940bd62a81 kernel/dma/direct.c David Rientjes 2020-04-14 353 return;
76a19940bd62a81 kernel/dma/direct.c David Rientjes 2020-04-14 354
f5ff79fddf0efec kernel/dma/direct.c Christoph Hellwig 2022-02-26 355 if (is_vmalloc_addr(cpu_addr)) {
3acac065508f6cc kernel/dma/direct.c Christoph Hellwig 2019-10-29 356 vunmap(cpu_addr);
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig 2021-10-21 357 } else {
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig 2021-10-21 358 if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
999a5d1203baa7c kernel/dma/direct.c Christoph Hellwig 2020-02-21 359 arch_dma_clear_uncached(cpu_addr, size);
2288b269c064b0b kernel/dma/direct.c Dexuan Cui 2022-06-22 360 if (dma_set_encrypted(dev, cpu_addr, size))
a90cf3043748934 kernel/dma/direct.c Christoph Hellwig 2021-11-09 361 return;
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig 2021-10-21 362 }
3acac065508f6cc kernel/dma/direct.c Christoph Hellwig 2019-10-29 363
f4111e39a52aa5d kernel/dma/direct.c Claire Chang 2021-06-19 364 __dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);
a8463d4b0e47d1f lib/dma-noop.c Christian Borntraeger 2016-02-02 365 }
a8463d4b0e47d1f lib/dma-noop.c Christian Borntraeger 2016-02-02 366
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-06-28 22:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-22 19:14 [PATCH] dma-direct: use the correct size for dma_set_encrypted() Dexuan Cui
2022-06-22 19:14 ` Dexuan Cui via iommu
2022-06-23 5:43 ` Christoph Hellwig
2022-06-23 5:43 ` Christoph Hellwig
2022-06-23 7:00 ` Dexuan Cui
2022-06-23 7:00 ` Dexuan Cui via iommu
2022-06-23 9:01 ` Robin Murphy
2022-06-23 9:01 ` Robin Murphy
2022-06-23 13:28 ` Christoph Hellwig
2022-06-23 13:28 ` Christoph Hellwig
2022-06-28 22:07 kernel test robot
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.