| Message ID | 1496403321-32234-1-git-send-email-henri.roosen@ginzinger.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Hi Henri, On 06/02/2017 06:35 AM, Henri Roosen wrote: > A device might not have an ops structure registered. This The rpmsg devices are registered from the respective backends, which are supposed to plug in their ops. What is the scenario where you think these ops might not be populated? We ought to check for NULL ops in rpmsg_register_device in fact to make sure an ops pointer is supplied. regards Suman > patch fixes a null-prt dereference by checking ops before dereferencing > it. > > Signed-off-by: Henri Roosen <henri.roosen@ginzinger.com> > --- > drivers/rpmsg/rpmsg_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c > index 600f5f9..0c48452 100644 > --- a/drivers/rpmsg/rpmsg_core.c > +++ b/drivers/rpmsg/rpmsg_core.c > @@ -429,7 +429,7 @@ static int rpmsg_dev_probe(struct device *dev) > goto out; > } > > - if (rpdev->ops->announce_create) > + if (rpdev->ops && rpdev->ops->announce_create) > err = rpdev->ops->announce_create(rpdev); > out: > return err; > -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 02 Jun 04:35 PDT 2017, Henri Roosen wrote: > A device might not have an ops structure registered. This > patch fixes a null-prt dereference by checking ops before dereferencing > it. > In what scenario do you end up with a rpdev without ops defined? You need at least create_ept defined in your ops to be able to do any form of communication. So it would probably make more sense to add a sanity check in rpmsg_register_device(), but perhaps I'm missing something. (If this is not true there are a bunch of other places where this needs to be checked as well) Regards, Bjorn > Signed-off-by: Henri Roosen <henri.roosen@ginzinger.com> > --- > drivers/rpmsg/rpmsg_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c > index 600f5f9..0c48452 100644 > --- a/drivers/rpmsg/rpmsg_core.c > +++ b/drivers/rpmsg/rpmsg_core.c > @@ -429,7 +429,7 @@ static int rpmsg_dev_probe(struct device *dev) > goto out; > } > > - if (rpdev->ops->announce_create) > + if (rpdev->ops && rpdev->ops->announce_create) > err = rpdev->ops->announce_create(rpdev); > out: > return err; > -- > 2.1.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2017 11:51 PM, Bjorn Andersson wrote: > On Fri 02 Jun 04:35 PDT 2017, Henri Roosen wrote: > >> A device might not have an ops structure registered. This >> patch fixes a null-prt dereference by checking ops before dereferencing >> it. >> > > In what scenario do you end up with a rpdev without ops defined? > > You need at least create_ept defined in your ops to be able to do any > form of communication. So it would probably make more sense to add a > sanity check in rpmsg_register_device(), but perhaps I'm missing > something. I was trying to add support for the generic rpmsg-char driver for virtio_rpmsg_bus. The rpmsg-char driver gets registered using rpmsg_chrdev_register_device(), and IMHO this device should not have any .ops. The chrdev is not used for communication, only for creating devices. The devices which should have the .ops are the ones created using the rpmsg-char device. So actually having .ops for the device passed to rpmsg_chrdev_register_device() in drivers/rpmsg/qcom_smd.c seems wrong to me too and should be cleaned up. > > > (If this is not true there are a bunch of other places where this needs > to be checked as well) If you agree to my opinion above, then I think this comes down to a design decision: a possibility might be to split off the chrdev code to a different implementation as the code for the communication devices. Else we need to identify the other places for the check. Best regards, Henri > > Regards, > Bjorn > >> Signed-off-by: Henri Roosen <henri.roosen@ginzinger.com> >> --- >> drivers/rpmsg/rpmsg_core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c >> index 600f5f9..0c48452 100644 >> --- a/drivers/rpmsg/rpmsg_core.c >> +++ b/drivers/rpmsg/rpmsg_core.c >> @@ -429,7 +429,7 @@ static int rpmsg_dev_probe(struct device *dev) >> goto out; >> } >> >> - if (rpdev->ops->announce_create) >> + if (rpdev->ops && rpdev->ops->announce_create) >> err = rpdev->ops->announce_create(rpdev); >> out: >> return err; >> -- >> 2.1.4 >> -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 26 Jun 02:04 PDT 2017, Henri Roosen wrote: > On 06/25/2017 11:51 PM, Bjorn Andersson wrote: > > On Fri 02 Jun 04:35 PDT 2017, Henri Roosen wrote: > > > > > A device might not have an ops structure registered. This > > > patch fixes a null-prt dereference by checking ops before dereferencing > > > it. > > > > > > > In what scenario do you end up with a rpdev without ops defined? > > > > You need at least create_ept defined in your ops to be able to do any > > form of communication. So it would probably make more sense to add a > > sanity check in rpmsg_register_device(), but perhaps I'm missing > > something. > > I was trying to add support for the generic rpmsg-char driver for > virtio_rpmsg_bus. > > The rpmsg-char driver gets registered using rpmsg_chrdev_register_device(), > and IMHO this device should not have any > .ops. The chrdev is not used for communication, only for creating devices. > The devices which should have the .ops are the ones created using the > rpmsg-char device. > In order to create/open new channels from user space you need to call rpmsg_create_ept() and this require a rpmsg_device context in order for the communication to be associated with the appropriate link. So we must set up the rpmsg_device context with the ops table including create_ept() in order to maintain the reference back to the particular virtio device (or SMD channel). The main difference from previous implementations of this is that the rpmsg_device does not have a primary endpoint. This removes the need for the firmware to create a special channel to instantiate the user space communication, but comes at the cost of the special spawning from the individual backend drivers. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c index 600f5f9..0c48452 100644 --- a/drivers/rpmsg/rpmsg_core.c +++ b/drivers/rpmsg/rpmsg_core.c @@ -429,7 +429,7 @@ static int rpmsg_dev_probe(struct device *dev) goto out; } - if (rpdev->ops->announce_create) + if (rpdev->ops && rpdev->ops->announce_create) err = rpdev->ops->announce_create(rpdev); out: return err;
A device might not have an ops structure registered. This patch fixes a null-prt dereference by checking ops before dereferencing it. Signed-off-by: Henri Roosen <henri.roosen@ginzinger.com> --- drivers/rpmsg/rpmsg_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)