cache_free. Use kfree_rcu() directly.
>
> The changes were done using the following Coccinelle semantic patch.
> This semantic patch is designed to ignore cases where the callback
> function is used in another way.
For the series:
Acked-by: Paul E. McKenney
> //
> #spat
On Wed, Oct 09, 2024 at 07:08:58PM +0200, Julia Lawall wrote:
> Hello,
>
> I have rerun the semantic patch that removes call_rcu calls in cases where
> the callback function just does some pointer arithmetic and calls
> kmem_cache_free. Let me know if this looks ok, and if so, I can make a
> more
On Tue, Oct 08, 2024 at 06:41:12PM +0200, Vlastimil Babka wrote:
> On 7/24/24 15:53, Paul E. McKenney wrote:
> > On Mon, Jul 15, 2024 at 10:39:38PM +0200, Vlastimil Babka wrote:
> >> On 6/21/24 11:32 AM, Uladzislau Rezki wrote:
> >> > On Wed, Jun 19, 2024 at 11:28:13A
On Mon, Jul 15, 2024 at 10:39:38PM +0200, Vlastimil Babka wrote:
> On 6/21/24 11:32 AM, Uladzislau Rezki wrote:
> > On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote:
> > One question. Maybe it is already late but it is better to ask rather than
> > not.
> >
> > What do you think if
On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote:
> On 6/18/24 7:53 PM, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote:
> >> On 6/18/24 6:48 PM, Paul E. McKenney wrote:
> >> > On Tue, Jun 18, 2024 at 11:3
On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote:
> On 6/18/24 6:48 PM, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote:
> >> > On 6/17/24 8:42 PM, Uladzislau Rezki wrote:
> >> > >> +
> &
On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote:
> > On 6/17/24 8:42 PM, Uladzislau Rezki wrote:
> > >> +
> > >> +s = container_of(work, struct kmem_cache, async_destroy_work);
> > >> +
> > >> +// XXX use the real kmem_cache_free_barrier() or similar thing
> > >> h
On Mon, Jun 17, 2024 at 07:23:36PM +0200, Vlastimil Babka wrote:
> On 6/17/24 6:12 PM, Paul E. McKenney wrote:
> > On Mon, Jun 17, 2024 at 05:10:50PM +0200, Vlastimil Babka wrote:
> >> On 6/13/24 2:22 PM, Jason A. Donenfeld wrote:
> >> > On Wed, Jun 12, 2024 at 08:3
On Mon, Jun 17, 2024 at 05:10:50PM +0200, Vlastimil Babka wrote:
> On 6/13/24 2:22 PM, Jason A. Donenfeld wrote:
> > On Wed, Jun 12, 2024 at 08:38:02PM -0700, Paul E. McKenney wrote:
> >> o Make the current kmem_cache_destroy() asynchronously wait for
> >>all
On Fri, Jun 14, 2024 at 02:35:33PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 11:13:52AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 07:58:17PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
>
On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
>
On Thu, Jun 13, 2024 at 07:58:17PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
>
On Thu, Jun 13, 2024 at 04:11:52PM +0200, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2024 at 05:46:11AM -0700, Paul E. McKenney wrote:
> > How about a kmem_cache_destroy_rcu() that marks that specified cache
> > for destruction, and then a kmem_cache_destroy_barrier() that waits?
On Thu, Jun 13, 2024 at 07:17:38AM -0700, Jakub Kicinski wrote:
> On Wed, 12 Jun 2024 20:38:02 -0700 Paul E. McKenney wrote:
> > o Make rcu_barrier() wait for kfree_rcu() objects. (This is
> > surprisingly complex and will wait unnecessarily in some cases.
> > Howe
On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > &g
On Thu, Jun 13, 2024 at 02:31:53AM +0200, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2024 at 01:31:57AM +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
On Wed, Jun 12, 2024 at 04:52:57PM -0600, Jens Axboe wrote:
> On 6/12/24 4:37 PM, Paul E. McKenney wrote:
> > [PATCH 09/14] block: replace call_rcu by kfree_rcu for simple
> > kmem_cache_free callback
> > I don't see a kmem_cache_destroy(), but then again, I
On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > Since SLOB was removed, it is not necessary to use call_rcu
> > when the callback only performs kmem_cache_free. Use
> > kfree_rcu() directly.
> >
> > The changes were done
/\ 1:r7=0)
> Observation SB+atomic_add+fetch Never 0 9
>
> [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
> [2] https://www.kernel.org/doc/Documentation/atomic_t.txt
>
> Fixes: 65112709115f ("powerpc/bpf/64: add support for BPF_ATOMIC bitwise
> ope
On Tue, May 02, 2023 at 11:06:02PM +0800, zhouzho...@gmail.com wrote:
> From: Zhouyi Zhou
>
> Currently, default time between rcu torture forward-progress tests is 60HZ,
> Under this configuration, false positive caused by __stack_chk_fail [1] is
> difficult to reproduce (needs average 5*420 seco
On Sun, Mar 26, 2023 at 08:24:34AM +0800, zhouzho...@gmail.com wrote:
> From: Zhouyi Zhou
>
> The argument --enable-kvm is duplicated because qemu_args
> in kvm-test-1-run.sh has already give this.
>
> Signed-off-by: Zhouyi Zhou
Good catch! Applied, thank you!
On Fri, Mar 24, 2023 at 08:47:38AM +0530, Sachin Sant wrote:
>
> >>> Hello, Sachin, and it looks like you hit something that Zqiang and I
> >>> have been tracking down. I am guessing that you were using modprobe
> >>> and rmmod to make this happen, and that this happened at rmmod time.
> >>>
> >
On Thu, Mar 23, 2023 at 11:00:59PM +0530, Sachin Sant wrote:
>
> >> [ 3629.243407] NIP [7fff8cd39558] 0x7fff8cd39558
> >> [ 3629.243410] LR [00010d800398] 0x10d800398
> >> [ 3629.243413] --- interrupt: c00
> >> [ 3629.243415] Code: 419dffa4 e93a0078 3941 552907be 2f89 7d20579e
> >
On Thu, Mar 23, 2023 at 04:55:54PM +0530, Sachin Sant wrote:
> While running rcutorture tests from LTP on an IBM Power10 server booted with
> 6.3.0-rc3-next-20230322 following warning is observed:
>
> [ 3629.242831] [ cut here ]
> [ 3629.242835] WARNING: CPU: 8 PID: 614614
On Thu, Feb 23, 2023 at 09:31:48AM +0530, Kautuk Consul wrote:
> On 2023-02-22 09:47:19, Paul E. McKenney wrote:
> > On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> > > A link from ibm.com states:
> > > "Ensures that all instructions preceding the
On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions can be executed
> on the processor that executed the function. Also, it ensures that
>
gt; v1.1:
> - add __noreturn to all arch_cpu_idle_dead() implementations (mpe)
With this, rcutorture no longer gets objtool complaints on x86, thank you!
Tested-by: Paul E. McKenney
> Josh Poimboeuf (24):
> alpha/cpu: Expose arch_cpu_idle_dead()'s prototype declaration
> a
On Wed, Jan 25, 2023 at 05:34:49PM -0800, Andrew Morton wrote:
> On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan
> wrote:
>
> > On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton
> > wrote:
> > >
> > > On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan
> > > wrote:
> > >
> > > > Convert
On Fri, Jan 20, 2023 at 04:49:42PM +, Matthew Wilcox wrote:
> On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> > > >
> > > > On Thu 19-01-23
On Fri, Jan 20, 2023 at 09:57:05AM +0100, Michal Hocko wrote:
> On Thu 19-01-23 11:17:07, Paul E. McKenney wrote:
> > On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> > > On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > > > On Wed, Jan 18, 202
On Thu, Jan 19, 2023 at 11:47:36AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 19, 2023 at 11:20 AM Paul E. McKenney wrote:
> >
> > On Thu, Jan 19, 2023 at 10:52:03AM -0800, Suren Baghdasaryan wrote:
> > > On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> >
On Thu, Jan 19, 2023 at 10:52:03AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > call_rcu() can take a long time when callback offloading is enabled.
> > > Its use in the vm_area_free can cau
On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney
> > wrote:
> [...]
> > > There are a couple of possibilities here.
> > >
> > > F
On Wed, Jan 18, 2023 at 11:01:08AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney wrote:
> >
> > On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> > > On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> >
On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> > > >
> > > > On Mon 09-01-23 12:53:34, Suren Baghdasar
I know Mark has been prodding that with something sharp.
>
> The last version was tested by a number of people and I'm hoping to not have
> broken anything in the meantime ;-)
>
>
> Changes since v2:
150 rcutorture hours on each of the default scenarios passed. This
i
On Thu, Jan 12, 2023 at 10:49:04AM +1100, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > Now that the SRCU Kconfig option is unconditionally selected, there is
> > no longer any point in selecting it. Therefore, remove the "select SRCU"
> >
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig statements.
Signed-off-by: Paul E. McKenney
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc:
---
arch/powerpc/k
On Mon, Nov 28, 2022 at 09:12:28AM +0100, Thomas Gleixner wrote:
> On Sun, Nov 27 2022 at 09:53, Paul E. McKenney wrote:
> > On Sun, Nov 27, 2022 at 01:40:28PM +0100, Thomas Gleixner wrote:
> >> There are quite some reasons why a CPU-hotplug or a hot-unplug operation
> >&g
On Sun, Nov 27, 2022 at 01:40:28PM +0100, Thomas Gleixner wrote:
[ . . . ]
> >> No. We are not exporting this just to make a bogus test case happy.
> >>
> >> Fix the torture code to handle -EBUSY correctly.
> > I am going to do a study on this, for now, I do a grep in the kernel tree:
> > find .
On Wed, Nov 23, 2022 at 11:25:43PM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 21, 2022 at 05:37:54PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> > > @@ -358,7 +359,16 @@ tortu
On Wed, Nov 23, 2022 at 10:23:11AM +0800, Zhouyi Zhou wrote:
> On Tue, Nov 22, 2022 at 9:37 AM Paul E. McKenney wrote:
> >
> > On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> > > During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> > &g
On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> offline tick_do_timer_cpu, the operation will fail because in
> function tick_nohz_cpu_down:
> ```
> if (tick_nohz_full_running && tick_do_timer_cpu == cpu)
> return
On Wed, Sep 14, 2022 at 10:15:28AM +0800, Zhouyi Zhou wrote:
> During the cpu offlining, the sub functions of xive_teardown_cpu will
> call __lock_acquire when CONFIG_LOCKDEP=y. The latter function will
> travel RCU protected list, so "WARNING: suspicious RCU usage" will be
> triggered.
>
> Try to
On Sat, Jul 30, 2022 at 02:40:32AM -0700, Michel Lespinasse wrote:
> On Fri, Jul 29, 2022 at 08:26:22AM -0700, Paul E. McKenney wrote:> Would you
> be willing to try another shot in the dark, but untested
> > this time? I freely admit that this is
Or better yet, try the patch that Rafael proposed. ;-)
Thanx, Paul
On Fri, Jul 29, 2022 at 08:26:22AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 29, 2022 at 03:24:58AM -0700, Michel Lespinasse wrote:
> > On Thu, Jul 28, 2022
On Fri, Jul 29, 2022 at 03:24:58AM -0700, Michel Lespinasse wrote:
> On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wro
cessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
equivalent debugging.
Could you please try your test with the -rce commit shown below applied?
Thanx, Paul
-------
t; can remove these calls.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Acked-by: Paul E. McKenney
We have some fun conflicts between this series and Frederic's context-tracking
series. But it looks like these can be resolved by:
1. A patch on top of Frederic's series that pr
On Fri, May 27, 2022 at 02:49:03PM +0800, Chen Zhongjin wrote:
> Hi,
>
> On 2022/5/18 9:11, Paul E. McKenney wrote:
> > On Tue, May 17, 2022 at 11:22:04AM +0800, Chen Zhongjin wrote:
> >> On 2022/5/10 17:46, Chen Zhongjin wrote:
> >>> csdlock_debug uses early
On Tue, May 17, 2022 at 11:22:04AM +0800, Chen Zhongjin wrote:
> On 2022/5/10 17:46, Chen Zhongjin wrote:
> > csdlock_debug uses early_param and static_branch_enable() to enable
> > csd_lock_wait feature, which triggers a panic on arm64 with config:
> > CONFIG_SPARSEMEM=y
> > CONFIG_SPARSEMEM_VMEMM
rttunen
> Cc: Neeraj Upadhyay
> Cc: Nicholas Piggin
> Cc: Paul Mackerras
> Cc: Suzuki K Poulose
> Cc: Thierry Reding
> Cc: Thomas Bogendoerfer
> Signed-off-by: Guilherme G. Piccoli
>From an RCU perspective:
Acked-by: Paul E. McKenney
> ---
> arch/arm64/kernel/setup
gt; Excerpts from Michael Ellerman's message of April 9, 2022 12:42 am:
> >> Michael Ellerman writes:
> >>> "Paul E. McKenney" writes:
> >>>> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >>>>> Hi
> >&g
On Tue, Apr 12, 2022 at 04:53:06PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
> >> Zhouyi Zhou writes:
> >> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney
> >
On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
> Zhouyi Zhou writes:
> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney wrote:
> >> On Fri, Apr 08, 2022 at 06:02:19PM +0800, Zhouyi Zhou wrote:
> >> > On Fri, Apr 8, 2022 at 3:23 PM M
On Sat, Apr 09, 2022 at 12:42:39AM +1000, Michael Ellerman wrote:
> Michael Ellerman writes:
> > "Paul E. McKenney" writes:
> >> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >>> Hi
> >>>
> >>> I can reproduce
On Fri, Apr 08, 2022 at 06:02:19PM +0800, Zhouyi Zhou wrote:
> On Fri, Apr 8, 2022 at 3:23 PM Michael Ellerman wrote:
> >
> > "Paul E. McKenney" writes:
> > > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> > >> Hi
> > >&g
On Fri, Apr 08, 2022 at 05:23:32PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >> Hi
> >>
> >> I can reproduce it in a ppc virtual cloud server provided by Oregon
On Fri, Apr 08, 2022 at 07:14:20AM +0800, Zhouyi Zhou wrote:
> Dear Paul and Miguel
>
> On Fri, Apr 8, 2022 at 1:55 AM Paul E. McKenney wrote:
> >
> > On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> > > On Thu, Apr 7, 2022 at 5:15 PM
On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
> >
> > Ah. So you would instead look for boot to have completed within 10
> > seconds? Either way, reliable automation might well more important than
On Thu, Apr 07, 2022 at 12:07:34PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote:
> >
> > Yes, this happens within 30 seconds after kernel boot. If we take all
> > into account (qemu preparing, kernel loading), we can do one test
> > within 54 seconds.
>
> When it
On Thu, Apr 07, 2022 at 02:25:59AM +0800, Zhouyi Zhou wrote:
> Hi Paul
>
> On Thu, Apr 7, 2022 at 1:00 AM Paul E. McKenney wrote:
> >
> > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> > > Hi
> > >
> > > I can reproduce it
On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> Hi
>
> I can reproduce it in a ppc virtual cloud server provided by Oregon
> State University. Following is what I do:
> 1) curl -l
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz
>
On Thu, Mar 10, 2022 at 10:37:12AM +0800, Zhouyi Zhou wrote:
> Dear Paul
>
> I try to reproduce the bug in ppc64 VM in Oregon State University
> using the vmlinux extracted from
> https://owww.molgen.mpg.de/~pmenzel/rcutorture-2022.02.01-21.52.37-torture-locktorture-kasan-lock01.tar.xz
>
> the pp
On Mon, Feb 07, 2022 at 05:53:05PM +0100, Paul Menzel wrote:
> Dear Sebastian, dear Paul,
>
>
> In commit a6fda6dab9 (rcutorture: Tweak kvm options)
> `tools/testing/selftests/rcutorture/configs/rcu/CFcommon` was extended by
> the three selections below:
>
> CONFIG_HYPERVISOR_GUEST=y
> C
On Mon, Feb 07, 2022 at 05:44:47PM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On the POWER8 server IBM S822LC running Ubuntu 21.10, building Linux
> 5.17-rc2+ with rcutorture tests
>
> $ tools/testing/selftests/rcutorture/bin/torture.sh --duration 10
>
> the built init
>
> $ f
On Fri, Jan 28, 2022 at 08:15:47AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 28, 2022 at 04:11:57PM +, Mark Rutland wrote:
> > On Fri, Jan 28, 2022 at 05:08:48PM +0100, Sven Schnelle wrote:
> > > Hi Mark,
> > >
> > > Mark Rutland writes:
> > &
On Fri, Jan 28, 2022 at 04:11:57PM +, Mark Rutland wrote:
> On Fri, Jan 28, 2022 at 05:08:48PM +0100, Sven Schnelle wrote:
> > Hi Mark,
> >
> > Mark Rutland writes:
> >
> > > On arm64 I bisected this down to:
> > >
> > > 7a30871b6a27de1a ("rcu-tasks: Introduce ->percpu_enqueue_shift for
>
Hello, Linus,
This fix is for a regression in the v5.10 merge window, but it was
reported quite late in the v5.10 process, plus generating and testing
the fix took some time.
The regression is due to 36dadef23fcc ("kprobes: Init kprobes in
early_initcall") which on powerpc can use RCU Tasks befor
On Fri, Nov 27, 2020 at 01:02:29PM +1100, Daniel Axtens wrote:
> Hi all,
>
> I'm having some difficulty tracking down a bug.
>
> Some configurations of the powerpc kernel since somewhere in the 5.10
> merge window fail to boot on some ppc64 systems. They hang while trying
> to bring up SMP. It se
On Thu, Oct 29, 2020 at 11:09:07AM +1100, Michael Ellerman wrote:
> Qian Cai writes:
> > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > in the CPU-hotplug onlining process, which results in lockdep splats as
> > follows:
>
> Since when?
> What kernel version?
>
> I h
declared the CPU to be watched for readers.
>
> Link:
> https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
> Signed-off-by: Qian Cai
Acked-by: Paul E. McKenney
> ---
> arch/powerpc/kernel/smp.c | 3 ++-
> 1 file changed, 2 insertions(+)
On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the rcu tree got a conflict in:
> >
> > arch/powerpc/kernel/traps.c
> >
> > between commit:
> >
> > 116ac378bb3f
irier #
> hwtracing/coresight/Kconfig
> Signed-off-by: Mauro Carvalho Chehab
For the memory-barrier.txt portions:
Reviewed-by: Paul E. McKenney
> ---
> Documentation/memory-barriers.txt| 2 +-
> Documentation/process/submit-checklist.rst | 2 +-
>
On Thu, Apr 02, 2020 at 12:19:54PM -0400, Qian Cai wrote:
>
>
> > On Apr 2, 2020, at 11:54 AM, Paul E. McKenney wrote:
> >
> > I do run this combination quite frequently, but only as part of
> > rcutorture, which might not be a representative workload. For o
On Thu, Apr 02, 2020 at 10:00:16AM -0400, Qian Cai wrote:
>
>
> > On Apr 2, 2020, at 7:24 AM, Michael Ellerman wrote:
> >
> > Qian Cai writes:
> >> From: Peter Zijlstra
> >>
> >> In the CPU-offline process, it calls mmdrop() after idle entry and the
> >> subsequent call to cpuhp_report_idle_
t's an acronym and not part of a function name
>
> Signed-off-by: Randy Dunlap
> Cc: Paul McKenney
> Cc: Thomas Gleixner
> Cc: Sebastian Siewior
> Cc: Joel Fernandes
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
Some nits below, but with or without those suggested ch
On Wed, Mar 25, 2020 at 05:02:12PM +0100, Sebastian Siewior wrote:
> On 2020-03-25 13:27:49 [+0100], Thomas Gleixner wrote:
> > The documentation of rw_semaphores is wrong as it claims that the non-owner
> > reader release is not supported by RT. That's just history biased memory
> > distortion.
>
On Wed, Mar 25, 2020 at 12:13:34AM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
> > On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> > In the normal case where the task sleeps through the entire lock
> > acquisition,
Suggested-by: "Paul E. McKenney"
> Signed-off-by: Qais Yousef
> CC: Thomas Gleixner
> CC: "Paul E. McKenney"
Reviewed-by: Paul E. McKenney
> CC: Helge Deller
> CC: Michael Ellerman
> CC: "David S. Miller"
> CC: Juergen Gross
> CC: Mark Rutland
initial documentation.
>
> Signed-off-by: Thomas Gleixner
> Cc: "Paul E . McKenney"
> Cc: Jonathan Corbet
> Cc: Davidlohr Bueso
> Cc: Randy Dunlap
> ---
> V3: Addressed review comments from Paul, Jonathan, Davidlohr
> V2: Addressed review comments from
On Sat, Mar 21, 2020 at 11:26:06AM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> > On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
> >> I agree that what I tried to express is hard to parse, but it's at least
> >> halfw
On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> > On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> >> "Paul E. McKenney" writes:
> >> >
> >> > - The soft interrupt re
On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> >
> > - The soft interrupt related suffix (_bh()) still disables softirq
> >handlers. However, unlike non-PREEMPT_RT kernels (which disable
> >preem
On Thu, Mar 19, 2020 at 07:02:17PM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
>
> > On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
> >
> > Mostly native-English-speaker services below, so please feel fre
On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The kernel provides a variety of locking primitives. The nesting of these
> lock types and the implications of them on RT enabled kernels is nowhere
> documented.
>
> Add initial documentation.
>
> Sign
ce(). This patches
renames all of them to be rcu_dereference_raw_check() with the "_check()"
indicating sparse checking.
Signed-off-by: Joel Fernandes (Google)
[ paulmck: Fix checkpatch warnings about parentheses. ]
Signed-off-by: Paul E. McKenney
dif
On Tue, May 28, 2019 at 03:00:07PM -0400, Joel Fernandes wrote:
> On Tue, May 28, 2019 at 05:24:47AM -0700, Paul E. McKenney wrote:
> > On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
> > > On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
> On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
> > On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> > > On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> >
On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> > On Sat, 25 May 2019 04:14:44 -0400
> > Joel Fernandes wrote:
> >
> > > > I guess the difference between the _raw_notrace and just _raw variants
> > > > is that _no
On Thu, Apr 11, 2019 at 05:27:31AM -0700, Joe Perches wrote:
> On Thu, 2019-04-11 at 22:07 +1000, Michael Ellerman wrote:
> > Joe Perches writes:
> > > On Thu, 2019-04-11 at 06:27 +0200, Lukas Bulwahn wrote:
> > > > Paul McKenney attempted to update all email addresses
> > > > @linux.vnet.ibm.com
ed.
>
> We update the remaining email addresses in MAINTAINERS, hopefully finally
> catching all cases for good.
>
> Fixes: 1dfddcdb95c4 ("MAINTAINERS: Update from @linux.vnet.ibm.com to
> @linux.ibm.com")
> Signed-off-by: Lukas Bulwahn
For whatever it is worth:
: Paul Mackerras
> Cc: Mathieu Desnoyers
> Cc: Masami Hiramatsu
> Cc: Peter Zijlstra
> Cc: Andrew Morton
> Cc: Philippe Ombredanne
> Cc: Colin Ian King
> Cc: Byungchul Park
> Cc: "Paul E. McKenney"
> Cc: "Luis R. Rodriguez"
> Cc: Waiman Long
Commit-ID: 04229110adfba984950fc0209632640a76eb1de4
Gitweb: https://git.kernel.org/tip/04229110adfba984950fc0209632640a76eb1de4
Author: Paul E. McKenney
AuthorDate: Mon, 5 Nov 2018 16:53:13 -0800
Committer: Paul E. McKenney
CommitDate: Thu, 8 Nov 2018 21:43:20 -0800
powerpc: Convert
On Wed, Nov 14, 2018 at 03:43:05PM +0100, Christophe LEROY wrote:
>
>
> Le 09/11/2018 à 21:10, Paul E. McKenney a écrit :
> >On Fri, Nov 09, 2018 at 06:11:20PM +0100, Christophe LEROY wrote:
> >>(Resending due to error in Paul's address)
> >>
> >>
Now that call_rcu()'s callback is not invoked until after all
preempt-disable regions of code have completed (in addition to explicitly
marked RCU read-side critical sections), call_rcu() can be used in place
of call_rcu_sched(). This commit therefore makes that change.
Signed-off-by: P
On Fri, Nov 09, 2018 at 12:10:30PM -0800, Paul E. McKenney wrote:
> On Fri, Nov 09, 2018 at 06:11:20PM +0100, Christophe LEROY wrote:
> > (Resending due to error in Paul's address)
> >
> > Paul
> >
> > I get the following UBSAN reports in 4.20-rc1
On Fri, Nov 09, 2018 at 06:11:20PM +0100, Christophe LEROY wrote:
> (Resending due to error in Paul's address)
>
> Paul
>
> I get the following UBSAN reports in 4.20-rc1 on an MPC8321E
> (powerpc/book3s/32)
>
> I bisected it to 3e31009898699dfc ("rcu: Defer reporting RCU-preempt
> quiescent stat
On Fri, Nov 02, 2018 at 01:23:28PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 02, 2018 at 10:56:31AM +, David Laight wrote:
> > From: Paul E. McKenney
> > > Sent: 01 November 2018 17:02
> > ...
> > > And there is a push to define C++ signed arithmetic as 2
On Fri, Nov 02, 2018 at 10:56:31AM +, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 01 November 2018 17:02
> ...
> > And there is a push to define C++ signed arithmetic as 2s complement,
> > but there are still 1s complement systems with C compilers. Ju
1 - 100 of 410 matches
Mail list logo
