From: 1425075683@qq.com
To: robin.murphy@arm.com
Cc: 1425075683@qq.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org,
saravanak@google.com
Subject: Re: [PATCH] of: Build warn for missing fn() in _OF_DECLARE
Date: Wed, 23 Apr 2025 22:48:35 +0800 [thread overview]
Message-ID: <tencent_B16F0FDE60249B5B302F900AE6EEE48C4F06@qq.com> (raw)
In-Reply-To: <a4277fb4-c982-43c7-9f02-e0050eff417a@arm.com>
>On 2025-04-17 2:23 pm, Liya Huang wrote:
>> The function pointer fn() in _OF_DECLARE macro might be NULL. For example,
>> in __reserved_mem_init_node(), only non-NULL cases are handled, and NULL
>> function pointers are ignored.
>>
>> This patch introduces a check to handle cases where fn() is NULL. If fn()
>> is found to be NULL, a warning is issued during compilation to notify
>> developers about the missing function pointer.
>>
>> ---
>> The function pointer fn() in _OF_DECLARE macro might be NULL. For example,
>> in __reserved_mem_init_node(), only non-NULL cases are handled, and NULL
>> function pointers are ignored.
>>
>> This patch introduces a check to handle cases where fn() is NULL. If fn()
>> is found to be NULL, a warning is issued during compilation to notify
>> developers about the missing function pointer.
>
>This patch in -next appears to be responsible for syzbot complaining
>about build errors for some configs:
>
>"
>kernel/dma/coherent.c:410:1: error: static assertion expression is not
>an integral constant expression
>kernel/dma/contiguous.c:497:1: error: static assertion expression is not
>an integral constant expression
>"
>
>https://lore.kernel.org/linux-iommu/6808d00a.050a0220.7184a.0010.GAE@google.com/
>
>Also on closer inspection, just outside the diff context we still seem
>to be explicitly anticipating fn being NULL with:
>
> .data = (fn == (fn_type)NULL) ? fn : fn
>
>so something doesn't seem quite right...
>
>Thanks,
>Robin.
I tested this patch, and it compiled successfully with GCC but failed with
Clang.I couldn't find a better way to consistently check for null function
pointers during compilation across these two compilers.
I even tried using the method of preventing negative array indexing, but
it failed to compile with GCC instead.
Perhaps it would be better to abandon this patch. :(
--
Thanks,
Liya Huang <1425075683@qq.com>
next prev parent reply other threads:[~2025-04-23 15:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 13:23 Liya Huang
2025-04-22 12:48 ` Rob Herring (Arm)
2025-04-23 12:18 ` Robin Murphy
2025-04-23 14:48 ` 1425075683 [this message]
2025-04-23 22:10 ` Rob Herring
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=tencent_B16F0FDE60249B5B302F900AE6EEE48C4F06@qq.com \
--to=1425075683@qq.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®