[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120308000233.GA10695@redhat.com>
Date: Wed, 7 Mar 2012 19:02:33 -0500
From: Dave Jones <davej@...hat.com>
To: Michal Nazarewicz <mina86@...a86.com>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: decode GFP flags in oom killer output.
On Thu, Mar 08, 2012 at 12:48:08AM +0100, Michal Nazarewicz wrote:
> > +static void decode_gfp_mask(gfp_t gfp_mask, char *out_string)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < 32; i++) {
> > + if (gfp_mask & (1 << i)) {
> > + if (gfp_flag_texts[i])
> > + out_string += sprintf(out_string, "%s ", gfp_flag_texts[i]);
> > + else
> > + out_string += sprintf(out_string, "reserved! ");
> > + }
> > + }
> > + out_string = "\0";
>
> Uh? Did you mean “*out_string = 0;” which is redundant anyway?
Yeah, that was the intent.
> Also, this leaves a trailing space at the end of the string.
The zero was supposed to wipe it out, but I just realized it's advanced past it.
> > static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order,
> > struct mem_cgroup *memcg, const nodemask_t *nodemask)
> > {
> > + char gfp_string[80];
>
> For ~0, the string will be 256 characters followed by a NUL byte byte at the end.
> This combination may make no sense, but the point is that you need to take length
> of the buffer into account, probably by using snprintf() and a counter.
alternatively, we could just use a bigger buffer here.
thanks,
Dave
--
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