On Mon, 23 Jun 2025 at 22:49, Christophe Leroy
wrote:
>
> >
> > (Although I also suspect that when we added ITER_UBUF we might have
> > created cases where those user addresses aren't checked at iter
> > creation time any more).
> >
>
> Let's take the follow path as an exemple:
>
> snd_pcm_ioctl(S
Hi!
On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote:
> On Tue, 24 Jun 2025 08:17:14 -0500
> Segher Boessenkool wrote:
>
> > On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> > > Ah ok, I overlooked that, I didn't know the cmove instruction, seem
> > > similar to t
On Tue, 24 Jun 2025 13:25:05 -0500
Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote:
> > On Tue, 24 Jun 2025 08:17:14 -0500
> > Segher Boessenkool wrote:
> >
> > > On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> > > > Ah o
Hi!
On Tue, Jun 24, 2025 at 09:32:58AM +0100, David Laight wrote:
> > So GCC uses the 'unlikely' variant of the branch instruction to force
> > the correct prediction, doesn't it ?
>
> Nope...
> Most architectures don't have likely/unlikely variants of branches.
In GCC, "likely" means 80%. "Ver
config-001-20250624gcc-12.4.0
arc randconfig-002-20250624gcc-8.5.0
arm allnoconfigclang-21
arm randconfig-001-20250624gcc-13.3.0
arm randconfig-002-20250624gcc-8.5.0
arm randconfig-00
On Wed, Jun 18, 2025 at 08:42:54PM +0100, Lorenzo Stoakes wrote:
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -279,7 +279,7 @@ static struct sgx_encl_page *__sgx_encl_load_page(struct
> sgx_encl *encl,
>
> static struct sgx_encl_page *sgx_encl_load_page_in_
On Wed, Jun 18, 2025 at 07:37:54PM -0500, Timothy Pearson wrote:
> - Original Message -
> > From: "Bjorn Helgaas"
> > To: "Timothy Pearson"
> > Cc: "linuxppc-dev" , "linux-kernel"
> > , "linux-pci"
> > , "Madhavan Srinivasan" ,
> > "Michael Ellerman" ,
> > "christophe leroy" , "Naveen N
On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> Ah ok, I overlooked that, I didn't know the cmove instruction, seem
> similar to the isel instruction on powerpc e500.
cmove does a move (register or memory) when some condition is true.
isel (which is base PowerPC, not something
- Original Message -
> From: "Krishna Kumar"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev" , "Shawn Anastasio"
> , "linux-kernel"
> , "linux-pci" ,
> "Madhavan Srinivasan" ,
> "Michael Ellerman" , "christophe leroy"
> , "Naveen N Rao"
> , "Bjorn Helgaas"
> Sent: Tuesday, June 24, 20
On Tue, 24 Jun 2025 08:17:14 -0500
Segher Boessenkool wrote:
> On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> > Ah ok, I overlooked that, I didn't know the cmove instruction, seem
> > similar to the isel instruction on powerpc e500.
>
> cmove does a move (register or memo
From: Markus Elfring
Date: Tue, 24 Jun 2025 16:33:53 +0200
Reuse existing functionality from usb_endpoint_type() instead of keeping
duplicate source code.
The source code was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/usb/gadget/udc/fsl_qe_udc.c
To provide support for page table check on powerpc, we need to reinstate the
address parameter in several functions, including
page_table_check_{ptes,pmds,puds}_set().
In preparation for this, add the addr parameter to arm64's __set_ptes_anysz()
and its callers, __set_ptes(), __set_pmds() and __se
From: Rohan McLure
Page table checking depends on architectures providing an
implementation of p{te,md,ud}_user_accessible_page. With
refactorisations made on powerpc/mm, the pte_access_permitted() and
similar methods verify whether a userland page is accessible with the
required permissions.
Si
From: Rohan McLure
In the new set_ptes() API, set_pte_at() (a special case of set_ptes())
is intended to be instrumented by the page table check facility. There
are however several other routines that constitute the API for setting
page table entries, including set_pmd_at() among others. Such rou
From: Rohan McLure
On several powerpc platforms, a page table entry may not imply whether
the relevant mapping is for userspace or kernelspace. Instead, such
platforms infer this by the address which is being accessed.
Add an additional address argument to each of these routines in order to
prov
From: Rohan McLure
This reverts commit aa232204c468 ("mm/page_table_check: remove unused
parameter in [__]page_table_check_pte_clear").
Reinstate previously unused parameters for the purpose of supporting
powerpc platforms, as many do not encode user/kernel ownership of the
page in the pte, but
From: Rohan McLure
This reverts commit 931c38e16499 ("mm/page_table_check: remove unused
parameter in [__]page_table_check_pud_clear").
Reinstate previously unused parameters for the purpose of supporting
powerpc platforms, as many do not encode user/kernel ownership of the
page in the pte, but
On 6/21/25 3:29 PM, Lukas Wunner wrote:
> On Fri, Jun 20, 2025 at 02:56:51PM +0530, Krishna Kumar wrote:
>> 5. If point 3 and 4 does not solve the problem, then only we should
>> move to pciehp.c. But AFAIK, PPC/Powernv is DT based while pciehp.c
>> may be only supporting acpi (I have to check it
branch this series applies ? Tried all the usual
ones but could not apply the series cleanly.
v6.16-rc3
next-20250624
mm-stable
mm-unstable
b4 am cover.1750274467.git.lorenzo.stoa...@oracle.com
git am ./20250618_lorenzo_stoakes_use_vm_flags_t_consistently.mbx
- Anshuman
When USRC=0, there is underrun issue for the non-ideal ratio mode;
according to the reference mannual, the internal measured ratio can be
used with USRC=1 and IDRC=0.
Fixes: d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio
mode")
Signed-off-by: Shengjiu Wang
---
sound/soc/f
On 19/06/25 1:12 AM, 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
On 19/06/25 1:12 AM, 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.
>
On 19/06/25 1:12 AM, 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 lo
On Wed, 25 Jun 2025 08:25:35 +0530 Anshuman Khandual
wrote:
> ust wondering which tree-branch this series applies ? Tried all the usual
> ones but could not apply the series cleanly.
>
> v6.16-rc3
> next-20250624
> mm-stable
> mm-unstable
It's now in mm-unstable if that helps.
Le 22/06/2025 à 18:57, Linus Torvalds a écrit :
On Sun, 22 Jun 2025 at 02:52, Christophe Leroy
wrote:
The results of "access_ok()" can be mis-speculated.
Hmm. This code is critical. I think it should be converted to use that
masked address thing if we have to add it here.
Ok, I'll add i
Le 22/06/2025 à 18:35, David Laight a écrit :
On Sun, 22 Jun 2025 11:52:39 +0200
Christophe Leroy wrote:
Allthough masked_user_access_begin() seems to only be used when reading
data from user at the moment, introduce masked_user_read_access_begin()
and masked_user_write_access_begin() in or
On 6/21/25 8:35 PM, Timothy Pearson wrote:
>
> - Original Message -
>> From: "Krishna Kumar"
>> To: "linuxppc-dev" , "Timothy Pearson"
>> , "Shawn
>> Anastasio"
>> Cc: "linuxppc-dev" , "linux-kernel"
>> , "linux-pci"
>> , "Madhavan Srinivasan" ,
>> "Michael Ellerman" ,
>> "christophe
On Tue, 24 Jun 2025 07:49:03 +0200
Christophe Leroy wrote:
> Le 22/06/2025 à 18:57, Linus Torvalds a écrit :
> > On Sun, 22 Jun 2025 at 02:52, Christophe Leroy
> > wrote:
> >>
> >> The results of "access_ok()" can be mis-speculated.
> >
> > Hmm. This code is critical. I think it should be c
Le 22/06/2025 à 18:20, David Laight a écrit :
On Sun, 22 Jun 2025 11:52:38 +0200
Christophe Leroy wrote:
Masked user access avoids the address/size verification by access_ok().
Allthough its main purpose is to skip the speculation in the
verification of user address and size hence avoid the
clang-19
arc randconfig-001-20250624gcc-8.5.0
arc randconfig-002-20250624gcc-8.5.0
arm allmodconfigclang-19
arm allnoconfiggcc-15.1.0
arm allyesconfig
On Tue, 24 Jun 2025 07:27:47 +0200
Christophe Leroy wrote:
> Le 22/06/2025 à 18:20, David Laight a écrit :
> > On Sun, 22 Jun 2025 11:52:38 +0200
> > Christophe Leroy wrote:
> >
> >> Masked user access avoids the address/size verification by access_ok().
> >> Allthough its main purpose is to
31 matches
Mail list logo
