linux-kernel - Re: [PATCH 3/3] block: convert elevator to generic rb tree code

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120529052458.GA17366@google.com>
Date:	Tue, 29 May 2012 14:24:58 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Kent Overstreet <koverstreet@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-bcache@...r.kernel.org,
	axboe@...nel.dk, paul.gortmaker@...driver.com
Subject: Re: [PATCH 3/3] block: convert elevator to generic rb tree code

Hello, Kent.

On Mon, May 28, 2012 at 11:25:02PM -0400, Kent Overstreet wrote:
> On Tue, May 29, 2012 at 08:17:17AM +0900, Tejun Heo wrote:
> > This is dangerous.  You can't put things like struct request on stack.
> > It might look like it's working ok on the tested setup but archs
> > differ in stack pressure and more importantly people may add
> > arbitrarily sized fields, including debugging stuff, to struct
> > request.  So, no, please don't do that.
> 
> I was telling you about this exact issue before - and I looked at the
> assembly to make sure that when the inlined version of rb_search() was
> used the struct request on the stack was optimized away, and it was.
> 
> So in practice there's no extra stack usage. Whether this is an
> optimization we want to depend I'm not going to say; I suspect it's
> pretty safe w.r.t. the optimizer but it's definitely sketchy and if at
> some point someone came along and switched it to the uninline version
> we'd have problems.

I don't think we can depend on that.  Note that compiler may as well
decide not to inline an inline function (e.g. if it sees many calling
instances).  Depending on such behavior is way too fragile.

> So we might want to leave this one open coded. Which would make me sad,
> but I can't think of a sane way of implementing generic rb_search() that
> doesn't require passing it a type t to compare against.

I don't know either.  Open coding isn't the end of the world but I
suspect a lot of data structures which go on rbtree wouldn't be stack
friendly, so having common helper which can't handle that might not be
too helpful.

Thanks.

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