On Wed, 2011-06-22 at 09:40 -0700, Fubo Chen wrote:
> On Tue, Jun 21, 2011 at 6:49 PM, Eddie Wai <[email protected]> wrote:
> > +/**
> > + * bnx2i_percpu_io_thread - thread per cpu for ios
> > + *
> > + * @arg:       ptr to bnx2i_percpu_info structure
> > + */
> > +int bnx2i_percpu_io_thread(void *arg)
> > +{
> > +       struct bnx2i_percpu_s *p = arg;
> > +       struct bnx2i_work *work, *tmp;
> > +       LIST_HEAD(work_list);
> > +
> > +       set_user_nice(current, -20);
> > +
> > +       set_current_state(TASK_INTERRUPTIBLE);
> > +       while (!kthread_should_stop()) {
> > +               schedule();
> > +               spin_lock_bh(&p->p_work_lock);
> > +               while (!list_empty(&p->work_list)) {
> > +                       list_splice_init(&p->work_list, &work_list);
> > +                       spin_unlock_bh(&p->p_work_lock);
> > +
> > +                       list_for_each_entry_safe(work, tmp, &work_list, 
> > list) {
> > +                               list_del_init(&work->list);
> > +                               /* work allocated in the bh, freed here */
> > +                               bnx2i_process_scsi_cmd_resp(work->session,
> > +                                                           
> > work->bnx2i_conn,
> > +                                                           &work->cqe);
> > +                               atomic_dec(&work->bnx2i_conn->work_cnt);
> > +                               kfree(work);
> > +                       }
> > +                       spin_lock_bh(&p->p_work_lock);
> > +               }
> > +               set_current_state(TASK_INTERRUPTIBLE);
> > +               spin_unlock_bh(&p->p_work_lock);
> > +       }
> > +       __set_current_state(TASK_RUNNING);
> > +
> > +       return 0;
> > +}
> 
> This loop looks a little strange to me. If the schedule() call would
> be moved from the top of the outermost while loop to the bottom then
> the first set_current_state(TASK_INTERRUPTIBLE) statement can be
> eliminated. And that also fixes the (theoretical?) race that occurs if
> wake_up_process() gets invoked after kthread_create() but before the
> first set_current_state(TASK_INTERRUPTIBLE) statement got executed.
Thanks Fubo.  Although the aforementioned race condition shouldn't be
much of a concern, however, it is theoretically possible.  I will make
the suggested change to process the work before calling schedule() to
resolve this.
> 
> Fubo.
> 


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to