linux-kernel - Re: [PATCH v2] bitops kernel-doc: inline instead of macro

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: <alpine.LFD.0.9999.0710251840530.3186@localhost.localdomain>
Date:	Thu, 25 Oct 2007 18:42:32 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Randy Dunlap <rdunlap@...otime.net>
cc:	Nick Piggin <nickpiggin@...oo.com.au>, mingo@...hat.com,
	hpa@...or.com, lkml <linux-kernel@...r.kernel.org>,
	torvalds <torvalds@...ux-foundation.org>,
	akpm <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2] bitops kernel-doc: inline instead of macro

On Thu, 25 Oct 2007, Randy Dunlap wrote:

> On Wed, 24 Oct 2007 18:00:19 +1000 Nick Piggin wrote:
> 
> > On Wednesday 24 October 2007 15:09, Randy Dunlap wrote:
> > > From: Randy Dunlap <randy.dunlap@...cle.com>
> > >
> > > Can we expand this macro definition, or should I look for a way to
> > > fool^W teach kernel-doc about this?
> > >
> > > scripts/kernel-doc says:
> > > Error(linux-2.6.24-rc1//include/asm-x86/bitops_32.h:188): cannot understand
> > > prototype: 'test_and_set_bit_lock test_and_set_bit '
> > 
> > Actually, it probably looks a bit nicer like this anyway. If you grep
> > for it, then you can actually see the parameters...
> > 
> > On third thoughts, an inline function might be the best thing to do,
> > and also avoid setting a bad example. What do you think?
> 
> ---
> 
> From: Randy Dunlap <randy.dunlap@...cle.com>
> 
> Use duplicated inline functions for test_and_set_bit_lock() on x86
> instead of #define macros, thus avoiding a bad example.  This allows
> kernel-doc to run cleanly instead of terminating with an error:

Hmm, can we simply do

static inline int test_and_set_bit_lock(int nr, volatile unsigned long * addr)
{
	return test_and_set_bit(nr, addr);
}

please ?

       tglx
 
> Error(linux-2.6.24-rc1//include/asm-x86/bitops_32.h:188): cannot understand prototype: 'test_and_set_bit_lock test_and_set_bit '
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@...cle.com>
> ---
>  include/asm-x86/bitops_32.h |   13 +++++++++++--
>  include/asm-x86/bitops_64.h |   13 +++++++++++--
>  2 files changed, 22 insertions(+), 4 deletions(-)
> 
> --- linux-2.6.24-rc1.orig/include/asm-x86/bitops_32.h
> +++ linux-2.6.24-rc1/include/asm-x86/bitops_32.h
> @@ -183,9 +183,18 @@ static inline int test_and_set_bit(int n
>   * @nr: Bit to set
>   * @addr: Address to count from
>   *
> - * This is the same as test_and_set_bit on x86
> + * This is the same as test_and_set_bit on x86.
>   */
> -#define test_and_set_bit_lock test_and_set_bit
> +static inline int test_and_set_bit_lock(int nr, volatile unsigned long * addr)
> +{
> +	int oldbit;
> +
> +	__asm__ __volatile__( LOCK_PREFIX
> +		"btsl %2,%1\n\tsbbl %0,%0"
> +		:"=r" (oldbit),"+m" (ADDR)
> +		:"Ir" (nr) : "memory");
> +	return oldbit;
> +}
>  
>  /**
>   * __test_and_set_bit - Set a bit and return its old value
> --- linux-2.6.24-rc1.orig/include/asm-x86/bitops_64.h
> +++ linux-2.6.24-rc1/include/asm-x86/bitops_64.h
> @@ -173,9 +173,18 @@ static __inline__ int test_and_set_bit(i
>   * @nr: Bit to set
>   * @addr: Address to count from
>   *
> - * This is the same as test_and_set_bit on x86
> + * This is the same as test_and_set_bit on x86.
>   */
> -#define test_and_set_bit_lock test_and_set_bit
> +static __inline__ int test_and_set_bit_lock(int nr, volatile void * addr)
> +{
> +	int oldbit;
> +
> +	__asm__ __volatile__( LOCK_PREFIX
> +		"btsl %2,%1\n\tsbbl %0,%0"
> +		:"=r" (oldbit),ADDR
> +		:"dIr" (nr) : "memory");
> +	return oldbit;
> +}
>  
>  /**
>   * __test_and_set_bit - Set a bit and return its old value
> 
-
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/