linux-kernel - Re: [PATCH 2/2] regmap: Make regmap-mmio usable from different contexts

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: <20130523151420.GA6406@sirena.org.uk>
Date:	Thu, 23 May 2013 10:14:20 -0500
From:	Mark Brown <broonie@...nel.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Davide Ciminaghi <ciminaghi@...dd.com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] regmap: Make regmap-mmio usable from different
 contexts

On Thu, May 23, 2013 at 04:36:53PM +0200, Lars-Peter Clausen wrote:
> On 05/23/2013 04:31 PM, Mark Brown wrote:

> > So you'd have to allocate a struct on the stack with a pointer and the
> > flags in it and initialise the pointer.  Not awesome but not the end of
> > the world.

> I'm not sure I understand what you mean. This needs to be done for each
> caller of a lock()/unlock() pair. We can't allocate the flags on the stack
> inside the lock() function since the stack will be gone once the function exits.

Allocate the struct on the stack - if you can allocate flags on the
stack you can allocate the struct on the stack too.  Though I suppose
you still need to change all the callers for this which is just nasty
and makes it seem pointless to bother with abstraction here.

This is all stuff you should've been going through in the changelog when
you're jumping off into something that involves changing every single
user...

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)