Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, Dec 7, 2022 at 7:05 AM Conor Dooley wrote: > > Hey Palmer, Xianting, > > On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote: > > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > > As disscussed in below patch set, the patch of 'describe VMCOREINFO > > > export in Documentation' > > > need to update according to Bagas's comments. > > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > > > As others patches in above patch set already applied, so this patch set > > > only contains below two > > > patches. > > > > > > [...] > > > > Applied, thanks! > > > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > > https://git.kernel.org/palmer/c/649d6b1019a2 > > So this patch seems to be causing issues for the nommu build: > https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/ > > I had a bit of a poke at trying to see if there were some headers we > could pull in before actually checking the .config only to see: > # CONFIG_MMU is not set > > Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix > compilation here? The problem does not belong to the patch. Could I send a fixup patch? like this? diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index ef8d66de5f38..d8c07999426c 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -512,6 +512,7 @@ config ARCH_HAS_KEXEC_PURGATORY config CRASH_DUMP bool "Build kdump crash kernel" + depends on KEXEC help Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels which are > > Thanks, > Conor. > -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] RISC-V: kexec: Fix memory leak of fdt buffer
On 2022/12/6 6:28, Palmer Dabbelt wrote: > On Fri, 4 Nov 2022 17:56:57 +0800, Li Huafei wrote: >> This is reported by kmemleak detector: >> >> unreferenced object 0xff6082864000 (size 9588): >> comm "kexec", pid 146, jiffies 4294900634 (age 64.788s) >> hex dump (first 32 bytes): >> d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...H...@ >> 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...( >> backtrace: >> [] kmemleak_alloc+0x34/0x3e >> [ ] kmalloc_order+0x9c/0xc4 >> [ ] kmalloc_order_trace+0x34/0xb6 >> [ ] __kmalloc+0x5c2/0x62a >> [<2bd497b2>] kvmalloc_node+0x66/0xd6 >> [<906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea >> [ ] elf_kexec_load+0x206/0x4ec >> [<36548e09>] kexec_image_load_default+0x40/0x4c >> [<79fbe1b4>] sys_kexec_file_load+0x1c4/0x322 >> [<40c62c03>] ret_from_syscall+0x0/0x2 >> >> [...] > > Applied, thanks! > > [1/2] RISC-V: kexec: Fix memory leak of fdt buffer > https://git.kernel.org/palmer/c/96df59b1ae23 > [2/2] RISC-V: kexec: Fix memory leak of elf header buffer > https://git.kernel.org/palmer/c/cbc32023ddbd > > These are on for-next. They'd probably be fine fixes candidates had I gotten > to them in time, but it's pretty late and a leak during kexec doesn't seem > like > a show-stopper. They'll get backported anyway, but this way they get an extra > week in linux-next just to see. > I have no problem with it being merged into the -next branch. Thanks Palmer! > Best regards, > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] RISC-V: kexec: Fix memory leak of fdt buffer
On 2022/12/6 6:28, Palmer Dabbelt wrote: > On Fri, 4 Nov 2022 17:56:57 +0800, Li Huafei wrote: >> This is reported by kmemleak detector: >> >> unreferenced object 0xff6082864000 (size 9588): >> comm "kexec", pid 146, jiffies 4294900634 (age 64.788s) >> hex dump (first 32 bytes): >> d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...H...@ >> 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...( >> backtrace: >> [] kmemleak_alloc+0x34/0x3e >> [ ] kmalloc_order+0x9c/0xc4 >> [ ] kmalloc_order_trace+0x34/0xb6 >> [ ] __kmalloc+0x5c2/0x62a >> [<2bd497b2>] kvmalloc_node+0x66/0xd6 >> [<906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea >> [ ] elf_kexec_load+0x206/0x4ec >> [<36548e09>] kexec_image_load_default+0x40/0x4c >> [<79fbe1b4>] sys_kexec_file_load+0x1c4/0x322 >> [<40c62c03>] ret_from_syscall+0x0/0x2 >> >> [...] > > Applied, thanks! > > [1/2] RISC-V: kexec: Fix memory leak of fdt buffer > https://git.kernel.org/palmer/c/96df59b1ae23 > [2/2] RISC-V: kexec: Fix memory leak of elf header buffer > https://git.kernel.org/palmer/c/cbc32023ddbd > > These are on for-next. They'd probably be fine fixes candidates had I gotten > to them in time, but it's pretty late and a leak during kexec doesn't seem > like > a show-stopper. They'll get backported anyway, but this way they get an extra > week in linux-next just to see. > I have no problem with it being merged into the -next branch. Thanks Palmer! > Best regards, > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
Hi Rafael
On Fri, 2 Dec 2022 at 18:48, Rafael J. Wysocki wrote:
>
> On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda wrote:
> >
> > Add a way to let the drivers know if the processes are frozen.
> >
> > This is needed by drivers that are waiting for processes to end on their
> > shutdown path.
> >
> > Convert pm_freezing into a function and export it, so it can be used by
> > drivers that are either built-in or modules.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine
> > drivers in .shutdown")
> > Signed-off-by: Ricardo Ribalda
>
> Why can't you export the original pm_freezing variable and why is this
> fixing anything?
Because then any module will be able to modify the content of the variable.
The Fixes: is because the last patch on the set is doing a real fix.
If you only cherry-pick the last patch on a stable branch, the build
will fail. (Also, the zero-day builder complains)
Anyway, I think we can hold this patch for a bit. The snd people are
discussing if this the way to handle it, or if we should handle
.shutdown in a different way.
Thanks!
>
> > ---
> > include/linux/freezer.h | 3 ++-
> > kernel/freezer.c| 3 +--
> > kernel/power/process.c | 24
> > 3 files changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> > index b303472255be..3413c869d68b 100644
> > --- a/include/linux/freezer.h
> > +++ b/include/linux/freezer.h
> > @@ -13,7 +13,7 @@
> > #ifdef CONFIG_FREEZER
> > DECLARE_STATIC_KEY_FALSE(freezer_active);
> >
> > -extern bool pm_freezing; /* PM freezing in effect */
> > +bool pm_freezing(void);
> > extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
> >
> > /*
> > @@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return
> > -ENOSYS; }
> > static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> > static inline void thaw_processes(void) {}
> > static inline void thaw_kernel_threads(void) {}
> > +static inline bool pm_freezing(void) { return false; }
> >
> > static inline bool try_to_freeze(void) { return false; }
> >
> > diff --git a/kernel/freezer.c b/kernel/freezer.c
> > index 4fad0e6fca64..2d3530ebdb7e 100644
> > --- a/kernel/freezer.c
> > +++ b/kernel/freezer.c
> > @@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
> > * indicate whether PM freezing is in effect, protected by
> > * system_transition_mutex
> > */
> > -bool pm_freezing;
> > bool pm_nosig_freezing;
> >
> > /* protects freezing and frozen transitions */
> > @@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
> > if (pm_nosig_freezing || cgroup_freezing(p))
> > return true;
> >
> > - if (pm_freezing && !(p->flags & PF_KTHREAD))
> > + if (pm_freezing() && !(p->flags & PF_KTHREAD))
> > return true;
> >
> > return false;
> > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > index ddd9988327fe..8a4d0e2c8c20 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
> > return todo ? -EBUSY : 0;
> > }
> >
> > +/*
> > + * Indicate whether PM freezing is in effect, protected by
> > + * system_transition_mutex.
> > + */
> > +static bool pm_freezing_internal;
> > +
> > +/**
> > + * pm_freezing - indicate whether PM freezing is in effect.
> > + *
> > + */
> > +bool pm_freezing(void)
> > +{
> > + return pm_freezing_internal;
> > +}
> > +EXPORT_SYMBOL(pm_freezing);
>
> Use EXPORT_SYMBOL_GPL() instead, please.
>
> > +
> > /**
> > * freeze_processes - Signal user space processes to enter the
> > refrigerator.
> > * The current thread will not be frozen. The same process that calls
> > @@ -126,12 +142,12 @@ int freeze_processes(void)
> > /* Make sure this task doesn't get frozen */
> > current->flags |= PF_SUSPEND_TASK;
> >
> > - if (!pm_freezing)
> > + if (!pm_freezing())
> > static_branch_inc(&freezer_active);
> >
> > pm_wakeup_clear(0);
> > pr_info("Freezing user space processes ... ");
> > - pm_freezing = true;
> > + pm_freezing_internal = true;
> > error = try_to_freeze_tasks(true);
> > if (!error) {
> > __usermodehelper_set_disable_depth(UMH_DISABLED);
> > @@ -187,9 +203,9 @@ void thaw_processes(void)
> > struct task_struct *curr = current;
> >
> > trace_suspend_resume(TPS("thaw_processes"), 0, true);
> > - if (pm_freezing)
> > + if (pm_freezing())
> > static_branch_dec(&freezer_active);
> > - pm_freezing = false;
> > + pm_freezing_internal = false;
> > pm_nosig_freezing = false;
> >
> > oom_killer_enable();
> >
> > --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromeos Kdump" group.
> To unsu
