On Sun, May 27, 2012 at 04:30:24PM -0400, Chuck Lever wrote:
> Hi-
>
> On May 25, 2012, at 7:30 PM, Chuck Lever wrote:
>
> > On May 25, 2012, at 9:46 AM, J. Bruce Fields wrote:
> >
> >> If you think it's worth checking for those buggy client cases, we could
> >> instaed check that stateid->si_opaque.so_clid and cl->clientid agree.
> >> That'd cover the special-stateid checks too.
> >
> > That's interesting. I can redrive this patch with this change.
>
> Doesn't a positive find_stateid(cl, stateid) result guarantee that so_clid and clientid are the same?
No, it only looks at the si_opaque.so_id, and assumes this stateid
belongs to the given client. The passed-in client was actually
extracted from the sequence at the start of the compound:
nfsd4_sequence(...)
{
...
session = find_in_sessionid_hashtbl(&seq->sessionid);
...
cstate->session = session;
}
nfsd4_free_stateid(...)
{
struct nfs4_client *cl = cstate->session->se_client;
...
... nfs4_validate_stateid(cl, &stateid->ts_id_stateid);
}
So in theory a confused client sent a free_stateid referencing a stateid
that belonged to a client other than the one that the session belonged
to, and then we'd see this inconsistency.
--b.
--
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
