linux-kernel - Re: [PATCH] headers_install.pl: autoconvert asm/inline/volatile to __xxx_

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] [day] [month] [year] [list]

Message-Id: <200901030338.34968.arnd@arndb.de>
Date:	Sat, 3 Jan 2009 03:38:34 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] headers_install.pl: autoconvert asm/inline/volatile to __xxx__

On Saturday 03 January 2009, Mike Frysinger wrote:
> how would you propose maintaining said list ?  attempting to maintain external 
> to the file in question will just lead to rot (since we dont want to whitelist 
> entire files, and we cant track line numbers, and we cant detect where the 
> keyword is being used in terms of macro/function) ... that leaves two choices 
> that i can think of:
>  - a new __asm_userok__ type marker
>  - adding a simple /* userok */ comment we can filter in the perl regex
> 
> neither of which sounds entire pleasant either ...

It all depends on how many exceptions there are. The number of instances
of asm and volatile keywords is really small (one file each, on x86), so
we can easily decide whether or not they should all be allowed or disallowed.

For inline, we already have a precedent in include/linux/socket.h,
which contains

/*
 *	This mess will go away with glibc
 */
#if    defined(__GNUC__)
#define __KINLINE static __inline__
#elif defined(__cplusplus) /* || __STDC_VERSION__ >= 199901L  --arnd */
#define __KINLINE static inline
#else
#define __KINLINE static
#endif

This demonstrates that there are additional problems to consider. In order
to do the right thing, we could first use your patch to fix up all instances
of inline, and then warn about any __inline__ and inline, converting the
legitimate ones to __KINLINE.

Again, there are very few legitimate ones, unless you count the byteorder
headers as correct, which I'm still undecided about.

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