Received: by 10.213.65.68 with SMTP id h4csp1687073imn; Thu, 5 Apr 2018 01:54:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/CanbbUj3lL+V5xVRcbujIl/3e4WJQK0fdTCCO1clmSzhXNNl1p+J8zBCjjvWQ4rk4J28B X-Received: by 10.98.76.196 with SMTP id e65mr16695190pfj.35.1522918489767; Thu, 05 Apr 2018 01:54:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522918489; cv=none; d=google.com; s=arc-20160816; b=azQModzVP2I+wYbl9IkQUUnYEvlpiFdg2+c5QE1hD3cg+H/2/2jBtyhFapaHLNNml3 n/zuAJmBFX4d0Pps4/OueUMPUAWnsPQh5CEdd3DupMszTpg1KZojGiVxvvs1EsuhSlCK ePzxjl9CeXUU476i+E97pwBXztsxAjNKYCyyzTLyijwNLuRfVbgc49Zeos4PvfkK1j6V ktZiJwBAmnFh7Qh3BPV0Mpu6VnDZuJ2upFbN155zjxw27mFWwxkbndOrDNscXa72qScj SmH/NmdoM7qhsg4LAjyaU43Zlzm0EUUoEAUCgHAFE12pu3Fq2G/bOzA5Lz+h7szlpkz+ 7E4g== 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=KDN0S8oIGhrtC5htn0+AwB10D2kkcp492UrloI3W8cg=; b=ZaGWI4y0krcWlXfXslcJS+obtv613cmQOIzTXLUQ06nnj+z7W3uc7tjs/RzyDzMglB RVdxCkmWh0vhjVql46e211/lo/aKp3fXMCE+xHe/lWDGP1WFHf6tTN7DXKEDC6zE8dIu TLymACxeeR53R3k+uDtqHUgn3tEPtQvUySye4DoPOpfSelHPknR5b8xJhTmh7Bod5JqS AVXZE3lqcTG4SbpKYArCP1kNJlmyWsQwEkCAHaGjZWAlQ0+3Sh6QGwxWVaLU3M/JLWo0 bO6GNdWDmieyMs1h2l2wk4feUkVmyjrjMNwFvQ3k1eermWs1V4CBEQWOEnUJ5rkjx5B0 sy3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=hwlajTWS; 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 x24si5170119pgc.780.2018.04.05.01.54.35; Thu, 05 Apr 2018 01:54:49 -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=hwlajTWS; 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 S1751414AbeDEIxU (ORCPT + 99 others); Thu, 5 Apr 2018 04:53:20 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:34305 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbeDEIxS (ORCPT ); Thu, 5 Apr 2018 04:53:18 -0400 Received: by mail-pl0-f65.google.com with SMTP id z5-v6so29855pln.1 for ; Thu, 05 Apr 2018 01:53:18 -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=KDN0S8oIGhrtC5htn0+AwB10D2kkcp492UrloI3W8cg=; b=hwlajTWSeIIUFZM6VtWC1+usWctNErTI6UfxsNwBGy2/vhk5EkCldo3HBn8Lvtgy7H SpX9CA8lOy5C3mla/uL65MhWjP71WKOdwgtfwcz8hpQt5CJqHqgKVhYLjaL1M8hvYebt 87QRhCaJkj92gzAsu+mGXHsT+T81tdi23XyDtORrh7QNbuaXhAU00ZQVJ2sR+Ch5I5ZL wx7rZOEZ6gktrzvhQfIErSs21MDFHFKD2CAK/WQ63yZ6u3LjTYSjfz+0d8xeRUYe81z3 E1fUEoPrLQeVL1ETplbYo5jlhCizxSHg2j/VQRA1IWgSMtNglStg2uIgdAjWJ2MR82jN zUMQ== 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=KDN0S8oIGhrtC5htn0+AwB10D2kkcp492UrloI3W8cg=; b=UWkhlys3gBSUHXx4KjkXU8OY9I4nJpocpz5KpD0mgCUo/0dY3wSVwuIN9uDaoBSBE+ 7KcvVc70H7sivPnx0JNdwvDX992TMc1PZUjOtUHc+fprRFfPgFQqszjHUImY1ejpxQK2 ctux/57kuzUR4NLR7e1wL9aMLyVMeRsTaJ2TygoJOp2ROkw48JKCwtWx/95tE5mq3D/y xhiIK1XWldvdzi5alwEHc8OlC9GueTY2vL5wKEOlt+QJxupe9E0dHHVM+t/OYJ6jauJD ZJD4muq8SFgvu91h459fVeZhS68qgYw8EenLun5u2F9Ro4a5KaEi7Q50AV5NroKDr5XU 9oeg== X-Gm-Message-State: AElRT7HyL7fTM3Oukm5R1vfgePgwqWMm/zMYBpXy49wxmuscfPgs+zPj FZfmngvGta1fhoNHd7h3w5Ap3hZ0YpfN93J7FQop+w== X-Received: by 2002:a17:902:8482:: with SMTP id c2-v6mr22619390plo.295.1522918397811; Thu, 05 Apr 2018 01:53:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.136 with HTTP; Thu, 5 Apr 2018 01:52:57 -0700 (PDT) In-Reply-To: <26e497b0-1e10-d9c6-73eb-e0feed9a60ea@redhat.com> References: <20180405063444.GA5877@kroah.com> <26e497b0-1e10-d9c6-73eb-e0feed9a60ea@redhat.com> From: Dmitry Vyukov Date: Thu, 5 Apr 2018 10:52:57 +0200 Message-ID: Subject: Re: WARNING: kobject bug in sysfs_warn_dup To: Steven Whitehouse Cc: Greg KH , 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 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.