On Tue, 2010-06-15 at 18:31 -0400, andros@xxxxxxxxxx wrote: > From: Andy Adamson <andros@xxxxxxxxxx> > > _nfs41_proc_sequence() kmallocs the calldata but does not set > calldata->res.slotid to NFS4_MAX_SLOT_TABLE, so nfs41_sequence_prepare() calls > nfs41_setup_sequence() with the res.sr_slotid set to a random value. > If nfs41_setup_sequence() sees res.sr_slotid as not set to NFS4_MAX_SLOT_TABLE, > it returns without actually setting up the sequence. Looks like a typo in my patch "NFSv41: Fix a memory leak in nfs41_proc_async_sequence()". I'll squash your patch into that. Please note that you will have to rebase if you try to pull the nfs-for-2.6.36 branch again. Now.... With that said, do we really need to allow RPC calls to call nfs41_setup_sequence with an initialised slotid? This initialisation is a serious hassle, and is easy to forget. When do we expect to end up hitting the res.sr_slotid != NFS4_MAX_SLOT_TABLE condition in real life? Cheers Trond -- 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
