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]:
>
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 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
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
>
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
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
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
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
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:
>
>
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
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().
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()
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
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
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
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
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
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
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
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
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
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:
+-
2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: d7bf73809849463f76de42aad62c850305dd6c5d
change-id: 20240214-bus_cleanup-alsa-1d05ffc6507b
Best regards,
--
Ricardo B. Marliere
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.
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
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 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
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
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
>
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
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
+++
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 =
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
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=170737160630106=2
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=170737160630106=2
Please use lore for links, in this case:
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
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
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:
> > >
> > >
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
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
> >
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
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
>
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
43 matches
Mail list logo
