AgeCommit message (Collapse)Author
2009-02-02Linux Kroah-Hartman
2009-02-02relay: fix lock imbalance in relay_late_setup_filesJiri Slaby
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 <>
2009-02-02NET: net_namespace, fix lock imbalanceJiri Slaby
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 <>
2009-02-02dmaengine: fix dependency chainingYuri Tikhonov
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 <>
2009-02-02PCI hotplug: fix lock imbalance in pciehpJiri Slaby
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 <>
2009-02-02x86, pat: fix PTE corruption issue while mapping RAM using /dev/memSuresh Siddha
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 <>
2009-02-02x86, pat: fix reserve_memtype() for legacy 1MB rangeSuresh Siddha
commit 5cca0cf15a94417f49625ce52e23589eed0a1675 upstream Thierry Vignaud reported: > > > 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 <>
2009-02-02crypto: ccm - Fix handling of null assoc dataJarod Wilson
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: [<ffffffff8864c4d7>] :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:[<ffffffff8864c4d7>] [<ffffffff8864c4d7>] :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: [<ffffffff8864c634>] :ccm:crypto_ccm_auth+0x12d/0x140 [<ffffffff8864cf73>] :ccm:crypto_ccm_decrypt+0x161/0x23a [<ffffffff88633643>] :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 <>
2009-02-02crypto: authenc - Fix zero-length IV crashHerbert Xu
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 <>
2009-02-02ALSA: hda - Add quirk for HP DV6700 laptopJoerg Schirottke
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 <>
2009-02-02ALSA: hda - add another MacBook Pro 4, 1 subsystem IDLuke Yelavich
commit 2a88464ceb1bda2571f88902fd8068a6168e3f7b upstream. Add another MacBook Pro 4,1 SSID (106b:3800). It seems that latter revisions, (at least mine), have different IDs to earlier revisions. Signed-off-by: Luke Yelavich <> Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02ALSA: hda - Fix PCM reference NID for STAC/IDT analog outputsTakashi Iwai
commit 00a602db1ce9d61319d6f769dee206ec85f19bda upstream. The reference NID for the analog outputs of STAC/IDT codecs is set to a fixed number 0x02. But this isn't always correct and in many codecs it points to a non-existing NID. This patch fixes the initialization of the PCM reference NID taken from the actually probed DAC list. Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02include/linux: Add bsg.h to the Kernel exported headersBoaz Harrosh
commit a229fc61ef0ee3c30fd193beee0eeb87410227f1 upstream. bsg.h in current form is perfectly suitable for user-mode consumption. It is needed together with scsi/sg.h for applications that want to interface with the bsg driver. Currently the few projects that use it would copy it over into the projects. But that is not acceptable for projects that need to provide source and devel packages for distros. This should also be submitted to stable 2.6.28 and 2.6.27 since bsg had a stable API since these Kernels and distro users will need the header for these kernels a swell Signed-off-by: Boaz Harrosh <> Acked-by: FUJITA Tomonori <> Signed-off-by: Jens Axboe <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02sgi-xpc: ensure flags are updated before bte_copyRobin Holt
commit 69b3bb65fa97a1e8563518dbbc35cd57beefb2d4 upstream. The clearing of the msg->flags needs a barrier between it and the notify of the channel threads that the messages are cleaned and ready for use. Signed-off-by: Robin Holt <> Signed-off-by: Dean Nelson <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02sgi-xpc: Remove NULL pointer dereference.Robin Holt
commit 17e2161654da4e6bdfd8d53d4f52e820ee93f423 upstream. If the bte copy fails, the attempt to retrieve payloads merely returns a null pointer deref and not NULL as was expected. Signed-off-by: Robin Holt <> Signed-off-by: Dean Nelson <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02gpiolib: fix request related issueMagnus Damm
commit 7460db567bbca76bf087d1694d792a1a96bdaa26 upstream. Fix request-already-requested handling in gpio_request(). Signed-off-by: Magnus Damm <> Acked-by: David Brownell <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02epoll: drop max_user_instances and rely only on max_user_watchesDavide Libenzi
commit 9df04e1f25effde823a600e755b51475d438f56b upstream. Linus suggested to put limits where the money is, and max_user_watches already does that w/out the need of max_user_instances. That has the advantage to mitigate the potential DoS while allowing pretty generous default behavior. Allowing top 4% of low memory (per user) to be allocated in epoll watches, we have: LOMEM MAX_WATCHES (per user) 512MB ~178000 1GB ~356000 2GB ~712000 A box with 512MB of lomem, will meet some challenge in hitting 180K watches, socket buffers math teaches us. No more max_user_instances limits then. Signed-off-by: Davide Libenzi <> Cc: Willy Tarreau <> Cc: Michael Kerrisk <> Cc: Bron Gondwana <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02rtl8187: Fix error in setting OFDM power settings for RTL8187LLarry Finger
commit eb83bbf57429ab80f49b413e3e44d3b19c3fdc5a upstream. After reports of poor performance, a review of the latest vendor driver (rtl8187_linux_26.1025.0328.2007) for RTL8187L devices was undertaken. A difference was found in the code used to index the OFDM power tables. When the Linux driver was changed, my unit works at a much greater range than before. I think this fixes Bugzilla #12380 and has been tested by at least two other users. Signed-off-by: Larry Finger <> Tested-by: Martín Ernesto Barreyro <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02ext3: Add sanity check to make_indexed_dirTheodore Ts'o
commit a21102b55c4f8dfd3adb4a15a34cd62237b46039 upstream. Make sure the rec_len field in the '..' entry is sane, lest we overrun the directory block and cause a kernel oops on a purposefully corrupted filesystem. This fixes a bug related to a bug originally reported by Sami Liedes for ext4 at: Signed-off-by: "Theodore Ts'o" <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02bnx2x: Block nvram access when the device is inactiveEilon Greenstein
commit 2add3acb11a26cc14b54669433ae6ace6406cbf2 upstream. Don't dump eeprom when bnx2x adapter is down. Running ethtool -e causes an eeh without it when the device is down Signed-off-by: Paul Larson <> Signed-off-by: Eilon Greenstein <> Signed-off-by: David S. Miller <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segmentsAndrew Morton
This patch differs from the upstream commit de33c8db5910cda599899dd431cc30d7c1018cbf written by Linus, as it aims to only prevent the oops from happening, not attempt to change anything else. The problem was introduced by commit ba470de43188cdbff795b5da43a1474523c6c2fb which added new references to *vma after we've potentially freed it. From: Andrew Morton <> Reported-by: Maksim Yevmenkin <> Tested-by: Maksim Yevmenkin <> Cc: Lee Schermerhorn <> Cc: Nick Piggin <> Cc: Andrew Morton <> Cc: Rik van Riel <> Cc: Hugh Dickins <> Cc: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02drm: stash AGP include under the do-we-have-AGP ifdefEric Anholt
commit 1bb88edb7a3769992026f34fd648bb459b0469aa upstream. This fixes the MIPS with DRM build. Signed-off-by: Eric Anholt <> Tested-by: Martin Michlmayr <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02serial_8250: support for Sealevel Systems Model 7803 COMM+8Flavio Leitner
commit e65f0f8271b1b0452334e5da37fd35413a000de4 upstream. Add support for Sealevel Systems Model 7803 COMM+8 Signed-off-by: Flavio Leitner <> Signed-off-by: Alan Cox <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02libata: pata_via: support VX855, future chips whose IDE controller use
commit e4d866cdea24543ee16ce6d07d80c513e86ba983 upstream. It supports VX855 and future chips whose IDE controller uses PCI ID 0x0571. Signed-off-by: Joseph Chan <> Acked-by: Tejun Heo <> Signed-off-by: Jeff Garzik <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02it821x: Add ultra_mask quirk for Vortex86SXBrandon Philips
commit b94b898f3107046b5c97c556e23529283ea5eadd upstream. On Vortex86SX with IDE controller revision 0x11 ultra DMA must be disabled. This patch was tested by DMP and seems to work. It is a cleaned up version of their older Kernel patch: Tested-by: Shawn Lin <> Signed-off-by: Brandon Philips <> Cc: Alan Cox <> Signed-off-by: Bartlomiej Zolnierkiewicz <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02rtl8187: Add termination packet to prevent stallLarry Finger
commit 2fcbab044a3faf4d4a6e269148dd1f188303b206 upstream. The RTL8187 and RTL8187B devices can stall unless an explicit termination packet is sent. Signed-off-by: Larry Finger <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02resources: skip sanity check of busy resourcesArjan van de Ven
commit 3ac52669c7a24b93663acfcab606d1065ed1accd upstream. Impact: reduce false positives in iomem_map_sanity_check() Some drivers (vesafb) only map/reserve a portion of a resource. If then some other driver comes in and maps the whole resource, the current code WARN_ON's. This is not the intent of the checks in iomem_map_sanity_check(); rather these checks want to warn when crossing *hardware* resources only. This patch skips BUSY resources as suggested by Linus. Note: having two drivers talk to the same hardware at the same time is obviously not optimal behavior, but that's a separate story. Signed-off-by: Arjan van de Ven <> Signed-off-by: Ingo Molnar <> Signed-off-by: Kyle McMartin <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02alpha: fix vmalloc breakageIvan Kokshaysky
commit 822c18f2e38cbc775792ab65ace4f9198678dec9 upstream. On alpha, we have to map some stuff in the VMALLOC space very early in the boot process (to make SRM console callbacks work and so on, see arch/alpha/mm/init.c). For old VM allocator, we just manually placed a vm_struct onto the global vmlist and this worked for ages. Unfortunately, the new allocator isn't aware of this, so it constantly tries to allocate the VM space which is already in use, making vmalloc on alpha defunct. This patch forces KVA to import vmlist entries on init. [ remove unneeded check (per Johannes)] Signed-off-by: Ivan Kokshaysky <> Cc: Nick Piggin <> Cc: Johannes Weiner <> Cc: Richard Henderson <> Cc: Johannes Weiner <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02alpha: nautilus - fix compile failure with gcc-4.3Ivan Kokshaysky
commit 70b66cbfd3316b792a855cb9a2574e85f1a63d0f upstream. init_srm_irq() deals with irq's #16 and above, but size of irq_desc array on nautilus and some other system types is 16. So gcc-4.3 complains that "array subscript is above array bounds", even though this function is never called on those systems. This adds a check for NR_IRQS <= 16, which effectively optimizes init_srm_irq() code away on problematic platforms. Thanks to Daniel Drake <> for detailed analysis of the problem. Signed-off-by: Ivan Kokshaysky <> Cc: Richard Henderson <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Cc: Tobias Klausmann <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02USB: storage: add unusual devs entryOliver Neukum
commit b90de8aea36ae6fe8050a6e91b031369c4f251b2 upstream. This adds an unusual devs entry for 2116:0320 Signed-off-by: Oliver Neukum <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02USB: fix char-device disconnect handlingAlan Stern
commit 501950d846218ed80a776d2aae5aed9c8b92e778 upstream. This patch (as1198) fixes a conceptual bug: Somewhere along the line we managed to confuse USB class devices with USB char devices. As a result, the code to send a disconnect signal to userspace would not be built if both CONFIG_USB_DEVICE_CLASS and CONFIG_USB_DEVICEFS were disabled. The usb_fs_classdev_common_remove() routine has been renamed to usbdev_remove() and it is now called whenever any USB device is removed, not just when a class device is unregistered. The notifier registration and unregistration calls are no longer conditionally compiled. And since the common removal code will always be called as part of the char device interface, there's no need to call it again as part of the usbfs interface; thus the invocation of usb_fs_classdev_common_remove() has been taken out of usbfs_remove_device(). Signed-off-by: Alan Stern <> Reported-by: Alon Bar-Lev <> Tested-by: Alon Bar-Lev <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02USB: usbmon: Implement compat_ioctlPete Zaitcev
commit 7abce6bedc118eb39fe177c2c26be5d008505c14 upstream. Running a 32-bit usbmon(8) on 2.6.28-rc9 produces the following: ioctl32(usbmon:28563): Unknown cmd fd(3) cmd(400c9206){t:ffffff92;sz:12} arg(ffd3f458) on /dev/usbmon0 It happens because the compatibility mode was implemented for 2.6.18 and not updated for the fsops.compat_ioctl API. This patch relocates the pieces from under #ifdef CONFIG_COMPAT into compat_ioctl with no other changes except one new whitespace. Signed-off-by: Pete Zaitcev <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02sound: virtuoso: enable UART on Xonar HDAV1.3Clemens Ladisch
commit 22c733788bbd4b75c00279119a83da5cd74b987a upstream. This hardware has a better chance of working correctly if we don't forget to enable it. Signed-off-by: Clemens Ladisch <> Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02USB: fix toggle mismatch in disable_endpoint pathsAlan Stern
commit ddeac4e75f2527a340f9dc655bde49bb2429b39b upstream. This patch (as1200) finishes some fixes that were left incomplete by an earlier patch. Although nobody has addressed this issue in the past, it turns out that we need to distinguish between two different modes of disabling and enabling endpoints. In one mode only the data structures in usbcore are affected, and in the other mode the host controller and device hardware states are affected as well. The earlier patch added an extra argument to the routines in the enable_endpoint pathways to reflect this difference. This patch adds corresponding arguments to the disable_endpoint pathways. Without this change, the endpoint toggle state can get out of sync between the host and the device. The exact mechanism depends on the details of the host controller (whether or not it stores its own copy of the toggle values). Signed-off-by: Alan Stern <> Reported-by: Dan Streetman <> Tested-by: Dan Streetman <> Signed-off-by: Greg Kroah-Hartman <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02x86: fix page attribute corruption with cpa()Suresh Siddha
commit a1e46212a410793d575718818e81ddc442a65283 upstream. Impact: fix sporadic slowdowns and warning messages This patch fixes a performance issue reported by Linus on his Nehalem system. While Linus reverted the PAT patch (commit 58dab916dfb57328d50deb0aa9b3fc92efa248ff) which exposed the issue, existing cpa() code can potentially still cause wrong(page attribute corruption) behavior. This patch also fixes the "WARNING: at arch/x86/mm/pageattr.c:560" that various people reported. In 64bit kernel, kernel identity mapping might have holes depending on the available memory and how e820 reports the address range covering the RAM, ACPI, PCI reserved regions. If there is a 2MB/1GB hole in the address range that is not listed by e820 entries, kernel identity mapping will have a corresponding hole in its 1-1 identity mapping. If cpa() happens on the kernel identity mapping which falls into these holes, existing code fails like this: __change_page_attr_set_clr() __change_page_attr() returns 0 because of if (!kpte). But doesn't set cpa->numpages and cpa->pfn. cpa_process_alias() uses uninitialized cpa->pfn (random value) which can potentially lead to changing the page attribute of kernel text/data, kernel identity mapping of RAM pages etc. oops! This bug was easily exposed by another PAT patch which was doing cpa() more often on kernel identity mapping holes (physical range between max_low_pfn_mapped and 4GB), where in here it was setting the cache disable attribute(PCD) for kernel identity mappings aswell. Fix cpa() to handle the kernel identity mapping holes. Retain the WARN() for cpa() calls to other not present address ranges (kernel-text/data, ioremap() addresses) Signed-off-by: Suresh Siddha <> Signed-off-by: Venkatesh Pallipadi <> Signed-off-by: Ingo Molnar <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02sysfs: fix problems with binary filesGreg Kroah-Hartman
commit 4503efd0891c40e30928afb4b23dc3f99c62a6b2 upstream. Some sysfs binary files don't like having 0 passed to them as a size. Fix this up at the root by just returning to the vfs if userspace asks us for a zero sized buffer. Thanks to Pavel Roskin for pointing this out. Reported-by: Pavel Roskin <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02klist.c: bit 0 in pointer can't be used as flagJesper Nilsson
commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b upstream. The commit a1ed5b0cffe4b16a93a6a3390e8cee0fbef94f86 (klist: don't iterate over deleted entries) introduces use of the low bit in a pointer to indicate if the knode is dead or not, assuming that this bit is always free. This is not true for all architectures, CRIS for example may align data on byte borders. The result is a bunch of warnings on bootup, devices not being added correctly etc, reported by Hinko Kocevar <>: ------------[ cut here ]------------ WARNING: at lib/klist.c:62 () Modules linked in: Stack from c1fe1cf0: c01cc7f4 c1fe1d11 c000eb4e c000e4de 00000000 00000000 c1f4f78f c1f50c2d c01d008c c1fdd1a0 c1fdd1a0 c1fe1d38 c0192954 c1fe0000 00000000 c1fe1dc0 00000002 7fffffff c1fe1da8 c0192d50 c1fe1dc0 00000002 7fffffff c1ff9fcc Call Trace: [<c000eb4e>] [<c000e4de>] [<c0192954>] [<c0192d50>] [<c001d49e>] [<c000b688>] [<c0192a3c>] [<c000b63e>] [<c000b63e>] [<c001a542>] [<c00b55b0>] [<c00411c0>] [<c00b559c>] [<c01918e6>] [<c0191988>] [<c01919d0>] [<c00cd9c8>] [<c00cdd6a>] [<c0034178>] [<c000409a>] [<c0015576>] [<c0029130>] [<c0029078>] [<c0029170>] [<c0012336>] [<c00b4076>] [<c00b4770>] [<c006d6e4>] [<c006d974>] [<c006dca0>] [<c0028d6c>] [<c0028e12>] [<c0006424>] <4>---[ end trace 4eaa2a86a8e2da22 ]--- ------------[ cut here ]------------ Repeat ad nauseam. Wed, Jan 14, 2009 at 12:11:32AM +0100, Bastien ROUCARIES wrote: > Perhaps using a pointerhackalign trick on this structure where > #define pointerhackalign(x) __attribute__ ((aligned (x))) > and declare > struct klist_node { > ... > } pointerhackalign(2); > > Because __attribute__ ((aligned (x))) could only increase alignment > it will safe to do that and serve as documentation purpose :) That works, but we need to do it not for the struct klist_node, but for the struct we insert into the void * in klist_node, which is struct klist. Reported-by: Hinko Kocevar < Cc: Bastien ROUCARIES <> Signed-off-by: Jesper Nilsson <> Signed-off-by: Greg Kroah-Hartman <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02x86, mm: fix pte_free()Peter Zijlstra
commit 42ef73fe134732b2e91c0326df5fd568da17c4b2 upstream. On -rt we were seeing spurious bad page states like: Bad page state in process 'firefox' page:c1bc2380 flags:0x40000000 mapping:c1bc2390 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Pid: 503, comm: firefox Not tainted #3 [<c043d0f3>] ? printk+0x14/0x19 [<c0272d4e>] bad_page+0x4e/0x79 [<c0273831>] free_hot_cold_page+0x5b/0x1d3 [<c02739f6>] free_hot_page+0xf/0x11 [<c0273a18>] __free_pages+0x20/0x2b [<c027d170>] __pte_alloc+0x87/0x91 [<c027d25e>] handle_mm_fault+0xe4/0x733 [<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63 [<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63 [<c0218875>] do_page_fault+0x36f/0x88a This is the case where a concurrent fault already installed the PTE and we get to free the newly allocated one. This is due to pgtable_page_ctor() doing the spin_lock_init(&page->ptl) which is overlaid with the {private, mapping} struct. union { struct { unsigned long private; struct address_space *mapping; }; spinlock_t ptl; struct kmem_cache *slab; struct page *first_page; }; Normally the spinlock is small enough to not stomp on page->mapping, but PREEMPT_RT=y has huge 'spin'locks. But lockdep kernels should also be able to trigger this splat, as the lock tracking code grows the spinlock to cover page->mapping. The obvious fix is calling pgtable_page_dtor() like the regular pte free path __pte_free_tlb() does. It seems all architectures except x86 and nm10300 already do this, and nm10300 doesn't seem to use pgtable_page_ctor(), which suggests it doesn't do SMP or simply doesnt do MMU at all or something. Signed-off-by: Peter Zijlstra <> Signed-off-by: Ingo Molnar <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02fuse: fix NULL deref in fuse_file_alloc()Dan Carpenter
commit bb875b38dc5e343bdb696b2eab8233e4d195e208 upstream. ff is set to NULL and then dereferenced on line 65. Compile tested only. Signed-off-by: Dan Carpenter <> Signed-off-by: Miklos Szeredi <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02fuse: fix missing fput on errorMiklos Szeredi
commit 3ddf1e7f57237ac7c5d5bfb7058f1ea4f970b661 upstream. Fix the leaking file reference if allocation or initialization of fuse_conn failed. Signed-off-by: Miklos Szeredi <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02fuse: destroy bdi on umountMiklos Szeredi
commit 26c3679101dbccc054dcf370143941844ba70531 upstream. If a fuse filesystem is unmounted but the device file descriptor remains open and a new mount reuses the old device number, then the mount fails with EEXIST and the following warning is printed in the kernel log: WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x35/0x3d() sysfs: duplicate filename '0:15' can not be created The cause is that the bdi belonging to the fuse filesystem was destoryed only after the device file was released. Fix this by calling bdi_destroy() from fuse_put_super() instead. Signed-off-by: Miklos Szeredi <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02inotify: clean up inotify_read and fix locking problemsVegard Nossum
commit 3632dee2f8b8a9720329f29eeaa4ec4669a3aff8 upstream. If userspace supplies an invalid pointer to a read() of an inotify instance, the inotify device's event list mutex is unlocked twice. This causes an unbalance which effectively leaves the data structure unprotected, and we can trigger oopses by accessing the inotify instance from different tasks concurrently. The best fix (contributed largely by Linus) is a total rewrite of the function in question: On Thu, Jan 22, 2009 at 7:05 AM, Linus Torvalds wrote: > The thing to notice is that: > > - locking is done in just one place, and there is no question about it > not having an unlock. > > - that whole double-while(1)-loop thing is gone. > > - use multiple functions to make nesting and error handling sane > > - do error testing after doing the things you always need to do, ie do > this: > > mutex_lock(..) > ret = function_call(); > mutex_unlock(..) > > .. test ret here .. > > instead of doing conditional exits with unlocking or freeing. > > So if the code is written in this way, it may still be buggy, but at least > it's not buggy because of subtle "forgot to unlock" or "forgot to free" > issues. > > This _always_ unlocks if it locked, and it always frees if it got a > non-error kevent. Cc: John McCutchan <> Cc: Robert Love <> Signed-off-by: Vegard Nossum <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02mac80211: decrement ref count to netdev after launching mesh discoveryBrian Cavagnolo
commit 5dc306f3bd1d4cfdf79df39221b3036eab1ddcf3 upstream. After launching mesh discovery in tx path, reference count was not being decremented. This was preventing module unload. Signed-off-by: Brian Cavagnolo <> Signed-off-by: Andrey Yurovsky <> Acked-by: Johannes Berg <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2009-02-02ath5k: fix mesh point operationAndrey Yurovsky
commit b706e65b40417e03c2451bb3f92488f3736843fa upstream. This patch fixes mesh point operation (thanks to YanBo for pointing out the problem): make mesh point interfaces start beaconing when they come up and configure the RX filter in mesh mode so that mesh beacons and action frames are received. Add mesh point to the check in ath5k_add_interface. Tested with multiple AR5211 cards. Signed-off-by: Andrey Yurovsky <> Acked-by: Nick Kossifidis <> Signed-off-by: John W. Linville <> Cc: Bob Copeland <> Signed-off-by: Greg Kroah-Hartman <>
2009-01-24Linux Kroah-Hartman
2009-01-24fs: sys_sync fixNick Piggin
commit 856bf4d717feb8c55d4e2f817b71ebb70cfbc67b upstream. s_syncing livelock avoidance was breaking data integrity guarantee of sys_sync, by allowing sys_sync to skip writing or waiting for superblocks if there is a concurrent sys_sync happening. This livelock avoidance is much less important now that we don't have the get_super_to_sync() call after every sb that we sync. This was replaced by __put_super_and_need_restart. Signed-off-by: Nick Piggin <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-01-24fs: sync_sb_inodes fixNick Piggin
commit 38f21977663126fef53f5585e7f1653d8ebe55c4 upstream. Fix data integrity semantics required by sys_sync, by iterating over all inodes and waiting for any writeback pages after the initial writeout. Comments explain the exact problem. Signed-off-by: Nick Piggin <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-01-24fs: remove WB_SYNC_HOLDNick Piggin
commit 4f5a99d64c17470a784a6c68064207d82e3e74a5 upstream. Remove WB_SYNC_HOLD. The primary motiviation is the design of my anti-starvation code for fsync. It requires taking an inode lock over the sync operation, so we could run into lock ordering problems with multiple inodes. It is possible to take a single global lock to solve the ordering problem, but then that would prevent a future nice implementation of "sync multiple inodes" based on lock order via inode address. Seems like a backward step to remove this, but actually it is busted anyway: we can't use the inode lists for data integrity wait: an inode can be taken off the dirty lists but still be under writeback. In order to satisfy data integrity semantics, we should wait for it to finish writeback, but if we only search the dirty lists, we'll miss it. It would be possible to have a "writeback" list, for sys_sync, I suppose. But why complicate things by prematurely optimise? For unmounting, we could avoid the "livelock avoidance" code, which would be easier, but again premature IMO. Fixing the existing data integrity problem will come next. Signed-off-by: Nick Piggin <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-01-24mm: direct IO starvation improvementNick Piggin
commit 48b47c561e41525061b5bc0cfd67d6367fd11dc4 upstream. Direct IO can invalidate and sync a lot of pagecache pages in the mapping. A 4K direct IO will actually try to sync and/or invalidate the pagecache of the entire file, for example (which might be many GB or TB large). Improve this by doing range syncs. Also, memory no longer has to be unmapped to catch the dirty bits for syncing, as dirty bits would remain coherent due to dirty mmap accounting. This fixes the immediate DM deadlocks when doing direct IO reads to block device with a mounted filesystem, if only by papering over the problem somewhat rather than addressing the fsync starvation cases. Signed-off-by: Nick Piggin <> Reviewed-by: Jeff Moyer <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2009-01-24mm: do_sync_mapping_range integrity fixNick Piggin
commit ee53a891f47444c53318b98dac947ede963db400 upstream. Chris Mason notices do_sync_mapping_range didn't actually ask for data integrity writeout. Unfortunately, it is advertised as being usable for data integrity operations. This is a data integrity bug. Signed-off-by: Nick Piggin <> Cc: Chris Mason <> Cc: Dave Chinner <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>