[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1182804548.5493.216.camel@localhost.localdomain>
Date: Mon, 25 Jun 2007 16:49:08 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ralph Campbell <ralph.campbell@...gic.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Roland Dreier <rdreier@...co.com>, openib-general@...nib.org,
Oleg Nesterov <oleg@...sign.ru>,
Christoph Hellwig <hch@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [POSSIBLE BUG] use of tasklet_unlock in ipath_no_bufs_available
On Mon, 2007-06-25 at 13:37 -0700, Ralph Campbell wrote:
> This was fixed by a patch that Arthur Jones sent out to
> general@...ts.openfabrics.org
Great!
>
> Tue Jun 19 16:42:09 PDT 2007
> [PATCH 17/28] IB/ipath - wait for PIO available interrupt
>
> I imagine that it is working its way into Roland's git tree
> for Linus.
* tasklet_hi_schedule() is called.
- * We clear the tasklet flag now since we are committing to return
- * from the tasklet function.
+ * We leave the busy flag set so that another post send doesn't
+ * try to put the same QP on the piowait list again.
*/
- clear_bit(IPATH_S_BUSY, &qp->s_busy);
- tasklet_unlock(&qp->s_task);
want_buffer(dev->dd);
dev->n_piowait++;
This removes the final use of tasklet_unlock. I'll submit a patch to
remove this from being a public function. So no others think they can
easily get to the internals of a tasklet.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists