commit 851d57212cd2e7e2dae52436d5e1337f6ec63964 Author: Alexandre Frade Date: Thu Dec 19 22:18:52 2019 -0300 4.19.90-rt35-xanmod Signed-off-by: Alexandre Frade commit 0a80d422122262d0738a81e586b35bafc2eb3b63 Merge: ea496ac112f9 5e45a0ea52bc Author: Alexandre Frade Date: Thu Dec 19 21:24:25 2019 -0300 Merge tag 'v4.19.90-rt35' into 4.19-rt Linux 4.19.90-rt35 commit 5e45a0ea52bc99c515828b0ef501cb320a17f383 Author: Steven Rostedt (VMware) Date: Wed Dec 18 15:22:05 2019 -0500 Linux 4.19.90-rt35 commit e467d29fe4c036d2b345447c9521aa70d11fa795 Merge: d53ff0cbecc9 7d120bf21c05 Author: Steven Rostedt (VMware) Date: Wed Dec 18 15:18:55 2019 -0500 Merge tag 'v4.19.90' into v4.19-rt This is the 4.19.90 stable release Conflicts: kernel/workqueue.c commit d53ff0cbecc9430b90fcd056e31ea3837f34ce7b Author: Steven Rostedt (VMware) Date: Wed Dec 18 11:35:05 2019 -0500 Linux 4.19.88-rt34 commit 263a62c60ceaa5a6e9081c4426de500b0c8b4e10 Merge: e71c1f62be9c fb683b5e3f53 Author: Steven Rostedt (VMware) Date: Wed Dec 18 11:29:25 2019 -0500 Merge tag 'v4.19.88' into v4.19-rt This is the 4.19.88 stable release Conflicts: arch/arm64/kernel/entry.S Reverted: 64694b276d74 ("arm64: preempt: Fix big-endian when checking preempt count in assembly") That commit should never have been backported to 4.19, as it depends on commit 396244692232 ("arm64: preempt: Provide our own implementation of asm/preempt.h") commit ea496ac112f90989202d31fb6e81b79bc24b8c12 Author: Tony Hutter Date: Wed Dec 18 09:59:04 2019 -0300 fs: Introduce the ZFS filesystem v0.8.2 for Linux kernel Signed-off-by: Tony Hutter Signed-off-by: Alexandre Frade commit 7d120bf21c05cbe30a679f0feeca884eeaceb069 Author: Greg Kroah-Hartman Date: Tue Dec 17 20:36:04 2019 +0100 Linux 4.19.90 commit b65a9b44f703f2767914dc07a5273a7af08f4bc9 Author: Erhard Furtner Date: Tue Nov 26 02:48:04 2019 +0100 of: unittest: fix memory leak in attach_node_and_children [ Upstream commit 2aacace6dbbb6b6ce4e177e6c7ea901f389c0472 ] In attach_node_and_children memory is allocated for full_name via kasprintf. If the condition of the 1st if is not met the function returns early without freeing the memory. Add a kfree() to fix that. This has been detected with kmemleak: Link: https://bugzilla.kernel.org/show_bug.cgi?id=205327 It looks like the leak was introduced by this commit: Fixes: 5babefb7f7ab ("of: unittest: allow base devicetree to have symbol metadata") Signed-off-by: Erhard Furtner Reviewed-by: Michael Ellerman Reviewed-by: Tyrel Datwyler Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit e62b2baf7ca97bd0d95e057731c5e8965fd880aa Author: Kars de Jong Date: Tue Nov 12 18:55:23 2019 +0100 scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane) [ Upstream commit 02f7e9f351a9de95577eafdc3bd413ed1c3b589f ] When using this driver on a Blizzard 1260, there were failures whenever DMA transfers from the SCSI bus to memory of 65535 bytes were followed by a DMA transfer of 1 byte. This caused the byte at offset 65535 to be overwritten with 0xff. The Blizzard hardware can't handle single byte DMA transfers. Besides this issue, limiting the DMA length to something that is not a multiple of the page size is very inefficient on most file systems. It seems this limit was chosen because the DMA transfer counter of the ESP by default is 16 bits wide, thus limiting the length to 65535 bytes. However, the value 0 means 65536 bytes, which is handled by the ESP and the Blizzard just fine. It is also the default maximum used by esp_scsi when drivers don't provide their own dma_length_limit() function. The limit of 65536 bytes can be used by all boards except the Fastlane. The old driver used a limit of 65532 bytes (0xfffc), which is reintroduced in this patch. Fixes: b7ded0e8b0d1 ("scsi: zorro_esp: Limit DMA transfers to 65535 bytes") Link: https://lore.kernel.org/r/20191112175523.23145-1-jongk@linux-m68k.org Signed-off-by: Kars de Jong Reviewed-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0cec640db89bfbb2d01d7ea9fe33bbab696ee595 Author: Matthew Wilcox (Oracle) Date: Fri Nov 1 21:36:39 2019 -0400 idr: Fix idr_get_next_ul race with idr_remove [ Upstream commit 5a74ac4c4a97bd8b7dba054304d598e2a882fea6 ] Commit 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove") neglected to fix idr_get_next_ul(). As far as I can tell, nobody's actually using this interface under the RCU read lock, but fix it now before anybody decides to use it. Fixes: 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove") Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 052d878cc2d138e350ee13ce5e6ad4c8309928bb Author: Jean-Baptiste Maneyrol Date: Thu Jun 27 13:19:53 2019 +0000 iio: imu: mpu6050: add missing available scan masks [ Upstream commit 1244a720572fd1680ac8d6b8a4235f2e8557b810 ] Driver only supports 3-axis gyro and/or 3-axis accel. For icm20602, temp data is mandatory for all configurations. Fix all single and double axis configurations (almost never used) and more importantly fix 3-axis gyro and 6-axis accel+gyro buffer on icm20602 when temp data is not enabled. Signed-off-by: Jean-Baptiste Maneyrol Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 89f3ac7eb35ebb32db91672d5d751f8e28af037b Author: Roman Bolshakov Date: Mon Nov 25 19:56:54 2019 +0300 scsi: qla2xxx: Change discovery state before PLOGI [ Upstream commit 58e39a2ce4be08162c0368030cdc405f7fd849aa ] When a port sends PLOGI, discovery state should be changed to login pending, otherwise RELOGIN_NEEDED bit is set in qla24xx_handle_plogi_done_event(). RELOGIN_NEEDED triggers another PLOGI, and it never goes out of the loop until login timer expires. Fixes: 8777e4314d397 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine") Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag") Cc: Quinn Tran Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191125165702.1013-6-r.bolshakov@yadro.com Acked-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Tested-by: Hannes Reinecke Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a40982c7e1f9d0a528bc32c17974f95b8ed5c40c Author: Guoqing Jiang Date: Wed Nov 27 17:57:50 2019 +0100 raid5: need to set STRIPE_HANDLE for batch head [ Upstream commit a7ede3d16808b8f3915c8572d783530a82b2f027 ] With commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list"), we don't want to set STRIPE_HANDLE flag for sh which is already in batch list. However, the stripe which is the head of batch list should set this flag, otherwise panic could happen inside init_stripe at BUG_ON(sh->batch_head), it is reproducible with raid5 on top of nvdimm devices per Xiao oberserved. Thanks for Xiao's effort to verify the change. Fixes: 6ce220dd2f8ea ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list") Reported-by: Xiao Ni Tested-by: Xiao Ni Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 2de650648f07bad6451832c6b8447e7c972ad097 Author: Hans de Goede Date: Wed Nov 6 12:51:09 2019 +0100 gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist [ Upstream commit 2727315df3f5ffbebcb174eed3153944a858b66f ] The Terra Pad 1061 has the usual micro-USB-B id-pin handler, but instead of controlling the actual micro-USB-B it turns the 5V boost for the tablet's USB-A connector and its keyboard-cover connector off. The actual micro-USB-B connector on the tablet is wired for charging only, and its id pin is *not* connected to the GPIO which is used for the (broken) id-pin event handler in the DSDT. While at it not only add a comment why the Terra Pad 1061 is on the blacklist, but also fix the missing comment for the Minix Neo Z83-4 entry. Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist") Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 14cb20ad6bfcd3b66ce5defa5b2d3d4c4553c9a9 Author: Paulo Alcantara (SUSE) Date: Fri Nov 22 12:30:53 2019 -0300 cifs: Fix potential softlockups while refreshing DFS cache [ Upstream commit 84a1f5b1cc6fd7f6cd99fc5630c36f631b19fa60 ] We used to skip reconnects on all SMB2_IOCTL commands due to SMB3+ FSCTL_VALIDATE_NEGOTIATE_INFO - which made sense since we're still establishing a SMB session. However, when refresh_cache_worker() calls smb2_get_dfs_refer() and we're under reconnect, SMB2_ioctl() will not be able to get a proper status error (e.g. -EHOSTDOWN in case we failed to reconnect) but an -EAGAIN from cifs_send_recv() thus looping forever in refresh_cache_worker(). Fixes: e99c63e4d86d ("SMB3: Fix deadlock in validate negotiate hits reconnect") Signed-off-by: Paulo Alcantara (SUSE) Suggested-by: Aurelien Aptel Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 12c88d91a82f30e54febb95fa68f6ce75108e22f Author: Konstantin Khorenko Date: Wed Nov 13 12:29:50 2019 +0300 kernel/module.c: wakeup processes in module_wq on module unload [ Upstream commit 5d603311615f612320bb77bd2a82553ef1ced5b7 ] Fix the race between load and unload a kernel module. sys_delete_module() try_stop_module() mod->state = _GOING add_unformed_module() old = find_module_all() (old->state == _GOING => wait_event_interruptible()) During pre-condition finished_loading() rets 0 schedule() (never gets waken up later) free_module() mod->state = _UNFORMED list_del_rcu(&mod->list) (dels mod from "modules" list) return The race above leads to modprobe hanging forever on loading a module. Error paths on loading module call wake_up_all(&module_wq) after freeing module, so let's do the same on straight module unload. Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading") Reviewed-by: Prarit Bhargava Signed-off-by: Konstantin Khorenko Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 0773dcee661aa4a91acdae1a3bc5238a3e350e22 Author: Frank Rowand Date: Thu Nov 21 13:16:56 2019 -0600 of: overlay: add_changeset_property() memory leak [ Upstream commit 637392a8506a3a7dd24ab9094a14f7522adb73b4 ] No changeset entries are created for #address-cells and #size-cells properties, but the duplicated properties are never freed. This results in a memory leak which is detected by kmemleak: unreferenced object 0x85887180 (size 64): backtrace: kmem_cache_alloc_trace+0x1fb/0x1fc __of_prop_dup+0x25/0x7c add_changeset_property+0x17f/0x370 build_changeset_next_level+0x29/0x20c of_overlay_fdt_apply+0x32b/0x6b4 ... Fixes: 6f75118800ac ("of: overlay: validate overlay properties #address-cells and #size-cells") Reported-by: Vincent Whitchurch Signed-off-by: Frank Rowand Tested-by: Vincent Whitchurch Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 0809e1087c3d6f0aeb3246114a06c96bb4102274 Author: Bob Peterson Date: Thu Nov 14 09:49:11 2019 -0500 gfs2: fix glock reference problem in gfs2_trans_remove_revoke [ Upstream commit fe5e7ba11fcf1d75af8173836309e8562aefedef ] Commit 9287c6452d2b fixed a situation in which gfs2 could use a glock after it had been freed. To do that, it temporarily added a new glock reference by calling gfs2_glock_hold in function gfs2_add_revoke. However, if the bd element was removed by gfs2_trans_remove_revoke, it failed to drop the additional reference. This patch adds logic to gfs2_trans_remove_revoke to properly drop the additional glock reference. Fixes: 9287c6452d2b ("gfs2: Fix occasional glock use-after-free") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 2de11b2e5dd2dce4f0f44101bb7aadb49e13de41 Author: Yoshihiro Shimoda Date: Tue Nov 5 19:51:29 2019 +0900 PCI: rcar: Fix missing MACCTLR register setting in initialization sequence [ Upstream commit 7c7e53e1c93df14690bd12c1f84730fef927a6f1 ] The R-Car Gen2/3 manual - available at: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html#documents "RZ/G Series User's Manual: Hardware" section strictly enforces the MACCTLR inizialization value - 39.3.1 - "Initial Setting of PCI Express": "Be sure to write the initial value (= H'80FF 0000) to MACCTLR before enabling PCIETCTLR.CFINIT". To avoid unexpected behavior and to match the SW initialization sequence guidelines, this patch programs the MACCTLR with the correct value. Note that the MACCTLR.SPCHG bit in the MACCTLR register description reports that "Only writing 1 is valid and writing 0 is invalid" but this "invalid" has to be interpreted as a write-ignore aka "ignored", not "prohibited". Reported-by: Eugeniu Rosca Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver") Fixes: be20bbcb0a8c ("PCI: rcar: Add the initialization of PCIe link in resume_noirq()") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Lorenzo Pieralisi Reviewed-by: Geert Uytterhoeven Cc: # v5.2+ Signed-off-by: Sasha Levin commit f1fd9d0bfd925afb58c496bd7cb3b24545349ff1 Author: Martin Schiller Date: Fri Oct 25 09:01:42 2019 +0200 leds: trigger: netdev: fix handling on interface rename [ Upstream commit 5f820ed52371b4f5d8c43c93f03408d0dbc01e5b ] The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 935f39807a7e95678e5bda50757af326691a211c Author: Eran Ben Elisha Date: Thu Dec 5 10:30:22 2019 +0200 net/mlx5e: Fix SFF 8472 eeprom length [ Upstream commit c431f8597863a91eea6024926e0c1b179cfa4852 ] SFF 8472 eeprom length is 512 bytes. Fix module info return value to support 512 bytes read. Fixes: ace329f4ab3b ("net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query") Signed-off-by: Eran Ben Elisha Reviewed-by: Aya Levin Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 67256225ecf3b70f5829a95049dd7aa2997b5427 Author: Pavel Tikhomirov Date: Tue Oct 1 11:03:59 2019 +0300 sunrpc: fix crash when cache_head become valid before update [ Upstream commit 5fcaf6982d1167f1cd9b264704f6d1ef4c505d54 ] I was investigating a crash in our Virtuozzo7 kernel which happened in in svcauth_unix_set_client. I found out that we access m_client field in ip_map structure, which was received from sunrpc_cache_lookup (we have a bit older kernel, now the code is in sunrpc_cache_add_entry), and these field looks uninitialized (m_client == 0x74 don't look like a pointer) but in the cache_head in flags we see 0x1 which is CACHE_VALID. It looks like the problem appeared from our previous fix to sunrpc (1): commit 4ecd55ea0742 ("sunrpc: fix cache_head leak due to queued request") And we've also found a patch already fixing our patch (2): commit d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.") Though the crash is eliminated, I think the core of the problem is not completely fixed: Neil in the patch (2) makes cache_head CACHE_NEGATIVE, before cache_fresh_locked which was added in (1) to fix crash. These way cache_is_valid won't say the cache is valid anymore and in svcauth_unix_set_client the function cache_check will return error instead of 0, and we don't count entry as initialized. But it looks like we need to remove cache_fresh_locked completely in sunrpc_cache_lookup: In (1) we've only wanted to make cache_fresh_unlocked->cache_dequeue so that cache_requests with no readers also release corresponding cache_head, to fix their leak. We with Vasily were not sure if cache_fresh_locked and cache_fresh_unlocked should be used in pair or not, so we've guessed to use them in pair. Now we see that we don't want the CACHE_VALID bit set here by cache_fresh_locked, as "valid" means "initialized" and there is no initialization in sunrpc_cache_add_entry. Both expiry_time and last_refresh are not used in cache_fresh_unlocked code-path and also not required for the initial fix. So to conclude cache_fresh_locked was called by mistake, and we can just safely remove it instead of crutching it with CACHE_NEGATIVE. It looks ideologically better for me. Hope I don't miss something here. Here is our crash backtrace: [13108726.326291] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074 [13108726.326365] IP: [] svcauth_unix_set_client+0x2ab/0x520 [sunrpc] [13108726.326448] PGD 0 [13108726.326468] Oops: 0002 [#1] SMP [13108726.326497] Modules linked in: nbd isofs xfs loop kpatch_cumulative_81_0_r1(O) xt_physdev nfnetlink_queue bluetooth rfkill ip6table_nat nf_nat_ipv6 ip_vs_wrr ip_vs_wlc ip_vs_sh nf_conntrack_netlink ip_vs_sed ip_vs_pe_sip nf_conntrack_sip ip_vs_nq ip_vs_lc ip_vs_lblcr ip_vs_lblc ip_vs_ftp ip_vs_dh nf_nat_ftp nf_conntrack_ftp iptable_raw xt_recent nf_log_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_TCPMSS xt_tcpmss vxlan ip6_udp_tunnel udp_tunnel xt_statistic xt_NFLOG nfnetlink_log dummy xt_mark xt_REDIRECT nf_nat_redirect raw_diag udp_diag tcp_diag inet_diag netlink_diag af_packet_diag unix_diag rpcsec_gss_krb5 xt_addrtype ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 ebtable_nat ebtable_broute nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle ip6table_raw nfsv4 [13108726.327173] dns_resolver cls_u32 binfmt_misc arptable_filter arp_tables ip6table_filter ip6_tables devlink fuse_kio_pcs ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_wdog_tmo xt_multiport bonding xt_set xt_conntrack iptable_filter iptable_mangle kpatch(O) ebtable_filter ebt_among ebtables ip_set_hash_ip ip_set nfnetlink vfat fat skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass fuse pcspkr ses enclosure joydev sg mei_me hpwdt hpilo lpc_ich mei ipmi_si shpchp ipmi_devintf ipmi_msghandler xt_ipvs acpi_power_meter ip_vs_rr nfsv3 nfsd auth_rpcgss nfs_acl nfs lockd grace fscache nf_nat cls_fw sch_htb sch_cbq sch_sfq ip_vs em_u32 nf_conntrack tun br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat ip_vznetstat [13108726.327817] ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper scsi_transport_iscsi 8021q syscopyarea sysfillrect garp sysimgblt fb_sys_fops mrp stp ttm llc bnx2x crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel drm dm_multipath ghash_clmulni_intel uas aesni_intel lrw gf128mul glue_helper ablk_helper cryptd tg3 smartpqi scsi_transport_sas mdio libcrc32c i2c_core usb_storage ptp pps_core wmi sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: kpatch_cumulative_82_0_r1] [13108726.328403] CPU: 35 PID: 63742 Comm: nfsd ve: 51332 Kdump: loaded Tainted: G W O ------------ 3.10.0-862.20.2.vz7.73.29 #1 73.29 [13108726.328491] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 10/02/2018 [13108726.328554] task: ffffa0a6a41b1160 ti: ffffa0c2a74bc000 task.ti: ffffa0c2a74bc000 [13108726.328610] RIP: 0010:[] [] svcauth_unix_set_client+0x2ab/0x520 [sunrpc] [13108726.328706] RSP: 0018:ffffa0c2a74bfd80 EFLAGS: 00010246 [13108726.328750] RAX: 0000000000000001 RBX: ffffa0a6183ae000 RCX: 0000000000000000 [13108726.328811] RDX: 0000000000000074 RSI: 0000000000000286 RDI: ffffa0c2a74bfcf0 [13108726.328864] RBP: ffffa0c2a74bfe00 R08: ffffa0bab8c22960 R09: 0000000000000001 [13108726.328916] R10: 0000000000000001 R11: 0000000000000001 R12: ffffa0a32aa7f000 [13108726.328969] R13: ffffa0a6183afac0 R14: ffffa0c233d88d00 R15: ffffa0c2a74bfdb4 [13108726.329022] FS: 0000000000000000(0000) GS:ffffa0e17f9c0000(0000) knlGS:0000000000000000 [13108726.329081] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [13108726.332311] CR2: 0000000000000074 CR3: 00000026a1b28000 CR4: 00000000007607e0 [13108726.334606] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [13108726.336754] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [13108726.338908] PKRU: 00000000 [13108726.341047] Call Trace: [13108726.343074] [] ? groups_alloc+0x34/0x110 [13108726.344837] [] svc_set_client+0x24/0x30 [sunrpc] [13108726.346631] [] svc_process_common+0x241/0x710 [sunrpc] [13108726.348332] [] svc_process+0x103/0x190 [sunrpc] [13108726.350016] [] nfsd+0xdf/0x150 [nfsd] [13108726.351735] [] ? nfsd_destroy+0x80/0x80 [nfsd] [13108726.353459] [] kthread+0xd1/0xe0 [13108726.355195] [] ? create_kthread+0x60/0x60 [13108726.356896] [] ret_from_fork_nospec_begin+0x7/0x21 [13108726.358577] [] ? create_kthread+0x60/0x60 [13108726.360240] Code: 4c 8b 45 98 0f 8e 2e 01 00 00 83 f8 fe 0f 84 76 fe ff ff 85 c0 0f 85 2b 01 00 00 49 8b 50 40 b8 01 00 00 00 48 89 93 d0 1a 00 00 0f c1 02 83 c0 01 83 f8 01 0f 8e 53 02 00 00 49 8b 44 24 38 [13108726.363769] RIP [] svcauth_unix_set_client+0x2ab/0x520 [sunrpc] [13108726.365530] RSP [13108726.367179] CR2: 0000000000000074 Fixes: d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.") Signed-off-by: Pavel Tikhomirov Acked-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 372098d54b33a0431d35be06074efae0a35ce744 Author: Wen Yang Date: Mon Nov 25 23:54:09 2019 +0800 firmware: arm_scmi: Avoid double free in error flow [ Upstream commit 8305e90a894f82c278c17e51a28459deee78b263 ] If device_register() fails, both put_device() and kfree() are called, ending with a double free of the scmi_dev. Calling kfree() is needed only when a failure happens between the allocation of the scmi_dev and its registration, so move it to there and remove it from the error flow. Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback") Signed-off-by: Wen Yang Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f7654ebe928d46bd540e0305dbdcc57752de424c Author: Cong Wang Date: Thu Dec 5 19:39:02 2019 -0800 gre: refetch erspan header from skb->data after pskb_may_pull() [ Upstream commit 0e4940928c26527ce8f97237fef4c8a91cd34207 ] After pskb_may_pull() we should always refetch the header pointers from the skb->data in case it got reallocated. In gre_parse_header(), the erspan header is still fetched from the 'options' pointer which is fetched before pskb_may_pull(). Found this during code review of a KMSAN bug report. Fixes: cb73ee40b1b3 ("net: ip_gre: use erspan key field for tunnel lookup") Cc: Lorenzo Bianconi Signed-off-by: Cong Wang Acked-by: Lorenzo Bianconi Acked-by: William Tu Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f579272b0e06943adabfab13d004e65e356a622 Author: Adrian Hunter Date: Thu Nov 14 16:25:38 2019 +0200 perf callchain: Fix segfault in thread__resolve_callchain_sample() [ Upstream commit aceb98261ea7d9fe38f9c140c5531f0b13623832 ] Do not dereference 'chain' when it is NULL. $ perf record -e intel_pt//u -e branch-misses:u uname $ perf report --itrace=l --branch-history perf: Segmentation fault Fixes: e9024d519d89 ("perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}") Signed-off-by: Adrian Hunter Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20191114142538.4097-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1b83d5756a89bd2824d6aad672782957bfa1e9a2 Author: Tejun Heo Date: Fri Sep 20 13:39:57 2019 -0700 workqueue: Fix missing kfree(rescuer) in destroy_workqueue() commit 8efe1223d73c218ce7e8b2e0e9aadb974b582d7f upstream. Signed-off-by: Tejun Heo Reported-by: Qian Cai Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()") Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit d88fb4f0b0728d578fb886148ee3d2014f7598be Author: Ming Lei Date: Mon Nov 4 16:26:53 2019 +0800 blk-mq: make sure that line break can be printed commit d2c9be89f8ebe7ebcc97676ac40f8dec1cf9b43a upstream. 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores") avoids sysfs buffer overflow, and reserves one character for line break. However, the last snprintf() doesn't get correct 'size' parameter passed in, so fixed it. Fixes: 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores") Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit d7248f5a0b7f9118b2ac5ca84fd53f0f861affe1 Author: Heiko Carstens Date: Mon Nov 18 13:09:52 2019 +0100 s390/smp,vdso: fix ASCE handling [ Upstream commit a2308c11ecbc3471ebb7435ee8075815b1502ef0 ] When a secondary CPU is brought up it must initialize its control registers. CPU A which triggers that a secondary CPU B is brought up stores its control register contents into the lowcore of new CPU B, which then loads these values on startup. This is problematic in various ways: the control register which contains the home space ASCE will correctly contain the kernel ASCE; however control registers for primary and secondary ASCEs are initialized with whatever values were present in CPU A. Typically: - the primary ASCE will contain the user process ASCE of the process that triggered onlining of CPU B. - the secondary ASCE will contain the percpu VDSO ASCE of CPU A. Due to lazy ASCE handling we may also end up with other combinations. When then CPU B switches to a different process (!= idle) it will fixup the primary ASCE. However the problem is that the (wrong) ASCE from CPU A was loaded into control register 1: as soon as an ASCE is attached (aka loaded) a CPU is free to generate TLB entries using that address space. Even though it is very unlikey that CPU B will actually generate such entries, this could result in TLB entries of the address space of the process that ran on CPU A. These entries shouldn't exist at all and could cause problems later on. Furthermore the secondary ASCE of CPU B will not be updated correctly. This means that processes may see wrong results or even crash if they access VDSO data on CPU B. The correct VDSO ASCE will eventually be loaded on return to user space as soon as the kernel executed a call to strnlen_user or an atomic futex operation on CPU B. Fix both issues by intializing the to be loaded control register contents with the correct ASCEs and also enforce (re-)loading of the ASCEs upon first context switch and return to user space. Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit c76adee3471f7fe0553904be7ab13c33eda64a19 Author: Michal Hocko Date: Fri Dec 28 00:38:21 2018 -0800 mm, thp, proc: report THP eligibility for each vma [ Upstream commit 7635d9cbe8327e131a1d3d8517dc186c2796ce2e ] Userspace falls short when trying to find out whether a specific memory range is eligible for THP. There are usecases that would like to know that http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@chino.kir.corp.google.com : This is used to identify heap mappings that should be able to fault thp : but do not, and they normally point to a low-on-memory or fragmentation : issue. The only way to deduce this now is to query for hg resp. nh flags and confronting the state with the global setting. Except that there is also PR_SET_THP_DISABLE that might change the picture. So the final logic is not trivial. Moreover the eligibility of the vma depends on the type of VMA as well. In the past we have supported only anononymous memory VMAs but things have changed and shmem based vmas are supported as well these days and the query logic gets even more complicated because the eligibility depends on the mount option and another global configuration knob. Simplify the current state and report the THP eligibility in /proc//smaps for each existing vma. Reuse transparent_hugepage_enabled for this purpose. The original implementation of this function assumes that the caller knows that the vma itself is supported for THP so make the core checks into __transparent_hugepage_enabled and use it for existing callers. __show_smap just use the new transparent_hugepage_enabled which also checks the vma support status (please note that this one has to be out of line due to include dependency issues). [mhocko@kernel.org: fix oops with NULL ->f_mapping] Link: http://lkml.kernel.org/r/20181224185106.GC16738@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20181211143641.3503-3-mhocko@kernel.org Signed-off-by: Michal Hocko Acked-by: Vlastimil Babka Cc: Dan Williams Cc: David Rientjes Cc: Jan Kara Cc: Mike Rapoport Cc: Paul Oppenheimer Cc: William Kucharski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8599f82351379a8f4bb6c7e3872739a0cfcf88f5 Author: Daniel Schultz Date: Tue Sep 17 10:12:53 2019 +0200 mfd: rk808: Fix RK818 ID template [ Upstream commit 37ef8c2c15bdc1322b160e38986c187de2b877b2 ] The Rockchip PMIC driver can automatically detect connected component versions by reading the ID_MSB and ID_LSB registers. The probe function will always fail with RK818 PMICs because the ID_MSK is 0xFFF0 and the RK818 template ID is 0x8181. This patch changes this value to 0x8180. Fixes: 9d6105e19f61 ("mfd: rk808: Fix up the chip id get failed") Cc: stable@vger.kernel.org Cc: Elaine Zhang Cc: Joseph Chen Signed-off-by: Daniel Schultz Signed-off-by: Heiko Stuebner Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b1ec93dd602aaf8de947f717a7c00aee3a8af1d8 Author: yangerkun Date: Thu Sep 19 14:35:08 2019 +0800 ext4: fix a bug in ext4_wait_for_tail_page_commit commit 565333a1554d704789e74205989305c811fd9c7a upstream. No need to wait for any commit once the page is fully truncated. Besides, it may confuse e.g. concurrent ext4_writepage() with the page still be dirty (will be cleared by truncate_pagecache() in ext4_setattr()) but buffers has been freed; and then trigger a bug show as below: [ 26.057508] ------------[ cut here ]------------ [ 26.058531] kernel BUG at fs/ext4/inode.c:2134! ... [ 26.088130] Call trace: [ 26.088695] ext4_writepage+0x914/0xb28 [ 26.089541] writeout.isra.4+0x1b4/0x2b8 [ 26.090409] move_to_new_page+0x3b0/0x568 [ 26.091338] __unmap_and_move+0x648/0x988 [ 26.092241] unmap_and_move+0x48c/0xbb8 [ 26.093096] migrate_pages+0x220/0xb28 [ 26.093945] kernel_mbind+0x828/0xa18 [ 26.094791] __arm64_sys_mbind+0xc8/0x138 [ 26.095716] el0_svc_common+0x190/0x490 [ 26.096571] el0_svc_handler+0x60/0xd0 [ 26.097423] el0_svc+0x8/0xc Run the procedure (generate by syzkaller) parallel with ext3. void main() { int fd, fd1, ret; void *addr; size_t length = 4096; int flags; off_t offset = 0; char *str = "12345"; fd = open("a", O_RDWR | O_CREAT); assert(fd >= 0); /* Truncate to 4k */ ret = ftruncate(fd, length); assert(ret == 0); /* Journal data mode */ flags = 0xc00f; ret = ioctl(fd, _IOW('f', 2, long), &flags); assert(ret == 0); /* Truncate to 0 */ fd1 = open("a", O_TRUNC | O_NOATIME); assert(fd1 >= 0); addr = mmap(NULL, length, PROT_WRITE | PROT_READ, MAP_SHARED, fd, offset); assert(addr != (void *)-1); memcpy(addr, str, 5); mbind(addr, length, 0, 0, 0, MPOL_MF_MOVE); } And the bug will be triggered once we seen the below order. reproduce1 reproduce2 ... | ... truncate to 4k | change to journal data mode | | memcpy(set page dirty) truncate to 0: | ext4_setattr: | ... | ext4_wait_for_tail_page_commit | | mbind(trigger bug) truncate_pagecache(clean dirty)| ... ... | mbind will call ext4_writepage() since the page still be dirty, and then report the bug since the buffers has been free. Fix it by return directly once offset equals to 0 which means the page has been fully truncated. Reported-by: Hulk Robot Signed-off-by: yangerkun Link: https://lore.kernel.org/r/20190919063508.1045-1-yangerkun@huawei.com Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 326ba910fa716dfcc721d7fd30889e4b1f85b1e0 Author: Darrick J. Wong Date: Tue Oct 15 08:44:32 2019 -0700 splice: only read in as much information as there is pipe buffer space commit 3253d9d093376d62b4a56e609f15d2ec5085ac73 upstream. Andreas Grünbacher reports that on the two filesystems that support iomap directio, it's possible for splice() to return -EAGAIN (instead of a short splice) if the pipe being written to has less space available in its pipe buffers than the length supplied by the calling process. Months ago we fixed splice_direct_to_actor to clamp the length of the read request to the size of the splice pipe. Do the same to do_splice. Fixes: 17614445576b6 ("splice: don't read more than available pipe space") Reported-by: syzbot+3c01db6025f26530cf8d@syzkaller.appspotmail.com Reported-by: Andreas Grünbacher Reviewed-by: Andreas Grünbacher Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 42a929edf5674aa5c9e2883dafca7eff2013729e Author: Alexandre Belloni Date: Mon Oct 21 01:13:20 2019 +0200 rtc: disable uie before setting time and enable after commit 7e7c005b4b1f1f169bcc4b2c3a40085ecc663df2 upstream. When setting the time in the future with the uie timer enabled, rtc_timer_do_work will loop for a while because the expiration of the uie timer was way before the current RTC time and a new timer will be enqueued until the current rtc time is reached. If the uie timer is enabled, disable it before setting the time and enable it after expiring current timers (which may actually be an alarm). This is the safest thing to do to ensure the uie timer is still synchronized with the RTC, especially in the UIE emulation case. Reported-by: syzbot+08116743f8ad6f9a6de7@syzkaller.appspotmail.com Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Link: https://lore.kernel.org/r/20191020231320.8191-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 32b02bfd467f79a55eab70e29baa08d04cbb8683 Author: Chen Jun Date: Sat Nov 30 17:58:11 2019 -0800 mm/shmem.c: cast the type of unmap_start to u64 commit aa71ecd8d86500da6081a72da6b0b524007e0627 upstream. In 64bit system. sb->s_maxbytes of shmem filesystem is MAX_LFS_FILESIZE, which equal LLONG_MAX. If offset > LLONG_MAX - PAGE_SIZE, offset + len < LLONG_MAX in shmem_fallocate, which will pass the checking in vfs_fallocate. /* Check for wrap through zero too */ if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0)) return -EFBIG; loff_t unmap_start = round_up(offset, PAGE_SIZE) in shmem_fallocate causes a overflow. Syzkaller reports a overflow problem in mm/shmem: UBSAN: Undefined behaviour in mm/shmem.c:2014:10 signed integer overflow: '9223372036854775807 + 1' cannot be represented in type 'long long int' CPU: 0 PID:17076 Comm: syz-executor0 Not tainted 4.1.46+ #1 Hardware name: linux, dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100 show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238 __dump_stack lib/dump_stack.c:15 [inline] ubsan_epilogue+0x18/0x70 lib/ubsan.c:164 handle_overflow+0x158/0x1b0 lib/ubsan.c:195 shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104 vfs_fallocate+0x238/0x428 fs/open.c:312 SYSC_fallocate fs/open.c:335 [inline] SyS_fallocate+0x54/0xc8 fs/open.c:239 The highest bit of unmap_start will be appended with sign bit 1 (overflow) when calculate shmem_falloc.start: shmem_falloc.start = unmap_start >> PAGE_SHIFT. Fix it by casting the type of unmap_start to u64, when right shifted. This bug is found in LTS Linux 4.1. It also seems to exist in mainline. Link: http://lkml.kernel.org/r/1573867464-5107-1-git-send-email-chenjun102@huawei.com Signed-off-by: Chen Jun Reviewed-by: Andrew Morton Cc: Hugh Dickins Cc: Qian Cai Cc: Kefeng Wang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 10eb175f8e0504edef86000cf8920a57de05d30d Author: Will Deacon Date: Mon Nov 4 15:58:15 2019 +0000 firmware: qcom: scm: Ensure 'a0' status code is treated as signed commit ff34f3cce278a0982a7b66b1afaed6295141b1fc upstream. The 'a0' member of 'struct arm_smccc_res' is declared as 'unsigned long', however the Qualcomm SCM firmware interface driver expects to receive negative error codes via this field, so ensure that it's cast to 'long' before comparing to see if it is less than 0. Cc: Reviewed-by: Bjorn Andersson Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 8e7a865366105b978eef4108f49a12100eea4299 Author: Theodore Ts'o Date: Mon Nov 11 22:18:13 2019 -0500 ext4: work around deleting a file with i_nlink == 0 safely commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream. If the file system is corrupted such that a file's i_links_count is too small, then it's possible that when unlinking that file, i_nlink will already be zero. Previously we were working around this kind of corruption by forcing i_nlink to one; but we were doing this before trying to delete the directory entry --- and if the file system is corrupted enough that ext4_delete_entry() fails, then we exit with i_nlink elevated, and this causes the orphan inode list handling to be FUBAR'ed, such that when we unmount the file system, the orphan inode list can get corrupted. A better way to fix this is to simply skip trying to call drop_nlink() if i_nlink is already zero, thus moving the check to the place where it makes the most sense. https://bugzilla.kernel.org/show_bug.cgi?id=205433 Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Reviewed-by: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit 79bee5a380342b48d0ce177cb2fb75ef6eeeb1a2 Author: Vincenzo Frascino Date: Mon Dec 2 07:57:29 2019 +0000 powerpc: Fix vDSO clock_getres() [ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ] clock_getres in the vDSO library has to preserve the same behaviour of posix_get_hrtimer_res(). In particular, posix_get_hrtimer_res() does: sec = 0; ns = hrtimer_resolution; and hrtimer_resolution depends on the enablement of the high resolution timers that can happen either at compile or at run time. Fix the powerpc vdso implementation of clock_getres keeping a copy of hrtimer_resolution in vdso data and using that directly. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Cc: stable@vger.kernel.org Signed-off-by: Vincenzo Frascino Reviewed-by: Christophe Leroy Acked-by: Shuah Khan [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES] Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit 12d1ed1977d7398588838c0fe01d2f5325f0e47e Author: Nathan Chancellor Date: Mon Nov 18 21:57:11 2019 -0700 powerpc: Avoid clang warnings around setjmp and longjmp [ Upstream commit c9029ef9c95765e7b63c4d9aa780674447db1ec0 ] Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when setjmp is used") disabled -Wbuiltin-requires-header because of a warning about the setjmp and longjmp declarations. r367387 in clang added another diagnostic around this, complaining that there is no jmp_buf declaration. In file included from ../arch/powerpc/xmon/xmon.c:47: ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of built-in function 'setjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header . [-Werror,-Wincomplete-setjmp-declaration] extern long setjmp(long *); ^ ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of built-in function 'longjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header . [-Werror,-Wincomplete-setjmp-declaration] extern void longjmp(long *, long); ^ 2 errors generated. We are not using the standard library's longjmp/setjmp implementations for obvious reasons; make this clear to clang by using -ffreestanding on these files. Cc: stable@vger.kernel.org # 4.14+ Suggested-by: Segher Boessenkool Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.com Signed-off-by: Sasha Levin commit be55e56eaaa83b7fd39dbdda31abc19e00e9a1f3 Author: Anders Roxell Date: Wed Jun 12 10:11:58 2019 +0200 regulator: 88pm800: fix warning same module names [ Upstream commit 6f10419187d0d5fe395e2a2f2a64370961bf02a3 ] When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800 enabled as loadable modules, we see the following warning: warning: same module names found: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko Rework so that the file is named 88pm800-regulator. Signed-off-by: Anders Roxell Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de986efd26696f171946ee6a5720b3fa0aa43fc5 Author: Miaoqing Pan Date: Fri May 24 11:16:22 2019 +0800 ath10k: fix fw crash by moving chip reset after napi disabled [ Upstream commit 08d80e4cd27ba19f9bee9e5f788f9a9fc440a22f ] On SMP platform, when continuously running wifi up/down, the napi poll can be scheduled during chip reset, which will call ath10k_pci_has_fw_crashed() to check the fw status. But in the reset period, the value from FW_INDICATOR_ADDRESS register will return 0xdeadbeef, which also be treated as fw crash. Fix the issue by moving chip reset after napi disabled. ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6) ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16 ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16 ath10k_pci 0000:01:00.0: Copy Engine register dump: ath10k_pci 0000:01:00.0: [00]: 0x0004a000 0 0 0 0 ath10k_pci 0000:01:00.0: [01]: 0x0004a400 0 0 0 0 ath10k_pci 0000:01:00.0: [02]: 0x0004a800 0 0 0 0 ath10k_pci 0000:01:00.0: [03]: 0x0004ac00 0 0 0 0 ath10k_pci 0000:01:00.0: [04]: 0x0004b000 0 0 0 0 ath10k_pci 0000:01:00.0: [05]: 0x0004b400 0 0 0 0 ath10k_pci 0000:01:00.0: [06]: 0x0004b800 0 0 0 0 ath10k_pci 0000:01:00.0: [07]: 0x0004bc00 1 0 1 0 ath10k_pci 0000:01:00.0: [08]: 0x0004c000 0 0 0 0 ath10k_pci 0000:01:00.0: [09]: 0x0004c400 0 0 0 0 ath10k_pci 0000:01:00.0: [10]: 0x0004c800 0 0 0 0 ath10k_pci 0000:01:00.0: [11]: 0x0004cc00 0 0 0 0 Tested HW: QCA9984,QCA9887,WCN3990 Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 27944403bbac5d451a7c97391276c3b9473628b1 Author: Helen Koike Date: Fri May 17 13:20:11 2019 -0400 media: vimc: fix component match compare [ Upstream commit ee1c71a8e1456ab53fe667281d855849edf26a4d ] If the system has other devices being registered in the component framework, the compare function will be called with a device that doesn't belong to vimc. This device is not necessarily a platform_device, nor have a platform_data (which causes a NULL pointer dereference error) and if it does have a pdata, it is not necessarily type of struct vimc_platform_data. So casting to any of these types is wrong. Instead of expecting a given pdev with a given pdata, just expect for the device it self. vimc-core is the one who creates them, we know in advance exactly which object to expect in the match. Fixes: 4a29b7090749 ("[media] vimc: Subdevices as modules") Signed-off-by: Helen Koike Reviewed-by: Boris Brezillon Tested-by: Boris Brezillon Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a827d6c0c3b58f063c3581f6eb44e93f3175f180 Author: Ido Schimmel Date: Tue Jun 11 10:19:41 2019 +0300 mlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead [ Upstream commit 83d5782681cc12b3d485a83cb34c46b2445f510c ] The driver tries to periodically refresh neighbours that are used to reach nexthops. This is done by periodically calling neigh_event_send(). However, if the neighbour becomes dead, there is nothing we can do to return it to a connected state and the above function call is basically a NOP. This results in the nexthop never being written to the device's adjacency table and therefore never used to forward packets. Fix this by dropping our reference from the dead neighbour and associating the nexthop with a new neigbhour which we will try to refresh. Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing") Signed-off-by: Ido Schimmel Reported-by: Alex Veber Tested-by: Alex Veber Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 52600d00af628c0d14a4ed9ccf7fc1dba38a666e Author: Tony Lindgren Date: Sun Apr 7 11:12:50 2019 -0700 power: supply: cpcap-battery: Fix signed counter sample register [ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ] The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision. Signed-off-by: Tony Lindgren Acked-by: Pavel Machek Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 938de2324afb53acd20893cd8eec8ee6f80de646 Author: Shirish S Date: Wed Jan 16 15:10:40 2019 +0000 x86/MCE/AMD: Carve out the MC4_MISC thresholding quirk [ Upstream commit 30aa3d26edb0f3d7992757287eec0ca588a5c259 ] The MC4_MISC thresholding quirk needs to be applied during S5 -> S0 and S3 -> S0 state transitions, which follow different code paths. Carve it out into a separate function and call it mce_amd_feature_init() where the two code paths of the state transitions converge. [ bp: massage commit message and the carved out function. ] Signed-off-by: Shirish S Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Kees Cook Cc: Thomas Gleixner Cc: Tony Luck Cc: Vishal Verma Cc: Yazen Ghannam Cc: x86-ml Link: https://lkml.kernel.org/r/1547651417-23583-3-git-send-email-shirish.s@amd.com Signed-off-by: Sasha Levin commit 805f5ff87d226ba164094f499acc390029c1dc1e Author: Shirish S Date: Thu Jan 10 07:54:40 2019 +0000 x86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 models [ Upstream commit c95b323dcd3598dd7ef5005d6723c1ba3b801093 ] MC4_MISC thresholding is not supported on all family 0x15 processors, hence skip the x86_model check when applying the quirk. [ bp: massage commit message. ] Signed-off-by: Shirish S Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Tony Luck Cc: Vishal Verma Cc: x86-ml Link: https://lkml.kernel.org/r/1547106849-3476-2-git-send-email-shirish.s@amd.com Signed-off-by: Sasha Levin commit 7bf64b2bc662e732be7af0a49a52154b9d7aa36d Author: Luo Jiaxing Date: Fri Jan 25 22:22:34 2019 +0800 scsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G [ Upstream commit eb44e4d7b5a3090f0114927f42ae575c29664a09 ] The SAS controller cannot support a programmed minimum linkrate of > 1.5G (it will always negotiate to 1.5G at least), so just reject it. This solves a strange situation where the PHY negotiated linkrate may be less than the programmed minimum linkrate. Signed-off-by: Luo Jiaxing Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e6f44b1306c1daf3bb0054affb662787221400c1 Author: Xiang Chen Date: Fri Jan 25 22:22:30 2019 +0800 scsi: hisi_sas: send primitive NOTIFY to SSP situation only [ Upstream commit 569eddcf3a0f4efff4ef96a7012010e0f7daa8b4 ] Send primitive NOTIFY to SSP situation only, or it causes underflow issue when sending IO. Also rename hisi_sas_hw.sl_notify() to hisi_sas_hw. sl_notify_ssp(). Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 84d3454ee8bdc29ef2e4bee91aeed79499165b61 Author: Yonglong Liu Date: Wed Feb 20 10:32:41 2019 +0800 net: hns3: Check variable is valid before assigning it to another [ Upstream commit 676131f7c53ecdd79e29fc8cfcdefe6f9f2485e8 ] In hnae3_register_ae_dev(), ae_algo->ops is assigned to ae_dev->ops before check that ae_algo->ops is valid. And in hnae3_register_ae_algo(), missing check for ae_algo->ops. This patch fixes them. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f10b277ffd095e3acd7b290b1a109a7afe33fe9 Author: Huazhong Tan Date: Thu Jan 31 04:55:44 2019 +0800 net: hns3: change hnae3_register_ae_dev() to int [ Upstream commit 74354140a579008fd164241e3697d9c37e5b8989 ] hnae3_register_ae_dev() may fail, and it should return a error code to its caller, so change hnae3_register_ae_dev() return type to int. Also, when hnae3_register_ae_dev() return error, hns3_probe() should do some error handling and return the error code. Signed-off-by: Huazhong Tan Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f6f6ba644cb1ae67b0f887021ee96cce3c30ef4 Author: Jian Shen Date: Sun Jan 27 00:49:11 2019 +0800 net: hns3: clear pci private data when unload hns3 driver [ Upstream commit ac864c2346d087dd3739435af1b8d36be5f60c75 ] When unload hns3 driver, we should clear the pci private data. Signed-off-by: Jian Shen Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 82060d9311250f2fe9893b89ae13ba0cb6a9d43f Author: Karsten Graul Date: Wed Jan 30 18:51:05 2019 +0100 net/smc: do not wait under send_lock [ Upstream commit 33f3fcc290671590821ff3c0c9396db1ec9b7d4c ] smc_cdc_get_free_slot() might wait for free transfer buffers when using SMC-R. This wait should not be done under the send_lock, which is a spin_lock. This fixes a cpu loop in parallel threads waiting for the send_lock. Signed-off-by: Karsten Graul Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 146f563f9761e070e6ef45e073bdc046035f39a0 Author: Toke Høiland-Jørgensen Date: Wed Jan 9 17:09:44 2019 +0100 sch_cake: Correctly update parent qlen when splitting GSO packets [ Upstream commit 8c6c37fdc20ec9ffaa342f827a8e20afe736fb0c ] To ensure parent qdiscs have the same notion of the number of enqueued packets even after splitting a GSO packet, update the qdisc tree with the number of packets that was added due to the split. Reported-by: Pete Heist Tested-by: Pete Heist Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 36a2e9bf242b49ac6be1e8d57d6da2099d93e405 Author: Stefano Stabellini Date: Fri Dec 21 15:06:32 2018 -0800 pvcalls-front: don't return error when the ring is full [ Upstream commit d90a1ca60a1eccb4383fe203c76223ab4c0799ed ] When the ring is full, size == array_size. It is not an error condition, so simply return 0 instead of an error. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 1fb59428912ed7cf21a4946be5406ccc2fdee50b Author: YueHaibing Date: Mon Nov 19 20:48:19 2018 +0800 e100: Fix passing zero to 'PTR_ERR' warning in e100_load_ucode_wait [ Upstream commit cd0d465bb697a9c7bf66a9fe940f7981232f1676 ] Fix a static code checker warning: drivers/net/ethernet/intel/e100.c:1349 e100_load_ucode_wait() warn: passing zero to 'PTR_ERR' Signed-off-by: YueHaibing Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 27d591844035ea8fd3908a3d1a592e6e4aaf6e02 Author: Nathan Chancellor Date: Thu Dec 20 17:23:44 2018 +0100 drbd: Change drbd_request_detach_interruptible's return type to int [ Upstream commit 5816a0932b4fd74257b8cc5785bc8067186a8723 ] Clang warns when an implicit conversion is done between enumerated types: drivers/block/drbd/drbd_state.c:708:8: warning: implicit conversion from enumeration type 'enum drbd_ret_code' to different enumeration type 'enum drbd_state_rv' [-Wenum-conversion] rv = ERR_INTR; ~ ^~~~~~~~ drbd_request_detach_interruptible's only call site is in the return statement of adm_detach, which returns an int. Change the return type of drbd_request_detach_interruptible to match, silencing Clang's warning. Reported-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 92b4361700f9573c9ab1fb11bffa778e978d1c5f Author: James Smart Date: Thu Nov 29 16:09:38 2018 -0800 scsi: lpfc: Correct topology type reporting on G7 adapters [ Upstream commit 76558b25733140a0c6bd53ea8af04b2811c92ec3 ] Driver missed classifying the chip type for G7 when reporting supported topologies. This resulted in loop being shown as supported on FC links that are not supported per the standard. Add the chip classifications to the topology checks in the driver. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 94fe147f90e6b5fba91f4291489d4b9383e7e9e3 Author: James Smart Date: Thu Nov 29 16:09:37 2018 -0800 scsi: lpfc: Correct code setting non existent bits in sli4 ABORT WQE [ Upstream commit 1c36833d82ff24d0d54215fd956e7cc30fffce54 ] Driver is setting bits in word 10 of the SLI4 ABORT WQE (the wqid). The field was a carry over from a prior SLI revision. The field does not exist in SLI4, and the action may result in an overlap with future definition of the WQE. Remove the setting of WQID in the ABORT WQE. Also cleaned up WQE field settings - initialize to zero, don't bother to set fields to zero. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2759c73b0c4f57c6e6f65525cd96df5f665c7d49 Author: James Smart Date: Thu Nov 29 16:09:33 2018 -0800 scsi: lpfc: Cap NPIV vports to 256 [ Upstream commit 8b47ae69e049ae0b3373859d901f0334322f9fe9 ] Depending on the chipset, the number of NPIV vports may vary and be in excess of what most switches support (256). To avoid confusion with the users, limit the reported NPIV vports to 256. Additionally correct the 16G adapter which is reporting a bogus NPIV vport number if the link is down. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6b0a3e81fa92b8f4bd7f037d6c13bba94fb80242 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:39 2019 +0100 omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251 [ Upstream commit 2398c41d64321e62af54424fd399964f3d48cdc2 ] With a wl1251 child node of mmc3 in the device tree decoded in omap_hsmmc.c to handle special wl1251 initialization, we do no longer need to instantiate the mmc3 through pdata quirks. We also can remove the wlan regulator and reset/interrupt definitions and do them through device tree. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ Acked-by: Tony Lindgren Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 66021cdf44491c1f4dd215ecde7963f03130de06 Author: Wen Yang Date: Tue Nov 26 22:04:52 2019 +0800 usb: typec: fix use after free in typec_register_port() [ Upstream commit 5c388abefda0d92355714010c0199055c57ab6c7 ] We can't use "port->sw" and/or "port->mux" after it has been freed. Fixes: 23481121c81d ("usb: typec: class: Don't use port parent for getting mux handles") Signed-off-by: Wen Yang Cc: stable Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Heikki Krogerus  Link: https://lore.kernel.org/r/20191126140452.14048-1-wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d03d96330d50e3bcbeb5661981f0575216b99931 Author: Mathias Nyman Date: Wed Dec 11 16:20:07 2019 +0200 xhci: make sure interrupts are restored to correct state [ Upstream commit bd82873f23c9a6ad834348f8b83f3b6a5bca2c65 ] spin_unlock_irqrestore() might be called with stale flags after reading port status, possibly restoring interrupts to a incorrect state. If a usb2 port just finished resuming while the port status is read the spin lock will be temporary released and re-acquired in a separate function. The flags parameter is passed as value instead of a pointer, not updating flags properly before the final spin_unlock_irqrestore() is called. Cc: # v3.12+ Fixes: 8b3d45705e54 ("usb: Fix xHCI host issues on remote wakeup.") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 64a8c5018a4b21b04a756a56c495ef47c14e92d9 Author: Quinn Tran Date: Tue Nov 5 07:06:52 2019 -0800 scsi: qla2xxx: Fix SRB leak on switch command timeout [ Upstream commit af2a0c51b1205327f55a7e82e530403ae1d42cbb ] when GPSC/GPDB switch command fails, driver just returns without doing a proper cleanup. This patch fixes this memory leak by calling sp->free() in the error path. Link: https://lore.kernel.org/r/20191105150657.8092-4-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f3a14d031ffa523d96f2fbb7b27f2e0bf756d285 Author: Himanshu Madhani Date: Fri Aug 30 15:23:57 2019 -0700 scsi: qla2xxx: Fix message indicating vectors used by driver [ Upstream commit da48b82425b8bf999fb9f7c220e967c4d661b5f8 ] This patch updates log message which indicates number of vectors used by the driver instead of displaying failure to get maximum requested vectors. Driver will always request maximum vectors during initialization. In the event driver is not able to get maximum requested vectors, it will adjust the allocated vectors. This is normal and does not imply failure in driver. Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Reviewed-by: Lee Duncan Link: https://lore.kernel.org/r/20190830222402.23688-2-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c266dfbc95023a7d1fd2ca66d8139f2093472043 Author: Bart Van Assche Date: Thu Aug 8 20:01:52 2019 -0700 scsi: qla2xxx: Always check the qla2x00_wait_for_hba_online() return value [ Upstream commit e6803efae5acd109fad9f2f07dab674563441a53 ] This patch fixes several Coverity complaints about not always checking the qla2x00_wait_for_hba_online() return value. Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f7ba4776c74affa8a853e0090b7adb498354eec7 Author: Bart Van Assche Date: Thu Aug 8 20:01:48 2019 -0700 scsi: qla2xxx: Fix qla24xx_process_bidir_cmd() [ Upstream commit c29282c65d1cf54daeea63be46243d7f69d72f4d ] Set the r??_data_len variables before using these instead of after. This patch fixes the following Coverity complaint: const: At condition req_data_len != rsp_data_len, the value of req_data_len must be equal to 0. const: At condition req_data_len != rsp_data_len, the value of rsp_data_len must be equal to 0. dead_error_condition: The condition req_data_len != rsp_data_len cannot be true. Cc: Himanshu Madhani Fixes: a9b6f722f62d ("[SCSI] qla2xxx: Implementation of bidirectional.") # v3.7. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3245c2061013d09a17367e11c5645d578d2b4129 Author: Bart Van Assche Date: Thu Aug 8 20:01:40 2019 -0700 scsi: qla2xxx: Fix session lookup in qlt_abort_work() [ Upstream commit ac452b8e79320c9e90c78edf32ba2d42431e4daf ] Pass the correct session ID to find_sess_by_s_id() instead of passing an uninitialized variable. Cc: Himanshu Madhani Fixes: 2d70c103fd2a ("[SCSI] qla2xxx: Add LLD target-mode infrastructure for >= 24xx series") # v3.5. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e46f7e2f0efc44f32204fc7a732fc832088fc7ed Author: Quinn Tran Date: Fri Jul 26 09:07:38 2019 -0700 scsi: qla2xxx: Fix hang in fcport delete path [ Upstream commit f00b3428a801758243693e046b34226e92bc56b3 ] A hang was observed in the fcport delete path when the device was responding slow and an issue-lip path (results in session termination) was taken. Fix this by issuing logo requests unconditionally. PID: 19491 TASK: ffff8e23e67bb150 CPU: 0 COMMAND: "kworker/0:0" #0 [ffff8e2370297bf8] __schedule at ffffffffb4f7dbb0 #1 [ffff8e2370297c88] schedule at ffffffffb4f7e199 #2 [ffff8e2370297c98] schedule_timeout at ffffffffb4f7ba68 #3 [ffff8e2370297d40] msleep at ffffffffb48ad9ff #4 [ffff8e2370297d58] qlt_free_session_done at ffffffffc0c32052 [qla2xxx] #5 [ffff8e2370297e20] process_one_work at ffffffffb48bcfdf #6 [ffff8e2370297e68] worker_thread at ffffffffb48bdca6 #7 [ffff8e2370297ec8] kthread at ffffffffb48c4f81 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bd9138ac3ff56b72dc742563eadbf6753d71768a Author: Himanshu Madhani Date: Fri Jul 26 09:07:26 2019 -0700 scsi: qla2xxx: Fix DMA unmap leak [ Upstream commit 5d328de64d89400dcf9911125844d8adc0db697f ] With debug kernel we see following wanings indicating memory leak. [28809.523959] WARNING: CPU: 3 PID: 6790 at lib/dma-debug.c:978 dma_debug_device_change+0x166/0x1d0 [28809.523964] pci 0000:0c:00.6: DMA-API: device driver has pending DMA allocations while released from device [count=5] [28809.523964] One of leaked entries details: [device address=0x00000002aefe4000] [size=8208 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] Fix this by unmapping DMA memory. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 33b0e54db4e50854263bc2f13b35f07920200e2f Author: Steffen Maier Date: Fri Oct 25 18:12:53 2019 +0200 scsi: zfcp: trace channel log even for FCP command responses [ Upstream commit 100843f176109af94600e500da0428e21030ca7f ] While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace") is right that we don't want to flood the (payload) trace ring buffer, we don't trace successful FCP command responses by default. So we can include the channel log for problem determination with failed responses of any FSF request type. Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace") Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Cc: #2.6.38+ Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.1572018132.git.bblock@linux.ibm.com Reviewed-by: Benjamin Block Signed-off-by: Steffen Maier Signed-off-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 42d72c9d28964fbbaeaa15baf2e7ce418d1c1a0a Author: Ming Lei Date: Sat Dec 1 00:38:18 2018 +0800 block: fix single range discard merge commit 2a5cf35cd6c56b2924bce103413ad3381bdc31fa upstream. There are actually two kinds of discard merge: - one is the normal discard merge, just like normal read/write request, and call it single-range discard - another is the multi-range discard, queue_max_discard_segments(rq->q) > 1 For the former case, queue_max_discard_segments(rq->q) is 1, and we should handle this kind of discard merge like the normal read/write request. This patch fixes the following kernel panic issue[1], which is caused by not removing the single-range discard request from elevator queue. Guangwu has one raid discard test case, in which this issue is a bit easier to trigger, and I verified that this patch can fix the kernel panic issue in Guangwu's test case. [1] kernel panic log from Jens's report BUG: unable to handle kernel NULL pointer dereference at 0000000000000148 PGD 0 P4D 0. Oops: 0000 [#1] SMP PTI CPU: 37 PID: 763 Comm: kworker/37:1H Not tainted \ 4.20.0-rc3-00649-ge64d9a554a91-dirty #14 Hardware name: Wiwynn \ Leopard-Orv2/Leopard-DDR BW, BIOS LBM08 03/03/2017 Workqueue: kblockd \ blk_mq_run_work_fn RIP: \ 0010:blk_mq_get_driver_tag+0x81/0x120 Code: 24 \ 10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 00 00 00 \ 0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 20 72 37 \ f6 87 b0 00 00 00 02 RSP: 0018:ffffc90004aabd30 EFLAGS: 00010246 \ RAX: 0000000000000003 RBX: ffff888465ea1300 RCX: ffffc90004aabde8 RDX: 00000000ffffffff RSI: ffffc90004aabde8 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff888465ea1348 R09: 0000000000000000 R10: 0000000000001000 R11: 00000000ffffffff R12: ffff888465ea1300 R13: 0000000000000000 R14: ffff888465ea1348 R15: ffff888465d10000 FS: 0000000000000000(0000) GS:ffff88846f9c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000148 CR3: 000000000220a003 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: blk_mq_dispatch_rq_list+0xec/0x480 ? elv_rb_del+0x11/0x30 blk_mq_do_dispatch_sched+0x6e/0xf0 blk_mq_sched_dispatch_requests+0xfa/0x170 __blk_mq_run_hw_queue+0x5f/0xe0 process_one_work+0x154/0x350 worker_thread+0x46/0x3c0 kthread+0xf5/0x130 ? process_one_work+0x350/0x350 ? kthread_destroy_worker+0x50/0x50 ret_from_fork+0x1f/0x30 Modules linked in: sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel \ kvm switchtec irqbypass iTCO_wdt iTCO_vendor_support efivars cdc_ether usbnet mii \ cdc_acm i2c_i801 lpc_ich mfd_core ipmi_si ipmi_devintf ipmi_msghandler acpi_cpufreq \ button sch_fq_codel nfsd nfs_acl lockd grace auth_rpcgss oid_registry sunrpc nvme \ nvme_core fuse sg loop efivarfs autofs4 CR2: 0000000000000148 \ ---[ end trace 340a1fb996df1b9b ]--- RIP: 0010:blk_mq_get_driver_tag+0x81/0x120 Code: 24 10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 \ 00 00 00 0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 \ 20 72 37 f6 87 b0 00 00 00 02 Fixes: 445251d0f4d329a ("blk-mq: fix discard merge with scheduler attached") Reported-by: Jens Axboe Cc: Guangwu Zhang Cc: Christoph Hellwig Cc: Jianchao Wang Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Cc: Andre Tomt Cc: Jack Wang Signed-off-by: Greg Kroah-Hartman commit 7b3ea9bb9b947d4ea7f0570162dbc1e036e2c9a0 Author: Jeff Mahoney Date: Thu Oct 24 10:31:27 2019 -0400 reiserfs: fix extended attributes on the root directory commit 60e4cf67a582d64f07713eda5fcc8ccdaf7833e6 upstream. Since commit d0a5b995a308 (vfs: Add IOP_XATTR inode operations flag) extended attributes haven't worked on the root directory in reiserfs. This is due to reiserfs conditionally setting the sb->s_xattrs handler array depending on whether it located or create the internal privroot directory. It necessarily does this after the root inode is already read in. The IOP_XATTR flag is set during inode initialization, so it never gets set on the root directory. This commit unconditionally assigns sb->s_xattrs and clears IOP_XATTR on internal inodes. The old return values due to the conditional assignment are handled via open_xa_root, which now returns EOPNOTSUPP as the VFS would have done. Link: https://lore.kernel.org/r/20191024143127.17509-1-jeffm@suse.com CC: stable@vger.kernel.org Fixes: d0a5b995a308 ("vfs: Add IOP_XATTR inode operations flag") Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 595a92a4f19d29d856311397f3695a92994fe7a3 Author: Jan Kara Date: Tue Nov 5 17:44:12 2019 +0100 ext4: Fix credit estimate for final inode freeing commit 65db869c754e7c271691dd5feabf884347e694f5 upstream. Estimate for the number of credits needed for final freeing of inode in ext4_evict_inode() was to small. We may modify 4 blocks (inode & sb for orphan deletion, bitmap & group descriptor for inode freeing) and not just 3. [ Fixed minor whitespace nit. -- TYT ] Fixes: e50e5129f384 ("ext4: xattr-in-inode support") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191105164437.32602-6-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f919b26fcbb88542c11799edaad84d034cd8adac Author: Dmitry Monakhov Date: Thu Oct 31 10:39:19 2019 +0000 quota: fix livelock in dquot_writeback_dquots commit 6ff33d99fc5c96797103b48b7b0902c296f09c05 upstream. Write only quotas which are dirty at entry. XFSTEST: https://github.com/dmonakhov/xfstests/commit/b10ad23566a5bf75832a6f500e1236084083cddc Link: https://lore.kernel.org/r/20191031103920.3919-1-dmonakhov@openvz.org CC: stable@vger.kernel.org Signed-off-by: Konstantin Khlebnikov Signed-off-by: Dmitry Monakhov Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 26eca105bceae8c9d49e5d4b2829220acb4ef676 Author: Chengguang Xu Date: Tue Nov 5 12:51:00 2019 +0800 ext2: check err when partial != NULL commit e705f4b8aa27a59f8933e8f384e9752f052c469c upstream. Check err when partial == NULL is meaningless because partial == NULL means getting branch successfully without error. CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191105045100.7104-1-cgxu519@mykernel.net Signed-off-by: Chengguang Xu Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 77b14d6ebc6e3dff9c6db607d32bd82bd46e79e8 Author: Dmitry Monakhov Date: Thu Oct 31 10:39:20 2019 +0000 quota: Check that quota is not dirty before release commit df4bb5d128e2c44848aeb36b7ceceba3ac85080d upstream. There is a race window where quota was redirted once we drop dq_list_lock inside dqput(), but before we grab dquot->dq_lock inside dquot_release() TASK1 TASK2 (chowner) ->dqput() we_slept: spin_lock(&dq_list_lock) if (dquot_dirty(dquot)) { spin_unlock(&dq_list_lock); dquot->dq_sb->dq_op->write_dquot(dquot); goto we_slept if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) { spin_unlock(&dq_list_lock); dquot->dq_sb->dq_op->release_dquot(dquot); dqget() mark_dquot_dirty() dqput() goto we_slept; } So dquot dirty quota will be released by TASK1, but on next we_sleept loop we detect this and call ->write_dquot() for it. XFSTEST: https://github.com/dmonakhov/xfstests/commit/440a80d4cbb39e9234df4d7240aee1d551c36107 Link: https://lore.kernel.org/r/20191031103920.3919-2-dmonakhov@openvz.org CC: stable@vger.kernel.org Signed-off-by: Dmitry Monakhov Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ecc8a51cba91dc994c7fa4dfafd9a6bb441c55d9 Author: Ville Syrjälä Date: Thu Sep 19 16:28:53 2019 +0300 video/hdmi: Fix AVI bar unpack commit 6039f37dd6b76641198e290f26b31c475248f567 upstream. The bar values are little endian, not big endian. The pack function did it right but the unpack got it wrong. Fix it. Cc: stable@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Martin Bugge Cc: Hans Verkuil Cc: Thierry Reding Cc: Mauro Carvalho Chehab Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for InfoFrames") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190919132853.30954-1-ville.syrjala@linux.intel.com Reviewed-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit abf104b64c8b207b56df3166dc1635aefd2db50e Author: Cédric Le Goater Date: Tue Dec 3 17:36:42 2019 +0100 powerpc/xive: Skip ioremap() of ESB pages for LSI interrupts commit b67a95f2abff0c34e5667c15ab8900de73d8d087 upstream. The PCI INTx interrupts and other LSI interrupts are handled differently under a sPAPR platform. When the interrupt source characteristics are queried, the hypervisor returns an H_INT_ESB flag to inform the OS that it should be using the H_INT_ESB hcall for interrupt management and not loads and stores on the interrupt ESB pages. A default -1 value is returned for the addresses of the ESB pages. The driver ignores this condition today and performs a bogus IO mapping. Recent changes and the DEBUG_VM configuration option make the bug visible with : kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=1024 NUMA pSeries Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-0.rc6.git0.1.fc32.ppc64le #1 NIP: c000000000f63294 LR: c000000000f62e44 CTR: 0000000000000000 REGS: c0000000fa45f0d0 TRAP: 0700 Not tainted (5.4.0-0.rc6.git0.1.fc32.ppc64le) ... NIP ioremap_page_range+0x4c4/0x6e0 LR ioremap_page_range+0x74/0x6e0 Call Trace: ioremap_page_range+0x74/0x6e0 (unreliable) do_ioremap+0x8c/0x120 __ioremap_caller+0x128/0x140 ioremap+0x30/0x50 xive_spapr_populate_irq_data+0x170/0x260 xive_irq_domain_map+0x8c/0x170 irq_domain_associate+0xb4/0x2d0 irq_create_mapping+0x1e0/0x3b0 irq_create_fwspec_mapping+0x27c/0x3e0 irq_create_of_mapping+0x98/0xb0 of_irq_parse_and_map_pci+0x168/0x230 pcibios_setup_device+0x88/0x250 pcibios_setup_bus_devices+0x54/0x100 __of_scan_bus+0x160/0x310 pcibios_scan_phb+0x330/0x390 pcibios_init+0x8c/0x128 do_one_initcall+0x60/0x2c0 kernel_init_freeable+0x290/0x378 kernel_init+0x2c/0x148 ret_from_kernel_thread+0x5c/0x80 Fixes: bed81ee181dd ("powerpc/xive: introduce H_INT_ESB hcall") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater Tested-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191203163642.2428-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit f80e2ee41491d997e17377bdc79ad8d26ed1ba55 Author: Alastair D'Silva Date: Mon Nov 4 13:32:53 2019 +1100 powerpc: Allow flush_icache_range to work across ranges >4GB commit 29430fae82073d39b1b881a3cd507416a56a363f upstream. When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191104023305.9581-2-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman commit 87682db0a14ae3c11528af61136cd9904923953f Author: Cédric Le Goater Date: Thu Oct 31 07:31:00 2019 +0100 powerpc/xive: Prevent page fault issues in the machine crash handler commit 1ca3dec2b2dff9d286ce6cd64108bda0e98f9710 upstream. When the machine crash handler is invoked, all interrupts are masked but interrupts which have not been started yet do not have an ESB page mapped in the Linux address space. This crashes the 'crash kexec' sequence on sPAPR guests. To fix, force the mapping of the ESB page when an interrupt is being mapped in the Linux IRQ number space. This is done by setting the initial state of the interrupt to OFF which is not necessarily the case on PowerNV. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Cédric Le Goater Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191031063100.3864-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit e0dd31b9e5f4d1ff5edc36f12c52d1b997004fc4 Author: Alastair D'Silva Date: Mon Nov 4 13:32:54 2019 +1100 powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB commit f9ec11165301982585e5e5f606739b5bae5331f3 upstream. When calling __kernel_sync_dicache with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191104023305.9581-3-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman commit 919fc442cf6b681df83a9d1eb3391e7331768ac8 Author: Arnd Bergmann Date: Fri Nov 8 21:34:30 2019 +0100 ppdev: fix PPGETTIME/PPSETTIME ioctls commit 998174042da229e2cf5841f574aba4a743e69650 upstream. Going through the uses of timeval in the user space API, I noticed two bugs in ppdev that were introduced in the y2038 conversion: * The range check was accidentally moved from ppsettime to ppgettime * On sparc64, the microseconds are in the other half of the 64-bit word. Fix both, and mark the fix for stable backports. Cc: stable@vger.kernel.org Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20191108203435.112759-8-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c85b9f7deb81348a0b9f35799a8e6a0b0ccddeac Author: Jarkko Nikula Date: Sat Nov 16 17:16:51 2019 +0200 ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity commit 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream. The MMC card detection GPIO polarity is active low on TAO3530, like in many other similar boards. Now the card is not detected and it is unable to mount rootfs from an SD card. Fix this by using the correct polarity. This incorrect polarity was defined already in the commit 30d95c6d7092 ("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18 kernel and later changed to use defined GPIO constants in v4.4 kernel by the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards"). While the latter commit did not introduce the issue I'm marking it with Fixes tag due the v4.4 kernels still being maintained. Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards") Cc: linux-stable # 4.4+ Signed-off-by: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 6c44b58d95bb29b5116be0d539c659e6a462da75 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:37 2019 +0100 mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card commit f6498b922e57aecbe3b7fa30a308d9d586c0c369 upstream. Pandora_wl1251_init_card was used to do special pdata based setup of the sdio mmc interface. This does no longer work with v4.7 and later. A fix requires a device tree based mmc3 setup. Therefore we move the special setup to omap_hsmmc.c instead of calling some pdata supplied init_card function. The new code checks for a DT child node compatible to wl1251 so it will not affect other MMC3 use cases. Generally, this code was and still is a hack and should be moved to mmc core to e.g. read such properties from optional DT child nodes. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ [Ulf: Fixed up some checkpatch complaints] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8e059f7bda9a8cc58767c61ffdf8608d30c92efe Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:09 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in S3C64xx wakeup controller init commit 7f028caadf6c37580d0f59c6c094ed09afc04062 upstream. In s3c64xx_eint_eint0_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 61dd72613177 ("pinctrl: Add pinctrl-s3c64xx driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 1d9501c2cef2d5368ae1c0aa744655ce91ca0ee3 Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:10 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in init code commit a322b3377f4bac32aa25fb1acb9e7afbbbbd0137 upstream. Several functions use for_each_child_of_node() loop with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit fcfaf1258751c07a92ce763db207db2ac6e20dfb Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:08 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in S3C24xx wakeup controller init commit 6fbbcb050802d6ea109f387e961b1dbcc3a80c96 upstream. In s3c24xx_eint_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: af99a7507469 ("pinctrl: Add pinctrl-s3c24xx driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 1aaf409ebd9c2bfb168fa65106b6f5f984c0cf48 Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:07 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in Exynos wakeup controller init commit 5c7f48dd14e892e3e920dd6bbbd52df79e1b3b41 upstream. In exynos_eint_wkup_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 43b169db1841 ("pinctrl: add exynos4210 specific extensions for samsung pinctrl driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 0c72a9f1f9dd3ce80ca7976c8534a095f4743483 Author: Nishka Dasgupta Date: Sun Aug 4 21:32:00 2019 +0530 pinctrl: samsung: Add of_node_put() before return in error path commit 3d2557ab75d4c568c79eefa2e550e0d80348a6bd upstream. Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return of exynos_eint_wkup_init() error path. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta Cc: Fixes: 14c255d35b25 ("pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 935057b02087c8729d6e0ae72aaf42a2b45a4d21 Author: Gregory CLEMENT Date: Fri Nov 15 16:57:52 2019 +0100 pinctrl: armada-37xx: Fix irq mask access in armada_37xx_irq_set_type() commit 04fb02757ae5188031eb71b2f6f189edb1caf5dc upstream. As explained in the following commit a9a1a4833613 ("pinctrl: armada-37xx: Fix gpio interrupt setup") the armada_37xx_irq_set_type() function can be called before the initialization of the mask field. That means that we can't use this field in this function and need to workaround it using hwirq. Fixes: 30ac0d3b0702 ("pinctrl: armada-37xx: Add edge both type gpio irq support") Cc: stable@vger.kernel.org Reported-by: Russell King Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191115155752.2562-1-gregory.clement@bootlin.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 24f41534919509450ae4f9b3e4e17c014ffef2dd Author: Rafael J. Wysocki Date: Wed Dec 4 02:54:27 2019 +0100 ACPI: PM: Avoid attaching ACPI PM domain to certain devices commit b9ea0bae260f6aae546db224daa6ac1bd9d94b91 upstream. Certain ACPI-enumerated devices represented as platform devices in Linux, like fans, require special low-level power management handling implemented by their drivers that is not in agreement with the ACPI PM domain behavior. That leads to problems with managing ACPI fans during system-wide suspend and resume. For this reason, make acpi_dev_pm_attach() skip the affected devices by adding a list of device IDs to avoid to it and putting the IDs of the affected devices into that list. Fixes: e5cc8ef31267 (ACPI / PM: Provide ACPI PM callback routines for subsystems) Reported-by: Zhang Rui Tested-by: Todd Brandt Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1309b43650dee26d16f21fe69e6060e42a48d005 Author: Vamshi K Sthambamkadi Date: Thu Nov 28 15:58:29 2019 +0530 ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data() commit 627ead724eff33673597216f5020b72118827de4 upstream. kmemleak reported backtrace: [] kmem_cache_alloc_trace+0x128/0x260 [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0 [<1180f4fc>] i2c_register_adapter+0x186/0x400 [<6083baf7>] i2c_add_adapter+0x4e/0x70 [] intel_gmbus_setup+0x1a2/0x2c0 [i915] [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915] [<81911d4b>] i915_pci_probe+0x48/0x160 [i915] [<4b159af1>] pci_device_probe+0xdc/0x160 [] really_probe+0x1ee/0x450 [] driver_probe_device+0x142/0x1b0 [] device_driver_attach+0x49/0x50 [] __driver_attach+0xc9/0x150 [] bus_for_each_dev+0x56/0xa0 [<80089bba>] driver_attach+0x19/0x20 [] bus_add_driver+0x177/0x220 [<7b29d8c7>] driver_register+0x56/0xf0 In i2c_acpi_remove_space_handler(), a leak occurs whenever the "data" parameter is initialized to 0 before being passed to acpi_bus_get_private_data(). This is because the NULL pointer check in acpi_bus_get_private_data() (condition->if(!*data)) returns EINVAL and, in consequence, memory is never freed in i2c_acpi_remove_space_handler(). Fix the NULL pointer check in acpi_bus_get_private_data() to follow the analogous check in acpi_get_data_full(). Signed-off-by: Vamshi K Sthambamkadi [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b81b6f35fa704d55412d0df132b93248454a849b Author: Francesco Ruggeri Date: Tue Nov 19 21:47:27 2019 -0800 ACPI: OSL: only free map once in osl.c commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream. acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock before freeing the map. This creates a race condition the can result in the map being freed more than once. A panic can be caused by running for ((i=0; i<10; i++)) do for ((j=0; j<100000; j++)) do cat /sys/firmware/acpi/tables/data/BERT >/dev/null done & done This patch makes sure that only the process that drops the reference to 0 does the freeing. Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c") Signed-off-by: Francesco Ruggeri Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9f5ee706852e43782910de18e74ef357a4b07d23 Author: Mika Westerberg Date: Wed Oct 30 18:05:45 2019 +0300 ACPI / hotplug / PCI: Allocate resources directly under the non-hotplug bridge commit 77adf9355304f8dcf09054280af5e23fc451ab3d upstream. Valerio and others reported that commit 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug") prevents some recent LG and HP laptops from booting with endless loop of: ACPI Error: No handler or method for GPE 08, disabling event (20190215/evgpe-835) ACPI Error: No handler or method for GPE 09, disabling event (20190215/evgpe-835) ACPI Error: No handler or method for GPE 0A, disabling event (20190215/evgpe-835) ... What seems to happen is that during boot, after the initial PCI enumeration when EC is enabled the platform triggers ACPI Notify() to one of the root ports. The root port itself looks like this: pci 0000:00:1b.0: PCI bridge to [bus 02-3a] pci 0000:00:1b.0: bridge window [mem 0xc4000000-0xda0fffff] pci 0000:00:1b.0: bridge window [mem 0x80000000-0xa1ffffff 64bit pref] The BIOS has configured the root port so that it does not have I/O bridge window. Now when the ACPI Notify() is triggered ACPI hotplug handler calls acpiphp_native_scan_bridge() for each non-hotplug bridge (as this system is using native PCIe hotplug) and pci_assign_unassigned_bridge_resources() to allocate resources. The device connected to the root port is a PCIe switch (Thunderbolt controller) with two hotplug downstream ports. Because of the hotplug ports __pci_bus_size_bridges() tries to add "additional I/O" of 256 bytes to each (DEFAULT_HOTPLUG_IO_SIZE). This gets further aligned to 4k as that's the minimum I/O window size so each hotplug port gets 4k I/O window and the same happens for the root port (which is also hotplug port). This means 3 * 4k = 12k I/O window. Because of this pci_assign_unassigned_bridge_resources() ends up opening a I/O bridge window for the root port at first available I/O address which seems to be in range 0x1000 - 0x3fff. Normally this range is used for ACPI stuff such as GPE bits (below is part of /proc/ioports): 1800-1803 : ACPI PM1a_EVT_BLK 1804-1805 : ACPI PM1a_CNT_BLK 1808-180b : ACPI PM_TMR 1810-1815 : ACPI CPU throttle 1850-1850 : ACPI PM2_CNT_BLK 1854-1857 : pnp 00:05 1860-187f : ACPI GPE0_BLK However, when the ACPI Notify() happened this range was not yet reserved for ACPI/PNP (that happens later) so PCI gets it. It then starts writing to this range and accidentally stomps over GPE bits among other things causing the endless stream of messages about missing GPE handler. This problem does not happen if "pci=hpiosize=0" is passed in the kernel command line. The reason is that then the kernel does not try to allocate the additional 256 bytes for each hotplug port. Fix this by allocating resources directly below the non-hotplug bridges where a new device may appear as a result of ACPI Notify(). This avoids the hotplug bridges and prevents opening the additional I/O window. Fixes: 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug") Link: https://bugzilla.kernel.org/show_bug.cgi?id=203617 Link: https://lore.kernel.org/r/20191030150545.19885-1-mika.westerberg@linux.intel.com Reported-by: Valerio Passini Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2324a66924008f899b7d4df0f3f34c288fcac927 Author: John Hubbard Date: Wed Oct 30 22:21:59 2019 -0700 cpufreq: powernv: fix stack bloat and hard limit on number of CPUs commit db0d32d84031188443e25edbd50a71a6e7ac5d1d upstream. The following build warning occurred on powerpc 64-bit builds: drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is with a cross-compiler based on gcc 8.1.0, which I got from: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ The warning is due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and it's also undesirable to have a hard limit on the number of CPUs here. Fix both problems by dynamically allocating based on num_possible_cpus, as recommended by Michael Ellerman. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Signed-off-by: John Hubbard Acked-by: Viresh Kumar Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b1d06da38497b017739a4837b34122aa44f56d90 Author: Leonard Crestez Date: Tue Sep 24 10:52:23 2019 +0300 PM / devfreq: Lock devfreq in trans_stat_show commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream. There is no locking in this sysfs show function so stats printing can race with a devfreq_update_status called as part of freq switching or with initialization. Also add an assert in devfreq_update_status to make it clear that lock must be held by caller. Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats") Cc: stable@vger.kernel.org Signed-off-by: Leonard Crestez Reviewed-by: Matthias Kaehlcke Reviewed-by: Chanwoo Choi Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 1fce7e81b94baf07af77e2c0a7f6736b3719897a Author: Alexander Shishkin Date: Wed Nov 20 15:08:06 2019 +0200 intel_th: pci: Add Tiger Lake CPU support commit 6e6c18bcb78c0dc0601ebe216bed12c844492d0c upstream. This adds support for the Trace Hub in Tiger Lake CPU. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191120130806.44028-4-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fc8e3ca5418bbb85cc0044dd01c130b0ff43f090 Author: Alexander Shishkin Date: Wed Nov 20 15:08:05 2019 +0200 intel_th: pci: Add Ice Lake CPU support commit 6a1743422a7c0fda26764a544136cac13e5ae486 upstream. This adds support for the Trace Hub in Ice Lake CPU. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191120130806.44028-3-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit aa5d849be16511186cdb1d7b63fcbcc38ac51f2f Author: Alexander Shishkin Date: Wed Nov 20 15:08:04 2019 +0200 intel_th: Fix a double put_device() in error path commit 512592779a337feb5905d8fcf9498dbf33672d4a upstream. Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") factored out intel_th_subdevice_alloc() from intel_th_populate(), but got the error path wrong, resulting in two instances of a double put_device() on a freshly initialized, but not 'added' device. Fix this by only doing one put_device() in the error path. Signed-off-by: Alexander Shishkin Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") Reported-by: Wen Yang Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v4.14+ Link: https://lore.kernel.org/r/20191120130806.44028-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b56d00ace1fc0c0382a730c056e35c01a12f8ff4 Author: Gao Xiang Date: Sun Dec 1 16:01:09 2019 +0800 erofs: zero out when listxattr is called with no xattr commit 926d1650176448d7684b991fbe1a5b1a8289e97c upstream. As David reported [1], ENODATA returns when attempting to modify files by using EROFS as an overlayfs lower layer. The root cause is that listxattr could return unexpected -ENODATA by mistake for inodes without xattr. That breaks listxattr return value convention and it can cause copy up failure when used with overlayfs. Resolve by zeroing out if no xattr is found for listxattr. [1] https://lore.kernel.org/r/CAEvUa7nxnby+rxK-KRMA46=exeOMApkDMAV08AjMkkPnTPV4CQ@mail.gmail.com Link: https://lore.kernel.org/r/20191201084040.29275-1-hsiangkao@aol.com Fixes: cadf1ccf1b00 ("staging: erofs: add error handling for xattr submodule") Cc: # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit c96788214ed3eac541501365ce47ff5c3bad836d Author: Zhenzhong Duan Date: Wed Oct 23 09:57:14 2019 +0800 cpuidle: Do not unset the driver if it is there already commit 918c1fe9fbbe46fcf56837ff21f0ef96424e8b29 upstream. Fix __cpuidle_set_driver() to check if any of the CPUs in the mask has a driver different from drv already and, if so, return -EBUSY before updating any cpuidle_drivers per-CPU pointers. Fixes: 82467a5a885d ("cpuidle: simplify multiple driver support") Cc: 3.11+ # 3.11+ Signed-off-by: Zhenzhong Duan [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit aedc1c75ff6affa30e37e7d1a3a48d6686eefe6f Author: Hans Verkuil Date: Mon Sep 16 02:47:41 2019 -0300 media: cec.h: CEC_OP_REC_FLAG_ values were swapped commit 806e0cdfee0b99efbb450f9f6e69deb7118602fc upstream. CEC_OP_REC_FLAG_NOT_USED is 0 and CEC_OP_REC_FLAG_USED is 1, not the other way around. Signed-off-by: Hans Verkuil Reported-by: Jiunn Chang Cc: # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit acdb4a6b24ff4e2c1ecdcd5529ac5b5a22789d47 Author: Johan Hovold Date: Thu Oct 10 10:13:32 2019 -0300 media: radio: wl1273: fix interrupt masking on release commit 1091eb830627625dcf79958d99353c2391f41708 upstream. If a process is interrupted while accessing the radio device and the core lock is contended, release() could return early and fail to update the interrupt mask. Note that the return value of the v4l2 release file operation is ignored. Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver") Cc: stable # 2.6.38 Cc: Matti Aaltonen Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2f86d5af05fa1570fdc54380626d02929115bf4e Author: Johan Hovold Date: Thu Oct 10 10:13:31 2019 -0300 media: bdisp: fix memleak on release commit 11609a7e21f8cea42630350aa57662928fa4dc63 upstream. If a process is interrupted while accessing the video device and the device lock is contended, release() could return early and fail to free related resources. Note that the return value of the v4l2 release file operation is ignored. Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Cc: stable # 4.2 Signed-off-by: Johan Hovold Reviewed-by: Fabien Dessenne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4ca41aa4c6641f7eb5c30b9f7f11055dccc8c9ea Author: Gerald Schaefer Date: Wed Sep 11 19:42:23 2019 +0200 s390/mm: properly clear _PAGE_NOEXEC bit when it is not supported commit ab874f22d35a8058d8fdee5f13eb69d8867efeae upstream. On older HW or under a hypervisor, w/o the instruction-execution- protection (IEP) facility, and also w/o EDAT-1, a translation-specification exception may be recognized when bit 55 of a pte is one (_PAGE_NOEXEC). The current code tries to prevent setting _PAGE_NOEXEC in such cases, by removing it within set_pte_at(). However, ptep_set_access_flags() will modify a pte directly, w/o using set_pte_at(). There is at least one scenario where this can result in an active pte with _PAGE_NOEXEC set, which would then lead to a panic due to a translation-specification exception (write to swapped out page): do_swap_page pte = mk_pte (with _PAGE_NOEXEC bit) set_pte_at (will remove _PAGE_NOEXEC bit in page table, but keep it in local variable pte) vmf->orig_pte = pte (pte still contains _PAGE_NOEXEC bit) do_wp_page wp_page_reuse entry = vmf->orig_pte (still with _PAGE_NOEXEC bit) ptep_set_access_flags (writes entry with _PAGE_NOEXEC bit) Fix this by clearing _PAGE_NOEXEC already in mk_pte_phys(), where the pgprot value is applied, so that no pte with _PAGE_NOEXEC will ever be visible, if it is not supported. The check in set_pte_at() can then also be removed. Cc: # 4.11+ Fixes: 57d7f939e7bd ("s390: add no-execute support") Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 0cc303ba19f8844236731248ede929b213ad980d Author: Denis Efremov Date: Mon Sep 30 23:31:47 2019 +0300 ar5523: check NULL before memcpy() in ar5523_cmd() commit 315cee426f87658a6799815845788fde965ddaad upstream. memcpy() call with "idata == NULL && ilen == 0" results in undefined behavior in ar5523_cmd(). For example, NULL is passed in callchain "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch adds ilen check before memcpy() call in ar5523_cmd() to prevent an undefined behavior. Cc: Pontus Fuchs Cc: Kalle Valo Cc: "David S. Miller" Cc: David Laight Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a1de70aa867fb1756eafc45584c525cc6e4fdde2 Author: Aleksa Sarai Date: Thu Oct 17 02:50:01 2019 +1100 cgroup: pids: use atomic64_t for pids->limit commit a713af394cf382a30dd28a1015cbe572f1b9ca75 upstream. Because pids->limit can be changed concurrently (but we don't want to take a lock because it would be needlessly expensive), use atomic64_ts instead. Fixes: commit 49b786ea146f ("cgroup: implement the PIDs subsystem") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Aleksa Sarai Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 317c80c672ce60e4eec8cf50d5df2520385c940f Author: Ming Lei Date: Sat Nov 2 16:02:15 2019 +0800 blk-mq: avoid sysfs buffer overflow with too many CPU cores commit 8962842ca5abdcf98e22ab3b2b45a103f0408b95 upstream. It is reported that sysfs buffer overflow can be triggered if the system has too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs of hctx via /sys/block/$DEV/mq/$N/cpu_list. Use snprintf to avoid the potential buffer overflow. This version doesn't change the attribute format, and simply stops showing CPU numbers if the buffer is going to overflow. Cc: stable@vger.kernel.org Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queue map on driver load") Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a12c768df372747ebe0551fbc386b701f02c2b0b Author: David Jeffery Date: Mon Sep 16 13:15:14 2019 -0400 md: improve handling of bio with REQ_PREFLUSH in md_flush_request() commit 775d78319f1ceb32be8eb3b1202ccdc60e9cb7f1 upstream. If pers->make_request fails in md_flush_request(), the bio is lost. To fix this, pass back a bool to indicate if the original make_request call should continue to handle the I/O and instead of assuming the flush logic will push it to completion. Convert md_flush_request to return a bool and no longer calls the raid driver's make_request function. If the return is true, then the md flush logic has or will complete the bio and the md make_request call is done. If false, then the md make_request function needs to keep processing like it is a normal bio. Let the original call to md_handle_request handle any need to retry sending the bio to the raid driver's make_request function should it be needed. Also mark md_flush_request and the make_request function pointer as __must_check to issue warnings should these critical return values be ignored. Fixes: 2bc13b83e629 ("md: batch flush requests.") Cc: stable@vger.kernel.org # # v4.19+ Cc: NeilBrown Signed-off-by: David Jeffery Reviewed-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit d88d9321e88cce771734377577767db0b1fea0cf Author: Pawel Harlozinski Date: Tue Nov 12 14:02:36 2019 +0100 ASoC: Jack: Fix NULL pointer dereference in snd_soc_jack_report commit 8f157d4ff039e03e2ed4cb602eeed2fd4687a58f upstream. Check for existance of jack before tracing. NULL pointer dereference has been reported by KASAN while unloading machine driver (snd_soc_cnl_rt274). Signed-off-by: Pawel Harlozinski Link: https://lore.kernel.org/r/20191112130237.10141-1-pawel.harlozinski@linux.intel.com Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 29674d00ca2b363863d397ab9226f6846206080b Author: Jacob Rasmussen Date: Thu Nov 14 16:20:11 2019 -0700 ASoC: rt5645: Fixed typo for buddy jack support. commit fe23be2d85b05f561431d75acddec726ea807d2a upstream. Had a typo in e7cfd867fd98 that resulted in buddy jack support not being fixed. Fixes: e7cfd867fd98 ("ASoC: rt5645: Fixed buddy jack support.") Signed-off-by: Jacob Rasmussen Reviewed-by: Ross Zwisler Cc: CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191114232011.165762-1-jacobraz@google.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fcea88b2ace8328a5c46a04079c9f088c3fbaebb Author: Jacob Rasmussen Date: Mon Nov 11 11:59:57 2019 -0700 ASoC: rt5645: Fixed buddy jack support. commit e7cfd867fd9842f346688f28412eb83dec342900 upstream. The headphone jack on buddy was broken with the following commit: commit 6b5da66322c5 ("ASoC: rt5645: read jd1_1 status for jd detection"). This changes the jd_mode for buddy to 4 so buddy can read from the same register that was used in the working version of this driver without affecting any other devices that might use this, since no other device uses jd_mode = 4. To test this I plugged and uplugged the headphone jack, verifying audio works. Signed-off-by: Jacob Rasmussen Reviewed-by: Ross Zwisler Link: https://lore.kernel.org/r/20191111185957.217244-1-jacobraz@google.com Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ebd9fbf9e7c781d79a39ae814764c3c3ac166c93 Author: Tejun Heo Date: Wed Sep 25 06:59:15 2019 -0700 workqueue: Fix pwq ref leak in rescuer_thread() commit e66b39af00f426b3356b96433d620cb3367ba1ff upstream. 008847f66c3 ("workqueue: allow rescuer thread to do more work.") made the rescuer worker requeue the pwq immediately if there may be more work items which need rescuing instead of waiting for the next mayday timer expiration. Unfortunately, it doesn't check whether the pwq is already on the mayday list and unconditionally gets the ref and moves it onto the list. This doesn't corrupt the list but creates an additional reference to the pwq. It got queued twice but will only be removed once. This leak later can trigger pwq refcnt warning on workqueue destruction and prevent freeing of the workqueue. Signed-off-by: Tejun Heo Cc: "Williams, Gerald S" Cc: NeilBrown Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Greg Kroah-Hartman commit 7c43540e884345998824376782bc5134aeb166b6 Author: Tejun Heo Date: Wed Sep 18 18:43:40 2019 -0700 workqueue: Fix spurious sanity check failures in destroy_workqueue() commit def98c84b6cdf2eeea19ec5736e90e316df5206b upstream. Before actually destrying a workqueue, destroy_workqueue() checks whether it's actually idle. If it isn't, it prints out a bunch of warning messages and leaves the workqueue dangling. It unfortunately has a couple issues. * Mayday list queueing increments pwq's refcnts which gets detected as busy and fails the sanity checks. However, because mayday list queueing is asynchronous, this condition can happen without any actual work items left in the workqueue. * Sanity check failure leaves the sysfs interface behind too which can lead to init failure of newer instances of the workqueue. This patch fixes the above two by * If a workqueue has a rescuer, disable and kill the rescuer before sanity checks. Disabling and killing is guaranteed to flush the existing mayday list. * Remove sysfs interface before sanity checks. Signed-off-by: Tejun Heo Reported-by: Marcin Pawlowski Reported-by: "Williams, Gerald S" Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56a830249038c2d4d88b78a43ed12582ba9a41c3 Author: Dmitry Fomichev Date: Wed Nov 6 14:34:35 2019 -0800 dm zoned: reduce overhead of backing device checks commit e7fad909b68aa37470d9f2d2731b5bec355ee5d6 upstream. Commit 75d66ffb48efb3 added backing device health checks and as a part of these checks, check_events() block ops template call is invoked in dm-zoned mapping path as well as in reclaim and flush path. Calling check_events() with ATA or SCSI backing devices introduces a blocking scsi_test_unit_ready() call being made in sd_check_events(). Even though the overhead of calling scsi_test_unit_ready() is small for ATA zoned devices, it is much larger for SCSI and it affects performance in a very negative way. Fix this performance regression by executing check_events() only in case of any I/O errors. The function dmz_bdev_is_dying() is modified to call only blk_queue_dying(), while calls to check_events() are made in a new helper function, dmz_check_bdev(). Reported-by: zhangxiaoxu Fixes: 75d66ffb48efb3 ("dm zoned: properly handle backing device failure") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Fomichev Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 10b9bf59bab1018940e8949c6861d1a7fb0393a1 Author: Maged Mokhtar Date: Wed Oct 23 22:41:17 2019 +0200 dm writecache: handle REQ_FUA commit c1005322ff02110a4df7f0033368ea015062b583 upstream. Call writecache_flush() on REQ_FUA in writecache_map(). Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Maged Mokhtar Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7c07d0267364194aae9786ec0b3d70a65c83329b Author: Sumit Garg Date: Mon Oct 14 17:32:45 2019 +0530 hwrng: omap - Fix RNG wait loop timeout commit be867f987a4e1222114dd07a01838a17c26f3fff upstream. Existing RNG data read timeout is 200us but it doesn't cover EIP76 RNG data rate which takes approx. 700us to produce 16 bytes of output data as per testing results. So configure the timeout as 1000us to also take account of lack of udelay()'s reliability. Fixes: 383212425c92 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Cc: Signed-off-by: Sumit Garg Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f785f33c23ad6bad78d82d148c3dd9c3600cd2ae Author: Amir Goldstein Date: Fri Dec 6 08:33:36 2019 +0200 ovl: relax WARN_ON() on rename to self commit 6889ee5a53b8d969aa542047f5ac8acdc0e79a91 upstream. In ovl_rename(), if new upper is hardlinked to old upper underneath overlayfs before upper dirs are locked, user will get an ESTALE error and a WARN_ON will be printed. Changes to underlying layers while overlayfs is mounted may result in unexpected behavior, but it shouldn't crash the kernel and it shouldn't trigger WARN_ON() either, so relax this WARN_ON(). Reported-by: syzbot+bb1836a212e69f8e201a@syzkaller.appspotmail.com Fixes: 804032fabb3b ("ovl: don't check rename to self") Cc: # v4.9+ Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 3e929ddf18ed66970ac002a1a0d1bdcacc77643a Author: Amir Goldstein Date: Sun Nov 17 17:43:44 2019 +0200 ovl: fix corner case of non-unique st_dev;st_ino commit 9c6d8f13e9da10a26ad7f0a020ef86e8ef142835 upstream. On non-samefs overlay without xino, non pure upper inodes should use a pseudo_dev assigned to each unique lower fs and pure upper inodes use the real upper st_dev. It is fine for an overlay pure upper inode to use the same st_dev;st_ino values as the real upper inode, because the content of those two different filesystem objects is always the same. In this case, however: - two filesystems, A and B - upper layer is on A - lower layer 1 is also on A - lower layer 2 is on B Non pure upper overlay inode, whose origin is in layer 1 will have the same st_dev;st_ino values as the real lower inode. This may result with a false positive results of 'diff' between the real lower and copied up overlay inode. Fix this by using the upper st_dev;st_ino values in this case. This breaks the property of constant st_dev;st_ino across copy up of this case. This breakage will be fixed by a later patch. Fixes: 5148626b806a ("ovl: allocate anon bdev per unique lower fs") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 458f77a499b6a9a9d511520888d4cfabc53c25d1 Author: Greg Kroah-Hartman Date: Fri Dec 6 16:26:00 2019 +0100 lib: raid6: fix awk build warnings commit 702600eef73033ddd4eafcefcbb6560f3e3a90f7 upstream. Newer versions of awk spit out these fun warnings: awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operator As commit 700c1018b86d ("x86/insn: Fix awk regexp warnings") showed, it turns out that there are a number of awk strings that do not need to be escaped and newer versions of awk now warn about this. Fix the string up so that no warning is produced. The exact same kernel module gets created before and after this patch, showing that it wasn't needed. Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.com Signed-off-by: Greg Kroah-Hartman commit 4ee6af20c2e11232bbd0a586c0130e944b3b3d26 Author: Larry Finger Date: Mon Nov 11 13:40:46 2019 -0600 rtlwifi: rtl8192de: Fix missing enable interrupt flag commit 330bb7117101099c687e9c7f13d48068670b9c62 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), the flag that indicates that interrupts are enabled was never set. In addition, there are several places when enable/disable interrupts were commented out are restored. A sychronize_interrupts() call is removed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # v3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 0aa2570917f4fe5d6c37f54140cabd1bd682a638 Author: Larry Finger Date: Mon Nov 11 13:40:45 2019 -0600 rtlwifi: rtl8192de: Fix missing callback that tests for hw release of buffer commit 3155db7613edea8fb943624062baf1e4f9cfbfd6 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback needed to check if the hardware has released a buffer indicating that a DMA operation is completed was not added. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # v3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 56a35a3f5a33948232f3f74ac99c7d7f2bb4e64a Author: Larry Finger Date: Mon Nov 11 13:40:44 2019 -0600 rtlwifi: rtl8192de: Fix missing code to retrieve RX buffer address commit 0e531cc575c4e9e3dd52ad287b49d3c2dc74c810 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback to get the RX buffer address was added to the PCI driver. Unfortunately, driver rtl8192de was not modified appropriately and the code runs into a WARN_ONCE() call. The use of an incorrect array is also fixed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # 3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8862b80bd517ff64b93e65a6288114bda51d34ab Author: Josef Bacik Date: Fri Nov 15 15:43:06 2019 -0500 btrfs: record all roots for rename exchange on a subvol commit 3e1740993e43116b3bc71b0aad1e6872f6ccf341 upstream. Testing with the new fsstress support for subvolumes uncovered a pretty bad problem with rename exchange on subvolumes. We're modifying two different subvolumes, but we only start the transaction on one of them, so the other one is not added to the dirty root list. This is caught by btrfs_cow_block() with a warning because the root has not been updated, however if we do not modify this root again we'll end up pointing at an invalid root because the root item is never updated. Fix this by making sure we add the destination root to the trans list, the same as we do with normal renames. This fixes the corruption. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f80318536150968ae29b03cc7e9bcc57c392642f Author: Filipe Manana Date: Wed Oct 30 12:23:01 2019 +0000 Btrfs: send, skip backreference walking for extents with many references commit fd0ddbe2509568b00df364156f47561e9f469f15 upstream. Backreference walking, which is used by send to figure if it can issue clone operations instead of write operations, can be very slow and use too much memory when extents have many references. This change simply skips backreference walking when an extent has more than 64 references, in which case we fallback to a write operation instead of a clone operation. This limit is conservative and in practice I observed no signicant slowdown with up to 100 references and still low memory usage up to that limit. This is a temporary workaround until there are speedups in the backref walking code, and as such it does not attempt to add extra interfaces or knobs to tweak the threshold. Reported-by: Atemu Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3SGdoinVo=C9eQ@mail.gmail.com/T/#me55dc0987f9cc2acaa54372ce0492c65782be3fa CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dc2a320dc2a8d08c41ad304185efdf831d9c1f30 Author: Qu Wenruo Date: Thu Oct 24 09:38:29 2019 +0800 btrfs: Remove btrfs_bio::flags member commit 34b127aecd4fe8e6a3903e10f204a7b7ffddca22 upstream. The last user of btrfs_bio::flags was removed in commit 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io"), remove it. (Tagged for stable as the structure is heavily used and space savings are desirable.) CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dfca82a7abcd015110bd2378044009f0ba7a077d Author: Tejun Heo Date: Thu Oct 3 07:27:13 2019 -0700 btrfs: Avoid getting stuck during cyclic writebacks commit f7bddf1e27d18fbc7d3e3056ba449cfbe4e20b0a upstream. During a cyclic writeback, extent_write_cache_pages() uses done_index to update the writeback_index after the current run is over. However, instead of current index + 1, it gets to to the current index itself. Unfortunately, this, combined with returning on EOF instead of looping back, can lead to the following pathlogical behavior. 1. There is a single file which has accumulated enough dirty pages to trigger balance_dirty_pages() and the writer appending to the file with a series of short writes. 2. balance_dirty_pages kicks in, wakes up background writeback and sleeps. 3. Writeback kicks in and the cursor is on the last page of the dirty file. Writeback is started or skipped if already in progress. As it's EOF, extent_write_cache_pages() returns and the cursor is set to done_index which is pointing to the last page. 4. Writeback is done. Nothing happens till balance_dirty_pages finishes, at which point we go back to #1. This can almost completely stall out writing back of the file and keep the system over dirty threshold for a long time which can mess up the whole system. We encountered this issue in production with a package handling application which can reliably reproduce the issue when running under tight memory limits. Reading the comment in the error handling section, this seems to be to avoid accidentally skipping a page in case the write attempt on the page doesn't succeed. However, this concern seems bogus. On each page, the code either: * Skips and moves onto the next page. * Fails issue and sets done_index to index + 1. * Successfully issues and continue to the next page if budget allows and not EOF. IOW, as long as it's not EOF and there's budget, the code never retries writing back the same page. Only when a page happens to be the last page of a particular run, we end up retrying the page, which can't possibly guarantee anything data integrity related. Besides, cyclic writes are only used for non-syncing writebacks meaning that there's no data integrity implication to begin with. Fix it by always setting done_index past the current page being processed. Note that this problem exists in other writepages too. CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Tejun Heo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8155dbe015f57d17cd729a58dfb4425a9d726918 Author: Filipe Manana Date: Fri Oct 11 16:41:20 2019 +0100 Btrfs: fix negative subv_writers counter and data space leak after buffered write commit a0e248bb502d5165b3314ac3819e888fdcdf7d9f upstream. When doing a buffered write it's possible to leave the subv_writers counter of the root, used for synchronization between buffered nocow writers and snapshotting. This happens in an exceptional case like the following: 1) We fail to allocate data space for the write, since there's not enough available data space nor enough unallocated space for allocating a new data block group; 2) Because of that failure, we try to go to NOCOW mode, which succeeds and therefore we set the local variable 'only_release_metadata' to true and set the root's sub_writers counter to 1 through the call to btrfs_start_write_no_snapshotting() made by check_can_nocow(); 3) The call to btrfs_copy_from_user() returns zero, which is very unlikely to happen but not impossible; 4) No pages are copied because btrfs_copy_from_user() returned zero; 5) We call btrfs_end_write_no_snapshotting() which decrements the root's subv_writers counter to 0; 6) We don't set 'only_release_metadata' back to 'false' because we do it only if 'copied', the value returned by btrfs_copy_from_user(), is greater than zero; 7) On the next iteration of the while loop, which processes the same page range, we are now able to allocate data space for the write (we got enough data space released in the meanwhile); 8) After this if we fail at btrfs_delalloc_reserve_metadata(), because now there isn't enough free metadata space, or in some other place further below (prepare_pages(), lock_and_cleanup_extent_if_need(), btrfs_dirty_pages()), we break out of the while loop with 'only_release_metadata' having a value of 'true'; 9) Because 'only_release_metadata' is 'true' we end up decrementing the root's subv_writers counter to -1 (through a call to btrfs_end_write_no_snapshotting()), and we also end up not releasing the data space previously reserved through btrfs_check_data_free_space(). As a consequence the mechanism for synchronizing NOCOW buffered writes with snapshotting gets broken. Fix this by always setting 'only_release_metadata' to false at the start of each iteration. Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume") Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9d0e32f0162299bc20bb27752d94a74b4fc591dd Author: Filipe Manana Date: Wed Oct 9 17:43:59 2019 +0100 Btrfs: fix metadata space leak on fixup worker failure to set range as delalloc commit 536870071dbc4278264f59c9a2f5f447e584d139 upstream. In the fixup worker, if we fail to mark the range as delalloc in the io tree, we must release the previously reserved metadata, as well as update the outstanding extents counter for the inode, otherwise we leak metadata space. In pratice we can't return an error from btrfs_set_extent_delalloc(), which is just a wrapper around __set_extent_bit(), as for most errors __set_extent_bit() does a BUG_ON() (or panics which hits a BUG_ON() as well) and returning an -EEXIST error doesn't happen in this case since the exclusive bits parameter always has a value of 0 through this code path. Nevertheless, just fix the error handling in the fixup worker, in case one day __set_extent_bit() can return an error to this code path. Fixes: f3038ee3a3f101 ("btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit eda96b244dd7d4d6da30eff2f32645a843a7446e Author: Josef Bacik Date: Thu Sep 26 08:29:32 2019 -0400 btrfs: use refcount_inc_not_zero in kill_all_nodes commit baf320b9d531f1cfbf64c60dd155ff80a58b3796 upstream. We hit the following warning while running down a different problem [ 6197.175850] ------------[ cut here ]------------ [ 6197.185082] refcount_t: underflow; use-after-free. [ 6197.194704] WARNING: CPU: 47 PID: 966 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60 [ 6197.521792] Call Trace: [ 6197.526687] __btrfs_release_delayed_node+0x76/0x1c0 [ 6197.536615] btrfs_kill_all_delayed_nodes+0xec/0x130 [ 6197.546532] ? __btrfs_btree_balance_dirty+0x60/0x60 [ 6197.556482] btrfs_clean_one_deleted_snapshot+0x71/0xd0 [ 6197.566910] cleaner_kthread+0xfa/0x120 [ 6197.574573] kthread+0x111/0x130 [ 6197.581022] ? kthread_create_on_node+0x60/0x60 [ 6197.590086] ret_from_fork+0x1f/0x30 [ 6197.597228] ---[ end trace 424bb7ae00509f56 ]--- This is because the free side drops the ref without the lock, and then takes the lock if our refcount is 0. So you can have nodes on the tree that have a refcount of 0. Fix this by zero'ing out that element in our temporary array so we don't try to kill it again. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ add comment ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6e3b9068b863716bd4dfcff530055a042ad39d52 Author: Josef Bacik Date: Tue Sep 24 16:50:43 2019 -0400 btrfs: check page->mapping when loading free space cache commit 3797136b626ad4b6582223660c041efdea8f26b2 upstream. While testing 5.2 we ran into the following panic [52238.017028] BUG: kernel NULL pointer dereference, address: 0000000000000001 [52238.105608] RIP: 0010:drop_buffers+0x3d/0x150 [52238.304051] Call Trace: [52238.308958] try_to_free_buffers+0x15b/0x1b0 [52238.317503] shrink_page_list+0x1164/0x1780 [52238.325877] shrink_inactive_list+0x18f/0x3b0 [52238.334596] shrink_node_memcg+0x23e/0x7d0 [52238.342790] ? do_shrink_slab+0x4f/0x290 [52238.350648] shrink_node+0xce/0x4a0 [52238.357628] balance_pgdat+0x2c7/0x510 [52238.365135] kswapd+0x216/0x3e0 [52238.371425] ? wait_woken+0x80/0x80 [52238.378412] ? balance_pgdat+0x510/0x510 [52238.386265] kthread+0x111/0x130 [52238.392727] ? kthread_create_on_node+0x60/0x60 [52238.401782] ret_from_fork+0x1f/0x30 The page we were trying to drop had a page->private, but had no page->mapping and so called drop_buffers, assuming that we had a buffer_head on the page, and then panic'ed trying to deref 1, which is our page->private for data pages. This is happening because we're truncating the free space cache while we're trying to load the free space cache. This isn't supposed to happen, and I'll fix that in a followup patch. However we still shouldn't allow those sort of mistakes to result in messing with pages that do not belong to us. So add the page->mapping check to verify that we still own this page after dropping and re-acquiring the page lock. This page being unlocked as: btrfs_readpage extent_read_full_page __extent_read_full_page __do_readpage if (!nr) unlock_page <-- nr can be 0 only if submit_extent_page returns an error CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik [ add callchain ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 80c291c11f1cdfead1ff75d1276a2d8f5067f8a6 Author: Yoshihiro Shimoda Date: Mon Oct 7 16:55:10 2019 +0900 phy: renesas: rcar-gen3-usb2: Fix sysfs interface of "role" commit 4bd5ead82d4b877ebe41daf95f28cda53205b039 upstream. Since the role_store() uses strncmp(), it's possible to refer out-of-memory if the sysfs data size is smaller than strlen("host"). This patch fixes it by using sysfs_streq() instead of strncmp(). Reported-by: Pavel Machek Fixes: 9bb86777fb71 ("phy: rcar-gen3-usb2: add sysfs for usb role swap") Cc: # v4.10+ Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-by: Pavel Machek Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit c6f58dcdbacbbd56fbec50deae8dc77937a831c7 Author: Thinh Nguyen Date: Wed Nov 27 13:10:54 2019 -0800 usb: dwc3: ep0: Clear started flag on completion commit 2d7b78f59e020b07fc6338eefe286f54ee2d6773 upstream. Clear ep0's DWC3_EP_TRANSFER_STARTED flag if the END_TRANSFER command is completed. Otherwise, we can't start control transfer again after END_TRANSFER. Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 16831495d435710c4ae2cd663dc131b821549a68 Author: Tejas Joglekar Date: Wed Nov 13 11:45:16 2019 +0530 usb: dwc3: gadget: Fix logical condition commit 8c7d4b7b3d43c54c0b8c1e4adb917a151c754196 upstream. This patch corrects the condition to kick the transfer without giving back the requests when either request has remaining data or when there are pending SGs. The && check was introduced during spliting up the dwc3_gadget_ep_cleanup_completed_requests() function. Fixes: f38e35dd84e2 ("usb: dwc3: gadget: split dwc3_gadget_ep_cleanup_completed_requests()") Cc: stable@vger.kernel.org Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6aa56f58aaf5cd43c59bea0d81049459a3822d89 Author: Heikki Krogerus Date: Thu Dec 12 12:37:13 2019 +0300 usb: dwc3: pci: add ID for the Intel Comet Lake -H variant commit 3c3caae4cd6e122472efcf64759ff6392fb6bce2 upstream. The original ID that was added for Comet Lake PCH was actually for the -LP (low power) variant even though the constant for it said CMLH. Changing that while at it. Signed-off-by: Heikki Krogerus Acked-by: Felipe Balbi Cc: stable Link: https://lore.kernel.org/r/20191212093713.60614-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 472f9483303d851d77a6d7190ef37f89646980d1 Author: David Hildenbrand Date: Wed Dec 11 12:11:52 2019 +0100 virtio-balloon: fix managed page counts when migrating pages between zones commit 63341ab03706e11a31e3dd8ccc0fbc9beaf723f0 upstream. In case we have to migrate a ballon page to a newpage of another zone, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and online the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 spanned 262144 present 262144 managed 18446744073709533486 6. Do anything that requires some memory (e.g., inflate the balloon some more). The OOM goes crazy and the system crashes [ 238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00 [ 238.338585] systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 [ 238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G D W 5.4.0-next-20191204+ #75 [ 238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4 [ 238.341121] Call Trace: [ 238.341337] dump_stack+0x8f/0xd0 [ 238.341630] dump_header+0x61/0x5ea [ 238.341942] oom_kill_process.cold+0xb/0x10 [ 238.342299] out_of_memory+0x24d/0x5a0 [ 238.342625] __alloc_pages_slowpath+0xd12/0x1020 [ 238.343024] __alloc_pages_nodemask+0x391/0x410 [ 238.343407] pagecache_get_page+0xc3/0x3a0 [ 238.343757] filemap_fault+0x804/0xc30 [ 238.344083] ? ext4_filemap_fault+0x28/0x42 [ 238.344444] ext4_filemap_fault+0x30/0x42 [ 238.344789] __do_fault+0x37/0x1a0 [ 238.345087] __handle_mm_fault+0x104d/0x1ab0 [ 238.345450] handle_mm_fault+0x169/0x360 [ 238.345790] do_user_addr_fault+0x20d/0x490 [ 238.346154] do_page_fault+0x31/0x210 [ 238.346468] async_page_fault+0x43/0x50 [ 238.346797] RIP: 0033:0x7f47eba4197e [ 238.347110] Code: Bad RIP value. [ 238.347387] RSP: 002b:00007ffd7c0c1890 EFLAGS: 00010293 [ 238.347834] RAX: 0000000000000002 RBX: 000055d196a20a20 RCX: 00007f47eba4197e [ 238.348437] RDX: 0000000000000033 RSI: 00007ffd7c0c18c0 RDI: 0000000000000004 [ 238.349047] RBP: 00007ffd7c0c1c20 R08: 0000000000000000 R09: 0000000000000033 [ 238.349660] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000001 [ 238.350261] R13: ffffffffffffffff R14: 0000000000000000 R15: 00007ffd7c0c18c0 [ 238.350878] Mem-Info: [ 238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0 [ 238.351085] active_file:12 inactive_file:7 isolated_file:0 [ 238.351085] unevictable:0 dirty:0 writeback:0 unstable:0 [ 238.351085] slab_reclaimable:5565 slab_unreclaimable:10170 [ 238.351085] mapped:3 shmem:111 pagetables:155 bounce:0 [ 238.351085] free:720717 free_pcp:2 free_cma:0 [ 238.353757] Node 0 active_anon:12484kB inactive_anon:204kB active_file:48kB inactive_file:28kB unevictable:0kB iss [ 238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB reserved_highatomic:0KB active_anon:152kB inactivB [ 238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884 [ 238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB high:13052kB reserved_highatomic:0KB active_anon:0B [ 238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 72057594037927865 [ 238.361888] Node 0 Normal free:193448kB min:99395541895224kB low:73886371836733356kB high:147673348131571488kB reB [ 238.364765] lowmem_reserve[]: 0 0 0 0 0 [ 238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B [ 238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B [ 238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B [ 238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 238.369915] 130 total pagecache pages [ 238.370241] 0 pages in swap cache [ 238.370533] Swap cache stats: add 0, delete 0, find 0/0 [ 238.370981] Free swap = 0kB [ 238.371239] Total swap = 0kB [ 238.371488] 1048445 pages RAM [ 238.371756] 0 pages HighMem/MovableOnly [ 238.372090] 306992 pages reserved [ 238.372376] 0 pages cma reserved [ 238.372661] 0 pages hwpoisoned In another instance (older kernel), I was able to observe this (negative page count :/): [ 180.896971] Offlined Pages 32768 [ 182.667462] Offlined Pages 32768 [ 184.408117] Offlined Pages 32768 [ 186.026321] Offlined Pages 32768 [ 187.684861] Offlined Pages 32768 [ 189.227013] Offlined Pages 32768 [ 190.830303] Offlined Pages 32768 [ 190.833071] Built 1 zonelists, mobility grouping on. Total pages: -36920272750453009 In another instance (older kernel), I was no longer able to start any process: [root@vm ~]# [ 214.348068] Offlined Pages 32768 [ 215.973009] Offlined Pages 32768 cat /proc/meminfo -bash: fork: Cannot allocate memory [root@vm ~]# cat /proc/meminfo -bash: fork: Cannot allocate memory Fix it by properly adjusting the managed page count when migrating if the zone changed. The managed page count of the zones now looks after unplug of the DIMM (and after deflating the balloon) just like before inflating the balloon (and plugging+onlining the DIMM). We'll temporarily modify the totalram page count. If this ever becomes a problem, we can fine tune by providing helpers that don't touch the totalram pages (e.g., adjust_zone_managed_page_count()). Please note that fixing up the managed page count is only necessary when we adjusted the managed page count when inflating - only if we don't have VIRTIO_BALLOON_F_DEFLATE_ON_OOM. With that feature, the managed page count is not touched when inflating/deflating. Reported-by: Yumei Huang Fixes: 3dcc0571cd64 ("mm: correctly update zone->managed_pages") Cc: # v3.11+ Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Jiang Liu Cc: Andrew Morton Cc: Igor Mammedov Cc: virtualization@lists.linux-foundation.org Signed-off-by: David Hildenbrand Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 37b8438a6f49ab4d06a088dd55e5b09afa0d59ab Author: Miquel Raynal Date: Tue Oct 22 16:58:59 2019 +0200 mtd: spear_smi: Fix Write Burst mode commit 69c7f4618c16b4678f8a4949b6bb5ace259c0033 upstream. Any write with either dd or flashcp to a device driven by the spear_smi.c driver will pass through the spear_smi_cpy_toio() function. This function will get called for chunks of up to 256 bytes. If the amount of data is smaller, we may have a problem if the data length is not 4-byte aligned. In this situation, the kernel panics during the memcpy: # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6 spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256 spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256 spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256 spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233 Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8 [...] PC is at memcpy+0xcc/0x330 The above error occurs because the implementation of memcpy_toio() tries to optimize the number of I/O by writing 4 bytes at a time as much as possible, until there are less than 4 bytes left and then switches to word or byte writes. Unfortunately, the specification states about the Write Burst mode: "the next AHB Write request should point to the next incremented address and should have the same size (byte, half-word or word)" This means ARM architecture implementation of memcpy_toio() cannot reliably be used blindly here. Workaround this situation by update the write path to stick to byte access when the burst length is not multiple of 4. Fixes: f18dbbb1bfe0 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash") Cc: Russell King Cc: Boris Brezillon Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 2e0e2b4860ccef8dc8033648e79fdff0d6a93613 Author: Tadeusz Struk Date: Mon Oct 7 14:46:37 2019 -0700 tpm: add check after commands attribs tab allocation commit f1689114acc5e89a196fec6d732dae3e48edb6ad upstream. devm_kcalloc() can fail and return NULL so we need to check for that. Cc: stable@vger.kernel.org Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands") Signed-off-by: Tadeusz Struk Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 3757e3818838828f969ea51bea9b0e4ba948575e Author: Pete Zaitcev Date: Wed Dec 4 20:39:41 2019 -0600 usb: mon: Fix a deadlock in usbmon between mmap and read commit 19e6317d24c25ee737c65d1ffb7483bdda4bb54a upstream. The problem arises because our read() function grabs a lock of the circular buffer, finds something of interest, then invokes copy_to_user() straight from the buffer, which in turn takes mm->mmap_sem. In the same time, the callback mon_bin_vma_fault() is invoked under mm->mmap_sem. It attempts to take the fetch lock and deadlocks. This patch does away with protecting of our page list with any semaphores, and instead relies on the kernel not close the device while mmap is active in a process. In addition, we prohibit re-sizing of a buffer while mmap is active. This way, when (now unlocked) fault is processed, it works with the page that is intended to be mapped-in, and not some other random page. Note that this may have an ABI impact, but hopefully no legitimate program is this wrong. Signed-off-by: Pete Zaitcev Reported-by: syzbot+56f9673bb4cdcbeb0e92@syzkaller.appspotmail.com Reviewed-by: Alan Stern Fixes: 46eb14a6e158 ("USB: fix usbmon BUG trigger") Cc: Link: https://lore.kernel.org/r/20191204203941.3503452b@suzdal.zaitcev.lan Signed-off-by: Greg Kroah-Hartman commit cf6a2fbc065a13579b0084b32650f8b045689979 Author: Emiliano Ingrassia Date: Wed Nov 27 17:03:55 2019 +0100 usb: core: urb: fix URB structure initialization function commit 1cd17f7f0def31e3695501c4f86cd3faf8489840 upstream. Explicitly initialize URB structure urb_list field in usb_init_urb(). This field can be potentially accessed uninitialized and its initialization is coherent with the usage of list_del_init() in usb_hcd_unlink_urb_from_ep() and usb_giveback_urb_bh() and its explicit initialization in usb_hcd_submit_urb() error path. Signed-off-by: Emiliano Ingrassia Cc: stable Link: https://lore.kernel.org/r/20191127160355.GA27196@ingrassia.epigenesys.com Signed-off-by: Greg Kroah-Hartman commit 8ae04b7d94722219bafa6e3f97f160ff5b8e7cc3 Author: Johan Hovold Date: Tue Dec 10 12:25:59 2019 +0100 USB: adutux: fix interface sanity check commit 3c11c4bed02b202e278c0f5c319ae435d7fb9815 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 03270634e242 ("USB: Add ADU support for Ontrak ADU devices") Cc: stable # 2.6.19 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c3dde73859c11c068d015a75d1968edb6527e3de Author: Wen Yang Date: Sun Nov 24 22:22:36 2019 +0800 usb: roles: fix a potential use after free commit 1848a543191ae32e558bb0a5974ae7c38ebd86fc upstream. Free the sw structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. Fixes: 5c54fcac9a9d ("usb: roles: Take care of driver module reference counting") Signed-off-by: Wen Yang Reviewed-by: Heikki Krogerus Reviewed-by: Peter Chen Cc: stable Cc: Hans de Goede Cc: Chunfeng Yun Cc: Suzuki K Poulose Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124142236.25671-1-wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 3d1eef385869d53f027c7c23bb475b56e438c98e Author: Johan Hovold Date: Tue Dec 10 12:26:01 2019 +0100 USB: serial: io_edgeport: fix epic endpoint lookup commit 7c5a2df3367a2c4984f1300261345817d95b71f8 upstream. Make sure to use the current alternate setting when looking up the endpoints on epic devices to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Cc: stable # 2.6.21 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8e8212fee96c4972b7c10a1008c3c771bdc81277 Author: Johan Hovold Date: Tue Dec 10 12:26:00 2019 +0100 USB: idmouse: fix interface sanity checks commit 59920635b89d74b9207ea803d5e91498d39e8b69 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6cbf02876f673061d42c256219cb26d7aaaba16c Author: Johan Hovold Date: Tue Dec 10 12:25:58 2019 +0100 USB: atm: ueagle-atm: add missing endpoint check commit 09068c1ad53fb077bdac288869dec2435420bdc4 upstream. Make sure that the interrupt interface has an endpoint before trying to access its endpoint descriptors to avoid dereferencing a NULL pointer. The driver binds to the interrupt interface with interface number 0, but must not assume that this interface or its current alternate setting are the first entries in the corresponding configuration arrays. Fixes: b72458a80c75 ("[PATCH] USB: Eagle and ADI 930 usb adsl modem driver") Cc: stable # 2.6.16 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8b462a32692041e7006a5dae21f51341bf975977 Author: Jean-Baptiste Maneyrol Date: Tue Nov 26 17:19:12 2019 +0100 iio: imu: inv_mpu6050: fix temperature reporting using bad unit commit 53eaa9c27fdc01b4f4d885223e29f97393409e7e upstream. Temperature should be reported in milli-degrees, not degrees. Fix scale and offset values to use the correct unit. This is a fix for an issue that has been present for a long time. The fixes tag reflects the point at which the code last changed in a fashion that would make this fix patch no longer apply. Backports will be necessary to fix those elements that predate that patch. Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 299f9959676426a3df2bc10e0057608041be8c3b Author: Chris Lesiak Date: Thu Nov 21 20:39:42 2019 +0000 iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting commit 342a6928bd5017edbdae376042d8ad6af3d3b943 upstream. The IIO_HUMIDITYRELATIVE channel was being incorrectly reported back as percent when it should have been milli percent. This is via an incorrect scale value being returned to userspace. Signed-off-by: Chris Lesiak Acked-by: Matt Ranostay Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a12dd9edc778d5d568f1b63c025635c9f8eb7e33 Author: Nuno Sá Date: Mon Oct 28 17:33:49 2019 +0100 iio: adis16480: Add debugfs_reg_access entry commit 4c35b7a51e2f291471f7221d112c6a45c63e83bc upstream. The driver is defining debugfs entries by calling `adis16480_debugfs_init()`. However, those entries are attached to the iio_dev debugfs entry which won't exist if no debugfs_reg_access callback is provided. Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs") Signed-off-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 11cc8bb5ef206953da5bad8b94ec0a749647019b Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:36 2019 +0100 ARM: dts: pandora-common: define wl1251 as child node of mmc3 commit 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream. Since v4.7 the dma initialization requires that there is a device tree property for "rx" and "tx" channels which is not provided by the pdata-quirks initialization. By conversion of the mmc3 setup to device tree this will finally allows to remove the OpenPandora wlan specific omap3 data-quirks. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ Acked-by: Tony Lindgren Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ff01cf28a403b4c4c3d2081bb02bc821300513ec Author: Mathias Nyman Date: Wed Dec 11 16:20:06 2019 +0200 xhci: handle some XHCI_TRUST_TX_LENGTH quirks cases as default behaviour. commit 7ff11162808cc2ec66353fc012c58bb449c892c3 upstream. xhci driver claims it needs XHCI_TRUST_TX_LENGTH quirk for both Broadcom/Cavium and a Renesas xHC controllers. The quirk was inteded for handling false "success" complete event for transfers that had data left untransferred. These transfers should complete with "short packet" events instead. In these two new cases the false "success" completion is reported after a "short packet" if the TD consists of several TRBs. xHCI specs 4.10.1.1.2 say remaining TRBs should report "short packet" as well after the first short packet in a TD, but this issue seems so common it doesn't make sense to add the quirk for all vendors. Turn these events into short packets automatically instead. This gets rid of the "The WARN Successful completion on short TX for slot 1 ep 1: needs XHCI_TRUST_TX_LENGTH quirk" warning in many cases. Cc: Reported-by: Eli Billauer Reported-by: Ard Biesheuvel Tested-by: Eli Billauer Tested-by: Ard Biesheuvel Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5ce600f893ec04433aac2e84ba93bcc5fc266c96 Author: Kai-Heng Feng Date: Wed Dec 11 16:20:05 2019 +0200 xhci: Increase STS_HALT timeout in xhci_suspend() commit 7c67cf6658cec70d8a43229f2ce74ca1443dc95e upstream. I've recently observed failed xHCI suspend attempt on AMD Raven Ridge system: kernel: xhci_hcd 0000:04:00.4: WARN: xHC CMD_RUN timeout kernel: PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110 kernel: PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110 kernel: PM: Device 0000:04:00.4 failed to suspend async: error -110 Similar to commit ac343366846a ("xhci: Increase STS_SAVE timeout in xhci_suspend()") we also need to increase the HALT timeout to make it be able to suspend again. Cc: # 5.2+ Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ecbaf20e0f1cb20ea626a3f530fd7bdf1f289a8c Author: Mika Westerberg Date: Wed Dec 11 16:20:02 2019 +0200 xhci: Fix memory leak in xhci_add_in_port() commit ce91f1a43b37463f517155bdfbd525eb43adbd1a upstream. When xHCI is part of Alpine or Titan Ridge Thunderbolt controller and the xHCI device is hot-removed as a result of unplugging a dock for example, the driver leaks memory it allocates for xhci->usb3_rhub.psi and xhci->usb2_rhub.psi in xhci_add_in_port() as reported by kmemleak: unreferenced object 0xffff922c24ef42f0 (size 16): comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s) hex dump (first 16 bytes): 21 00 0c 00 12 00 dc 05 23 00 e0 01 00 00 00 00 !.......#....... backtrace: [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7 [<0000000001b6d775>] xhci_init+0x7c/0x160 [<00000000db443fe3>] xhci_gen_setup+0x214/0x340 [<00000000fdffd320>] xhci_pci_setup+0x48/0x110 [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747 [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4 [<0000000021043861>] xhci_pci_probe+0x24/0x1c0 [<00000000b9231f25>] local_pci_probe+0x3d/0x70 [<000000006385c9d7>] pci_device_probe+0xd0/0x150 [<0000000070241068>] really_probe+0xf5/0x3c0 [<0000000061f35c0a>] driver_probe_device+0x58/0x100 [<000000009da11198>] bus_for_each_drv+0x79/0xc0 [<000000009ce45f69>] __device_attach+0xda/0x160 [<00000000df201aaf>] pci_bus_add_device+0x46/0x70 [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60 [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60 unreferenced object 0xffff922c24ef3318 (size 8): comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s) hex dump (first 8 bytes): 34 01 05 00 35 41 0a 00 4...5A.. backtrace: [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7 [<0000000001b6d775>] xhci_init+0x7c/0x160 [<00000000db443fe3>] xhci_gen_setup+0x214/0x340 [<00000000fdffd320>] xhci_pci_setup+0x48/0x110 [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747 [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4 [<0000000021043861>] xhci_pci_probe+0x24/0x1c0 [<00000000b9231f25>] local_pci_probe+0x3d/0x70 [<000000006385c9d7>] pci_device_probe+0xd0/0x150 [<0000000070241068>] really_probe+0xf5/0x3c0 [<0000000061f35c0a>] driver_probe_device+0x58/0x100 [<000000009da11198>] bus_for_each_drv+0x79/0xc0 [<000000009ce45f69>] __device_attach+0xda/0x160 [<00000000df201aaf>] pci_bus_add_device+0x46/0x70 [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60 [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60 Fix this by calling kfree() for the both psi objects in xhci_mem_cleanup(). Cc: # 4.4+ Fixes: 47189098f8be ("xhci: parse xhci protocol speed ID list for usb 3.1 usage") Signed-off-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2f23dc86c3f801bce35e0d20606839ac4d2e72fc Author: Henry Lin Date: Wed Dec 11 16:20:04 2019 +0200 usb: xhci: only set D3hot for pci device commit f2c710f7dca8457e88b4ac9de2060f011254f9dd upstream. Xhci driver cannot call pci_set_power_state() on non-pci xhci host controllers. For example, NVIDIA Tegra XHCI host controller which acts as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform hits this issue during shutdown. Cc: Fixes: 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") Signed-off-by: Henry Lin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b48f19d74f82861378de1c68f9291742cfc853a1 Author: Johan Hovold Date: Mon Dec 2 09:56:10 2019 +0100 staging: gigaset: add endpoint-type sanity check commit ed9ed5a89acba51b82bdff61144d4e4a4245ec8a upstream. Add missing endpoint-type sanity checks to probe. This specifically prevents a warning in USB core on URB submission when fuzzing USB descriptors. Signed-off-by: Johan Hovold Cc: stable Link: https://lore.kernel.org/r/20191202085610.12719-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0f5e357b8ff40103a9bbb018176c3bd8ba3abfb6 Author: Johan Hovold Date: Mon Dec 2 09:56:09 2019 +0100 staging: gigaset: fix illegal free on probe errors commit 84f60ca7b326ed8c08582417493982fe2573a9ad upstream. The driver failed to initialise its receive-buffer pointer, something which could lead to an illegal free on late probe errors. Fix this by making sure to clear all driver data at allocation. Fixes: 2032e2c2309d ("usb_gigaset: code cleanup") Cc: stable # 2.6.33 Cc: Tilman Schmidt Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191202085610.12719-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit a5778b88c76da9647e8d53e45822cd885e8e91c1 Author: Johan Hovold Date: Mon Dec 2 09:56:08 2019 +0100 staging: gigaset: fix general protection fault on probe commit 53f35a39c3860baac1e5ca80bf052751cfb24a99 upstream. Fix a general protection fault when accessing the endpoint descriptors which could be triggered by a malicious device due to missing sanity checks on the number of endpoints. Reported-by: syzbot+35b1c403a14f5c89eba7@syzkaller.appspotmail.com Fixes: 07dc1f9f2f80 ("[PATCH] isdn4linux: Siemens Gigaset drivers - M105 USB DECT adapter") Cc: stable # 2.6.17 Cc: Hansjoerg Lipp Cc: Tilman Schmidt Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191202085610.12719-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ecf75f293521427a8b09f01a8efc1538a24dab06 Author: Johan Hovold Date: Tue Dec 10 12:47:51 2019 +0100 staging: rtl8712: fix interface sanity check commit c724f776f048538ecfdf53a52b7a522309f5c504 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Cc: stable # 2.6.37 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210114751.5119-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit bfa71d73ac9f42f881a5b11d14ebed5e9205f786 Author: Johan Hovold Date: Tue Dec 10 12:47:50 2019 +0100 staging: rtl8188eu: fix interface sanity check commit 74ca34118a0e05793935d804ccffcedd6eb56596 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: c2478d39076b ("staging: r8188eu: Add files for new driver - part 20") Cc: stable # 3.12 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210114751.5119-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ae14443c5bce87cb386ccf9f84cbf8d90a2f9b05 Author: Kai-Heng Feng Date: Wed Nov 6 14:27:10 2019 +0800 usb: Allow USB device to be warm reset in suspended state commit e76b3bf7654c3c94554c24ba15a3d105f4006c80 upstream. On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging cable to the ethernet port, the hub and roothub get runtime resumed and runtime suspended immediately: ... [ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.315204] usb usb4: usb auto-resume [ 433.315226] hub 4-0:1.0: hub_resume [ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343 [ 433.315264] usb usb4-port1: status 0343 change 0001 [ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2 [ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0 [ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422307] usb usb4-port1: do warm reset [ 433.422311] usb 4-1: device reset not allowed in state 8 [ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000 [ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422356] usb usb4-port1: do warm reset [ 433.422358] usb 4-1: device reset not allowed in state 8 [ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2 [ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0 [ 433.422465] hub 4-0:1.0: hub_suspend [ 433.422475] usb usb4: bus auto-suspend, wakeup 1 [ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling. [ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0 [ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled [ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20) [ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403) [ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled [ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering [ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt! [ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2 [ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub [ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling. [ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling. [ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.902919] usb usb4: usb wakeup-resume [ 433.902942] usb usb4: usb auto-resume [ 433.902966] hub 4-0:1.0: hub_resume ... As Mathias pointed out, the hub enters Cold Attach Status state and requires a warm reset. However usb_reset_device() bails out early when the device is in suspended state, as its callers port_event() and hub_event() don't always resume the device. Since there's nothing wrong to reset a suspended device, allow usb_reset_device() to do so to solve the issue. Signed-off-by: Kai-Heng Feng Acked-by: Alan Stern Cc: stable Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman commit 9e002edde3c1aeff87acd313c9a0fd192f3b7e3f Author: Oliver Neukum Date: Thu Nov 14 12:27:58 2019 +0100 USB: documentation: flags on usb-storage versus UAS commit 65cc8bf99349f651a0a2cee69333525fe581f306 upstream. Document which flags work storage, UAS or both Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-4-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 0c7149e2191958332a0dcd91f84676f0c9a518fc Author: Oliver Neukum Date: Thu Nov 14 12:27:57 2019 +0100 USB: uas: heed CAPACITY_HEURISTICS commit 335cbbd5762d5e5c67a8ddd6e6362c2aa42a328f upstream. There is no need to ignore this flag. We should be as close to storage in that regard as makes sense, so honor flags whose cost is tiny. Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-3-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 0b495fa36eec75f8c60c6522bd91dfc06d55b59e Author: Oliver Neukum Date: Thu Nov 14 12:27:56 2019 +0100 USB: uas: honor flag to avoid CAPACITY16 commit bff000cae1eec750d62e265c4ba2db9af57b17e1 upstream. Copy the support over from usb-storage to get feature parity Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit de5fb1872af9073e3a9001d1e5d243bd39aa23a2 Author: Arnd Bergmann Date: Wed Nov 6 10:06:54 2019 +0100 media: venus: remove invalid compat_ioctl32 handler commit 4adc0423de92cf850d1ef5c0e7cb28fd7a38219e upstream. v4l2_compat_ioctl32() is the function that calls into v4l2_file_operations->compat_ioctl32(), so setting that back to the same function leads to a trivial endless loop, followed by a kernel stack overrun. Remove the incorrect assignment. Cc: stable@vger.kernel.org Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files") Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files") Signed-off-by: Arnd Bergmann Acked-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 42dadb842d752979185cf47925dae439390ddc6c Author: Quinn Tran Date: Tue Nov 5 07:06:53 2019 -0800 scsi: qla2xxx: Fix driver unload hang commit dd322b7f3efc8cda085bb60eadc4aee6324eadd8 upstream. This patch fixes driver unload hang by removing msleep() Fixes: d74595278f4ab ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191105150657.8092-5-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f831f6b8db4ad1757c64969d1f044309eca0d37f Author: Gustavo A. R. Silva Date: Wed Nov 6 14:28:21 2019 -0600 usb: gadget: pch_udc: fix use after free commit 66d1b0c0580b7f1b1850ee4423f32ac42afa2e92 upstream. Remove pointer dereference after free. pci_pool_free doesn't care about contents of td. It's just a void* for it Addresses-Coverity-ID: 1091173 ("Use after free") Cc: stable@vger.kernel.org Acked-by: Michal Nazarewicz Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20191106202821.GA20347@embeddedor Signed-off-by: Greg Kroah-Hartman commit 2a030dbece27562a044188d2e6960cf080ac2760 Author: Wei Yongjun Date: Wed Oct 30 03:40:46 2019 +0000 usb: gadget: configfs: Fix missing spin_lock_init() commit 093edc2baad2c258b1f55d1ab9c63c2b5ae67e42 upstream. The driver allocates the spinlock but not initialize it. Use spin_lock_init() on it to initialize it correctly. This is detected by Coccinelle semantic patch. Fixes: 1a1c851bbd70 ("usb: gadget: configfs: fix concurrent issue between composite APIs") Signed-off-by: Wei Yongjun Cc: stable Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20191030034046.188808-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman commit e71c1f62be9c3f060b6ff7d8345a8b5d1806121f Author: Steven Rostedt (VMware) Date: Fri Dec 13 20:24:55 2019 -0500 Linux 4.19.87-rt33 commit 9b0b6ae996fd9f3ab54badf2f3a74bee2026bea2 Merge: 7ed90a716772 174651bdf802 Author: Steven Rostedt (VMware) Date: Fri Dec 13 20:24:35 2019 -0500 Merge tag 'v4.19.87' into v4.19-rt This is the 4.19.87 stable release Conflicts: kernel/printk/printk.c commit 7ed90a7167723ef383fc9e9c3660b7562be72421 Author: Steven Rostedt (VMware) Date: Fri Dec 13 19:50:39 2019 -0500 Linux 4.19.86-rt32 commit 910f09985ff96b5c17f28d41d42ef5de772e2d6d Merge: b6b27cc3ed9a 14260788bbb9 Author: Steven Rostedt (VMware) Date: Fri Dec 13 19:50:17 2019 -0500 Merge tag 'v4.19.86' into v4.19-rt This is the 4.19.86 stable release Conflicts: fs/nfs/delegation.c commit b6b27cc3ed9a5303be1038f3ce45630cd29ba5a3 Author: Steven Rostedt (VMware) Date: Fri Dec 13 18:44:30 2019 -0500 Linux 4.19.84-rt31 commit 9336b96d0c4b99ecdd702ac0823eca00bb048b4c Merge: 0e315bfd29ec c555efaf1402 Author: Steven Rostedt (VMware) Date: Fri Dec 13 18:36:35 2019 -0500 Merge tag 'v4.19.84' into v4.19-rt This is the 4.19.84 stable release Conflicts: kernel/sched/fair.c commit 312017a460d5ea31d646e7148e400e13db799ddc Author: Greg Kroah-Hartman Date: Fri Dec 13 08:52:59 2019 +0100 Linux 4.19.89 commit b136eeb65de081668061c35f70e95309e97a54cf Author: YueHaibing Date: Tue Apr 30 19:34:08 2019 +0800 appletalk: Set error code if register_snap_client failed commit c93ad1337ad06a718890a89cdd85188ff9a5a5cc upstream. If register_snap_client fails in atalk_init, error code should be set, otherwise it will triggers NULL pointer dereference while unloading module. Fixes: 9804501fa122 ("appletalk: Fix potential NULL pointer dereference in unregister_snap_client") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0977763a13fd87a7aebe376dc96385758de3aa9e Author: YueHaibing Date: Thu Mar 14 13:47:59 2019 +0800 appletalk: Fix potential NULL pointer dereference in unregister_snap_client commit 9804501fa1228048857910a6bf23e085aade37cc upstream. register_snap_client may return NULL, all the callers check it, but only print a warning. This will result in NULL pointer dereference in unregister_snap_client and other places. It has always been used like this since v2.6 Reported-by: Dan Carpenter Signed-off-by: YueHaibing Signed-off-by: David S. Miller Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 754e3c0c31c96cf3a4a54ed2a8c63cca28109136 Author: Navid Emamdoost Date: Wed Sep 11 10:09:02 2019 -0500 net: qrtr: fix memort leak in qrtr_tun_write_iter commit a21b7f0cff1906a93a0130b74713b15a0b36481d upstream. In qrtr_tun_write_iter the allocated kbuf should be release in case of error or success return. v2 Update: Thanks to David Miller for pointing out the release on success path as well. Signed-off-by: Navid Emamdoost Signed-off-by: David S. Miller Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 5119ffd480b644d8bc9af741cc8ef435a7ec5ff7 Author: Paolo Bonzini Date: Wed Dec 4 10:28:54 2019 +0100 KVM: x86: fix out-of-bounds write in KVM_GET_EMULATED_CPUID (CVE-2019-19332) commit 433f4ba1904100da65a311033f17a9bf586b287e upstream. The bounds check was present in KVM_GET_SUPPORTED_CPUID but not KVM_GET_EMULATED_CPUID. Reported-by: syzbot+e3f4897236c4eeb8af4f@syzkaller.appspotmail.com Fixes: 84cffe499b94 ("kvm: Emulate MOVBE", 2013-10-29) Signed-off-by: Paolo Bonzini Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 9852d0c67678dd5f8ade26c15f80ae0b9e565962 Author: Kuninori Morimoto Date: Fri Feb 1 16:49:30 2019 +0900 ASoC: rsnd: fixup MIX kctrl registration commit 7aea8a9d71d54f449f49e20324df06341cc18395 upstream. Renesas sound device has many IPs and many situations. If platform/board uses MIXer, situation will be more complex. To avoid duplicate DVC kctrl registration when MIXer was used, it had original flags. But it was issue when sound card was re-binded, because no one can't cleanup this flags then. To solve this issue, commit 9c698e8481a15237a ("ASoC: rsnd: tidyup registering method for rsnd_kctrl_new()") checks registered card->controls, because if card was re-binded, these were cleanuped automatically. This patch could solve re-binding issue. But, it start to avoid MIX kctrl. To solve these issues, we need below. To avoid card re-binding issue: check registered card->controls To avoid duplicate DVC registration: check registered rsnd_kctrl_cfg To allow multiple MIX registration: check registered rsnd_kctrl_cfg This patch do it. Fixes: 9c698e8481a15237a ("ASoC: rsnd: tidyup registering method for rsnd_kctrl_new()") Reported-by: Jiada Wang Signed-off-by: Kuninori Morimoto Tested-By: Jiada Wang Signed-off-by: Mark Brown Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 17559e35fc97b62d4a2b4f7f0893bd3394358f23 Author: Brian Foster Date: Fri Apr 26 07:30:24 2019 -0700 xfs: add missing error check in xfs_prepare_shift() commit 1749d1ea89bdf3181328b7d846e609d5a0e53e50 upstream. xfs_prepare_shift() fails to check the error return from xfs_flush_unmap_range(). If the latter fails, that could lead to an insert/collapse range operation over a delalloc range, which is not supported. Add an error check and return appropriately. This is reproduced rarely by generic/475. Fixes: 7f9f71be84bc ("xfs: extent shifting doesn't fully invalidate page cache") Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Allison Collins Reviewed-by: Dave Chinner Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 4c67dbea4d2b335634ab37daa148dca8e0e18555 Author: Darrick J. Wong Date: Sun Dec 2 08:38:07 2018 -0800 iomap: partially revert 4721a601099 (simulated directio short read on EFAULT) [ Upstream commit 8f67b5adc030553fbc877124306f3f3bdab89aa8 ] In commit 4721a601099, we tried to fix a problem wherein directio reads into a splice pipe will bounce EFAULT/EAGAIN all the way out to userspace by simulating a zero-byte short read. This happens because some directio read implementations (xfs) will call bio_iov_iter_get_pages to grab pipe buffer pages and issue asynchronous reads, but as soon as we run out of pipe buffers that _get_pages call returns EFAULT, which the splice code translates to EAGAIN and bounces out to userspace. In that commit, the iomap code catches the EFAULT and simulates a zero-byte read, but that causes assertion errors on regular splice reads because xfs doesn't allow short directio reads. This causes infinite splice() loops and assertion failures on generic/095 on overlayfs because xfs only permit total success or total failure of a directio operation. The underlying issue in the pipe splice code has now been fixed by changing the pipe splice loop to avoid avoid reading more data than there is space in the pipe. Therefore, it's no longer necessary to simulate the short directio, so remove the hack from iomap. Fixes: 4721a601099 ("iomap: dio data corruption and spurious errors when pipes fill") Reported-by: Murphy Zhou Ranted-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 019b63253f8651ed305683368d3ddfe56082dcac Author: Darrick J. Wong Date: Fri Nov 30 10:37:49 2018 -0800 splice: don't read more than available pipe space [ Upstream commit 17614445576b6af24e9cf36607c6448164719c96 ] In commit 4721a601099, we tried to fix a problem wherein directio reads into a splice pipe will bounce EFAULT/EAGAIN all the way out to userspace by simulating a zero-byte short read. This happens because some directio read implementations (xfs) will call bio_iov_iter_get_pages to grab pipe buffer pages and issue asynchronous reads, but as soon as we run out of pipe buffers that _get_pages call returns EFAULT, which the splice code translates to EAGAIN and bounces out to userspace. In that commit, the iomap code catches the EFAULT and simulates a zero-byte read, but that causes assertion errors on regular splice reads because xfs doesn't allow short directio reads. The brokenness is compounded by splice_direct_to_actor immediately bailing on do_splice_to returning <= 0 without ever calling ->actor (which empties out the pipe), so if userspace calls back we'll EFAULT again on the full pipe, and nothing ever gets copied. Therefore, teach splice_direct_to_actor to clamp its requests to the amount of free space in the pipe and remove the simulated short read from the iomap directio code. Fixes: 4721a601099 ("iomap: dio data corruption and spurious errors when pipes fill") Reported-by: Murphy Zhou Ranted-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 484c4d9a9cce1fc457ed45b597672c822857b037 Author: Adrian Hunter Date: Wed Nov 27 11:56:31 2019 +0200 perf script: Fix invalid LBR/binary mismatch error [ Upstream commit 5172672da02e483d9b3c4d814c3482d0c8ffb1a6 ] The 'len' returned by grab_bb() includes an extra MAXINSN bytes to allow for the last instruction, so the the final 'offs' will not be 'len'. Fix the error condition logic accordingly. Before: $ perf record -e '{intel_pt//,cpu/mem_inst_retired.all_loads,aux-sample-size=8192/pp}:u' grep -rqs jhgjhg /boot [ perf record: Woken up 19 times to write data ] [ perf record: Captured and wrote 2.274 MB perf.data ] $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head grep 13759 [002] 8091.310257: 1862 instructions:uH: 5641d58069eb bmexec+0x86b (/bin/grep) bmexec+2485: 00005641d5806b35 jnz 0x5641d5806bd0 # MISPRED 00005641d5806bd0 movzxb (%r13,%rdx,1), %eax 00005641d5806bd6 add %rdi, %rax 00005641d5806bd9 movzxb -0x1(%rax), %edx 00005641d5806bdd cmp %rax, %r14 00005641d5806be0 jnb 0x5641d58069c0 # MISPRED mismatch of LBR data and executable 00005641d58069c0 movzxb (%r13,%rdx,1), %edi After: $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head grep 13759 [002] 8091.310257: 1862 instructions:uH: 5641d58069eb bmexec+0x86b (/bin/grep) bmexec+2485: 00005641d5806b35 jnz 0x5641d5806bd0 # MISPRED 00005641d5806bd0 movzxb (%r13,%rdx,1), %eax 00005641d5806bd6 add %rdi, %rax 00005641d5806bd9 movzxb -0x1(%rax), %edx 00005641d5806bdd cmp %rax, %r14 00005641d5806be0 jnb 0x5641d58069c0 # MISPRED 00005641d58069c0 movzxb (%r13,%rdx,1), %edi 00005641d58069c6 add %rax, %rdi Fixes: e98df280bc2a ("perf script brstackinsn: Fix recovery from LBR/binary mismatch") Reported-by: Andi Kleen Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20191127095631.15663-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5cdbe243008392b324ee77e19e7e2961dda3d931 Author: Joel Stanley Date: Fri Nov 8 13:59:05 2019 +1030 watchdog: aspeed: Fix clock behaviour for ast2600 [ Upstream commit c04571251b3d842096f1597f5d4badb508be016d ] The ast2600 no longer uses bit 4 in the control register to indicate a 1MHz clock (It now controls whether this watchdog is reset by a SOC reset). This means we do not want to set it. It also does not need to be set for the ast2500, as it is read-only on that SoC. The comment next to the clock rate selection wandered away from where it was set, so put it back next to the register setting it's describing. Fixes: b3528b487448 ("watchdog: aspeed: Add support for AST2600") Signed-off-by: Joel Stanley Reviewed-by: Cédric Le Goater Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20191108032905.22463-1-joel@jms.id.au Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 23c81ea6b13647abbf218e50de9b5bdda2de7863 Author: Dan Carpenter Date: Sat Sep 21 09:00:31 2019 +0300 md/raid0: Fix an error message in raid0_make_request() [ Upstream commit e3fc3f3d0943b126f76b8533960e4168412d9e5a ] The first argument to WARN() is supposed to be a condition. The original code will just print the mdname() instead of the full warning message. Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.") Signed-off-by: Dan Carpenter Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit ba2247f90d8dd10e35080886255a2a5244d45bed Author: Takashi Iwai Date: Mon Oct 28 11:58:03 2019 +0100 ALSA: hda - Fix pending unsol events at shutdown [ Upstream commit ca58f55108fee41d87c9123f85ad4863e5de7f45 ] This is an alternative fix attemp for the issue reported in the commit caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") that was reverted later due to regressions. Instead of tweaking the hardware disablement order and the enforced irq flushing, do calling cancel_work_sync() of the unsol work early enough, and explicitly ignore the unsol events during the shutdown by checking the bus->shutdown flag. Fixes: caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") Cc: Chris Wilson Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit af0174a63c45bd25c7fd7ece5f93e5f166256d1c Author: Jann Horn Date: Fri Oct 18 22:56:31 2019 +0200 binder: Handle start==NULL in binder_update_page_range() commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream. The old loop wouldn't stop when reaching `start` if `start==NULL`, instead continuing backwards to index -1 and crashing. Luckily you need to be highly privileged to map things at NULL, so it's not a big problem. Fix it by adjusting the loop so that the loop variable is always in bounds. This patch is deliberately minimal to simplify backporting, but IMO this function could use a refactor. The jump labels in the second loop body are horrible (the error gotos should be jumping to free_range instead), and both loops would look nicer if they just iterated upwards through indices. And the up_read()+mmput() shouldn't be duplicated like that. Cc: stable@vger.kernel.org Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Signed-off-by: Jann Horn Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit fe0d31eddb9e6404dc1847648e388953e194557c Author: Jann Horn Date: Fri Oct 18 22:56:29 2019 +0200 binder: Fix race between mmap() and binder_alloc_print_pages() commit 8eb52a1ee37aafd9b796713aa0b3ab9cbc455be3 upstream. binder_alloc_print_pages() iterates over alloc->pages[0..alloc->buffer_size-1] under alloc->mutex. binder_alloc_mmap_handler() writes alloc->pages and alloc->buffer_size without holding that lock, and even writes them before the last bailout point. Unfortunately we can't take the alloc->mutex in the ->mmap() handler because mmap_sem can be taken while alloc->mutex is held. So instead, we have to locklessly check whether the binder_alloc has been fully initialized with binder_alloc_get_vma(), like in binder_alloc_new_buf_locked(). Fixes: 8ef4665aa129 ("android: binder: Add page usage in binder stats") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20191018205631.248274-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 627f3b9e4dd812dac9d93e578af80de751e704a4 Author: Nicolas Pitre Date: Tue Nov 5 10:33:16 2019 +0100 vcs: prevent write access to vcsu devices commit 0c9acb1af77a3cb8707e43f45b72c95266903cee upstream. Commit d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") guarded against using devices containing attributes as this is not yet implemented. It however failed to guard against writes to any devices as this is also unimplemented. Reported-by: Or Cohen Signed-off-by: Nicolas Pitre Cc: # v4.19+ Cc: Jiri Slaby Fixes: d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1911051030580.30289@knanqh.ubzr Signed-off-by: Greg Kroah-Hartman commit fe46db764fb1a55caf2a87932414da7edb868ff1 Author: Wei Wang Date: Tue Nov 12 12:42:23 2019 -0800 thermal: Fix deadlock in thermal thermal_zone_device_check commit 163b00cde7cf2206e248789d2780121ad5e6a70b upstream. 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device") changed cancel_delayed_work to cancel_delayed_work_sync to avoid a use-after-free issue. However, cancel_delayed_work_sync could be called insides the WQ causing deadlock. [54109.642398] c0 1162 kworker/u17:1 D 0 11030 2 0x00000000 [54109.642437] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check [54109.642447] c0 1162 Call trace: [54109.642456] c0 1162 __switch_to+0x138/0x158 [54109.642467] c0 1162 __schedule+0xba4/0x1434 [54109.642480] c0 1162 schedule_timeout+0xa0/0xb28 [54109.642492] c0 1162 wait_for_common+0x138/0x2e8 [54109.642511] c0 1162 flush_work+0x348/0x40c [54109.642522] c0 1162 __cancel_work_timer+0x180/0x218 [54109.642544] c0 1162 handle_thermal_trip+0x2c4/0x5a4 [54109.642553] c0 1162 thermal_zone_device_update+0x1b4/0x25c [54109.642563] c0 1162 thermal_zone_device_check+0x18/0x24 [54109.642574] c0 1162 process_one_work+0x3cc/0x69c [54109.642583] c0 1162 worker_thread+0x49c/0x7c0 [54109.642593] c0 1162 kthread+0x17c/0x1b0 [54109.642602] c0 1162 ret_from_fork+0x10/0x18 [54109.643051] c0 1162 kworker/u17:2 D 0 16245 2 0x00000000 [54109.643067] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check [54109.643077] c0 1162 Call trace: [54109.643085] c0 1162 __switch_to+0x138/0x158 [54109.643095] c0 1162 __schedule+0xba4/0x1434 [54109.643104] c0 1162 schedule_timeout+0xa0/0xb28 [54109.643114] c0 1162 wait_for_common+0x138/0x2e8 [54109.643122] c0 1162 flush_work+0x348/0x40c [54109.643131] c0 1162 __cancel_work_timer+0x180/0x218 [54109.643141] c0 1162 handle_thermal_trip+0x2c4/0x5a4 [54109.643150] c0 1162 thermal_zone_device_update+0x1b4/0x25c [54109.643159] c0 1162 thermal_zone_device_check+0x18/0x24 [54109.643167] c0 1162 process_one_work+0x3cc/0x69c [54109.643177] c0 1162 worker_thread+0x49c/0x7c0 [54109.643186] c0 1162 kthread+0x17c/0x1b0 [54109.643195] c0 1162 ret_from_fork+0x10/0x18 [54109.644500] c0 1162 cat D 0 7766 1 0x00000001 [54109.644515] c0 1162 Call trace: [54109.644524] c0 1162 __switch_to+0x138/0x158 [54109.644536] c0 1162 __schedule+0xba4/0x1434 [54109.644546] c0 1162 schedule_preempt_disabled+0x80/0xb0 [54109.644555] c0 1162 __mutex_lock+0x3a8/0x7f0 [54109.644563] c0 1162 __mutex_lock_slowpath+0x14/0x20 [54109.644575] c0 1162 thermal_zone_get_temp+0x84/0x360 [54109.644586] c0 1162 temp_show+0x30/0x78 [54109.644609] c0 1162 dev_attr_show+0x5c/0xf0 [54109.644628] c0 1162 sysfs_kf_seq_show+0xcc/0x1a4 [54109.644636] c0 1162 kernfs_seq_show+0x48/0x88 [54109.644656] c0 1162 seq_read+0x1f4/0x73c [54109.644664] c0 1162 kernfs_fop_read+0x84/0x318 [54109.644683] c0 1162 __vfs_read+0x50/0x1bc [54109.644692] c0 1162 vfs_read+0xa4/0x140 [54109.644701] c0 1162 SyS_read+0xbc/0x144 [54109.644708] c0 1162 el0_svc_naked+0x34/0x38 [54109.845800] c0 1162 D 720.000s 1->7766->7766 cat [panic] Fixes: 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device") Cc: stable@vger.kernel.org Signed-off-by: Wei Wang Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit b59116ffe8a63edc394a723077272bd4ba876401 Author: Jan Kara Date: Thu Nov 21 16:14:38 2019 -0800 iomap: Fix pipe page leakage during splicing commit 419e9c38aa075ed0cd3c13d47e15954b686bcdb6 upstream. When splicing using iomap_dio_rw() to a pipe, we may leak pipe pages because bio_iov_iter_get_pages() records that the pipe will have full extent worth of data however if file size is not block size aligned iomap_dio_rw() returns less than what bio_iov_iter_get_pages() set up and splice code gets confused leaking a pipe page with the file tail. Handle the situation similarly to the old direct IO implementation and revert iter to actually returned read amount which makes iter consistent with value returned from iomap_dio_rw() and thus the splice code is happy. Fixes: ff6a9292e6f6 ("iomap: implement direct I/O") CC: stable@vger.kernel.org Reported-by: syzbot+991400e8eba7e00a26e1@syzkaller.appspotmail.com Signed-off-by: Jan Kara Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 18a236223bb7c9a5234d2e52a2fc1a021041104c Author: Viresh Kumar Date: Thu Nov 7 08:50:25 2019 +0530 RDMA/qib: Validate ->show()/store() callbacks before calling them commit 7ee23491b39259ae83899dd93b2a29ef0f22f0a7 upstream. The permissions of the read-only or write-only sysfs files can be changed (as root) and the user can then try to read a write-only file or write to a read-only file which will lead to kernel crash here. Protect against that by always validating the show/store callbacks. Link: https://lore.kernel.org/r/d45cc26361a174ae12dbb86c994ef334d257924b.1573096807.git.viresh.kumar@linaro.org Signed-off-by: Viresh Kumar Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 42bd3e78afd00f60002001c56fb3700aa5050004 Author: Johan Hovold Date: Thu Nov 28 19:26:03 2019 +0100 can: ucan: fix non-atomic allocation in completion handler commit 870db5d1015c8bd63e93b579e857223c96249ff7 upstream. USB completion handlers are called in atomic context and must specifically not allocate memory using GFP_KERNEL. Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Cc: stable # 4.19 Cc: Jakob Unterwurzacher Cc: Martin Elshuber Cc: Philipp Tomsich Signed-off-by: Johan Hovold Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 59101399e156104b31373c83a715284f7a919a95 Author: Sharvari Harisangam Date: Wed Jun 12 20:42:11 2019 +0530 mwifiex: update set_mac_address logic commit 7afb94da3cd8a28ed7ae268143117bf1ac8a3371 upstream. In set_mac_address, driver check for interfaces with same bss_type For first STA entry, this would return 3 interfaces since all priv's have bss_type as 0 due to kzalloc. Thus mac address gets changed for STA unexpected. This patch adds check for first STA and avoids mac address change. This patch also adds mac_address change for p2p based on bss_num type. Signed-off-by: Sharvari Harisangam Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo Cc: Brian Norris Signed-off-by: Greg Kroah-Hartman commit a1371a6113a99fd625d207f9f90cc2063ce0d20c Author: Gregory CLEMENT Date: Thu Oct 17 16:18:41 2019 +0200 spi: atmel: Fix CS high support commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream. Until a few years ago, this driver was only used with CS GPIO. The only exception is CS0 on AT91RM9200 which has to use internal CS. A limitation of the internal CS is that they don't support CS High. So by using the CS GPIO the CS high configuration was available except for the particular case CS0 on RM9200. When the support for the internal chip-select was added, the check of the CS high support was not updated. Due to this the driver accepts this configuration for all the SPI controller v2 (used by all SoCs excepting the AT91RM9200) whereas the hardware doesn't support it for infernal CS. This patch fixes the test to match the hardware capabilities. Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller") Cc: Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 351a567ebf2482de4dd5e5bbd539f2175540b717 Author: Navid Emamdoost Date: Fri Oct 4 14:29:16 2019 -0500 crypto: user - fix memory leak in crypto_report commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream. In crypto_report, a new skb is created via nlmsg_new(). This skb should be released if crypto_report_alg() fails. Fixes: a38f7907b926 ("crypto: Add userspace configuration API") Cc: Signed-off-by: Navid Emamdoost Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cdaeaea6aa1bc6de2974c9058ed98dac59209d5b Author: Ard Biesheuvel Date: Wed Oct 23 11:50:44 2019 +0200 crypto: ecdh - fix big endian bug in ECC library commit f398243e9fd6a3a059c1ea7b380c40628dbf0c61 upstream. The elliptic curve arithmetic library used by the EC-DH KPP implementation assumes big endian byte order, and unconditionally reverses the byte and word order of multi-limb quantities. On big endian systems, the byte reordering is not necessary, while the word ordering needs to be retained. So replace the __swab64() invocation with a call to be64_to_cpu() which should do the right thing for both little and big endian builds. Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") Cc: # v4.9+ Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit be7993dd8e8ce27f0f66b5079de8fe7219a6883e Author: Mark Salter Date: Mon Oct 21 11:29:49 2019 -0400 crypto: ccp - fix uninitialized list head commit 691505a803a7f223b2af621848d581259c61f77d upstream. A NULL-pointer dereference was reported in fedora bz#1762199 while reshaping a raid6 array after adding a fifth drive to an existing array. [ 47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2 [ 47.804017] md0: detected capacity change from 0 to 7885289422848 [ 47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000 ... [ 47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G W 5.2.18-200.fc30.aarch64 #1 [ 47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016 [ 47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO) [ 47.963668] pc : __list_del_entry_valid+0x2c/0xa8 [ 47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp] [ 47.972882] sp : ffff00001369b970 [ 47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8 [ 47.981483] x27: 00000000ffffffff x26: ffff8003b758af70 [ 47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818 [ 47.992080] x23: 0000000000000000 x22: ffff8003e62450c0 [ 47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003 [ 48.002678] x19: ffff8003e6245100 x18: 0000000000000000 [ 48.007976] x17: 0000000000000000 x16: 0000000000000000 [ 48.013274] x15: 0000000000000000 x14: 0000000000000000 [ 48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001 [ 48.023870] x11: ffff000010eff998 x10: 00000000000019a0 [ 48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180 [ 48.034467] x7 : 0000000000000000 x6 : 000000000000003f [ 48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080 [ 48.045064] x3 : dead000000000200 x2 : 0000000000000000 [ 48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0 [ 48.055660] Call trace: [ 48.058095] __list_del_entry_valid+0x2c/0xa8 [ 48.062442] ccp_tx_submit+0x84/0x168 [ccp] [ 48.066615] async_tx_submit+0x224/0x368 [async_tx] [ 48.071480] async_trigger_callback+0x68/0xfc [async_tx] [ 48.076784] ops_run_biofill+0x178/0x1e8 [raid456] [ 48.081566] raid_run_ops+0x248/0x818 [raid456] [ 48.086086] handle_stripe+0x864/0x1208 [raid456] [ 48.090781] handle_active_stripes.isra.0+0xb0/0x278 [raid456] [ 48.096604] raid5d+0x378/0x618 [raid456] [ 48.100602] md_thread+0xa0/0x150 [ 48.103905] kthread+0x104/0x130 [ 48.107122] ret_from_fork+0x10/0x18 [ 48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021) [ 48.116766] ---[ end trace 23f390a527f7ad77 ]--- ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in a ccp_dma_desc and adds it to a ccp channel's pending list: list_del(&desc->entry); list_add_tail(&desc->entry, &chan->pending); The problem is that desc->entry may be uninitialized in the async_trigger_callback path where the descriptor was gotten from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc which doesn't initialize the desc->entry list head. So, just initialize the list head to avoid the problem. Cc: Reported-by: Sahaj Sarup Signed-off-by: Mark Salter Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit dac11877298e3264d1e59656a0907d77404e49ef Author: Ayush Sawal Date: Fri Oct 4 10:50:58 2019 -0700 crypto: af_alg - cast ki_complete ternary op to int commit 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 upstream. when libkcapi test is executed using HW accelerator, cipher operation return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int, libkcapi receive 429467222 even though it expect -ve value. Hence its required to cast resultlen to int so that proper error is returned to libkcapi. AEAD one shot non-aligned test 2(libkcapi test) ./../bin/kcapi -x 10 -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7 -k ea38ac0c9b9998c80e28fb496a2b88d9 -a "853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc" -t "c4ce58985b7203094be1d134c1b8ab0b" -q "b03692f86d1b8b39baf2abb255197c98" Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") Cc: Signed-off-by: Ayush Sawal Signed-off-by: Atul Gupta Signed-off-by: Herbert Xu Signed-off-by: Ayush Sawal Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1e475dc405337200ac743f9d84e13edb01cfd048 Author: Tudor Ambarus Date: Fri Oct 4 08:55:37 2019 +0000 crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize commit 86ef1dfcb561473fbf5e199d58d18c55554d78be upstream. commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property") adds a test vector where the input length is smaller than the IV length (the second test vector). This revealed a NULL pointer dereference in the atmel-aes driver, that is caused by passing an incorrect offset in scatterwalk_map_and_copy() when atmel_aes_complete() is called. Do not save the IV in req->info of ablkcipher_request (or equivalently req->iv of skcipher_request) when req->nbytes < ivsize, because the IV will not be further used. While touching the code, modify the type of ivsize from int to unsigned int, to comply with the return type of crypto_ablkcipher_ivsize(). Fixes: 91308019ecb4 ("crypto: atmel-aes - properly set IV after {en,de}crypt") Cc: Signed-off-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0d51b4d823a9c89d49c52b61e28d3365bbd50c0b Author: Christian Lamparter Date: Thu Oct 31 17:14:38 2019 +0100 crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream. This patch fixes a crash that can happen during probe when the available dma memory is not enough (this can happen if the crypto4xx is built as a module). The descriptor window mapping would end up being free'd twice, once in crypto4xx_build_pdr() and the second time in crypto4xx_destroy_sdr(). Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak") Cc: Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5cbc7ff56097659c5e41e884cff34731ea03e23a Author: Sean Christopherson Date: Fri Nov 22 08:58:18 2019 -0800 KVM: x86: Grab KVM's srcu lock when setting nested state commit ad5996d9a0e8019c3ae5151e687939369acfe044 upstream. Acquire kvm->srcu for the duration of ->set_nested_state() to fix a bug where nVMX derefences ->memslots without holding ->srcu or ->slots_lock. The other half of nested migration, ->get_nested_state(), does not need to acquire ->srcu as it is a purely a dump of internal KVM (and CPU) state to userspace. Detected as an RCU lockdep splat that is 100% reproducible by running KVM's state_test selftest with CONFIG_PROVE_LOCKING=y. Note that the failing function, kvm_is_visible_gfn(), is only checking the validity of a gfn, it's not actually accessing guest memory (which is more or less unsupported during vmx_set_nested_state() due to incorrect MMU state), i.e. vmx_set_nested_state() itself isn't fundamentally broken. In any case, setting nested state isn't a fast path so there's no reason to go out of our way to avoid taking ->srcu. ============================= WARNING: suspicious RCU usage 5.4.0-rc7+ #94 Not tainted ----------------------------- include/linux/kvm_host.h:626 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by evmcs_test/10939: #0: ffff88826ffcb800 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x85/0x630 [kvm] stack backtrace: CPU: 1 PID: 10939 Comm: evmcs_test Not tainted 5.4.0-rc7+ #94 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0x68/0x9b kvm_is_visible_gfn+0x179/0x180 [kvm] mmu_check_root+0x11/0x30 [kvm] fast_cr3_switch+0x40/0x120 [kvm] kvm_mmu_new_cr3+0x34/0x60 [kvm] nested_vmx_load_cr3+0xbd/0x1f0 [kvm_intel] nested_vmx_enter_non_root_mode+0xab8/0x1d60 [kvm_intel] vmx_set_nested_state+0x256/0x340 [kvm_intel] kvm_arch_vcpu_ioctl+0x491/0x11a0 [kvm] kvm_vcpu_ioctl+0xde/0x630 [kvm] do_vfs_ioctl+0xa2/0x6c0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x54/0x200 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f59a2b95f47 Fixes: 8fcc4b5923af5 ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6a10f818a9adbe394eb36d223814e207e5121236 Author: Paolo Bonzini Date: Mon Nov 18 18:58:26 2019 +0100 KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream. KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented to the guests. It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR && !RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not hidden (it actually was), yet the value says that TSX is not vulnerable to microarchitectural data sampling. Fix both. Cc: stable@vger.kernel.org Tested-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5efbd9a9d9c5492fb467bfaf55b77085898645c1 Author: Paolo Bonzini Date: Mon Nov 18 12:23:00 2019 -0500 KVM: x86: do not modify masked bits of shared MSRs commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream. "Shared MSRs" are guest MSRs that are written to the host MSRs but keep their value until the next return to userspace. They support a mask, so that some bits keep the host value, but this mask is only used to skip an unnecessary MSR write and the value written to the MSR is always the guest MSR. Fix this and, while at it, do not update smsr->values[slot].curr if for whatever reason the wrmsr fails. This should only happen due to reserved bits, so the value written to smsr->values[slot].curr will not match when the user-return notifier and the host value will always be restored. However, it is untidy and in rare cases this can actually avoid spurious WRMSRs on return to userspace. Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Tested-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 66f8ca55eb8131fde0b63239d7462a0dbb5cb1d2 Author: Zenghui Yu Date: Tue Oct 29 15:19:19 2019 +0800 KVM: arm/arm64: vgic: Don't rely on the wrong pending table commit ca185b260951d3b55108c0b95e188682d8a507b7 upstream. It's possible that two LPIs locate in the same "byte_offset" but target two different vcpus, where their pending status are indicated by two different pending tables. In such a scenario, using last_byte_offset optimization will lead KVM relying on the wrong pending table entry. Let us use last_ptr instead, which can be treated as a byte index into a pending table and also, can be vcpu specific. Fixes: 280771252c1b ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES") Cc: stable@vger.kernel.org Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Acked-by: Eric Auger Link: https://lore.kernel.org/r/20191029071919.177-4-yuzenghui@huawei.com Signed-off-by: Greg Kroah-Hartman commit e8d9825d557367bdebc0f8d2c1aa27814ac7319f Author: Marek Szyprowski Date: Thu Sep 12 09:36:02 2019 +0200 arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node" commit bed903167ae5b5532eda5d7db26de451bd232da5 upstream. Commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") changed the address and size cells in root node from 2 to 1, but /memory nodes for the affected boards were not updated. This went unnoticed on Exynos5433-based TM2(e) boards, because they use u-boot, which updates /memory node to the correct values. On the other hand, the mentioned commit broke boot on Exynos7-based Espresso board, which bootloader doesn't touch /memory node at all. This patch reverts commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node"), so Exynos5433 and Exynos7 SoCs again matches other ARM64 platforms with 64bit mappings in root node. Reported-by: Alim Akhtar Fixes: ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") Signed-off-by: Marek Szyprowski Cc: # 5.3.x: 72ddcf6aa224 arm64: dts: exynos: Move GPU under /soc node for Exynos5433 Cc: # 5.3.x: ede87c3a2bdb arm64: dts: exynos: Move GPU under /soc node for Exynos7 Cc: # 4.18.x Tested-by: Alim Akhtar Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 9a0511abab590d18c19e71e24f37bb1db2bda4ec Author: Dan Carpenter Date: Fri Oct 4 13:22:51 2019 +0300 drm/i810: Prevent underflow in ioctl commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream. The "used" variables here come from the user in the ioctl and it can be negative. It could result in an out of bounds write. Signed-off-by: Dan Carpenter Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8e47f51af8bb504953952973404b51578d8f8e7a Author: Johan Hovold Date: Thu Oct 10 15:13:30 2019 +0200 drm/msm: fix memleak on release commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream. If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable # 4.18 Cc: Jordan Crouse Cc: Rob Clark Reviewed-by: Rob Clark Signed-off-by: Johan Hovold Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3152fcd479eeae2eeaa44b553adf05a1ccac7637 Author: Jan Kara Date: Tue Nov 5 17:44:07 2019 +0100 jbd2: Fix possible overflow in jbd2_log_space_left() commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream. When number of free space in the journal is very low, the arithmetic in jbd2_log_space_left() could underflow resulting in very high number of free blocks and thus triggering assertion failure in transaction commit code complaining there's not enough space in the journal: J_ASSERT(journal->j_free > 1); Properly check for the low number of free blocks. CC: stable@vger.kernel.org Reviewed-by: Theodore Ts'o Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191105164437.32602-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 18493bac1ae0fd613243c885503142559ec5f1ac Author: Tejun Heo Date: Mon Nov 4 15:54:29 2019 -0800 kernfs: fix ino wrap-around detection commit e23f568aa63f64cd6b355094224cc9356c0f696b upstream. When the 32bit ino wraps around, kernfs increments the generation number to distinguish reused ino instances. The wrap-around detection tests whether the allocated ino is lower than what the cursor but the cursor is pointing to the next ino to allocate so the condition never triggers. Fix it by remembering the last ino and comparing against that. Signed-off-by: Tejun Heo Reviewed-by: Greg Kroah-Hartman Fixes: 4a3ef68acacf ("kernfs: implement i_generation") Cc: Namhyung Kim Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman commit ea57322ae9d7c692c8b2e5ced1eba56065514e4a Author: Jouni Hogander Date: Wed Nov 27 08:40:26 2019 +0200 can: slcan: Fix use-after-free Read in slcan_open commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream. Slcan_open doesn't clean-up device which registration failed from the slcan_devs device list. On next open this list is iterated and freed device is accessed. Fix this by calling slc_free_netdev in error path. Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was identified in slip_open by syzboz. Same bug is in slcan.c. Here is the trace from the Syzbot slip report: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 sl_sync drivers/net/slip/slip.c:725 [inline] slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 tiocsetd drivers/tty/tty_io.c:2334 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path") Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: David Miller Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Cc: linux-stable # >= v5.4 Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 9eadcebe8c87ac6b5c32a655bc8466e096b82496 Author: Dmitry Torokhov Date: Fri Nov 22 12:42:20 2019 -0800 tty: vt: keyboard: reject invalid keycodes commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream. Do not try to handle keycodes that are too big, otherwise we risk doing out-of-bounds writes: BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline] BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722 ... kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145 input_pass_values drivers/input/input.c:949 [inline] input_set_keycode+0x290/0x320 drivers/input/input.c:954 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882 evdev_do_ioctl drivers/input/evdev.c:1150 [inline] In this case we were dealing with a fuzzed HID device that declared over 12K buttons, and while HID layer should not be reporting to us such big keycodes, we should also be defensive and reject invalid data ourselves as well. Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com Signed-off-by: Dmitry Torokhov Cc: stable Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws Signed-off-by: Greg Kroah-Hartman commit d4785d88459eac631347e445793c7c5bccd26e86 Author: Pavel Shilovsky Date: Thu Oct 31 14:18:57 2019 -0700 CIFS: Fix SMB2 oplock break processing commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream. Even when mounting modern protocol version the server may be configured without supporting SMB2.1 leases and the client uses SMB2 oplock to optimize IO performance through local caching. However there is a problem in oplock break handling that leads to missing a break notification on the client who has a file opened. It latter causes big latencies to other clients that are trying to open the same file. The problem reproduces when there are multiple shares from the same server mounted on the client. The processing code tries to match persistent and volatile file ids from the break notification with an open file but it skips all share besides the first one. Fix this by looking up in all shares belonging to the server that issued the oplock break. Cc: Stable Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit df871e551d0a81d3336ecc0790f978a9903e2564 Author: Pavel Shilovsky Date: Wed Nov 27 16:18:39 2019 -0800 CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks commit 6f582b273ec23332074d970a7fb25bef835df71f upstream. Currently when the client creates a cifsFileInfo structure for a newly opened file, it allocates a list of byte-range locks with a pointer to the new cfile and attaches this list to the inode's lock list. The latter happens before initializing all other fields, e.g. cfile->tlink. Thus a partially initialized cifsFileInfo structure becomes available to other threads that walk through the inode's lock list. One example of such a thread may be an oplock break worker thread that tries to push all cached byte-range locks. This causes NULL-pointer dereference in smb2_push_mandatory_locks() when accessing cfile->tlink: [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs] [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs] ... [598428.945834] Call Trace: [598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs] [598428.945901] cifs_oplock_break+0x13d/0x450 [cifs] [598428.945909] process_one_work+0x1db/0x380 [598428.945914] worker_thread+0x4d/0x400 [598428.945921] kthread+0x104/0x140 [598428.945925] ? process_one_work+0x380/0x380 [598428.945931] ? kthread_park+0x80/0x80 [598428.945937] ret_from_fork+0x35/0x40 Fix this by reordering initialization steps of the cifsFileInfo structure: initialize all the fields first and then add the new byte-range lock list to the inode's lock list. Cc: Stable Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 153bd25686d069083734ff9ce216b8dd2891da79 Author: Nicolas Dichtel Date: Mon Jul 15 12:00:23 2019 +0200 xfrm interface: fix management of phydev commit 22d6552f827ef76ade3edf6bbb3f05048a0a7d8b upstream. With the current implementation, phydev cannot be removed: $ ip link add dummy type dummy $ ip link add xfrm1 type xfrm dev dummy if_id 1 $ ip l d dummy kernel:[77938.465445] unregister_netdevice: waiting for dummy to become free. Usage count = 1 Manage it like in ip tunnels, ie just keep the ifindex. Not that the side effect, is that the phydev is now optional. Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Signed-off-by: Nicolas Dichtel Tested-by: Julien Floret Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit cbb629783d9252f5a5eb4585d5844e6ae1ccafd4 Author: Nicolas Dichtel Date: Mon Jul 15 12:00:22 2019 +0200 xfrm interface: fix list corruption for x-netns commit c5d1030f23002430c2a336b2b629b9d6f72b3564 upstream. dev_net(dev) is the netns of the device and xi->net is the link netns, where the device has been linked. changelink() must operate in the link netns to avoid a corruption of the xfrm lists. Note that xi->net and dev_net(xi->physdev) are always the same. Before the patch, the xfrmi lists may be corrupted and can later trigger a kernel panic. Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Reported-by: Julien Floret Signed-off-by: Nicolas Dichtel Tested-by: Julien Floret Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit f04f067aaa38246cc8d7392ee27da80ed8d19289 Author: Nicolas Dichtel Date: Mon Jul 15 12:00:20 2019 +0200 xfrm interface: avoid corruption on changelink commit e9e7e85d75f3731079ffd77c1a66f037aef04fe7 upstream. The new parameters must not be stored in the netdev_priv() before validation, it may corrupt the interface. Note also that if data is NULL, only a memset() is done. $ ip link add xfrm1 type xfrm dev lo if_id 1 $ ip link add xfrm2 type xfrm dev lo if_id 2 $ ip link set xfrm1 type xfrm dev lo if_id 2 RTNETLINK answers: File exists $ ip -d link list dev xfrm1 5: xfrm1@lo: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/none 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu 68 maxmtu 1500 xfrm if_id 0x2 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 => "if_id 0x2" Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Signed-off-by: Nicolas Dichtel Tested-by: Julien Floret Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 28655c632ee0090ae01576e234118ee983a4afa3 Author: Nicolas Dichtel Date: Tue Jul 2 17:51:39 2019 +0200 xfrm interface: fix memory leak on creation commit 56c5ee1a5823e9cf5288b84ae6364cb4112f8225 upstream. The following commands produce a backtrace and return an error but the xfrm interface is created (in the wrong netns): $ ip netns add foo $ ip netns add bar $ ip -n foo netns set bar 0 $ ip -n foo link add xfrmi0 link-netnsid 0 type xfrm dev lo if_id 23 RTNETLINK answers: Invalid argument $ ip -n bar link ls xfrmi0 2: xfrmi0@lo: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/none 00:00:00:00:00:00 brd 00:00:00:00:00:00 Here is the backtrace: [ 79.879174] WARNING: CPU: 0 PID: 1178 at net/core/dev.c:8172 rollback_registered_many+0x86/0x3c1 [ 79.880260] Modules linked in: xfrm_interface nfsv3 nfs_acl auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache button parport_pc parport serio_raw evdev pcspkr loop ext4 crc16 mbcache jbd2 crc32c_generic ide_cd_mod ide_gd_mod cdrom ata_$ eneric ata_piix libata scsi_mod 8139too piix psmouse i2c_piix4 ide_core 8139cp mii i2c_core floppy [ 79.883698] CPU: 0 PID: 1178 Comm: ip Not tainted 5.2.0-rc6+ #106 [ 79.884462] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 79.885447] RIP: 0010:rollback_registered_many+0x86/0x3c1 [ 79.886120] Code: 01 e8 d7 7d c6 ff 0f 0b 48 8b 45 00 4c 8b 20 48 8d 58 90 49 83 ec 70 48 8d 7b 70 48 39 ef 74 44 8a 83 d0 04 00 00 84 c0 75 1f <0f> 0b e8 61 cd ff ff 48 b8 00 01 00 00 00 00 ad de 48 89 43 70 66 [ 79.888667] RSP: 0018:ffffc900015ab740 EFLAGS: 00010246 [ 79.889339] RAX: ffff8882353e5700 RBX: ffff8882353e56a0 RCX: ffff8882353e5710 [ 79.890174] RDX: ffffc900015ab7e0 RSI: ffffc900015ab7e0 RDI: ffff8882353e5710 [ 79.891029] RBP: ffffc900015ab7e0 R08: ffffc900015ab7e0 R09: ffffc900015ab7e0 [ 79.891866] R10: ffffc900015ab7a0 R11: ffffffff82233fec R12: ffffc900015ab770 [ 79.892728] R13: ffffffff81eb7ec0 R14: ffff88822ed6cf00 R15: 00000000ffffffea [ 79.893557] FS: 00007ff350f31740(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 [ 79.894581] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 79.895317] CR2: 00000000006c8580 CR3: 000000022c272000 CR4: 00000000000006f0 [ 79.896137] Call Trace: [ 79.896464] unregister_netdevice_many+0x12/0x6c [ 79.896998] __rtnl_newlink+0x6e2/0x73b [ 79.897446] ? __kmalloc_node_track_caller+0x15e/0x185 [ 79.898039] ? pskb_expand_head+0x5f/0x1fe [ 79.898556] ? stack_access_ok+0xd/0x2c [ 79.899009] ? deref_stack_reg+0x12/0x20 [ 79.899462] ? stack_access_ok+0xd/0x2c [ 79.899927] ? stack_access_ok+0xd/0x2c [ 79.900404] ? __module_text_address+0x9/0x4f [ 79.900910] ? is_bpf_text_address+0x5/0xc [ 79.901390] ? kernel_text_address+0x67/0x7b [ 79.901884] ? __kernel_text_address+0x1a/0x25 [ 79.902397] ? unwind_get_return_address+0x12/0x23 [ 79.903122] ? __cmpxchg_double_slab.isra.37+0x46/0x77 [ 79.903772] rtnl_newlink+0x43/0x56 [ 79.904217] rtnetlink_rcv_msg+0x200/0x24c In fact, each time a xfrm interface was created, a netdev was allocated by __rtnl_newlink()/rtnl_create_link() and then another one by xfrmi_newlink()/xfrmi_create(). Only the second one was registered, it's why the previous commands produce a backtrace: dev_change_net_namespace() was called on a netdev with reg_state set to NETREG_UNINITIALIZED (the first one). CC: Lorenzo Colitti CC: Benedict Wong CC: Steffen Klassert CC: Shannon Nelson CC: Antony Antony CC: Eyal Birger Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Reported-by: Julien Floret Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 2e5c738a25dbc1f9eb03139a03724267bbe70c49 Author: Kai-Heng Feng Date: Mon Sep 2 22:52:52 2019 +0800 x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream. The AMD FCH USB XHCI Controller advertises support for generating PME# while in D0. When in D0, it does signal PME# for USB 3.0 connect events, but not for USB 2.0 or USB 1.1 connect events, which means the controller doesn't wake correctly for those events. 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI]) Subsystem: Dell FCH USB XHCI Controller [1028:087e] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not assert PME# from D0 so we don't rely on it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673 Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 37d080a40575dd62a5caf55ec27c8030361cb3d6 Author: Joerg Roedel Date: Tue Nov 26 11:09:42 2019 +0100 x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all() commit 9a62d20027da3164a22244d9f022c0c987261687 upstream. The job of vmalloc_sync_all() is to help the lazy freeing of vmalloc() ranges: before such vmap ranges are reused we make sure that they are unmapped from every task's page tables. This is really easy on pagetable setups where the kernel page tables are shared between all tasks - this is the case on 32-bit kernels with SHARED_KERNEL_PMD = 1. But on !SHARED_KERNEL_PMD 32-bit kernels this involves iterating over the pgd_list and clearing all pmd entries in the pgds that are cleared in the init_mm.pgd, which is the reference pagetable that the vmalloc() code uses. In that context the current practice of vmalloc_sync_all() iterating until FIX_ADDR_TOP is buggy: for (address = VMALLOC_START & PMD_MASK; address >= TASK_SIZE_MAX && address < FIXADDR_TOP; address += PMD_SIZE) { struct page *page; Because iterating up to FIXADDR_TOP will involve a lot of non-vmalloc address ranges: VMALLOC -> PKMAP -> LDT -> CPU_ENTRY_AREA -> FIX_ADDR This is mostly harmless for the FIX_ADDR and CPU_ENTRY_AREA ranges that don't clear their pmds, but it's lethal for the LDT range, which relies on having different mappings in different processes, and 'synchronizing' them in the vmalloc sense corrupts those pagetable entries (clearing them). This got particularly prominent with PTI, which turns SHARED_KERNEL_PMD off and makes this the dominant mapping mode on 32-bit. To make LDT working again vmalloc_sync_all() must only iterate over the volatile parts of the kernel address range that are identical between all processes. So the correct check in vmalloc_sync_all() is "address < VMALLOC_END" to make sure the VMALLOC areas are synchronized and the LDT mapping is not falsely overwritten. The CPU_ENTRY_AREA and the FIXMAP area are no longer synced either, but this is not really a proplem since their PMDs get established during bootup and never change. This change fixes the ldt_gdt selftest in my setup. [ mingo: Fixed up the changelog to explain the logic and modified the copying to only happen up until VMALLOC_END. ] Reported-by: Borislav Petkov Tested-by: Borislav Petkov Signed-off-by: Joerg Roedel Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Joerg Roedel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: hpa@zytor.com Fixes: 7757d607c6b3: ("x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32") Link: https://lkml.kernel.org/r/20191126111119.GA110513@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 79f08904592c18921969cfcff851b627d69da7bf Author: Navid Emamdoost Date: Thu Nov 21 14:01:11 2019 -0600 Input: Fix memory leak in psxpad_spi_probe In the implementation of psxpad_spi_probe() the allocated memory for pdev is leaked if psxpad_spi_init_ff() or input_register_polled_device() fail. The solution is using device managed allocation, like the one used for pad. Perform the allocation using devm_input_allocate_polled_device(). Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI") Signed-off-by: Navid Emamdoost Acked-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7c193ed6e1a1276a1b3f6b8b0430cb2892e31740 Author: Mike Leach Date: Mon Nov 4 11:12:42 2019 -0700 coresight: etm4x: Fix input validation for sysfs. commit 2fe6899e36aa174abefd017887f9cfe0cb60c43a upstream. A number of issues are fixed relating to sysfs input validation:- 1) bb_ctrl_store() - incorrect compare of bit select field to absolute value. Reworked per ETMv4 specification. 2) seq_event_store() - incorrect mask value - register has two event values. 3) cyc_threshold_store() - must mask with max before checking min otherwise wrapped values can set illegal value below min. 4) res_ctrl_store() - update to mask off all res0 bits. Reviewed-by: Leo Yan Reviewed-by: Mathieu Poirier Signed-off-by: Mike Leach Fixes: a77de2637c9eb ("coresight: etm4x: moving sysFS entries to a dedicated file") Cc: stable # 4.9+ Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20191104181251.26732-6-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 1d01bae86690323e163260287e59689d5782081a Author: Hans de Goede Date: Mon Dec 2 09:36:15 2019 -0800 Input: goodix - add upside-down quirk for Teclast X89 tablet commit df5b5e555b356662a5e4a23c6774fdfce8547d54 upstream. The touchscreen on the Teclast X89 is mounted upside down in relation to the display orientation (the touchscreen itself is mounted upright, but the display is mounted upside-down). Add a quirk for this so that we send coordinates which match the display orientation. Signed-off-by: Hans de Goede Reviewed-by: Bastien Nocera Link: https://lore.kernel.org/r/20191202085636.6650-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 29fef2fe327f65a3da2c9d977bd534f721db8b32 Author: Hans Verkuil Date: Mon Dec 2 10:08:12 2019 -0800 Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers commit a284e11c371e446371675668d8c8120a27227339 upstream. This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by: Hans Verkuil Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 29116a86d746680d73a1252c9b092af5b8c62f54 Author: Lucas Stach Date: Mon Dec 2 09:37:00 2019 -0800 Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash commit 86bcd3a12999447faad60ec59c2d64d18d8e61ac upstream. F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2ef2441c49859001d562b1c40635d4d7bc74f758 Author: Hans Verkuil Date: Fri Nov 22 16:17:08 2019 -0800 Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus commit fc1156f373e3927e0dcf06678906c367588bfdd6 upstream. Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this to the smbus_pnp_ids list. Signed-off-by: Hans Verkuil Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191119105118.54285-2-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1760cf232b5cb77f9eeff11411401857976d0d12 Author: Kai-Heng Feng Date: Wed Nov 20 16:20:35 2019 +0800 ALSA: hda - Add mute led support for HP ProBook 645 G4 commit e190de6941db14813032af87873f5550ad5764fe upstream. Mic mute led does not work on HP ProBook 645 G4. We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20191120082035.18937-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c6bebccd3c6293e49a291a3339f1230b3e49630a Author: Takashi Iwai Date: Wed Dec 4 15:48:24 2019 +0100 ALSA: pcm: oss: Avoid potential buffer overflows commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream. syzkaller reported an invalid access in PCM OSS read, and this seems to be an overflow of the internal buffer allocated for a plugin. Since the rate plugin adjusts its transfer size dynamically, the calculation for the chained plugin might be bigger than the given buffer size in some extreme cases, which lead to such an buffer overflow as caught by KASAN. Fix it by limiting the max transfer size properly by checking against the destination size in each plugin transfer callback. Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f9f56eb9c8412fa62131e6ed0ac8cb7ab7d15d77 Author: Kailang Yang Date: Tue Nov 26 17:04:23 2019 +0800 ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236 commit e1e8c1fdce8b00fce08784d9d738c60ebf598ebc upstream. headphone have noise even the volume is very small. Let it fill up pcbeep hidden register to default value. The issue was gone. Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256") Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204") Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/9ae47f23a64d4e41a9c81e263cd8a250@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fa77bf0cf96c54de226463a6fe9d8dd4be5c115a Author: Hui Wang Date: Thu Nov 21 10:54:27 2019 +0800 ALSA: hda/realtek - Enable the headset-mic on a Xiaomi's laptop commit 695d1ec3994f9de2cefae80ee2087c95d2e5a2f3 upstream. The headset on this machine is not defined, after applying the quirk ALC256_FIXUP_ASUS_HEADSET_MIC, the headset-mic works well BugLink: https://bugs.launchpad.net/bugs/1846148 Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20191121025427.8856-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3bf78033c0441691cf1ba250a4020043ee5069d9 Author: Jian-Hong Pan Date: Mon Nov 25 17:34:06 2019 +0800 ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC commit 436e25505f3458cc92c7f3c985e9cbc198a98209 upstream. Laptops like ASUS UX431FLC and UX431FL can share the same audio quirks. But UX431FLC needs one more step to enable the internal speaker: Pull the GPIO from CODEC to initialize the AMP. Fixes: 60083f9e94b2 ("ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL") Signed-off-by: Jian-Hong Pan Cc: Link: https://lore.kernel.org/r/20191125093405.5702-1-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 710c33adef4ebe46b351988d3fccb0d225ba466c Author: Miklos Szeredi Date: Tue Nov 12 11:49:04 2019 +0100 fuse: verify attributes commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream. If a filesystem returns negative inode sizes, future reads on the file were causing the cpu to spin on truncate_pagecache. Create a helper to validate the attributes. This now does two things: - check the file mode - check if the file size fits in i_size without overflowing Reported-by: Arijit Banerjee Fixes: d8a5ba45457e ("[PATCH] FUSE - core") Cc: # v2.6.14 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9f435a5e3f5f28e20a6b6cfc2301cf5310f6238a Author: Miklos Szeredi Date: Tue Nov 12 11:49:04 2019 +0100 fuse: verify nlink commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream. When adding a new hard link, make sure that i_nlink doesn't overflow. Fixes: ac45d61357e8 ("fuse: fix nlink after unlink") Cc: # v3.4 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 742f2319cbd61d9a051f532ad8c83bb33b48f442 Author: Xuewei Zhang Date: Thu Oct 3 17:12:43 2019 -0700 sched/fair: Scale bandwidth quota and period without losing quota/period ratio precision commit 4929a4e6faa0f13289a67cae98139e727f0d4a97 upstream. The quota/period ratio is used to ensure a child task group won't get more bandwidth than the parent task group, and is calculated as: normalized_cfs_quota() = [(quota_us << 20) / period_us] If the quota/period ratio was changed during this scaling due to precision loss, it will cause inconsistency between parent and child task groups. See below example: A userspace container manager (kubelet) does three operations: 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us. 2) Create a few children cgroups. 3) Set quota to 1,000us and period to 10,000us on a child cgroup. These operations are expected to succeed. However, if the scaling of 147/128 happens before step 3, quota and period of the parent cgroup will be changed: new_quota: 1148437ns, 1148us new_period: 11484375ns, 11484us And when step 3 comes in, the ratio of the child cgroup will be 104857, which will be larger than the parent cgroup ratio (104821), and will fail. Scaling them by a factor of 2 will fix the problem. Tested-by: Phil Auld Signed-off-by: Xuewei Zhang Signed-off-by: Peter Zijlstra (Intel) Acked-by: Phil Auld Cc: Anton Blanchard Cc: Ben Segall Cc: Dietmar Eggemann Cc: Juri Lelli Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vincent Guittot Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup") Link: https://lkml.kernel.org/r/20191004001243.140897-1-xueweiz@google.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b73b5eedddfac178e4db917183b49d0ab7f63210 Author: Dmitry Bogdanov Date: Fri Dec 7 14:00:11 2018 +0000 net: aquantia: fix RSS table and key sizes [ Upstream commit 474fb1150d40780e71f0b569aeac4f375df3af3d ] Set RSS indirection table and RSS hash key sizes to their real size. Signed-off-by: Dmitry Bogdanov Signed-off-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 21a16d1ac916baca3dfeba17788c40dba4303cc3 Author: Helen Fornazier Date: Fri Dec 7 12:56:41 2018 -0500 media: vimc: fix start stream when link is disabled [ Upstream commit e159b6074c82fe31b79aad672e02fa204dbbc6d8 ] If link is disabled, media_entity_remote_pad returns NULL, causing a NULL pointer deference. Ignore links that are not enabled instead. Signed-off-by: Helen Koike Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fb2f4385fca4972afaf8d25dee34383f7446f72c Author: Felix Brack Date: Fri Nov 30 15:54:46 2018 +0100 ARM: dts: am335x-pdu001: Fix polarity of card detection input [ Upstream commit 5760367298a37c459ef0b1364463d70fd9a1f972 ] When a micro SD card is inserted in the PDU001 card cage, the card detection switch is opened and the corresponding GPIO input is driven by a pull-up. Hence change the active level of the card detection input from low to high. Signed-off-by: Felix Brack Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit e60d4b917a7a23ce1326b310451a73201499126c Author: Rob Herring Date: Thu Dec 6 13:11:42 2018 -0600 ARM: dts: sunxi: Fix PMU compatible strings [ Upstream commit 5719ac19fc32d892434939c1756c2f9a8322e6ef ] "arm,cortex-a15-pmu" is not a valid fallback compatible string for an Cortex-A7 PMU, so drop it. Cc: Maxime Ripard Cc: Chen-Yu Tsai Signed-off-by: Rob Herring Acked-by: Will Deacon Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 6539e282bd945118093be174573e624d4655b625 Author: Ladislav Michl Date: Tue Dec 4 19:19:51 2018 +0100 ASoC: max9867: Fix power management [ Upstream commit 29f58ff06795a923407d011d4721eaf3e8d39acc ] Implement set_bias_level to drive shutdown bit, so device is put to sleep when unused. Signed-off-by: Ladislav Michl Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f8d72a2e23efb279435c4e0ca58ec5d796b5d84 Author: Niklas Söderlund Date: Thu Nov 29 01:15:38 2018 +0100 clk: renesas: rcar-gen3: Set state when registering SD clocks [ Upstream commit ecda0a09fa9933bcd67e33c952f778f0872392ed ] The driver tries to figure out which state a SD clock is in when the clock is registered, instead of setting a known state. This can be problematic for two reasons. 1. If the clock driver can't figure out the state of the clock, registration of the clock fails, and setting of a known state by a clock user is not possible. 2. The state of the clock depends on if and how the bootloader configured it. The driver only checks that the rate is known, not if the clock is stopped or not for example. Fix this by setting a known state and making sure the clock is stopped. Signed-off-by: Niklas Söderlund Tested-by: Wolfram Sang Acked-by: Wolfram Sang Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a4c104a35e0b912b44841fd8a85edb4cea53587d Author: YueHaibing Date: Fri Dec 7 03:52:43 2018 +0000 usb: mtu3: fix dbginfo in qmu_tx_zlp_error_handler [ Upstream commit f770e3bc236ee954a3b4052bdf55739e26ee25db ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/usb/mtu3/mtu3_qmu.c: In function 'qmu_tx_zlp_error_handler': drivers/usb/mtu3/mtu3_qmu.c:385:22: warning: variable 'req' set but not used [-Wunused-but-set-variable] It seems dbginfo original intention is print 'req' other than 'mreq' Acked-by: Chunfeng Yun Signed-off-by: YueHaibing Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 49ef54a3523dfb86d91116b595fab554f417bfb9 Author: Qian Cai Date: Thu Nov 29 21:18:07 2018 -0500 mlx4: Use snprintf instead of complicated strcpy [ Upstream commit 0fbc9b8b4ea3f688a5da141a64f97aa33ad02ae9 ] This fixes a compilation warning in sysfs.c drivers/infiniband/hw/mlx4/sysfs.c:360:2: warning: 'strncpy' output may be truncated copying 8 bytes from a string of length 31 [-Wstringop-truncation] By eliminating the temporary stack buffer. Signed-off-by: Qian Cai Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 647ded863b5a3733679e402e3d17bc149bb16f3e Author: Mike Marciniszyn Date: Wed Nov 28 10:32:48 2018 -0800 IB/hfi1: Close VNIC sdma_progress sleep window [ Upstream commit 18912c4524385dd6532c682cb9d4f6aa39ba8d47 ] The call to sdma_progress() is called outside the wait lock. In this case, there is a race condition where sdma_progress() can return false and the sdma_engine can idle. If that happens, there will be no more sdma interrupts to cause the wakeup and the vnic_sdma xmit will hang. Fix by moving the lock to enclose the sdma_progress() call. Also, delete the tx_retry. The need for this was removed by: commit bcad29137a97 ("IB/hfi1: Serve the most starved iowait entry first") Fixes: 64551ede6cd1 ("IB/hfi1: VNIC SDMA support") Reviewed-by: Gary Leshner Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 46824288a5fc7b7e5166be2b6c303d98a41bd631 Author: Kaike Wan Date: Wed Nov 28 10:19:04 2018 -0800 IB/hfi1: Ignore LNI errors before DC8051 transitions to Polling state [ Upstream commit c1a797c0818e0122c7ec8422edd971cfec9b15ea ] When it is requested to change its physical state back to Offline while in the process to go up, DC8051 will set the ERROR field in the DC8051_DBG_ERR_INFO_SET_BY_8051 register. This ERROR field will remain until the next time when DC8051 transitions from Offline to Polling. Subsequently, when the host requests DC8051 to change its physical state to Polling again, it may receive a DC8051 interrupt with the stale ERROR field still in DC8051_DBG_ERR_INFO_SET_BY_8051. If the host link state has been changed to Polling, this stale ERROR will force the host to transition to Offline state, resulting in a vicious cycle of Polling ->Offline->Polling->Offline. On the other hand, if the host link state is still Offline when the stale ERROR is received, the stale ERROR will be ignored, and the link will come up correctly. This patch implements the correct behavior by changing host link state to Polling only after DC8051 changes its physical state to Polling. Reviewed-by: Mike Marciniszyn Signed-off-by: Krzysztof Goreczny Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6b1f6d02f0846290b15ed1fdb1ed06b6d9f819f7 Author: Nir Dotan Date: Thu Dec 6 17:44:52 2018 +0000 mlxsw: spectrum_router: Relax GRE decap matching check [ Upstream commit da93d2913fdf43d5cde3c5a53ac9cc29684d5c7c ] GRE decap offload is configured when local routes prefix correspond to the local address of one of the offloaded GRE tunnels. The matching check was found to be too strict, such that for a flat GRE configuration, in which the overlay and underlay traffic share the same non-default VRF, decap flow was not offloaded. Relax the check for decap flow offloading. A match occurs if the local address of the tunnel matches the local route address while both share the same VRF table. Fixes: 4607f6d26950 ("mlxsw: spectrum_router: Support IPv4 underlay decap") Signed-off-by: Nir Dotan Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 24e9c85c6ea0c37015f39250ac07955000521ef4 Author: Geert Uytterhoeven Date: Wed Dec 5 16:39:42 2018 +0100 soc: renesas: r8a77990-sysc: Fix initialization order of 3DG-{A,B} [ Upstream commit b0d7fbf8b174168c580bb310964c3c809e5569a9 ] The workaround for the wrong hierarchy of the 3DG-{A,B} power domains on R-Car E3 ES1.0 corrected the parent domains. However, the 3DG-{A,B} power domains were still initialized and powered in the wrong order, causing 3DG operation to fail. Fix this by changing the order in the table at runtime, when running on an affected SoC. Fixes: 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit f033651fba25689f1bfa87bed8140add1b5adeab Author: Jakub Audykowicz Date: Tue Dec 4 20:27:41 2018 +0100 sctp: frag_point sanity check [ Upstream commit afd0a8006e98b1890908f81746c94ca5dae29d7c ] If for some reason an association's fragmentation point is zero, sctp_datamsg_from_user will try to endlessly try to divide a message into zero-sized chunks. This eventually causes kernel panic due to running out of memory. Although this situation is quite unlikely, it has occurred before as reported. I propose to add this simple last-ditch sanity check due to the severity of the potential consequences. Signed-off-by: Jakub Audykowicz Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 253c617ea626cb569c91215b7bbdfb53f2205a2b Author: Bjorn Andersson Date: Mon Dec 3 10:33:29 2018 -0800 clk: qcom: gcc-msm8998: Disable halt check of UFS clocks [ Upstream commit 2abf856202fd3e4883e4c518acaa9a023b0dbe54 ] Drop the halt check of the UFS symbol clocks, in accordance with other platforms. This makes clk_disable_unused() happy and makes it possible to turn the clocks on again without an error. Signed-off-by: Bjorn Andersson Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b6f4e1caf426b1978c1afdbade18d094aed4e3ce Author: Jonathan Marek Date: Wed Nov 21 21:32:25 2018 -0500 firmware: qcom: scm: fix compilation error when disabled [ Upstream commit 16ad9501b1f2edebe24f8cf3c09da0695871986b ] This fixes the case when CONFIG_QCOM_SCM is not enabled, and linux/errno.h has not been included previously. Signed-off-by: Jonathan Marek Reviewed-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit 8eccf35a6ff771f831587953dd5b3c659ad16e11 Author: Andreas Pape Date: Fri Nov 23 11:14:54 2018 -0500 media: stkwebcam: Bugfix for wrong return values [ Upstream commit 3c28b91380dd1183347d32d87d820818031ebecf ] usb_control_msg returns in case of a successfully sent message the number of sent bytes as a positive number. Don't use this value as a return value for stk_camera_read_reg, as a non-zero return value is used as an error condition in some cases when stk_camera_read_reg is called. Signed-off-by: Andreas Pape Reviewed-by: Kieran Bingham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 50e9fda8654bf1c4a9239c253f99350b392842c1 Author: Dmitry Safonov Date: Thu Nov 1 00:24:48 2018 +0000 tty: Don't block on IO when ldisc change is pending [ Upstream commit c96cf923a98d1b094df9f0cf97a83e118817e31b ] There might be situations where tty_ldisc_lock() has blocked, but there is already IO on tty and it prevents line discipline changes. It might theoretically turn into dead-lock. Basically, provide more priority to pending tty_ldisc_lock() than to servicing reads/writes over tty. User-visible issue was reported by Mikulas where on pa-risc with Debian 5 reboot took either 80 seconds, 3 minutes or 3:25 after proper locking in tty_reopen(). Cc: Jiri Slaby Reported-by: Mikulas Patocka Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 01e5d17964947f52808a2908a972918223c4b4d0 Author: Paul Kocialkowski Date: Wed Dec 5 10:24:30 2018 +0100 ARM: dts: sun8i: h3: Fix the system-control register range [ Upstream commit 925c5afd78c40169c7e0e6adec52d5119ff43751 ] Unlike in previous generations, the system-control register range is not limited to a size of 0x30 on the H3. In particular, the EMAC clock configuration register (accessed through syscon) is at offset 0x30 in that range. Extend the register size to its full range (0x1000) as a result. Signed-off-by: Paul Kocialkowski Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 6854d02bcb67d0b768b25b2e54482e3e4cc046a1 Author: Ryan Case Date: Thu Nov 29 18:18:40 2018 -0800 tty: serial: qcom_geni_serial: Fix softlock [ Upstream commit a1fee899e5bed457afc20a6a2ff3915a95cc5942 ] Transfers were being divided into device FIFO sized (64 byte max) operations which would poll for completion within a spin_lock_irqsave / spin_unlock_irqrestore block. This both made things slow by waiting for the FIFO to completely drain before adding further data and would also result in softlocks on large transmissions. This patch allows larger transfers with continuous FIFO additions as space becomes available and removes polling from the interrupt handler. Signed-off-by: Ryan Case Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5146add60adf31ae4d02cfac0150eb8f8d3aa9b7 Author: Kieran Bingham Date: Fri Nov 9 09:26:10 2018 -0500 media: uvcvideo: Abstract streaming object lifetime [ Upstream commit ece41454c6a5ed8f301ef1c37710ab222e577823 ] The streaming object is a key part of handling the UVC device. Although not critical, we are currently missing a call to destroy the mutex on clean up paths, and we are due to extend the objects complexity in the near future. Facilitate easy management of a stream object by creating a pair of functions to handle creating and destroying the allocation. The new uvc_stream_delete() function also performs the missing mutex_destroy() operation. Previously a failed streaming object allocation would cause uvc_parse_streaming() to return -EINVAL, which is inappropriate. If the constructor failes, we will instead return -ENOMEM. While we're here, fix the trivial spelling error in the function banner of uvc_delete(). Signed-off-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1ff89e6d4b2332801bfaf5ab3cfd6660b7096bd0 Author: zhengbin Date: Fri Nov 30 16:04:25 2018 +0800 nfsd: Return EPERM, not EACCES, in some SETATTR cases [ Upstream commit 255fbca65137e25b12bced18ec9a014dc77ecda0 ] As the man(2) page for utime/utimes states, EPERM is returned when the second parameter of utime or utimes is not NULL, the caller's effective UID does not match the owner of the file, and the caller is not privileged. However, in a NFS directory mounted from knfsd, it will return EACCES (from nfsd_setattr-> fh_verify->nfsd_permission). This patch fixes that. Signed-off-by: zhengbin Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit ef51042de4b497e2c2baaabfd176815cd6e8b5c1 Author: Aaro Koskinen Date: Tue Dec 4 22:12:17 2018 +0200 MIPS: OCTEON: cvmx_pko_mem_debug8: use oldest forward compatible definition [ Upstream commit 1c6121c39677175bd372076020948e184bad4b6b ] cn58xx is compatible with cn50xx, so use the latter. Signed-off-by: Aaro Koskinen [paul.burton@mips.com: s/cn52xx/cn50xx/ in commit message.] Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@vger.kernel.org Signed-off-by: Sasha Levin commit 66371d5356d38d61cbea61711569b55948fae075 Author: Geert Uytterhoeven Date: Thu Nov 29 11:06:37 2018 +0100 clk: renesas: r8a77995: Correct parent clock of DU [ Upstream commit 515b2915ee08060ad4f6a3b3de38c5c2c5258e8b ] According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock of the DU module clocks on R-Car D3 is S1D1. Fixes: d71e851d82c6cfe5 ("clk: renesas: cpg-mssr: Add R8A77995 support") Signed-off-by: Geert Uytterhoeven Acked-by: Stephen Boyd Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 7718f9e818d7c8abb401ea5144ede10465b3c053 Author: Takeshi Kihara Date: Fri Oct 12 16:48:34 2018 +0900 clk: renesas: r8a77990: Correct parent clock of DU [ Upstream commit 7cf3a216a2b3a672cad3e498c186c9333bdff90a ] According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock of the DU module clocks on R-Car E3 is S1D1. Signed-off-by: Takeshi Kihara Fixes: 3570a2af473789c5 ("clk: renesas: cpg-mssr: Add support for R-Car E3") Signed-off-by: Geert Uytterhoeven Acked-by: Stephen Boyd Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 7ad0c78bb317358639c3af35783442fd7bfd5f2b Author: Joel Stanley Date: Tue Dec 4 09:37:46 2018 +1030 powerpc/math-emu: Update macros from GCC [ Upstream commit b682c8692442711684befe413cf93cf01c5324ea ] The add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate from GCC's longlong.h which in turn was copied from GMP's longlong.h a few decades ago. This was found when compiling with clang: arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions FP_ADD_D(R, T, B); ^~~~~~~~~~~~~~~~~ ... ./arch/powerpc/include/asm/sfp-machine.h:283:27: note: expanded from macro 'sub_ddmmss' : "=r" ((USItype)(sh)), \ ~~~~~~~~~~^~~ Segher points out: this was fixed in GCC over 16 years ago ( https://gcc.gnu.org/r56600 ), and in GMP (where it comes from) presumably before that. Update the add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros to the latest GCC version in order to git rid of the invalid casts. These were taken as-is from GCC's longlong in order to make future syncs obvious. Other parts of sfp-machine.h were left as-is as the file contains more features than present in longlong.h. Link: https://github.com/ClangBuiltLinux/linux/issues/260 Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers Reviewed-by: Segher Boessenkool Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 6b6f6030afd29f3470a3cf2630d9afdc1ec8a241 Author: Kees Cook Date: Mon Dec 3 16:39:01 2018 -0800 pstore/ram: Avoid NULL deref in ftrace merging failure path [ Upstream commit 8665569e97dd52920713b95675409648986b5b0d ] Given corruption in the ftrace records, it might be possible to allocate tmp_prz without assigning prz to it, but still marking it as needing to be freed, which would cause at least a NULL dereference. smatch warnings: fs/pstore/ram.c:340 ramoops_pstore_read() error: we previously assumed 'prz' could be null (see line 255) https://lists.01.org/pipermail/kbuild-all/2018-December/055528.html Reported-by: Dan Carpenter Fixes: 2fbea82bbb89 ("pstore: Merge per-CPU ftrace records into one") Cc: "Joel Fernandes (Google)" Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 9c6ca33f12cd4b678676c0a9e152c0e2c4e2a277 Author: Erez Alfasi Date: Sun Dec 2 17:40:25 2018 +0200 net/mlx4_core: Fix return codes of unsupported operations [ Upstream commit 95aac2cdafd8c8298c9b2589c52f44db0d824e0e ] Functions __set_port_type and mlx4_check_port_params returned -EINVAL while the proper return code is -EOPNOTSUPP as a result of an unsupported operation. All drivers should generate this and all users should check for it when detecting an unsupported functionality. Signed-off-by: Erez Alfasi Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 446a04d879a0ca9fc58195050ea6117d1f9bd22a Author: David Teigland Date: Mon Dec 3 15:27:37 2018 -0600 dlm: fix invalid cluster name warning [ Upstream commit 3595c559326d0b660bb088a88e22e0ca630a0e35 ] The warning added in commit 3b0e761ba83 "dlm: print log message when cluster name is not set" did not account for the fact that lockspaces created from userland do not supply a cluster name, so bogus warnings are printed every time a userland lockspace is created. Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ab9d56dace3bdd7ed6957923b85c6cb29f959d68 Author: Rob Herring Date: Mon Dec 3 13:12:48 2018 -0600 ARM: dts: realview: Fix some more duplicate regulator nodes [ Upstream commit f3b2f758ec1e6cdb13c925647cbd8ad4938b78fb ] There's a bug in dtc in checking for duplicate node names when there's another section (e.g. "/ { };"). In this case, skeleton.dtsi provides another section. Upon removal of skeleton.dtsi, the dtb fails to build due to a duplicate node 'fixedregulator@0'. As both nodes were pretty much the same 3.3V fixed regulator, it hasn't really mattered. Fix this by renaming the nodes to something unique. In the process, drop the unit-address which shouldn't be present wtihout reg property. Signed-off-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 82bfaec726d3e0a5318c9cd17ad0a24a6007e479 Author: Neil Armstrong Date: Thu Nov 8 07:44:48 2018 -0500 media: cxd2880-spi: fix probe when dvb_attach fails [ Upstream commit 458ffce1cb46e46e3cec48b625ed142250475708 ] When dvb_attach fails, probe returns 0, and remove crashes afterwards. This patch sets the return value to -ENODEV when attach fails. Fixes: bd24fcddf6b8 ("media: cxd2880-spi: Add support for CXD2880 SPI interface") Signed-off-by: Neil Armstrong Acked-by: Yasunari Takiguchi Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7f095bd0326b486011d6a0b1637e1fe6c6d40326 Author: Jeffrey Hugo Date: Mon Dec 3 09:13:43 2018 -0700 clk: qcom: Fix MSM8998 resets [ Upstream commit 4f89f7b59a6ea17e81cff212c18a0b580ff5ff27 ] The offsets for the defined BCR reset registers does not match the hardware documentation. Update the values to match the hardware documentation. Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver) Signed-off-by: Jeffrey Hugo Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5c6493d2ee8e855c82dcc218151ecd92934cdd32 Author: Chen-Yu Tsai Date: Fri Nov 30 13:33:28 2018 +0800 clk: sunxi-ng: h3/h5: Fix CSI_MCLK parent [ Upstream commit 7bb7d29cffdd24bf419516d14b6768591e74069e ] The third parent of CSI_MCLK is PLL_PERIPH1, not PLL_PERIPH0. Fix it. Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks") Acked-by: Stephen Boyd Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 9122845dc398e1ab3316e18dc10b469c689c85ce Author: Martin Blumenstingl Date: Sun Dec 2 22:42:18 2018 +0100 clk: meson: meson8b: fix the offset of vid_pll_dco's N value [ Upstream commit 376d8c45bd6ac79f02ecf9ca1606dc5d1b271bc0 ] Unlike the other PLLs on Meson8b the N value "vid_pll_dco" (a better name would be hdmi_pll_dco or - as the datasheet calls it - HPLL) is located at HHI_VID_PLL_CNTL[14:10] instead of [13:9]. This results in an incorrect calculation of the rate of this PLL because the value seen by the kernel is double the actual N (divider) value. Update the offset of the N value to fix the calculation of the PLL rate. Fixes: 28b9fcd016126e ("clk: meson8b: Add support for Meson8b clocks") Reported-by: Jianxin Pan Signed-off-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20181202214220.7715-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 90ac7278e652660bd7ffd2e23bfa13893237a344 Author: Daniel Mack Date: Sat Dec 1 14:54:51 2018 +0100 ARM: dts: pxa: clean up USB controller nodes [ Upstream commit c40ad24254f1dbd54f2df5f5f524130dc1862122 ] PXA25xx SoCs don't have a USB controller, so drop the node from the common pxa2xx.dtsi base file. Both pxa27x and pxa3xx have a dedicated node already anyway. While at it, unify the names for the nodes across all pxa platforms. Signed-off-by: Daniel Mack Reported-by: Sergey Yanovich Link: https://patchwork.kernel.org/patch/8375421/ Signed-off-by: Robert Jarzmik Signed-off-by: Sasha Levin commit 75fecd8d71dba8bde48e5a0edebe1f3847b883b2 Author: Miquel Raynal Date: Sun Nov 18 21:18:30 2018 +0100 mtd: fix mtd_oobavail() incoherent returned value [ Upstream commit 4348433d8c0234f44adb6e12112e69343f50f0c5 ] mtd_oobavail() returns either mtd->oovabail or mtd->oobsize. Both values are unsigned 32-bit entities, so there is no reason to pretend returning a signed one. Signed-off-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit f7a5ed083e71b700ee9a5c89fcb37cfc22e3731a Author: Masahiro Yamada Date: Thu Nov 22 08:11:54 2018 +0900 kbuild: fix single target build for external module [ Upstream commit e07db28eea38ed4e332b3a89f3995c86b713cb5b ] Building a single target in an external module fails due to missing .tmp_versions directory. For example, $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o will fail in the following way: CC [M] /home/masahiro/foo/foo.o /bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent This is because $(cmd_crmodverdir) is executed only before building /, %/, %.ko single targets of external modules. Create .tmp_versions in the 'prepare' target. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit f28d930810ee3b4483a76712478279370b7f0281 Author: Paul Walmsley Date: Wed Nov 21 13:14:13 2018 -0800 modpost: skip ELF local symbols during section mismatch check [ Upstream commit a4d26f1a0958bb1c2b60c6f1e67c6f5d43e2647b ] During development of a serial console driver with a gcc 8.2.0 toolchain for RISC-V, the following modpost warning appeared: ---- WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1 references the function __init sifive_serial_console_setup() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console ---- ".LANCHOR1" is an ELF local symbol, automatically created by gcc's section anchor generation code: https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473 This was verified by compiling the kernel with -fno-section-anchors and observing that the ".LANCHOR1" ELF local symbol disappeared, and modpost no longer warned about the section mismatch. The serial driver code idiom triggering the warning is standard Linux serial driver practice that has a specific whitelist inclusion in modpost.c. I'm neither a modpost nor an ELF expert, but naively, it doesn't seem useful for modpost to report section mismatch warnings caused by ELF local symbols by default. Local symbols have compiler-generated names, and thus bypass modpost's whitelisting algorithm, which relies on the presence of a non-autogenerated symbol name. This increases the likelihood that false positive warnings will be generated (as in the above case). Thus, disable section mismatch reporting on ELF local symbols. The rationale here is similar to that of commit 2e3a10a1551d ("ARM: avoid ARM binutils leaking ELF local symbols") and of similar code already present in modpost.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256 This third version of the patch implements a suggestion from Masahiro Yamada to restructure the code as an additional pattern matching step inside secref_whitelist(), and further improves the patch description. Signed-off-by: Paul Walmsley Signed-off-by: Paul Walmsley Acked-by: Sam Ravnborg Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 01775a8dc616d465cfb28ee1b928803179bec440 Author: Yuchung Cheng Date: Wed Nov 28 16:06:45 2018 -0800 tcp: fix SNMP TCP timeout under-estimation [ Upstream commit e1561fe2dd69dc5dddd69bd73aa65355bdfb048b ] Previously the SNMP TCPTIMEOUTS counter has inconsistent accounting: 1. It counts all SYN and SYN-ACK timeouts 2. It counts timeouts in other states except recurring timeouts and timeouts after fast recovery or disorder state. Such selective accounting makes analysis difficult and complicated. For example the monitoring system needs to collect many other SNMP counters to infer the total amount of timeout events. This patch makes TCPTIMEOUTS counter simply counts all the retransmit timeout (SYN or data or FIN). Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a5f37a687f3fc7c3cea674287642424ebf9764a1 Author: Yuchung Cheng Date: Wed Nov 28 16:06:44 2018 -0800 tcp: fix SNMP under-estimation on failed retransmission [ Upstream commit ec641b39457e17774313b66697a8a1dc070257bd ] Previously the SNMP counter LINUX_MIB_TCPRETRANSFAIL is not counting the TSO/GSO properly on failed retransmission. This patch fixes that. Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 85b03cfe31befc481e1da603d888517da2e30409 Author: Yuchung Cheng Date: Wed Nov 28 16:06:43 2018 -0800 tcp: fix off-by-one bug on aborting window-probing socket [ Upstream commit 3976535af0cb9fe34a55f2ffb8d7e6b39a2f8188 ] Previously there is an off-by-one bug on determining when to abort a stalled window-probing socket. This patch fixes that so it is consistent with tcp_write_timeout(). Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 47d83feb885e2dfa625f0cd50829ea10bd5902e2 Author: Rob Herring Date: Thu Nov 29 19:05:47 2018 -0600 ARM: dts: realview-pbx: Fix duplicate regulator nodes [ Upstream commit 7f4b001b7f6e0480b5bdab9cd8ce1711e43e5cb5 ] There's a bug in dtc in checking for duplicate node names when there's another section (e.g. "/ { };"). In this case, skeleton.dtsi provides another section. Upon removal of skeleton.dtsi, the dtb fails to build due to a duplicate node 'fixedregulator@0'. As both nodes were pretty much the same 3.3V fixed regulator, it hasn't really mattered. Fix this by renaming the nodes to something unique. In the process, drop the unit-address which shouldn't be present wtihout reg property. Cc: Linus Walleij Signed-off-by: Rob Herring Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 3ab2e27ba4463d45118457cf9e0bc856ec2a122c Author: Lubomir Rintel Date: Wed Nov 28 18:53:06 2018 +0100 ARM: dts: mmp2: fix the gpio interrupt cell number [ Upstream commit 400583983f8a8e95ec02c9c9e2b50188753a87fb ] gpio-pxa uses two cell to encode the interrupt source: the pin number and the trigger type. Adjust the device node accordingly. Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 3ad3a9a24207dd868bdd20c42e23f2eed6c4cfdd Author: Eric Dumazet Date: Tue Nov 27 14:42:02 2018 -0800 tcp: make tcp_space() aware of socket backlog [ Upstream commit 85bdf7db5b53cdcc7a901db12bcb3d0063e3866d ] Jean-Louis Dupond reported poor iscsi TCP receive performance that we tracked to backlog drops. Apparently we fail to send window updates reflecting the fact that we are under stress. Note that we might lack a proper window increase when backlog is fully processed, since __release_sock() clears sk->sk_backlog.len _after_ all skbs have been processed. This should not matter in practice. If we had a significant load through socket backlog, we are in a dangerous situation. Reported-by: Jean-Louis Dupond Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Tested-by: Jean-Louis Dupond Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5db05cf0f6e698c11bc7dbfc0f31fb0bb23c458e Author: Rob Herring Date: Wed Nov 28 19:11:50 2018 -0600 kbuild: disable dtc simple_bus_reg warnings by default [ Upstream commit 70523a3ce5ff928faa43bb2cad554dc63438e3e7 ] The updated version of dtc has a bug fix for simple_bus_reg warnings and lots of warnings are generated now. So disable this warning by default. Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 82df606be888193dc7bbfb29e9fc624feb05500f Author: Geert Uytterhoeven Date: Thu Nov 29 11:56:18 2018 +0100 soc: renesas: r8a77980-sysc: Correct A3VIP[012] power domain hierarchy [ Upstream commit 160bfa7c724b348a90a12dd9694f351927a15b8e ] The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018) renamed the A3VIP power domain on R-Car V3H to A3VIP0, and clarified the power domain hierarchy for the A3VIP[012] power domains. As the definition for the A3VIP0 domain is not yet used from DT, it can just be renamed. Fixes: 7755b40d07a8dba7 ("dt-bindings: power: add R8A77980 SYSC power domain definitions") Fixes: 41d6d8bd8ae94ca9 ("soc: renesas: rcar-sysc: add R8A77980 support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 1b43a008d371110a8d031109cf7f4bc6d7d1fc70 Author: Geert Uytterhoeven Date: Thu Nov 29 11:56:17 2018 +0100 soc: renesas: r8a77980-sysc: Correct names of A2DP[01] power domains [ Upstream commit 97473bc85b22ac610b1810b6a9a4669a6cb0b7b0 ] The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018) renamed the A2PD0 and A2DP0 power domains on R-Car V3H to A2DP0 resp. A2DP1. As these definitions are not yet used from DT, they can just be renamed. Fixes: 7755b40d07a8dba7 ("dt-bindings: power: add R8A77980 SYSC power domain definitions") Fixes: 41d6d8bd8ae94ca9 ("soc: renesas: rcar-sysc: add R8A77980 support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 9a04bfc7594ccea27880292a6059725933610472 Author: Geert Uytterhoeven Date: Thu Nov 29 11:56:16 2018 +0100 soc: renesas: r8a77970-sysc: Correct names of A2DP/A2CN power domains [ Upstream commit b5eb730e031acaba2d25e8f522ac5966a70885ae ] The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018) renamed the A2IR2 and A2IR3 power domains on R-Car V3M to A2DP resp. A2CN. As these definitions are not yet used from DT, they can just be renamed. While at it, fix the indentation of the A3IR definition. Fixes: 833bdb47c826a1a6 ("dt-bindings: power: add R8A77970 SYSC power domain definitions") Fixes: bab9b2a74fe9da96 ("soc: renesas: rcar-sysc: add R8A77970 support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 5f21842def7442706aa9ba7802b5c4287d6eaa3f Author: Stephen Boyd Date: Fri Nov 30 00:36:33 2018 -0800 clk: mediatek: Drop more __init markings for driver probe [ Upstream commit 553604c041b8c18cd6a8e1d785a77f3e4be61cdb ] This function is called from driver probe, which isn't the same as __init code because driver probe can happen later. Drop the __init marking here to fix this potential problem. Cc: Sean Wang Cc: Ryder Lee Cc: Rob Herring Cc: Wenzhen Yu Cc: Weiyi Lu Fixes: 2fc0a509e4ee ("clk: mediatek: add clock support for MT7622 SoC") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d4343f89c7141d91b18a46e2c8ced18a0c3a301 Author: Stephen Boyd Date: Fri Nov 30 00:34:33 2018 -0800 clk: mediatek: Drop __init from mtk_clk_register_cpumuxes() commit 28f1186a26f7e4e5df7be454710da26c810effb6 upstream. This function is used from more places than just __init code. Removing __init silences a section mismatch warning here. Cc: Sean Wang Cc: Ryder Lee Cc: Rob Herring Cc: Wenzhen Yu Cc: Weiyi Lu Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 043a7151d23c5c1171c1e0084d7402e230b56e0a Author: Yonghong Song Date: Thu Nov 29 15:31:45 2018 -0800 tools/bpf: make libbpf _GNU_SOURCE friendly [ Upstream commit b42699547fc9fb1057795bccc21a6445743a7fde ] During porting libbpf to bcc, I got some warnings like below: ... [ 2%] Building C object src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0: warning: "_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE ... [ 3%] Building C object src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf_errno.c.o /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf_errno.c: In function ‘libbpf_strerror’: /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf_errno.c:45:7: warning: assignment makes integer from pointer without a cast [enabled by default] ret = strerror_r(err, buf, size); ... bcc is built with _GNU_SOURCE defined and this caused the above warning. This patch intends to make libpf _GNU_SOURCE friendly by . define _GNU_SOURCE in libbpf.c unless it is not defined . undefine _GNU_SOURCE as non-gnu version of strerror_r is expected. Signed-off-by: Yonghong Song Acked-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit d094d6510231b1ebafe6cc651507a62206f0ca72 Author: Martin Schiller Date: Tue Nov 27 09:50:28 2018 +0100 net/x25: fix null_x25_address handling [ Upstream commit 06137619f061f498c2924f6543fa45b7d39f0501 ] o x25_find_listener(): the compare for the null_x25_address was wrong. We have to check the x25_addr of the listener socket instead of the x25_addr of the incomming call. o x25_bind(): it was not possible to bind a socket to null_x25_address Signed-off-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12fc4bcc89ef5b34a8fdd8df6b674e055be09a17 Author: Martin Schiller Date: Tue Nov 27 09:50:27 2018 +0100 net/x25: fix called/calling length calculation in x25_parse_address_block [ Upstream commit d449ba3d581ed29f751a59792fdc775572c66904 ] The length of the called and calling address was not calculated correctly (BCD encoding). Signed-off-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b7950442f2977363b53d567ab723c92cf47279fb Author: Neil Armstrong Date: Wed Nov 7 11:45:50 2018 +0100 arm64: dts: meson-gxl-khadas-vim: fix GPIO lines names [ Upstream commit 5b78012636f537344bd551934387f5772c38ba80 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 60795933b709 ("ARM64: dts: meson-gxl-khadas-vim: Add GPIO lines names") Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit f7979e85d40774ef84df368450c2a09aa8264555 Author: Neil Armstrong Date: Wed Nov 7 11:45:49 2018 +0100 arm64: dts: meson-gxbb-odroidc2: fix GPIO lines names [ Upstream commit 2165b006b65d609140dafafcb14cce5a4aaacbab ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: b03c7d6438bb ("ARM64: dts: meson-gxbb-odroidc2: Add GPIO lines names") Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit f9737040b24c6f33c64275aad69b4fecd7105e1e Author: Neil Armstrong Date: Wed Nov 7 11:45:48 2018 +0100 arm64: dts: meson-gxbb-nanopi-k2: fix GPIO lines names [ Upstream commit f0783f5edb52af14ecaae6c5ce4f38e0a358f5d8 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 12ada0513d7a ("ARM64: dts: meson-gxbb-nanopi-k2: Add GPIO lines names") Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit e99194333f3c48406e8b1cb41dd2da05b248e4d3 Author: Neil Armstrong Date: Wed Nov 7 11:45:47 2018 +0100 arm64: dts: meson-gxl-libretech-cc: fix GPIO lines names [ Upstream commit 11fa9774612decea87144d7f950a9c53a4fe3050 ] The gpio line names were set in the pinctrl node instead of the gpio node, at the time it was merged, it worked, but was obviously wrong. This patch moves the properties to the gpio nodes. Fixes: 47884c5c746e ("ARM64: dts: meson-gxl-libretech-cc: Add GPIO lines names") Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 9cd0da478f1d65e43b15f83bcba1bfa0098a7b41 Author: Aaro Koskinen Date: Mon Nov 19 21:46:41 2018 +0200 ARM: OMAP1/2: fix SoC name printing [ Upstream commit 04a92358b3964988c78dfe370a559ae550383886 ] Currently we get extra newlines on OMAP1/2 when the SoC name is printed: [ 0.000000] OMAP1510 [ 0.000000] revision 2 handled as 15xx id: bc058c9b93111a16 [ 0.000000] OMAP2420 [ 0.000000] Fix by using pr_cont. Signed-off-by: Aaro Koskinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 833ca57bf485969973cb56408377230599796b30 Author: Young_X Date: Tue Nov 27 06:33:16 2018 +0000 ASoC: au8540: use 64-bit arithmetic instead of 32-bit [ Upstream commit cd7fdc45bc69a62b4e22c6e875f1f1aea566256d ] Add suffix ULL to constant 256 in order to give the compiler complete information about the proper arithmetic to use. Notice that such constant is used in a context that expects an expression of type u64 (64 bits, unsigned) and the following expression is currently being evaluated using 32-bit arithmetic: 256 * fs * 2 * mclk_src_scaling[i].param Signed-off-by: Young_X Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29e704b7a7b119291511a9f18bd2c46da50cf4f7 Author: Yonghong Song Date: Wed Nov 28 09:38:23 2018 -0800 tools: bpftool: fix a bitfield pretty print issue [ Upstream commit 528bff0cdb6649f97f2c4802e4ac7a4b50645f2f ] Commit b12d6ec09730 ("bpf: btf: add btf print functionality") added btf pretty print functionality to bpftool. There is a problem though in printing a bitfield whose type has modifiers. For example, for a type like typedef int ___int; struct tmp_t { int a:3; ___int b:3; }; Suppose we have a map struct bpf_map_def SEC("maps") tmpmap = { .type = BPF_MAP_TYPE_HASH, .key_size = sizeof(__u32), .value_size = sizeof(struct tmp_t), .max_entries = 1, }; and the hash table is populated with one element with key 0 and value (.a = 1 and .b = 2). In BTF, the struct member "b" will have a type "typedef" which points to an int type. The current implementation does not pass the bit offset during transition from typedef to int type, hence incorrectly print the value as $ bpftool m d id 79 [{ "key": 0, "value": { "a": 0x1, "b": 0x1 } } ] This patch fixed the issue by carrying bit_offset along the type chain during bit_field print. The correct result can be printed as $ bpftool m d id 76 [{ "key": 0, "value": { "a": 0x1, "b": 0x2 } } ] The kernel pretty print is implemented correctly and does not have this issue. Fixes: b12d6ec09730 ("bpf: btf: add btf print functionality") Signed-off-by: Yonghong Song Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 12c49ac4cfa935ba76cde8f717c49d422e05e7bb Author: Yonghong Song Date: Tue Nov 27 13:23:28 2018 -0800 bpf: btf: check name validity for various types [ Upstream commit eb04bbb608e683f8fd3ef7f716e2fa32dd90861f ] This patch added name checking for the following types: . BTF_KIND_PTR, BTF_KIND_ARRAY, BTF_KIND_VOLATILE, BTF_KIND_CONST, BTF_KIND_RESTRICT: the name must be null . BTF_KIND_STRUCT, BTF_KIND_UNION: the struct/member name is either null or a valid identifier . BTF_KIND_ENUM: the enum type name is either null or a valid identifier; the enumerator name must be a valid identifier. . BTF_KIND_FWD: the name must be a valid identifier . BTF_KIND_TYPEDEF: the name must be a valid identifier For those places a valid name is required, the name must be a valid C identifier. This can be relaxed later if we found use cases for a different (non-C) frontend. Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)") Acked-by: Martin KaFai Lau Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2f3e380d494c2126f7a9520ceeccbff00ab3e82f Author: Yonghong Song Date: Tue Nov 27 13:23:27 2018 -0800 bpf: btf: implement btf_name_valid_identifier() [ Upstream commit cdbb096adddb3f42584cecb5ec2e07c26815b71f ] Function btf_name_valid_identifier() have been implemented in bpf-next commit 2667a2626f4d ("bpf: btf: Add BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO"). Backport this function so later patch can use it. Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3ff6af8e0a6ad7526789808a6b2867fce16331a2 Author: Scott Mayhew Date: Tue Nov 6 13:35:08 2018 -0500 nfsd: fix a warning in __cld_pipe_upcall() [ Upstream commit b493fd31c0b89d9453917e977002de58bebc3802 ] __cld_pipe_upcall() emits a "do not call blocking ops when !TASK_RUNNING" warning due to the dput() call in rpc_queue_upcall(). Fix it by using a completion instead of hand coding the wait. Signed-off-by: Scott Mayhew Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit a57b3ecc06d4dbc3b327a98a6ce5e432112e1f95 Author: YueHaibing Date: Wed Sep 26 18:32:29 2018 +0800 can: xilinx: fix return type of ndo_start_xmit function [ Upstream commit 81de0cd60fd492575b24d97667f38b8b833fb058 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by: YueHaibing Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 614348676cb945b8dfccaa37cff491880be01277 Author: Clément Péron Date: Tue Oct 9 13:28:37 2018 +0200 ARM: debug: enable UART1 for socfpga Cyclone5 [ Upstream commit f6628486c8489e91c513b62608f89ccdb745600d ] Cyclone5 and Arria10 doesn't have the same memory map for UART1. Split the SOCFPGA_UART1 into 2 options to allow debugging on UART1 for Cyclone5. Signed-off-by: Clément Péron Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 3b0107ca80fbd03991ad568ef14fe13199703592 Author: Wen Yang Date: Wed Nov 28 15:25:00 2018 +0800 dlm: NULL check before kmem_cache_destroy is not needed [ Upstream commit f31a89692830061bceba8469607e4e4b0f900159 ] kmem_cache_destroy(NULL) is safe, so removes NULL check before freeing the mem. This patch also fix ifnullfree.cocci warnings. Signed-off-by: Wen Yang Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 980cd9a18b16ba1ff07d60101c1d836d7df5e18f Author: Maxime Ripard Date: Wed Nov 7 10:58:01 2018 +0100 ARM: dts: sun8i: v3s: Change pinctrl nodes to avoid warning [ Upstream commit 438a44ce7e51ce571f942433c6c7cb87c4c0effd ] All our pinctrl nodes were using a node name convention with a unit-address to differentiate the different muxing options. However, since those nodes didn't have a reg property, they were generating warnings in DTC. In order to accomodate for this, convert the old nodes to the syntax we've been using for the new SoCs, including removing the letter suffix of the node labels to the bank of those pins to make things more readable. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 7e79de528afa68176ba5f131f2185f443a9f6ad1 Author: Maxime Ripard Date: Wed Nov 21 09:51:04 2018 +0100 ARM: dts: sun8i: a23/a33: Fix OPP DTC warnings [ Upstream commit a858f569b80a69076c521532a289097af905cf1e ] DTC will emit a warning on our OPPs nodes for the common DTSI between the A23 and A33 since those nodes use the frequency as unit addresses, but don't have a matching reg property. Fix this by moving the frequency to the node name instead. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 1ff8cb13835d5fedd7ad9c54bf38ed52763ad108 Author: Maxime Ripard Date: Fri Sep 7 16:00:22 2018 +0200 ARM: dts: sun7i: Fix HDMI output DTC warning [ Upstream commit 4d9a06979b1ae0c802440cb4433dfcd85fc7bdd3 ] Our HDMI output endpoint on the A10s DTSI has a warning under DTC: "graph node has single child node 'endpoint', #address-cells/#size-cells are not necessary". Fix this by removing those properties. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 05a8d2ab6604943b0349508308c5170c5d940e49 Author: Laurent Pinchart Date: Wed Oct 17 20:48:01 2018 +0300 ARM: dts: r8a779[01]: Disable unconnected LVDS encoders [ Upstream commit 89862542fab10fed8a3c2f9c167622ef4287351d ] The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager, are enabled in DT but have no device connected to their output. This result in spurious messages being printed to the kernel log such as rcar-du feb00000.display: no connector for encoder /soc/lvds@feb90000, skipping Fix it by disabling the encoders. Fixes: 15a1ff30d8f9 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings") Fixes: e5c3f4707f39 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings") Reported-by: Geert Uytterhoeven Signed-off-by: Laurent Pinchart Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 0b3d71d82a852563f8002221820eba6d7d6c55e4 Author: Maxime Ripard Date: Fri Sep 7 16:00:22 2018 +0200 ARM: dts: sun5i: a10s: Fix HDMI output DTC warning [ Upstream commit ed5fc60b909427be6ca93d3e07a0a5f296d7000a ] Our HDMI output endpoint on the A10s DTSI has a warning under DTC: "graph node has single child node 'endpoint', #address-cells/#size-cells are not necessary". Fix this by removing those properties. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit b00d8fc54ab4496bd3d4ba4d680e68b13bbf2e9c Author: Maxime Ripard Date: Fri Sep 7 16:00:22 2018 +0200 ARM: dts: sun4i: Fix HDMI output DTC warning [ Upstream commit 123b796d3fac60d69a3737d81901ab483c4efd6e ] Our HDMI output endpoint on the A10 DTSI has a warning under DTC: "graph node has single child node 'endpoint', #address-cells/#size-cells are not necessary". Fix this by removing those properties. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 6f1560992075b162c3dcf144e6a35922e6b245b5 Author: Maxime Ripard Date: Fri Sep 7 15:59:30 2018 +0200 ARM: dts: sun4i: Fix gpio-keys warning [ Upstream commit c9b543404c5e1fd51a7ac375294519be5064bf80 ] Fix the 'unnecessary #address-cells/#size-cells without "ranges" or child "reg" property' DTC warning for the gpio-keys DT node on A10 boards. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit df799def8c3e91bdc9e37f13ac346ca3e84688ee Author: Kuninori Morimoto Date: Tue Nov 27 07:35:34 2018 +0000 ASoC: rsnd: tidyup registering method for rsnd_kctrl_new() [ Upstream commit 9c698e8481a15237a5b1db5f8391dd66d59e42a4 ] Current rsnd dvc.c is using flags to avoid duplicating register for MIXer case. OTOH, commit e894efef9ac7 ("ASoC: core: add support to card rebind") allows to rebind sound card without rebinding all drivers. Because of above patch and dvc.c flags, it can't re-register kctrl if only sound card was rebinded, because dvc is keeping old flags. (Of course it will be no problem if rsnd driver also be rebinded, but it is not purpose of above patch). This patch checks current card registered kctrl when registering. In MIXer case, it can avoid duplicate register if card already has same kctrl. In rebind case, it can re-register kctrl because card registered kctl had been removed when unbinding. This patch is updated version of commit b918f1bc7f1ce ("ASoC: rsnd: DVC kctrl sets once") Reported-by: Nguyen Viet Dung Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung Cc: Hiroyuki Yokoyama Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d18e7c216a3b348f4b747a73c8e35ce2dc42436c Author: Joerg Roedel Date: Tue Nov 27 16:43:57 2018 +0100 iommu/amd: Fix line-break in error log reporting [ Upstream commit 1a21ee1aabf7ff9484f2eb122476d80c7f60a620 ] With the switch to dev_err for reporting errors from the iommu log there was an unwanted newline introduced. The reason was that the reporting was done in multiple dev_err() calls, and dev_err adds a newline after every call. Fix it by printing the log messages with only one dev_err() call. Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 52cc7ea79741bcd91d5eb093ac6b351a56307493 Author: Xin Long Date: Mon Nov 26 14:52:44 2018 +0800 sctp: increase sk_wmem_alloc when head->truesize is increased [ Upstream commit 0d32f17717e65e76cbdb248374dd162acdfe2fff ] I changed to count sk_wmem_alloc by skb truesize instead of 1 to fix the sk_wmem_alloc leak caused by later truesize's change in xfrm in Commit 02968ccf0125 ("sctp: count sk_wmem_alloc by skb truesize in sctp_packet_transmit"). But I should have also increased sk_wmem_alloc when head->truesize is increased in sctp_packet_gso_append() as xfrm does. Otherwise, sctp gso packet will cause sk_wmem_alloc underflow. Fixes: 02968ccf0125 ("sctp: count sk_wmem_alloc by skb truesize in sctp_packet_transmit") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a2b7010f76ea67963a098095318a9552297478e6 Author: J. Bruce Fields Date: Mon Nov 26 11:36:52 2018 -0500 lockd: fix decoding of TEST results [ Upstream commit b8db159239b3f51e2b909859935cc25cb3ff3eed ] We fail to advance the read pointer when reading the stat.oh field that identifies the lock-holder in a TEST result. This turns out not to matter if the server is knfsd, which always returns a zero-length field. But other servers (Ganesha is an example) may not do this. The result is bad values in fcntl F_GETLK results. Fix this. Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 5f7d707b15885cb039477d91867e653b243f7c2f Author: Thierry Reding Date: Mon Nov 19 11:31:30 2018 +0100 gpu: host1x: Fix syncpoint ID field size on Tegra186 [ Upstream commit 2fc777ba8422e4a38cae61537ad6a26435a86fb8 ] The number of syncpoints on Tegra186 is 576 and therefore no longer fits into 8 bits. Increase the size of the syncpoint ID field to 10 in order to accomodate all syncpoints. Reviewed-by: Mikko Perttunen Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 0dcdd33f8e13380b11965491bdefc29eca3f69ec Author: Neil Armstrong Date: Wed Nov 21 12:19:22 2018 +0100 clk: meson: Fix GXL HDMI PLL fractional bits width [ Upstream commit 21310c39ec01e82ef3ef9bf8ac385b53ccdc158c ] The GXL Documentation specifies 12 bits for the Fractional bit field, bit the last bits have a different purpose that we cannot handle right now, so update the bitwidth to have correct fractional calculations. Signed-off-by: Neil Armstrong [narmstrong: added comment on GXL HHI_HDMI_PLL_CNTL register shift] Acked-by: Martin Blumenstingl Link: https://lkml.kernel.org/r/20181121111922.1277-1-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit a976029de2525fe3a06776f4bb3d62f2c2936d17 Author: Lucas Stach Date: Wed Nov 14 18:29:13 2018 +0100 i2c: imx: don't print error message on probe defer [ Upstream commit fece4978510e43f09c8cd386fee15210e8c68493 ] Probe deferral is a normal operating condition in the probe function, so don't spam the log with an error in this case. Signed-off-by: Lucas Stach Acked-by: Uwe Kleine-König Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 33b629d41c47c0d348b88c5d2dbb3a416e48f294 Author: Stefan Agner Date: Wed Nov 14 18:49:38 2018 +0100 serial: imx: fix error handling in console_setup [ Upstream commit 63fd4b94b948c14eeb27a3bbf50ea0f7f0593bad ] The ipg clock only needs to be unprepared in case preparing per clock fails. The ipg clock has already disabled at the point. Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check") Signed-off-by: Stefan Agner Reviewed-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f6ea3c03ec082abfe2b6519e93f10fe9ec37c5a2 Author: Colin Ian King Date: Sat Nov 24 12:34:10 2018 +0000 altera-stapl: check for a null key before strcasecmp'ing it [ Upstream commit 9ccb645683ef46e3c52c12c088a368baa58447d4 ] Currently the null check on key is occurring after the strcasecmp on the key, hence there is a potential null pointer dereference on key. Fix this by checking if key is null first. Also replace the == 0 check on strcasecmp with just the ! operator. Detected by CoverityScan, CID#1248787 ("Dereference before null check") Fixes: fa766c9be58b ("[media] Altera FPGA firmware download module") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7e82b903dbd5f0295dad4a807ae1faf4ed5461e Author: Srinivas Kandagatla Date: Mon Nov 12 12:25:25 2018 +0000 slimbus: ngd: Fix build error on x86 [ Upstream commit 458a445deb9c9fb13cec46fe9b179a84d2ff514f ] on non DT platforms like x86 of_match_node is set to NULL, dereferencing directly would throw an error. Fix this by doing this in two steps, get the match then the data. Reported-by: Greg KH Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0c40b942f6a99f2ade4d43ed5186bbba1c88d9f6 Author: Niklas Söderlund Date: Wed Aug 29 23:29:21 2018 +0200 dma-mapping: fix return type of dma_set_max_seg_size() [ Upstream commit c9d76d0655c06b8c1f944e46c4fd9e9cf4b331c0 ] The function dma_set_max_seg_size() can return either 0 on success or -EIO on error. Change its return type from unsigned int to int to capture this. Signed-off-by: Niklas Söderlund Reviewed-by: Geert Uytterhoeven Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 0e6ec8b39105ef5f63a9af25a60fc2f7d2a682a2 Author: Keith Busch Date: Mon Nov 26 16:39:47 2018 -0700 nvme: Free ctrl device name on init failure [ Upstream commit d6a2b9535d1e52bea269c138614c4801469d10e1 ] Free the kobject name that was allocated for the controller device on failure rather than its parent. Fixes: d22524a4782a9 ("nvme: switch controller refcounting to use struct device") Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a4d121d90e28daf1619781ee1eb098705a474ec9 Author: David Miller Date: Mon Nov 26 14:52:18 2018 -0800 sparc: Correct ctx->saw_frame_pointer logic. [ Upstream commit e2ac579a7a18bcd9e8cf14cf42eac0b8a2ba6c4b ] We need to initialize the frame pointer register not just if it is seen as a source operand, but also if it is seen as the destination operand of a store or an atomic instruction (which effectively is a source operand). This is exercised by test_verifier's "non-invalid fp arithmetic" Signed-off-by: David S. Miller Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d4926994be7f5669a57ff796cbd3213f4178a40a Author: David Miller Date: Mon Nov 26 13:03:46 2018 -0800 sparc: Fix JIT fused branch convergance. [ Upstream commit c44768a33da81b4a0986e79bbf0588f1a0651dec ] On T4 and later sparc64 cpus we can use the fused compare and branch instruction. However, it can only be used if the branch destination is in the range of a signed 10-bit immediate offset. This amounts to 1024 instructions forwards or backwards. After the commit referenced in the Fixes: tag, the largest possible size program seen by the JIT explodes by a significant factor. As a result of this convergance takes many more passes since the expanded "BPF_LDX | BPF_MSH | BPF_B" code sequence, for example, contains several embedded branch on condition instructions. On each pass, as suddenly new fused compare and branch instances become valid, this makes thousands more in range for the next pass. And so on and so forth. This is most greatly exemplified by "BPF_MAXINSNS: exec all MSH" which takes 35 passes to converge, and shrinks the image by about 64K. To decrease the cost of this number of convergance passes, do the convergance pass before we have the program image allocated, just like other JITs (such as x86) do. Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf") Signed-off-by: David S. Miller Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c8aa27cf7e946da7d6c065dab3dbb7c5325f4b2c Author: Sahitya Tummala Date: Mon Nov 26 13:31:41 2018 +0530 f2fs: fix to allow node segment for GC by ioctl path [ Upstream commit 08ac9a3870f6babb2b1fff46118536ca8a71ef19 ] Allow node type segments also to be GC'd via f2fs ioctl F2FS_IOC_GARBAGE_COLLECT_RANGE. Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2a34b42f08006c630a73610672703fe3969968d8 Author: Otavio Salvador Date: Mon Nov 26 15:35:04 2018 -0200 ARM: dts: rockchip: Assign the proper GPIO clocks for rv1108 [ Upstream commit efc2e0bd9594060915696a418564aefd0270b1d6 ] It is not correct to assign the 24MHz clock oscillator to the GPIO ports. Fix it by assigning the proper GPIO clocks instead. Signed-off-by: Otavio Salvador Tested-by: Fabio Berton Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 42953e7c6b64be38f0ec89e73233bd510b26a5ee Author: Otavio Salvador Date: Mon Nov 26 15:35:03 2018 -0200 ARM: dts: rockchip: Fix the PMU interrupt number for rv1108 [ Upstream commit c955b7aec510145129ca7aaea6ecbf6d748f5ebf ] According to the Rockchip vendor tree the PMU interrupt number is 76, so fix it accordingly. Signed-off-by: Otavio Salvador Tested-by: Fabio Berton Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 313f1fef6650b76d194b2e9071aa64b43194b0c4 Author: Yunlong Song Date: Tue Oct 30 20:37:55 2018 +0800 f2fs: change segment to section in f2fs_ioc_gc_range [ Upstream commit 67b0e42b768c9ddc3fd5ca1aee3db815cfaa635c ] f2fs_ioc_gc_range skips blocks_per_seg each time, however, f2fs_gc moves blocks of section each time, so fix it from segment to section. Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 859c93a04b61de9aa9d75f8f09a7f9ab0b6af3a5 Author: Yunlong Song Date: Wed Oct 24 16:08:30 2018 +0800 f2fs: fix count of seg_freed to make sec_freed correct [ Upstream commit d6c66cd19ef322fe0d51ba09ce1b7f386acab04a ] When sbi->segs_per_sec > 1, and if some segno has 0 valid blocks before gc starts, do_garbage_collect will skip counting seg_freed++, and this will cause seg_freed < sbi->segs_per_sec and finally skip sec_freed++. Signed-off-by: Yunlong Song Signed-off-by: Chao Yu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c1054aeba939e7b14b1dc5137474fc38242cba11 Author: Chao Yu Date: Wed Oct 24 17:24:10 2018 +0800 f2fs: fix to account preflush command for noflush_merge mode [ Upstream commit a8075dc484cf10ebdb07bee2b17322fb0a846309 ] Previously, we only account preflush command for flush_merge mode, so for noflush_merge mode, we can not know in-flight preflush command count, fix it. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2ba4f54b60e149cf447bec8b7136e7f84b74eb26 Author: Alexey Dobriyan Date: Fri Nov 23 23:07:14 2018 +0300 ACPI: fix acpi_find_child_device() invocation in acpi_preset_companion() [ Upstream commit f8c6d1402b89f22a3647705d63cbd171aa19a77e ] acpi_find_child_device() accepts boolean not pointer as last argument. Signed-off-by: Alexey Dobriyan [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 497411c5a43f5778fbd17b12f1c290f3e6bf009c Author: Brian Norris Date: Wed Nov 7 12:40:29 2018 -0800 usb: dwc3: don't log probe deferrals; but do log other error codes [ Upstream commit 408d3ba006af57380fa48858b39f72fde6405031 ] It's not very useful to repeat a bunch of probe deferral errors. And it's also not very useful to log "failed" without telling the error code. Signed-off-by: Brian Norris Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 184bc0d73bdc82ba5a45c6ca94365b9ae7a584f4 Author: Thinh Nguyen Date: Wed Nov 7 17:55:19 2018 -0800 usb: dwc3: debugfs: Properly print/set link state for HS [ Upstream commit 0d36dede457873404becd7c9cb9d0f2bcfd0dcd9 ] Highspeed device and below has different state names than superspeed and higher. Add proper checks and printouts of link states for highspeed and below. Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 5aba77393e6f1e5a09a7bdd6ed8442d18484a399 Author: Breno Leitao Date: Wed Oct 31 11:38:22 2018 -0300 selftests/powerpc: Skip test instead of failing [ Upstream commit eafcd8e3fbad4f426a40ed2b6a8c697c3a4ef36a ] Current core-pkey selftest fails if the test runs without privileges to write into the core pattern file (/proc/sys/kernel/core_pattern). This causes the test to fail and give the impression that the subsystem being tested is broken, when, in fact, the test is being executed without the proper privileges. This is the current error: test: core_pkey tags: git_version:v4.19-3-g9e3363be9bce-dirty Error writing to core_pattern file: Permission denied failure: core_pkey This patch simply skips this test if it runs without the proper privileges, avoiding this undesired failure. CC: Tyrel Datwyler CC: Thiago Jung Bauermann Signed-off-by: Breno Leitao Reviewed-by: Thiago Jung Bauermann Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 104d0d63a1268301c35caca9b701d4b9b1af13e8 Author: Breno Leitao Date: Wed Oct 31 11:38:20 2018 -0300 selftests/powerpc: Allocate base registers [ Upstream commit 5249497a7bb6334fcc128588d6a7e1e21786515a ] Some ptrace selftests are passing input operands using a constraint that can allocate any register for the operand, and using these registers on load/store operations. If the register allocated by the compiler happens to be zero (r0), it might cause an invalid memory address access, since load and store operations consider the content of 0x0 address if the base register is r0, instead of the content of the r0 register. For example: r1 := 0xdeadbeef r0 := 0xdeadbeef ld r2, 0(1) /* will load into r2 the content of r1 address */ ld r2, 0(0) /* will load into r2 the content of 0x0 */ In order to avoid this possible problem, the inline assembly constraint should be aware that these registers will be used as a base register, thus, r0 should not be allocated. Other than that, this patch removes inline assembly operands that are not used by the tests. Signed-off-by: Breno Leitao Reviewed-by: Segher Boessenkool Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit baf4915acc2a9c1e117693da08f9856da64d271d Author: Colin Ian King Date: Sat Nov 24 15:03:02 2018 +0000 net: qualcomm: rmnet: move null check on dev before dereferecing it [ Upstream commit 3c18aa1464f9232d6abac8d7b4540f61b0658d62 ] Currently dev is dereferenced by the call dev_net(dev) before dev is null checked. Fix this by null checking dev before the potential null pointer dereference. Detected by CoverityScan, CID#1462955 ("Dereference before null check") Fixes: 23790ef12082 ("net: qualcomm: rmnet: Allow to configure flags for existing devices") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c2160296f10fe42e74a936e6cf5e6ff99edecf9a Author: Christian Lamparter Date: Sat Nov 17 17:17:21 2018 +0100 dmaengine: dw-dmac: implement dma protection control setting [ Upstream commit 7b0c03ecc42fb223baf015877fee9d517c2c8af1 ] This patch adds a new device-tree property that allows to specify the dma protection control bits for the all of the DMA controller's channel uniformly. Setting the "correct" bits can have a huge impact on the PPC460EX and APM82181 that use this DMA engine in combination with a DesignWare' SATA-II core (sata_dwc_460ex driver). In the OpenWrt Forum, the user takimata reported that: |It seems your patch unleashed the full power of the SATA port. |Where I was previously hitting a really hard limit at around |82 MB/s for reading and 27 MB/s for writing, I am now getting this: | |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 13.65s |user 0m 0.01s |sys 0m 11.89s | |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 8.41s |user 0m 0.01s |sys 0m 4.70s | |This means: 121 MB/s reading and 75 MB/s writing! | |The drive is a WD Green WD10EARX taken from an older MBL Single. |I repeated the test a few times with even larger files to rule out |any caching, I'm still seeing the same great performance. OpenWrt is |now completely on par with the original MBL firmware's performance. Another user And.short reported: |I can report that your fix worked! Boots up fine with two |drives even with more partitions, and no more reboot on |concurrent disk access! A closer look into the sata_dwc_460ex code revealed that the driver did initally set the correct protection control bits. However, this feature was lost when the sata_dwc_460ex driver was converted to the generic DMA driver framework. BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55 BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50 Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver") Reviewed-by: Andy Shevchenko Signed-off-by: Christian Lamparter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cffba72c1a09d973d53b313490a0d065c5f5d8ed Author: Vinod Koul Date: Mon Nov 26 13:34:15 2018 +0530 dmaengine: coh901318: Remove unused variable commit 35faaf0df42d285b40f8a6310afbe096720f7758 upstream. Commit 627469e4445b ("dmaengine: coh901318: Fix a double-lock bug") left flags variable unused, so remove it to fix the warning. drivers/dma/coh901318.c: In function 'coh901318_config': drivers/dma/coh901318.c:1805:16: warning: unused variable 'flags' [-Wunused-variable] unsigned long flags; ^~~~~ Fixes: 627469e4445b ("dmaengine: coh901318: Fix a double-lock bug") Reported-By: Stephen Rothwell Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 213ca8b833cc032336f0061ac814c55623ae49d7 Author: Jia-Ju Bai Date: Tue Nov 6 11:33:48 2018 +0800 dmaengine: coh901318: Fix a double-lock bug [ Upstream commit 627469e4445b9b12e0229b3bdf8564d5ce384dd7 ] The function coh901318_alloc_chan_resources() calls spin_lock_irqsave() before calling coh901318_config(). But coh901318_config() calls spin_lock_irqsave() again in its definition, which may cause a double-lock bug. Because coh901318_config() is only called by coh901318_alloc_chan_resources(), the bug fix is to remove the calls to spin-lock and -unlock functions in coh901318_config(). Signed-off-by: Jia-Ju Bai Reviewed-by: Linus Walleij Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2a35fdf64649c618243fefc24aa154937dc57a7c Author: Hangbin Liu Date: Wed Nov 21 21:52:33 2018 +0800 net/ipv6: re-do dad when interface has IFF_NOARP flag change [ Upstream commit 896585d48e8e9ba44cd1754fbce8537feffcc1a5 ] When we add a new IPv6 address, we should also join corresponding solicited-node multicast address, unless the interface has IFF_NOARP flag, as function addrconf_join_solict() did. But if we remove IFF_NOARP flag later, we do not do dad and add the mcast address. So we will drop corresponding neighbour discovery message that came from other nodes. A typical example is after creating a ipvlan with mode l3, setting up an ipv6 address and changing the mode to l2. Then we will not be able to ping this address as the interface doesn't join related solicited-node mcast address. Fix it by re-doing dad when interface changed IFF_NOARP flag. Then we will add corresponding mcast group and check if there is a duplicate address on the network. Reported-by: Jianlin Shi Reviewed-by: Stefano Brivio Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c0e9153e42ffb168fdfffb7031f36b3b175906a6 Author: Magnus Damm Date: Wed Nov 21 20:21:26 2018 +0900 ravb: Clean up duplex handling [ Upstream commit 08b43857804dd0eca48f5c5a84885cf0079586e0 ] Since only full-duplex operation is supported by the hardware, remove duplex handling code and keep the register setting of ECMR.DM fixed at 1. This updates the driver implementation to follow the data sheet text "This bit should always be set to 1." Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Magnus Damm Reviewed-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 052cedfaba15a2d047fcc9dde1e37d5be33e576a Author: Luca Coelho Date: Sat Aug 4 14:45:42 2018 +0300 iwlwifi: fix cfg structs for 22000 with different RF modules [ Upstream commit b1bbc1a636505ebdd6336ff781e417123226d4f7 ] We have to choose different configuration and different firmwares depending on the external RF module that is installed. Since the external module is not represented in the PCI IDs, we need to change the configuration at runtime, after checking the RF ID of the module installed. We have a bit of a mess in the code that does this, because it applies cfg's according to the RF ID only, ignoring the integrated module that is in use. Fix that for some devices by adding correct configurations for them and not ignoring the integrated module's type when making the decision. Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit bc82b92116d755d377187f49055e1ae5d5ebfc6e Author: Hans Verkuil Date: Tue Oct 16 03:44:20 2018 -0400 media: cec: report Vendor ID after initialization [ Upstream commit 7f02ac77c768ba2bcdd0ce719c1fca0870ffe2fb ] The CEC specification requires that the Vendor ID (if any) is reported after a logical address was claimed. This was never done, so add support for this. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 137ab853ad89f0eb58d437da1a6b1be9e9ce6d74 Author: Hans Verkuil Date: Wed Nov 14 08:25:53 2018 -0500 media: pulse8-cec: return 0 when invalidating the logical address [ Upstream commit 2e84eb9affac43eeaf834992888b72426a8cd442 ] Return 0 when invalidating the logical address. The cec core produces a warning for drivers that do this. Signed-off-by: Hans Verkuil Reported-by: Torbjorn Jansson Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d9e046de6e12f89641408df5c6892e271ab2fce6 Author: Philipp Zabel Date: Tue Nov 6 05:40:54 2018 -0500 media: coda: fix memory corruption in case more than 32 instances are opened [ Upstream commit 649cfc2bdfeeb98ff7d8fdff0af3f8fb9c8da50f ] The ffz() return value is undefined if the instance mask does not contain any zeros. If it returned 32, the following set_bit would corrupt the debugfs_root pointer. Switch to IDA for context index allocation. This also removes the artificial 32 instance limit for all except CodaDx6. Signed-off-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fbb4503e55b8e8a338f2cf8495b440980639b0a3 Author: Marek Szyprowski Date: Tue Nov 20 16:54:28 2018 +0100 ARM: dts: exynos: Use Samsung SoC specific compatible for DWC2 module [ Upstream commit 6035cbcceb069f87296b3cd0bc4736ad5618bf47 ] DWC2 hardware module integrated in Samsung SoCs requires some quirks to operate properly, so use Samsung SoC specific compatible to notify driver to apply respective fixes. Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 0281b46b529a4f648f5fc5aadebc7dab7c4c0c76 Author: Baruch Siach Date: Mon Nov 19 14:34:02 2018 +0200 rtc: dt-binding: abx80x: fix resistance scale [ Upstream commit 73852e56827f5cb5db9d6e8dd8191fc2f2e8f424 ] The abracon,tc-resistor property value is in kOhm. Signed-off-by: Baruch Siach Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit e1669a130f681c47b1ee0d7838c612fdc4ae0a33 Author: Christophe JAILLET Date: Wed Nov 14 18:19:51 2018 +0100 rtc: max8997: Fix the returned value in case of error in 'max8997_rtc_read_alarm()' [ Upstream commit 41ef3878203cd9218d92eaa07df4b85a2cb128fb ] In case of error, we return 0. This is spurious and not consistent with the other functions of the driver. Propagate the error code instead. Signed-off-by: Christophe JAILLET Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit a346307acbc477fd82c64859532482248dd8d601 Author: Nylon Chen Date: Thu Nov 8 19:28:05 2018 +0800 nds32: Fix the items of hwcap_str ordering issue. [ Upstream commit a5234068e6dc18ae5300d678fbf3e129d9b93f78 ] The hwcap_str should be set in a correct order according to HWCAP_xx. We also add the missing "fpu_dp" to it. Signed-off-by: Nylon Chen Acked-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Sasha Levin commit 8f56c6c72013f07856f58cbfa69af946c7ed8c1a Author: Vincent Chen Date: Thu Nov 22 11:14:38 2018 +0800 math-emu/soft-fp.h: (_FP_ROUND_ZERO) cast 0 to void to fix warning [ Upstream commit 83312f1b7ae205dca647bf52bbe2d51303cdedfb ] _FP_ROUND_ZERO is defined as 0 and used as a statemente in macro _FP_ROUND. This generates "error: statement with no effect [-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to fix it. This modification is quoted from glibc 'commit (8ed1e7d5894000c155acbd06f)' Signed-off-by: Vincent Chen Acked-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Sasha Levin commit 78e6704dd6b2848ebc3406d2de1304b387acc779 Author: Ursula Braun Date: Tue Nov 20 16:46:43 2018 +0100 net/smc: use after free fix in smc_wr_tx_put_slot() [ Upstream commit e438bae43c1e08e688c09c410407b59fc1c173b4 ] In smc_wr_tx_put_slot() field pend->idx is used after being cleared. That means always idx 0 is cleared in the wr_tx_mask. This results in a broken administration of available WR send payload buffers. Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7ff2e42795cb68667a484f640fdc0ba21042c7e1 Author: Aaro Koskinen Date: Thu Nov 22 00:37:29 2018 +0200 MIPS: OCTEON: octeon-platform: fix typing [ Upstream commit 2cf1c8933dd93088cfb5f8f58b3bb9bbdf1781b9 ] Use correct type for fdt_property nameoff field. Signed-off-by: Aaro Koskinen Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21204/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@linux-mips.org Signed-off-by: Sasha Levin commit cd69bcc07ac1be675ba976917163318858668d1f Author: Steve Wise Date: Sat Nov 10 05:27:39 2018 -0800 iw_cxgb4: only reconnect with MPAv1 if the peer aborts [ Upstream commit 9828ca654b52848e7eb7dcc9b0994ff130dd4546 ] Only retry connection setup with MPAv1 if the peer actually aborted the connection upon receiving the MPAv2 start message. This avoids retrying with MPAv1 in the case where the connection was aborted due to retransmit timeouts. Fixes: d2fe99e86bb2 ("RDMA/cxgb4: Add support for MPAv2 Enhanced RDMA Negotiation") Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c3a62b651d74fc541989e5c7b20bd3a24c396a50 Author: Dave Chinner Date: Wed Nov 21 08:06:37 2018 -0800 iomap: readpages doesn't zero page tail beyond EOF [ Upstream commit 8c110d43c6bca4b24dd13272a9d4e0ba6f2ec957 ] When we read the EOF page of the file via readpages, we need to zero the region beyond EOF that we either do not read or should not contain data so that mmap does not expose stale data to user applications. However, iomap_adjust_read_range() fails to detect EOF correctly, and so fsx on 1k block size filesystems fails very quickly with mapreads exposing data beyond EOF. There are two problems here. Firstly, when calculating the end block of the EOF byte, we have to round the size by one to avoid a block aligned EOF from reporting a block too large. i.e. a size of 1024 bytes is 1 block, which in index terms is block 0. Therefore we have to calculate the end block from (isize - 1), not isize. The second bug is determining if the current page spans EOF, and so whether we need split it into two half, one for the IO, and the other for zeroing. Unfortunately, the code that checks whether we should split the block doesn't actually check if we span EOF, it just checks if the read spans the /offset in the page/ that EOF sits on. So it splits every read into two if EOF is not page aligned, regardless of whether we are reading the EOF block or not. Hence we need to restrict the "does the read span EOF" check to just the page that spans EOF, not every page we read. This patch results in correct EOF detection through readpages: xfs_vm_readpages: dev 259:0 ino 0x43 nr_pages 24 xfs_iomap_found: dev 259:0 ino 0x43 size 0x66c00 offset 0x4f000 count 98304 type hole startoff 0x13c startblock 1368 blockcount 0x4 iomap_readpage_actor: orig pos 323584 pos 323584, length 4096, poff 0 plen 4096, isize 420864 xfs_iomap_found: dev 259:0 ino 0x43 size 0x66c00 offset 0x50000 count 94208 type hole startoff 0x140 startblock 1497 blockcount 0x5c iomap_readpage_actor: orig pos 327680 pos 327680, length 94208, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 331776 pos 331776, length 90112, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 335872 pos 335872, length 86016, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 339968 pos 339968, length 81920, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 344064 pos 344064, length 77824, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 348160 pos 348160, length 73728, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 352256 pos 352256, length 69632, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 356352 pos 356352, length 65536, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 360448 pos 360448, length 61440, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 364544 pos 364544, length 57344, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 368640 pos 368640, length 53248, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 372736 pos 372736, length 49152, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 376832 pos 376832, length 45056, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 380928 pos 380928, length 40960, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 385024 pos 385024, length 36864, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 389120 pos 389120, length 32768, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 393216 pos 393216, length 28672, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 397312 pos 397312, length 24576, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 401408 pos 401408, length 20480, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 405504 pos 405504, length 16384, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 409600 pos 409600, length 12288, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 413696 pos 413696, length 8192, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 417792 pos 417792, length 4096, poff 0 plen 3072, isize 420864 iomap_readpage_actor: orig pos 420864 pos 420864, length 1024, poff 3072 plen 1024, isize 420864 As you can see, it now does full page reads until the last one which is split correctly at the block aligned EOF, reading 3072 bytes and zeroing the last 1024 bytes. The original version of the patch got this right, but it got another case wrong. The EOF detection crossing really needs to the the original length as plen, while it starts at the end of the block, will be shortened as up-to-date blocks are found on the page. This means "orig_pos + plen" no longer points to the end of the page, and so will not correctly detect EOF crossing. Hence we have to use the length passed in to detect this partial page case: xfs_filemap_fault: dev 259:1 ino 0x43 write_fault 0 xfs_vm_readpage: dev 259:1 ino 0x43 nr_pages 1 xfs_iomap_found: dev 259:1 ino 0x43 size 0x2cc00 offset 0x2c000 count 4096 type hole startoff 0xb0 startblock 282 blockcount 0x4 iomap_readpage_actor: orig pos 180224 pos 181248, length 4096, poff 1024 plen 2048, isize 183296 xfs_iomap_found: dev 259:1 ino 0x43 size 0x2cc00 offset 0x2cc00 count 1024 type hole startoff 0xb3 startblock 285 blockcount 0x1 iomap_readpage_actor: orig pos 183296 pos 183296, length 1024, poff 3072 plen 1024, isize 183296 Heere we see a trace where the first block on the EOF page is up to date, hence poff = 1024 bytes. The offset into the page of EOF is 3072, so the range we want to read is 1024 - 3071, and the range we want to zero is 3072 - 4095. You can see this is split correctly now. This fixes the stale data beyond EOF problem that fsx quickly uncovers on 1k block size filesystems. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 807a59723109cf6e6bc4c081c8e9e505a9143bca Author: Dave Chinner Date: Mon Nov 19 13:31:11 2018 -0800 iomap: dio data corruption and spurious errors when pipes fill [ Upstream commit 4721a6010990971440b4ffefbdf014976b8eda2f ] When doing direct IO to a pipe for do_splice_direct(), then pipe is trivial to fill up and overflow as it can only hold 16 pages. At this point bio_iov_iter_get_pages() then returns -EFAULT, and we abort the IO submission process. Unfortunately, iomap_dio_rw() propagates the error back up the stack. The error is converted from the EFAULT to EAGAIN in generic_file_splice_read() to tell the splice layers that the pipe is full. do_splice_direct() completely fails to handle EAGAIN errors (it aborts on error) and returns EAGAIN to the caller. copy_file_write() then completely fails to handle EAGAIN as well, and so returns EAGAIN to userspace, having failed to copy the data it was asked to. Avoid this whole steaming pile of fail by having iomap_dio_rw() silently swallow EFAULT errors and so do short reads. To make matters worse, iomap_dio_actor() has a stale data exposure bug bio_iov_iter_get_pages() fails - it does not zero the tail block that it may have been left uncovered by partial IO. Fix the error handling case to drop to the sub-block zeroing rather than immmediately returning the -EFAULT error. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit b61fdcdbdad97639dfb9c605ab89e2d33d5d6aa0 Author: Dave Chinner Date: Mon Nov 19 13:31:10 2018 -0800 iomap: sub-block dio needs to zeroout beyond EOF [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ] If we are doing sub-block dio that extends EOF, we need to zero the unused tail of the block to initialise the data in it it. If we do not zero the tail of the block, then an immediate mmap read of the EOF block will expose stale data beyond EOF to userspace. Found with fsx running sub-block DIO sizes vs MAPREAD/MAPWRITE operations. Fix this by detecting if the end of the DIO write is beyond EOF and zeroing the tail if necessary. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit ac3ec5a40ec9b63208d661319536451f0f93f16c Author: Dave Chinner Date: Mon Nov 19 13:31:10 2018 -0800 iomap: FUA is wrong for DIO O_DSYNC writes into unwritten extents [ Upstream commit 0929d8580071c6a1cec1a7916a8f674c243ceee1 ] When we write into an unwritten extent via direct IO, we dirty metadata on IO completion to convert the unwritten extent to written. However, when we do the FUA optimisation checks, the inode may be clean and so we issue a FUA write into the unwritten extent. This means we then bypass the generic_write_sync() call after unwritten extent conversion has ben done and we don't force the modified metadata to stable storage. This violates O_DSYNC semantics. The window of exposure is a single IO, as the next DIO write will see the inode has dirty metadata and hence will not use the FUA optimisation. Calling generic_write_sync() after completion of the second IO will also sync the first write and it's metadata. Fix this by avoiding the FUA optimisation when writing to unwritten extents. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 388682b7bdde5d87fd4c316762677c0c103e728c Author: Bruce Allan Date: Wed Nov 7 10:19:35 2018 -0800 ice: Fix possible NULL pointer de-reference [ Upstream commit f25dad19ba70f7cc135da78ec013325042cd8c52 ] A recent update to smatch is causing it to report the error "we previously assumed 'm_entry->vsi_list_info' could be null". Fix that. Signed-off-by: Bruce Allan Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit e0cf32be082a6ef5688f6d2d66672898ef3cd993 Author: Dave Ertman Date: Fri Oct 26 11:44:43 2018 -0700 ice: Fix return value from NAPI poll [ Upstream commit e0c9fd9b77a7334032ec407d9e14d7c3cac1ac4f ] ice_napi_poll is hard-coded to return zero when it's done. It should instead return the work done (if any work was done). The only time it should return zero is if an interrupt or poll is handled and no work is performed. So change the return value to be the minimum of work done or budget-1. Signed-off-by: Dave Ertman Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit f04eee4042ab74a240fb39daf0e089cf3cee35c5 Author: Xue Chaojing Date: Tue Nov 20 05:47:34 2018 +0000 net-next/hinic: fix a bug in rx data flow [ Upstream commit b1a200484143a727ce293e0f200a543cc7584152 ] In rx_alloc_pkts(), there is a loop call of tasklet, which causes 100% cpu utilization, even no packets are being received. This patch fixes this bug. Signed-off-by: Xue Chaojing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 25c748238d0addec29f3af531ace0a721e16fed8 Author: Xue Chaojing Date: Tue Nov 20 05:47:33 2018 +0000 net-next/hinic:fix a bug in set mac address [ Upstream commit 9ea72dc9430306b77c73a8a21beb51437cde1d6d ] In add_mac_addr(), if the MAC address is a muliticast address, it will not be set, which causes the network card fail to receive the multicast packet. This patch fixes this bug. Signed-off-by: Xue Chaojing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 249279c677aff01d6c4eaa99c1fb0bb6f8edd3f9 Author: Dave Chinner Date: Mon Nov 19 13:31:09 2018 -0800 xfs: extent shifting doesn't fully invalidate page cache [ Upstream commit 7f9f71be84bcab368e58020a42f6d0dd97adf0ce ] The extent shifting code uses a flush and invalidate mechainsm prior to shifting extents around. This is similar to what xfs_free_file_space() does, but it doesn't take into account things like page cache vs block size differences, and it will fail if there is a page that it currently busy. xfs_flush_unmap_range() handles all of these cases, so just convert xfs_prepare_shift() to us that mechanism rather than having it's own special sauce. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 5e28bbc7c8643c3d4b259e50b6b365b3a60db43c Author: Ji-Ze Hong (Peter Hong) Date: Thu Nov 15 10:58:44 2018 +0800 USB: serial: f81534: fix reading old/new IC config [ Upstream commit ab60075f2a4eebca1abb04f712569963fb4d9d6c ] The F81532/534 had a internal configuration space to save & control IC state with address F81534_CUSTOM_ADDRESS_START (0x2f00). Layout as following: +00h: to indicate the section is valid +01h~04h: UART Mode & port availability +05h~08h: Output pin control on IC power on +09h~12h: Output pin control on working <-- New added Old driver will use +05~08h as default on working, but newer IC will configed with shutdown mode(7) in 05h~08h and working mode with RS232(1) in 09h~12h. It'll make mainstream driver not working. This patch will make mainstream driver compatible older and newer IC. If using a old IC, the +05h~08h will be 00h~06h, we'll direct apply it. If using a new IC, the +05h~08h will be 07h or larger, we'll read +09h~12h to apply newer configuration. Signed-off-by: Ji-Ze Hong (Peter Hong) Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit eaef0135705e19f0fb6a6c584757790671aed890 Author: Mark Brown Date: Fri Nov 16 19:19:30 2018 -0800 regulator: Fix return value of _set_load() stub [ Upstream commit f1abf67217de91f5cd3c757ae857632ca565099a ] The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang Signed-off-by: Mark Brown Reviewed-by: Douglas Anderson Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 94b4e528b152d24db7d92db0dfaa4f577d78be3f Author: Xin Long Date: Sun Nov 18 15:07:38 2018 +0800 sctp: count sk_wmem_alloc by skb truesize in sctp_packet_transmit [ Upstream commit 02968ccf0125d39b08ecef5946300a8a873c0942 ] Now sctp increases sk_wmem_alloc by 1 when doing set_owner_w for the skb allocked in sctp_packet_transmit and decreases by 1 when freeing this skb. But when this skb goes through networking stack, some subcomponents might change skb->truesize and add the same amount on sk_wmem_alloc. However sctp doesn't know the amount to decrease by, it would cause a leak on sk->sk_wmem_alloc and the sock can never be freed. Xiumei found this issue when it hit esp_output_head() by using sctp over ipsec, where skb->truesize is added and so is sk->sk_wmem_alloc. Since sctp has used sk_wmem_queued to count for writable space since Commit cd305c74b0f8 ("sctp: use sk_wmem_queued to check for writable space"), it's ok to fix it by counting sk_wmem_alloc by skb truesize in sctp_packet_transmit. Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 959f19ffa49e65c91c7280ded7978c03d90ba6c6 Author: Katsuhiro Suzuki Date: Sun Nov 18 13:18:02 2018 +0900 clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328 [ Upstream commit df7b1f2e0a4ae0fceff261e29cde63dafcf2360f ] This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1 successfully. Signed-off-by: Katsuhiro Suzuki Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 66bee515e3c202397e876861d9e69ff0c1fda532 Author: Katsuhiro Suzuki Date: Sun Nov 18 13:16:12 2018 +0900 clk: rockchip: fix I2S1 clock gate register for rk3328 [ Upstream commit 5c73ac2f8b70834a603eb2d92eb0bb464634420b ] This patch fixes definition of I2S1 clock gate register for rk3328. Current setting is not related I2S clocks. - bit6 of CRU_CLKGATE_CON0 means clk_ddrmon_en - bit6 of CRU_CLKGATE_CON1 means clk_i2s1_en Signed-off-by: Katsuhiro Suzuki Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7d0ef9419d6f2704b1381cbd85ee0b32eb6d751b Author: Janne Huttunen Date: Fri Nov 16 15:08:32 2018 -0800 mm/vmstat.c: fix NUMA statistics updates [ Upstream commit 13c9aaf7fa01cc7600c61981609feadeef3354ec ] Scan through the whole array to see if an update is needed. While we're at it, use sizeof() to be safe against any possible type changes in the future. The bug here is that we wouldn't sync per-cpu counters into global ones if there was an update of numa_stats for higher cpus. Highly theoretical one though because it is much more probable that zone_stats are updated so we would refresh anyway. So I wouldn't bother to mark this for stable, yet something nice to fix. [mhocko@suse.com: changelog enhancement] Link: http://lkml.kernel.org/r/1541601517-17282-1-git-send-email-janne.huttunen@nokia.com Fixes: 1d90ca897cb0 ("mm: update NUMA counter threshold size") Signed-off-by: Janne Huttunen Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 20148a17cd0203ab4e90730055579c04cb1436cb Author: James Hughes Date: Fri Nov 16 14:39:07 2018 +0000 firmware: raspberrypi: Fix firmware calls with large buffers [ Upstream commit 91c6ada69f396e663acb2b713e8acb8a9463557d ] Commit a1547e0bca51 ("firmware: raspberrypi: Remove VLA usage") moved away from VLA's to a fixed maximum size for mailbox data. However, some mailbox calls use larger data buffers than the maximum allowed in that change. This fix therefor moves from using fixed buffers to kmalloc to ensure all sizes are catered for. There is some documentation, which is somewhat out of date, on the mailbox calls here : https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface Fixes: a1547e0bca51 ("firmware: raspberrypi: Remove VLA usage") Signed-off-by: James Hughes Reviewed-by: Eric Anholt Signed-off-by: Stefan Wahren Signed-off-by: Sasha Levin commit b0db2672b398f16aa982807615e20639d23e3a34 Author: Shreeya Patel Date: Sat Nov 17 04:19:07 2018 +0530 Staging: iio: adt7316: Fix i2c data reading, set the data field [ Upstream commit 688cd642ba0c393344c802647848da5f0d925d0e ] adt7316_i2c_read function nowhere sets the data field. It is necessary to have an appropriate value for it. Hence, assign the value stored in 'ret' variable to data field. This is an ancient bug, and as no one seems to have noticed, probably no sense in applying it to stable. Signed-off-by: Shreeya Patel Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 095fe9307550b70ea35432f540be1a71cd9aba23 Author: Brian Masney Date: Sat Nov 10 20:34:11 2018 -0500 pinctrl: qcom: ssbi-gpio: fix gpio-hog related boot issues [ Upstream commit 7ed07855773814337b9814f1c3e866df52ebce68 ] When attempting to setup up a gpio hog, device probing will repeatedly fail with -EPROBE_DEFERED errors. It is caused by a circular dependency between the gpio and pinctrl frameworks. If the gpio-ranges property is present in device tree, then the gpio framework will handle the gpio pin registration and eliminate the circular dependency. See Christian Lamparter's commit a86caa9ba5d7 ("pinctrl: msm: fix gpio-hog related boot issues") for a detailed commit message that explains the issue in much more detail. The code comment in this commit came from Christian's commit. I did not test this change against any hardware supported by this particular driver, however I was able to validate this same fix works for pinctrl-spmi-gpio.c using a LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 702155b1f84ebee8d0a38e335b72d860a2b79d85 Author: Michal Simek Date: Thu Nov 8 10:06:53 2018 +0100 arm64: dts: zynqmp: Fix node names which contain "_" [ Upstream commit d1d4445abffb2b17e841d37b555b6f1364b571c1 ] s/_/-/ for node names. It fixes warnings like this: ... Warning (node_name_chars_strict): /cpu_opp_table: Character '_' not recommended in node name ... Issues reported by make dtbs W=12 Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit b0465a7187368f8e12221cb82f3f4c5e799569f1 Author: Raveendra Padasalagi Date: Tue Nov 6 13:58:58 2018 +0530 crypto: bcm - fix normal/non key hash algorithm failure [ Upstream commit 4f0129d13e69bad0363fd75553fb22897b32c379 ] Remove setkey() callback handler for normal/non key hash algorithms and keep it for AES-CBC/CMAC which needs key. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a2b797bbec6f7dffcee554f5a7398f510d36e16d Author: Vitaly Chikunov Date: Mon Nov 5 11:36:18 2018 +0300 crypto: ecc - check for invalid values in the key verification test [ Upstream commit 2eb4942b6609d35a4e835644a33203b0aef7443d ] Currently used scalar multiplication algorithm (Matthieu Rivain, 2011) have invalid values for scalar == 1, n-1, and for regularized version n-2, which was previously not checked. Verify that they are not used as private keys. Signed-off-by: Vitaly Chikunov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f38b78cf6f7dc39722f55003c10abf9f8695a97b Author: Lucas Stach Date: Mon Nov 5 18:31:56 2018 +0100 ARM: dts: imx6: RDU2: fix eGalax touchscreen node [ Upstream commit 749a5068f2e2453a38777b1d5fc322d503cabf1d ] Use the correct compatible for the new protocol used by the firmware on the touch controller, the GPIO wakeup isn't used in that case. Also eGalax touch needs axis swapping, just as with the RMI4 touch. Signed-off-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 65930054756acfbacddf6f80bd55a6f23a8937f6 Author: Tony Lindgren Date: Thu Nov 15 14:46:52 2018 -0800 bus: ti-sysc: Fix getting optional clocks in clock_roles [ Upstream commit 7b4f8ac2f1acdff3c0cce23d8c3b86434a6e768a ] We can have holes in clock_roles with interface clock missing for example. Currently getting an optional clock will fail if there are only a functional clock and an optional clock. Fixes: 09dfe5810762 ("bus: ti-sysc: Add handling for clkctrl opt clocks") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit ed973f15f445352cd92efadfa47135c237561b5e Author: Maxime Jourdan Date: Mon Nov 12 17:46:54 2018 +0100 drivers: soc: Allow building the amlogic drivers without ARCH_MESON [ Upstream commit 41bb5769b7f4b7a85e4b92c37429228279b4f569 ] The current condition makes it difficult to compile the amlogic/ drivers with COMPILE_TEST, or without ARCH_MESON in general. Fixes kbuild errors with patch series that depend on drivers in that directory, for instance the meson video decoder. Signed-off-by: Maxime Jourdan Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 45c2f3f7e1a1e47502b70694d4957f19ec30a9a3 Author: Steffen Maier Date: Thu Nov 8 15:44:57 2018 +0100 scsi: zfcp: drop default switch case which might paper over missing case [ Upstream commit 0c902936e55cff9335b27ed632fc45e7115ced75 ] This was introduced with v4.18 commit 8c3d20aada70 ("scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED") but would now suppress helpful -Wswitch compiler warnings when building with W=1 such as the following forced example: drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_handle_failed': drivers/s390/scsi/zfcp_erp.c:126:2: warning: enumeration value 'ZFCP_ERP_ACTION_REOPEN_PORT_FORCED' not handled in switch [-Wswitch] switch (want) { ^~~~~~ But then again, only with W=1 we would notice unhandled enum cases. Without the default cases and a missed unhandled enum case, the code might perform unforeseen things we might not want... As of today, we never run through the removed default case, so removing it is no functional change. In the future, we never should run through a default case but introduce the necessary specific case(s) to handle new functionality. Signed-off-by: Steffen Maier Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 96f4a86c4bf76f990c39e318322c934b4396298a Author: Steffen Maier Date: Thu Nov 8 15:44:47 2018 +0100 scsi: zfcp: update kernel message for invalid FCP_CMND length, it's not the CDB [ Upstream commit 724e144387f4d7e7668d3da913d0efc44a9b4664 ] The CDB is just a part inside of FCP_CMND, see zfcp_fc_scsi_to_fcp(). While at it, fix the device driver reaction: adapter not LUN shutdown. Signed-off-by: Steffen Maier Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 381b6e9257dc10199142763aaf26488262b726a4 Author: Andrew Lunn Date: Mon Nov 12 18:51:01 2018 +0100 net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2 [ Upstream commit ddc49acb659a2d8bfc5fdb0de0ef197712c11d75 ] We already have a workaround for a couple of switches whose internal PHYs only have the Marvel OUI, but no model number. We detect such PHYs and give them the 6390 ID as the model number. However the mv88e6161 has two SERDES interfaces in the same address range as its internal PHYs. These suffer from the same problem, the Marvell OUI, but no model number. As a result, these SERDES interfaces were getting the same PHY ID as the mv88e6390, even though they are not PHYs, and the Marvell PHY driver was trying to drive them. Add a special case to stop this from happen. Reported-by: Chris Healy Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1181b6965fe36a96b2c8e6aa922ba3039e516ca5 Author: Maciej W. Rozycki Date: Tue Nov 13 22:42:37 2018 +0000 MIPS: SiByte: Enable ZONE_DMA32 for LittleSur [ Upstream commit 756d6d836dbfb04a5a486bc2ec89397aa4533737 ] The LittleSur board is marked for high memory support and therefore clearly must provide a way to have enough memory installed for some to be present outside the low 4GiB physical address range. With the memory map of the BCM1250 SOC it has been built around it means over 1GiB of actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical address range[1]. Complement commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") then and also enable ZONE_DMA32 for LittleSur. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Reviewed-by: Christoph Hellwig Patchwork: https://patchwork.linux-mips.org/patch/21107/ Fixes: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit 1bcac298b943ebe41143f2b8ccb6ffd1d77155b9 Author: David Teigland Date: Thu Nov 15 11:17:40 2018 -0600 dlm: fix missing idr_destroy for recover_idr [ Upstream commit 8fc6ed9a3508a0435b9270c313600799d210d319 ] Which would leak memory for the idr internals. Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 8b01af683df2b381dfbd232455711cfbf2386b50 Author: John Keeping Date: Tue Nov 13 15:24:13 2018 +0000 ARM: dts: rockchip: Fix rk3288-rock2 vcc_flash name [ Upstream commit 03d9f8fa2bfdc791865624d3adc29070cf67814e ] There is no functional change from this, but it is confusing to find two copies of vcc_sys and no vcc_flash when looking in /sys/class/regulator/*/name. Signed-off-by: John Keeping Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e9ad6c940e1b1358615b9b2acd49ed9d7c6622af Author: Heiko Stuebner Date: Thu Nov 15 12:17:30 2018 +0100 clk: rockchip: fix rk3188 sclk_mac_lbtest parameter ordering [ Upstream commit ac8cb53829a6ba119082e067f5bc8fab3611ce6a ] Similar to commit a9f0c0e56371 ("clk: rockchip: fix rk3188 sclk_smc gate data") there is one other gate clock in the rk3188 clock driver with a similar wrong ordering, the sclk_mac_lbtest. So fix it as well. Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d499bc748dbb805dcbb75d8436e0f5ec944475d3 Author: Finley Xiao Date: Wed Nov 14 15:45:49 2018 +0000 clk: rockchip: fix rk3188 sclk_smc gate data [ Upstream commit a9f0c0e563717b9f63b3bb1c4a7c2df436a206d9 ] Fix sclk_smc gate data. Change variable order, flags come before the register address. Signed-off-by: Finley Xiao Signed-off-by: Johan Jonker Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d5be9df0679440bdca7412e2c303aca1f561696a Author: Alice Michael Date: Fri Oct 26 14:33:31 2018 -0700 virtchnl: Fix off by one error [ Upstream commit 843faff87af261bf55eda719a06087af0486a168 ] When calculating the valid length for a VIRTCHNL_OP_ENABLE_CHANNELS message, we accidentally allowed messages with one extra virtchnl_channel_info structure on the end. This happened due to an off by one error, because we forgot that valid_len already accounted for one virtchnl_channel_info structure, so we need to subtract one from the num_tc value. Signed-off-by: Alice Michael Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit ea962fa132b6633479835b83aeb7944c958ccb8d Author: Mitch Williams Date: Fri Oct 26 14:33:28 2018 -0700 i40e: don't restart nway if autoneg not supported [ Upstream commit 7c3758f7839377ab67529cc50264a640636c47af ] On link types that do not support autoneg, we cannot attempt to restart nway negotiation. This results in a dead link that requires a power cycle to remedy. Fix this by saving off the autoneg state and checking this value before we try to restart nway. Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 2538bbb0daf6cd31bdd9675b10eb0974330ba6ba Author: Christophe JAILLET Date: Wed Nov 14 00:36:45 2018 +0100 rtc: max77686: Fix the returned value in case of error in 'max77686_rtc_read_time()' [ Upstream commit b28cc6cec3d814f5184cbebb2d1f987e769f534a ] In case of error, we return 0. This is spurious and not consistent with the other functions of the driver. Commit e115a2bf1426 has modified more than what is said in the commit message. Reverse part of it znd return an error when needed, as it was previously. Fixes: e115a2bf1426 ("rtc: max77686: stop validating rtc_time in .read_time") Signed-off-by: Christophe JAILLET Reviewed-by: Chanwoo Choi Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit eb5b255e3c29a2b32ee354d0b3a4ae0d5bc5291e Author: Marek Szyprowski Date: Tue Nov 13 12:32:50 2018 +0100 rtc: s3c-rtc: Avoid using broken ALMYEAR register [ Upstream commit 50c8aec4212a966817e868056efc9bfbb73337c0 ] (RTC,ALM)YEAR registers of Exynos built-in RTC device contains 3 BCD characters. s3c-rtc driver uses only 2 lower of them and supports years from 2000..2099 range. The third BCD value is typically set to 0, but it looks that handling of it is broken in the hardware. It sometimes defaults to a random (even non-BCD) value. This is not an issue for handling RTCYEAR register, because bcd2bin() properly handles only 8bit values (2 BCD characters, the third one is skipped). The problem is however with ALMYEAR register and proper RTC alarm operation. When YEAREN bit is set for the configured alarm, RTC hardware triggers alarm only when ALMYEAR and RTCYEAR matches. This usually doesn't happen because of the random noise on the third BCD character. Fix this by simply skipping setting ALMYEAR register in alarm configuration. This workaround fixes broken alarm operation on Exynos built-in rtc device. My tests revealed that the issue happens on the following Exynos series: 3250, 4210, 4412, 5250 and 5410. Signed-off-by: Marek Szyprowski Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 22a6ec0ab11768b78742fcc2d2f05f3af2836fb3 Author: Ivan Khoronzhuk Date: Mon Nov 12 16:00:20 2018 +0200 net: ethernet: ti: cpts: correct debug for expired txq skb [ Upstream commit d0e14c4d9bcef0d4aa1057d2959adaa6f18d4a17 ] The msgtype and seqid that is smth that belongs to event for comparison but not for staled txq skb. Signed-off-by: Ivan Khoronzhuk Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 644fde1c387f63047fba9c95a72bc9a0f080cbde Author: Marek Szyprowski Date: Tue Nov 13 16:38:47 2018 +0100 extcon: max8997: Fix lack of path setting in USB device mode [ Upstream commit a2dc50914744eea9f83a70a5db0486be625e5dc0 ] MAX8997 driver disables automatic path selection from MicroUSB connector and manually sets path to either UART or USB lines. However the code for setting USB path worked only for USB host mode (when ID pin is set to ground). When standard USB cable (USB device mode) is connected, path registers are not touched. This means that once the non-USB accessory is connected to MAX8997-operated micro USB port, the path is no longer set to USB and USB device mode doesn't work. This patch fixes it by setting USB path both for USB and USB host modes. Signed-off-by: Marek Szyprowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 2c0ba7706a2cd4fa625316f5220e04189c383367 Author: Anand Moon Date: Thu Sep 27 14:07:34 2018 +0000 ARM: dts: exynos: Fix LDO13 min values on Odroid XU3/XU4/HC1 [ Upstream commit 8fe325fa9d065aa54db4914fdaccab2169fd67a8 ] From Odroid XU3/XU4/HC1 schematics the LDO13 regulator for SD2, can be set on 1.8V or 2.8V so the minimal value should be fixed to 1.8V. This is necessary to support UHS-I tuning (otherwise card won't be detected during boot). Signed-off-by: Anand Moon Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit ed22415081ed7d76846d50d8bfa5b30eeb3ad830 Author: Denis V. Lunev Date: Tue Nov 13 20:39:50 2018 +0300 dlm: fix possible call to kfree() for non-initialized pointer [ Upstream commit 58a923adf4d9aca8bf7205985c9c8fc531c65d72 ] Technically dlm_config_nodes() could return error and keep nodes uninitialized. After that on the fail path of we'll call kfree() for that uninitialized value. The patch is simple - we should just initialize nodes with NULL. Signed-off-by: Denis V. Lunev Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit fd12b061f2b9270854f3dfc18dec1b087a61764e Author: Lev Faerman Date: Fri Oct 26 10:41:05 2018 -0700 ice: Fix NVM mask defines [ Upstream commit 6263e811f4d4418660c20b36a08063c6d2c3fb9d ] Fixes bad masks that would break compilation when evaluated. Signed-off-by: Lev Faerman Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit ac3750e9bfe1cc656ce6b868d4cf90ea2c6c038d Author: Jagan Teki Date: Tue Nov 13 16:46:08 2018 +0530 clk: sunxi-ng: a64: Fix gate bit of DSI DPHY [ Upstream commit ee678706e46d0d185c27cc214ad97828e0643159 ] DSI DPHY gate bit on MIPI DSI clock register is bit 15 not bit 30. Signed-off-by: Jagan Teki Acked-by: Stephen Boyd Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit a26a44691eee2667fd9ec92ce1f9867c4953c87c Author: Moni Shoua Date: Thu Nov 8 21:10:08 2018 +0200 net/mlx5: Release resource on error flow [ Upstream commit 698114968a22f6c0c9f42e983ba033cc36bb7217 ] Fix reference counting leakage when the event handler aborts due to an unsupported event for the resource type. Fixes: a14c2d4beee5 ("net/mlx5_core: Warn on unsupported events of QP/RQ/SQ") Signed-off-by: Moni Shoua Reviewed-by: Majd Dibbiny Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 705d1e733142b188b6b98f707c8e78b3badf13db Author: Eugeniy Paltsev Date: Thu Oct 4 16:12:12 2018 +0300 ARC: IOC: panic if kernel was started with previously enabled IOC [ Upstream commit 3624379d90ad2b65f9dbb30d7f7ce5498d2fe322 ] If IOC was already enabled (due to bootloader) it technically needs to be reconfigured with aperture base,size corresponding to Linux memory map which will certainly be different than uboot's. But disabling and reenabling IOC when DMA might be potentially active is tricky business. To avoid random memory issues later, just panic here and ask user to upgrade bootloader to one which doesn't enable IOC This was actually seen as issue on some of the HSDK board with a version of uboot which enabled IOC. There were random issues later with starting of X or peripherals etc. Also while I'm at it, replace hardcoded bits in ARC_REG_IO_COH_PARTIAL and ARC_REG_IO_COH_ENABLE registers by definitions. Inspired by: https://lkml.org/lkml/2018/1/19/557 Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 2d484087a00c267c25ad33b2e09ac6cfe48457e8 Author: Florian Westphal Date: Sun Nov 4 12:07:14 2018 +0100 netfilter: nf_tables: don't use position attribute on rule replacement [ Upstream commit 447750f281abef547be44fdcfe3bc4447b3115a8 ] Its possible to set both HANDLE and POSITION when replacing a rule. In this case, the rule at POSITION gets replaced using the userspace-provided handle. Rule handles are supposed to be generated by the kernel only. Duplicate handles should be harmless, however better disable this "feature" by only checking for the POSITION attribute on insert operations. Fixes: 5e94846686d0 ("netfilter: nf_tables: add insert operation") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6ce317fdc212aa0cae3c0b375d6273161caad2e5 Author: Jan Kara Date: Mon Nov 12 09:54:48 2018 -0500 audit: Embed key into chunk [ Upstream commit 8d20d6e9301d7b3777d66d47dd5b89acd645cd39 ] Currently chunk hash key (which is in fact pointer to the inode) is derived as chunk->mark.conn->obj. It is tricky to make this dereference reliable for hash table lookups only under RCU as mark can get detached from the connector and connector gets freed independently of the running lookup. Thus there is a possible use after free / NULL ptr dereference issue: CPU1 CPU2 untag_chunk() ... audit_tree_lookup() list_for_each_entry_rcu(p, list, hash) { list_del_rcu(&chunk->hash); fsnotify_destroy_mark(entry); fsnotify_put_mark(entry) chunk_to_key(p) if (!chunk->mark.connector) ... hlist_del_init_rcu(&mark->obj_list); if (hlist_empty(&conn->list)) { inode = fsnotify_detach_connector_from_object(conn); mark->connector = NULL; ... frees connector from workqueue chunk->mark.connector->obj This race is probably impossible to hit in practice as the race window on CPU1 is very narrow and CPU2 has a lot of code to execute. Still it's better to have this fixed. Since the inode the chunk is attached to is constant during chunk's lifetime it is easy to cache the key in the chunk itself and thus avoid these issues. Reviewed-by: Richard Guy Briggs Signed-off-by: Jan Kara Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit b8252ec6ddd1067e6fce5abc84f7f15f5830b619 Author: Vincent Whitchurch Date: Fri Nov 9 10:12:30 2018 +0100 ARM: 8813/1: Make aligned 2-byte getuser()/putuser() atomic on ARMv6+ [ Upstream commit 344eb5539abf3e0b6ce22568c03e86450073e097 ] getuser() and putuser() (and there underscored variants) use two strb[t]/ldrb[t] instructions when they are asked to get/put 16-bits. This means that the read/write is not atomic even when performed to a 16-bit-aligned address. This leads to problems with vhost: vhost uses __getuser() to read the vring's 16-bit avail.index field, and if it happens to observe a partial update of the index, wrong descriptors will be used which will lead to a breakdown of the virtio communication. A similar problem exists for __putuser() which is used to write to the vring's used.index field. The reason these functions use strb[t]/ldrb[t] is because strht/ldrht instructions did not exist until ARMv6T2/ARMv7. So we should be easily able to fix this on ARMv7. Also, since all ARMv6 processors also don't actually use the unprivileged instructions anymore for uaccess (since CONFIG_CPU_USE_DOMAINS is not used) we can easily fix them too. Signed-off-by: Vincent Whitchurch Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d0426a344cf62993d1427035223f616fc1a6be0f Author: Andrei Otcheretianski Date: Tue Jul 24 21:57:50 2018 +0300 iwlwifi: mvm: Send non offchannel traffic via AP sta [ Upstream commit dc1aca22f8f38b7e2ad7b118db87404d11e68771 ] TDLS discovery response frame is a unicast direct frame to the peer. Since we don't have a STA for this peer, this frame goes through iwl_tx_skb_non_sta(). As the result aux_sta and some completely arbitrary queue would be selected for this frame, resulting in a queue hang. Fix that by sending such frames through AP sta instead. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 698d71cba6873d6bc4627e6af291aeec51edc6de Author: Shahar S Matityahu Date: Wed Jul 4 15:31:36 2018 +0300 iwlwifi: trans: Clear persistence bit when starting the FW [ Upstream commit 8954e1eb2270fa2effffd031b4839253952c76f2 ] In D3 suspend flow in 9260 gen2 HW, the NIC receives two PERST signals. The first PERST is expected and indicates the device on coming resume flow. The second PERST causes FW restart FW restart. In order to avoid this issue, the FW set the persistence bit on. Once this bit is set, the FW ignores reset attempts. The problem is when the FW gets assert during D3 and then the persistence bit is set and causes the FW to ignore reset. To handle this issue, the FW opens the preg bit which allows access to the persistence bit, so that the driver clear the persistence bit and reset the NIC. The flow is as follows: the driver checks if the persistence bit is set. If the bit is set, the driver checks if he can clear the bit. If the driver can not clear the bit then there is no point to continue configuring the NIC since it will fail. The fix was added is in start HW flow instead of the resume flow since in general, if the persistence bit is set, the driver can not start the FW. So it is good to check it when we start configuring the NIC. The driver does not need to close the preg bit since the FW close it during the start flow. Signed-off-by: Shahar S Matityahu Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 26632a077366e3b929076dc1105f15e000379691 Author: Johannes Berg Date: Wed Jul 4 23:12:33 2018 +0200 iwlwifi: mvm: synchronize TID queue removal [ Upstream commit 06bc6f6ed4ae0246a5e52094d1be90906a1361c7 ] When we mark a TID as no longer having a queue, there's no guarantee the TX path isn't using this txq_id right now, having accessed it just before we reset the value. To fix this, add synchronize_net() when we change the TIDs from having a queue to not having one, so that we can then be sure that the TX path is no longer accessing that queue. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit cdec9eec4e356fef3805c854ceb90e72887d63e1 Author: Arjun Vynipadath Date: Fri Nov 9 14:52:01 2018 +0530 cxgb4vf: fix memleak in mac_hlist initialization [ Upstream commit 24357e06ba511ad874d664d39475dbb01c1ca450 ] mac_hlist was initialized during adapter_up, which will be called every time a vf device is first brought up, or every time when device is brought up again after bringing all devices down. This means our state of previous list is lost, causing a memleak if entries are present in the list. To fix that, move list init to the condition that performs initial one time adapter setup. Signed-off-by: Arjun Vynipadath Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2c299a22f47c3891b3ab3e1266be50e89ac7150d Author: Douglas Anderson Date: Tue Oct 30 15:11:04 2018 -0700 serial: core: Allow processing sysrq at port unlock time [ Upstream commit d6e1935819db0c91ce4a5af82466f3ab50d17346 ] Right now serial drivers process sysrq keys deep in their character receiving code. This means that they've already grabbed their port->lock spinlock. This can end up getting in the way if we've go to do serial stuff (especially kgdb) in response to the sysrq. Serial drivers have various hacks in them to handle this. Looking at '8250_port.c' you can see that the console_write() skips locking if we're in the sysrq handler. Looking at 'msm_serial.c' you can see that the port lock is dropped around uart_handle_sysrq_char(). It turns out that these hacks aren't exactly perfect. If you have lockdep turned on and use something like the 8250_port hack you'll get a splat that looks like: WARNING: possible circular locking dependency detected [...] is trying to acquire lock: ... (console_owner){-.-.}, at: console_unlock+0x2e0/0x5e4 but task is already holding lock: ... (&port_lock_key){-.-.}, at: serial8250_handle_irq+0x30/0xe4 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x58/0x70 serial8250_console_write+0xa8/0x250 univ8250_console_write+0x40/0x4c console_unlock+0x528/0x5e4 register_console+0x2c4/0x3b0 uart_add_one_port+0x350/0x478 serial8250_register_8250_port+0x350/0x3a8 dw8250_probe+0x67c/0x754 platform_drv_probe+0x58/0xa4 really_probe+0x150/0x294 driver_probe_device+0xac/0xe8 __driver_attach+0x98/0xd0 bus_for_each_dev+0x84/0xc8 driver_attach+0x2c/0x34 bus_add_driver+0xf0/0x1ec driver_register+0xb4/0x100 __platform_driver_register+0x60/0x6c dw8250_platform_driver_init+0x20/0x28 ... -> #0 (console_owner){-.-.}: lock_acquire+0x1e8/0x214 console_unlock+0x35c/0x5e4 vprintk_emit+0x230/0x274 vprintk_default+0x7c/0x84 vprintk_func+0x190/0x1bc printk+0x80/0xa0 __handle_sysrq+0x104/0x21c handle_sysrq+0x30/0x3c serial8250_read_char+0x15c/0x18c serial8250_rx_chars+0x34/0x74 serial8250_handle_irq+0x9c/0xe4 dw8250_handle_irq+0x98/0xcc serial8250_interrupt+0x50/0xe8 ... other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&port_lock_key); lock(console_owner); lock(&port_lock_key); lock(console_owner); *** DEADLOCK *** The hack used in 'msm_serial.c' doesn't cause the above splats but it seems a bit ugly to unlock / lock our spinlock deep in our irq handler. It seems like we could defer processing the sysrq until the end of the interrupt handler right after we've unlocked the port. With this scheme if a whole batch of sysrq characters comes in one irq then we won't handle them all, but that seems like it should be a fine compromise. Signed-off-by: Douglas Anderson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c3563c3ed77d0d8667640b3645c7753b1854d8fc Author: Wen Yang Date: Fri Nov 8 16:36:48 2019 +0800 i2c: core: fix use after free in of_i2c_notify [ Upstream commit a4c2fec16f5e6a5fee4865e6e0e91e2bc2d10f37 ] We can't use "adap->dev" after it has been freed. Fixes: 5bf4fa7daea6 ("i2c: break out OF support into separate file") Signed-off-by: Wen Yang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d228e1e35419df3ca9ca58f81e80f6055ea5fe5b Author: Chuhong Yuan Date: Thu Nov 14 23:43:24 2019 +0800 net: ep93xx_eth: fix mismatch of request_mem_region in remove [ Upstream commit 3df70afe8d33f4977d0e0891bdcfb639320b5257 ] The driver calls release_resource in remove to match request_mem_region in probe, which is incorrect. Fix it by using the right one, release_mem_region. Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6eb6e800188e7363d959bd68e55c750c59707730 Author: Chuhong Yuan Date: Wed Nov 13 14:38:47 2019 +0800 rsxx: add missed destroy_workqueue calls in remove [ Upstream commit dcb77e4b274b8f13ac6482dfb09160cd2fae9a40 ] The driver misses calling destroy_workqueue in remove like what is done when probe fails. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a806e2a35dc10f77765ed5b0efaa460ab899779c Author: Vitaly Kuznetsov Date: Wed Nov 13 13:51:15 2019 +0100 selftests: kvm: fix build with glibc >= 2.30 [ Upstream commit e37f9f139f62deddff90c7298ae3a85026a71067 ] Glibc-2.30 gained gettid() wrapper, selftests fail to compile: lib/assert.c:58:14: error: static declaration of ‘gettid’ follows non-static declaration 58 | static pid_t gettid(void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from include/test_util.h:18, from lib/assert.c:10: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 15479dd156acd90b709b31893567e83f0386c3c0 Author: Yunhao Tian Date: Wed Nov 13 13:27:25 2019 +0000 drm/sun4i: tcon: Set min division of TCON0_DCLK to 1. [ Upstream commit 0b8e7bbde5e7e2c419567e1ee29587dae3b78ee3 ] The datasheet of V3s (and various other chips) wrote that TCON0_DCLK_DIV can be >= 1 if only dclk is used, and must >= 6 if dclk1 or dclk2 is used. As currently neither dclk1 nor dclk2 is used (no writes to these bits), let's set minimal division to 1. If this minimal division is 6, some common dot clock frequencies can't be produced (e.g. 30MHz will not be possible and will fallback to 25MHz), which is obviously not an expected behaviour. Signed-off-by: Yunhao Tian Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/linux-arm-kernel/MN2PR08MB57905AD8A00C08DA219377C989760@MN2PR08MB5790.namprd08.prod.outlook.com/ Signed-off-by: Sasha Levin commit e41ca81e46b957a9f46bad0b3cf7e38f2ad110d1 Author: paulhsia Date: Wed Nov 13 01:17:14 2019 +0800 ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed() [ Upstream commit f5cdc9d4003a2f66ea57b3edd3e04acc2b1a4439 ] If the nullity check for `substream->runtime` is outside of the lock region, it is possible to have a null runtime in the critical section if snd_pcm_detach_substream is called right before the lock. Signed-off-by: paulhsia Link: https://lore.kernel.org/r/20191112171715.128727-2-paulhsia@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 78a917bea6ede80a0635a4fb4f87d713bb6fbeb1 Author: Alexander Shishkin Date: Tue Nov 5 09:57:02 2019 +0200 perf/core: Consistently fail fork on allocation failures [ Upstream commit 697d877849d4b34ab58d7078d6930bad0ef6fc66 ] Commit: 313ccb9615948 ("perf: Allocate context task_ctx_data for child event") makes the inherit path skip over the current event in case of task_ctx_data allocation failure. This, however, is inconsistent with allocation failures in perf_event_alloc(), which would abort the fork. Correct this by returning an error code on task_ctx_data allocation failure and failing the fork in that case. Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Jiri Olsa Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mark Rutland Cc: Namhyung Kim Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: https://lkml.kernel.org/r/20191105075702.60319-1-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 870083b6af3585601b69232f2ffdd362ac1bde7b Author: Peter Zijlstra Date: Tue Oct 1 11:18:37 2019 +0200 sched/core: Avoid spurious lock dependencies [ Upstream commit ff51ff84d82aea5a889b85f2b9fb3aa2b8691668 ] While seemingly harmless, __sched_fork() does hrtimer_init(), which, when DEBUG_OBJETS, can end up doing allocations. This then results in the following lock order: rq->lock zone->lock.rlock batched_entropy_u64.lock Which in turn causes deadlocks when we do wakeups while holding that batched_entropy lock -- as the random code does. Solve this by moving __sched_fork() out from under rq->lock. This is safe because nothing there relies on rq->lock, as also evident from the other __sched_fork() callsite. Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Qian Cai Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: bigeasy@linutronix.de Cc: cl@linux.com Cc: keescook@chromium.org Cc: penberg@kernel.org Cc: rientjes@google.com Cc: thgarnie@google.com Cc: tytso@mit.edu Cc: will@kernel.org Fixes: b7d5dc21072c ("random: add a spinlock_t to struct batched_entropy") Link: https://lkml.kernel.org/r/20191001091837.GK4536@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 41415da3aa6ec235e8cbd365e6b61ac357b3d73e Author: Pan Bian Date: Tue Nov 12 17:04:54 2019 -0800 Input: cyttsp4_core - fix use after free bug [ Upstream commit 79aae6acbef16f720a7949f8fc6ac69816c79d62 ] The device md->input is used after it is released. Setting the device data to NULL is unnecessary as the device is never used again. Instead, md->input should be assigned NULL to avoid accessing the freed memory accidently. Besides, checking md->si against NULL is superfluous as it points to a variable address, which cannot be NULL. Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/1572936379-6423-1-git-send-email-bianpan2016@163.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e31f97a04f0aaf3516c3fad156e679051d19b9d7 Author: Xiaodong Xu Date: Mon Nov 11 15:05:46 2019 -0800 xfrm: release device reference for invalid state [ Upstream commit 4944a4b1077f74d89073624bd286219d2fcbfce3 ] An ESP packet could be decrypted in async mode if the input handler for this packet returns -EINPROGRESS in xfrm_input(). At this moment the device reference in skb is held. Later xfrm_input() will be invoked again to resume the processing. If the transform state is still valid it would continue to release the device reference and there won't be a problem; however if the transform state is not valid when async resumption happens, the packet will be dropped while the device reference is still being held. When the device is deleted for some reason and the reference to this device is not properly released, the kernel will keep logging like: unregister_netdevice: waiting for ppp2 to become free. Usage count = 1 The issue is observed when running IPsec traffic over a PPPoE device based on a bridge interface. By terminating the PPPoE connection on the server end for multiple times, the PPPoE device on the client side will eventually get stuck on the above warning message. This patch will check the async mode first and continue to release device reference in async resumption, before it is dropped due to invalid state. v2: Do not assign address family from outer_mode in the transform if the state is invalid v3: Release device reference in the error path instead of jumping to resume Fixes: 4ce3dbe397d7b ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)") Signed-off-by: Xiaodong Xu Reported-by: Bo Chen Tested-by: Bo Chen Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 3c5f6ba0f90e840086cc5114276f1d0493c14009 Author: Stephan Gerhold Date: Sun Nov 10 17:19:15 2019 +0100 NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error [ Upstream commit a71a29f50de1ef97ab55c151a1598eb12dde379d ] I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci result in a NULL pointer dereference at the moment: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1 RIP: 0010:skb_queue_tail+0x25/0x50 Call Trace: nci_recv_frame+0x36/0x90 [nci] nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c] ? preempt_count_add+0x68/0xa0 ? irq_forced_thread_fn+0x80/0x80 irq_thread_fn+0x20/0x60 irq_thread+0xee/0x180 ? wake_threads_waitq+0x30/0x30 kthread+0xfb/0x130 ? irq_thread_check_affinity+0xd0/0xd0 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x40 Afterward the kernel must be rebooted to work properly again. This happens because it attempts to call nci_recv_frame() with skb == NULL. However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any NULL checks for skb, causing the NULL pointer dereference. Change the code to call only nxp_nci_fw_recv_frame() in case of an error. Make sure to log it so it is obvious that a communication error occurred. The error above then becomes: nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 nci: __nci_request: wait_for_completion_interruptible_timeout failed 0 nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Signed-off-by: Stephan Gerhold Reviewed-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7fb6ef16efc014acbc09db2ed36970dcaca416e5 Author: Al Viro Date: Sat Nov 2 13:11:41 2019 -0400 audit_get_nd(): don't unlock parent too early [ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ] if the child has been negative and just went positive under us, we want coherent d_is_positive() and ->d_inode. Don't unlock the parent until we'd done that work... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit af17e1fc7cb773c7f22f7343323cf102ea52a50b Author: Al Viro Date: Fri Nov 8 22:08:29 2019 -0500 exportfs_decode_fh(): negative pinned may become positive without the parent locked [ Upstream commit a2ece088882666e1dc7113744ac912eb161e3f87 ] Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit dadd71d18abff387cd4fd9a091eea50dfab7f781 Author: Mordechay Goodstein Date: Thu Nov 7 13:51:47 2019 +0200 iwlwifi: pcie: don't consider IV len in A-MSDU [ Upstream commit cb1a4badf59275eb7221dcec621e8154917eabd1 ] From gen2 PN is totally offloaded to hardware (also the space for the IV isn't part of the skb). As you can see in mvm/mac80211.c:3545, the MAC for cipher types CCMP/GCMP doesn't set IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs. This causes all the AMSDU data to be corrupted with cipher enabled. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 65e5e9913161e3c0d61528b6a1745e568635d94e Author: Sirong Wang Date: Fri Nov 1 10:33:29 2019 +0800 RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN [ Upstream commit 531eb45b3da4267fc2a64233ba256c8ffb02edd2 ] Size of pointer to buf field of struct hns_roce_hem_chunk should be considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will be larger than expected when allocating hem. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/1572575610-52530-2-git-send-email-liweihang@hisilicon.com Signed-off-by: Sirong Wang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d4bc855afd2e1b93bbc94f67e98b8ce867d89f09 Author: Al Viro Date: Fri Oct 25 00:03:11 2019 -0400 autofs: fix a leak in autofs_expire_indirect() [ Upstream commit 03ad0d703df75c43f78bd72e16124b5b94a95188 ] if the second call of should_expire() in there ends up grabbing and returning a new reference to dentry, we need to drop it before continuing. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c44d21f8227e3919d5282d861352a91957b6743c Author: Chuhong Yuan Date: Mon Nov 18 10:48:33 2019 +0800 serial: ifx6x60: add missed pm_runtime_disable commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream. The driver forgets to call pm_runtime_disable in remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Cc: stable Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman commit bd95aea990a40c3a386e387722f3a6253b4c07a5 Author: Jiangfeng Xiao Date: Wed Nov 20 23:18:53 2019 +0800 serial: serial_core: Perform NULL checks for break_ctl ops commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream. Doing fuzz test on sbsa uart device, causes a kernel crash due to NULL pointer dereference: ------------[ cut here ]------------ Unable to handle kernel paging request at virtual address fffffffffffffffc pgd = ffffffe331723000 [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O) Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O) hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O) mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O) uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry nfsv3 nfs nfs_acl lockd sunrpc grace autofs4 CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G O 4.4.193 #1 task: ffffffe32b23f110 task.stack: ffffffe32bda4000 PC is at uart_break_ctl+0x44/0x84 LR is at uart_break_ctl+0x34/0x84 pc : [] lr : [] pstate: 80000005 sp : ffffffe32bda7cc0 x29: ffffffe32bda7cc0 x28: ffffffe32b23f110 x27: ffffff8393402000 x26: 0000000000000000 x25: ffffffe32b233f40 x24: ffffffc07a8ec680 x23: 0000000000005425 x22: 00000000ffffffff x21: ffffffe33ed73c98 x20: 0000000000000000 x19: ffffffe33ed94168 x18: 0000000000000004 x17: 0000007f92ae9d30 x16: ffffff8392fa6064 x15: 0000000000000010 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000020 x10: 0000007ffdac1708 x9 : 0000000000000078 x8 : 000000000000001d x7 : 0000000052a64887 x6 : ffffffe32bda7e08 x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000 x3 : ffffff83938d5018 x2 : 0000000000000080 x1 : ffffffe32b23c040 x0 : ffffff83934428f8 virtual start addr offset is 38ac00000 module base offset is 2cd4cf1000 linear region base offset is : 0 Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000) Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000) 7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054 7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c 7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600 7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425 7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003 7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e 7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600 7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410 7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978 7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc 7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0 7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78 7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c 7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425 7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014 7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078 7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000 7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30 7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0 7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840 7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000 7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Call trace: Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0) 7aa0: 0000000000001000 0000007fffffffff 7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025 7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c 7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20 7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000 7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110 7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600 7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018 7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887 7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020 7be0: 0000000000000000 0000000000000000 [] uart_break_ctl+0x44/0x84 [] send_break+0xa0/0x114 [] tty_ioctl+0xc50/0xe84 [] do_vfs_ioctl+0xc4/0x6e8 [] SyS_ioctl+0x68/0x9c [] __sys_trace_return+0x0/0x4 Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280) ---[ end trace 8606094f1960c5e0 ]--- Kernel panic - not syncing: Fatal exception Fix this problem by adding NULL checks prior to calling break_ctl ops. Signed-off-by: Jiangfeng Xiao Cc: stable Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman commit 4fca520233920314bd13446890af558c3260d836 Author: Vincent Whitchurch Date: Mon Nov 18 10:25:47 2019 +0100 serial: pl011: Fix DMA ->flush_buffer() commit f6a196477184b99a31d16366a8e826558aa11f6d upstream. PL011's ->flush_buffer() implementation releases and reacquires the port lock. Due to a race condition here, data can end up being added to the circular buffer but neither being discarded nor being sent out. This leads to, for example, tcdrain(2) waiting indefinitely. Process A Process B uart_flush_buffer() - acquire lock - circ_clear - pl011_flush_buffer() -- release lock -- dmaengine_terminate_all() uart_write() - acquire lock - add chars to circ buffer - start_tx() -- start DMA - release lock -- acquire lock -- turn off DMA -- release lock // Data in circ buffer but DMA is off According to the comment in the code, the releasing of the lock around dmaengine_terminate_all() is to avoid a deadlock with the DMA engine callback. However, since the time this code was written, the DMA engine API documentation seems to have been clarified to say that dmaengine_terminate_all() (in the identically implemented but differently named dmaengine_terminate_async() variant) does not wait for any running complete callback to be completed and can even be called from a complete callback. So there is no possibility of deadlock if the DMA engine driver implements this API correctly. So we should be able to just remove this release and reacquire of the lock to prevent the aforementioned race condition. Signed-off-by: Vincent Whitchurch Cc: stable Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman commit 4f7294890ac39130277243aebd5a3d33f4feebba Author: Jeffrey Hugo Date: Mon Oct 21 08:46:16 2019 -0700 tty: serial: msm_serial: Fix flow control commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream. hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and Lenovo Miix 630 laptop. As part of initializing the wcn3990, hci_qca disables flow, configures the uart baudrate, and then reenables flow - at which point an event is expected to be received over the uart from the wcn3990. It is observed that this event comes after the baudrate change but before hci_qca re-enables flow. This is unexpected, and is a result of msm_reset() being broken. According to the uart_dm hardware documentation, it is recommended that automatic hardware flow control be enabled by setting RX_RDY_CTL. Auto hw flow control will manage RFR based on the configured watermark. When there is space to receive data, the hw will assert RFR. When the watermark is hit, the hw will de-assert RFR. The hardware documentation indicates that RFR can me manually managed via CR when RX_RDY_CTL is not set. SET_RFR asserts RFR, and RESET_RFR de-asserts RFR. msm_reset() is broken because after resetting the hardware, it unconditionally asserts RFR via SET_RFR. This enables flow regardless of the current configuration, and would undo a previous flow disable operation. It should instead de-assert RFR via RESET_RFR to block flow until the hardware is reconfigured. msm_serial should rely on the client to specify that flow should be enabled, either via mctrl() or the termios structure, and only assert RFR in response to those triggers. Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.") Signed-off-by: Jeffrey Hugo Reviewed-by: Bjorn Andersson Cc: stable Reviewed-by: Andy Gross Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8f7600e2db0caeaf0427eaca02a8f7e1126bb342 Author: Peng Fan Date: Tue Nov 5 05:51:10 2019 +0000 tty: serial: fsl_lpuart: use the sg count from dma_map_sg commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream. The dmaengine_prep_slave_sg needs to use sg count returned by dma_map_sg, not use sport->dma_tx_nents, because the return value of dma_map_sg is not always same with "nents". When enabling iommu for lpuart + edma, iommu framework may concatenate two sgs into one. Fixes: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Cc: Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.com Signed-off-by: Greg Kroah-Hartman commit c5a309dc42f1891c8c00a704d5d206702a047a42 Author: Michał Mirosław Date: Sat Aug 10 10:42:48 2019 +0200 usb: gadget: u_serial: add missing port entry locking commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream. gserial_alloc_line() misses locking (for a release barrier) while resetting port entry on TTY allocation failure. Fix this. Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław Reviewed-by: Greg Kroah-Hartman Tested-by: Ladislav Michl Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c35cac9280113e2dcf78f9a5bfa85321b62a9610 Author: Arnd Bergmann Date: Fri Nov 8 21:34:29 2019 +0100 lp: fix sparc64 LPSETTIMEOUT ioctl commit 45a2d64696b11913bcf1087b041740edbade3e21 upstream. The layout of struct timeval is different on sparc64 from anything else, and the patch I did long ago failed to take this into account. Change it now to handle sparc64 user space correctly again. Quite likely nobody cares about parallel ports on sparc64, but there is no reason not to fix it. Cc: stable@vger.kernel.org Fixes: 9a450484089d ("lp: support 64-bit time_t user space") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20191108203435.112759-7-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman commit a59c5bc79eea008a7141200332323e4041e2fbeb Author: Tuowen Zhao Date: Wed Oct 16 15:06:27 2019 -0600 sparc64: implement ioremap_uc commit 38e45d81d14e5f78cd67922596b1c37b4c22ec74 upstream. On sparc64, the whole physical IO address space is accessible using physically addressed loads and stores. *_uc does nothing like the others. Cc: # v4.19+ Reported-by: kbuild test robot Signed-off-by: Tuowen Zhao Acked-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 2f5eb8d64fa587d41d8e8efe24d7c146a5a343e7 Author: Jon Hunter Date: Wed Sep 25 15:12:29 2019 +0100 arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator commit 1e5e929c009559bd7e898ac8e17a5d01037cb057 upstream. Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") added a regulator for HDMI on the Jetson TX1 platform. This regulator has an active high enable, but the GPIO specifier for enabling the regulator incorrectly defines it as active-low. This causes the following warning to occur on boot ... WARNING KERN regulator@10 GPIO handle specifies active low - ignored The fixed-regulator binding does not use the active-low flag from the gpio specifier and purely relies of the presence of the 'enable-active-high' property to determine if it is active high or low (if this property is omitted). Fix this warning by setting the GPIO to active-high in the GPIO specifier which aligns with the presense of the 'enable-active-high' property. Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 5da96cc31633a9076404621ebb89bbe78f2c8676 Author: Navid Emamdoost Date: Fri Sep 13 19:08:11 2019 -0500 rsi: release skb if rsi_prepare_beacon fails commit d563131ef23cbc756026f839a82598c8445bc45f upstream. In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should be released. Signed-off-by: Navid Emamdoost Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit fb683b5e3f53a73e761952735736180939a313df Author: Greg Kroah-Hartman Date: Thu Dec 5 09:21:36 2019 +0100 Linux 4.19.88 commit 04748841f7a02ec6ff07fadfc5d1f8e24e61946d Author: Chuhong Yuan Date: Wed Nov 20 09:25:13 2019 +0800 net: fec: fix clock count mis-match commit a31eda65ba210741b598044d045480494d0ed52a upstream. pm_runtime_put_autosuspend in probe will call runtime suspend to disable clks automatically if CONFIG_PM is defined. (If CONFIG_PM is not defined, its implementation will be empty, then runtime suspend will not be called.) Therefore, we can call pm_runtime_get_sync to runtime resume it first to enable clks, which matches the runtime suspend. (Only when CONFIG_PM is defined, otherwise pm_runtime_get_sync will also be empty, then runtime resume will not be called.) Then it is fine to disable clks without causing clock count mis-match. Fixes: c43eab3eddb4 ("net: fec: add missed clk_disable_unprepare in remove") Signed-off-by: Chuhong Yuan Acked-by: Fugang Duan Signed-off-by: David S. Miller Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 067f44ce04e07d66a9b4fe6f4ef6f470097927d1 Author: Hans de Goede Date: Fri Nov 22 19:56:41 2019 +0100 platform/x86: hp-wmi: Fix ACPI errors caused by passing 0 as input size commit f3e4f3fc8ee9729c4b1b27a478c68b713df53c0c upstream. The AML code implementing the WMI methods creates a variable length field to hold the input data we pass like this: CreateDWordField (Arg1, 0x0C, DSZI) Local5 = DSZI /* \HWMC.DSZI */ CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN) If we pass 0 as bios_args.datasize argument then (Local5 * 0x08) is 0 which results in these errors: [ 71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133) [ 71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) [ 71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for read commands where extra input is needed to specify exactly what to read. So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected output as insize to hp_wmi_perform_query(), as we are already doing for all other HPWMI_READ commands we send. Doing so fixes these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit ef070b318beced8980632d57ac85629617d110d6 Author: Hans de Goede Date: Fri Nov 22 19:56:40 2019 +0100 platform/x86: hp-wmi: Fix ACPI errors caused by too small buffer commit 16245db1489cd9aa579506f64afeeeb13d825a93 upstream. The HP WMI calls may take up to 128 bytes of data as input, and the AML methods implementing the WMI calls, declare a couple of fields for accessing input in different sizes, specifycally the HWMC method contains: CreateField (Arg1, 0x80, 0x0400, D128) Even though we do not use any of the WMI command-types which need a buffer of this size, the APCI interpreter still tries to create it as it is declared in generoc code at the top of the HWMC method which runs before the code looks at which command-type is requested. This results in many of these errors on many different HP laptop models: [ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236) [ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543) [ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543) This commit increases the size of the data element of the bios_args struct to 128 bytes fixing these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit ecda0abb141725d9d76dcc8b07c78b4506098b73 Author: Pierre-Yves MORDRET Date: Tue Sep 11 09:31:16 2018 +0200 dmaengine: stm32-dma: check whether length is aligned on FIFO threshold commit cc832dc8e32785a730ba07c3a357e17c201a5df8 upstream. When a period length is not multiple of FIFO some data may be stuck within FIFO. Burst/FIFO Threshold/Period or buffer length check has to be hardened In any case DMA will grant any request from client but will degraded any parameters whether awkward. Signed-off-by: Pierre-Yves MORDRET Signed-off-by: Vinod Koul Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit f0b7d56f1fd58b7a45c2ebe06fa96eea68eb2ea3 Author: Wen Yang Date: Sat Feb 9 10:41:09 2019 +0000 ASoC: stm32: sai: add missing put_device() commit 1c3816a194870e7a6622345dab7fb56c7d708613 upstream. The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Fixes: 7dd0d835582f ("ASoC: stm32: sai: simplify sync modes management") Signed-off-by: Wen Yang Acked-by: Olivier Moysan Signed-off-by: Mark Brown Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 86c823d4a99ceb869f53320a0cbbe721d8f2c84c Author: Olivier Moysan Date: Tue Feb 26 14:51:04 2019 +0100 ASoC: stm32: i2s: fix IRQ clearing commit 8ba3c5215d69c09f5c39783ff3b78347769822ad upstream. Because of regmap cache, interrupts may not be cleared as expected. Declare IFCR register as write only and make writings to IFCR register unconditional. Signed-off-by: Olivier Moysan Signed-off-by: Mark Brown Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit cacd33b1c9b0700f8cba2f8f57278173822f90db Author: Olivier Moysan Date: Tue Feb 26 14:51:05 2019 +0100 ASoC: stm32: i2s: fix 16 bit format support commit 0c4c68d6fa1bae74d450e50823c24fcc3cd0b171 upstream. I2S supports 16 bits data in 32 channel length. However the expected driver behavior, is to set channel length to 16 bits when data format is 16 bits. Signed-off-by: Olivier Moysan Signed-off-by: Mark Brown Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 9247eca74dbaa0e607eb9389015e04b345efcd6b Author: Olivier Moysan Date: Tue Feb 26 14:51:07 2019 +0100 ASoC: stm32: i2s: fix dma configuration commit 1ac2bd16448997d9ec01922423486e1e85535eda upstream. DMA configuration is not balanced on start/stop. Move DMA configuration to trigger callback. Signed-off-by: Olivier Moysan Signed-off-by: Mark Brown Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 1ff5ee143c8ae6f383c5d6e0fb04069c12e014f6 Author: Alexandre Torgue Date: Thu Feb 14 17:54:24 2019 +0100 pinctrl: stm32: fix memory leak issue commit cd8c9b5a49576bf28990237715bc2cb2210ac80a upstream. configs is allocated by pinconf_generic_parse_dt_config(), pinctrl_utils_add_map_configs() duplicates configs so it can and has to be freed to prevent memory leaks. Signed-off-by: Alexandre Torgue Signed-off-by: Linus Walleij Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 3e777af50963bc38d816190fe07e79f519d66a0b Author: Fabien Dessenne Date: Fri Jan 4 14:47:16 2019 +0100 mailbox: mailbox-test: fix null pointer if no mmio commit 6899b4f7c99c72968e58e502f96084f74f6e5e86 upstream. Fix null pointer issue if resource_size is called with no ioresource. Signed-off-by: Ludovic Barre Signed-off-by: Fabien Dessenne Signed-off-by: Jassi Brar Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 115160ff78d55ff99f0df640debe1ec576afe6a2 Author: Gabriel Fernandez Date: Thu Feb 14 11:40:41 2019 +0100 clk: stm32mp1: parent clocks update commit 749c9e553e1f063eb132a78d80225532cbfedb80 upstream. Fixes parent clock for axi, fdcan, sai and adc12 clocks. Fixes: e51d297e9a92 ("clk: stm32mp1: add Sub System clocks") Signed-off-by: Gabriel Fernandez Signed-off-by: Stephen Boyd Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 6887765e65f08c6fdaefeb383e70926e352b1e05 Author: Gabriel Fernandez Date: Thu Feb 14 11:40:42 2019 +0100 clk: stm32mp1: add CLK_SET_RATE_NO_REPARENT to Kernel clocks commit 72cfd1ad1057f16fc614861b3c271597995e57ba upstream. STM32MP1 clock IP offers lots of Kernel clocks that are shared by multiple IP's at the same time. Then boot loader applies a clock tree that allows to use all IP's at same time and with the maximum of performance. Not change parents on a change rate on kernel clocks ensures the integrity of the system. Signed-off-by: Gabriel Fernandez Signed-off-by: Stephen Boyd Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 8b4c36532ee45914385dfb26483a857cce84523d Author: Gabriel Fernandez Date: Thu Feb 14 11:40:44 2019 +0100 clk: stm32mp1: fix mcu divider table commit 140fc4e406fac420b978a0ef2ee1fe3c641a6ae4 upstream. index 8: ck_mcu is divided by 256 (not 512) Fixes: e51d297e9a92 ("clk: stm32mp1: add Sub System clocks") Signed-off-by: Gabriel Fernandez Signed-off-by: Stephen Boyd Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit f802418afabdcab6c96b9d8ee21a8e8033813246 Author: Gabriel Fernandez Date: Thu Feb 14 11:40:45 2019 +0100 clk: stm32mp1: fix HSI divider flag commit d3f2e33c875de5052e032a9eefa64c897a930ed1 upstream. The divider of HSI (clk-hsi-div) is power of two divider. Fixes: 9bee94e7b7da ("clk: stm32mp1: Introduce STM32MP1 clock driver") Signed-off-by: Gabriel Fernandez Signed-off-by: Stephen Boyd Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 5c28bbeb58d4b74c1642323668e35f6414580db9 Author: Lionel Debieve Date: Mon Apr 1 12:30:45 2019 +0200 hwrng: stm32 - fix unbalanced pm_runtime_enable commit af0d4442dd6813de6e77309063beb064fa8e89ae upstream. No remove function implemented yet in the driver. Without remove function, the pm_runtime implementation complains when removing and probing again the driver. Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 9510194763e08f9823e1340e52ad3d9b44864f8e Author: Hugues Fruchet Date: Thu Feb 28 12:09:17 2019 -0500 media: stm32-dcmi: fix check of pm_runtime_get_sync return value commit ab41b99e7e55c85f29ff7b54718ccbbe051905e7 upstream. Start streaming was sometimes failing because of pm_runtime_get_sync() non-0 return value. In fact return value was not an error but a positive value (1), indicating that PM was already enabled. Fix this by going to error path only with negative return value. Signed-off-by: Hugues Fruchet Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit e7455065952b1b1c0a62db153ac5297eee97d48d Author: Hugues Fruchet Date: Thu Feb 28 12:10:53 2019 -0500 media: stm32-dcmi: fix DMA corruption when stopping streaming commit b3ce6f6ff3c260ee53b0f2236e5fd950d46957da upstream. Avoid call of dmaengine_terminate_all() between dmaengine_prep_slave_single() and dmaengine_submit() by locking the whole DMA submission sequence. Signed-off-by: Hugues Fruchet Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit c7f92e45fe21a55ea6906e165e14e666fa53a8d1 Author: Lionel Debieve Date: Fri Jun 28 13:26:54 2019 +0200 crypto: stm32/hash - Fix hmac issue more than 256 bytes commit 0acabecebc912b3ba06289e4ef40476acc499a37 upstream. Correct condition for the second hmac loop. Key must be only set in the first loop. Initial condition was wrong, HMAC_KEY flag was not properly checked. Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit be41df88a568ef7871870b1c924d220c37d2e28c Author: Candle Sun Date: Tue Oct 22 22:21:39 2019 +0800 HID: core: check whether Usage Page item is after Usage ID items commit 1cb0d2aee26335d0bccf29100c7bed00ebece851 upstream. Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation to Main item") adds support for Usage Page item after Usage ID items (such as keyboards manufactured by Primax). Usage Page concatenation in Main item works well for following report descriptor patterns: USAGE_PAGE (Keyboard) 05 07 USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 INPUT (Data,Var,Abs) 81 02 ------------- USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 USAGE_PAGE (Keyboard) 05 07 INPUT (Data,Var,Abs) 81 02 But it makes the parser act wrong for the following report descriptor pattern(such as some Gamepads): USAGE_PAGE (Button) 05 09 USAGE (Button 1) 09 01 USAGE (Button 2) 09 02 USAGE (Button 4) 09 04 USAGE (Button 5) 09 05 USAGE (Button 7) 09 07 USAGE (Button 8) 09 08 USAGE (Button 14) 09 0E USAGE (Button 15) 09 0F USAGE (Button 13) 09 0D USAGE_PAGE (Consumer Devices) 05 0C USAGE (Back) 0a 24 02 USAGE (HomePage) 0a 23 02 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (11) 95 0B INPUT (Data,Var,Abs) 81 02 With Usage Page concatenation in Main item, parser recognizes all the 11 Usages as consumer keys, it is not the HID device's real intention. This patch checks whether Usage Page is really defined after Usage ID items by comparing usage page using status. Usage Page concatenation on currently defined Usage Page will always do in local parsing when Usage ID items encountered. When Main item is parsing, concatenation will do again with last defined Usage Page if this page has not been used in the previous usages concatenation. Signed-off-by: Candle Sun Signed-off-by: Nianfu Bai Cc: Benjamin Tissoires Signed-off-by: Jiri Kosina Cc: Siarhei Vishniakou Signed-off-by: Greg Kroah-Hartman commit d832269ac697067335952ba3a9c185027065f95c Author: Yuchung Cheng Date: Wed Jan 16 15:05:28 2019 -0800 tcp: exit if nothing to retransmit on RTO timeout commit 88f8598d0a302a08380eadefd09b9f5cb1c4c428 upstream. Previously TCP only warns if its RTO timer fires and the retransmission queue is empty, but it'll cause null pointer reference later on. It's better to avoid such catastrophic failure and simply exit with a warning. Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Reviewed-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95442682dd2dfc6398be43574cb073f4322d6889 Author: Arnaud Pouliquen Date: Wed May 22 10:25:35 2019 +0200 mailbox: stm32_ipcc: add spinlock to fix channels concurrent access commit dba9a3dfe912dc47c9dbc9ba1f5f65adbf9aea0f upstream. Add spinlock protection on IPCC register update to avoid race condition. Without this fix, stm32_ipcc_set_bits and stm32_ipcc_clr_bits can be called in parallel for different channels. This results in register corruptions. Signed-off-by: Arnaud Pouliquen Reviewed-by: Fabien Dessenne Signed-off-by: Jassi Brar Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit f9367f945d23ccb8f8d930bcd9a60a509457ba83 Author: Claudiu Beznea Date: Thu Apr 25 12:36:39 2019 +0000 drm/atmel-hlcdc: revert shift by 8 commit cbb32079149dbf557fa3f7bab8fa3c5fec857da7 upstream. Revert shift by 8 of state->base.alpha. This introduced a regression on planes. Fixes: 7f73c10b256b ("drm/atmel-hclcdc: Convert to the new generic alpha property") Cc: Maxime Ripard Signed-off-by: Claudiu Beznea Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1556195748-11106-7-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 37b5fff3d666fae1df038d8f9e90586e5e0e8ba1 Author: huijin.park Date: Wed Nov 28 03:02:14 2018 -0500 mtd: spi-nor: cast to u64 to avoid uint overflows commit 84a1c2109d23df3543d96231c4fee1757299bb1a upstream. The "params->size" is defined as "u64". And "info->sector_size" and "info->n_sectors" are defined as unsigned int and u16. Thus, u64 data might have strange data(loss data) if the result overflows an unsigned int. This patch casts "info->sector_size" to an u64. Signed-off-by: huijin.park Reviewed-by: Geert Uytterhoeven Signed-off-by: Boris Brezillon Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 4535def71226e3d7f330875f1746b479baaf6bc6 Author: Wen Yang Date: Thu Feb 7 03:50:55 2019 +0000 mtd: rawnand: atmel: fix possible object reference leak commit a12085d13997ed15f745f33a0e01002541160179 upstream. of_find_device_by_node() takes a reference to the struct device when it finds a match via get_device, there is no need to call get_device() twice. We also should make sure to drop the reference to the device taken by of_find_device_by_node() on driver unbind. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Wen Yang Suggested-by: Boris Brezillon Reviewed-by: Boris Brezillon Reviewed-by: Miquel Raynal Acked-by: Miquel Raynal Cc: Tudor Ambarus Cc: Boris Brezillon Cc: Miquel Raynal Cc: Richard Weinberger Cc: David Woodhouse Cc: Brian Norris Cc: Marek Vasut Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: linux-mtd@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit d76562fe5cdbe6032f5278cd6cb51abf354193c7 Author: Miquel Raynal Date: Mon Apr 1 16:49:01 2019 +0200 mtd: rawnand: atmel: Fix spelling mistake in error message commit e39bb786816453788836c367caefd72eceea380c upstream. Wrong copy/paste from the previous block, the error message should refer to #size-cells instead of #address-cells. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Miquel Raynal Reviewed-by: Tudor Ambarus Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit cabf7f90ced5088d16820221c9301c872a7a2a5d Author: Paul Thomas Date: Mon Apr 8 15:37:54 2019 -0400 net: macb driver, check for SKBTX_HW_TSTAMP commit a62520473f15750cd1432d36b377a06cd7cff8d2 upstream. Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been enabled for this skb. It does fix the issue where normal socks that aren't expecting a timestamp will not wake up on select, but when a user does want a SOF_TIMESTAMPING_TX_HARDWARE it does work. Signed-off-by: Paul Thomas Signed-off-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e8d59efd8ef9f1d2f3a79d41c16b9a01fea4be38 Author: Harini Katakam Date: Thu Jun 27 11:51:00 2019 +0530 net: macb: Fix SUBNS increment and increase resolution commit 7ad342bc58cc5197cd2f12a3c30b3949528c6d83 upstream. The subns increment register has 24 bits as follows: RegBit[15:0] = Subns[23:8]; RegBit[31:24] = Subns[7:0] Fix the same in the driver and increase sub ns resolution to the best capable, 24 bits. This should be the case on all GEM versions that this PTP driver supports. Signed-off-by: Harini Katakam Signed-off-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit d29baef043374938ef9b052bef6aae8e2156b65a Author: Eugen Hristev Date: Wed May 8 14:15:03 2019 +0000 watchdog: sama5d4: fix WDD value to be always set to max commit 8632944841d41a36d77dd1fa88d4201b5291100f upstream. WDD value must be always set to max (0xFFF) otherwise the hardware block will reset the board on the first ping of the watchdog. Signed-off-by: Eugen Hristev Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e91cce02f3025da559468729ea0ad9dea242d3eb Author: Theodore Ts'o Date: Thu Nov 7 21:43:41 2019 -0500 ext4: add more paranoia checking in ext4_expand_extra_isize handling commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream. It's possible to specify a non-zero s_want_extra_isize via debugging option, and this can cause bad things(tm) to happen when using a file system with an inode size of 128 bytes. Add better checking when the file system is mounted, as well as when we are actually doing the trying to do the inode expansion. Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 10d3899dc67baf167c5410c084c3defbb59559df Author: Chuhong Yuan Date: Thu Nov 28 10:00:21 2019 +0800 net: macb: add missed tasklet_kill [ Upstream commit 61183b056b49e2937ff92a1424291ba36a6f6d05 ] This driver forgets to kill tasklet in remove. Add the call to fix it. Fixes: 032dc41ba6e2 ("net: macb: Handle HRESP error") Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 50ee7a491fc8af423b306b0e9acebb455779bbc1 Author: Dust Li Date: Thu Nov 28 14:29:09 2019 +0800 net: sched: fix `tc -s class show` no bstats on class with nolock subqueues [ Upstream commit 14e54ab9143fa60794d13ea0a66c792a2046a8f3 ] When a classful qdisc's child qdisc has set the flag TCQ_F_CPUSTATS (pfifo_fast for example), the child qdisc's cpu_bstats should be passed to gnet_stats_copy_basic(), but many classful qdisc didn't do that. As a result, `tc -s class show dev DEV` always return 0 for bytes and packets in this case. Pass the child qdisc's cpu_bstats to gnet_stats_copy_basic() to fix this issue. The qstats also has this problem, but it has been fixed in 5dd431b6b9 ("net: sched: introduce and use qstats read...") and bstats still remains buggy. Fixes: 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe") Signed-off-by: Dust Li Signed-off-by: Tony Lu Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1bef71f558cc38c0b93b4f465b9c2a9923720b7b Author: Xin Long Date: Sat Nov 23 11:56:49 2019 +0800 sctp: cache netns in sctp_ep_common [ Upstream commit 312434617cb16be5166316cf9d08ba760b1042a1 ] This patch is to fix a data-race reported by syzbot: BUG: KCSAN: data-race in sctp_assoc_migrate / sctp_hash_obj write to 0xffff8880b67c0020 of 8 bytes by task 18908 on cpu 1: sctp_assoc_migrate+0x1a6/0x290 net/sctp/associola.c:1091 sctp_sock_migrate+0x8aa/0x9b0 net/sctp/socket.c:9465 sctp_accept+0x3c8/0x470 net/sctp/socket.c:4916 inet_accept+0x7f/0x360 net/ipv4/af_inet.c:734 __sys_accept4+0x224/0x430 net/socket.c:1754 __do_sys_accept net/socket.c:1795 [inline] __se_sys_accept net/socket.c:1792 [inline] __x64_sys_accept+0x4e/0x60 net/socket.c:1792 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffff8880b67c0020 of 8 bytes by task 12003 on cpu 0: sctp_hash_obj+0x4f/0x2d0 net/sctp/input.c:894 rht_key_get_hash include/linux/rhashtable.h:133 [inline] rht_key_hashfn include/linux/rhashtable.h:159 [inline] rht_head_hashfn include/linux/rhashtable.h:174 [inline] head_hashfn lib/rhashtable.c:41 [inline] rhashtable_rehash_one lib/rhashtable.c:245 [inline] rhashtable_rehash_chain lib/rhashtable.c:276 [inline] rhashtable_rehash_table lib/rhashtable.c:316 [inline] rht_deferred_worker+0x468/0xab0 lib/rhashtable.c:420 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269 worker_thread+0xa0/0x800 kernel/workqueue.c:2415 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 It was caused by rhashtable access asoc->base.sk when sctp_assoc_migrate is changing its value. However, what rhashtable wants is netns from asoc base.sk, and for an asoc, its netns won't change once set. So we can simply fix it by caching netns since created. Fixes: d6c0256a60e6 ("sctp: add the rhashtable apis for sctp global transport hashtable") Reported-by: syzbot+e3b35fe7918ff0ee474e@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2e849d71df3a589a5676dffc2f835f250c774b79 Author: John Rutherford Date: Tue Nov 26 13:52:55 2019 +1100 tipc: fix link name length check [ Upstream commit fd567ac20cb0377ff466d3337e6e9ac5d0cb15e4 ] In commit 4f07b80c9733 ("tipc: check msg->req data len in tipc_nl_compat_bearer_disable") the same patch code was copied into routines: tipc_nl_compat_bearer_disable(), tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats(). The two link routine occurrences should have been modified to check the maximum link name length and not bearer name length. Fixes: 4f07b80c9733 ("tipc: check msg->reg data len in tipc_nl_compat_bearer_disable") Signed-off-by: John Rutherford Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 93c259c582afb5890f3d6d054160ba0aa5f78a2a Author: Jakub Kicinski Date: Wed Nov 27 12:16:45 2019 -0800 selftests: bpf: test_sockmap: handle file creation failures gracefully [ Upstream commit 4b67c515036313f3c3ecba3cb2babb9cbddb3f85 ] test_sockmap creates a temporary file to use for sendpage. this may fail for various reasons. Handle the error rather than segfault. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ed8f48e6a535eec497b98ff13c17ccca1735432 Author: Paolo Abeni Date: Sun Dec 1 18:41:25 2019 +0100 openvswitch: remove another BUG_ON() [ Upstream commit 8a574f86652a4540a2433946ba826ccb87f398cc ] If we can't build the flow del notification, we can simply delete the flow, no need to crash the kernel. Still keep a WARN_ON to preserve debuggability. Note: the BUG_ON() predates the Fixes tag, but this change can be applied only after the mentioned commit. v1 -> v2: - do not leak an skb on error Fixes: aed067783e50 ("openvswitch: Minimize ovs_flow_cmd_del critical section.") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7e48458fd1f7a355c86527ad35fac012ae64c025 Author: Paolo Abeni Date: Sun Dec 1 18:41:24 2019 +0100 openvswitch: drop unneeded BUG_ON() in ovs_flow_cmd_build_info() [ Upstream commit 8ffeb03fbba3b599690b361467bfd2373e8c450f ] All the callers of ovs_flow_cmd_build_info() already deal with error return code correctly, so we can handle the error condition in a more gracefull way. Still dump a warning to preserve debuggability. v1 -> v2: - clarify the commit message - clean the skb and report the error (DaveM) Fixes: ccb1352e76cf ("net: Add Open vSwitch kernel components.") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0c6e6ceae72c9bdb8834352190c6cafcd0b3c21d Author: Jouni Hogander Date: Mon Nov 25 14:23:43 2019 +0200 slip: Fix use-after-free Read in slip_open [ Upstream commit e58c1912418980f57ba2060017583067f5f71e52 ] Slip_open doesn't clean-up device which registration failed from the slip_devs device list. On next open after failure this list is iterated and freed device is accessed. Fix this by calling sl_free_netdev in error path. Here is the trace from the Syzbot: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 sl_sync drivers/net/slip/slip.c:725 [inline] slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 tiocsetd drivers/tty/tty_io.c:2334 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3b5a39979daf ("slip: Fix memory leak in slip_open error path") Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com Cc: David Miller Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 681e08498e5e7e051ba1fedf815509f56ef31c4f Author: Navid Emamdoost Date: Fri Nov 22 16:17:56 2019 -0600 sctp: Fix memory leak in sctp_sf_do_5_2_4_dupcook [ Upstream commit b6631c6031c746ed004c4221ec0616d7a520f441 ] In the implementation of sctp_sf_do_5_2_4_dupcook() the allocated new_asoc is leaked if security_sctp_assoc_request() fails. Release it via sctp_association_free(). Fixes: 2277c7cd75e3 ("sctp: Add LSM hooks") Signed-off-by: Navid Emamdoost Acked-by: Marcelo Ricardo Leitner Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ae0ab39570fbb2a37690f70f2d93dfb2ddebdf3d Author: Paolo Abeni Date: Tue Nov 26 12:55:50 2019 +0100 openvswitch: fix flow command message size [ Upstream commit 4e81c0b3fa93d07653e2415fa71656b080a112fd ] When user-space sets the OVS_UFID_F_OMIT_* flags, and the relevant flow has no UFID, we can exceed the computed size, as ovs_nla_put_identifier() will always dump an OVS_FLOW_ATTR_KEY attribute. Take the above in account when computing the flow command message size. Fixes: 74ed7ab9264c ("openvswitch: Add support for unique flow IDs.") Reported-by: Qi Jun Ding Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4f8bd02b6f6715cc06e5725a9a9ce7835bcfd958 Author: Nikolay Aleksandrov Date: Wed Nov 27 00:16:44 2019 +0200 net: psample: fix skb_over_panic [ Upstream commit 7eb9d7675c08937cd11d32b0b40442d4d731c5ee ] We need to calculate the skb size correctly otherwise we risk triggering skb_over_panic[1]. The issue is that data_len is added to the skb in a nl attribute, but we don't account for its header size (nlattr 4 bytes) and alignment. We account for it when calculating the total size in the > PSAMPLE_MAX_PACKET_SIZE comparison correctly, but not when allocating after that. The fix is simple - use nla_total_size() for data_len when allocating. To reproduce: $ tc qdisc add dev eth1 clsact $ tc filter add dev eth1 egress matchall action sample rate 1 group 1 trunc 129 $ mausezahn eth1 -b bcast -a rand -c 1 -p 129 < skb_over_panic BUG(), tail is 4 bytes past skb->end > [1] Trace: [ 50.459526][ T3480] skbuff: skb_over_panic: text:(____ptrval____) len:196 put:136 head:(____ptrval____) data:(____ptrval____) tail:0xc4 end:0xc0 dev: [ 50.474339][ T3480] ------------[ cut here ]------------ [ 50.481132][ T3480] kernel BUG at net/core/skbuff.c:108! [ 50.486059][ T3480] invalid opcode: 0000 [#1] PREEMPT SMP [ 50.489463][ T3480] CPU: 3 PID: 3480 Comm: mausezahn Not tainted 5.4.0-rc7 #108 [ 50.492844][ T3480] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 [ 50.496551][ T3480] RIP: 0010:skb_panic+0x79/0x7b [ 50.498261][ T3480] Code: bc 00 00 00 41 57 4c 89 e6 48 c7 c7 90 29 9a 83 4c 8b 8b c0 00 00 00 50 8b 83 b8 00 00 00 50 ff b3 c8 00 00 00 e8 ae ef c0 fe <0f> 0b e8 2f df c8 fe 48 8b 55 08 44 89 f6 4c 89 e7 48 c7 c1 a0 22 [ 50.504111][ T3480] RSP: 0018:ffffc90000447a10 EFLAGS: 00010282 [ 50.505835][ T3480] RAX: 0000000000000087 RBX: ffff888039317d00 RCX: 0000000000000000 [ 50.507900][ T3480] RDX: 0000000000000000 RSI: ffffffff812716e1 RDI: 00000000ffffffff [ 50.509820][ T3480] RBP: ffffc90000447a60 R08: 0000000000000001 R09: 0000000000000000 [ 50.511735][ T3480] R10: ffffffff81d4f940 R11: 0000000000000000 R12: ffffffff834a22b0 [ 50.513494][ T3480] R13: ffffffff82c10433 R14: 0000000000000088 R15: ffffffff838a8084 [ 50.515222][ T3480] FS: 00007f3536462700(0000) GS:ffff88803eac0000(0000) knlGS:0000000000000000 [ 50.517135][ T3480] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 50.518583][ T3480] CR2: 0000000000442008 CR3: 000000003b222000 CR4: 00000000000006e0 [ 50.520723][ T3480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 50.522709][ T3480] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 50.524450][ T3480] Call Trace: [ 50.525214][ T3480] skb_put.cold+0x1b/0x1b [ 50.526171][ T3480] psample_sample_packet+0x1d3/0x340 [ 50.527307][ T3480] tcf_sample_act+0x178/0x250 [ 50.528339][ T3480] tcf_action_exec+0xb1/0x190 [ 50.529354][ T3480] mall_classify+0x67/0x90 [ 50.530332][ T3480] tcf_classify+0x72/0x160 [ 50.531286][ T3480] __dev_queue_xmit+0x3db/0xd50 [ 50.532327][ T3480] dev_queue_xmit+0x18/0x20 [ 50.533299][ T3480] packet_sendmsg+0xee7/0x2090 [ 50.534331][ T3480] sock_sendmsg+0x54/0x70 [ 50.535271][ T3480] __sys_sendto+0x148/0x1f0 [ 50.536252][ T3480] ? tomoyo_file_ioctl+0x23/0x30 [ 50.537334][ T3480] ? ksys_ioctl+0x5e/0xb0 [ 50.540068][ T3480] __x64_sys_sendto+0x2a/0x30 [ 50.542810][ T3480] do_syscall_64+0x73/0x1f0 [ 50.545383][ T3480] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 50.548477][ T3480] RIP: 0033:0x7f35357d6fb3 [ 50.551020][ T3480] Code: 48 8b 0d 18 90 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 d3 20 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 eb f6 ff ff 48 89 04 24 [ 50.558547][ T3480] RSP: 002b:00007ffe0c7212c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 50.561870][ T3480] RAX: ffffffffffffffda RBX: 0000000001dac010 RCX: 00007f35357d6fb3 [ 50.565142][ T3480] RDX: 0000000000000082 RSI: 0000000001dac2a2 RDI: 0000000000000003 [ 50.568469][ T3480] RBP: 00007ffe0c7212f0 R08: 00007ffe0c7212d0 R09: 0000000000000014 [ 50.571731][ T3480] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000082 [ 50.574961][ T3480] R13: 0000000001dac2a2 R14: 0000000000000001 R15: 0000000000000003 [ 50.578170][ T3480] Modules linked in: sch_ingress virtio_net [ 50.580976][ T3480] ---[ end trace 61a515626a595af6 ]--- CC: Yotam Gigi CC: Jiri Pirko CC: Jamal Hadi Salim CC: Simon Horman CC: Roopa Prabhu Fixes: 6ae0a6286171 ("net: Introduce psample, a new genetlink channel for packet sampling") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8a0092e90559aae1fa8f0d913cb246f79a9727a9 Author: Menglong Dong Date: Mon Nov 25 16:58:09 2019 +0800 macvlan: schedule bc_work even if error [ Upstream commit 1d7ea55668878bb350979c377fc72509dd6f5b21 ] While enqueueing a broadcast skb to port->bc_queue, schedule_work() is called to add port->bc_work, which processes the skbs in bc_queue, to "events" work queue. If port->bc_queue is full, the skb will be discarded and schedule_work(&port->bc_work) won't be called. However, if port->bc_queue is full and port->bc_work is not running or pending, port->bc_queue will keep full and schedule_work() won't be called any more, and all broadcast skbs to macvlan will be discarded. This case can happen: macvlan_process_broadcast() is the pending function of port->bc_work, it moves all the skbs in port->bc_queue to the queue "list", and processes the skbs in "list". During this, new skbs will keep being added to port->bc_queue in macvlan_broadcast_enqueue(), and port->bc_queue may already full when macvlan_process_broadcast() return. This may happen, especially when there are a lot of real-time threads and the process is preempted. Fix this by calling schedule_work(&port->bc_work) even if port->bc_work is full in macvlan_broadcast_enqueue(). Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue") Signed-off-by: Menglong Dong Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 59fd7d5fcae1c9f53fd86d6ed5c814ac6df9a85d Author: Eugen Hristev Date: Fri Apr 12 06:19:46 2019 -0400 media: atmel: atmel-isc: fix INIT_WORK misplacement commit 79199002db5c571e335131856b3ff057ffd9f3c0 upstream. In case the completion function failes, unbind will be called which will call cancel_work for awb_work. This will trigger a WARN message from the workqueue. To avoid this, move the INIT_WORK call at the start of the completion function. This way the work is always initialized, which corresponds to the 'always canceled' unbind code. Fixes: 93d4a26c3d ("[media] atmel-isc: add the isc pipeline function") Signed-off-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 9656c3d14cebe392200005ec906da06e9dbb29bd Author: Eugen Hristev Date: Fri Apr 12 06:19:49 2019 -0400 media: atmel: atmel-isc: fix asd memory allocation commit 1e4e25c4959c10728fbfcc6a286f9503d32dfe02 upstream. The subsystem will free the asd memory on notifier cleanup, if the asd is added to the notifier. However the memory is freed using kfree. Thus, we cannot allocate the asd using devm_* This can lead to crashes and problems. To test this issue, just return an error at probe, but cleanup the notifier beforehand. Fixes: 106267444f ("[media] atmel-isc: add the Image Sensor Controller code") Signed-off-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit a030363e45dcc72534ea12b9a6887db334c5e2b6 Author: Uwe Kleine-König Date: Mon Mar 25 10:49:33 2019 +0100 pwm: Clear chip_data in pwm_put() commit e926b12c611c2095c7976e2ed31753ad6eb5ff1a upstream. After a PWM is disposed by its user the per chip data becomes invalid. Clear the data in common code instead of the device drivers to get consistent behaviour. Before this patch only three of nine drivers cleaned up here. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 9e08b4b72366e3bc1908aed8f15701f99794c2fa Author: Luca Ceresoli Date: Tue May 14 15:23:07 2019 +0200 net: macb: fix error format in dev_err() commit f413cbb332a0b5251a790f396d0eb4ebcade5dec upstream. Errors are negative numbers. Using %u shows them as very large positive numbers such as 4294967277 that don't make sense. Use the %d format instead, and get a much nicer -19. Signed-off-by: Luca Ceresoli Fixes: b48e0bab142f ("net: macb: Migrate to devm clock interface") Fixes: 93b31f48b3ba ("net/macb: unify clock management") Fixes: 421d9df0628b ("net/macb: merge at91_ether driver into macb driver") Fixes: aead88bd0e99 ("net: ethernet: macb: Add support for rx_clk") Fixes: f5473d1d44e4 ("net: macb: Support clock management for tsu_clk") Acked-by: Nicolas Ferre Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 8f93f779f1220d1a912873c179fa2c6f8075eb33 Author: Eugen Hristev Date: Mon Apr 15 10:13:51 2019 -0400 media: v4l2-ctrl: fix flags for DO_WHITE_BALANCE commit a0816e5088baab82aa738d61a55513114a673c8e upstream. Control DO_WHITE_BALANCE is a button, with read only and execute-on-write flags. Adding this control in the proper list in the fill function. After adding it here, we can see output of v4l2-ctl -L do_white_balance 0x0098090d (button) : flags=write-only, execute-on-write Signed-off-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 55b5cbaa468a778fac157141e443e90fe0d201cd Author: Steffen Klassert Date: Wed Nov 6 08:13:49 2019 +0100 xfrm: Fix memleak on xfrm state destroy commit 86c6739eda7d2a03f2db30cbee67a5fb81afa8ba upstream. We leak the page that we use to create skb page fragments when destroying the xfrm_state. Fix this by dropping a page reference if a page was assigned to the xfrm_state. Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Reported-by: JD Reported-by: Paul Wouters Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit c01cffbcdb5273c64a2b4003220a27042afc87c2 Author: Mika Westerberg Date: Mon Nov 11 13:25:44 2019 +0300 thunderbolt: Power cycle the router if NVM authentication fails commit 7a7ebfa85f4fac349f3ab219538c44efe18b0cf6 upstream. On zang's Dell XPS 13 9370 after Thunderbolt NVM firmware upgrade the Thunderbolt controller did not come back as expected. Only after the system was rebooted it became available again. It is not entirely clear what happened but I suspect the new NVM firmware image authentication failed for some reason. Regardless of this the router needs to be power cycled if NVM authentication fails in order to get it fully functional again. This modifies the driver to issue a power cycle in case the NVM authentication fails immediately when dma_port_flash_update_auth() returns. We also need to call tb_switch_set_uuid() earlier to be able to fetch possible NVM authentication failure when DMA port is added. Link: https://bugzilla.kernel.org/show_bug.cgi?id=205457 Reported-by: zang Cc: stable Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 728fd8373780ed9ce1a9af9904c13c5578a55c7f Author: Alexander Usyskin Date: Tue Nov 5 17:05:14 2019 +0200 mei: me: add comet point V device id commit 82b29b9f72afdccb40ea5f3c13c6a3cb65a597bc upstream. Comet Point (Comet Lake) V device id. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20191105150514.14010-2-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit e99fe2c49fc57fce9f492b7543979b12c746557c Author: Alexander Usyskin Date: Tue Nov 5 17:05:13 2019 +0200 mei: bus: prefix device names on bus with the bus name commit 7a2b9e6ec84588b0be65cc0ae45a65bac431496b upstream. Add parent device name to the name of devices on bus to avoid device names collisions for same client UUID available from different MEI heads. Namely this prevents sysfs collision under /sys/bus/mei/device/ In the device part leave just UUID other parameters that are required for device matching are not required here and are just bloating the name. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20191105150514.14010-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit 841a521ca86df782ca7abdb694f454746864a6d0 Author: Fabio D'Urso Date: Thu Nov 14 01:30:53 2019 +0000 USB: serial: ftdi_sio: add device IDs for U-Blox C099-F9P commit c1a1f273d0825774c80896b8deb1c9ea1d0b91e3 upstream. This device presents itself as a USB hub with three attached devices: - An ACM serial port connected to the GPS module (not affected by this commit) - An FTDI serial port connected to the GPS module (1546:0502) - Another FTDI serial port connected to the ODIN-W2 radio module (1546:0503) This commit registers U-Blox's VID and the PIDs of the second and third devices. Datasheet: https://www.u-blox.com/sites/default/files/C099-F9P-AppBoard-Mbed-OS3-FW_UserGuide_%28UBX-18063024%29.pdf Signed-off-by: Fabio D'Urso Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 93d5ab97173000cbb59fe38b24cbb139f1107951 Author: Hans de Goede Date: Mon Nov 11 12:38:45 2019 +0100 staging: rtl8723bs: Add 024c:0525 to the list of SDIO device-ids commit 3d5f1eedbfd22ceea94b39989d6021b1958181f4 upstream. Add 024c:0525 to the list of SDIO device-ids, based on a patch found in the Android X86 kernels. According to that patch this device id is used on the Alcatel Plus 10 device. Reported-and-tested-by: youling257 Signed-off-by: Hans de Goede Cc: stable Link: https://lore.kernel.org/r/20191111113846.24940-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit dba9ff8b016685dde5798daaa66eec71d07bff64 Author: Hans de Goede Date: Mon Nov 11 12:38:46 2019 +0100 staging: rtl8723bs: Drop ACPI device ids commit 2d9d2491530a156b9a5614adf9dc79285e35d55e upstream. The driver only binds by SDIO device-ids, all the ACPI device-id does is causing the driver to load unnecessarily on devices where the DSDT contains a bogus OBDA8723 device. Signed-off-by: Hans de Goede Cc: stable Link: https://lore.kernel.org/r/20191111113846.24940-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0047bb5ac4ac63a8b00caf1f72714dfebef6c903 Author: Pan Bian Date: Tue Nov 5 22:49:11 2019 +0800 staging: rtl8192e: fix potential use after free commit b7aa39a2ed0112d07fc277ebd24a08a7b2368ab9 upstream. The variable skb is released via kfree_skb() when the return value of _rtl92e_tx is not zero. However, after that, skb is accessed again to read its length, which may result in a use after free bug. This patch fixes the bug by moving the release operation to where skb is never used later. Signed-off-by: Pan Bian Reviewed-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/1572965351-6745-1-git-send-email-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman commit 603612d9b9d1eaa5b9b704daf1cdf74e0dad9d47 Author: Mathias Kresin Date: Sun Jul 7 16:22:01 2019 +0200 usb: dwc2: use a longer core rest timeout in dwc2_core_reset() commit 6689f0f4bb14e50917ba42eb9b41c25e0184970c upstream. Testing on different generations of Lantiq MIPS SoC based boards, showed that it takes up to 1500 us until the core reset bit is cleared. The driver from the vendor SDK (ifxhcd) uses a 1 second timeout. Use the same timeout to fix wrong hang detections and make the driver work for Lantiq MIPS SoCs. At least till kernel 4.14 the hanging reset only caused a warning but the driver was probed successful. With kernel 4.19 errors out with EBUSY. Cc: linux-stable # 4.19+ Signed-off-by: Mathias Kresin Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d7b32924172dfde17465dfaf00e940cd472ddff8 Author: Alexandre Belloni Date: Tue Oct 16 16:21:43 2018 +0200 clk: at91: generated: set audio_pll_allowed in at91_clk_register_generated() commit c1e4580a1d0ff510d56268c1fc7fcfeec366fe70 upstream. Set gck->audio_pll_allowed in at91_clk_register_generated. This makes it easier to do it from code that is not parsing device tree. Also, this fixes an issue where the resulting clk_hw can be dereferenced before being tested for error. Fixes: 1a1a36d72e3d ("clk: at91: clk-generated: make gclk determine audio_pll rate") Signed-off-by: Alexandre Belloni Signed-off-by: Stephen Boyd Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 6e82a4e3377b9215e446aa8049e0480f210e0524 Author: Eugen Hristev Date: Mon Sep 9 15:30:31 2019 +0000 clk: at91: fix update bit maps on CFG_MOR write commit 263eaf8f172d9f44e15d6aca85fe40ec18d2c477 upstream. The regmap update bits call was not selecting the proper mask, considering the bits which was updating. Update the mask from call to also include OSCBYPASS. Removed MOSCEN which was not updated. Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally") Signed-off-by: Eugen Hristev Link: https://lkml.kernel.org/r/1568042692-11784-1-git-send-email-eugen.hristev@microchip.com Acked-by: Alexandre Belloni Reviewed-by: Claudiu Beznea Signed-off-by: Stephen Boyd Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 44efbdc479d0e0a45b4257d709dab7bf0f4b8033 Author: Vlastimil Babka Date: Fri Nov 29 10:03:51 2019 +0100 mm, gup: add missing refcount overflow checks on s390 The mainline commit 8fde12ca79af ("mm: prevent get_user_pages() from overflowing page refcount") was backported to 4.19.y stable as commit d972ebbf42ba. The backport however missed that in 4.19, there are several arch-specific gup.c versions with fast gup implementations, so these do not prevent refcount overflow. This stable-only commit fixes the s390 version, and is based on the backport in SUSE SLES/openSUSE 4.12-based kernels. The remaining architectures with own gup.c are sparc, mips, sh. It's unlikely the known overflow scenario based on FUSE, which needs 140GB of RAM, is a problem for those architectures, and I don't feel confident enough to patch them. Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit d00bd54f9994f9c1c8b0d302daba70e32c552d59 Author: Boris Brezillon Date: Wed Jan 30 09:47:00 2019 +0100 mtd: Remove a debug trace in mtdpart.c [ Upstream commit bda2ab56356b9acdfab150f31c4bac9846253092 ] Commit 2b6f0090a333 ("mtd: Check add_mtd_device() ret code") contained a leftover of the debug session that led to this bug fix. Remove this pr_info(). Fixes: 2b6f0090a333 ("mtd: Check add_mtd_device() ret code") Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 7d8677ff106f9410a8b71e4a4de06fe11fec8501 Author: Jesper Dangaard Brouer Date: Fri Mar 29 10:18:00 2019 +0100 xdp: fix cpumap redirect SKB creation bug [ Upstream commit 676e4a6fe703f2dae699ee9d56f14516f9ada4ea ] We want to avoid leaking pointer info from xdp_frame (that is placed in top of frame) like commit 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse"), and followup commit 97e19cce05e5 ("bpf: reserve xdp_frame size in xdp headroom") that reserve this headroom. These changes also affected how cpumap constructed SKBs, as xdpf->headroom size changed, the skb data starting point were in-effect shifted with 32 bytes (sizeof xdp_frame). This was still okay, as the cpumap frame_size calculation also included xdpf->headroom which were reduced by same amount. A bug was introduced in commit 77ea5f4cbe20 ("bpf/cpumap: make sure frame_size for build_skb is aligned if headroom isn't"), where the xdpf->headroom became part of the SKB_DATA_ALIGN rounding up. This round-up to find the frame_size is in principle still correct as it does not exceed the 2048 bytes frame_size (which is max for ixgbe and i40e), but the 32 bytes offset of pkt_data_start puts this over the 2048 bytes limit. This cause skb_shared_info to spill into next frame. It is a little hard to trigger, as the SKB need to use above 15 skb_shinfo->frags[] as far as I calculate. This does happen in practise for TCP streams when skb_try_coalesce() kicks in. KASAN can be used to detect these wrong memory accesses, I've seen: BUG: KASAN: use-after-free in skb_try_coalesce+0x3cb/0x760 BUG: KASAN: wild-memory-access in skb_release_data+0xe2/0x250 Driver veth also construct a SKB from xdp_frame in this way, but is not affected, as it doesn't reserve/deduct the room (used by xdp_frame) from the SKB headroom. Instead is clears the pointers via xdp_scrub_frame(), and allows SKB to use this area. The fix in this patch is to do like veth and instead allow SKB to (re)use the area occupied by xdp_frame, by clearing via xdp_scrub_frame(). (This does kill the idea of the SKB being able to access (mem) info from this area, but I guess it was a bad idea anyhow, and it was already killed by the veth changes.) Fixes: 77ea5f4cbe20 ("bpf/cpumap: make sure frame_size for build_skb is aligned if headroom isn't") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 32a24a397aee35ca2bb0f835b8f3daabd88890fa Author: Gen Zhang Date: Sun May 26 10:42:40 2019 +0800 powerpc/pseries/dlpar: Fix a missing check in dlpar_parse_cc_property() [ Upstream commit efa9ace68e487ddd29c2b4d6dd23242158f1f607 ] In dlpar_parse_cc_property(), 'prop->name' is allocated by kstrdup(). kstrdup() may return NULL, so it should be checked and handle error. And prop should be freed if 'prop->name' is NULL. Signed-off-by: Gen Zhang Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 123b9510b72ad07d6e0fc685c3262da83bdf3184 Author: Hui Wang Date: Mon Apr 29 11:44:07 2019 +0800 ASoC: rt5645: Headphone Jack sense inverts on the LattePanda board [ Upstream commit 406dcbc55a0a20fd155be889a4a0c4b812f7c18e ] The LattePanda board has a sound card chtrt5645, when there is nothing plugged in the headphone jack, the system thinks the headphone is plugged in, while we plug a headphone in the jack, the system thinks the headphone is unplugged. If adding quirk=0x21 in the module parameter, the headphone jack can work well. So let us fix it via platform_data. https://bugs.launchpad.net/bugs/182459 Signed-off-by: Hui Wang Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ec2771128eeeeea1d0b3a7bec9998964c7826ce0 Author: YueHaibing Date: Mon Mar 4 10:56:20 2019 +0800 RDMA/hns: Use GFP_ATOMIC in hns_roce_v2_modify_qp [ Upstream commit 4e69cf1fe2c52d189acdd06c1fd99cc258aba61f ] The the below commit, hns_roce_v2_modify_qp is called inside spinlock while using GFP_KERNEL. Change it to GFP_ATOMIC. Fixes: 0425e3e6e0c7 ("RDMA/hns: Support flush cqe for hip08 in kernel space") Signed-off-by: YueHaibing Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cc84d7b1b215758ed2f48f03621a8945c8dd7ef9 Author: Yixian Liu Date: Sun Feb 3 16:13:04 2019 +0800 RDMA/hns: Fix the state of rereg mr [ Upstream commit ab22bf05216a6bb4812448f3a8609489047cf311 ] The state of mr after reregister operation should be set to valid state. Otherwise, it will keep the same as the state before reregistered. Signed-off-by: Yixian Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 53ac199202e3d2f9560a977877b03619f8d36a8a Author: Lijun Ou Date: Wed Dec 12 17:49:07 2018 +0800 RDMA/hns: Bugfix for the scene without receiver queue [ Upstream commit 4d103905eb1e4f14cb62fcf962c9d35da7005dea ] In some application scenario, the user could not have receive queue when run rdma write or read operation. Signed-off-by: Lijun Ou Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c665760002cd9ebe4f8c5c0e29effd1a3787bc8f Author: Lijun Ou Date: Wed Dec 12 17:49:06 2018 +0800 RDMA/hns: Fix the bug with updating rq head pointer when flush cqe [ Upstream commit 9c6ccc035c209dda07685e8dba829a203ba17499 ] When flush cqe with srq, the driver disable to update the rq head pointer into the hardware. Signed-off-by: Lijun Ou Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 647e8d791bda75e7a5a7c2a03d464e9763e5e1bb Author: John Garry Date: Sat Jan 5 00:01:27 2019 +0800 scsi: libsas: Check SMP PHY control function result [ Upstream commit 01929a65dfa13e18d89264ab1378854a91857e59 ] Currently the SMP PHY control execution result is checked, however the function result for the command is not. As such, we may be missing all potential errors, like SMP FUNCTION FAILED, INVALID REQUEST FRAME LENGTH, etc., meaning the PHY control request has failed. In some scenarios we need to ensure the function result is accepted, so add a check for this. Tested-by: Jian Luo Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 182215d7fb1759a4a2bea929ac33f7a3ae90da09 Author: Xiang Chen Date: Fri Jan 25 22:22:31 2019 +0800 scsi: hisi_sas: shutdown axi bus to avoid exception CQ returned [ Upstream commit 5c31b0c677531c2b8b4e29b3cfb923df663f39b7 ] When injecting 2 bit ECC error, it will cause fatal AXI interrupts. Before the recovery of SAS controller reset, the internal of SAS controller is in error. If CQ interrupts return at the time, actually it is exception CQ interrupt, and it may cause resource release in disorder. To avoid the exception situation, shutdown AXI bus after fatal AXI interrupt. In SAS controller reset, it will restart AXI bus. For later version of v3 hw, hardware will shutdown AXI bus for this situation, so just fix current ver of v3 hw. Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 81ae6e6bfa2704df650f37c59c1ce989cb56536d Author: James Morse Date: Tue Jan 29 18:48:39 2019 +0000 ACPI / APEI: Switch estatus pool to use vmalloc memory [ Upstream commit 0ac234be1a9497498e57d958f4251f5257b116b4 ] The ghes code is careful to parse and round firmware's advertised memory requirements for CPER records, up to a maximum of 64K. However when ghes_estatus_pool_expand() does its work, it splits the requested size into PAGE_SIZE granules. This means if firmware generates 5K of CPER records, and correctly describes this in the table, __process_error() will silently fail as it is unable to allocate more than PAGE_SIZE. Switch the estatus pool to vmalloc() memory. On x86 vmalloc() memory may fault and be fixed up by vmalloc_fault(). To prevent this call vmalloc_sync_all() before an NMI handler could discover the memory. Signed-off-by: James Morse Reviewed-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 07575de062cde051926e1f951548f112d9463637 Author: James Morse Date: Tue Jan 29 18:48:37 2019 +0000 ACPI / APEI: Don't wait to serialise with oops messages when panic()ing [ Upstream commit 78b0b690f6558ed788dccafa45965325dd11ba89 ] oops_begin() exists to group printk() messages with the oops message printed by die(). To reach this caller we know that platform firmware took this error first, then notified the OS via NMI with a 'panic' severity. Don't wait for another CPU to release the die-lock before panic()ing, our only goal is to print this fatal error and panic(). This code is always called in_nmi(), and since commit 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI"), it has been safe to call printk() from this context. Messages are batched in a per-cpu buffer and printed via irq-work, or a call back from panic(). Link: https://patchwork.kernel.org/patch/10313555/ Acked-by: Borislav Petkov Signed-off-by: James Morse Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a0ba8c4e200d775b778d5b8c9f025af0dca6dbff Author: John Garry Date: Sat Jan 5 00:01:28 2019 +0800 scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery [ Upstream commit cec9771d2e954650095aa37a6a97722c8194e7d2 ] +----------+ +----------+ | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk |initiator | | | | device |--- 3.0 G ---| Expander |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SATA disk -->failed to connect | | | | | | | |--- 6.0 G --- SATA disk -->failed to connect | | | | +----------+ +----------+ According to Serial Attached SCSI - 1.1 (SAS-1.1): If an expander PHY attached to a SATA PHY is using a physical link rate greater than the maximum connection rate supported by the pathway from an STP initiator port, a management application client should use the SMP PHY CONTROL function (see 10.4.3.10) to set the PROGRAMMED MAXIMUM PHYSICAL LINK RATE field of the expander PHY to the maximum connection rate supported by the pathway from that STP initiator port. Currently libsas does not support checking if this condition occurs, nor rectifying when it does. Such a condition is not at all common, however it has been seen on some pre-silicon environments where the initiator PHY only supports a 1.5 Gbit maximum linkrate, mated with 12G expander PHYs and 3/6G SATA phy. This patch adds support for checking and rectifying this condition during initial device discovery only. We do support checking min pathway connection rate during revalidation phase, when new devices can be detected in the topology. However we do not support in the case of the the user reprogramming PHY linkrates, such that min pathway condition is not met/maintained. A note on root port PHY rates: The libsas root port PHY rates calculation is broken. Libsas sets the rates (min, max, and current linkrate) of a root port to the same linkrate of the first PHY member of that same port. In doing so, it assumes that all other PHYs which subsequently join the port to have the same negotiated linkrate, when they could actually be different. In practice this doesn't happen, as initiator and expander PHYs are normally initialised with consistent min/max linkrates. This has not caused an issue so far, so leave alone for now. Tested-by: Jian Luo Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d8a89c3e7556dcad72d31ded550b1e9b4ea8842a Author: Chris Coulson Date: Mon Feb 4 10:21:23 2019 +0000 apparmor: delete the dentry in aafs_remove() to avoid a leak [ Upstream commit 201218e4d3dfa1346e30997f48725acce3f26d01 ] Although the apparmorfs dentries are always dropped from the dentry cache when the usage count drops to zero, there is no guarantee that this will happen in aafs_remove(), as another thread might still be using it. In this scenario, this means that the dentry will temporarily continue to appear in the results of lookups, even after the call to aafs_remove(). In the case of removal of a profile - it also causes simple_rmdir() on the profile directory to fail, as the directory won't be empty until the usage counts of all child dentries have decreased to zero. This results in the dentry for the profile directory leaking and appearing empty in the file system tree forever. Signed-off-by: Chris Coulson Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit aa1844c9137e7fae79b94ad87017167320419dee Author: Aaron Ma Date: Wed Mar 13 21:53:24 2019 +0800 iommu/amd: Fix NULL dereference bug in match_hid_uid [ Upstream commit bb6bccba390c7d743c1e4427de4ef284c8cc6869 ] Add a non-NULL check to fix potential NULL pointer dereference Cleanup code to call function once. Signed-off-by: Aaron Ma Fixes: 2bf9a0a12749b ('iommu/amd: Add iommu support for ACPI HID devices') Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 320ab115caf10ce500fbdd9ae9b2d322dc80d744 Author: Peng Li Date: Sat Feb 2 22:39:27 2019 +0800 net: hns3: fix an issue for hns3_update_new_int_gl [ Upstream commit 6241e71e7207102ffc733991f7a00f74098d7da0 ] HNS3 supports setting rx-usecs|tx-usecs as 0, but it will not update dynamically when adaptive-tx or adaptive-rx is enable. This patch removes the Redundant check. Fixes: a95e1f8666e9 ("net: hns3: change the time interval of int_gl calculating") Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 312846d0aebf389af0a67f92d5b12b7dc27ea6b6 Author: Peng Li Date: Thu Jan 31 04:55:50 2019 +0800 net: hns3: fix an issue for hclgevf_ae_get_hdev [ Upstream commit eed9535f9f716a532ec0c5d6cc7a48584acdf435 ] HNS3 VF driver support NIC and Roce, hdev stores NIC handle and Roce handle, should use correct parameter for container_of. Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 64e91fafc2a7412a27747b302c846bbc5f64fb6d Author: Yunsheng Lin Date: Wed Jan 23 07:39:38 2019 +0800 net: hns3: fix PFC not setting problem for DCB module [ Upstream commit d3ad430ac531e65f29c9737f86744c425c9173ef ] The PFC enabling is based on user priority, currently it is based on TC, which may cause PFC not setting correctly when pri to TC mapping is not one to one relation. This patch adds pfc_en in tm_info to fix it. Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature") Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9b40977f6e8d4b4e879dbdb2bf702ebca1843f91 Author: Yunsheng Lin Date: Wed Jan 23 07:39:34 2019 +0800 net: hns3: Change fw error code NOT_EXEC to NOT_SUPPORTED [ Upstream commit 4a402f47cfce904051cd8b31bef4fe2910d9dce9 ] According to firmware error code definition, the error code of 2 means NOT_SUPPORTED, this patch changes it to NOT_SUPPORTED. Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1a5df073d06cfe457ff04ffd3d7172617b06f527 Author: Peng Sun Date: Wed Feb 27 22:36:25 2019 +0800 bpf: drop refcount if bpf_map_new_fd() fails in map_create() [ Upstream commit 352d20d611414715353ee65fc206ee57ab1a6984 ] In bpf/syscall.c, map_create() first set map->usercnt to 1, a file descriptor is supposed to return to userspace. When bpf_map_new_fd() fails, drop the refcount. Fixes: bd5f5f4ecb78 ("bpf: Add BPF_MAP_GET_FD_BY_ID") Signed-off-by: Peng Sun Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 9c458dd158a881e88b4903a249132893b6614e1b Author: Greg Kroah-Hartman Date: Thu Feb 28 16:34:37 2019 +0100 kvm: properly check debugfs dentry before using it [ Upstream commit 8ed0579c12b2fe56a1fac2f712f58fc26c1dc49b ] debugfs can now report an error code if something went wrong instead of just NULL. So if the return value is to be used as a "real" dentry, it needs to be checked if it is an error before dereferencing it. This is now happening because of ff9fb72bc077 ("debugfs: return error values, not NULL"). syzbot has found a way to trigger multiple debugfs files attempting to be created, which fails, and then the error code gets passed to dentry_path_raw() which obviously does not like it. Reported-by: Eric Biggers Reported-and-tested-by: syzbot+7857962b4d45e602b8ad@syzkaller.appspotmail.com Cc: "Radim Krčmář" Cc: kvm@vger.kernel.org Acked-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4ccab1788e9a37d9ebed05f4e306dc915bb6fba0 Author: Andy Shevchenko Date: Wed Feb 27 13:37:26 2019 +0300 net: dev: Use unsigned integer as an argument to left-shift [ Upstream commit f4d7b3e23d259c44f1f1c39645450680fcd935d6 ] 1 << 31 is Undefined Behaviour according to the C standard. Use U type modifier to avoid theoretical overflow. Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b32dc79a5ac557d124fbc124b2d6d61bbc97bcf1 Author: Ming Lei Date: Thu Feb 28 00:02:11 2019 +0800 mmc: core: align max segment size with logical block size [ Upstream commit c53336c8f5f29043fded57912cc06c24e12613d7 ] Logical block size is the lowest possible block size that the storage device can address. Max segment size is often related with controller's DMA capability. And it is reasonable to align max segment size with logical block size. SDHCI sets un-aligned max segment size, and causes ADMA error, so fix it by aligning max segment size with logical block size. Reported-by: Naresh Kamboju Cc: Christoph Hellwig Cc: Naresh Kamboju Cc: Faiz Abbas Cc: linux-block@vger.kernel.org Signed-off-by: Ming Lei Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 944df7b4b9dc1a75ec13e48505402bcc96906a89 Author: Peng Sun Date: Tue Feb 26 22:15:37 2019 +0800 bpf: decrease usercnt if bpf_map_new_fd() fails in bpf_map_get_fd_by_id() [ Upstream commit 781e62823cb81b972dc8652c1827205cda2ac9ac ] In bpf/syscall.c, bpf_map_get_fd_by_id() use bpf_map_inc_not_zero() to increase the refcount, both map->refcnt and map->usercnt. Then, if bpf_map_new_fd() fails, should handle map->usercnt too. Fixes: bd5f5f4ecb78 ("bpf: Add BPF_MAP_GET_FD_BY_ID") Signed-off-by: Peng Sun Acked-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit ddb2badbe975c95841527aff47107bb44ec47009 Author: Maciej Kwiecien Date: Fri Feb 22 09:45:26 2019 +0100 sctp: don't compare hb_timer expire date before starting it [ Upstream commit d1f20c03f48102e52eb98b8651d129b83134cae4 ] hb_timer might not start at all for a particular transport because its start is conditional. In a result a node is not sending heartbeats. Function sctp_transport_reset_hb_timer has two roles: - initial start of hb_timer for a given transport, - update expire date of hb_timer for a given transport. The function is optimized to update timer's expire only if it is before a new calculated one but this comparison is invalid for a timer which has not yet started. Such a timer has expire == 0 and if a new expire value is bigger than (MAX_JIFFIES / 2 + 2) then "time_before" macro will fail and timer will not start resulting in no heartbeat packets send by the node. This was found when association was initialized within first 5 mins after system boot due to jiffies init value which is near to MAX_JIFFIES. Test kernel version: 4.9.154 (ARCH=arm) hb_timer.expire = 0; //initialized, not started timer new_expire = MAX_JIFFIES / 2 + 2; //or more time_before(hb_timer.expire, new_expire) == false Fixes: ba6f5e33bdbb ("sctp: avoid refreshing heartbeat timer too often") Reported-by: Marcin Stojek Tested-by: Marcin Stojek Signed-off-by: Maciej Kwiecien Reviewed-by: Alexander Sverdlin Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b277a8a28810d859e5f477429d1a1eb09ea2f454 Author: Lorenzo Bianconi Date: Tue Feb 19 17:42:06 2019 +0100 net: ip6_gre: do not report erspan_ver for ip6gre or ip6gretap [ Upstream commit 103d0244d29fcaf38f1339d4538919bbbc051490 ] Report erspan version field to userspace in ip6gre_fill_info just for erspan_v6 tunnels. Moreover report IFLA_GRE_ERSPAN_INDEX only for erspan version 1. The issue can be triggered with the following reproducer: $ip link add name gre6 type ip6gre local 2001::1 remote 2002::2 $ip link set gre6 up $ip -d link sh gre6 14: grep6@NONE: mtu 1448 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre6 2001::1 peer 2002::2 promiscuity 0 minmtu 0 maxmtu 0 ip6gre remote 2002::2 local 2001::1 hoplimit 64 encaplimit 4 tclass 0x00 flowlabel 0x00000 erspan_index 0 erspan_ver 0 addrgenmode eui64 Fixes: 94d7d8f29287 ("ip6_gre: add erspan v2 support") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3c81acf23fe1e5ef48eb0f7b1f16eab733040e7 Author: Lorenzo Bianconi Date: Tue Feb 19 17:42:05 2019 +0100 net: ip_gre: do not report erspan_ver for gre or gretap [ Upstream commit 2bdf700e538828d6456150b9319e5f689b062d54 ] Report erspan version field to userspace in ipgre_fill_info just for erspan tunnels. The issue can be triggered with the following reproducer: $ip link add name gre1 type gre local 192.168.0.1 remote 192.168.1.1 $ip link set dev gre1 up $ip -d link sh gre1 13: gre1@NONE: mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 192.168.0.1 peer 192.168.1.1 promiscuity 0 minmtu 0 maxmtu 0 gre remote 192.168.1.1 local 192.168.0.1 ttl inherit erspan_ver 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 Fixes: f551c91de262 ("net: erspan: introduce erspan v2 for ip_gre") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1dde4137a041ff4c928e3879cb95b300d901e9e Author: Eric Dumazet Date: Tue Feb 12 12:26:27 2019 -0800 net: fix possible overflow in __sk_mem_raise_allocated() [ Upstream commit 5bf325a53202b8728cf7013b72688c46071e212e ] With many active TCP sockets, fat TCP sockets could fool __sk_mem_raise_allocated() thanks to an overflow. They would increase their share of the memory, instead of decreasing it. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d5e2bb84851df18fc99884df89b4b44a297fabf Author: Matteo Croce Date: Mon Feb 11 15:32:36 2019 +0100 geneve: change NET_UDP_TUNNEL dependency to select [ Upstream commit a7603ac1fc8ce1409f8ff70e6ce505f308b2c002 ] Due to the depends on NET_UDP_TUNNEL, at the moment it is impossible to compile GENEVE if no other protocol depending on NET_UDP_TUNNEL is selected. Fix this changing the depends to a select, and drop NET_IP_TUNNEL from the select list, as it already depends on NET_UDP_TUNNEL. Signed-off-by: Matteo Croce Reviewed-and-tested-by: Andrea Claudi Tested-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bed231aa94949312b4072540cf8ed8ddf55dab90 Author: Bert Kenward Date: Tue Feb 12 13:10:00 2019 +0000 sfc: initialise found bitmap in efx_ef10_mtd_probe [ Upstream commit c65285428b6e7797f1bb063f33b0ae7e93397b7b ] The bitmap of found partitions in efx_ef10_mtd_probe was not initialised, causing partitions to be suppressed based off whatever value was in the bitmap at the start. Fixes: 3366463513f5 ("sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe") Signed-off-by: Bert Kenward Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fe8e9fdf449e0500602ca79355feb41113ee4a31 Author: Sylwester Nawrocki Date: Thu Feb 7 18:00:12 2019 +0100 ASoC: samsung: i2s: Fix prescaler setting for the secondary DAI [ Upstream commit 323fb7b947b265753de34703dbbf8acc8ea3a4de ] Make sure i2s->rclk_srcrate is properly initialized also during playback through the secondary DAI. Signed-off-by: Sylwester Nawrocki Acked-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 66bccc6afb826bb3835aae9a7f28aed22fe8165e Author: Hoang Le Date: Mon Feb 11 09:18:28 2019 +0700 tipc: fix skb may be leaky in tipc_link_input [ Upstream commit 7384b538d3aed2ed49d3575483d17aeee790fb06 ] When we free skb at tipc_data_input, we return a 'false' boolean. Then, skb passed to subcalling tipc_link_input in tipc_link_rcv, 1303 int tipc_link_rcv: ... 1354 if (!tipc_data_input(l, skb, l->inputq)) 1355 rc |= tipc_link_input(l, skb, l->inputq); Fix it by simple changing to a 'true' boolean when skb is being free-ed. Then, tipc_link_rcv will bypassed to subcalling tipc_link_input as above condition. Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c29e33a2245be2a2a21657cf0d7a962e66e9b9b Author: Ursula Braun Date: Thu Feb 7 14:52:54 2019 +0100 net/smc: fix byte_order for rx_curs_confirmed [ Upstream commit ccc8ca9b90acb45a3309f922b2591b07b4e070ec ] The recent change in the rx_curs_confirmed assignment disregards byte order, which causes problems on little endian architectures. This patch fixes it. Fixes: b8649efad879 ("net/smc: fix sender_free computation") (net-tree) Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 932ff095dac83d9ded67b8971c38631343368a2f Author: Jan Kara Date: Thu Feb 7 11:55:39 2019 +0100 blktrace: Show requests without sector [ Upstream commit 0803de78049fe1b0baf44bcddc727b036fb9139b ] Currently, blktrace will not show requests that don't have any data as rq->__sector is initialized to -1 which is out of device range and thus discarded by act_log_check(). This is most notably the case for cache flush requests sent to the device. Fix the problem by making blk_rq_trace_sector() return 0 for requests without initialized sector. Reviewed-by: Johannes Thumshirn Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e2b5978b30e8c0461dc5499d3c4981e69383a92a Author: Ursula Braun Date: Mon Feb 4 13:44:45 2019 +0100 net/smc: fix sender_free computation [ Upstream commit b8649efad879c69c7ab1f19ce8814fcabef1f72b ] In some scenarios a separate consumer cursor update is necessary. The decision is made in smc_tx_consumer_cursor_update(). The sender_free computation could be wrong: The rx confirmed cursor is always smaller than or equal to the rx producer cursor. The parameters in the smc_curs_diff() call have to be exchanged, otherwise sender_free might even be negative. And if more data arrives local_rx_ctrl.prod might be updated, enabling a cursor difference between local_rx_ctrl.prod and rx confirmed cursor larger than the RMB size. This case is not covered by smc_curs_diff(). Thus function smc_curs_diff_large() is introduced here. If a recvmsg() is processed in parallel, local_tx_ctrl.cons might change during smc_cdc_msg_send. Make sure rx_curs_confirmed is updated with the actually sent local_tx_ctrl.cons value. Fixes: e82f2e31f559 ("net/smc: optimize consumer cursor updates") Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fe685954ee73da1e2a2b3c40d995409790a3a862 Author: Brian Foster Date: Sun Feb 3 14:03:06 2019 -0800 xfs: end sync buffer I/O properly on shutdown error [ Upstream commit 465fa17f4a303d9fdff9eac4d45f91ece92e96ca ] As of commit e339dd8d8b ("xfs: use sync buffer I/O for sync delwri queue submission"), the delwri submission code uses sync buffer I/O for sync delwri I/O. Instead of waiting on async I/O to unlock the buffer, it uses the underlying sync I/O completion mechanism. If delwri buffer submission fails due to a shutdown scenario, an error is set on the buffer and buffer completion never occurs. This can cause xfs_buf_delwri_submit() to deadlock waiting on a completion event. We could check the error state before waiting on such buffers, but that doesn't serialize against the case of an error set via a racing I/O completion. Instead, invoke I/O completion in the shutdown case regardless of buffer I/O type. Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 9803fc4f4aacb6cb7b40ec969f605bc06128435e Author: Qian Cai Date: Fri Feb 1 14:20:51 2019 -0800 mm/hotplug: invalid PFNs from pfn_to_online_page() [ Upstream commit b13bc35193d9e7a8c050a24928ca5c9e7c9a009b ] On an arm64 ThunderX2 server, the first kmemleak scan would crash [1] with CONFIG_DEBUG_VM_PGFLAGS=y due to page_to_nid() found a pfn that is not directly mapped (MEMBLOCK_NOMAP). Hence, the page->flags is uninitialized. This is due to the commit 9f1eb38e0e11 ("mm, kmemleak: little optimization while scanning") starts to use pfn_to_online_page() instead of pfn_valid(). However, in the CONFIG_MEMORY_HOTPLUG=y case, pfn_to_online_page() does not call memblock_is_map_memory() while pfn_valid() does. Historically, the commit 68709f45385a ("arm64: only consider memblocks with NOMAP cleared for linear mapping") causes pages marked as nomap being no long reassigned to the new zone in memmap_init_zone() by calling __init_single_page(). Since the commit 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes") introduced pfn_to_online_page() and was designed to return a valid pfn only, but it is clearly broken on arm64. Therefore, let pfn_to_online_page() call pfn_valid_within(), so it can handle nomap thanks to the commit f52bb98f5ade ("arm64: mm: always enable CONFIG_HOLES_IN_ZONE"), while it will be optimized away on architectures where have no HOLES_IN_ZONE. [1] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000006 Mem abort info: ESR = 0x96000005 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 Internal error: Oops: 96000005 [#1] SMP CPU: 60 PID: 1408 Comm: kmemleak Not tainted 5.0.0-rc2+ #8 pstate: 60400009 (nZCv daif +PAN -UAO) pc : page_mapping+0x24/0x144 lr : __dump_page+0x34/0x3dc sp : ffff00003a5cfd10 x29: ffff00003a5cfd10 x28: 000000000000802f x27: 0000000000000000 x26: 0000000000277d00 x25: ffff000010791f56 x24: ffff7fe000000000 x23: ffff000010772f8b x22: ffff00001125f670 x21: ffff000011311000 x20: ffff000010772f8b x19: fffffffffffffffe x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: ffff802698b19600 x13: ffff802698b1a200 x12: ffff802698b16f00 x11: ffff802698b1a400 x10: 0000000000001400 x9 : 0000000000000001 x8 : ffff00001121a000 x7 : 0000000000000000 x6 : ffff0000102c53b8 x5 : 0000000000000000 x4 : 0000000000000003 x3 : 0000000000000100 x2 : 0000000000000000 x1 : ffff000010772f8b x0 : ffffffffffffffff Process kmemleak (pid: 1408, stack limit = 0x(____ptrval____)) Call trace: page_mapping+0x24/0x144 __dump_page+0x34/0x3dc dump_page+0x28/0x4c kmemleak_scan+0x4ac/0x680 kmemleak_scan_thread+0xb4/0xdc kthread+0x12c/0x13c ret_from_fork+0x10/0x18 Code: d503201f f9400660 36000040 d1000413 (f9400661) ---[ end trace 4d4bd7f573490c8e ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x002,20000c38 Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception ]--- Link: http://lkml.kernel.org/r/20190122132916.28360-1-cai@lca.pw Fixes: 9f1eb38e0e11 ("mm, kmemleak: little optimization while scanning") Signed-off-by: Qian Cai Acked-by: Michal Hocko Cc: Oscar Salvador Cc: Catalin Marinas Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit aa69ab5882afa15762197f011bed3a6f6000dfb1 Author: Karsten Graul Date: Wed Jan 30 18:51:03 2019 +0100 net/smc: don't wait for send buffer space when data was already sent [ Upstream commit 6889b36da78a21a312d8b462c1fa25a03c2ff192 ] When there is no more send buffer space and at least 1 byte was already sent then return to user space. The wait is only done when no data was sent by the sendmsg() call. This fixes smc_tx_sendmsg() which tried to always send all user data and started to wait for free send buffer space when needed. During this wait the user space program was blocked in the sendmsg() call and hence not able to receive incoming data. When both sides were in such a situation then the connection stalled forever. Signed-off-by: Karsten Graul Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f8e7423f5e182d60a0350c455195af5ff63f67cb Author: Karsten Graul Date: Wed Jan 30 18:51:02 2019 +0100 net/smc: prevent races between smc_lgr_terminate() and smc_conn_free() [ Upstream commit 77f838ace755d2f466536c44dac6c856f62cd901 ] To prevent races between smc_lgr_terminate() and smc_conn_free() add an extra check of the lgr field before accessing it, and cancel a delayed free_work when a new smc connection is created. This fixes the problem that free_work cleared the lgr variable but smc_lgr_terminate() or smc_conn_free() still access it in parallel. Signed-off-by: Karsten Graul Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dcb901cebe0f1e97fb6d5fc9adafe65515785e6f Author: Johannes Berg Date: Sat Jan 26 21:12:19 2019 +0100 decnet: fix DN_IFREQ_SIZE [ Upstream commit 50c2936634bcb1db78a8ca63249236810c11a80f ] Digging through the ioctls with Al because of the previous patches, we found that on 64-bit decnet's dn_dev_ioctl() is wrong, because struct ifreq::ifr_ifru is actually 24 bytes (not 16 as expected from struct sockaddr) due to the ifru_map and ifru_settings members. Clearly, decnet expects the ioctl to be called with a struct like struct ifreq_dn { char ifr_name[IFNAMSIZ]; struct sockaddr_dn ifr_addr; }; since it does struct ifreq *ifr = ...; struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr; This means that DN_IFREQ_SIZE is too big for what it wants on 64-bit, as it is sizeof(struct ifreq) - sizeof(struct sockaddr) + sizeof(struct sockaddr_dn) This assumes that sizeof(struct sockaddr) is the size of ifr_ifru but that isn't true. Fix this to use offsetof(struct ifreq, ifr_ifru). This indeed doesn't really matter much - the result is that we copy in/out 8 bytes more than we should on 64-bit platforms. In case the "struct ifreq_dn" lands just on the end of a page though it might lead to faults. As far as I can tell, it has been like this forever, so it seems very likely that nobody cares. Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9f1ac494023d7adde34814612e44efecf4b8e4e6 Author: wenxu Date: Sat Jan 19 13:11:25 2019 +0800 ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel [ Upstream commit d71b57532d70c03f4671dd04e84157ac6bf021b0 ] ip l add dev tun type gretap key 1000 ip a a dev tun 10.0.0.1/24 Packets with tun-id 1000 can be recived by tun dev. But packet can't be sent through dev tun for non-tunnel-dst With this patch: tunnel-dst can be get through lwtunnel like beflow: ip r a 10.0.0.7 encap ip dst 172.168.0.11 dev tun Signed-off-by: wenxu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2269278085f7c505b70d7ca6a2118ad45b966cd7 Author: Edward Cree Date: Tue Jan 22 19:02:17 2019 +0000 sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe [ Upstream commit 3366463513f544c12c6b88c13da4462ee9e7a1a1 ] Use a bitmap to keep track of which partition types we've already seen; for duplicates, return -EEXIST from efx_ef10_mtd_probe_partition() and thus skip adding that partition. Duplicate partitions occur because of the A/B backup scheme used by newer sfc NICs. Prior to this patch they cause sysfs_warn_dup errors because they have the same name, causing us not to expose any MTDs at all. Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d9566fb14f0e24d6472c425fd1d64746a257287 Author: Lucas Stach Date: Tue Dec 18 16:46:29 2018 +0100 gpu: ipu-v3: pre: don't trigger update if buffer address doesn't change [ Upstream commit eb0200a4357da100064971689d3a0e9e3cf57f33 ] On a NOP double buffer update where current buffer address is the same as the next buffer address, the SDW_UPDATE bit clears too late. As we are now using this bit to determine when it is safe to signal flip completion to userspace this will delay completion of atomic commits where one plane doesn't change the buffer by a whole frame period. Fix this by remembering the last buffer address and just skip the double buffer update if it would not change the buffer address. Signed-off-by: Lucas Stach [p.zabel@pengutronix.de: initialize last_bufaddr in ipu_pre_configure] Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 498ce67eb68c38d73c998ff0de6972e0dcf4d10d Author: He Zhe Date: Thu Jan 17 17:00:19 2019 +0800 serial: 8250: Fix serial8250 initialization crash [ Upstream commit 352c4cf40c4a7d439fa5d30aa2160f54b394da82 ] The initialization code of interrupt backoff work might reference NULL pointer and cause the following crash, if no port was found. [ 10.017727] CPU 0 Unable to handle kernel paging request at virtual address 000001b0, epc == 807088e0, ra == 8070863c ---- snip ---- [ 11.704470] [<807088e0>] serial8250_register_8250_port+0x318/0x4ac [ 11.747251] [<80708d74>] serial8250_probe+0x148/0x1c0 [ 11.789301] [<80728450>] platform_drv_probe+0x40/0x94 [ 11.830515] [<807264f8>] really_probe+0xf8/0x318 [ 11.870876] [<80726b7c>] __driver_attach+0x110/0x12c [ 11.910960] [<80724374>] bus_for_each_dev+0x78/0xcc [ 11.951134] [<80725958>] bus_add_driver+0x200/0x234 [ 11.989756] [<807273d8>] driver_register+0x84/0x148 [ 12.029832] [<80d72f84>] serial8250_init+0x138/0x198 [ 12.070447] [<80100e6c>] do_one_initcall+0x5c/0x2a0 [ 12.110104] [<80d3a208>] kernel_init_freeable+0x370/0x484 [ 12.150722] [<80a49420>] kernel_init+0x10/0xf8 [ 12.191517] [<8010756c>] ret_from_kernel_thread+0x14/0x1c This patch makes sure the initialization code can be reached only if a port is found. Fixes: 6d7f677a2afa ("serial: 8250: Rate limit serial port rx interrupts during input overruns") Signed-off-by: He Zhe Reviewed-by: Darwin Dingel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 91e161b62d13851f71644c3fa6c02ec5b4e46388 Author: Konstantin Khlebnikov Date: Mon Jan 14 13:38:43 2019 +0300 net/core/neighbour: fix kmemleak minimal reference count for hash tables [ Upstream commit 01b833ab44c9e484060aad72267fc7e71beb559b ] This should be 1 for normal allocations, 0 disables leak reporting. Signed-off-by: Konstantin Khlebnikov Reported-by: Cong Wang Fixes: 85704cb8dcfd ("net/core/neighbour: tell kmemleak about hash tables") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3e059545043dc13774d2b689edb44dbed071869f Author: Ming Lei Date: Tue Jan 15 17:31:29 2019 -0600 PCI/MSI: Return -ENOSPC from pci_alloc_irq_vectors_affinity() [ Upstream commit 77f88abd4a6f73a1a68dbdc0e3f21575fd508fc3 ] The API of pci_alloc_irq_vectors_affinity() says it returns -ENOSPC if fewer than @min_vecs interrupt vectors are available for @dev. However, if a device supports MSI-X but not MSI and a caller requests @min_vecs that can't be satisfied by MSI-X, we previously returned -EINVAL (from the failed attempt to enable MSI), not -ENOSPC. When -ENOSPC is returned, callers may reduce the number IRQs they request and try again. Most callers can use the @min_vecs and @max_vecs parameters to avoid this retry loop, but that doesn't work when using IRQ affinity "nr_sets" because rebalancing the sets is driver-specific. This return value bug has been present since pci_alloc_irq_vectors() was added in v4.10 by aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines"), but it wasn't an issue because @min_vecs/@max_vecs removed the need for callers to iteratively reduce the number of IRQs requested and retry the allocation, so they didn't need to distinguish -ENOSPC from -EINVAL. In v5.0, 6da4b3ab9a6e ("genirq/affinity: Add support for allocating interrupt sets") added IRQ sets to the interface, which reintroduced the need to check for -ENOSPC and possibly reduce the number of IRQs requested and retry the allocation. Signed-off-by: Ming Lei [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Cc: Jens Axboe Cc: Keith Busch Cc: Christoph Hellwig Signed-off-by: Sasha Levin commit d5c58be987bb73c6f5e9e24f9a4dc2703d035849 Author: Miquel Raynal Date: Tue Dec 4 20:28:27 2018 +0100 ata: ahci: mvebu: do Armada 38x configuration only on relevant SoCs [ Upstream commit 96dbcb40e4b1a387cdb9b21f43638c759aebb5a4 ] At the beginning, only Armada 38x SoCs where supported by the ahci_mvebu.c driver. Commit 15d3ce7b63bd ("ata: ahci_mvebu: add support for Armada 3700 variant") introduced Armada 3700 support. As opposed to Armada 38x SoCs, the 3700 variants do not have to configure mbus and the regret option. This patch took care of avoiding such configuration when not needed in the probe function, but failed to do the same in the resume path. While doing so looks harmless by experience, let's clean the driver logic and avoid doing this useless configuration with Armada 3700 SoCs. Because the logic is very similar between these two places, it has been decided to factorize this code and put it in a "Armada 38x configuration function". This function is part of a new (per-compatible) platform data structure, so that the addition of such configuration function for Armada 3700 will be eased. Fixes: 15d3ce7b63bd ("ata: ahci_mvebu: add support for Armada 3700 variant") Signed-off-by: Miquel Raynal Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 725bbd5ce9f4e0253b5f6924521ce9f6423c3b76 Author: Konstantin Khlebnikov Date: Tue Jan 8 12:30:00 2019 +0300 net/core/neighbour: tell kmemleak about hash tables [ Upstream commit 85704cb8dcfd88d351bfc87faaeba1c8214f3177 ] This fixes false-positive kmemleak reports about leaked neighbour entries: unreferenced object 0xffff8885c6e4d0a8 (size 1024): comm "softirq", pid 0, jiffies 4294922664 (age 167640.804s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 20 2c f3 83 ff ff ff ff ........ ,...... 08 c0 ef 5f 84 88 ff ff 01 8c 7d 02 01 00 00 00 ..._......}..... backtrace: [<00000000748509fe>] ip6_finish_output2+0x887/0x1e40 [<0000000036d7a0d8>] ip6_output+0x1ba/0x600 [<0000000027ea7dba>] ip6_send_skb+0x92/0x2f0 [<00000000d6e2111d>] udp_v6_send_skb.isra.24+0x680/0x15e0 [<000000000668a8be>] udpv6_sendmsg+0x18c9/0x27a0 [<000000004bd5fa90>] sock_sendmsg+0xb3/0xf0 [<000000008227b29f>] ___sys_sendmsg+0x745/0x8f0 [<000000008698009d>] __sys_sendmsg+0xde/0x170 [<00000000889dacf1>] do_syscall_64+0x9b/0x400 [<0000000081cdb353>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000005767ed39>] 0xffffffffffffffff Signed-off-by: Konstantin Khlebnikov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7717d9830b5600830f881f300e9e51887f64724c Author: Gustavo A. R. Silva Date: Sat Jan 5 10:52:23 2019 -0600 tipc: fix memory leak in tipc_nl_compat_publ_dump [ Upstream commit f87d8ad9233f115db92c6c087d58403b0009ed36 ] There is a memory leak in case genlmsg_put fails. Fix this by freeing *args* before return. Addresses-Coverity-ID: 1476406 ("Resource leak") Fixes: 46273cf7e009 ("tipc: fix a missing check of genlmsg_put") Signed-off-by: Gustavo A. R. Silva Acked-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c4c8e4f800b4871b4794df84fecb0d4e73987de Author: Boris Brezillon Date: Wed Jan 2 15:36:54 2019 +0100 mtd: Check add_mtd_device() ret code [ Upstream commit 2b6f0090a3335b7bdd03ca520c35591159463041 ] add_mtd_device() can fail. We should always check its return value and gracefully handle the failure case. Fix the call sites where this not done (in mtdpart.c) and add a __must_check attribute to the prototype to avoid this kind of mistakes. Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 6a471a2665a988641b177553e1493831dd2acea2 Author: Olof Johansson Date: Sat Jan 5 13:21:18 2019 -0800 lib/genalloc.c: include vmalloc.h [ Upstream commit 35004f2e55807a1a1491db24ab512dd2f770a130 ] Fixes build break on most ARM/ARM64 defconfigs: lib/genalloc.c: In function 'gen_pool_add_virt': lib/genalloc.c:190:10: error: implicit declaration of function 'vzalloc_node'; did you mean 'kzalloc_node'? lib/genalloc.c:190:8: warning: assignment to 'struct gen_pool_chunk *' from 'int' makes pointer from integer without a cast [-Wint-conversion] lib/genalloc.c: In function 'gen_pool_destroy': lib/genalloc.c:254:3: error: implicit declaration of function 'vfree'; did you mean 'kfree'? Fixes: 6862d2fc8185 ('lib/genalloc.c: use vzalloc_node() to allocate the bitmap') Cc: Huang Shijie Cc: Andrew Morton Cc: Alexey Skidanov Signed-off-by: Olof Johansson Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4da8c782c47eace0399b834476596cdf1fa7c3d6 Author: Qian Cai Date: Thu Jan 3 15:29:05 2019 -0800 drivers/base/platform.c: kmemleak ignore a known leak [ Upstream commit 967d3010df8b6f6f9aa95c198edc5fe3646ebf36 ] unreferenced object 0xffff808ec6dc5a80 (size 128): comm "swapper/0", pid 1, jiffies 4294938063 (age 2560.530s) hex dump (first 32 bytes): ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace: [<00000000476dcf8c>] kmem_cache_alloc_trace+0x430/0x500 [<000000004f708d37>] platform_device_register_full+0xbc/0x1e8 [<000000006c2a7ec7>] acpi_create_platform_device+0x370/0x450 [<00000000ef135642>] acpi_default_enumeration+0x34/0x78 [<000000003bd9a052>] acpi_bus_attach+0x2dc/0x3e0 [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0 [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0 [<000000002968643e>] acpi_bus_scan+0xb0/0x110 [<0000000010dd0bd7>] acpi_scan_init+0x1a8/0x410 [<00000000965b3c5a>] acpi_init+0x408/0x49c [<00000000ed4b9fe2>] do_one_initcall+0x178/0x7f4 [<00000000a5ac5a74>] kernel_init_freeable+0x9d4/0xa9c [<0000000070ea6c15>] kernel_init+0x18/0x138 [<00000000fb8fff06>] ret_from_fork+0x10/0x1c [<0000000041273a0d>] 0xffffffffffffffff Then, faddr2line pointed out this line, /* * This memory isn't freed when the device is put, * I don't have a nice idea for that though. Conceptually * dma_mask in struct device should not be a pointer. * See http://thread.gmane.org/gmane.linux.kernel.pci/9081 */ pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); Since this leak has existed for more than 8 years and it does not reference other parts of the memory, let kmemleak ignore it, so users don't need to waste time reporting this in the future. Link: http://lkml.kernel.org/r/20181206160751.36211-1-cai@gmx.us Signed-off-by: Qian Cai Reviewed-by: Andrew Morton Cc: Greg Kroah-Hartman Cc: "Rafael J . Wysocki" Cc: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fc38279ec51ae7c8022da085061a8b4c5f9e9c20 Author: Yi Wang Date: Thu Jan 3 15:28:03 2019 -0800 fork: fix some -Wmissing-prototypes warnings [ Upstream commit fb5bf31722d0805a3f394f7d59f2e8cd07acccb7 ] We get a warning when building kernel with W=1: kernel/fork.c:167:13: warning: no previous prototype for `arch_release_thread_stack' [-Wmissing-prototypes] kernel/fork.c:779:13: warning: no previous prototype for `fork_init' [-Wmissing-prototypes] Add the missing declaration in head file to fix this. Also, remove arch_release_thread_stack() completely because no arch seems to implement it since bb9d81264 (arch: remove tile port). Link: http://lkml.kernel.org/r/1542170087-23645-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by: Yi Wang Acked-by: Michal Hocko Acked-by: Mike Rapoport Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0321fe1cdd706f6f326addfd6cd90d0e92e5fe67 Author: Huang Shijie Date: Thu Jan 3 15:26:51 2019 -0800 lib/genalloc.c: use vzalloc_node() to allocate the bitmap [ Upstream commit 6862d2fc81859f88c1f3f660886427893f2b4f3f ] Some devices may have big memory on chip, such as over 1G. In some cases, the nbytes maybe bigger then 4M which is the bounday of the memory buddy system (4K default). So use vzalloc_node() to allocate the bitmap. Also use vfree to free it. Link: http://lkml.kernel.org/r/20181225015701.6289-1-sjhuang@iluvatar.ai Signed-off-by: Huang Shijie Reviewed-by: Andrew Morton Cc: Alexey Skidanov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 28fb78ccb59063d5b3cb81504b4705faed83b0e0 Author: Alexey Skidanov Date: Thu Jan 3 15:26:44 2019 -0800 lib/genalloc.c: fix allocation of aligned buffer from non-aligned chunk [ Upstream commit 52fbf1134d479234d7e64ba9dcbaea23405f229e ] gen_pool_alloc_algo() uses different allocation functions implementing different allocation algorithms. With gen_pool_first_fit_align() allocation function, the returned address should be aligned on the requested boundary. If chunk start address isn't aligned on the requested boundary, the returned address isn't aligned too. The only way to get properly aligned address is to initialize the pool with chunks aligned on the requested boundary. If want to have an ability to allocate buffers aligned on different boundaries (for example, 4K, 1MB, ...), the chunk start address should be aligned on the max possible alignment. This happens because gen_pool_first_fit_align() looks for properly aligned memory block without taking into account the chunk start address alignment. To fix this, we provide chunk start address to gen_pool_first_fit_align() and change its implementation such that it starts looking for properly aligned block with appropriate offset (exactly as is done in CMA). Link: https://lkml.kernel.org/lkml/a170cf65-6884-3592-1de9-4c235888cc8a@intel.com Link: http://lkml.kernel.org/r/1541690953-4623-1-git-send-email-alexey.skidanov@intel.com Signed-off-by: Alexey Skidanov Reviewed-by: Andrew Morton Cc: Logan Gunthorpe Cc: Daniel Mentz Cc: Mathieu Desnoyers Cc: Laura Abbott Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit eccc6a2c5354a89f83bab8dfe92094d302c80cb1 Author: James Morse Date: Fri Dec 21 19:25:19 2018 +0000 firmware: arm_sdei: Fix DT platform device creation [ Upstream commit acafce48b07bf5f9994a38e7fe237193d43d092e ] It turns out the dt-probing part of this wasn't tested properly after it was merged. commit 3aa0582fdb82 ("of: platform: populate /firmware/ node from of_platform_default_populate_init()") changed the core-code to generate the platform devices, meaning the driver's attempt fails, and it bails out. Fix this by removing the manual platform-device creation for DT systems, core code has always done this for us. CC: Nicolas Saenz Julienne Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d393cc60c6ea2b74b42c799f8ae71ea8f38699cb Author: Nicolas Saenz Julienne Date: Fri Dec 21 19:25:18 2018 +0000 firmware: arm_sdei: fix wrong of_node_put() in init function [ Upstream commit c3790b3799f8d75d93d26f6fd7bb569fc8c8b0cb ] After finding a "firmware" dt node arm_sdei tries to match it's compatible string with it. To do so it's calling of_find_matching_node() which already takes care of decreasing the refcount on the "firmware" node. We are then incorrectly decreasing the refcount on that node again. This patch removes the unwarranted call to of_node_put(). Signed-off-by: Nicolas Saenz Julienne Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 77a9b90d266b06abf3c90073b14fa83543b86234 Author: Aditya Pakki Date: Mon Dec 24 12:24:45 2018 -0600 infiniband/qedr: Potential null ptr dereference of qp [ Upstream commit 9c6260de505b63638dd86fcc33849b17f6146d94 ] idr_find() may fail and return a NULL pointer. The fix checks the return value of the function and returns an error in case of NULL. Signed-off-by: Aditya Pakki Acked-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6a9d929bc9faa106f345d486d9a3a749cf4bb0ea Author: Aditya Pakki Date: Wed Dec 26 12:56:22 2018 -0600 infiniband: bnxt_re: qplib: Check the return value of send_message [ Upstream commit 94edd87a1c59f3efa6fdf4e98d6d492e6cec6173 ] In bnxt_qplib_map_tc2cos(), bnxt_qplib_rcfw_send_message() can return an error value but it is lost. Propagate this error to the callers. Signed-off-by: Aditya Pakki Acked-By: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d95b814359f0b533570fe80f96603f70f09c9e17 Author: Chuck Lever Date: Fri Dec 7 11:11:44 2018 -0500 xprtrdma: Prevent leak of rpcrdma_rep objects [ Upstream commit 07e10308ee5da8e6132e0b737ece1c99dd651fb6 ] If a reply has been processed but the RPC is later retransmitted anyway, the req->rl_reply field still contains the only pointer to the old rpcrdma rep. When the next reply comes in, the reply handler will stomp on the rl_reply field, leaking the old rep. A trace event is added to capture such leaks. This problem seems to be worsened by the restructuring of the RPC Call path in v4.20. Fully addressing this issue will require at least a re-architecture of the disconnect logic, which is not appropriate during -rc. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d398807976c904be4dfa2e7804d4ab43aa904774 Author: Kangjie Lu Date: Fri Dec 21 00:46:23 2018 -0600 netfilter: nf_tables: fix a missing check of nla_put_failure [ Upstream commit eb8950861c1bfd3eecc8f6faad213e3bca0dc395 ] If nla_nest_start() may fail. The fix checks its return value and goes to nla_put_failure if it fails. Signed-off-by: Kangjie Lu Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a787b7ac3cc79cc8ad02e91385b9c7f5adebd31c Author: Anthony Yznaga Date: Fri Dec 28 00:37:27 2018 -0800 tools/vm/page-types.c: fix "kpagecount returned fewer pages than expected" failures [ Upstream commit b6fb87b8e3ff1ef6bcf68470f24a97c984554d5a ] Because kpagecount_read() fakes success if map counts are not being collected, clamp the page count passed to it by walk_pfn() to the pages value returned by the preceding call to kpageflags_read(). Link: http://lkml.kernel.org/r/1543962269-26116-1-git-send-email-anthony.yznaga@oracle.com Fixes: 7f1d23e60718 ("tools/vm/page-types.c: include shared map counts") Signed-off-by: Anthony Yznaga Reviewed-by: Naoya Horiguchi Cc: Vlastimil Babka Cc: Matthew Wilcox Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5643569bec7d03e49c27e732e011219af87caeaf Author: Wentao Wang Date: Fri Dec 28 00:35:26 2018 -0800 mm/page_alloc.c: deduplicate __memblock_free_early() and memblock_free() [ Upstream commit d31cfe7bff9109476da92c245b56083e9b48d60a ] Link: http://lkml.kernel.org/r/C8ECE1B7A767434691FEEFA3A01765D72AFB8E78@MX203CL03.corp.emc.com Signed-off-by: Wentao Wang Reviewed-by: Andrew Morton Cc: Mike Rapoport Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9696c7656e3d90d5ddee74946c70bd6b6099a7d8 Author: Aaron Lu Date: Fri Dec 28 00:35:22 2018 -0800 mm/page_alloc.c: use a single function to free page [ Upstream commit 742aa7fb52c56fb3b307e704f93e67b698959cc2 ] There are multiple places of freeing a page, they all do the same things so a common function can be used to reduce code duplicate. It also avoids bug fixed in one function but left in another. Link: http://lkml.kernel.org/r/20181119134834.17765-3-aaron.lu@intel.com Signed-off-by: Aaron Lu Acked-by: Vlastimil Babka Cc: Alexander Duyck Cc: Ilias Apalodimas Cc: Jesper Dangaard Brouer Cc: Mel Gorman Cc: Pankaj gupta Cc: Pawel Staszewski Cc: Tariq Toukan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 257ad5fbfe06c59f877aa781c5e185de61d2264c Author: Aaron Lu Date: Fri Dec 28 00:35:18 2018 -0800 mm/page_alloc.c: free order-0 pages through PCP in page_frag_free() [ Upstream commit 65895b67ad27df0f62bfaf82dd5622f95ea29196 ] page_frag_free() calls __free_pages_ok() to free the page back to Buddy. This is OK for high order page, but for order-0 pages, it misses the optimization opportunity of using Per-Cpu-Pages and can cause zone lock contention when called frequently. Pawel Staszewski recently shared his result of 'how Linux kernel handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer found the lock contention comes from page allocator: mlx5e_poll_tx_cq | --16.34%--napi_consume_skb | |--12.65%--__free_pages_ok | | | --11.86%--free_one_page | | | |--10.10%--queued_spin_lock_slowpath | | | --0.65%--_raw_spin_lock | |--1.55%--page_frag_free | --1.44%--skb_release_data Jesper explained how it happened: mlx5 driver RX-page recycle mechanism is not effective in this workload and pages have to go through the page allocator. The lock contention happens during mlx5 DMA TX completion cycle. And the page allocator cannot keep up at these speeds.[2] I thought that __free_pages_ok() are mostly freeing high order pages and thought this is an lock contention for high order pages but Jesper explained in detail that __free_pages_ok() here are actually freeing order-0 pages because mlx5 is using order-0 pages to satisfy its page pool allocation request.[3] The free path as pointed out by Jesper is: skb_free_head() -> skb_free_frag() -> page_frag_free() And the pages being freed on this path are order-0 pages. Fix this by doing similar things as in __page_frag_cache_drain() - send the being freed page to PCP if it's an order-0 page, or directly to Buddy if it is a high order page. With this change, Paweł hasn't noticed lock contention yet in his workload and Jesper has noticed a 7% performance improvement using a micro benchmark and lock contention is gone. Ilias' test on a 'low' speed 1Gbit interface on an cortex-a53 shows ~11% performance boost testing with 64byte packets and __free_pages_ok() disappeared from perf top. [1]: https://www.spinics.net/lists/netdev/msg531362.html [2]: https://www.spinics.net/lists/netdev/msg531421.html [3]: https://www.spinics.net/lists/netdev/msg531556.html [akpm@linux-foundation.org: add comment] Link: http://lkml.kernel.org/r/20181120014544.GB10657@intel.com Signed-off-by: Aaron Lu Reported-by: Pawel Staszewski Analysed-by: Jesper Dangaard Brouer Acked-by: Vlastimil Babka Acked-by: Mel Gorman Acked-by: Jesper Dangaard Brouer Acked-by: Ilias Apalodimas Tested-by: Ilias Apalodimas Acked-by: Alexander Duyck Acked-by: Tariq Toukan Acked-by: Pankaj gupta Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 78ce155fb8036cb61b245727d6ee2cdd327cfd47 Author: Wei Yang Date: Fri Dec 28 00:34:36 2018 -0800 vmscan: return NODE_RECLAIM_NOSCAN in node_reclaim() when CONFIG_NUMA is n [ Upstream commit 8b09549c2bfd9f3f8f4cdad74107ef4f4ff9cdd7 ] Commit fa5e084e43eb ("vmscan: do not unconditionally treat zones that fail zone_reclaim() as full") changed the return value of node_reclaim(). The original return value 0 means NODE_RECLAIM_SOME after this commit. While the return value of node_reclaim() when CONFIG_NUMA is n is not changed. This will leads to call zone_watermark_ok() again. This patch fixes the return value by adjusting to NODE_RECLAIM_NOSCAN. Since node_reclaim() is only called in page_alloc.c, move it to mm/internal.h. Link: http://lkml.kernel.org/r/20181113080436.22078-1-richard.weiyang@gmail.com Signed-off-by: Wei Yang Acked-by: Michal Hocko Reviewed-by: Matthew Wilcox Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1b0e201c754421254e3cdb7d5e3de5e693deebb4 Author: Junxiao Bi Date: Fri Dec 28 00:32:53 2018 -0800 ocfs2: clear journal dirty flag after shutdown journal [ Upstream commit d85400af790dba2aa294f0a77e712f166681f977 ] Dirty flag of the journal should be cleared at the last stage of umount, if do it before jbd2_journal_destroy(), then some metadata in uncommitted transaction could be lost due to io error, but as dirty flag of journal was already cleared, we can't find that until run a full fsck. This may cause system panic or other corruption. Link: http://lkml.kernel.org/r/20181121020023.3034-3-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Yiwen Jiang Reviewed-by: Joseph Qi Cc: Jun Piao Cc: Changwei Ge Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit df427cac8469c58791cdd8c0d5ef6e625b9300ec Author: Wen Yang Date: Wed Dec 26 16:28:30 2018 +0800 net/wan/fsl_ucc_hdlc: Avoid double free in ucc_hdlc_probe() [ Upstream commit 40752b3eae29f8ca2378e978a02bd6dbeeb06d16 ] This patch fixes potential double frees if register_hdlc_device() fails. Signed-off-by: Wen Yang Reviewed-by: Peng Hao CC: Zhao Qiang CC: "David S. Miller" CC: netdev@vger.kernel.org CC: linuxppc-dev@lists.ozlabs.org CC: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e3a5ee138296040393c7d230ede7d1ddf2a661dc Author: Kangjie Lu Date: Wed Dec 26 00:31:08 2018 -0600 net: marvell: fix a missing check of acpi_match_device [ Upstream commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e ] When acpi_match_device fails, its return value is NULL. Directly using the return value without a check may result in a NULL-pointer dereference. The fix checks if acpi_match_device fails, and if so, returns -EINVAL. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6d98c426e5f3f4430fc31d85cda5f4110e5f3e9f Author: Kangjie Lu Date: Wed Dec 26 00:09:04 2018 -0600 tipc: fix a missing check of genlmsg_put [ Upstream commit 46273cf7e009231d2b6bc10a926e82b8928a9fb2 ] genlmsg_put could fail. The fix inserts a check of its return value, and if it fails, returns -EMSGSIZE. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a3ab332b4e1e94dbfc3b3d556d7720b2eecfef49 Author: Kangjie Lu Date: Tue Dec 25 22:23:19 2018 -0600 atl1e: checking the status of atl1e_write_phy_reg [ Upstream commit ff07d48d7bc0974d4f96a85a4df14564fb09f1ef ] atl1e_write_phy_reg() could fail. The fix issues an error message when it fails. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8688658355ba0d6f37b76d4be488fda7073e9645 Author: Kangjie Lu Date: Tue Dec 25 22:08:18 2018 -0600 net: dsa: bcm_sf2: Propagate error value from mdio_write [ Upstream commit e49505f7255be8ced695919c08a29bf2c3d79616 ] Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's return their error codes upstream. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d29d4ccc4ee8e22c0e8ba0c6a223799d6e060e3f Author: Kangjie Lu Date: Tue Dec 25 20:57:14 2018 -0600 net: stmicro: fix a missing check of clk_prepare [ Upstream commit f86a3b83833e7cfe558ca4d70b64ebc48903efec ] clk_prepare() could fail, so let's check its status, and if it fails, return its error code upstream. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d7519148362f6aa00c26de4bdbf381d3ec45259 Author: Kangjie Lu Date: Tue Dec 25 20:55:37 2018 -0600 net: (cpts) fix a missing check of clk_prepare [ Upstream commit 2d822f2dbab7f4c820f72eb8570aacf3f35855bd ] clk_prepare() could fail, so let's check its status, and if it fails, return its error code upstream. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 48b140f563ad61a7d0b529bc85c13417bb9f141d Author: Richard Weinberger Date: Tue Oct 30 12:58:12 2018 +0100 um: Make GCOV depend on !KCOV [ Upstream commit 550ed0e2036663b35cec12374b835444f9c60454 ] Both do more or less the same thing and are mutually exclusive. If both are enabled the build will fail. Sooner or later we can kill UML's GCOV. Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit a4a8cec1aa83b2b2cac37199303e7a49c160f4c7 Author: Richard Weinberger Date: Tue Oct 30 12:58:11 2018 +0100 um: Include sys/uio.h to have writev() [ Upstream commit 0053102a869f1b909904b1b85ac282e2744deaab ] sys/uio.h gives us writev(), otherwise the build might fail on some systems. Fixes: 49da7e64f33e ("High Performance UML Vector Network Driver") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 18bd3588a5707c1a8b1940ed5477194b3b1024d9 Author: Chao Yu Date: Tue Dec 18 19:20:17 2018 +0800 f2fs: fix to dirty inode synchronously [ Upstream commit b32e019049e959ee10ec359893c9dd5d057dad55 ] If user change inode's i_flags via ioctl, let's add it into global dirty list, so that checkpoint can guarantee its persistence before fsync, it can make checkpoint keeping strong consistency. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 75491eae5fff246e21c5fcff65a989d6806c4d03 Author: Qiuyang Sun Date: Tue Dec 18 17:32:23 2018 +0800 f2fs: fix block address for __check_sit_bitmap [ Upstream commit 9249dded7b5cb539a8c8698b25d08a3c15261470 ] Should use lstart (logical start address) instead of start (in dev) here. This fixes a bug in multi-device scenarios. Signed-off-by: Qiuyang Sun Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bb76fe3f703bf000dcbbb8757c3fbf5f4ee92f2b Author: Aditya Pakki Date: Sun Dec 23 19:42:38 2018 -0600 net/net_namespace: Check the return value of register_pernet_subsys() [ Upstream commit 0eb987c874dc93f9c9d85a6465dbde20fdd3884c ] In net_ns_init(), register_pernet_subsys() could fail while registering network namespace subsystems. The fix checks the return value and sends a panic() on failure. Signed-off-by: Aditya Pakki Reviewed-by: Kirill Tkhai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef354c629ce73d0ca8e445efc947eefe4a26f622 Author: Aditya Pakki Date: Sun Dec 23 18:54:53 2018 -0600 net/netlink_compat: Fix a missing check of nla_parse_nested [ Upstream commit 89dfd0083751d00d5d7ead36f6d8b045bf89c5e1 ] In tipc_nl_compat_sk_dump(), if nla_parse_nested() fails, it could return an error. To be consistent with other invocations of the function call, on error, the fix passes the return value upstream. Signed-off-by: Aditya Pakki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7281cde1d36bd4a89950bd8dee2b3723d99dbfab Author: Alexander Shiyan Date: Wed Dec 19 13:39:24 2018 +0300 pwm: clps711x: Fix period calculation [ Upstream commit b0f17570b8203c22f139459c86cfbaa0311313ed ] Commit e39c0df1be5a ("pwm: Introduce the pwm_args concept") has changed the variable for the period for clps711x-pwm driver, so now pwm_get/set_period() works with pwm->state.period variable instead of pwm->args.period. This patch changes the period variable in other places where it is used. Signed-off-by: Alexander Shiyan Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit e2e0a193a6b3882a13d26c1700234bdc37a7b4e2 Author: Fabio Estevam Date: Thu Dec 13 07:52:32 2018 -0200 crypto: mxc-scc - fix build warnings on ARM64 [ Upstream commit 2326828ee40357b3d2b1359b8ca7526af201495b ] The following build warnings are seen when building for ARM64 allmodconfig: drivers/crypto/mxc-scc.c:181:20: warning: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' {aka 'long unsigned int'} [-Wformat=] drivers/crypto/mxc-scc.c:186:21: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Wformat=] drivers/crypto/mxc-scc.c:277:21: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Wformat=] drivers/crypto/mxc-scc.c:339:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/crypto/mxc-scc.c:340:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Fix them by using the %zu specifier to print a size_t variable and using a plain %x to print the result of a readl(). Signed-off-by: Fabio Estevam Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9db6e5d2637e2da84c64d7b353f08061c3fd8cf1 Author: Benjamin Herrenschmidt Date: Mon Oct 8 15:08:31 2018 +1100 powerpc: Fix HMIs on big-endian with CONFIG_RELOCATABLE=y [ Upstream commit 505a314fb28ce122091691c51426fa85c084e115 ] HMIs will crash the kernel due to BRANCH_LINK_TO_FAR(hmi_exception_realmode) Calling into the OPD instead of the actual code. Fixes: 2337d207288f ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts") Signed-off-by: Benjamin Herrenschmidt [mpe: Use DOTSYM() rather than #ifdef] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b7ef6f3c6f041b4e011d2656501d0e9a6d88794f Author: Michael Ellerman Date: Tue Nov 27 19:16:44 2018 +1100 powerpc/pseries: Fix node leak in update_lmb_associativity_index() [ Upstream commit 47918bc68b7427e961035949cc1501a864578a69 ] In update_lmb_associativity_index() we lookup dr_node using of_find_node_by_path() which takes a reference for us. In the non-error case we forget to drop the reference. Note that find_aa_index() does modify properties of the node, but doesn't need an extra reference held once it's returned. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f4d1d649d2eaf389b16e9204d71ab0bcf7ceb4e2 Author: Christophe Leroy Date: Mon Dec 10 11:41:29 2018 +0000 powerpc/83xx: handle machine check caused by watchdog timer [ Upstream commit 0deae39cec6dab3a66794f3e9e83ca4dc30080f1 ] When the watchdog timer is set in interrupt mode, it causes a machine check when it times out. The purpose of this mode is to ease debugging, not to crash the kernel and reboot the machine. This patch implements a special handling for that, in order to not crash the kernel if the watchdog times out while in interrupt or within the idle task. Signed-off-by: Christophe Leroy [scottwood: added missing #include] Signed-off-by: Scott Wood Signed-off-by: Sasha Levin commit 2bf4b03bc3ecb43f7182c88e6c15f3014df6d845 Author: Kangjie Lu Date: Fri Dec 21 00:29:19 2018 -0600 regulator: tps65910: fix a missing check of return value [ Upstream commit cd07e3701fa6a4c68f8493ee1d12caa18d46ec6a ] tps65910_reg_set_bits() may fail. The fix checks if it fails, and if so, returns with its error code. Signed-off-by: Kangjie Lu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f0910af753bd885152c2e23fcd67000d41e9711f Author: Jesper Dangaard Brouer Date: Wed Dec 19 17:00:23 2018 +0100 bpf/cpumap: make sure frame_size for build_skb is aligned if headroom isn't [ Upstream commit 77ea5f4cbe2084db9ab021ba73fb7eadf1610884 ] The frame_size passed to build_skb must be aligned, else it is possible that the embedded struct skb_shared_info gets unaligned. For correctness make sure that xdpf->headroom in included in the alignment. No upstream drivers can hit this, as all XDP drivers provide an aligned headroom. This was discovered when playing with implementing XDP support for mvneta, which have a 2 bytes DSA header, and this Marvell ARM64 platform didn't like doing atomic operations on an unaligned skb_shinfo(skb)->dataref addresses. Fixes: 1c601d829ab0 ("bpf: cpumap xdp_buff to skb conversion and allocation") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit f48c240cbff66d9fac4d5557b48bd4bdda13aef2 Author: Parav Pandit Date: Fri Dec 14 00:32:42 2018 -0600 IB/rxe: Make counters thread safe [ Upstream commit d5108e69fe013ff47ab815b849caba9cc33ca1e5 ] Current rxe device counters are not thread safe. When multiple QPs are used, they can be racy. Make them thread safe by making it atomic64. Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats") Signed-off-by: Parav Pandit Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c67c496f713813935d4b3f630eca3267c4d7d7e8 Author: Luc Van Oostenryck Date: Thu Dec 20 17:23:39 2018 +0100 drbd: fix print_st_err()'s prototype to match the definition [ Upstream commit 2c38f035117331eb78d0504843c79ea7c7fabf37 ] print_st_err() is defined with its 4th argument taking an 'enum drbd_state_rv' but its prototype use an int for it. Fix this by using 'enum drbd_state_rv' in the prototype too. Signed-off-by: Luc Van Oostenryck Signed-off-by: Roland Kammerer Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0a4dae25ab47e6c62c263fb73d120f785d7b7b97 Author: Lars Ellenberg Date: Thu Dec 20 17:23:37 2018 +0100 drbd: do not block when adjusting "disk-options" while IO is frozen [ Upstream commit f708bd08ecbdc23d03aaedf5b3311ebe44cfdb50 ] "suspending" IO is overloaded. It can mean "do not allow new requests" (obviously), but it also may mean "must not complete pending IO", for example while the fencing handlers do their arbitration. When adjusting disk options, we suspend io (disallow new requests), then wait for the activity-log to become unused (drain all IO completions), and possibly replace it with a new activity log of different size. If the other "suspend IO" aspect is active, pending IO completions won't happen, and we would block forever (unkillable drbdsetup process). Fix this by skipping the activity log adjustment if the "al-extents" setting did not change. Also, in case it did change, fail early without blocking if it looks like we would block forever. Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7df41c6b0eaad0275e21cbcfd05710fda2b8de03 Author: Lars Ellenberg Date: Thu Dec 20 17:23:35 2018 +0100 drbd: reject attach of unsuitable uuids even if connected [ Upstream commit fe43ed97bba3b11521abd934b83ed93143470e4f ] Multiple failure scenario: a) all good Connected Primary/Secondary UpToDate/UpToDate b) lose disk on Primary, Connected Primary/Secondary Diskless/UpToDate c) continue to write to the device, changes only make it to the Secondary storage. d) lose disk on Secondary, Connected Primary/Secondary Diskless/Diskless e) now try to re-attach on Primary This would have succeeded before, even though that is clearly the wrong data set to attach to (missing the modifications from c). Because we only compared our "effective" and the "to-be-attached" data generation uuid tags if (device->state.conn < C_CONNECTED). Fix: change that constraint to (device->state.pdsk != D_UP_TO_DATE) compare the uuids, and reject the attach. This patch also tries to improve the reverse scenario: first lose Secondary, then Primary disk, then try to attach the disk on Secondary. Before this patch, the attach on the Secondary succeeds, but since commit drbd: disconnect, if the wrong UUIDs are attached on a connected peer the Primary will notice unsuitable data, and drop the connection hard. Though unfortunately at a point in time during the handshake where we cannot easily abort the attach on the peer without more refactoring of the handshake. We now reject any attach to "unsuitable" uuids, as long as we can see a Primary role, unless we already have access to "good" data. Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit de0713a3da9d7a9ed134b18e8170c4041c4c44ac Author: Lars Ellenberg Date: Thu Dec 20 17:23:31 2018 +0100 drbd: ignore "all zero" peer volume sizes in handshake [ Upstream commit 94c43a13b8d6e3e0dd77b3536b5e04a84936b762 ] During handshake, if we are diskless ourselves, we used to accept any size presented by the peer. Which could be zero if that peer was just brought up and connected to us without having a disk attached first, in which case both peers would just "flip" their volume sizes. Now, even a diskless node will ignore "zero" sizes presented by a diskless peer. Also a currently Diskless Primary will refuse to shrink during handshake: it may be frozen, and waiting for a "suitable" local disk or peer to re-appear (on-no-data-accessible suspend-io). If the peer is smaller than what we used to be, it is not suitable. The logic for a diskless node during handshake is now supposed to be: believe the peer, if - I don't have a current size myself - we agree on the size anyways - I do have a current size, am Secondary, and he has the only disk - I do have a current size, am Primary, and he has the only disk, which is larger than my current size Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e440f9fd4eddd44f790a39090c4747df22efbc0e Author: Alexey Kardashevskiy Date: Mon Nov 19 15:25:17 2018 +1100 powerpc/powernv/eeh/npu: Fix uninitialized variables in opal_pci_eeh_freeze_status [ Upstream commit c20577014f85f36d4e137d3d52a1f61225b4a3d2 ] The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS call in skiboot's NPU driver does not touch the pci_error_type parameter so it might have garbage but the powernv code analyzes it nevertheless. This initializes pcierr and fstate to zero in all call sites. Signed-off-by: Alexey Kardashevskiy Reviewed-by: Sam Bobroff Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 42cdd8e9616d5a228ba1dd17ed8a2a8d2719b1a1 Author: Alexey Kardashevskiy Date: Tue Oct 2 13:22:31 2018 +1000 vfio/spapr_tce: Get rid of possible infinite loop [ Upstream commit 517ad4ae8aa93dccdb9a88c27257ecb421c9e848 ] As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered memory. If there is a bug in memory release, the loop in tce_iommu_release() becomes infinite; this actually happened to me. This makes the loop finite and prints a warning on every failure to make the code more bug prone. Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson Acked-by: Alex Williamson Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 3cb8eefbdc12d2f2d240b416cc014cc1a6fa8f05 Author: Benjamin Herrenschmidt Date: Tue Dec 11 13:27:33 2018 +1100 powerpc/44x/bamboo: Fix PCI range [ Upstream commit 3cfb9ebe906b51f2942b1e251009bb251efd2ba6 ] The bamboo dts has a bug: it uses a non-naturally aligned range for PCI memory space. This isnt' supported by the code, thus causing PCI to break on this system. This is due to the fact that while the chip memory map has 1G reserved for PCI memory, it's only 512M aligned. The code doesn't know how to split that into 2 different PMMs and fails, so limit the region to 512M. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ba87ed0ad7c1ab3f3a335372be96c7fdab0edb3c Author: Christophe Leroy Date: Fri Dec 14 15:23:33 2018 +0000 powerpc/mm: Make NULL pointer deferences explicit on bad page faults. [ Upstream commit 49a502ea23bf9dec47f8f3c3960909ff409cd1bb ] As several other arches including x86, this patch makes it explicit that a bad page fault is a NULL pointer dereference when the fault address is lower than PAGE_SIZE In the mean time, this page makes all bad_page_fault() messages shorter so that they remain on one single line. And it prefixes them by "BUG: " so that they get easily grepped. Signed-off-by: Christophe Leroy [mpe: Avoid pr_cont()] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d02f0fc975b25d3934490d6625310fe95c04ae66 Author: Christophe Leroy Date: Fri Dec 14 10:27:47 2018 +0000 powerpc/prom: fix early DEBUG messages [ Upstream commit b18f0ae92b0a1db565c3e505fa87b6971ad3b641 ] This patch fixes early DEBUG messages in prom.c: - Use %px instead of %p to see the addresses - Cast memblock_phys_mem_size() with (unsigned long long) to avoid build failure when phys_addr_t is not 64 bits. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b92e5db0f492026778cb31dfc479e50f33f75bca Author: Joel Stanley Date: Mon Nov 12 15:58:06 2018 +1030 powerpc/32: Avoid unsupported flags with clang [ Upstream commit 72e7bcc2cdf82bf03caaa5e6c9b0134c2fc2ee7d ] When building for ppc32 with clang these flags are unsupported: -ffixed-r2 and -mmultiple llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on when building for SVR4ABI and !ppc64: // The SVR4 ABI reserves r2 and r13 if (Subtarget.isSVR4ABI()) { // We only reserve r2 if we need to use the TOC pointer. If we have no // explicit uses of the TOC pointer (meaning we're a leaf function with // no constant-pool loads, etc.) and we have no potential uses inside an // inline asm block, then we can treat r2 has an ordinary callee-saved // register. const PPCFunctionInfo *FuncInfo = MF.getInfo(); if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm()) markSuperRegs(Reserved, PPC::R2); // System-reserved register markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register } This means we can safely omit -ffixed-r2 when building for 32-bit targets. The -mmultiple/-mno-multiple flags are not supported by clang, so platforms that might support multiple miss out on using multiple word instructions. We wrap these flags in cc-option so that when Clang gains support the kernel will be able use these flags. Clang 8 can then build a ppc44x_defconfig which boots in Qemu: make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ppc44x_defconfig ./scripts/config -e CONFIG_DEVTMPFS -d DEVTMPFS_MOUNT make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- qemu-system-ppc -M bamboo \ -kernel arch/powerpc/boot/zImage \ -dtb arch/powerpc/boot/dts/bamboo.dtb \ -initrd ~/ppc32-440-rootfs.cpio \ -nographic -serial stdio -monitor pty -append "console=ttyS0" Link: https://github.com/ClangBuiltLinux/linux/issues/261 Link: https://bugs.llvm.org/show_bug.cgi?id=39556 Link: https://bugs.llvm.org/show_bug.cgi?id=39555 Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 5c83f9fc11d376beec5d5dae995c2b5c8c21975b Author: Madhavan Srinivasan Date: Mon Oct 9 19:42:40 2017 +0530 powerpc/perf: Fix unit_sel/cache_sel checks [ Upstream commit 2d46d4877b1afd14059393a48bdb8ce27955174c ] Raw event code has couple of fields "unit" and "cache" in it, to capture the "unit" to monitor for a given pmcxsel and cache reload qualifier to program in MMCR1. isa207_get_constraint() refers "unit" field to update the MMCRC (L2/L3) Event bus control fields with "cache" bits of the raw event code. These are power8 specific and not supported by PowerISA v3.0 pmu. So wrap the checks to be power8 specific. Also, "cache" bit field is referred to update MMCR1[16:17] and this check can be power8 specific. Fixes: 7ffd948fae4cd ('powerpc/perf: factor out power8 pmu functions') Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 4f580e82a5b1b85199398edf7aba50835f730020 Author: Kyle Roeschley Date: Wed Dec 5 09:43:13 2018 +0200 ath6kl: Fix off by one error in scan completion [ Upstream commit 5803c12816c43bd09e5f4247dd9313c2d9a2c41b ] When ath6kl was reworked to share code between regular and scheduled scans in commit 3b8ffc6a22ba ("ath6kl: Configure probed SSID list consistently"), probed SSID entry changed from 1-index to 0-indexed. However, ath6kl_cfg80211_scan_complete_event() was missed in that change. Fix its indexing so that we correctly clear out the probed SSID list. Signed-off-by: Kyle Roeschley Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 7049ff5c11ac92e8aacdb1ac2d0dd4efcf346da4 Author: Kyle Roeschley Date: Wed Dec 5 09:43:11 2018 +0200 ath6kl: Only use match sets when firmware supports it [ Upstream commit fb376a495fbdb886f38cfaf5a3805401b9e46f13 ] Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan") merged the probed and matched SSID lists before sending them to the firmware. In the process, it assumed match set support is always available in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check that the firmware supports matching SSIDs in scheduled scans before setting MATCH_SSID_FLAG. Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan") Signed-off-by: Kyle Roeschley Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 76f5d7487a8227d4dd1b32baba6f0fc87fa62c08 Author: Stefan Wahren Date: Wed Dec 12 20:20:06 2018 +0100 brcmfmac: Fix access point mode [ Upstream commit 861cb5eb467f5e38dce1aabe4e8db379255bd89b ] Since commit 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") the Raspberry Pi 3 A+ (BCM43455) isn't able to operate in AP mode with hostapd (device_ap_sme=1 use_monitor=0): brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -52 So add the missing mgmt_stypes for AP mode to fix this. Fixes: 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") Suggested-by: Arend van Spriel Signed-off-by: Stefan Wahren Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit a88218f75d48819e7577fd75206fdedee7f035ea Author: Varun Prakash Date: Wed Dec 19 15:42:50 2018 +0530 scsi: csiostor: fix incorrect dma device in case of vport [ Upstream commit 9934613edcb40b92a216122876cd3b7e76d08390 ] In case of ->vport_create() call scsi_add_host_with_dma() instead of scsi_add_host() to pass correct dma device. Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a76bee5c31b8cf3bdc9dfa5655c5b7227f9fc357 Author: Anatoliy Glagolev Date: Thu Dec 6 16:48:45 2018 -0700 scsi: qla2xxx: deadlock by configfs_depend_item [ Upstream commit 17b18eaa6f59044a5172db7d07149e31ede0f920 ] The intent of invoking configfs_depend_item in commit 7474f52a82d51 ("tcm_qla2xxx: Perform configfs depend/undepend for base_tpg") was to prevent a physical Fibre Channel port removal when virtual (NPIV) ports announced through that physical port are active. The change does not work as expected: it makes enabled physical port dependent on target configfs subsystem (the port's parent), something the configfs guarantees anyway. Besides, scheduling work in a worker thread and waiting for the work's completion is not really a valid workaround for the requirement not to call configfs_depend_item from a configfs callback: the call occasionally deadlocks. Thus, removing configfs_depend_item calls does not break anything and fixes the deadlock problem. Signed-off-by: Anatoliy Glagolev Acked-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 59d45be57cb9fc4dbcca721135cfddcc3a2954c4 Author: Bart Van Assche Date: Mon Dec 17 13:20:36 2018 -0800 RDMA/srp: Propagate ib_post_send() failures to the SCSI mid-layer [ Upstream commit 2ee00f6a98c36f7e4ba07cc33f24cc5a69060cc9 ] This patch avoids that the SCSI mid-layer keeps retrying forever if ib_post_send() fails. This was discovered while testing immediate data support and passing a too large num_sge value to ib_post_send(). Cc: Sergey Gorenko Cc: Max Gurtovoy Cc: Laurence Oberman Signed-off-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 96f68d4d4015dcea541fcfaae54420008071eaef Author: Geert Uytterhoeven Date: Mon Dec 3 13:20:47 2018 +0100 openrisc: Fix broken paths to arch/or32 [ Upstream commit 57ce8ba0fd3a95bf29ed741df1c52bd591bf43ff ] OpenRISC was mainlined as "openrisc", not "or32". vmlinux.lds is generated from vmlinux.lds.S. Signed-off-by: Geert Uytterhoeven Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 98b49680367aa8f056f465ff5e7fd0d2a578399d Author: Alexander Shiyan Date: Wed Dec 19 14:19:20 2018 +0300 serial: max310x: Fix tx_empty() callback [ Upstream commit a8da3c7873ea57acb8f9cea58c0af477522965aa ] Function max310x_tx_empty() accesses the IRQSTS register, which is cleared by IC when reading, so if there is an interrupt status, we will lose it. This patch implement the transmitter check only by the current FIFO level. Signed-off-by: Alexander Shiyan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4104d973c61fdf4d77f359c6415480960d30afeb Author: Jonathan Bakker Date: Wed Dec 19 12:22:28 2018 +0100 Bluetooth: hci_bcm: Handle specific unknown packets after firmware loading [ Upstream commit 22bba80500fdf624a7cfbb65fdfa97a038ae224d ] The Broadcom controller on aries S5PV210 boards sends out a couple of unknown packets after the firmware is loaded. This will cause logging of errors such as: Bluetooth: hci0: Frame reassembly failed (-84) This is probably also the case with other boards, as there are related Android userspace patches for custom ROMs such as https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/ Since this appears to be intended behaviour, treated them as diagnostic packets. Note that this is another variant of commit 01d5e44ace8a ("Bluetooth: hci_bcm: Handle empty packet after firmware loading") Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 6e5176f52017ee5c3a7a1baca56367fcff3095b8 Author: Kangjie Lu Date: Tue Dec 18 23:04:13 2018 -0600 drivers/regulator: fix a missing check of return value [ Upstream commit 966e927bf8cc6a44f8b72582a1d6d3ffc73b12ad ] If palmas_smps_read() fails, we should not use the read data in "reg" which may contain random value. The fix inserts a check for the return value of palmas_smps_read(): If it fails, we return the error code upstream and stop using "reg". Signed-off-by: Kangjie Lu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b5a1a46dc29fabd4f933052b98f8c8114ee85c53 Author: Christophe Leroy Date: Fri Nov 16 17:31:08 2018 +0000 powerpc/xmon: fix dump_segments() [ Upstream commit 32c8c4c621897199e690760c2d57054f8b84b6e6 ] mfsrin() takes segment num from bits 31-28 (IBM bits 0-3). Signed-off-by: Christophe Leroy [mpe: Clarify bit numbering] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d003b67d2b97868a7e695663f7835f4d96e73728 Author: Christophe Leroy Date: Fri Nov 16 17:27:42 2018 +0000 powerpc/book3s/32: fix number of bats in p/v_block_mapped() [ Upstream commit e93ba1b7eb5b188c749052df7af1c90821c5f320 ] This patch fixes the loop in p_block_mapped() and v_block_mapped() to scan the entire bat_addrs[] array. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 09a0f8d4423a0069cbdc45e1dfca0e739389cc53 Author: Petr Machata Date: Tue Dec 18 13:16:00 2018 +0000 vxlan: Fix error path in __vxlan_dev_create() [ Upstream commit 6db9246871394b3a136cd52001a0763676563840 ] When a failure occurs in rtnl_configure_link(), the current code calls unregister_netdevice() to roll back the earlier call to register_netdevice(), and jumps to errout, which calls vxlan_fdb_destroy(). However unregister_netdevice() calls transitively ndo_uninit, which is vxlan_uninit(), and that already takes care of deleting the default FDB entry by calling vxlan_fdb_delete_default(). Since the entry added earlier in __vxlan_dev_create() is exactly the default entry, the cleanup code in the errout block always leads to double free and thus a panic. Besides, since vxlan_fdb_delete_default() always destroys the FDB entry with notification enabled, the deletion of the default entry is notified even before the addition was notified. Instead, move the unregister_netdevice() call after the manual destroy, which solves both problems. Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create") Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eabcc2ff5060031a931727788f2a4a0772b5e424 Author: Tao Ren Date: Wed Oct 3 14:53:50 2018 -0700 clocksource/drivers/fttmr010: Fix invalid interrupt register access [ Upstream commit 86fe57fc47b17b3528fa5497fc57e158d846c4ea ] TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed for masking interrupts on ast2500 chips, and it's not even listed in ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed chips. Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is not interrupt status register on ast2400 and ast2500 chips. Although there is no side effect to reset the register in fttmr010_common_init(), it's just misleading to do so. Besides, "count_down" is renamed to "is_aspeed" in "fttmr010" structure, and more comments are added so the code is more readble. Signed-off-by: Tao Ren Reviewed-by: Linus Walleij Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 360e6fe776912c9273b4aacedfba5d80e9cf4320 Author: Dan Carpenter Date: Mon Dec 17 10:05:36 2018 +0300 IB/qib: Fix an error code in qib_sdma_verbs_send() [ Upstream commit 5050ae5fa3d54c8e83e1e447cc7e3591110a7f57 ] We accidentally return success on this error path. Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by: Dan Carpenter Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 68cb344ccae90304f224e70953d8d2be730afd43 Author: Nick Bowler Date: Mon Dec 17 09:35:27 2018 -0800 xfs: Fix bulkstat compat ioctls on x32 userspace. [ Upstream commit 7ca860e3c1a74ad6bd8949364073ef1044cad758 ] The bulkstat family of ioctls are problematic on x32, because there is a mixup of native 32-bit and 64-bit conventions. The xfs_fsop_bulkreq struct contains pointers and 32-bit integers so that matches the native 32-bit layout, and that means the ioctl implementation goes into the regular compat path on x32. However, the 'ubuffer' member of that struct in turn refers to either struct xfs_inogrp or xfs_bstat (or an array of these). On x32, those structures match the native 64-bit layout. The compat implementation writes out the 32-bit version of these structures. This is not the expected format for x32 userspace, causing problems. Fortunately the functions which actually output these xfs_inogrp and xfs_bstat structures have an easy way to select which output format is required, so we just need a little tweak to select the right format on x32. Signed-off-by: Nick Bowler Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 5d8d2116c16baf7bb7d81429f21cb0d888b9bfec Author: Nick Bowler Date: Mon Dec 17 09:35:27 2018 -0800 xfs: Align compat attrlist_by_handle with native implementation. [ Upstream commit c456d64449efe37da50832b63d91652a85ea1d20 ] While inspecting the ioctl implementations, I noticed that the compat implementation of XFS_IOC_ATTRLIST_BY_HANDLE does not do exactly the same thing as the native implementation. Specifically, the "cursor" does not appear to be written out to userspace on the compat path, like it is on the native path. This adjusts the compat implementation to copy out the cursor just like the native implementation does. The attrlist cursor does not require any special compat handling. This fixes xfstests xfs/269 on both IA-32 and x32 userspace, when running on an amd64 kernel. Signed-off-by: Nick Bowler Fixes: 0facef7fb053b ("xfs: in _attrlist_by_handle, copy the cursor back to userspace") Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit fe8e594cb7246815d051d78b74dc5270b7d598f3 Author: Heinz Mauelshagen Date: Tue Dec 18 17:35:41 2018 +0100 dm raid: fix false -EBUSY when handling check/repair message [ Upstream commit 74694bcbdf7e28a5ad548cdda9ac56d30be00d13 ] Sending a check/repair message infrequently leads to -EBUSY instead of properly identifying an active resync. This occurs because raid_message() is testing recovery bits in a racy way. Fix by calling decipher_sync_action() from raid_message() to properly identify the idle state of the RAID device. Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 7baf8fd1ffff8e57f903956c10d8a18dc098cdbe Author: Bob Peterson Date: Tue Dec 18 08:29:32 2018 -0600 gfs2: take jdata unstuff into account in do_grow [ Upstream commit bc0205612bbd4dd4026d4ba6287f5643c37366ec ] Before this patch, function do_grow would not reserve enough journal blocks in the transaction to unstuff jdata files while growing them. This patch adds the logic to add one more block if the file to grow is jdata. Signed-off-by: Bob Peterson Reviewed-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit d4c637af2e56ee1ec66ee34d0ac5a13c75911aec Author: Sweet Tea Date: Tue Nov 13 08:04:24 2018 -0500 dm flakey: Properly corrupt multi-page bios. [ Upstream commit a00f5276e26636cbf72f24f79831026d2e2868e7 ] The flakey target is documented to be able to corrupt the Nth byte in a bio, but does not corrupt byte indices after the first biovec in the bio. Change the corrupting function to actually corrupt the Nth byte no matter in which biovec that index falls. A test device generating two-page bios, atop a flakey device configured to corrupt a byte index on the second page, verified both the failure to corrupt before this patch and the expected corruption after this change. Signed-off-by: John Dorminy Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 168779023daab60ae37e3ec5f5186242f730f9db Author: Peter Hutterer Date: Thu Dec 13 11:28:51 2018 +1000 HID: doc: fix wrong data structure reference for UHID_OUTPUT [ Upstream commit 46b14eef59a8157138dc02f916a7f97c73b3ec53 ] Signed-off-by: Peter Hutterer Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a7f1b12fab652467232fe9ccd9b1292c66396168 Author: Geert Uytterhoeven Date: Thu Dec 13 14:41:11 2018 +0100 pinctrl: sh-pfc: sh7734: Fix shifted values in IPSR10 [ Upstream commit 054f2400f706327f96770219c3065b5131f8f154 ] Some values in the Peripheral Function Select Register 10 descriptor are shifted by one position, which may cause a peripheral function to be programmed incorrectly. Fixing this makes all HSCIF0 pins use Function 4 (value 3), like was already the case for the HSCK0 pin in field IP10[5:3]. Fixes: ac1ebc2190f575fc ("sh-pfc: Add sh7734 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Sasha Levin commit f83a5dba5e776edfd4e43c022ee765d25de01ba7 Author: Geert Uytterhoeven Date: Thu Dec 13 14:09:56 2018 +0100 pinctrl: sh-pfc: sh7264: Fix PFCR3 and PFCR0 register configuration [ Upstream commit 1b99d0c80bbe1810572c2cb77b90f67886adfa8d ] The Port F Control Register 3 (PFCR3) contains only a single field. However, counting from left to right, it is the fourth field, not the first field. Insert the missing dummy configuration values (3 fields of 16 values) to fix this. The descriptor for the Port F Control Register 0 (PFCR0) lacks the description for the 4th field (PF0 Mode, PF0MD[2:0]). Add the missing configuration values to fix this. Fixes: a8d42fc4217b1ea1 ("sh-pfc: Add sh7264 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Sasha Levin commit 593acae104fdba67f3ab7e23387ad771c536385c Author: Geert Uytterhoeven Date: Thu Dec 13 10:53:11 2018 +0100 pinctrl: sh-pfc: r8a77990: Fix MOD_SEL0 SEL_I2C1 field width [ Upstream commit 755a5b805fa7ff22e2934d67501efd92109f41ea ] The SEL_I2C1 (MOD_SEL0[21:20]) field in Module Select Register 0 has a width of 2 bits, i.e. it allows programming one out of 4 different configurations. However, the MOD_SEL0_21_20 macro contains 8 values instead of 4, overflowing into the subsequent fields in the register, and thus breaking the configuration of the latter. Fix this by dropping the bogus last 4 values, including the non-existent SEL_I2C1_4 configuration. Fixes: 6d4036a1e3b3ac0f ("pinctrl: sh-pfc: Initial R8A77990 PFC support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Sasha Levin commit afa39431f680ef6fe04f6fb6f6f8bf002fced407 Author: Michael Mueller Date: Fri Nov 30 15:32:06 2018 +0100 KVM: s390: unregister debug feature on failing arch init [ Upstream commit 308c3e6673b012beecb96ef04cc65f4a0e7cdd99 ] Make sure the debug feature and its allocated resources get released upon unsuccessful architecture initialization. A related indication of the issue will be reported as kernel message. Signed-off-by: Michael Mueller Reviewed-by: Cornelia Huck Reviewed-by: Pierre Morel Reviewed-by: David Hildenbrand Message-Id: <20181130143215.69496-2-mimu@linux.ibm.com> Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 343249b914942e966cd2b50c3e1cc113dbe15f66 Author: Vasundhara Volam Date: Sun Dec 16 18:46:31 2018 -0500 bnxt_en: query force speeds before disabling autoneg mode. [ Upstream commit 56d374624778652d2a999e18c87a25338b127b41 ] With autoneg enabled, PHY loopback test fails. To disable autoneg, driver needs to send a valid forced speed to FW. FW is not sending async event for invalid speeds. To fix this, query forced speeds and send the correct speed when disabling autoneg mode. Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 591d453768d62cbe778b388812f63c374f99afdf Author: Michael Chan Date: Sun Dec 16 18:46:29 2018 -0500 bnxt_en: Save ring statistics before reset. [ Upstream commit b8875ca356f1c0b17ec68be6666269373a62288e ] With the current driver, the statistics reported by .ndo_get_stats64() are reset when the device goes down. Store a snapshot of the rtnl_link_stats64 before shutdown. This snapshot is added to the current counters in .ndo_get_stats64() so that the counters will not get reset when the device is down. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 58fcfeaf26ed90bbb3e6a0c7071ec6ee8dbe9118 Author: Vasundhara Volam Date: Sun Dec 16 18:46:28 2018 -0500 bnxt_en: Return linux standard errors in bnxt_ethtool.c [ Upstream commit 7c675421afef18253a86ffc383f57bc15ef32ea8 ] Currently firmware specific errors are returned directly in flash_device and reset ethtool hooks. Modify it to return linux standard errors to userspace when flashing operations fail. Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bd5acf3e81ec539c10d0bf116b43297de6a43338 Author: Al Viro Date: Fri Nov 9 22:26:42 2018 -0500 exofs_mount(): fix leaks on failure exits [ Upstream commit 26cb5a328c6b2bda9e859307ce4cfc60df3a2c28 ] ... and don't abuse mount_nodev(), while we are at it. Signed-off-by: Al Viro Reviewed-by: David Howells Signed-off-by: Sasha Levin commit d1dbff485dc86b1e0e87c96ee032de98a2bbf2b5 Author: Alin Nastac Date: Thu Dec 13 11:10:37 2018 +0100 netfilter: nf_nat_sip: fix RTP/RTCP source port translations [ Upstream commit 8294059931448aa1ca112615bdffa3eab552c382 ] Each media stream negotiation between 2 SIP peers will trigger creation of 4 different expectations (2 RTP and 2 RTCP): - INVITE will create expectations for the media packets sent by the called peer - reply to the INVITE will create expectations for media packets sent by the caller The dport used by these expectations usually match the ones selected by the SIP peers, but they might get translated due to conflicts with another expectation. When such event occur, it is important to do this translation in both directions, dport translation on the receiving path and sport translation on the sending path. This commit fixes the sport translation when the peer requiring it is also the one that starts the media stream. In this scenario, first media stream packet is forwarded from LAN to WAN and will rely on nf_nat_sip_expected() to do the necessary sport translation. However, the expectation matched by this packet does not contain the necessary information for doing SNAT, this data being stored in the paired expectation created by the sender's SIP message (INVITE or reply to it). Signed-off-by: Alin Nastac Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fa32aee89734ee22d0717f99c07f236ca5f1410f Author: Leon Romanovsky Date: Thu Dec 13 13:15:11 2018 +0200 net/mlx5: Continue driver initialization despite debugfs failure [ Upstream commit 199fa087dc6b503baad06712716fac645a983e8a ] The failure to create debugfs entry is unpleasant event, but not enough to abort drier initialization. Align the mlx5_core code to debugfs design and continue execution whenever debugfs_create_dir() successes or not. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Reviewed-by: Saeed Mahameed Signed-off-by: Leon Romanovsky Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4c084af314f04729d79fa421f6399c728dd2dfee Author: Martin Schiller Date: Fri Dec 14 08:48:25 2018 +0100 pinctrl: xway: fix gpio-hog related boot issues [ Upstream commit 9b4924da4711674e62d97d4f5360446cc78337af ] This patch is based on commit a86caa9ba5d7 ("pinctrl: msm: fix gpio-hog related boot issues"). It fixes the issue that the gpio ranges needs to be defined before gpiochip_add(). Therefore, we also have to swap the order of registering the pinctrl driver and registering the gpio chip. You also have to add the "gpio-ranges" property to the pinctrl device node to get it finally working. Signed-off-by: Martin Schiller Acked-by: John Crispin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit acada7c2c68b0ed824ef031331afe287ad3a38da Author: Linus Walleij Date: Mon Dec 17 14:11:08 2018 +0100 memory: omap-gpmc: Get the header of the enum [ Upstream commit a0752e9c3097b2c4fccd618802938e0951038dfa ] Commit 21abf103818a ("gpio: Pass a flag to gpiochip_request_own_desc()") started to pass an enum gpiod_flags but this file is not including the header file that defines that enum and the compiler spits: drivers/memory/omap-gpmc.c: In function 'gpmc_probe_generic_child': drivers/memory/omap-gpmc.c:2174:9: error: type of formal parameter 4 is incomplete 0); ^ Cc: Ladislav Michl Cc: Janusz Krzysztofik Reported-by: Stephen Rothwell Fixes: 21abf103818a ("gpio: Pass a flag to gpiochip_request_own_desc()") Acked-by: Tony Lindgren Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 005874c5170e70c92010a23d766f76f721ae52ba Author: Nathan Chancellor Date: Fri Oct 19 11:04:27 2018 -0700 vfio-mdev/samples: Use u8 instead of char for handle functions [ Upstream commit 8ba35b3a0046d6573c98f00461d9bd1b86250d35 ] Clang warns: samples/vfio-mdev/mtty.c:592:39: warning: implicit conversion from 'int' to 'char' changes value from 162 to -94 [-Wconstant-conversion] *buf = UART_MSR_DSR | UART_MSR_DDSR | UART_MSR_DCD; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ 1 warning generated. Turns out that all uses of buf in this function ultimately end up stored or cast to an unsigned type. Just use u8, which has the same number of bits but can store this larger number so Clang no longer warns. Signed-off-by: Nathan Chancellor Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 962b1f6b0307c205467fe868b7c68f85f44c6c7d Author: Masami Hiramatsu Date: Mon Dec 17 17:21:24 2018 +0900 kprobes/x86: Show x86-64 specific blacklisted symbols correctly [ Upstream commit fe6e65615415987629a2dda583b4495677d8c388 ] Show x86-64 specific blacklisted symbols in debugfs. Since x86-64 prohibits probing on symbols which are in entry text, those should be shown. Tested-by: Andrea Righi Signed-off-by: Masami Hiramatsu Cc: Andy Lutomirski Cc: Anil S Keshavamurthy Cc: Borislav Petkov Cc: David S. Miller Cc: Linus Torvalds Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Yonghong Song Link: http://lkml.kernel.org/r/154503488425.26176.17136784384033608516.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 98cf16d33c0796b1cfce7960c43862273e4c5c10 Author: Masami Hiramatsu Date: Mon Dec 17 17:20:55 2018 +0900 kprobes: Blacklist symbols in arch-defined prohibited area [ Upstream commit fb1a59fae8baa3f3c69b72a87ff94fc4fa5683ec ] Blacklist symbols in arch-defined probe-prohibited areas. With this change, user can see all symbols which are prohibited to probe in debugfs. All archtectures which have custom prohibit areas should define its own arch_populate_kprobe_blacklist() function, but unless that, all symbols marked __kprobes are blacklisted. Reported-by: Andrea Righi Tested-by: Andrea Righi Signed-off-by: Masami Hiramatsu Cc: Andy Lutomirski Cc: Anil S Keshavamurthy Cc: Borislav Petkov Cc: David S. Miller Cc: Linus Torvalds Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Yonghong Song Link: http://lkml.kernel.org/r/154503485491.26176.15823229545155174796.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 73c1ca2dda37a65d4ef218551a39794658a0ef2c Author: Ross Lagerwall Date: Fri Dec 14 12:55:45 2018 +0000 xen/pciback: Check dev_data before using it [ Upstream commit 1669907e3d1abfa3f7586e2d55dbbc117b5adba2 ] If pcistub_init_device fails, the release function will be called with dev_data set to NULL. Check it before using it to avoid a NULL pointer dereference. Signed-off-by: Ross Lagerwall Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 24d992bcaa5ac8f2f28e62f54d8db504b24ed0c1 Author: Andrea Righi Date: Mon Dec 10 16:12:57 2018 +0100 kprobes/x86/xen: blacklist non-attachable xen interrupt functions [ Upstream commit bf9445a33ae6ac2f0822d2f1ce1365408387d568 ] Blacklist symbols in Xen probe-prohibited areas, so that user can see these prohibited symbols in debugfs. See also: a50480cb6d61. Signed-off-by: Andrea Righi Acked-by: Masami Hiramatsu Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit ab77c2c16da82e50f46a66699b9eceb78022d163 Author: Darwin Dingel Date: Mon Dec 10 11:29:09 2018 +1300 serial: 8250: Rate limit serial port rx interrupts during input overruns [ Upstream commit 6d7f677a2afa1c82d7fc7af7f9159cbffd5dc010 ] When a serial port gets faulty or gets flooded with inputs, its interrupt handler starts to work double time to get the characters to the workqueue for the tty layer to handle them. When this busy time on the serial/tty subsystem happens during boot, where it is also busy on the userspace trying to initialise, some processes can continuously get preempted and will be on hold until the interrupts subside. The fix is to backoff on processing received characters for a specified amount of time when an input overrun is seen (received a new character before the previous one is processed). This only stops receive and will continue to transmit characters to serial port. After the backoff period is done, it receive will be re-enabled. This is optional and will only be enabled by setting 'overrun-throttle-ms' in the dts. Signed-off-by: Darwin Dingel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 02ef84c0b26723f4d963b595fb8417904ed7af6b Author: Nicolas Saenz Julienne Date: Mon Dec 10 17:50:05 2018 +0100 gpio: raspberrypi-exp: decrease refcount on firmware dt node [ Upstream commit 85af74c474b21940e88483fd48f6094145c89d97 ] We're getting a reference RPi's firmware node in order to be able to communicate with it's driver. We should decrease the reference count on the dt node after being done with it. Fixes: a98d90e7d588 ("gpio: raspberrypi-exp: Driver for RPi3 GPIO expander via mailbox service") Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e1bb74ba4525adaaabd041a6e6dc9a05f53b2170 Author: Pan Bian Date: Thu Nov 22 08:52:33 2018 +0800 HID: intel-ish-hid: fixes incorrect error handling [ Upstream commit 6e0856d317440a950b17c00a9283114f025e5699 ] The memory chunk allocated by hid_allocate_device() should be released by hid_destroy_device(), not kfree(). Fixes: 0b28cb4bcb1("HID: intel-ish-hid: ISH HID client driver") Signed-off-by: Pan Bian Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3e30e75bc15663d6e5fd56290c5bd296b1086e0f Author: Geert Uytterhoeven Date: Thu Dec 13 19:44:42 2018 +0100 serial: sh-sci: Fix crash in rx_timer_fn() on PIO fallback [ Upstream commit 2e948218b7c1262a3830823d6620eb227e3d4e3a ] When falling back to PIO, active_rx must be set to a different value than cookie_rx[i], else sci_dma_rx_find_active() will incorrectly find a match, leading to a NULL pointer dereference in rx_timer_fn() later. Use zero instead, which is the same value as after driver initialization. Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df3a72c9608ca74e9add4ac781a3613534bc585c Author: Josef Bacik Date: Mon Dec 3 10:20:32 2018 -0500 btrfs: only track ref_heads in delayed_ref_updates [ Upstream commit 158ffa364bf723fa1ef128060646d23dc3942994 ] We use this number to figure out how many delayed refs to run, but __btrfs_run_delayed_refs really only checks every time we need a new delayed ref head, so we always run at least one ref head completely no matter what the number of items on it. Fix the accounting to only be adjusted when we add/remove a ref head. In addition to using this number to limit the number of delayed refs run, a future patch is also going to use it to calculate the amount of space required for delayed refs space reservation. Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e9a7415a347d8e7b0dbedc39cd1791e42abee74b Author: Filipe Manana Date: Fri Nov 16 13:04:44 2018 +0000 Btrfs: allow clear_extent_dirty() to receive a cached extent state record [ Upstream commit 0e6ec385b55f6001da8c6b1532494241e52c550d ] We can have a lot freed extents during the life span of transaction, so the red black tree that keeps track of the ranges of each freed extent (fs_info->freed_extents[]) can get quite big. When finishing a transaction commit we find each range, process it (discard the extents, unpin them) and then remove it from the red black tree. We can use an extent state record as a cache when searching for a range, so that when we clean the range we can use the cached extent state we passed to the search function instead of iterating the red black tree again. Doing things as fast as possible when finishing a transaction (in state TRANS_STATE_UNBLOCKED) is convenient as it reduces the time we block another task that wants to commit the next transaction. So change clear_extent_dirty() to allow an optional extent state record to be passed as an argument, which will be passed down to __clear_extent_bit. Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d87ca19cc574fff6d3bba2cb164c96e299db15dc Author: Anand Jain Date: Sun Nov 11 22:22:20 2018 +0800 btrfs: dev-replace: set result code of cancel by status of scrub [ Upstream commit b47dda2ef6d793b67fd5979032dcd106e3f0a5c9 ] The device-replace needs to check the result code of the scrub workers in btrfs_dev_replace_cancel and distinguish if successful cancel operation and when the there was no operation running. If btrfs_scrub_cancel() fails, return BTRFS_IOCTL_DEV_REPLACE_RESULT_NOT_STARTED so that user can try to cancel the replace again. Signed-off-by: Anand Jain Reviewed-by: David Sterba [ update changelog ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 37410d6a7e4c7d0c469e9b5c8dc9611cbb17b8da Author: Hans van Kranenburg Date: Thu Oct 4 23:24:41 2018 +0200 btrfs: fix ncopies raid_attr for RAID56 [ Upstream commit da612e31aee51bd13231c78a47c714b543bd3ad8 ] RAID5 and RAID6 profile store one copy of the data, not 2 or 3. These values are not yet used anywhere so there's no change. Reviewed-by: Nikolay Borisov Signed-off-by: Hans van Kranenburg Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ff874d5243276a2bbac55be55cd38c189f57d6a7 Author: Nikolay Borisov Date: Thu Nov 8 16:16:38 2018 +0200 btrfs: Check for missing device before bio submission in btrfs_map_bio [ Upstream commit fc8a168aa9ab1680c2bd52bf9db7c994e0f2524f ] Before btrfs_map_bio submits all stripe bios it does a number of checks to ensure the device for every stripe is present. However, it doesn't do a DEV_STATE_MISSING check, instead this is relegated to the lower level btrfs_schedule_bio (in the async submission case, sync submission doesn't check DEV_STATE_MISSING at all). Additionally btrfs_schedule_bios does the duplicate device->bdev check which has already been performed in btrfs_map_bio. This patch moves the DEV_STATE_MISSING check in btrfs_map_bio and removes the duplicate device->bdev check. Doing so ensures that no bio cloning/submission happens for both async/sync requests in the face of missing device. This makes the async io submission path slightly shorter in terms of instruction count. No functional changes. Reviewed-by: Josef Bacik Reviewed-by: Anand Jain Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1cfc35d0deac4534e0e3c6df130863d7bd9ee90f Author: Roger Quadros Date: Fri Dec 14 11:36:15 2018 +0200 usb: ehci-omap: Fix deferred probe for phy handling [ Upstream commit 8dc7623bf608495b6e6743e805807c7840673573 ] PHY model is being used on omap5 platforms even if port mode is not OMAP_EHCI_PORT_MODE_PHY. So don't guess if PHY is required or not based on PHY mode. If PHY is provided in device tree, it must be required. So, if devm_usb_get_phy_by_phandle() gives us an error code other than -ENODEV (no PHY) then error out. This fixes USB Ethernet on omap5-uevm if PHY happens to probe after EHCI thus causing a -EPROBE_DEFER. Cc: Johan Hovold Cc: Ladislav Michl Reported-by: Peter Ujfalusi Signed-off-by: Roger Quadros Tested-by: Peter Ujfalusi Acked-by: Tony Lindgren Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 272ff3bb77445890148dbd797134e4338be60253 Author: Boris Brezillon Date: Sun Dec 16 09:34:17 2018 +0100 mtd: rawnand: sunxi: Write pageprog related opcodes to WCMD_SET [ Upstream commit 732774437ae01d9882e60314e303898e63c7f038 ] The opcodes used by the controller when doing batched page prog should be written in NFC_REG_WCMD_SET not FC_REG_RCMD_SET. Luckily, the default NFC_REG_WCMD_SET value matches the one we set in the driver which explains why we didn't notice the problem. Fixes: 614049a8d904 ("mtd: nand: sunxi: add support for DMA assisted operations") Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit d302bd158ce1e3b358446184133e07b0ab564f81 Author: Jerome Brunet Date: Thu Dec 6 16:18:25 2018 +0100 mmc: meson-gx: make sure the descriptor is stopped on errors [ Upstream commit 18f92bc02f1739b5c4d5b70009fbb7eada45bca3 ] On errors, if we don't stop the descriptor chain, it may continue to run and raise IRQ after we have called mmc_request_done(). This is bad because we won't be able to get cmd anymore and properly deal with the IRQ. This patch makes sure the descriptor chain is stopped before calling mmc_request_done() Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode") Signed-off-by: Jerome Brunet Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7e976ccc4f0666131f1a59d01b958b3e51718084 Author: Lepton Wu Date: Tue Dec 11 11:12:55 2018 -0800 VSOCK: bind to random port for VMADDR_PORT_ANY [ Upstream commit 8236b08cf50f85bbfaf48910a0b3ee68318b7c4b ] The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more in vhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one. Signed-off-by: Lepton Wu Reviewed-by: Jorgen Hansen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e58133e43cb0005524cc8f789e340e797153a6fb Author: Atul Gupta Date: Tue Dec 11 02:20:26 2018 -0800 crypto/chelsio/chtls: listen fails with multiadapt [ Upstream commit 6422ccc5fbefbd219f3fab133f698e58f5aa44eb ] listen fails when more than one tls capable device is registered. tls_hw_hash is called for each dev which loops again for each cdev_list causing listen failure. Hence call chtls_listen_start/stop for specific device than loop over all devices. Signed-off-by: Atul Gupta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4801268958084c32af91f922ab1dde98054b86ff Author: Greg Kroah-Hartman Date: Thu Dec 5 08:32:43 2019 +0100 Revert "KVM: nVMX: move check_vmentry_postreqs() call to nested_vmx_enter_non_root_mode()" This reverts commit 7392aa08f8a4386c99d5c6506a79e2ccd5b4701f which is commit 7671ce21b13b9596163a29f4712cb2451a9b97dc upstream. It should not have been selected for a stable kernel as it breaks the nVMX regression tests. Reported-by: Jack Wang Reported-by: Paolo Bonzini Cc: Sean Christopherson Cc: Jim Mattson Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1865538d5d0a57726071aa0a297c731491d9e720 Author: Greg Kroah-Hartman Date: Thu Dec 5 08:25:45 2019 +0100 Revert "KVM: nVMX: reset cache/shadows when switching loaded VMCS" This reverts commit 9fe573d539a827d123ba7503cc8ac2301424d26b which is commit b7031fd40fcc741b0f9b0c04c8d844e445858b84 upstream. It should not have been selected for a stable kernel as it breaks the nVMX regression tests. Reported-by: Jack Wang Reported-by: Paolo Bonzini Cc: Jim Mattson Cc: Sean Christopherson Cc: Jim Mattson Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 279bbd22774b542aa6ab7b1fa0303678738912a1 Author: Jim Mattson Date: Wed Dec 5 15:28:58 2018 -0800 kvm: vmx: Set IA32_TSC_AUX for legacy mode guests [ Upstream commit 0023ef39dc35c773c436eaa46ca539a26b308b55 ] RDTSCP is supported in legacy mode as well as long mode. The IA32_TSC_AUX MSR should be set to the correct guest value before entering any guest that supports RDTSCP. Fixes: 4e47c7a6d714 ("KVM: VMX: Add instruction rdtscp support for guest") Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Reviewed-by: Marc Orr Reviewed-by: Liran Alon Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 06f464df98351f823c7c30c489e0e6cf15eb8d77 Author: Krzysztof Kozlowski Date: Thu Dec 6 10:45:49 2018 +0100 gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB [ Upstream commit c5510b8dafce5f3f5a039c9b262ebcae0092c462 ] If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return the same type of error as regular version: NULL. All the callers compare the return value of gpio_to_desc() against NULL, so returned ERR_PTR would be treated as non-error case leading to dereferencing of error value. Fixes: 79a9becda894 ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fc3df7cb3e1f5e220a84cae3b184921d5fdbbd6f Author: Marek Vasut Date: Wed Dec 12 02:39:50 2018 +0100 gpio: pca953x: Fix AI overflow on PCAL6524 [ Upstream commit 92f45ebe68181c2d7f76633ffae55bc9447d62cd ] The PCAL_PINCTRL_MASK is too large. The extended register block on PCAL6524, which is the largest chip with this block, has the block limited to address range 0x40..0x7f. This is because the bit 7 in the command register is used for the Address Increment functionality. Trim the mask to 0x60 to match the datasheet and to prevent accidental overwrite of the AI bit. Signed-off-by: Marek Vasut Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 116301fff70a37760959b100bb1228fa29147150 Author: Sara Sharon Date: Mon Aug 20 10:07:32 2018 +0300 iwlwifi: pcie: set cmd_len in the correct place [ Upstream commit 956343a61226e1af3d146386f70a059feb567d0c ] command len is set too early in the code, since when building AMSDU, the size changes. This causes the byte count table to have the wrong size. Fixes: a0ec0169b7a9 ("iwlwifi: support new tx api") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit fd31ea11e87c58041d78fe2782d9d75c63c00174 Author: Sara Sharon Date: Thu Aug 16 13:01:09 2018 +0300 iwlwifi: pcie: fix erroneous print [ Upstream commit 0916224eaa77bff0fbbc747961d550ff8db45457 ] When removing the driver, the following flow can happen: 1. host command is in progress, for example at index 68. 2. RX interrupt is received with the response. 3. Before it is processed, the remove flow kicks in, and calls iwl_pcie_txq_unmap. The function cleans all DMA, and promotes the read pointer to 69. 4. RX thread proceeds with the processing, and is calling iwl_pcie_cmdq_reclaim, which will print this error: iwl_pcie_cmdq_reclaim: Read index for DMA queue txq id (0), index 4 is out of range [0-256] 69 69. Detect this situation, and avoid the print. Change it to warning while at it, to make such issues more noticeable in the future. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 080aee83be54c976f4477bc296bfc992ea912c37 Author: Avraham Stern Date: Wed Aug 15 12:23:39 2018 +0300 iwlwifi: mvm: force TCM re-evaluation on TCM resume [ Upstream commit 7bc2468277033e05401d5f8fd48a772f407338c2 ] When traffic load is not low or low latency is active, TCM schedules re-evaluation work so in case traffic stops TCM will detect that traffic load has become low or that low latency is no longer active. However, if TCM is paused when the re-evaluation work runs, it does not re-evaluate and the re-evaluation work is no longer scheduled. As a result, TCM will not indicate that low latency is no longer active or that traffic load is low when traffic stops. Fix this by forcing TCM re-evaluation when TCM is resumed in case low latency is active or traffic load is not low. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit ccc084cdf1337f844154277d1a4ebfcb2b9be008 Author: Luca Coelho Date: Thu Aug 16 09:23:08 2018 +0300 iwlwifi: move iwl_nvm_check_version() into dvm [ Upstream commit 64866e5da1eabd0c52ff45029b245f5465920031 ] This function is only half-used by mvm (i.e. only the nvm_version part matters, since the calibration version is irrelevant), so it's pointless to export it from iwlwifi. If mvm uses this function, it has the additional complexity of setting the calib version to a bogus value on all cfg structs. To avoid this, move the function to dvm and make a simple comparison of the nvm_version in mvm instead. Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 694c90cd5ba72ebf820209f741fe26084733485f Author: Masahiro Yamada Date: Fri Dec 7 20:33:54 2018 +0900 microblaze: fix multiple bugs in arch/microblaze/boot/Makefile [ Upstream commit 4722a3e6b716d9d4594c3cf3856b03bbd24a59a8 ] This commit fixes some build issues. The first issue is the breakage of linux.bin.ub target since commit ece97f3a5fb5 ("microblaze: Fix simpleImage format generation") because the addition of UIMAGE_{IN,OUT} affected it. make ARCH=microblaze CROSS_COMPILE=microblaze-linux- linux.bin.ub [ snip ] OBJCOPY arch/microblaze/boot/linux.bin UIMAGE arch/microblaze/boot/linux.bin.ub.ub /usr/bin/mkimage: Can't open arch/microblaze/boot/linux.bin.ub: No such file or directory make[1]: *** [arch/microblaze/boot/Makefile;14: arch/microblaze/boot/linux.bin.ub] Error 1 make: *** [arch/microblaze/Makefile;83: linux.bin.ub] Error 2 The second issue is the use of the "if_changed" multiple times for the same target. As commit 92a4728608a8 ("x86/boot: Fix if_changed build flip/flop bug") pointed out, this never works properly. Moreover, generating multiple images as a side-effect is confusing. Let's split the build recipe for each image. simpleImage.
*.unstrip is just a copy of vmlinux. simpleImage.
and simpleImage.
.ub are created in the same way as linux.bin and linux.bin.ub, respectively. I kept simpleImage.* recipes independent of linux.bin.* ones to not change the behavior. Lastly, this commit fixes "make ARCH=microblaze clean". Previously, it only cleaned up the unstrip image. Now, all the simpleImage files are cleaned. Signed-off-by: Masahiro Yamada Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 04bafea14874af4806aab1242c7a8a796fd44632 Author: Masahiro Yamada Date: Fri Dec 7 20:33:53 2018 +0900 microblaze: move "... is ready" messages to arch/microblaze/Makefile [ Upstream commit 2e14f94cf4bc2f15ca5362e81ca3a987c79e3062 ] To prepare for more fixes, move this to arch/microblaze/Makefile. Otherwise, the same "... is ready" would be printed multiple times. Signed-off-by: Masahiro Yamada Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 4e860e92c8fde5d66a193e6994d8485a39e59c3a Author: Masahiro Yamada Date: Fri Dec 7 20:33:52 2018 +0900 microblaze: adjust the help to the real behavior [ Upstream commit bafcc61d998c1ca18f556d92a0e95335ac68c7da ] "make ARCH=microblaze help" mentions simpleImage.
.unstrip, but it is not a real Make target. It does not work because Makefile assumes "system.unstrip" is the name of DT. $ make ARCH=microblaze CROSS_COMPILE=microblaze-linux- simpleImage.system.unstrip [ snip ] make[1]: *** No rule to make target 'arch/microblaze/boot/dts/system.unstrip.dtb', needed by 'arch/microblaze/boot/dts/system.dtb'. Stop. make: *** [Makefile;1060: arch/microblaze/boot/dts] Error 2 make: *** Waiting for unfinished jobs.... simpleImage.
works like a phony target that generates multiple images. Reflect the real behavior. I removed the DT directory path information because it is already explained a few lines below. While I am here, I deleted the redundant *_defconfig explanation. The top-level Makefile caters to list available defconfig files: mmu_defconfig - Build for mmu nommu_defconfig - Build for nommu Signed-off-by: Masahiro Yamada Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit dc040b55964cbebf9134fa4c8dd2a1ab4f0f9e5c Author: Pan Bian Date: Wed Nov 28 11:20:03 2018 +0800 ubi: Do not drop UBI device reference before using [ Upstream commit e542087701f09418702673631a908429feb3eae0 ] The UBI device reference is dropped but then the device is used as a parameter of ubi_err. The bug is introduced in changing ubi_err's behavior. The old ubi_err does not require a UBI device as its first parameter, but the new one does. Fixes: 32608703310 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit d57b00ff7ace7abc8e01fbc2584cc6b7f7dd4cc1 Author: Pan Bian Date: Wed Nov 28 10:57:33 2018 +0800 ubi: Put MTD device after it is not used [ Upstream commit b95f83ab762dd6211351b9140f99f43644076ca8 ] The MTD device reference is dropped via put_mtd_device, however its field ->index is read and passed to ubi_msg. To fix this, the patch moves the reference dropping after calling ubi_msg. Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit c7f81d70d7aee4ce224c73cc23b0ea721ce7ed6c Author: Gabor Juhos Date: Sun Dec 9 18:12:13 2018 +0100 ubifs: Fix default compression selection in ubifs [ Upstream commit d62e98ed1efcaa94caa004f622944afdce5f1c3c ] When ubifs is build without the LZO compressor and no compressor is given the creation of the default file system will fail. before selection the LZO compressor check if it is present and if not fall back to the zlib or none. Signed-off-by: Gabor Juhos Signed-off-by: Hauke Mehrtens Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 3331e61b23b1c7d1b62e1b882650992fc6f364b5 Author: Sagi Grimberg Date: Thu Dec 13 12:34:07 2018 -0800 nvme: fix kernel paging oops [ Upstream commit 092ff0520070fad8407b196f3bb6156ce77a6f98 ] free the controller discard_page correctly. Fixes: cb5b7262b011 ("nvme: provide fallback for discard alloc failure") Signed-off-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2f99d478ddbd8293e6fe499b5906c8c7cfa79141 Author: Darrick J. Wong Date: Wed Dec 12 15:18:52 2018 -0800 xfs: require both realtime inodes to mount [ Upstream commit 64bafd2f1e484e27071e7584642005d56516cb77 ] Since mkfs always formats the filesystem with the realtime bitmap and summary inodes immediately after the root directory, we should expect that both of them are present and loadable, even if there isn't a realtime volume attached. There's no reason to skip this if rbmino == NULLFSINO; in fact, this causes an immediate crash if the there /is/ a realtime volume and someone writes to it. Signed-off-by: Darrick J. Wong Reviewed-by: Bill O'Donnell Signed-off-by: Sasha Levin commit b2d84967f07658bab63e6157bd2758db5cc68c86 Author: Shenghui Wang Date: Thu Dec 13 22:53:50 2018 +0800 bcache: do not mark writeback_running too early [ Upstream commit 79b791466e525c98f6aeee9acf5726e7b27f4231 ] A fresh backing device is not attached to any cache_set, and has no writeback kthread created until first attached to some cache_set. But bch_cached_dev_writeback_init run " dc->writeback_running = true; WARN_ON(test_and_clear_bit(BCACHE_DEV_WB_RUNNING, &dc->disk.flags)); " for any newly formatted backing devices. For a fresh standalone backing device, we can get something like following even if no writeback kthread created: ------------------------ /sys/block/bcache0/bcache# cat writeback_running 1 /sys/block/bcache0/bcache# cat writeback_rate_debug rate: 512.0k/sec dirty: 0.0k target: 0.0k proportional: 0.0k integral: 0.0k change: 0.0k/sec next io: -15427384ms The none ZERO fields are misleading as no alive writeback kthread yet. Set dc->writeback_running false as no writeback thread created in bch_cached_dev_writeback_init(). We have writeback thread created and woken up in bch_cached_dev_writeback _start(). Set dc->writeback_running true before bch_writeback_queue() called, as a writeback thread will check if dc->writeback_running is true before writing back dirty data, and hung if false detected. After the change, we can get the following output for a fresh standalone backing device: ----------------------- /sys/block/bcache0/bcache$ cat writeback_running 0 /sys/block/bcache0/bcache# cat writeback_rate_debug rate: 0.0k/sec dirty: 0.0k target: 0.0k proportional: 0.0k integral: 0.0k change: 0.0k/sec next io: 0ms v1 -> v2: Set dc->writeback_running before bch_writeback_queue() called, Signed-off-by: Shenghui Wang Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6f48e23888b92cacab7c610a6220429256b348cf Author: Shenghui Wang Date: Thu Dec 13 22:53:47 2018 +0800 bcache: do not check if debug dentry is ERR or NULL explicitly on remove [ Upstream commit ae17102316550b4b230a283febe31b2a9ff30084 ] debugfs_remove and debugfs_remove_recursive will check if the dentry pointer is NULL or ERR, and will do nothing in that case. Remove the check in cache_set_free and bch_debug_init. Signed-off-by: Shenghui Wang Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c318f88411a8e69891c691c07b508c4b77772e54 Author: Pan Bian Date: Thu Nov 29 18:48:10 2018 +0800 rtl818x: fix potential use after free [ Upstream commit afbb1947db94eacc5a13302eee88a9772fb78935 ] entry is released via usb_put_urb just after calling usb_submit_urb. However, entry is used if the submission fails, resulting in a use after free bug. The patch fixes this. Signed-off-by: Pan Bian ACKed-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 7cf86c89d7e411cba54da97ef831f9f10aa147b8 Author: Madhan Mohan R Date: Wed Nov 21 07:53:45 2018 +0000 brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373 [ Upstream commit 58e4bbea0c1d9b5ace11df968c5dc096ce052a73 ] Along with F2 watermark (existing) configuration, F1 MesBusyCtrl should be enabled & sdio device RX FIFO watermark should be configured to avoid overflow errors. Reviewed-by: Arend van Spriel Signed-off-by: Madhan Mohan R Signed-off-by: Chi-Hsien Lin Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 38b73129c113e1fd000aff242cbad60103f960da Author: Wright Feng Date: Wed Nov 21 07:53:44 2018 +0000 brcmfmac: set F2 watermark to 256 for 4373 [ Upstream commit e1a08730eeb0bad4d82c3bc40e74854872de618d ] We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional throughput test. Enable watermark to 256 to guarantee the operation stability. Reviewed-by: Arend van Spriel Signed-off-by: Wright Feng Signed-off-by: Chi-Hsien Lin Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 6138e4b132cda808ff283cf15e8480b60894bb7a Author: Brian Norris Date: Mon Dec 3 14:26:55 2018 -0800 mwifiex: debugfs: correct histogram spacing, formatting [ Upstream commit 4cb777c64e030778c569f605398d7604d8aabc0f ] Currently, snippets of this file look like: rx rates (in Mbps): 0=1M 1=2M2=5.5M 3=11M 4=6M 5=9M 6=12M 7=18M 8=24M 9=36M 10=48M 11=54M12-27=MCS0-15(BW20) 28-43=MCS0-15(BW40) 44-53=MCS0-9(VHT:BW20)54-63=MCS0-9(VHT:BW40)64-73=MCS0-9(VHT:BW80) ... noise_flr[--96dBm] = 22 noise_flr[--95dBm] = 149 noise_flr[--94dBm] = 9 noise_flr[--93dBm] = 2 We're missing some spaces, and we're adding a minus sign ('-') on values that are already negative signed integers. Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 1450ff72007696a33b39cc82f1b419d128bbd233 Author: Pan Bian Date: Thu Nov 29 18:25:19 2018 +0800 mwifiex: fix potential NULL dereference and use after free [ Upstream commit 1dcd9429212b98bea87fc6ec92fb50bf5953eb47 ] There are two defects: (1) passing a NULL bss to mwifiex_save_hidden_ssid_channels will result in NULL dereference, (2) using bss after dropping the reference to it via cfg80211_put_bss. To fix them, the patch moves the buggy code to the branch that bss is not NULL and puts it before cfg80211_put_bss. Signed-off-by: Pan Bian Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 4912b454e029ff508754a63347e57746442021a3 Author: Laurent Pinchart Date: Mon Dec 10 11:43:55 2018 +0200 arm64: dts: renesas: draak: Fix CVBS input [ Upstream commit 6f61a2c8f1f6163c7e08c77c5f71df0427e4d2f6 ] A typo in the adv7180 DT node prevents successful probing of the VIN. Fix it. Fixes: 6a0942c20f5c ("arm64: dts: renesas: draak: Describe CVBS input") Signed-off-by: Laurent Pinchart Acked-by: Jacopo Mondi Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 48d37cc4239067671aff37c27faa9b07c4c6611e Author: Eric Biggers Date: Thu Dec 6 15:55:41 2018 -0800 crypto: user - support incremental algorithm dumps [ Upstream commit 0ac6b8fb23c724b015d9ca70a89126e8d1563166 ] CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all registered crypto algorithms, because it doesn't support incremental dumps. crypto_dump_report() only permits itself to be called once, yet the netlink subsystem allocates at most ~64 KiB for the skb being dumped to. Thus only the first recvmsg() returns data, and it may only include a subset of the crypto algorithms even if the user buffer passed to recvmsg() is large enough to hold all of them. Fix this by using one of the arguments in the netlink_callback structure to keep track of the current position in the algorithm list. Then userspace can do multiple recvmsg() on the socket after sending the dump request. This is the way netlink dumps work elsewhere in the kernel; it's unclear why this was different (probably just an oversight). Also fix an integer overflow when calculating the dump buffer size hint. Fixes: a38f7907b926 ("crypto: Add userspace configuration API") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 43cd68d7002bcc70cf37c2c88057e17fa9a46b98 Author: Harald Freudenberger Date: Mon Nov 26 15:50:04 2018 +0100 s390/zcrypt: make sysfs reset attribute trigger queue reset [ Upstream commit 42a87d4103ae365e18c3be1333592ab583b8ad9d ] Until now there is no way to reset a AP queue or card. Driving a card or queue offline and online again does only toggle the 'software' online state. The only way to trigger a (hardware) reset is by running hot-unplug/hot-plug for example on the HMC. This patch makes the queue reset attribute in sysfs writable. Writing into this attribute triggers a reset on the AP queue's state machine. So the AP queue is flushed and state machine runs through the initial states which cause a reset (PQAP(RAPQ)) and a re-registration to interrupts (PQAP(AQIC)) if available. The reset sysfs attribute is writable by root only. So only an administrator is allowed to initiate a reset of AP queues. Please note that the queue's counter values are left untouched by the reset. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 5ac0da68eae1e170888bd366f077ef484c2a6403 Author: Jens Axboe Date: Wed Dec 12 09:18:11 2018 -0700 nvme: provide fallback for discard alloc failure [ Upstream commit cb5b7262b011cfb793519bf97e54dff5282da23c ] When boxes are run near (or to) OOM, we have a problem with the discard page allocation in nvme. If we fail allocating the special page, we return busy, and it'll get retried. But since ordering is honored for dispatch requests, we can keep retrying this same IO and failing. Behind that IO could be requests that want to free memory, but they never get the chance. Allocate a fixed discard page per controller for a safe fallback, and use that if the initial allocation fails. Signed-off-by: Jens Axboe Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d702d7bc7eb46c0fc91c1143220e05459f598c8d Author: Giridhar Malavali Date: Mon Dec 10 12:36:24 2018 -0800 scsi: qla2xxx: Fix for FC-NVMe discovery for NPIV port [ Upstream commit 835aa4f2691e4ed4ed16de81f3cabf17a87a164f ] This patch fixes NVMe discovery by setting SKIP_PRLI flag, so that PRLI is driven by driver and is retried when the NPIV port is detected to have NVMe capability. Signed-off-by: Giridhar Malavali Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 78777dd6174eb18509a0ab68a904fe2fd6210822 Author: Himanshu Madhani Date: Mon Dec 10 12:36:23 2018 -0800 scsi: qla2xxx: Fix NPIV handling for FC-NVMe [ Upstream commit 5e6803b409ba3c18434de6693062d98a470bcb1e ] This patch fixes issues with NPIV port with FC-NVMe. Clean up code for remoteport delete and also call nvme_delete when deleting VPs. Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 58ab95b03497dec6e513ca860fa0fa289372c819 Author: James Smart Date: Mon Dec 10 19:37:01 2018 -0800 scsi: lpfc: Enable Management features for IF_TYPE=6 [ Upstream commit 719162bd5bb968203397b9b1d0dd30a9797bbd09 ] Addition of support for if_type=6 missed several checks for interface type, resulting in the failure of several key management features such as firmware dump and loopback testing. Correct the checks on the if_type so that both SLI4 IF_TYPE's 2 and 6 are supported. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e772949a3fd6f5aa5a4ea2a1e10fb0e9725f5498 Author: Hans de Goede Date: Sat Dec 8 13:59:24 2018 +0100 ACPI / LPSS: Ignore acpi_device_fix_up_power() return value [ Upstream commit 1a2fa02f7489dc4d746f2a15fb77b3ce1affade8 ] Ignore acpi_device_fix_up_power() return value. If we return an error we end up with acpi_default_enumeration() still creating a platform- device for the device and we end up with the device still being used but without the special LPSS related handling which is not useful. Specicifically ignoring the error fixes the touchscreen no longer working after a suspend/resume on a Prowise PT301 tablet. This tablet has a broken _PS0 method on the touchscreen's I2C controller, causing acpi_device_fix_up_power() to fail, causing fallback to standard platform-dev handling and specifically causing acpi_lpss_save/restore_ctx to not run. The I2C controllers _PS0 method does actually turn on the device, but then does some more nonsense which fails when run during early boot trying to use I2C opregion handling on another not-yet registered I2C controller. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d411bd85844737769af3b6cde193c84aac1422b5 Author: Arnd Bergmann Date: Mon Dec 10 22:58:38 2018 +0100 ARM: ks8695: fix section mismatch warning [ Upstream commit 4aa64677330beeeed721b4b122884dabad845d66 ] WARNING: vmlinux.o(.text+0x13250): Section mismatch in reference from the function acs5k_i2c_init() to the (unknown reference) .init.data:(unknown) The function acs5k_i2c_init() references the (unknown reference) __initdata (unknown). This is often because acs5k_i2c_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Signed-off-by: Arnd Bergmann Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 22227437ca68262144031a8077a8addab5f2af37 Author: Dave Chinner Date: Wed Dec 12 08:46:21 2018 -0800 xfs: zero length symlinks are not valid [ Upstream commit 43feeea88c9cb2955b9f7ba8152ec5abeea42810 ] A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload. The underlying problem is the issue in xfs_inactive_symlink(): the inode is unlocked between the symlink inactivation/truncation and the inode being freed. This opens a window for the inode to be written to disk before it xfs_ifree() removes it from the unlinked list, marks it free in the inobt and zeros the mode. For shortform inodes, the fix is simple. xfs_ifree() clears the data fork state, so there's no need to do it in xfs_inactive_symlink(). This means the shortform fork verifier will not see a zero length data fork as it mirrors the inode size through to xfs_ifree()), and hence if the inode gets written back and the fork verifiers are run they will still see a fork that matches the on-disk inode size. For extent form (remote) symlinks, it is a little more tricky. Here we explicitly set the inode size to zero, so the above race can lead to zero length symlinks on disk. Because the inode is unlinked at this point (i.e. on the unlinked list) and unreferenced, it can never be seen again by a user. Hence when we set the inode size to zeor, also change the type to S_IFREG. xfs_ifree() expects S_IFREG inodes to be of zero length, and so this avoids all the problems of zero length symlinks ever hitting the disk. It also avoids the problem of needing to handle zero length symlink inodes in log recovery to replay the extent free intents and the remaining deferops to free the extents the symlink used. Also add a couple of asserts to warn us if zero length symlinks end up in either the symlink create or inactivation paths. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 4d54a79695246ef5c40bd0ab4bd0ff00ae8f7927 Author: Thomas Meyer Date: Sun Dec 2 21:52:11 2018 +0100 PM / AVS: SmartReflex: NULL check before some freeing functions is not needed [ Upstream commit 14d338a857f05f894ba3badd9e6d3039c68b8180 ] NULL check before some freeing functions is not needed. Signed-off-by: Thomas Meyer Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d2e3e3c3c14ba62eeff4a8072789775ebdf69858 Author: Gal Pressman Date: Mon Dec 10 17:17:25 2018 +0200 RDMA/vmw_pvrdma: Use atomic memory allocation in create AH [ Upstream commit a276a4d93bf1580d737f38d1810e5f4b166f3edd ] Create address handle callback should not sleep, use GFP_ATOMIC instead of GFP_KERNEL for memory allocation. Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Cc: Adit Ranadive Signed-off-by: Gal Pressman Reviewed-by: Yuval Shaia Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 64694b276d74c653051637caa4bfa5e8c27b30ad Author: Will Deacon Date: Tue Dec 11 13:41:32 2018 +0000 arm64: preempt: Fix big-endian when checking preempt count in assembly [ Upstream commit 7faa313f05cad184e8b17750f0cbe5216ac6debb ] Commit 396244692232 ("arm64: preempt: Provide our own implementation of asm/preempt.h") extended the preempt count field in struct thread_info to 64 bits, so that it consists of a 32-bit count plus a 32-bit flag indicating whether or not the current task needs rescheduling. Whilst the asm-offsets definition of TSK_TI_PREEMPT was updated to point to this new field, the assembly usage was left untouched meaning that a 32-bit load from TSK_TI_PREEMPT on a big-endian machine actually returns the reschedule flag instead of the count. Whilst we could fix this by pointing TSK_TI_PREEMPT at the count field, we're actually better off reworking the two assembly users so that they operate on the whole 64-bit value in favour of inspecting the thread flags separately in order to determine whether a reschedule is needed. Acked-by: Ard Biesheuvel Reported-by: "kernelci.org bot" Tested-by: Kevin Hilman Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2ec10345885541e618fb4a01694bce4e562b8e44 Author: Lijun Ou Date: Sat Dec 8 18:40:09 2018 +0800 RDMA/hns: Fix the bug while use multi-hop of pbl [ Upstream commit 4af07f01f7a787ba5158352b98c9e3cb74995a1c ] It will prevent multiply overflow when defines the pbl for u64 type. Signed-off-by: Lijun Ou Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 60da6da4b5117c262c10ec921964299c773a4125 Author: Aaro Koskinen Date: Tue Dec 4 19:57:42 2018 +0200 ARM: OMAP1: fix USB configuration for device-only setups [ Upstream commit c7b7b5cbd0c859b1546a5a3455d457708bdadf4c ] Currently we do USB configuration only if the host mode (CONFIG_USB) is enabled. But it should be done also in the case of device-only setups, so change the condition to CONFIG_USB_SUPPORT. This allows to use omap_udc on Palm Tungsten E. Signed-off-by: Aaro Koskinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 0086d127f90df2cd3dccc76e259deacfa51004c6 Author: Vadim Pasternak Date: Thu Nov 15 17:26:57 2018 +0000 platform/x86: mlx-platform: Fix LED configuration [ Upstream commit 440f343df1996302d9a3904647ff11b689bf27bc ] Exchange LED configuration between msn201x and next generation systems types. Bug was introduced when LED driver activation was added to mlx-platform. LED configuration for the three new system MQMB7, MSN37, MSN34 was assigned to MSN21 and vice versa. This bug affects MSN21 only and likely requires backport to v4.19. Fixes: 1189456b1cce ("platform/x86: mlx-platform: Add LED platform driver activation") Signed-off-by: Vadim Pasternak Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 08d8ab9615c522a432a92523ed16a00d77b14d5d Author: Tony Lindgren Date: Mon Dec 10 14:11:26 2018 -0800 bus: ti-sysc: Check for no-reset and no-idle flags at the child level [ Upstream commit 4014c08ba39476a18af546186da625a6833a1529 ] With ti-sysc, we need to now have the device tree properties for ti,no-reset-on-init and ti,no-idle-on-init at the module level instead of the child device level. Let's check for these properties at the child device level to enable quirks, and warn about moving the properties to the module level. Otherwise am335x-evm based boards tagging gpio1 with ti,no-reset-on-init will have their DDR power disabled if wired up in such a tricky way. Note that this should not be an issue for earlier kernels as we don't rely on this until the dts files have been updated to probe with ti-sysc interconnect target driver. Cc: Peter Ujfalusi Reported-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 4b40393b5240356e54f6b27bd39a9294a69a7081 Author: Suzuki K Poulose Date: Mon Dec 10 18:07:33 2018 +0000 arm64: smp: Handle errors reported by the firmware [ Upstream commit f357b3a7e17af7736d67d8267edc1ed3d1dd9391 ] The __cpu_up() routine ignores the errors reported by the firmware for a CPU bringup operation and looks for the error status set by the booting CPU. If the CPU never entered the kernel, we could end up in assuming stale error status, which otherwise would have been set/cleared appropriately by the booting CPU. Reported-by: Steve Capper Cc: Will Deacon Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e3d27b94111bd024e9ef929020e38ddbfc19d1dc Author: Steve Capper Date: Thu Dec 6 22:50:40 2018 +0000 arm64: mm: Prevent mismatched 52-bit VA support [ Upstream commit a96a33b1ca57dbea4285893dedf290aeb8eb090b ] For cases where there is a mismatch in ARMv8.2-LVA support between CPUs we have to be careful in allowing secondary CPUs to boot if 52-bit virtual addresses have already been enabled on the boot CPU. This patch adds code to the secondary startup path. If the boot CPU has enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the secondary can also enable 52-bit support. If not, the secondary is prevented from booting and an error message is displayed indicating why. Technically this patch could be implemented using the cpufeature code when considering 52-bit userspace support. However, we employ low level checks here as the cpufeature code won't be able to run if we have mismatched 52-bit kernel va support. Signed-off-by: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 57f3359cdabe46180ac0e42b6ab8157d3cfc4989 Author: Tony Lindgren Date: Wed Dec 5 14:48:51 2018 -0800 ARM: dts: Fix hsi gdd range for omap4 [ Upstream commit e9e685480b74aef3f3d0967dadb52eea3ff625d2 ] While reviewing the missing mcasp ranges I noticed omap4 hsi range for gdd is wrong so let's fix it. I'm not aware of any omap4 devices in mainline kernel though that use hsi though. Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") Reviewed-by: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 9b1f6bde17d651aec810d1ead617691685de43c2 Author: Helge Deller Date: Thu Nov 15 21:06:34 2018 +0100 parisc: Fix HP SDC hpa address output [ Upstream commit c4bff35ca1bfba886da6223c9fed76a2b1382b8e ] Show the hpa address of the HP SDC instead of a hashed value, e.g.: HP SDC: HP SDC at 0xf0201000, IRQ 23 (NMI IRQ 24) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit d18f228f504eb7ab0cf434d7a87855c69fc638f8 Author: Helge Deller Date: Thu Nov 15 21:09:59 2018 +0100 parisc: Fix serio address output [ Upstream commit 785145171d17af2554128becd6a7c8f89e101141 ] We want the hpa addresses printed in the serio modules, not some virtual ioremap()ed address, e.g.: serio: gsc-ps2-keyboard port at 0xf0108000 irq 22 @ 2:0:11 serio: gsc-ps2-mouse port at 0xf0108100 irq 22 @ 2:0:12 Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 72a50a1e1c6572b34e783c9e872eeb9fe0863994 Author: Fabio Estevam Date: Wed Dec 5 16:10:01 2018 -0200 ARM: dts: imx53-voipac-dmm-668: Fix memory node duplication [ Upstream commit 998a84c27a7f3f9133d32af64e19c05cec161a1a ] imx53-voipac-dmm-668 has two memory nodes, but the correct representation would be to use a single one with two reg entries - one for each RAM chip select, so fix it accordingly. Reported-by: Marco Franchi Signed-off-by: Fabio Estevam Signed-off-by: Marco Franchi Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit bf39f5b323ebb63dcd0497dc1df9923e9315f2f6 Author: Fabio Estevam Date: Mon Nov 26 10:40:54 2018 -0200 ARM: dts: imx25: Fix memory node duplication [ Upstream commit 59d8bb363f563e4a147a291037bf979cb8ff9a59 ] Boards based on imx25 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx25.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d2eb50e57a5cef9f8ad0bf749291be90ec77428f Author: Fabio Estevam Date: Mon Nov 26 10:40:53 2018 -0200 ARM: dts: imx27: Fix memory node duplication [ Upstream commit 38715dcd49b4430ac5b6bc1293278d91a4d32bd5 ] Boards based on imx27 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx27.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 54750b6f66715bc1d205d57d93a503b3eb04a284 Author: Fabio Estevam Date: Mon Nov 26 10:40:52 2018 -0200 ARM: dts: imx1: Fix memory node duplication [ Upstream commit 62864d5665c4fc636d3021f829b3ac00fa058e30 ] Boards based on imx1 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx1.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6aeb6bd0eda6c0b693f4070e6501903093f7a777 Author: Fabio Estevam Date: Mon Nov 26 10:08:55 2018 -0200 ARM: dts: imx23: Fix memory node duplication [ Upstream commit b629e83520fafe6f4c2f3e8c88c78a496fc4987c ] Boards based on imx23 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx23.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 1694780bd4ca108a0fff86ad62f6e2da5f104322 Author: Fabio Estevam Date: Fri Nov 23 11:25:19 2018 -0200 ARM: dts: imx50: Fix memory node duplication [ Upstream commit aab5e3ea95b958cf22a24e756a84e635bdb081c1 ] imx50-evk has duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx50.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2442b4c0f30afddce4a86ad7a505e10a33819846 Author: Fabio Estevam Date: Tue Nov 20 13:59:45 2018 -0200 ARM: dts: imx6sl: Fix memory node duplication [ Upstream commit 7fa8ab65ee15e386558ac5e971004712da91e2dd ] Boards based on imx6sl have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6sl.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit bae011f4c9a4e89f165a801704c295bae5defc69 Author: Fabio Estevam Date: Tue Nov 20 13:59:44 2018 -0200 ARM: dts: imx6sx: Fix memory node duplication [ Upstream commit 216f35fedd8688c8b654ebfbad18c6e64713fad7 ] Boards based on imx6sx have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6sx.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0990926c93952281328d14e90cedc1fa310246f5 Author: Fabio Estevam Date: Tue Nov 20 13:59:43 2018 -0200 ARM: dts: imx6ul: Fix memory node duplication [ Upstream commit 750d8df6e7b269b828f66631a1d39ea027afc92a ] Boards based on imx6ul have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6ul.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e021f0ccc4fa87e57977fc6e7e982a515d825482 Author: Fabio Estevam Date: Tue Nov 6 13:40:47 2018 -0200 ARM: dts: imx7: Fix memory node duplication [ Upstream commit 29988e867cb17de7119e971f9acfad2c3fccdb47 ] Boards based on imx7 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx7s.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a90469345b263d4e91308270e86066e47f73bf21 Author: Fabio Estevam Date: Tue Nov 6 13:40:46 2018 -0200 ARM: dts: imx35: Fix memory node duplication [ Upstream commit 8721610a6c2b8c42fc57819d8c3bfbb9166f95a3 ] Boards based on imx35 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx35.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6bc1e695b4be2f5140f7ec2531f4aa71b40e6474 Author: Fabio Estevam Date: Tue Nov 6 13:40:45 2018 -0200 ARM: dts: imx31: Fix memory node duplication [ Upstream commit 013d37e4707e24c7b9bc3fc55aeda55ce9c2b262 ] Boards based on imx31 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx31.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Reviewed-by: Vladimir Zapolskiy Tested-by: Vladimir Zapolskiy Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ca02e14bdd7f1756b5a7ef6ad94dd7111c6440c0 Author: Fabio Estevam Date: Mon Nov 5 19:14:46 2018 -0200 ARM: dts: imx53: Fix memory node duplication [ Upstream commit e8fd17b900a4a1e3a8bef7b44727cbad35db05a7 ] Boards based on imx53 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx53.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5a1e6f95733c6438a694078b158f7a19ff687dd0 Author: Fabio Estevam Date: Mon Nov 5 19:14:45 2018 -0200 ARM: dts: imx51: Fix memory node duplication [ Upstream commit 6a9681168b83c62abfa457c709f2f4b126bd6b92 ] Boards based on imx51 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx51.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8c0c8c2a80b234e30235ea914a298e403ca75f08 Author: Uwe Kleine-König Date: Wed Nov 28 10:04:16 2018 +0100 ARM: debug-imx: only define DEBUG_IMX_UART_PORT if needed [ Upstream commit 7c41ea57beb2aee96fa63091a457b1a2826f3c42 ] If debugging on i.MX is enabled DEBUG_IMX_UART_PORT defines which UART is used for the debug output. If however debugging is off don't only hide the then unused config item but drop it completely by using a dependency instead of a conditional prompt. This fixes DEBUG_IMX_UART_PORT being present in the kernel config even if DEBUG_LL is disabled. Signed-off-by: Uwe Kleine-König Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit dee3f77032077225a2346ffd142091c7c41fe939 Author: Masami Hiramatsu Date: Mon Nov 5 18:00:43 2018 +0900 tracing: Lock event_mutex before synth_event_mutex [ Upstream commit fc800a10be26017f8f338bc8e500d48e3e6429d9 ] synthetic event is using synth_event_mutex for protecting synth_event_list, and event_trigger_write() path acquires locks as below order. event_trigger_write(event_mutex) ->trigger_process_regex(trigger_cmd_mutex) ->event_hist_trigger_func(synth_event_mutex) On the other hand, synthetic event creation and deletion paths call trace_add_event_call() and trace_remove_event_call() which acquires event_mutex. In that case, if we keep the synth_event_mutex locked while registering/unregistering synthetic events, its dependency will be inversed. To avoid this issue, current synthetic event is using a 2 phase process to create/delete events. For example, it searches existing events under synth_event_mutex to check for event-name conflicts, and unlocks synth_event_mutex, then registers a new event under event_mutex locked. Finally, it locks synth_event_mutex and tries to add the new event to the list. But it can introduce complexity and a chance for name conflicts. To solve this simpler, this introduces trace_add_event_call_nolock() and trace_remove_event_call_nolock() which don't acquire event_mutex inside. synthetic event can lock event_mutex before synth_event_mutex to solve the lock dependency issue simpler. Link: http://lkml.kernel.org/r/154140844377.17322.13781091165954002713.stgit@devbox Reviewed-by: Tom Zanussi Tested-by: Tom Zanussi Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 67547b9b46602759a4d29ee6d8655837a94e5b68 Author: Linus Walleij Date: Fri Oct 19 09:00:51 2018 +0200 ARM: dts: Fix up SQ201 flash access [ Upstream commit d88b11ef91b15d0af9c0676cbf4f441a0dff0c56 ] This sets the partition information on the SQ201 to be read out from the RedBoot partition table, removes the static partition table and sets our boot options to mount root from /dev/mtdblock2 where the squashfs+JFFS2 resides. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ee6d2bedb400ffc904ddddc06270167ec43c6565 Author: James Smart Date: Thu Nov 29 16:09:40 2018 -0800 scsi: lpfc: Fix dif and first burst use in write commands [ Upstream commit 7c4042a4d0b7532cfbc90478fd3084b2dab5849e ] When dif and first burst is used in a write command wqe, the driver was not properly setting fields in the io command request. This resulted in no dif bytes being sent and invalid xfer_rdy's, resulting in the io being aborted by the hardware. Correct the wqe initializaton when both dif and first burst are used. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 20feb73330490eac584551824369946b82ee4c59 Author: James Smart Date: Thu Nov 29 16:09:32 2018 -0800 scsi: lpfc: Fix kernel Oops due to null pring pointers [ Upstream commit 5a9eeff57f340238c39c95d8e7e54c96fc722de7 ] Driver is hitting null pring pointers in lpfc_do_work(). Pointer assignment occurs based on SLI-revision. If recovering after an error, its possible the sli revision for the port was cleared, making the lpfc_phba_elsring() not return a ring pointer, thus the null pointer. Add SLI revision checking to lpfc_phba_elsring() and status checking to all callers. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a8c0f6334e56a3218f69e7dfa768fb352cef7492 Author: Bart Van Assche Date: Tue Nov 27 15:51:55 2018 -0800 scsi: target/tcmu: Fix queue_cmd_ring() declaration [ Upstream commit e7f411049f5164ee6db6c3434c07302846f09990 ] This patch does not change any functionality but avoids that sparse complains about the queue_cmd_ring() function and its callers. Fixes: 6fd0ce79724d ("tcmu: prep queue_cmd_ring to be used by unmap wq") Reviewed-by: David Disseldorp Cc: Nicholas Bellinger Cc: Mike Christie Cc: Christoph Hellwig Cc: Hannes Reinecke Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 480233f89d42b33f099387c001692a448a105416 Author: Uwe Kleine-König Date: Thu Oct 17 21:22:18 2019 +0200 pwm: bcm-iproc: Prevent unloading the driver module while in use [ Upstream commit 24906a41eecb73d51974ade0847c21e429beec60 ] The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König Reviewed-by: Florian Fainelli Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 27d22db4ccf1a9e298651cc1d8a2578b721cc19d Author: Dan Carpenter Date: Thu Nov 7 10:48:47 2019 +0300 block: drbd: remove a stray unlock in __drbd_send_protocol() [ Upstream commit 8e9c523016cf9983b295e4bc659183d1fa6ef8e0 ] There are two callers of this function and they both unlock the mutex so this ends up being a double unlock. Fixes: 44ed167da748 ("drbd: rcu_read_lock() and rcu_dereference() for tconn->net_conf") Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 51a564498cfbe97a631bcd7fb30faf2bb254860e Author: Ahmed Zaki Date: Thu Oct 31 06:12:43 2019 -0600 mac80211: fix station inactive_time shortly after boot [ Upstream commit 285531f9e6774e3be71da6673d475ff1a088d675 ] In the first 5 minutes after boot (time of INITIAL_JIFFIES), ieee80211_sta_last_active() returns zero if last_ack is zero. This leads to "inactive time" showing jiffies_to_msecs(jiffies). # iw wlan0 station get fc:ec:da:64:a6:dd Station fc:ec:da:64:a6:dd (on wlan0) inactive time: 4294894049 ms . . connected time: 70 seconds Fix by returning last_rx if last_ack == 0. Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20191031121243.27694-1-anzaki@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b707e0da2791c0e8a36c20f81d63fd264a267bf4 Author: Toke Høiland-Jørgensen Date: Tue Nov 5 16:57:50 2019 +0100 net/fq_impl: Switch to kvmalloc() for memory allocation [ Upstream commit 71e67c3bd127cfe7863f54e4b087eba1cc8f9a7a ] The FQ implementation used by mac80211 allocates memory using kmalloc(), which can fail; and Johannes reported that this actually happens in practice. To avoid this, switch the allocation to kvmalloc() instead; this also brings fq_impl in line with all the FQ qdiscs. Fixes: 557fc4a09803 ("fq: add fair queuing framework") Reported-by: Johannes Berg Signed-off-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/20191105155750.547379-1-toke@redhat.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a8a61f82cc9ff679a5621952f907f129acc23cd6 Author: Jeff Layton Date: Thu Nov 7 09:39:32 2019 -0500 ceph: return -EINVAL if given fsc mount option on kernel w/o support [ Upstream commit ff29fde84d1fc82f233c7da0daa3574a3942bec7 ] If someone requests fscache on the mount, and the kernel doesn't support it, it should fail the mount. [ Drop ceph prefix -- it's provided by pr_err. ] Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 0f716cda304bd3b80edf65ccf3d4a087c06c04fe Author: Vladimir Oltean Date: Wed Nov 6 00:01:40 2019 +0200 net: mscc: ocelot: fix __ocelot_rmw_ix prototype [ Upstream commit 17fdd7638cb687cd7f15a48545f25d738f0101e0 ] The "read-modify-write register index" function is declared with a confusing prototype: the "mask" and "reg" arguments are swapped. Fortunately, this does not affect callers so far. Both arguments are u32, and the wrapper macros (ocelot_rmw_ix etc) have the arguments in the correct order (the one from ocelot_io.c). Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a30c6e424fddff9470e021f644f960a54f81c844 Author: Doug Berger Date: Tue Nov 5 11:07:26 2019 -0800 net: bcmgenet: reapply manual settings to the PHY [ Upstream commit 0686bd9d5e6863f60e4bb1e78e6fe7bb217a0890 ] The phy_init_hw() function may reset the PHY to a configuration that does not match manual network settings stored in the phydev structure. If the phy state machine is polled rather than event driven this can create a timing hazard where the phy state machine might alter the settings stored in the phydev structure from the value read from the BMCR. This commit follows invocations of phy_init_hw() by the bcmgenet driver with invocations of the genphy_config_aneg() function to ensure that the BMCR is written to match the settings held in the phydev structure. This prevents the risk of manual settings being accidentally altered. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit acd6a29134f081cba7f23042fe94a8fcb2b77802 Author: Doug Berger Date: Tue Nov 5 11:07:24 2019 -0800 net: bcmgenet: use RGMII loopback for MAC reset [ Upstream commit 3a55402c93877d291b0a612d25edb03d1b4b93ac ] As noted in commit 28c2d1a7a0bf ("net: bcmgenet: enable loopback during UniMAC sw_reset") the UniMAC must be clocked while sw_reset is asserted for its state machines to reset cleanly. The transmit and receive clocks used by the UniMAC are derived from the signals used on its PHY interface. The bcmgenet MAC can be configured to work with different PHY interfaces including MII, GMII, RGMII, and Reverse MII on internal and external interfaces. Unfortunately for the UniMAC, when configured for MII the Tx clock is always driven from the PHY which places it outside of the direct control of the MAC. The earlier commit enabled a local loopback mode within the UniMAC so that the receive clock would be derived from the transmit clock which addressed the observed issue with an external GPHY disabling it's Rx clock. However, when a Tx clock is not available this loopback is insufficient. This commit implements a workaround that leverages the fact that the MAC can reliably generate all of its necessary clocking by enterring the external GPHY RGMII interface mode with the UniMAC in local loopback during the sw_reset interval. Unfortunately, this has the undesirable side efect of the RGMII GTXCLK signal being driven during the same window. In most configurations this is a benign side effect as the signal is either not routed to a pin or is already expected to drive the pin. The one exception is when an external MII PHY is expected to drive the same pin with its TX_CLK output creating output driver contention. This commit exploits the IEEE 802.3 clause 22 standard defined isolate mode to force an external MII PHY to present a high impedance on its TX_CLK output during the window to prevent any contention at the pin. The MII interface is used internally with the 40nm internal EPHY which agressively disables its clocks for power savings leading to incomplete resets of the UniMAC and many instabilities observed over the years. The workaround of this commit is expected to put an end to those problems. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ff3f7465ee985aec0e43b626dd2ff6497e76beed Author: Ilya Leoshkevich Date: Tue Nov 5 21:17:06 2019 -0800 scripts/gdb: fix debugging modules compiled with hot/cold partitioning [ Upstream commit 8731acc5068eb3f422a45c760d32198175c756f8 ] gcc's -freorder-blocks-and-partition option makes it group frequently and infrequently used code in .text.hot and .text.unlikely sections respectively. At least when building modules on s390, this option is used by default. gdb assumes that all code is located in .text section, and that .text section is located at module load address. With such modules this is no longer the case: there is code in .text.hot and .text.unlikely, and either of them might precede .text. Fix by explicitly telling gdb the addresses of code sections. It might be tempting to do this for all sections, not only the ones in the white list. Unfortunately, gdb appears to have an issue, when telling it about e.g. loadable .note.gnu.build-id section causes it to think that non-loadable .note.Linux section is loaded at address 0, which in turn causes NULL pointers to be resolved to bogus symbols. So keep using the white list approach for the time being. Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich Reviewed-by: Jan Kiszka Cc: Kieran Bingham Cc: Heiko Carstens Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 22f4892950b2b783f2e2884735549b9441faef12 Author: Olivier Moysan Date: Mon Nov 4 14:36:54 2019 +0100 ASoC: stm32: sai: add restriction on mmap support [ Upstream commit eaf072e512d54c95b0977eda06cbca3151ace1e5 ] Do not support mmap in S/PDIF mode. In S/PDIF mode the buffer has to be copied, to allow the channel status bits insertion. Signed-off-by: Olivier Moysan Link: https://lore.kernel.org/r/20191104133654.28750-1-olivier.moysan@st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3f034e6889e7f0d369cba911b0b44765c320f0d9 Author: Xingyu Chen Date: Sun Sep 29 18:53:49 2019 +0800 watchdog: meson: Fix the wrong value of left time [ Upstream commit 2c77734642d52448aca673e889b39f981110828b ] The left time value is wrong when we get it by sysfs. The left time value should be equal to preset timeout value minus elapsed time value. According to the Meson-GXB/GXL datasheets which can be found at [0], the timeout value is saved to BIT[0-15] of the WATCHDOG_TCNT, and elapsed time value is saved to BIT[16-31] of the WATCHDOG_TCNT. [0]: http://linux-meson.com Fixes: 683fa50f0e18 ("watchdog: Add Meson GXBB Watchdog Driver") Signed-off-by: Xingyu Chen Acked-by: Neil Armstrong Reviewed-by: Kevin Hilman Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 7302e7b10855e8512d406e2cb32916c71edb8936 Author: Timo Schlüßler Date: Fri Oct 11 15:38:19 2019 +0200 can: mcp251x: mcp251x_restart_work_handler(): Fix potential force_quit race condition [ Upstream commit 27a0e54bae09d2dd023a01254db506d61cc50ba1 ] In mcp251x_restart_work_handler() the variable to stop the interrupt handler (priv->force_quit) is reset after the chip is restarted and thus a interrupt might occur. This patch fixes the potential race condition by resetting force_quit before enabling interrupts. Signed-off-by: Timo Schlüßler Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 24e10fc2e0db64a87853f868f5c8dafac469ec8a Author: Marc Kleine-Budde Date: Mon Jul 15 20:53:08 2019 +0200 can: flexcan: increase error counters if skb enqueueing via can_rx_offload_queue_sorted() fails [ Upstream commit 758124335a9dd649ab820bfb5b328170919ee7dc ] The call to can_rx_offload_queue_sorted() may fail and return an error (in the current implementation due to resource shortage). The passed skb is consumed. This patch adds incrementing of the appropriate error counters to let the device statistics reflect that there's a problem. Reported-by: Martin Hundebøll Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ee798153829321cc25fcdd86f1e3e74accc4b0b6 Author: Marc Kleine-Budde Date: Tue Sep 24 18:45:38 2019 +0000 can: rx-offload: can_rx_offload_irq_offload_fifo(): continue on error [ Upstream commit 1f7f504dcd9d1262437bdcf4fa071e41dec1af03 ] In case of a resource shortage, i.e. the rx_offload queue will overflow or a skb fails to be allocated (due to OOM), can_rx_offload_offload_one() will call mailbox_read() to discard the mailbox and return an ERR_PTR. If the hardware FIFO is empty can_rx_offload_offload_one() will return NULL. In case a CAN frame was read from the hardware, can_rx_offload_offload_one() returns the skb containing it. Without this patch can_rx_offload_irq_offload_fifo() bails out if no skb returned, regardless of the reason. Similar to can_rx_offload_irq_offload_timestamp() in case of a resource shortage the whole FIFO should be discarded, to avoid an IRQ storm and give the system some time to recover. However if the FIFO is empty the loop can be left. With this patch the loop is left in case of empty FIFO, but not on errors. Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 5c8f5485614c17dd8918d790cedd13f710809197 Author: Jeroen Hofstee Date: Tue Sep 24 18:45:38 2019 +0000 can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error [ Upstream commit c2a9f74c9d18acfdcabd3361adc7eac82c537a66 ] In case of a resource shortage, i.e. the rx_offload queue will overflow or a skb fails to be allocated (due to OOM), can_rx_offload_offload_one() will call mailbox_read() to discard the mailbox and return an ERR_PTR. However can_rx_offload_irq_offload_timestamp() bails out in the error case. In case of a resource shortage all mailboxes should be discarded, to avoid an IRQ storm and give the system some time to recover. Since can_rx_offload_irq_offload_timestamp() is typically called from a while loop, all message will eventually be discarded. So let's continue on error instead to discard them directly. Signed-off-by: Jeroen Hofstee Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit eca4b786f3bb39ae56a4af8475c71056b4264706 Author: Marc Kleine-Budde Date: Wed Oct 9 21:00:32 2019 +0200 can: rx-offload: can_rx_offload_offload_one(): use ERR_PTR() to propagate error value in case of errors [ Upstream commit d763ab3044f0bf50bd0e6179f6b2cf1c125d1d94 ] Before this patch can_rx_offload_offload_one() returns a pointer to a skb containing the read CAN frame or a NULL pointer. However the meaning of the NULL pointer is ambiguous, it can either mean the requested mailbox is empty or there was an error. This patch fixes this situation by returning: - pointer to skb on success - NULL pointer if mailbox is empty - ERR_PTR() in case of an error All users of can_rx_offload_offload_one() have been adopted, no functional change intended. Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit a85ce0107d6bd14f78424de2fac4420d46f15d4e Author: Marc Kleine-Budde Date: Wed Oct 9 15:15:07 2019 +0200 can: rx-offload: can_rx_offload_offload_one(): increment rx_fifo_errors on queue overflow or OOM [ Upstream commit 4e9016bee3bf0c24963097edace034ff205b565c ] If the rx-offload skb_queue is full or the skb allocation fails (due to OOM), the mailbox contents is discarded. This patch adds the incrementing of the rx_fifo_errors statistics counter. Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit b83d4e4899d647bab00e1f5f544a8e4900120a7d Author: Marc Kleine-Budde Date: Wed Oct 9 16:03:18 2019 +0200 can: rx-offload: can_rx_offload_offload_one(): do not increase the skb_queue beyond skb_queue_len_max [ Upstream commit a2dc3f5e1022a5ede8af9ab89a144f1e69db8636 ] The skb_queue is a linked list, holding the skb to be processed in the next NAPI call. Without this patch, the queue length in can_rx_offload_offload_one() is limited to skb_queue_len_max + 1. As the skb_queue is a linked list, no array or other resources are accessed out-of-bound, however this behaviour is counterintuitive. This patch limits the rx-offload skb_queue length to skb_queue_len_max. Fixes: d254586c3453 ("can: rx-offload: Add support for HW fifo based irq offloading") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 77f94f0d7f523691b9b677e1f683ad7d01640d60 Author: Marc Kleine-Budde Date: Wed Oct 9 15:48:48 2019 +0200 can: rx-offload: can_rx_offload_queue_tail(): fix error handling, avoid skb mem leak [ Upstream commit 6caf8a6d6586d44fd72f4aa1021d14aa82affafb ] If the rx-offload skb_queue is full can_rx_offload_queue_tail() will not queue the skb and return with an error. This patch frees the skb in case of a full queue, which brings can_rx_offload_queue_tail() in line with the can_rx_offload_queue_sorted() function, which has been adjusted in the previous patch. The return value is adjusted to -ENOBUFS to better reflect the actual problem. The device stats handling is left to the caller. Fixes: d254586c3453 ("can: rx-offload: Add support for HW fifo based irq offloading") Reported-by: Kurt Van Dijck Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 66e21b7b9251fd9deb9b873221fe9fcab0c56e71 Author: Jeroen Hofstee Date: Tue Oct 1 21:01:20 2019 +0000 can: c_can: D_CAN: c_can_chip_config(): perform a sofware reset on open [ Upstream commit 23c5a9488f076bab336177cd1d1a366bd8ddf087 ] When the CAN interface is closed it the hardwre is put in power down mode, but does not reset the error counters / state. Reset the D_CAN on open, so the reported state and the actual state match. According to [1], the C_CAN module doesn't have the software reset. [1] http://www.bosch-semiconductors.com/media/ip_modules/pdf_2/c_can_fd8/users_manual_c_can_fd8_r210_1.pdf Signed-off-by: Jeroen Hofstee Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 7559e68ca91fbb891df80da9e01215931fa77c47 Author: Jeroen Hofstee Date: Wed Sep 25 08:58:45 2019 +0000 can: peak_usb: report bus recovery as well [ Upstream commit 128a1b87d3ceb2ba449d5aadb222fe22395adeb0 ] While the state changes are reported when the error counters increase and decrease, there is no event when the bus recovers and the error counters decrease again. So add those as well. Change the state going downward to be ERROR_PASSIVE -> ERROR_WARNING -> ERROR_ACTIVE instead of directly to ERROR_ACTIVE again. Signed-off-by: Jeroen Hofstee Cc: Stephane Grosjean Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit c5b0bbef436756eda3e2195219bbf227a50a2f71 Author: Florian Westphal Date: Sun Nov 3 20:54:28 2019 +0100 bridge: ebtables: don't crash when using dnat target in output chains [ Upstream commit b23c0742c2ce7e33ed79d10e451f70fdb5ca85d1 ] xt_in() returns NULL in the output hook, skip the pkt_type change for that case, redirection only makes sense in broute/prerouting hooks. Reported-by: Tom Yan Cc: Linus Lüssing Fixes: cf3cb246e277d ("bridge: ebtables: fix reception of frames DNAT-ed to bridge device/port") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2070b33ee9873e06711d9c69cbd75d4dcc921fbd Author: Chuhong Yuan Date: Mon Nov 4 23:50:00 2019 +0800 net: fec: add missed clk_disable_unprepare in remove [ Upstream commit c43eab3eddb4c6742ac20138659a9b701822b274 ] This driver forgets to disable and unprepare clks when remove. Add calls to clk_disable_unprepare to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 28f34294442b5525796d801f26ef3eda253f0096 Author: Tony Lindgren Date: Mon Sep 30 08:40:01 2019 -0700 clk: ti: clkctrl: Fix failed to enable error with double udelay timeout [ Upstream commit 81a41901ffd46bac6df4c95b8290ac259e0feda8 ] Commit 3d8598fb9c5a ("clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended") added handling for cases when timekeeping is suspended. But looks like we can still get occasional "failed to enable" errors on the PM runtime resume path with udelay() returning faster than expected. With ti-sysc interconnect target module driver this leads into device failure with PM runtime failing with "failed to enable" clkctrl error. Let's fix the issue with a delay of two times the desired delay as in often done for udelay() to account for the inaccuracy. Fixes: 3d8598fb9c5a ("clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended") Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren Link: https://lkml.kernel.org/r/20190930154001.46581-1-tony@atomide.com Tested-by: Keerthy Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit cb5a4049608c1969145868bed20a7819a2577c9f Author: Peter Ujfalusi Date: Wed Oct 2 11:34:36 2019 +0300 clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call [ Upstream commit 9982b0f69b49931b652d35f86f519be2ccfc7027 ] ti_clk_register() calls it already so the driver should not create duplicated alias. Signed-off-by: Peter Ujfalusi Link: https://lkml.kernel.org/r/20191002083436.10194-1-peter.ujfalusi@ti.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1677a0e54937aab8354fba987dd960faa3421d4e Author: Xiaochen Shen Date: Tue Oct 29 13:25:02 2019 +0800 x86/resctrl: Prevent NULL pointer dereference when reading mondata [ Upstream commit 26467b0f8407cbd628fa5b7bcfd156e772004155 ] When a mon group is being deleted, rdtgrp->flags is set to RDT_DELETED in rdtgroup_rmdir_mon() firstly. The structure of rdtgrp will be freed until rdtgrp->waitcount is dropped to 0 in rdtgroup_kn_unlock() later. During the window of deleting a mon group, if an application calls rdtgroup_mondata_show() to read mondata under this mon group, 'rdtgrp' returned from rdtgroup_kn_lock_live() is a NULL pointer when rdtgrp->flags is RDT_DELETED. And then 'rdtgrp' is passed in this path: rdtgroup_mondata_show() --> mon_event_read() --> mon_event_count(). Thus it results in NULL pointer dereference in mon_event_count(). Check 'rdtgrp' in rdtgroup_mondata_show(), and return -ENOENT immediately when reading mondata during the window of deleting a mon group. Fixes: d89b7379015f ("x86/intel_rdt/cqm: Add mon_data") Signed-off-by: Xiaochen Shen Signed-off-by: Borislav Petkov Reviewed-by: Fenghua Yu Reviewed-by: Tony Luck Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: pei.p.jia@intel.com Cc: Reinette Chatre Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/1572326702-27577-1-git-send-email-xiaochen.shen@intel.com Signed-off-by: Sasha Levin commit 8ef58b82d1e48378a53d2390629f23fba3aaf8c2 Author: Matthew Wilcox (Oracle) Date: Sat Nov 2 00:25:08 2019 -0400 idr: Fix idr_alloc_u32 on 32-bit systems [ Upstream commit b7e9728f3d7fc5c5c8508d99f1675212af5cfd49 ] Attempting to allocate an entry at 0xffffffff when one is already present would succeed in allocating one at 2^32, which would confuse everything. Return -ENOSPC in this case, as expected. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 88358c7610cc29234f795bb9deca4ece95fd2c1b Author: Matthew Wilcox (Oracle) Date: Sun Nov 3 06:36:43 2019 -0500 idr: Fix integer overflow in idr_for_each_entry [ Upstream commit f6341c5af4e6e15041be39976d16deca789555fa ] If there is an entry at INT_MAX then idr_for_each_entry() will increment id after handling it. This is undefined behaviour, and is caught by UBSAN. Adding 1U to id forces the operation to be carried out as an unsigned addition which (when assigned to id) will result in INT_MIN. Since there is never an entry stored at INT_MIN, idr_get_next() will return NULL, ending the loop as expected. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit a6359d5e2d98771b33f3dcd9ff26009ba8244eed Author: Eric Dumazet Date: Thu Oct 31 20:34:44 2019 -0700 powerpc/bpf: Fix tail call implementation [ Upstream commit 7de086909365cd60a5619a45af3f4152516fd75c ] We have seen many crashes on powerpc hosts while loading bpf programs. The problem here is that bpf_int_jit_compile() does a first pass to compute the program length. Then it allocates memory to store the generated program and calls bpf_jit_build_body() a second time (and a third time later) What I have observed is that the second bpf_jit_build_body() could end up using few more words than expected. If bpf_jit_binary_alloc() put the space for the program at the end of the allocated page, we then write on a non mapped memory. It appears that bpf_jit_emit_tail_call() calls bpf_jit_emit_common_epilogue() while ctx->seen might not be stable. Only after the second pass we can be sure ctx->seen wont be changed. Trying to avoid a second pass seems quite complex and probably not worth it. Fixes: ce0761419faef ("powerpc/bpf: Implement support for tail calls") Signed-off-by: Eric Dumazet Signed-off-by: Daniel Borkmann Cc: Naveen N. Rao Cc: Sandipan Das Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Link: https://lore.kernel.org/bpf/20191101033444.143741-1-edumazet@google.com Signed-off-by: Sasha Levin commit 4665759af73519d2b49cff33f9a5c4b3fcf7cf30 Author: Björn Töpel Date: Tue Oct 1 13:33:07 2019 +0200 samples/bpf: fix build by setting HAVE_ATTR_TEST to zero [ Upstream commit 04ec044b7d30800296824783df7d9728d16d7567 ] To remove that test_attr__{enabled/open} are used by perf-sys.h, we set HAVE_ATTR_TEST to zero. Signed-off-by: Björn Töpel Tested-by: KP Singh Acked-by: Song Liu Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Namhyung Kim Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Daniel Borkmann Link: http://lore.kernel.org/bpf/20191001113307.27796-3-bjorn.topel@gmail.com Signed-off-by: Sasha Levin commit 40c3b8fc47b33c55681721253270d4b0f831815d Author: Ondrej Jirman Date: Mon Oct 28 22:58:58 2019 +0100 ARM: dts: sun8i-a83t-tbs-a711: Fix WiFi resume from suspend [ Upstream commit e614f341253f8541baf0230a8dc6a016b544b1e2 ] Without enabling keep-power-in-suspend, we can't wake the device up using WOL packet, and the log is flooded with these messages on resume: sunxi-mmc 1c10000.mmc: send stop command failed sunxi-mmc 1c10000.mmc: data error, sending stop command sunxi-mmc 1c10000.mmc: send stop command failed sunxi-mmc 1c10000.mmc: data error, sending stop command So to make the WiFi really a wakeup-source, we need to keep it powered during suspend. Fixes: 0e23372080def7 ("arm: dts: sun8i: Add the TBS A711 tablet devicetree") Signed-off-by: Ondrej Jirman Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 40017db20bfabfce650fc588f144f57b8a7da092 Author: Colin Ian King Date: Wed Oct 23 12:28:09 2019 +0100 clk: sunxi-ng: a80: fix the zero'ing of bits 16 and 18 [ Upstream commit cdfc2e2086bf9c465f44e2db25561373b084a113 ] The zero'ing of bits 16 and 18 is incorrect. Currently the code is masking with the bitwise-and of BIT(16) & BIT(18) which is 0, so the updated value for val is always zero. Fix this by bitwise and-ing value with the correct mask that will zero bits 16 and 18. Addresses-Coverity: (" Suspicious &= or |= constant expression") Fixes: b8eb71dcdd08 ("clk: sunxi-ng: Add A80 CCU") Signed-off-by: Colin Ian King Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 49ade064ea4b2836e1933fb8aa4c152ebecab6ab Author: Nathan Chancellor Date: Tue Oct 22 09:50:54 2019 -0700 clk: sunxi: Fix operator precedence in sunxi_divs_clk_setup [ Upstream commit afdc74ed2d57e86c10b1d6831339770a802bab9a ] r375326 in Clang exposes an issue with operator precedence in sunxi_div_clk_setup: drivers/clk/sunxi/clk-sunxi.c:1083:30: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] data->div[i].critical ? ~~~~~~~~~~~~~~~~~~~~~ ^ drivers/clk/sunxi/clk-sunxi.c:1083:30: note: place parentheses around the '|' expression to silence this warning data->div[i].critical ? ^ ) drivers/clk/sunxi/clk-sunxi.c:1083:30: note: place parentheses around the '?:' expression to evaluate it first data->div[i].critical ? ^ ( 1 warning generated. It appears that the intention was for ?: to be evaluated first so that CLK_IS_CRITICAL could be added to clkflags if the critical boolean was set; right now, | is being evaluated first. Add parentheses around the ?: block to have it be evaluated first. Fixes: 9919d44ff297 ("clk: sunxi: Use CLK_IS_CRITICAL flag for critical clks") Link: https://github.com/ClangBuiltLinux/linux/issues/745 Signed-off-by: Nathan Chancellor Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 15fc2f3c64e75704a6bd4939023cceb69efc396c Author: Alexandre Belloni Date: Fri Sep 20 17:39:06 2019 +0200 clk: at91: avoid sleeping early [ Upstream commit 658fd65cf0b0d511de1718e48d9a28844c385ae0 ] It is not allowed to sleep to early in the boot process and this may lead to kernel issues if the bootloader didn't prepare the slow clock and main clock. This results in the following error and dump stack on the AriettaG25: bad: scheduling from the idle thread! Ensure it is possible to sleep, else simply have a delay. Reported-by: Uwe Kleine-König Signed-off-by: Alexandre Belloni Link: https://lkml.kernel.org/r/20190920153906.20887-1-alexandre.belloni@bootlin.com Fixes: 80eded6ce8bb ("clk: at91: add slow clks driver") Tested-by: Uwe Kleine-König Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 8885552a061b4d45356759452079bd31021c2c5c Author: Randy Dunlap Date: Tue Oct 22 20:57:06 2019 -0700 reset: fix reset_control_ops kerneldoc comment [ Upstream commit f430c7ed8bc22992ed528b518da465b060b9223f ] Add a missing short description to the reset_control_ops documentation. Signed-off-by: Randy Dunlap [p.zabel@pengutronix.de: rebased and updated commit message] Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit a94913c0c8cfef9228b7dd5406901ff4afc8ffb8 Author: Fabio Estevam Date: Wed Oct 9 17:43:43 2019 -0300 ARM: dts: imx6qdl-sabreauto: Fix storm of accelerometer interrupts [ Upstream commit 7e5d0bf6afcc7bd72f78e7f33570e2e0945624f0 ] Since commit a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors") a storm of accelerometer interrupts is seen: [ 114.211283] irq 260: nobody cared (try booting with the "irqpoll" option) [ 114.218108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.4 #1 [ 114.223960] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 114.230531] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 114.238301] [] (show_stack) from [] (dump_stack+0xd8/0x110) [ 114.245644] [] (dump_stack) from [] (__report_bad_irq+0x30/0xc0) [ 114.253417] [] (__report_bad_irq) from [] (note_interrupt+0x108/0x298) [ 114.261707] [] (note_interrupt) from [] (handle_irq_event_percpu+0x70/0x80) [ 114.270433] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) [ 114.279326] [] (handle_irq_event) from [] (handle_level_irq+0xc8/0x154) [ 114.287701] [] (handle_level_irq) from [] (generic_handle_irq+0x20/0x34) [ 114.296166] [] (generic_handle_irq) from [] (mxc_gpio_irq_handler+0x30/0xf0) [ 114.304975] [] (mxc_gpio_irq_handler) from [] (mx3_gpio_irq_handler+0x60/0xb0) [ 114.313955] [] (mx3_gpio_irq_handler) from [] (generic_handle_irq+0x20/0x34) [ 114.322762] [] (generic_handle_irq) from [] (__handle_domain_irq+0x64/0xe0) [ 114.331485] [] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0xa8) [ 114.339862] [] (gic_handle_irq) from [] (__irq_svc+0x70/0x98) [ 114.347361] Exception stack(0xc1301ec0 to 0xc1301f08) [ 114.352435] 1ec0: 00000001 00000006 00000000 c130c340 00000001 c130f688 9785636d c13ea2e8 [ 114.360635] 1ee0: 9784907d 0000001a eaf99d78 0000001a 00000000 c1301f10 c0182b00 c0878de4 [ 114.368830] 1f00: 20000013 ffffffff [ 114.372349] [] (__irq_svc) from [] (cpuidle_enter_state+0x168/0x5f4) [ 114.380464] [] (cpuidle_enter_state) from [] (cpuidle_enter+0x28/0x38) [ 114.388751] [] (cpuidle_enter) from [] (do_idle+0x224/0x2a8) [ 114.396168] [] (do_idle) from [] (cpu_startup_entry+0x18/0x20) [ 114.403765] [] (cpu_startup_entry) from [] (start_kernel+0x43c/0x500) [ 114.411958] handlers: [ 114.414302] [] irq_default_primary_handler threaded [] mma8452_interrupt [ 114.422974] Disabling IRQ #260 CPU0 CPU1 .... 260: 100001 0 gpio-mxc 31 Level mma8451 The MMA8451 interrupt triggers as low level, so the GPIO6_IO31 pin needs to activate its pull up, otherwise it will stay always at low level generating multiple interrupts. The current device tree does not configure the IOMUX for this pin, so it uses whathever comes configured from the bootloader. The IOMUXC_SW_PAD_CTL_PAD_EIM_BCLK register value comes as 0x8000 from the bootloader, which has PKE bit cleared, hence disabling the pull-up. Instead of relying on a previous configuration from the bootloader, configure the GPIO6_IO31 pin with pull-up enabled in order to fix this problem. Fixes: a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors") Signed-off-by: Fabio Estevam Reviewed-By: Leonard Crestez Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5b15b1bf54286ffae6f77b4de5bd243f29abbdfe Author: Andy Shevchenko Date: Thu Oct 24 16:34:41 2019 +0300 pinctrl: cherryview: Allocate IRQ chip dynamic [ Upstream commit 67d33aecd030226f0a577eb683aaa6853ecf8f91 ] Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. This patch is heavily based on the attachment to the bug by Christoph Marz. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=202543 Fixes: 6e08d6bbebeb ("pinctrl: Add Intel Cherryview/Braswell pin controller support") Depends-on: 83b9dc11312f ("pinctrl: cherryview: Associate IRQ descriptors to irqdomain") Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit a0554203bc121fa53bddabdf41e628e35eec1e7f Author: Marek Szyprowski Date: Fri Oct 25 11:02:01 2019 +0200 clk: samsung: exynos5420: Preserve PLL configuration during suspend/resume [ Upstream commit e9323b664ce29547d996195e8a6129a351c39108 ] Properly save and restore all top PLL related configuration registers during suspend/resume cycle. So far driver only handled EPLL and RPLL clocks, all other were reset to default values after suspend/resume cycle. This caused for example lower G3D (MALI Panfrost) performance after system resume, even if performance governor has been selected. Reported-by: Reported-by: Marian Mihailescu Fixes: 773424326b51 ("clk: samsung: exynos5420: add more registers to restore list") Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 80e28fa256c9ebf9174662a62c8cf0fa529c992f Author: Russell King Date: Wed Oct 23 14:46:49 2019 +0100 ASoC: kirkwood: fix device remove ordering [ Upstream commit dc39596a906d5b604f4e64597b6e904fc14625e8 ] The devm conversion of kirkwood was incorrect; on removal, devm takes effect after the "remove" function has returned. So, the effect of the conversion was to change the order during remove from: - snd_soc_unregister_component() (unpublishes interfaces) - clk_disable_unprepare() - cleanup resources After the conversion, this became: - clk_disable_unprepare() - while the device may still be active - snd_soc_unregister_component() - cleanup resources Hence, it introduces a bug, where the internal clock for the device may be shut down before the device itself has been shut down. It is known that Marvell SoCs, including Dove, locks up if registers for a peripheral that has its clocks disabled are accessed. Fixes: f98fc0f8154e ("ASoC: kirkwood: replace platform to component") Signed-off-by: Russell King Link: https://lore.kernel.org/r/E1iNGyP-0004oN-BA@rmk-PC.armlinux.org.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6a7472add344a51fd868a3d89e697dca2d3f0ce2 Author: Russell King Date: Wed Oct 23 14:46:44 2019 +0100 ASoC: kirkwood: fix external clock probe defer [ Upstream commit 4523817d51bc3b2ef38da768d004fda2c8bc41de ] When our call to get the external clock fails, we forget to clean up the enabled internal clock correctly. Enable the clock after we have obtained all our resources. Fixes: 84aac6c79bfd ("ASoC: kirkwood: fix loss of external clock at probe time") Signed-off-by: Russell King Link: https://lore.kernel.org/r/E1iNGyK-0004oF-6A@rmk-PC.armlinux.org.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2c2cf16b059c8b0958379b36e8f830207e6a0cb Author: Marek Szyprowski Date: Wed Oct 2 10:53:09 2019 +0200 clk: samsung: exynos5433: Fix error paths [ Upstream commit faac3604d05e8015567124e5ee79edc3f1568a89 ] Add checking the value returned by samsung_clk_alloc_reg_dump() and devm_kcalloc(). While fixing this, also release all gathered clocks. Fixes: 523d3de41f02 ("clk: samsung: exynos5433: Add support for runtime PM") Signed-off-by: Marek Szyprowski Reviewed-by: Krzysztof Kozlowski Acked-by: Chanwoo Choi [s.nawrocki: squashed patch from K. Kozlowski adding missing slab.h header] Reported-by: kbuild test robot Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 9a5933aa1242fc11ba3474dd4b73ee9dbdfcf995 Author: Kishon Vijay Abraham I Date: Tue Oct 22 14:06:23 2019 +0530 reset: Fix memory leak in reset_control_array_put() [ Upstream commit 532f9cd6ee994ed10403e856ca27501428048597 ] Memory allocated for 'struct reset_control_array' in of_reset_control_array_get() is never freed in reset_control_array_put() resulting in kmemleak showing the following backtrace. backtrace: [<00000000c5f17595>] __kmalloc+0x1b0/0x2b0 [<00000000bd499e13>] of_reset_control_array_get+0xa4/0x180 [<000000004cc02754>] 0xffff800008c669e4 [<0000000050a83b24>] platform_drv_probe+0x50/0xa0 [<00000000d3a0b0bc>] really_probe+0x108/0x348 [<000000005aa458ac>] driver_probe_device+0x58/0x100 [<000000008853626c>] device_driver_attach+0x6c/0x90 [<0000000085308d19>] __driver_attach+0x84/0xc8 [<00000000080d35f2>] bus_for_each_dev+0x74/0xc8 [<00000000dd7f015b>] driver_attach+0x20/0x28 [<00000000923ba6e6>] bus_add_driver+0x148/0x1f0 [<0000000061473b66>] driver_register+0x60/0x110 [<00000000c5bec167>] __platform_driver_register+0x40/0x48 [<000000007c764b4f>] 0xffff800008c6c020 [<0000000047ec2e8c>] do_one_initcall+0x5c/0x1b0 [<0000000093d4b50d>] do_init_module+0x54/0x1d0 Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit e8eb6233be9a838c637daf34ddd41d7c5154a93e Author: Xiaojun Sang Date: Mon Oct 21 10:54:32 2019 +0100 ASoC: compress: fix unsigned integer overflow check [ Upstream commit d3645b055399538415586ebaacaedebc1e5899b0 ] Parameter fragments and fragment_size are type of u32. U32_MAX is the correct check. Signed-off-by: Xiaojun Sang Signed-off-by: Srinivas Kandagatla Acked-by: Vinod Koul Link: https://lore.kernel.org/r/20191021095432.5639-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7971b7fd5623b6d8134f463ffc76aaf4f888c36e Author: Stephan Gerhold Date: Sun Oct 20 17:30:06 2019 +0200 ASoC: msm8916-wcd-analog: Fix RX1 selection in RDAC2 MUX [ Upstream commit 9110d1b0e229cebb1ffce0c04db2b22beffd513d ] According to the PM8916 Hardware Register Description, CDC_D_CDC_CONN_HPHR_DAC_CTL has only a single bit (RX_SEL) to switch between RX1 (0) and RX2 (1). It is not possible to disable it entirely to achieve the "ZERO" state. However, at the moment the "RDAC2 MUX" mixer defines three possible values ("ZERO", "RX2" and "RX1"). Setting the mixer to "ZERO" actually configures it to RX1. Setting the mixer to "RX1" has (seemingly) no effect. Remove "ZERO" and replace it with "RX1" to fix this. Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Signed-off-by: Stephan Gerhold Acked-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20191020153007.206070-1-stephan@gerhold.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit daa2c40305100077535e8a7663db6eb4c6cad365 Author: Fabien Parent Date: Thu Sep 19 21:13:15 2019 +0200 clocksource/drivers/mediatek: Fix error handling [ Upstream commit 41d49e7939de5ec532d86494185b2ca2e99c848a ] When timer_of_init fails, it cleans up after itself by undoing everything it did during the initialization function. mtk_syst_init and mtk_gpt_init both call timer_of_cleanup if timer_of_init fails. timer_of_cleanup try to release the resource taken. Since these resources have already been cleaned up by timer_of_init, we end up getting a few warnings printed: [ 0.001935] WARNING: CPU: 0 PID: 0 at __clk_put+0xe8/0x128 [ 0.002650] Modules linked in: [ 0.003058] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.67+ #1 [ 0.003852] Hardware name: MediaTek MT8183 (DT) [ 0.004446] pstate: 20400085 (nzCv daIf +PAN -UAO) [ 0.005073] pc : __clk_put+0xe8/0x128 [ 0.005555] lr : clk_put+0xc/0x14 [ 0.005988] sp : ffffff80090b3ea0 [ 0.006422] x29: ffffff80090b3ea0 x28: 0000000040e20018 [ 0.007121] x27: ffffffc07bfff780 x26: 0000000000000001 [ 0.007819] x25: ffffff80090bda80 x24: ffffff8008ec5828 [ 0.008517] x23: ffffff80090bd000 x22: ffffff8008d8b2e8 [ 0.009216] x21: 0000000000000001 x20: fffffffffffffdfb [ 0.009914] x19: ffffff8009166180 x18: 00000000002bffa8 [ 0.010612] x17: ffffffc012996980 x16: 0000000000000000 [ 0.011311] x15: ffffffbf004a6800 x14: 3536343038393334 [ 0.012009] x13: 2079726576652073 x12: 7eb9c62c5c38f100 [ 0.012707] x11: ffffff80090b3ba0 x10: ffffff80090b3ba0 [ 0.013405] x9 : 0000000000000004 x8 : 0000000000000040 [ 0.014103] x7 : ffffffc079400270 x6 : 0000000000000000 [ 0.014801] x5 : ffffffc079400248 x4 : 0000000000000000 [ 0.015499] x3 : 0000000000000000 x2 : 0000000000000000 [ 0.016197] x1 : ffffff80091661c0 x0 : fffffffffffffdfb [ 0.016896] Call trace: [ 0.017218] __clk_put+0xe8/0x128 [ 0.017654] clk_put+0xc/0x14 [ 0.018048] timer_of_cleanup+0x60/0x7c [ 0.018551] mtk_syst_init+0x8c/0x9c [ 0.019020] timer_probe+0x6c/0xe0 [ 0.019469] time_init+0x14/0x44 [ 0.019893] start_kernel+0x2d0/0x46c [ 0.020378] ---[ end trace 8c1efabea1267649 ]--- [ 0.020982] ------------[ cut here ]------------ [ 0.021586] Trying to vfree() nonexistent vm area ((____ptrval____)) [ 0.022427] WARNING: CPU: 0 PID: 0 at __vunmap+0xd0/0xd8 [ 0.023119] Modules linked in: [ 0.023524] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.67+ #1 [ 0.024498] Hardware name: MediaTek MT8183 (DT) [ 0.025091] pstate: 60400085 (nZCv daIf +PAN -UAO) [ 0.025718] pc : __vunmap+0xd0/0xd8 [ 0.026176] lr : __vunmap+0xd0/0xd8 [ 0.026632] sp : ffffff80090b3e90 [ 0.027066] x29: ffffff80090b3e90 x28: 0000000040e20018 [ 0.027764] x27: ffffffc07bfff780 x26: 0000000000000001 [ 0.028462] x25: ffffff80090bda80 x24: ffffff8008ec5828 [ 0.029160] x23: ffffff80090bd000 x22: ffffff8008d8b2e8 [ 0.029858] x21: 0000000000000000 x20: 0000000000000000 [ 0.030556] x19: ffffff800800d000 x18: 00000000002bffa8 [ 0.031254] x17: 0000000000000000 x16: 0000000000000000 [ 0.031952] x15: ffffffbf004a6800 x14: 3536343038393334 [ 0.032651] x13: 2079726576652073 x12: 7eb9c62c5c38f100 [ 0.033349] x11: ffffff80090b3b40 x10: ffffff80090b3b40 [ 0.034047] x9 : 0000000000000005 x8 : 5f5f6c6176727470 [ 0.034745] x7 : 5f5f5f5f28282061 x6 : ffffff80091c86ef [ 0.035443] x5 : ffffff800852b690 x4 : 0000000000000000 [ 0.036141] x3 : 0000000000000002 x2 : 0000000000000002 [ 0.036839] x1 : 7eb9c62c5c38f100 x0 : 7eb9c62c5c38f100 [ 0.037536] Call trace: [ 0.037859] __vunmap+0xd0/0xd8 [ 0.038271] vunmap+0x24/0x30 [ 0.038664] __iounmap+0x2c/0x34 [ 0.039088] timer_of_cleanup+0x70/0x7c [ 0.039591] mtk_syst_init+0x8c/0x9c [ 0.040060] timer_probe+0x6c/0xe0 [ 0.040507] time_init+0x14/0x44 [ 0.040932] start_kernel+0x2d0/0x46c This commit remove the calls to timer_of_cleanup when timer_of_init fails since it is unnecessary and actually cause warnings to be printed. Fixes: a0858f937960 ("mediatek: Convert the driver to timer-of") Signed-off-by: Fabien Parent Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/linux-arm-kernel/20190919191315.25190-1-fparent@baylibre.com/ Signed-off-by: Sasha Levin commit 9c65bb9518eacfbad63123037c01c25a222a3128 Author: Martin Blumenstingl Date: Sat Sep 21 17:04:11 2019 +0200 clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate [ Upstream commit 44b09b11b813b8550e6b976ea51593bc23bba8d1 ] The meson-saradc driver manually sets the input clock for sar_adc_clk_sel. Update the GXBB clock driver (which is used on GXBB, GXL and GXM) so the rate settings on sar_adc_clk_div are propagated up to sar_adc_clk_sel which will let the common clock framework select the best matching parent clock if we want that. This makes sar_adc_clk_div consistent with the axg-aoclk and g12a-aoclk drivers, which both also specify CLK_SET_RATE_PARENT. Fixes: 33d0fcdfe0e870 ("clk: gxbb: add the SAR ADC clocks and expose them") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 174651bdf802a2139065e8e31ce950e2f3fc4a94 Author: Greg Kroah-Hartman Date: Sun Dec 1 09:17:47 2019 +0100 Linux 4.19.87 commit 6938a9da7ff8f25fc6a445d4b7510776b00bb386 Author: Ezequiel Garcia Date: Fri Jun 21 18:39:49 2019 -0300 PM / devfreq: Fix kernel oops on governor module load commit 7544fd7f384591038646d3cd9efb311ab4509e24 upstream. A bit unexpectedly (but still documented), request_module may return a positive value, in case of a modprobe error. This is currently causing issues in the devfreq framework. When a request_module exits with a positive value, we currently return that via ERR_PTR. However, because the value is positive, it's not a ERR_VALUE proper, and is therefore treated as a valid struct devfreq_governor pointer, leading to a kernel oops. Fix this by returning -EINVAL if request_module returns a positive value. Fixes: b53b0128052ff ("PM / devfreq: Fix static checker warning in try_then_request_governor") Signed-off-by: Ezequiel Garcia Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 345712c95eec44bf414782b33e6d5a550fe62b3b Author: Michael Ellerman Date: Wed Nov 13 21:05:44 2019 +1100 KVM: PPC: Book3S HV: Flush link stack on guest exit to host kernel commit af2e8c68b9c5403f77096969c516f742f5bb29e0 upstream. On some systems that are vulnerable to Spectre v2, it is up to software to flush the link stack (return address stack), in order to protect against Spectre-RSB. When exiting from a guest we do some house keeping and then potentially exit to C code which is several stack frames deep in the host kernel. We will then execute a series of returns without preceeding calls, opening up the possiblity that the guest could have poisoned the link stack, and direct speculative execution of the host to a gadget of some sort. To prevent this we add a flush of the link stack on exit from a guest. Signed-off-by: Michael Ellerman [dja: straightforward backport to v4.19] Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit 0a60d4bddc0ba6a7e06d10efa59f7861837860b0 Author: Michael Ellerman Date: Wed Nov 13 21:05:41 2019 +1100 powerpc/book3s64: Fix link stack flush on context switch commit 39e72bf96f5847ba87cc5bd7a3ce0fed813dc9ad upstream. In commit ee13cb249fab ("powerpc/64s: Add support for software count cache flush"), I added support for software to flush the count cache (indirect branch cache) on context switch if firmware told us that was the required mitigation for Spectre v2. As part of that code we also added a software flush of the link stack (return address stack), which protects against Spectre-RSB between user processes. That is all correct for CPUs that activate that mitigation, which is currently Power9 Nimbus DD2.3. What I got wrong is that on older CPUs, where firmware has disabled the count cache, we also need to flush the link stack on context switch. To fix it we create a new feature bit which is not set by firmware, which tells us we need to flush the link stack. We set that when firmware tells us that either of the existing Spectre v2 mitigations are enabled. Then we adjust the patching code so that if we see that feature bit we enable the link stack flush. If we're also told to flush the count cache in software then we fall through and do that also. On the older CPUs we don't need to do do the software count cache flush, firmware has disabled it, so in that case we patch in an early return after the link stack flush. The naming of some of the functions is awkward after this patch, because they're called "count cache" but they also do link stack. But we'll fix that up in a later commit to ease backporting. This is the fix for CVE-2019-18660. Reported-by: Anthony Steinhauser Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 19d98b4d55b044b0d3902d70b3bec0ea9f652cd9 Author: Christopher M. Riedl Date: Thu May 23 21:46:48 2019 -0500 powerpc/64s: support nospectre_v2 cmdline option commit d8f0e0b073e1ec52a05f0c2a56318b47387d2f10 upstream. Add support for disabling the kernel implemented spectre v2 mitigation (count cache flush on context switch) via the nospectre_v2 and mitigations=off cmdline options. Suggested-by: Michael Ellerman Signed-off-by: Christopher M. Riedl Reviewed-by: Andrew Donnellan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190524024647.381-1-cmr@informatik.wtf Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit b7e2a040d9fcaddcd665b593f31f0f5df8bbc1f3 Author: Bernd Porr Date: Mon Nov 18 23:07:59 2019 +0000 staging: comedi: usbduxfast: usbduxfast_ai_cmdtest rounding error commit 5618332e5b955b4bff06d0b88146b971c8dd7b32 upstream. The userspace comedilib function 'get_cmd_generic_timed' fills the cmd structure with an informed guess and then calls the function 'usbduxfast_ai_cmdtest' in this driver repeatedly while 'usbduxfast_ai_cmdtest' is modifying the cmd struct until it no longer changes. However, because of rounding errors this never converged because 'steps = (cmd->convert_arg * 30) / 1000' and then back to 'cmd->convert_arg = (steps * 1000) / 30' won't be the same because of rounding errors. 'Steps' should only be converted back to the 'convert_arg' if 'steps' has actually been modified. In addition the case of steps being 0 wasn't checked which is also now done. Signed-off-by: Bernd Porr Cc: # 4.4+ Reviewed-by: Ian Abbott Link: https://lore.kernel.org/r/20191118230759.1727-1-mail@berndporr.me.uk Signed-off-by: Greg Kroah-Hartman commit 4101916e9f08a692000c0052ce2ca86305ff9b55 Author: Aleksander Morgado Date: Wed Nov 13 11:14:05 2019 +0100 USB: serial: option: add support for Foxconn T77W968 LTE modules commit f0797095423e6ea3b4be61134ee353c7f504d440 upstream. These are the Foxconn-branded variants of the Dell DW5821e modules, same USB layout as those. The device exposes AT, NMEA and DIAG ports in both USB configurations. P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Aleksander Morgado [ johan: drop id defines ] Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 62aca6645c084de24c3e594d7ecac0a8cfc08d6e Author: Aleksander Morgado Date: Thu Nov 7 11:55:08 2019 +0100 USB: serial: option: add support for DW5821e with eSIM support commit 957c31ea082e3fe5196f46d5b04018b10de47400 upstream. The device exposes AT, NMEA and DIAG ports in both USB configurations. Exactly same layout as the default DW5821e module, just a different vid/pid. P: Vendor=413c ProdID=81e0 Rev=03.18 S: Manufacturer=Dell Inc. S: Product=DW5821e-eSIM Snapdragon X20 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option P: Vendor=413c ProdID=81e0 Rev=03.18 S: Manufacturer=Dell Inc. S: Product=DW5821e-eSIM Snapdragon X20 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Aleksander Morgado Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3349ed266ae22ea9571343b996ffed7fcf500244 Author: Johan Hovold Date: Thu Nov 7 14:21:19 2019 +0100 USB: serial: mos7840: fix remote wakeup commit 92fe35fb9c70a00d8fbbf5bd6172c921dd9c7815 upstream. The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Cc: stable # 2.6.19 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit abbda35d6a6e9449fcf8c40a8a79cfc208a3a127 Author: Johan Hovold Date: Thu Nov 7 14:21:18 2019 +0100 USB: serial: mos7720: fix remote wakeup commit ea422312a462696093b5db59d294439796cba4ad upstream. The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver") Cc: stable # 2.6.19 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 84743898d60bd9ac8a3ad0cac53aa01d508175bb Author: Pavel Löbl Date: Fri Nov 1 08:01:50 2019 +0100 USB: serial: mos7840: add USB ID to support Moxa UPort 2210 commit e696d00e65e81d46e911f24b12e441037bf11b38 upstream. Add USB ID for MOXA UPort 2210. This device contains mos7820 but it passes GPIO0 check implemented by driver and it's detected as mos7840. Hence product id check is added to force mos7820 mode. Signed-off-by: Pavel Löbl Cc: stable [ johan: rename id defines and add vendor-id check ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 356440a79b6b2faf796a65b9915b0882e9f1f73b Author: Oliver Neukum Date: Wed Nov 6 13:49:01 2019 +0100 appledisplay: fix error handling in the scheduled work commit 91feb01596e5efc0cc922cc73f5583114dccf4d2 upstream. The work item can operate on 1. stale memory left over from the last transfer the actual length of the data transfered needs to be checked 2. memory already freed the error handling in appledisplay_probe() needs to cancel the work in that case Reported-and-tested-by: syzbot+495dab1f175edc9c2f13@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191106124902.7765-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 0439d6b901872933da7003413e1bae327c225717 Author: Oliver Neukum Date: Thu Nov 7 15:28:55 2019 +0100 USB: chaoskey: fix error case of a timeout commit 92aa5986f4f7b5a8bf282ca0f50967f4326559f5 upstream. In case of a timeout or if a signal aborts a read communication with the device needs to be ended lest we overwrite an active URB the next time we do IO to the device, as the URB may still be active. Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191107142856.16774-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit a18675e5d5f7addca7042d77c4763c26c5e8b1e8 Author: Greg Kroah-Hartman Date: Mon Nov 18 10:21:19 2019 +0100 usb-serial: cp201x: support Mark-10 digital force gauge commit 347bc8cb26388791c5881a3775cb14a3f765a674 upstream. Add support for the Mark-10 digital force gauge device to the cp201x driver. Based on a report and a larger patch from Joel Jennings Reported-by: Joel Jennings Cc: stable Acked-by: Johan Hovold Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.com Signed-off-by: Greg Kroah-Hartman commit 61f6a3fac394fb4f2325196d8fb4cd2b6c8a3ac7 Author: Suwan Kim Date: Mon Nov 11 23:10:35 2019 +0900 usbip: Fix uninitialized symbol 'nents' in stub_recv_cmd_submit() commit 2a9125317b247f2cf35c196f968906dcf062ae2d upstream. Smatch reported that nents is not initialized and used in stub_recv_cmd_submit(). nents is currently initialized by sgl_alloc() and used to allocate multiple URBs when host controller doesn't support scatter-gather DMA. The use of uninitialized nents means that buf_len is zero and use_sg is true. But buffer length should not be zero when an URB uses scatter-gather DMA. To prevent this situation, add the conditional that checks buf_len and use_sg. And move the use of nents right after the sgl_alloc() to avoid the use of uninitialized nents. If the error occurs, it adds SDEV_EVENT_ERROR_MALLOC and stub_priv will be released by stub event handler and connection will be shut down. Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by: kbuild test robot Reported-by: Dan Carpenter Signed-off-by: Suwan Kim Acked-by: Shuah Khan Cc: stable Link: https://lore.kernel.org/r/20191111141035.27788-1-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman commit 375b26a8648188957e2f3119c6cf078d3275bd74 Author: Hewenliang Date: Fri Oct 25 00:35:15 2019 -0400 usbip: tools: fix fd leakage in the function of read_attr_usbip_status commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream. We should close the fd before the return of read_attr_usbip_status. Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by: Hewenliang Cc: stable Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.com Signed-off-by: Greg Kroah-Hartman commit e70448b92253c6b20a95b852147a7ff4b97f1c34 Author: Oliver Neukum Date: Tue Nov 12 16:49:39 2019 +0100 USBIP: add config dependency for SGL_ALLOC commit 1ec13abac58b6f24e32f0d3081ef4e7456e62ed8 upstream. USBIP uses lib/scatterlist.h Hence it needs to set CONFIG_SGL_ALLOC Signed-off-by: Oliver Neukum Cc: stable Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20191112154939.21217-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 5d0b56f6725d93e750ec9a5a99222294fc631004 Author: Halil Pasic Date: Thu Nov 14 13:46:46 2019 +0100 virtio_ring: fix return code on DMA mapping fails [ Upstream commit f7728002c1c7bfa787b276a31c3ef458739b8e7c ] Commit 780bc7903a32 ("virtio_ring: Support DMA APIs") makes virtqueue_add() return -EIO when we fail to map our I/O buffers. This is a very realistic scenario for guests with encrypted memory, as swiotlb may run out of space, depending on it's size and the I/O load. The virtio-blk driver interprets -EIO form virtqueue_add() as an IO error, despite the fact that swiotlb full is in absence of bugs a recoverable condition. Let us change the return code to -ENOMEM, and make the block layer recover form these failures when virtio-blk encounters the condition described above. Cc: stable@vger.kernel.org Fixes: 780bc7903a32 ("virtio_ring: Support DMA APIs") Signed-off-by: Halil Pasic Tested-by: Michael Mueller Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 78260a294c04952758f9367f6d92ab129dd8fffb Author: Sean Young Date: Wed Oct 16 14:19:15 2019 -0300 media: imon: invalid dereference in imon_touch_event commit f3f5ba42c58d56d50f539854d8cc188944e96087 upstream. The touch timer is set up in intf1. If the second interface does not exist, the timer and touch input device are not setup and we get the following error, when touch events are reported via intf0. kernel BUG at kernel/time/timer.c:956! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc1+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mod_timer kernel/time/timer.c:956 [inline] RIP: 0010:__mod_timer kernel/time/timer.c:949 [inline] RIP: 0010:mod_timer+0x5a2/0xb50 kernel/time/timer.c:1100 Code: 45 10 c7 44 24 14 ff ff ff ff 48 89 44 24 08 48 8d 45 20 48 c7 44 24 18 00 00 00 00 48 89 04 24 e9 5a fc ff ff e8 ae ce 0e 00 <0f> 0b e8 a7 ce 0e 00 4c 89 74 24 20 e9 37 fe ff ff e8 98 ce 0e 00 RSP: 0018:ffff8881db209930 EFLAGS: 00010006 RAX: ffffffff86c2b200 RBX: 00000000ffffa688 RCX: ffffffff83efc583 RDX: 0000000000000100 RSI: ffffffff812f4d82 RDI: ffff8881d2356200 RBP: ffff8881d23561e8 R08: ffffffff86c2b200 R09: ffffed103a46abeb R10: ffffed103a46abea R11: ffff8881d2355f53 R12: dffffc0000000000 R13: 1ffff1103b64132d R14: ffff8881d2355f50 R15: 0000000000000006 FS: 0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f75e2799000 CR3: 00000001d3b07000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: imon_touch_event drivers/media/rc/imon.c:1348 [inline] imon_incoming_packet.isra.0+0x2546/0x2f10 drivers/media/rc/imon.c:1603 usb_rx_callback_intf0+0x151/0x1e0 drivers/media/rc/imon.c:1734 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1654 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1719 dummy_timer+0x120f/0x2fa2 drivers/usb/gadget/udc/dummy_hcd.c:1965 call_timer_fn+0x179/0x650 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5e3/0x1490 kernel/time/timer.c:1786 __do_softirq+0x221/0x912 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x12f/0x500 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 RIP: 0010:default_idle+0x28/0x2e0 arch/x86/kernel/process.c:581 Code: 90 90 41 56 41 55 65 44 8b 2d 44 3a 8f 7a 41 54 55 53 0f 1f 44 00 00 e8 36 ee d0 fb e9 07 00 00 00 0f 00 2d fa dd 4f 00 fb f4 <65> 44 8b 2d 20 3a 8f 7a 0f 1f 44 00 00 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffffff86c07da8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000007 RBX: ffffffff86c2b200 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffffff86c2ba4c RBP: fffffbfff0d85640 R08: ffffffff86c2b200 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x3b6/0x500 kernel/sched/idle.c:263 cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:355 start_kernel+0x82a/0x864 init/main.c:784 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 Modules linked in: Reported-by: syzbot+f49d12d34f2321cf4df2@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 94a94b605916a3c1f2e54cde475434281d7b7205 Author: Vito Caputo Date: Sun Oct 13 23:08:45 2019 -0300 media: cxusb: detect cxusb_ctrl_msg error in query commit ca8f245f284eeffa56f3b7a5eb6fc503159ee028 upstream. Don't use uninitialized ircode[] in cxusb_rc_query() when cxusb_ctrl_msg() fails to populate its contents. syzbot reported: dvb-usb: bulk message failed: -22 (1/-30591) ===================================================== BUG: KMSAN: uninit-value in ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] BUG: KMSAN: uninit-value in rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] BUG: KMSAN: uninit-value in rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 CPU: 1 PID: 11436 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events dvb_usb_read_remote_control Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 bsearch+0x1dd/0x250 lib/bsearch.c:41 ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline] kmsan_internal_chain_origin+0xd2/0x170 mm/kmsan/kmsan.c:314 __msan_chain_origin+0x6b/0xe0 mm/kmsan/kmsan_instr.c:184 rc_g_keycode_from_table drivers/media/rc/rc-main.c:583 [inline] rc_keydown+0x2c4/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Local variable description: ----ircode@cxusb_rc_query Variable was created at: cxusb_rc_query+0x4d/0x360 drivers/media/usb/dvb-usb/cxusb.c:543 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 Signed-off-by: Vito Caputo Reported-by: syzbot Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8b42c263ec1a348bf098e6255407486c1bf17ece Author: Oliver Neukum Date: Tue Jul 30 09:48:27 2019 +0200 media: b2c2-flexcop-usb: add sanity checking commit 1b976fc6d684e3282914cdbe7a8d68fdce19095c upstream. The driver needs an isochronous endpoint to be present. It will oops in its absence. Add checking for it. Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 56be9f1b8733395caf570a80aa97d30e1fc61c28 Author: Laurent Pinchart Date: Mon Jul 29 23:14:55 2019 -0300 media: uvcvideo: Fix error path in control parsing failure commit 8c279e9394cade640ed86ec6c6645a0e7df5e0b6 upstream. When parsing the UVC control descriptors fails, the error path tries to cleanup a media device that hasn't been initialised, potentially resulting in a crash. Fix this by initialising the media device before the error handling path can be reached. Fixes: 5a254d751e52 ("[media] uvcvideo: Register a v4l2_device") Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 61e73cf57ed81f63ccce6209f16568578953a3ef Author: Kai Shen Date: Thu Nov 7 05:08:17 2019 +0000 cpufreq: Add NULL checks to show() and store() methods of cpufreq commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream. Add NULL checks to show() and store() in cpufreq.c to avoid attempts to invoke a NULL callback. Though some interfaces of cpufreq are set as read-only, users can still get write permission using chmod which can lead to a kernel crash, as follows: chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq This bug was found in linux 4.19. Signed-off-by: Kai Shen Reported-by: Feilong Lin Reviewed-by: Feilong Lin Acked-by: Viresh Kumar [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f217cef919dacaab257df22355ae6d275c126f61 Author: Alan Stern Date: Mon Oct 7 12:09:53 2019 -0300 media: usbvision: Fix races among open, close, and disconnect commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream. Visual inspection of the usbvision driver shows that it suffers from three races between its open, close, and disconnect handlers. In particular, the driver is careful to update its usbvision->user and usbvision->remove_pending flags while holding the private mutex, but: usbvision_v4l2_close() and usbvision_radio_close() don't hold the mutex while they check the value of usbvision->remove_pending; usbvision_disconnect() doesn't hold the mutex while checking the value of usbvision->user; and also, usbvision_v4l2_open() and usbvision_radio_open() don't check whether the device has been unplugged before allowing the user to open the device files. Each of these can potentially lead to usbvision_release() being called twice and use-after-free errors. This patch fixes the races by reading the flags while the mutex is still held and checking for pending removes before allowing an open to succeed. Signed-off-by: Alan Stern CC: Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 467052f6ea5a51524992e43f02b543550495c391 Author: Alexander Popov Date: Sun Nov 3 23:17:19 2019 +0100 media: vivid: Fix wrong locking that causes race conditions on streaming stop commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream. There is the same incorrect approach to locking implemented in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(). These functions are called during streaming stopping with vivid_dev.mutex locked. And they all do the same mistake while stopping their kthreads, which need to lock this mutex as well. See the example from vivid_stop_generating_vid_cap(): /* shutdown control thread */ vivid_grab_controls(dev, false); mutex_unlock(&dev->mutex); kthread_stop(dev->kthread_vid_cap); dev->kthread_vid_cap = NULL; mutex_lock(&dev->mutex); But when this mutex is unlocked, another vb2_fop_read() can lock it instead of vivid_thread_vid_cap() and manipulate the buffer queue. That causes a use-after-free access later. To fix those issues let's: 1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(); 2. use mutex_trylock() with schedule_timeout_uninterruptible() in the loops of the vivid kthread handlers. Signed-off-by: Alexander Popov Acked-by: Linus Torvalds Tested-by: Hans Verkuil Signed-off-by: Hans Verkuil Cc: # for v3.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b73b28b1b2cbc345cbe24d98b0997ec599bf4d06 Author: Vandana BN Date: Mon Sep 9 06:43:31 2019 -0300 media: vivid: Set vid_cap_streaming and vid_out_streaming to true commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream. When vbi stream is started, followed by video streaming, the vid_cap_streaming and vid_out_streaming were not being set to true, which would cause the video stream to stop when vbi stream is stopped. This patch allows to set vid_cap_streaming and vid_out_streaming to true. According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)' checks are a left-over from the original vivid development and should never have been there. Signed-off-by: Vandana BN Cc: # for v3.18 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit af8071f50f4627fc68ad5f662f200a043dd68472 Author: Oliver Neukum Date: Thu Nov 21 11:37:10 2019 +0100 nfc: port100: handle command failure cleanly commit 5f9f0b11f0816b35867f2cf71e54d95f53f03902 upstream. If starting the transfer of a command suceeds but the transfer for the reply fails, it is not enough to initiate killing the transfer for the command may still be running. You need to wait for the killing to finish before you can reuse URB and buffer. Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3510fb7947d5a7ca662178efe4f8d3712bb85177 Author: Takashi Iwai Date: Fri Nov 22 12:28:40 2019 +0100 ALSA: usb-audio: Fix NULL dereference at parsing BADD commit 9435f2bb66874a0c4dd25e7c978957a7ca2c93b1 upstream. snd_usb_mixer_controls_badd() that parses UAC3 BADD profiles misses a NULL check for the given interfaces. When a malformed USB descriptor is passed, this may lead to an Oops, as spotted by syzkaller. Skip the iteration if the interface doesn't exist for avoiding the crash. Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support") Reported-by: syzbot+a36ab65c6653d7ccdd62@syzkaller.appspotmail.com Suggested-by: Dan Carpenter Cc: Link: https://lore.kernel.org/r/20191122112840.24797-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2819f4030f43057238992a4adcd950d7c95aff65 Author: Yang Tao Date: Wed Nov 6 22:55:35 2019 +0100 futex: Prevent robust futex exit race commit ca16d5bee59807bf04deaab0a8eccecd5061528c upstream. Robust futexes utilize the robust_list mechanism to allow the kernel to release futexes which are held when a task exits. The exit can be voluntary or caused by a signal or fault. This prevents that waiters block forever. The futex operations in user space store a pointer to the futex they are either locking or unlocking in the op_pending member of the per task robust list. After a lock operation has succeeded the futex is queued in the robust list linked list and the op_pending pointer is cleared. After an unlock operation has succeeded the futex is removed from the robust list linked list and the op_pending pointer is cleared. The robust list exit code checks for the pending operation and any futex which is queued in the linked list. It carefully checks whether the futex value is the TID of the exiting task. If so, it sets the OWNER_DIED bit and tries to wake up a potential waiter. This is race free for the lock operation but unlock has two race scenarios where waiters might not be woken up. These issues can be observed with regular robust pthread mutexes. PI aware pthread mutexes are not affected. (1) Unlocking task is killed after unlocking the futex value in user space before being able to wake a waiter. pthread_mutex_unlock() | V atomic_exchange_rel (&mutex->__data.__lock, 0) <------------------------killed lll_futex_wake () | | |(__lock = 0) |(enter kernel) | V do_exit() exit_mm() mm_release() exit_robust_list() handle_futex_death() | |(__lock = 0) |(uval = 0) | V if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr)) return 0; The sanity check which ensures that the user space futex is owned by the exiting task prevents the wakeup of waiters which in consequence block infinitely. (2) Waiting task is killed after a wakeup and before it can acquire the futex in user space. OWNER WAITER futex_wait() pthread_mutex_unlock() | | | |(__lock = 0) | | | V | futex_wake() ------------> wakeup() | |(return to userspace) |(__lock = 0) | V oldval = mutex->__data.__lock <-----------------killed atomic_compare_and_exchange_val_acq (&mutex->__data.__lock, | id | assume_other_futex_waiters, 0) | | | (enter kernel)| | V do_exit() | | V handle_futex_death() | |(__lock = 0) |(uval = 0) | V if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr)) return 0; The sanity check which ensures that the user space futex is owned by the exiting task prevents the wakeup of waiters, which seems to be correct as the exiting task does not own the futex value, but the consequence is that other waiters wont be woken up and block infinitely. In both scenarios the following conditions are true: - task->robust_list->list_op_pending != NULL - user space futex value == 0 - Regular futex (not PI) If these conditions are met then it is reasonably safe to wake up a potential waiter in order to prevent the above problems. As this might be a false positive it can cause spurious wakeups, but the waiter side has to handle other types of unrelated wakeups, e.g. signals gracefully anyway. So such a spurious wakeup will not affect the correctness of these operations. This workaround must not touch the user space futex value and cannot set the OWNER_DIED bit because the lock value is 0, i.e. uncontended. Setting OWNER_DIED in this case would result in inconsistent state and subsequently in malfunction of the owner died handling in user space. The rest of the user space state is still consistent as no other task can observe the list_op_pending entry in the exiting tasks robust list. The eventually woken up waiter will observe the uncontended lock value and take it over. [ tglx: Massaged changelog and comment. Made the return explicit and not depend on the subsequent check and added constants to hand into handle_futex_death() instead of plain numbers. Fixed a few coding style issues. ] Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core") Signed-off-by: Yang Tao Signed-off-by: Yi Wang Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1573010582-35297-1-git-send-email-wang.yi59@zte.com.cn Link: https://lkml.kernel.org/r/20191106224555.943191378@linutronix.de Signed-off-by: Greg Kroah-Hartman commit d3f8c58d701caa5fb18fcea8ff93946b747b8d8a Author: Arnd Bergmann Date: Tue Apr 17 16:31:07 2018 +0200 y2038: futex: Move compat implementation into futex.c commit 04e7712f4460585e5eed5b853fd8b82a9943958f upstream. We are going to share the compat_sys_futex() handler between 64-bit architectures and 32-bit architectures that need to deal with both 32-bit and 64-bit time_t, and this is easier if both entry points are in the same file. In fact, most other system call handlers do the same thing these days, so let's follow the trend here and merge all of futex_compat.c into futex.c. In the process, a few minor changes have to be done to make sure everything still makes sense: handle_futex_death() and futex_cmpxchg_enabled() become local symbol, and the compat version of the fetch_robust_entry() function gets renamed to compat_fetch_robust_entry() to avoid a symbol clash. This is intended as a purely cosmetic patch, no behavior should change. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 344966da99c962bea479298e4d3744e0c6a513f1 Author: Navid Emamdoost Date: Mon Sep 23 15:09:58 2019 -0500 nbd: prevent memory leak commit 03bf73c315edca28f47451913177e14cd040a216 upstream. In nbd_add_socket when krealloc succeeds, if nsock's allocation fail the reallocted memory is leak. The correct behaviour should be assigning the reallocted memory to config->socks right after success. Reviewed-by: Josef Bacik Signed-off-by: Navid Emamdoost Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ed7a3dde0aa224051c6455fce3755bf48c062178 Author: Waiman Long Date: Fri Nov 15 11:14:45 2019 -0500 x86/speculation: Fix redundant MDS mitigation message commit cd5a2aa89e847bdda7b62029d94e95488d73f6b2 upstream. Since MDS and TAA mitigations are inter-related for processors that are affected by both vulnerabilities, the followiing confusing messages can be printed in the kernel log: MDS: Vulnerable MDS: Mitigation: Clear CPU buffers To avoid the first incorrect message, defer the printing of MDS mitigation after the TAA mitigation selection has been done. However, that has the side effect of printing TAA mitigation first before MDS mitigation. [ bp: Check box is affected/mitigations are disabled first before printing and massage. ] Suggested-by: Pawan Gupta Signed-off-by: Waiman Long Signed-off-by: Borislav Petkov Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Mark Gross Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Tony Luck Cc: Tyler Hicks Cc: x86-ml Link: https://lkml.kernel.org/r/20191115161445.30809-3-longman@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0af5ae268e24e265494ea4e91119ddd241744195 Author: Waiman Long Date: Fri Nov 15 11:14:44 2019 -0500 x86/speculation: Fix incorrect MDS/TAA mitigation status commit 64870ed1b12e235cfca3f6c6da75b542c973ff78 upstream. For MDS vulnerable processors with TSX support, enabling either MDS or TAA mitigations will enable the use of VERW to flush internal processor buffers at the right code path. IOW, they are either both mitigated or both not. However, if the command line options are inconsistent, the vulnerabilites sysfs files may not report the mitigation status correctly. For example, with only the "mds=off" option: vulnerabilities/mds:Vulnerable; SMT vulnerable vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable The mds vulnerabilities file has wrong status in this case. Similarly, the taa vulnerability file will be wrong with mds mitigation on, but taa off. Change taa_select_mitigation() to sync up the two mitigation status and have them turned off if both "mds=off" and "tsx_async_abort=off" are present. Update documentation to emphasize the fact that both "mds=off" and "tsx_async_abort=off" have to be specified together for processors that are affected by both TAA and MDS to be effective. [ bp: Massage and add kernel-parameters.txt change too. ] Fixes: 1b42f017415b ("x86/speculation/taa: Add mitigation for TSX Async Abort") Signed-off-by: Waiman Long Signed-off-by: Borislav Petkov Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Kosina Cc: Jonathan Corbet Cc: Josh Poimboeuf Cc: linux-doc@vger.kernel.org Cc: Mark Gross Cc: Cc: Pawan Gupta Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Tony Luck Cc: Tyler Hicks Cc: x86-ml Link: https://lkml.kernel.org/r/20191115161445.30809-2-longman@redhat.com Signed-off-by: Greg Kroah-Hartman commit ed7312096a1f253dc8cf3cca1c838bbdeefbf067 Author: Alexander Kapshuk Date: Tue Sep 24 07:46:59 2019 +0300 x86/insn: Fix awk regexp warnings commit 700c1018b86d0d4b3f1f2d459708c0cdf42b521d upstream. gawk 5.0.1 generates the following regexp warnings: GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator Ealier versions of gawk are not known to generate these warnings. The gawk manual referenced below does not list characters ':' and '&' as needing escaping, so 'unescape' them. See https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html for more info. Running diff on the output generated by the script before and after applying the patch reported no differences. [ bp: Massage commit message. ] [ Caught the respective tools header discrepancy. ] Reported-by: kbuild test robot Signed-off-by: Alexander Kapshuk Signed-off-by: Borislav Petkov Acked-by: Masami Hiramatsu Cc: "H. Peter Anvin" Cc: "Peter Zijlstra (Intel)" Cc: Arnaldo Carvalho de Melo Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190924044659.3785-1-alexander.kapshuk@gmail.com Signed-off-by: Greg Kroah-Hartman commit 99b933bbc7b05cebf99b032a80efae5ecc41888c Author: Alexey Brodkin Date: Tue Oct 22 17:04:11 2019 +0300 ARC: perf: Accommodate big-endian CPU commit 5effc09c4907901f0e71e68e5f2e14211d9a203f upstream. 8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ------------------------->8---------------------- ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ------------------------->8---------------------- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP____" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "____" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "____" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit e02f1448282b9e83250c25d47fc09e618fdca524 Author: Chester Lin Date: Fri Aug 30 14:30:07 2019 +0100 ARM: 8904/1: skip nomap memblocks while finding the lowmem/highmem boundary commit 1d31999cf04c21709f72ceb17e65b54a401330da upstream. adjust_lowmem_bounds() checks every memblocks in order to find the boundary between lowmem and highmem. However some memblocks could be marked as NOMAP so they are not used by kernel, which should be skipped while calculating the boundary. Signed-off-by: Chester Lin Reviewed-by: Mike Rapoport Signed-off-by: Russell King Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 046f0fcf7397fa0b6c7925d1f4fd3fe69af2278a Author: Gang He Date: Fri Nov 2 15:48:03 2018 -0700 ocfs2: remove ocfs2_is_o2cb_active() commit a634644751c46238df58bbfe992e30c1668388db upstream. Remove ocfs2_is_o2cb_active(). We have similar functions to identify which cluster stack is being used via osb->osb_cluster_stack. Secondly, the current implementation of ocfs2_is_o2cb_active() is not totally safe. Based on the design of stackglue, we need to get ocfs2_stack_lock before using ocfs2_stack related data structures, and that active_stack pointer can be NULL in the case of mount failure. Link: http://lkml.kernel.org/r/1495441079-11708-1-git-send-email-ghe@suse.com Signed-off-by: Gang He Reviewed-by: Joseph Qi Reviewed-by: Eric Ren Acked-by: Changwei Ge Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 36bef080b55f9264d587085d9b00d658d4eafa22 Author: Max Uvarov Date: Tue May 28 13:00:50 2019 +0300 net: phy: dp83867: increase SGMII autoneg timer duration commit 1a97a477e666cbdededab93bd3754e508f0c09d7 upstream. After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01). That is not enough to finalize autonegatiation on some devices. Increase this timer duration to maximum supported 16ms. Signed-off-by: Max Uvarov Cc: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller [ adapted for kernels without phy_modify_mmd ] Signed-off-by: Adrian Bunk Signed-off-by: Greg Kroah-Hartman commit 87997a7800a1c0d206ff84cbb3b6fd2fc0eb561e Author: Max Uvarov Date: Tue May 28 13:00:49 2019 +0300 net: phy: dp83867: fix speed 10 in sgmii mode commit 333061b924539c0de081339643f45514f5f1c1e6 upstream. For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit of DP83867_10M_SGMII_CFG register has to be cleared by software. That does not affect speeds 100 and 1000 so can be done on init. Signed-off-by: Max Uvarov Cc: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller [ adapted for kernels without phy_modify_mmd ] Signed-off-by: Adrian Bunk Signed-off-by: Greg Kroah-Hartman commit 5779cbc98369aec83eef8fd2fbe2ff04b27196d1 Author: David Hildenbrand Date: Thu Nov 21 17:53:56 2019 -0800 mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span() commit 7ce700bf11b5e2cb84e4352bbdf2123a7a239c84 upstream. Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We should never try to touch the memmap of offline sections where we could have uninitialized memmaps and could trigger BUGs when calling page_to_nid() on poisoned pages. There is no reliable way to distinguish an uninitialized memmap from an initialized memmap that belongs to ZONE_DEVICE, as we don't have anything like SECTION_IS_ONLINE we can use similar to pfn_to_online_section() for !ZONE_DEVICE memory. E.g., set_zone_contiguous() similarly relies on pfn_to_online_section() and will therefore never set a ZONE_DEVICE zone consecutive. Stopping to shrink the ZONE_DEVICE therefore results in no observable changes, besides /proc/zoneinfo indicating different boundaries - something we can totally live with. Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug"), the memmap was initialized with 0 and the node with the right value. So the zone might be wrong but not garbage. After that commit, both the zone and the node will be garbage when touching uninitialized memmaps. Toshiki reported a BUG (race between delayed initialization of ZONE_DEVICE memmaps without holding the memory hotplug lock and concurrent zone shrinking). https://lkml.org/lkml/2019/11/14/1040 "Iteration of create and destroy namespace causes the panic as below: kernel BUG at mm/page_alloc.c:535! CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0 Call Trace: memmap_init_zone_device+0x165/0x17c memremap_pages+0x4c1/0x540 devm_memremap_pages+0x1d/0x60 pmem_attach_disk+0x16b/0x600 [nd_pmem] nvdimm_bus_probe+0x69/0x1c0 really_probe+0x1c2/0x3e0 driver_probe_device+0xb4/0x100 device_driver_attach+0x4f/0x60 bind_store+0xc9/0x110 kernfs_fop_write+0x116/0x190 vfs_write+0xa5/0x1a0 ksys_write+0x59/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 While creating a namespace and initializing memmap, if you destroy the namespace and shrink the zone, it will initialize the memmap outside the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page) in set_pfnblock_flags_mask()." This BUG is also mitigated by this commit, where we for now stop to shrink the ZONE_DEVICE zone until we can do it in a safe and clean way. Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319] Signed-off-by: David Hildenbrand Reported-by: Aneesh Kumar K.V Reported-by: Toshiki Fukasawa Cc: Oscar Salvador Cc: David Hildenbrand Cc: Michal Hocko Cc: Pavel Tatashin Cc: Dan Williams Cc: Alexander Duyck Cc: Alexander Potapenko Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Damian Tometzki Cc: Dave Hansen Cc: Fenghua Yu Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Halil Pasic Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jun Yao Cc: Logan Gunthorpe Cc: Mark Rutland Cc: Masahiro Yamada Cc: "Matthew Wilcox (Oracle)" Cc: Mel Gorman Cc: Michael Ellerman Cc: Mike Rapoport Cc: Pankaj Gupta Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: Qian Cai Cc: Rich Felker Cc: Robin Murphy Cc: Steve Capper Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Tony Luck Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: Wei Yang Cc: Wei Yang Cc: Will Deacon Cc: Yoshinori Sato Cc: Yu Zhao Cc: [4.13+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman commit a268d985f08935f565937cf36f0c1a1e0ca04ad3 Author: John Pittman Date: Mon Nov 11 16:43:20 2019 -0800 md/raid10: prevent access of uninitialized resync_pages offset commit 45422b704db392a6d79d07ee3e3670b11048bd53 upstream. Due to unneeded multiplication in the out_free_pages portion of r10buf_pool_alloc(), when using a 3-copy raid10 layout, it is possible to access a resync_pages offset that has not been initialized. This access translates into a crash of the system within resync_free_pages() while passing a bad pointer to put_page(). Remove the multiplication, preventing access to the uninitialized area. Fixes: f0250618361db ("md: raid10: don't use bio's vec table to manage resync pages") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: John Pittman Suggested-by: David Jeffery Reviewed-by: Laurence Oberman Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit f8dc0350d32bc4c7c3b27698bbde319ca1e632a3 Author: Denis Efremov Date: Fri Sep 27 01:56:04 2019 +0300 ath9k_hw: fix uninitialized variable data commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream. Currently, data variable in ar9003_hw_thermo_cal_apply() could be uninitialized if ar9300_otp_read_word() will fail to read the value. Initialize data variable with 0 to prevent an undefined behavior. This will be enough to handle error case when ar9300_otp_read_word() fails. Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462") Cc: Rajkumar Manoharan Cc: John W. Linville Cc: Kalle Valo Cc: "David S. Miller" Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit f0cfe98332d650f31b462207d63c496b4cedaee2 Author: Hui Peng Date: Sat Oct 19 14:42:23 2019 +0300 ath10k: Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe commit bfd6e6e6c5d2ee43a3d9902b36e01fc7527ebb27 upstream. The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath10k_usb` object according to endpoint descriptors read from the device side, as shown below in `ath10k_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and `ath10k_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref. Signed-off-by: Hui Peng Reported-by: Hui Peng Reported-by: Mathias Payer Reviewed-by: Greg Kroah-Hartman [groeck: Add driver tag to subject, fix build warning] Signed-off-by: Guenter Roeck Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4ae7392ab6f457b8d695df271d9344f54a326077 Author: Sean Christopherson Date: Mon Nov 11 14:12:27 2019 -0800 KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved commit a78986aae9b2988f8493f9f65a587ee433e83bc3 upstream. Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages. This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup(). Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned. [*] http://lkml.kernel.org/r/20190919115547.GA17963@angband.pl Reported-by: Adam Borowski Analyzed-by: David Hildenbrand Acked-by: Dan Williams Cc: stable@vger.kernel.org Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini [sean: backport to 4.x; resolve conflict in mmu.c] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 03bf4876a5935ab48e4dbf56ebdffd25e44378a5 Author: Tomas Bortoli Date: Fri Nov 1 21:42:44 2019 +0100 Bluetooth: Fix invalid-free in bcsp_close() commit cf94da6f502d8caecabd56b194541c873c8a7a3c upstream. Syzbot reported an invalid-free that I introduced fixing a memleak. bcsp_recv() also frees bcsp->rx_skb but never nullifies its value. Nullify bcsp->rx_skb every time it is freed. Signed-off-by: Tomas Bortoli Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann Cc: Alexander Potapenko Signed-off-by: Greg Kroah-Hartman commit 006360ec33d9387610f641c633aef0e523753b8d Author: Vinayak Menon Date: Fri Nov 15 17:35:00 2019 -0800 mm/page_io.c: do not free shared swap slots [ Upstream commit 5df373e95689b9519b8557da7c5bd0db0856d776 ] The following race is observed due to which a processes faulting on a swap entry, finds the page neither in swapcache nor swap. This causes zram to give a zero filled page that gets mapped to the process, resulting in a user space crash later. Consider parent and child processes Pa and Pb sharing the same swap slot with swap_count 2. Swap is on zram with SWP_SYNCHRONOUS_IO set. Virtual address 'VA' of Pa and Pb points to the shared swap entry. Pa Pb fault on VA fault on VA do_swap_page do_swap_page lookup_swap_cache fails lookup_swap_cache fails Pb scheduled out swapin_readahead (deletes zram entry) swap_free (makes swap_count 1) Pb scheduled in swap_readpage (swap_count == 1) Takes SWP_SYNCHRONOUS_IO path zram enrty absent zram gives a zero filled page Fix this by making sure that swap slot is freed only when swap count drops down to one. Link: http://lkml.kernel.org/r/1571743294-14285-1-git-send-email-vinmenon@codeaurora.org Fixes: aa8d22a11da9 ("mm: swap: SWP_SYNCHRONOUS_IO: skip swapcache only if swapped page has no other reference") Signed-off-by: Vinayak Menon Suggested-by: Minchan Kim Acked-by: Minchan Kim Cc: Michal Hocko Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 16a300fb1dbb119023275798bbd749c3a3a54d18 Author: Johannes Berg Date: Fri Feb 1 11:09:54 2019 +0100 cfg80211: call disconnect_wk when AP stops [ Upstream commit e005bd7ddea06784c1eb91ac5bb6b171a94f3b05 ] Since we now prevent regulatory restore during STA disconnect if concurrent AP interfaces are active, we need to reschedule this check when the AP state changes. This fixes never doing a restore when an AP is the last interface to stop. Or to put it another way: we need to re-check after anything we check here changes. Cc: stable@vger.kernel.org Fixes: 113f3aaa81bd ("cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces") Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2b3541ffdd05198b329d21920a0f606009a1058b Author: David Ahern Date: Wed Dec 12 15:27:38 2018 -0800 ipv6: Fix handling of LLA with VRF and sockets bound to VRF [ Upstream commit c2027d1e17582903e368abf5d4838b22a98f2b7b ] A recent commit allows sockets bound to a VRF to receive ipv6 link local packets. However, it only works for UDP and worse TCP connection attempts to the LLA with the only listener bound to the VRF just hang where as before the client gets a reset and connection refused. Fix by adjusting ir_iif for LL addresses and packets received through a device enslaved to a VRF. Fixes: 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF") Reported-by: Donald Sharp Cc: Mike Manning Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 091ed093c9c8a1c4c0243924131c8344383aeec3 Author: zhong jiang Date: Mon Apr 8 12:07:17 2019 +0800 mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock [ Upstream commit d2ab99403ee00d8014e651728a4702ea1ae5e52c ] When adding the memory by probing memory block in sysfs interface, there is an obvious issue that we will unlock the device_hotplug_lock when fails to takes it. That issue was introduced in Commit 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") We should drop out in time when fails to take the device_hotplug_lock. Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") Reported-by: Yang yingliang Signed-off-by: zhong jiang Reviewed-by: Oscar Salvador Reviewed-by: David Hildenbrand Acked-by: Michal Hocko Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 896f7398152baf02aec8696cd8141d76946b0eb2 Author: Masahiro Yamada Date: Thu Dec 6 12:55:25 2018 +0900 i2c: uniphier-f: fix timeout error after reading 8 bytes [ Upstream commit c2a653deaa81f5a750c0dfcbaf9f8e5195cbe4a5 ] I was totally screwed up in commit eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared"). Since that commit, if the number of read bytes is multiple of the FIFO size (8, 16, 24... bytes), the STOP condition could be issued twice, depending on the timing. If this happens, the controller will go wrong, resulting in the timeout error. It was more than 3 years ago when I wrote this driver, so my memory about this hardware was vague. Please let me correct the description in the commit log of eaba68785c2d. Clearing the IRQ status on exiting the IRQ handler is absolutely fine. This controller makes a pause while any IRQ status is asserted. If the IRQ status is cleared first, the hardware may start the next transaction before the IRQ handler finishes what it supposed to do. This partially reverts the bad commit with clear comments so that I will never repeat this mistake. I also investigated what is happening at the last moment of the read mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier (by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB. I consulted a hardware engineer, and I got the following information: UNIPHIER_FI2C_INT_RF asserted at the falling edge of SCL at the 8th bit. UNIPHIER_FI2C_INT_RB asserted at the rising edge of SCL at the 9th (ACK) bit. In order to avoid calling uniphier_fi2c_stop() twice, check the latter interrupt. I also commented this because it is obscure hardware internal. Fixes: eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1efa17ab9cb830119b5f456b5f0a37aa3f44adbe Author: Vignesh R Date: Tue Jan 15 12:28:32 2019 +0530 spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch [ Upstream commit baf8b9f8d260c55a86405f70a384c29cda888476 ] Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") broke SPI transfers where bits_per_word != 8. This is because of mimsatch between McSPI FIFO level event trigger size (SPI word length) and DMA request size(word length * maxburst). This leads to data corruption, lockup and errors like: spi1.0: EOW timed out Fix this by setting DMA maxburst size to 1 so that McSPI FIFO level event trigger size matches DMA request size. Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") Cc: stable@vger.kernel.org Reported-by: David Lechner Tested-by: David Lechner Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b0f1b2dde066c8dd78c9df9e33c82eecf572dcc Author: Igor Konopko Date: Fri Nov 23 16:58:10 2018 +0100 nvme-pci: fix surprise removal [ Upstream commit 751a0cc0cd3a0d51e6aaf6fd3b8bd31f4ecfaf3e ] When a PCIe NVMe device is not present, nvme_dev_remove_admin() calls blk_cleanup_queue() on the admin queue, which frees the hctx for that queue. Moments later, on the same path nvme_kill_queues() calls blk_mq_unquiesce_queue() on admin queue and tries to access hctx of it, which leads to following OOPS: Oops: 0000 [#1] SMP PTI RIP: 0010:sbitmap_any_bit_set+0xb/0x40 Call Trace: blk_mq_run_hw_queue+0xd5/0x150 blk_mq_run_hw_queues+0x3a/0x50 nvme_kill_queues+0x26/0x50 nvme_remove_namespaces+0xb2/0xc0 nvme_remove+0x60/0x140 pci_device_remove+0x3b/0xb0 Fixes: cb4bfda62afa2 ("nvme-pci: fix hot removal during error handling") Signed-off-by: Igor Konopko Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 597a37d01b69671088d70fffffcfd38f10a1cda7 Author: Kishon Vijay Abraham I Date: Wed Oct 17 13:10:54 2018 +0530 PCI: keystone: Use quirk to limit MRRS for K2G [ Upstream commit 148e340c0696369fadbbddc8f4bef801ed247d71 ] PCI controller in K2G also has a limitation that memory read request size (MRRS) must not exceed 256 bytes. Use the quirk to limit MRRS (added for K2HK, K2L and K2E) for K2G as well. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit c0418c4a61aa52bf46c234ccc6a067ae0ddbd3ce Author: Nathan Chancellor Date: Wed Nov 7 01:56:40 2018 -0700 pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD [ Upstream commit cd8a145a066a1a3beb0ae615c7cb2ee4217418d7 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion from enumeration type 'enum zynq_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18}, ~ ^~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion from enumeration type 'enum zynq_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true), ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from macro 'PCONFDUMP' .param = a, .display = b, .format = c, .has_arg = d \ ^ 2 warnings generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Signed-off-by: Nathan Chancellor Acked-by: Michal Simek Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0858006cda38ef89c0263d081077ef7f21b53ca1 Author: Nathan Chancellor Date: Thu Nov 1 08:00:08 2018 -0700 pinctrl: lpc18xx: Use define directive for PIN_CONFIG_GPIO_PIN_INT [ Upstream commit f24bfb39975c241374cadebbd037c17960cf1412 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion from enumeration type 'enum lpc18xx_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0}, ~ ^~~~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinctrl-lpc18xx.c:648:12: warning: implicit conversion from enumeration type 'enum lpc18xx_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] PCONFDUMP(PIN_CONFIG_GPIO_PIN_INT, "gpio pin int", NULL, true), ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from macro 'PCONFDUMP' .param = a, .display = b, .format = c, .has_arg = d \ ^ 2 warnings generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Link: https://github.com/ClangBuiltLinux/linux/issues/140 Signed-off-by: Nathan Chancellor Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5efa36e7f04abffe4f6553e6a5b3a6593bec10e7 Author: Nathan Chancellor Date: Wed Oct 31 17:46:54 2018 -0700 pinctrl: bcm2835: Use define directive for BCM2835_PINCONF_PARAM_PULL [ Upstream commit b40ac08ff886302a6aa457fd72e94a969f50e245 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit conversion from enumeration type 'enum bcm2835_pinconf_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] configs[0] = pinconf_to_config_packed(BCM2835_PINCONF_PARAM_PULL, pull); ~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Signed-off-by: Nathan Chancellor Acked-by: Stefan Wahren Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bad4da12b7977e562e48ceee914d290e66768396 Author: Brian Masney Date: Wed Oct 31 20:11:47 2018 -0400 pinctrl: qcom: spmi-gpio: fix gpio-hog related boot issues [ Upstream commit 149a96047237574b756d872007c006acd0cc6687 ] When attempting to setup up a gpio hog, device probing would repeatedly fail with -EPROBE_DEFERED errors. It was caused by a circular dependency between the gpio and pinctrl frameworks. If the gpio-ranges property is present in device tree, then the gpio framework will handle the gpio pin registration and eliminate the circular dependency. See Christian Lamparter's commit a86caa9ba5d7 ("pinctrl: msm: fix gpio-hog related boot issues") for a detailed commit message that explains the issue in much more detail. The code comment in this commit came from Christian's commit. Signed-off-by: Brian Masney Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c24fe7807320ca9e881ee30e1a54b71b2c05ee1e Author: Sriram R Date: Fri Oct 19 14:42:59 2018 +0530 cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces [ Upstream commit 113f3aaa81bd56aba02659786ed65cbd9cb9a6fc ] Currently when an AP and STA interfaces are active in the same or different radios, regulatory settings are restored whenever the STA disconnects. This restores all channel information including dfs states in all radios. For example, if an AP interface is active in one radio and STA in another, when radar is detected on the AP interface, the dfs state of the channel will be changed to UNAVAILABLE. But when the STA interface disconnects, this issues a regulatory disconnect hint which restores all regulatory settings in all the radios attached and thereby losing the stored dfs state on the other radio where the channel was marked as unavailable earlier. Hence prevent such regulatory restore whenever another active beaconing interface is present in the same or other radios. Signed-off-by: Sriram R Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ee7d2473812be2fbadc419764eb580478f9f31ff Author: Quentin Monnet Date: Thu Nov 8 11:52:27 2018 +0000 tools: bpftool: pass an argument to silence open_obj_pinned() [ Upstream commit f120919f9905a2cad9dea792a28a11fb623f72c1 ] Function open_obj_pinned() prints error messages when it fails to open a link in the BPF virtual file system. However, in some occasions it is not desirable to print an error, for example when we parse all links under the bpffs root, and the error is due to some paths actually being symbolic links. Example output: # ls -l /sys/fs/bpf/ lrwxrwxrwx 1 root root 0 Oct 18 19:00 ip -> /sys/fs/bpf/tc/ drwx------ 3 root root 0 Oct 18 19:00 tc lrwxrwxrwx 1 root root 0 Oct 18 19:00 xdp -> /sys/fs/bpf/tc/ # bpftool --bpffs prog show Error: bpf obj get (/sys/fs/bpf): Permission denied Error: bpf obj get (/sys/fs/bpf): Permission denied # strace -e bpf bpftool --bpffs prog show bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/ip", bpf_fd=0}, 72) = -1 EACCES (Permission denied) Error: bpf obj get (/sys/fs/bpf): Permission denied bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/xdp", bpf_fd=0}, 72) = -1 EACCES (Permission denied) Error: bpf obj get (/sys/fs/bpf): Permission denied ... To fix it, pass a bool as a second argument to the function, and prevent it from printing an error when the argument is set to true. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 367e64ce11fc59fc51b41a8f0f2ba4b5daa23a17 Author: Frank Rowand Date: Thu Oct 4 20:40:21 2018 -0700 of: unittest: initialize args before calling of_*parse_*() [ Upstream commit eeb07c573ec307c53fe2f6ac6d8d11c261f64006 ] Callers of of_irq_parse_one() blindly use the pointer args.np without checking whether of_irq_parse_one() had an error and thus did not set the value of args.np. Initialize args to zero so that using the format "%pOF" to show the value of args.np will show "(null)" when of_irq_parse_one() has an error. This prevents the dereference of a random value. Make the same fix for callers of of_parse_phandle_with_args() and of_parse_phandle_with_args_map(). Reported-by: Guenter Roeck Tested-by: Alan Tull Signed-off-by: Frank Rowand Signed-off-by: Sasha Levin commit e4547e02854776bd8270a7493a5e9f40e77c7ce4 Author: Frank Rowand Date: Fri Oct 12 19:38:26 2018 -0700 of: unittest: allow base devicetree to have symbol metadata [ Upstream commit 5babefb7f7ab1f23861336d511cc666fa45ede82 ] The overlay metadata nodes in the FDT created from testcases.dts are not handled properly. The __fixups__ and __local_fixups__ node were added to the live devicetree, but should not be. Only the first property in the /__symbols__ node was added to the live devicetree if the live devicetree already contained a /__symbols node. All of the node's properties must be added. Tested-by: Alan Tull Signed-off-by: Frank Rowand Signed-off-by: Sasha Levin commit 1303c938c95377895deafce6067dd433c814f94f Author: YueHaibing Date: Thu Nov 8 02:08:43 2018 +0000 net: bcmgenet: return correct value 'ret' from bcmgenet_power_down [ Upstream commit 0db55093b56618088b9a1d445eb6e43b311bea33 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/broadcom/genet/bcmgenet.c: In function 'bcmgenet_power_down': drivers/net/ethernet/broadcom/genet/bcmgenet.c:1136:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] bcmgenet_power_down should return 'ret' instead of 0. Fixes: ca8cf341903f ("net: bcmgenet: propagate errors from bcmgenet_power_down") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1d6a0dd6aa535e3c5d9d840e3d0cff55cefabaa8 Author: Colin Ian King Date: Mon Nov 5 09:43:52 2018 -0800 ACPICA: Use %d for signed int print formatting instead of %u [ Upstream commit f8ddf49b420112e28bdd23d7ad52d7991a0ccbe3 ] Fix warnings found using static analysis with cppcheck, use %d printf format specifier for signed ints rather than %u Signed-off-by: Colin Ian King Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d15b8b691725a432130358d198e909ccb48b403b Author: Dmitry Osipenko Date: Sun Oct 21 21:30:50 2018 +0300 clk: tegra20: Turn EMC clock gate into divider [ Upstream commit 514fddba845ed3a1b17e01e99cb3a2a52256a88a ] Kernel should never gate the EMC clock as it causes immediate lockup, so removing clk-gate functionality doesn't affect anything. Turning EMC clk gate into divider allows to implement glitch-less EMC scaling, avoiding reparenting to a backup clock. Signed-off-by: Dmitry Osipenko Acked-by: Peter De Schrijver Acked-by: Stephen Boyd Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 91c5f99d131ed3b231aaef7d4ed6799085b095a3 Author: Mike Manning Date: Wed Nov 7 15:36:07 2018 +0000 vrf: mark skb for multicast or link-local as enslaved to VRF [ Upstream commit 6f12fa775530195a501fb090d092c637f32d0cc5 ] The skb for packets that are multicast or to a link-local address are not marked as being enslaved to a VRF, if they are received on a socket bound to the VRF. This is needed for ND and it is preferable for the kernel not to have to deal with the additional use-cases if ll or mcast packets are handled as enslaved. However, this does not allow service instances listening on unbound and bound to VRF sockets to distinguish the VRF used, if packets are sent as multicast or to a link-local address. The fix is for the VRF driver to also mark these skb as being enslaved to the VRF. Signed-off-by: Mike Manning Reviewed-by: David Ahern Tested-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c2a3997ae5b7d14431eda830bfd0d4d727a7ec9 Author: Tycho Andersen Date: Fri Nov 2 14:18:22 2018 -0600 dlm: don't leak kernel pointer to userspace [ Upstream commit 9de30f3f7f4d31037cfbb7c787e1089c1944b3a7 ] In copy_result_to_user(), we first create a struct dlm_lock_result, which contains a struct dlm_lksb, the last member of which is a pointer to the lvb. Unfortunately, we copy the entire struct dlm_lksb to the result struct, which is then copied to userspace at the end of the function, leaking the contents of sb_lvbptr, which is a valid kernel pointer in some cases (indeed, later in the same function the data it points to is copied to userspace). It is an error to leak kernel pointers to userspace, as it undermines KASLR protections (see e.g. 65eea8edc31 ("floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl") for another example of this). Signed-off-by: Tycho Andersen Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit afb4717ab81b5aca60cd9836788cb6e2e6a1bcba Author: Tycho Andersen Date: Fri Nov 2 14:18:20 2018 -0600 dlm: fix invalid free [ Upstream commit d968b4e240cfe39d39d80483bac8bca8716fd93c ] dlm_config_nodes() does not allocate nodes on failure, so we should not free() nodes when it fails. Signed-off-by: Tycho Andersen Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 30fc13ae88b2b6a40c130f243284ee030591a658 Author: Badhri Jagan Sridharan Date: Mon Oct 1 12:45:01 2018 -0700 usb: typec: tcpm: charge current handling for sink during hard reset [ Upstream commit 157c0f2f641a9938382b092c64548ebdabfe25e0 ] During the initial connect to a non-pd port, sink would hard reset twice before deeming that the port partner is non-pd. TCPM sets the the charge path to false during the hard reset. This causes unnecessary connects/disconnects of charge path and makes port take longer to charge from the non-pd ports. Avoid this by not setting the charge path to false unless the partner has already identified to be pd capable. When partner is a pd port, set the charge path to false in SNK_HARD_RESET_SINK_OFF. Set the current limits to default value based of CC pull up and resume the charge path when port enters SNK_HARD_RESET_SINK_ON. Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Rob Herring Reviewed-by: Heikki Krogerus -------- Changes in V3: Rebase on top of usb-next Changes in V2: Based on feedback of jackp@codeaurora.org - vsafe_5v_hard_reset flag from tcpc_config is removed - Patch only differentiates between pd port partner and non-pd port partner V1 version of the patch is here: https://lkml.org/lkml/2018/9/14/11 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5e989b6cad68f64512bfab2d04df48a47f5c24d2 Author: James Smart Date: Tue Oct 23 13:41:09 2018 -0700 scsi: lpfc: Correct loss of fc4 type on remote port address change [ Upstream commit d83ca3ea833d7a66d49225e4191c4e37cab8f079 ] An address change for a remote port cause PRLI for the wrong protocol to be sent. The node copy done in the discovery code skipped copying the fc4 protocols supported as well. Fix the copy logic for the address change. Beefed up log messages in this area as well. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a391709b636e9b78cf28494f38e42a30c37294f5 Author: James Smart Date: Tue Oct 23 13:41:08 2018 -0700 scsi: lpfc: Fix odd recovery in duplicate FLOGIs in point-to-point [ Upstream commit d496b9a7246cb9813da1fe49e14edbbbf8e232d5 ] Testing a point-to-point topology and a case of re-FLOGI without intervening link bouncing, showed an odd interaction with firmware and a resulting scenario where the driver no longer probed after accepting the new FLOGI. Work around the firmware issue by issuing a link bounce if a FLOGI is received after the link is already up and FLOGI's accepted. While debugging the issue, realized that some debug traces should be clarified to help in the future. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 05678af01a337a242da9744b15255cd6f08a436c Author: James Smart Date: Tue Oct 23 13:41:06 2018 -0700 scsi: lpfc: fcoe: Fix link down issue after 1000+ link bounces [ Upstream commit 036cad1f1ac9ce03e2db94b8460f98eaf1e1ee4c ] On FCoE adapters, when running link bounce test in a loop, initiator failed to login with switch switch and required driver reload to recover. Switch reached a point where all subsequent FLOGIs would be LS_RJT'd. Further testing showed the condition to be related to not performing FCF discovery between FLOGI's. Fix by monitoring FLOGI failures and once a repeated error is seen repeat FCF discovery. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e6d0262e1628e5d61d936a9e15ec5919a2abacbe Author: Shivasharan S Date: Tue Oct 16 23:37:44 2018 -0700 scsi: megaraid_sas: Fix goto labels in error handling [ Upstream commit 8a25fa17b6ed6e6c8101e9c68a10ae68a9025f2c ] During init, if pci_alloc_irq_vectors() fails, the driver has not yet setup the IRQs. Fix the goto labels and error handling for this case. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 83e679606e78210a30f5f3906f8b8f64391f062b Author: Shivasharan S Date: Tue Oct 16 23:37:41 2018 -0700 scsi: megaraid_sas: Fix msleep granularity [ Upstream commit 9155cf30a3c4ef97e225d6daddf9bd4b173267e8 ] In megasas_transition_to_ready() driver waits 180seconds for controller to change FW state. Here we are calling msleep(1) in a loop for this. As explained in timers-howto.txt, msleep(1) will actually sleep longer than 1ms. If a faulty controller is connected, we will end up waiting for much more than 180 seconds causing unnecessary delays during load. Change the granularity of msleep() call from 1ms to 1000ms. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ff997bf13c1e732139ec5b5d1eda998cf3b50320 Author: Suganath Prabu Date: Wed Oct 31 18:53:38 2018 +0530 scsi: mpt3sas: Fix driver modifying persistent data in Manufacturing page11 [ Upstream commit 97f35194093362a63b33caba2485521ddabe2c95 ] Currently driver is modifying both current & NVRAM/persistent data in Manufacturing page11. Driver should change only current copy of Manufacturing page11. It should not modify the persistent data. So removed the section of code where driver is modifying the persistent data of Manufacturing page11. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 80224e3b08ffe85eb990af78e7e3532d779e7be4 Author: Suganath Prabu Date: Wed Oct 31 18:53:37 2018 +0530 scsi: mpt3sas: Don't modify EEDPTagMode field setting on SAS3.5 HBA devices [ Upstream commit 6cd1bc7b9b5075d395ba0120923903873fc7ea0e ] If EEDPTagMode field in manufacturing page11 is set then unset it. This is needed to fix a hardware bug only in SAS3/SAS2 cards. So, skipping EEDPTagMode changes in Manufacturing page11 for SAS 3.5 controllers. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5553e2bdcb02bd0d9cb2c4115910fbc46a96b58b Author: Suganath Prabu Date: Wed Oct 31 18:53:36 2018 +0530 scsi: mpt3sas: Fix Sync cache command failure during driver unload [ Upstream commit 9029a72500b95578a35877a43473b82cb0386c53 ] This is to fix SYNC CACHE and START STOP command failures with DID_NO_CONNECT during driver unload. In driver's IO submission patch (i.e. in driver's .queuecommand()) driver won't allow any SCSI commands to the IOC when ioc->remove_host flag is set and hence SYNC CACHE commands which are issued to the target drives (where write cache is enabled) during driver unload time is failed with DID_NO_CONNECT status. Now modified the driver to allow SYNC CACHE and START STOP commands to IOC, even when remove_host flag is set. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5f2dc610eb281af3f9f19e39b5ddb07598f033be Author: Florian Fainelli Date: Tue Nov 6 15:15:16 2018 -0800 net: dsa: bcm_sf2: Turn on PHY to allow successful registration [ Upstream commit c04a17d2a9ccf1eaba1c5a56f83e997540a70556 ] We are binding to the PHY using the SF2 slave MDIO bus that we create, binding involves reading the PHY's MII_PHYSID1/2 which won't be possible if the PHY is turned off. Temporarily turn it on/off for the bus probing to succeeed. This fixes unbind/bind problems where the port connecting to that PHY would be in error since it could not connect to it. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2ac94b9e902fa2abe9de0c9b8262fb9e147f4b3a Author: Shaokun Zhang Date: Mon Nov 5 19:25:30 2018 +0800 rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information [ Upstream commit 7d129adff3afbd3a449bc3593f2064ac546d58d3 ] RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Cc: Ping-Ke Shih Cc: Kalle Valo Signed-off-by: Shaokun Zhang Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 13d434fed1a2ce7c11b1c3a95a1c20c86b2bf8a7 Author: Dan Carpenter Date: Wed Oct 24 11:33:34 2018 +0300 wireless: airo: potential buffer overflow in sprintf() [ Upstream commit 3d39e1bb1c88f32820c5f9271f2c8c2fb9a52bac ] It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes of the ssid, but we accidentally use "%*s" (width) instead of "%.*s" (precision) so if the ssid doesn't have a NUL terminator this could lead to an overflow. Static analysis. Not tested. Fixes: e174961ca1a0 ("net: convert print_mac to %pM") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit fad934bb2e476d90957af95c8d51ede3bbfca4c9 Author: Ali MJ Al-Nasrawy Date: Tue Oct 23 19:12:35 2018 +0300 brcmsmac: never log "tid x is not agg'able" by default [ Upstream commit 96fca788e5788b7ea3b0050eb35a343637e0a465 ] This message greatly spams the log under heavy Tx of frames with BK access class which is especially true when operating as AP. It is also not informative as the "agg'ablity" of TIDs are set once and never change. Fix this by logging only in debug mode. Signed-off-by: Ali MJ Al-Nasrawy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit bdb61fa50b708a45f21095f586fdd08921f3cf50 Author: Gustavo A. R. Silva Date: Mon Oct 22 13:51:03 2018 +0200 rtl8xxxu: Fix missing break in switch [ Upstream commit 307b00c5e695857ca92fc6a4b8ab6c48f988a1b1 ] Add missing break statement in order to prevent the code from falling through to the default case. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 06ed77066838a07a0126c4d09fc843d1a692c419 Author: Christophe JAILLET Date: Tue Oct 16 09:39:40 2018 +0200 wlcore: Fix the return value in case of error in 'wlcore_vendor_cmd_smart_config_start()' [ Upstream commit 3419348a97bcc256238101129d69b600ceb5cc70 ] We return 0 unconditionally at the end of 'wlcore_vendor_cmd_smart_config_start()'. However, 'ret' is set to some error codes in several error handling paths and we already return some error codes at the beginning of the function. Return 'ret' instead to propagate the error code. Fixes: 80ff8063e87c ("wlcore: handle smart config vendor commands") Signed-off-by: Christophe JAILLET Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c68a499448e139192ca0b45dbe05ca47463a376d Author: Brian Norris Date: Mon Nov 5 14:35:22 2018 +0200 ath10k: snoc: fix unbalanced clock error handling [ Upstream commit 82e60d920e8ad70cd9a280ab156566755f1fe4aa ] Similar to regulator error handling, we should only start tearing down the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might end up with an unbalanced clock, where we never successfully enabled the clock, but we try to disable it anyway. Fixes: a6a793f98786 ("ath10k: vote for hardware resources for WCN3990") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c262dc0655dfdd1d61298a132027159d87e80407 Author: Lior David Date: Wed Oct 31 10:52:24 2018 +0200 wil6210: fix locking in wmi_call [ Upstream commit dc57731dbd535880fe6ced31c229262c34df7d64 ] Switch from spin_lock to spin_lock_irqsave, because wmi_ev_lock is used inside interrupt handler. Signed-off-by: Lior David Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ccb2390e89330d3a562c816408d571975dc8ae5e Author: Maya Erez Date: Wed Oct 31 10:52:20 2018 +0200 wil6210: fix RGF_CAF_ICR address for Talyn-MB [ Upstream commit 7c69709f8ed27197b16aa1c3f9b0744402b2fa02 ] RGF_CAF_ICR register location has changed in Talyn-MB. Add RGF_CAF_ICR_TALYN_MB to support the new address. Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 0e1304ae42c2174a5056fec0aa03ffa09776b1f2 Author: Maya Erez Date: Wed Oct 31 10:52:19 2018 +0200 wil6210: fix L2 RX status handling [ Upstream commit 04de15010aa42a92add66b159e3ae44b4287390f ] L2 RX status errors should not be treated as a bitmap and the actual error values should be checked. Print L2 errors as wil_err_ratelimited for easier debugging when such errors occurs. Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit aa2112d571521b68cfdb82d399a517041e9c4b7c Author: Ahmad Masri Date: Wed Oct 31 10:52:18 2018 +0200 wil6210: fix debugfs memory access alignment [ Upstream commit 84ec040d0fb25197584d28a0dedc355503cd19b9 ] All wil6210 device memory access should be 4 bytes aligned. In io blob wil6210 did not force alignment for read function, this caused alignment fault on some platforms. Fixing that by accessing all 4 lower bytes and return to host the requested data. Signed-off-by: Ahmad Masri Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ea136e61e4df85f53c7fce53d2273c579cf6db9f Author: Arnd Bergmann Date: Sat Nov 3 16:39:28 2018 +0100 btrfs: avoid link error with CONFIG_NO_AUTO_INLINE [ Upstream commit 7e17916b35797396f681a3270245fd29c1e4c250 ] Note: this patch fixes a problem in a feature outside of btrfs ("kernel hacking: add a config option to disable compiler auto-inlining") and is applied ahead of time due to cross-subsystem dependencies. On 32-bit ARM with gcc-8, I see a link error with the addition of the CONFIG_NO_AUTO_INLINE option: fs/btrfs/super.o: In function `btrfs_statfs': super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod' fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to `__aeabi_uldivmod' follow So far this is the only file that shows the behavior, so I'd propose to just work around it by marking the functions as 'static inline' that normally get inlined here. The reference to __aeabi_uldivmod comes from a div_u64() which has an optimization for a constant division that uses a straight '/' operator when the result should be known to the compiler. My interpretation is that as we turn off inlining, gcc still expects the result to be constant but fails to use that constant value. Link: https://lkml.kernel.org/r/20181103153941.1881966-1-arnd@arndb.de Reviewed-by: Nikolay Borisov Reviewed-by: Changbin Du Signed-off-by: Arnd Bergmann [ add the note ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4a035f2643c6b05bbd029e1f509f8e3843a93552 Author: Chiranjeevi Rapolu Date: Fri Oct 26 11:34:30 2018 -0400 media: ov13858: Check for possible null pointer [ Upstream commit 35629182eb8f931b0de6ed38c0efac58e922c801 ] Check for possible null pointer to avoid crash. Signed-off-by: Chiranjeevi Rapolu Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3ee72f30c1636c57c9fe0dbd925d25ecb10a9ff8 Author: Nickhu Date: Thu Oct 25 10:24:14 2018 +0800 nds32: Fix bug in bitfield.h [ Upstream commit 9aaafac8cffa1c1edb66e19a63841b7c86be07ca ] There two bitfield bug for perfomance counter in bitfield.h: PFM_CTL_offSEL1 21 --> 16 PFM_CTL_offSEL2 27 --> 22 This commit fix it. Signed-off-by: Nickhu Acked-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Sasha Levin commit e6c6c0439a936e7fadc6a861cfa53ee61e43dae0 Author: Taehee Yoo Date: Mon Nov 5 22:31:41 2018 +0900 net: bpfilter: fix iptables failure if bpfilter_umh is disabled [ Upstream commit 97adaddaa6db7a8af81b9b11e30cbe3628cd6700 ] When iptables command is executed, ip_{set/get}sockopt() try to upload bpfilter.ko if bpfilter is enabled. if it couldn't find bpfilter.ko, command is failed. bpfilter.ko is generated if CONFIG_BPFILTER_UMH is enabled. ip_{set/get}sockopt() only checks CONFIG_BPFILTER. So that if CONFIG_BPFILTER is enabled and CONFIG_BPFILTER_UMH is disabled, iptables command is always failed. test config: CONFIG_BPFILTER=y # CONFIG_BPFILTER_UMH is not set test command: %iptables -L iptables: No chain/target/match by that name. Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 811c8141d663e399f9413eba23eb046c98b16665 Author: Andrei Vagin Date: Sun Nov 4 22:37:15 2018 -0800 sock_diag: fix autoloading of the raw_diag module [ Upstream commit c34c1287778b080ed692c0a46a8e345206cc29e6 ] IPPROTO_RAW isn't registred as an inet protocol, so inet_protos[protocol] is always NULL for it. Cc: Cyrill Gorcunov Cc: Xin Long Fixes: bf2ae2e4bf93 ("sock_diag: request _diag module only when the family or proto has been registered") Signed-off-by: Andrei Vagin Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3c69a033b416cdebf455787f51750e3ab0c12718 Author: Richard Guy Briggs Date: Wed Oct 10 16:22:57 2018 -0400 audit: print empty EXECVE args [ Upstream commit ea956d8be91edc702a98b7fe1f9463e7ca8c42ab ] Empty executable arguments were being skipped when printing out the list of arguments in an EXECVE record, making it appear they were somehow lost. Include empty arguments as an itemized empty string. Reproducer: autrace /bin/ls "" "/etc" ausearch --start recent -m execve -i | grep EXECVE type=EXECVE msg=audit(10/03/2018 13:04:03.208:1391) : argc=3 a0=/bin/ls a2=/etc With fix: type=EXECVE msg=audit(10/03/2018 21:51:38.290:194) : argc=3 a0=/bin/ls a1= a2=/etc type=EXECVE msg=audit(1538617898.290:194): argc=3 a0="/bin/ls" a1="" a2="/etc" Passes audit-testsuite. GH issue tracker at https://github.com/linux-audit/audit-kernel/issues/99 Signed-off-by: Richard Guy Briggs [PM: cleaned up the commit metadata] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 5dc441fbef91a8d05c0917942692d3c06d255e73 Author: Florian Fainelli Date: Thu Sep 27 12:27:11 2018 -0700 soc: bcm: brcmstb: Fix re-entry point with a THUMB2_KERNEL [ Upstream commit fb14ada11d62fb849fc357a25ef8016ba438ba10 ] When the kernel is built with CONFIG_THUMB2_KERNEL we would set the kernel's resume entry point to be a function that is already built as Thumb-2 code while the boot agent doing the resume is in ARM mode, so this does not work. There is a header label defined: cpu_resume_arm which we can use to do the switching for us. Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 9cdfff0a5e61b0eed6f8a81f178939f06dc5b65b Author: Icenowy Zheng Date: Thu Oct 18 15:07:29 2018 +0800 clk: sunxi-ng: enable so-said LDOs for A64 SoC's pll-mipi clock [ Upstream commit 859783d1390035e29ba850963bded2b4ffdf43b5 ] In the user manual of A64 SoC, the bit 22 and 23 of pll-mipi control register is called "LDO{1,2}_EN", and according to the BSP source code from Allwinner , the LDOs are enabled during the clock's enabling process. The clock failed to generate output if the two LDOs are not enabled. Add the two bits to the clock's gate bits, so that the LDOs are enabled when the PLL is enabled. Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks") Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit a2e6fe1f647f45ec3ad14922f05b34b8c4afd211 Author: Leonard Crestez Date: Mon Oct 8 15:28:01 2018 +0000 ARM: dts: imx6sx-sdb: Fix enet phy regulator [ Upstream commit 1ad9fb750a104f51851c092edd7b3553f0218428 ] Bindings for "fixed-regulator" only explicitly support "gpio" property, not "gpios". Fix by correcting the property name. The enet PHYs on imx6sx-sdb needs to be explicitly reset after a power cycle, this can be handled by the phy-reset-gpios property. Sadly this is not handled on suspend: the fec driver turns phy-supply off but doesn't assert phy-reset-gpios again on resume. Since additional phy-level work is required to support powering off the phy in suspend fix the problem by just marking the regulator as "boot-on" "always-on" so that it's never turned off. This behavior is equivalent to older releases. Keep the phy-reset-gpios property on fec anyway because it is a correct description of board design. This issue was exposed by commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") which causes the "gpios" property to also be parsed. Before that commit the "gpios" property had no effect, PHY reset was only handled in the the bootloader. This fixes linux-next boot failures previously reported here: https://lore.kernel.org/patchwork/patch/982437/#1177900 https://lore.kernel.org/patchwork/patch/994091/#1178304 Signed-off-by: Leonard Crestez Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 465073e44fda4982af05fb2d518ef5ce99b1fbe6 Author: Arnd Bergmann Date: Fri Nov 2 16:36:55 2018 +0100 openvswitch: fix linking without CONFIG_NF_CONNTRACK_LABELS [ Upstream commit a277d516de5f498c91d91189717ef7e01102ad27 ] When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler fails to optimize out a dead code path, which leads to a link failure: net/openvswitch/conntrack.o: In function `ovs_ct_set_labels': conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace' In this configuration, we can take a shortcut, and completely remove the contrack label code. This may also help the regular optimization. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 31bced01fe77f5164201190bb488f09575000c1d Author: Valentin Schneider Date: Wed Sep 26 16:12:07 2018 +0100 sched/fair: Don't increase sd->balance_interval on newidle balance [ Upstream commit 3f130a37c442d5c4d66531b240ebe9abfef426b5 ] When load_balance() fails to move some load because of task affinity, we end up increasing sd->balance_interval to delay the next periodic balance in the hopes that next time we look, that annoying pinned task(s) will be gone. However, idle_balance() pays no attention to sd->balance_interval, yet it will still lead to an increase in balance_interval in case of pinned tasks. If we're going through several newidle balances (e.g. we have a periodic task), this can lead to a huge increase of the balance_interval in a very small amount of time. To prevent that, don't increase the balance interval when going through a newidle balance. This is a similar approach to what is done in commit 58b26c4c0257 ("sched: Increment cache_nice_tries only on periodic lb"), where we disregard newidle balance and rely on periodic balance for more stable results. Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: patrick.bellasi@arm.com Cc: vincent.guittot@linaro.org Link: http://lkml.kernel.org/r/1537974727-30788-2-git-send-email-valentin.schneider@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ed023646c2cf2366d0d31beef688227b0a2bc15f Author: Peter Zijlstra Date: Fri Nov 2 14:22:25 2018 +0100 sched/topology: Fix off by one bug [ Upstream commit 993f0b0510dad98b4e6e39506834dab0d13fd539 ] With the addition of the NUMA identity level, we increased @level by one and will run off the end of the array in the distance sort loop. Fixed: 051f3ca02e46 ("sched/topology: Introduce NUMA identity node sched domain") Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit f9fca78e6cf2a44504dac45761c5195973f49c29 Author: Eric Dumazet Date: Wed Oct 31 08:39:13 2018 -0700 net: do not abort bulk send on BQL status [ Upstream commit fe60faa5063822f2d555f4f326c7dd72a60929bf ] Before calling dev_hard_start_xmit(), upper layers tried to cook optimal skb list based on BQL budget. Problem is that GSO packets can end up comsuming more than the BQL budget. Breaking the loop is not useful, since requeued packets are ahead of any packets still in the qdisc. It is also more expensive, since next TX completion will push these packets later, while skbs are not in cpu caches. It is also a behavior difference with TSO packets, that can break the BQL limit by a large amount. Note that drivers should use __netdev_tx_sent_queue() in order to have optimal xmit_more support, and avoid useless atomic operations as shown in the following patch. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d3b9ac2844fd0fe3eb2b19592aaced0abb0d6bb Author: Larry Chen Date: Fri Nov 2 15:48:27 2018 -0700 ocfs2: fix clusters leak in ocfs2_defrag_extent() [ Upstream commit 6194ae4242dec0c9d604bc05df83aa9260a899e4 ] ocfs2_defrag_extent() might leak allocated clusters. When the file system has insufficient space, the number of claimed clusters might be less than the caller wants. If that happens, the original code might directly commit the transaction without returning clusters. This patch is based on code in ocfs2_add_clusters_in_btree(). [akpm@linux-foundation.org: include localalloc.h, reduce scope of data_ac] Link: http://lkml.kernel.org/r/20180904041621.16874-3-lchen@suse.com Signed-off-by: Larry Chen Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6c150df9c2e80b5cf86f5a0d98beb7390ad63bfc Author: Changwei Ge Date: Fri Nov 2 15:48:19 2018 -0700 ocfs2: don't put and assigning null to bh allocated outside [ Upstream commit cf76c78595ca87548ca5e45c862ac9e0949c4687 ] ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read several blocks from disk. Currently, the input argument *bhs* can be NULL or NOT. It depends on the caller's behavior. If the function fails in reading blocks from disk, the corresponding bh will be assigned to NULL and put. Obviously, above process for non-NULL input bh is not appropriate. Because the caller doesn't even know its bhs are put and re-assigned. If buffer head is managed by caller, ocfs2_read_blocks and ocfs2_read_blocks_sync() should not evaluate it to NULL. It will cause caller accessing illegal memory, thus crash. Link: http://lkml.kernel.org/r/HK2PR06MB045285E0F4FBB561F9F2F9B3D5680@HK2PR06MB0452.apcprd06.prod.outlook.com Signed-off-by: Changwei Ge Reviewed-by: Guozhonghua Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6fd469d06eb840462329b60239b5f235cee9e925 Author: Changwei Ge Date: Fri Nov 2 15:48:11 2018 -0700 ocfs2: don't use iocb when EIOCBQUEUED returns [ Upstream commit 9e985787750db8aae87f02b67e908f28ac4d6b83 ] When -EIOCBQUEUED returns, it means that aio_complete() will be called from dio_complete(), which is an asynchronous progress against write_iter. Generally, IO is a very slow progress than executing instruction, but we still can't take the risk to access a freed iocb. And we do face a BUG crash issue. Using the crash tool, iocb is obviously freed already. crash> struct -x kiocb ffff881a350f5900 struct kiocb { ki_filp = 0xffff881a350f5a80, ki_pos = 0x0, ki_complete = 0x0, private = 0x0, ki_flags = 0x0 } And the backtrace shows: ocfs2_file_write_iter+0xcaa/0xd00 [ocfs2] aio_run_iocb+0x229/0x2f0 do_io_submit+0x291/0x540 SyS_io_submit+0x10/0x20 system_call_fastpath+0x16/0x75 Link: http://lkml.kernel.org/r/1523361653-14439-1-git-send-email-ge.changwei@h3c.com Signed-off-by: Changwei Ge Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit abc7968b86b1d09e1798341760197f6d1e9071f5 Author: Guozhonghua Date: Fri Nov 2 15:48:07 2018 -0700 ocfs2: without quota support, avoid calling quota recovery [ Upstream commit 21158ca85b73ddd0088076a5209cfd040513a8b5 ] During one dead node's recovery by other node, quota recovery work will be queued. We should avoid calling quota when it is not supported, so check the quota flags. Link: http://lkml.kernel.org/r/71604351584F6A4EBAE558C676F37CA401071AC9FB@H3CMLB12-EX.srv.huawei-3com.com Signed-off-by: guozhonghua Reviewed-by: Jan Kara Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6a2245d828e4627df8927957b30602a04d9c2f07 Author: Roman Gushchin Date: Fri Nov 2 15:47:49 2018 -0700 mm: handle no memcg case in memcg_kmem_charge() properly [ Upstream commit e68599a3c3ad0f3171a7cb4e48aa6f9a69381902 ] Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") on a system with "cgroup_disable=memory" boot option: the system panics with the following stack trace: BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 0 PID: 1 Comm: systemd Not tainted 4.19.0-preempt+ #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fed4 RIP: 0010:page_counter_try_charge+0x22/0xc0 Code: 41 5d c3 c3 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 0f 84 a7 00 00 00 41 56 48 89 f8 49 89 fe 49 Call Trace: try_charge+0xcb/0x780 memcg_kmem_charge_memcg+0x28/0x80 memcg_kmem_charge+0x8b/0x1d0 copy_process.part.41+0x1ca/0x2070 _do_fork+0xd7/0x3d0 do_syscall_64+0x5a/0x180 entry_SYSCALL_64_after_hwframe+0x49/0xbe The problem occurs because get_mem_cgroup_from_current() returns the NULL pointer if memory controller is disabled. Let's check if this is a case at the beginning of memcg_kmem_charge() and just return 0 if mem_cgroup_disabled() returns true. This is how we handle this case in many other places in the memory controller code. Link: http://lkml.kernel.org/r/20181029215123.17830-1-guro@fb.com Fixes: 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") Signed-off-by: Roman Gushchin Reported-by: Mike Galbraith Acked-by: Rik van Riel Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 08f07d9f5b17c5d1e0c4bafb75840e4f7ad6b764 Author: Len Brown Date: Tue Aug 7 20:22:28 2018 -0400 tools/power turbosat: fix AMD APIC-id output [ Upstream commit 3404155190ce09a1e5d8407e968fc19aac4493e3 ] turbostat recently gained a feature adding APIC and X2APIC columns. While they are disabled by-default, they are enabled with --debug or when explicitly requested, eg. $ sudo turbostat --quiet --show Package,Node,Core,CPU,APIC,X2APIC date But these columns erroneously showed zeros on AMD hardware. This patch corrects the APIC and X2APIC [sic] columns on AMD. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit b167fee4e45d51d69c68dcd0a3495e576e7d6190 Author: Victor Kamensky Date: Tue Oct 30 16:37:10 2018 -0700 arm64: makefile fix build of .i file in external module case [ Upstream commit 98356eb0ae499c63e78073ccedd9a5fc5c563288 ] After 'a66649dab350 arm64: fix vdso-offsets.h dependency' if one will try to build .i file in case of external kernel module, build fails complaining that prepare0 target is missing. This issue came up with SystemTap when it tries to build variety of .i files for its own generated kernel modules trying to figure given kernel features/capabilities. The issue is that prepare0 is defined in top level Makefile only if KBUILD_EXTMOD is not defined. .i file rule depends on prepare and in case KBUILD_EXTMOD defined top level Makefile contains empty rule for prepare. But after mentioned commit arch/arm64/Makefile would introduce dependency on prepare0 through its own prepare target. Fix it to put proper ifdef KBUILD_EXTMOD around code introduced by mentioned commit. It matches what top level Makefile does. Acked-by: Kevin Brodsky Signed-off-by: Victor Kamensky Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit fa7f1bce27c064c204d942cc31c31a4c4cef451a Author: Keith Busch Date: Wed Oct 31 13:15:29 2018 -0600 nvme-pci: fix conflicting p2p resource adds [ Upstream commit 9fe5c59ff6a1e5e26a39b75489a1420e7eaaf0b1 ] The nvme pci driver had been adding its CMB resource to the P2P DMA subsystem everytime on on a controller reset. This results in the following warning: ------------[ cut here ]------------ nvme 0000:00:03.0: Conflicting mapping in same section WARNING: CPU: 7 PID: 81 at kernel/memremap.c:155 devm_memremap_pages+0xa6/0x380 ... Call Trace: pci_p2pdma_add_resource+0x153/0x370 nvme_reset_work+0x28c/0x17b1 [nvme] ? add_timer+0x107/0x1e0 ? dequeue_entity+0x81/0x660 ? dequeue_entity+0x3b0/0x660 ? pick_next_task_fair+0xaf/0x610 ? __switch_to+0xbc/0x410 process_one_work+0x1cf/0x350 worker_thread+0x215/0x3d0 ? process_one_work+0x350/0x350 kthread+0x107/0x120 ? kthread_park+0x80/0x80 ret_from_fork+0x1f/0x30 ---[ end trace f7ea76ac6ee72727 ]--- nvme nvme0: failed to register the CMB This patch fixes this by registering the CMB with P2P only once. Signed-off-by: Keith Busch Reviewed-by: Logan Gunthorpe Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0bbb8382db4c8c7d1b0dc894f3364719d91dbf7e Author: Michael Kelley Date: Thu Nov 1 00:35:05 2018 +0000 irq/matrix: Fix memory overallocation [ Upstream commit 57f01796f14fecf00d330fe39c8d2477ced9cd79 ] IRQ_MATRIX_SIZE is the number of longs needed for a bitmap, multiplied by the size of a long, yielding a byte count. But it is used to size an array of longs, which is way more memory than is needed. Change IRQ_MATRIX_SIZE so it is just the number of longs needed and the arrays come out the correct size. Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator") Signed-off-by: Michael Kelley Signed-off-by: Thomas Gleixner Cc: KY Srinivasan Link: https://lkml.kernel.org/r/1541032428-10392-1-git-send-email-mikelley@microsoft.com Signed-off-by: Sasha Levin commit ad8298fccd706b6c5fd23c20c77a1d38ecb34609 Author: Dave Jiang Date: Tue Aug 28 17:13:59 2018 -0700 ntb: intel: fix return value for ndev_vec_mask() [ Upstream commit 7756e2b5d68c36e170a111dceea22f7365f83256 ] ndev_vec_mask() should be returning u64 mask value instead of int. Otherwise the mask value returned can be incorrect for larger vectors. Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Signed-off-by: Dave Jiang Tested-by: Lucas Van Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 3bd4422af874152e95c743f71b86d57fc0a0d4d8 Author: Jon Mason Date: Mon Jun 11 16:13:12 2018 -0400 ntb_netdev: fix sleep time mismatch [ Upstream commit a861594b1b7ffd630f335b351c4e9f938feadb8e ] The tx_time should be in usecs (according to the comment above the variable), but the setting of the timer during the rearming is done in msecs. Change it to match the expected units. Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Suggested-by: Gerd W. Haeussler Signed-off-by: Jon Mason Acked-by: Dave Jiang Signed-off-by: Sasha Levin commit 8dbecf6c2f1737249701522e93c7952083a12826 Author: Huazhong Tan Date: Tue Oct 30 21:50:49 2018 +0800 net: hns3: bugfix for hclge_mdio_write and hclge_mdio_read [ Upstream commit 1c12493809924deda6c0834cb2f2c5a6dc786390 ] When there is a PHY, the driver needs to complete some operations through MDIO during reset reinitialization, so HCLGE_STATE_CMD_DISABLE is more suitable than HCLGE_STATE_RST_HANDLING to prevent the MDIO operation from being sent during the hardware reset. Fixes: b50ae26c57cb ("net: hns3: never send command queue message to IMP when reset) Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12eeb72afac226d9cb4c5555ebbcfebcc57f76f9 Author: Huazhong Tan Date: Tue Oct 30 21:50:48 2018 +0800 net: hns3: bugfix for is_valid_csq_clean_head() [ Upstream commit 6d71ec6cbf74ac9c2823ef751b1baa5b889bb3ac ] The HEAD pointer of the hardware command queue maybe equal to the command queue's next_to_use in the driver, so that does not belong to the invalid HEAD pointer, since the hardware may not process the command in time, causing the HEAD pointer to be too late to update. The variables' name in this function is unreadable, so give them a more readable one. Fixes: 3ff504908f95 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e3345108409c720bbce563d02443bc85431dab09 Author: Huazhong Tan Date: Tue Oct 30 21:50:45 2018 +0800 net: hns3: bugfix for reporting unknown vector0 interrupt repeatly problem [ Upstream commit 0d4411408a7fb9aad0645f23911d9bfdd2ce3177 ] The current driver supports handling two vector0 interrupts, reset and mailbox. When the hardware reports an interrupt of another type of interrupt source, if the driver does not process the interrupt, but enables the interrupt, the hardware will repeatedly report the unknown interrupt. Therefore, the driver enables the vector0 interrupt after clearing the known type of interrupt source. Other conditions are not enabled. Fixes: cd8c5c269b1d ("net: hns3: Fix for hclge_reset running repeatly problem") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0465d06d4c6bedde945864cc10cdf7a1da1f034 Author: Huazhong Tan Date: Tue Oct 30 21:50:44 2018 +0800 net: hns3: bugfix for buffer not free problem during resetting [ Upstream commit 73b907a083b8a8c1c62cb494bc9fbe6ae086c460 ] When hns3_get_ring_config()/hns3_queue_to_ring()/ hns3_get_vector_ring_chain() failed during resetting, the allocated memory has not been freed before these three functions return. So this patch adds error handler in these functions to fix it. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d9bc014c519fc2fb755bb397a07332010d520ab Author: Jacob Keller Date: Mon Oct 15 12:18:28 2018 -0700 fm10k: ensure completer aborts are marked as non-fatal after a resume [ Upstream commit e330af788998b0de4da4f5bd7ddd087507999800 ] VF drivers can trigger PCIe completer aborts any time they read a queue that they don't own. Even in nominal circumstances, it is not possible to prevent the VF driver from reading queues it doesn't own. VF drivers may attempt to read queues it previously owned, but which it no longer does due to a PF reset. Normally these completer aborts aren't an issue. However, on some platforms these trigger machine check errors. This is true even if we lower their severity from fatal to non-fatal. Indeed, we already have code for lowering the severity. We could attempt to mask these errors conditionally around resets, which is the most common time they would occur. However this would essentially be a race between the PF and VF drivers, and we may still occasionally see machine check exceptions on these strictly configured platforms. Instead, mask the errors entirely any time we resume VFs. By doing so, we prevent the completer aborts from being sent to the parent PCIe device, and thus these strict platforms will not upgrade them into machine check errors. Additionally, we don't lose any information by masking these errors, because we'll still report VFs which attempt to access queues via the FUM_BAD_VF_QACCESS errors. Without this change, on platforms where completer aborts cause machine check exceptions, the VF reading queues it doesn't own could crash the host system. Masking the completer abort prevents this, so we should mask it for good, and not just around a PCIe reset. Otherwise malicious or misconfigured VFs could cause the host system to crash. Because we are masking the error entirely, there is little reason to also keep setting the severity bit, so that code is also removed. Signed-off-by: Jacob Keller Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 2fed73906e97b57804c7e344838e88c1a1cc2b94 Author: Miroslav Lichvar Date: Fri Oct 12 13:13:39 2018 +0200 igb: shorten maximum PHC timecounter update interval [ Upstream commit 094bf4d0e9657f6ea1ee3d7e07ce3970796949ce ] The timecounter needs to be updated at least once per ~550 seconds in order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old timestamp. Since commit 500462a9d ("timers: Switch to a non-cascading wheel"), scheduling of delayed work seems to be less accurate and a requested delay of 540 seconds may actually be longer than 550 seconds. Shorten the delay to 480 seconds to be sure the timecounter is updated in time. This fixes an issue with HW timestamps on 82580/I350/I354 being off by ~1100 seconds for few seconds every ~9 minutes. Cc: Jacob Keller Cc: Richard Cochran Cc: Thomas Gleixner Signed-off-by: Miroslav Lichvar Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3081ae5e378f4ec1860b14457b03fe94e65374e7 Author: David Hildenbrand Date: Tue Oct 30 15:10:33 2018 -0700 powerpc/powernv: hold device_hotplug_lock when calling device_online() [ Upstream commit cec1680591d6d5b10ecc10f370210089416e98af ] device_online() should be called with device_hotplug_lock() held. Link: http://lkml.kernel.org/r/20180925091457.28651-5-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Cc: Boris Ostrovsky Cc: Dan Williams Cc: Greg Kroah-Hartman Cc: Haiyang Zhang Cc: Heiko Carstens Cc: John Allen Cc: Jonathan Corbet Cc: Joonsoo Kim Cc: Juergen Gross Cc: Kate Stewart Cc: "K. Y. Srinivasan" Cc: Len Brown Cc: Martin Schwidefsky Cc: Mathieu Malaterre Cc: Michal Hocko Cc: Nathan Fontenot Cc: Oscar Salvador Cc: Philippe Ombredanne Cc: Rafael J. Wysocki Cc: "Rafael J. Wysocki" Cc: Stephen Hemminger Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: YASUAKI ISHIMATSU Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 17523d7a1cc8c4dd79b078d8724c2af5ad2f3a4e Author: David Hildenbrand Date: Tue Oct 30 15:10:29 2018 -0700 mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock [ Upstream commit 381eab4a6ee81266f8dddc62e57376c7e584e5b8 ] There seem to be some problems as result of 30467e0b3be ("mm, hotplug: fix concurrent memory hot-add deadlock"), which tried to fix a possible lock inversion reported and discussed in [1] due to the two locks a) device_lock() b) mem_hotplug_lock While add_memory() first takes b), followed by a) during bus_probe_device(), onlining of memory from user space first took a), followed by b), exposing a possible deadlock. In [1], and it was decided to not make use of device_hotplug_lock, but rather to enforce a locking order. The problems I spotted related to this: 1. Memory block device attributes: While .state first calls mem_hotplug_begin() and the calls device_online() - which takes device_lock() - .online does no longer call mem_hotplug_begin(), so effectively calls online_pages() without mem_hotplug_lock. 2. device_online() should be called under device_hotplug_lock, however onlining memory during add_memory() does not take care of that. In addition, I think there is also something wrong about the locking in 3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages() without locks. This was introduced after 30467e0b3be. And skimming over the code, I assume it could need some more care in regards to locking (e.g. device_online() called without device_hotplug_lock. This will be addressed in the following patches. Now that we hold the device_hotplug_lock when - adding memory (e.g. via add_memory()/add_memory_resource()) - removing memory (e.g. via remove_memory()) - device_online()/device_offline() We can move mem_hotplug_lock usage back into online_pages()/offline_pages(). Why is mem_hotplug_lock still needed? Essentially to make get_online_mems()/put_online_mems() be very fast (relying on device_hotplug_lock would be very slow), and to serialize against addition of memory that does not create memory block devices (hmm). [1] http://driverdev.linuxdriverproject.org/pipermail/ driverdev-devel/ 2015-February/065324.html This patch is partly based on a patch by Vitaly Kuznetsov. Link: http://lkml.kernel.org/r/20180925091457.28651-4-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Reviewed-by: Oscar Salvador Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Rashmica Gupta Cc: Michael Neuling Cc: Balbir Singh Cc: Kate Stewart Cc: Thomas Gleixner Cc: Philippe Ombredanne Cc: Pavel Tatashin Cc: Vlastimil Babka Cc: Dan Williams Cc: Oscar Salvador Cc: YASUAKI ISHIMATSU Cc: Mathieu Malaterre Cc: John Allen Cc: Jonathan Corbet Cc: Joonsoo Kim Cc: Nathan Fontenot Cc: Rafael J. Wysocki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 02735d5987b949f290ba65d491a714bba38de905 Author: David Hildenbrand Date: Tue Oct 30 15:10:24 2018 -0700 mm/memory_hotplug: make add_memory() take the device_hotplug_lock [ Upstream commit 8df1d0e4a265f25dc1e7e7624ccdbcb4a6630c89 ] add_memory() currently does not take the device_hotplug_lock, however is aleady called under the lock from arch/powerpc/platforms/pseries/hotplug-memory.c drivers/acpi/acpi_memhotplug.c to synchronize against CPU hot-remove and similar. In general, we should hold the device_hotplug_lock when adding memory to synchronize against online/offline request (e.g. from user space) - which already resulted in lock inversions due to device_lock() and mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory hot-add deadlock"). add_memory()/add_memory_resource() will create memory block devices, so this really feels like the right thing to do. Holding the device_hotplug_lock makes sure that a memory block device can really only be accessed (e.g. via .online/.state) from user space, once the memory has been fully added to the system. The lock is not held yet in drivers/xen/balloon.c arch/powerpc/platforms/powernv/memtrace.c drivers/s390/char/sclp_cmd.c drivers/hv/hv_balloon.c So, let's either use the locked variants or take the lock. Don't export add_memory_resource(), as it once was exported to be used by XEN, which is never built as a module. If somebody requires it, we also have to export a locked variant (as device_hotplug_lock is never exported). Link: http://lkml.kernel.org/r/20180925091457.28651-3-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rafael J. Wysocki Reviewed-by: Rashmica Gupta Reviewed-by: Oscar Salvador Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Nathan Fontenot Cc: John Allen Cc: Michal Hocko Cc: Dan Williams Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Mathieu Malaterre Cc: Pavel Tatashin Cc: YASUAKI ISHIMATSU Cc: Balbir Singh Cc: Haiyang Zhang Cc: Heiko Carstens Cc: Jonathan Corbet Cc: Kate Stewart Cc: "K. Y. Srinivasan" Cc: Martin Schwidefsky Cc: Michael Neuling Cc: Philippe Ombredanne Cc: Stephen Hemminger Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 023c071f101c6ab7640c37445f1ea8f8013d3f16 Author: Borislav Petkov Date: Tue Oct 30 15:07:13 2018 -0700 kernel/panic.c: do not append newline to the stack protector panic string [ Upstream commit 95c4fb78fb23081472465ca20d5d31c4b780ed82 ] ... because panic() itself already does this. Otherwise you have line-broken trailer: [ 1.836965] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: pgd_alloc+0x29e/0x2a0 [ 1.836965] ]--- Link: http://lkml.kernel.org/r/20181008202901.7894-1-bp@alien8.de Signed-off-by: Borislav Petkov Acked-by: Kees Cook Cc: Masahiro Yamada Cc: "Steven Rostedt (VMware)" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1914e5edd81131c3b7f6621f4c12832997dd2c93 Author: Colin Ian King Date: Tue Oct 30 15:06:35 2018 -0700 fs/hfs/extent.c: fix array out of bounds read of array extent [ Upstream commit 6c9a3f843a29d6894dfc40df338b91dbd78f0ae3 ] Currently extent and index i are both being incremented causing an array out of bounds read on extent[i]. Fix this by removing the extraneous increment of extent. Ernesto said: : This is only triggered when deleting a file with a resource fork. I : may be wrong because the documentation isn't clear, but I don't think : you can create those under linux. So I guess nobody was testing them. : : > A disk space leak, perhaps? : : That's what it looks like in general. hfs_free_extents() won't do : anything if the block count doesn't add up, and the error will be : ignored. Now, if the block count randomly does add up, we could see : some corruption. Detected by CoverityScan, CID#711541 ("Out of bounds read") Link: http://lkml.kernel.org/r/20180831140538.31566-1-colin.king@canonical.com Signed-off-by: Colin Ian King Reviewed-by: Ernesto A. Fernndez Cc: David Howells Cc: Al Viro Cc: Hin-Tak Leung Cc: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a9f38975eb981ff59ef3e943274a723c837da422 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:31 2018 -0700 hfs: update timestamp on truncate() [ Upstream commit 8cd3cb5061730af085a3f9890a3352f162b4e20c ] The vfs takes care of updating mtime on ftruncate(), but on truncate() it must be done by the module. Link: http://lkml.kernel.org/r/e1611eda2985b672ed2d8677350b4ad8c2d07e8a.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0013adceb5211fce175c0bd30b4ebc81c265d97f Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:27 2018 -0700 hfsplus: update timestamps on truncate() [ Upstream commit dc8844aada735890a6de109bef327f5df36a982e ] The vfs takes care of updating ctime and mtime on ftruncate(), but on truncate() it must be done by the module. This patch can be tested with xfstests generic/313. Link: http://lkml.kernel.org/r/9beb0913eea37288599e8e1b7cec8768fb52d1b8.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 38e7b916daa2d9c4161a2e46148693b2374c0296 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:24 2018 -0700 hfs: fix return value of hfs_get_block() [ Upstream commit 1267a07be5ebbff2d2739290f3d043ae137c15b4 ] Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfs is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfs_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/4538ab8c35ea37338490525f0f24cbc37227528c.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 550da9ee35fd904b3814da10236802a555c13f2c Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:21 2018 -0700 hfsplus: fix return value of hfsplus_get_block() [ Upstream commit 839c3a6a5e1fbc8542d581911b35b2cb5cd29304 ] Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfsplus is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfsplus_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/2cd1301404ec7cf1e39c8f11a01a4302f1460ad6.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8687d57d247a4d7a217fcf324b34c5ded887c21a Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:17 2018 -0700 hfs: prevent btree data loss on ENOSPC [ Upstream commit 54640c7502e5ed41fbf4eedd499e85f9acc9698f ] Inserting a new record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes or extents. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. There is no need to reserve space before deleting a catalog record, as we do for hfsplus. This difference is because hfs index nodes have fixed length keys. Link: http://lkml.kernel.org/r/ab5fc8a7d5ffccfd5f27b1cf2cb4ceb6c110da74.1536269131.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0b54b59d8541ec9ca6160c77633bf8e11edfaaac Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:14 2018 -0700 hfsplus: prevent btree data loss on ENOSPC [ Upstream commit d92915c35bfaf763d78bf1d5ac7f183420e3bd99 ] Inserting or deleting a record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes, extents or xattrs. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. The patch can be tested with xfstests generic/027. Link: http://lkml.kernel.org/r/4596eef22fbda137b4ffa0272d92f0da15364421.1536269129.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7beaf6105e2e14a421a5ccb1d01fb730ea61d8c3 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:11 2018 -0700 hfs: fix BUG on bnode parent update [ Upstream commit ef75bcc5763d130451a99825f247d301088b790b ] hfs_brec_update_parent() may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this BUG, so it's better to fix it. Link: http://lkml.kernel.org/r/cf9b02d57f806217a2b1bf5db8c3e39730d8f603.1535682463.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Andrew Morton Cc: Christoph Hellwig Cc: Viacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1df96949ebfb210c9cc56c90e4159121d3c470c3 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:04 2018 -0700 hfsplus: fix BUG on bnode parent update [ Upstream commit 19a9d0f1acf75e8be8cfba19c1a34e941846fa2b ] Creating, renaming or deleting a file may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. This bug is triggered by xfstests generic/027, somewhat rarely; here is a more reliable reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=1000 while [ $i -le 2400 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=2400 while [ $i -ge 1000 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x61") &>/dev/null ((--i)) done The issue is that a newly created bnode is being put twice. Reset new_node to NULL in hfs_brec_update_parent() before reaching goto again. Link: http://lkml.kernel.org/r/5ee1db09b60373a15890f6a7c835d00e76bf601d.1535682461.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 08751e477f0eacf90a72df15dbda94f95c794fda Author: Rasmus Villemoes Date: Tue Oct 30 15:05:14 2018 -0700 lib/bitmap.c: fix remaining space computation in bitmap_print_to_pagebuf [ Upstream commit ce1091d471107dbf6f91db66a480a25950c9b9ff ] For various alignments of buf, the current expression computes 4096 ok 4095 ok 8190 8189 ... 4097 i.e., if the caller has already written two bytes into the page buffer, len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next boundary. So if the printed version of the bitmap is huge, scnprintf() ends up writing beyond the page boundary. I don't think any current callers actually write anything before bitmap_print_to_pagebuf, but the API seems to be designed to allow it. [akpm@linux-foundation.org: use offset_in_page(), per Andy] [akpm@linux-foundation.org: include mm.h for offset_in_page()] Link: http://lkml.kernel.org/r/20180818131623.8755-7-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Reviewed-by: Andy Shevchenko Cc: Yury Norov Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1d58349459450f04cbd82e5f3bdd8c4e3699433b Author: Rasmus Villemoes Date: Tue Oct 30 15:05:07 2018 -0700 linux/bitmap.h: fix type of nbits in bitmap_shift_right() [ Upstream commit d9873969fa8725dc6a5a21ab788c057fd8719751 ] Most other bitmap API, including the OOL version __bitmap_shift_right, take unsigned nbits. This was accidentally left out from 2fbad29917c98. Link: http://lkml.kernel.org/r/20180818131623.8755-5-linux@rasmusvillemoes.dk Fixes: 2fbad29917c98 ("lib: bitmap: change bitmap_shift_right to take unsigned parameters") Signed-off-by: Rasmus Villemoes Reported-by: Yury Norov Reviewed-by: Andy Shevchenko Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8deaaf77ce2efb3f314c97fa2e1f73eb6899d8c3 Author: Rasmus Villemoes Date: Tue Oct 30 15:04:59 2018 -0700 linux/bitmap.h: handle constant zero-size bitmaps correctly [ Upstream commit 7275b097851a5e2e0dd4da039c7e96b59ac5314e ] The static inlines in bitmap.h do not handle a compile-time constant nbits==0 correctly (they dereference the passed src or dst pointers, despite only 0 words being valid to access). I had the 0-day buildbot chew on a patch [1] that would cause build failures for such cases without complaining, suggesting that we don't have any such users currently, at least for the 70 .config/arch combinations that was built. Should any turn up, make sure they use the out-of-line versions, which do handle nbits==0 correctly. This is of course not the most efficient, but it's much less churn than teaching all the static inlines an "if (zero_const_nbits())", and since we don't have any current instances, this doesn't affect existing code at all. [1] lkml.kernel.org/r/20180815085539.27485-1-linux@rasmusvillemoes.dk Link: http://lkml.kernel.org/r/20180818131623.8755-3-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Reviewed-by: Andy Shevchenko Cc: Yury Norov Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 30598425aecc7af38f8786db3ab5317e07430db2 Author: Dan Carpenter Date: Tue Oct 30 15:04:32 2018 -0700 mm/gup_benchmark.c: prevent integer overflow in ioctl [ Upstream commit 4b408c74ee5a0b74fc9265c2fe39b0e7dec7c056 ] The concern here is that "gup->size" is a u64 and "nr_pages" is unsigned long. On 32 bit systems we could trick the kernel into allocating fewer pages than expected. Link: http://lkml.kernel.org/r/20181025061546.hnhkv33diogf2uis@kili.mountain Fixes: 64c349f4ae78 ("mm: add infrastructure for get_user_pages_fast() benchmarking") Signed-off-by: Dan Carpenter Acked-by: Kirill A. Shutemov Reviewed-by: Andrew Morton Cc: Stephen Rothwell Cc: Keith Busch Cc: "Michael S. Tsirkin" Cc: Kees Cook Cc: YueHaibing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9663d294ae28ccd970bd0f1e8abbd8d7eb630943 Author: Ming Lei Date: Wed Oct 24 21:18:09 2018 +0800 block: call rq_qos_exit() after queue is frozen [ Upstream commit c57cdf7a9e51d97a43e29b8f4a04157875104000 ] rq_qos_exit() removes the current q->rq_qos, this action has to be done after queue is frozen, otherwise the IO queue path may never be waken up, then IO hang is caused. So fixes this issue by moving rq_qos_exit() after queue is frozen. Cc: Josef Bacik Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a125df22d134c341a1e7a998958ecaa2969256cd Author: Michael Ellerman Date: Mon Oct 29 22:23:53 2018 +1100 selftests/powerpc/cache_shape: Fix out-of-tree build [ Upstream commit 69f8117f17b332a68cd8f4bf8c2d0d3d5b84efc5 ] Use TEST_GEN_PROGS and don't redefine all, this makes the out-of-tree build work. We need to move the extra dependencies below the include of lib.mk, because it adds the $(OUTPUT) prefix if it's defined. We can also drop the clean rule, lib.mk does it for us. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 024cd793bbe1f3a0417f8b1f7a44fe9efc7a0f02 Author: Michael Ellerman Date: Mon Oct 29 22:23:52 2018 +1100 selftests/powerpc/switch_endian: Fix out-of-tree build [ Upstream commit 266bac361d5677e61a6815bd29abeb3bdced2b07 ] For the out-of-tree build to work we need to tell switch_endian_test to look for check-reversed.S in $(OUTPUT). Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit a4a660f7abd984c733b4a6599ef22031e2398146 Author: Joel Stanley Date: Mon Oct 29 22:23:50 2018 +1100 selftests/powerpc/signal: Fix out-of-tree build [ Upstream commit 27825349d7b238533a47e3d98b8bb0efd886b752 ] We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the signal_tm rule to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f74f406bbd0b29d58237a5d14d6cff69e00cf511 Author: Joel Stanley Date: Mon Oct 29 22:23:49 2018 +1100 selftests/powerpc/ptrace: Fix out-of-tree build [ Upstream commit c39b79082a38a4f8c801790edecbbb4d62ed2992 ] We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the ptrace-pkey and core-pkey rules to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 57aab8f0a33d5eab59d2108de0644f209941f39e Author: Joel Stanley Date: Wed Oct 31 11:39:34 2018 +1030 powerpc/xmon: Relax frame size for clang [ Upstream commit 9c87156cce5a63735d1218f0096a65c50a7a32aa ] When building with clang (8 trunk, 7.0 release) the frame size limit is hit: arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576 bytes in function 'xmon_core' [-Wframe-larger-than=] Some investigation by Naveen indicates this is due to clang saving the addresses to printf format strings on the stack. While this issue is investigated, bump up the frame size limit for xmon when building with clang. Link: https://github.com/ClangBuiltLinux/linux/issues/252 Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 32d7474b7a08f432191c9781a05f6ba3585f0db9 Author: Hangbin Liu Date: Fri Oct 26 11:30:35 2018 +0800 ipv4/igmp: fix v1/v2 switchback timeout based on rfc3376, 8.12 [ Upstream commit 966c37f2d77eb44d47af8e919267b1ba675b2eca ] Similiar with ipv6 mcast commit 89225d1ce6af3 ("net: ipv6: mld: fix v1/v2 switchback timeout to rfc3810, 9.12.") i) RFC3376 8.12. Older Version Querier Present Timeout says: The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval. This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval). Currently we only use a hardcode value IGMP_V1/v2_ROUTER_PRESENT_TIMEOUT. Fix it by adding two new items mr_qi(Query Interval) and mr_qri(Query Response Interval) in struct in_device. Now we can calculate the switchback time via (mr_qrv * mr_qi) + mr_qri. We need update these values when receive IGMPv3 queries. Reported-by: Ying Xu Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 691bd94c15b107de103650d0656822fa9b639fa6 Author: Darrick J. Wong Date: Tue Oct 30 10:40:55 2018 +1100 vfs: avoid problematic remapping requests into partial EOF block [ Upstream commit 07d19dc9fbe9128378b9e226abe886fd8fd473df ] A deduplication data corruption is exposed in XFS and btrfs. It is caused by extending the block match range to include the partial EOF block, but then allowing unknown data beyond EOF to be considered a "match" to data in the destination file because the comparison is only made to the end of the source file. This corrupts the destination file when the source extent is shared with it. The VFS remapping prep functions only support whole block dedupe, but we still need to appear to support whole file dedupe correctly. Hence if the dedupe request includes the last block of the souce file, don't include it in the actual dedupe operation. If the rest of the range dedupes successfully, then reject the entire request. A subsequent patch will enable us to shorten dedupe requests correctly. When reflinking sub-file ranges, a data corruption can occur when the source file range includes a partial EOF block. This shares the unknown data beyond EOF into the second file at a position inside EOF, exposing stale data in the second file. If the reflink request includes the last block of the souce file, only proceed with the reflink operation if it lands at or past the destination file's current EOF. If it lands within the destination file EOF, reject the entire request with -EINVAL and make the caller go the hard way. A subsequent patch will enable us to shorten reflink requests correctly. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit cdc45f2047750b511409c1c7b6b7725d902d79a4 Author: Anton Ivanov Date: Tue Sep 25 08:47:13 2018 +0100 um: Make line/tty semantics use true write IRQ [ Upstream commit 917e2fd2c53eb3c4162f5397555cbd394390d4bc ] This fixes a long standing bug where large amounts of output could freeze the tty (most commonly seen on stdio console). While the bug has always been there it became more pronounced after moving to the new interrupt controller. The line semantics are now changed to have true IRQ write semantics which should further improve the tty/line subsystem stability and performance Signed-off-by: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit a17e3bbfb97c3ff7fa297f5193c1310faf6b749f Author: Masahiro Yamada Date: Tue Oct 16 12:01:49 2018 +0900 i2c: uniphier-f: fix race condition when IRQ is cleared [ Upstream commit eaba68785c2d24ebf1f0d46c24e11b79cc2f94c7 ] The current IRQ handler clears all the IRQ status bits when it bails out. This is dangerous because it might clear away the status bits that have just been set while processing the current handler. If this happens, the IRQ event for the latest transfer is lost forever. The IRQ status bits must be cleared *before* the next transfer is kicked. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a118403a5ecce1ba8da834bf1de501402851bc9b Author: Masahiro Yamada Date: Tue Oct 16 12:01:48 2018 +0900 i2c: uniphier-f: fix occasional timeout error [ Upstream commit 39226aaa85f002d695e3cafade3309e12ffdaecd ] Currently, a timeout error could happen at a repeated START condition. For a (non-repeated) START condition, the controller starts sending data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated START condition, the hardware starts running when the slave address is written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is actually unneeded. Because the hardware is already running before the IRQ is enabled for a repeated START, the driver may miss the IRQ event. In most cases, this problem does not show up since modern CPUs are much faster than the I2C transfer. However, it is still possible that a context switch happens after the controller starts, but before the IRQ register is set up. To fix this, - Do not write UNIPHIER_FI2C_CR for repeated START conditions. - Enable IRQ *before* writing the slave address to the TX FIFO. - Disable IRQ for the current CPU while queuing up the TX FIFO; If the CPU is interrupted by some task, the interrupt handler might be invoked due to the empty TX FIFO before completing the setup. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1466eae37a9f867674dceba9c7f17d7e8167456d Author: Masahiro Yamada Date: Tue Oct 16 12:01:47 2018 +0900 i2c: uniphier-f: make driver robust against concurrency [ Upstream commit f1fdcbbdf45d9609f3d4063b67e9ea941ba3a58f ] This is unlikely to happen, but it is possible for a CPU to enter the interrupt handler just after wait_for_completion_timeout() has expired. If this happens, the hardware is accessed from multiple contexts concurrently. Disable the IRQ after wait_for_completion_timeout(), and do nothing from the handler when the IRQ is disabled. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 10807b374663291a3571ba3092a1e2d3ffb7b2b9 Author: Jianchao Wang Date: Sat Oct 27 19:52:14 2018 +0800 block: fix the DISCARD request merge [ Upstream commit 69840466086d2248898020a08dda52732686c4e6 ] There are two cases when handle DISCARD merge. If max_discard_segments == 1, the bios/requests need to be contiguous to merge. If max_discard_segments > 1, it takes every bio as a range and different range needn't to be contiguous. But now, attempt_merge screws this up. It always consider contiguity for DISCARD for the case max_discard_segments > 1 and cannot merge contiguous DISCARD for the case max_discard_segments == 1, because rq_attempt_discard_merge always returns false in this case. This patch fixes both of the two cases above. Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Signed-off-by: Jianchao Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b948d56951be8e8fe169c608cf384f5303ae4d0c Author: Sabrina Dubroca Date: Sun Oct 28 09:33:10 2018 +0100 macsec: let the administrator set UP state even if lowerdev is down [ Upstream commit 07bddef9839378bd6f95b393cf24c420529b4ef1 ] Currently, the kernel doesn't let the administrator set a macsec device up unless its lower device is currently up. This is inconsistent, as a macsec device that is up won't automatically go down when its lower device goes down. Now that linkstate propagation works, there's really no reason for this limitation, so let's remove it. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Reported-by: Radu Rendec Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5bdad7106fc509f27a627a94671ef2dd7136021 Author: Sabrina Dubroca Date: Sun Oct 28 09:33:09 2018 +0100 macsec: update operstate when lower device changes [ Upstream commit e6ac075882b2afcdf2d5ab328ce4ab42a1eb9593 ] Like all other virtual devices (macvlan, vlan), the operstate of a macsec device should match the state of its lower device. This is done by calling netif_stacked_transfer_operstate from its netdevice notifier. We also need to call netif_stacked_transfer_operstate when a new macsec device is created, so that its operstate is set properly. This is only relevant when we try to bring the device up directly when we create it. Radu Rendec proposed a similar patch, inspired from the 802.1q driver, that included changing the administrative state of the macsec device, instead of just the operstate. This version is similar to what the macvlan driver does, and updates only the operstate. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Reported-by: Radu Rendec Reported-by: Patrick Talbert Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4291e97c69f658d3d6ba1720d3c2fc820a1721aa Author: Andrea Arcangeli Date: Fri Oct 26 15:10:36 2018 -0700 mm: thp: fix MADV_DONTNEED vs migrate_misplaced_transhuge_page race condition [ Upstream commit d7c3393413fe7e7dc54498ea200ea94742d61e18 ] Patch series "migrate_misplaced_transhuge_page race conditions". Aaron found a new instance of the THP MADV_DONTNEED race against pmdp_clear_flush* variants, that was apparently left unfixed. While looking into the race found by Aaron, I may have found two more issues in migrate_misplaced_transhuge_page. These race conditions would not cause kernel instability, but they'd corrupt userland data or leave data non zero after MADV_DONTNEED. I did only minor testing, and I don't expect to be able to reproduce this (especially the lack of ->invalidate_range before migrate_page_copy, requires the latest iommu hardware or infiniband to reproduce). The last patch is noop for x86 and it needs further review from maintainers of archs that implement flush_cache_range() (not in CC yet). To avoid confusion, it's not the first patch that introduces the bug fixed in the second patch, even before removing the pmdp_huge_clear_flush_notify, that _notify suffix was called after migrate_page_copy already run. This patch (of 3): This is a corollary of ced108037c2aa ("thp: fix MADV_DONTNEED vs. numa balancing race"), 58ceeb6bec8 ("thp: fix MADV_DONTNEED vs. MADV_FREE race") and 5b7abeae3af8c ("thp: fix MADV_DONTNEED vs clear soft dirty race). When the above three fixes where posted Dave asked https://lkml.kernel.org/r/929b3844-aec2-0111-fef7-8002f9d4e2b9@intel.com but apparently this was missed. The pmdp_clear_flush* in migrate_misplaced_transhuge_page() was introduced in a54a407fbf7 ("mm: Close races between THP migration and PMD numa clearing"). The important part of such commit is only the part where the page lock is not released until the first do_huge_pmd_numa_page() finished disarming the pagenuma/protnone. The addition of pmdp_clear_flush() wasn't beneficial to such commit and there's no commentary about such an addition either. I guess the pmdp_clear_flush() in such commit was added just in case for safety, but it ended up introducing the MADV_DONTNEED race condition found by Aaron. At that point in time nobody thought of such kind of MADV_DONTNEED race conditions yet (they were fixed later) so the code may have looked more robust by adding the pmdp_clear_flush(). This specific race condition won't destabilize the kernel, but it can confuse userland because after MADV_DONTNEED the memory won't be zeroed out. This also optimizes the code and removes a superfluous TLB flush. [akpm@linux-foundation.org: reflow comment to 80 cols, fix grammar and typo (beacuse)] Link: http://lkml.kernel.org/r/20181013002430.698-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli Reported-by: Aaron Tomlin Acked-by: Mel Gorman Acked-by: Kirill A. Shutemov Cc: Jerome Glisse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ac1cad79bcad463ff2c886abf613dd0bc273ac3f Author: Keith Busch Date: Fri Oct 26 15:09:59 2018 -0700 tools/testing/selftests/vm/gup_benchmark.c: fix 'write' flag usage [ Upstream commit 319e0bec1aecb36c5ac6d23812af487ff2c8f47f ] If the '-w' parameter was provided, the benchmark would exit due to a mssing 'break'. Link: http://lkml.kernel.org/r/20181010195605.10689-3-keith.busch@intel.com Signed-off-by: Keith Busch Acked-by: Kirill A. Shutemov Reviewed-by: Andrew Morton Cc: Dave Hansen Cc: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2d9d6c099eaf91523c7f73ec84c523afd196b18f Author: Dave Chinner Date: Fri Oct 26 15:09:45 2018 -0700 mm/page-writeback.c: fix range_cyclic writeback vs writepages deadlock [ Upstream commit 64081362e8ff4587b4554087f3cfc73d3e0a4cd7 ] We've recently seen a workload on XFS filesystems with a repeatable deadlock between background writeback and a multi-process application doing concurrent writes and fsyncs to a small range of a file. range_cyclic writeback Process 1 Process 2 xfs_vm_writepages write_cache_pages writeback_index = 2 cycled = 0 .... find page 2 dirty lock Page 2 ->writepage page 2 writeback page 2 clean page 2 added to bio no more pages write() locks page 1 dirties page 1 locks page 2 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 find page 1 towrite lock Page 1 ->writepage page 1 writeback page 1 clean page 1 added to bio find page 2 towrite lock Page 2 page 2 is writeback write() locks page 1 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 !done && !cycled sets index to 0, restarts lookup find page 1 dirty find page 1 towrite lock Page 1 page 1 is writeback lock Page 1 DEADLOCK because: - process 1 needs page 2 writeback to complete to make enough progress to issue IO pending for page 1 - writeback needs page 1 writeback to complete so process 2 can progress and unlock the page it is blocked on, then it can issue the IO pending for page 2 - process 2 can't make progress until process 1 issues IO for page 1 The underlying cause of the problem here is that range_cyclic writeback is processing pages in descending index order as we hold higher index pages in a structure controlled from above write_cache_pages(). The write_cache_pages() caller needs to be able to submit these pages for IO before write_cache_pages restarts writeback at mapping index 0 to avoid wcp inverting the page lock/writeback wait order. generic_writepages() is not susceptible to this bug as it has no private context held across write_cache_pages() - filesystems using this infrastructure always submit pages in ->writepage immediately and so there is no problem with range_cyclic going back to mapping index 0. However: mpage_writepages() has a private bio context, exofs_writepages() has page_collect fuse_writepages() has fuse_fill_wb_data nfs_writepages() has nfs_pageio_descriptor xfs_vm_writepages() has xfs_writepage_ctx All of these ->writepages implementations can hold pages under writeback in their private structures until write_cache_pages() returns, and hence they are all susceptible to this deadlock. Also worth noting is that ext4 has it's own bastardised version of write_cache_pages() and so it /may/ have an equivalent deadlock. I looked at the code long enough to understand that it has a similar retry loop for range_cyclic writeback reaching the end of the file and then promptly ran away before my eyes bled too much. I'll leave it for the ext4 developers to determine if their code is actually has this deadlock and how to fix it if it has. There's a few ways I can see avoid this deadlock. There's probably more, but these are the first I've though of: 1. get rid of range_cyclic altogether 2. range_cyclic always stops at EOF, and we start again from writeback index 0 on the next call into write_cache_pages() 2a. wcp also returns EAGAIN to ->writepages implementations to indicate range cyclic has hit EOF. writepages implementations can then flush the current context and call wpc again to continue. i.e. lift the retry into the ->writepages implementation 3. range_cyclic uses trylock_page() rather than lock_page(), and it skips pages it can't lock without blocking. It will already do this for pages under writeback, so this seems like a no-brainer 3a. all non-WB_SYNC_ALL writeback uses trylock_page() to avoid blocking as per pages under writeback. I don't think #1 is an option - range_cyclic prevents frequently dirtied lower file offset from starving background writeback of rarely touched higher file offsets. #2 is simple, and I don't think it will have any impact on performance as going back to the start of the file implies an immediate seek. We'll have exactly the same number of seeks if we switch writeback to another inode, and then come back to this one later and restart from index 0. #2a is pretty much "status quo without the deadlock". Moving the retry loop up into the wcp caller means we can issue IO on the pending pages before calling wcp again, and so avoid locking or waiting on pages in the wrong order. I'm not convinced we need to do this given that we get the same thing from #2 on the next writeback call from the writeback infrastructure. #3 is really just a band-aid - it doesn't fix the access/wait inversion problem, just prevents it from becoming a deadlock situation. I'd prefer we fix the inversion, not sweep it under the carpet like this. #3a is really an optimisation that just so happens to include the band-aid fix of #3. So it seems that the simplest way to fix this issue is to implement solution #2 Link: http://lkml.kernel.org/r/20181005054526.21507-1-david@fromorbit.com Signed-off-by: Dave Chinner Reviewed-by: Jan Kara Cc: Nicholas Piggin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bcba80f38a003f0cfcebb8502ab81cb043a68977 Author: Jia-Ju Bai Date: Fri Oct 26 15:02:52 2018 -0700 fs/ocfs2/dlm/dlmdebug.c: fix a sleep-in-atomic-context bug in dlm_print_one_mle() [ Upstream commit 999865764f5f128896402572b439269acb471022 ] The kernel module may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 255: __dlm_put_mle in dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 254: spin_lock in dlm_put_ml [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 222: __dlm_put_mle in dlm_put_mle_inuse fs/ocfs2/dlm/dlmmaster.c, 219: spin_lock in dlm_put_mle_inuse To fix this bug, GFP_NOFS is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Link: http://lkml.kernel.org/r/20180901112528.27025-1-baijiaju1990@gmail.com Signed-off-by: Jia-Ju Bai Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 99b3146b799ab983b1b639334dd0a2eba40844ca Author: Andrey Ryabinin Date: Fri Oct 26 15:02:30 2018 -0700 arm64: lib: use C string functions with KASAN enabled [ Upstream commit 19a2ca0fb560fd7be7b5293c6b652c6d6078dcde ] ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(), str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm code, thus it can potentially miss many bugs. Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is enabled, so the generic implementations from lib/string.c will be used. We can't just remove the asm functions because efistub uses them. And we can't have two non-weak functions either, so declare the asm functions as weak. Link: http://lkml.kernel.org/r/20180920135631.23833-2-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Reported-by: Kyeongdon Kim Cc: Alexander Potapenko Cc: Ard Biesheuvel Cc: Dmitry Vyukov Cc: Mark Rutland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b84e965c7edb55405956dbbec93a0754a97c4526 Author: David S. Miller Date: Fri Oct 26 15:39:49 2018 -0700 sparc64: Rework xchg() definition to avoid warnings. [ Upstream commit 6c2fc9cddc1ffdef8ada1dc8404e5affae849953 ] Such as: fs/ocfs2/file.c: In function ‘ocfs2_file_write_iter’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) and drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_xdp_setup’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e4cad4365e0e2458c0ae48b2a9c8c0f0207f31f Author: Felipe Rechia Date: Wed Oct 24 10:57:22 2018 -0300 powerpc/process: Fix flush_all_to_thread for SPE [ Upstream commit e901378578c62202594cba0f6c076f3df365ec91 ] Fix a bug introduced by the creation of flush_all_to_thread() for processors that have SPE (Signal Processing Engine) and use it to compute floating-point operations. >From userspace perspective, the problem was seen in attempts of computing floating-point operations which should generate exceptions. For example: fork(); float x = 0.0 / 0.0; isnan(x); // forked process returns False (should be True) The operation above also should always cause the SPEFSCR FINV bit to be set. However, the SPE floating-point exceptions were turned off after a fork(). Kernel versions prior to the bug used flush_spe_to_thread(), which first saves SPEFSCR register values in tsk->thread and then calls giveup_spe(tsk). After commit 579e633e764e, the save_all() function was called first to giveup_spe(), and then the SPEFSCR register values were saved in tsk->thread. This would save the SPEFSCR register values after disabling SPE for that thread, causing the bug described above. Fixes 579e633e764e ("powerpc: create flush_all_to_thread()") Signed-off-by: Felipe Rechia Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 54299e1cf3793df8fe266dac00f7083b1378b08f Author: Martin Lau Date: Wed Oct 24 20:42:25 2018 +0000 bpf, btf: fix a missing check bug in btf_parse [ Upstream commit 4a6998aff82a20a1aece86a186d8e5263f8b2315 ] Wenwen Wang reported: In btf_parse(), the header of the user-space btf data 'btf_data' is firstly parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then verified. If no error happens during the verification process, the whole data of 'btf_data', including the header, is then copied to 'data' in btf_parse(). It is obvious that the header is copied twice here. More importantly, no check is enforced after the second copy to make sure the headers obtained in these two copies are same. Given that 'btf_data' resides in the user space, a malicious user can race to modify the header between these two copies. By doing so, the user can inject inconsistent data, which can cause undefined behavior of the kernel and introduce potential security risk. This issue is similar to the one fixed in commit 8af03d1ae2e1 ("bpf: btf: Fix a missing check bug"). To fix it, this patch copies the user 'btf_data' *before* parsing / verifying the BTF header. Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)") Signed-off-by: Martin KaFai Lau Co-developed-by: Wenwen Wang Acked-by: Song Liu Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 8044e741eee42db4a08f1d284144ef2d482996be Author: Taehee Yoo Date: Wed Oct 24 20:15:17 2018 +0900 bpf: devmap: fix wrong interface selection in notifier_call [ Upstream commit f592f804831f1cf9d1f9966f58c80f150e6829b5 ] The dev_map_notification() removes interface in devmap if unregistering interface's ifindex is same. But only checking ifindex is not enough because other netns can have same ifindex. so that wrong interface selection could occurred. Hence netdev pointer comparison code is added. v2: compare netdev pointer instead of using net_eq() (Daniel Borkmann) v1: Initial patch Fixes: 2ddf71e23cc2 ("net: add notifier hooks for devmap bpf map") Signed-off-by: Taehee Yoo Acked-by: Song Liu Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 7b557dbdc51947b92dcfe8f13d6fd59d2353d2d9 Author: Tristram Ha Date: Wed Oct 24 14:51:23 2018 -0700 net: ethernet: cadence: fix socket buffer corruption problem [ Upstream commit 899ecaedd15599c22553d158f53b127cc1632dc2 ] Socket buffer is not re-created when headroom is 2 and tailroom is 1. Signed-off-by: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3681b901e94a18e9fbe505f4c7f34536c931ce92 Author: Geert Uytterhoeven Date: Fri Oct 12 09:20:15 2018 +0200 thermal: rcar_thermal: Prevent hardware access during system suspend [ Upstream commit 3a31386217628ffe2491695be2db933c25dde785 ] On r8a7791/koelsch, sometimes the following message is printed during system suspend: rcar_thermal e61f0000.thermal: thermal sensor was broken This happens if the workqueue runs while the device is already suspended. Fix this by using the freezable system workqueue instead, cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from happening during system suspend"). Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 436e610bf195a59a9d5b1c47a75a8ebdd1f250bb Author: Sergei Shtylyov Date: Wed Oct 3 23:47:34 2018 +0300 thermal: rcar_thermal: fix duplicate IRQ request [ Upstream commit df016bbba63743bbef9ff5c6c282561211dd72cc ] The driver on R8A77995 requests the same IRQ twice since platform_get_resource() is always called for the 1st IRQ resource. Fixes: 1969d9dc2079 ("thermal: rcar_thermal: add r8a77995 support") Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Reviewed-by: Daniel Lezcano Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 51aa1a10fbac2faabcee67b882ca5bf8129cb1bb Author: Peng Hao Date: Fri Oct 12 03:53:50 2018 +0800 selftests: fix warning: "_GNU_SOURCE" redefined [ Upstream commit 0387662d1b6c5ad2950d8e94d5e380af3f15c05c ] Makefile contains -D_GNU_SOURCE. remove define "_GNU_SOURCE" in c files. Signed-off-by: Peng Hao Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit c62be4108883a7aee896e4e1417a1e00cf0bb89a Author: Andrea Parri Date: Tue Oct 16 16:13:46 2018 +0200 selftests: kvm: Fix -Wformat warnings [ Upstream commit fb363e2d20351e1d16629df19e7bce1a31b3227a ] Fixes the following warnings: dirty_log_test.c: In function ‘help’: dirty_log_test.c:216:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -i: specify iteration counts (default: %"PRIu64")\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" dirty_log_test.c:218:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -I: specify interval in ms (default: %"PRIu64" ms)\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" Signed-off-by: Andrea Parri Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 5802cb25de861943f88e96eb43a9aaf42544fb5b Author: Jerry Hoemann Date: Wed Sep 26 15:23:08 2018 -0600 selftests: watchdog: Fix error message. [ Upstream commit 04d5e4bd37516ad60854eb74592c7dbddd75d277 ] Printf's say errno but print the string version of error. Make consistent. Signed-off-by: Jerry Hoemann Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 74685702363cc13dac2915bf47b49fa18627c666 Author: Shuah Khan (Samsung OSG) Date: Wed Sep 26 13:07:11 2018 -0600 selftests: watchdog: fix message when /dev/watchdog open fails [ Upstream commit 9a244229a4b850b11952a0df79607c69b18fd8df ] When /dev/watchdog open fails, watchdog exits with "watchdog not enabled" message. This is incorrect when open fails due to insufficient privilege. Fix message to clearly state the reason when open fails with EACCESS when a non-root user runs it. Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 58ceffabad41aaab4dcf68490b10133344a2377e Author: Masami Hiramatsu Date: Thu Aug 30 23:16:13 2018 +0900 selftests/ftrace: Fix to test kprobe $comm arg only if available [ Upstream commit 2452c96e617a0ff6fb2692e55217a3fa57a7322c ] Test $comm in kprobe-event argument syntax testcase only if it is supported on the kernel because $comm has been introduced 4.8 kernel. So on older stable kernel, it should be skipped. Signed-off-by: Masami Hiramatsu Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit adcb6d9ff121bcff8365ab42321d71fbed4725ea Author: Keiji Hayashibara Date: Wed Oct 24 18:34:29 2018 +0900 spi: uniphier: fix incorrect property items [ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ] This commit fixes incorrect property because it was different from the actual. The parameters of '#address-cells' and '#size-cells' were removed, and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added. Fixes: 4dcd5c2781f3 ("spi: add DT bindings for UniPhier SPI controller") Signed-off-by: Keiji Hayashibara Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c2075f792c6bf10809577bec6cf8d0d347ba056 Author: Garry McNulty Date: Wed Oct 3 20:51:21 2018 +0100 fs/cifs: fix uninitialised variable warnings [ Upstream commit ef2298a06d012973bbc592b86fe5ff730d4d0c63 ] In some error conditions, resp_buftype can be passed uninitialised to free_rsp_buf(), potentially resulting in a spurious debug message. If resp_buftype randomly had the value 1 (CIFS_SMALL_BUFFER) then this would log a debug message. The rsp pointer is initialised to NULL so there is no other side-effect. Detected by CoverityScan, CID 1438585 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438667 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438764 ("Uninitialized scalar variable") Signed-off-by: Garry McNulty Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Signed-off-by: Sasha Levin commit c5621fbd656077c2d888d341059ce5a180c906bd Author: Masahisa Kojima Date: Tue Oct 23 20:24:26 2018 +0900 net: socionext: Stop PHY before resetting netsec [ Upstream commit 8e850f25b5812aefedec6732732eb10e7b47cb5c ] In ndo_stop, driver resets the netsec ethernet controller IP. When the netsec IP is reset, HW running mode turns to NRM mode and driver has to wait until this mode transition completes. But mode transition to NRM will not complete if the PHY is in normal operation state. Netsec IP requires PHY is in power down state when it is reset. This modification stops the PHY before resetting netsec. Together with this modification, phy_addr is stored in netsec_priv structure because ndev->phydev is not yet ready in ndo_init. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Masahisa Kojima Signed-off-by: Yoshitoyo Osaki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a6fa6119ab178a50dfb8c82921bac54b2982d56 Author: Marek Szyprowski Date: Wed Sep 5 13:54:07 2018 +0200 mfd: max8997: Enale irq-wakeup unconditionally [ Upstream commit efddff27c886e729a7f84a7205bd84d7d4af7336 ] IRQ wake up support for MAX8997 driver was initially configured by respective property in pdata. However, after the driver conversion to device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD drivers initialized from device-tree assume that they can be an irq wakeup source, so enable it also for MAX8997. This fixes support for wakeup from MAX8997 RTC alarm. Signed-off-by: Marek Szyprowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5a04242e8c2357dfb3dd0af4dbca24c5e0aa774a Author: Andy Shevchenko Date: Thu Aug 30 19:52:52 2018 +0300 mfd: intel_soc_pmic_bxtwc: Chain power button IRQs as well [ Upstream commit 9f8ddee1dab836ca758ca8fc555ab5a3aaa5d3fd ] Power button IRQ actually has a second level of interrupts to distinguish between UI and POWER buttons. Moreover, current implementation looks awkward in approach to handle second level IRQs by first level related IRQ chip. To address above issues, split power button IRQ to be chained as well. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit dd72391c9a5380a96351e9dba7a0a7cf7fd23a39 Author: Fabio Estevam Date: Tue Aug 28 17:02:40 2018 -0300 mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values [ Upstream commit 55143439b7b501882bea9d95a54adfe00ffc79a3 ] When trying to read any MC13892 ADC channel on a imx51-babbage board: The MC13892 PMIC shutdowns completely. After debugging this issue and comparing the MC13892 and MC13783 initializations done in the vendor kernel, it was noticed that the CHRGRAWDIV bit of the ADC0 register was not being set. This bit is set by default after power on, but the driver was clearing it. After setting this bit it is possible to read the ADC values correctly. Signed-off-by: Fabio Estevam Tested-by: Chris Healy Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 02c9ec11860f217006bc04c16d960cdba8de1c23 Author: Sapthagiri Baratam Date: Tue Aug 21 19:52:44 2018 +0530 mfd: arizona: Correct calling of runtime_put_sync [ Upstream commit 6b269a41a4520f7eb639e61a45ebbb9c9267d5e0 ] Don't call runtime_put_sync when clk32k_ref is ARIZONA_32KZ_MCLK2 as there is no corresponding runtime_get_sync call. MCLK1 is not in the AoD power domain so if it is used as 32kHz clock source we need to hold a runtime PM reference to keep the device from going into low power mode. Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks") Signed-off-by: Sapthagiri Baratam Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e79d230832d02e4783df5fc62ad7c8752fe846c4 Author: Ivan Khoronzhuk Date: Mon Oct 22 21:51:36 2018 +0300 net: ethernet: ti: cpsw: unsync mcast entries while switch promisc mode [ Upstream commit 9737cc99dd14b5b8b9d267618a6061feade8ea68 ] After flushing all mcast entries from the table, the ones contained in mc list of ndev are not restored when promisc mode is toggled off, because they are considered as synched with ALE, thus, in order to restore them after promisc mode - reset syncing info. This fix touches only switch mode devices, including single port boards like Beagle Bone. Fixes: commit 5da1948969bc ("net: ethernet: ti: cpsw: fix lost of mcast packets while rx_mode update") Signed-off-by: Ivan Khoronzhuk Reviewed-by: Grygorii Strashko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c011435110f150abba12ab187c131fa902e2520 Author: Dan Carpenter Date: Fri Oct 19 23:11:11 2018 +0300 qlcnic: fix a return in qlcnic_dcb_get_capability() [ Upstream commit c94f026fb742b2d3199422751dbc4f6fc0e753d8 ] These functions are supposed to return one on failure and zero on success. Returning a zero here could cause uninitialized variable bugs in several of the callers. For example: drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:1660 get_iscsi_dcb_priority() error: uninitialized symbol 'caps'. Fixes: 48365e485275 ("qlcnic: dcb: Add support for CEE Netlink interface.") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 321c40dce58185672882e9250ce333eec1f91886 Author: Nathan Chancellor Date: Fri Oct 19 11:00:30 2018 -0700 mISDN: Fix type of switch control variable in ctrl_teimanager [ Upstream commit aeb5e02aca91522733eb1db595ac607d30c87767 ] Clang warns (trimmed for brevity): drivers/isdn/mISDN/tei.c:1193:7: warning: overflow converting case value to switch condition type (2147764552 to 18446744071562348872) [-Wswitch] case IMHOLD_L1: ^ drivers/isdn/mISDN/tei.c:1187:7: warning: overflow converting case value to switch condition type (2147764550 to 18446744071562348870) [-Wswitch] case IMCLEAR_L2: ^ 2 warnings generated. The root cause is that the _IOC macro can generate really large numbers, which don't find into type int. My research into how GCC and Clang are handling this at a low level didn't prove fruitful and surveying the kernel tree shows that aside from here and a few places in the scsi subsystem, everything that uses _IOC is at least of type 'unsigned int'. Make that change here because as nothing in this function cares about the signedness of the variable and it removes ambiguity, which is never good when dealing with compilers. While we're here, remove the unnecessary local variable ret (just return -EINVAL and 0 directly). Link: https://github.com/ClangBuiltLinux/linux/issues/67 Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 074af1668038e5743bddb413681e345d632e7a97 Author: Chao Yu Date: Sun Oct 7 19:06:15 2018 +0800 f2fs: spread f2fs_set_inode_flags() [ Upstream commit 9149a5eb606152df158eb7d7da5a34e84b574189 ] This patch changes codes as below: - use f2fs_set_inode_flags() to update i_flags atomically to avoid potential race. - synchronize F2FS_I(inode)->i_flags to inode->i_flags in f2fs_new_inode(). - use f2fs_set_inode_flags() to simply codes in f2fs_quota_{on,off}. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e7f81efae3b5c90684a83dc95aab1ba5c8c7b7cf Author: Chao Yu Date: Fri Jul 27 18:15:16 2018 +0800 f2fs: fix to spread clear_cold_data() [ Upstream commit 2baf07818549c8bb8d7b3437e889b86eab56d38e ] We need to drop PG_checked flag on page as well when we clear PG_uptodate flag, in order to avoid treating the page as GCing one later. Signed-off-by: Weichao Guo Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 733fddc346515d1d44c577efa7d36cb02fb57a3f Author: Dan Carpenter Date: Wed Sep 19 13:35:00 2018 +0300 thermal: armada: fix a test in probe() [ Upstream commit d1d2c290b3c04b65fa6132eeebe50a070746d8f6 ] The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Fixes: 3d4e51844a4e ("thermal: armada: convert driver to syscon register accesses") Signed-off-by: Dan Carpenter Reviewed-by: Miquel Raynal Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit bb925b9bece25e3c53fb06dc0cbcc4f3e40b196e Author: Vincent Chen Date: Tue Oct 2 16:52:31 2018 +0800 RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap [ Upstream commit 827a438156e4c423b6875a092e272933952a2910 ] For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by: Vincent Chen Reviewed-by: Christoph Hellwig Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 829aa617bf6e061964a724d48a2cb892752fa5ef Author: Nathan Chancellor Date: Fri Oct 19 13:43:45 2018 -0700 rtc: s35390a: Change buf's type to u8 in s35390a_init [ Upstream commit ef0f02fd69a02b50e468a4ddbe33e3d81671e248 ] Clang warns: drivers/rtc/rtc-s35390a.c:124:27: warning: implicit conversion from 'int' to 'char' changes value from 192 to -64 [-Wconstant-conversion] buf = S35390A_FLAG_RESET | S35390A_FLAG_24H; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ 1 warning generated. Update buf to be an unsigned 8-bit integer, which matches the buf member in struct i2c_msg. https://github.com/ClangBuiltLinux/linux/issues/145 Signed-off-by: Nathan Chancellor Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8112f3d4ed036ca5caacecad23e31e805fb93ec6 Author: Luis Henriques Date: Tue Oct 9 18:54:28 2018 +0100 ceph: only allow punch hole mode in fallocate [ Upstream commit bddff633ab7bc60a18a86ac8b322695b6f8594d0 ] Current implementation of cephfs fallocate isn't correct as it doesn't really reserve the space in the cluster, which means that a subsequent call to a write may actually fail due to lack of space. In fact, it is currently possible to fallocate an amount space that is larger than the free space in the cluster. It has behaved this way since the initial commit ad7a60de882a ("ceph: punch hole support"). Since there's no easy solution to fix this at the moment, this patch simply removes support for all fallocate operations but FALLOC_FL_PUNCH_HOLE (which implies FALLOC_FL_KEEP_SIZE). Link: https://tracker.ceph.com/issues/36317 Signed-off-by: Luis Henriques Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 146fb4b0d4fe8a35e3cc28cd7a9fa69a5d1ee8ab Author: Yan, Zheng Date: Fri Sep 28 09:10:29 2018 +0800 ceph: fix dentry leak in ceph_readdir_prepopulate [ Upstream commit c58f450bd61511d897efc2ea472c69630635b557 ] Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 083757d848597e5e33528c931751ceb8a98bc6c0 Author: Quentin Monnet Date: Sat Oct 20 23:01:50 2018 +0100 tools: bpftool: fix completion for "bpftool map update" [ Upstream commit fe8ecccc10b3adc071de05ca7af728ca1a4ac9aa ] When trying to complete "bpftool map update" commands, the call to printf would print an error message that would show on the command line if no map is found to complete the command line. Fix it by making sure we have map ids to complete the line with, before we try to print something. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 570c05378d971ab29e6e67500c8b0e6fdd19dc93 Author: Quentin Monnet Date: Sat Oct 20 22:58:44 2018 +0100 selftests/bpf: fix return value comparison for tests in test_libbpf.sh [ Upstream commit c5fa5d602221362f8341ecd9e32d83194abf5bd9 ] The return value for each test in test_libbpf.sh is compared with if (( $? == 0 )) ; then ... This works well with bash, but not with dash, that /bin/sh is aliased to on some systems (such as Ubuntu). Let's replace this comparison by something that works on both shells. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3173e226ca412a80267f471ce173e326895198df Author: Nicholas Piggin Date: Tue Aug 28 18:11:27 2018 +1000 powerpc/64s/radix: Fix radix__flush_tlb_collapsed_pmd double flushing pmd [ Upstream commit dd76ff5af35350fd6d5bb5b069e73b6017f66893 ] Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b43c5287f6bca1bfaef43326130515c1256856ff Author: Michael Ellerman Date: Tue Aug 14 21:05:20 2018 +1000 powerpc/mm/radix: Fix small page at boundary when splitting [ Upstream commit 81d1b54dec95209ab5e5be2cf37182885f998753 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we want to split the linear mapping at the text/data boundary so we can map the kernel text read only. Currently we always use a small page at the text/data boundary, even when that's not necessary: Mapped 0x0000000000000000-0x0000000000e00000 with 2.00 MiB pages Mapped 0x0000000000e00000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages This is because the check that the mapping crosses the __init_begin boundary is too strict, it also returns true when we map exactly up to the boundary. So fix it to check that the mapping would actually map past __init_begin, and with that we see: Mapped 0x0000000000000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b499fa070ee4827931c443811a08cced55f8f00a Author: Michael Ellerman Date: Tue Aug 14 20:48:22 2018 +1000 powerpc/mm/radix: Fix overuse of small pages in splitting logic [ Upstream commit 3b5657ed5b4e27ccf593a41ff3c5aa27dae8df18 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we want to split the linear mapping at the text/data boundary so we can map the kernel text read only. But the current logic uses small pages for the entire text section, regardless of whether a larger page size would fit. eg. with the boundary at 16M we could use 2M pages, but instead we use 64K pages up to the 16M boundary: Mapped 0x0000000000000000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages This is because the test is checking if addr is < __init_begin and addr + mapping_size is >= _stext. But that is true for all pages between _stext and __init_begin. Instead what we want to check is if we are crossing the text/data boundary, which is at __init_begin. With that fixed we see: Mapped 0x0000000000000000-0x0000000000e00000 with 2.00 MiB pages Mapped 0x0000000000e00000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages ie. we're correctly using 2MB pages below __init_begin, but we still drop down to 64K pages unnecessarily at the boundary. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 434551e9fd4485b18df07c8566fb2df59105dcc0 Author: Michael Ellerman Date: Fri Aug 10 22:29:26 2018 +1000 powerpc/mm/radix: Fix off-by-one in split mapping logic [ Upstream commit 5c6499b7041b43807dfaeda28aa87fc0e62558f7 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we try to split the kernel linear (1:1) mapping so that the kernel text is in a separate page to kernel data, so we can mark the former read-only. We could achieve that just by always using 64K pages for the linear mapping, but we try to be smarter. Instead we use huge pages when possible, and only switch to smaller pages when necessary. However we have an off-by-one bug in that logic, which causes us to calculate the wrong boundary between text and data. For example with the end of the kernel text at 16M we see: radix-mmu: Mapped 0x0000000000000000-0x0000000001200000 with 64.0 KiB pages radix-mmu: Mapped 0x0000000001200000-0x0000000040000000 with 2.00 MiB pages radix-mmu: Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages ie. we mapped from 0 to 18M with 64K pages, even though the boundary between text and data is at 16M. With the fix we see we're correctly hitting the 16M boundary: radix-mmu: Mapped 0x0000000000000000-0x0000000001000000 with 64.0 KiB pages radix-mmu: Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages radix-mmu: Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ee35e01b0f08affff2c03dbd1c1f11bababf908e Author: Aravinda Prasad Date: Tue Oct 16 17:20:05 2018 +0530 powerpc/pseries: Export raw per-CPU VPA data via debugfs [ Upstream commit c6c26fb55e8e4b3fc376be5611685990a17de27a ] This patch exports the raw per-CPU VPA data via debugfs. A per-CPU file is created which exports the VPA data of that CPU to help debug some of the VPA related issues or to analyze the per-CPU VPA related statistics. v3: Removed offline CPU check. v2: Included offline CPU check and other review comments. Signed-off-by: Aravinda Prasad Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 9ed143cf730d6a13415da0a6a3456560bb4bc6cf Author: Gustavo A. R. Silva Date: Thu Oct 18 18:59:39 2018 +0200 scsi: hisi_sas: Fix NULL pointer dereference [ Upstream commit f4445bb93d82a984657b469e63118c2794a4c3d3 ] There is a NULL pointer dereference in case *slot* happens to be NULL at lines 1053 and 1878: struct hisi_sas_cq *cq = &hisi_hba->cq[slot->dlvry_queue]; Notice that *slot* is being NULL checked at lines 1057 and 1881: if (slot), which implies it may be NULL. Fix this by placing the declaration and definition of variable cq, which contains the pointer dereference slot->dlvry_queue, after slot has been properly NULL checked. Addresse