linux-kernel - Re: [PATCH] virtio: console: Prepare for making REMOTEPROC modular

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]

Message-ID: <4c7e30d960b101fbcc9b6b8356f3bd20d26b0982.camel@kernel.org>
Date: Tue, 18 Feb 2025 10:49:47 +0100
From: Amit Shah <amit@...nel.org>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman
	 <gregkh@...uxfoundation.org>, virtualization@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] virtio: console: Prepare for making REMOTEPROC modular

On Mon, 2025-02-17 at 11:59 +0100, Amit Shah wrote:
> On Mon, 2025-02-17 at 11:53 +0100, Amit Shah wrote:
> > On Fri, 2025-02-14 at 18:47 +0100, Uwe Kleine-König wrote:
> > > On Fri, Feb 14, 2025 at 05:55:41PM +0100, Amit Shah wrote:
> > > > On Fri, 2025-02-14 at 17:52 +0100, Uwe Kleine-König wrote:
> > > > > Hello Amit,
> > > > > 
> > > > > On Fri, Feb 14, 2025 at 05:37:52PM +0100, Amit Shah wrote:
> > > > > > I'm thinking of the two combinations of interest:
> > > > > > REMOTEPROC=m,
> > > > > > VIRTIO_CONSOLE can be y or m.  Say virtcons_probe() happens
> > > > > > when
> > > > > > the
> > > > > > remoteproc module isn't yet loaded.  Even after later
> > > > > > loading
> > > > > > remoteproc, virtio console won't do anything interesting
> > > > > > with
> > > > > > remoteproc.
> > > > > 
> > > > > Where does the interesting thing happen if remoteproc is
> > > > > already
> > > > > loaded
> > > > > at that time? I'm not seeing anything interesting in that
> > > > > case
> > > > > either
> > > > > ...
> > > > 
> > > > The code I pointed to,
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/virtio_console.c#n1993
> > > > 
> > > > either enables remoteproc if the module is present; or it
> > > > enables
> > > > multiport, but not both at the same time.  If remoteproc isn't
> > > > present
> > > > when this probe routine is executed, multiport might get
> > > > enabled. 
> > > > And
> > > > then there's no chance for remoteproc to get enabled.
> > > 
> > > The only case where there is a difference between IS_REACHABLE
> > > and
> > > IS_ENABLED is:
> > > 
> > > 	CONFIG_REMOTEPROC=m
> > > 	CONFIG_VIRTIO_CONSOLE=y
> > 
> > Well, also if CONFIG_VIRTIO_CONSOLE=m; and virtio_console.ko is
> > loaded
> > before remoteproc.ko.
> > 
> > > Iff in this case you never want to test for MULTIPORT (even
> > > though
> > > the
> > > remoteproc module might never get loaded), then my patch is
> > > wrong.
> > > 
> > > When creating the patch I thought there is a hard dependency on
> > > remoteproc (like calling a function that is provided by
> > > CONFIG_REMOTEPROC). I don't understand how the remoteproc stuff
> > > interacts with the virtio_console driver, is this something in
> > > userspace
> > > which then would also autoload the remoteproc module?
> > 
> > What's happening is that multiport and remoteproc are mutually
> > exclusive in the virtio_console code.
> > 
> > And, I'm also not sure of how remoteproc loads and configures
> > itself.
> > Does loading remoteproc cause a load of virtio_console?  How?
> > 
> > So - based on our discussions, I think your assumptions are:
> > 
> > 1. remoteproc will load virtio_console when remoteproc is required
> > 2. virtio_console will never be loaded by itself
> > 3. General virtio_console functionality (including tty and
> > multiport)
> > is never used when remoteproc is used
> > 
> > I think at least 3 needs more thought/justification why it's a
> > valid
> > assumption.  Documenting it in the commit msg is fine.
> > 
> > At least assumptions 1 and 2 will cause remoteproc to not function
> > correctly with virtio_console, despite both of them being loaded
> > (because they can be loaded in the unexpected order --
> > virtio_console
> > before remoteproc).  Do you want to adjust the code so that
> > remoteproc
> > queries for already-existing virtio_console.ko, triggers the code
> > that
> > would otherwise be not triggered in virtcons_probe(), and makes
> > remoteproc functional in that case?
> 
> ... I just saw that virtcons_probe() doesn't have any setup in case
> of
> rproc.  So this last paragraph doesn't apply.

... I knew I was missing something yesterday. There's the call to
add_port() from virtcons_probe() that sets up the port for remoteproc.
So that part will be entirely skipped in case the virtcons probe
happens before remoteproc is loaded.

There's much too confusion here, better to start anew.

> So maybe just adding some notes in the commit log about why this will
> end up working, and why rproc usage and tty+multiport usage are
> mutually exclusive (and fine) will help.
> 
> Thanks,
> 
> 		Amit