kernel/linux.git, branch v2.6.28.3

Linux 2.6.28.3

2009-02-02T18:12:10+00:00

relay: fix lock imbalance in relay_late_setup_files

2009-02-02T17:53:29+00:00

commit b786c6a98ef6fa81114ba7b9fbfc0d67060775e3 upstream. One fail path in relay_late_setup_files() omits mutex_unlock(&relay_channels_mutex); Add it. Signed-off-by: Jiri Slaby Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

NET: net_namespace, fix lock imbalance

2009-02-02T17:53:29+00:00

commit 357f5b0b91054ae23385ea4b0634bb8b43736e83 upstream. register_pernet_gen_subsys omits mutex_unlock in one fail path. Fix it. Signed-off-by: Jiri Slaby Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

dmaengine: fix dependency chaining

2009-02-02T17:53:29+00:00

commit dd59b8537f6cb53ab863fafad86a5828f1e889a2 upstream ASYNC_TX: fix dependency chaining In ASYNC_TX we track the dependencies between the descriptors using the 'next' pointers of the structures. These pointers are set to NULL as soon as the corresponding descriptor has been submitted to the channel (in async_tx_run_dependencies()). But, the first 'next' in chain still remains set, regardless the fact, that tx->next is already submitted. This may lead to multiple submisions of the same descriptor. This patch fixes this. Signed-off-by: Yuri Tikhonov Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman

PCI hotplug: fix lock imbalance in pciehp

2009-02-02T17:53:28+00:00

commit c2fdd36b550659f5ac2240d1f5a83ffa1a092289 upstream. set_lock_status omits mutex_unlock in fail path. Add the omitted unlock. As a result a lockup caused by this can be triggered from userspace by writing 1 to /sys/bus/pci/slots/.../lock often enough. Signed-off-by: Jiri Slaby Reviewed-by: Kenji Kaneshige Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

x86, pat: fix PTE corruption issue while mapping RAM using /dev/mem

2009-02-02T17:53:28+00:00

commit 9597134218300c045cf219be3664615e97cb239c upstream. Beschorner Daniel reported: > hwinfo problem since 2.6.28, showing this in the oops: > Corrupted page table at address 7fd04de3ec00 Also, PaX Team reported a regression with this commit: > commit 9542ada803198e6eba29d3289abb39ea82047b92 > Author: Suresh Siddha > Date: Wed Sep 24 08:53:33 2008 -0700 > > x86: track memtype for RAM in page struct This commit breaks mapping any RAM page through /dev/mem, as the reserve_memtype() was not initializing the return attribute type and as such corrupting the PTE entry that was setup with the return attribute type. Because of this bug, application mapping this RAM page through /dev/mem will die with "Corrupted page table at address xxxx" message in the kernel log and also the kernel identity mapping which maps the underlying RAM page gets converted to UC. Fix this by initializing the return attribute type before calling reserve_ram_pages_type() Reported-by: PaX Team Reported-and-tested-by: Beschorner Daniel Tested-and-Acked-by: PaX Team Signed-off-by: Suresh Siddha Signed-off-by: Venkatesh Pallipadi Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86, pat: fix reserve_memtype() for legacy 1MB range

2009-02-02T17:53:28+00:00

commit 5cca0cf15a94417f49625ce52e23589eed0a1675 upstream Thierry Vignaud reported: > http://bugzilla.kernel.org/show_bug.cgi?id=12372 > > On P4 with an SiS motherboard (video card is a SiS 651) > X server fails to start with error: > xf86MapVidMem: Could not mmap framebuffer (0x00000000,0x2000) (Invalid > argument) Here X is trying to map first 8KB of memory using /dev/mem. Existing code treats first 0-4KB of memory as non-RAM and 4KB-8KB as RAM. Recent code changes don't allow to map memory with different attributes at the same time. Fix this by treating the first 1MB legacy region as special and always track the attribute requests with in this region using linear linked list (and don't bother if the range is RAM or non-RAM or mixed) Reported-and-tested-by: Thierry Vignaud Signed-off-by: Suresh Siddha Signed-off-by: Venkatesh Pallipadi Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

crypto: ccm - Fix handling of null assoc data

2009-02-02T17:53:28+00:00

commit 516280e735b034216de97eb7ba080ec6acbfc58f upstream. Its a valid use case to have null associated data in a ccm vector, but this case isn't being handled properly right now. The following ccm decryption/verification test vector, using the rfc4309 implementation regularly triggers a panic, as will any other vector with null assoc data: * key: ab2f8a74b71cd2b1ff802e487d82f8b9 * iv: c6fb7d800d13abd8a6b2d8 * Associated Data: [NULL] * Tag Length: 8 * input: d5e8939fc7892e2b The resulting panic looks like so: Unable to handle kernel paging request at ffff810064ddaec0 RIP: [] :ccm:get_data_to_compute+0x1a6/0x1d6 PGD 8063 PUD 0 Oops: 0002 [1] SMP last sysfs file: /module/libata/version CPU 0 Modules linked in: crypto_tester_kmod(U) seqiv krng ansi_cprng chainiv rng ctr aes_generic aes_x86_64 ccm cryptomgr testmgr_cipher testmgr aead crypto_blkcipher crypto_a lgapi des ipv6 xfrm_nalgo crypto_api autofs4 hidp l2cap bluetooth nfs lockd fscache nfs_acl sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_ tcpudp iptable_filter ip_tables x_tables dm_mirror dm_log dm_multipath scsi_dh dm_mod video hwmon backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp sg snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss joydev snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ide_cd snd_pcm floppy parport_p c shpchp e752x_edac snd_timer e1000 i2c_i801 edac_mc snd soundcore snd_page_alloc i2c_core cdrom parport serio_raw pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd uhci_h cd ohci_hcd ehci_hcd Pid: 12844, comm: crypto-tester Tainted: G 2.6.18-128.el5.fips1 #1 RIP: 0010:[] [] :ccm:get_data_to_compute+0x1a6/0x1d6 RSP: 0018:ffff8100134434e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8100104898b0 RCX: ffffffffab6aea10 RDX: 0000000000000010 RSI: ffff8100104898c0 RDI: ffff810064ddaec0 RBP: 0000000000000000 R08: ffff8100104898b0 R09: 0000000000000000 R10: ffff8100103bac84 R11: ffff8100104898b0 R12: ffff810010489858 R13: ffff8100104898b0 R14: ffff8100103bac00 R15: 0000000000000000 FS: 00002ab881adfd30(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff810064ddaec0 CR3: 0000000012a88000 CR4: 00000000000006e0 Process crypto-tester (pid: 12844, threadinfo ffff810013442000, task ffff81003d165860) Stack: ffff8100103bac00 ffff8100104898e8 ffff8100134436f8 ffffffff00000000 0000000000000000 ffff8100104898b0 0000000000000000 ffff810010489858 0000000000000000 ffff8100103bac00 ffff8100134436f8 ffffffff8864c634 Call Trace: [] :ccm:crypto_ccm_auth+0x12d/0x140 [] :ccm:crypto_ccm_decrypt+0x161/0x23a [] :crypto_tester_kmod:cavs_test_rfc4309_ccm+0x4a5/0x559 [...] The above is from a RHEL5-based kernel, but upstream is susceptible too. The fix is trivial: in crypto/ccm.c:crypto_ccm_auth(), pctx->ilen contains whatever was in memory when pctx was allocated if assoclen is 0. The tested fix is to simply add an else clause setting pctx->ilen to 0 for the assoclen == 0 case, so that get_data_to_compute() doesn't try doing things its not supposed to. Signed-off-by: Jarod Wilson Acked-by: Neil Horman Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: authenc - Fix zero-length IV crash

2009-02-02T17:53:28+00:00

commit 29b37f42127f7da511560a40ea74f5047da40c13 upstream. As it is if an algorithm with a zero-length IV is used (e.g., NULL encryption) with authenc, authenc may generate an SG entry of length zero, which will trigger a BUG check in the hash layer. This patch fixes it by skipping the IV SG generation if the IV size is zero. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add quirk for HP DV6700 laptop

2009-02-02T17:53:27+00:00

commit aa9d823bb347fb66cb07f98c686be8bb85cb6a74 upstream. Added the matching model=laptop for HP DV6700 laptop. Signed-off-by: Joerg Schirottke Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman