1. 18 12月, 2019 40 次提交
    • G
      Linux 4.19.90 · 7d120bf2
      Greg Kroah-Hartman 提交于
      7d120bf2
    • E
      of: unittest: fix memory leak in attach_node_and_children · b65a9b44
      Erhard Furtner 提交于
      [ 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: NErhard Furtner <erhard_f@mailbox.org>
      Reviewed-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NTyrel Datwyler <tyreld@linux.ibm.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b65a9b44
    • K
      scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane) · e62b2baf
      Kars de Jong 提交于
      [ 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.orgSigned-off-by: NKars de Jong <jongk@linux-m68k.org>
      Reviewed-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e62b2baf
    • M
      idr: Fix idr_get_next_ul race with idr_remove · 0cec640d
      Matthew Wilcox (Oracle) 提交于
      [ 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: NMatthew Wilcox (Oracle) <willy@infradead.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0cec640d
    • J
      iio: imu: mpu6050: add missing available scan masks · 052d878c
      Jean-Baptiste Maneyrol 提交于
      [ 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: NJean-Baptiste Maneyrol <jmaneyrol@invensense.com>
      Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602")
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      052d878c
    • R
      scsi: qla2xxx: Change discovery state before PLOGI · 89f3ac7e
      Roman Bolshakov 提交于
      [ 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: 8777e431 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")
      Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag")
      Cc: Quinn Tran <qutran@marvell.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191125165702.1013-6-r.bolshakov@yadro.comAcked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Tested-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NRoman Bolshakov <r.bolshakov@yadro.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      89f3ac7e
    • G
      raid5: need to set STRIPE_HANDLE for batch head · a40982c7
      Guoqing Jiang 提交于
      [ 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: NXiao Ni <xni@redhat.com>
      Tested-by: NXiao Ni <xni@redhat.com>
      Signed-off-by: NGuoqing Jiang <guoqing.jiang@cloud.ionos.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a40982c7
    • H
      gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist · 2de65064
      Hans de Goede 提交于
      [ 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: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2de65064
    • P
      cifs: Fix potential softlockups while refreshing DFS cache · 14cb20ad
      Paulo Alcantara (SUSE) 提交于
      [ 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: NPaulo Alcantara (SUSE) <pc@cjr.nz>
      Suggested-by: NAurelien Aptel <aaptel@suse.com>
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      14cb20ad
    • K
      kernel/module.c: wakeup processes in module_wq on module unload · 12c88d91
      Konstantin Khorenko 提交于
      [ 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: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NKonstantin Khorenko <khorenko@virtuozzo.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      12c88d91
    • F
      of: overlay: add_changeset_property() memory leak · 0773dcee
      Frank Rowand 提交于
      [ 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: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Tested-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0773dcee
    • B
      gfs2: fix glock reference problem in gfs2_trans_remove_revoke · 0809e108
      Bob Peterson 提交于
      [ 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: NBob Peterson <rpeterso@redhat.com>
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0809e108
    • Y
      PCI: rcar: Fix missing MACCTLR register setting in initialization sequence · 2de11b2e
      Yoshihiro Shimoda 提交于
      [ 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: NEugeniu Rosca <erosca@de.adit-jv.com>
      Fixes: c25da477 ("PCI: rcar: Add Renesas R-Car PCIe driver")
      Fixes: be20bbcb0a8c ("PCI: rcar: Add the initialization of PCIe link in resume_noirq()")
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: <stable@vger.kernel.org> # v5.2+
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2de11b2e
    • M
      leds: trigger: netdev: fix handling on interface rename · f1fd9d0b
      Martin Schiller 提交于
      [ 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: 06f502f5 ("leds: trigger: Introduce a NETDEV trigger")
      Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename")
      Signed-off-by: NMartin Schiller <ms@dev.tdt.de>
      Signed-off-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f1fd9d0b
    • E
      net/mlx5e: Fix SFF 8472 eeprom length · 935f3980
      Eran Ben Elisha 提交于
      [ 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: NEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: NAya Levin <ayal@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      935f3980
    • P
      sunrpc: fix crash when cache_head become valid before update · 67256225
      Pavel Tikhomirov 提交于
      [ 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: [<ffffffffc01f79eb>] 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:[<ffffffffc01f79eb>]  [<ffffffffc01f79eb>] 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]  [<ffffffff8a2c78b4>] ? groups_alloc+0x34/0x110
      [13108726.344837]  [<ffffffffc01f5eb4>] svc_set_client+0x24/0x30 [sunrpc]
      [13108726.346631]  [<ffffffffc01f2ac1>] svc_process_common+0x241/0x710 [sunrpc]
      [13108726.348332]  [<ffffffffc01f3093>] svc_process+0x103/0x190 [sunrpc]
      [13108726.350016]  [<ffffffffc07d605f>] nfsd+0xdf/0x150 [nfsd]
      [13108726.351735]  [<ffffffffc07d5f80>] ? nfsd_destroy+0x80/0x80 [nfsd]
      [13108726.353459]  [<ffffffff8a2bf741>] kthread+0xd1/0xe0
      [13108726.355195]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
      [13108726.356896]  [<ffffffff8a9556dd>] ret_from_fork_nospec_begin+0x7/0x21
      [13108726.358577]  [<ffffffff8a2bf670>] ? 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 <f0> 0f c1 02 83 c0 01 83 f8 01 0f 8e 53 02 00 00 49 8b 44 24 38
      [13108726.363769] RIP  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
      [13108726.365530]  RSP <ffffa0c2a74bfd80>
      [13108726.367179] CR2: 0000000000000074
      
      Fixes: d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
      Signed-off-by: NPavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      67256225
    • W
      firmware: arm_scmi: Avoid double free in error flow · 372098d5
      Wen Yang 提交于
      [ 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: NWen Yang <wenyang@linux.alibaba.com>
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      372098d5
    • C
      gre: refetch erspan header from skb->data after pskb_may_pull() · f7654ebe
      Cong Wang 提交于
      [ 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 <lorenzo.bianconi@redhat.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Acked-by: NWilliam Tu <u9012063@gmail.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f7654ebe
    • A
      perf callchain: Fix segfault in thread__resolve_callchain_sample() · 4f579272
      Adrian Hunter 提交于
      [ 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: NAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20191114142538.4097-1-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4f579272
    • T
      workqueue: Fix missing kfree(rescuer) in destroy_workqueue() · 1b83d575
      Tejun Heo 提交于
      commit 8efe1223d73c218ce7e8b2e0e9aadb974b582d7f upstream.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NQian Cai <cai@lca.pw>
      Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()")
      Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b83d575
    • M
      blk-mq: make sure that line break can be printed · d88fb4f0
      Ming Lei 提交于
      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: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d88fb4f0
    • H
      s390/smp,vdso: fix ASCE handling · d7248f5a
      Heiko Carstens 提交于
      [ 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: 0aaba41b ("s390: remove all code using the access register mode")
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d7248f5a
    • M
      mm, thp, proc: report THP eligibility for each vma · c76adee3
      Michal Hocko 提交于
      [ 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/<pid>/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.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Paul Oppenheimer <bepvte@gmail.com>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c76adee3
    • D
      mfd: rk808: Fix RK818 ID template · 8599f823
      Daniel Schultz 提交于
      [ 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: 9d6105e1 ("mfd: rk808: Fix up the chip id get failed")
      Cc: stable@vger.kernel.org
      Cc: Elaine Zhang <zhangqing@rock-chips.com>
      Cc: Joseph Chen <chenjh@rock-chips.com>
      Signed-off-by: NDaniel Schultz <d.schultz@phytec.de>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8599f823
    • Y
      ext4: fix a bug in ext4_wait_for_tail_page_commit · b1ec93dd
      yangerkun 提交于
      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: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: Nyangerkun <yangerkun@huawei.com>
      Link: https://lore.kernel.org/r/20190919063508.1045-1-yangerkun@huawei.comReviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1ec93dd
    • D
      splice: only read in as much information as there is pipe buffer space · 326ba910
      Darrick J. Wong 提交于
      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: NAndreas Grünbacher <andreas.gruenbacher@gmail.com>
      Reviewed-by: NAndreas Grünbacher <andreas.gruenbacher@gmail.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      326ba910
    • A
      rtc: disable uie before setting time and enable after · 42a929ed
      Alexandre Belloni 提交于
      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: 6610e089 ("RTC: Rework RTC code to use timerqueue for events")
      Link: https://lore.kernel.org/r/20191020231320.8191-1-alexandre.belloni@bootlin.comSigned-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42a929ed
    • C
      mm/shmem.c: cast the type of unmap_start to u64 · 32b02bfd
      Chen Jun 提交于
      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.comSigned-off-by: NChen Jun <chenjun102@huawei.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32b02bfd
    • W
      firmware: qcom: scm: Ensure 'a0' status code is treated as signed · 10eb175f
      Will Deacon 提交于
      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: <stable@vger.kernel.org>
      Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10eb175f
    • T
      ext4: work around deleting a file with i_nlink == 0 safely · 8e7a8653
      Theodore Ts'o 提交于
      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.eduSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Reviewed-by: NAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e7a8653
    • V
      powerpc: Fix vDSO clock_getres() · 79bee5a3
      Vincenzo Frascino 提交于
      [ 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: a7f290da ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
      Cc: stable@vger.kernel.org
      Signed-off-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.frSigned-off-by: NSasha Levin <sashal@kernel.org>
      79bee5a3
    • N
      powerpc: Avoid clang warnings around setjmp and longjmp · 12d1ed19
      Nathan Chancellor 提交于
      [ 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 <setjmp.h>.
        [-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 <setjmp.h>.
        [-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: NSegher Boessenkool <segher@kernel.crashing.org>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      12d1ed19
    • A
      regulator: 88pm800: fix warning same module names · be55e56e
      Anders Roxell 提交于
      [ 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: NAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      be55e56e
    • M
      ath10k: fix fw crash by moving chip reset after napi disabled · de986efd
      Miaoqing Pan 提交于
      [ 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: NMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      de986efd
    • H
      media: vimc: fix component match compare · 27944403
      Helen Koike 提交于
      [ 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: 4a29b709 ("[media] vimc: Subdevices as modules")
      Signed-off-by: NHelen Koike <helen.koike@collabora.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Tested-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      27944403
    • I
      mlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead · a827d6c0
      Ido Schimmel 提交于
      [ 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: a7ff87ac ("mlxsw: spectrum_router: Implement next-hop routing")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a827d6c0
    • T
      power: supply: cpcap-battery: Fix signed counter sample register · 52600d00
      Tony Lindgren 提交于
      [ 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: NTony Lindgren <tony@atomide.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52600d00
    • S
      x86/MCE/AMD: Carve out the MC4_MISC thresholding quirk · 938de232
      Shirish S 提交于
      [ 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: NShirish S <shirish.s@amd.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Yazen Ghannam <yazen.ghannam@amd.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/1547651417-23583-3-git-send-email-shirish.s@amd.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      938de232
    • S
      x86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 models · 805f5ff8
      Shirish S 提交于
      [ 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: NShirish S <shirish.s@amd.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/1547106849-3476-2-git-send-email-shirish.s@amd.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      805f5ff8
    • L
      scsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G · 7bf64b2b
      Luo Jiaxing 提交于
      [ 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: NLuo Jiaxing <luojiaxing@huawei.com>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7bf64b2b