| Age | Commit message (Collapse) | Author |
|---|
|
When the AP is advertising limited TX power, the message can be
printed over and over again. Suppress it when the power level
isn't changing.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=106011
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
During reprogramming, mac80211 currently first adds all the channel
contexts, then binds them to the vifs and then goes to reconfigure
all the interfaces. Drivers might, perhaps implicitly, rely on the
operation order for certain things that typically happen within a
single function elsewhere in mac80211. To avoid problems with that,
reorder the code in mac80211's restart/reprogramming to work fully
within the interface loop so that the order of operations is like
in normal operation.
For iwlwifi, this fixes a firmware crash when reprogramming with an
AP/GO interface active.
Reported-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When reconfiguration during resume fails while a scan is pending
for completion work, that work will never run, and the scan will
be stuck forever. Factor out the code to recover this and call it
also in ieee80211_handle_reconfig_failure().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Free cached keys if the last early return path is taken.
Signed-off-by: Ola Olsson <ola.olsson@sonymobile.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Compared to cfg80211_rdev_free_wowlan in core.h,
the error goto label lacks the freeing of nd_config.
Fix that.
Signed-off-by: Ola Olsson <ola.olsson@sonymobile.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The first leak occurs when entering the default case
in the switch for the initiator in set_regdom.
The second leaks a platform_device struct if the
platform registration in regulatory_init succeeds but
the sub sequent regulatory hint fails due to no memory.
Signed-off-by: Ola Olsson <ola.olsson@sonymobile.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
__user_swpX_asm maybe failed in first STREX operation, emulate_swpX
will try again, but the *data has been changed in first time. which
causes the result is wrong.
This patch is to fix this issue. When STREX succeed, change the *data.
if it fail, *data is not changed.
Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
In cpu_v7_do_suspend routine, r11 is used while it is NOT
saved/restored, different compiler may have different usage
of ARM general registers, so it may cause issues during
calling cpu_v7_do_suspend.
We meet kernel fault occurs when using GCC 4.8.3, r11 contains
valid value before calling into cpu_v7_do_suspend, but when returned
from this routine, r11 is corrupted and lead to kernel fault.
Doing save/restore for those corrupted registers is a must in
assemble code.
Signed-off-by: Anson Huang <Anson.Huang@freescale.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Cc: <stable@vger.kernel.org> # v3.3+
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The uaccess_with_memcpy() code is currently incompatible with the SW
PAN code: it takes locks within the region that we've changed the DACR,
potentially sleeping as a result. As we do not save and restore the
DACR across co-operative sleep events, can lead to an incorrect DACR
value later in this code path.
Reported-by: Peter Rosin <peda@axentia.se>
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Gateworks Ventana boards seem to need "RGMII-ID" (internal delay)
PHY mode, instead of simple "RGMII", for their Marvell 88E1510
transceiver. Otherwise, the Ethernet MAC doesn't work with Marvell PHY
driver (TX doesn't seem to work correctly).
Tested on GW5400 rev. C.
This bug affects ARM Fedora 23.
Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
Acked-by: Tim Harvey <tharvey@gateworks.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The 'assigned-clock-parents' and 'assigned-clock-rates' list
should corresponding to the 'assigned-clocks' property clock list.
Signed-off-by: Bai Ping <b51503@freescale.com>
Fixes: ed339363de1b ("ARM: dts: imx6qdl-sabreauto: Allow HDMI and LVDS to work simultaneously")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
skb_reorder_vlan_header is called after the vlan header has
been pulled. As a result the offset of the begining of
the mac header has been incrased by 4 bytes (VLAN_HLEN).
When moving the mac addresses, include this incrase in
the offset calcualation so that the mac addresses are
copied correctly.
Fixes: a6e18ff1117 (vlan: Fix untag operations of stacked vlans with REORDER_HEADER off)
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: Vladislav Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Reported-by: Dmitry Vyukov <dvyukov@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Ethernet AVB does not support 10 Mbps transfer speed.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The driver never calls cpu_to_edmac() when writing the descriptor address
and edmac_to_cpu() when reading it, although it should -- fix this.
Note that the frame/buffer length descriptor field accesses also need fixing
but since they are both 16-bit we can't use {cpu|edmac}_to_{edmac|cpu}()...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For the little-endian SH771x kernels the driver has to byte-swap the RX/TX
buffers, however yet unset physcial address from the TX descriptor is used
to call sh_eth_soft_swap(). Use 'skb->data' instead...
Fixes: 31fcb99d9958 ("net: sh_eth: remove __flush_purge_region")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
David Wilder reported crashes caused by dst reuse.
<quote David>
I am seeing a crash on a distro V4.2.3 kernel caused by a double
release of a dst_entry. In ipv4_dst_destroy() the call to
list_empty() finds a poisoned next pointer, indicating the dst_entry
has already been removed from the list and freed. The crash occurs
18 to 24 hours into a run of a network stress exerciser.
</quote>
Thanks to his detailed report and analysis, we were able to understand
the core issue.
IP early demux can associate a dst to skb, after a lookup in TCP/UDP
sockets.
When socket cache is not properly set, we want to store into
sk->sk_dst_cache the dst for future IP early demux lookups,
by acquiring a stable refcount on the dst.
Problem is this acquisition is simply using an atomic_inc(),
which works well, unless the dst was queued for destruction from
dst_release() noticing dst refcount went to zero, if DST_NOCACHE
was set on dst.
We need to make sure current refcount is not zero before incrementing
it, or risk double free as David reported.
This patch, being a stable candidate, adds two new helpers, and use
them only from IP early demux problematic paths.
It might be possible to merge in net-next skb_dst_force() and
skb_dst_force_safe(), but I prefer having the smallest patch for stable
kernels : Maybe some skb_dst_force() callers do not expect skb->dst
can suddenly be cleared.
Can probably be backported back to linux-3.6 kernels
Reported-by: David J. Wilder <dwilder@us.ibm.com>
Tested-by: David J. Wilder <dwilder@us.ibm.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
status OK)
3. Modes are moved from the probed_modes list to the actual
mode list. If a mode already on the mode list is deemed
to match one of the probed modes, the duplicate is dropped
and the mode status updated to OK. After this the
probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
with an appropriate debug message.
What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).
I broke that in
commit 05acaec334fc ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.
Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.
Cc: stable@vger.kernel.org
Cc: Adam Jackson <ajax@redhat.com>
Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
Merge "Allwinner fixes for 4.4" from Maxime Ripard:
Allwinner fixes for 4.4
Two patches, one to fix the touchscreen axis on one Allwinner board, and
the other one fixing a mutex unlocking issue on one error path in the RSB
driver.
* tag 'sunxi-fixes-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
bus: sunxi-rsb: unlock on error in sunxi_rsb_read()
ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
Here are some i915 fixes for v4.4, sorry for being late this week.
* tag 'drm-intel-fixes-2015-12-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Do a better job at disabling primary plane in the noatomic case.
drm/i915/skl: Double RC6 WRL always on
drm/i915/skl: Disable coarse power gating up until F0
drm/i915: Remove incorrect warning in context cleanup
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes
omapdrm fix for 4.4
* tag 'omapdrm-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: fix fbdev pix format to support all platforms
|
|
The Kconfig currently controlling compilation of this code is:
cpuidle/Kconfig.arm:config ARM_EXYNOS_CPUIDLE
cpuidle/Kconfig.arm: bool "Cpu Idle Driver for the Exynos processors"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The Kconfig currently controlling compilation of this code is:
cpuidle/Kconfig.arm:config ARM_U8500_CPUIDLE
cpuidle/Kconfig.arm: bool "Cpu Idle Driver for the ST-E u8500 processors"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The Kconfig currently controlling compilation of this code is:
drivers/cpuidle/Kconfig.arm:config ARM_CLPS711X_CPUIDLE
drivers/cpuidle/Kconfig.arm: bool "CPU Idle Driver for CLPS711X processors"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch converts AML debugger into a loadable module.
Note that, it implements driver unloading at the level dependent on the
module reference count. Which means if ACPI debugger is being used by a
userspace program, "rmmod acpi_dbg" should result in failure.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch adds a userspace tool to access Linux kernel AML debugger
interface.
Tow modes are supported by this tool:
1. Interactive: Users are able to launch a debugging shell to talk with
in-kernel AML debugger.
Note that it's user duty to ensure kernel runtime integrity by using
this debugging tool:
A. Some control methods evaluated by the users may result in kernel
panics if those control methods shouldn't be evaluated by the OSPMs
according to the current BIOS/OS configurations.
B. Currently if a single stepping evaluation couldn't run to an end,
then the synchronization primitives acquired by the evaluation may
block normal OSPM control method evaluations.
2. Batch: Users are able to execute debugger commands in a script.
Note that in addition to the above duties, it's user duty to ensure
script runtime integrity by using this debugging tool in this mode:
C. Currently only those commands that are not used for single stepping
are suitable to be used in this mode.
D. If the execution of the command may cause a failure that could result
in an endless kernel execution, the execution of the script may also
get blocked.
To exit the utility, currently "exit/quit" commands are recommended, but
ctrl-C" can also be used.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by
userspace programs to access ACPICA debugger functionalities.
Known issue:
1. IO flush support
acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can
be used by acpi_dbg module to implement .flush() filesystem operation.
While this patch doesn't go that far. It then becomes userspace tool's
duty now to flush old commands before executing new batch mode commands.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
different stub mechanism
ACPICA commit 11522d6b894054fc4d62dd4f9863ec151296b386
The ACPI_DEBUGGER_EXEC is a problem now when the debugger code is compiled
but runtime disabled. They actually will get executed in this situation.
Although such executions are harmless if we can correctly make
acpi_db_single_step() a runtime stub, users may still do not want to see the
debugger print messages logged into OSPMs' kernel logs when a debugger
driver is not loaded to enable the debugger during runtime.
This patch fixes this issue by introducing new stub mechanism instead of
ACPI_DEBUGGER_EXEC. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/11522d6b
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The following mechanisms are OSPM specific:
1. Redirect output destination to console: no file redirection will be
needed by an in-kernel debugger, there is even no file can be accessed
when the debugger is running in the kernel mode.
2. Output command prompts: programs other than acpiexec can have different
prompt characters and the prompt characters may be implemented as a
special character sequence to form a char device IO protocol.
3. Command ready/complete handshake: OSPM debugger may wait more conditions
to implement OSPM specific semantics (for example, FIFO full/empty
conditions for O_NONBLOCK or IO open/close conditions).
Leaving such OSPM specific stuffs in the ACPICA debugger core blocks
Linux debugger IO driver implementation.
Several new OSL APIs are provided by this patch:
1. acpi_os_initialize_command_signals: initialize command handshake mechanism
or any other OSPM specific stuffs.
2. acpi_os_terminate_command_signals: reversal of
acpi_os_initialize_command_signals.
3. acpi_os_wait_command_ready: putting debugger task into wait state when a
command is not ready. OSPMs can terminate command loop by returning
AE_CTRL_TERMINATE from this API. Normally, wait_event() or
wait_for_multiple_object() may be used to implement this API.
4. acpi_os_notify_command_complete: putting user task into running state when a
command has been completed. OSPMs can terminate command loop by
returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or
set_event() may be used to implement this API.
This patch also converts current command signaling implementation into a
generic debugger layer (osgendbg.c) to be used by the existing OSPMs or
acpiexec, in return, Linux can have chance to implement its own command
handshake mechanism. This patch also implements acpiexec batch mode in a
multi-threading mode comaptible style as a demo (this can be confirmed by
configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode
is still working). Lv Zheng.
Note that the OSPM specific command handshake mechanism is required by
Linux kernel because:
1. Linux kernel trends to use wait queue to synchronize two threads, using
mutexes to achieve that will cause false "dead lock" warnings.
2. The command handshake mechanism implemented by ACPICA is implemented in
this way because of a design issue in debugger IO streaming. Debugger IO
outputs are simply cached using a giant buffer, this should be tuned by
Linux in the future.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit f9d5c6c9a25e9f5ac05458bfcd8b381e21bb2ba5
ACPICA BZ 1205. Colin Ian King.
Link: https://bugs.acpica.org/show_bug.cgi?id=1205
Link: https://github.com/acpica/acpica/commit/f9d5c6c9
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* powercap:
powercap / RAPL: fix BIOS lock check
* pm-cpufreq:
cpufreq: intel_pstate: Minor cleanup for FRAC_BITS
cpufreq: tegra: add regulator dependency for T124
* pm-domains:
PM / Domains: Allow runtime PM callbacks to be re-used during system PM
|
|
Commit 3365711df024 ("sh_eth: WARN on access to a register not implemented in
in a particular chip") added WARN_ON() to sh_eth_{read|write}(), thus making
it unacceptable for these functions to be *inline* anymore. Remove *inline*
and move the functions from the header to the driver itself. Below is our
code economy with ARM gcc 4.7.3:
$ size drivers/net/ethernet/renesas/sh_eth.o{~,}
text data bss dec hex filename
32489 1140 0 33629 835d drivers/net/ethernet/renesas/sh_eth.o~
25413 1140 0 26553 67b9 drivers/net/ethernet/renesas/sh_eth.o
Suggested-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
dwmac-sunxi has 2 callbacks that were called from stmmac_platform as
part of the probe and remove sequences.
Ater the conversion of dwmac-sunxi into a standalone platform driver,
the .init function is called before calling into the stmmac driver
core, but .exit is not called to clean up if stmmac returns an error.
This patch fixes the probe error path. This properly cleans up and
releases resources when the driver core fails to probe.
Cc: Joachim Eastwood <manabian@gmail.com>
Fixes: 9a9e9a1edee8 ("stmmac: dwmac-sunxi: turn setup callback into a
probe function")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
郭永刚 reported that one could simply crash the kernel as root by
using a simple program:
int socket_fd;
struct sockaddr_in addr;
addr.sin_port = 0;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_family = 10;
socket_fd = socket(10,3,0x40000000);
connect(socket_fd , &addr,16);
AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.
This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.
kernel: Call Trace:
kernel: [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
kernel: [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
kernel: [<ffffffff81645069>] SYSC_connect+0xd9/0x110
kernel: [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
kernel: [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
kernel: [<ffffffff81645e0e>] SyS_connect+0xe/0x10
kernel: [<ffffffff81779515>] tracesys_phase2+0x84/0x89
I found no particular commit which introduced this problem.
CVE: CVE-2015-8543
Cc: Cong Wang <cwang@twopensource.com>
Reported-by: 郭永刚 <guoyonggang@360.cn>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
mdiobus_alloc() might return NULL, but its return value is not
checked in mdio_mux_init(). This could potentially lead to a NULL
pointer dereference. Fix it by checking the return value
Fixes: 0ca2997d1452 ("netdev/of/phy: Add MDIO bus multiplexer support.")
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The commit 33db4125ec74 ("openvswitch: Rename LABEL->LABELS") left
over an old OVS_CT_ATTR_LABEL instance, fix it.
Fixes: 33db4125ec74 ("openvswitch: Rename LABEL->LABELS")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Joe Stringer <joe@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
New system call added in
commit a8ca5d0ecbdde5cc3d7accacbd69968b0c98764e
mm: mlock: add new mlock system call
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Pablo Neira Ayuso says:
====================
netfilter fixes for net
The following patchset contains Netfilter fixes for you net tree,
specifically for nf_tables and nfnetlink_queue, they are:
1) Avoid a compilation warning in nfnetlink_queue that was introduced
in the previous merge window with the simplification of the conntrack
integration, from Arnd Bergmann.
2) nfnetlink_queue is leaking the pernet subsystem registration from
a failure path, patch from Nikolay Borisov.
3) Pass down netns pointer to batch callback in nfnetlink, this is the
largest patch and it is not a bugfix but it is a dependency to
resolve a splat in the correct way.
4) Fix a splat due to incorrect socket memory accounting with nfnetlink
skbuff clones.
5) Add missing conntrack dependencies to NFT_DUP_IPV4 and NFT_DUP_IPV6.
6) Traverse the nftables commit list in reverse order from the commit
path, otherwise we crash when the user applies an incremental update
via 'nft -f' that deletes an object that was just introduced in this
batch, from Xin Long.
Regarding the compilation warning fix, many people have sent us (and
keep sending us) patches to address this, that's why I'm including this
batch even if this is not critical.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The current handling of accesses to guest MSR_TSC_AUX returns error if
vcpu does not support rdtscp, though those accesses are initiated by
host. This can result in the reboot failure of some versions of
QEMU. This patch fixes this issue by passing those host initiated
accesses for further handling instead.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Not doing so is a bug and might trigger a BUG_ON in
handle_mm_fault(). So add the proper permission checks
before calling into mm code.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
The handle_mm_fault function expects the caller to do the
access checks. Not doing so and calling the function with
wrong permissions is a bug (catched by a BUG_ON).
So fix this bug by adding proper access checking to the io
page-fault code in the AMD IOMMUv2 driver.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Otherwise we keep missing patches related to this driver.
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
will likely perform same IPIs as would have the guest.
More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
guest's address on remote CPU (when, for example, VCPU from another guest
is running there).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
|
Currently the provided initial value for bcm2835_gpio_direction_output
has no effect. So fix this issue by changing the value before
changing the GPIO direction. As a result we need to move the function below
bcm2835_gpio_set.
Suggested-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Fixes: e1b2dc70cd5b ("pinctrl: add bcm2835 driver")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
and causes noisy "cannot get freq at ep 0x1" messages when playback
starts.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AudioQuest DragonFly DAC reports a volume control range of 0..50
(0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
is obviously incorrect and would cause software using the dB information
in e.g. volume sliders to have a massive volume difference in 100..102%
range.
Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
devices") added a dB range mapping for it with range 0..50 dB.
However, the actual volume mapping seems to be neither linear volume nor
linear dB scale, but instead quite close to the cubic mapping e.g.
alsamixer uses, with a range of approx. -53...0 dB.
Replace the previous quirk with a custom dB mapping based on some basic
output measurements, using a 10-item range TLV (which will still fit in
alsa-lib MAX_TLV_RANGE_SIZE).
Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.
v2: incorporated Takashi Iwai's suggestion for the quirk application
method
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
If a interrupt chip utilizes chip->buslock then free_irq() can
deadlock in the following way:
CPU0 CPU1
interrupt(X) (Shared or spurious)
free_irq(X) interrupt_thread(X)
chip_bus_lock(X)
irq_finalize_oneshot(X)
chip_bus_lock(X)
synchronize_irq(X)
synchronize_irq() waits for the interrupt thread to complete,
i.e. forever.
Solution is simple: Drop chip_bus_lock() before calling
synchronize_irq() as we do with the irq_desc lock. There is nothing to
be protected after the point where irq_desc lock has been released.
This adds chip_bus_lock/unlock() to the remove_irq() code path, but
that's actually correct in the case where remove_irq() is called on
such an interrupt. The current users of remove_irq() are not affected
as none of those interrupts is on a chip which requires buslock.
Reported-by: Fredrik Markström <fredrik.markstrom@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
|
|
omap_fbdev always creates a framebuffer with ARGB8888 pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB8888, and on
OMAP2 none of the overlays support ARGB888.
This patch changes the omap_fbdev's fb to XRGB8888, which is supported
by all platforms.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The VRF driver cycles netdevs when an interface is enslaved or released:
the down event is used to flush neighbor and route tables and the up
event (if the interface was already up) effectively moves local and
connected routes to the proper table.
As of 4f823defdd5b the local route is left hanging around after a link
down, so when a netdev is moved from one VRF to another (or released
from a VRF altogether) local routes are left in the wrong table.
Fix by handling the NETDEV_CHANGEUPPER event. When the upper dev is
an L3mdev then call fib_disable_ip to flush all routes, local ones
to.
Fixes: 4f823defdd5b ("ipv4: fix to not remove local route on link down")
Cc: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
printf() has a dedicated specifier to print MAC addresses. Use it instead of
pushing each byte via stack.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
