From: Stefan Agner <stefan@agner.ch>
To: Kees Cook <keescook@chromium.org>,
Nick Desaulniers <ndesaulniers@google.com>
Cc: Jessica Yu <jeyu@kernel.org>,
Matthias Kaehlcke <mka@chromium.org>,
Rusty Russell <rusty@rustcorp.com.au>,
LKML <linux-kernel@vger.kernel.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <mmarek@suse.com>, Arnd Bergmann <arnd@arndb.de>,
Doug Anderson <dianders@chromium.org>,
Grant Grundler <grundler@chromium.org>,
Greg Hackmann <ghackmann@google.com>,
Michael Davidson <md@google.com>,
Alexander Potapenko <glider@google.com>,
Bernhard.Rosenkranzer@linaro.org, keescook@google.com
Subject: Re: module: Remove const attribute from alias for MODULE_DEVICE_TABLE
Date: Mon, 28 Aug 2017 19:24:07 -0700 [thread overview]
Message-ID: <0f65aa38c08597209d8635cc14ac36e3@agner.ch> (raw)
In-Reply-To: <CAGXu5jJMbS5ModDVhgs2kzus71B7pwkDd+GtvDZ=zjHDTmGNiQ@mail.gmail.com>
On 2017-08-28 10:41, Kees Cook wrote:
> On Mon, Aug 28, 2017 at 10:38 AM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
>> I think Kees' proposal is a better solution; rather than require all
>> usage of device table to remember to add const, have the macro add it
>> for all users. Otherwise if you require caller's to add it, they may
>> forget.
>
> And with the coccinelle script, it should be easy to invert the logic
> and remove const from the callers...
>
I tried to reproduce my findings again but was not successful :-( I must
have changed .config or something in between and draw wrong
conclusions...
So removing the const in the module.h alias actually did not change
anything... It did not help for drivers which forget to constify... I
think even the alias in module.h was actually illegal according to C
standard:
(C89, 6.2.7p2) "All declarations that refer to the same object or
function shall have compatible type; otherwise the behavior is
undefined."
I guess it would still make sense to constify the structs for most of
the 620 drivers which do not have it const currently. I found some
driver actually change the table at runtime, e.g.
drivers/net/usb/pegasus.c, so we would have to exclude them.
--
Stefan
prev parent reply other threads:[~2017-08-29 2:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 1:27 [PATCH] " Matthias Kaehlcke
2017-07-29 21:48 ` Jessica Yu
2017-08-27 23:52 ` Stefan Agner
2017-08-28 17:20 ` Kees Cook
2017-08-28 17:38 ` Nick Desaulniers
2017-08-28 17:41 ` Kees Cook
2017-08-29 2:24 ` Stefan Agner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f65aa38c08597209d8635cc14ac36e3@agner.ch \
--to=stefan@agner.ch \
--cc=Bernhard.Rosenkranzer@linaro.org \
--cc=arnd@arndb.de \
--cc=dianders@chromium.org \
--cc=ghackmann@google.com \
--cc=glider@google.com \
--cc=grundler@chromium.org \
--cc=jeyu@kernel.org \
--cc=keescook@chromium.org \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=md@google.com \
--cc=mka@chromium.org \
--cc=mmarek@suse.com \
--cc=ndesaulniers@google.com \
--cc=rusty@rustcorp.com.au \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®