Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220407161745.7d6754b3@gandalf.local.home> <87pmlrkgi3.ffs@tglx>
 <CAHk-=whbsLXy85XpKRQmBXr=GqWbMoi+wVjFY_V22=BOE=dHog@mail.gmail.com>
 <87v8vjiaih.ffs@tglx> <20220408202230.0ea5388f@rorschach.local.home>
 <CAHk-=wg3icnjr+6aU-Wyw+kBoSRBM28P4o4iTgimOWDuuUiStQ@mail.gmail.com> <20220408204925.16361b44@rorschach.local.home>
In-Reply-To: <20220408204925.16361b44@rorschach.local.home>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 8 Apr 2022 15:00:43 -1000
Message-ID: <CAHk-=wg6ZTjCoWev039ijHkzJGOE8v1Psc=yDANkt5r3GBxc0w@mail.gmail.com>
Subject: Re: [RFC][PATCH] timers: Add del_time_free() to be called before
 freeing timers
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, jstultz@google.com,
        Stephen Boyd <sboyd@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        Eric Dumazet <edumazet@google.com>,
        Guenter Roeck <linux@roeck-us.net>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Apr 8, 2022 at 2:49 PM Steven Rostedt <rostedt@goodmis.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