1. 06 May, 2010 20 commits
  2. 05 May, 2010 20 commits
    • Linus Torvalds's avatar
      Merge branch 'zerolen' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6 · 722154e4
      Linus Torvalds authored
      * 'zerolen' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6:
        [MTD] Remove zero-length files mtdbdi.c and internal.ho
      722154e4
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · 1d7746cb
      Linus Torvalds authored
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        pata_pcmcia / ide-cs: Fix bad hashes for Transcend and kingston IDs
        libata: Fix several inaccuracies in developer's guide
      1d7746cb
    • Jeff Garzik's avatar
      [MTD] Remove zero-length files mtdbdi.c and internal.ho · 0fd6b32b
      Jeff Garzik authored
      Both were "removed" in commit a33eb6b9.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      0fd6b32b
    • Kristoffer Ericson's avatar
      pata_pcmcia / ide-cs: Fix bad hashes for Transcend and kingston IDs · 85ea2d3f
      Kristoffer Ericson authored
      This patch fixes the bad hashes for one Kingston and one Transcend card.
      Thanks to komuro for pointing this out.
      Signed-off-by: default avatarKristoffer Ericson <kristoffer.ericson@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      85ea2d3f
    • Sergei Shtylyov's avatar
      libata: Fix several inaccuracies in developer's guide · 40868c85
      Sergei Shtylyov authored
      Commit 6bfff31e (libata: kill probe_ent
      and related helpers) killed ata_device_add() but didn't remove references
      to it from the libata developer's guide.
      
      Commits 9363c382 (libata: rename SFF
      functions) and 5682ed33 (libata: rename
      SFF port ops) renamed the taskfile access methods but didn't update the
      developer's guide.  Commit c9f75b04
      (libata: kill ata_noop_dev_select()) didn't update the developer's
      guide as well.
      
      The guide also refers to the long gone ata_pio_data_xfer_noirq(),
      ata_pio_data_xfer(), and ata_mmio_data_xfer() -- replace those by
      the modern ata_sff_data_xfer_noirq(), ata_sff_data_xfer(), and
      ata_sff_data_xfer32().
      
      Also, remove the reference to non-existant ata_port_stop()...
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      40868c85
    • Linus Torvalds's avatar
      Merge branch 'slab-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 · 65be2f50
      Linus Torvalds authored
      * 'slab-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
        slub: Fix bad boundary check in init_kmem_cache_nodes()
      65be2f50
    • Zhang, Yanmin's avatar
      slub: Fix bad boundary check in init_kmem_cache_nodes() · 111c7d82
      Zhang, Yanmin authored
      Function init_kmem_cache_nodes is incorrect when checking upper limitation of
      kmalloc_caches. The breakage was introduced by commit
      91efd773 ("dma kmalloc handling fixes").
      Acked-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      111c7d82
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of... · 5f233706
      Linus Torvalds authored
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
        KEYS: call_sbin_request_key() must write lock keyrings before modifying them
        KEYS: Use RCU dereference wrappers in keyring key type code
        KEYS: find_keyring_by_name() can gain access to a freed keyring
      5f233706
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq · 8777c793
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
        workqueue: flush_delayed_work: keep the original workqueue for re-queueing
      8777c793
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 7437e7d3
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        FEC: Fix kernel panic in fec_set_mac_address.
        ipv6: Fix default multicast hops setting.
        net: ep93xx_eth stops receiving packets
        drivers/net/phy: micrel phy driver
        dm9601: fix phy/eeprom write routine
        ppp_generic: handle non-linear skbs when passing them to pppd
        ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid
        net: fix compile error due to double return type in SOCK_DEBUG
        net/usb: initiate sync sequence in sierra_net.c driver
        net/usb: remove default in Kconfig for sierra_net driver
        r8169: Fix rtl8169_rx_interrupt()
        e1000e: Fix oops caused by ASPM patch.
        net/sb1250: register mdio bus in probe
        sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)
        p54pci: fix bugs in p54p_check_tx_ring
      7437e7d3
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 · 38c9e91b
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
        ALSA: hda: Fix 0 dB for Packard Bell models using Conexant CX20549 (Venice)
        ALSA: hda - Add quirk for Dell Inspiron 19T using a Conexant CX20582
        ALSA: take tu->qlock with irqs disabled
        ALSA: hda: Use olpc-xo-1_5 quirk for Toshiba Satellite P500-PSPGSC-01800T
        ALSA: hda: Use olpc-xo-1_5 quirk for Toshiba Satellite Pro T130-15F
        ALSA: hda - fix array indexing while creating inputs for Cirrus codecs
        ALSA: es968: fix wrong PnP dma index
      38c9e91b
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · 1d7aec30
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: joydev - allow binding to button-only devices
        Input: elantech - ignore high bits in the position coordinates
        Input: elantech - allow forcing Elantech protocol
        Input: elantech - fix firmware version check
        Input: ati_remote - add some missing devices from lirc_atiusb
        Input: eeti_ts - cancel pending work when going to suspend
        Input: Add support of Synaptics Clickpad device
        Revert "Input: ALPS - add signature for HP Pavilion dm3 laptops"
        Input: psmouse - ignore parity error for basic protocols
      1d7aec30
    • Dan Williams's avatar
      raid6: fix recovery performance regression · 5157b4aa
      Dan Williams authored
      The raid6 recovery code should immediately drop back to the optimized
      synchronous path when a p+q dma resource is not available.  Otherwise we
      run the non-optimized/multi-pass async code in sync mode.
      
      Verified with raid6test (NDISKS=255)
      
      Applies to kernels >= 2.6.32.
      
      Cc: <stable@kernel.org>
      Acked-by: default avatarNeilBrown <neilb@suse.de>
      Reported-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5157b4aa
    • David Howells's avatar
      KEYS: call_sbin_request_key() must write lock keyrings before modifying them · 896903c2
      David Howells authored
      call_sbin_request_key() creates a keyring and then attempts to insert a link to
      the authorisation key into that keyring, but does so without holding a write
      lock on the keyring semaphore.
      
      It will normally get away with this because it hasn't told anyone that the
      keyring exists yet.  The new keyring, however, has had its serial number
      published, which means it can be accessed directly by that handle.
      
      This was found by a previous patch that adds RCU lockdep checks to the code
      that reads the keyring payload pointer, which includes a check that the keyring
      semaphore is actually locked.
      
      Without this patch, the following command:
      
      	keyctl request2 user b a @s
      
      will provoke the following lockdep warning is displayed in dmesg:
      
      	===================================================
      	[ INFO: suspicious rcu_dereference_check() usage. ]
      	---------------------------------------------------
      	security/keys/keyring.c:727 invoked rcu_dereference_check() without protection!
      
      	other info that might help us debug this:
      
      	rcu_scheduler_active = 1, debug_locks = 0
      	2 locks held by keyctl/2076:
      	 #0:  (key_types_sem){.+.+.+}, at: [<ffffffff811a5b29>] key_type_lookup+0x1c/0x71
      	 #1:  (keyring_serialise_link_sem){+.+.+.}, at: [<ffffffff811a6d1e>] __key_link+0x4d/0x3c5
      
      	stack backtrace:
      	Pid: 2076, comm: keyctl Not tainted 2.6.34-rc6-cachefs #54
      	Call Trace:
      	 [<ffffffff81051fdc>] lockdep_rcu_dereference+0xaa/0xb2
      	 [<ffffffff811a6d1e>] ? __key_link+0x4d/0x3c5
      	 [<ffffffff811a6e6f>] __key_link+0x19e/0x3c5
      	 [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
      	 [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
      	 [<ffffffff811aa0dc>] call_sbin_request_key+0xe7/0x33b
      	 [<ffffffff8139376a>] ? mutex_unlock+0x9/0xb
      	 [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
      	 [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
      	 [<ffffffff811aa6fa>] ? request_key_auth_new+0x1c2/0x23c
      	 [<ffffffff810aaf15>] ? cache_alloc_debugcheck_after+0x108/0x173
      	 [<ffffffff811a9d00>] ? request_key_and_link+0x146/0x300
      	 [<ffffffff810ac568>] ? kmem_cache_alloc+0xe1/0x118
      	 [<ffffffff811a9e45>] request_key_and_link+0x28b/0x300
      	 [<ffffffff811a89ac>] sys_request_key+0xf7/0x14a
      	 [<ffffffff81052c0b>] ? trace_hardirqs_on_caller+0x10c/0x130
      	 [<ffffffff81394fb9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      	 [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      896903c2
    • David Howells's avatar
      KEYS: Use RCU dereference wrappers in keyring key type code · f0641cba
      David Howells authored
      The keyring key type code should use RCU dereference wrappers, even when it
      holds the keyring's key semaphore.
      Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      f0641cba
    • Toshiyuki Okajima's avatar
      KEYS: find_keyring_by_name() can gain access to a freed keyring · cea7daa3
      Toshiyuki Okajima authored
      find_keyring_by_name() can gain access to a keyring that has had its reference
      count reduced to zero, and is thus ready to be freed.  This then allows the
      dead keyring to be brought back into use whilst it is being destroyed.
      
      The following timeline illustrates the process:
      
      |(cleaner)                           (user)
      |
      | free_user(user)                    sys_keyctl()
      |  |                                  |
      |  key_put(user->session_keyring)     keyctl_get_keyring_ID()
      |  ||	//=> keyring->usage = 0        |
      |  |schedule_work(&key_cleanup_task)   lookup_user_key()
      |  ||                                   |
      |  kmem_cache_free(,user)               |
      |  .                                    |[KEY_SPEC_USER_KEYRING]
      |  .                                    install_user_keyrings()
      |  .                                    ||
      | key_cleanup() [<= worker_thread()]    ||
      |  |                                    ||
      |  [spin_lock(&key_serial_lock)]        |[mutex_lock(&key_user_keyr..mutex)]
      |  |                                    ||
      |  atomic_read() == 0                   ||
      |  |{ rb_ease(&key->serial_node,) }     ||
      |  |                                    ||
      |  [spin_unlock(&key_serial_lock)]      |find_keyring_by_name()
      |  |                                    |||
      |  keyring_destroy(keyring)             ||[read_lock(&keyring_name_lock)]
      |  ||                                   |||
      |  |[write_lock(&keyring_name_lock)]    ||atomic_inc(&keyring->usage)
      |  |.                                   ||| *** GET freeing keyring ***
      |  |.                                   ||[read_unlock(&keyring_name_lock)]
      |  ||                                   ||
      |  |list_del()                          |[mutex_unlock(&key_user_k..mutex)]
      |  ||                                   |
      |  |[write_unlock(&keyring_name_lock)]  ** INVALID keyring is returned **
      |  |                                    .
      |  kmem_cache_free(,keyring)            .
      |                                       .
      |                                       atomic_dec(&keyring->usage)
      v                                         *** DESTROYED ***
      TIME
      
      If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
      
      	=============================================================================
      	BUG key_jar: Poison overwritten
      	-----------------------------------------------------------------------------
      
      	INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
      	INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
      	INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
      	INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
      	INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
      
      	Bytes b4 0xffff880197a7e1f0:  5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
      	  Object 0xffff880197a7e200:  6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
      
      Alternatively, we may see a system panic happen, such as:
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
      	IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	PGD 6b2b4067 PUD 6a80d067 PMD 0
      	Oops: 0000 [#1] SMP
      	last sysfs file: /sys/kernel/kexec_crash_loaded
      	CPU 1
      	...
      	Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
      	RIP: 0010:[<ffffffff810e61a3>]  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	RSP: 0018:ffff88006af3bd98  EFLAGS: 00010002
      	RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
      	RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
      	RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
      	R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
      	R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
      	FS:  00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
      	Stack:
      	 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
      	 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
      	 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
      	Call Trace:
      	 [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
      	 [<ffffffff810face3>] ? do_filp_open+0x145/0x590
      	 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
      	 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
      	 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
      	 [<ffffffff81103916>] ? alloc_fd+0x69/0x10e
      	 [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
      	 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
      	Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
      	RIP  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      
      This problem is that find_keyring_by_name does not confirm that the keyring is
      valid before accepting it.
      
      Skipping keyrings that have been reduced to a zero count seems the way to go.
      To this end, use atomic_inc_not_zero() to increment the usage count and skip
      the candidate keyring if that returns false.
      
      The following script _may_ cause the bug to happen, but there's no guarantee
      as the window of opportunity is small:
      
      	#!/bin/sh
      	LOOP=100000
      	USER=dummy_user
      	/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
      	for ((i=0; i<LOOP; i++))
      	do
      		/bin/su -c "echo '$i' > /dev/null" $USER
      	done
      	(( add == 1 )) && /usr/sbin/userdel -r $USER
      	exit
      
      Note that the nominated user must not be in use.
      
      An alternative way of testing this may be:
      
      	for ((i=0; i<100000; i++))
      	do
      		keyctl session foo /bin/true || break
      	done >&/dev/null
      
      as that uses a keyring named "foo" rather than relying on the user and
      user-session named keyrings.
      Reported-by: default avatarToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      cea7daa3
    • Takashi Iwai's avatar
      Merge branch 'fix/hda' into for-linus · 69b5de84
      Takashi Iwai authored
      69b5de84
    • Daniel T Chen's avatar
      ALSA: hda: Fix 0 dB for Packard Bell models using Conexant CX20549 (Venice) · 8f0f5ff6
      Daniel T Chen authored
      BugLink: https://launchpad.net/bugs/541802
      
      The OR's hardware distorts at PCM 100% because it does not correspond to
      0 dB. Fix this in patch_cxt5045() for all Packard Bell models.
      
      Reported-by: Valombre
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarDaniel T Chen <crimsun@ubuntu.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8f0f5ff6
    • Anisse Astier's avatar
      ALSA: hda - Add quirk for Dell Inspiron 19T using a Conexant CX20582 · 231f50bc
      Anisse Astier authored
      Add a quirk for all-in-one computer Dell Inspiron One 19 Touch to have proper
      HP and Mic support.
      Signed-off-by: default avatarAnisse Astier <anisse@astier.eu>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      231f50bc
    • Dan Carpenter's avatar
      ALSA: take tu->qlock with irqs disabled · bfe70783
      Dan Carpenter authored
      We should disable irqs when we take the tu->qlock because it is used in
      the irq handler.  The only place that doesn't is
      snd_timer_user_ccallback().  Most of the time snd_timer_user_ccallback()
      is called with interrupts disabled but the the first ti->ccallback()
      call in snd_timer_notify1() has interrupts enabled.
      
      This was caught by lockdep which generates the following message:
      
      > =================================
      > [ INFO: inconsistent lock state ]
      > 2.6.34-rc5 #5
      > ---------------------------------
      > inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      > dolphin/4003 [HC1[1]:SC0[0]:HE0:SE1] takes:
      > (&(&tu->qlock)->rlock){?.+...}, at: [<f84ec472>] snd_timer_user_tinterrupt+0x28/0x132 [snd_timer]
      > {HARDIRQ-ON-W} state was registered at:
      >   [<c1048de9>] __lock_acquire+0x654/0x1482
      >   [<c1049c73>] lock_acquire+0x5c/0x73
      >   [<c125ac3e>] _raw_spin_lock+0x25/0x34
      >   [<f84ec370>] snd_timer_user_ccallback+0x55/0x95 [snd_timer]
      >   [<f84ecc4b>] snd_timer_notify1+0x53/0xca [snd_timer]
      Reported-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bfe70783