linux-kernel - Re: decode GFP flags in oom killer output.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <op.watr0ors3l0zgt@mpn-glaptop>
Date:	Thu, 08 Mar 2012 01:08:38 +0100
From:	"Michal Nazarewicz" <mina86@...a86.com>
To:	"Dave Jones" <davej@...hat.com>
Cc:	"Linux Kernel" <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: decode GFP flags in oom killer output.

On Thu, 08 Mar 2012 01:02:33 +0100, Dave Jones <davej@...hat.com> wrote:

> On Thu, Mar 08, 2012 at 12:48:08AM +0100, Michal Nazarewicz wrote:
> > >  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.

Allocating 257 bytes on stack does not seem like a good idea especially inside of
OOM killer, where probably quite a bit of the stack was already consumed prior to
reaching this function.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +----<email/xmpp: mpn@...gle.com>--------------ooO--(_)--Ooo--
--
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/