On 2024/7/24 14:23, Ojaswin Mujoo wrote:
On Wed, Jul 17, 2024 at 02:11:27PM +0800, Baokun Li wrote:
On 2024/7/17 13:29, Ojaswin Mujoo wrote:
On Tue, Jul 16, 2024 at 07:54:43PM +0800, Baokun Li wrote:
Hi Ojaswin,
On 2024/7/16 17:54, Ojaswin Mujoo wrote:
But the journal will ensure the consistency of the extents path after
this patch.
When ext4_ext_get_access() or ext4_ext_dirty() returns an error in
ext4_ext_rm_idx() and ext4_ext_correct_indexes(), this may cause
the extents tree to be inconsistent. But the inconsistency just
exists in memory and doesn't land on disk.
For ext4_ext_get_access(), the handle must have been aborted
when it returned an error, as follows:
ext4_ext_get_access
ext4_journal_get_write_access
__ext4_journal_get_write_access
err = jbd2_journal_get_write_access
if (err)
ext4_journal_abort_handle
For ext4_ext_dirty(), since path->p_bh must not be null and handle
must be valid, handle is aborted anyway when an error is returned:
ext4_ext_dirty
__ext4_ext_dirty
if (path->p_bh)
__ext4_handle_dirty_metadata
if (ext4_handle_valid(handle))
err = jbd2_journal_dirty_metadata
if (!is_handle_aborted(handle) && WARN_ON_ONCE(err))
ext4_journal_abort_handle
Thus the extents tree will only be inconsistent in memory, so only
the verified bit of the modified buffer needs to be cleared to avoid
these inconsistent data being used in memory.
Regards,
Baokun
Thanks for the explanation Baokun, so basically we only have the
inconsitency in the memory.
I do have a followup questions:
So in the above example, after we have the error, we'll have the buffer
for depth=0 marked as valid but pointing to the wrong ei_block.
It looks wrong here. When there is an error, the ei_block of the
unmodified buffer with depth=0 is the correct one, it is indeed
'valid' and it is consistent with the disk. Only buffers that were
Hey Baokun,
Ahh I see now, I was looking at it the wrong way. So basically since
depth 1 to 4 is inconsistent to the disk we mark then non verified so
then subsequent lookups can act accordingly.
Thanks for the explanation! I am in the middle of testing this patchset
with xfstests on a POWERPC system with 64k page size. I'll let you know
how that goes!
Regards,
Ojaswin
Hi Ojaswin,
Thank you for the test and feedback!
Cheers,
Baokun
Hey Baokun,
Hi Ojaswin,
Sorry for the slow reply, I'm currently on a business trip.
The xfstests pass for sub page size as well as bs = page size for
POWERPC with no new regressions.
Thank you very much for your test!
Although for this particular patch I doubt if we would be able to
exersice the error path using xfstests. We might need to artifically
inject error in ext4_ext_get_access or ext4_ext_dirty. Do you have any
other way of testing this?
The issues in this patch set can all be triggered by injecting EIO or
ENOMEM into ext4_find_extent(). So not only did I test kvm-xftests
several times on x86 to make sure there weren't any regressions,
but I also tested that running kvm-xfstests while randomly injecting
faults into ext4_find_extent() didn't crash the system.
Also, just curious whether you came across this bug during code reading
or were you actually hitting it?
The initial issue was that e2fsck was always reporting some sort of
extents tree exception after testing, so the processes in question
were troubleshooting and hardening, i.e. the first two patches.
The other issues were discovered during fault injection testing of
the processes in question.
Regards,
Baokun
