Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Ankur Arora <ankur.a.arora@oracle.com>
To:     linux-audit@redhat.com
Cc:     paul@paul-moore.com, eparis@redhat.com,
        linux-kernel@vger.kernel.org, boris.ostrovsky@oracle.com,
        konrad.wilk@oracle.com
Subject: [PATCH 2/3] audit: annotate branch direction for audit_in_mask()
Date:   Tue, 27 Sep 2022 15:59:43 -0700
Message-Id: <20220927225944.2254360-3-ankur.a.arora@oracle.com>
In-Reply-To: <20220927225944.2254360-1-ankur.a.arora@oracle.com>
References: <20220927225944.2254360-1-ankur.a.arora@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+pwxJfYeIuktDUiNnRn8XaWrSrbsoJ1o7ZDzUg6K/AE+0gtr1UrEq6LqkvOr?=
 =?us-ascii?Q?7VsDltvj1teGLJX+Hn1JvQKfOHpIRbKMTA+qhDYxsc2UCpb8YweUno2TJXwZ?=
 =?us-ascii?Q?aXYSCVmqEUpwhVqU565ZM2ed/EcHXbMdjjWQWakW8WXng6PbiCuUfWLBkoOs?=
 =?us-ascii?Q?b9Z0RIOnm6c+Ft6U2j+hovHIst/MGtYSUjluFWSxEXZhII44XjkhMCuADgHN?=
 =?us-ascii?Q?V/TcRmZ3tpPW2UMD9SXZ0o2lriPGpHb6/Ylu1dwuCumyViAOEn6RuCLFoIIX?=
 =?us-ascii?Q?illMNq8Vl+P2YWpynKiJuRxebxosGyH09D06s+WvwutvA1hNjCA2g9MiJJAP?=
 =?us-ascii?Q?GslBcSLX7ShRpDoHWwLe+vlnlyAezVQN0plh5T6SRq3eys5KSG3G2hXVYQqa?=
 =?us-ascii?Q?6WOrPdElM+GynW1k3jSVC0CYbPREk4riSdkzB/bBWubOIEua+y0D2+mdAvrN?=
 =?us-ascii?Q?0H/nHGbanXt9SjiluLFeb9Yw9McLyE9KR18ZNKstOrVSvcV1QtVFLIOGHQXp?=
 =?us-ascii?Q?2+NiOpd7JkestLlursTnNWap0HO58pdgyre2zEtyNhc+IXLEvH4277qX6w23?=
 =?us-ascii?Q?Q8DTII7j3eBxQCIUytNO1drcjfUCSMI61xbJxvCnRftSXJUR8KMpXkLlKzlb?=
 =?us-ascii?Q?opCki3ANcLe7ycHiPLio48EHcvtyGZr7LqM6GRgRVXI7hHLTMbuRPUIDL5R9?=
 =?us-ascii?Q?UcZB/P58OYtErF46VH7fXyQNTuXYali2JgGAM1nZkHEGWTS0NQQMRDQ2rtSz?=
 =?us-ascii?Q?0QM6O4eulIed+RuL1++XCDeLSxtbgQHPpCtx/IjXbU7l7Sqmc2a+bRtJWd2O?=
 =?us-ascii?Q?Xs1BW9+MWnGubkdaTIMb+0IY2klVUsmLuX86vyjc9InAxT1gYsUVKaCamBWu?=
 =?us-ascii?Q?ko6affOFxqvceaxQgA1+rpTX6qGry/rnL4tHEdBtm5H7hztBvr4SZmo7x3Hb?=
 =?us-ascii?Q?pg6X3g7vfQjfb12XIvYdfx5nut4ltN1nDDW4WUxqtUOKR6DLPiyRfExpn+vw?=
 =?us-ascii?Q?eJnWXlttHDhucs8ZoxU+15aouBY9IZ1wKjgPHgKohYn2BVd/n6z63KkovTO+?=
 =?us-ascii?Q?St9GIwoH2X01tdrfVA3F3vPeEvk9DptWZOEvFWedpYj2JBqX7UiGGg63P1ph?=
 =?us-ascii?Q?ql7rE2ai1T+NbqRRNzeWKLkQCtjx4eJAeaLNHSDnB9u4lTjReYi57aMWJhnx?=
 =?us-ascii?Q?oHz3kGQ2f995Cq0qLUbfhEEK+Eq5Ogn6P6Nfh1rF1AFWGy1OUnRd8Mj/Fw80?=
 =?us-ascii?Q?iIoU2LTZXFT5WnTfnL1nyFiNN2qyzgWREykyQxpda9OPDuH5zsb6/AVHLh6n?=
 =?us-ascii?Q?IRO4RUoA5UGyivlSQDi7Y2Zd1DAhy1Ai3SQz0dL6aWNoYFf+m4NwcDFEsphH?=
 =?us-ascii?Q?1LhXtHXsOIKlRckh8RgTIRnXTT4mw/1qFV0ZTX/lOYUY4ZnB+Lo4aEe23lm4?=
 =?us-ascii?Q?wsUOSLx+QzJ5w3rKT5pyr5leVMRDdaClRG4hyGdHNGDPCegvD3s/qFquFUJj?=
 =?us-ascii?Q?DHyOixkRNw7MHR4uXsRl2y37jFzaEFW1mRe++GothPEU5ER+rCKHpvORIwKD?=
 =?us-ascii?Q?/es/0jM5ERL7ANdazIMy8+MlUcBdLdq8vbqglyHF?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: de9cae4a-dd10-43fe-bd66-08daa0dbfcc4
X-MS-Exchange-CrossTenant-AuthSource: CO6PR10MB5409.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2022 22:59:52.7879
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: d53XzvHardYjhp9KF3G7DW0jaCTQhSpgIbxVRTHgvPENUKzdqCMHiIm9hMjQwoyrxIZhsYWCu315cC9pfyQnvlxnKYZJtxPdvmfKHUV55OU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB6900
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-27_11,2022-09-27_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0
 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2209270141
X-Proofpoint-ORIG-GUID: Z_BTAAb9xJGqByzVkMPpu-hFUF9IQgUx
X-Proofpoint-GUID: Z_BTAAb9xJGqByzVkMPpu-hFUF9IQgUx
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

With sane audit rules, audit logging would only be triggered
infrequently. Keeping this in mind, annotate audit_in_mask() as
unlikely() to allow the compiler to pessimize the call to
audit_filter_rules().

This allows GCC to invert the branch direction for the audit_filter_rules()
basic block in this loop:

 	list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_EXIT], list) {
 		if (audit_in_mask(&e->rule, major) &&
 		    audit_filter_rules(tsk, &e->rule, ctx, NULL,
 				       &state, false)) {
			...

such that it executes the common case in a straight line fashion.

On a Skylakex system change in getpid() latency (all results
aggregated across 12 boot cycles):

         Min     Mean    Median   Max      pstdev
         (ns)    (ns)    (ns)     (ns)

 -    196.63   207.86  206.60  230.98      (+- 3.92%)
 +    173.11   182.51  179.65  202.09      (+- 4.34%)

Performance counter stats for 'bin/getpid' (3 runs) go from:
    cycles               805.58  (  +-  4.11% )
    instructions        1654.11  (  +-   .05% )
    IPC                    2.06  (  +-  3.39% )
    branches             430.02  (  +-   .05% )
    branch-misses          1.55  (  +-  7.09% )
    L1-dcache-loads      440.01  (  +-   .09% )
    L1-dcache-load-misses  9.05  (  +- 74.03% )

 to:
    cycles               706.13  (  +-  4.13% )
    instructions        1654.70  (  +-   .06% )
    IPC                    2.35  (  +-  4.25% )
    branches             430.99  (  +-   .06% )
    branch-misses          0.50  (  +-  2.00% )
    L1-dcache-loads      440.02  (  +-   .07% )
    L1-dcache-load-misses  5.22  (  +- 82.75% )

(Both aggregated over 12 boot cycles.)

cycles: performance improves on average by ~100 cycles/call. IPC
improves commensurately. Two reasons for this improvement:

  * one fewer branch mispred: no obvious reason for this
    branch-miss reduction. There is no significant change in
    basic-block structure (apart from the branch inversion.)

  * the direction of the branch for the call is now inverted, so it
    chooses the not-taken direction more often. The issue-latency
    for not-taken branches is often cheaper.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 kernel/auditsc.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 533b087c3c02..bf26f47b5226 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -789,7 +789,7 @@ static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
 	return AUDIT_STATE_BUILD;
 }
 
-static int audit_in_mask(const struct audit_krule *rule, unsigned long val)
+static bool audit_in_mask(const struct audit_krule *rule, unsigned long val)
 {
 	int word, bit;
 
@@ -850,12 +850,13 @@ static void audit_filter_syscall(struct task_struct *tsk,
 
 	rcu_read_lock();
 	list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_EXIT], list) {
-		if (audit_in_mask(&e->rule, major) &&
-		    audit_filter_rules(tsk, &e->rule, ctx, NULL,
-				       &state, false)) {
-			rcu_read_unlock();
-			ctx->current_state = state;
-			return;
+		if (unlikely(audit_in_mask(&e->rule, major))) {
+			if (audit_filter_rules(tsk, &e->rule, ctx, NULL,
+					       &state, false)) {
+				rcu_read_unlock();
+				ctx->current_state = state;
+				return;
+			}
 		}
 	}
 	rcu_read_unlock();
-- 
2.31.1