Messages in this thread | | | Date | Tue, 4 Sep 2007 18:45:23 +0200 | From | "anon... anon.al" <> | Subject | Re: Race condition: calling remove_proc_entry in cleanup_module (module_exit) while someone's using procfile |
| |
On 9/4/07, anon... anon.al <anon.asdf@gmail.com> wrote: <snip> > If yes: which mechanism can be used?
I was thinking about using an atomic counter in procfile_write
proc_f = create_proc_entry(PROC_FILE_NAME, 0644, NULL); //... proc_f->write_proc = procfile_write;
int procfile_write(struct file *filp, const char *buffer, \ unsigned long len, void *data) { //"StackXXX" atomic_inc(&cnt_procfile_users);
printk(KERN_ALERT "Hi there!\n");
atomic_dec(&cnt_procfile_users); wake_up_interruptible(&queue); return len; }
and then in cleanup_module using:
wait_event_interruptible(queue, \ ( \ spin_lock_irqsave(&lock, flags), \ cnt = atomic_read(&cnt_procfile_users), \ ((cnt == 0) \ ? 1 \ : (spin_unlock_irqrestore(&lock, flags), 0))\ )); remove_proc_entry(PROC_FILE_NAME, &proc_root); spin_unlock_irqrestore(&lock, flags);
But: x1) Could it happen that code is already in function procfile_write at "StackXXX" (before atomic_inc(&cnt_procfile_users)) when the scheduler switches to another task?? ((Or is the "entering into a function, up to the function's first statement" atomic??))
x2) Could it happen that the scheduler switches, after atomic_dev(&cnt_procfile_users) but before return len??
If so, then it could happen that we're in spin_lock_irqsave, while someone else is still using the procfile; and then this code still fails miserably. ?
Regards -Albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |