From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933623AbcFMOhn (ORCPT ); Mon, 13 Jun 2016 10:37:43 -0400 Received: from mail-yw0-f181.google.com ([209.85.161.181]:36162 "EHLO mail-yw0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933313AbcFMOhm (ORCPT ); Mon, 13 Jun 2016 10:37:42 -0400 MIME-Version: 1.0 In-Reply-To: <575E74C9.9010004@arm.com> References: <1465204301-24184-1-git-send-email-suzuki.poulose@arm.com> <1465204301-24184-5-git-send-email-suzuki.poulose@arm.com> <575E74C9.9010004@arm.com> From: Mathieu Poirier Date: Mon, 13 Jun 2016 08:37:35 -0600 Message-ID: Subject: Re: [PATCH v2 4/9] coresight: Fix csdev connections initialisation To: Suzuki K Poulose Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13 June 2016 at 02:54, Suzuki K Poulose wrote: > On 12/06/16 21:39, Mathieu Poirier wrote: >> >> On 6 June 2016 at 03:11, Suzuki K Poulose 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 >> >> >> This patch no longer deals with csdev->refcnt. > > > Ok, fill fix that. Btw, do we need that check ? I am tempted to keep it > there, > just to make sure we don't end up in something similar in the future. If it becomes an issue in the future we'll know what to do :o) Thanks, Mathieu > > Cheers > Suzuki From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathieu.poirier@linaro.org (Mathieu Poirier) Date: Mon, 13 Jun 2016 08:37:35 -0600 Subject: [PATCH v2 4/9] coresight: Fix csdev connections initialisation In-Reply-To: <575E74C9.9010004@arm.com> References: <1465204301-24184-1-git-send-email-suzuki.poulose@arm.com> <1465204301-24184-5-git-send-email-suzuki.poulose@arm.com> <575E74C9.9010004@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 13 June 2016 at 02:54, Suzuki K Poulose wrote: > On 12/06/16 21:39, Mathieu Poirier wrote: >> >> On 6 June 2016 at 03:11, Suzuki K Poulose 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 >> >> >> This patch no longer deals with csdev->refcnt. > > > Ok, fill fix that. Btw, do we need that check ? I am tempted to keep it > there, > just to make sure we don't end up in something similar in the future. If it becomes an issue in the future we'll know what to do :o) Thanks, Mathieu > > Cheers > Suzuki