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 93801C4332F for ; Wed, 19 Oct 2022 14:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA51B6B0071; Wed, 19 Oct 2022 10:08:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2E636B0073; Wed, 19 Oct 2022 10:08:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA8EB6B0074; Wed, 19 Oct 2022 10:08:34 -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 9940C6B0071 for ; Wed, 19 Oct 2022 10:08:34 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5BC5480606 for ; Wed, 19 Oct 2022 14:08:34 +0000 (UTC) X-FDA: 80037879348.23.B42B947 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id CD79D18003C for ; Wed, 19 Oct 2022 14:08:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666188513; 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=bNsmwdfusQykh4S+xlKrJJSlnfHZs+V8z/WwZn6gi74=; b=YxGpLPt/1RnvXTy/gz8/bAcxCDInKJExD5NiNKDmtz+s8O/tJmQqAqNWAyWAAbfXK4GTrh j3Y3XHI09u+4jf9+ldo02WA/D+6kRzi8mRTgRXPq1JEkrkbAR0wy8pQ2Aa5XJX6Yg4CdaZ k70RpYO3ThGqEtT6CK1ByvurwdB8w6E= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-584--BvD-sDuO8K0n4MdW5h4gA-1; Wed, 19 Oct 2022 10:08:31 -0400 X-MC-Unique: -BvD-sDuO8K0n4MdW5h4gA-1 Received: by mail-wm1-f69.google.com with SMTP id f7-20020a7bcd07000000b003c6e73579d3so9178284wmj.8 for ; Wed, 19 Oct 2022 07:08:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bNsmwdfusQykh4S+xlKrJJSlnfHZs+V8z/WwZn6gi74=; b=OB1g05XmXy0Thg9dYOMZW09U3nPifztPtmCKtLaQf8e4d2FOX2ODoFZtrvTn3k2uDX nFd7HrGRg5lktmh3t2xYdjJGKjaA7Lvmhs1RVUiLGDV0D+8sHoGmyg26Wd0BWYzB1Rrk kI8Ky6knqK+Zsu14w/L/1bF9xzYs7gFYpyz06m+EHF5DjahhtV1k6QQ0/zYoPDwoQ85C tKFBth2q0BvEvkyj0N+WY3IfxoTJVMlbZH64PWDd0ROEvO51NvK0rlNHnxDPoJkWm5Rn 4u7Es42zUFKaLNisVe4sKt/6ApJFGHdfZA8kmEmon75Y9OmqNNU58HSQiUwS8R4NzycP oMwA== X-Gm-Message-State: ACrzQf0hWMSXoYxDdKj7b+Jt9xEnExqMXb4sYzU4coVS67LednIiw7P+ lGIVE1XAupXTB5/g/raYfYo1gsra+f7/IsHfYOLlHw5TVQQEs/PWg9ut2RddUw5F0G1mBg0eX3j wofJQZnxeIhk= X-Received: by 2002:a05:600c:a08:b0:3bc:eb4c:b90 with SMTP id z8-20020a05600c0a0800b003bceb4c0b90mr5909831wmp.184.1666188510550; Wed, 19 Oct 2022 07:08:30 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6EwyJcYMSpjoODNKk5OHkTyIuDhpe47pK9XQN7+0LEtL4Gr7Lu8Tejd0RmwxqPO1rZdijHgw== X-Received: by 2002:a05:600c:a08:b0:3bc:eb4c:b90 with SMTP id z8-20020a05600c0a0800b003bceb4c0b90mr5909802wmp.184.1666188510202; Wed, 19 Oct 2022 07:08:30 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:2c00:d4ac:d2c:4aee:dac1? (p200300cbc7072c00d4ac0d2c4aeedac1.dip0.t-ipconnect.de. [2003:cb:c707:2c00:d4ac:d2c:4aee:dac1]) by smtp.gmail.com with ESMTPSA id 5-20020a05600c028500b003c64c186206sm33907wmk.16.2022.10.19.07.08.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 07:08:29 -0700 (PDT) Message-ID: Date: Wed, 19 Oct 2022 16:08:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] mm/mmap: Fix MAP_FIXED address return on VMA merge To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , Liu Zixian , Jason Gunthorpe , Matthew Wilcox , Mark Rutland References: <20221018191613.4133459-1-Liam.Howlett@oracle.com> <3da4244a-5a1b-cf34-bf5c-22c199b15cb6@redhat.com> <20221018202518.zrnoe6ho4lcfuptm@revolver> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20221018202518.zrnoe6ho4lcfuptm@revolver> 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666188514; a=rsa-sha256; cv=none; b=v7cK41uNOEu7hBlkFHZvD9+foG7y9A6Y15ko+x2WeSp6hjIBBKEVRYbgP2uvxe7iESjrB+ yB0BytviqB5YHJ9P758FkrXqR0kon7T3sd6cVNplQaB2QQHAHzm55X6+ac00BpcOuv/Btl TbRHq59AowZkmTLF+X+3UygSkfO+yU4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="YxGpLPt/"; spf=pass (imf24.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=1666188514; 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=bNsmwdfusQykh4S+xlKrJJSlnfHZs+V8z/WwZn6gi74=; b=Yh9vdjJiiLSkICgh5ImHaSVPibXrY3FNLgxY9hECBOoZWNEGWbJkRVAgE7iNEQ5jt/t/iO swdmGW38Vb5MPMhxLJirKvgTCquKc28zhqfeTcgkA7F0uN6Mgrq2mXMYo3uSWp2f4WOTEX H0L05NdhoYdEFixMQdfCSG4ceDZzQ04= X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="YxGpLPt/"; spf=pass (imf24.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 X-Stat-Signature: dszdo35dbk4d5n1gu44kjke3ibbxursc X-Rspamd-Queue-Id: CD79D18003C X-Rspamd-Server: rspam10 X-HE-Tag: 1666188513-689616 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: >>> mm/mmap.c | 15 +++++++-------- >>> 1 file changed, 7 insertions(+), 8 deletions(-) >>> >>> diff --git a/mm/mmap.c b/mm/mmap.c >>> index 42cd2c260898..22010e13f1a1 100644 >>> --- a/mm/mmap.c >>> +++ b/mm/mmap.c >>> @@ -2625,14 +2625,14 @@ unsigned long mmap_region(struct file *file, unsigned long addr, >>> if (error) >>> goto unmap_and_free_vma; >>> - /* Can addr have changed?? >>> - * >>> - * Answer: Yes, several device drivers can do it in their >>> - * f_op->mmap method. -DaveM >>> + /* >>> + * Expansion is handled above, merging is handled below. >>> + * Drivers should not alter the address of the VMA. >>> */ >>> - WARN_ON_ONCE(addr != vma->vm_start); >>> - >>> - addr = vma->vm_start; >>> + if (WARN_ON((addr != vma->vm_start))) { >>> + error = -EINVAL; >>> + goto close_and_free_vma; >>> + } >> >> If this is something that user space can trigger, WARN_* is the wrong >> choice. But what I understand from the comment change is that this must not >> happen at that point unless there is a real issue. > > The VMA start address could be changed in call_mmap() which is a driver > call. I guess someone could write a driver to mmap by a users action? > I don't think it can be reached other ways. In any case, I'm changing a > WARN_ON_ONCE() to a WARN_ON() and undoing the badness instead of > marching forwards. WARN_ON_ONCE() can also be used in conditionals if that's what you were concerned about, but ... > >> >> Why not "if (WARN_ON_ONCE)" ? > > I was thinking it was harder to ignore if it happen more frequently? > There isn't a driver that does this now, but I'm not picky over which > variant to call. .. I think the assumption really is that we won't see (m)any these calls. And if we do, it's a bad bad driver. So WARN_ON() might be just fine. If this would be easy to trigger by any user space, WARN* would have been the wrong choice, that's why I was asking. -- Thanks, David / dhildenb