Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2653566yba; Mon, 15 Apr 2019 16:56:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8xDY9zLk0EWjBs7VulV9W4DCWW05Ji9JLXPZdB5DZKb9PyxCD2DSy6AqP3JxkfpmNG0vC X-Received: by 2002:a63:2b4c:: with SMTP id r73mr74466064pgr.181.1555372577427; Mon, 15 Apr 2019 16:56:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555372577; cv=none; d=google.com; s=arc-20160816; b=ury6o4kqw7WtUte+LjRYIMA+m6d92Yz8M9s5erOblA8PYTPT7PRyfCoojPmpdigzFI xcVK02SG3fQzdTfS5JDJcbW1Q8Vdj1+xK7bp+tajevlpNMuVSfcPiCyRjM7BMJuWSIRb C3lXDm/aLjUnTAJxz9eNN9up8SSoiAZol3ZsjizxoZ6xhKXKb1gyJlRXDxwgAn7fXT8U s8fKgqxRtvEmqx92/DPxnd9MYZZFjIrtNMOB7nIL8glL0h/KZV1ul1tJgMlSDNYcji9u 5NEwMJHCrjTtzz86pssPS0Qow9roK47f7120La4/fa7Em9ZaQJwZBtKRTWG+DZWy8uCh uU/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zZphwyqx2WYWwKoVLB7HzmJjaFvUntSiWqc2u4tETDo=; b=N+nIC2XqedbA/nRKKHs4MRj8h2dpIMDHMGLj2PvlljlR7S1jvxB+n15+miAfkEQsa8 aARZj4T+LGZLjXFfXa1jWqTL9iu8wFu+pQHBHQ+sTpD6rrY2tDNht3mhexFtb5fIB1Gn DN/RLWjqj0Izb+LC2connhdbCg4vcgO5w9hpQGiXRHbeDGzF84l3SCDTNgc5Pa0dQp7V QTfgOqYCF8RVkTp/A8uI3texlEoJBRBulFRWu8XCkF5YcYA50XRCFbFTiIOcxXOWtUS/ 3BoYVq3MKWyTzd4gpaahUi4QhRAmo35zejWhISJRS4UqWluIYxv2E0TBpy4VJKOuK4yk Kd4A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si27798037plp.296.2019.04.15.16.56.01; Mon, 15 Apr 2019 16:56:17 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728291AbfDOXyi (ORCPT + 99 others); Mon, 15 Apr 2019 19:54:38 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:43588 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728101AbfDOXyi (ORCPT ); Mon, 15 Apr 2019 19:54:38 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hGBQi-0004gX-T3; Mon, 15 Apr 2019 23:54:28 +0000 Date: Tue, 16 Apr 2019 00:54:28 +0100 From: Al Viro To: Khazhismel Kumykov Cc: Tetsuo Handa , syzbot , linux-fsdevel , syzkaller-bugs@googlegroups.com, Linux Kernel Mailing List , linux-xfs@vger.kernel.org Subject: Re: WARNING in notify_change Message-ID: <20190415235428.GS2217@ZenIV.linux.org.uk> References: <94eb2c0ce3aa7551d30569658325@google.com> <96c750b3-fcb0-3d7f-45eb-45459078ef83@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2019 at 04:20:17PM -0700, Khazhismel Kumykov wrote: > I was able to reproduce this by setting security.capability xattr on a > blockdev file, then writing to it - when writing to the blockdev we > never lock the inode, so when we clear the capability we hit this > lockdep warning. > > Is the issue here that we can set this xattr in the first place so we > have to clear it at all? Or should we really be locking the inode for > blockdevs after all? I'm not too familiar, but my gut says former More interesting question is, WTF do we even touch that thing for bdev? The thing is, mknod will cheerfully create any number of different filesystem objects, all giving access to the same block device. Which of them should have that xattr removed? It makes no sense whatsoever; moreover, who *cares* about caps for block device in the first place? And if we did, what of another way to modify the block device? You know, mount it read-write...