Re: [PATCH] tracing: Remove precision vsnprintf() check from print event

40227125706.04279...@gandalf.local.home > Link: https://lore.kernel.org/all/20240302111244.3a167...@gandalf.local.home/ > > Reported-by: Sachin Sant > Fixes: 60be76eeabb3d ("tracing: Add size check when printing trace_marker > output") > Signed-off-by: Steven Rostedt

Re: [PATCH V2] selftests/cgroup: Fix build on older distros

> On 11-Nov-2020, at 3:45 AM, Shuah Khan wrote: > > On 11/6/20 12:40 AM, Sachin Sant wrote: >> --- >> V2: Replace all instances of clone_args by __clone_args >> --- >> diff --git a/a/tools/testing/selftests/cgroup/cgroup_util.c >> b/b/tools/testing/

[PATCH V2] selftests/cgroup: Fix build on older distros

type 'struct clone_args' But the selftests already have a locally defined version of the structure which is up to date, called __clone_args. So use __clone_args which fixes the error. Signed-off-by: Michael Ellerman Signed-off-by: Sachin Sant > Acked-by: Christian Brauner --- V2: Replace

Re: [PATCH] selftests/cgroup: Fix build on older distros

> On 04-Nov-2020, at 3:35 PM, Michael Ellerman wrote: > > On older distros struct clone_args does not have a cgroup member, > leading to build errors: > > cgroup_util.c: In function 'clone_into_cgroup': > cgroup_util.c:343:4: error: 'struct clone_args' has no member named 'cgroup' > > But

Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic

> On 03-Sep-2019, at 1:43 PM, Naresh Kamboju wrote: > > On Tue, 3 Sep 2019 at 09:51, Qian Cai wrote: >> >> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” >> [1] causes boot panic on all >> architectures here on today’s linux-next (0902). Reverted it will fix the

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

> On 30-Aug-2019, at 8:43 PM, David Howells wrote: > > Can you try this patch instead of Hillf’s? Works for me. Test ran fine without any problem. Tested-by: Sachin Sant Thanks -Sachin

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

> On 30-Aug-2019, at 2:26 PM, Hillf Danton wrote: > > > On Fri, 30 Aug 2019 12:18:07 +0530 Sachin Sant wrote: >> >> [ 8074.351033] BUG: Kernel NULL pointer dereference at 0x0038 >> [ 8074.351046] Faulting instruction address: 0xc04ddf30 >>

Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

While running LTP tests (specifically cve-2016-7042) against 5.3-rc6 (commit 4a64489cf8) on a POWER9 LPAR, following problem is seen [ 3373.814425] FS-Cache: Netfs 'nfs' registered for caching [ 7695.250230] Clock: inserting leap second 23:59:60 UTC [ 8074.351033] BUG: Kernel NULL pointer

Re: [PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver

into tpm_chip_register. This ensures that allocated banks are initialized >> in any case. >> >> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with >> PCR read") >> Signed-off-by: Nayna Jain > Reviewed-by: Mimi Zohar Thanks for the fix. Kernel boots fine with this fix. Tested-by: Sachin Sant Thanks -Sachin

Re: [next][PowerPC] RCU stalls while booting linux-next on PowerVM LPAR

> On 24-Jun-2019, at 8:12 PM, David Hildenbrand wrote: > > On 24.06.19 16:09, Sachin Sant wrote: >> Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls. >> >> This problem was introduced with next-20190620 (dc636f5d78). >> next-20190619 was l

[next][PowerPC] RCU stalls while booting linux-next on PowerVM LPAR

Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls. This problem was introduced with next-20190620 (dc636f5d78). next-20190619 was last good kernel. Reverting following commit allows the kernel to boot. 2fd4aeea6b603 : mm/memory_hotplug: move and simplify walk_memory_blocks()

Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470

> On 04-Jun-2019, at 3:59 PM, Stephen Rothwell wrote: > > Hi Sachin, > > On Tue, 4 Jun 2019 14:45:43 +0530 Sachin Sant > wrote: >> >> While booting linux-next [next-20190603] on a POWER9 LPAR following >> BUG is encountered and the boot fails. >>

[PowerPC][next-20190603] WARNING: at kernel/fork.c:721

While booting linux-next [20190603] on a POWER9 LPAR ran into following warning [9.002935] WARNING: CPU: 0 PID: 1 at kernel/fork.c:721 __put_task_struct+0x34/0x170 [9.002947] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod [9.002960] CPU: 0 PID: 1 Comm: systemd Not tainted

[POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470

While booting linux-next [next-20190603] on a POWER9 LPAR following BUG is encountered and the boot fails. If I revert the following 2 patches I no longer see this BUG message 07031d37b2f9 ( mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va() ) 728e0fbf263e ( mm/vmalloc.c: get rid of

Re: WARN @lib/refcount.c:128 during hot unplug of I/O adapter.

> On 07-Apr-2017, at 2:14 AM, Tyrel Datwyler <tyr...@linux.vnet.ibm.com> wrote: > > On 04/06/2017 03:27 AM, Sachin Sant wrote: >> On a POWER8 LPAR running 4.11.0-rc5, a hot unplug operation on >> any I/O adapter results in the following warning > > I remember y

Re: WARN @lib/refcount.c:128 during hot unplug of I/O adapter.

> On 07-Apr-2017, at 2:14 AM, Tyrel Datwyler wrote: > > On 04/06/2017 03:27 AM, Sachin Sant wrote: >> On a POWER8 LPAR running 4.11.0-rc5, a hot unplug operation on >> any I/O adapter results in the following warning > > I remember you mentioning this when the issue

WARN @lib/refcount.c:128 during hot unplug of I/O adapter.

On a POWER8 LPAR running 4.11.0-rc5, a hot unplug operation on any I/O adapter results in the following warning This problem has been in the code for some time now. I had first seen this in -next tree. [ 269.589441] rpadlpar_io: slot PHB 72 removed [ 270.589997] refcount_t: underflow;

WARN @lib/refcount.c:128 during hot unplug of I/O adapter.

On a POWER8 LPAR running 4.11.0-rc5, a hot unplug operation on any I/O adapter results in the following warning This problem has been in the code for some time now. I had first seen this in -next tree. [ 269.589441] rpadlpar_io: slot PHB 72 removed [ 270.589997] refcount_t: underflow;

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

to test in your setup. I tested the patch on 2 different systems where I ran into this problem. In both cases the system boots without any warning. A quick module load/unload test also worked correctly. Tested-by: Sachin Sant <sach...@linux.vnet.ibm.com> Thanks -Sachin

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

to test in your setup. I tested the patch on 2 different systems where I ran into this problem. In both cases the system boots without any warning. A quick module load/unload test also worked correctly. Tested-by: Sachin Sant Thanks -Sachin

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

> Thanks for the suggestion! I would like to see if this resolves the ppc issue > we had. I'm attaching a powerpc patch based on your suggestion. Hopefully, > Sachin can try it. > > Thanks, > I tried this patch. It does not fix the warning. [ 11.709071] mount (2956) used greatest stack

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

> Thanks for the suggestion! I would like to see if this resolves the ppc issue > we had. I'm attaching a powerpc patch based on your suggestion. Hopefully, > Sachin can try it. > > Thanks, > I tried this patch. It does not fix the warning. [ 11.709071] mount (2956) used greatest stack

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

>> While booting next-20170217 on a POWER6 box, I ran into following >> warning. This is a full system lpar. Previous next tree was good. >> I will try a bisect tomorrow. > > Do you have CONFIG_DEBUG_SHIRQ=y ? > Yes. CONFIG_DEBUG_SHIRQ is enabled. As suggested by you reverting following

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

>> While booting next-20170217 on a POWER6 box, I ran into following >> warning. This is a full system lpar. Previous next tree was good. >> I will try a bisect tomorrow. > > Do you have CONFIG_DEBUG_SHIRQ=y ? > Yes. CONFIG_DEBUG_SHIRQ is enabled. As suggested by you reverting following

next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

While booting next-20170217 on a POWER8 LPAR following warning is displayed. Reverting the following commit helps boot cleanly. commit 3821fd35b5 : jump_label: Reduce the size of struct static_key [ 11.393008] [ cut here ] [ 11.393031] WARNING: CPU: 5 PID: 2890 at

next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

While booting next-20170217 on a POWER8 LPAR following warning is displayed. Reverting the following commit helps boot cleanly. commit 3821fd35b5 : jump_label: Reduce the size of struct static_key [ 11.393008] [ cut here ] [ 11.393031] WARNING: CPU: 5 PID: 2890 at

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

>>> I've seen it on tip. It looks like hot unplug goes really slow when >>> there's running tasks on the CPU being taken down. >>> >>> What I did was something like: >>> >>> taskset -p $((1<<1)) $$ >>> for ((i=0; i<20; i++)) do while :; do :; done & done >>> >>> taskset -p $((1<<0)) $$ >>>

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

>>> I've seen it on tip. It looks like hot unplug goes really slow when >>> there's running tasks on the CPU being taken down. >>> >>> What I did was something like: >>> >>> taskset -p $((1<<1)) $$ >>> for ((i=0; i<20; i++)) do while :; do :; done & done >>> >>> taskset -p $((1<<0)) $$ >>>

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

> On 02-Feb-2017, at 9:25 PM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote: >> On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith <efa...@gmx.de> wrote: >>> On Tue, 2017-01-31 at 16:30 +0530, S

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

> On 02-Feb-2017, at 9:25 PM, Peter Zijlstra wrote: > > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote: >> On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith wrote: >>> On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > > > Could some of you t

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

Trimming the cc list. >> I assume I should be worried? > > Thanks for the report. No need to worry, the bug has existed for a > while, this patch just turns on the warning ;-) > > The following commit queued up in tip/sched/core should fix your > issues (assuming you see the same callstack on

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

Trimming the cc list. >> I assume I should be worried? > > Thanks for the report. No need to worry, the bug has existed for a > while, this patch just turns on the warning ;-) > > The following commit queued up in tip/sched/core should fix your > issues (assuming you see the same callstack on