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] [day] [month] [year] [list]

Date:   Mon, 8 Nov 2021 09:42:38 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Dmitry Vyukov <dvyukov@...gle.com>,
        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 11/8/21 9:30 AM, Dmitry Vyukov wrote:
> 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.

Maybe the -next tree is just lagging. Does the syzbot setup for the
kernel have some notion of the trees involved? For this particular
example, if the upstream tree that contains/contained the patch that is
flagged as problematic, then it would be ideal if it didn't get
reported. Not sure if this is viable or not.

Ditto if the upstream tree already has a fix for that issue, marked
appropriately. But I guess this one naturally falls out from having told
syzbot with a #fix reply, but that normally doesn't need to happen as
long as the patch flows into the tree being tested. If -next is lagging,
then again we'd get multiple reports for the same thing on an outdated
tree.

> 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.

And the latter is problematic if the -next tree isn't current 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 guess a work-around would just be to use #fix for eg the merge commit
in the upstream branch.

-- 
Jens Axboe