All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: mark.rutland@arm.com, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
Date: Wed, 20 May 2020 16:47:11 +0100	[thread overview]
Message-ID: <20200520154711.GD18302@gaia> (raw)
In-Reply-To: <20200520122012.GA25815@willie-the-truck>

On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
> > There is no way to proceed when requested register could not be searched in
> > arm64_ftr_reg[]. Requesting for a non present register would be an error as
> > well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
> > rather than checking for return value and doing the same in some individual
> > callers.
> > 
> > But there are some callers that dont BUG_ON() upon search failure. It adds
> > an argument 'failsafe' that provides required switch between callers based
> > on whether they could proceed or not.
> > 
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > 
> > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > ---
> > Applies on next-20200518 that has recent cpufeature changes from Will.
> > 
> >  arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index bc5048f152c1..62767cc540c3 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
> >   *         - NULL on failure. It is upto the caller to decide
> >   *	     the impact of a failure.
> >   */
> > -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
> > +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
> 
> Generally, I'm not a big fan of boolean arguments because they are really
> opaque at the callsite. It also seems bogus to me that we don't trust the
> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
> which seems to mean "I promise to check the result isn't NULL before
> dereferencing it."
> 
> So I don't see how this patch improves anything. I'd actually be more
> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
> have the callers handle NULL by returning early, getting rid of all the
> BUG_ONs in here. Sure, the system might end up in a funny state, but we
> WARN()d about it and tried to keep going (and Linus has some strong opinions
> on this too).

Such WARN can be triggered by the user via emulate_sys_reg(), so we
can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
Date: Wed, 20 May 2020 16:47:11 +0100	[thread overview]
Message-ID: <20200520154711.GD18302@gaia> (raw)
In-Reply-To: <20200520122012.GA25815@willie-the-truck>

On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
> > There is no way to proceed when requested register could not be searched in
> > arm64_ftr_reg[]. Requesting for a non present register would be an error as
> > well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
> > rather than checking for return value and doing the same in some individual
> > callers.
> > 
> > But there are some callers that dont BUG_ON() upon search failure. It adds
> > an argument 'failsafe' that provides required switch between callers based
> > on whether they could proceed or not.
> > 
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > 
> > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > ---
> > Applies on next-20200518 that has recent cpufeature changes from Will.
> > 
> >  arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index bc5048f152c1..62767cc540c3 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
> >   *         - NULL on failure. It is upto the caller to decide
> >   *	     the impact of a failure.
> >   */
> > -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
> > +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
> 
> Generally, I'm not a big fan of boolean arguments because they are really
> opaque at the callsite. It also seems bogus to me that we don't trust the
> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
> which seems to mean "I promise to check the result isn't NULL before
> dereferencing it."
> 
> So I don't see how this patch improves anything. I'd actually be more
> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
> have the callers handle NULL by returning early, getting rid of all the
> BUG_ONs in here. Sure, the system might end up in a funny state, but we
> WARN()d about it and tried to keep going (and Linus has some strong opinions
> on this too).

Such WARN can be triggered by the user via emulate_sys_reg(), so we
can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.

-- 
Catalin

  reply	other threads:[~2020-05-20 15:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  1:22 [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg() Anshuman Khandual
2020-05-20  1:22 ` Anshuman Khandual
2020-05-20 11:49 ` Catalin Marinas
2020-05-20 11:49   ` Catalin Marinas
2020-05-20 12:20 ` Will Deacon
2020-05-20 12:20   ` Will Deacon
2020-05-20 15:47   ` Catalin Marinas [this message]
2020-05-20 15:47     ` Catalin Marinas
2020-05-20 17:39     ` Will Deacon
2020-05-20 17:39       ` Will Deacon
2020-05-21  3:15       ` Anshuman Khandual
2020-05-21  3:15         ` Anshuman Khandual
2020-05-21 16:22         ` Will Deacon
2020-05-21 16:22           ` Will Deacon
2020-05-21 16:59           ` Catalin Marinas
2020-05-21 16:59             ` Catalin Marinas
2020-05-24 23:52             ` Anshuman Khandual
2020-05-24 23:52               ` Anshuman Khandual
2020-05-26 12:19               ` Catalin Marinas
2020-05-26 12:19                 ` Catalin Marinas
2020-05-21  3:12   ` Anshuman Khandual
2020-05-21  3:12     ` Anshuman Khandual

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=20200520154711.GD18302@gaia \
    --to=catalin.marinas@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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.