All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-s390@vger.kernel.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCH] s390: Fix perf event init
Date: Wed, 20 Sep 2017 08:51:00 +0200	[thread overview]
Message-ID: <20170920085100.6adb0e0d@mschwideX1> (raw)
In-Reply-To: <20170920050757.22857-1-paul.burton@imgtec.com>

Hi Paul,

On Tue, 19 Sep 2017 22:07:57 -0700
Paul Burton <paul.burton@imgtec.com> wrote:

> Commit c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
> modified cpumsf_pmu_event_init() to cast the struct perf_event cpu field
> to an unsigned integer before it is compared with nr_cpumask_bits. This
> is broken because the cpu field may be -1 for events which follow a
> process rather than being affine to a particular CPU. When this is the
> case the cast to an unsigned int results in a value equal to ULONG_MAX,
> which is always greater than nr_cpumask_bits so we always fail
> cpumsf_pmu_event_init() and return -ENODEV.
> 
> The check against nr_cpumask_bits seems nonsensical anyway, so this
> patch simply removes it. The cpu field is going to either be 0 or a
> valid CPU number. Comparing it with nr_cpumask_bits is effectively
> checking that it's a valid cpu number, but it seems safe to rely on the
> core perf events code to ensure that's the case.
> 
> The end result is that this fixes use of perf when not constraining
> events to a particular CPU, and fixes the "perf list hw" command which
> fails to list any events without this.
> 
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> Fixes: c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
> Cc: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: linux-s390@vger.kernel.org
> Cc: stable <stable@vger.kernel.org> # v4.12+
> 
> ---
> This patch is purely speculative, based upon fixing perf on MIPS
> following the offending commit c311c797998c ("cpumask: make
> "nr_cpumask_bits" unsigned") which made the same change to both MIPS &
> s390. I leave it to s390 developers to verify whether this affects them
> in the same way as it affected MIPS thus whether this fix is correct
> there too.

Thanks for the patch, there is indeed an issue with nr_cpumask_bits.
But we already have a slightly different fix for this queued on the
fixes branch of s390/linux:

https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=fixes&id=fc3100d64f0ae383ae8d845989103da06d62763b

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: <linux-s390@vger.kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCH] s390: Fix perf event init
Date: Wed, 20 Sep 2017 08:51:00 +0200	[thread overview]
Message-ID: <20170920085100.6adb0e0d@mschwideX1> (raw)
In-Reply-To: <20170920050757.22857-1-paul.burton@imgtec.com>

Hi Paul,

On Tue, 19 Sep 2017 22:07:57 -0700
Paul Burton <paul.burton@imgtec.com> wrote:

> Commit c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
> modified cpumsf_pmu_event_init() to cast the struct perf_event cpu field
> to an unsigned integer before it is compared with nr_cpumask_bits. This
> is broken because the cpu field may be -1 for events which follow a
> process rather than being affine to a particular CPU. When this is the
> case the cast to an unsigned int results in a value equal to ULONG_MAX,
> which is always greater than nr_cpumask_bits so we always fail
> cpumsf_pmu_event_init() and return -ENODEV.
> 
> The check against nr_cpumask_bits seems nonsensical anyway, so this
> patch simply removes it. The cpu field is going to either be 0 or a
> valid CPU number. Comparing it with nr_cpumask_bits is effectively
> checking that it's a valid cpu number, but it seems safe to rely on the
> core perf events code to ensure that's the case.
> 
> The end result is that this fixes use of perf when not constraining
> events to a particular CPU, and fixes the "perf list hw" command which
> fails to list any events without this.
> 
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> Fixes: c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
> Cc: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: linux-s390@vger.kernel.org
> Cc: stable <stable@vger.kernel.org> # v4.12+
> 
> ---
> This patch is purely speculative, based upon fixing perf on MIPS
> following the offending commit c311c797998c ("cpumask: make
> "nr_cpumask_bits" unsigned") which made the same change to both MIPS &
> s390. I leave it to s390 developers to verify whether this affects them
> in the same way as it affected MIPS thus whether this fix is correct
> there too.

Thanks for the patch, there is indeed an issue with nr_cpumask_bits.
But we already have a slightly different fix for this queued on the
fixes branch of s390/linux:

https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=fixes&id=fc3100d64f0ae383ae8d845989103da06d62763b

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

  reply	other threads:[~2017-09-20  6:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20  5:07 [PATCH] s390: Fix perf event init Paul Burton
2017-09-20  5:07 ` Paul Burton
2017-09-20  6:51 ` Martin Schwidefsky [this message]
2017-09-20  6:51   ` Martin Schwidefsky
2017-09-20 12:15   ` Heiko Carstens
2017-09-20 16:04     ` Paul Burton
2017-09-20 16:04       ` Paul Burton
2017-09-20 20:54       ` Alexey Dobriyan

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=20170920085100.6adb0e0d@mschwideX1 \
    --to=schwidefsky@de.ibm.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=stable@vger.kernel.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.