linux-kernel - Re: [syzbot] WARNING in io_poll_task

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]

Date:   Mon, 8 Nov 2021 17:30:39 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Jens Axboe <axboe@...nel.dk>,
        syzkaller <syzkaller@...glegroups.com>
Cc:     Aleksandr Nogikh <nogikh@...gle.com>,
        syzbot <syzbot+804709f40ea66018e544@...kaller.appspotmail.com>,
        asml.silence@...il.com, io-uring@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        xiaoguang.wang@...ux.alibaba.com
Subject: Re: [syzbot] WARNING in io_poll_task_func (2)

On Thu, 4 Nov 2021 at 12:44, Jens Axboe <axboe@...nel.dk> wrote:
>
> On 11/4/21 4:45 AM, Aleksandr Nogikh wrote:
> > Hi Jeans,
> >
> > We'll try to figure something out.
> >
> > I've filed an issue to track progress on the problem.
> > https://github.com/google/syzkaller/issues/2865
>
> Great thanks. It's annoyed me a bit in the past, but it's really
> excessive this time around. Probably because that particular patch
> caused more than its fair share of problems, but still shouldn't
> be an issue once it's dropped from the trees.

syzbot always tests the latest working tree. In this case it's the
latest linux-next tree. No dead branches were tested.

The real problem here is rebased trees and dropped patches and the use
of "invalid" command.
For issues fixed with a commit (#syz fix) syzbot tracks precisely when
the commit reaches all of the tested builds and only then closes the
issue and starts reporting new occurrences as new issues.
But "syz invalid" does not give syzbot a commit to track and means
literally "close now", so any new occurrences are reported as new
issues immediately.
The intention is that it's on the user issuing the "invalid" command
to do this only when the issue is really not present in any of syzbot
builds anymore.
There are hacks around like saying "syz fix" with some unrelated later
commit that will reach linux-next upstream along with the dropped
patch, then syzbot will do proper tracking on its own.
Better suggestions are welcome.

I think https://github.com/google/syzkaller/issues/2865 will help only
in very limited number of cases (no reproducer, can't determine the
subsystem tree") and in some cases can make things worse (falsely
deciding to not report a real bug).