Hello,
On Thu, Jun 20, 2024 at 09:01:01PM +0530, Athira Rajeev wrote:
>
>
> > On 14 Jun 2024, at 10:56 PM, Athira Rajeev
> > wrote:
> >
> > The patchset from Namhyung added support for data type profiling
> > in perf tool. This enabled support to associate PMU samples to data
> > types they r
On Fri, 21 Jun 2024 17:30:14 -0400, Frank Li wrote:
> Convert qman, bman, qman-portals, bman-portals to yaml format.
>
> Additional Chang for fsl,q(b)man-portal:
> - Only keep one example.
> - Add fsl,qman-channel-id property.
> - Use interrupt type macro.
> - Remove top level qman-portals@ff420
On Fri, 2024-06-21 at 16:27 -0400, Peter Xu wrote:
> On Fri, Jun 21, 2024 at 07:36:30PM +, Edgecombe, Rick P wrote:
> > On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
> > >
> > > But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> > > to make it Dirty=1,Write=0? Wh
Convert qman, bman, qman-portals, bman-portals to yaml format.
Additional Chang for fsl,q(b)man-portal:
- Only keep one example.
- Add fsl,qman-channel-id property.
- Use interrupt type macro.
- Remove top level qman-portals@ff420 at example.
Additional change for fsl,q(b)man:
- Fixed example
On Fri, Jun 21, 2024 at 07:36:30PM +, Edgecombe, Rick P wrote:
> On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
> >
> > But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> > to make it Dirty=1,Write=0? What prevents that from being
> > misinterpreted by the hardwar
On Fri, Jun 21, 2024 at 10:44:39AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Arnd,
>
> thanks for your patch!
>
> On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The unusual function calling conventions on superh ended up causing
>
Hello,
> Applied patch 2/5 to pci/endpoint! Krzysztof, please apply patches 1/5 and 5/5
> to controller/dwc (patches 3/5 and 4/5 are already applied by you).
Applied to controller/dwc, thank you!
[01/02] PCI: dwc: ep: Remove dw_pcie_ep_init_notify() wrapper
https://git.kernel.org/pci/pci
On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
>
> But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> to make it Dirty=1,Write=0? What prevents that from being
> misinterpreted by the hardware as being a valid 1G shadow stack mapping?
Hmm, it looks like we could use
On Fri, May 03, 2024 at 02:01:38PM +0100, Joey Gouly wrote:
> Set the EL0/userspace indirection encodings to be the overlay enabled
> variants of the permissions.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Fri, May 03, 2024 at 02:01:34PM +0100, Joey Gouly wrote:
> We do not want take POE into account when clearing the MTE tags.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Fri, May 03, 2024 at 02:01:24PM +0100, Joey Gouly wrote:
> +static void flush_poe(void)
> +{
> + if (!system_supports_poe())
> + return;
> +
> + write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> + /* ISB required for kernel uaccess routines when chaning POR_EL0 */
Nit: s/chan
On Fri, May 03, 2024 at 02:01:30PM +0100, Joey Gouly wrote:
> The 3-bit POIndex is stored in the PTE at bits 60..62.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Fri, May 03, 2024 at 02:01:29PM +0100, Joey Gouly wrote:
> To make it easier to share the generic PKEYs flags, move the MTE flag.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be used to
> check if the CPU supports the feature.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Fri, May 03, 2024 at 02:01:24PM +0100, Joey Gouly wrote:
> POR_EL0 is a register that can be modified by userspace directly,
> so it must be context switched.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Fri, Jun 21, 2024 at 06:01:52PM +0100, Catalin Marinas wrote:
> On Fri, May 03, 2024 at 02:01:23PM +0100, Joey Gouly wrote:
> > This indicates if the system supports POE. This is a CPUCAP_BOOT_CPU_FEATURE
> > as the boot CPU will enable POE if it has it, so secondary CPUs must also
> > have this
On Fri, May 03, 2024 at 02:01:23PM +0100, Joey Gouly wrote:
> This indicates if the system supports POE. This is a CPUCAP_BOOT_CPU_FEATURE
> as the boot CPU will enable POE if it has it, so secondary CPUs must also
> have this feature.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Wi
On Fri, May 03, 2024 at 02:01:23PM +0100, Joey Gouly wrote:
> This indicates if the system supports POE. This is a CPUCAP_BOOT_CPU_FEATURE
> as the boot CPU will enable POE if it has it, so secondary CPUs must also
> have this feature.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Wi
On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> @@ -529,6 +547,8 @@ static int __kprobes do_page_fault(unsigned long far,
> unsigned long esr,
> unsigned int mm_flags = FAULT_FLAG_DEFAULT;
> unsigned long addr = untagged_addr(far);
> struct vm_area_struct *vma;
> +
On 6/21/24 11:52, Arnd Bergmann wrote:
On Fri, Jun 21, 2024, at 11:03, John Paul Adrian Glaubitz wrote:
On Fri, 2024-06-21 at 10:56 +0200, Arnd Bergmann wrote:
Feel free to pick up the sh patch directly, I'll just merge whatever
is left in the end. I mainly want to ensure we can get all the bug
On 6/21/24 08:45, Peter Xu wrote:
> On Fri, Jun 21, 2024 at 07:51:26AM -0700, Dave Hansen wrote:
...
>> But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
>> to make it Dirty=1,Write=0? What prevents that from being
>> misinterpreted by the hardware as being a valid 1G shadow s
On Fri, Jun 21, 2024 at 07:51:26AM -0700, Dave Hansen wrote:
> On 6/21/24 07:25, Peter Xu wrote:
> > These new helpers will be needed for pud entry updates soon. Namely:
> >
> > - pudp_invalidate()
> > - pud_modify()
>
> I think it's also definitely worth noting where you got this code from.
> P
On Fri, Jun 21, 2024 at 10:25:01AM -0400, Peter Xu wrote:
> +pmd_t pudp_invalidate(struct vm_area_struct *vma, unsigned long address,
> + pud_t *pudp)
> +{
> + unsigned long old_pud;
> +
> + VM_WARN_ON_ONCE(!pmd_present(*pmdp));
> + old_pmd = pmd_hugepage_update(vma->v
On 6/21/24 07:25, Peter Xu wrote:
> These new helpers will be needed for pud entry updates soon. Namely:
>
> - pudp_invalidate()
> - pud_modify()
I think it's also definitely worth noting where you got this code from.
Presumably you copied, pasted and modified the PMD code. That's fine,
but it
On Mon, 17 Jun 2024 17:51:21 +0530, Athira Rajeev wrote:
> Running "perftool-testsuite_probe" fails as below:
>
> ./perf test -v "perftool-testsuite_probe"
> 83: perftool-testsuite_probe : FAILED
>
> There are three fails:
>
> [...]
Applied to perf-tools-next, thanks!
Best regard
On 6/21/24 07:25, Peter Xu wrote:
> An entry should be reported as PUD leaf even if it's PROT_NONE, in which
> case PRESENT bit isn't there. I hit bad pud without this when testing dax
> 1G on zapping a PROT_NONE PUD.
Yeah, looks like pmd_leaf() got fixed up because of its involvement in
THP, but
An entry should be reported as PUD leaf even if it's PROT_NONE, in which
case PRESENT bit isn't there. I hit bad pud without this when testing dax
1G on zapping a PROT_NONE PUD.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: x...@kernel.org
Signed-off-by: Peter Xu
This is only relevant to the two archs that support PUD dax, aka, x86_64
and ppc64. PUD THPs do not yet exist elsewhere, and hugetlb PUDs do not
count in this case.
DAX have had PUD mappings for years, but change protection path never
worked. When the path is triggered in any form (a simple test
These new helpers will be needed for pud entry updates soon. Namely:
- pudp_invalidate()
- pud_modify()
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: x...@kernel.org
Signed-off-by: Peter Xu
---
arch/x86/include/asm/pgtable.h | 36 ++
These new helpers will be needed for pud entry updates soon. Namely:
- pudp_invalidate()
- pud_modify()
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Aneesh Kumar K.V
Signed-off-by: Peter Xu
---
arch/powerpc/include/asm/book3s/64/pgtabl
mprotect() does mmu notifiers in PMD levels. It's there since 2014 of
commit a5338093bfb4 ("mm: move mmu notifier call from change_protection to
change_pmd_range").
At that time, the issue was that NUMA balancing can be applied on a huge
range of VM memory, even if nothing was populated. The not
In 2013, commit 72403b4a0fbd ("mm: numa: return the number of base pages
altered by protection changes") introduced "numa_huge_pte_updates" vmstat
entry, trying to capture how many huge ptes (in reality, PMD thps at that
time) are marked by NUMA balancing.
This patch proposes to remove it for some
Currently the dax fault handler dumps the vma range when dynamic debugging
enabled. That's mostly not useful. Dump the (aligned) address instead
with the order info.
Signed-off-by: Peter Xu
---
drivers/dax/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
[Based on mm-unstable, commit a53138cdbe3e]
Dax supports pud pages for a while, but mprotect on puds was missing since
the start. This series tries to fix that by providing pud handling in
mprotect(), while my real goal is adding more types of pud mappings like
hugetlb or pfnmaps, it's just that
On Thu, Jun 20, 2024 at 06:23:03PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Using sys_io_pgetevents() as the entry point for compat mode tasks
> works almost correctly, but misses the sign extension for the min_nr
> and nr arguments.
>
> This was addressed on parisc by switching to
On Thu, Jun 20, 2024 at 06:23:13PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The mmap2() syscall has never been used on 64-bit s390x and should
> have been removed as part of 5a79859ae0f3 ("s390: remove 31 bit
> support").
>
> Remove it now.
>
> Signed-off-by: Arnd Bergmann
> ---
>
On Fri, Jun 21, 2024 at 10:30 AM Miquel Raynal
wrote:
>
> Hi Piotr,
>
> piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
>
> > Move away from pl08x platform data towards device tree.
> >
> > Signed-off-by: Piotr Wojtaszczyk
>
> I don't see any change regarding the NAND cont
On 2024-06-21 4:54 a.m., John Paul Adrian Glaubitz wrote:
Hi,
On Fri, 2024-06-21 at 08:28 +0200, Arnd Bergmann wrote:
It's more likely to be related to the upward growing stack.
I checked the gcc sources and found that out of the 50 supported
architectures, ARGS_GROW_DOWNWARD is set on everythi
Hi Andi,
On Fri, Jun 21, 2024 at 12:57 AM Andi Shyti wrote:
> On Thu, Jun 20, 2024 at 07:56:41PM GMT, Piotr Wojtaszczyk wrote:
> > When del_timer_sync() is called in an interrupt context it throws a warning
> > because of potential deadlock. Threaded irq handler fixes the potential
> > problem.
>
Anjali K writes:
> Hi Michael
>
> On 18/06/24 12:41, Michael Ellerman wrote:
>> I guess there isn't a kmem_cache_create_user_readonly() ?
> Thank you for your review.
>
> My understanding of the question is whether there's a way to whitelist a
On Fri, Jun 21, 2024, at 11:03, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-06-21 at 10:56 +0200, Arnd Bergmann wrote:
>> Feel free to pick up the sh patch directly, I'll just merge whatever
>> is left in the end. I mainly want to ensure we can get all the bugfixes
>> done for v6.10 so I can bu
On Fri, Jun 21, 2024, at 10:44, John Paul Adrian Glaubitz wrote:
> On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The unusual function calling conventions on superh ended up causing
> ^^
>
On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote:
> On 6/18/24 7:53 PM, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote:
> >> On 6/18/24 6:48 PM, Paul E. McKenney wrote:
> >> > On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrot
On Fri, 2024-06-21 at 10:56 +0200, Arnd Bergmann wrote:
> The patches are all independent of one another, except for a couple
> of context changes where multiple patches touch the same lines.
OK.
> Feel free to pick up the sh patch directly, I'll just merge whatever
> is left in the end. I mainly
On Fri, Jun 21, 2024, at 10:52, John Paul Adrian Glaubitz wrote:
> Hi Helge and Arnd,
>
> On Thu, 2024-06-20 at 23:21 +0200, Helge Deller wrote:
>> The patch looks good at first sight.
>> I'll pick it up in my parisc git tree and will do some testing the
>> next few days and then push forward for 6
Hi,
On Fri, 2024-06-21 at 08:28 +0200, Arnd Bergmann wrote:
> It's more likely to be related to the upward growing stack.
> I checked the gcc sources and found that out of the 50 supported
> architectures, ARGS_GROW_DOWNWARD is set on everything except
> for gcn, stormy16 and 32-bit parisc. The o
Hi Helge and Arnd,
On Thu, 2024-06-20 at 23:21 +0200, Helge Deller wrote:
> The patch looks good at first sight.
> I'll pick it up in my parisc git tree and will do some testing the
> next few days and then push forward for 6.11 when it opens
Isn't this supposed to go in as one series or can
Hi Arnd,
thanks for your patch!
On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The unusual function calling conventions on superh ended up causing
^^
It's spelled SuperH
Hi Piotr,
piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
> Move away from pl08x platform data towards device tree.
>
> Signed-off-by: Piotr Wojtaszczyk
I don't see any change regarding the NAND controller node in the device
tree, is there any dependency with other patc
On Thu, Jun 20, 2024 at 06:23:04PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This is almost compatible, but passing a negative offset should result
> in a EINVAL error, but on mips o32 compat mode would seek to a large
> 32-bit byte offset.
>
> Use compat_sys_lseek() to correctly sig
Hi Michael
On 18/06/24 12:41, Michael Ellerman wrote:
> I guess there isn't a kmem_cache_create_user_readonly() ?
Thank you for your review.
My understanding of the question is whether there's a way to whitelist a
region such that it can be co
On Thu, Jun 20, 2024 at 06:23:02PM GMT, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The old ftruncate() syscall, using the 32-bit off_t misses a sign
> extension when called in compat mode on 64-bit architectures. As a
> result, passing a negative length accidentally succeeds in truncating
>
52 matches
Mail list logo
