1. 22 11月, 2019 1 次提交
    • K
      block: add iostat counters for flush requests · b6866318
      Konstantin Khlebnikov 提交于
      Requests that triggers flushing volatile writeback cache to disk (barriers)
      have significant effect to overall performance.
      
      Block layer has sophisticated engine for combining several flush requests
      into one. But there is no statistics for actual flushes executed by disk.
      Requests which trigger flushes usually are barriers - zero-size writes.
      
      This patch adds two iostat counters into /sys/class/block/$dev/stat and
      /proc/diskstats - count of completed flush requests and their total time.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b6866318
  2. 16 11月, 2019 1 次提交
    • M
      dm integrity: fix excessive alignment of metadata runs · d537858a
      Mikulas Patocka 提交于
      Metadata runs are supposed to be aligned on 4k boundary (so that they work
      efficiently with disks with 4k sectors). However, there was a programming
      bug that makes them aligned on 128k boundary instead. The unused space is
      wasted.
      
      Fix this bug by providing a proper 4k alignment. In order to keep
      existing volumes working, we introduce a new flag SB_FLAG_FIXED_PADDING
      - when the flag is clear, we calculate the padding the old way. In order
      to make sure that the old version cannot mount the volume created by the
      new version, we increase superblock version to 4.
      
      Also in order to not break with old integritysetup, we fix alignment
      only if the parameter "fix_padding" is present when formatting the
      device.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      d537858a
  3. 14 11月, 2019 2 次提交
  4. 13 11月, 2019 1 次提交
  5. 07 11月, 2019 1 次提交
    • E
      fscrypt: add support for IV_INO_LBLK_64 policies · b103fb76
      Eric Biggers 提交于
      Inline encryption hardware compliant with the UFS v2.1 standard or with
      the upcoming version of the eMMC standard has the following properties:
      
      (1) Per I/O request, the encryption key is specified by a previously
          loaded keyslot.  There might be only a small number of keyslots.
      
      (2) Per I/O request, the starting IV is specified by a 64-bit "data unit
          number" (DUN).  IV bits 64-127 are assumed to be 0.  The hardware
          automatically increments the DUN for each "data unit" of
          configurable size in the request, e.g. for each filesystem block.
      
      Property (1) makes it inefficient to use the traditional fscrypt
      per-file keys.  Property (2) precludes the use of the existing
      DIRECT_KEY fscrypt policy flag, which needs at least 192 IV bits.
      
      Therefore, add a new fscrypt policy flag IV_INO_LBLK_64 which causes the
      encryption to modified as follows:
      
      - The encryption keys are derived from the master key, encryption mode
        number, and filesystem UUID.
      
      - The IVs are chosen as (inode_number << 32) | file_logical_block_num.
        For filenames encryption, file_logical_block_num is 0.
      
      Since the file nonces aren't used in the key derivation, many files may
      share the same encryption key.  This is much more efficient on the
      target hardware.  Including the inode number in the IVs and mixing the
      filesystem UUID into the keys ensures that data in different files is
      nevertheless still encrypted differently.
      
      Additionally, limiting the inode and block numbers to 32 bits and
      placing the block number in the low bits maintains compatibility with
      the 64-bit DUN convention (property (2) above).
      
      Since this scheme assumes that inode numbers are stable (which may
      preclude filesystem shrinking) and that inode and file logical block
      numbers are at most 32-bit, IV_INO_LBLK_64 will only be allowed on
      filesystems that meet these constraints.  These are acceptable
      limitations for the cases where this format would actually be used.
      
      Note that IV_INO_LBLK_64 is an on-disk format, not an implementation.
      This patch just adds support for it using the existing filesystem layer
      encryption.  A later patch will add support for inline encryption.
      Reviewed-by: NPaul Crowley <paulcrowley@google.com>
      Co-developed-by: NSatya Tangirala <satyat@google.com>
      Signed-off-by: NSatya Tangirala <satyat@google.com>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      b103fb76
  6. 06 11月, 2019 2 次提交
  7. 05 11月, 2019 5 次提交
  8. 04 11月, 2019 2 次提交
    • P
      kvm: mmu: ITLB_MULTIHIT mitigation · b8e8c830
      Paolo Bonzini 提交于
      With some Intel processors, putting the same virtual address in the TLB
      as both a 4 KiB and 2 MiB page can confuse the instruction fetch unit
      and cause the processor to issue a machine check resulting in a CPU lockup.
      
      Unfortunately when EPT page tables use huge pages, it is possible for a
      malicious guest to cause this situation.
      
      Add a knob to mark huge pages as non-executable. When the nx_huge_pages
      parameter is enabled (and we are using EPT), all huge pages are marked as
      NX. If the guest attempts to execute in one of those pages, the page is
      broken down into 4K pages, which are then marked executable.
      
      This is not an issue for shadow paging (except nested EPT), because then
      the host is in control of TLB flushes and the problematic situation cannot
      happen.  With nested EPT, again the nested guest can cause problems shadow
      and direct EPT is treated in the same way.
      
      [ tglx: Fixup default to auto and massage wording a bit ]
      Originally-by: NJunaid Shahid <junaids@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b8e8c830
    • V
      x86/bugs: Add ITLB_MULTIHIT bug infrastructure · db4d30fb
      Vineela Tummalapalli 提交于
      Some processors may incur a machine check error possibly resulting in an
      unrecoverable CPU lockup when an instruction fetch encounters a TLB
      multi-hit in the instruction TLB. This can occur when the page size is
      changed along with either the physical address or cache type. The relevant
      erratum can be found here:
      
         https://bugzilla.kernel.org/show_bug.cgi?id=205195
      
      There are other processors affected for which the erratum does not fully
      disclose the impact.
      
      This issue affects both bare-metal x86 page tables and EPT.
      
      It can be mitigated by either eliminating the use of large pages or by
      using careful TLB invalidations when changing the page size in the page
      tables.
      
      Just like Spectre, Meltdown, L1TF and MDS, a new bit has been allocated in
      MSR_IA32_ARCH_CAPABILITIES (PSCHANGE_MC_NO) and will be set on CPUs which
      are mitigated against this issue.
      Signed-off-by: NVineela Tummalapalli <vineela.tummalapalli@intel.com>
      Co-developed-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      db4d30fb
  9. 02 11月, 2019 1 次提交
  10. 01 11月, 2019 7 次提交
  11. 31 10月, 2019 1 次提交
  12. 29 10月, 2019 2 次提交
  13. 28 10月, 2019 4 次提交
  14. 26 10月, 2019 2 次提交
  15. 25 10月, 2019 1 次提交
  16. 24 10月, 2019 1 次提交
    • R
      dt-bindings: riscv: Fix CPU schema errors · 9af865d9
      Rob Herring 提交于
      Fix the errors in the RiscV CPU DT schema:
      
      Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property
      Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@1: 'timebase-frequency' is a required property
      Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible:0: 'riscv' is not one of ['sifive,rocket0', 'sifive,e5', 'sifive,e51', 'sifive,u54-mc', 'sifive,u54', 'sifive,u5']
      Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible: ['riscv'] is too short
      Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property
      
      The DT spec allows for 'timebase-frequency' to be in 'cpu' or 'cpus' node
      and RiscV requires it in /cpus node, so make it disallowed in cpu
      nodes.
      
      Fixes: 4fd669a8 ("dt-bindings: riscv: convert cpu binding to json-schema")
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: linux-riscv@lists.infradead.org
      Acked-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      9af865d9
  17. 22 10月, 2019 2 次提交
  18. 16 10月, 2019 1 次提交
  19. 15 10月, 2019 2 次提交
  20. 14 10月, 2019 1 次提交
反馈
建议
客服 返回
顶部