From: "Shan Sinha" <sks@alum.mit.edu>
To: <linux-kernel@vger.kernel.org>
Subject: (2.4 question) open_namei hangs
Date: Sun, 9 Nov 2003 20:47:53 -0500 [thread overview]
Message-ID: <001901c3a72c$a8575080$0200a8c0@bombay> (raw)
In-Reply-To: <20031109221546.GA11520%konsti@ludenkalle.de>
Hi everyone-
I know everyone is probably focused on 2.6 right now, but I hope someone
will have the time to answer this question about 2.4.20! I'm extremely
confused, and am not sure what work-around I could employ.
I am trying to read the contents of a file from a kernel thread, spawned
when an LKM is insmod'ed. open_namei appears to hang. The LKM is
something that I created. When I call filp_open("/mydirectory",
O_RDONLY, 0), and then subsequently call vfs_readdir on the returned
file *, it traverses the files in the directory correctly.
However, in the call back passed to vfs_readdir, if I try to do a
filp_open("/mydirectory/file1"), where "file1" is the string passed to
the call back, filp_open appears to hang somewhere inside open_namei (I
verified this by modifying filp_open).
But! if I do "touch /mydirectory/*" in user space before I insert the
module and spawn my thread, the open and subsequent read for any files
in /mydirectory work fine.
I suspect this is something to do with the files being loaded into the
buffer cache and my doing something incorrectly with respect to being in
a kernel thread. Does anyone have any ideas of what may be happening?
I have included snips of the relevant code below. I guessing my thread
is getting deadlocked somehow when the kernel has to go to disk to fetch
the file. However, I created the code using khttpd as a sample (not
sure if this was a mistake).
Cheers-
Shan Sinha
Network and Mobile Systems
MIT CSAIL
ssinha@nms.mit.edu
------------------------------------------------------------
int my_callback(void * buf, const char * name, int namlen, loff_t
offset,
ino_t ino, unsigned int d_type)
{
// for each file
if (d_type == DT_REG) {
struct file * f;
read_descriptor_t read_desc;
char * file_name = make_file_name("/mydirectory/", name, namlen);
printk(KERN_INFO "loading file: %s\n", file_name);
// WE HANG IN HERE (IF FILES HAVE NOT BEEN LOADED INTO BUFFER
CACHE??)!!!
f = filp_open(file_name, O_RDONLY, 0);
printk(KERN_INFO "opened file: %s\n", file_name);
// Code snipped - set up code for call to do_generic_file_read
// Code snipped - call to do_generic_file_read
kfree(file_name);
}
return 0;
}
// Main daemon thread
int pm_daemon(void * data)
{
DECLARE_WAIT_QUEUE_HEAD(WQ);
sigset_t tmpsig;
daemon_running = 1;
leave_daemon_running = 1;
sprintf(current->comm, "mythread");
daemonize();
/* Code snipped that blocks all signals except SIGKILL and SIGTERM */
/* main loop */
while (leave_daemon_running) {
int signal_counter = 0;
// count the number of files
int num_files = 0;
struct file * f = filp_open("/mydirectory/", O_RDONLY, 0);
vfs_readdir(f, file_counter, &num_files);
// loop through all files
fput(f);
printk(KERN_INFO "Counted files: %d\n", num_files );
f = filp_open("/mydirectory/", O_RDONLY, 0);
vfs_readdir(f, my_callback, NULL);
// code snipped sleep and respond to signals
}
leave_daemon_running = 0;
daemon_running = 0;
return 0;
}
// called on module init
void pm_init(void)
{
if (!daemon_running)
kernel_thread(pm_daemon, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGHAND);
}
prev parent reply other threads:[~2003-11-10 1:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-09 1:12 Weird partititon recocnising problem in 2.6.0-testX Konstantin Kletschke
2003-11-09 2:36 ` Andries Brouwer
2003-11-09 3:49 ` Konstantin Kletschke
2003-11-09 11:58 ` Andries Brouwer
2003-11-09 12:10 ` Stefan Smietanowski
2003-11-09 22:15 ` Konstantin Kletschke
2003-11-09 23:09 ` Konstantin Kletschke
2003-11-10 0:00 ` Andries Brouwer
2003-11-10 1:47 ` Shan Sinha [this message]
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='001901c3a72c$a8575080$0200a8c0@bombay' \
--to=sks@alum.mit.edu \
--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
all inboxes | Powered by JetHome®