16 Jan, 2015
40 commits
-
commit 015760563ec77bf17cec712fa94afdf53b285287 upstream.
SH-MSIOF driver is enabled autosuspend API of spi framework.
But autosuspend framework doesn't work during initializing.
So runtime PM lock is added in SH-MSIOF driver initializing.Fixes: e2a0ba547ba31c (spi: sh-msiof: Convert to spi core auto_runtime_pm framework)
Signed-off-by: Hisashi Nakamura
Signed-off-by: Yoshihiro Kaneko
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit f61ff6c06dc8f32c7036013ad802c899ec590607 upstream.
Linus reported perf report command being interrupted due to processing
of 'out of order' event, with following error:Timestamp below last timeslice flush
0x5733a8 [0x28]: failed to process type: 3I could reproduce the issue and in my case it was caused by one CPU
(mmap) being behind during record and userspace mmap reader seeing the
data after other CPUs data were already stored.This is expected under some circumstances because we need to limit the
number of events that we queue for reordering when we receive a
PERF_RECORD_FINISHED_ROUND or when we force flush due to memory
pressure.Reported-by: Linus Torvalds
Signed-off-by: Jiri Olsa
Acked-by: Ingo Molnar
Cc: Andi Kleen
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/1417016371-30249-1-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Zhiqiang Zhang
Signed-off-by: Greg Kroah-Hartman -
commit 5306c31c5733cb4a79cc002e0c3ad256fd439614 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
Signed-off-by: Andi Kleen
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: Stephane Eranian
Cc: Yan, Zheng
Link: http://lkml.kernel.org/r/1420583675-9163-1-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 9fc81d87420d0d3fd62d5e5529972c0ad9eab9cc upstream.
We allow PMU driver to change the cpu on which the event
should be installed to. This happened in patch:e2d37cd213dc ("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:0cda4c023132 ("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
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Vince Weaver
Cc: Yan, Zheng
Link: http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jolsa@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit af91568e762d04931dcbdd6bef4655433d8b9418 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: [] 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: Vince Weaver
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Yan, Zheng
Link: http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jolsa@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 1e359a5de861a57aa04d92bb620f52a5c1d7f8b1 upstream.
This reverts commit ca34e3b5c808385b175650605faa29e71e91991b.
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: ca34e3b5c808 ("mac80211: Fix accounting of the tailroom-needed counter")
Reported-by: Christopher Chavez
Bisected-by: Larry Finger
Debugged-by: Christian Lamparter
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 6f8960541b1eb6054a642da48daae2320fddba93 upstream.
Commit 1d52c78afbb (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
Signed-off-by: Greg Kroah-Hartman -
commit 0b1e95b2fa0934c3a08db483979c70d3b287f50e 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
Cc: Chandramouli Narayanan
Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 0b8c960cf6defc56b3aa1a71b5af95872b6dff2b 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 directorySigned-off-by: Vinson Lee
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 0e63ea48b4d8035dd0e91a3fa6fb79458b47adfb upstream.
The early ioremap support introduced by patch bf4b558eba92
("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 f84d02755f5a ("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: f84d02755f5a ("arm64: add EFI runtime services")
Signed-off-by: Leif Lindholm
Signed-off-by: Ard Biesheuvel
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit f43c27188a49111b58e9611afa2f0365b0b55625 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: 95322526ef62 ("arm64: kernel: cpu_{suspend/resume} implementation")
Cc: Will Deacon
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit c3684fbb446501b48dec6677a6a9f61c215053de 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
Reviewed-by: Mark Rutland
Reviewed-by: Lorenzo Pieralisi
Tested-by: Mark Rutland
Tested-by: Lorenzo Pieralisi
Tested-by: Kees Cook
Acked-by: Ard Biesheuvel
Signed-off-by: Laura Abbott
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit d27eb7931c98a1ebfc9b2fcc48939846bcbfc804 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=86338
Signed-off-by: Hans de Goede
Tested-by: Benjamin Tissoires
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 7091c443dda8c6c6d8e70e33452252f9ad3e7814 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=86338
Signed-off-by: Hans de Goede
Tested-by: Benjamin Tissoires
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 8b23811535d2e1dd6abbe4ce6ea1edfd50ce72de 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 inSince problems 2 & 3 cannot be worked around, just ignore them.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Signed-off-by: Hans de Goede
Tested-by: Benjamin Tissoires
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 1b1f3e1699a9886f1070f94171097ab4ccdbfc95 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
Reviewed-by: Mika Westerberg
Signed-off-by: Greg Kroah-Hartman -
commit 7d0b93499f4879ddbc75d594f4ea216ba964f78e 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
Reported-by: Vitaliy Filippov
Reported-by: Laszlo KREKACS
For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V:
Reported-by: Vladimir Perepechin
Signed-off-by: Aaron Lu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 49a068f82a1d30eb585d7804b05948376be6cf9a 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
Tested-by: Holger Hoffstätte
Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode"
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 4bf9636c39ac70da091d5a2e28d3448eaa7f115c upstream.
Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting
bogomips in /proc/cpuinfo") breaks audio in python, and probably
elsewhere, with messageFATAL: 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=1Reading original changelog, I have to say "Stop breaking working setups.
You know who you are!".Signed-off-by: Pavel Machek
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9008d83fe9dc2e0f19b8ba17a423b3759d8e0fd7 upstream.
Commit 705814b5ea6f ("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: 705814b5ea6f ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5")
Signed-off-by: Nishanth Menon
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 5e794de514f56de1e78e979ca09c56a91aa2e9f1 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
Signed-off-by: Kukjin Kim
Signed-off-by: Greg Kroah-Hartman -
commit be6688350a4470e417aaeca54d162652aab40ac5 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: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board")
Signed-off-by: Lokesh Vutla
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 9d312cd12e89ce08add99fe66e8f6baeaca16d7d upstream.
CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
("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: Nishanth Menon
Signed-off-by: Viresh Kumar
Signed-off-by: Kevin Hilman
Signed-off-by: Greg Kroah-Hartman -
commit d73f825e6efa723e81d9ffcc4949fe9f03f1df29 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
Signed-off-by: Tomi Valkeinen
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 58230c2c443bc9801293f6535144d04ceaf731e0 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: Tomi Valkeinen
Signed-off-by: Felipe Balbi
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit fd7de1e8d5b2b2b35e71332fafb899f584597150 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: f6be8af1c95d ("sched: Add new API wake_up_if_idle() to wake up the idle cpu")
Signed-off-by: Andy Lutomirski
Reviewed-by: Chuansheng Liu
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/729365dddca178506dfd0a9451006344cd6808bc.1417277372.git.luto@amacapital.net
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 269ad8015a6b2bb1cf9e684da4921eb6fa0a0c88 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
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Juri Lelli
Cc: Dario Faggioli
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1418813432-20797-3-git-send-email-luca.abeni@unitn.it
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 6a503c3be937d275113b702e0421e5b0720abe8a 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 < 2This 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: Luca Abeni
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Juri Lelli
Cc: Dario Faggioli
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1418813432-20797-2-git-send-email-luca.abeni@unitn.it
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 7b990789a4c3420fa57596b368733158e432d444 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: 9dc30918b23f ("scripts/kernel-doc: handle struct member __aligned without numbers")
Signed-off-by: Johannes Berg
Cc: Nishanth Menon
Cc: Randy Dunlap
Cc: Michal Marek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 705304a863cc41585508c0f476f6d3ec28cf7e00 upstream.
Same story as in commit 41080b5a2401 ("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
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 775a9134f4398ca98a10af8cc3cf9b664017267f 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 b491da7233d5 ("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: b491da7233d5 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes")
Reported-by: Tony Lindgren
Signed-off-by: Roger Quadros
Signed-off-by: Brian Norris
Signed-off-by: Greg Kroah-Hartman -
commit 834b686552d9018e2d17bd56ac5361b78bcc75b8 upstream.
As stated in a5b7616c5, "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
Signed-off-by: Brian Norris
Signed-off-by: Greg Kroah-Hartman -
commit 68f29815034e9dc9ed53cad85946c32b07adc8cc 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: 6cf78358c94f ("mtd: mtd_torturetest: use mtd_test helpers")
Signed-off-by: Brian Norris
Cc: Akinobu Mita
Signed-off-by: Greg Kroah-Hartman -
commit 021b77bee210843bed1ea91b5cad58235ff9c8e5 upstream.
Probably this code was syncing a lot more often then intended because
the do_sync variable wasn't set to zero.Fixes: c62988ec0910 ('ceph: avoid meaningless calling ceph_caps_revoking if sync_mode == WB_SYNC_ALL.')
Signed-off-by: Dan Carpenter
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman -
commit b4df463678fb9c6dae9548dbb7545993779fd416 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=70241
Reported-and-tested-by: Oleksij Rempel
Reported-and-tested-by: Dmitry Tunin
Reported-and-tested-by: Jimbo
Signed-off-by: Aaron Lu
Acked-by: Jani Nikula
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 94ae1db226a5bcbb48372d81161f084c9e283fd8 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
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit bf7491f1be5e125eece2ec67e0f79d513caa6c7e 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
Fixes: 082d4bd72a45 (nfsd4: "backfill" using write_bytes_to_xdr_buf)
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 5a64e56976f1ba98743e1678c0029a98e9034c81 upstream.
Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as
an additional string encoding.Signed-off-by: Benjamin Coddington
Fixes: e7a0444aef4a "nfsd: add IPv6 addr escaping to fs_location hosts"
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit ef17af2a817db97d42dd2ec0a425231748e23dbc upstream.
Bugs similar to the one in acbbe6fbb240 (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: Jeff Layton
Signed-off-by: Rasmus Villemoes
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 31d4ea1a093fcf668d5f95af44b8d41488bdb7ec upstream.
An attempt to fix fcopy on i586 (bc5a5b0 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 bytesOn 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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
