From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [195.10.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 304FA378D9B for ; Mon, 16 Mar 2026 08:34:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.10.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773650069; cv=none; b=AfVYwf1HaZH6YihSQC57waTe2JTtq7s/tYexANR/L085uLLrv5b3/IAARYgo/c7Suss6FmL0iCU1qBlPMqfma102dAkaFeVq4WzYImsTqMvlrUG3tL0TIcYzPy7cveVw2SMJtP9f1PK9669+kjG8t6wBtrDSl7Vp4P1YN21mbB0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773650069; c=relaxed/simple; bh=Soi/V+09RjtHoFXKoGWkOcNQdO9NI+WsJ0CukIORpJc=; h=Message-ID:Date:MIME-Version:To:From:Subject:Cc:Content-Type; b=IUWj66UDD7O5OY/5+A2c/AQve/9edpxhype56mt9Wkvw/+RE8hez7Q8e3t9j8jaCjjIPK9NobFd1Zk0SvRfW/mWRIkbMjQlgzg2bgxBIREv6JAxqT44SWZHZ5FGJt7A/OpWxOnWfaLQJQfH9FWF2y7ravi5A5McKpwI3t/haZSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mandelbit.com; spf=pass smtp.mailfrom=mandelbit.com; dkim=pass (2048-bit key) header.d=mandelbit.com header.i=@mandelbit.com header.b=xSrmb4yj; arc=none smtp.client-ip=195.10.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mandelbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mandelbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mandelbit.com header.i=@mandelbit.com header.b="xSrmb4yj" Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-112.mailbox.org (Postfix) with ESMTPS id 4fZ7Y16ZtpzDv6q; Mon, 16 Mar 2026 09:29:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandelbit.com; s=MBO0001; t=1773649750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=56cEiUVQudPZGQM4C6TG89ilgIXAL7hRSwoaU9wQeKQ=; b=xSrmb4yjBKQ4N21jUapcWiivQ98TvhPY+aExeNFagCzCj1IAYJUl+9V0CCQ4srcjVqY+xO cojR6wJgj/PYxjbQvQ/vPgmgysA0YF/UHr2+BhryCLvtixP0HPyvKlMbpv9R2LX4S168RJ xb6mQHIahSQXo0B2XCZaGJU1/E21FYlk3fGC/ceWmFDmsORof+4G4oAHtiMcWRLKKhtxaH 2got2wsvKSbu7pvDzZ9CsMxAno2W7rT3EB0WXj2XQ8Xl5gbUs8FhhZ0X8O4oNpQRzsDdg1 Dl/Lrub/vI5+Qt5ZpZ78OdZ9GlNnzYsSg9cGQfgvz3+m9LbeplNPs0zcg8cXIQ== Message-ID: Date: Mon, 16 Mar 2026 09:29:06 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Language: en-US To: ojeda@kernel.org From: Ralf Lici Subject: [RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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