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: <6427a661-2e92-49a0-8329-7f67e8dd5c35@oracle.com>
Date: Mon, 8 Jul 2024 08:36:52 +0100
From: John Garry <john.g.garry@...cle.com>
To: Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@....de>,
        djwong@...nel.org
Cc: chandan.babu@...cle.com, dchinner@...hat.com, 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 08/13] xfs: Do not free EOF blocks for forcealign

On 08/07/2024 02:44, Dave Chinner wrote:
> On Sat, Jul 06, 2024 at 09:56:09AM +0200, Christoph Hellwig wrote:
>> On Fri, Jul 05, 2024 at 04:24:45PM +0000, John Garry wrote:
>>> -	if (xfs_inode_has_bigrtalloc(ip))
>>> +
>>> +	/* Only try to free beyond the allocation unit that crosses EOF */
>>> +	if (xfs_inode_has_forcealign(ip))
>>> +		end_fsb = roundup_64(end_fsb, ip->i_extsize);
>>> +	else if (xfs_inode_has_bigrtalloc(ip))
>>>   		end_fsb = xfs_rtb_roundup_rtx(mp, end_fsb);
>>
>> Shouldn't we have a common helper to align things the right way?
> 
> Yes, that's what I keep saying. 

Such a change was introduced in 
https://lore.kernel.org/linux-xfs/20240501235310.GP360919@frogsfrogsfrogs/

and, as you can see, Darrick was less than happy with it. That is why I 
kept this method which removed recently added RT code.

Darrick, can we find a better method to factor this code out, like below?

> The common way to do this is:
> 
> 	align = xfs_inode_alloc_unitsize(ip);
> 	if (align > mp->m_blocksize)
> 		end_fsb = roundup_64(end_fsb, align);
> 
> Wrapping that into a helper might be appropriate, though we'd need
> wrappers for aligning both the start (down) and end (up).
> 
> To make this work, the xfs_inode_alloc_unitsize() code needs to grow
> a forcealign check. That overrides the RT rextsize value (force
> align on RT should work the same as it does on data devs) and needs
> to look like this:
> 
> 	unsigned int		blocks = 1;
> 
> +	if (xfs_inode_has_forcealign(ip)
> +		blocks = ip->i_extsize;
> -	if (XFS_IS_REALTIME_INODE(ip))
> +	else if (XFS_IS_REALTIME_INODE(ip))
>                  blocks = ip->i_mount->m_sb.sb_rextsize;

That's in 09/13

> 
>          return XFS_FSB_TO_B(ip->i_mount, blocks);
> 
>> But more importantly shouldn't this also cover hole punching if we
>> really want force aligned boundaries?

so doesn't the xfs_file_fallocate(PUNCH_HOLES) -> 
xfs_flush_unmap_range() -> rounding with xfs_inode_alloc_unitsize() do 
the required job?

> 
> Yes, that's what I keep saying. There is no difference in the
> alignment behaviour needed for "xfs_inode_has_bigrtalloc" and
> "xfs_inode_has_forcealign" except for the source of the allocation
> alignment value.
> 




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ