1. 27 4月, 2019 40 次提交
    • S
      Revert "scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO" · ee4b8e26
      Saurav Kashyap 提交于
      commit 0228034d8e5915b98c33db35a98f5e909e848ae9 upstream.
      
      This patch clears FC_RP_STARTED flag during logoff, because of this
      re-login(flogi) didn't happen to the switch.
      
      This reverts commit 1550ec45.
      
      Fixes: 1550ec45 ("scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO")
      Cc: <stable@vger.kernel.org> # v4.18+
      Signed-off-by: NSaurav Kashyap <skashyap@marvell.com>
      Reviewed-by: NHannes Reinecke <hare@#suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee4b8e26
    • J
      scsi: core: set result when the command cannot be dispatched · 1aa2682d
      Jaesoo Lee 提交于
      commit be549d49115422f846b6d96ee8fd7173a5f7ceb0 upstream.
      
      When SCSI blk-mq is enabled, there is a bug in handling errors in
      scsi_queue_rq.  Specifically, the bug is not setting result field of
      scsi_request correctly when the dispatch of the command has been
      failed. Since the upper layer code including the sg_io ioctl expects to
      receive any error status from result field of scsi_request, the error is
      silently ignored and this could cause data corruptions for some
      applications.
      
      Fixes: d285203c ("scsi: add support for a blk-mq based I/O path.")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJaesoo Lee <jalee@purestorage.com>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1aa2682d
    • M
      vt: fix cursor when clearing the screen · 8f2ef0e8
      Mikulas Patocka 提交于
      commit b2ecf00631362a83744e5ec249947620db5e240c upstream.
      
      The patch a6dbe4427559 ("vt: perform safe console erase in the right
      order") introduced a bug. The conditional do_update_region() was
      replaced by a call to update_region() that does contain the conditional
      already, but with unwanted extra side effects such as restoring the cursor
      drawing.
      
      In order to reproduce the bug:
      - use framebuffer console with the AMDGPU driver
      - type "links" to start the console www browser
      - press 'q' and space to exit links
      
      Now the cursor will be permanently visible in the center of the
      screen. It will stay there until something overwrites it.
      
      The bug goes away if we change update_region() back to the conditional
      do_update_region().
      
      [ nico: reworded changelog ]
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
      Cc: stable@vger.kernel.org
      Fixes: a6dbe4427559 ("vt: perform safe console erase in the right order")
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f2ef0e8
    • G
      serial: sh-sci: Fix HSCIF RX sampling point calculation · 38b7f09a
      Geert Uytterhoeven 提交于
      commit ace965696da2611af759f0284e26342b7b6cec89 upstream.
      
      There are several issues with the formula used for calculating the
      deviation from the intended rate:
        1. While min_err and last_stop are signed, srr and baud are unsigned.
           Hence the signed values are promoted to unsigned, which will lead
           to a bogus value of deviation if min_err is negative,
        2. Srr is the register field value, which is one less than the actual
           sampling rate factor,
        3. The divisions do not use rounding.
      
      Fix this by casting unsigned variables to int, adding one to srr, and
      using a single DIV_ROUND_CLOSEST().
      
      Fixes: 63ba1e00 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment")
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38b7f09a
    • G
      serial: sh-sci: Fix HSCIF RX sampling point adjustment · de6d6b89
      Geert Uytterhoeven 提交于
      commit 6b87784b53592a90d21576be8eff688b56d93cce upstream.
      
      The calculation of the sampling point has min() and max() exchanged.
      Fix this by using the clamp() helper instead.
      
      Fixes: 63ba1e00 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment")
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
      Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de6d6b89
    • K
      Input: elan_i2c - add hardware ID for multiple Lenovo laptops · ec96f65e
      KT Liao 提交于
      commit 738c06d0e4562e0acf9f2c7438a22b2d5afc67aa upstream.
      
      There are many Lenovo laptops which need elan_i2c support, this patch adds
      relevant IDs to the Elan driver so that touchpads are recognized.
      Signed-off-by: NKT Liao <kt.liao@emc.com.tw>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec96f65e
    • T
      ALSA: core: Fix card races between register and disconnect · b50e435d
      Takashi Iwai 提交于
      commit 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac upstream.
      
      There is a small race window in the card disconnection code that
      allows the registration of another card with the very same card id.
      This leads to a warning in procfs creation as caught by syzkaller.
      
      The problem is that we delete snd_cards and snd_cards_lock entries at
      the very beginning of the disconnection procedure.  This makes the
      slot available to be assigned for another card object while the
      disconnection procedure is being processed.  Then it becomes possible
      to issue a procfs registration with the existing file name although we
      check the conflict beforehand.
      
      The fix is simply to move the snd_cards and snd_cards_lock clearances
      at the end of the disconnection procedure.  The references to these
      entries are merely either from the global proc files like
      /proc/asound/cards or from the card registration / disconnection, so
      it should be fine to shift at the very end.
      
      Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b50e435d
    • H
      ALSA: hda/realtek - add two more pin configuration sets to quirk table · 4171b6ee
      Hui Wang 提交于
      commit b26e36b7ef36a8a3a147b1609b2505f8a4ecf511 upstream.
      
      We have two Dell laptops which have the codec 10ec0236 and 10ec0256
      respectively, the headset mic on them can't work, need to apply the
      quirk of ALC255_FIXUP_DELL1_MIC_NO_PRESENCE. So adding their pin
      configurations in the pin quirk table.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4171b6ee
    • I
      staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf · 4e78a1fb
      Ian Abbott 提交于
      commit af4b54a2e5ba18259ff9aac445bf546dd60d037e upstream.
      
      `ni6501_alloc_usb_buffers()` is called from `ni6501_auto_attach()` to
      allocate RX and TX buffers for USB transfers.  It allocates
      `devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`.  If the
      allocation of `devpriv->usb_tx_buf` fails, it frees
      `devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
      error.  Later, `ni6501_detach()` will be called from the core comedi
      module code to clean up.  `ni6501_detach()` also frees both
      `devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
      `devpriv->usb_rx_buf` may have already beed freed, leading to a
      double-free error.  Fix it bu removing the call to
      `kfree(devpriv->usb_rx_buf)` from `ni6501_alloc_usb_buffers()`, relying
      on `ni6501_detach()` to free the memory.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e78a1fb
    • I
      staging: comedi: ni_usb6501: Fix use of uninitialized mutex · 09f9baca
      Ian Abbott 提交于
      commit 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c upstream.
      
      If `ni6501_auto_attach()` returns an error, the core comedi module code
      will call `ni6501_detach()` to clean up.  If `ni6501_auto_attach()`
      successfully allocated the comedi device private data, `ni6501_detach()`
      assumes that a `struct mutex mut` contained in the private data has been
      initialized and uses it.  Unfortunately, there are a couple of places
      where `ni6501_auto_attach()` can return an error after allocating the
      device private data but before initializing the mutex, so this
      assumption is invalid.  Fix it by initializing the mutex just after
      allocating the private data in `ni6501_auto_attach()` before any other
      errors can be retturned.  Also move the call to `usb_set_intfdata()`
      just to keep the code a bit neater (either position for the call is
      fine).
      
      I believe this was the cause of the following syzbot crash report
      <https://syzkaller.appspot.com/bug?extid=cf4f2b6c24aff0a3edf6>:
      
      usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
      usb 1-1: config 0 descriptor??
      usb 1-1: string descriptor 0 read error: -71
      comedi comedi0: Wrong number of endpoints
      ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: usb_hub_wq hub_event
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xe8/0x16e lib/dump_stack.c:113
       assign_lock_key kernel/locking/lockdep.c:786 [inline]
       register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
       __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
       lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0xfe/0x12b0 kernel/locking/mutex.c:1072
       ni6501_detach+0x5b/0x110 drivers/staging/comedi/drivers/ni_usb6501.c:567
       comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
       comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
       comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
       comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
       comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
       comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
       comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
       usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
       really_probe+0x2da/0xb10 drivers/base/dd.c:509
       driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
       __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
       bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
       __device_attach+0x223/0x3a0 drivers/base/dd.c:844
       bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
       device_add+0xad2/0x16e0 drivers/base/core.c:2106
       usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
       generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
       usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
       really_probe+0x2da/0xb10 drivers/base/dd.c:509
       driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
       __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
       bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
       __device_attach+0x223/0x3a0 drivers/base/dd.c:844
       bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
       device_add+0xad2/0x16e0 drivers/base/core.c:2106
       usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
       hub_port_connect drivers/usb/core/hub.c:5089 [inline]
       hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
       port_event drivers/usb/core/hub.c:5350 [inline]
       hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
       process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
       worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
       kthread+0x313/0x420 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      Reported-by: syzbot+cf4f2b6c24aff0a3edf6@syzkaller.appspotmail.com
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09f9baca
    • I
      staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf · edf2f548
      Ian Abbott 提交于
      commit 663d294b4768bfd89e529e069bffa544a830b5bf upstream.
      
      `vmk80xx_alloc_usb_buffers()` is called from `vmk80xx_auto_attach()` to
      allocate RX and TX buffers for USB transfers.  It allocates
      `devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`.  If the
      allocation of `devpriv->usb_tx_buf` fails, it frees
      `devpriv->usb_rx_buf`,  leaving the pointer set dangling, and returns an
      error.  Later, `vmk80xx_detach()` will be called from the core comedi
      module code to clean up.  `vmk80xx_detach()` also frees both
      `devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
      `devpriv->usb_rx_buf` may have already been freed, leading to a
      double-free error.  Fix it by removing the call to
      `kfree(devpriv->usb_rx_buf)` from `vmk80xx_alloc_usb_buffers()`, relying
      on `vmk80xx_detach()` to free the memory.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edf2f548
    • I
      staging: comedi: vmk80xx: Fix use of uninitialized semaphore · 1f01a970
      Ian Abbott 提交于
      commit 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e upstream.
      
      If `vmk80xx_auto_attach()` returns an error, the core comedi module code
      will call `vmk80xx_detach()` to clean up.  If `vmk80xx_auto_attach()`
      successfully allocated the comedi device private data,
      `vmk80xx_detach()` assumes that a `struct semaphore limit_sem` contained
      in the private data has been initialized and uses it.  Unfortunately,
      there are a couple of places where `vmk80xx_auto_attach()` can return an
      error after allocating the device private data but before initializing
      the semaphore, so this assumption is invalid.  Fix it by initializing
      the semaphore just after allocating the private data in
      `vmk80xx_auto_attach()` before any other errors can be returned.
      
      I believe this was the cause of the following syzbot crash report
      <https://syzkaller.appspot.com/bug?extid=54c2f58f15fe6876b6ad>:
      
      usb 1-1: config 0 has no interface number 0
      usb 1-1: New USB device found, idVendor=10cf, idProduct=8068, bcdDevice=e6.8d
      usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
      usb 1-1: config 0 descriptor??
      vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: usb_hub_wq hub_event
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xe8/0x16e lib/dump_stack.c:113
       assign_lock_key kernel/locking/lockdep.c:786 [inline]
       register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
       __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
       lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
       down+0x12/0x80 kernel/locking/semaphore.c:58
       vmk80xx_detach+0x59/0x100 drivers/staging/comedi/drivers/vmk80xx.c:829
       comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
       comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
       comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
       comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
       comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
       comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
       comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
       usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
       really_probe+0x2da/0xb10 drivers/base/dd.c:509
       driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
       __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
       bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
       __device_attach+0x223/0x3a0 drivers/base/dd.c:844
       bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
       device_add+0xad2/0x16e0 drivers/base/core.c:2106
       usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
       generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
       usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
       really_probe+0x2da/0xb10 drivers/base/dd.c:509
       driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
       __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
       bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
       __device_attach+0x223/0x3a0 drivers/base/dd.c:844
       bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
       device_add+0xad2/0x16e0 drivers/base/core.c:2106
       usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
       hub_port_connect drivers/usb/core/hub.c:5089 [inline]
       hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
       port_event drivers/usb/core/hub.c:5350 [inline]
       hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
       process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
       worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
       kthread+0x313/0x420 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      Reported-by: syzbot+54c2f58f15fe6876b6ad@syzkaller.appspotmail.com
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f01a970
    • C
      staging: most: core: use device description as name · a1da981f
      Christian Gromm 提交于
      commit 131ac62253dba79daf4a6d83ab12293d2b9863d3 upstream.
      
      This patch uses the device description to clearly identity a device
      attached to the bus. It is needed as the currently useed mdevX
      notation is not sufficiant in case more than one network
      interface controller is being used at the same time.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristian Gromm <christian.gromm@microchip.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1da981f
    • H
      io: accel: kxcjk1013: restore the range after resume. · b007c64d
      he, bo 提交于
      commit fe2d3df639a7940a125a33d6460529b9689c5406 upstream.
      
      On some laptops, kxcjk1013 is powered off when system enters S3. We need
      restore the range regiter during resume. Otherwise, the sensor doesn't
      work properly after S3.
      Signed-off-by: Nhe, bo <bo.he@intel.com>
      Signed-off-by: NChen, Hu <hu1.chen@intel.com>
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b007c64d
    • F
      iio: core: fix a possible circular locking dependency · bbe0bed4
      Fabrice Gasnier 提交于
      commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
      
      This fixes a possible circular locking dependency detected warning seen
      with:
      - CONFIG_PROVE_LOCKING=y
      - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
      
      When using the IIO consumer interface, e.g. iio_channel_get(), the consumer
      device will likely call iio_read_channel_raw() or similar that rely on
      'info_exist_lock' mutex.
      
      typically:
      ...
      	mutex_lock(&chan->indio_dev->info_exist_lock);
      	if (chan->indio_dev->info == NULL) {
      		ret = -ENODEV;
      		goto err_unlock;
      	}
      	ret = do_some_ops()
      err_unlock:
      	mutex_unlock(&chan->indio_dev->info_exist_lock);
      	return ret;
      ...
      
      Same mutex is also hold in iio_device_unregister().
      
      The following deadlock warning happens when:
      - the consumer device has called an API like iio_read_channel_raw()
        at least once.
      - the consumer driver is unregistered, removed (unbind from sysfs)
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.19.24 #577 Not tainted
      ------------------------------------------------------
      sh/372 is trying to acquire lock:
      (kn->count#30){++++}, at: kernfs_remove_by_name_ns+0x3c/0x84
      
      but task is already holding lock:
      (&dev->info_exist_lock){+.+.}, at: iio_device_unregister+0x18/0x60
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&dev->info_exist_lock){+.+.}:
             __mutex_lock+0x70/0xa3c
             mutex_lock_nested+0x1c/0x24
             iio_read_channel_raw+0x1c/0x60
             iio_read_channel_info+0xa8/0xb0
             dev_attr_show+0x1c/0x48
             sysfs_kf_seq_show+0x84/0xec
             seq_read+0x154/0x528
             __vfs_read+0x2c/0x15c
             vfs_read+0x8c/0x110
             ksys_read+0x4c/0xac
             ret_fast_syscall+0x0/0x28
             0xbedefb60
      
      -> #0 (kn->count#30){++++}:
             lock_acquire+0xd8/0x268
             __kernfs_remove+0x288/0x374
             kernfs_remove_by_name_ns+0x3c/0x84
             remove_files+0x34/0x78
             sysfs_remove_group+0x40/0x9c
             sysfs_remove_groups+0x24/0x34
             device_remove_attrs+0x38/0x64
             device_del+0x11c/0x360
             cdev_device_del+0x14/0x2c
             iio_device_unregister+0x24/0x60
             release_nodes+0x1bc/0x200
             device_release_driver_internal+0x1a0/0x230
             unbind_store+0x80/0x130
             kernfs_fop_write+0x100/0x1e4
             __vfs_write+0x2c/0x160
             vfs_write+0xa4/0x17c
             ksys_write+0x4c/0xac
             ret_fast_syscall+0x0/0x28
             0xbe906840
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&dev->info_exist_lock);
                                     lock(kn->count#30);
                                     lock(&dev->info_exist_lock);
        lock(kn->count#30);
      
       *** DEADLOCK ***
      ...
      
      cdev_device_del() can be called without holding the lock. It should be safe
      as info_exist_lock prevents kernelspace consumers to use the exported
      routines during/after provider removal. cdev_device_del() is for userspace.
      
      Help to reproduce:
      See example: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
      sysv {
      	compatible = "voltage-divider";
      	io-channels = <&adc 0>;
      	output-ohms = <22>;
      	full-ohms = <222>;
      };
      
      First, go to iio:deviceX for the "voltage-divider", do one read:
      $ cd /sys/bus/iio/devices/iio:deviceX
      $ cat in_voltage0_raw
      
      Then, unbind the consumer driver. It triggers above deadlock warning.
      $ cd /sys/bus/platform/drivers/iio-rescale/
      $ echo sysv > unbind
      
      Note I don't actually expect stable will pick this up all the
      way back into IIO being in staging, but if's probably valid that
      far back.
      Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
      Fixes: ac917a81 ("staging:iio:core set the iio_dev.info pointer to null on unregister")
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbe0bed4
    • G
      iio: adc: at91: disable adc channel interrupt in timeout case · 98171e19
      Georg Ottinger 提交于
      commit 09c6bdee51183a575bf7546890c8c137a75a2b44 upstream.
      
      Having a brief look at at91_adc_read_raw() it is obvious that in the case
      of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR registers is
      omitted. If 2 different channels are queried we can end up with a
      situation where two interrupts are enabled, but only one interrupt is
      cleared in the interrupt handler. Resulting in a interrupt loop and a
      system hang.
      Signed-off-by: NGeorg Ottinger <g.ottinger@abatec.at>
      Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98171e19
    • L
      iio: Fix scan mask selection · 36971130
      Lars-Peter Clausen 提交于
      commit 20ea39ef9f2f911bd01c69519e7d69cfec79fde3 upstream.
      
      The trialmask is expected to have all bits set to 0 after allocation.
      Currently kmalloc_array() is used which does not zero the memory and so
      random bits are set. This results in random channels being enabled when
      they shouldn't. Replace kmalloc_array() with kcalloc() which has the same
      interface but zeros the memory.
      
      Note the fix is actually required earlier than the below fixes tag, but
      will require a manual backport due to move from kmalloc to kmalloc_array.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NAlexandru Ardelean <alexandru.ardelean@analog.com>
      Fixes commit 057ac1ac ("iio: Use kmalloc_array() in iio_scan_mask_set()").
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36971130
    • J
      iio: dac: mcp4725: add missing powerdown bits in store eeprom · 0e47edde
      Jean-Francois Dagenais 提交于
      commit 06003531502d06bc89d32528f6ec96bf978790f9 upstream.
      
      When issuing the write DAC register and write eeprom command, the two
      powerdown bits (PD0 and PD1) are assumed by the chip to be present in
      the bytes sent. Leaving them at 0 implies "powerdown disabled" which is
      a different state that the current one. By adding the current state of
      the powerdown in the i2c write, the chip will correctly power-on exactly
      like as it is at the moment of store_eeprom call.
      
      This is documented in MCP4725's datasheet, FIGURE 6-2: "Write Commands
      for DAC Input Register and EEPROM" and MCP4726's datasheet, FIGURE 6-3:
      "Write All Memory Command".
      Signed-off-by: NJean-Francois Dagenais <jeff.dagenais@gmail.com>
      Acked-by: NPeter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e47edde
    • D
      iio: ad_sigma_delta: select channel when reading register · 5ad173ea
      Dragos Bogdan 提交于
      commit fccfb9ce70ed4ea7a145f77b86de62e38178517f upstream.
      
      The desired channel has to be selected in order to correctly fill the
      buffer with the corresponding data.
      The `ad_sd_write_reg()` already does this, but for the
      `ad_sd_read_reg_raw()` this was omitted.
      
      Fixes: af300848 ("iio:adc: Add common code for ADI Sigma Delta devices")
      Signed-off-by: NDragos Bogdan <dragos.bogdan@analog.com>
      Signed-off-by: NAlexandru Ardelean <alexandru.ardelean@analog.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ad173ea
    • G
      iio: cros_ec: Fix the maths for gyro scale calculation · 42eae0cf
      Gwendal Grignou 提交于
      commit 3d02d7082e5823598090530c3988a35f69689943 upstream.
      
      Calculation did not use IIO_DEGREE_TO_RAD and implemented a variant to
      avoid precision loss as we aim a nano value. The offset added to avoid
      rounding error, though, doesn't give us a close result to the expected
      value. E.g.
      
      For 1000dps, the result should be:
      
          (1000 * pi ) / 180 >> 15 ~= 0.000532632218
      
      But with current calculation we get
      
          $ cat scale
          0.000547890
      
      Fix the calculation by just doing the maths involved for a nano value
      
         val * pi * 10e12 / (180 * 2^15)
      
      so we get a closer result.
      
          $ cat scale
          0.000532632
      
      Fixes: c14dca07 ("iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver")
      Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
      Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42eae0cf
    • M
      iio:chemical:bme680: Fix SPI read interface · adfb0f0b
      Mike Looijmans 提交于
      commit 73f3bc6da506711302bb67572440eb84b1ec4a2c upstream.
      
      The SPI interface implementation was completely broken.
      
      When using the SPI interface, there are only 7 address bits, the upper bit
      is controlled by a page select register. The core needs access to both
      ranges, so implement register read/write for both regions. The regmap
      paging functionality didn't agree with a register that needs to be read
      and modified, so I implemented a custom paging algorithm.
      
      This fixes that the device wouldn't even probe in SPI mode.
      
      The SPI interface then isn't different from I2C, merged them into the core,
      and the I2C/SPI named registers are no longer needed.
      
      Implemented register value caching for the registers to reduce the I2C/SPI
      data transfers considerably.
      
      The calibration set reads as all zeroes until some undefined point in time,
      and I couldn't determine what makes it valid. The datasheet mentions these
      registers but does not provide any hints on when they become valid, and they
      aren't even enumerated in the memory map. So check the calibration and
      retry reading it from the device after each measurement until it provides
      something valid.
      
      Despite the size this is suitable for a stable backport given that
      it seems the SPI support never worked.
      Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
      Fixes: 1b3bd859 ("iio: chemical: Add support for Bosch BME680 sensor");
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adfb0f0b
    • M
      iio:chemical:bme680: Fix, report temperature in millidegrees · a3117576
      Mike Looijmans 提交于
      commit 9436f45dd53595e21566a8c6627411077dfdb776 upstream.
      
      The standard unit for temperature is millidegrees Celcius. Adapt the
      driver to report in millidegrees instead of degrees.
      Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
      Fixes: 1b3bd859 ("iio: chemical: Add support for Bosch BME680 sensor");
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3117576
    • M
      iio/gyro/bmg160: Use millidegrees for temperature scale · f7ee6890
      Mike Looijmans 提交于
      commit 40a7198a4a01037003c7ca714f0d048a61e729ac upstream.
      
      Standard unit for temperature is millidegrees Celcius, whereas this driver
      was reporting in degrees. Fix the scale factor in the driver.
      Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7ee6890
    • S
      iio: gyro: mpu3050: fix chip ID reading · 8bd3fd46
      Sergey Larin 提交于
      commit 409a51e0a4a5f908763191fae2c29008632eb712 upstream.
      
      According to the datasheet, the last bit of CHIP_ID register controls
      I2C bus, and the first one is unused. Handle this correctly.
      
      Note that there are chips out there that have a value such that
      the id check currently fails.
      Signed-off-by: NSergey Larin <cerg2010cerg2010@mail.ru>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8bd3fd46
    • M
      staging: iio: ad7192: Fix ad7193 channel address · 6f3e66b1
      Mircea Caprioru 提交于
      commit 7ce0f216221856a17fc4934b39284678a5fef2e9 upstream.
      
      This patch fixes the differential channels addresses for the ad7193.
      Signed-off-by: NMircea Caprioru <mircea.caprioru@analog.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f3e66b1
    • L
      Staging: iio: meter: fixed typo · c54d1258
      Leonard Pollak 提交于
      commit 0a8a29be499cbb67df79370aaf5109085509feb8 upstream.
      
      This patch fixes an obvious typo, which will cause erroneously returning the Peak
      Voltage instead of the Peak Current.
      Signed-off-by: NLeonard Pollak <leonardp@tr-host.de>
      Cc: <Stable@vger.kernel.org>
      Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c54d1258
    • V
      KVM: x86: svm: make sure NMI is injected after nmi_singlestep · c9e34935
      Vitaly Kuznetsov 提交于
      commit 99c221796a810055974b54c02e8f53297e48d146 upstream.
      
      I noticed that apic test from kvm-unit-tests always hangs on my EPYC 7401P,
      the hanging test nmi-after-sti is trying to deliver 30000 NMIs and tracing
      shows that we're sometimes able to deliver a few but never all.
      
      When we're trying to inject an NMI we may fail to do so immediately for
      various reasons, however, we still need to inject it so enable_nmi_window()
      arms nmi_singlestep mode. #DB occurs as expected, but we're not checking
      for pending NMIs before entering the guest and unless there's a different
      event to process, the NMI will never get delivered.
      
      Make KVM_REQ_EVENT request on the vCPU from db_interception() to make sure
      pending NMIs are checked and possibly injected.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9e34935
    • S
      KVM: x86: Don't clear EFER during SMM transitions for 32-bit vCPU · 18cf09a8
      Sean Christopherson 提交于
      commit 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de upstream.
      
      Neither AMD nor Intel CPUs have an EFER field in the legacy SMRAM save
      state area, i.e. don't save/restore EFER across SMM transitions.  KVM
      somewhat models this, e.g. doesn't clear EFER on entry to SMM if the
      guest doesn't support long mode.  But during RSM, KVM unconditionally
      clears EFER so that it can get back to pure 32-bit mode in order to
      start loading CRs with their actual non-SMM values.
      
      Clear EFER only when it will be written when loading the non-SMM state
      so as to preserve bits that can theoretically be set on 32-bit vCPUs,
      e.g. KVM always emulates EFER_SCE.
      
      And because CR4.PAE is cleared only to play nice with EFER, wrap that
      code in the long mode check as well.  Note, this may result in a
      compiler warning about cr4 being consumed uninitialized.  Re-read CR4
      even though it's technically unnecessary, as doing so allows for more
      readable code and RSM emulation is not a performance critical path.
      
      Fixes: 660a5d51 ("KVM: x86: save/load state on SMM switch")
      Cc: stable@vger.kernel.org
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18cf09a8
    • R
      cifs: fix handle leak in smb2_query_symlink() · 2fcee5ea
      Ronnie Sahlberg 提交于
      commit e6d0fb7b34f264f72c33053558a360a6a734905e upstream.
      
      If we enter smb2_query_symlink() for something that is not a symlink
      and where the SMB2_open() would succeed we would never end up
      closing this handle and would thus leak a handle on the server.
      
      Fix this by immediately calling SMB2_close() on successfull open.
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fcee5ea
    • Z
      cifs: Fix use-after-free in SMB2_read · c69330a8
      ZhangXiaoxu 提交于
      commit 088aaf17aa79300cab14dbee2569c58cfafd7d6e upstream.
      
      There is a KASAN use-after-free:
      BUG: KASAN: use-after-free in SMB2_read+0x1136/0x1190
      Read of size 8 at addr ffff8880b4e45e50 by task ln/1009
      
      Should not release the 'req' because it will use in the trace.
      
      Fixes: eccb4422 ("smb3: Add ftrace tracepoints for improved SMB3 debugging")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org> 4.18+
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c69330a8
    • Z
      cifs: Fix use-after-free in SMB2_write · 8fb89b43
      ZhangXiaoxu 提交于
      commit 6a3eb3360667170988f8a6477f6686242061488a upstream.
      
      There is a KASAN use-after-free:
      BUG: KASAN: use-after-free in SMB2_write+0x1342/0x1580
      Read of size 8 at addr ffff8880b6a8e450 by task ln/4196
      
      Should not release the 'req' because it will use in the trace.
      
      Fixes: eccb4422 ("smb3: Add ftrace tracepoints for improved SMB3 debugging")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org> 4.18+
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fb89b43
    • A
      CIFS: keep FileInfo handle live during oplock break · 8092ecc3
      Aurelien Aptel 提交于
      commit b98749cac4a695f084a5ff076f4510b23e353ecd upstream.
      
      In the oplock break handler, writing pending changes from pages puts
      the FileInfo handle. If the refcount reaches zero it closes the handle
      and waits for any oplock break handler to return, thus causing a deadlock.
      
      To prevent this situation:
      
      * We add a wait flag to cifsFileInfo_put() to decide whether we should
        wait for running/pending oplock break handlers
      
      * We keep an additionnal reference of the SMB FileInfo handle so that
        for the rest of the handler putting the handle won't close it.
        - The ref is bumped everytime we queue the handler via the
          cifs_queue_oplock_break() helper.
        - The ref is decremented at the end of the handler
      
      This bug was triggered by xfstest 464.
      
      Also important fix to address the various reports of
      oops in smb2_push_mandatory_locks
      Signed-off-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8092ecc3
    • P
      net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c · 6e2081f2
      Peter Oskolkov 提交于
      [ Upstream commit 997dd96471641e147cb2c33ad54284000d0f5e35 ]
      
      Currently, IPv6 defragmentation code drops non-last fragments that
      are smaller than 1280 bytes: see
      commit 0ed4229b ("ipv6: defrag: drop non-last frags smaller than min mtu")
      
      This behavior is not specified in IPv6 RFCs and appears to break
      compatibility with some IPv6 implemenations, as reported here:
      https://www.spinics.net/lists/netdev/msg543846.html
      
      This patch re-uses common IP defragmentation queueing and reassembly
      code in IP6 defragmentation in nf_conntrack, removing the 1280 byte
      restriction.
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Reported-by: NTom Herbert <tom@herbertland.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6e2081f2
    • P
      net: IP6 defrag: use rbtrees for IPv6 defrag · 68468532
      Peter Oskolkov 提交于
      [ Upstream commit d4289fcc9b16b89619ee1c54f829e05e56de8b9a ]
      
      Currently, IPv6 defragmentation code drops non-last fragments that
      are smaller than 1280 bytes: see
      commit 0ed4229b ("ipv6: defrag: drop non-last frags smaller than min mtu")
      
      This behavior is not specified in IPv6 RFCs and appears to break
      compatibility with some IPv6 implemenations, as reported here:
      https://www.spinics.net/lists/netdev/msg543846.html
      
      This patch re-uses common IP defragmentation queueing and reassembly
      code in IPv6, removing the 1280 byte restriction.
      
      v2: change handling of overlaps to match that of upstream.
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Reported-by: NTom Herbert <tom@herbertland.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      68468532
    • P
      net: IP defrag: encapsulate rbtree defrag code into callable functions · 702ddf86
      Peter Oskolkov 提交于
      [ Upstream commit c23f35d19db3b36ffb9e04b08f1d91565d15f84f ]
      
      This is a refactoring patch: without changing runtime behavior,
      it moves rbtree-related code from IPv4-specific files/functions
      into .h/.c defrag files shared with IPv6 defragmentation code.
      
      v2: make handling of overlapping packets match upstream.
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      702ddf86
    • T
      sch_cake: Simplify logic in cake_select_tin() · e24be8e3
      Toke Høiland-Jørgensen 提交于
      [ Upstream commit 4976e3c683f328bc6f2edef555a4ffee6524486f ]
      
      The logic in cake_select_tin() was getting a bit hairy, and it turns out we
      can simplify it quite a bit. This also allows us to get rid of one of the
      two diffserv parsing functions, which has the added benefit that
      already-zeroed DSCP fields won't get re-written.
      Suggested-by: NKevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e24be8e3
    • P
      nfp: flower: remove vlan CFI bit from push vlan action · 8d9051a4
      Pieter Jansen van Vuuren 提交于
      [ Upstream commit 42cd5484a22f1a1b947e21e2af65fa7dab09d017 ]
      
      We no longer set CFI when pushing vlan tags, therefore we remove
      the CFI bit from push vlan.
      
      Fixes: 1a1e586f ("nfp: add basic action capabilities to flower offloads")
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Signed-off-by: NLouis Peens <louis.peens@netronome.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d9051a4
    • P
      nfp: flower: replace CFI with vlan present · 06f7d218
      Pieter Jansen van Vuuren 提交于
      [ Upstream commit f7ee799a51ddbcc205ef615fe424fb5084e9e0aa ]
      
      Replace vlan CFI bit with a vlan present bit that indicates the
      presence of a vlan tag. Previously the driver incorrectly assumed
      that an vlan id of 0 is not matchable, therefore we indicate vlan
      presence with a vlan present bit.
      
      Fixes: 5571e8c9 ("nfp: extend flower matching capabilities")
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Signed-off-by: NLouis Peens <louis.peens@netronome.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06f7d218
    • T
      sch_cake: Make sure we can write the IP header before changing DSCP bits · cbce0413
      Toke Høiland-Jørgensen 提交于
      [ Upstream commit c87b4ecdbe8db27867a7b7f840291cd843406bd7 ]
      
      There is not actually any guarantee that the IP headers are valid before we
      access the DSCP bits of the packets. Fix this using the same approach taken
      in sch_dsmark.
      Reported-by: NKevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbce0413
    • T
      sch_cake: Use tc_skb_protocol() helper for getting packet protocol · 49053222
      Toke Høiland-Jørgensen 提交于
      [ Upstream commit b2100cc56fca8c51d28aa42a9f1fbcb2cf351996 ]
      
      We shouldn't be using skb->protocol directly as that will miss cases with
      hardware-accelerated VLAN tags. Use the helper instead to get the right
      protocol number.
      Reported-by: NKevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49053222