mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Kees Cook <keescook@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>
Subject: Re: refactoring timers to avoid init_timer*()
Date: Thu, 17 Aug 2017 16:30:55 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1708171621410.2271@nanos> (raw)
In-Reply-To: <CAGXu5jKu6JWC6hw4BYGPA+qatMdd-SiaO2LiJy6XnAfjbU+1Rw@mail.gmail.com>

On Wed, 16 Aug 2017, Kees Cook wrote:
> In the process I noticed that we already have
> scripts/coccinelle/api/setup_timer.cocci to detect existing cases of:
> 
> init_timer(t);
> t->function = func;
> t->data = data;
> 
> And replace it with: setup_timer(t, func, data);
> 
> Another pattern was:
> 
> t->expires = when;
> add_timer(t);
> 
> Which can be replaced with mod_timer(t, when);
> 
> So, I've created scripts/coccinelle/api/mod_timer.cocci for the
> latter, and done a few passes with manual review. The current result
> doesn't fully eliminate init_timer() yet, but it gets much closer. I
> just wanted to be sure that this whole clean-up would actually be
> welcome before I try to nail down the last many cases.

I think it's worth the trouble, but rather than having a gazillion of
commits with the same changelog, we should do that based on a cocci script
right before the next rc1 in one go and be done with it.

That will cover most of the init_timer() cases and we can fixup the
remaining few oddballs manually after that.

I just noticed that we have the same pattern with hrtimer_init(). I had a
stab on adding hrtimer_setup() and friends which takes a function argument
and converted the bulk with coccinelle.

    82 files changed, 186 insertions(+), 210 deletions(-)

We can do that in the same sweep as the init_timer() one and then you can
do the canary magic on hrtimers as well.

Thanks,

	tglx

  reply	other threads:[~2017-08-17 14:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 23:20 Kees Cook
2017-08-17 14:30 ` Thomas Gleixner [this message]
2017-08-17 14:39   ` Kees Cook
2017-08-17 14:40 ` Christoph Hellwig
2017-08-17 15:08   ` Kees Cook

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=alpine.DEB.2.20.1708171621410.2271@nanos \
    --to=tglx@linutronix.de \
    --cc=keescook@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    /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®