linux-kernel - outb(2) Text regarding optimizations

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

Message-ID: <3db43b50-a0a5-ed0e-4def-e44f845f8e89@gmail.com>
Date:   Wed, 6 Oct 2021 21:14:48 +0200
From:   "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
To:     linux-man <linux-man@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Libc-alpha <libc-alpha@...rceware.org>
Subject: outb(2) Text regarding optimizations

Hi,

outb(2) says that users of these functions should optimize to avoid 
having unresolved references at link time.

The text is:

[
        They  are  primarily  designed for internal kernel use, but
        can be used from user space.

        You must compile with -O or -O2 or similar.  The  functions
        are  defined  as inline macros, and will not be substituted
        in without optimization enabled, causing unresolved  refer‐
        ences at link time.
]

First of all, "inline macros" already is a misnomer.  They are 'static 
inline' functions.  But 'static inline' functions _never_ cause 
unresolved references, because they are 'static', so the function code 
is added to each translation unit as an anonymous function (which is a 
big problem of static inline: it may bloat code by repeating code in 
translation units, C99 inline being preferable).

So is this an incorrect advice (maybe because of a veeery old 
implementation)?  (I couldn't find any relevant implementation changes 
in the glibc git history.)

If there is any reason I'm missing (I don't understand the assembly 
calls that these functions call, so maybe) that would cause these 
functions to actually require optimization, I'd say it's a bug, and a 
better solution would be to add the attribute 
__attribute__((__always_inline__)) to the functions, so that they will 
_always_ be inlined, no matter what optimization level the user chooses. 
  Right?

Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/