summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-09-08nfs: fix kernel warning when removing proc entryCong Wang
I saw the following kernel warning: [ 1852.321222] ------------[ cut here ]------------ [ 1852.326527] WARNING: CPU: 0 PID: 118 at fs/proc/generic.c:521 remove_proc_entry+0x154/0x16b() [ 1852.335630] remove_proc_entry: removing non-empty directory 'fs/nfsfs', leaking at least 'volumes' [ 1852.344084] CPU: 0 PID: 118 Comm: kworker/u8:2 Not tainted 3.16.0+ #540 [ 1852.350036] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 1852.354992] Workqueue: netns cleanup_net [ 1852.358701] 0000000000000000 ffff880116f2fbd0 ffffffff819c03e9 ffff880116f2fc18 [ 1852.366474] ffff880116f2fc08 ffffffff810744ee ffffffff811e0e6e ffff8800d4e96238 [ 1852.373507] ffffffff81dbe665 ffff8800d46a5948 0000000000000005 ffff880116f2fc68 [ 1852.380224] Call Trace: [ 1852.381976] [<ffffffff819c03e9>] dump_stack+0x4d/0x66 [ 1852.385495] [<ffffffff810744ee>] warn_slowpath_common+0x7a/0x93 [ 1852.389869] [<ffffffff811e0e6e>] ? remove_proc_entry+0x154/0x16b [ 1852.393987] [<ffffffff8107457b>] warn_slowpath_fmt+0x4c/0x4e [ 1852.397999] [<ffffffff811e0e6e>] remove_proc_entry+0x154/0x16b [ 1852.402034] [<ffffffff8129c73d>] nfs_fs_proc_net_exit+0x53/0x56 [ 1852.406136] [<ffffffff812a103b>] nfs_net_exit+0x12/0x1d [ 1852.409774] [<ffffffff81785bc9>] ops_exit_list+0x44/0x55 [ 1852.413529] [<ffffffff81786389>] cleanup_net+0xee/0x182 [ 1852.417198] [<ffffffff81088c9e>] process_one_work+0x209/0x40d [ 1852.502320] [<ffffffff81088bf7>] ? process_one_work+0x162/0x40d [ 1852.587629] [<ffffffff810890c1>] worker_thread+0x1f0/0x2c7 [ 1852.673291] [<ffffffff81088ed1>] ? process_scheduled_works+0x2f/0x2f [ 1852.759470] [<ffffffff8108e079>] kthread+0xc9/0xd1 [ 1852.843099] [<ffffffff8109427f>] ? finish_task_switch+0x3a/0xce [ 1852.926518] [<ffffffff8108dfb0>] ? __kthread_parkme+0x61/0x61 [ 1853.008565] [<ffffffff819cbeac>] ret_from_fork+0x7c/0xb0 [ 1853.076477] [<ffffffff8108dfb0>] ? __kthread_parkme+0x61/0x61 [ 1853.140653] ---[ end trace 69c4c6617f78e32d ]--- It looks wrong that we add "/proc/net/nfsfs" in nfs_fs_proc_net_init() while remove "/proc/fs/nfsfs" in nfs_fs_proc_net_exit(). Fixes: commit 65b38851a17 (NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes) Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Dan Aloni <dan@kernelim.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> [Trond: replace uses of remove_proc_entry() with remove_proc_subtree() as suggested by Al Viro] Cc: stable@vger.kernel.org # 3.4.x : 65b38851a17: NFS: Fix /proc/fs/nfsfs/servers Cc: stable@vger.kernel.org # 3.4.x Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-09-08tty: xuartps: Fix tx_emtpy() callbackLars-Peter Clausen
The tx_empty() callback currently checks the TXEMPTY bit in the interrupt status register to decided whether the FIFO should be reported as empty or not. The bit in this register gets set when the FIFO state transitions from non-empty to empty but is cleared again in the interrupt handler. This means it is not suitable to be used to decided whether the FIFO is currently empty or not. Instead use the TXEMPTY bit from the status register which will be set as long as the FIFO is empty. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08tty/serial: at91: BUG: disable interrupts when !UART_ENABLE_MS()Richard Genoud
In set_termios(), interrupts where not disabled if UART_ENABLE_MS() was false. Tested on at91sam9g35. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Cc: stable <stable@vger.kernel.org> # >= 3.16 Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08serial: 8250_dw: Add ACPI ID for Intel BraswellAlan Cox
Another new ACPI identifier for the 8250 dw bindings to cover newer Intel SoCs such as Braswell. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08uwb: init beacon cache entry before registering uwb deviceThomas Pugliese
Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in uwbd_dev_onair so that usermode will only see the device after it is properly initialized. This fixes a kernel panic that can occur if usermode tries to access the IEs sysfs attribute of a UWB device before the driver has had a chance to set the beacon cache entry. Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08Merge branch 'oom_fixes'David S. Miller
Florian Fainelli says: ==================== net: systemport and bcmgenet OOM fixes These two patches fix similar Out of Memory code paths in the SYSTEMPORT and GENET drivers. Under high memory pressure, we could produce an OOPS by passing a NULL pointer to dma_unmap_single(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08net: bcmgenet: check harder for out of memory conditionsFlorian Fainelli
There is a potential case where we might be failing to refill a control block, leaving it with both a NULL skb pointer *and* a NULL dma_unmap_addr. The way we process incoming packets, by first calling dma_unmap_single(), and then only checking for a potential NULL skb can lead to situations where do pass a NULL dma_unmap_addr() to dma_unmap_single(), resulting in an oops. Fix this my moving the NULL skb check earlier, since no backing skb also means no corresponding DMA mapping for this packet. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08net: systemport: check harder for out of memory conditionsFlorian Fainelli
There is a potential case where we might be failing to refill a control block, leaving it with both a NULL skb pointer *and* a NULL dma_unmap_addr. The way we process incoming packets, by first calling dma_unmap_single(), and then only checking for a potential NULL skb can lead to situations where do pass a NULL dma_unmap_addr() to dma_unmap_single(), resulting in an oops. Fix this my moving the NULL skb check earlier, since no backing skb also means no corresponding DMA mapping for this packet. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker deviceTaylor Braun-Jones
Signed-off-by: Taylor Braun-Jones <taylor.braun-jones@ge.com> Cc: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08net/mlx4_en: do not ignore autoneg in mlx4_en_set_pauseparam()Ivan Vecera
The driver does not support pause autonegotiation so it should return -EINVAL when the function is called with non-zero autoneg. Cc: Amir Vadai <amirv@mellanox.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08Merge branch 'for_linus_urgent' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 bugfix from Ted Ts'o. [ Hmm. It's possible we should make kfree() aware of error pointers, and use IS_ERR_OR_NULL rather than a NULL check. But in the meantime this is obviously the right fix. - Linus ] * 'for_linus_urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: avoid trying to kfree an ERR_PTR pointer
2014-09-08Merge branch 'for-3.17' of git://linux-nfs.org/~bfields/linuxLinus Torvalds
Pull nfsd bugfixes from Bruce Fields: "A couple minor nfsd bugfixes" * 'for-3.17' of git://linux-nfs.org/~bfields/linux: lockd: fix rpcbind crash on lockd startup failure nfsd4: fix rd_dircount enforcement
2014-09-08Input: cap1106 - fix register definitionKlaus Goger
Use the correct register address for Calibration Active and Interrupt Enable. Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Acked-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-09-08Input: add missing POINTER / DIRECT properties to a bunch of driversHans de Goede
I've not done a full audit of all mouse drivers, I noticed these ones were missing the POINTER property while working on the POINTING_STICK property. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-09-08Input: add INPUT_PROP_POINTING_STICK propertyHans de Goede
It is useful for userspace to know that there not dealing with a regular mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace can e.g. automatically enable middle button scrollwheel emulation. It is impossible to tell the difference from the evdev info without resorting to putting a list of device / driver names in userspace, this is undesirable. Add a property which allows userspace to see if a device is a pointing stick, and set it on all the pointing stick drivers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-09-08Input: elantech - fix detection of touchpad on ASUS s301lHans de Goede
Adjust Elantech signature validation to account fo rnewer models of touchpads. Cc: stable@vger.kernel.org Reported-and-tested-by: Màrius Monton <marius.monton@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-09-08Lattice ECP3 FPGA: Check firmware pointerJean-Michel Hautbois
This patch corrects a lack of testing. If fw is NULL when calling firmware_load(), it results in a kernel oops. Signed-off-by: Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08USB: document the 'u' flag for usb-storage quirks parameterAlan Stern
Commit d24d481b7d36 (usb-storage: Modify and export adjust_quirks so that it can be used by uas) added the 'u' flag to the quirks module parameter for usb-storage, but neglected to update the documentation. This patch adds the documentation. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> # 3.15+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08usb: host: xhci: fix compliance mode workaroundFelipe Balbi
Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes <alexis.cortes@ti.com> Cc: <stable@vger.kernel.org> # v3.2+ Signed-off-by: Felipe Balbi <balbi@ti.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08drivers: net: ethernet: octeon_mgmt: fix a compiler warningAaro Koskinen
Fix the following compiler warning: drivers/net/ethernet/octeon/octeon_mgmt.c: In function 'octeon_mgmt_clean_tx_buffers': drivers/net/ethernet/octeon/octeon_mgmt.c:295:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port)); ^ Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com> Acked-by: David Daney <david.daney@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08net: fix skb_page_frag_refill() kerneldocEric Dumazet
In commit d9b2938aabf7 ("net: attempt a single high order allocation) I forgot to update kerneldoc, as @prio parameter was renamed to @gfp Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08sunvnet - add missing rmb() for sunvnet driverDavid L Stevens
The sunvnet driver does not have an rmb() in the ring consumer corresponding to the wmb() in the producer. According to Documentation/memory-barriers.txt: "When dealing with CPU-CPU interactions, certain types of memory barrier should always be paired. A lack of appropriate pairing is almost certainly an error." In cases where an rmb() is not a no-op and a consumer is removing data from the ring while a producer is adding new entries, a load reorder would allow CPU1 CPU2 ---- ---- LOAD desc.size [e.g] STORE desc.size <wmb> set desc.hdr.state = VIO_DESC_READY LOAD desc.hdr.state [because VIO_DESC_READY, use old desc.size, already loaded out of order] [CPU2 has reordered apparently unrelated LOADs] To ensure other desc fields are not loaded before checking VIO_DESC_READY, we need an rmb() between the check and desc data accesses. I've also moved the viodbg() call to after the rmb() so that it, too, has current descriptor data even with reordering, which has the side effect that it won't print anything for descriptors that are not VIO_DESC_READY as before. That's a) probably a good thing, since the fields are not necessarily set and, b) better than adding another rmb() just for viodbg(). This would not be possible if strict-ordering is enforced, but then the memory barriers should be no-ops in that case. Signed-off-by: David L Stevens <david.stevens@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-08Btrfs: use insert_inode_locked4 for inode creationChris Mason
Btrfs was inserting inodes into the hash table before we had fully set the inode up on disk. This leaves us open to rare races that allow two different inodes in memory for the same [root, inode] pair. This patch fixes things by using insert_inode_locked4 to insert an I_NEW inode and unlock_new_inode when we're ready for the rest of the kernel to use the inode. It also makes sure to init the operations pointers on the inode before going into the error handling paths. Signed-off-by: Chris Mason <clm@fb.com> Reported-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-08Btrfs: fix fsync data loss after a ranged fsyncFilipe Manana
While we're doing a full fsync (when the inode has the flag BTRFS_INODE_NEEDS_FULL_SYNC set) that is ranged too (covers only a portion of the file), we might have ordered operations that are started before or while we're logging the inode and that fall outside the fsync range. Therefore when a full ranged fsync finishes don't remove every extent map from the list of modified extent maps - as for some of them, that fall outside our fsync range, their respective ordered operation hasn't finished yet, meaning the corresponding file extent item wasn't inserted into the fs/subvol tree yet and therefore we didn't log it, and we must let the next fast fsync (one that checks only the modified list) see this extent map and log a matching file extent item to the log btree and wait for its ordered operation to finish (if it's still ongoing). A test case for xfstests follows. Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com>
2014-09-08Btrfs: kfree()ing ERR_PTRsDan Carpenter
The "inherit" in btrfs_ioctl_snap_create_v2() and "vol_args" in btrfs_ioctl_rm_dev() are ERR_PTRs so we can't call kfree() on them. These kind of bugs are "One Err Bugs" where there is just one error label that does everything. I could set the "inherit = NULL" and keep the single out label but it ends up being more complicated that way. It makes the code simpler to re-order the unwind so it's in the mirror order of the allocation and introduce some new error labels. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Chris Mason <clm@fb.com>
2014-09-08android: fix reference leak in sync_fence_createMaarten Lankhorst
According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. This fixes a memory leak introduced in 3.17's android fence rework. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Colin Cross <ccross@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08x86/efi: Fixup GOT in all boot code pathsMatt Fleming
Maarten reported that his Macbook pro 8.2 stopped booting after commit f23cf8bd5c1f49 ("efi/x86: efistub: Move shared dependencies to <asm/efi.h>"), the main feature of which is changing the visibility of symbol 'efi_early' from local to global. By making 'efi_early' global we end up requiring an entry in the Global Offset Table. Unfortunately, while we do include code to fixup GOT entries in the early boot code, it's only called after we've executed the EFI boot stub. What this amounts to is that references to 'efi_early' in the EFI boot stub don't point to the correct place. Since we've got multiple boot entry points we need to be prepared to fixup the GOT in multiple places, while ensuring that we never do it more than once, otherwise the GOT entries will still point to the wrong place. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-09-08x86/efi: Only load initrd above 4g on second tryYinghai Lu
Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"), the kernel freezes at the earliest possible moment when trying to boot via UEFI on Asus laptop. Revert to old way to load initrd under 4G on first try, second try will use above 4G buffer when initrd is too big and does not fit under 4G. [ The cause of the freeze appears to be a firmware bug when reading file data into buffers above 4GB, though the exact reason is unknown. Mantas reports that the hang can be avoid if the file size is a multiple of 512 bytes, but I've seen some ASUS firmware simply corrupting the file data rather than freezing. Laszlo fixed an issue in the upstream EDK2 DiskIO code in Aug 2013 which may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe: fix source/destination pointer of overrun transfer"). Whatever the cause, it's unlikely that a fix will be forthcoming from the vendor, hence the workaround - Matt ] Cc: Laszlo Ersek <lersek@redhat.com> Reported-by: Mantas Mikulėnas <grawity@gmail.com> Reported-by: Harald Hoyer <harald@redhat.com> Tested-by: Anders Darander <anders@chargestorm.se> Tested-by: Calvin Walton <calvin.walton@kepstin.ca> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-09-08imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind()Russell King
When trying to unbind imx-drm, the following oops was observed from the imx-ldb driver: Unable to handle kernel NULL pointer dereference at virtual address 0000001c pgd = de954000 [0000001c] *pgd=2e92c831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma imx_ldb(C) imx_thermal imx_sdma imx2_wdt snd_soc_sgtl5000 snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux CPU: 1 PID: 1228 Comm: bash Tainted: G C 3.16.0-rc2+ #1229 task: ea378d80 ti: de948000 task.ti: de948000 PC is at imx_ldb_unbind+0x1c/0x58 [imx_ldb] LR is at component_unbind+0x38/0x70 pc : [<bf025068>] lr : [<c0353108>] psr: 200f0013 sp : de949da8 ip : de949dc0 fp : de949dbc r10: e9a44b0c r9 : 00000000 r8 : de949f78 r7 : 00000012 r6 : e9b3f400 r5 : e9b133b8 r4 : e9b13010 r3 : 00000000 r2 : e9b3f400 r1 : ea9a0210 r0 : e9b13020 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 2e95404a DAC: 00000015 Process bash (pid: 1228, stack limit = 0xde948240) Stack: (0xde949da8 to 0xde94a000) ... Backtrace: [<bf02504c>] (imx_ldb_unbind [imx_ldb]) from [<c0353108>] (component_unbind+0x38/0x70) [<c03530d0>] (component_unbind) from [<c03531d4>] (component_unbind_all+0x94/0xc8) [<c0353140>] (component_unbind_all) from [<c04bc224>] (imx_drm_driver_unload+0x34/0x4c) [<c04bc1f0>] (imx_drm_driver_unload) from [<c03394a4>] (drm_dev_unregister+0x2c/0xa0) [<c0339478>] (drm_dev_unregister) from [<c0339f8c>] (drm_put_dev+0x30/0x6c) [<c0339f5c>] (drm_put_dev) from [<c04bc1cc>] (imx_drm_unbind+0x14/0x18) [<c04bc1b8>] (imx_drm_unbind) from [<c03530b4>] (component_master_del+0xbc/0xd8) ... Code: e5904058 e2840010 e2845fea e59430a0 (e593301c) ---[ end trace 4f211c6dbbcd4963 ]--- This is caused by only having one channel out of the pair configured in DT; the second channel remains uninitialised, but upon unbind, the driver attempts to clean up both, thereby dereferencing a NULL pointer. Avoid this by checking that the second channel is initialised. Fixes: 1b3f76756633 ("imx-drm: initialise drm components directly") Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08imx-drm: ipuv3-plane: fix ipu_plane_dpms()Russell King
When unbinding imx-drm, the following oops was observed: Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = e995c000 [00000004] *pgd=4fea5831 Internal error: Oops: 817 [#1] SMP ARM Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma snd_soc_sgtl5000 imx_sdma imx2_wdt imx_ldb(C) imx_thermal snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux CPU: 1 PID: 779 Comm: bash Tainted: G C 3.16.0-rc2+ #1230 task: ea9eb180 ti: ea378000 task.ti: ea378000 PC is at ipu_dp_put+0x10/0x18 LR is at ipu_plane_dpms+0x60/0x8c pc : [<c0350d20>] lr : [<c04bd9e8>] psr: 200f0013 sp : ea379d80 ip : ea379d90 fp : ea379d8c r10: 00100100 r9 : 00000000 r8 : 00200200 r7 : e9ba0264 r6 : e9ba01f8 r5 : 00000000 r4 : ea34b800 r3 : 00000000 r2 : 00000000 r1 : 0000009b r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3995c04a DAC: 00000015 Process bash (pid: 779, stack limit = 0xea378240) Stack: (0xea379d80 to 0xea37a000) ... Backtrace: [<c0350d10>] (ipu_dp_put) from [<c04bd9e8>] (ipu_plane_dpms+0x60/0x8c) [<c04bd988>] (ipu_plane_dpms) from [<c04bda40>] (ipu_disable_plane+0x2c/0x60) [<c04bda14>] (ipu_disable_plane) from [<c04bda9c>] (ipu_plane_destroy+0x28/0x60) [<c04bda74>] (ipu_plane_destroy) from [<c033ff84>] (drm_mode_config_cleanup+0x1b8/0x250) [<c033fdcc>] (drm_mode_config_cleanup) from [<c04bc234>] (imx_drm_driver_unload+0x44/0x4c) [<c04bc1f0>] (imx_drm_driver_unload) from [<c03394a4>] (drm_dev_unregister+0x2c/0xa0) [<c0339478>] (drm_dev_unregister) from [<c0339f8c>] (drm_put_dev+0x30/0x6c) [<c0339f5c>] (drm_put_dev) from [<c04bc1cc>] (imx_drm_unbind+0x14/0x18) [<c04bc1b8>] (imx_drm_unbind) from [<c03530b4>] (component_master_del+0xbc/0xd8) ... Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e5c03004) This is caused by a missing check in ipu_plane_dpms for a NULL pointer. Fixes: b8d181e408af ("staging: drm/imx: add drm plane support") Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08x86-64, ptdump: Mark espfix area only if existentMathias Krause
We should classify the espfix area as such only if we actually have enabled the corresponding option. Otherwise the page table dump might look confusing. Signed-off-by: Mathias Krause <minipli@googlemail.com> Link: http://lkml.kernel.org/r/1410114629-24523-1-git-send-email-minipli@googlemail.com Cc: Arjan van de Ven <arjan.van.de.ven@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2014-09-08drm/radeon: add connector quirk for fujitsu boardAlex Deucher
Vbios connector table lists non-existent VGA port. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83184 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-09-08drm/radeon: fix semaphore value initChristian König
Semaphore values have 64 bits, not 32. This fixes a very subtle bug that disables synchronization when the upper 32bits wasn't zero. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Reviewed-By: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-08drm/radeon: only use me/pfp sync on evergreen+Alex Deucher
The packet seems to cause hangs on some 7xx asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=83616 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-08iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strengthEyal Shapira
The idea here is to translate a value of 0 received from the firmware to the lowest rssi figure. As rx_status->chain_signal is a signed byte the lowest possible value is -128 and not -256. -256 was causing 0 to get stored in the signed byte. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-09-08iwlwifi: add PCI IDs and add then new 3165 seriesOren Givon
This change does the following: 1) Add a new 7265 series PCI ID 2) Add two new 3160 series PCI IDs 3) Add the new 3165 series PCI IDs and configurations Signed-off-by: Oren Givon <oren.givon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-09-08lockd: fix rpcbind crash on lockd startup failureJ. Bruce Fields
Nikita Yuschenko reported that booting a kernel with init=/bin/sh and then nfs mounting without portmap or rpcbind running using a busybox mount resulted in: # mount -t nfs 10.30.130.21:/opt /mnt svc: failed to register lockdv1 RPC service (errno 111). lockd_up: makesock failed, error=-111 Unable to handle kernel paging request for data at address 0x00000030 Faulting instruction address: 0xc055e65c Oops: Kernel access of bad area, sig: 11 [#1] MPC85xx CDS Modules linked in: CPU: 0 PID: 1338 Comm: mount Not tainted 3.10.44.cge #117 task: cf29cea0 ti: cf35c000 task.ti: cf35c000 NIP: c055e65c LR: c0566490 CTR: c055e648 REGS: cf35dad0 TRAP: 0300 Not tainted (3.10.44.cge) MSR: 00029000 <CE,EE,ME> CR: 22442488 XER: 20000000 DEAR: 00000030, ESR: 00000000 GPR00: c05606f4 cf35db80 cf29cea0 cf0ded80 cf0dedb8 00000001 1dec3086 00000000 GPR08: 00000000 c07b1640 00000007 1dec3086 22442482 100b9758 00000000 10090ae8 GPR16: 00000000 000186a5 00000000 00000000 100c3018 bfa46edc 100b0000 bfa46ef0 GPR24: cf386ae0 c07834f0 00000000 c0565f88 00000001 cf0dedb8 00000000 cf0ded80 NIP [c055e65c] call_start+0x14/0x34 LR [c0566490] __rpc_execute+0x70/0x250 Call Trace: [cf35db80] [00000080] 0x80 (unreliable) [cf35dbb0] [c05606f4] rpc_run_task+0x9c/0xc4 [cf35dbc0] [c0560840] rpc_call_sync+0x50/0xb8 [cf35dbf0] [c056ee90] rpcb_register_call+0x54/0x84 [cf35dc10] [c056f24c] rpcb_register+0xf8/0x10c [cf35dc70] [c0569e18] svc_unregister.isra.23+0x100/0x108 [cf35dc90] [c0569e38] svc_rpcb_cleanup+0x18/0x30 [cf35dca0] [c0198c5c] lockd_up+0x1dc/0x2e0 [cf35dcd0] [c0195348] nlmclnt_init+0x2c/0xc8 [cf35dcf0] [c015bb5c] nfs_start_lockd+0x98/0xec [cf35dd20] [c015ce6c] nfs_create_server+0x1e8/0x3f4 [cf35dd90] [c0171590] nfs3_create_server+0x10/0x44 [cf35dda0] [c016528c] nfs_try_mount+0x158/0x1e4 [cf35de20] [c01670d0] nfs_fs_mount+0x434/0x8c8 [cf35de70] [c00cd3bc] mount_fs+0x20/0xbc [cf35de90] [c00e4f88] vfs_kern_mount+0x50/0x104 [cf35dec0] [c00e6e0c] do_mount+0x1d0/0x8e0 [cf35df10] [c00e75ac] SyS_mount+0x90/0xd0 [cf35df40] [c000ccf4] ret_from_syscall+0x0/0x3c The addition of svc_shutdown_net() resulted in two calls to svc_rpcb_cleanup(); the second is no longer necessary and crashes when it calls rpcb_register_call with clnt=NULL. Reported-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru> Fixes: 679b033df484 "lockd: ensure we tear down any live sockets when socket creation fails during lockd_up" Cc: stable@vger.kernel.org Acked-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2014-09-08nfsd4: fix rd_dircount enforcementJ. Bruce Fields
Commit 3b299709091b "nfsd4: enforce rd_dircount" totally misunderstood rd_dircount; it refers to total non-attribute bytes returned, not number of directory entries returned. Bring the code into agreement with RFC 3530 section 14.2.24. Cc: stable@vger.kernel.org Fixes: 3b299709091b "nfsd4: enforce rd_dircount" Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2014-09-08Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A bug fix for the vdso code, the loadparm for booting from SCSI is added and the access permissions for the dasd module parameters are corrected" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/vdso: remove NULL pointer check from clock_gettime s390/ipl: Add missing SCSI loadparm attributes to /sys/firmware s390/dasd: Make module parameter visible in sysfs
2014-09-08drm/i915: Wait for vblank before enabling the TV encoderVille Syrjälä
The vblank waits in intel_tv_detect_type() are timing out for some reason. This is a regression caused removing seemingly useless vblank waits from the modeset seqeuence in: commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 8 19:23:15 2014 +0300 drm/i915: Kill vblank waits after pipe enable on gmch platforms So it turns out they weren't all entirely useless. Apparently the pipe has to go through one full frame before we enable the TV port. Add a vblank wait to intel_enable_tv() to make sure that happens. Another approach was attempted by placing the vblank wait just after enabling the port. The theory behind that attempt was that we need to let the port stay enabled for one full frame before disabling it again during load detection. But that didn't work, and we definitely must have the vblank wait before enabling the port. Cc: stable@vger.kernel.org Cc: Alan Bartlett <ajb@elrepo.org> Tested-by: Alan Bartlett <ajb@elrepo.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08of: Fix memory block alignment in early_init_dt_add_memory_arch()Geert Uytterhoeven
If a memory block is not aligned to PAGE_SIZE, its base address must be rounded up, not down, and its size must be reduced. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-09-08of: make sure of_alias is initialized before accessing itLaurentiu Tudor
Simply swap of_alias and of_chosen initialization so that of_alias ends up read first. This must be done because it is accessed couple of lines below when trying to initialize the of_stdout using the alias based legacy method. [Fixes a752ee5 - tty: Update hypervisor tty drivers to use core stdout parsing code] Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com> [glikely: Don't move the 'if (!of_aliases)' test] Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-09-08of: Documentation regarding attaching OF Selftest testdataGaurav Minocha
This patch add a document that explains how the selftest test data is dynamically attached into the live device tree irrespective of the machine's architecture. Signed-off-by: Gaurav Minocha <gaurav.minocha.os@gmail.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-09-08of: Disabling OF functions that use sysfs if CONFIG_SYSFS disabledGaurav Minocha
This patch is to the fix the recent runtime bug in kernel reported by <fengguang.wu@intel.com>. The bug was exposed by commit b951f9dc, "Enabling OF selftest to run without machine's devicetree" and is exposed when CONFIG_OF_SELFTEST is enabled and CONFIG_SYSFS is disabled. Mail Subject: [OF test] BUG: unable to handle kernel NULL pointer dereference at 00000038 Tested on x86 and arm architecture Signed-off-by: Gaurav Minocha <gaurav.minocha.os@gmail.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-09-08of: correct of_console_check()'s return valueBrian Norris
The comments above of_console_check() say that it will return TRUE if it registers a preferred console, but add_preferred_console() uses a 0-equals-success convention, so this leaves of_console_check() with an inconsistent policy for its return values. Fortunately, nobody was actually checking the return value of of_console_check(), so this isn't significant at the moment. But let's match the comments, so we're doing what we say. Fixes: 3482f2c52b77 ('of: Create of_console_check() for selecting a console specified in /chosen') Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-09-08drm/i915: Evict CS TLBs between batchesChris Wilson
Running igt, I was encountering the invalid TLB bug on my 845g, despite that it was using the CS workaround. Examining the w/a buffer in the error state, showed that the copy from the user batch into the workaround itself was suffering from the invalid TLB bug (the first cacheline was broken with the first two words reversed). Time to try a fresh approach. This extends the workaround to write into each page of our scratch buffer in order to overflow the TLB and evict the invalid entries. This could be refined to only do so after we update the GTT, but for simplicity, we do it before each batch. I suspect this supersedes our current workaround, but for safety keep doing both. v2: The magic number shall be 2. This doesn't conclusively prove that it is the mythical TLB bug we've been trying to workaround for so long, that it requires touching a number of pages to prevent the corruption indicates to me that it is TLB related, but the corruption (the reversed cacheline) is more subtle than a TLB bug, where we would expect it to read the wrong page entirely. Oh well, it prevents a reliable hang for me and so probably for others as well. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08ACPI / RTC: Fix CMOS RTC opregion handler accesses to wrong addressesLee, Chun-Yi
The value64 parameter is an u64 point that used to transfer the value for write to CMOS, or used to return the value that's read from CMOS. The value64 is an u64 point, so don't need get address again. It causes acpi_cmos_rtc_space_handler always return 0 to reader and didn't write expected value to CMOS. Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-08regmap: Fix debugfs-file 'registers' modeMarkus Pargmann
The macro "REGMAP_ALLOW_WRITE_DEBUGFS" can be used to enable write support on the registers file in the debugfs. The mode of the file is fixed to 0400 so it is not possible to write the file ever. This patch fixes the mode by setting it to the correct value depending on the macro. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-08iwlwifi: dvm: disable power save by defaultEmmanuel Grumbach
In https://bugzilla.kernel.org/show_bug.cgi?id=84031, the submitter said that disabling power saving helped, do just that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-09-08iwlwifi: mvm: BT Coex - always initialize smps_modeJohannes Berg
smps_mode is used uninitialized in a debug statement in AP mode, so always initialize it. While at it, fix a typo. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>