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]
Date: Thu, 15 Feb 2024 19:41:52 +0100
From: Michal Hocko <mhocko@...e.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
	vbabka@...e.cz, hannes@...xchg.org, roman.gushchin@...ux.dev,
	mgorman@...e.de, dave@...olabs.net, willy@...radead.org,
	liam.howlett@...cle.com, corbet@....net, void@...ifault.com,
	peterz@...radead.org, juri.lelli@...hat.com,
	catalin.marinas@....com, will@...nel.org, arnd@...db.de,
	tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
	x86@...nel.org, peterx@...hat.com, david@...hat.com,
	axboe@...nel.dk, mcgrof@...nel.org, masahiroy@...nel.org,
	nathan@...nel.org, dennis@...nel.org, tj@...nel.org,
	muchun.song@...ux.dev, rppt@...nel.org, paulmck@...nel.org,
	pasha.tatashin@...een.com, yosryahmed@...gle.com, yuzhao@...gle.com,
	dhowells@...hat.com, hughd@...gle.com, andreyknvl@...il.com,
	keescook@...omium.org, ndesaulniers@...gle.com, vvvvvv@...gle.com,
	gregkh@...uxfoundation.org, ebiggers@...gle.com, ytcoode@...il.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, bristot@...hat.com,
	vschneid@...hat.com, cl@...ux.com, penberg@...nel.org,
	iamjoonsoo.kim@....com, 42.hyeyoo@...il.com, glider@...gle.com,
	elver@...gle.com, dvyukov@...gle.com, shakeelb@...gle.com,
	songmuchun@...edance.com, jbaron@...mai.com, rientjes@...gle.com,
	minchan@...gle.com, kaleshsingh@...gle.com, kernel-team@...roid.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux.dev, linux-arch@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-modules@...r.kernel.org, kasan-dev@...glegroups.com,
	cgroups@...r.kernel.org
Subject: Re: [PATCH v3 31/35] lib: add memory allocations report in show_mem()

On Thu 15-02-24 13:29:40, Kent Overstreet wrote:
> On Thu, Feb 15, 2024 at 08:47:59AM -0800, Suren Baghdasaryan wrote:
> > On Thu, Feb 15, 2024 at 8:45 AM Michal Hocko <mhocko@...e.com> wrote:
> > >
> > > On Thu 15-02-24 06:58:42, Suren Baghdasaryan wrote:
> > > > On Thu, Feb 15, 2024 at 1:22 AM Michal Hocko <mhocko@...e.com> wrote:
> > > > >
> > > > > On Mon 12-02-24 13:39:17, Suren Baghdasaryan wrote:
> > > > > [...]
> > > > > > @@ -423,4 +424,18 @@ void __show_mem(unsigned int filter, nodemask_t *nodemask, int max_zone_idx)
> > > > > >  #ifdef CONFIG_MEMORY_FAILURE
> > > > > >       printk("%lu pages hwpoisoned\n", atomic_long_read(&num_poisoned_pages));
> > > > > >  #endif
> > > > > > +#ifdef CONFIG_MEM_ALLOC_PROFILING
> > > > > > +     {
> > > > > > +             struct seq_buf s;
> > > > > > +             char *buf = kmalloc(4096, GFP_ATOMIC);
> > > > > > +
> > > > > > +             if (buf) {
> > > > > > +                     printk("Memory allocations:\n");
> > > > > > +                     seq_buf_init(&s, buf, 4096);
> > > > > > +                     alloc_tags_show_mem_report(&s);
> > > > > > +                     printk("%s", buf);
> > > > > > +                     kfree(buf);
> > > > > > +             }
> > > > > > +     }
> > > > > > +#endif
> > > > >
> > > > > I am pretty sure I have already objected to this. Memory allocations in
> > > > > the oom path are simply no go unless there is absolutely no other way
> > > > > around that. In this case the buffer could be preallocated.
> > > >
> > > > Good point. We will change this to a smaller buffer allocated on the
> > > > stack and will print records one-by-one. Thanks!
> > >
> > > __show_mem could be called with a very deep call chains. A single
> > > pre-allocated buffer should just do ok.
> > 
> > Ack. Will do.
> 
> No, we're not going to permanently burn 4k here.
> 
> It's completely fine if the allocation fails, there's nothing "unsafe"
> about doing a GFP_ATOMIC allocation here.

Nobody is talking about safety. This is just a wrong thing to do when
you are likely under OOM situation. This is a situation when you
GFP_ATOMIC allocation is _likely_ to fail. Yes, yes you will get some
additional memory reservers head room, but you shouldn't rely on that
because that will make the output unreliable. Not something you want in
situation when you really want to know that information.

More over you do not need to preallocate a full page.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ