Thanks Rik,

On Mon, Mar 31, 2008 at 12:16 AM, Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Mar 2008 23:24:50 +0800
>  "Peter Teoh" <[EMAIL PROTECTED]> wrote:
>
>  > Is there any guidelines on when and where can we insert printk() to do
>  > debugging?
>
>  You can use it pretty much anywhere.
>

Ah....so I supposed it updates the memory directly, no I/O is involved
right?   Another daemon will then asynchronously read it from the
memory to write to the system file (/var/log/message*) - correct?
(this operation can sleep.)   So since printk() DOES NOT sleep (as
implied by u) we can pretty use it anywhere?

Thanks in advance for the answer :-).

>
>  > asmlinkage int vprintk(const char *fmt, va_list args)
>  > {
>
>  ...
>
>
>  >         preempt_disable();
>  >         /* This stops the holder of console_sem just where we want him */
>  >         raw_local_irq_save(flags);
>  >
>  > So we can see that printk() MUST NOT BE USED when the kernel is
>  > preempt-disabled, as at the end of printk() it will be enabled again.
>  >
>  > MISUSE scenario:   using printk() INSIDE a spin_lock()-spin_unlock() pair.
>
>  Multiple preempt_disable+preempt_enable sequences can nest, because
>  they simply keep a counter and preemption will not be enabled until
>  the counter reaches zero (the outer-most preempt_disable call).
>

Ok, I am trying to understand this:

spin_lock()-->_spin_lock():

void __lockfunc _spin_lock(spinlock_t *lock)
{
        preempt_disable();
        spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
        LOCK_CONTENDED(lock, _raw_spin_trylock, _raw_spin_lock);
}

For preempt_disable() (linux/preempt.h):

#define preempt_disable() \
do { \
        inc_preempt_count(); \
        barrier(); \
} while (0)

but inc_preempt_count() effectively just increase the
current_thread_info()->preempt_count.

and barrier() just put a barrier to cancel any potential internal CPU
instructions reordering through optimization.   So question is WHERE
IS the preemption disabling?   Ie, "cli" in x86 context?
(but inside spin_acquire(), which called lock_acquire(), there is a
check for irq_disabled(), and therefore the irq disabling must happen
before this spin_acquire(), right?)

>  --
>  All rights reversed.
>

erh.....u mean every time we quote your statements, you will pay us
money?   :-).



 if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
                return 0;



-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ

Reply via email to