All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Hockin <thockin@sun.com>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, viro@parcelfarce.linux.theplanet.co.uk,
	Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: PATCH - raise max_anon limit
Date: Wed, 11 Feb 2004 17:08:22 -0800	[thread overview]
Message-ID: <20040212010822.GP9155@sun.com> (raw)
In-Reply-To: <20040211164233.5f233595.akpm@osdl.org>

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.

> > 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. :)

-- 
Tim Hockin
Sun Microsystems, Linux Software Engineering
thockin@sun.com
All opinions are my own, not Sun's

  parent reply	other threads:[~2004-02-12  1:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06 22:15 PATCH - raise max_anon limit Tim Hockin
2004-02-07  8:55 ` Andrew Morton
2004-02-07  9:48   ` viro
2004-02-11 20:33     ` Tim Hockin
2004-02-11 20:38       ` Linus Torvalds
2004-02-11 21:09         ` Tim Hockin
2004-02-11 21:53           ` Andrew Morton
2004-02-11 22:28             ` Tim Hockin
2004-02-11 22:48               ` Andrew Morton
     [not found]                 ` <20040211233852.GN9155@sun.com>
     [not found]                   ` <20040211155754.5068332c.akpm@osdl.org>
     [not found]                     ` <20040212003840.GO9155@sun.com>
     [not found]                       ` <20040211164233.5f233595.akpm@osdl.org>
2004-02-12  1:08                         ` Tim Hockin [this message]
2004-02-12  1:20                           ` Andrew Morton
2004-02-12  2:22                             ` Tim Hockin
2004-02-12 17:26                             ` Jim Houston
2004-02-12 18:49                               ` Tim Hockin
2004-02-13  2:01                                 ` Jamie Lokier
2004-02-12 22:03                               ` Andrew Morton
2004-02-13  1:12                                 ` George Anzinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040212010822.GP9155@sun.com \
    --to=thockin@sun.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.