linux-kernel - Re: [PATCH v2 07/13] xfs: Introduce FORCEALIGN inode flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f402a11-7dd2-4da8-9e1c-ea8a4e3ab33d@oracle.com>
Date: Wed, 24 Jul 2024 19:50:11 +0100
From: John Garry <john.g.garry@...cle.com>
To: "Darrick J. Wong" <djwong@...nel.org>, Dave Chinner <david@...morbit.com>
Cc: chandan.babu@...cle.com, dchinner@...hat.com, hch@....de,
        viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
        linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, catherine.hoang@...cle.com,
        martin.petersen@...cle.com
Subject: Re: [PATCH v2 07/13] xfs: Introduce FORCEALIGN inode flag

On 24/07/2024 01:04, Darrick J. Wong wrote:
>> So why not just enable the per-inode flag with RT right from the
>> start given that this functionality is supposed to work and be
>> globally supported by the rtdev right now? It seems like a whole lot
>> less work to just enable it for RT now than it is to disable it...
> What needs to be done to the rt allocator, anyway?
> 
> I think it's mostly turning off the fallback to unaligned allocation,
> just like what was done for the data device allocator, right?  And
> possibly tweaking whatever this does:
> 
> 	/*
> 	 * Only bother calculating a real prod factor if offset & length are
> 	 * perfectly aligned, otherwise it will just get us in trouble.
> 	 */
> 	div_u64_rem(ap->offset, align, &mod);
> 	if (mod || ap->length % align) {
> 		prod = 1;
> 	} else {
> 		prod = xfs_extlen_to_rtxlen(mp, align);
> 		if (prod > 1)
> 			xfs_rtalloc_align_minmax(&raminlen, &ralen, &prod);
> 	}
> 
> 

My initial impression is that calling xfs_bmap_rtalloc() -> 
xfs_rtpick_extent() for XFS_ALLOC_INITIAL_USER_DATA won't always give an 
aligned extent. However the rest of the allocator paths are giving 
extents aligned as requested - that is from limited testing.

And we would need to not take the xfs_bmap_rtalloc() retry fallback for 
-ENOSPC when align > rtextsize, but I have not hit that yet - maybe 
because xfs_trans_reserve() stops us getting to this point due to lack 
of free rtextents.