ntfs3.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: syzbot <syzbot+a98f21ebda0a437b04d7@syzkaller.appspotmail.com>
Cc: almaz.alexandrovich@paragon-software.com,
	linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org,
	ntfs3@lists.linux.dev,  syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [ntfs3?] WARNING in attr_data_get_block (2)
Date: Wed, 31 May 2023 14:48:14 -0400	[thread overview]
Message-ID: <CAHk-=wjqv_dAd55m31fJk=6FAy1+=556L9y8eAOB92RstWy6_Q@mail.gmail.com> (raw)
In-Reply-To: <00000000000040020d05fcf58ebf@google.com>

On Wed, May 31, 2023 at 12:14 AM syzbot
<syzbot+a98f21ebda0a437b04d7@syzkaller.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

      reply	other threads:[~2023-05-31 18:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-25 13:41 [syzbot] [ntfs3?] WARNING in attr_data_get_block (2) syzbot
2023-03-30 16:25 ` syzbot
2023-05-31  4:14 ` syzbot
2023-05-31 18:48   ` Linus Torvalds [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wjqv_dAd55m31fJk=6FAy1+=556L9y8eAOB92RstWy6_Q@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --cc=syzbot+a98f21ebda0a437b04d7@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).