All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Richard Narron <richard@aaazen.com>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Marcin Wojtas <marcin.s.wojtas@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
	linux-mm@kvack.org, Andrew Lunn <andrew@lunn.ch>,
	Dan Carpenter <dan.carpenter@linaro.org>
Subject: [PATCH hotfix 6.11 v2 0/3] minmax: reduce egregious min/max macro expansion
Date: Wed, 11 Sep 2024 18:51:08 +0100	[thread overview]
Message-ID: <cover.1726074904.git.lorenzo.stoakes@oracle.com> (raw)

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") [0].

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.

Note that we use clamp_t() rather than clamp() when we otherwise could use
the latter because it isn't certain than the clamp() won't expand into a
more egregiously huge form, certainly prior to the recent fixes.

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 series
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/

v2:
* Split into separate patches to make backporting easier.
* Corrected type in sDIGIT_FITTING() argument.
* Added reviewed-by tags.

v1:
https://lore.kernel.org/all/20240911153457.1005227-1-lorenzo.stoakes@oracle.com/

Lorenzo Stoakes (3):
  minmax: reduce min/max macro expansion in mvpp2 driver
  minmax: reduce min/max macro expansion in skbuff
  minmax: reduce min/max macro expansion in atomisp driver

 drivers/net/ethernet/marvell/mvpp2/mvpp2.h    |  2 +-
 .../staging/media/atomisp/pci/sh_css_frac.h   | 26 ++++++++++++++-----
 include/linux/skbuff.h                        |  6 ++++-
 3 files changed, 25 insertions(+), 9 deletions(-)

--
2.46.0

             reply	other threads:[~2024-09-11 17:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-11 17:51 Lorenzo Stoakes [this message]
2024-09-11 17:51 ` [PATCH hotfix 6.11 v2 1/3] minmax: reduce min/max macro expansion in mvpp2 driver Lorenzo Stoakes
2024-09-11 17:51 ` [PATCH hotfix 6.11 v2 2/3] minmax: reduce min/max macro expansion in skbuff Lorenzo Stoakes
2024-09-11 17:52   ` kernel test robot
2024-09-11 17:51 ` [PATCH hotfix 6.11 v2 3/3] minmax: reduce min/max macro expansion in atomisp driver Lorenzo Stoakes
2024-09-11 18:03   ` Hans de Goede
2024-09-11 18:11   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1726074904.git.lorenzo.stoakes@oracle.com \
    --to=lorenzo.stoakes@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@lunn.ch \
    --cc=arnd@kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux@armlinux.org.uk \
    --cc=marcin.s.wojtas@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richard@aaazen.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=torvalds@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.