From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4C07C001DB for ; Mon, 14 Aug 2023 20:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF4CE8E0009; Mon, 14 Aug 2023 16:55:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7D588E0003; Mon, 14 Aug 2023 16:55:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD0618E0009; Mon, 14 Aug 2023 16:55:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BAFEE8E0003 for ; Mon, 14 Aug 2023 16:55:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7DEC8A0C6B for ; Mon, 14 Aug 2023 20:55:21 +0000 (UTC) X-FDA: 81123915642.05.AEC3BFE Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf26.hostedemail.com (Postfix) with ESMTP id 95DAC140015 for ; Mon, 14 Aug 2023 20:55:19 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="CT/zqs6l"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692046519; a=rsa-sha256; cv=none; b=2meRs6NMpNTUtwabvI0gnblS3RGfYHFlUQDaREdO/W5jtm1vxM8xGLwbGAuH8HateYOn5J JJLj1lRcDgIQiaVUsoRYSyCXfF4KSx+rJd7KxfkVLsI56n5H48ZvqEiMPTqLMSn6BWRNYy +Bd0DJKqLdodAUHT6q6/8UfGaG73gH4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="CT/zqs6l"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692046519; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=a9dZ73eR63TSb0FHn05N7SRusCzdcPNZECU/wwItrsA=; b=SAPGK4PEgiSaXMPS6feLPXsmky+CJ1as6u9XEb5ps9ssD4nvGJMiIIjt2o99Frg6aiHBx7 W3420IF80vKdjj0+vVkriclaxHP9iSmJPvWdAMXuyqGOaTGcVd45TcwlhXo8sw9qsazmMm dc0N4TQqD2Vv9gVVxIsLUrAV6w8IO3k= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-586a684e85aso52880637b3.2 for ; Mon, 14 Aug 2023 13:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692046518; x=1692651318; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=a9dZ73eR63TSb0FHn05N7SRusCzdcPNZECU/wwItrsA=; b=CT/zqs6lJKr3IfioiSPcoTqQijaIZMdovkYnMzXHL3dISU1OXQVB8oP/rosR6VG1Nk lk6QLIMtLfgJrClVCLM5EFZ1ggyfRryLdH9aBG+cZ2+rfRBrd5Lz92/4ZR97/Na2mUEm LiekPHyTIbtNI2/hUZvj2pKOac3rjWY3zJ6LVIMkC41sOmd1Q66cUYFRg/WigvWvOrk7 TVRDn4lw67otYTkb6Fqg5c66mmdw9NaNWCOz34GBrrMFgaAgxQiWJPi15fNb+xwbHRNU b0QjqcCKra+VKpc7bPoCqzJWhSYAVeYOZtafUeBN2OCvvCJk7fjh5pWoGlyXiE7KJwKJ EH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692046518; x=1692651318; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a9dZ73eR63TSb0FHn05N7SRusCzdcPNZECU/wwItrsA=; b=WTZEJazvov5jSb9SZRxNS4pUh0Ci/fxahRV2mGTnqUy2LnjpGysQWEj41gaQ1kl1/D TI/OD9K08WN/NgXn9gt9c1vMZwcuRcVL+e1GQbD0vGuSEirIDR21bUPrtfTMiCHGQwwT HrcNsHYMfirSZgtjskEAkkO42aw+dZVIVkA0Sux+BxWMUUg/PAxBDrlAeURa7Bw7EWFM HK5D9nn7XYElcQpqGvUcLuILyURBwguL6t7Cwbg4f0ntHWNMbcbiiYRHecj1BQo3/J8V 8XYTLUXk7EDbI51oovLsucERkb3fzqBcxp9QMEFbVqUslkkxzgAkMVImHRi4KzIoC646 yepA== X-Gm-Message-State: AOJu0YxMzDP5Vhrmhq/9ty0u4CvpJrq3SRdUt97hyt697S4XpkSiylu9 JNtkX1m0WVKb/PhJpYGw/uLnqVFr7Xl6glHQ63/YOQ== X-Google-Smtp-Source: AGHT+IFfSwl3rDi87AUO872jchrVGVY0U9LzJycxnEERl17SfkCwqGVZyZzMjhHVa+54K2gFqsMvhmfl00YPO/9KzP8= X-Received: by 2002:a5b:70a:0:b0:d09:33b0:f4e4 with SMTP id g10-20020a5b070a000000b00d0933b0f4e4mr10444404ybq.4.1692046518432; Mon, 14 Aug 2023 13:55:18 -0700 (PDT) MIME-Version: 1.0 References: <202308131610.jF4ncWp6-lkp@intel.com> <20230814130623.90cf2bc8c625087ea616dd3c@linux-foundation.org> <20230814134139.1a590870aa184f2ed34fd923@linux-foundation.org> In-Reply-To: <20230814134139.1a590870aa184f2ed34fd923@linux-foundation.org> From: Suren Baghdasaryan Date: Mon, 14 Aug 2023 13:55:07 -0700 Message-ID: Subject: Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? To: Andrew Morton Cc: kernel test robot , "Matthew Wilcox (Oracle)" , oe-kbuild-all@lists.linux.dev, Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 95DAC140015 X-Stat-Signature: r5nskp87d6q4hnfojtid8ppjjri8pwn5 X-HE-Tag: 1692046519-487130 X-HE-Meta: U2FsdGVkX1/teWyMjk+hBi3Vl5WwQlRwHYcyssEDmDHp15Lc8mv9JAuXzxn5aQidu2TrRjJRKp08COvKtvY34v/A9BMW4MauA3d6RYdUwsdgIDUhnFWzNTV8GsMQwt1sQ4BAZ5UptaRrNUZ9u5Ox1f/1EaR8Ays8Na2PsRjYkIKjXX63fJ4c7T0jCMzz32lcnA1LgsKzbJvP1NkNXDHokFhIl9gJ+XV7acJzDSiaKIkyJFhDk2O32FA41CSVbcOvrfmwIiK63Gjp8nvWZTzSKgXUL4uTS3RgFlaOuEerCuHW2umS0gtrckiqdGVDS21ve7I89145LQPqxIDNX4U3UvDltmbksFpwlmOM2Kehpgcttqh5H+zB60DMFedpA+6UJrgEN9Z/dl3gUR1G78MnoccIXYBNtsAQXjczdW4SvBHG49EF0ObM2Ql0HFPKN9WUf+HE0okR+JSA2iFGK/fhco5jE4SOHvYQ951RWB/Bq23N7dYRq/W0Tgho1jRqEu/jOxmjmmC0CmlmA+7mN712G2hJ6W4MY45nM7wX+TGwAqigGGNAKW436YEa/Md+tGOt4siN4nCVskcS5Wy4/jqaMJP4gnexegtO7YSF6pV8dcPsASwNBerxrioqy8HmxF2sttno75Lw2i1gN8gZgFRl61za8E6KSNSpfJl4iT5nXKzrkInEBTl9FMyfme42/pyy8QnsZNomzaoI1bz3hAPlIiKH3y/yEmJgSxIalUrBqO3sg7X3jG/KGnjXEZcEFsvdt4g/HaLQhv28U/MWdMVz/TPX+hh052o1Yks+/qAUCD7AeGjAZBb5hZ//dRkMmqHr7g5VGzx63gy7X4P4V9NyJoWxew0LWLuA18PbqZtLspW/MY5yLP9xfqOLqP61yv6BPK2aBw6TgZkHSMS1RRMBozWzcJh2D2GHp393oI9pS5UqaBij7YWAc+/KrvuaosbUwmgWRY8eHNeeJeHnmCw CC/wJBaM jpMtGHpgbeS/cxNwhhQhFc5xPc/K8wpAafz2y77Fc053wT9V05OFkRqMrMnZXE9rn/LrRgtS0cNc6vXKxbixIjnSTi3z+3oCoYXd3/Tm/x+MJunqh737Czx/ERg6nESnV7oviQA1+ZtaeMU9ljCUeD+U5xuSZTvIDHwTvOuNh9cHmzb3qnKweh7840EhELd0+9llk2iR1Es/22dRIVmx2hMEvzAMKw1xzWeTiU0NOCGNWamRainIX972OJ58zJSUfZOFgoKHuX9C2NcDKAxhrR0cl/j7M5hTl6Bj8pLt07DZFxbOUuXtexY4mzqSVgMXP7eC6VYbJluXAzbjLUs4zzpxzys1dUmlowVeXH/qnv6qsfmBiweX2Tx6BcWDGF4GYMGXS1lu1mjjpOWvy65l84RLw5NBNi7p4BmhasMWt51Zq4J/EnM0/3OEuGwZwxPLMHAsCTtBgVYBpmdSjI7Rl8reDJo1GnmWETbdPgyQpIDKQ4YDhvG1lJfY0p/75Mk5fSYD4/Q0y6HAi1t1bleZOfNdxp6fd8Pk78/wH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Aug 14, 2023 at 1:41=E2=80=AFPM Andrew Morton wrote: > > On Mon, 14 Aug 2023 13:33:19 -0700 Suren Baghdasaryan = wrote: > > > Andrew, is "mm: handle userfaults under VMA lock" merged into > > mm-stable? I could not find it and in fact the whole "Per-VMA lock > > support for swap and userfaults" patchset > > (https://lore.kernel.org/all/CAJuCfpHSFikZ=3Dh34yS980BmUP5M=3D+j6rB4_b-= q7MCc10Xs24+w@mail.gmail.com/) > > seems to be missing in mm-stable. That's problematic because Matthew's > > "Handle most file-backed faults under the VMA lock" patchset > > (https://lore.kernel.org/all/20230724185410.1124082-1-willy@infradead.o= rg/) > > requires at least one patch from my patchset to work correctly, this > > one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@google= .com/. > > > > An additional note, > > https://lore.kernel.org/all/20230812002033.1002367-1-willy@infradead.or= g/ > > is fixing a known issue in "Handle most file-backed faults under the > > VMA lock" patchset and it's missing from mm-stable too. As Matthew > > mentioned in that patch, ideally it should be placed before "mm: > > handle faults that merely update the accessed bit under the VMA lock" > > > > I was unaware of these dependencies. I didn't notice the reordering in mm-unstable but now I see them reordered there as well. Should have warned you earlier :( > > All the above-mentioned patches are in mm-unstable, so we have > bisection holes. > > If I get sent a replacement patch series, I'll move it to > back-of-queue, because I'll assume all previous testing is invalidated. > I assume this is how this misordering came about. If I get sent > little -fix patches, I don't do this reordering. Possibly the recent riscv fixup for my patch series reordered things... Reordering my patchset before Matthew's would fix that bisection hole but up to you. I was just worried that if one patchset is merged without the other, this hole would produce multiple issues.