linux-kernel - Re: [PATCH] tick: prefer a lower rating device only if it's CPU local device

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: <20180703164823.GB15335@e107155-lin>
Date:   Tue, 3 Jul 2018 17:48:23 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Kevin Hilman <khilman@...libre.com>,
        lkml <linux-kernel@...r.kernel.org>, fweisbec@...il.com,
        Arnd Bergmann <arnd@...db.de>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH] tick: prefer a lower rating device only if it's CPU
 local device

Hi Thomas,

On Tue, Jul 03, 2018 at 06:08:19PM +0200, Thomas Gleixner wrote:

[...]

> > > / # cat /sys/devices/system/clockevents/broadcast/current_device
> > > meson6_tick
> >
> > OK, it can support broadcast
> >
> > > / # cat /sys/devices/system/clockevents/clockevent0/current_device
> > > dummy_timer
> > > / # cat /sys/devices/system/clockevents/clockevent1/current_device
> > > dummy_timer
> > > / # cat /sys/devices/system/clockevents/clockevent2/current_device
> > > dummy_timer
> >
> > But I can't understand why is dummy_timer the active event source and
> > not meson6_tick. And you say this is working case ? Looks suspicious.
>
> Because if it switches to broadcast mode then the meson timer cannot longer
> be used as per cpu timer. It's broadcasting to all CPUs via the dummy timer.

Thanks for the explanation. I completely misread the sysfs entry and
assume clockevent_register failed for meson6 and hence regarded as
suspicious which is complete non-sense, my bad. Sorry for that.
I think I now understand the issue.

1. Juno usecase for which $subject was added as fix:

Two system wide timers(cpumask=possible cpus) with rating 300 and 400.
When second one with 400 is added, timer with rating 300 is added to
released list and again added back to main one. In this case both were
chosen as preferred and that resulted in deadlock.

2. Meson6 usecase:

When meson6_tick is added, it's set as preferred and dummy_timer is released.
When it's being added back from the released list, it will be chosen as
preferred as it's per_cpu resulting in deadlock.

I am not sure how to fix this. Should the fix to my original problem have
checks for both old and new for per-cpu  to prevent the issue reported on
Meson6

--
Regards,
Sudeep