1. 06 Aug, 2011 8 commits
    • Linus Torvalds's avatar
      f38092b5
    • John Stanley's avatar
      savagedb: Fix typo causing regression in savage4 series video chip detection · 4b00e4b3
      John Stanley authored
      Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES
      macro was incompletely modified, resulting in a false positive detection
      of a savage4 card regardless of which savage card is actually present.
      
      For non-savage4 series cards, such as a Savage/IX-MV card, this results
      in garbled video and/or a hard-hang at boot time.  Fix this by changing
      an '||' to an '&&' in the S3_SAVAGE4_SERIES macro.
      Signed-off-by: default avatarJohn P. Stanley <jpsinthemix@verizon.net>
      Reviewed-by: default avatarTormod Volden <debian.tormod@gmail.com>
      [ The macros have incomplete parenthesis too, but whatever ..  -Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4b00e4b3
    • Josh Triplett's avatar
      CodingStyle: Document the exception of not splitting user-visible strings, for grepping · 6f76b6fc
      Josh Triplett authored
      Patch reviewers now recommend not splitting long user-visible strings,
      such as printk messages, even if they exceed 80 columns.  This avoids
      breaking grep.  However, that recommendation did not actually appear
      anywhere in Documentation/CodingStyle.
      
      See, for example, the thread at
        http://news.gmane.org/find-root.php?message_id=%3c1312215262.11635.15.camel%40Joe%2dLaptop%3eSigned-off-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6f76b6fc
    • Linus Torvalds's avatar
      vfs: show O_CLOEXE bit properly in /proc/<pid>/fdinfo/<fd> files · 1117f72e
      Linus Torvalds authored
      The CLOEXE bit is magical, and for performance (and semantic) reasons we
      don't actually maintain it in the file descriptor itself, but in a
      separate bit array.  Which means that when we show f_flags, the CLOEXE
      status is shown incorrectly: we show the status not as it is now, but as
      it was when the file was opened.
      
      Fix that by looking up the bit properly in the 'fdt->close_on_exec' bit
      array.
      
      Uli needs this in order to re-implement the pfiles program:
      
        "For normal file descriptors (not sockets) this was the last piece of
         information which wasn't available.  This is all part of my 'give
         Solaris users no reason to not switch' effort.  I intend to offer the
         code to the util-linux-ng maintainers."
      Requested-by: default avatarUlrich Drepper <drepper@akkadia.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1117f72e
    • Linus Torvalds's avatar
      oom_ajd: don't use WARN_ONCE, just use printk_once · c2142704
      Linus Torvalds authored
      WARN_ONCE() is very annoying, in that it shows the stack trace that we
      don't care about at all, and also triggers various user-level "kernel
      oopsed" logic that we really don't care about.  And it's not like the
      user can do anything about the applications (sshd) in question, it's a
      distro issue.
      
      Requested-by: Andi Kleen <andi@firstfloor.org> (and many others)
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c2142704
    • Mandeep Singh Baines's avatar
      lib/sha1: use the git implementation of SHA-1 · 1eb19a12
      Mandeep Singh Baines authored
      For ChromiumOS, we use SHA-1 to verify the integrity of the root
      filesystem.  The speed of the kernel sha-1 implementation has a major
      impact on our boot performance.
      
      To improve boot performance, we investigated using the heavily optimized
      sha-1 implementation used in git.  With the git sha-1 implementation, we
      see a 11.7% improvement in boot time.
      
      10 reboots, remove slowest/fastest.
      
      Before:
      
        Mean: 6.58 seconds Stdev: 0.14
      
      After (with git sha-1, this patch):
      
        Mean: 5.89 seconds Stdev: 0.07
      
      The other cool thing about the git SHA-1 implementation is that it only
      needs 64 bytes of stack for the workspace while the original kernel
      implementation needed 320 bytes.
      Signed-off-by: default avatarMandeep Singh Baines <msb@chromium.org>
      Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
      Cc: Nicolas Pitre <nico@cam.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: linux-crypto@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1eb19a12
    • Len Brown's avatar
      Merge branch 'battery' into release · 5389102e
      Len Brown authored
      5389102e
    • Sergey Senozhatsky's avatar
      Battery: sysfs_remove_battery(): possible circular locking · 69d94ec6
      Sergey Senozhatsky authored
      Commit 9c921c22
      Author: Lan Tianyu <tianyu.lan@intel.com>
      
          ACPI / Battery: Resolve the race condition in the sysfs_remove_battery()
      
      fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side
      effect made lockdep unhappy with sysfs_remove_battery():
      
      [14818.477168]
      [14818.477170] =======================================================
      [14818.477200] [ INFO: possible circular locking dependency detected ]
      [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668
      [14818.477236] -------------------------------------------------------
      [14818.477257] s2ram/1599 is trying to acquire lock:
      [14818.477276]  (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a
      [14818.477323]
      [14818.477325] but task is already holding lock:
      [14818.477350]  (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery]
      [14818.477395]
      [14818.477397] which lock already depends on the new lock.
      [14818.477399]
      [..]
      [14818.479121] stack backtrace:
      [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668
      [14818.479175] Call Trace:
      [14818.479198]  [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4
      [14818.479228]  [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b
      [14818.479260]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
      [14818.479288]  [<ffffffff810718d2>] lock_acquire+0x138/0x1ac
      [14818.479316]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
      [14818.479345]  [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec
      [14818.479373]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
      [14818.479405]  [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a
      [14818.479433]  [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77
      [14818.479461]  [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14
      [14818.479488]  [<ffffffff81385bf8>] device_remove_file+0x12/0x14
      [14818.479516]  [<ffffffff81386504>] device_del+0x119/0x17c
      [14818.479542]  [<ffffffff81386575>] device_unregister+0xe/0x1a
      [14818.479570]  [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27
      [14818.479601]  [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery]
      [14818.479632]  [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery]
      [14818.479662]  [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1
      [14818.479692]  [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89
      [14818.479722]  [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11
      [14818.479751]  [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27
      [14818.479770]  [<ffffffff8107ee1a>] enter_state+0xa7/0xd5
      [14818.479782]  [<ffffffff8107e341>] state_store+0xaa/0xc0
      [14818.479795]  [<ffffffff8107e297>] ? pm_async_store+0x45/0x45
      [14818.479807]  [<ffffffff81248837>] kobj_attr_store+0x17/0x19
      [14818.479820]  [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f
      [14818.479834]  [<ffffffff81109037>] vfs_write+0xad/0x13d
      [14818.479847]  [<ffffffff811092b2>] sys_write+0x45/0x6c
      [14818.479860]  [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b
      
      This patch introduces separate lock to struct acpi_battery to
      grab in sysfs_remove_battery() instead of battery->lock.
      So fix by Lan Tianyu is still there, we just grab independent lock.
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Tested-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      69d94ec6
  2. 05 Aug, 2011 19 commits
  3. 04 Aug, 2011 13 commits