[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHk-=wjqv_dAd55m31fJk=6FAy1+=556L9y8eAOB92RstWy6_Q@mail.gmail.com>
Date: Wed, 31 May 2023 14:48:14 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: syzbot <syzbot+a98f21ebda0a437b04d7@...kaller.appspotmail.com>
Cc: almaz.alexandrovich@...agon-software.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
ntfs3@...ts.linux.dev, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ntfs3?] WARNING in attr_data_get_block (2)
On Wed, May 31, 2023 at 12:14 AM syzbot
<syzbot+a98f21ebda0a437b04d7@...kaller.appspotmail.com> wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 68674f94ffc9dddc45e7733963ecc35c5eda9efd
> x86: don't use REP_GOOD or ERMS for small memory copies
That sounds very unlikely.
While we had another similar issue where not using REP_GOOD or ERMS
for user space clearing fixes a bug, that one failed by having
clear_user() oops instead of handling the right exception.
In that case the commit really did fix things, even if it was just by
pure luck, and removing buggy code.
But this one seems to have a failure case that has nothing to do with
exception handling, and I don't think that commit actually fixes any
semantic bug. I suspect the bisection was not entirely repeatable,
and/or might have been timing-dependent, and that the bisection thus
ended up on a random unrelated commit.
Linus
Powered by blists - more mailing lists