On Fri, 17 Aug 2018 13:46:36 -0500 [email protected] (Eric W. Biederman) wrote:
> Dmitry Vyukov <[email protected]> writes: > > > On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman > > <[email protected]> wrote: > >> > >> Recently syzbot reported crashes in send_sigio_to_task and > >> send_sigurg_to_task in linux-next. Despite finding a reproducer > >> syzbot apparently did not bisected this or otherwise track down the > >> offending commit in linux-next. > >> > >> I happened to see this report and examined the code because I had > >> recently changed these functions as part of making PIDTYPE_TGID a real > >> pid type so that fork would does not need to restart when receiving a > >> signal. By examination I see that I spotted a bug in the code > >> that could explain the reported crashes. > >> > >> When I took Oleg's suggestion and optimized send_sigurg and send_sigio > >> to only send to a single task when type is PIDTYPE_PID or PIDTYPE_TGID > >> I failed to handle pids that no longer point to tasks. The macro > >> do_each_pid_task simply iterates for zero iterations. With pid_task > >> an explicit NULL test is needed. > >> > >> Update the code to include the missing NULL test. > >> > >> Fixes: 019191342fec ("signal: Use PIDTYPE_TGID to clearly store where file > >> signals will be sent") > >> Reported-by: [email protected] > > > > Since the commit does not contain the syzbot-provided Reported-by tag, > > we need to tell syzbot that this is fixed explicitly: > > Nor will my commits ever contain that information. That is information > only of use to syzbot. That is not information useful to anyone else. > > Further syzbot did not track this down and report this. Syzbot said > something is fishy here and happened to CC a public mailing list. Only > by chance did I see the report. There was enough information to start > an investigation but it certainly was not any kind of useful bug report. > > It is very annoying that despite syzbot claming to have a reproducer > syzbot completely failed to locate the problem commit or the proper > people to repor the issue to. I looked at the syzbot website link and > there was no evidence that syzbot even tried to track down which branch > in linux-next the commit came from. Much less to identify the commit on > that branch. Dude, lighten up. These reports are useful. Even if they don't have a reproducer, we have a backtrace and we can go look and we have a good chance of fixing the bug. And as adding a single-line tag to the commit message helps the syzbot people keep track of things, why not do it? It's hardly a big effort. They're doing useful things - please don't get all bent out of shape because things aren't 100% perfect. > Very annoyingly syzbot sent out emails and report this before it found a > reproducer. This is despite several people explicitly asking syzbot > to not report issuing on linux-next where syzbot does not have a > reproducer and it can not track down the offending commit. Dear syzbot, please report linux-next issues when you do not have a reproducer and/or cannot track down the offending commit.
