From: Rusev <arusev@dev.rtsoft.ru>
To: linux-kernel@vger.kernel.org
Subject: JBD-DEBUG /proc/sys entry (again)
Date: Thu, 04 Oct 2007 16:28:07 +0400 [thread overview]
Message-ID: <4704DC57.9040001@dev.rtsoft.ru> (raw)
All that should be moved to DEBUGFS under /sys/kernel/debug and so on
- that's right, a bit other issue
is of interest for me.
My suggestion is that a few other problems with PROCFS exist:
>From my observation there are two major issues are involved:
1. /proc/sys entry has very specific readdir operation (vs. other
entries such as /proc/drivers and others)
entries to /proc/sys is likely is to be performed by means of other API.
(quick search found thet API explanation for 2.4.xx
http://www.opentech.at/papers/embedded_proc/node33.html,
yet it looks to be a little change in 2.6)
2. function xlate_proc_name behaves not the way it specified in it's
header comment:
[1] minor issue is that proc_match wolud likely return "equals"
as result of comparison of "sys" and "sysvipc"
[2] more significant issue is that it can't properly walk long
paths such as /proc/sys/jbd/jbd-debug,
but only paths likes /proc/sys/jbd-debug (just one step
down, path walking is broken).
This way we can't add not only /proc/sys/jbd/jbd-debug but any path
likes /proc/aaa/bbb/xxx-debug at one step.
The entry /proc/sys is still specific, because even if fixing
xlate_proc_name we can't see /proc/sys/jbd/jbd-debug
in userspace and successfully see /proc/aaa/bbb/jbd-debug.
That's because /proc/sys specific operator readdir blocks such PROCFS
entries that they are NOTproperly registersd
with CTL_TABLE.
Yet I think that we have a general problem with
adding-long-paths-in-one-step, which is addressed by the following patch:
diff -uprN linux-2.6.21.orig/fs/proc/generic.c
linux-2.6.21/fs/proc/generic.c
--- linux-2.6.21.orig/fs/proc/generic.c 2007-09-13 15:36:07.000000000 +0400
+++ linux-2.6.21/fs/proc/generic.c 2007-10-03 22:12:57.000000000 +0400
@@ -298,6 +298,7 @@ static int xlate_proc_name(const char *n
int len;
int rtn = 0;
+
spin_lock(&proc_subdir_lock);
de = &proc_root;
while (1) {
@@ -305,24 +306,52 @@ static int xlate_proc_name(const char *n
if (!next)
break;
- len = next - cp;
- for (de = de->subdir; de ; de = de->next) {
- if (proc_match(len, cp, de))
- break;
- }
- if (!de) {
- rtn = -ENOENT;
- goto out;
- }
- cp += len + 1;
- }
+ ++next;
+
+
+ len = next - cp;
+
+ if(de->subdir == NULL){
+ /* directory "de" is empty, add myself to it now */
+ char* my_name = kzalloc( (len - 1) + 1, GFP_KERNEL);
+ memcpy(my_name, cp, len - 1);
+ proc_mkdir(my_name,de);
+ kfree(my_name);
+ }
+
+
+ struct proc_dir_entry *parent_de = de;
+ for (de = parent_de->subdir; de ; de = de->next) {
+ if (proc_match(len - 1, cp, de))
+ break;
+
+ }
+
+ if(de == NULL){
+ /* we found no appropriate subdirectory, well create
it now */
+ char* my_name = kzalloc( (len - 1) + 1, GFP_KERNEL);
+ memcpy(my_name, cp, len - 1);
+ de = proc_mkdir(my_name,parent_de);
+ kfree(my_name);
+ }
+
+
+
+ if (!de){
+ rtn = -ENOENT;
+ goto out;
+ }
+ cp += len;
+ }
*residual = cp;
*ret = de;
out:
spin_unlock(&proc_subdir_lock);
return rtn;
+
}
+
static DEFINE_IDR(proc_inum_idr);
static DEFINE_SPINLOCK(proc_inum_lock); /* protects the above */
next reply other threads:[~2007-10-04 13:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 12:28 Rusev [this message]
2007-10-04 22:46 ` JBD-DEBUG /proc/sys entry (again) Jose R. Santos
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=4704DC57.9040001@dev.rtsoft.ru \
--to=arusev@dev.rtsoft.ru \
--cc=linux-kernel@vger.kernel.org \
/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