From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 39AEA35295C for ; Mon, 23 Feb 2026 10:23:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771842228; cv=none; b=S6UUu7oE21o4b3IJbS4agiypEb/a9Z3kgN7XOM0fMsymsUvfj5ZxdzsL4dChgT2IhUqARGurmGKHcmqcnNNIkZPNGjoWIGbNYzGPpE+pTlf83gt6eBCCJ1Ia4nvvhNM878B3GKrzhKkISuzOct1fXFP6Sj886hsYP941aURY1Zs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771842228; c=relaxed/simple; bh=HmYfZSaA9BL2YrIuz88qtjK5frUhP3ED5n+nUkxyTYc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BQrZ9/ikdtNokE1ceeYx8RdXWIsBv9eVbDGCjv07KTJSJ8/w5h787ODO23/CGA95kEy4EKuip9Qa8AQ1VE1LQ6u3zxj26SGdyyRz3rwx6SyTJuChAiCaqs2tQDk2GnJTA6Aq6F8IV/1EIWCkuMuyVSnPBXdGEddWFOok4CIzwp8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4B3C6339; Mon, 23 Feb 2026 02:23:40 -0800 (PST) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 285BC3F59E; Mon, 23 Feb 2026 02:23:46 -0800 (PST) Date: Mon, 23 Feb 2026 10:23:43 +0000 From: Leo Yan To: Suzuki K Poulose Cc: Mike Leach , James Clark , Mathieu Poirier , Greg Kroah-Hartman , Junhao He , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Michiel van Tol Subject: Re: [PATCH] coresight: tmc: Fix overflow when calculating is bigger than 2GiB Message-ID: <20260223102343.GK136967@e132581.arm.com> References: <20260217-arm_coresight_fix_big_buffer_size-v1-1-774e893d8e3f@arm.com> <666e2c55-a1aa-4960-a084-50921ec7f696@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <666e2c55-a1aa-4960-a084-50921ec7f696@arm.com> On Mon, Feb 23, 2026 at 09:50:41AM +0000, Suzuki K Poulose wrote: [...] > > --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c > > +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c > > @@ -154,7 +154,7 @@ tmc_pages_get_offset(struct tmc_pages *tmc_pages, dma_addr_t addr) > > for (i = 0; i < tmc_pages->nr_pages; i++) { > > page_start = tmc_pages->daddrs[i]; > > if (addr >= page_start && addr < (page_start + PAGE_SIZE)) > > - return i * PAGE_SIZE + (addr - page_start); > > + return (long)i * PAGE_SIZE + (addr - page_start); > > } > > return -EINVAL; > > @@ -1381,7 +1381,7 @@ alloc_etr_buf(struct tmc_drvdata *drvdata, struct perf_event *event, > > node = (event->cpu == -1) ? NUMA_NO_NODE : cpu_to_node(event->cpu); > > /* Use the minimum limit if the required size is smaller */ > > - size = nr_pages << PAGE_SHIFT; > > + size = (ssize_t)nr_pages << PAGE_SHIFT; > > size = max_t(ssize_t, size, TMC_ETR_PERF_MIN_BUF_SIZE); > > /* > > > > Thanks for the fix. Could we not fix the declaration of the variables > instead ? (Also add a comment to make sure people don't revert it back ) I thought a bit the variable declaration when worked on the patch, but it is tricky. "nr_pages" is passed down from the perf core layer as an int type. In CoreSight, the value is passed down through several functions using the same type, and it does not seem necessary to change the type in every function in the call path. We could silently use wider type for the "nr_pages" argument or the index variable "i". As you said, we need comments to remind future changing. This might be more error-prone than using an explicit cast at the point of calculation ? Thanks, Leo