linux-kernel - Re: [RFC][PATCH] timers: Add del_time_free() to be called before freeing timers

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: <CAHk-=wg6ZTjCoWev039ijHkzJGOE8v1Psc=yDANkt5r3GBxc0w@mail.gmail.com>
Date:   Fri, 8 Apr 2022 15:00:43 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, jstultz@...gle.com,
        Stephen Boyd <sboyd@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [RFC][PATCH] timers: Add del_time_free() to be called before
 freeing timers

On Fri, Apr 8, 2022 at 2:49 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Hmm, well, I'm not sure it would work for all architectures, but what
> about the MSB?  Setting it to zero on "shutdown"?

Let's just clear the whole thing for now. We don't actually _have_ any
timer_restart() cases yet.

I was more thinking that we might have situations where "I don't want
to race with timers, but I also don't want to take an interrupt-safe
lock" makes a lot of sense.

Most people most definitely are just about "module unload" and similar
issues, where it goes along with doing "task_work_cancel()" and
friends.

I do wonder if we want some way to shut down new timers that doesn't
actually wait for old ones to finish.

We've had issues with some code not being able to use del_timer_sync()
simply because they hold locks that could deadlock with any "wait for
running timer" situation.

Those places couldn't use a synchronous cancel operation either, for
the same reason.

I'm not sure a "make sure no future timers can start" operation is
sensible on its own, though. I can't think of a situation where that
wouldn't also need that "wait for existing ones to finish".

                       Linus