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] [day] [month] [year] [list]
Date: Tue, 2 Jul 2024 00:34:03 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Zhang Yi <yi.zhang@...weicloud.com>, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	djwong@...nel.org, hch@...radead.org, brauner@...nel.org,
	chandanbabu@...nel.org, John Garry <john.g.garry@...cle.com>,
	jack@...e.cz, yi.zhang@...wei.com, chengzhihao1@...wei.com,
	yukuai3@...wei.com
Subject: Re: [PATCH -next v6 1/2] xfs: reserve blocks for truncating large
 realtime inode

On Mon, Jul 01, 2024 at 10:35:07PM +1000, Dave Chinner wrote:
> Sorry, but I don't really care what either John or Christoph say on
> this matter: xfs_inode_has_bigrtalloc() is recently introduced
> technical debt that should not be propagated further.

So send a patch to fix it.

> xfs_inode_has_bigrtalloc() needs to be replaced completely with
> xfs_inode_alloc_unitsize() and any conditional behaviour needed can
> be based on the return value from xfs_inode_alloc_unitsize(). That
> works for everything that has an allocation block size larger than
> one filesystem block, not just one specific RT case.

Only assuming we actually get these larger alloc sizes.  Which right
now we don't have, and to be honest I'm not sure they are a good
idea.  The whole larger alloc size thing has been a massive pain
to deal with, and we'll need good argument for furthering that pain.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ