[GIT PULL 0/3] stm class/intel_th: Fixes for v5.1

[GIT PULL 0/3] stm class/intel_th: Fixes for v5.1

[Alexander Shishkin]

Hi Greg,

Here are the fixes that I have for 5.1. These are two bugfixes in stm
class code, both stable-worthy and a new PCI ID for Intel TH. Static
checkers approve, as usual. Individual patches follow. Please consider
pulling or applying. Thanks!

The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:

  Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git tags/intel_th-stm-fixes-for-greg-20190417

for you to fetch changes up to a32bb4a8524253943548f6c3794bfe9af5c99f4b:

  intel_th: pci: Add Comet Lake support (2019-04-17 10:16:04 +0300)

----------------------------------------------------------------
stm class/intel_th: Fixes for v5.1

These are:
 * Fix for a resource leak in stm core
 * Fix for stm on 32-bit systems
 * A new PCI ID for Intel TH

----------------------------------------------------------------
Alexander Shishkin (2):
      stm class: Fix channel bitmap on 32-bit systems
      intel_th: pci: Add Comet Lake support

Tingwei Zhang (1):
      stm class: Fix channel free in stm output free path

 drivers/hwtracing/intel_th/pci.c | 5 +++++
 drivers/hwtracing/stm/core.c     | 9 ++++-----
 2 files changed, 9 insertions(+), 5 deletions(-)

-- 
2.20.1

[GIT PULL 1/3] stm class: Fix channel free in stm output free path

[Alexander Shishkin]

From: Tingwei Zhang <tingwei@codeaurora.org>

Number of free masters is not set correctly in stm
free path. Fix this by properly adding the number
of output channels before setting them to 0 in
stm_output_disclaim().

Currently it is equivalent to doing nothing since
master->nr_free is incremented by 0.

Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices")
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: stable@vger.kernel.org # v4.4
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 drivers/hwtracing/stm/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index c7ba8acfd4d5..5b5807cbcf7c 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -218,8 +218,8 @@ stm_output_disclaim(struct stm_device *stm, struct stm_output *output)
 	bitmap_release_region(&master->chan_map[0], output->channel,
 			      ilog2(output->nr_chans));
 
-	output->nr_chans = 0;
 	master->nr_free += output->nr_chans;
+	output->nr_chans = 0;
 }
 
 /*
-- 
2.20.1

[GIT PULL 2/3] stm class: Fix channel bitmap on 32-bit systems

[Alexander Shishkin]

Commit 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace
Module devices") naively calculates the channel bitmap size in 64-bit
chunks regardless of the size of underlying unsigned long, making the
bitmap half as big on a 32-bit system. This leads to an out of bounds
access with the upper half of the bitmap.

Fix this by using BITS_TO_LONGS. While at it, convert to using
struct_size() for the total size calculation of the master struct.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices")
Reported-by: Mulu He <muluhe@codeaurora.org>
Cc: stable@vger.kernel.org # v4.4+
---
 drivers/hwtracing/stm/core.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 5b5807cbcf7c..e55b902560de 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -166,11 +166,10 @@ stm_master(struct stm_device *stm, unsigned int idx)
 static int stp_master_alloc(struct stm_device *stm, unsigned int idx)
 {
 	struct stp_master *master;
-	size_t size;
 
-	size = ALIGN(stm->data->sw_nchannels, 8) / 8;
-	size += sizeof(struct stp_master);
-	master = kzalloc(size, GFP_ATOMIC);
+	master = kzalloc(struct_size(master, chan_map,
+				     BITS_TO_LONGS(stm->data->sw_nchannels)),
+			 GFP_ATOMIC);
 	if (!master)
 		return -ENOMEM;
 
-- 
2.20.1

[GIT PULL 3/3] intel_th: pci: Add Comet Lake support

[Alexander Shishkin]

This adds support for Intel TH on Comet Lake.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 drivers/hwtracing/intel_th/pci.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/hwtracing/intel_th/pci.c b/drivers/hwtracing/intel_th/pci.c
index 1cf6290d6435..70f2cb90adc5 100644
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -165,6 +165,11 @@ static const struct pci_device_id intel_th_pci_id_table[] = {
 		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x34a6),
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
 	},
+	{
+		/* Comet Lake */
+		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x02a6),
+		.driver_data = (kernel_ulong_t)&intel_th_2x,
+	},
 	{ 0 },
 };
 
-- 
2.20.1

Re: [GIT PULL 0/3] stm class/intel_th: Fixes for v5.1

[Alexander Shishkin]

Alexander Shishkin <alexander.shishkin@linux.intel.com> writes:

> Hi Greg,

Hi Greg,

This seems to have fallen through the cracks. Unless you picked it up
already, should I resend these as a part of my pull request for v5.2
instead? Both fixes are not v5.1 specific and will have to go to stable
either way.

Regards,
--
Alex

Re: [GIT PULL 0/3] stm class/intel_th: Fixes for v5.1

[Alexander Shishkin]

Alexander Shishkin <alexander.shishkin@linux.intel.com> writes:

> Alexander Shishkin <alexander.shishkin@linux.intel.com> writes:
>
>> Hi Greg,
>
> Hi Greg,
>
> This seems to have fallen through the cracks. Unless you picked it up
> already, should I resend these as a part of my pull request for v5.2
> instead? Both fixes are not v5.1 specific and will have to go to stable
> either way.

I see you picked them up already, so disregard that email.

Thanks,
--
Alex

Re: [GIT PULL 0/3] stm class/intel_th: Fixes for v5.1

[Greg Kroah-Hartman]

On Thu, Apr 25, 2019 at 12:48:11PM +0300, Alexander Shishkin wrote:
> Alexander Shishkin <alexander.shishkin@linux.intel.com> writes:
> 
> > Hi Greg,
> 
> Hi Greg,
> 
> This seems to have fallen through the cracks. Unless you picked it up
> already, should I resend these as a part of my pull request for v5.2
> instead? Both fixes are not v5.1 specific and will have to go to stable
> either way.

I just picked these up a few hours ago :)

thanks,

greg k-h