From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Minchan Kim <minchan@kernel.org>, Dave Hansen <dave@sr71.net>,
Michal Nazarewicz <mina86@mina86.com>,
Jungsoo Son <jungsoo.son@lge.com>, Ingo Molnar <mingo@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/7] stacktrace: introduce snprint_stack_trace for buffer output
Date: Fri, 21 Nov 2014 15:37:59 -0800 [thread overview]
Message-ID: <20141121153759.c6a502e824207d517dd2f994@linux-foundation.org> (raw)
In-Reply-To: <1416557646-21755-6-git-send-email-iamjoonsoo.kim@lge.com>
On Fri, 21 Nov 2014 17:14:04 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> Current stacktrace only have the function for console output.
> page_owner that will be introduced in following patch needs to print
> the output of stacktrace into the buffer for our own output format
> so so new function, snprint_stack_trace(), is needed.
>
> ...
>
> --- a/include/linux/stacktrace.h
> +++ b/include/linux/stacktrace.h
> @@ -20,6 +20,8 @@ extern void save_stack_trace_tsk(struct task_struct *tsk,
> struct stack_trace *trace);
>
> extern void print_stack_trace(struct stack_trace *trace, int spaces);
> +extern int snprint_stack_trace(char *buf, int buf_len,
> + struct stack_trace *trace, int spaces);
>
> #ifdef CONFIG_USER_STACKTRACE_SUPPORT
> extern void save_stack_trace_user(struct stack_trace *trace);
> @@ -32,6 +34,7 @@ extern void save_stack_trace_user(struct stack_trace *trace);
> # define save_stack_trace_tsk(tsk, trace) do { } while (0)
> # define save_stack_trace_user(trace) do { } while (0)
> # define print_stack_trace(trace, spaces) do { } while (0)
> +# define snprint_stack_trace(buf, len, trace, spaces) do { } while (0)
Doing this with macros instead of C functions is pretty crappy - it
defeats typechecking and can lead to unused-var warnings when the
feature is disabled.
Fixing this might not be practical if struct stack_trace isn't
available, dunno.
> --- a/kernel/stacktrace.c
> +++ b/kernel/stacktrace.c
> @@ -25,6 +25,30 @@ void print_stack_trace(struct stack_trace *trace, int spaces)
> }
> EXPORT_SYMBOL_GPL(print_stack_trace);
>
> +int snprint_stack_trace(char *buf, int buf_len, struct stack_trace *trace,
> + int spaces)
> +{
> + int i, printed;
> + unsigned long ip;
> + int ret = 0;
> +
> + if (WARN_ON(!trace->entries))
> + return 0;
> +
> + for (i = 0; i < trace->nr_entries && buf_len; i++) {
> + ip = trace->entries[i];
> + printed = snprintf(buf, buf_len, "%*c[<%p>] %pS\n",
> + 1 + spaces, ' ', (void *) ip, (void *) ip);
> +
> + buf_len -= printed;
> + ret += printed;
> + buf += printed;
> + }
> +
> + return ret;
> +}
I'm not liking this much. The behaviour when the output buffer is too
small is scary. snprintf() will return "the number of characters which
would be generated for the given input", so local variable `buf_len'
will go negative and we pass a negative int into snprintf()'s `size_t
size'. snprintf() says "goody, lots and lots of buffer!" and your
machine crashes.
buf_len should be a size_t and snprint_stack_trace() will need to be
changed to handle this.
--
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:[~2014-11-21 23:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 8:13 [PATCH v2 0/7] Resurrect and use struct page extension for some debugging features Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 1/7] mm/page_ext: resurrect struct page extending code for debugging Joonsoo Kim
2014-11-21 23:37 ` Andrew Morton
2014-11-24 2:50 ` Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 2/7] mm/debug-pagealloc: prepare boottime configurable on/off Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 3/7] mm/debug-pagealloc: make debug-pagealloc boottime configurable Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 4/7] mm/nommu: use alloc_pages_exact() rather than it's own implementation Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 5/7] stacktrace: introduce snprint_stack_trace for buffer output Joonsoo Kim
2014-11-21 23:37 ` Andrew Morton [this message]
2014-11-24 2:57 ` Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 6/7] mm/page_owner: keep track of page owners Joonsoo Kim
2014-11-21 23:38 ` Andrew Morton
2014-11-24 3:09 ` Joonsoo Kim
2014-11-21 8:14 ` [PATCH v2 7/7] mm/page_owner: correct owner information for early allocated pages Joonsoo Kim
2014-11-21 23:38 ` Andrew Morton
2014-11-24 3:10 ` Joonsoo Kim
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=20141121153759.c6a502e824207d517dd2f994@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dave@sr71.net \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jungsoo.son@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
/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