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 CE835D3B98B for ; Tue, 26 Nov 2024 12:36:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3368E6B0083; Tue, 26 Nov 2024 07:36:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E5E06B0085; Tue, 26 Nov 2024 07:36:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1399C6B0088; Tue, 26 Nov 2024 07:36:35 -0500 (EST) 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 E790F6B0083 for ; Tue, 26 Nov 2024 07:36:34 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 96FFEA0DC5 for ; Tue, 26 Nov 2024 12:36:34 +0000 (UTC) X-FDA: 82828194624.05.080DDE0 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf12.hostedemail.com (Postfix) with ESMTP id 4368440010 for ; Tue, 26 Nov 2024 12:36:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=boLqMRJr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=e4ozsGO8; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=boLqMRJr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=e4ozsGO8; spf=pass (imf12.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=1732624589; 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=BLEya6E7ELTfrUjipQUSn0lt0twW9YOZE0Q8PEW1SaA=; b=SALph2AwZIJeYJKFFkv/T3VRsVl6wJMmxXOuXsL0nf7/ArF1+VCNOB3SkEgBasKloPDQZ1 bjpKoeox7exr6IRw7pzTQ65wIlrdvkmauu+eKlNwjFMxyN2npqwiI4PuJ+JyT5FehDPv86 BRJY0vbI/naO3vaGHL+K45pWGlXHvrM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732624589; a=rsa-sha256; cv=none; b=ZBMo8FUabrav22zXEebd17tLhZJZWdUD7PKgFCBfXecoiUSCy5uVTBjoS10M6deMoSXgRJ PdGd7v93X9tQYOA00HYDjzeDy0mE0pOUsSU62xBh30CqLADObaY1OsGyWmsyNjj8ElPuaD OUPanSe+3Lds4nVrDS/Yc/h8M4U+LQM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=boLqMRJr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=e4ozsGO8; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=boLqMRJr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=e4ozsGO8; spf=pass (imf12.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 782FD1F745; Tue, 26 Nov 2024 12:36:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1732624590; 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=BLEya6E7ELTfrUjipQUSn0lt0twW9YOZE0Q8PEW1SaA=; b=boLqMRJramn1CbtheRx/PGZ4+1U8P3ymVkqWk67uVmWQWCdUuGMaVhHBxXv0h6ADF7RF2f +ZsB4wLi/zpIHc2/xblO+YQgef6HPAaGqdCVeAWEaK4orFiPmS1Xiplxj0RZTNB6B3kzgg Ek6ZcwMJUQCDXYUOZdxbHi6lzmIYDEA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1732624590; 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=BLEya6E7ELTfrUjipQUSn0lt0twW9YOZE0Q8PEW1SaA=; b=e4ozsGO8mMsBC5/830LFdI/VFGFhoUvUNeUayLlZI9nMqNJabMhNpO/g4DotpOyncszB0i U6w6o0QdSOEK/CBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1732624590; 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=BLEya6E7ELTfrUjipQUSn0lt0twW9YOZE0Q8PEW1SaA=; b=boLqMRJramn1CbtheRx/PGZ4+1U8P3ymVkqWk67uVmWQWCdUuGMaVhHBxXv0h6ADF7RF2f +ZsB4wLi/zpIHc2/xblO+YQgef6HPAaGqdCVeAWEaK4orFiPmS1Xiplxj0RZTNB6B3kzgg Ek6ZcwMJUQCDXYUOZdxbHi6lzmIYDEA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1732624590; 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=BLEya6E7ELTfrUjipQUSn0lt0twW9YOZE0Q8PEW1SaA=; b=e4ozsGO8mMsBC5/830LFdI/VFGFhoUvUNeUayLlZI9nMqNJabMhNpO/g4DotpOyncszB0i U6w6o0QdSOEK/CBA== 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 669D2139AA; Tue, 26 Nov 2024 12:36:30 +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 cyuyGM7ARWeWUQAAD6G6ig (envelope-from ); Tue, 26 Nov 2024 12:36:30 +0000 Message-ID: <9675f4f0-6290-43aa-bf17-6b9c2b461485@suse.cz> Date: Tue, 26 Nov 2024 13:36:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm/slab: Avoid build bug for calls to kmalloc with a large constant Content-Language: en-US To: Ryan Roberts , Dave Kleikamp , Andrew Morton Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20241014105514.3206191-1-ryan.roberts@arm.com> <20241014105912.3207374-1-ryan.roberts@arm.com> <20241014105912.3207374-6-ryan.roberts@arm.com> <44312f4a-8b9c-49ce-9277-5873a94ca1bb@oracle.com> <7fb6c5a2-b9ae-4a29-a871-2f0bdc636e41@arm.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: <7fb6c5a2-b9ae-4a29-a871-2f0bdc636e41@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 4cwzbuy1zp6usskku6kgtu7b567nxj7e X-Rspam-User: X-Rspamd-Queue-Id: 4368440010 X-Rspamd-Server: rspam02 X-HE-Tag: 1732624590-393096 X-HE-Meta: U2FsdGVkX1/zT7Uz+HnC9GYBiy1NHsgnQDsxynctEc8SiZVeTbtb2OoWh0mzfGk2chePJqKwHvAl8VtFpGhPq66phnRL5efOZjYjxEXETNE030jvg+k6/We2wARDkeKV45QCQ1G5EXFbqi6kHjCCxUl2JiXgEonGN/7/37ziTtk3nqnctRHAALYfksgEAvcLIJIa/mzvPHtYIRdI+NSC+W/7su4rnNGbdhPIw497YBrOWMXGUatpwhpotvfoogQFUJWIMvaG80No/89TRoP2znKMdFcTQAB37gHJ/0RBXtBNWUHgDFZs0TRwphmzYqWgrUkOgGtbKmmXCoIDzJsCSlWeeIZvGG4wuncQOKNoYJG/lKPiTlRFgRZpQBrhorGInMn/48AEhTmoT7hA+6Begi/KDeoZPO266kffW6EgAetdgcTCGyeMq9F1bBz+peP1zD9Dk7Hd+bR0iJHWeitrZqHcjXE6YfuwQsY1IXIoGXNK04WX+lbBCuEkrgXDr7SS25UkpK+c4/+8zkpKsy5JHHQy+ub7uw+eb71e+C4xN2HTizywz6hhDG6yWkD3K5lpdMba/QZ9H/ALNN69wRrCDUoo3BmbD5512Xn6zmUHfXs8F3P/deBi/ZWBHEEzyNwEUBGK0I0ZroGHOcKTP8nfYDN2VB0W75oI6BpHrgd4tgUF8ojsfu1MqXbt4aIzOxjBXZ+ROfWBxSM3YyZHsS9PLS+0O5sfRimA9oZcyFS4HusnJ7IH5LMUoAPjx97sXQxATHhal5C9amlWgxrN1DwGthXYxZYc7Av/iRIwqXSGePPv04ezp9HH1h6tTxFO420TNVrINSX9EKYSLCU3loBgO6wly1b9EBPLWc58jJXzy94V8LJ0VY1mjhNqWzJkkiTiUcULW0DnLyKiTgkg2R5JT5ffZbYAst1mTlzZAJc6at9oMb1xaUFD7JaDp8Edq/CNbzfQS/jT86xJpAFLW+l ZM/CMKPG Cpe8vOyc90i9DU3JZYyepUqyhcmJ5JIhK89frWRNc2j6TaIvb7Z8NI8BfoacTG8u7L0InlDhxcPXHKhcX5rA+row8DMkzYZGMCcwf/e/bYq0DIv3crkVdRaYaRbNfCGRSJO+fM0O2xbk+Z7oXxdTavK/VkJMLIArrBEeM5TwSY4MidYNtC3Vf4kxT9+zzpszpRQAVryqmsB0diBb3kHsx1haGhXweDmf/kS9OLitsl6HNV5u6sh+XbQN4nWiNZwuQLlUC55XnwNemkCubX9JTUH5bd5UWkd+uXhvCZMLJgl7HZwQ2RAY8D90vig== 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 11/26/24 13:18, Ryan Roberts wrote: > On 14/11/2024 10:09, Vlastimil Babka wrote: >> On 11/1/24 21:16, Dave Kleikamp wrote: >>> When boot-time page size is enabled, the test against KMALLOC_MAX_CACHE_SIZE >>> is no longer optimized out with a constant size, so a build bug may >>> occur on a path that won't be reached. >> >> That's rather unfortunate, the __builtin_constant_p(size) part of >> kmalloc_noprof() really expects things to resolve at compile time and it >> would be better to keep it that way. >> >> I think it would be better if we based KMALLOC_MAX_CACHE_SIZE itself on >> PAGE_SHIFT_MAX and kept it constant, instead of introducing >> KMALLOC_SHIFT_HIGH_MAX only for some sanity checks. >> >> So if the kernel was built to support 4k to 64k, but booted as 4k, it would >> still create and use kmalloc caches up to 128k. SLUB should handle that fine >> (if not, please report it :) > > So when PAGE_SIZE_MAX=64K and PAGE_SIZE=4K, kmalloc will support up to 128K > whereas before it only supported up to 8K. I was trying to avoid that since I > assumed that would be costly in terms of extra memory allocated for those higher > order buckets that will never be used. But I have no idea how SLUB works in > practice. Perhaps memory for the cache is only lazily allocated so we won't see > an issue in practice? Yes the e.g. 128k slabs themselves will be lazily allocated. There will be some overhead with the management structures (struct kmem_cache etc) but much smaller. To be completely honest, some extra overhead might come to be when the slabs are allocated ans later the user frees those allocations. kmalloc_large() wwould return them immediately, while a regular kmem_cache will keep one or more per cpu for reuse. But if that becomes a visible problem we can tune those caches to discard slabs more aggressively. > I'm happy to make this change if you're certain it's the right approach; please > confirm. Yes it's much better option than breaking the build-time-constant part of kmalloc_noprof(). >> >> Maybe we could also stop adding + 1 to PAGE_SHIFT_MAX if it's >=64k, so the >> cache size is max 64k and not 128k but that should be probably evaluated >> separately from this series. > > I'm inferring from this that perhaps there is a memory cost with having the > higher orders defined but unused. Yeah as per above, should not be too large and we could tune it down if necessary. > Thanks, > Ryan > >> >> Vlastimil >> >>> Found compiling drivers/net/ethernet/qlogic/qed/qed_sriov.c >>> >>> Signed-off-by: Dave Kleikamp >>> --- >>> >>> Ryan, >>> >>> Please consider incorporating this fix or something similar into your >>> mm patch in the boot-time pages size patches. >>> >>> include/linux/slab.h | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/slab.h b/include/linux/slab.h >>> index 9848296ca6ba..a4c7507ab8ec 100644 >>> --- a/include/linux/slab.h >>> +++ b/include/linux/slab.h >>> @@ -685,7 +685,8 @@ static __always_inline unsigned int __kmalloc_index(size_t size, >>> if (size <= 1024 * 1024) return 20; >>> if (size <= 2 * 1024 * 1024) return 21; >>> >>> - if (!IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) >>> + if (!IS_ENABLED(CONFIG_ARM64_BOOT_TIME_PAGE_SIZE) && >>> + !IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) >>> BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); >>> else >>> BUG(); >> >