On 01/18/2013 01:33 PM, Chuck Lever wrote:
On Jan 18, 2013, at 4:28 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
Any chance the STALE_CLIENTID case needs a 'break'?
I don't think so. LEASE_CONFIRM is set, and we want to wake the state renewal thread.
Twice I've seen kernel crashes after the nfs40_walk_client_list
failed (though code comments say it should never fail).
nfs40_walk_client_list() is looking for an nfs_client that is supposed to already be in the nfs_client list. If the search fails, that's a bug.
Eyeball the contents of your nfs_client list. You should find an appropriate nfs_client in there, and then figure out why the search doesn't find it.
Ok, I think I found another issue.
nfs4_client_init does not initialize 'old', but passes it to nfs4_discover_server_trunking.
That gets passed to the detect_trunking operation, which is nfs40_discover_server_trunking
or nfs41_discover_server_trunking.
This will call walk_client_list, which also may not ever assign a value to
'result'.
The code in walk_client_list always dereferences result, however.
So, that is probably why my system blows up shortly after the 'impossible'
error message...
Maybe initialize result to NULL in nfs4[10]_walk_client_list and properly check
for null result in calling code?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
