- 16 Jan, 2015 40 commits
-
-
Andi Kleen authored
commit 5306c31c upstream. There was another report of a boot failure with a #GP fault in the uncore SBOX initialization. The earlier work around was not enough for this system. The boot was failing while trying to initialize the third SBOX. This patch detects parts with only two SBOXes and limits the number of SBOX units to two there. Stable material, as it affects boot problems on 3.18. Tested-by:
Andreas Oehler <andreas@oehler-net.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1420583675-9163-1-git-send-email-andi@firstfloor.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Olsa authored
commit 9fc81d87 upstream. We allow PMU driver to change the cpu on which the event should be installed to. This happened in patch: e2d37cd2 ("perf: Allow the PMU driver to choose the CPU on which to install events") This patch also forces all the group members to follow the currently opened events cpu if the group happened to be moved. This and the change of event->cpu in perf_install_in_context() function introduced in: 0cda4c02 ("perf: Introduce perf_pmu_migrate_context()") forces group members to change their event->cpu, if the currently-opened-event's PMU changed the cpu and there is a group move. Above behaviour causes problem for breakpoint events, which uses event->cpu to touch cpu specific data for breakpoints accounting. By changing event->cpu, some breakpoints slots were wrongly accounted for given cpu. Vinces's perf fuzzer hit this issue and caused following WARN on my setup: WARNING: CPU: 0 PID: 20214 at arch/x86/kernel/hw_breakpoint.c:119 arch_install_hw_breakpoint+0x142/0x150() Can't find any breakpoint slot [...] This patch changes the group moving code to keep the event's original cpu. Reported-by:
Vince Weaver <vince@deater.net> Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vince@deater.net> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jolsa@kernel.orgSigned-off-by:
-
Jiri Olsa authored
commit af91568e upstream. The uncore_collect_events functions assumes that event group might contain only uncore events which is wrong, because it might contain any type of events. This bug leads to uncore framework touching 'not' uncore events, which could end up all sorts of bugs. One was triggered by Vince's perf fuzzer, when the uncore code touched breakpoint event private event space as if it was uncore event and caused BUG: BUG: unable to handle kernel paging request at ffffffff82822068 IP: [<ffffffff81020338>] uncore_assign_events+0x188/0x250 ... The code in uncore_assign_events() function was looking for event->hw.idx data while the event was initialized as a breakpoint with different members in event->hw union. This patch forces uncore_collect_events() to collect only uncore events. Reported-by:
-
Johannes Berg authored
commit 1e359a5d upstream. This reverts commit ca34e3b5. It turns out that the p54 and cw2100 drivers assume that there's tailroom even when they don't say they really need it. However, there's currently no way for them to explicitly say they do need it, so for now revert this. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331. Fixes: ca34e3b5 ("mac80211: Fix accounting of the tailroom-needed counter") Reported-by:
Christopher Chavez <chrischavez@gmx.us> Bisected-by:
Larry Finger <Larry.Finger@lwfinger.net> Debugged-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Chris Mason authored
commit 6f896054 upstream. Commit 1d52c78a (Btrfs: try not to ENOSPC on log replay) added a check to skip delayed inode updates during log replay because it confuses the enospc code. But the delayed processing will end up ignoring delayed refs from log replay because the inode itself wasn't put through the delayed code. This can end up triggering a warning at commit time: WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty+0x32/0x34() Which is repeated for each commit because we never process the delayed inode ref update. The fix used here is to change btrfs_delayed_delete_inode_ref to return an error if we're currently in log replay. The caller will do the ref deletion immediately and everything will work properly. Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Mathias Krause authored
commit 0b1e95b2 upstream. The "by8" counter mode optimization is broken for 128 bit keys with input data longer than 128 bytes. It uses the wrong key material for en- and decryption. The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved in case we're handling more than 128 bytes of input data -- they won't get reloaded after the initial load. They must therefore be (a) loaded on the first iteration and (b) be preserved for the latter ones. The implementation for 128 bit keys does not comply with (a) nor (b). Fix this by bringing the implementation back to its original source and correctly load the key registers and preserve their values by *not* re-using the registers for other purposes. Kudos to James for reporting the issue and providing a test case showing the discrepancies. Reported-by:
James Yonan <james@openvpn.net> Cc: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Vinson Lee authored
commit 0b8c960c upstream. This patch fixes this allyesconfig target build error with older binutils. LD arch/x86/crypto/built-in.o ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory Signed-off-by:
Vinson Lee <vlee@twitter.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 0e63ea48 upstream. The early ioremap support introduced by patch bf4b558e ("arm64: add early_ioremap support") failed to add a call to early_ioremap_reset() at an appropriate time. Without this call, invocations of early_ioremap etc. that are done too late will go unnoticed and may cause corruption. This is exactly what happened when the first user of this feature was added in patch f84d0275 ("arm64: add EFI runtime services"). The early mapping of the EFI memory map is unmapped during an early initcall, at which time the early ioremap support is long gone. Fix by adding the missing call to early_ioremap_reset() to setup_arch(), and move the offending early_memunmap() to right after the point where the early mapping of the EFI memory map is last used. Fixes: f84d0275 ("arm64: add EFI runtime services") Signed-off-by:
Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit f43c2718 upstream. On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0 page tables on boot or to the active_mm mappings belonging to user space processes, it must never be set to swapper_pg_dir page tables mappings. When a CPU is booted its active_mm is set to init_mm even though its TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies that when __cpu_suspend is triggered the active_mm can point at init_mm even if the current TTBR0_EL1 register contains the reserved TTBR0_EL1 mappings. Therefore, the mm save and restore executed in __cpu_suspend might turn out to be erroneous in that, if the current->active_mm corresponds to init_mm, on resume from low power it ends up restoring in the TTBR0_EL1 the init_mm mappings that are global and can cause speculation of TLB entries which end up being propagated to user space. This patch fixes the issue by checking the active_mm pointer before restoring the TTBR0 mappings. If the current active_mm == &init_mm, the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of switching back to the active_mm, which is the expected behaviour corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered. Fixes: 95322526 ("arm64: kernel: cpu_{suspend/resume} implementation") Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Laura Abbott authored
commit c3684fbb upstream. The function cpu_resume currently lives in the .data section. There's no reason for it to be there since we can use relative instructions without a problem. Move a few cpu_resume data structures out of the assembly file so the .data annotation can be dropped completely and cpu_resume ends up in the read only text section. Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Laura Abbott <lauraa@codeaurora.org> Signed-off-by:
-
Hans de Goede authored
commit d27eb793 upstream. Protocol v7 uses the middle / right button bits on clickpads to communicate "location" information of a 3th touch (and possible 4th) touch on clickpads. Specifically when 3 touches are down, if one of the 3 touches is in the left / right button area, this will get reported in the middle / right button bits and the touchpad will still send a TWO type packet rather then a MULTI type packet, so when this happens we must add the finger reported in the button area to the finger count. Likewise we must also add fingers reported this way to the finger count when we get MULTI packets. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit 7091c443 upstream. The v7 proto differentiates between a primary touch (with high precision) and a secondary touch (with lower precision). Normally when 2 fingers are down and one is lifted the still present touch becomes the primary touch, but some traces have shown that this does not happen always. This commit deals with this by making alps_get_mt_count() not stop at the first empty mt slot, and if a touch is present in mt[1] and not mt[0] moving the data to mt[0] (for input_mt_assign_slots). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
-
Hans de Goede authored
commit 8b238115 upstream. NEW packets are send to indicate a discontinuity in the finger coordinate reporting. Specifically a finger may have moved from slot 0 to 1 or vice versa. INPUT_MT_TRACK takes care of this for us. NEW packets have 3 problems: 1) They do not contain middle / right button info (on non clickpads) this can be worked around by preserving the old button state 2) They do not contain an accurate fingercount, and they are typically send when the number of fingers changes. We cannot use the old finger count as that may mismatch with the amount of touch coordinates we've available in the NEW packet 3) Their x data for the second touch is inaccurate leading to a possible jump of the x coordinate by 16 units when the first non NEW packet comes in Since problems 2 & 3 cannot be worked around, just ignore them. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
-
Rafael J. Wysocki authored
commit 1b1f3e16 upstream. If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Aaron Lu authored
commit 7d0b9349 upstream. Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working native backlight control interface so restore their acpi_videoX interface. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221 Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651 For SAMSUNG 870Z5E/880Z5E/680Z5E: Reported-and-tested-by:
Brent Saner <brent.saner@gmail.com> Reported-by:
Vitaliy Filippov <vitalif@yourcmc.ru> Reported-by:
Laszlo KREKACS <laszlo.krekacs.list@gmail.com> For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V: Reported-by:
Vladimir Perepechin <vovochka13@gmail.com> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
J. Bruce Fields authored
commit 49a068f8 upstream. A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by:
Holger Hoffstätte <holger.hoffstaette@googlemail.com> Tested-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Pavel Machek authored
commit 4bf9636c upstream. Commit 9fc2105a ("ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo") breaks audio in python, and probably elsewhere, with message FATAL: cannot locate cpu MHz in /proc/cpuinfo I'm not the first one to hit it, see for example https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/ https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1 Reading original changelog, I have to say "Stop breaking working setups. You know who you are!". Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Nishanth Menon authored
commit 9008d83f upstream. Commit 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Moved logic generic for OMAP5+ as part of the init routine by introducing omap4_pm_init. However, the patch left the powerdomain initial setup, an unused omap4430 es1.0 check and a spurious log "Power Management for TI OMAP4." in the original code. Remove the duplicate code which is already present in omap4_pm_init from omap4_init_static_deps. As part of this change, also move the u-boot version print out of the static dependency function to the omap4_pm_init function. Fixes: 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tomasz Figa authored
commit 5e794de5 upstream. The PWM block is required for system clock source so it must be always enabled. This patch fixes boot issues on SMDK6410 which did not have the node enabled explicitly for other purposes. Fixes: eeb93d02 ("clocksource: of: Respect device tree node status") Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Lokesh Vutla authored
commit be668835 upstream. OMAP wdt driver supports only ti,omap3-wdt compatible. In DRA7 dt wdt compatible property is defined as ti,omap4-wdt by mistake instead of ti,omap3-wdt. Correcting the typo. Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Viresh Kumar authored
commit 9d312cd1 upstream. CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf0719 ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'") and some defconfigs are still using it instead of the new one. Use the renamed CONFIG_CPUFREQ_DT generic driver. Reported-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Tomi Valkeinen authored
commit d73f825e upstream. The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while they seem to work with a quick test, doing for example blank/unblank will give you a black display. This patch updates the timings to the 'typical' values from the LCD spec sheet. Also, the compatible string is completely bogus, as "osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on the board is a newhaven one. Update the compatible string to reflect this. Note that this hasn't caused any issues, as the "panel-dpi" matches the driver. Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit 58230c2c upstream. Caused by a copy & paste error. Note that even with this bug AM437x SK display still works because GPIO mux mode is always enabled. It's still wrong to mux somebody else's pin. Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x isn't used for anything. While at that, also replace a pullup with a pulldown as that gpio should be normally low, not high. Acked-by:
-
Andy Lutomirski authored
commit fd7de1e8 upstream. Locklessly doing is_idle_task(rq->curr) is only okay because of RCU protection. The older variant of the broken code checked rq->curr == rq->idle instead and therefore didn't need RCU. Fixes: f6be8af1 ("sched: Add new API wake_up_if_idle() to wake up the idle cpu") Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
Chuansheng Liu <chuansheng.liu@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/729365dddca178506dfd0a9451006344cd6808bc.1417277372.git.luto@amacapital.netSigned-off-by:
-
Luca Abeni authored
commit 269ad801 upstream. The dl_runtime_exceeded() function is supposed to ckeck if a SCHED_DEADLINE task must be throttled, by checking if its current runtime is <= 0. However, it also checks if the scheduling deadline has been missed (the current time is larger than the current scheduling deadline), further decreasing the runtime if this happens. This "double accounting" is wrong: - In case of partitioned scheduling (or single CPU), this happens if task_tick_dl() has been called later than expected (due to small HZ values). In this case, the current runtime is also negative, and replenish_dl_entity() can take care of the deadline miss by recharging the current runtime to a value smaller than dl_runtime - In case of global scheduling on multiple CPUs, scheduling deadlines can be missed even if the task did not consume more runtime than expected, hence penalizing the task is wrong This patch fix this problem by throttling a SCHED_DEADLINE task only when its runtime becomes negative, and not modifying the runtime Signed-off-by:
Luca Abeni <luca.abeni@unitn.it> Signed-off-by:
Juri Lelli <juri.lelli@gmail.com> Cc: Dario Faggioli <raistlin@linux.it> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1418813432-20797-3-git-send-email-luca.abeni@unitn.itSigned-off-by:
-
Luca Abeni authored
commit 6a503c3b upstream. According to global EDF, tasks should be migrated between runqueues without checking if their scheduling deadlines and runtimes are valid. However, SCHED_DEADLINE currently performs such a check: a migration happens doing: deactivate_task(rq, next_task, 0); set_task_cpu(next_task, later_rq->cpu); activate_task(later_rq, next_task, 0); which ends up calling dequeue_task_dl(), setting the new CPU, and then calling enqueue_task_dl(). enqueue_task_dl() then calls enqueue_dl_entity(), which calls update_dl_entity(), which can modify scheduling deadline and runtime, breaking global EDF scheduling. As a result, some of the properties of global EDF are not respected: for example, a taskset {(30, 80), (40, 80), (120, 170)} scheduled on two cores can have unbounded response times for the third task even if 30/80+40/80+120/170 = 1.5809 < 2 This can be fixed by invoking update_dl_entity() only in case of wakeup, or if this is a new SCHED_DEADLINE task. Signed-off-by:
-
Johannes Berg authored
commit 7b990789 upstream. The change from \d+ to .+ inside __aligned() means that the following structure: struct test { u8 a __aligned(2); u8 b __aligned(2); }; essentially gets modified to struct test { u8 a; }; for purposes of kernel-doc, thus dropping a struct member, which in turns causes warnings and invalid kernel-doc generation. Fix this by replacing the catch-all (".") with anything that's not a semicolon ("[^;]"). Fixes: 9dc30918 ("scripts/kernel-doc: handle struct member __aligned without numbers") Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ryusuke Konishi authored
commit 705304a8 upstream. Same story as in commit 41080b5a ("nfsd race fixes: ext2") (similar ext2 fix) except that nilfs2 needs to use insert_inode_locked4() instead of insert_inode_locked() and a bug of a check for dead inodes needs to be fixed. If nilfs_iget() is called from nfsd after nilfs_new_inode() calls insert_inode_locked4(), nilfs_iget() will wait for unlock_new_inode() at the end of nilfs_mkdir()/nilfs_create()/etc to unlock the inode. If nilfs_iget() is called before nilfs_new_inode() calls insert_inode_locked4(), it will create an in-core inode and read its data from the on-disk inode. But, nilfs_iget() will find i_nlink equals zero and fail at nilfs_read_inode_common(), which will lead it to call iget_failed() and cleanly fail. However, this sanity check doesn't work as expected for reused on-disk inodes because they leave a non-zero value in i_mode field and it hinders the test of i_nlink. This patch also fixes the issue by removing the test on i_mode that nilfs2 doesn't need. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Roger Quadros authored
commit 775a9134 upstream. 3430LDP has NAND flash with 32 bytes OOB size which is sufficient to hold BCH8 codes but the small page check introduced in commit b491da72 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") considers anything below 64 bytes unsuitable for BCH4/8/16. There is another bug in that code where it doesn't skip the check for OMAP_ECC_HAM1_CODE_SW. Get rid of that small page check code as it is insufficient and redundant because we are checking for OOB available bytes vs ecc layout before calling nand_scan_tail(). Fixes: b491da72 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") Reported-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Alison Chaiken authored
commit 834b6865 upstream. As stated in a5b7616c, "mtd: m25p80,spi-nor: Fix module aliases for m25p80", m25p_ids[] in m25p80.c needs to be kept in sync with spi_nor_ids[] in spi-nor.c. The change here corrects a misalignment. (We were missing m25px80 and we had a duplicate w25q128.) Signed-off-by:
Alison Chaiken <alison_chaiken@mentor.com> Signed-off-by:
-
Brian Norris authored
commit 68f29815 upstream. The torture test should quit once it actually induces an error in the flash. This step was accidentally removed during refactoring. Without this fix, the torturetest just continues infinitely, or until the maximum cycle count is reached. e.g.: ... [ 7619.218171] mtd_test: error -5 while erasing EB 100 [ 7619.297981] mtd_test: error -5 while erasing EB 100 [ 7619.377953] mtd_test: error -5 while erasing EB 100 [ 7619.457998] mtd_test: error -5 while erasing EB 100 [ 7619.537990] mtd_test: error -5 while erasing EB 100 ... Fixes: 6cf78358 ("mtd: mtd_torturetest: use mtd_test helpers") Signed-off-by:
-
Dan Carpenter authored
commit 021b77be upstream. Probably this code was syncing a lot more often then intended because the do_sync variable wasn't set to zero. Fixes: c62988ec ('ceph: avoid meaningless calling ceph_caps_revoking if sync_mode == WB_SYNC_ALL.') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Signed-off-by:
-
Aaron Lu authored
commit b4df4636 upstream. If the firmware has declared more than 8 video output devices, and the one that control the internal panel's backlight is listed after the first 8 output devices, the _DOD will not include it due to the current i915 operation region implementation. As a result, we will not create a backlight device for it while we should. Solve this problem by special case the firmware that has 8+ output devices in that if we see such a firmware, we do not test if the device is in _DOD list. The creation of the backlight device will also enable the firmware to emit events on backlight hotkey press when the acpi_osi= cmdline option is specified on those affected ASUS laptops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70241Reported-and-tested-by:
Oleksij Rempel <linux@rempel-privat.de> Reported-and-tested-by:
Dmitry Tunin <hanipouspilot@gmail.com> Reported-and-tested-by:
Jimbo <jaime.91@hotmail.es> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jeff Layton authored
commit 94ae1db2 upstream. Currently, nfs4_set_delegation takes a reference to an existing delegation and then checks to see if there is a conflict. If there is one, then it doesn't release that reference. Change the code to take the reference after the check and only if there is no conflict. Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
Benjamin Coddington authored
commit bf7491f1 upstream. Fix a bug where nfsd4_encode_components_esc() incorrectly calculates the length of server array in fs_location4--note that it is a count of the number of array elements, not a length in bytes. Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Fixes: 082d4bd7 (nfsd4: "backfill" using write_bytes_to_xdr_buf) Signed-off-by:
-
Benjamin Coddington authored
commit 5a64e569 upstream. Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as an additional string encoding. Signed-off-by:
-
Rasmus Villemoes authored
commit ef17af2a upstream. Bugs similar to the one in acbbe6fb (kcmp: fix standard comparison bug) are in rich supply. In this variant, the problem is that struct xdr_netobj::len has type unsigned int, so the expression o1->len - o2->len _also_ has type unsigned int; it has completely well-defined semantics, and the result is some non-negative integer, which is always representable in a long long. But this means that if the conditional triggers, we are guaranteed to return a positive value from compare_blob. In this case it could be fixed by - res = o1->len - o2->len; + res = (long long)o1->len - (long long)o2->len; but I'd rather eliminate the usually broken 'return a - b;' idiom. Reviewed-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Vitaly Kuznetsov authored
commit 31d4ea1a upstream. An attempt to fix fcopy on i586 (bc5a5b02 Drivers: hv: util: Properly pack the data for file copy functionality) led to a regression on x86_64 (and actually didn't fix i586 breakage). Fcopy messages from Hyper-V host come in the following format: struct do_fcopy_hdr | 36 bytes 0000 | 4 bytes offset | 8 bytes size | 4 bytes data | 6144 bytes On x86_64 struct hv_do_fcopy matched this format without ' __attribute__((packed))' and on i586 adding ' __attribute__((packed))' to it doesn't change anything. Keep the structure packed and add padding to match re reality. Tested both i586 and x86_64 on Hyper-V Server 2012 R2. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
commit 04a258c1 upstream. When build with Debug the following crash is sometimes observed: Call Trace: [<ffffffff812b9600>] string+0x40/0x100 [<ffffffff812bb038>] vsnprintf+0x218/0x5e0 [<ffffffff810baf7d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff812bb4c1>] vscnprintf+0x11/0x30 [<ffffffff8107a2f0>] vprintk+0xd0/0x5c0 [<ffffffffa0051ea0>] ? vmbus_process_rescind_offer+0x0/0x110 [hv_vmbus] [<ffffffff8155c71c>] printk+0x41/0x45 [<ffffffffa004ebac>] vmbus_device_unregister+0x2c/0x40 [hv_vmbus] [<ffffffffa0051ecb>] vmbus_process_rescind_offer+0x2b/0x110 [hv_vmbus] ... This happens due to the following race: between 'if (channel->device_obj)' check in vmbus_process_rescind_offer() and pr_debug() in vmbus_device_unregister() the device can disappear. Fix the issue by taking an additional reference to the device before proceeding to vmbus_device_unregister(). Signed-off-by:
-
Christian Riesch authored
commit 8bfbe2de upstream. Commit 19e2ad6a ("n_tty: Remove overflow tests from receive_buf() path") moved the increment of read_head into the arguments list of read_buf_addr(). Function calls represent a sequence point in C. Therefore read_head is incremented before the character c is placed in the buffer. Since the circular read buffer is a lock-less design since commit 6d76bd26 ("n_tty: Make N_TTY ldisc receive path lockless"), this creates a race condition that leads to communication errors. This patch modifies the code to increment read_head _after_ the data is placed in the buffer and thus fixes the race for non-SMP machines. To fix the problem for SMP machines, memory barriers must be added in a separate patch. Signed-off-by:
Christian Riesch <christian.riesch@omicron.at> Signed-off-by:
-
