1. 09 Jun, 2022 4 commits
    • Linus Torvalds's avatar
      gcc-12: disable '-Warray-bounds' universally for now · f0be87c4
      Linus Torvalds authored
      In commit 8b202ee2 ("s390: disable -Warray-bounds") the s390 people
      disabled the '-Warray-bounds' warning for gcc-12, because the new logic
      in gcc would cause warnings for their use of the S390_lowcore macro,
      which accesses absolute pointers.
      
      It turns out gcc-12 has many other issues in this area, so this takes
      that s390 warning disable logic, and turns it into a kernel build config
      entry instead.
      
      Part of the intent is that we can make this all much more targeted, and
      use this conflig flag to disable it in only particular configurations
      that cause problems, with the s390 case as an example:
      
              select GCC12_NO_ARRAY_BOUNDS
      
      and we could do that for other configuration cases that cause issues.
      
      Or we could possibly use the CONFIG_CC_NO_ARRAY_BOUNDS thing in a more
      targeted way, and disable the warning only for particular uses: again
      the s390 case as an example:
      
        KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
      
      but this ends up just doing it globally in the top-level Makefile, since
      the current issues are spread fairly widely all over:
      
        KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
      
      We'll try to limit this later, since the gcc-12 problems are rare enough
      that *much* of the kernel can be built with it without disabling this
      warning.
      
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f0be87c4
    • Linus Torvalds's avatar
      mellanox: mlx5: avoid uninitialized variable warning with gcc-12 · 842c3b3d
      Linus Torvalds authored
      gcc-12 started warning about 'tracker' being used uninitialized:
      
        drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c: In function ‘mlx5_do_bond’:
        drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c:786:28: warning: ‘tracker’ is used uninitialized [-Wuninitialized]
          786 |         struct lag_tracker tracker;
              |                            ^~~~~~~
      
      which seems to be because it doesn't track how the use (and
      initialization) is bound by the 'do_bond' flag.
      
      But admittedly that 'do_bond' usage is fairly complicated, and involves
      passing it around as an argument to helper functions, so it's somewhat
      understandable that gcc doesn't see how that all works.
      
      This function could be rewritten to make the use of that tracker
      variable more obviously safe, but for now I'm just adding the forced
      initialization of it.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      842c3b3d
    • Linus Torvalds's avatar
      gcc-12: disable '-Wdangling-pointer' warning for now · 49beadbd
      Linus Torvalds authored
      While the concept of checking for dangling pointers to local variables
      at function exit is really interesting, the gcc-12 implementation is not
      compatible with reality, and results in false positives.
      
      For example, gcc sees us putting things on a local list head allocated
      on the stack, which involves exactly those kinds of pointers to the
      local stack entry:
      
        In function ‘__list_add’,
            inlined from ‘list_add_tail’ at include/linux/list.h:102:2,
            inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2:
        include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=]
           74 |         new->prev = prev;
              |         ~~~~~~~~~~^~~~~~
      
      But then gcc - understandably - doesn't really understand the big
      picture how the doubly linked list works, so doesn't see how we then end
      up emptying said list head in a loop and the pointer we added has been
      removed.
      
      Gcc also complains about us (intentionally) using this as a way to store
      a kind of fake stack trace, eg
      
        drivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=]
           40 |         acpi_gbl_entry_stack_pointer = &current_sp;
              |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
      
      which is entirely reasonable from a compiler standpoint, and we may want
      to change those kinds of patterns, but not not.
      
      So this is one of those "it would be lovely if the compiler were to
      complain about us leaving dangling pointers to the stack", but not this
      way.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      49beadbd
    • Linus Torvalds's avatar
      drm: imx: fix compiler warning with gcc-12 · 7aefd8b5
      Linus Torvalds authored
      Gcc-12 correctly warned about this code using a non-NULL pointer as a
      truth value:
      
        drivers/gpu/drm/imx/ipuv3-crtc.c: In function ‘ipu_crtc_disable_planes’:
        drivers/gpu/drm/imx/ipuv3-crtc.c:72:21: error: the comparison will always evaluate as ‘true’ for the address of ‘plane’ will never be NULL [-Werror=address]
           72 |                 if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
              |                     ^
      
      due to the extraneous '&' address-of operator.
      
      Philipp Zabel points out that The mistake had no adverse effect since
      the following condition doesn't actually dereference the NULL pointer,
      but the intent of the code was obviously to check for it, not to take
      the address of the member.
      
      Fixes: eb8c8880 ("drm/imx: add deferred plane disabling")
      Acked-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7aefd8b5
  2. 08 Jun, 2022 6 commits
    • Linus Torvalds's avatar
      cert host tools: Stop complaining about deprecated OpenSSL functions · 6bfb56e9
      Linus Torvalds authored
      OpenSSL 3.0 deprecated the OpenSSL's ENGINE API.  That is as may be, but
      the kernel build host tools still use it.  Disable the warning about
      deprecated declarations until somebody who cares fixes it.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6bfb56e9
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 34f4335c
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
      
       - syzkaller NULL pointer dereference
      
       - TDP MMU performance issue with disabling dirty logging
      
       - 5.14 regression with SVM TSC scaling
      
       - indefinite stall on applying live patches
      
       - unstable selftest
      
       - memory leak from wrong copy-and-paste
      
       - missed PV TLB flush when racing with emulation
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: do not report a vCPU as preempted outside instruction boundaries
        KVM: x86: do not set st->preempted when going back to user space
        KVM: SVM: fix tsc scaling cache logic
        KVM: selftests: Make hyperv_clock selftest more stable
        KVM: x86/MMU: Zap non-leaf SPTEs when disabling dirty logging
        x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm()
        KVM: x86/mmu: Check every prev_roots in __kvm_mmu_free_obsolete_roots()
        entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set
        KVM: Don't null dereference ops->destroy
      34f4335c
    • Linus Torvalds's avatar
      Merge tag 'tpmdd-next-v5.19-rc2-v2' of... · 32d380a7
      Linus Torvalds authored
      Merge tag 'tpmdd-next-v5.19-rc2-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
      
      Pull tpm fix from Jarkko Sakkinen:
       "A bug fix for migratable (whether or not a key is tied to the TPM chip
        soldered to the machine) handling for TPM2 trusted keys"
      
      * tag 'tpmdd-next-v5.19-rc2-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
        KEYS: trusted: tpm2: Fix migratable logic
      32d380a7
    • David Safford's avatar
      KEYS: trusted: tpm2: Fix migratable logic · dda53843
      David Safford authored
      When creating (sealing) a new trusted key, migratable
      trusted keys have the FIXED_TPM and FIXED_PARENT attributes
      set, and non-migratable keys don't. This is backwards, and
      also causes creation to fail when creating a migratable key
      under a migratable parent. (The TPM thinks you are trying to
      seal a non-migratable blob under a migratable parent.)
      
      The following simple patch fixes the logic, and has been
      tested for all four combinations of migratable and non-migratable
      trusted keys and parent storage keys. With this logic, you will
      get a proper failure if you try to create a non-migratable
      trusted key under a migratable parent storage key, and all other
      combinations work correctly.
      
      Cc: stable@vger.kernel.org # v5.13+
      Fixes: e5fb5d2c ("security: keys: trusted: Make sealed key properly interoperable")
      Signed-off-by: default avatarDavid Safford <david.safford@gmail.com>
      Reviewed-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      dda53843
    • Paolo Bonzini's avatar
      KVM: x86: do not report a vCPU as preempted outside instruction boundaries · 6cd88243
      Paolo Bonzini authored
      If a vCPU is outside guest mode and is scheduled out, it might be in the
      process of making a memory access.  A problem occurs if another vCPU uses
      the PV TLB flush feature during the period when the vCPU is scheduled
      out, and a virtual address has already been translated but has not yet
      been accessed, because this is equivalent to using a stale TLB entry.
      
      To avoid this, only report a vCPU as preempted if sure that the guest
      is at an instruction boundary.  A rescheduling request will be delivered
      to the host physical CPU as an external interrupt, so for simplicity
      consider any vmexit *not* instruction boundary except for external
      interrupts.
      
      It would in principle be okay to report the vCPU as preempted also
      if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
      vmentry/vmexit overhead unnecessarily, and optimistic spinning is
      also unlikely to succeed.  However, leave it for later because right
      now kvm_vcpu_check_block() is doing memory accesses.  Even
      though the TLB flush issue only applies to virtual memory address,
      it's very much preferrable to be conservative.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6cd88243
    • Paolo Bonzini's avatar
      KVM: x86: do not set st->preempted when going back to user space · 54aa83c9
      Paolo Bonzini authored
      Similar to the Xen path, only change the vCPU's reported state if the vCPU
      was actually preempted.  The reason for KVM's behavior is that for example
      optimistic spinning might not be a good idea if the guest is doing repeated
      exits to userspace; however, it is confusing and unlikely to make a difference,
      because well-tuned guests will hardly ever exit KVM_RUN in the first place.
      Suggested-by: default avatarSean Christopherson <seanjc@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      54aa83c9
  3. 07 Jun, 2022 12 commits
  4. 06 Jun, 2022 3 commits
  5. 05 Jun, 2022 15 commits