Re: INFO: task hung in xlog_grant_head_check
From: Dmitry Vyukov
Date: Mon Jun 11 2018 - 09:21:12 EST
On Wed, May 23, 2018 at 8:01 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> On 5/23/18 11:20 AM, Eric Biggers wrote:
> I'd revise that to "have to fix /some/ of them anyway."
> What I'm personally hung up on are the bugs where the "exploit" involves
> mounting a crafted filesystem that in reality would never (until the heat
> of the universe) corrupt itself into that state on its own; it's the
> image" case, which is quite different than exposing fundamental bugs like
> SB_BORN race or or the user-exploitable ext4 flaw you mentioned in your
> Those are more insidious and/or things which can be hit by real users in
> real life.
> I don't know if I can win the "malicious images aren't a critical security
> threat" battle, but I do think they are at least a different class of flaws,
> because as Dave said, mount is supposed to be a privileged operation.
> In a perfect world we'd fix them anyway, but I don't know that our resource
> pool can keep up with your google-scale bot and still make progress in other
> critical areas.
> Anyway, the upshot is that we're probably just not going to care much about
> filesystem oops-or-hang-on-mount bugs. Those problems are solved (largely)
> V5 filesystem format. Maybe I /will/ propose a system-wide tunable to
> V4 for those who are worried about such things.
> To Darrick's points about more collaboration, I still wish that our requests
> for more traditional fs fuzzer reporting (i.e. a filesystem image) weren't
> with such resistance.Tailoring your bug reports to the needs of the
> community you're interacting with seems like a pretty reasonable thing to
> As an aside, I wonder how much coverage of the V5 format code syzkaller
> achieved; that would be another useful datapoint google could provide - if
> syzkaller is in fact traversing the V5 codepaths and isn't turning anything
> up, that'd be pretty useful to know.
The current syzbot kernel code coverage is available here: