commit e3185123541204ca4f715eeaaa1f9929c09ff3b4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun Jan 13 09:51:11 2019 +0100
Linux 4.19.15
commit 6384c67c64b59fb0a3e0b414a9171ec8147eaae1
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date: Mon Dec 24 20:13:05 2018 +0500
bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
commit 38355a5f9a22bfa5bd5b1bb79805aca39fa53729 upstream.
This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I 4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffffa47ccdc9fbe0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000003e8 RCX: ffffa47ccdc9fbf8
RDX: ffffa47ccdc9fc00 RSI: ffff97d9ee7b01f8 RDI: ffff97d9f0150b80
RBP: ffff97d9f0150b80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
R13: ffff97d9ef1e53e8 R14: 0000000000000009 R15: ffff97d9f0ac6730
FS: 00007f4d224ef700(0000) GS:ffff97d9fa200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000011ece52006 CR4: 00000000000206e0
Call Trace:
? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
? bnx2x_set_features+0x79/0xa0 [bnx2x]
? __netdev_update_features+0x244/0x9e0
? netlink_broadcast_filtered+0x136/0x4b0
? netdev_update_features+0x22/0x60
? dev_disable_lro+0x1c/0xe0
? devinet_sysctl_forward+0x1c6/0x211
? proc_sys_call_handler+0xab/0x100
? __vfs_write+0x36/0x1a0
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x14c/0x1b0
? vfs_write+0x159/0x1c0
? vfs_write+0xba/0x1c0
? ksys_write+0x52/0xc0
? do_syscall_64+0x60/0x1f0
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
After some investigation I figured out that recently added cleanup code
tries to call VLAN filtering de-initialization function which exist only
for newer hardware. Corresponding function pointer is not
set (== 0) for older hardware, namely these chips:
#define CHIP_NUM_57710 0x164e
#define CHIP_NUM_57711 0x164f
#define CHIP_NUM_57711E 0x1650
And I have one of those in my test system:
Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]
Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to
initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not.
This regression was introduced after v4.20-rc7, and still exists in v4.20
release.
Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e3a1c500288d806e80b2de08eb9186653267e6f
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Nov 28 16:17:50 2018 -0500
drm/amd/display: Fix unintialized max_bpc state values
commit 49f1c44b581b08e3289127ffe58bd208c3166701 upstream.
[Why]
If the "max bpc" isn't explicitly set in the atomic state then it
have a value of 0. This has the correct behavior of limiting a panel
to 8bpc in the case where the panel supports 8bpc. In the case of eDP
panels this isn't a true assumption - there are panels that can only
do 6bpc.
Banding occurs for these displays.
[How]
Initialize the max_bpc when the connector resets to 8bpc. Also carry
over the value when the state is duplicated.
Bugzilla: https://bugs.freedesktop.org/108825
Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f0ab980de1a444dbd17dfdb02be9fc636f0cc14
Author: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Date: Sat Oct 13 12:56:54 2018 +0200
drm/rockchip: psr: do not dereference encoder before it is null checked.
commit 4eda776c3cefcb1f01b2d85bd8753f67606282b5 upstream.
'encoder' is dereferenced before it is null sanity checked, hence we
potentially have a null pointer dereference bug. Instead, initialise
drm_drv from encoder->dev->dev_private after we are sure 'encoder' is
not null.
Fixes: 5182c1a556d7f ("drm/rockchip: add an common abstracted PSR driver")
Cc: stable@vger.kernel.org
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181013105654.11827-1-enric.balletbo@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 05a0177d84d9d76a246d8ee0fe176262bab9f293
Author: Boris Brezillon <boris.brezillon@bootlin.com>
Date: Tue Oct 9 15:24:46 2018 +0200
drm/vc4: Set ->is_yuv to false when num_planes == 1
commit 2b02a05bdc3a62d36e0d0b015351897109e25991 upstream.
When vc4_plane_state is duplicated ->is_yuv is left assigned to its
previous value, and we never set it back to false when switching to
a non-YUV format.
Fix that by setting ->is_yuv to false in the 'num_planes == 1' branch
of the vc4_plane_setup_clipping_and_scaling() function.
Fixes: fc04023fafecf ("drm/vc4: Add support for YUV planes.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181009132446.21960-1-boris.brezillon@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 85c8c61007dd62aa611522dae361370e114cdb88
Author: Lyude Paul <lyude@redhat.com>
Date: Wed Nov 14 20:39:51 2018 -0500
drm/nouveau/drm/nouveau: Check rc from drm_dp_mst_topology_mgr_resume()
commit b89fdf7ae8500feae1100d8b283176a44d31d698 upstream.
We need to actually make sure we check this on resume since otherwise we
won't know whether or not the topology is still there once we've
resumed, which will cause us to still think the topology is connected
even after it's been removed if the removal happens mid-suspend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f44e58a561412c4225544220cdde8cf27defb34
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Mon Dec 10 08:08:28 2018 +0000
lib: fix build failure in CONFIG_DEBUG_VIRTUAL test
commit 10fdf838e5f540beca466e9d1325999c072e5d3f upstream.
On several arches, virt_to_phys() is in io.h
Build fails without it:
CC lib/test_debug_virtual.o
lib/test_debug_virtual.c: In function 'test_debug_virtual_init':
lib/test_debug_virtual.c:26:7: error: implicit declaration of function 'virt_to_phys' [-Werror=implicit-function-declaration]
pa = virt_to_phys(va);
^
Fixes: e4dace361552 ("lib: add test module for CONFIG_DEBUG_VIRTUAL")
CC: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8dbea64423dca8a357aeea7160713ba9c0e26845
Author: Frank Rowand <frank.rowand@sony.com>
Date: Tue Dec 18 11:40:03 2018 -0800
of: __of_detach_node() - remove node from phandle cache
commit 5801169a2ed20003f771acecf3ac00574cf10a38 upstream.
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. Remove the node from the
cache.
Add paranoia checks in of_find_node_by_phandle() as a second level
of defense (do not return cached node if detached, do not add node
to cache if detached).
Fixes: 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of of_find_node_by_phandle()")
Reported-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1cb5a0333a5d2b3e79c318751d71a080a7869a88
Author: Frank Rowand <frank.rowand@sony.com>
Date: Tue Dec 18 11:40:02 2018 -0800
of: of_node_get()/of_node_put() nodes held in phandle cache
commit b8a9ac1a5b99a2fcbed19fd29d2d59270c281a31 upstream.
The phandle cache contains struct device_node pointers. The refcount
of the pointers was not incremented while in the cache, allowing use
after free error after kfree() of the node. Add the proper increment
and decrement of the use count.
Fixes: 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of of_find_node_by_phandle()")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit daa67bd5d1ec3398c0386c222502c26af7788c5d
Author: Lubomir Rintel <lkundrak@v3.sk>
Date: Fri Nov 16 17:23:47 2018 +0100
power: supply: olpc_battery: correct the temperature units
commit ed54ffbe554f0902689fd6d1712bbacbacd11376 upstream.
According to [1] and [2], the temperature values are in tenths of degree
Celsius. Exposing the Celsius value makes the battery appear on fire:
$ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery
...
temperature: 236.9 degrees C
Tested on OLPC XO-1 and OLPC XO-1.75 laptops.
[1] include/linux/power_supply.h
[2] Documentation/power/power_supply_class.txt
Fixes: fb972873a767 ("[BATTERY] One Laptop Per Child power/battery driver")
Cc: stable@vger.kernel.org
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f65b4d4ff3aa08efed2ad9f7efcde7cc16c5c642
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date: Wed Dec 19 17:19:22 2018 +0200
intel_th: msu: Fix an off-by-one in attribute store
commit ec5b5ad6e272d8d6b92d1007f79574919862a2d2 upstream.
The 'nr_pages' attribute of the 'msc' subdevices parses a comma-separated
list of window sizes, passed from userspace. However, there is a bug in
the string parsing logic wherein it doesn't exclude the comma character
from the range of characters as it consumes them. This leads to an
out-of-bounds access given a sufficiently long list. For example:
> # echo 8,8,8,8 > /sys/bus/intel_th/devices/0-msc0/nr_pages
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in memchr+0x1e/0x40
> Read of size 1 at addr ffff8803ffcebcd1 by task sh/825
>
> CPU: 3 PID: 825 Comm: npktest.sh Tainted: G W 4.20.0-rc1+
> Call Trace:
> dump_stack+0x7c/0xc0
> print_address_description+0x6c/0x23c
> ? memchr+0x1e/0x40
> kasan_report.cold.5+0x241/0x308
> memchr+0x1e/0x40
> nr_pages_store+0x203/0xd00 [intel_th_msu]
Fix this by accounting for the comma character.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: ba82664c134ef ("intel_th: Add Memory Storage Unit driver")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 998c3537af41b7c2738442daea6d9404c0e78ce6
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Wed Dec 12 14:45:18 2018 +0100
genwqe: Fix size check
commit fdd669684655c07dacbdb0d753fd13833de69a33 upstream.
Calling the test program genwqe_cksum with the default buffer size of
2MB triggers the following kernel warning on s390:
WARNING: CPU: 30 PID: 9311 at mm/page_alloc.c:3189 __alloc_pages_nodemask+0x45c/0xbe0
CPU: 30 PID: 9311 Comm: genwqe_cksum Kdump: loaded Not tainted 3.10.0-957.el7.s390x #1
task: 00000005e5d13980 ti: 00000005e7c6c000 task.ti: 00000005e7c6c000
Krnl PSW : 0704c00180000000 00000000002780ac (__alloc_pages_nodemask+0x45c/0xbe0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 00000000002932b8 0000000000b73d7c 0000000000000010 0000000000000009
0000000000000041 00000005e7c6f9b8 0000000000000001 00000000000080d0
0000000000000000 0000000000b70500 0000000000000001 0000000000000000
0000000000b70528 00000000007682c0 0000000000277df2 00000005e7c6f9a0
Krnl Code: 000000000027809e: de7195001000 ed 1280(114,%r9),0(%r1)
00000000002780a4: a774fead brc 7,277dfe
#00000000002780a8: a7f40001 brc 15,2780aa
>00000000002780ac: 92011000 mvi 0(%r1),1
00000000002780b0: a7f4fea7 brc 15,277dfe
00000000002780b4: 9101c6b6 tm 1718(%r12),1
00000000002780b8: a784ff3a brc 8,277f2c
00000000002780bc: a7f4fe2e brc 15,277d18
Call Trace:
([<0000000000277df2>] __alloc_pages_nodemask+0x1a2/0xbe0)
[<000000000013afae>] s390_dma_alloc+0xfe/0x310
[<000003ff8065f362>] __genwqe_alloc_consistent+0xfa/0x148 [genwqe_card]
[<000003ff80658f7a>] genwqe_mmap+0xca/0x248 [genwqe_card]
[<00000000002b2712>] mmap_region+0x4e2/0x778
[<00000000002b2c54>] do_mmap+0x2ac/0x3e0
[<0000000000292d7e>] vm_mmap_pgoff+0xd6/0x118
[<00000000002b081c>] SyS_mmap_pgoff+0xdc/0x268
[<00000000002b0a34>] SyS_old_mmap+0x8c/0xb0
[<000000000074e518>] sysc_tracego+0x14/0x1e
[<000003ffacf87dc6>] 0x3ffacf87dc6
turns out the check in __genwqe_alloc_consistent uses "> MAX_ORDER"
while the mm code uses ">= MAX_ORDER". Fix genwqe.
Cc: stable@vger.kernel.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86dcb94392f710eeed3bf824203a058d5b2fe32f
Author: Shaokun Zhang <zhangshaokun@hisilicon.com>
Date: Fri Jan 4 14:21:34 2019 +0800
drivers/perf: hisi: Fixup one DDRC PMU register offset
commit eb4f5213251833567570df1a09803f895653274d upstream.
For DDRC PMU, each PMU counter is fixed-purpose. There is a mismatch
between perf list and driver definition on rw_chg event.
# perf list | grep chg
hisi_sccl1_ddrc0/rnk_chg/ [Kernel PMU event]
hisi_sccl1_ddrc0/rw_chg/ [Kernel PMU event]
But the register offset of rw_chg event is not defined in the driver,
meanwhile bnk_chg register offset is mis-defined, let's fixup it.
Fixes: 904dcf03f086 ("perf: hisi: Add support for HiSilicon SoC DDRC PMU driver")
Cc: stable@vger.kernel.org
Cc: John Garry <john.garry@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reported-by: Weijian Huang <huangweijian4@hisilicon.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1aa0c845c36a37f4119c42d974f4cfb653da192
Author: YueHaibing <yuehaibing@huawei.com>
Date: Thu Dec 20 19:13:08 2018 +0100
video: fbdev: pxafb: Fix "WARNING: invalid free of devm_ allocated data"
commit 2607391882fca37463187e7f2a9c76dec286947e upstream.
'info->modes' got allocated with devm_kcalloc in of_get_pxafb_display.
This gives this error message:
./drivers/video/fbdev/pxafb.c:2238:2-7: WARNING: invalid free of devm_ allocated data
Fixes: c8f96304ec8b4 ("video: fbdev: pxafb: switch to devm_* API")
Cc: stable@kernel.org [v4.19+]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Daniel Mack <daniel@zonque.org>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9797226bf661499ddfb7d754d155f594d5742f5e
Author: Yan, Zheng <zyan@redhat.com>
Date: Thu Nov 29 11:22:50 2018 +0800
ceph: don't update importing cap's mseq when handing cap export
commit 3c1392d4c49962a31874af14ae9ff289cb2b3851 upstream.
Updating mseq makes client think importer mds has accepted all prior
cap messages and importer mds knows what caps client wants. Actually
some cap messages may have been dropped because of mseq mismatch.
If mseq is left untouched, importing cap's mds_wanted later will get
reset by cap import message.
Cc: stable@vger.kernel.org
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc8408ea0b22ab181ee541f3786b4fd6161e0ce3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Dec 27 13:46:17 2018 -0800
sched/fair: Fix infinite loop in update_blocked_averages() by reverting a9e7f6544b9c
commit c40f7d74c741a907cfaeb73a7697081881c497d0 upstream.
Zhipeng Xie, Xie XiuQi and Sargun Dhillon reported lockups in the
scheduler under high loads, starting at around the v4.18 time frame,
and Zhipeng Xie tracked it down to bugs in the rq->leaf_cfs_rq_list
manipulation.
Do a (manual) revert of:
a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance path")
It turns out that the list_del_leaf_cfs_rq() introduced by this commit
is a surprising property that was not considered in followup commits
such as:
9c2791f936ef ("sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list")
As Vincent Guittot explains:
"I think that there is a bigger problem with commit a9e7f6544b9c and
cfs_rq throttling:
Let take the example of the following topology TG2 --> TG1 --> root:
1) The 1st time a task is enqueued, we will add TG2 cfs_rq then TG1
cfs_rq to leaf_cfs_rq_list and we are sure to do the whole branch in
one path because it has never been used and can't be throttled so
tmp_alone_branch will point to leaf_cfs_rq_list at the end.
2) Then TG1 is throttled
3) and we add TG3 as a new child of TG1.
4) The 1st enqueue of a task on TG3 will add TG3 cfs_rq just before TG1
cfs_rq and tmp_alone_branch will stay on rq->leaf_cfs_rq_list.
With commit a9e7f6544b9c, we can del a cfs_rq from rq->leaf_cfs_rq_list.
So if the load of TG1 cfs_rq becomes NULL before step 2) above, TG1
cfs_rq is removed from the list.
Then at step 4), TG3 cfs_rq is added at the beginning of rq->leaf_cfs_rq_list
but tmp_alone_branch still points to TG3 cfs_rq because its throttled
parent can't be enqueued when the lock is released.
tmp_alone_branch doesn't point to rq->leaf_cfs_rq_list whereas it should.
So if TG3 cfs_rq is removed or destroyed before tmp_alone_branch
points on another TG cfs_rq, the next TG cfs_rq that will be added,
will be linked outside rq->leaf_cfs_rq_list - which is bad.
In addition, we can break the ordering of the cfs_rq in
rq->leaf_cfs_rq_list but this ordering is used to update and
propagate the update from leaf down to root."
Instead of trying to work through all these cases and trying to reproduce
the very high loads that produced the lockup to begin with, simplify
the code temporarily by reverting a9e7f6544b9c - which change was clearly
not thought through completely.
This (hopefully) gives us a kernel that doesn't lock up so people
can continue to enjoy their holidays without worrying about regressions. ;-)
[ mingo: Wrote changelog, fixed weird spelling in code comment while at it. ]
Analyzed-by: Xie XiuQi <xiexiuqi@huawei.com>
Analyzed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reported-by: Zhipeng Xie <xiezhipeng1@huawei.com>
Reported-by: Sargun Dhillon <sargun@sargun.me>
Reported-by: Xie XiuQi <xiexiuqi@huawei.com>
Tested-by: Zhipeng Xie <xiezhipeng1@huawei.com>
Tested-by: Sargun Dhillon <sargun@sargun.me>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Vincent Guittot <vincent.guittot@linaro.org>
Cc: <stable@vger.kernel.org> # v4.13+
Cc: Bin Li <huawei.libin@huawei.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance path")
Link: http://lkml.kernel.org/r/1545879866-27809-1-git-send-email-xiexiuqi@huawei.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 87b868070f41b5664ab8024e16aed574244d9613
Author: Sohil Mehta <sohil.mehta@intel.com>
Date: Wed Nov 21 15:29:33 2018 -0800
iommu/vt-d: Handle domain agaw being less than iommu agaw
commit 3569dd07aaad71920c5ea4da2d5cc9a167c1ffd4 upstream.
The Intel IOMMU driver opportunistically skips a few top level page
tables from the domain paging directory while programming the IOMMU
context entry. However there is an implicit assumption in the code that
domain's adjusted guest address width (agaw) would always be greater
than IOMMU's agaw.
The IOMMU capabilities in an upcoming platform cause the domain's agaw
to be lower than IOMMU's agaw. The issue is seen when the IOMMU supports
both 4-level and 5-level paging. The domain builds a 4-level page table
based on agaw of 2. However the IOMMU's agaw is set as 3 (5-level). In
this case the code incorrectly tries to skip page page table levels.
This causes the IOMMU driver to avoid programming the context entry. The
fix handles this case and programs the context entry accordingly.
Fixes: de24e55395698 ("iommu/vt-d: Simplify domain_context_mapping_one")
Cc: <stable@vger.kernel.org>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reported-by: Ramos Falcon, Ernesto R <ernesto.r.ramos.falcon@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f408aac3104c24126ad94b54f0465499678f28ba
Author: Bart Van Assche <bvanassche@acm.org>
Date: Mon Dec 17 13:20:40 2018 -0800
RDMA/srpt: Fix a use-after-free in the channel release code
commit ed041919f0d23c109d52cde8da6ddc211c52d67e upstream.
This patch avoids that KASAN sporadically reports the following:
BUG: KASAN: use-after-free in rxe_run_task+0x1e/0x60 [rdma_rxe]
Read of size 1 at addr ffff88801c50d8f4 by task check/24830
CPU: 4 PID: 24830 Comm: check Not tainted 4.20.0-rc6-dbg+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0x86/0xca
print_address_description+0x71/0x239
kasan_report.cold.5+0x242/0x301
__asan_load1+0x47/0x50
rxe_run_task+0x1e/0x60 [rdma_rxe]
rxe_post_send+0x4bd/0x8d0 [rdma_rxe]
srpt_zerolength_write+0xe1/0x160 [ib_srpt]
srpt_close_ch+0x8b/0xe0 [ib_srpt]
srpt_set_enabled+0xe7/0x150 [ib_srpt]
srpt_tpg_enable_store+0xc0/0x100 [ib_srpt]
configfs_write_file+0x157/0x1d0
__vfs_write+0xd7/0x3d0
vfs_write+0x102/0x290
ksys_write+0xab/0x130
__x64_sys_write+0x43/0x50
do_syscall_64+0x71/0x210
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Allocated by task 13856:
save_stack+0x43/0xd0
kasan_kmalloc+0xc7/0xe0
kasan_slab_alloc+0x11/0x20
kmem_cache_alloc+0x105/0x320
rxe_alloc+0xff/0x1f0 [rdma_rxe]
rxe_create_qp+0x9f/0x160 [rdma_rxe]
ib_create_qp+0xf5/0x690 [ib_core]
rdma_create_qp+0x6a/0x140 [rdma_cm]
srpt_cm_req_recv.cold.59+0x1588/0x237b [ib_srpt]
srpt_rdma_cm_req_recv.isra.35+0x1d5/0x220 [ib_srpt]
srpt_rdma_cm_handler+0x6f/0x100 [ib_srpt]
cma_listen_handler+0x59/0x60 [rdma_cm]
cma_ib_req_handler+0xd5b/0x2570 [rdma_cm]
cm_process_work+0x2e/0x110 [ib_cm]
cm_work_handler+0x2aae/0x502b [ib_cm]
process_one_work+0x481/0x9e0
worker_thread+0x67/0x5b0
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
Freed by task 3440:
save_stack+0x43/0xd0
__kasan_slab_free+0x139/0x190
kasan_slab_free+0xe/0x10
kmem_cache_free+0xbc/0x330
rxe_elem_release+0x66/0xe0 [rdma_rxe]
rxe_destroy_qp+0x3f/0x50 [rdma_rxe]
ib_destroy_qp+0x140/0x360 [ib_core]
srpt_release_channel_work+0xdc/0x310 [ib_srpt]
process_one_work+0x481/0x9e0
worker_thread+0x67/0x5b0
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
Cc: Sergey Gorenko <sergeygo@mellanox.com>
Cc: Max Gurtovoy <maxg@mellanox.com>
Cc: Laurence Oberman <loberman@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c03d6b0f9a95ae91f6a83d8133413888f89c7ef3
Author: Sagi Grimberg <sagi@grimberg.me>
Date: Thu Oct 25 12:40:57 2018 -0700
rxe: fix error completion wr_id and qp_num
commit e48d8ed9c6193502d849b35767fd18e20bbd7ba2 upstream.
Error completions must still contain a valid wr_id and
qp_num such that the consumer can rely on. Correctly
fill these fields in receive error completions.
Reported-by: Walker Benjamin <benjamin.walker@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Tested-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6bf97c01b948a2d4110c3ab19940d01f1c34ce54
Author: Dominique Martinet <dominique.martinet@cea.fr>
Date: Mon Nov 5 09:52:48 2018 +0100
9p/net: put a lower bound on msize
commit 574d356b7a02c7e1b01a1d9cba8a26b3c2888f45 upstream.
If the requested msize is too small (either from command line argument
or from the server version reply), we won't get any work done.
If it's *really* too small, nothing will work, and this got caught by
syzbot recently (on a new kmem_cache_create_usercopy() call)
Just set a minimum msize to 4k in both code paths, until someone
complains they have a use-case for a smaller msize.
We need to check in both mount option and server reply individually
because the msize for the first version request would be unchecked
with just a global check on clnt->msize.
Link: http://lkml.kernel.org/r/1541407968-31350-1-git-send-email-asmadeus@codewreck.org
Reported-by: syzbot+0c1d61e4db7db94102ca@syzkaller.appspotmail.com
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af7cc8ebab4aade6b2a1860b31bbdda3c9739ecc
Author: Mircea Caprioru <mircea.caprioru@analog.com>
Date: Thu Dec 6 15:53:15 2018 +0200
iio: dac: ad5686: fix bit shift read register
commit 0e76df5c978338f3051e5126fc0c4245c57a307a upstream.
This patch solves the register readback issue with the bit shift. When the
dac resolution was lower than the register size (ex. 12 bits out of 16
bits) the readback value was not shifted with the difference in bits and
the value was higher. Also a mask is applied on the read value in order to
get the value relative to the actual bit size.
Fixes: 0357e488b8 ("iio:dac:ad5686: Refactor the driver")
Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a854ab8f6446c551fb0f318931cabc9bb9a81c63
Author: Breno Leitao <leitao@debian.org>
Date: Wed Nov 21 17:21:09 2018 -0200
powerpc/tm: Set MSR[TS] just prior to recheckpoint
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c00000041f1576d0]
pc: c000000000054550: restore_gprs+0xb0/0x180
lr: 0000000000000000
sp: c00000041f157950
msr: 8000000100021033
current = 0xc00000041f143000
paca = 0xc00000000fb86300 softe: 0 irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
enter ? for help
[c00000041f157b30] c00000000001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c00000041f157b70] c00000000001d184 __switch_to+0x1e4/0x4c0
[c00000041f157bd0] c00000000082eeb8 __schedule+0x2f8/0x990
[c00000041f157cb0] c00000000082f598 schedule+0x48/0xc0
[c00000041f157ce0] c0000000000f0d28 worker_thread+0x148/0x610
[c00000041f157d80] c0000000000f96b0 kthread+0x120/0x140
[c00000041f157e30] c00000000000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: stable@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d9e96f37d389a0ff5825c7e9e456c81a2fe321b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Jan 11 08:05:32 2019 +0100
Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing"
This reverts commit a9935a12768851762089fda8e5a9daaf0231808e which is
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
It breaks the powerpc build, so drop it from the tree until a fix goes
upstream.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: Breno Leitao <leitao@debian.org>
Cc: Michal Suchánek <msuchanek@suse.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eb05c02903a76c3bba0bd4eebe34fa684b0ca759
Author: Jerome Brunet <jbrunet@baylibre.com>
Date: Thu Sep 6 15:59:04 2018 +0200
leds: pwm: silently error out on EPROBE_DEFER
commit 9aec30371fb095a0c9415f3f0146ae269c3713d8 upstream.
When probing, if we fail to get the pwm due to probe deferal, we shouldn't
print an error message. Just be silent in this case.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Benjamin Drung <bdrung@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ae5c75e660e2fece83b8e5aca52ffcfd79e752eb
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Mon Dec 3 20:58:05 2018 +0100
arm64: relocatable: fix inconsistencies in linker script and options
commit 3bbd3db86470c701091fb1d67f1fab6621debf50 upstream.
readelf complains about the section layout of vmlinux when building
with CONFIG_RELOCATABLE=y (for KASLR):
readelf: Warning: [21]: Link field (0) should index a symtab section.
readelf: Warning: [21]: Info field (0) should index a relocatable section.
Also, it seems that our use of '-pie -shared' is contradictory, and
thus ambiguous. In general, the way KASLR is wired up at the moment
is highly tailored to how ld.bfd happens to implement (and conflate)
PIE executables and shared libraries, so given the current effort to
support other toolchains, let's fix some of these issues as well.
- Drop the -pie linker argument and just leave -shared. In ld.bfd,
the differences between them are unclear (except for the ELF type
of the produced image [0]) but lld chokes on seeing both at the
same time.
- Rename the .rela output section to .rela.dyn, as is customary for
shared libraries and PIE executables, so that it is not misidentified
by readelf as a static relocation section (producing the warnings
above).
- Pass the -z notext and -z norelro options to explicitly instruct the
linker to permit text relocations, and to omit the RELRO program
header (which requires a certain section layout that we don't adhere
to in the kernel). These are the defaults for current versions of
ld.bfd.
- Discard .eh_frame and .gnu.hash sections to avoid them from being
emitted between .head.text and .text, screwing up the section layout.
These changes only affect the ELF image, and produce the same binary
image.
[0] b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Smith <peter.smith@linaro.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9873efe708bb3e3bb09ae40ddb18db9ac435ac52
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri Nov 30 12:35:58 2018 +0100
arm64: drop linker script hack to hide __efistub_ symbols
commit dd6846d774693bfa27d7db4dae5ea67dfe373fa1 upstream.
Commit 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_
symbols") updated the kallsyms code to filter out symbols with
the __efistub_ prefix explicitly, so we no longer require the
hack in our linker script to emit them as absolute symbols.
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f26e68af5c0a3a0704a44dd0286c785b603a5c8
Author: J. Bruce Fields <bfields@redhat.com>
Date: Thu Nov 15 11:21:40 2018 -0500
nfsd4: zero-length WRITE should succeed
commit fdec6114ee1f0f43b1ad081ad8d46b23ba126d70 upstream.
Zero-length writes are legal; from 5661 section 18.32.3: "If the count
is zero, the WRITE will succeed and return a count of zero subject to
permissions checking".
This check is unnecessary and is causing zero-length reads to return
EINVAL.
Cc: stable@vger.kernel.org
Fixes: 3fd9557aec91 "NFSD: Refactor the generic write vector fill helper"
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b6001b941af35cde42ac3fdd4079488f2f19a82
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Thu Nov 1 13:39:49 2018 -0400
lockd: Show pid of lockd for remote locks
commit b8eee0e90f9797b747113638bc75e739b192ad38 upstream.
Commit 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid
for remote locks") specified that the l_pid returned for F_GETLK on a local
file that has a remote lock should be the pid of the lock manager process.
That commit, while updating other filesystems, failed to update lockd, such
that locks created by lockd had their fl_pid set to that of the remote
process holding the lock. Fix that here to be the pid of lockd.
Also, fix the client case so that the returned lock pid is negative, which
indicates a remote lock on a remote file.
Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific...")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b541ebbe0cf0ed2cb1e1f1ea39a1195cc11b92a2
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date: Tue Oct 23 14:45:52 2018 +0300
PCI / PM: Allow runtime PM without callback functions
commit c5eb1190074cfb14c5d9cac692f1912eecf1a5e4 upstream.
a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM")
nullified the runtime PM suspend/resume callback pointers while keeping the
runtime PM enabled.
This caused the SMBus PCI device to stay in D0 with
/sys/devices/.../power/runtime_status showing "error" when the runtime PM
framework attempted to autosuspend the device. This is due to PCI bus
runtime PM, which checks for driver runtime PM callbacks and returns
-ENOSYS if they are not set.
Since i2c-i801.c doesn't need to do anything device-specific for runtime
PM, Jean Delvare proposed this be fixed in the PCI core rather than adding
dummy runtime PM callback functions in the PCI drivers.
Change pci_pm_runtime_suspend()/pci_pm_runtime_resume() so they allow
changing the PCI device power state during runtime PM transitions even if
the driver supplies no runtime PM callbacks.
This fixes the runtime PM regression on i2c-i801.c.
It is not obvious why the code previously required the runtime PM
callbacks. The test has been there since the code was introduced by
6cbf82148ff2 ("PCI PM: Run-time callbacks for PCI bus type").
On the other hand, a similar change was done to generic runtime PM
callbacks in 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm
callbacks").
Fixes: a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM")
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@vger.kernel.org # v4.18+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b37fdd94103684869a295c0d3740ac0043c13a1e
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date: Tue Oct 23 09:02:17 2018 +0200
selinux: policydb - fix byte order and alignment issues
commit 5df275cd4cf51c86d49009f1397132f284ba515e upstream.
Do the LE conversions before doing the Infiniband-related range checks.
The incorrect checks are otherwise causing a failure to load any policy
with an ibendportcon rule on BE systems. This can be reproduced by
running (on e.g. ppc64):
cat >my_module.cil <<EOF
(type test_ibendport_t)
(roletype object_r test_ibendport_t)
(ibendportcon mlx4_0 1 (system_u object_r test_ibendport_t ((s0) (s0))))
EOF
semodule -i my_module.cil
Also, fix loading/storing the 64-bit subnet prefix for OCON_IBPKEY to
use a correctly aligned buffer.
Finally, do not use the 'nodebuf' (u32) buffer where 'buf' (__le32)
should be used instead.
Tested internally on a ppc64 machine with a RHEL 7 kernel with this
patch applied.
Cc: Daniel Jurgens <danielj@mellanox.com>
Cc: Eli Cohen <eli@mellanox.com>
Cc: James Morris <jmorris@namei.org>
Cc: Doug Ledford <dledford@redhat.com>
Cc: <stable@vger.kernel.org> # 4.13+
Fixes: a806f7a1616f ("selinux: Create policydb version for Infiniband support")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6c59adbc19ac19fd70e348cb7da4dd99f894df8
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 19 20:01:24 2018 +0200
b43: Fix error in cordic routine
commit 8ea3819c0bbef57a51d8abe579e211033e861677 upstream.
The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f1b ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.
This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.
Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)")
Reported-by: Priit Laes <plaes@plaes.org>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Stable <stable@vger.kernel.org> # 2.6.34
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6ef56c9ad7f151f62992f524acce093f1a15d45b
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Tue Dec 4 15:06:27 2018 +0100
gfs2: Fix loop in gfs2_rbm_find
commit 2d29f6b96d8f80322ed2dd895bca590491c38d34 upstream.
Fix the resource group wrap-around logic in gfs2_rbm_find that commit
e579ed4f44 broke. The bug can lead to unnecessary repeated scanning of the
same bitmaps; there is a risk that future changes will turn this into an
endless loop.
Fixes: e579ed4f44 ("GFS2: Introduce rbm field bii")
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 310486107d4105ceb0a1f7884074ff0da32e7d1c
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Mon Nov 26 18:45:35 2018 +0100
gfs2: Get rid of potential double-freeing in gfs2_create_inode
commit 6ff9b09e00a441599f3aacdf577254455a048bc9 upstream.
In gfs2_create_inode, after setting and releasing the acl / default_acl, the
acl / default_acl pointers are not set to NULL as they should be. In that
state, when the function reaches label fail_free_acls, gfs2_create_inode will
try to release the same acls again.
Fix that by setting the pointers to NULL after releasing the acls. Slightly
simplify the logic. Also, posix_acl_release checks for NULL already, so
there is no need to duplicate those checks here.
Fixes: e01580bf9e4d ("gfs2: use generic posix ACL infrastructure")
Reported-by: Pan Bian <bianpan2016@163.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 30d3dfd4c42005311a0a06aa5bb9d3557fdc2e0e
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Thu Nov 15 13:18:56 2018 +0300
dlm: memory leaks on error path in dlm_user_request()
commit d47b41aceeadc6b58abc9c7c6485bef7cfb75636 upstream.
According to comment in dlm_user_request() ua should be freed
in dlm_free_lkb() after successful attach to lkb.
However ua is attached to lkb not in set_lock_args() but later,
inside request_lock().
Fixes 597d0cae0f99 ("[DLM] dlm: user locks")
Cc: stable@kernel.org # 2.6.19
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5fa01a0153fc4df23777034bc47eae31ac27731
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Thu Nov 15 13:18:24 2018 +0300
dlm: lost put_lkb on error path in receive_convert() and receive_unlock()
commit c0174726c3976e67da8649ac62cae43220ae173a upstream.
Fixes 6d40c4a708e0 ("dlm: improve error and debug messages")
Cc: stable@kernel.org # 3.5
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 294776562f96efbd9b6a64348020b9e96ccf6e9e
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Thu Nov 15 13:18:18 2018 +0300
dlm: possible memory leak on error path in create_lkb()
commit 23851e978f31eda8b2d01bd410d3026659ca06c7 upstream.
Fixes 3d6aa675fff9 ("dlm: keep lkbs in idr")
Cc: stable@kernel.org # 3.1
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03acbec28a24fd961b0e78904d5644a30bb5cfc5
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Thu Nov 15 13:15:05 2018 +0300
dlm: fixed memory leaks after failed ls_remove_names allocation
commit b982896cdb6e6a6b89d86dfb39df489d9df51e14 upstream.
If allocation fails on last elements of array need to free already
allocated elements.
v2: just move existing out_rsbtbl label to right place
Fixes 789924ba635f ("dlm: fix race between remove and lookup")
Cc: stable@kernel.org # 3.6
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6353c0a03791c5d076d5edacfabc103cc51d879c
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date: Mon Dec 17 15:14:05 2018 +0900
block: mq-deadline: Fix write completion handling
commit 7211aef86f79583e59b88a0aba0bc830566f7e8e upstream.
For a zoned block device using mq-deadline, if a write request for a
zone is received while another write was already dispatched for the same
zone, dd_dispatch_request() will return NULL and the newly inserted
write request is kept in the scheduler queue waiting for the ongoing
zone write to complete. With this behavior, when no other request has
been dispatched, rq_list in blk_mq_sched_dispatch_requests() is empty
and blk_mq_sched_mark_restart_hctx() not called. This in turn leads to
__blk_mq_free_request() call of blk_mq_sched_restart() to not run the
queue when the already dispatched write request completes. The newly
dispatched request stays stuck in the scheduler queue until eventually
another request is submitted.
This problem does not affect SCSI disk as the SCSI stack handles queue
restart on request completion. However, this problem is can be triggered
the nullblk driver with zoned mode enabled.
Fix this by always requesting a queue restart in dd_dispatch_request()
if no request was dispatched while WRITE requests are queued.
Fixes: 5700f69178e9 ("mq-deadline: Introduce zone locking support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add missing export of blk_mq_sched_restart()
Signed-off-by: Jens Axboe <axboe@kernel.dk>
commit 69e9b2858b2051b57d738e4143d1938e7de24cb5
Author: Ming Lei <ming.lei@redhat.com>
Date: Wed Dec 12 19:44:34 2018 +0800
block: deactivate blk_stat timer in wbt_disable_default()
commit 544fbd16a461a318cd80537d1331c0df5c6cf930 upstream.
rwb_enabled() can't be changed when there is any inflight IO.
wbt_disable_default() may set rwb->wb_normal as zero, however the
blk_stat timer may still be pending, and the timer function will update
wrb->wb_normal again.
This patch introduces blk_stat_deactivate() and applies it in
wbt_disable_default(), then the following IO hang triggered when running
parted & switching io scheduler can be fixed:
[ 369.937806] INFO: task parted:3645 blocked for more than 120 seconds.
[ 369.938941] Not tainted 4.20.0-rc6-00284-g906c801e5248 #498
[ 369.939797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 369.940768] parted D 0 3645 3239 0x00000000
[ 369.941500] Call Trace:
[ 369.941874] ? __schedule+0x6d9/0x74c
[ 369.942392] ? wbt_done+0x5e/0x5e
[ 369.942864] ? wbt_cleanup_cb+0x16/0x16
[ 369.943404] ? wbt_done+0x5e/0x5e
[ 369.943874] schedule+0x67/0x78
[ 369.944298] io_schedule+0x12/0x33
[ 369.944771] rq_qos_wait+0xb5/0x119
[ 369.945193] ? karma_partition+0x1c2/0x1c2
[ 369.945691] ? wbt_cleanup_cb+0x16/0x16
[ 369.946151] wbt_wait+0x85/0xb6
[ 369.946540] __rq_qos_throttle+0x23/0x2f
[ 369.947014] blk_mq_make_request+0xe6/0x40a
[ 369.947518] generic_make_request+0x192/0x2fe
[ 369.948042] ? submit_bio+0x103/0x11f
[ 369.948486] ? __radix_tree_lookup+0x35/0xb5
[ 369.949011] submit_bio+0x103/0x11f
[ 369.949436] ? blkg_lookup_slowpath+0x25/0x44
[ 369.949962] submit_bio_wait+0x53/0x7f
[ 369.950469] blkdev_issue_flush+0x8a/0xae
[ 369.951032] blkdev_fsync+0x2f/0x3a
[ 369.951502] do_fsync+0x2e/0x47
[ 369.951887] __x64_sys_fsync+0x10/0x13
[ 369.952374] do_syscall_64+0x89/0x149
[ 369.952819] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 369.953492] RIP: 0033:0x7f95a1e729d4
[ 369.953996] Code: Bad RIP value.
[ 369.954456] RSP: 002b:00007ffdb570dd48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
[ 369.955506] RAX: ffffffffffffffda RBX: 000055c2139c6be0 RCX: 00007f95a1e729d4
[ 369.956389] RDX: 0000000000000001 RSI: 0000000000001261 RDI: 0000000000000004
[ 369.957325] RBP: 0000000000000002 R08: 0000000000000000 R09: 000055c2139c6ce0
[ 369.958199] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c2139c0380
[ 369.959143] R13: 0000000000000004 R14: 0000000000000100 R15: 0000000000000008
Cc: stable@vger.kernel.org
Cc: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a8544919953942e68acb047c550a781ba125dfaa
Author: Matthew Wilcox <willy@infradead.org>
Date: Fri Dec 28 07:22:26 2018 -0800
Fix failure path in alloc_pid()
commit 1a80dade010c7a7f4885a4c4c2a7ac22cc7b34df upstream.
The failure path removes the allocated PIDs from the wrong namespace.
This could lead to us inadvertently reusing PIDs in the leaf namespace
and leaking PIDs in parent namespaces.
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR API")
Cc: <stable@vger.kernel.org>
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5781b53dd89c1034daa0929fe98f87f87d1af914
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu Dec 13 19:27:47 2018 +0100
driver core: Add missing dev->bus->need_parent_lock checks
commit e121a833745b4708b660e3fe6776129c2956b041 upstream.
__device_release_driver() has to check dev->bus->need_parent_lock
before dropping the parent lock and acquiring it again as it may
attempt to drop a lock that hasn't been acquired or lock a device
that shouldn't be locked and create a lock imbalance.
Fixes: 8c97a46af04b (driver core: hold dev's parent lock when needed)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b57b3b00828467b922838731827385174ae9a9c9
Author: Dennis Krein <Dennis.Krein@netapp.com>
Date: Fri Oct 26 07:38:24 2018 -0700
srcu: Lock srcu_data structure in srcu_gp_start()
commit eb4c2382272ae7ae5d81fdfa5b7a6c86146eaaa4 upstream.
The srcu_gp_start() function is called with the srcu_struct structure's
->lock held, but not with the srcu_data structure's ->lock. This is
problematic because this function accesses and updates the srcu_data
structure's ->srcu_cblist, which is protected by that lock. Failing to
hold this lock can result in corruption of the SRCU callback lists,
which in turn can result in arbitrarily bad results.
This commit therefore makes srcu_gp_start() acquire the srcu_data
structure's ->lock across the calls to rcu_segcblist_advance() and
rcu_segcblist_accelerate(), thus preventing this corruption.
Reported-by: Bart Van Assche <bvanassche@acm.org>
Reported-by: Christoph Hellwig <hch@infradead.org>
Reported-by: Sebastian Kuzminsky <seb.kuzminsky@gmail.com>
Signed-off-by: Dennis Krein <Dennis.Krein@netapp.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Tested-by: Dennis Krein <Dennis.Krein@netapp.com>
Cc: <stable@vger.kernel.org> # 4.16.x
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 378f9dfa495a548cbc87173477d8c4b8cbea8826
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jan 2 17:12:21 2019 +0100
ALSA: usb-audio: Always check descriptor sizes in parser code
commit 3e96d7280f16e2f787307f695a31296b9e4a1cd7 upstream.
There are a few places where we access the data without checking the
actual object size from the USB audio descriptor. This may result in
OOB access, as recently reported.
This patch addresses these missing checks. Most of added codes are
simple bLength checks in the caller side. For the input and output
terminal parsers, we put the length check in the parser functions.
For the input terminal, a new argument is added to distinguish between
UAC1 and the rest, as they treat different objects.
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Reported-by: Hui Peng <benquike@163.com>
Tested-by: Hui Peng <benquike@163.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6c8c16479b2363972d02bc6a4be132a9a9acd17e
Author: Hui Peng <benquike@163.com>
Date: Tue Dec 25 18:11:52 2018 -0500
ALSA: usb-audio: Fix an out-of-bound read in create_composite_quirks
commit cbb2ebf70daf7f7d97d3811a2ff8e39655b8c184 upstream.
In `create_composite_quirk`, the terminating condition of for loops is
`quirk->ifnum < 0`. So any composite quirks should end with `struct
snd_usb_audio_quirk` object with ifnum < 0.
for (quirk = quirk_comp->data; quirk->ifnum >= 0; ++quirk) {
.....
}
the data field of Bower's & Wilkins PX headphones usb device device quirks
do not end with {.ifnum = -1}, wihch may result in out-of-bound read.
This Patch fix the bug by adding an ending quirk object.
Fixes: 240a8af929c7 ("ALSA: usb-audio: Add a quirck for B&W PX headphones")
Signed-off-by: Hui Peng <benquike@163.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b389f9c4c97ac438174b9409b372208dea62821f
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Dec 19 14:04:47 2018 +0100
ALSA: usb-audio: Check mixer unit descriptors more strictly
commit 0bfe5e434e6665b3590575ec3c5e4f86a1ce51c9 upstream.
We've had some sanity checks of the mixer unit descriptors but they
are too loose and some corner cases are overlooked. Add more strict
checks in uac_mixer_unit_get_channels() for avoiding possible OOB
accesses by malformed descriptors.
This also changes the semantics of uac_mixer_unit_get_channels()
slightly. Now it returns zero for the cases where the descriptor
lacks of bmControls instead of -EINVAL. Then the caller side skips
the mixer creation for such unit while it keeps parsing it.
This corresponds to the case like Maya44.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8ee6f180d56fe760b275ab7f060c7b12fc05d7b7
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Dec 19 12:36:27 2018 +0100
ALSA: usb-audio: Avoid access before bLength check in build_audio_procunit()
commit f4351a199cc120ff9d59e06d02e8657d08e6cc46 upstream.
The parser for the processing unit reads bNrInPins field before the
bLength sanity check, which may lead to an out-of-bound access when a
malformed descriptor is given. Fix it by assignment after the bLength
check.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 281a9e46a94c18d3c4377aee3221b89aa65d2e00
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Jan 8 10:43:30 2019 +0300
ALSA: cs46xx: Potential NULL dereference in probe
commit 1524f4e47f90b27a3ac84efbdd94c63172246a6f upstream.
The "chip->dsp_spos_instance" can be NULL on some of the ealier error
paths in snd_cs46xx_create().
Reported-by: "Yavuz, Tuba" <tuba@ece.ufl.edu>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6584ae39fa6063c322475d6bc6cee9eaa5d5183b
Author: Brad Love <brad@nextdimension.cc>
Date: Wed Dec 19 12:07:01 2018 -0500
media: cx23885: only reset DMA on problematic CPUs
commit 4bd46aa0353e022c2401a258e93b107880a66533 upstream.
It is reported that commit 95f408bbc4e4 ("media: cx23885: Ryzen DMA
related RiSC engine stall fixes") caused regresssions with other CPUs.
Ensure that the quirk will be applied only for the CPUs that
are known to cause problems.
A module option is added for explicit control of the behaviour.
Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall fixes")
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6f66e8b227fd0292e3a75c8e7799f4c2f90dbaf
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Thu Sep 6 11:18:41 2018 +0200
mt76x0: init hw capabilities
commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream.
Enable hw capabilities supported by mt76-usb layer
- fast_xmit
- tx/rx amsdu
- MFP
- non-linear tx skbs
[This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init
hw capabilities"), which add also other different features, however
those are not supported in 4.19.
802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly
fall-back to software encryption when 802.11w ciphers are used.
Without the patch we fail to associate with WPA3 APs, so this is
considered as fix.]
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[remove marking non-working features on 4.19, make topic correspond the change]
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 13e554feddbd4ed8a3c1168036c696fa08fc05f2
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date: Mon Dec 17 14:39:16 2018 +0000
dma-direct: do not include SME mask in the DMA supported check
commit c92a54cfa0257e8ffd66b2a17d49e9c0bd4b769f upstream.
The dma_direct_supported() function intends to check the DMA mask against
specific values. However, the phys_to_dma() function includes the SME
encryption mask, which defeats the intended purpose of the check. This
results in drivers that support less than 48-bit DMA (SME encryption mask
is bit 47) from being able to set the DMA mask successfully when SME is
active, which results in the driver failing to initialize.
Change the function used to check the mask from phys_to_dma() to
__phys_to_dma() so that the SME encryption mask is not part of the check.
Fixes: c1d0af1a1d5d ("kernel/dma/direct: take DMA offset into account in dma_direct_supported")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 439022e0c2ec8fbf39e6b8d443d2b961cdc86c2d
Author: Joel Stanley <joel@jms.id.au>
Date: Fri Nov 2 11:14:55 2018 +1030
raid6/ppc: Fix build for clang
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.
We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.
Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float. So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).
This is a workaround until the issue is resolved in clang.
Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: https://github.com/ClangBuiltLinux/linux/issues/239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7dfb22b5abaaa5cb542bf661aacbf359371844cf
Author: Joel Stanley <joel@jms.id.au>
Date: Mon Nov 12 14:51:16 2018 +1030
powerpc/boot: Set target when cross-compiling for clang
commit 813af51f5d30a2da6a2523c08465f9726e51772e upstream.
Clang needs to be told which target it is building for when cross
compiling.
Link: https://github.com/ClangBuiltLinux/linux/issues/259
Signed-off-by: Joel Stanley <joel@jms.id.au>
Tested-by: Daniel Axtens <dja@axtens.net> # powerpc 64-bit BE
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4c27d53b15dbd8bae0b3095cf3cfff20d43ceb2
Author: Joel Stanley <joel@jms.id.au>
Date: Mon Nov 12 14:51:15 2018 +1030
Makefile: Export clang toolchain variables
commit 3bd9805090af843b25f97ffe5049f20ade1d86d6 upstream.
The powerpc makefile will use these in it's boot wrapper.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1637d5d2e299c33ef693bc2c85073bdd4b61adba
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Tue Nov 6 12:04:55 2018 +0900
kbuild: consolidate Clang compiler flags
commit 238bcbc4e07fad2fff99c5b157d0c37ccd4d093c upstream.
Collect basic Clang options such as --target, --prefix, --gcc-toolchain,
-no-integrated-as into a single variable CLANG_FLAGS so that it can be
easily reused in other parts of Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcaab8b5d7459dfb29216d6c4482cad798daf70a
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Tue Nov 6 12:04:54 2018 +0900
kbuild: add -no-integrated-as Clang option unconditionally
commit dbe27a002ef8573168cb64e181458ea23a74e2b6 upstream.
We are still a way off the Clang's integrated assembler support for
the kernel. Hence, -no-integrated-as is mandatory to build the kernel
with Clang. If you had an ancient version of Clang that does not
recognize this option, you would not be able to compile the kernel
anyway.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 28e1d143b868f762efdb8d4429a8487c2b0a880a
Author: Joel Stanley <joel@jms.id.au>
Date: Mon Sep 17 17:16:21 2018 +0930
powerpc: Disable -Wbuiltin-requires-header when setjmp is used
commit aea447141c7e7824b81b49acd1bc785506fba46e upstream.
The powerpc kernel uses setjmp which causes a warning when building
with clang:
In file included from arch/powerpc/xmon/xmon.c:51:
./arch/powerpc/include/asm/setjmp.h:15:13: error: declaration of
built-in function 'setjmp' requires inclusion of the header <setjmp.h>
[-Werror,-Wbuiltin-requires-header]
extern long setjmp(long *);
^
./arch/powerpc/include/asm/setjmp.h:16:13: error: declaration of
built-in function 'longjmp' requires inclusion of the header <setjmp.h>
[-Werror,-Wbuiltin-requires-header]
extern void longjmp(long *, long);
^
This *is* the header and we're not using the built-in setjump but
rather the one in arch/powerpc/kernel/misc.S. As the compiler warning
does not make sense, it for the files where setjmp is used.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
[mpe: Move subdir-ccflags in xmon/Makefile to not clobber -Werror]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba1fe90be68f4b4260a8c76d7941381619ac1cb4
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri Sep 14 15:08:54 2018 +1000
powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer
commit 6977f95e63b9b3fb4a5973481a800dd9f48a1338 upstream.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24e26062b90efe03e6f1cca51bd880353ae87d99
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri Sep 14 15:08:53 2018 +1000
powerpc: consolidate -mno-sched-epilog into FTRACE flags
commit 2a056f58fd33ccc6a0261b552b0f17e7fa4a12f3 upstream.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5b59eeba6b00ddceae41e06f363d63bb77b53d7e
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri Sep 14 15:08:52 2018 +1000
powerpc: remove old GCC version checks
commit f2910f0e6835339e6ce82cef22fa15718b7e3bfa upstream.
GCC 4.6 is the minimum supported now.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Applied to minimize unnecessary conflicts]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 668ecd6b17b98cd0c833087049158be957bd52e2
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Mon Dec 24 14:44:42 2018 +0300
sunrpc: use SVC_NET() in svcauth_gss_* functions
commit b8be5674fa9a6f3677865ea93f7803c4212f3e10 upstream.
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 807957cecdc71cce568a963a104ef6b64898f143
Author: Vasily Averin <vvs@virtuozzo.com>
Date: Wed Nov 28 11:45:57 2018 +0300
sunrpc: fix cache_head leak due to queued request
commit 4ecd55ea074217473f94cfee21bb72864d39f8d7 upstream.
After commit d202cce8963d, an expired cache_head can be removed from the
cache_detail's hash.
However, the expired cache_head may be waiting for a reply from a
previously submitted request. Such a cache_head has an increased
refcounter and therefore it won't be freed after cache_put(freeme).
Because the cache_head was removed from the hash it cannot be found
during cache_clean() and can be leaked forever, together with stalled
cache_request and other taken resources.
In our case we noticed it because an entry in the export cache was
holding a reference on a filesystem.
Fixes d202cce8963d ("sunrpc: never return expired entries in sunrpc_cache_lookup")
Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: stable@kernel.org # 2.6.35
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c5e0be35de1c8c5be3a11619aac76b8d45e0cfc
Author: Michal Hocko <mhocko@suse.com>
Date: Fri Dec 28 00:39:57 2018 -0800
memcg, oom: notify on oom killer invocation from the charge path
commit 7056d3a37d2c6aaaab10c13e8e69adc67ec1fc65 upstream.
Burt Holzman has noticed that memcg v1 doesn't notify about OOM events via
eventfd anymore. The reason is that 29ef680ae7c2 ("memcg, oom: move
out_of_memory back to the charge path") has moved the oom handling back to
the charge path. While doing so the notification was left behind in
mem_cgroup_oom_synchronize.
Fix the issue by replicating the oom hierarchy locking and the
notification.
Link: http://lkml.kernel.org/r/20181224091107.18354-1-mhocko@kernel.org
Fixes: 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Burt Holzman <burt@fnal.gov>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com
Cc: <stable@vger.kernel.org> [4.19+]
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>
commit 8da70752f5faacd5a3071163cebc37901a5ddc0b
Author: Huang Ying <ying.huang@intel.com>
Date: Fri Dec 28 00:39:53 2018 -0800
mm, swap: fix swapoff with KSM pages
commit 7af7a8e19f0c5425ff639b0f0d2d244c2a647724 upstream.
KSM pages may be mapped to the multiple VMAs that cannot be reached from
one anon_vma. So during swapin, a new copy of the page need to be
generated if a different anon_vma is needed, please refer to comments of
ksm_might_need_to_copy() for details.
During swapoff, unuse_vma() uses anon_vma (if available) to locate VMA and
virtual address mapped to the page, so not all mappings to a swapped out
KSM page could be found. So in try_to_unuse(), even if the swap count of
a swap entry isn't zero, the page needs to be deleted from swap cache, so
that, in the next round a new page could be allocated and swapin for the
other mappings of the swapped out KSM page.
But this contradicts with the THP swap support. Where the THP could be
deleted from swap cache only after the swap count of every swap entry in
the huge swap cluster backing the THP has reach 0. So try_to_unuse() is
changed in commit e07098294adf ("mm, THP, swap: support to reclaim swap
space for THP swapped out") to check that before delete a page from swap
cache, but this has broken KSM swapoff too.
Fortunately, KSM is for the normal pages only, so the original behavior
for KSM pages could be restored easily via checking PageTransCompound().
That is how this patch works.
The bug is introduced by e07098294adf ("mm, THP, swap: support to reclaim
swap space for THP swapped out"), which is merged by v4.14-rc1. So I
think we should backport the fix to from 4.14 on. But Hugh thinks it may
be rare for the KSM pages being in the swap device when swapoff, so nobody
reports the bug so far.
Link: http://lkml.kernel.org/r/20181226051522.28442-1-ying.huang@intel.com
Fixes: e07098294adf ("mm, THP, swap: support to reclaim swap space for THP swapped out")
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Reported-by: Hugh Dickins <hughd@google.com>
Tested-by: Hugh Dickins <hughd@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Shaohua Li <shli@kernel.org>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: <stable@vger.kernel.org>
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>
commit 0f1a62e0737a9a1c09d4cc86162724656db9eb70
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:35:15 2018 -0800
mm, hmm: mark hmm_devmem_{add, add_resource} EXPORT_SYMBOL_GPL
commit 02917e9f8676207a4c577d4d94eae12bf348e9d7 upstream.
At Maintainer Summit, Greg brought up a topic I proposed around
EXPORT_SYMBOL_GPL usage. The motivation was considerations for when
EXPORT_SYMBOL_GPL is warranted and the criteria for taking the exceptional
step of reclassifying an existing export. Specifically, I wanted to make
the case that although the line is fuzzy and hard to specify in abstract
terms, it is nonetheless clear that devm_memremap_pages() and HMM
(Heterogeneous Memory Management) have crossed it. The
devm_memremap_pages() facility should have been EXPORT_SYMBOL_GPL from the
beginning, and HMM as a derivative of that functionality should have
naturally picked up that designation as well.
Contrary to typical rules, the HMM infrastructure was merged upstream with
zero in-tree consumers. There was a promise at the time that those users
would be merged "soon", but it has been over a year with no drivers
arriving. While the Nouveau driver is about to belatedly make good on
that promise it is clear that HMM was targeted first and foremost at an
out-of-tree consumer.
HMM is derived from devm_memremap_pages(), a facility Christoph and I
spearheaded to support persistent memory. It combines a device lifetime
model with a dynamically created 'struct page' / memmap array for any
physical address range. It enables coordination and control of the many
code paths in the kernel built to interact with memory via 'struct page'
objects. With HMM the integration goes even deeper by allowing device
drivers to hook and manipulate page fault and page free events.
One interpretation of when EXPORT_SYMBOL is suitable is when it is
exporting stable and generic leaf functionality. The
devm_memremap_pages() facility continues to see expanding use cases,
peer-to-peer DMA being the most recent, with no clear end date when it
will stop attracting reworks and semantic changes. It is not suitable to
export devm_memremap_pages() as a stable 3rd party driver API due to the
fact that it is still changing and manipulates core behavior. Moreover,
it is not in the best interest of the long term development of the core
memory management subsystem to permit any external driver to effectively
define its own system-wide memory management policies with no
encouragement to engage with upstream.
I am also concerned that HMM was designed in a way to minimize further
engagement with the core-MM. That, with these hooks in place,
device-drivers are free to implement their own policies without much
consideration for whether and how the core-MM could grow to meet that
need. Going forward not only should HMM be EXPORT_SYMBOL_GPL, but the
core-MM should be allowed the opportunity and stimulus to change and
address these new use cases as first class functionality.
Original changelog:
hmm_devmem_add(), and hmm_devmem_add_resource() duplicated
devm_memremap_pages() and are now simple now wrappers around the core
facility to inject a dev_pagemap instance into the global pgmap_radix and
hook page-idle events. The devm_memremap_pages() interface is base
infrastructure for HMM. HMM has more and deeper ties into the kernel
memory management implementation than base ZONE_DEVICE which is itself a
EXPORT_SYMBOL_GPL facility.
Originally, the HMM page structure creation routines copied the
devm_memremap_pages() code and reused ZONE_DEVICE. A cleanup to unify the
implementations was discussed during the initial review:
http://lkml.iu.edu/hypermail/linux/kernel/1701.2/00812.html Recent work to
extend devm_memremap_pages() for the peer-to-peer-DMA facility enabled
this cleanup to move forward.
In addition to the integration with devm_memremap_pages() HMM depends on
other GPL-only symbols:
mmu_notifier_unregister_no_release
percpu_ref
region_intersects
__class_create
It goes further to consume / indirectly expose functionality that is not
exported to any other driver:
alloc_pages_vma
walk_page_range
HMM is derived from devm_memremap_pages(), and extends deep core-kernel
fundamentals. Similar to devm_memremap_pages(), mark its entry points
EXPORT_SYMBOL_GPL().
[logang@deltatee.com: PCI/P2PDMA: match interface changes to devm_memremap_pages()]
Link: http://lkml.kernel.org/r/20181130225911.2900-1-logang@deltatee.com
Link: http://lkml.kernel.org/r/154275560565.76910.15919297436557795278.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Balbir Singh <bsingharora@gmail.com>,
Cc: Michal Hocko <mhocko@suse.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <stable@vger.kernel.org>
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>
commit e890a867060ba0d02ee34a83d2999f92195b4826
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:35:07 2018 -0800
mm, hmm: use devm semantics for hmm_devmem_{add, remove}
commit 58ef15b765af0d2cbe6799ec564f1dc485010ab8 upstream.
devm semantics arrange for resources to be torn down when
device-driver-probe fails or when device-driver-release completes.
Similar to devm_memremap_pages() there is no need to support an explicit
remove operation when the users properly adhere to devm semantics.
Note that devm_kzalloc() automatically handles allocating node-local
memory.
Link: http://lkml.kernel.org/r/154275559545.76910.9186690723515469051.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
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>
commit c215c66ceab5673e7e813986279f18d718f9435d
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:35:01 2018 -0800
mm, devm_memremap_pages: add MEMORY_DEVICE_PRIVATE support
commit 69324b8f48339de2f90fdf2f774687fc6c47629a upstream.
In preparation for consolidating all ZONE_DEVICE enabling via
devm_memremap_pages(), teach it how to handle the constraints of
MEMORY_DEVICE_PRIVATE ranges.
[jglisse@redhat.com: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVATE]
Link: http://lkml.kernel.org/r/154275559036.76910.12434636179931292607.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Reported-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
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>
commit ec5471c92fb29ad848c81875840478be201eeb3f
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:34:57 2018 -0800
mm, devm_memremap_pages: fix shutdown handling
commit a95c90f1e2c253b280385ecf3d4ebfe476926b28 upstream.
The last step before devm_memremap_pages() returns success is to allocate
a release action, devm_memremap_pages_release(), to tear the entire setup
down. However, the result from devm_add_action() is not checked.
Checking the error from devm_add_action() is not enough. The api
currently relies on the fact that the percpu_ref it is using is killed by
the time the devm_memremap_pages_release() is run. Rather than continue
this awkward situation, offload the responsibility of killing the
percpu_ref to devm_memremap_pages_release() directly. This allows
devm_memremap_pages() to do the right thing relative to init failures and
shutdown.
Without this change we could fail to register the teardown of
devm_memremap_pages(). The likelihood of hitting this failure is tiny as
small memory allocations almost always succeed. However, the impact of
the failure is large given any future reconfiguration, or disable/enable,
of an nvdimm namespace will fail forever as subsequent calls to
devm_memremap_pages() will fail to setup the pgmap_radix since there will
be stale entries for the physical address range.
An argument could be made to require that the ->kill() operation be set in
the @pgmap arg rather than passed in separately. However, it helps code
readability, tracking the lifetime of a given instance, to be able to grep
the kill routine directly at the devm_memremap_pages() call site.
Link: http://lkml.kernel.org/r/154275558526.76910.7535251937849268605.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface...")
Reviewed-by: "Jérôme Glisse" <jglisse@redhat.com>
Reported-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
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>
commit 0a38f2e4a4c7686e00a92bddec62f91ad0eb1de1
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:34:54 2018 -0800
mm, devm_memremap_pages: kill mapping "System RAM" support
commit 06489cfbd915ff36c8e36df27f1c2dc60f97ca56 upstream.
Given the fact that devm_memremap_pages() requires a percpu_ref that is
torn down by devm_memremap_pages_release() the current support for mapping
RAM is broken.
Support for remapping "System RAM" has been broken since the beginning and
there is no existing user of this this code path, so just kill the support
and make it an explicit error.
This cleanup also simplifies a follow-on patch to fix the error path when
setting a devm release action for devm_memremap_pages_release() fails.
Link: http://lkml.kernel.org/r/154275557997.76910.14689813630968180480.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: "Jérôme Glisse" <jglisse@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
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>
commit b30ea244cf3e1f086da008fe6fa0278154f49244
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Dec 28 00:34:50 2018 -0800
mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL
commit 808153e1187fa77ac7d7dad261ff476888dcf398 upstream.
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management.
Specifically the facility is tightly integrated with the kernel's memory
hotplug functionality. It injects an altmap argument deep into the
architecture specific vmemmap implementation to allow allocating from
specific reserved pages, and it has Linux specific assumptions about page
structure reference counting relative to get_user_pages() and
get_user_pages_fast(). It was an oversight and a mistake that this was
not marked EXPORT_SYMBOL_GPL from the outset.
Again, devm_memremap_pagex() exposes and relies upon core kernel internal
assumptions and will continue to evolve along with 'struct page', memory
hotplug, and support for new memory types / topologies. Only an in-kernel
GPL-only driver is expected to keep up with this ongoing evolution. This
interface, and functionality derived from this interface, is not suitable
for kernel-external drivers.
Link: http://lkml.kernel.org/r/154275557457.76910.16923571232582744134.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: <stable@vger.kernel.org>
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>
commit 2c87072a3bf9bbcd747618bb2ccc3cd0da181db6
Author: Michal Hocko <mhocko@suse.com>
Date: Fri Dec 28 00:38:01 2018 -0800
hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
commit b15c87263a69272423771118c653e9a1d0672caa upstream.
We have received a bug report that an injected MCE about faulty memory
prevents memory offline to succeed on 4.4 base kernel. The underlying
reason was that the HWPoison page has an elevated reference count and the
migration keeps failing. There are two problems with that. First of all
it is dubious to migrate the poisoned page because we know that accessing
that memory is possible to fail. Secondly it doesn't make any sense to
migrate a potentially broken content and preserve the memory corruption
over to a new location.
Oscar has found out that 4.4 and the current upstream kernels behave
slightly differently with his simply testcase
===
int main(void)
{
int ret;
int i;
int fd;
char *array = malloc(4096);
char *array_locked = malloc(4096);
fd = open("/tmp/data", O_RDONLY);
read(fd, array, 4095);
for (i = 0; i < 4096; i++)
array_locked[i] = 'd';
ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked), sizeof(array_locked));
if (ret)
perror("mlock");
sleep (20);
ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096, MADV_HWPOISON);
if (ret)
perror("madvise");
for (i = 0; i < 4096; i++)
array_locked[i] = 'd';
return 0;
}
===
+ offline this memory.
In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU
list
kernel: [<ffffffff81019ac9>] dump_trace+0x59/0x340
kernel: [<ffffffff81019e9a>] show_stack_log_lvl+0xea/0x170
kernel: [<ffffffff8101ac71>] show_stack+0x21/0x40
kernel: [<ffffffff8132bb90>] dump_stack+0x5c/0x7c
kernel: [<ffffffff810815a1>] warn_slowpath_common+0x81/0xb0
kernel: [<ffffffff811a275c>] __pagevec_lru_add_fn+0x14c/0x160
kernel: [<ffffffff811a2eed>] pagevec_lru_move_fn+0xad/0x100
kernel: [<ffffffff811a334c>] __lru_cache_add+0x6c/0xb0
kernel: [<ffffffff81195236>] add_to_page_cache_lru+0x46/0x70
kernel: [<ffffffffa02b4373>] extent_readpages+0xc3/0x1a0 [btrfs]
kernel: [<ffffffff811a16d7>] __do_page_cache_readahead+0x177/0x200
kernel: [<ffffffff811a18c8>] ondemand_readahead+0x168/0x2a0
kernel: [<ffffffff8119673f>] generic_file_read_iter+0x41f/0x660
kernel: [<ffffffff8120e50d>] __vfs_read+0xcd/0x140
kernel: [<ffffffff8120e9ea>] vfs_read+0x7a/0x120
kernel: [<ffffffff8121404b>] kernel_read+0x3b/0x50
kernel: [<ffffffff81215c80>] do_execveat_common.isra.29+0x490/0x6f0
kernel: [<ffffffff81215f08>] do_execve+0x28/0x30
kernel: [<ffffffff81095ddb>] call_usermodehelper_exec_async+0xfb/0x130
kernel: [<ffffffff8161c045>] ret_from_fork+0x55/0x80
And that latter confuses the hotremove path because an LRU page is
attempted to be migrated and that fails due to an elevated reference
count. It is quite possible that the reuse of the HWPoisoned page is some
kind of fixed race condition but I am not really sure about that.
With the upstream kernel the failure is slightly different. The page
doesn't seem to have LRU bit set but isolate_movable_page simply fails and
do_migrate_range simply puts all the isolated pages back to LRU and
therefore no progress is made and scan_movable_pages finds same set of
pages over and over again.
Fix both cases by explicitly checking HWPoisoned pages before we even try
to get reference on the page, try to unmap it if it is still mapped. As
explained by Naoya:
: Hwpoison code never unmapped those for no big reason because
: Ksm pages never dominate memory, so we simply didn't have strong
: motivation to save the pages.
Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU
HWPoison pages which shouldn't happen but I couldn't convince myself about
that. Naoya has noted the following:
: Theoretically no such gurantee, because try_to_unmap() doesn't have a
: guarantee of success and then memory_failure() returns immediately
: when hwpoison_user_mappings fails.
: Or the following code (comes after hwpoison_user_mappings block) also impli=
: es
: that the target page can still have PageLRU flag.
:
: /*
: * Torn down by someone else?
: */
: if (PageLRU(p) && !PageSwapCache(p) && p->mapping =3D=3D NULL) {
: action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED);
: res =3D -EBUSY;
: goto out;
: }
:
: So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in
: current version of your patch.
Link: http://lkml.kernel.org/r/20181206120135.14079-1-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.com>
Debugged-by: Oscar Salvador <osalvador@suse.com>
Tested-by: Oscar Salvador <osalvador@suse.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org>
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>
commit e3af83bd44ecb99afe17184676f3f55e59b2cc53
Author: Minchan Kim <minchan@kernel.org>
Date: Fri Dec 28 00:36:37 2018 -0800
zram: fix double free backing device
commit 5547932dc67a48713eece4fa4703bfdf0cfcb818 upstream.
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise, kernel emits
below log. This patch fixes it.
WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828 blkdev_put+0x105/0x120
Modules linked in:
CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
RIP: 0010:blkdev_put+0x105/0x120
Call Trace:
__x64_sys_swapoff+0x46d/0x490
do_syscall_64+0x5a/0x190
entry_SYSCALL_64_after_hwframe+0x49/0xbe
irq event stamp: 4466
hardirqs last enabled at (4465): __free_pages_ok+0x1e3/0x490
hardirqs last disabled at (4466): trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (3420): __do_softirq+0x333/0x446
softirqs last disabled at (3407): irq_exit+0xd1/0xe0
Link: http://lkml.kernel.org/r/20181127055429.251614-3-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Joey Pabalinas <joeypabalinas@gmail.com>
Cc: <stable@vger.kernel.org> [4.14+]
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>
commit bc999b5099d70030a9cb1aff2c48b073f65e0f8f
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Tue Jan 8 13:58:52 2019 +0100
fork: record start_time late
commit 7b55851367136b1efd84d98fea81ba57a98304cf upstream.
This changes the fork(2) syscall to record the process start_time after
initializing the basic task structure but still before making the new
process visible to user-space.
Technically, we could record the start_time anytime during fork(2). But
this might lead to scenarios where a start_time is recorded long before
a process becomes visible to user-space. For instance, with
userfaultfd(2) and TLS, user-space can delay the execution of fork(2)
for an indefinite amount of time (and will, if this causes network
access, or similar).
By recording the start_time late, it much closer reflects the point in
time where the process becomes live and can be observed by other
processes.
Lastly, this makes it much harder for user-space to predict and control
the start_time they get assigned. Previously, user-space could fork a
process and stall it in copy_thread_tls() before its pid is allocated,
but after its start_time is recorded. This can be misused to later-on
cycle through PIDs and resume the stalled fork(2) yielding a process
that has the same pid and start_time as a process that existed before.
This can be used to circumvent security systems that identify processes
by their pid+start_time combination.
Even though user-space was always aware that start_time recording is
flaky (but several projects are known to still rely on start_time-based
identification), changing the start_time to be recorded late will help
mitigate existing attacks and make it much harder for user-space to
control the start_time a process gets assigned.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d257d4299ae7bc4b5ee16f9aea004ada8293164e
Author: Ewan D. Milne <emilne@redhat.com>
Date: Thu Dec 13 15:25:16 2018 -0500
scsi: lpfc: do not set queue->page_count to 0 if pc_sli4_params.wqpcnt is invalid
commit 4e87eb2f46ea547d12a276b2e696ab934d16cfb6 upstream.
Certain older adapters such as the OneConnect OCe10100 may not have a valid
wqpcnt value. In this case, do not set queue->page_count to 0 in
lpfc_sli4_queue_alloc() as this will prevent the driver from initializing.
Fixes: 895427bd01 ("scsi: lpfc: NVME Initiator: Base modifications")
Cc: stable@vger.kernel.org # 4.11+
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Tested-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 06fd6847c4a15207d266a92914a29a04096961c4
Author: Steffen Maier <maier@linux.ibm.com>
Date: Thu Dec 6 17:31:20 2018 +0100
scsi: zfcp: fix posting too many status read buffers leading to adapter shutdown
commit 60a161b7e5b2a252ff0d4c622266a7d8da1120ce upstream.
Suppose adapter (open) recovery is between opened QDIO queues and before
(the end of) initial posting of status read buffers (SRBs). This time
window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING
causing by design looping with exponential increase sleeps in the function
performing exchange config data during recovery
[zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up.
Suppose an event occurs for which the FCP channel would send an unsolicited
notification to zfcp by means of a previously posted SRB. We saw it with
local cable pull (link down) in multi-initiator zoning with multiple
NPIV-enabled subchannels of the same shared FCP channel.
As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial
status read buffers from within the adapter's ERP thread, the channel does
send an unsolicited notification.
Since v2.6.27 commit d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted
status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules
adapter->stat_work to re-fill the just consumed SRB from a work item.
Now the ERP thread and the work item post SRBs in parallel. Both contexts
call the helper function zfcp_status_read_refill(). The tracking of
missing (to be posted / re-filled) SRBs is not thread-safe due to separate
atomic_read() and atomic_dec(), in order to depend on posting
success. Hence, both contexts can see
atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts
one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue
(trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in
zfcp_qdio_handler_error().
An obvious and seemingly clean fix would be to schedule stat_work from the
ERP thread and wait for it to finish. This would serialize all SRB
re-fills. However, we already have another work item wait on the ERP
thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls
zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the
open port recoveries during zfcp auto port scan, but in fact it waits for
any pending recovery including an adapter recovery. This approach leads to
a deadlock. [see also v3.19 commit 18f87a67e6d6 ("zfcp: auto port scan
resiliency"); v2.6.37 commit d3e1088d6873
("[SCSI] zfcp: No ERP escalation on gpn_ft eval");
v2.6.28 commit fca55b6fb587
("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP")
fixing v2.6.27 commit c57a39a45a76
("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port");
v2.6.27 commit cc8c282963bd
("[SCSI] zfcp: Automatically attach remote ports")]
Instead make the accounting of missing SRBs atomic for parallel execution
in both the ERP thread and adapter->stat_work.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Fixes: d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall")
Cc: <stable@vger.kernel.org> #2.6.27+
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 218c81851f11712653487ee36a7a564ea3b7a254
Author: Mans Rullgard <mans@mansr.com>
Date: Wed Dec 5 13:52:47 2018 +0000
auxdisplay: charlcd: fix x/y command parsing
[ Upstream commit 9bc30ab82108e6a34dc63bf956b49edf71b1681a ]
The x/y command parsing has been broken since commit 129957069e6a
("staging: panel: Fixed checkpatch warning about simple_strtoul()").
Commit b34050fadb86 ("auxdisplay: charlcd: Fix and clean up handling of
x/y commands") fixed some problems by rewriting the parsing code,
but also broke things further by removing the check for a complete
command before attempting to parse it. As a result, parsing is
terminated at the first x or y character.
This reinstates the check for a final semicolon. Whereas the original
code use strchr(), this is wasteful seeing as the semicolon is always
at the end of the buffer. Thus check this character directly instead.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dc68052427be094c97be535710a29764bf633430
Author: Yangtao Li <tiny.windzz@gmail.com>
Date: Wed Dec 12 11:01:45 2018 -0500
serial/sunsu: fix refcount leak
[ Upstream commit d430aff8cd0c57502d873909c184e3b5753f8b88 ]
The function of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
su_get_type() doesn't do that. The match node are used as an identifier
to compare against the current node, so we can directly drop the refcount
after getting the node from the path as it is not used as pointer.
Fix this by use a single variable and drop the refcount right after
of_find_node_by_path().
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 08e7661cdd560ff290350d124d09be204d87acec
Author: Daniele Palmas <dnlplm@gmail.com>
Date: Fri Dec 21 13:07:23 2018 +0100
qmi_wwan: Fix qmap header retrieval in qmimux_rx_fixup
[ Upstream commit d667044f49513d55fcfefe4fa8f8d96091782901 ]
This patch fixes qmap header retrieval when modem is configured for
dl data aggregation.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2fb13e2004e81c7e03700726642c2dbb271c64e8
Author: Kangjie Lu <kjlu@umn.edu>
Date: Fri Dec 21 00:22:32 2018 -0600
net: netxen: fix a missing check and an uninitialized use
[ Upstream commit d134e486e831defd26130770181f01dfc6195f7d ]
When netxen_rom_fast_read() fails, "bios" is left uninitialized and may
contain random value, thus should not be used.
The fix ensures that if netxen_rom_fast_read() fails, we return "-EIO".
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8bb68ed82f0171b7bafdaf898dddca43850e7190
Author: Mantas MikulÄ—nas <grawity@gmail.com>
Date: Fri Dec 21 01:04:26 2018 -0800
Input: synaptics - enable SMBus for HP EliteBook 840 G4
[ Upstream commit 7a71712293ba303aad928f580b89addb0be2892e ]
dmesg reports that "Your touchpad (PNP: SYN3052 SYN0100 SYN0002 PNP0f13)
says it can support a different bus."
I've tested the offered psmouse.synaptics_intertouch=1 with 4.18.x and
4.19.x and it seems to work well. No problems seen with suspend/resume.
Also, it appears that RMI/SMBus mode is actually required for 3-4 finger
multitouch gestures to work -- otherwise they are not reported at all.
Information from dmesg in both modes:
psmouse serio3: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1,
caps: 0xf00123/0x840300/0x2e800/0x0, board id: 3139, fw id: 2000742
psmouse serio3: synaptics: Trying to set up SMBus access
rmi4_smbus 6-002c: registering SMbus-connected sensor
rmi4_f01 rmi4-00.fn01: found RMI device,
manufacturer: Synaptics, product: TM3139-001, fw id: 2000742
Signed-off-by: Mantas MikulÄ—nas <grawity@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ae247d60588c1e29f05d8b4861e85e59da7d6ae3
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Mon Dec 17 09:43:13 2018 +0100
gpio: mvebu: only fail on missing clk if pwm is actually to be used
[ Upstream commit c8da642d41a6811c21177c9994aa7dc35be67d46 ]
The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm
registers. So there is no need for a clk as the pwm isn't used anyhow.
So only check for the clk in the presence of the pwm registers. This fixes
a failure to probe the gpio driver for the above mentioned gpio device.
Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 332fc66790d6b2c4660c17444913dedbc7ba05cd
Author: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Date: Wed Dec 19 16:55:15 2018 -0500
lan743x: Remove MAC Reset from initialization
[ Upstream commit e0e587878f538c9e3400219b6c516b8199dc2042 ]
The MAC Reset was noticed to erase important EEPROM settings.
It is also unnecessary since a chip wide reset was done earlier
in initialization, and that reset preserves EEPROM settings.
There for this patch removes the unnecessary MAC specific reset.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e1b3575c474e4aa1c8673b0ad2face6bc12620c4
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Wed Dec 19 18:21:51 2018 -0500
virtio: fix test build after uio.h change
[ Upstream commit c5c08bed843c2b2c048c16d1296d7631d7c1620e ]
Fixes: d38499530e5 ("fs: decouple READ and WRITE from the block layer ops")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e46d5bd8fd899f04b33c9942ffdd7616d907680e
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Mon Dec 3 12:53:51 2018 +0100
m68k: Fix memblock-related crashes
[ Upstream commit bed1369f51901b17108a4bb4f7210aab183bea42 ]
When running the kernel in Fast RAM on Atari:
Ignoring memory chunk at 0x0:0xe00000 before the first chunk
...
Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
Oops: 00000000
Modules linked in:
PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
SR: 2714 SP: (ptrval) a2: 005e3314
d0: 00000000 d1: 0000000a d2: 00000e00 d3: 00000000
d4: 005e1fc0 d5: 0000001a a0: 01000000 a1: 00000000
Process swapper (pid: 0, task=(ptrval))
Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
wb 1 stat/addr/data: 0000 00000000 00000000
wb 2 stat/addr/data: 0000 00000000 00000000
wb 3 stat/addr/data: 0000 00000736 00000000
push data: 00000000 00000000 00000000 00000000
Stack from 005e1f84:
00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
00000000 00000000 00000000 00000000 006b5006 00000000 00690872
Call Trace: [<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
[<00693cd8>] mem_init+0xa/0x5c
[<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<00691be6>] start_kernel+0x1ca/0x462
[<00690872>] _sinittext+0x872/0x11f8
Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill the idle task!
As the kernel must run in the memory chunk with the lowest address,
ST-RAM is ignored, and removed from the m68k_memory[] array.
However, it is not removed from memblock, causing a crash later.
More investigation shows that there are 3 places where memory chunks are
ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
and thus causing crashes:
1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
chunks below the first chunk, cfr. above,
2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
Zorro II memory,
3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
but the first memory chunk.
Fix this by moving the calls to memblock_add() from
m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
have been removed from m68k_memory[].
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ae206a1a5e3aad52e8a64a9a104dc2ebd8c1ee3d
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Tue Dec 18 14:25:41 2018 +0900
kbuild: fix false positive warning/error about missing libelf
[ Upstream commit ef7cfd00b2caf6edeb7f169682b64be2d0a798cf ]
For the same reason as commit 25896d073d8a ("x86/build: Fix compiler
support check for CONFIG_RETPOLINE"), you cannot put this $(error ...)
into the parse stage of the top Makefile.
Perhaps I'd propose a more sophisticated solution later, but this is
the best I can do for now.
Link: https://lkml.org/lkml/2017/12/25/211
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reported-by: Qian Cai <cai@lca.pw>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ff014712e5d3b5de40514118846e8fa260a788a2
Author: Sara Sharon <sara.sharon@intel.com>
Date: Sat Dec 15 11:03:06 2018 +0200
mac80211: free skb fraglist before freeing the skb
[ Upstream commit 34b1e0e9efe101822e83cc62d22443ed3867ae7a ]
mac80211 uses the frag list to build AMSDU. When freeing
the skb, it may not be really freed, since someone is still
holding a reference to it.
In that case, when TCP skb is being retransmitted, the
pointer to the frag list is being reused, while the data
in there is no longer valid.
Since we will never get frag list from the network stack,
as mac80211 doesn't advertise the capability, we can safely
free and nullify it before releasing the SKB.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 366fc5858720b749d52a32ec15c8420939092b2a
Author: Johannes Berg <johannes.berg@intel.com>
Date: Sat Dec 15 11:03:22 2018 +0200
nl80211: fix memory leak if validate_pae_over_nl80211() fails
[ Upstream commit d350a0f431189517b1af0dbbb605c273231a8966 ]
If validate_pae_over_nl80211() were to fail in nl80211_crypto_settings(),
we might leak the 'connkeys' allocation. Fix this.
Fixes: 64bf3d4bc2b0 ("nl80211: Add CONTROL_PORT_OVER_NL80211 attribute")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 098143bfc29e1709fab54891176325a346d9e100
Author: Colin Ian King <colin.king@canonical.com>
Date: Tue Dec 18 15:19:47 2018 +0000
vxge: ensure data0 is initialized in when fetching firmware version information
[ Upstream commit f7db2beb4c2c6cc8111f5ab90fc7363ca91107b6 ]
Currently variable data0 is not being initialized so a garbage value is
being passed to vxge_hw_vpath_fw_api and this value is being written to
the rts_access_steer_data0 register. There are other occurrances where
data0 is being initialized to zero (e.g. in function
vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0
is initialized likewise to 0.
Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable")
Fixes: 8424e00dfd52 ("vxge: serialize access to steering control register")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 945b416a973b7cadc8cc2a55c822bdfc8eeef1d3
Author: Jason Martinsen <jasonmartinsen@msn.com>
Date: Tue Dec 18 05:38:22 2018 +0000
lan78xx: Resolve issue with changing MAC address
[ Upstream commit 15515aaaa69659c502003926a2067ee76176148a ]
Current state for the lan78xx driver does not allow for changing the
MAC address of the interface, without either removing the module (if
you compiled it that way) or rebooting the machine. If you attempt to
change the MAC address, ifconfig will show the new address, however,
the system/interface will not respond to any traffic using that
configuration. A few short-term options to work around this are to
unload the module and reload it with the new MAC address, change the
interface to "promisc", or reboot with the correct configuration to
change the MAC.
This patch enables the ability to change the MAC address via fairly normal means...
ifdown <interface>
modify entry in /etc/network/interfaces OR a similar method
ifup <interface>
Then test via any network communication, such as ICMP requests to gateway.
My only test platform for this patch has been a raspberry pi model 3b+.
Signed-off-by: Jason Martinsen <jasonmartinsen@msn.com>
-----
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c26419f3574e7944460af45cab9945461e7a5884
Author: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Date: Mon Dec 17 16:44:50 2018 -0500
lan743x: Expand phy search for LAN7431
[ Upstream commit 0db7d253e9f0ff1a41c602429bea93df221be6ed ]
The LAN7431 uses an external phy, and it can be found anywhere in
the phy address space. This patch uses phy address 1 for LAN7430
only. And searches all addresses otherwise.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 98876c46efd0cda22eabc15187fca86ca056d4f5
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date: Mon Dec 17 15:05:41 2018 +0200
net: macb: add missing barriers when reading descriptors
[ Upstream commit 6e0af298066f3b6d99f58989bb0dca6f764b4c6d ]
When reading buffer descriptors on RX or on TX completion, an
RX_USED/TX_USED bit is checked first to ensure that the descriptors have
been populated, i.e. the ownership has been transferred. However, there
are no memory barriers to ensure that the data protected by the
RX_USED/TX_USED bit is up-to-date with respect to that bit.
Specifically:
- TX timestamp descriptors may be loaded before ctrl is loaded for the
TX_USED check, which is racy as the descriptors may be updated between
the loads, causing old timestamp descriptor data to be used.
- RX ctrl may be loaded before addr is loaded for the RX_USED check,
which is racy as a new frame may be written between the loads, causing
old ctrl descriptor data to be used.
This issue exists for both macb_rx() and gem_rx() variants.
Fix the races by adding DMA read memory barriers on those paths and
reordering the reads in macb_rx().
I have not observed any actual problems in practice caused by these
being missing, though.
Tested on a ZynqMP based system.
Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6e48c0fc14af6ca06a793130c25476aee8a92955
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date: Mon Dec 17 15:05:40 2018 +0200
net: macb: fix dropped RX frames due to a race
[ Upstream commit 8159ecab0db9095902d4c73605fb8787f5c7d653 ]
Bit RX_USED set to 0 in the address field allows the controller to write
data to the receive buffer descriptor.
The driver does not ensure the ctrl field is ready (cleared) when the
controller sees the RX_USED=0 written by the driver. The ctrl field might
only be cleared after the controller has already updated it according to
a newly received frame, causing the frame to be discarded in gem_rx() due
to unexpected ctrl field contents.
A message is logged when the above scenario occurs:
macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor
Fix the issue by ensuring that when the controller sees RX_USED=0 the
ctrl field is already cleared.
This issue was observed on a ZynqMP based system.
Fixes: 4df95131ea80 ("net/macb: change RX path for GEM")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 873f9a559bcb73690d6f9ee6e5a7d1c360c254e2
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date: Mon Dec 17 15:05:39 2018 +0200
net: macb: fix random memory corruption on RX with 64-bit DMA
[ Upstream commit e100a897bf9b19089e57f236f2398c9e0538900e ]
64-bit DMA addresses are split in upper and lower halves that are
written in separate fields on GEM. For RX, bit 0 of the address is used
as the ownership bit (RX_USED). When the RX_USED bit is unset the
controller is allowed to write data to the buffer.
The driver does not guarantee that the controller already sees the upper
half when the RX_USED bit is cleared, possibly resulting in the
controller writing an incoming frame to an address with an incorrect
upper half and therefore possibly corrupting unrelated system memory.
Fix that by adding the necessary DMA memory barrier between the writes.
This corruption was observed on a ZynqMP based system.
Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Acked-by: Harini Katakam <harini.katakam@xilinx.com>
Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 12024f4fc118cb5b889738c55451b8224282cb15
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Dec 17 10:05:13 2018 +0300
qed: Fix an error code qed_ll2_start_xmit()
[ Upstream commit f07d4276892d97671e880190ff195a288b2d8d92 ]
We accidentally deleted the code to set "rc = -ENOMEM;" and this patch
adds it back.
Fixes: d2201a21598a ("qed: No need for LL2 frags indication")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 233ba13db681749b9a02e3c6179efea5e364bb04
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date: Mon Dec 17 17:38:51 2018 -0500
SUNRPC: Fix a race with XPRT_CONNECTING
[ Upstream commit cf76785d30712d90185455e752337acdb53d2a5d ]
Ensure that we clear XPRT_CONNECTING before releasing the XPRT_LOCK so that
we don't have races between the (asynchronous) socket setup code and
tasks in xprt_connect().
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4f784484bd96937dd86c41ec06cdac4f86c5300b
Author: Sara Sharon <sara.sharon@intel.com>
Date: Sat Dec 15 11:03:10 2018 +0200
mac80211: fix a kernel panic when TXing after TXQ teardown
[ Upstream commit a50e5fb8db83c5b57392204c21ea6c5c4ccefde6 ]
Recently TXQ teardown was moved earlier in ieee80211_unregister_hw(),
to avoid a use-after-free of the netdev data. However, interfaces
aren't fully removed at the point, and cfg80211_shutdown_all_interfaces
can for example, TX a deauth frame. Move the TXQ teardown to the
point between cfg80211_shutdown_all_interfaces and the free of
netdev queues, so we can be sure they are torn down before netdev
is freed, but after there is no ongoing TX.
Fixes: 77cfaf52eca5 ("mac80211: Run TXQ teardown code before de-registering interfaces")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 97fd4c7f6ddf1fefcce7e684f1eeb895b9fdf387
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:29 2018 +0800
net: hns: Fix ping failed when use net bridge and send multicast
[ Upstream commit 6adafc356e20189193b38ee6b9af7743078bf6b4 ]
Create a net bridge, add eth and vnet to the bridge. The vnet is used
by a virtual machine. When ping the virtual machine from the outside
host and the virtual machine send multicast at the same time, the ping
package will lost.
The multicast package send to the eth, eth will send it to the bridge too,
and the bridge learn the mac of eth. When outside host ping the virtual
mechine, it will match the promisc entry of the eth which is not expected,
and the bridge send it to eth not to vnet, cause ping lost.
So this patch change promisc tcam entry position to the END of 512 tcam
entries, which indicate lower priority. And separate one promisc entry to
two: mc & uc, to avoid package match the wrong tcam entry.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1f89e4e8b54d5bd85b1f80b8a3180b6206a6df68
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:28 2018 +0800
net: hns: Add mac pcs config when enable|disable mac
[ Upstream commit 726ae5c9e5f0c18eca8ea5296b526242c3e89822 ]
In some case, when mac enable|disable and adjust link, may cause hard to
link(or abnormal) between mac and phy. This patch adds the code for rx PCS
to avoid this bug.
Disable the rx PCS when driver disable the gmac, and enable the rx PCS
when driver enable the mac.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b686b8c073c06205774e3d4925638f506a7c398e
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:27 2018 +0800
net: hns: Fix ntuple-filters status error.
[ Upstream commit 7e74a19ca522aec7c2be201a7ae1d1d57ded409b ]
The ntuple-filters features is forced on by chip.
But it shows "ntuple-filters: off [fixed]" when use ethtool.
This patch make it correct with "ntuple-filters: on [fixed]".
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit db2ca348c80c462e0f896287366df8b090b486a6
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:26 2018 +0800
net: hns: Avoid net reset caused by pause frames storm
[ Upstream commit a57275d35576fdd89d8c771eedf1e7cf97e0dfa6 ]
There will be a large number of MAC pause frames on the net,
which caused tx timeout of net device. And then the net device
was reset to try to recover it. So that is not useful, and will
cause some other problems.
So need doubled ndev->watchdog_timeo if device watchdog occurred
until watchdog_timeo up to 40s and then try resetting to recover
it.
When collecting dfx information such as hardware registers when tx timeout.
Some registers for count were cleared when read. So need move this task
before update net state which also read the count registers.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c8e78cbcde24a7bab0a5b1a897efa439b025f981
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:25 2018 +0800
net: hns: Free irq when exit from abnormal branch
[ Upstream commit c82bd077e1ba3dd586569c733dc6d3dd4b0e43cd ]
1.In "hns_nic_init_irq", if request irq fail at index i,
the function return directly without releasing irq resources
that already requested.
2.In "hns_nic_net_up" after "hns_nic_init_irq",
if exceptional branch occurs, irqs that already requested
are not release.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ac9ae1930a1b7136d9167373fb19c4c7d05c6c85
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:24 2018 +0800
net: hns: Clean rx fbd when ae stopped.
[ Upstream commit 31f6b61d810654fb3ef43f4d8afda0f44b142fad ]
If there are packets in hardware when changing the speed or duplex,
it may cause hardware hang up.
This patch adds the code to wait rx fbd clean up when ae stopped.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1b2f8d7cc1b2a9a6de1ba349a70da0a2496966fa
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:23 2018 +0800
net: hns: Fixed bug that netdev was opened twice
[ Upstream commit 5778b13b64eca5549d242686f2f91a2c80c8fa40 ]
After resetting dsaf to try to repair chip error such as ecc error,
the net device will be open if net interface is up. But at this time
if there is the users set the net device up with the command ifconfig,
the net device will be opened twice consecutively.
Function napi_enable was called when open device. And Kernel panic will
be occurred if it was called twice consecutively. Such as follow:
static inline void napi_enable(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
smp_mb__before_clear_bit();
clear_bit(NAPI_STATE_SCHED, &n->state);
}
[37255.571996] Kernel panic - not syncing: BUG!
[37255.595234] Call trace:
[37255.597694] [<ffff80000008ab48>] dump_backtrace+0x0/0x1a0
[37255.603114] [<ffff80000008ad08>] show_stack+0x20/0x28
[37255.608187] [<ffff8000009c4944>] dump_stack+0x98/0xb8
[37255.613258] [<ffff8000009c149c>] panic+0x10c/0x26c
[37255.618070] [<ffff80000070f134>] hns_nic_net_up+0x30c/0x4e0
[37255.623664] [<ffff80000070f39c>] hns_nic_net_open+0x94/0x12c
[37255.629346] [<ffff80000084be78>] __dev_open+0xf4/0x168
[37255.634504] [<ffff80000084c1ac>] __dev_change_flags+0x98/0x15c
[37255.640359] [<ffff80000084c29c>] dev_change_flags+0x2c/0x68
[37255.769580] [<ffff8000008dc400>] devinet_ioctl+0x650/0x704
[37255.775086] [<ffff8000008ddc38>] inet_ioctl+0x98/0xb4
[37255.780159] [<ffff800000827b7c>] sock_do_ioctl+0x44/0x84
[37255.785490] [<ffff800000828e04>] sock_ioctl+0x248/0x30c
[37255.790737] [<ffff80000026dc6c>] do_vfs_ioctl+0x480/0x618
[37255.796156] [<ffff80000026de94>] SyS_ioctl+0x90/0xa4
[37255.801139] SMP: stopping secondary CPUs
[37255.805079] kbox: catch panic event.
[37255.809586] collected_len = 128928, LOG_BUF_LEN_LOCAL = 131072
[37255.816103] flush cache 0xffff80003f000000 size 0x800000
[37255.822192] flush cache 0xffff80003f000000 size 0x800000
[37255.828289] flush cache 0xffff80003f000000 size 0x800000
[37255.834378] kbox: no notify die func register. no need to notify
[37255.840413] ---[ end Kernel panic - not syncing: BUG!
This patchset fix this bug according to the flag NIC_STATE_DOWN.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 17eeca6e3d9b78142c4fb0420ea63aa28c93c7f9
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:22 2018 +0800
net: hns: Some registers use wrong address according to the datasheet.
[ Upstream commit 4ad26f117b6ea0f5d5f1592127bafb5ec65904d3 ]
According to the hip06 datasheet:
1.Six registers use wrong address:
RCB_COM_SF_CFG_INTMASK_RING
RCB_COM_SF_CFG_RING_STS
RCB_COM_SF_CFG_RING
RCB_COM_SF_CFG_INTMASK_BD
RCB_COM_SF_CFG_BD_RINT_STS
DSAF_INODE_VC1_IN_PKT_NUM_0_REG
2.The offset of DSAF_INODE_VC1_IN_PKT_NUM_0_REG should be
0x103C + 0x80 * all_chn_num
3.The offset to show the value of DSAF_INODE_IN_DATA_STP_DISC_0_REG
is wrong, so the value of DSAF_INODE_SW_VLAN_TAG_DISC_0_REG will be
overwrite
These registers are only used in "ethtool -d", so that did not cause ndev
to misfunction.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 341b8840435a56d6363fa701b9d461ab1e7c8a20
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:21 2018 +0800
net: hns: All ports can not work when insmod hns ko after rmmod.
[ Upstream commit 308c6cafde0147616da45e3a928adae55c428deb ]
There are two test cases:
1. Remove the 4 modules:hns_enet_drv/hns_dsaf/hnae/hns_mdio,
and install them again, must use "ifconfig down/ifconfig up"
command pair to bring port to work.
This patch calls phy_stop function when init phy to fix this bug.
2. Remove the 2 modules:hns_enet_drv/hns_dsaf, and install them again,
all ports can not use anymore, because of the phy devices register
failed(phy devices already exists).
Phy devices are registered when hns_dsaf installed, this patch
removes them when hns_dsaf removed.
The two cases are sometimes related, fixing the second case also requires
fixing the first case, so fix them together.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 41d54657e34bb94ce443964c9f332f6448b3699d
Author: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat Dec 15 11:53:20 2018 +0800
net: hns: Incorrect offset address used for some registers.
[ Upstream commit 4e1d4be681b2c26fd874adbf584bf034573ac45d ]
According to the hip06 Datasheet:
1. The offset of INGRESS_SW_VLAN_TAG_DISC should be 0x1A00+4*all_chn_num
2. The offset of INGRESS_IN_DATA_STP_DISC should be 0x1A50+4*all_chn_num
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2cd0c6f8d050ea68ed482f16a574c864fcb95b23
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Dec 10 21:45:07 2018 +0100
w90p910_ether: remove incorrect __init annotation
[ Upstream commit 51367e423c6501a26e67d91a655d2bc892303462 ]
The get_mac_address() function is normally inline, but when it is
not, we get a warning that this configuration is broken:
WARNING: vmlinux.o(.text+0x4aff00): Section mismatch in reference from the function w90p910_ether_setup() to the function .init.text:get_mac_address()
The function w90p910_ether_setup() references
the function __init get_mac_address().
This is often because w90p910_ether_setup lacks a __init
Remove the __init to make it always do the right thing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 997cb5039dba909f06d70797981e67c7c197d5b9
Author: Atul Gupta <atul.gupta@chelsio.com>
Date: Tue Dec 11 02:19:40 2018 -0800
net/tls: Init routines in create_ctx
[ Upstream commit 6c0563e442528733219afe15c749eb2cc365da3f ]
create_ctx is called from tls_init and tls_hw_prot
hence initialize function pointers in common routine.
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7a2b5258682f316c9979ade832acdf20645e505f
Author: Nathan Chancellor <natechancellor@gmail.com>
Date: Mon Dec 10 21:20:30 2018 -0700
drivers: net: xgene: Remove unnecessary forward declarations
[ Upstream commit 2ab4c3426c0cf711d7147e3f559638e4ab88960e ]
Clang warns:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning:
tentative array definition assumed to have one element
static const struct acpi_device_id xgene_enet_acpi_match[];
^
1 warning generated.
Both xgene_enet_acpi_match and xgene_enet_of_match are defined before
their uses at the bottom of the file so this is unnecessary. When
CONFIG_ACPI is disabled, ACPI_PTR becomes NULL so xgene_enet_acpi_match
doesn't need to be defined.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 37fc22c6cf2202e5255d25156b31124060f2be96
Author: Sinan Kaya <okaya@kernel.org>
Date: Sat Dec 1 21:40:38 2018 +0000
x86, hyperv: remove PCI dependency
[ Upstream commit c629421a990033ba539eb8585e73a2e6fa9ea631 ]
Need to be able to boot without PCI devices present.
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2e212750829792dcf723861d919ae622d78ea27e
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Fri Nov 16 17:19:21 2018 +0100
mt76: fix potential NULL pointer dereference in mt76_stop_tx_queues
[ Upstream commit 7c250f4612ae97aa04500c0d0cff69bb87046e3a ]
Starting from mac80211 commit adf8ed01e4fd ("mac80211: add an optional
TXQ for other PS-buffered frames") and commit 0eeb2b674f05 ("mac80211:
add an option for station management TXQ") a new per-sta queue has been
introduced for bufferable management frames.
sta->txq[IEEE80211_NUM_TIDS] is initialized just if the driver reports
the following hw flags:
- IEEE80211_HW_STA_MMPDU_TXQ
- IEEE80211_HW_BUFF_MMPDU_TXQ
This can produce a NULL pointer dereference in mt76_stop_tx_queues
since mt76 iterates on all available sta tx queues assuming they are
initialized by mac80211. This issue has been spotted analyzing the code
(it has not triggered any crash yet)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 131366ebda88bc119c19746dcf35c8280bb982c7
Author: Varun Prakash <varun@chelsio.com>
Date: Fri Nov 9 20:59:46 2018 +0530
scsi: target: iscsi: cxgbit: add missing spin_lock_init()
[ Upstream commit 9e6371d3c6913ff1707fb2c0274c9925f7aaef80 ]
Add missing spin_lock_init() for cdev->np_lock.
Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c9cef2c71a89a2c926dae8151f9497e72f889315
Author: Varun Prakash <varun@chelsio.com>
Date: Fri Nov 9 20:59:01 2018 +0530
scsi: target: iscsi: cxgbit: fix csk leak
[ Upstream commit 801df68d617e3cb831f531c99fa6003620e6b343 ]
csk leak can happen if a new TCP connection gets established after
cxgbit_accept_np() returns, to fix this leak free remaining csk in
cxgbit_free_np().
Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a01345407c43b4c743db2bfc1956ee282205f252
Author: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed Dec 12 08:57:03 2018 -0800
bnx2x: Send update-svid ramrod with retry/poll flags enabled
[ Upstream commit 9061193c4ee065d3240fde06767c2e06ec61decc ]
Driver sends update-SVID ramrod in the MFW notification path.
If there is a pending ramrod, driver doesn't retry the command
and storm firmware will never be updated with the SVID value.
The patch adds changes to send update-svid ramrod in process context with
retry/poll flags set.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 53471f0d893dd2c52f21872a59b5a3e9da8e2d81
Author: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed Dec 12 08:57:01 2018 -0800
bnx2x: Remove configured vlans as part of unload sequence.
[ Upstream commit 04f05230c5c13b1384f66f5186a68d7499e34622 ]
Vlans are not getting removed when drivers are unloaded. The recent storm
firmware versions had added safeguards against re-configuring an already
configured vlan. As a result, PF inner reload flows (e.g., mtu change)
might trigger an assertion.
This change is going to remove vlans (same as we do for MACs) when doing
a chip cleanup during unload.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 096795d4ccc7aa571488b890df7a4318c3a7c855
Author: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed Dec 12 08:57:00 2018 -0800
bnx2x: Clear fip MAC when fcoe offload support is disabled
[ Upstream commit bbf666c1af916ed74795493c564df6fad462cc80 ]
On some customer setups it was observed that shmem contains a non-zero fip
MAC for 57711 which would lead to enabling of SW FCoE.
Add a software workaround to clear the bad fip mac address if no FCoE
connections are supported.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7fd995d3b4446649fd29909072fa78bc076346cd
Author: Taehee Yoo <ap420073@gmail.com>
Date: Sat Dec 8 11:03:01 2018 +0900
netfilter: nf_conncount: use rb_link_node_rcu() instead of rb_link_node()
[ Upstream commit d4e7df16567b80836a78d31b42f1a9355a636d67 ]
rbnode in insert_tree() is rcu protected pointer.
So, in order to handle this pointer, _rcu function should be used.
rb_link_node_rcu() is a rcu version of rb_link_node().
Fixes: 34848d5c896e ("netfilter: nf_conncount: Split insert and traversal")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ba364929ff0c02d8a2362fe049dc076b393814b2
Author: Florian Westphal <fw@strlen.de>
Date: Tue Dec 11 07:45:29 2018 +0100
netfilter: nat: can't use dst_hold on noref dst
[ Upstream commit 542fbda0f08f1cbbc250f9e59f7537649651d0c8 ]
The dst entry might already have a zero refcount, waiting on rcu list
to be free'd. Using dst_hold() transitions its reference count to 1, and
next dst release will try to free it again -- resulting in a double free:
WARNING: CPU: 1 PID: 0 at include/net/dst.h:239 nf_xfrm_me_harder+0xe7/0x130 [nf_nat]
RIP: 0010:nf_xfrm_me_harder+0xe7/0x130 [nf_nat]
Code: 48 8b 5c 24 60 65 48 33 1c 25 28 00 00 00 75 53 48 83 c4 68 5b 5d 41 5c c3 85 c0 74 0d 8d 48 01 f0 0f b1 0a 74 86 85 c0 75 f3 <0f> 0b e9 7b ff ff ff 29 c6 31 d2 b9 20 00 48 00 4c 89 e7 e8 31 27
Call Trace:
nf_nat_ipv4_out+0x78/0x90 [nf_nat_ipv4]
nf_hook_slow+0x36/0xd0
ip_output+0x9f/0xd0
ip_forward+0x328/0x440
ip_rcv+0x8a/0xb0
Use dst_hold_safe instead and bail out if we cannot take a reference.
Fixes: a4c2fd7f7891 ("net: remove DST_NOCACHE flag")
Reported-by: Martin Zaharinov <micron10@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9e404101601531ff9416d79eee37101ef694f0da
Author: Pan Bian <bianpan2016@163.com>
Date: Mon Dec 10 14:39:37 2018 +0100
netfilter: ipset: do not call ipset_nest_end after nla_nest_cancel
[ Upstream commit 708abf74dd87f8640871b814faa195fb5970b0e3 ]
In the error handling block, nla_nest_cancel(skb, atd) is called to
cancel the nest operation. But then, ipset_nest_end(skb, atd) is
unexpected called to end the nest operation. This patch calls the
ipset_nest_end only on the branch that nla_nest_cancel is not called.
Fixes: 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 27f59f342f7c04a1f96f4b586d67e73b620f4f71
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Wed Dec 5 13:54:26 2018 +0000
ixgbe: Fix race when the VF driver does a reset
[ Upstream commit 96d1a731611f711f0cb82cea93363ae2ea8cb028 ]
When the VF driver does a reset, it (at least the Linux one) writes to
the VFCTRL register to issue a reset and then immediately sends a reset
message using the mailbox API. This is racy because when the PF driver
detects that the VFCTRL register reset pin has been asserted, it clears
the mailbox memory. Depending on ordering, the reset message sent by
the VF could be cleared by the PF driver. It then responds to the
cleared message with a NACK which causes the VF driver to malfunction.
Fix this by deferring clearing the mailbox memory until the reset
message is received.
Fixes: 939b701ad633 ("ixgbe: fix driver behaviour after issuing VFLR")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3bfed541c3ee07d8acaad08f6f23fd3ce69dd705
Author: Stefan Assmann <sassmann@kpanic.de>
Date: Tue Dec 4 15:18:52 2018 +0100
i40e: fix mac filter delete when setting mac address
[ Upstream commit 158daed16efb1170694e420ae06ba8ba954d82e5 ]
A previous commit moved the ether_addr_copy() in i40e_set_mac() before
the mac filter del/add to avoid a race. However it wasn't taken into
account that this alters the mac address being handed to
i40e_del_mac_filter().
Also changed i40e_add_mac_filter() to operate on netdev->dev_addr,
hopefully that makes the code easier to read.
Fixes: 458867b2ca0c ("i40e: don't remove netdev->dev_addr when syncing uc list")
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 56769ef90b83a803ece304d57c397eb74c9bf50a
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Fri Nov 30 23:23:28 2018 +0300
x86/dump_pagetables: Fix LDT remap address marker
[ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ]
The LDT remap placement has been changed. It's now placed before the direct
mapping in the kernel virtual address space for both paging modes.
Change address markers order accordingly.
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: dave.hansen@linux.intel.com
Cc: luto@kernel.org
Cc: peterz@infradead.org
Cc: boris.ostrovsky@oracle.com
Cc: jgross@suse.com
Cc: bhe@redhat.com
Cc: hans.van.kranenburg@mendix.com
Cc: linux-mm@kvack.org
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/20181130202328.65359-3-kirill.shutemov@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 62075c982bf702949af59bd902bc0faaf20f38b0
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Fri Nov 30 23:23:27 2018 +0300
x86/mm: Fix guard hole handling
[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
This reserved range is not defined explicitely, it is calculated relative
to other entities: direct mapping and user space ranges.
The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the
calculation invalid.
The breakage leads to crash on Xen dom0 boot[1].
Define the reserved range explicitely. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")
Reported-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: dave.hansen@linux.intel.com
Cc: luto@kernel.org
Cc: peterz@infradead.org
Cc: boris.ostrovsky@oracle.com
Cc: bhe@redhat.com
Cc: linux-mm@kvack.org
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shutemov@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit af03a980e86fc4c90bccad23dd8edc20efc589a2
Author: YueHaibing <yuehaibing@huawei.com>
Date: Tue Dec 11 11:13:39 2018 +0800
ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
[ Upstream commit 8e41cae64b08fe2e86a9ffb88b295c6b4b3a3322 ]
gcc warning this:
drivers/net/ieee802154/ca8210.c:730:10: warning:
comparison is always false due to limited range of data type [-Wtype-limits]
'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
This patch change the type of 'len' to unsigned int to avoid this,also fix
the gcc warning.
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e4bcb09d3b487b25002ec3e0a4ec9e88a594c465
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Mon Dec 10 15:22:23 2018 -0600
ibmvnic: Fix non-atomic memory allocation in IRQ context
[ Upstream commit 1d1bbc37f89b0559c9e913682f2489d89cfde6b8 ]
ibmvnic_reset allocated new reset work item objects in a non-atomic
context. This can be called from a tasklet, generating the output below.
Allocate work items with the GFP_ATOMIC flag instead.
BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 1, pid: 93, name: kworker/0:2
INFO: lockdep is turned off.
irq event stamp: 66049
hardirqs last enabled at (66048): [<c000000000122468>] tasklet_action_common.isra.12+0x78/0x1c0
hardirqs last disabled at (66049): [<c000000000befce8>] _raw_spin_lock_irqsave+0x48/0xf0
softirqs last enabled at (66044): [<c000000000a8ac78>] dev_deactivate_queue.constprop.28+0xc8/0x160
softirqs last disabled at (66045): [<c0000000000306e0>] call_do_softirq+0x14/0x24
CPU: 0 PID: 93 Comm: kworker/0:2 Kdump: loaded Not tainted 4.20.0-rc6-00001-g1b50a8f03706 #7
Workqueue: events linkwatch_event
Call Trace:
[c0000003fffe7ae0] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable)
[c0000003fffe7b30] [c00000000015ba0c] ___might_sleep+0x2dc/0x320
[c0000003fffe7bb0] [c000000000391514] kmem_cache_alloc_trace+0x3e4/0x440
[c0000003fffe7c30] [d000000005b2309c] ibmvnic_reset+0x16c/0x360 [ibmvnic]
[c0000003fffe7cc0] [d000000005b29834] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic]
[c0000003fffe7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0
[c0000003fffe7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c
[c0000003fffe7f90] [c0000000000306e0] call_do_softirq+0x14/0x24
[c0000003f3967980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0
[c0000003f39679c0] [c0000000001218a8] do_softirq+0xa8/0x100
[c0000003f39679f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180
[c0000003f3967a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80
[c0000003f3967a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160
[c0000003f3967ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520
[c0000003f3967b70] [c000000000a8cd40] dev_deactivate+0x40/0x60
[c0000003f3967ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0
[c0000003f3967bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0
[c0000003f3967c30] [c000000000a5e728] linkwatch_event+0x48/0x60
[c0000003f3967c50] [c0000000001444e8] process_one_work+0x238/0x710
[c0000003f3967d20] [c000000000144a48] worker_thread+0x88/0x4e0
[c0000003f3967db0] [c00000000014e3a8] kthread+0x178/0x1c0
[c0000003f3967e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 733f5216eb54c11690f78761391d1e43af68e097
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Mon Dec 10 15:22:22 2018 -0600
ibmvnic: Convert reset work item mutex to spin lock
[ Upstream commit 6c5c7489089608d89b7ce310bca44812e2b0a4a5 ]
ibmvnic_reset can create and schedule a reset work item from
an IRQ context, so do not use a mutex, which can sleep. Convert
the reset work item mutex to a spin lock. Locking debugger generated
the trace output below.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
in_atomic(): 1, irqs_disabled(): 1, pid: 120, name: kworker/8:1
4 locks held by kworker/8:1/120:
#0: 0000000017c05720 ((wq_completion)"events"){+.+.}, at: process_one_work+0x188/0x710
#1: 00000000ace90706 ((linkwatch_work).work){+.+.}, at: process_one_work+0x188/0x710
#2: 000000007632871f (rtnl_mutex){+.+.}, at: rtnl_lock+0x30/0x50
#3: 00000000fc36813a (&(&crq->lock)->rlock){..-.}, at: ibmvnic_tasklet+0x88/0x2010 [ibmvnic]
irq event stamp: 26293
hardirqs last enabled at (26292): [<c000000000122468>] tasklet_action_common.isra.12+0x78/0x1c0
hardirqs last disabled at (26293): [<c000000000befce8>] _raw_spin_lock_irqsave+0x48/0xf0
softirqs last enabled at (26288): [<c000000000a8ac78>] dev_deactivate_queue.constprop.28+0xc8/0x160
softirqs last disabled at (26289): [<c0000000000306e0>] call_do_softirq+0x14/0x24
CPU: 8 PID: 120 Comm: kworker/8:1 Kdump: loaded Not tainted 4.20.0-rc6 #6
Workqueue: events linkwatch_event
Call Trace:
[c0000003fffa7a50] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable)
[c0000003fffa7aa0] [c00000000015ba0c] ___might_sleep+0x2dc/0x320
[c0000003fffa7b20] [c000000000be960c] __mutex_lock+0x8c/0xb40
[c0000003fffa7c30] [d000000006202ac8] ibmvnic_reset+0x78/0x330 [ibmvnic]
[c0000003fffa7cc0] [d0000000062097f4] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic]
[c0000003fffa7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0
[c0000003fffa7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c
[c0000003fffa7f90] [c0000000000306e0] call_do_softirq+0x14/0x24
[c0000003f3f87980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0
[c0000003f3f879c0] [c0000000001218a8] do_softirq+0xa8/0x100
[c0000003f3f879f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180
[c0000003f3f87a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80
[c0000003f3f87a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160
[c0000003f3f87ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520
[c0000003f3f87b70] [c000000000a8cd40] dev_deactivate+0x40/0x60
[c0000003f3f87ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0
[c0000003f3f87bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0
[c0000003f3f87c30] [c000000000a5e728] linkwatch_event+0x48/0x60
[c0000003f3f87c50] [c0000000001444e8] process_one_work+0x238/0x710
[c0000003f3f87d20] [c000000000144a48] worker_thread+0x88/0x4e0
[c0000003f3f87db0] [c00000000014e3a8] kthread+0x178/0x1c0
[c0000003f3f87e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b7e2af3fdf8aab01f38550b19c35e9236a036aab
Author: Yussuf Khalil <dev@pp3345.net>
Date: Sat Dec 8 20:13:35 2018 -0800
Input: synaptics - enable RMI on ThinkPad T560
[ Upstream commit ca5047286c9c93a01e1f471d00a6019536992954 ]
Before commit 7fd6d98b89f3 ("i2c: i801: Allow ACPI AML access I/O
ports not reserved for SMBus"), enabling RMI on the T560 would cause
the touchpad to stop working after resuming from suspend. Now that
this issue is fixed, RMI can be enabled safely and works fine.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Yussuf Khalil <dev@pp3345.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c5dabddc2ccc51ed9c35d47fedca9ab084b95164
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Dec 4 13:52:49 2018 -0800
Input: omap-keypad - fix idle configuration to not block SoC idle states
[ Upstream commit e2ca26ec4f01486661b55b03597c13e2b9c18b73 ]
With PM enabled, I noticed that pressing a key on the droid4 keyboard will
block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT
and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as
suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>.
From the hardware point of view, looks like we need to manage the registers
for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid
blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE
register now gone with IRQF_ONESHOT, also the SoC idle state problem is
gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in
omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent
blocking deeper SoC idle states after rmmod omap4-keypad.
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c0c14b758c0c249e601f0fd84cf4878626a31c8f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu Nov 1 08:25:30 2018 +0300
scsi: bnx2fc: Fix NULL dereference in error handling
[ Upstream commit 9ae4f8420ed7be4b13c96600e3568c144d101a23 ]
If "interface" is NULL then we can't release it and trying to will only
lead to an Oops.
Fixes: aea71a024914 ("[SCSI] bnx2fc: Introduce interface structure for each vlan interface")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 98ce676bea964cc045babb1878a0267ae47ab323
Author: Himanshu Madhani <hmadhani@marvell.com>
Date: Thu Dec 6 21:49:42 2018 -0800
Revert "scsi: qla2xxx: Fix NVMe Target discovery"
[ Upstream commit c64a87f9518409d0a439895f09f6149ffdd427b8 ]
This reverts commit db186382af21e926e90df19499475f2552192b77.
This commit introduced regression with FCP discovery so revert it to fix
discovery for FCP luns.
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6bcf9ef86c865129da9ee1de52ca32de6f859ae7
Author: Florian Westphal <fw@strlen.de>
Date: Wed Dec 5 14:12:19 2018 +0100
netfilter: seqadj: re-load tcp header pointer after possible head reallocation
[ Upstream commit 530aad77010b81526586dfc09130ec875cd084e4 ]
When adjusting sack block sequence numbers, skb_make_writable() gets
called to make sure tcp options are all in the linear area, and buffer
is not shared.
This can cause tcp header pointer to get reallocated, so we must
reaload it to avoid memory corruption.
This bug pre-dates git history.
Reported-by: Neel Mehta <nmehta@google.com>
Reported-by: Shane Huntley <shuntley@google.com>
Reported-by: Heather Adkins <argv@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cee05c0371a6d5b65c96613b65227ccc2895cfad
Author: Taehee Yoo <ap420073@gmail.com>
Date: Mon Nov 26 20:03:30 2018 +0900
netfilter: nf_tables: fix suspicious RCU usage in nft_chain_stats_replace()
[ Upstream commit 4c05ec47384ab3627b62814e8f886e90cc38ce15 ]
basechain->stats is rcu protected data which is updated from
nft_chain_stats_replace(). This function is executed from the commit
phase which holds the pernet nf_tables commit mutex - not the global
nfnetlink subsystem mutex.
Test commands to reproduce the problem are:
%iptables-nft -I INPUT
%iptables-nft -Z
%iptables-nft -Z
This patch uses RCU calls to handle basechain->stats updates to fix a
splat that looks like:
[89279.358755] =============================
[89279.363656] WARNING: suspicious RCU usage
[89279.368458] 4.20.0-rc2+ #44 Tainted: G W L
[89279.374661] -----------------------------
[89279.379542] net/netfilter/nf_tables_api.c:1404 suspicious rcu_dereference_protected() usage!
[...]
[89279.406556] 1 lock held by iptables-nft/5225:
[89279.411728] #0: 00000000bf45a000 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1f/0x70 [nf_tables]
[89279.424022] stack backtrace:
[89279.429236] CPU: 0 PID: 5225 Comm: iptables-nft Tainted: G W L 4.20.0-rc2+ #44
[89279.430135] Call Trace:
[89279.430135] dump_stack+0xc9/0x16b
[89279.430135] ? show_regs_print_info+0x5/0x5
[89279.430135] ? lockdep_rcu_suspicious+0x117/0x160
[89279.430135] nft_chain_commit_update+0x4ea/0x640 [nf_tables]
[89279.430135] ? sched_clock_local+0xd4/0x140
[89279.430135] ? check_flags.part.35+0x440/0x440
[89279.430135] ? __rhashtable_remove_fast.constprop.67+0xec0/0xec0 [nf_tables]
[89279.430135] ? sched_clock_cpu+0x126/0x170
[89279.430135] ? find_held_lock+0x39/0x1c0
[89279.430135] ? hlock_class+0x140/0x140
[89279.430135] ? is_bpf_text_address+0x5/0xf0
[89279.430135] ? check_flags.part.35+0x440/0x440
[89279.430135] ? __lock_is_held+0xb4/0x140
[89279.430135] nf_tables_commit+0x2555/0x39c0 [nf_tables]
Fixes: f102d66b335a4 ("netfilter: nf_tables: use dedicated mutex to guard transactions")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 537e9a8c301d601da81b3966352dd42dce14a08c
Author: Alexander Aring <aring@mojatatu.com>
Date: Thu Nov 29 17:41:54 2018 -0500
ieee802154: hwsim: fix off-by-one in parse nested
[ Upstream commit a73d4e1490913b76b292f91553b7ba08a65caa3f ]
This patch fixes a off-by-one mistake in nla_parse_nested() functions of
mac802154_hwsim driver. I had to enabled stack protector so I was able
to reproduce it.
Reference: https://github.com/linux-wpan/wpan-tools/issues/17
Signed-off-by: Alexander Aring <aring@mojatatu.com>
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 083d552a890cb7998395ad92f6aacccd082d8f37
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu Nov 22 07:26:24 2018 +0100
xfrm: Fix NULL pointer dereference in xfrm_input when skb_dst_force clears the dst_entry.
[ Upstream commit 0152eee6fc3b84298bb6a79961961734e8afa5b8 ]
Since commit 222d7dbd258d ("net: prevent dst uses after free")
skb_dst_force() might clear the dst_entry attached to the skb.
The xfrm code doesn't expect this to happen, so we crash with
a NULL pointer dereference in this case.
Fix it by checking skb_dst(skb) for NULL after skb_dst_force()
and drop the packet in case the dst_entry was cleared. We also
move the skb_dst_force() to a codepath that is not used when
the transformation was offloaded, because in this case we
don't have a dst_entry attached to the skb.
The output and forwarding path was already fixed by
commit 9e1437937807 ("xfrm: Fix NULL pointer dereference when
skb_dst_force clears the dst_entry.")
Fixes: 222d7dbd258d ("net: prevent dst uses after free")
Reported-by: Jean-Philippe Menil <jpmenil@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 00eff089dfb7a3d542715d6cddd42d47828ed625
Author: Benjamin Poirier <bpoirier@suse.com>
Date: Mon Nov 5 17:00:53 2018 +0900
xfrm: Fix bucket count reported to userspace
[ Upstream commit ca92e173ab34a4f7fc4128bd372bd96f1af6f507 ]
sadhcnt is reported by `ip -s xfrm state count` as "buckets count", not the
hash mask.
Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.")
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 34a2f36c0115b52c316a10c53472fe6dfc2d17ea
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat Oct 27 06:12:06 2018 +0000
xfrm: Fix error return code in xfrm_output_one()
[ Upstream commit 533555e5cbb6aa2d77598917871ae5b579fe724b ]
xfrm_output_one() does not return a error code when there is
no dst_entry attached to the skb, it is still possible crash
with a NULL pointer dereference in xfrm_output_resume(). Fix
it by return error code -EHOSTUNREACH.
Fixes: 9e1437937807 ("xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7519ffa9118c2fac3ce30fc517abbef731ccda13
Author: Qian Cai <cai@lca.pw>
Date: Fri Dec 14 14:17:20 2018 -0800
checkstack.pl: fix for aarch64
[ Upstream commit f1733a1d3cd32a9492f4cf866be37bb46e10163d ]
There is actually a space after "sp," like this,
ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]!
Right now, checkstack.pl isn't able to print anything on aarch64,
because it won't be able to match the stating objdump line of a function
due to this missing space. Hence, it displays every stack as zero-size.
After this patch, checkpatch.pl is able to match the start of a
function's objdump, and is then able to calculate each function's stack
correctly.
Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8c9c3747750a5d8fe217a51d026f3d2c0a4771ae
Author: Mark Zhang <markz@mellanox.com>
Date: Wed Dec 5 15:50:49 2018 +0200
IB/core: Fix oops in netdev_next_upper_dev_rcu()
[ Upstream commit 37fbd834b4e492dc41743830cbe435f35120abd8 ]
When support for bonding of RoCE devices was added, there was
necessarily a link between the RoCE device and the paired netdevice that
was part of the bond. If you remove the mlx4_en module, that paired
association is broken (the RoCE device is still present but the paired
netdevice has been released). We need to account for this in
is_upper_ndev_bond_master_filter() and filter out those links with a
broken pairing or else we later oops in netdev_next_upper_dev_rcu().
Fixes: 408f1242d940 ("IB/core: Delete lower netdevice default GID entries in bonding scenario")
Signed-off-by: Mark Zhang <markz@mellanox.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a8d16017db2ecb376103fda6bbc8cdcf10cd3283
Author: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Date: Thu Dec 6 15:51:37 2018 -0500
drm/amdgpu: Fix DEBUG_LOCKS_WARN_ON(depth <= 0) in amdgpu_ctx.lock
[ Upstream commit c554206077428af56cc2e0314b86b41cd030458c ]
If CS is submitted using guilty ctx, we terminate amdgpu_cs_parser_init
before locking ctx->lock, latter in amdgpu_cs_parser_fini we still are
trying to release the lock just becase parser->ctx != NULL.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@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 <sashal@kernel.org>
commit 54568ab2e11f2744674ced22763939245a16ace2
Author: Oliver O'Halloran <oohall@gmail.com>
Date: Fri Dec 7 02:17:14 2018 +1100
powerpc/mm: Fallback to RAM if the altmap is unusable
[ Upstream commit 9ef34630a4614ee1cd478f9859ebea55d55f10ec ]
The "altmap" is used to provide a pool of memory that is reserved for
the vmemmap backing of hot-plugged memory. This is useful when adding
large amount of ZONE_DEVICE memory to a system with a limited amount of
normal memory.
On ppc64 we use huge pages to map the vmemmap which requires the backing
storage to be contigious and aligned to the hugepage size. The altmap
implementation allows for the altmap provider to reserve a few PFNs at
the start of the range for it's own uses and when this occurs the
first chunk of the altmap is not usable for hugepage mappings. On hash
there is no sane way to fall back to a normal sized page mapping so we
fail the allocation. This results in memory hotplug failing with
ENOMEM when the new range doesn't fall into an existing vmemmap block.
This patch handles this case by falling back to using system memory
rather than failing if we cannot allocate from the altmap. This
fallback should only ever be used for the first vmemmap block so it
should not cause excess memory consumption.
Fixes: 7b73d978a5d0 ("mm: pass the vmem_altmap to vmemmap_populate")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 52e1f29e8bcf655dd170bac485a1deda76fa5f1f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Dec 6 09:03:36 2018 +1000
Input: restore EV_ABS ABS_RESERVED
[ Upstream commit c201e3808e0e4be9b98d192802085a9f491bd80c ]
ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b4592b838322d621ff74e803d9b01e77b6957af6
Author: Yishai Hadas <yishaih@mellanox.com>
Date: Wed Dec 5 15:50:21 2018 +0200
IB/mlx5: Block DEVX umem from the non applicable cases
[ Upstream commit 47f07f03b5ee436fe074c4fb1fb28d013c36a0d8 ]
Blocks creating a DEVX UMEM with the non applicable access flags
as of ODP, MW_BIND, etc.
Specifically when an ODP flag is used below WARN call trace is issued.
[ 2510.404131] RIP: 0010:__mlx5_ib_populate_pas+0x207/0x220 [mlx5_ib]
...
[ 2510.404143] Call Trace:
[ 2510.404150] ? __kmalloc_node+0x1b3/0x280
[ 2510.404156] ? _uverbs_alloc+0x63/0x90 [ib_uverbs]
[ 2510.404158] ? _uverbs_alloc+0x63/0x90 [ib_uverbs]
[ 2510.404162] mlx5_ib_populate_pas+0x53/0x60 [mlx5_ib]
[ 2510.404167] mlx5_ib_handler_MLX5_IB_METHOD_DEVX_UMEM_REG+0x273/0x3f0 [mlx5_ib]
Fixes: aeae94579caf ("IB/mlx5: Add DEVX support for memory registration")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit aad142a61ebb35cd53111b600cc7459e88c1813d
Author: Fabio Estevam <festevam@gmail.com>
Date: Wed Dec 5 09:05:30 2018 -0200
ARM: dts: imx7d-nitrogen7: Fix the description of the Wifi clock
[ Upstream commit f15096f12a4e9340168df5fdd9201aa8ed60d59e ]
According to bindings/regulator/fixed-regulator.txt the 'clocks' and
'clock-names' properties are not valid ones.
In order to turn on the Wifi clock the correct location for describing
the CLKO2 clock is via a mmc-pwrseq handle, so do it accordingly.
Fixes: 56354959cfec ("ARM: dts: imx: add Boundary Devices Nitrogen7 board")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit eab3109e154766740e617195a7d321b8c6a52c35
Author: Anson Huang <anson.huang@nxp.com>
Date: Tue Dec 4 03:17:45 2018 +0000
ARM: imx: update the cpu power up timing setting on i.mx6sx
[ Upstream commit 1e434b703248580b7aaaf8a115d93e682f57d29f ]
The sw2iso count should cover ARM LDO ramp-up time,
the MAX ARM LDO ramp-up time may be up to more than
100us on some boards, this patch sets sw2iso to 0xf
(~384us) which is the reset value, and it is much
more safe to cover different boards, since we have
observed that some customer boards failed with current
setting of 0x2.
Fixes: 05136f0897b5 ("ARM: imx: support arm power off in cpuidle for i.mx6sx")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 94541b595ad431702567e536eba9a6cc422b50c5
Author: Fabio Estevam <festevam@gmail.com>
Date: Fri Nov 30 08:31:29 2018 -0200
ARM: dts: imx7d-pico: Describe the Wifi clock
[ Upstream commit c3b9ab5db11d8098ca7674175f12ab21cdce1bbb ]
The Wifi chip should be clocked by a 32kHz clock coming from i.MX7D
CLKO2 output pin, so describe the pinmux and clock hierarchy in the
device tree to allow the Wifi chip to be properly clocked.
Managed to successfully test Wifi with such change. Used the standard
nvram.txt file provided by TechNexion, which selects an external 32kHz
clock for the Wifi chip by default.
Fixes: 99a52450c707 ("ARM: dts: imx7d-pico: Add Wifi support")
Suggested-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Tested-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 270a08ffa1b96f366cf5c9dc42c56d42d2e4d9f1
Author: Hans de Goede <hdegoede@redhat.com>
Date: Mon Nov 26 11:52:18 2018 +0100
HID: ite: Add USB id match for another ITE based keyboard rfkill key quirk
[ Upstream commit 4050207485e47e00353e87f2fe2166083e282688 ]
The 258a:6a88 keyboard-dock shipped with the Prowise PT301 tablet is
likely another ITE based design. The controller die is directly bonded
to the PCB with a blob of black glue on top so there are no markings and
the 258a vendor-id used is unknown anywhere. But the keyboard has the
exact same hotkeys mapped to Fn+F1 - F10 as the other ITE8595 keyboard
I have *and* it has the same quirky behavior wrt the rfkill hotkey.
Either way as said this keyboard has the same quirk for its rfkill /
airplane mode hotkey as the ITE 8595 chip, it only sends a single release
event when pressed and released, it never sends a press event.
This commit adds the 258a:6a88 USB id to the hid-ite id-table, fixing
the rfkill key not working on this keyboard.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d4fdc5e82357d883a6d1183fa7d89b108d23722b
Author: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon Nov 26 12:59:16 2018 +1100
powerpc/mm: Fix linux page tables build with some configs
[ Upstream commit 462951cd32e1496dc64b00051dfb777efc8ae5d8 ]
For some configs the build fails with:
arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers':
arch/powerpc/mm/dump_linuxpagetables.c:306:39: error: 'PKMAP_BASE' undeclared (first use in this function)
arch/powerpc/mm/dump_linuxpagetables.c:314:50: error: 'LAST_PKMAP' undeclared (first use in this function)
These come from highmem.h, including that fixes the build.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4642a5c582997afefaf87d23a37f55440ee85199
Author: Paul Mackerras <paulus@ozlabs.org>
Date: Tue Nov 27 09:01:54 2018 +1100
powerpc: Fix COFF zImage booting on old powermacs
[ Upstream commit 5564597d51c8ff5b88d95c76255e18b13b760879 ]
Commit 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper
as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor
at the start of crt0.S to have a hard-coded start address of 0x500000
rather than a reference to _zimage_start, presumably because having
a reference to a symbol introduced a relocation which is awkward to
handle in a position-independent executable. Unfortunately, what is
at 0x500000 in the COFF image is not the first instruction, but the
procedure descriptor itself, that is, a word containing 0x500000,
which is not a valid instruction. Hence, booting a COFF zImage
results in a "DEFAULT CATCH!, code=FFF00700" message from Open
Firmware.
This fixes the problem by (a) putting the procedure descriptor in the
data section and (b) adding a branch to _zimage_start as the first
instruction in the program.
Fixes: 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a294de739535135a614a40172fb236c77e52555b
Author: Ryder Lee <ryder.lee@mediatek.com>
Date: Mon Nov 12 09:28:06 2018 +0800
arm64: dts: mt7622: fix no more console output on rfb1
[ Upstream commit 6c05946e349d92f527d98644fbc9c41f06312c00 ]
No default serial console on boot.
Fix this by using a 'stdout-path' property that points to the device.
Fixes: c0d9f9ad4f76 ("arm64: dts: mt7622: add earlycon to mt7622-rfb1 board")
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
[mb: Fix commit message]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cd9ff62bad88456448016ad5d542457147f75798
Author: Jerome Brunet <jbrunet@baylibre.com>
Date: Tue Nov 13 11:55:36 2018 +0100
pinctrl: meson: fix pull enable register calculation
[ Upstream commit 614b1868a125a0ba24be08f3a7fa832ddcde6bca ]
We just changed the code so we apply bias disable on the correct
register but forgot to align the register calculation. The result
is that we apply the change on the correct register, but possibly
at the incorrect offset/bit
This went undetected because offsets tends to be the same between
REG_PULL and REG_PULLEN for a given pin the EE controller. This
is not true for the AO controller.
Fixes: e39f9dd8206a ("pinctrl: meson: fix pinconf bias disable")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0dc2ffac869ca57047ffa21bec679b5e0403d383
Author: Corentin Labbe <clabbe@baylibre.com>
Date: Mon Jul 9 19:51:54 2018 +0000
ARM: dts: sun8i: a83t: bananapi-m3: increase vcc-pd voltage to 3.3V
[ Upstream commit 5f8208f557065163f9a8089ea2ea7888f9d96922 ]
Since commit d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add
AXP813 regulator nodes") my BPIM3 no longer works at gigabit speed.
With the default setting, dldo3 is regulated at 2.9v which seems
sufficient for the PHY but the aforementioned commit drops it to 2.5V
which is insufficient. Note that this behaviour is random for all BPIM3.
Some work with 2.5V, but some don't.
Finnaly, someone from Bananapi confirmed that this regulator must be set
to 3.3V.
Fixes: d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813
regulator nodes")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
[wens@csie.org: Reworked commit message]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>