aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-15ARM: tegra: Comment out gpio-ranges propertiesThierry Reding4-0/+8
While the addition of these properties is technically correct it unveils a bug with deferred probe. The problem is that the presence of the gpio- range property causes the gpio-tegra driver to defer probe (it needs the pinctrl driver to be ready). That's technically correct, but it causes a couple of issues: - The keyboard on Chromebooks stops working. The reason for that is that the gpio-tegra device has not registered an IRQ domain by the time the EC SPI device is registered, hence the interrupt number resolves to 0. This is technically a bug in the SPI core, since it should really resolve the interrupt at probe time and defer if the IRQ domain isn't available yet. This is similar to what's done for I2C and platform device already. - The gpio-tegra device deferring probe means that it is moved to the end of the dpm_list. This list defines the suspend/resume order for devices. However the core lacks a way to move all users of the gpio-tegra device to the end of the dpm_list at the same time. This in turn results in a subtle bug on Jetson TK1, where the gpio-keys device is used to expose the power key as input. The power key is a convenient way to wake the system from suspend. Interestingly, the gpio-keys device ends up getting probed at a point after gpio-tegra has been probed successfully from having been deferred earlier. As such the driver doesn't need to defer the probe itself, and hence the device isn't moved to the end of the dpm_list. This causes the gpio-tegra device to be suspended before gpio-keys, which in turn leaves gpio-keys unable to wake the system from suspend. There are patches in the works to fix both of the above issues, but they are too involved to make it into v4.3, so in the meantime let's fix the regressions by commenting out the gpio-ranges properties until the fixes have landed. Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-15block: don't release bdi while request_queue has live referencesTejun Heo4-3/+18
bdi's are initialized in two steps, bdi_init() and bdi_register(), but destroyed in a single step by bdi_destroy() which, for a bdi embedded in a request_queue, is called during blk_cleanup_queue() which makes the queue invisible and starts the draining of remaining usages. A request_queue's user can access the congestion state of the embedded bdi as long as it holds a reference to the queue. As such, it may access the congested state of a queue which finished blk_cleanup_queue() but hasn't reached blk_release_queue() yet. Because the congested state was embedded in backing_dev_info which in turn is embedded in request_queue, accessing the congested state after bdi_destroy() was called was fine. The bdi was destroyed but the memory region for the congested state remained accessible till the queue got released. a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") changed the situation. Now, the root congested state which is expected to be pinned while request_queue remains accessible is separately reference counted and the base ref is put during bdi_destroy(). This means that the root congested state may go away prematurely while the queue is between bdi_dstroy() and blk_cleanup_queue(), which was detected by Andrey's KASAN tests. The root cause of this problem is that bdi doesn't distinguish the two steps of destruction, unregistration and release, and now the root congested state actually requires a separate release step. To fix the issue, this patch separates out bdi_unregister() and bdi_exit() from bdi_destroy(). bdi_unregister() is called from blk_cleanup_queue() and bdi_exit() from blk_release_queue(). bdi_destroy() is now just a simple wrapper calling the two steps back-to-back. While at it, the prototype of bdi_destroy() is moved right below bdi_setup_and_register() so that the counterpart operations are located together. Signed-off-by: Tejun Heo <[email protected]> Fixes: a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") Cc: [email protected] # v4.2+ Reported-and-tested-by: Andrey Konovalov <[email protected]> Link: http://lkml.kernel.org/g/CAAeHK+zUJ74Zn17=rOyxacHU18SgCfC6bsYW=6kCY5GXJBwGfQ@mail.gmail.com Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Jeff Moyer <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-10-15nvme: use an integer value to Linux errno valuesChristoph Hellwig1-5/+7
Use a separate integer variable to hold the signed Linux errno values we pass back to the block layer. Note that for pass through commands those might still be NVMe values, but those fit into the int as well. Fixes: f4829a9b7a61: ("blk-mq: fix racy updates of rq->errors") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-10-15Merge tag 'omap-for-v4.3/fixes-rc5' of ↵Arnd Bergmann4-5/+19
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "Fixes for omap against v4.3-rc5" from Tony Lindgren: - Regulator fix for beagle-x15 to fix HDMI without a SD card being inserted - GPMC fix for showing proper timings and to allow enabling debug options that somehow was unselectable earlier - Add minimal documentation for new MMC1 dependency on REGULATOR_PBIAS as it may not be obvious for people with targeted .config files * tag 'omap-for-v4.3/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: Documentation: ARM: List new omap MMC requirements memory: omap-gpmc: dump "before" state before first modification memory: omap-gpmc: Fix unselectable debug option for GPMC ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on
2015-10-15ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref boardMasahiro Yamada1-1/+1
The IRQ signal from external devices on this board is connected to the XIRQ4 pin of the SoC. The IRQ number should be 52, not 50. Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b SoC/board support") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-15drivers/perf: arm_pmu: avoid CPU device_node reference leakWill Deacon1-2/+8
of_cpu_device_node_get increments the reference count on the CPU device_node, so we must take care to of_node_put once we've finished with it. This patch fixes the perf IRQ probing code to avoid the leak. Cc: Sudeep Holla <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-15bus: arm-ccn: Fix irq affinity setting on CPU migrationPawel Moll1-1/+2
When PMU context is migrating between CPUs, interrupt affinity is set as well. Only this should not happen when the CCN interrupt is not being used at all (the driver is using a hrtimer tick instead). Fixed now. Cc: <[email protected]> # 4.2+ Signed-off-by: Pawel Moll <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-15bus: arm-ccn: Handle correctly no-more-cpus casePawel Moll1-1/+1
When migrating events the driver picks another cpu using cpumask_any_but() function, which returns value >= nr_cpu_ids when there is none available, not a negative value as the code assumed. Fixed now. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Pawel Moll <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-15blk-mq: fix use-after-free in blk_mq_free_tag_set()Junichi Nomura2-3/+2
tags is freed in blk_mq_free_rq_map() and should not be used after that. The problem doesn't manifest if CONFIG_CPUMASK_OFFSTACK is false because free_cpumask_var() is nop. tags->cpumask is allocated in blk_mq_init_tags() so it's natural to free cpumask in its counter part, blk_mq_free_tags(). Fixes: f26cdc8536ad ("blk-mq: Shared tag enhancements") Signed-off-by: Jun'ichi Nomura <[email protected]> Cc: Keith Busch <[email protected]> Reviewed-by: Jeff Moyer <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-10-15iommu/amd: Fix BUG when faulting a PROT_NONE VMAJay Cornwall1-0/+7
handle_mm_fault indirectly triggers a BUG in do_numa_page when given a VMA without read/write/execute access. Check this condition in do_fault. do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page mm/memory.c 3147 static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, .... 3159 /* A PROT_NONE fault should not end up here */ 3160 BUG_ON(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))); Signed-off-by: Jay Cornwall <[email protected]> Cc: <[email protected]> # v4.1+ Signed-off-by: Joerg Roedel <[email protected]>
2015-10-15drm/amdgpu: Keep the pflip interrupts always enabled v7Michel Dänzer4-8/+84
This fixes flickering issues caused by prematurely firing pflip interrupts. v2 (chk): add commit message, fix DCE V10/V11 and DM as well v3: Re-enable pflip interrupt wherever we re-enable a CRTC v4: Enable pflip interrupt in DAL as well v5: drop DAL changes for upstream v6: (agd): only enable interrupts on crtcs that exist v7: (agd): integrate suggestions from Michel Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-10-15drm/amdgpu: adjust default dispclk (v2)Alex Deucher1-2/+6
Set the default to 600Mhz if it's not set in the bios, and bump the default to 600Mhz if it's lower than that. Port of radeon commit: 9368931db826d57b6b88b3145a00276626b48df0 v2: clean up the code a bit bug: https://bugs.freedesktop.org/show_bug.cgi?id=91896 Signed-off-by: Alex Deucher <[email protected]>
2015-10-15mlxsw: core: Fix race condition in __mlxsw_emad_transmitIdo Schimmel1-4/+9
Under certain conditions EMAD responses can be returned from the device even before setting trans_active. This will cause the EMAD Rx listener to drop the EMAD response - as there are no active transactions - and timeouts will be generated. Fix this by setting trans_active before transmitting the EMAD skb. Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-10-15i2c: designware-platdrv: enable RuntimePM before registering to the coreWolfram Sang1-6/+7
The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Mika Westerberg <[email protected]> Cc: [email protected]
2015-10-15i2c: s3c2410: enable RuntimePM before registering to the coreWolfram Sang1-3/+5
The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Krzysztof Kozlowski <[email protected]> Acked-by: Kukjin Kim <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2015-10-15i2c: rcar: enable RuntimePM before registering to the coreWolfram Sang1-3/+4
The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2015-10-15i2c: return probe deferred status on dev_pm_domain_attachKieran Bingham1-6/+6
A change of return status was introduced in commit 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") The commit prevents the defer status being passed up the call stack appropriately when dev_pm_domain_attach returns -EPROBE_DEFER. Catch the PROBE_DEFER and clear up the IRQ wakeup status Signed-off-by: Kieran Bingham <[email protected]> Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") Reviewed-by: Dmitry Torokhov <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2015-10-15ARM: mvebu: correct a385-db-ap compatible stringMarcin Wojtas1-1/+1
This commit enables standby support on Armada 385 DB-AP board, because the PM initalization routine requires "marvell,armada380" compatible string for all Armada 38x-based platforms. Beside the compatible "marvell,armada38x" was wrong and should be fixed in the stable kernels too. [[email protected]: add information, about the fixes] Fixes: e5ee12817e9ea ("ARM: mvebu: Add Armada 385 Access Point Development Board support") Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Cc: <[email protected]>
2015-10-14tipc: move fragment importance field to new header positionJon Paul Maloy1-2/+2
In commit e3eea1eb47a ("tipc: clean up handling of message priorities") we introduced a field in the packet header for keeping track of the priority of fragments, since this value is not present in the specified protocol header. Since the value so far only is used at the transmitting end of the link, we have not yet officially defined it as part of the protocol. Unfortunately, the field we use for keeping this value, bits 13-15 in in word 5, has turned out to be a poor choice; it is already used by the broadcast protocol for carrying the 'network id' field of the sending node. Since packet fragments also need to be transported across the broadcast protocol, the risk of conflict is obvious, and we see this happen when we use network identities larger than 2^13-1. This has escaped our testing because we have so far only been using small network id values. We now move this field to bits 0-2 in word 9, a field that is guaranteed to be unused by all involved protocols. Fixes: e3eea1eb47a ("tipc: clean up handling of message priorities") Signed-off-by: Jon Maloy <[email protected]> Acked-by: Ying Xue <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-10-14ethtool: Use kcalloc instead of kmalloc for ethtool_get_stringsJoe Perches1-1/+1
It seems that kernel memory can leak into userspace by a kmalloc, ethtool_get_strings, then copy_to_user sequence. Avoid this by using kcalloc to zero fill the copied buffer. Signed-off-by: Joe Perches <[email protected]> Acked-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-10-14Merge tag 'mac80211-for-davem-2015-10-13' of ↵David S. Miller3-3/+7
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Like last time, we have two small fixes: * fast-xmit was not doing powersave filter clearing correctly, disable fast-xmit while any such operations are still pending * a debugfs file was broken due to some infrastructure changes ==================== Signed-off-by: David S. Miller <[email protected]>
2015-10-15drm/dp/mst: make mst i2c transfer code more robust.Dave Airlie2-2/+4
This zeroes the msg so no random stack data ends up getting sent, it also limits the function to not accepting > 4 i2c msgs. Cc: [email protected] Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2015-10-15drm/radeon: attach tile property to mst connectorDave Airlie1-0/+1
This allows tiled monitors to work with radeon once mst is enabled. Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
2015-10-14ACPICA: Tables: Fix FADT dependency regressionLv Zheng5-33/+10
Some logics actually relying on the existence of FADT, currently relies on the number of loaded tables. This false dependency can easily trigger regressions. One of them has been introduced by commit 8ec3f459073e (ACPICA: Tables: Fix global table list issues by removing fixed table). The commit changing the fixed table indexes results in the change of FADT table index, originally, it was 3 (thus the installed table count should be greater than 4), while currently it is 0 (and the installed table count may be 3). This patch fixes this regression by cleaning up the code. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=105351 Fixes: 8ec3f459073e (ACPICA: Tables: Fix global table list issues by removing fixed table) Reported-and-tested-by: Meelis Roos <[email protected]> Signed-off-by: Lv Zheng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-10-14ARM: meson6: DTS: Fix wrong reg mapping and IRQ numbersCarlo Caione1-11/+12
The DTS erronously uses the wrong reg mapping and IRQ numbers for some UART, WDT and timer nodes. Fix this. Reported-by: John Wehle <[email protected]> Signed-off-by: Carlo Caione <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-14Partially revert "clk: mvebu: Convert to clk_hw based provider APIs"Stephen Boyd1-1/+3
This partially reverts commit eca61c9ff2588e1df373e61078e1874976315839. Thomas reports that it causes regressions on Armada XP devices. This is because of_clk_get_parent_name() relies on the property 'clock-output-names' to resolve the name of a clock's parent, without trying to get the clock from the framework and call __clk_get_name(). Given that Armada XP devices don't have the 'clock-output-names' property, of_clk_get_parent_name() returns the name of the node which doesn't match the actual parent clock's name at all, causing CPU clocks to never link up with their parents. Reported-by: Thomas Petazzoni <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2015-10-14Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds4-87/+90
Pull KVM fixes from Paolo Bonzini: "Bug fixes for system management mode emulation. The first two patches fix SMM emulation on Nehalem processors. The others fix some cases that became apparent as work progressed on the firmware side" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: fix RSM into 64-bit protected mode KVM: x86: fix previous commit for 32-bit KVM: x86: fix SMI to halted VCPU KVM: x86: clean up kvm_arch_vcpu_runnable KVM: x86: map/unmap private slots in __x86_set_memory_region KVM: x86: build kvm_userspace_memory_region in x86_set_memory_region
2015-10-14Merge tag 'mfd-fixes-4.3' of ↵Linus Torvalds2-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD fixes from Lee Jones: "Bug Fixes: - Return correct error code i.e. not zero - Fix build error when !CONFIG_PM_SLEEP" * tag 'mfd-fixes-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: max77843: Fix max77843_chg_init() return on error mfd: intel-lpss: Fix build error when !CONFIG_PM_SLEEP
2015-10-14MAINTAINERS: Update Allwinner entry and add new maintainerMaxime Ripard1-2/+3
Add Chen-Yu Tsai as a co-maintainer to the ARM sunxi support. While we are doing so, also update the entry for new SoCs. Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-14ARM: ux500: modify initial levelshifter statusLinus Walleij1-1/+1
commit 1d8aca9df612f5751892fb2642d72536f2f48fd0 "ARM: ux500: fix MMC/SD card regression" fixed broken the level shifter: it should be default ON but became default OFF. Fixes: 1d8aca9df612 "ARM: ux500: fix MMC/SD card regression" Reported-and-tested-by: Ulf Hansson <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2015-10-14ARM: pxa: fix pxa3xx DFI lockup hackArnd Bergmann1-4/+5
Some recently added code to avoid a bug introduced a build error when CONFIG_PM is disabled and a macro is hidden: arch/arm/mach-pxa/pxa3xx.c: In function 'pxa3xx_init': arch/arm/mach-pxa/pxa3xx.c:439:3: error: 'NDCR' undeclared (first use in this function) NDCR = (NDCR & ~NDCR_ND_ARB_EN) | NDCR_ND_ARB_CNTL; ^ This moves the macro outside of the #ifdef so it can be referenced correctly. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: adf3442cc890 ("ARM: pxa: fix DFI bus lockups on startup") Acked-by: Robert Jarzmik <[email protected]>
2015-10-14Merge tag 'imx-fixes-4.3-2' of ↵Arnd Bergmann1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Pull "The i.MX fixes for 4.3, 2nd round:" from Shawn Guo: It includes a single fix for i.MX7D, which corrects the base address of UART2 in device tree. * tag 'imx-fixes-4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx7d: Fix UART2 base address
2015-10-14Merge tag 'berlin-fixes-for-4.3-1' of ↵Arnd Bergmann1-3/+3
git://git.infradead.org/users/hesselba/linux-berlin into fixes Merge "Marvell Berlin fixes for v4.3 take 1" from Sebastian Hesselbarth: - BG2Q USB PHY compatible fix (also tagged for stable v4.2) * tag 'berlin-fixes-for-4.3-1' of git://git.infradead.org/users/hesselba/linux-berlin: ARM: dts: berlin: change BG2Q's USB PHY compatible
2015-10-14Merge tag 'mvebu-fixes-4.3-1' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann1-1/+1
Merge "mvebu fixes for 4.3 (part 1)" from Gregory CLEMENT: DSA fixes for orion platform * tag 'mvebu-fixes-4.3-1' of git://git.infradead.org/linux-mvebu: ARM: orion: Fix DSA platform device after mvmdio conversion
2015-10-14KVM: x86: fix RSM into 64-bit protected modePaolo Bonzini1-3/+7
In order to get into 64-bit protected mode, you need to enable paging while EFER.LMA=1. For this to work, CS.L must be 0. Currently, we load the segments before CR0 and CR4, which means that if RSM returns into 64-bit protected mode CS.L is already 1 and everything breaks. Luckily, CS.L=0 is always the case when executing RSM, because it is forbidden to execute RSM from 64-bit protected mode. Hence it is enough to load CR0 and CR4 first, and only then the segments. Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-14KVM: x86: fix previous commit for 32-bitPaolo Bonzini1-1/+1
Unfortunately I only noticed this after pushing. Fixes: f0d648bdf0a5bbc91da6099d5282f77996558ea4 Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-14x86/efi: Fix multiple GOP device supportKővágó, Zoltán1-2/+6
When multiple GOP devices exists, but none of them implements ConOut, the code should just choose the first GOP (according to the comments). But currently 'fb_base' will refer to the last GOP, while other parameters to the first GOP, which will likely result in a garbled display. I can reliably reproduce this bug using my ASRock Z87M Extreme4 motherboard with CSM and integrated GPU disabled, and two PCIe video cards (NVidia GT640 and GTX980), booting from efi-stub (booting from grub works fine). On the primary display the ASRock logo remains and on the secondary screen it is garbled up completely. Signed-off-by: Kővágó, Zoltán <[email protected]> Signed-off-by: Matt Fleming <[email protected]> Cc: <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-10-14tipc: eliminate risk of stalled link synchronizationJon Paul Maloy1-3/+3
In commit 6e498158a827 ("tipc: move link synch and failover to link aggregation level") we introduced a new mechanism for performing link failover and synchronization. We have now detected a bug in this mechanism. During link synchronization we use the arrival of any packet on the tunnel link to trig a check for whether it has reached the synchronization point or not. This has turned out to be too permissive, since it may cause an arriving non-last SYNCH packet to end the synch state, just to see the next SYNCH packet initiate a new synch state with a new, higher synch point. This is not fatal, but should be avoided, because it may significantly extend the synchronization period, while at the same time we are not allowed to send NACKs if packets are lost. In the worst case, a low-traffic user may see its traffic stall until a LINK_PROTOCOL state message trigs the link to leave synchronization state. At the same time, LINK_PROTOCOL packets which happen to have a (non- valid) sequence number lower than the tunnel link's rcv_nxt value will be consistently dropped, and will never be able to resolve the situation described above. We fix this by exempting LINK_PROTOCOL packets from the sequence number check, as they should be. We also reduce (but don't completely eliminate) the risk of entering multiple synchronization states by only allowing the (logically) first SYNCH packet to initiate a synchronization state. This works independently of actual packet arrival order. Fixes: commit 6e498158a827 ("tipc: move link synch and failover to link aggregation level") Signed-off-by: Jon Maloy <[email protected]> Acked-by: Ying Xue <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-10-14arm64: compat: wire up new syscallsWill Deacon2-1/+10
Commit 208473c1f3ac ("ARM: wire up new syscalls") hooked up the new userfaultfd and membarrier syscalls for ARM, so do the same for our compat syscall table in arm64. Signed-off-by: Will Deacon <[email protected]>
2015-10-14drm/i915: Add primary plane to mask if it's visibleMaarten Lankhorst1-2/+6
This fixes the warnings like "plane A assertion failure, should be disabled but not" that on the initial modeset during boot. This can happen if the primary plane is enabled by the firmware, but inheriting it fails because the DMAR is active or for other reasons. Most likely caused by commit 36750f284b3a4f19b304fda1bb7d6e9e1275ea8d Author: Maarten Lankhorst <[email protected]> Date: Mon Jun 1 12:49:54 2015 +0200 drm/i915: update plane state during init This is a new version of commit 721a09f7393de6c28a07516dccd654c6e995944a Author: Maarten Lankhorst <[email protected]> Date: Tue Sep 15 14:28:54 2015 +0200 drm/i915: Add primary plane to mask if it's visible That was reverted in order to facilitate easier backporting of some commits from -next to v4.3. Reported-by: Andreas Reis <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429 Reported-and-tested-by: Emil Renner Berthing <[email protected]> Tested-by: Andreas Reis <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> [Jani: cherry-picked from -next to v4.3] Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2015-10-14drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()Ville Syrjälä1-24/+20
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc() where it belongs instead of doing it in intel_modeset_readout_hw_state(). The plane disabling was first added in 4cf0ebbd4fafbdf8e6431dbb315e5511c3efdc3b drm/i915: Rework plane readout. I got the idea from some patches from Partik and/or Maarten but those moved also the plane state readout to intel_sanitize_crtc() which isn't quite right in my opinion. Cc: Maarten Lankhorst <[email protected]> Cc: Patrik Jakobsson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> References: https://bugs.freedesktop.org/show_bug.cgi?id=91910 Reviewed-by: Patrik Jakobsson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> [Jani: cherry-picked from -next to v4.3] Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2015-10-14drm/i915: Assign hwmode after encoder state readoutVille Syrjälä1-27/+30
The dotclock is often calculated in encoder .get_config(), so we shouldn't copy the adjusted_mode to hwmode until we have read out the dotclock. Gets rid of some warnings like these: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [drm:i915_get_vblank_timestamp] crtc 0 is disabled v2: Steal Maarten's idea to move crtc->mode etc. assignment too Cc: Maarten Lankhorst <[email protected]> Cc: Patrik Jakobsson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428 Reviewed-by: Patrik Jakobsson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> [Jani: cherry-picked from -next to v4.3] Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2015-10-14Revert "drm/i915: Add primary plane to mask if it's visible"Jani Nikula1-5/+2
This reverts commit 721a09f7393de6c28a07516dccd654c6e995944a. There is nothing wrong with the commit per se. We had two versions of the commit, one in -next headed for v4.4 and this one for v4.3. Turns out we'll need to backport more fixes from -next, and they conflict with the v4.3 version. It gets messy. It will be easiest to revert this one, and backport all the relevant commits from -next without modifications; they apply cleanly after this revert. Requested-by: Joseph Yasi <[email protected]> References: https://bugs.freedesktop.org/show_bug.cgi?id=91910#c4 Cc: Maarten Lankhorst <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2015-10-13Input: cyapa - fix the copy paste error on electrodes_rx valueDudley Du1-7/+3
Fix the copy paste error on the electrodes_rx value set code which will cause the electrodes_rx value be always set to the value of electrodes_y. Reported-by: Sudip Mukherjee <[email protected]> Signed-off-by: Dudley Du <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-10-13btrfs: fix use after free iterating extrefsChris Mason1-5/+3
The code for btrfs inode-resolve has never worked properly for files with enough hard links to trigger extrefs. It was trying to get the leaf out of a path after freeing the path: btrfs_release_path(path); leaf = path->nodes[0]; item_size = btrfs_item_size_nr(leaf, slot); The fix here is to use the extent buffer we cloned just a little higher up to avoid deadlocks caused by using the leaf in the path. Signed-off-by: Chris Mason <[email protected]> cc: [email protected] # v3.7+ cc: Mark Fasheh <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Reviewed-by: Mark Fasheh <[email protected]>
2015-10-13btrfs: check unsupported filters in balance argumentsDavid Sterba2-0/+13
We don't verify that all the balance filter arguments supplemented by the flags are actually known to the kernel. Thus we let it silently pass and do nothing. At the moment this means only the 'limit' filter, but we're going to add a few more soon so it's better to have that fixed. Also in older stable kernels so that it works with newer userspace tools. Cc: [email protected] # 3.16+ Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-10-14PM / Domains: Fix validation of latency constraints in genpd governorUlf Hansson1-16/+6
Commit ba2bbfbf6307 (PM / Domains: Remove intermediate states from the power off sequence) changed the power off sequence in genpd. That also required some updates regarding the validation of latency constraints in the genpd governor. Unfortunate that wasn't covered, so let's fix this. From a runtime PM and latency point of view, we need to consider the worst case scenario while validating latency constraints. That's typically when a call to pm_runtime_get_sync() needs to wait for a ongoing runtime suspend operation to be carried out, as it then also needs to wait for the device to be runtime resumed again. The above mentioned commit made the genpd governor's ->stop_ok() callback responsible of validating genpd's device's runtime suspend/resume latency. In other words, the constraint needs to be validated towards the relevant latencies present in genpd's ->runtime_suspend|resume() callbacks. Earlier, that included latencies from the ->stop|start() callbacks, but as ->save|restore_state() are now also being invoked from genpd's ->runtime_suspend|resume() and to comply with the worst case scenario, let's take also those latencies into account. Fixes: ba2bbfbf6307 (PM / Domains: Remove intermediate states from the power off sequence) Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-10-13IB/ipoib: For sendonly join free the multicast group on leaveChristoph Lameter3-2/+5
When we leave the multicast group on expiration of a neighbor we do not free the mcast structure. This results in a memory leak that causes ib_dealloc_pd to fail and print a WARN_ON message and backtrace. Fixes: bd99b2e05c4d (IB/ipoib: Expire sendonly multicast joins) Signed-off-by: Christoph Lameter <[email protected]> Tested-by: Sagi Grimberg <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2015-10-13iommu/vt-d: fix range computation when making room for large pagesChristian Zander1-4/+8
In preparation for the installation of a large page, any small page tables that may still exist in the target IOV address range are removed. However, if a scatter/gather list entry is large enough to fit more than one large page, the address space for any subsequent large pages is not cleared of conflicting small page tables. This can cause legitimate mapping requests to fail with errors of the form below, potentially followed by a series of IOMMU faults: ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083) In this example, a 4MiB scatter/gather list entry resulted in the successful installation of a large page @ vPFN 0xfdc00, followed by a failed attempt to install another large page @ vPFN 0xfde00, due to the presence of a pointer to a small page table @ 0x7f83a4000. To address this problem, compute the number of large pages that fit into a given scatter/gather list entry, and use it to derive the last vPFN covered by the large page(s). Cc: [email protected] Signed-off-by: Christian Zander <[email protected]> Signed-off-by: David Woodhouse <[email protected]>
2015-10-13Merge tag 'nfsd-4.3-2' of git://linux-nfs.org/~bfields/linuxLinus Torvalds2-9/+1
Pull nfsd fixes from Bruce Fields: "Two nfsd fixes, one for an RDMA crash, one for a pnfs/block protocol bug" * tag 'nfsd-4.3-2' of git://linux-nfs.org/~bfields/linux: svcrdma: Fix NFS server crash triggered by 1MB NFS WRITE nfsd/blocklayout: accept any minlength
Powered by cgit, Gruvboxed by Blaster4385.