linux-kernel - Re: [bug] SLOB, tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic

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] [day] [month] [year] [list]

Date:	Fri, 30 Nov 2007 16:35:37 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Allan Stephens <allan.stephens@...driver.com>,
	Jon Paul Maloy <jon.maloy@...csson.com>,
	Christoph Lameter <clameter@....com>
Subject: Re: [bug] SLOB, tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot()

On Fri, Nov 30, 2007 at 10:14:18AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <mpm@...enic.com> wrote:
> 
> > > plus, and this is a slob question i guess, how come we drop into 
> > > clear_highpage() for a kzalloc()??
> > 
> > Good question. Looks like kzalloc switched from doing a memset to
> > passing a GFP_ZERO flag down to kmalloc. Slob didn't get completely
> > updated to reflect this, so it blindly propagates the flag onto
> > __alloc_pages and does a harmless double-clear.
> > 
> > Someone should remind us what the point of moving the kzalloc memset
> > down into the allocators was. We now have all three allocators doing:
> > 
> >         if (unlikely((flags & __GFP_ZERO) && ptr))
> >                 memset(ptr, 0, obj_size(cachep));
> > 
> > and needing to mask flags before passing them to page allocators,
> > which hardly seems better than kzalloc unconditionally doing the
> > memset. Wouldn't it be better/faster/smaller to make kzalloc a
> > non-inline?
> > 
> > Slob also has a nice second path for large kmallocs where it just 
> > calls the page allocator directly which also needs this treatment. 
> > Which does the right thing with non-highmem systems, but can hit this 
> > bug otherwise.
> > 
> > Below is a totally untested patch. Alternately, we could simply tweak 
> > clear_highpage to remove the limitation, but that would leave slob 
> > doing an extra clear.
> 
> ok, this fixes the debug warning.
> 

But the question remains: is this the right fix? The commit in
question is here:

http://www.kernel.org/hg/linux-2.6/rev/13683609d67a

Christoph, remind us what's the upside here? It seems to me it would
be better to have separate non-inline kzalloc and kcalloc functions
that did the memset instead.

Another smaller open question is whether we want to remove the
in_interrupt restriction from clear_pagehigh.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/