Re: [PATCH] x86/rcutorture move CONFIG_HYPERVISOR_GUEST to kvm-test-1-run.sh

On Tue, Apr 30, 2024 at 7:22 AM Paul E. McKenney wrote: > > On Sat, Apr 27, 2024 at 12:56:26AM +, Zhouyi Zhou wrote: > > CONFIG_HYPERVISOR_GUEST is a x86 specific kernel option, move to > > kvm-test-1-run.sh to avoid ConfigFragment.diags in non-x86 platforms. > > &

[PATCH] x86/rcutorture move CONFIG_HYPERVISOR_GUEST to kvm-test-1-run.sh

Signed-off-by: Zhouyi Zhou --- tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 4 tools/testing/selftests/rcutorture/configs/rcu/CFcommon | 1 - 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh b/tools/testing

Re: There is a line missing in the diagram Figure 10.18 and Figure E.7

Thank Akira's guidance On Mon, Jan 15, 2024 at 7:18 PM Akira Yokosawa wrote: > > Hi Zhouyi, > > On 2024/01/15 15:20, Zhouyi Zhou wrote: > > Hi Paul and Akira, > > > > Our Chinese version editor Yunjing Li points out that there is a line > > missing in Figure

There is a line missing in the diagram Figure 10.18 and Figure E.7

bugs, fixing them is beyond my capability. Thanks, Zhouyi Reported-by: Yunjing Li Reported-by: Zhouyi Zhou

Re: [PATCH -perfbook] toolsoftrade: fix a typo: manpages should be man pages

Thank Akira for the warm hearted reminder On Mon, Jan 1, 2024 at 9:00 AM Akira Yokosawa wrote: > > Hi Zhouyi, > > On 2023/12/31 9:25, Paul E. McKenney wrote: > > On Sun, Dec 31, 2023 at 08:11:07AM +0800, Zhouyi Zhou wrote: > >> On Sun, Dec 31, 2023 at 7:59 AM Pa

Re: [PATCH -perfbook] toolsoftrade: fix a typo: manpages should be man pages

On Sun, Dec 31, 2023 at 7:59 AM Paul E. McKenney wrote: > > On Sat, Dec 30, 2023 at 04:59:29PM +0800, zhouzho...@gmail.com wrote: > > From: Zhouyi Zhou > > > > According to [1][2], manpages should be man pages or man-pages. > > > > [1] https://en.wikip

Re: [PATCH -perfbook] cpu: make Quick Quiz 3.6 more explicit

On Sat, Dec 30, 2023 at 7:22 AM Paul E. McKenney wrote: > > On Sat, Dec 30, 2023 at 07:15:56AM +0800, Zhouyi Zhou wrote: > > On Sat, Dec 30, 2023 at 7:09 AM Paul E. McKenney wrote: > > > > > > On Thu, Dec 28, 2023 at 11:55:00AM +0800, zhouzho...@gmail.com wr

Re: [PATCH -perfbook] cpu: make Quick Quiz 3.6 more explicit

On Sat, Dec 30, 2023 at 7:09 AM Paul E. McKenney wrote: > > On Thu, Dec 28, 2023 at 11:55:00AM +0800, zhouzho...@gmail.com wrote: > > From: Zhouyi Zhou > > > > Rewrite Quick Quiz 3.6 for clarity and explicitness, so that the > > firsttime reader know that another

Re: [PATCH -perfbook v4] howto: make ref to git archive explicit

On Wed, Dec 27, 2023 at 6:34 PM Akira Yokosawa wrote: > > On Wed, 27 Dec 2023 17:34:25 +0800, zhouzho...@gmail.com wrote: > > From: Zhouyi Zhou > > > > Make "git archive" in answer to Quick Quiz 1.3 more explicit, so that > > reader can easily

Re: [PATCH -perfbook v3] howto: make ref to git archive explicit

On Wed, Dec 27, 2023 at 3:50 PM Akira Yokosawa wrote: > > On Wed, 27 Dec 2023 14:39:20 +0800, zhouzho...@gmail.com wrote: > > From: Zhouyi Zhou > > > > Make "git archive" in answer to Quick Quiz 1.3 more explicit, so that > > reader can easily know where

Re: [PATCH perfbook] bib: make ref to git archive explicit

> Honestly speaking, I don't see much point in this update. Yunjin Li's original advice was "Can we make 'git archive' in answer to Quick Quiz 1.3 more explicit, so that reader can easily know where 'git archive' is" > > > > > Signed-off-by: Zhouyi Zhou > >

Re: SRCU: kworker hung in synchronize_srcu

On Fri, Sep 29, 2023 at 6:05 AM Joel Fernandes wrote: > > Hello, > Firstly, kudos to the detailed report and analysis. Rare failures are > hard and your usage crash/kdump is awesome to dig deeper into the > issue.. > > On Thu, Sep 28, 2023 at 3:59 AM zhuangel570 wrote: > > > > Hi, > > > > We

Re: [PATCH RFC] rcu: torture: shorten the time between forward-progress tests

On Thu, Aug 24, 2023 at 5:15 AM Paul E. McKenney wrote: > > 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 config

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

On Thu, Jul 6, 2023 at 3:09 PM Christophe Leroy wrote: > > > > Le 21/11/2022 à 04:51, Zhouyi Zhou a écrit : > > During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to > > offline tick_do_timer_cpu, the operation will fail because in > &g

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Thu, Apr 27, 2023 at 10:13 PM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > On Thu, Apr 27, 2023 at 11:09 AM Michael Ellerman > > wrote: > >> > >> Zhouyi Zhou writes: > >> > On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote: > >

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Thu, Apr 27, 2023 at 11:09 AM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote: > >> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman > >> wrote: > ... > >> > > >> > There's 12.2

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Thu, Apr 27, 2023 at 11:09 AM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote: > >> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman > >> wrote: > ... > >> > > >> > There's 12.2

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Wed, Apr 26, 2023 at 10:15 AM Joel Fernandes wrote: > > Hi Zhouyi, > > On Wed, Apr 26, 2023 at 09:31:17AM +0800, Zhouyi Zhou wrote: > [..] > > Joel makes the learning process easier for me, indeed! > > I know that feeling being a learner myself ;-) > > >

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Wed, Apr 26, 2023 at 8:33 AM Joel Fernandes wrote: > > On Tue, Apr 25, 2023 at 9:50 AM Zhouyi Zhou wrote: > > > > Hi > > > > On Tue, Apr 25, 2023 at 9:40 PM Christophe Leroy > > wrote: > > > > > > > > > > > > Le 25/04/

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

Hi On Tue, Apr 25, 2023 at 9:40 PM Christophe Leroy wrote: > > > > Le 25/04/2023 à 13:06, Joel Fernandes a écrit : > > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote: > >> > >> hi > >> > >> On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Tue, Apr 25, 2023 at 7:06 PM Joel Fernandes wrote: > > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote: > > > > hi > > > > On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra wrote: > > > > > > On Mon, Apr 24, 2023 at 02:55:11PM -0400, Joel Fe

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

hi On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra wrote: > > On Mon, Apr 24, 2023 at 02:55:11PM -0400, Joel Fernandes wrote: > > This is amazing debugging Boqun, like a boss! One comment below: > > > > > > > Or something simple I haven't thought of? :) > > > > > > > > At what points can r13

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote: > > hi > > On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman wrote: > > > > Zhouyi Zhou writes: > > > Dear PowerPC and RCU developers: > > > During the RCU torture test on mainline (on the VM of Opens

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

hi On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > Dear PowerPC and RCU developers: > > During the RCU torture test on mainline (on the VM of Opensource Lab > > of Oregon State University), SRCU-P failed with __stack_chk_fail: >

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > Dear PowerPC and RCU developers: > > During the RCU torture test on mainline (on the VM of Opensource Lab > > of Oregon State University), SRCU-P failed with __stack_chk_fail: >

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

Thank Boqun for your wonderful analysis! On Mon, Apr 24, 2023 at 8:33 AM Boqun Feng wrote: > > On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote: > > On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote: > > > > > > Dear PowerPC and RCU developers: >

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Sun, Apr 23, 2023 at 9:37 AM Zhouyi Zhou wrote: > > On Sun, Apr 23, 2023 at 3:19 AM Joel Fernandes wrote: > > > > Hi Zhouyi, > Thank Joel for your quick response ;-) > I will gradually provide all the necessary information to facilitate > our chasing. Please do n

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Sun, Apr 23, 2023 at 3:19 AM Joel Fernandes wrote: > > Hi Zhouyi, Thank Joel for your quick response ;-) I will gradually provide all the necessary information to facilitate our chasing. Please do not hesitate email me if I have ignored any ;-) > > On Sat, Apr 22, 2023 at 2:47 PM

BUG : PowerPC RCU: torture test failed with __stack_chk_fail

Dear PowerPC and RCU developers: During the RCU torture test on mainline (on the VM of Opensource Lab of Oregon State University), SRCU-P failed with __stack_chk_fail: [ 264.381952][ T99] [c6c7bab0] [c10c67c0] dump_stack_lvl+0x94/0xd8 (unreliable) [ 264.383786][ T99]

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

Thank you all for your guidance and encouragement! I learn how to construct commit message properly and learn how important the role that the torture test framework plays for the Linux kernel. Hope I can be of benefit to the community by my work. I am going to continue to study this topic and

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

Thank Thomas for your guidance On Sun, Nov 27, 2022 at 1:05 AM Thomas Gleixner wrote: > > On Mon, Nov 21 2022 at 11:51, 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 becau

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

On Thu, Nov 24, 2022 at 2:49 AM Paul E. McKenney wrote: > > 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: >

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

On Thu, Nov 24, 2022 at 6:37 AM Frederic Weisbecker 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 > > offline tick_do_timer_cpu, the operation will fail because in > > fun

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

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 > > offline tick_do_timer_cpu, the operation will fail because in > > fun

[PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

erformed in PPC VM of Open Source Lab of Oregon State University, and reproducable in RISC-V and X86-64 (with additional kernel commandline cpu0_hotplug). In this patch, we avoid offline tick_do_timer_cpu by distribute the offlining cpu among remaining cpus. Signed-off-by: Zhouyi Zhou --- inclu

Re: [PATCH linux-next][RFC] powerpc: fix HOTPLUG error in rcutorture

Hi, I also reappear the same phenomenon in RISC-V: [ 120.156380] scftorture: --- End of test: LOCK_HOTPLUG So I guess it is not the arch's responsibility. I am very interested in it ;-) Thank you both for your guidance! Cheers Zhouyi On Tue, Oct 11, 2022 at 9:59 AM Zhouyi Zhou wrote

[PATCH linux-next][RFC]powerpc: move pseries interrupt cleanup code to under __cpu_disable

in ppc VM of Open Source Lab of Oregon State University, by comparing the test results, our fix don't introduce new bugs and fixed previous "WARNING: suspicious RCU usage" bugs. Suggested-by: Nicholas Piggin Signed-off-by: Zhouyi Zhou --- Dear PPC and RCU developers I tries do move pseri

Re: [PATCH linux-next][RFC] powerpc: fix HOTPLUG error in rcutorture

Thanks Michael for reviewing my patch On Mon, Oct 10, 2022 at 7:21 PM Michael Ellerman wrote: > > Zhouyi Zhou writes: > > I think we should avoid torture offline the cpu who do tick timer > > when nohz full is running. > > Can you tell us what the bug you're fixing is?

Re: [PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline

On Mon, Oct 10, 2022 at 11:49 AM Nicholas Piggin wrote: > > On Thu Sep 29, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote: > > On Wed, Sep 28, 2022 at 10:51 AM Nicholas Piggin wrote: > > > > > > On Wed Sep 28, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote: > > &

[PATCH linux-next][RFC] powerpc: fix HOTPLUG error in rcutorture

Failures: 11 I examined the console.log and Make.out files one by one, no new compile error or test error is introduced by above fix. Signed-off-by: Zhouyi Zhou --- Dear PPC developers I found this bug when trying to do rcutorture tests in ppc VM of Open Source Lab of Oregon State University

Re: [PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline

On Wed, Sep 28, 2022 at 10:51 AM Nicholas Piggin wrote: > > On Wed Sep 28, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote: > > Thank Nick for reviewing my patch > > > > On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin wrote: > > > > > > On Tue Sep 27

Re: [PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline

Thank Nick for reviewing my patch On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin wrote: > > On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote: > > This is second version of my fix to PPC's "WARNING: suspicious RCU usage", > > I improved my fix under Paul E. M

[PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline

will call __lock_acquire when CONFIG_LOCKDEP=y. The latter function will travel RCU protected list, so "WARNING: suspicious RCU usage" will be triggered. Avoid lockdep when we are offline. Signed-off-by: Zhouyi Zhou --- Dear PPC and RCU developers I found this bug when trying to do rcutor

Re: [PATCH linux-next][RFC] powerpc: protect cpu offlining by RCU offline lock

On Wed, Sep 14, 2022 at 8:17 PM Paul E. McKenney wrote: > > 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 > > t

[PATCH linux-next][RFC] powerpc: protect cpu offlining by RCU offline lock

From: Zhouyi Zhou 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 protect cpu offlining by RCU offline loc

[PATCH linux-next][RFC] powerpc: protect cpu offlining by RCU offline lock

o my subject line. Signed-off-by: Zhouyi Zhou --- [it seems that there are some delivery problem in my previous email, so I send again via gmail, sorry for the trouble] Dear PPC and RCU developers I found this bug when trying to do rcutorture tests in ppc VM of Open Source Lab of Oregon State U

Re: [PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set

On Wed, Aug 24, 2022 at 12:50 AM Christophe Leroy wrote: > > > > Le 23/08/2022 à 10:47, Christophe Leroy a écrit : > > > > > > Le 23/08/2022 à 10:33, Michael Ellerman a écrit : > >> Zhouyi Zhou writes: > >> > >> My worry is that this

Re: [PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set

On Mon, Aug 22, 2022 at 2:04 PM Christophe Leroy wrote: > > > > Le 21/08/2022 à 03:00, Zhouyi Zhou a écrit : > > In ppc, compiler based sanitizer will generate instrument instructions > > around statement WRITE_ONCE(local_paca->irq_soft_mask, mask): > > > &

[PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set

;stb r9,2354(r31)", r31 may not equal to r13, in such case, irq soft mask will not work. This patch disable sanitizer in irq_soft_mask_set. Signed-off-by: Zhouyi Zhou --- Dear PPC developers I found this bug when trying to do rcutorture tests in ppc VM of Open Source Lab of Oreg

Re: [PATCH linux-next] powerpc: init jump label early in ppc 64

On Mon, Jul 25, 2022 at 3:55 PM Michael Ellerman wrote: > > zhouzho...@gmail.com writes: > > From: Zhouyi Zhou > > > > In ppc 64, invoke jump_label_init in setup_feature_keys is too late > > because static key will be used in subroutine of early_init_dev

Re: [PATCH linux-next] powerpc: use raw_smp_processor_id in arch_touch_nmi_watchdog

Thank John for correcting me ;-) On Thu, Jul 14, 2022 at 5:25 PM John Ogness wrote: > > On 2022-07-14, Zhouyi Zhou wrote: > > use raw_smp_processor_id() in arch_touch_nmi_watchdog > > because when called from watchdog, the cpu is preemptible. > > I would expect the cor

[PATCH linux-next] powerpc: use raw_smp_processor_id in arch_touch_nmi_watchdog

use raw_smp_processor_id() in arch_touch_nmi_watchdog because when called from watchdog, the cpu is preemptible. Signed-off-by: Zhouyi Zhou --- Dear PPC developers I found this bug when trying to do rcutorture tests in ppc VM of Open Source Lab of Oregon State University. qemu-system-ppc64

Re: rcu_sched self-detected stall on CPU

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 Michael Ellerman wrote: > > > > > > "Paul E. McKenney" writes: > > > > On Wed,

Re: rcu_sched self-detected stall on CPU

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 > >> > >> I can reproduce it in a ppc virtual cloud server provided by Oregon >

Re: rcu_sched self-detected stall on CPU

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 Paul E. McKenney wrote: > > > > > > Ah. So you would instead look for boot to have completed within 10 > > > seconds?

Re: rcu_sched self-detected stall on CPU

Hi Paul On Thu, Apr 7, 2022 at 3:50 AM Paul E. McKenney wrote: > > 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

Re: rcu_sched self-detected stall on CPU

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 in a ppc virtual cloud server provided by Oregon > > State University. Following is what I

Re: rcu_sched self-detected stall on CPU

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 -o linux-5.18-rc1.tar.gz 2) tar zxf linux-5.18-rc1.tar.gz 3) cp config

Re: rcutorture’s init segfaults in ppc64le VM

Dear Paul On Thu, Mar 10, 2022 at 4:10 PM Paul Menzel wrote: > > Dear Zhouyi, > > > Thank you for still looking into this. You are very welcome ;-) > > > Am 10.03.22 um 03:37 schrieb Zhouyi Zhou: > > > I try to reproduce the bug in ppc64 VM in Oregon State

Re: rcutorture’s init segfaults in ppc64le VM

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 ppc64 VM in which I run the qemu without hardware acceleration is: Linux

Re: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:256

Thank Matthew for correcting me On Sun, Feb 13, 2022 at 12:09 PM Matthew Wilcox wrote: > > On Sun, Feb 13, 2022 at 11:19:09AM +0800, Zhouyi Zhou wrote: > > I think the key to the problem lies in your attached console.log > > (pasted below), at times 0.014987 and 0.015995, I

Re: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:256

Dear Paul I think the key to the problem lies in your attached console.log (pasted below), at times 0.014987 and 0.015995, I see there are two locks (cpu_hotplug_lock and jump_label_mutex) holded while kmem_cache_alloc calls __might_resched (0.023356). I guess PowerPC's map_patch_area should

[PATCH linux-next] video: fbdev: fbmem: fix pointer reference to null device field

In function do_remove_conflicting_framebuffers, if device is NULL, there will be null pointer reference. The patch add a check to the if expression. Signed-off-by: Zhouyi Zhou --- Dear Linux folks I discover this bug in the PowerPC VM provided by Open source lab of Oregon State University

Re: BUG: Kernel NULL pointer dereference on write at 0x00000000 (rtmsg_ifinfo_build_skb)

Menzel and all other community members who support my tiny research. Thanks Zhouyi On Wed, Feb 2, 2022 at 10:39 AM Zhouyi Zhou wrote: > > Thank Paul for your encouragement! > > On Wed, Feb 2, 2022 at 1:50 AM Paul E. McKenney wrote: > > > > On Mon, Jan 31, 2022 at 09:08:40AM +08

Re: rcutorture’s init segfaults in ppc64le VM

Hi, The mailing list forward the emails to me in periodic style, very sorry not seeing Willy's email until I visited https://lore.kernel.org/rcu/20220207180901.gb14...@1wt.eu/T/#u, I am also very interested in testing Willy's proposal. Thanks a lot Zhouyi On Tue, Feb 8, 2022 at 1:46 PM Zhouyi

Re: rcutorture’s init segfaults in ppc64le VM

Dear Paul I am also very interested in the topic. The Open source lab of Oregon State University has lent me a 8 core power ppc64el VM for 3 months, I guess I can try reproducing this bug in the Virtual Machine by executing qemu in non hardware accelerated mode (using -no-kvm argument). I am

Re: [PATCH] D109408: [libcxxabi] NFC: fix incorrect indentation of braces

Hi， On Wed, Sep 8, 2021 at 10:01 AM zhouyizhou via Phabricator wrote: > > zhouyizhou added a comment. > > In D109408#2988417 , @ldionne wrote: > > > FWIW, I dislike that we don't indent stuff at all inside namespaces -- > > often I find it useful to

[tip: sched/urgent] preempt/dynamic: Fix typo in macro conditional statement

The following commit has been merged into the sched/urgent branch of tip: Commit-ID: 0c89d87d1d43d9fa268d1dc489518564d58bf497 Gitweb: https://git.kernel.org/tip/0c89d87d1d43d9fa268d1dc489518564d58bf497 Author:Zhouyi Zhou AuthorDate:Sat, 10 Apr 2021 15:35:23 +08:00

[tip: core/rcu] rcu: Remove spurious instrumentation_end() in rcu_nmi_enter()

The following commit has been merged into the core/rcu branch of tip: Commit-ID: 6494ccb93271bee596a12db32ff44867d5be2321 Gitweb: https://git.kernel.org/tip/6494ccb93271bee596a12db32ff44867d5be2321 Author:Zhouyi Zhou AuthorDate:Mon, 11 Jan 2021 09:08:59 +08:00 Committer

[PATCH] preempt/dynamic: fix typo in macro conditional statement

commit 40607ee97e4e ("preempt/dynamic: Provide irqentry_exit_cond_resched() static call") tried to provide irqentry_exit_cond_resched() static call in irqentry_exit, but has a typo in macro conditional statement. This patch fix this typo. Signed-off-by: Zhouyi Zhou --- kernel/entr

[PATCH] RCU: some improvements to comments of tree.c

During my study of RCU, I go through tree.c many times and try to make some improvements to the comments. Thanks a lot. Signed-off-by: Zhouyi Zhou --- kernel/rcu/tree.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel

[PATCH] rcu: remove surplus instrumentation_end in rcu_nmi_enter

as visited), I think remove the surplus instrumentation_end will make the code better. Signed-off-by: Zhouyi Zhou --- kernel/rcu/tree.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 40e5e3dd253e..eaec6f6032c2 100644 --- a/kernel/rcu/tree.c +++ b

[tip: core/rcu] rcu: Fix a typo in rcu_blocking_is_gp() header comment

The following commit has been merged into the core/rcu branch of tip: Commit-ID: 354c3f0e22dcb17c10d0b79f6e1c5ba286eec0b0 Gitweb: https://git.kernel.org/tip/354c3f0e22dcb17c10d0b79f6e1c5ba286eec0b0 Author:Zhouyi Zhou AuthorDate:Thu, 15 Oct 2020 03:53:03 Committer

[PATCH] RCU: fix a typo in comments of rcu_blocking_is_gp

There is a tiny typo in comment of function rcu_blocking_is_gp. Signed-off-by: Zhouyi Zhou --- kernel/rcu/tree.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index f78ee75..4cca03f 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu

[PATCH V2] kprobes: Correct a typo in function kprobes_module_callback

There is a tiny typo in comment of function kprobes_module_callback. Signed-off-by: Zhouyi Zhou --- kernel/kprobes.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index e995541..9d2042b 100644 --- a/kernel/kprobes.c +++ b/kernel

Re: [PATCH] kprobes: Correct a type error in function kprobes_module_callback

Thanks for the tip! On Thu, Oct 8, 2020 at 11:06 AM Randy Dunlap wrote: > > Hi, > > On 10/7/20 7:59 PM, Zhouyi Zhou wrote: > > There is a tiny type error in comment of function kprobes_module_callback. > > Preferable > typo > and same in $Subject.

[PATCH] kprobes: Correct a type error in function kprobes_module_callback

There is a tiny type error in comment of function kprobes_module_callback. Signed-off-by: Zhouyi Zhou --- kernel/kprobes.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index e995541..9d2042b 100644 --- a/kernel/kprobes.c +++ b

[PATCH] RCU: Adjust comments for force_qs_rnp

even if all corresponding CPUs offline")' Consequently, rcu does not initiate RCU priority boosting on root rcu_node. commit 1be0085b515e ("rcu: Don't initiate RCU priority boosting on root rcu_node")' So I think the comments for force_qs_rnp should be adjusted. Signed-off-by: Zhou

[ping*2] Fix ICE in pp_cxx_unqualified_id (PR c++/88348)

On Fri, Dec 14, 2018 at 10:59 AM Zhouyi Zhou wrote: > > Hello, > > Ping for https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00151.html > > By the way, are there any GCC open project for volunteer beginners to > > do in spare time. > > Thanks in advance for your feedba

[ping] Fix ICE in pp_cxx_unqualified_id (PR c++/88348)

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00151.html By the way, are there any GCC open project for volunteer beginners to do in spare time. Thanks in advance for your feedback, Zhouyi

Fix ICE in pp_cxx_unqualified_id (PR c++/88348)

cxx_pretty_printer::type_id do not treat pointer to pointer to member correctly. this patch handle pointer to pointer to member according to C++ standard 11.3.3. I don't have write access to gcc. Bootstrapped/regtested on x86_64-linux Signed-off-by: Zhouyi Zhou 2018-12-04 Zhouyi Zhou

[PING] [PATCH] Add a comma to comment in lower_eh_constructs_2

Hi, Following patch has not been reviewed for two weeks. I think the patch is trivial, it doesn't affect other parts of GCC. https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01005.html And I don't have write permission to GCC Thanks Zhouyi On Mon, May 21, 2018 at 12:09 PM, Zhouyi Zhou

[PATCH] Add a comma to comment in lower_eh_constructs_2

Hi I think the comment in lower_eh_constructs_2 need a comma. And I don't have write permission to GCC. Bootstraped on x86-64 Thanks, Zhouyi Signed-off-by: Zhouyi Zhou <zhouzho...@gmail.com> gcc/ChangeLog: 2018-05-21 Zhouyi Zhou <zhouzho...@gmail.com>

Re: [PATCH] srcu: remove never used variable

Thanks Paul's encouragement, I will keep studying SRCU code. On Fri, Feb 23, 2018 at 9:20 AM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Fri, Feb 23, 2018 at 09:04:05AM +0800, Zhouyi Zhou wrote: >> Thanks Paul for reviewing > > And thank you for your interest

Re: [PATCH] srcu: remove never used variable

Thanks Paul's encouragement, I will keep studying SRCU code. On Fri, Feb 23, 2018 at 9:20 AM, Paul E. McKenney wrote: > On Fri, Feb 23, 2018 at 09:04:05AM +0800, Zhouyi Zhou wrote: >> Thanks Paul for reviewing > > And thank you for your interest in SRCU! I am pretty sure that oth

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

Hi, In function __ext4_grp_locked_error, __save_error_info(sb, function, line) is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. The reason, I guess maybe it is in locked state. My question is why not

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

Hi, In function __ext4_grp_locked_error, __save_error_info(sb, function, line) is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. The reason, I guess maybe it is in locked state. My question is why not

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

group the qlist_node according to their cache, so as not to compare one by one to every qlist_node in the system. Sorry for your time Best Wishes Zhouyi On Wed, Nov 29, 2017 at 7:41 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: > Hi, > I will try to reestablish the environment, and

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

group the qlist_node according to their cache, so as not to compare one by one to every qlist_node in the system. Sorry for your time Best Wishes Zhouyi On Wed, Nov 29, 2017 at 7:41 AM, Zhouyi Zhou wrote: > Hi, > I will try to reestablish the environment, and design proof of >

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

Hi, I will try to reestablish the environment, and design proof of concept of experiment. Cheers On Wed, Nov 29, 2017 at 1:57 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Tue, Nov 28, 201

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

Hi, I will try to reestablish the environment, and design proof of concept of experiment. Cheers On Wed, Nov 29, 2017 at 1:57 AM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov wrote: >> On Tue, Nov 28, 2017 at 12:30 PM, Zhouyi Zhou wrote: >>> H

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

to drain because cache_free is fine in that context. I am willing do it if you think it is convenient :-) On Tue, Nov 28, 2017 at 5:27 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 10:17 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> H

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

to drain because cache_free is fine in that context. I am willing do it if you think it is convenient :-) On Tue, Nov 28, 2017 at 5:27 PM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 10:17 AM, Zhouyi Zhou wrote: >> Hi, >> Imagine all of the QUARANTINE_B

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

wrote: > On Tue, Nov 28, 2017 at 9:33 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> Hi, >>Please take a look at function quarantine_put, I don't think following >> code will limit the batch size below quarantine_batch_size. It only advance >&g

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

t 9:33 AM, Zhouyi Zhou wrote: >> Hi, >>Please take a look at function quarantine_put, I don't think following >> code will limit the batch size below quarantine_batch_size. It only advance >> quarantine_tail after qlist_move_all. >> &g

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

try Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 9:00 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> Thanks for reviewing >>My machine has 128G of RAM, and runs many KVM virtual machines. >> libvirtd always >> report "internal error:

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

try Vyukov wrote: > On Tue, Nov 28, 2017 at 9:00 AM, Zhouyi Zhou wrote: >> Thanks for reviewing >>My machine has 128G of RAM, and runs many KVM virtual machines. >> libvirtd always >> report "internal error: received hangup / error event on socket" under >

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

v 28, 2017 at 3:45 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 5:05 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> When there are huge amount of quarantined cache allocates in system, >> number of entries in global_quarantine[i] will be g

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

v 28, 2017 at 3:45 PM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 5:05 AM, Zhouyi Zhou wrote: >> When there are huge amount of quarantined cache allocates in system, >> number of entries in global_quarantine[i] will be great. Meanwhile, >> there is no relax in while lo

Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache

. On Tue, Nov 28, 2017 at 12:04 PM, <zhouzho...@gmail.com> wrote: > From: Zhouyi Zhou <zhouzho...@gmail.com> > > This patch fix livelock by conditionally release cpu to let others > has a chance to run. > > Tested on x86_64. > Signed-off-by: Zhouyi Zhou <zho

  1   2   3   4   >