Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4349795ybv; Sun, 16 Feb 2020 20:13:25 -0800 (PST) X-Google-Smtp-Source: APXvYqzcRjnHK09OD2C+2iKAKGJOVX9WCKdIFUwePaiBSUYmqgyquEIcY+gLgLDdCStbddjLczjq X-Received: by 2002:aca:d483:: with SMTP id l125mr8654597oig.124.1581912805152; Sun, 16 Feb 2020 20:13:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581912805; cv=none; d=google.com; s=arc-20160816; b=AtKbaw/xbJ2x/vUBSraXP83dmxyKcfp8iKaO0jGNYBvslP5BotiYlk/tDx7rCf36J+ RWvF77e2JHB+UI/PS4Mgafjgvpf6ryA13cCwrRNnnmA4R6t3OrW6axwTs9bX/1nYcfEm UeTL5o8XGFnQBdDErIQWqN4wKxyIvfSJPO4zC1GvyDSavsjJjt0KEta4xASuuzuZKf1S 0SgCiWymUfMYb0mZ6dUQupVhydlfIcdmpXs5E0+G7H0hQ/kul7kIAFcO8JolaM6C31lt x1mXI+rs6lry6eslQEkBJXhpPaybZBidvauCy96psED+EuACPV1vS1M+JR3vX8gVOy7r zmig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+t2lAkJHHWrFw6xWV3SgprQvUaUl1BY+kJcD9vJxAFw=; b=wp3agQNTLa/C/T2xs/sxSCxqDvlP2Orx9zQxRTt8wM3bLpvWuPzQztXUH/vQpHdLda B/zcLFEXYHjXBObZrqh+Nyl580mNgzqDk90W7NLkPMHDdzLuNiE+eTDaSsnUZ028cvEt 3jbcWp0GyIA3sZV1hfMlxsCjA9ZOA0UE9VlM2rhdk91G/HhL87C+Egi7zgfPNtu3ygEW ngCzq5VvFsORmhbjd7uAtxn4KDzWa9k/m/NvuyruY12OWsOMhkNl13QVOhVnKR3d6T3f OKUyBkkAcedBaAHueFexT2fOCsrdoWa9t3C6VV4haIueNBHt3DjBVQWzCktVsMzaAzZ5 Vtww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DqBHCUg2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j71si5886858oib.213.2020.02.16.20.13.12; Sun, 16 Feb 2020 20:13:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DqBHCUg2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727362AbgBQENH (ORCPT + 99 others); Sun, 16 Feb 2020 23:13:07 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:41963 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726591AbgBQENH (ORCPT ); Sun, 16 Feb 2020 23:13:07 -0500 Received: by mail-wr1-f67.google.com with SMTP id c9so17938654wrw.8 for ; Sun, 16 Feb 2020 20:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+t2lAkJHHWrFw6xWV3SgprQvUaUl1BY+kJcD9vJxAFw=; b=DqBHCUg2BEqvLrW9aug6Iu5M9vdgPJjktizhhWsUeAu9Myk3h+5eSsIIJphj0G7roz dgn4pQJbXjvsyltRE9cC6TJlZ+F2H/zKmtqph8PZ5Wlyuc0lUStJJcCPwJtPs9RRvd+M fvw+HeUSFawyfABLMJfZeaXjKf6APAuj4KIntzf3+LbMYc3pVNw8HfE0VQZSXrLfCRG+ NNz/Rw9ExeK8O2kWRK80ffyKPdQ4GKcmaG99DCSO8ys6GjrVW/m0Ejcmv5hg5Jp+Q/AR f3kw0avsgwosAwxT3pOISPkuAytimngtFCEPqmalzrl+dX4d+FbjHyEPnW8MDb6jlgXC rtOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+t2lAkJHHWrFw6xWV3SgprQvUaUl1BY+kJcD9vJxAFw=; b=M7l1IkQqWp1APidZO14BwmkGlmw67rMJ6jbedcCXqqXGUeyEGl5FSD9c4PUAn/MDWC eeWIPhp+D80GlT8guukTRYPP8CD2MzzE6X2sw+jYVDwsJAJue/z0bvyRzWZtjgmKb4S4 6sFBh5HOZco94W1PZW2K5JjW6iLsDcI+ookhkwgI1ZRRxg2WikpBtD9e4bjVBY2gXggw ooPrgYRVGwki33HuA9QU07Luri5dmThCJQQXJfe2nGGz7eWfo/G2IGL0yiidR+D15Kob b0pqgOdfTZLzwQuq4XKjOyL/X46X8mRifOGy+qDfDRcNCUFhEGGXdastFWPDtFmhbLjR 5skQ== X-Gm-Message-State: APjAAAWUzM7qKf86wDnj5W8/0t04hqqxrxRVeX/PGngPd2SUj65NHRF9 CPn6fZAcon9yshB7PbKXwTzp+PABI4MA1ddWwd1DCg== X-Received: by 2002:a5d:6545:: with SMTP id z5mr18921279wrv.3.1581912784734; Sun, 16 Feb 2020 20:13:04 -0800 (PST) MIME-Version: 1.0 References: <20200217145711.4af495a3@canb.auug.org.au> In-Reply-To: <20200217145711.4af495a3@canb.auug.org.au> From: Arjun Roy Date: Sun, 16 Feb 2020 20:12:53 -0800 Message-ID: Subject: Re: linux-next: build failure after merge of the akpm tree To: Stephen Rothwell Cc: Andrew Morton , Linux Next Mailing List , Linux Kernel Mailing List , David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Thanks, -Arjun > -- > Cheers, > Stephen Rothwell