On Sat, Dec 30, 2023 at 03:49:52PM +, David Laight wrote:
[...]
> I don't completely understand the 'acquire'/'release' semantics (they didn't
> exist when I started doing SMP kernel code in the late 1980s).
> But it looks odd that osq_unlock()'s fast path uses _release but the very
> similar
On Sat, Sep 09, 2023 at 04:31:25AM +, Joel Fernandes wrote:
> On Fri, Sep 08, 2023 at 10:35:57PM +0200, Frederic Weisbecker wrote:
> > A full barrier is issued from nocb_gp_wait() upon callbacks advancing
> > to order grace period completion with callbacks execution.
> >
> > However these two
we can use Rust-for-Linux or
linux-toolchains list to discuss.
[...]
> > - Boqun Feng is working hard on the different options for
> > threading abstractions and has reviewed most of the `sync` PRs.
>
> Boqun, I know you're familiar with LKMM, can you please talk about how
> Ru
On Wed, Mar 31, 2021 at 11:22:35PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> > >
> > > CPU0 CPU1
> > > =
Hi,
On Wed, Mar 31, 2021 at 02:30:32PM +, guo...@kernel.org wrote:
> From: Guo Ren
>
> Some architectures don't have sub-word swap atomic instruction,
> they only have the full word's one.
>
> The sub-word swap only improve the performance when:
> NR_CPUS < 16K
> * 0- 7: locked byte
> *
On Mon, Apr 05, 2021 at 04:38:07PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 06, 2021 at 07:25:44AM +0800, Boqun Feng wrote:
> > On Mon, Apr 05, 2021 at 10:27:52AM -0700, Paul E. McKenney wrote:
> > > On Mon, Apr 05, 2021 at 01:23:30PM +0800, Boqun Feng wrote:
> > > &
On Mon, Apr 05, 2021 at 10:27:52AM -0700, Paul E. McKenney wrote:
> On Mon, Apr 05, 2021 at 01:23:30PM +0800, Boqun Feng wrote:
> > On Sun, Apr 04, 2021 at 09:30:38PM -0700, Paul E. McKenney wrote:
> > > On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote:
> >
On Sun, Apr 04, 2021 at 09:30:38PM -0700, Paul E. McKenney wrote:
> On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote:
> > On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote:
> > > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote:
> > > > On Sun, Apr 04,
Hi Arnd,
On Sat, Mar 20, 2021 at 05:09:10PM +0100, Arnd Bergmann wrote:
> On Sat, Mar 20, 2021 at 1:54 PM Arnd Bergmann wrote:
> > I actually still have a (not really tested) patch series to clean up
> > the pci host bridge registration, and this should make this a lot easier
> > to add on
cts CONFIG_PCI_DOMAINS_GENERIC), we
introduce arch-specific pci sysdata (similar to the one for x86) for
ARM64, and allow the core PCI code to detect the type of sysdata at the
runtime. The latter is achieved by adding a pci_ops::use_arch_sysdata
field.
Originally-by: Sunil Muthuswamy
Signed-off-by: Boqun F
(rather
than pci_config_window) for CONFIG_PCI_DOMAINS_GENERIC=y architectures.
This allows us to reuse the existing code for Hyper-V PCI controller.
This is simply a proposal, I'm open to any suggestion.
Thanks!
Regards,
Boqun
Boqun Feng (2):
arm64: PCI: Allow use arch-specific pci sysdata
PCI
Use the newly introduced ->use_arch_sysdata to tell PCI core, we still
use the arch-specific sysdata way to set up root PCI buses on
CONFIG_PCI_DOMAINS_GENERIC=y architectures, this is preparation fo
Hyper-V ARM64 guest virtual PCI support.
Signed-off-by: Boqun Feng (Microsoft)
---
drivers/
On Wed, Mar 17, 2021 at 10:54:17PM -0400, Waiman Long wrote:
> On 3/17/21 10:24 PM, Boqun Feng wrote:
> > Hi Waiman,
> >
> > Just a question out of curiosity: how does this problem hide so long?
> > ;-) Because IIUC, both locktorture and ww_mutex_lock have been th
Hi Waiman,
Just a question out of curiosity: how does this problem hide so long?
;-) Because IIUC, both locktorture and ww_mutex_lock have been there for
a while, so why didn't we spot this earlier?
I ask just to make sure we don't introduce the problem because of some
subtle problems in
imer. nocb_gp_wait()
> > > is going to check again the bypass state and rearm the bypass timer if
> > > necessary.
> > >
> > > Signed-off-by: Frederic Weisbecker
> > > Cc: Josh Triplett
> > > Cc: Lai Jiangshan
> > > Cc: Joel Fernandes
> &g
On Sat, Mar 06, 2021 at 09:39:54PM +0100, Marc Kleine-Budde wrote:
> Hello *,
>
> On 02.11.2020 11:41:52, Andrea Righi wrote:
> > We have the following potential deadlock condition:
> >
> >
> > WARNING: possible irq lock inversion
On Thu, Mar 04, 2021 at 11:11:42AM -0500, Alan Stern wrote:
> On Thu, Mar 04, 2021 at 02:33:32PM +0800, Boqun Feng wrote:
>
> > Right, I was thinking about something unrelated.. but how about the
> > following case:
> >
> > local_v =
> > r1 = READ_ONC
On Wed, Mar 03, 2021 at 10:13:22PM -0500, Alan Stern wrote:
> On Thu, Mar 04, 2021 at 09:26:31AM +0800, Boqun Feng wrote:
> > On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
>
> > > Which brings us back to the case of the
> > >
> > > dep
On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> > On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
>
> > > Local variables absolutely should be treated just like CPU registers, if
> > > possible. In
On Thu, Feb 18, 2021 at 03:16:29PM -0800, Michael Kelley wrote:
[...]
> +
> +/*
> + * Get the value of a single VP register. One version
> + * returns just 64 bits and another returns the full 128 bits.
> + * The two versions are separate to avoid complicating the
> + * calling sequence for the
On Wed, Jan 27, 2021 at 12:23:45PM -0800, Michael Kelley wrote:
> STIMER0 interrupts are most naturally modeled as per-cpu IRQs. But
> because x86/x64 doesn't have per-cpu IRQs, the core STIMER0 interrupt
> handling machinery is done in code under arch/x86 and Linux IRQs are
> not used. Adding
On Wed, Jan 27, 2021 at 12:23:44PM -0800, Michael Kelley wrote:
> On x86/x64, the TSC clocksource is available in a Hyper-V VM only if
> Hyper-V provides the TSC_INVARIANT flag. The rating on the Hyper-V
> Reference TSC page clocksource is currently set so that it will not
> override the TSC
on than to the architecture.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/include/asm/mshyperv.h| 11 ---
> drivers/clocksource/hyperv_timer.c | 21 +
> 2 files changed
on than to the architecture.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/include/asm/mshyperv.h| 4
> drivers/clocksource/hyperv_timer.c | 10 --
> 2 files changed, 8 insertions(+), 6
inux per-cpu IRQ allocation into the main VMbus
> driver, and bypassing it in the x86/x64 exception case. For x86/x64,
> special case code is retained under arch/x86, but no VMbus interrupt
> handling code is needed under arch/arm64.
>
> No functional change.
>
> Signed-off-by: Mi
nctional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/include/asm/mshyperv.h | 3 ---
> drivers/hv/hv.c | 12 +++-
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/in
; under arch/arm64.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/hyperv/hv_init.c | 27 ---
> drivers/hv/vmbus_drv.c | 24 +++-
> includ
ode) have been cleaned up in a separate patch series.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/hyperv/hv_init.c | 2 +-
> arch/x86/include/asm/hyperv-tlfs.h | 102
>
rch specific module. But C doesn't provide
> a way to extend enum types. As a compromise, move the entire
> definition into an arch neutral module, to avoid duplicating the
> arch neutral values for x86/x64 and for ARM64.
>
> No functional change.
>
> Signed-off-by: Michael
nctional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/hyperv/hv_init.c | 22 --
> arch/x86/include/asm/mshyperv.h | 5 -
> drivers/hv/hv.c | 36
On Wed, Jan 27, 2021 at 11:18:31AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 27, 2021 at 03:05:24PM +0800, Boqun Feng wrote:
> > On Tue, Jan 26, 2021 at 08:40:24PM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 27, 2021 at 10:42:35AM +0800, Boqun Feng wrot
On Tue, Jan 26, 2021 at 08:40:24PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 27, 2021 at 10:42:35AM +0800, Boqun Feng wrote:
> > Hi Paul,
> >
> > On Tue, Jan 19, 2021 at 08:32:33PM -0800, paul...@kernel.org wrote:
> > > From: "Paul E. McKenney"
> &g
Hi Paul,
On Tue, Jan 19, 2021 at 08:32:33PM -0800, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> Historically, a task that has been subjected to RCU priority boosting is
> deboosted at rcu_read_unlock() time. However, with the advent of deferred
> quiescent states, if the outermost
The following commit has been merged into the locking/core branch of tip:
Commit-ID: bc2dd71b283665f0a409d5b6fc603d5a6fdc219e
Gitweb:
https://git.kernel.org/tip/bc2dd71b283665f0a409d5b6fc603d5a6fdc219e
Author:Boqun Feng
AuthorDate:Thu, 10 Dec 2020 11:02:40 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 9271a40d2a1429113160ccc4c16150921600bcc1
Gitweb:
https://git.kernel.org/tip/9271a40d2a1429113160ccc4c16150921600bcc1
Author:Boqun Feng
AuthorDate:Tue, 08 Dec 2020 18:31:12 +08:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 5f2962401c6e195222f320d12b3a55377b2d4653
Gitweb:
https://git.kernel.org/tip/5f2962401c6e195222f320d12b3a55377b2d4653
Author:Boqun Feng
AuthorDate:Thu, 10 Dec 2020 11:15:00 +01:00
On Wed, Jan 06, 2021 at 08:49:32PM +, Dexuan Cui wrote:
> > From: Michael Kelley
> > Sent: Wednesday, January 6, 2021 9:38 AM
> > From: Dexuan Cui
> > Sent: Tuesday, December 22, 2020 4:12 PM
> > >
> > > When a Linux VM runs on Hyper-V, if the host toolstack doesn't support
> > > hibernation
On Tue, Dec 22, 2020 at 01:52:50PM +1000, Nicholas Piggin wrote:
> Excerpts from Boqun Feng's message of November 14, 2020 1:30 am:
> > Hi Nicholas,
> >
> > On Wed, Nov 11, 2020 at 09:07:23PM +1000, Nicholas Piggin wrote:
> >> All the cool kids are doing it.
> >>
> >> Signed-off-by: Nicholas
Hi Dmitry,
On Fri, Dec 18, 2020 at 12:27:04PM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 18, 2020 at 2:30 AM Boqun Feng wrote:
> >
> > On Thu, Dec 17, 2020 at 07:21:18AM -0800, Paul E. McKenney wrote:
> > > On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote
On Thu, Dec 17, 2020 at 07:21:18AM -0800, Paul E. McKenney wrote:
> On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
> > >
> > > On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > > > On Wed, Dec 16, 2020 at
On Wed, Dec 09, 2020 at 05:21:58PM -0800, Paul E. McKenney wrote:
> On Tue, Dec 08, 2020 at 01:51:04PM +0100, Frederic Weisbecker wrote:
> > Hi Boqun Feng,
> >
> > On Tue, Dec 08, 2020 at 10:41:31AM +0800, Boqun Feng wrote:
> > > Hi Frederic,
> > >
> &g
Hi Frederic,
On Tue, Dec 08, 2020 at 11:04:38PM +0100, Frederic Weisbecker wrote:
> On Tue, Dec 08, 2020 at 10:24:09AM -0800, Paul E. McKenney wrote:
> > > It reduces the code scope running with BH disabled.
> > > Also narrowing down helps to understand what it actually protects.
> >
> > I
On Tue, Dec 08, 2020 at 03:33:24PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 08, 2020 at 06:31:12PM +0800, Boqun Feng wrote:
> > These tests are added for two purposes:
> >
> > * Test the implementation of wait context checks and related
> > annotations.
at the the comment of patch #4 in case I
miss something subtle.
Suggestion and comments are welcome!
Regards,
Boqun
Boqun Feng (4):
lockdep/selftest: Make HARDIRQ context threaded
lockdep: Allow wait context checking with empty ->held_locks
rcu/lockdep: Annotate the rcu_callback_
s still working without it. The idea is that if we currently
don't hold any lock, then the current context is the only one we should
use to check.
Signed-off-by: Boqun Feng
---
kernel/locking/lockdep.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b
context checking makes more sense for that configuration.
Signed-off-by: Boqun Feng
---
lib/locking-selftest.c | 232 +
1 file changed, 232 insertions(+)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 0af91a07fd18..c00ef4e69637 100644
annotations can be added to detect bugs like
using mutex in a RCU callback.
Signed-off-by: Boqun Feng
---
kernel/rcu/update.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 39334d2d2b37..dd59e6412f61 100644
--- a/kernel
-by: Boqun Feng
---
lib/locking-selftest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index afa7d4bb291f..0af91a07fd18 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -186,6 +186,7 @@ static void init_shared_classes(void
Hi Frederic,
On Fri, Nov 13, 2020 at 01:13:15PM +0100, Frederic Weisbecker wrote:
> This keeps growing up. Rest assured, most of it is debug code and sanity
> checks.
>
> Boqun Feng found that holding rnp lock while updating the offloaded
> state of an rdp isn't needed, and he wa
Hi Richard,
On Sun, Dec 06, 2020 at 11:59:16PM +0100, Richard Weinberger wrote:
> Hi!
>
> With both KMEMLEAK and KASAN enabled, I'm facing the following lockdep
> splat at random times on Linus' tree as of today.
> Sometimes it happens at bootup, sometimes much later when userspace has
>
The following commit has been merged into the locking/core branch of tip:
Commit-ID: e04ce676e7aa490dcf5df880592e3db5e842a9bc
Gitweb:
https://git.kernel.org/tip/e04ce676e7aa490dcf5df880592e3db5e842a9bc
Author:Boqun Feng
AuthorDate:Mon, 02 Nov 2020 13:37:42 +08:00
Hi Naresh,
On Wed, Dec 02, 2020 at 10:15:44AM +0530, Naresh Kamboju wrote:
> While running kselftests on arm64 db410c platform "BUG: Invalid wait context"
> noticed at different runs this specific platform running stable-rc 5.9.12-rc1.
>
> While running these two test cases we have noticed this
ify+0xa6/0xab
> >
> > This lockdep splat is reported after:
> > commit e918188611f0 ("locking: More accurate annotations for read_lock()")
> >
> > To clarify:
> > - read-locks are recursive only in interrupt context (when
> >in_in
Hi Steven,
On Mon, Nov 23, 2020 at 01:42:27PM -0500, Steven Rostedt wrote:
> On Mon, 23 Nov 2020 11:28:12 -0500
> Steven Rostedt wrote:
>
> > I noticed:
> >
> >
> > [ 237.650900] enabling event benchmark_event
> >
> > In both traces. Could you disable CONFIG_TRACEPOINT_BENCHMARK and see if
Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> Hyper-V frame buffer driver")
> Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on
> HyperV Gen 1 VMs.")
> Cc: Wei Hu
> Cc: Boqun Feng
> Signed-off-by: Dexuan C
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 43be4388e94b915799a24f0eaf664bf95b85231f
Gitweb:
https://git.kernel.org/tip/43be4388e94b915799a24f0eaf664bf95b85231f
Author:Boqun Feng
AuthorDate:Fri, 13 Nov 2020 19:05:03 +08:00
Hi Matthew,
On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
[...]
>
> It's not just about lockdep for semaphores. Mutexes will spin if the
> current owner is still running, so to convert an interrupt-released
> semaphore to a mutex, we need a way to mark the mutex as being
he problem.
Regards,
Boqun
On Tue, Nov 17, 2020 at 07:56:44AM -0500, Sasha Levin wrote:
> From: Boqun Feng
>
> [ Upstream commit d61fc96a37603384cd531622c1e89de1096b5123 ]
>
> Chris Wilson reported a problem spotted by check_chain_key(): a chain
> key got changed in validate_chain()
Hi Nicholas,
On Wed, Nov 11, 2020 at 09:07:23PM +1000, Nicholas Piggin wrote:
> All the cool kids are doing it.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/atomic.h | 681 ++---
> arch/powerpc/include/asm/cmpxchg.h | 62 +--
> 2 files changed,
cursion protection to fix this
problem and avoid similiar problems.
Signed-off-by: Boqun Feng
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
---
Hi David,
On Wed, Nov 11, 2020 at 03:01:21PM +0100, David Sterba wrote:
> On Tue, Nov 10, 2020 at 04:33:27PM +0100, David Sterba wrote:
> > On Tue, Nov 10, 2020 at 09:37:37AM +0800, Boqun Feng wrote:
> >
> > I'll run another test on top of the development branch in case th
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: d61fc96a37603384cd531622c1e89de1096b5123
Gitweb:
https://git.kernel.org/tip/d61fc96a37603384cd531622c1e89de1096b5123
Author:Boqun Feng
AuthorDate:Mon, 02 Nov 2020 13:37:41 +08:00
On Mon, Nov 09, 2020 at 05:49:25PM -0800, Darrick J. Wong wrote:
> On Tue, Nov 10, 2020 at 09:37:37AM +0800, Boqun Feng wrote:
> > Filipe Manana reported a warning followed by task hanging after attempts
> > to freeze a filesystem[1]. The problem happened in a L
On Mon, Nov 09, 2020 at 09:57:05AM +, Filipe Manana wrote:
>
>
> On 09/11/20 08:44, Boqun Feng wrote:
> > Hi Filipe,
> >
> > On Thu, Nov 05, 2020 at 09:10:12AM +0800, Boqun Feng wrote:
> >> On Wed, Nov 04, 2020 at 07:54:40PM +, Filipe Manana wrote:
ckdep turn-offs.
[1]: https://lore.kernel.org/lkml/a5cf643b-842f-7a60-73c7-85d738a92...@suse.com/
Reported-by: Filipe Manana
Fixes: 4d004099a668 ("lockdep: Fix lockdep recursion")
Signed-off-by: Boqun Feng
Cc: Peter Zijlstra
Cc: Jan Kara
Cc: David Sterba
Cc: Nikolay Borisov
Cc: "
Hi Filipe,
On Thu, Nov 05, 2020 at 09:10:12AM +0800, Boqun Feng wrote:
> On Wed, Nov 04, 2020 at 07:54:40PM +, Filipe Manana wrote:
> [...]
> >
> > Ok, so I ran 5.10-rc2 plus your two patches (the fix and the debug one):
> >
> > diff --git a/kernel/lock
On Fri, Nov 06, 2020 at 10:01:02AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2020 at 09:47:22AM +0800, Boqun Feng wrote:
> > On Thu, Nov 05, 2020 at 02:00:14PM -0800, paul...@kernel.org wrote:
> > > From: "Paul E. McKenney"
> > >
version, we get the expected
> usage:
>
> [ write<1> | size<14> | address<49> ]
>
> Functionally no change is expected, since that extra address bit is
> insignificant for enabled architectures.
>
> Signed-off-by: Marco Elver
Acked-
On Fri, Nov 06, 2020 at 10:03:21AM +0100, Marco Elver wrote:
> On Fri, 6 Nov 2020 at 02:23, Boqun Feng wrote:
> > Hi Marco,
> >
> > On Thu, Nov 05, 2020 at 02:03:24PM -0800, paul...@kernel.org wrote:
> > > From: Marco Elver
> > >
> > > The watchpo
On Thu, Nov 05, 2020 at 02:00:14PM -0800, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/Documentation/glossary.txt | 155
> ++
> 1 file changed, 155 insertions(+)
> create mode 100644
Hi Marco,
On Thu, Nov 05, 2020 at 02:03:24PM -0800, paul...@kernel.org wrote:
> From: Marco Elver
>
> The watchpoint encoding masks for size and address were off-by-one bit
> each, with the size mask using 1 unnecessary bit and the address mask
> missing 1 bit. However, due to the way the size
Hi Chris,
Could you try this to see if it fixes the problem? Thanks!
Regards,
Boqun
On Mon, Nov 02, 2020 at 01:37:41PM +0800, Boqun Feng wrote:
> Chris Wilson reported a problem spotted by check_chain_key(): a chain
> key got changed in validate_chain() because we modify the
Hi,
On Wed, Nov 04, 2020 at 04:18:08AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit e918188611f073063415f40fae568fa4d86d9044
> Author: Boqun Feng
> Date: Fri Aug 7 07:42:20 2020 +
>
> locking: More accurate annotations for read_lock
On Wed, Nov 04, 2020 at 07:54:40PM +, Filipe Manana wrote:
[...]
>
> Ok, so I ran 5.10-rc2 plus your two patches (the fix and the debug one):
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index b71ad8d9f1c9..b31d4ad482c7 100644
> --- a/kernel/locking/lockdep.c
> +++
On Wed, Nov 04, 2020 at 03:31:35PM +0100, Frederic Weisbecker wrote:
[...]
> >
> > > + rcu_segcblist_offload(cblist, false);
> > > + raw_spin_unlock_rcu_node(rnp);
> > > +
> > > + if (rdp->nocb_cb_sleep) {
> > > + rdp->nocb_cb_sleep = false;
> > > + wake_cb = true;
> > > + }
> > >
On Wed, Nov 04, 2020 at 10:22:36AM +0800, Boqun Feng wrote:
> On Tue, Nov 03, 2020 at 07:44:29PM +, Filipe Manana wrote:
> >
> >
> > On 03/11/20 14:08, Boqun Feng wrote:
> > > Hi Filipe,
> > >
> > > On Mon, Oct 26, 2020 at 11:
On Tue, Nov 03, 2020 at 07:44:29PM +, Filipe Manana wrote:
>
>
> On 03/11/20 14:08, Boqun Feng wrote:
> > Hi Filipe,
> >
> > On Mon, Oct 26, 2020 at 11:26:49AM +, Filipe Manana wrote:
> >> Hello,
> >>
> >> I've recently st
Hi Filipe,
On Mon, Oct 26, 2020 at 11:26:49AM +, Filipe Manana wrote:
> Hello,
>
> I've recently started to hit a warning followed by tasks hanging after
> attempts to freeze a filesystem. A git bisection pointed to the
> following commit:
>
> commit 4d004099a668c41522242aa146a38cc4eb59cb1e
Hi Frederic,
Could you copy the r...@vger.kernel.org if you have another version, it
will help RCU hobbyists like me to catch up news in RCU, thanks! ;-)
Please see below for some comments, I'm still reading the whole
patchset, so probably I miss something..
On Fri, Oct 23, 2020 at 04:46:38PM
/160390684819.31966.12048967113267928...@build.alporthouse.com/
Signed-off-by: Boqun Feng
Cc: Chris Wilson
---
lib/locking-selftest.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index afa7d4bb291f..4c24ac8a456c 100644
, there is only one case left (nest_lock) where we want
to skip checks in validate_chain(), we simply remove the modification
for ->read and rely on the return value of check_deadlock() to skip the
dependency adding.
Reported-by: Chris Wilson
Signed-off-by: Boqun Feng
Cc: Peter Zijlstra
---
Pe
Hi Andrea,
On Sun, Nov 01, 2020 at 10:26:14AM +0100, Andrea Righi wrote:
> I'm getting the following lockdep splat (see below).
>
> Apparently this warning starts to be reported after applying:
>
> e918188611f0 ("locking: More accurate annotations for read_lock()")
>
> It looks like a false
Hi Peter,
On Wed, Oct 28, 2020 at 08:59:10PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 28, 2020 at 08:42:09PM +0100, Peter Zijlstra wrote:
> > On Wed, Oct 28, 2020 at 05:40:48PM +, Chris Wilson wrote:
> > > Quoting Chris Wilson (2020-10-27 16:34:53)
> > > > Quoting Peter Zijlstra (2020-10-27
rong html output, and some
> literals are not properly identified.
>
> Also, the symbols used at the irq enabled/disable table
> are not displayed as expected, as they're not literals.
> Also, on another table they're using a different notation.
>
> Fixes: 224ec489d3cd ("lo
Hi,
On Tue, Oct 20, 2020 at 10:59:58AM -0400, Mathieu Desnoyers wrote:
> - On Oct 20, 2020, at 10:36 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Tue, Oct 20, 2020 at 09:47:13AM -0400, Mathieu Desnoyers wrote:
> >> +void membarrier_update_current_mm(struct mm_struct *next_mm)
> >>
On Tue, Oct 13, 2020 at 12:27:15PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2020 at 11:11:10AM +0800, Boqun Feng wrote:
>
> > I think this happened because in this commit debug_lockdep_rcu_enabled()
> > didn't adopt to the change that made lockdep_recursion a p
Hi,
On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > The following commit has been merged into the locking/core branch of tip:
> >
> > Commit-ID: 4d004099a668c41522242aa146a38cc4eb59cb1e
> > Gitweb:
On Fri, Oct 02, 2020 at 03:09:29PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 02, 2020 at 08:36:02PM +0800, Boqun Feng wrote:
>
> > But what if f2() is called with interrupt disabled? Or f2() disables
> > interrupt inside the function, like:
&g
On Wed, Sep 30, 2020 at 09:02:28PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 30, 2020 at 08:18:18PM +0800, Boqun Feng wrote:
>
> > For one thing, I do think that LOCK_READ_USED trace is helpful for
> > better reporting, because if there is a read lock in the dependency pat
On Wed, Sep 30, 2020 at 11:49:37AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote:
> > > I think there are two problems here:
> > >
> > >
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 6d1823ccc480866e571ab1206665d693aeb600cf
Gitweb:
https://git.kernel.org/tip/6d1823ccc480866e571ab1206665d693aeb600cf
Author:Boqun Feng
AuthorDate:Thu, 17 Sep 2020 16:01:50 +08:00
On Tue, Sep 29, 2020 at 10:31:56AM -0400, Qian Cai wrote:
> I tried to add a few new Kconfig options like LEDS_TRIGGERS instantly trigger
> a
> warning during the boot, and then there is null-ptr-deref in lockdep below.
> Any
> idea?
>
> [ 16.487309] WARNING: possible irq lock inversion
On Mon, Sep 28, 2020 at 10:51:04AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 17, 2020 at 04:01:50PM +0800, Boqun Feng wrote:
>
> > __cq_init(cq);
> > __cq_enqueue(cq, source_entry);
> >
> > + while (lock || (lock = __cq_dequeue(cq))) {
&g
On Mon, Sep 28, 2020 at 10:03:19AM +0200, Dmitry Vyukov wrote:
> On Thu, Sep 24, 2020 at 5:13 PM Boqun Feng wrote:
> >
> > Ping ;-)
> >
> > Regards,
> > Boqun
>
> Hi Boqun,
>
> Peter says this may also fix this issue:
> https://syzkaller.appspot
Ping ;-)
Regards,
Boqun
On Thu, Sep 17, 2020 at 04:01:50PM +0800, Boqun Feng wrote:
> Qian Cai reported a BFS_EQUEUEFULL warning [1] after read recursive
> deadlock detection merged into tip tree recently. Unlike the previous
> lockep graph searching, which iterate every lock class (e
he "exit" label).
[1]:
https://lore.kernel.org/lkml/17343f6f7f2438fc376125384133c5ba70c2a681.ca...@redhat.com/
Reported-by: Qian Cai
Signed-off-by: Boqun Feng
---
kernel/locking/lockdep.c | 108 ---
1 file changed, 67 insertions(+), 41 deletions(-)
On Wed, Sep 16, 2020 at 05:11:59PM -0400, Qian Cai wrote:
> On Thu, 2020-09-17 at 00:14 +0800, Boqun Feng wrote:
> > Found a way to resolve this while still keeping the BFS. Every time when
> > we want to enqueue a lock_list, we basically enqueue a whole dep list of
> > entr
On Wed, Sep 16, 2020 at 04:10:46PM +0800, Boqun Feng wrote:
> On Tue, Sep 15, 2020 at 02:32:51PM -0400, Qian Cai wrote:
> > On Fri, 2020-08-07 at 15:42 +0800, Boqun Feng wrote:
> > > Currently, in safe->unsafe detection, lockdep misses the fact that a
> > >
On Tue, Sep 15, 2020 at 02:32:51PM -0400, Qian Cai wrote:
> On Fri, 2020-08-07 at 15:42 +0800, Boqun Feng wrote:
> > Currently, in safe->unsafe detection, lockdep misses the fact that a
> > LOCK_ENABLED_IRQ_*_READ usage and a LOCK_USED_IN_IRQ_*_READ usage may
> > cause d
to HV_HYP_PAGE_SIZE).
Signed-off-by: Boqun Feng
Reviewed-by: Michael Kelley
---
drivers/hv/channel.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 3ebda7707e46..4d0f8e5a88d6 100644
--- a/drivers/hv/channel.c
+++ b
1 - 100 of 1674 matches
Mail list logo
