All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Paul Burton <paul.burton@imgtec.com>,
	linux-s390@vger.kernel.org,
	Christian Borntraeger <borntraeger@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 14:15:17 +0200	[thread overview]
Message-ID: <20170920121517.GE3583@osiris> (raw)
In-Reply-To: <20170920085100.6adb0e0d@mschwideX1>

On Wed, Sep 20, 2017 at 08:51:00AM +0200, Martin Schwidefsky wrote:
> 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

I assume you meant to write "...either be -1..."?

> > 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.

Looks like you are right and the nr_cpumask_bits check is not needed. The
sanity check is done at the beginning of perf_event_alloc() and everything
else can rely on a sane cpu number (-1 or within bounds of nr_cpumask_bits).

> 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

So we should either use your patch or remove the superfluous check with an
addon patch. Martin's call ;)

  reply	other threads:[~2017-09-20 12:15 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
2017-09-20  6:51   ` Martin Schwidefsky
2017-09-20 12:15   ` Heiko Carstens [this message]
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=20170920121517.GE3583@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=schwidefsky@de.ibm.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.