All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] coresight: Fix csdev connections initialisation
Date: Wed, 1 Jun 2016 10:30:34 +0100	[thread overview]
Message-ID: <574EAB3A.6040303@arm.com> (raw)
In-Reply-To: <CANLsYkzQJVY3CDC7D9_Miw3Lu7iqV-6ABsVbTUCpivc-R0WB+Q@mail.gmail.com>

On 31/05/16 18:55, Mathieu Poirier wrote:
> On 31 May 2016 at 05:57, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>> This is a cleanup patch.
>>
>> coresight_device->conns holds an array to point to the devices
>> connected to the OUT ports of a component. Sinks, e.g ETR, do not
>> have an OUT port (nr_outport = 0), as it streams the trace to
>> memory via AXI.
>>
>> At coresight_register() we do :
>>
>>          conns = kcalloc(csdev->nr_outport, sizeof(*conns), GFP_KERNEL);
>>          if (!conns) {
>>                  ret = -ENOMEM;
>>                  goto err_kzalloc_conns;
>>          }
>>
>> For ETR, since the total size requested for kcalloc is zero, the return value is,
>> ZERO_SIZE_PTR ( != NULL). Hence, csdev->conns = ZERO_SIZE_PTR which cannot be
>> verified later to contain a valid pointer. The code which accesses the csdev->conns
>> is bounded by the csdev->nr_outport check, hence we don't try to dereference the
>> ZERO_SIZE_PTR. This patch cleans up the csdev->conns and csdev->refcnt, initialisation
>> to make sure we initialise it properly(i.e, either NULL or valid conns array).
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>   drivers/hwtracing/coresight/coresight.c | 42 +++++++++++++++++++--------------
>>   1 file changed, 24 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
>> index 0fdaaf4..8410420 100644
>> --- a/drivers/hwtracing/coresight/coresight.c
>> +++ b/drivers/hwtracing/coresight/coresight.c
>> @@ -890,7 +890,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
>>          int nr_refcnts = 1;
>>          atomic_t *refcnts = NULL;
>>          struct coresight_device *csdev;
>> -       struct coresight_connection *conns;
>> +       struct coresight_connection *conns = NULL;
>>
>>          csdev = kzalloc(sizeof(*csdev), GFP_KERNEL);
>>          if (!csdev) {
>> @@ -908,29 +908,35 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
>>                          nr_refcnts = desc->pdata->nr_outport;
>>          }
>>
>> -       refcnts = kcalloc(nr_refcnts, sizeof(*refcnts), GFP_KERNEL);
>> -       if (!refcnts) {
>> -               ret = -ENOMEM;
>> -               goto err_kzalloc_refcnts;
>> -       }
>> +       if (nr_refcnts) {
>
> Did you manage to find a usecase where "nr_refcnts == 0" ?  Since
> components have at least one port this condition will always be true.

No, I didn't find one. While I was fixing the nr_outport, I thought it would
be good to check the refcnts as well.

>>
>> -       csdev->conns = conns;
>> +               for (i = 0; i < csdev->nr_outport; i++) {
>> +                       conns[i].outport = desc->pdata->outports[i];
>> +                       conns[i].child_name = desc->pdata->child_names[i];
>> +                       conns[i].child_port = desc->pdata->child_ports[i];
>> +               }
>> +
>> +               csdev->conns = conns;
>
> The purpose of your patch is to correctly initialise csdev->conns to
> NULL if there is no output port to speak of.  As such shouldn't the
> above statement be out of the if (csdev->nr_outport) {} ?.

Not necessarily. We do a kzalloc() for csdev, which implies csdev->conns
is already NULL. I can move the code to make that explicit assignment.

>
> I'm also getting a couple of checkpatch.pl warnings on this patch.

I can fix those warnings. I ignored them initially, as it was for the length of the comment.

Cheers
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/5] coresight: Fix csdev connections initialisation
Date: Wed, 1 Jun 2016 10:30:34 +0100	[thread overview]
Message-ID: <574EAB3A.6040303@arm.com> (raw)
In-Reply-To: <CANLsYkzQJVY3CDC7D9_Miw3Lu7iqV-6ABsVbTUCpivc-R0WB+Q@mail.gmail.com>

On 31/05/16 18:55, Mathieu Poirier wrote:
> On 31 May 2016 at 05:57, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>> This is a cleanup patch.
>>
>> coresight_device->conns holds an array to point to the devices
>> connected to the OUT ports of a component. Sinks, e.g ETR, do not
>> have an OUT port (nr_outport = 0), as it streams the trace to
>> memory via AXI.
>>
>> At coresight_register() we do :
>>
>>          conns = kcalloc(csdev->nr_outport, sizeof(*conns), GFP_KERNEL);
>>          if (!conns) {
>>                  ret = -ENOMEM;
>>                  goto err_kzalloc_conns;
>>          }
>>
>> For ETR, since the total size requested for kcalloc is zero, the return value is,
>> ZERO_SIZE_PTR ( != NULL). Hence, csdev->conns = ZERO_SIZE_PTR which cannot be
>> verified later to contain a valid pointer. The code which accesses the csdev->conns
>> is bounded by the csdev->nr_outport check, hence we don't try to dereference the
>> ZERO_SIZE_PTR. This patch cleans up the csdev->conns and csdev->refcnt, initialisation
>> to make sure we initialise it properly(i.e, either NULL or valid conns array).
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>   drivers/hwtracing/coresight/coresight.c | 42 +++++++++++++++++++--------------
>>   1 file changed, 24 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
>> index 0fdaaf4..8410420 100644
>> --- a/drivers/hwtracing/coresight/coresight.c
>> +++ b/drivers/hwtracing/coresight/coresight.c
>> @@ -890,7 +890,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
>>          int nr_refcnts = 1;
>>          atomic_t *refcnts = NULL;
>>          struct coresight_device *csdev;
>> -       struct coresight_connection *conns;
>> +       struct coresight_connection *conns = NULL;
>>
>>          csdev = kzalloc(sizeof(*csdev), GFP_KERNEL);
>>          if (!csdev) {
>> @@ -908,29 +908,35 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
>>                          nr_refcnts = desc->pdata->nr_outport;
>>          }
>>
>> -       refcnts = kcalloc(nr_refcnts, sizeof(*refcnts), GFP_KERNEL);
>> -       if (!refcnts) {
>> -               ret = -ENOMEM;
>> -               goto err_kzalloc_refcnts;
>> -       }
>> +       if (nr_refcnts) {
>
> Did you manage to find a usecase where "nr_refcnts == 0" ?  Since
> components have at least one port this condition will always be true.

No, I didn't find one. While I was fixing the nr_outport, I thought it would
be good to check the refcnts as well.

>>
>> -       csdev->conns = conns;
>> +               for (i = 0; i < csdev->nr_outport; i++) {
>> +                       conns[i].outport = desc->pdata->outports[i];
>> +                       conns[i].child_name = desc->pdata->child_names[i];
>> +                       conns[i].child_port = desc->pdata->child_ports[i];
>> +               }
>> +
>> +               csdev->conns = conns;
>
> The purpose of your patch is to correctly initialise csdev->conns to
> NULL if there is no output port to speak of.  As such shouldn't the
> above statement be out of the if (csdev->nr_outport) {} ?.

Not necessarily. We do a kzalloc() for csdev, which implies csdev->conns
is already NULL. I can move the code to make that explicit assignment.

>
> I'm also getting a couple of checkpatch.pl warnings on this patch.

I can fix those warnings. I ignored them initially, as it was for the length of the comment.

Cheers
Suzuki

  reply	other threads:[~2016-06-01  9:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 11:57 [PATCH 0/5] coresight: Miscellaneous fixes Suzuki K Poulose
2016-05-31 11:57 ` Suzuki K Poulose
2016-05-31 11:57 ` [PATCH 1/5] coresight: Fix NULL pointer dereference in _coresight_build_path Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:39   ` Mathieu Poirier
2016-05-31 17:39     ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 2/5] coresight: etmv4: Fix ETMv4x peripheral ID table Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:45   ` Mathieu Poirier
2016-05-31 17:45     ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 3/5] coresight: Fix csdev connections initialisation Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:55   ` Mathieu Poirier
2016-05-31 17:55     ` Mathieu Poirier
2016-06-01  9:30     ` Suzuki K Poulose [this message]
2016-06-01  9:30       ` Suzuki K Poulose
2016-05-31 11:57 ` [PATCH 4/5] coresight: Add better messages for coresight_timeout Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:57   ` Mathieu Poirier
2016-05-31 17:57     ` Mathieu Poirier
2016-05-31 17:58   ` Joe Perches
2016-05-31 17:58     ` Joe Perches
2016-06-01  9:34     ` Suzuki K Poulose
2016-06-01  9:34       ` Suzuki K Poulose
2016-06-01 15:15       ` Mathieu Poirier
2016-06-01 15:15         ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 5/5] coresight: Cleanup TMC status check Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 18:01   ` Mathieu Poirier
2016-05-31 18:01     ` Mathieu Poirier

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=574EAB3A.6040303@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.