Re: PATCH - raise max_anon limit

[Andrew Morton]

Tim Hockin <thockin@xxxxxxx> wrote:
>
> On Wed, Feb 11, 2004 at 04:42:33PM -0800, Andrew Morton wrote:
> On Wed, Feb 11, 2004 at 04:42:33PM -0800, Andrew Morton wrote:
> > > Indeed.  MKDEV() already masks off the high order stuff, so that is OK.
> >_
> > That means that we've lost the original idr key and can no longer remove
> > the thing, doesn't it?
> 
> No, it doesn't store the counter with the id.  They expect you to do that.
> My best understanding is that thi sis to prevent re-use of the same key.
> I'm not sure I grok why it is useful.  If you release a key, it should be
> safe to reuse.  Period.  I assume there was some use case that brought about
> this "feature" but if so, I don't know what it is.  The big comment about it
> is just confusing me.

Maybe Jim can tell us why it's there.  Certainly, the idr interface would
be more useful if it just returned id's which start from zero.


> > > On idr_get_new(), we can just check for
> > > 	dev & ((1<<MINORBITS)-1) == (1<<MINORBITS)-1)
> > > and return -EMFILE.
> > >_
> > > That combined with a gfp mask to idr and the assumption that idr's
> > > counter
> > > won't ever grow beyond (sizeof(int)*8 - MINORBITS) (12) bits
> > >_
> > > Shall I whip that up and test it?  Do you prefer a gfp mask to idr_init
> > > that
> > > sticks around for all allocations or a GFP mask to idr_pre_get?
> 
> Offer repeated. :)

Please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/