1. 09 Mar, 2022 3 commits
  2. 08 Mar, 2022 10 commits
  3. 07 Mar, 2022 6 commits
    • Linus Torvalds's avatar
      Merge tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux · ea4424be
      Linus Torvalds authored
      Pull MTD fix from Miquel Raynal:
       "As part of a previous changeset introducing support for the K3
        architecture, the OMAP_GPMC (a non visible symbol) got selected by the
        selection of MTD_NAND_OMAP2 instead of doing so from the architecture
        directly (like for the other users of these two drivers). Indeed, from
        a hardware perspective, the OMAP NAND controller needs the GPMC to
        work.
      
        This led to a robot error which got addressed in fix merge into -rc4.
        Unfortunately, the approach at this time still used "select" and lead
        to further build error reports (sparc64:allmodconfig).
      
        This time we switch to 'depends on' in order to prevent random
        misconfigurations. The different dependencies will however need a
        future cleanup"
      
      * tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
        mtd: rawnand: omap2: Actually prevent invalid configuration and build error
      ea4424be
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · 06be3029
      Linus Torvalds authored
      Pull virtio fixes from Michael Tsirkin:
       "Some last minute fixes that took a while to get ready. Not
        regressions, but they look safe and seem to be worth to have"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        tools/virtio: handle fallout from folio work
        tools/virtio: fix virtio_test execution
        vhost: remove avail_event arg from vhost_update_avail_event()
        virtio: drop default for virtio-mem
        vdpa: fix use-after-free on vp_vdpa_remove
        virtio-blk: Remove BUG_ON() in virtio_queue_rq()
        virtio-blk: Don't use MAX_DISCARD_SEGMENTS if max_discard_seg is zero
        vhost: fix hung thread due to erroneous iotlb entries
        vduse: Fix returning wrong type in vduse_domain_alloc_iova()
        vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
        vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
        vdpa: factor out vdpa_set_features_unlocked for vdpa internal use
        virtio_console: break out of buf poll on remove
        virtio: document virtio_reset_device
        virtio: acknowledge all features before access
        virtio: unexport virtio_finalize_features
      06be3029
    • Halil Pasic's avatar
      swiotlb: rework "fix info leak with DMA_FROM_DEVICE" · aa6f8dcb
      Halil Pasic authored
      Unfortunately, we ended up merging an old version of the patch "fix info
      leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph
      (the swiotlb maintainer), he asked me to create an incremental fix
      (after I have pointed this out the mix up, and asked him for guidance).
      So here we go.
      
      The main differences between what we got and what was agreed are:
      * swiotlb_sync_single_for_device is also required to do an extra bounce
      * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters
      * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE
        must take precedence over DMA_ATTR_SKIP_CPU_SYNC
      
      Thus this patch removes DMA_ATTR_OVERWRITE, and makes
      swiotlb_sync_single_for_device() bounce unconditionally (that is, also
      when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
      data from the swiotlb buffer.
      
      Let me note, that if the size used with dma_sync_* API is less than the
      size used with dma_[un]map_*, under certain circumstances we may still
      end up with swiotlb not being transparent. In that sense, this is no
      perfect fix either.
      
      To get this bullet proof, we would have to bounce the entire
      mapping/bounce buffer. For that we would have to figure out the starting
      address, and the size of the mapping in
      swiotlb_sync_single_for_device(). While this does seem possible, there
      seems to be no firm consensus on how things are supposed to work.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Fixes: ddbd89de ("swiotlb: fix info leak with DMA_FROM_DEVICE")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aa6f8dcb
    • James Morse's avatar
      arm64: proton-pack: Include unprivileged eBPF status in Spectre v2 mitigation reporting · 58c9a506
      James Morse authored
      The mitigations for Spectre-BHB are only applied when an exception is
      taken from user-space. The mitigation status is reported via the spectre_v2
      sysfs vulnerabilities file.
      
      When unprivileged eBPF is enabled the mitigation in the exception vectors
      can be avoided by an eBPF program.
      
      When unprivileged eBPF is enabled, print a warning and report vulnerable
      via the sysfs vulnerabilities file.
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      58c9a506
    • Roger Quadros's avatar
      mtd: rawnand: omap2: Actually prevent invalid configuration and build error · 42da5a4b
      Roger Quadros authored
      The root of the problem is that we are selecting symbols that have
      dependencies. This can cause random configurations that can fail.
      The cleanest solution is to avoid using select.
      
      This driver uses interfaces from the OMAP_GPMC driver so we have to
      depend on it instead.
      
      Fixes: 4cd335da ("mtd: rawnand: omap2: Prevent invalid configuration and build error")
      Signed-off-by: default avatarRoger Quadros <rogerq@kernel.org>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Link: https://lore.kernel.org/linux-mtd/20220219193600.24892-1-rogerq@kernel.org
      42da5a4b
    • Miklos Szeredi's avatar
      fuse: fix pipe buffer lifetime for direct_io · 0c4bcfde
      Miklos Szeredi authored
      In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls
      fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then
      imports the write buffer with fuse_get_user_pages(), which uses
      iov_iter_get_pages() to grab references to userspace pages instead of
      actually copying memory.
      
      On the filesystem device side, these pages can then either be read to
      userspace (via fuse_dev_read()), or splice()d over into a pipe using
      fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops.
      
      This is wrong because after fuse_dev_do_read() unlocks the FUSE request,
      the userspace filesystem can mark the request as completed, causing write()
      to return. At that point, the userspace filesystem should no longer have
      access to the pipe buffer.
      
      Fix by copying pages coming from the user address space to new pipe
      buffers.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Fixes: c3021629 ("fuse: support splice() reading from fuse device")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      0c4bcfde
  4. 06 Mar, 2022 13 commits
  5. 05 Mar, 2022 8 commits