[PATCH v2 0/3] mm: Fix apply_to_pte_range() vs lazy MMU mode

Hi All, Chages since v1: - left fixes only, improvements will be posted separately; - Fixes: and -stable tags added to patch descriptions; This series is an attempt to fix the violation of lazy MMU mode context requirement as described for arch_enter_lazy_mmu_mode(): This mode can only be en

Re: [PATCH v2 02/12] x86: pgtable: Always use pte_free_kernel()

On 4/8/25 10:40, Matthew Wilcox wrote: > I think at this point in Kevin's series, we don't call the ctor for > these pages, so we never set PageTable() on them. I could be wrong; > as Kevin says, this is all very twisty and confusing with exceptions and > exceptions to exceptions. This series sho

Re: [PATCH v2 02/12] x86: pgtable: Always use pte_free_kernel()

On Tue, Apr 08, 2025 at 09:54:42AM -0700, Dave Hansen wrote: > On 4/8/25 09:37, Matthew Wilcox wrote: > > On Tue, Apr 08, 2025 at 08:22:47AM -0700, Dave Hansen wrote: > >> Are there any tests for folio_test_pgtable() at free_page() time? If we > >> had that, it would make it less likely that anothe

Re: [PATCH v2 02/12] x86: pgtable: Always use pte_free_kernel()

On 4/8/25 09:37, Matthew Wilcox wrote: > On Tue, Apr 08, 2025 at 08:22:47AM -0700, Dave Hansen wrote: >> Are there any tests for folio_test_pgtable() at free_page() time? If we >> had that, it would make it less likely that another free_page() user >> could sneak in without calling the destructor.

[PATCH v2 3/3] mm: Protect kernel pgtables in apply_to_pte_range()

The lazy MMU mode can only be entered and left under the protection of the page table locks for all page tables which may be modified. Yet, when it comes to kernel mappings apply_to_pte_range() does not take any locks. That does not conform arch_enter|leave_lazy_mmu_mode() semantics and could poten

[PATCH v2 2/3] mm: Cleanup apply_to_pte_range() routine

Reverse 'create' vs 'mm == &init_mm' conditions and move page table mask modification out of the atomic context. This is a prerequisite for fixing missing kernel page tables lock. Cc: sta...@vger.kernel.org Fixes: 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") Signed-off-b

Re: [PATCH v2 2/4] tpm: support devices with synchronous send()

On Tue, Apr 08, 2025 at 10:32:06AM +0200, Stefano Garzarella wrote: > From: Stefano Garzarella > > Some devices do not support interrupts and provide a single synchronous > operation to send the command and receive the response on the same buffer. > > Currently, these types of drivers must use a

Re: [PATCH v2 02/12] x86: pgtable: Always use pte_free_kernel()

On 4/8/25 02:52, Kevin Brodsky wrote: > Page table pages are normally freed using the appropriate helper for > the given page table level. On x86, pud_free_pmd_page() and > pmd_free_pte_page() are an exception to the rule: they call > free_page() directly. > > Constructor/destructor calls are abou

Re: [RFC net-next PATCH 00/13] Add PCS core support

On 4/7/25 13:25, Daniel Golle wrote: > On Mon, Apr 07, 2025 at 07:21:38PM +0200, Christian Marangi (Ansuel) wrote: >> Il giorno lun 7 apr 2025 alle ore 19:00 Sean Anderson >> > I agree that a "cells" approach would require this, but >> > >> > - There are no in-tree examples of where this is necessa

Re: [kvm-unit-tests PATCH v2] Makefile: Use CFLAGS in cc-option

On Fri, Mar 07, 2025 at 10:18:29AM +0100, Andrew Jones wrote: > When cross compiling with clang we need to specify the target in > CFLAGS and cc-option will fail to recognize target-specific options > without it. Add CFLAGS to the CC invocation in cc-option. > > The introduction of the realmode_bi

[PATCH 4/6] bus: fsl-mc: add the dprc_get_mem() command to the whitelist

Add a new MC command to the list of accepted firmware commands. The DPRC_GET_MEM command can be used to gather information on the internal memory characteristics. Signed-off-by: Ioana Ciornei --- drivers/bus/fsl-mc/fsl-mc-uapi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/

Re: [PATCH] soc: fsl: Do not enable DPAA2_CONSOLE by default during compile testing

On Fri, Apr 04, 2025 at 01:24:07PM +0200, Krzysztof Kozlowski wrote: > Enabling the compile test should not cause automatic enabling of such > drivers. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Ioana Ciornei

[PATCH 3/6] bus: fsl-mc: fix GET/SET_TAILDROP command ids

From: Wan Junjie Command ids for taildrop get/set can not pass the check when they are using from the restool user space utility. Correct them according to the user manual. Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl") Signed-off-by: Wan Junjie Signed-of

Re: [RFC net-next PATCH 00/13] Add PCS core support

On 4/7/25 13:21, Christian Marangi (Ansuel) wrote: > Il giorno lun 7 apr 2025 alle ore 19:00 Sean Anderson > ha scritto: >> >> On 4/7/25 12:46, Christian Marangi (Ansuel) wrote: >> > Il giorno lun 7 apr 2025 alle ore 18:33 Sean Anderson >> > ha scritto: >> >> >> >> On 4/7/25 12:27, Kory Maincent

Re: [PATCH 0/4] ASoC: fsl_sai: add several improvements

On Fri, 28 Mar 2025 16:57:40 +0800, Shengjiu Wang wrote: > Add several improvements for the sai interface. > 1.allow to set mclk rate with zero clk_id for master mode > 2.add xlate_tdm_slot_mask() callback to avoid channel constrain > 3.separate 'is_dsp_mode' for tx and rx > 4.separate set_tdm_slot

[PATCH v2 01/12] mm: Pass mm down to pagetable_{pte,pmd}_ctor

In preparation for calling constructors for all kernel page tables while eliding unnecessary ptlock initialisation, let's pass down the associated mm to the PTE/PMD level ctors. (These are the two levels where ptlocks are used.) In most cases the mm is already around at the point of calling the ct

[PATCH v2 02/12] x86: pgtable: Always use pte_free_kernel()

Page table pages are normally freed using the appropriate helper for the given page table level. On x86, pud_free_pmd_page() and pmd_free_pte_page() are an exception to the rule: they call free_page() directly. Constructor/destructor calls are about to be introduced for kernel PTEs. To avoid missi

[PATCH 5/6] bus: fsl-mc: drop useless cleanup

From: Laurentiu Tudor This cleanup is actually a no-op because the resources are freed when the device objects are removed from the allocator at driver remove time. Remove the fsl_mc_cleanup_all_resource_pools() function and its call site. Signed-off-by: Laurentiu Tudor Signed-off-by: Ioana Cio

[PATCH 0/6] bus: fsl-mc: cleanup and fixes

This patch set is a combination of small fixes and some cleanup. Some of the patches were already submitted in the past years but were lost in the process due to an uncertain maintenance path. Ioana Ciornei (3): bus: fsl-mc: fix double-free on mc_dev bus: fsl-mc: do not add a device-link for

[PATCH 6/6] bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value

From: Laurentiu Tudor In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more

[PATCH v2 10/12] riscv: mm: Clarify ctor mm argument in alloc_{pte,pmd}_late

pagetable_{pte,pmd}_ctor(mm, ptdesc) skip the ptlock initialisation if mm is &init_mm. To avoid unnecessary overhead, it is therefore preferable to pass the actual mm associated to the PTE/PMD. Unfortunately, this proves challenging for alloc_{pte,pmd}_late() as the associated mm is not available

[PATCH v2 12/12] riscv: mm: Call PUD/P4D ctor in special kernel pgtable alloc

Constructors for PUD/P4D-level pgtables were recently introduced. They should be called for all pgtables; make sure they are called for special kernel mappings created by create_pgd_mapping() too. While at it also switch to using pagetable_alloc() like in alloc_{pte,pmd}_late(). Signed-off-by: Ke

[PATCH v2 11/12] arm64: mm: Call PUD/P4D ctor in __create_pgd_mapping()

Constructors for PUD/P4D-level pgtables were recently introduced. They should be called for all pgtables; make sure they are called for special kernel mappings created by __create_pgd_mapping() too. Signed-off-by: Kevin Brodsky --- arch/arm64/mm/mmu.c | 6 +- 1 file changed, 5 insertions(+),

[PATCH v2 07/12] mm: Skip ptlock_init() for kernel PMDs

Split page table locks are not used for pgtables associated to init_mm, at any level. pte_alloc_kernel() does not call ptlock_init() as a result. There is however no separate alloc/free functions for kernel PMDs, and pmd_ptlock_init() is called unconditionally. When ALLOC_SPLIT_PTLOCKS is true (e.g

[PATCH v2 08/12] arm64: mm: Use enum to identify pgtable level instead of *_SHIFT

Commit 90292aca9854 ("arm64: mm: use appropriate ctors for page tables") introduced pgtable ctor calls in pgd_pgtable_alloc(). To identify the pgtable level and call the appropriate ctor, the *_SHIFT value associated with the pgtable level is used. However, those values do not unambiguously identif

[PATCH v2 05/12] powerpc: mm: Call ctor/dtor for kernel PTEs

The generic implementation of pte_{alloc_one,free}_kernel now calls the [cd]tor, without initialising the ptlock needlessly as pagetable_pte_ctor() skips it for init_mm. On powerpc, all functions related to PTE allocation are implemented by common helpers, which are passed a boolean to differentia

[PATCH v2 06/12] sparc64: mm: Call ctor/dtor for kernel PTEs

The generic implementation of pte_{alloc_one,free}_kernel now calls the [cd]tor, without initialising the ptlock needlessly as pagetable_pte_ctor() skips it for init_mm. Align sparc64 with the generic implementation by ensuring pagetable_pte_[cd]tor() are called for kernel PTEs. As a result the ke

[PATCH v2 03/12] mm: Call ctor/dtor for kernel PTEs

Since [1], constructors/destructors are expected to be called for all page table pages, at all levels and for both user and kernel pgtables. There is however one glaring exception: kernel PTEs are managed via separate helpers (pte_alloc_kernel/pte_free_kernel), which do not call the [cd]tor, at lea

[PATCH v2 00/12] Always call constructor for kernel page tables

There has been much confusion around exactly when page table constructors/destructors (pagetable_*_[cd]tor) are supposed to be called. They were initially introduced for user PTEs only (to support split page table locks), then at the PMD level for the same purpose. Accounting was added later on, st

Re: [RFC PATCH] powerpc: Add check to select PPC_RADIX_BROADCAST_TLBIE

Christophe Leroy writes: > Le 07/04/2025 à 21:10, Ritesh Harjani (IBM) a écrit : >> Madhavan Srinivasan writes: >> >>> Commit 3d45a3d0d2e6 ("powerpc: Define config option for processors with >>> broadcast TLBIE") >> >> We may need to add above to Fixes tag as well, no? >> >>> added a config

[PATCH v2 4/4] tpm/tpm_svsm: support TPM_CHIP_FLAG_SYNC

From: Stefano Garzarella This driver does not support interrupts, and receiving the response is synchronous with sending the command. So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and return responses in the same buffer used for commands. This way we don't need to implement recv

[PATCH v2 2/4] tpm: support devices with synchronous send()

From: Stefano Garzarella Some devices do not support interrupts and provide a single synchronous operation to send the command and receive the response on the same buffer. Currently, these types of drivers must use an internal buffer where they temporarily store the response between .send() and

[PATCH v2 0/4] tpm: add support for sync send() and use it in ftpm and svsm drivers

This series is a follow-up to the discussion we had about whether or not to add send_recv() op in tpm_class_ops[1]. Much boilerplate code has already been removed by Jarkko with commit 980a573621ea ("tpm: Make chip->{status,cancel,req_canceled} opt"). With this series we try to avoid also the tempo

[PATCH v2 1/4] tpm: add buf_size parameter in the .send callback

From: Stefano Garzarella In preparation for the next commit, add a new `buf_size` parameter to the `.send` callback in `tpm_class_ops` which contains the entire buffer size. In this patch it is pretty much ignored by all drivers, but it will be used in the next patch. Also rename the previous pa

[PATCH 2/5] powerpc: 83xx/gpio: use new line value setter callbacks

From: Bartosz Golaszewski struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski --- arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 6 -- 1 file changed, 4 inse

[PATCH 5/5] powerpc: 8xx/gpio: use new line value setter callbacks

From: Bartosz Golaszewski struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski --- arch/powerpc/platforms/8xx/cpm1.c | 12 1 file changed, 8 insertions

[PATCH 0/5] powerpc: convert board-file GPIO chips to using new value setters

struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. We're in the process of converting all GPIO drivers to using the new API. This series converts all powerpc board-file level controllers. Signed-off-by: Bartosz Golaszewski --- Barto

Re: [PATCH v2 09/13] arch, mm: set max_mapnr when allocating memory map for FLATMEM

Hi Mike, Le 14/03/2025 à 10:25, Christophe Leroy a écrit : Le 13/03/2025 à 14:49, Mike Rapoport a écrit : From: "Mike Rapoport (Microsoft)" max_mapnr is essentially the size of the memory map for systems that use FLATMEM. There is no reason to calculate it in each and every architecture w