All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: decode GFP flags in oom killer output.
Date: Wed, 7 Mar 2012 19:02:33 -0500	[thread overview]
Message-ID: <20120308000233.GA10695@redhat.com> (raw)
In-Reply-To: <op.watq2ixr3l0zgt@mpn-glaptop>

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 a??*out_string = 0;a?? 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, 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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Dave Jones <davej@redhat.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: decode GFP flags in oom killer output.
Date: Wed, 7 Mar 2012 19:02:33 -0500	[thread overview]
Message-ID: <20120308000233.GA10695@redhat.com> (raw)
In-Reply-To: <op.watq2ixr3l0zgt@mpn-glaptop>

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

  reply	other threads:[~2012-03-08  0:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 23:39 decode GFP flags in oom killer output Dave Jones
2012-03-07 23:39 ` Dave Jones
2012-03-07 23:48 ` Michal Nazarewicz
2012-03-07 23:48   ` Michal Nazarewicz
2012-03-08  0:02   ` Dave Jones [this message]
2012-03-08  0:02     ` Dave Jones
2012-03-08  0:08     ` Michal Nazarewicz
2012-03-08  0:08       ` Michal Nazarewicz
2012-03-07 23:50 ` Jesper Juhl
2012-03-07 23:50   ` Jesper Juhl
2012-03-07 23:53 ` David Rientjes
2012-03-07 23:53   ` David Rientjes
2012-03-08  0:04 ` Joe Perches
2012-03-08  0:04   ` Joe Perches
2012-03-08  0:18   ` Michal Nazarewicz
2012-03-08  0:18     ` Michal Nazarewicz
2012-03-08 16:24 ` Mel Gorman
2012-03-08 16:24   ` Mel Gorman

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=20120308000233.GA10695@redhat.com \
    --to=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mina86@mina86.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.