On 1 Dec 2002, Michel Dänzer wrote:
>
> Actually, I did that because I thought send_sig_info() or kfree() might
> not be interrupt safe.
Signals are commonly sent from interrupts: kill_fasync() is quite commonly
supported by many device drivers, and the resulting SIGIO is almost
universally sent from an interrupt handler.
Memory freeing is also fine - it's only _allocation_ that is frowned upon
(you can do it, using GFP_ATOMIC, but it's usually a really bad idea. Most
useful for things like network drivers where the loss of a packet due to
out-of-memory conditions is acceptable).
> Does that also apply to kmalloc()/kfree(), or are they safe?
kfree() (or free_pages() or others of that type) is always safe.
kmalloc(x, GFP_ATOMIC) works, but has problems (ie being over-eager about
using it can easily result in a system that just dies from being out of
memory and not being able to do the required memory balancing and
swap-out to replenish it).
The attached patch looked mostly ok, except this part:
- sema_init( &dev->vbl_sem, 0 );
+ spin_lock_irqsave( &dev->vbl_lock, flags );
..
should almost certainly have been a
spin_lock_init(&dev->vbl_lock);
instead of locking and unlocking an uninitialized variable (from what I
could tell from just reading the diff).
Btw, from a testing standpoint it's then also worthwhile compiling with
CONFIG_DEBUG_SPINLOCK, which will verify that spinlocks are initialized
etc.
Linus
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
