Re: kernel BUG at fs/inode.c:LINE!

[Eric Biggers <ebiggers@kernel.org>]

Hi Dmitry,

On Fri, Apr 12, 2019 at 01:04:27PM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> On Thu, Apr 11, 2019 at 4:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent 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@zeniv.linux.org.uk> 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()).
> >
> > Right - "autofs: fix possible inode leak in autofs_fill_super()" had been
> > broken (and completely pointless), leading to double iput() in that failure
> > case.  And yes, double iput() can trigger that BUG_ON(), and with non-zero
> > odds do so with that stack trace.
> >
> > As far as I'm concerned, case closed - bug had been in a misguided "fix"
> > for inexistent leak (coming from misreading the calling conventions for
> > d_make_root()), introduced in -next at next-20181130 and kicked out of
> > there in next-20181219.  Dropped by Ian's request in
> > Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.camel@themaw.net>
> > which has fixed that crap.  Moreover, that posting had been in reply to
> > that very syzcaller report, AFAICS.
> >
> > I don't know how to tell the bot to STFU and close the report in this
> > situation; up to you, folks.
> 
> 
> Please see the following for this:
> 
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  syzbot.
> 
> There are just 3 operations: mark as fixed by a commit, mark as
> invalid, mark as duplicate.
> I won't be always around. Tracking statuses of bug reports is in the
> interests of kernel quality.
> 

As I suggested before, syzbot should automatically invalidate old bug reports,
especially on linux-next, that are unlikely to still be real problems.

And, syzbot should send remainders about bugs that are still occurring.

Instead, currently developers have to waste time debugging bugs caused by
patches that were in linux-next for a few days/weeks and then dropped months
ago, and have to argue with you every time about how to tell syzbot to close the
bug when it never made it into git history.  And meanwhile, no one is looking
into the bugs that are being hit on mainline every hour or even every 10 minutes
for the past year.

That's not a great strategy to actually get bugs fixed.

- Eric