1. 18 12月, 2012 4 次提交
  2. 11 10月, 2012 1 次提交
    • P
      tpm: Propagate error from tpm_transmit to fix a timeout hang · abce9ac2
      Peter Huewe 提交于
      tpm_write calls tpm_transmit without checking the return value and
      assigns the return value unconditionally to chip->pending_data, even if
      it's an error value.
      This causes three bugs.
      
      So if we write to /dev/tpm0 with a tpm_param_size bigger than
      TPM_BUFSIZE=0x1000 (e.g. 0x100a)
      and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
      tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
      -7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
      been written to the TPM, altough this is not true (bug #1).
      
      As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
      that only TPM_BUFSIZE bytes have been written the vfs tries to write
      the remaining bytes (in this case 10 bytes) to the tpm device driver via
      tpm_write which then blocks at
      
       /* cannot perform a write until the read has cleared
       either via tpm_read or a user_read_timer timeout */
       while (atomic_read(&chip->data_pending) != 0)
      	 msleep(TPM_TIMEOUT);
      
      for 60 seconds, since data_pending is -7 and nobody is able to
      read it (since tpm_read luckily checks if data_pending is greater than
      0) (#bug 2).
      
      After that the remaining bytes are written to the TPM which are
      interpreted by the tpm as a normal command. (bug #3)
      So if the last bytes of the command stream happen to be a e.g.
      tpm_force_clear this gets accidentally sent to the TPM.
      
      This patch fixes all three bugs, by propagating the error code of
      tpm_write and returning -E2BIG if the input buffer is too big,
      since the response from the tpm for a truncated value is bogus anyway.
      Moreover it returns -EBUSY to userspace if there is a response ready to be
      read.
      Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
      Signed-off-by: NKent Yoder <key@linux.vnet.ibm.com>
      abce9ac2
  3. 10 10月, 2012 1 次提交
  4. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  5. 07 10月, 2012 1 次提交
    • A
      ARM: footbridge: nw_gpio_lock is raw_spin_lock · 45ef6ac6
      Arnd Bergmann 提交于
      bd31b859 "locking, ARM: Annotate low level hw locks as raw"
      made nw_gpio_lock a raw spinlock, but did not change all the
      users in device drivers. This fixes the remaining ones.
      
      sound/oss/waveartist.c: In function 'vnc_mute_spkr':
      sound/oss/waveartist.c:1485:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
      include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
      drivers/char/ds1620.c: In function 'netwinder_lock':
      drivers/char/ds1620.c:77:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
      include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
      drivers/char/nwflash.c: In function 'kick_open':
      drivers/char/nwflash.c:620:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
      include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      45ef6ac6
  6. 06 10月, 2012 1 次提交
  7. 28 9月, 2012 5 次提交
  8. 27 9月, 2012 3 次提交
  9. 26 9月, 2012 1 次提交
    • M
      Fix a crash when block device is read and block size is changed at the same time · b87570f5
      Mikulas Patocka 提交于
      The kernel may crash when block size is changed and I/O is issued
      simultaneously.
      
      Because some subsystems (udev or lvm) may read any block device anytime,
      the bug actually puts any code that changes a block device size in
      jeopardy.
      
      The crash can be reproduced if you place "msleep(1000)" to
      blkdev_get_blocks just before "bh->b_size = max_blocks <<
      inode->i_blkbits;".
      Then, run "dd if=/dev/ram0 of=/dev/null bs=4k count=1 iflag=direct"
      While it is waiting in msleep, run "blockdev --setbsz 2048 /dev/ram0"
      You get a BUG.
      
      The direct and non-direct I/O is written with the assumption that block
      size does not change. It doesn't seem practical to fix these crashes
      one-by-one there may be many crash possibilities when block size changes
      at a certain place and it is impossible to find them all and verify the
      code.
      
      This patch introduces a new rw-lock bd_block_size_semaphore. The lock is
      taken for read during I/O. It is taken for write when changing block
      size. Consequently, block size can't be changed while I/O is being
      submitted.
      
      For asynchronous I/O, the patch only prevents block size change while
      the I/O is being submitted. The block size can change when the I/O is in
      progress or when the I/O is being finished. This is acceptable because
      there are no accesses to block size when asynchronous I/O is being
      finished.
      
      The patch prevents block size changing while the device is mapped with
      mmap.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b87570f5
  10. 24 9月, 2012 3 次提交
  11. 20 9月, 2012 2 次提交
    • C
      agp/intel: Use a write-combining map for updating PTEs · edef7e68
      Chris Wilson 提交于
      Rewriting the PTE entries using an WC mapping is roughly an order of
      magnitude faster than through the uncached mapping. This makes an
      observable difference on workloads that cycle through large numbers of
      buffers, for example Chromium using ShmPixmaps where virtually all the
      CPU time is currently spent rebinding the userptr.
      
      v2: Limit the WC mapping to older generations as we have observed that
      the TLB invalidation on SandyBridge+ is unreliable with WC updates.
      See i-g-t/tests/gem_gtt_cpu_tlb
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      edef7e68
    • C
      drm/i915: Replace the array of pages with a scatterlist · 9da3da66
      Chris Wilson 提交于
      Rather than have multiple data structures for describing our page layout
      in conjunction with the array of pages, we can migrate all users over to
      a scatterlist.
      
      One major advantage, other than unifying the page tracking structures,
      this offers is that we replace the vmalloc'ed array (which can be up to
      a megabyte in size) with a chain of individual pages which helps reduce
      memory pressure.
      
      The disadvantage is that we then do not have a simple array to iterate,
      or to access randomly. The common case for this is in the relocation
      processing, which will typically fit within a single scatterlist page
      and so be almost the same cost as the simple array. For iterating over
      the array, the extra function call could be optimised away, but in
      reality is an insignificant cost of either binding the pages, or
      performing the pwrite/pread.
      
      v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
      trivial compile error from rebasing.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9da3da66
  12. 18 9月, 2012 1 次提交
  13. 12 9月, 2012 1 次提交
  14. 07 9月, 2012 2 次提交
    • F
      hwrng: mxc-rnga - Access data via structure · 821873ab
      Fabio Estevam 提交于
      In current driver, everytime we need to access the rng clock
      ,ie to enable or disable it, a call to clk_get is done.
      
      This is not correct and the preferred way is to provide a rng data structure
      that could be used for accessing rng resources.
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      821873ab
    • F
      hwrng: mxc-rnga - Adapt clocks to new i.mx clock framework · a9ccb7bd
      Fabio Estevam 提交于
      Adapt clocks to the new i.mx clock framework and fix the following warning:
      
      ------------[ cut here ]------------
      WARNING: at drivers/clk/clk.c:511 __clk_enable+0x9c/0xac()
      Modules linked in:
      Backtrace:
      [<800124c8>] (dump_backtrace+0x0/0x10c) from [<804172dc>] (dump_stack+0x18/0x1c)
       r7:00000009 r6:000001ff r5:8032cb50 r4:00000000
      [<804172c4>] (dump_stack+0x0/0x1c) from [<80021834>] (warn_slowpath_common+0x54)
      [<800217e0>] (warn_slowpath_common+0x0/0x6c) from [<80021870>] (warn_slowpath_n)
       r9:80581cac r8:8700a9c0 r7:805ab070 r6:80000013 r5:806133d4
      r4:8700a9c0
      [<8002184c>] (warn_slowpath_null+0x0/0x2c) from [<8032cb50>] (__clk_enable+0x9c)
      [<8032cab4>] (__clk_enable+0x0/0xac) from [<8032cb88>] (clk_enable+0x28/0x44)
       r5:806133d4 r4:8700a9c0
      [<8032cb60>] (clk_enable+0x0/0x44) from [<80560f14>] (mxc_rnga_probe+0x68/0x164)
       r7:805ab070 r6:8706ec00 r5:80611314 r4:00000000
      [<80560eac>] (mxc_rnga_probe+0x0/0x164) from [<8025914c>] (platform_drv_probe+0)
      [<8025912c>] (platform_drv_probe+0x0/0x24) from [<80257c7c>] (driver_probe_devi)
      [<80257bfc>] (driver_probe_device+0x0/0x204) from [<80257e94>] (__driver_attach)
       r9:80581cac r8:0000008e r7:00000000 r6:8706ec3c r5:805ab070
      r4:8706ec08
      [<80257e00>] (__driver_attach+0x0/0x98) from [<8025642c>] (bus_for_each_dev+0x6)
       r7:00000000 r6:80257e00 r5:87035e98 r4:805ab070
      [<802563c4>] (bus_for_each_dev+0x0/0x94) from [<80257adc>] (driver_attach+0x20/)
       r7:00000000 r6:873f2380 r5:805ab338 r4:805ab070
      [<80257abc>] (driver_attach+0x0/0x28) from [<80256d50>] (bus_add_driver+0x18c/0)
      [<80256bc4>] (bus_add_driver+0x0/0x268) from [<802584c4>] (driver_register+0x80)
      [<80258444>] (driver_register+0x0/0x134) from [<802594f4>] (platform_driver_reg)
       r7:00000000 r6:805c2e00 r5:00000007 r4:805ab05c
      [<802594a8>] (platform_driver_register+0x0/0x60) from [<80259528>] (platform_dr)
      [<80259508>] (platform_driver_probe+0x0/0xa4) from [<80560ea0>] (mod_init+0x18/)
       r7:00000000 r6:805c2e00 r5:00000007 r4:87034000
      [<80560e88>] (mod_init+0x0/0x24) from [<800086b4>] (do_one_initcall+0x40/0x194)
      [<80008674>] (do_one_initcall+0x0/0x194) from [<8053d3f4>] (kernel_init+0xfc/0x)
      [<8053d2f8>] (kernel_init+0x0/0x1cc) from [<80027190>] (do_exit+0x0/0x7ec)
      ---[ end trace 4198eed02050f461 ]---
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a9ccb7bd
  15. 06 9月, 2012 3 次提交
  16. 05 9月, 2012 1 次提交
  17. 23 8月, 2012 9 次提交