On 2/1/21 1:09 PM, Dmitry Vyukov wrote:
On Mon, Feb 1, 2021 at 6:54 PM Waiman Long wrote:
On 2/1/21 6:23 AM, Peter Zijlstra wrote:
On Mon, Feb 01, 2021 at 10:50:58AM +0100, Peter Zijlstra wrote:
queued_spin_unlock arch/x86/include/asm/qspinlock.h:56 [inline]
lockdep_unlock+0x10e/0x290
}
I have also suspected doing unlock without a corresponding lock. This
patch looks good to me.
Acked-by: Waiman Long
Cheers,
Longman
On 12/7/20 8:24 AM, Kuniyuki Iwashima wrote:
This reverts commit 607904c357c61adf20b8fd18af765e501d61a385 to use
spin_lock_bh_nested() in the next commit.
Link:
https://lore.kernel.org/netdev/9d290a57-49e1-04cd-2487-262b0d7c5...@gmail.com/
Signed-off-by: Kuniyuki Iwashima
CC: Waiman Long
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()"
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()"
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 importa
izer 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
ked-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 +-
cry
.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 kz
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 i
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
ked-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 +-
cry
() 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
ring 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 (3):
mm/slab: Use memzero_explicit() in kzfree()
mm, treewide
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 Lon
On 6/15/20 2:07 PM, Dan Carpenter wrote:
On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote:
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 23c7500eea7d..c08bc7eb20bd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1707,17 +1707,17 @@ void *krealloc(const void *p
On 01/30/2019 09:01 PM, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 04:32:12PM -0500, Waiman Long wrote:
>> On 01/30/2019 04:11 PM, Waiman Long wrote:
>>> On 01/30/2019 03:10 PM, Alexei Starovoitov wrote:
>>>> On Wed, Jan 30, 2019 at 02:42:23PM -0500, Waiman L
On 01/30/2019 04:11 PM, Waiman Long wrote:
> On 01/30/2019 03:10 PM, Alexei Starovoitov wrote:
>> On Wed, Jan 30, 2019 at 02:42:23PM -0500, Waiman Long wrote:
>>> On 01/30/2019 02:30 PM, Alexei Starovoitov wrote:
>>>> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Pete
On 01/30/2019 03:10 PM, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 02:42:23PM -0500, Waiman Long wrote:
>> On 01/30/2019 02:30 PM, Alexei Starovoitov wrote:
>>> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Peter Zijlstra wrote:
>>>> On Tue, Jan 29, 20
On 01/30/2019 02:44 PM, Peter Zijlstra wrote:
> On Wed, Jan 30, 2019 at 11:30:41AM -0800, Alexei Starovoitov wrote:
>> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Peter Zijlstra wrote:
>>> On Tue, Jan 29, 2019 at 08:04:56PM -0800, Alexei Starovoitov wrote:
Lockdep warns about false positive:
>>>
On 01/30/2019 02:30 PM, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 29, 2019 at 08:04:56PM -0800, Alexei Starovoitov wrote:
>>> Lockdep warns about false positive:
>> This is not a false positive, and you probably also need to use
>> do
On 07/03/2017 04:23 AM, Jiri Benc wrote:
> On Sun, 2 Jul 2017 16:06:10 -0400, Waiman Long wrote:
>> I didn't see any init code for hlist4 and hlist6. Is vxlan_dev going to
>> be *zalloc'ed so that they are guaranteed to be NULL? If not, you may
>> need to add init
On 07/02/2017 01:00 PM, Jiri Benc wrote:
> It's not a good idea to add the same hlist_node to two different hash lists.
> This leads to various hard to debug memory corruptions.
>
> Fixes: b1be00a6c39f ("vxlan: support both IPv4 and IPv6 sockets in a single
> vxlan device")
> Signed-off-by: Jiri B
24 matches
Mail list logo
