linux-kernel - Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and writes

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]

Date:   Mon, 21 Feb 2022 19:29:44 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sai Prakash Ranjan <quic_saipraka@...cinc.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Elliot Berman <quic_eberman@...cinc.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Shanker Donthineni <shankerd@...eaurora.org>,
        Adam Wallis <awallis@...eaurora.org>,
        Timur Tabi <timur@...eaurora.org>,
        Elliot Berman <eberman@...eaurora.org>
Subject: Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and
 writes

On Tue, Feb 15, 2022 at 09:33:23AM +0530, Sai Prakash Ranjan wrote:
> Hi Mark,
> 
> On 2/14/2022 8:46 PM, Mark Rutland wrote:
> > Hi,
> > 
> > On Thu, Feb 10, 2022 at 07:26:32PM +0530, Sai Prakash Ranjan wrote:
> > > From: Shanker Donthineni <shankerd@...eaurora.org>
> > > 
> > > Some debuggers, such as Trace32 from Lauterbach GmbH, do not handle
> > > reads/writes from/to DCC on secondary cores. Each core has its
> > > own DCC device registers, so when a core reads or writes from/to DCC,
> > > it only accesses its own DCC device. Since kernel code can run on
> > > any core, every time the kernel wants to write to the console, it
> > > might write to a different DCC.
> > > 
> > > In SMP mode, Trace32 creates multiple windows, and each window shows
> > > the DCC output only from that core's DCC. The result is that console
> > > output is either lost or scattered across windows.
> > This has been the Linux behaviour since the dawn of time, so why is this not
> > considered to be a bug in the tools? Why can't Lauterbach add an option to
> > treat the cores as one?
> 
> More like a feature request than a bug? And why would tools add such a
> feature when
> it is the kernel which runs in SMP mode? Shouldn't kernel be the one having
> such a feature
> because there would be number of such tools with the same issue and we can't
> send a feature
> request to all those tool vendors to add this feature right. Instead adding
> this in the kernel would
> avoid all these centrally at one place.

Please fix this in userspace.

> > Importantly, with hotplug we *cannot* guarantee that all messages will go to
> > the same CPU anyway, since that could be offlined (even if it is CPU 0), so in
> > general we cann't provide a guarantee here.
> 
> Right that is true, in case of CPU hotplug this would be pretty much broken
> if CPU0 is offlined.
> We use these during initial bringup stage of SoCs when we don't have debug
> UART console up and running
> and at the time we don't much care for testing out hotplugging the CPUs and
> let alone trying out
> to offline CPU0 which we use and shoot our own foot :)
> 
> Given this is mostly a debug feature, we don't mind if this doesn't
> guarantee to work in hotplug scenario.

We do not get to choose this type of thing.  Either it will work
properly, or not.  Offlineing cpu 0 happens with power management
situations, right?  Especially with big/little systems, if CPU0 was a
big one, you would remove it while only the little ones were running.

I still feel this should all be handled in userspace.

Especially given the problems that this patch is having with being
tested properly :(

thanks,

greg k-h