Nonblocking call may block in a mutex? Nonblocking call after poll may fail?
Hi! This is a driver-related question on non-blocking writes and poll. Setup: there is a single output-buffer (in kernel-space) of 24 bytes for writes from all processes A, B, and C: each process is restricted to use at most 8 bytes: 8*3 = 24 (until that data is handled (interrupt-handler...)) Question: If this output-buffer has "4-bytes space remaining for process A", then a non-blocking write of process A could still encounter a locked mutex, if process B is busy writing to the output-buffer. Should process A now block/sleep until that mutex is free and it can access the output-buffer (and it's 4 bytes space)? What about a non-blocking (write-) poll of process A: if the poll call succeeds (the output buffer has space remaining for process A), and process A now performs a non-blocking write: what happens if A encounters a blocked mutex, since process B is busy writing to the output-buffer. a) Should A block until the mutex is available? b) Should A return -EAGAIN, even though the poll call succeeded? c) Should it be impossible for this to happen! i.e. -> should process A already "have" the mutex in question, when the poll call succeeds (thus preventing B from writing to the output buffer) For c) What if process A "has" the mutex, but never does the non-blocking write. Then no process can write, since the mutex is held by process A... I'll appreciate any answer, or pointer to relevant information. Thanks Albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nonblocking call may block in a mutex? Nonblocking call after poll may fail?
On Aug 31, 2:20 pm, "anon... anon.al" <[EMAIL PROTECTED]> wrote:
> Setup:
> there is a single output-buffer (in kernel-space) of 24 bytes for
> writes from all processes A, B, and C: each process is restricted to
> use at most 8 bytes: 8*3 = 24
> (until that data is handled (interrupt-handler...))
>
> Question:
> If this output-buffer has "4-bytes space remaining for process A",
> then a non-blocking write of process A could still encounter a locked
> mutex, if process B is busy writing to the output-buffer.
>
> Should process A now block/sleep until that mutex is free and it can
> access the output-buffer (and it's 4 bytes space)?
Yes, it should sleep until the mutex is free.
This can be seen from a code snippet in LDD3 (Linux Device Drivers,
3rd ed.), on page 153:
http://lwn.net/images/pdf/LDD3/ch06.pdf#page=19&zoom=80,0,450
The code snippet in LDD3 does not contain the following before the while loop:
if (filp->f_flags & O_NONBLOCK) {
if (down_trylock(&dev->sem)) {
return -EAGAIN;
}
}
So a non-blocking process can also sleep (in down) if this type of
mutex is locked. It may however not block if the output-queue is full.
>
> What about a non-blocking (write-) poll of process A: if the poll call
> succeeds (the output buffer has space remaining for process A), and
> process A now performs a non-blocking write: what happens if A
> encounters a blocked mutex, since process B is busy writing to the
> output-buffer.
> a) Should A block until the mutex is available?
> b) Should A return -EAGAIN, even though the poll call succeeded?
> c) Should it be impossible for this to happen! i.e. -> should process
> A already "have" the mutex in question, when the poll call succeeds
> (thus preventing B from writing to the output buffer)
>
> For c) What if process A "has" the mutex, but never does the
> non-blocking write. Then no process can write, since the mutex is held
> by process A...
>
It cannot be b) (same reasoning as above).
But is it a) or c)...?
Regards,
Albert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
memory barrier to ensure copy_to_user() completes
Hi! a) Which memory barrier do I require if I need to ensure that a copy_to_user(dest, src, len) completes before the next statement? copy_to_user(dest, src, len) ; //rmb(); OR wmb(); OR barrier(); OR mb(); ?? //next statement; I'm guessing: Use rmb() to be sure that all of src is in registers, before continuing. Use wmb() to be sure that all of src is actually written to dest memory, before continuing. ? b) If I'm writing to hardware, and need to ensure the correct order, I'll use wmb(), right? e.g.: #define HW_address1 20 #define HW_address2 40 *((int *)HW_address1) = 0x0001; wmb(); // is this good??? *((int *)HW_address2) = 0x0010; Thanks - Albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Race condition: calling remove_proc_entry in cleanup_module (module_exit) while someone's using procfile
Hi!
There is a race condition if an instance is executing "__exit
device_exit" and calls remove_proc_entry, while someone is still using
the procfile, right?.
static void __exit device_exit(void)
{
// what if the procfile is still in use?
remove_proc_entry(PROC_FILE_NAME, &proc_root);
}
To remove this race condition, the code in "__exit device_exit" must
a) be sure that no other instance is in procfile functions
b) call remove_proc_entry before any other instance accesses the procfile
*** Is this at all possible if a race-condition is to be avoided?
If yes: which mechanism can be used?
Thanks -Albert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Race condition: calling remove_proc_entry in cleanup_module (module_exit) while someone's using procfile
On 9/4/07, anon... anon.al <[EMAIL PROTECTED]> wrote:
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Race condition: calling remove_proc_entry in cleanup_module (module_exit) while someone's using procfile
On 9/4/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > For regular proc files, this is fixed in 2.6.23-rc1 and later. Thanks! I see you've been working on it: fix-rmmod-read-write-races-in-proc-entries... http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/broken-out/ (( older relevant posts: http://groups.google.com/group/linux.kernel/browse_thread/thread/4c74bbea17727e6e/809c15bd0e6fa8f9? http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/fb03e1a500fcb258/563a7f11acdec992? )) Thanks, Albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
