- Original Message -
From: "Darrick J. Wong"
To: "Waiman Long"
Cc: linux-...@vger.kernel.org, linux-kernel@vger.kernel.org, "Dave Chinner"
, "Qian Cai" , "Eric Sandeen"
Sent: Monday, July 13, 2020 12:41:12 PM
Subject: Re:
This patch changes:
1) Fix typo in kernel connector documentation.
s/cn_netlink_send_multi/cn_netlink_send_mult/
2) update definition of struct cn_msg
Signed-off-by: Wang Long
---
Documentation/driver-api/connector.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
In the current xarray code, the negative value -1 and -4095 represented
as an error.
xa_is_err(xa_mk_internal(-4095)) and xa_is_err(xa_mk_internal(-1))
are all return true.
This patch update the document.
Signed-off-by: Wang Long
---
include/linux/xarray.h | 2 +-
1 file changed, 1 insertion
In the current xarray code, the negative value -1 and -4095 represented
as an error.
xa_is_error(xa_mk_internal(-4095)) and xa_is_error(xa_mk_internal(-1))
are all return true.
This patch update the document.
Signed-off-by: Wang Long
---
include/linux/xarray.h | 2 +-
1 file changed, 1
In the current xarray code, the negative value -1 and -4095 represented
as an error.
xa_is_error(xa_mk_internal(-4095)) and xa_is_error(xa_mk_internal(-1))
are all return true.
This patch update the document.
Signed-off-by: Wang Long
---
include/linux/xarray.h | 2 +-
1 file changed, 1
ux/commits/Waiman-Long/x86-locking-qspinlock-Allow-lock-to-store-lock-holder-cpu-number/20200717-033319
base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git
f9ad4a5f3f20bee022b1bdde94e5ece6dc0b0edc
in testcase: trinity
with following parameters:
runtime: 300s
test-descriptio
Make the qrwlock code to store an encoded cpu number (+1 saturated)
for the writer that hold the write lock if desired.
Signed-off-by: Waiman Long
---
include/asm-generic/qrwlock.h | 12 +++-
kernel/locking/qrwlock.c | 11 ++-
2 files changed, 17 insertions(+), 6 deletions
Make the qspinlock code to store an encoded cpu number (+2 saturated)
into the locked byte. The lock value of 1 is used by PV qspinlock to
signal that the PV unlock slowpath has to be called.
Signed-off-by: Waiman Long
---
arch/x86/include/asm/qspinlock_paravirt.h | 42
. There is no functional change.
Signed-off-by: Waiman Long
---
kernel/locking/qspinlock.c | 12
kernel/locking/qspinlock_paravirt.h | 6 ++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index
numbers are very likely to be located
in the same hot cacheline as cpu_number. As these numbers are before
the unsigned long this_cpu_off, no additional percpu space will be
consumed in x86-64.
Signed-off-by: Waiman Long
---
arch/x86/include/asm/spinlock.h | 5 +
arch/x86/kernel
,
that performance difference should be negligible for most real workloads.
Waiman Long (5):
x86/smp: Add saturated +1/+2 1-byte cpu numbers
locking/pvqspinlock: Make pvqsinlock code easier to read
locking/qspinlock: Pass lock value as function argument
locking/qspinlock: Make qspinhlock
Update the various internal qspinlock functions to pass in the lock
value to be used as a function argument instead of hardcoding it to
_Q_LOCKED_VAL. There is no functional change.
Signed-off-by: Waiman Long
---
kernel/locking/qspinlock.c | 19 ++-
kernel/locking
On 7/14/20 5:01 AM, Peter Zijlstra wrote:
On Mon, Jul 13, 2020 at 10:48:00PM -0400, Waiman Long wrote:
Storing the cpu number into the lock can be useful for other reason too. It
is not totally related to PPC support.
Well, the thing you did only works for 'small' (<253 CPU) systems.
Ther
Hi, Steffen,
I've confirmed the patchset I posted yesterday would fix this:
[PATCH ipsec-next 0/3] xfrm: not register one xfrm(6)_tunnel object twice
Thanks.
On Tue, Jul 14, 2020 at 5:37 PM Steffen Klassert
wrote:
>
> Xin,
>
> this looks a bit like it was introduced with one of your recent
>
On Tue, Jul 14, 2020 at 5:37 PM Steffen Klassert
wrote:
>
> Xin,
>
> this looks a bit like it was introduced with one of your recent
> patches. Can you please look into that?
Yes, I'm looking into it.
Thanks.
>
> Thanks!
>
> On Mon, Jul 13, 2020 at 03:04:16PM -0700, syzbot wrote:
> > Hello,
> >
On 7/13/20 12:17 AM, Nicholas Piggin wrote:
Excerpts from Waiman Long's message of July 13, 2020 9:05 am:
On 7/12/20 1:34 PM, Peter Zijlstra wrote:
On Sat, Jul 11, 2020 at 02:21:28PM -0400, Waiman Long wrote:
The previous patch enables native qspinlock to store lock holder cpu
number
On 7/12/20 1:34 PM, Peter Zijlstra wrote:
On Sat, Jul 11, 2020 at 02:21:28PM -0400, Waiman Long wrote:
The previous patch enables native qspinlock to store lock holder cpu
number into the lock word when the lock is acquired via the slowpath.
Since PV qspinlock uses atomic unlock, allowing
qspinlocks
in the slowpath will put the lock holder cpu information in the lock
word.
Signed-off-by: Waiman Long
---
arch/Kconfig | 12 +++
arch/x86/include/asm/qspinlock_paravirt.h | 9 +++--
include/asm-generic/qspinlock.h | 13 +--
kernel/locking
the locked byte is set or not
(1 or 0). There is another special value for PV qspinlock (3). The whole
byte is used because of performance reason. So there is space to store
additional information such as the lock holder cpu as long as the cpu
number is small enough to fit into a little less than
.
Waiman Long (2):
locking/qspinlock: Store lock holder cpu in lock if feasible
locking/pvqspinlock: Optionally store lock holder cpu into lock
arch/Kconfig | 12 ++
arch/x86/include/asm/qspinlock_paravirt.h | 9 ++--
include/asm-generic/qspinlock.h
++
arch/powerpc/platforms/pseries/Kconfig| 5 ++
arch/powerpc/platforms/pseries/setup.c| 6 +-
include/asm-generic/qspinlock.h | 2 +
Another ack?
I am OK with adding the #ifdef around queued_spin_lock().
Acked-by: Waiman Long
diff --git a/arch/powerpc
On 7/8/20 7:50 PM, Waiman Long wrote:
On 7/8/20 1:10 AM, Nicholas Piggin wrote:
Excerpts from Waiman Long's message of July 8, 2020 1:33 pm:
On 7/7/20 1:57 AM, Nicholas Piggin wrote:
Yes, powerpc could certainly get more performance out of the slow
paths, and then there are a few parameters
On 7/8/20 4:41 AM, Peter Zijlstra wrote:
On Tue, Jul 07, 2020 at 03:57:06PM +1000, Nicholas Piggin wrote:
Yes, powerpc could certainly get more performance out of the slow
paths, and then there are a few parameters to tune.
Can you clarify? The slow path is already in use on ARM64 which is
On 7/8/20 4:32 AM, Peter Zijlstra wrote:
On Tue, Jul 07, 2020 at 11:33:45PM -0400, Waiman Long wrote:
From 5d7941a498935fb225b2c7a3108cbf590114c3db Mon Sep 17 00:00:00 2001
From: Waiman Long
Date: Tue, 7 Jul 2020 22:29:16 -0400
Subject: [PATCH 2/9] locking/pvqspinlock: Introduce
On 7/8/20 1:10 AM, Nicholas Piggin wrote:
Excerpts from Waiman Long's message of July 8, 2020 1:33 pm:
On 7/7/20 1:57 AM, Nicholas Piggin wrote:
Yes, powerpc could certainly get more performance out of the slow
paths, and then there are a few parameters to tune.
We don't have a good alternate
rom 161e545523a7eb4c42c145c04e9a5a15903ba3d9 Mon Sep 17 00:00:00 2001
From: Waiman Long
Date: Tue, 7 Jul 2020 20:46:51 -0400
Subject: [PATCH 1/9] locking/pvqspinlock: Code relocation and extraction
Move pv_kick_node() and the unlock functions up and extract out the hash
and lock code from pv_wait_head_or_lock() into pv_hash_l
. Because of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_super.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 379cbff438bc..0797a96b83d6 100644
On 7/6/20 12:35 AM, Nicholas Piggin wrote:
v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you).
Thanks,
Nick
Nicholas Piggin (6):
powerpc/powernv: must include hvcall.h to get PAPR defines
powerpc/pseries: move some PAPR paravirt functions to their own file
On 7/3/20 3:35 AM, Nicholas Piggin wrote:
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/paravirt.h | 28 ++
arch/powerpc/include/asm/qspinlock.h | 55 +++
arch/powerpc/include/asm/qspinlock_paravirt.h | 5 ++
On 7/5/20 2:22 PM, Abhishek Bhardwaj wrote:
On Sun, Jul 5, 2020 at 8:57 AM Waiman Long wrote:
On 7/5/20 11:23 AM, Mike Rapoport wrote:
Nothing prevents people from continuing to use the command line
options if they want, right? This just allows a different default.
So if a distro is security
On 7/5/20 11:23 AM, Mike Rapoport wrote:
Nothing prevents people from continuing to use the command line
options if they want, right? This just allows a different default.
So if a distro is security focused and decided that it wanted a slower
/ more secure default then it could ship that way
On 7/2/20 9:07 PM, Dave Chinner wrote:
On Wed, Jul 01, 2020 at 08:59:23PM -0400, Waiman Long wrote:
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_super.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs
On 7/2/20 12:15 PM, kernel test robot wrote:
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on tip/locking/core v5.8-rc3 next-20200702]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 7/2/20 6:12 PM, Abhishek Bhardwaj wrote:
This change adds a new kernel configuration that sets the l1d cache
flush setting at compile time rather than at run time.
Signed-off-by: Abhishek Bhardwaj
Can you explain in the commit log why you need a compile time option
whereas the desired
On 7/2/20 3:48 AM, Nicholas Piggin wrote:
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/paravirt.h | 23
arch/powerpc/include/asm/qspinlock.h | 55 +++
arch/powerpc/include/asm/qspinlock_paravirt.h | 5 ++
rder to make the code clear, the warning
message is put in one place.
Signed-off-by: Long Li
---
changes in V4:
-Change the check function name to kmalloc_check_flags()
-Put the flags check into the kmalloc_check_flags()
changes in V3:
-Put the warning message in one place
-updage the change
ternal -> fs_reclaim lock dependency
chain can no longer be found. Because of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_super.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_
rder to make the code clear, the warning
message is put in one place.
Signed-off-by: Long Li
---
changes in V3:
-Put the warning message in one place
-updage the change log to be clear
mm/slab.c| 10 +++---
mm/slab.h| 1 +
mm/slab_common.c | 17 +
mm/sl
to a virtual address, kmalloc_order() will return
NULL and the page has been allocated.
After modification, GFP_SLAB_BUG_MASK has been checked before
allocating pages, refer to the new_slab().
Signed-off-by: Long Li
---
Changes in v2:
- patch is rebased againest "[PATCH] mm: Free unused
NULL, the pages has not
been released. Usually driver developers will not use the
GFP_HIGHUSER flag to allocate memory in kmalloc, but I think this
memory leak is not perfect, it is best to be fixed. This is the
first time I have posted a patch, there may be something wrong.
Signed-off-by: Long Li
22 June 2020 19:33
> >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Jun 22,
On Wed, Jun 24, 2020 at 12:00 AM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
> > >
> > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > > &g
On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> > wrote:
> > >
> > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> > >
t;>>
> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>>>
> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> >&g
On 6/18/20 7:04 PM, Dave Chinner wrote:
On Fri, Jun 19, 2020 at 08:58:10AM +1000, Dave Chinner wrote:
On Thu, Jun 18, 2020 at 01:19:41PM -0400, Waiman Long wrote:
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 379cbff438bc..1b94b9bfa4d7 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop after
> 2.5 seconds
On 6/20/20 5:00 PM, Andrew Morton wrote:
On Sat, 20 Jun 2020 14:47:19 -0400 Waiman Long wrote:
It was found that running the LTP test on a PowerPC system could produce
erroneous values in /proc/meminfo, like:
MemTotal: 531915072 kB
MemFree:507962176 kB
MemAvailable
On 6/20/20 3:59 PM, Roman Gushchin wrote:
On Sat, Jun 20, 2020 at 02:47:19PM -0400, Waiman Long wrote:
It was found that running the LTP test on a PowerPC system could produce
erroneous values in /proc/meminfo, like:
MemTotal: 531915072 kB
MemFree:507962176 kB
od_zone_page_state() which accepts a long argument. Depending on
the compiler and how inlining is done, "-nr_pages" may be treated as
a negative number or a very large positive number. Apparently, it was
treated as a large positive number in that PowerPC system leading to
incorrect stat c
On 6/19/20 9:21 AM, Christoph Hellwig wrote:
I find it really confusing that we record this in current->flags.
per-thread state makes total sense for not dipping into fs reclaim.
But for annotating something related to memory allocation passing flags
seems a lot more descriptive to me, as it is
tes. With this
patch applied, the object size is reduced to 202 bytes. This is a saving
of 107 bytes and will probably be slightly faster too.
Signed-off-by: Waiman Long
---
include/linux/sched/mm.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched/mm.
On 6/18/20 12:07 PM, Peter Zijlstra wrote:
On Thu, Jun 18, 2020 at 11:58:47AM -0400, Waiman Long wrote:
The current_gfp_context() converts a number of PF_MEMALLOC_* per-process
flags into the corresponding GFP_* flags for memory allocation. In
that function, current->flags is accessed 3 ti
ternal -> fs_reclaim lock dependency
chain can no longer be found. Because of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_super.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git
tes. With this
patch applied, the object size is reduced to 202 bytes. This is a saving
of 107 bytes and will probably be slightly faster too.
Signed-off-by: Waiman Long
---
include/linux/sched/mm.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched/mm.
On 6/18/20 11:20 AM, Darrick J. Wong wrote:
On Thu, Jun 18, 2020 at 11:05:57AM -0400, Waiman Long wrote:
Depending on the workloads, the following circular locking dependency
warning between sb_internal (a percpu rwsem) and fs_reclaim (a pseudo
lock) may show up
ternal -> fs_reclaim lock dependency
chain can no longer be found. Because of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_super.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff -
On 6/17/20 8:45 PM, Dave Chinner wrote:
On Wed, Jun 17, 2020 at 01:53:10PM -0400, Waiman Long wrote:
fs/xfs/xfs_log.c | 9 +
fs/xfs/xfs_trans.c | 31 +++
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs
On 6/17/20 8:01 PM, Dave Chinner wrote:
On Wed, Jun 17, 2020 at 01:53:09PM -0400, Waiman Long wrote:
There are cases where calling kmalloc() can lead to false positive
lockdep splat. One notable example that can happen in the freezing of
the xfs filesystem is as follows:
Possible unsafe
, there are
still 2 free bits left.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
include/linux/sched.h| 7 +++
include/linux/sched/mm.h | 15 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b62e6aaf28f0
the lockdep splat.
Waiman Long (2):
sched: Add PF_MEMALLOC_NOLOCKDEP flag
xfs: Fix false positive lockdep warning with sb_internal & fs_reclaim
fs/xfs/xfs_log.c | 9 +
fs/xfs/xfs_trans.c | 31 +++
include/linux/sched.h
hain can no longer be found. Because of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_log.c | 9 +
fs/xfs/xfs_trans.c | 31 +++
2 files changed, 36 insertions(+), 4 deletions(-)
diff
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()&q
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()&q
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 pa
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
.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
ked-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
.
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 168deb8ef68a..e8f7c5f00894 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2692,7 +2692,7 @@ static int
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
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
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
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
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: Ren
.
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
ked-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
On 6/15/20 8:13 PM, Boqun Feng wrote:
Hi Matthew,
On Mon, Jun 15, 2020 at 01:40:46PM -0700, Matthew Wilcox wrote:
On Mon, Jun 15, 2020 at 01:13:51PM -0400, Waiman Long wrote:
On 6/15/20 12:49 PM, Matthew Wilcox wrote:
On Fri, Jun 12, 2020 at 03:01:01PM +0800, Boqun Feng wrote:
On the archs
On 6/15/20 12:43 PM, Darrick J. Wong wrote:
On Mon, Jun 15, 2020 at 12:08:30PM -0400, Waiman Long wrote:
Depending on the workloads, the following circular locking dependency
warning between sb_internal (a percpu rwsem) and fs_reclaim (a pseudo
lock) may show up
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 6/15/20 12:49 PM, Matthew Wilcox wrote:
On Fri, Jun 12, 2020 at 03:01:01PM +0800, Boqun Feng wrote:
On the archs using QUEUED_RWLOCKS, read_lock() is not always a recursive
read lock, actually it's only recursive if in_interrupt() is true. So
change the annotation accordingly to catch more
On 6/12/20 3:01 AM, Boqun Feng wrote:
On Fri, Jun 12, 2020 at 07:55:26AM +0800, Boqun Feng wrote:
Hi Peter and Waiman,
On Thu, Jun 11, 2020 at 12:09:59PM -0400, Waiman Long wrote:
On 6/11/20 10:22 AM, Peter Zijlstra wrote:
On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote
, there are
still 2 free bits left.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
include/linux/sched.h| 7 +++
include/linux/sched/mm.h | 15 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b62e6aaf28f0
ecause of that, the locking dependency
warning will not be shown.
Suggested-by: Dave Chinner
Signed-off-by: Waiman Long
---
fs/xfs/xfs_log.c | 9 +
fs/xfs/xfs_trans.c | 30 ++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_log
);
lock(sb_internal);
lock(fs_reclaim);
*** DEADLOCK ***
This patch series works around this problem by adding a
PF_MEMALLOC_NOLOCKDEP flag and set during filesystem freeze to avoid
the lockdep splat.
Waiman Long (2):
sched: Add PF_MEMALLOC_NOLOCKDEP flag
xfs: Fix false positive lockdep
On 6/11/20 7:55 PM, Boqun Feng wrote:
Hi Peter and Waiman,
On Thu, Jun 11, 2020 at 12:09:59PM -0400, Waiman Long wrote:
On 6/11/20 10:22 AM, Peter Zijlstra wrote:
On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote:
There was an old lockdep patch that I think may address the issue
On 6/11/20 10:22 AM, Peter Zijlstra wrote:
On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote:
There was an old lockdep patch that I think may address the issue, but was
not merged at the time. I will need to dig it out and see if it can be
adapted to work in the current kernel
On 6/11/20 3:43 AM, Dmitry Vyukov wrote:
On Thu, Jun 11, 2020 at 4:33 AM Waiman Long wrote:
On 4/4/20 1:55 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
git tree: upstream
console output
On 4/4/20 1:55 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f39c5de0
kernel config:
On 6/9/20 11:07 AM, Miklos Szeredi wrote:
While running xfstests[1] on overlayfs I get the following:
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
turning off the locking correctness validator.
[...]
Then when doing cat /proc/lockdep_chains I get this Oops:
BUG: unable to handle page fault for
On 6/4/20 7:13 PM, Dave Chinner wrote:
On Thu, Jun 04, 2020 at 05:01:30PM -0400, Waiman Long wrote:
---
fs/xfs/xfs_log.c | 3 ++-
fs/xfs/xfs_trans.c | 8 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index 00fda2e8e738
plying the patch, such sb_internal -> fs_reclaim lock dependency
chain can no longer be found. Because of that, the locking dependency
warning will not be shown.
Signed-off-by: Waiman Long
---
fs/xfs/xfs_log.c | 3 ++-
fs/xfs/xfs_trans.c | 8 +++-
2 files changed, 9 insertions(+), 2 deletions(
On 6/4/20 3:29 AM, Tada, Kenta (Sony) wrote:
It conflicts with your new code. We can have an argument on whether IB should
follow how SSB is being handled. Before that is settled,
Thank you for the information.
It conflicts but I think users who read the below document get confused.
a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ed54b3b21c39..678ace157035 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1173,6 +1173,9 @@ static int ib_prctl_set(struct task_struct *task,
unsigned long ctrl)
if (spectre_v2_user
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 2ca41f555e857ec5beef6063bfa43a17ee76d7ec
Gitweb:
https://git.kernel.org/tip/2ca41f555e857ec5beef6063bfa43a17ee76d7ec
Author:Waiman Long
AuthorDate:Tue, 26 May 2020 08:20:14 -04:00
ddress that is
> part of an existing association has experienced a change of
> state (e.g., a failure or return to service of the reachability
> of an endpoint via a specific transport address).
>
> Signed-off-by: Jonas Falkevik
Reviewed-by: Xin Long
> ---
> Changes in v2:
>
On 5/26/20 5:27 PM, Peter Zijlstra wrote:
On Tue, May 26, 2020 at 04:30:58PM -0400, Waiman Long wrote:
On 5/26/20 3:56 PM, Peter Zijlstra wrote:
On Tue, May 26, 2020 at 02:58:50PM -0400, Qian Cai wrote:
I still don't understand why reading all sysfs files on this system
could increase
,
https://cailca.github.io/files/lockdep.txt
f011a2a5 OPS: 20 FD: 45 BD:1 .+.+: kn->active#834
is that somewhere near the number of CPUs you have?
Anyway, there's very long "kn->active#..." chains in there, which seems
to suggest some annotation is all s
in memory consumption of
917504 bytes. With that change, the percentage usage of list_entries[]
will fall to 31.8% and 34.9% respectively to make them more in line
with the other tables.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep_internals.h | 4 ++--
1 file changed, 2 insertions(+), 2
onger used. Remove those as well to avoid confusion.
Signed-off-by: Waiman Long
---
arch/x86/include/asm/spinlock_types.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/arch/x86/include/asm/spinlock_types.h
b/arch/x86/include/asm/spinlock_types.h
index bf3e34b25afc..32
On Mon, May 25, 2020 at 9:10 PM Marcelo Ricardo Leitner
wrote:
>
> On Mon, May 25, 2020 at 04:42:16PM +0800, Xin Long wrote:
> > On Sat, May 23, 2020 at 8:04 PM Jonas Falkevik
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:42 PM Marcelo Ricardo Leitner
On Sat, May 23, 2020 at 8:04 PM Jonas Falkevik wrote:
>
> On Tue, May 19, 2020 at 10:42 PM Marcelo Ricardo Leitner
> wrote:
> >
> > On Fri, May 15, 2020 at 10:30:29AM +0200, Jonas Falkevik wrote:
> > > On Wed, May 13, 2020 at 11:32 PM Marcelo Ricardo Leitner
> > > wrote:
> > > >
> > > > On Wed,
301 - 400 of 9157 matches
Mail list logo
