linux-kernel - Re: [RFC PATCH] remoteproc: core: Add support for predefined notifyids

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: <CAEnQRZDoYvK-YXLjqbXsRAWDkHrWNOoR1OCCWxs+AfNUDuPB_w@mail.gmail.com>
Date: Wed, 30 Oct 2024 16:04:00 +0200
From: Daniel Baluta <daniel.baluta@...il.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Daniel Baluta <daniel.baluta@....com>, andersson@...nel.org, 
	linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	imx@...ts.linux.dev, iuliana.prodan@....com, peng.fan@....com, 
	Alexandru Lastur <alexandru.lastur@....com>, arnaud.pouliquen@...s.st.com
Subject: Re: [RFC PATCH] remoteproc: core: Add support for predefined notifyids

On Wed, Oct 23, 2024 at 6:32 PM Mathieu Poirier
<mathieu.poirier@...aro.org> wrote:
>
> Hello Daniel,
>
> On Fri, Oct 18, 2024 at 02:09:29PM +0300, Daniel Baluta wrote:
> > Currently we generate notifyids in the linux kernel and override
> > those found in rsc_table.
> >
> > This doesn't play well with users expecting to use the exact ids
> > from rsc_table.
> >
> > So, use predefined notifyids found in rsc_table if any. Otherwise,
> > let Linux generate the ids as before.
> >
> > Keypoint is we also define an invalid notifid as 0xFFFFFFFFU. This
> > should be placed as notifids if users want Linux to generate the ids.
> >
> > Signed-off-by: Alexandru Lastur <alexandru.lastur@....com>
> > Signed-off-by: Daniel Baluta <daniel.baluta@....com>
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 14 ++++++++++++--
> >  include/linux/remoteproc.h           |  1 +
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index f276956f2c5c..9f00fe16da38 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -332,6 +332,7 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> >       int ret, notifyid;
> >       struct rproc_mem_entry *mem;
> >       size_t size;
> > +     int start, end;
> >
> >       /* actual size of vring (in bytes) */
> >       size = PAGE_ALIGN(vring_size(rvring->num, rvring->align));
> > @@ -363,9 +364,18 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> >       /*
> >        * Assign an rproc-wide unique index for this vring
> >        * TODO: assign a notifyid for rvdev updates as well
> > -      * TODO: support predefined notifyids (via resource table)
> >        */
> > -     ret = idr_alloc(&rproc->notifyids, rvring, 0, 0, GFP_KERNEL);
> > +
> > +     start = 0;
> > +     end = 0;
> > +
> > +     /* use id if specified in rsc table */
> > +     if (rsc->vring[i].notifyid != RSC_INVALID_NOTIFYID) {
> > +             start = rsc->vring[i].notifyid;
> > +             end = start + 1;
> > +     }
>
> This will likely introduce a backward compatibility issue where anyone that
> has more than one vring and set their notifyids to anything else than 0xFFFFFFFF
> in the resource table will see a boot failure.
>
> A while back the openAMP group started discussions on using the configuration
> space of a virtio device to enhance device discovery, with exactly this kind of
> use case in mind.  I think it is the only way to move forward with this
> feature, though it is a big job that requires a lot of community interactions.

I also found this attempt few years ago:

https://lkml.iu.edu/hypermail/linux/kernel/2001.2/05248.html

I think the best way to go is to bump the resource table version and support
the old behavior for v1 and the new behavior for the new version
(which should be v2).

We will be back next week with a patch to express this.

thanks,
Daniel.