1. 30 10月, 2013 16 次提交
  2. 11 10月, 2013 1 次提交
  3. 07 10月, 2013 1 次提交
    • J
      MIPS: stack protector: Fix per-task canary switch · 8b3c569a
      James Hogan 提交于
      Commit 1400eb65 (MIPS: r4k,octeon,r2300: stack protector: change canary
      per task) was merged in v3.11 and introduced assembly in the MIPS resume
      functions to update the value of the current canary in
      __stack_chk_guard. However it used PTR_L resulting in a load of the
      canary value, instead of PTR_LA to construct its address. The value is
      intended to be random but is then treated as an address in the
      subsequent LONG_S (store).
      
      This was observed to cause a fault and panic:
      
      CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
      Oops[#1]:
      ...
      $24   : 139fea20 1e1f7cb6
      ...
      Call Trace:
      [<8000cc0c>] resume+0xac/0x118
      [<8034f2a4>] __schedule+0x5f8/0x78c
      [<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
      [<80348eec>] rest_init+0x74/0x84
      [<804dc990>] start_kernel+0x43c/0x454
      Code: 3c18804b  8f184030  8cb901f8 <af190000> 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc
      
      This can also be forced by modifying
      arch/mips/include/asm/stackprotector.h so that the default
      __stack_chk_guard value is more likely to be a bad (or unaligned)
      pointer.
      
      Fix it to use PTR_LA instead, to load the address of the canary value,
      which the LONG_S can then use to write into it.
      
      Reported-by: bobjones (via #mipslinux on IRC)
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Gregory Fong <gregory.0xf0@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/6026/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8b3c569a
  4. 02 10月, 2013 1 次提交
    • Y
      MIPS: Fix forgotten preempt_enable() when CPU has inclusive pcaches · 5596b0b2
      Yoichi Yuasa 提交于
      [    1.904000] BUG: scheduling while atomic: swapper/1/0x00000002
      [    1.908000] Modules linked in:
      [    1.916000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc2-lemote-los.git-5318619-dirty #1
      [    1.920000] Stack : 0000000031aac000 ffffffff810d0000 0000000000000052 ffffffff802730a4
                0000000000000000 0000000000000001 ffffffff810cdf90 ffffffff810d0000
                ffffffff8068b968 ffffffff806f5537 ffffffff810cdf90 980000009f0782e8
                0000000000000001 ffffffff80720000 ffffffff806b0000 980000009f078000
                980000009f290000 ffffffff805f312c 980000009f05b5d8 ffffffff80233518
                980000009f05b5e8 ffffffff80274b7c 980000009f078000 ffffffff8068b968
                0000000000000000 0000000000000000 0000000000000000 0000000000000000
                0000000000000000 980000009f05b520 0000000000000000 ffffffff805f2f6c
                0000000000000000 ffffffff80700000 ffffffff80700000 ffffffff806fc758
                ffffffff80700000 ffffffff8020be98 ffffffff806fceb0 ffffffff805f2f6c
                ...
      [    2.028000] Call Trace:
      [    2.032000] [<ffffffff8020be98>] show_stack+0x80/0x98
      [    2.036000] [<ffffffff805f2f6c>] __schedule_bug+0x44/0x6c
      [    2.040000] [<ffffffff805fac58>] __schedule+0x518/0x5b0
      [    2.044000] [<ffffffff805f8a58>] schedule_timeout+0x128/0x1f0
      [    2.048000] [<ffffffff80240314>] msleep+0x3c/0x60
      [    2.052000] [<ffffffff80495400>] do_probe+0x238/0x3a8
      [    2.056000] [<ffffffff804958b0>] ide_probe_port+0x340/0x7e8
      [    2.060000] [<ffffffff80496028>] ide_host_register+0x2d0/0x7a8
      [    2.064000] [<ffffffff8049c65c>] ide_pci_init_two+0x4e4/0x790
      [    2.068000] [<ffffffff8049f9b8>] amd74xx_probe+0x148/0x2c8
      [    2.072000] [<ffffffff803f571c>] pci_device_probe+0xc4/0x130
      [    2.076000] [<ffffffff80478f60>] driver_probe_device+0x98/0x270
      [    2.080000] [<ffffffff80479298>] __driver_attach+0xe0/0xe8
      [    2.084000] [<ffffffff80476ab0>] bus_for_each_dev+0x78/0xe0
      [    2.088000] [<ffffffff80478468>] bus_add_driver+0x230/0x310
      [    2.092000] [<ffffffff80479b44>] driver_register+0x84/0x158
      [    2.096000] [<ffffffff80200504>] do_one_initcall+0x104/0x160
      Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org>
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-mips@linux-mips.org
      Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/5941/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5596b0b2
  5. 30 9月, 2013 1 次提交
  6. 25 9月, 2013 1 次提交
  7. 24 9月, 2013 1 次提交
  8. 19 9月, 2013 8 次提交
  9. 18 9月, 2013 3 次提交
  10. 17 9月, 2013 2 次提交
    • R
      MIPS: Fix accessing to per-cpu data when flushing the cache · ff522058
      Ralf Baechle 提交于
      This fixes the following issue
      
      BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
      caller is blast_dcache32+0x30/0x254
      Call Trace:
      [<8047f02c>] dump_stack+0x8/0x34
      [<802e7e40>] debug_smp_processor_id+0xe0/0xf0
      [<80114d94>] blast_dcache32+0x30/0x254
      [<80118484>] r4k_dma_cache_wback_inv+0x200/0x288
      [<80110ff0>] mips_dma_map_sg+0x108/0x180
      [<80355098>] ide_dma_prepare+0xf0/0x1b8
      [<8034eaa4>] do_rw_taskfile+0x1e8/0x33c
      [<8035951c>] ide_do_rw_disk+0x298/0x3e4
      [<8034a3c4>] do_ide_request+0x2e0/0x704
      [<802bb0dc>] __blk_run_queue+0x44/0x64
      [<802be000>] queue_unplugged.isra.36+0x1c/0x54
      [<802beb94>] blk_flush_plug_list+0x18c/0x24c
      [<802bec6c>] blk_finish_plug+0x18/0x48
      [<8026554c>] journal_commit_transaction+0x3b8/0x151c
      [<80269648>] kjournald+0xec/0x238
      [<8014ac00>] kthread+0xb8/0xc0
      [<8010268c>] ret_from_kernel_thread+0x14/0x1c
      
      Caches in most systems are identical - but not always, so we can't avoid
      the use of smp_call_function() by just looking at the boot CPU's data,
      have to fiddle with preemption instead.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5835
      ff522058
    • R
      MIPS: Provide nice way to access boot CPU's data. · c5f66596
      Ralf Baechle 提交于
      boot_cpu_data is used the same as current_cpu_data but returns the CPU
      data for CPU 0.  This means it doesn't have to use smp_processor_id()
      thus no need to disable preemption.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c5f66596
  11. 13 9月, 2013 5 次提交
    • M
      MIPS: kernel: vpe: Make vpe_attrs an array of pointers. · 1b467633
      Markos Chandras 提交于
      Commit 567b21e9
      "mips: convert vpe_class to use dev_groups"
      
      broke the build on MIPS since vpe_attrs should be an array
      of 'struct device_attribute' pointers.
      
      Fixes the following build problem:
      arch/mips/kernel/vpe.c:1372:2: error: missing braces around initializer
      [-Werror=missing-braces]
      arch/mips/kernel/vpe.c:1372:2: error: (near initialization for 'vpe_attrs[0]')
      [-Werror=missing-braces]
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5819/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1b467633
    • M
      Remove GENERIC_HARDIRQ config option · 0244ad00
      Martin Schwidefsky 提交于
      After the last architecture switched to generic hard irqs the config
      options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
      for !CONFIG_GENERIC_HARDIRQS can be removed.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0244ad00
    • L
      MIPS: Fix SMP core calculations when using MT support. · 670bac3a
      Leonid Yegoshin 提交于
      The TCBIND register is only available if the core has MT support. It
      should not be read otherwise. Secondly, the number of TCs (siblings)
      are calculated differently depending on if the kernel is configured
      as SMVP or SMTC.
      Signed-off-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5822/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      670bac3a
    • M
      MIPS: DECstation I/O ASIC DMA interrupt handling fix · 5359b938
      Maciej W. Rozycki 提交于
      This change complements commit d0da7c002f7b2a93582187a9e3f73891a01d8ee4
      and brings clear_ioasic_irq back, renaming it to clear_ioasic_dma_irq at
      the same time, to make I/O ASIC DMA interrupts functional.
      
      Unlike ordinary I/O ASIC interrupts DMA interrupts need to be deasserted
      by software by writing 0 to the respective bit in I/O ASIC's System
      Interrupt Register (SIR), similarly to how CP0.Cause.IP0 and CP0.Cause.IP1
      bits are handled in the CPU (the difference is SIR DMA interrupt bits are
      R/W0C so there's no need for an RMW cycle).  Otherwise the handler is
      reentered over and over again.
      
      The only current user is the DEC LANCE Ethernet driver and its extremely
      uncommon DMA memory error handler that does not care when exactly the
      interrupt is cleared.  Anticipating the use of DMA interrupts by the Zilog
      SCC driver this change however exports clear_ioasic_dma_irq for device
      drivers to choose the right application-specific sequence to clear the
      request explicitly rather than calling it implicitly in the .irq_eoi
      handler of `struct irq_chip'.  Previously these interrupts were cleared in
      the .end handler of the said structure, before it was removed.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5826/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5359b938
    • M
      MIPS: DECstation HRT initialization rearrangement · daed1285
      Maciej W. Rozycki 提交于
      Not all I/O ASIC versions have the free-running counter implemented, an
      early revision used in the 5000/1xx models aka 3MIN and 4MIN did not have
      it.  Therefore we cannot unconditionally use it as a clock source.
      Fortunately if not implemented its register slot has a fixed value so it
      is enough if we check for the value at the end of the calibration period
      being the same as at the beginning.
      
      This also means we need to look for another high-precision clock source on
      the systems affected.  The 5000/1xx can have an R4000SC processor
      installed where the CP0 Count register can be used as a clock source.
      Unfortunately all the R4k DECstations suffer from the missed timer
      interrupt on CP0 Count reads erratum, so we cannot use the CP0 timer as a
      clock source and a clock event both at a time.  However we never need an
      R4k clock event device because all DECstations have a DS1287A RTC chip
      whose periodic interrupt can be used as a clock source.
      
      This gives us the following four configuration possibilities for I/O ASIC
      DECstations:
      
      1. No I/O ASIC counter and no CP0 timer, e.g. R3k 5000/1xx (3MIN).
      
      2. No I/O ASIC counter but the CP0 timer, i.e. R4k 5000/150 (4MIN).
      
      3. The I/O ASIC counter but no CP0 timer, e.g. R3k 5000/240 (3MAX+).
      
      4. The I/O ASIC counter and the CP0 timer, e.g. R4k 5000/260 (4MAX+).
      
      For #1 and #2 this change stops the I/O ASIC free-running counter from
      being installed as a clock source of a 0Hz frequency.  For #2 it also
      arranges for the CP0 timer to be used as a clock source rather than a
      clock event device, because having an accurate wall clock is more
      important than a high-precision interval timer.  For #3 there is no
      change.  For #4 the change makes the I/O ASIC free-running counter
      installed as a clock source so that the CP0 timer can be used as a clock
      event device.
      
      Unfortunately the use of the CP0 timer as a clock event device relies on a
      succesful completion of c0_compare_interrupt.  That never happens, because
      while waiting for a CP0 Compare interrupt to happen the function spins in
      a loop reading the CP0 Count register.  This makes the CP0 Count erratum
      trigger reliably causing the interrupt waited for to be lost in all cases.
      As a result #4 resorts to using the CP0 timer as a clock source as well,
      just as #2.  However we want to keep this separate arrangement in case
      (hope) c0_compare_interrupt is eventually rewritten such that it avoids
      the erratum.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5825/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      daed1285