4.14.45-stable review
Subsystems (8)
Greg Kroah-Hartman
maintainerPATCH 333/496 dp83640: Ensure against premature access to PHY registers after reset
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Esben Haabendal <[email protected]>
[ Upstream commit 76327a35caabd1a932e83d6a42b967aa08584e5d ]
The datasheet specifies a 3uS pause after performing a software reset. The default implementation of genphy_soft_reset() does not provide this, so implement soft_reset with the needed pause.
--- drivers/net/phy/dp83640.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/net/phy/dp83640.c +18 -0
@@ -1207,6 +1207,23 @@ static void dp83640_remove(struct phy_dekfree (dp83640); } +static int dp83640_soft_reset (struct phy_device *phydev) +{ +int ret; + + ret =genphy_soft_reset (phydev); +if (ret <0 ) +return ret; + +/* From DP83640 datasheet: "Software driver code must wait 3 us +* following a software reset before allowing further serial MII +* operations with the DP83640." +*/ +udelay (10 );/* Taking udelay inaccuracy into account */ + +return 0 ; +} +static int dp83640_config_init (struct phy_device *phydev) {struct dp83640_private *dp83640 = phydev->priv;
@@ -1501,6 +1518,7 @@ static struct phy_driver dp83640_driver .flags = PHY_HAS_INTERRUPT, .probe = dp83640_probe, .remove = dp83640_remove, + .soft_reset = dp83640_soft_reset, .config_init = dp83640_config_init, .config_aneg = genphy_config_aneg, .read_status = genphy_read_status,
Greg Kroah-Hartman
maintainerPATCH 334/496 ibmvnic: Zero used TX descriptor counter on reset
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Falcon <[email protected]>
[ Upstream commit 41f714672f93608751dbd2fa2291d476a8ff0150 ]
The counter that tracks used TX descriptors pending completion needs to be zeroed as part of a device reset. This change fixes a bug causing transmit queues to be stopped unnecessarily and in some cases a transmit queue stall and timeout reset. If the counter is not reset, the remaining descriptors will not be "removed", effectively reducing queue capacity. If the queue is over half full, it will cause the queue to stall if stopped.
--- drivers/net/ethernet/ibm/ibmvnic.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/ibm/ibmvnic.c +1 -0
@@ -1962,6 +1962,7 @@ static int reset_one_sub_crq_queue(struc }memset (scrq->msgs,0 ,4 *PAGE_SIZE ); +atomic_set (&scrq->used,0 ); scrq->cur =0 ; rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
Greg Kroah-Hartman
maintainerPATCH 335/496 mm/ksm: fix interaction with THP
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudio Imbrenda <[email protected]>
[ Upstream commit 77da2ba0648a4fd52e5ff97b8b2b8dd312aec4b0 ]
This patch fixes a corner case for KSM. When two pages belong or belonged to the same transparent hugepage, and they should be merged, KSM fails to split the page, and therefore no merging happens.
This bug can be reproduced by:
* making sure ksm is running (in case disabling ksmtuned)
* enabling transparent hugepages
* allocating a THP-aligned 1-THP-sized buffer e.g. on amd64: posix_memalign(&p, 1<<21, 1<<21)
* filling it with the same values
e.g. memset(p, 42, 1<<21)
* performing madvise to make it mergeable
e.g. madvise(p, 1<<21, MADV_MERGEABLE)
* waiting for KSM to perform a few scans
The expected outcome is that the all the pages get merged (1 shared and the rest sharing); the actual outcome is that no pages get merged (1 unshared and the rest volatile)
The reason of this behaviour is that we increase the reference count once for both pages we want to merge, but if they belong to the same hugepage (or compound page), the reference counter used in both cases is the one of the head of the compound page. This means that split_huge_page will find a value of the reference counter too high and will fail.
This patch solves this problem by testing if the two pages to merge belong to the same hugepage when attempting to merge them. If so, the hugepage is split safely. This means that the hugepage is not split if not necessary.
--- mm/ksm.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
mm/ksm.c +28 -0
@@ -2085,8 +2085,22 @@ static void cmp_and_merge_page(struct pa tree_rmap_item =unstable_tree_search_insert (rmap_item, page, &tree_page);if (tree_rmap_item) { +bool split; + kpage =try_to_merge_two_pages (rmap_item, page, tree_rmap_item, tree_page); +/* +* If both pages we tried to merge belong to the same compound +* page, then we actually ended up increasing the reference +* count of the same compound page twice, and split_huge_page +* failed. +* Here we set a flag if that happened, and we use it later to +* try split_huge_page again. Since we call put_page right +* afterwards, the reference count will be correct and +* split_huge_page should succeed. +*/ + split =PageTransCompound (page) + &&compound_head (page) ==compound_head (tree_page);put_page (tree_page);if (kpage) {/*
@@ -2113,6 +2127,20 @@ static void cmp_and_merge_page(struct pabreak_cow (tree_rmap_item);break_cow (rmap_item); } + }else if (split) { +/* +* We are here if we tried to merge two pages and +* failed because they both belonged to the same +* compound page. We will split the page now, but no +* merging will take place. +* We do not want to add the cost of a full lock; if +* the page is locked, it is better to skip it and +* perhaps try again later. +*/ +if (!trylock_page (page)) +return ; +split_huge_page (page); +unlock_page (page); } } }
Greg Kroah-Hartman
maintainerPATCH 336/496 mm: fix races between address_space dereference and free in page_evicatable
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
[ Upstream commit e92bb4dd9673945179b1fc738c9817dd91bfb629 ]
When page_mapping() is called and the mapping is dereferenced in page_evicatable() through shrink_active_list(), it is possible for the inode to be truncated and the embedded address space to be freed at the same time. This may lead to the following race.
CPU1 CPU2
truncate(inode) shrink_active_list()
... page_evictable(page)
truncate_inode_page(mapping, page);
delete_from_page_cache(page)
spin_lock_irqsave(&mapping->tree_lock, flags);
__delete_from_page_cache(page, NULL)
page_cache_tree_delete(..)
... mapping = page_mapping(page);
page->mapping = NULL;
...
spin_unlock_irqrestore(&mapping->tree_lock, flags);
page_cache_free_page(mapping, page)
put_page(page)
if (put_page_testzero(page)) -> false- inode now has no pages and can be freed including embedded address_space
mapping_unevictable(mapping) test_bit(AS_UNEVICTABLE, &mapping->flags);
- we've dereferenced mapping which is potentially already free.
Similar race exists between swap cache freeing and page_evicatable() too.
The address_space in inode and swap cache will be freed after a RCU grace period. So the races are fixed via enclosing the page_mapping() and address_space usage in rcu_read_lock/unlock(). Some comments are added in code to make it clear what is protected by the RCU read lock.
--- mm/vmscan.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
mm/vmscan.c +7 -1
@@ -3961,7 +3961,13 @@ int node_reclaim(struct pglist_data *pgd*/ int page_evictable (struct page *page) { -return !mapping_unevictable (page_mapping (page)) && !PageMlocked (page); +int ret; + +/* Prevent address_space of inode and swap cache from being freed */ +rcu_read_lock (); + ret = !mapping_unevictable (page_mapping (page)) && !PageMlocked (page); +rcu_read_unlock (); +return ret; }#ifdef CONFIG_SHMEM
Greg Kroah-Hartman
maintainerPATCH 337/496 mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Shi <[email protected]>
[ Upstream commit f0849ac0b8e072073ec5fcc7fadd05a77434364e ]
For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced.
When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the result of the last PTE. If the last PTE has not referenced, the referenced flag will be cleared.
Just set referenced when ptep{pmdp}_clear_young_notify() returns true.
--- mm/page_idle.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
mm/page_idle.c +8 -4
@@ -65,11 +65,15 @@ static bool page_idle_clear_pte_refs_onewhile (page_vma_mapped_walk (&pvmw)) { addr = pvmw.address;if (pvmw.pte) { - referenced =ptep_clear_young_notify (vma, addr, - pvmw.pte); +/* +* For PTE-mapped THP, one sub page is referenced, +* the whole THP is referenced. +*/ +if (ptep_clear_young_notify (vma, addr, pvmw.pte)) + referenced = true; }else if (IS_ENABLED (CONFIG_TRANSPARENT_HUGEPAGE )) { - referenced =pmdp_clear_young_notify (vma, addr, - pvmw.pmd); +if (pmdp_clear_young_notify (vma, addr, pvmw.pmd)) + referenced = true; }else {/* unexpected pmd-mapped page? */ WARN_ON_ONCE (1 );
Greg Kroah-Hartman
maintainerPATCH 338/496 Btrfs: bail out on error during replay_dir_deletes
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit b98def7ca6e152ee55e36863dddf6f41f12d1dc6 ]
If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs to bail out, otherwise @ret would be forced to be 0 after 'break;' and the caller won't be aware of it.
--- fs/btrfs/tree-log.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/btrfs/tree-log.c +3 -1
@@ -2272,8 +2272,10 @@ again: nritems =btrfs_header_nritems (path->nodes[0 ]);if (path->slots[0 ] >= nritems) { ret =btrfs_next_leaf (root, path); -if (ret) +if (ret ==1 )break ; +else if (ret <0 ) + goto out; }btrfs_item_key_to_cpu (path->nodes[0 ], &found_key, path->slots[0 ]);
Greg Kroah-Hartman
maintainerPATCH 339/496 Btrfs: fix NULL pointer dereference in log_dir_items
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit 80c0b4210a963e31529e15bf90519708ec947596 ]
0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is returned, path->nodes[0] could be NULL, log_dir_items lacks such a check for <0 and we may run into a null pointer dereference panic.
--- fs/btrfs/tree-log.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
fs/btrfs/tree-log.c +5 -2
@@ -3462,8 +3462,11 @@ static noinline int log_dir_items(struct* from this directory and from this transaction */ ret =btrfs_next_leaf (root, path); -if (ret ==1 ) { - last_offset = (u64)-1 ; +if (ret) { +if (ret ==1 ) + last_offset = (u64)-1 ; +else + err = ret; goto done; }btrfs_item_key_to_cpu (path->nodes[0 ], &tmp, path->slots[0 ]);
Greg Kroah-Hartman
maintainerPATCH 340/496 btrfs: Fix possible softlock on single core machines
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Borisov <[email protected]>
[ Upstream commit 1e1c50a929bc9e49bc3f9935b92450d9e69f8158 ]
do_chunk_alloc implements a loop checking whether there is a pending chunk allocation and if so causes the caller do loop. Generally this loop is executed only once, however testing with btrfs/072 on a single core vm machines uncovered an extreme case where the system could loop indefinitely. This is due to a missing cond_resched when loop which doesn't give a chance to the previous chunk allocator finish its job.
The fix is to simply add the missing cond_resched.
--- fs/btrfs/extent-tree.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/extent-tree.c +1 -0
@@ -4675,6 +4675,7 @@ again:if (wait_for_alloc) {mutex_unlock (&fs_info->chunk_mutex); wait_for_alloc =0 ; +cond_resched (); goto again; }
Greg Kroah-Hartman
maintainerPATCH 341/496 IB/rxe: Fix for oops in rxe_register_device on ppc64le arch
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikhail Malygin <[email protected]>
[ Upstream commit efc365e7290d040fbd43f60b0e97653489a739d4 ]
On ppc64le arch rxe_add command causes oops in kernel log:
[ 92.495140] Oops: Kernel access of bad area, sig: 11 [#1] [ 92.499710] SMP NR_CPUS=2048 NUMA pSeries [ 92.499792] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) nf_conntrack_netlink(E) nfnetlink(E) xfrm_user(E) iptable
_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) iptable_filter(E) ip_tables(E) xt_conntrack(E) x_tables(E)
nf_nat(E) nf_conntrack(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) af_packet(E) rpcrdma(E) ib_isert(E) iscsi_target_mod(E) ib_iser(E) libiscsi(E) ib_srpt(E) target_core_mod(E) ib_srp(E) ib_ipoib(E) rdma_ucm(E) ib_ucm(E) ib_uverbs(E) ib_umad(E) bochs_drm(E) tt m(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm(E) agpgart(E) virtio_rng(E) virtio_console(E) rtc_ generic(E) dm_ec(OEN) ttln_rdma(OEN) rdma_cm(E) configfs(E) iw_cm(E) ib_cm(E) rdma_rxe(E) ip6_udp_tunnel(E) udp_tunnel(E) ib_core(E) ql a2xxx(E)
[ 92.499832] scsi_transport_fc(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E) ipmi_watchdog(E) ipmi_ssif(E) ipmi_poweroff(E) ipmi_powernv(EX) ipmi_devintf(E) ipmi_msghandler(E) dummy(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_service_time(E) scsi_transport_iscsi(E) sd_mod(E) sr_mod(E) cdrom(E) hid_generic(E) usbhid(E) virtio_blk(E) virtio_scsi(E) virtio_net(E) ibmvscsi(EX) scsi_transport_srp(E) xhci_pci(E) xhci_hcd(E) usbcore(E) usb_common(E) virtio_pci(E) virtio_ring(E) virtio(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[ 92.499834] Supported: No, Unsupported modules are loaded
[ 92.499839] CPU: 3 PID: 5576 Comm: sh Tainted: G OE NX 4.4.120-ttln.17-default #1
[ 92.499841] task: c0000000afe8a490 ti: c0000000beba8000 task.ti: c0000000beba8000
[ 92.499842] NIP: c00000000008ba3c LR: c000000000027644 CTR: c00000000008ba10
[ 92.499844] REGS: c0000000bebab750 TRAP: 0300 Tainted: G OE NX (4.4.120-ttln.17-default)
[ 92.499850] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28424428 XER: 20000000
[ 92.499871] CFAR: 0000000000002424 DAR: 0000000000000208 DSISR: 40000000 SOFTE: 1
GPR00: c000000000027644 c0000000bebab9d0 c000000000f09700 0000000000000000
GPR04: d0000000043d7192 0000000000000002 000000000000001a fffffffffffffffe
GPR08: 000000000000009c c00000000008ba10 d0000000043e5848 d0000000043d3828
GPR12: c00000000008ba10 c000000007a02400 0000000010062e38 0000010020388860
GPR16: 0000000000000000 0000000000000000 00000100203885f0 00000000100f6c98
GPR20: c0000000b3f1fcc0 c0000000b3f1fc48 c0000000b3f1fbd0 c0000000b3f1fb58
GPR24: c0000000b3f1fae0 c0000000b3f1fa68 00000000000005dc c0000000b3f1f9f0
GPR28: d0000000043e5848 c0000000b3f1f900 c0000000b3f1f320 c0000000b3f1f000
[ 92.499881] NIP [c00000000008ba3c] dma_get_required_mask_pSeriesLP+0x2c/0x1a0
[ 92.499885] LR [c000000000027644] dma_get_required_mask+0x44/0xac
[ 92.499886] Call Trace:
[ 92.499891] [c0000000bebab9d0] [c0000000bebaba30] 0xc0000000bebaba30 (unreliable)
[ 92.499894] [c0000000bebaba10] [c000000000027644] dma_get_required_mask+0x44/0xac
[ 92.499904] [c0000000bebaba30] [d0000000043cb4b4] rxe_register_device+0xc4/0x430 [rdma_rxe]
[ 92.499910] [c0000000bebabab0] [d0000000043c06c8] rxe_add+0x448/0x4e0 [rdma_rxe]
[ 92.499915] [c0000000bebabb30] [d0000000043d28dc] rxe_net_add+0x4c/0xf0 [rdma_rxe]
[ 92.499921] [c0000000bebabb60] [d0000000043d305c] rxe_param_set_add+0x6c/0x1ac [rdma_rxe]
[ 92.499924] [c0000000bebabbf0] [c0000000000e78c0] param_attr_store+0xa0/0x180
[ 92.499927] [c0000000bebabc70] [c0000000000e6448] module_attr_store+0x48/0x70
[ 92.499932] [c0000000bebabc90] [c000000000391f60] sysfs_kf_write+0x70/0xb0
[ 92.499935] [c0000000bebabcb0] [c000000000390f1c] kernfs_fop_write+0x18c/0x1e0
[ 92.499939] [c0000000bebabd00] [c0000000002e22ac] __vfs_write+0x4c/0x1d0
[ 92.499942] [c0000000bebabd90] [c0000000002e2f94] vfs_write+0xc4/0x200
[ 92.499945] [c0000000bebabde0] [c0000000002e488c] SyS_write+0x6c/0x110
[ 92.499948] [c0000000bebabe30] [c000000000009384] system_call+0x38/0xe4
[ 92.499949] Instruction dump:
[ 92.499954] 4e800020 3c4c00e8 3842dcf0 7c0802a6 f8010010 60000000 7c0802a6 fba1ffe8
[ 92.499958] fbc1fff0 fbe1fff8 f8010010 f821ffc1 <e9230208> 7c7e1b78 2fa90000 419e0078
[ 92.499962] ---[ end trace bed077e15eb420cf ]---It fails in dma_get_required_mask, that has ppc-specific implementation, and fail if provided device argument is NULL
--- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/sw/rxe/rxe_verbs.c +1 -1
@@ -1206,7 +1206,7 @@ int rxe_register_device(struct rxe_dev * rxe->ndev->dev_addr); dev->dev.dma_ops = &dma_virt_ops;dma_coerce_mask_and_coherent (&dev->dev, -dma_get_required_mask (dev->dev.parent)); +dma_get_required_mask (&dev->dev)); dev->uverbs_abi_ver =RXE_UVERBS_ABI_VERSION ; dev->uverbs_cmd_mask =BIT_ULL (IB_USER_VERBS_CMD_GET_CONTEXT )
Greg Kroah-Hartman
maintainerPATCH 342/496 ocfs2/dlm: dont handle migrate lockres if already in shutdown
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jun Piao <[email protected]>
[ Upstream commit bb34f24c7d2c98d0c81838a7700e6068325b17a0 ]
We should not handle migrate lockres if we are already in 'DLM_CTXT_IN_SHUTDOWN', as that will cause lockres remains after leaving dlm domain. At last other nodes will get stuck into infinite loop when requsting lock from us.
The problem is caused by concurrency umount between nodes. Before receiveing N1's DLM_BEGIN_EXIT_DOMAIN_MSG, N2 has picked up N1 as the migrate target. So N2 will continue sending lockres to N1 even though N1 has left domain.
N1 N2 (owner)
touch file
access the file,
and get pr lock
begin leave domain and pick up N1 as new owner
begin leave domain and
migrate all lockres done
begin migrate lockres to N1
end leave domain, but
the lockres left
unexpectedly, because
migrate task has passed
--- fs/ocfs2/dlm/dlmdomain.c | 14 -------------- fs/ocfs2/dlm/dlmdomain.h | 25 ++++++++++++++++++++++++- fs/ocfs2/dlm/dlmrecovery.c | 9 +++++++++ 3 files changed, 33 insertions(+), 15 deletions(-)
fs/ocfs2/dlm/dlmdomain.c +0 -14
@@ -676,20 +676,6 @@ static void dlm_leave_domain(struct dlm_spin_unlock (&dlm->spinlock); } -int dlm_shutting_down (struct dlm_ctxt *dlm) -{ -int ret =0 ; - -spin_lock (&dlm_domain_lock); - -if (dlm->dlm_state ==DLM_CTXT_IN_SHUTDOWN ) - ret =1 ; - -spin_unlock (&dlm_domain_lock); - -return ret; -} -void dlm_unregister_domain (struct dlm_ctxt *dlm) {int leave =0 ;
fs/ocfs2/dlm/dlmdomain.h +24 -1
@@ -28,7 +28,30 @@extern spinlock_t dlm_domain_lock;extern struct list_head dlm_domains; -int dlm_shutting_down (struct dlm_ctxt *dlm); +static inline int dlm_joined (struct dlm_ctxt *dlm) +{ +int ret =0 ; + +spin_lock (&dlm_domain_lock); +if (dlm->dlm_state ==DLM_CTXT_JOINED ) + ret =1 ; +spin_unlock (&dlm_domain_lock); + +return ret; +} + +static inline int dlm_shutting_down (struct dlm_ctxt *dlm) +{ +int ret =0 ; + +spin_lock (&dlm_domain_lock); +if (dlm->dlm_state ==DLM_CTXT_IN_SHUTDOWN ) + ret =1 ; +spin_unlock (&dlm_domain_lock); + +return ret; +} +void dlm_fire_domain_eviction_callbacks (struct dlm_ctxt *dlm,int node_num);
fs/ocfs2/dlm/dlmrecovery.c +9 -0
@@ -1378,6 +1378,15 @@ int dlm_mig_lockres_handler(struct o2netif (!dlm_grab (dlm))return -EINVAL ; +if (!dlm_joined (dlm)) { +mlog (ML_ERROR ,"Domain %s not joined! " +"lockres %.*s, master %u\n" , + dlm->name, mres->lockname_len, + mres->lockname, mres->master); +dlm_put (dlm); +return -EINVAL ; + } +BUG_ON (!(mres->flags & (DLM_MRES_RECOVERY |DLM_MRES_MIGRATION ))); real_master = mres->master;
Greg Kroah-Hartman
maintainerPATCH 343/496 powerpc/64s/idle: Fix restore of AMOR on POWER9 after deep sleep
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit c1b25a17d24925b0961c319cfc3fd7e1dc778914 ]
POWER8 restores AMOR when waking from deep sleep, but POWER9 does not, because it does not go through the subcore restore.
Have POWER9 restore it in core restore.
--- arch/powerpc/kernel/idle_book3s.S | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/kernel/idle_book3s.S +2 -0
@@ -838,6 +838,8 @@ BEGIN_FTR_SECTION mtspr SPRN_PTCR,r4 ld r4,_RPR(r1) mtspr SPRN_RPR,r4 + ld r4,_AMOR(r1) + mtspr SPRN_AMOR,r4 END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300) ld r4,_TSCR(r1)
Greg Kroah-Hartman
maintainerPATCH 344/496 sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davidlohr Bueso <[email protected]>
[ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]
While running rt-tests' pi_stress program I got the following splat:
rq->clock_update_flags < RQCF_ACT_SKIP
WARNING: CPU: 27 PID: 0 at kernel/sched/sched.h:960 assert_clock_updated.isra.38.part.39+0x13/0x20
[...]
<IRQ> enqueue_top_rt_rq+0xf4/0x150 ? cpufreq_dbs_governor_start+0x170/0x170 sched_rt_rq_enqueue+0x65/0x80 sched_rt_period_timer+0x156/0x360 ? sched_rt_rq_enqueue+0x80/0x80 __hrtimer_run_queues+0xfa/0x260 hrtimer_interrupt+0xcb/0x220 smp_apic_timer_interrupt+0x62/0x120 apic_timer_interrupt+0xf/0x20 </IRQ>
[...]
do_idle+0x183/0x1e0 cpu_startup_entry+0x5f/0x70 start_secondary+0x192/0x1d0 secondary_startup_64+0xa5/0xb0
We can get rid of it be the "traditional" means of adding an update_rq_clock() call after acquiring the rq->lock in do_sched_rt_period_timer().
The case for the RT task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted).
By setting RQCF_UPDATED we really don't care if the skip is happening or not and will therefore make the assert_clock_updated() check happy.
--- kernel/sched/rt.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/sched/rt.c +2 -0
@@ -843,6 +843,8 @@ static int do_sched_rt_period_timer(strucontinue ;raw_spin_lock (&rq->lock); +update_rq_clock (rq); +if (rt_rq->rt_time) {u64 runtime;
Greg Kroah-Hartman
maintainerPATCH 345/496 x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sai Praneeth <[email protected]>
[ Upstream commit 162ee5a8ab49be40d253f90e94aef712470a3a24 ]
Linus reported the following boot warning:
WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/tlbflush.h:134 load_new_mm_cr3+0x114/0x170 [...] Call Trace: switch_mm_irqs_off+0x267/0x590 switch_mm+0xe/0x20 efi_switch_mm+0x3e/0x50 efi_enter_virtual_mode+0x43f/0x4da start_kernel+0x3bf/0x458 secondary_startup_64+0xa5/0xb0
... after merging:
03781e40890c: x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3
When the platform supports PCID and if CONFIG_DEBUG_VM=y is enabled, build_cr3_noflush() (called via switch_mm()) does a sanity check to see if X86_FEATURE_PCID is set.
Presently, build_cr3_noflush() uses "this_cpu_has(X86_FEATURE_PCID)" to perform the check but this_cpu_has() works only after SMP is initialized (i.e. per cpu cpu_info's should be populated) and this happens to be very late in the boot process (during rest_init()).
As efi_runtime_services() are called during (early) kernel boot time and run time, modify build_cr3_noflush() to use boot_cpu_has() all the time. As suggested by Dave Hansen, this should be OK because all CPU's have same capabilities on x86.
With this change the warning is fixed.
( Dave also suggested that we put a warning in this_cpu_has() if it's used
early in the boot process. This is still work in progress as it affects MCE. )
--- arch/x86/include/asm/tlbflush.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/x86/include/asm/tlbflush.h +6 -1
@@ -131,7 +131,12 @@ static inline unsigned long build_cr3(pgstatic inline unsigned long build_cr3_noflush (pgd_t *pgd,u16 asid) {VM_WARN_ON_ONCE (asid >MAX_ASID_AVAILABLE ); -VM_WARN_ON_ONCE (!this_cpu_has (X86_FEATURE_PCID )); +/* +* Use boot_cpu_has() instead of this_cpu_has() as this function +* might be called during early boot. This should work even after +* boot because all CPU's the have same capabilities: +*/ +VM_WARN_ON_ONCE (!boot_cpu_has (X86_FEATURE_PCID ));return __sme_pa (pgd) |kern_pcid (asid) |CR3_NOFLUSH ; }
Greg Kroah-Hartman
maintainerPATCH 347/496 lan78xx: Connect phy early
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Graf <[email protected]>
[ Upstream commit 92571a1aae40d291158d16e7142637908220f470 ]
When using wicked with a lan78xx device attached to the system, we end up with ethtool commands issued on the device before an ifup got issued. That lead to the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000039c
pgd = ffff800035b30000
[0000039c] *pgd=0000000000000000
Internal error: Oops: 96000004 [#1] SMP
Modules linked in: [...]
Supported: Yes
CPU: 3 PID: 638 Comm: wickedd Tainted: G E 4.12.14-0-default #1
Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018
task: ffff800035e74180 task.stack: ffff800036718000
PC is at phy_ethtool_ksettings_get+0x20/0x98
LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
pc : [<ffff0000086f7f30>] lr : [<ffff000000dcca84>] pstate: 20000005
sp : ffff80003671bb20
x29: ffff80003671bb20 x28: ffff800035e74180
x27: ffff000008912000 x26: 000000000000001d
x25: 0000000000000124 x24: ffff000008f74d00
x23: 0000004000114809 x22: 0000000000000000
x21: ffff80003671bbd0 x20: 0000000000000000
x19: ffff80003671bbd0 x18: 000000000000040d
x17: 0000000000000001 x16: 0000000000000000
x15: 0000000000000000 x14: ffffffffffffffff
x13: 0000000000000000 x12: 0000000000000020
x11: 0101010101010101 x10: fefefefefefefeff
x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364
x7 : 0000000080808080 x6 : ffff80003671bc9c
x5 : ffff80003671b9f8 x4 : ffff80002c296190
x3 : 0000000000000000 x2 : 0000000000000000
x1 : ffff80003671bbd0 x0 : ffff80003671bc00
Process wickedd (pid: 638, stack limit = 0xffff800036718000)
Call trace:
Exception stack(0xffff80003671b9e0 to 0xffff80003671bb20)
b9e0: ffff80003671bc00 ffff80003671bbd0 0000000000000000 0000000000000000
ba00: ffff80002c296190 ffff80003671b9f8 ffff80003671bc9c 0000000080808080
ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101
ba40: 0000000000000020 0000000000000000 ffffffffffffffff 0000000000000000
ba60: 0000000000000000 0000000000000001 000000000000040d ffff80003671bbd0
ba80: 0000000000000000 ffff80003671bbd0 0000000000000000 0000004000114809
baa0: ffff000008f74d00 0000000000000124 000000000000001d ffff000008912000
bac0: ffff800035e74180 ffff80003671bb20 ffff000000dcca84 ffff80003671bb20
bae0: ffff0000086f7f30 0000000020000005 ffff80002c296000 ffff800035223900
bb00: 0000ffffffffffff 0000000000000000 ffff80003671bb20 ffff0000086f7f30
[<ffff0000086f7f30>] phy_ethtool_ksettings_get+0x20/0x98
[<ffff000000dcca84>] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
[<ffff0000087cbc40>] ethtool_get_settings+0x68/0x210
[<ffff0000087cc0d4>] dev_ethtool+0x214/0x2180
[<ffff0000087e5008>] dev_ioctl+0x400/0x630
[<ffff00000879dd00>] sock_do_ioctl+0x70/0x88
[<ffff00000879f5f8>] sock_ioctl+0x208/0x368
[<ffff0000082cde10>] do_vfs_ioctl+0xb0/0x848
[<ffff0000082ce634>] SyS_ioctl+0x8c/0xa8
Exception stack(0xffff80003671bec0 to 0xffff80003671c000)
bec0: 0000000000000009 0000000000008946 0000fffff4e841d0 0000aa0032687465
bee0: 0000aaaafa2319d4 0000fffff4e841d4 0000000032687465 0000000032687465
bf00: 000000000000001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f
bf20: 0101010101010101 0000000000000020 ffffffffffffffff 0000ffff7f510c68
bf40: 0000ffff7f6a9d18 0000ffff7f44ce30 000000000000040d 0000ffff7f6f98f0
bf60: 0000fffff4e842c0 0000000000000001 0000aaaafa2c2e00 0000ffff7f6ab000
bf80: 0000fffff4e842c0 0000ffff7f62a000 0000aaaafa2b9f20 0000aaaafa2c2e00
bfa0: 0000fffff4e84818 0000fffff4e841a0 0000ffff7f5ad0cc 0000fffff4e841a0
bfc0: 0000ffff7f44ce3c 0000000080000000 0000000000000009 000000000000001d
bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000The culprit is quite simple: The driver tries to access the phy left and right, but only actually has a working reference to it when the device is up.
The fix thus is quite simple too: Get a reference to the phy on probe already and keep it even when the device is going down.
With this patch applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between.
--- drivers/net/usb/lan78xx.c | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-)
drivers/net/usb/lan78xx.c +18 -16
@@ -2083,10 +2083,6 @@ static int lan78xx_phy_init(struct lan78 dev->fc_autoneg = phydev->autoneg; -phy_start (phydev); - -netif_dbg (dev, ifup, dev->net,"phy initialised successfully" ); -return 0 ; error:
@@ -2523,9 +2519,9 @@ static int lan78xx_open(struct net_devicif (ret <0 ) goto done; - ret =lan78xx_phy_init (dev); -if (ret <0 ) - goto done; +phy_start (net->phydev); + +netif_dbg (dev, ifup, dev->net,"phy initialised successfully" );/* for Link Check */ if (dev->urb_intr) {
@@ -2586,13 +2582,8 @@ static int lan78xx_stop(struct net_devicif (timer_pending (&dev->stat_monitor))del_timer_sync (&dev->stat_monitor); -phy_unregister_fixup_for_uid (PHY_KSZ9031RNX ,0xfffffff0 ); -phy_unregister_fixup_for_uid (PHY_LAN8835 ,0xfffffff0 ); - -phy_stop (net->phydev); -phy_disconnect (net->phydev); - - net->phydev =NULL ; +if (net->phydev) +phy_stop (net->phydev);clear_bit (EVENT_DEV_OPEN , &dev->flags);netif_stop_queue (net);
@@ -3507,8 +3498,13 @@ static void lan78xx_disconnect(struct usreturn ; udev =interface_to_usbdev (intf); - net = dev->net; + +phy_unregister_fixup_for_uid (PHY_KSZ9031RNX ,0xfffffff0 ); +phy_unregister_fixup_for_uid (PHY_LAN8835 ,0xfffffff0 ); + +phy_disconnect (net->phydev); +unregister_netdev (net);cancel_delayed_work_sync (&dev->wq);
@@ -3668,8 +3664,14 @@ static int lan78xx_probe(struct usb_intepm_runtime_set_autosuspend_delay (&udev->dev,DEFAULT_AUTOSUSPEND_DELAY ); + ret =lan78xx_phy_init (dev); +if (ret <0 ) + goto out4; +return 0 ; +out4: +unregister_netdev (netdev); out3:lan78xx_unbind (dev, intf); out2:
@@ -4017,7 +4019,7 @@ static int lan78xx_reset_resume(struct ulan78xx_reset (dev); -lan78xx_phy_init (dev); +phy_start (dev->net->phydev);return lan78xx_resume (intf); }
Greg Kroah-Hartman
maintainerPATCH 348/496 fscache: Fix hanging wait on page discarded by writeback
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 2c98425720233ae3e135add0c7e869b32913502f ]
If the fscache asynchronous write operation elects to discard a page that's pending storage to the cache because the page would be over the store limit then it needs to wake the page as someone may be waiting on completion of the write.
The problem is that the store limit may be updated by a different asynchronous operation - and so may miss the write - and that the store limit may not even get updated until later by the netfs.
Fix the kernel hang by making fscache_write_op() mark as written any pages that are over the limit.
--- fs/fscache/page.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
fs/fscache/page.c +9 -4
@@ -776,6 +776,7 @@ static void fscache_write_op(struct fsca_enter ("{OP%x,%d}" , op->op.debug_id,atomic_read (&op->op.usage)); +again:spin_lock (&object->lock); cookie = object->cookie;
@@ -816,10 +817,6 @@ static void fscache_write_op(struct fsca goto superseded; page = results[0 ];_debug ("gang %d [%lx]" , n, page->index); -if (page->index >= op->store_limit) { -fscache_stat (&fscache_n_store_pages_over_limit); - goto superseded; - }radix_tree_tag_set (&cookie->stores, page->index,FSCACHE_COOKIE_STORING_TAG );
@@ -829,6 +826,9 @@ static void fscache_write_op(struct fscaspin_unlock (&cookie->stores_lock);spin_unlock (&object->lock); +if (page->index >= op->store_limit) + goto discard_page; +fscache_stat (&fscache_n_store_pages);fscache_stat (&fscache_n_cop_write_page); ret = object->cache->ops->write_page (op, page);
@@ -844,6 +844,11 @@ static void fscache_write_op(struct fsca_leave ("" );return ; +discard_page: +fscache_stat (&fscache_n_store_pages_over_limit); +fscache_end_page_write (object, page); + goto again; + superseded:/* this writer is going away and there aren't any more things to * write */
Greg Kroah-Hartman
maintainerPATCH 350/496 net: bgmac: Fix endian access in bgmac_dma_tx_ring_free()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit 60d6e6f0b9e422dd01aeda39257ee0428e5e2a3f ]
bgmac_dma_tx_ring_free() assigns the ctl1 word which is a litle endian 32-bit word without using proper accessors, fix this, and because a length cannot be negative, use unsigned int while at it.
--- drivers/net/ethernet/broadcom/bgmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bgmac.c +2 -1
@@ -532,7 +532,8 @@ static void bgmac_dma_tx_ring_free(strucint i;for (i =0 ; i <BGMAC_TX_RING_SLOTS ; i++) { -int len = dma_desc[i].ctl1 &BGMAC_DESC_CTL1_LEN ; +u32 ctl1 =le32_to_cpu (dma_desc[i].ctl1); +unsigned int len = ctl1 &BGMAC_DESC_CTL1_LEN ; slot = &ring->slots[i];dev_kfree_skb (slot->skb);
Greg Kroah-Hartman
maintainerPATCH 351/496 net: bgmac: Correctly annotate register space
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit 16a1c0646e55c3345bce8e4edfc06ad119d27c04 ]
All the members: base, idm_base and nicpm_base should be annotated with __iomem since they are pointers to register space. This fixes a bunch of sparse reported warnings.
--- drivers/net/ethernet/broadcom/bgmac.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/broadcom/bgmac.h +3 -3
@@ -479,9 +479,9 @@ struct bgmac_rx_header { struct bgmac { union { struct { - void *base; - void *idm_base; - void *nicpm_base; + void __iomem *base; + void __iomem *idm_base; + void __iomem *nicpm_base; } plat; struct { struct bcma_device *core;
Greg Kroah-Hartman
maintainerPATCH 352/496 powerpc/64s: sreset panic if there is no debugger or crash dump handlers
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit d40b6768e45bd9213139b2d91d30c7692b6007b1 ]
system_reset_exception does most of its own crash handling now, invoking the debugger or crash dumps if they are registered. If not, then it goes through to die() to print stack traces, and then is supposed to panic (according to comments).
However after die() prints oopses, it does its own handling which doesn't allow system_reset_exception to panic (e.g., it may just kill the current process). This patch causes sreset exceptions to return from die after it prints messages but before acting.
This also stops die from invoking the debugger on 0x100 crashes. system_reset_exception similarly calls the debugger. It had been thought this was harmless (because if the debugger was disabled, neither call would fire, and if it was enabled the first call would return). However in some cases like xmon 'X' command, the debugger returns 0, which currently causes it to be entered again (first in system_reset_exception, then in die), which is confusing.
--- arch/powerpc/kernel/traps.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
arch/powerpc/kernel/traps.c +13 -2
@@ -182,6 +182,12 @@ static void oops_end(unsigned long flags }raw_local_irq_restore (flags); +/* +* system_reset_excption handles debugger, crash dump, panic, for 0x100 +*/ +if (TRAP (regs) ==0x100 ) +return ; +crash_fadump (regs,"die oops" );if (kexec_should_crash (current))
@@ -246,8 +252,13 @@ void die(const char *str, struct pt_regs {unsigned long flags; -if (debugger (regs)) -return ; +/* +* system_reset_excption handles debugger, crash dump, panic, for 0x100 +*/ +if (TRAP (regs) !=0x100 ) { +if (debugger (regs)) +return ; + } flags =oops_begin (regs);if (__die (str, regs, err))
Greg Kroah-Hartman
maintainerPATCH 353/496 btrfs: tests/qgroup: Fix wrong tree backref level
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
[ Upstream commit 3c0efdf03b2d127f0e40e30db4e7aa0429b1b79a ]
The extent tree of the test fs is like the following:
BTRFS info (device (null)): leaf 16327509003777336587 total ptrs 1 free space 3919
item 0 key (4096 168 4096) itemoff 3944 itemsize 51
extent refs 1 gen 1 flags 2
tree block key (68719476736 0 0) level 1
^^^^^^^
ref#0: tree block backref root 5
And it's using an empty tree for fs tree, so there is no way that its level can be 1.
For REAL (created by mkfs) fs tree backref with no skinny metadata, the result should look like:
item 3 key (30408704 EXTENT_ITEM 4096) itemoff 3845 itemsize 51
refs 1 gen 4 flags TREE_BLOCK
tree block key (256 INODE_ITEM 0) level 0
^^^^^^^
tree block backref root 5
Fix the level to 0, so it won't break later tree level checker.
--- fs/btrfs/tests/qgroup-tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/tests/qgroup-tests.c +1 -1
@@ -63,7 +63,7 @@ static int insert_normal_tree_ref(structbtrfs_set_extent_generation (leaf, item,1 );btrfs_set_extent_flags (leaf, item,BTRFS_EXTENT_FLAG_TREE_BLOCK ); block_info = (struct btrfs_tree_block_info *)(item +1 ); -btrfs_set_tree_block_level (leaf, block_info,1 ); +btrfs_set_tree_block_level (leaf, block_info,0 ); iref = (struct btrfs_extent_inline_ref *)(block_info +1 );if (parent >0 ) { btrfs_set_extent_inline_ref_type(leaf, iref,
Greg Kroah-Hartman
maintainerPATCH 354/496 Btrfs: fix copy_items() return value when logging an inode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit 8434ec46c6e3232cebc25a910363b29f5c617820 ]
When logging an inode, at tree-log.c:copy_items(), if we call btrfs_next_leaf() at the loop which checks for the need to log holes, we need to make sure copy_items() returns the value 1 to its caller and not 0 (on success). This is because the path the caller passed was released and is now different from what is was before, and the caller expects a return value of 0 to mean both success and that the path has not changed, while a return value of 1 means both success and signals the caller that it can not reuse the path, it has to perform another tree search.
Even though this is a case that should not be triggered on normal circumstances or very rare at least, its consequences can be very unpredictable (especially when replaying a log tree).
--- fs/btrfs/tree-log.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/tree-log.c +1 -0
@@ -3918,6 +3918,7 @@ fill_holes:ASSERT (ret ==0 ); src = src_path->nodes[0 ]; i =0 ; + need_find_last_extent = true; }btrfs_item_key_to_cpu (src, &key, i);
Greg Kroah-Hartman
maintainerPATCH 355/496 btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Mahoney <[email protected]>
[ Upstream commit 8a5a916d9a35e13576d79cc16e24611821b13e34 ]
While running btrfs/011, I hit the following lockdep splat.
This is the important bit:
pcpu_alloc+0x1ac/0x5e0 __percpu_counter_init+0x4e/0xb0 btrfs_init_fs_root+0x99/0x1c0 [btrfs] btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs] resolve_indirect_refs+0x130/0x830 [btrfs] find_parent_nodes+0x69e/0xff0 [btrfs] btrfs_find_all_roots_safe+0xa0/0x110 [btrfs] btrfs_find_all_roots+0x50/0x70 [btrfs] btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs] btrfs_commit_transaction+0x3ce/0x9b0 [btrfs]
The percpu_counter_init call in btrfs_alloc_subvolume_writers uses GFP_KERNEL, which we can't do during transaction commit.
This switches it to GFP_NOFS.
========================================================
WARNING: possible irq lock inversion dependency detected
4.12.14-kvmsmall #8 Tainted: G W
--------------------------------------------------------
kswapd0/50 just changed the state of lock:
(&delayed_node->mutex){+.+.-.}, at: [<ffffffffc06994fa>] __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
but this lock took another, RECLAIM_FS-unsafe lock in the past:
(pcpu_alloc_mutex){+.+.+.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Chain exists of: &delayed_node->mutex --> &found->groups_sem --> pcpu_alloc_mutex
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcpu_alloc_mutex);
local_irq_disable();
lock(&delayed_node->mutex);
lock(&found->groups_sem);
<Interrupt>
lock(&delayed_node->mutex);*** DEADLOCK ***
2 locks held by kswapd0/50:
#0: (shrinker_rwsem){++++..}, at: [<ffffffff811dc11f>] shrink_slab+0x7f/0x5b0 #1: (&type->s_umount_key#30){+++++.}, at: [<ffffffff8126dec6>] trylock_super+0x16/0x50
the shortest dependencies between 2nd lock and 1st lock:
-> (pcpu_alloc_mutex){+.+.+.} ops: 4904 {
HARDIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
kmem_cache_init_late+0x42/0x75
start_kernel+0x343/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
SOFTIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
kmem_cache_init_late+0x42/0x75
start_kernel+0x343/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
RECLAIM_FS-ON-W at:
__kmalloc+0x47/0x310
pcpu_extend_area_map+0x2b/0xc0
pcpu_alloc+0x3ec/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
__kmem_cache_create+0x1bf/0x390
create_cache+0xba/0x1b0
kmem_cache_create+0x1f8/0x2b0
ksm_init+0x6f/0x19d
do_one_initcall+0x50/0x1b0
kernel_init_freeable+0x201/0x289
kernel_init+0xa/0x100
ret_from_fork+0x3a/0x50
INITIAL USE at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
setup_cpu_cache+0x2f/0x1f0
__kmem_cache_create+0x1bf/0x390
create_boot_cache+0x8b/0xb1
kmem_cache_init+0xa1/0x19e
start_kernel+0x270/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
}
... key at: [<ffffffff821d8e70>] pcpu_alloc_mutex+0x70/0xa0
... acquired at:
pcpu_alloc+0x1ac/0x5e0
__percpu_counter_init+0x4e/0xb0
btrfs_init_fs_root+0x99/0x1c0 [btrfs]
btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs]
resolve_indirect_refs+0x130/0x830 [btrfs]
find_parent_nodes+0x69e/0xff0 [btrfs]
btrfs_find_all_roots_safe+0xa0/0x110 [btrfs]
btrfs_find_all_roots+0x50/0x70 [btrfs]
btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs]
btrfs_commit_transaction+0x3ce/0x9b0 [btrfs]
transaction_kthread+0x176/0x1b0 [btrfs]
kthread+0x102/0x140
ret_from_fork+0x3a/0x50 -> (&fs_info->commit_root_sem){++++..} ops: 1566382 {
HARDIRQ-ON-W at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
HARDIRQ-ON-R at:
down_read+0x35/0x90
caching_thread+0x57/0x560 [btrfs]
normal_work_helper+0x1c0/0x5e0 [btrfs]
process_one_work+0x1e0/0x5c0
worker_thread+0x44/0x390
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
SOFTIRQ-ON-W at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-R at:
down_read+0x35/0x90
caching_thread+0x57/0x560 [btrfs]
normal_work_helper+0x1c0/0x5e0 [btrfs]
process_one_work+0x1e0/0x5c0
worker_thread+0x44/0x390
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
INITIAL USE at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc0729578>] __key.61970+0x0/0xfffffffffff9aa88 [btrfs]
... acquired at:
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs]
btrfs_create_tree+0xbb/0x2a0 [btrfs]
btrfs_create_uuid_tree+0x37/0x140 [btrfs]
open_ctree+0x23c0/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> (&found->groups_sem){++++..} ops: 2134587 {
HARDIRQ-ON-W at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
HARDIRQ-ON-R at:
down_read+0x35/0x90
btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs]
open_ctree+0x207b/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-W at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-R at:
down_read+0x35/0x90
btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs]
open_ctree+0x207b/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
INITIAL USE at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc0729488>] __key.59101+0x0/0xfffffffffff9ab78 [btrfs]
... acquired at:
find_free_extent+0xcb4/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs]
__btrfs_cow_block+0x110/0x5b0 [btrfs]
btrfs_cow_block+0xd7/0x290 [btrfs]
btrfs_search_slot+0x1f6/0x960 [btrfs]
btrfs_lookup_inode+0x2a/0x90 [btrfs]
__btrfs_update_delayed_inode+0x65/0x210 [btrfs]
btrfs_commit_inode_delayed_inode+0x121/0x130 [btrfs]
btrfs_evict_inode+0x3fe/0x6a0 [btrfs]
evict+0xc4/0x190
__dentry_kill+0xbf/0x170
dput+0x2ae/0x2f0
SyS_rename+0x2a6/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7-> (&delayed_node->mutex){+.+.-.} ops: 5580204 {
HARDIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
IN-RECLAIM_FS-W at:
__mutex_lock+0x4e/0x8c0
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
INITIAL USE at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc072d488>] __key.56935+0x0/0xfffffffffff96b78 [btrfs]
... acquired at:
__lock_acquire+0x264/0x11c0
lock_acquire+0xbd/0x1e0
__mutex_lock+0x4e/0x8c0
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
stack backtrace:
CPU: 1 PID: 50 Comm: kswapd0 Tainted: G W 4.12.14-kvmsmall #8 SLE15 (unreleased)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x78/0xb7
print_irq_inversion_bug.part.38+0x19f/0x1aa
check_usage_forwards+0x102/0x120
? ret_from_fork+0x3a/0x50
? check_usage_backwards+0x110/0x110
mark_lock+0x16c/0x270
__lock_acquire+0x264/0x11c0
? pagevec_lookup_entries+0x1a/0x30
? truncate_inode_pages_range+0x2b3/0x7f0
lock_acquire+0xbd/0x1e0
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
__mutex_lock+0x4e/0x8c0
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
? btrfs_evict_inode+0x1f6/0x6a0 [btrfs]
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
? mem_cgroup_shrink_node+0x2c0/0x2c0
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x3a/0x50--- fs/btrfs/disk-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/disk-io.c +1 -1
@@ -1276,7 +1276,7 @@ static struct btrfs_subvolume_writers *bif (!writers)return ERR_PTR (-ENOMEM ); - ret =percpu_counter_init (&writers->counter,0 ,GFP_KERNEL ); + ret =percpu_counter_init (&writers->counter,0 ,GFP_NOFS );if (ret <0 ) {kfree (writers);return ERR_PTR (ret);
Greg Kroah-Hartman
maintainerPATCH 356/496 btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
[ Upstream commit 4d31778aa2fa342f5f92ca4025b293a1729161d1 ]
When multiple pending snapshots referring to the same source subvolume are executed, enabled quota will cause root item corruption, where root items are using old bytenr (no backref in extent tree).
This can be triggered by fstests btrfs/152.
The cause is when source subvolume is still dirty, extra commit (simplied transaction commit) of qgroup_account_snapshot() can skip dirty roots not recorded in current transaction, making root item of source subvolume not updated.
Fix it by forcing recording source subvolume in current transaction before qgroup sub-transaction commit.
--- fs/btrfs/transaction.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/btrfs/transaction.c +9 -1
@@ -319,7 +319,7 @@ static int record_root_in_trans(struct bif ((test_bit (BTRFS_ROOT_REF_COWS , &root->state) && root->last_trans < trans->transid) || force) {WARN_ON (root == fs_info->extent_root); -WARN_ON (root->commit_root != root->node); +WARN_ON (!force && root->commit_root != root->node);/* * see below for IN_TRANS_SETUP usage rules
@@ -1366,6 +1366,14 @@ static int qgroup_account_snapshot(strucreturn 0 ;/* +* Ensure dirty @src will be commited. Or, after comming +* commit_fs_roots() and switch_commit_roots(), any dirty but not +* recorded root will never be updated again, causing an outdated root +* item. +*/ +record_root_in_trans (trans, src,1 ); + +/* * We are going to commit transaction, see btrfs_commit_transaction() * comment for reason locking tree_log_mutex */
Greg Kroah-Hartman
maintainerPATCH 357/496 rxrpc: Fix Tx ring annotation after initial Tx failure
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 03877bf6a30cca7d4bc3ffabd3c3e9464a7a1a19 ]
rxrpc calls have a ring of packets that are awaiting ACK or retransmission and a parallel ring of annotations that tracks the state of those packets. If the initial transmission of a packet on the underlying UDP socket fails then the packet annotation is marked for resend - but the setting of this mark accidentally erases the last-packet mark also stored in the same annotation slot. If this happens, a call won't switch out of the Tx phase when all the packets have been transmitted.
Fix this by retaining the last-packet mark and only altering the packet state.
--- net/rxrpc/sendmsg.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/rxrpc/sendmsg.c +3 -1
@@ -92,7 +92,9 @@ static inline void rxrpc_instant_resend(spin_lock_bh (&call->lock);if (call->state <RXRPC_CALL_COMPLETE ) { - call->rxtx_annotations[ix] =RXRPC_TX_ANNO_RETRANS ; + call->rxtx_annotations[ix] = + (call->rxtx_annotations[ix] &RXRPC_TX_ANNO_LAST ) | +RXRPC_TX_ANNO_RETRANS ;if (!test_and_set_bit (RXRPC_CALL_EV_RESEND , &call->events))rxrpc_queue_call (call); }
Greg Kroah-Hartman
maintainerPATCH 358/496 rxrpc: Dont treat call aborts as conn aborts
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 57b0c9d49b94bbeb53649b7fbd264603c1ebd585 ]
If a call-level abort is received for the previous call to complete on a connection channel, then that abort is queued for the connection processor to handle. Unfortunately, the connection processor then assumes without checking that the abort is connection-level (ie. callNumber is 0) and distributes it over all active calls on that connection, thereby incorrectly aborting them.
Fix this by discarding aborts aimed at a completed call.
Further, discard all packets aimed at a call that's complete if there's currently an active call on a channel, since the DATA packets associated with the new call automatically terminate the old call.
--- net/rxrpc/input.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
net/rxrpc/input.c +9 -6
@@ -1175,16 +1175,19 @@ void rxrpc_data_ready(struct sock *udp_s goto discard_unlock;if (sp->hdr.callNumber == chan->last_call) { -/* For the previous service call, if completed successfully, we -* discard all further packets. +if (chan->call || + sp->hdr.type ==RXRPC_PACKET_TYPE_ABORT ) + goto discard_unlock; + +/* For the previous service call, if completed +* successfully, we discard all further packets. */ if (rxrpc_conn_is_service (conn) && - (chan->last_type ==RXRPC_PACKET_TYPE_ACK || - sp->hdr.type ==RXRPC_PACKET_TYPE_ABORT )) + chan->last_type ==RXRPC_PACKET_TYPE_ACK ) goto discard_unlock; -/* But otherwise we need to retransmit the final packet from -* data cached in the connection record. +/* But otherwise we need to retransmit the final packet +* from data cached in the connection record. */ rxrpc_post_packet_to_conn (conn, skb); goto out_unlock;
Greg Kroah-Hartman
maintainerPATCH 359/496 xen/acpi: off by one in read_acpi_id()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit c37a3c94775855567b90f91775b9691e10bd2806 ]
If acpi_id is == nr_acpi_bits, then we access one element beyond the end of the acpi_psd[] array or we set one bit beyond the end of the bit map when we do __set_bit(acpi_id, acpi_id_present);
--- drivers/xen/xen-acpi-processor.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/xen/xen-acpi-processor.c +3 -3
@@ -362,9 +362,9 @@ read_acpi_id(acpi_handle handle, u32 lvl }/* There are more ACPI Processor objects than in x2APIC or MADT. * This can happen with incorrect ACPI SSDT declerations. */ -if (acpi_id > nr_acpi_bits) { -pr_debug ("We only have %u, trying to set %u\n" , - nr_acpi_bits, acpi_id); +if (acpi_id >= nr_acpi_bits) { +pr_debug ("max acpi id %u, trying to set %u\n" , + nr_acpi_bits -1 , acpi_id);return AE_OK ; }/* OK, There is a ACPI Processor object */
Greg Kroah-Hartman
maintainerPATCH 360/496 drivers: macintosh: rack-meter: really fix bogus memsets
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaro Koskinen <[email protected]>
[ Upstream commit e283655b5abe26462d53d5196f186c5e8863af3b ]
We should zero an array using sizeof instead of number of elements.
Fixes the following compiler (GCC 7.3.0) warnings:
drivers/macintosh/rack-meter.c: In function 'rackmeter_do_pause':drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] drivers/macintosh/rack-meter.c:158:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
--- drivers/macintosh/rack-meter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/macintosh/rack-meter.c +2 -2
@@ -154,8 +154,8 @@ static void rackmeter_do_pause(struct raDBDMA_DO_STOP (rm->dma_regs);return ; } -memset (rdma->buf1,0 ,ARRAY_SIZE (rdma->buf1)); -memset (rdma->buf2,0 ,ARRAY_SIZE (rdma->buf2)); +memset (rdma->buf1,0 ,sizeof (rdma->buf1)); +memset (rdma->buf2,0 ,sizeof (rdma->buf2)); rm->dma_buf_v->mark =0 ;
Greg Kroah-Hartman
maintainerPATCH 361/496 ACPI: acpi_pad: Fix memory leak in power saving threads
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lenny Szubowicz <[email protected]>
[ Upstream commit 8b29d29abc484d638213dd79a18a95ae7e5bb402 ]
Fix once per second (round_robin_time) memory leak of about 1 KB in each acpi_pad kernel idling thread that is activated.
Found by testing with kmemleak.
--- drivers/acpi/acpi_pad.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/acpi/acpi_pad.c +3 -0
@@ -110,6 +110,7 @@ static void round_robin_cpu(unsigned intcpumask_andnot (tmp, cpu_online_mask, pad_busy_cpus);if (cpumask_empty (tmp)) {mutex_unlock (&round_robin_lock); +free_cpumask_var (tmp);return ; }for_each_cpu (cpu, tmp) {
@@ -127,6 +128,8 @@ static void round_robin_cpu(unsigned intmutex_unlock (&round_robin_lock);set_cpus_allowed_ptr (current,cpumask_of (preferred_cpu)); + +free_cpumask_var (tmp); }static void exit_round_robin (unsigned int tsk_index)
Greg Kroah-Hartman
maintainerPATCH 362/496 powerpc/mpic: Check if cpu_possible() in mpic_physmask()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
[ Upstream commit 0834d627fbea00c1444075eb3e448e1974da452d ]
In mpic_physmask() we loop over all CPUs up to 32, then get the hard SMP processor id of that CPU.
Currently that's possibly walking off the end of the paca array, but in a future patch we will change the paca array to be an array of pointers, and in that case we will get a NULL for missing CPUs and oops. eg:
Unable to handle kernel paging request for data at address 0x88888888888888b8 Faulting instruction address: 0xc00000000004e380 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP .mpic_set_affinity+0x60/0x1a0 LR .irq_do_set_affinity+0x48/0x100
Fix it by checking the CPU is possible, this also fixes the code if there are gaps in the CPU numbering which probably never happens on mpic systems but who knows.
--- arch/powerpc/sysdev/mpic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/sysdev/mpic.c +1 -1
@@ -626,7 +626,7 @@ static inline u32 mpic_physmask(u32 cpumint i;u32 mask =0 ; -for (i =0 ; i <min (32 ,NR_CPUS ); ++i, cpumask >>=1 ) +for (i =0 ; i <min (32 ,NR_CPUS ) &&cpu_possible (i); ++i, cpumask >>=1 ) mask |= (cpumask &1 ) <<get_hard_smp_processor_id (i);return mask; }
Greg Kroah-Hartman
maintainerPATCH 363/496 ieee802154: ca8210: fix uninitialised data read
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harry Morris <[email protected]>
[ Upstream commit 86674a97f5055f4c7f406563408096e8cf9364ff ]
In ca8210_test_int_user_write() a user can request the transfer of a frame with a length field (command.length) that is longer than the actual buffer provided (len). In this scenario the driver will copy the buffer contents into the uninitialised command[] buffer, then transfer <data.length> bytes over the SPI even though only <len> bytes had been populated, potentially leaking sensitive kernel memory.
Also the first 6 bytes of the command buffer must be initialised in case a malformed, short packet is written and the uninitialised bytes are read in ca8210_test_check_upstream.
--- drivers/net/ieee802154/ca8210.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/net/ieee802154/ca8210.c +11 -3
@@ -2493,13 +2493,14 @@ static ssize_t ca8210_test_int_user_writstruct ca8210_priv *priv = filp->private_data;u8 command[CA8210_SPI_BUF_SIZE ]; -if (len >CA8210_SPI_BUF_SIZE ) { +memset (command,SPI_IDLE ,6 ); +if (len >CA8210_SPI_BUF_SIZE || len <2 ) {dev_warn ( &priv->spi->dev, -"userspace requested erroneously long write (%zu)\n" , +"userspace requested erroneous write length (%zu)\n" , len ); -return -EMSGSIZE ; +return -EBADE ; } ret =copy_from_user (command, in_buf, len);
@@ -2511,6 +2512,13 @@ static ssize_t ca8210_test_int_user_writ );return -EIO ; } +if (len != command[1 ] +2 ) { +dev_err ( + &priv->spi->dev, +"write len does not match packet length field\n" + ); +return -EBADE ; + } ret =ca8210_test_check_upstream (command, priv->spi);if (ret ==0 ) {
Greg Kroah-Hartman
maintainerPATCH 364/496 ath10k: advertize beacon_int_min_gcd
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anilkumar Kolli <[email protected]>
[ Upstream commit 8ebee73b574ad3dd1f14d461f65ceaffbd637650 ]
This patch fixes regression caused by 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals"), with this change cfg80211 expects the driver to advertize 'beacon_int_min_gcd' to support different beacon intervals in multivap scenario. This support is added for, QCA988X/QCA99X0/QCA9984/QCA4019.
Verifed AP + mesh bring up on QCA9984 with beacon interval 100msec and 1000msec respectively.
Frimware: firmware-5.bin_10.4-3.5.3-00053
--- drivers/net/wireless/ath/ath10k/mac.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/wireless/ath/ath10k/mac.c +2 -0
@@ -7810,6 +7810,7 @@ static const struct ieee80211_iface_comb .max_interfaces = 8, .num_different_channels = 1, .beacon_int_infra_match = true, + .beacon_int_min_gcd =1 , #ifdef CONFIG_ATH10K_DFS_CERTIFIED .radar_detect_widths =BIT (NL80211_CHAN_WIDTH_20_NOHT ) | BIT(NL80211_CHAN_WIDTH_20) |
@@ -7933,6 +7934,7 @@ static const struct ieee80211_iface_comb .max_interfaces = 16, .num_different_channels = 1, .beacon_int_infra_match = true, + .beacon_int_min_gcd =1 , #ifdef CONFIG_ATH10K_DFS_CERTIFIED .radar_detect_widths =BIT (NL80211_CHAN_WIDTH_20_NOHT ) | BIT(NL80211_CHAN_WIDTH_20) |
Greg Kroah-Hartman
maintainerPATCH 365/496 iommu/amd: Take into account that alloc_dev_data() may return NULL
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 39ffe39545cd5cb5b8cee9f0469165cf24dc62c2 ]
find_dev_data() does not check whether the return value alloc_dev_data() is NULL. This was okay once because the pointer was returned once as-is. Since commit df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") the pointer may be used within find_dev_data() so a NULL check is required.
--- drivers/iommu/amd_iommu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/amd_iommu.c +2 -0
@@ -311,6 +311,8 @@ static struct iommu_dev_data *find_dev_dif (dev_data ==NULL ) { dev_data =alloc_dev_data (devid); +if (!dev_data) +return NULL ;if (translation_pre_enabled (iommu)) dev_data->defer_attach = true;
Greg Kroah-Hartman
maintainerPATCH 366/496 intel_th: Use correct method of finding hub
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shishkin <[email protected]>
[ Upstream commit 9ad577087165478c9d9be82b15ed9bf2db5835f5 ]
Since commit 8edc514b01e9 ("intel_th: Make SOURCE devices children of the root device") the hub is not the parent of SOURCE devices any more, so the new helper function should be used for that instead of always using the parent. The intel_th_set_output() path, however, still uses the old logic, leading to the hub driver structure being aliased with something else, like struct pci_driver or struct acpi_driver, and an incorrect call to an address inferred from that, potentially resulting in a crash.
--- drivers/hwtracing/intel_th/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/intel_th/core.c +1 -1
@@ -935,7 +935,7 @@ EXPORT_SYMBOL_GPL(intel_th_trace_disableint intel_th_set_output (struct intel_th_device *thdev,unsigned int master) { -struct intel_th_device *hub =to_intel_th_device (thdev->dev.parent); +struct intel_th_device *hub =to_intel_th_hub (thdev);struct intel_th_driver *hubdrv =to_intel_th_driver (hub->dev.driver);if (!hubdrv->set_output)
Greg Kroah-Hartman
maintainerPATCH 367/496 m68k: set dma and coherent masks for platform FEC ethernets
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Ungerer <[email protected]>
[ Upstream commit f61e64310b75733d782e930d1fb404b84699eed6 ]
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask") the Freescale FEC driver is issuing the following warning on driver initialization on ColdFire systems:
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
Call Trace:
[<40025534>] 0x40025534
[<4004e514>] 0x4004e514
[<400255de>] 0x400255de
[<40159e20>] 0x40159e20
[<40159e20>] 0x40159e20It is not fatal, the driver and the system continue to function normally.
As per the warning the coherent_dma_mask is not set on this device. There is nothing special about the DMA memory coherency on this hardware so we can just set the mask to 32bits in the platform data for the FEC ethernet devices.
--- arch/m68k/coldfire/device.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/m68k/coldfire/device.c +10 -2
@@ -135,7 +135,11 @@ static struct platform_device mcf_fec0 = .id = 0, .num_resources = ARRAY_SIZE(mcf_fec0_resources), .resource = mcf_fec0_resources, - .dev.platform_data = FEC_PDATA, + .dev = { + .dma_mask = &mcf_fec0.dev.coherent_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = FEC_PDATA, + } };#ifdef MCFFEC_BASE1
@@ -167,7 +171,11 @@ static struct platform_device mcf_fec1 = .id = 1, .num_resources = ARRAY_SIZE(mcf_fec1_resources), .resource = mcf_fec1_resources, - .dev.platform_data = FEC_PDATA, + .dev = { + .dma_mask = &mcf_fec1.dev.coherent_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = FEC_PDATA, + } };#endif /* MCFFEC_BASE1 */ #endif /* CONFIG_FEC */
Greg Kroah-Hartman
maintainerPATCH 368/496 iwlwifi: mvm: check if mac80211_queue is valid in iwl_mvm_disable_txq
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Coelho <[email protected]>
[ Upstream commit 9a233bb8025105db9a60b5d761005cc5a6c77f3d ]
Sometimes iwl_mvm_disable_txq() may be called with mac80211_queue == IEEE80211_INVAL_HW_QUEUE, and this would cause us to use BIT(0xFF) which is way too large for the u16 we used to store it in hw_queue_to_mac820211. If this happens the following UBSAN warning will be generated:
[ 167.185167] UBSAN: Undefined behaviour in drivers/net/wireless/intel/iwlwifi/mvm/utils.c:838:5 [ 167.185171] shift exponent 255 is too large for 64-bit type 'long unsigned int'
Fix that by checking that it is not IEEE80211_INVAL_HW_QUEUE and, while at it, add a warning if the queue number is larger than IEEE80211_MAX_QUEUES.
--- drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/utils.c +9 -2
@@ -810,12 +810,19 @@ int iwl_mvm_disable_txq(struct iwl_mvm * .scd_queue = queue, .action = SCD_CFG_DISABLE_QUEUE, }; -bool remove_mac_queue = true; +bool remove_mac_queue = mac80211_queue !=IEEE80211_INVAL_HW_QUEUE ;int ret; +if (WARN_ON (remove_mac_queue && mac80211_queue >=IEEE80211_MAX_QUEUES )) +return -EINVAL ; +if (iwl_mvm_has_new_tx_api (mvm)) {spin_lock_bh (&mvm->queue_info_lock); - mvm->hw_queue_to_mac80211[queue] &= ~BIT (mac80211_queue); + +if (remove_mac_queue) + mvm->hw_queue_to_mac80211[queue] &= + ~BIT (mac80211_queue); +spin_unlock_bh (&mvm->queue_info_lock);iwl_trans_txq_free (mvm->trans, queue);
Greg Kroah-Hartman
maintainerPATCH 369/496 parisc/pci: Switch LBA PCI bus from Hard Fail to Soft Fail mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
[ Upstream commit b845f66f78bf42a4ce98e5cfe0e94fab41dd0742 ]
Carlo Pisani noticed that his C3600 workstation behaved unstable during heavy I/O on the PCI bus with a VIA VT6421 IDE/SATA PCI card.
To avoid such instability, this patch switches the LBA PCI bus from Hard Fail mode into Soft Fail mode. In this mode the bus will return -1UL for timed out MMIO transactions, which is exactly how the x86 (and most other architectures) PCI busses behave.
This patch is based on a proposal by Grant Grundler and Kyle McMartin 10 years ago:
https://www.spinics.net/lists/linux-parisc/msg01027.html
--- drivers/parisc/lba_pci.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
drivers/parisc/lba_pci.c +19 -1
@@ -1403,9 +1403,27 @@ lba_hw_init(struct lba_device *d)WRITE_REG32 (stat, d->hba.base_addr +LBA_ERROR_CONFIG ); } -/* Set HF mode as the default (vs. -1 mode). */ + +/* +* Hard Fail vs. Soft Fail on PCI "Master Abort". +* +* "Master Abort" means the MMIO transaction timed out - usually due to +* the device not responding to an MMIO read. We would like HF to be +* enabled to find driver problems, though it means the system will +* crash with a HPMC. +* +* In SoftFail mode "~0L" is returned as a result of a timeout on the +* pci bus. This is like how PCI busses on x86 and most other +* architectures behave. In order to increase compatibility with +* existing (x86) PCI hardware and existing Linux drivers we enable +* Soft Faul mode on PA-RISC now too. +*/ stat =READ_REG32 (d->hba.base_addr +LBA_STAT_CTL ); +#if defined(ENABLE_HARDFAIL )WRITE_REG32 (stat |HF_ENABLE , d->hba.base_addr +LBA_STAT_CTL ); +#else +WRITE_REG32 (stat & ~HF_ENABLE , d->hba.base_addr +LBA_STAT_CTL ); +#endif /* ** Writing a zero to STAT_CTL.rf (bit 0) will clear reset signal
Greg Kroah-Hartman
maintainerPATCH 370/496 hwmon: (nct6775) Fix writing pwmX_mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 415eb2a1aaa4881cf85bd86c683356fdd8094a23 ]
pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip register bit is set to 1 for DC mode. This got mixed up, and writing 1 into pwmX_mode resulted in DC mode enabled. Fix it up by using the ABI definition throughout the driver for consistency.
--- drivers/hwmon/nct6775.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/hwmon/nct6775.c +5 -5
@@ -1469,7 +1469,7 @@ static void nct6775_update_pwm(struct de duty_is_dc = data->REG_PWM_MODE[i] && (nct6775_read_value (data, data->REG_PWM_MODE[i]) & data->PWM_MODE_MASK[i]); - data->pwm_mode[i] = duty_is_dc; + data->pwm_mode[i] = !duty_is_dc; fanmodecfg =nct6775_read_value (data, data->REG_FAN_MODE[i]);for (j =0 ; j <ARRAY_SIZE (data->REG_PWM); j++) {
@@ -2350,7 +2350,7 @@ show_pwm_mode(struct device *dev, structstruct nct6775_data *data =nct6775_update_device (dev);struct sensor_device_attribute *sattr =to_sensor_dev_attr (attr); -return sprintf (buf,"%d\n" , !data->pwm_mode[sattr->index]); +return sprintf (buf,"%d\n" , data->pwm_mode[sattr->index]); } static ssize_t
@@ -2371,9 +2371,9 @@ store_pwm_mode(struct device *dev, strucif (val >1 )return -EINVAL ; -/* Setting DC mode is not supported for all chips/channels */ +/* Setting DC mode (0) is not supported for all chips/channels */ if (data->REG_PWM_MODE[nr] ==0 ) { -if (val) +if (!val)return -EINVAL ;return count; }
@@ -2382,7 +2382,7 @@ store_pwm_mode(struct device *dev, struc data->pwm_mode[nr] = val; reg =nct6775_read_value (data, data->REG_PWM_MODE[nr]); reg &= ~data->PWM_MODE_MASK[nr]; -if (val) +if (!val) reg |= data->PWM_MODE_MASK[nr];nct6775_write_value (data, data->REG_PWM_MODE[nr], reg);mutex_unlock (&data->update_lock);
Greg Kroah-Hartman
maintainerPATCH 371/496 powerpc/perf: Prevent kernel address leak to userspace via BHRB buffer
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Madhavan Srinivasan <[email protected]>
[ Upstream commit bb19af816025d495376bd76bf6fbcf4244f9a06d ]
The current Branch History Rolling Buffer (BHRB) code does not check for any privilege levels before updating the data from BHRB. This could leak kernel addresses to userspace even when profiling only with userspace privileges. Add proper checks to prevent it.
--- arch/powerpc/perf/core-book3s.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/powerpc/perf/core-book3s.c +10 -0
@@ -457,6 +457,16 @@ static void power_pmu_bhrb_read(struct c/* invalid entry */ continue ; +/* +* BHRB rolling buffer could very much contain the kernel +* addresses at this point. Check the privileges before +* exporting it to userspace (avoid exposure of regions +* where we could have speculative execution) +*/ +if (perf_paranoid_kernel () && !capable (CAP_SYS_ADMIN ) && +is_kernel_addr (addr)) +continue ; +/* Branches are read most recent first (ie. mfbhrb 0 is * the most recent branch). * There are two types of valid entries:
Greg Kroah-Hartman
maintainerPATCH 372/496 powerpc/perf: Fix kernel address leak via sampling registers
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
[ Upstream commit e1ebd0e5b9d0a10ba65e63a3514b6da8c6a5a819 ]
Current code in power_pmu_disable() does not clear the sampling registers like Sampling Instruction Address Register (SIAR) and Sampling Data Address Register (SDAR) after disabling the PMU. Since these are userspace readable and could contain kernel addresses, add code to explicitly clear the content of these registers.
Also add a "context synchronizing instruction" to enforce no further updates to these registers as suggested by Power ISA v3.0B. From section 9.4, on page 1108:
"If an mtspr instruction is executed that changes the value of a Performance Monitor register other than SIAR, SDAR, and SIER, the change is not guaranteed to have taken effect until after a subsequent context synchronizing instruction has been executed (see Chapter 11. "Synchronization Requirements for Context Alterations" on page 1133)."
--- arch/powerpc/perf/core-book3s.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
arch/powerpc/perf/core-book3s.c +15 -0
@@ -1236,6 +1236,7 @@ static void power_pmu_disable(struct pmu*/ write_mmcr0 (cpuhw, val);mb (); +isync ();/* * Disable instruction sampling if it was enabled
@@ -1244,12 +1245,26 @@ static void power_pmu_disable(struct pmumtspr (SPRN_MMCRA , cpuhw->mmcr[2 ] & ~MMCRA_SAMPLE_ENABLE );mb (); +isync (); } cpuhw->disabled =1 ; cpuhw->n_added =0 ;ebb_switch_out (mmcr0); + +#ifdef CONFIG_PPC64 +/* +* These are readable by userspace, may contain kernel +* addresses and are not switched by context switch, so clear +* them now to avoid leaking anything to userspace in general +* including to another process. +*/ +if (ppmu->flags &PPMU_ARCH_207S ) { +mtspr (SPRN_SDAR ,0 ); +mtspr (SPRN_SIAR ,0 ); + } +#endif }local_irq_restore (flags);
Greg Kroah-Hartman
maintainerPATCH 373/496 rsi: fix kernel panic observed on 64bit machine
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amitkumar Karwar <[email protected]>
[ Upstream commit 864db4d5085349fcfa1f260b5bcd2adde3d7f2ed ]
Following kernel panic is observed on 64bit machine while loading the driver. It is fixed if we pass dynamically allocated memory to SDIO for DMA.
BUG: unable to handle kernel paging request at ffffeb04000172e0 IP: sg_miter_stop+0x56/0x70 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Modules linked in: rsi_sdio(OE+) rsi_91x(OE) btrsi(OE) rfcomm bluetooth ecdh_generic mac80211 mmc_block fuse xt_CHECKSUM iptable_mangle drm_kms_helper mmc_core serio_raw drm firewire_ohci tg3 CPU: 0 PID: 4003 Comm: insmod Tainted: G OE 4.16.0-rc1+ #27 Hardware name: Dell Inc. Latitude E5500 /0DW634, BIOS A19 06/13/2013 RIP: 0010:sg_miter_stop+0x56/0x70 RSP: 0018:ffff88007d003e78 EFLAGS: 00010002 RAX: 0000000000000003 RBX: 0000000000000004 RCX: 0000000000000000 RDX: ffffeb04000172c0 RSI: ffff88002f58002c RDI: ffff88007d003e80 RBP: 0000000000000004 R08: ffff88007d003e80 R09: 0000000000000008 R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000004 R13: ffff88002f580028 R14: 0000000000000000 R15: 0000000000000004 FS: 00007f35c29db700(0000) GS:ffff88007d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffeb04000172e0 CR3: 000000007038e000 CR4: 00000000000406f0 Call Trace: <IRQ> sg_copy_buffer+0xc6/0xf0 sdhci_tasklet_finish+0x170/0x260 [sdhci] tasklet_action+0xf4/0x100 __do_softirq+0xef/0x26e irq_exit+0xbe/0xd0 do_IRQ+0x4a/0xc0 common_interrupt+0xa2/0xa2 </IRQ>
--- drivers/net/wireless/rsi/rsi_91x_sdio.c | 32 +++++++++++++++++++++----------- drivers/net/wireless/rsi/rsi_sdio.h | 2 ++ 2 files changed, 23 insertions(+), 11 deletions(-)
drivers/net/wireless/rsi/rsi_91x_sdio.c +21 -11
@@ -636,11 +636,14 @@ static int rsi_sdio_master_reg_read(stru u32 *read_buf, u16 size) {u32 addr_on_bus, *data; -u32 align[2 ] = {};u16 ms_addr;int status; - data =PTR_ALIGN (&align[0 ],8 ); + data =kzalloc (RSI_MASTER_REG_BUF_SIZE ,GFP_KERNEL ); +if (!data) +return -ENOMEM ; + + data =PTR_ALIGN (data,8 ); ms_addr = (addr >>16 ); status =rsi_sdio_master_access_msword (adapter, ms_addr);
@@ -648,7 +651,7 @@ static int rsi_sdio_master_reg_read(strursi_dbg (ERR_ZONE ,"%s: Unable to set ms word to common reg\n" , __func__); -return status; + goto err; } addr &=0xFFFF ;
@@ -666,7 +669,7 @@ static int rsi_sdio_master_reg_read(stru (u8 *)data, 4);if (status <0 ) {rsi_dbg (ERR_ZONE ,"%s: AHB register read failed\n" , __func__); -return status; + goto err; }if (size ==2 ) {if ((addr &0x3 ) ==0 )
@@ -688,17 +691,23 @@ static int rsi_sdio_master_reg_read(stru *read_buf = *data; } -return 0 ; +err: +kfree (data); +return status; }static int rsi_sdio_master_reg_write (struct rsi_hw *adapter,unsigned long addr,unsigned long data,u16 size) { -unsigned long data1[2 ], *data_aligned; +unsigned long *data_aligned;int status; - data_aligned =PTR_ALIGN (&data1[0 ],8 ); + data_aligned =kzalloc (RSI_MASTER_REG_BUF_SIZE ,GFP_KERNEL ); +if (!data_aligned) +return -ENOMEM ; + + data_aligned =PTR_ALIGN (data_aligned,8 );if (size ==2 ) { *data_aligned = ((data <<16 ) | (data &0xFFFF ));
@@ -717,6 +726,7 @@ static int rsi_sdio_master_reg_write(strrsi_dbg (ERR_ZONE ,"%s: Unable to set ms word to common reg\n" , __func__); +kfree (data_aligned);return -EIO ; } addr = addr &0xFFFF ;
@@ -726,12 +736,12 @@ static int rsi_sdio_master_reg_write(str (adapter, (addr |RSI_SD_REQUEST_MASTER ), (u8 *)data_aligned, size); -if (status <0 ) { +if (status <0 )rsi_dbg (ERR_ZONE ,"%s: Unable to do AHB reg write\n" , __func__); -return status; - } -return 0 ; + +kfree (data_aligned); +return status; }/**
drivers/net/wireless/rsi/rsi_sdio.h +2 -0
@@ -46,6 +46,8 @@ enum sdio_interrupt_type {#define PKT_BUFF_AVAILABLE 1#define FW_ASSERT_IND 2 +#define RSI_MASTER_REG_BUF_SIZE 12 +#define RSI_DEVICE_BUFFER_STATUS_REGISTER 0xf3#define RSI_FN1_INT_REGISTER 0xf9#define RSI_SD_REQUEST_MASTER 0x10000
Greg Kroah-Hartman
maintainerPATCH 374/496 tools/thermal: tmon: fix for segfault
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank Asseg <[email protected]>
[ Upstream commit 6c59f64b7ecf2bccbe73931d7d573d66ed13b537 ]
Fixes a segfault occurring when e.g. <TAB> is pressed multiple times in the ncurses tmon application. The segfault is caused by incrementing cur_thermal_record in the main function without checking if it's value reached NR_THERMAL_RECORD immediately. Since the boundary check only occurred in update_thermal_data a race condition existed, which lead to an attempted read beyond the last element of the trec array.
The fix was implemented by moving the cur_thermal_record incrementation to the update_thermal_data function using a temporary variable on which the boundary condition is checked before updating cur_thread_record, so that the variable is never incremented beyond the trec array's boundary.
It seems the segfault does not occur on every machine: On a HP EliteBook G4 the segfault happens, while it does not happen on a Thinkpad T540p.
--- tools/thermal/tmon/sysfs.c | 12 +++++++----- tools/thermal/tmon/tmon.c | 1 - 2 files changed, 7 insertions(+), 6 deletions(-)
tools/thermal/tmon/sysfs.c +7 -5
@@ -486,6 +486,7 @@ int zone_instance_to_index(int zone_instint update_thermal_data () {int i; +int next_thermal_record = cur_thermal_record +1 ;char tz_name[256 ];static unsigned long samples;
@@ -495,9 +496,9 @@ int update_thermal_data() }/* circular buffer for keeping historic data */ -if (cur_thermal_record >=NR_THERMAL_RECORDS ) - cur_thermal_record =0 ; -gettimeofday (&trec[cur_thermal_record].tv,NULL ); +if (next_thermal_record >=NR_THERMAL_RECORDS ) + next_thermal_record =0 ; +gettimeofday (&trec[next_thermal_record].tv,NULL );if (tmon_log) {fprintf (tmon_log,"%lu " , ++samples);fprintf (tmon_log,"%3.1f " , p_param.t_target);
@@ -507,11 +508,12 @@ int update_thermal_data()snprintf (tz_name,256 ,"%s/%s%d" ,THERMAL_SYSFS ,TZONE , ptdata.tzi[i].instance);sysfs_get_ulong (tz_name,"temp" , - &trec[cur_thermal_record].temp[i]); + &trec[next_thermal_record].temp[i]);if (tmon_log)fprintf (tmon_log,"%lu " , - trec[cur_thermal_record].temp[i]/1000 ); + trec[next_thermal_record].temp[i] /1000 ); } + cur_thermal_record = next_thermal_record;for (i =0 ; i < ptdata.nr_cooling_dev; i++) {char cdev_name[256 ];unsigned long val;
tools/thermal/tmon/tmon.c +0 -1
@@ -336,7 +336,6 @@ int main(int argc, char **argv)show_data_w ();show_cooling_device (); } - cur_thermal_record++; time_elapsed += ticktime;controller_handler (trec[0 ].temp[target_tz_index] /1000 , &yk);
Greg Kroah-Hartman
maintainerPATCH 375/496 selftests: Print the test were running to /dev/kmsg
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
[ Upstream commit 88893cf787d3062c631cc20b875068eb11756e03 ]
Some tests cause the kernel to print things to the kernel log buffer (ie. printk), in particular oops and warnings etc. However when running all the tests in succession it's not always obvious which test(s) caused the kernel to print something.
We can narrow it down by printing which test directory we're running in to /dev/kmsg, if it's writable.
Example output:
[ 170.149149] kselftest: Running tests in powerpc
[ 305.300132] kworker/dying (71) used greatest stack depth: 7776 bytes
left
[ 808.915456] kselftest: Running tests in pstore--- tools/testing/selftests/Makefile | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/Makefile +1 -0
@@ -122,6 +122,7 @@ ifdef INSTALL_PATH BUILD_TARGET=$$BUILD/$$TARGET; \ echo "echo ; echo Running tests in $$TARGET" >> $(ALL_SCRIPT); \ echo "echo ========================================" >> $(ALL_SCRIPT); \ + echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \ echo "cd $$TARGET" >> $(ALL_SCRIPT); \ make -s --no-print-directory OUTPUT=$$BUILD_TARGET -C $$TARGET emit_tests >> $(ALL_SCRIPT); \ echo "cd \$$ROOT" >> $(ALL_SCRIPT); \
Greg Kroah-Hartman
maintainerPATCH 376/496 net/mlx5: Protect from command bit overflow
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
[ Upstream commit 957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ]
The system with CONFIG_UBSAN enabled on produces the following error during driver initialization. The reason to it that max_reg_cmds can be larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long.
================================================================================
UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42 signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0xe9/0x18f ? dma_virt_alloc+0x81/0x81 ubsan_epilogue+0xe/0x4e handle_overflow+0x187/0x20c mlx5_cmd_init+0x73a/0x12b0 mlx5_load_one+0x1c3d/0x1d30 init_one+0xd02/0xf10 pci_device_probe+0x26c/0x3b0 driver_probe_device+0x622/0xb40 __driver_attach+0x175/0x1b0 bus_for_each_dev+0xef/0x190 bus_add_driver+0x2db/0x490 driver_register+0x16b/0x1e0 __pci_register_driver+0x177/0x1b0 init+0x6d/0x92 do_one_initcall+0x15b/0x270 kernel_init_freeable+0x2d8/0x3d0 kernel_init+0x14/0x190 ret_from_fork+0x24/0x30 ================================================================================
--- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/cmd.c +1 -1
@@ -1802,7 +1802,7 @@ int mlx5_cmd_init(struct mlx5_core_dev * cmd->checksum_disabled =1 ; cmd->max_reg_cmds = (1 << cmd->log_sz) -1 ; - cmd->bitmask = (1 << cmd->max_reg_cmds) -1 ; + cmd->bitmask = (1UL << cmd->max_reg_cmds) -1 ; cmd->cmdif_rev =ioread32be (&dev->iseg->cmdif_rev_fw_sub) >>16 ;if (cmd->cmdif_rev >CMD_IF_REV ) {
Greg Kroah-Hartman
maintainerPATCH 377/496 watchdog: davinci_wdt: fix error handling in davinci_wdt_probe()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Khoroshilov <[email protected]>
[ Upstream commit d66e53649c18377edc08d48901e658e4fd491d46 ]
clk_disable_unprepare() was added to one error path, but there is another one. The patch makes sure clk is disabled at the both of them.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/watchdog/davinci_wdt.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/watchdog/davinci_wdt.c +11 -4
@@ -198,15 +198,22 @@ static int davinci_wdt_probe(struct plat wdt_mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); davinci_wdt->base =devm_ioremap_resource (dev, wdt_mem); -if (IS_ERR (davinci_wdt->base)) -return PTR_ERR (davinci_wdt->base); +if (IS_ERR (davinci_wdt->base)) { + ret =PTR_ERR (davinci_wdt->base); + goto err_clk_disable; + } ret =watchdog_register_device (wdd); -if (ret <0 ) { -clk_disable_unprepare (davinci_wdt->clk); +if (ret) {dev_err (dev,"cannot register watchdog device\n" ); + goto err_clk_disable; } +return 0 ; + +err_clk_disable: +clk_disable_unprepare (davinci_wdt->clk); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 378/496 ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karthikeyan Periyasamy <[email protected]>
[ Upstream commit 8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ]
When attempt to run worker (ath10k_sta_rc_update_wk) after the station object (ieee80211_sta) delete will trigger the kernel panic.
This problem arise in AP + Mesh configuration, Where the current node AP VAP and neighbor node mesh VAP MAC address are same. When the current mesh node try to establish the mesh link with neighbor node, driver peer creation for the neighbor mesh node fails due to duplication MAC address. Already the AP VAP created with same MAC address.
It is caused by the following scenario steps.
Steps:
1. In above condition, ath10k driver sta_state callback (ath10k_sta_state) fails to do the state change for a station from IEEE80211_STA_NOTEXIST to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is called from ieee80211_add_station() to handle the new station (neighbor mesh node) request from the wpa_supplicant.
2. Concurrently ath10k receive the sta_rc_update callback notification from the mesh_neighbour_update() to handle the beacon frames of the above neighbor mesh node. since its atomic callback, ath10k driver queue the work (ath10k_sta_rc_update_wk) to handle rc update.
3. Due to driver sta_state callback fails (step 1), mac80211 free the station object.
4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access the station object which is already deleted. so it will trigger kernel panic.
Added the peer exist check in sta_rc_update callback before queue the work.
Kernel Panic log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1 task: dcef0000 ti: d72b6000 task.ti: d72b6000 PC is at pwq_activate_delayed_work+0x10/0x40 LR is at pwq_activate_delayed_work+0xc/0x40 pc : [<c023f988>] lr : [<c023f984>] psr: 40000193
sp : d72b7f18 ip : 0000007a fp : d72b6000
r10: 00000000 r9 : dd404414 r8 : d8c31998
r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300 r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5787d Table: 595bc06a DAC: 00000015
...
Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238)
Stack: (0xd72b7f18 to 0xd72b8000)
7f00: 00000001 dcee1300
7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089 7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000 7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000 7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340 7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4) [<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360) [<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec) [<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34)
Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs
Rebooting in 3 seconds..
--- drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/wireless/ath/ath10k/mac.c +10 -0
@@ -7059,10 +7059,20 @@ static void ath10k_sta_rc_update(struct {struct ath10k *ar = hw->priv;struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv; +struct ath10k_vif *arvif = (void *)vif->drv_priv; +struct ath10k_peer *peer;u32 bw, smps;spin_lock_bh (&ar->data_lock); + peer =ath10k_peer_find (ar, arvif->vdev_id, sta->addr); +if (!peer) { +spin_unlock_bh (&ar->data_lock); +ath10k_warn (ar,"mac sta rc update failed to find peer %pM on vdev %i\n" , + sta->addr, arvif->vdev_id); +return ; + } + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac sta rc update for %pM changed %08x bw %d nss %d smps %d\n", sta->addr, changed, sta->bandwidth, sta->rx_nss,
Greg Kroah-Hartman
maintainerPATCH 380/496 ath9k: fix crash in spectral scan
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Gottschall <[email protected]>
[ Upstream commit 221b6ec69ed9c56b6cd9a124a387a9472f14284e ]
Fixes crash seen on arm smp systems (gateworks ventana imx6):
Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = 80004000 [00000014] *pgd=00000000 Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM Modules linked in: ip6table_filter nf_conntrack_ipv6 ip6_tables nf_log_ipv6 nf_defrag_ipv6 shortcut_fe ipcomp6 xfrm_ipcomp xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet ip6_tunnel tunnel6 mip6 ah6 esp6 xfrm_algo sit ip_tunnel tunnel4 ipv6 ath10k_pci ath10k_core ath9k ath mac80211 cfg80211 compat ath_pci ath_hal(P) caamalg authencesn authenc caamrng caamhash caam_jr caam cdc_ncm usbnet usbcore sky2 imx2_wdt CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: P 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: bf064980 task.stack: bf07c000 PC is at relay_buf_full+0xc/0x30 LR is at _674+0x740/0xf10 [ath9k] pc : [<8018bce0>] lr : [<7f1aa604>] psr: 80000013
sp : bf07dbf0 ip : bf07dc00 fp : bf07dbfc
r10: 0000003f r9 : bf130e00 r8 : 809044b0
r7 : 00000000 r6 : be67a9f0 r5 : 00000000 r4 : 809043e4 r3 : c0864c24 r2 : 00000000 r1 : 00000004 r0 : 00000000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 4e6a004a DAC: 00000055 Process ksoftirqd/0 (pid: 3, stack limit = 0xbf07c210)
Stack: (0xbf07dbf0 to 0xbf07e000)
dbe0: bf07dd04 bf07dc00 7f1aa604 8018bce0
dc00: 00004014 be59e010 bf07dc34 bf07dc18 7f1a7084 7f19c07c be59c010 be6470a0
dc20: 0000096c be648954 bf07dc6c bf07dc38 7f1c286c bf07dd90 bf07dc5c bf07dc48
dc40: 8029ea4c 0000003c 00000001 be59c010 00000094 00000000 00000000 00000000
dc60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dc80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dca0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dcc0: 00000000 00000000 00000000 00000000 00000000 00000000 8010ef24 00000030
dce0: be94f5e8 be6485a0 bddf0200 be59c010 be6465a0 be6415a0 bf07ddf4 bf07dd08
dd00: 7f1cf800 7f1aa55c 1fc38c4c 00000000 bf07dd58 cccccccd 66666667 be640bc0
dd20: bf07dd54 be6415a0 1fc38c4c 00000000 00000000 be59c038 be67a9c0 be59e010
dd40: be67a9f0 be647170 8090c904 be59c010 00000000 00000001 1fc38e84 00000000
dd60: be640bc0 bddf0200 00000200 00000010 0000003f 00000002 20000013 be59c010
dd80: 8092d940 bf7ca2c0 bf07ddb4 bf07dd98 1fc38c4c 2602003f 0100ff1b 80ff1b00
dda0: 00808080 00000000 00000000 80808080 80808080 80808080 80808080 00008080
ddc0: 00000000 00000000 7f1b62b8 00000002 be6470ec be6470f0 00000000 bf07de98
dde0: 8092d940 be6415a0 bf07de94 bf07ddf8 7f1d1ed8 7f1cf1fc 00000000 00000000
de00: bf7cc4c0 00000400 be6470f0 bf07de18 8015165c be59c010 8090453c 8090453c
de20: bf07dec4 be6465a0 8014f614 80148884 0000619a 00000001 bf07c000 00000100
de40: bf07de78 00000001 7f327850 00000002 afb50401 bf064980 bf07de9c bf07de68
de60: bf064a00 803cc668 bf064a00 be6470b4 be6470b8 80844180 00000000 bf07de98
de80: 8092d940 bf07c000 bf07dec4 bf07de98 80124d18 7f1d1c44 80124c94 00000000
dea0: 00000006 80902098 80902080 40000006 00000100 bf07c000 bf07df24 bf07dec8
dec0: 8012501c 80124ca0 bf7cc4c0 bf064980 be95e1c0 04208040 80902d00 000061c7
dee0: 0000000a 80600b54 8092d940 808441f8 80902080 bf07dec8 bf03b200 bf07c000
df00: bf03b200 8090fe54 00000000 00000000 00000000 00000000 bf07df34 bf07df28
df20: 80125148 80124f28 bf07df5c bf07df38 8013deb4 8012511c 00000000 bf03b240
df40: bf03b200 8013dc90 00000000 00000000 bf07dfac bf07df60 8013ad40 8013dc9c
df60: 70448040 00000001 00000000 bf03b200 00000000 00030003 bf07df78 bf07df78
df80: 00000000 00000000 bf07df88 bf07df88 bf03b240 8013ac48 00000000 00000000
dfa0: 00000000 bf07dfb0 80107760 8013ac54 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 8c120004 1190ad04
Backtrace: [<8018bcd4>] (relay_buf_full) from [<7f1aa604>] (_674+0x740/0xf10 [ath9k]) [<7f1aa550>] (_674 [ath9k]) from [<7f1cf800>] (_582+0x14b4/0x3708 [ath9k]) r10:be6415a0 r9:be6465a0 r8:be59c010 r7:bddf0200 r6:be6485a0 r5:be94f5e8 r4:00000030 [<7f1cf1f0>] (_582 [ath9k]) from [<7f1d1ed8>] (_735+0x2a0/0xec4 [ath9k]) r10:be6415a0 r9:8092d940 r8:bf07de98 r7:00000000 r6:be6470f0 r5:be6470ec r4:00000002 [<7f1d1c38>] (_735 [ath9k]) from [<80124d18>] (tasklet_action+0x84/0xf8) r10:bf07c000 r9:8092d940 r8:bf07de98 r7:00000000 r6:80844180 r5:be6470b8 r4:be6470b4 [<80124c94>] (tasklet_action) from [<8012501c>] (__do_softirq+0x100/0x1f4) r10:bf07c000 r9:00000100 r8:40000006 r7:80902080 r6:80902098 r5:00000006 r4:00000000 r3:80124c94 [<80124f1c>] (__do_softirq) from [<80125148>] (run_ksoftirqd+0x38/0x4c) r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:8090fe54 r5:bf03b200 r4:bf07c000 [<80125110>] (run_ksoftirqd) from [<8013deb4>] (smpboot_thread_fn+0x224/0x260) [<8013dc90>] (smpboot_thread_fn) from [<8013ad40>] (kthread+0xf8/0x100) r9:00000000 r8:00000000 r7:8013dc90 r6:bf03b200 r5:bf03b240 r4:00000000 [<8013ac48>] (kthread) from [<80107760>] (ret_from_fork+0x14/0x34) r7:00000000 r6:00000000 r5:8013ac48 r4:bf03b240 Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5901014) ---[ end trace dddf11ac9111b272 ]--- Kernel panic - not syncing: Fatal exception in interrupt CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<8010a708>] (dump_backtrace) from [<8010a99c>] (show_stack+0x18/0x1c) r7:bf093f58 r6:20000193 r5:809168e8 r4:00000000 [<8010a984>] (show_stack) from [<802a09c4>] (dump_stack+0x94/0xa8) [<802a0930>] (dump_stack) from [<8010d184>] (handle_IPI+0xe8/0x180) r7:bf093f58 r6:00000000 r5:00000001 r4:808478c4 [<8010d09c>] (handle_IPI) from [<801013e8>] (gic_handle_irq+0x78/0x7c) r7:f4000100 r6:bf093f58 r5:f400010c r4:8090467c [<80101370>] (gic_handle_irq) from [<8010b378>] (__irq_svc+0x58/0x8c) Exception stack(0xbf093f58 to 0xbf093fa0)
3f40: bf7d62a0 00000000
3f60: 0010a5f4 80113460 bf092000 809043e4 00000002 80904434 bf092008 412fc09a 3f80: 00000000 bf093fb4 bf093fb8 bf093fa8 8010804c 80108050 60000013 ffffffff
r9:bf092000 r8:bf092008 r7:bf093f8c r6:ffffffff r5:60000013 r4:80108050
[<80108014>] (arch_cpu_idle) from [<80553c2c>] (default_idle_call+0x30/0x34) [<80553bfc>] (default_idle_call) from [<80158394>] (cpu_startup_entry+0xc4/0xfc) [<801582d0>] (cpu_startup_entry) from [<8010ce40>] (secondary_start_kernel+0x168/0x174)
r7:8092d2f8 r4:80913568
[<8010ccd8>] (secondary_start_kernel) from [<10101488>] (0x10101488)
r5:00000055 r4:4f07806a
Rebooting in 10 seconds..
Reboot failed -- System halted
--- drivers/net/wireless/ath/ath9k/common-spectral.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/net/wireless/ath/ath9k/common-spectral.c +7 -5
@@ -479,14 +479,16 @@ ath_cmn_is_fft_buf_full(struct ath_spec_ {int i =0 ;int ret =0 ; +struct rchan_buf *buf;struct rchan *rc = spec_priv->rfs_chan_spec_scan; -for_each_online_cpu (i) - ret +=relay_buf_full (*per_cpu_ptr (rc->buf, i)); +for_each_possible_cpu (i) { +if ((buf = *per_cpu_ptr (rc->buf, i))) { + ret +=relay_buf_full (buf); + } + } - i =num_online_cpus (); - -if (ret == i) +if (ret)return 1 ;else return 0 ;
Greg Kroah-Hartman
maintainerPATCH 381/496 cxgb4: Setup FW queues before registering netdev
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arjun Vynipadath <[email protected]>
[ Upstream commit 843bd7db79c861b49e2912d723625f5fa8e94502 ]
When NetworkManager is enabled, there are chances that interface up is called even before probe completes. This means we have not yet allocated the FW sge queues, hence rest of ingress queue allocation wont be proper. Fix this by calling setup_fw_sge_queues() before register_netdev().
--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +8 -3
@@ -815,8 +815,6 @@ static int setup_fw_sge_queues(struct ad err =t4_sge_alloc_rxq (adap, &s->fw_evtq, true, adap->port[0 ], adap->msi_idx,NULL , fwevtq_handler,NULL ,-1 ); -if (err) -t4_free_sge_resources (adap);return err; }
@@ -5116,6 +5114,13 @@ static int init_one(struct pci_dev *pdevif (err) goto out_free_dev; + err =setup_fw_sge_queues (adapter); +if (err) { +dev_err (adapter->pdev_dev, +"FW sge queue allocation failed, err %d" , err); + goto out_free_dev; + } +/* * The card is now ready to go. If any errors occur during device * registration we do not fail the whole card but rather proceed only
@@ -5164,7 +5169,6 @@ static int init_one(struct pci_dev *pdevcxgb4_ptp_init (adapter);print_adapter_info (adapter); -setup_fw_sge_queues (adapter);return 0 ; sriov:
@@ -5220,6 +5224,7 @@ free_mbox_log:#endif out_free_dev: +t4_free_sge_resources (adapter);free_some_resources (adapter);if (adapter->flags &USING_MSIX )free_msix_info (adapter);
Greg Kroah-Hartman
maintainerPATCH 382/496 ima: Fix Kconfig to select TPM 2.0 CRB interface
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiandi An <[email protected]>
[ Upstream commit fac37c628fd5d68fd7298d9b57ae8601ee1b4723 ]
TPM_CRB driver provides TPM CRB 2.0 support. If it is built as a module, the TPM chip is registered after IMA init. tpm_pcr_read() in IMA fails and displays the following message even though eventually there is a TPM chip on the system.
ima: No TPM chip found, activating TPM-bypass! (rc=-19)
Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is built in the kernel and initializes before IMA.
--- security/integrity/ima/Kconfig | 1 + 1 file changed, 1 insertion(+)
security/integrity/ima/Kconfig +1 -0
@@ -10,6 +10,7 @@ config IMA select CRYPTO_HASH_INFO select TCG_TPM if HAS_IOMEM && !UML select TCG_TIS if TCG_TPM && X86 + select TCG_CRB if TCG_TPM && ACPI select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES help The Trusted Computing Group(TCG) runtime Integrity
Greg Kroah-Hartman
maintainerPATCH 383/496 ima: Fallback to the builtin hash algorithm
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Petr Vorel <[email protected]>
[ Upstream commit ab60368ab6a452466885ef4edf0cefd089465132 ]
IMA requires having it's hash algorithm be compiled-in due to it's early use. The default IMA algorithm is protected by Kconfig to be compiled-in.
The ima_hash kernel parameter allows to choose the hash algorithm. When the specified algorithm is not available or available as a module, IMA initialization fails, which leads to a kernel panic (mknodat syscall calls ima_post_path_mknod()). Therefore as fallback we force IMA to use the default builtin Kconfig hash algorithm.
Fixed crash:
$ grep CONFIG_CRYPTO_MD4 .config CONFIG_CRYPTO_MD4=m
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=74ae8202-9ca7-4e39-813b-22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4 ... [ 1.545190] ima: Can not allocate md4 (reason: -2) ... [ 2.610120] BUG: unable to handle kernel NULL pointer dereference at (null) [ 2.611903] IP: ima_match_policy+0x23/0x390 [ 2.612967] PGD 0 P4D 0 [ 2.613080] Oops: 0000 [#1] SMP [ 2.613080] Modules linked in: autofs4 [ 2.613080] Supported: Yes [ 2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1 [ 2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 [ 2.613080] task: ffff88003e2d0040 task.stack: ffffc90000190000 [ 2.613080] RIP: 0010:ima_match_policy+0x23/0x390 [ 2.613080] RSP: 0018:ffffc90000193e88 EFLAGS: 00010296 [ 2.613080] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000004 [ 2.613080] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffff880037071728 [ 2.613080] RBP: 0000000000008000 R08: 0000000000000000 R09: 0000000000000000 [ 2.613080] R10: 0000000000000008 R11: 61c8864680b583eb R12: 00005580ff10086f [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000008000 [ 2.613080] FS: 00007f5c1da08940(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 2.613080] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.613080] CR2: 0000000000000000 CR3: 0000000037002000 CR4: 00000000003406f0 [ 2.613080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.613080] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.613080] Call Trace: [ 2.613080] ? shmem_mknod+0xbf/0xd0 [ 2.613080] ima_post_path_mknod+0x1c/0x40 [ 2.613080] SyS_mknod+0x210/0x220 [ 2.613080] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 2.613080] RIP: 0033:0x7f5c1bfde570 [ 2.613080] RSP: 002b:00007ffde1c90dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000085 [ 2.613080] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c1bfde570 [ 2.613080] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00005580ff10086f [ 2.613080] RBP: 00007ffde1c91040 R08: 00005580ff10086f R09: 0000000000000000 [ 2.613080] R10: 0000000000104000 R11: 0000000000000246 R12: 00005580ffb99660 [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002 [ 2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20 [ 2.613080] RIP: ima_match_policy+0x23/0x390 RSP: ffffc90000193e88 [ 2.613080] CR2: 0000000000000000 [ 2.613080] ---[ end trace 9a9f0a8a73079f6a ]--- [ 2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.673052] [ 2.675337] Kernel Offset: disabled [ 2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
--- security/integrity/ima/ima_crypto.c | 2 ++ security/integrity/ima/ima_main.c | 13 +++++++++++++ 2 files changed, 15 insertions(+)
security/integrity/ima/ima_crypto.c +2 -0
@@ -78,6 +78,8 @@ int __init ima_init_crypto(void) hash_algo_name[ima_hash_algo], rc);return rc; } +pr_info ("Allocated hash algorithm: %s\n" , + hash_algo_name[ima_hash_algo]);return 0 ; }
security/integrity/ima/ima_main.c +13 -0
@@ -16,6 +16,9 @@* implements the IMA hooks: ima_bprm_check, ima_file_mmap, * and ima_file_check. */ + +#define pr_fmt (fmt) KBUILD_MODNAME ": " fmt +#include <linux/module.h> #include <linux/file.h> #include <linux/binfmts.h>
@@ -427,6 +430,16 @@ static int __init init_ima(void)ima_init_template_list ();hash_setup (CONFIG_IMA_DEFAULT_HASH ); error =ima_init (); + +if (error &&strcmp (hash_algo_name[ima_hash_algo], +CONFIG_IMA_DEFAULT_HASH ) !=0 ) { +pr_info ("Allocating %s failed, going to use default hash algorithm %s\n" , + hash_algo_name[ima_hash_algo],CONFIG_IMA_DEFAULT_HASH ); + hash_setup_done =0 ; +hash_setup (CONFIG_IMA_DEFAULT_HASH ); + error =ima_init (); + } +if (!error) { ima_initialized =1 ;ima_update_policy_flag ();
Greg Kroah-Hartman
maintainerPATCH 384/496 watchdog: aspeed: Allow configuring for alternate boot
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milton Miller <[email protected]>
[ Upstream commit 6ffa3402211acc30e47e691e14d62f3fd065a54e ]
Allow the device tree to specify a watchdog to fallover to the alternate boot source.
The aspeeed watchdog can set a latch directing flash chip select 0 to chip select 1, allowing boot from an alternate media if the watchdog is not reset in time. On the ast2400 bank 1 also goes to flash bank 1, while on the ast2500 the chip selects are swapped.
Also clear the secondary boot bit during the machine restart operation. Otherwise, the system will switch to the alternate boot after every reboot, which is not desired.
--- drivers/watchdog/aspeed_wdt.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/watchdog/aspeed_wdt.c +4 -0
@@ -46,6 +46,7 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_ta#define WDT_RELOAD_VALUE 0x04#define WDT_RESTART 0x08#define WDT_CTRL 0x0C +#define WDT_CTRL_BOOT_SECONDARY BIT(7)#define WDT_CTRL_RESET_MODE_SOC (0x00 << 5)#define WDT_CTRL_RESET_MODE_FULL_CHIP (0x01 << 5)#define WDT_CTRL_RESET_MODE_ARM_CPU (0x10 << 5)
@@ -158,6 +159,7 @@ static int aspeed_wdt_restart(struct wat {struct aspeed_wdt *wdt =to_aspeed_wdt (wdd); + wdt->ctrl &= ~WDT_CTRL_BOOT_SECONDARY ;aspeed_wdt_enable (wdt,128 *WDT_RATE_1MHZ /1000 );mdelay (1000 );
@@ -242,6 +244,8 @@ static int aspeed_wdt_probe(struct platf }if (of_property_read_bool (np,"aspeed,external-signal" )) wdt->ctrl |=WDT_CTRL_WDT_EXT ; +if (of_property_read_bool (np,"aspeed,alt-boot" )) + wdt->ctrl |=WDT_CTRL_BOOT_SECONDARY ;writel (wdt->ctrl, wdt->base +WDT_CTRL );
Greg Kroah-Hartman
maintainerPATCH 385/496 virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Vosburgh <[email protected]>
[ Upstream commit bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ]
The operstate update logic will leave an interface in the default UNKNOWN operstate if the interface carrier state never changes from the default carrier up state set at creation. This includes the case of an explicit call to netif_carrier_on, as the carrier on to on transition has no effect on operstate.
This affects virtio-net for the case that the virtio peer does
not support VIRTIO_NET_F_STATUS (the feature that provides carrier state updates). Without this feature, the virtio specification states that "the link should be assumed active," so, logically, the operstate should be UP instead of UNKNOWN. This has impact on user space applications that use the operstate to make availability decisions for the interface.
Resolve this by changing the virtio probe logic slightly to callnetif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS cases, and then the existing call to netif_carrier_on for the "without" case will cause an operstate transition.
--- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/virtio_net.c +1 -1
@@ -2655,8 +2655,8 @@ static int virtnet_probe(struct virtio_d/* Assume link up if device can't report link status, otherwise get link status from config. */ +netif_carrier_off (dev);if (virtio_has_feature (vi->vdev,VIRTIO_NET_F_STATUS )) { -netif_carrier_off (dev);schedule_work (&vi->config_work); }else { vi->status =VIRTIO_NET_S_LINK_UP ;
Greg Kroah-Hartman
maintainerPATCH 386/496 arm: dts: socfpga: fix GIC PPI warning
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philipp Puschmann <[email protected]>
[ Upstream commit 6d97d5aba08b26108f95dc9fb7bbe4d9436c769c ]
Fixes the warning "GIC: PPI13 is secure or misconfigured" by changing the interrupt type from level_low to edge_raising
--- arch/arm/boot/dts/socfpga.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/socfpga.dtsi +1 -1
@@ -827,7 +827,7 @@ timer@fffec600 { compatible = "arm,cortex-a9-twd-timer"; reg = <0xfffec600 0x100>; - interrupts = <1 13 0xf04>; + interrupts = <1 13 0xf01>; clocks = <&mpu_periph_clk>; };
Greg Kroah-Hartman
maintainerPATCH 387/496 ext4: dont complain about incorrect features when probing
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Sandeen <[email protected]>
[ Upstream commit 0d9366d67bcf066b028e57d09c9a86ce879bcc28 ]
If mount is auto-probing for filesystem type, it will try various filesystems in order, with the MS_SILENT flag set. We get that flag as the silent arg to ext4_fill_super.
If we're probing (silent==1) then don't complain about feature incompatibilities that are found if it looks like it's actually a different valid extN type - failed probes should be silent in this case.
If the on-disk features are unknown even to ext4, then complain.
--- fs/ext4/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
fs/ext4/super.c +12 -0
@@ -3663,6 +3663,12 @@ static int ext4_fill_super(struct super_ext4_msg (sb,KERN_INFO ,"mounting ext2 file system " "using the ext4 subsystem" ); else { +/* +* If we're probing be silent, if this looks like +* it's actually an ext[34] filesystem. +*/ +if (silent &&ext4_feature_set_ok (sb,sb_rdonly (sb))) + goto failed_mount;ext4_msg (sb,KERN_ERR ,"couldn't mount as ext2 due " "to feature incompatibilities" ); goto failed_mount;
@@ -3674,6 +3680,12 @@ static int ext4_fill_super(struct super_ext4_msg (sb,KERN_INFO ,"mounting ext3 file system " "using the ext4 subsystem" ); else { +/* +* If we're probing be silent, if this looks like +* it's actually an ext4 filesystem. +*/ +if (silent &&ext4_feature_set_ok (sb,sb_rdonly (sb))) + goto failed_mount;ext4_msg (sb,KERN_ERR ,"couldn't mount as ext3 due " "to feature incompatibilities" ); goto failed_mount;
Greg Kroah-Hartman
maintainerPATCH 388/496 drm/vmwgfx: Unpin the screen object backup buffer when not used
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellstrom <[email protected]>
[ Upstream commit 20fb5a635a0c8478ac98f15cfafc2ea83df29565 ]
We were relying on the pinned screen object backup buffer to be destroyed when not used. But if we hold a copy of the atomic state, like when hibernating, the backup buffer might not be destroyed since it's refcounted by the atomic state. This causes us to hibernate with a buffer pinned in VRAM.
Fix this by only having the buffer pinned when it is actually used by a screen object.
--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +21 -8
@@ -453,7 +453,11 @@ vmw_sou_primary_plane_cleanup_fb(struct struct drm_plane_state *old_state) {struct vmw_plane_state *vps =vmw_plane_state_to_vps (old_state); +struct drm_crtc *crtc = plane->state->crtc ? + plane->state->crtc : old_state->crtc; +if (vps->dmabuf) +vmw_dmabuf_unpin (vmw_priv (crtc->dev), vps->dmabuf, false);vmw_dmabuf_unreference (&vps->dmabuf); vps->dmabuf_size =0 ;
@@ -491,10 +495,17 @@ vmw_sou_primary_plane_prepare_fb(struct } size = new_state->crtc_w * new_state->crtc_h *4 ; + dev_priv =vmw_priv (crtc->dev);if (vps->dmabuf) { -if (vps->dmabuf_size == size) -return 0 ; +if (vps->dmabuf_size == size) { +/* +* Note that this might temporarily up the pin-count +* to 2, until cleanup_fb() is called. +*/ +return vmw_dmabuf_pin_in_vram (dev_priv, vps->dmabuf, + true); + }vmw_dmabuf_unreference (&vps->dmabuf); vps->dmabuf_size =0 ;
@@ -504,7 +515,6 @@ vmw_sou_primary_plane_prepare_fb(structif (!vps->dmabuf)return -ENOMEM ; - dev_priv =vmw_priv (crtc->dev);vmw_svga_enable (dev_priv);/* After we have alloced the backing store might not be able to
@@ -515,13 +525,16 @@ vmw_sou_primary_plane_prepare_fb(struct &vmw_vram_ne_placement, false, &vmw_dmabuf_bo_free);vmw_overlay_resume_all (dev_priv); - -if (ret !=0 ) +if (ret) { vps->dmabuf =NULL ;/* vmw_dmabuf_init frees on error */ -else - vps->dmabuf_size = size; +return ret; + } -return ret; +/* +* TTM already thinks the buffer is pinned, but make sure the +* pin_count is upped. +*/ +return vmw_dmabuf_pin_in_vram (dev_priv, vps->dmabuf, true); }
Greg Kroah-Hartman
maintainerPATCH 389/496 iommu/mediatek: Fix protect memory setting
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong Wu <[email protected]>
[ Upstream commit 70ca608b2ec6dafa6bb1c2b0691852fc78f8f717 ]
In MediaTek's IOMMU design, When a iommu translation fault occurs (HW can NOT translate the destination address to a valid physical address), the IOMMU HW output the dirty data into a special memory to avoid corrupting the main memory, this is called "protect memory". the register(0x114) for protect memory is a little different between mt8173 and mt2712.
In the mt8173, bit[30:6] in the register represents [31:7] of the physical address. In the 4GB mode, the register bit[31] should be 1. While in the mt2712, the bits don't shift. bit[31:7] in the register represents [31:7] in the physical address, and bit[1:0] in the register represents bit[33:32] of the physical address if it has.
--- drivers/iommu/mtk_iommu.c | 15 ++++++++++----- drivers/iommu/mtk_iommu.h | 1 + 2 files changed, 11 insertions(+), 5 deletions(-)
drivers/iommu/mtk_iommu.c +10 -5
@@ -60,7 +60,7 @@ (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))#define REG_MMU_IVRP_PADDR 0x114 -#define F_MMU_IVRP_PA_SET (pa, ext) (((pa) >> 1) | ((!!(ext)) << 31)) +#define REG_MMU_VLD_PA_RNG 0x118#define F_MMU_VLD_PA_RNG (EA ,SA ) (((EA) << 8) | (SA))
@@ -532,8 +532,13 @@ static int mtk_iommu_hw_init(const strucF_INT_PRETETCH_TRANSATION_FIFO_FAULT ;writel_relaxed (regval, data->base +REG_MMU_INT_MAIN_CONTROL ); -writel_relaxed (F_MMU_IVRP_PA_SET (data->protect_base, data->enable_4GB), - data->base +REG_MMU_IVRP_PADDR ); +if (data->m4u_plat ==M4U_MT8173 ) + regval = (data->protect_base >>1 ) | (data->enable_4GB <<31 ); +else + regval =lower_32_bits (data->protect_base) | +upper_32_bits (data->protect_base); +writel_relaxed (regval, data->base +REG_MMU_IVRP_PADDR ); +if (data->enable_4GB && data->m4u_plat !=M4U_MT8173 ) {/* * If 4GB mode is enabled, the validate PA range is from
@@ -688,6 +693,7 @@ static int __maybe_unused mtk_iommu_susp reg->ctrl_reg =readl_relaxed (base +REG_MMU_CTRL_REG ); reg->int_control0 =readl_relaxed (base +REG_MMU_INT_CONTROL0 ); reg->int_main_control =readl_relaxed (base +REG_MMU_INT_MAIN_CONTROL ); + reg->ivrp_paddr =readl_relaxed (base +REG_MMU_IVRP_PADDR );clk_disable_unprepare (data->bclk);return 0 ; }
@@ -710,8 +716,7 @@ static int __maybe_unused mtk_iommu_resuwritel_relaxed (reg->ctrl_reg, base +REG_MMU_CTRL_REG );writel_relaxed (reg->int_control0, base +REG_MMU_INT_CONTROL0 );writel_relaxed (reg->int_main_control, base +REG_MMU_INT_MAIN_CONTROL ); -writel_relaxed (F_MMU_IVRP_PA_SET (data->protect_base, data->enable_4GB), - base +REG_MMU_IVRP_PADDR ); +writel_relaxed (reg->ivrp_paddr, base +REG_MMU_IVRP_PADDR );if (data->m4u_dom)writel (data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0 ], base +REG_MMU_PT_BASE_ADDR );
drivers/iommu/mtk_iommu.h +1 -0
@@ -32,6 +32,7 @@ struct mtk_iommu_suspend_reg {u32 ctrl_reg;u32 int_control0;u32 int_main_control; +u32 ivrp_paddr; };enum mtk_iommu_plat {
Greg Kroah-Hartman
maintainerPATCH 390/496 cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chunyu Hu <[email protected]>
[ Upstream commit 55b55abc17f238c61921360e61dde90dd9a326d1 ]
Kmemleak reported the below leak. When cppc_cpufreq_init went into failure path, the cpu mask is not freed. After fix, this report is gone. And to avaoid potential NULL pointer reference, check the cpu value first.
unreferenced object 0xffff800fd5ea4880 (size 128):
comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s) hex dump (first 32 bytes):
00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffff0000082c4ae4>] __kmalloc_node+0x278/0x634
[<ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60
[<ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c
[<ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c
[<ffff000008083828>] do_one_initcall+0xec/0x15c
[<ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4
[<ffff0000089099b0>] kernel_init+0x18/0x10c
[<ffff000008084d50>] ret_from_fork+0x10/0x18
[<ffffffffffffffff>] 0xffffffffffffffff--- drivers/cpufreq/cppc_cpufreq.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/cpufreq/cppc_cpufreq.c +7 -2
@@ -243,8 +243,13 @@ static int __init cppc_cpufreq_init(voidreturn ret; out: -for_each_possible_cpu (i) -kfree (all_cpu_data[i]); +for_each_possible_cpu (i) { + cpu = all_cpu_data[i]; +if (!cpu) +break ; +free_cpumask_var (cpu->shared_cpu_map); +kfree (cpu); + }kfree (all_cpu_data);return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 391/496 IB/mlx5: Set the default active rate and width to QDR and 4X
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Honggang Li <[email protected]>
[ Upstream commit 7672ed33c4c15dbe9d56880683baaba4227cf940 ]
Before commit f1b65df5a232 ("IB/mlx5: Add support for active_width and active_speed in RoCE"), the mlx5_ib driver set the default active_width and active_speed to IB_WIDTH_4X and IB_SPEED_QDR.
When the RoCE port is down, the RoCE port does not negotiate the active width with the remote side, causing the active width to be zero. When running userspace ibstat to view the port status, ibstat will panic as it reads an invalid width from sys file.
This patch restores the original behavior.
--- drivers/infiniband/hw/mlx5/main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/infiniband/hw/mlx5/main.c +3 -0
@@ -270,6 +270,9 @@ static int mlx5_query_port_roce(struct iif (err)return err; + props->active_width =IB_WIDTH_4X ; + props->active_speed =IB_SPEED_QDR ; +translate_eth_proto_oper (eth_prot_oper, &props->active_speed, &props->active_width);
Greg Kroah-Hartman
maintainerPATCH 392/496 zorro: Set up z->dev.dma_mask for the DMA API
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Schmitz <[email protected]>
[ Upstream commit 55496d3fe2acd1a365c43cbd613a20ecd4d74395 ]
The generic DMA API uses dev->dma_mask to check the DMA addressable memory bitmask, and warns if no mask is set or even allocated.
Set z->dev.dma_coherent_mask on Zorro bus scan, and make z->dev.dma_mask to point to z->dev.dma_coherent_mask so device drivers that need DMA have everything set up to avoid warnings from dma_alloc_coherent(). Drivers can still use dma_set_mask_and_coherent() to explicitly set their DMA bit mask.
--- drivers/zorro/zorro.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/zorro/zorro.c +12 -0
@@ -16,6 +16,7 @@#include <linux/bitops.h> #include <linux/string.h> #include <linux/platform_device.h> +#include <linux/dma-mapping.h> #include <linux/slab.h> #include <asm/byteorder.h>
@@ -185,6 +186,17 @@ static int __init amiga_zorro_probe(stru z->dev.parent = &bus->dev; z->dev.bus = &zorro_bus_type; z->dev.id = i; +switch (z->rom.er_Type &ERT_TYPEMASK ) { +case ERT_ZORROIII : + z->dev.coherent_dma_mask =DMA_BIT_MASK (32 ); +break ; + +case ERT_ZORROII : +default : + z->dev.coherent_dma_mask =DMA_BIT_MASK (24 ); +break ; + } + z->dev.dma_mask = &z->dev.coherent_dma_mask; }/* ... then register them */
Greg Kroah-Hartman
maintainerPATCH 393/496 bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Coly Li <[email protected]>
[ Upstream commit fadd94e05c02afec7b70b0b14915624f1782f578 ]
In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", cached_dev_get() is called when creating dc->writeback_thread, and cached_dev_put() is called when exiting dc->writeback_thread. This modification works well unless people detach the bcache device manually by
'echo 1 > /sys/block/bcache<N>/bcache/detach'
Because this sysfs interface only calls bch_cached_dev_detach() which wakes up dc->writeback_thread but does not stop it. The reason is, before patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", inside bch_writeback_thread(), if cache is not dirty after writeback, cached_dev_put() will be called here. And in cached_dev_make_request() when a new write request makes cache from clean to dirty, cached_dev_get() will be called there. Since we don't operate dc->count in these locations, refcount d->count cannot be dropped after cache becomes clean, and cached_dev_detach_finish() won't be called to detach bcache device.
This patch fixes the issue by checking whether BCACHE_DEV_DETACHING is set inside bch_writeback_thread(). If this bit is set and cache is clean (no existing writeback_keys), break the while-loop, call cached_dev_put() and quit the writeback thread.
Please note if cache is still dirty, even BCACHE_DEV_DETACHING is set the writeback thread should continue to perform writeback, this is the original design of manually detach.
It is safe to do the following check without locking, let me explain why,
+ if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
+ (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) {
If the kenrel thread does not sleep and continue to run due to conditions are not updated in time on the running CPU core, it just consumes more CPU cycles and has no hurt. This should-sleep-but-run is safe here. We just focus on the should-run-but-sleep condition, which means the writeback thread goes to sleep in mistake while it should continue to run. 1, First of all, no matter the writeback thread is hung or not,
kthread_stop() from cached_dev_detach_finish() will wake up it and terminate by making kthread_should_stop() return true. And in normal run time, bit on index BCACHE_DEV_DETACHING is always cleared, the condition
!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags)
is always true and can be ignored as constant value.
2, If one of the following conditions is true, the writeback thread should
go to sleep,
"!atomic_read(&dc->has_dirty)" or "!dc->writeback_running)" each of them independently controls the writeback thread should sleep or not, let's analyse them one by one.
2.1 condition "!atomic_read(&dc->has_dirty)"
If dc->has_dirty is set from 0 to 1 on another CPU core, bcache will call bch_writeback_queue() immediately or call bch_writeback_add() which indirectly calls bch_writeback_queue() too. In bch_writeback_queue(), wake_up_process(dc->writeback_thread) is called. It sets writeback thread's task state to TASK_RUNNING and following an implicit memory barrier, then tries to wake up the writeback thread.
In writeback thread, its task state is set to TASK_INTERRUPTIBLE before doing the condition check. If other CPU core sets the TASK_RUNNING state after writeback thread setting TASK_INTERRUPTIBLE, the writeback thread will be scheduled to run very soon because its state is not TASK_INTERRUPTIBLE. If other CPU core sets the TASK_RUNNING state before writeback thread setting TASK_INTERRUPTIBLE, the implict memory barrier of wake_up_process() will make sure modification of dc->has_dirty on other CPU core is updated and observed on the CPU core of writeback thread. Therefore the condition check will correctly be false, and continue writeback code without sleeping.
2.2 condition "!dc->writeback_running)"
dc->writeback_running can be changed via sysfs file, every time it is modified, a following bch_writeback_queue() is alwasy called. So the change is always observed on the CPU core of writeback thread. If dc->writeback_running is changed from 0 to 1 on other CPU core, this condition check will observe the modification and allow writeback thread to continue to run without sleeping.
Now we can see, even without a locking protection, multiple conditions check is safe here, no deadlock or process hang up will happen.
I compose a separte patch because that patch "bcache: fix cached_dev->count usage for bch_cache_set_error()" already gets a "Reviewed-by:" from Hannes Reinecke. Also this fix is not trivial and good for a separate patch.
--- drivers/md/bcache/writeback.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
drivers/md/bcache/writeback.c +17 -3
@@ -421,9 +421,15 @@ static int bch_writeback_thread(void *arwhile (!kthread_should_stop ()) {down_write (&dc->writeback_lock);set_current_state (TASK_INTERRUPTIBLE ); -if (!atomic_read (&dc->has_dirty) || - (!test_bit (BCACHE_DEV_DETACHING , &dc->disk.flags) && - !dc->writeback_running)) { +/* +* If the bache device is detaching, skip here and continue +* to perform writeback. Otherwise, if no dirty data on cache, +* or there is dirty data on cache but writeback is disabled, +* the writeback thread should sleep here and wait for others +* to wake up it. +*/ +if (!test_bit (BCACHE_DEV_DETACHING , &dc->disk.flags) && + (!atomic_read (&dc->has_dirty) || !dc->writeback_running)) {up_write (&dc->writeback_lock);if (kthread_should_stop ()) {
@@ -444,6 +450,14 @@ static int bch_writeback_thread(void *arcached_dev_put (dc);SET_BDEV_STATE (&dc->sb,BDEV_STATE_CLEAN );bch_write_bdev_super (dc,NULL ); +/* +* If bcache device is detaching via sysfs interface, +* writeback thread should stop after there is no dirty +* data on cache. BCACHE_DEV_DETACHING flag is set in +* bch_cached_dev_detach(). +*/ +if (test_bit (BCACHE_DEV_DETACHING , &dc->disk.flags)) +break ; }up_write (&dc->writeback_lock);
Greg Kroah-Hartman
maintainerPATCH 394/496 remoteproc: imx_rproc: Fix an error handling path in imx_rproc_probe()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit de6f83f85be94e0b7d0d324c29ccc9d78a6bb4e7 ]
If 'of_device_get_match_data()' fails, we must undo the previous 'rproc_alloc()' call.
--- drivers/remoteproc/imx_rproc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/remoteproc/imx_rproc.c +4 -2
@@ -339,8 +339,10 @@ static int imx_rproc_probe(struct platfo } dcfg =of_device_get_match_data (dev); -if (!dcfg) -return -EINVAL ; +if (!dcfg) { + ret = -EINVAL ; + goto err_put_rproc; + } priv = rproc->priv; priv->rproc = rproc;
Greg Kroah-Hartman
maintainerPATCH 395/496 dt-bindings: add device tree binding for Allwinner H6 main CCU
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <[email protected]>
[ Upstream commit 2e08e4d2ff488424919d69dd211ac860a019ac1d ]
The Allwinner H6 main CCU uses the internal oscillator of the SoC, which is different with old SoCs' main CCU.
Add device tree binding for the Allwinner H6 main CCU.
--- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/devicetree/bindings/clock/sunxi-ccu.txt +4 -0
@@ -20,6 +20,7 @@ Required properties : - "allwinner,sun50i-a64-ccu" - "allwinner,sun50i-a64-r-ccu" - "allwinner,sun50i-h5-ccu" + - "allwinner,sun50i-h6-ccu" - "nextthing,gr8-ccu" - reg: Must contain the registers base address and length
@@ -31,6 +32,9 @@ Required properties : - #clock-cells : must contain 1 - #reset-cells : must contain 1 +For the main CCU on H6, one more clock is needed: +- "iosc": the SoC's internal frequency oscillator + For the PRCM CCUs on A83T/H3/A64, two more clocks are needed: - "pll-periph": the SoC's peripheral PLL from the main CCU - "iosc": the SoC's internal frequency oscillator
Greg Kroah-Hartman
maintainerPATCH 396/496 ACPICA: Events: add a return on failure from acpi_hw_register_read
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erik Schmauss <[email protected]>
[ Upstream commit b4c0de312613ca676db5bd7e696a44b56795612a ]
This ensures that acpi_ev_fixed_event_detect() does not use fixed_status and and fixed_enable as uninitialized variables.
--- drivers/acpi/acpica/evevent.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/acpi/acpica/evevent.c +7 -2
@@ -204,6 +204,7 @@ u32 acpi_ev_fixed_event_detect(void)u32 fixed_status;u32 fixed_enable;u32 i; +acpi_status status;ACPI_FUNCTION_NAME (ev_fixed_event_detect);
@@ -211,8 +212,12 @@ u32 acpi_ev_fixed_event_detect(void)* Read the fixed feature status and enable registers, as all the cases * depend on their values. Ignore errors here. */ - (void )acpi_hw_register_read (ACPI_REGISTER_PM1_STATUS , &fixed_status); - (void )acpi_hw_register_read (ACPI_REGISTER_PM1_ENABLE , &fixed_enable); + status =acpi_hw_register_read (ACPI_REGISTER_PM1_STATUS , &fixed_status); + status |= +acpi_hw_register_read (ACPI_REGISTER_PM1_ENABLE , &fixed_enable); +if (ACPI_FAILURE (status)) { +return (int_status); + } ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS, "Fixed Event Block: Enable %08X Status %08X\n",
Greg Kroah-Hartman
maintainerPATCH 397/496 ACPICA: Fix memory leak on unusual memory leak
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Moore <[email protected]>
[ Upstream commit 1c29c372b2d1d2415601041532745ce859f24126 ]
Fixes a single-object memory leak on a store-to-reference method invocation. ACPICA BZ 1439.
--- drivers/acpi/acpica/psargs.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/acpi/acpica/psargs.c +4 -0
@@ -890,6 +890,10 @@ acpi_ps_get_next_arg(struct acpi_walk_st ACPI_POSSIBLE_METHOD_CALL);if (arg->common.aml_opcode ==AML_INT_METHODCALL_OP ) { + +/* Free method call op and corresponding namestring sub-ob */ + +acpi_ps_free_op (arg->common.value.arg);acpi_ps_free_op (arg); arg =NULL ; walk_state->arg_count =1 ;
Greg Kroah-Hartman
maintainerPATCH 398/496 ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Seunghun Han <[email protected]>
[ Upstream commit 97f3c0a4b0579b646b6b10ae5a3d59f0441cc12c ]
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
Quoted 36 lines
[ 0.464168] ACPI: Added _OSI(Module Device) [ 0.467022] ACPI: Added _OSI(Processor Device) [ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.471647] ACPI: Added _OSI(Processor Aggregator Device) [ 0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) [ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) [ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) [ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543) [ 0.497683] ACPI: Interpreter enabled [ 0.499385] ACPI: (supports S0) [ 0.501151] ACPI: Using IOAPIC for interrupt routing [ 0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) [ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) [ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) [ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543) [ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991) [ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects [ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 [ 0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.529668] Call Trace: [ 0.530811] ? dump_stack+0x5c/0x81 [ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.533905] ? acpi_os_delete_cache+0xa/0x10 [ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b [ 0.537237] ? acpi_terminate+0xa/0x14 [ 0.538701] ? acpi_init+0x2af/0x34f [ 0.540008] ? acpi_sleep_proc_init+0x27/0x27 [ 0.541593] ? do_one_initcall+0x4e/0x1a0 [ 0.543008] ? kernel_init_freeable+0x19e/0x21f [ 0.546202] ? rest_init+0x80/0x80 [ 0.547513] ? kernel_init+0xa/0x100 [ 0.548817] ? ret_from_fork+0x25/0x30 [ 0.550587] vgaarb: loaded [ 0.551716] EDAC MC: Ver: 3.0.0 [ 0.553744] PCI: Probing PCI hardware [ 0.555038] PCI host bridge to bus 0000:00
Quoted 1 line
... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ns_evaluate() function only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is also not null. Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
--- drivers/acpi/acpica/nseval.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/acpi/acpica/nseval.c +8 -0
@@ -308,6 +308,14 @@ acpi_status acpi_ns_evaluate(struct acpi/* Map AE_CTRL_RETURN_VALUE to AE_OK, we are done with it */ status =AE_OK ; + }else if (ACPI_FAILURE (status)) { + +/* If return_object exists, delete it */ + +if (info->return_object) { +acpi_ut_remove_reference (info->return_object); + info->return_object =NULL ; + } } ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
Greg Kroah-Hartman
maintainerPATCH 399/496 cxgb4: Fix queue free path of ULD drivers
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arjun Vynipadath <[email protected]>
[ Upstream commit d7cb44496a9bb458632cb3c18acb08949c210448 ]
Setting sge_uld_rxq_info to NULL in free_queues_uld(). We are referencing sge_uld_rxq_info in cxgb_up(). This will fix a panic when interface is brought up after a ULDq creation failure.
of resources for ULD)
--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c +1 -0
@@ -342,6 +342,7 @@ static void free_queues_uld(struct adapt {struct sge_uld_rxq_info *rxq_info = adap->sge.uld_rxq_info[uld_type]; + adap->sge.uld_rxq_info[uld_type] =NULL ;kfree (rxq_info->rspq_id);kfree (rxq_info->uldrxq);kfree (rxq_info);
Greg Kroah-Hartman
maintainerPATCH 400/496 i2c: mv64xxx: Apply errata delay only in standard mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gregory CLEMENT <[email protected]>
[ Upstream commit 31184d8c6ea49ea0676d100cdd7e1f102ad025b5 ]
The errata FE-8471889 description has been updated. There is still a timing violation for repeated start. But the errata now states that it was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz) there is no issue.
This patch limit the errata fix to the Standard mode.
It has been tesed successfully on the clearfog (Aramda 388 based board).
--- drivers/i2c/busses/i2c-mv64xxx.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-mv64xxx.c +6 -2
@@ -844,12 +844,16 @@ mv64xxx_of_config(struct mv64xxx_i2c_dat*/ if (of_device_is_compatible (np,"marvell,mv78230-i2c" )) { drv_data->offload_enabled = true; - drv_data->errata_delay = true; +/* The delay is only needed in standard mode (100kHz) */ +if (bus_freq <=100000 ) + drv_data->errata_delay = true; }if (of_device_is_compatible (np,"marvell,mv78230-a0-i2c" )) { drv_data->offload_enabled = false; - drv_data->errata_delay = true; +/* The delay is only needed in standard mode (100kHz) */ +if (bus_freq <=100000 ) + drv_data->errata_delay = true; }if (of_device_is_compatible (np,"allwinner,sun6i-a31-i2c" ))
Greg Kroah-Hartman
maintainerPATCH 402/496 perf top: Fix top.call-graph config option reading
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yisheng Xie <[email protected]>
[ Upstream commit a3a4a3b37c9b911af4c375b2475cea0fd2b84d38 ]
When trying to add the "call-graph" variable for top into the .perfconfig file, like:
[top]
call-graph = fp
I that perf_top_config() do not parse this variable.
Fix it by calling perf_default_config() when the top.call-graph variable is set.
--- tools/perf/builtin-top.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
tools/perf/builtin-top.c +4 -2
@@ -1080,8 +1080,10 @@ parse_callchain_opt(const struct optionstatic int perf_top_config (const char *var,const char *value,void *cb__maybe_unused ) { -if (!strcmp (var,"top.call-graph" )) - var ="call-graph.record-mode" ;/* fall-through */ +if (!strcmp (var,"top.call-graph" )) { + var ="call-graph.record-mode" ; +return perf_default_config (var, value, cb); + }if (!strcmp (var,"top.children" )) { symbol_conf.cumulate_callchain =perf_config_bool (var, value);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 403/496 perf stat: Fix core dump when flag T is used
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Richter <[email protected]>
[ Upstream commit fca32340a5e8b896f57d41fd94b8b1701df25eb1 ]
Executing command 'perf stat -T -- ls' dumps core on x86 and s390.
Here is the call back chain (done on x86):
# gdb ./perf
....
(gdb) r stat -T -- ls
...
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6
(gdb) where
#0 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6
#1 0x00007ffff56ae484 in asprintf () from /lib64/libc.so.6
#2 0x00000000004f1982 in __parse_events_add_pmu (parse_state=0x7fffffffd580,
list=0xbfb970, name=0xbf3ef0 "cpu",
head_config=0xbfb930, auto_merge_stats=false) at util/parse-events.c:1233
#3 0x00000000004f1c8e in parse_events_add_pmu (parse_state=0x7fffffffd580,
list=0xbfb970, name=0xbf3ef0 "cpu",
head_config=0xbfb930) at util/parse-events.c:1288
#4 0x0000000000537ce3 in parse_events_parse (_parse_state=0x7fffffffd580,
scanner=0xbf4210) at util/parse-events.y:234
#5 0x00000000004f2c7a in parse_events__scanner (str=0x6b66c0
"task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}",
parse_state=0x7fffffffd580, start_token=258) at util/parse-events.c:1673
#6 0x00000000004f2e23 in parse_events (evlist=0xbe9990, str=0x6b66c0
"task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", err=0x0)
at util/parse-events.c:1713
#7 0x000000000044e137 in add_default_attributes () at builtin-stat.c:2281
#8 0x000000000044f7b5 in cmd_stat (argc=1, argv=0x7fffffffe3b0) at
builtin-stat.c:2828
#9 0x00000000004c8b0f in run_builtin (p=0xab01a0 <commands+288>, argc=4,
argv=0x7fffffffe3b0) at perf.c:297
#10 0x00000000004c8d7c in handle_internal_command (argc=4,
argv=0x7fffffffe3b0) at perf.c:349
#11 0x00000000004c8ece in run_argv (argcp=0x7fffffffe20c,
argv=0x7fffffffe200) at perf.c:393
#12 0x00000000004c929c in main (argc=4, argv=0x7fffffffe3b0) at perf.c:537
(gdb)It turns out that a NULL pointer is referenced. Here are the function calls:
...
cmd_stat()
+---> add_default_attributes() +---> parse_events(evsel_list, transaction_attrs, NULL);
3rd parameter set to NULL
Function parse_events(xx, xx, struct parse_events_error *err) dives into a bison generated scanner and creates
parser state information for it first:
struct parse_events_state parse_state = {
.list = LIST_HEAD_INIT(parse_state.list),
.idx = evlist->nr_entries,
.error = err, <--- NULL POINTER !!!
.evlist = evlist,
};Now various functions inside the bison scanner are called to end up in __parse_events_add_pmu(struct parse_events_state *parse_state, ..) with first parameter being a pointer to above structure definition.
Now the PMU event name is not found (because being executed in a VM) and this function tries to create an error message with
asprintf(&parse_state->error.str, ....)
which references a NULL pointer and dumps core.
Fix this by providing a pointer to the necessary error information instead of NULL. Technically only the else part is needed to avoid the core dump, just lets be safe...
--- tools/perf/builtin-stat.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
tools/perf/builtin-stat.c +7 -2
@@ -2185,11 +2185,16 @@ static int add_default_attributes(void)return 0 ;if (transaction_run) { +struct parse_events_error errinfo; +if (pmu_have_event ("cpu" ,"cycles-ct" ) &&pmu_have_event ("cpu" ,"el-start" )) - err =parse_events (evsel_list, transaction_attrs,NULL ); + err =parse_events (evsel_list, transaction_attrs, + &errinfo);else - err =parse_events (evsel_list, transaction_limited_attrs,NULL ); + err =parse_events (evsel_list, + transaction_limited_attrs, + &errinfo);if (err) {fprintf (stderr,"Cannot set up transaction events\n" );return -1 ;
Greg Kroah-Hartman
maintainerPATCH 404/496 IB/core: Honor port_num while resolving GID for IB link layer
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Parav Pandit <[email protected]>
[ Upstream commit 563c4ba3bd2b8b0b21c65669ec2226b1cfa1138b ]
ah_attr contains the port number to which cm_id is bound. However, while searching for GID table for matching GID entry, the port number is ignored.
This could cause the wrong GID to be used when the ah_attr is converted to an AH.
--- drivers/infiniband/core/multicast.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-)
drivers/infiniband/core/multicast.c +11 -13
@@ -724,21 +724,19 @@ int ib_init_ah_from_mcmember(struct ib_d {int ret;u16 gid_index; -u8 p; -if (rdma_protocol_roce (device, port_num)) { - ret =ib_find_cached_gid_by_port (device, &rec->port_gid, - gid_type, port_num, - ndev, - &gid_index); - }else if (rdma_protocol_ib (device, port_num)) { - ret =ib_find_cached_gid (device, &rec->port_gid, -IB_GID_TYPE_IB ,NULL , &p, - &gid_index); - }else { - ret = -EINVAL ; - } +/* GID table is not based on the netdevice for IB link layer, +* so ignore ndev during search. +*/ +if (rdma_protocol_ib (device, port_num)) + ndev =NULL ; +else if (!rdma_protocol_roce (device, port_num)) +return -EINVAL ; + ret =ib_find_cached_gid_by_port (device, &rec->port_gid, + gid_type, port_num, + ndev, + &gid_index);if (ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 405/496 drm/amdkfd: add missing include of mm.h
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oded Gabbay <[email protected]>
[ Upstream commit 7420f482ea5163bf6dae39a5c7628d5397cd6307 ]
This patch fixes kernel build in ARCH=frv
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h +1 -0
@@ -26,6 +26,7 @@#define AMDGPU_AMDKFD_H_INCLUDED #include <linux/types.h> +#include <linux/mm.h> #include <linux/mmu_context.h> #include <kgd_kfd_interface.h>
Greg Kroah-Hartman
maintainerPATCH 406/496 coresight: Use %px to print pcsr instead of %p
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leo Yan <[email protected]>
[ Upstream commit 831c326fcd0e8e2a6ece952f898a1ec9b1dc1004 ]
Commit ad67b74d2469 ("printk: hash addresses printed with %p") lets printk specifier %p to hash all addresses before printing, this was resulting in the high 32 bits of pcsr can only output zeros. So module cannot completely print pc value and it's pointless for debugging purpose.
This patch fixes this by using %px to print pcsr instead.
--- drivers/hwtracing/coresight/coresight-cpu-debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/coresight/coresight-cpu-debug.c +1 -1
@@ -315,7 +315,7 @@ static void debug_dump_regs(struct debug } pc =debug_adjust_pc (drvdata); -dev_emerg (dev," EDPCSR: [<%p>] %pS\n" , (void *)pc, (void *)pc); +dev_emerg (dev," EDPCSR: [<%px>] %pS\n" , (void *)pc, (void *)pc);if (drvdata->edcidsr_present)dev_emerg (dev," EDCIDSR: %08x\n" , drvdata->edcidsr);
Greg Kroah-Hartman
maintainerPATCH 407/496 regulator: gpio: Fix some error handling paths in gpio_regulator_probe()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Jaillet <[email protected]>
[ Upstream commit ed8cffda27dea6fd3dafb3ee881c5a786edac9ca ]
Re-order error handling code and gotos to avoid leaks in error handling paths.
--- drivers/regulator/gpio-regulator.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-)
drivers/regulator/gpio-regulator.c +7 -9
@@ -271,8 +271,7 @@ static int gpio_regulator_probe(struct p drvdata->desc.name =kstrdup (config->supply_name,GFP_KERNEL );if (drvdata->desc.name ==NULL ) {dev_err (&pdev->dev,"Failed to allocate supply name\n" ); - ret = -ENOMEM ; - goto err; +return -ENOMEM ; }if (config->nr_gpios !=0 ) {
@@ -292,7 +291,7 @@ static int gpio_regulator_probe(struct pdev_err (&pdev->dev,"Could not obtain regulator setting GPIOs: %d\n" , ret); - goto err_memstate; + goto err_memgpio; } }
@@ -303,7 +302,7 @@ static int gpio_regulator_probe(struct pif (drvdata->states ==NULL ) {dev_err (&pdev->dev,"Failed to allocate state data\n" ); ret = -ENOMEM ; - goto err_memgpio; + goto err_stategpio; } drvdata->nr_states = config->nr_states;
@@ -324,7 +323,7 @@ static int gpio_regulator_probe(struct pdefault :dev_err (&pdev->dev,"No regulator type set\n" ); ret = -EINVAL ; - goto err_memgpio; + goto err_memstate; }/* build initial state from gpio init data. */
@@ -361,22 +360,21 @@ static int gpio_regulator_probe(struct pif (IS_ERR (drvdata->dev)) { ret =PTR_ERR (drvdata->dev);dev_err (&pdev->dev,"Failed to register regulator: %d\n" , ret); - goto err_stategpio; + goto err_memstate; }platform_set_drvdata (pdev, drvdata);return 0 ; -err_stategpio: -gpio_free_array (drvdata->gpios, drvdata->nr_gpios); err_memstate:kfree (drvdata->states); +err_stategpio: +gpio_free_array (drvdata->gpios, drvdata->nr_gpios); err_memgpio:kfree (drvdata->gpios); err_name:kfree (drvdata->desc.name); -err:return ret; }
Greg Kroah-Hartman
maintainerPATCH 408/496 spi: bcm-qspi: fIX some error handling paths
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Jaillet <[email protected]>
[ Upstream commit bc3cc75281b3c2b1c5355d88d147b66a753bb9a5 ]
For some reason, commit c0368e4db4a3 ("spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path") has updated some gotos, but not all of them.
This looks spurious, so fix it.
--- drivers/spi/spi-bcm-qspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/spi-bcm-qspi.c +2 -2
@@ -1255,7 +1255,7 @@ int bcm_qspi_probe(struct platform_devic qspi->base[MSPI ] =devm_ioremap_resource (dev, res);if (IS_ERR (qspi->base[MSPI ])) { ret =PTR_ERR (qspi->base[MSPI ]); - goto qspi_probe_err; + goto qspi_resource_err; } }else { goto qspi_resource_err;
@@ -1266,7 +1266,7 @@ int bcm_qspi_probe(struct platform_devic qspi->base[BSPI ] =devm_ioremap_resource (dev, res);if (IS_ERR (qspi->base[BSPI ])) { ret =PTR_ERR (qspi->base[BSPI ]); - goto qspi_probe_err; + goto qspi_resource_err; } qspi->bspi_mode = true; }else {
Greg Kroah-Hartman
maintainerPATCH 409/496 net/smc: pay attention to MAX_ORDER for CQ entries
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ursula Braun <[email protected]>
[ Upstream commit c9f4c6cf53bfafb639386a4c094929f13f573e04 ]
smc allocates a certain number of CQ entries for used RoCE devices. For mlx5 devices the chosen constant number results in a large allocation causing this warning:
[13355.124656] WARNING: CPU: 3 PID: 16535 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0x2be/0x10c0
[13355.124657] Modules linked in: smc_diag(O) smc(O) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter mlx5_ib ib_core sunrpc mlx5_core s390_trng rng_core ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common ptp pps_core eadm_sch dm_multipath dm_mod vhost_net tun vhost tap sch_fq_codel kvm ip_tables x_tables autofs4 [last unloaded: smc]
[13355.124672] CPU: 3 PID: 16535 Comm: kworker/3:0 Tainted: G O 4.14.0uschi #1
[13355.124673] Hardware name: IBM 3906 M04 704 (LPAR)
[13355.124675] Workqueue: events smc_listen_work [smc]
[13355.124677] task: 00000000e2f22100 task.stack: 0000000084720000
[13355.124678] Krnl PSW : 0704c00180000000 000000000029da76 (__alloc_pages_nodemask+0x2be/0x10c0)
[13355.124681] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
[13355.124682] Krnl GPRS: 0000000000000000 00550e00014080c0 0000000000000000 0000000000000001
[13355.124684] 000000000029d8b6 00000000f3bfd710 0000000000000000 00000000014080c0
[13355.124685] 0000000000000009 00000000ec277a00 0000000000200000 0000000000000000
[13355.124686] 0000000000000000 00000000000001ff 000000000029d8b6 0000000084723720
[13355.124708] Krnl Code: 000000000029da6a: a7110200 tmll %r1,512
000000000029da6e: a774ff29 brc 7,29d8c0
#000000000029da72: a7f40001 brc 15,29da74
>000000000029da76: a7f4ff25 brc 15,29d8c0
000000000029da7a: a7380000 lhi %r3,0
000000000029da7e: a7f4fef1 brc 15,29d860
000000000029da82: 5820f0c4 l %r2,196(%r15)
000000000029da86: a53e0048 llilh %r3,72
[13355.124720] Call Trace:
[13355.124722] ([<000000000029d8b6>] __alloc_pages_nodemask+0xfe/0x10c0)
[13355.124724] [<000000000013bd1e>] s390_dma_alloc+0x6e/0x148
[13355.124733] [<000003ff802eeba6>] mlx5_dma_zalloc_coherent_node+0x8e/0xe0 [mlx5_core]
[13355.124740] [<000003ff802eee18>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core]
[13355.124744] [<000003ff804eb410>] mlx5_ib_create_cq+0x558/0x898 [mlx5_ib]
[13355.124749] [<000003ff80407d40>] ib_create_cq+0x48/0x88 [ib_core]
[13355.124751] [<000003ff80109fba>] smc_ib_setup_per_ibdev+0x52/0x118 [smc]
[13355.124753] [<000003ff8010bcb6>] smc_conn_create+0x65e/0x728 [smc]
[13355.124755] [<000003ff801081a2>] smc_listen_work+0x2d2/0x540 [smc]
[13355.124756] [<0000000000162c66>] process_one_work+0x1be/0x440
[13355.124758] [<0000000000162f40>] worker_thread+0x58/0x458
[13355.124759] [<0000000000169e7e>] kthread+0x14e/0x168
[13355.124760] [<00000000009ce8be>] kernel_thread_starter+0x6/0xc
[13355.124762] [<00000000009ce8b8>] kernel_thread_starter+0x0/0xc
[13355.124762] Last Breaking-Event-Address:
[13355.124764] [<000000000029da72>] __alloc_pages_nodemask+0x2ba/0x10c0
[13355.124764] ---[ end trace 34be38b581c0b585 ]---This patch reduces the smc constant for the maximum number of allocated completion queue entries SMC_MAX_CQE by 2 to avoid high round up values in the mlx5 code, and reduces the number of allocated completion queue entries even more, if the final allocation for an mlx5 device hits the MAX_ORDER limit.
--- net/smc/smc_ib.c | 10 +++++++++- net/smc/smc_wr.h | 1 - 2 files changed, 9 insertions(+), 2 deletions(-)
net/smc/smc_ib.c +9 -1
@@ -23,6 +23,8 @@#include "smc_wr.h" #include "smc.h" +#define SMC_MAX_CQE 32766/* max. # of completion queue elements */ +#define SMC_QP_MIN_RNR_TIMER 5#define SMC_QP_TIMEOUT 15/* 4096 * 2 ** timeout usec */ #define SMC_QP_RETRY_CNT 7/* 7: infinite */
@@ -435,9 +437,15 @@ out:long smc_ib_setup_per_ibdev (struct smc_ib_device *smcibdev) {struct ib_cq_init_attr cqattr = { - .cqe =SMC_WR_MAX_CQE , .comp_vector =0 }; + .cqe =SMC_MAX_CQE , .comp_vector =0 }; +int cqe_size_order, smc_order;long rc; +/* the calculated number of cq entries fits to mlx5 cq allocation */ + cqe_size_order =cache_line_size () ==128 ?7 :6 ; + smc_order =MAX_ORDER - cqe_size_order -1 ; +if (SMC_MAX_CQE +2 > (0x00000001 << smc_order) *PAGE_SIZE ) + cqattr.cqe = (0x00000001 << smc_order) *PAGE_SIZE -2 ; smcibdev->roce_cq_send =ib_create_cq (smcibdev->ibdev, smc_wr_tx_cq_handler,NULL , smcibdev, &cqattr);
net/smc/smc_wr.h +0 -1
@@ -19,7 +19,6 @@#include "smc.h" #include "smc_core.h" -#define SMC_WR_MAX_CQE 32768/* max. # of completion queue elements */ #define SMC_WR_BUF_CNT 16/* # of ctrl buffers per link */ #define SMC_WR_TX_WAIT_FREE_SLOT_TIME (10 * HZ)
Greg Kroah-Hartman
maintainerPATCH 410/496 MIPS: ath79: Fix AR724X_PLL_REG_PCIE_CONFIG offset
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Kresin <[email protected]>
[ Upstream commit 05454c1bde91fb013c0431801001da82947e6b5a ]
According to the QCA u-boot source the "PCIE Phase Lock Loop Configuration (PCIE_PLL_CONFIG)" register is for all SoCs except the QCA955X and QCA956X at offset 0x10.
Since the PCIE PLL config register is only defined for the AR724x fix only this value. The value is wrong since the day it was added and isn't used by any driver yet.
Patchwork: https://patchwork.linux-mips.org/patch/16048/
--- arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h +1 -1
@@ -167,7 +167,7 @@#define AR71XX_AHB_DIV_MASK 0x7#define AR724X_PLL_REG_CPU_CONFIG 0x00 -#define AR724X_PLL_REG_PCIE_CONFIG 0x18 +#define AR724X_PLL_REG_PCIE_CONFIG 0x10#define AR724X_PLL_FB_SHIFT 0#define AR724X_PLL_FB_MASK 0x3ff
Greg Kroah-Hartman
maintainerPATCH 411/496 PCI: Restore config space on runtime resume despite being unbound
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
[ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ]
We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child goes to D3cold, its internal state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.
One example are recent hybrid graphics laptops which cut power to the discrete GPU when the root port above it goes to ACPI power state D3. Users may provoke this by unbinding the GPU driver and allowing runtime PM on the GPU via sysfs: The PM core will then treat the GPU as "suspended", which in turn allows the root port to runtime suspend, causing the power resources listed in its _PR3 object to be powered off. The GPU's BARs will be uninitialized when a driver later probes it.
Another example are hybrid graphics laptops where the GPU itself (rather than the root port) is capable of runtime suspending to D3cold. If the GPU's integrated HDA controller is not bound and the GPU's driver decides to runtime suspend to D3cold, the HDA controller's BARs will be uninitialized when a driver later probes it.
Fix by saving and restoring config space over a runtime suspend cycle even if the device is not bound.
--- drivers/pci/pci-driver.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/pci/pci-driver.c +11 -6
@@ -1164,11 +1164,14 @@ static int pci_pm_runtime_suspend(structint error;/* -* If pci_dev->driver is not set (unbound), the device should -* always remain in D0 regardless of the runtime PM status +* If pci_dev->driver is not set (unbound), we leave the device in D0, +* but it may go to D3cold when the bridge above it runtime suspends. +* Save its config space in case that happens. */ -if (!pci_dev->driver) +if (!pci_dev->driver) { +pci_save_state (pci_dev);return 0 ; + }if (!pm || !pm->runtime_suspend)return -ENOSYS ;
@@ -1216,16 +1219,18 @@ static int pci_pm_runtime_resume(structconst struct dev_pm_ops *pm = dev->driver ? dev->driver->pm :NULL ;/* -* If pci_dev->driver is not set (unbound), the device should -* always remain in D0 regardless of the runtime PM status +* Restoring config space is necessary even if the device is not bound +* to a driver because although we left it in D0, it may have gone to +* D3cold when the bridge above it runtime suspended. */ +pci_restore_standard_config (pci_dev); +if (!pci_dev->driver)return 0 ;if (!pm || !pm->runtime_resume)return -ENOSYS ; -pci_restore_standard_config (pci_dev);pci_fixup_device (pci_fixup_resume_early, pci_dev);pci_enable_wake (pci_dev,PCI_D0 , false);pci_fixup_device (pci_fixup_resume, pci_dev);
Greg Kroah-Hartman
maintainerPATCH 412/496 watchdog: dw: RMW the control register
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
[ Upstream commit a81abbb412341e9e3b2d42ed7d310cf71fbb84a8 ]
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't clobber this value, because that might make the system reset ineffective. On RK3399, we're seeing that a value of 000b (meaning 2 cycles) yields an unreliable (partial?) reset, and so we only fully reset after the watchdog fires a second time. If we retain the system default (010b, or 8 clock cycles), then the watchdog reset is much more reliable.
Read-modify-write retains the system value and improves reset reliability.
It seems we were intentionally clobbering the response mode previously, to ensure we performed a system reset (we don't support an interrupt notification), so retain that explicitly.
--- drivers/watchdog/dw_wdt.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
drivers/watchdog/dw_wdt.c +15 -8
@@ -34,6 +34,7 @@#define WDOG_CONTROL_REG_OFFSET 0x00#define WDOG_CONTROL_REG_WDT_EN_MASK 0x01 +#define WDOG_CONTROL_REG_RESP_MODE_MASK 0x02#define WDOG_TIMEOUT_RANGE_REG_OFFSET 0x04#define WDOG_TIMEOUT_RANGE_TOPINIT_SHIFT 4#define WDOG_CURRENT_COUNT_REG_OFFSET 0x08
@@ -121,14 +122,23 @@ static int dw_wdt_set_timeout(struct watreturn 0 ; } +static void dw_wdt_arm_system_reset (struct dw_wdt *dw_wdt) +{ +u32 val =readl (dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); + +/* Disable interrupt mode; always perform system reset. */ + val &= ~WDOG_CONTROL_REG_RESP_MODE_MASK ; +/* Enable watchdog. */ + val |=WDOG_CONTROL_REG_WDT_EN_MASK ; +writel (val, dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +} +static int dw_wdt_start (struct watchdog_device *wdd) {struct dw_wdt *dw_wdt =to_dw_wdt (wdd);dw_wdt_set_timeout (wdd, wdd->timeout); - -writel (WDOG_CONTROL_REG_WDT_EN_MASK , - dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +dw_wdt_arm_system_reset (dw_wdt);return 0 ; }
@@ -152,16 +162,13 @@ static int dw_wdt_restart(struct watchdo unsigned long action, void *data) { struct dw_wdt *dw_wdt = to_dw_wdt(wdd); -u32 val;writel (0 , dw_wdt->regs +WDOG_TIMEOUT_RANGE_REG_OFFSET ); - val =readl (dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); -if (val &WDOG_CONTROL_REG_WDT_EN_MASK ) +if (dw_wdt_is_enabled (dw_wdt))writel (WDOG_COUNTER_RESTART_KICK_VALUE , dw_wdt->regs +WDOG_COUNTER_RESTART_REG_OFFSET );else -writel (WDOG_CONTROL_REG_WDT_EN_MASK , - dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +dw_wdt_arm_system_reset (dw_wdt);/* wait for reset to assert... */ mdelay (500 );
Greg Kroah-Hartman
maintainerPATCH 413/496 watchdog: aspeed: Fix translation of reset mode to ctrl register
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milton Miller <[email protected]>
[ Upstream commit d2fc8db691bf3197d43b2afb553311a9bf257bff ]
Assert RESET_SYSTEM bit for any reset and set MODE field from reset type.
The watchdog control register has a RESET_SYSTEM bit that is really closer to activate a reset, and RESET_SYSTEM_MODE field that chooses how much to reset.
Before this patch, a node without these optional property would do a SOC reset, but a node with properties requesting a cpu or SOC reset would do nothing and a node requesting a system reset would do a SOC reset.
--- drivers/watchdog/aspeed_wdt.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/watchdog/aspeed_wdt.c +6 -3
@@ -234,11 +234,14 @@ static int aspeed_wdt_probe(struct platf wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC |WDT_CTRL_RESET_SYSTEM ; }else {if (!strcmp (reset_type,"cpu" )) - wdt->ctrl |=WDT_CTRL_RESET_MODE_ARM_CPU ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_ARM_CPU | +WDT_CTRL_RESET_SYSTEM ;else if (!strcmp (reset_type,"soc" )) - wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC | +WDT_CTRL_RESET_SYSTEM ;else if (!strcmp (reset_type,"system" )) - wdt->ctrl |=WDT_CTRL_RESET_SYSTEM ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_FULL_CHIP | +WDT_CTRL_RESET_SYSTEM ;else if (strcmp (reset_type,"none" ))return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 414/496 ipmi_ssif: Fix kernel panic at msg_done_handler
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamlakant Patel <[email protected]>
[ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ]
This happens when BMC doesn't return any data and the code is trying to print the value of data[2].
Getting following crash:
[ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002 [ 484.736496] pgd = ffff0000094a2000 [ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000 [ 484.748158] Internal error: Oops: 96000005 [#1] SMP [...] [ 485.101451] Call trace: [...] [ 485.188473] [<ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif] [ 485.195249] [<ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif] [ 485.202038] [<ffff0000080f1430>] kthread+0x108/0x138 [ 485.206994] [<ffff0000080838e0>] ret_from_fork+0x10/0x30 [ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)
Adding a check to validate the data len before printing data[2] to fix this issue.
--- drivers/char/ipmi/ipmi_ssif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/char/ipmi/ipmi_ssif.c +2 -2
@@ -763,7 +763,7 @@ static void msg_done_handler(struct ssif ssif_info->ssif_state =SSIF_NORMAL ;ipmi_ssif_unlock_cond (ssif_info, flags);pr_warn (PFX "Error getting flags: %d %d, %x\n" , - result, len, data[2 ]); + result, len, (len >=3 ) ? data[2 ] :0 ); }else if (data[0 ] != (IPMI_NETFN_APP_REQUEST |1 ) <<2 || data[1 ] !=IPMI_GET_MSG_FLAGS_CMD ) {/*
@@ -785,7 +785,7 @@ static void msg_done_handler(struct ssifif ((result <0 ) || (len <3 ) || (data[2 ] !=0 )) {/* Error clearing flags */ pr_warn (PFX "Error clearing flags: %d %d, %x\n" , - result, len, data[2 ]); + result, len, (len >=3 ) ? data[2 ] :0 ); }else if (data[0 ] != (IPMI_NETFN_APP_REQUEST |1 ) <<2 || data[1 ] !=IPMI_CLEAR_MSG_FLAGS_CMD ) { pr_warn(PFX "Invalid response clearing flags: %x %x\n",
Greg Kroah-Hartman
maintainerPATCH 415/496 drm/meson: Fix some error handling paths in meson_drv_bind_master()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 2c18107b9d58972588cd45d89b8f58d0f033c110 ]
If one of these functions fail, we whould free 'drm', as alreadry done in the other error handling paths, below and above.
--- drivers/gpu/drm/meson/meson_drv.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/gpu/drm/meson/meson_drv.c +16 -8
@@ -180,35 +180,43 @@ static int meson_drv_bind_master(struct res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"vpu" ); regs =devm_ioremap_resource (dev, res); -if (IS_ERR (regs)) -return PTR_ERR (regs); +if (IS_ERR (regs)) { + ret =PTR_ERR (regs); + goto free_drm; + } priv->io_base = regs; res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"hhi" );/* Simply ioremap since it may be a shared register zone */ regs =devm_ioremap (dev, res->start,resource_size (res)); -if (!regs) -return -EADDRNOTAVAIL ; +if (!regs) { + ret = -EADDRNOTAVAIL ; + goto free_drm; + } priv->hhi =devm_regmap_init_mmio (dev, regs, &meson_regmap_config);if (IS_ERR (priv->hhi)) {dev_err (&pdev->dev,"Couldn't create the HHI regmap\n" ); -return PTR_ERR (priv->hhi); + ret =PTR_ERR (priv->hhi); + goto free_drm; } res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"dmc" );/* Simply ioremap since it may be a shared register zone */ regs =devm_ioremap (dev, res->start,resource_size (res)); -if (!regs) -return -EADDRNOTAVAIL ; +if (!regs) { + ret = -EADDRNOTAVAIL ; + goto free_drm; + } priv->dmc =devm_regmap_init_mmio (dev, regs, &meson_regmap_config);if (IS_ERR (priv->dmc)) {dev_err (&pdev->dev,"Couldn't create the DMC regmap\n" ); -return PTR_ERR (priv->dmc); + ret =PTR_ERR (priv->dmc); + goto free_drm; } priv->vsync_irq =platform_get_irq (pdev,0 );
Greg Kroah-Hartman
maintainerPATCH 416/496 drm/meson: Fix an un-handled error path in meson_drv_bind_master()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit e770f6bf18182bc3af6ceec30189b6c323cbc157 ]
'drm_vblank_init()' can fail. So handle this (unlikely) error.
--- drivers/gpu/drm/meson/meson_drv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/meson/meson_drv.c +4 -1
@@ -221,7 +221,10 @@ static int meson_drv_bind_master(struct priv->vsync_irq =platform_get_irq (pdev,0 ); -drm_vblank_init (drm,1 ); + ret =drm_vblank_init (drm,1 ); +if (ret) + goto free_drm; +drm_mode_config_init (drm); drm->mode_config.max_width =3840 ; drm->mode_config.max_height =2160 ;
Greg Kroah-Hartman
maintainerPATCH 418/496 powerpc/powernv/npu: Fix deadlock in mmio_invalidate()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alistair Popple <[email protected]>
[ Upstream commit 2b74e2a9b39df40a2b489af2d24079617c61ee0e ]
When sending TLB invalidates to the NPU we need to send extra flushes due to a hardware issue. The original implementation would lock the all the ATSD MMIO registers sequentially before unlocking and relocking each of them sequentially to do the extra flush.
This introduced a deadlock as it is possible for one thread to hold one ATSD register whilst waiting for another register to be freed while the other thread is holding that register waiting for the one in the first thread to be freed.
For example if there are two threads and two ATSD registers:
Thread A Thread B
----------------------
Acquire 1
Acquire 2
Release 1 Acquire 1
Wait 1 Wait 2
Both threads will be stuck waiting to acquire a register resulting in an RCU stall warning or soft lockup.
This patch solves the deadlock by refactoring the code to ensure registers are not released between flushes and to ensure all registers are either acquired or released together and in order.
--- arch/powerpc/platforms/powernv/npu-dma.c | 227 +++++++++++++++++++------------ 1 file changed, 140 insertions(+), 87 deletions(-)
arch/powerpc/platforms/powernv/npu-dma.c +140 -87
@@ -413,6 +413,11 @@ struct npu_context {void *priv; }; +struct mmio_atsd_reg { +struct npu *npu; +int reg; +}; +/* * Find a free MMIO ATSD register and mark it in use. Return -ENOSPC * if none are available.
@@ -422,7 +427,7 @@ static int get_mmio_atsd_reg(struct npuint i;for (i =0 ; i < npu->mmio_atsd_count; i++) { -if (!test_and_set_bit (i, &npu->mmio_atsd_usage)) +if (!test_and_set_bit_lock (i, &npu->mmio_atsd_usage))return i; }
@@ -431,86 +436,90 @@ static int get_mmio_atsd_reg(struct npustatic void put_mmio_atsd_reg (struct npu *npu,int reg) { -clear_bit (reg, &npu->mmio_atsd_usage); +clear_bit_unlock (reg, &npu->mmio_atsd_usage); }/* MMIO ATSD register offsets */ #define XTS_ATSD_AVA 1#define XTS_ATSD_STAT 2 -static int mmio_launch_invalidate (struct npu *npu,unsigned long launch, -unsigned long va) +static void mmio_launch_invalidate (struct mmio_atsd_reg *mmio_atsd_reg, +unsigned long launch,unsigned long va) { -int mmio_atsd_reg; - -do { - mmio_atsd_reg =get_mmio_atsd_reg (npu); -cpu_relax (); - }while (mmio_atsd_reg <0 ); +struct npu *npu = mmio_atsd_reg->npu; +int reg = mmio_atsd_reg->reg;__raw_writeq (cpu_to_be64 (va), - npu->mmio_atsd_regs[mmio_atsd_reg] +XTS_ATSD_AVA ); + npu->mmio_atsd_regs[reg] +XTS_ATSD_AVA );eieio (); -__raw_writeq (cpu_to_be64 (launch), npu->mmio_atsd_regs[mmio_atsd_reg]); - -return mmio_atsd_reg; +__raw_writeq (cpu_to_be64 (launch), npu->mmio_atsd_regs[reg]); } -static int mmio_invalidate_pid (struct npu *npu,unsigned long pid,bool flush) +static void mmio_invalidate_pid (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ], +unsigned long pid,bool flush) { +int i;unsigned long launch; -/* IS set to invalidate matching PID */ - launch =PPC_BIT (12 ); +for (i =0 ; i <= max_npu2_index; i++) { +if (mmio_atsd_reg[i].reg <0 ) +continue ; + +/* IS set to invalidate matching PID */ + launch =PPC_BIT (12 ); -/* PRS set to process-scoped */ - launch |=PPC_BIT (13 ); +/* PRS set to process-scoped */ + launch |=PPC_BIT (13 ); -/* AP */ - launch |= (u64 )mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); +/* AP */ + launch |= (u64 ) +mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); -/* PID */ - launch |= pid <<PPC_BITLSHIFT (38 ); +/* PID */ + launch |= pid <<PPC_BITLSHIFT (38 ); -/* No flush */ - launch |= !flush <<PPC_BITLSHIFT (39 ); +/* No flush */ + launch |= !flush <<PPC_BITLSHIFT (39 ); -/* Invalidating the entire process doesn't use a va */ -return mmio_launch_invalidate (npu, launch,0 ); +/* Invalidating the entire process doesn't use a va */ +mmio_launch_invalidate (&mmio_atsd_reg[i], launch,0 ); + } } -static int mmio_invalidate_va (struct npu *npu,unsigned long va, -unsigned long pid,bool flush) +static void mmio_invalidate_va (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ], +unsigned long va,unsigned long pid,bool flush) { +int i;unsigned long launch; -/* IS set to invalidate target VA */ - launch =0 ; +for (i =0 ; i <= max_npu2_index; i++) { +if (mmio_atsd_reg[i].reg <0 ) +continue ; -/* PRS set to process scoped */ - launch |=PPC_BIT (13 ); +/* IS set to invalidate target VA */ + launch =0 ; -/* AP */ - launch |= (u64 )mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); +/* PRS set to process scoped */ + launch |=PPC_BIT (13 ); -/* PID */ - launch |= pid <<PPC_BITLSHIFT (38 ); +/* AP */ + launch |= (u64 ) +mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); -/* No flush */ - launch |= !flush <<PPC_BITLSHIFT (39 ); +/* PID */ + launch |= pid <<PPC_BITLSHIFT (38 ); -return mmio_launch_invalidate (npu, launch, va); +/* No flush */ + launch |= !flush <<PPC_BITLSHIFT (39 ); + +mmio_launch_invalidate (&mmio_atsd_reg[i], launch, va); + } }#define mn_to_npu_context (x) container_of(x, struct npu_context, mn) -struct mmio_atsd_reg { -struct npu *npu; -int reg; -}; -static void mmio_invalidate_wait ( -struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ],bool flush) +struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) {struct npu *npu;int i, reg;
@@ -525,16 +534,67 @@ static void mmio_invalidate_wait( reg = mmio_atsd_reg[i].reg;while (__raw_readq (npu->mmio_atsd_regs[reg] +XTS_ATSD_STAT ))cpu_relax (); + } +} + +/* +* Acquires all the address translation shootdown (ATSD) registers required to +* launch an ATSD on all links this npu_context is active on. +*/ +static void acquire_atsd_reg (struct npu_context *npu_context, +struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) +{ +int i, j; +struct npu *npu; +struct pci_dev *npdev; +struct pnv_phb *nphb; + +for (i =0 ; i <= max_npu2_index; i++) { + mmio_atsd_reg[i].reg =-1 ; +for (j =0 ; j <NV_MAX_LINKS ; j++) { +/* +* There are no ordering requirements with respect to +* the setup of struct npu_context, but to ensure +* consistent behaviour we need to ensure npdev[][] is +* only read once. +*/ + npdev =READ_ONCE (npu_context->npdev[i][j]); +if (!npdev) +continue ; + + nphb =pci_bus_to_host (npdev->bus)->private_data; + npu = &nphb->npu; + mmio_atsd_reg[i].npu = npu; + mmio_atsd_reg[i].reg =get_mmio_atsd_reg (npu); +while (mmio_atsd_reg[i].reg <0 ) { + mmio_atsd_reg[i].reg =get_mmio_atsd_reg (npu); +cpu_relax (); + } +break ; + } + } +} -put_mmio_atsd_reg (npu, reg); +/* +* Release previously acquired ATSD registers. To avoid deadlocks the registers +* must be released in the same order they were acquired above in +* acquire_atsd_reg. +*/ +static void release_atsd_reg (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) +{ +int i; +for (i =0 ; i <= max_npu2_index; i++) {/* -* The GPU requires two flush ATSDs to ensure all entries have -* been flushed. We use PID 0 as it will never be used for a -* process on the GPU. +* We can't rely on npu_context->npdev[][] being the same here +* as when acquire_atsd_reg() was called, hence we use the +* values stored in mmio_atsd_reg during the acquire phase +* rather than re-reading npdev[][]. */ -if (flush) -mmio_invalidate_pid (npu,0 , true); +if (mmio_atsd_reg[i].reg <0 ) +continue ; + +put_mmio_atsd_reg (mmio_atsd_reg[i].npu, mmio_atsd_reg[i].reg); } }
@@ -545,10 +605,6 @@ static void mmio_invalidate_wait(static void mmio_invalidate (struct npu_context *npu_context,int va,unsigned long address,bool flush) { -int i, j; -struct npu *npu; -struct pnv_phb *nphb; -struct pci_dev *npdev;struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ];unsigned long pid = npu_context->mm->context.id;
@@ -562,37 +618,25 @@ static void mmio_invalidate(struct npu_c* Loop over all the NPUs this process is active on and launch * an invalidate. */ -for (i =0 ; i <= max_npu2_index; i++) { - mmio_atsd_reg[i].reg =-1 ; -for (j =0 ; j <NV_MAX_LINKS ; j++) { - npdev = npu_context->npdev[i][j]; -if (!npdev) -continue ; +acquire_atsd_reg (npu_context, mmio_atsd_reg); +if (va) +mmio_invalidate_va (mmio_atsd_reg, address, pid, flush); +else +mmio_invalidate_pid (mmio_atsd_reg, pid, flush); - nphb =pci_bus_to_host (npdev->bus)->private_data; - npu = &nphb->npu; - mmio_atsd_reg[i].npu = npu; - -if (va) - mmio_atsd_reg[i].reg = -mmio_invalidate_va (npu, address, pid, - flush); -else - mmio_atsd_reg[i].reg = -mmio_invalidate_pid (npu, pid, flush); - -/* -* The NPU hardware forwards the shootdown to all GPUs -* so we only have to launch one shootdown per NPU. -*/ -break ; - } +mmio_invalidate_wait (mmio_atsd_reg); +if (flush) { +/* +* The GPU requires two flush ATSDs to ensure all entries have +* been flushed. We use PID 0 as it will never be used for a +* process on the GPU. +*/ +mmio_invalidate_pid (mmio_atsd_reg,0 , true); +mmio_invalidate_wait (mmio_atsd_reg); +mmio_invalidate_pid (mmio_atsd_reg,0 , true); +mmio_invalidate_wait (mmio_atsd_reg); } - -mmio_invalidate_wait (mmio_atsd_reg, flush); -if (flush) -/* Wait for the flush to complete */ -mmio_invalidate_wait (mmio_atsd_reg, false); +release_atsd_reg (mmio_atsd_reg); } static void pnv_npu2_mn_release(struct mmu_notifier *mn,
@@ -735,7 +779,16 @@ struct npu_context *pnv_npu2_init_contexif (WARN_ON (of_property_read_u32 (nvlink_dn,"ibm,npu-link-index" , &nvlink_index)))return ERR_PTR (-ENODEV ); - npu_context->npdev[npu->index][nvlink_index] = npdev; + +/* +* npdev is a pci_dev pointer setup by the PCI code. We assign it to +* npdev[][] to indicate to the mmu notifiers that an invalidation +* should also be sent over this nvlink. The notifiers don't use any +* other fields in npu_context, so we just need to ensure that when they +* deference npu_context->npdev[][] it is either a valid pointer or +* NULL. +*/ +WRITE_ONCE (npu_context->npdev[npu->index][nvlink_index], npdev);return npu_context; }
@@ -774,7 +827,7 @@ void pnv_npu2_destroy_context(struct npuif (WARN_ON (of_property_read_u32 (nvlink_dn,"ibm,npu-link-index" , &nvlink_index)))return ; - npu_context->npdev[npu->index][nvlink_index] =NULL ; +WRITE_ONCE (npu_context->npdev[npu->index][nvlink_index],NULL );opal_npu_destroy_context (nphb->opal_id, npu_context->mm->context.id,PCI_DEVID (gpdev->bus->number, gpdev->devfn));kref_put (&npu_context->kref, pnv_npu2_release_context);
Greg Kroah-Hartman
maintainerPATCH 419/496 cxl: Check if PSL data-cache is available before issue flush request
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vaibhav Jain <[email protected]>
[ Upstream commit 94322ed8e857e3b2a33cf75118051af9baaa110f ]
PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache. This is usually indicated in the kernel logs with this message:
"WARNING: cache flush timed out"
To fix this the patch checks PSL_Debug register CDC-Field(BIT:27) which indicates the absence of a data-cache and sets a flag 'no_data_cache' in 'struct cxl_native' to indicate this. When cxl_data_cache_flush() is called it checks the flag and if set bails out early without requesting a data-cache flush operation to the PSL.
--- drivers/misc/cxl/cxl.h | 4 ++++ drivers/misc/cxl/native.c | 11 ++++++++++- drivers/misc/cxl/pci.c | 19 +++++++++++++------ 3 files changed, 27 insertions(+), 7 deletions(-)
drivers/misc/cxl/cxl.h +4 -0
@@ -365,6 +365,9 @@ static const cxl_p2n_reg_t CXL_PSL_WED_A#define CXL_PSL_TFC_An_AE (1ull << (63-30))/* Restart PSL with address error */ #define CXL_PSL_TFC_An_R (1ull << (63-31))/* Restart PSL transaction */ +/****** CXL_PSL_DEBUG *****************************************************/ +#define CXL_PSL_DEBUG_CDC (1ull << (63-27))/* Coherent Data cache support */ +/****** CXL_XSL9_IERAT_ERAT - CAIA 2 **********************************/ #define CXL_XSL9_IERAT_MLPID (1ull << (63-0))/* Match LPID */ #define CXL_XSL9_IERAT_MPID (1ull << (63-1))/* Match PID */
@@ -659,6 +662,7 @@ struct cxl_native {irq_hw_number_t err_hwirq;unsigned int err_virq;u64 ps_off; +bool no_data_cache;/* set if no data cache on the card */ const struct cxl_service_layer_ops *sl_ops; };
drivers/misc/cxl/native.c +10 -1
@@ -352,8 +352,17 @@ int cxl_data_cache_flush(struct cxl *adau64 reg;unsigned long timeout = jiffies + (HZ *CXL_TIMEOUT ); -pr_devel ("Flushing data cache\n" ); +/* +* Do a datacache flush only if datacache is available. +* In case of PSL9D datacache absent hence flush operation. +* would timeout. +*/ +if (adapter->native->no_data_cache) { +pr_devel ("No PSL data cache. Ignoring cache flush req.\n" ); +return 0 ; + } +pr_devel ("Flushing data cache\n" ); reg =cxl_p1_read (adapter, CXL_PSL_Control); reg |= CXL_PSL_Control_Fr;cxl_p1_write (adapter, CXL_PSL_Control, reg);
drivers/misc/cxl/pci.c +13 -6
@@ -457,6 +457,7 @@ static int init_implementation_adapter_ru64 chipid;u32 phb_index;u64 capp_unit_id; +u64 psl_debug;int rc; rc =cxl_calc_capp_routing (dev, &chipid, &phb_index, &capp_unit_id);
@@ -507,6 +508,16 @@ static int init_implementation_adapter_rif (cxl_is_power9_dd1 ())cxl_p1_write (adapter,CXL_PSL9_GP_CT ,0x0400000000000001ULL ); +/* +* Check if PSL has data-cache. We need to flush adapter datacache +* when as its about to be removed. +*/ + psl_debug =cxl_p1_read (adapter,CXL_PSL9_DEBUG ); +if (psl_debug &CXL_PSL_DEBUG_CDC ) { +dev_dbg (&dev->dev,"No data-cache present\n" ); + adapter->native->no_data_cache = true; + } +return 0 ; }
@@ -1450,10 +1461,8 @@ int cxl_pci_reset(struct cxl *adapter)/* * The adapter is about to be reset, so ignore errors. -* Not supported on P9 DD1 */ -if ((cxl_is_power8 ()) || (!(cxl_is_power9_dd1 ()))) -cxl_data_cache_flush (adapter); +cxl_data_cache_flush (adapter);/* pcie_warm_reset requests a fundamental pci reset which includes a * PERST assert/deassert. PERST triggers a loading of the image
@@ -1898,10 +1907,8 @@ static void cxl_pci_remove_adapter(struc/* * Flush adapter datacache as its about to be removed. -* Not supported on P9 DD1. */ -if ((cxl_is_power8 ()) || (!(cxl_is_power9_dd1 ()))) -cxl_data_cache_flush (adapter); +cxl_data_cache_flush (adapter);cxl_deconfigure_adapter (adapter);
Greg Kroah-Hartman
maintainerPATCH 420/496 f2fs: fix to set KEEP_SIZE bit in f2fs_zero_range
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit 17cd07ae95073c298af92c1ba14ac58ce84de33b ]
As Jayashree Mohan reported:
A simple workload to reproduce this would be :
1. create foo
2. Write (8K - 16K) // foo size = 16K now
3. fsync()
4. falloc zero_range , keep_size (4202496 - 4210688) // foo size must be 16K
5. fdatasync()
Crash now
On recovery, we see that the file size is 4210688 and not 16K, which violates the semantics of keep_size flag. We have a test case to reproduce this using CrashMonkey on 4.15 kernel. Try this out by simply running :
./c_harness -f /dev/sda -d /dev/cow_ram0 -t f2fs -e 102400 -P -v tests/generic_468_zero.so
The root cause is that we miss to set KEEP_SIZE bit correctly in zero_range when zeroing block cross EOF with FALLOC_FL_KEEP_SIZE, let's fix this missing case.
--- fs/f2fs/file.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
fs/f2fs/file.c +6 -2
@@ -1321,8 +1321,12 @@ static int f2fs_zero_range(struct inode } out: -if (!(mode &FALLOC_FL_KEEP_SIZE ) &&i_size_read (inode) < new_size) -f2fs_i_size_write (inode, new_size); +if (new_size >i_size_read (inode)) { +if (mode &FALLOC_FL_KEEP_SIZE ) +file_set_keep_isize (inode); +else +f2fs_i_size_write (inode, new_size); + } out_sem:up_write (&F2FS_I (inode)->i_mmap_sem);
Greg Kroah-Hartman
maintainerPATCH 421/496 f2fs: fix to clear CP_TRIMMED_FLAG
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit cd36d7a17f9da68be9aa67185ba3ad7969934a19 ]
Once CP_TRIMMED_FLAG is set, after a reboot, we will never issue discard before LBA becomes invalid again, fix it by clearing the flag in checkpoint without CP_TRIMMED reason.
--- fs/f2fs/checkpoint.c | 2 ++ 1 file changed, 2 insertions(+)
fs/f2fs/checkpoint.c +2 -0
@@ -1108,6 +1108,8 @@ static void update_ckpt_flags(struct f2fif (cpc->reason &CP_TRIMMED )__set_ckpt_flags (ckpt,CP_TRIMMED_FLAG ); +else +__clear_ckpt_flags (ckpt,CP_TRIMMED_FLAG );if (cpc->reason &CP_UMOUNT )__set_ckpt_flags (ckpt,CP_UMOUNT_FLAG );
Greg Kroah-Hartman
maintainerPATCH 422/496 f2fs: fix to check extent cache in f2fs_drop_extent_tree
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit bf617f7a92edc6bb2909db2bfa4576f50b280ee5 ]
If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: _raw_write_lock+0xc/0x30 Call Trace: ? f2fs_drop_extent_tree+0x41/0x70 [f2fs] f2fs_fallocate+0x5a0/0xdd0 [f2fs] ? common_file_perm+0x47/0xc0 ? apparmor_file_permission+0x1a/0x20 vfs_fallocate+0x15b/0x290 SyS_fallocate+0x44/0x70 do_syscall_64+0x6e/0x160 entry_SYSCALL64_slow_path+0x25/0x25
This patch fixes to check extent cache status before using in f2fs_drop_extent_tree.
--- fs/f2fs/extent_cache.c | 3 +++ 1 file changed, 3 insertions(+)
fs/f2fs/extent_cache.c +3 -0
@@ -706,6 +706,9 @@ void f2fs_drop_extent_tree(struct inodestruct f2fs_sb_info *sbi =F2FS_I_SB (inode);struct extent_tree *et =F2FS_I (inode)->extent_tree; +if (!f2fs_may_extent_tree (inode)) +return ; +set_inode_flag (inode,FI_NO_EXTENT );write_lock (&et->lock);
Greg Kroah-Hartman
maintainerPATCH 423/496 perf/core: Fix installing cgroup events on CPU
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "leilei.lin" <[email protected]>
[ Upstream commit 33801b94741d6c3be9713c10aa627477216c21e2 ]
There's two problems when installing cgroup events on CPUs: firstly list_update_cgroup_event() only tries to set cpuctx->cgrp for the first event, if that mismatches on @cgrp we'll not try again for later additions.
Secondly, when we install a cgroup event into an active context, only issue an event reprogram when the event matches the current cgroup context. This avoids a pointless event reprogramming.
--- kernel/events/core.c | 46 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 35 insertions(+), 11 deletions(-)
kernel/events/core.c +35 -11
@@ -900,27 +900,39 @@ list_update_cgroup_event(struct perf_eveif (!is_cgroup_event (event))return ; -if (add && ctx->nr_cgroups++) -return ; -else if (!add && --ctx->nr_cgroups) -return ;/* * Because cgroup events are always per-cpu events, * this will always be called from the right CPU. */ cpuctx =__get_cpu_context (ctx); - cpuctx_entry = &cpuctx->cgrp_cpuctx_entry; -/* cpuctx->cgrp is NULL unless a cgroup event is active in this CPU .*/ -if (add) { + +/* +* Since setting cpuctx->cgrp is conditional on the current @cgrp +* matching the event's cgroup, we must do this for every new event, +* because if the first would mismatch, the second would not try again +* and we would leave cpuctx->cgrp unset. +*/ +if (add && !cpuctx->cgrp) {struct perf_cgroup *cgrp =perf_cgroup_from_task (current, ctx); -list_add (cpuctx_entry,this_cpu_ptr (&cgrp_cpuctx_list));if (cgroup_is_descendant (cgrp->css.cgroup, event->cgrp->css.cgroup)) cpuctx->cgrp = cgrp; - }else { -list_del (cpuctx_entry); - cpuctx->cgrp =NULL ; } + +if (add && ctx->nr_cgroups++) +return ; +else if (!add && --ctx->nr_cgroups) +return ; + +/* no cgroup running */ +if (!add) + cpuctx->cgrp =NULL ; + + cpuctx_entry = &cpuctx->cgrp_cpuctx_entry; +if (add) +list_add (cpuctx_entry,this_cpu_ptr (&cgrp_cpuctx_list)); +else + list_del(cpuctx_entry); }#else /* !CONFIG_CGROUP_PERF */
@@ -2404,6 +2416,18 @@ static int __perf_install_in_context(voraw_spin_lock (&task_ctx->lock); } +#ifdef CONFIG_CGROUP_PERF +if (is_cgroup_event (event)) { +/* +* If the current cgroup doesn't match the event's +* cgroup, we should not try to schedule it. +*/ +struct perf_cgroup *cgrp =perf_cgroup_from_task (current, ctx); + reprogram =cgroup_is_descendant (cgrp->css.cgroup, + event->cgrp->css.cgroup); + } +#endif +if (reprogram) {ctx_sched_out (ctx, cpuctx,EVENT_TIME );add_event_to_ctx (event, ctx);
Greg Kroah-Hartman
maintainerPATCH 424/496 max17042: propagate of_node to power supply device
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre Bourdon <[email protected]>
[ Upstream commit 66ec32fc7cd116dab5c02603ea8ec28ff92da3b5 ]
max17042_get_status uses the core power_supply_am_i_supplied. That function relies on DT properties to figure out the power supply topology, and will error out without DT.
Fixes max17042 battery status being reported as "unknown".
--- drivers/power/supply/max17042_battery.c | 1 + 1 file changed, 1 insertion(+)
drivers/power/supply/max17042_battery.c +1 -0
@@ -1021,6 +1021,7 @@ static int max17042_probe(struct i2c_clii2c_set_clientdata (client, chip); psy_cfg.drv_data = chip; + psy_cfg.of_node = dev->of_node;/* When current is not measured, * CURRENT_NOW and CURRENT_AVG properties should be invisible. */
Greg Kroah-Hartman
maintainerPATCH 425/496 perf/core: Fix perf_output_read_group()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 9e5b127d6f33468143d90c8a45ca12410e4c3fa7 ]
Mark reported his arm64 perf fuzzer runs sometimes splat like:
armv8pmu_read_counter+0x1e8/0x2d8 armpmu_event_update+0x8c/0x188 armpmu_read+0xc/0x18 perf_output_read+0x550/0x11e8 perf_event_read_event+0x1d0/0x248 perf_event_exit_task+0x468/0xbb8 do_exit+0x690/0x1310 do_group_exit+0xd0/0x2b0 get_signal+0x2e8/0x17a8 do_signal+0x144/0x4f8 do_notify_resume+0x148/0x1e8 work_pending+0x8/0x14
which asserts that we only call pmu::read() on ACTIVE events.
The above callchain does:
perf_event_exit_task()
perf_event_exit_task_context()
task_ctx_sched_out() // INACTIVE
perf_event_exit_event()
perf_event_set_state(EXIT) // EXIT
sync_child_event()
perf_event_read_event()
perf_output_read()
perf_output_read_group()
leader->pmu->read()
Which results in doing a pmu::read() on an !ACTIVE event.
I _think_ this is 'new' since we added attr.inherit_stat, which added the perf_event_read_event() to the exit path, without that perf_event_read_output() would only trigger from samples and for @event to trigger a sample, it's leader _must_ be ACTIVE too.
Still, adding this check makes it consistent with the @sub case for the siblings.
--- kernel/events/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/events/core.c +2 -1
@@ -5837,7 +5837,8 @@ static void perf_output_read_group(strucif (read_format &PERF_FORMAT_TOTAL_TIME_RUNNING ) values[n++] = running; -if (leader != event) +if ((leader != event) && + (leader->state ==PERF_EVENT_STATE_ACTIVE )) leader->pmu->read (leader); values[n++] =perf_event_count (leader);
Greg Kroah-Hartman
maintainerPATCH 426/496 drm/panel: simple: Fix the bus format for the Ontat panel
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
[ Upstream commit 5651e5e094591f479adad5830ac1bc45196a39b3 ]
This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel.
--- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/panel/panel-simple.c +1 -1
@@ -1561,7 +1561,7 @@ static const struct panel_desc ontat_yx7 .width = 154, .height = 83, }, - .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, }; static const struct drm_display_mode ortustech_com43h4m85ulc_mode = {
Greg Kroah-Hartman
maintainerPATCH 427/496 hwmon: (pmbus/max8688) Accept negative page register values
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit a46f8cd696624ef757be0311eb28f119c36778e8 ]
A negative page register value means that no page needs to be selected. This is used by status register evaluations and needs to be accepted.
--- drivers/hwmon/pmbus/max8688.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/pmbus/max8688.c +1 -1
@@ -45,7 +45,7 @@ static int max8688_read_word_data(struct {int ret; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
Greg Kroah-Hartman
maintainerPATCH 428/496 hwmon: (pmbus/adm1275) Accept negative page register values
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit ecb29abd4cb0670c616fb563a078f25d777ce530 ]
A negative page register value means that no page needs to be selected. This is used by status register read operations and needs to be accepted. The failure to do so so results in missed status and limit registers.
--- drivers/hwmon/pmbus/adm1275.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/pmbus/adm1275.c +2 -2
@@ -154,7 +154,7 @@ static int adm1275_read_word_data(structconst struct adm1275_data *data =to_adm1275_data (info);int ret =0 ; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
@@ -240,7 +240,7 @@ static int adm1275_write_word_data(strucconst struct adm1275_data *data =to_adm1275_data (info);int ret; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
Greg Kroah-Hartman
maintainerPATCH 429/496 perf/x86/intel: Properly save/restore the PMU state in the NMI handler
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit 82d71ed0277efc45360828af8c4e4d40e1b45352 ]
The PMU is disabled in intel_pmu_handle_irq(), but cpuc->enabled is not updated accordingly.
This is fine in current usage because no-one checks it - but fix it for future code: for example, the drain_pebs() will be modified to fix an auto-reload bug.
Properly save/restore the old PMU state.
--- arch/x86/events/intel/core.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
arch/x86/events/intel/core.c +9 -1
@@ -2201,16 +2201,23 @@ static int intel_pmu_handle_irq(struct pint bit, loops;u64 status;int handled; +int pmu_enabled; cpuc =this_cpu_ptr (&cpu_hw_events);/* +* Save the PMU state. +* It needs to be restored when leaving the handler. +*/ + pmu_enabled = cpuc->enabled; +/* * No known reason to not always do late ACK, * but just in case do it opt-in. */ if (!x86_pmu.late_ack)apic_write (APIC_LVTPC ,APIC_DM_NMI );intel_bts_disable_local (); + cpuc->enabled =0 ;__intel_pmu_disable_all (); handled =intel_pmu_drain_bts_buffer (); handled +=intel_bts_interrupt ();
@@ -2320,7 +2327,8 @@ again: done:/* Only restore PMU state when it's active. See x86_pmu_disable(). */ -if (cpuc->enabled) + cpuc->enabled = pmu_enabled; +if (pmu_enabled)__intel_pmu_enable_all (0 , true);intel_bts_enable_local ();
Greg Kroah-Hartman
maintainerPATCH 430/496 cdrom: do not call check_disk_change() inside cdrom_open()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]
when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks.
PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount"
#0 [ffff880078447ae0] __schedule at ffffffff8168d605
#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570
#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
#10 [ffff880078447e28] mount_fs at ffffffff81202d09
#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f #12 [ffff880078447ea8] do_mount at ffffffff81220fee
#13 [ffff880078447f28] sys_mount at ffffffff812218d6
#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246
RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010
RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30
RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010
R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040
R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002bThis task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock.
PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd"
#0 [ffff880078417898] __schedule at ffffffff8168d605
#1 [ffff880078417900] schedule at ffffffff8168dc59
#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 #4 [ffff8800784179d0] down_read at ffffffff8168cde0
#5 [ffff8800784179e8] get_super at ffffffff81201cc7
#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de #7 [ffff880078417a40] flush_disk at ffffffff8123a94b
#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
#16 [ffff880078417d00] do_last at ffffffff8120d53d
#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
#20 [ffff880078417f70] sys_open at ffffffff811fde4e
#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246
RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000
RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70
RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020
R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e
R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010
ORIG_RAX: 0000000000000002 CS: 0033 SS: 002bThis task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.
The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock.
This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it.
--- drivers/block/paride/pcd.c | 2 ++ drivers/cdrom/cdrom.c | 3 --- drivers/cdrom/gdrom.c | 3 +++ drivers/ide/ide-cd.c | 2 ++ drivers/scsi/sr.c | 2 ++ 5 files changed, 9 insertions(+), 3 deletions(-)
drivers/block/paride/pcd.c +2 -0
@@ -230,6 +230,8 @@ static int pcd_block_open(struct block_dstruct pcd_unit *cd = bdev->bd_disk->private_data;int ret; +check_disk_change (bdev); +mutex_lock (&pcd_mutex); ret =cdrom_open (&cd->info, bdev, mode);mutex_unlock (&pcd_mutex);
drivers/cdrom/cdrom.c +0 -3
@@ -1152,9 +1152,6 @@ int cdrom_open(struct cdrom_device_infocd_dbg (CD_OPEN ,"entering cdrom_open\n" ); -/* open is event synchronization point, check events first */ -check_disk_change (bdev); -/* if this was a O_NONBLOCK open and we should honor the flags, * do a quick open without drive/disc integrity checks. */ cdi->use_count++;
drivers/cdrom/gdrom.c +3 -0
@@ -497,6 +497,9 @@ static const struct cdrom_device_ops gdrstatic int gdrom_bdops_open (struct block_device *bdev,fmode_t mode) {int ret; + +check_disk_change (bdev); +mutex_lock (&gdrom_mutex); ret =cdrom_open (gd.cd_info, bdev, mode);mutex_unlock (&gdrom_mutex);
drivers/ide/ide-cd.c +2 -0
@@ -1614,6 +1614,8 @@ static int idecd_open(struct block_devicstruct cdrom_info *info;int rc = -ENXIO ; +check_disk_change (bdev); +mutex_lock (&ide_cd_mutex); info =ide_cd_get (bdev->bd_disk);if (!info)
drivers/scsi/sr.c +2 -0
@@ -525,6 +525,8 @@ static int sr_block_open(struct block_destruct scsi_cd *cd;int ret = -ENXIO ; +check_disk_change (bdev); +mutex_lock (&sr_mutex); cd =scsi_cd_get (bdev->bd_disk);if (cd) {
Greg Kroah-Hartman
maintainerPATCH 431/496 efi/arm*: Only register page tables when they exist
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ]
Currently the arm/arm64 runtime code registers the runtime servies pagetables with ptdump regardless of whether runtime services page tables have been created.
As efi_mm.pgd is NULL in these cases, attempting to dump the efi page tables results in a NULL pointer dereference in the ptdump code:
/sys/kernel/debug# cat efi_page_tables
[ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 479.522715] Mem abort info: [ 479.522764] ESR = 0x96000006 [ 479.522850] Exception class = DABT (current EL), IL = 32 bits [ 479.522899] SET = 0, FnV = 0 [ 479.522937] EA = 0, S1PTW = 0 [ 479.528200] Data abort info: [ 479.528230] ISV = 0, ISS = 0x00000006 [ 479.528317] CM = 0, WnR = 0 [ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000064ab0cb0 [ 479.528449] [0000000000000000] *pgd=00000000fbbe4003, *pud=00000000fb66e003, *pmd=0000000000000000 [ 479.528600] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 479.528664] Modules linked in: [ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7 [ 479.528799] Hardware name: FVP Base (DT) [ 479.528899] pstate: 00400009 (nzcv daif +PAN -UAO) [ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0 [ 479.529011] lr : ptdump_walk_pgd+0x30/0x50 [ 479.529105] sp : ffff00000bf4bc20 [ 479.529185] x29: ffff00000bf4bc20 x28: 0000ffff9d22e000 [ 479.529271] x27: 0000000000020000 x26: ffff80007b4c63c0 [ 479.529358] x25: 00000000014000c0 x24: ffff80007c098900 [ 479.529445] x23: ffff00000bf4beb8 x22: 0000000000000000 [ 479.529532] x21: ffff00000bf4bd70 x20: 0000000000000001 [ 479.529618] x19: ffff00000bf4bcb0 x18: 0000000000000000 [ 479.529760] x17: 000000000041a1c8 x16: ffff0000082139d8 [ 479.529800] x15: 0000ffff9d3c6030 x14: 0000ffff9d2527f4 [ 479.529924] x13: 00000000000003f3 x12: 0000000000000038 [ 479.530000] x11: 0000000000000003 x10: 0101010101010101 [ 479.530099] x9 : 0000000017e94050 x8 : 000000000000003f [ 479.530226] x7 : 0000000000000000 x6 : 0000000000000000 [ 479.530313] x5 : 0000000000000001 x4 : 0000000000000000 [ 479.530416] x3 : ffff000009069fd8 x2 : 0000000000000000 [ 479.530500] x1 : 0000000000000000 x0 : 0000000000000000 [ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f) [ 479.530660] Call trace: [ 479.530746] walk_pgd.isra.1+0x20/0x1d0 [ 479.530833] ptdump_walk_pgd+0x30/0x50 [ 479.530907] ptdump_show+0x10/0x20 [ 479.530920] seq_read+0xc8/0x470 [ 479.531023] full_proxy_read+0x60/0x90 [ 479.531100] __vfs_read+0x18/0x100 [ 479.531180] vfs_read+0x88/0x160 [ 479.531267] SyS_read+0x48/0xb0 [ 479.531299] el0_svc_naked+0x20/0x24 [ 479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f9400000) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]---
Segmentation fault
Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use.
--- drivers/firmware/efi/arm-runtime.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/firmware/efi/arm-runtime.c +3 -0
@@ -54,6 +54,9 @@ static struct ptdump_info efi_ptdump_infstatic int __init ptdump_init (void ) { +if (!efi_enabled (EFI_RUNTIME_SERVICES )) +return 0 ; +return ptdump_debugfs_register (&efi_ptdump_info,"efi_page_tables" ); }device_initcall (ptdump_init);
Greg Kroah-Hartman
maintainerPATCH 432/496 perf/x86/intel: Fix large period handling on Broadwell CPUs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit f605cfca8c39ffa2b98c06d2b9f30ba64f1e54e3 ]
Large fixed period values could be truncated on Broadwell, for example:
perf record -e cycles -c 10000000000
Here the fixed period is 0x2540BE400, but the period which finally applied is 0x540BE400 - which is wrong.
The reason is that x86_pmu::limit_period() uses an u32 parameter, so the high 32 bits of 'period' get truncated.
This bug was introduced in:
commit 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
It's safe to use u64 instead of u32:
- Although the 'left' is s64, the value of 'left' must be positive when calling limit_period().
- bdw_limit_period() only modifies the lowest 6 bits, it doesn't touch the higher 32 bits.
--- arch/x86/events/intel/core.c | 2 +- arch/x86/events/perf_event.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/x86/events/intel/core.c +1 -1
@@ -3196,7 +3196,7 @@ glp_get_event_constraints(struct cpu_hw_* Therefore the effective (average) period matches the requested period, * despite coarser hardware granularity. */ -static unsigned bdw_limit_period (struct perf_event *event,unsigned left) +static u64 bdw_limit_period (struct perf_event *event,u64 left) {if ((event->hw.config &INTEL_ARCH_EVENT_MASK ) == X86_CONFIG(.event=0xc0, .umask=0x01)) {
arch/x86/events/perf_event.h +1 -1
@@ -556,7 +556,7 @@ struct x86_pmu {struct x86_pmu_quirk *quirks;int perfctr_second_write;bool late_ack; -unsigned (*limit_period)(struct perf_event *event,unsigned l); +u64 (*limit_period)(struct perf_event *event,u64 l);/* * sysfs attrs
Greg Kroah-Hartman
maintainerPATCH 433/496 perf/x86/intel: Fix event update for auto-reload
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit d31fc13fdcb20e1c317f9a7dd6273c18fbd58308 ]
There is a bug when reading event->count with large PEBS enabled.
Here is an example:
# ./read_count 0x71f0 0x122c0 0x1000000001c54 0x100000001257d 0x200000000bdc5
In fixed period mode, the auto-reload mechanism could be enabled for PEBS events, but the calculation of event->count does not take the auto-reload values into account.
Anyone who reads event->count will get the wrong result, e.g x86_pmu_read().
This bug was introduced with the auto-reload mechanism enabled since commit:
851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible")
Introduce intel_pmu_save_and_restart_reload() to calculate the event->count only for auto-reload.
Since the counter increments a negative counter value and overflows on the sign switch, giving the interval:
[-period, 0]
the difference between two consequtive reads is:
A) value2 - value1;
when no overflows have happened in between,
B) (0 - value1) + (value2 - (-period));
when one overflow happened in between,
C) (0 - value1) + (n - 1) * (period) + (value2 - (-period)); when @n overflows happened in between.
Here A) is the obvious difference, B) is the extension to the discrete interval, where the first term is to the top of the interval and the second term is from the bottom of the next interval and C) the extension to multiple intervals, where the middle term is the whole intervals covered.
The equation for all cases is:
value2 - value1 + n * period
Previously the event->count is updated right before the sample output. But for case A, there is no PEBS record ready. It needs to be specially handled.
Remove the auto-reload code from x86_perf_event_set_period() since we'll not longer call that function in this case.
Based-on-code-from: Peter Zijlstra (Intel) <[email protected]>
--- arch/x86/events/core.c | 15 ++----- arch/x86/events/intel/ds.c | 92 +++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 94 insertions(+), 13 deletions(-)
arch/x86/events/core.c +6 -9
@@ -1162,16 +1162,13 @@ int x86_perf_event_set_period(struct perper_cpu (pmc_prev_left[idx],smp_processor_id ()) = left; -if (!(hwc->flags &PERF_X86_EVENT_AUTO_RELOAD ) || -local64_read (&hwc->prev_count) != (u64)-left) { -/* -* The hw event starts counting from this event offset, -* mark it to be able to extra future deltas: -*/ -local64_set (&hwc->prev_count, (u64)-left); +/* +* The hw event starts counting from this event offset, +* mark it to be able to extra future deltas: +*/ +local64_set (&hwc->prev_count, (u64)-left); -wrmsrl (hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask); - } +wrmsrl (hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);/* * Due to erratum on certan cpu we need
arch/x86/events/intel/ds.c +88 -4
121 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 434/496 arm64: dts: qcom: Fix SPI5 config on MSM8996
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilia Lin <[email protected]>
[ Upstream commit e723795c702b52cfceb3bb3faa63059eb4658313 ]
Set correct clocks and interrupt values. Fixes the incorrect SPI master configuration. This is mandatory to make the SPI5 interface functional.
--- arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/msm8996.dtsi +2 -2
@@ -484,8 +484,8 @@ blsp2_spi5: spi@075ba000{ compatible = "qcom,spi-qup-v2.2.1"; reg = <0x075ba000 0x600>; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&gcc GCC_BLSP2_QUP5_SPI_APPS_CLK>, + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GCC_BLSP2_QUP6_SPI_APPS_CLK>, <&gcc GCC_BLSP2_AHB_CLK>; clock-names = "core", "iface"; pinctrl-names = "default", "sleep";
Greg Kroah-Hartman
maintainerPATCH 435/496 soc: qcom: wcnss_ctrl: Fix increment in NV upload
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit 90c29ed7627b6b4aeb603ee197650173c8434512 ]
hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data.
Instead use fragment size steps through the firmware blob.
--- drivers/soc/qcom/wcnss_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/qcom/wcnss_ctrl.c +1 -1
@@ -249,7 +249,7 @@ static int wcnss_download_nv(struct wcns/* Increment for next fragment */ req->seq++; - data += req->hdr.len; + data +=NV_FRAGMENT_SIZE ; left -=NV_FRAGMENT_SIZE ; }while (left >0 );
Greg Kroah-Hartman
maintainerPATCH 436/496 gfs2: Fix fallocate chunk size
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Gruenbacher <[email protected]>
[ Upstream commit 174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ]
The chunk size of allocations in __gfs2_fallocate is calculated incorrectly. The size can collapse, causing __gfs2_fallocate to allocate one block at a time, which is very inefficient. This needs fixing in two places:
In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate that there is no quota limit. This fixes callers that rely on ap->allowed to be set even when quotas are off.
In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the loop to make sure that allocation limits from one resource group won't spill over into another resource group.
--- fs/gfs2/file.c | 5 +++-- fs/gfs2/quota.h | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-)
fs/gfs2/file.c +3 -2
@@ -803,7 +803,7 @@ static long __gfs2_fallocate(struct filestruct gfs2_inode *ip =GFS2_I (inode);struct gfs2_alloc_parms ap = { .aflags =0 , };unsigned int data_blocks =0 , ind_blocks =0 , rblocks; -loff_t bytes, max_bytes, max_blks =UINT_MAX ; +loff_t bytes, max_bytes, max_blks;int error;const loff_t pos = offset;const loff_t count = len;
@@ -855,7 +855,8 @@ static long __gfs2_fallocate(struct filereturn error;/* ap.allowed tells us how many blocks quota will allow * us to write. Check if this reduces max_blks */ -if (ap.allowed && ap.allowed < max_blks) + max_blks =UINT_MAX ; +if (ap.allowed) max_blks = ap.allowed; error =gfs2_inplace_reserve (ip, &ap);
fs/gfs2/quota.h +2 -0
@@ -45,6 +45,8 @@ static inline int gfs2_quota_lock_check( {struct gfs2_sbd *sdp =GFS2_SB (&ip->i_inode);int ret; + + ap->allowed =UINT_MAX ;/* Assume we are permitted a whole lot */ if (sdp->sd_args.ar_quota ==GFS2_QUOTA_OFF )return 0 ; ret =gfs2_quota_lock (ip,NO_UID_QUOTA_CHANGE ,NO_GID_QUOTA_CHANGE );
Greg Kroah-Hartman
maintainerPATCH 437/496 x86/devicetree: Initialize device tree before using it
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Gorinov <[email protected]>
[ Upstream commit 628df9dc5ad886b0a9b33c75a7b09710eb859ca1 ]
Commit 08d53aa58cb1 added CRC32 calculation in early_init_dt_verify() and checking in late initcall of_fdt_raw_init(), making early_init_dt_verify() mandatory.
The required call to early_init_dt_verify() was not added to the x86-specific implementation, causing failure to create the sysfs entry in of_fdt_raw_init().
--- arch/x86/kernel/devicetree.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/kernel/devicetree.c +5 -3
@@ -12,6 +12,7 @@#include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/of_irq.h> +#include <linux/libfdt.h> #include <linux/slab.h> #include <linux/pci.h> #include <linux/of_pci.h>
@@ -276,14 +277,15 @@ static void __init x86_flattree_get_conf map_len =max (PAGE_SIZE - (initial_dtb & ~PAGE_MASK ), (u64 )128 ); - initial_boot_params = dt =early_memremap (initial_dtb, map_len); - size =of_get_flat_dt_size (); + dt =early_memremap (initial_dtb, map_len); + size =fdt_totalsize (dt);if (map_len < size) {early_memunmap (dt, map_len); - initial_boot_params = dt =early_memremap (initial_dtb, size); + dt =early_memremap (initial_dtb, size); map_len = size; } +early_init_dt_verify (dt);unflatten_and_copy_device_tree ();early_memunmap (dt, map_len); }
Greg Kroah-Hartman
maintainerPATCH 438/496 x86/devicetree: Fix device IRQ settings in DT
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Gorinov <[email protected]>
[ Upstream commit 0a5169add90e43ab45ab1ba34223b8583fcaf675 ]
IRQ parameters for the SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree.
Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.
But x86-specific DT IRQ allocation code casts @arg to of_phandle_args structure pointer and crashes trying to read the IRQ parameters. The function was not converted when the mapping descriptor was changed to irq_fwspec in the generic irqdomain code.
--- arch/x86/kernel/devicetree.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
arch/x86/kernel/devicetree.c +8 -5
@@ -201,19 +201,22 @@ static struct of_ioapic_type of_ioapic_tstatic int dt_irqdomain_alloc (struct irq_domain *domain,unsigned int virq,unsigned int nr_irqs,void *arg) { -struct of_phandle_args *irq_data = (void *)arg; +struct irq_fwspec *fwspec = (struct irq_fwspec *)arg;struct of_ioapic_type *it;struct irq_alloc_info tmp; +int type_index; -if (WARN_ON (irq_data->args_count <2 )) +if (WARN_ON (fwspec->param_count <2 ))return -EINVAL ; -if (irq_data->args[1 ] >=ARRAY_SIZE (of_ioapic_type)) + + type_index = fwspec->param[1 ]; +if (type_index >=ARRAY_SIZE (of_ioapic_type))return -EINVAL ; - it = &of_ioapic_type[irq_data->args[1 ]]; + it = &of_ioapic_type[type_index];ioapic_set_alloc_attr (&tmp,NUMA_NO_NODE , it->trigger, it->polarity); tmp.ioapic_id =mpc_ioapic_id (mp_irqdomain_ioapic_idx (domain)); - tmp.ioapic_pin = irq_data->args[0 ]; + tmp.ioapic_pin = fwspec->param[0 ];return mp_irqdomain_alloc (domain, virq, nr_irqs, &tmp); }
Greg Kroah-Hartman
maintainerPATCH 439/496 phy: rockchip-emmc: retry calpad busy trimming
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
[ Upstream commit a4781c2a74b249cad814ceea7272997bbd20051e ]
It turns out that 5us isn't enough for all cases, so let's retry some more times to wait for caldone.
--- drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
drivers/phy/rockchip/phy-rockchip-emmc.c +17 -10
@@ -76,6 +76,10 @@#define PHYCTRL_OTAPDLYSEL_MASK 0xf#define PHYCTRL_OTAPDLYSEL_SHIFT 0x7 +#define PHYCTRL_IS_CALDONE (x) \ + ((((x) >> PHYCTRL_CALDONE_SHIFT) & \ + PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE) +struct rockchip_emmc_phy {unsigned int reg_offset;struct regmap *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(strucunsigned int freqsel =PHYCTRL_FREQSEL_200M ;unsigned long rate;unsigned long timeout; +int ret;/* * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struc PHYCTRL_PDB_SHIFT));/* -* According to the user manual, it asks driver to -* wait 5us for calpad busy trimming +* According to the user manual, it asks driver to wait 5us for +* calpad busy trimming. However it is documented that this value is +* PVT(A.K.A process,voltage and temperature) relevant, so some +* failure cases are found which indicates we should be more tolerant +* to calpad busy trimming. */ -udelay (5 ); -regmap_read (rk_phy->reg_base, - rk_phy->reg_offset +GRF_EMMCPHY_STATUS , - &caldone); - caldone = (caldone >>PHYCTRL_CALDONE_SHIFT ) &PHYCTRL_CALDONE_MASK ; -if (caldone !=PHYCTRL_CALDONE_DONE ) { -pr_err ("rockchip_emmc_phy_power: caldone timeout.\n" ); -return -ETIMEDOUT ; + ret =regmap_read_poll_timeout (rk_phy->reg_base, + rk_phy->reg_offset +GRF_EMMCPHY_STATUS , + caldone,PHYCTRL_IS_CALDONE (caldone), +0 ,50 ); +if (ret) { +pr_err ("%s: caldone failed, ret=%d\n" , __func__, ret); +return ret; }/* Set the frequency of the DLL operation */
Greg Kroah-Hartman
maintainerPATCH 440/496 ALSA: vmaster: Propagate slave error
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit 2e2c177ca84aff092c3c96714b0f6a12900f3946 ]
In slave_update() of vmaster code ignores the error from the slave get() callback and copies the values. It's not only about the missing error code but also that this may potentially lead to a leak of uninitialized variables when the slave get() don't clear them.
This patch fixes slave_update() not to copy the potentially uninitialized values when an error is returned from the slave get() callback, and to propagate the error value properly.
--- sound/core/vmaster.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
sound/core/vmaster.c +4 -1
@@ -68,10 +68,13 @@ static int slave_update(struct link_slavreturn -ENOMEM ; uctl->id = slave->slave.id; err = slave->slave.get (&slave->slave, uctl); +if (err <0 ) + goto error;for (ch =0 ; ch < slave->info.count; ch++) slave->vals[ch] = uctl->value.integer.value[ch]; + error:kfree (uctl); -return 0 ; +return err <0 ? err :0 ; }/* get the slave ctl info and save the initial values */
Greg Kroah-Hartman
maintainerPATCH 441/496 phy: qcom-qmp: Fix phy pipe clock gating
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Gautam <[email protected]>
[ Upstream commit f8ba22a39e985c93e278709b1d5f20857a26b49b ]
Pipe clock comes out of the phy and is available as long as the phy is turned on. Clock controller fails to gate this clock after the phy is turned off and generates a warning.
/ # [ 33.048561] gcc_usb3_phy_pipe_clk status stuck at 'on'
[ 33.048585] ------------[ cut here ]------------ [ 33.052621] WARNING: CPU: 1 PID: 18 at ../drivers/clk/qcom/clk-branch.c:97 clk_branch_wait+0xf0/0x108 [ 33.057384] Modules linked in: [ 33.066497] CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G W 4.12.0-rc7-00024-gfe926e34c36d-dirty #96 [ 33.069451] Hardware name: Qualcomm Technologies, Inc. DB820c (DT) ... [ 33.278565] [<ffff00000849b27c>] clk_branch_wait+0xf0/0x108 [ 33.286375] [<ffff00000849b2f4>] clk_branch2_disable+0x28/0x34 [ 33.291761] [<ffff0000084868dc>] clk_core_disable+0x5c/0x88 [ 33.297660] [<ffff000008487d68>] clk_core_disable_lock+0x20/0x34 [ 33.303129] [<ffff000008487d98>] clk_disable+0x1c/0x24 [ 33.309384] [<ffff0000083ccd78>] qcom_qmp_phy_poweroff+0x20/0x48 [ 33.314328] [<ffff0000083c53f4>] phy_power_off+0x80/0xdc [ 33.320492] [<ffff00000875c950>] dwc3_core_exit+0x94/0xa0 [ 33.325784] [<ffff00000875c9ac>] dwc3_suspend_common+0x50/0x60 [ 33.331080] [<ffff00000875ca04>] dwc3_runtime_suspend+0x48/0x6c [ 33.336810] [<ffff0000085b82f4>] pm_generic_runtime_suspend+0x28/0x38 [ 33.342627] [<ffff0000085bace0>] __rpm_callback+0x150/0x254 [ 33.349222] [<ffff0000085bae08>] rpm_callback+0x24/0x78 [ 33.354604] [<ffff0000085b9fd8>] rpm_suspend+0xe0/0x4e4 [ 33.359813] [<ffff0000085bb784>] pm_runtime_work+0xdc/0xf0 [ 33.365028] [<ffff0000080d7b30>] process_one_work+0x12c/0x28c [ 33.370576] [<ffff0000080d7ce8>] worker_thread+0x58/0x3b8 [ 33.376393] [<ffff0000080dd4a8>] kthread+0x100/0x12c [ 33.381776] [<ffff0000080836c0>] ret_from_fork+0x10/0x50
Fix this by disabling it as the first thing in phy_exit().
--- drivers/phy/qualcomm/phy-qcom-qmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/phy/qualcomm/phy-qcom-qmp.c +2 -2
@@ -751,8 +751,6 @@ static int qcom_qmp_phy_poweroff(structstruct qmp_phy *qphy =phy_get_drvdata (phy);struct qcom_qmp *qmp = qphy->qmp; -clk_disable_unprepare (qphy->pipe_clk); -regulator_bulk_disable (qmp->cfg->num_vregs, qmp->vregs);return 0 ;
@@ -936,6 +934,8 @@ static int qcom_qmp_phy_exit(struct phyconst struct qmp_phy_cfg *cfg = qmp->cfg;int i = cfg->num_clks; +clk_disable_unprepare (qphy->pipe_clk); +/* PHY reset */ qphy_setbits (qphy->pcs, cfg->regs[QPHY_SW_RESET ],SW_RESET );
Greg Kroah-Hartman
maintainerPATCH 443/496 tools: hv: fix compiler warnings about major/target_fname
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dexuan Cui <[email protected]>
[ Upstream commit 1330fc35327f3ecdfa1aa645e7321ced7349b2cd ]
This patch fixes the below warnings with new glibc and gcc:
hv_vss_daemon.c:100:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is currently
defined by <sys/types.h> as well, but we plan to remove this soon. To use "major", include <sys/sysmacros.h> directly.
hv_fcopy_daemon.c:42:2: note: 'snprintf' output between 2 and 1040 bytes into a destination of size 260
--- tools/hv/hv_fcopy_daemon.c | 3 ++- tools/hv/hv_vss_daemon.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)
tools/hv/hv_fcopy_daemon.c +2 -1
@@ -23,13 +23,14 @@#include <unistd.h> #include <errno.h> #include <linux/hyperv.h> +#include <linux/limits.h> #include <syslog.h> #include <sys/stat.h> #include <fcntl.h> #include <getopt.h> static int target_fd; -static char target_fname[W_MAX_PATH ]; +static char target_fname[PATH_MAX ];static unsigned long long filesize;static int hv_start_fcopy (struct hv_start_fcopy *smsg)
tools/hv/hv_vss_daemon.c +1 -0
@@ -22,6 +22,7 @@#include <sys/poll.h> #include <sys/ioctl.h> #include <sys/stat.h> +#include <sys/sysmacros.h> #include <fcntl.h> #include <stdio.h> #include <mntent.h>
Greg Kroah-Hartman
maintainerPATCH 444/496 block: null_blk: fix Invalid parameters when loading module
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
[ Upstream commit 66231ad3e2886ba99fbf440cea44cab547e5163f ]
On ARM64, the default page size has been 64K on some distributions, and we should allow ARM64 people to play null_blk.
This patch fixes the issue by extend page bitmap size for supporting other non-4KB PAGE_SIZE.
--- drivers/block/null_blk.c | 46 +++++++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 21 deletions(-)
drivers/block/null_blk.c +25 -21
@@ -68,6 +68,7 @@ enum nullb_device_flags { NULLB_DEV_FL_CACHE = 3, }; +#define MAP_SZ ((PAGE_SIZE >> SECTOR_SHIFT) + 2)/* * nullb_page is a page in memory for nullb devices. *
@@ -82,10 +83,10 @@ enum nullb_device_flags {*/ struct nullb_page {struct page *page; -unsigned long bitmap; + DECLARE_BITMAP(bitmap, MAP_SZ); }; -#define NULLB_PAGE_LOCK (sizeof(unsigned long) * 8 - 1) -#define NULLB_PAGE_FREE (sizeof(unsigned long) * 8 - 2) +#define NULLB_PAGE_LOCK (MAP_SZ - 1) +#define NULLB_PAGE_FREE (MAP_SZ - 2)struct nullb_device {struct nullb *nullb;
@@ -725,7 +726,7 @@ static struct nullb_page *null_alloc_pagif (!t_page->page) goto out_freepage; - t_page->bitmap =0 ; +memset (t_page->bitmap,0 ,sizeof (t_page->bitmap));return t_page; out_freepage:kfree (t_page);
@@ -735,13 +736,20 @@ out:static void null_free_page (struct nullb_page *t_page) { -__set_bit (NULLB_PAGE_FREE , &t_page->bitmap); -if (test_bit (NULLB_PAGE_LOCK , &t_page->bitmap)) +__set_bit (NULLB_PAGE_FREE , t_page->bitmap); +if (test_bit (NULLB_PAGE_LOCK , t_page->bitmap))return ;__free_page (t_page->page);kfree (t_page); } +static bool null_page_empty (struct nullb_page *page) +{ +int size =MAP_SZ -2 ; + +return find_first_bit (page->bitmap, size) == size; +} +static void null_free_sector (struct nullb *nullb,sector_t sector,bool is_cache) {
@@ -756,9 +764,9 @@ static void null_free_sector(struct null t_page =radix_tree_lookup (root, idx);if (t_page) { -__clear_bit (sector_bit, &t_page->bitmap); +__clear_bit (sector_bit, t_page->bitmap); -if (!t_page->bitmap) { +if (null_page_empty (t_page)) { ret =radix_tree_delete_item (root, idx, t_page);WARN_ON (ret != t_page);null_free_page (ret);
@@ -829,7 +837,7 @@ static struct nullb_page *__null_lookup_ t_page =radix_tree_lookup (root, idx);WARN_ON (t_page && t_page->page->index != idx); -if (t_page && (for_write ||test_bit (sector_bit, &t_page->bitmap))) +if (t_page && (for_write ||test_bit (sector_bit, t_page->bitmap)))return t_page;return NULL ;
@@ -892,10 +900,10 @@ static int null_flush_cache_page(struct t_page =null_insert_page (nullb, idx <<PAGE_SECTORS_SHIFT , true); -__clear_bit (NULLB_PAGE_LOCK , &c_page->bitmap); -if (test_bit (NULLB_PAGE_FREE , &c_page->bitmap)) { +__clear_bit (NULLB_PAGE_LOCK , c_page->bitmap); +if (test_bit (NULLB_PAGE_FREE , c_page->bitmap)) {null_free_page (c_page); -if (t_page && t_page->bitmap ==0 ) { +if (t_page &&null_page_empty (t_page)) { ret =radix_tree_delete_item (&nullb->dev->data, idx, t_page);null_free_page (t_page);
@@ -911,11 +919,11 @@ static int null_flush_cache_page(structfor (i =0 ; i <PAGE_SECTORS ; i += (nullb->dev->blocksize >>SECTOR_SHIFT )) { -if (test_bit (i, &c_page->bitmap)) { +if (test_bit (i, c_page->bitmap)) { offset = (i <<SECTOR_SHIFT );memcpy (dst + offset, src + offset, nullb->dev->blocksize); -__set_bit (i, &t_page->bitmap); +__set_bit (i, t_page->bitmap); } }
@@ -952,10 +960,10 @@ again:* We found the page which is being flushed to disk by other * threads */ -if (test_bit (NULLB_PAGE_LOCK , &c_pages[i]->bitmap)) +if (test_bit (NULLB_PAGE_LOCK , c_pages[i]->bitmap)) c_pages[i] =NULL ;else -__set_bit (NULLB_PAGE_LOCK , &c_pages[i]->bitmap); +__set_bit (NULLB_PAGE_LOCK , c_pages[i]->bitmap); } one_round =0 ;
@@ -1008,7 +1016,7 @@ static int copy_to_nullb(struct nullb *nkunmap_atomic (dst);kunmap_atomic (src); -__set_bit (sector &SECTOR_MASK , &t_page->bitmap); +__set_bit (sector &SECTOR_MASK , t_page->bitmap);if (is_fua)null_free_sector (nullb, sector, true);
@@ -1922,10 +1930,6 @@ static int __init null_init(void)struct nullb *nullb;struct nullb_device *dev; -/* check for nullb_page.bitmap */ -if (sizeof (unsigned long ) *8 -2 < (PAGE_SIZE >>SECTOR_SHIFT )) -return -EINVAL ; -if (g_bs >PAGE_SIZE ) {pr_warn ("null_blk: invalid block size\n" );pr_warn ("null_blk: defaults block size to %lu\n" ,PAGE_SIZE );
Greg Kroah-Hartman
maintainerPATCH 445/496 dmaengine: pl330: fix a race condition in case of threaded irqs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qi Hou <[email protected]>
[ Upstream commit a3ca831249ca8c4c226e4ceafee04e280152e59d ]
When booting up with "threadirqs" in command line, all irq handlers of the DMA controller pl330 will be threaded forcedly. These threads will race for the same list, pl330->req_done.
Before the callback, the spinlock was released. And after it, the spinlock was taken. This opened an race window where another threaded irq handler could steal the spinlock and be permitted to delete entries of the list, pl330->req_done.
If the later deleted an entry that was still referred to by the former, there would be a kernel panic when the former was scheduled and tried to get the next sibling of the deleted entry.
The scenario could be depicted as below:
Thread: T1 pl330->req_done Thread: T2
| | |
| -A-B-C-D- |
Locked | |
| | Waiting
Del A | |
| -B-C-D- |
Unlocked | |
| | Locked
Waiting | |
| | Del B
| | |
| -C-D- Unlocked
Waiting | |
|
Locked
| get C via B
\
- Kernel panic
The kernel panic looked like as below:
Unable to handle kernel paging request at virtual address dead000000000108 pgd = ffffff8008c9e000 [dead000000000108] *pgd=000000027fffe003, *pud=000000027fffe003, *pmd=0000000000000000 Internal error: Oops: 96000044 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 85 Comm: irq/59-66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2 Hardware name: Broadcom NS2 SVK (DT) task: ffffffc1f5cc3c00 task.stack: ffffffc1f5ce0000 PC is at pl330_irq_handler+0x27c/0x390 LR is at pl330_irq_handler+0x2a8/0x390 pc : [<ffffff80084cb694>] lr : [<ffffff80084cb6c0>] pstate: 800001c5
sp : ffffffc1f5ce3d00
x29: ffffffc1f5ce3d00 x28: 0000000000000140
x27: ffffffc1f5c530b0 x26: dead000000000100
x25: dead000000000200 x24: 0000000000418958
x23: 0000000000000001 x22: ffffffc1f5ccd668
x21: ffffffc1f5ccd590 x20: ffffffc1f5ccd418
x19: dead000000000060 x18: 0000000000000001
x17: 0000000000000007 x16: 0000000000000001
x15: ffffffffffffffff x14: ffffffffffffffff
x13: ffffffffffffffff x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000840
x9 : ffffffc1f5ce0000 x8 : ffffffc1f5cc3338
x7 : ffffff8008ce2020 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001
x3 : dead000000000200 x2 : dead000000000100
x1 : 0000000000000140 x0 : ffffffc1f5ccd590
Process irq/59-66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020)
Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000)
3d00: ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600 3d20: ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998 3d40: ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000 3d60: ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0 3d80: ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001 3da0: ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8 3dc0: ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00 3de0: ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000 3e00: 0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68 3e20: 0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80 3e40: 0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648 3e60: ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00 3e80: ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90 3ea0: 0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0 3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000 3fe0: 0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8
Call trace: Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60)
3b20: dead000000000060 0000008000000000
3b40: ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88 3b60: ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4 3b80: 00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc 3ba0: 0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000 3bc0: 0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140 3be0: dead000000000100 dead000000000200 0000000000000001 0000000000000000 3c00: 0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000 3c20: 0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff 3c40: ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007
[<ffffff80084cb694>] pl330_irq_handler+0x27c/0x390 [<ffffff80080f09d0>] irq_forced_thread_fn+0x38/0x88 [<ffffff80080f0d70>] irq_thread+0x140/0x200 [<ffffff80080bf4f8>] kthread+0xd8/0xf0 [<ffffff8008083690>] ret_from_fork+0x10/0x40 Code: f2a00838 f9405763 aa1c03e1 aa1503e0 (f9000443) ---[ end trace f50005726d31199c ]--- Kernel panic - not syncing: Fatal exception in interrupt
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-1
Kernel Offset: disabled
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception in interrupt
To fix this, re-start with the list-head after dropping the lock then re-takeing it.
--- drivers/dma/pl330.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/dma/pl330.c +4 -2
@@ -1510,7 +1510,7 @@ static void pl330_dotask(unsigned long d/* Returns 1 if state was updated, 0 otherwise */ static int pl330_update (struct pl330_dmac *pl330) { -struct dma_pl330_desc *descdone, *tmp; +struct dma_pl330_desc *descdone;unsigned long flags;void __iomem *regs;u32 val;
@@ -1588,7 +1588,9 @@ static int pl330_update(struct pl330_dma }/* Now that we are in no hurry, do the callbacks */ -list_for_each_entry_safe (descdone, tmp, &pl330->req_done, rqd) { +while (!list_empty (&pl330->req_done)) { + descdone =list_first_entry (&pl330->req_done, + struct dma_pl330_desc, rqd);list_del (&descdone->rqd);spin_unlock_irqrestore (&pl330->lock, flags);dma_pl330_rqcb (descdone,PL330_ERR_NONE );
Greg Kroah-Hartman
maintainerPATCH 446/496 dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
[ Upstream commit 3e081628d510b2ddbe493371d9c574d9275da17e ]
This patch fixes an issue that a race condition happens between a client driver and the rcar-dmac driver:
- The rcar_dmac_isr_transfer_end() is called.
- The done list appears, and desc.running is the next active list.
- rcar_dmac_chan_get_residue() is called by a client driver before rcar_dmac_isr_channel_thread() is called.
- The rcar_dmac_chan_get_residue() will not find any descriptors.
- And, the following WARNING happens:
WARN(1, "No descriptor for cookie!");
The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this situation.
So, this patch checks the done lists in rcar_dmac_chan_get_residue() and returns zero if the done lists has the argument cookie.
--- drivers/dma/sh/rcar-dmac.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/dma/sh/rcar-dmac.c +9 -0
@@ -1264,8 +1264,17 @@ static unsigned int rcar_dmac_chan_get_r* If the cookie doesn't correspond to the currently running transfer * then the descriptor hasn't been processed yet, and the residue is * equal to the full descriptor size. +* Also, a client driver is possible to call this function before +* rcar_dmac_isr_channel_thread() runs. In this case, the "desc.running" +* will be the next descriptor, and the done list will appear. So, if +* the argument cookie matches the done list's cookie, we can assume +* the residue is zero. */ if (cookie != desc->async_tx.cookie) { +list_for_each_entry (desc, &chan->desc.done, node) { +if (cookie == desc->async_tx.cookie) +return 0 ; + }list_for_each_entry (desc, &chan->desc.pending, node) {if (cookie == desc->async_tx.cookie)return desc->size;
Greg Kroah-Hartman
maintainerPATCH 447/496 enic: enable rq before updating rq descriptors
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Govindarajulu Varadarajan <[email protected]>
[ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]
rq should be enabled before posting the buffers to rq desc. If not hw sees stale value and casuses DMAR errors.
--- drivers/net/ethernet/cisco/enic/enic_main.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/ethernet/cisco/enic/enic_main.c +7 -3
@@ -1897,6 +1897,8 @@ static int enic_open(struct net_device * }for (i =0 ; i < enic->rq_count; i++) { +/* enable rq before updating rq desc */ +vnic_rq_enable (&enic->rq[i]);vnic_rq_fill (&enic->rq[i], enic_rq_alloc_buf);/* Need at least one buffer on ring to get going */ if (vnic_rq_desc_used (&enic->rq[i]) ==0 ) {
@@ -1908,8 +1910,6 @@ static int enic_open(struct net_device *for (i =0 ; i < enic->wq_count; i++)vnic_wq_enable (&enic->wq[i]); -for (i =0 ; i < enic->rq_count; i++) -vnic_rq_enable (&enic->rq[i]);if (!enic_is_dynamic (enic) && !enic_is_sriov_vf (enic))enic_dev_add_station_addr (enic);
@@ -1935,8 +1935,12 @@ static int enic_open(struct net_device *return 0 ; err_out_free_rq: -for (i =0 ; i < enic->rq_count; i++) +for (i =0 ; i < enic->rq_count; i++) { + err =vnic_rq_disable (&enic->rq[i]); +if (err) +return err;vnic_rq_clean (&enic->rq[i], enic_free_rq_buf); + }enic_dev_notify_unset (enic); err_out_free_intr:enic_unset_affinity_hint (enic);
Greg Kroah-Hartman
maintainerPATCH 448/496 watchdog: asm9260_wdt: fix error handling in asm9260_wdt_probe()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Khoroshilov <[email protected]>
[ Upstream commit 3c829f47e33eb0398a9a14e357a05199a7be0277 ]
If devm_reset_control_get_exclusive() fails, asm9260_wdt_probe() returns immediately. But clks has been already enabled at that point, so it is required to disable them or to move the code around.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/watchdog/asm9260_wdt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/watchdog/asm9260_wdt.c +4 -4
@@ -292,14 +292,14 @@ static int asm9260_wdt_probe(struct platif (IS_ERR (priv->iobase))return PTR_ERR (priv->iobase); - ret =asm9260_wdt_get_dt_clks (priv); -if (ret) -return ret; - priv->rst =devm_reset_control_get_exclusive (&pdev->dev,"wdt_rst" );if (IS_ERR (priv->rst))return PTR_ERR (priv->rst); + ret =asm9260_wdt_get_dt_clks (priv); +if (ret) +return ret; + wdd = &priv->wdd; wdd->info = &asm9260_wdt_ident; wdd->ops = &asm9260_wdt_ops;
Greg Kroah-Hartman
maintainerPATCH 449/496 hwrng: stm32 - add reset during probe
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ]
Avoid issue when probing the RNG without
reset if bad status has been detected previously
--- drivers/char/hw_random/stm32-rng.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/char/hw_random/stm32-rng.c +9 -0
@@ -21,6 +21,7 @@#include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/pm_runtime.h> +#include <linux/reset.h> #include <linux/slab.h> #define RNG_CR 0x00
@@ -46,6 +47,7 @@ struct stm32_rng_private {struct hwrng rng;void __iomem *base;struct clk *clk; +struct reset_control *rst; };static int stm32_rng_read (struct hwrng *rng,void *data,size_t max,bool wait)
@@ -140,6 +142,13 @@ static int stm32_rng_probe(struct platfoif (IS_ERR (priv->clk))return PTR_ERR (priv->clk); + priv->rst =devm_reset_control_get (&ofdev->dev,NULL ); +if (!IS_ERR (priv->rst)) { +reset_control_assert (priv->rst); +udelay (2 ); +reset_control_deassert (priv->rst); + } +dev_set_drvdata (dev, priv); priv->rng.name = dev_driver_string(dev),
Greg Kroah-Hartman
maintainerPATCH 450/496 pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit b89405b6102fcc3746f43697b826028caa94c823 ]
When dt_to_map_one_config() is called with a pinctrl_dev passed in, it should only be using this if the node being looked up is a hog. The code was always using the passed pinctrl_dev without checking whether the dt node referred to it.
A pin controller can have pinctrl-n dependencies on other pin controllers in these cases:
- the pin controller hardware is external, for example I2C, so needs other pin controller(s) to be setup to communicate with the hardware device.
- it is a child of a composite MFD so its of_node is shared with the parent MFD and other children of that MFD. Any part of that MFD could have dependencies on other pin controllers.
Because of this, dt_to_map_one_config() can't assume that if it has a pinctrl_dev passed in then the node it looks up must be a hog. It could be a reference to some other pin controller.
--- drivers/pinctrl/devicetree.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/pinctrl/devicetree.c +4 -2
@@ -122,8 +122,10 @@ static int dt_to_map_one_config(struct p/* OK let's just assume this will appear later then */ return -EPROBE_DEFER ; } -if (!pctldev) - pctldev =get_pinctrl_dev_from_of_node (np_pctldev); +/* If we're creating a hog we can use the passed pctldev */ +if (pctldev && (np_pctldev == p->dev->of_node)) +break ; + pctldev =get_pinctrl_dev_from_of_node (np_pctldev);if (pctldev)break ;/* Do not defer probing of hogs (circular loop) */
Greg Kroah-Hartman
maintainerPATCH 451/496 pinctrl: artpec6: dt: add missing pin group uart5nocts
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 7e065fb9ccce89fe667fdbd9a177eaec59a359fc ]
Add missing pin group uart5nocts (all pins except cts), which has been supported by the artpec6 pinctrl driver since its initial submission.
--- Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt +3 -2
@@ -20,7 +20,8 @@ Required subnode-properties: gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0, i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0, spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0, - uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0 + uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0, + uart5nocts cpuclkout: cpuclkoutgrp0 udlclkout: udlclkoutgrp0 i2c1: i2c1grp0
@@ -37,7 +38,7 @@ Required subnode-properties: uart2: uart2grp0, uart2grp1 uart3: uart3grp0 uart4: uart4grp0 - uart5: uart5grp0 + uart5: uart5grp0, uart5nocts nand: nandgrp0 sdio0: sdio0grp0 sdio1: sdio1grp0
Greg Kroah-Hartman
maintainerPATCH 452/496 vfio-ccw: fence off transport mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cornelia Huck <[email protected]>
[ Upstream commit 9851bc77e62499957567e7c39a5beba7d6de6296 ]
vfio-ccw only supports command mode for channel programs, not transport mode. User space is supposed to already take care of that and pass us command-mode ORBs only, but better make sure and return an error to the caller instead of trying to process tcws as ccws.
--- drivers/s390/cio/vfio_ccw_fsm.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/s390/cio/vfio_ccw_fsm.c +5 -0
@@ -129,6 +129,11 @@ static void fsm_io_request(struct vfio_cif (scsw->cmd.fctl &SCSW_FCTL_START_FUNC ) { orb = (union orb *)io_region->orb_area; +/* Don't try to build a cp if transport mode is specified. */ +if (orb->tm.b) { + io_region->ret_code = -EOPNOTSUPP ; + goto err_out; + } io_region->ret_code =cp_init (&private->cp,mdev_dev (mdev), orb);if (io_region->ret_code)
Greg Kroah-Hartman
maintainerPATCH 453/496 dmaengine: qcom: bam_dma: get num-channels and num-ees from dt
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
[ Upstream commit 48d163b1aa6e7f650c0b7a4f9c61c387a6def868 ]
When Linux is master of BAM, it can directly read registers to know number of supported channels, however when its remotely controlled reading these registers would trigger a crash if the BAM is not yet initialized or powered up on the remote side.
This patch allows driver to read num-channels and num-ees from Device Tree for remotely controlled BAM.
--- drivers/dma/qcom/bam_dma.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-)
drivers/dma/qcom/bam_dma.c +22 -5
@@ -388,6 +388,7 @@ struct bam_device {struct device_dma_parameters dma_parms;struct bam_chan *channels;u32 num_channels; +u32 num_ees;/* execution environment ID, from DT */ u32 ee;
@@ -1080,15 +1081,19 @@ static int bam_init(struct bam_device *bu32 val;/* read revision and configuration information */ - val =readl_relaxed (bam_addr (bdev,0 ,BAM_REVISION )) >>NUM_EES_SHIFT ; - val &=NUM_EES_MASK ; +if (!bdev->num_ees) { + val =readl_relaxed (bam_addr (bdev,0 ,BAM_REVISION )); + bdev->num_ees = (val >>NUM_EES_SHIFT ) &NUM_EES_MASK ; + }/* check that configured EE is within range */ -if (bdev->ee >= val) +if (bdev->ee >= bdev->num_ees)return -EINVAL ; - val =readl_relaxed (bam_addr (bdev,0 ,BAM_NUM_PIPES )); - bdev->num_channels = val &BAM_NUM_PIPES_MASK ; +if (!bdev->num_channels) { + val =readl_relaxed (bam_addr (bdev,0 ,BAM_NUM_PIPES )); + bdev->num_channels = val &BAM_NUM_PIPES_MASK ; + }if (bdev->controlled_remotely)return 0 ;
@@ -1183,6 +1188,18 @@ static int bam_dma_probe(struct platform bdev->controlled_remotely =of_property_read_bool (pdev->dev.of_node,"qcom,controlled-remotely" ); +if (bdev->controlled_remotely) { + ret =of_property_read_u32 (pdev->dev.of_node,"num-channels" , + &bdev->num_channels); +if (ret) +dev_err (bdev->dev,"num-channels unspecified in dt\n" ); + + ret =of_property_read_u32 (pdev->dev.of_node,"qcom,num-ees" , + &bdev->num_ees); +if (ret) +dev_err (bdev->dev,"num-ees unspecified in dt\n" ); + } + bdev->bamclk =devm_clk_get (bdev->dev,"bam_clk" );if (IS_ERR (bdev->bamclk))return PTR_ERR (bdev->bamclk);
Greg Kroah-Hartman
maintainerPATCH 454/496 drm: omapdrm: dss: Move initialization code from component bind to probe
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ]
There's no reason to delay initialization of most of the driver (such as mapping memory I/O, getting clocks or enabling runtime PM) to the component master bind handler.
This additionally fixes a real PM issue caused enabling runtime PM in the bind handler.
The bind handler performs the following sequence of PM operations:
pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... (access the hardware to read the device revision) ... pm_runtime_put_sync(dev);
If a failure occurs at this point, the error path calls pm_runtime_disable() to balance the pm_runtime_enable() call.
To understand the problem, it should be noted that the bind handler is called when one of the component registers itself, which happens in the component's probe handler. Furthermore, as the components are children of the DSS, the device core calls pm_runtime_get_sync() on the DSS platform device before calling the component's probe handler. This increases the DSS power usage count but doesn't runtime resume the device, as runtime PM is disabled at that point.
The bind handler is thus called with runtime PM disabled, with the device runtime suspended, but with the power usage count larger than 0. The pm_runtime_get_sync() call will thus further increase the power usage count and runtime resume the device. The pm_runtime_put_sync() handler will decrease the power usage count to a non-zero value and will thus not suspend the device. Finally, the pm_runtime_disable() call will disable runtime PM, preventing the pm_runtime_put() call in the device core from runtime suspending the device. The DSS device is thus left powered on.
To fix this, move the initialization code from the bind handler to the probe handler.
--- drivers/gpu/drm/omapdrm/dss/dss.c | 193 ++++++++++++++++++++------------------ 1 file changed, 104 insertions(+), 89 deletions(-)
drivers/gpu/drm/omapdrm/dss/dss.c +104 -89
@@ -1299,88 +1299,18 @@ static const struct soc_device_attributestatic int dss_bind (struct device *dev) { -struct platform_device *pdev =to_platform_device (dev); -struct resource *dss_mem; -u32 rev;int r; - dss_mem =platform_get_resource (dss.pdev,IORESOURCE_MEM ,0 ); - dss.base =devm_ioremap_resource (&pdev->dev, dss_mem); -if (IS_ERR (dss.base)) -return PTR_ERR (dss.base); - - r =dss_get_clocks (); + r =component_bind_all (dev,NULL );if (r)return r; - r =dss_setup_default_clock (); -if (r) - goto err_setup_clocks; - - r =dss_video_pll_probe (pdev); -if (r) - goto err_pll_init; - - r =dss_init_ports (pdev); -if (r) - goto err_init_ports; - -pm_runtime_enable (&pdev->dev); - - r =dss_runtime_get (); -if (r) - goto err_runtime_get; - - dss.dss_clk_rate =clk_get_rate (dss.dss_clk); - -/* Select DPLL */ -REG_FLD_MOD (DSS_CONTROL ,0 ,0 ,0 ); - -dss_select_dispc_clk_source (DSS_CLK_SRC_FCK ); - -#ifdef CONFIG_OMAP2_DSS_VENC -REG_FLD_MOD (DSS_CONTROL ,1 ,4 ,4 );/* venc dac demen */ -REG_FLD_MOD (DSS_CONTROL ,1 ,3 ,3 );/* venc clock 4x enable */ -REG_FLD_MOD (DSS_CONTROL ,0 ,2 ,2 );/* venc clock mode = normal */ -#endif - dss.dsi_clk_source[0 ] =DSS_CLK_SRC_FCK ; - dss.dsi_clk_source[1 ] =DSS_CLK_SRC_FCK ; - dss.dispc_clk_source =DSS_CLK_SRC_FCK ; - dss.lcd_clk_source[0 ] =DSS_CLK_SRC_FCK ; - dss.lcd_clk_source[1 ] =DSS_CLK_SRC_FCK ; - - rev =dss_read_reg (DSS_REVISION ); -pr_info ("OMAP DSS rev %d.%d\n" ,FLD_GET (rev,7 ,4 ),FLD_GET (rev,3 ,0 )); - -dss_runtime_put (); - - r =component_bind_all (&pdev->dev,NULL ); -if (r) - goto err_component; - -dss_debugfs_create_file ("dss" , dss_dump_regs); -pm_set_vt_switch (0 );omapdss_gather_components (dev);omapdss_set_is_initialized (true);return 0 ; - -err_component: -err_runtime_get: -pm_runtime_disable (&pdev->dev); -dss_uninit_ports (pdev); -err_init_ports: -if (dss.video1_pll) -dss_video_pll_uninit (dss.video1_pll); - -if (dss.video2_pll) -dss_video_pll_uninit (dss.video2_pll); -err_pll_init: -err_setup_clocks: -dss_put_clocks (); -return r; }static void dss_unbind (struct device *dev)
@@ -1390,18 +1320,6 @@ static void dss_unbind(struct device *deomapdss_set_is_initialized (false);component_unbind_all (&pdev->dev,NULL ); - -if (dss.video1_pll) -dss_video_pll_uninit (dss.video1_pll); - -if (dss.video2_pll) -dss_video_pll_uninit (dss.video2_pll); - -dss_uninit_ports (pdev); - -pm_runtime_disable (&pdev->dev); - -dss_put_clocks (); }static const struct component_master_ops dss_component_ops = {
@@ -1433,10 +1351,46 @@ static int dss_add_child_component(strucreturn 0 ; } +static int dss_probe_hardware (void ) +{ +u32 rev; +int r; + + r =dss_runtime_get (); +if (r) +return r; + + dss.dss_clk_rate =clk_get_rate (dss.dss_clk); + +/* Select DPLL */ +REG_FLD_MOD (DSS_CONTROL ,0 ,0 ,0 ); + +dss_select_dispc_clk_source (DSS_CLK_SRC_FCK ); + +#ifdef CONFIG_OMAP2_DSS_VENC +REG_FLD_MOD (DSS_CONTROL ,1 ,4 ,4 );/* venc dac demen */ +REG_FLD_MOD (DSS_CONTROL ,1 ,3 ,3 );/* venc clock 4x enable */ +REG_FLD_MOD (DSS_CONTROL ,0 ,2 ,2 );/* venc clock mode = normal */ +#endif + dss.dsi_clk_source[0 ] =DSS_CLK_SRC_FCK ; + dss.dsi_clk_source[1 ] =DSS_CLK_SRC_FCK ; + dss.dispc_clk_source =DSS_CLK_SRC_FCK ; + dss.lcd_clk_source[0 ] =DSS_CLK_SRC_FCK ; + dss.lcd_clk_source[1 ] =DSS_CLK_SRC_FCK ; + + rev =dss_read_reg (DSS_REVISION ); +pr_info ("OMAP DSS rev %d.%d\n" ,FLD_GET (rev,7 ,4 ),FLD_GET (rev,3 ,0 )); + +dss_runtime_put (); + +return 0 ; +} +static int dss_probe (struct platform_device *pdev) {const struct soc_device_attribute *soc;struct component_match *match =NULL ; +struct resource *dss_mem;int r; dss.pdev = pdev;
@@ -1451,20 +1405,69 @@ static int dss_probe(struct platform_develse dss.feat =of_match_device (dss_of_match, &pdev->dev)->data; - r =dss_initialize_debugfs (); +/* Map I/O registers, get and setup clocks. */ + dss_mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); + dss.base =devm_ioremap_resource (&pdev->dev, dss_mem); +if (IS_ERR (dss.base)) +return PTR_ERR (dss.base); + + r =dss_get_clocks ();if (r)return r; -/* add all the child devices as components */ + r =dss_setup_default_clock (); +if (r) + goto err_put_clocks; + +/* Setup the video PLLs and the DPI and SDI ports. */ + r =dss_video_pll_probe (pdev); +if (r) + goto err_put_clocks; + + r =dss_init_ports (pdev); +if (r) + goto err_uninit_plls; + +/* Enable runtime PM and probe the hardware. */ +pm_runtime_enable (&pdev->dev); + + r =dss_probe_hardware (); +if (r) + goto err_pm_runtime_disable; + +/* Initialize debugfs. */ + r =dss_initialize_debugfs (); +if (r) + goto err_pm_runtime_disable; + +dss_debugfs_create_file ("dss" , dss_dump_regs); + +/* Add all the child devices as components. */ device_for_each_child (&pdev->dev, &match, dss_add_child_component); r =component_master_add_with_match (&pdev->dev, &dss_component_ops, match); -if (r) { -dss_uninitialize_debugfs (); -return r; - } +if (r) + goto err_uninit_debugfs;return 0 ; + +err_uninit_debugfs: +dss_uninitialize_debugfs (); + +err_pm_runtime_disable: +pm_runtime_disable (&pdev->dev); +dss_uninit_ports (pdev); + +err_uninit_plls: +if (dss.video1_pll) +dss_video_pll_uninit (dss.video1_pll); +if (dss.video2_pll) +dss_video_pll_uninit (dss.video2_pll); + +err_put_clocks: +dss_put_clocks (); + +return r; }static int dss_remove (struct platform_device *pdev)
@@ -1473,6 +1476,18 @@ static int dss_remove(struct platform_dedss_uninitialize_debugfs (); +pm_runtime_disable (&pdev->dev); + +dss_uninit_ports (pdev); + +if (dss.video1_pll) +dss_video_pll_uninit (dss.video1_pll); + +if (dss.video2_pll) +dss_video_pll_uninit (dss.video2_pll); + +dss_put_clocks (); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 455/496 ARM: dts: dra71-evm: Correct evm_sd regulator max voltage
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ravikumar Kattekola <[email protected]>
[ Upstream commit f4aa1bd5b4fc80f5f4ecd184caad832fd62c25f7 ]
Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V
--- arch/arm/boot/dts/dra71-evm.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/dra71-evm.dts +2 -2
@@ -24,13 +24,13 @@ regulator-name = "vddshv8"; regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3000000>; + regulator-max-microvolt = <3300000>; regulator-boot-on; vin-supply = <&evm_5v0>; gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>; states = <1800000 0x0 - 3000000 0x1>; + 3300000 0x1>; }; evm_1v8_sw: fixedregulator-evm_1v8 {
Greg Kroah-Hartman
maintainerPATCH 456/496 drm/amdgpu: disable GFX ring and disable PQ wptr in hw_fini
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Monk Liu <[email protected]>
[ Upstream commit 9f0178fb67699992d38601cb923b434f9986dd68 ]
otherwise there will be DMAR reading error comes out from CP since GFX is still alive and CPC's WPTR_POLL is still enabled, which would lead to DMAR read error.
fix:
we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ stil need to be alive to let RLCV invoke, but its WPTR_POLL could be disabled.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +7 -1
@@ -2889,7 +2889,13 @@ static int gfx_v9_0_hw_fini(void *handleamdgpu_irq_put (adev, &adev->gfx.priv_reg_irq,0 );amdgpu_irq_put (adev, &adev->gfx.priv_inst_irq,0 );if (amdgpu_sriov_vf (adev)) { -pr_debug ("For SRIOV client, shouldn't do anything.\n" ); +gfx_v9_0_cp_gfx_enable (adev, false); +/* must disable polling for SRIOV when hw finished, otherwise +* CPC engine may still keep fetching WB address which is already +* invalid after sw finished and trigger DMAR reading error in +* hypervisor side. +*/ +WREG32_FIELD15 (GC ,0 ,CP_PQ_WPTR_POLL_CNTL ,EN ,0 );return 0 ; }gfx_v9_0_cp_enable (adev, false);
Greg Kroah-Hartman
maintainerPATCH 458/496 net: stmmac: ensure that the device has released ownership before reading data
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit a6b25da5e7ba212af5826a662e6a035a79bffabd ]
According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit.
This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields, e.g. reading the tx hardware timestamp (if PTP is enabled).
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +5 -0
@@ -1829,6 +1829,11 @@ static void stmmac_tx_clean(struct stmmaif (unlikely (status & tx_dma_own))break ; +/* Make sure descriptor fields are read after reading +* the own bit. +*/ +dma_rmb (); +/* Just consider the last segment and ...*/ if (likely (!(status & tx_not_ls))) {/* ... verify the status error condition */
Greg Kroah-Hartman
maintainerPATCH 459/496 net: stmmac: ensure that the MSS desc is the last desc to set the own bit
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 15d2ee42a3087089e73ad52fd8c1b37ab496b87c ]
A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory.
There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc.
However, in the rare case that MSS changes, there will be a MSS context descriptor in front of the regular DMA descriptors:
<MSS desc> <- DMA Next Descriptor
<First Desc>
<desc n>
<Last Desc>
Thus, for this special case, we need a dma_wmb()
after prepare_tso_tx_desc()/before writing the own bit to the MSS desc, so that we flush the write to TDES3 for First Desc,
in order to ensure that the MSS descriptor is the last descriptor to set the own bit.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +8 -1
@@ -2923,8 +2923,15 @@ static netdev_tx_t stmmac_tso_xmit(struc tcp_hdrlen(skb) / 4, (skb->len - proto_hdr_len));/* If context desc is used to change MSS */ -if (mss_desc) +if (mss_desc) { +/* Make sure that first descriptor has been completely +* written, including its own bit. This is because MSS is +* actually before first descriptor, so we need to make +* sure that MSS's own bit is the last thing written. +*/ +dma_wmb (); priv->hw->desc->set_tx_owner (mss_desc); + }/* The own bit must be the latest setting done when prepare the * descriptor and then barrier is needed to make sure that
Greg Kroah-Hartman
maintainerPATCH 460/496 cpufreq: Reorder cpufreq_online() error code path
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <[email protected]>
[ Upstream commit b24b6478e65f140610ab1ffaadc7bc6bf0be8aad ]
Ideally the de-allocation of resources should happen in the exact opposite order in which they were allocated. It helps maintain the code in long term, even if nothing really breaks with incorrect ordering.
That wasn't followed in cpufreq_online() and it has some inconsistencies. For example, the symlinks were created from within the locked region while they are removed only after putting the locks. Also ->exit() should have been called only after the symlinks are removed and the lock is dropped, as that was the case when ->init() was first called.
--- drivers/cpufreq/cpufreq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/cpufreq/cpufreq.c +3 -3
@@ -1315,14 +1315,14 @@ static int cpufreq_online(unsigned int creturn 0 ; out_exit_policy: +for_each_cpu (j, policy->real_cpus) +remove_cpu_dev_symlink (policy,get_cpu_device (j)); +up_write (&policy->rwsem);if (cpufreq_driver->exit) cpufreq_driver->exit (policy); -for_each_cpu (j, policy->real_cpus) -remove_cpu_dev_symlink (policy,get_cpu_device (j)); - out_free_policy:cpufreq_policy_free (policy);return ret;
Greg Kroah-Hartman
maintainerPATCH 461/496 dpaa_eth: fix SG mapping
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Madalin Bucur <[email protected]>
[ Upstream commit 120d75ecf043044554abbba8507f6d22e4715beb ]
An issue in the code mapping the skb fragments into scatter-gather frames was evidentiated by netperf TCP_SENDFILE tests. The size was set wrong for all fragments but the first, affecting the transmission of any skb with more than one fragment.
--- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +13 -10
@@ -1930,8 +1930,10 @@ static int skb_to_sg_fd(struct dpaa_priv goto csum_failed; } +/* SGT[0] is used by the linear part */ sgt = (struct qm_sg_entry *)(sgt_buf + priv->tx_headroom); -qm_sg_entry_set_len (&sgt[0 ],skb_headlen (skb)); + frag_len =skb_headlen (skb); +qm_sg_entry_set_len (&sgt[0 ], frag_len); sgt[0 ].bpid =FSL_DPAA_BPID_INV ; sgt[0 ].offset =0 ; addr = dma_map_single(dev, skb->data,
@@ -1944,9 +1946,9 @@ static int skb_to_sg_fd(struct dpaa_privqm_sg_entry_set64 (&sgt[0 ], addr);/* populate the rest of SGT entries */ - frag = &skb_shinfo (skb)->frags[0 ]; - frag_len = frag->size; -for (i =1 ; i <= nr_frags; i++, frag++) { +for (i =0 ; i < nr_frags; i++) { + frag = &skb_shinfo (skb)->frags[i]; + frag_len = frag->size;WARN_ON (!skb_frag_page (frag)); addr =skb_frag_dma_map (dev, frag,0 , frag_len, dma_dir);
@@ -1956,15 +1958,16 @@ static int skb_to_sg_fd(struct dpaa_priv goto sg_map_failed; } -qm_sg_entry_set_len (&sgt[i], frag_len); - sgt[i].bpid =FSL_DPAA_BPID_INV ; - sgt[i].offset =0 ; +qm_sg_entry_set_len (&sgt[i +1 ], frag_len); + sgt[i +1 ].bpid =FSL_DPAA_BPID_INV ; + sgt[i +1 ].offset =0 ;/* keep the offset in the address */ -qm_sg_entry_set64 (&sgt[i], addr); - frag_len = frag->size; +qm_sg_entry_set64 (&sgt[i +1 ], addr); } -qm_sg_entry_set_f (&sgt[i -1 ], frag_len); + +/* Set the final bit in the last used entry of the SGT */ +qm_sg_entry_set_f (&sgt[nr_frags], frag_len);qm_fd_set_sg (fd, priv->tx_headroom, skb->len);
Greg Kroah-Hartman
maintainerPATCH 462/496 PCI: Add function 1 DMA alias quirk for Marvell 88SE9220
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Vincent-Cross <[email protected]>
[ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]
Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.
--- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pci/quirks.c +3 -0
@@ -3896,6 +3896,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c46 */ DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x91a0 , quirk_dma_func1_alias); +/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c127 */ +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9220 , + quirk_dma_func1_alias);/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */ DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9230 , quirk_dma_func1_alias);
Greg Kroah-Hartman
maintainerPATCH 464/496 ixgbe: prevent ptp_rx_hang from running when in FILTER_ALL mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit 6704a3abf4cf4181a1ee64f5db4969347b88ca1d ]
On hardware which supports timestamping all packets, the timestamps are recorded in the packet buffer, and the driver no longer uses or reads the registers. This makes the logic for checking and clearing Rx timestamp hangs meaningless.
If we run the ixgbe_ptp_rx_hang() function in this case, then the driver will continuously spam the log output with "Clearing Rx timestamp hang". These messages are spurious, and confusing to end users.
The original code in commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices", 2015-12-03) did have a flag PTP_RX_TIMESTAMP_IN_REGISTER which was intended to be used to avoid the Rx timestamp hang check, however it did not actually check the flag before calling the function.
Do so now in order to stop the checks and prevent the spurious log messages.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +2 -1
@@ -7658,7 +7658,8 @@ static void ixgbe_service_task(struct woif (test_bit (__IXGBE_PTP_RUNNING, &adapter->state)) {ixgbe_ptp_overflow_check (adapter); -ixgbe_ptp_rx_hang (adapter); +if (adapter->flags &IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ) +ixgbe_ptp_rx_hang (adapter);ixgbe_ptp_tx_hang (adapter); }
Greg Kroah-Hartman
maintainerPATCH 465/496 sh_eth: fix TSU init on SH7734/R8A7740
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit a94cf2a614f8bc5b2b33c708626ce695bf71e424 ]
It appears that the single port Ether controllers having TSU (like SH7734/ R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100 currently has -- they also don't have the TSU registers related e.g. to passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port' flag and use it as a new criterion for taking a "short path" in the TSU init sequence in order to avoid writing to the non-existent registers...
--- drivers/net/ethernet/renesas/sh_eth.c | 6 +++++- drivers/net/ethernet/renesas/sh_eth.h | 1 + 2 files changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/renesas/sh_eth.c +5 -1
@@ -753,6 +753,7 @@ static struct sh_eth_cpu_data sh7757_dat .rpadir = 1, .rpadir_value = 2 << 16, .rtrate = 1, + .dual_port = 1, };#define SH_GIGA_ETH_BASE 0xfee00000UL
@@ -831,6 +832,7 @@ static struct sh_eth_cpu_data sh7757_dat .no_trimd = 1, .no_ade = 1, .tsu = 1, + .dual_port = 1, };/* SH7734 */
@@ -901,6 +903,7 @@ static struct sh_eth_cpu_data sh7763_dat .tsu = 1, .irq_flags = IRQF_SHARED, .magic = 1, + .dual_port = 1, };static struct sh_eth_cpu_data sh7619_data = {
@@ -933,6 +936,7 @@ static struct sh_eth_cpu_data sh771x_datEESIPR_RRFIP |EESIPR_RTLFIP |EESIPR_RTSFIP | EESIPR_PREIP | EESIPR_CERFIP, .tsu = 1, + .dual_port = 1, };static void sh_eth_set_default_cpu_data (struct sh_eth_cpu_data *cd)
@@ -2911,7 +2915,7 @@ static int sh_eth_vlan_rx_kill_vid(struc/* SuperH's TSU register init function */ static void sh_eth_tsu_init (struct sh_eth_private *mdp) { -if (sh_eth_is_rz_fast_ether (mdp)) { +if (!mdp->cd->dual_port) {sh_eth_tsu_write (mdp,0 ,TSU_TEN );/* Disable all CAM entry */ sh_eth_tsu_write (mdp,TSU_FWSLC_POSTENU |TSU_FWSLC_POSTENL ,TSU_FWSLC );/* Enable POST registers */
drivers/net/ethernet/renesas/sh_eth.h +1 -0
@@ -509,6 +509,7 @@ struct sh_eth_cpu_data { unsigned rmiimode:1; /* EtherC has RMIIMODE register */ unsigned rtrate:1; /* EtherC has RTRATE register */ unsigned magic:1; /* EtherC has ECMR.MPDE and ECSR.MPD */ + unsigned dual_port:1; /* Dual EtherC/E-DMAC */ };struct sh_eth_private {
Greg Kroah-Hartman
maintainerPATCH 466/496 power: supply: ltc2941-battery-gauge: Fix temperature units
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ladislav Michl <[email protected]>
[ Upstream commit dde5953f05a89eb63a0d666ffe51d447b2ac3e05 ]
Temperature is measured in tenths of degree Celsius.
--- drivers/power/supply/ltc2941-battery-gauge.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/power/supply/ltc2941-battery-gauge.c +4 -4
@@ -316,15 +316,15 @@ static int ltc294x_get_temperature(constif (info->id ==LTC2942_ID ) { reg =LTC2942_REG_TEMPERATURE_MSB ; - value =60000 ;/* Full-scale is 600 Kelvin */ + value =6000 ;/* Full-scale is 600 Kelvin */ }else { reg =LTC2943_REG_TEMPERATURE_MSB ; - value =51000 ;/* Full-scale is 510 Kelvin */ + value =5100 ;/* Full-scale is 510 Kelvin */ } ret =ltc294x_read_regs (info->client, reg, &datar[0 ],2 ); value *= (datar[0 ] <<8 ) | datar[1 ]; -/* Convert to centidegrees */ - *val = value /0xFFFF -27215 ; +/* Convert to tenths of degree Celsius */ + *val = value /0xFFFF -2722 ;return ret; }
Greg Kroah-Hartman
maintainerPATCH 467/496 ARM: dts: bcm283x: Fix probing of bcm2835-i2s
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
[ Upstream commit 79c81facdc0b43b1cef37b8d5689a8c8b78f8be0 ]
Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework") the bcm2835-i2s requires a clock as DT property. Unfortunately the necessary DT change has never been applied. While we are at it also fix the first PCM register range to cover the PCM_GRAY register.
--- arch/arm/boot/dts/bcm283x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/bcm283x.dtsi +2 -2
@@ -396,8 +396,8 @@ i2s: i2s@7e203000 { compatible = "brcm,bcm2835-i2s"; - reg = <0x7e203000 0x20>, - <0x7e101098 0x02>; + reg = <0x7e203000 0x24>; + clocks = <&clocks BCM2835_CLOCK_PCM>; dmas = <&dma 2>, <&dma 3>;
Greg Kroah-Hartman
maintainerPATCH 468/496 ARM: dts: bcm283x: Fix pin function of JTAG pins
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henry Zhang <[email protected]>
[ Upstream commit 1a012cb2569f2031b3636232c3ab21c20c92d281 ]
BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13 carry altenate function, ALT5 for ARM JTAG
--- arch/arm/boot/dts/bcm283x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/bcm283x.dtsi +1 -1
@@ -251,7 +251,7 @@ jtag_gpio4: jtag_gpio4 { brcm,pins = <4 5 6 12 13>; - brcm,function = <BCM2835_FSEL_ALT4>; + brcm,function = <BCM2835_FSEL_ALT5>; }; jtag_gpio22: jtag_gpio22 { brcm,pins = <22 23 24 25 26 27>;
Greg Kroah-Hartman
maintainerPATCH 469/496 PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
[ Upstream commit dbdd0f58fd2cdde5cf945c9da67a2d52d32ba550 ]
There is a problem with PCMCIA system resume callbacks with respect to suspend-to-idle in which the ->suspend_noirq() callback may be invoked after the ->resume_noirq() one without resuming the system entirely in some cases. This doesn't work for PCMCIA because of the lack of symmetry between its system suspend and system resume "noirq" callbacks.
The system resume handling in PCMCIA is split between socket_early_resume() and socket_late_resume() which are called in different phases of system resume and both need to run for socket_suspend() (invoked by the system suspend "noirq" callback) to work. Specifically, socket_suspend() returns an error when called after socket_early_resume() without socket_late_resume(), so if the suspend-to-idle core detects a spurious wakeup event and attempts to put the system back to sleep, that is aborted by the error coming from socket_suspend().
Avoid that by using a new socket state flag, SOCKET_IN_RESUME, to indicate that socket_early_resume() has already run for the socket in which case socket_suspend() will do minimum handling and return 0.
This change has been tested on my venerable Toshiba Portege R500 (which is where the problem has been discovered in the first place), but admittedly I have no PCMCIA cards to test along with the socket itself.
--- drivers/pcmcia/cs.c | 10 +++++++--- drivers/pcmcia/cs_internal.h | 1 + 2 files changed, 8 insertions(+), 3 deletions(-)
drivers/pcmcia/cs.c +7 -3
@@ -452,17 +452,20 @@ static int socket_insert(struct pcmcia_sstatic int socket_suspend (struct pcmcia_socket *skt) { -if (skt->state &SOCKET_SUSPEND ) +if ((skt->state &SOCKET_SUSPEND ) && !(skt->state &SOCKET_IN_RESUME ))return -EBUSY ;mutex_lock (&skt->ops_mutex); - skt->suspended_state = skt->state; +/* store state on first suspend, but not after spurious wakeups */ +if (!(skt->state &SOCKET_IN_RESUME )) + skt->suspended_state = skt->state; skt->socket = dead_socket; skt->ops->set_socket (skt, &skt->socket);if (skt->ops->suspend) skt->ops->suspend (skt); skt->state |=SOCKET_SUSPEND ; + skt->state &= ~SOCKET_IN_RESUME ;mutex_unlock (&skt->ops_mutex);return 0 ; }
@@ -475,6 +478,7 @@ static int socket_early_resume(struct pc skt->ops->set_socket (skt, &skt->socket);if (skt->state &SOCKET_PRESENT ) skt->resume_status =socket_setup (skt, resume_delay); + skt->state |=SOCKET_IN_RESUME ;mutex_unlock (&skt->ops_mutex);return 0 ; }
@@ -484,7 +488,7 @@ static int socket_late_resume(struct pcmint ret =0 ;mutex_lock (&skt->ops_mutex); - skt->state &= ~SOCKET_SUSPEND ; + skt->state &= ~(SOCKET_SUSPEND |SOCKET_IN_RESUME );mutex_unlock (&skt->ops_mutex);if (!(skt->state &SOCKET_PRESENT )) {
drivers/pcmcia/cs_internal.h +1 -0
@@ -70,6 +70,7 @@ struct pccard_resource_ops {/* Flags in socket state */ #define SOCKET_PRESENT 0x0008#define SOCKET_INUSE 0x0010 +#define SOCKET_IN_RESUME 0x0040#define SOCKET_SUSPEND 0x0080#define SOCKET_WIN_REQ (i) (0x0100<<(i))#define SOCKET_CARDBUS 0x8000
Greg Kroah-Hartman
maintainerPATCH 470/496 audit: return on memory error to avoid null pointer dereference
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Guy Briggs <[email protected]>
[ Upstream commit 23138ead270045f1b3e912e667967b6094244999 ]
If there is a memory allocation error when trying to change an audit kernel feature value, the ignored allocation error will trigger a NULL pointer dereference oops on subsequent use of that pointer. Return instead.
Passes audit-testsuite.
See: https://github.com/linux-audit/audit-kernel/issues/76
--- kernel/audit.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/audit.c +2 -0
@@ -1058,6 +1058,8 @@ static void audit_log_feature_change(intreturn ; ab =audit_log_start (NULL ,GFP_KERNEL ,AUDIT_FEATURE_CHANGE ); +if (!ab) +return ;audit_log_task_info (ab, current); audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u res=%d", audit_feature_names[which], !!old_feature, !!new_feature,
Greg Kroah-Hartman
maintainerPATCH 471/496 net: stmmac: call correct function in stmmac_mac_config_rx_queues_routing()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 13138de01400762f706c5e956e70660770d61962 ]
stmmac_mac_config_rx_queues_routing() incorrectly calls rx_queue_prio() instead of rx_queue_routing().
This looks like a copy paste issue, since stmmac_mac_config_rx_queues_prio() already calls rx_queue_prio(), and both stmmac_mac_config_rx_queues_routing() and stmmac_mac_config_rx_queues_prio() are very similar in structure.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 -1
@@ -2373,7 +2373,7 @@ static void stmmac_mac_config_rx_queues_continue ; packet = priv->plat->rx_queues_cfg[queue].pkt_route; - priv->hw->mac->rx_queue_prio (priv->hw, packet, queue); + priv->hw->mac->rx_queue_routing (priv->hw, packet, queue); } }
Greg Kroah-Hartman
maintainerPATCH 472/496 rcu: Call touch_nmi_watchdog() while printing stall warnings
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
[ Upstream commit 3caa973b7a260e7a2a69edc94c300ab9c65148c3 ]
When RCU stall warning triggers, it can print out a lot of messages while holding spinlocks. If the console device is slow (e.g. an actual or IPMI serial console), it may end up triggering NMI hard lockup watchdog like the following.
--- kernel/rcu/tree_plugin.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
kernel/rcu/tree_plugin.h +13 -1
@@ -559,8 +559,14 @@ static void rcu_print_detail_task_stall_ } t =list_entry (rnp->gp_tasks->prev, struct task_struct, rcu_node_entry); -list_for_each_entry_continue (t, &rnp->blkd_tasks, rcu_node_entry) +list_for_each_entry_continue (t, &rnp->blkd_tasks, rcu_node_entry) { +/* +* We could be printing a lot while holding a spinlock. +* Avoid triggering hard lockup. +*/ +touch_nmi_watchdog ();sched_show_task (t); + }raw_spin_unlock_irqrestore_rcu_node (rnp, flags); }
@@ -1677,6 +1683,12 @@ static void print_cpu_stall_info(structchar *ticks_title;unsigned long ticks_value; +/* +* We could be printing a lot while holding a spinlock. Avoid +* triggering hard lockup. +*/ +touch_nmi_watchdog (); +if (rsp->gpnum == rdp->gpnum) { ticks_title ="ticks this GP" ; ticks_value = rdp->ticks_this_gp;
Greg Kroah-Hartman
maintainerPATCH 473/496 pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for SSI pins group
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takeshi Kihara <[email protected]>
[ Upstream commit b418c4609d5052d174668ad6d13efe023c45c595 ]
This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment for SSI pins group.
This is a correction to the incorrect implementation of MOD_SEL register pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware User's Manual Rev.0.51E or later.
--- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 40 +++++++++++++++++------------------ 1 file changed, 20 insertions(+), 20 deletions(-)
drivers/pinctrl/sh-pfc/pfc-r8a7796.c +20 -20
@@ -1,7 +1,7 @@/* * R8A7796 processor support - PFC hardware block. * -* Copyright (C) 2016 Renesas Electronics Corp. +* Copyright (C) 2016-2017 Renesas Electronics Corp. * * This file is based on the drivers/pinctrl/sh-pfc/pfc-r8a7795.c *
@@ -477,7 +477,7 @@ FM(IP16_31_28) IP16_31_28 FM(IP17_31_28)#define MOD_SEL1_26 FM(SEL_TIMER_TMU_0) FM(SEL_TIMER_TMU_1)#define MOD_SEL1_25_24 FM(SEL_SSP1_1_0) FM(SEL_SSP1_1_1) FM(SEL_SSP1_1_2) FM(SEL_SSP1_1_3)#define MOD_SEL1_23_22_21 FM(SEL_SSP1_0_0) FM(SEL_SSP1_0_1) FM(SEL_SSP1_0_2) FM(SEL_SSP1_0_3) FM(SEL_SSP1_0_4) F_(0, 0) F_(0, 0) F_(0, 0) -#define MOD_SEL1_20 FM(SEL_SSI_0) FM(SEL_SSI_1) +#define MOD_SEL1_20 FM(SEL_SSI1_0) FM(SEL_SSI1_1)#define MOD_SEL1_19 FM(SEL_SPEED_PULSE_0) FM(SEL_SPEED_PULSE_1)#define MOD_SEL1_18_17 FM(SEL_SIMCARD_0) FM(SEL_SIMCARD_1) FM(SEL_SIMCARD_2) FM(SEL_SIMCARD_3)#define MOD_SEL1_16 FM(SEL_SDHI2_0) FM(SEL_SDHI2_1)
@@ -1224,7 +1224,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_11_8 ,HSCK0 ),PINMUX_IPSR_MSEL (IP13_11_8 ,MSIOF1_SCK_D ,SEL_MSIOF1_3 ),PINMUX_IPSR_MSEL (IP13_11_8 ,AUDIO_CLKB_A ,SEL_ADG_B_0 ), -PINMUX_IPSR_MSEL (IP13_11_8 ,SSI_SDATA1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_11_8 ,SSI_SDATA1_B ,SEL_SSI1_1 ),PINMUX_IPSR_MSEL (IP13_11_8 ,TS_SCK0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_11_8 ,STP_ISCLK_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_11_8, RIF0_CLK_C, SEL_DRIF0_2),
@@ -1232,14 +1232,14 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_15_12 ,HRX0 ),PINMUX_IPSR_MSEL (IP13_15_12 ,MSIOF1_RXD_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_15_12 ,SSI_SDATA2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_15_12 ,SSI_SDATA2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP13_15_12 ,TS_SDEN0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_15_12 ,STP_ISEN_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_MSEL (IP13_15_12 ,RIF0_D0_C ,SEL_DRIF0_2 ),PINMUX_IPSR_GPSR (IP13_19_16 ,HTX0 ),PINMUX_IPSR_MSEL (IP13_19_16 ,MSIOF1_TXD_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_19_16 ,SSI_SDATA9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_19_16 ,SSI_SDATA9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP13_19_16 ,TS_SDAT0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_19_16 ,STP_ISD_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_19_16, RIF0_D1_C, SEL_DRIF0_2),
@@ -1247,7 +1247,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_23_20 ,HCTS0_N ),PINMUX_IPSR_MSEL (IP13_23_20 ,RX2_B ,SEL_SCIF2_1 ),PINMUX_IPSR_MSEL (IP13_23_20 ,MSIOF1_SYNC_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_23_20 ,SSI_SCK9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP13_23_20 ,SSI_SCK9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP13_23_20 ,TS_SPSYNC0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_23_20 ,STP_ISSYNC_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_23_20, RIF0_SYNC_C, SEL_DRIF0_2),
@@ -1256,7 +1256,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_27_24 ,HRTS0_N ),PINMUX_IPSR_MSEL (IP13_27_24 ,TX2_B ,SEL_SCIF2_1 ),PINMUX_IPSR_MSEL (IP13_27_24 ,MSIOF1_SS1_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_27_24 ,SSI_WS9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP13_27_24 ,SSI_WS9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP13_27_24 ,STP_IVCXO27_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_MSEL (IP13_27_24 ,BPFCLK_A ,SEL_FM_0 ), PINMUX_IPSR_GPSR(IP13_27_24, AUDIO_CLKOUT2_A),
@@ -1271,7 +1271,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_3_0 ,RX5_A ,SEL_SCIF5_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,NFWP_N_A ,SEL_NDF_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,AUDIO_CLKA_C ,SEL_ADG_A_2 ), -PINMUX_IPSR_MSEL (IP14_3_0 ,SSI_SCK2_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP14_3_0 ,SSI_SCK2_A ,SEL_SSI2_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,STP_IVCXO27_0_C ,SEL_SSP1_0_2 ),PINMUX_IPSR_GPSR (IP14_3_0 ,AUDIO_CLKOUT3_A ), PINMUX_IPSR_MSEL(IP14_3_0, TCLK1_B, SEL_TIMER_TMU_1),
@@ -1280,7 +1280,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_7_4 ,TX5_A ,SEL_SCIF5_0 ),PINMUX_IPSR_MSEL (IP14_7_4 ,MSIOF1_SS2_D ,SEL_MSIOF1_3 ),PINMUX_IPSR_MSEL (IP14_7_4 ,AUDIO_CLKC_A ,SEL_ADG_C_0 ), -PINMUX_IPSR_MSEL (IP14_7_4 ,SSI_WS2_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP14_7_4 ,SSI_WS2_A ,SEL_SSI2_0 ),PINMUX_IPSR_MSEL (IP14_7_4 ,STP_OPWM_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_GPSR (IP14_7_4 ,AUDIO_CLKOUT_D ), PINMUX_IPSR_MSEL(IP14_7_4, SPEEDIN_B, SEL_SPEED_PULSE_1),
@@ -1308,10 +1308,10 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_31_28 ,MSIOF1_SS2_F ,SEL_MSIOF1_5 ),/* IPSR15 */ -PINMUX_IPSR_MSEL (IP15_3_0 ,SSI_SDATA1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP15_3_0 ,SSI_SDATA1_A ,SEL_SSI1_0 ), -PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SDATA2_A ,SEL_SSI_0 ), -PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SCK1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SDATA2_A ,SEL_SSI2_0 ), +PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SCK1_B ,SEL_SSI1_1 ),PINMUX_IPSR_GPSR (IP15_11_8 ,SSI_SCK349 ), PINMUX_IPSR_MSEL(IP15_11_8, MSIOF1_SS1_A, SEL_MSIOF1_0),
@@ -1397,11 +1397,11 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP16_27_24 ,RIF1_D1_A ,SEL_DRIF1_0 ),PINMUX_IPSR_MSEL (IP16_27_24 ,RIF3_D1_A ,SEL_DRIF3_0 ), -PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_SDATA9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_SDATA9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP16_31_28 ,HSCK2_B ,SEL_HSCIF2_1 ),PINMUX_IPSR_MSEL (IP16_31_28 ,MSIOF1_SS1_C ,SEL_MSIOF1_2 ),PINMUX_IPSR_MSEL (IP16_31_28 ,HSCK1_A ,SEL_HSCIF1_0 ), -PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_WS1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_WS1_B ,SEL_SSI1_1 ),PINMUX_IPSR_GPSR (IP16_31_28 ,SCK1 ),PINMUX_IPSR_MSEL (IP16_31_28 ,STP_IVCXO27_1_A ,SEL_SSP1_1_0 ), PINMUX_IPSR_MSEL(IP16_31_28, SCK5_A, SEL_SCIF5_0),
@@ -1433,7 +1433,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_19_16 ,USB1_PWEN ),PINMUX_IPSR_MSEL (IP17_19_16 ,SIM0_CLK_C ,SEL_SIMCARD_2 ), -PINMUX_IPSR_MSEL (IP17_19_16 ,SSI_SCK1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP17_19_16 ,SSI_SCK1_A ,SEL_SSI1_0 ),PINMUX_IPSR_MSEL (IP17_19_16 ,TS_SCK0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP17_19_16 ,STP_ISCLK_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP17_19_16, FMCLK_B, SEL_FM_1),
@@ -1443,7 +1443,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_23_20 ,USB1_OVC ),PINMUX_IPSR_MSEL (IP17_23_20 ,MSIOF1_SS2_C ,SEL_MSIOF1_2 ), -PINMUX_IPSR_MSEL (IP17_23_20 ,SSI_WS1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP17_23_20 ,SSI_WS1_A ,SEL_SSI1_0 ),PINMUX_IPSR_MSEL (IP17_23_20 ,TS_SDAT0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP17_23_20 ,STP_ISD_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP17_23_20, FMIN_B, SEL_FM_1),
@@ -1453,7 +1453,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_27_24 ,USB30_PWEN ),PINMUX_IPSR_GPSR (IP17_27_24 ,AUDIO_CLKOUT_B ), -PINMUX_IPSR_MSEL (IP17_27_24 ,SSI_SCK2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP17_27_24 ,SSI_SCK2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP17_27_24 ,TS_SDEN1_D ,SEL_TSIF1_3 ),PINMUX_IPSR_MSEL (IP17_27_24 ,STP_ISEN_1_D ,SEL_SSP1_1_3 ), PINMUX_IPSR_MSEL(IP17_27_24, STP_OPWM_0_E, SEL_SSP1_0_4),
@@ -1465,7 +1465,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_31_28 ,USB30_OVC ),PINMUX_IPSR_GPSR (IP17_31_28 ,AUDIO_CLKOUT1_B ), -PINMUX_IPSR_MSEL (IP17_31_28 ,SSI_WS2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP17_31_28 ,SSI_WS2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP17_31_28 ,TS_SPSYNC1_D ,SEL_TSIF1_3 ),PINMUX_IPSR_MSEL (IP17_31_28 ,STP_ISSYNC_1_D ,SEL_SSP1_1_3 ), PINMUX_IPSR_MSEL(IP17_31_28, STP_IVCXO27_0_E, SEL_SSP1_0_4),
@@ -1476,7 +1476,7 @@ static const u16 pinmux_data[] = {/* IPSR18 */ PINMUX_IPSR_GPSR (IP18_3_0 ,GP6_30 ),PINMUX_IPSR_GPSR (IP18_3_0 ,AUDIO_CLKOUT2_B ), -PINMUX_IPSR_MSEL (IP18_3_0 ,SSI_SCK9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP18_3_0 ,SSI_SCK9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP18_3_0 ,TS_SDEN0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP18_3_0 ,STP_ISEN_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP18_3_0, RIF2_D0_B, SEL_DRIF2_1),
@@ -1486,7 +1486,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP18_7_4 ,GP6_31 ),PINMUX_IPSR_GPSR (IP18_7_4 ,AUDIO_CLKOUT3_B ), -PINMUX_IPSR_MSEL (IP18_7_4 ,SSI_WS9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP18_7_4 ,SSI_WS9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP18_7_4 ,TS_SPSYNC0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP18_7_4 ,STP_ISSYNC_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP18_7_4, RIF2_D1_B, SEL_DRIF2_1),
Greg Kroah-Hartman
maintainerPATCH 474/496 dpaa_eth: fix pause capability advertisement logic
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jake Moroni <[email protected]>
[ Upstream commit 3021efb440d02bf5b952b6d151c7ffee9bdd49fe ]
The ADVERTISED_Asym_Pause bit was being improperly set when both rx and tx pause were enabled. When rx and tx are both enabled, only the ADVERTISED_Pause bit is supposed to be set.
--- drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c +1 -1
@@ -211,7 +211,7 @@ static int dpaa_set_pauseparam(struct neif (epause->rx_pause) newadv = ADVERTISED_Pause | ADVERTISED_Asym_Pause;if (epause->tx_pause) - newadv |= ADVERTISED_Asym_Pause; + newadv ^= ADVERTISED_Asym_Pause; oldadv = phydev->advertising & (ADVERTISED_Pause | ADVERTISED_Asym_Pause);
Greg Kroah-Hartman
maintainerPATCH 475/496 MIPS: Octeon: Fix logging messages with spurious periods after newlines
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Perches <[email protected]>
[ Upstream commit db6775ca6e0353d2618ca7d5e210fc36ad43bbd4 ]
Using a period after a newline causes bad output.
Patchwork: https://patchwork.linux-mips.org/patch/17886/
--- arch/mips/cavium-octeon/octeon-irq.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
arch/mips/cavium-octeon/octeon-irq.c +5 -5
@@ -2271,7 +2271,7 @@ static int __init octeon_irq_init_cib(st parent_irq =irq_of_parse_and_map (ciu_node,0 );if (!parent_irq) { -pr_err ("ERROR: Couldn't acquire parent_irq for %s\n." , +pr_err ("ERROR: Couldn't acquire parent_irq for %s\n" , ciu_node->name);return -EINVAL ; }
@@ -2283,7 +2283,7 @@ static int __init octeon_irq_init_cib(st addr =of_get_address (ciu_node,0 ,NULL ,NULL );if (!addr) { -pr_err ("ERROR: Couldn't acquire reg(0) %s\n." , ciu_node->name); +pr_err ("ERROR: Couldn't acquire reg(0) %s\n" , ciu_node->name);return -EINVAL ; } host_data->raw_reg = (u64)phys_to_virt(
@@ -2291,7 +2291,7 @@ static int __init octeon_irq_init_cib(st addr =of_get_address (ciu_node,1 ,NULL ,NULL );if (!addr) { -pr_err ("ERROR: Couldn't acquire reg(1) %s\n." , ciu_node->name); +pr_err ("ERROR: Couldn't acquire reg(1) %s\n" , ciu_node->name);return -EINVAL ; } host_data->en_reg = (u64)phys_to_virt(
@@ -2299,7 +2299,7 @@ static int __init octeon_irq_init_cib(st r =of_property_read_u32 (ciu_node,"cavium,max-bits" , &val);if (r) { -pr_err ("ERROR: Couldn't read cavium,max-bits from %s\n." , +pr_err ("ERROR: Couldn't read cavium,max-bits from %s\n" , ciu_node->name);return r; }
@@ -2309,7 +2309,7 @@ static int __init octeon_irq_init_cib(st &octeon_irq_domain_cib_ops, host_data);if (!cib_domain) { -pr_err ("ERROR: Couldn't irq_domain_add_linear()\n." ); +pr_err ("ERROR: Couldn't irq_domain_add_linear()\n" );return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 477/496 x86/apic: Set up through-local-APIC mode on the boot CPU if noapic specified
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baoquan He <[email protected]>
[ Upstream commit bee3204ec3c49f6f53add9c3962c9012a5c036fa ]
Currently the kdump kernel becomes very slow if 'noapic' is specified. Normal kernel doesn't have this bug.
Kernel parameter 'noapic' is used to disable IO-APIC in system for testing or special purpose. Here the root cause is that in kdump kernel LAPIC is disabled since commit:
522e664644 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
In this case we need set up through-local-APIC on boot CPU in setup_local_APIC().
In normal kernel the legacy irq mode is enabled by the BIOS. If it is virtual wire mode, the local-APIC has been enabled and set as through-local-APIC.
Though we fixed the regression introduced by commit 522e664644, to further improve robustness set up the through-local-APIC mode explicitly, do not rely on the default boot IRQ mode.
--- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/apic/apic.c +1 -1
@@ -1481,7 +1481,7 @@ void setup_local_APIC(void)* TODO: set up through-local-APIC from through-I/O-APIC? --macro */ value =apic_read (APIC_LVT0 ) &APIC_LVT_MASKED ; -if (!cpu && (pic_mode || !value)) { +if (!cpu && (pic_mode || !value || skip_ioapic_setup)) { value =APIC_DM_EXTINT ;apic_printk (APIC_VERBOSE ,"enabled ExtINT on CPU#%d\n" , cpu); }else {
Greg Kroah-Hartman
maintainerPATCH 478/496 perf test: Fix test case inet_pton to accept inlines.
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Richter <[email protected]>
[ Upstream commit 0f19a038afdc592176c9a302f0d08be6a68ad74a ]
Using Fedora 27 and latest Linux kernel the test case trace+probe_libc_inet_pton.sh fails again on s390. This time is the inlining of functions which does not match. After an update of the glibc (from 2.26-16 to 2.26-24) the output is different
The expected output is:
__inet_pton (/usr/lib64/libc-2.26.so)
gaih_inet (inlined)
....The actual output is:
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms
0.000 probe_libc:inet_pton:(3ffb2140448))
__inet_pton (inlined)
gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
...Fix this by being less strict on 'inlined' verses library name and accept both
--- tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
tools/perf/tests/shell/trace+probe_libc_inet_pton.sh +3 -3
@@ -21,12 +21,12 @@ trace_libc_inet_pton_backtrace() { expected[3]=".*packets transmitted.*" expected[4]="rtt min.*" expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)" - expected[6]=".*inet_pton[[:space:]]\($libc\)$" + expected[6]=".*inet_pton[[:space:]]\($libc|inlined\)$" case "$(uname -m)" in s390x) eventattr='call-graph=dwarf' - expected[7]="gaih_inet[[:space:]]\(inlined\)$" - expected[8]="__GI_getaddrinfo[[:space:]]\(inlined\)$" + expected[7]="gaih_inet.*[[:space:]]\($libc|inlined\)$" + expected[8]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$" expected[9]="main[[:space:]]\(.*/bin/ping.*\)$" expected[10]="__libc_start_main[[:space:]]\($libc\)$" expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$"
Greg Kroah-Hartman
maintainerPATCH 480/496 perf tests: Use arch__compare_symbol_names to compare symbols
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit ab6e9a99345131cd8e54268d1d0dc04a33f7ed11 ]
The symbol search called by machine__find_kernel_symbol_by_name is using internally arch__compare_symbol_names function to compare 2 symbol names, because different archs have different ways of comparing symbols. Mostly for skipping '.' prefixes and similar.
In test 1 when we try to find matching symbols in kallsyms and vmlinux, by address and by symbol name. When either is found we compare the pair symbol names by simple strcmp, which is not good enough for reasons explained in previous paragraph.
On powerpc this can cause lockup, because even thought we found the pair, the compared names are different and don't match simple strcmp. Following code path is executed, that leads to lockup:
- we find the pair in kallsyms by sym->startnext_pair:
- we compare the names and it fails
- we find the pair by sym->name
- the pair addresses match so we call goto next_pair because we assume the names match in this case
--- tools/perf/tests/vmlinux-kallsyms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/tests/vmlinux-kallsyms.c +1 -1
@@ -125,7 +125,7 @@ int test__vmlinux_matches_kallsyms(strucif (pair &&UM (pair->start) == mem_start) { next_pair: -if (strcmp (sym->name, pair->name) ==0 ) { +if (arch__compare_symbol_names (sym->name, pair->name) ==0 ) {/* * kallsyms don't have the symbol end, so we * set that by using the next symbol start - 1,
Greg Kroah-Hartman
maintainerPATCH 481/496 perf report: Fix memory corruption in --branch-history mode --branch-history
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit e3ebaa465136ecfedf9c6f4671df02bf625f8125 ]
Jin Yao reported memory corrupton in perf report with branch info used for stack trace:
Quoted 15 lines
Following command lines will cause perf crash.
perf record -j call -g -a <application>
perf report --branch-history*** Error in `perf': double free or corruption (!prev):
0x00000000104aa040*** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc] perf[0x51b914]
perf(hist_entry_iter__add+0x1e5)[0x51f305]
perf[0x43cf01]
perf[0x4fa3bf]
perf[0x4fa923]
Quoted 8 lines
perf[0x4fd396]
perf[0x4f9614] perf(perf_session__process_events+0x89e)[0x4fc38e] perf(cmd_report+0x15d2)[0x43f202]
perf[0x4a059f]
perf(main+0x631)[0x427b71] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830] perf(_start+0x29)[0x427d89]
For the cumulative output, we allocate the he_cache array based on the --max-stack option value and populate it with data from 'callchain_cursor'.
The --max-stack option value does not ensure now the limit for number of callchain_cursor nodes, so the cumulative iter code will allocate smaller array than it's actually needed and cause above corruption.
I think the --max-stack limit does not apply here anyway, because we add callchain data as normal hist entries, while the --max-stack control the limit of single entry callchain depth.
Using the callchain_cursor.nr as he_cache array count to fix this. Also removing struct hist_entry_iter::max_stack, because there's no longer any use for it.
We need more fixes to ensure that the branch stack code follows properly the logic of --max-stack, which is not the case at the moment.
--- tools/perf/util/hist.c | 4 +--- tools/perf/util/hist.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-)
tools/perf/util/hist.c +1 -3
@@ -878,7 +878,7 @@ iter_prepare_cumulative_entry(struct his* cumulated only one time to prevent entries more than 100% * overhead. */ - he_cache =malloc (sizeof (*he_cache) * (iter->max_stack +1 )); + he_cache =malloc (sizeof (*he_cache) * (callchain_cursor.nr +1 ));if (he_cache ==NULL )return -ENOMEM ;
@@ -1043,8 +1043,6 @@ int hist_entry_iter__add(struct hist_entif (err)return err; - iter->max_stack = max_stack_depth; - err = iter->ops->prepare_entry (iter, al);if (err) goto out;
tools/perf/util/hist.h +0 -1
@@ -107,7 +107,6 @@ struct hist_entry_iter {int curr;bool hide_unresolved; -int max_stack;struct perf_evsel *evsel;struct perf_sample *sample;
Greg Kroah-Hartman
maintainerPATCH 482/496 perf tests: Fix dwarf unwind for stripped binaries
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit fdf7c49c200d1b9909e2204cec5bd68b48605c71 ]
When we strip the perf binary, dwarf unwind test stop to work. The reason is that strip will remove static function symbols, which we need to check for unwind.
This change will keep this test working in cases where the global symbols are put into dynamic symbol table, which is the case on x86. It still won't work on powerpc.
Making those 5 local functions global, and adding 'test_dwarf_unwind__' to their names.
Committer testing:
Before:
# perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : FAILED! # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 6590 unwind: thread map already set, dso=/home/acme/bin/perf <SNIP> unwind: access_mem addr 0x7ffce6c48098 val 48563f, offset 1144 unwind: test__dwarf_unwind:ip = 0x4a54e5 (0xa54e5) got: test__dwarf_unwind 0xa54e5, expecting test__dwarf_unwind unwind: '':ip = 0x4a50bb (0xa50bb) failed: got unresolved address 0xa50bb unwind failed test child finished with -1 ---- end ---- DWARF unwind: FAILED! #
After:
# perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : Ok # # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 7219 unwind: thread map already set, dso=/home/acme/bin/perf <SNIP> unwind: access_mem addr 0x7fff007da2c8 val 48575f, offset 1144 unwind: test__arch_unwind_sample:ip = 0x589044 (0x189044) got: test__arch_unwind_sample 0x189044, expecting test__arch_unwind_sample unwind: test_dwarf_unwind__thread:ip = 0x4a52f7 (0xa52f7) got: test_dwarf_unwind__thread 0xa52f7, expecting test_dwarf_unwind__thread unwind: test_dwarf_unwind__compare:ip = 0x4a5468 (0xa5468) got: test_dwarf_unwind__compare 0xa5468, expecting test_dwarf_unwind__compare unwind: bsearch:ip = 0x7f6608ae94d8 (0x394d8) got: bsearch 0x394d8, expecting bsearch unwind: test_dwarf_unwind__krava_3:ip = 0x4a54d1 (0xa54d1) got: test_dwarf_unwind__krava_3 0xa54d1, expecting test_dwarf_unwind__krava_3 unwind: test_dwarf_unwind__krava_2:ip = 0x4a550b (0xa550b) got: test_dwarf_unwind__krava_2 0xa550b, expecting test_dwarf_unwind__krava_2 unwind: test_dwarf_unwind__krava_1:ip = 0x4a554b (0xa554b) got: test_dwarf_unwind__krava_1 0xa554b, expecting test_dwarf_unwind__krava_1 unwind: test__dwarf_unwind:ip = 0x4a5605 (0xa5605) got: test__dwarf_unwind 0xa5605, expecting test__dwarf_unwind test child finished with 0 ---- end ---- DWARF unwind: Ok #
--- tools/perf/tests/dwarf-unwind.c | 46 ++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 16 deletions(-)
tools/perf/tests/dwarf-unwind.c +30 -16
@@ -37,6 +37,19 @@ static int init_live_machine(struct mach mmap_handler, machine, true, 500); } +/* +* We need to keep these functions global, despite the +* fact that they are used only locally in this object, +* in order to keep them around even if the binary is +* stripped. If they are gone, the unwind check for +* symbol fails. +*/ +int test_dwarf_unwind__thread (struct thread *thread); +int test_dwarf_unwind__compare (void *p1,void *p2); +int test_dwarf_unwind__krava_3 (struct thread *thread); +int test_dwarf_unwind__krava_2 (struct thread *thread); +int test_dwarf_unwind__krava_1 (struct thread *thread); +#define MAX_STACK 8static int unwind_entry (struct unwind_entry *entry,void *arg)
@@ -45,12 +58,12 @@ static int unwind_entry(struct unwind_enchar *symbol = entry->sym ? entry->sym->name :NULL ;static const char *funcs[MAX_STACK ] = {"test__arch_unwind_sample" , -"unwind_thread" , -"compare" , +"test_dwarf_unwind__thread" , +"test_dwarf_unwind__compare" ,"bsearch" , -"krava_3" , -"krava_2" , -"krava_1" , +"test_dwarf_unwind__krava_3" , +"test_dwarf_unwind__krava_2" , +"test_dwarf_unwind__krava_1" ,"test__dwarf_unwind" };/*
@@ -77,7 +90,7 @@ static int unwind_entry(struct unwind_enreturn strcmp ((const char *) symbol, funcs[idx]); } -static noinline int unwind_thread(struct thread *thread) +noinline int test_dwarf_unwind__thread(struct thread *thread) {struct perf_sample sample;unsigned long cnt =0 ;
@@ -108,7 +121,7 @@ static noinline int unwind_thread(structstatic int global_unwind_retval = -INT_MAX ; -static noinline int compare(void *p1, void *p2) +noinline int test_dwarf_unwind__compare(void *p1, void *p2) {/* Any possible value should be 'thread' */ struct thread *thread = *(struct thread **)p1;
@@ -117,17 +130,17 @@ static noinline int compare(void *p1, vo/* Call unwinder twice for both callchain orders. */ callchain_param.order =ORDER_CALLER ; - global_unwind_retval =unwind_thread (thread); + global_unwind_retval =test_dwarf_unwind__thread (thread);if (!global_unwind_retval) { callchain_param.order =ORDER_CALLEE ; - global_unwind_retval =unwind_thread (thread); + global_unwind_retval =test_dwarf_unwind__thread (thread); } }return p1 - p2; } -static noinline int krava_3(struct thread *thread) +noinline int test_dwarf_unwind__krava_3(struct thread *thread) {struct thread *array[2 ] = {thread, thread};void *fp = &bsearch;
@@ -141,18 +154,19 @@ static noinline int krava_3(struct threa size_t, int (*)(void *, void *)); _bsearch = fp; -_bsearch (array, &thread,2 ,sizeof (struct thread **), compare); +_bsearch (array, &thread,2 ,sizeof (struct thread **), + test_dwarf_unwind__compare);return global_unwind_retval; } -static noinline int krava_2(struct thread *thread) +noinline int test_dwarf_unwind__krava_2(struct thread *thread) { -return krava_3 (thread); +return test_dwarf_unwind__krava_3 (thread); } -static noinline int krava_1(struct thread *thread) +noinline int test_dwarf_unwind__krava_1(struct thread *thread) { -return krava_2 (thread); +return test_dwarf_unwind__krava_2 (thread); }int test__dwarf_unwind (struct test *test__maybe_unused ,int subtest__maybe_unused )
@@ -189,7 +203,7 @@ int test__dwarf_unwind(struct test *test goto out; } - err =krava_1 (thread); + err =test_dwarf_unwind__krava_1 (thread);thread__put (thread); out:
Greg Kroah-Hartman
maintainerPATCH 483/496 selftests/net: fixes psock_fanout eBPF test case
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prashant Bhole <[email protected]>
[ Upstream commit ddd0010392d9cbcb95b53d11b7cafc67b373ab56 ]
eBPF test fails due to verifier failure because log_buf is too small. Fixed by increasing log_buf size
--- tools/testing/selftests/net/psock_fanout.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/selftests/net/psock_fanout.c +2 -1
@@ -128,6 +128,8 @@ static void sock_fanout_getopts(int fd,static void sock_fanout_set_ebpf (int fd) { +static char log_buf[65536 ]; + const int len_off = __builtin_offsetof(struct __sk_buff, len);struct bpf_insn prog[] = { {BPF_ALU64 |BPF_MOV |BPF_X ,6 ,1 ,0 ,0 },
@@ -140,7 +142,6 @@ static void sock_fanout_set_ebpf(int fd) { BPF_ALU | BPF_MOV | BPF_K, 0, 0, 0, 0 }, { BPF_JMP | BPF_EXIT, 0, 0, 0, 0 } }; -char log_buf[512 ];union bpf_attr attr;int pfd;
Greg Kroah-Hartman
maintainerPATCH 484/496 netlabel: If PF_INET6, check sk_buff ip header version
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Haines <[email protected]>
[ Upstream commit 213d7f94775322ba44e0bbb55ec6946e9de88cea ]
When resolving a fallback label, check the sk_buff version as it is possible (e.g. SCTP) to have family = PF_INET6 while receiving ip_hdr(skb)->version = 4.
--- net/netlabel/netlabel_unlabeled.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
net/netlabel/netlabel_unlabeled.c +10 -0
@@ -1472,6 +1472,16 @@ int netlbl_unlabel_getattr(const struct iface =rcu_dereference (netlbl_unlhsh_def);if (iface ==NULL || !iface->valid) goto unlabel_getattr_nolabel; + +#if IS_ENABLED (CONFIG_IPV6 ) +/* When resolving a fallback label, check the sk_buff version as +* it is possible (e.g. SCTP) to have family = PF_INET6 while +* receiving ip_hdr(skb)->version = 4. +*/ +if (family ==PF_INET6 &&ip_hdr (skb)->version ==4 ) + family =PF_INET ; +#endif /* IPv6 */ +switch (family) {case PF_INET : {struct iphdr *hdr4;
Greg Kroah-Hartman
maintainerPATCH 485/496 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit 796ceb9269626afaed3b4955c40d2c3d7a8c5d01 ]
According to the latest revisions of the R-Car Gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the Gen3 LVDS startup sequence accordingly.
--- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c +5 -2
@@ -95,7 +95,7 @@ static void rcar_du_lvdsenc_start_gen3(su32 lvdcr0;u32 pllcr; -/* PLL clock configuration */ +/* Set the PLL clock configuration and LVDS mode. */ if (freq <42000 ) pllcr =LVDPLLCR_PLLDIVCNT_42M ;else if (freq <85000 )
@@ -107,6 +107,9 @@ static void rcar_du_lvdsenc_start_gen3(srcar_lvds_write (lvds,LVDPLLCR , pllcr); + lvdcr0 = lvds->mode <<LVDCR0_LVMD_SHIFT ; +rcar_lvds_write (lvds,LVDCR0 , lvdcr0); +/* Turn all the channels on. */ rcar_lvds_write(lvds, LVDCR1, LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
@@ -117,7 +120,7 @@ static void rcar_du_lvdsenc_start_gen3(s* Turn the PLL on, set it to LVDS normal mode, wait for the startup * delay and turn the output on. */ - lvdcr0 = (lvds->mode <<LVDCR0_LVMD_SHIFT ) |LVDCR0_PLLON ; + lvdcr0 |=LVDCR0_PLLON ;rcar_lvds_write (lvds,LVDCR0 , lvdcr0); lvdcr0 |=LVDCR0_PWD ;
Greg Kroah-Hartman
maintainerPATCH 486/496 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit 8525d04ba8a6a9ecfa4bd619c988ca873a5fc2a4 ]
According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS and the bias circuit must be enabled after the LVDS I/O pins are enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.
While at it, also fix the comment preceding the first LVDCR0 write that still talks about hardcoding the LVDS mode 0.
--- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c +6 -5
@@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(srcar_lvds_write (lvds,LVDPLLCR , pllcr); -/* -* Select the input, hardcode mode 0, enable LVDS operation and turn -* bias circuitry on. -*/ - lvdcr0 = (lvds->mode <<LVDCR0_LVMD_SHIFT ) |LVDCR0_BEN |LVDCR0_LVEN ; +/* Select the input and set the LVDS mode. */ + lvdcr0 = lvds->mode <<LVDCR0_LVMD_SHIFT ;if (rcrtc->index ==2 ) lvdcr0 |=LVDCR0_DUSEL ;rcar_lvds_write (lvds,LVDCR0 , lvdcr0);
@@ -74,6 +71,10 @@ static void rcar_du_lvdsenc_start_gen2(sLVDCR1_CHSTBY_GEN2 (1 ) |LVDCR1_CHSTBY_GEN2 (0 ) | LVDCR1_CLKSTBY_GEN2); +/* Enable LVDS operation and turn bias circuitry on. */ + lvdcr0 |=LVDCR0_BEN |LVDCR0_LVEN ; +rcar_lvds_write (lvds,LVDCR0 , lvdcr0); +/* * Turn the PLL on, wait for the startup delay, and turn the output * on.
Greg Kroah-Hartman
maintainerPATCH 487/496 ARM: dts: at91: tse850: use the correct compatible for the eeprom
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <[email protected]>
[ Upstream commit 7981190fb5dd710dea08c2613cee3d05e795ca5e ]
The used part does contain an eeprom compatible with an Atmel 24c02 chip and it is from NXP, but it is not called 24c02. It's actually a se97b chip. Adjust the compatible accordingly.
--- arch/arm/boot/dts/at91-tse850-3.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/at91-tse850-3.dts +1 -1
@@ -245,7 +245,7 @@ }; eeprom@50 { - compatible = "nxp,24c02", "atmel,24c02"; + compatible = "nxp,se97b", "atmel,24c02"; reg = <0x50>; pagesize = <16>; };
Greg Kroah-Hartman
maintainerPATCH 488/496 regmap: Correct comparison in regmap_cached
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
[ Upstream commit 71df179363a5a733a8932e9afb869760d7559383 ]
The cache pointer points to the actual memory used by the cache, as the comparison here is looking for the type of the cache it should check against cache_type.
--- drivers/base/regmap/regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/regmap/regmap.c +1 -1
@@ -98,7 +98,7 @@ bool regmap_cached(struct regmap *map, uint ret;unsigned int val; -if (map->cache ==REGCACHE_NONE ) +if (map->cache_type ==REGCACHE_NONE )return false;if (!map->cache_ops)
Greg Kroah-Hartman
maintainerPATCH 489/496 i40e: Add delay after EMP reset for firmware to recover
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filip Sadowski <[email protected]>
[ Upstream commit 1fa51a650e1deb50410677f1bd6c0ce17aa48a49 ]
This patch adds necessary delay for 4.33 firmware to recover after EMP reset. Without this patch driver occasionally reinitializes structures too quickly to communicate with firmware after EMP reset causing AdminQ to timeout.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/net/ethernet/intel/i40e/i40e_main.c +11 -0
@@ -7196,6 +7196,17 @@ static void i40e_rebuild(struct i40e_pf }i40e_get_oem_version (&pf->hw); +if (test_bit (__I40E_EMP_RESET_INTR_RECEIVED, pf->state) && + ((hw->aq.fw_maj_ver ==4 && hw->aq.fw_min_ver <=33 ) || + hw->aq.fw_maj_ver <4 ) && hw->mac.type ==I40E_MAC_XL710 ) { +/* The following delay is necessary for 4.33 firmware and older +* to recover after EMP reset. 200 ms should suffice but we +* put here 300 ms to be sure that FW is ready to operate +* after reset. +*/ +mdelay (300 ); + } +/* re-verify the eeprom if we just had an EMP reset */ if (test_and_clear_bit (__I40E_EMP_RESET_INTR_RECEIVED, pf->state))i40e_verify_eeprom (pf);
Greg Kroah-Hartman
maintainerPATCH 490/496 ARM: dts: imx7d: cl-som-imx7: fix pinctrl_enet
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aapo Vienamo <[email protected]>
[ Upstream commit 2bada7ac1fdcbf79a9689bd2ff65fa515ca7a31f ]
The missing last digit of the CONFIG values is added. Looks like a typo of some sort when comparing to the downstream dt. This fixes intermittent behavior behaviour of the ethernet controllers.
--- arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 52 ++++++++++++++++---------------- 1 file changed, 26 insertions(+), 26 deletions(-)
arch/arm/boot/dts/imx7d-cl-som-imx7.dts +26 -26
@@ -213,37 +213,37 @@ &iomuxc { pinctrl_enet1: enet1grp { fsl,pins = < - MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3 - MX7D_PAD_SD2_WP__ENET1_MDC 0x3 - MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x1 - MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1 - MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1 - MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x1 - MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x1 - MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1 - MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x1 - MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1 - MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1 - MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x1 - MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x1 - MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1 + MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x30 + MX7D_PAD_SD2_WP__ENET1_MDC 0x30 + MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x11 + MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x11 + MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x11 + MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x11 + MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x11 + MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x11 + MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x11 + MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x11 + MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x11 + MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x11 + MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x11 + MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x11 >; }; pinctrl_enet2: enet2grp { fsl,pins = < - MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC 0x1 - MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x1 - MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x1 - MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2 0x1 - MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3 0x1 - MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x1 - MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC 0x1 - MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x1 - MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x1 - MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2 0x1 - MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3 0x1 - MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x1 + MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC 0x11 + MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x11 + MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x11 + MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2 0x11 + MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3 0x11 + MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x11 + MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC 0x11 + MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x11 + MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x11 + MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2 0x11 + MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3 0x11 + MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x11 >; };
Greg Kroah-Hartman
maintainerPATCH 491/496 ARM: dts: porter: Fix HDMI output routing
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
[ Upstream commit d4b78db6ac3e084e2bdc57d5518bd247c727f396 ]
The HDMI encoder is connected to the RGB output of the DU, which is port@0, not port@1. Fix the incorrect DT description.
--- arch/arm/boot/dts/r8a7791-porter.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/r8a7791-porter.dts +1 -1
@@ -427,7 +427,7 @@ "dclkin.0", "dclkin.1"; ports { - port@1 { + port@0 { endpoint { remote-endpoint = <&adv7511_in>; };
Greg Kroah-Hartman
maintainerPATCH 492/496 regulator: of: Add a missing of_node_put() in an error handling path of of_regulator_match()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 30966861a7a2051457be8c49466887d78cc47e97 ]
If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning.
--- drivers/regulator/of_regulator.c | 1 + 1 file changed, 1 insertion(+)
drivers/regulator/of_regulator.c +1 -0
@@ -305,6 +305,7 @@ int of_regulator_match(struct device *dedev_err (dev,"failed to parse DT for regulator %s\n" , child->name); +of_node_put (child);return -EINVAL ; } match->of_node =of_node_get (child);
Greg Kroah-Hartman
maintainerPATCH 493/496 pinctrl: msm: Use dynamic GPIO numbering
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]
The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/qcom/pinctrl-msm.c +1 -1
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;
Greg Kroah-Hartman
maintainerPATCH 495/496 kdb: make "mdr" command repeat
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Randy Dunlap <[email protected]>
[ Upstream commit 1e0ce03bf142454f38a5fc050bf4fd698d2d36d8 ]
The "mdr" command should repeat (continue) when only Enter/Return is pressed, so make it do so.
--- kernel/debug/kdb/kdb_main.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
kernel/debug/kdb/kdb_main.c +21 -6
@@ -1566,6 +1566,7 @@ static int kdb_md(int argc, const char *int symbolic =0 ;int valid =0 ;int phys =0 ; +int raw =0 ;kdbgetintenv ("MDCOUNT" , &mdcount);kdbgetintenv ("RADIX" , &radix);
@@ -1575,9 +1576,10 @@ static int kdb_md(int argc, const char * repeat = mdcount *16 / bytesperword;if (strcmp (argv[0 ],"mdr" ) ==0 ) { -if (argc !=2 ) +if (argc ==2 || (argc ==0 && last_addr !=0 )) + valid = raw =1 ; +else return KDB_ARGCOUNT ; - valid =1 ; }else if (isdigit (argv[0 ][2 ])) { bytesperword = (int )(argv[0 ][2 ] -'0' );if (bytesperword ==0 ) {
@@ -1613,7 +1615,10 @@ static int kdb_md(int argc, const char * radix = last_radix; bytesperword = last_bytesperword; repeat = last_repeat; - mdcount = ((repeat * bytesperword) +15 ) /16 ; +if (raw) + mdcount = repeat; +else + mdcount = ((repeat * bytesperword) +15 ) /16 ; }if (argc) {
@@ -1630,7 +1635,10 @@ static int kdb_md(int argc, const char * diag =kdbgetularg (argv[nextarg], &val);if (!diag) { mdcount = (int ) val; - repeat = mdcount *16 / bytesperword; +if (raw) + repeat = mdcount; +else + repeat = mdcount *16 / bytesperword; } }if (argc >= nextarg+1 ) {
@@ -1640,8 +1648,15 @@ static int kdb_md(int argc, const char * } } -if (strcmp (argv[0 ],"mdr" ) ==0 ) -return kdb_mdr (addr, mdcount); +if (strcmp (argv[0 ],"mdr" ) ==0 ) { +int ret; + last_addr = addr; + ret =kdb_mdr (addr, mdcount); + last_addr += mdcount; + last_repeat = mdcount; + last_bytesperword = bytesperword;// to make REPEAT happy +return ret; + }switch (radix) {case 10 :
Greg Kroah-Hartman
maintainerPATCH 496/496 drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Rawat <[email protected]>
commit 91ba9f28a3de97761c2b5fd5df5d88421268e507 upstream.
SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO (and not call a new vmw_dmabuf_init) when a new fb size is same as current fb. This was changed in a recent commit which is causing page_flip to fail on VM with low display memory and multi-mon failure when cycle monitors from secondary display.
--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +2 -0
@@ -530,6 +530,8 @@ vmw_sou_primary_plane_prepare_fb(structreturn ret; } + vps->dmabuf_size = size; +/* * TTM already thinks the buffer is pinned, but make sure the * pin_count is upped.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.45 release. There are 496 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:00:57 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Merged, compiled, and installed onto my Raspberry Pi 3.
No initial issues noticed in general usage or dmesg.
Thanks!
Nathan
Greg Kroah-Hartman
maintainerQuoted 15 lines · Nathan Chancellor
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.45 release. There are 496 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:00:57 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 4 lines
thanks,
greg k-h
Merged, compiled, and installed onto my Raspberry Pi 3.
No initial issues noticed in general usage or dmesg.
Thanks for testing 2 of these and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.45 release. There are 496 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:00:57 UTC 2018. Anything received after that time might be too late.
Build results:
total: 146 pass: 146 fail: 0 Qemu test results: total: 143 pass: 143 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.45 release. There are 496 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:00:57 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
NOTE:
The failed LTP test case "cve-2017-5669" is a waiver here.
Summary
------------------------------------------------------------------------
kernel: 4.14.45-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 9fcb9d72e8a3a813caae6e2fac43a73603d75abd
git describe: v4.14.44-497-g9fcb9d72e8a3
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.44-497-g9fcb9d72e8a3
No regressions (compared to build v4.14.44-499-g88bdb64f9c00)
Ran 11325 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.45 release. There are 496 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:00:57 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah