1. 01 11月, 2019 7 次提交
  2. 23 10月, 2019 6 次提交
  3. 20 10月, 2019 5 次提交
  4. 19 10月, 2019 8 次提交
  5. 18 10月, 2019 11 次提交
    • J
      iommu/amd: Check PM_LEVEL_SIZE() condition in locked section · 46ac18c3
      Joerg Roedel 提交于
      The increase_address_space() function has to check the PM_LEVEL_SIZE()
      condition again under the domain->lock to avoid a false trigger of the
      WARN_ON_ONCE() and to avoid that the address space is increase more
      often than necessary.
      Reported-by: NQian Cai <cai@lca.pw>
      Fixes: 754265bc ("iommu/amd: Fix race in increase_address_space()")
      Reviewed-by: NJerry Snitselaar <jsnitsel@redhat.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      46ac18c3
    • K
      nvme-pci: Set the prp2 correctly when using more than 4k page · a4f40484
      Kevin Hao 提交于
      In the current code, the nvme is using a fixed 4k PRP entry size,
      but if the kernel use a page size which is more than 4k, we should
      consider the situation that the bv_offset may be larger than the
      dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
      cause the command can't be executed correctly.
      
      Fixes: dff824b2 ("nvme-pci: optimize mapping of small single segment requests")
      Cc: stable@vger.kernel.org
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKevin Hao <haokexin@gmail.com>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      a4f40484
    • J
      ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit() · 56a0b978
      John Garry 提交于
      When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
      warning:
      
      [   20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
      [   20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
      [   20.884826]
      [   20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
      [   20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
      [   20.903505] Call trace:
      [   20.905942]  dump_backtrace+0x0/0x200
      [   20.909593]  show_stack+0x14/0x20
      [   20.912899]  dump_stack+0xd4/0x130
      [   20.916291]  print_address_description.isra.9+0x6c/0x3b8
      [   20.921592]  __kasan_report+0x12c/0x23c
      [   20.925417]  kasan_report+0xc/0x18
      [   20.928808]  __asan_load4+0x94/0xb8
      [   20.932286]  pcc_data_alloc+0x40/0xb8
      [   20.935938]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   20.940717]  __acpi_processor_start+0x48/0xb0
      [   20.945062]  acpi_processor_start+0x40/0x60
      [   20.949235]  really_probe+0x118/0x548
      [   20.952887]  driver_probe_device+0x7c/0x148
      [   20.957059]  device_driver_attach+0x94/0xa0
      [   20.961231]  __driver_attach+0xa4/0x110
      [   20.965055]  bus_for_each_dev+0xe8/0x158
      [   20.968966]  driver_attach+0x30/0x40
      [   20.972531]  bus_add_driver+0x234/0x2f0
      [   20.976356]  driver_register+0xbc/0x1d0
      [   20.980182]  acpi_processor_driver_init+0x40/0xe4
      [   20.984875]  do_one_initcall+0xb4/0x254
      [   20.988700]  kernel_init_freeable+0x24c/0x2f8
      [   20.993047]  kernel_init+0x10/0x118
      [   20.996524]  ret_from_fork+0x10/0x18
      [   21.000087]
      [   21.001567] Allocated by task 1:
      [   21.004785]  save_stack+0x28/0xc8
      [   21.008089]  __kasan_kmalloc.isra.9+0xbc/0xd8
      [   21.012435]  kasan_kmalloc+0xc/0x18
      [   21.015913]  pcc_data_alloc+0x94/0xb8
      [   21.019564]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   21.024343]  __acpi_processor_start+0x48/0xb0
      [   21.028689]  acpi_processor_start+0x40/0x60
      [   21.032860]  really_probe+0x118/0x548
      [   21.036512]  driver_probe_device+0x7c/0x148
      [   21.040684]  device_driver_attach+0x94/0xa0
      [   21.044855]  __driver_attach+0xa4/0x110
      [   21.048680]  bus_for_each_dev+0xe8/0x158
      [   21.052591]  driver_attach+0x30/0x40
      [   21.056155]  bus_add_driver+0x234/0x2f0
      [   21.059980]  driver_register+0xbc/0x1d0
      [   21.063805]  acpi_processor_driver_init+0x40/0xe4
      [   21.068497]  do_one_initcall+0xb4/0x254
      [   21.072322]  kernel_init_freeable+0x24c/0x2f8
      [   21.076667]  kernel_init+0x10/0x118
      [   21.080144]  ret_from_fork+0x10/0x18
      [   21.083707]
      [   21.085186] Freed by task 1:
      [   21.088056]  save_stack+0x28/0xc8
      [   21.091360]  __kasan_slab_free+0x118/0x180
      [   21.095445]  kasan_slab_free+0x10/0x18
      [   21.099183]  kfree+0x80/0x268
      [   21.102139]  acpi_cppc_processor_exit+0x1a8/0x1b8
      [   21.106832]  acpi_processor_stop+0x70/0x80
      [   21.110917]  really_probe+0x174/0x548
      [   21.114568]  driver_probe_device+0x7c/0x148
      [   21.118740]  device_driver_attach+0x94/0xa0
      [   21.122912]  __driver_attach+0xa4/0x110
      [   21.126736]  bus_for_each_dev+0xe8/0x158
      [   21.130648]  driver_attach+0x30/0x40
      [   21.134212]  bus_add_driver+0x234/0x2f0
      [   21.0x10/0x18
      [   21.161764]
      [   21.163244] The buggy address belongs to the object at ffff00236cdeb600
      [   21.163244]  which belongs to the cache kmalloc-256 of size 256
      [   21.175750] The buggy address is located 132 bytes inside of
      [   21.175750]  256-byte region [ffff00236cdeb600, ffff00236cdeb700)
      [   21.187473] The buggy address belongs to the page:
      [   21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
      [   21.202331] flags: 0x1ffff00000010200(slab|head)
      [   21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
      [   21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
      [   21.222400] page dumped because: kasan: bad access detected
      [   21.227959]
      [   21.229438] Memory state around the buggy address:
      [   21.234218]  ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.241427]  ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.255845]                    ^
      [   21.259062]  ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.266272]  ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.273480] ==================================================================
      
      It seems that global pcc_data[pcc_ss_id] can be freed in
      acpi_cppc_processor_exit(), but we may later reference this value, so
      NULLify it when freed.
      
      Also remove the useless setting of data "pcc_channel_acquired", which
      we're about to free.
      
      Fixes: 85b1407b ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      56a0b978
    • M
      net: phy: micrel: Update KSZ87xx PHY name · 1d951ba3
      Marek Vasut 提交于
      The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
      Update the PHY ID and name to reflect that, as this family of switches
      is commonly refered to as KSZ87xx
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d951ba3
    • M
      net: phy: micrel: Discern KSZ8051 and KSZ8795 PHYs · 8b95599c
      Marek Vasut 提交于
      The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
      same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
      in the micrel PHY driver, it is used even with the KSZ87xx switch. This
      is wrong, since the KSZ8051 configures registers of the PHY which are
      not present on the simplified KSZ87xx switch PHYs and misconfigures
      other registers of the KSZ87xx switch PHYs.
      
      Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the
      KSZ87xx switch by checking the Basic Status register Bit 0, which is
      read-only and indicates presence of the Extended Capability Registers.
      The KSZ8051 PHY has those registers while the KSZ87xx switch does not.
      
      This patch implements simple check for the presence of this bit for
      both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct
      PHY driver instance.
      
      Fixes: 9d162ed6 ("net: phy: micrel: add support for KSZ8795")
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b95599c
    • M
      net: dsa: microchip: Add shared regmap mutex · 013572a2
      Marek Vasut 提交于
      The KSZ driver uses one regmap per register width (8/16/32), each with
      it's own lock, but accessing the same set of registers. In theory, it
      is possible to create a race condition between these regmaps, although
      the underlying bus (SPI or I2C) locking should assure nothing bad will
      really happen and the accesses would be correct.
      
      To make the driver do the right thing, add one single shared mutex for
      all the regmaps used by the driver instead. This assures that even if
      some future hardware is on a bus which does not serialize the accesses
      the same way SPI or I2C does, nothing bad will happen.
      
      Note that the status_mutex was unused and only initied, hence it was
      renamed and repurposed as the regmap mutex.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      013572a2
    • M
      net: dsa: microchip: Do not reinit mutexes on KSZ87xx · 7f238ca9
      Marek Vasut 提交于
      The KSZ87xx driver calls mutex_init() on mutexes already inited in
      ksz_common.c ksz_switch_register(). Do not do it twice, drop the
      reinitialization.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f238ca9
    • B
      net: stmmac: fix argument to stmmac_pcs_ctrl_ane() · c9ad4c10
      Ben Dooks (Codethink) 提交于
      The stmmac_pcs_ctrl_ane() expects a register address as
      argument 1, but for some reason the mac_device_info is
      being passed.
      
      Fix the warning (and possible bug) from sparse:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:    expected void [noderef] <asn:2> *ioaddr
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:    got struct mac_device_info *hw
      Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9ad4c10
    • I
      dpaa2-eth: Fix TX FQID values · a690af4f
      Ioana Radulescu 提交于
      Depending on when MC connects the DPNI to a MAC, Tx FQIDs may
      not be available during probe time.
      
      Read the FQIDs each time the link goes up to avoid using invalid
      values. In case an error occurs or an invalid value is retrieved,
      fall back to QDID-based enqueueing.
      
      Fixes: 1fa0f68c ("dpaa2-eth: Use FQ-based DPIO enqueue API")
      Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a690af4f
    • F
      dpaa2-eth: add irq for the dpmac connect/disconnect event · 8398b375
      Florin Chiculita 提交于
      Add IRQ for the DPNI endpoint change event, resolving the issue
      when a dynamically created DPNI gets a randomly generated hw address
      when the endpoint is a DPMAC object.
      Signed-off-by: NFlorin Chiculita <florinlaurentiu.chiculita@nxp.com>
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8398b375
    • O
      usb: hso: obey DMA rules in tiocmget · af0de130
      Oliver Neukum 提交于
      The serial state information must not be embedded into another
      data structure, as this interferes with cache handling for DMA
      on architectures without cache coherence..
      That would result in data corruption on some architectures
      Allocating it separately.
      
      v2: fix syntax error
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af0de130
  6. 17 10月, 2019 3 次提交
    • M
      dm cache: fix bugs when a GFP_NOWAIT allocation fails · 13bd677a
      Mikulas Patocka 提交于
      GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
      available and it fails if the mempool is exhausted and there is not enough
      memory.
      
      If we go down this path:
        map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
      we can see that map_bio() doesn't check the return value of mg_start(),
      and the bio is leaked.
      
      If we go down this path:
        map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
        dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
        mg_lock_writes -> mg_complete
      the bio is ended with an error - it is unacceptable because it could
      cause filesystem corruption if the machine ran out of memory
      temporarily.
      
      Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
      wait until memory becomes available. mempool_alloc with GFP_NOIO can't
      fail, so remove the code paths that deal with allocation failure.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      13bd677a
    • B
      net: stmmac: disable/enable ptp_ref_clk in suspend/resume flow · e497c20e
      Biao Huang 提交于
      disable ptp_ref_clk in suspend flow, and enable it in resume flow.
      
      Fixes: f573c0b9 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e497c20e
    • Y
      net: phy: Fix "link partner" information disappear issue · 3de5ae54
      Yonglong Liu 提交于
      Some drivers just call phy_ethtool_ksettings_set() to set the
      links, for those phy drivers that use genphy_read_status(), if
      autoneg is on, and the link is up, than execute "ethtool -s
      ethx autoneg on" will cause "link partner" information disappear.
      
      The call trace is phy_ethtool_ksettings_set()->phy_start_aneg()
      ->linkmode_zero(phydev->lp_advertising)->genphy_read_status(),
      the link didn't change, so genphy_read_status() just return, and
      phydev->lp_advertising is zero now.
      
      This patch moves the clear operation of lp_advertising from
      phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and
      if autoneg on and autoneg not complete, just clear what the
      generic functions care about.
      
      Fixes: 88d6272a ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
      Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
      Reviewed-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3de5ae54