Skip to content

L
linux-davinci
Switch branch/tag
  1. 30 Jan, 2009 2 commits
    • Steven Rostedt's avatar
      generic-ipi: use per cpu data for single cpu ipi calls · d7240b98
      Steven Rostedt authored 
      The smp_call_function can be passed a wait parameter telling it to
wait for all the functions running on other CPUs to complete before
returning, or to return without waiting. Unfortunately, this is
currently just a suggestion and not manditory. That is, the
smp_call_function can decide not to return and wait instead.

The reason for this is because it uses kmalloc to allocate storage
to send to the called CPU and that CPU will free it when it is done.
But if we fail to allocate the storage, the stack is used instead.
This means we must wait for the called CPU to finish before
continuing.

Unfortunatly, some callers do no abide by this hint and act as if
the non-wait option is mandatory. The MTRR code for instance will
deadlock if the smp_call_function is set to wait. This is because
the smp_call_function will wait for the other CPUs to finish their
called functions, but those functions are waiting on the caller to
continue.

This patch changes the generic smp_call_function code to use per cpu
variables if the allocation of the data fails for a single CPU call. The
smp_call_function_many will fall back to the smp_call_function_single
if it fails its alloc. The smp_call_function_single is modified
to not force the wait state.

Since we now are using a single data per cpu we must synchronize the
callers to prevent a second caller modifying the data before the
first called IPI functions complete. To do so, I added a flag to
the call_single_data called CSD_FLAG_LOCK. When the single CPU is
called (which can be called when a many call fails an alloc), we
set the LOCK bit on this per cpu data. When the caller finishes
it clears the LOCK bit.

The caller must wait till the LOCK bit is cleared before setting
it. When it is cleared, there is no IPI function using it.
Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: default avatarJens Axboe <jens.axboe@oracle.com>
Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d7240b98
    • Rusty Russell's avatar
      cpumask: convert lib/smp_processor_id to new cpumask ops · 4ab0a940
      Rusty Russell authored 
      Impact: fix debug_smp_processor_id() for CONFIG_CPUMASK_OFFSTACK=y

The scheduler now uses the new cpumask API, which deals up to
nr_cpumask_bits, whereas the API used NR_CPUS bits.

If CONFIG_CPUMASK_OFFSTACK=y these two are not equal, so the top bits
are undefined.  Leading to bug 12518 "BUG: using smp_processor_id() in
preemptible [00000000] code: dellWirelessCtl/..."

The fix is simple: use the modern API in the check.
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: default avatarMike Travis <travis@sgi.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4ab0a940
  3. 26 Jan, 2009 31 commits
  5. 25 Jan, 2009 2 commits
  7. 23 Jan, 2009 5 commits
    • Ian Campbell's avatar
      xen: handle highmem pages correctly when shrinking a domain · ff4ce8c3
      Ian Campbell authored 
      Commit 1058a75f ("xen: actually release
memory when shrinking domain") causes a crash if the page being released
is a highmem page.

If a page is highmem then there is no need to unmap it.
Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ff4ce8c3
    • Peter Zijlstra's avatar
      x86, mm: fix pte_free() · 42ef73fe
      Peter Zijlstra authored 
      On -rt we were seeing spurious bad page states like:

Bad page state in process 'firefox'
page:c1bc2380 flags:0x40000000 mapping:c1bc2390 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 503, comm: firefox Not tainted 2.6.26.8-rt13 #3
[<c043d0f3>] ? printk+0x14/0x19
[<c0272d4e>] bad_page+0x4e/0x79
[<c0273831>] free_hot_cold_page+0x5b/0x1d3
[<c02739f6>] free_hot_page+0xf/0x11
[<c0273a18>] __free_pages+0x20/0x2b
[<c027d170>] __pte_alloc+0x87/0x91
[<c027d25e>] handle_mm_fault+0xe4/0x733
[<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
[<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
[<c0218875>] do_page_fault+0x36f/0x88a

This is the case where a concurrent fault already installed the PTE and
we get to free the newly allocated one.

This is due to pgtable_page_ctor() doing the spin_lock_init(&page->ptl)
which is overlaid with the {private, mapping} struct.

union {
    struct {
        unsigned long private;
        struct address_space *mapping;
    };
    spinlock_t ptl;
    struct kmem_cache *slab;
    struct page *first_page;
};

Normally the spinlock is small enough to not stomp on page->mapping, but
PREEMPT_RT=y has huge 'spin'locks.

But lockdep kernels should also be able to trigger this splat, as the
lock tracking code grows the spinlock to cover page->mapping.

The obvious fix is calling pgtable_page_dtor() like the regular pte free
path __pte_free_tlb() does.

It seems all architectures except x86 and nm10300 already do this, and
nm10300 doesn't seem to use pgtable_page_ctor(), which suggests it
doesn't do SMP or simply doesnt do MMU at all or something.
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlsta@chello.nl>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
      42ef73fe
    • Takashi Iwai's avatar
      Merge branch 'fix/asoc' into for-linus · 0f0779b1
      Takashi Iwai authored
      0f0779b1
    • Michael Holzheu's avatar
      [S390] Add missing compat system call wrappers. · e34a6280
      Michael Holzheu authored 
      Add wrapper functions for the following compat system calls:
* readahead
* sendfile64
* tkill
* tgkill
* keyctl
This ensures that the high order bits of the parameter registers are correctly
sign extended.
Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      e34a6280
    • Heiko Carstens's avatar
      [S390] etr/stp: fix possible deadlock · 179cb81a
      Heiko Carstens authored 
      Precreate stop_machine threads in case the machine supports ETR/STP.
Otherwise we might deadlock if a time sync operation gets scheduled
and the creation of stop_machine threads would cause disk I/O.
This is just the minimal fix.
The real fix would be to only precreate stop_machine threads if
ETR/STP is actually used. But that would be a rather large and
complicated patch.
Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      179cb81a