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 0B31ACF5389 for ; Wed, 23 Oct 2024 12:58:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 656B26B007B; Wed, 23 Oct 2024 08:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 606ED6B0082; Wed, 23 Oct 2024 08:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47FF76B0083; Wed, 23 Oct 2024 08:58:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 215596B007B for ; Wed, 23 Oct 2024 08:58:51 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0AE51160B76 for ; Wed, 23 Oct 2024 12:58:31 +0000 (UTC) X-FDA: 82704870486.17.67B467C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf03.hostedemail.com (Postfix) with ESMTP id 95F3B20004 for ; Wed, 23 Oct 2024 12:58:39 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KeJZTGrQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=slMKgFLs; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="y/sf5fk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=QCkUYC0Y; dmarc=none; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729688160; 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=zoLfz/fjZfhokZzjollbHy6uKEWa9Wv7liSzK+L+N2s=; b=1I+FYOlGJtYJKIx4UZvWxgvZC/3BgzCHGku/cFNa+hEQEZtiWT+uWMkO3w6miDhBlntw0O ZDjlXL1GFBAXaCmkKx0giev81MHCxnBej4HmqzGmpQEVTEBUBCvigAMSf0klNyipy8Cjp5 Ae+Pzz3YKP3az6PVW3K6EQCnW0EVF1c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729688160; a=rsa-sha256; cv=none; b=5EJWqUged0p3+IHoy1VJHa5yoW10yrVOS+G8cqpr1SWNmTutU/fVA7bWUwUZ8fc+0ze+sm xgky4TAkCV6MZwW4ccUszSeJ+wJ1pMVBZm+luPybQ2tCHzHUkCivtIWdYBVMkSersBPQoN UKB1rVKZ5wvyJQzv5qmGBhLjv4B8lsY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KeJZTGrQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=slMKgFLs; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="y/sf5fk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=QCkUYC0Y; dmarc=none; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E6F8B21F05; Wed, 23 Oct 2024 12:58:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729688326; h=from:from:reply-to: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:autocrypt:autocrypt; bh=zoLfz/fjZfhokZzjollbHy6uKEWa9Wv7liSzK+L+N2s=; b=KeJZTGrQoGRd8MIy3b2bUxODm9K4Z1Qp8EeTcxrAE/qgOYIPMy8sfPspyxENyPL/w5QsX4 n+SnetYe2Mocr4X5yc/vsHgUWHeUFpqFnmHFYiolDkf+ZhbxvzW+jARyLtDfBa+uefZtRI tcL539Slu/SQxcCErmXjdTBznQfJZ6k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729688326; h=from:from:reply-to: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:autocrypt:autocrypt; bh=zoLfz/fjZfhokZzjollbHy6uKEWa9Wv7liSzK+L+N2s=; b=slMKgFLsqPhzNdFQq1UliB7PDvl36BPVM0O7oAjk3r1X2CEUPtcQaKWG7rChP97uEnCrZU a1KkKYzkxyJXnKBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729688325; h=from:from:reply-to: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:autocrypt:autocrypt; bh=zoLfz/fjZfhokZzjollbHy6uKEWa9Wv7liSzK+L+N2s=; b=y/sf5fk6OyvmEdSiquKsE9qehRV0Vx0T3nyi9Cmx5kPbbJbUiyRgfVkCe4vCbloiP7CSEn 8m5LaprzuZfpEGCp5L9g4JGEuRVYMtUBk1s8pUg1YUiW1L17GKiYabBlRdMdYVZZ5BUh/z qi1b/B5o4ucGB/aAC3/o0XMrdJVj9PM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729688325; h=from:from:reply-to: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:autocrypt:autocrypt; bh=zoLfz/fjZfhokZzjollbHy6uKEWa9Wv7liSzK+L+N2s=; b=QCkUYC0Y9RIzaK5JkVPdLGoN/iSlkNVEd4+Y1siso5Ts7vEirRMvtsN6G66hpf5ep6ULnf vEQ40IeOUDWYnfAw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C671513A63; Wed, 23 Oct 2024 12:58:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 1VgAMAXzGGflcwAAD6G6ig (envelope-from ); Wed, 23 Oct 2024 12:58:45 +0000 Message-ID: Date: Wed, 23 Oct 2024 14:58:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hotfix 6.12 4/8] mm: resolve faulty mmap_region() error path behaviour Content-Language: en-US To: Lorenzo Stoakes , Andrew Morton Cc: "Liam R . Howlett" , Jann Horn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Peter Xu References: <3bc3ef7520eed73472f7ffdce044f2e94f809b32.1729628198.git.lorenzo.stoakes@oracle.com> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: <3bc3ef7520eed73472f7ffdce044f2e94f809b32.1729628198.git.lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 95F3B20004 X-Stat-Signature: zkgb419aimrooorjfe6413uxr1h6cpcs X-Rspam-User: X-HE-Tag: 1729688319-368732 X-HE-Meta: U2FsdGVkX19gEAQC3R6BRksguWp3wGNWS5LurBQz+o8h6CPiIqik3K97IH5zFGMIxuXYS3g787Yj515J9SF0uU0WPi4o36czQphnp1pTNK5fQIrJC8+gLOqNQBGCoLx9p9/8Jx81tY4gYqsPwIahF0k/imu22Px28uViwIWLBSK4dWblgjMdGyIVS1XZFl5qkGZXgFqoLO6mz9OYu+FianX2InWPPRLLL97pdDVdxVcWfmf3y09w1Eq+aXSZT59/ggSOLz0hSGZpouVxiXSKvzMyF5Opbp3+q2lQiVkTGJpa+Iluzk5wJ/vSdcLHkKHSXtbjEHzvzKnp4VyGynSBSlExRYFUBASN91tHAvbCWI9LjMJEVgo6p7X3uW3/hm2+Npvh6MzJ+PtydpJsCrOqJAHcISY+B9vEmxJzPDPsKGKMaShuvV9naS4cBSSrMHBak86bFJ0rLRoneUF2HrK160Nd5PP7LpVbUUXgEMbINw/oaQEltAD4Q5qEJxbVnA29Q6hWFEHp9uxykE/PtBWVFq6X6q/emmDJ7YPn3qHCY5CxIFIxsClslt02Fzcuk/hQUwn3IU4nXTkyP2tuFxv+ArAH7PqiEflHjSuQmk/MMVel9goNq4XYhMHGHI6v1K8sZdkfNEpAaPLM0UWCREuWbxCdIN8SH8V9wf/5evMXdrsBNDYiGObXInEquWRePIfExwVZ8zy5D6CCZsMVK7dCRpEtqT5QJj/GNOovWlC99K6gFvAdvmw9ccyi3ZBRLqftn13f0neJE3xizVV/B+qcakRZg9E9GipVz7IZijhxZ0opCwh3PiyqZ5bJ0u9Z012DAiJ89uMQ3REq/AG3qwVAP5rbba7ISg2ySp964k3hqblou+5SFtzHytt1c/WLCxtmBmVhl/+bd5REuqk07mGYKuJtSFzr2UQAN8hBmp/6mWViBUvkvB4SKGGHL6WBHIhp+8h4Zlt6S1KXr1C2fZL q2VjmX3j 1ec4wKHWu0xlTOo6j/sodHC8khNL03C7PuBmBkOLaHAlwcK2DXMK9lw/+OhWQFqIW1IpuGwUmfs6bMXQPIBivP7lXA9vzaWkhzcbaEXnujPyGkpRefplyXAxkXGCxiZ3P37ZXvTXbc8Qkzd70bGRGZHostasVS3jYnMSdBUjqkDzEjkzfolXNOWOQ87rkjp8Y2am1UQqWInIgqUwckJnt8t8+kGeJlRUsKZf5XViYvctBiDwuSlh1LnlX8Rf88psm8iKvuzmnOvrXvcEbfVmw98rJ4X7SZ8JSIUMpdFbfIZ6Pv0UD6rjNHjarhw8Vt5OhEfVFUAD3P5nXFf7cRVlRc+LBMG4PBNpSH5i1k+mVYlW/cKPPsNwRVgH3ssx91h/yPXRyK1tvJQSYY1JyMEmu0Z1ncw== 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: List-Subscribe: List-Unsubscribe: On 10/22/24 22:40, Lorenzo Stoakes wrote: > The mmap_region() function is somewhat terrifying, with spaghetti-like > control flow and numerous means by which issues can arise and incomplete > state, memory leaks and other unpleasantness can occur. > > A large amount of the complexity arises from trying to handle errors late > in the process of mapping a VMA, which forms the basis of recently observed > issues with resource leaks and observable inconsistent state. > > Taking advantage of previous patches in this series we move a number of > checks earlier in the code, simplifying things by moving the core of the > logic into a static internal function __mmap_region(). > > Doing this allows us to perform a number of checks up front before we do > any real work, and allows us to unwind the writable unmap check > unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE > validation unconditionally also. > > We move a number of things here: > > 1. We preallocate memory for the iterator before we call the file-backed > memory hook, allowing us to exit early and avoid having to perform > complicated and error-prone close/free logic. We carefully free > iterator state on both success and error paths. > > 2. The enclosing mmap_region() function handles the mapping_map_writable() > logic early. Previously the logic had the mapping_map_writable() at the > point of mapping a newly allocated file-backed VMA, and a matching > mapping_unmap_writable() on success and error paths. > > We now do this unconditionally if this is a file-backed, shared writable > mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however > doing so does not invalidate the seal check we just performed, and we in > any case always decrement the counter in the wrapper. > > We perform a debug assert to ensure a driver does not attempt to do the > opposite. > > 3. We also move arch_validate_flags() up into the mmap_region() > function. This is only relevant on arm64 and sparc64, and the check is > only meaningful for SPARC with ADI enabled. We explicitly add a warning > for this arch if a driver invalidates this check, though the code ought > eventually to be fixed to eliminate the need for this. > > With all of these measures in place, we no longer need to explicitly close > the VMA on error paths, as we place all checks which might fail prior to a > call to any driver mmap hook. > > This eliminates an entire class of errors, makes the code easier to reason > about and more robust. > > Reported-by: Jann Horn > Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails") > Cc: stable > Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka some nits below > --- > mm/mmap.c | 120 ++++++++++++++++++++++++++++++------------------------ > 1 file changed, 66 insertions(+), 54 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 66edf0ebba94..7d02b47a1895 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1361,20 +1361,18 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, > return do_vmi_munmap(&vmi, mm, start, len, uf, false); > } > > -unsigned long mmap_region(struct file *file, unsigned long addr, > +static unsigned long __mmap_region(struct file *file, unsigned long addr, > unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, > struct list_head *uf) > { > struct mm_struct *mm = current->mm; > struct vm_area_struct *vma = NULL; > pgoff_t pglen = PHYS_PFN(len); > - struct vm_area_struct *merge; > unsigned long charged = 0; > struct vma_munmap_struct vms; > struct ma_state mas_detach; > struct maple_tree mt_detach; > unsigned long end = addr + len; > - bool writable_file_mapping = false; > int error; > VMA_ITERATOR(vmi, mm, addr); > VMG_STATE(vmg, mm, &vmi, addr, end, vm_flags, pgoff); > @@ -1448,28 +1446,26 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > vm_flags_init(vma, vm_flags); > vma->vm_page_prot = vm_get_page_prot(vm_flags); > > + if (vma_iter_prealloc(&vmi, vma)) { > + error = -ENOMEM; > + goto free_vma; > + } > + > if (file) { > vma->vm_file = get_file(file); > error = mmap_file(file, vma); > if (error) > - goto unmap_and_free_vma; > - > - if (vma_is_shared_maywrite(vma)) { > - error = mapping_map_writable(file->f_mapping); > - if (error) > - goto close_and_free_vma; > - > - writable_file_mapping = true; > - } > + goto unmap_and_free_file_vma; > > + /* Drivers cannot alter the address of the VMA. */ > + WARN_ON_ONCE(addr != vma->vm_start); > /* > - * Expansion is handled above, merging is handled below. > - * Drivers should not alter the address of the VMA. > + * Drivers should not permit writability when previously it was > + * disallowed. > */ > - if (WARN_ON((addr != vma->vm_start))) { > - error = -EINVAL; > - goto close_and_free_vma; > - } > + VM_WARN_ON_ONCE(vm_flags != vma->vm_flags && > + !(vm_flags & VM_MAYWRITE) && > + (vma->vm_flags & VM_MAYWRITE)); > > vma_iter_config(&vmi, addr, end); I wonder if this one could be removed, earlier above we did the same config and neither parameters changed? But it was true before this patch as well, and maybe it's further refactored away later in the series, just noting. > /* > @@ -1477,6 +1473,8 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > * vma again as we may succeed this time. > */ > if (unlikely(vm_flags != vma->vm_flags && vmg.prev)) { > + struct vm_area_struct *merge; > + > vmg.flags = vma->vm_flags; > /* If this fails, state is reset ready for a reattempt. */ > merge = vma_merge_new_range(&vmg); > @@ -1491,10 +1489,11 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > */ > fput(vma->vm_file); > vm_area_free(vma); > + vma_iter_free(&vmi); If we merged successfully, I think this is not necessary? But doesn't hurt? > vma = merge; > /* Update vm_flags to pick up the change. */ > vm_flags = vma->vm_flags; > - goto unmap_writable; > + goto file_expanded; > } > vma_iter_config(&vmi, addr, end); > } > @@ -1503,26 +1502,15 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > } else if (vm_flags & VM_SHARED) { > error = shmem_zero_setup(vma); > if (error) > - goto free_vma; > + goto free_iter_vma; > } else { > vma_set_anonymous(vma); > } > > - if (map_deny_write_exec(vma->vm_flags, vma->vm_flags)) { > - error = -EACCES; > - goto close_and_free_vma; > - } > - > - /* Allow architectures to sanity-check the vm_flags */ > - if (!arch_validate_flags(vma->vm_flags)) { > - error = -EINVAL; > - goto close_and_free_vma; > - } > - > - if (vma_iter_prealloc(&vmi, vma)) { > - error = -ENOMEM; > - goto close_and_free_vma; > - } > +#ifdef CONFIG_SPARC64 > + /* TODO: Fix SPARC ADI! */ > + WARN_ON_ONCE(!arch_validate_flags(vm_flags)); > +#endif > > /* Lock the VMA since it is modified after insertion into VMA tree */ > vma_start_write(vma); > @@ -1536,10 +1524,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > */ > khugepaged_enter_vma(vma, vma->vm_flags); > > - /* Once vma denies write, undo our temporary denial count */ > -unmap_writable: > - if (writable_file_mapping) > - mapping_unmap_writable(file->f_mapping); > +file_expanded: > file = vma->vm_file; > ksm_add_vma(vma); > expanded: > @@ -1572,23 +1557,17 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > vma_set_page_prot(vma); > > - validate_mm(mm); > return addr; > > -close_and_free_vma: > - vma_close(vma); > - > - if (file || vma->vm_file) { > -unmap_and_free_vma: > - fput(vma->vm_file); > - vma->vm_file = NULL; > +unmap_and_free_file_vma: > + fput(vma->vm_file); > + vma->vm_file = NULL; > > - vma_iter_set(&vmi, vma->vm_end); > - /* Undo any partial mapping done by a device driver. */ > - unmap_region(&vmi.mas, vma, vmg.prev, vmg.next); > - } > - if (writable_file_mapping) > - mapping_unmap_writable(file->f_mapping); > + vma_iter_set(&vmi, vma->vm_end); > + /* Undo any partial mapping done by a device driver. */ > + unmap_region(&vmi.mas, vma, vmg.prev, vmg.next); > +free_iter_vma: > + vma_iter_free(&vmi); > free_vma: > vm_area_free(vma); > unacct_error: > @@ -1598,10 +1577,43 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > abort_munmap: > vms_abort_munmap_vmas(&vms, &mas_detach); > gather_failed: > - validate_mm(mm); > return error; > } > > +unsigned long mmap_region(struct file *file, unsigned long addr, > + unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, > + struct list_head *uf) > +{ > + unsigned long ret; > + bool writable_file_mapping = false; > + > + /* Allow architectures to sanity-check the vm_flags. */ > + if (!arch_validate_flags(vm_flags)) > + return -EINVAL; > + > + /* Check to see if MDWE is applicable. */ > + if (map_deny_write_exec(vm_flags, vm_flags)) > + return -EACCES; The two checks above used to be in the opposite order. Can we keep that just to be sure we don't change user observable behavior unnecessarily? > + /* Map writable and ensure this isn't a sealed memfd. */ > + if (file && is_shared_maywrite(vm_flags)) { > + int error = mapping_map_writable(file->f_mapping); > + > + if (error) > + return error; > + writable_file_mapping = true; > + } > + > + ret = __mmap_region(file, addr, len, vm_flags, pgoff, uf); > + > + /* Clear our write mapping regardless of error. */ > + if (writable_file_mapping) > + mapping_unmap_writable(file->f_mapping); > + > + validate_mm(current->mm); > + return ret; > +} > + > static int __vm_munmap(unsigned long start, size_t len, bool unlock) > { > int ret; > -- > 2.47.0