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 789D8C76196 for ; Mon, 3 Apr 2023 11:58:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B17B86B0072; Mon, 3 Apr 2023 07:58:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC7836B0074; Mon, 3 Apr 2023 07:58:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98F7D6B0075; Mon, 3 Apr 2023 07:58:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8A0796B0072 for ; Mon, 3 Apr 2023 07:58:13 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 505231609EF for ; Mon, 3 Apr 2023 11:58:13 +0000 (UTC) X-FDA: 80639931666.30.A98A9ED Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 2FB9A4000F for ; Mon, 3 Apr 2023 11:58:10 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=D5fF3joT; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680523090; 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=OVIwWquixww+JFF4EZop7Ld7XWMwZqHJw07biyoMhrs=; b=e2fnKieyVAJmdIZrKJIepZpzKlA8ECdlpoAHx5s+vocWHh8ASUkJJbx998wB1Rv7qV1PPd yATLxjCoy6yiAKOrnoIq84uwnPvBF5DAn4PM1CfQSWp4dZI5lp3GIbr1DWH6lAPe1GfcX0 mUkK04wkIvWHAu1rqEOwFbIJg/qNVT0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=D5fF3joT; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680523090; a=rsa-sha256; cv=none; b=VbJxCx3WjAcESAA5euQReFRMPm6i15sIKigfA9KrZR2uPme5ZUgKD9mhW7KQgqAx/GOk0+ 6Kx1Z0PhR5wiDkAKb9tYezCbqMtTO//iHZgQuHaKdz/GH0OVJBwavChYVqtJzK2DJS9J2C OfKKUew1+FLG+/pzM0bk3aR9cWGIvMo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680523089; h=from:from: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; bh=OVIwWquixww+JFF4EZop7Ld7XWMwZqHJw07biyoMhrs=; b=D5fF3joTCY0fkbdaP27EX0/SkQL1BTwWcuz5aCesP0xdQERYv41LhhkrW2mHIVRTd3AxXz PybsCgkuCluNKcYAbwQp1xAr2ErDw8/P22ladIbwGG1BIWMJ2d7bVUZkDTTSdIv68WVMgs 4A+mWnFEFd6s4Wy6HX1tEh2AeEim+Lo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-646-OWv1KSUGOwePxgGXqrb9gQ-1; Mon, 03 Apr 2023 07:58:08 -0400 X-MC-Unique: OWv1KSUGOwePxgGXqrb9gQ-1 Received: by mail-wr1-f72.google.com with SMTP id m4-20020adfa3c4000000b002e75158e632so494281wrb.17 for ; Mon, 03 Apr 2023 04:58:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680523087; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OVIwWquixww+JFF4EZop7Ld7XWMwZqHJw07biyoMhrs=; b=DXFhBsZzERaxyxVQeTeaH6e9USDFK89HMX5YaGQZIm5CMGdQWX1l//a31nkAgSEu0k A2B8gFIJLED/B+Q82kVn3L8WDIYejeYdOqsbOh9LFYTY77QG02d8c7lPNoSxfQH2vF31 0Ikh0HaHjWEG6PUqVJso3N2PAOcR4SauJMtocI5mLJ6h/yEiVTwyw0Qcankoo0UenSvN yafpnMHCJ4AqmEqBXgARy9XQZKF2MZx8+OOEwcTt3BGIPQQL0lVutylGLyCBpaA53qq5 pBkipSj0QJZ2FAnJWBCN+iHeYOL82L1+7bYH0gQ/TfK59GnEg7sIMT4V893KU/+RQkqN TXsQ== X-Gm-Message-State: AAQBX9fkJaLwcuhk/1St7LpYcZEUR6QPapJXJpXxmIzjEuICyJHT/QcY RPU4REVwyVDdQ0OrDC8FkQvNEE/384i1PxxE8D8y8hsMcJVnXyvL+eEiNbfnPO1BlgpZhvb3p1l XJNXKkYMxy9U= X-Received: by 2002:a7b:c4c3:0:b0:3f0:3d47:2cbe with SMTP id g3-20020a7bc4c3000000b003f03d472cbemr9925363wmk.10.1680523086945; Mon, 03 Apr 2023 04:58:06 -0700 (PDT) X-Google-Smtp-Source: AKy350auUP6YlKdUMeXPodnB2zUsvo68kS9KkPE7VXHPKr8F7AMGTQxl3KOOakGGn6pcXGVH/lLRFw== X-Received: by 2002:a7b:c4c3:0:b0:3f0:3d47:2cbe with SMTP id g3-20020a7bc4c3000000b003f03d472cbemr9925348wmk.10.1680523086654; Mon, 03 Apr 2023 04:58:06 -0700 (PDT) Received: from ?IPV6:2003:cb:c702:5e00:8e78:71f3:6243:77f0? (p200300cbc7025e008e7871f3624377f0.dip0.t-ipconnect.de. [2003:cb:c702:5e00:8e78:71f3:6243:77f0]) by smtp.gmail.com with ESMTPSA id t14-20020a05600c198e00b003ee1e07a14asm19260533wmq.45.2023.04.03.04.58.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Apr 2023 04:58:05 -0700 (PDT) Message-ID: Date: Mon, 3 Apr 2023 13:58:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 To: stsp , Linux Kernel Mailing List Cc: linux-mm@kvack.org, =?UTF-8?Q?Jakub_Mat=c4=9bna?= , Hugh Dickins , Vlastimil Babka , "Peter Zijlstra (Intel)" References: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru> From: David Hildenbrand Organization: Red Hat Subject: Re: MREMAP_FIXED unmaps dest on error In-Reply-To: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2FB9A4000F X-Stat-Signature: angqr9b7x7yu7ejhktd1cjgjbot9qi78 X-HE-Tag: 1680523090-327070 X-HE-Meta: U2FsdGVkX1/CIU1QKcEBHq5YQjqdXg69jj9Pg55YZglw+TrFYfeJ4rVZu3mraPyXp+lyq61PfbX3yFNML7yzm2Dth17X9VgHDeNEur/vfnZPo2eT7goN7LHcwohVBf4i2fWsHcQKAlIAM+XSFuZOFHJYccZiy+54kghnSaIESmvjgbUJ9yan5FvRK1fOS9sTcg1dikbMzmmUgqNVTW+UUe4tVqAmmWeLnUI6OpR3xhWYIFsmCkRWDfWOeM60la6xIkjPhKxoS4tCnOEVuCoTNfmppN1eLR5V0VDpEtej2iNIvCFRf/9qyywF3/ZbzjUqv6xzFdiVze8tU91yLRJ6gLYrs2rQ/r0GZBStHB7Nf3LBBw7JFomgK94T739YN+KjXDBn1L2gu0EDmooA0OUMeKuBSwNFJB/HUD9PnhdqABkQr5JyoWIMXXVhKL32YKRB8K1fyEM3hb1rE2pwFGKwRXiO5g71mXEM1pH7kXRxgso7tQ+KJgEwdo6Xw5zNr6Vhk3VyyXPkSRU7SGY0oS2HNPzdZ5Y0y2E5Zp8hK8so5Dsp0gWUdyHawSsAyiAMhivkEntgJSBb9dHyoTqwIBFnReh+I96HluBrCDT4oOMj7SVkJI/4KTCRio6F+GA5IdBHJOQ2jqXhZGXdwUnJU+JRIyjufVePavg9ypsXjXxLVJaLoi1sFQjNkDY+CDJB96LHf5dTedSi90SsNwkMs9n3oADQwH5amcZ1WOuJn0LMvDJpX5vNgjOl50omXLbTVUdWmr05snAYoyB7W8hdyMapBup/9sIlal/VHmsrw52ljjR6aXMhHNAFnNgVJiX3H8VZjirK8EDLpFuJIpwWCNw24KP4RrUUf6hwXoxL94slnEcn90BldRuH25W1juOLFy+XWC1vzGwHaX5vHnqmoP0nJR2FA7ykThoxXj3g/oN+YZVq+wighKYcPhxFrt/xQNFyYByWdYKxel9rL+iEbpY A8ZPjLn+ Vvz6fZJkp/TSSiecie+BBUmAxhwLpNeBw7hi7dFeUlWLOt5g4jTLbSoQM0/03CPP3hATZpaoMmxCuHZAeLSZn3uVi0RX411HpYKxUvReg1WqRuAuxWtzUrmQifM8FBfxSa+MGjX2FNCHtTT9ElTyNYCItu60UtLZGreiAcnapV9sv/U03NjtEy6PNZn0m+0z5aEBKsr1ZW5ObZ9oBglgAsDtj1VJ/ab6BlwJU+/m72FuL5D8SnY5yPqmw3gcM6Qh7e3CSm3BxjM6CmbUqKJH5qHh1iMvwZdW6j3PbqKuGpaNcCh26su7Uh6WmHSOA/mn+F+w7frcjolBdIJs9wwe37DIP59bbO2f7CgwgdpE5IfFz6sN45JuJG7/ZXb6F+xmDK/8VTgJwd1s/Yo/p1ZJp6LgFB81CAsMleRyPLLEggvTChC2Fxn5a7TUTO0ssNmR9PaRT X-Bogosity: Ham, tests=bogofilter, spamicity=0.001076, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 30.03.23 17:48, stsp wrote: > Hello. > > The attached test-case demonstrates a > bug in mremap(). If MREMAP_FIXED is used > over an existing mapping and mremap() fails, > destination area gets unmapped. > AFAIK the failed syscall should have no > observable effects. I remember that holds for various mapping-related syscalls: if something goes wrong, the end result is not guaranteed to be what we had before the syscall. For example, if you use mmap(MAP_FIXED) to replace part of an exiting mapping, we first munmap what's there and then try to mmap the new mapping. If something goes wrong while doing that, we cannot simple undo what we already did. Long story short: the semantics of these syscalls has never been to leave the system in the state as it was before in case anything goes wrong. As another example, if you do an mprotect() that covers multiple VMAS, and there is an issue with the last VMA, all but the last VMA will have their permissions changed. -- Thanks, David / dhildenb