OSDN Git Service
Xin Long [Tue, 7 Feb 2017 12:56:08 +0000 (20:56 +0800)]
sctp: check af before verify address in sctp_addr_id2transport
[ Upstream commit
912964eacb111551db73429719eb5fadcab0ff8a ]
Commit
6f29a1306131 ("sctp: sctp_addr_id2transport should verify the
addr before looking up assoc") invoked sctp_verify_addr to verify the
addr.
But it didn't check af variable beforehand, once users pass an address
with family = 0 through sockopt, sctp_get_af_specific will return NULL
and NULL pointer dereference will be caused by af->sockaddr_len.
This patch is to fix it by returning NULL if af variable is NULL.
Fixes:
6f29a1306131 ("sctp: sctp_addr_id2transport should verify the addr before looking up assoc")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jack Morgenstein [Mon, 16 Jan 2017 16:31:39 +0000 (18:31 +0200)]
net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV
[ Upstream commit
9577b174cd0323d287c994ef0891db71666d0765 ]
When running SRIOV, warnings for SRQ LIMIT events flood the Hypervisor's
message log when (correct, normally operating) apps use SRQ LIMIT events
as a trigger to post WQEs to SRQs.
Add more information to the existing debug printout for SRQ_LIMIT, and
output the warning messages only for the SRQ CATAS ERROR event.
Fixes:
acba2420f9d2 ("mlx4_core: Add wrapper functions and comm channel and slave event support to EQs")
Fixes:
e0debf9cb50d ("mlx4_core: Reduce warning message for SRQ_LIMIT event to debug level")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Wed, 11 Jan 2017 06:01:57 +0000 (15:01 +0900)]
perf probe: Fix to probe on gcc generated functions in modules
[ Upstream commit
613f050d68a8ed3c0b18b9568698908ef7bbc1f7 ]
Fix to probe on gcc generated functions on modules. Since
probing on a module is based on its symbol name, it should
be adjusted on actual symbols.
E.g. without this fix, perf probe shows probe definition
on non-exist symbol as below.
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -F in_range*
in_range.isra.12
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
p:probe/in_range nf_nat:in_range+0
With this fix, perf probe correctly shows a probe on
gcc-generated symbol.
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
p:probe/in_range nf_nat:in_range.isra.12+0
This also fixes same problem on online module as below.
$ perf probe -m i915 -D assert_plane
p:probe/assert_plane i915:assert_plane.constprop.134+0
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148411450673.9978.14905987549651656075.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parthasarathy Bhuvaragan [Fri, 13 Jan 2017 14:46:25 +0000 (15:46 +0100)]
tipc: allocate user memory with GFP_KERNEL flag
[ Upstream commit
57d5f64d83ab5b5a5118b1597386dd76eaf4340d ]
Until now, we allocate memory always with GFP_ATOMIC flag.
When the system is under memory pressure and a user tries to send,
the send fails due to low memory. However, the user application
can wait for free memory if we allocate it using GFP_KERNEL flag.
In this commit, we use allocate memory with GFP_KERNEL for all user
allocation.
Reported-by: Rune Torgersen <runet@innovsys.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Karicheri, Muralidharan [Fri, 13 Jan 2017 14:32:34 +0000 (09:32 -0500)]
net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
[ Upstream commit
34c55cf2fc75f8bf6ba87df321038c064cf2d426 ]
Currently dp83867 driver returns error if phy interface type
PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
Fix this by checking also the interface type if a particular delay
value is missing in the phy dt bindings. Also update the DT document
accordingly.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Wed, 11 Jan 2017 05:59:38 +0000 (14:59 +0900)]
perf probe: Fix to show correct locations for events on modules
[ Upstream commit
d2d4edbebe07ddb77980656abe7b9bc7a9e0cdf7 ]
Fix to show correct locations for events on modules by relocating given
address instead of retrying after failure.
This happens when the module text size is big enough, bigger than
sh_addr, because the original code retries with given address + sh_addr
if it failed to find CU DIE at the given address.
Any address smaller than sh_addr always fails and it retries with the
correct address, but addresses bigger than sh_addr will get a CU DIE
which is on the given address (not adjusted by sh_addr).
In my environment(x86-64), the sh_addr of ".text" section is 0x10030.
Since i915 is a huge kernel module, we can see this issue as below.
$ grep "[Tt] .*\[i915\]" /proc/kallsyms | sort | head -n1
ffffffffc0270000 t i915_switcheroo_can_switch [i915]
ffffffffc0270000 + 0x10030 =
ffffffffc0280030, so we'll check
symbols cross this boundary.
$ grep "[Tt] .*\[i915\]" /proc/kallsyms | grep -B1 ^
ffffffffc028\
| head -n 2
ffffffffc027ff80 t haswell_init_clock_gating [i915]
ffffffffc0280110 t valleyview_init_clock_gating [i915]
So setup probes on both function and see what happen.
$ sudo ./perf probe -m i915 -a haswell_init_clock_gating \
-a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
$ sudo ./perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on i915_vga_set_decode:4@gpu/drm/i915/i915_drv.c in i915)
As you can see, haswell_init_clock_gating is correctly shown,
but valleyview_init_clock_gating is not.
With this patch, both events are shown correctly.
$ sudo ./perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
Committer notes:
In my case:
# perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
# perf probe -l
probe:haswell_init_clock_gating (on i915_getparam+432@gpu/drm/i915/i915_drv.c in i915)
probe:valleyview_init_clock_gating (on __i915_printk+240@gpu/drm/i915/i915_drv.c in i915)
#
# readelf -SW /lib/modules/4.9.0+/build/vmlinux | egrep -w '.text|Name'
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 1] .text PROGBITS
ffffffff81000000 200000 822fd3 00 AX 0 0 4096
#
So both are b0rked, now with the fix:
# perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
# perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
#
Both looks correct.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148411436777.9978.1440275861947194930.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Vecera [Fri, 13 Jan 2017 21:38:29 +0000 (22:38 +0100)]
be2net: fix MAC addr setting on privileged BE3 VFs
[ Upstream commit
34393529163af7163ef8459808e3cf2af7db7f16 ]
During interface opening MAC address stored in netdev->dev_addr is
programmed in the HW with exception of BE3 VFs where the initial
MAC is programmed by parent PF. This is OK when MAC address is not
changed when an interfaces is down. In this case the requested MAC is
stored to netdev->dev_addr and later is stored into HW during opening.
But this is not done for all BE3 VFs so the NIC HW does not know
anything about this change and all traffic is filtered.
This is the case of bonding if fail_over_mac == 0 where the MACs of
the slaves are changed while they are down.
The be2net behavior is too restrictive because if a BE3 VF has
the FILTMGMT privilege then it is able to modify its MAC without
any restriction.
To solve the described problem the driver should take care about these
privileged BE3 VFs so the MAC is programmed during opening. And by
contrast unpriviled BE3 VFs should not be allowed to change its MAC
in any case.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Vecera [Fri, 13 Jan 2017 21:38:28 +0000 (22:38 +0100)]
be2net: don't delete MAC on close on unprivileged BE3 VFs
[ Upstream commit
6d928ae590c8d58cfd5cca997d54394de139cbb7 ]
BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Vecera [Fri, 13 Jan 2017 21:38:27 +0000 (22:38 +0100)]
be2net: fix status check in be_cmd_pmac_add()
[ Upstream commit
fe68d8bfe59c561664aa87d827aa4b320eb08895 ]
Return value from be_mcc_notify_wait() contains a base completion status
together with an additional status. The base_status() macro need to be
used to access base status.
Fixes:
e3a7ae2 be2net: Changing MAC Address of a VF was broken
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amelie Delaunay [Thu, 12 Jan 2017 15:09:44 +0000 (16:09 +0100)]
usb: dwc2: gadget: Fix GUSBCFG.USBTRDTIM value
[ Upstream commit
ca02954ada711b08e5b0d84590a631fd63ed39f9 ]
USBTrdTim must be programmed to 0x5 when phy has a UTMI+ 16-bit wide
interface or 0x9 when it has a 8-bit wide interface.
GUSBCFG reset value (Value After Reset: 0x1400) sets USBTrdTim to 0x5.
In case of 8-bit UTMI+, without clearing GUSBCFG.USBTRDTIM mask, USBTrdTim
results in 0xD (0x5 | 0x9).
That's why we need to clear GUSBCFG.USBTRDTIM mask before setting USBTrdTim
value, to ensure USBTrdTim is correctly set in case of 8-bit UTMI+.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Wed, 28 Dec 2016 10:33:48 +0000 (11:33 +0100)]
s390/ctl_reg: make __ctl_load a full memory barrier
[ Upstream commit
e991c24d68b8c0ba297eeb7af80b1e398e98c33f ]
We have quite a lot of code that depends on the order of the
__ctl_load inline assemby and subsequent memory accesses, like
e.g. disabling lowcore protection and the writing to lowcore.
Since the __ctl_load macro does not have memory barrier semantics, nor
any other dependencies the compiler is, theoretically, free to shuffle
code around. Or in other words: storing to lowcore could happen before
lowcore protection is disabled.
In order to avoid this class of potential bugs simply add a full
memory barrier to the __ctl_load macro.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikita Yushchenko [Wed, 11 Jan 2017 18:56:31 +0000 (21:56 +0300)]
swiotlb: ensure that page-sized mappings are page-aligned
[ Upstream commit
602d9858f07c72eab64f5f00e2fae55f9902cfbe ]
Some drivers do depend on page mappings to be page aligned.
Swiotlb already enforces such alignment for mappings greater than page,
extend that to page-sized mappings as well.
Without this fix, nvme hits BUG() in nvme_setup_prps(), because that routine
assumes page-aligned mappings.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Kleikamp [Wed, 11 Jan 2017 19:25:00 +0000 (13:25 -0600)]
coredump: Ensure proper size of sparse core files
[ Upstream commit
4d22c75d4c7b5c5f4bd31054f09103ee490878fd ]
If the last section of a core file ends with an unmapped or zero page,
the size of the file does not correspond with the last dump_skip() call.
gdb complains that the file is truncated and can be confusing to users.
After all of the vma sections are written, make sure that the file size
is no smaller than the current file position.
This problem can be demonstrated with gdb's bigcore testcase on the
sparc architecture.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shaohua Li [Tue, 13 Dec 2016 20:09:56 +0000 (12:09 -0800)]
aio: fix lock dep warning
[ Upstream commit
a12f1ae61c489076a9aeb90bddca7722bf330df3 ]
lockdep reports a warnning. file_start_write/file_end_write only
acquire/release the lock for regular files. So checking the files in aio
side too.
[ 453.532141] ------------[ cut here ]------------
[ 453.533011] WARNING: CPU: 1 PID: 1298 at ../kernel/locking/lockdep.c:3514 lock_release+0x434/0x670
[ 453.533011] DEBUG_LOCKS_WARN_ON(depth <= 0)
[ 453.533011] Modules linked in:
[ 453.533011] CPU: 1 PID: 1298 Comm: fio Not tainted 4.9.0+ #964
[ 453.533011] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.0-1.fc24 04/01/2014
[ 453.533011]
ffff8803a24b7a70 ffffffff8196cffb ffff8803a24b7ae8 0000000000000000
[ 453.533011]
ffff8803a24b7ab8 ffffffff81091ee1 ffff8803a5dba700 00000dba00000008
[ 453.533011]
ffffed0074496f59 ffff8803a5dbaf54 ffff8803ae0f8488 fffffffffffffdef
[ 453.533011] Call Trace:
[ 453.533011] [<
ffffffff8196cffb>] dump_stack+0x67/0x9c
[ 453.533011] [<
ffffffff81091ee1>] __warn+0x111/0x130
[ 453.533011] [<
ffffffff81091f97>] warn_slowpath_fmt+0x97/0xb0
[ 453.533011] [<
ffffffff81091f00>] ? __warn+0x130/0x130
[ 453.533011] [<
ffffffff8191b789>] ? blk_finish_plug+0x29/0x60
[ 453.533011] [<
ffffffff811205d4>] lock_release+0x434/0x670
[ 453.533011] [<
ffffffff8198af94>] ? import_single_range+0xd4/0x110
[ 453.533011] [<
ffffffff81322195>] ? rw_verify_area+0x65/0x140
[ 453.533011] [<
ffffffff813aa696>] ? aio_write+0x1f6/0x280
[ 453.533011] [<
ffffffff813aa6c9>] aio_write+0x229/0x280
[ 453.533011] [<
ffffffff813aa4a0>] ? aio_complete+0x640/0x640
[ 453.533011] [<
ffffffff8111df20>] ? debug_check_no_locks_freed+0x1a0/0x1a0
[ 453.533011] [<
ffffffff8114793a>] ? debug_lockdep_rcu_enabled.part.2+0x1a/0x30
[ 453.533011] [<
ffffffff81147985>] ? debug_lockdep_rcu_enabled+0x35/0x40
[ 453.533011] [<
ffffffff812a92be>] ? __might_fault+0x7e/0xf0
[ 453.533011] [<
ffffffff813ac9bc>] do_io_submit+0x94c/0xb10
[ 453.533011] [<
ffffffff813ac2ae>] ? do_io_submit+0x23e/0xb10
[ 453.533011] [<
ffffffff813ac070>] ? SyS_io_destroy+0x270/0x270
[ 453.533011] [<
ffffffff8111d7b3>] ? mark_held_locks+0x23/0xc0
[ 453.533011] [<
ffffffff8100201a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 453.533011] [<
ffffffff813acb90>] SyS_io_submit+0x10/0x20
[ 453.533011] [<
ffffffff824f96aa>] entry_SYSCALL_64_fastpath+0x18/0xad
[ 453.533011] [<
ffffffff81119190>] ? trace_hardirqs_off_caller+0xc0/0x110
[ 453.533011] ---[ end trace
b2fbe664d1cc0082 ]---
Cc: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Olsa [Tue, 3 Jan 2017 14:24:54 +0000 (15:24 +0100)]
perf/x86: Reject non sampling events with precise_ip
[ Upstream commit
18e7a45af91acdde99d3aa1372cc40e1f8142f7b ]
As Peter suggested [1] rejecting non sampling PEBS events,
because they dont make any sense and could cause bugs
in the NMI handler [2].
[1] http://lkml.kernel.org/r/
20170103094059.GC3093@worktop
[2] http://lkml.kernel.org/r/
1482931866-6018-3-git-send-email-jolsa@kernel.org
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vince@deater.net>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Link: http://lkml.kernel.org/r/20170103142454.GA26251@krava
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Fri, 9 Dec 2016 13:59:00 +0000 (14:59 +0100)]
perf/core: Fix sys_perf_event_open() vs. hotplug
[ Upstream commit
63cae12bce9861cec309798d34701cf3da20bc71 ]
There is problem with installing an event in a task that is 'stuck' on
an offline CPU.
Blocked tasks are not dis-assosciated from offlined CPUs, after all, a
blocked task doesn't run and doesn't require a CPU etc.. Only on
wakeup do we ammend the situation and place the task on a available
CPU.
If we hit such a task with perf_install_in_context() we'll loop until
either that task wakes up or the CPU comes back online, if the task
waking depends on the event being installed, we're stuck.
While looking into this issue, I also spotted another problem, if we
hit a task with perf_install_in_context() that is in the middle of
being migrated, that is we observe the old CPU before sending the IPI,
but run the IPI (on the old CPU) while the task is already running on
the new CPU, things also go sideways.
Rework things to rely on task_curr() -- outside of rq->lock -- which
is rather tricky. Imagine the following scenario where we're trying to
install the first event into our task 't':
CPU0 CPU1 CPU2
(current == t)
t->perf_event_ctxp[] = ctx;
smp_mb();
cpu = task_cpu(t);
switch(t, n);
migrate(t, 2);
switch(p, t);
ctx = t->perf_event_ctxp[]; // must not be NULL
smp_function_call(cpu, ..);
generic_exec_single()
func();
spin_lock(ctx->lock);
if (task_curr(t)) // false
add_event_to_ctx();
spin_unlock(ctx->lock);
perf_event_context_sched_in();
spin_lock(ctx->lock);
// sees event
So its CPU0's store of t->perf_event_ctxp[] that must not go 'missing'.
Because if CPU2's load of that variable were to observe NULL, it would
not try to schedule the ctx and we'd have a task running without its
counter, which would be 'bad'.
As long as we observe !NULL, we'll acquire ctx->lock. If we acquire it
first and not see the event yet, then CPU0 must observe task_curr()
and retry. If the install happens first, then we must see the event on
sched-in and all is well.
I think we can translate the first part (until the 'must not be NULL')
of the scenario to a litmus test like:
C C-peterz
{
}
P0(int *x, int *y)
{
int r1;
WRITE_ONCE(*x, 1);
smp_mb();
r1 = READ_ONCE(*y);
}
P1(int *y, int *z)
{
WRITE_ONCE(*y, 1);
smp_store_release(z, 1);
}
P2(int *x, int *z)
{
int r1;
int r2;
r1 = smp_load_acquire(z);
smp_mb();
r2 = READ_ONCE(*x);
}
exists
(0:r1=0 /\ 2:r1=1 /\ 2:r2=0)
Where:
x is perf_event_ctxp[],
y is our tasks's CPU, and
z is our task being placed on the rq of CPU2.
The P0 smp_mb() is the one added by this patch, ordering the store to
perf_event_ctxp[] from find_get_context() and the load of task_cpu()
in task_function_call().
The smp_store_release/smp_load_acquire model the RCpc locking of the
rq->lock and the smp_mb() of P2 is the context switch switching from
whatever CPU2 was running to our task 't'.
This litmus test evaluates into:
Test C-peterz Allowed
States 7
0:r1=0; 2:r1=0; 2:r2=0;
0:r1=0; 2:r1=0; 2:r2=1;
0:r1=0; 2:r1=1; 2:r2=1;
0:r1=1; 2:r1=0; 2:r2=0;
0:r1=1; 2:r1=0; 2:r2=1;
0:r1=1; 2:r1=1; 2:r2=0;
0:r1=1; 2:r1=1; 2:r2=1;
No
Witnesses
Positive: 0 Negative: 7
Condition exists (0:r1=0 /\ 2:r1=1 /\ 2:r2=0)
Observation C-peterz Never 0 7
Hash=
e427f41d9146b2a5445101d3e2fcaa34
And the strong and weak model agree.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: Will Deacon <will.deacon@arm.com>
Cc: jeremy.linton@arm.com
Link: http://lkml.kernel.org/r/20161209135900.GU3174@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tobias Klauser [Thu, 12 Jan 2017 15:53:11 +0000 (16:53 +0100)]
x86/mpx: Use compatible types in comparison to fix sparse error
[ Upstream commit
453828625731d0ba7218242ef6ec88f59408f368 ]
info->si_addr is of type void __user *, so it should be compared against
something from the same address space.
This fixes the following sparse error:
arch/x86/mm/mpx.c:296:27: error: incompatible types in comparison expression (different address spaces)
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Len Brown [Fri, 13 Jan 2017 06:11:18 +0000 (01:11 -0500)]
x86/tsc: Add the Intel Denverton Processor to native_calibrate_tsc()
[ Upstream commit
695085b4bc7603551db0b3da897b8bf9893ca218 ]
The Intel Denverton microserver uses a 25 MHz TSC crystal,
so we can derive its exact [*] TSC frequency
using CPUID and some arithmetic, eg.:
TSC: 1800 MHz (
25000000 Hz * 216 / 3 /
1000000)
[*] 'exact' is only as good as the crystal, which should be +/- 20ppm
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/306899f94804aece6d8fa8b4223ede3b48dbb59c.1484287748.git.len.brown@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Fri, 13 Jan 2017 10:28:25 +0000 (11:28 +0100)]
mac80211: initialize SMPS field in HT capabilities
[ Upstream commit
43071d8fb3b7f589d72663c496a6880fb097533c ]
ibss and mesh modes copy the ht capabilites from the band without
overriding the SMPS state. Unfortunately the default value 0 for the
SMPS field means static SMPS instead of disabled.
This results in HT ibss and mesh setups using only single-stream rates,
even though SMPS is not supposed to be active.
Initialize SMPS to disabled for all bands on ieee80211_hw_register to
ensure that the value is sane where it is not overriden with the real
SMPS state.
Reported-by: Elektra Wagenrad <onelektra@gmx.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[move VHT TODO comment to a better place]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Hajnoczi [Thu, 5 Jan 2017 10:05:46 +0000 (10:05 +0000)]
pmem: return EIO on read_pmem() failure
[ Upstream commit
d47d1d27fd6206c18806440f6ebddf51a806be4f ]
The read_pmem() function uses memcpy_mcsafe() on x86 where an EFAULT
error code indicates a failed read. Block I/O should use EIO to
indicate failure. Other pmem code paths (like bad blocks) already use
EIO so let's be consistent.
This fixes compatibility with consumers like btrfs that try to parse the
specific error code rather than treat all errors the same.
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Tue, 10 Jan 2017 07:47:50 +0000 (15:47 +0800)]
drm/amd/powerplay: refine vce dpm update code on Cz.
[ Upstream commit
ab8db87b8256e13a62f10af1d32f5fc233c398cc ]
Program HardMin based on the vce_arbiter.ecclk
if ecclk is 0, disable ECLK DPM 0. Otherwise VCE
could hang if switching SCLK from DPM 0 to 6/7
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Tue, 10 Jan 2017 11:26:49 +0000 (19:26 +0800)]
drm/amd/powerplay: fix vce cg logic error on CZ/St.
[ Upstream commit
3731d12dce83d47b357753ffc450ce03f1b49688 ]
can fix Bug 191281: vce ib test failed.
when vce idle, set vce clock gate, so the clock
in vce domain will be disabled.
when need to encode, disable vce clock gate,
enable the clocks to vce engine.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 20 Dec 2016 21:35:50 +0000 (16:35 -0500)]
drm/radeon/si: load special ucode for certain MC configs
[ Upstream commit
ef736d394e85b1bf1fd65ba5e5257b85f6c82325 ]
Special MC ucode is required for these memory configurations.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vadim Lomovtsev [Thu, 12 Jan 2017 15:28:06 +0000 (07:28 -0800)]
net: thunderx: acpi: fix LMAC initialization
[ Upstream commit
7aa4865506a26c607e00bd9794a85785b55ebca7 ]
While probing BGX we requesting appropriate QLM for it's configuration
and get LMAC count by that request. Then, while reading configured
MAC values from SSDT table we need to save them in proper mapping:
BGX[i]->lmac[j].mac = <MAC value>
to later provide for initialization stuff. In order to fill
such mapping properly we need to add lmac index to be used while
acpi initialization since at this moment bgx->lmac_count already contains
actual value.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Wed, 11 Jan 2017 14:54:53 +0000 (14:54 +0000)]
arm64: assembler: make adr_l work in modules under KASLR
[ Upstream commit
41c066f2c4d436c535616fe182331766c57838f0 ]
When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
modules and the core kernel may exceed 4 GB, putting symbols exported
by the core kernel out of the reach of the ordinary adrp/add instruction
pairs used to generate relative symbol references. So make the adr_l
macro emit a movz/movk sequence instead when executing in module context.
While at it, remove the pointless special case for the stack pointer.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Hilman [Thu, 12 Jan 2017 02:18:40 +0000 (18:18 -0800)]
spi: davinci: use dma_mapping_error()
[ Upstream commit
c5a2a394835f473ae23931eda5066d3771d7b2f8 ]
The correct error checking for dma_map_single() is to use
dma_mapping_error().
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roberto Sassu [Wed, 11 Jan 2017 10:06:42 +0000 (11:06 +0100)]
scsi: lpfc: avoid double free of resource identifiers
[ Upstream commit
cd60be4916ae689387d04b86b6fc15931e4c95ae ]
Set variables initialized in lpfc_sli4_alloc_resource_identifiers() to
NULL if an error occurred. Otherwise, lpfc_sli4_driver_resource_unset()
attempts to free the memory again.
Signed-off-by: Roberto Sassu <rsassu@suse.de>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brendan McGrath [Fri, 6 Jan 2017 21:01:38 +0000 (08:01 +1100)]
HID: i2c-hid: Add sleep between POWER ON and RESET
[ Upstream commit
a89af4abdf9b353cdd6f61afc0eaaac403304873 ]
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.
Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.
As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.
See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.
Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin King [Wed, 11 Jan 2017 11:43:10 +0000 (11:43 +0000)]
perf/x86/intel: Use ULL constant to prevent undefined shift behaviour
[ Upstream commit
ad5013d5699d30ded0cdbbc68b93b2aa28222c6e ]
When x86_pmu.num_counters is 32 the shift of the integer constant 1 is
exceeding 32bit and therefor undefined behaviour.
Fix this by shifting 1ULL instead of 1.
Reported-by: CoverityScan CID#1192105 ("Bad bit shift operation")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: http://lkml.kernel.org/r/20170111114310.17928-1-colin.king@canonical.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Thu, 20 Oct 2016 06:52:50 +0000 (08:52 +0200)]
mac80211: recalculate min channel width on VHT opmode changes
[ Upstream commit
d2941df8fbd9708035d66d889ada4d3d160170ce ]
When an associated station changes its VHT operating mode this
can/will affect the bandwidth it's using, and consequently we
must recalculate the minimum bandwidth we need to use. Failure
to do so can lead to one of two scenarios:
1) we use a too high bandwidth, this is benign
2) we use a too narrow bandwidth, causing rate control and
actual PHY configuration to be out of sync, which can in
turn cause problems/crashes
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Tue, 10 Jan 2017 23:13:45 +0000 (23:13 +0000)]
net: phy: marvell: fix Marvell
88E1512 used in SGMII mode
[ Upstream commit
a13c06525ab9ff442924e67df9393a5efa914c56 ]
When an Marvell
88E1512 PHY is connected to a nic in SGMII mode, the
fiber page is used for the SGMII host-side connection. The PHY driver
notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
for the link status, and ends up reading the MAC-side status instead of
the outgoing (copper) link. This leads to incorrect results reported
via ethtool.
If the PHY is connected via SGMII to the host, ignore the fiber page.
However, continue to allow the existing power management code to
suspend and resume the fiber page.
Fixes:
6cfb3bcc0641 ("Marvell phy: check link status in case of fiber link.")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Shevchenko [Mon, 2 Jan 2017 12:07:22 +0000 (14:07 +0200)]
pinctrl: intel: Set pin direction properly
[ Upstream commit
17fab473693e8357a9aa6fee4fbed6c13a34bd81 ]
There are two bits in the PADCFG0 register to configure direction, one per
TX/RX buffers.
For now we wrongly assume that the GPIO is always requested before it is being
used, which is not true when the GPIO is used through irqchip. In this case the
GPIO is never requested and we never enable RX buffer for it.
Fix this by setting both bits accordingly.
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prarit Bhargava [Thu, 5 Jan 2017 15:09:25 +0000 (10:09 -0500)]
perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code
[ Upstream commit
6d6daa20945f3f598e56e18d1f926c08754f5801 ]
hswep_uncore_cpu_init() uses a hardcoded physical package id 0 for the boot
cpu. This works as long as the boot CPU is actually on the physical package
0, which is normaly the case after power on / reboot.
But it fails with a NULL pointer dereference when a kdump kernel is started
on a secondary socket which has a different physical package id because the
locigal package translation for physical package 0 does not exist.
Use the logical package id of the boot cpu instead of hard coded 0.
[ tglx: Rewrote changelog once more ]
Fixes:
cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Harish Chegondi <harish.chegondi@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1483628965-2890-1-git-send-email-prarit@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lucas Stach [Mon, 12 Dec 2016 15:15:17 +0000 (16:15 +0100)]
drm/etnaviv: trick drm_mm into giving out a low IOVA
[ Upstream commit
3546fb0cdac25a79c89d87020566fab52b92867d ]
After rollover of the IOVA space, we want to get a low IOVA address,
otherwise the the games we play by remembering the last IOVA are
pointless. When we search for a free hole with DRM_MM_SEARCH_DEFAULT,
drm_mm will pop the next entry from the free holes stack, which will
likely be a high IOVA. By using DRM_MM_SEARCH_BELOW we can trick
drm_mm into reversing the search and provide us with a low IOVA.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Wladimir van der Laan <laanwj@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Crispin [Wed, 25 Jan 2017 08:20:54 +0000 (09:20 +0100)]
Documentation: devicetree: change the mediatek ethernet compatible string
[ Upstream commit
61976fff20f92aceecc3670f6168bfc57a79e047 ]
When the binding was defined, I was not aware that mt2701 was an earlier
version of the SoC. For sake of consistency, the ethernet driver should
use mt2701 inside the compat string as this is the earliest SoC with the
ethernet core.
The ethernet driver is currently of no real use until we finish and
upstream the DSA driver. There are no users of this binding yet. It should
be safe to fix this now before it is too late and we need to provide
backward compatibility for the mt7623-eth compat string.
Reported-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Tue, 24 Jan 2017 23:18:29 +0000 (15:18 -0800)]
kernel/panic.c: add missing \n
[ Upstream commit
ff7a28a074ccbea999dadbb58c46212cf90984c6 ]
When a system panics, the "Rebooting in X seconds.." message is never
printed because it lacks a new line. Fix it.
Link: http://lkml.kernel.org/r/20170119114751.2724-1-jslaby@suse.cz
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Tue, 24 Jan 2017 06:28:41 +0000 (07:28 +0100)]
ibmveth: Add a proper check for the availability of the checksum features
[ Upstream commit
23d28a859fb847fd7fcfbd31acb3b160abb5d6ae ]
When using the ibmveth driver in a KVM/QEMU based VM, it currently
always prints out a scary error message like this when it is started:
ibmveth
71000003 (unregistered net_device): unable to change
checksum offload settings. 1 rc=-2 ret_attr=
71000003
This happens because the driver always tries to enable the checksum
offloading without checking for the availability of this feature first.
QEMU does not support checksum offloading for the spapr-vlan device,
thus we always get the error message here.
According to the LoPAPR specification, the "ibm,illan-options" property
of the corresponding device tree node should be checked first to see
whether the H_ILLAN_ATTRIUBTES hypercall and thus the checksum offloading
feature is available. Thus let's do this in the ibmveth driver, too, so
that the error message is really only limited to cases where something
goes wrong, and does not occur if the feature is just missing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Balakrishnan Raman [Tue, 24 Jan 2017 04:44:33 +0000 (20:44 -0800)]
vxlan: do not age static remote mac entries
[ Upstream commit
efb5f68f32995c146944a9d4257c3cf8eae2c4a1 ]
Mac aging is applicable only for dynamically learnt remote mac
entries. Check for user configured static remote mac entries
and skip aging.
Signed-off-by: Balakrishnan Raman <ramanb@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 24 Jan 2017 00:43:05 +0000 (16:43 -0800)]
ip6_tunnel: must reload ipv6h in ip6ip6_tnl_xmit()
[ Upstream commit
21b995a9cb093fff33ec91d7cb3822b882a90a1e ]
Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull(),
we must reload any pointer that was related to skb->head
(or skb->data), or risk use after free.
Fixes:
c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael S. Tsirkin [Mon, 23 Jan 2017 19:37:52 +0000 (21:37 +0200)]
virtio_net: fix PAGE_SIZE > 64k
[ Upstream commit
d0fa28f00052391b5df328f502fbbdd4444938b7 ]
I don't have any guests with PAGE_SIZE > 64k but the
code seems to be clearly broken in that case
as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need
more than 8 bit and so the code in mergeable_ctx_to_buf_address
does not give us the actual true size.
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ido Schimmel [Mon, 23 Jan 2017 10:11:42 +0000 (11:11 +0100)]
mlxsw: spectrum_router: Correctly reallocate adjacency entries
[ Upstream commit
a59b7e0246774e28193126fe7fdbbd0ae9c67dcc ]
mlxsw_sp_nexthop_group_mac_update() is called in one of two cases:
1) When the MAC of a nexthop needs to be updated
2) When the size of a nexthop group has changed
In the second case the adjacency entries for the nexthop group need to
be reallocated from the adjacency table. In this case we must write to
the entries the MAC addresses of all the nexthops that should be
offloaded and not only those whose MAC changed. Otherwise, these entries
would be filled with garbage data, resulting in packet loss.
Fixes:
a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kurz [Tue, 24 Jan 2017 16:50:26 +0000 (17:50 +0100)]
vfio/spapr: fail tce_iommu_attach_group() when iommu_data is null
[ Upstream commit
bd00fdf198e2da475a2f4265a83686ab42d998a8 ]
The recently added mediated VFIO driver doesn't know about powerpc iommu.
It thus doesn't register a struct iommu_table_group in the iommu group
upon device creation. The iommu_data pointer hence remains null.
This causes a kernel oops when userspace tries to set the iommu type of a
container associated with a mediated device to VFIO_SPAPR_TCE_v2_IOMMU.
[ 82.585440] mtty mtty: MDEV: Registered
[ 87.655522] iommu: Adding device
83b8f4f2-509f-382f-3c1e-
e6bfe0fa1001 to group 10
[ 87.655527] vfio_mdev
83b8f4f2-509f-382f-3c1e-
e6bfe0fa1001: MDEV: group_id = 10
[ 116.297184] Unable to handle kernel paging request for data at address 0x00000030
[ 116.297389] Faulting instruction address: 0xd000000007870524
[ 116.297465] Oops: Kernel access of bad area, sig: 11 [#1]
[ 116.297611] SMP NR_CPUS=2048
[ 116.297611] NUMA
[ 116.297627] PowerNV
...
[ 116.297954] CPU: 33 PID: 7067 Comm: qemu-system-ppc Not tainted 4.10.0-rc5-mdev-test #8
[ 116.297993] task:
c000000e7718b680 task.stack:
c000000e77214000
[ 116.298025] NIP:
d000000007870524 LR:
d000000007870518 CTR:
0000000000000000
[ 116.298064] REGS:
c000000e77217990 TRAP: 0300 Not tainted (4.10.0-rc5-mdev-test)
[ 116.298103] MSR:
9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
[ 116.298107] CR:
84004444 XER:
00000000
[ 116.298154] CFAR:
c00000000000888c DAR:
0000000000000030 DSISR:
40000000 SOFTE: 1
GPR00:
d000000007870518 c000000e77217c10 d00000000787b0ed c000000eed2103c0
GPR04:
0000000000000000 0000000000000000 c000000eed2103e0 0000000f24320000
GPR08:
0000000000000104 0000000000000001 0000000000000000 d0000000078729b0
GPR12:
c00000000025b7e0 c00000000fe08400 0000000000000001 000001002d31d100
GPR16:
000001002c22c850 00003ffff315c750 0000000043145680 0000000043141bc0
GPR20:
ffffffffffffffed fffffffffffff000 0000000020003b65 d000000007706018
GPR24:
c000000f16cf0d98 d000000007706000 c000000003f42980 c000000003f42980
GPR28:
c000000f1575ac00 c000000003f429c8 0000000000000000 c000000eed2103c0
[ 116.298504] NIP [
d000000007870524] tce_iommu_attach_group+0x10c/0x360 [vfio_iommu_spapr_tce]
[ 116.298555] LR [
d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce]
[ 116.298601] Call Trace:
[ 116.298610] [
c000000e77217c10] [
d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce] (unreliable)
[ 116.298671] [
c000000e77217cb0] [
d0000000077033a0] vfio_fops_unl_ioctl+0x278/0x3e0 [vfio]
[ 116.298713] [
c000000e77217d40] [
c0000000002a3ebc] do_vfs_ioctl+0xcc/0x8b0
[ 116.298745] [
c000000e77217de0] [
c0000000002a4700] SyS_ioctl+0x60/0xc0
[ 116.298782] [
c000000e77217e30] [
c00000000000b220] system_call+0x38/0xfc
[ 116.298812] Instruction dump:
[ 116.298828]
7d3f4b78 409effc8 3d220000 e9298020 3c800140 38a00018 608480c0 e8690028
[ 116.298869]
4800249d e8410018 7c7f1b79 41820230 <
e93e0030>
2fa90000 419e0114 e9090020
[ 116.298914] ---[ end trace
1e10b0ced08b9120 ]---
This patch fixes the oops.
Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ding Pixel [Wed, 18 Jan 2017 09:26:38 +0000 (17:26 +0800)]
drm/amdgpu: check ring being ready before using
[ Upstream commit
c5f21c9f878b8dcd54d0b9739c025ca73cb4c091 ]
Return success when the ring is properly initialized, otherwise return
failure.
Tonga SRIOV VF doesn't have UVD and VCE engines, the initialization of
these IPs is bypassed. The system crashes if application submit IB to
their rings which are not ready to use. It could be a common issue if
IP having ring buffer is disabled for some reason on specific ASIC, so
it should check the ring being ready to use.
Bug: amdgpu_test crashes system on Tonga VF.
Signed-off-by: Ding Pixel <Pixel.Ding@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Sat, 21 Jan 2017 00:05:05 +0000 (16:05 -0800)]
net: dsa: Check return value of phy_connect_direct()
[ Upstream commit
4078b76cac68e50ccf1f76a74e7d3d5788aec3fe ]
We need to check the return value of phy_connect_direct() in
dsa_slave_phy_connect() otherwise we may be continuing the
initialization of a slave network device with a PHY that already
attached somewhere else and which will soon be in error because the PHY
device is in error.
The conditions for such an error to occur are that we have a port of our
switch that is not disabled, and has the same port number as a PHY
address (say both 5) that can be probed using the DSA slave MII bus. We
end-up having this slave network device find a PHY at the same address
as our port number, and we try to attach to it.
A slave network (e.g: port 0) has already attached to our PHY device,
and we try to re-attach it with a different network device, but since we
ignore the error we would end-up initializating incorrect device
references by the time the slave network interface is opened.
The code has been (re)organized several times, making it hard to provide
an exact Fixes tag, this is a bugfix nonetheless.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lendacky, Thomas [Fri, 20 Jan 2017 18:14:13 +0000 (12:14 -0600)]
amd-xgbe: Check xgbe_init() return code
[ Upstream commit
738f7f647371ff4cfc9646c99dba5b58ad142db3 ]
The xgbe_init() routine returns a return code indicating success or
failure, but the return code is not checked. Add code to xgbe_init()
to issue a message when failures are seen and add code to check the
xgbe_init() return code.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zach Ploskey [Sun, 22 Jan 2017 08:47:19 +0000 (00:47 -0800)]
platform/x86: ideapad-laptop: handle ACPI event 1
[ Upstream commit
cfee5d63767b2e7997c1f36420d008abbe61565c ]
On Ideapad laptops, ACPI event 1 is currently not handled. Many models
log "ideapad_laptop: Unknown event: 1" every 20 seconds or so while
running on battery power. Some convertible laptops receive this event
when switching in and out of tablet mode.
This adds and additional case for event 1 in ideapad_acpi_notify to call
ideapad_input_report(priv, vpc_bit), so that the event is reported to
userspace and we avoid unnecessary logging.
Fixes bug #107481 (https://bugzilla.kernel.org/show_bug.cgi?id=107481)
Fixes bug #65751 (https://bugzilla.kernel.org/show_bug.cgi?id=65751)
Signed-off-by: Zach Ploskey <zach@ploskey.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Tue, 17 Jan 2017 22:22:24 +0000 (14:22 -0800)]
iwlwifi: fix kernel crash when unregistering thermal zone
[ Upstream commit
92549cdc288f47f3a98cf80ac5890c91f5876a06 ]
A recent firmware change seems to have enabled thermal zones on the
iwlwifi driver. Unfortunately, my device fails when registering the
thermal zone. This doesn't stop the driver from attempting to unregister
the thermal zone at unload time, triggering a NULL pointer deference in
strlen() off the thermal_zone_device_unregister() path.
Don't unregister if name is NULL, for that case we failed registering.
Do the same for the cooling zone.
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Farman [Fri, 13 Jan 2017 17:48:06 +0000 (12:48 -0500)]
scsi: virtio_scsi: Reject commands when virtqueue is broken
[ Upstream commit
773c7220e22d193e5667c352fcbf8d47eefc817f ]
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the device
has been removed. Later, the removal of the controller sees two CRWs
presented, but there's no further indication of the removal from the
guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when an
entire controller (host) is removed and all associated disks are removed
via the loop in scsi_forget_host. The same call to sd_sync_cache is
made, but because the controller has already been removed, the
Synchronize Cache(10) command is neither issued (and then failed) nor
rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already been
marked as broken (via virtio_break_device in virtio_ccw_remove), but we
still attempt to queue the command only to have it remain there. The
calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these four
kernel messages in the guest (the fourth one does not occur prior to
this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the more
graceful device detach, where the disk device is removed prior to the
controller device.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineeth Remanan Pillai [Thu, 19 Jan 2017 16:35:39 +0000 (08:35 -0800)]
xen-netfront: Fix Rx stall during network stress and OOM
[ Upstream commit
90c311b0eeead647b708a723dbdde1eda3dcad05 ]
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.
The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefano Stabellini [Thu, 19 Jan 2017 18:39:09 +0000 (10:39 -0800)]
swiotlb-xen: update dev_addr after swapping pages
[ Upstream commit
f1225ee4c8fcf09afaa199b8b1f0450f38b8cd11 ]
In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
page is not suitable, we swap it for another page from the swiotlb
pool.
In these cases, we don't update the previously calculated dma address
for the page before calling xen_dma_map_page. Thus, we end up calling
xen_dma_map_page passing the wrong dev_addr, resulting in
xen_dma_map_page mistakenly assuming that the page is foreign when it is
local.
Fix the bug by updating dev_addr appropriately.
This change has no effect on x86, because xen_dma_map_page is a stub
there.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Pooya Keshavarzi <Pooya.Keshavarzi@de.bosch.com>
Tested-by: Pooya Keshavarzi <Pooya.Keshavarzi@de.bosch.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
G. Campana [Thu, 19 Jan 2017 21:37:46 +0000 (23:37 +0200)]
virtio_console: fix a crash in config_work_handler
[ Upstream commit
8379cadf71c3ee8173a1c6fc1ea7762a9638c047 ]
Using control_work instead of config_work as the 3rd argument to
container_of results in an invalid portdev pointer. Indeed, the work
structure is initialized as below:
INIT_WORK(&portdev->config_work, &config_work_handler);
It leads to a crash when portdev->vdev is dereferenced later. This
bug
is triggered when the guest uses a virtio-console without multiport
feature and receives a config_changed virtio interrupt.
Signed-off-by: G. Campana <gcampana@quarkslab.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu Bo [Thu, 1 Dec 2016 21:43:31 +0000 (13:43 -0800)]
Btrfs: fix truncate down when no_holes feature is enabled
[ Upstream commit
91298eec05cd8d4e828cf7ee5d4a6334f70cf69a ]
For such a file mapping,
[0-4k][hole][8k-12k]
In NO_HOLES mode, we don't have the [hole] extent any more.
Commit
c1aa45759e90 ("Btrfs: fix shrinking truncate when the no_holes feature is enabled")
fixed disk isize not being updated in NO_HOLES mode when data is not flushed.
However, even if data has been flushed, we can still have trouble
in updating disk isize since we updated disk isize to 'start' of
the last evicted extent.
Reviewed-by: Chris Mason <clm@fb.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chandan Rajendra [Fri, 23 Dec 2016 09:30:18 +0000 (15:00 +0530)]
Btrfs: Fix deadlock between direct IO and fast fsync
[ Upstream commit
97dcdea076ecef41ea4aaa23d4397c2f622e4265 ]
The following deadlock is seen when executing generic/113 test,
---------------------------------------------------------+----------------------------------------------------
Direct I/O task Fast fsync task
---------------------------------------------------------+----------------------------------------------------
btrfs_direct_IO
__blockdev_direct_IO
do_blockdev_direct_IO
do_direct_IO
btrfs_get_blocks_direct
while (blocks needs to written)
get_more_blocks (first iteration)
btrfs_get_blocks_direct
btrfs_create_dio_extent
down_read(&BTRFS_I(inode) >dio_sem)
Create and add extent map and ordered extent
up_read(&BTRFS_I(inode) >dio_sem)
btrfs_sync_file
btrfs_log_dentry_safe
btrfs_log_inode_parent
btrfs_log_inode
btrfs_log_changed_extents
down_write(&BTRFS_I(inode) >dio_sem)
Collect new extent maps and ordered extents
wait for ordered extent completion
get_more_blocks (second iteration)
btrfs_get_blocks_direct
btrfs_create_dio_extent
down_read(&BTRFS_I(inode) >dio_sem)
--------------------------------------------------------------------------------------------------------------
In the above description, Btrfs direct I/O code path has not yet started
submitting bios for file range covered by the initial ordered
extent. Meanwhile, The fast fsync task obtains the write semaphore and
waits for I/O on the ordered extent to get completed. However, the
Direct I/O task is now blocked on obtaining the read semaphore.
To resolve the deadlock, this commit modifies the Direct I/O code path
to obtain the read semaphore before invoking
__blockdev_direct_IO(). The semaphore is then given up after
__blockdev_direct_IO() returns. This allows the Direct I/O code to
complete I/O on all the ordered extents it creates.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 19 Jan 2017 03:44:42 +0000 (19:44 -0800)]
gianfar: Do not reuse pages from emergency reserve
[ Upstream commit
69fed99baac186013840ced3524562841296034f ]
A driver using dev_alloc_page() must not reuse a page that had to
use emergency memory reserve.
Otherwise all packets using this page will be immediately dropped,
unless for very specific sockets having SOCK_MEMALLOC bit set.
This issue might be hard to debug, because only a fraction of the RX
ring buffer would suffer from drops.
Fixes:
75354148ce69 ("gianfar: Add paged allocation and Rx S/G")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Wed, 18 Jan 2017 13:29:21 +0000 (14:29 +0100)]
objtool: Fix IRET's opcode
[ Upstream commit
b5b46c4740aed1538544f0fa849c5b76c7823469 ]
The IRET opcode is 0xcf according to the Intel manual and also to objdump of my
vmlinux:
1ea8: 48 cf iretq
Fix the opcode in arch_decode_instruction().
The previous value (0xc5) seems to correspond to LDS.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170118132921.19319-1-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Wed, 18 Jan 2017 14:14:17 +0000 (15:14 +0100)]
bpf: don't trigger OOM killer under pressure with map alloc
[ Upstream commit
d407bd25a204bd66b7346dde24bd3d37ef0e0b05 ]
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Chan [Wed, 18 Jan 2017 03:07:19 +0000 (22:07 -0500)]
bnxt_en: Fix "uninitialized variable" bug in TPA code path.
[ Upstream commit
719ca8111402aa6157bd83a3c966d184db0d8956 ]
In the TPA GRO code path, initialize the tcp_opt_len variable to 0 so
that it will be correct for packets without TCP timestamps. The bug
caused the SKB fields to be incorrectly set up for packets without
TCP timestamps, leading to these packets being rejected by the stack.
Reported-by: Andy Gospodarek <andrew.gospodarek@broadocm.com>
Acked-by: Andy Gospodarek <andrew.gospodarek@broadocm.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Igor Druzhinin [Tue, 17 Jan 2017 20:49:38 +0000 (20:49 +0000)]
xen-netback: protect resource cleaning on XenBus disconnect
[ Upstream commit
f16f1df65f1cf139ff9e9f84661e6573d6bb27fc ]
vif->lock is used to protect statistics gathering agents from using the
queue structure during cleaning.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Igor Druzhinin [Tue, 17 Jan 2017 20:49:37 +0000 (20:49 +0000)]
xen-netback: fix memory leaks on XenBus disconnect
[ Upstream commit
9a6cdf52b85ea5fb21d2bb31e4a7bc61b79923a7 ]
Eliminate memory leaks introduced several years ago by cleaning the
queue resources which are allocated on XenBus connection event. Namely, queue
structure array and pages used for IO rings.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eran Ben Elisha [Tue, 17 Jan 2017 17:19:17 +0000 (19:19 +0200)]
net: ethtool: Initialize buffer when querying device channel settings
[ Upstream commit
31a86d137219373c3222ca5f4f912e9a4d8065bb ]
Ethtool channels respond struct was uninitialized when querying device
channel boundaries settings. As a result, unreported fields by the driver
hold garbage. This may cause sending unsupported params to driver.
Fixes:
8bf368620486 ('ethtool: ensure channel counts are within bounds ...')
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
CC: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gavin Shan [Thu, 5 Jan 2017 23:39:49 +0000 (10:39 +1100)]
powerpc/eeh: Enable IO path on permanent error
[ Upstream commit
387bbc974f6adf91aa635090f73434ed10edd915 ]
We give up recovery on permanent error, simply shutdown the affected
devices and remove them. If the devices can't be put into quiet state,
they spew more traffic that is likely to cause another unexpected EEH
error. This was observed on "p8dtu2u" machine:
0002:00:00.0 PCI bridge: IBM Device 03dc
0002:01:00.0 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.1 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.2 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.3 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
On P8 PowerNV platform, the IO path is frozen when shutdowning the
devices, meaning the memory registers are inaccessible. It is why
the devices can't be put into quiet state before removing them.
This fixes the issue by enabling IO path prior to putting the devices
into quiet state.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Sat, 24 Dec 2016 03:56:56 +0000 (19:56 -0800)]
net: korina: Fix NAPI versus resources freeing
commit
e6afb1ad88feddf2347ea779cfaf4d03d3cd40b6 upstream.
Commit
beb0babfb77e ("korina: disable napi on close and restart")
introduced calls to napi_disable() that were missing before,
unfortunately this leaves a small window during which NAPI has a chance
to run, yet we just freed resources since korina_free_ring() has been
called:
Fix this by disabling NAPI first then freeing resource, and make sure
that we also cancel the restart task before doing the resource freeing.
Fixes:
beb0babfb77e ("korina: disable napi on close and restart")
Reported-by: Alexandros C. Couloumbis <alex@ozo.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhou Chengming [Mon, 16 Jan 2017 03:21:11 +0000 (11:21 +0800)]
perf/x86/intel: Handle exclusive threadid correctly on CPU hotplug
[ Upstream commit
4e71de7986386d5fd3765458f27d612931f27f5e ]
The CPU hotplug function intel_pmu_cpu_starting() sets
cpu_hw_events.excl_thread_id unconditionally to 1 when the shared exclusive
counters data structure is already availabe for the sibling thread.
This works during the boot process because the first sibling gets threadid
0 assigned and the second sibling which shares the data structure gets 1.
But when the first thread of the core is offlined and onlined again it
shares the data structure with the second thread and gets exclusive thread
id 1 assigned as well.
Prevent this by checking the threadid of the already online thread.
[ tglx: Rewrote changelog ]
Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
Cc: NuoHan Qiao <qiaonuohan@huawei.com>
Cc: ak@linux.intel.com
Cc: peterz@infradead.org
Cc: kan.liang@intel.com
Cc: dave.hansen@linux.intel.com
Cc: eranian@google.com
Cc: qiaonuohan@huawei.com
Cc: davidcc@google.com
Cc: guohanjun@huawei.com
Link: http://lkml.kernel.org/r/1484536871-3131-1-git-send-email-zhouchengming1@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alvaro G. M [Tue, 17 Jan 2017 08:08:16 +0000 (09:08 +0100)]
net: phy: dp83848: add DP83620 PHY support
[ Upstream commit
93b43fd137cd8865adf9978ab9870a344365d3af ]
This PHY with fiber support is register compatible with DP83848,
so add support for it.
Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 17 Jan 2017 20:06:58 +0000 (15:06 -0500)]
drm/amdgpu: add support for new hainan variants
[ Upstream commit
17324b6add82d6c0bf119f1d1944baef392a4e39 ]
New hainan parts require updated smc firmware.
Cc: Sonny Jiang <sonny.jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Tue, 10 Jan 2017 12:03:59 +0000 (20:03 +0800)]
drm/amdgpu: fix program vce instance logic error.
[ Upstream commit
50a1ebc70a2803deb7811fc73fb55d70e353bc34 ]
need to clear bit31-29 in GRBM_GFX_INDEX,
then the program can be valid.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quinn Tran [Sat, 24 Dec 2016 02:06:13 +0000 (18:06 -0800)]
qla2xxx: Fix erroneous invalid handle message
[ Upstream commit
4f060736f29a960aba8e781a88837464756200a8 ]
Termination of Immediate Notify IOCB was using wrong
IOCB handle. IOCB completion code was unable to find
appropriate code path due to wrong handle.
Following message is seen in the logs.
"Error entry - invalid handle/queue (ffff)."
Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[ bvanassche: Fixed word order in patch title ]
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quinn Tran [Sat, 24 Dec 2016 02:06:11 +0000 (18:06 -0800)]
qla2xxx: Terminate exchange if corrupted
[ Upstream commit
5f35509db179ca7ed1feaa4b14f841adb06ed220 ]
Corrupted ATIO is defined as length of fcp_header & fcp_cmd
payload is less than 0x38. It's the minimum size for a frame to
carry 8..16 bytes SCSI CDB. The exchange will be dropped or
terminated if corrupted.
Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[ bvanassche: Fixed spelling in patch title ]
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Tue, 10 Jan 2017 11:05:54 +0000 (12:05 +0100)]
scsi: lpfc: Set elsiocb contexts to NULL after freeing it
[ Upstream commit
8667f515952feefebb3c0f8d9a9266c91b101a46 ]
Set the elsiocb contexts to NULL after freeing as others depend on it.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julia Lawall [Tue, 17 Jan 2017 11:23:21 +0000 (12:23 +0100)]
stmmac: add missing of_node_put
[ Upstream commit
a249708bc2aa1fe3ddf15dfac22bee519d15996b ]
The function stmmac_dt_phy provides several possibilities for initializing
plat->mdio_node, all of which have the effect of increasing the reference
count of the assigned value. This field is not updated elsewhere, so the
value is live until the end of the lifetime of plat (devm_allocated), just
after the end of stmmac_remove_config_dt. Thus, add an of_node_put on
plat->mdio_node in stmmac_remove_config_dt. It is possible that the field
mdio_node is never initialized, but of_node_put is NULL-safe, so it is also
safe to call of_node_put in that case.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Le Moal [Thu, 12 Jan 2017 06:25:10 +0000 (15:25 +0900)]
scsi: sd: Fix wrong DPOFUA disable in sd_read_cache_type
[ Upstream commit
26f2819772af891dee2843e1f8662c58e5129d5f ]
Zoned block devices force the use of READ/WRITE(16) commands by setting
sdkp->use_16_for_rw and clearing sdkp->use_10_for_rw. This result in
DPOFUA always being disabled for these drives as the assumed use of
the deprecated READ/WRITE(6) commands only looks at sdkp->use_10_for_rw.
Strenghten the test by also checking that sdkp->use_16_for_rw is false.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Vyukov [Tue, 17 Jan 2017 13:51:04 +0000 (14:51 +0100)]
KVM: x86: fix fixing of hypercalls
[ Upstream commit
ce2e852ecc9a42e4b8dabb46025cfef63209234a ]
emulator_fix_hypercall() replaces hypercall with vmcall instruction,
but it does not handle GP exception properly when writes the new instruction.
It can return X86EMUL_PROPAGATE_FAULT without setting exception information.
This leads to incorrect emulation and triggers
WARN_ON(ctxt->exception.vector > 0x1f) in x86_emulate_insn()
as discovered by syzkaller fuzzer:
WARNING: CPU: 2 PID: 18646 at arch/x86/kvm/emulate.c:5558
Call Trace:
warn_slowpath_null+0x2c/0x40 kernel/panic.c:582
x86_emulate_insn+0x16a5/0x4090 arch/x86/kvm/emulate.c:5572
x86_emulate_instruction+0x403/0x1cc0 arch/x86/kvm/x86.c:5618
emulate_instruction arch/x86/include/asm/kvm_host.h:1127 [inline]
handle_exception+0x594/0xfd0 arch/x86/kvm/vmx.c:5762
vmx_handle_exit+0x2b7/0x38b0 arch/x86/kvm/vmx.c:8625
vcpu_enter_guest arch/x86/kvm/x86.c:6888 [inline]
vcpu_run arch/x86/kvm/x86.c:6947 [inline]
Set exception information when write in emulator_fix_hypercall() fails.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: kvm@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Thu, 18 May 2017 15:28:48 +0000 (17:28 +0200)]
xen/blkback: don't free be structure too early
commit
71df1d7ccad1c36f7321d6b3b48f2ea42681c363 upstream.
The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Brunet [Fri, 20 Jan 2017 16:20:24 +0000 (08:20 -0800)]
ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
[ Upstream commit
feb3cbea0946c67060e2d5bcb7499b0a6f6700fe ]
OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
the Tx path). The problem seems to come from the phy Rx path, entering the
LPI state.
Disabling EEE advertisement on the phy prevent this feature to be
negociated with the link partner and solve the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:38 +0000 (16:05 +0100)]
dt: bindings: net: use boolean dt properties for eee broken modes
[ Upstream commit
308d3165d8b2b98d3dc3d97d6662062735daea67 ]
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:37 +0000 (16:05 +0100)]
net: phy: use boolean dt properties for eee broken modes
[ Upstream commit
57f3986231bb2c69a55ccab1d2b30a00818027ac ]
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:36 +0000 (16:05 +0100)]
net: phy: fix sign type error in genphy_config_eee_advert
[ Upstream commit
3bb9ab63276696988d8224f52db20e87194deb4b ]
In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.
Fixes:
d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 28 Nov 2016 09:46:47 +0000 (10:46 +0100)]
dt-bindings: net: add EEE capability constants
[ Upstream commit
1fc31357ad194fb98691f3d122bcd47e59239e83 ]
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 28 Nov 2016 09:46:46 +0000 (10:46 +0100)]
net: phy: add an option to disable EEE advertisement
[ Upstream commit
d853d145ea3e63387a2ac759aa41d5e43876e561 ]
This patch adds an option to disable EEE advertisement in the generic PHY
by providing a mask of prohibited modes corresponding to the value found in
the MDIO_AN_EEE_ADV register.
On some platforms, PHY Low power idle seems to be causing issues, even
breaking the link some cases. The patch provides a convenient way for these
platforms to disable EEE advertisement and work around the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Belous [Sat, 28 Jan 2017 19:53:28 +0000 (22:53 +0300)]
net: ethtool: add support for 2500BaseT and 5000BaseT link modes
[ Upstream commit
94842b4fc4d6b1691cfc86c6f5251f299d27f4ba ]
This patch introduce support for 2500BaseT and 5000BaseT link modes.
These modes are included in the new IEEE 802.3bz standard.
Signed-off-by: Pavel Belous <pavel.s.belous@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liam R. Howlett [Wed, 24 May 2017 01:54:11 +0000 (21:54 -0400)]
sparc64: Zero pages on allocation for mondo and error queues.
[ Upstream commit
7a7dc961a28b965a0d0303c2e989df17b411708b ]
Error queues use a non-zero first word to detect if the queues are full.
Using pages that have not been zeroed may result in false positive
overflow events. These queues are set up once during boot so zeroing
all mondo and error queue pages is safe.
Note that the false positive overflow does not always occur because the
page allocation for these queues is so early in the boot cycle that
higher number CPUs get fresh pages. It is only when traps are serviced
with lower number CPUs who were given already used pages that this issue
is exposed.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liam R. Howlett [Wed, 24 May 2017 01:54:10 +0000 (21:54 -0400)]
sparc64: Handle PIO & MEM non-resumable errors.
[ Upstream commit
047487241ff59374fded8c477f21453681f5995c ]
User processes trying to access an invalid memory address via PIO will
receive a SIGBUS signal instead of causing a panic. Memory errors will
receive a SIGKILL since a SIGBUS may result in a coredump which may
attempt to repeat the faulting access.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Fri, 16 Jun 2017 21:02:34 +0000 (14:02 -0700)]
mm: numa: avoid waiting on freed migrated pages
commit
3c226c637b69104f6b9f1c6ec5b08d7b741b3229 upstream.
In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by
waiting until the pmd is unlocked before we return and retry. However,
we can race with migrate_misplaced_transhuge_page():
// do_huge_pmd_numa_page // migrate_misplaced_transhuge_page()
// Holds 0 refs on page // Holds 2 refs on page
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
/* ... */
if (pmd_trans_migrating(*vmf->pmd)) {
page = pmd_page(*vmf->pmd);
spin_unlock(vmf->ptl);
ptl = pmd_lock(mm, pmd);
if (page_count(page) != 2)) {
/* roll back */
}
/* ... */
mlock_migrate_page(new_page, page);
/* ... */
spin_unlock(ptl);
put_page(page);
put_page(page); // page freed here
wait_on_page_locked(page);
goto out;
}
This can result in the freed page having its waiters flag set
unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the
page alloc/free functions. This has been observed on arm64 KVM guests.
We can avoid this by having do_huge_pmd_numa_page() take a reference on
the page before dropping the pmd lock, mirroring what we do in
__migration_entry_wait().
When we hit the race, migrate_misplaced_transhuge_page() will see the
reference and abort the migration, as it may do today in other cases.
Fixes:
b8916634b77bffb2 ("mm: Prevent parallel splits during THP migration")
Link: http://lkml.kernel.org/r/1497349722-6731-2-git-send-email-will.deacon@arm.com
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Steve Capper <steve.capper@arm.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:30 +0000 (13:02 +0200)]
l2tp: take a reference on sessions used in genetlink handlers
commit
2777e2ab5a9cf2b4524486c6db1517a6ded25261 upstream.
Callers of l2tp_nl_session_find() need to hold a reference on the
returned session since there's no guarantee that it isn't going to
disappear from under them.
Relying on the fact that no l2tp netlink message may be processed
concurrently isn't enough: sessions can be deleted by other means
(e.g. by closing the PPPOL2TP socket of a ppp pseudowire).
l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
function that may require a previous call to session->ref(). In
particular, for ppp pseudowires, the callback is l2tp_session_delete(),
which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
socket. The socket might already be gone at the moment
l2tp_session_delete() calls session->ref(), so we need to take a
reference during the session lookup. So we need to pass the do_ref
variable down to l2tp_session_get() and l2tp_session_get_by_ifname().
Since all callers have to be updated, l2tp_session_find_by_ifname() and
l2tp_nl_session_find() are renamed to reflect their new behaviour.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:29 +0000 (13:02 +0200)]
l2tp: hold session while sending creation notifications
commit
5e6a9e5a3554a5b3db09cdc22253af1849c65dff upstream.
l2tp_session_find() doesn't take any reference on the returned session.
Therefore, the session may disappear while sending the notification.
Use l2tp_session_get() instead and decrement session's refcount once
the notification is sent.
Fixes:
33f72e6f0c67 ("l2tp : multicast notification to the registered listeners")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:27 +0000 (13:02 +0200)]
l2tp: fix duplicate session creation
commit
dbdbc73b44782e22b3b4b6e8b51e7a3d245f3086 upstream.
l2tp_session_create() relies on its caller for checking for duplicate
sessions. This is racy since a session can be concurrently inserted
after the caller's verification.
Fix this by letting l2tp_session_create() verify sessions uniqueness
upon insertion. Callers need to be adapted to check for
l2tp_session_create()'s return code instead of calling
l2tp_session_find().
pppol2tp_connect() is a bit special because it has to work on existing
sessions (if they're not connected) or to create a new session if none
is found. When acting on a preexisting session, a reference must be
held or it could go away on us. So we have to use l2tp_session_get()
instead of l2tp_session_find() and drop the reference before exiting.
Fixes:
d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:26 +0000 (13:02 +0200)]
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()
commit
57377d63547861919ee634b845c7caa38de4a452 upstream.
Holding a reference on session is required before calling
pppol2tp_session_ioctl(). The session could get freed while processing the
ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
we also need to take a reference on it in l2tp_session_get().
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:25 +0000 (13:02 +0200)]
l2tp: fix race in l2tp_recv_common()
commit
61b9a047729bb230978178bca6729689d0c50ca2 upstream.
Taking a reference on sessions in l2tp_recv_common() is racy; this
has to be done by the callers.
To this end, a new function is required (l2tp_session_get()) to
atomically lookup a session and take a reference on it. Callers then
have to manually drop this reference.
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baolin Wang [Thu, 8 Dec 2016 11:55:22 +0000 (19:55 +0800)]
usb: gadget: f_fs: Fix possibe deadlock
commit
b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.
When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().
[ 52.642225] c1 ======================================================
[ 52.642228] c1 [ INFO: possible circular locking dependency detected ]
[ 52.642236] c1 4.4.6+ #1 Tainted: G W O
[ 52.642241] c1 -------------------------------------------------------
[ 52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[ 52.642270] c0 (udc_lock){+.+.+.}, at: [<
ffffffc00065aeec>]
usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642272] c1 but task is already holding lock:
[ 52.642283] c0 (ffs_lock){+.+.+.}, at: [<
ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642285] c1 which lock already depends on the new lock.
[ 52.642287] c1
the existing dependency chain (in reverse order) is:
[ 52.642295] c0
-> #1 (ffs_lock){+.+.+.}:
[ 52.642307] c0 [<
ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
[ 52.642314] c0 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642322] c0 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642328] c0 [<
ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
[ 52.642334] c0 [<
ffffffc000654004>] usb_add_function+0x84/0x184
[ 52.642340] c0 [<
ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
[ 52.642346] c0 [<
ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
[ 52.642352] c0 [<
ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
[ 52.642358] c0 [<
ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
[ 52.642369] c0 [<
ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
[ 52.642376] c0 [<
ffffffc00023c054>] vfs_write+0xb8/0x214
[ 52.642381] c0 [<
ffffffc00023cad4>] SyS_write+0x54/0xb0
[ 52.642388] c0 [<
ffffffc000085ff0>] el0_svc_naked+0x24/0x28
[ 52.642395] c0
-> #0 (udc_lock){+.+.+.}:
[ 52.642401] c0 [<
ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
[ 52.642407] c0 [<
ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642412] c0 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642420] c0 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642427] c0 [<
ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642432] c0 [<
ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642439] c0 [<
ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642444] c0 [<
ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642450] c0 [<
ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642454] c0 [<
ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642460] c0 [<
ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642466] c0 [<
ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642473] c0 [<
ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642482] c0 [<
ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642487] c0 [<
ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642494] c0 [<
ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642501] c0 [<
ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642507] c0 [<
ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642512] c0 [<
ffffffc000085ee8>] work_pending+0x1c/0x20
[ 52.642514] c1
other info that might help us debug this:
[ 52.642517] c1 Possible unsafe locking scenario:
[ 52.642518] c1 CPU0 CPU1
[ 52.642520] c1 ---- ----
[ 52.642525] c0 lock(ffs_lock);
[ 52.642529] c0 lock(udc_lock);
[ 52.642533] c0 lock(ffs_lock);
[ 52.642537] c0 lock(udc_lock);
[ 52.642539] c1
*** DEADLOCK ***
[ 52.642543] c1 1 lock held by usb ffs open/2808:
[ 52.642555] c0 #0: (ffs_lock){+.+.+.}, at: [<
ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642557] c1 stack backtrace:
[ 52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[ 52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[ 52.642568] c1 Call trace:
[ 52.642573] c1 [<
ffffffc00008b430>] dump_backtrace+0x0/0x170
[ 52.642577] c1 [<
ffffffc00008b5c0>] show_stack+0x20/0x28
[ 52.642583] c1 [<
ffffffc000422694>] dump_stack+0xa8/0xe0
[ 52.642587] c1 [<
ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
[ 52.642591] c1 [<
ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642595] c1 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642599] c1 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642604] c1 [<
ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642608] c1 [<
ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642613] c1 [<
ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642618] c1 [<
ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642621] c1 [<
ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642625] c1 [<
ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642629] c1 [<
ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642633] c1 [<
ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642636] c1 [<
ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642640] c1 [<
ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642644] c1 [<
ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642647] c1 [<
ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642651] c1 [<
ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642656] c1 [<
ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642659] c1 [<
ffffffc000085ee8>] work_pending+0x1c/0x20
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baoquan He [Thu, 4 May 2017 02:25:47 +0000 (10:25 +0800)]
x86/mm: Fix boot crash caused by incorrect loop count calculation in sync_global_pgds()
commit
fc5f9d5f151c9fff21d3d1d2907b888a5aec3ff7 upstream.
Jeff Moyer reported that on his system with two memory regions 0~64G and
1T~1T+192G, and kernel option "memmap=192G!1024G" added, enabling KASLR
will make the system hang intermittently during boot. While adding 'nokaslr'
won't.
The back trace is:
Oops: 0000 [#1] SMP
RIP: memcpy_erms()
[ .... ]
Call Trace:
pmem_rw_page()
bdev_read_page()
do_mpage_readpage()
mpage_readpages()
blkdev_readpages()
__do_page_cache_readahead()
force_page_cache_readahead()
page_cache_sync_readahead()
generic_file_read_iter()
blkdev_read_iter()
__vfs_read()
vfs_read()
SyS_read()
entry_SYSCALL_64_fastpath()
This crash happens because the for loop count calculation in sync_global_pgds()
is not correct. When a mapping area crosses PGD entries, we should
calculate the starting address of region which next PGD covers and assign
it to next for loop count, but not add PGDIR_SIZE directly. The old
code works right only if the mapping area is an exact multiple of PGDIR_SIZE,
otherwize the end region could be skipped so that it can't be synchronized
to all other processes from kernel PGD init_mm.pgd.
In Jeff's system, emulated pmem area [1024G, 1216G) is smaller than
PGDIR_SIZE. While 'nokaslr' works because PAGE_OFFSET is 1T aligned, it
makes this area be mapped inside one PGD entry. With KASLR enabled,
this area could cross two PGD entries, then the next PGD entry won't
be synced to all other processes. That is why we saw empty PGD.
Fix it.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jinbum Park <jinb.park7@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yasuaki Ishimatsu <yasu.isimatu@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1493864747-8506-1-git-send-email-bhe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vallish Vaidyeshwara [Fri, 23 Jun 2017 18:53:06 +0000 (18:53 +0000)]
dm thin: do not queue freed thin mapping for next stage processing
commit
00a0ea33b495ee6149bf5a77ac5807ce87323abb upstream.
process_prepared_discard_passdown_pt1() should cleanup
dm_thin_new_mapping in cases of error.
dm_pool_inc_data_range() can fail trying to get a block reference:
metadata operation 'dm_pool_inc_data_range' failed: error = -61
When dm_pool_inc_data_range() fails, dm thin aborts current metadata
transaction and marks pool as PM_READ_ONLY. Memory for thin mapping
is released as well. However, current thin mapping will be queued
onto next stage as part of queue_passdown_pt2() or passdown_endio().
This dangling thin mapping memory when processed and accessed in
next stage will lead to device mapper crashing.
Code flow without fix:
-> process_prepared_discard_passdown_pt1(m)
-> dm_thin_remove_range()
-> discard passdown
--> passdown_endio(m) queues m onto next stage
-> dm_pool_inc_data_range() fails, frees memory m
but does not remove it from next stage queue
-> process_prepared_discard_passdown_pt2(m)
-> processes freed memory m and crashes
One such stack:
Call Trace:
[<
ffffffffa037a46f>] dm_cell_release_no_holder+0x2f/0x70 [dm_bio_prison]
[<
ffffffffa039b6dc>] cell_defer_no_holder+0x3c/0x80 [dm_thin_pool]
[<
ffffffffa039b88b>] process_prepared_discard_passdown_pt2+0x4b/0x90 [dm_thin_pool]
[<
ffffffffa0399611>] process_prepared+0x81/0xa0 [dm_thin_pool]
[<
ffffffffa039e735>] do_worker+0xc5/0x820 [dm_thin_pool]
[<
ffffffff8152bf54>] ? __schedule+0x244/0x680
[<
ffffffff81087e72>] ? pwq_activate_delayed_work+0x42/0xb0
[<
ffffffff81089f53>] process_one_work+0x153/0x3f0
[<
ffffffff8108a71b>] worker_thread+0x12b/0x4b0
[<
ffffffff8108a5f0>] ? rescuer_thread+0x350/0x350
[<
ffffffff8108fd6a>] kthread+0xca/0xe0
[<
ffffffff8108fca0>] ? kthread_park+0x60/0x60
[<
ffffffff81530b45>] ret_from_fork+0x25/0x30
The fix is to first take the block ref count for discarded block and
then do a passdown discard of this block. If block ref count fails,
then bail out aborting current metadata transaction, mark pool as
PM_READ_ONLY and also free current thin mapping memory (existing error
handling code) without queueing this thin mapping onto next stage of
processing. If block ref count succeeds, then passdown discard of this
block. Discard callback of passdown_endio() will queue this thin mapping
onto next stage of processing.
Code flow with fix:
-> process_prepared_discard_passdown_pt1(m)
-> dm_thin_remove_range()
-> dm_pool_inc_data_range()
--> if fails, free memory m and bail out
-> discard passdown
--> passdown_endio(m) queues m onto next stage
Reviewed-by: Eduardo Valentin <eduval@amazon.com>
Reviewed-by: Cristian Gafton <gafton@amazon.com>
Reviewed-by: Anchal Agarwal <anchalag@amazon.com>
Signed-off-by: Vallish Vaidyeshwara <vallish@amazon.com>
Reviewed-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Deepak Rawat [Mon, 26 Jun 2017 12:39:08 +0000 (14:39 +0200)]
drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
commit
82fcee526ba8ca2c5d378bdf51b21b7eb058fe3a upstream.
The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.
Tested for memory leak by running piglit overnight and kernel
memory is not inflated which earlier was.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bartosz Golaszewski [Fri, 23 Jun 2017 11:45:16 +0000 (13:45 +0200)]
gpiolib: fix filtering out unwanted events
commit
ad537b822577fcc143325786cd6ad50d7b9df31c upstream.
GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.
The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.
Fix it by checking both RISING & FALLING flags explicitly.
Fixes:
61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 27 Jun 2017 21:33:38 +0000 (17:33 -0400)]
NFSv4.1: Fix a race in nfs4_proc_layoutget
commit
bd171930e6a3de4f5cffdafbb944e50093dfb59b upstream.
If the task calling layoutget is signalled, then it is possible for the
calls to nfs4_sequence_free_slot() and nfs4_layoutget_prepare() to race,
in which case we leak a slot.
The fix is to move the call to nfs4_sequence_free_slot() into the
nfs4_layoutget_release() so that it gets called at task teardown time.
Fixes:
2e80dbe7ac51 ("NFSv4.1: Close callback races for OPEN, LAYOUTGET...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hui Wang [Wed, 28 Jun 2017 00:59:16 +0000 (08:59 +0800)]
ALSA: hda - set input_path bitmap to zero after moving it to new place
commit
a8f20fd25bdce81a8e41767c39f456d346b63427 upstream.
Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".
Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.
Fixes:
3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 28 Jun 2017 10:02:02 +0000 (12:02 +0200)]
ALSA: hda - Fix endless loop of codec configure
commit
d94815f917da770d42c377786dc428f542e38f71 upstream.
azx_codec_configure() loops over the codecs found on the given
controller via a linked list. The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.
The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus. Since the list is initialized via list_del_init(), the
next object points to the same device itself. This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.
For fixing this bug, just use a *_safe() version of list iteration.
Fixes:
d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Fri, 3 Mar 2017 23:26:05 +0000 (15:26 -0800)]
MIPS: Fix IRQ tracing & lockdep when rescheduling
commit
d8550860d910c6b7b70f830f59003b33daaa52c9 upstream.
When the scheduler sets TIF_NEED_RESCHED & we call into the scheduler
from arch/mips/kernel/entry.S we disable interrupts. This is true
regardless of whether we reach work_resched from syscall_exit_work,
resume_userspace or by looping after calling schedule(). Although we
disable interrupts in these paths we don't call trace_hardirqs_off()
before calling into C code which may acquire locks, and we therefore
leave lockdep with an inconsistent view of whether interrupts are
disabled or not when CONFIG_PROVE_LOCKING & CONFIG_DEBUG_LOCKDEP are
both enabled.
Without tracing this interrupt state lockdep will print warnings such
as the following once a task returns from a syscall via
syscall_exit_partial with TIF_NEED_RESCHED set:
[ 49.927678] ------------[ cut here ]------------
[ 49.934445] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3687 check_flags.part.41+0x1dc/0x1e8
[ 49.946031] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
[ 49.946355] CPU: 0 PID: 1 Comm: init Not tainted
4.10.0-00439-gc9fd5d362289-dirty #197
[ 49.963505] Stack :
0000000000000000 ffffffff81bb5d6a 0000000000000006 ffffffff801ce9c4
[ 49.974431]
0000000000000000 0000000000000000 0000000000000000 000000000000004a
[ 49.985300]
ffffffff80b7e487 ffffffff80a24498 a8000000ff160000 ffffffff80ede8b8
[ 49.996194]
0000000000000001 0000000000000000 0000000000000000 0000000077c8030c
[ 50.007063]
000000007fd8a510 ffffffff801cd45c 0000000000000000 a8000000ff127c88
[ 50.017945]
0000000000000000 ffffffff801cf928 0000000000000001 ffffffff80a24498
[ 50.028827]
0000000000000000 0000000000000001 0000000000000000 0000000000000000
[ 50.039688]
0000000000000000 a8000000ff127bd0 0000000000000000 ffffffff805509bc
[ 50.050575]
00000000140084e0 0000000000000000 0000000000000000 0000000000040a00
[ 50.061448]
0000000000000000 ffffffff8010e1b0 0000000000000000 ffffffff805509bc
[ 50.072327] ...
[ 50.076087] Call Trace:
[ 50.079869] [<
ffffffff8010e1b0>] show_stack+0x80/0xa8
[ 50.086577] [<
ffffffff805509bc>] dump_stack+0x10c/0x190
[ 50.093498] [<
ffffffff8015dde0>] __warn+0xf0/0x108
[ 50.099889] [<
ffffffff8015de34>] warn_slowpath_fmt+0x3c/0x48
[ 50.107241] [<
ffffffff801c15b4>] check_flags.part.41+0x1dc/0x1e8
[ 50.114961] [<
ffffffff801c239c>] lock_is_held_type+0x8c/0xb0
[ 50.122291] [<
ffffffff809461b8>] __schedule+0x8c0/0x10f8
[ 50.129221] [<
ffffffff80946a60>] schedule+0x30/0x98
[ 50.135659] [<
ffffffff80106278>] work_resched+0x8/0x34
[ 50.142397] ---[ end trace
0cb4f6ef5b99fe21 ]---
[ 50.148405] possible reason: unannotated irqs-off.
[ 50.154600] irq event stamp: 400463
[ 50.159566] hardirqs last enabled at (400463): [<
ffffffff8094edc8>] _raw_spin_unlock_irqrestore+0x40/0xa8
[ 50.171981] hardirqs last disabled at (400462): [<
ffffffff8094eb98>] _raw_spin_lock_irqsave+0x30/0xb0
[ 50.183897] softirqs last enabled at (400450): [<
ffffffff8016580c>] __do_softirq+0x4ac/0x6a8
[ 50.195015] softirqs last disabled at (400425): [<
ffffffff80165e78>] irq_exit+0x110/0x128
Fix this by using the TRACE_IRQS_OFF macro to call trace_hardirqs_off()
when CONFIG_TRACE_IRQFLAGS is enabled. This is done before invoking
schedule() following the work_resched label because:
1) Interrupts are disabled regardless of the path we take to reach
work_resched() & schedule().
2) Performing the tracing here avoids the need to do it in paths which
disable interrupts but don't call out to C code before hitting a
path which uses the RESTORE_SOME macro that will call
trace_hardirqs_on() or trace_hardirqs_off() as appropriate.
We call trace_hardirqs_on() using the TRACE_IRQS_ON macro before calling
syscall_trace_leave() for similar reasons, ensuring that lockdep has a
consistent view of state after we re-enable interrupts.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15385/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Thu, 2 Mar 2017 22:02:40 +0000 (14:02 -0800)]
MIPS: pm-cps: Drop manual cache-line alignment of ready_count
commit
161c51ccb7a6faf45ffe09aa5cf1ad85ccdad503 upstream.
We allocate memory for a ready_count variable per-CPU, which is accessed
via a cached non-coherent TLB mapping to perform synchronisation between
threads within the core using LL/SC instructions. In order to ensure
that the variable is contained within its own data cache line we
allocate 2 lines worth of memory & align the resulting pointer to a line
boundary. This is however unnecessary, since kmalloc is guaranteed to
return memory which is at least cache-line aligned (see
ARCH_DMA_MINALIGN). Stop the redundant manual alignment.
Besides cleaning up the code & avoiding needless work, this has the side
effect of avoiding an arithmetic error found by Bryan on 64 bit systems
due to the 32 bit size of the former dlinesz. This led the ready_count
variable to have its upper 32b cleared erroneously for MIPS64 kernels,
causing problems when ready_count was later used on MIPS64 via cpuidle.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes:
3179d37ee1ed ("MIPS: pm-cps: add PM state entry code for CPS systems")
Reported-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15383/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Thu, 29 Jun 2017 14:05:04 +0000 (15:05 +0100)]
MIPS: Avoid accidental raw backtrace
commit
854236363370995a609a10b03e35fd3dc5e9e4a1 upstream.
Since commit
81a76d7119f6 ("MIPS: Avoid using unwind_stack() with
usermode") show_backtrace() invokes the raw backtracer when
cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels
where user and kernel address spaces overlap.
However this is used by show_stack() which creates its own pt_regs on
the stack and leaves cp0_status uninitialised in most of the code paths.
This results in the non deterministic use of the raw back tracer
depending on the previous stack content.
show_stack() deals exclusively with kernel mode stacks anyway, so
explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure
we get a useful backtrace.
Fixes:
81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16656/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Karl Beldan [Tue, 27 Jun 2017 19:22:16 +0000 (19:22 +0000)]
MIPS: head: Reorder instructions missing a delay slot
commit
25d8b92e0af75d72ce8b99e63e5a449cc0888efa upstream.
In this sequence the 'move' is assumed in the delay slot of the 'beq',
but head.S is in reorder mode and the former gets pushed one 'nop'
farther by the assembler.
The corrected behavior made booting with an UHI supplied dtb erratic.
Fixes:
15f37e158892 ("MIPS: store the appended dtb address in a variable")
Signed-off-by: Karl Beldan <karl.beldan+oss@gmail.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16614/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OSDN Git Service
