commit 96e199f1751e707a7a8c04d9b079f84df2e0d4ff Author: Sasha Levin Date: Mon Mar 23 21:05:12 2015 -0400 Linux 3.18.10 Signed-off-by: Sasha Levin commit da7a05331943f70380ceb71a6e2d462d6196334c Author: Ian Munsie Date: Wed Feb 4 19:10:38 2015 +1100 cxl: Add missing return statement after handling AFU errror commit a6130ed253a931d2169c26ab0958d81b0dce4d6e upstream. We were missing a return statement in the PSL interrupt handler in the case of an AFU error, which would trigger an "Unhandled CXL PSL IRQ" warning. We do actually handle these type of errors (by notifying userspace), so add the missing return IRQ_HANDLED so we don't throw unecessary warnings. Signed-off-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 3bc64c1b582e4de917fbbdeaec199864ec8194af Author: Ryan Grimm Date: Wed Jan 28 20:16:04 2015 -0600 cxl: Fix device_node reference counting commit 6f963ec2d6bf2476a16799eece920acb2100ff1c upstream. When unbinding and rebinding the driver on a system with a card in PHB0, this error condition is reached after a few attempts: ERROR: Bad of_node_put() on /pciex@3fffe40000000 CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152 Call Trace: [c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable) [c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0 [c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0 [c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30 [c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50 [c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0 [c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170 [c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0 [c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160 [c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60 [c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0 [c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0 [c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260 [c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100 [c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98 We are missing a call to of_node_get(). pnv_pci_to_phb_node() should call of_node_get() otherwise np's reference count isn't incremented and it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node() so it's clear it calls of_node_get(). Signed-off-by: Ryan Grimm Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0153a8f025996a5d465717a8782c26d1ce09d254 Author: Ryan Grimm Date: Mon Jan 19 11:52:48 2015 -0600 cxl: Use image state defaults for reloading FPGA commit 4beb5421babee1204757b877622830c6aa31be6d upstream. Select defaults such that a PERST causes flash image reload. Select which image based on what the card is set up to load. CXL_VSEC_PERST_LOADS_IMAGE selects whether PERST assertion causes flash image load. CXL_VSEC_PERST_SELECT_USER selects which image is loaded on the next PERST. cxl_update_image_control writes these bits into the VSEC. Signed-off-by: Ryan Grimm Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 22374fc8ef69575e6d5ca79ba3f01d8472ff87e7 Author: Sergei Shtylyov Date: Wed Dec 24 17:43:27 2014 +0300 clk-gate: fix bit # check in clk_register_gate() commit 2e9dcdae4068460c45a308dd891be5248260251c upstream. In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit # should be no higher than 15, however the corresponding check is obviously off- by-one. Fixes: 045779942c04 ("clk: gate: add CLK_GATE_HIWORD_MASK") Signed-off-by: Sergei Shtylyov Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 9acb057e979d4512d74ea62287e81186961348ba Author: Peter Zijlstra Date: Mon Feb 9 11:53:18 2015 +0100 sched/autogroup: Fix failure to set cpu.rt_runtime_us commit 1fe89e1b6d270aa0d3452c60d38461ea589594e3 upstream. Because task_group() uses a cache of autogroup_task_group(), whose output depends on sched_class, switching classes can generate problems. In particular, when started as fair, the cache points to the autogroup, so when switching to RT the tg_rt_schedulable() test fails for every cpu.rt_{runtime,period}_us change because now the autogroup has tasks and no runtime. Furthermore, going back to the previous semantics of varying task_group() with sched_class has the down-side that the sched_debug output varies as well, even though the task really is in the autogroup. Therefore add an autogroup exception to tg_has_rt_tasks() -- such that both (all) task_group() usages in sched/core now have one. And remove all the remnants of the variable task_group() output. Reported-by: Zefan Li Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Stefan Bader Fixes: 8323f26ce342 ("sched: Fix race in task_group()") Link: http://lkml.kernel.org/r/20150209112237.GR5029@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c462adc8c228fa42ca16017d19f88fa535a93aab Author: Michal Hocko Date: Wed Feb 11 15:28:24 2015 -0800 vmstat: do not use deferrable delayed work for vmstat_update commit ba4877b9ca51f80b5d30f304a46762f0509e1635 upstream. Vinayak Menon has reported that an excessive number of tasks was throttled in the direct reclaim inside too_many_isolated() because NR_ISOLATED_FILE was relatively high compared to NR_INACTIVE_FILE. However it turned out that the real number of NR_ISOLATED_FILE was 0 and the per-cpu vm_stat_diff wasn't transferred into the global counter. vmstat_work which is responsible for the sync is defined as deferrable delayed work which means that the defined timeout doesn't wake up an idle CPU. A CPU might stay in an idle state for a long time and general effort is to keep such a CPU in this state as long as possible which might lead to all sorts of troubles for vmstat consumers as can be seen with the excessive direct reclaim throttling. This patch basically reverts 39bf6270f524 ("VM statistics: Make timer deferrable") but it shouldn't cause any problems for idle CPUs because only CPUs with an active per-cpu drift are woken up since 7cc36bbddde5 ("vmstat: on-demand vmstat workers v8") and CPUs which are idle for a longer time shouldn't have per-cpu drift. Fixes: 39bf6270f524 (VM statistics: Make timer deferrable) Signed-off-by: Michal Hocko Reported-by: Vinayak Menon Acked-by: Christoph Lameter Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Mel Gorman Cc: Minchan Kim Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 71a2b6dff6de85e60a1b9042aada125c69acff03 Author: Uwe Kleine-König Date: Wed Jan 28 00:45:56 2015 +0100 pinctrl: imx25: fix numbering for pins commit 34027ca2bbc6043fea8fc5c4a82670518b6be7df upstream. The pin id for a given tuple listed in a fsl,pins property is calculated by dividing the first entry (which is also a register offset) by 4. As the first available register is at offset 0x8 and configures the pad MX25_PAD_A10 the right id for this pin is 2. All other pins are off by one, too. This patch drops the definition MX25_PAD_RESERVE1 (together with its only use) and decrements all following values by 1. Fixes: b4a87c9b966f ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") Signed-off-by: Uwe Kleine-König Tested-by: Fabio Estevam Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 248f2c55b4369308e90db4ab8e3f71d187fa441c Author: Uwe Kleine-König Date: Tue Jan 27 23:50:25 2015 +0100 pinctrl: pinctrl-imx: don't use invalid value of conf_reg commit 4ff0f034e95d65f8f063a362dfcf86e986377a82 upstream. The right check for conf_reg to be invalid it testing against -1 not 0 as is done in the rest of the driver. This fixes an oops that can be triggered by: cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/* Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver") Signed-off-by: Uwe Kleine-König Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a5754abd4f4141d346ede748391364ce6882c870 Author: Sergey Ryazanov Date: Wed Feb 4 00:21:13 2015 +0300 ath5k: fix spontaneus AR5312 freezes commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream. Sometimes while CPU have some load and ath5k doing the wireless interface reset the whole WiSoC completely freezes. Set of tests shows that using atomic delay function while we wait interface reset helps to avoid such freezes. The easiest way to reproduce this issue: create a station interface, start continous scan with wpa_supplicant and load CPU by something. Or just create multiple station interfaces and put them all in continous scan. This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use usleep_range where possible"), which replaces initial udelay() by usleep_range(). I do not know actual source of this issue, but all looks like that HW freeze is caused by transaction on internal SoC bus, while wireless block is in reset state. Also I should note that I do not know how many chips are affected, but I did not see this issue with chips, other than AR5312. CC: Jiri Slaby CC: Nick Kossifidis CC: Luis R. Rodriguez Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible") Reported-by: Christophe Prevotaux Tested-by: Christophe Prevotaux Tested-by: Eric Bree Signed-off-by: Sergey Ryazanov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 46b6f104d8419a7c468c91b7e6f5289f230c4826 Author: Andrew Elble Date: Mon Feb 9 12:53:04 2015 -0500 GFS2: Fix crash during ACL deletion in acl max entry check in gfs2_set_acl() commit 278702074ff77b1a3fa2061267997095959f5e2c upstream. Fixes: e01580bf9e ("gfs2: use generic posix ACL infrastructure") Reported-by: Eric Meddaugh Tested-by: Eric Meddaugh Signed-off-by: Andrew Elble Signed-off-by: Steven Whitehouse Signed-off-by: Greg Kroah-Hartman commit c0064e10c9085a79a44ea7110c0bde081095c193 Author: Lorenzo Pieralisi Date: Tue Jan 27 18:01:45 2015 +0000 of/pci: Free resources on failure in of_pci_get_host_bridge_resources() commit d2be00c0fb5ae0794deffcdb0425cd5a8d823db0 upstream. In the function of_pci_get_host_bridge_resources() if the parsing of ranges fails, previously allocated resources inclusive of bus_range are not freed and are not expected to be freed by the function caller on error return. This patch fixes the issues by adding code that properly frees resources and bus_range before exiting the function with an error return value. Fixes: cbe4097f8ae6 ("of/pci: Add support for parsing PCI host bridge resources from DT") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Liviu Dudau CC: Arnd Bergmann CC: Rob Herring Signed-off-by: Greg Kroah-Hartman commit f42e86dcb197cbe6c21c1ad7e0293840f219be2f Author: Wanpeng Li Date: Wed Nov 26 08:44:06 2014 +0800 sched: Fix hrtick_start() on UP commit 868933359a3bdda25b562e9d41bce7071edc1b08 upstream. The commit 177ef2a6315e ("sched/deadline: Fix a precision problem in the microseconds range") forgot to change the UP version of hrtick_start(), do so now. Signed-off-by: Wanpeng Li Fixes: 177ef2a6315e ("sched/deadline: Fix a precision problem in the microseconds range") [ Fixed the changelog. ] Signed-off-by: Peter Zijlstra (Intel) Cc: Juri Lelli Cc: Kirill Tkhai Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1416962647-76792-7-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ac9967357285a52a3ffd2c4b44e14c17515a16b7 Author: Brian Norris Date: Thu Dec 18 14:55:53 2014 -0800 stable_kernel_rules: reorganize and update submission options commit 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae upstream. The current organization of Documentation/stable_kernel_rules.txt doesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to stable@vger.kernel.org, but the instructions do not make this clear. Also, there are some established processes that are not listed -- specifically, what I call Option 2 below. This patch updates and reorganizes a bit, to make things clearer. Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit a607783c8c6afba65c2058027a5dbb67bd8f603d Author: Bard Liao Date: Mon Feb 16 13:06:45 2015 +0800 ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile commit 850529249d7cce02e9bfae9476d09c8c51410d28 upstream. RT5670_IRQ_CTRL1(0xbd) is a non volatile register. And we need to restore its value after suspend/resume. Signed-off-by: Bard Liao Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 651b0e43f9f24ebbab21c3aa093b288c70cab88d Author: Peter Ujfalusi Date: Tue Mar 3 13:38:14 2015 +0200 ASoC: omap-pcm: Correct dma mask commit d51199a83a2cf82a291d19ee852c44caa511427d upstream. DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be set to 32. The 64 was introduced by commit (in 2009): a152ff24b978 ASoC: OMAP: Make DMA 64 aligned But the dma_mask and coherent_dma_mask can not be used to specify alignment. Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned) Reported-by: Grygorii Strashko Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1b9428b3de359595bcf55c792603218332a46739 Author: Trond Myklebust Date: Thu Feb 26 12:54:46 2015 -0500 NFSv4: Don't call put_rpccred() under the rcu_read_lock() commit 7c0af9ffb7bb4e5355470fa60b3eb711ddf226fa upstream. put_rpccred() can sleep. Fixes: 8f649c3762547 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 6394d0e510ce8d1de980fe2641f81ac84f3166cc Author: Trond Myklebust Date: Sun Feb 22 16:35:36 2015 -0500 NFS: Don't invalidate a submounted dentry in nfs_prime_dcache() commit 6c441c254eea2354d686be7f5544bcd79fb6a61f upstream. If we're traversing a directory which contains a submounted filesystem, or one that has a referral, the NFS server that is processing the READDIR request will often return information for the underlying (mounted-on) directory. It may, or may not, also return filehandle information. If this happens, and the lookup in nfs_prime_dcache() returns the dentry for the submounted directory, the filehandle comparison will fail, and we call d_invalidate(). Post-commit 8ed936b5671bf ("vfs: Lazily remove mounts on unlinked files and directories."), this means the entire subtree is unmounted. The following minimal patch addresses this problem by punting on the invalidation if there is a submount. Kudos to Neil Brown for having tracked down this issue (see link). Reported-by: Nix Link: http://lkml.kernel.org/r/87iofju9ht.fsf@spindle.srvr.nix Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 76e118b5f07d3e6a198e605f5665f92e74555230 Author: Heikki Krogerus Date: Fri Mar 6 15:48:38 2015 +0200 ACPI / LPSS: provide con_id for the clkdev commit fcf0789a96777d79d20290e08bf43943a5619387 upstream. Commit 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock) introduces handling for a second clk to 8250_dw.c which is the driver also for LPSS UART. The second clk forces us to provide identifier (con_id) for the clkdev we create. This fixes an issue where 8250_dw.c is getting the same handler for both clocks. Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock) Signed-off-by: Heikki Krogerus Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 78f8ef078686a9e13eaf6870bd18a8ac91519b08 Author: Chris Wilson Date: Sun Mar 1 10:41:37 2015 +0000 ACPI / video: Load the module even if ACPI is disabled commit 6e17cb12881ba8d5e456b89f072dc6b70048af36 upstream. i915.ko depends upon the acpi/video.ko module and so refuses to load if ACPI is disabled at runtime if for example the BIOS is broken beyond repair. acpi/video provides an optional service for i915.ko and so we should just allow the modules to load, but do no nothing in order to let the machines boot correctly. Reported-by: Bill Augur Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Jani Nikula Acked-by: Aaron Lu [ rjw: Fixed up the new comment in acpi_video_init() ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4a1167f2dd975d8fbf946d00caf155ad0833a61f Author: Tyler Hicks Date: Tue Feb 24 19:28:10 2015 -0600 eCryptfs: don't pass fs-specific ioctl commands through commit 6d65261a09adaa374c05de807f73a144d783669e upstream. eCryptfs can't be aware of what to expect when after passing an arbitrary ioctl command through to the lower filesystem. The ioctl command may trigger an action in the lower filesystem that is incompatible with eCryptfs. One specific example is when one attempts to use the Btrfs clone ioctl command when the source file is in the Btrfs filesystem that eCryptfs is mounted on top of and the destination fd is from a new file created in the eCryptfs mount. The ioctl syscall incorrectly returns success because the command is passed down to Btrfs which thinks that it was able to do the clone operation. However, the result is an empty eCryptfs file. This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl commands through and then copies up the inode metadata from the lower inode to the eCryptfs inode to catch any changes made to the lower inode's metadata. Those five ioctl commands are mostly common across all filesystems but the whitelist may need to be further pruned in the future. https://bugzilla.kernel.org/show_bug.cgi?id=93691 https://launchpad.net/bugs/1305335 Signed-off-by: Tyler Hicks Cc: Rocko Cc: Colin Ian King Signed-off-by: Greg Kroah-Hartman commit e16752a8d31bebed4719d869f39f1d6a00e09c89 Author: Yinghai Lu Date: Thu Feb 19 20:18:03 2015 -0800 efi/libstub: Fix boundary checking in efi_high_alloc() commit 7ed620bb343f434f8a85f830020c04988df2a140 upstream. While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. It turns out efi_high_alloc() boundary checking is not right. end - size will be the new start, and should not compare new start with max, we need to make sure end is smaller than max. [ Basically, with the current efi_high_alloc() code it's possible to allocate memory above 'max', because efi_high_alloc() doesn't check that the tail of the allocation is below 'max'. If you have an EFI memory map with a single entry that looks like so, [0xc0000000-0xc0004000] And want to allocate 0x3000 bytes below 0xc0003000 the current code will allocate [0xc0001000-0xc0004000], not [0xc0000000-0xc0003000] like you would expect. - Matt ] Signed-off-by: Yinghai Lu Reviewed-by: Ard Biesheuvel Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit f3b9a854c406ce44342bca393930a429cdb6d241 Author: Dan Carpenter Date: Thu Jan 15 12:21:21 2015 +0300 efi: Small leak on error in runtime map code commit 86d68a58d00db3770735b5919ef2c6b12d7f06f3 upstream. The "> 0" here should ">= 0" so we free map_entries[0]. Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs') Signed-off-by: Dan Carpenter Acked-by: Dave Young Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 95379cd7dae4b6e8490dab8c208b5537685cbeff Author: Andrew Elble Date: Wed Feb 25 17:46:27 2015 -0500 nfsd: fix clp->cl_revoked list deletion causing softlock in nfsd commit c876486be17aeefe0da569f3d111cbd8de6f675d upstream. commit 2d4a532d385f ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock") removed the use of the reaplist to clean out clp->cl_revoked. It failed to change list_entry() to walk clp->cl_revoked.next instead of reaplist.next Fixes: 2d4a532d385f ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock") Reported-by: Eric Meddaugh Tested-by: Eric Meddaugh Signed-off-by: Andrew Elble Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6a6eed5961f0c3181524fe6d425eeeaa8c9707bd Author: Michel Dänzer Date: Thu Jan 22 16:00:17 2015 +0900 reservation: Remove shadowing local variable 'ret' commit 4eb2440ed60fb5793f7aa6da89b3d517cc59de43 upstream. It was causing the return value of fence_is_signaled to be ignored, making reservation objects signal too early. Reviewed-by: Maarten Lankhorst Reviewed-by: Alex Deucher Signed-off-by: Michel Dänzer Signed-off-by: Sumit Semwal Signed-off-by: Greg Kroah-Hartman commit eb67532e61435486a7bc747e36f0dda697d7817e Author: Imre Deak Date: Tue Feb 24 11:14:30 2015 +0200 drm/i915: avoid processing spurious/shared interrupts in low-power states commit 2dd2a883aad7c852400027c2261bcab69d9e238e upstream. Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit e11aa362308f5de467ce355a2a2471321b15a35c Author: Jesse Barnes Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by: Klaus Ethgen Signed-off-by: Imre Deak Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit fc6f347ca3e2d877f29454fa8938cbf4975db5ae Author: Jani Nikula Date: Thu Feb 19 10:53:39 2015 +0200 drm/i915: Dell Chromebook 11 has PWM backlight commit cf6f0af9fbdd90b81af14fa6375387131cd8adf1 upstream. Add quirk for Dell Chromebook 11 backlight. Reported-and-tested-by: Owen Garland Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451 Acked-by: Damien Lespiau Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a0e57b28b7c0f92243b1a863245afacd4534fb86 Author: Chris Wilson Date: Thu Feb 12 07:53:18 2015 +0000 drm/i915: Check obj->vma_list under the struct_mutex commit 6c31a614c43ae274546f736b2a33363e149c3dc2 upstream. When we walk the list of vma, or even for protecting against concurrent framebuffer creation, we must hold the struct_mutex or else a second thread can corrupt the list as we walk it. Fixes regression from commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA References: https://bugs.freedesktop.org/show_bug.cgi?id=89085 Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 914b78e88f0a760cc490ed6a84f36edad8b3e13f Author: Rodrigo Vivi Date: Wed Jan 21 11:46:32 2015 -0800 drm/i915/bdw: PCI IDs ending in 0xb are ULT. commit 0dc6f20b9803f09726bbb682649d35cda8ef5b5d upstream. When reviewing patch that fixes VGA on BDW Halo Jani noticed that we also had other ULT IDs that weren't listed there. So this follow-up patch add these pci-ids as halo and fix comments on i915_pciids.h Cc: Jani Nikula Signed-off-by: Rodrigo Vivi Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f69d6655cdf8918564dcf831b8201025acca5afa Author: Alex Deucher Date: Thu Feb 19 16:02:15 2015 -0500 drm/radeon: fix 1 RB harvest config setup for TN/RL commit dbfb00c3e7e18439f2ebf67fe99bf7a50b5bae1e upstream. The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7b1fcdad16058b69c17522f03bf5b7f0e2e95ea0 Author: Alex Deucher Date: Wed Feb 18 01:05:30 2015 -0500 drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh commit 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 upstream. Just in case it hasn't been calculated for the mode. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 814475133b8c51ba85b723759b2ac3bca664f8db Author: Nathan-J. Hirschauer Date: Wed Feb 18 02:01:19 2015 +0100 drm/radeon: enable native backlight control on old macs commit 7a26f9ad1b5badfd0200ce2262ad696e2a6b7fbb upstream. Commit b7bc596ebbe0 ("drm/radeon: disable native backlight control on pre-r6xx asics (v2)") accidently broke backlight control on old mac laptops that use the on-GPU backlight controller. Signed-off-by: Nathan-J. Hirschauer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 60efb89c4ec8c9b68101265006f68c81189838b8 Author: Jason Gerecke Date: Thu Jan 22 15:53:28 2015 -0800 HID: wacom: Report ABS_MISC event for Cintiq Companion Hybrid commit 33e5df0e0e32027866e9fb00451952998fc957f2 upstream. It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to userspace when any of its ExpressKeys are pressed. This is not strictly necessary now that the pad exists on its own device, but should be fixed for consistency's sake. Traditionally both the stylus and pad shared the same device node, and xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes the Hybrid to behave incorrectly with xf86-input-wacom beginning with its 8f44f3 commit. Signed-off-by: Jason Gerecke Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c6cbffb4e9bcfb55482875d71615521a024e9021 Author: Jiri Kosina Date: Tue Jan 6 22:34:19 2015 +0100 HID: fixup the conflicting keyboard mappings quirk commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream. The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion on conflicting mappings") needs to properly check for VARIABLE reports as well (ARRAY reports should be ignored), otherwise legitimate keyboards might break. Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings") Reported-by: Fredrik Hallenberg Reported-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1e1d4d7158defa3c65a8566b3736c24e7e692dd6 Author: David Herrmann Date: Mon Dec 29 15:21:26 2014 +0100 HID: input: fix confusion on conflicting mappings commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream. On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its neighbours look like this: +---+ +---+ +-------+ | 1 | | 2 | | 5 | +---+ +---+ +-------+ +---+ +-----------+ | 3 | | 4 | +---+ +-----------+ On a PC-102/105 keyboard (European layout) it looks like this: +---+ +---+ +-------+ | 1 | | 2 | | | +---+ +---+ +-+ 4 | +---+ +---+ | | | 3 | | 5 | | | +---+ +---+ +-----+ (Note that the number of keys is the same, but key '5' is moved down and the shape of key '4' is changed. Keys '1' to '3' are exactly the same.) The keys 1-4 report the same scan-code in HID in both layouts, even though the keysym they produce is usually different depending on the XKB-keymap used by user-space. However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout and 0x32 for the lower layout, as defined by the HID spec. This is highly confusing as the linux-input API uses a single keycode for both. So far, this was never a problem as there never has been a keyboard with both of those keys present at the same time. It would have to look something like this: +---+ +---+ +-------+ | 1 | | 2 | | x31 | +---+ +---+ +-------+ +---+ +---+ +-----+ | 3 | |x32| | 4 | +---+ +---+ +-----+ HID can represent such a keyboard, but the linux-input API cannot. Furthermore, any user-space mapping would be confused by this and, luckily, no-one ever produced such hardware. Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys is present on a hardware, this works just fine. Lets introduce hardware-vendors into this: ------------------------------------------ Unfortunately, it seems way to expensive to produce a different device for American and European layouts. Therefore, hardware-vendors put both keys, (0x31 and 0x32) on the same keyboard, but only one of them is hooked up to the physical button, the other one is 'dead'. This means, they can use the same hardware, with a different button-layout and automatically produce the correct HID events for American *and* European layouts. This is unproblematic for normal keyboards, as the 'dead' key will never report any KEY-DOWN events. But RollOver keyboards send the whole matrix on each key-event, allowing n-key roll-over mode. This means, we get a 0x31 and 0x32 event on each key-press. One of them will always be 0, the other reports the real state. As we map both to the same keycode, we will get spurious key-events, even though the real key-state never changed. The easiest way would be to blacklist 'dead' keys and never handle those. We could simply read the 'country' tag of USB devices and blacklist either key according to the layout. But... hardware vendors... want the same device for all countries and thus many of them set 'country' to 0 for all devices. Meh.. So we have to deal with this properly. As we cannot know which of the keys is 'dead', we either need a heuristic and track those keys, or we simply make use of our value-tracking for HID fields. We simply ignore HID events for absolute data if the data didn't change. As HID tracks events on the HID level, we haven't done the keycode translation, yet. Therefore, the 'dead' key is tracked independently of the real key, therefore, any events on it will be ignored. This patch simply discards any HID events for absolute data if it didn't change compared to the last report. We need to ignore relative and buffered-byte reports for obvious reasons. But those cannot be affected by this bug, so we're fine. Preferably, we'd do this filtering on the HID-core level. But this might break a lot of custom drivers, if they do not follow the HID specs. Therefore, we do this late in hid-input just before we inject it into the input layer (which does the exact same filtering, but on the keycode level). If this turns out to break some devices, we might have to limit filtering to EV_KEY events. But lets try to do the Right Thing first, and properly filter any absolute data that didn't change. This patch is tagged for 'stable' as it fixes a lot of n-key RollOver hardware. We might wanna wait with backporting for a while, before we know it doesn't break anything else, though. Reported-by: Adam Goode Reported-by: Fredrik Hallenberg Tested-by: Fredrik Hallenberg Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a437367531473cbf5273c57a0cdbedee2275c4a8 Author: Ian Abbott Date: Mon Jan 19 14:47:27 2015 +0000 staging: comedi: cb_pcidas64: fix incorrect AI range code handling commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream. The hardware range code values and list of valid ranges for the AI subdevice is incorrect for several supported boards. The hardware range code values for all boards except PCI-DAS4020/12 is determined by calling `ai_range_bits_6xxx()` based on the maximum voltage of the range and whether it is bipolar or unipolar, however it only returns the correct hardware range code for the PCI-DAS60xx boards. For PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar ranges. For PCI-DAS64/Mx/16 it returns the wrong code for all the ranges and the comedi range table is incorrect. Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new member `ai_range_codes` of `struct pcidas64_board` to map the comedi range table indices to the hardware range codes. Use a new comedi range table for the PCI-DAS64/Mx/16 boards (and the commented out variants). Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 29bc14605e59c06d9f91dc0119ecbb27f4b26508 Author: Mikulas Patocka Date: Tue Feb 17 14:34:00 2015 -0500 dm snapshot: fix a possible invalid memory access on unload commit 22aa66a3ee5b61e0f4a0bfeabcaa567861109ec3 upstream. When the snapshot target is unloaded, snapshot_dtr() waits until pending_exceptions_count drops to zero. Then, it destroys the snapshot. Therefore, the function that decrements pending_exceptions_count should not touch the snapshot structure after the decrement. pending_complete() calls free_pending_exception(), which decrements pending_exceptions_count, and then it performs up_write(&s->lock) and it calls retry_origin_bios() which dereferences s->origin. These two memory accesses to the fields of the snapshot may touch the dm_snapshot struture after it is freed. This patch moves the call to free_pending_exception() to the end of pending_complete(), so that the snapshot will not be destroyed while pending_complete() is in progress. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ed68077f440bcd522c7e30af527611a4ff3230e0 Author: Mikulas Patocka Date: Tue Feb 17 14:30:53 2015 -0500 dm: fix a race condition in dm_get_md commit 2bec1f4a8832e74ebbe859f176d8a9cb20dd97f4 upstream. The function dm_get_md finds a device mapper device with a given dev_t, increases the reference count and returns the pointer. dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the device, tests that the device doesn't have DMF_DELETING or DMF_FREEING flag, drops _minor_lock and returns pointer to the device. dm_get_md then calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag, otherwise it increments the reference count. There is a possible race condition - after dm_find_md exits and before dm_get is called, there are no locks held, so the device may disappear or DMF_FREEING flag may be set, which results in BUG. To fix this bug, we need to call dm_get while we hold _minor_lock. This patch renames dm_find_md to dm_get_md and changes it so that it calls dm_get while holding the lock. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 48703eaf5118de9f412e983f615df56fc71e7530 Author: Darrick J. Wong Date: Fri Feb 13 11:05:37 2015 -0800 dm io: reject unsupported DISCARD requests with EOPNOTSUPP commit 37527b869207ad4c208b1e13967d69b8bba1fbf9 upstream. I created a dm-raid1 device backed by a device that supports DISCARD and another device that does NOT support DISCARD with the following dm configuration: # echo '0 2048 mirror core 1 512 2 /dev/sda 0 /dev/sdb 0' | dmsetup create moo # lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 4K 1G 0 `-moo (dm-0) 0 4K 1G 0 sdb 0 0B 0B 0 `-moo (dm-0) 0 4K 1G 0 Notice that the mirror device /dev/mapper/moo advertises DISCARD support even though one of the mirror halves doesn't. If I issue a DISCARD request (via fstrim, mount -o discard, or ioctl BLKDISCARD) through the mirror, kmirrord gets stuck in an infinite loop in do_region() when it tries to issue a DISCARD request to sdb. The problem is that when we call do_region() against sdb, num_sectors is set to zero because q->limits.max_discard_sectors is zero. Therefore, "remaining" never decreases and the loop never terminates. To fix this: before entering the loop, check for the combination of REQ_DISCARD and no discard and return -EOPNOTSUPP to avoid hanging up the mirror device. This bug was found by the unfortunate coincidence of pvmove and a discard operation in the RHEL 6.5 kernel; upstream is also affected. Signed-off-by: Darrick J. Wong Acked-by: "Martin K. Petersen" Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0a877dfa4f182dce29daae4d44f599c4f9e6f625 Author: Mikulas Patocka Date: Thu Feb 12 10:09:20 2015 -0500 dm mirror: do not degrade the mirror on discard error commit f2ed51ac64611d717d1917820a01930174c2f236 upstream. It may be possible that a device claims discard support but it rejects discards with -EOPNOTSUPP. It happens when using loopback on ext2/ext3 filesystem driven by the ext4 driver. It may also happen if the underlying devices are moved from one disk on another. If discard error happens, we reject the bio with -EOPNOTSUPP, but we do not degrade the array. This patch fixes failed test shell/lvconvert-repair-transient.sh in the lvm2 testsuite if the testsuite is extracted on an ext2 or ext3 filesystem and it is being driven by the ext4 driver. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0e60c3831e89d65fd4cd0be066162287b642682f Author: Ian Abbott Date: Tue Jan 27 18:16:51 2015 +0000 staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream. `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl. This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd` back to user-space. (This occurs when the low-level Comedi driver's `do_cmdtest()` handler returns non-zero to indicate a problem with the contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has the `CMDF_BOGUS` flag set.) `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible version of the `COMEDI_CMD` ioctl. Currently, it never copies a 32-bit compatible version of `struct comedi_cmd` back to user-space, which is at odds with the way the regular `COMEDI_CMD` ioctl is handled. To fix it, change `compat_cmd()` to copy a 32-bit compatible version of the `struct comedi_cmd` back to user-space when the main ioctl handler returns `-EAGAIN`. Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d3fd045f4faf772d903f5b590c972e5d832f5807 Author: Hans de Goede Date: Sat Jan 24 12:56:32 2015 +0100 sunxi: clk: Set sun6i-pll1 n_start = 1 commit 76820fcf7aa5a418b69cb7bed31b62d1feb1d6ad upstream. For all pll-s on sun6i n == 0 means use a multiplier of 1, rather then 0 as it means on sun4i / sun5i / sun7i. n_start = 1 is already correctly set for sun6i pll6, but was missing for pll1, this commit fixes this. Cc: Chen-Yu Tsai Signed-off-by: Hans de Goede Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit af33873cc77bf2dd6e8bd1821905bef47ec9e4e2 Author: Srinivas Kandagatla Date: Mon Jan 19 09:57:13 2015 +0000 clk: Fix debugfs clk removal before inited commit 52bba9809a954d72bc77773bd560b9724b495eb7 upstream. Some of the clks can be registered & unregistered before the clk related debugfs entries are initialized at late_initcall. In the unregister path checking for only dentry before clk_debug_init() would lead dangling pointers in the debug clk list, because the list is already populated in register path and the clk pointer freed in unregister path. The side effect of not removing it from the list is either a null pointer dereference or if lucky to boot the system, the number of clk entries in debugfs disappear. We could add more checks like if (inited && !clk->dentry) but just removing the check for dentry made more sense as debugfs_remove_recursive() seems to be safe with null pointers. This will ensure that the unregistering clk would be removed from the debug list in all the code paths. Without this patch kernel would crash with log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 3.19.0-rc3-00007-g412f9ba-dirty #840 Hardware name: Qualcomm (Flattened Device Tree) task: ed948000 ti: ed944000 task.ti: ed944000 PC is at strlen+0xc/0x40 LR is at __create_file+0x64/0x1dc pc : [] lr : [] psr: 60000013 sp : ed945e40 ip : ed945e50 fp : ed945e4c r10: 00000000 r9 : c1006094 r8 : 00000000 r7 : 000041ed r6 : 00000000 r5 : ed4af998 r4 : c11b5e28 r3 : 00000000 r2 : ed945e38 r1 : a0000013 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 8020406a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xed944248) Stack: (0xed945e40 to 0xed946000) 5e40: ed945e7c ed945e50 c049f1c4 c04ee604 c0fc2fa4 00000000 ecb748c0 c11c2b80 5e60: c0beec04 0000011c c0fc2fa4 00000000 ed945e94 ed945e80 c049f3e0 c049f16c 5e80: 00000000 00000000 ed945eac ed945e98 c08cbc50 c049f3c0 ecb748c0 c11c2b80 5ea0: ed945ed4 ed945eb0 c0fc3080 c08cbc30 c0beec04 c107e1d8 ecdf0600 c107e1d8 5ec0: c107e1d8 ecdf0600 ed945f54 ed945ed8 c0208ed4 c0fc2fb0 c026a784 c04ee628 5ee0: ed945f0c ed945ef0 c0f5d600 c04ee604 c0f5d5ec ef7fcc7d c0b40ecc 0000011c 5f00: ed945f54 ed945f10 c026a994 c0f5d5f8 c04ecc00 00000007 ef7fcc95 00000007 5f20: c0e90744 c0dd0884 ed945f54 c106cde0 00000007 c117f8c0 0000011c c0f5d5ec 5f40: c1006094 c100609c ed945f94 ed945f58 c0f5de34 c0208e50 00000007 00000007 5f60: c0f5d5ec be9b5ae0 00000000 c117f8c0 c0af1680 00000000 00000000 00000000 5f80: 00000000 00000000 ed945fac ed945f98 c0af169c c0f5dd2c ed944000 00000000 5fa0: 00000000 ed945fb0 c020f298 c0af168c 00000000 00000000 00000000 00000000 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ebcc6d33 bfffca73 [] (strlen) from [] (__create_file+0x64/0x1dc) [] (__create_file) from [] (debugfs_create_dir+0x2c/0x34) [] (debugfs_create_dir) from [] (clk_debug_create_one+0x2c/0x16c) [] (clk_debug_create_one) from [] (clk_debug_init+0xdc/0x144) [] (clk_debug_init) from [] (do_one_initcall+0x90/0x1e0) [] (do_one_initcall) from [] (kernel_init_freeable+0x114/0x1e0) [] (kernel_init_freeable) from [] (kernel_init+0x1c/0xfc) [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) Code: c0b40ecc e1a0c00d e92dd800 e24cb004 (e5d02000) ---[ end trace b940e45b5e25c1e7 ]--- Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation" Signed-off-by: Srinivas Kandagatla Reviewed-by: Stephen Boyd Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 5be4a626326063a014865c34db5d70963fbf73f2 Author: Soren Brinkmann Date: Tue Jan 27 11:05:27 2015 -0800 clk: zynq: Force CPU_2X clock to be ungated commit 3dccfecdb867fe35b305a4e493ef5652b7d9d4cb upstream. The CPU_2X clock does not have a classical in-kernel user, but is, amongst other things, required for OCM and debug access. Make sure this clock is not mistakenly disabled during boot up by enabling it in the platform's clock driver. Fixes: 0ee52b157b8e 'clk: zynq: Add clock controller driver' Signed-off-by: Soren Brinkmann Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 83ace369e37cca8dae0b2a07125b49aca33a1c9d Author: Minh Duc Tran Date: Mon Feb 9 18:54:09 2015 +0000 fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather segment boundary limit. commit f76a610a8b4b6280eaedf48f3af9d5d74e418b66 upstream. In reference to bug https://bugzilla.redhat.com/show_bug.cgi?id=1097141 Assert is seen with AMD cpu whenever calling pci_alloc_consistent. [ 29.406183] ------------[ cut here ]------------ [ 29.410505] kernel BUG at lib/iommu-helper.c:13! Signed-off-by: Minh Tran Fixes: 6733b39a1301b0b020bbcbf3295852e93e624cb1 Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 814643bcbf69637b539ab16bbab652d5f8562fc0 Author: Ryusuke Konishi Date: Fri Feb 27 15:51:56 2015 -0800 nilfs2: fix potential memory overrun on inode commit 957ed60b53b519064a54988c4e31e0087e47d091 upstream. Each inode of nilfs2 stores a root node of a b-tree, and it turned out to have a memory overrun issue: Each b-tree node of nilfs2 stores a set of key-value pairs and the number of them (in "bn_nchildren" member of nilfs_btree_node struct), as well as a few other "bn_*" members. Since the value of "bn_nchildren" is used for operations on the key-values within the b-tree node, it can cause memory access overrun if a large number is incorrectly set to "bn_nchildren". For instance, nilfs_btree_node_lookup() function determines the range of binary search with it, and too large "bn_nchildren" leads nilfs_btree_node_get_key() in that function to overrun. As for intermediate b-tree nodes, this is prevented by a sanity check performed when each node is read from a drive, however, no sanity check has been done for root nodes stored in inodes. This patch fixes the issue by adding missing sanity check against b-tree root nodes so that it's called when on-memory inodes are read from ifile, inode metadata file. Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6ff59abff69c457b6dc74b134f015d10259b7063 Author: Ilya Nelkenbaum Date: Thu Feb 5 13:53:48 2015 +0200 IB/core: When marshaling ucma path from user-space, clear unused fields commit c2be9dc0e0fa59cc43c2c7084fc42b430809a0fe upstream. When marshaling a user path to the kernel struct ib_sa_path, we need to zero smac and dmac and set the vlan id to the "no vlan" value. This is to ensure that Ethernet attributes are not used with InfiniBand QPs. Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures") Signed-off-by: Ilya Nelkenbaum Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit f90ead8d0f136b36a8527b1259e984ac58cfe4da Author: Moshe Lazer Date: Thu Feb 5 13:53:52 2015 +0200 IB/core: Fix deadlock on uverbs modify_qp error flow commit 0fb8bcf022f19a375d7c4bd79ac513da8ae6d78b upstream. The deadlock occurs in __uverbs_modify_qp: we take a lock (idr_read_qp) and in case of failure in ib_resolve_eth_l2_attrs we don't release it (put_qp_read). Fix that. Fixes: ed4c54e5b4ba ("IB/core: Resolve Ethernet L2 addresses when modifying QP") Signed-off-by: Moshe Lazer Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit b092f84af2add4f5cc3ca399e800f660154e9b65 Author: Or Gerlitz Date: Wed Dec 17 16:17:34 2014 +0200 IB/mlx4: Fix wrong usage of IPv4 protocol for multicast attach/detach commit e9a7faf11af94957e5107b40af46c2e329541510 upstream. The MLX4_PROT_IB_IPV4 protocol should only be used with RoCEv2 and such. Removing this wrong usage allows to run multicast applications over RoCE. Fixes: d487ee77740c ("IB/mlx4: Use IBoE (RoCE) IP based GIDs in the port GID table") Reported-by: Carol Soto Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit f8a4faf99f25ad33a3845eacf53b550544ec05af Author: Majd Dibbiny Date: Thu Jan 29 10:41:41 2015 +0200 IB/mlx4: Fix memory leak in __mlx4_ib_modify_qp commit bede98e781747623ae170667694a71ef19c6ba7f upstream. In case handle_eth_ud_smac_index fails, we need to free the allocated resources. Fixes: 2f5bb473681b ("mlx4: Add ref counting to port MAC table for RoCE") Signed-off-by: Majd Dibbiny Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit aeda89ac0f69090c11d6bf159ed983700e6621ef Author: Dan Carpenter Date: Mon Jan 12 11:56:58 2015 +0300 IB/mlx5: Fix error code in get_port_caps() commit f614fc15ae39ceb531586e3969f2b99fd23182a0 upstream. The current code returns success when kmalloc() fails. It should return an error code, -ENOMEM. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Dan Carpenter Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit 78a1437c7fd46d0081c691fdd3a16288a487fb5b Author: Roi Dayan Date: Sun Dec 28 14:26:11 2014 +0200 IB/iser: Use correct dma direction when unmapping SGs commit c6c95ef4cec680f7a10aa425a9970744b35b6489 upstream. We always unmap SGs with the same direction instead of unmapping with the direction the mapping was done, fix that. Fixes: 9a8b08fad2ef ("IB/iser: Generalize iser_unmap_task_data and [...]") Signed-off-by: Roi Dayan Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit caa2a1adfedfa16ce25f4230d814f425b25b9630 Author: Sagi Grimberg Date: Sun Jan 18 16:51:06 2015 +0200 IB/iser: Fix memory regions possible leak commit 6606e6a2ff2710b473838b291dc533cd8fc1471f upstream. When teardown process starts during live IO, we need to keep the memory regions pool (frmr/fmr) until all in-flight tasks are properly released, since each task may return a memory region to the pool. In order to do this, we pass a destroy flag to iser_free_ib_conn_res to indicate we can destroy the device and the memory regions pool. iser_conn_release will pass it as true and also DEVICE_REMOVAL event (we need to let the device to properly remove). Also, Since we conditionally call iser_free_rx_descriptors, remove the extra check on iser_conn->rx_descs. Fixes: 5426b1711fd0 ("IB/iser: Collapse cleanup and disconnect handlers") Reported-by: Or Gerlitz Signed-off-by: Sagi Grimberg Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit bbc56fba25d6a3ff29224503702614e311cc8e77 Author: Mitko Haralanov Date: Fri Jan 16 08:55:27 2015 -0500 IB/qib: Do not write EEPROM commit 18c0b82a3e4501511b08d0e8676fb08ac08734a3 upstream. This changeset removes all the code that allows the driver to write to the EEPROM and update the recorded error counters and power on hours. These two stats are unused and writing them exposes a timing risk which could leave the EEPROM in a bad state preventing further normal operation of the HCA. Reviewed-by: Mike Marciniszyn Signed-off-by: Mitko Haralanov Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Sasha Levin commit 26a344876afaace358669f0f06894b9bce24ec09 Author: Tony Battersby Date: Wed Feb 11 11:32:06 2015 -0500 sg: fix read() error reporting commit 3b524a683af8991b4eab4182b947c65f0ce1421b upstream. Fix SCSI generic read() incorrectly returning success after detecting an error. Signed-off-by: Tony Battersby Acked-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 636697380e1189b5385aeef9b022a3a65024fba9 Author: Sebastian Andrzej Siewior Date: Tue Feb 17 16:43:43 2015 +0100 locking/rtmutex: Avoid a NULL pointer dereference on deadlock commit 8d1e5a1a1ccf5ae9d8a5a0ee7960202ccb0c5429 upstream. With task_blocks_on_rt_mutex() returning early -EDEADLK we never add the waiter to the waitqueue. Later, we try to remove it via remove_waiter() and go boom in rt_mutex_top_waiter() because rb_entry() gives a NULL pointer. ( Tested on v3.18-RT where rtmutex is used for regular mutex and I tried to get one twice in a row. ) Not sure when this started but I guess 397335f004f4 ("rtmutex: Fix deadlock detector for real") or commit 3d5c9340d194 ("rtmutex: Handle deadlock detection smarter"). Signed-off-by: Sebastian Andrzej Siewior Acked-by: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1424187823-19600-1-git-send-email-bigeasy@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e055b8cf3331da106a9ba9457a74576a563e0455 Author: Hui Wang Date: Fri Mar 6 14:03:57 2015 +0800 ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk commit 70658b99490dd86cfdbf4fca117bbe2ef9a80d03 upstream. BugLink: https://bugs.launchpad.net/bugs/1428947 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 33da15b0eb4737a3207f2969fea5837a5a2c6b62 Author: Takashi Iwai Date: Wed Feb 25 07:53:31 2015 +0100 ALSA: hda - Disable runtime PM for Panther Point again commit de5d0ad506cb10ab143e2ffb9def7607e3671f83 upstream. This is essentially a partial revert of the commit [b1920c21102a: 'ALSA: hda - Enable runtime PM on Panther Point']. There was a bug report showing the HD-audio bus hang during runtime PM on HP Spectre XT. Reported-by: Dang Sananikone Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fc30e76c8a7834726ed2955180ad564cdc7f42e4 Author: Jaroslav Kysela Date: Tue Feb 24 12:04:57 2015 +0100 ALSA: hda: controller code - do not export static functions commit 37ed398839fa3e0d2de77925097db7a370abb096 upstream. It is a bad idea to export static functions. GCC for some platforms shows errors like: error: __ksymtab_azx_get_response causes a section type conflict Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c78962a5cf041afc732eb1202636ddc5988e959e Author: Takashi Iwai Date: Thu Feb 19 13:01:37 2015 +0100 ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec commit 6426460e5d87810e042962281fe3c1e8fc256162 upstream. BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need to give explicitly here. Reported-and-tested-by: Misan Thropos Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 10556d5c3831cbb644b74c7501722a06564026b9 Author: Takashi Iwai Date: Thu Dec 18 10:02:41 2014 +0100 ALSA: pcm: Don't leave PREPARED state after draining commit 70372a7566b5e552dbe48abdac08c275081d8558 upstream. When a PCM draining is performed to an empty stream that has been already in PREPARED state, the current code just ignores and leaves as it is, although the drain is supposed to set all such streams to SETUP state. This patch covers that overlooked case. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d2d74ad4febf3c32d508a3b31d952e889eb8b81e Author: Sebastian Andrzej Siewior Date: Sun Feb 15 18:32:16 2015 +0100 serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO" commit ca8bb4aefb932e3da105f28cbfba36d57a931081 upstream. This reverts commit 0aa525d11859c1a4d5b78fdc704148e2ae03ae13. The conditional RX-FIFO read seems to cause spurious interrupts and we see just: |serial8250: too much work for irq29 The previous behaviour was "default" for decades and Marvell's 88f6282 SoC might not be the only that relies on it. Therefore the Omap fix is reverted for now. Fixes: 0aa525d11859 ("tty: serial: 8250_core: read only RX if there is something in the FIFO") Reported-By: Nicolas Schichan Debuged-By: Peter Hurley Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 8ca9d129871d99f27c85d565fb5dff9f837f2811 Author: Jiri Slaby Date: Fri Feb 27 18:40:31 2015 +0100 tty: fix up atime/mtime mess, take four commit f0bf0bd07943bfde8f5ac39a32664810a379c7d3 upstream. This problem was taken care of three times already in * b0de59b5733d18b0d1974a060860a8b5c1b36a2e (TTY: do not update atime/mtime on read/write), * 37b7f3c76595e23257f61bd80b223de8658617ee (TTY: fix atime/mtime regression), and * b0b885657b6c8ef63a46bc9299b2a7715d19acde (tty: fix up atime/mtime mess, take three) But it still misses one point. As John Paul correctly points out, we do not care about setting date. If somebody ever changes wall time backwards (by mistake for example), tty timestamps are never updated until the original wall time passes. So check the absolute difference of times and if it large than "8 seconds or so", always update the time. That means we will update immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the check, but it was always that way. Thanks John for serving me this so nicely debugged. Signed-off-by: Jiri Slaby Reported-by: John Paul Perry Acked-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b7dc640d64902d88d4ff9117d1f417ea471ee562 Author: Vineet Gupta Date: Fri Feb 27 10:39:17 2015 +0530 ARC: Fix KSTK_ESP() commit 13648b0118a24f4fc76c34e6c7b6ccf447e46a2a upstream. /proc//maps currently don't annotate stack vma with "[stack]" This is because KSTK_ESP ie expected to return usermode SP of tsk while currently it returns the kernel mode SP of a sleeping tsk. While the fix is trivial, we also need to adjust the ARC kernel stack unwinder to not use KSTK_SP and friends any more. Reported-and-suggested-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 8ed378b1711f05f26c4ebce1c81eda7cf6e89f44 Author: Chuck Lever Date: Fri Feb 13 13:08:25 2015 -0500 SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock commit 813b00d63f6ca1ed40a2f4f9c034d59bc424025e upstream. Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock. xprt_complete_bc_request() should do the same. Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split . . .") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ca261c91b5dd6c4b0d9ab9b6c9286a19b15fc680 Author: Al Viro Date: Sat Mar 7 21:08:46 2015 +0000 sunrpc: fix braino in ->poll() commit 1711fd9addf214823b993468567cab1f8254fc51 upstream. POLL_OUT isn't what callers of ->poll() are expecting to see; it's actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap bit... Signed-off-by: Al Viro Cc: Bruce Fields Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 208fb83dac2f4355d854222d2e9cb17a4123fd58 Author: Al Viro Date: Sat Feb 21 22:16:11 2015 -0500 procfs: fix race between symlink removals and traversals commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9 upstream. use_pde()/unuse_pde() in ->follow_link()/->put_link() resp. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c74eb981faeac66ad77545ecab2ed54d5b6fbe6e Author: Al Viro Date: Sat Feb 21 22:05:11 2015 -0500 debugfs: leave freeing a symlink body until inode eviction commit 0db59e59299f0b67450c5db21f7f316c8fb04e84 upstream. As it is, we have debugfs_remove() racing with symlink traversals. Supply ->evict_inode() and do freeing there - inode will remain pinned until we are done with the symlink body. And rip the idiocy with checking if dentry is positive right after we'd verified debugfs_positive(), which is a stronger check... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit be9eb995384f8f619ab5255b29ba35c3b4780bed Author: Al Viro Date: Sat Feb 21 22:19:57 2015 -0500 autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation commit 0a280962dc6e117e0e4baa668453f753579265d9 upstream. X-Coverup: just ask spender Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 318dc9ceff4e0c9f43168902c4df883b2956e5fc Author: Johan Hovold Date: Wed Feb 18 10:34:51 2015 +0700 USB: serial: fix tty-device error handling at probe commit ca4383a3947a83286bc9b9c598a1f55e867871d7 upstream. Add missing error handling when registering the tty device at port probe. This avoids trying to remove an uninitialised character device when the port device is removed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Takashi Iwai Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit acc69639af028cb6e2a74d66a1dea931c9ea17b2 Author: Johan Hovold Date: Wed Feb 18 10:34:50 2015 +0700 USB: serial: fix potential use-after-free after failed probe commit 07fdfc5e9f1c966be8722e8fa927e5ea140df5ce upstream. Fix return value in probe error path, which could end up returning success (0) on errors. This could in turn lead to use-after-free or double free (e.g. in port_remove) when the port device is removed. Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove at the right times") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2e52da5fbf6d34bb496986d408ccb8eaf93800ff Author: Johan Hovold Date: Wed Mar 4 10:39:06 2015 +0100 TTY: fix tty_wait_until_sent on 64-bit machines commit 79fbf4a550ed6a22e1ae1516113e6c7fa5d56a53 upstream. Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an infinite timeout (0) would be passed to the underlying tty-driver's wait_until_sent-operation as a negative timeout (-1), causing it to return immediately. This manifests itself for example as tcdrain() returning immediately, drivers not honouring the drain flags when setting terminal attributes, or even dropped data on close as a requested infinite closing-wait timeout would be ignored. The first symptom was reported by Asier LLANO who noted that tcdrain() returned prematurely when using the ftdi_sio usb-serial driver. Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the underlying tty driver. Note that the serial-core wait_until_sent-implementation is not affected by this bug due to a lucky chance (comparison to an unsigned maximum timeout), and neither is the cyclades one that had an explicit check for negative timeouts, but all other tty drivers appear to be affected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: ZIV-Asier Llano Palacios Signed-off-by: Johan Hovold Reviewed-by: Peter Hurley Signed-off-by: Sasha Levin commit ec02f95f554f3ef15f249cf2af16bf21bbb8a2b3 Author: Johan Hovold Date: Wed Mar 4 10:39:05 2015 +0100 USB: serial: fix infinite wait_until_sent timeout commit f528bf4f57e43d1af4b2a5c97f09e43e0338c105 upstream. Make sure to handle an infinite timeout (0). Note that wait_until_sent is currently never called with a 0-timeout argument due to a bug in tty_wait_until_sent. Fixes: dcf010503966 ("USB: serial: add generic wait_until_sent implementation") Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit d6bc66d775f2ad2419aef5fc39b2347a6fdf357c Author: Johan Hovold Date: Wed Mar 4 10:39:03 2015 +0100 net: irda: fix wait_until_sent poll timeout commit 2c3fbe3cf28fbd7001545a92a83b4f8acfd9fa36 upstream. In case an infinite timeout (0) is requested, the irda wait_until_sent implementation would use a zero poll timeout rather than the default 200ms. Note that wait_until_sent is currently never called with a 0-timeout argument due to a bug in tty_wait_until_sent. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 13c54411be91b8c1249caecb06e666cb94161698 Author: Jouni Malinen Date: Thu Feb 26 15:50:50 2015 +0200 mac80211: Send EAPOL frames at lowest rate commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream. The current minstrel_ht rate control behavior is somewhat optimistic in trying to find optimum TX rate. While this is usually fine for normal Data frames, there are cases where a more conservative set of retry parameters would be beneficial to make the connection more robust. EAPOL frames are critical to the authentication and especially the EAPOL-Key message 4/4 (the last message in the 4-way handshake) is important to get through to the AP. If that message is lost, the only recovery mechanism in many cases is to reassociate with the AP and start from scratch. This can often be avoided by trying to send the frame with more conservative rate and/or with more link layer retries. In most cases, minstrel_ht is currently using the initial EAPOL-Key frames for probing higher rates and this results in only five link layer transmission attempts (one at high(ish) MCS and four at MCS0). While this works with most APs, it looks like there are some deployed APs that may have issues with the EAPOL frames using HT MCS immediately after association. Similarly, there may be issues in cases where the signal strength or radio environment is not good enough to be able to get frames through even at couple of MCS 0 tries. The best approach for this would likely to be to reduce the TX rate for the last rate (3rd rate parameter in the set) to a low basic rate (say, 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly requires some more effort. For now, we can start with a simple one-liner that forces the minimum rate to be used for EAPOL frames similarly how the TX rate is selected for the IEEE 802.11 Management frames. This does result in a small extra latency added to the cases where the AP would be able to receive the higher rate, but taken into account how small number of EAPOL frames are used, this is likely to be insignificant. A future optimization in the minstrel_ht design can also allow this patch to be reverted to get back to the more optimized initial TX rate. It should also be noted that many drivers that do not use minstrel as the rate control algorithm are already doing similar workarounds by forcing the lowest TX rate to be used for EAPOL frames. Reported-by: Linus Torvalds Tested-by: Linus Torvalds Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1d2dcde82265ba849b1c9a577fa68ebba254317a Author: Mathias Nyman Date: Fri Mar 6 17:23:19 2015 +0200 xhci: Workaround for PME stuck issues in Intel xhci commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream. The xhci in Intel Sunrisepoint and Cherryview platforms need a driver workaround for a Stuck PME that might either block PME events in suspend, or create spurious PME events preventing runtime suspend. Workaround is to clear a internal PME flag, BIT(28) in a vendor specific PMCTRL register at offset 0x80a4, in both suspend resume callbacks Without this, xhci connected usb devices might never be able to wake up the system from suspend, or prevent device from going to suspend (xhci d3) Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin commit 662a8fbce79e3178558ce7eaafcb148dd14419e9 Author: Aleksander Morgado Date: Fri Mar 6 17:14:21 2015 +0200 xhci: fix reporting of 0-sized URBs in control endpoint commit 45ba2154d12fc43b70312198ec47085f10be801a upstream. When a control transfer has a short data stage, the xHCI controller generates two transfer events: a COMP_SHORT_TX event that specifies the untransferred amount, and a COMP_SUCCESS event. But when the data stage is not short, only the COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless urb->actual_length was set already by a previous COMP_SHORT_TX event. The driver checks this by seeing whether urb->actual_length == 0, but this alone is the wrong test, as it is entirely possible for a short transfer to have an urb->actual_length = 0. This patch changes the xhci driver to rely on a new td->urb_length_set flag, which is set to true when a COMP_SHORT_TX event is received and the URB length updated at that stage. This fixes a bug which affected the HSO plugin, which relies on URBs with urb->actual_length == 0 to halt re-submitting the RX URB in the control endpoint. Signed-off-by: Aleksander Morgado Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin commit cc405315a775785af00696fdc859a269017df6fb Author: Mathias Nyman Date: Tue Feb 24 18:27:01 2015 +0200 xhci: Allocate correct amount of scratchpad buffers commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream. Include the high order bit fields for Max scratchpad buffers when calculating how many scratchpad buffers are needed. I'm suprised this hasn't caused more issues, we never allocated more than 32 buffers even if xhci needed more. Either we got lucky and xhci never really used past that area, or then we got enough zeroed dma memory anyway. Should be backported as far back as possible Reported-by: Tim Chen Tested-by: Tim Chen Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin commit 9e3e203f169ecefbe1ac7d67e24ccdf63e259f25 Author: Maxime Ripard Date: Tue Feb 24 18:27:00 2015 +0200 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks commit 1e7e4fb66489cc84366656ca5318f1cb61afd4ba upstream. The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window. However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock. Things get messy when EPROBE_DEFER is involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever. Fix this by running the quirks after the clock has been enabled by the driver. Signed-off-by: Maxime Ripard Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8bea8b45631a0c4f4d4aa08fa4792a9a61aeb300 Author: Andrzej Pietrasiewicz Date: Fri Feb 13 12:12:53 2015 +0100 usb: gadget: configfs: don't NUL-terminate (sub)compatible ids commit a0456399fb07155637a2b597b91cc1c63bc25141 upstream. The "Extended Compat ID OS Feature Descriptor Specification" does not require the (sub)compatible ids to be NUL-terminated, because they are placed in a fixed-size buffer and only unused parts of it should contain NULs. If the buffer is fully utilized, there is no place for NULs. Consequently, the code which uses desc->ext_compat_id never expects the data contained to be NUL terminated. If the compatible id is stored after sub-compatible id, and the compatible id is full length (8 bytes), the (useless) NUL terminator overwrites the first byte of the sub-compatible id. If the sub-compatible id is full length (8 bytes), the (useless) NUL terminator ends up out of the buffer. The situation can happen in the RNDIS function, where the buffer is a part of struct f_rndis_opts. The next member of struct f_rndis_opts is a mutex, so its first byte gets overwritten. The said byte is a part of a mutex'es member which contains the information on whether the muext is locked or not. This can lead to a deadlock, because, in a configfs-composed gadget when a function is linked into a configuration with config_usb_cfg_link(), usb_get_function() is called, which then calls rndis_alloc(), which tries locking the same mutex and (wrongly) finds it already locked. This patch eliminates NUL terminating of the (sub)compatible id. Fixes: da4243145fb1: "usb: gadget: configfs: OS Extended Compatibility descriptors support" Reported-by: Dan Carpenter Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 092140164c4bd4186d6545b684403534cfef767e Author: George Cherian Date: Fri Feb 13 10:13:24 2015 +0530 usb: dwc3: dwc3-omap: Fix disable IRQ commit 96e5d31244c5542f5b2ea81d76f14ba4b8a7d440 upstream. In the wrapper the IRQ disable should be done by writing 1's to the IRQ*_CLR register. Existing code is broken because it instead writes zeros to IRQ*_SET register. Fix this by adding functions dwc3_omap_write_irqmisc_clr() and dwc3_omap_write_irq0_clr() which do the right thing. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: George Cherian Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e377af70258aceab65f7db8033e8fde81e99958f Author: Max Mansfield Date: Mon Mar 2 18:38:02 2015 -0700 usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards commit c7d373c3f0da2b2b78c4b1ce5ae41485b3ef848c upstream. This patch integrates Cyber Cortex AV boards with the existing ftdi_jtag_quirk in order to use serial port 0 with JTAG which is required by the manufacturers' software. Steps: 2 [ftdi_sio_ids.h] 1. Defined the device PID [ftdi_sio.c] 2. Added a macro declaration to the ids array, in order to enable the jtag quirk for the device. Signed-off-by: Max Mansfield Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 7ab630607a087798ec180b7055ae466c0d480347 Author: Mark Glover Date: Fri Feb 13 09:04:39 2015 +0000 USB: ftdi_sio: add PIDs for Actisense USB devices commit f6950344d3cf4a1e231b5828b50c4ac168db3886 upstream. These product identifiers (PID) all deal with marine NMEA format data used on motor boats and yachts. We supply the programmed devices to Chetco, for use inside their equipment. The PIDs are a direct copy of our Windows device drivers (FTDI drivers with altered PIDs). Signed-off-by: Mark Glover [johan: edit commit message slightly ] Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 9705b410152451e509ec0049aa1ce6eab79b98e7 Author: Alan Stern Date: Fri Feb 13 10:54:53 2015 -0500 USB: usbfs: don't leak kernel data in siginfo commit f0c2b68198589249afd2b1f2c4e8de8c03e19c16 upstream. When a signal is delivered, the information in the siginfo structure is copied to userspace. Good security practice dicatates that the unused fields in this structure should be initialized to 0 so that random kernel stack data isn't exposed to the user. This patch adds such an initialization to the two places where usbfs raises signals. Signed-off-by: Alan Stern Reported-by: Dave Mielke Signed-off-by: Sasha Levin commit 405703342558427c0e97e1178074c7df15047bd4 Author: Johan Hovold Date: Wed Feb 18 11:51:07 2015 +0700 USB: mxuport: fix null deref when used as a console commit db81de767e375743ebb0ad2bcad3326962c2b67e upstream. Fix null-pointer dereference at probe when the device is used as a console, in which case the tty argument to open will be NULL. Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e7d3ac3545bc976217858eafd54c40ec7b0335c1 Author: Michiel vd Garde Date: Fri Feb 27 02:08:29 2015 +0100 USB: serial: cp210x: Adding Seletek device id's commit 675af70856d7cc026be8b6ea7a8b9db10b8b38a1 upstream. These device ID's are not associated with the cp210x module currently, but should be. This patch allows the devices to operate upon connecting them to the usb bus as intended. Signed-off-by: Michiel van de Garde Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 64264c33bfb941f4fc9ed49b183f292dc704f893 Author: Johan Hovold Date: Sun Feb 15 11:57:53 2015 +0700 Revert "USB: serial: make bulk_out_size a lower limit" commit bc4b1f486fe69b86769e07c8edce472327a8462b upstream. This reverts commit 5083fd7bdfe6760577235a724cf6dccae13652c2. A bulk-out size smaller than the end-point size is indeed valid. The offending commit broke the usb-debug driver for EHCI debug devices, which use 8-byte buffers. Fixes: 5083fd7bdfe6 ("USB: serial: make bulk_out_size a lower limit") Reported-by: "Li, Elvin" Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit ddcc85e52e9c2b9a36e5c837453421b089dab310 Author: Hans de Goede Date: Mon Feb 23 13:41:14 2015 +0100 uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539 commit 59e980efafd27df83a5c85c054f906d82bcbf752 upstream. Like the JMicron JMS567 enclosures with the JMS539 choke on report-opcodes, so avoid it. Tested-and-reported-by: Tom Arild Naess Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit a3ee1048dd8559a8498d98b2e55bf91686e44087 Author: James Hogan Date: Tue Feb 24 11:46:20 2015 +0000 KVM: MIPS: Fix trace event to save PC directly commit b3cffac04eca9af46e1e23560a8ee22b1bd36d43 upstream. Currently the guest exit trace event saves the VCPU pointer to the structure, and the guest PC is retrieved by dereferencing it when the event is printed rather than directly from the trace record. This isn't safe as the printing may occur long afterwards, after the PC has changed and potentially after the VCPU has been freed. Usually this results in the same (wrong) PC being printed for multiple trace events. It also isn't portable as userland has no way to access the VCPU data structure when interpreting the trace record itself. Lets save the actual PC in the structure so that the correct value is accessible later. Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Ralf Baechle Cc: Marcelo Tosatti Cc: Gleb Natapov Cc: Steven Rostedt Cc: Ingo Molnar Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Acked-by: Steven Rostedt Signed-off-by: Marcelo Tosatti Signed-off-by: Sasha Levin commit c8b6504b25d2894e7e3b4909bae15ebcd740120b Author: Paolo Bonzini Date: Thu Feb 12 17:04:47 2015 +0100 KVM: emulate: fix CMPXCHG8B on 32-bit hosts commit 4ff6f8e61eb7f96d3ca535c6d240f863ccd6fb7d upstream. This has been broken for a long time: it broke first in 2.6.35, then was almost fixed in 2.6.36 but this one-liner slipped through the cracks. The bug shows up as an infinite loop in Windows 7 (and newer) boot on 32-bit hosts without EPT. Windows uses CMPXCHG8B to write to page tables, which causes a page fault if running without EPT; the emulator is then called from kvm_mmu_page_fault. The loop then happens if the higher 4 bytes are not 0; the common case for this is that the NX bit (bit 63) is 1. Fixes: 6550e1f165f384f3a46b60a1be9aba4bc3c2adad Fixes: 16518d5ada690643453eb0aef3cc7841d3623c2d Reported-by: Erik Rull Tested-by: Erik Rull Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 218c886394e239706714caec1fb5d7c47fcb54c8 Author: Quentin Casasnovas Date: Tue Mar 3 16:31:38 2015 +0100 Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref. commit dd9ef135e3542ffc621c4eb7f0091870ec7a1504 upstream. Improper arithmetics when calculting the address of the extended ref could lead to an out of bounds memory read and kernel panic. Signed-off-by: Quentin Casasnovas Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 0ab9252919f9a72aa381cac67ac77d5c470a7215 Author: Filipe Manana Date: Sun Mar 1 20:36:00 2015 +0000 Btrfs: fix data loss in the fast fsync path commit 3a8b36f378060d20062a0918e99fae39ff077bf0 upstream. When using the fast file fsync code path we can miss the fact that new writes happened since the last file fsync and therefore return without waiting for the IO to finish and write the new extents to the fsync log. Here's an example scenario where the fsync will miss the fact that new file data exists that wasn't yet durably persisted: 1. fs_info->last_trans_committed == N - 1 and current transaction is transaction N (fs_info->generation == N); 2. do a buffered write; 3. fsync our inode, this clears our inode's full sync flag, starts an ordered extent and waits for it to complete - when it completes at btrfs_finish_ordered_io(), the inode's last_trans is set to the value N (via btrfs_update_inode_fallback -> btrfs_update_inode -> btrfs_set_inode_last_trans); 4. transaction N is committed, so fs_info->last_trans_committed is now set to the value N and fs_info->generation remains with the value N; 5. do another buffered write, when this happens btrfs_file_write_iter sets our inode's last_trans to the value N + 1 (that is fs_info->generation + 1 == N + 1); 6. transaction N + 1 is started and fs_info->generation now has the value N + 1; 7. transaction N + 1 is committed, so fs_info->last_trans_committed is set to the value N + 1; 8. fsync our inode - because it doesn't have the full sync flag set, we only start the ordered extent, we don't wait for it to complete (only in a later phase) therefore its last_trans field has the value N + 1 set previously by btrfs_file_write_iter(), and so we have: inode->last_trans <= fs_info->last_trans_committed (N + 1) (N + 1) Which made us not log the last buffered write and exit the fsync handler immediately, returning success (0) to user space and resulting in data loss after a crash. This can actually be triggered deterministically and the following excerpt from a testcase I made for xfstests triggers the issue. It moves a dummy file across directories and then fsyncs the old parent directory - this is just to trigger a transaction commit, so moving files around isn't directly related to the issue but it was chosen because running 'sync' for example does more than just committing the current transaction, as it flushes/waits for all file data to be persisted. The issue can also happen at random periods, since the transaction kthread periodicaly commits the current transaction (about every 30 seconds by default). The body of the test is: _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create our main test file 'foo', the one we check for data loss. # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync' # bit from its flags (btrfs inode specific flags). $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \ -c "fsync" $SCRATCH_MNT/foo | _filter_xfs_io # Now create one other file and 2 directories. We will move this second file # from one directory to the other later because it forces btrfs to commit its # currently open transaction if we fsync the old parent directory. This is # necessary to trigger the data loss bug that affected btrfs. mkdir $SCRATCH_MNT/testdir_1 touch $SCRATCH_MNT/testdir_1/bar mkdir $SCRATCH_MNT/testdir_2 # Make sure everything is durably persisted. sync # Write more 8Kb of data to our file. $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo | _filter_xfs_io # Move our 'bar' file into a new directory. mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar # Fsync our first directory. Because it had a file moved into some other # directory, this made btrfs commit the currently open transaction. This is # a condition necessary to trigger the data loss bug. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1 # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of # data we wrote previously to be persisted and available if a crash happens. # This did not happen with btrfs, because of the transaction commit that # happened when we fsynced the parent directory. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # Now check that all data we wrote before are available. echo "File content after log replay:" od -t x1 $SCRATCH_MNT/foo status=0 exit The expected golden output for the test, which is what we get with this fix applied (or when running against ext3/4 and xfs), is: wrote 8192/8192 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 8192/8192 bytes at offset 8192 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) File content after log replay: 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb * 0040000 Without this fix applied, the output shows the test file does not have the second 8Kb extent that we successfully fsynced: wrote 8192/8192 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 8192/8192 bytes at offset 8192 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) File content after log replay: 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0020000 So fix this by skipping the fsync only if we're doing a full sync and if the inode's last_trans is <= fs_info->last_trans_committed, or if the inode is already in the log. Also remove setting the inode's last_trans in btrfs_file_write_iter since it's useless/unreliable. Also because btrfs_file_write_iter no longer sets inode->last_trans to fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't bail out if last_trans is 0, otherwise something as simple as the following example wouldn't log the second write on the last fsync: 1. write to file 2. fsync file 3. fsync file |--> btrfs_inode_in_log() returns true and it set last_trans to 0 4. write to file |--> btrfs_file_write_iter() no longers sets last_trans, so it remained with a value of 0 5. fsync |--> inode->last_trans == 0, so it bails out without logging the second write A test case for xfstests will be sent soon. Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit d771f1d4941c553a320cd40eed826a272a522945 Author: David Sterba Date: Tue Feb 24 18:57:18 2015 +0100 btrfs: fix lost return value due to variable shadowing commit 1932b7be973b554ffe20a5bba6ffaed6fa995cdc upstream. A block-local variable stores error code but btrfs_get_blocks_direct may not return it in the end as there's a ret defined in the function scope. Fixes: d187663ef24c ("Btrfs: lock extents as we map them in DIO") Signed-off-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 67b67dfa5982320f9baf97dc0869a85d27210ccb Author: Filipe Manana Date: Mon Feb 9 17:17:43 2015 +0000 Btrfs: fix fsync race leading to ordered extent memory leaks commit 4d884fceaa2c838abb598778813e93f6d9fea723 upstream. We can have multiple fsync operations against the same file during the same transaction and they can collect the same ordered extents while they don't complete (still accessible from the inode's ordered tree). If this happens, those ordered extents will never get their reference counts decremented to 0, leading to memory leaks and inode leaks (an iput for an ordered extent's inode is scheduled only when the ordered extent's refcount drops to 0). The following sequence diagram explains this race: CPU 1 CPU 2 btrfs_sync_file() btrfs_sync_file() mutex_lock(inode->i_mutex) btrfs_log_inode() btrfs_get_logged_extents() --> collects ordered extent X --> increments ordered extent X's refcount btrfs_submit_logged_extents() mutex_unlock(inode->i_mutex) mutex_lock(inode->i_mutex) btrfs_sync_log() btrfs_wait_logged_extents() --> list_del_init(&ordered->log_list) btrfs_log_inode() btrfs_get_logged_extents() --> Adds ordered extent X to logged_list because at this point: list_empty(&ordered->log_list) && test_bit(BTRFS_ORDERED_LOGGED, &ordered->flags) == 0 --> Increments ordered extent X's refcount --> check if ordered extent's io is finished or not, start it if necessary and wait for it to finish --> sets bit BTRFS_ORDERED_LOGGED on ordered extent X's flags and adds it to trans->ordered btrfs_sync_log() finishes btrfs_submit_logged_extents() btrfs_log_inode() finishes mutex_unlock(inode->i_mutex) btrfs_sync_file() finishes btrfs_sync_log() btrfs_wait_logged_extents() --> Sees ordered extent X has the bit BTRFS_ORDERED_LOGGED set in its flags --> X's refcount is untouched btrfs_sync_log() finishes btrfs_sync_file() finishes btrfs_commit_transaction() --> called by transaction kthread for e.g. btrfs_wait_pending_ordered() --> waits for ordered extent X to complete --> decrements ordered extent X's refcount by 1 only, corresponding to the increment done by the fsync task ran by CPU 1 In the scenario of the above diagram, after the transaction commit, the ordered extent will remain with a refcount of 1 forever, leaking the ordered extent structure and preventing the i_count of its inode from ever decreasing to 0, since the delayed iput is scheduled only when the ordered extent's refcount drops to 0, preventing the inode from ever being evicted by the VFS. Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to mean that an ordered extent is already being processed by an fsync call, which will attach it to the current transaction, preventing it from being collected by subsequent fsync operations against the same inode. This race was introduced with the following change (added in 3.19 and backported to stable 3.18 and 3.17): Btrfs: make sure logged extents complete in the current transaction V3 commit 50d9aa99bd35c77200e0e3dd7a72274f8304701f I ran into this issue while running xfstests/generic/113 in a loop, which failed about 1 out of 10 runs with the following warning in dmesg: [ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]() [ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo ppy e1000 scsi_mod [last unloaded: btrfs] [ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G W 3.19.0-rc5-btrfs-next-4+ #1 [ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 2612.457709] 0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8 [ 2612.459829] 0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000 [ 2612.461564] ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068 [ 2612.463163] Call Trace: [ 2612.463719] [] dump_stack+0x4c/0x65 [ 2612.464789] [] warn_slowpath_common+0xa1/0xbb [ 2612.466026] [] ? free_fs_root+0x36/0x133 [btrfs] [ 2612.467247] [] warn_slowpath_null+0x1a/0x1c [ 2612.468416] [] free_fs_root+0x36/0x133 [btrfs] [ 2612.469625] [] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs] [ 2612.471251] [] btrfs_free_fs_roots+0xa4/0xd6 [btrfs] [ 2612.472536] [] ? wait_for_completion+0x24/0x26 [ 2612.473742] [] close_ctree+0x1f3/0x33c [btrfs] [ 2612.475477] [] ? destroy_workqueue+0x148/0x1ba [ 2612.476695] [] btrfs_put_super+0x19/0x1b [btrfs] [ 2612.477911] [] generic_shutdown_super+0x73/0xef [ 2612.479106] [] kill_anon_super+0x13/0x1e [ 2612.480226] [] btrfs_kill_super+0x17/0x23 [btrfs] [ 2612.481471] [] deactivate_locked_super+0x3b/0x50 [ 2612.482686] [] deactivate_super+0x3f/0x43 [ 2612.483791] [] cleanup_mnt+0x59/0x78 [ 2612.484842] [] __cleanup_mnt+0x12/0x14 [ 2612.485900] [] task_work_run+0x8f/0xbc [ 2612.486960] [] do_notify_resume+0x5a/0x6b [ 2612.488083] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 2612.489333] [] int_signal+0x12/0x17 [ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]--- [ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds. Have a nice day... Kmemleak confirmed the ordered extent leak (and btrfs inode specific structures such as delayed nodes): $ cat /sys/kernel/debug/kmemleak unreferenced object 0xffff880154290db0 (size 576): comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s) hex dump (first 32 bytes): 01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff .@.........N.... 00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff ..........)T.... backtrace: [] kmemleak_update_trace+0x4c/0x6a [] radix_tree_node_alloc+0x6d/0x83 [] __radix_tree_create+0x109/0x190 [] radix_tree_insert+0x30/0xac [] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [] __btrfs_unlink_inode+0xee/0x288 [btrfs] [] btrfs_unlink_inode+0x1e/0x40 [btrfs] [] btrfs_unlink+0x60/0x9b [btrfs] [] vfs_unlink+0x9c/0xed [] do_unlinkat+0x12c/0x1fa [] SyS_unlinkat+0x29/0x2b [] system_call_fastpath+0x12/0x17 [] 0xffffffffffffffff unreferenced object 0xffff88014ef11db0 (size 576): comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s) hex dump (first 32 bytes): 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff ...........N.... backtrace: [] kmemleak_update_trace+0x4c/0x6a [] radix_tree_node_alloc+0x6d/0x83 [] __radix_tree_create+0x109/0x190 [] radix_tree_insert+0x30/0xac [] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [] __btrfs_unlink_inode+0xee/0x288 [btrfs] [] btrfs_unlink_inode+0x1e/0x40 [btrfs] [] btrfs_unlink+0x60/0x9b [btrfs] [] vfs_unlink+0x9c/0xed [] do_unlinkat+0x12c/0x1fa [] SyS_unlinkat+0x29/0x2b [] system_call_fastpath+0x12/0x17 [] 0xffffffffffffffff unreferenced object 0xffff8800336feda8 (size 584): comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s) hex dump (first 32 bytes): 00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00 .@>........B.... 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 ................ backtrace: [] create_object+0x172/0x29a [] kmemleak_alloc+0x25/0x41 [] kmemleak_alloc_recursive.constprop.52+0x16/0x18 [] kmem_cache_alloc+0xf7/0x198 [] __btrfs_add_ordered_extent+0x43/0x309 [btrfs] [] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs] [] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs] [] do_blockdev_direct_IO+0x62a/0xb47 [] __blockdev_direct_IO+0x34/0x36 [] btrfs_direct_IO+0x16a/0x1e8 [btrfs] [] generic_file_direct_write+0xb8/0x12d [] btrfs_file_write_iter+0x24b/0x42f [btrfs] [] aio_run_iocb+0x2b7/0x32e [] do_io_submit+0x26e/0x2ff [] SyS_io_submit+0x10/0x12 [] system_call_fastpath+0x12/0x17 Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 85f1ab830872695c6b414c87ad5d2730b52cb23d Author: Alexander Usyskin Date: Tue Feb 10 10:36:36 2015 +0200 mei: make device disabled on stop unconditionally commit 6c15a8516b8118eb19a59fd0bd22df41b9101c32 upstream. Set the internal device state to to disabled after hardware reset in stop flow. This will cover cases when driver was not brought to disabled state because of an error and in stop flow we wish not to retry the reset. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Sasha Levin commit 2c76bd8b4023531f4fb9bf22176e4d6bd92dfa88 Author: Angelo Compagnucci Date: Wed Feb 4 15:14:26 2015 +0100 iio:adc:mcp3422 Fix incorrect scales table commit 9e128ced3851d2802b6db870f6b2e93f449ce013 upstream. This patch fixes uncorrect order of mcp3422_scales table, the values was erroneously transposed. It removes also an unused array and a wrong comment. Signed-off-by: Angelo Compagnucci Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 328499bcb4176cbcd99e60d12d3320f356241540 Author: Urs Fässler Date: Mon Feb 2 17:12:23 2015 +0100 iio: ad5686: fix optional reference voltage declaration commit da019f59cb16570e78feaf10380ac65a3a06861e upstream. When not using the "_optional" function, a dummy regulator is returned and the driver fails to initialize. Signed-off-by: Urs Fässler Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 30fa0dbf6757fd3c7ecb035583beba3169654e4e Author: Kristina Martšenko Date: Sun Jan 25 18:28:22 2015 +0200 iio: mxs-lradc: only update the buffer when its conversions have finished commit 89bb35e200bee745c539a96666e0792301ca40f1 upstream. Using the touchscreen while running buffered capture results in the buffer reporting lots of wrong values, often just zeros. This is because we push readings to the buffer every time a touchscreen interrupt arrives, including when the buffer's own conversions have not yet finished. So let's only push to the buffer when its conversions are ready. Signed-off-by: Kristina Martšenko Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9f074c6a2d50b9717d4aea50f7cdad87133dac5b Author: Kristina Martšenko Date: Sun Jan 25 18:28:21 2015 +0200 iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions commit 6abe0300a1d5242f4ff89257197f284679af1a06 upstream. Reading a channel through sysfs, or starting a buffered capture, can occasionally turn off the touchscreen. This is because the read_raw() and buffer preenable()/postdisable() callbacks unschedule current conversions on all channels. If a delay channel happens to schedule a touchscreen conversion at the same time, the conversion gets cancelled and the touchscreen sequence stops. This is probably related to this note from the reference manual: "If a delay group schedules channels to be sampled and a manual write to the schedule field in CTRL0 occurs while the block is discarding samples, the LRADC will switch to the new schedule and will not sample the channels that were previously scheduled. The time window for this to happen is very small and lasts only while the LRADC is discarding samples." So make the callbacks only unschedule conversions for the channels they use. This means channel 0 for read_raw() and channels 0-5 for the buffer (if the touchscreen is enabled). Since the touchscreen uses different channels (6 and 7), it no longer gets turned off. This is tested and fixes the issue on i.MX28, but hasn't been tested on i.MX23. Signed-off-by: Kristina Martšenko Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1322dc3bad902aa868071900edf8f217cb834d2b Author: Kristina Martšenko Date: Sun Jan 25 18:28:20 2015 +0200 iio: mxs-lradc: make ADC reads not disable touchscreen interrupts commit 86bf7f3ef7e961e91e16dceb31ae0f583483b204 upstream. Reading a channel through sysfs, or starting a buffered capture, will currently turn off the touchscreen. This is because the read_raw() and buffer preenable()/postdisable() callbacks disable interrupts for all LRADC channels, including those the touchscreen uses. So make the callbacks only disable interrupts for the channels they use. This means channel 0 for read_raw() and channels 0-5 for the buffer (if the touchscreen is enabled). Since the touchscreen uses different channels (6 and 7), it no longer gets turned off. Note that only i.MX28 is affected by this issue, i.MX23 should be fine. Signed-off-by: Kristina Martšenko Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 567a6d5e273d6db8a18abc4a62fa128c7b5fb6a8 Author: Kristina Martšenko Date: Sun Jan 25 18:28:19 2015 +0200 iio: mxs-lradc: separate touchscreen and buffer virtual channels commit f81197b8a31b8fb287ae57f597b5b6841e1ece92 upstream. The touchscreen was initially designed [1] to map all of its physical channels to one virtual channel, leaving buffered capture to use the remaining 7 virtual channels. When the touchscreen was reimplemented [2], it was made to use four virtual channels, which overlap and conflict with the channels the buffer uses. As a result, when the buffer is enabled, the touchscreen's virtual channels are remapped to whichever physical channels the buffer was configured with, causing the touchscreen to read those instead of the touch measurement channels. Effectively the touchscreen stops working. So here we separate the channels again, giving the touchscreen 2 virtual channels and the buffer 6. We can't give the touchscreen just 1 channel as before, as the current pressure calculation requires 2 channels to be read at the same time. This makes the touchscreen continue to work during buffered capture. It has been tested on i.MX28, but not on i.MX23. [1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen") [2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection") Signed-off-by: Kristina Martšenko Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c0d65db7de554c63952c20eb412e31af454537e5 Author: Rasmus Villemoes Date: Fri Jan 23 00:34:02 2015 +0100 iio: imu: adis16400: Fix sign extension commit 19e353f2b344ad86cea6ebbc0002e5f903480a90 upstream. The intention is obviously to sign-extend a 12 bit quantity. But because of C's promotion rules, the assignment is equivalent to "val16 &= 0xfff;". Use the proper API for this. Signed-off-by: Rasmus Villemoes Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ec23c856a5102f8a54ff6a376722536c4afb49b1 Author: Stefan Wahren Date: Sat Jan 3 20:34:12 2015 +0000 iio: mxs-lradc: fix iio channel map regression commit 03305e535cd5cdc1079b32909bf4b2dd67d46f7f upstream. Since commit c8231a9af8147f8a ("iio: mxs-lradc: compute temperature from channel 8 and 9") with the removal of adc channel 9 there is no 1-1 mapping in the channel spec. All hwmon channel values above 9 are accessible via there index minus one. So add a hidden iio channel 9 to fix this issue. Signed-off-by: Stefan Wahren Acked-by: Alexandre Belloni Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 6ddd115f4c15c2fe03bc2e214c3c95a9626156e2 Author: Quentin Casasnovas Date: Thu Mar 5 13:19:22 2015 +0100 x86/fpu/xsaves: Fix improper uses of __ex_table commit 06c8173eb92bbfc03a0fe8bb64315857d0badd06 upstream. Commit: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") introduced alternative instructions for XSAVES/XRSTORS and commit: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time") added support for the XSAVES/XRSTORS instructions at boot time. Unfortunately both failed to properly protect them against faulting: The 'xstate_fault' macro will use the closest label named '1' backward and that ends up in the .altinstr_replacement section rather than in .text. This means that the kernel will never find in the __ex_table the .text address where this instruction might fault, leading to serious problems if userspace manages to trigger the fault. Signed-off-by: Quentin Casasnovas Signed-off-by: Jamie Iles [ Improved the changelog, fixed some whitespace noise. ] Acked-by: Borislav Petkov Acked-by: Linus Torvalds Cc: Allan Xavier Cc: H. Peter Anvin Cc: Thomas Gleixner Fixes: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time") Fixes: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ce5dd33cbf06346752eeb5530e135d953d6b7abb Author: Andy Lutomirski Date: Thu Mar 5 01:09:44 2015 +0100 x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization commit 956421fbb74c3a6261903f3836c0740187cf038b upstream. 'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and the related state make sense for 'ret_from_sys_call'. This is entirely the wrong check. TS_COMPAT would make a little more sense, but there's really no point in keeping this optimization at all. This fixes a return to the wrong user CS if we came from int 0x80 in a 64-bit task. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net [ Backported from tip:x86/asm. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit cdc937a511477545ede5dd55a2ef9eca6f2f3b56 Author: Nicholas Bellinger Date: Fri Feb 13 22:27:40 2015 +0000 target: Check for LBA + sectors wrap-around in sbc_parse_cdb commit aa179935edea9a64dec4b757090c8106a3907ffa upstream. This patch adds a check to sbc_parse_cdb() in order to detect when an LBA + sector vs. end-of-device calculation wraps when the LBA is sufficently large enough (eg: 0xFFFFFFFFFFFFFFFF). Cc: Martin Petersen Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit f38a130bffe1b699bd9ac9ce89f19ccff31d97b5 Author: Nicholas Bellinger Date: Fri Feb 13 22:09:47 2015 +0000 target: Add missing WRITE_SAME end-of-device sanity check commit 8e575c50a171f2579e367a7f778f86477dfdaf49 upstream. This patch adds a check to sbc_setup_write_same() to verify the incoming WRITE_SAME LBA + number of blocks does not exceed past the end-of-device. Also check for potential LBA wrap-around as well. Reported-by: Bart Van Assche Cc: Martin Petersen Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit aff40baf1dc0c562918b866e66274c94b0f87c23 Author: Nicholas Bellinger Date: Wed Feb 11 18:34:40 2015 -0800 target: Fix PR_APTPL_BUF_LEN buffer size limitation commit f161d4b44d7cc1dc66b53365215227db356378b1 upstream. This patch addresses the original PR_APTPL_BUF_LEN = 8k limitiation for write-out of PR APTPL metadata that Martin has recently been running into. It changes core_scsi3_update_and_write_aptpl() to use vzalloc'ed memory instead of kzalloc, and increases the default hardcoded length to 256k. It also adds logic in core_scsi3_update_and_write_aptpl() to double the original length upon core_scsi3_update_aptpl_buf() failure, and retries until the vzalloc'ed buffer is large enough to accommodate the outgoing APTPL metadata. Reported-by: Martin Svec Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit e12d499e9a51646d5ded2c1d108a3f2ff838cc88 Author: Shobhit Kumar Date: Thu Feb 5 17:10:56 2015 +0530 drm/i915: Correct the IOSF Dev_FN field for IOSF transfers commit d180d2bbb66579e3bf449642b8ec2a76f4014fcd upstream. As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target device and not the source. So PCI_DEVFN(2,0) is not correct. Further the port ID should be enough to identify devices unless they are MFD. The SB_DevFn was intended to remove ambiguity in case of these MFD devices. For non MFD devices the recommendation for the target device IP was to ignore these fields, but not all of them followed the recommendation. Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0). It turned out that this did not follow the recommendation and expected 0 in this field. In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for all devices except target PCI devices. Signed-off-by: Shobhit Kumar Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 5c8bf2b80c3d002b8fb5b76cd6f112da69fc0cc9 Author: Michał Winiarski Date: Tue Feb 3 15:48:17 2015 +0100 drm/i915: Prevent use-after-free in invalidate_range_start callback commit 460822b0b1a77db859b0320469799fa4dbe4d367 upstream. It's possible for invalidate_range_start mmu notifier callback to race against userptr object release. If the gem object was released prior to obtaining the spinlock in invalidate_range_start we're hitting null pointer dereference. Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap Cc: Chris Wilson Signed-off-by: Michał Winiarski Reviewed-by: Chris Wilson [Jani: added code comment suggested by Chris] Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 4182c01b2586909366f48bcd498b8ca1de196898 Author: Daniel Vetter Date: Mon Nov 24 16:54:11 2014 +0100 drm/i915: Drop vblank wait from intel_dp_link_down commit 0ca09685546fed5fc8f0535204f0626f352140f4 upstream. Nothing in Bspec seems to indicate that we actually needs this, and it looks like can't work since by this point the pipe is off and so vblanks won't really happen any more. Note that Bspec mentions that it takes a vblank for this bit to change, but _only_ when enabling. Dropping this code quenches an annoying backtrace introduced by the more anal checking since commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait Note: This fixes the fallout from the above commit, but does not address the shortcomings of the IBX transcoder select workaround implementation discussed during review [1]. [1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095 Signed-off-by: Daniel Vetter Reviewed-by: Paulo Zanoni Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 2de5e09aaf489002fc903c0c83e09e016f9584b0 Author: Chris Wilson Date: Thu Jan 22 13:42:00 2015 +0000 drm/i915: Insert a command barrier on BLT/BSD cache flushes commit f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf upstream. This looked like an odd regression from commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b Author: Chris Wilson Date: Thu Jun 12 10:28:55 2014 +0100 drm/i915: Restrict GPU boost to the RCS engine but in reality it undercovered a much older coherency bug. The issue that boosting the GPU frequency on the BCS ring was masking was that we could wake the CPU up after completion of a BCS batch and inspect memory prior to the write cache being fully evicted. In order to serialise the breadcrumb interrupt (and so ensure that the CPU's view of memory is coherent) we need to perform a post-sync operation in the MI_FLUSH_DW. v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists). Also fix the invalidate_domains mask in gen8_emit_flush() for ring != VCS. Testcase: gpuX-rcs-gpu-read-after-write Signed-off-by: Chris Wilson Acked-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 93fd529dd1bc4263c9a993cc6172a257d7b90878 Author: Alex Deucher Date: Thu Feb 12 00:40:58 2015 -0500 drm/radeon: fix voltage setup on hawaii commit 09b6e85fc868568e1b2820235a2a851aecbccfcc upstream. Missing parameter when fetching the real voltage values from atom. Fixes problems with dynamic clocking on certain boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87457 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c112fd14870e43f1b5bd8f5e055c59f185a44ba9 Author: Alex Deucher Date: Wed Feb 11 18:34:36 2015 -0500 drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary commit 66c2b84ba6256bc5399eed45582af9ebb3ba2c15 upstream. Don't restrict it to just eDP panels. Some LVDS bridge chips require this. Fixes blank panels on resume on certain laptops. Noticed by mrnuke on IRC. bug: https://bugs.freedesktop.org/show_bug.cgi?id=42960 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5b7776747be61db9b5f6830fa371a4247bde369b Author: Christian König Date: Tue Feb 10 14:26:39 2015 +0100 drm/radeon: workaround for CP HW bug on CIK commit a9c73a0e022c33954835e66fec3cd744af90ec98 upstream. Emit the EOP twice to avoid cache flushing problems. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fee477d50fbec786a0068992f615b771eba24063 Author: Alex Deucher Date: Fri Feb 6 12:53:27 2015 -0500 drm/radeon: only enable kv/kb dpm interrupts once v3 commit 410af8d7285a0b96314845c75c39fd612b755688 upstream. Enable at init and disable on fini. Workaround for hardware problems. v2 (chk): extend commit message v3: add new function Signed-off-by: Alex Deucher Signed-off-by: Christian König (v2) Signed-off-by: Sasha Levin commit 22d4d7e79636d9af15366ab44f6bbb9cd807d069 Author: Michel Dänzer Date: Wed Feb 4 10:19:51 2015 +0900 drm/radeon: Don't try to enable write-combining without PAT commit a53fa43873b88bad15a2eb1f01dc5efa689625ce upstream. Doing so can cause things to become slow. Print a warning at compile time and an informative message at runtime in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758 Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c5131a9810621121fcd320ed40ddad5f5939d662 Author: David Ung Date: Tue Jan 20 18:37:35 2015 -0800 drm/tegra: Use correct relocation target offsets commit 31f40f86526b71009973854c1dfe799ee70f7588 upstream. When copying a relocation from userspace, copy the correct target offset. Signed-off-by: David Ung Fixes: 961e3beae3b2 ("drm/tegra: Make job submission 64-bit safe") [treding@nvidia.com: provide a better commit message] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b7c386cf63c54ae1d569e0708f6fb6b36f58c377 Author: Hugh Dickins Date: Thu Feb 12 15:00:28 2015 -0800 mm: fix negative nr_isolated counts commit ff59909a077b3c51c168cb658601c6b63136a347 upstream. The vmstat interfaces are good at hiding negative counts (at least when CONFIG_SMP); but if you peer behind the curtain, you find that nr_isolated_anon and nr_isolated_file soon go negative, and grow ever more negative: so they can absorb larger and larger numbers of isolated pages, yet still appear to be zero. I'm happy to avoid a congestion_wait() when too_many_isolated() myself; but I guess it's there for a good reason, in which case we ought to get too_many_isolated() working again. The imbalance comes from isolate_migratepages()'s ISOLATE_ABORT case: putback_movable_pages() decrements the NR_ISOLATED counts, but we forgot to call acct_isolated() to increment them. It is possible that the bug whcih this patch fixes could cause OOM kills when the system still has a lot of reclaimable page cache. Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from isolate_migratepages_range()") Signed-off-by: Hugh Dickins Acked-by: Vlastimil Babka Acked-by: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 463fb5a2cc7013f50763ee2322fa724553150842 Author: Grazvydas Ignotas Date: Thu Feb 12 15:00:19 2015 -0800 mm/memory.c: actually remap enough memory commit 9cb12d7b4ccaa976f97ce0c5fd0f1b6a83bc2a75 upstream. For whatever reason, generic_access_phys() only remaps one page, but actually allows to access arbitrary size. It's quite easy to trigger large reads, like printing out large structure with gdb, which leads to a crash. Fix it by remapping correct size. Fixes: 28b2ee20c7cb ("access_process_vm device memory infrastructure") Signed-off-by: Grazvydas Ignotas Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 42af81da88243ea738bc3b13c3120b80b6687a07 Author: Joonsoo Kim Date: Thu Feb 12 14:59:50 2015 -0800 mm/compaction: fix wrong order check in compact_finished() commit 372549c2a3778fd3df445819811c944ad54609ca upstream. What we want to check here is whether there is highorder freepage in buddy list of other migratetype in order to steal it without fragmentation. But, current code just checks cc->order which means allocation request order. So, this is wrong. Without this fix, non-movable synchronous compaction below pageblock order would not stopped until compaction is complete, because migratetype of most pageblocks are movable and high order freepage made by compaction is usually on movable type buddy list. There is some report related to this bug. See below link. http://www.spinics.net/lists/linux-mm/msg81666.html Although the issued system still has load spike comes from compaction, this makes that system completely stable and responsive according to his report. stress-highalloc test in mmtests with non movable order 7 allocation doesn't show any notable difference in allocation success rate, but, it shows more compaction success rate. Compaction success rate (Compaction success * 100 / Compaction stalls, %) 18.47 : 28.94 Fixes: 1fb3f8ca0e92 ("mm: compaction: capture a suitable high-order page immediately when it is made available") Signed-off-by: Joonsoo Kim Acked-by: Vlastimil Babka Reviewed-by: Zhang Yanfei Cc: Mel Gorman Cc: David Rientjes Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f0f7d8f66583963ada258eb446b2a829f9ae7ec8 Author: Roman Gushchin Date: Wed Feb 11 15:28:42 2015 -0800 mm/nommu.c: fix arithmetic overflow in __vm_enough_memory() commit 8138a67a5557ffea3a21dfd6f037842d4e748513 upstream. I noticed that "allowed" can easily overflow by falling below 0, because (total_vm / 32) can be larger than "allowed". The problem occurs in OVERCOMMIT_NONE mode. In this case, a huge allocation can success and overcommit the system (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall (system-wide), so system become unusable. The problem was masked out by commit c9b1d0981fcc ("mm: limit growth of 3% hardcoded other user reserve"), but it's easy to reproduce it on older kernels: 1) set overcommit_memory sysctl to 2 2) mmap() large file multiple times (with VM_SHARED flag) 3) try to malloc() large amount of memory It also can be reproduced on newer kernels, but miss-configured sysctl_user_reserve_kbytes is required. Fix this issue by switching to signed arithmetic here. Signed-off-by: Roman Gushchin Cc: Andrew Shewmaker Cc: Rik van Riel Cc: Konstantin Khlebnikov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 64ac32052a49d485cb8e2bc6dca17a1d82917fdc Author: Roman Gushchin Date: Wed Feb 11 15:28:39 2015 -0800 mm/mmap.c: fix arithmetic overflow in __vm_enough_memory() commit 5703b087dc8eaf47bfb399d6cf512d471beff405 upstream. I noticed, that "allowed" can easily overflow by falling below 0, because (total_vm / 32) can be larger than "allowed". The problem occurs in OVERCOMMIT_NONE mode. In this case, a huge allocation can success and overcommit the system (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall (system-wide), so system become unusable. The problem was masked out by commit c9b1d0981fcc ("mm: limit growth of 3% hardcoded other user reserve"), but it's easy to reproduce it on older kernels: 1) set overcommit_memory sysctl to 2 2) mmap() large file multiple times (with VM_SHARED flag) 3) try to malloc() large amount of memory It also can be reproduced on newer kernels, but miss-configured sysctl_user_reserve_kbytes is required. Fix this issue by switching to signed arithmetic here. [akpm@linux-foundation.org: use min_t] Signed-off-by: Roman Gushchin Cc: Andrew Shewmaker Cc: Rik van Riel Cc: Konstantin Khlebnikov Reviewed-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8473518c0756c4ddebbb2f999d36568e43d5e87c Author: Vlastimil Babka Date: Wed Feb 11 15:28:15 2015 -0800 mm: when stealing freepages, also take pages created by splitting buddy page commit 99592d598eca62bdbbf62b59941c189176dfc614 upstream. When studying page stealing, I noticed some weird looking decisions in try_to_steal_freepages(). The first I assume is a bug (Patch 1), the following two patches were driven by evaluation. Testing was done with stress-highalloc of mmtests, using the mm_page_alloc_extfrag tracepoint and postprocessing to get counts of how often page stealing occurs for individual migratetypes, and what migratetypes are used for fallbacks. Arguably, the worst case of page stealing is when UNMOVABLE allocation steals from MOVABLE pageblock. RECLAIMABLE allocation stealing from MOVABLE allocation is also not ideal, so the goal is to minimize these two cases. The evaluation of v2 wasn't always clear win and Joonsoo questioned the results. Here I used different baseline which includes RFC compaction improvements from [1]. I found that the compaction improvements reduce variability of stress-highalloc, so there's less noise in the data. First, let's look at stress-highalloc configured to do sync compaction, and how these patches reduce page stealing events during the test. First column is after fresh reboot, other two are reiterations of test without reboot. That was all accumulater over 5 re-iterations (so the benchmark was run 5x3 times with 5 fresh restarts). Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-nothp-1 5-nothp-2 5-nothp-3 Page alloc extfrag event 10264225 8702233 10244125 Extfrag fragmenting 10263271 8701552 10243473 Extfrag fragmenting for unmovable 13595 17616 15960 Extfrag fragmenting unmovable placed with movable 7989 12193 8447 Extfrag fragmenting for reclaimable 658 1840 1817 Extfrag fragmenting reclaimable placed with movable 558 1677 1679 Extfrag fragmenting for movable 10249018 8682096 10225696 With Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-nothp-1 6-nothp-2 6-nothp-3 Page alloc extfrag event 11834954 9877523 9774860 Extfrag fragmenting 11833993 9876880 9774245 Extfrag fragmenting for unmovable 7342 16129 11712 Extfrag fragmenting unmovable placed with movable 4191 10547 6270 Extfrag fragmenting for reclaimable 373 1130 923 Extfrag fragmenting reclaimable placed with movable 302 906 738 Extfrag fragmenting for movable 11826278 9859621 9761610 With Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-nothp-1 7-nothp-2 7-nothp-3 Page alloc extfrag event 4725990 3668793 3807436 Extfrag fragmenting 4725104 3668252 3806898 Extfrag fragmenting for unmovable 6678 7974 7281 Extfrag fragmenting unmovable placed with movable 2051 3829 4017 Extfrag fragmenting for reclaimable 429 1208 1278 Extfrag fragmenting reclaimable placed with movable 369 976 1034 Extfrag fragmenting for movable 4717997 3659070 3798339 With Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-nothp-1 8-nothp-2 8-nothp-3 Page alloc extfrag event 5016183 4700142 3850633 Extfrag fragmenting 5015325 4699613 3850072 Extfrag fragmenting for unmovable 1312 3154 3088 Extfrag fragmenting unmovable placed with movable 1115 2777 2714 Extfrag fragmenting for reclaimable 437 1193 1097 Extfrag fragmenting reclaimable placed with movable 330 969 879 Extfrag fragmenting for movable 5013576 4695266 3845887 In v2 we've seen apparent regression with Patch 1 for unmovable events, this is now gone, suggesting it was indeed noise. Here, each patch improves the situation for unmovable events. Reclaimable is improved by patch 1 and then either the same modulo noise, or perhaps sligtly worse - a small price for unmovable improvements, IMHO. The number of movable allocations falling back to other migratetypes is most noisy, but it's reduced to half at Patch 2 nevertheless. These are least critical as compaction can move them around. If we look at success rates, the patches don't affect them, that didn't change. Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-nothp-1 5-nothp-2 5-nothp-3 Success 1 Min 49.00 ( 0.00%) 42.00 ( 14.29%) 41.00 ( 16.33%) Success 1 Mean 51.00 ( 0.00%) 45.00 ( 11.76%) 42.60 ( 16.47%) Success 1 Max 55.00 ( 0.00%) 51.00 ( 7.27%) 46.00 ( 16.36%) Success 2 Min 53.00 ( 0.00%) 47.00 ( 11.32%) 44.00 ( 16.98%) Success 2 Mean 59.60 ( 0.00%) 50.80 ( 14.77%) 48.20 ( 19.13%) Success 2 Max 64.00 ( 0.00%) 56.00 ( 12.50%) 52.00 ( 18.75%) Success 3 Min 84.00 ( 0.00%) 82.00 ( 2.38%) 78.00 ( 7.14%) Success 3 Mean 85.60 ( 0.00%) 82.80 ( 3.27%) 79.40 ( 7.24%) Success 3 Max 86.00 ( 0.00%) 83.00 ( 3.49%) 80.00 ( 6.98%) Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-nothp-1 6-nothp-2 6-nothp-3 Success 1 Min 49.00 ( 0.00%) 44.00 ( 10.20%) 44.00 ( 10.20%) Success 1 Mean 51.80 ( 0.00%) 46.00 ( 11.20%) 45.80 ( 11.58%) Success 1 Max 54.00 ( 0.00%) 49.00 ( 9.26%) 49.00 ( 9.26%) Success 2 Min 58.00 ( 0.00%) 49.00 ( 15.52%) 48.00 ( 17.24%) Success 2 Mean 60.40 ( 0.00%) 51.80 ( 14.24%) 50.80 ( 15.89%) Success 2 Max 63.00 ( 0.00%) 54.00 ( 14.29%) 55.00 ( 12.70%) Success 3 Min 84.00 ( 0.00%) 81.00 ( 3.57%) 79.00 ( 5.95%) Success 3 Mean 85.00 ( 0.00%) 81.60 ( 4.00%) 79.80 ( 6.12%) Success 3 Max 86.00 ( 0.00%) 82.00 ( 4.65%) 82.00 ( 4.65%) Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-nothp-1 7-nothp-2 7-nothp-3 Success 1 Min 50.00 ( 0.00%) 44.00 ( 12.00%) 39.00 ( 22.00%) Success 1 Mean 52.80 ( 0.00%) 45.60 ( 13.64%) 42.40 ( 19.70%) Success 1 Max 55.00 ( 0.00%) 46.00 ( 16.36%) 47.00 ( 14.55%) Success 2 Min 52.00 ( 0.00%) 48.00 ( 7.69%) 45.00 ( 13.46%) Success 2 Mean 53.40 ( 0.00%) 49.80 ( 6.74%) 48.80 ( 8.61%) Success 2 Max 57.00 ( 0.00%) 52.00 ( 8.77%) 52.00 ( 8.77%) Success 3 Min 84.00 ( 0.00%) 81.00 ( 3.57%) 79.00 ( 5.95%) Success 3 Mean 85.00 ( 0.00%) 82.40 ( 3.06%) 79.60 ( 6.35%) Success 3 Max 86.00 ( 0.00%) 83.00 ( 3.49%) 80.00 ( 6.98%) Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-nothp-1 8-nothp-2 8-nothp-3 Success 1 Min 46.00 ( 0.00%) 44.00 ( 4.35%) 42.00 ( 8.70%) Success 1 Mean 50.20 ( 0.00%) 45.60 ( 9.16%) 44.00 ( 12.35%) Success 1 Max 52.00 ( 0.00%) 47.00 ( 9.62%) 47.00 ( 9.62%) Success 2 Min 53.00 ( 0.00%) 49.00 ( 7.55%) 48.00 ( 9.43%) Success 2 Mean 55.80 ( 0.00%) 50.60 ( 9.32%) 49.00 ( 12.19%) Success 2 Max 59.00 ( 0.00%) 52.00 ( 11.86%) 51.00 ( 13.56%) Success 3 Min 84.00 ( 0.00%) 80.00 ( 4.76%) 79.00 ( 5.95%) Success 3 Mean 85.40 ( 0.00%) 81.60 ( 4.45%) 80.40 ( 5.85%) Success 3 Max 87.00 ( 0.00%) 83.00 ( 4.60%) 82.00 ( 5.75%) While there's no improvement here, I consider reduced fragmentation events to be worth on its own. Patch 2 also seems to reduce scanning for free pages, and migrations in compaction, suggesting it has somewhat less work to do: Patch 1: Compaction stalls 4153 3959 3978 Compaction success 1523 1441 1446 Compaction failures 2630 2517 2531 Page migrate success 4600827 4943120 5104348 Page migrate failure 19763 16656 17806 Compaction pages isolated 9597640 10305617 10653541 Compaction migrate scanned 77828948 86533283 87137064 Compaction free scanned 517758295 521312840 521462251 Compaction cost 5503 5932 6110 Patch 2: Compaction stalls 3800 3450 3518 Compaction success 1421 1316 1317 Compaction failures 2379 2134 2201 Page migrate success 4160421 4502708 4752148 Page migrate failure 19705 14340 14911 Compaction pages isolated 8731983 9382374 9910043 Compaction migrate scanned 98362797 96349194 98609686 Compaction free scanned 496512560 469502017 480442545 Compaction cost 5173 5526 5811 As with v2, /proc/pagetypeinfo appears unaffected with respect to numbers of unmovable and reclaimable pageblocks. Configuring the benchmark to allocate like THP page fault (i.e. no sync compaction) gives much noisier results for iterations 2 and 3 after reboot. This is not so surprising given how [1] offers lower improvements in this scenario due to less restarts after deferred compaction which would change compaction pivot. Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-thp-1 5-thp-2 5-thp-3 Page alloc extfrag event 8148965 6227815 6646741 Extfrag fragmenting 8147872 6227130 6646117 Extfrag fragmenting for unmovable 10324 12942 15975 Extfrag fragmenting unmovable placed with movable 5972 8495 10907 Extfrag fragmenting for reclaimable 601 1707 2210 Extfrag fragmenting reclaimable placed with movable 520 1570 2000 Extfrag fragmenting for movable 8136947 6212481 6627932 Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-thp-1 6-thp-2 6-thp-3 Page alloc extfrag event 8345457 7574471 7020419 Extfrag fragmenting 8343546 7573777 7019718 Extfrag fragmenting for unmovable 10256 18535 30716 Extfrag fragmenting unmovable placed with movable 6893 11726 22181 Extfrag fragmenting for reclaimable 465 1208 1023 Extfrag fragmenting reclaimable placed with movable 353 996 843 Extfrag fragmenting for movable 8332825 7554034 6987979 Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-thp-1 7-thp-2 7-thp-3 Page alloc extfrag event 3512847 3020756 2891625 Extfrag fragmenting 3511940 3020185 2891059 Extfrag fragmenting for unmovable 9017 6892 6191 Extfrag fragmenting unmovable placed with movable 1524 3053 2435 Extfrag fragmenting for reclaimable 445 1081 1160 Extfrag fragmenting reclaimable placed with movable 375 918 986 Extfrag fragmenting for movable 3502478 3012212 2883708 Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-thp-1 8-thp-2 8-thp-3 Page alloc extfrag event 3181699 3082881 2674164 Extfrag fragmenting 3180812 3082303 2673611 Extfrag fragmenting for unmovable 1201 4031 4040 Extfrag fragmenting unmovable placed with movable 974 3611 3645 Extfrag fragmenting for reclaimable 478 1165 1294 Extfrag fragmenting reclaimable placed with movable 387 985 1030 Extfrag fragmenting for movable 3179133 3077107 2668277 The improvements for first iteration are clear, the rest is much noisier and can appear like regression for Patch 1. Anyway, patch 2 rectifies it. Allocation success rates are again unaffected so there's no point in making this e-mail any longer. [1] http://marc.info/?l=linux-mm&m=142166196321125&w=2 This patch (of 3): When __rmqueue_fallback() is called to allocate a page of order X, it will find a page of order Y >= X of a fallback migratetype, which is different from the desired migratetype. With the help of try_to_steal_freepages(), it may change the migratetype (to the desired one) also of: 1) all currently free pages in the pageblock containing the fallback page 2) the fallback pageblock itself 3) buddy pages created by splitting the fallback page (when Y > X) These decisions take the order Y into account, as well as the desired migratetype, with the goal of preventing multiple fallback allocations that could e.g. distribute UNMOVABLE allocations among multiple pageblocks. Originally, decision for 1) has implied the decision for 3). Commit 47118af076f6 ("mm: mmzone: MIGRATE_CMA migration type added") changed that (probably unintentionally) so that the buddy pages in case 3) are always changed to the desired migratetype, except for CMA pageblocks. Commit fef903efcf0c ("mm/page_allo.c: restructure free-page stealing code and fix a bug") did some refactoring and added a comment that the case of 3) is intended. Commit 0cbef29a7821 ("mm: __rmqueue_fallback() should respect pageblock type") removed the comment and tried to restore the original behavior where 1) implies 3), but due to the previous refactoring, the result is instead that only 2) implies 3) - and the conditions for 2) are less frequently met than conditions for 1). This may increase fragmentation in situations where the code decides to steal all free pages from the pageblock (case 1)), but then gives back the buddy pages produced by splitting. This patch restores the original intended logic where 1) implies 3). During testing with stress-highalloc from mmtests, this has shown to decrease the number of events where UNMOVABLE and RECLAIMABLE allocations steal from MOVABLE pageblocks, which can lead to permanent fragmentation. In some cases it has increased the number of events when MOVABLE allocations steal from UNMOVABLE or RECLAIMABLE pageblocks, but these are fixable by sync compaction and thus less harmful. Note that evaluation has shown that the behavior introduced by 47118af076f6 for buddy pages in case 3) is actually even better than the original logic, so the following patch will introduce it properly once again. For stable backports of this patch it makes thus sense to only fix versions containing 0cbef29a7821. [iamjoonsoo.kim@lge.com: tracepoint fix] Signed-off-by: Vlastimil Babka Acked-by: Mel Gorman Cc: Zhang Yanfei Acked-by: Minchan Kim Cc: David Rientjes Cc: Rik van Riel Cc: "Aneesh Kumar K.V" Cc: "Kirill A. Shutemov" Cc: Johannes Weiner Cc: Joonsoo Kim Cc: Michal Hocko Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6f59e648688b38af6144a81e1d493f33cd2fe6f1 Author: Andrey Ryabinin Date: Tue Feb 10 14:11:33 2015 -0800 mm, hugetlb: remove unnecessary lower bound on sysctl handlers"? commit 3cd7645de624939c38f5124b4ac15f8b35a1a8b7 upstream. Commit ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity") replaced 'unsigned long hugetlb_zero' with 'int zero' leading to out-of-bounds access in proc_doulongvec_minmax(). Use '.extra1 = NULL' instead of '.extra1 = &zero'. Passing NULL is equivalent to passing minimal value, which is 0 for unsigned types. Fixes: ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity") Signed-off-by: Andrey Ryabinin Reported-by: Dmitry Vyukov Suggested-by: Manfred Spraul Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ac369918c6c1eca4c3b99761d2299d8df9e7bffb Author: Naoya Horiguchi Date: Wed Feb 11 15:25:32 2015 -0800 mm/hugetlb: add migration entry check in __unmap_hugepage_range commit 9fbc1f635fd0bd28cb32550211bf095753ac637a upstream. If __unmap_hugepage_range() tries to unmap the address range over which hugepage migration is on the way, we get the wrong page because pte_page() doesn't work for migration entries. This patch simply clears the pte for migration entries as we do for hwpoison entries. Fixes: 290408d4a2 ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi Cc: Hugh Dickins Cc: James Hogan Cc: David Rientjes Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Rik van Riel Cc: Andrea Arcangeli Cc: Luiz Capitulino Cc: Nishanth Aravamudan Cc: Lee Schermerhorn Cc: Steve Capper Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fa94a396378ac95ae47e97dfea9e740305aba255 Author: Naoya Horiguchi Date: Wed Feb 11 15:25:28 2015 -0800 mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection commit a8bda28d87c38c6aa93de28ba5d30cc18e865a11 upstream. There is a race condition between hugepage migration and change_protection(), where hugetlb_change_protection() doesn't care about migration entries and wrongly overwrites them. That causes unexpected results like kernel crash. HWPoison entries also can cause the same problem. This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this function to do proper actions. Fixes: 290408d4a2 ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi Cc: Hugh Dickins Cc: James Hogan Cc: David Rientjes Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Rik van Riel Cc: Andrea Arcangeli Cc: Luiz Capitulino Cc: Nishanth Aravamudan Cc: Lee Schermerhorn Cc: Steve Capper Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 674eefded6e5188501d97443ea3830aafe565277 Author: Naoya Horiguchi Date: Wed Feb 11 15:25:25 2015 -0800 mm/hugetlb: fix getting refcount 0 page in hugetlb_fault() commit 0f792cf949a0be506c2aa8bfac0605746b146dda upstream. When running the test which causes the race as shown in the previous patch, we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault(). This race happens when pte turns into migration entry just after the first check of is_hugetlb_entry_migration() in hugetlb_fault() passed with false. To fix this, we need to check pte_present() again after huge_ptep_get(). This patch also reorders taking ptl and doing pte_page(), because pte_page() should be done in ptl. Due to this reordering, we need use trylock_page() in page != pagecache_page case to respect locking order. Fixes: 66aebce747ea ("hugetlb: fix race condition in hugetlb_fault()") Signed-off-by: Naoya Horiguchi Cc: Hugh Dickins Cc: James Hogan Cc: David Rientjes Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Rik van Riel Cc: Andrea Arcangeli Cc: Luiz Capitulino Cc: Nishanth Aravamudan Cc: Lee Schermerhorn Cc: Steve Capper Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c3b2b0df736920de3a188642d5d88e246ba780e0 Author: Jiri Pirko Date: Wed Mar 4 08:36:31 2015 +0100 team: don't traverse port list using rcu in team_set_mac_address [ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ] Currently the list is traversed using rcu variant. That is not correct since dev_set_mac_address can be called which eventually calls rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this by remove the rcu usage here. Fixes: 3d249d4ca7 "net: introduce ethernet teaming device" Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f009d6b5ebf8c31b89a71485e8d69819f69dbc3b Author: Lorenzo Colitti Date: Tue Mar 3 23:16:16 2015 +0900 net: ping: Return EAFNOSUPPORT when appropriate. [ Upstream commit 9145736d4862145684009d6a72a6e61324a9439e ] 1. For an IPv4 ping socket, ping_check_bind_addr does not check the family of the socket address that's passed in. Instead, make it behave like inet_bind, which enforces either that the address family is AF_INET, or that the family is AF_UNSPEC and the address is 0.0.0.0. 2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL if the socket family is not AF_INET6. Return EAFNOSUPPORT instead, for consistency with inet6_bind. 3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT instead of EINVAL if an incorrect socket address structure is passed in. 4. Make IPv6 ping sockets be IPv6-only. The code does not support IPv4, and it cannot easily be made to support IPv4 because the protocol numbers for ICMP and ICMPv6 are different. This makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead of making the socket unusable. Among other things, this fixes an oops that can be triggered by: int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP); struct sockaddr_in6 sin6 = { .sin6_family = AF_INET6, .sin6_addr = in6addr_any, }; bind(s, (struct sockaddr *) &sin6, sizeof(sin6)); Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241 Signed-off-by: Lorenzo Colitti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1b5d485e7ee3d5f2c1125783fb0434a4466b690a Author: Michal Kubeček Date: Mon Mar 2 18:27:11 2015 +0100 udp: only allow UFO for packets from SOCK_DGRAM sockets [ Upstream commit acf8dd0a9d0b9e4cdb597c2f74802f79c699e802 ] If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer checksum is to be computed on segmentation. However, in this case, skb->csum_start and skb->csum_offset are never set as raw socket transmit path bypasses udp_send_skb() where they are usually set. As a result, driver may access invalid memory when trying to calculate the checksum and store the result (as observed in virtio_net driver). Moreover, the very idea of modifying the userspace provided UDP header is IMHO against raw socket semantics (I wasn't able to find a document clearly stating this or the opposite, though). And while allowing CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit too intrusive change just to handle a corner case like this. Therefore disallowing UFO for packets from SOCK_DGRAM seems to be the best option. Signed-off-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af5b76c9f3c428c321045bdd1053a417ed250287 Author: Ben Shelton Date: Mon Feb 16 13:47:06 2015 -0600 usb: plusb: Add support for National Instruments host-to-host cable [ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ] The National Instruments USB Host-to-Host Cable is based on the Prolific PL-25A1 chipset. Add its VID/PID so the plusb driver will recognize it. Signed-off-by: Ben Shelton Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0972883e7e01533e368cb83a659ba7cb5c92d841 Author: Eric Dumazet Date: Fri Feb 27 09:42:50 2015 -0800 net: do not use rcu in rtnl_dump_ifinfo() [ Upstream commit cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ] We did a failed attempt in the past to only use rcu in rtnl dump operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during netlink dump callbacks") Now that dumps are holding RTNL anyway, there is no need to also use rcu locking, as it forbids any scheduling ability, like GFP_KERNEL allocations that controlling path should use instead of GFP_ATOMIC whenever possible. This should fix following splat Cong Wang reported : [ INFO: suspicious RCU usage. ] 3.19.0+ #805 Tainted: G W include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by ip/771: #0: (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x21/0x26c #1: (rcu_read_lock){......}, at: [] rcu_read_lock+0x0/0x6e stack backtrace: CPU: 3 PID: 771 Comm: ip Tainted: G W 3.19.0+ #805 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6 ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd 00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758 Call Trace: [] dump_stack+0x4c/0x65 [] lockdep_rcu_suspicious+0x107/0x110 [] rcu_preempt_sleep_check+0x45/0x47 [] ___might_sleep+0x1d/0x1cb [] __might_sleep+0x78/0x80 [] idr_alloc+0x45/0xd1 [] ? rcu_read_lock_held+0x3b/0x3d [] ? idr_for_each+0x53/0x101 [] alloc_netid+0x61/0x69 [] __peernet2id+0x79/0x8d [] peernet2id+0x13/0x1f [] rtnl_fill_ifinfo+0xa8d/0xc20 [] ? __lock_is_held+0x39/0x52 [] rtnl_dump_ifinfo+0x149/0x213 [] netlink_dump+0xef/0x26c [] netlink_recvmsg+0x17b/0x2c5 [] __sock_recvmsg+0x4e/0x59 [] sock_recvmsg+0x3f/0x51 [] ___sys_recvmsg+0xf6/0x1d9 [] ? handle_pte_fault+0x6e1/0xd3d [] ? native_sched_clock+0x35/0x37 [] ? sched_clock_local+0x12/0x72 [] ? sched_clock_cpu+0x9e/0xb7 [] ? rcu_read_lock_held+0x3b/0x3d [] ? __fcheck_files+0x4c/0x58 [] ? __fget_light+0x2d/0x52 [] __sys_recvmsg+0x42/0x60 [] SyS_recvmsg+0x12/0x1c Signed-off-by: Eric Dumazet Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids") Cc: Nicolas Dichtel Reported-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29db1c2ae7b445ae070ff2643f5c6cfaa508e22e Author: Jaedon Shin Date: Sat Feb 28 11:48:26 2015 +0900 net: bcmgenet: fix throughtput regression [ Upstream commit 4092e6acf5cb16f56154e2dd22d647023dc3d646 ] This patch adds bcmgenet_tx_poll for the tx_rings. This can reduce the interrupt load and send xmit in network stack on time. This also separated for the completion of tx_ring16 from bcmgenet_poll. The bcmgenet_tx_reclaim of tx_ring[{0,1,2,3}] operative by an interrupt is to be not more than a certain number TxBDs. It is caused by too slowly reclaiming the transmitted skb. Therefore, performance degradation of xmit after 605ad7f ("tcp: refine TSO autosizing"). Signed-off-by: Jaedon Shin Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e2aaa2c0534fc242c97c1c27bb230da85620eb00 Author: Eric Dumazet Date: Fri Feb 27 18:35:35 2015 -0800 macvtap: make sure neighbour code can push ethernet header [ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ] Brian reported crashes using IPv6 traffic with macvtap/veth combo. I tracked the crashes in neigh_hh_output() -> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD); Neighbour code assumes headroom to push Ethernet header is at least 16 bytes. It appears macvtap has only 14 bytes available on arches where NET_IP_ALIGN is 0 (like x86) Effect is a corruption of 2 bytes right before skb->head, and possible crashes if accessing non existing memory. This fix should also increase IPv4 performance, as paranoid code in ip_finish_output2() wont have to call skb_realloc_headroom() Reported-by: Brian Rak Tested-by: Brian Rak Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c03ec3e2d785de4a658962e37a619f1b40c23d5 Author: Catalin Marinas Date: Mon Feb 23 18:12:56 2015 +0000 net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send, recv}msg [ Upstream commit d720d8cec563ce4e4fa44a613d4f2dcb1caf2998 ] With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points, changing the kernel compat behaviour from the one before the commit it was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg). On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native 32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by the kernel). However, on a 64-bit kernel, the compat ABI is different with commit a7526eb5d06b. This patch changes the compat_sys_{send,recv}msg behaviour to the one prior to commit 1be374a0518a. The problem was found running 32-bit LTP (sendmsg01) binary on an arm64 kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg() but the general rule is not to break user ABI (even when the user behaviour is not entirely sane). Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg) Cc: Andy Lutomirski Cc: David S. Miller Signed-off-by: Catalin Marinas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 722243f16e3638d39a9ba0de8b170bcb4840b85d Author: Jiri Pirko Date: Mon Feb 23 14:02:54 2015 +0100 team: fix possible null pointer dereference in team_handle_frame [ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ] Currently following race is possible in team: CPU0 CPU1 team_port_del team_upper_dev_unlink priv_flags &= ~IFF_TEAM_PORT team_handle_frame team_port_get_rcu team_port_exists priv_flags & IFF_TEAM_PORT == 0 return NULL (instead of port got from rx_handler_data) netdev_rx_handler_unregister The thing is that the flag is removed before rx_handler is unregistered. If team_handle_frame is called in between, team_port_exists returns 0 and team_port_get_rcu will return NULL. So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister that team_handle_frame will always see valid rx_handler_data pointer. Signed-off-by: Jiri Pirko Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 539500104f37c687b525eef51efd5cee9efa1c7d Author: Eric Dumazet Date: Sun Feb 22 17:03:41 2015 -0800 net: pktgen: disable xmit_clone on virtual devices [ Upstream commit 52d6c8c6ca125872459054daa70f2f1c698c8e75 ] Trying to use burst capability (aka xmit_more) on a virtual device like bonding is not supported. For example, skb might be queued multiple times on a qdisc, with various list corruptions. Fixes: 38b2cf2982dc ("net: pktgen: packet bursting via skb->xmit_more") Signed-off-by: Eric Dumazet Cc: Alexei Starovoitov Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e7a29f315e8a644460e73109c42acc585aeb51e Author: David S. Miller Date: Tue Mar 10 18:47:33 2015 -0400 Revert "r8169: add support for Byte Queue Limits" This reverts commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6. Revert BQL support in r8169 driver as several regressions point to this commit and we cannot figure out the real cause yet. Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e664c2cc867cce095a7f07b3b3de614072aa7bb6 Author: Matthew Thode Date: Tue Feb 17 18:31:57 2015 -0600 net: reject creation of netdev names with colons [ Upstream commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ] colons are used as a separator in netdev device lookup in dev_ioctl.c Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME Signed-off-by: Matthew Thode Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4946f9d29794e6b5f2efc47eb6ac23b8bf9645f6 Author: Eric Dumazet Date: Wed Feb 18 05:47:55 2015 -0800 sock: sock_dequeue_err_skb() needs hard irq safety [ Upstream commit 997d5c3f4427f38562cbe207ce05bb25fdcb993b ] Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb() from hard IRQ context. Therefore, sock_dequeue_err_skb() needs to block hard irq or corruptions or hangs can happen. Signed-off-by: Eric Dumazet Fixes: 364a9e93243d1 ("sock: deduplicate errqueue dequeue") Fixes: cb820f8e4b7f7 ("net: Provide a generic socket error queue delivery method for Tx time stamps.") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 91f3fc9b4df473b8e1824fdd22147aa7c97f3042 Author: Pravin B Shelar Date: Tue Feb 17 11:23:10 2015 -0800 openvswitch: Fix net exit. [ Upstream commit 7b4577a9da3702049650f7095506e9afd9f68849 ] Open vSwitch allows moving internal vport to different namespace while still connected to the bridge. But when namespace deleted OVS does not detach these vports, that results in dangling pointer to netdevice which causes kernel panic as follows. This issue is fixed by detaching all ovs ports from the deleted namespace at net-exit. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] ovs_vport_locate+0x35/0x80 [openvswitch] Oops: 0000 [#1] SMP Call Trace: [] lookup_vport+0x21/0xd0 [openvswitch] [] ovs_vport_cmd_get+0x59/0xf0 [openvswitch] [] genl_family_rcv_msg+0x1bc/0x3e0 [] genl_rcv_msg+0x79/0xc0 [] netlink_rcv_skb+0xb9/0xe0 [] genl_rcv+0x2c/0x40 [] netlink_unicast+0x12d/0x1c0 [] netlink_sendmsg+0x34a/0x6b0 [] sock_sendmsg+0xa0/0xe0 [] ___sys_sendmsg+0x408/0x420 [] __sys_sendmsg+0x51/0x90 [] SyS_sendmsg+0x12/0x20 [] system_call_fastpath+0x12/0x17 Reported-by: Assaf Muller Fixes: 46df7b81454("openvswitch: Add support for network namespaces.") Signed-off-by: Pravin B Shelar Reviewed-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cbac74b71f36968c3b54a6c0d068defec3851b9b Author: Ignacy Gawędzki Date: Tue Feb 17 20:15:20 2015 +0100 ematch: Fix auto-loading of ematch modules. [ Upstream commit 34eea79e2664b314cab6a30fc582fdfa7a1bb1df ] In tcf_em_validate(), after calling request_module() to load the kind-specific module, set em->ops to NULL before returning -EAGAIN, so that module_put() is not called again by tcf_em_tree_destroy(). Signed-off-by: Ignacy Gawędzki Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e6aa677fd2f9ebc21b5b623be5a2a4088532dece Author: Guenter Roeck Date: Tue Feb 17 09:36:22 2015 -0800 net: phy: Fix verification of EEE support in phy_init_eee [ Upstream commit 54da5a8be3c1e924c35480eb44c6e9b275f6444e ] phy_init_eee uses phy_find_setting(phydev->speed, phydev->duplex) to find a valid entry in the settings array for the given speed and duplex value. For full duplex 1000baseT, this will return the first matching entry, which is the entry for 1000baseKX_Full. If the phy eee does not support 1000baseKX_Full, this entry will not match, causing phy_init_eee to fail for no good reason. Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support") Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array") Cc: Giuseppe Cavallaro Signed-off-by: Guenter Roeck Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e95afb07ddb3876fac5037ce7b3c2a3c23442fe2 Author: Alexander Drozdov Date: Thu Mar 5 10:29:39 2015 +0300 ipv4: ip_check_defrag should not assume that skb_network_offset is zero [ Upstream commit 3e32e733d1bbb3f227259dc782ef01d5706bdae0 ] ip_check_defrag() may be used by af_packet to defragment outgoing packets. skb_network_offset() of af_packet's outgoing packets is not zero. Signed-off-by: Alexander Drozdov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 913c52e4ef72da0a91ee55acdbce34072ac4011e Author: Alexander Drozdov Date: Tue Feb 17 13:33:46 2015 +0300 ipv4: ip_check_defrag should correctly check return value of skb_copy_bits [ Upstream commit fba04a9e0c869498889b6445fd06cbe7da9bb834 ] skb_copy_bits() returns zero on success and negative value on error, so it is needed to invert the condition in ip_check_defrag(). Fixes: 1bf3751ec90c ("ipv4: ip_check_defrag must not modify skb before unsharing") Signed-off-by: Alexander Drozdov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aaf410beca530f2c17de11ad7202a864876688c1 Author: Ignacy Gawędzki Date: Fri Feb 13 14:47:05 2015 -0800 gen_stats.c: Duplicate xstats buffer for later use [ Upstream commit 1c4cff0cf55011792125b6041bc4e9713e46240f ] The gnet_stats_copy_app() function gets called, more often than not, with its second argument a pointer to an automatic variable in the caller's stack. Therefore, to avoid copying garbage afterwards when calling gnet_stats_finish_copy(), this data is better copied to a dynamically allocated memory that gets freed after use. [xiyou.wangcong@gmail.com: remove a useless kfree()] Signed-off-by: Ignacy Gawędzki Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8652a96c846ee011f82ae1425bcd980bd9fb1f19 Author: WANG Cong Date: Fri Feb 13 13:56:53 2015 -0800 rtnetlink: call ->dellink on failure when ->newlink exists [ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ] Ignacy reported that when eth0 is down and add a vlan device on top of it like: ip link add link eth0 name eth0.1 up type vlan id 1 We will get a refcount leak: unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2 The problem is when rtnl_configure_link() fails in rtnl_newlink(), we simply call unregister_device(), but for stacked device like vlan, we almost do nothing when we unregister the upper device, more work is done when we unregister the lower device, so call its ->dellink(). Reported-by: Ignacy Gawedzki Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 677aa4a278c3ac9a8f1570b26a3fe72311d52e1e Author: Martin KaFai Lau Date: Thu Feb 12 16:14:08 2015 -0800 ipv6: fix ipv6_cow_metrics for non DST_HOST case [ Upstream commit 3b4711757d7903ab6fa88a9e7ab8901b8227da60 ] ipv6_cow_metrics() currently assumes only DST_HOST routes require dynamic metrics allocation from inetpeer. The assumption breaks when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric. Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set() is called after the route is created. This patch creates the metrics array (by calling dst_cow_metrics_generic) in ipv6_cow_metrics(). Test: radvd.conf: interface qemubr0 { AdvLinkMTU 1300; AdvCurHopLimit 30; prefix fd00:face:face:face::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; Before: [root@qemu1 ~]# ip -6 r show | egrep -v unreachable fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec fe80::/64 dev eth0 proto kernel metric 256 default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec After: [root@qemu1 ~]# ip -6 r show | egrep -v unreachable fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu 1300 fe80::/64 dev eth0 proto kernel metric 256 mtu 1300 default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec mtu 1300 hoplimit 30 Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.) Signed-off-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 82629d5f112e2a2270f53d21de3a252f63cb9334 Author: Eric Dumazet Date: Fri Feb 13 04:47:12 2015 -0800 tcp: make sure skb is not shared before using skb_get() [ Upstream commit ba34e6d9d346fe4e05d7e417b9edf5140772d34c ] IPv6 can keep a copy of SYN message using skb_get() in tcp_v6_conn_request() so that caller wont free the skb when calling kfree_skb() later. Therefore TCP fast open has to clone the skb it is queuing in child->sk_receive_queue, as all skbs consumed from receive_queue are freed using __kfree_skb() (ie assuming skb->users == 1) Signed-off-by: Eric Dumazet Signed-off-by: Yuchung Cheng Fixes: 5b7ed0892f2af ("tcp: move fastopen functions to tcp_fastopen.c") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33617dede056975e7056b65c468d39f6bcc663d2 Author: Daniel Borkmann Date: Thu Feb 5 18:44:04 2015 +0100 rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY [ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ] ifla_vf_policy[] is wrong in advertising its individual member types as NLA_BINARY since .type = NLA_BINARY in combination with .len declares the len member as *max* attribute length [0, len]. The issue is that when do_setvfinfo() is being called to set up a VF through ndo handler, we could set corrupted data if the attribute length is less than the size of the related structure itself. The intent is exactly the opposite, namely to make sure to pass at least data of minimum size of len. Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink") Cc: Mitch Williams Cc: Jeff Kirsher Signed-off-by: Daniel Borkmann Acked-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 76936e5d2a4cdbe18caae900f300d752ea46886b Author: Sabrina Dubroca Date: Wed Feb 4 23:08:50 2015 +0100 pktgen: fix UDP checksum computation [ Upstream commit 7744b5f3693cc06695cb9d6667671c790282730f ] This patch fixes two issues in UDP checksum computation in pktgen. First, the pseudo-header uses the source and destination IP addresses. Currently, the ports are used for IPv4. Second, the UDP checksum covers both header and data. So we need to generate the data earlier (move pktgen_finalize_skb up), and compute the checksum for UDP header + data. Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums") Signed-off-by: Sabrina Dubroca Acked-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5cd5724b91933ba6985e2094bf7eacb4ce081b53 Author: Daniel Borkmann Date: Thu Feb 5 14:39:11 2015 +0100 ipv6: addrconf: add missing validate_link_af handler [ Upstream commit 11b1f8288d4341af5d755281c871bff6c3e270dd ] We still need a validate_link_af() handler with an appropriate nla policy, similarly as we have in IPv4 case, otherwise size validations are not being done properly in that case. Fixes: f53adae4eae5 ("net: ipv6: add tokenized interface identifier support") Fixes: bc91b0f07ada ("ipv6: addrconf: implement address generation modes") Cc: Jiri Pirko Signed-off-by: Daniel Borkmann Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a7dc52c774f1cc83dcfeca3a3d0434f528473972 Author: Miroslav Urbanek Date: Thu Feb 5 16:36:50 2015 +0100 flowcache: Fix kernel panic in flow_cache_flush_task [ Upstream commit 233c96fc077d310772375d47522fb444ff546905 ] flow_cache_flush_task references a structure member flow_cache_gc_work where it should reference flow_cache_flush_task instead. Kernel panic occurs on kernels using IPsec during XFRM garbage collection. The garbage collection interval can be shortened using the following sysctl settings: net.ipv4.xfrm4_gc_thresh=4 net.ipv6.xfrm6_gc_thresh=4 With the default settings, our productions servers crash approximately once a week. With the settings above, they crash immediately. Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware") Reported-by: Tomáš Charvát Tested-by: Jan Hejl Signed-off-by: Miroslav Urbanek Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin