On 2011-10-03 16:57, J. Bruce Fields wrote: > On Mon, Oct 03, 2011 at 04:43:40PM +0200, Benny Halevy wrote: >> Bruce, it seems with this patch, doing si_opaque.so_id = current_stateid >> makes all stateid's unique, regardless of their type. >> Is find_stateid_by_type still needed? >> >> And if the opaque part of the stateid isn't unique, >> shouldn't find_stateid_by_type go over the hash bucket by itself >> to look for other stateid's sharing the same opaque but having >> the type it is looking for? > > Stateid's have actually always been unique--they'd have to be, since > e.g. READ doesn't come with any indication of which type of stateid > you're being given. All find_stateid_by_type() does is fail when it > doesn't find something of the right type. > So I'm still confused. That's what I thought. So in what cases find_stateid that find_stateid_by_type calls will find a stateid structure with a non-matching sc_type? Benny > I did think at the time that find_stateid_by_type() was a confusing name > for that reason, but couldn't come up with a better idea. Maybe it > should be find_stateid_of_type() or find_stateid_if_type().... > > --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 -- 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
