Skip to content
Snippets Groups Projects
  1. Jul 03, 2024
  2. Jun 26, 2024
  3. Jan 23, 2024
  4. Sep 06, 2023
  5. May 24, 2023
  6. May 23, 2023
  7. Mar 30, 2023
    • Jens Axboe's avatar
      iov_iter: add iter_iovec() helper · de4f5fed
      Jens Axboe authored
      
      This returns a pointer to the current iovec entry in the iterator. Only
      useful with ITER_IOVEC right now, but it prepares us to treat ITER_UBUF
      and ITER_IOVEC identically for the first segment.
      
      Rename struct iov_iter->iov to iov_iter->__iov to find any potentially
      troublesome spots, and also to prevent anyone from adding new code that
      accesses iter->iov directly.
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      de4f5fed
  8. Mar 29, 2023
  9. Feb 20, 2023
  10. Jan 29, 2023
  11. Jan 11, 2023
  12. Nov 09, 2022
  13. Oct 25, 2022
  14. Sep 30, 2022
  15. Sep 05, 2022
  16. Aug 22, 2022
  17. Aug 09, 2022
  18. Apr 23, 2022
  19. Apr 18, 2022
  20. Feb 17, 2022
  21. Sep 03, 2021
    • Christoph Hellwig's avatar
      mm: remove flush_kernel_dcache_page · f358afc5
      Christoph Hellwig authored
      flush_kernel_dcache_page is a rather confusing interface that implements a
      subset of flush_dcache_page by not being able to properly handle page
      cache mapped pages.
      
      The only callers left are in the exec code as all other previous callers
      were incorrect as they could have dealt with page cache pages.  Replace
      the calls to flush_kernel_dcache_page with calls to flush_dcache_page,
      which for all architectures does either exactly the same thing, can
      contains one or more of the following:
      
       1) an optimization to defer the cache flush for page cache pages not
          mapped into userspace
       2) additional flushing for mapped page cache pages if cache aliases
          are possible
      
      Link: https://lkml.kernel.org/r/20210712060928.4161649-7-hch@lst.de
      
      
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Cc: Alex Shi <alexs@kernel.org>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Paul Cercueil <paul@crapouillou.net>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Vincent Chen <deanbo422@gmail.com>
      Cc: Yoshinori Sato <ysato@users.osdn.me>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f358afc5
  22. Aug 02, 2021
  23. Apr 12, 2021
  24. Apr 06, 2021
  25. Mar 11, 2021
  26. Feb 26, 2021
  27. Sep 23, 2020
  28. Sep 01, 2020
  29. May 14, 2020
    • Satya Tangirala's avatar
      block: Inline encryption support for blk-mq · a892c8d5
      Satya Tangirala authored
      
      We must have some way of letting a storage device driver know what
      encryption context it should use for en/decrypting a request. However,
      it's the upper layers (like the filesystem/fscrypt) that know about and
      manages encryption contexts. As such, when the upper layer submits a bio
      to the block layer, and this bio eventually reaches a device driver with
      support for inline encryption, the device driver will need to have been
      told the encryption context for that bio.
      
      We want to communicate the encryption context from the upper layer to the
      storage device along with the bio, when the bio is submitted to the block
      layer. To do this, we add a struct bio_crypt_ctx to struct bio, which can
      represent an encryption context (note that we can't use the bi_private
      field in struct bio to do this because that field does not function to pass
      information across layers in the storage stack). We also introduce various
      functions to manipulate the bio_crypt_ctx and make the bio/request merging
      logic aware of the bio_crypt_ctx.
      
      We also make changes to blk-mq to make it handle bios with encryption
      contexts. blk-mq can merge many bios into the same request. These bios need
      to have contiguous data unit numbers (the necessary changes to blk-merge
      are also made to ensure this) - as such, it suffices to keep the data unit
      number of just the first bio, since that's all a storage driver needs to
      infer the data unit number to use for each data block in each bio in a
      request. blk-mq keeps track of the encryption context to be used for all
      the bios in a request with the request's rq_crypt_ctx. When the first bio
      is added to an empty request, blk-mq will program the encryption context
      of that bio into the request_queue's keyslot manager, and store the
      returned keyslot in the request's rq_crypt_ctx. All the functions to
      operate on encryption contexts are in blk-crypto.c.
      
      Upper layers only need to call bio_crypt_set_ctx with the encryption key,
      algorithm and data_unit_num; they don't have to worry about getting a
      keyslot for each encryption context, as blk-mq/blk-crypto handles that.
      Blk-crypto also makes it possible for request-based layered devices like
      dm-rq to make use of inline encryption hardware by cloning the
      rq_crypt_ctx and programming a keyslot in the new request_queue when
      necessary.
      
      Note that any user of the block layer can submit bios with an
      encryption context, such as filesystems, device-mapper targets, etc.
      
      Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
      Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      a892c8d5
Loading