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]
Message-ID: <58418b66-8dd1-41ca-90d6-f1dc3176c9be@gmail.com>
Date: Thu, 8 Feb 2024 17:31:00 -0800
From: Daniel Dawson <danielcdawson@...il.com>
To: Luis Henriques <lhenriques@...e.de>, "Theodore Y. Ts'o" <tytso@....edu>,
 Andreas Dilger <adilger.kernel@...ger.ca>
Cc: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ext4: destroy inline data immediately when converting
 to extent

On 2/8/24 8:58 AM, Luis Henriques wrote:
> The 'lsattr' command shows that the file has data stored inline.  However,
> that is not correct because writing 192 bytes (3 * 64) has forced the data
> to be un-inlined.  Doing a 'sync' before running the 'lsattr' fixes it.
I know I'm the one who initially reported this, but I suppose there is 
an argument to be made that this in itself is not a bug, as Ted seemed 
to say before. What is a problem, however, is lseek() giving ENOENT when 
the kernel finds file data where it expects to find a block/extent map, 
and I can confirm this patch solves that (tested against 6.8.0-rc3). Not 
sure if it's the best thing to do so by forcing immediate allocation, 
but I feel it's still an improvement.


-- 
PGP fingerprint: 5BBD5080FEB0EF7F142F8173D572B791F7B4422A


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ