Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1594541 > unrolled thread

Re: [PATCH v2 2/2] mm, page_alloc: avoid page_to_pfn() when merging buddies

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 2/2] mm, page_alloc: avoid page_to_pfn() when merging buddies Tony Luck <tony.luck@gmail.com> - 2017-03-07 20:00 +0100
    Re: [PATCH v2 2/2] mm, page_alloc: avoid page_to_pfn() when merging buddies Tony Luck <tony.luck@gmail.com> - 2017-03-07 20:50 +0100

#1594541 — Re: [PATCH v2 2/2] mm, page_alloc: avoid page_to_pfn() when merging buddies

On Fri, Dec 16, 2016 at 4:00 AM, Vlastimil Babka <vbabka@suse.cz> wrote:
> On architectures that allow memory holes, page_is_buddy() has to perform
> page_to_pfn() to check for the memory hole. After the previous patch, we have
> the pfn already available in __free_one_page(), which is the only caller of
> page_is_buddy(), so move the check there and avoid page_to_pfn().
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Acked-by: Mel Gorman <mgorman@techsingularity.net>

git bisect says this patch is the cause of an ia64 crash early in boot.

Reverting 13ad59df67f19788f6c22985b1a33e466eceb643
from v4.11-rc1 makes it boot again.

The commit messages talks about the "only caller" of page_is_buddy().
But grep shows two call sites:

mm/page_alloc.c:816:            if (!page_is_buddy(page, buddy, order))
mm/page_alloc.c:876:            if (page_is_buddy(higher_page,
higher_buddy, order + 1)) {


The crash happens due to a bad pointer in free_one_page()

Initmem setup node 0 [mem 0x0000000001000000-0x00000004fbffffff]
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 260199
Policy zone: Normal
Kernel command line: BOOT_IMAGE=scsi0:\efi\SuSE\l-bisect.gz
console=tty1 console=uart,io,0x3f8 intel_iommu=off root=/dev/sda3
DMAR: IOMMU disabled
PID hash table entries: 4096 (order: -1, 32768 bytes)
Sorting __ex_table...
software IO TLB [mem 0x060b0000-0x0a0b0000] (64MB) mapped at
[e0000000060b0000-e00000000a0affff]
Unable to handle kernel paging request at virtual address a07fffffffc80018
swapper[0]: Oops 11012296146944 [1]
Modules linked in:

CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-bisect-06032-g13ad59d #12
task: a000000101300000 task.stack: a000000101300000
psr : 00001210084a2010 ifs : 8000000000000a98 ip  :
[<a0000001001cc1e1>]    Not tainted (4.10.0-bisect-06032-g13ad59d)
ip is at free_one_page+0x561/0x740
unat: 0000000000000000 pfs : 0000000000000a98 rsc : 0000000000000003
rnat: 20c49ba5e353f7cf bsps: 04ba52743edc9494 pr  : 966696816682aa69
ldrs: 0000000000000000 ccv : 00000000000355b9 fpsr: 0009804c8a70433f
csd : 0930ffff00063000 ssd : 0930ffff00063000
b0  : a0000001001cc170 b6  : a0000001011a43c0 b7  : a000000100721ba0
f6  : 000000000000000000000 f7  : 1003e0044b82fa09b5a53
f8  : 1003e0000000000000000 f9  : 1003e00000000000016e8
f10 : 1003e0000000000000008 f11 : 1003e20c49ba5e353f7cf
r1  : a000000101a8ef60 r2  : 000000000000000e r3  : 0000000000000000
r8  : 0000000000000001 r9  : 0000000000000000 r10 : 0000000000230000
r11 : 000000000004fc00 r12 : a00000010130fdb0 r13 : a000000101300000
r14 : 0000000000000000 r15 : a07fffffffc80000 r16 : ffffffffffff0000
r17 : 0000000000000001 r18 : a07fffffffdd0037 r19 : 000000000000000c
r20 : 0000000000000001 r21 : a00000010130fdcc r22 : 0000000000044000
r23 : ffffffffffffff80 r24 : a07fffffffd60018 r25 : 0010000000000000
r26 : 0010000000000000 r27 : a07fffffffd60030 r28 : 0000000000000100
r29 : a0000001018b99c8 r30 : a0000001018b99c8 r31 : 000000000004fc00
unwind: cannot stack reg state!
unwind.desc_label_state(): out of memory
unwind: stack underflow!
unwind: failed to find state labeled 0x1

[toc] | [next] | [standalone]

#1594591

On Tue, Mar 7, 2017 at 10:40 AM, Tony Luck <tony.luck@gmail.com> wrote:
> The commit messages talks about the "only caller" of page_is_buddy().
> But grep shows two call sites:
>
> mm/page_alloc.c:816:            if (!page_is_buddy(page, buddy, order))
> mm/page_alloc.c:876:            if (page_is_buddy(higher_page,

and it looks like the second one is the problem:

        if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)) {
                struct page *higher_page, *higher_buddy;
                combined_pfn = buddy_pfn & pfn;
                higher_page = page + (combined_pfn - pfn);
                buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
                higher_buddy = higher_page + (buddy_pfn - combined_pfn);
                if (page_is_buddy(higher_page, higher_buddy, order + 1)) {
                        list_add_tail(&page->lru,
                                &zone->free_area[order].free_list[migratetype]);
                        goto out;
                }
        }

Although outer "if" checked for pfn_valid_within(buddy_pfn),
we actually pass "higher_buddy" to this call of page_is_buddy().

-Tony

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web