linux-kernel - Re: kmemcheck caught read from freed memory (cfq_free_io

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: <20080403151842.GA25193@linux.vnet.ibm.com>
Date:	Thu, 3 Apr 2008 08:18:42 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Vegard Nossum <vegard.nossum@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Jens Axboe <jens.axboe@...cle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kmemcheck caught read from freed memory (cfq_free_io_context)

On Wed, Apr 02, 2008 at 01:15:51PM -0700, Paul E. McKenney wrote:
> On Wed, Apr 02, 2008 at 10:53:53PM +0300, Pekka Enberg wrote:
> > I suppose you haven't actually run kmemcheck on your machine? We're
> > taking a page fault for _every_ memory access so a lock round-trip in
> > the SLAB_RCU case is probably not that bad performance-wise :-).
> 
> Coward that I am, no I have not.  ;-)
> 
> The thing that worries me even more than the lock is the need to keep
> track of the addresses.
> 
> Then again, if you are taking a page fault on every access, perhaps not
> such a big deal to allocate the memory and link it into a list...
> But yikes!!!  ;-)

OK, so another approach would be to use a larger shadow block for
SLAB_DESTROY_BY_RCU slabs, so that each shadow location would have enough
room for an rcu_head and a size in addition to the flag.  That would
trivialize tracking, or, more accurately, delegate such tracking to the
RCU infrastructure.

Of course, the case where the block gets reallocated before the RCU
grace period ends would also need to be handled (which my rough sketch
yesterday did -not- handle, by the way...).

There are a couple of ways of doing this.  Probably the easiest approach
is to add more state to the flag, so that the RCU callback would check
to see if reallocation had already happened.  If so, it would update the
state to indicate that the rcu_head was again available, and would need to
repost itself if the block had been freed again after being reallocated.

The other approach would be to defer actually adding the block to the
freelist until the grace period expired.  This would be more accurate,
but also quite a bit more intrusive.

Thoughts?

							Thanx, Paul
--
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/