26 Jan, 2021

6 commits


25 Jan, 2021

2 commits


22 Jan, 2021

9 commits


21 Jan, 2021

3 commits

  • In case no job rings are available, secure memory structures are not
    initialized, since caam_jr_probe()->init_misc_func()->caam_sm_startup()
    is not called.
    This could happen if all job ring devices bind to the jr uio driver
    instead of the caam/jr driver.
    Running sm_test in this case will lead to a crash.

    Add a check to verify that SM has been initialized - if not the tests
    will be skipped.

    Reported-by: Gaurav Jain
    Signed-off-by: Horia Geantă
    Reviewed-by: Gaurav Jain

    Horia Geantă
     
  • Introduction
    ===

    Currently we are facing some limitations in the caam/jr module lifecycle.
    There are some discussion in upstream:
    Link: https://lore.kernel.org/linux-crypto/20190904023515.7107-13-andrew.smirnov@gmail.com
    Link: https://lore.kernel.org/linux-crypto/20191105151353.6522-1-andrew.smirnov@gmail.com
    but in the end it all seems to get down to implementations not being able
    to gracefully unregister crypto algorithms from crypto API while there are
    users / allocated tfms (cra_refcnt > 1).

    [*] OTOH functionalities in caam/jr that don't interact with crypto API
    (like Secure Memory or black keys / blobs generation) don't face this
    limitation.

    Issue at hand
    ===

    When unloading the caam_jr module, the .remove callback for the last JR
    device exits with -EBUSY (see "Introduction" above) and doesn't perform
    the clean-up (crypto algorithms unregistering etc.).

    One side effect of this is leeding to an oops, which occurs due to a
    corruption in the linked list of "misc devices"
    (drivers/char/misc.c - misc_list):
    1. caam_jr module is unloaded without calling unregister_algs()->
    caam_keygen_exit()->misc_deregister() for the last job ring device;
    this leaves a dangling entry in the misc_list double-linked list
    2. rng_core module is unloaded and calls misc_deregister(); this implies
    removing the corresponding entry in the misc_list; while doing this the
    dangling entry is accessed - which leads to an oops since the address is
    no longer valid (address points to the caam_jr module address space,
    but caam_jr has been previously unloaded).

    Fix this by moving the clean-up of non-crypto related functionalities [*]
    before crypto related ones.

    Fixes: 3af836d4b311 ("MLK-24420-3 crypto: caam - add ioctl calls for black keys and blobs generation")
    Signed-off-by: Horia Geantă
    Reviewed-by: Gaurav Jain

    Horia Geantă
     
  • In case of long format of qDMA command descriptor, there are one frame
    descriptor, three entries in the frame list and two data entries. So the
    size of dma_pool_create for these three fields should be the same with
    the total size of entries respectively, or the contents may be overwritten
    by the next allocated descriptor.

    Signed-off-by: Guanhua Gao

    Guanhua Gao
     

20 Jan, 2021

20 commits

  • This is the 5.10.9 stable release

    * tag 'v5.10.9': (153 commits)
    Linux 5.10.9
    netfilter: nf_nat: Fix memleak in nf_nat_init
    netfilter: conntrack: fix reading nf_conntrack_buckets
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.10.8 stable release

    * tag 'v5.10.8': (104 commits)
    Linux 5.10.8
    tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
    drm/panfrost: Remove unused variables in panfrost_job_close()
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.10.7 stable release

    * tag 'v5.10.7': (144 commits)
    Linux 5.10.7
    scsi: target: Fix XCOPY NAA identifier lookup
    rtlwifi: rise completion at the last step of firmware callback
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.10.6 stable release

    * tag 'v5.10.6': (21 commits)
    Linux 5.10.6
    mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
    exec: Transform exec_update_mutex into a rw_semaphore
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/rtc/rtc-pcf2127.c

    Jason Liu
     
  • This is the 5.10.5 stable release

    * tag 'v5.10.5': (63 commits)
    Linux 5.10.5
    device-dax: Fix range release
    ext4: avoid s_mb_prefetch to be zero in individual scenarios
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is a gpio driver to control the PINs which are managed by scu fw.

    Signed-off-by: Shenwei Wang

    Shenwei Wang
     
  • commit 0378c625afe80eb3f212adae42cc33c9f6f31abf upstream.

    There wasn't ever a real need to log an error in the kernel log for
    ioctls issued with insufficient permissions. Simply return an error
    and if an admin/user is sufficiently motivated they can enable DM's
    dynamic debugging to see an explanation for why the ioctls were
    disallowed.

    Reported-by: Nir Soffer
    Fixes: e980f62353c6 ("dm: don't allow ioctls to targets that don't map to whole devices")
    Signed-off-by: Mike Snitzer
    Signed-off-by: Greg Kroah-Hartman

    Mike Snitzer
     
  • commit 2d6ffc63f12417b979955a5b22ad9a76d2af5de9 upstream.

    The VT-d hardware will ignore those Addr bits which have been masked by
    the AM field in the PASID-based-IOTLB invalidation descriptor. As the
    result, if the starting address in the descriptor is not aligned with
    the address mask, some IOTLB caches might not invalidate. Hence people
    will see below errors.

    [ 1093.704661] dmar_fault: 29 callbacks suppressed
    [ 1093.704664] DMAR: DRHD: handling fault status reg 3
    [ 1093.712738] DMAR: [DMA Read] Request device [7a:02.0] PASID 2
    fault addr 7f81c968d000 [fault reason 113]
    SM: Present bit in first-level paging entry is clear

    Fix this by using aligned address for PASID-based-IOTLB invalidation.

    Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable mode")
    Reported-and-tested-by: Guo Kaijie
    Signed-off-by: Lu Baolu
    Link: https://lore.kernel.org/r/20201231005323.2178523-2-baolu.lu@linux.intel.com
    Signed-off-by: Will Deacon
    Signed-off-by: Greg Kroah-Hartman

    Lu Baolu
     
  • commit 09aa9e45863e9e25dfbf350bae89fc3c2964482c upstream.

    The mitigation is required for all gen7 platforms, now that it does not
    cause GPU hangs, restore it for Ivybridge and Baytrail.

    Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
    Signed-off-by: Chris Wilson
    Cc: Mika Kuoppala
    Cc: Prathap Kumar Valsan
    Cc: Akeem G Abodunrin
    Cc: Bloomfield Jon
    Reviewed-by: Akeem G Abodunrin
    Reviewed-by: Rodrigo Vivi
    Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk
    (cherry picked from commit 008ead6ef8f588a8c832adfe9db201d9be5fd410)
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Chris Wilson
     
  • commit 2af5268180410b874fc06be91a1b2fbb22b1be0c upstream.

    For an enabled DSC during HW readout the corresponding power reference
    is taken along the CRTC power domain references in
    get_crtc_power_domains(). Remove the incorrect get ref from the DSI
    encoder hook.

    Fixes: 2b68392e638d ("drm/i915/dsi: add support for DSC")
    Cc: Vandita Kulkarni
    Cc: Jani Nikula
    Signed-off-by: Imre Deak
    Reviewed-by: Anshuman Gupta
    Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com
    (cherry picked from commit 3a9ec563a4ff770ae647f6ee539810f1866866c9)
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Imre Deak
     
  • …eset-deassert MIPI-sequence

    commit 00cb645fd7e29bdd20967cd20fa8f77bcdf422f9 upstream.

    Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
    added an intel_dsi_msleep() helper which skips sleeping if the
    MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
    and it moved a bunch of msleep-s over to this new helper.

    This was based on my reading of the big comment around line 730 which
    starts with "Panel enable/disable sequences from the VBT spec.",
    where the "v3 video mode seq" column does not have any wait t# entries.

    Given that this code has been used on a lot of different devices without
    issues until now, it seems that my interpretation of the spec here is
    mostly correct.

    But now I have encountered one device, an Acer Aspire Switch 10 E
    SW3-016, where the panel will not light up unless we do actually honor the
    panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.

    What seems to set this model apart is that it is lacking a
    MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
    delay usually happens.

    Fix the panel not lighting up on this model by using an unconditional
    msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
    no MIPI_SEQ_DEASSERT_RESET sequence.

    Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com
    (cherry picked from commit 6fdb335f1c9c0845b50625de1624d8445c4c4a07)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Hans de Goede
     
  • commit b690bd546b227c32b860dae985a18bed8aa946fe upstream.

    Without crc32 support, this driver fails to link:

    arm-linux-gnueabi-ld: drivers/md/dm-zoned-metadata.o: in function `dmz_write_sb':
    dm-zoned-metadata.c:(.text+0xe98): undefined reference to `crc32_le'
    arm-linux-gnueabi-ld: drivers/md/dm-zoned-metadata.o: in function `dmz_check_sb':
    dm-zoned-metadata.c:(.text+0x7978): undefined reference to `crc32_le'

    Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
    Signed-off-by: Arnd Bergmann
    Reviewed-by: Damien Le Moal
    Signed-off-by: Mike Snitzer
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     
  • commit 2cb091f6293df898b47f4e0f2e54324e2bbaf816 upstream.

    When set_has_smi_cap() fails, multiport master cleanup is missed. Fix it
    by doing the correct error unwinding goto.

    Fixes: a989ea01cb10 ("RDMA/mlx5: Move SMI caps logic")
    Link: https://lore.kernel.org/r/20210113121703.559778-3-leon@kernel.org
    Signed-off-by: Parav Pandit
    Signed-off-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Greg Kroah-Hartman

    Parav Pandit
     
  • commit 1c3aa6bd0b823105c2030af85d92d158e815d669 upstream.

    If the allocation of the fast path blue flame register fails, the driver
    should free the regular blue flame register allocated a statement above,
    not the one that it just failed to allocate.

    Fixes: 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add and remove stages")
    Link: https://lore.kernel.org/r/20210113121703.559778-6-leon@kernel.org
    Reported-by: Hans Petter Selasky
    Signed-off-by: Mark Bloch
    Signed-off-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Greg Kroah-Hartman

    Mark Bloch
     
  • commit 869c4d5eb1e6fbda66aa790c48bdb946d71494a0 upstream.

    The function bnxt_get_ulp_stat_ctxs() does not count the stats contexts
    used by the RDMA driver correctly when the RDMA driver is freeing the
    MSIX vectors. It assumes that if the RDMA driver is registered, the
    additional stats contexts will be needed. This is not true when the
    RDMA driver is about to unregister and frees the MSIX vectors.

    This slight error leads to over accouting of the stats contexts needed
    after the RDMA driver has unloaded. This will cause some firmware
    warning and error messages in dmesg during subsequent config. changes
    or ifdown/ifup.

    Fix it by properly accouting for extra stats contexts only if the
    RDMA driver is registered and MSIX vectors have been successfully
    requested.

    Fixes: c027c6b4e91f ("bnxt_en: get rid of num_stat_ctxs variable")
    Reviewed-by: Yongping Zhang
    Reviewed-by: Pavan Chebbi
    Signed-off-by: Michael Chan
    Signed-off-by: Jakub Kicinski
    Signed-off-by: Greg Kroah-Hartman

    Michael Chan
     
  • commit a306aba9c8d869b1fdfc8ad9237f1ed718ea55e6 upstream.

    If usnic_ib_qp_grp_create() fails at the first call, dev_list
    will not be freed on error, which leads to memleak.

    Fixes: e3cf00d0a87f ("IB/usnic: Add Cisco VIC low-level hardware driver")
    Link: https://lore.kernel.org/r/20201226074248.2893-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Dinghao Liu
    Reviewed-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Greg Kroah-Hartman

    Dinghao Liu
     
  • commit 3c638cdb8ecc0442552156e0fed8708dd2c7f35b upstream.

    xa_alloc_cyclic() call returns positive number if ID allocation
    succeeded but wrapped. It is not an error, so normalize the "ret"
    variable to zero as marker of not-an-error.

    drivers/infiniband/core/restrack.c:261 rdma_restrack_add()
    warn: 'ret' can be either negative or positive

    Fixes: fd47c2f99f04 ("RDMA/restrack: Convert internal DB from hash to XArray")
    Link: https://lore.kernel.org/r/20201216100753.1127638-1-leon@kernel.org
    Reported-by: Dan Carpenter
    Signed-off-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Greg Kroah-Hartman

    Leon Romanovsky
     
  • commit 1d53864c3617f5235f891ca0fbe9347c4cd35d46 upstream.

    Currently if device needs to do flush or BKOP operations, the device VCC
    power is kept during runtime-suspend period.

    However, if system suspend is happening while device is runtime-suspended,
    such power may not be disabled successfully.

    The reasons may be,

    1. If current PM level is the same as SPM level, device will keep
    runtime-suspended by ufshcd_system_suspend().

    2. Flush recheck work may not be scheduled successfully during system
    suspend period. If it can wake up the system, this is also not the
    intention of the recheck work.

    To fix this issue, simply runtime-resume the device if the flush is allowed
    during runtime suspend period. Flush capability will be disabled while
    leaving runtime suspend, and also not be allowed in system suspend period.

    Link: https://lore.kernel.org/r/20201222072905.32221-2-stanley.chu@mediatek.com
    Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend")
    Reviewed-by: Chaotian Jing
    Reviewed-by: Can Guo
    Signed-off-by: Stanley Chu
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Greg Kroah-Hartman

    Stanley Chu
     
  • commit ada831772188192243f9ea437c46e37e97a5975d upstream.

    We shouldn't call smp_processor_id() in a preemptible
    context, but this is advisory at best, so instead
    call __smp_processor_id().

    Fixes: db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq context")
    Reported-by: Or Gerlitz
    Reported-by: Yi Zhang
    Signed-off-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Greg Kroah-Hartman

    Sagi Grimberg
     
  • commit ca1ff67d0fb14f39cf0cc5102b1fbcc3b14f6fb9 upstream.

    When a bio merges, we can get a request that spans multiple
    bios, and the overall request payload size is the sum of
    all bios. When we calculate how much we need to send
    from the existing bio (and bvec), we did not take into
    account the iov_iter byte count cap.

    Since multipage bvecs support, bvecs can split in the middle
    which means that when we account for the last bvec send we
    should also take the iov_iter byte count cap as it might be
    lower than the last bvec size.

    Reported-by: Hao Wang
    Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
    Tested-by: Hao Wang
    Signed-off-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Greg Kroah-Hartman

    Sagi Grimberg