Received: by 10.213.65.68 with SMTP id h4csp1975559imn; Thu, 5 Apr 2018 07:02:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/PZ/dlWN/glVBuBJvRkxRiNamGFGJ9T/JUj4US/i4kBCDKHGpESZwMZxBiCLGCArVODbQi X-Received: by 2002:a17:902:5609:: with SMTP id h9-v6mr22952970pli.121.1522936936940; Thu, 05 Apr 2018 07:02:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522936936; cv=none; d=google.com; s=arc-20160816; b=R10H22jCwJhiP8Z0eFHkZgYA/5+3QLQHw9NRu3Ne/X0KsgfuRkS7b3p/ftnN8y8TEC NNb/lnpyE064XwnEuymQhdPCS31uu2OKd0koc82N8HVpUc802Gk+K8XsYGp18kL/Egso odyQQ+O94G9WL+6LdKg3BB1FBpIVeKmQKea4Ph97up1uQZCRzidj9VBrZnqWc733rv7a CwdqvUZ6/hbPhJk47yWkoKb6sJp+T6fufNR1O1PC8hVztwJND7+7invDL8Jp4qK2wDkH 5ZG4KtZydIXxKYjpbAwocDxpLsiwgHlkX/ePjm5IV/tqAB+L5zOZtIDxGyCZfEWr/SEl XJbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=XAz8RXy8yD7XoNdCJTGLCFIOX8AjEIhZ3FVWBb0AfjU=; b=lvtnBmez6qo8TRDBFJ7c66OPd6ym6+Ud1L8wAMV9CUg5b0BhemXkYRskXnJjU7JJCY JhPBWyOlNg09vf5IM0kLvGuuh3UUUWSIO/zqb+jtTMTn+4AyGVncKEJfWoqdRvYC63IJ TfqDEk5mMZl3bKp2f78MquAOraV6bB86rIlCzXUjAHdzEMQq/afSaKHPmgVk0FBuTZuX R3ta/PdKhnwA/+DCbD/HUxfNJA8HCLF1q6WpYQkdXD/8jkN8JXPVzn/1TaqykV5SdZQ9 BgDs7ux6i/H2CEfL0Eao8QsBoW5Zc1XZZ6+92+vST9PmdkGM8vVXmSibyrXKN53gGhWP gNKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CFL8qwJJ; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si7978498pld.255.2018.04.05.07.02.01; Thu, 05 Apr 2018 07:02:16 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=CFL8qwJJ; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751465AbeDEOAY (ORCPT + 99 others); Thu, 5 Apr 2018 10:00:24 -0400 Received: from mail-pl0-f54.google.com ([209.85.160.54]:34289 "EHLO mail-pl0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbeDEOAU (ORCPT ); Thu, 5 Apr 2018 10:00:20 -0400 Received: by mail-pl0-f54.google.com with SMTP id z5-v6so1055076pln.1 for ; Thu, 05 Apr 2018 07:00:20 -0700 (PDT) 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=XAz8RXy8yD7XoNdCJTGLCFIOX8AjEIhZ3FVWBb0AfjU=; b=CFL8qwJJIAaJQTb/Lynjih1wjh9fRjvMJ3ftAEgmXB/H+WHyS1lfE5naDchsgEqqK0 3mQyoMCgV8KicVJu6oQPOtjFAwQNv/PaqqXCefdVfynIDjDxh5snWqnIdHwbDlVJ13CK mZiT04CTx3cN6Lw5NpeMaC/HE5BlJlC8YgflsyRGlGi5Zid48D1+i0Y9Vseps6NWEMbp TQ0rJO2qF1c8Hu5YaOspcz57j5dbXlKYGGIi/e7vWLZs2EGAj6dxEm0lHrQXMV9CbsfS +YP1CetvVc/Kene5xF0G27fRAcwjDK9vJasQ/caqBXA/XwVSTJnx555Jfx6Z7Qg+sIMJ fBlg== 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=XAz8RXy8yD7XoNdCJTGLCFIOX8AjEIhZ3FVWBb0AfjU=; b=mqyQlthAOue/zPfMREns6f88XnGZsTZ8Ws8B0hetLv/hHKB1tumoE8NzjICjqyyeUr 2FlcvtAc8KDxqE9jELacd+Efe0wk0IJhQ8PLoEDpFoJLmrTmyh++uEXj1DnSbVt8HokV VIGYMP03P+AL+kAR907rl1YKWqMimbf0Fj99XQL3ugo/AFE6bQCB2y3VfsghITRBEGZ0 Ae4FgZF9ll6xaaDoUAqETgRaKU9ZAKIrvtUHpL5BJsZVki67qWchwwlmi9D0X6ZoDEhO amwaDeCwoZiVnKgWODLZRhpNlX/hARGo8asm9u5/0uMR1geOVzcGzEhC0JayixVfdGTX ZEtw== X-Gm-Message-State: ALQs6tAayzHSYeEeIX1pgtZ34WvxiY5MEARk7q9PMBckn4fpKw7biC7i N4bVJK/rRvhttXUdibSi3kAJ8dmP/5z1pxC7EQskCQ== X-Received: by 10.167.134.25 with SMTP id p25mr824249pfn.93.1522936819377; Thu, 05 Apr 2018 07:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.136 with HTTP; Thu, 5 Apr 2018 06:59:58 -0700 (PDT) In-Reply-To: <20180405133430.GA21390@kroah.com> References: <20180405063444.GA5877@kroah.com> <26e497b0-1e10-d9c6-73eb-e0feed9a60ea@redhat.com> <97ada9f8-93e0-b321-e588-2d3b34b10ef8@redhat.com> <20180405133430.GA21390@kroah.com> From: Dmitry Vyukov Date: Thu, 5 Apr 2018 15:59:58 +0200 Message-ID: Subject: Re: WARNING: kobject bug in sysfs_warn_dup To: Greg KH Cc: Steven Whitehouse , rpeterso@redhat.com, cluster-devel@redhat.com, syzbot , LKML , syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 5, 2018 at 3:34 PM, Greg KH wrote: > On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote: >> 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. > > No, it has been there since at least the 3.13 kernel release (back in > 2013), which is where it got moved to a separate function, but the logic > has been around in the kernel tree for much longer than that as seen in > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a > separate function") > >> 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. > > Don't you have a list of the "names" of the things you are creating > somewhere? Or are you relying on sysfs to do your housekeeping for you? > > Also, why did this trigger a syzbot report? It's only a dump_stack() > reference, one showing that yes, this is something that should not be > done, but the kernel keeps on working afterward. There is a WARN(), not just dump_stack(): WARN(1, "%s failed for %s with " "-EEXIST, don't try to register things with " "the same name in the same directory.\n", __func__, kobject_name(kobj));