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 8F13CD3C935 for ; Mon, 21 Oct 2024 17:26:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F2F26B0089; Mon, 21 Oct 2024 13:26:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07CCB6B008C; Mon, 21 Oct 2024 13:26:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE9EE6B0093; Mon, 21 Oct 2024 13:26:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BC8756B0089 for ; Mon, 21 Oct 2024 13:26:15 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5432C140376 for ; Mon, 21 Oct 2024 17:25:59 +0000 (UTC) X-FDA: 82698287742.28.1796D28 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf07.hostedemail.com (Postfix) with ESMTP id 537494000E for ; Mon, 21 Oct 2024 17:25:52 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YrXoX5mK; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gUlqYEb4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YrXoX5mK; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gUlqYEb4; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729531422; 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=UZv9f7LMlXSjmsbwslEKPBtm1QgaxLmQcoTj3XO9DvQ=; b=fQPw62Qj40QlQ8GGXpw/bl7B+S6WcQAxUlU/pGNiWe5tQlJq6PaqbFDbfdngzZcIjdIjTZ 6nXvBvo1BdxKzpS+V8dBLd6zaWGhsmNsWck4xDavJxmQSl5TDxKDwN4vqVd59+DF+mWZPw 1Dn8XQQImvGxsZHYOgees4ha9rVVY+8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729531422; a=rsa-sha256; cv=none; b=ctgPlAZqZ0TkIUxwkfeFDrX9dFtxNPlk/6cQHhZ//as5lNHnLQG+UJG0qbVyBBTjxwk11K c/a78D/q5CromKGmJmfwwWVbcRTiKV+MTu3OufptZtrJ4GCQNh70oE1Aij44myAyBvGBW/ OAn5ytD7NJhyVyQb80uH6ZCi/bW5Qjc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YrXoX5mK; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gUlqYEb4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YrXoX5mK; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gUlqYEb4; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none 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-out2.suse.de (Postfix) with ESMTPS id 2A8C51F80C; Mon, 21 Oct 2024 17:26:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729531571; 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=UZv9f7LMlXSjmsbwslEKPBtm1QgaxLmQcoTj3XO9DvQ=; b=YrXoX5mKHHiuoR5IRYvUGZw7aCw2cW4dJUqyx/Wr+OjXLNmA6IDzC48BDXVmf5h0Uqq961 dIq59SQaNRJSShXalIyQAtLNjNrvLJ4IFBkFJmxgD9SueibkCbZzN6Paehxw0pmj6BJC7I DDeVrjio0eREaxVRft/ak3LWhywi4Iw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729531571; 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=UZv9f7LMlXSjmsbwslEKPBtm1QgaxLmQcoTj3XO9DvQ=; b=gUlqYEb4wQQPD/TGWY9HQQV5JQS00CvegZPA3DRcfBrUorVqmfFeSg/b4IpcR17fANVQFB 9a2FEH2XJqKLMQDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729531571; 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=UZv9f7LMlXSjmsbwslEKPBtm1QgaxLmQcoTj3XO9DvQ=; b=YrXoX5mKHHiuoR5IRYvUGZw7aCw2cW4dJUqyx/Wr+OjXLNmA6IDzC48BDXVmf5h0Uqq961 dIq59SQaNRJSShXalIyQAtLNjNrvLJ4IFBkFJmxgD9SueibkCbZzN6Paehxw0pmj6BJC7I DDeVrjio0eREaxVRft/ak3LWhywi4Iw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729531571; 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=UZv9f7LMlXSjmsbwslEKPBtm1QgaxLmQcoTj3XO9DvQ=; b=gUlqYEb4wQQPD/TGWY9HQQV5JQS00CvegZPA3DRcfBrUorVqmfFeSg/b4IpcR17fANVQFB 9a2FEH2XJqKLMQDw== 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 D966F136DC; Mon, 21 Oct 2024 17:26:10 +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 HlhSNLKOFmc/EAAAD6G6ig (envelope-from ); Mon, 21 Oct 2024 17:26:10 +0000 Message-ID: <8329667f-73b6-48fe-8f3c-07c741462fee@suse.cz> Date: Mon, 21 Oct 2024 19:26:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] mm: add PTE_MARKER_GUARD PTE marker Content-Language: en-US To: Lorenzo Stoakes , David Hildenbrand Cc: Andrew Morton , Suren Baghdasaryan , "Liam R . Howlett" , Matthew Wilcox , "Paul E . McKenney" , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song , Richard Henderson , Ivan Kokshaysky , Matt Turner , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Chris Zankel , Max Filippov , Arnd Bergmann , linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-arch@vger.kernel.org, Shuah Khan , Christian Brauner , linux-kselftest@vger.kernel.org, Sidhartha Kumar , Jeff Xu , Christoph Hellwig , linux-api@vger.kernel.org, John Hubbard References: <081837b697a98c7fa5832542b20f603d49e0b557.1729440856.git.lorenzo.stoakes@oracle.com> <470886d2-9f6f-4486-a935-daea4c5bea09@suse.cz> <434a440a-d6a4-4144-b4fb-8e0d8535f03f@lucifer.local> <4f4e41f1-531c-4686-b44d-dacdf034c241@lucifer.local> <49afa956-21e1-4b3d-9dde-82a6891f2902@redhat.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 4diy6dpsr31yhi1guyjp4c4hj9p9whq4 X-Rspamd-Queue-Id: 537494000E X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1729531552-503181 X-HE-Meta: U2FsdGVkX1+PXVkTtw20ggpsmajnOFo0JD5xwqXu9Ym1ViZl2hdpGX8O7G2dvf+2EQg64xGQ8+2US2pzxmi0SdVyj7J3fjcQoBCnPtGyaF25xbDKN5VMvu5+xcigaJwyvdm9PUVocadTDSFJA67+JUzvHnjRwWZK1MHsSmk258UNmHij5sG2VjS2WEIbbLr0Sil/XAmA++wwzZGJEXfPhMvq+/kjo/NeQBzgL/AzWAxtsi1UZCzFVMyan3n8IqsOuqGN/LG/WwLnazt9ySAY4KD5qF8SodueCL4Wg2mf1i8SalxylDJ+8LrIPt+kiy3WwF6Y4ouYj2cxLoPTPqaPaFHc2bHpdkRo8V26+ySJVZObVMXkEFPiah+cGM0hS08xEhMmDympqifnNNCIVEYV30S8YcnKvL3XvxxSFMstjcWUTdubrVbNqwEBimnuvUxsZqKNIujvFmXkSDanDYq/7BefRjYSSTToXdPQGej+44hZ5i+KX4xiFXK+uD+2n/2sEBM1hT7TW91rzB2WG+J/wK//gZmHWZt2sGFKxCimrlI89kaaM2rIaxtIwG3inyzYmv9tAQK2HsvDvdxtTqYsB+XX+rGTnsXsQaR83EKG8aXsfqbEwktaHlRCyPAUaT5LOeT+DJCW2Ej5ZbQuioOkBWEBDRdTaxvHrflG6Jl0FOZiMhrIXT7aNUCJ8n8GYIttirwUA7k6JM43WfQJ5hQfHxIeyu4HJZuV5+DyvL9G7HCv5cIAXykbyhFvOEslQBVWZ8E8WTDd9O5aKIH1AWebSNTpwHtX6uKGHpnarMlrskOyOcRZUnpI/LtgLC+DownGsLzE94uczsvwRFiSlXMdGqwe9UqBjOGBHTvy21ZXsVwED1ChpRq7xfP/CvBgZ8AfkXdGyOePLYFeo/+9ZTsbQ3zHlgTYAGO8KI1D5GG36mx6MKn4PYUgkjyhjC6+68j62X98DZHuCrfMR9CCOAL QSgIPHur 8EHl5jQKX2kLWcSDFXv2pC3tziGsj/U8E1DyNivYpedVF2ndT/dnuNJeaKDMZ1FRpmRqnIiKepyCHdi+XXOa2CKCoaSoVbh0lvXaAEHW1DggZW8Nloj1AmECHq5gKZW6Me2UvLVl8AjZBczS5rOJjzFriFPquM6riI1S6935fVrzmgRPZCL5dDr3R1c++uJp4kcJyQg5RM/ot8rJ2STR4FtIBD1jZoEDIBm1xwIjQC2bSCvW0b8JbhmVEqJ35QeMt4Y1SQD+xuPvbLbFjsI1tYcBwj6D33YFiTv4NpdE8NRJDHMcavcQwd7+FJIXR87USQhWsQ87bu9yEhZFHgLBdUiUJnA== 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/21/24 19:14, Lorenzo Stoakes wrote: > On Mon, Oct 21, 2024 at 07:00:53PM +0200, David Hildenbrand wrote: >> >> > >> > > >> > > > >> > > > Also the existing logic is that existing markers (HW poison, uffd-simulated HW >> > > > poison, uffd wp marker) are retained and no error raised on MADV_DONTNEED, and >> > > > no error on MADV_FREE either, so it'd be consistent with existing behaviour. >> > > >> > > >> > > HW poison / uffd-simulated HW poison are expected to be zapped: it's just >> > > like a mapped page with HWPOISON. So that is correct. >> > >> > Well, poison is _not_ zapped on MADV_DONTNEED but _is_ on MADV_FREE :) anyway, I >> >> Huh? >> >> madvise_dontneed_single_vma()->zap_page_range_single(details=NULL)->unmap_single_vma(details=NULL) >> ... zap_pte_range() >> >> } else if (is_hwpoison_entry(entry) || >> is_poisoned_swp_entry(entry)) { >> if (!should_zap_cows(details)) >> continue; >> ... >> >> Should just zap them. >> >> What am I missing? > > Yeah ok it's me who's missing something here, I hadn't noticed details == NULL > so should_zap_cows() is true, my mistake! Well, good to know it's consistent then. As I've explained I see why zapping actual hwpoison makes sense for MADV_DONTNEED/MADV_FREE. That it's done also for uffd poison is not completely clear, but maybe it was just easier to implement. But it doesn't mean we have to do the same for GUARD PTEs. Either behavior of zap/ignore/error could be valid, we just have to pick one and then live with it as it can't change :) Zapping guards on DONTNEED/FREE seems wrong to me, so it's between error (and potentially catching some misuse) and ignore (potentially more performant in case somebody wants to DOTNEED/FREE an area that contains scattered guards). And the impossibility to meaningfully unwind on errors in the middle of the operation (unless we pre-scan for guards) isn't exactly nice, so maybe just ignore, i.e. the current approach? > In any case we explicitly add code here to prevent guard pages from going. I > will correct everything where I wrongly say otherwise, doh! > >> >> > mean the MADV flags are a confusing mess generally, as per Vlasta's comments >> > which to begin with I strongly disagreed with then, discussing further, realsed >> > that no this is just a bit insane and had driven _me_ insane. >> > >> > > >> > > UFFD-WP behavior is ... weird. Would not expect MADV_DONTNEED to zap uffd-wp >> > > entries. >> > > >> > > > >> > > > Also semantically you are achieving what the calls expect you are freeing the >> > > > ranges since the guard page regions are unbacked so are already freed... so yeah >> > > > I don't think an error really makes sense here. >> > > >> > > I you compare it to a VMA hole, it make sense to fail. If we treat it like >> > > PROT_NONE, it make sense to skip them. >> > > >> > > > >> > > > We might also be limiting use cases by assuming they might _only_ be used for >> > > > allocators and such. >> > > >> > > I don't buy that as an argument, sorry :) >> > > >> > > "Let's map the kernel writable into all user space because otherwise we >> > > might be limiting use cases" >> > >> > That's a great idea! Patch series incoming, 1st April 2025... :>) >> >> :) Just flip the bit on x86 and we're done! > > ;) > >> >> > > >> > > >> > > :P >> > > >> > > -- >> > > Cheers, >> > > >> > > David / dhildenb >> > > >> > >> > Overall I think just always leaving in place except on remedy err sorry sorry >> > unpoison and munmap and not returning an error if encountered elsewhere (other >> > than, of course, GUP) is the right way forward and most in line with user >> > expectation and practical usage. >> >> >> Fine with me, make sure to document that is behaves like a PROT_NONE VMA, >> not like a memory hole, except when something would trigger a fault (GUP >> etc). > > Ack will make sure to document. > >> >> >> -- >> Cheers, >> >> David / dhildenb >>