linux-kernel - Re: [PATCH 2/2] Replace the dangerous to_root

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: <87zkrd3gkz.fsf@tac.ki.iif.hu>
Date:	Thu, 06 Jan 2011 21:47:08 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Replace the dangerous to_root_device macro with an inline function

Greg KH <gregkh@...e.de> writes:

> On Thu, Jan 06, 2011 at 04:24:24PM +0100, Ferenc Wagner wrote:
>
>> The original macro worked only when applied to variables named 'dev'.
>> While this could have been fixed by simply renaming the macro argument,
>> a more type-safe replacement is preferred.
>
> Preferred for what?  This is a local macro, not exported to anything
> else, is it causing problems today within this single file?

No, it isn't a problem currently, because this macro is applied to
variables named 'dev' exclusively.  But the macro definition is wrong,
as it uses 'dev' (the macro argument) in two places, of which the second
probably isn't intentional, as the third argument of the container_of
macro is a structure member name, which should stay fixed to the literal
string 'dev' in this case, not replaced by the actual macro argument.

So you've got the choice of leaving things as they are and happen to
work for the moment, fixing the definition of the to_root_device macro
to use some other token as the name of the free variable instead of
'dev', or to replace the macro with a function, which provides some
type-checking advantages during compilation as well.  I thought this was
a general reason for preferring inline functions over preprocessor
macros in the kernel codebase, but maybe I was wrong.
-- 
Regards,
Feri.
--
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/