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 7A08FC74A5B for ; Sun, 26 Mar 2023 22:48:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 718576B0072; Sun, 26 Mar 2023 18:48:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C8E16B0074; Sun, 26 Mar 2023 18:48:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56A546B0075; Sun, 26 Mar 2023 18:48:29 -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 44DF96B0072 for ; Sun, 26 Mar 2023 18:48:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0550BA04E7 for ; Sun, 26 Mar 2023 22:48:28 +0000 (UTC) X-FDA: 80612539938.22.FAD35B5 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf06.hostedemail.com (Postfix) with ESMTP id 756DF180007 for ; Sun, 26 Mar 2023 22:48:25 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="eSv/r4S8"; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679870907; 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=9fZkdxeeHkFCzAR8aqy81oHdx9YlDO1HnuZfhrn/TQ8=; b=zIvJdqRwDjkDgw76GHnjq90lt97EnjnzdCSD2Cq3CepO89CNtiZtnvq6c8Z2Unl72uDvjx VfxpsNIxUmUmta0k2y08/B/nfLj9k0GzfqV3Yzl19fKaqoTOrk2Uxt3zaErsEs5+UgZfJE a0j4CgHWsobr4l7xz0EMJPWRp+MMhNs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="eSv/r4S8"; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679870907; a=rsa-sha256; cv=none; b=xtg4y3t3eT+1RGiT0x137DnbVW2UClNw1My79D6JPkXtwpN64+N1f3N8+AP3UPKy48Sf6Z vddUWxfYaxfLul7aeH6pIiJymq6ovNmhmPWk+LGg7lC2IfIdPH7928macJMho6JlSyi/k9 EL88qeQr8HjiWCxTqwfRyvAntIstLIU= Received: by mail-ed1-f48.google.com with SMTP id eh3so28609323edb.11 for ; Sun, 26 Mar 2023 15:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1679870903; 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=9fZkdxeeHkFCzAR8aqy81oHdx9YlDO1HnuZfhrn/TQ8=; b=eSv/r4S8HeF5JxW79ORKgU8fYq/vw/bKT+NR9Y79aZYWhgWtjPO9M1jZEUmvpDyp+e gBboqx3KXWTg7FNdY7YNr/4vgkMTPadAOXje14caUSXNzIe5x7ISDbWZh5W+cqe7bkpi 6ytZ6z0e4qmBbDyEWapGtnPeLP6pPgCYYj/wY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679870903; 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=9fZkdxeeHkFCzAR8aqy81oHdx9YlDO1HnuZfhrn/TQ8=; b=Xrr8ZA36UtCtPJ+GHRyRnjjTqEYZELACsk9dYb7R1BEROta3Icv2Stj4ROnt2B4amc wZQyASEWK9IuEmDf/yu0A9+tAhO6xTJp3k9N4IhZq3yLqy/W5I3cLuStEpYyRtZeMerX RHITz8DQQgjhRGIhC97bQ/JiZSo1MCNITM8GS66Ta1WRKIwY6iG34OpyABxdp8wQdJ64 bzoJZm2oPKDrwtoGjogawaMgoI8/p28TCY/miVUWyztJbHnivxR43ODdB8P0tbrrud/U g7E5hhUPT8qBkSwbvvDABEqgcvs09ZmYrt/tx2c3KITEp6hJk2x9V7J9x2BSN4E1d/Ab t1cQ== X-Gm-Message-State: AAQBX9dZ9O9eSz/4qrBBiO+Vkz1Z+7VvLF1ySROUo3bO7zsY7E4jdSZN mMlH2sOhX9m8c9yMdeBEb6ej+CGcaJZntu5A3v0qww== X-Google-Smtp-Source: AKy350bCBam0nrY1p8TejkfJficPyZrgXjDf/wItADQkgyaT8kNg9OAFFISf9Bb253S/VVRRVeXA1g== X-Received: by 2002:aa7:c65a:0:b0:501:c3de:dc5c with SMTP id z26-20020aa7c65a000000b00501c3dedc5cmr10327359edr.18.1679870903392; Sun, 26 Mar 2023 15:48:23 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id x92-20020a50bae5000000b004fa19f5ba99sm14052618ede.79.2023.03.26.15.48.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 15:48:22 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id w9so28746445edc.3 for ; Sun, 26 Mar 2023 15:48:22 -0700 (PDT) X-Received: by 2002:a17:907:7b8a:b0:931:6e39:3d0b with SMTP id ne10-20020a1709077b8a00b009316e393d0bmr4811641ejc.15.1679870902220; Sun, 26 Mar 2023 15:48:22 -0700 (PDT) MIME-Version: 1.0 References: <20230324130530.xsmqcxapy4j2aaik@box.shutemov.name> <20230325163323.GA3088525@google.com> <20230326022658.GB3142556@google.com> In-Reply-To: <20230326022658.GB3142556@google.com> From: Linus Torvalds Date: Sun, 26 Mar 2023 15:48:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: WARN_ON in move_normal_pmd To: Joel Fernandes Cc: "Kirill A. Shutemov" , Michal Hocko , Naresh Kamboju , Andrew Morton , linux-mm@kvack.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nc8gh4eyink7116pi7sdszhh7yd9um1e X-Rspam-User: X-Rspamd-Queue-Id: 756DF180007 X-Rspamd-Server: rspam06 X-HE-Tag: 1679870905-568333 X-HE-Meta: U2FsdGVkX1+pvflCASglLOSlCr65qriwnnUwNaFtDE9KhNmOPSj17TSq9rT19M10As0o+apLSK9dAUTS3W/zoJnyE5CkIwWZsZcS4Muw6cAJDzAzesUz5+IYF5YKxUfepRvk+X3xApIreMHXHmKmkCIvSMFpALNcmek/qPH7kfuf4VTxhtUynbzzwGPYjfRZLnuCb+x2MQQ8dF1tkrkDmtxfXrL26EaeH8vqDao+wKksIHHCFC7iy1k7vsSTMJrsleDJSnwgO4oxLwSxDpkYMIAlq7cC+7b8jhwwFFJd+hqBc0fTOOQG93F63C/JRDyNZRVSYaoxU7LzeM/nU1UhIr2sdmukGEOAysRPKcUIrYwYKGPcvhXIn1DzlNxzB2/LHMBjwzgojo+2qlc1yjUKz9m/pl+S8zKb0MBjtHvBb9BSnqprK9I65gma1RNwKaW9xOzC6KDGPsya+zCvqJiRY+XPjaw0pWvnrhw+Mms66mqJZP/793lf1jcq7yue9Vk6Gq1eFxm6gRHMFTvBUEyrbuLEzF+GXvzDGYHdPKZpoEPI0m69K8om0w2Pikay75v0eZUVFNeibqvE/62hjLhVUFKjDUlxX1qNCgyNtftSKJ3fgoYsJc+4KTltRf8BPuDAnR3M6RHsYDonqfwsFAC5cbcUTH8434hOwd/921EyvLUnTKJRNZlJ52Ye37P+CdHjC1x4cGMSfWleqOC0f4pKUBdQA4Hckl67UKnpZFmamvV97dhqym0NKwGE0aKtf3DDlGtZZA5M1NCv9Ph8sY2NGSZceKPuK6I3m56VAfnk8sapc9CIx0VSrVBEPMto3zrtM88RWar9aum0HPKWrdc+PLWgTKxpUce8b+dVuPxok6UnG3nHGVJQ6HUp4T1Eik2zf/VxjmFKgP8RCUVUNaeYdSVgp5Rx6BKl6sRs3Gec/SaHK5oF1/49qG1GhNKMyJ0KgxyOsxt1dAi6EDIZSEx xtC5bdjW kkbF4+6FPy1RpwiBQoW0hbnre32W9YqH63VGCSftvhKnhZuMe632W+dE4+ZCIn2JeBogg3xLBBDuf0D1t3bz3yEZ+d+1zG6O8jOYI7/eATG/sIsXi+P3BSsHLiQPPV6WdwbvogcddUhTMlmiRMSAbfsvG1XdK0CvgmY1jB+jPWTs/4PL2Oi+7u+KiBdMG5eC/AueF36tSeMzYxvGUqL0z3C6NxWsnN+D6HU4aFShAA9pVcT9+B44/c9pRWYaUyMGlzxQkP2scjLSUROZ7DIQ3Xoyf65tYNrU6aY+eeirXD5YVVDqv3PM2++9ODZkKVrhV7s4v/stIQpmv444SGnLHNHQo1rwtxPJeLdvEB9dOHZ107NEkqF6jwk7/oVkyHE2sStvNp423vxNvt8majXkG9uCJinGlQiCOfUOhA3oDdyss88y1lTuM7QncQDuOHtsl+HYh/Nbo4SMSS9CiiuyGXJL2MKOxeN/Q744rI9KmZfltWnecB0Lg0ddF/V0DNDnq3H9AVWBv8axAgSSQc3IKtcastnFhyAjNlKJZ9lEUF3ZSNkUT1pOjGFEuXnxZttqs6oFeWVxP31iqvzIK+cN5RO4EDdSQOYRszhFtiR2oeB3LMbgwOXYZxFRtHQ== 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 Sat, Mar 25, 2023 at 7:27=E2=80=AFPM Joel Fernandes wrote: > > So for that very reason, we still have to handle the bad case where the > source PMD was not deleted right? Well, so our rules are that if nothing is mapped in a particular page table directory (any level), then it must be empty. And that "must" is actually a hard requirement, because our exit path won't even spend time tearing down page tables that don't have any mappings in them. So if you were to have non-empty pmd entries that don't have a vma associated with them, there would be a memory leak, and we really would want to warn about that case. End result: it should be sufficient to do something like "if you don't have a mapping below you within this PMD, you can expand the movement down to a full PMD". And same with the above case. Of course, the more I think about this, the more I wonder "is this even worth it". Because we have (a) mremap() that can't trigger the problematic case currently (because not overlapping), and *probably* almost never would trigger the optimization of widening the move in practice. (b) setup_arg_pages() will probably almost never triggers the problematic case in practice, since you'd have to shift the pages by *just* the right amount so in the end, maybe the "real fix" is to just say "none of this matters, let's just remove the warning". An alternative "real fix" might even be to just say "just don't shift the stack by exactly a PMD". It's unlikely to happen anyway, it's not worth optimizing for, so just make sure it doesn't happen. IOW, another alternative could be something like this: --- a/fs/exec.c +++ b/fs/exec.c @@ -783,7 +783,14 @@ int setup_arg_pages(struct linux_binprm *bprm, unlikely(vma->vm_end - vma->vm_start >=3D stack_top - mmap_min_= addr)) return -ENOMEM; + /* + * Shift the stack up, but avoid shifting by + * exactly a PMD size, which causes issues + * when mixing page-sized and pmd-sized moves. + */ stack_shift =3D vma->vm_end - stack_top; + if (stack_shift && !(stack_shift & ~PMD_MASK)) + stack_shift -=3D PAGE_SIZE; bprm->p -=3D stack_shift; mm->arg_start =3D bprm->p; which is *really* quite ugly, and only handles the stack-grows-down case, and I'm not proud of it, and the above is also entirely untested. I will delete that patch from my system after sending out this email, and disavow any knowledge of that horrendously ugly hack. But if somebody else takes ownership of it and I won't be blamed for it, I would probably accept it as a solution. Shudder. That's nasty. Linus