1. 17 1月, 2019 1 次提交
  2. 16 1月, 2019 6 次提交
  3. 13 1月, 2019 3 次提交
  4. 12 1月, 2019 14 次提交
    • G
      mISDN: hfcsusb: Use struct_size() in kzalloc() · 8d008e64
      Gustavo A. R. Silva 提交于
      One of the more common cases of allocation size calculations is finding the
      size of a structure that has a zero-sized array at the end, along with memory
      for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          void *entry[];
      };
      
      instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can now
      use the new struct_size() helper:
      
      instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d008e64
    • J
      isdn: i4l: isdn_tty: Fix some concurrency double-free bugs · 2ff33d66
      Jia-Ju Bai 提交于
      The functions isdn_tty_tiocmset() and isdn_tty_set_termios() may be
      concurrently executed.
      
      isdn_tty_tiocmset
        isdn_tty_modem_hup
          line 719: kfree(info->dtmf_state);
          line 721: kfree(info->silence_state);
          line 723: kfree(info->adpcms);
          line 725: kfree(info->adpcmr);
      
      isdn_tty_set_termios
        isdn_tty_modem_hup
          line 719: kfree(info->dtmf_state);
          line 721: kfree(info->silence_state);
          line 723: kfree(info->adpcms);
          line 725: kfree(info->adpcmr);
      
      Thus, some concurrency double-free bugs may occur.
      
      These possible bugs are found by a static tool written by myself and
      my manual code review.
      
      To fix these possible bugs, the mutex lock "modem_info_mutex" used in
      isdn_tty_tiocmset() is added in isdn_tty_set_termios().
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ff33d66
    • Z
      vhost/vsock: fix vhost vsock cid hashing inconsistent · 7fbe078c
      Zha Bin 提交于
      The vsock core only supports 32bit CID, but the Virtio-vsock spec define
      CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
      zero. This inconsistency causes one bug in vhost vsock driver. The
      scenarios is:
      
        0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
        object. And hash_min() is used to compute the hash key. hash_min() is
        defined as:
        (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)).
        That means the hash algorithm has dependency on the size of macro
        argument 'val'.
        0. In function vhost_vsock_set_cid(), a 64bit CID is passed to
        hash_min() to compute the hash key when inserting a vsock object into
        the hash table.
        0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min()
        to compute the hash key when looking up a vsock for an CID.
      
      Because the different size of the CID, hash_min() returns different hash
      key, thus fails to look up the vsock object for an CID.
      
      To fix this bug, we keep CID as u64 in the IOCTLs and virtio message
      headers, but explicitly convert u64 to u32 when deal with the hash table
      and vsock core.
      
      Fixes: 834e772c ("vhost/vsock: fix use-after-free in network stack callers")
      Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.texSigned-off-by: NZha Bin <zhabin@linux.alibaba.com>
      Reviewed-by: NLiu Jiang <gerry@linux.alibaba.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fbe078c
    • J
      net: stmmac: Prevent RX starvation in stmmac_napi_poll() · fa0be0a4
      Jose Abreu 提交于
      Currently, TX is given a budget which is consumed by stmmac_tx_clean()
      and stmmac_rx() is given the remaining non-consumed budget.
      
      This is wrong and in case we are sending a large number of packets this
      can starve RX because remaining budget will be low.
      
      Let's give always the same budget for RX and TX clean.
      
      While at it, check if we missed any interrupts while we were in NAPI
      callback by looking at DMA interrupt status.
      
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa0be0a4
    • J
      net: stmmac: Fix the logic of checking if RX Watchdog must be enabled · 3b509466
      Jose Abreu 提交于
      RX Watchdog can be disabled by platform definitions but currently we are
      initializing the descriptors before checking if Watchdog must be
      disabled or not.
      
      Fix this by checking earlier if user wants Watchdog disabled or not.
      
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b509466
    • J
      net: stmmac: Check if CBS is supported before configuring · 0650d401
      Jose Abreu 提交于
      Check if CBS is currently supported before trying to configure it in HW.
      
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0650d401
    • J
      net: stmmac: dwxgmac2: Only clear interrupts that are active · fcc509eb
      Jose Abreu 提交于
      In DMA interrupt handler we were clearing all interrupts status, even
      the ones that were not active. Fix this and only clear the active
      interrupts.
      
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fcc509eb
    • J
      net: stmmac: Fix PCI module removal leak · 6dea7e18
      Jose Abreu 提交于
      Since commit b7d0f08e, the enable / disable of PCI device is not
      managed which will result in IO regions not being automatically unmapped.
      As regions continue mapped it is currently not possible to remove and
      then probe again the PCI module of stmmac.
      
      Fix this by manually unmapping regions on remove callback.
      
      Changes from v1:
      - Fix build error
      
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Fixes: b7d0f08e ("net: stmmac: Fix WoL for PCI-based setups")
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6dea7e18
    • M
      ata: ahci: mvebu: request PHY suspend/resume for Armada 3700 · bde0b5c1
      Miquel Raynal 提交于
      A feature has been added in the libahci driver: the possibility to set
      a new flag in hpriv->flags to let the core handle PHY suspend/resume
      automatically. Make use of this feature to make suspend to RAM work
      with SATA drives on A3700.
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      bde0b5c1
    • M
      ata: ahci: mvebu: add Armada 3700 initialization needed for S2RAM · 2f558bc3
      Miquel Raynal 提交于
      A3700 comphy initialization is done in the firmware (TF-A). Looking at
      the SATA PHY initialization routine, there is a comment about "vendor
      specific" registers. Two registers are mentioned. They are not
      initialized there in the firmware because they are AHCI related, while
      the firmware at this location does only PHY configuration. The
      solution to avoid doing such initialization is relying on U-Boot.
      
      While this work at boot time, U-Boot is definitely not going to run
      during a resume after suspending to RAM.
      
      Two possible solutions were considered:
      * Fixing the firmware.
      * Fixing the kernel driver.
      
      The first solution would take ages to propagate, while the second
      solution is easy to implement as the driver as been a little bit
      reworked to prepare for such platform configuration. Hence, this patch
      adds an Armada 3700 configuration function to set these two registers
      both at boot time (in the probe) and after a suspend (in the resume
      path).
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      2f558bc3
    • M
      ata: ahci: mvebu: do Armada 38x configuration only on relevant SoCs · 96dbcb40
      Miquel Raynal 提交于
      At the beginning, only Armada 38x SoCs where supported by the
      ahci_mvebu.c driver. Commit 15d3ce7b ("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: 15d3ce7b ("ata: ahci_mvebu: add support for Armada 3700 variant")
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      96dbcb40
    • M
      ata: ahci: mvebu: remove stale comment · c9bc1367
      Miquel Raynal 提交于
      For Armada-38x (32-bit) SoCs, PM platform support has been added since:
      commit 32f9494c ("ARM: mvebu: prepare pm-board.c for the
                            introduction of Armada 38x support")
      commit 3cbd6a6c ("ARM: mvebu: Add standby support")
      
      For Armada 64-bit SoCs, like the A3700 also using this AHCI driver, PM
      platform support has always existed.
      
      There are even suspend/resume hooks in this driver since:
      commit d6ecf158 ("ata: ahci_mvebu: add suspend/resume support")
      
      Remove the stale comment at the end of this driver stating that all
      the above does not exist yet.
      
      Fixes: d6ecf158 ("ata: ahci_mvebu: add suspend/resume support")
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c9bc1367
    • M
      ata: libahci_platform: comply to PHY framework · 49e54187
      Miquel Raynal 提交于
      Current implementation of the libahci does not take into account the
      new PHY framework. Correct the situation by adding a call to
      phy_set_mode() before phy_power_on().
      
      PHYs should also be handled at suspend/resume time. For this, call
      ahci_platform_enable/disable_phys() at suspend/resume_host() time. These
      calls are guarded by a HFLAG (AHCI_HFLAG_SUSPEND_PHYS) that the user of
      the libahci driver must set manually in hpriv->flags at probe time. This
      is to avoid breaking users that have not been tested with this change.
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Suggested-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      49e54187
    • D
      tty: Don't hold ldisc lock in tty_reopen() if ldisc present · d3736d82
      Dmitry Safonov 提交于
      Try to get reference for ldisc during tty_reopen().
      If ldisc present, we don't need to do tty_ldisc_reinit() and lock the
      write side for line discipline semaphore.
      Effectively, it optimizes fast-path for tty_reopen(), but more
      importantly it won't interrupt ongoing IO on the tty as no ldisc change
      is needed.
      Fixes user-visible issue when tty_reopen() interrupted login process for
      user with a long password, observed and reported by Lukas.
      
      Fixes: c96cf923 ("tty: Don't block on IO when ldisc change is pending")
      Fixes: 83d817f4 ("tty: Hold tty_ldisc_lock() during tty_reopen()")
      Cc: Jiri Slaby <jslaby@suse.com>
      Reported-by: NLukas F. Hartmann <lukas@mntmn.com>
      Tested-by: NLukas F. Hartmann <lukas@mntmn.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3736d82
  5. 11 1月, 2019 12 次提交
    • M
      mmc: core: don't override the CD GPIO level when "cd-inverted" is set · e3e4767b
      Martin Blumenstingl 提交于
      Since commit 89a5e15b ("gpio/mmc/of: Respect polarity in the device
      tree") gpiolib-of parses the "cd-gpios" property and flips the polarity
      if "cd-inverted" is also set. This results in the "cd-inverted" property
      being evaluated twice, which effectively makes it a no-op:
      - first in drivers/gpio/gpiolib-of.c (of_xlate_and_get_gpiod_flags) when
        setting up the CD GPIO
      - then again in drivers/mmc/core/slot-gpio.c (mmc_gpio_get_cd) when
        reading the CD GPIO value at runtime
      
      On boards which are using device-tree with the "cd-inverted" property
      being set any inserted card are not detected anymore. This is due to the
      MMC core treating the CD GPIO with the wrong polarity.
      
      Disable "override_cd_active_level" for the card detection GPIO which is
      parsed using mmc_of_parse. This fixes SD card detection on the boards
      which are currently using the "cd-inverted" device-tree property (tested
      on Meson8b Odroid-C1 and Meson8b EC-100).
      
      This does not remove the CD GPIO inversion logic from the MMC core
      because there's at least one driver (sdhci-pci-core for Intel BayTrail
      based boards) which still passes "override_cd_active_level = true" to
      mmc_gpiod_request_cd(). Due to lack of hardware for testing this is left
      untouched.
      In the future the GPIO inversion logic for both, card and read-only
      detection can be removed once no driver is using it anymore.
      
      Fixes: 89a5e15b ("gpio/mmc/of: Respect polarity in the device tree")
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Tested-by: NAnand Moon <linux.amoon@gmail.com>
      Tested-by: NLoys Ollivier <loys.ollivier@gmail.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      e3e4767b
    • J
      ACPI/IORT: Fix rc_dma_get_range() · c7777236
      Jean-Philippe Brucker 提交于
      When executed for a PCI_ROOT_COMPLEX type, iort_match_node_callback()
      expects the opaque pointer argument to be a PCI bus device. At the
      moment rc_dma_get_range() passes the PCI endpoint instead of the bus,
      and we've been lucky to have pci_domain_nr(ptr) return 0 instead of
      crashing. Pass the bus device to iort_scan_node().
      
      Fixes: 5ac65e8c ("ACPI/IORT: Support address size limit for root complexes")
      Reported-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Cc: stable@vger.kernel.org
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c7777236
    • G
      Revert "staging: rtl8723bs: Mark ACPI table declaration as used" · 06382dea
      Greg Kroah-Hartman 提交于
      This reverts commit e6d09371.
      
      Turns out it is not needed at all, a fix for clang was made and accepted
      upstream in that project that makes this change unnecessary.  So revert
      it.
      Reported-by: NNick Desaulniers <ndesaulniers@google.com>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06382dea
    • W
      gpio: pca953x: Make symbol 'pca953x_i2c_regmap' static · d04e779f
      Wei Yongjun 提交于
      Fixes the following sparse warning:
      
      drivers/gpio/gpio-pca953x.c:292:28: warning:
       symbol 'pca953x_i2c_regmap' was not declared. Should it be static?
      
      Fixes: 49427232 ("gpio: pca953x: Perform basic regmap conversion")
      Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: NMarek Vasut <marex@denx.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      d04e779f
    • I
    • T
      drm/nouveau: Don't disable polling in fallback mode · 11878006
      Takashi Iwai 提交于
      When a fan is controlled via linear fallback without cstate, we
      shouldn't stop polling.  Otherwise it won't be adjusted again and
      keeps running at an initial crazy pace.
      
      Fixes: 800efb4c ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios")
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447Reported-by: NThomas Blume <thomas.blume@suse.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NMartin Peres <martin.peres@free.fr>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      11878006
    • B
      drm/nouveau: register backlight on pascal and newer · 15f77c4a
      Ben Skeggs 提交于
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      15f77c4a
    • S
      i2c: tegra: Fix Maximum transfer size · b67d4530
      Sowjanya Komatineni 提交于
      Tegra194 supports maximum 64K Bytes transfer per packet.
      Tegra186 and prior supports maximum 4K Bytes transfer per packet.
      
      This patch fixes this payload difference between Tegra194 and prior
      Tegra chipsets using separate i2c_adapter_quirks.
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      b67d4530
    • Y
      i2c: dev: prevent adapter retries and timeout being set as minus value · 6ebec961
      Yi Zeng 提交于
      If adapter->retries is set to a minus value from user space via ioctl,
      it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
      adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
      registered by the underlying bus drivers, and return value 0 to all the
      callers. The bus driver will never be accessed anymore by all users,
      besides, the users may still get successful return value without any
      error or information log print out.
      
      If adapter->timeout is set to minus value from user space via ioctl,
      it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
      always break after the the first try, due to the time_after always
      returns true.
      Signed-off-by: NYi Zeng <yizeng@asrmicro.com>
      [wsa: minor grammar updates to commit message]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      6ebec961
    • H
      net: ethernet: mediatek: fix warning in phy_start_aneg · b19bce03
      Heiner Kallweit 提交于
      linux 5.0-rc1 shows following warning on bpi-r2/mt7623 bootup:
      
      [ 5.170597] WARNING: CPU: 3 PID: 1 at drivers/net/phy/phy.c:548 phy_start_aneg+0x110/0x144
      [ 5.178826] called from state READY
      ....
      [ 5.264111] [<c0629fd4>] (phy_start_aneg) from [<c0e3e720>] (mtk_init+0x414/0x47c)
      [ 5.271630] r7:df5f5eec r6:c0f08c48 r5:00000000 r4:dea67800
      [ 5.277256] [<c0e3e30c>] (mtk_init) from [<c07dabbc>] (register_netdevice+0x98/0x51c)
      [ 5.285035] r8:00000000 r7:00000000 r6:c0f97080 r5:c0f08c48 r4:dea67800
      [ 5.291693] [<c07dab24>] (register_netdevice) from [<c07db06c>] (register_netdev+0x2c/0x44)
      [ 5.299989] r8:00000000 r7:dea2e608 r6:deacea00 r5:dea2e604 r4:dea67800
      [ 5.306646] [<c07db040>] (register_netdev) from [<c06326d8>] (mtk_probe+0x668/0x7ac)
      [ 5.314336] r5:dea2e604 r4:dea2e040
      [ 5.317890] [<c0632070>] (mtk_probe) from [<c05a78fc>] (platform_drv_probe+0x58/0xa8)
      [ 5.325670] r10:c0f86bac r9:00000000 r8:c0fbe578 r7:00000000 r6:c0f86bac r5:00000000
      [ 5.333445] r4:deacea10
      [ 5.335963] [<c05a78a4>] (platform_drv_probe) from [<c05a5248>] (really_probe+0x2d8/0x424)
      
      maybe other boards using this generic driver are affected
      
      v2:
      optimization:
      
      - phy_set_max_speed() is only needed if you want to reduce the
        max speed, typically if the PHY supports 1Gbps but the MAC
        supports 100Mbps only.
      
      - The pause parameters are autonegotiated. Except you have a specific
        need you normally don't need to manually fiddle with this.
      
      - phy_start_aneg() is called implicitly by the phylib state machine,
        you shouldn't call it manually except you have a good excuse.
      
      - netif_carrier_on/netif_carrier_off in mtk_phy_link_adjust() isn't
        needed. It's done by phy_link_change() in phylib.
      Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
      Reviewed-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Acked-by: NSean Wang <sean.wang@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b19bce03
    • A
      net: dsa: mv88x6xxx: mv88e6390 errata · ea89098e
      Andrew Lunn 提交于
      The 6390 copper ports have an errata which require poking magic values
      into undocumented magic registers and then performing a software
      reset.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea89098e
    • W
      bonding: update nest level on unlink · 001e465f
      Willem de Bruijn 提交于
      A network device stack with multiple layers of bonding devices can
      trigger a false positive lockdep warning. Adding lockdep nest levels
      fixes this. Update the level on both enslave and unlink, to avoid the
      following series of events ..
      
          ip netns add test
          ip netns exec test bash
          ip link set dev lo addr 00:11:22:33:44:55
          ip link set dev lo down
      
          ip link add dev bond1 type bond
          ip link add dev bond2 type bond
      
          ip link set dev lo master bond1
          ip link set dev bond1 master bond2
      
          ip link set dev bond1 nomaster
          ip link set dev bond2 master bond1
      
      .. from still generating a splat:
      
          [  193.652127] ======================================================
          [  193.658231] WARNING: possible circular locking dependency detected
          [  193.664350] 4.20.0 #8 Not tainted
          [  193.668310] ------------------------------------------------------
          [  193.674417] ip/15577 is trying to acquire lock:
          [  193.678897] 00000000a40e3b69 (&(&bond->stats_lock)->rlock#3/3){+.+.}, at: bond_get_stats+0x58/0x290
          [  193.687851]
          	       but task is already holding lock:
          [  193.693625] 00000000807b9d9f (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0x58/0x290
      
          [..]
      
          [  193.851092]        lock_acquire+0xa7/0x190
          [  193.855138]        _raw_spin_lock_nested+0x2d/0x40
          [  193.859878]        bond_get_stats+0x58/0x290
          [  193.864093]        dev_get_stats+0x5a/0xc0
          [  193.868140]        bond_get_stats+0x105/0x290
          [  193.872444]        dev_get_stats+0x5a/0xc0
          [  193.876493]        rtnl_fill_stats+0x40/0x130
          [  193.880797]        rtnl_fill_ifinfo+0x6c5/0xdc0
          [  193.885271]        rtmsg_ifinfo_build_skb+0x86/0xe0
          [  193.890091]        rtnetlink_event+0x5b/0xa0
          [  193.894320]        raw_notifier_call_chain+0x43/0x60
          [  193.899225]        netdev_change_features+0x50/0xa0
          [  193.904044]        bond_compute_features.isra.46+0x1ab/0x270
          [  193.909640]        bond_enslave+0x141d/0x15b0
          [  193.913946]        do_set_master+0x89/0xa0
          [  193.918016]        do_setlink+0x37c/0xda0
          [  193.921980]        __rtnl_newlink+0x499/0x890
          [  193.926281]        rtnl_newlink+0x48/0x70
          [  193.930238]        rtnetlink_rcv_msg+0x171/0x4b0
          [  193.934801]        netlink_rcv_skb+0xd1/0x110
          [  193.939103]        rtnetlink_rcv+0x15/0x20
          [  193.943151]        netlink_unicast+0x3b5/0x520
          [  193.947544]        netlink_sendmsg+0x2fd/0x3f0
          [  193.951942]        sock_sendmsg+0x38/0x50
          [  193.955899]        ___sys_sendmsg+0x2ba/0x2d0
          [  193.960205]        __x64_sys_sendmsg+0xad/0x100
          [  193.964687]        do_syscall_64+0x5a/0x460
          [  193.968823]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 7e2556e4 ("bonding: avoid lockdep confusion in bond_get_stats()")
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      001e465f
  6. 10 1月, 2019 4 次提交