From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A286C433F5 for ; Mon, 9 May 2022 09:55:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233567AbiEIJzV (ORCPT ); Mon, 9 May 2022 05:55:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240009AbiEIJsE (ORCPT ); Mon, 9 May 2022 05:48:04 -0400 Received: from smtp-1908.mail.infomaniak.ch (smtp-1908.mail.infomaniak.ch [IPv6:2001:1600:4:17::1908]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93BC725E95 for ; Mon, 9 May 2022 02:44:04 -0700 (PDT) Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Kxbpn59SKzMpyc1; Mon, 9 May 2022 11:44:01 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4Kxbpm2dG6zljsTk; Mon, 9 May 2022 11:44:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1652089441; bh=IFfFmj2+RkCP9G2Z76uXCcYYBbyAciGpIE19FbUTSso=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=IEGm/NO+iC7mfpMeM7kDDqb2BbcLTxaPn10tJd1KkeIhaOhQ0D/esgbepxz2l/IU7 Qdm7dVb4MxbAm+acN9SEZk9SpKbJ6jkOoNO1aUBDiByt5HJPYFyT/zVOG/Jd+wqmnp lvaiGBEJQfL2IJW4dBcw7wm5F1fEKD74qlb7q/QQ= Message-ID: <0be9b4c6-3e32-3d18-1715-aaadd6324701@digikod.net> Date: Mon, 9 May 2022 11:45:44 +0200 MIME-Version: 1.0 User-Agent: Content-Language: en-US To: Miguel Ojeda Cc: James Morris , "Serge E . Hallyn" , Kees Cook , Konstantin Meskhidze , Miguel Ojeda , Paul Moore , Shuah Khan , Tom Rix , linux-kernel , linux-security-module References: <20220506160513.523257-1-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Subject: Re: [PATCH v1 0/7] Landlock: Clean up coding style with clang-format In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/2022 11:06, Miguel Ojeda wrote: > Hi Mickaël, > > (Answering in v1 since I want to quote something in this cover letter) There is only a v1 for this specific series, but other series (with higher versions) are now relying on this one. ;) > > On Fri, May 6, 2022 at 6:03 PM Mickaël Salaün wrote: >> >> I used a simple coding style for the initial Landlock code. However, >> this may be subject to different interpretations. To avoid relying >> on tacit knowledge or text editors for these kind of rules, let's >> automate it as much as possible thanks to clang-format. This makes the >> code formatting simple, consistent and impersonal. > > Thanks for moving your subsystem to `clang-format`. I am glad you > found it useful. > >> Several versions of clang-format can be use but they may have (small) >> different behaviors for undefined/new configuration parts. After >> testing different versions, I picked clang-format-14 which is relatively >> new and fixes a bug present in version 11 to 13 (visible in the Landlock >> formatted code). > > Which was the bug? You can check it by running clang-format-X on security/landlock/fs.c [1] and you'll get different results for this hunk (only): --- a/security/landlock/fs.c +++ b/security/landlock/fs.c @@ -688,7 +688,7 @@ static inline access_mask_t maybe_remove(const struct dentry *const dentry) if (d_is_negative(dentry)) return 0; return d_is_dir(dentry) ? LANDLOCK_ACCESS_FS_REMOVE_DIR : - LANDLOCK_ACCESS_FS_REMOVE_FILE; + LANDLOCK_ACCESS_FS_REMOVE_FILE; } /** [1] https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/log/?h=landlock-wip