It's possible we try to mknod a dentry, which have
already bound to an inode, just skip it.
Signed-off-by: Chen Li <[email protected]>
---
fs/ramfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 9ebd17d7befb..6cb1de521142 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -106,6 +106,8 @@ ramfs_mknod(struct user_namespace *mnt_userns, struct inode *dir,
{
struct inode * inode = ramfs_get_inode(dir->i_sb, dir, mode, dev);
int error = -ENOSPC;
+ if (dentry->d_inode)
+ return -EEXIST;
if (inode) {
d_instantiate(dentry, inode);
--
2.32.0
On Wed, Jun 16, 2021 at 10:53:12AM +0800, Chen Li wrote:
>
> It's possible we try to mknod a dentry, which have
> already bound to an inode, just skip it.
How do you think this could happen?
On Wed, 16 Jun 2021 13:10:25 +0800,
Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 10:53:12AM +0800, Chen Li wrote:
> >
> > It's possible we try to mknod a dentry, which have
> > already bound to an inode, just skip it.
>
> How do you think this could happen?
>
>
Sorry, that's my bad. I noticed unionfs used to do this check in 9c5b4452998c6e670cfde0928b277e9c50d9a676, but not sure is it a must.
On Wed, Jun 16, 2021 at 10:53:12AM +0800, Chen Li wrote:
>
> It's possible we try to mknod a dentry, which have
> already bound to an inode, just skip it.
Caller should have checked may_create(), which includes EEXIST handling.
NAKed-by: Al Viro <[email protected]>
Incidentally, if it ever had been called that way, your variant would
leak inode. Not the main problem, though...
On Wed, 16 Jun 2021 20:16:58 +0800,
Al Viro wrote:
>
> On Wed, Jun 16, 2021 at 10:53:12AM +0800, Chen Li wrote:
> >
> > It's possible we try to mknod a dentry, which have
> > already bound to an inode, just skip it.
>
> Caller should have checked may_create(), which includes EEXIST handling.
> NAKed-by: Al Viro <[email protected]>
Don't know may_create before, thanks!
>
> Incidentally, if it ever had been called that way, your variant would
> leak inode. Not the main problem, though...
>
>