linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the tip-core tree with Linus' tree
@ 2009-04-06  0:36 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2009-04-06  0:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: linux-next, Matthew Wilcox, Andrew Morton

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
kernel/sysctl.c between commit 8e654fba4a376f436bdfe361fc5cdbc87ac09b35
("sysctl: fix suid_dumpable and lease-break-time sysctls") from Linus'
tree and commit 9f8d979f082a3ee1b27f32b7e0811b51c3ad1d15 ("softlockup:
move 'one' to the softlockup section in sysctl.c") from the tip-core tree.

I fixed it up (see below) and can carry the fix as necessary.  This seems
to be the same fixup that is in tip/master.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/sysctl.c
index 82350f8,6d2aeff..0000000
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -96,9 -98,11 +99,8 @@@ static int sixty = 60
  static int neg_one = -1;
  #endif
  
 -#if defined(CONFIG_MMU) && defined(CONFIG_FILE_LOCKING)
 -static int two = 2;
 -#endif
 -
  static int zero;
- static int one = 1;
 +static int two = 2;
  static unsigned long one_ul = 1;
  static int one_hundred = 100;
  

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-22  5:50     ` Stephen Rothwell
@ 2009-05-22 18:18       ` Darren Hart
  0 siblings, 0 replies; 14+ messages in thread
From: Darren Hart @ 2009-05-22 18:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

Stephen Rothwell wrote:
> Hi Darren, Thomas,
> 
> On Fri, 22 May 2009 10:19:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> I have made the changes you suggested for today since the -tip stuff has
>                                                                        ^^^
> has not
> 
>> filtered through yet.
> 
> The resolution patch now looks like below.

Looks right at a quick glance.  I just updated linux-2.6-tip and checked 
the "auto-core-next" branch.  I appears to have the necessary 
changes.... I believe since merge 74869023169c6b85383abc66877154a582b35798.

Thanks,

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-22  0:19   ` Stephen Rothwell
@ 2009-05-22  5:50     ` Stephen Rothwell
  2009-05-22 18:18       ` Darren Hart
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2009-05-22  5:50 UTC (permalink / raw)
  To: Darren Hart
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

Hi Darren, Thomas,

On Fri, 22 May 2009 10:19:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have made the changes you suggested for today since the -tip stuff has
                                                                       ^^^
has not

> filtered through yet.

The resolution patch now looks like below.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/futex.c
index d546b2d,0c406a3..0000000
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@@ -813,13 -1092,43 +1094,44 @@@ static int futex_requeue(u32 __user *ua
  	struct futex_hash_bucket *hb1, *hb2;
  	struct plist_head *head1;
  	struct futex_q *this, *next;
- 	int ret, drop_count = 0;
+ 	u32 curval2;
+ 
+ 	if (requeue_pi) {
+ 		/*
+ 		 * requeue_pi requires a pi_state, try to allocate it now
+ 		 * without any locks in case it fails.
+ 		 */
+ 		if (refill_pi_state_cache())
+ 			return -ENOMEM;
+ 		/*
+ 		 * requeue_pi must wake as many tasks as it can, up to nr_wake
+ 		 * + nr_requeue, since it acquires the rt_mutex prior to
+ 		 * returning to userspace, so as to not leave the rt_mutex with
+ 		 * waiters and no owner.  However, second and third wake-ups
+ 		 * cannot be predicted as they involve race conditions with the
+ 		 * first wake and a fault while looking up the pi_state.  Both
+ 		 * pthread_cond_signal() and pthread_cond_broadcast() should
+ 		 * use nr_wake=1.
+ 		 */
+ 		if (nr_wake != 1)
+ 			return -EINVAL;
+ 	}
  
  retry:
+ 	if (pi_state != NULL) {
+ 		/*
+ 		 * We will have to lookup the pi_state again, so free this one
+ 		 * to keep the accounting correct.
+ 		 */
+ 		free_pi_state(pi_state);
+ 		pi_state = NULL;
+ 	}
+ 
 -	ret = get_futex_key(uaddr1, fshared, &key1);
 +	ret = get_futex_key(uaddr1, fshared, &key1, VERIFY_READ);
  	if (unlikely(ret != 0))
  		goto out;
- 	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_READ);
 -	ret = get_futex_key(uaddr2, fshared, &key2);
++	ret = get_futex_key(uaddr2, fshared, &key2,
++			    requeue_pi ? VERIFY_WRITE : VERIFY_READ);
  	if (unlikely(ret != 0))
  		goto out_put_key1;
  
@@@ -1165,14 -1668,20 +1671,20 @@@ static int futex_wait_setup(u32 __user 
  	 * A consequence is that futex_wait() can return zero and absorb
  	 * a wakeup when *uaddr != val on entry to the syscall.  This is
  	 * rare, but normal.
- 	 *
- 	 * For shared futexes, we hold the mmap semaphore, so the mapping
- 	 * cannot have changed since we looked it up in get_futex_key.
  	 */
+ retry:
+ 	q->key = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr, fshared, &q->key);
++	ret = get_futex_key(uaddr, fshared, &q->key, VERIFY_READ);
+ 	if (unlikely(ret != 0))
+ 		return ret;
+ 
+ retry_private:
+ 	*hb = queue_lock(q);
+ 
  	ret = get_futex_value_locked(&uval, uaddr);
  
- 	if (unlikely(ret)) {
- 		queue_unlock(&q, hb);
+ 	if (ret) {
+ 		queue_unlock(q, *hb);
  
  		ret = get_user(uval, uaddr);
  		if (ret)
@@@ -1330,9 -1828,10 +1831,10 @@@ static int futex_lock_pi(u32 __user *ua
  	}
  
  	q.pi_state = NULL;
+ 	q.rt_waiter = NULL;
  retry:
  	q.key = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr, fshared, &q.key);
 +	ret = get_futex_key(uaddr, fshared, &q.key, VERIFY_WRITE);
  	if (unlikely(ret != 0))
  		goto out;
  
@@@ -1674,6 -2050,253 +2053,253 @@@ pi_faulted
  	return ret;
  }
  
+ /**
+  * handle_early_requeue_pi_wakeup() - Detect early wakeup on the initial futex
+  * @hb:		the hash_bucket futex_q was original enqueued on
+  * @q:		the futex_q woken while waiting to be requeued
+  * @key2:	the futex_key of the requeue target futex
+  * @timeout:	the timeout associated with the wait (NULL if none)
+  *
+  * Detect if the task was woken on the initial futex as opposed to the requeue
+  * target futex.  If so, determine if it was a timeout or a signal that caused
+  * the wakeup and return the appropriate error code to the caller.  Must be
+  * called with the hb lock held.
+  *
+  * Returns
+  *  0 - no early wakeup detected
+  * <0 - -ETIMEDOUT or -ERESTARTSYS (FIXME: or ERESTARTNOINTR?)
+  */
+ static inline
+ int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb,
+ 				   struct futex_q *q, union futex_key *key2,
+ 				   struct hrtimer_sleeper *timeout)
+ {
+ 	int ret = 0;
+ 
+ 	/*
+ 	 * With the hb lock held, we avoid races while we process the wakeup.
+ 	 * We only need to hold hb (and not hb2) to ensure atomicity as the
+ 	 * wakeup code can't change q.key from uaddr to uaddr2 if we hold hb.
+ 	 * It can't be requeued from uaddr2 to something else since we don't
+ 	 * support a PI aware source futex for requeue.
+ 	 */
+ 	if (!match_futex(&q->key, key2)) {
+ 		WARN_ON(q->lock_ptr && (&hb->lock != q->lock_ptr));
+ 		/*
+ 		 * We were woken prior to requeue by a timeout or a signal.
+ 		 * Unqueue the futex_q and determine which it was.
+ 		 */
+ 		plist_del(&q->list, &q->list.plist);
+ 		drop_futex_key_refs(&q->key);
+ 
+ 		if (timeout && !timeout->task)
+ 			ret = -ETIMEDOUT;
+ 		else {
+ 			/*
+ 			 * We expect signal_pending(current), but another
+ 			 * thread may have handled it for us already.
+ 			 */
+ 			/* FIXME: ERESTARTSYS or ERESTARTNOINTR?  Do we care if
+ 			 * the user specified SA_RESTART or not? */
+ 			ret = -ERESTARTSYS;
+ 		}
+ 	}
+ 	return ret;
+ }
+ 
+ /**
+  * futex_wait_requeue_pi() - Wait on uaddr and take uaddr2
+  * @uaddr:	the futex we initialyl wait on (non-pi)
+  * @fshared:	whether the futexes are shared (1) or not (0).  They must be
+  * 		the same type, no requeueing from private to shared, etc.
+  * @val:	the expected value of uaddr
+  * @abs_time:	absolute timeout
+  * @bitset:	32 bit wakeup bitset set by userspace, defaults to all.
+  * @clockrt:	whether to use CLOCK_REALTIME (1) or CLOCK_MONOTONIC (0)
+  * @uaddr2:	the pi futex we will take prior to returning to user-space
+  *
+  * The caller will wait on uaddr and will be requeued by futex_requeue() to
+  * uaddr2 which must be PI aware.  Normal wakeup will wake on uaddr2 and
+  * complete the acquisition of the rt_mutex prior to returning to userspace.
+  * This ensures the rt_mutex maintains an owner when it has waiters; without
+  * one, the pi logic wouldn't know which task to boost/deboost, if there was a
+  * need to.
+  *
+  * We call schedule in futex_wait_queue_me() when we enqueue and return there
+  * via the following:
+  * 1) wakeup on uaddr2 after an atomic lock acquisition by futex_requeue()
+  * 2) wakeup on uaddr2 after a requeue and subsequent unlock
+  * 3) signal (before or after requeue)
+  * 4) timeout (before or after requeue)
+  *
+  * If 3, we setup a restart_block with futex_wait_requeue_pi() as the function.
+  *
+  * If 2, we may then block on trying to take the rt_mutex and return via:
+  * 5) successful lock
+  * 6) signal
+  * 7) timeout
+  * 8) other lock acquisition failure
+  *
+  * If 6, we setup a restart_block with futex_lock_pi() as the function.
+  *
+  * If 4 or 7, we cleanup and return with -ETIMEDOUT.
+  *
+  * Returns:
+  *  0 - On success
+  * <0 - On error
+  */
+ static int futex_wait_requeue_pi(u32 __user *uaddr, int fshared,
+ 				 u32 val, ktime_t *abs_time, u32 bitset,
+ 				 int clockrt, u32 __user *uaddr2)
+ {
+ 	struct hrtimer_sleeper timeout, *to = NULL;
+ 	struct rt_mutex_waiter rt_waiter;
+ 	struct rt_mutex *pi_mutex = NULL;
+ 	DECLARE_WAITQUEUE(wait, current);
+ 	struct restart_block *restart;
+ 	struct futex_hash_bucket *hb;
+ 	union futex_key key2;
+ 	struct futex_q q;
+ 	int res, ret;
+ 	u32 uval;
+ 
+ 	if (!bitset)
+ 		return -EINVAL;
+ 
+ 	if (abs_time) {
+ 		to = &timeout;
+ 		hrtimer_init_on_stack(&to->timer, clockrt ? CLOCK_REALTIME :
+ 				      CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ 		hrtimer_init_sleeper(to, current);
+ 		hrtimer_set_expires_range_ns(&to->timer, *abs_time,
+ 					     current->timer_slack_ns);
+ 	}
+ 
+ 	/*
+ 	 * The waiter is allocated on our stack, manipulated by the requeue
+ 	 * code while we sleep on uaddr.
+ 	 */
+ 	debug_rt_mutex_init_waiter(&rt_waiter);
+ 	rt_waiter.task = NULL;
+ 
+ 	q.pi_state = NULL;
+ 	q.bitset = bitset;
+ 	q.rt_waiter = &rt_waiter;
+ 
+ 	key2 = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr2, fshared, &key2);
++	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_WRITE);
+ 	if (unlikely(ret != 0))
+ 		goto out;
+ 
+ 	/* Prepare to wait on uaddr. */
+ 	ret = futex_wait_setup(uaddr, val, fshared, &q, &hb);
+ 	if (ret) {
+ 		put_futex_key(fshared, &key2);
+ 		goto out;
+ 	}
+ 
+ 	/* Queue the futex_q, drop the hb lock, wait for wakeup. */
+ 	futex_wait_queue_me(hb, &q, to, &wait);
+ 
+ 	spin_lock(&hb->lock);
+ 	ret = handle_early_requeue_pi_wakeup(hb, &q, &key2, to);
+ 	spin_unlock(&hb->lock);
+ 	if (ret)
+ 		goto out_put_keys;
+ 
+ 	/*
+ 	 * In order for us to be here, we know our q.key == key2, and since
+ 	 * we took the hb->lock above, we also know that futex_requeue() has
+ 	 * completed and we no longer have to concern ourselves with a wakeup
+ 	 * race with the atomic proxy lock acquition by the requeue code.
+ 	 */
+ 
+ 	/* Check if the requeue code acquired the second futex for us. */
+ 	if (!q.rt_waiter) {
+ 		/*
+ 		 * Got the lock. We might not be the anticipated owner if we
+ 		 * did a lock-steal - fix up the PI-state in that case.
+ 		 */
+ 		if (q.pi_state && (q.pi_state->owner != current)) {
+ 			spin_lock(q.lock_ptr);
+ 			ret = fixup_pi_state_owner(uaddr2, &q, current,
+ 						   fshared);
+ 			spin_unlock(q.lock_ptr);
+ 		}
+ 	} else {
+ 		/*
+ 		 * We have been woken up by futex_unlock_pi(), a timeout, or a
+ 		 * signal.  futex_unlock_pi() will not destroy the lock_ptr nor
+ 		 * the pi_state.
+ 		 */
+ 		WARN_ON(!&q.pi_state);
+ 		pi_mutex = &q.pi_state->pi_mutex;
+ 		ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1);
+ 		debug_rt_mutex_free_waiter(&rt_waiter);
+ 
+ 		spin_lock(q.lock_ptr);
+ 		/*
+ 		 * Fixup the pi_state owner and possibly acquire the lock if we
+ 		 * haven't already.
+ 		 */
+ 		res = fixup_owner(uaddr2, fshared, &q, !ret);
+ 		/*
+ 		 * If fixup_owner() returned an error, proprogate that.  If it
+ 		 * acquired the lock, clear our -ETIMEDOUT or -EINTR.
+ 		 */
+ 		if (res)
+ 			ret = (res < 0) ? res : 0;
+ 
+ 		/* Unqueue and drop the lock. */
+ 		unqueue_me_pi(&q);
+ 	}
+ 
+ 	/*
+ 	 * If fixup_pi_state_owner() faulted and was unable to handle the
+ 	 * fault, unlock the rt_mutex and return the fault to userspace.
+ 	 */
+ 	if (ret == -EFAULT) {
+ 		if (rt_mutex_owner(pi_mutex) == current)
+ 			rt_mutex_unlock(pi_mutex);
+ 	} else if (ret == -EINTR) {
+ 		ret = -EFAULT;
+ 		if (get_user(uval, uaddr2))
+ 			goto out_put_keys;
+ 
+ 		/*
+ 		 * We've already been requeued, so restart by calling
+ 		 * futex_lock_pi() directly, rather then returning to this
+ 		 * function.
+ 		 */
+ 		ret = -ERESTART_RESTARTBLOCK;
+ 		restart = &current_thread_info()->restart_block;
+ 		restart->fn = futex_lock_pi_restart;
+ 		restart->futex.uaddr = (u32 *)uaddr2;
+ 		restart->futex.val = uval;
+ 		restart->futex.flags = 0;
+ 		if (abs_time) {
+ 			restart->futex.flags |= FLAGS_HAS_TIMEOUT;
+ 			restart->futex.time = abs_time->tv64;
+ 		}
+ 
+ 		if (fshared)
+ 			restart->futex.flags |= FLAGS_SHARED;
+ 		if (clockrt)
+ 			restart->futex.flags |= FLAGS_CLOCKRT;
+ 	}
+ 
+ out_put_keys:
+ 	put_futex_key(fshared, &q.key);
+ 	put_futex_key(fshared, &key2);
+ 
+ out:
+ 	if (to) {
+ 		hrtimer_cancel(&to->timer);
+ 		destroy_hrtimer_on_stack(&to->timer);
+ 	}
+ 	return ret;
+ }
+ 
  /*
   * Support for robust futexes: the kernel cleans up held futexes at
   * thread exit time.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-21  3:56 ` Darren Hart
  2009-05-21  9:30   ` Thomas Gleixner
@ 2009-05-22  0:19   ` Stephen Rothwell
  2009-05-22  5:50     ` Stephen Rothwell
  1 sibling, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2009-05-22  0:19 UTC (permalink / raw)
  To: Darren Hart
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Hi Darren,

On Wed, 20 May 2009 20:56:47 -0700 Darren Hart <dvhltc@us.ibm.com> wrote:
>
> I suspect Thomas will be catching that up in the next day or so in tip
> (or I can).  If you need something now, the uaddr is VERIFY_READ and
> uaddr2 is VERIFY_WRITE.  See below...

I have made the changes you suggested for today since the -tip stuff has
filtered through yet.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-21  9:30   ` Thomas Gleixner
@ 2009-05-21  9:38     ` Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2009-05-21  9:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Darren Hart, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Hi Thomas,

On Thu, 21 May 2009 11:30:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Fix is in -tip and queued for -next

Thanks for that.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-21  3:56 ` Darren Hart
@ 2009-05-21  9:30   ` Thomas Gleixner
  2009-05-21  9:38     ` Stephen Rothwell
  2009-05-22  0:19   ` Stephen Rothwell
  1 sibling, 1 reply; 14+ messages in thread
From: Thomas Gleixner @ 2009-05-21  9:30 UTC (permalink / raw)
  To: Darren Hart
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

On Wed, 20 May 2009, Darren Hart wrote:

> Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the tip-core tree got a conflict in
> > kernel/futex.c between commit 64d1304a64477629cb16b75491a77bafe6f86963
> > ("futex: setup writeable mapping for futex ops which modify user space
> > data") from Linus' tree and a couple of commits from the tip-core tree.
> > 
> > I fixed it up (see below - but please check in particular, I have no idea
> > if the call to get_futex_key() in futex_wait_requeue_pi() should take
> > VERIFY_READ or VERIFY_WRITE).
> > 
> > I can carry this fixup as necessary.
> 
> I suspect Thomas will be catching that up in the next day or so in tip
> (or I can).  If you need something now, the uaddr is VERIFY_READ and
> uaddr2 is VERIFY_WRITE.  See below...

Fix is in -tip and queued for -next

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-05-21  1:39 Stephen Rothwell
@ 2009-05-21  3:56 ` Darren Hart
  2009-05-21  9:30   ` Thomas Gleixner
  2009-05-22  0:19   ` Stephen Rothwell
  0 siblings, 2 replies; 14+ messages in thread
From: Darren Hart @ 2009-05-21  3:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next, linux-kernel

Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip-core tree got a conflict in
> kernel/futex.c between commit 64d1304a64477629cb16b75491a77bafe6f86963
> ("futex: setup writeable mapping for futex ops which modify user space
> data") from Linus' tree and a couple of commits from the tip-core tree.
> 
> I fixed it up (see below - but please check in particular, I have no idea
> if the call to get_futex_key() in futex_wait_requeue_pi() should take
> VERIFY_READ or VERIFY_WRITE).
> 
> I can carry this fixup as necessary.

I suspect Thomas will be catching that up in the next day or so in tip
(or I can).  If you need something now, the uaddr is VERIFY_READ and
uaddr2 is VERIFY_WRITE.  See below...

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc kernel/futex.c
> index d546b2d,0c406a3..0000000
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@@ -813,13 -1092,43 +1094,43 @@@ static int futex_requeue(u32 __user *ua
>   	struct futex_hash_bucket *hb1, *hb2;
>   	struct plist_head *head1;
>   	struct futex_q *this, *next;
> - 	int ret, drop_count = 0;
> + 	u32 curval2;
> + 
> + 	if (requeue_pi) {
> + 		/*
> + 		 * requeue_pi requires a pi_state, try to allocate it now
> + 		 * without any locks in case it fails.
> + 		 */
> + 		if (refill_pi_state_cache())
> + 			return -ENOMEM;
> + 		/*
> + 		 * requeue_pi must wake as many tasks as it can, up to nr_wake
> + 		 * + nr_requeue, since it acquires the rt_mutex prior to
> + 		 * returning to userspace, so as to not leave the rt_mutex with
> + 		 * waiters and no owner.  However, second and third wake-ups
> + 		 * cannot be predicted as they involve race conditions with the
> + 		 * first wake and a fault while looking up the pi_state.  Both
> + 		 * pthread_cond_signal() and pthread_cond_broadcast() should
> + 		 * use nr_wake=1.
> + 		 */
> + 		if (nr_wake != 1)
> + 			return -EINVAL;
> + 	}
>   
>   retry:
> + 	if (pi_state != NULL) {
> + 		/*
> + 		 * We will have to lookup the pi_state again, so free this one
> + 		 * to keep the accounting correct.
> + 		 */
> + 		free_pi_state(pi_state);
> + 		pi_state = NULL;
> + 	}
> + 
>  -	ret = get_futex_key(uaddr1, fshared, &key1);
>  +	ret = get_futex_key(uaddr1, fshared, &key1, VERIFY_READ);
>   	if (unlikely(ret != 0))
>   		goto out;
>  -	ret = get_futex_key(uaddr2, fshared, &key2);
>  +	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_READ);

This one should be VERIFY_WRITE in the case of requeue_pi==1 as we
attempt to take this futex on behalf of the waiting task (either setting
the FUTEX_HAS_WAITERS flag or setting it as the owner).  So maybe
something like:

+	ret = get_futex_key(uaddr2, fshared, &key2,
			    requeue_pi == 1 ? VERIFY_WRITE : VERIFY_READ);

Alternatively just put it in an if/else block to avoid the inline
tertiary operator.

> + static int futex_wait_requeue_pi(u32 __user *uaddr, int fshared,
> + 				 u32 val, ktime_t *abs_time, u32 bitset,
> + 				 int clockrt, u32 __user *uaddr2)
> + {
> + 	struct hrtimer_sleeper timeout, *to = NULL;
> + 	struct rt_mutex_waiter rt_waiter;
> + 	struct rt_mutex *pi_mutex = NULL;
> + 	DECLARE_WAITQUEUE(wait, current);
> + 	struct restart_block *restart;
> + 	struct futex_hash_bucket *hb;
> + 	union futex_key key2;
> + 	struct futex_q q;
> + 	int res, ret;
> + 	u32 uval;
> + 
> + 	if (!bitset)
> + 		return -EINVAL;
> + 
> + 	if (abs_time) {
> + 		to = &timeout;
> + 		hrtimer_init_on_stack(&to->timer, clockrt ? CLOCK_REALTIME :
> + 				      CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> + 		hrtimer_init_sleeper(to, current);
> + 		hrtimer_set_expires_range_ns(&to->timer, *abs_time,
> + 					     current->timer_slack_ns);
> + 	}
> + 
> + 	/*
> + 	 * The waiter is allocated on our stack, manipulated by the requeue
> + 	 * code while we sleep on uaddr.
> + 	 */
> + 	debug_rt_mutex_init_waiter(&rt_waiter);
> + 	rt_waiter.task = NULL;
> + 
> + 	q.pi_state = NULL;
> + 	q.bitset = bitset;
> + 	q.rt_waiter = &rt_waiter;
> + 
> + 	key2 = FUTEX_KEY_INIT;
>  -	ret = get_futex_key(uaddr2, fshared, &key2);
> ++	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_READ);

This one should be VERIFY_WRITE (it's the pi futex, so we set it's value
here in the kernel).

Thanks,

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the tip-core tree with Linus' tree
@ 2009-05-21  1:39 Stephen Rothwell
  2009-05-21  3:56 ` Darren Hart
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2009-05-21  1:39 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: linux-next, linux-kernel, Darren Hart

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
kernel/futex.c between commit 64d1304a64477629cb16b75491a77bafe6f86963
("futex: setup writeable mapping for futex ops which modify user space
data") from Linus' tree and a couple of commits from the tip-core tree.

I fixed it up (see below - but please check in particular, I have no idea
if the call to get_futex_key() in futex_wait_requeue_pi() should take
VERIFY_READ or VERIFY_WRITE).

I can carry this fixup as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/futex.c
index d546b2d,0c406a3..0000000
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@@ -813,13 -1092,43 +1094,43 @@@ static int futex_requeue(u32 __user *ua
  	struct futex_hash_bucket *hb1, *hb2;
  	struct plist_head *head1;
  	struct futex_q *this, *next;
- 	int ret, drop_count = 0;
+ 	u32 curval2;
+ 
+ 	if (requeue_pi) {
+ 		/*
+ 		 * requeue_pi requires a pi_state, try to allocate it now
+ 		 * without any locks in case it fails.
+ 		 */
+ 		if (refill_pi_state_cache())
+ 			return -ENOMEM;
+ 		/*
+ 		 * requeue_pi must wake as many tasks as it can, up to nr_wake
+ 		 * + nr_requeue, since it acquires the rt_mutex prior to
+ 		 * returning to userspace, so as to not leave the rt_mutex with
+ 		 * waiters and no owner.  However, second and third wake-ups
+ 		 * cannot be predicted as they involve race conditions with the
+ 		 * first wake and a fault while looking up the pi_state.  Both
+ 		 * pthread_cond_signal() and pthread_cond_broadcast() should
+ 		 * use nr_wake=1.
+ 		 */
+ 		if (nr_wake != 1)
+ 			return -EINVAL;
+ 	}
  
  retry:
+ 	if (pi_state != NULL) {
+ 		/*
+ 		 * We will have to lookup the pi_state again, so free this one
+ 		 * to keep the accounting correct.
+ 		 */
+ 		free_pi_state(pi_state);
+ 		pi_state = NULL;
+ 	}
+ 
 -	ret = get_futex_key(uaddr1, fshared, &key1);
 +	ret = get_futex_key(uaddr1, fshared, &key1, VERIFY_READ);
  	if (unlikely(ret != 0))
  		goto out;
 -	ret = get_futex_key(uaddr2, fshared, &key2);
 +	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_READ);
  	if (unlikely(ret != 0))
  		goto out_put_key1;
  
@@@ -1165,14 -1668,20 +1670,20 @@@ static int futex_wait_setup(u32 __user 
  	 * A consequence is that futex_wait() can return zero and absorb
  	 * a wakeup when *uaddr != val on entry to the syscall.  This is
  	 * rare, but normal.
- 	 *
- 	 * For shared futexes, we hold the mmap semaphore, so the mapping
- 	 * cannot have changed since we looked it up in get_futex_key.
  	 */
+ retry:
+ 	q->key = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr, fshared, &q->key);
++	ret = get_futex_key(uaddr, fshared, &q->key, VERIFY_READ);
+ 	if (unlikely(ret != 0))
+ 		return ret;
+ 
+ retry_private:
+ 	*hb = queue_lock(q);
+ 
  	ret = get_futex_value_locked(&uval, uaddr);
  
- 	if (unlikely(ret)) {
- 		queue_unlock(&q, hb);
+ 	if (ret) {
+ 		queue_unlock(q, *hb);
  
  		ret = get_user(uval, uaddr);
  		if (ret)
@@@ -1330,9 -1828,10 +1830,10 @@@ static int futex_lock_pi(u32 __user *ua
  	}
  
  	q.pi_state = NULL;
+ 	q.rt_waiter = NULL;
  retry:
  	q.key = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr, fshared, &q.key);
 +	ret = get_futex_key(uaddr, fshared, &q.key, VERIFY_WRITE);
  	if (unlikely(ret != 0))
  		goto out;
  
@@@ -1674,6 -2050,253 +2052,253 @@@ pi_faulted
  	return ret;
  }
  
+ /**
+  * handle_early_requeue_pi_wakeup() - Detect early wakeup on the initial futex
+  * @hb:		the hash_bucket futex_q was original enqueued on
+  * @q:		the futex_q woken while waiting to be requeued
+  * @key2:	the futex_key of the requeue target futex
+  * @timeout:	the timeout associated with the wait (NULL if none)
+  *
+  * Detect if the task was woken on the initial futex as opposed to the requeue
+  * target futex.  If so, determine if it was a timeout or a signal that caused
+  * the wakeup and return the appropriate error code to the caller.  Must be
+  * called with the hb lock held.
+  *
+  * Returns
+  *  0 - no early wakeup detected
+  * <0 - -ETIMEDOUT or -ERESTARTSYS (FIXME: or ERESTARTNOINTR?)
+  */
+ static inline
+ int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb,
+ 				   struct futex_q *q, union futex_key *key2,
+ 				   struct hrtimer_sleeper *timeout)
+ {
+ 	int ret = 0;
+ 
+ 	/*
+ 	 * With the hb lock held, we avoid races while we process the wakeup.
+ 	 * We only need to hold hb (and not hb2) to ensure atomicity as the
+ 	 * wakeup code can't change q.key from uaddr to uaddr2 if we hold hb.
+ 	 * It can't be requeued from uaddr2 to something else since we don't
+ 	 * support a PI aware source futex for requeue.
+ 	 */
+ 	if (!match_futex(&q->key, key2)) {
+ 		WARN_ON(q->lock_ptr && (&hb->lock != q->lock_ptr));
+ 		/*
+ 		 * We were woken prior to requeue by a timeout or a signal.
+ 		 * Unqueue the futex_q and determine which it was.
+ 		 */
+ 		plist_del(&q->list, &q->list.plist);
+ 		drop_futex_key_refs(&q->key);
+ 
+ 		if (timeout && !timeout->task)
+ 			ret = -ETIMEDOUT;
+ 		else {
+ 			/*
+ 			 * We expect signal_pending(current), but another
+ 			 * thread may have handled it for us already.
+ 			 */
+ 			/* FIXME: ERESTARTSYS or ERESTARTNOINTR?  Do we care if
+ 			 * the user specified SA_RESTART or not? */
+ 			ret = -ERESTARTSYS;
+ 		}
+ 	}
+ 	return ret;
+ }
+ 
+ /**
+  * futex_wait_requeue_pi() - Wait on uaddr and take uaddr2
+  * @uaddr:	the futex we initialyl wait on (non-pi)
+  * @fshared:	whether the futexes are shared (1) or not (0).  They must be
+  * 		the same type, no requeueing from private to shared, etc.
+  * @val:	the expected value of uaddr
+  * @abs_time:	absolute timeout
+  * @bitset:	32 bit wakeup bitset set by userspace, defaults to all.
+  * @clockrt:	whether to use CLOCK_REALTIME (1) or CLOCK_MONOTONIC (0)
+  * @uaddr2:	the pi futex we will take prior to returning to user-space
+  *
+  * The caller will wait on uaddr and will be requeued by futex_requeue() to
+  * uaddr2 which must be PI aware.  Normal wakeup will wake on uaddr2 and
+  * complete the acquisition of the rt_mutex prior to returning to userspace.
+  * This ensures the rt_mutex maintains an owner when it has waiters; without
+  * one, the pi logic wouldn't know which task to boost/deboost, if there was a
+  * need to.
+  *
+  * We call schedule in futex_wait_queue_me() when we enqueue and return there
+  * via the following:
+  * 1) wakeup on uaddr2 after an atomic lock acquisition by futex_requeue()
+  * 2) wakeup on uaddr2 after a requeue and subsequent unlock
+  * 3) signal (before or after requeue)
+  * 4) timeout (before or after requeue)
+  *
+  * If 3, we setup a restart_block with futex_wait_requeue_pi() as the function.
+  *
+  * If 2, we may then block on trying to take the rt_mutex and return via:
+  * 5) successful lock
+  * 6) signal
+  * 7) timeout
+  * 8) other lock acquisition failure
+  *
+  * If 6, we setup a restart_block with futex_lock_pi() as the function.
+  *
+  * If 4 or 7, we cleanup and return with -ETIMEDOUT.
+  *
+  * Returns:
+  *  0 - On success
+  * <0 - On error
+  */
+ static int futex_wait_requeue_pi(u32 __user *uaddr, int fshared,
+ 				 u32 val, ktime_t *abs_time, u32 bitset,
+ 				 int clockrt, u32 __user *uaddr2)
+ {
+ 	struct hrtimer_sleeper timeout, *to = NULL;
+ 	struct rt_mutex_waiter rt_waiter;
+ 	struct rt_mutex *pi_mutex = NULL;
+ 	DECLARE_WAITQUEUE(wait, current);
+ 	struct restart_block *restart;
+ 	struct futex_hash_bucket *hb;
+ 	union futex_key key2;
+ 	struct futex_q q;
+ 	int res, ret;
+ 	u32 uval;
+ 
+ 	if (!bitset)
+ 		return -EINVAL;
+ 
+ 	if (abs_time) {
+ 		to = &timeout;
+ 		hrtimer_init_on_stack(&to->timer, clockrt ? CLOCK_REALTIME :
+ 				      CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ 		hrtimer_init_sleeper(to, current);
+ 		hrtimer_set_expires_range_ns(&to->timer, *abs_time,
+ 					     current->timer_slack_ns);
+ 	}
+ 
+ 	/*
+ 	 * The waiter is allocated on our stack, manipulated by the requeue
+ 	 * code while we sleep on uaddr.
+ 	 */
+ 	debug_rt_mutex_init_waiter(&rt_waiter);
+ 	rt_waiter.task = NULL;
+ 
+ 	q.pi_state = NULL;
+ 	q.bitset = bitset;
+ 	q.rt_waiter = &rt_waiter;
+ 
+ 	key2 = FUTEX_KEY_INIT;
 -	ret = get_futex_key(uaddr2, fshared, &key2);
++	ret = get_futex_key(uaddr2, fshared, &key2, VERIFY_READ);
+ 	if (unlikely(ret != 0))
+ 		goto out;
+ 
+ 	/* Prepare to wait on uaddr. */
+ 	ret = futex_wait_setup(uaddr, val, fshared, &q, &hb);
+ 	if (ret) {
+ 		put_futex_key(fshared, &key2);
+ 		goto out;
+ 	}
+ 
+ 	/* Queue the futex_q, drop the hb lock, wait for wakeup. */
+ 	futex_wait_queue_me(hb, &q, to, &wait);
+ 
+ 	spin_lock(&hb->lock);
+ 	ret = handle_early_requeue_pi_wakeup(hb, &q, &key2, to);
+ 	spin_unlock(&hb->lock);
+ 	if (ret)
+ 		goto out_put_keys;
+ 
+ 	/*
+ 	 * In order for us to be here, we know our q.key == key2, and since
+ 	 * we took the hb->lock above, we also know that futex_requeue() has
+ 	 * completed and we no longer have to concern ourselves with a wakeup
+ 	 * race with the atomic proxy lock acquition by the requeue code.
+ 	 */
+ 
+ 	/* Check if the requeue code acquired the second futex for us. */
+ 	if (!q.rt_waiter) {
+ 		/*
+ 		 * Got the lock. We might not be the anticipated owner if we
+ 		 * did a lock-steal - fix up the PI-state in that case.
+ 		 */
+ 		if (q.pi_state && (q.pi_state->owner != current)) {
+ 			spin_lock(q.lock_ptr);
+ 			ret = fixup_pi_state_owner(uaddr2, &q, current,
+ 						   fshared);
+ 			spin_unlock(q.lock_ptr);
+ 		}
+ 	} else {
+ 		/*
+ 		 * We have been woken up by futex_unlock_pi(), a timeout, or a
+ 		 * signal.  futex_unlock_pi() will not destroy the lock_ptr nor
+ 		 * the pi_state.
+ 		 */
+ 		WARN_ON(!&q.pi_state);
+ 		pi_mutex = &q.pi_state->pi_mutex;
+ 		ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1);
+ 		debug_rt_mutex_free_waiter(&rt_waiter);
+ 
+ 		spin_lock(q.lock_ptr);
+ 		/*
+ 		 * Fixup the pi_state owner and possibly acquire the lock if we
+ 		 * haven't already.
+ 		 */
+ 		res = fixup_owner(uaddr2, fshared, &q, !ret);
+ 		/*
+ 		 * If fixup_owner() returned an error, proprogate that.  If it
+ 		 * acquired the lock, clear our -ETIMEDOUT or -EINTR.
+ 		 */
+ 		if (res)
+ 			ret = (res < 0) ? res : 0;
+ 
+ 		/* Unqueue and drop the lock. */
+ 		unqueue_me_pi(&q);
+ 	}
+ 
+ 	/*
+ 	 * If fixup_pi_state_owner() faulted and was unable to handle the
+ 	 * fault, unlock the rt_mutex and return the fault to userspace.
+ 	 */
+ 	if (ret == -EFAULT) {
+ 		if (rt_mutex_owner(pi_mutex) == current)
+ 			rt_mutex_unlock(pi_mutex);
+ 	} else if (ret == -EINTR) {
+ 		ret = -EFAULT;
+ 		if (get_user(uval, uaddr2))
+ 			goto out_put_keys;
+ 
+ 		/*
+ 		 * We've already been requeued, so restart by calling
+ 		 * futex_lock_pi() directly, rather then returning to this
+ 		 * function.
+ 		 */
+ 		ret = -ERESTART_RESTARTBLOCK;
+ 		restart = &current_thread_info()->restart_block;
+ 		restart->fn = futex_lock_pi_restart;
+ 		restart->futex.uaddr = (u32 *)uaddr2;
+ 		restart->futex.val = uval;
+ 		restart->futex.flags = 0;
+ 		if (abs_time) {
+ 			restart->futex.flags |= FLAGS_HAS_TIMEOUT;
+ 			restart->futex.time = abs_time->tv64;
+ 		}
+ 
+ 		if (fshared)
+ 			restart->futex.flags |= FLAGS_SHARED;
+ 		if (clockrt)
+ 			restart->futex.flags |= FLAGS_CLOCKRT;
+ 	}
+ 
+ out_put_keys:
+ 	put_futex_key(fshared, &q.key);
+ 	put_futex_key(fshared, &key2);
+ 
+ out:
+ 	if (to) {
+ 		hrtimer_cancel(&to->timer);
+ 		destroy_hrtimer_on_stack(&to->timer);
+ 	}
+ 	return ret;
+ }
+ 
  /*
   * Support for robust futexes: the kernel cleans up held futexes at
   * thread exit time.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-02-09  0:46 ` Chris Mason
@ 2009-02-09  8:51   ` Ingo Molnar
  0 siblings, 0 replies; 14+ messages in thread
From: Ingo Molnar @ 2009-02-09  8:51 UTC (permalink / raw)
  To: Chris Mason; +Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next


* Chris Mason <chris.mason@oracle.com> wrote:

> On Mon, 2009-02-09 at 11:38 +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the tip-core tree got a conflict in
> > fs/btrfs/locking.c between commit
> > b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
> > use explicit blocking points") from Linus' tree and commit
> > cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
> > mutex_trylock and let the adaptive code spin for us") from the tip-core
> > tree.
> > 
> > Resolved as in tip/master by taking the version from Linus' tree.
> 
> Sorry, I meant to ask Ingo to drop the patch I had sent along for the btrfs 
> adaptive code. Using Linus' copy was the right answer, it replaces the patch I 
> sent to Ingo.

It was obvious how to resolve it so i did not notify you about it. I generally ping 
people when a conflict looks troublesome in some way - that's pretty rare.

	Ingo

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-02-09  0:38 Stephen Rothwell
@ 2009-02-09  0:46 ` Chris Mason
  2009-02-09  8:51   ` Ingo Molnar
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Mason @ 2009-02-09  0:46 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next

On Mon, 2009-02-09 at 11:38 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip-core tree got a conflict in
> fs/btrfs/locking.c between commit
> b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
> use explicit blocking points") from Linus' tree and commit
> cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
> mutex_trylock and let the adaptive code spin for us") from the tip-core
> tree.
> 
> Resolved as in tip/master by taking the version from Linus' tree.

Sorry, I meant to ask Ingo to drop the patch I had sent along for the
btrfs adaptive code. Using Linus' copy was the right answer, it replaces
the patch I sent to Ingo.

-chris

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the tip-core tree with Linus' tree
@ 2009-02-09  0:38 Stephen Rothwell
  2009-02-09  0:46 ` Chris Mason
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2009-02-09  0:38 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-next, Chris Mason

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
fs/btrfs/locking.c between commit
b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
use explicit blocking points") from Linus' tree and commit
cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
mutex_trylock and let the adaptive code spin for us") from the tip-core
tree.

Resolved as in tip/master by taking the version from Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the tip-core tree with Linus' tree
  2009-02-06  2:26 Stephen Rothwell
@ 2009-02-06 13:53 ` Ingo Molnar
  0 siblings, 0 replies; 14+ messages in thread
From: Ingo Molnar @ 2009-02-06 13:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, H. Peter Anvin, linux-next, James Bottomley


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the tip-core tree got a conflict in
> arch/x86/mach-voyager/voyager_smp.c between commit
> 92ab78315c638515d0e81b0c70b2082f713582d9 ("x86/Voyager: make it build and
> boot") from Linus' tree and commit
> 552be871e67ff577ed36beb2f53d078b42304739 ("x86: pass in cpu number to
> switch_to_new_gdt()") from the tip-core tree.
> 
> I used the resolution from tip/master (see below -worth checking that I 
> got it right).  (Though I assume that there is no reason that the other 
> uses of smp_processor_id() in voyager_smp_prepare_boot_cpu could be 
> replaced by "cpu" as well?)

Thanks!

Note that the x86/Voyager code will have to be totally reworked ontop of the 
new x86 subarch code and that the cpumask logic there is largely obsolete 
(in the context of linux-next) and cannot be triggered via any 
Kconfig-reachable build mode anymore.

I've pushed out a next tip/auto-core-next branch so the conflict should 
disappear from your tree.

Note that there's another upcoming conflict, in arch/x86/mm/fault.c, due to 
this upstream commit from a few hours ago:

  9be260a: prevent kprobes from catching spurious page faults

This will conflict both with the pagefault cleanups in tip/x86/mm and with 
tip/kmemcheck so it's a non-trivial 3-way conflict. I've resolved the 
conflicts explicitly on the Git level and pushed out a freshly integrated 
x86-next, core-next and kmemcheck-next tree as well - so you should not be 
seeing conflicts in that area.

Note: take care because these trees also contain a lot of new stuff: the x86 
APIC and subarch rewrite, the shiny new percpu changes and cleanup and more. 
Let us know if you run into any trouble with them.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the tip-core tree with Linus' tree
@ 2009-02-06  2:26 Stephen Rothwell
  2009-02-06 13:53 ` Ingo Molnar
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2009-02-06  2:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-next, James Bottomley

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
arch/x86/mach-voyager/voyager_smp.c between commit
92ab78315c638515d0e81b0c70b2082f713582d9 ("x86/Voyager: make it build and
boot") from Linus' tree and commit
552be871e67ff577ed36beb2f53d078b42304739 ("x86: pass in cpu number to
switch_to_new_gdt()") from the tip-core tree.

I used the resolution from tip/master (see below -worth checking that I
got it right).  (Though I assume that there is no reason that the other
uses of smp_processor_id() in voyager_smp_prepare_boot_cpu could be
replaced by "cpu" as well?)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/mach-voyager/voyager_smp.c
index 7ffcdee,58c7cac..0000000
--- a/arch/x86/mach-voyager/voyager_smp.c
+++ b/arch/x86/mach-voyager/voyager_smp.c
@@@ -1745,14 -1746,13 +1744,13 @@@ static void __init voyager_smp_prepare_
  
  static void __cpuinit voyager_smp_prepare_boot_cpu(void)
  {
- 	init_gdt(smp_processor_id());
- 	switch_to_new_gdt();
+ 	int cpu = smp_processor_id();
+ 	switch_to_new_gdt(cpu);
  
 -	cpu_set(cpu, cpu_online_map);
 -	cpu_set(cpu, cpu_callout_map);
 -	cpu_set(cpu, cpu_possible_map);
 -	cpu_set(cpu, cpu_present_map);
 +	cpu_online_map = cpumask_of_cpu(smp_processor_id());
 +	cpu_callout_map = cpumask_of_cpu(smp_processor_id());
 +	cpu_callin_map = CPU_MASK_NONE;
 +	cpu_present_map = cpumask_of_cpu(smp_processor_id());
- 
  }
  
  static int __cpuinit voyager_cpu_up(unsigned int cpu)
@@@ -1779,12 -1779,11 +1777,11 @@@ static void __init voyager_smp_cpus_don
  void __init smp_setup_processor_id(void)
  {
  	current_thread_info()->cpu = hard_smp_processor_id();
- 	x86_write_percpu(cpu_number, hard_smp_processor_id());
  }
  
 -static void voyager_send_call_func(cpumask_t callmask)
 +static void voyager_send_call_func(const struct cpumask *callmask)
  {
 -	__u32 mask = cpus_addr(callmask)[0] & ~(1 << smp_processor_id());
 +	__u32 mask = cpus_addr(*callmask)[0] & ~(1 << smp_processor_id());
  	send_CPI(mask, VIC_CALL_FUNCTION_CPI);
  }
  

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the tip-core tree with Linus' tree
@ 2009-02-02  0:46 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2009-02-02  0:46 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: linux-next, David Daney, Yinghai Lu, Mike Travis

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
kernel/irq/handle.c between commit
97179fd46da7ddedd18e95388130ed3e06c5a0c7 ("cpumask fallout: Initialize
irq_default_affinity earlier") from Linus' tree and commits
9594949b060efe86ecaa1a66839232a3b9800bc9 ("irq: change references from
NR_IRQS to nr_irqs") and 4a046d1754ee6ebb6f399696805ed61ea0444d4c ("x86:
arch_probe_nr_irqs") from the tip-core tree.

Just overlapping additions.  I fixed it up as done in tip/master (see
below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/irq/handle.c
index 3aba8d1,375d68c..0000000
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@@ -146,8 -133,10 +145,12 @@@ int __init early_irq_init(void
  	int legacy_count;
  	int i;
  
 +	init_irq_default_affinity();
 +
+ 	 /* initialize nr_irqs based on nr_cpu_ids */
+ 	arch_probe_nr_irqs();
+ 	printk(KERN_INFO "NR_IRQS:%d nr_irqs:%d\n", NR_IRQS, nr_irqs);
+ 
  	desc = irq_desc_legacy;
  	legacy_count = ARRAY_SIZE(irq_desc_legacy);
  
@@@ -233,8 -229,8 +243,10 @@@ int __init early_irq_init(void
  	int count;
  	int i;
  
 +	init_irq_default_affinity();
 +
+ 	printk(KERN_INFO "NR_IRQS:%d\n", NR_IRQS);
+ 
  	desc = irq_desc;
  	count = ARRAY_SIZE(irq_desc);
  

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2009-05-22 18:18 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-06  0:36 linux-next: manual merge of the tip-core tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2009-05-21  1:39 Stephen Rothwell
2009-05-21  3:56 ` Darren Hart
2009-05-21  9:30   ` Thomas Gleixner
2009-05-21  9:38     ` Stephen Rothwell
2009-05-22  0:19   ` Stephen Rothwell
2009-05-22  5:50     ` Stephen Rothwell
2009-05-22 18:18       ` Darren Hart
2009-02-09  0:38 Stephen Rothwell
2009-02-09  0:46 ` Chris Mason
2009-02-09  8:51   ` Ingo Molnar
2009-02-06  2:26 Stephen Rothwell
2009-02-06 13:53 ` Ingo Molnar
2009-02-02  0:46 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).