[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5d0ee8c54ec2f80cb71cd72e3b4aec3@manguebit.com>
Date: Mon, 25 Mar 2024 17:47:16 -0300
From: Paulo Alcantara <pc@...guebit.com>
To: Al Viro <viro@...iv.linux.org.uk>, Steve French <smfrench@...il.com>
Cc: Christian Brauner <brauner@...nel.org>, Roberto Sassu
<roberto.sassu@...wei.com>, LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>, CIFS
<linux-cifs@...r.kernel.org>, Christian Brauner <christian@...uner.io>,
Mimi Zohar <zohar@...ux.ibm.com>, Paul Moore <paul@...l-moore.com>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>
Subject: Re: kernel crash in mknod
Al Viro <viro@...iv.linux.org.uk> writes:
> On Mon, Mar 25, 2024 at 11:26:59AM -0500, Steve French wrote:
>
>> A loosely related question. Do I need to change cifs.ko to return the
>> pointer to inode on mknod now? dentry->inode is NULL in the case of mknod
>> from cifs.ko (and presumably some other fs as Al noted), unlike mkdir and
>> create where it is filled in. Is there a perf advantage in filling in the
>> dentry->inode in the mknod path in the fs or better to leave it as is? Is
>> there a good example to borrow from on this?
>
> AFAICS, that case in in CIFS is the only instance of ->mknod() that does this
> "skip lookups, just unhash and return 0" at the moment.
>
> What's more, it really had been broken all along for one important case -
> AF_UNIX bind(2) with address (== socket pathname) being on the filesystem
> in question.
Yes, except that we currently return -EPERM for such cases. I don't
even know if this SFU thing supports sockets.
> 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?
This should be pretty straightforward as it would only require an extra
query info call and then {smb311_posix,cifs}_get_inode_info() ->
d_instantiate(). We could even make it a single compound request of
open/write/getinfo/close for SMB2+ case.
Powered by blists - more mailing lists