Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Karen Xie <kxie@...>
Cc: <netdev@...>, <open-iscsi@...>, <linux-scsi@...>, <linux-kernel@...>, <jgarzik@...>, <davem@...>, <michaelc@...>, <swise@...>, <rdreier@...>, <daisyc@...>, <wenxiong@...>, <bhua@...>, <divy@...>, <dm@...>, <leedom@...>, <kxie@...>
Date: Friday, August 22, 2008 - 3:48 pm

On Fri, 22 Aug 2008 11:40:56 -0700
Karen Xie <kxie@chelsio.com> wrote:


I'm going to suggest that this not be merged in this form due to the
__GFP_NOFAIL issues identified below.


Please use scripts/checkpatch.pl. It finds things which should be fixed.


Only three of the five fields were documented.


We got bored of documenting, I see ;)


It's a shame, because documenting the data structures is very useful. 
More important than documenting code flow, for example.


Far too large to inline, has only one call site.  Can be made static
non-inline in cxgb3i_iscsi.c.


I'd suggest that the version number just be removed.  It becomes
meaningless (and often misleading) once a driver is in the mainline
kernel.  People will update the driver without changing the version
number.  Code external to the driver but which affects it can change.

The kernel version identifier is really the only way in whcih you and
your support people can reproduce a user's code.


Ditto.


This is normally done at module_init() time.


It is conventional to put a single blank line between end-of-locals and
start-of-code.


like that.


Is this racy?  We look up a device then return it after having unlocked
the lock.  The caller of this fucntion is handed a pointer to a think
which can now be freed by cxgb3i_adapter_remove().


Can `hba' really be NULL here?


Can hba->shost really be NULL here?


hm, I'm surprised that networking doesn't provide a neater, typesafe
way of converting a sockaddr to a sockaddr_in.  union, anonymous union
or even a plain old inlined C function.  Casts are dangerous.


dd_data is void*, so no cast is needed.

The unneeded cast is actually a little bit dangerous because it
suppresses a compiler warning which we'd get if dd_data has any type
other than cxgb3i_endpoint* or void*.



Please check the whole patch for unneeded casts of void*.


	if (cconn && cconn->conn) {
		struct iscsi_conn *conn = cconn->conn;
		struct iscsi_tcp_conn *tcp_conn = conn->dd_data;

		write_lock_bh(&cep->c3cn->callback_lock);
		cep->c3cn->user_data = NULL;
		set_bit(ISCSI_SUSPEND_BIT, &conn->suspend_rx);
		cconn->cep = NULL;
		tcp_conn->sock = NULL;
		write_unlock_bh(&cep->c3cn->callback_lock);
	}

is easier to read, no?


Code uses a mixture of uint16_t and u16.

u16 is usually preferred for in-kernel work.


cast..


you forgot the typecast :)


This looks a bit bizarre.  We somehow got a `struct iscsi_tcp_conn' and
a 'struct cxgb3i_conn' laid out contiguously in memory?  I don't think
I want to know how that happened, but it can all be done very nicely
using the C type system, rather than abusing it.


Is this covering up a bug?


erk.

Yes, it happens.  We should provide this in core kernel.  We shouldn't
be open-coding it in a remote driver.


y:/usr/src/linux-2.6.27-rc4> grep -r VMALLOC_START drivers | wc -l
1

Now it's two.  That's a big hint that something is wrong here.


This function is odd.  cpl_handlers[] is already all-zeroes, so why are
we rezeroing it all?

The function has no callers so I'm at a loss.


That's DIV_ROUND_UP().


__GFP_NOFAIL is unusual.  Should be commented, or removed.  Preferably
removed - __GFP_NOFAIL is a hack for callsites which haven't been fixed
yet.


This callsite should be fixed.  Allocations can fail.


dittoes


ug.  All this nofail stuff seems to go pretty deep.  Sorry, but it all
should go away and the driver should be coded to handle allocation
failures.


(attention span ran out, sorry)
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver, Karen Xie, (Fri Aug 22, 2:40 pm)
Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver, Andrew Morton, (Fri Aug 22, 3:48 pm)
Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver, Divy Le Ray, (Sat Aug 23, 3:31 pm)
Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver, David Miller, (Sat Aug 23, 4:28 am)
Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver, David Miller, (Sat Aug 23, 5:29 am)