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] [day] [month] [year] [list]
Date:   Fri, 16 Oct 2020 21:32:52 +0200
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list\:ARM\/Amlogic Meson..." 
        <linux-amlogic@...ts.infradead.org>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Kevin Hilman <khilman@...libre.com>,
        Da Xue <da@...re.computer>,
        Sudeep Holla <sudeep.holla@....com>,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH] mailbox: avoid timer start from callback


On Fri 16 Oct 2020 at 20:45, Jassi Brar <jassisinghbrar@...il.com> wrote:

> On Fri, Oct 16, 2020 at 1:38 PM Jerome Brunet <jbrunet@...libre.com> wrote:
>>
>>
>> On Fri 16 Oct 2020 at 19:30, jassisinghbrar@...il.com wrote:
>>
>> > From: Jassi Brar <jaswinder.singh@...aro.org>
>> >
>> > If the txdone is done by polling, it is possible for msg_submit() to start
>> > the timer while txdone_hrtimer() callback is running. If the timer needs
>> > recheduling, it could already be enqueued by the time hrtimer_forward_now()
>> > is called, leading hrtimer to loudly complain.
>> >
>> > WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 hrtimer_forward+0xc4/0x110
>> > CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted 5.9.0-rc2-00236-gd3520067d01c-dirty #5
>> > Hardware name: Libre Computer AML-S805X-AC (DT)
>> > Workqueue: events_freezable_power_ thermal_zone_device_check
>> > pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--)
>> > pc : hrtimer_forward+0xc4/0x110
>> > lr : txdone_hrtimer+0xf8/0x118
>> > [...]
>> >
>> > This can be fixed by not starting the timer from the callback path. Which
>> > requires the timer reloading as long as any message is queued on the
>> > channel, and not just when current tx is not done yet.
>> >
>> > Signed-off-by: Jassi Brar <jaswinder.singh@...aro.org>
>> > ---
>> >  drivers/mailbox/mailbox.c | 12 +++++++-----
>> >  1 file changed, 7 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
>> > index 0b821a5b2db8..a093a6ecaa66 100644
>> > --- a/drivers/mailbox/mailbox.c
>> > +++ b/drivers/mailbox/mailbox.c
>> > @@ -82,9 +82,12 @@ static void msg_submit(struct mbox_chan *chan)
>> >  exit:
>> >       spin_unlock_irqrestore(&chan->lock, flags);
>> >
>> > -     if (!err && (chan->txdone_method & TXDONE_BY_POLL))
>> > -             /* kick start the timer immediately to avoid delays */
>> > -             hrtimer_start(&chan->mbox->poll_hrt, 0, HRTIMER_MODE_REL);
>> > +     /* kick start the timer immediately to avoid delays */
>> > +     if (!err && (chan->txdone_method & TXDONE_BY_POLL)) {
>> > +             /* but only if not already active */
>>
>> It would solve the problem I reported as well but instead of running the
>> check immediately (timer with value 0), we will have to wait for the
>> next of the timer, it is already started. IOW, there might be a delay
>> now. I don't know if this important for the mailbox - the existing
>> comments in the code suggested it was.
>>
> That comment is for when the first message is queued on the channel,
> which remains unimpacted.
> So, do I have your tested/acked by ?

Sure go ahead

Acked-by: Jerome Brunet <jbrunet@...libre.com>
Tested-by: Jerome Brunet <jbrunet@...libre.com>

>
> thnx,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ