Received: by 10.213.65.68 with SMTP id h4csp1692767imn; Thu, 5 Apr 2018 02:01:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/SASE+/++utTWtrMsMPiWjgBJyuroCLS4uH2mFGzyhdKiv5oOVOfijp9f+fm3WqBDzPiSl X-Received: by 10.98.7.83 with SMTP id b80mr16592064pfd.133.1522918895829; Thu, 05 Apr 2018 02:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522918895; cv=none; d=google.com; s=arc-20160816; b=jyiUWqSmgDCQwqJ0cIN5XRLxb31OpuToiRGlBlaxyjNEaLgAS0dYmEnfGpc9T0Wiey vMK6KG+JyQFQc2ampxh/0bMNIKt24cTYpuwQzqy5E36yXiNbA9oggPwHdEf7SFM2q4f2 Y53/vHdXh/48ckcHLLfagQxCvjNs+p8fLxMovgm6RcwPGCbmXPmJjBboRrAvNIoJ00NE U2GMcBU5yz28NsUt3dvIuYSVjTCUVy0qPohlpjkLw7q8W08i1TmVTFMqvEWdyVUO9rBm I9RYc/w1ZcqP0T1REEwJvcuJ3Bu8zhMyu4Sb941YCJcqAqt4K5FqN0Z3+5LkVJj2ifRC t3tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=T7B4VJEwAJcgw0fk1ZD4Cn4hBZKXACo84tuLEzq2AQ4=; b=k8flAZtNUh+avUQ1dhTQ6VPRuAms2mgPZFDZWo+IsooCfFXFjyOkarfRj+uu+SofKv tACrkVzWSQBwnZbizXb0GLVza/toiSVNWUl7aSBf1P0sMdrrxGajkXVgsviEr10LaNGz BIT2rJkefTOT0ORxIG70C6kFmZnm36PaBycrerwOlSwm/OSEnmvd78LvLbaOMbFA6G/7 VMWzFFedNTn/a1jNNgFFjDtxJf4oO0iK10OUl5PxFhW5fxQ4GAGneloYwOX0PI6I8454 v2XDvvgMUTeHMv1KqnE5pfFKm21pxYZU0Sz9dawn4dJUXnw9N3dOS3iEcNuEljlsTWiA ROLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k11-v6si5276921pls.58.2018.04.05.02.01.22; Thu, 05 Apr 2018 02:01:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751672AbeDEJAJ (ORCPT + 99 others); Thu, 5 Apr 2018 05:00:09 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:45970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751525AbeDEJAH (ORCPT ); Thu, 5 Apr 2018 05:00:07 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DE5A7C6DC; Thu, 5 Apr 2018 09:00:07 +0000 (UTC) Received: from 117.195.187.81.in-addr.arpa (unknown [10.33.36.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E827215CDAF; Thu, 5 Apr 2018 09:00:05 +0000 (UTC) Subject: Re: WARNING: kobject bug in sysfs_warn_dup To: Dmitry Vyukov Cc: Greg KH , rpeterso@redhat.com, cluster-devel@redhat.com, syzbot , LKML , syzkaller-bugs@googlegroups.com References: <20180405063444.GA5877@kroah.com> <26e497b0-1e10-d9c6-73eb-e0feed9a60ea@redhat.com> From: Steven Whitehouse Message-ID: <97ada9f8-93e0-b321-e588-2d3b34b10ef8@redhat.com> Date: Thu, 5 Apr 2018 10:00:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 05 Apr 2018 09:00:07 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 05 Apr 2018 09:00:07 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'swhiteho@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 05/04/18 09:52, Dmitry Vyukov wrote: > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse wrote: >> Hi, >> >> >> >> On 05/04/18 09:19, Dmitry Vyukov wrote: >>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH >>> wrote: >>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote: >>>>> Hello, >>>>> >>>>> syzbot hit the following crash on upstream commit >>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000) >>>>> Merge tag 'ext4_for_linus' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 >>>>> syzbot dashboard link: >>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5 >>>>> >>>>> C reproducer: >>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512 >>>>> syzkaller reproducer: >>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336 >>>>> Raw console output: >>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608 >>>>> Kernel config: >>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941 >>>>> compiler: gcc (GCC) 7.1.1 20170620 >>>>> >>>>> IMPORTANT: if you fix the bug, please add the following tag to the >>>>> commit: >>>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com >>>>> It will help syzbot understand when the bug is fixed. See footer for >>>>> details. >>>>> If you forward the report, please keep this part and the footer. >>>>> >>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003 >>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000 >>>>> ------------[ cut here ]------------ >>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to >>>>> register >>>>> things with the same name in the same directory. >>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev(' >>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238 >>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235 >>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15 >>>>> Kernel panic - not syncing: panic_on_warn set ... >>>>> >>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>>>> Google 01/01/2011 >>>>> Call Trace: >>>>> __dump_stack lib/dump_stack.c:17 [inline] >>>>> dump_stack+0x1a7/0x27d lib/dump_stack.c:53 >>>>> sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30 >>>>> sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58 >>>>> create_dir lib/kobject.c:69 [inline] >>>>> kobject_add_internal+0x335/0xbc0 lib/kobject.c:227 >>>>> kobject_add_varg lib/kobject.c:364 [inline] >>>>> kobject_init_and_add+0xf9/0x150 lib/kobject.c:436 >>>>> gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652 >>>>> fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118 >>>>> gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321 >>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect >>>> usage of the api. >>> Then +gfs2 maintainers. >>> >>>> Now if we should turn this into a non-WARN message, that's a different >>>> thing, I'll gladly take a patch for that. >>> If it's API usage bug in higher level code, then I think WARN is a >>> proper thing. We already had similar ones and they were fixed. >> >> I'm trying to figure out what the test is doing, but it is not very clear. >> At a guess I'd say that perhaps it is trying to mount multiple filesystems >> with the same label? If that is the case then it is not allowed, and it >> should be caught be the sysfs code and result in a refusal to mount, which >> is what I think I see here. Knowing which sysfs directory is involved would >> allow us to confirm, but I suspect that the test needs altering to give each >> gfs2 mount a different label at an initial guess, > > Hi Steve, > > But Greg claims that this is incorrect usage of sysfs API: > >> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect >> usage of the api. > I think this means that sysfs callers must not try to create the same > thing twice. > > Either way user-space code must not be able to triggers WARNINGs in > kernel. If it does than this is something to fix in kernel. I guess that this warning was added more recently as I've not seen it before. My expectation is that it will return -EEXIST and not print a warning there. To avoid that we would have to create a new list of GFS2 superblocks, and check the list for each mount I think. We could do that, but it seems a bit odd to duplicate code that is already there and working. So it sounds like a case of differing assumptions about what is a valid use of the sysfs api. Shouldn't be too hard to fix though, Steve.