public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Chris Wright <chrisw@osdl.org>,
	Arjan van de Ven <arjanv@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [patch] mlock-as-nonroot revisted
Date: Tue, 3 Aug 2004 15:33:35 -0700	[thread overview]
Message-ID: <20040803153335.R1924@build.pdx.osdl.net> (raw)
In-Reply-To: <20040803221121.GN2241@dualathlon.random>; from andrea@suse.de on Wed, Aug 04, 2004 at 12:11:21AM +0200

* Andrea Arcangeli (andrea@suse.de) wrote:
> On Tue, Aug 03, 2004 at 03:01:18PM -0700, Chris Wright wrote:
> > I'm not sure what you mean.  Truncate should only update the accounting,
> > not break the binding, right?
> 
> yep, update the accounting. And with that I meant "releasing" part of
> it (accordingly to the size of the truncate, a truncate(0) should
> release it all).

OK, good.  I thought you meant drop binding to user, rather then reduce
the accounting.

> > It's meant to be done at object destruction.
> 
> where?

I just mean in general the only time it's valid to drop the binding
(which includes dropping refcount on the user struct) should be when
the object is destroyed.

> Maybe it's just that those are incremental patches and I'm missing the
> other part of the patch, but reading those patches I can't see where the
> user_subtract_mlock happens when I truncate an hugetlbfs file (or delete
> it or whatever). Sure it can't be munlock releasing/_updating_ the user-struct
> accounting for fs persistent storage. But if other code takes care of it
> then maybe you want to delete the user_subtract_mlock function and use
> the other piece that already existed for truncate.

Heh, yeah in a place like hugetlb_put_quota?

> Anyways my overall picture of this is that you're trying to do
> filesystem quotas with rlimit which sounds quite flawed.

It's so tempting because of the similarity (and hence ease of
administration) with mlocked pages.  And if they can be merged,
user_struct being a fine placeholder, then it's perhaps simpler.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

  reply	other threads:[~2004-08-03 22:33 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-29 10:03 [patch] mlock-as-nonroot revisted Arjan van de Ven
2004-07-29 21:28 ` Andrew Morton
2004-07-29 21:40   ` Andrea Arcangeli
2004-07-30  0:50     ` Rik van Riel
2004-07-30  2:16       ` Andrea Arcangeli
2004-07-30  0:51   ` Rik van Riel
2004-07-30  2:17     ` Andrea Arcangeli
2004-07-30  1:52 ` Chris Wright
2004-07-30  2:09   ` Andrea Arcangeli
2004-07-30  2:46   ` Rik van Riel
2004-08-03 20:54   ` Rik van Riel
2004-08-03 21:45     ` Chris Wright
2004-08-03 20:55   ` Rik van Riel
2004-08-03 21:07     ` Andrea Arcangeli
2004-08-03 21:13       ` Arjan van de Ven
2004-08-03 21:36         ` Andrea Arcangeli
2004-08-03 21:38           ` Arjan van de Ven
2004-08-03 21:51             ` Andrea Arcangeli
2004-08-03 22:01               ` Chris Wright
2004-08-03 22:11                 ` Andrea Arcangeli
2004-08-03 22:33                   ` Chris Wright [this message]
2004-08-03 22:42                     ` Andrea Arcangeli
2004-08-03 22:52                       ` Chris Wright
2004-08-04  1:21                   ` Rik van Riel
2004-08-04  1:53                     ` Andrea Arcangeli
2004-08-04  2:01                       ` Rik van Riel
2004-08-04  2:13                         ` Andrea Arcangeli
2004-08-04  2:20                           ` William Lee Irwin III
2004-08-04  2:22                           ` Rik van Riel
2004-08-04  2:31                             ` William Lee Irwin III
2004-08-04  2:56                               ` Rik van Riel
2004-08-04  6:06                                 ` Chris Wright
2004-08-04 13:31                                   ` Rik van Riel
2004-08-04 13:51                                     ` Arjan van de Ven
2004-08-04 13:56                                       ` Rik van Riel
2004-08-04  3:13                             ` Andrea Arcangeli
2004-08-04  2:25                           ` Chris Wright
2004-08-04  2:07                       ` Chris Wright
2004-08-04  2:18                         ` Andrea Arcangeli
2004-08-03 21:13       ` Rik van Riel
2004-08-03 21:22         ` Andrea Arcangeli
2004-08-03 21:24           ` Arjan van de Ven
2004-08-03 21:31           ` Rik van Riel
2004-08-03 21:39             ` Andrea Arcangeli
2004-08-04  1:56               ` William Lee Irwin III
2004-08-03 22:18             ` Gerrit Huizenga
2004-08-04  1:22               ` Rik van Riel
2004-08-04  1:37                 ` Gerrit Huizenga
2004-08-04  1:55                   ` William Lee Irwin III

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=20040803153335.R1924@build.pdx.osdl.net \
    --to=chrisw@osdl.org \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox