All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: akpm@linux-foundation.org, mingo@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] core: allow setrlimit to non-current tasks
Date: Wed, 02 Sep 2009 20:44:08 +0200	[thread overview]
Message-ID: <4A9EBCF8.1020609@gmail.com> (raw)
In-Reply-To: <20090902135024.GA6452@redhat.com>

On 09/02/2009 03:50 PM, Oleg Nesterov wrote:
> But there is another minor problem. If we use read_lock(ttasklist), then
> the write to /proc/application_pid/limits can race with application doing
> sys_setrlimits().
> 
> Nothing bad can happen, but this means that "echo ... > /proc/limits" can
> be lost. Not good, if admin wants to lower ->rlim_max we should try to ensure
> this always works.

Actually, process cpu timer may be set to a wrong value. When
* somebody unrelated holds sighand->siglock
* process one stores rlim_new to rlim and gets stuck on spin_lock(siglock)
* process two does the same
* somebody releases sighand->siglock
* process one continues...

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, or some other(I-don't-know-of)/new lock. Any ideas?

Thanks.

  reply	other threads:[~2009-09-02 18:44 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 [this message]
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           ` [PATCH 0/1] sys_setrlimit: make sure ->rlim_max never grows Oleg Nesterov
2009-09-03 17:21           ` [PATCH 1/1] " 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=4A9EBCF8.1020609@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@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.