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 B71BAC4332F for ; Fri, 23 Dec 2022 01:25:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E663D900003; Thu, 22 Dec 2022 20:25:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1644900002; Thu, 22 Dec 2022 20:25:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB713900003; Thu, 22 Dec 2022 20:25:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B7BF5900002 for ; Thu, 22 Dec 2022 20:25:52 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7A6C3140E68 for ; Fri, 23 Dec 2022 01:25:52 +0000 (UTC) X-FDA: 80271829344.18.7BE1D2B Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf14.hostedemail.com (Postfix) with ESMTP id 5763E100004 for ; Fri, 23 Dec 2022 01:25:49 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BekA9FGh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of hughd@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671758749; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iDDEIzb1QyFB3mkdBGt2+S0Bq2GwNo6hOfdIaxMpijI=; b=WiMBpsJPqyCjb3DYvSAOQf005MYVI8M4mI4VMHsVMpU5bit+ymyjlc4jFnlXltFb6Hzl6Z YWr3W4E84eQaW+DQEoNHxbQvI2vVkWevfcZqq1zPLfYLXAxcpOHxDepq2kvJQqCjOEYGcN 5hk7wR7byLDiPnbo+5ulWpFj2FdBkMc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BekA9FGh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of hughd@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671758749; a=rsa-sha256; cv=none; b=Klt4Q5NP0aGuSYi/FMa8JiSVrXHU5VxGqr6pf3f20+cqDCueJipEeknetWRLPbfe1JtI1J RVqzNm7coi2PJXaTwre0CFaIIssk6kyGSFSeoXxnOGl8z0StNc8zPj4tIvnJaIM9iSuhHF 3N7HTI97DCV7WDEPTqRrPnYuidpolW4= Received: by mail-qt1-f181.google.com with SMTP id c11so2743149qtn.11 for ; Thu, 22 Dec 2022 17:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=iDDEIzb1QyFB3mkdBGt2+S0Bq2GwNo6hOfdIaxMpijI=; b=BekA9FGheDvSS3fgWCJJtXDiuyk0b45+jyc4vVjB+aDMXdBuOtgqspiIJYqOhE+9Z5 bxvsd3/FHfEyLSxXjPYOxg8+gG1mKTbMM+LL97BW2Jtg3/mlR58fj/9/N7ELMbjDoUme vlpNnSXes3RgGrwhYsczecPT0GkmVVSGsxQyOnq8JDEFafvLMgMmy9jbxf+zJMhxmO6P 7uUoo8WCLqO5BhVC2+FtP7pT/TlLU+SrixYWSJ0zjsEwQas/QOJm1mwvrS03gB+/jkKx OExz3OVbBtWOuCrflPPd71JPK/M72cC7VIplrrY8HZzxubkX8aSnw/k1dWIR74R/9qRP RyPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iDDEIzb1QyFB3mkdBGt2+S0Bq2GwNo6hOfdIaxMpijI=; b=F80Iw29FSvlhlzOSsLKE25k5RjJaF0iCt6WDZSmVa1GDOzQUDWSVp+jkmzLkab1iUw FC7FlScBhYhpp4YxtVZGaK9IHoaKMu6dloO7mt4cVXqBIJT924HxvSyD2EyT60XZPeUk cgY2Yk5EuOv3XigJFb/tkW8PIp4cVt3qwOnwQFmaCELxM2O+ZoCmVD7CIbWs1xIPKi/p NjBbW66Aegx/ygl1nxyeI1XDDboc9asazLJTyTqFcpoUsJckbGxOqmfqeczWJpqjifv9 ro/rokpPUxc+raXPEnm3y2E97fj+Tp+6S6OL1hbVmfQk96Jr5cJjqGfJSSzVp+EJv8VT t5dw== X-Gm-Message-State: AFqh2kpKSVbxx22F+ELufKWzu7cqF7HS3O08ur4qk2p1G2qoHE/HarWB s2/CqCLrJO8fm6wKYvP2yCfaGg== X-Google-Smtp-Source: AMrXdXt3hIxGlvQUojLgB3HiGK+VtBsKy3kJL2rhVcEJcSU2kN4rnTbjCh4+btLNbSvA2SPZNf9nTA== X-Received: by 2002:ac8:44b8:0:b0:3a8:2fba:b02d with SMTP id a24-20020ac844b8000000b003a82fbab02dmr10214662qto.51.1671758748455; Thu, 22 Dec 2022 17:25:48 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id l16-20020a37f910000000b006ef1a8f1b81sm1350981qkj.5.2022.12.22.17.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Dec 2022 17:25:47 -0800 (PST) Date: Thu, 22 Dec 2022 17:25:38 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Andrew Morton cc: Zach O'Keefe , linux-mm@kvack.org, Hugh Dickins , Yang Shi Subject: Re: [PATCH] mm/MADV_COLLAPSE: don't expand collapse when vm_end is past requested end In-Reply-To: <20221222165652.3775ff5343580e02ffabfa23@linux-foundation.org> Message-ID: <4678bb5a-b417-c3c3-333e-1618694b7653@google.com> References: <20221223003953.2795313-1-zokeefe@google.com> <20221222165652.3775ff5343580e02ffabfa23@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5763E100004 X-Stat-Signature: emfx6n4gtqrf6kak5psrsd1f7ep8e9y1 X-HE-Tag: 1671758749-92950 X-HE-Meta: U2FsdGVkX1+ZHsyFyH7HQDZPYq9iqnTVwb9ZWYc2/rSmmAHO6uiCZ2FAUK/lMTLurozuTpvoVkWnSi/0LII6rldQYF2qzhgebdISWX5PDtRKRiwxL4rvRTQbGLVXGuUo2PmX+drkIOXQm0TsJASdmuyBn63NHARHoyjtQd0dH0BnMW2NmyPavXeLXSVndFWwdbkkCsQ184c25i7Ir/oy4eup+Y9HmACEOra+MhytqST7JUaurd75/sIiI0rtw3AiBfWjFVr16k0qAfJwKVw9k1kdZm0SSafBggXsAKGIkz1ee8dh1iLLnlV0Umls8QMTJBzRWoS/wdXDKJrEM3468z+pg3/IjIVm+Tc1cSiwwGKLUNmOaBOAX9C8W3bHcr9FP/yWnCBfwpxB8xqrDKscWFf5GyE+EainoYnDnzRreyKhehlJPgHU4ZQU6kstE1JBt71bhr2TXNGz4jSc8bzb6DkxNWnKqJErogLKDPb9DwEPAZwqx/V6oGKuoGTsONZpe0ZCfnRsDHM9eHy0AiM52oIOyHSwBv0xqOMcfd0vhf4aHmUdlBgEnLaxRYtdQoqlitak7k3ncUvHXbdF6uWo4lahyN4L7dlxYWPpG5FmJjhh9kp09vYnyDOHavm6VVxg2i8Sc7mg11pE/xmhJOHmffjjX/x2OUtnMWIVtagPeqvavk4r4JHq4rKofVPC9oHVemdGQ2SVb9BaArRvh1dA60PtGT0xHdDj2PT4AS1979WG9xnx+MKPxciRYZGBc47S/OaHvzoc6hYGXwT5nSOn3mGVzj3q+PIbbA9xfmDZzCFrTbF73t8AKF4jDNQNXMJY7m6XF9TRNwohIbpGC169fFluH934UGgyDhJAlvv1VbQIyYrQuGZnUcU373uvmTPVTV+cHZQagDZdnaUQvLfWJ7X450pTU1TghO9ZeHZIQomJ31TlsgrGp5MrUSt5587xICD4lMMzCgdJvPteYZb c0tKzAzk foW74Jk9ZWrpMlaSg25johrpBEPRjNd5TFXC9AaT43ZNu5IQ5FShupotdKJyAXmlE5FmRKp4vrBO6ZFUrtscik1Czhs5jHR0jNRDw97vQEpoImqCRFYMx8eipXRvC3fAkV6hm5vXW5zmIfn4= 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 Thu, 22 Dec 2022, Andrew Morton wrote: > On Thu, 22 Dec 2022 16:39:53 -0800 "Zach O'Keefe" wrote: > > > MADV_COLLAPSE acts on one hugepage-aligned/sized region at a time, until > > it has collapsed all eligible memory contained within the bounds > > supplied by the user. > > > > At the top of each hugepage iteration we (re)lock mmap_lock and > > (re)validate the VMA for eligibility and update variables that might > > have changed while mmap_lock was dropped. One thing that might occur, > > is that the VMA could be resized, and as such, we refetch vma->vm_end > > to make sure we don't collapse past the end of the VMA. > > > > However, it's possible that during this refetch that we expand the > > region acted on by MADV_COLLAPSE if vma->vm_end is greater than the end > > of the user-supplied range. > > > > Don't expand the acted-on region when refetching vma->vm_end. > > What are the user-visible effects of this? Not any kernel crash, I think; but in my case (I was trying to check something else about MADV_COLLAPSE, and so was first verifying that it worked in the simple case) I kept getting EINVAL back from it, even when I'd fixed all my own userspace mistakes. It turned out to be that my mmap was bigger than the file itself, and I was only trying to collapse the file length; but because of the mis-adjustment to vm_end, it ran off the end of file and got into EINVAL territory (in a different context, would be EFAULT or SIGBUS). So in my case, unexpected failure. But I guess another case would be too much success: I suppose that if you try to collapse the first 2M of a 2T file, the mis-adjustment would cause it to spend a very long time doing much more work than you asked for. > > > Fixes: 4d24de9425f7 ("mm: MADV_COLLAPSE: refetch vm_end after reacquiring mmap_lock") > > Should we backport "mm/shmem: restore SHMEM_HUGE_DENY precedence over > MADV_COLLAPSE" and/or this patch into 6.1.x? Yes, please do Cc stable for them both in 6.1.x: I only just now realized the nasty "too much success" possibility, which does seem well worth stable; and I'd particularly like the precedence of SHMEM_HUGE_DENY asserted in 6.1.x, because doing it later it would become a UAPI change - I'm sorry I didn't catch it sooner, Zach did ask me to check but I was head down on other things. Thanks, Hugh