commit acbf4c08b347d3a405319212aa6c9f85ea3edfab Author: Jiri Slaby Date: Sat Mar 22 22:02:40 2014 +0100 Linux 3.12.16 commit 4c3280ca0ee91125e8f086d33d879065222d6daa Author: Ilya Dryomov Date: Thu Jan 9 20:08:21 2014 +0200 libceph: fix preallocation check in get_reply() commit f2be82b0058e90b5d9ac2cb896b4914276fb50ef upstream. The check that makes sure that we have enough memory allocated to read in the entire header of the message in question is currently busted. It compares front_len of the incoming message with iov_len field of ceph_msg::front structure, which is used primarily to indicate the amount of data already read in, and not the size of the allocated buffer. Under certain conditions (e.g. a short read from a socket followed by that socket's shutdown and owning ceph_connection reset) this results in a warning similar to [85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0) and, through another bug, leads to forever hung tasks and forced reboots. Fix this by comparing front_len with front_alloc_len field of struct ceph_msg, which stores the actual size of the buffer. Fixes: http://tracker.ceph.com/issues/5425 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit ed0d7f08ff8b76555525a9ee61d8eed2796594c2 Author: Ilya Dryomov Date: Thu Jan 9 20:08:21 2014 +0200 libceph: rename front to front_len in get_reply() commit 3f0a4ac55fe036902e3666be740da63528ad8639 upstream. Rename front local variable to front_len in get_reply() to make its purpose more clear. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit 7335817378e3e4c3325c65b0e15b2918cc04f5c1 Author: Ilya Dryomov Date: Thu Jan 9 20:08:21 2014 +0200 libceph: rename ceph_msg::front_max to front_alloc_len commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream. Rename front_max field of struct ceph_msg to front_alloc_len to make its purpose more clear. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit 8b988a3907cc2ca7d85c4d79a2afec2914b2de0b Author: Michele Baldessari Date: Thu Jan 30 10:51:04 2014 +0000 e100: Fix "disabling already-disabled device" warning commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream. In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received different reports of e100 throwing the following warning: [] ? pci_disable_device+0x85/0x90 [] warn_slowpath_fmt+0x33/0x40 [] pci_disable_device+0x85/0x90 [] __e100_shutdown+0x80/0x120 [e100] [] ? check_preempt_curr+0x65/0x90 [] e100_suspend+0x16/0x30 [e100] [] pci_legacy_suspend+0x2b/0xb0 [] ? wait_for_completion+0x1f/0xd0 [] ? pci_pm_poweroff+0xb0/0xb0 [] pci_pm_freeze+0x94/0xa0 [] dpm_run_callback+0x37/0x80 [] ? pm_wakeup_pending+0xc4/0x140 [] __device_suspend+0xb2/0x1f0 [] async_suspend+0x1f/0x90 [] async_run_entry_fn+0x35/0x140 [] ? wake_up_process+0x1f/0x40 [] process_one_work+0x115/0x370 [] ? start_worker+0x25/0x30 [] ? manage_workers.isra.27+0x1a5/0x250 [] worker_thread+0xfe/0x330 [] ? manage_workers.isra.27+0x250/0x250 [] kthread+0x94/0xa0 [] ret_from_kernel_thread+0x1b/0x28 [] ? insert_kthread_work+0x30/0x30 This patch removes pci_disable_device() from __e100_shutdown(). pci_clear_master() is enough. Signed-off-by: Michele Baldessari Tested-by: Mark Harig Signed-off-by: Aaron Brown Signed-off-by: David S. Miller Cc: Josh Boyer Signed-off-by: Jiri Slaby commit 1e716a5e78cb28cb004ccb58d904191f0d1cbba3 Author: Sarah Sharp Date: Fri Jan 17 15:38:12 2014 -0800 xhci: Fix resume issues on Renesas chips in Samsung laptops commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream. Don Zickus writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by: Sarah Sharp Reported-by: Don Zickus Tested-by: Prarit Bhargava Signed-off-by: Jiri Slaby commit 16cf0c328d308b4bfb2baf0257bfdff47899a6ca Author: Ping Cheng Date: Mon Nov 25 18:43:45 2013 -0800 Input: wacom - make sure touch_max is set for touch devices commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream. Old single touch Tablet PCs do not have touch_max set at wacom_features. Since touch device at lease supports one finger, assign touch_max to 1 when touch usage is defined in its HID Descriptor and touch_max is not pre-defined. Tested-by: Jason Gerecke Signed-off-by: Ping Cheng Reviewed-by: Chris Bagwell Signed-off-by: Dmitry Torokhov Cc: Josh Boyer Signed-off-by: Jiri Slaby commit 5b6325c676690b26685c55998c49cea0a437fd24 Author: Marcelo Tosatti Date: Fri Jan 3 17:00:51 2014 -0200 KVM: VMX: fix use after free of vmx->loaded_vmcs commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream. After free_loaded_vmcs executes, the "loaded_vmcs" structure is kfreed, and now vmx->loaded_vmcs points to a kfreed area. Subsequent free_loaded_vmcs then attempts to manipulate vmx->loaded_vmcs. Switch the order to avoid the problem. https://bugzilla.redhat.com/show_bug.cgi?id=1047892 Reviewed-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Cc: Josh Boyer Signed-off-by: Jiri Slaby commit df071bf16dc2e1d12d36f8d3861df672376d5c75 Author: Marcelo Tosatti Date: Fri Jan 3 17:09:32 2014 -0200 KVM: x86: handle invalid root_hpa everywhere commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream. Rom Freiman notes other code paths vulnerable to bug fixed by 989c6b34f6a9480e397b. Signed-off-by: Marcelo Tosatti Cc: Josh Boyer Signed-off-by: Jiri Slaby commit 0334c2e03c00144d2ff68c97a1ff93a640883c57 Author: Marcelo Tosatti Date: Thu Dec 19 15:28:51 2013 -0200 KVM: MMU: handle invalid root_hpa at __direct_map commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream. It is possible for __direct_map to be called on invalid root_hpa (-1), two examples: 1) try_async_pf -> can_do_async_pf -> vmx_interrupt_allowed -> nested_vmx_vmexit 2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit Then to load_vmcs12_host_state and kvm_mmu_reset_context. Check for this possibility, let fault exception be regenerated. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916 Signed-off-by: Marcelo Tosatti Signed-off-by: Paolo Bonzini Cc: Josh Boyer Signed-off-by: Jiri Slaby commit 1743fc6cc6a54a4fac440ce885752cee819ed25a Author: Hans de Goede Date: Mon Dec 16 07:09:25 2013 -0800 Input: elantech - improve clickpad detection commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream. The current assumption in the elantech driver that hw version 3 touchpads are never clickpads and hw version 4 touchpads are always clickpads is wrong. There are several bug reports for this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1030802 http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux I've spend a couple of hours wading through various bugzillas, launchpads and forum posts to create a list of fw-versions and capabilities for different laptop models to find a good method to differentiate between clickpads and versions with separate hardware buttons. Which shows that a device being a clickpad is reliable indicated by bit 12 being set in the fw_version. I've included the gathered list inside the driver, so that we've this info at hand if we need to revisit this later. Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Cc: Josh Boyer Signed-off-by: Jiri Slaby commit 6d05cdce4fb86af309b91cc1e055e995f79c9a72 Author: Dave Jones Date: Thu Jan 23 15:55:43 2014 -0800 fs/proc/proc_devtree.c: remove empty /proc/device-tree when no openfirmware exists. commit c1d867a54d426b45da017fbe8e585f8a3064ce8d upstream. Distribution kernels might want to build in support for /proc/device-tree for kernels that might end up running on hardware that doesn't support openfirmware. This results in an empty /proc/device-tree existing. Remove it if the OFW root node doesn't exist. This situation actually confuses grub2, resulting in install failures. grub2 sees the /proc/device-tree and picks the wrong install target cf. http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/4300/util/grub-install.in#L311 grub should be more robust, but still, leaving an empty proc dir seems pointless. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=818378. Signed-off-by: Dave Jones Cc: Al Viro Cc: Paul Mackerras Cc: Josh Boyer Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 20a9e39efdd640c57aa348d53a149ff0692e842a Author: Gavin Shan Date: Wed Jan 15 13:16:11 2014 +0800 powerpc/eeh: Handle multiple EEH errors commit 7e4e7867b1e551b7b8f326da3604c47332972bc6 upstream. For one PCI error relevant OPAL event, we possibly have multiple EEH errors for that. For example, multiple frozen PEs detected on different PHBs. Unfortunately, we didn't cover the case. The patch enumarates the return value from eeh_ops::next_error() and change eeh_handle_special_event() and eeh_ops::next_error() to handle all existing EEH errors. As Ben pointed out, we needn't list_for_each_entry_safe() since we are not deleting any PHB from the hose_list and the EEH serialized lock should be held while purging EEH events. The patch covers those suggestions as well. Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 8ebdd122d3a30463bf10ea8120939d2f69b1608a Author: Markus Pargmann Date: Thu Feb 20 17:36:04 2014 +0100 regulator: core: Replace direct ops->disable usage commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by: Markus Pargmann Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit f615b037e16b61fb9358fdd94dec9728b8df90d8 Author: Dan Carpenter Date: Mon Jan 13 22:05:23 2014 +0300 p54: clamp properly instead of just truncating commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156eef1d ('p54: improve site survey') Signed-off-by: Dan Carpenter Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 7eb5fad9a3e737438329d1d1a4b22fa3fbf240f2 Author: Ben Hutchings Date: Thu Dec 5 14:37:35 2013 +0000 deb-pkg: Fix cross-building linux-headers package commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream. builddeb generates a control file that says the linux-headers package can only be built for the build system primary architecture. This breaks cross-building configurations. We should use $debarch for this instead. Since $debarch is not yet set when generating the control file, set Architecture: any and use control file variables to fill in the description. Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg') Reported-and-tested-by: "Niew, Sh." Signed-off-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 363103b6944721b60cf28c3531fae5cd5e1edb98 Author: Ben Hutchings Date: Thu Dec 5 14:39:11 2013 +0000 deb-pkg: Fix building for MIPS big-endian or ARM OABI commit c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream. These commands will mysteriously fail: $ make ARCH=arm versatile_defconfig [...] $ make ARCH=arm deb-pkg [...] make[1]: *** [deb-pkg] Error 1 make: *** [deb-pkg] Error 2 The Debian architecture selection for these kernel architectures does 'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this aborts the script if grep does not find the given config symbol. Fixes: 10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE') Signed-off-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 20c5552a8a399d0b4296d68d5759896d85f46acb Author: Linus Torvalds Date: Mon Feb 17 12:24:45 2014 -0800 printk: fix syslog() overflowing user buffer commit e4178d809fdaee32a56833fff1f5056c99e90a1a upstream. This is not a buffer overflow in the traditional sense: we don't overflow any *kernel* buffers, but we do mis-count the amount of data we copy back to user space for the SYSLOG_ACTION_READ_ALL case. In particular, if the user buffer is too small to hold everything, and *if* there is a continuation line at just the right place, we can end up giving the user more data than he asked for. The reason is that we first count up the number of bytes all the log records contains, then we walk the records again until we've skipped the records at the beginning that won't fit, and then we walk the rest of the records and copy them to the user space buffer. And in between that "skip the initial records that won't fit" and the "copy the records that *will* fit to user space", we reset the 'prev' variable that contained the record information for the last record not copied. That meant that when we started copying to user space, we now had a different character count than what we had originally calculated in the first record walk-through. The fix is to simply not clear the 'prev' flags value (in both cases where we had the same logic: syslog_print_all and kmsg_dump_get_buffer: the latter is used for pstore-like dumping) Reported-and-tested-by: Debabrata Banerjee Acked-by: Kay Sievers Cc: Jeff Mahoney Signed-off-by: Linus Torvalds Cc: Josh Hunt Signed-off-by: Jiri Slaby commit 03961b13eea339809447597c9222a87a3ee0d059 Author: Alexei Starovoitov Date: Mon Mar 10 15:56:51 2014 -0700 x86: bpf_jit: support negative offsets commit fdfaf64e75397567257e1051931f9a3377360665 upstream. Commit a998d4342337 claimed to introduce negative offset support to x86 jit, but it couldn't be working, since at the time of the execution of LD+ABS or LD+IND instructions via call into bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func) had junk value instead of access size in bytes (1 or 2 or 4). Store size into %edx instead of %ecx (what original commit intended to do) Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets") Signed-off-by: Alexei Starovoitov Cc: Jan Seiffert Cc: Eric Dumazet Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e9fc4074f0325b19f31bd407eb70739d49cfaf6d Author: Ben Hutchings Date: Thu Jan 23 14:35:48 2014 +0000 sfc: Use the correct maximum TX DMA ring size for SFC9100 commit d9317aea16ecec7694271ef11fb7791a0f0d9cc5 upstream. As part of a workaround for a hardware erratum in the SFC9100 family (SF bug 35388), the TX_DESC_UPD_DWORD register address is also used for communicating with the event block, and only descriptor pointer values < 2048 are valid. If the TX DMA ring size is increased to 4096 descriptors (which the firmware still allows) then we may write a descriptor pointer value >= 2048, which has entirely different and undesirable effects! Limit the TX DMA ring size correctly when this workaround is in effect. Fixes: 8127d661e77f ('sfc: Add support for Solarflare SFC9100 family') Signed-off-by: Ben Hutchings Signed-off-by: Shradha Shah Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9c831038cc7e6d2bc48034a6e8e328ed71cb7270 Author: Stephen Warren Date: Thu Feb 13 16:54:24 2014 -0700 ASoC: max98090: make REVISION_ID readable commit e126a646f77fdd66978785cb0a3a5e46b07aee2e upstream. The REVISION_ID register is not currently marked readable. snd_soc_read() refuses to read the register, and hence probe() fails. Fixes: d4807ad2c4c0 ("regmap: Check readable regs in _regmap_read") [exposed the bug, by checking for readability] Fixes: 685e42154dcf ("ASoC: Replace max98090 Device Driver") [left out this register from the readable list] Signed-off-by: Stephen Warren Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit fcd6ba0f80c3b3fcad379e622a97477ae7065a71 Author: Josh Durgin Date: Tue Dec 10 09:35:13 2013 -0800 libceph: resend all writes after the osdmap loses the full flag commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream. With the current full handling, there is a race between osds and clients getting the first map marked full. If the osd wins, it will return -ENOSPC to any writes, but the client may already have writes in flight. This results in the client getting the error and propagating it up the stack. For rbd, the block layer turns this into EIO, which can cause corruption in filesystems above it. To avoid this race, osds are being changed to drop writes that came from clients with an osdmap older than the last osdmap marked full. In order for this to work, clients must resend all writes after they encounter a full -> not full transition in the osdmap. osds will wait for an updated map instead of processing a request from a client with a newer map, so resent writes will not be dropped by the osd unless there is another not full -> full transition. This approach requires both osds and clients to be fixed to avoid the race. Old clients talking to osds with this fix may hang instead of returning EIO and potentially corrupting an fs. New clients talking to old osds have the same behavior as before if they encounter this race. Fixes: http://tracker.ceph.com/issues/6938 Reviewed-by: Sage Weil Signed-off-by: Josh Durgin Signed-off-by: Jiri Slaby commit 7388cfc1876b7caf0747d6864b74e7bef59a4ad2 Author: Josh Durgin Date: Mon Dec 2 19:11:48 2013 -0800 libceph: block I/O when PAUSE or FULL osd map flags are set commit d29adb34a94715174c88ca93e8aba955850c9bde upstream. The PAUSEWR and PAUSERD flags are meant to stop the cluster from processing writes and reads, respectively. The FULL flag is set when the cluster determines that it is out of space, and will no longer process writes. PAUSEWR and PAUSERD are purely client-side settings already implemented in userspace clients. The osd does nothing special with these flags. When the FULL flag is set, however, the osd responds to all writes with -ENOSPC. For cephfs, this makes sense, but for rbd the block layer translates this into EIO. If a cluster goes from full to non-full quickly, a filesystem on top of rbd will not behave well, since some writes succeed while others get EIO. Fix this by blocking any writes when the FULL flag is set in the osd client. This is the same strategy used by userspace, so apply it by default. A follow-on patch makes this configurable. __map_request() is called to re-target osd requests in case the available osds changed. Add a paused field to a ceph_osd_request, and set it whenever an appropriate osd map flag is set. Avoid queueing paused requests in __map_request(), but force them to be resent if they become unpaused. Also subscribe to the next osd map from the monitor if any of these flags are set, so paused requests can be unblocked as soon as possible. Fixes: http://tracker.ceph.com/issues/6079 Reviewed-by: Sage Weil Signed-off-by: Josh Durgin Signed-off-by: Jiri Slaby commit d5ce3633797811aa7274d49cc13aff4d1665b22e Author: Dan Carpenter Date: Fri Nov 22 04:51:47 2013 -0300 media: cx18: check for allocation failure in cx18_read_eeprom() commit e351bf25fa373a3de0be2141b962c5c3c27006a2 upstream. It upsets static checkers when we don't check for allocation failure. I moved the memset() of "tv" earlier so we don't use uninitialized data on error. Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack') Signed-off-by: Dan Carpenter Acked-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 560febde5250115f1ac28fe21ee72790e09e42d9 Author: Dan Carpenter Date: Fri Nov 22 04:56:33 2013 -0300 media: dw2102: some missing unlocks on error commit 324ed533bf0b23c309b805272c4ffcc5d51493a6 upstream. We recently introduced some new error paths but the unlocks are missing. Fixes: 0065a79a8698 ('[media] dw2102: Don't use dynamic static allocation') Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit fc3200dcb5db366c4acb031b644fdd6b1c37f392 Author: Dan Carpenter Date: Fri Nov 22 04:55:43 2013 -0300 media: cxusb: unlock on error in cxusb_i2c_xfer() commit 1cdbcc5db4e6d51ce9bb1313195167cada9aa6e9 upstream. We recently introduced some new error paths which are missing their unlocks. Fixes: 64f7ef8afbf8 ('[media] cxusb: Don't use dynamic static allocation') Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 1fd2acab4c32240c1df5dad22d907f68f9db15b2 Author: Christian Riesch Date: Mon Mar 24 13:46:26 2014 +0100 net: davinci_emac: Replace devm_request_irq with request_irq commit 33b7107f59a61236d94ecd6b45e20283cd5abcc8 upstream. In commit 6892b41d9701283085b655c6086fb57a5d63fa47 Author: Lad, Prabhakar Date: Tue Jun 25 21:24:51 2013 +0530 net: davinci: emac: Convert to devm_* api the call of request_irq is replaced by devm_request_irq and the call of free_irq is removed. But since interrupts are requested in emac_dev_open, doing ifconfig up/down on the board requests the interrupts again each time, causing devm_request_irq to fail. The interface is dead until the device is rebooted. This patch reverts said commit partially: It changes the driver back to use request_irq instead of devm_request_irq, puts free_irq back in place, but keeps the remaining changes of the original patch. Reported-by: Jon Ringle Signed-off-by: Christian Riesch Cc: Lad, Prabhakar Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c0316f975b1a29a1161f86d524150f493188e9b2 Author: Vaibhav Nagarnaik Date: Thu Feb 13 19:51:48 2014 -0800 tracing: Fix array size mismatch in format string commit 87291347c49dc40aa339f587b209618201c2e527 upstream. In event format strings, the array size is reported in two locations. One in array subscript and then via the "size:" attribute. The values reported there have a mismatch. For e.g., in sched:sched_switch the prev_comm and next_comm character arrays have subscript values as [32] where as the actual field size is 16. name: sched_switch ID: 301 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1;signed:0; field:int common_pid; offset:4; size:4; signed:1; field:char prev_comm[32]; offset:8; size:16; signed:1; field:pid_t prev_pid; offset:24; size:4; signed:1; field:int prev_prio; offset:28; size:4; signed:1; field:long prev_state; offset:32; size:8; signed:1; field:char next_comm[32]; offset:40; size:16; signed:1; field:pid_t next_pid; offset:56; size:4; signed:1; field:int next_prio; offset:60; size:4; signed:1; After bisection, the following commit was blamed: 92edca0 tracing: Use direct field, type and system names This commit removes the duplication of strings for field->name and field->type assuming that all the strings passed in __trace_define_field() are immutable. This is not true for arrays, where the type string is created in event_storage variable and field->type for all array fields points to event_storage. Use __stringify() to create a string constant for the type string. Also, get rid of event_storage and event_storage_mutex that are not needed anymore. also, an added benefit is that this reduces the overhead of events a bit more: text data bss dec hex filename 8424787 2036472 1302528 11763787 b3804b vmlinux 8420814 2036408 1302528 11759750 b37086 vmlinux.patched Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com Cc: Laurent Chavey Signed-off-by: Vaibhav Nagarnaik Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit bf7cda9a0101c4a149aa5846306df9d21dd5cc2b Author: Chris Wilson Date: Tue Mar 18 14:50:50 2014 +0200 drm/i915: Disable stolen memory when DMAR is active commit 0f4706d2740f2a221cd502922b22e522009041d9 upstream. We have reports of heavy screen corruption if we try to use the stolen memory reserved by the BIOS whilst the DMA-Remapper is active. This quirk may be only specific to a few machines or BIOSes, but first lets apply the big hammer and always disable use of stolen memory when DMAR is active. v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit 07a2f05ccb2b392a0360653eb6f9d32906e2d516 Author: Stefan Agner Date: Wed Mar 5 23:11:08 2014 +0100 clocksource: vf_pit_timer: use complement for sched_clock reading commit 224aa3ed45c8735ae02bb2ecca002409fa6aa772 upstream. Vybrids PIT register is monitonic decreasing. However, sched_clock reading needs to be monitonic increasing. Use bitwise not to get the complement of the clock register. This fixes the clock going backward. Also, the clock now starts at 0 since we load the register with the maximum value at start. Signed-off-by: Stefan Agner Acked-by: Shawn Guo Cc: daniel.lezcano@linaro.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux@arm.linux.org.uk Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit aaaf6019ec191283b55b257deacc4c62ed9b26fb Author: Charles Keepax Date: Wed Mar 19 12:59:39 2014 +0000 ALSA: compress: Pass through return value of open ops callback commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream. The snd_compr_open function would always return 0 even if the compressed ops open function failed, obviously this is incorrect. Looks like this was introduced by a small typo in: commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85 ALSA: Add a reference counter to card instance This patch returns the value from the compressed op as it should. Signed-off-by: Charles Keepax Acked-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 49ae3ce036a7bbaad86c36b1f8b1cfabe005cd05 Author: Fernando Luis Vazquez Cao Date: Wed Feb 26 16:51:24 2014 +0900 HID: hidraw: fix warning destroying hidraw device files after parent commit 47587fc098451c2100dc1fb618855fc2e2d937af upstream. I noticed that after hot unplugging a Logitech unifying receiver (drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a stack trace similar to this: usb 1-1.1.2: USB disconnect, device number 7 WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0() sysfs group ffffffff8187fa20 not found for kobject 'hidraw0' [...] CPU: 0 PID: 2865 Comm: upowerd Tainted: G W 3.14.0-rc4 #7 Hardware name: LENOVO 7783PN4/ , BIOS 9HKT43AUS 07/11/2011 0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7 ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8 ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028 Call Trace: [] ? dump_stack+0x41/0x51 [] ? warn_slowpath_common+0x77/0x90 [] ? warn_slowpath_fmt+0x4c/0x50 [] ? device_del+0x40/0x1b0 [] ? device_unregister+0x2f/0x50 [] ? device_destroy+0x3a/0x40 [] ? drop_ref+0x55/0x120 [hid] [] ? hidraw_release+0x96/0xb0 [hid] [] ? __fput+0xca/0x210 [] ? task_work_run+0x97/0xd0 [] ? do_notify_resume+0x69/0xa0 [] ? int_signal+0x12/0x17 ---[ end trace 63f4a46f6566d737 ]--- During device removal hid_disconnect() is called via hid_hw_stop() to stop the device and free all its resources, including the sysfs files. The problem is that if a user space process, such as upowerd, holds a reference to a hidraw file the corresponding sysfs files will be kept around (drop_ref() does not call device_destroy() if the open counter is not 0) and it will be usb_disconnect() who, by calling device_del() for the USB device, will indirectly remove the sysfs files of the hidraw device (sysfs_remove_dir() is recursive these days). Because of this, by the time user space releases the last reference to the hidraw file and drop_ref() tries to destroy the device the sysfs files are already gone and the kernel will print the warning above. Fix this by calling device_destroy() at USB disconnect time. Signed-off-by: Fernando Luis Vazquez Cao Reviewed-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit 304dfba651cecbac257ecfef9b12779f0e98ff2a Author: Stephen Warren Date: Tue Feb 18 16:51:58 2014 -0700 ARM: tegra: only run PL310 init on systems with one commit 8859685785bfafadf9bc922dd3a2278e59886947 upstream. Fix tegra_init_cache() to check whether the system has a PL310 cache before touching the PL310 registers. This prevents access to non-existent registers on Tegra114 and later. Note for stable kernels: In <= v3.12, the file to patch is arch/arm/mach-tegra/common.c. Signed-off-by: Stephen Warren Signed-off-by: Olof Johansson Signed-off-by: Jiri Slaby commit dffdacf81b8705d6d1a43ccb9fdf60da750f75f9 Author: Catalin Marinas Date: Fri Nov 29 10:56:14 2013 +0000 arm64: Use Normal NonCacheable memory for writecombine commit 4f00130b70e5eee813cc7bc298e0f3fdf79673cc upstream. This provides better performance compared to Device GRE and also allows unaligned accesses. Such memory is intended to be used with standard RAM (e.g. framebuffers) and not I/O. Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 8c992df26ee88eb93c39c1ce187c9003a997001e Author: Catalin Marinas Date: Thu Nov 14 15:15:37 2013 +0000 arm64: dts: Reserve the memory used for secondary CPU release address commit df503ba7f653c590b475ab80bde788edf5af70d5 upstream. With the spin-table SMP booting method, secondary CPUs poll a location passed in the DT. The foundation-v8.dts file doesn't have this memory reserved and there is a risk of Linux using it before secondary CPUs are started. Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 9dd6503025b97a699c92da785eff35d66eb7358a Author: Simon Wood Date: Wed Nov 6 12:30:43 2013 -0700 HID:hid-lg4ff: Initialize device properties before we touch autocentering. commit 114a55cf9dd1576e7ac56189832cd4d7dc56c218 upstream. Re-arrange code slightly to ensure that device properties are configured before calling auto-center command. Reported-by: Michal Malý Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit a6bbc17f7d8d495f66556a550b69beddbd1aa438 Author: Heiko Carstens Date: Thu Oct 31 13:24:28 2013 +0100 s390/dasd: hold request queue sysfs lock when calling elevator_init() commit ef0899410ff630b2e75306da49996dbbfa318165 upstream. "elevator: Fix a race in elevator switching and md device initialization" changed the semantics of elevator_init() in a way that now enforces to hold the corresponding request queue's sysfs_lock when calling elevator_init() to fix a race. The patch did not convert the s390 dasd device driver which is the only device driver which also calls elevator_init(). So add the missing locking. Cc: Tomoki Sekiyama Cc: Jens Axboe Signed-off-by: Heiko Carstens Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit e35c7079f86c08cf6808f9cd3bcc5f6e944318f3 Author: AKASHI Takahiro Date: Thu Oct 3 06:47:44 2013 +0100 arm64: check for number of arguments in syscall_get/set_arguments() commit 7b22c03536a539142f931815528d55df455ffe2d upstream. In ftrace_syscall_enter(), syscall_get_arguments(..., 0, n, ...) if (i == 0) { ...; n--;} memcpy(..., n * sizeof(args[0])); If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in syscall_get_arguments(), none of arguments should be copied by memcpy(). Otherwise 'n--' can be a big positive number and unexpected amount of data will be copied. Tracing system calls which take no argument, say sync(void), may hit this case and eventually make the system corrupted. This patch fixes the issue both in syscall_get_arguments() and syscall_set_arguments(). Signed-off-by: AKASHI Takahiro Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit fb5277ee5110caec1e8483b8f092e4a7de94d65c Author: Jiri Slaby Date: Thu Mar 27 09:52:01 2014 +0100 iscsi/iser-target: fix build warning With upstream commit defd884845297fd5690594bfe89656b01f16d87e, 3.12 commit 2f82fa987df6b060241fc760eadf5dd02c51a979, we introduced a warning: drivers/infiniband/ulp/isert/ib_isert.c: In function 'isert_cq_rx_comp_err': drivers/infiniband/ulp/isert/ib_isert.c:##L##: warning: unused variable 'ib_dev' [-Wunused-variable] Remove ib_dev as it is unused. Signed-off-by: Jiri Slaby Cc: Sagi Grimberg Cc: Or Gerlitz Cc: Nicholas Bellinger commit e86b14ce46d56f6f84ccacec45466d9b18bef1c2 Author: Mengdong Lin Date: Wed Jan 8 15:55:32 2014 -0500 ALSA: hda/hdmi - apply all Haswell fix-ups to Broadwell display codec commit 75dcbe4dc251ebc28cdf0797b85774cdf53a4d29 upstream. Broadwell and Haswell have the same behavior on display audio. So this patch defines is_haswell_plus() to include codecs for both Haswell and its successor Broadwell, and apply all Haswell fix-ups to Broadwell. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit a628ce56b7f1018764a0315339e2116bca965ffc Author: Mengdong Lin Date: Wed Jan 8 15:55:24 2014 -0500 ALSA: hda - add codec ID for Broadwell display audio codec commit 3adadd280a5a78efabdec394c1e745a3f5a1cc18 upstream. This patch adds codec ID (0x80862808) and module alias for Broadwell display codec. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 5de87726a1c396bc04dfaa65316e1d5eb7827561 Author: Mengdong Lin Date: Wed Jan 8 15:55:14 2014 -0500 ALSA: hda - add device ID for Broadwell display audio controller commit 862d761818ba2cb785a0a57557f97a43bd1bc922 upstream. This patch adds the device ID for Intel Broadwell display HD-Audio controller, and applies Haswell properties to this device. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit ad727c5a26d6a7833471ffe06be55d296f8ce7d9 Author: Anton Blanchard Date: Wed Mar 26 11:25:37 2014 +0100 ibmveth: Fix endian issues with MAC addresses commit d746ca9561440685edb62614d1bcbbc27ff50e66 upstream. The code to load a MAC address into a u64 for passing to the hypervisor via a register is broken on little endian. Create a helper function called ibmveth_encode_mac_addr which does the right thing in both big and little endian. We were storing the MAC address in a long in struct ibmveth_adapter. It's never used so remove it - we don't need another place in the driver where we create endian issues with MAC addresses. Signed-off-by: Anton Blanchard Signed-off-by: David S. Miller Acked-by: Torsten Duwe Signed-off-by: Jiri Slaby commit 59d9c5f94655a3cc63e2772e847509010598b7f1 Author: Li Zefan Date: Tue Feb 11 16:05:46 2014 +0800 cgroup: protect modifications to cgroup_idr with cgroup_mutex commit 0ab02ca8f887908152d1a96db5130fc661d36a1e upstream. Setup cgroupfs like this: # mount -t cgroup -o cpuacct xxx /cgroup # mkdir /cgroup/sub1 # mkdir /cgroup/sub2 Then run these two commands: # for ((; ;)) { mkdir /cgroup/sub1/tmp && rmdir /mnt/sub1/tmp; } & # for ((; ;)) { mkdir /cgroup/sub2/tmp && rmdir /mnt/sub2/tmp; } & After seconds you may see this warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 25243 at lib/idr.c:527 sub_remove+0x87/0x1b0() idr_remove called for id=6 which is not allocated. ... Call Trace: [] dump_stack+0x7a/0x96 [] warn_slowpath_common+0x8c/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] sub_remove+0x87/0x1b0 [] ? css_killed_work_fn+0x32/0x1b0 [] idr_remove+0x25/0xd0 [] cgroup_destroy_css_killed+0x5b/0xc0 [] css_killed_work_fn+0x130/0x1b0 [] process_one_work+0x26c/0x550 [] worker_thread+0x12e/0x3b0 [] kthread+0xe6/0xf0 [] ret_from_fork+0x7c/0xb0 ---[ end trace 2d1577ec10cf80d0 ]--- It's because allocating/removing cgroup ID is not properly synchronized. The bug was introduced when we converted cgroup_ida to cgroup_idr. While synchronization is already done inside ida_simple_{get,remove}(), users are responsible for concurrent calls to idr_{alloc,remove}(). [mhocko@suse.cz: ported to 3.12] Fixes: 4e96ee8e981b ("cgroup: convert cgroup_ida to cgroup_idr") Cc: #3.12+ Reported-by: Michal Hocko Signed-off-by: Li Zefan Signed-off-by: Michal Hocko Signed-off-by: Jiri Slaby commit 293639e5b70e7c19b36bf1504d09dac574b30895 Author: Russell King Date: Sat Jan 11 11:22:18 2014 +0000 ARM: ignore memory below PHYS_OFFSET commit 571b14375019c3a66ef70d4d4a7083f4238aca30 upstream. If the kernel is loaded higher in physical memory than normal, and we calculate PHYS_OFFSET higher than the start of RAM, this leads to boot problems as we attempt to map part of this RAM into userspace. Rather than struggle with this, just truncate the mapping. Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 1e9a0925a3e8dc5705eb386cde8b7033d4fbc518 Author: Magnus Damm Date: Tue Oct 22 17:59:54 2013 +0100 ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t commit 6d7d5da7d75c6df676c8b72d32b02ff024438f0c upstream. Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine if ignoring or truncating of memory banks is neccessary. This may be needed in the case of 64-bit memory bank addresses but when phys_addr_t is kept 32-bit. Signed-off-by: Magnus Damm Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit dec2e6e6bd7cc728a9b3091075dd17aef6b4c33c Author: Trond Myklebust Date: Sat Mar 22 10:00:50 2014 -0400 NFSv4: Fix another nfs4_sequence corruptor commit b7e63a1079b266866a732cf699d8c4d61391bbda upstream. nfs4_release_lockowner needs to set the rpc_message reply to point to the nfs4_sequence_res in order to avoid another Oopsable situation in nfs41_assign_slot. Fixes: fbd4bfd1d9d21 (NFS: Add nfs4_sequence calls for RELEASE_LOCKOWNER) Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit bda870334924cbb6daa011713adfe65a24730e68 Author: Christoffer Dall Date: Mon Mar 24 21:40:06 2014 -0700 ARM: 7950/1: mm: Fix stage-2 device memory attributes commit 4d9c5b89cf3605bbc39c6e274351ff25f0d83e6a upstream. The stage-2 memory attributes are distinct from the Hyp memory attributes and the Stage-1 memory attributes. We were using the stage-1 memory attributes for stage-2 mappings causing device mappings to be mapped as normal memory. Add the S2 equivalent defines for memory attributes and fix the comments explaining the defines while at it. Add a prot_pte_s2 field to the mem_type struct and fill out the field for device mappings accordingly. Cc: [3.12] Acked-by: Marc Zyngier Acked-by: Catalin Marinas Signed-off-by: Christoffer Dall Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 3d316682dc951d54ac0c9927968fdfe372d47c37 Author: Emmanuel Grumbach Date: Sat Mar 22 21:35:43 2014 +0200 iwlwifi: mvm: don't WARN when statistics are handled late commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream. Since the statistics handler is asynchrous, it can very well be that we will handle the statistics (hence the RSSI fluctuation) when we already disassociated. Don't WARN on this case. This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998 Cc: [3.10+] Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power") Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Jiri Slaby