Re: schedule_work returns FAILURE (0)

[Andrew Morton <akpm@osdl.org>]

"Ravi Dubey" <ravi.dubey@conexant.com> wrote:
>
> Hi,
> 
> I have ported my USB driver on from Linux Kernel 2.4.20-8 to 2.6.11.12.
> As a part of this porting process, I have replaced the bottom halves
> with work_queues. Now, I am facing problems in the driver execution.
> :-(.
> 
> The schedule_work() function which schedules the work is returning
> FAILURE (0) many times (at least 1 out of 4 times it is called).
> 
> My queries:
> 
> 1. When a work is queued using schedule_work (), does the function (that
> is to be called as bottom half) run at process context OR Interrupt
> context

Process context.

> - The reason why I am getting confused is that in this called
> function, if I print the return value of in_interrupt (), I get 0 (which
> means that is running at process context),

Yup.

> However, if I print the value
> of in_interrupt after I have acquired a spin lock in this function, I
> get the value 256 (which means I am running in interrupt context) ?

Not really.  Bits 8-19 of preempt_count() count the IRQ depth and bits 0..7
count the inc_preempt_count() depth.  If CONFIG_PREEMPT is enabled,
spin_lock() does inc_preempt_count().  See the definitions of
hardirq_count(), softirq_count() and irq_count().

> 2. Why is the schedule_work () function failing.

umm, look at the implementation of schedule_work()?

	if (!test_and_set_bit(0, &work->pending)) {

it's already pending (the scheduled work has not run yet).  You need to
design you schedule_work() caller to queue things up and you need to design
your schedule_work() handler to consume all the thus-far-queued work items.

Just ignore the return value of schedule_work().