All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Petr Mladek <pmladek@suse.com>,  Arnd Bergmann <arnd@arndb.de>,
	Borislav Petkov <bp@alien8.de>,
	 Christophe Leroy <christophe.leroy@csgroup.eu>,
	"Darrick J. Wong" <djwong@kernel.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	 Gaosheng Cui <cuigaosheng1@huawei.com>,
	"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	 Guo Ren <guoren@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Huacai Chen <chenhuacai@kernel.org>,
	 Ingo Molnar <mingo@redhat.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Jianmin Lv <lvjianmin@loongson.cn>,
	 Jinyang He <hejinyang@loongson.cn>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	 Kees Cook <keescook@chromium.org>,
	Lecopzer Chen <lecopzer.chen@mediatek.com>,
	 Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	 "Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	 Pingfan Liu <kernelfans@gmail.com>,
	Qing Zhang <zhangqing@loongson.cn>,
	 "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Russell King <linux@armlinux.org.uk>,
	 Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	 Thomas Gleixner <tglx@linutronix.de>, Tom Rix <trix@redhat.com>,
	 Ulf Hansson <ulf.hansson@linaro.org>,
	Valentin Schneider <vschneid@redhat.com>,
	 WANG Xuerui <kernel@xen0n.name>,
	linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	 linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
	 sparclinux@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU
Date: Fri, 4 Aug 2023 09:06:07 -0700	[thread overview]
Message-ID: <CAD=FV=XhksUsBKjkD08YxdmxvvbgoZH-va7WnPptkYA6EOpPsg@mail.gmail.com> (raw)
In-Reply-To: <ZM0S9gKBBiu83kFq@dhcp22.suse.cz>

Hi,

On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko <mhocko@suse.com> wrote:
>
> > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace
> > > by switching arguments so that some leftovers are captured easier.
> >
> > I'm not sure I understand. Oh, you're saying make the prototype of
> > arch_trigger_cpumask_backtrace() incompatible so that if someone is
> > directly calling it then it'll be a compile-time error?
>
> exactly. bool to int promotion would be too easy to miss while the
> pointer to int would complain loudly.
>
> > I guess the
> > hope is that nobody is calling that directly and they're calling
> > through the trigger_...() functions.
>
> Hope is one thing, being preventive another.
>
> > For now I'm going to leave this alone.
>
> If you are going to send another version then please consider this. Not
> a hard requirement but better.

If I do send another version, do you have any suggestions for how to
change this to make it incompatible? I guess swapping the order of the
parameters would be best? I considered doing that for v4 but I felt
like long term the current order of the parameters was better. I also
considered a rename, but that different problems. ;-) If I rename both
the #define and the function then if someone has an out-of-tree patch
adding arch_trigger_cpumask_backtrace() for another architecture, like
say arm64, then there would be no compile-time failure indicating that
the out-of-tree patch needs updating. I could rename the functions but
_not_ the #define, I guess?

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Jinyang He <hejinyang@loongson.cn>,
	Lecopzer Chen <lecopzer.chen@mediatek.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Qing Zhang <zhangqing@loongson.cn>,
	Pingfan Liu <kernelfans@gmail.com>,
	linux-mips@vger.kernel.org, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, WANG Xuerui <kernel@xen0n.name>,
	Gaosheng Cui <cuigaosheng1@huawei.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Valentin Schneider <vschneid@redhat.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Marc Zyngier <maz@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, Tom Rix <trix@redhat.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Petr Mladek <pmladek@suse.com>, Kees Cook <keescook@chromium.org>,
	Arnd Ber gmann <arnd@arndb.de>,
	Nicholas Piggin <npiggin@gmail.com>,
	Jianmin Lv <lvjianmin@loongson.cn>,
	Borislav Petkov <bp@alien8.de>,
	loongarch@lists.linux.dev, Thomas Gleixner <tglx@linutronix.de>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU
Date: Fri, 4 Aug 2023 09:06:07 -0700	[thread overview]
Message-ID: <CAD=FV=XhksUsBKjkD08YxdmxvvbgoZH-va7WnPptkYA6EOpPsg@mail.gmail.com> (raw)
In-Reply-To: <ZM0S9gKBBiu83kFq@dhcp22.suse.cz>

Hi,

On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko <mhocko@suse.com> wrote:
>
> > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace
> > > by switching arguments so that some leftovers are captured easier.
> >
> > I'm not sure I understand. Oh, you're saying make the prototype of
> > arch_trigger_cpumask_backtrace() incompatible so that if someone is
> > directly calling it then it'll be a compile-time error?
>
> exactly. bool to int promotion would be too easy to miss while the
> pointer to int would complain loudly.
>
> > I guess the
> > hope is that nobody is calling that directly and they're calling
> > through the trigger_...() functions.
>
> Hope is one thing, being preventive another.
>
> > For now I'm going to leave this alone.
>
> If you are going to send another version then please consider this. Not
> a hard requirement but better.

If I do send another version, do you have any suggestions for how to
change this to make it incompatible? I guess swapping the order of the
parameters would be best? I considered doing that for v4 but I felt
like long term the current order of the parameters was better. I also
considered a rename, but that different problems. ;-) If I rename both
the #define and the function then if someone has an out-of-tree patch
adding arch_trigger_cpumask_backtrace() for another architecture, like
say arm64, then there would be no compile-time failure indicating that
the out-of-tree patch needs updating. I could rename the functions but
_not_ the #define, I guess?

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Petr Mladek <pmladek@suse.com>,  Arnd Bergmann <arnd@arndb.de>,
	Borislav Petkov <bp@alien8.de>,
	 Christophe Leroy <christophe.leroy@csgroup.eu>,
	"Darrick J. Wong" <djwong@kernel.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	 Gaosheng Cui <cuigaosheng1@huawei.com>,
	"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	 Guo Ren <guoren@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Huacai Chen <chenhuacai@kernel.org>,
	 Ingo Molnar <mingo@redhat.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Jianmin Lv <lvjianmin@loongson.cn>,
	 Jinyang He <hejinyang@loongson.cn>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	 Kees Cook <keescook@chromium.org>,
	Lecopzer Chen <lecopzer.chen@mediatek.com>,
	 Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	 "Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	 Pingfan Liu <kernelfans@gmail.com>,
	Qing Zhang <zhangqing@loongson.cn>,
	 "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Russell King <linux@armlinux.org.uk>,
	 Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	 Thomas Gleixner <tglx@linutronix.de>, Tom Rix <trix@redhat.com>,
	 Ulf Hansson <ulf.hansson@linaro.org>,
	Valentin Schneider <vschneid@redhat.com>,
	 WANG Xuerui <kernel@xen0n.name>,
	linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	 linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
	 sparclinux@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU
Date: Fri, 4 Aug 2023 09:06:07 -0700	[thread overview]
Message-ID: <CAD=FV=XhksUsBKjkD08YxdmxvvbgoZH-va7WnPptkYA6EOpPsg@mail.gmail.com> (raw)
In-Reply-To: <ZM0S9gKBBiu83kFq@dhcp22.suse.cz>

Hi,

On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko <mhocko@suse.com> wrote:
>
> > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace
> > > by switching arguments so that some leftovers are captured easier.
> >
> > I'm not sure I understand. Oh, you're saying make the prototype of
> > arch_trigger_cpumask_backtrace() incompatible so that if someone is
> > directly calling it then it'll be a compile-time error?
>
> exactly. bool to int promotion would be too easy to miss while the
> pointer to int would complain loudly.
>
> > I guess the
> > hope is that nobody is calling that directly and they're calling
> > through the trigger_...() functions.
>
> Hope is one thing, being preventive another.
>
> > For now I'm going to leave this alone.
>
> If you are going to send another version then please consider this. Not
> a hard requirement but better.

If I do send another version, do you have any suggestions for how to
change this to make it incompatible? I guess swapping the order of the
parameters would be best? I considered doing that for v4 but I felt
like long term the current order of the parameters was better. I also
considered a rename, but that different problems. ;-) If I rename both
the #define and the function then if someone has an out-of-tree patch
adding arch_trigger_cpumask_backtrace() for another architecture, like
say arm64, then there would be no compile-time failure indicating that
the out-of-tree patch needs updating. I could rename the functions but
_not_ the #define, I guess?

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

  reply	other threads:[~2023-08-04 16:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 23:07 [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU Douglas Anderson
2023-08-03 23:07 ` Douglas Anderson
2023-08-03 23:07 ` Douglas Anderson
2023-08-03 23:07 ` [PATCH v3 2/2] watchdog/hardlockup: Avoid large stack frames in watchdog_hardlockup_check() Douglas Anderson
2023-08-04  7:50   ` Michal Hocko
2023-08-04  7:50 ` [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU Michal Hocko
2023-08-04  7:50   ` Michal Hocko
2023-08-04  7:50   ` Michal Hocko
2023-08-04 13:56   ` Doug Anderson
2023-08-04 13:56     ` Doug Anderson
2023-08-04 13:56     ` Doug Anderson
2023-08-04 15:02     ` Michal Hocko
2023-08-04 15:02       ` Michal Hocko
2023-08-04 15:02       ` Michal Hocko
2023-08-04 16:06       ` Doug Anderson [this message]
2023-08-04 16:06         ` Doug Anderson
2023-08-04 16:06         ` Doug Anderson
2023-08-07  7:03         ` Michal Hocko
2023-08-07  7:03           ` Michal Hocko
2023-08-07  7:03           ` Michal Hocko

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='CAD=FV=XhksUsBKjkD08YxdmxvvbgoZH-va7WnPptkYA6EOpPsg@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=Jason@zx2c4.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=chenhuacai@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=cuigaosheng1@huawei.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=djwong@kernel.org \
    --cc=gautham.shenoy@amd.com \
    --cc=gpiccoli@igalia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guoren@kernel.org \
    --cc=hejinyang@loongson.cn \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernel@xen0n.name \
    --cc=kernelfans@gmail.com \
    --cc=lecopzer.chen@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=lvjianmin@loongson.cn \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=trix@redhat.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulf.hansson@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.org \
    --cc=zhangqing@loongson.cn \
    /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.