On 9/4/07, anon... anon.al <anon.asdf@gmail.com> wrote: <snip>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 -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
