1. 24 12月, 2010 4 次提交
    • L
      Merge branches 'perf-fixes-for-linus' and 'x86-fixes-for-linus' of... · 79534f23
      Linus Torvalds 提交于
      Merge branches 'perf-fixes-for-linus' and 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        perf probe: Fix to support libdwfl older than 0.148
        perf tools: Fix lazy wildcard matching
        perf buildid-list: Fix error return for success
        perf buildid-cache: Fix symbolic link handling
        perf symbols: Stop using vmlinux files with no symbols
        perf probe: Fix use of kernel image path given by 'k' option
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86, kexec: Limit the crashkernel address appropriately
      79534f23
    • D
      KEYS: Don't call up_write() if __key_link_begin() returns an error · 3fc5e98d
      David Howells 提交于
      In construct_alloc_key(), up_write() is called in the error path if
      __key_link_begin() fails, but this is incorrect as __key_link_begin() only
      returns with the nominated keyring locked if it returns successfully.
      
      Without this patch, you might see the following in dmesg:
      
      	=====================================
      	[ BUG: bad unlock balance detected! ]
      	-------------------------------------
      	mount.cifs/5769 is trying to release lock (&key->sem) at:
      	[<ffffffff81201159>] request_key_and_link+0x263/0x3fc
      	but there are no more locks to release!
      
      	other info that might help us debug this:
      	3 locks held by mount.cifs/5769:
      	 #0:  (&type->s_umount_key#41/1){+.+.+.}, at: [<ffffffff81131321>] sget+0x278/0x3e7
      	 #1:  (&ret_buf->session_mutex){+.+.+.}, at: [<ffffffffa0258e59>] cifs_get_smb_ses+0x35a/0x443 [cifs]
      	 #2:  (root_key_user.cons_lock){+.+.+.}, at: [<ffffffff81201000>] request_key_and_link+0x10a/0x3fc
      
      	stack backtrace:
      	Pid: 5769, comm: mount.cifs Not tainted 2.6.37-rc6+ #1
      	Call Trace:
      	 [<ffffffff81201159>] ? request_key_and_link+0x263/0x3fc
      	 [<ffffffff81081601>] print_unlock_inbalance_bug+0xca/0xd5
      	 [<ffffffff81083248>] lock_release_non_nested+0xc1/0x263
      	 [<ffffffff81201159>] ? request_key_and_link+0x263/0x3fc
      	 [<ffffffff81201159>] ? request_key_and_link+0x263/0x3fc
      	 [<ffffffff81083567>] lock_release+0x17d/0x1a4
      	 [<ffffffff81073f45>] up_write+0x23/0x3b
      	 [<ffffffff81201159>] request_key_and_link+0x263/0x3fc
      	 [<ffffffffa026fe9e>] ? cifs_get_spnego_key+0x61/0x21f [cifs]
      	 [<ffffffff812013c5>] request_key+0x41/0x74
      	 [<ffffffffa027003d>] cifs_get_spnego_key+0x200/0x21f [cifs]
      	 [<ffffffffa026e296>] CIFS_SessSetup+0x55d/0x1273 [cifs]
      	 [<ffffffffa02589e1>] cifs_setup_session+0x90/0x1ae [cifs]
      	 [<ffffffffa0258e7e>] cifs_get_smb_ses+0x37f/0x443 [cifs]
      	 [<ffffffffa025a9e3>] cifs_mount+0x1aa1/0x23f3 [cifs]
      	 [<ffffffff8111fd94>] ? alloc_debug_processing+0xdb/0x120
      	 [<ffffffffa027002c>] ? cifs_get_spnego_key+0x1ef/0x21f [cifs]
      	 [<ffffffffa024cc71>] cifs_do_mount+0x165/0x2b3 [cifs]
      	 [<ffffffff81130e72>] vfs_kern_mount+0xaf/0x1dc
      	 [<ffffffff81131007>] do_kern_mount+0x4d/0xef
      	 [<ffffffff811483b9>] do_mount+0x6f4/0x733
      	 [<ffffffff8114861f>] sys_mount+0x88/0xc2
      	 [<ffffffff8100ac42>] system_call_fastpath+0x16/0x1b
      Reported-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-and-Tested-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3fc5e98d
    • A
      cs5535-gpio: handle GPIO regs where higher (clear) bits are set · 44658a11
      Andres Salomon 提交于
      The default for non-READ_BACK GPIO regs is to have the clear bits set;
      this means that our original errata fix was too simplistic.  This
      changes it to the following behavior:
      
       - when setting GPIOs, ignore the higher order bits (they're for
         clearing, we don't need to care about them).
      
       - when clearing GPIOs, keep all the bits, but unset (via XOR) the
         lower order bit that negates the clear bit that we care about.  That
         is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
         currently in the register with 0x0400 (GPIO 26's SET bit), and then
         OR that with the GPIO 26's CLEAR bit.
      Tested-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      44658a11
    • A
      cs5535-gpio: don't apply errata #36 to edge detect GPIOs · 00185165
      Andres Salomon 提交于
      The edge detect status GPIOs function differently from the other atomic
      model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
      but writing 1 to the lower bits also clears the bit.
      
      This means that read-modify-write doesn't actually work for it, so don't
      apply the errata here.  If a negative edge status gets lost after
      resume..  well, we tried our best!
      Tested-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00185165
  2. 23 12月, 2010 16 次提交
  3. 22 12月, 2010 11 次提交
  4. 21 12月, 2010 9 次提交