All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: akpm@linux-foundation.org, mingo@redhat.com,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] sys_setrlimit: make sure ->rlim_max never grows
Date: Thu, 3 Sep 2009 19:20:52 +0200	[thread overview]
Message-ID: <20090903172052.GA27161@redhat.com> (raw)
In-Reply-To: <4A9FC8DA.4090001@gmail.com>

On 09/03, Jiri Slaby wrote:
>
> On 09/02/2009 11:51 PM, Oleg Nesterov wrote:
> > On 09/02, Jiri Slaby wrote:
> >> I can't think of anything else than doing all the checks and updates
> >> under alloc_lock, introducing coarse grained static mutex in setrlimit
> >> to protect it,
> >
> > Oh, please don't ;)
> >
> > Or I missed your point?
> >
> > But if you mean this series, then yes, I agree.
>
> Yes, I meant those. But I don't know what do you agree with :).

Not sure what I agree with, but I am glad we seem to agree with each other ;)

> > We should try to do something
> > to ensure that at least rlim_max can be always lowered when admin writes to
> > /proc/pid/limits.
>
> Yes, that's what I asked about when I wrote the three options which I
> was able to think of above. So any other ideas about how to elegantly
> protect against sys_setrlimit vs. admin+/proc/*/limits race?

Perhaps we should start these change with this patch (see the next email) ?

Perhaps, before your changes, we should "fix" sys_setrlimit() first ?
Well, the patch (the next email) is not tested... What do you think?

Oleg.


  parent reply	other threads:[~2009-09-03 17:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  9:45 [PATCH 1/2] core: add lockless update_rlimit_cpu Jiri Slaby
2009-09-02  9:45 ` [PATCH 2/2] core: allow setrlimit to non-current tasks Jiri Slaby
2009-09-02  9:47   ` Jiri Slaby
2009-09-02 13:50   ` Oleg Nesterov
2009-09-02 18:44     ` Jiri Slaby
2009-09-02 21:51       ` Oleg Nesterov
2009-09-03 13:47         ` Jiri Slaby
2009-09-03 13:52           ` [PATCH] " Jiri Slaby
2009-09-03 17:41             ` Oleg Nesterov
2009-09-03 20:08               ` [PATCH v2 1/8] SECURITY: selinux, fix update_rlimit_cpu parameter Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 2/8] SECURITY: add task_struct to setrlimit Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 3/8] core: add task_struct to update_rlimit_cpu Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 4/8] sys_setrlimit: make sure ->rlim_max never grows Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 5/8] core: split sys_setrlimit Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 6/8] core: allow setrlimit to non-current tasks Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 7/8] core: optimize setrlimit for current task Jiri Slaby
2009-09-03 20:08               ` [PATCH v2 8/8] FS: proc, make limits writable Jiri Slaby
2009-09-04 14:26                 ` Oleg Nesterov
2009-10-08 20:55                   ` Jiri Slaby
2009-10-12 15:13                     ` Oleg Nesterov
2009-09-03 17:20           ` Oleg Nesterov [this message]
2009-09-03 17:21           ` [PATCH 1/1] sys_setrlimit: make sure ->rlim_max never grows Oleg Nesterov

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=20090903172052.GA27161@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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 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.