* Re: [PATCH v4 2/4] remoteproc: core: Move validate before device add
[not found] ` <1623783824-13395-3-git-send-email-sidgup@codeaurora.org>
@ 2021-06-15 19:06 ` Greg KH
0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2021-06-15 19:06 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:42PM -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>
> Cc: stable@vger.kernel.org
> ---
> drivers/remoteproc/remoteproc_core.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Why is this relevant for stable? What commit does this fix? Please put
a Fixes: tag for that.
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] 4+ messages in thread
* Re: [PATCH v4 4/4] remoteproc: core: Cleanup device in case of failure
[not found] ` <1623783824-13395-5-git-send-email-sidgup@codeaurora.org>
@ 2021-06-15 19:06 ` Greg KH
[not found] ` <75ce2563-3d34-a578-200d-8ec5f259d405@codeaurora.org>
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2021-06-15 19:06 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:44PM -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>
> Cc: stable@vger.kernel.org
> ---
> drivers/remoteproc/remoteproc_core.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
Why is this needed for stable kernels? And again, a Fixes: tag?
_______________________________________________
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] 4+ messages in thread
* Re: [PATCH v4 3/4] remoteproc: core: Fix cdev remove and rproc del
[not found] ` <1623783824-13395-4-git-send-email-sidgup@codeaurora.org>
@ 2021-06-15 19:06 ` Greg KH
0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2021-06-15 19:06 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:43PM -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>
> Cc: stable@vger.kernel.org
Is this really needed for stable? What bug does this solve? ANd again,
fixes: ?
_______________________________________________
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] 4+ messages in thread
* Re: [PATCH v4 4/4] remoteproc: core: Cleanup device in case of failure
[not found] ` <75ce2563-3d34-a578-200d-8ec5f259d405@codeaurora.org>
@ 2021-06-16 5:56 ` Greg KH
0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2021-06-16 5:56 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 01:21:11PM -0700, Siddharth Gupta wrote:
>
> On 6/15/2021 12:06 PM, Greg KH wrote:
> > On Tue, Jun 15, 2021 at 12:03:44PM -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>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > drivers/remoteproc/remoteproc_core.c | 15 ++++++++++++---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > Why is this needed for stable kernels? And again, a Fixes: tag?
> Patch 2 and patch 3 are leading up to fix rproc_add()
> in case of a failure. This means we'll have errors with
> use after free unless we call device_del() or cdev_del(),
> also the sysfs and devtempfs nodes will also not be
> removed.
Then please explain that better in the changelogs. At it is, no one
knows this.
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] 4+ messages in thread
end of thread, other threads:[~2021-06-16 5:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1623783824-13395-1-git-send-email-sidgup@codeaurora.org>
[not found] ` <1623783824-13395-3-git-send-email-sidgup@codeaurora.org>
2021-06-15 19:06 ` [PATCH v4 2/4] remoteproc: core: Move validate before device add Greg KH
[not found] ` <1623783824-13395-5-git-send-email-sidgup@codeaurora.org>
2021-06-15 19:06 ` [PATCH v4 4/4] remoteproc: core: Cleanup device in case of failure Greg KH
[not found] ` <75ce2563-3d34-a578-200d-8ec5f259d405@codeaurora.org>
2021-06-16 5:56 ` Greg KH
[not found] ` <1623783824-13395-4-git-send-email-sidgup@codeaurora.org>
2021-06-15 19:06 ` [PATCH v4 3/4] remoteproc: core: Fix cdev remove and rproc del 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).