On 9/25/19 9:36 AM, Ravi Bangoria wrote:
v3: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-July/193339.html
v3->v4:
- Instead of considering exception as extraneous when dar is outside of
user specified range, analyse the instruction and check for overlap
between user specifi
This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.
Test page table and memory p
alloc_gigantic_page() implements an allocation method where it scans over
various zones looking for a large contiguous memory block which could not
have been allocated through the buddy allocator. A subsequent patch which
tests arch page table helpers needs such a method to allocate PUD_SIZE
sized
This series adds a test validation for architecture exported page table
helpers. Patch in the series adds basic transformation tests at various
levels of the page table. Before that it exports gigantic page allocation
function from HugeTLB.
This test was originally suggested by Catalin during arm6
Hello David,
patch 05/10 is missing in the patch series.
On Sun, 06. Oct 10:56, David Hildenbrand wrote:
> From: "Aneesh Kumar K.V"
>
> With an altmap, the memmap falling into the reserved altmap space are
> not initialized and, therefore, contain a garbage NID and a garbage
> zone. Make sure
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On 06.10.19 21:58, Damian Tometzki wrote:
> Hello David,
>
> patch 05/10 is missing in the patch series.
>
Hi Damian,
not really. Could be that lkml is slow today. E.g., check
https://marc.info/?l=linux-mm&m=157035222620403&w=2
and especially
https://marc.info/?l=linux-mm&m=157035225120440&
https://bugzilla.kernel.org/show_bug.cgi?id=200449
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285369
--> https://bugzilla.kernel.org/attachment.cgi?id=285369&action=edit
kernel .config (5.4-rc1, PowerMac G4 DP)
--
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Bug ID: 205099
Summary: KASAN hit at raid6_pq: BUG: Unable to handle kernel
data access at 0x00f0fd0d
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.4-rc1
Fixes gcc '-Wunused-but-set-variable' warning:
sound/soc/fsl/fsl_mqs.c: In function fsl_mqs_hw_params:
sound/soc/fsl/fsl_mqs.c:54:6: warning: variable bclk set but not used
[-Wunused-but-set-variable]
It is never used, so can be removed.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
This series fixes the access of uninitialized memmaps when shrinking
zones/nodes and when removing memory. Also, it contains all fixes for
crashes that can be triggered when removing certain namespace using
memunmap_pages() - ZONE_DEVICE, reported by Aneesh.
We stop trying to shrink ZONE_DEVICE, a
Let's drop the basically unused section stuff and simplify.
Also, let's use a shorter variant to calculate the number of pages to
the next section boundary.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbran
Get rid of the unnecessary local variables.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 15 ++-
1 file changed, 6 insertions(+), 9 deleti
If we have holes, the holes will automatically get detected and removed
once we remove the next bigger/smaller section. The extra checks can
go.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: David Hildenbrand
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David
With shrink_pgdat_span() out of the way, we now always have a valid
zone.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 4 ++--
1 file changed, 2 inser
Let's poison the pages similar to when adding new memory in
sparse_add_section(). Also call remove_pfn_range_from_zone() from
memunmap_pages(), so we can poison the memmap from there as well.
While at it, calculate the pfn in memunmap_pages() only once.
Cc: Andrew Morton
Cc: David Hildenbrand
C
We currently try to shrink a single zone when removing memory. We use the
zone of the first page of the memory we are removing. If that memmap was
never initialized (e.g., memory was never onlined), we will read garbage
and can trigger kernel BUGs (due to a stale pointer):
:/# [ 23.912993] BUG:
Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We
should never try to touch the memmap of offline sections where we could
have uninitialized memmaps and could trigger BUGs when calling
page_to_nid() on poisoned pages.
There is no reliable way to distinguish an uninitialized
We might use the nid of memmaps that were never initialized. For
example, if the memmap was poisoned, we will crash the kernel in
pfn_to_nid() right now. Let's use the calculated boundaries of the separate
zones instead. This now also avoids having to iterate over a whole bunch of
subsections again
From: "Aneesh Kumar K.V"
The third argument is actually number of pages. Changes the variable name
from size to nr_pages to indicate this better.
No functional change in this patch.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Oscar Salvador
Cc: Mel Gorman
Cc: Mike Rapoport
From: "Aneesh Kumar K.V"
With an altmap, the memmap falling into the reserved altmap space are
not initialized and, therefore, contain a garbage NID and a garbage
zone. Make sure to read the NID/zone from a memmap that was initialzed.
This fixes a kernel crash that is observed when destroying a
On 05.10.19 08:13, Aneesh Kumar K.V wrote:
> On 10/4/19 2:33 PM, David Hildenbrand wrote:
>> On 04.10.19 11:00, David Hildenbrand wrote:
>>> On 03.10.19 18:48, Aneesh Kumar K.V wrote:
On 10/1/19 8:33 PM, David Hildenbrand wrote:
> On 01.10.19 16:57, David Hildenbrand wrote:
>> On 01.10
23 matches
Mail list logo
