Attaching the dmesg logs.
On 28/02/25 11:49 am, Venkat Rao Bagalkote wrote:
Greetings!!
I am seeing memory hot plug self test is failing on power-pc kernel on
IBM P11 system.
Kernel Version: 6.14.0-rc4-g09a81ff40389
Logs:
[stdlog] TAP version 13
[stdlog] 1..1
[stdlog] # timeout set to 45
Greetings!!
I am seeing memory hot plug self test is failing on power-pc kernel on
IBM P11 system.
Kernel Version: 6.14.0-rc4-g09a81ff40389
Logs:
[stdlog] TAP version 13
[stdlog] 1..1
[stdlog] # timeout set to 45
[stdlog] # selftests: memory-hotplug: mem-on-off-test.sh
[stdlog] # Test scope
Several functions internal to FS DAX use the following pattern when
trying to obtain an unlocked entry:
xas_for_each(&xas, entry, end_idx) {
if (dax_is_locked(entry))
entry = get_unlocked_entry(&xas, 0);
This is problematic because get_unlocked_entry() will get the next
pr
PCI P2PDMA pages are not mapped with pXX_devmap PTEs therefore the
check in __gup_device_huge() is redundant. Remove it
Signed-off-by: Alistair Popple
Reviewed-by: Jason Gunthorpe
Reviewed-by: Dan Wiliams
Acked-by: David Hildenbrand
---
mm/gup.c | 5 -
1 file changed, 5 deletions(-)
diff
dax_layout_busy_page_range() is used by file systems to scan the DAX
page-cache to unmap mapping pages from user-space and to determine if
any pages in the given range are busy, either due to ongoing DMA or
other get_user_pages() usage.
Currently it checks to see the file mapping is mapped into us
Device DAX pages are currently not reference counted when mapped,
instead relying on the devmap PTE bit to ensure mapping code will not
get/put references. This requires special handling in various page
table walkers, particularly GUP, to manage references on the
underlying pgmap to ensure the page
Andrew,
This is essentially the same as what's currently in mm-unstable aside from
the two updates listed below. The main thing to note is it incorporates
Balbir's fixup which is currently in mm-unstable as c98612955016
("mm-allow-compound-zone-device-pages-fix-fix")
- Alistair
On Fri, Feb 28,
File systems call dax_break_mapping() prior to reallocating file system
blocks to ensure the page is not undergoing any DMA or other
accesses. Generally this is needed when a file is truncated to ensure that
if a block is reallocated nothing is writing to it. However filesystems
currently don't cal
Main updates since v8:
- Fixed reading of bad pgmap in migrate_vma_collect_pmd() as reported/fixed
by Balbir.
- Fixed bad warnings generated in free_zone_device_folio() when pgmap->ops
isn't defined, even if it's not required to be. As reported by Gerald.
Main updates since v7:
- Rebas
Prior to any truncation operations file systems call
dax_break_mapping() to ensure pages in the range are not under going
DMA. Later DAX page-cache entries will be removed by
truncate_folio_batch_exceptionals() in the generic page-cache code.
However this makes it possible for folios to be removed
The page ->mapping pointer can have magic values like
PAGE_MAPPING_DAX_SHARED and PAGE_MAPPING_ANON for page owner specific
usage. Currently PAGE_MAPPING_DAX_SHARED and PAGE_MAPPING_ANON alias to the
same value. This isn't a problem because FS DAX pages are never seen by the
anonymous mapping code
Currently fs dax pages are considered free when the refcount drops to
one and their refcounts are not increased when mapped via PTEs or
decreased when unmapped. This requires special logic in mm paths to
detect that these pages should not be properly refcounted, and to
detect when the refcount drop
From: Dan Williams
The dcssblk driver has long needed special case supoprt to enable
limited dax operation, so called CONFIG_FS_DAX_LIMITED. This mode
works around the incomplete support for ZONE_DEVICE on s390 by forgoing
the ability of dax-mapped pages to support GUP.
Now, pending cleanups to
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
folio_is_longterm_pinnable() return false for FS DAX pages.
Signed-off-by: Alistair Popple
Reviewed-by: John Hubbard
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce vmf_insert_folio_pud. This will map the entire PUD-sized folio
and take references as it would for a normally mapped page.
This is distinct from the cu
In preparation for using insert_page() for DAX, enhance
insert_page_into_pte_locked() to handle establishing writable
mappings. Recall that DAX returns VM_FAULT_NOPAGE after installing a
PTE which bypasses the typical set_pte_range() in finish_fault.
Signed-off-by: Alistair Popple
Suggested-by:
Currently DAX folio/page reference counts are managed differently to normal
pages. To allow these to be managed the same as normal pages introduce
vmf_insert_folio_pmd. This will map the entire PMD-sized folio and take
references as it would for a normally mapped page.
This is distinct from the cu
Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
creates a special devmap PTE entry for the pfn but does not take a
reference on the underlying struct page for the mapping. This is
because DAX page refcounts are treated specially, as indicated by the
presence of a devmap entry.
The rmap doesn't currently support adding a PUD mapping of a
folio. This patch adds support for entire PUD mappings of folios,
primarily to allow for more standard refcounting of device DAX
folios. Currently DAX is the only user of this and it doesn't require
support for partially mapped PUD-sized
Zone device pages are used to represent various type of device memory
managed by device drivers. Currently compound zone device pages are
not supported. This is because MEMORY_DEVICE_FS_DAX pages are the only
user of higher order zone device pages and have their own page
reference counting.
A futu
Currently ZONE_DEVICE page reference counts are initialised by core
memory management code in __init_zone_device_page() as part of the
memremap() call which driver modules make to obtain ZONE_DEVICE
pages. This initialises page refcounts to 1 before returning them to
the driver.
This was presumabl
A FS DAX page is considered idle when its refcount drops to one. This
is currently open-coded in all file systems supporting FS DAX. Move
the idle detection to a common function to make future changes easier.
Signed-off-by: Alistair Popple
Reviewed-by: Jan Kara
Reviewed-by: Christoph Hellwig
Re
Prior to freeing a block file systems supporting FS DAX must check
that the associated pages are both unmapped from user-space and not
undergoing DMA or other access from eg. get_user_pages(). This is
achieved by unmapping the file range and scanning the FS DAX
page-cache to see if any pages within
FS DAX requires file systems to call into the DAX layout prior to unlinking
inodes to ensure there is no ongoing DMA or other remote access to the
direct mapped page. The fuse file system implements
fuse_dax_break_layouts() to do this which includes a comment indicating
that passing dmap_end == 0 l
configs may be tested in the coming days.
tested configs:
alphaallyesconfiggcc-14.2.0
arc randconfig-001-20250227gcc-13.2.0
arc randconfig-002-20250227gcc-13.2.0
arm randconfig-001-20250227gcc-14.2.0
Hi Vaibhav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on powerpc/fixes]
[also build test WARNING on kvm/queue kvm/next powerpc/topic/ppc-kvm
linus/master v6.14-rc4 next-20250227]
[cannot apply to powerpc/next kvm/linux-next]
[If your patch is applied to
On Tue, 25 Feb 2025 18:00:42 +0530, Athira Rajeev wrote:
> Perf probe on vfs_fstatat fails as below on a powerpc system
>
> ./perf probe -nf --max-probes=512 -a 'vfs_fstatat $params'
> Segmentation fault (core dumped)
>
> This is observed while running perftool-testsuite_probe testcase.
>
> [...
On Tue, 25 Feb 2025 17:01:57 +0530, Athira Rajeev wrote:
> Perf trace on perf.data fails as below:
>
> ./perf trace record -- sleep 1
> ./perf trace -i perf.data
> perf: Segmentation fault
> Segmentation fault (core dumped)
>
> [...]
Applied to perf-tools-next, thanks!
Be
On Thu, 27 Feb 2025 09:00:06 +0530
Madhavan Srinivasan wrote:
> On 2/27/25 3:44 AM, Erhard Furtner wrote:
> > On Mon, 23 Dec 2024 23:58:26 +1100
> > Michael Ellerman wrote:
> >
> >> Erhard Furtner writes:
> >>> Greetings!
> >>>
> >>> I am aware there is commit cf89c9434af122f28a3552e6f9cc5
On Thu, 27 Feb 2025 10:42:44 +0530
Ritesh Harjani (IBM) wrote:
> Since only the swapon failed, I think you might still have the console
> up right? So this is mostly a vmalloc allocation failure report?
Correct. The machine stays usable via VNC in my case, even after the vmalloc
allocation fail
Le 27/02/2025 à 15:05, Michael Kelley a écrit :
From: Christophe Leroy Sent: Thursday, February
27, 2025 2:43 AM
Le 27/02/2025 à 02:38, Stephen Rothwell a écrit :
Hi Venkat,
CC Kees Cook for advice. This is a result of the tests added in commit
bbeb38b8487a ("string.h: Validate mem
Le 27/02/2025 à 14:47, Venkat Rao Bagalkote a écrit :
Hello,
Attached is the .config file.
This is being run on IBM Power8 system in PowerVM mode, as a full system
LPAR.
Ah ok so you are using a quite old version of GCC, that is GCC 8.5
I get the same problem when building ppc64_defconf
From: Christophe Leroy Sent: Thursday, February
27, 2025 2:43 AM
>
> Le 27/02/2025 à 02:38, Stephen Rothwell a écrit :
> > Hi Venkat,
> >
> > CC Kees Cook for advice. This is a result of the tests added in commit
> >
> >bbeb38b8487a ("string.h: Validate memtostr*()/strtomem*() arguments mor
On Wed, Feb 19, 2025 at 02:53:03PM +0100, Brendan Jackman wrote:
> Argh, sorry, GMail switched back to HTML mode somehow. Maybe I have to
> get a proper mail client after all.
Yap, wouldn't be such a bad idea. And yes, it ain't easy - we have a whole doc
about it:
Documentation/process/email-clie
Hi Mike,
Drive by review comments below...
On 23/10/2024 17:27, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Using large pages to map text areas reduces iTLB pressure and improves
> performance.
>
> Extend execmem_alloc() with an ability to use huge pages with ROX
> permission
Le 27/02/2025 à 02:38, Stephen Rothwell a écrit :
Hi Venkat,
CC Kees Cook for advice. This is a result of the tests added in commit
bbeb38b8487a ("string.h: Validate memtostr*()/strtomem*() arguments more
carefully")
from the kspp tree.
I note that the comment about memtostr() says "C
Le 27/02/2025 à 06:12, Ritesh Harjani a écrit :
Erhard Furtner writes:
Greetings!
At boot with a KASAN-enabled v6.14-rc4 kernel on my PowerMac G4 DP I get:
[...]
vmalloc_node_range for size 4198400 failed: Address range restricted to
0xf100 - 0xf511
swapon: vmalloc error: size 41
37 matches
Mail list logo
