* Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add [not found] ` <1623723671-5517-2-git-send-email-sidgup@codeaurora.org> @ 2021-06-15 4:54 ` Greg KH 2021-06-15 4:56 ` Greg KH 1 sibling, 0 replies; 7+ messages in thread From: Greg KH @ 2021-06-15 4:54 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add [not found] ` <1623723671-5517-2-git-send-email-sidgup@codeaurora.org> 2021-06-15 4:54 ` [PATCH v3 1/4] remoteproc: core: Move cdev add before device add Greg KH @ 2021-06-15 4:56 ` Greg KH [not found] ` <0a196786-f624-d9bb-8ef9-55c04ed57497@codeaurora.org> 1 sibling, 1 reply; 7+ messages in thread From: Greg KH @ 2021-06-15 4:56 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <0a196786-f624-d9bb-8ef9-55c04ed57497@codeaurora.org>]
* Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add [not found] ` <0a196786-f624-d9bb-8ef9-55c04ed57497@codeaurora.org> @ 2021-06-16 5:58 ` Greg KH [not found] ` <f81acd52-fe59-a296-b221-febbf8281606@codeaurora.org> 0 siblings, 1 reply; 7+ messages in thread From: Greg KH @ 2021-06-16 5:58 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <f81acd52-fe59-a296-b221-febbf8281606@codeaurora.org>]
* Re: [PATCH v3 1/4] remoteproc: core: Move cdev add before device add [not found] ` <f81acd52-fe59-a296-b221-febbf8281606@codeaurora.org> @ 2021-06-23 7:27 ` Greg KH 0 siblings, 0 replies; 7+ messages in thread From: Greg KH @ 2021-06-23 7:27 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1623723671-5517-3-git-send-email-sidgup@codeaurora.org>]
* Re: [PATCH v3 2/4] remoteproc: core: Move validate before device add [not found] ` <1623723671-5517-3-git-send-email-sidgup@codeaurora.org> @ 2021-06-15 4:54 ` Greg KH 0 siblings, 0 replies; 7+ messages in thread From: Greg KH @ 2021-06-15 4:54 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1623723671-5517-4-git-send-email-sidgup@codeaurora.org>]
* Re: [PATCH v3 3/4] remoteproc: core: Fix cdev remove and rproc del [not found] ` <1623723671-5517-4-git-send-email-sidgup@codeaurora.org> @ 2021-06-15 4:54 ` Greg KH 0 siblings, 0 replies; 7+ messages in thread From: Greg KH @ 2021-06-15 4:54 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1623723671-5517-5-git-send-email-sidgup@codeaurora.org>]
* Re: [PATCH v3 4/4] remoteproc: core: Cleanup device in case of failure [not found] ` <1623723671-5517-5-git-send-email-sidgup@codeaurora.org> @ 2021-06-15 4:54 ` Greg KH 0 siblings, 0 replies; 7+ messages in thread From: Greg KH @ 2021-06-15 4:54 UTC (permalink / raw) To: Siddharth Gupta Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-arm-msm, linux-arm-kernel, psodagud, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-06-23 7:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1623723671-5517-1-git-send-email-sidgup@codeaurora.org> [not found] ` <1623723671-5517-2-git-send-email-sidgup@codeaurora.org> 2021-06-15 4:54 ` [PATCH v3 1/4] remoteproc: core: Move cdev add before device add Greg KH 2021-06-15 4:56 ` Greg KH [not found] ` <0a196786-f624-d9bb-8ef9-55c04ed57497@codeaurora.org> 2021-06-16 5:58 ` Greg KH [not found] ` <f81acd52-fe59-a296-b221-febbf8281606@codeaurora.org> 2021-06-23 7:27 ` Greg KH [not found] ` <1623723671-5517-3-git-send-email-sidgup@codeaurora.org> 2021-06-15 4:54 ` [PATCH v3 2/4] remoteproc: core: Move validate " Greg KH [not found] ` <1623723671-5517-4-git-send-email-sidgup@codeaurora.org> 2021-06-15 4:54 ` [PATCH v3 3/4] remoteproc: core: Fix cdev remove and rproc del Greg KH [not found] ` <1623723671-5517-5-git-send-email-sidgup@codeaurora.org> 2021-06-15 4:54 ` [PATCH v3 4/4] remoteproc: core: Cleanup device in case of failure Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).