All of lore.kernel.org
 help / color / mirror / Atom feed
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 */


             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.