From nobody Sun Feb 8 07:21:56 2026 Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3AF332AAC1 for ; Wed, 7 Jan 2026 14:06:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767794818; cv=none; b=l7pzbAGfu7YfzCZx9Q/UOs1isNt6zA/IGn4m6ZAi4O7sg+ivHYrHT6BVAwnAHkzdNReIKjDbU297+tQws0XfDftagBE/TpKHcGSLiGMiL0R5QFeBqOhg81rw5gB3tTEn7JLQ73RR/YVcOy9Sy3x4MHQS9Oo+C9uUTkZk7gIW5B4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767794818; c=relaxed/simple; bh=Q03oAK7dYPK8RIOcWB5kLJfIjm+pK92q86ShqiLQj4c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=dbS2k1NSA1tmgborVlDVPCK5zOewA002jEcvUu/Niy4GkCp8xgzmvJghZc2xfgh3720OOIfr/yAUbVIGLwCL6f8kpTdctfGxhAt5E6p0Sh6NC249toMxEvJr79NxMAkMvwTDYHYTewpzNAf0idFRcUDjDf2uhmia8VAumLcuY0E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.160.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-3f11ad6e76fso1699313fac.1 for ; Wed, 07 Jan 2026 06:06:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767794814; x=1768399614; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Kq0N2ZYr66guWKudTrbZSgeGohHNa2AeqLyUsW/1UrU=; b=vkyLNyL93YR6mrxV5SNQkUqc5IEDW5cA14DdmOGmjw/Mfxzmeoma7EEb0G7yRnaTbk eFhzDqjooiKfdem655HLWVdnBV77cOBccDFbj3AqYzKbH6BCHyjpXJltK76heu3XFkBs LDyg/CU01qlKKPSJM1Imf+T5AGfyDOurOPqXRJb+YQiAYEZIliBPPlrll50xtRGSv+IK AHDrTu6uTcAjSvwhgPw4BCmHPutzonOBFuIBFcK1eQeujAztfSlwkk9YiCzck3l57ubQ ABqRa4FTAFhPs7+Do3p90+vRRTSGtjz0+4NQlogH4s6xucHSFiEzNty6GkNJSQc+NBb3 +cmQ== X-Gm-Message-State: AOJu0YztysACBT28miJRWC41S3f1eIRmippA1+sXnPjO1VSvIm5zW+aZ uuu1Q5jQ8FRWkQz44bONImkNZDPa7bTyw/sKiAFjR46Shut4CZnGmEC5 X-Gm-Gg: AY/fxX58CDkFTb9zszpvnYkHPXXW/kdbaRhLK22cR2nPi+1CBmN6DLpSjIi3cSqEcQJ CNVVbaPzuwdum7ynB8JdM7KhEP7L+GgsgNDB3LTzYeVikJ5JYKMZ1pKTiYm/MRELeWok/vOuRHJ D5KQEZnlIXSWF4iQRFl2eXaNUNaxMUNdYanQbdBaVCZ9XeGXTNFdJdmcJqbz1ciJ1+a3rmq1kvs 2f1mEeqegm9DOOc9QhLmptRrl/mjvjqeVklbBbAaZ7z0cTGIpVZF5aUI6yKfmXuUYMsaK1QaWVh h5W8WejA4yr6VldnhOfLqOA96ldlJJnVZ09HFOLsE3RxShVc4iwV8+JUDHdC/HUHUxC1tontxxm QpFAlDhWOvBlduFFU/Iw1Br0aBqyb4i2WsGjZ7zGEFAwbGFU7LHT9XSxqdjfX0A+qwsxvsTB1kj dQqJsLmdLHIP0i X-Google-Smtp-Source: AGHT+IHWGit+F298nFpjyBlCkq0pRLQwpp0ohTaIDars4OMRdvHaA+CCb22mjSzxxuDVBjhmE2h0kA== X-Received: by 2002:a05:6871:114:b0:3f5:aec3:88dd with SMTP id 586e51a60fabf-3ffc0b72aaemr1337331fac.44.1767794813851; Wed, 07 Jan 2026 06:06:53 -0800 (PST) Received: from localhost ([2a03:2880:10ff:5::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-3ffa516150fsm3199934fac.20.2026.01.07.06.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 06:06:53 -0800 (PST) From: Breno Leitao Date: Wed, 07 Jan 2026 06:06:36 -0800 Subject: [PATCH] device_cgroup: remove branch hint after code refactor Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260107-likely_device-v1-1-0c55f83a7e47@debian.org> X-B4-Tracking: v=1; b=H4sIAGtoXmkC/yXMywrCMBAF0F8Z7rqB6YAP8isiUpOrjpYqSS1K6 b+LujybM6OyOCuizCicvPp9QJS2EaRLN5wZPCMKTG2trW5C7zf270Pm5InBNHfcWl6pZTSCR+H JX79vt/+7Po9XpvGbYFk+DJ5fsHEAAAA= X-Change-ID: 20260107-likely_device-20dae82d502d To: Mateusz Guzik , Christian Brauner Cc: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, rostedt@goodmis.org, linux-fsdevel@vger.kernel.org, kernel-team@meta.com, Breno Leitao X-Mailer: b4 0.15-dev-47773 X-Developer-Signature: v=1; a=openpgp-sha256; l=2052; i=leitao@debian.org; h=from:subject:message-id; bh=Q03oAK7dYPK8RIOcWB5kLJfIjm+pK92q86ShqiLQj4c=; b=owEBbQKS/ZANAwAIATWjk5/8eHdtAcsmYgBpXmh82Ir1CWimsBijOp4n6TRb8hZZRduh3mYui 2Z6wlkI/2KJAjMEAAEIAB0WIQSshTmm6PRnAspKQ5s1o5Of/Hh3bQUCaV5ofAAKCRA1o5Of/Hh3 bYCVD/94MQ/N702Z6ptR0kfQCM2Med8nwkztcIl3lX4VVDLsn+f5A+kJgIL/deEDtIeHpT8lPsF yztsQC0igyy966fS+V6rfqEMEaOPmpm1QmbdZ0m7rjeeHT2FON81v3LX2WrCKeYk7B+R89/p8t0 EAhFSRjsgZvvnks37YuFI0K1oC0rutHcQSTPHiIJU7xxOGQCi0Dwg4ZDPN2Ly3YVN6rTVd/qgwz 6CaOU/Riyh3Bms/KY/1rPPbDIctF3Rpu1zcnDWMxPbiUtMBRaYm7OPgUoDkUOAGuUSf+X0qyH3C XSd2B9ORXQfjF6EhR+tTFGqyrAYzmzqTLW/++hxd0oFUZtb0O68GB1v6UR01kIB8Ui2wBW/tYwO yOCu0TlIeQEKcyOb34C1nz9JuFfEtoTXCPLHFjSRL3OByu3Eh+xbsQrcf+WFXG5jox0yRpJpo+B O7Tt9DHS3NrlWTIk+pb6UfkipCbNc+JUI0rPEfZtVu9yT1llDHFAsRLRm1XGSPqP9mvD20ORN2s 3JWQPNQZSkCVG4u16/1fgCrEFz3wOgZ3cBc3Cpb6eeXWwKr2JM/OcFQIPqBnQ37Ky+auu2hdiY/ Ptsk2aaXP4MVSMMNU8C10BKe5N5/DAn0szweI3FgkPOZDvUK5IhjwmaW4Wvn6P6ENfcMjmEDxBm JgU/9+bhMpT/Xdg== X-Developer-Key: i=leitao@debian.org; a=openpgp; fpr=AC8539A6E8F46702CA4A439B35A3939FFC78776D commit 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") reordered the checks in devcgroup_inode_permission() to check the inode mode before checking i_rdev, for better cache behavior. However, the likely() annotation on the i_rdev check was not updated to reflect the new code flow. Originally, when i_rdev was checked first, likely(!inode->i_rdev) made sense because most inodes were(?) regular files/directories, thus i_rdev =3D=3D 0. After the reorder, by the time we reach the i_rdev check, we have already confirmed the inode IS a block or character device. Block and character special files are precisely defined by having a device number (i_rdev), so !inode->i_rdev is now the rare edge case, not the common case. Branch profiling confirmed this is 100% mispredicted: correct incorrect % Function File L= ine ------- --------- - -------- ---- -= --- 0 2631904 100 devcgroup_inode_permission device_cgroup.h 24 Remove likely() to avoid giving the wrong hint to the CPU. Fixes: 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common= case in devcgroup_inode_permission()") Signed-off-by: Breno Leitao Reviewed-by: Mateusz Guzik --- include/linux/device_cgroup.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h index 0864773a57e8..822085bc2d20 100644 --- a/include/linux/device_cgroup.h +++ b/include/linux/device_cgroup.h @@ -21,7 +21,7 @@ static inline int devcgroup_inode_permission(struct inode= *inode, int mask) if (likely(!S_ISBLK(inode->i_mode) && !S_ISCHR(inode->i_mode))) return 0; =20 - if (likely(!inode->i_rdev)) + if (!inode->i_rdev) return 0; =20 if (S_ISBLK(inode->i_mode)) --- base-commit: f0b9d8eb98dfee8d00419aa07543bdc2c1a44fb1 change-id: 20260107-likely_device-20dae82d502d Best regards, -- =20 Breno Leitao