> On 7 Aug 2024, at 11:42 PM, Namhyung Kim wrote:
>
> Hello folks,
>
> On Tue, Aug 06, 2024 at 03:50:03PM -0700, Namhyung Kim wrote:
>> Hello,
>>
>> This is the usual sync up in header files we keep in tools directory.
>> I put a file to give the reason of this work and not to repeat it in
>
Hello,
On Wed, Aug 07, 2024 at 07:50:26AM +0200, Christophe Leroy wrote:
> Le 04/08/2024 à 13:20, Uwe Kleine-König a écrit :
> > This driver doesn't use the driver_data member of struct i2c_device_id,
> > so don't explicitly initialize this member.
>
> Well, even if the member was used, a 0 init
On Wed, Aug 7, 2024 at 8:21 PM Linus Torvalds
wrote:
>
> On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote:
> >
> > Okay, I'm going to try one more time here. You are suggesting to have a
> > conf flag to leave the vdso pointer unchanged when it is unmapped.
> > Having the close behind the conf
On Wed, Aug 7, 2024 at 8:21 PM Linus Torvalds
wrote:
>
> On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote:
> >
> > Okay, I'm going to try one more time here. You are suggesting to have a
> > conf flag to leave the vdso pointer unchanged when it is unmapped.
> > Having the close behind the conf
On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote:
>
> Okay, I'm going to try one more time here. You are suggesting to have a
> conf flag to leave the vdso pointer unchanged when it is unmapped.
> Having the close behind the conf option will not prevent it from being
> unmapped or mapped over,
On Wed, 7 Aug 2024 22:29:35 +1000 Oliver O'Halloran Wrote
> My read was that Matt is essentially doing a surprise hot-unplug by
> removing power to the card without notifying the OS. I thought the
> LBMS bit wouldn't be set in that case since the link goes down rather
> than changes speed, but the
On Wed, Aug 07, 2024 at 11:12:45AM -0700, Namhyung Kim wrote:
> On Tue, Aug 06, 2024 at 03:50:03PM -0700, Namhyung Kim wrote:
> > This is the usual sync up in header files we keep in tools directory.
> > I put a file to give the reason of this work and not to repeat it in
> > every commit message.
* Jeff Xu [240807 16:12]:
> On Wed, Aug 7, 2024 at 10:11 AM Liam R. Howlett
> wrote:
> >
> > * Jeff Xu [240807 12:37]:
> > > On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett
> > > wrote:
> > > >
> > > > * Jeff Xu [240807 11:44]:
> > > > > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman
> > >
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> These new helpers will be needed for pud entry updates soon. Introduce
> these helpers by referencing the pmd ones. Namely:
>
> - pudp_invalidate()
> - pud_modify()
Zero content about what these helpers do and why they are needed. That's
not how it
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> Subject: mm/x86: arch_check_zapped_pud()
Is not a proper subject line. It clearly lacks a verb.
Subject: mm/x86: Implement arch_check_zapped_pud()
> Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
> It has the same l
On Wed, Aug 07 2024 at 15:48, 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.
That does not qualify as a change log. What you hit is irrelevant un
On Wed, Aug 07, 2024 at 02:23:16PM -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> >
> > Tests
> > =
> >
> > What I did test:
> >
> > - cross-build tests that I normally cover [1]
> >
> > - smoke tested on x86_64 the simplest program [2] on dev_dax 1G
On Wed, 7 Aug 2024 17:34:10 -0400 Peter Xu wrote:
> The problem is mprotect() will skip the dax 1G PUD while it shouldn't;
> meanwhile it'll dump some bad PUD in dmesg. Both of them look like (corner
> case) bugs to me.. where:
>
> - skipping the 1G pud means mprotect() will succeed even if t
On Wed, Aug 07, 2024 at 02:17:03PM -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> >
> > 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(). The
On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> Tests
> =
>
> What I did test:
>
> - cross-build tests that I normally cover [1]
>
> - smoke tested on x86_64 the simplest program [2] on dev_dax 1G PUD
> mprotect() using QEMU's nvdimm emulations [3] and ndctl to create
> namespa
On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> 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(). The goal is to add more types of pud mappings like hugetlb or
> pfnmaps. This
On Wed, Aug 7, 2024 at 10:11 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240807 12:37]:
> > On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett
> > wrote:
> > >
> > > * Jeff Xu [240807 11:44]:
> > > > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman
> > > > wrote:
> > > > >
> > > > > Add a close() ca
On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240807 11:44]:
> > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman wrote:
> > >
> > > Add a close() callback to the VDSO special mapping to handle unmapping
> > > of the VDSO. That will make it possible to remove the arch_unmap
On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman wrote:
>
> Add a close() callback to the VDSO special mapping to handle unmapping
> of the VDSO. That will make it possible to remove the arch_unmap() hook
> entirely in a subsequent patch.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Michael E
On Fri, 2 Aug 2024 09:03:47 +0300
Baruch Siach wrote:
> From: Catalin Marinas
>
> Hardware DMA limit might not be power of 2. When RAM range starts above
> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
> can not encode this limit.
>
> Use plain address for DMA zone lim
On Wed, 7 Aug 2024 14:58:49 +0100
Catalin Marinas wrote:
> Thanks Robin for having a look.
>
> On Wed, Aug 07, 2024 at 02:13:06PM +0100, Robin Murphy wrote:
> > On 2024-08-02 7:03 am, Baruch Siach wrote:
> > > When device DMA limit does not fit in DMA32 zone it should use DMA zone,
> > > even
On Fri, 2 Aug 2024 10:37:38 +0100
Catalin Marinas wrote:
> On Fri, Aug 02, 2024 at 09:03:47AM +0300, Baruch Siach wrote:
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 3b4be4ca3b08..62b36fda44c9 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -20,7
Dan Williams wrote:
> [ add Boris ]
[ actually add Boris ]
Boris, see below, thoughts on deprecating acpi_extlog...
> Bjorn Helgaas wrote:
> > On Mon, May 27, 2024 at 04:43:41PM +0200, Fabio M. De Francesco wrote:
> > > Currently, extlog_print() (ELOG) only reports CPER PCIe section (UEFI
> > >
[ add Boris ]
Bjorn Helgaas wrote:
> On Mon, May 27, 2024 at 04:43:41PM +0200, Fabio M. De Francesco wrote:
> > Currently, extlog_print() (ELOG) only reports CPER PCIe section (UEFI
> > v2.10, Appendix N.2.7) to the kernel log via print_extlog_rcd(). Instead,
> > the similar ghes_do_proc() (GHES)
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. Introduce
these helpers by referencing the pmd ones. 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/inc
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
Acked-by: Dave Hansen
R
Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
It has the same logic of the PMD helper.
One thing to mention is, it might be a good idea to use page_table_check in
the future for trapping wrong setups of shadow stack pgtable entries [1].
That is left for the future as
These new helpers will be needed for pud entry updates soon. Introduce
them by referencing the pmd ones. 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
-
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.
Acked-by: David Hildenbrand
Signed-off-by: Peter Xu
---
drivers/dax/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
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
[Based on mm-unstable, commit 98808d08fc0f, Aug 7th]
v4:
- Added tags
- Dropped patch "mm/mprotect: Remove NUMA_HUGE_PTE_UPDATES" [DavidH]
- Touched up comment in pgtable_split_needed() [James]
v1: https://lore.kernel.org/r/20240621142504.1940209-1-pet...@redhat.com
v2: https://lore.kernel.org/r/
On Wed, Aug 7, 2024, at 20:18, Mike Rapoport wrote:
> On Wed, Aug 07, 2024 at 08:58:37AM +0200, Arnd Bergmann wrote:
>> On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
>> >
>> > void __init arch_numa_init(void);
>> > int __init numa_add_memblk(int nodeid, u64 start, u64 end);
>> > -void __in
On 8/7/24 03:11, Christophe Leroy wrote:
Hi,
Le 31/07/2024 à 18:35, Guenter Roeck a écrit :
On 7/31/24 08:36, LEROY Christophe wrote:
Hi Guenter,
Thanks for this report. I'm afk this week, i"ll have a look at it in more
détails next week.
But to be sûre, does that Oops match the bisected com
On Wed, Aug 07, 2024 at 08:58:37AM +0200, Arnd Bergmann wrote:
> On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Until now arch_numa was directly translating firmware NUMA information
> > to memblock.
>
> I get a link time warning from this:
>
>
On Wed, Aug 07, 2024 at 04:19:38PM +0200, Petr Tesařík wrote:
> On Fri, 2 Aug 2024 10:37:38 +0100
> Catalin Marinas wrote:
> > On Fri, Aug 02, 2024 at 09:03:47AM +0300, Baruch Siach wrote:
> > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > > index 3b4be4ca3b08..62b36fda44c9 100644
>
Hello folks,
On Tue, Aug 06, 2024 at 03:50:03PM -0700, Namhyung Kim wrote:
> Hello,
>
> This is the usual sync up in header files we keep in tools directory.
> I put a file to give the reason of this work and not to repeat it in
> every commit message. The changes will be carried in the perf-too
On Wed, Aug 07 2024 at 22:41, Michael Ellerman wrote:
> Now that powerpc no longer uses arch_unmap() to handle VDSO unmapping,
> there are no meaningful implementions left. Drop support for it
> entirely, and update comments which refer to it.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Mich
* Jeff Xu [240807 12:37]:
> On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett
> wrote:
> >
> > * Jeff Xu [240807 11:44]:
> > > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman
> > > wrote:
> > > >
> > > > Add a close() callback to the VDSO special mapping to handle unmapping
> > > > of the VDSO.
: 8400291e289ee6b2bf9779ff1c83a291501f017b
patch link:
https://lore.kernel.org/r/5200f289af1a9b80dfd329b6ed3d54e1d4a02876.1722578375.git.baruch%40tkos.co.il
patch subject: [PATCH v5 1/3] dma: improve DMA zone selection
config: csky-randconfig-001-20240807
(https://download.01.org/0day-ci/archive/20240808/202408080035.rxxbb5yc
On Fri, Jul 26, 2024 at 04:51:11PM -0700, Sean Christopherson wrote:
> Disallow copying MTE tags to guest memory while KVM is dirty logging, as
> writing guest memory without marking the gfn as dirty in the memslot could
> result in userspace failing to migrate the updated page. Ideally (maybe?),
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a
* Jeff Xu [240807 11:44]:
> On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman wrote:
> >
> > Add a close() callback to the VDSO special mapping to handle unmapping
> > of the VDSO. That will make it possible to remove the arch_unmap() hook
> > entirely in a subsequent patch.
> >
> > Suggested-by: L
* Michael Ellerman [240807 08:41]:
> Add an optional close() callback to struct vm_special_mapping. It will
> be used, by powerpc at least, to handle unmapping of the VDSO.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Michael Ellerman
> ---
> include/linux/mm_types.h | 2 ++
> mm/mmap.c
On Wed, Aug 7, 2024, at 17:17, Stewart Hildebrand wrote:
> In this context, "small" is defined as max(SZ_4K, PAGE_SIZE).
>
> This series sets the default minimum resource alignment to
> max(SZ_4K, PAGE_SIZE) for memory BARs. In preparation, it makes an
> optimization and addresses some corner cases
On 07.08.24 14:41, Michael Ellerman wrote:
Now that powerpc no longer uses arch_unmap() to handle VDSO unmapping,
there are no meaningful implementions left. Drop support for it
entirely, and update comments which refer to it.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
On 07.08.24 14:41, Michael Ellerman wrote:
Add a close() callback to the VDSO special mapping to handle unmapping
of the VDSO. That will make it possible to remove the arch_unmap() hook
entirely in a subsequent patch.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
Reviewed-
On 07.08.24 14:41, Michael Ellerman wrote:
Add an optional close() callback to struct vm_special_mapping. It will
be used, by powerpc at least, to handle unmapping of the VDSO.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
include/linux/mm_types.h | 2 ++
mm/mmap.c
On 07.08.24 16:40, Pasha Tatashin wrote:
On Wed, Aug 7, 2024 at 7:50 AM David Hildenbrand wrote:
On 07.08.24 13:32, David Hildenbrand wrote:
On 07.08.24 00:14, Pasha Tatashin wrote:
nid is needed during memory hot-remove in order to account the
information about the memmap overhead that is b
There is a corner case in pcibios_allocate_resources()/alloc_resource()
where the IORESOURCE_STARTALIGN alignment of memory BAR resources gets
overwritten. This does not affect bridge resources. Account for
IORESOURCE_STARTALIGN.
Signed-off-by: Stewart Hildebrand
---
v2->v3:
* no change
v1->v2:
In this context, "small" is defined as max(SZ_4K, PAGE_SIZE).
This series sets the default minimum resource alignment to
max(SZ_4K, PAGE_SIZE) for memory BARs. In preparation, it makes an
optimization and addresses some corner cases observed when reallocating
BARs. I consider the prepapatory patch
On 8/7/24 03:11, Christophe Leroy wrote:
Hi,
Le 31/07/2024 à 18:35, Guenter Roeck a écrit :
On 7/31/24 08:36, LEROY Christophe wrote:
Hi Guenter,
Thanks for this report. I'm afk this week, i"ll have a look at it in more
détails next week.
But to be sûre, does that Oops match the bisected com
On Wed, Aug 7, 2024 at 7:50 AM David Hildenbrand wrote:
>
> On 07.08.24 13:32, David Hildenbrand wrote:
> > On 07.08.24 00:14, Pasha Tatashin wrote:
> >> nid is needed during memory hot-remove in order to account the
> >> information about the memmap overhead that is being removed.
> >>
> >> In ad
On Fri, Jul 26, 2024 at 04:51:10PM -0700, Sean Christopherson wrote:
> Put the page reference acquired by gfn_to_pfn_prot() if
> kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> than-stellar heuristics for dealing with pfn-mapped memory means that KVM
> can get a page refer
Thanks Robin for having a look.
On Wed, Aug 07, 2024 at 02:13:06PM +0100, Robin Murphy wrote:
> On 2024-08-02 7:03 am, Baruch Siach wrote:
> > When device DMA limit does not fit in DMA32 zone it should use DMA zone,
> > even when DMA zone is stricter than needed.
> >
> > Same goes for devices tha
On 2024-08-02 7:03 am, Baruch Siach wrote:
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Per the bot report this only works
Linus noticed that the error handling in __arch_setup_additional_pages()
fails to clear the mm VDSO pointer if _install_special_mapping()
fails. In practice there should be no actual bug, because if there's an
error the VDSO pointer is cleared later in arch_setup_additional_pages().
However it's n
Now that powerpc no longer uses arch_unmap() to handle VDSO unmapping,
there are no meaningful implementions left. Drop support for it
entirely, and update comments which refer to it.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/mmu_context.h | 5 --
Add a close() callback to the VDSO special mapping to handle unmapping
of the VDSO. That will make it possible to remove the arch_unmap() hook
entirely in a subsequent patch.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/mmu_context.h | 4
arch/
Add an optional close() callback to struct vm_special_mapping. It will
be used, by powerpc at least, to handle unmapping of the VDSO.
Suggested-by: Linus Torvalds
Signed-off-by: Michael Ellerman
---
include/linux/mm_types.h | 2 ++
mm/mmap.c| 3 +++
2 files changed, 5 insertions
On Wed, Aug 7, 2024 at 9:14 PM Maciej W. Rozycki wrote:
>
> On Wed, 7 Aug 2024, Matthew W Carlis wrote:
>
> > > it does seem like this series made wASMedia ASM2824 work better but
> > > caused regressions elsewhere, so maybe we just need to accept that
> > > ASM2824 is slightly broken and doesn't
: 8400291e289ee6b2bf9779ff1c83a291501f017b
patch link:
https://lore.kernel.org/r/5200f289af1a9b80dfd329b6ed3d54e1d4a02876.1722578375.git.baruch%40tkos.co.il
patch subject: [PATCH v5 1/3] dma: improve DMA zone selection
config: i386-randconfig-063-20240807
(https://download.01.org/0day-ci/archive/20240807/202408071931.w1ga8ee2
On 07.08.24 13:32, David Hildenbrand wrote:
On 07.08.24 00:14, Pasha Tatashin wrote:
nid is needed during memory hot-remove in order to account the
information about the memmap overhead that is being removed.
In addition, we cannot use page_pgdat(pfn_to_page(pfn)) during
hotremove after remove_
On Mon, 5 Aug 2024, Matthew W Carlis wrote:
> The most common place where we see our systems getting stuck at Gen1 is with
> device power cycling. If a device is powered on and then off quickly then the
> link will of course fail to train & the consequence here is that the port is
> forced to Gen1
On 07.08.24 00:14, Pasha Tatashin wrote:
nid is needed during memory hot-remove in order to account the
information about the memmap overhead that is being removed.
In addition, we cannot use page_pgdat(pfn_to_page(pfn)) during
hotremove after remove_pfn_range_from_zone().
We also cannot determ
On 07.08.24 00:14, Pasha Tatashin wrote:
It is more logical to update the stat before the page is freed, to avoid
use after free scenarios.
Fixes: 15995a352474 ("mm: report per-page metadata information")
Signed-off-by: Pasha Tatashin
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / d
On Wed, 7 Aug 2024, Matthew W Carlis wrote:
> > it does seem like this series made wASMedia ASM2824 work better but
> > caused regressions elsewhere, so maybe we just need to accept that
> > ASM2824 is slightly broken and doesn't work as well as it should.
>
> One of my colleagues challenged me t
Hi,
Le 31/07/2024 à 18:35, Guenter Roeck a écrit :
On 7/31/24 08:36, LEROY Christophe wrote:
Hi Guenter,
Thanks for this report. I'm afk this week, i"ll have a look at it in
more détails next week.
But to be sûre, does that Oops match the bisected commit ? Because
pmd_leaf() for e500 doesn'
On Tues, 06 Aug 2024 Bjorn Helgaas wrote:
> it does seem like this series made wASMedia ASM2824 work better but
> caused regressions elsewhere, so maybe we just need to accept that
> ASM2824 is slightly broken and doesn't work as well as it should.
One of my colleagues challenged me to provide a m
On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Until now arch_numa was directly translating firmware NUMA information
> to memblock.
I get a link time warning from this:
WARNING: modpost: vmlinux: section mismatch in reference:
numa_set_cpumask+0
From: "Mike Rapoport (Microsoft)"
NUMA emulation can be now enabled on arm64 and riscv in addition to x86.
Move description of numa=fake parameters from x86 documentation of
admin-guide/kernel-parameters.txt
Suggested-by: Zi Yan
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan C
71 matches
Mail list logo
