From: Al Viro <viro@zeniv.linux.org.uk>
To: yikangy2@illinois.edu
Cc: mikulas@artax.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org,
shaobol2@illinois.edu, yiruiz2@illinois.edu, jianh@illinois.edu
Subject: Re: [PATCH] fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink
Date: Sun, 4 May 2025 04:23:55 +0100 [thread overview]
Message-ID: <20250504032355.GB2023217@ZenIV> (raw)
In-Reply-To: <20250504014433.120804-1-yikangy2@illinois.edu>
On Sat, May 03, 2025 at 08:44:34PM -0500, yikangy2@illinois.edu wrote:
> From: Yikang Yue <yikangy2@illinois.edu>
>
> The function call new_inode() is a primitive for allocating an inode in memory,
> rather than planning disk space for it. Therefore, -ENOMEM should be returned
> as the error code rather than -ENOSPC.
>
> To be specific, new_inode()'s call path looks like this:
> new_inode
> new_inode_pseudo
> alloc_inode
> ops->alloc_inode (hpfs_alloc_inode)
> alloc_inode_sb
> kmem_cache_alloc_lru
>
> Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM),
> not a lack of disk space. However, the current implementation of
> hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails.
> This patch fix this by set err to -ENOMEM before the goto statement.
>
> BTW, we also noticed that other nested calls within these four functions,
> like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure.
> But similarly, only -ENOSPC is returned. Addressing these will involve code
> modifications in other functions, and we plan to submit dedicated patches for these
> issues in the future. For this patch, we focus on new_inode().
Frankly, that amount of boilerplate is begging for a helper function...
next prev parent reply other threads:[~2025-05-04 3:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-04 1:44 [PATCH] fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink yikangy2
2025-05-04 3:23 ` Al Viro [this message]
2025-05-28 21:36 ` Yikang Yue
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=20250504032355.GB2023217@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=jianh@illinois.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=shaobol2@illinois.edu \
--cc=yikangy2@illinois.edu \
--cc=yiruiz2@illinois.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox