linux-kernel - Re: kernel BUGs when removing largish files with the SLOB allocator

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: <20060912202826.GC19707@waste.org>
Date:	Tue, 12 Sep 2006 15:28:26 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Aubrey <aubreylee@...il.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org, davidm@...pgear.com,
	gerg@...pgear.com
Subject: Re: kernel BUGs when removing largish files with the SLOB allocator

On Tue, Sep 12, 2006 at 08:25:04PM +0100, David Howells wrote:
> Matt Mackall <mpm@...enic.com> wrote:
> 
> > Looking through all the users of kobjsize, it seems we always know
> > what the type is (and it's usually a VMA). I instead propose we use
> > ksize on objects we know to be SLAB/SLOB-allocated and add a new
> > function (kpagesize?) to size other objects where nommu needs it.
> 
> It sounds like we'd need an op in the VMA to do the per-type size thing (the
> VMA itself not the VMA ops table).

Not sure yet. There's only one user in nommu.c that shouldn't just be
changed to ksize() that I can see, and that's the one in
show_process_blocks(). That could test for VM_MAPPED_COPY and keep its
hands off otherwise. 

I can imagine situations where ->mmap returns pointers to something
that's statically allocated anyway (XIP?), where kobjsize doesn't
really make sense.

Also, looks like the WARN_ON_SLACK code has rotten, result isn't
defined in that function. Change it to base, perhaps?

-- 
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/