Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add

Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add

[Greg KH]

On Mon, Jun 14, 2021 at 07:21:08PM -0700, Siddharth Gupta wrote:
> When cdev_add is called after device_add has been called there is no
> way for the userspace to know about the addition of a cdev as cdev_add
> itself doesn't trigger a uevent notification, or for the kernel to
> know about the change to devt. This results in two problems:
>  - mknod is never called for the cdev and hence no cdev appears on
>    devtmpfs.
>  - sysfs links to the new cdev are not established.
> 
> The cdev needs to be added and devt assigned before device_add() is
> called in order for the relevant sysfs and devtmpfs entries to be
> created and the uevent to be properly populated.
> 
> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_core.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/4] remoteproc: core: Move validate before device add

[Greg KH]

On Mon, Jun 14, 2021 at 07:21:09PM -0700, Siddharth Gupta wrote:
> We can validate whether the remoteproc is correctly setup before
> making the cdev_add and device_add calls. This saves us the
> trouble of cleaning up later on.
> 
> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_core.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)


<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 3/4] remoteproc: core: Fix cdev remove and rproc del

[Greg KH]

On Mon, Jun 14, 2021 at 07:21:10PM -0700, Siddharth Gupta wrote:
> The rproc_char_device_remove() call currently unmaps the cdev
> region instead of simply deleting the cdev that was added as a
> part of the rproc_char_device_add() call. This change fixes that
> behaviour, and also fixes the order in which device_del() and
> cdev_del() need to be called.
> 
> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
> ---
>  drivers/remoteproc/remoteproc_cdev.c | 2 +-
>  drivers/remoteproc/remoteproc_core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 4/4] remoteproc: core: Cleanup device in case of failure

[Greg KH]

On Mon, Jun 14, 2021 at 07:21:11PM -0700, Siddharth Gupta wrote:
> When a failure occurs in rproc_add() it returns an error, but does
> not cleanup after itself. This change adds the failure path in such
> cases.
> 
> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
> ---
>  drivers/remoteproc/remoteproc_core.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add

[Greg KH]

On Mon, Jun 14, 2021 at 07:21:08PM -0700, Siddharth Gupta wrote:
> When cdev_add is called after device_add has been called there is no
> way for the userspace to know about the addition of a cdev as cdev_add
> itself doesn't trigger a uevent notification, or for the kernel to
> know about the change to devt. This results in two problems:
>  - mknod is never called for the cdev and hence no cdev appears on
>    devtmpfs.
>  - sysfs links to the new cdev are not established.
> 
> The cdev needs to be added and devt assigned before device_add() is
> called in order for the relevant sysfs and devtmpfs entries to be
> created and the uevent to be properly populated.

So this means no one ever ran this code on a system that used devtmpfs?

How was it ever tested?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add

[Greg KH]

On Tue, Jun 15, 2021 at 12:03:26PM -0700, Siddharth Gupta wrote:
> 
> On 6/14/2021 9:56 PM, Greg KH wrote:
> > On Mon, Jun 14, 2021 at 07:21:08PM -0700, Siddharth Gupta wrote:
> > > When cdev_add is called after device_add has been called there is no
> > > way for the userspace to know about the addition of a cdev as cdev_add
> > > itself doesn't trigger a uevent notification, or for the kernel to
> > > know about the change to devt. This results in two problems:
> > >   - mknod is never called for the cdev and hence no cdev appears on
> > >     devtmpfs.
> > >   - sysfs links to the new cdev are not established.
> > > 
> > > The cdev needs to be added and devt assigned before device_add() is
> > > called in order for the relevant sysfs and devtmpfs entries to be
> > > created and the uevent to be properly populated.
> > So this means no one ever ran this code on a system that used devtmpfs?
> > 
> > How was it ever tested?
> My testing was done with toybox + Android's ueventd ramdisk.
> As I mentioned in the discussion, the race became evident
> recently. I will make sure to test all such changes without
> systemd/ueventd in the future.

It isn't an issue of systemd/ueventd, those do not control /dev on a
normal system, that is what devtmpfs is for.

And devtmpfs nodes are only created if you create a struct device
somewhere with a proper major/minor, which you were not doing here, so
you must have had a static /dev on your test systems, right?

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add

[Greg KH]

On Wed, Jun 16, 2021 at 11:47:01AM -0700, Siddharth Gupta wrote:
> 
> On 6/15/2021 10:58 PM, Greg KH wrote:
> > On Tue, Jun 15, 2021 at 12:03:26PM -0700, Siddharth Gupta wrote:
> > > On 6/14/2021 9:56 PM, Greg KH wrote:
> > > > On Mon, Jun 14, 2021 at 07:21:08PM -0700, Siddharth Gupta wrote:
> > > > > When cdev_add is called after device_add has been called there is no
> > > > > way for the userspace to know about the addition of a cdev as cdev_add
> > > > > itself doesn't trigger a uevent notification, or for the kernel to
> > > > > know about the change to devt. This results in two problems:
> > > > >    - mknod is never called for the cdev and hence no cdev appears on
> > > > >      devtmpfs.
> > > > >    - sysfs links to the new cdev are not established.
> > > > > 
> > > > > The cdev needs to be added and devt assigned before device_add() is
> > > > > called in order for the relevant sysfs and devtmpfs entries to be
> > > > > created and the uevent to be properly populated.
> > > > So this means no one ever ran this code on a system that used devtmpfs?
> > > > 
> > > > How was it ever tested?
> > > My testing was done with toybox + Android's ueventd ramdisk.
> > > As I mentioned in the discussion, the race became evident
> > > recently. I will make sure to test all such changes without
> > > systemd/ueventd in the future.
> > It isn't an issue of systemd/ueventd, those do not control /dev on a
> > normal system, that is what devtmpfs is for.
> I am not fully aware of when devtmpfs is enabled or not, but in
> case it is not - systemd/ueventd will create these files with
> mknod, right?

No, systemd does not create device nodes, and neither does udev.  Hasn't
done so for well over 10 years now.

> I was even manually able to call mknod from the
> terminal when some of the remoteproc character device entries
> showed up (using major number from there, and minor number being
> the remoteproc id), and that allowed me to boot up the
> remoteprocs as well.

Yes, that is fine, but that also means that this was not working from
the very beginning :(

> > And devtmpfs nodes are only created if you create a struct device
> > somewhere with a proper major/minor, which you were not doing here, so
> > you must have had a static /dev on your test systems, right?
> I am not sure of what you mean by a static /dev? Could you
> explain? In case you mean the character device would be
> non-functional, that is not the case. They have been working
> for us since the beginning.

/dev on modern systems is managed by devtmpfs, which knows to create the
device nodes when you properly register the device with the driver core.
A "static" /dev is managed by mknod from userspace, like you did "by
hand", and that is usually only done by older systems.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel