Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp442174yba; Thu, 18 Apr 2019 04:05:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyE1By2P78fyoW48L/Fp4YPbzRjAs+FZPi8oKatfb8tZELNbwU8I7H4FuRnnQm7CrgvyaBa X-Received: by 2002:aa7:9296:: with SMTP id j22mr96974820pfa.140.1555585508640; Thu, 18 Apr 2019 04:05:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555585508; cv=none; d=google.com; s=arc-20160816; b=q50w/vmaPkuFRaU8iATWRiEkoT6d0pnpyQE7UE2YxNjN9YPw/MOaYAkShMTMrenwiF 4mJrWUZ6loAt0E813DuOeROtJPvLWQyN5ucwb+AkQ+kBMGav+Wkx6g+iU89upRiK684n Z/4vfg+S/Nt8hIz2Wa5gjkfUFnBj6gkm8LBKpIYj9kDcnPj4iF1NhPS8pYLAenJt+Y2U RsUpc+zmGNHJZq5luhp+ua1eICOvDgG9KeU9zLVpRb4DWnQBcsK9uQcdRBxkuje2XlJR gt7t+nKnvK+OfHxSR5kk1zy0ga2/KDH/Yqs7MoOBVig1ieNZqxsGTAdva0dlFM7RN6v4 vDIA== 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=cJN+8dElN1tSGuueT5lXKGUY3fdJD9zCAhOJwZpc+Ho=; b=VUmMG2L51nOWvanJstSqvGtaidUD1Nuv5YzkuqGCTHUM+rtkflX/69WZ8fUwfnQof2 OzI2Mz/TcPeK+5hLFI6BcCfcLiu9fzjymHVYqpqo4Ny1YV2ahnh7C8wW3COmuUUAHG4b 7lt8RLeghblX08S1wV1Zz9tgQ9uO/BmuMidk0XYDXExPIivnCHsW/3uvVkIIq9ML/+C7 2hEgvo3kqWgKkcRMGeBaZ2XnGD794sER/T3THN1zUD6hVVuClIISk297VeedEsjDGMSK qqTbqqzAXnPOB6D2Nghwc6ZpuXQ56zmreuQcQ+EPI+FTdJoPcKdoTXTy3UYmyA1iUgVT XmCQ== 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 a33si1898722pld.123.2019.04.18.04.04.52; Thu, 18 Apr 2019 04:05:08 -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 S2388572AbfDRLEB (ORCPT + 99 others); Thu, 18 Apr 2019 07:04:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:36994 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728074AbfDRLEA (ORCPT ); Thu, 18 Apr 2019 07:04:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3BC43B01F; Thu, 18 Apr 2019 11:03:59 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 65A431E15AE; Thu, 18 Apr 2019 13:03:56 +0200 (CEST) Date: Thu, 18 Apr 2019 13:03:56 +0200 From: Jan Kara To: Al Viro Cc: Khazhismel Kumykov , 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: <20190418110356.GC28541@quack2.suse.cz> References: <94eb2c0ce3aa7551d30569658325@google.com> <96c750b3-fcb0-3d7f-45eb-45459078ef83@I-love.SAKURA.ne.jp> <20190415235428.GS2217@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190415235428.GS2217@ZenIV.linux.org.uk> 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 Tue 16-04-19 00:54:28, Al Viro wrote: > 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... Yes, Alexander Lochman has sent a patch to silence this warning back in February [1] by just bailing out from file_remove_privs() for non-regular files. But so far you've ignored that patch... Will you pick it up please? Honza [1] https://lore.kernel.org/lkml/cbdc8071-de76-bb0a-6890-15ef21023a70@tu-dortmund.de -- Jan Kara SUSE Labs, CR