[RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE

From: Ralf Lici

Date: Mon Mar 16 2026 - 04:37:48 EST


Hi,

while looking at .clang-format output in the kernel tree, I ran into a
recurring case where long function calls are reformatted by breaking
immediately after the opening parenthesis of the call.

A representative example is this:

Original code:
int __skb_unclone_keeptruesize(struct sk_buff *skb, gfp_t pri)
{
...
if (...) {
pr_err_once("__skb_unclone_keeptruesize() skb_end_offset() %u -> %u\n",
saved_end_offset, skb_end_offset(skb));
}
...
}

Formatted with the current kernel .clang-format:
int __skb_unclone_keeptruesize(struct sk_buff *skb, gfp_t pri)
{
...
if (...) {
pr_err_once(
"__skb_unclone_keeptruesize() skb_end_offset() %u -> %u\n",
saved_end_offset, skb_end_offset(skb));
...
}

The reformatted version looks less desirable for this kind of kernel
call site, and it conflicts with checkpatch's OPEN_ENDED_LINE check for
for added lines ending in '[' or '('.

I tried to understand whether this could be improved while staying
within the current .clang-format baseline. The closest existing knob
seems to be PenaltyBreakBeforeFirstCallParameter, but in my testing it
does not appear to provide a clean or convincing solution: the value
needed to preserve the original layout in the example above is very
high, which makes it look more like a blunt global workaround than a
principled fix.

The more promising option seems to be PenaltyBreakOpenParenthesis, which
is a much more direct control for this behavior. However, that option is
only available in newer clang-format versions (starting from v14), so
using it would mean revisiting the current version expectations for the
in-tree .clang-format, which is clang-format 11 or newer.

Therefore I wanted to ask whether maintainers think this class of
formatting is worth addressing at all, and if so, whether there is any
openness to adjusting the existing cost model while keeping the current
clang-format compatibility expectations, or revisiting the minimum
supported clang-format version for .clang-format so that more specific
options can be used.

Thanks,

--
Ralf Lici
Mandelbit Srl