* 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 = ¤t_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 = ¤t_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).