DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Harman Kalra <hkalra@marvell.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"marko.kallio@cavium.com" <marko.kallio@cavium.com>,
	Kallio Marko <marko.kallio@cavium.comm>
Subject: Re: [dpdk-dev] [PATCH] raw/skeleton: fix segmentation fault on rawdev_autotest
Date: Thu, 13 Dec 2018 07:22:56 +0000	[thread overview]
Message-ID: <6143dcfc-83b3-762a-b912-54acaa970470@nxp.com> (raw)
In-Reply-To: <20181211131412.14232-1-hkalra@marvell.com>

On Tuesday 11 December 2018 06:44 PM, Harman Kalra wrote:
> segmentation fault ocured as vdev->device.driver->name did not
> return correct value.
> Test2 failed as dummy_value was freed before it was used.
> 
> Signed-off-by: Kallio Marko <marko.kallio@cavium.comm>
> Signed-off-by: Harman Kalra <hkalra@marvell.com>
> ---
>   drivers/raw/skeleton_rawdev/skeleton_rawdev.c      | 3 ++-
>   drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c | 4 ++--
>   2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/raw/skeleton_rawdev/skeleton_rawdev.c b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
> index d7630fc69..c957ced11 100644
> --- a/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
> +++ b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
> @@ -585,7 +585,8 @@ skeleton_rawdev_create(const char *name,
>   
>   	rawdev->dev_ops = &skeleton_rawdev_ops;
>   	rawdev->device = &vdev->device;
> -	rawdev->driver_name = vdev->device.driver->name;
> +
> +	rawdev->driver_name = rawdev->name;

This is not right. rawdev->name is name of the device and not that of a 
driver.

But, this also highlights a much bigger issue here:

----
$ master+* ± grep driver_name * -rn
dpaa2_cmdif/dpaa2_cmdif.c:214:  rawdev->driver_name = 
vdev->device.driver->name;
dpaa2_qdma/dpaa2_qdma.c:958:    rawdev->driver_name = 
dpaa2_drv->driver.name;
ifpga_rawdev/ifpga_rawdev.c:421:        rawdev->driver_name = 
pci_dev->device.driver->name;
skeleton_rawdev/skeleton_rawdev.c:588:  rawdev->driver_name = 
vdev->device.driver->name;
----

So, it seems that all rawdev drivers are assuming that even before probe 
is over (this assignment is path of probe within driver), they can 
assign the name to the 'device.driver'.

Here is the snippet from bus/pci/pci_common.c
--->8---
         ret = dr->probe(dr, dev);
	...
         if (ret) {
		/* Error case */
		...
         } else {
                 dev->device.driver = &dr->driver;
         }
--->8---

And from bus/vdev/vdev.c

--->8---
         ret = driver->probe(dev);
         if (ret == 0)
                 dev->device.driver = &driver->driver;
--->8---

So, the bus is actually assigning device.driver part *after* probe is 
successfully complete.

So, if your's segfaulted, there is a high probability others too would 
encounter the same.
This needs investigation.



>   
>   	skeldev = skeleton_rawdev_get_priv(rawdev);
>   
> diff --git a/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c b/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
> index 359c9e296..788c3f1b9 100644
> --- a/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
> +++ b/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
> @@ -294,14 +294,14 @@ test_rawdev_attr_set_get(void)
>   			      "Attribute (Test1) not set correctly (%" PRIu64 ")",
>   			      ret_value);
>   
> -	free(dummy_value);
> -
>   	ret_value = 0;
>   	ret = rte_rawdev_get_attr(TEST_DEV_ID, "Test2", &ret_value);
>   	RTE_TEST_ASSERT_EQUAL(*((int *)(uintptr_t)ret_value), 200,
>   			      "Attribute (Test2) not set correctly (%" PRIu64 ")",
>   			      ret_value);
>   
> +	free(dummy_value);
> +

The issue that you report is correct - that dummy_value is being 
released before next test - causing segfault.

The problem here is that if free(dummy_value) is called *after* "Test2", 
coverity reports error [See: 88d0e47880ec ("raw/skeleton: fix memory 
leak on test failure"] - and rightly so because RTE_TES_ASSERT_EQUAL() 
returns in case of error.

I will try and find a way out of this.

>   	return TEST_SUCCESS;
>   }
>   
> 


      reply	other threads:[~2018-12-13  7:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 13:14 Harman Kalra
2018-12-13  7:22 ` Shreyansh Jain [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6143dcfc-83b3-762a-b912-54acaa970470@nxp.com \
    --to=shreyansh.jain@nxp.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=hkalra@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=marko.kallio@cavium.com \
    --cc=marko.kallio@cavium.comm \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).