On Thu, 2 Jul 2015 17:45:35 +0100 Al Viro <v...@zeniv.linux.org.uk> wrote:
> On Thu, Jul 02, 2015 at 08:07:38AM -0400, Jeff Layton wrote: > > > Erm...and why is it passing in '0' to idr_alloc for the end value if it > > can't deal with more than 16 bits? That seems like a plain old bug... > > Because they are using the same function (with different pool, obviously) > for FID allocation, and those are 32bit... Ahh, right... So p9_idpool_create should take an argument for the "end" value, and then store that in a new field in p9_idpool. Then they can pass that in as the "end" parm in idr_alloc. Or, they could give up using the same function there and use a different one for tags and FIDs. In any case...allowing this thing to allocate tag values that can collide seems fundamentally wrong. Using idr_alloc_cyclic might also not hurt either, particularly given that these tag values are supposed to function something like an XID and you probably don't want to be reusing them too quickly. -- Jeff Layton <jlay...@poochiereds.net> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
