| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 Jan 2010 14:24:04 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Stefani Seibold <stefani@...bold.net>
Cc: kosaki.motohiro@...fujitsu.com,
LKML <linux-kernel@...r.kernel.org>,
Samuel Thibault <samuel.thibault@...-lyon.org>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Alexey Dobriyan <adobriyan@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] partial revert to show stack information in /proc/<pid>/status
> As announce here is the patch to partial revert the show stack
> information patch due a not accepted performance regression. It will be
> now show only the current stack usage, not the high water mark.
>
> The path is only partial reverted because i need the other parts to do
> it in an other way.
>
> There are now two possibilities solutions:
>
> - create a new /proc/<pid>/stackinfo entry, which provides the reverted
> information and maybe others like the sigaltstack.
> - create a user space tool which use /proc/<pid>/pagemap
>
> In both cases the information of task->stack_start and the KSTK_ESP is
> needed.
>
> It will be also needed for an enhancement of the oom handler, where i
> free unused stack pages (the pages before the stack pointer) under high
> memory pressure. This is currently under work.
This explanation seems still strange. both task->stack_start and the KSTK_ESP are already exported
by /proc/{pid}/task/{tid}/stat. and This patch assume KSTK_ESP(task) - task->stack_start mean
StackUsage but it isn't the same as many people's assumption.
However, useless feature better than regression. probably I can ack this.
>
> Andrew please apply this patch to 2.6.34-rc* tree.
>
> Greetings,
> Stefani
>
> Signed-off-by: Stefani Seibold <stefani@...bold.net>
> ---
> Documentation/filesystems/proc.txt | 2
> fs/proc/array.c | 87 ++-----------------------------------
> 2 files changed, 8 insertions(+), 81 deletions(-)
>
> diff -u -N -r -p linux-2.6.33-rc2.orig/fs/proc/array.c linux-2.6.33-rc2.new/fs/proc/array.c
> --- linux-2.6.33-rc2.orig/fs/proc/array.c 2009-12-27 23:37:04.817427024 +0100
> +++ linux-2.6.33-rc2.new/fs/proc/array.c 2010-01-02 14:36:53.794188418 +0100
> @@ -327,93 +327,20 @@ static inline void task_context_switch_c
> p->nivcsw);
> }
>
> -#ifdef CONFIG_MMU
> -
> -struct stack_stats {
> - struct vm_area_struct *vma;
> - unsigned long startpage;
> - unsigned long usage;
> -};
> -
> -static int stack_usage_pte_range(pmd_t *pmd, unsigned long addr,
> - unsigned long end, struct mm_walk *walk)
> +static inline void task_show_stack_usage(struct seq_file *m,
> + struct task_struct *task)
> {
> - struct stack_stats *ss = walk->private;
> - struct vm_area_struct *vma = ss->vma;
> - pte_t *pte, ptent;
> - spinlock_t *ptl;
> - int ret = 0;
> -
> - pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> - for (; addr != end; pte++, addr += PAGE_SIZE) {
> - ptent = *pte;
> + unsigned long usage;
>
> + if (task->mm) {
> #ifdef CONFIG_STACK_GROWSUP
> - if (pte_present(ptent) || is_swap_pte(ptent))
> - ss->usage = addr - ss->startpage + PAGE_SIZE;
> + usage = KSTK_ESP(task) - task->stack_start;
> #else
> - if (pte_present(ptent) || is_swap_pte(ptent)) {
> - ss->usage = ss->startpage - addr + PAGE_SIZE;
> - pte++;
> - ret = 1;
> - break;
> - }
> + usage = task->stack_start - KSTK_ESP(task);
> #endif
> + seq_printf(m, "Stack usage:\t%lu kB\n", (usage + 1023) >> 10);
> }
> - pte_unmap_unlock(pte - 1, ptl);
> - cond_resched();
> - return ret;
> -}
> -
> -static inline unsigned long get_stack_usage_in_bytes(struct vm_area_struct *vma,
> - struct task_struct *task)
> -{
> - struct stack_stats ss;
> - struct mm_walk stack_walk = {
> - .pmd_entry = stack_usage_pte_range,
> - .mm = vma->vm_mm,
> - .private = &ss,
> - };
> -
> - if (!vma->vm_mm || is_vm_hugetlb_page(vma))
> - return 0;
> -
> - ss.vma = vma;
> - ss.startpage = task->stack_start & PAGE_MASK;
> - ss.usage = 0;
> -
> -#ifdef CONFIG_STACK_GROWSUP
> - walk_page_range(KSTK_ESP(task) & PAGE_MASK, vma->vm_end,
> - &stack_walk);
> -#else
> - walk_page_range(vma->vm_start, (KSTK_ESP(task) & PAGE_MASK) + PAGE_SIZE,
> - &stack_walk);
> -#endif
> - return ss.usage;
> -}
> -
> -static inline void task_show_stack_usage(struct seq_file *m,
> - struct task_struct *task)
> -{
> - struct vm_area_struct *vma;
> - struct mm_struct *mm = get_task_mm(task);
> -
> - if (mm) {
> - down_read(&mm->mmap_sem);
> - vma = find_vma(mm, task->stack_start);
> - if (vma)
> - seq_printf(m, "Stack usage:\t%lu kB\n",
> - get_stack_usage_in_bytes(vma, task) >> 10);
> -
> - up_read(&mm->mmap_sem);
> - mmput(mm);
> - }
> -}
> -#else
> -static void task_show_stack_usage(struct seq_file *m, struct task_struct *task)
> -{
> }
> -#endif /* CONFIG_MMU */
>
> static void task_cpus_allowed(struct seq_file *m, struct task_struct *task)
> {
> diff -u -N -r -p linux-2.6.33-rc2.orig/Documentation/filesystems/proc.txt linux-2.6.33-rc2.new/Documentation/filesystems/proc.txt
> --- linux-2.6.33-rc2.orig/Documentation/filesystems/proc.txt 2009-12-27 23:37:01.098310709 +0100
> +++ linux-2.6.33-rc2.new/Documentation/filesystems/proc.txt 2010-01-02 14:30:39.059150340 +0100
> @@ -231,7 +231,7 @@ Table 1-2: Contents of the statm files (
> Mems_allowed_list Same as previous, but in "list format"
> voluntary_ctxt_switches number of voluntary context switches
> nonvoluntary_ctxt_switches number of non voluntary context switches
> - Stack usage: stack usage high water mark (round up to page size)
> + Stack usage: stack usage in kB
> ..............................................................................
>
> Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists