| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There's a small race when function graph shutsdown and the calling of the
registered function graph entry callback. The callback must not reference
the task's ret_stack without first checking that it is not NULL. Note, when
a ret_stack is allocated for a task, it stays allocated until the task exits.
The problem here, is that function_graph is shutdown, and a new task was
created, which doesn't have its ret_stack allocated. But since some of the
functions are still being traced, the callbacks can still be called.
The normal function_graph code handles this, but starting with commit
8861dd303c ("ftrace: Access ret_stack->subtime only in the function
profiler") the profiler code references the ret_stack on function entry, but
doesn't check if it is NULL first.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196611
Cc: [email protected]
Fixes: 8861dd303c ("ftrace: Access ret_stack->subtime only in the function profiler")
Reported-by: [email protected]
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
|
|
This change exposes mixer control 'Hotword Model' for switching
hotword model in runtime. This new function requires updated
firmware to load hotword model at address 0x4ff80000.
Signed-off-by: Hsin-Yu Chao <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Static checkers complain that unsigned int val is always >= 0. The
context is that snd_soc_read() returns -1U on error. This is harmless
because we're checking that CDC_A_MBHC_RESULT_1_BTN_RESULT_MASK is not
set, and it will always be set for -1U. I could have just removed the
check against -1 but I preserved it because I thought it helped with
readability.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
This adds missing memory barriers to order updates/tests of
the virtual CPPR and MFRR, thus fixing a lost IPI problem.
While at it also document all barriers in this file.
This fixes a bug causing guest IPIs to occasionally get lost. The
symptom then is hangs or stalls in the guest.
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Tested-by: Guilherme G. Piccoli <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
|
|
This adds a workaround for a bug in POWER9 DD1 chips where changing
the CPPR (Current Processor Priority Register) can cause bits in the
IPB (Interrupt Pending Buffer) to get lost. Thankfully it only
happens when manually manipulating CPPR which is quite rare. When it
does happen it can cause interrupts to be delayed or lost.
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
|
|
When msgsnd is used for IPIs to other cores, msgsync must be executed by
the target to order stores performed on the source before its msgsnd
(provided the source executes the appropriate sync).
Fixes: 1704a81ccebc ("KVM: PPC: Book3S HV: Use msgsnd for IPIs to other cores on POWER9")
Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
|
|
When a timer base is idle, it is forwarded when a new timer is added
to ensure that granularity does not become excessive. When not idle,
the timer tick is expected to increment the base.
However there are several problems:
- If an existing timer is modified, the base is forwarded only after
the index is calculated.
- The base is not forwarded by add_timer_on.
- There is a window after a timer is restarted from a nohz idle, after
it is marked not-idle and before the timer tick on this CPU, where a
timer may be added but the ancient base does not get forwarded.
These result in excessive granularity (a 1 jiffy timeout can blow out
to 100s of jiffies), which cause the rcu lockup detector to trigger,
among other things.
Fix this by keeping track of whether the timer base has been idle
since it was last run or forwarded, and if so then forward it before
adding a new timer.
There is still a case where mod_timer optimises the case of a pending
timer mod with the same expiry time, where the timer can see excessive
granularity relative to the new, shorter interval. A comment is added,
but it's not changed because it is an important fastpath for
networking.
This has been tested and found to fix the RCU softlockup messages.
Testing was also done with tracing to measure requested versus
achieved wakeup latencies for all non-deferrable timers in an idle
system (with no lockup watchdogs running). Wakeup latency relative to
absolute latency is calculated (note this suffers from round-up skew
at low absolute times) and analysed:
max avg std
upstream 506.0 1.20 4.68
patched 2.0 1.08 0.15
The bug was noticed due to the lockup detector Kconfig changes
dropping it out of people's .configs and resulting in larger base
clk skew When the lockup detectors are enabled, no CPU can go idle for
longer than 4 seconds, which limits the granularity errors.
Sub-optimal timer behaviour is observable on a smaller scale in that
case:
max avg std
upstream 9.0 1.05 0.19
patched 2.0 1.04 0.11
Fixes: Fixes: a683f390b93f ("timers: Forward the wheel clock whenever possible")
Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Jonathan Cameron <[email protected]>
Tested-by: David Miller <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Stephen Boyd <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: John Stultz <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
|
|
This reverts commit c8c03f1858331e85d397bacccd34ef409aae993c.
It turns out that while fixing the ptmx file descriptor to have the
correct 'struct path' to the associated slave pty is a really good
thing, it breaks some user space tools for a very annoying reason.
The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X)
are on different mounts. That was what caused us to have the wrong path
in the first place (we would mix up the vfsmount of the 'ptmx' node,
with the dentry of the pty slave node), but it also means that now while
we use the right vfsmount, having the pty master open also keeps the pts
mount busy.
And it turn sout that that makes 'pbuilder' very unhappy, as noted by
Stefan Lippers-Hollmann:
"This patch introduces a regression for me when using pbuilder
0.228.7[2] (a helper to build Debian packages in a chroot and to
create and update its chroots) when trying to umount /dev/ptmx (inside
the chroot) on Debian/ unstable (full log and pbuilder configuration
file[3] attached).
[...]
Setting up build-essential (12.3) ...
Processing triggers for libc-bin (2.24-15) ...
I: unmounting dev/ptmx filesystem
W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)"
apparently pbuilder tries to unmount the /dev/pts filesystem while still
holding at least one master node open, which is arguably not very nice,
but we don't break user space even when fixing other bugs.
So this commit has to be reverted.
I'll try to figure out a way to avoid caching the path to the slave pty
in the master pty. The only thing that actually wants that slave pty
path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the
path at that time.
Reported-by: Stefan Lippers-Hollmann <[email protected]>
Cc: Eric W Biederman <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
There's some stuff still up in the air, let's not get stuck with a
subpar ABI. I'll follow up with something better for 4.14.
Signed-off-by: Omar Sandoval <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
discard request usually is very big and easily use all bandwidth budget
of a cgroup. discard request size doesn't really mean the size of data
written, so it doesn't make sense to account it into bandwidth budget.
Jens pointed out treating the size 0 doesn't make sense too, because
discard request does have cost. But it's not easy to find the actual
cost. This patch simply makes the size one sector.
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
CEC support was added for Exynos5 in 4.13, but for the Odroids we need to set
'needs-hpd' as well since CEC is disabled when there is no HDMI hotplug signal,
just as for the exynos4 Odroid-U3.
This is due to the level-shifter that is disabled when there is no HPD, thus
blocking the CEC signal as well. Same close-but-no-cigar board design as the
Odroid-U3.
Tested with my Odroid XU4.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Late arm64 fixes.
They fix very early boot failures with KASLR where the early mapping
of the kernel is incorrect, so the failure mode looks like a hang with
no output. There's also a signal-handling fix when a uaccess routine
faults with a fatal signal pending, which could be used to create
unkillable user tasks using userfaultfd and finally a state leak fix
for the floating pointer registers across a call to exec().
We're still seeing some random issues crop up (inode memory corruption
and spinlock recursion) but we've not managed to reproduce things
reliably enough to debug or bisect them yet.
Summary:
- Fix very early boot failures with KASLR enabled
- Fix fatal signal handling on userspace access from kernel
- Fix leakage of floating point register state across exec()"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: kaslr: Adjust the offset to avoid Image across alignment boundary
arm64: kaslr: ignore modulo offset when validating virtual displacement
arm64: mm: abort uaccess retries upon fatal signal
arm64: fpsimd: Prevent registers leaking across exec
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Here are the (hopefully) last GPIO fixes for v4.13:
- an important core fix to reject invalid GPIOs *before* trying to
obtain a GPIO descriptor for it.
- a driver fix for the mvebu driver IRQ handling"
* tag 'gpio-v4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: mvebu: Fix cause computation in irq handler
gpio: reject invalid gpio before getting gpio_desc
|
|
Add checking for the path component length and verify it is <= the maximum
that the server advertizes via FileFsAttributeInformation.
With this patch cifs.ko will now return ENAMETOOLONG instead of ENOENT
when users to access an overlong path.
To test this, try to cd into a (non-existing) directory on a CIFS share
that has a too long name:
cd /mnt/aaaaaaaaaaaaaaa...
and it now should show a good error message from the shell:
bash: cd: /mnt/aaaaaaaaaaaaaaaa...aaaaaa: File name too long
rh bz 1153996
Signed-off-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
Cc: <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Six minor and error leg fixes, plus one major change: the reversion of
scsi-mq as the default.
We're doing the latter temporarily (with a backport to stable) to give
us time to fix all the issues that turned up with this default before
trying again"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: cxgb4i: call neigh_event_send() to update MAC address
Revert "scsi: default to scsi-mq"
scsi: sd_zbc: Write unlock zone from sd_uninit_cmnd()
scsi: aacraid: Fix out of bounds in aac_get_name_resp
scsi: csiostor: fail probe if fw does not support FCoE
scsi: megaraid_sas: fix error handle in megasas_probe_one
|
|
The df for a SMB2 share triggers a GetInfo call for
FS_FULL_SIZE_INFORMATION. The values returned are used to populate
struct statfs.
The problem is that none of the information returned by the call
contains the total blocks available on the filesystem. Instead we use
the blocks available to the user ie. quota limitation when filling out
statfs.f_blocks. The information returned does contain Actual free units
on the filesystem and is used to populate statfs.f_bfree. For users with
quota enabled, it can lead to situations where the total free space
reported is more than the total blocks on the system ending up with df
reports like the following
# df -h /mnt/a
Filesystem Size Used Avail Use% Mounted on
//192.168.22.10/a 2.5G -2.3G 2.5G - /mnt/a
To fix this problem, we instead populate both statfs.f_bfree with the
same value as statfs.f_bavail ie. CallerAvailableAllocationUnits. This
is similar to what is done already in the code for cifs and df now
reports the quota information for the user used to mount the share.
# df --si /mnt/a
Filesystem Size Used Avail Use% Mounted on
//192.168.22.10/a 2.7G 101M 2.6G 4% /mnt/a
Signed-off-by: Sachin Prabhu <[email protected]>
Signed-off-by: Pierguido Lambri <[email protected]>
Signed-off-by: Steve French <[email protected]>
Cc: <[email protected]>
|
|
On failure to get dsp_ops, dsp_init returns error without assigning ret. ret
is assigned in code path which will never be executed. Fix it.
Fixes: f77d443c4c29 ("ASoC: Intel: Skylake: Fix to free resources for dsp_init failure"
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Subhransu S. Prusty <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Make these const as they are only used during a copy operation.
Done using Coccinelle.
@match disable optional_qualifier@
identifier s;
@@
static struct rt5645_platform_data s = {...};
@ref@
position p;
identifier match.s;
@@
s@p
@good1@
position ref.p;
identifier match.s,f,c;
expression e;
@@
(
e = s@p
|
e = [email protected]
|
c(...,[email protected],...)
|
c(...,s@p,...)
)
@bad depends on !good1@
position ref.p;
identifier match.s;
@@
s@p
@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct rt5645_platform_data s;
Signed-off-by: Bhumika Goyal <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
My previous patch fixed a link error for all at91 platforms when
CONFIG_ARM_CPU_SUSPEND was not set, however this caused another
problem on a configuration that enabled CONFIG_ARCH_AT91 but none
of the individual SoCs, and that also enabled CPU_ARM720 as
the only CPU:
warning: (ARCH_AT91 && SOC_IMX23 && SOC_IMX28 && ARCH_PXA && MACH_MVEBU_V7 && SOC_IMX6 && ARCH_OMAP3 && ARCH_OMAP4 && SOC_OMAP5 && SOC_AM33XX && SOC_DRA7XX && ARCH_EXYNOS3 && ARCH_EXYNOS4 && EXYNOS5420_MCPM && EXYNOS_CPU_SUSPEND && ARCH_VEXPRESS_TC2_PM && ARM_BIG_LITTLE_CPUIDLE && ARM_HIGHBANK_CPUIDLE && QCOM_PM) selects ARM_CPU_SUSPEND which has unmet direct dependencies (ARCH_SUSPEND_POSSIBLE)
arch/arm/kernel/sleep.o: In function `cpu_resume':
(.text+0xf0): undefined reference to `cpu_arm720_suspend_size'
arch/arm/kernel/suspend.o: In function `__cpu_suspend_save':
suspend.c:(.text+0x134): undefined reference to `cpu_arm720_do_suspend'
This improves the hack some more by only selecting ARM_CPU_SUSPEND
for the part that requires it, and changing pm.c to drop the
contents of unused init functions so we no longer refer to
cpu_resume on at91 platforms that don't need it.
Fixes: cc7a938f5f30 ("ARM: at91: select CONFIG_ARM_CPU_SUSPEND")
Acked-by: Alexandre Belloni <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Jack is not detected by default, using jdmode=3 works fine
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Fix jack detection and dmic setup
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
During dsp init failure, the ref count is not incremented and dsp is
powered down. But as the skl driver calls put_core for the init failure it
decrements the dsp core ref count and ref count becomes unbalanced.
This results in dsp core powered up in further runtime suspend/resume
cycles and never powered down.
So increment the ref count before dsp core powerup and for any failure,
decrement in put_core will be balanced.
Signed-off-by: Subhransu S. Prusty <[email protected]>
Acked-By: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
The dev_id passed by the driver in request_threaded_irq is an ebus pointer,
whereas to free_irq it is hdac_bus. Fix by passing correct dev_id to
free_irq.
Signed-off-by: Subhransu S. Prusty <[email protected]>
Acked-By: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
unmap mmio and free memory resources if dsp_init fails.
Signed-off-by: Subhransu S. Prusty <[email protected]>
Acked-By: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
For some dsp init error path, irq and few more resources are not freed.
This results in oops. So, fix it by freeing up the resources on ipc_init
failure.
Signed-off-by: Subhransu S. Prusty <[email protected]>
Acked-By: Vinod Koul <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Set snd_soc_pm_ops for the pm ops to make sure that the ASoC level of PM
operations are going to happen. This is needed to get suspend/resume
working correctly when the audio is using audio-graph-scu-card.
Reported-by: Hiroyuki Yokoyama <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Set snd_soc_pm_ops for the pm ops to make sure that the ASoC level of PM
operations are going to happen. This is needed to get suspend/resume
working correctly when the audio is using audio-graph-card.
Reported-by: Hiroyuki Yokoyama <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Set snd_soc_pm_ops for the pm ops to make sure that the ASoC level of PM
operations are going to happen. This is needed to get suspend/resume
working correctly when the audio is using simple-scu-card.
Reported-by: Hiroyuki Yokoyama <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
wm8524 doesn't register platform, unregister platform is not needed
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Fixes: 2a8bd83af30e ("ASoC: tegra: Remove superfluous snd_soc_jack_free_gpios() call")
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
drm-intel-fixes
gvt-fixes-2017-08-23
- Fix possible null ptr reference in error path (Fred)
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Lenovo G50-70 (17aa:3978) with Conexant codec chip requires the
similar workaround for the inverted stereo dmic like other Lenovo
models.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1020657
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
once error happens in shadow_indirect_ctx function, the variable
wa_ctx->indirect_ctx.obj is not initialized but accessed, so the
kernel null point panic occurs.
Fixes: 894cf7d15634 ("drm/i915/gvt: i915_gem_object_create() returns an error pointer")
Cc: [email protected] # v4.8+
Signed-off-by: fred gao <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Fix a clang build regression and an potential xattr corruption bug"
* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: add missing xattr hash update
ext4: fix clang build regression
|
|
Commit c4ea41ba195d ("binder: use group leader instead of open thread")'
was incomplete and didn't update a check in binder_mmap(), causing all
mmap() calls into the binder driver to fail.
Signed-off-by: Martijn Coenen <[email protected]>
Tested-by: John Stultz <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
acpi_graph_get_child_prop_value() is intended to find a child node with a
certain property value pair. The check
if (!fwnode_property_read_u32(fwnode, prop_name, &nr))
continue;
is faulty: fwnode_property_read_u32() returns zero on success, not on
failure, leading to comparing values only if the searched property was not
found.
Moreover, the check is made against the parent device node instead of
the child one as it should be.
Fixes: 79389a83bc38 (ACPI / property: Add support for remote endpoints)
Reported-by: Hyungwoo Yang <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Cc: 4.12+ <[email protected]> # 4.12+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Commit 2d2a954375a0 (ACPICA: Update two error messages to emit
control method name) causes acpi_evaluate_object_typed() to fail
if its pathname argument is NULL, but some callers of that function
in the kernel, particularly acpi_nondev_subnode_data_ok(), pass
NULL as pathname to it and expect it to work.
For this reason, make acpi_evaluate_object_typed() check if its
pathname argument is NULL and fall back to using the pathname of
its handle argument if that is the case.
Reported-by: Sakari Ailus <[email protected]>
Tested-by: Yang, Hyungwoo <[email protected]>
Fixes: 2d2a954375a0 (ACPICA: Update two error messages to emit control method name)
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Initializing cq_context with ev_queue in create_cq(), leads to NULL pointer
dereference in ib_uverbs_comp_handler(), if application doesnot use completion
channel. This patch fixes the cq_context initialization.
Fixes: 1e7710f3f65 ("IB/core: Change completion channel to use the reworked")
Cc: [email protected] # 4.12
Signed-off-by: Potnuri Bharat Teja <[email protected]>
Reviewed-by: Matan Barak <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
(cherry picked from commit 699a2d5b1b880b4e4e1c7d55fa25659322cf5b51)
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD fix from Lee Jones:
"Revert duplicate commit in da9062-core"
* tag 'mfd-fixes-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
Revert "mfd: da9061: Fix to remove BBAT_CONT register from chip model"
|
|
With 16KB pages and a kernel Image larger than 16MB, the current
kaslr_early_init() logic for avoiding mappings across swapper table
boundaries fails since increasing the offset by kimg_sz just moves the
problem to the next boundary.
This patch rounds the offset down to (1 << SWAPPER_TABLE_SHIFT) if the
Image crosses a PMD_SIZE boundary.
Fixes: afd0e5a87670 ("arm64: kaslr: Fix up the kernel image alignment")
Cc: Ard Biesheuvel <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Neeraj Upadhyay <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
In the KASLR setup routine, we ensure that the early virtual mapping
of the kernel image does not cover more than a single table entry at
the level above the swapper block level, so that the assembler routines
involved in setting up this mapping can remain simple.
In this calculation we add the proposed KASLR offset to the values of
the _text and _end markers, and reject it if they would end up falling
in different swapper table sized windows.
However, when taking the addresses of _text and _end, the modulo offset
(the physical displacement modulo 2 MB) is already accounted for, and
so adding it again results in incorrect results. So disregard the modulo
offset from the calculation.
Fixes: 08cdac619c81 ("arm64: relocatable: deal with physically misaligned ...")
Reviewed-by: Catalin Marinas <[email protected]>
Tested-by: Catalin Marinas <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Cc: Catalin Marinas <[email protected]>
Cc: Laura Abbott <[email protected]>
Cc: [email protected]
Reviewed-by: Steve Capper <[email protected]>
Tested-by: Steve Capper <[email protected]>
Reviewed-by: James Morse <[email protected]>
Tested-by: James Morse <[email protected]>
Signed-off-by: Mark Rutland <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
There are some tricky dependencies between the different stages of
flushing the FPSIMD register state during exec, and these can race
with context switch in ways that can cause the old task's regs to
leak across. In particular, a context switch during the memset() can
cause some of the task's old FPSIMD registers to reappear.
Disabling preemption for this small window would be no big deal for
performance: preemption is already disabled for similar scenarios
like updating the FPSIMD registers in sigreturn.
So, instead of rearranging things in ways that might swap existing
subtle bugs for new ones, this patch just disables preemption
around the FPSIMD state flushing so that races of this type can't
occur here. This brings fpsimd_flush_thread() into line with other
code paths.
Cc: [email protected]
Fixes: 674c242c9323 ("arm64: flush FP/SIMD state correctly after execve()")
Reviewed-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
The 'dmic-delay' property name is different with the dt-binding.
So correct it with 'dmic-wakeup-delay-ms'.
Fixes: 3a6f9dce6116 (ASoC: rk3399_gru_sound: fix recording pop at first attempt)
Signed-off-by: Jeffy Chen <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
When user tries to replace the user-defined control TLV, the kernel
checks the change of its content via memcmp(). The problem is that
the kernel passes the return value from memcmp() as is. memcmp()
gives a non-zero negative value depending on the comparison result,
and this shall be recognized as an error code.
The patch covers that corner-case, return 1 properly for the changed
TLV.
Fixes: 8aa9b586e420 ("[ALSA] Control API - more robust TLV implementation")
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into fixes
Pull "Driver fixes for 4.13" from Alexandre Belloni:
- Multiple EBI/SMC timing setting/calculation fixes
* tag 'at91-ab-4.13-drivers-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
memory: atmel-ebi: Fix smc cycle xlate converter
memory: atmel-ebi: Allow t_DF timings of zero ns
memory: atmel-ebi: Fix smc timing return value evaluation
|
|
This is the same bug as we fixed in commit f6cd7daecff5 ("drm: Release
driver references to handle before making it available again"), but now
the exposure is via the PRIME lookup tables. If we remove the
object/handle from the PRIME lut, then a new request for the same
object/fd will generate a new handle, thus for a short window that
object is known to userspace by two different handles. Fix this by
releasing the driver tracking before PRIME.
Fixes: 0ff926c7d4f0 ("drm/prime: add exported buffers to current fprivs
imported buffer list (v2)")
Signed-off-by: Chris Wilson <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
RT5670 codec driver and its machine driver for Intel CHT assume the
implicit GPIO mapping on the index 0 while BIOS on most devices don't
provide it. The recent commit f10e4bf6632b ("gpio: acpi: Even more
tighten up ACPI GPIO lookups") restricts such cases and it resulted in
a regression where the headset jack setup fails like:
rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2
rt5670 i2c-10EC5672:00: Adding jack GPIO failed
For fixing this, we need to provide the GPIO mapping explicitly in the
machine driver. Also this patch corrects the string to be passed to
gpiolib to match with the pre-given mapping, too.
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115531
Reported-by: Pierre-Louis Bossart <[email protected]>
Tested-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Currently we are searching dai name in snd_soc_find_dai, which could
either be dai driver name or component device name(for legacy naming).
Allow searching dai driver name in snd_soc_find_dai too, so that we can
use dai driver name to find legacy naming dais.
Signed-off-by: Jeffy Chen <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|