Messages in this thread | | | From | Keith Owens <> | Subject | Re: integrity of user-space copy | Date | Sat, 08 May 1999 10:40:32 +1000 |
| |
On Fri, 7 May 1999 15:26:51 -0700 (PDT), "B. James Phillippe" <bryan@terran.org> wrote: >So in general practice, what is the preferred method of transferring data >to user-space if that data is operated on by something like a kernel timer? >For instance, if I have a block of data about 32k in size that is >(potentially) manipulated on timer expiration, what is the best way to >safely copy it to user-space intact?
If you are using copy_to_user and the interrupt driven updates are not "continuous", one option is to maintain separate fields which hold an update count and an update in progress flag. Pseudo code
atomic_t my_update_count = 0; char my_data[32768];
i = atomic_read(&my_update_count); do { copy_to_user(user_addr, my_data, sizeof(my_data)); } while (i != atomic_read(&my_update_count));
The interrupt driven code does atomic_inc(&my_update_count). Your suggestion of disabling interrupts, taking a copy, enabling interrupts and copying to user space has the overhead of an extra 32K copy every time and a reasonably long irq off period which can impact the rest of the kernel. The above pseudo code has an overhead of two atomic_read plus an occasional extra copy and does not disable interrupts.
The only problem with this sort of approach is resource starvation. If interrupt driven updates come faster than you can copy to user space then it loops forever. Mind you, in that situation, a disabled interrupt copy is going to loose interrupts like nobody's business.
ps. The above is not SMP safe, only irq safe. It can be made SMP safe but is more complicated.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |