[patch] procfs: returns ENOENT on opening the being-removed proc entry

From: "FJCL) 荻野 大輔 "
Date: Thu Jun 23 2011 - 21:48:36 EST


From: Daisuke Ohino <ogino.daisuke@xxxxxxxxxxxxxx>

opening the proc entry may return EINVAL if the entry is being removed, for
example open("/proc/bus/pci/XX/YY") during the corresponding device is being
hot-removed. The return value is inappropriate and should return ENOENT.

This return value comes from proc_reg_open().

fs/proc/inode.c:
-----------------------------------------------------------
static int proc_reg_open(struct inode *inode, struct file *file)
{
(snip)
if (!pde->proc_fops) {
spin_unlock(&pde->pde_unload_lock);
kfree(pdeo);
return -EINVAL;
}
(snip)
-----------------------------------------------------------

pde->proc_fops is NULL iff the proc entry is being removed. It
is set by remove_proc_entry().

-----------------------------------------------------------
void remove_proc_entry(const char *name, struct proc_dir_entry*parent)
{
(snip)
/*
* Stop accepting new callers into module. If you're
* dynamically allocating ->proc_fops, save a pointer somewhere.
*/
de->proc_fops = NULL;
(snip)
-----------------------------------------------------------

But POSIX says:

-----------------------------------------------------------
[EINVAL]
The implementation does not support synchronized I/O for this file.
-----------------------------------------------------------

Since removing proc entry is apparently not related to synchronized I/O,
this function should return ENOENT in this case.

Signed-off-by: Daisuke Ogino <ogino.daisuke@xxxxxxxxxxxxxx>
---
fs/proc/inode.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 74b48cf..7ed72d6 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -319,7 +319,7 @@ static int proc_reg_open(struct inode *inode, struct file *file)
if (!pde->proc_fops) {
spin_unlock(&pde->pde_unload_lock);
kfree(pdeo);
- return -EINVAL;
+ return -ENOENT;
}
pde->pde_users++;
open = pde->proc_fops->open;
--

Since I don't subscribe LKML, please Cc me if you have any comment.

Thanks,
Daisuke


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/