[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874izm2v02.ffs@tglx>
Date: Fri, 21 Mar 2025 17:45:01 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: cuiguoqi <cuiguoqi@...inos.cn>, anna-maria@...utronix.de
Cc: frederic@...nel.org, linux-kernel@...r.kernel.org,
bigeasy@...utronix.de, clrkwllms@...nel.org, rostedt@...dmis.org,
linux-rt-devel@...ts.linux.dev, cuiguoqi <cuiguoqi@...inos.cn>
Subject: Re: [PATCH] hrtimer: Fix the incorrect initialization of
timer->is_hard
On Fri, Mar 21 2025 at 10:03, cuiguoqi@...inos.cn wrote:
I have no idea why you think that sending this patch to
sales@...utronix.de makes any sense.
It's equally useful as me cc'ing sales@...inos.cn on my reply.
> When PREEMPT_RT is disabled,there is a possibility that
> timer->is_hard will be incorrectly initialized.
> When creating a high-resolution timer and setting the mode to
> HRTIMER_MODE_ABS,the timer->is_hard will be incorrectly initialized.
What is the consequence, i.e. malfunction, of this being incorrectly
initialized?
Nothing as far as I can tell.
So what's incorrect? It's slightly inconsistent and confusing, but not
incorrect in the way that it causes malfunction, right?
If so, then please say so. If it causes malfunction, then describe it.
> timer->is_soft = softtimer;
> - timer->is_hard = !!(mode & HRTIMER_MODE_HARD);
> + timer->is_hard = !softtimer;
Now timer->is_soft is always !timer->is_hard, right?
Which means that one of those flags is superfluous, no?
Thanks,
tglx
Powered by blists - more mailing lists