On Wed, Nov 07, 2007 at 02:45:18PM -0800, Kok, Auke wrote:
> [adding netdev, jeff G to the Cc]
>
> Linas Vepstas wrote:
> > On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote:
> >> Linas Vepstas wrote:
> >>> If a PCI bus error is encountered during device open, the
> >>> error recovery routines will attempt to close the device.
> >>> If napi has not yet been enabled, the napi disable in the
> >>> close will hang.
> >>>
> >>> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
> >>>
> >>> ----
> >>> The "elegence" of this solution is arguable: one could
> >>> say its "better" to perform this check in e1000_down().
> >>> However, doing so will disrupt a commonly used path,
> >>> whereas here, the hack is in the infrequently used
> >>> error path, and thus less intrusive.
> >>>
> >>> drivers/net/e1000/e1000_main.c | 9 ++++++++-
> >>> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >> I think this is OK, but it's quite awful looking if you ask me.
> >
> > Yeah, ...
> >
> > There are several alternatives: below are two. If you
> > find one to be more appealing.. could you use it? Consider them
> > to be "signed-off-by"; I have not actually compiled or tested
> > either of them.
>
> I'm not a particular fan of putting extra state tracking in the driver for
> something we could extract from the napi subsystem already.
>
> Jeff, Stephen, can't we have a generic napi_enabled() inline in netdevice.h
> that
> tests for NAPI_STATE_SCHED ?
Like this?
include/linux/netdevice.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: linux-2.6.23-rc8-mm1/include/linux/netdevice.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/include/linux/netdevice.h 2007-09-26
15:07:05.000000000 -0500
+++ linux-2.6.23-rc8-mm1/include/linux/netdevice.h 2007-11-07
17:14:50.000000000 -0600
@@ -384,6 +384,18 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+/**
+ * napi_enabled_p - return non-zero if napi enabled
+ * @n: napi context
+ *
+ * Mnemonic: _p stands for "predicate", returning a yes/no
+ * answer to the question.
+ */
+static inline int napi_enabled_p(struct napi_struct *n)
+{
+ return !test_bit(NAPI_STATE_SCHED, &n->state);
+}
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
> I wonder if there isn't something in the PCI error recovery missing the point
> and
> we can solve this problem better for all drivers somehow.
Well, there's also scsi, which doesn't use napi :-)
For the most part, error recovery is a fairly cut-n-paste
set of steps. However, I don't quite have enough confidence
to say "yea verily, all network adapters will use these
same steps."
--linas
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
