Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov :
On Thu, 19 Jun 2025 16:26:47 +0200 you wrote:
> Without this, the compiler (clang21) might emit a warning under W=1
> because the variable ori31_emitted is set but never used if
> CONFIG_PPC_BOOK3S_64=n.
>
> Witho
From: Eric Biggers
Move the contents of arch/powerpc/lib/crypto/ into lib/crypto/powerpc/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and
From: Eric Biggers
Move the contents of arch/arm/lib/crypto/ into lib/crypto/arm/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dead
co
This series applies on top of
https://lore.kernel.org/r/20250616014019.415791-1-ebigg...@kernel.org/
and is also available in git at:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
arch-to-lib-crypto-v2
This series moves the contents of arch/$(ARCH)/lib/crypto/
From: Eric Biggers
Move the contents of arch/mips/lib/crypto/ into lib/crypto/mips/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dead
From: Eric Biggers
Move the contents of arch/riscv/lib/crypto/ into lib/crypto/riscv/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dea
- Original Message -
> From: "Bjorn Helgaas"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev" , "linux-kernel"
> , "linux-pci"
> , "Madhavan Srinivasan" ,
> "Michael Ellerman" ,
> "christophe leroy" , "Naveen N Rao"
> , "Bjorn Helgaas"
> , "Shawn Anastasio"
> Sent: Wednesday, June 18,
From: Eric Biggers
Move the contents of arch/s390/lib/crypto/ into lib/crypto/s390/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dead
From: Eric Biggers
Since all files arch/*/lib/crypto/* have been moved into lib/crypto/,
remove the arch/*/lib/crypto/ file pattern from MAINTAINERS.
Signed-off-by: Eric Biggers
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a92290fffa163..8c
From: Eric Biggers
Move the contents of arch/arm64/lib/crypto/ into lib/crypto/arm64/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dea
From: Eric Biggers
Move the contents of arch/x86/lib/crypto/ into lib/crypto/x86/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dead
co
From: Eric Biggers
Move the contents of arch/sparc/lib/crypto/ into lib/crypto/sparc/.
The new code organization makes a lot more sense for how this code
actually works and is developed. In particular, it makes it possible to
build each algorithm as a single module, with better inlining and dea
- Original Message -
> From: "Bjorn Helgaas"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev" , "linux-kernel"
> , "linux-pci"
> , "Madhavan Srinivasan" ,
> "Michael Ellerman" ,
> "christophe leroy" , "Naveen N Rao"
> , "Bjorn Helgaas"
> , "Shawn Anastasio" ,
> "Lukas Wunner"
> Sent:
Hi Chancel,
kernel test robot noticed the following build warnings:
[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on linus/master v6.16-rc2 next-20250619]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
The system manager indices names are different for each platform, rename
the indices for i.MX95 to differentiate with other platform.
Signed-off-by: Shengjiu Wang
---
include/linux/firmware/imx/sm.h | 12 ++--
sound/soc/fsl/fsl_mqs.c | 2 +-
2 files changed, 7 insertions(+), 7 d
On i.MX94, the MQS2 also needs to be configured by SCMI interface, add
sm_index variable in struct fsl_mqs_soc_data to distinguish the MQS1 and
MQS2 on this platform.
Add the system manager indices for i.MX94 in the header file.
Signed-off-by: Shengjiu Wang
---
include/linux/firmware/imx/sm.h |
ASoC: fsl_mqs: support MQS2 on i.MX94 platform
Shengjiu Wang (2):
ASoC: fsl_mqs: Distinguish different modules by system manager indices
ASoC: fsl_mqs: rename system manager indices for i.MX95
include/linux/firmware/imx/sm.h | 20 ++--
sound/soc/fsl/fsl_mqs.c | 11 +++
On Thu, Jun 19, 2025 at 02:12:49PM +0200, Oscar Salvador wrote:
> On Wed, Jun 18, 2025 at 08:42:52PM +0100, Lorenzo Stoakes wrote:
> > We abstract the type of the VMA flags to vm_flags_t, however in may places
> many?
> > it is simpl
Without this, the compiler (clang21) might emit a warning under W=1
because the variable ori31_emitted is set but never used if
CONFIG_PPC_BOOK3S_64=n.
Without this patch:
$ make -j $(nproc) W=1 ARCH=powerpc SHELL=/bin/bash arch/powerpc/net
[...]
CC arch/powerpc/net/bpf_jit_comp.o
CC
Hi Andrew,
I enclose a quick fix-patch to address a case I missed and to avoid any risk of
circular dependency in a header include.
Thanks to Vlastimil and Oscar for spotting this! :)
Cheers, Lorenzo
8<
>From d66fe0b934098ccc2ba45f739277fffe86c91442 Mon Sep 17 00:00:00 2001
From: Lorenz
On 6/18/25 21:42, Lorenzo Stoakes wrote:
> We abstract the type of the VMA flags to vm_flags_t, however in may places
> it is simply assumed this is unsigned long, which is simply incorrect.
>
> At the moment this is simply an incongruity, however in future we plan to
> change this type and theref
On Wed, Jun 18, 2025 at 08:42:52PM +0100, Lorenzo Stoakes wrote:
> We abstract the type of the VMA flags to vm_flags_t, however in may places
many?
> it is simply assumed this is unsigned long, which is simply incorrect.
>
> At the
On Wed, Jun 18, 2025 at 08:42:52PM +0100, Lorenzo Stoakes wrote:
> We abstract the type of the VMA flags to vm_flags_t, however in may places
> it is simply assumed this is unsigned long, which is simply incorrect.
>
> At the moment this is simply an incongruity, however in future we plan to
> cha
On Wed, Jun 18, 2025 at 08:42:54PM +0100, Lorenzo Stoakes wrote:
> In future we intend to change the vm_flags_t type, so it isn't correct for
> architecture and driver code to assume it is unsigned long. Correct this
> assumption across the board.
>
> Overall, this patch does not introduce any fun
On Wed, Jun 18, 2025 at 08:42:53PM +0100, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this resu
On Wed, Jun 18, 2025 at 08:42:54PM +0100, Lorenzo Stoakes wrote:
> In future we intend to change the vm_flags_t type, so it isn't correct for
> architecture and driver code to assume it is unsigned long. Correct this
> assumption across the board.
>
> Overall, this patch does not introduce any fun
The pmd_devmap() check in check_pmd_state() is redundant because the
only user of pmd_devmap were device dax and fs dax. However all callers
of check_pmd_state() first call thp_vma_allowable_order() to check if
the vma should be scanned. Except when called from a page fault this
always returns 0 fo
On Sat, Jun 07, 2025 at 11:51:59PM +0800, Hans Zhang wrote:
> Replace manual read-modify-write sequences in multiple functions with
> pci_clear_and_set_config_dword() to ensure atomic operations and reduce
> code duplication.
>
No, pci_clear_and_set_config_dword() doesn't ensure atomicity. It ju
On Thu, Jun 19, 2025 at 01:31:50PM +0200, Vlastimil Babka wrote:
> On 6/18/25 21:42, Lorenzo Stoakes wrote:
> > We abstract the type of the VMA flags to vm_flags_t, however in may places
> > it is simply assumed this is unsigned long, which is simply incorrect.
> >
> > At the moment this is simply
Le 19/06/2025 à 16:26, Luis Gerhorst a écrit :
Without this, the compiler (clang21) might emit a warning under W=1
because the variable ori31_emitted is set but never used if
CONFIG_PPC_BOOK3S_64=n.
Without this patch:
$ make -j $(nproc) W=1 ARCH=powerpc SHELL=/bin/bash arch/powerpc/net
[
On Wed, Jun 18, 2025 at 08:42:53PM +0100, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this resu
On Wed 18-06-25 20:42:53, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this results in rather a
On Tue, Jun 17, 2025 at 11:44:30AM +0200, David Hildenbrand wrote:
> On 16.06.25 13:58, Alistair Popple wrote:
> > The only users of pmd_devmap were device dax and fs dax. The check for
> > pmd_devmap() in check_pmd_state() is therefore redundant as callers
> > explicitly check for is_zone_device_p
Nothing uses PFN_DEV anymore so no need to create devmap pXd's when
mapping a PFN. Instead special mappings will be created which ensures
vm_normal_page_pXd() will not return pages which don't have an
associated page. This could change behaviour slightly on architectures
where pXd_devmap() does not
It's no longer used so remove it.
Signed-off-by: Alistair Popple
Reviewed-by: Jason Gunthorpe
Acked-by: David Hildenbrand
---
mm/memremap.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index 044a455..f75078c 100644
--- a/mm/memre
PFN_DEV no longer exists. This means no devmap PMDs or PUDs will be
created, so checking for them is redundant. Instead mappings of pages that
would have previously returned true for pXd_devmap() will return true for
pXd_trans_huge()
Signed-off-by: Alistair Popple
Reviewed-by: Jason Gunthorpe
Ac
On Thu, Jun 19, 2025 at 10:42:14AM +0200, Christian Brauner wrote:
> If you change vm_flags_t to u64 you probably want to compile with some
> of these integer truncation options when you're doing the conversion.
> Because otherwise you risk silently truncating the upper 32bits when
> assigning to a
On Tue, Jun 17, 2025 at 11:19:34AM +0200, David Hildenbrand wrote:
> On 16.06.25 13:58, Alistair Popple wrote:
> > Currently dax is the only user of pmd and pud mapped ZONE_DEVICE
> > pages. Therefore page walkers that want to exclude DAX pages can check
> > pmd_devmap or pud_devmap. However soon d
On Tue, Jun 17, 2025 at 11:49:20AM +0200, David Hildenbrand wrote:
> On 16.06.25 13:58, Alistair Popple wrote:
> > Nothing uses PFN_DEV anymore so no need to create devmap pXd's when
> > mapping a PFN. Instead special mappings will be created which ensures
> > vm_normal_page_pXd() will not return p
PFN_DEV was used by callers of dax_direct_access() to figure out if the
returned PFN is associated with a page using pfn_t_has_page() or
not. However all DAX PFNs now require an assoicated ZONE_DEVICE page so can
assume a page exists.
Other users of PFN_DEV were setting it before calling
vmf_inser
The DMA map functions can fail and should be tested for errors.
Signed-off-by: Thomas Fourier
---
arch/powerpc/include/asm/floppy.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/floppy.h
b/arch/powerpc/include/asm/floppy.h
index f8ce178b43b7.
Hello Dave,
In commit 74e19ef0ff80 ("uaccess: Add speculation barrier to
copy_from_user()") you add barrier_nospec() to copy_from_user().
There is already a barrier_nospec() in allow_read_from_user() which is
called by raw_copy_from_user(), see commit 8524e2e76441
("powerpc/uaccess: Perform
GUP uses pXX_devmap() calls to see if it needs to a get a reference on
the associated pgmap data structure to ensure the pages won't go
away. However it's a driver responsibility to ensure that if pages are
mapped (ie. discoverable by GUP) that they are not offlined or removed
from the memmap so th
Currently dax is the only user of pmd and pud mapped ZONE_DEVICE
pages. Therefore page walkers that want to exclude DAX pages can check
pmd_devmap or pud_devmap. However soon dax will no longer set PFN_DEV,
meaning dax pages are mapped as normal pages.
Ensure page walkers that currently use pXd_de
DAX no longer requires device PTEs as it always has a ZONE_DEVICE page
associated with the PTE that can be reference counted normally. Other users
of pte_devmap are drivers that set PFN_DEV when calling vmf_insert_mixed()
which ensures vm_normal_page() returns NULL for these entries.
There is no r
All PFN_* pfn_t flags have been removed. Therefore there is no longer
a need for the pfn_t type and all uses can be replaced with normal
pfns.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Acked-by: David Hildenbrand
---
Changes since v1:
- Reba
Now that DAX and all other reference counts to ZONE_DEVICE pages are
managed normally there is no need for the special devmap PTE/PMD/PUD
page table bits. So drop all references to these, freeing up a
software defined page table bit on architectures supporting it.
Signed-off-by: Alistair Popple
A
DAX was the only thing that created pmd_devmap and pud_devmap entries
however it no longer does as DAX pages are now refcounted normally and
pXd_trans_huge() returns true for those. Therefore checking both pXd_devmap
and pXd_trans_huge() is redundant and the former can be removed without
changing b
On Wed, Jun 18, 2025 at 08:32:28PM +0300, Dan Carpenter wrote:
> Hi Alexander,
>
> kernel test robot noticed the following build warnings:
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Alexander-Gordeev/mm-Cleanup-apply_to_pte_range-routine/20250613-013835
> base: https://git.ke
The dcssblk driver was the last user of FS_DAX_LIMITED. That was marked
broken by 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED
support") to allow removal of PFN_SPECIAL. However the FS_DAX_LIMITED
config option itself was not removed, so do that now.
Signed-off-by: Alistair Poppl
Changes from v2:
- Addressed minor comments from David (thanks!).
- Reordered removal of the devmap functions.
- Fixed a minor RISC-V build error introduced by a recent change to mm-unstable
which added pud_mkdevmap() to RISC-V
Changes from v1:
- Moved "mm: Remove PFN_MAP, PFN_SPECIAL,
The PFN_MAP flag is no longer used for anything, so remove it.
The PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been
used so also remove them. The last user of PFN_SPECIAL was removed
by 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED
support").
Users of PFN_DEV were remo
Previously dax pages were skipped by the pagewalk code as pud_special() or
vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
refcounted normally that is no longer the case, so the pagewalk code will
start returning them.
Most callers already explicitly filter for DAX or z
On 6/18/25 21:42, Lorenzo Stoakes wrote:
> In future we intend to change the vm_flags_t type, so it isn't correct for
> architecture and driver code to assume it is unsigned long. Correct this
> assumption across the board.
>
> Overall, this patch does not introduce any functional change.
>
> Sig
On 6/18/25 21:42, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this results in rather a lot of c
55 matches
Mail list logo
