From: david laight <david.laight@runbox.com>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] hwmon: (max6620) Add locking to avoid TOCTOU
Date: Fri, 28 Nov 2025 20:06:34 +0000 [thread overview]
Message-ID: <20251128200135.26000eed@pumpkin> (raw)
In-Reply-To: <CALbr=LbzgLK7Y-e3TTpusXGZEq4+DJJ=mbVMP=M3gt6XDGNUGA@mail.gmail.com>
On Sat, 29 Nov 2025 01:59:51 +0800
Gui-Dong Han <hanguidong02@gmail.com> wrote:
...
> In our previous discussion, you also suggested adding a note to
> submitting-patches.rst about "avoiding calculations in macros" to
> explicitly explain the risk of race conditions. Is this something you
> would still like to see added? If so, I would be happy to prepare a
> patch.
The real problem with #defines evaluating their parameters more than
once is just side effects of the expansion.
Even if the current users just pass a simple variable, you never
really know what is going to happen in the future.
There is also a secondary issue of pre-processor output 'bloat'.
This happens when large #define expansions get nested.
With the current headers FIELD_PREP(GENMASK(8, 5), val) expands to
about 18kB [1] (even though it is just (val >> 5) & 15).
I think one of your #defines get passed one of those - and then expands
it several times. As well as the massive line, the compiler may well
generate the code multiple times.
(CSE will normally stop foo->bar[x] being executed multiple times).
[1] Nothing like the 30MB that triple nested min() generated for a while.
David
prev parent reply other threads:[~2025-11-28 20:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 12:43 [PATCH] hwmon: (max6620) Add locking to avoid TOCTOU Gui-Dong Han
2025-11-28 16:34 ` Guenter Roeck
2025-11-28 17:59 ` Gui-Dong Han
2025-11-28 18:09 ` Guenter Roeck
2025-11-28 20:06 ` david laight [this message]
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=20251128200135.26000eed@pumpkin \
--to=david.laight@runbox.com \
--cc=hanguidong02@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=stable@vger.kernel.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.