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 6FB05C761A6 for ; Thu, 30 Mar 2023 18:42:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE7DC6B0074; Thu, 30 Mar 2023 14:42:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E70E4900002; Thu, 30 Mar 2023 14:42:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D11D86B007B; Thu, 30 Mar 2023 14:42:41 -0400 (EDT) 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 BE5D56B0074 for ; Thu, 30 Mar 2023 14:42:41 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 95B901C681A for ; Thu, 30 Mar 2023 18:42:41 +0000 (UTC) X-FDA: 80626435722.26.D3252BE Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf06.hostedemail.com (Postfix) with ESMTP id A332E180002 for ; Thu, 30 Mar 2023 18:42:39 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HtX6Y03x; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680201759; 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=2fPzEeGQfGKvHIpXtPehtZ0JbbS+swuQ9EVmGDwLLEA=; b=FJUrB0EWlzhezIauuvYW6NvgsS2OOglOwJyduNDJvfTRbGEwBMDo5lpm0tQbY9A/r5qjIT z/ixIVoyRjU9Vm+0ZTULC1KvrmvSjbypZn09YKW6RwZFQwLQ7NfvSHWs8uWx66w3U+1qgL OjnmTb/V4BzLIQdgqs8J863lBxAgKyw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HtX6Y03x; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680201759; a=rsa-sha256; cv=none; b=c7u93m74Cqg8QRC5ZpWQ0ZPVCQ30ddwOT7OkJAYVdbuBFZWrKXQlFQoLk7xLXg40TFzTbV 8ytW5Tlbt9U1vz4uCW1Qkxl19jyUSz4qppT0F8IhyUVbZsVc9c7xlWSTInZmH8Lp9n1Ct/ vO12XqkM/jD0FpYP83nYGu2lJyFZryY= Received: by mail-wr1-f42.google.com with SMTP id v1so20071311wrv.1 for ; Thu, 30 Mar 2023 11:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680201758; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=2fPzEeGQfGKvHIpXtPehtZ0JbbS+swuQ9EVmGDwLLEA=; b=HtX6Y03xeHioKLx988e7xQQTyhBoTywZuRNy6+OykxZQBG5iRT44BecKWnsodswzHS BRBk6JAs6fcVQPxzviOyWoLE/5Hn4mcTelCx6DMpFosKX8gwIlWIOhgw1eG9lfmR3i6/ 7IaqyAxWjpo2XirEuGXrbU47ZVDiRhy8D06oZyhDaRwqK0oCC8I6yway9QTohJjGRJ5r XrTTBPlqsVCzwoT5nC4dSWB2A+I/9FuopwgBoXIyBhGDCXghl6EyhJ6pYj3/3k1EBPBl pGLb+BbaeoyXUNUDtRx88GIDER/WTZVP0rr89eo4RnEXS2Z/v0F4Ql7fxC7Js3gHe4AB +L6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680201758; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2fPzEeGQfGKvHIpXtPehtZ0JbbS+swuQ9EVmGDwLLEA=; b=1bn0WoBZG9QJmewRXHHhTIZsNyryvlrMGBf+y8VD79JZysWhnTxe9F2ALK7M0FQgOf mczypQhQ9QA4V4IpojsInUDKNUAM/toxXmVcOaCbqF5RKbOq+4kTqj2n2/cjbO5XK7Vh W+oyAra/ndHkHgxpQ0QUqKScP1BN+6PCg3RBSfkEy1Fvx6H6eiTZ6HyZttXdCv4gNPNJ DNjulbY9uC7oF/lNF1O4Q2T3pY8qOLwxxzpeB+ITmoqq+70MTv6sL0gfhn/p7YXw075X 1bW+XfSgXyX0Wqf/jgKd7ArlnePvj+DG5KRbbqJ6Cm0RyXjd/wK01k9TogKjLfJm5LtY 9WMw== X-Gm-Message-State: AAQBX9dqXJjtCHiE1whAlNye7svwigUlUlur3irj0NuSLXJCngd6yQqu 4uTIWcwNcoOUhj/vPWwDhTA= X-Google-Smtp-Source: AKy350Y5DDfVY64K5seLH5yUFT65ouB/N/TVyyiwQ6GJYaZBgTP1CSO3OTSCDVHGopJOmaiElejokg== X-Received: by 2002:adf:db4b:0:b0:2d9:eb77:90d2 with SMTP id f11-20020adfdb4b000000b002d9eb7790d2mr17610492wrj.70.1680201758038; Thu, 30 Mar 2023 11:42:38 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id q9-20020a5d61c9000000b002cfe3f842c8sm70489wrv.56.2023.03.30.11.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:42:37 -0700 (PDT) Date: Thu, 30 Mar 2023 19:42:36 +0100 From: Lorenzo Stoakes To: stsp Cc: Linux Kernel Mailing List , linux-mm@kvack.org, Brian Geffon , Li Xinhai , Dmitry Safonov <0x7f454c46@gmail.com>, linux-api@vger.kernel.org, linux-man@vger.kernel.org, Michael Kerrisk Subject: Re: MREMAP_DONTUNMAP corrupts initial mapping Message-ID: <498d7a19-2b29-46ea-9c34-ec8fb7394e6c@lucifer.local> References: <38c80313-ba1c-092c-ae31-f58fe6ffa82c@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38c80313-ba1c-092c-ae31-f58fe6ffa82c@yandex.ru> X-Rspamd-Queue-Id: A332E180002 X-Stat-Signature: 1w8cmncahpyo819e1z9ej1nphu3imub5 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680201759-11456 X-HE-Meta: U2FsdGVkX1/rmfLnGDDqOeJ73/wptDMZSPec4pNgA+eGouBU1A7sFb6ElS5dKTn30Tm3AKumw26rHJ0Cs9UooDnQhm59MnOp+Zbq2pMSKLQvHpSFVJAywefp5KtUY/Ho0Xv4t/mtQfsknKxJqMXmNa5ArjJOUroMCwSRs+MZpRhjsj1bB2wGdO3g9BsgLpgsQMtdeXvoTtar0JAAikdtmCfo81rpB0BduTaqQRacSVYB0qf6tzU9Rq3B6T8Cm7N3aBccW6Q7R0degANzT8KvLWULQ3aCw66TJGbG3/lXDT+zDVCM6gWSeasM8xU/T942AGzptApmfVo9O2lKR01CG9hzpNxatmiPhgnN0swH5KmQP62MRGy80NG87CnLnjNHJYxFaoaDMmAtwbtmg7WHmGVkj+SQqMDmNIHfnkx6Gw16AtiRITRhn1hEM5oMnyy20hyZ3BpCtmzcvGL1dFGNu7ZDoiNcjUOO6zh64Kv7U6B2SmdB2qSWhZs42FyVmNnOdzmPzbnCw0BYPd9AJO6NLEBR49sbXU41ns8bOYFwx7UK5LSv3OA1fgcZkykjC9uQLvsuxHhClky6f62hQ1oc/LirTE+V9lm9F+TieZqFxL2i8VBZRnZearkO4/0d9Gg0FOS4IVeBXFEHgkIYNwRdfhV5aqf+mEgCkuPi6JoiO19MZbL67Kecc2IofOyuY7PWb/qBvGOl9JVJlT0fABGFbKQw3NWHirM0cfvVH3mg2zI4RK0Sx8DAeY1AXUe82ArjdKNiJOhyV8NKv1vlJtUTVBgD4k1Fq9EHJsCzizzF8+EKpd0fXP005rrJxS8frhB6sf1ODSgx8qrIkxSuyebrTYcBcRjMEjpYcfIlcdtYvCrXjKUA89XD+DEw7pWLBYmKRhp9iGGf6Grimn08C1lUWpFqEUVbIZy9cNn4sYl4DmHCgQZ8KUApCZRvt5vlaugQ/zjSwL9HLyEwcTznMV+ W39ai4Qt khVD5/lxEMC+S3mGy3HOSNgB2djFtAo1fjVS9WeyUy+Ut4mYTPyNVR1/cYyBqfDCOfPHsr8Wf0y6AR9qbo9p3x7Jtsdp2RUTNIMQxhYPyKr+0Nl2v+nqC1YLs+Edv0F2YQ8h9E69scDjQ5GrJvaFjSC+QxLjzqapxZVlTRbH/Xfziz850DfoaNIcZjRqibRK40ZIEcoE5fkRJVsV32K49OPNwaPHSNGLPVX0tQ7WLYtLK2lYSDFajjcLgw1huar1iG4XQRh4hr5EM8NaToGeoYAZSCt+HswgaZernpjJJJ8X9J+m2WoBAisRCFFDQ6mjfQaTvZV9ZSPrRn0ZsjyxJvNny2VJTqxMY1bUn6X4NwA3Pm0Ve+CCcQmpRpT1XhDLxSaxF1rLH8Tx88jWfB1m4YEo1+LialZzICxxxyfP8Jk9AsLzZ6pXnX0EoFcprjU1Ge5iLSQdyPwp19tek1MgfzzPWYb/Ay4K8nMFos4p5iIcHKMejnEgrc322MtGMF07XlTZQOZV0mSKXypnToeLYXzUVeDSJl14jeRyDTlflPW/90O4bwtgQrMuETkl2G13sDDtMj3e3OiIA2uBERhnxXtLaVaSBiCxN0U7D 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, Mar 30, 2023 at 07:45:14PM +0500, stsp wrote: > Add a few CCs. > > 30.03.2023 17:38, stsp пишет: > > Hello. > > > > Attached is a small test-case that > > demonstrates the problem. > > The problem happens if you change > > some data in a file-backed private > > mapping and then use mremap on > > it with MREMAP_DONTUNMAP flag. > > The result is: > > - destination copy is valid > > - source copy restored from the original file > > > > So the 2 copies do not match. This seems to be a case of the documentation not quite being correct in the case of a MAP_PRIVATE file mapping, from the mremap man page discussing MREMAP_DONTUNMAP:- After completion, any access to the range specified by old_address and old_size will result in a page fault. The page fault will be han‐ dled by a userfaultfd(2) handler if the address is in a range previously registered with userfaultfd(2). Otherwise, the kernel allocates a zero-filled page to handle the fault. This documents what happens with the combination of MREMAP_DONTUNMAP and _anonymous_ mappings. This is accurate in the anonymous mapping case because after move_page_tables() the VMA remains the same but accesses cause page faults which will map the zero page. However, MAP_PRIVATE file-backed mappings have different semantics - if the page table mappings are invalidated in any way (typically due to file truncation) then, on fault, the mappings revert to a CoW of the page cache entries, which is exactly what is happening here. I think this is probably the behaviour you want because fundamentally the VMAs in both cases map a file and these are the semantics associated with a MAP_PRIVATE file mapping. You'd otherwise have to either change the original VMA to be a wholly anonymous mapping (which would cause surprising behaviour on truncation) or you'd have to explicitly zero the memory and CoW it in which doesn't really sound appealing either. Overall this strikes me as a problem with the documentation being a bit outdated since MREMAP_DONTUNMAP was extended to non-anonymous mappings [1] and ultimately needs a slightly tweaked explanation to cover this case. CC-ing Michael, manpages/api lists accordingly. [1]:https://lore.kernel.org/all/20210323182520.2712101-1-bgeffon@google.com/