commit 13c24cc86702e823152cfaa8fd42adfc6bca182f Author: Greg Kroah-Hartman Date: Thu Oct 9 12:24:04 2014 -0700 Linux 3.16.5 commit 79d627d4cd0f2823115f70843c16709ba2869611 Author: Andrew Hunter Date: Thu Sep 4 14:17:16 2014 -0700 jiffies: Fix timeval conversion to jiffies commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream. timeval_to_jiffies tried to round a timeval up to an integral number of jiffies, but the logic for doing so was incorrect: intervals corresponding to exactly N jiffies would become N+1. This manifested itself particularly repeatedly stopping/starting an itimer: setitimer(ITIMER_PROF, &val, NULL); setitimer(ITIMER_PROF, NULL, &val); would add a full tick to val, _even if it was exactly representable in terms of jiffies_ (say, the result of a previous rounding.) Doing this repeatedly would cause unbounded growth in val. So fix the math. Here's what was wrong with the conversion: we essentially computed (eliding seconds) jiffies = usec * (NSEC_PER_USEC/TICK_NSEC) by using scaling arithmetic, which took the best approximation of NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC = x/(2^USEC_JIFFIE_SC), and computed: jiffies = (usec * x) >> USEC_JIFFIE_SC and rounded this calculation up in the intermediate form (since we can't necessarily exactly represent TICK_NSEC in usec.) But the scaling arithmetic is a (very slight) *over*approximation of the true value; that is, instead of dividing by (1 usec/ 1 jiffie), we effectively divided by (1 usec/1 jiffie)-epsilon (rounding down). This would normally be fine, but we want to round timeouts up, and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this would be fine if our division was exact, but dividing this by the slightly smaller factor was equivalent to adding just _over_ 1 to the final result (instead of just _under_ 1, as desired.) In particular, with HZ=1000, we consistently computed that 10000 usec was 11 jiffies; the same was true for any exact multiple of TICK_NSEC. We could possibly still round in the intermediate form, adding something less than 2^USEC_JIFFIE_SC - 1, but easier still is to convert usec->nsec, round in nanoseconds, and then convert using time*spec*_to_jiffies. This adds one constant multiplication, and is not observably slower in microbenchmarks on recent x86 hardware. Tested: the following program: int main() { struct itimerval zero = {{0, 0}, {0, 0}}; /* Initially set to 10 ms. */ struct itimerval initial = zero; initial.it_interval.tv_usec = 10000; setitimer(ITIMER_PROF, &initial, NULL); /* Save and restore several times. */ for (size_t i = 0; i < 10; ++i) { struct itimerval prev; setitimer(ITIMER_PROF, &zero, &prev); /* on old kernels, this goes up by TICK_USEC every iteration */ printf("previous value: %ld %ld %ld %ld\n", prev.it_interval.tv_sec, prev.it_interval.tv_usec, prev.it_value.tv_sec, prev.it_value.tv_usec); setitimer(ITIMER_PROF, &prev, NULL); } return 0; } Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Paul Turner Cc: Richard Cochran Cc: Prarit Bhargava Reviewed-by: Paul Turner Reported-by: Aaron Jacobs Signed-off-by: Andrew Hunter [jstultz: Tweaked to apply to 3.17-rc] Signed-off-by: John Stultz [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 1c1e2cc7f5140a38ffbe2d3ffd037c09969c4860 Author: Hans Verkuil Date: Sat Sep 20 16:16:35 2014 -0300 media: vb2: fix VBI/poll regression commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream. The recent conversion of saa7134 to vb2 unconvered a poll() bug that broke the teletext applications alevt and mtt. These applications expect that calling poll() without having called VIDIOC_STREAMON will cause poll() to return POLLERR. That did not happen in vb2. This patch fixes that behavior. It also fixes what should happen when poll() is called when STREAMON is called but no buffers have been queued. In that case poll() will also return POLLERR, but only for capture queues since output queues will always return POLLOUT anyway in that situation. This brings the vb2 behavior in line with the old videobuf behavior. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 106aad139eee0af5dabedbb15e56e602515c504c Author: Mel Gorman Date: Thu Oct 2 19:47:42 2014 +0100 mm: numa: Do not mark PTEs pte_numa when splitting huge pages commit abc40bd2eeb77eb7c2effcaf63154aad929a1d5f upstream. This patch reverts 1ba6e0b50b ("mm: numa: split_huge_page: transfer the NUMA type from the pmd to the pte"). If a huge page is being split due a protection change and the tail will be in a PROT_NONE vma then NUMA hinting PTEs are temporarily created in the protected VMA. VM_RW|VM_PROTNONE |-----------------| ^ split here In the specific case above, it should get fixed up by change_pte_range() but there is a window of opportunity for weirdness to happen. Similarly, if a huge page is shrunk and split during a protection update but before pmd_numa is cleared then a pte_numa can be left behind. Instead of adding complexity trying to deal with the case, this patch will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults will not be triggered which is marginal in comparison to the complexity in dealing with the corner cases during THP split. Signed-off-by: Mel Gorman Acked-by: Rik van Riel Acked-by: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c16f6baf8c349db712528a370f9f0521844cb3cd Author: Waiman Long Date: Wed Aug 6 16:05:36 2014 -0700 mm, thp: move invariant bug check out of loop in __split_huge_page_map commit f8303c2582b889351e261ff18c4d8eb197a77db2 upstream. In __split_huge_page_map(), the check for page_mapcount(page) is invariant within the for loop. Because of the fact that the macro is implemented using atomic_read(), the redundant check cannot be optimized away by the compiler leading to unnecessary read to the page structure. This patch moves the invariant bug check out of the loop so that it will be done only once. On a 3.16-rc1 based kernel, the execution time of a microbenchmark that broke up 1000 transparent huge pages using munmap() had an execution time of 38,245us and 38,548us with and without the patch respectively. The performance gain is about 1%. Signed-off-by: Waiman Long Acked-by: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: Mel Gorman Cc: Rik van Riel Cc: Scott J Norton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce027dac592c0ada241ce0f95ae65856828ac450 Author: Bruno Prémont Date: Sun Aug 24 23:09:53 2014 +0200 vgaarb: Don't default exclusively to first video device with mem+io commit 86fd887b7fe350819dae5b55e7fef05b511c8656 upstream. Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()") moved boot video device detection from efifb to x86 and ia64 pci/fixup.c. For dual-GPU Apple computers above change represents a regression as code in efifb did forcefully override vga_default_device while the merge did not (vgaarb happens prior to PCI fixup). To improve on initial device selection by vgaarb (it cannot know if PCI device not behind bridges see/decode legacy VGA I/O or not), move the screen_info based check from pci_video_fixup() to vgaarb's init function and use it to refine/override decision taken while adding the individual PCI VGA devices. This way PCI fixup has no reason to adjust vga_default_device anymore but can depend on its value for flagging shadowed VBIOS. This has the nice benefit of removing duplicated code but does introduce a #if defined() block in vgaarb. Not all architectures have screen_info and would cause compile to fail without it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461 Reported-and-Tested-By: Andreas Noever Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas CC: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 7babfd7f066dae02c63d9ccac886419ccfb80cfd Author: Bruno Prémont Date: Wed Jun 25 00:55:01 2014 +0200 x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() commit 20cde694027e7477cc532833e38ab9fcaa83fb64 upstream. Commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") added efifb vga_default_device() so EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such as MacBookAir2,1. Xorg detects the GPU and finds the DRI device but then bails out with "no devices detected". Note: When vga_default_device() is set boot_vga PCI sysfs attribute reflects its state. When unset this attribute is 1 whenever IORESOURCE_ROM_SHADOW flag is set. With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete while having native drivers for the GPU also makes selecting sysfb/efifb optional. Remove the efifb implementation of vga_default_device() and initialize vgaarb's vga_default_device() with the PCI GPU that matches boot screen_info in pci_fixup_video(). [bhelgaas: remove unused "dev" in efifb_setup()] Fixes: b4aa0163056b ("efifb: Implement vga_default_device() (v2)") Tested-by: Anibal Francisco Martinez Cortina Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas Acked-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit b3c565a153af057d5529b82d86116d8144205191 Author: Hans de Goede Date: Thu Sep 11 11:06:12 2014 +0200 uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check commit a79e5bc53a9519202dfad7d916761601fcbf8db1 upstream. Reported-by: kbuild test robot Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit d7d36249e4fc82eec2a81313d35e9f8ad2e77dd8 Author: Hans de Goede Date: Wed Sep 10 10:51:36 2014 +0200 uas: Disable uas on ASM1051 devices commit a9c54caa456dccba938005f6479892b589975e6a upstream. There are a large numbers of issues with ASM1051 devices in uas mode: 1) They do not support REPORT SUPPORTED OPERATION CODES 2) They use out of spec 8 byte status iu-s when they have no sense data, switching to normal 16 byte status iu-s when they do have sense data. 3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd. 4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks with which then normally do work (once 1 & 2 are worked around). Where as in BOT mode they appear to work fine, so the best way forward with these devices is to just blacklist them for uas usage. Unfortunately this is easier said then done. as older versions of the ASM1053 (which works fine) use the same usb-id as the ASM1051. When connected over USB-3 the 2 can be told apart by the number of streams they support. So this patch adds some less then pretty code to disable uas for the ASM1051. When connected over USB-2, simply disable uas alltogether for devices with the shared usb-id. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit d751f8815f9ada8fb6d0b3ca54fcde2a61b5b950 Author: Hans de Goede Date: Fri Jul 25 22:01:27 2014 +0200 uas: Log a warning when we cannot use uas because the hcd lacks streams commit 43508be512661c905d0320ee73e0b65ef36d2459 upstream. So that an user who wants to use uas can see why he is not getting uas. Also move the check down so that we don't warn if there are other reasons why uas cannot work. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit d9d4dc60d6a31906483d620a2ce0552f7a921df9 Author: Hans de Goede Date: Fri Jul 25 22:01:26 2014 +0200 uas: Only complain about missing sg if all other checks succeed commit cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 upstream. Don't complain about controllers without sg support if there are other reasons why uas cannot be used anyways. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 70e9e5208ea43056297763cb88866f9686cbf701 Author: Steven Rostedt (Red Hat) Date: Thu Oct 2 16:51:18 2014 -0400 ring-buffer: Fix infinite spin in reading buffer commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream. Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page" fixed one bug but in the process caused another one. The reset is to update the header page, but that fix also changed the way the cached reads were updated. The cache reads are used to test if an iterator needs to be updated or not. A ring buffer iterator, when created, disables writes to the ring buffer but does not stop other readers or consuming reads from happening. Although all readers are synchronized via a lock, they are only synchronized when in the ring buffer functions. Those functions may be called by any number of readers. The iterator continues down when its not interrupted by a consuming reader. If a consuming read occurs, the iterator starts from the beginning of the buffer. The way the iterator sees that a consuming read has happened since its last read is by checking the reader "cache". The cache holds the last counts of the read and the reader page itself. Commit 651e22f2701b changed what was saved by the cache_read when the rb_iter_reset() occurred, making the iterator never match the cache. Then if the iterator calls rb_iter_reset(), it will go into an infinite loop by checking if the cache doesn't match, doing the reset and retrying, just to see that the cache still doesn't match! Which should never happen as the reset is suppose to set the cache to the current value and there's locks that keep a consuming reader from having access to the data. Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f3b920a7e21d11d122eb2e6d247599e2547ce5ee Author: Josh Triplett Date: Fri Oct 3 16:19:24 2014 -0700 init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu commit 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f upstream. commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test") added the HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in the middle of the options for the EXPERT menu. However, HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops placing items in the EXPERT menu, and displays the remaining several EXPERT items (starting with EPOLL) directly in the General Setup menu. Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the subsequent items display as part of the EXPERT menu again; the EMBEDDED menu now appears as the next top-level item in the General Setup menu, which makes General Setup much shorter and more usable. Signed-off-by: Josh Triplett Acked-by: Randy Dunlap Signed-off-by: Greg Kroah-Hartman commit f173e28fd20f08e3896b6508421a9f7e0974c276 Author: Steve French Date: Thu Sep 25 01:26:55 2014 -0500 Fix problem recognizing symlinks commit 19e81573fca7b87ced7701e01ba164b968d929bd upstream. Changeset eb85d94bd introduced a problem where if a cifs open fails during query info of a file we will still try to close the file (happens with certain types of reparse points) even though the file handle is not valid. In addition for SMB2/SMB3 we were not mapping the return code returned by Windows when trying to open a file (like a Windows NFS symlink) which is a reparse point. Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 332cec01edeaf698e2fdf6fc9b57a15bdfed009d Author: Chris Wilson Date: Thu Sep 25 10:13:12 2014 +0100 drm/i915: Flush the PTEs after updating them before suspend commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream. As we use WC updates of the PTE, we are responsible for notifying the hardware when to flush its TLBs. Do so after we zap all the PTEs before suspend (and the BIOS tries to read our GTT). Fixes a regression from commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend that survived and continue to cause harm even after commit e568af1c626031925465a5caaab7cca1303d55c7 Author: Daniel Vetter Date: Wed Mar 26 20:08:20 2014 +0100 drm/i915: Undo gtt scratch pte unmapping again v2: Trivial rebase. v3: Fixes requires pointer dances. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 Tested-by: ming.yao@intel.com Signed-off-by: Chris Wilson Cc: Takashi Iwai Cc: Paulo Zanoni Cc: Todd Previte Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ede6b1e92d0c8787a1f56f2398c530c5965cbd8d Author: NeilBrown Date: Thu Oct 2 13:45:00 2014 +1000 md/raid5: disable 'DISCARD' by default due to safety concerns. commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream. It has come to my attention (thanks Martin) that 'discard_zeroes_data' is only a hint. Some devices in some cases don't do what it says on the label. The use of DISCARD in RAID5 depends on reads from discarded regions being predictably zero. If a write to a previously discarded region performs a read-modify-write cycle it assumes that the parity block was consistent with the data blocks. If all were zero, this would be the case. If some are and some aren't this would not be the case. This could lead to data corruption after a device failure when data needs to be reconstructed from the parity. As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y As this is a data-safety issue, I believe this patch is suitable for -stable. DISCARD support for RAID456 was added in 3.7 Cc: Shaohua Li Cc: "Martin K. Petersen" Cc: Mike Snitzer Cc: Heinz Mauelshagen Acked-by: Martin K. Petersen Acked-by: Mike Snitzer Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 9346dc9c64f7a4b712d3cc11092c69db479796b0 Author: Rafael J. Wysocki Date: Sat Sep 27 21:56:08 2014 +0200 cpufreq: pcc-cpufreq: Fix wait_event() under spinlock commit e65b5ddba84634f31d42dfd86013f4c6be5e9e32 upstream. Fix the following bug introduced by commit 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) that forgot to move the spin_lock() in pcc_cpufreq_target() past cpufreq_freq_transition_begin() which calls wait_event(): BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] [ 51.025044] CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7 Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00 Call Trace: [] dump_stack+0x4d/0x90 [] ___might_sleep+0x10f/0x180 [] __might_sleep+0x48/0xd0 [] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); [] ? preempt_count_add+0xb9/0xc0 [] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); [] ? update_ts_time_stats+0x7f/0xb0 [] __cpufreq_driver_target+0x85/0x170 [] od_check_cpu+0xa8/0xb0 [] dbs_check_cpu+0x180/0x1d0 [] cpufreq_governor_dbs+0x3b0/0x720 [] od_cpufreq_governor_dbs+0x33/0xe0 [] __cpufreq_governor+0xa9/0x210 [] cpufreq_set_policy+0x1e2/0x2e0 [] cpufreq_init_policy+0x8c/0x110 [] ? cpufreq_update_policy+0x1b0/0x1b0 [] ? preempt_count_sub+0xb9/0x100 [] __cpufreq_add_dev+0x596/0x6b0 [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [] cpufreq_add_dev+0xe/0x10 [] subsys_interface_register+0xc1/0xf0 [] ? preempt_count_sub+0xb9/0x100 [] cpufreq_register_driver+0x117/0x2a0 [] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [] do_one_initcall+0xc8/0x1f0 [] ? __vunmap+0x9d/0x100 [] do_init_module+0x30/0x1b0 [] load_module+0x686/0x710 [] ? do_init_module+0x1b0/0x1b0 [] SyS_init_module+0x9b/0xc0 [] system_call_fastpath+0x16/0x1b Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) Reported-and-tested-by: Mike Galbraith Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2c36e46476440f966bf652d68092cf29de515b5f Author: Arnd Bergmann Date: Fri Sep 26 22:19:12 2014 +0200 cpufreq: integrator: fix integrator_cpufreq_remove return type commit d62dbf77f7dfaa6fb455b4b9828069a11965929c upstream. When building this driver as a module, we get a helpful warning about the return type: drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type .remove = __exit_p(integrator_cpufreq_remove), If the remove callback returns void, the caller gets an undefined value as it expects an integer to be returned. This fixes the problem by passing down the value from cpufreq_unregister_driver. Signed-off-by: Arnd Bergmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8cc976514d47f6ff7e04634b71c3d82bf50fd97b Author: Aaron Lu Date: Fri Sep 26 10:30:08 2014 +0800 ACPI / i915: Update the condition to ignore firmware backlight change request commit 77076c7aac0184cae2d8a358cf6e6ed1f195fe3f upstream. Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár Signed-off-by: Aaron Lu Acked-by: Daniel Vetter Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 57ca8495860a669ceca5b1f535dafbf47264dfb1 Author: Alexandru M Stan Date: Wed Oct 1 10:40:41 2014 -0700 i2c: rk3x: fix 0 length write transfers commit cf27020d2f253bac6457d6833b97141030f0122a upstream. i2cdetect -q was broken (everything was a false positive, and no transfers were actually being sent over i2c). The way it works is by sending a 0 length write request and checking for NACK. This patch fixes the 0 length writes and actually sends them. Reported-by: Doug Anderson Signed-off-by: Alexandru M Stan Tested-by: Doug Anderson Tested-by: Max Schwarz Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 7f28469c12cdc4cdc7b278de5b4e367b550bb046 Author: Andy Gross Date: Mon Sep 29 17:00:51 2014 -0500 i2c: qup: Fix order of runtime pm initialization commit 86b59bbfae2a895aa26b3d15f31b1a705dbfede1 upstream. The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by: Andy Gross Reviewed-by: Felipe Balbi Acked-by: Bjorn Andersson Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit e9203e7b4019370e6d8f69cbf71c052aad22ced7 Author: Mel Gorman Date: Thu Oct 2 19:47:41 2014 +0100 mm: migrate: Close race between migration completion and mprotect commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream. A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Signed-off-by: Mel Gorman Acked-by: Rik van Riel Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a1130ef0b0b1f058d1f713063404a81bb96d6533 Author: Johannes Weiner Date: Thu Oct 2 16:16:57 2014 -0700 mm: memcontrol: do not iterate uninitialized memcgs commit 2f7dd7a4100ad4affcb141605bef178ab98ccb18 upstream. The cgroup iterators yield css objects that have not yet gone through css_online(), but they are not complete memcgs at this point and so the memcg iterators should not return them. Commit d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized") set out to implement exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does not meet the ordering requirements for memcg, and so the iterator may skip over initialized groups, or return partially initialized memcgs. The cgroup core can not reasonably provide a clear answer on whether the object around the css has been fully initialized, as that depends on controller-specific locking and lifetime rules. Thus, introduce a memcg-specific flag that is set after the memcg has been initialized in css_online(), and read before mem_cgroup_iter() callers access the memcg members. Signed-off-by: Johannes Weiner Cc: Tejun Heo Acked-by: Michal Hocko Cc: Hugh Dickins Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 54a9ae913f324df56734a57af9dea94f14362cf4 Author: Peter Zijlstra Date: Thu Oct 2 16:17:02 2014 -0700 perf: fix perf bug in fork() commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream. Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by: Oleg Nesterov Reported-by: Oleg Nesterov Reported-by: Sylvain 'ythier' Hitier Signed-off-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8f805204b5b0595140be2b33e2297d8ba1c7fc13 Author: Xiubo Li Date: Sun Sep 28 17:29:37 2014 +0800 ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error. commit 6596aa047b624aeec2ea321962cfdecf9953a383 upstream. Since we cannot make sure the 'params->num_regs' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by: Xiubo Li Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b744c01491f0b12ac47e8db28065975fc65a0e2 Author: Stefan Kristiansson Date: Mon Sep 29 22:39:13 2014 +0300 ASoC: ssm2602: do not hardcode type to SSM2602 commit fe2a08b3bf1a6e35c00e18843bc19aa1778432c3 upstream. The correct type (SSM2602/SSM2603/SSM2604) is passed down from the ssm2602_spi_probe()/ssm2602_spi_probe() functions, so use that instead of hardcoding it to SSM2602 in ssm2602_probe(). Fixes: c924dc68f737 ("ASoC: ssm2602: Split SPI and I2C code into different modules") Signed-off-by: Stefan Kristiansson Signed-off-by: Mark Brown Acked-by: Lars-Peter Clausen Signed-off-by: Greg Kroah-Hartman commit 7478bcf7d5594fba7a98b8fef615e8924caf7977 Author: Jan Kara Date: Thu Sep 4 14:06:55 2014 +0200 udf: Avoid infinite loop when processing indirect ICBs commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 upstream. We did not implement any bound on number of indirect ICBs we follow when loading inode. Thus corrupted medium could cause kernel to go into an infinite loop, possibly causing a stack overflow. Fix the possible stack overflow by removing recursion from __udf_read_inode() and limit number of indirect ICBs we follow to avoid infinite loops. Signed-off-by: Jan Kara Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman