On Thu, Apr 11, 2019 at 2:50 AM Ian Kent <raven@xxxxxxxxxx> wrote: > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > seeking clarification on what linux-next to look at for the > > > > > sake of accuracy. > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > or one of the daily branches one would use to check for conflicts > > > > > before posting? > > > > > > > > Sorry those are tags not branches. > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > and master is rebased every day. Can it be reproduced with the current > > > tree? > > > > From the info on the dashboard we know that it happened only once on > > d14b746c (the second one is result of reproducing the first one). So > > it was either fixed or just hard to trigger. > > Looking at the source of tag next-20181214 in linux-next-history I see > this is mistake I made due to incorrect error handling which I fixed > soon after (there was in fact a double iput()). > > I'm pretty sure this never made it to a released kernel so unless > there's a report of this in a stable released kernel I'm going to > move on. Please don't ignore the bug status tracking part. Or we will only have options of not testing kernel or dropping most of the bug reports on the floor. Both are equally harmful for kernel quality. Let's mark it as fixed by the next commit in series (which already made it into mainline): #syz fix: autofs: simplify parse_options() function call But I won't be around always.
