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  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]
Date:   Fri, 4 Sep 2020 08:25:59 -0700
From:   "Darrick J. Wong" <>
To:     Jens Axboe <>
Cc:     "Theodore Y. Ts'o" <>,,
        "" <>
Subject: Re: [PATCH] ext4: flag as supporting buffered async reads

On Fri, Sep 04, 2020 at 08:51:24AM -0600, Jens Axboe wrote:
> On 9/3/20 9:55 PM, Theodore Y. Ts'o wrote:
> > Hi Jens,
> > 
> > Sorry, the past few months have been *crazy* insane.  Between Linux
> > Plumbers Conference organizing, having to deal with some interns at
> > $WORK, performance reviews, etc.., etc., it's been a perfect storm.
> > As a result, I was late getting the primary ext4 pull request to
> > Linus, and he's already yelled at me for a late pull request.
> > 
> > As a result, I'm being super paranoid about asking Linus for anything,
> > even a one-time change, if it's not a bug fix.  And what you are
> > asking for isn't a bug fix, but enabling a new feature.
> That's fine, we blew past the 5.9 window long ago imho. As mentioned,
> back in May we could have solved this by just adding your acked-by
> or reviewed-by to the patch like we did for xfs/btrfs. That removes the
> ext4 tree dependency. Obviously that's no longer a concern for 5.10, but
> I need to know if we're going one of two routes:
> a) I'm queueing this up, in which case I'll still need that ack/review
> b) you're queueing it up, in which case you can just grab it
> I just don't want to end up in the same situation for 5.10, and then
> we're pushing this out 2 releases at that point...
> > Worse, right now, -rc1 and -rc2 is causing random crashes in my
> > gce-xfstests framework.  Sometimes it happens before we've run even a
> > single xfstests; sometimes it happens after we have successfully
> > completed all of the tests, and we're doing a shutdown of the VM under
> > test.  Other times it happens in the middle of a test run.  Given that
> > I'm seeing this at -rc1, which is before my late ext4 pull request to
> > Linus, it's probably not an ext4 related bug.  But it also means that
> > I'm partially blind in terms of my kernel testing at the moment.  So I
> > can't even tell Linus that I've run lots of tests and I'm 100%
> > confident your one-line change is 100% safe.
> > 
> > Next week after Labor Day, I should be completely done with the
> > performance review writeups that are on my plate, and I will hopefully
> > have a bit more time to try to debug these mysterious failures.  Or
> > maybe someone else will be able to figure out what the heck is going
> > wrong, and perhaps -rc3 will make all of these failures go away.

FWIW I saw a strange crash in the xfs/iomap directio code that I could
never reproduce again, but none of my newly onlined ext4 fstests vms
have died, and I've been running a combination of 5.9-rc1 and 5.9-rc3 +
other xfs goodies.  Good luck!


> > I'm sorry your frustrated; I'm frustrated too!  But until I can find
> > the time to do a full bisect (v5.8 works just fine.  v5.9-rc1 is
> > flakey as hell when booting my test config in a GCE VM), I'm not in a
> > position to send anything to Linus.
> That looks nasty, good luck! Hopefully the bisect will be helpful. FWIW,
> in the testing I've done (with this patch) on ext4 and with XFS, I
> haven't seen anything odd. That's using real hardware though, and qemu
> on the laptop, no GCE.
> -- 
> Jens Axboe

Powered by blists - more mailing lists