nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper whi
Le 14/02/2024 à 10:16, Mahesh Salgaonkar a écrit :
> [Vous ne recevez pas souvent de courriers de mah...@linux.ibm.com. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
> crash
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper whi
From: Segher Boessenkool
> Sent: 13 February 2024 19:13
>
> On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> > clang warns about explicitly casting between incompatible function
> > pointers:
> >
> > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void
> > *)'
Le 14/02/2024 à 10:51, Mahesh Salgaonkar a écrit :
> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
> crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
> interrupt handler) if percpu allocation comes from vmalloc area.
>
> Early HMI/MCE handler
On Wed, Feb 14, 2024 at 09:46:33AM +, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 13 February 2024 19:13
> >
> > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> > > clang warns about explicitly casting between incompatible function
> > > pointers:
> > >
> > > driv
On Wed, Feb 14, 2024 at 09:47:54AM +0530, Kishon Vijay Abraham I wrote:
> Hi Niklas,
>
> On 2/10/2024 6:56 AM, Niklas Cassel wrote:
> > The series is based on top of:
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint
> >
> >
> > Hello all,
> >
> > This series clean
On Wed, Feb 14, 2024 at 11:37:21AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 14, 2024 at 09:46:33AM +, David Laight wrote:
> > From: Segher Boessenkool
> > > Sent: 13 February 2024 19:13
> > >
> > > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> > > > clang warns about e
Venkat Rao Bagalkote writes:
> Thanks for the patch. Applied this patch and verified and issue is fixed.
>
> This issue way originally reported in the below mail.
>
> https://marc.info/?l=linux-kernel&m=170737160630106&w=2
Please use lore for links, in this case:
https://lore.kernel.org/all/274e
On Wed, Feb 14, 2024 at 11:53:20PM +1100, Michael Ellerman wrote:
> Venkat Rao Bagalkote writes:
> > Thanks for the patch. Applied this patch and verified and issue is fixed.
> >
> > This issue way originally reported in the below mail.
> >
> > https://marc.info/?l=linux-kernel&m=170737160630106&w
Aneesh Kumar K.V writes:
> Michael Ellerman writes:
>
>
>
>> +static int assign_threads(unsigned cpu, unsigned int nthreads, bool avail,
>>
>
> May be rename 'avail' to 'present'
Yeah, will do.
cheers
>> + const __be32 *hw_ids)
>> +{
>> +for (int i = 0; i <
Jiri Bohac writes:
> On Tue, Jan 02, 2024 at 10:16:04AM +0530, Aneesh Kumar K.V wrote:
>> Michael Ellerman writes:
>>
>>
>>
>> > #ifdef CONFIG_PPC64
>> > int boot_cpu_hwid = -1;
>> > @@ -492,12 +493,26 @@ void __init smp_setup_cpu_maps(void)
>> >avail = !of_property_m
On 13/02/24 08:51, Baoquan He wrote:
On 02/12/24 at 07:27pm, Sourabh Jain wrote:
Hello Baoquan,
On 05/02/24 08:40, Baoquan He wrote:
Hi Sourabh,
..
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 802052d9c64b..7880d74dc5c4 100644
--- a/include/linux/kexec.h
+++ b/inc
From: Palmer Dabbelt
The new SBI console has the same problem as the old one: there's only
one shared backing hardware and no synchronization, so the two drivers
end up stepping on each other. This was the same issue the old SBI-0.1
console drivers had, but that was disabled by default when SBI-
On Wed, 14 Feb 2024, Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> The new SBI console has the same problem as the old one: there's only
> one shared backing hardware and no synchronization, so the two drivers
> end up stepping on each other. This was the same issue the old SBI-0.1
> console
On Wed, Feb 14, 2024 at 9:06 PM Palmer Dabbelt wrote:
>
> From: Palmer Dabbelt
>
> The new SBI console has the same problem as the old one: there's only
> one shared backing hardware and no synchronization, so the two drivers
> end up stepping on each other. This was the same issue the old SBI-0
On Wed, Feb 14, 2024 at 07:34:30AM -0800, Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> The new SBI console has the same problem as the old one: there's only
> one shared backing hardware and no synchronization, so the two drivers
> end up stepping on each other. This was the same issue the o
The function spapr_tce_platform_iommu_attach_dev() is missing to call
iommu_group_put() when the domain is already set. This refcount leak
shows up with BUG_ON() during DLPAR remove operation as,
KernelBug: Kernel bug in state 'None': kernel BUG at
arch/powerpc/platforms/pseries/iommu.c:100!
On Wed, Feb 14, 2024 at 12:09:24PM -0600, Shivaprasad G Bhat wrote:
> The function spapr_tce_platform_iommu_attach_dev() is missing to call
> iommu_group_put() when the domain is already set. This refcount leak
> shows up with BUG_ON() during DLPAR remove operation as,
>
> KernelBug: Kernel bug
On 2/14/24 18:28, Jason Gunthorpe wrote:
On Wed, Feb 14, 2024 at 11:53:20PM +1100, Michael Ellerman wrote:
Venkat Rao Bagalkote writes:
Thanks for the patch. Applied this patch and verified and issue is fixed.
This issue way originally reported in the below mail.
https://marc.info/?l=linux
+-
2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: d7bf73809849463f76de42aad62c850305dd6c5d
change-id: 20240214-bus_cleanup-alsa-1d05ffc6507b
Best regards,
--
Ricardo B. Marliere
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the soundbus_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the snd_seq_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
This series is based on [1]. Similar to what we did with fork(), let's
implement PTE batching during unmap/zap when processing PTE-mapped THPs.
We collect consecutive PTEs that map consecutive pages of the same large
folio, making sure that the other PTE bits are compatible, and (a) adjust
the ref
Let's prepare for further changes by factoring out processing of present
PTEs.
Reviewed-by: Ryan Roberts
Signed-off-by: David Hildenbrand
---
mm/memory.c | 94 ++---
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/mm/memory.c b/mm/
We don't need up-to-date accessed-dirty information for anon folios and can
simply work with the ptent we already have. Also, we know the RSS counter
we want to update.
We can safely move arch_check_zapped_pte() + tlb_remove_tlb_entry() +
zap_install_uffd_wp_if_needed() after updating the folio an
Let's prepare for further changes by factoring it out into a separate
function.
Reviewed-by: Ryan Roberts
Signed-off-by: David Hildenbrand
---
mm/memory.c | 53 -
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/mm/memory.c b/mm
We have two bits available in the encoded page pointer to store
additional information. Currently, we use one bit to request delay of the
rmap removal until after a TLB flush.
We want to make use of the remaining bit internally for batching of
multiple pages of the same folio, specifying that the
Nowadays, encoded pages are only used in mmu_gather handling. Let's
update the documentation, and define ENCODED_PAGE_BIT_DELAY_RMAP. While at
it, rename ENCODE_PAGE_BITS to ENCODED_PAGE_BITS.
If encoded page pointers would ever be used in other context again, we'd
likely want to change the define
Let's add a helper that lets us batch-process multiple consecutive PTEs.
Note that the loop will get optimized out on all architectures except on
powerpc. We have to add an early define of __tlb_remove_tlb_entry() on
ppc to make the compiler happy (and avoid making tlb_remove_tlb_entries() a
macro
Add __tlb_remove_folio_pages(), which will remove multiple consecutive
pages that belong to the same large folio, instead of only a single
page. We'll be using this function when optimizing unmapping/zapping of
large folios that are mapped by PTEs.
We're using the remaining spare bit in an encoded
In tlb_batch_pages_flush(), we can end up freeing up to 512 pages or
now up to 256 folio fragments that span more than one page, before we
conditionally reschedule.
It's a pain that we have to handle cond_resched() in
tlb_batch_pages_flush() manually and cannot simply handle it in
release_pages()
Similar to how we optimized fork(), let's implement PTE batching when
consecutive (present) PTEs map consecutive pages of the same large
folio.
Most infrastructure we need for batching (mmu gather, rmap) is already
there. We only have to add get_and_clear_full_ptes() and
clear_full_ptes(). Similar
We don't need uptodate accessed/dirty bits, so in theory we could
replace ptep_get_and_clear_full() by an optimized ptep_clear_full()
function. Let's rely on the provided pte.
Further, there is no scenario where we would have to insert uffd-wp
markers when zapping something that is not a normal pa
Hi
On Mon, 12 Feb 2024 12:19:04 +0100, Arnd Bergmann wrote:
> On powerpc, it is possible to compile test both the new apple (arm) and
> old pasemi (powerpc) drivers for the i2c hardware at the same time,
> which leads to a warning about linking the same object file twice:
>
> scripts/Makefile.bui
Rahul Rameshbabu writes:
> On Fri, 15 Dec, 2023 23:44:49 +1100 Michael Ellerman
> wrote:
>> There are reports of kernels crashing due to stack overflow while
>> running OpenShift (Kubernetes). The primary contributor to the stack
>> usage seems to be openvswitch, which is used by OVN-Kubernetes
Changes from v1:
- Add Acked-by lines.
The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
access by the __builtin_cpu_supports built-in function. The TCB space for
the HWCAP entries - which are created in pairs - is an ABI extension, so
waiting to create the space for H
On 29.01.24 13:46, David Hildenbrand wrote:
We already read it, let's just forward it.
This patch is based on work by Ryan Roberts.
Reviewed-by: Ryan Roberts
Signed-off-by: David Hildenbrand
---
mm/memory.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/memor
On Fri, 15 Dec, 2023 23:44:49 +1100 Michael Ellerman
wrote:
> There are reports of kernels crashing due to stack overflow while
> running OpenShift (Kubernetes). The primary contributor to the stack
> usage seems to be openvswitch, which is used by OVN-Kubernetes (based on
> OVN (Open Virtual Net
Shivaprasad G Bhat writes:
> The function spapr_tce_platform_iommu_attach_dev() is missing to call
> iommu_group_put() when the domain is already set. This refcount leak
> shows up with BUG_ON() during DLPAR remove operation as,
>
> KernelBug: Kernel bug in state 'None': kernel BUG at
> arch/po
On 2/13/24 20:14, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20240213:
>
on powerpc64:
when CONFIG_IOMMU_API is not set.
powerpc64-linux-ld: arch/powerpc/platforms/pseries/pci_dlpar.o: in function
`init_phb_dynamic':
pci_dlpar.c:(.text+0xc4): undefined reference to `ppc_iommu_regis
Randy Dunlap writes:
> On 2/13/24 20:14, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20240213:
>>
>
> on powerpc64:
> when CONFIG_IOMMU_API is not set.
>
>
> powerpc64-linux-ld: arch/powerpc/platforms/pseries/pci_dlpar.o: in function
> `init_phb_dynamic':
> pci_dlpar.c:(.text+0xc4):
On Wed, Feb 14, 2024 at 04:28:27PM -0300, Ricardo B. Marliere wrote:
> This series is part of an effort to cleanup the users of the driver
> core, as can be seen in many recent patches authored by Greg across the
> tree (e.g. [1]).
>
> ---
> [1]:
> https://lore.kernel.org/lkml/?q=f%3Agregkh%40lin
43 matches
Mail list logo
