[PATCH v4 1/2] panic: add option to dump task maps info in panic_print
Lorenzo Stoakes
lorenzo.stoakes at oracle.com
Tue Oct 1 04:23:12 PDT 2024
+ Liam, Vlastimil
Sigh I hate to do it (honestly!), but NACK.
But, wait, I'll explain :)
I don't know what's going on with this thread, you have a 4th iteration of
a series I've never seen before that plays with VMAs, no cover letter, only
this one cc's linux-mm.
This is making my life really hard to review your work, you're playing with
VMAs but only partly cc'ing...
If you go for a v5, PLEASE create a cover letter and reply patches to
that. And cc everyone involve on all patches.
Something like
$ git format-patch -s --cover-letter --thread ...
Would work great for this, or even better b4 :)
On Tue, Sep 24, 2024 at 03:43:40PM GMT, qiwu.chen wrote:
> Currently, it's hard to debug panic issues caused by kill init,
> since there is no debug info from user mode in current panic msg
> such as the user_regs and maps info.
You haven't explained why printing all the VMAs for a specific process
helps?
We have dump_mm() that provides a sensible blob of mm information in such
situations already. Yes it's behind CONFIG_DEBUG_VM, that's on purpose.
You're STILL failing to provide a user who you are exporting symbols to.
>
> This patch adds an option to dump task maps info in panic_print.
>
> - changes history:
> v3:
> https://lore.kernel.org/all/20240922095504.7182-1-qiwu.chen@transsion.com/
> https://lore.kernel.org/all/20240922095504.7182-2-qiwu.chen@transsion.com/
> v2: https://lore.kernel.org/all/20231110031553.33186-1-qiwu.chen@transsion.com/
> v1: https://lore.kernel.org/all/20231110022720.GA3087@rlk/
>
> Signed-off-by: qiwu.chen <qiwu.chen at transsion.com>
> ---
> .../admin-guide/kernel-parameters.txt | 1 +
> Documentation/admin-guide/sysctl/kernel.rst | 1 +
> fs/proc/task_mmu.c | 3 +-
> include/linux/mm.h | 4 ++
> kernel/panic.c | 52 +++++++++++++++++++
> 5 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 8337d0fed311..f76709deef6c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4253,6 +4253,7 @@
> bit 5: print all printk messages in buffer
> bit 6: print all CPUs backtrace (if available in the arch)
> bit 7: print only tasks in uninterruptible (blocked) state
> + bit 8: print task maps info
Woefully, woefully inadequate documentation.
> *Be aware* that this option may print a _lot_ of lines,
> so there are risks of losing older messages in the log.
> Use this option carefully, maybe worth to setup a
> diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
> index f8bc1630eba0..558e365b76a9 100644
> --- a/Documentation/admin-guide/sysctl/kernel.rst
> +++ b/Documentation/admin-guide/sysctl/kernel.rst
> @@ -872,6 +872,7 @@ bit 4 print ftrace buffer
> bit 5 print all printk messages in buffer
> bit 6 print all CPUs backtrace (if available in the arch)
> bit 7 print only tasks in uninterruptible (blocked) state
> +bit 8 print task maps info
Equally woefully inadequate.
> ===== ============================================
>
> So for example to print tasks and memory info on panic, user can::
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index ade74a396968..37169ae36542 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -240,7 +240,7 @@ static int do_maps_open(struct inode *inode, struct file *file,
> sizeof(struct proc_maps_private));
> }
>
> -static void get_vma_name(struct vm_area_struct *vma,
> +void get_vma_name(struct vm_area_struct *vma,
> const struct path **path,
> const char **name,
> const char **name_fmt)
> @@ -300,6 +300,7 @@ static void get_vma_name(struct vm_area_struct *vma,
> return;
> }
> }
> +EXPORT_SYMBOL(get_vma_name);
Please stop exporting symbols arbitrarily. Oleg already raised this.
I aleady explained at [0] that I am not in favour of you exporting this and
you have failed to give a justification.
So NACK on this alone.
[0]: https://lore.kernel.org/linux-mm/20240929093212.40449-1-qiwu.chen@transsion.com/
>
> static void show_vma_header_prefix(struct seq_file *m,
> unsigned long start, unsigned long end,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 13bff7cf03b7..2fa403aae1de 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3566,6 +3566,10 @@ static inline bool range_in_vma(struct vm_area_struct *vma,
> #ifdef CONFIG_MMU
> pgprot_t vm_get_page_prot(unsigned long vm_flags);
> void vma_set_page_prot(struct vm_area_struct *vma);
> +void get_vma_name(struct vm_area_struct *vma,
> + const struct path **path,
> + const char **name,
> + const char **name_fmt);
> #else
> static inline pgprot_t vm_get_page_prot(unsigned long vm_flags)
> {
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 753d12f4dc8f..2217e1d0ad44 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -77,6 +77,8 @@ EXPORT_SYMBOL_GPL(panic_timeout);
> #define PANIC_PRINT_ALL_PRINTK_MSG 0x00000020
> #define PANIC_PRINT_ALL_CPU_BT 0x00000040
> #define PANIC_PRINT_BLOCKED_TASKS 0x00000080
> +#define PANIC_PRINT_TASK_MAPS_INFO 0x00000100
> +
> unsigned long panic_print;
>
> ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
> @@ -208,6 +210,53 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
> }
> EXPORT_SYMBOL(nmi_panic);
>
> +/*
> + * This function is called in panic proccess if the PANIC_PRINT_TASK_MAPS_INFO
> + * flag is specified in panic_print, which is helpful to debug panic issues due
> + * to an unhandled falut in user mode such as kill init.
> + */
> +static void dump_task_maps_info(struct task_struct *tsk)
> +{
> + struct pt_regs *user_ret = task_pt_regs(tsk);
> + struct mm_struct *mm = tsk->mm;
> + struct vm_area_struct *vma;
> +
> + if (!mm || !user_mode(user_ret))
> + return;
> +
> + pr_info("Dump task %s:%d maps start\n", tsk->comm, task_pid_nr(tsk));
> + mmap_read_lock(mm);
> + VMA_ITERATOR(vmi, mm, 0);
> + for_each_vma(vmi, vma) {
> + int flags = vma->vm_flags;
> + unsigned long long pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT;
> + const struct path *path;
> + const char *name_fmt, *name;
> + char name_buf[SZ_256];
> +
> + get_vma_name(vma, &path, &name, &name_fmt);
> + if (path) {
> + name = d_path(path, name_buf, sizeof(name_buf));
> + name = IS_ERR(name) ? "?" : name;
> + } else if (name || name_fmt) {
> + snprintf(name_buf, sizeof(name_buf), name_fmt ?: "%s", name);
> + name = name_buf;
> + }
> +
> + if (name)
> + pr_info("%08lx-%08lx %c%c%c%c %08llx %s\n",
> + vma->vm_start, vma->vm_end,
> + flags & VM_READ ? 'r' : '-',
> + flags & VM_WRITE ? 'w' : '-',
> + flags & VM_EXEC ? 'x' : '-',
> + flags & VM_MAYSHARE ? 's' : 'p',
> + pgoff, name);
> +
> + }
> + mmap_read_unlock(mm);
> + pr_info("Dump task %s:%d maps end\n", tsk->comm, task_pid_nr(tsk));
> +}
Surely taking the mm sem on panic (!) is a really bad idea? Not sure if we
do this elsewhere but the lock might deadlock, you're not using a 'try'
variant or a killable variant, you're just saying 'hey wait forever if we
can't get this even though I know the kernel is inconsistent'. That's just
crazy to me?
Also PLEASE PLEASE NO. Do not put arbitrary mm, VMA code in a random file,
this is just not acceptable.
All mm code needs to live in mm files. As I said in the other thread, we
are planning to change how we lock things around /proc/$pid/maps
iterations, and sorry but having a random other place do this with whatever
locking is applied is just a big, big no.
> +
> static void panic_print_sys_info(bool console_flush)
> {
> if (console_flush) {
> @@ -233,6 +282,9 @@ static void panic_print_sys_info(bool console_flush)
>
> if (panic_print & PANIC_PRINT_BLOCKED_TASKS)
> show_state_filter(TASK_UNINTERRUPTIBLE);
> +
> + if (panic_print & PANIC_PRINT_TASK_MAPS_INFO)
> + dump_task_maps_info(current);
> }
>
> void check_panic_on_warn(const char *origin)
> --
> 2.25.1
>
>
More information about the linux-arm-kernel
mailing list