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 0F576C3DA59 for ; Fri, 19 Jul 2024 08:35:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8840A6B0083; Fri, 19 Jul 2024 04:35:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 834BA6B0089; Fri, 19 Jul 2024 04:35:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AE0A6B008C; Fri, 19 Jul 2024 04:35:57 -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 4E42B6B0083 for ; Fri, 19 Jul 2024 04:35:57 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D06F1A256F for ; Fri, 19 Jul 2024 08:35:56 +0000 (UTC) X-FDA: 82355844312.01.B4D1F30 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf05.hostedemail.com (Postfix) with ESMTP id 78E1D100028 for ; Fri, 19 Jul 2024 08:35:54 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RrTgH0r/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zFXaBPJo; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RrTgH0r/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zFXaBPJo; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 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=1721378112; 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=1tgusl4FKQY7tGPrdECOdjKOCpwryhf02vVCHTRCCd0=; b=VXgT7EXl0DEICj5O+9usog4WU4x56GPpgodPfDyYWh4TZ8InUuyJ1PT0TobGQWtivkUhEY Uvgc3pfH0JMLdBFq89r8VGXda6ovU0z0jV3uu0uEoWM5JWWdSno6arhsWDs9rlBDwKs4ge JvWrnO6082LioA39Ch1jW6xNXORaR/Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721378112; a=rsa-sha256; cv=none; b=dHorYWt9f/VH2VtCGokzs1Dz9OcimMtl6Ce8YXU8OfMAbY/L/z7EqrhmzU/fCp5EjzADLn DjQX+EjraTLlPaia73UyJTkocB3hhDr5JN9e1t2BEinTW3wlwg2yQ90pbShvXYDbyhsuo7 0/8Ze11pbSMgViGJ33WYa/720nNV6B8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RrTgH0r/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zFXaBPJo; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RrTgH0r/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zFXaBPJo; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 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-out1.suse.de (Postfix) with ESMTPS id D9BF721AED; Fri, 19 Jul 2024 08:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1721378152; 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=1tgusl4FKQY7tGPrdECOdjKOCpwryhf02vVCHTRCCd0=; b=RrTgH0r/0SaGQ5hU0iZJjWjc4C3zZJFyy8OJNcdoMEDfUEdaz0N/vXSFrMiuUoVmznDAcC jmcPLB8bf0gy+B8aSMYb3hlq2t0ys37oQ5I98YSNXyBl1AfPuITHs7sU7OhnyIPjGNhnNx CvFYb4uX6bMg8YXpApapr7sfiiO57vY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1721378152; 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=1tgusl4FKQY7tGPrdECOdjKOCpwryhf02vVCHTRCCd0=; b=zFXaBPJoNsCzes5vIieY76lnSvkRVH2IkLJGX4oLv5HU0sUu4b/sigmxTuPebi8f+hSbMC Hz5H2rKPJ9SKVBAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1721378152; 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=1tgusl4FKQY7tGPrdECOdjKOCpwryhf02vVCHTRCCd0=; b=RrTgH0r/0SaGQ5hU0iZJjWjc4C3zZJFyy8OJNcdoMEDfUEdaz0N/vXSFrMiuUoVmznDAcC jmcPLB8bf0gy+B8aSMYb3hlq2t0ys37oQ5I98YSNXyBl1AfPuITHs7sU7OhnyIPjGNhnNx CvFYb4uX6bMg8YXpApapr7sfiiO57vY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1721378152; 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=1tgusl4FKQY7tGPrdECOdjKOCpwryhf02vVCHTRCCd0=; b=zFXaBPJoNsCzes5vIieY76lnSvkRVH2IkLJGX4oLv5HU0sUu4b/sigmxTuPebi8f+hSbMC Hz5H2rKPJ9SKVBAg== 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 B9042132CB; Fri, 19 Jul 2024 08:35:52 +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 PndvLGglmmZBOAAAD6G6ig (envelope-from ); Fri, 19 Jul 2024 08:35:52 +0000 Message-ID: <8f5270ec-1745-4e68-b3b3-cdc6bb48c4a2@suse.cz> Date: Fri, 19 Jul 2024 10:35:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Barry Song <21cnbao@gmail.com>, Michal Hocko Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> References: <20240717230025.77361-1-21cnbao@gmail.com> Content-Language: en-US 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: 8bit X-Stat-Signature: czcfidyeeq3u8pbb948bki6qenpu1ddz X-Rspamd-Queue-Id: 78E1D100028 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1721378154-971365 X-HE-Meta: U2FsdGVkX18tv80ZBN3euvAnPTO7zTlgRzWgtfyMjScGULr9K7U9GlH94X2L9o6mbjzN0/eGIbAvdEXU4tabwXFv2ZxnHzA04pFl0cG+IUeMTOXwjrQGpjtbXM6RhLV/66S+CpHnLk9fz7gUYexS5ELkj/fTyiOAajIxkGX/7LaRYkD1TdsPF7SExZNLxwMVtGCbk0sSPcE02zkhcf6diYnfw9ETWVt0TFSilU93h5m+JyVk8Jb150s2D7ByqycJbeWahfU6gpTnUCFHfTuvCP31GYoDdXRC3DDKF/lVjp2sPXXs6Q/J5lVM3Qk7omfpGIZ3ZXaeTB3xvNppvz6cZY/Gyq/LQlh9karhkk8JU8xBQnw11MTWDLwYCeAHPxLNgJQ2b4djP62aL5WHrfv95RuYHfuA5hHqv+vgSsShsgPW6UYCQHnZiUl1MrBnju55dMMHETs60UB0GU4wkME4RvJ4yU5N1NMAMUCSdSC5WvDTUl4Dt+aE46fTHoU9gKOLDuRIZA9upvd+TFCTBGKfFh3Cyjem1S7w7tS9U5occLYZxwgBkVufe7gUcfHy2PK0KyAjdL5+n0QVoPkWiIKLbYDRZPUoqx/scZn6gEWPIBl++Q/L3szpXD8kGEREtbHRJmkKjUNxIqA1Td7tSvCtBee5V1gj0xBAZ8Dyt4lRrGGvxOrwDA5ZtWiVmAaebazuUvTufHGWszttiVGcNDqdgTNkdI2P4c3ALJ7s/0pcXbF4YaSxyuMe+V40kX4gw57/NfSaCF/Fv329pVEUH82oyU7td8KNHl6nmofxOvw9ta+QiLdauuMCEvWwJNrx1gZ15zj1Ylj1elNWhUqabkQzVIoh+Q34uoPUHbo840EFVhY6FHgFQk52qjY/xxyUw7VxjJCMcHToUyTVTs05quxXA0bEUmLDd0TnSJHpG/dUuUeiimKSkJ3xpMnZ9p+EEl3Igq4zCMRra+VQengnTY8 G0M+5TUB H76Zqv81C75BXM0sg8BVxHdgJADRY85qxdVqe9lEGvWCt4P4IapdjIQZvaCXCrKcWdO0GvkUXjmCheV22vBy3WsyN6XAprHaIb9ZLEugAhhFAS/EEaDEKKmnU/+FWusZq/Ysv/An/7BxtgbmdWT8yJ9YqvEK6ylltKsznLXufgJUVwhxQRsYKVBZpTb1UxnV+Q+iVeLVamsmH9/wfS9XFR1S92G0G54X3FlrM6UcJ98BRJV1gVOxUCd4AlY2eyhvfDCznwZbPF+7p1zgOHveQDXo1GToJKbtDwPKvmBTi0bEVPFbIhG06HBhtLe62dIk9zFPGpOr+JTkZMJms2jAFGujdy98Us6WTh0uFH9rZ1/eUowdV+kCKoZ4Y0xp46uNXKoYddaAtQbTu281VXW9cqu5T9xNXXaSok1oOoOdObpfKf3Zs3NwpPkCsSN5GJ3ol/G2rW9qBWvQ+TTd3pC1NaHfY+w== 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 7/19/24 2:35 AM, Barry Song wrote: > On Thu, Jul 18, 2024 at 8:50 PM Michal Hocko wrote: >> >> On Thu 18-07-24 20:43:53, Barry Song wrote: >> > On Thu, Jul 18, 2024 at 8:32 PM Michal Hocko wrote: >> > > >> > > On Thu 18-07-24 20:18:02, Barry Song wrote: >> > > > So the purpose is making sure the semantics - NOFAIL means no failure >> > > > and we don't need to check ret. If we can't really succeed, it should throw >> > > > a BUG to stop any potential exploits. >> > > >> > > This would require to panic consistently on failure in all allocator >> > > path that can bail out. E.g. page allocator on GFP_NOWAIT|GFP_NOFAIL >> > > req. not sure how many more. >> > >> > Right, this GFP_NOFAIL issue seems quite messy. However, at least vmalloc >> > will retry by itself, even if alloc_pages might have failed with >> > GFP_NOWAIT | GFP_NOFAIL. >> > >> > But isn't that the definition of __GFP_NOFAIL? >> > >> > * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller >> > * cannot handle allocation failures. The allocation could block >> > * indefinitely but will never return with failure. Testing for >> > * failure is pointless." >> > >> > So I believe any code that doesn't retry and ends up returning NULL should be >> > fixed. >> >> Yes, those shouldn't really fail. NOWAIT|NOFAIL was something that >> should never happen and I really hope it doesn't. Others should really >> retry but it's been some time since I've checked the last time. > > > I assume allocations directly using alloc_pages() might not respect GFP_NOFAIL > and violate the semantics of GFP_NOFAIL. > > static inline struct page * > __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > struct alloc_context *ac) { > /* > * Make sure that __GFP_NOFAIL request doesn't leak out and make sure > * we always retry > */ > if (gfp_mask & __GFP_NOFAIL) { > /* > * All existing users of the __GFP_NOFAIL are blockable, so warn > * of any new users that actually require GFP_NOWAIT > */ > if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > goto fail; > ... > } > > Additionally, at least drivers/vdpa/vdpa_user/iova_domain.c is > incorrect with GFP_ATOMIC > | __GFP_NOFAIL. > > void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain) > { > ... > > count = domain->bounce_size >> PAGE_SHIFT; > for (i = 0; i < count; i++) { > ... > > /* Copy user page to kernel page if it's in use */ > if (map->orig_phys != INVALID_PHYS_ADDR) { > page = alloc_page(GFP_ATOMIC | __GFP_NOFAIL); This should be already triggering the warning above? If it doesn't nobody yet reached the particular line in the alloc slowpath. Probalby thanks to the GFP_ATOMIC reserves. Maybe we should tighten the warnigns then. > memcpy_from_page(page_address(page), > map->bounce_page, 0, PAGE_SIZE); > } > put_page(map->bounce_page); > map->bounce_page = page; > } > domain->user_bounce_pages = false; > out: > write_unlock(&domain->bounce_lock); > } > > GFP_NOFAIL things need to be fixed. Let me investigate further. > >> >> These overflow checks were added without any acks by MM people... >> -- >> Michal Hocko >> SUSE Labs > > Thanks > Barry