Re: [PATCH] Fixed styling issues by adding blank line after definitions.
On Tue, Jun 16, 2020 at 09:26:55PM +0100, dan love wrote:
> Signed-off-by: dan love
> ---
> drivers/staging/comedi/comedi_fops.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/comedi/comedi_fops.c
> b/drivers/staging/comedi/comedi_fops.c
> index e85a99b68f31..3f70e5dfac39 100644
> --- a/drivers/staging/comedi/comedi_fops.c
> +++ b/drivers/staging/comedi/comedi_fops.c
> @@ -2169,6 +2169,7 @@ static long comedi_unlocked_ioctl(struct file *file,
> unsigned int cmd,
> break;
> case COMEDI_CHANINFO: {
> struct comedi_chaninfo it;
> +
> if (copy_from_user(, (void __user *)arg, sizeof(it)))
> rc = -EFAULT;
> else
> @@ -2177,6 +2178,7 @@ static long comedi_unlocked_ioctl(struct file *file,
> unsigned int cmd,
> }
> case COMEDI_RANGEINFO: {
> struct comedi_rangeinfo it;
> +
> if (copy_from_user(, (void __user *)arg, sizeof(it)))
> rc = -EFAULT;
> else
> @@ -2249,6 +2251,7 @@ static long comedi_unlocked_ioctl(struct file *file,
> unsigned int cmd,
> }
> case COMEDI_INSN: {
> struct comedi_insn insn;
> +
> if (copy_from_user(, (void __user *)arg, sizeof(insn)))
> rc = -EFAULT;
> else
> --
> 2.17.1
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: gasket: Convert get_user_pages*() --> pin_user_pages*()
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: Souptick Joarder
Acked-by: Dan Carpenter
Cc: John Hubbard
Cc: Dan Carpenter
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
v2:
Added review tag.
drivers/staging/gasket/gasket_page_table.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b/drivers/staging/gasket/gasket_page_table.c
index f6d7157..d712ad4 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -449,7 +449,7 @@ static bool gasket_release_page(struct page *page)
if (!PageReserved(page))
SetPageDirty(page);
- put_page(page);
+ unpin_user_page(page);
return true;
}
@@ -486,12 +486,12 @@ static int gasket_perform_mapping(struct
gasket_page_table *pg_tbl,
ptes[i].dma_addr = pg_tbl->coherent_pages[0].paddr +
off + i * PAGE_SIZE;
} else {
- ret = get_user_pages_fast(page_addr - offset, 1,
+ ret = pin_user_pages_fast(page_addr - offset, 1,
FOLL_WRITE, );
if (ret <= 0) {
dev_err(pg_tbl->device,
- "get user pages failed for addr=0x%lx,
offset=0x%lx [ret=%d]\n",
+ "pin user pages failed for addr=0x%lx,
offset=0x%lx [ret=%d]\n",
page_addr, offset, ret);
return ret ? ret : -ENOMEM;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: kpc2000: kpc_dma: Convert get_user_pages() --> pin_user_pages()
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Bharath Vedartham
Cc: Dan Carpenter
---
drivers/staging/kpc2000/kpc_dma/fileops.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c
b/drivers/staging/kpc2000/kpc_dma/fileops.c
index bcce86c..1f5ab81 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -76,10 +76,10 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
// Lock the user buffer pages in memory, and hold on to the page
pointers (for the sglist)
mmap_read_lock(current->mm); /* get memory map semaphore */
- rv = get_user_pages(iov_base, acd->page_count, FOLL_TOUCH | FOLL_WRITE
| FOLL_GET, acd->user_pages, NULL);
+ rv = pin_user_pages(iov_base, acd->page_count, FOLL_TOUCH | FOLL_WRITE,
acd->user_pages, NULL);
mmap_read_unlock(current->mm);/* release the semaphore */
if (rv != acd->page_count) {
- dev_err(>ldev->pldev->dev, "Couldn't get_user_pages
(%ld)\n", rv);
+ dev_err(>ldev->pldev->dev, "Couldn't pin_user_pages
(%ld)\n", rv);
goto err_get_user_pages;
}
@@ -189,14 +189,11 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
sg_free_table(>sgt);
err_dma_map_sg:
err_alloc_sg_table:
- for (i = 0 ; i < acd->page_count ; i++)
- put_page(acd->user_pages[i]);
+ unpin_user_pages(acd->user_pages, acd->page_count);
err_get_user_pages:
- if (rv > 0) {
- for (i = 0; i < rv; i++)
- put_pages(acd->user_pages[i])
- }
+ if (rv > 0)
+ unpin_user_pages(acd->user_pages, rv);
kfree(acd->user_pages);
err_alloc_userpages:
kfree(acd);
@@ -221,8 +218,7 @@ void transfer_complete_cb(struct aio_cb_data *acd, size_t
xfr_count, u32 flags)
set_page_dirty_lock(acd->user_pages[i]);
}
- for (i = 0 ; i < acd->page_count ; i++)
- put_page(acd->user_pages[i]);
+ unpin_user_pages(acd->user_pages, acd->page_count);
sg_free_table(>sgt);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: kpc2000: kpc_dma: Convert set_page_dirty() --> set_page_dirty_lock()
First, convert set_page_dirty() to set_page_dirty_lock()
Second, there is an interval in there after set_page_dirty() and
before put_page(), in which the device could be running and setting
pages dirty. Moving set_page_dirty_lock() after dma_unmap_sg().
Signed-off-by: Souptick Joarder
Suggested-by: John Hubbard
Cc: Dan Carpenter
Cc: Bharath Vedartham
---
drivers/staging/kpc2000/kpc_dma/fileops.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c
b/drivers/staging/kpc2000/kpc_dma/fileops.c
index b136353..bcce86c 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -214,13 +214,13 @@ void transfer_complete_cb(struct aio_cb_data *acd,
size_t xfr_count, u32 flags)
BUG_ON(!acd->ldev);
BUG_ON(!acd->ldev->pldev);
+ dma_unmap_sg(>ldev->pldev->dev, acd->sgt.sgl, acd->sgt.nents,
acd->ldev->dir);
+
for (i = 0 ; i < acd->page_count ; i++) {
if (!PageReserved(acd->user_pages[i]))
- set_page_dirty(acd->user_pages[i]);
+ set_page_dirty_lock(acd->user_pages[i]);
}
- dma_unmap_sg(>ldev->pldev->dev, acd->sgt.sgl, acd->sgt.nents,
acd->ldev->dir);
-
for (i = 0 ; i < acd->page_count ; i++)
put_page(acd->user_pages[i]);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: kpc2000: kpc_dma: Remove excess goto statement
As 3 goto level referring to same common code, those can be
accomodated with a single goto level and renameing it to
unpin_user_pages.
Signed-off-by: Souptick Joarder
Cc: Dan Carpenter
Cc: John Hubbard
---
drivers/staging/kpc2000/kpc_dma/fileops.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c
b/drivers/staging/kpc2000/kpc_dma/fileops.c
index 1f5ab81..b0fcde5 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -35,7 +35,7 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
unsigned long iov_base, size_t iov_len)
{
unsigned int i = 0;
- int rv = 0;
+ int rv = 0, nr_pages = 0;
struct kpc_dma_device *ldev;
struct aio_cb_data *acd;
DECLARE_COMPLETION_ONSTACK(done);
@@ -79,22 +79,23 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
rv = pin_user_pages(iov_base, acd->page_count, FOLL_TOUCH | FOLL_WRITE,
acd->user_pages, NULL);
mmap_read_unlock(current->mm);/* release the semaphore */
if (rv != acd->page_count) {
+ nr_pages = rv;
dev_err(>ldev->pldev->dev, "Couldn't pin_user_pages
(%ld)\n", rv);
- goto err_get_user_pages;
+ goto unpin_user_pages;
}
-
+ nr_pages = acd->page_count;
// Allocate and setup the sg_table (scatterlist entries)
rv = sg_alloc_table_from_pages(>sgt, acd->user_pages,
acd->page_count, iov_base & (PAGE_SIZE - 1), iov_len, GFP_KERNEL);
if (rv) {
dev_err(>ldev->pldev->dev, "Couldn't alloc sg_table
(%ld)\n", rv);
- goto err_alloc_sg_table;
+ goto unpin_user_pages;
}
// Setup the DMA mapping for all the sg entries
acd->mapped_entry_count = dma_map_sg(>pldev->dev, acd->sgt.sgl,
acd->sgt.nents, ldev->dir);
if (acd->mapped_entry_count <= 0) {
dev_err(>ldev->pldev->dev, "Couldn't dma_map_sg (%d)\n",
acd->mapped_entry_count);
- goto err_dma_map_sg;
+ goto unpin_user_pages;
}
// Calculate how many descriptors are actually needed for this transfer.
@@ -187,13 +188,9 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
unlock_engine(ldev);
dma_unmap_sg(>pldev->dev, acd->sgt.sgl, acd->sgt.nents,
ldev->dir);
sg_free_table(>sgt);
- err_dma_map_sg:
- err_alloc_sg_table:
- unpin_user_pages(acd->user_pages, acd->page_count);
-
- err_get_user_pages:
- if (rv > 0)
- unpin_user_pages(acd->user_pages, rv);
+ unpin_user_pages:
+ if (nr_pages > 0)
+ unpin_user_pages(acd->user_pages, nr_pages);
kfree(acd->user_pages);
err_alloc_userpages:
kfree(acd);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: kpc2000: Unpin partial pinned pages
There is a bug, when get_user_pages() failed but partially pinned
pages are not unpinned. Fixed it.
Also, int is more appropriate type for rv. Changed it.
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Bharath Vedartham
Cc: Dan Carpenter
---
drivers/staging/kpc2000/kpc_dma/fileops.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c
b/drivers/staging/kpc2000/kpc_dma/fileops.c
index 8975346..b136353 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -35,7 +35,7 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
unsigned long iov_base, size_t iov_len)
{
unsigned int i = 0;
- long rv = 0;
+ int rv = 0;
struct kpc_dma_device *ldev;
struct aio_cb_data *acd;
DECLARE_COMPLETION_ONSTACK(done);
@@ -193,6 +193,10 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
put_page(acd->user_pages[i]);
err_get_user_pages:
+ if (rv > 0) {
+ for (i = 0; i < rv; i++)
+ put_pages(acd->user_pages[i])
+ }
kfree(acd->user_pages);
err_alloc_userpages:
kfree(acd);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: kpc2000: kpc_dma: Few clean up and Convert to pin_user_pages()
This series contains few clean up, minor bug fixes and Convert get_user_pages() to pin_user_pages(). I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. Souptick Joarder (4): staging: kpc2000: Unpin partial pinned pages staging: kpc2000: kpc_dma: Convert set_page_dirty() --> set_page_dirty_lock() staging: kpc2000: kpc_dma: Convert get_user_pages() --> pin_user_pages() staging: kpc2000: kpc_dma: Remove excess goto statement drivers/staging/kpc2000/kpc_dma/fileops.c | 33 ++- 1 file changed, 15 insertions(+), 18 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5 08/12] device core: Introduce multiple dma pfn offsets
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
The function of_dma_get_range() has been modified to take two additional
arguments: the "map", which is an array that holds the information
regarding the pfn offset regions, and map_size, which is the size in bytes
of the map array.
of_dma_configure() is the typical manner to set pfn offsets but there are a
number of ad hoc assignments to dev->dma_pfn_offset in the kernel driver
code. These cases now invoke the function
dma_attach_uniform_pfn_offset(dev, pfn_offset).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +--
arch/arm/mach-keystone/keystone.c | 8 ++-
arch/sh/drivers/pci/pcie-sh7786.c | 3 +-
arch/sh/kernel/dma-coherent.c | 14 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 4 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 71 ---
drivers/of/device.c | 19 +++--
drivers/of/of_private.h | 11 +--
drivers/of/unittest.c | 8 ++-
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 4 +-
drivers/usb/core/usb.c| 2 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 14 +++-
include/linux/dma-mapping.h | 38 ++
kernel/dma/coherent.c | 11 +--
kernel/dma/mapping.c | 39 ++
23 files changed, 231 insertions(+), 60 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..f1e72f99468b 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev && dev->dma_pfn_offset_map)
+ pfn -= dma_pfn_offset_from_phys_addr(dev, PFN_PHYS(pfn));
+
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
+ if (dev && dev->dma_pfn_offset_map)
+ pfn += dma_pfn_offset_from_dma_addr(dev, addr);
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..5890ec90599e 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -38,9 +39,10 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_attach_uniform_pfn_offset(dev,
keystone_dma_pfn_offset);
+
+ dev_err(dev, "set dma_pfn_offset%08lx%s\n", dev->dma_pfn_offset,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
diff --git a/arch/sh/drivers/pci/pcie-sh7786.c
b/arch/sh/drivers/pci/pcie-sh7786.c
index e0b568aaa701..3e63c6b6e070 100644
--- a/arch/sh/drivers/pci/pcie-sh7786.c
+++ b/arch/sh/drivers/pci/pcie-sh7786.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -487,7 +488,7 @@ int pcibios_map_platform_irq(const struct pci_dev *pdev, u8
slot, u8 pin)
void pcibios_bus_add_device(struct pci_dev *pdev)
{
- pdev->dev.dma_pfn_offset = dma_pfn_offset;
+ dma_attach_uniform_pfn_offset(>dev, dma_pfn_offset);
}
static int __init sh7786_pcie_core_init(void)
diff --git a/arch/sh/kernel/dma-coherent.c b/arch/sh/kernel/dma-coherent.c
index d4811691b93c..f4a092e74910 100644
--- a/arch/sh/kernel/dma-coherent.c
+++ b/arch/sh/kernel/dma-coherent.c
@@ -14,6 +14,7 @@ void *arch_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle,
{
void *ret, *ret_nocache;
int order = get_order(size);
+ phys_addr_t phys;
gfp |= __GFP_ZERO;
@@ -34,11 +35,12 @@ void
[PATCH v5 00/12] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets.
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range() call.
Commit "device core: Add ability to handle multiple dma offsets"
-- align comment in device.h (AndyS).
-- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
dma_pfn_offset_region (AndyS).
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > > now as there can be a bit more discussion on what is best. It will be > > > introduced as a separate patch later on after this one is merged. > > > > To this larger audience and last week without reply: > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > > > Are there _any_ fastpath uses of kfree or vfree? > > I'd consider kfree performance critical for cases where it is called > under locks. If possible the kfree is moved outside of the critical > section, but we have rbtrees or lists that get deleted under locks and > restructuring the code to do eg. splice and free it outside of the lock > is not always possible. Not just performance critical, but correctness critical. Since kvfree() may allocate from the vmalloc allocator, I really think that kvfree() should assert that it's !in_atomic(). Otherwise we can get into trouble if we end up calling vfree() and have to take the mutex. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > v4: > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > so that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a bit more discussion on what is best. It will be > > introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? I'd consider kfree performance critical for cases where it is called under locks. If possible the kfree is moved outside of the critical section, but we have rbtrees or lists that get deleted under locks and restructuring the code to do eg. splice and free it outside of the lock is not always possible. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? I worked on adding a 'free' a couple of years ago. That was capable of freeing percpu, vmalloc, kmalloc and alloc_pages memory. I ran into trouble when I tried to free kmem_cache_alloc memory -- it works for slab and slub, but not slob (because slob needs the size from the kmem_cache). My motivation for this was to change kfree_rcu() to just free_rcu(). > To eliminate these mispairings at a runtime cost of four > comparisons, should the kfree/vfree/kvfree/kfree_const > functions be consolidated into a single kfree? I would say to leave kfree() alone and just introduce free() as a new default. There's some weird places in the kernel that have a 'free' symbol of their own, but those should be renamed anyway. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Fixed styling issues by adding blank line after definitions.
Signed-off-by: dan love
---
drivers/staging/comedi/comedi_fops.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index e85a99b68f31..3f70e5dfac39 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2169,6 +2169,7 @@ static long comedi_unlocked_ioctl(struct file *file,
unsigned int cmd,
break;
case COMEDI_CHANINFO: {
struct comedi_chaninfo it;
+
if (copy_from_user(, (void __user *)arg, sizeof(it)))
rc = -EFAULT;
else
@@ -2177,6 +2178,7 @@ static long comedi_unlocked_ioctl(struct file *file,
unsigned int cmd,
}
case COMEDI_RANGEINFO: {
struct comedi_rangeinfo it;
+
if (copy_from_user(, (void __user *)arg, sizeof(it)))
rc = -EFAULT;
else
@@ -2249,6 +2251,7 @@ static long comedi_unlocked_ioctl(struct file *file,
unsigned int cmd,
}
case COMEDI_INSN: {
struct comedi_insn insn;
+
if (copy_from_user(, (void __user *)arg, sizeof(insn)))
rc = -EFAULT;
else
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 2:53 PM, Joe Perches wrote:
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
v4:
- Break out the memzero_explicit() change as suggested by Dan Carpenter
so that it can be backported to stable.
- Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
now as there can be a bit more discussion on what is best. It will be
introduced as a separate patch later on after this one is merged.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
Are there _any_ fastpath uses of kfree or vfree?
Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.
To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?
Something like the below:
void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;
if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}
#define kvfree kfree
#define vfree kfree
#define kfree_const kfree
How about adding CONFIG_DEBUG_VM code to check for invalid address
ranges in kfree() and vfree()? By doing this, we can catch unmatched
pairing in debug mode, but won't have the overhead when debug mode is off.
Thought?
Cheers,
Longman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > v4: > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > so that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a bit more discussion on what is best. It will be > > introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? The networking stack has various places where there will be a quick kmalloc followed by a kfree for an incoming or outgoing packet. One place that comes to mind would be esp_alloc_tmp, which does a quick allocation of some temporary kmalloc memory, processes some packet things inside of that, and then frees it, sometimes in the same function, and sometimes later in an async callback. I don't know how "fastpath" you consider this, but usually packet processing is something people want to do with minimal overhead, considering how fast NICs are these days. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 2:53 PM, Joe Perches wrote:
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
v4:
- Break out the memzero_explicit() change as suggested by Dan Carpenter
so that it can be backported to stable.
- Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
now as there can be a bit more discussion on what is best. It will be
introduced as a separate patch later on after this one is merged.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
Are there _any_ fastpath uses of kfree or vfree?
I am not sure about that, but both of them can be slow.
Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.
To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?
Something like the below:
void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;
if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}
is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the
overhead can be a bit bigger.
Cheers,
Longman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> v4:
> - Break out the memzero_explicit() change as suggested by Dan Carpenter
> so that it can be backported to stable.
> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> now as there can be a bit more discussion on what is best. It will be
> introduced as a separate patch later on after this one is merged.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
Are there _any_ fastpath uses of kfree or vfree?
Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.
To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?
Something like the below:
void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;
if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}
#define kvfree kfree
#define vfreekfree
#define kfree_const kfree
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 2:09 PM, Andrew Morton wrote: On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote: As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_. The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects. Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: git grep -w --name-only kzfree |\ xargs sed -i 's/\bkzfree\b/kfree_sensitive/' followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h. ... --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, struct mem_cgroup *); */ void * __must_check krealloc(const void *, size_t, gfp_t); void kfree(const void *); -void kzfree(const void *); +void kfree_sensitive(const void *); size_t __ksize(const void *); size_t ksize(const void *); +#define kzfree(x) kfree_sensitive(x) /* For backward compatibility */ + What was the thinking here? Is this really necessary? I suppose we could keep this around for a while to ease migration. But not for too long, please. It should be there just for 1 release cycle. I have broken out the btrfs patch to the btrfs list and I didn't make the kzfree to kfree_sensitive conversion there as that patch was in front in my patch list. So depending on which one lands first, there can be a window where the compilation may fail without this workaround. I am going to send out another patch in the next release cycle to remove it. Cheers, Longman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote: > As said by Linus: > > A symmetric naming is only helpful if it implies symmetries in use. > Otherwise it's actively misleading. > > In "kzalloc()", the z is meaningful and an important part of what the > caller wants. > > In "kzfree()", the z is actively detrimental, because maybe in the > future we really _might_ want to use that "memfill(0xdeadbeef)" or > something. The "zero" part of the interface isn't even _relevant_. > > The main reason that kzfree() exists is to clear sensitive information > that should not be leaked to other future users of the same memory > objects. > > Rename kzfree() to kfree_sensitive() to follow the example of the > recently added kvfree_sensitive() and make the intention of the API > more explicit. In addition, memzero_explicit() is used to clear the > memory to make sure that it won't get optimized away by the compiler. > > The renaming is done by using the command sequence: > > git grep -w --name-only kzfree |\ > xargs sed -i 's/\bkzfree\b/kfree_sensitive/' > > followed by some editing of the kfree_sensitive() kerneldoc and adding > a kzfree backward compatibility macro in slab.h. > > ... > > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, > struct mem_cgroup *); > */ > void * __must_check krealloc(const void *, size_t, gfp_t); > void kfree(const void *); > -void kzfree(const void *); > +void kfree_sensitive(const void *); > size_t __ksize(const void *); > size_t ksize(const void *); > > +#define kzfree(x)kfree_sensitive(x) /* For backward compatibility */ > + What was the thinking here? Is this really necessary? I suppose we could keep this around for a while to ease migration. But not for too long, please. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2][next] staging: rts5208: Use array_size() helper in vmalloc() and memset()
The vmalloc() function has no 2-factor argument form, so multiplication
factors need to be wrapped in array_size(). Also, while there, use
array_size() in memset().
This issue was found with the help of Coccinelle and, audited and fixed
manually.
Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Fix subject line and commit message. Previously, part of the subject
line, unintentionally, sneaked into the commit message.
drivers/staging/rts5208/ms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index d53dd138a356..9001570a8c94 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -2306,14 +2306,14 @@ static int ms_build_l2p_tbl(struct rtsx_chip *chip, int
seg_no)
if (!segment->l2p_table)
goto BUILD_FAIL;
}
- memset((u8 *)(segment->l2p_table), 0xff, table_size * 2);
+ memset((u8 *)(segment->l2p_table), 0xff, array_size(table_size, 2));
if (!segment->free_table) {
- segment->free_table = vmalloc(MS_FREE_TABLE_CNT * 2);
+ segment->free_table = vmalloc(array_size(MS_FREE_TABLE_CNT, 2));
if (!segment->free_table)
goto BUILD_FAIL;
}
- memset((u8 *)(segment->free_table), 0xff, MS_FREE_TABLE_CNT * 2);
+ memset((u8 *)(segment->free_table), 0xff, array_size(MS_FREE_TABLE_CNT,
2));
start = (u16)seg_no << 9;
end = (u16)(seg_no + 1) << 9;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() "memset()" is all lowercase. > is currently used for buffer clearing. However unlikely, there is still a > non-zero probability I'd say "a possibility". > that and I'd move "in [the] future" here. > the compiler may choose to optimize away the > memory clearing especially if LTO is being used in the future. To make sure > that this optimization will never happen "in these cases" > , memzero_explicit(), which is introduced in v3.18, is now used in "instead of"? > kzfree() to future-proof it. Davod ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_. The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects. Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: git grep -w --name-only kzfree |\ xargs sed -i 's/\bkzfree\b/kfree_sensitive/' followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h. Suggested-by: Joe Perches Acked-by: David Howells Acked-by: Michal Hocko Acked-by: Johannes Weiner Signed-off-by: Waiman Long --- arch/s390/crypto/prng.c | 4 +-- arch/x86/power/hibernate.c| 2 +- crypto/adiantum.c | 2 +- crypto/ahash.c| 4 +-- crypto/api.c | 2 +- crypto/asymmetric_keys/verify_pefile.c| 4 +-- crypto/deflate.c | 2 +- crypto/drbg.c | 10 +++--- crypto/ecc.c | 8 ++--- crypto/ecdh.c | 2 +- crypto/gcm.c | 2 +- crypto/gf128mul.c | 4 +-- crypto/jitterentropy-kcapi.c | 2 +- crypto/rng.c | 2 +- crypto/rsa-pkcs1pad.c | 6 ++-- crypto/seqiv.c| 2 +- crypto/shash.c| 2 +- crypto/skcipher.c | 2 +- crypto/testmgr.c | 6 ++-- crypto/zstd.c | 2 +- .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 2 +- .../allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +- drivers/crypto/amlogic/amlogic-gxl-cipher.c | 4 +-- drivers/crypto/atmel-ecc.c| 2 +- drivers/crypto/caam/caampkc.c | 28 +++ drivers/crypto/cavium/cpt/cptvf_main.c| 6 ++-- drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 12 +++ drivers/crypto/cavium/nitrox/nitrox_lib.c | 4 +-- drivers/crypto/cavium/zip/zip_crypto.c| 6 ++-- drivers/crypto/ccp/ccp-crypto-rsa.c | 6 ++-- drivers/crypto/ccree/cc_aead.c| 4 +-- drivers/crypto/ccree/cc_buffer_mgr.c | 4 +-- drivers/crypto/ccree/cc_cipher.c | 6 ++-- drivers/crypto/ccree/cc_hash.c| 8 ++--- drivers/crypto/ccree/cc_request_mgr.c | 2 +- drivers/crypto/marvell/cesa/hash.c| 2 +- .../crypto/marvell/octeontx/otx_cptvf_main.c | 6 ++-- .../marvell/octeontx/otx_cptvf_reqmgr.h | 2 +- drivers/crypto/mediatek/mtk-aes.c | 2 +- drivers/crypto/nx/nx.c| 4 +-- drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++ drivers/crypto/virtio/virtio_crypto_core.c| 2 +- drivers/md/dm-crypt.c | 32 - drivers/md/dm-integrity.c | 6 ++-- drivers/misc/ibmvmc.c | 6 ++-- .../hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +- .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c| 6 ++-- drivers/net/ppp/ppp_mppe.c| 6 ++-- drivers/net/wireguard/noise.c | 4 +-- drivers/net/wireguard/peer.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 6 ++-- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 6 ++-- drivers/net/wireless/intersil/orinoco/wext.c | 4 +-- drivers/s390/crypto/ap_bus.h | 4 +-- drivers/staging/ks7010/ks_hostif.c| 2 +- drivers/staging/rtl8723bs/core/rtw_security.c | 2 +- drivers/staging/wlan-ng/p80211netdev.c| 2 +- drivers/target/iscsi/iscsi_target_auth.c | 2 +- fs/cifs/cifsencrypt.c | 2 +- fs/cifs/connect.c | 10 +++--- fs/cifs/dfs_cache.c | 2 +- fs/cifs/misc.c| 8 ++--- fs/crypto/keyring.c | 6 ++-- fs/crypto/keysetup_v1.c | 4 +-- fs/ecryptfs/keystore.c| 4 +-- fs/ecryptfs/messaging.c
[PATCH v5 1/2] mm/slab: Use memzero_explicit() in kzfree()
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for buffer clearing. However
unlikely, there is still a non-zero probability that the compiler may
choose to optimize away the memory clearing especially if LTO is being
used in the future. To make sure that this optimization will never
happen, memzero_explicit(), which is introduced in v3.18, is now used
in kzfree() to future-proof it.
Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc: sta...@vger.kernel.org
Acked-by: Michal Hocko
Signed-off-by: Waiman Long
---
mm/slab_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9e72ba224175..37d48a56431d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
if (unlikely(ZERO_OR_NULL_PTR(mem)))
return;
ks = ksize(mem);
- memset(mem, 0, ks);
+ memzero_explicit(mem, ks);
kfree(mem);
}
EXPORT_SYMBOL(kzfree);
--
2.18.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5 0/2] mm, treewide: Rename kzfree() to kfree_sensitive()
v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer especially if LTO is used. Instead, the new kfree_sensitive() uses memzero_explicit() which won't get compiled out. Waiman Long (2): mm/slab: Use memzero_explicit() in kzfree() mm, treewide: Rename kzfree() to kfree_sensitive() arch/s390/crypto/prng.c | 4 +-- arch/x86/power/hibernate.c| 2 +- crypto/adiantum.c | 2 +- crypto/ahash.c| 4 +-- crypto/api.c | 2 +- crypto/asymmetric_keys/verify_pefile.c| 4 +-- crypto/deflate.c | 2 +- crypto/drbg.c | 10 +++--- crypto/ecc.c | 8 ++--- crypto/ecdh.c | 2 +- crypto/gcm.c | 2 +- crypto/gf128mul.c | 4 +-- crypto/jitterentropy-kcapi.c | 2 +- crypto/rng.c | 2 +- crypto/rsa-pkcs1pad.c | 6 ++-- crypto/seqiv.c| 2 +- crypto/shash.c| 2 +- crypto/skcipher.c | 2 +- crypto/testmgr.c | 6 ++-- crypto/zstd.c | 2 +- .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 2 +- .../allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +- drivers/crypto/amlogic/amlogic-gxl-cipher.c | 4 +-- drivers/crypto/atmel-ecc.c| 2 +- drivers/crypto/caam/caampkc.c | 28 +++ drivers/crypto/cavium/cpt/cptvf_main.c| 6 ++-- drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 12 +++ drivers/crypto/cavium/nitrox/nitrox_lib.c | 4 +-- drivers/crypto/cavium/zip/zip_crypto.c| 6 ++-- drivers/crypto/ccp/ccp-crypto-rsa.c | 6 ++-- drivers/crypto/ccree/cc_aead.c| 4 +-- drivers/crypto/ccree/cc_buffer_mgr.c | 4 +-- drivers/crypto/ccree/cc_cipher.c | 6 ++-- drivers/crypto/ccree/cc_hash.c| 8 ++--- drivers/crypto/ccree/cc_request_mgr.c | 2 +- drivers/crypto/marvell/cesa/hash.c| 2 +- .../crypto/marvell/octeontx/otx_cptvf_main.c | 6 ++-- .../marvell/octeontx/otx_cptvf_reqmgr.h | 2 +- drivers/crypto/mediatek/mtk-aes.c | 2 +- drivers/crypto/nx/nx.c| 4 +-- drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++ drivers/crypto/virtio/virtio_crypto_core.c| 2 +- drivers/md/dm-crypt.c | 32 - drivers/md/dm-integrity.c | 6 ++-- drivers/misc/ibmvmc.c | 6 ++-- .../hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +- .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c| 6 ++-- drivers/net/ppp/ppp_mppe.c| 6 ++-- drivers/net/wireguard/noise.c | 4 +-- drivers/net/wireguard/peer.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 6 ++-- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 6 ++-- drivers/net/wireless/intersil/orinoco/wext.c | 4 +-- drivers/s390/crypto/ap_bus.h | 4 +-- drivers/staging/ks7010/ks_hostif.c| 2 +- drivers/staging/rtl8723bs/core/rtw_security.c | 2 +- drivers/staging/wlan-ng/p80211netdev.c| 2 +- drivers/target/iscsi/iscsi_target_auth.c | 2 +- fs/cifs/cifsencrypt.c | 2 +- fs/cifs/connect.c | 10 +++--- fs/cifs/dfs_cache.c | 2 +- fs/cifs/misc.c| 8 ++--- fs/crypto/keyring.c | 6 ++-- fs/crypto/keysetup_v1.c | 4 +-- fs/ecryptfs/keystore.c| 4 +-- fs/ecryptfs/messaging.c | 2 +- include/crypto/aead.h | 2 +- include/crypto/akcipher.h
Re: [PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 10:26 AM, Dan Carpenter wrote: Last time you sent this we couldn't decide which tree it should go through. Either the crypto tree or through Andrew seems like the right thing to me. Also the other issue is that it risks breaking things if people add new kzfree() instances while we are doing the transition. Could you just add a "#define kzfree kfree_sensitive" so that things continue to compile and we can remove it in the next kernel release? regards, dan carpenter Yes, that make sure sense. Will send out v5 later today. Cheers, Longman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
On 6/16/20 10:48 AM, David Sterba wrote: On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote: In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc() was incorrectly paired with kzfree(). According to David Sterba, there isn't any sensitive information in the subvol_info that needs to be cleared before freeing. So kfree_sensitive() isn't really needed, use kfree() instead. Reported-by: David Sterba Signed-off-by: Waiman Long --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index f1dd9e4271e9..e8f7c5f00894 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp) btrfs_put_root(root); out_free: btrfs_free_path(path); - kfree_sensitive(subvol_info); + kfree(subvol_info); I would rather merge a patch doing to kzfree -> kfree instead of doing the middle step to switch it to kfree_sensitive. If it would help integration of your patchset I can push it to the next rc so there are no kzfree left in the btrfs code. Treewide change like that can take time so it would be one less problem to care about for you. Sure, I will move it forward in the patch series. Thanks, Longman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote: > In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc() > was incorrectly paired with kzfree(). According to David Sterba, there > isn't any sensitive information in the subvol_info that needs to be > cleared before freeing. So kfree_sensitive() isn't really needed, > use kfree() instead. > > Reported-by: David Sterba > Signed-off-by: Waiman Long > --- > fs/btrfs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index f1dd9e4271e9..e8f7c5f00894 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file > *file, void __user *argp) > btrfs_put_root(root); > out_free: > btrfs_free_path(path); > - kfree_sensitive(subvol_info); > + kfree(subvol_info); I would rather merge a patch doing to kzfree -> kfree instead of doing the middle step to switch it to kfree_sensitive. If it would help integration of your patchset I can push it to the next rc so there are no kzfree left in the btrfs code. Treewide change like that can take time so it would be one less problem to care about for you. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()
Last time you sent this we couldn't decide which tree it should go through. Either the crypto tree or through Andrew seems like the right thing to me. Also the other issue is that it risks breaking things if people add new kzfree() instances while we are doing the transition. Could you just add a "#define kzfree kfree_sensitive" so that things continue to compile and we can remove it in the next kernel release? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: rts5208: Use array_size() helper in vmalloc()
On Tue, Jun 16, 2020 at 01:13:12PM +0300, Dan Carpenter wrote: > On Mon, Jun 15, 2020 at 06:08:11PM -0500, Gustavo A. R. Silva wrote: > > and memset() > > Please don't start the commit message in the middle of a sentence. It's > That was, certainly, unintentional. Thanks for letting me know. -- Gustavo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Urgent Alert From Bank About Your Funds???
HSBC BANK PLC LONDON.(REGISTERED NO.1026167). ADDRESS:8 CANADA SQUARE, CANARY WHARF, LONDON E14 5HQ, UK.. Attn: Beneficiary, We write to inform you that Series of meetings have been held over the past 2 weeks with the Secretary General of United Nations,U.S Department of State and Africa Union Organization this ended last week. During the meeting, this organization discovered that you have not received your funds due to past corrupt Government Officials who almost held the funds to themselves for their selfish reason and some individuals who have taken advantage of your fund all in an attempt to defraud you, which has led to unnecessary delay in releasing the funds to you. The United Nations/ U.S. Department of State and Africa Union Organization have successfully passed a payment mandate to our bank, to clear all over due Contract funds, Lottery winnings and Inheritance funds owed to you and other individuals/organizations who have been found not to have receive their long overdue payment. A woman by name (MRS: CINDY MAY A CITIZEN OF USA) came to our office with an application stating that you gave her the power of attorney to be the beneficiary of your Outstanding funds. She made us to believe that you are dead and that she is your next of kin. We decided to send you email through this address hoping to find out if you are dead or alive and also to find out if you at any time gave this woman the power of attorney to represent you. We are almost ready to release part payment of $21.5M USD of your outstanding funds to her but we decided to contact you before we can take any action because of the sensitivity of the transaction and the amount of money that is involved: For immediate release of your funds to you legally as the legal recipient if you did not authorize Cindy May, you are required to send YOUR FULL NAME, CURRENT ADDRESS, CELL PHONE AND FAX NUMBER for onward proceeding on how you are going to receive the said funds legally .You have 48hrs from now to do that. Yours Sincerely, Mr. James Emmett HSBC Chief Executive Officer . ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
On 6/15/20 11:30 PM, Eric Biggers wrote:
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for the buffer clearing. However,
it is entirely possible that the compiler may choose to optimize away the
memory clearing especially if LTO is being used. To make sure that this
optimization will not happen, memzero_explicit(), which is introduced
in v3.18, is now used in kzfree() to do the clearing.
Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc: sta...@vger.kernel.org
Signed-off-by: Waiman Long
---
mm/slab_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9e72ba224175..37d48a56431d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
if (unlikely(ZERO_OR_NULL_PTR(mem)))
return;
ks = ksize(mem);
- memset(mem, 0, ks);
+ memzero_explicit(mem, ks);
kfree(mem);
}
EXPORT_SYMBOL(kzfree);
This is a good change, but the commit message isn't really accurate. AFAIK, no
one has found any case where this memset() gets optimized out. And even with
LTO, it would be virtually impossible due to all the synchronization and global
data structures that kfree() uses. (Remember that this isn't the C standard
function "free()", so the compiler can't assign it any special meaning.)
Not to mention that LTO support isn't actually upstream yet.
I still agree with the change, but it might be helpful if the commit message
were honest that this is really a hardening measure and about properly conveying
the intent. As-is this sounds like a critical fix, which might confuse people.
Yes, I agree that the commit log may look a bit scary. How about the
following:
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for buffer clearing. However
unlikely, there is still a non-zero probability that the compiler may
choose to optimize away the memory clearing especially if LTO is being
used in the future. To make sure that this optimization will never
happen, memzero_explicit(), which is introduced in v3.18, is now used
in kzfree() to future-proof it.
Cheers,
Longman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: gasket: core: Fix a coding style issue in gasket_core.c
On Sun, 2020-06-14 at 21:51 +0800, Zhixu Zhao wrote:
> Fix a coding alignment issue found by checkpatch.pl.
Another option would be to use a temporary for
gasket_dev->bar_data[bar_num]
Something like:
---
drivers/staging/gasket/gasket_core.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging/gasket/gasket_core.c
index 67325fbaf760..73b138f984cf 100644
--- a/drivers/staging/gasket/gasket_core.c
+++ b/drivers/staging/gasket/gasket_core.c
@@ -262,6 +262,7 @@ static int gasket_map_pci_bar(struct gasket_dev
*gasket_dev, int bar_num)
internal_desc->driver_desc;
ulong desc_bytes = driver_desc->bar_descriptions[bar_num].size;
int ret;
+ struct gasket_bar_data *data;
if (desc_bytes == 0)
return 0;
@@ -270,31 +271,32 @@ static int gasket_map_pci_bar(struct gasket_dev
*gasket_dev, int bar_num)
/* not PCI: skip this entry */
return 0;
}
+
+ data = _dev->bar_data[bar_num];
+
/*
* pci_resource_start and pci_resource_len return a "resource_size_t",
* which is safely castable to ulong (which itself is the arg to
* request_mem_region).
*/
- gasket_dev->bar_data[bar_num].phys_base =
+ data->phys_base =
(ulong)pci_resource_start(gasket_dev->pci_dev, bar_num);
- if (!gasket_dev->bar_data[bar_num].phys_base) {
+ if (!data->phys_base) {
dev_err(gasket_dev->dev, "Cannot get BAR%u base address\n",
bar_num);
return -EINVAL;
}
- gasket_dev->bar_data[bar_num].length_bytes =
+ data->length_bytes =
(ulong)pci_resource_len(gasket_dev->pci_dev, bar_num);
- if (gasket_dev->bar_data[bar_num].length_bytes < desc_bytes) {
+ if (data->length_bytes < desc_bytes) {
dev_err(gasket_dev->dev,
"PCI BAR %u space is too small: %lu; expected >= %lu\n",
- bar_num, gasket_dev->bar_data[bar_num].length_bytes,
- desc_bytes);
+ bar_num, data->length_bytes, desc_bytes);
return -ENOMEM;
}
- if (!request_mem_region(gasket_dev->bar_data[bar_num].phys_base,
- gasket_dev->bar_data[bar_num].length_bytes,
+ if (!request_mem_region(data->phys_base, data->length_bytes,
gasket_dev->dev_info.name)) {
dev_err(gasket_dev->dev,
"Cannot get BAR %d memory region %p\n",
@@ -302,10 +304,8 @@ static int gasket_map_pci_bar(struct gasket_dev
*gasket_dev, int bar_num)
return -EINVAL;
}
- gasket_dev->bar_data[bar_num].virt_base =
- ioremap(gasket_dev->bar_data[bar_num].phys_base,
- gasket_dev->bar_data[bar_num].length_bytes);
- if (!gasket_dev->bar_data[bar_num].virt_base) {
+ data->virt_base = ioremap(data->phys_base, data->length_bytes);
+ if (!data->virt_base) {
dev_err(gasket_dev->dev,
"Cannot remap BAR %d memory region %p\n",
bar_num, _dev->pci_dev->resource[bar_num]);
@@ -319,9 +319,8 @@ static int gasket_map_pci_bar(struct gasket_dev
*gasket_dev, int bar_num)
return 0;
fail:
- iounmap(gasket_dev->bar_data[bar_num].virt_base);
- release_mem_region(gasket_dev->bar_data[bar_num].phys_base,
- gasket_dev->bar_data[bar_num].length_bytes);
+ iounmap(data->virt_base);
+ release_mem_region(data->phys_base, data->length_bytes);
return ret;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: rts5208: Use array_size() helper in vmalloc()
On Mon, Jun 15, 2020 at 06:08:11PM -0500, Gustavo A. R. Silva wrote: > and memset() Please don't start the commit message in the middle of a sentence. It's a completely different thing from the title. When you're reading the full email then the title is hidden in the headers and the Date: and Message-ID: field go in between the title and the message body. https://lore.kernel.org/lkml/20200615230811.GA18818@embeddedor/ I normally read either the title or the body but seldom read both when I'm reviewing patches. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: atomisp: Fix a pointer math problem in dump_sp_dmem()
On Tue, Jun 16, 2020 at 12:27:28PM +0300, Dan Carpenter wrote:
> The "io_virt_addr" variable is a u32 pointer and it should be
> incremented by one instead of four. The current code will dump bogus
> data and read beyond the end of the buffer.
>
> Fixes: 69a03e36c711 ("media: atomisp: get rid of an iomem abstraction layer")
> Signed-off-by: Dan Carpenter
Acked-by: Sakari Ailus
--
Sakari Ailus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: atomisp: Fix a pointer math problem in dump_sp_dmem()
The "io_virt_addr" variable is a u32 pointer and it should be
incremented by one instead of four. The current code will dump bogus
data and read beyond the end of the buffer.
Fixes: 69a03e36c711 ("media: atomisp: get rid of an iomem abstraction layer")
Signed-off-by: Dan Carpenter
---
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 7b936e5a5f03..6faf223c6d20 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -682,7 +682,7 @@ void dump_sp_dmem(struct atomisp_device *isp, unsigned int
addr,
do {
data = *io_virt_addr;
dev_dbg(isp->dev, "%s, \t [0x%x]:0x%x\n", __func__, addr, data);
- io_virt_addr += sizeof(u32);
+ io_virt_addr++;
size32 -= 1;
} while (size32 > 0);
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
On Tue, Jun 16, 2020 at 08:42:08AM +0200, Michal Hocko wrote:
> On Mon 15-06-20 21:57:16, Waiman Long wrote:
> > The kzfree() function is normally used to clear some sensitive
> > information, like encryption keys, in the buffer before freeing it back
> > to the pool. Memset() is currently used for the buffer clearing. However,
> > it is entirely possible that the compiler may choose to optimize away the
> > memory clearing especially if LTO is being used. To make sure that this
> > optimization will not happen, memzero_explicit(), which is introduced
> > in v3.18, is now used in kzfree() to do the clearing.
> >
> > Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Waiman Long
>
> Acked-by: Michal Hocko
>
> Although I am not really sure this is a stable material. Is there any
> known instance where the memset was optimized out from kzfree?
I told him to add the stable. Otherwise it will just get reported to
me again. It's a just safer to backport it before we forget.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello friend 16/06/2020
Good day, My name is Reem E. Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee. I am writing you to manage my funds I received as financial gratification from various foreign companies I assisted to receive participation slot in the incoming Dubai World Expo 2020. The amount is $44,762,906.00 United States dollars.The cumulative deposit were given as an expression of appreciation from the various foreign companies whose applications received approval to participate in the in-coming Dubai Expo 2020. But I could not receive the various gratifications to my personal account in my country because my social status as a married Muslim lady with limitations to certain investment opportunities. For this reason, an agreement was reached with a consulting firm to keep the funds in open beneficiary account with a financial institution where it will be possible to instruct transfer of the funds to a third party account for investment purpose which is the reason I am contacting you to receive and manage the funds as my investment partner. The detail will be discuss on your indication of interest with your information and capacity to manage the fund. However, if you are not ready to take up responsibility in this partnership, please do not reply. While looking forward to good partnership, I am wishing you the best of the year. my Regards Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello friend 16/06/2020
Good day, My name is Reem E. Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee. I am writing you to manage my funds I received as financial gratification from various foreign companies I assisted to receive participation slot in the incoming Dubai World Expo 2020. The amount is $44,762,906.00 United States dollars.The cumulative deposit were given as an expression of appreciation from the various foreign companies whose applications received approval to participate in the in-coming Dubai Expo 2020. But I could not receive the various gratifications to my personal account in my country because my social status as a married Muslim lady with limitations to certain investment opportunities. For this reason, an agreement was reached with a consulting firm to keep the funds in open beneficiary account with a financial institution where it will be possible to instruct transfer of the funds to a third party account for investment purpose which is the reason I am contacting you to receive and manage the funds as my investment partner. The detail will be discuss on your indication of interest with your information and capacity to manage the fund. However, if you are not ready to take up responsibility in this partnership, please do not reply. While looking forward to good partnership, I am wishing you the best of the year. my Regards Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
On Mon 15-06-20 21:57:16, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possible that the compiler may choose to optimize away the
> memory clearing especially if LTO is being used. To make sure that this
> optimization will not happen, memzero_explicit(), which is introduced
> in v3.18, is now used in kzfree() to do the clearing.
>
> Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Waiman Long
Acked-by: Michal Hocko
Although I am not really sure this is a stable material. Is there any
known instance where the memset was optimized out from kzfree?
> ---
> mm/slab_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9e72ba224175..37d48a56431d 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1726,7 +1726,7 @@ void kzfree(const void *p)
> if (unlikely(ZERO_OR_NULL_PTR(mem)))
> return;
> ks = ksize(mem);
> - memset(mem, 0, ks);
> + memzero_explicit(mem, ks);
> kfree(mem);
> }
> EXPORT_SYMBOL(kzfree);
> --
> 2.18.1
>
--
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
