1. 04 7月, 2013 1 次提交
    • Z
      /dev/oldmem: Remove the interface · a11edb59
      Zhang Yanfei 提交于
      /dev/oldmem provides the interface for us to access the "old memory" in
      the dump-capture kernel.  Unfortunately, no one actually uses this
      interface.
      
      And this interface could actually cause some real problems if used on ia64
      where the cached/uncached accesses are mixed.  See the discussion from the
      link: https://lkml.org/lkml/2013/4/12/386.
      
      So Eric suggested that we should remove /dev/oldmem as an unused piece of
      code.
      
      [akpm@linux-foundation.org: mention /dev/oldmem obsolescence in devices.txt]
      Suggested-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a11edb59
  2. 29 6月, 2013 2 次提交
  3. 27 6月, 2013 1 次提交
  4. 25 6月, 2013 1 次提交
    • T
      char: misc: assign file->private_data in all cases · 585d98e0
      Thomas Petazzoni 提交于
      In fa1f68db ("drivers: misc: pass miscdevice pointer via file
      private data"), the misc driver infrastructure was changed to assigned
      file->private_data as a pointer to the 'struct miscdevice' that
      corresponds to the device being opened.
      
      However, this assignment was only done when the misc driver was
      declaring a driver-specific ->open() operation in its
      file_operations. This doesn't make sense, as the driver may not
      necessarily have a custom ->open() operation, and might still be
      interested in having file->private_data properly set for use in its
      ->read() and write() operations.
      
      Therefore, we move the assignment of file->private_data outside of the
      condition that tests whether a driver-specific ->open() operation was
      defined.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      585d98e0
  5. 19 6月, 2013 1 次提交
    • A
      hwrng: bcm2835: fix MODULE_LICENSE tag · 22e8099f
      Arnd Bergmann 提交于
      The MODULE_LICENSE macro invocation must use either "GPL" or "GPL v2",
      but not "GPLv2" in order to be detected by the module loader.
      
      This fixes the allmodconfig build error:
      
      FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NLubomir Rintel <lkundrak@v3.sk>
      Cc: Dom Cobley <popcornmix@gmail.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: linux-rpi-kernel@lists.infradead.org
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      22e8099f
  6. 18 6月, 2013 1 次提交
  7. 07 6月, 2013 1 次提交
  8. 04 6月, 2013 2 次提交
  9. 30 5月, 2013 2 次提交
  10. 25 5月, 2013 2 次提交
    • J
      random: fix accounting race condition with lockless irq entropy_count update · 10b3a32d
      Jiri Kosina 提交于
      Commit 902c098a ("random: use lockless techniques in the interrupt
      path") turned IRQ path from being spinlock protected into lockless
      cmpxchg-retry update.
      
      That commit removed r->lock serialization between crediting entropy bits
      from IRQ context and accounting when extracting entropy on userspace
      read path, but didn't turn the r->entropy_count reads/updates in
      account() to use cmpxchg as well.
      
      It has been observed, that under certain circumstances this leads to
      read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets
      corrupted and becomes negative, which in turn results in propagating 0
      all the way from account() to the actual read() call.
      
      Convert the accounting code to be the proper lockless counterpart of
      what has been partially done by 902c098a.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Greg KH <greg@kroah.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10b3a32d
    • J
      drivers/char/random.c: fix priming of last_data · 1e7e2e05
      Jarod Wilson 提交于
      Commit ec8f02da ("random: prime last_data value per fips
      requirements") added priming of last_data per fips requirements.
      
      Unfortuantely, it did so in a way that can lead to multiple threads all
      incrementing nbytes, but only one actually doing anything with the extra
      data, which leads to some fun random corruption and panics.
      
      The fix is to simply do everything needed to prime last_data in a single
      shot, so there's no window for multiple cpus to increment nbytes -- in
      fact, we won't even increment or decrement nbytes anymore, we'll just
      extract the needed EXTRACT_SIZE one time per pool and then carry on with
      the normal routine.
      
      All these changes have been tested across multiple hosts and
      architectures where panics were previously encoutered.  The code changes
      are are strictly limited to areas only touched when when booted in fips
      mode.
      
      This change should also go into 3.8-stable, to make the myriads of fips
      users on 3.8.x happy.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Tested-by: NJan Stancek <jstancek@redhat.com>
      Tested-by: NJan Stodola <jstodola@redhat.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1e7e2e05
  11. 22 5月, 2013 2 次提交
  12. 17 5月, 2013 5 次提交
  13. 12 5月, 2013 1 次提交
  14. 08 5月, 2013 2 次提交
  15. 05 5月, 2013 2 次提交
  16. 02 5月, 2013 1 次提交
  17. 01 5月, 2013 1 次提交
  18. 30 4月, 2013 3 次提交
  19. 25 4月, 2013 3 次提交
  20. 20 4月, 2013 1 次提交
  21. 17 4月, 2013 1 次提交
    • D
      TPM: Retry SaveState command in suspend path · 32d33b29
      Duncan Laurie 提交于
      If the TPM has already been sent a SaveState command before the driver
      is loaded it may have problems sending that same command again later.
      
      This issue is seen with the Chromebook Pixel due to a firmware bug in
      the legacy mode boot path which is sending the SaveState command
      before booting the kernel.  More information is available at
      http://crbug.com/203524
      
      This change introduces a retry of the SaveState command in the suspend
      path in order to work around this issue.  A future firmware update
      should fix this but this is also a trivial workaround in the driver
      that has no effect on systems that do not show this problem.
      
      When this does happen the TPM responds with a non-fatal TPM_RETRY code
      that is defined in the specification:
      
        The TPM is too busy to respond to the command immediately, but the
        command could be resubmitted at a later time.  The TPM MAY return
        TPM_RETRY for any command at any time.
      
      It can take several seconds before the TPM will respond again.  I
      measured a typical time between 3 and 4 seconds and the timeout is set
      at a safe 5 seconds.
      
      It is also possible to reproduce this with commands via /dev/tpm0.
      The bug linked above has a python script attached which can be used to
      test for this problem.  I tested a variety of TPMs from Infineon,
      Nuvoton, Atmel, and STMicro but was only able to reproduce this with
      LPC and I2C TPMs from Infineon.
      
      The TPM specification only loosely defines this behavior:
      
        TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
        The TPM MAY declare all preserved values invalid in response to any
        command other than TPM_Init.
      
        TCG PC Client BIOS Spec 1.21 section 8.3.1.
        After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
        commands before transitioning to S3 without issuing another
        TPM_SaveState command.
      
        TCG PC Client TIS 1.21, section 4. Power Management:
        The TPM_SaveState command allows a Static OS to indicate to the TPM
        that the platform may enter a low power state where the TPM will be
        required to enter into the D3 power state.  The use of the term "may"
        is significant in that there is no requirement for the platform to
        actually enter the low power state after sending the TPM_SaveState
        command.  The software may, in fact, send subsequent commands after
        sending the TPM_SaveState command.
      
      Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9
      Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
      Signed-off-by: NKent Yoder <key@linux.vnet.ibm.com>
      32d33b29
  22. 15 4月, 2013 1 次提交
  23. 13 4月, 2013 3 次提交