From: Jan Kara <jack@suse.cz>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Khazhismel Kumykov <khazhy@google.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzbot <syzbot+2b74da47f048a5046135@syzkaller.appspotmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
syzkaller-bugs@googlegroups.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: WARNING in notify_change
Date: Thu, 18 Apr 2019 13:03:56 +0200 [thread overview]
Message-ID: <20190418110356.GC28541@quack2.suse.cz> (raw)
In-Reply-To: <20190415235428.GS2217@ZenIV.linux.org.uk>
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 <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2019-04-18 11:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 7:40 WARNING in notify_change syzbot
2018-06-11 10:33 ` Tetsuo Handa
2019-04-15 23:20 ` Khazhismel Kumykov
2019-04-15 23:54 ` Al Viro
2019-04-18 11:03 ` Jan Kara [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190418110356.GC28541@quack2.suse.cz \
--to=jack@suse.cz \
--cc=khazhy@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+2b74da47f048a5046135@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.