Awesome, thanks!
On Wed, May 24, 2023, 6:03 PM Michael Ellerman wrote:
> Bagas Sanjaya writes:
> > On 5/24/23 17:58, Bagas Sanjaya wrote:
> >> Anyway, I'm adding it to regzbot:
> >>
> >> #regzbot introduced: 23baf831a32c04f
> https://bugzilla.kernel.org/show_bug.cgi?id=217477
> >> #regzbot titl
Glad to hear it!
Thank you
On Wed, May 24, 2023, 3:58 PM Bagas Sanjaya wrote:
> On 5/24/23 17:58, Bagas Sanjaya wrote:
> > Anyway, I'm adding it to regzbot:
> >
> > #regzbot introduced: 23baf831a32c04f
> https://bugzilla.kernel.org/show_bug.cgi?id=217477
> > #regzbot title: Allocator MAX_ORDER e
On Thu, May 25, 2023 at 01:03:22AM +1000, Michael Ellerman wrote:
> Should be fixed properly by:
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230519113806.370635-1-...@ellerman.id.au/
>
> Which is in powerpc-fixes as 358e526a1648.
Telling regzbot:
#regzbot fix: 358e526a1648cd
On 5/24/23 19:16, Jerry Snitselaar wrote:
On Tue, Apr 18, 2023 at 09:44:08AM -0400, Stefan Berger wrote:
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
Reviewed-b
On Tue, Apr 18, 2023 at 09:44:08AM -0400, Stefan Berger wrote:
> Refactor IMA buffer related functions to make them reusable for carrying
> TPM logs across kexec.
>
> Signed-off-by: Stefan Berger
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: Mimi Zohar
> Reviewed-by: Mimi Zohar
> Reviewed-by: Ro
On Tue, Apr 18, 2023 at 09:44:07AM -0400, Stefan Berger wrote:
> Simplify tpm_read_log_of() by moving reusable parts of the code into
> an inline function that makes it commonly available so it can be
> used also for kexec support. Call the new of_tpm_get_sml_parameters()
> function from the TPM Op
On Tue, Apr 18, 2023 at 09:44:06AM -0400, Stefan Berger wrote:
> From: Palmer Dabbelt
>
> RISC-V recently added kexec_file() support, which uses enables kexec
> IMA. We're the first 32-bit platform to support this, so we found a
> build bug.
>
> Acked-by: Rob Herring
> Signed-off-by: Palmer Da
On Tue, May 23, 2023 at 06:22:13PM -0500, Terry Bowman wrote:
> From: Robert Richter
>
> In Restricted CXL Device (RCD) mode a CXL device is exposed as an
> RCiEP, but CXL downstream and upstream ports are not enumerated and
> not visible in the PCIe hierarchy. Protocol and link errors are sent
>
Hi,
On Wed, May 24, 2023 at 6:59 AM Petr Mladek wrote:
>
> On Fri 2023-05-19 10:18:37, Douglas Anderson wrote:
> > The fact that there watchdog_hardlockup_enable(),
> > watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
> > declared __weak means that the configured hardlockup dete
On Wed, May 17, 2023 at 03:11:01PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> There are a few __weak functions in kernel/fork.c, which architectures
> can override. If there is no prototype, the compiler warns about them:
>
> kernel/fork.c:164:13: error: no previous prototype for
> '
On Wed, May 17, 2023 at 4:52 PM Arnd Bergmann wrote:
>
> On Wed, May 17, 2023, at 15:48, Rafael J. Wysocki wrote:
> > On Wed, May 17, 2023 at 3:12 PM Arnd Bergmann wrote:
> >>
> >> From: Arnd Bergmann
> >>
> >> The arch_resume_nosmt() has a __weak definition, plus an x86
> >> specific override,
Integrate with the generic SMT support, so that when a CPU is DLPAR
onlined it is brought up with the correct SMT mode.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hotp
Add support for HOTPLUG_SMT, which enables the generic sysfs SMT support
files in /sys/devices/system/cpu/smt, as well as the "nosmt" boot
parameter.
Implement the recently added hooks to allow partial SMT states, allow
any number of threads per core.
Tie the config symbol to HOTPLUG_CPU, which e
As part of the generic HOTPLUG_SMT code, there is support for disabling
secondary SMT threads at boot time, by passing "nosmt" on the kernel
command line.
The way that is implemented is the secondary threads are brought partly
online, and then taken back offline again. That is done to support x86
Add support to the /sys/devices/system/cpu/smt/control interface for
enabling a specified number of SMT threads per core, including partial
SMT states where not all threads are brought online.
The current interface accepts "on" and "off", to enable either 1 or all
SMT threads per core.
This commi
A subsequent patch will enable partial SMT states, ie. when not all SMT
threads are brought online.
To support that, add an arch helper which checks whether a given CPU is
allowed to be brought online depending on how many SMT threads are
currently enabled.
Call the helper from cpu_smt_enable(),
Move the simple exit cases, ie. which don't depend on the value written,
earlier in the function. That makes it clearer that regardless of the
input those states can not be transitioned out of.
That does have a user-visible effect, in that the error returned will
now always be EPERM/ENODEV for tho
A subsequent patch will enable partial SMT states, ie. when not all SMT
threads are brought online.
To support that, add an arch helper to check how many SMT threads are
supported.
To retain existing behaviour, the x86 implementation only allows a
single thread or all threads to be online.
Signe
A subsequent patch will enable partial SMT states, ie. when not all SMT
threads are brought online.
To support that the SMT code needs to know the maximum number of SMT
threads, and also the currently configured number.
The arch code knows the max number of threads, so have the arch code
pass tha
A subsequent patch would like to use the cpuhp_smt_control enum as part
of the interface between generic and arch code.
Currently that leads to circular header dependencies. So split the enum
and related declarations into a separate header.
Signed-off-by: Michael Ellerman
---
arch/x86/include/a
Gaurav Batra writes:
> On 5/17/23 7:19 AM, Michael Ellerman wrote:
>> Gaurav Batra writes:
>>> Hello Michael,
>>>
>>> System test hit the crash. I believe, it was PHYP that resulted in it
>>> due to number of TCEs passed in to be >512.
>> OK. It's always good to spell out in the change log whethe
Bagas Sanjaya writes:
> On 5/24/23 17:58, Bagas Sanjaya wrote:
>> Anyway, I'm adding it to regzbot:
>>
>> #regzbot introduced: 23baf831a32c04f
>> https://bugzilla.kernel.org/show_bug.cgi?id=217477
>> #regzbot title: Allocator MAX_ORDER exceeds SECTION_SIZE caused by MAX_ORDER
>> redefinition
>>
On 5/24/23 02:29, David Rientjes wrote:
> On Tue, 23 May 2023, Vlastimil Babka wrote:
>
>> As discussed at LSF/MM [1] [2] and with no objections raised there,
>> deprecate the SLAB allocator. Rename the user-visible option so that
>> users with CONFIG_SLAB=y get a new prompt with explanation durin
On Fri 2023-05-19 10:18:37, Douglas Anderson wrote:
> The fact that there watchdog_hardlockup_enable(),
> watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
> declared __weak means that the configured hardlockup detector can
> define non-weak versions of those functions if it needs
On 5/24/23 20:11, Doru Iorgulescu wrote:
> Glad to hear it!
> Thank you
tl;dr:
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing
On Fri 2023-05-19 10:18:36, Douglas Anderson wrote:
> Do a search and replace of:
> - NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED
> - SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED
> - watchdog_nmi_ => watchdog_hardlockup_
> - nmi_watchdog_available => watchdog_hardlockup_available
> -
On Fri 2023-05-19 10:18:35, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector, which wants the same
> petting logic as the current perf hardlockup detector, move the code
> to watchdog.c. While doing this, rename the global variable to match
> others nearby. As part of this
On 5/24/23 17:58, Bagas Sanjaya wrote:
> Anyway, I'm adding it to regzbot:
>
> #regzbot introduced: 23baf831a32c04f
> https://bugzilla.kernel.org/show_bug.cgi?id=217477
> #regzbot title: Allocator MAX_ORDER exceeds SECTION_SIZE caused by MAX_ORDER
> redefinition
>
>From bugzilla [1], the repor
On 24 May 2023, at 6:58, Bagas Sanjaya wrote:
> Hi,
>
> I notice a powerpc[64?] build regression on Bugzilla [1]. Quoting from it:
>
>> CC arch/powerpc/kernel/asm-offsets.s
>> In file included from ./include/linux/gfp.h:7,
>> from ./include/linux/xarray.h:15,
>>
On Tue 2023-05-23 09:34:37, Doug Anderson wrote:
> Hi,
>
> On Tue, May 23, 2023 at 9:02 AM Petr Mladek wrote:
> >
> > On Fri 2023-05-19 10:18:34, Douglas Anderson wrote:
> > > In preparation for the buddy hardlockup detector where the CPU
> > > checking for lockup might not be the currently runni
Hi,
I notice a powerpc[64?] build regression on Bugzilla [1]. Quoting from it:
> CC arch/powerpc/kernel/asm-offsets.s
> In file included from ./include/linux/gfp.h:7,
> from ./include/linux/xarray.h:15,
> from ./include/linux/list_lru.h:14,
>
On Fri, May 19, 2023 at 03:33:34PM -0700, Randy Dunlap wrote:
> Fix build warnings when DEBUG_FS is not enabled by using an empty
> do-while loop instead of a value:
>
> In file included from ../drivers/crypto/nx/nx.c:27:
> ../drivers/crypto/nx/nx.c: In function 'nx_register_algs':
> ../drivers/cr
On Wed, May 24, 2023 at 03:44:59PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed to boot like this:
>
> Built 1 zonelists, mobility grouping on. Total pages: 32736
> Policy zone: Normal
> mem auto-init
33 matches
Mail list logo
