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: <20200929113727.GK10896@quack2.suse.cz>
Date:   Tue, 29 Sep 2020 13:37:27 +0200
From:   Jan Kara <jack@...e.cz>
To:     Mauricio Faria de Oliveira <mfo@...onical.com>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
        dann frazier <dann.frazier@...onical.com>
Subject: Re: [RFC PATCH v4 0/4] ext4/jbd2: data=journal: write-protect pages
 on transaction commit

On Mon 28-09-20 16:40:59, Mauricio Faria de Oliveira wrote:
> Hey Jan,
> 
> This series implements your suggestions for the RFC PATCH v3 set [1].
> 
> That addressed the issue you confirmed with block_page_mkwrite() [2].
> There's no "JBD2: Spotted dirty metadata buffer" message in over 72h
> runs across 3 VMs (it used to happen within a few hours.) *Thanks!*
> 
> I added Reviewed-by: tags for the patches/changes you mentioned.
> The only changes from v3 are patch 3 which is new, and contains
> the 2 fixes to ext4_page_mkwrite(); and patch 4 changed 'struct
> writeback_control.nr_to_write' from ~0ULL to LONG_MAX, since it
> is signed long (~0ULL overflows to -1; kudos, kernel test robot!)
> 
> It looks almost good on fstests: zero regressions on data=ordered,
> and two apparently flaky tests data=journal (generic/347 _passed_
> 1/6 times with the patch, and generic/547 failed 1/6 times.)

Cool. Neither of these tests has anything to do with mmap. The first test
checks what happens when thin provisioned storage runs out of space (and
that fs remains consistent), the second tests that fsync flushed properly
all data and that it can be seen after a crash. So I'm reasonably confident
that it isn't caused by your patches. It still might be a bug in
data=journal implementation though but that would be something for another
patch series :).

I'll have a look at the remaining patches.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ