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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AFE7C433F5 for ; Mon, 27 Sep 2021 09:08:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 239376103B for ; Mon, 27 Sep 2021 09:08:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 239376103B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 94ECB6B0071; Mon, 27 Sep 2021 05:08:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FEA0900002; Mon, 27 Sep 2021 05:08:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C6A16B0073; Mon, 27 Sep 2021 05:08:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6E0F26B0071 for ; Mon, 27 Sep 2021 05:08:56 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 24F322DED6 for ; Mon, 27 Sep 2021 09:08:56 +0000 (UTC) X-FDA: 78632778672.13.9EC9F35 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf14.hostedemail.com (Postfix) with ESMTP id D1BAA6001981 for ; Mon, 27 Sep 2021 09:08:55 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id y28so73845142lfb.0 for ; Mon, 27 Sep 2021 02:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kxoB9mdMEcTYaE8IB5Sp9G6grOx34N+1L2jpLnbwDQo=; b=RVlfdSdDqh2nb52hnBus/aGjFtE0qJvNCsbiMFR+TaBERfh4COBpLLJo6GxzwYDw+j T2JH3JqVVkxxe5vwyGrTUtlslTIGVyB7pCcpCg+d7A1oXY8RxGQqtGA46I++/XgMkKDv 71ijReBePA0whAW4INt7iGk+D/JKsm6vPEd3oSxHN7FGvS6i6shdaO7uA1vT6NWbJJAZ vmNiCbSEVvgCEBEmfT58m0NyHqCABm7rzN/uLRKSFeX7GBCdyQxL0w+QUxcOf6lTatGB nNXyVWwSfJWGUwF3QFODGA4Z/Hb32myldrm8VFrz+E+1xZJyIkOfQbtmp/tW4trlAglI lWeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kxoB9mdMEcTYaE8IB5Sp9G6grOx34N+1L2jpLnbwDQo=; b=n+7Wx8tTS+b0vNQFXBr68fHMNxJwygNRXSvJukA8kBm63ID7H7gbgD+F82rHIlNMgo pGApDskIGPm9htXXvRZ6GGBSS1ygi8cRCgZqsJ5rtqTF3eyz/LC4iKe0K6NO+f1iaVpA VRrcIJZWDsYnzrqUumTg3Jul4ArNslSW1HPOXfGCsSo4xbhi8ISClXBzlaGMtxqQjCr2 p0yTuzDNlk/UFclC+WP6YunFcDYMUDC12uZsCnTSfUHt4M2YmuBDyg2iMNU2iGGMvrjS FI3jX22kZV/zT7QXWi8y8z1w9kCVbPgoqgWKfirNnp8a6AWf+1Ih6pHs2ei64E6XdXkc 6zhw== X-Gm-Message-State: AOAM533QxxFtluU/4d+4/iDPjeMmmRXONFm80FsUTV0bdarkSbWIKfh6 +/nCgXtilVRzrVeVp9k0QmXmFA== X-Google-Smtp-Source: ABdhPJwNwfYaOpwDx/Ps+4B8HoVpwhq5tkIdzspPlEGmStAbODdsSs1jy8L1kc6hatMOzrJTdHJwlw== X-Received: by 2002:a2e:bc1e:: with SMTP id b30mr28375759ljf.191.1632733734119; Mon, 27 Sep 2021 02:08:54 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id e2sm960866ljj.118.2021.09.27.02.08.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 02:08:53 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B66F510306C; Mon, 27 Sep 2021 12:08:52 +0300 (+03) Date: Mon, 27 Sep 2021 12:08:52 +0300 From: "Kirill A. Shutemov" To: Nadav Amit Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Peter Xu , Nadav Amit , Andrea Arcangeli , Minchan Kim , Colin Cross , Suren Baghdasarya , Mike Rapoport Subject: Re: [RFC PATCH 1/8] mm/madvise: propagate vma->vm_end changes Message-ID: <20210927090852.sc5u65ufwvfx57rl@box.shutemov.name> References: <20210926161259.238054-1-namit@vmware.com> <20210926161259.238054-2-namit@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210926161259.238054-2-namit@vmware.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D1BAA6001981 X-Stat-Signature: 5d65wu758iikyootsmp9qtfzdjj1hg8c Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=RVlfdSdD; dmarc=none; spf=none (imf14.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.43) smtp.mailfrom=kirill@shutemov.name X-HE-Tag: 1632733735-899239 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 Sun, Sep 26, 2021 at 09:12:52AM -0700, Nadav Amit wrote: > From: Nadav Amit > > The comment in madvise_dontneed_free() says that vma splits that occur > while the mmap-lock is dropped, during userfaultfd_remove(), should be > handled correctly, but nothing in the code indicates that it is so: prev > is invalidated, and do_madvise() will therefore continue to update VMAs > from the "obsolete" end (i.e., the one before the split). > > Propagate the changes to end from madvise_dontneed_free() back to > do_madvise() and continue the updates from the new end accordingly. Could you describe in details a race that would lead to wrong behaviour? If mmap lock was dropped any change to VMA layout can appear. We can have totally unrelated VMA there. Either way, if userspace change VMA layout for a region that is under madvise(MADV_DONTNEED) it is totally broken. I don't see a valid reason to do this. The current behaviour looks reasonable to me. Yes, we can miss VMAs, but these VMAs can also be created just after madvise() is finished. -- Kirill A. Shutemov