linux-kernel - Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE

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:   Fri, 15 Jun 2018 11:33:14 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Sig Shen <sigshen@...ology.com>
Cc:     Philippe Ombredanne <pombredanne@...b.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate

On Fri, Jun 15, 2018 at 06:51:08PM +0800, Sig Shen wrote:
> FALLOC_FL_NO_HIDE_STALE flag must be set if user want to issue
> a discard request for block devices. But vfs_fallocate() will
> return with an error -EOPNOTSUPP indicating lack of support
> if this flag is set.
> 
> fix it by allowing FALLOC_FL_NO_HIDE_STALE flag in vfs_fallocate
> 
> Fixes: 25f4c41415e5 ("block: implement (some of) fallocate for block devices")
> Signed-off-by: Sig Shen <sigshen@...ology.com>

The commit description is not quite correct.  What the NO_HIDE_STALE
flag does is allow a discard request for those block devices which do
not have the DISCARD_ZEROES_DATA flag.

I will note that the FALLOC_FL_NO_HIDE_STALE flag is a bit
controversial in linux-fsdevel.  I have a similar patch in the VFS in
Google's internal data center kernel, as well as an internal patch
which implements support for this flag in ext4.  However, the patches
are out of tree, because pretty much all of the file system developers
who work for enterpise distributions were against this functionality.

I know of one other major cloud provider (in China) using the
functionality as an out-of-tree patch, but with no one else speaking
in favor of it, and everyone else NAK'ing the patch and enterprise
distro's saying they would revert the patch in their distro kernels,
the compromise we came to was that the code point for NO_HIDE_STALE_FL
would be reserved so that users of the out-of-tree patches wouldn't
collide with future fallocate flags; and I would stop trying to push
the patches upstream.

I have no idea how Darrick was able to get commit 25f4c41415e5
upstream, but I guess it was less controversial for block devices than
for file systems.

So I'm certainly in favor of this patch landing in mainline, but you
should be aware that there may be some opposition to it.

Cheers,

					- Ted