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: <20200226172653.GW10728@quack2.suse.cz>
Date:   Wed, 26 Feb 2020 18:26:53 +0100
From:   Jan Kara <jack@...e.cz>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Ritesh Harjani <riteshh@...ux.ibm.com>, jack@...e.cz,
        tytso@....edu, linux-ext4@...r.kernel.org,
        adilger.kernel@...ger.ca, linux-fsdevel@...r.kernel.org,
        hch@...radead.org, cmaiolino@...hat.com
Subject: Re: [PATCHv3 6/6] Documentation: Correct the description of
 FIEMAP_EXTENT_LAST

On Wed 26-02-20 08:17:42, Darrick J. Wong wrote:
> On Wed, Feb 26, 2020 at 05:05:03AM -0800, Matthew Wilcox wrote:
> > On Wed, Feb 26, 2020 at 03:27:08PM +0530, Ritesh Harjani wrote:
> > > Currently FIEMAP_EXTENT_LAST is not working consistently across
> > > different filesystem's fiemap implementations and thus this feature
> > > may be broken. So fix the documentation about this flag to meet the
> > > right expectations.
> > 
> > Are you saying filesystems have both false positives and false negatives?
> > I can understand how a filesystem might fail to set FIEMAP_EXTENT_LAST,
> > but not how a filesystem might set it when there's actually another
> > extent beyond this one.
> > 
> > >  * FIEMAP_EXTENT_LAST
> > > -This is the last extent in the file. A mapping attempt past this
> > > -extent will return nothing.
> > > +This is generally the last extent in the file. A mapping attempt past this
> > > +extent may return nothing. But the user must still confirm by trying to map
> > > +past this extent, since different filesystems implement this differently.
> 
> "This flag means nothing and can be set arbitrarily by the fs for the lulz."
> 
> Yuck.  I was really hoping for "This is set on the last extent record in
> the dataset generated by the query parameters", particularly becaue
> that's how e2fsprogs utilties interpret that flag.

The problem is that in some cases, we cannot determine whether the flag
should be set without doing work equivalent to another fiemap call. And it
just seems pointless to try to provide the flag in those cases.

But I agree with Matthew that seeing the flag without the extent really
being the last one shouldn't happen (unless someone is changing the file).

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ