All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Steve French <smfrench@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	CIFS <linux-cifs@vger.kernel.org>,
	Paulo Alcantara <pc@manguebit.com>,
	Christian Brauner <christian@brauner.io>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Paul Moore <paul@paul-moore.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>
Subject: Re: kernel crash in mknod
Date: Mon, 25 Mar 2024 20:46:07 +0000	[thread overview]
Message-ID: <20240325204607.GX538574@ZenIV> (raw)
In-Reply-To: <20240325195413.GW538574@ZenIV>

On Mon, Mar 25, 2024 at 07:54:13PM +0000, Al Viro wrote:

> Note that cifs_sfu_make_node() is the only case in CIFS where that happens -
> other codepaths (both in cifs_make_node() and in smb2_make_node()) will
> instantiate.  How painful would it be for cifs_sfu_make_node()?
> AFAICS, you do open/sync_write/close there; would it be hard to do
> an eqiuvalent of fstat and set the inode up?  No need to reread the
> file contents (as cifs_sfu_type() does), and you do have full path
> anyway, so it's less work than for full ->lookup() even if you need
> a path-based protocol operations...
> 
> Does that thing have an equivalent of fstat() that would return the
> metadata of opened file?

You do have a FID there, so doing ->query_file_info() just before close,
using the result to build inode (with type and ->i_rdev taken from what
you've been given by the caller) and passing it to d_instantiate() looks
not entirely implausible, but I'm really not familiar with the codebase,
so take that with a cartload of salt.

mknod() usually is followed by lookup of some sort pretty soon, and your
lookup would have to do at least open/sync_read/close just to decode the
device number.  So if anything, *not* setting an inode up during mknod()
is likely to be a pessimization...

If we did it in vfs_mknod() callers, that would be something along the
lines of
	err = vfs_mknod(..., dir, dentry, ...)
	if (err)
		fuck off
	if (unlikely(!dentry->d_inode)) {
		if (d_unhashed(dentry)) {
			struct dentry *d = dir->i_op->lookup(dir, dentry, 0);
			if (unlikely(d)) {
				if (IS_ERR(d)) {
					fuck off, lookup failed
				} else {
					// ->lookup returns a pointer to existing
					// alias *ONLY* for directories; WTF is
					// going on?
					dput(d);
					fuck off, wrong thing created there
				}
			}
			if (!dentry->d_inode)
				fuck off, it hasn't been created
			if (wrong type of dentry->d_inode))
				fuck off, wrong thing created there
			OK, there we go
		} else {
			complain about bogus ->mknod() behavior
			fuck off - it hasn't been created, apparently
		}
	}
at least in net/unix/af_unix.c:unix_bind().  So the minimal change
would be to have your d_drop(dentry) in that codepath followed by
cifs_lookup(<parent inode>, dentry, 0) and checking the result.

But I would very much suspect that fetching metadata by fid before
you close the file would be cheaper than full-blown cifs_lookup()
there.

  reply	other threads:[~2024-03-25 20:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-24  5:00 kernel crash in mknod Steve French
2024-03-24  5:46 ` Al Viro
2024-03-24  6:31   ` Al Viro
2024-03-24 16:50   ` Roberto Sassu
2024-03-24 21:02     ` Al Viro
2024-03-25 16:06     ` Christian Brauner
2024-03-25 17:18       ` Roberto Sassu
2024-03-26 11:40         ` Christian Brauner
2024-03-26 12:53           ` Paul Moore
2024-03-28 10:53           ` Roberto Sassu
2024-03-28 11:08             ` Christian Brauner
2024-03-28 11:24               ` Roberto Sassu
2024-03-28 12:07                 ` Christian Brauner
2024-03-28 13:03                   ` Paul Moore
2024-03-28 12:43                 ` Paul Moore
2024-03-25 17:21       ` Paul Moore
     [not found]       ` <CAH2r5muL4NEwLxq_qnPOCTHunLB_vmDA-1jJ152POwBv+aTcXg@mail.gmail.com>
2024-03-25 19:54         ` Al Viro
2024-03-25 20:46           ` Al Viro [this message]
2024-03-25 20:47           ` Paulo Alcantara
2024-03-25 21:13             ` Al Viro
2024-03-25 21:31               ` Paulo Alcantara
2024-03-25 17:05     ` Paul Moore

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=20240325204607.GX538574@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=christian@brauner.io \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=pc@manguebit.com \
    --cc=roberto.sassu@huawei.com \
    --cc=smfrench@gmail.com \
    --cc=zohar@linux.ibm.com \
    /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.