Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754114AbbGBRCN (ORCPT ); Thu, 2 Jul 2015 13:02:13 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:36851 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753732AbbGBRBq (ORCPT ); Thu, 2 Jul 2015 13:01:46 -0400 Date: Thu, 2 Jul 2015 13:01:39 -0400 From: Jeff Layton To: Al Viro Cc: Andrey Ryabinin , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [git pull] vfs part 2 Message-ID: <20150702130139.35e01106@tlielax.poochiereds.net> In-Reply-To: <20150702164535.GM17109@ZenIV.linux.org.uk> References: <20150701062752.GC17109@ZenIV.linux.org.uk> <55939BE3.6040902@samsung.com> <20150701082753.GD17109@ZenIV.linux.org.uk> <5593A7A0.6050400@samsung.com> <20150701085507.GE17109@ZenIV.linux.org.uk> <5593CE37.4070307@samsung.com> <20150701184408.GF17109@ZenIV.linux.org.uk> <20150702032042.GA32613@ZenIV.linux.org.uk> <20150702080026.1c32f1c7@tlielax.poochiereds.net> <20150702080738.615e1c52@tlielax.poochiereds.net> <20150702164535.GM17109@ZenIV.linux.org.uk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1290 Lines: 31 On Thu, 2 Jul 2015 17:45:35 +0100 Al Viro 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/