From: Michal Hocko <mhocko@kernel.org>
To: Joe Perches <joe@perches.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Jann Horn <jann@thejh.net>,
linux-mm@kvack.org
Subject: Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time
Date: Mon, 22 Aug 2016 09:24:15 +0200 [thread overview]
Message-ID: <20160822072414.GB13596@dhcp22.suse.cz> (raw)
In-Reply-To: <2c1ea0d8f35fa5ddea477369b273d6d91c5bf2e2.1471679737.git.joe@perches.com>
On Sat 20-08-16 01:00:17, Joe Perches wrote:
[...]
> static int proc_maps_open(struct inode *inode, struct file *file,
> const struct seq_operations *ops, int psize)
> {
> - struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> + struct proc_maps_private *priv;
> + struct mm_struct *mm;
> +
> + mm = proc_mem_open(inode, PTRACE_MODE_READ);
> + if (IS_ERR(mm))
> + return PTR_ERR(mm);
>
> + priv = __seq_open_private_bufsize(file, ops, psize,
> + mm && mm->map_count ?
> + mm->map_count * 0x300 : PAGE_SIZE);
NAK to this! Seriously, this just gives any random user access to user
defined amount of memory which not accounted, not reclaimable and a
potential consumer of any higher order blocks.
Besides that, at least one show_smap output will always fit inside the
single page and AFAIR (it's been quite a while since I've looked into
seq_file internals) the buffer grows only when the single show doesn't
fit in.
> if (!priv)
> return -ENOMEM;
>
> priv->inode = inode;
> - priv->mm = proc_mem_open(inode, PTRACE_MODE_READ);
> - if (IS_ERR(priv->mm)) {
> - int err = PTR_ERR(priv->mm);
> -
> - seq_release_private(inode, file);
> - return err;
> - }
> + priv->mm = mm;
>
> return 0;
> }
> @@ -721,6 +723,25 @@ void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> {
> }
>
> +static void show_val_kb(struct seq_file *m, const char *s, unsigned long num)
> +{
> + char v[32];
> + static const char blanks[7] = {' ', ' ', ' ', ' ',' ', ' ', ' '};
> + int len;
> +
> + len = num_to_str(v, sizeof(v), num >> 10);
> +
> + seq_write(m, s, 16);
> +
> + if (len > 0) {
> + if (len < 8)
> + seq_write(m, blanks, 8 - len);
> +
> + seq_write(m, v, len);
> + }
> + seq_write(m, " kB\n", 4);
> +}
> +
I really do not understand why you insist on code duplication rather
than reuse but if you really insist then just make this (without the
above __seq_open_private_bufsize, re-measure and add the results to the
changelog and repost.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-08-22 7:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 11:31 [PATCH] proc, smaps: reduce printing overhead Michal Hocko
2016-08-18 13:26 ` Joe Perches
2016-08-18 14:26 ` Michal Hocko
2016-08-18 14:41 ` Joe Perches
2016-08-18 14:41 ` Michal Hocko
2016-08-18 14:46 ` Joe Perches
2016-08-18 14:58 ` Michal Hocko
2016-08-18 15:23 ` Joe Perches
2016-08-18 16:42 ` Michal Hocko
2016-08-19 10:12 ` [PATCH 0/2] fs, proc: optimize smaps output formatting Michal Hocko
2016-08-19 10:12 ` [PATCH 1/2] proc, meminfo: abstract show_val_kb Michal Hocko
2016-08-26 2:54 ` [lkp] [proc, meminfo] dd3b422c11: stderr.Signal#(FPE)caught_by_ps(procps-ng_version#) kernel test robot
2016-08-19 10:13 ` [PATCH 2/2] proc, smaps: reduce printing overhead Michal Hocko
2016-08-19 17:43 ` [PATCH 0/2] fs, proc: optimize smaps output formatting Joe Perches
2016-08-19 20:18 ` Joe Perches
2016-08-20 7:29 ` Michal Hocko
2016-08-20 7:55 ` Joe Perches
2016-08-20 8:00 ` [PATCH 0/2] seq: Speed up /proc/<pid>/smaps Joe Perches
2016-08-20 8:00 ` [PATCH 1/2] seq_file: Add __seq_open_private_bufsize for seq file_operation sizes Joe Perches
2016-08-20 8:00 ` [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time Joe Perches
2016-08-22 7:24 ` Michal Hocko [this message]
2016-08-22 8:00 ` Joe Perches
2016-08-22 8:30 ` Joe Perches
2016-08-22 12:09 ` Michal Hocko
2016-08-23 15:14 ` [PATCH] proc, smaps: reduce printing overhead Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160822072414.GB13596@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=jann@thejh.net \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox