All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Anton Arapov <anton@redhat.com>, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/1] uprobes: Use percpu_rw_semaphore to fix register/unregister vs dup_mmap() race
Date: Wed, 14 Nov 2012 19:49:29 +0100	[thread overview]
Message-ID: <20121114184929.GA6977@redhat.com> (raw)

Hello.

The same patch I sent before, the only difference is that it uses
percpu_rw_semaphore instead of brw_mutex.

Srikar, I'll hope you can ack v2 too, and unless someone objects
I'll ask Ingo to pull this fix.

Tejun, recently we briefly discussed signal->group_rwsem, please
see the note about cgroups below.

Note:

	- The current implementation of percpu_rw_semaphore is not
	  optimal, register/unregister will block fork() completely
	  while it sleeps in msleep() and synchronize_sched().

	  So this patch assumes that

	  	percpu_rw_semaphore-reimplement-to-not-block-the-readers-unnecessarily.patch
	  	http://marc.info/?l=linux-mm-commits&m=135240650828875

	  will be applied eventually (and the new implementation can be
	  improved).

	- This patch adds percpu_down_read/up_read around dup_mmap()
	  for uprobes.

	  Given that it is very cheap (and assuming the optimizations
	  above), _perhaps_ we can turn this dup_mmap_sem into fork_sem
	  and use it instead of threadgroup_change_begin/end, so that
	  uprobes and cgroups can use it.

	- Compared to v1, percpu_rw_semaphore doesn't support multi-
	  writers. I hope we can tolerate this, register/unregister
	  are system-wide and rare events anyway. And _perhaps_ we
	  can add percpu_down_write_nonexclusive() later.

	- Given that currently percpu_down_write() is exclusive, this
	  patch almost dismisses the purpose of uprobes_mutex[] array.

	  Yes, but we need to rework this locking anyway for filtering.

Oleg.


             reply	other threads:[~2012-11-14 18:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14 18:49 Oleg Nesterov [this message]
2012-11-14 18:49 ` [PATCH v2 1/1] uprobes: Use percpu_rw_semaphore to fix register/unregister vs dup_mmap() race Oleg Nesterov
2012-11-15  6:57   ` Srikar Dronamraju

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=20121114184929.GA6977@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tj@kernel.org \
    /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.