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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
---
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
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
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
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
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
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
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':
>
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
This performs lazy tlb mm shootdown when doing the exit TLB flush when
all mm users go away and user mappings are removed, which avoids having
to do the lazy tlb mm shootdown IPIs on the final mmput when all kernel
references disappear.
powerpc/64s uses a broadcast TLBIE for the exit TLB flush if
When context switching away from an mm, add a CONFIG_DEBUG_VM warning
check to ensure this CPU is still set in the mask. This could catch
bugs where the mask is improperly trimmed while the CPU is still using
the mm.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/mmu_context.c | 7 +--
Avoid open-coded atomic_dec on mm->context.active_cpus and use the
function made for it. Add CONFIG_DEBUG_VM underflow checking on the
counter.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
arch/powerpc/include/asm/mmu_context.h | 1 +
init_mm mm_cpumask and context.active_cpus is not maintained at boot
and hotplug. This seems to be harmless because init_mm does not have a
userspace and so never gets user TLBs flushed, but it looks odd and it
prevents some sanity checks being added.
Signed-off-by: Nicholas Piggin
---
In the process of doing patch 4, I found a few things we could improve
and tighten up with mm_cpumask handling, so added those first. They're
mostly just debugging, no real fixes or dependency on patch 4 there.
Thanks,
Nick
Nicholas Piggin (4):
powerpc: Account mm_cpumask and active_cpus in
Switching a kernel thread using a "lazy tlb mm" to init_mm is a
relatively common sequence that is not quite trivial. Consolidate this
into a function.
This fixes a bug in do_shoot_lazy_tlb() for any arch that implements
finish_arch_post_lock_switch(). None select MMU_LAZY_TLB_SHOOTDOWN at
the
CPU unplug first calls __cpu_disable(), and that's where powerpc calls
cleanup_cpu_mmu_context(), which clears this CPU from mm_cpumask() of
all mms in the system.
However this CPU may still be using a lazy tlb mm, and its mm_cpumask
bit will be cleared from it. The CPU does not switch away from
40 matches
Mail list logo
