1. 17 11月, 2016 10 次提交
  2. 16 11月, 2016 2 次提交
  3. 12 11月, 2016 2 次提交
    • A
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      Arnd Bergmann 提交于
      The rfc4106 encrypy/decrypt helper functions cause an annoying
      false-positive warning in allmodconfig if we turn on
      -Wmaybe-uninitialized warnings again:
      
        arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
        include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem seems to be that the compiler doesn't track the state of the
      'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
      section.
      
      This takes the easy way out by adding a bogus initialization, which
      should be harmless enough to get the patch into v4.9 so we can turn on
      this warning again by default without producing useless output.  A
      follow-up patch for v4.10 rearranges the code to make the warning go
      away.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
    • A
      x86: apm: avoid uninitialized data · 3a6d8676
      Arnd Bergmann 提交于
      apm_bios_call() can fail, and return a status in its argument structure.
      If that status however is zero during a call from
      apm_get_power_status(), we end up using data that may have never been
      set, as reported by "gcc -Wmaybe-uninitialized":
      
        arch/x86/kernel/apm_32.c: In function ‘apm’:
        arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
        arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here
      
      This changes the function to return "APM_NO_ERROR" here, which makes the
      code more robust to broken BIOS versions, and avoids the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a6d8676
  4. 04 11月, 2016 3 次提交
  5. 03 11月, 2016 20 次提交
  6. 29 10月, 2016 1 次提交
    • T
      x86/smpboot: Init apic mapping before usage · 1e90a13d
      Thomas Gleixner 提交于
      The recent changes, which forced the registration of the boot cpu on UP
      systems, which do not have ACPI tables, have been fixed for systems w/o
      local APIC, but left a wreckage for systems which have neither ACPI nor
      mptables, but the CPU has an APIC, e.g. virtualbox.
      
      The boot process crashes in prefill_possible_map() as it wants to register
      the boot cpu, which needs to access the local apic, but the local APIC is
      not yet mapped.
      
      There is no reason why init_apic_mapping() can't be invoked before
      prefill_possible_map(). So instead of playing another silly early mapping
      game, as the ACPI/mptables code does, we just move init_apic_mapping()
      before the call to prefill_possible_map().
      
      In hindsight, I should have noticed that combination earlier.
      
      Sorry for the churn (also in stable)!
      
      Fixes: ff856051 ("x86/boot/smp: Don't try to poke disabled/non-existent APIC")
      Reported-and-debugged-by: NMichal Necasek <michal.necasek@oracle.com>
      Reported-and-tested-by: NWolfgang Bauer <wbauer@tmo.at>
      Cc: prarit@redhat.com
      Cc: ville.syrjala@linux.intel.com
      Cc: michael.thayer@oracle.com
      Cc: knut.osmundsen@oracle.com
      Cc: frank.mehnert@oracle.com
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1e90a13d
  7. 28 10月, 2016 2 次提交