1. 28 4月, 2014 1 次提交
    • M
      arm: KVM: fix possible misalignment of PGDs and bounce page · 5d4e08c4
      Mark Salter 提交于
      The kvm/mmu code shared by arm and arm64 uses kalloc() to allocate
      a bounce page (if hypervisor init code crosses page boundary) and
      hypervisor PGDs. The problem is that kalloc() does not guarantee
      the proper alignment. In the case of the bounce page, the page sized
      buffer allocated may also cross a page boundary negating the purpose
      and leading to a hang during kvm initialization. Likewise the PGDs
      allocated may not meet the minimum alignment requirements of the
      underlying MMU. This patch uses __get_free_page() to guarantee the
      worst case alignment needs of the bounce page and PGDs on both arm
      and arm64.
      
      Cc: <stable@vger.kernel.org> # 3.10+
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      5d4e08c4
  2. 26 4月, 2014 2 次提交
  3. 25 4月, 2014 6 次提交
  4. 24 4月, 2014 8 次提交
  5. 23 4月, 2014 8 次提交
  6. 22 4月, 2014 4 次提交
    • J
      locks: rename file-private locks to "open file description locks" · 0d3f7a2d
      Jeff Layton 提交于
      File-private locks have been merged into Linux for v3.15, and *now*
      people are commenting that the name and macro definitions for the new
      file-private locks suck.
      
      ...and I can't even disagree. The names and command macros do suck.
      
      We're going to have to live with these for a long time, so it's
      important that we be happy with the names before we're stuck with them.
      The consensus on the lists so far is that they should be rechristened as
      "open file description locks".
      
      The name isn't a big deal for the kernel, but the command macros are not
      visually distinct enough from the traditional POSIX lock macros. The
      glibc and documentation folks are recommending that we change them to
      look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
      programmer will typo one of the commands wrong, and also makes it easier
      to spot this difference when reading code.
      
      This patch makes the following changes that I think are necessary before
      v3.15 ships:
      
      1) rename the command macros to their new names. These end up in the uapi
         headers and so are part of the external-facing API. It turns out that
         glibc doesn't actually use the fcntl.h uapi header, but it's hard to
         be sure that something else won't. Changing it now is safest.
      
      2) make the the /proc/locks output display these as type "OFDLCK"
      
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Carlos O'Donell <carlos@redhat.com>
      Cc: Stefan Metzmacher <metze@samba.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Frank Filz <ffilzlnx@mindspring.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      0d3f7a2d
    • S
    • S
      ARM: zynq: DT: Add 'clock-latency' property · b2bf5d48
      Soren Brinkmann 提交于
      Specify the 'clock-latency' property to avoid certain cpufreq governors
      from refusing to work with the following error:
        ondemand governor failed, too long transition latency of HW, fallback to performance governor
      Reported-by: NMike Looijmans <mike.looijmans@topic.nl>
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Tested-by: NMike Looijmans <mike.looijmans@topic.nl>
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      b2bf5d48
    • T
      ARM: OMAP2+: Fix oops for GPMC free · efe80723
      Tony Lindgren 提交于
      If gpmc_cs_remap() fails we will get an error because we are calling
      release_resource() on an uninitialized resource. Let's fix that by
      checking the resource flags. And while at it, let's also make
      gpmc_cs_delete_mem() use the res pointer that we already have to
      avoid confusion.
      
      Without this patch we can get the following error:
      
      omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300
      Unable to handle kernel NULL pointer dereference at virtual address 00000018
      ...
      (gpmc_cs_free+0x94/0xc8)
      (gpmc_probe_generic_child+0x178/0x1ec)
      (gpmc_probe_dt+0x1bc/0x2cc)
      (gpmc_probe+0x250/0x44c)
      (platform_drv_probe+0x3c/0x6c)
      (really_probe+0x74/0x208)
      (driver_probe_device+0x34/0x50)
      (bus_for_each_drv+0x60/0x8c)
      (device_attach+0x80/0xa4)
      (bus_probe_device+0x88/0xb0)
      (device_add+0x320/0x450)
      (of_platform_device_create_pdata+0x80/0x9c)
      (of_platform_bus_create+0xd0/0x170)
      (of_platform_bus_create+0x12c/0x170)
      (of_platform_populate+0x60/0x98)
      (pdata_quirks_init+0x30/0x48)
      (customize_machine+0x20/0x48)
      (do_one_initcall+0x2c/0x14c)
      (do_basic_setup+0x98/0xd8)
      (kernel_init_freeable+0x12c/0x1e0)
      (kernel_init+0x8/0xf0)
      (ret_from_fork+0x14/0x2c)
      Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018)
      
      Cc: Pekon Gupta <pekon@ti.com>
      Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
      Signed-off-by: Ntony Lindgren <tony@atomide.com>
      efe80723
  7. 19 4月, 2014 11 次提交