Received-SPF: pass (google.com: domain of linux-ext4+bounces-2811-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: John Garry <john.g.garry@oracle.com>
To: axboe@kernel.dk, tytso@mit.edu, dchinner@redhat.com,
        viro@zeniv.linux.org.uk, brauner@kernel.org, djwong@kernel.org,
        jack@suse.com, chandan.babu@oracle.com, hch@lst.de
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
        linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
        linux-fsdevel@vger.kernel.org, gfs2@lists.linux.dev,
        linux-xfs@vger.kernel.org, catherine.hoang@oracle.com,
        ritesh.list@gmail.com, mcgrof@kernel.org,
        mikulas@artax.karlin.mff.cuni.cz, agruenba@redhat.com,
        miklos@szeredi.hu, martin.petersen@oracle.com,
        John Garry <john.g.garry@oracle.com>
Subject: [PATCH v4 05/22] xfs: always tail align maxlen allocations
Date: Fri,  7 Jun 2024 14:39:02 +0000
Message-Id: <20240607143919.2622319-6-john.g.garry@oracle.com>
In-Reply-To: <20240607143919.2622319-1-john.g.garry@oracle.com>
References: <20240607143919.2622319-1-john.g.garry@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?sNDl+vPX6XZDTYtv1UWg0CcZu17ngIQ7vlHCDHaKOa16HwGFNVkut5+iArtP?=
 =?us-ascii?Q?ZSvoEYTgzayMWMAt/ONQvX1YKEQi97BlLdlnR7rny8ToDwSqx3RwNCoqbE6i?=
 =?us-ascii?Q?pVvzdWsOpfOyqPYKnEgGihyDgcje2BZjgozB53oj8iQH9derg3ySxI+IhXdc?=
 =?us-ascii?Q?HHW5TaLWzsONwQvC2xrDxsj7ezx2gJJTN4HRNfYRLcy7lB3BVMjRSD7Djyjm?=
 =?us-ascii?Q?T17As/VLBGHI9ogLabZRIuBopaS2qi6QR7U3KCe2x5lgcAJMPdfgrabs9rFE?=
 =?us-ascii?Q?jrManRHIFKoHdrpeas1LcJGs6tA6+EfrjhS3sUm/2dohYgNoiMzXURht8aMw?=
 =?us-ascii?Q?7wTb5TYeJie5Jr5Fqxqxy80/qDze2cFFYoYllyV/RLWV15dfSiTGooHrNMX3?=
 =?us-ascii?Q?GA7fKcsdhBsCc8XE9UOGZe7gcD1SGXbbGnMX1BDUATNY2Mb2r0Wvbc/fOJv1?=
 =?us-ascii?Q?8EZCj+QUG5h3rVTHKsonyqoHaEATuMYh45ulKOcAKLhazvFN7MhRy4nOjFlJ?=
 =?us-ascii?Q?JxKwb/NLaKNHEh4JIxhUdhWKak5w9au/AzGbo3yZyLoWFn50YEgyPq8+gyfi?=
 =?us-ascii?Q?pLaMjJ90H0rdhIrd7KZxqtQUaKPBUkQqcTFoB2C1tL9yNZWxhfoAAPWMK2sp?=
 =?us-ascii?Q?yy/UgHuNrxKQk9f9tZcYBbfdWDJv9Zh+JuE6S/AFRXcxomhaiFgH4LpB5hpR?=
 =?us-ascii?Q?wS1YWqMqr3iPy30TYZ955kcCj3f27ldNQ50CxG7ozkH5nbYypVyHfR/cyvr3?=
 =?us-ascii?Q?F858K5FveRGaTlkK3LXokLBrGGm8GjB+1KMPmrNl8ZWeqNcl617R/9sazsqv?=
 =?us-ascii?Q?R5Jn8BgdRDf9tzgus675lkjSILGIcrErJdWZiCr/S+tqA2ENtMbNfUOxMoGj?=
 =?us-ascii?Q?16neEOGcc/8xATxDeeXuKBcflCCIa3FffkOXtazgLfnpZ7S5tIwOk8xMtPoP?=
 =?us-ascii?Q?opbBmXEFfLK4RgRW2xWIg/pTbQ35C2nPpS/bYbfcQYqBOPX2IBmPP0fBP3Mb?=
 =?us-ascii?Q?+7JlzMYooXTtEecl0uy36ioUXEpjD6Igz1wcEr0trP++Jc8QYtdXVxw1A4BF?=
 =?us-ascii?Q?0wNUCkCrN091Kp54ZiM/kKxbw9OEIigBOg9UN36v1es1+e3A+vsCyb/wwlRB?=
 =?us-ascii?Q?VKYKouK8Ui82wRcPhuAMI2BIPsaue7xReaBCNbt/LOoyuxEoDZfSGFifGMYy?=
 =?us-ascii?Q?AQE89dLrCZeEoLv/ZbzoWdonzpKqNQfMQRoLRNDBgJA+vrE2dmHLaeXcA9eF?=
 =?us-ascii?Q?M2WcR7GC8l4xkbM5U8KNVNfk3Yb/jSy16PDPWjK3KbgellWDubpXO7qgahPE?=
 =?us-ascii?Q?53WGfyCrZp5t3yEishZKP9H8OpPuDGSnjbFOsoYoS6LEQTMgXwiynZSLzN7f?=
 =?us-ascii?Q?MoXqcpxDOpSyblTINM9PAc1oOWyyU7i4Kd9urs3TGZOVp53Kubhm9PfVR/OQ?=
 =?us-ascii?Q?g8j3J6tf5HhhPVKMTgtcAhVvOAejJWvn8+dX7Pba/1hjgWo60bIsvtPZW5my?=
 =?us-ascii?Q?q1JBXEDa4EYbraaR3zO9WeCskWS/6UFzoeXUJ4/nidj8V6Lul2LumaSEphMN?=
 =?us-ascii?Q?eC0MT4+fWQjMFaaQdxsvDDaJ1Mc+I8iNZ/Vn9SO3Vq+R/Yh7IPJ57dFBShW9?=
 =?us-ascii?Q?Qw=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	eeSb/VQ0AtPZ+sxlSepiz17Cqv0LePUbY4PklVByiWoFnq/y9IrMnCfA4Ue96rhsEQe1B/Wf4fuPvl2cpsgBwfRUri/Pxctz4HfLA4jgvhfy/dxtZ2wp3N+UJz8NJMtdDwIFRcG99XVFADBOlEx+aglR8vg5MCnwdtm3MVd88PGUeuSC8aoJmu5klnFEjeVSE3VM6j63KLA3dc5zo9haTvIOjIc08ZKbgCjiIXC/AsNnS45gcYcN4p7Mic5vUakvsDXuSD78b4qzQyeypBdMQYYicui/LM2Lw+GjkxPadDXdLlTwAfFPIHZnCNk4C2fZMlBfWJoTKjzdgj771r+gJA9essJ7snua6+/WAhmKClxPTAAEGWxo8nH5l7PPQ/8LhKhZnVjGwHyLdFUGZlCxp0S0sbrFv1GicWh/gNPi0tmNcty08h6hodnq5KqHToi9xc+cdLK5VvtuBjfZUc76dezNlmta2gJSSfEEtkCE1s4XMUC0BQvmTqHFxO66ci1NIgPKb3pEUQh87nF3jb4G5GRRLZ0lf5zsiBD7cb+Vkj68c6XRsYwmjHMhBZzP6uciD9lcZ8tRx9inO4k7PzQ2F9dfm0qB3Gi98ZXe3FShTB0=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e267ef2-d4ec-4599-bf87-08dc86ffb916
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4313.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2024 14:40:06.1373
 (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: VeMTpAjaKD6Boe7Nf8WDRrfHWkmCb6DUdxXRbq1TyhjRSoWTK8WupikBwsbZIBd6AE78ilRDtlqA3BXPm+35sg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4226
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-07_08,2024-06-06_02,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 spamscore=0
 adultscore=0 suspectscore=0 malwarescore=0 mlxscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000
 definitions=main-2406070108
X-Proofpoint-GUID: ov_tdcW2raaN95C4BzHe_pJUsBASs6T5
X-Proofpoint-ORIG-GUID: ov_tdcW2raaN95C4BzHe_pJUsBASs6T5

From: Dave Chinner <dchinner@redhat.com>

When we do a large allocation, the core free space allocation code
assumes that args->maxlen is aligned to args->prod/args->mod. hence
if we get a maximum sized extent allocated, it does not do tail
alignment of the extent.

However, this assumes that nothing modifies args->maxlen between the
original allocation context setup and trimming the selected free
space extent to size. This assumption has recently been found to be
invalid - xfs_alloc_space_available() modifies args->maxlen in low
space situations - and there may be more situations we haven't yet
found like this.

Force aligned allocation introduces the requirement that extents are
correctly tail aligned, resulting in this occasional latent
alignment failure to e reclassified from an unimportant curiousity
to a must-fix bug.

Removing the assumption about args->maxlen allocations always being
tail aligned is trivial, and should not impact anything because
args->maxlen for inodes with extent size hints configured are
already aligned. Hence all this change does it avoid weird corner
cases that would have resulted in unaligned extent sizes by always
trimming the extent down to an aligned size.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 fs/xfs/libxfs/xfs_alloc.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
index 5855a21d4864..32f72217c126 100644
--- a/fs/xfs/libxfs/xfs_alloc.c
+++ b/fs/xfs/libxfs/xfs_alloc.c
@@ -432,20 +432,18 @@ xfs_alloc_compute_diff(
  * Fix up the length, based on mod and prod.
  * len should be k * prod + mod for some k.
  * If len is too small it is returned unchanged.
- * If len hits maxlen it is left alone.
  */
-STATIC void
+static void
 xfs_alloc_fix_len(
-	xfs_alloc_arg_t	*args)		/* allocation argument structure */
+	struct xfs_alloc_arg	*args)
 {
-	xfs_extlen_t	k;
-	xfs_extlen_t	rlen;
+	xfs_extlen_t		k;
+	xfs_extlen_t		rlen = args->len;
 
 	ASSERT(args->mod < args->prod);
-	rlen = args->len;
 	ASSERT(rlen >= args->minlen);
 	ASSERT(rlen <= args->maxlen);
-	if (args->prod <= 1 || rlen < args->mod || rlen == args->maxlen ||
+	if (args->prod <= 1 || rlen < args->mod ||
 	    (args->mod == 0 && rlen < args->prod))
 		return;
 	k = rlen % args->prod;
-- 
2.31.1