From patchwork Mon Nov 20 13:05:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Vyukov X-Patchwork-Id: 10066393 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F3B8A60375 for ; Mon, 20 Nov 2017 13:05:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E577628F96 for ; Mon, 20 Nov 2017 13:05:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D930B290AC; Mon, 20 Nov 2017 13:05:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6785728F96 for ; Mon, 20 Nov 2017 13:05:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751258AbdKTNFf (ORCPT ); Mon, 20 Nov 2017 08:05:35 -0500 Received: from mail-pf0-f175.google.com ([209.85.192.175]:35373 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751071AbdKTNFe (ORCPT ); Mon, 20 Nov 2017 08:05:34 -0500 Received: by mail-pf0-f175.google.com with SMTP id r88so3317182pfi.2 for ; Mon, 20 Nov 2017 05:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6v4eSJFSQFcKX31wCcjev+fKvnkxeN1ylKqR4AyHMys=; b=m8qbFjm791jDcL1MAoYKgTXUxdwIxEFTjZDufdbfKLeZUQ718EKSqjAXmHk0XNuzhz 4gcvj7vDL/8ZgzeQrZNglBP0Eo3WD372voKYEdR1fmKDK2+ZCWL2aZ+fxLYL0aSJqJZ7 D5qlOcSaz++vRrZdMreHx71+9R5Oxs3tESUmo/osqlXZ4yW3EEhPJ1ADv/fN2dfmnjp3 bXrnwoMOxZsvgkzxF+Y2LWx/ypmnaCw5R67n0Ncjr2xs6b5uOZj0yEfCyKEb4ohJ5B2n jZl+bVnJlWL3abBOti9z3X7DPfUBrFJqWjlRM040U572sFCKsJLkFYceN9Im0JD8LU8A ryQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6v4eSJFSQFcKX31wCcjev+fKvnkxeN1ylKqR4AyHMys=; b=ZekM+vCy6Re3cm849/6+Aj+Fhl2Td7EJ5yQ5Igu/cbAbvZdgKl8rTOCeMqOJprjMxG izm4l8XXEnT4zybd2uvbgYEgfqaR9uRRR0dmIzmYCis4QL8t0xml8A07FjH/oFKO1a1j /QEmUWe6pHn2m5O21/kn+vYput9tAnXmBouV+m19DKQ29XQkjl2HeSzNJhBcRQ227Aci xaVHGeqIcY1sECsWN5sDEx/nRDKMYOqAvSa950nWtmVvtozUhdlOpTzdkZZuhnZQyQXx KwRlnyHvYOd98cyKRBzRFVjYRRYqU4IXmrr4sRZvSsalG0+nO4BoTOb16dqYd8Ew9PYM 1plQ== X-Gm-Message-State: AJaThX4x0lmtNzFRuvxDhQXaduCUrgmol0DWgq/EDkpQzwZNkXUjbcCP 7/EdqjvmgcBHHzr6sscpLR3L09ewXZUsi5FpJttBuw== X-Google-Smtp-Source: AGs4zMYs1bTXFnvGs1oqwIYHc7P8ivbUJL/VV+VetzOlADmo4nm+trJgFkvtbZzPzpMOM4CPnr/3S+FOhrcU7u7dYm4= X-Received: by 10.84.131.34 with SMTP id 31mr14020054pld.449.1511183133505; Mon, 20 Nov 2017 05:05:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.141.228 with HTTP; Mon, 20 Nov 2017 05:05:12 -0800 (PST) In-Reply-To: <20171117210232.GP21978@ZenIV.linux.org.uk> References: <001a113fd5c8383f10055e17773c@google.com> <20171117210232.GP21978@ZenIV.linux.org.uk> From: Dmitry Vyukov Date: Mon, 20 Nov 2017 14:05:12 +0100 Message-ID: Subject: Re: WARNING in lock_release To: Al Viro Cc: syzbot , linux-fsdevel@vger.kernel.org, LKML , syzkaller-bugs@googlegroups.com Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Nov 17, 2017 at 10:02 PM, Al Viro wrote: > On Thu, Nov 16, 2017 at 02:56:00AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 5515cf16e270538121e4fa9283fed86c6cfd8c9c >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached >> Raw console output is attached. >> C reproducer is attached >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ >> for information about syzkaller reproducers > > Hmm... That's alloc_super() buggering off on allocation failure and > hitting up_write(s->s_umount) in destroy_unused_super(), since it has > not done > init_rwsem(&s->s_umount); > lockdep_set_class(&s->s_umount, &type->s_umount_key); > down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING); > part yet. The sucker is just all-zeroes here. The easiest way to fix > that would probably be to move that bit of initialization in the very > beginning... > > diff --git a/fs/super.c b/fs/super.c > index 8ca15415351a..2808aeaf5337 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -190,6 +190,24 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags, > > INIT_LIST_HEAD(&s->s_mounts); > s->s_user_ns = get_user_ns(user_ns); > + init_rwsem(&s->s_umount); > + lockdep_set_class(&s->s_umount, &type->s_umount_key); > + /* > + * sget() can have s_umount recursion. > + * > + * When it cannot find a suitable sb, it allocates a new > + * one (this one), and tries again to find a suitable old > + * one. > + * > + * In case that succeeds, it will acquire the s_umount > + * lock of the old one. Since these are clearly distrinct > + * locks, and this object isn't exposed yet, there's no > + * risk of deadlocks. > + * > + * Annotate this by putting this lock in a different > + * subclass. > + */ > + down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING); > > if (security_sb_alloc(s)) > goto fail; > @@ -217,25 +235,6 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags, > goto fail; > if (list_lru_init_memcg(&s->s_inode_lru)) > goto fail; > - > - init_rwsem(&s->s_umount); > - lockdep_set_class(&s->s_umount, &type->s_umount_key); > - /* > - * sget() can have s_umount recursion. > - * > - * When it cannot find a suitable sb, it allocates a new > - * one (this one), and tries again to find a suitable old > - * one. > - * > - * In case that succeeds, it will acquire the s_umount > - * lock of the old one. Since these are clearly distrinct > - * locks, and this object isn't exposed yet, there's no > - * risk of deadlocks. > - * > - * Annotate this by putting this lock in a different > - * subclass. > - */ > - down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING); > s->s_count = 1; > atomic_set(&s->s_active, 1); > mutex_init(&s->s_vfs_rename_mutex); Hi, We are rolling out patch testing feature for syzbot: https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot So if you are asking for testing, feel free to use it. If not, let's still give it a try (it also needs testing): #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master diff --git a/fs/super.c b/fs/super.c index 8ca15415351a..2808aeaf5337 100644 --- a/fs/super.c +++ b/fs/super.c @@ -190,6 +190,24 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags, INIT_LIST_HEAD(&s->s_mounts); s->s_user_ns = get_user_ns(user_ns); + init_rwsem(&s->s_umount); + lockdep_set_class(&s->s_umount, &type->s_umount_key); + /* + * sget() can have s_umount recursion. + * + * When it cannot find a suitable sb, it allocates a new + * one (this one), and tries again to find a suitable old + * one. + * + * In case that succeeds, it will acquire the s_umount + * lock of the old one. Since these are clearly distrinct + * locks, and this object isn't exposed yet, there's no + * risk of deadlocks. + * + * Annotate this by putting this lock in a different + * subclass. + */ + down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING); if (security_sb_alloc(s)) goto fail; @@ -217,25 +235,6 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags, goto fail; if (list_lru_init_memcg(&s->s_inode_lru)) goto fail; - - init_rwsem(&s->s_umount); - lockdep_set_class(&s->s_umount, &type->s_umount_key); - /* - * sget() can have s_umount recursion. - * - * When it cannot find a suitable sb, it allocates a new - * one (this one), and tries again to find a suitable old - * one. - * - * In case that succeeds, it will acquire the s_umount - * lock of the old one. Since these are clearly distrinct - * locks, and this object isn't exposed yet, there's no - * risk of deadlocks. - * - * Annotate this by putting this lock in a different - * subclass. - */ - down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING); s->s_count = 1; atomic_set(&s->s_active, 1); mutex_init(&s->s_vfs_rename_mutex);