aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-03-25TTY: 8250, revert module name changeJiri Slaby2-6/+6
In 3.7 the 8250 module name was changed unintentionally from 8250 to 8250_core by commit 835d844d1a28efba81d5aca7385e24c29d3a6db2 (8250_pnp: do pnp probe before legacy probe). We then had to re-introduce the old module options to ensure the old good 8250.nr_uart & co. still work. This can be done only by a very dirty hack and we did it in f2b8dfd9e480c3db3bad0c25c590a5d11b31f4ef (serial: 8250: Keep 8250.<xxxx> module options functional after driver rename). That is so damn ugly so that I decided to revert to the old module name and deprecate the new 8250_core options present in 3.7 and 3.8 only. The deprecation will happen in the following patch. Note that this patch changes the hack above to support "8250_core.*", because we now have "8250.*" natively. Signed-off-by: Jiri Slaby <[email protected]> Cc: Josh Boyer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-03-25libfcoe: Fix fcoe_sysfs VN2VN modeRobert Love1-15/+45
The libfc discovery layer is being initialized in the 'create' paths for both legacy libfcoe module parameters and fcoe_sysfs control interfaces. The problem is that for VN2VN mode the discovery layer is initialized as if it were in 'fabric' mode and it is not re-configured when the mode is changed to 'vn2vn'. This patch splits out code that needs to be initialized once and code that can, and should be, re-configured when the mode changes. Additionally this patch makes that change so that the discovery layer can be reconfigured to the libfcoe implementation when in 'vn2vn' mode. Signed-off-by: Robert Love <[email protected]> Tested-by: Jack Morgan <[email protected]> Reviewed-by: Bhanu Prakash Gollapudi <[email protected]>
2013-03-25libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}Robert Love4-11/+23
Split discovery initialization in code that is setup once (fcoe_disc_init) and code that can be re-configured (fcoe_disc_config). Signed-off-by: Robert Love <[email protected]> Tested-by: Jack Morgan <[email protected]> Reviewed-by: Bhanu Prakash Gollapudi <[email protected]>
2013-03-25libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery layer ↵Robert Love4-9/+11
initialization Currently libfcoe is doing some libfc discovery layer initialization outside of libfc. This patch moves this code into libfc and sets up a split in discovery (one time) initialization code and (re-configurable) settings that will come in the next patch. Signed-off-by: Robert Love <[email protected]> Tested-by: Jack Morgan <[email protected]> Reviewed-by: Bhanu Prakash Gollapudi <[email protected]>
2013-03-25fcoe: Fix deadlock between create and destroy pathsRobert Love1-4/+11
We can deadlock (s_active and fcoe_config_mutex) if a port is being destroyed at the same time one is being created. [ 4200.503113] ====================================================== [ 4200.503114] [ INFO: possible circular locking dependency detected ] [ 4200.503116] 3.8.0-rc5+ #8 Not tainted [ 4200.503117] ------------------------------------------------------- [ 4200.503118] kworker/3:2/2492 is trying to acquire lock: [ 4200.503119] (s_active#292){++++.+}, at: [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503127] but task is already holding lock: [ 4200.503128] (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe] [ 4200.503133] which lock already depends on the new lock. [ 4200.503135] the existing dependency chain (in reverse order) is: [ 4200.503136] -> #1 (fcoe_config_mutex){+.+.+.}: [ 4200.503139] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503143] [<ffffffff816ca7be>] mutex_lock_nested+0x6e/0x360 [ 4200.503146] [<ffffffffa02f11bd>] fcoe_enable+0x1d/0xb0 [fcoe] [ 4200.503148] [<ffffffffa02f127d>] fcoe_ctlr_enabled+0x2d/0x50 [fcoe] [ 4200.503151] [<ffffffffa02ffbe8>] store_ctlr_enabled+0x38/0x90 [libfcoe] [ 4200.503154] [<ffffffff81424878>] dev_attr_store+0x18/0x30 [ 4200.503157] [<ffffffff8122b750>] sysfs_write_file+0xe0/0x150 [ 4200.503160] [<ffffffff811b334c>] vfs_write+0xac/0x180 [ 4200.503162] [<ffffffff811b3692>] sys_write+0x52/0xa0 [ 4200.503164] [<ffffffff816d7159>] system_call_fastpath+0x16/0x1b [ 4200.503167] -> #0 (s_active#292){++++.+}: [ 4200.503170] [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90 [ 4200.503172] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503174] [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160 [ 4200.503176] [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503178] [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0 [ 4200.503180] [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100 [ 4200.503183] [<ffffffff814251eb>] device_remove_groups+0x3b/0x60 [ 4200.503185] [<ffffffff81425534>] device_remove_attrs+0x44/0x80 [ 4200.503187] [<ffffffff81425e97>] device_del+0x127/0x1c0 [ 4200.503189] [<ffffffff81425f52>] device_unregister+0x22/0x60 [ 4200.503191] [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe] [ 4200.503194] [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe] [ 4200.503196] [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe] [ 4200.503198] [<ffffffff8107ee91>] process_one_work+0x1a1/0x580 [ 4200.503203] [<ffffffff81080c6e>] worker_thread+0x15e/0x440 [ 4200.503205] [<ffffffff8108715a>] kthread+0xea/0xf0 [ 4200.503207] [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0 [ 4200.503209] other info that might help us debug this: [ 4200.503211] Possible unsafe locking scenario: [ 4200.503212] CPU0 CPU1 [ 4200.503213] ---- ---- [ 4200.503214] lock(fcoe_config_mutex); [ 4200.503215] lock(s_active#292); [ 4200.503218] lock(fcoe_config_mutex); [ 4200.503219] lock(s_active#292); [ 4200.503221] *** DEADLOCK *** [ 4200.503223] 3 locks held by kworker/3:2/2492: [ 4200.503224] #0: (fcoe){.+.+.+}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580 [ 4200.503228] #1: ((&port->destroy_work)){+.+.+.}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580 [ 4200.503232] #2: (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe] [ 4200.503236] stack backtrace: [ 4200.503238] Pid: 2492, comm: kworker/3:2 Not tainted 3.8.0-rc5+ #8 [ 4200.503240] Call Trace: [ 4200.503243] [<ffffffff816c2f09>] print_circular_bug+0x1fb/0x20c [ 4200.503246] [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90 [ 4200.503248] [<ffffffff810c463a>] ? debug_check_no_locks_freed+0x9a/0x180 [ 4200.503250] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503253] [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70 [ 4200.503255] [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160 [ 4200.503258] [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70 [ 4200.503260] [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503262] [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0 [ 4200.503265] [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100 [ 4200.503273] [<ffffffff814251eb>] device_remove_groups+0x3b/0x60 [ 4200.503275] [<ffffffff81425534>] device_remove_attrs+0x44/0x80 [ 4200.503277] [<ffffffff81425e97>] device_del+0x127/0x1c0 [ 4200.503279] [<ffffffff81425f52>] device_unregister+0x22/0x60 [ 4200.503282] [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe] [ 4200.503285] [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe] [ 4200.503287] [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe] [ 4200.503290] [<ffffffff8107ee91>] process_one_work+0x1a1/0x580 [ 4200.503292] [<ffffffff8107ee2b>] ? process_one_work+0x13b/0x580 [ 4200.503295] [<ffffffffa02f3250>] ? fcoe_if_destroy+0x230/0x230 [fcoe] [ 4200.503297] [<ffffffff81080c6e>] worker_thread+0x15e/0x440 [ 4200.503299] [<ffffffff81080b10>] ? busy_worker_rebind_fn+0x100/0x100 [ 4200.503301] [<ffffffff8108715a>] kthread+0xea/0xf0 [ 4200.503304] [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160 [ 4200.503306] [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0 [ 4200.503308] [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160 Signed-off-by: Robert Love <[email protected]> Tested-by: Jack Morgan <[email protected]>
2013-03-25Merge tag 'msm-fix-3.9' of ↵Arnd Bergmann1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into fixes From David Brown <[email protected]>: This fix is intended for v3.9. It fixes a timer bug on MSM targets that cause system hangs. * tag 'msm-fix-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm: ARM: msm: Stop counting before reprogramming clockevent Signed-off-by: Arnd Bergmann <[email protected]>
2013-03-26powerpc: define the conditions where the ePAPR idle hcall can be supportedStuart Yoder1-0/+6
For 32-bit, CONFIG_EPAPR_PARAVIRT pulls in both epapr_paravirt.c and epapr_hcalls.c which contains the 32-bit paravirt idle loop. For 64-bit, the paravirt idle loop is in idle_book3e.S and that source file is included only if CONFIG_PPC_BOOK3E_64 defined. This patch makes that dependency for 64-bit explicit. Fixes these build errors: arch/powerpc/kernel/built-in.o: In function `restore_pblist_ptr': ftrace.c:(.toc+0xdc0): undefined reference to `epapr_ev_idle_start' ftrace.c:(.toc+0xdd0): undefined reference to `epapr_ev_idle' Signed-off-by: Stuart Yoder <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
2013-03-25USB: EHCI: fix bug in iTD/siTD DMA pool allocationSoeren Moch1-0/+2
[Description written by Alan Stern] Soeren tracked down a very difficult bug in ehci-hcd's DMA pool management of iTD and siTD structures. Some background: ehci-hcd gives each isochronous endpoint its own set of active and free itd's (or sitd's for full-speed devices). When a new itd is needed, it is taken from the head of the free list, if possible. However, itd's must not be used twice in a single frame because the hardware continues to access the data structure for the entire duration of a frame. Therefore if the itd at the head of the free list has its "frame" member equal to the current value of ehci->now_frame, it cannot be reused and instead a new itd is allocated from the DMA pool. The entries on the free list are not released back to the pool until the endpoint is no longer in use. The bug arises from the fact that sometimes an itd can be moved back onto the free list before itd->frame has been set properly. In Soeren's case, this happened because ehci-hcd can allocate one more itd than it actually needs for an URB; the extra itd may or may not be required depending on how the transfer aligns with a frame boundary. For example, an URB with 8 isochronous packets will cause two itd's to be allocated. If the URB is scheduled to start in microframe 3 of frame N then it will require both itds: one for microframes 3 - 7 of frame N and one for microframes 0 - 2 of frame N+1. But if the URB had been scheduled to start in microframe 0 then it would require only the first itd, which could cover microframes 0 - 7 of frame N. The second itd would be returned to the end of the free list. The itd allocation routine initializes the entire structure to 0, so the extra itd ends up on the free list with itd->frame set to 0 instead of a meaningful value. After a while the itd reaches the head of the list, and occasionally this happens when ehci->now_frame is equal to 0. Then, even though it would be okay to reuse this itd, the driver thinks it must get another itd from the DMA pool. For as long as the isochronous endpoint remains in use, this flaw in the mechanism causes more and more itd's to be taken slowly from the DMA pool. Since none are released back, the pool eventually becomes exhausted. This reuslts in memory allocation failures, which typically show up during a long-running audio stream. Video might suffer the same effect. The fix is very simple. To prevent allocations from the pool when they aren't needed, make sure that itd's sent back to the free list prematurely have itd->frame set to an invalid value which can never be equal to ehci->now_frame. This should be applied to -stable kernels going back to 3.6. Signed-off-by: Soeren Moch <[email protected]> Signed-off-by: Alan Stern <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-03-25bnx2fc: Make the fcoe_cltr the SCSI host parentRobert Love1-3/+2
The fcoemon userspace daemon is searching for the a hostX under the the /sys/bus/fcoe/devices/ctlrX/ entries. When interfaces created using fcoe_sysfs and fcoe.ko this linkage is setup correctly, but bnx2fc is not doing the same thing and therefore fcoemon does not create the fcoe interface for bnx2fc. This patch sets up the correct linkage for bnx2fc such that fcoemon will work correctly with fcoe_sysfs and bnx2fc. Signed-off-by: Robert Love <[email protected]> Acked-by: Bhanu Prakash Gollapudi <[email protected]>
2013-03-25mwifiex: reset skb->data after processing PCIe sleep confirm cmd resposeAvinash Patil1-0/+1
This patch is a bug fix for an issue wherein power save was not working for PCIe. This happens because for processing power save sleep confirm command we pull skb so that skb->data points ahead of interface header. We use same skb to get other cmda responses as well. So if we don't push skb after processing cmd response, it results into reduction in skb->len and finally skb->len reaches zero. This causes failure in processing sleep command response. Fix this by pushing skb by INTF_HEADER_LEN at the end of command response processing. Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-03-25Merge branch 'for-john' of ↵John W. Linville12-76/+154
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
2013-03-25staging: comedi: s626: fix continuous acquisitionIan Abbott1-1/+1
For the s626 driver, there is a bug in the handling of asynchronous commands on the AI subdevice when the stop source is `TRIG_NONE`. The command should run continuously until cancelled, but the interrupt handler stops the command running after the first scan. The command set-up function `s626_ai_cmd()` contains this code: switch (cmd->stop_src) { case TRIG_COUNT: /* data arrives as one packet */ devpriv->ai_sample_count = cmd->stop_arg; devpriv->ai_continous = 0; break; case TRIG_NONE: /* continous acquisition */ devpriv->ai_continous = 1; devpriv->ai_sample_count = 0; break; } The interrupt handler `s626_irq_handler()` contains this code: if (!(devpriv->ai_continous)) devpriv->ai_sample_count--; if (devpriv->ai_sample_count <= 0) { devpriv->ai_cmd_running = 0; /* ... */ } So `devpriv->ai_sample_count` is only decremented for the `TRIG_COUNT` case, but `devpriv->ai_cmd_running` is set to 0 (and the command stopped) regardless. Fix this in `s626_ai_cmd()` by setting `devpriv->ai_sample_count = 1` for the `TRIG_NONE` case. The interrupt handler will not decrement it so it will remain greater than 0 and the check for stopping the acquisition will fail. Cc: stable <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-03-25[media] fix compilation with both V4L2 and I2C as 'm'Mauro Carvalho Chehab1-1/+1
When config options are: CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2=m CONFIG_I2C=m Compilation breaks, as reported by: https://bugzilla.kernel.org/show_bug.cgi?id=55681 Before changeset 7b34be71db533f3e0cf93d53cf62d036cdb5418a, no compilation errors occurred. However, the I2C code there at v4l2-device was incorrectly disabled. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2013-03-25ARM64: early_printk: Fix check for CONFIG_ARM64_64K_PAGESBen Hutchings1-1/+1
The 'CONFIG_' prefix is not implicit in IS_ENABLED(). Signed-off-by: Ben Hutchings <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Paul Bolle <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2013-03-25ipv6: fix bad free of addrconf_init_netHong Zhiguo1-16/+10
Signed-off-by: Hong Zhiguo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-25xhci: Don't warn on empty ring for suspended devices.Sarah Sharp1-8/+15
When a device attached to the roothub is suspended, the endpoint rings are stopped. The host may generate a completion event with the completion code set to 'Stopped' or 'Stopped Invalid' when the ring is halted. The current xHCI code prints a warning in that case, which can be really annoying if the USB device is coming into and out of suspend. Remove the unnecessary warning. Signed-off-by: Sarah Sharp <[email protected]> Tested-by: Stephen Hemminger <[email protected]>
2013-03-25usb: xhci: Fix TRB transfer length macro used for Event TRB.Vivek Gautam2-12/+16
Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci: Bulk transfer support". This patch will have issues applying to older kernels. Signed-off-by: Vivek gautam <[email protected]> Signed-off-by: Sarah Sharp <[email protected]> Cc: [email protected]
2013-03-25usb/acpi: binding xhci root hub usb port with ACPILan Tianyu1-1/+7
This patch is to bind xhci root hub usb port with its acpi node. The port num in the acpi table matches with the sequence in the xhci extended capabilities table. So call usb_hcd_find_raw_port_number() to transfer hub port num into raw port number which associates with the sequence in the xhci extended capabilities table before binding. Signed-off-by: Lan Tianyu <[email protected]> Signed-off-by: Sarah Sharp <[email protected]>
2013-03-25usb: add find_raw_port_number callback to struct hc_driver()Lan Tianyu6-28/+42
xhci driver divides the root hub into two logical hubs which work respectively for usb 2.0 and usb 3.0 devices. They are independent devices in the usb core. But in the ACPI table, it's one device node and all usb2.0 and usb3.0 ports are under it. Binding usb port with its acpi node needs the raw port number which is reflected in the xhci extended capabilities table. This patch is to add find_raw_port_number callback to struct hc_driver(), fill it with xhci_find_raw_port_number() which will return raw port number and add a wrap usb_hcd_find_raw_port_number(). Otherwise, refactor xhci_find_real_port_number(). Using xhci_find_raw_port_number() to get real index in the HW port status registers instead of scanning through the xHCI roothub port array. This can help to speed up. All addresses in xhci->usb2_ports and xhci->usb3_ports array are kown good ports and don't include following bad ports in the extended capabilities talbe. (1) root port that doesn't have an entry (2) root port with unknown speed (3) root port that is listed twice and with different speeds. So xhci_find_raw_port_number() will only return port num of good ones and never touch bad ports above. Signed-off-by: Lan Tianyu <[email protected]> Signed-off-by: Sarah Sharp <[email protected]>
2013-03-25usb: xhci: fix build warningPeter Chen1-6/+8
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In function ‘handle_port_status’: /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580: warning: ‘hcd’ may be used uninitialized in this function Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Sarah Sharp <[email protected]>
2013-03-25unix: fix a race condition in unix_release()Paul Moore1-4/+3
As reported by Jan, and others over the past few years, there is a race condition caused by unix_release setting the sock->sk pointer to NULL before properly marking the socket as dead/orphaned. This can cause a problem with the LSM hook security_unix_may_send() if there is another socket attempting to write to this partially released socket in between when sock->sk is set to NULL and it is marked as dead/orphaned. This patch fixes this by only setting sock->sk to NULL after the socket has been marked as dead; I also take the opportunity to make unix_release_sock() a void function as it only ever returned 0/success. Dave, I think this one should go on the -stable pile. Special thanks to Jan for coming up with a reproducer for this problem. Reported-by: Jan Stancek <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-25Merge tag 'rdma-for-linus' of ↵Linus Torvalds11-19/+27
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband Pull infiniband/rdma fixes from Roland Dreier: "Small batch of InfiniBand/RDMA fixes for 3.9: - Fix for TX lockup in IPoIB - QLogic -> Intel update for qib driver - Small static checker fix for qib - Fix error path return value in cxgb4" * tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: IB/qib: change QLogic to Intel IB/ipath: Silence a static checker warning IPoIB: Fix send lockup due to missed TX completion RDMA/cxgb4: Fix error return code in create_qp()
2013-03-25Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds7-21/+28
Pull ARM SoC bug fixes from Arnd Bergmann: "Four patches for arm-soc this week: - Kevin Hilman is no longer reachable under his previous email address. He submitted the patch earlier, but nobody felt responsible to pick it up. - One Tegra fix for an incorect register address in device tree. - IMX multiplatform support exposes a configuration option that leads to unbootable kernels on all other machines and that needs to depend on that platform. - A nontrivial bug fix for the setup of the mxs video output." * tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: MAINTAINERS: update email address for Kevin Hilman ARM: tegra: fix register address of slink controller ARM: imx: add dependency check for DEBUG_IMX_UART_PORT ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
2013-03-25Merge branch 'for-3.9' of git://linux-nfs.org/~bfields/linuxLinus Torvalds2-6/+8
Pull nfsd bugfixes from J Bruce Fields: "Fixes for a couple mistakes in the new DRC code. And thanks to Kent Overstreet for noticing we've been sync'ing the wrong range on stable writes since 3.8." * 'for-3.9' of git://linux-nfs.org/~bfields/linux: nfsd: fix bad offset use nfsd: fix startup order in nfsd_reply_cache_init nfsd: only unhash DRC entries that are in the hashtable
2013-03-25SUNRPC: Add barriers to ensure read ordering in rpc_wake_up_task_queue_lockedTrond Myklebust1-2/+7
We need to be careful when testing task->tk_waitqueue in rpc_wake_up_task_queue_locked, because it can be changed while we are holding the queue->lock. By adding appropriate memory barriers, we can ensure that it is safe to test task->tk_waitqueue for equality if the RPC_TASK_QUEUED bit is set. Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected]
2013-03-25cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init()Viresh Kumar1-2/+0
With the addition of following patch: fcf8058 cpufreq: Simplify cpufreq_add_dev() cpufreq driver's .init() routine must initialize policy->cpus with mask of all possible CPUs (Online + Offline) that share the clock. Then the core would copy this mask onto policy->related_cpus and will reset policy->cpus to carry only online cpus. acpi-cpufreq driver wasn't updated with this assumption and so sometimes when we try to hot[un]plug CPUs at run time, sysfs directories get corrupted. This patch fixes acpi-cpufreq driver against this corruption. Reported-and-tested-by: Maciej Rutecki <[email protected]> Tested-by: Borislav Petkov <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-03-25cpufreq: stats: do cpufreq_cpu_put() corresponding to cpufreq_cpu_get()viresh kumar1-4/+8
In cpufreq_stats_free_sysfs() we aren't balancing calls to cpufreq_cpu_get() with cpufreq_cpu_put(). This will never let us have ref count to policy->kobj as zero. We will get a hang if somehow cpufreq_driver_unregister() is called. And that can happen when we compile our driver as module and insmod/rmmod it. Signed-off-by: Viresh Kumar <[email protected]> Acked-by: Amit Kucheria <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-03-25intel-pstate: Use #defines instead of hard-coded values.Konrad Rzeszutek Wilk2-3/+4
They are defined in coreboot (MSR_PLATFORM) and the other one is already defined in msr-index.h. Let's use those. Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Dirk Brandewie <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-03-25cpufreq / intel_pstate: Fix calculation of current frequencyDirk Brandewie1-1/+1
Use the correct pstate value to calculate the effective frequency. References: https://bugzilla.redhat.com/show_bug.cgi?id=923942 Reported-by: Satish Balay <[email protected]> Signed-off-by: Dirk Brandewie <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-03-25cpufreq / intel_pstate: Add function to check that all MSRs are validDirk Brandewie1-0/+26
Some VMs seem to try to implement some MSRs but not all the registers the driver needs. Check to make sure all the MSR that we need are available. If any of the required MSRs are not available refuse to load. References: https://bugzilla.redhat.com/show_bug.cgi?id=922923 Reported-by: Josh Stone <[email protected]> Signed-off-by: Dirk Brandewie <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-03-25Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds11-73/+384
Pull drm fixes from Dave Airlie: "Exynos and Intel fixes. The intel fixes are fairly straightforward, mostly reverts due to bugs found. The exynos one is a big larger since they found some issues with the G2D engine and iommu interaction, and needed to verify the operations a lot better than they were previously, otherwise a user app can just crash the kernel with an iommu fault." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: Revert "drm/i915: write backlight harder" drm/i915: don't disable the power well yet Revert "drm/i915: set TRANSCODER_EDP even earlier" drm/exynos: Check g2d cmd list for g2d restrictions drm/exynos: Add a new function to get gem buffer size drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Clean up some G2D codes for readability drm/exynos: Fix G2D core malfunctioning issue drm/exynos: clear node object type at gem unmap drm/exynos: Fix error routine to getting dma addr. drm/exynos: Replaced kzalloc & memcpy with kmemdup drm/exynos: fimd: calculate the correct address offset drm/exynos: Make mixer_check_timing static drm/exynos: modify the compatible string for exynos fimd
2013-03-25xfrm: Fix esn sequence number diff calculation in xfrm_replay_notify_esn()Mathias Krause1-4/+2
Commit 0017c0b "xfrm: Fix replay notification for esn." is off by one for the sequence number wrapped case as UINT_MAX is 0xffffffff, not 0x100000000. ;) Just calculate the diff like done everywhere else in the file. Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2013-03-25powerpc: make additional room in exception vector areaChen Gang1-72/+72
The FWNMI region is fixed at 0x7000 and the vector are now overflowing that with allmodconfig. Fix that by moving slb_miss_realmode code out of that region as it doesn't need to be that close to the call sites (it is a _GLOBAL function) Fixes this build error: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
2013-03-25Merge branch 'drm-intel-fixes' of ↵Dave Airlie5-13/+19
git://people.freedesktop.org/~danvet/drm-intel into HEAD Daniel writes: "Just three revert/disable by default patches, one of them cc: stable (since the offending commit was cc: stable, too)." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: Revert "drm/i915: write backlight harder" drm/i915: don't disable the power well yet Revert "drm/i915: set TRANSCODER_EDP even earlier"
2013-03-25Merge branch 'exynos-drm-fixes' of ↵Dave Airlie6-60/+365
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into HEAD Inki writes: Includes bug fixes and code cleanups. And it considers some restrictions to G2D hardware. With this, the malfunction and page fault issues to g2d driver would be fixed. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: Check g2d cmd list for g2d restrictions drm/exynos: Add a new function to get gem buffer size drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Clean up some G2D codes for readability drm/exynos: Fix G2D core malfunctioning issue drm/exynos: clear node object type at gem unmap drm/exynos: Fix error routine to getting dma addr. drm/exynos: Replaced kzalloc & memcpy with kmemdup drm/exynos: fimd: calculate the correct address offset drm/exynos: Make mixer_check_timing static drm/exynos: modify the compatible string for exynos fimd
2013-03-24tcp: undo spurious timeout after SACK renegingYuchung Cheng1-5/+2
On SACK reneging the sender immediately retransmits and forces a timeout but disables Eifel (undo). If the (buggy) receiver does not drop any packet this can trigger a false slow-start retransmit storm driven by the ACKs of the original packets. This can be detected with undo and TCP timestamps. Signed-off-by: Yuchung Cheng <[email protected]> Acked-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-24bnx2x: fix assignment of signed expression to unsigned variableKumar Amit Mehta1-9/+9
fix for incorrect assignment of signed expression to unsigned variable. Signed-off-by: Kumar Amit Mehta <[email protected]> Acked-by: Dmitry Kravkov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-24bridge: fix crash when set mac address of br interfaceHong zhi guo1-1/+1
When I tried to set mac address of a bridge interface to a mac address which already learned on this bridge, I got system hang. The cause is straight forward: function br_fdb_change_mac_address calls fdb_insert with NULL source nbp. Then an fdb lookup is performed. If an fdb entry is found and it's local, it's OK. But if it's not local, source is dereferenced for printk without NULL check. Signed-off-by: Hong Zhiguo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-248021q: fix a potential use-after-freeCong Wang1-7/+7
vlan_vid_del() could possibly free ->vlan_info after a RCU grace period, however, we may still refer to the freed memory area by 'grp' pointer. Found by code inspection. This patch moves vlan_vid_del() as behind as possible. Cc: Patrick McHardy <[email protected]> Cc: "David S. Miller" <[email protected]> Signed-off-by: Cong Wang <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-24net: remove a WARN_ON() in net_enable_timestamp()Eric Dumazet1-1/+0
The WARN_ON(in_interrupt()) in net_enable_timestamp() can get false positive, in socket clone path, run from softirq context : [ 3641.624425] WARNING: at net/core/dev.c:1532 net_enable_timestamp+0x7b/0x80() [ 3641.668811] Call Trace: [ 3641.671254] <IRQ> [<ffffffff80286817>] warn_slowpath_common+0x87/0xc0 [ 3641.677871] [<ffffffff8028686a>] warn_slowpath_null+0x1a/0x20 [ 3641.683683] [<ffffffff80742f8b>] net_enable_timestamp+0x7b/0x80 [ 3641.689668] [<ffffffff80732ce5>] sk_clone_lock+0x425/0x450 [ 3641.695222] [<ffffffff8078db36>] inet_csk_clone_lock+0x16/0x170 [ 3641.701213] [<ffffffff807ae449>] tcp_create_openreq_child+0x29/0x820 [ 3641.707663] [<ffffffff807d62e2>] ? ipt_do_table+0x222/0x670 [ 3641.713354] [<ffffffff807aaf5b>] tcp_v4_syn_recv_sock+0xab/0x3d0 [ 3641.719425] [<ffffffff807af63a>] tcp_check_req+0x3da/0x530 [ 3641.724979] [<ffffffff8078b400>] ? inet_hashinfo_init+0x60/0x80 [ 3641.730964] [<ffffffff807ade6f>] ? tcp_v4_rcv+0x79f/0xbe0 [ 3641.736430] [<ffffffff807ab9bd>] tcp_v4_do_rcv+0x38d/0x4f0 [ 3641.741985] [<ffffffff807ae14a>] tcp_v4_rcv+0xa7a/0xbe0 Its safe at this point because the parent socket owns a reference on the netstamp_needed, so we cant have a 0 -> 1 transition, which requires to lock a mutex. Instead of refining the check, lets remove it, as all known callers are safe. If it ever changes in the future, static_key_slow_inc() will complain anyway. Reported-by: Laurent Chavey <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-03-24Merge tag 'pinctrl-fixes-for-v3.9' of ↵Linus Torvalds6-7/+11
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pinctrl fixes from Linus Walleij: "Here are a few pinctrl fixes for the v3.9 rc series: - Usecount bounds checking so we do not go below zero on mux usecounts. - Loop range checking in GPIO ranges in the DT range parser. - Proper print in debugfs for pinconf state. - Fix compilation bug in generic pinconf code. - Minor bugfixes to abx500 and mvebu drivers." * tag 'pinctrl-fixes-for-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinmux: forbid mux_usecount to be set at UINT_MAX pinctrl: mvebu: fix checking for SoC specific controls pinctrl: generic: Fix compilation error pinctrl: Print the correct information in debugfs pinconf-state file pinctrl: abx500: Fix checking if pin use AlternateFunction register gpio: fix wrong checking condition for gpio range
2013-03-24Merge branch 'x86/urgent' of ↵Linus Torvalds4-63/+139
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "A collection of minor fixes, more EFI variables paranoia (anti-bricking) plus the ability to disable the pstore either as a runtime default or completely, due to bricking concerns." * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE x86, microcode_intel_early: Mark apply_microcode_early() as cpuinit efivars: Handle duplicate names from get_next_variable() efivars: explicitly calculate length of VariableName efivars: Add module parameter to disable use as a pstore backend efivars: Allow disabling use as a pstore backend x86-32, microcode_intel_early: Fix crash with CONFIG_DEBUG_VIRTUAL x86-64: Fix the failure case in copy_user_handle_tail()
2013-03-24Revert "drm/i915: write backlight harder"Daniel Vetter1-8/+5
This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <[email protected]> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid fixed a regression in 3.6-rc kernels for which we've never figured out the exact root cause. But some further inspection of the backlight code reveals that it's seriously lacking locking. And especially the asle backlight update is know to get fired (through some smm magic) when writing specific backlight control registers. So the possibility of suffering from races is rather real. Until those races are fixed I don't think it makes sense to try further hacks. Which sucks a bit, but sometimes that's how it is :( References: http://www.mail-archive.com/[email protected]/msg18788.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Tested-by: Takashi Iwai <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: [email protected] (the reverted commit was cc: stable, too) Signed-off-by: Daniel Vetter <[email protected]>
2013-03-24drm/i915: don't disable the power well yetPaulo Zanoni3-0/+9
We're still not 100% ready to disable the power well, so don't disable it for now. When we disable it we break the audio driver (because some of the audio registers are on the power well) and machines with eDP on port D (because it doesn't use TRANSCODER_EDP). Also, instead of just reverting the code, add a Kernel option to let us disable it if we want. This will allow us to keep developing and testing the feature while it's not enabled. This fixes problems caused by the following commit: commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 Author: Daniel Vetter <[email protected]> Date: Tue Jan 29 16:35:20 2013 -0200 drm/i915: dynamic Haswell display power well support References: http://www.mail-archive.com/[email protected]/msg18788.html Cc: Takashi Iwai <[email protected]> Cc: Mengdong Lin <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-03-24Revert "drm/i915: set TRANSCODER_EDP even earlier"Daniel Vetter1-5/+5
This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. The reason is that Takashi Iwai reported a regression bisected to this commit: http://www.mail-archive.com/[email protected]/msg18788.html His machine has eDP on port D (usual desktop all-in-on setup), which intel_dp.c identifies as an eDP panel, but the hsw ddi code mishandles. Closer inspection of the code reveals that haswell_crtc_mode_set also checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell that doesn't make much sense (since there's no edp on the pch), but what this function _really_ checks is whether that edp connector is on port A or port D. It's just that on ilk-ivb port D was on the pch ... So that explains why this seemingly innocent change killed eDP on port D. Furthermore it looks like everything else accidentally works, since we've never enabled eDP on port D support for hsw intentionally (e.g. we still register the HDMI output for port D in that case). But in retrospective I also don't like that this leaks highly platform specific details into common code, and the reason is that the drm vblank layer sucks. So instead I think we should: - move the cpu_transcoder into the dynamic pipe_config tracking (once that's merged). - fix up the drm vblank layer to finally deal with kms crtc objects instead of int pipes. v2: Pimp commit message with the better diagnosis as discussed with Paulo on irc. Cc: Paulo Zanoni <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-03-24mac80211: Don't restart sta-timer if not associated.Ben Greear2-3/+6
I found another crash when deleting lots of virtual stations in a congested environment. I think the problem is that the ieee80211_mlme_notify_scan_completed could call ieee80211_restart_sta_timer for a stopped interface that was about to be deleted. With the following patch I am unable to reproduce the crash. Signed-off-by: Ben Greear <[email protected]> [move check, also make the same change in mesh] Signed-off-by: Johannes Berg <[email protected]>
2013-03-24cfg80211: always check for scan end on P2P deviceJohannes Berg6-47/+92
If a P2P device wdev is removed while it has a scan, then the scan completion might crash later as it is already freed by that time. To avoid the crash always check the scan completion when the P2P device is being removed for some reason. If the driver already canceled it, don't want and free it, otherwise warn and leak it to avoid later crashes. In order to do this, locking needs to be changed away from the rdev mutex (which can't always be guaranteed). For now, use the sched_scan_mtx instead, I'll rename it to just scan_mtx in a later patch. Signed-off-by: Johannes Berg <[email protected]>
2013-03-23Merge tag 'efi-for-3.9-rc4' into x86/urgentH. Peter Anvin1-1/+1
Signed-off-by: H. Peter Anvin <[email protected]>
2013-03-23Linux 3.9-rc4Linus Torvalds1-1/+1
2013-03-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pendingLinus Torvalds6-12/+29
Pull SCSI target fixes from Nicholas Bellinger: "These are mostly minor fixes this time around. The iscsi-target CHAP big-endian bugfix and bump FD_MAX_SECTORS=2048 default patch to allow 1MB sized I/Os for FILEIO backends on >= v3.5 code are both CC'ed to stable. Also, there is a persistent reservations regression that has recently been reported for >= v3.8.x code, that is currently being tracked down for v3.9." * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: target/pscsi: Reject cross page boundary case in pscsi_map_sg target/file: Bump FD_MAX_SECTORS to 2048 to handle 1M sized I/Os tcm_vhost: Flush vhost_work in vhost_scsi_flush() tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint() target: fix possible memory leak in core_tpg_register() target/iscsi: Fix mutual CHAP auth on big-endian arches target_core_sbc: use noop for SYNCHRONIZE_CACHE
Powered by cgit, Gruvboxed by Blaster4385.