public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Ulrich Drepper <drepper@redhat.com>,
	Paul Jackson <pj@sgi.com>, Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [patch 0/6] lightweight robust futexes: -V4
Date: Tue, 21 Feb 2006 04:23:38 -0500	[thread overview]
Message-ID: <20060221092338.GV24295@devserv.devel.redhat.com> (raw)
In-Reply-To: <20060221084631.GA5506@elte.hu>

On Tue, Feb 21, 2006 at 09:46:31AM +0100, Ingo Molnar wrote:
> 
> This is release -V4 of the "lightweight robust futexes" patchset. The 
> patchset can also be downloaded from:
> 
>   http://redhat.com/~mingo/lightweight-robust-futexes/
> 
> no big changes - docs updates and the tidying of futex_atomic_cmpxchg() 
> semantics.

To me the registering of thread's robust_list_head address is very
similar to registering thread's tid address and will be needed at the same
time (i.e. during program startup, when thread library is being initialized,
and upon thread creation), so I'd say we should register it the same
way as tid address and save a syscall per thread creation and a syscall
per process start.

TID address is registered through:
pid_t set_tid_address (int *tidptr)
syscall, so IMHO we should add a new syscall
pid_t set_tid_robust_addresses (int *tidptr, struct robust_list_head *robustptr)
which could register both tid and robust addresses.

For thread creation, we can just add CLONE_CHILD_SETROBUST clone flag
and if that flag is set, pass struct robust_list_head * as additional
argument.

The `len' argument (or really revision of the structure if really needed)
can be encoded in the structure, as in:
struct robust_list_head {
       struct robust_list list;
       short robust_list_head_len; /* or robust_list_head_version ? */
       short futex_offset;
       struct robust_list __user *list_op_pending;
};
or with long futex_offset, but using say upper 8 bits of the field as
version or length.

What do you think?

	Jakub

  reply	other threads:[~2006-02-21  9:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-21  8:46 [patch 0/6] lightweight robust futexes: -V4 Ingo Molnar
2006-02-21  9:23 ` Jakub Jelinek [this message]
2006-02-21 16:26   ` Ulrich Drepper
2006-02-21 16:37     ` Jakub Jelinek
2006-02-23  5:01       ` Eric W. Biederman

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=20060221092338.GV24295@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=tglx@linutronix.de \
    /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