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..3f70e5
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/
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/
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-
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
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 |
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: Con
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:
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_
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
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 me
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
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/sta
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
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_
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
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 discus
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
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 "kz
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/i
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-ze
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 r
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 t
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
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 ar
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_inf
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 fr
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
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.
-
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
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 clea
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
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
Me
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
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/s
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
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 participati
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 participati
38 matches
Mail list logo
