From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E231D1B4C41 for ; Wed, 11 Sep 2024 17:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726075542; cv=none; b=qan9QuQi+4jPXQwDcdf0LGAUH8RpbdLdBrd5+NBCVDaHM8G96xGdhx7Jha5IyvB0l9tDmXyekv0rtdAZ1vU0/3h3WgFCOO+jLnSb7ZooJTrHyAcj/M/GugCgeHd0ePpCkWFDQPugsA47X9iQlVPiApzbrPI0BX/habY/qUG2ljU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726075542; c=relaxed/simple; bh=2CXGVg6NEhqLRKhGUyW5174lZyw87X6GSvdQUeR5MmQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=s7iL+WzN3hjePKA/C3vlKjoTMwAxztbvIgUywfEZSM+wHratp+XpeZjwRmqOVEfaaBZgm+qqBIWYIHE8zLnsmyXLRzEN70crVmVZyj4i3JbILvtx8cVyg78E1ZwGhZXEUX+25v5pazzKSTxPNod0qQi4BSaSegJw3bV6pRXhJUc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=HwHjrkA7; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="HwHjrkA7" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-42cb0f28bfbso20947815e9.1 for ; Wed, 11 Sep 2024 10:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1726075538; x=1726680338; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xmCKuyw0DapJvOtbSWzmF0OL2IUWJWDlS7+rw4t0ojA=; b=HwHjrkA7gzRnzqnFdZlE8r6f5osEn/6loIJMeUgfFx4K6WN80pA/kVCIa5Z2V2BRjK oBIAS4iyhXLPEyteeDJ2g/iOKbY6g746NyGc8G3DudBVDhzwdzvp4GUFLXSf9kTz6R4W OtWw5cnx6+4KIgkTKLzWtNAgIVuhuG3/mq3vhGlM/dcdkWYyxSoFxEjjk3MKjiuI1yZd JBjlhTRp9dyISMNvcHvGgYAeA72qQwwQFI/b4w1qlVEWFyjOqVnJ85gJzjm5lBEGBY8N JsTslB+5SyT9CRCvWieZ0bprCE0C8qYgGMhya917d5SNnXLn197NHtrzqQ/Eys7coEqA 8eBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726075538; x=1726680338; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xmCKuyw0DapJvOtbSWzmF0OL2IUWJWDlS7+rw4t0ojA=; b=gB29qwekYabvWuqxRxjJA24Vk52reHuy7v4s+2cn0k3OqFIml1kNTfaROtmHV307xi 8kW/VuK5vbcmta0OAZe55hmd5XeIUXO4htHyL1jzNy0M99PxufrVb7DXlHCVRFf6KgJn KiEKejdAarZl9gW6x0D3DeUXnwMhUHfMOGp9ajyePWv2NgzRs2i7MGX00dORz2Ydn45c r9qUKAHbYDGk3Np7RjZT4pjLTofSA9drDFzA9quZPhs4WI0hxdsHLnevHoNvCae3ojAO +/0FNv1paZiQs6pql1CYr/W6JNbuEh01Aif4N+qr9HJRJQTsXebA96EiqkoKjQ4EC0Om vYOg== X-Forwarded-Encrypted: i=1; AJvYcCWKQ3TRdvcEM4X7wJtL/0X5RfN4LzDLydqJJXbcJBrNl4OjwvJW31v/9kmiEzye/WtnUOBh3LLL8DMVGDs=@vger.kernel.org X-Gm-Message-State: AOJu0YzBIpnedlloqgbll3pDWtQYIV/n5hUogMr6LEszzbYzNrETS3EJ uZqQeKHGsrfMcwvcQN3C5OGWg/4yP+DRppSkLDx274Emz5lrucLeZxBiKbNzcJI= X-Google-Smtp-Source: AGHT+IHwgouVHhx28DMTt5PoacyStj3TzOC4jjzt7G5qL8rZ2fYGdKla/4VYhBMKB9fgtOsriRz47g== X-Received: by 2002:a5d:6111:0:b0:374:93c4:2f61 with SMTP id ffacd0b85a97d-378b07966dbmr2405056f8f.5.1726075538049; Wed, 11 Sep 2024 10:25:38 -0700 (PDT) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3789564a18asm12049442f8f.15.2024.09.11.10.25.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 10:25:37 -0700 (PDT) Date: Wed, 11 Sep 2024 20:25:33 +0300 From: Dan Carpenter To: Hans de Goede Cc: Lorenzo Stoakes , Andrew Morton , Richard Narron , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mauro Carvalho Chehab , Sakari Ailus , Greg Kroah-Hartman , Marcin Wojtas , Russell King , "David S . Miller" , Arnd Bergmann , Linus Torvalds , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH hotfix 6.11] minmax: reduce egregious min/max macro expansion Message-ID: References: <20240911153457.1005227-1-lorenzo.stoakes@oracle.com> <181dec64-5906-4cdd-bb29-40bc7c02d63e@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <181dec64-5906-4cdd-bb29-40bc7c02d63e@redhat.com> On Wed, Sep 11, 2024 at 06:24:54PM +0200, Hans de Goede wrote: > Hi Lorenzo, > > On 9/11/24 5:34 PM, Lorenzo Stoakes wrote: > > Avoid nested min()/max() which results in egregious macro expansion. > > > > This issue was introduced by commit 867046cc7027 ("minmax: relax check to > > allow comparison between unsigned arguments and signed constants") [2]. > > > > Work has been done to address the issue of egregious min()/max() macro > > expansion in commit 22f546873149 ("minmax: improve macro expansion and type > > checking") and related, however it appears that some issues remain on more > > tightly constrained systems. > > > > Adjust a few known-bad cases of deeply nested macros to avoid doing so to > > mitigate this. Porting the patch first proposed in [1] to Linus's tree. > > > > Running an allmodconfig build using the methodology described in [2] we > > observe a 35 MiB reduction in generated code. > > > > The difference is much more significant prior to recent minmax fixes which > > were not backported. As per [1] prior these the reduction is more like 200 > > MiB. > > > > This resolves an issue with slackware 15.0 32-bit compilation as reported > > by Richard Narron. > > > > Presumably the min/max fixups would be difficult to backport, this patch > > should be easier and fix's Richard's problem in 5.15. > > > > [0]:https://lore.kernel.org/all/b97faef60ad24922b530241c5d7c933c@AcuMS.aculab.com/ > > [1]:https://lore.kernel.org/lkml/5882b96e-1287-4390-8174-3316d39038ef@lucifer.local/ > > [2]:https://lore.kernel.org/linux-mm/36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local/ > > > > Reported-by: Richard Narron > > Closes: https://lore.kernel.org/all/4a5321bd-b1f-1832-f0c-cea8694dc5aa@aaazen.com/ > > Fixes: 867046cc7027 ("minmax: relax check to allow comparison between unsigned arguments and signed constants") > > Cc: stable@vger.kernel.org > > Signed-off-by: Lorenzo Stoakes > > Thank you for your patch. > > I must say that I'm not a fan of that this is patching 3 totally > unrelated files here in a single patch. > > This is e.g. going to be a problem if we need to revert one of > the changes because of regressions... These kinds of thing also complicates backporting to stable. The stable kernel developers like whole, unmodified patches. So if we have to fix something in sDIGIT_FITTING() then we'd want to pull this back instead of re-writing the fix on top of the original define (unmodified patches). But now we have to backport the chunk which changes mvpp2 as well (whole patches). regards, dan carpenter