On Fri, Apr 12, 2024 at 02:36:25PM +1000, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Hi all,
> >
> > The following commit is also in the powerpc-fixes tree as a different
> > commit (but the same patch):
> >
> > 156539fd6501 ("Documentation: embargoed-hardware-issues.rst: Add myself
On Fri, Apr 12, 2024 at 11:38:48AM +0800, li.ha...@zte.com.cn wrote:
> From: Li Hao
>
> Cancel the do_wakeup flag in hvc_struct, and change it to immediately
> wake up tty when hp->n_outbuf is 0 in hvc_push().
>
> When we receive a key input character, the interrupt handling function
>
Stephen Rothwell writes:
> Hi all,
>
> The following commit is also in the powerpc-fixes tree as a different
> commit (but the same patch):
>
> 156539fd6501 ("Documentation: embargoed-hardware-issues.rst: Add myself for
> Power")
>
> This is commit
>
> 36627111b568 ("Documentation:
From: Li Hao
Cancel the do_wakeup flag in hvc_struct, and change it to immediately
wake up tty when hp->n_outbuf is 0 in hvc_push().
When we receive a key input character, the interrupt handling function
hvc_handle_interrupt() will be executed, and the echo thread
flush_to_ldisc() will be added
sorry,the patch seems to be corrupt,I will resubmit the patch
--Original--
From: gregkh
To: li hao10307857;
Cc: jirislaby ;linuxppc-dev
;linux-kernel ;
Date: 2024/04/11 22:03
Subject: Re: [PATCH] tty: hvc: wakeup hvc console immediately when needed
On Thu,
On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote:
>
> On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 03:11, Samuel Holland
> > wrote:
> >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> >> > Samuel Holland writes:
> >>
> >> >> The short-term fix would
From: Li Hao
Cancel the do_wakeup flag in hvc_struct, and change it to immediately
wake up tty when hp->n_outbuf is 0 in hvc_push().
When we receive a key input character, the interrupt handling function
hvc_handle_interrupt() will be executed, and the echo thread
flush_to_ldisc() will be added
Hi all,
The following commit is also in the powerpc-fixes tree as a different
commit (but the same patch):
156539fd6501 ("Documentation: embargoed-hardware-issues.rst: Add myself for
Power")
This is commit
36627111b568 ("Documentation: embargoed-hardware-issues.rst: Add myself for
Hi Mike.
On Thu, Apr 11, 2024 at 07:00:42PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Several architectures override module_alloc() only to define address
> range for code allocations different than VMALLOC address space.
>
> Provide a generic implementation in execmem that
On Thu, Apr 11, 2024 at 07:00:36PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Since v3 I looked into making execmem more of an utility toolbox, as we
> discussed at LPC with Mark Rutland, but it was getting more hairier than
> having a struct describing architecture
On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace,
On 08/04/2024 18.06, Nico Boehr wrote:
Quoting Nicholas Piggin (2024-04-05 10:35:07)
The migration harness is complicated and easy to break so CI will
be helpful.
Signed-off-by: Nicholas Piggin
---
.gitlab-ci.yml | 32 +++-
s390x/unittests.cfg | 8
On Thu, Apr 11, 2024 at 06:55:44PM +0200, Paolo Bonzini wrote:
> On Mon, Apr 8, 2024 at 3:56 PM Peter Xu wrote:
> > Paolo,
> >
> > I may miss a bunch of details here (as I still remember some change_pte
> > patches previously on the list..), however not sure whether we considered
> > enable it?
On Thu, Apr 11, 2024 at 07:00:36PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Since v3 I looked into making execmem more of an utility toolbox, as we
> discussed at LPC with Mark Rutland, but it was getting more hairier than
> having a struct describing architecture
On Wed, Apr 10, 2024 at 11:30 PM Andrew Morton
wrote:
> On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> > Please review! Also feel free to take the KVM patches through the mm
> > tree, as I don't expect any conflicts.
>
> It's mainly a KVM thing and the MM changes are small and
On Mon, Apr 8, 2024 at 3:56 PM Peter Xu wrote:
> Paolo,
>
> I may miss a bunch of details here (as I still remember some change_pte
> patches previously on the list..), however not sure whether we considered
> enable it? Asked because I remember Andrea used to have a custom tree
> maintaining
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> > This series reimplements hugepages with hugepd on powerpc 8xx.
> >
> > Unlike most architectures, powerpc 8xx HW requires a two-level
> > pagetable topology for
From: "Mike Rapoport (IBM)"
Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module
text allocations.
Signed-off-by: Mike Rapoport (IBM)
---
arch/x86/mm/init.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/init.c
From: "Mike Rapoport (IBM)"
Using large pages to map text areas reduces iTLB pressure and improves
performance.
Extend execmem_alloc() with an ability to use PMD_SIZE'ed pages with ROX
permissions as a cache for smaller allocations.
To populate the cache, a writable large page is allocated
From: "Mike Rapoport (IBM)"
When module text memory will be allocated with ROX permissions, the
memory at the actual address where the module will live will contain
invalid instructions and there will be a writable copy that contains the
actual module code.
Update relocations and alternatives
From: Song Liu
ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
ftrace_swap_func so that archs can use RO-memory-poke function to do the
sorting.
Signed-off-by: Song Liu
Signed-off-by: Mike Rapoport (IBM)
---
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c |
From: "Mike Rapoport (IBM)"
In order to support ROX allocations for module text, it is necessary to
handle modifications to the code, such as relocations and alternatives
patching, without write access to that memory.
One option is to use text patching, but this would make module loading
From: "Mike Rapoport (IBM)"
vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explictly
specify node ID will use huge pages only if size_per_node is larger than
PMD_SIZE.
Still the actual allocated memory is not distributed between nodes and
there is no advantage in such approach.
On the
From: "Mike Rapoport (IBM)"
Several architectures support text patching, but they name the header
files that declare patching functions differently.
Make all such headers consistently named text-patching.h and add an empty
header in asm-generic for architectures that do not support text
From: "Mike Rapoport (IBM)"
Hi,
These patches add support for using large ROX pages for allocations of
executable memory on x86.
They address Andy's comments [1] about having executable mappings for code
that was not completely formed.
The approach taken is to allocate ROX memory along with
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules,
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 2 +-
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As powerpc uses
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Slightly reorder execmem_params initialization to support both 32 and
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF ranges in
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocation of KASAN
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignment and page
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code allocation to the
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
---
kernel/module/main.c | 64 +++-
1 file changed, 39 insertions(+), 25
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
Acked-by:
From: "Mike Rapoport (IBM)"
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/mips/kernel/module.c | 4 ++--
arch/mips/mm/fault.c
From: "Mike Rapoport (IBM)"
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan_alloc_module_shadow() will
From: "Mike Rapoport (IBM)"
Hi,
Since v3 I looked into making execmem more of an utility toolbox, as we
discussed at LPC with Mark Rutland, but it was getting more hairier than
having a struct describing architecture constraints and a type identifying
the consumer of execmem.
And I do think
On Thu, Apr 11, 2024 at 09:15:03AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Mar 05, 2024 at 05:26:57PM +0100, Uwe Kleine-König wrote:
> > this series converts all drivers below drivers/char/ipmi to struct
> > platform_driver::remove_new(). See commit 5c5a7680e67b ("platform: Provide a
On Thu, Apr 11, 2024 at 09:50:17PM +0800, li.ha...@zte.com.cn wrote:
> From: Li Hao
>
> Cancel the do_wakeup flag in hvc_struct, and change it to immediately
> wake up tty when hp->n_outbuf is 0 in hvc_push().
>
> When we receive a key input character, the interrupt handling function
>
On Thu, Apr 11, 2024 at 03:07:46PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 06, 2024 at 03:52:00PM +0200, Lukas Wunner wrote:
> > For my upcoming PCI device authentication v2 patches, I have the need
> > to expose a simple buffer in virtual memory as a bin_attribute.
> >
> > It turns out
On Sat, Apr 06, 2024 at 03:52:00PM +0200, Lukas Wunner wrote:
> For my upcoming PCI device authentication v2 patches, I have the need
> to expose a simple buffer in virtual memory as a bin_attribute.
>
> It turns out we've duplicated the ->read() callback for such simple
> buffers a fair number
On Sat, Apr 06, 2024 at 03:52:01PM +0200, Lukas Wunner wrote:
> When drivers expose a bin_attribute in sysfs which is backed by a buffer
> in memory, a common pattern is to set the @private and @size members in
> struct bin_attribute to the buffer's location and size.
>
> The ->read() callback
On Wed, Apr 10, 2024, at 06:54, Christophe Leroy wrote:
> Le 19/02/2024 à 16:30, Vladimir Oltean a écrit :
>> On Thu, Feb 15, 2024 at 11:23:26AM -0500, Sean Anderson wrote:
>>> smp_call_function_single disables IRQs when executing the callback. To
>>> prevent deadlocks, we must disable IRQs when
>>
>> I confirm the error goes away with the following change to next-20240411
>> on powerpc tinyconfig with gcc 13.2
>>
>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> index 4e18db1819f8..3d5ac0cdd721 100644
>> --- a/kernel/time/
From: Adrian Hunter
> Sent: 11 April 2024 10:04
>
> On 11/04/24 10:56, Arnd Bergmann wrote:
> > On Thu, Apr 11, 2024, at 09:16, Adrian Hunter wrote:
> >> On 11/04/24 10:04, Arnd Bergmann wrote:
> >>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
> BUG() does not return, and arch
gt; message.
>>>>
>>>> Do you know which compiler version show the warning above?
>>>
>>> Original report has a list
>>>
>>>
>>> https://lore.kernel.org/all/CA+G9fYvjdZCW=7zgxs6a_3bysjq56yf7s-+pnlq_8a4dkh1...@mai
On 11/04/24 10:56, Arnd Bergmann wrote:
> On Thu, Apr 11, 2024, at 09:16, Adrian Hunter wrote:
>> On 11/04/24 10:04, Arnd Bergmann wrote:
>>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
BUG() does not return, and arch implementations of BUG() use unreachable()
or other
hrow out the entire code path leading up to it and just
>>> run into undefined behavior instead of printing a BUG()
>>> message.
>>>
>>> Do you know which compiler version show the warning above?
>>
>> Original report has a list
>>
>>
>&g
Le 11/04/2024 à 09:16, Adrian Hunter a écrit :
> On 11/04/24 10:04, Arnd Bergmann wrote:
>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
>>> BUG() does not return, and arch implementations of BUG() use unreachable()
>>> or other non-returning code. However with !CONFIG_BUG, the default
On Thu, Apr 11, 2024, at 09:16, Adrian Hunter wrote:
> On 11/04/24 10:04, Arnd Bergmann wrote:
>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
>>> BUG() does not return, and arch implementations of BUG() use unreachable()
>>> or other non-returning code. However with !CONFIG_BUG, the
When the watchdog determines that the current soft lockup is due
to an interrupt storm based on CPU utilization, reporting the
most frequent interrupts could be good enough for further
troubleshooting.
Below is an example of interrupt storm. The call tree does not
provide useful information, but
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call
show_interrupts() unconditionally accumulates the per CPU interrupt
statistics to determine whether an interrupt was ever raised.
This can be avoided for all interrupts which are not strictly per CPU
and not of type NMI because those interrupts provide already an
accumulated counter. The required
The soft lockup detector lacks a mechanism to identify interrupt storms
as root cause of a lockup. To enable this the detector needs a
mechanism to snapshot the interrupt count statistics on a CPU when the
detector observes a potential lockup scenario and compare that against
the interrupt count
Hi, guys.
I have implemented a low-overhead method for detecting interrupt
storm in softlockup. Please review it, all comments are welcome.
Changes from v12 to v13:
- Update patch #1 based on the latest kernel code.
- From Thomas, split patch #1 into two. The new patch #1 converts
kstat_irqs
The irq_desc::kstat_irqs member is a per-CPU variable of type int, and
it is only capable of counting. The snapshot mechanism for interrupt
statistics will be added soon, which requires an additional variable to
store snapshot. To facilitate expansion, convert kstat_irqs here to
a struct
On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> On Thu, 11 Apr 2024 at 03:11, Samuel Holland
> wrote:
>> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
>> > Samuel Holland writes:
>>
>> >> The short-term fix would be to drop the `select
>> >> ARCH_HAS_KERNEL_FPU_SUPPORT` for
>> >>
On 11/04/24 10:04, Arnd Bergmann wrote:
> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
>> BUG() does not return, and arch implementations of BUG() use unreachable()
>> or other non-returning code. However with !CONFIG_BUG, the default
>> implementation is often used instead, and that does
(cc Arnd)
On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote:
>
> Hi Thiago,
>
> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> > Samuel Holland writes:
> >> On 2024-04-10 5:21 PM, Thiago Jung Bauermann wrote:
> >>>
> >>> Unfortunately this patch causes build failures on arm with
Hello,
On Tue, Mar 05, 2024 at 05:26:57PM +0100, Uwe Kleine-König wrote:
> this series converts all drivers below drivers/char/ipmi to struct
> platform_driver::remove_new(). See commit 5c5a7680e67b ("platform: Provide a
> remove callback that returns no value") for an extended explanation and
On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
> BUG() does not return, and arch implementations of BUG() use unreachable()
> or other non-returning code. However with !CONFIG_BUG, the default
> implementation is often used instead, and that does not do that. x86 always
> uses its own
65 matches
Mail list logo
