lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 16 Feb 2020 20:12:53 -0800
From:   Arjun Roy <>
To:     Stephen Rothwell <>
Cc:     Andrew Morton <>,
        Linux Next Mailing List <>,
        Linux Kernel Mailing List <>,
        David Miller <>
Subject: Re: linux-next: build failure after merge of the akpm tree

On Sun, Feb 16, 2020 at 7:57 PM Stephen Rothwell <> wrote:
> Hi all,
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
> mm/memory.c: In function 'insert_pages':
> mm/memory.c:1523:56: error: macro "pte_index" requires 2 arguments, but only 1 given
>    remaining_pages_total, PTRS_PER_PTE - pte_index(addr));
>                                                         ^
> Caused by commit
>   366142f0b000 ("mm/memory.c: add vm_insert_pages()")
> This is the first use of pte_index() outside arch specific code and the
> sparc64 version of pte_index() nas an extra argument.

Looks like this happens for sparc, and also metag. Other platforms
just take the addr parameter based on a quick search.

> I have reverted these commits for today:
>   219ae14a9686 ("net-zerocopy-use-vm_insert_pages-for-tcp-rcv-zerocopy-fix")
>   cb912fdf96bf ("net-zerocopy: use vm_insert_pages() for tcp rcv zerocopy")
>   72c684430b94 ("add missing page_count() check to vm_insert_pages().")
>   dbd9553775f3 ("mm-add-vm_insert_pages-fix")
>   366142f0b000 ("mm/memory.c: add vm_insert_pages()")

In terms of fixing this; passing in an appropriate dir parameter is
not really a problem, but what is concerning that it seems messy to
have a per-platform ifdef to pass it either two arguments or one in
this case. But it seems like either that would be one way to fix it,
or having some arch method across all arches that takes two arguments
(and ignores one of them for most arches).

Is there a general preference for the right way forward, in this case?


> --
> Cheers,
> Stephen Rothwell

Powered by blists - more mailing lists