Re: INFO: task hung in lo_ioctl

From: Dmitry Vyukov <dvyukov@google.com>
To: Omar Sandoval <osandov@osandov.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Al Viro <viro@zeniv.linux.org.uk>, Omar Sandoval <osandov@fb.com>,
	syzbot 
	<bot+abdba5bc6de135d7622f00756da97998425b6de5@syzkaller.appspotmail.com>,
	Jens Axboe <axboe@kernel.dk>, Ming Lei <tom.leiming@gmail.com>,
	Hannes Reinecke <hare@suse.de>,
	shli@fb.com, LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	knikanth@suse.de
Subject: Re: INFO: task hung in lo_ioctl
Date: Sat, 19 Jan 2019 19:56:00 +0100	[thread overview]
Message-ID: <CACT4Y+ZaL=zPbb-r7PKvOsY8aBRiMEEHMc+-HVGm+dRTax+DfA@mail.gmail.com> (raw)
In-Reply-To: <20180406155905.GA11697@vader>

On Fri, Apr 6, 2018 at 5:59 PM Omar Sandoval <osandov@osandov.com> wrote:
>
> On Fri, Apr 06, 2018 at 05:43:43PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 06, 2018 at 10:55:03PM +0900, Tetsuo Handa wrote:
> > > Peter Zijlstra wrote:
> > > > On Fri, Apr 06, 2018 at 09:04:18PM +0900, Tetsuo Handa wrote:
> > >
 > > +       /* Temporary hack for handling lock imbalance. */
> > > > > +       if (__mutex_owner(&lo->lo_ctl_mutex) == current)
> > > > > +               mutex_unlock(&lo->lo_ctl_mutex);
> > > >
> > > > ARGGH.. you didn't read the comment we put on that?
> > > >
> > >
> > > Commit 5b52330bbfe63b33 ("audit: fix auditd/kernel connection state tracking")
> > > is using __mutex_owner(). ;-)
> >
> > That got removed and the warning added.
>
> Seems easy enough to fix without resorting to __mutex_owner() (untested):
>
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 264abaaff662..cee258d12a1e 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1300,12 +1300,13 @@ loop_get_status_old(struct loop_device *lo, struct loop_info __user *arg) {
>  static int
>  loop_get_status64(struct loop_device *lo, struct loop_info64 __user *arg) {
>         struct loop_info64 info64;
> -       int err = 0;
> +       int err;
>
> -       if (!arg)
> -               err = -EINVAL;
> -       if (!err)
> -               err = loop_get_status(lo, &info64);
> +       if (!arg) {
> +               mutex_unlock(&lo->lo_ctl_mutex);
> +               return -EINVAL;
> +       }
> +       err = loop_get_status(lo, &info64);
>         if (!err && copy_to_user(arg, &info64, sizeof(info64)))
>                 err = -EFAULT;
>
>
> I'll test it and send it up when I get into the office.

Was this ever submitted? Or some other fix for this?

The bug is still open, but last happened 289 days ago:
https://syzkaller.appspot.com/bug?id=608144371e7fc2cb6285b9ed871fb1eb817a61ce

But it also has 10 duplicates, some of which happened much more recently.
If a fix was submitted, but Reported-by tag wasn't added this open bug
can now mask lots of other new bugs.