1. 11 5月, 2015 1 次提交
  2. 03 3月, 2015 1 次提交
  3. 19 2月, 2015 1 次提交
  4. 25 7月, 2014 1 次提交
  5. 14 1月, 2014 1 次提交
  6. 09 12月, 2013 1 次提交
  7. 01 2月, 2013 1 次提交
  8. 23 8月, 2012 1 次提交
  9. 07 5月, 2012 1 次提交
  10. 14 10月, 2011 1 次提交
  11. 27 12月, 2010 1 次提交
    • J
      x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree() · 5cdd2de0
      Jesper Juhl 提交于
      In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
      we have  this:
      
      	while (leftover) {
      		...
      		if (get_ucode_data(mc, ucode_ptr, mc_size) ||
      		    microcode_sanity_check(mc) < 0) {
      			vfree(mc);
      			break;
      		}
      		...
      	}
      
      	if (mc)
      		vfree(mc);
      
      This will cause a double free of 'mc'. This patch fixes that by
      just  removing the vfree() call in the loop since 'mc' will be
      freed nicely just  after we break out of the loop.
      
      There's also a second change in the patch. I noticed a lot of
      checks for  pointers being NULL before passing them to vfree().
      That's completely  redundant since vfree() deals gracefully with
      being passed a NULL pointer.  Removing the redundant checks
      yields a nice size decrease for the object  file.
      
      Size before the patch:
         text    data     bss     dec     hex filename
         4578     240    1032    5850    16da arch/x86/kernel/microcode_intel.o
      Size after the patch:
         text    data     bss     dec     hex filename
         4489     240     984    5713    1651 arch/x86/kernel/microcode_intel.o
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Acked-by: NTigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Shaohua Li <shaohua.li@intel.com>
      LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd2de0
  12. 18 10月, 2010 1 次提交
  13. 11 3月, 2010 1 次提交
  14. 08 2月, 2010 1 次提交
  15. 09 12月, 2009 1 次提交
  16. 12 5月, 2009 1 次提交
    • D
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed,... · 871b72dd
      Dmitry Adamushko 提交于
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic
      
      * Solve issues described in 6f66cbc6
        in a way that doesn't resort to set_cpus_allowed();
      
      * in fact, only collect_cpu_info and apply_microcode callbacks
        must run on a target cpu, others will do just fine on any other.
        smp_call_function_single() (as suggested by Ingo) is used to run
        these callbacks on a target cpu.
      
      * cleanup of synchronization logic of the 'microcode_core' part
      
        The generic 'microcode_core' part guarantees that only a single cpu
        (be it a full-fledged cpu, one of the cores or HT)
        is being updated at any particular moment of time.
      
        In general, there is no need for any additional sync. mechanism in
        arch-specific parts (the patch removes existing spinlocks).
      
        See also the "Synchronization" section in microcode_core.c.
      
      * return -EINVAL instead of -1 (which is translated into -EPERM) in
        microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions
        for an error code?
      
      * use 'enum ucode_state' as return value of request_microcode_{fw, user}
        to gain more flexibility by distinguishing between real error cases
        and situations when an appropriate ucode was not found (which is not an
        error per-se).
      
      * some minor cleanups
      
      Thanks a lot to Hugh Dickins for review/suggestions/testing!
      
         Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2
      
      [ Impact: refactor and clean up microcode driver locking code ]
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <1242078507.5560.9.camel@earth>
      [ did some more cleanups ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
       arch/x86/include/asm/microcode.h  |   25 ++
       arch/x86/kernel/microcode_amd.c   |   58 ++----
       arch/x86/kernel/microcode_core.c  |  326 +++++++++++++++++++++-----------------
       arch/x86/kernel/microcode_intel.c |   92 +++-------
       4 files changed, 261 insertions(+), 240 deletions(-)
      
      (~20 new comment lines)
      871b72dd
  17. 18 3月, 2009 1 次提交
    • I
      x86: microcode: cleanup · 4bae1967
      Ingo Molnar 提交于
      Impact: cleanup
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4bae1967
  18. 12 1月, 2009 1 次提交
  19. 20 12月, 2008 1 次提交
    • D
      x86: fix resume (S2R) broken by Intel microcode module, on A110L · 280a9ca5
      Dmitry Adamushko 提交于
      Impact: fix deadlock
      
      This is in response to the following bug report:
      
      Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12100
      Subject         : resume (S2R) broken by Intel microcode module, on A110L
      Submitter       : Andreas Mohr <andi@lisas.de>
      Date            : 2008-11-25 08:48 (19 days old)
      Handled-By      : Dmitry Adamushko <dmitry.adamushko@gmail.com>
      
      [ The deadlock scenario has been discovered by Andreas Mohr ]
      
      I think I might have a logical explanation why the system:
      
        (http://bugzilla.kernel.org/show_bug.cgi?id=12100)
      
      might hang upon resuming, OTOH it should have likely hanged each and every time.
      
      (1) possible deadlock in microcode_resume_cpu() if either 'if' section is
      taken;
      
      (2) now, I don't see it in spec. and can't experimentally verify it (newer
      ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
      think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
      be back to its original one (we need to reload ucode anyway so it doesn't seem
      logical if a cpu doesn't drop the version)... if so, the comparison with
      memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
      the aforementioned 'if' sections might have been triggered - leading to a
      deadlock.
      
      Obviously, in my tests I simulated loading/resuming with the ucode of the same
      version (just to see that the file is loaded/re-loaded upon resuming) so this
      issue has never popped up.
      
      I'd appreciate if someone with an appropriate system might give a try to the
      2nd patch (titled "fix a comparison && deadlock...").
      
      In any case, the deadlock situation is a must-have fix.
      Reported-by: NAndreas Mohr <andi@lisas.de>
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Tested-by: NAndreas Mohr <andi@lisas.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      280a9ca5
  20. 26 11月, 2008 1 次提交
    • H
      x86: microcode: fix sparse warnings · 4db646b1
      Hannes Eder 提交于
      Impact: make global variables and a function static
      
      Fix following sparse warnings:
      
        arch/x86/kernel/microcode_core.c:102:22: warning: symbol
        'microcode_ops' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:206:24: warning: symbol
        'microcode_pdev' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:322:6: warning: symbol
        'microcode_update_cpu' was not declared. Should it be static?
        arch/x86/kernel/microcode_intel.c:468:22: warning: symbol
        'microcode_intel_ops' was not declared. Should it be static?
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4db646b1
  21. 23 9月, 2008 1 次提交
  22. 14 9月, 2008 1 次提交
  23. 12 9月, 2008 1 次提交
    • D
      x86, microcode rework, v2 · a0a29b62
      Dmitry Adamushko 提交于
      this is a rework of the microcode splitup in tip/x86/microcode
      
      (1) I think this new interface is cleaner (look at the changes
          in 'struct microcode_ops' in microcode.h);
      
      (2) it's -64 lines of code;
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a0a29b62
  24. 20 8月, 2008 2 次提交
  25. 14 8月, 2008 1 次提交
  26. 01 8月, 2008 1 次提交
  27. 29 7月, 2008 7 次提交
  28. 26 7月, 2008 1 次提交
  29. 22 7月, 2008 1 次提交
    • A
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      Andi Kleen 提交于
      This allow to dynamically generate attributes and share show/store
      functions between attributes. Right now most attributes are generated
      by special macros and lots of duplicated code. With the attribute
      passed it's instead possible to attach some data to the attribute
      and then use that in shared low level functions to do different things.
      
      I need this for the dynamically generated bank attributes in the x86
      machine check code, but it'll allow some further cleanups.
      
      I converted all users in tree to the new show/store prototype. It's a single
      huge patch to avoid unbisectable sections.
      
      Runtime tested: x86-32, x86-64
      Compiled only: ia64, powerpc
      Not compile tested/only grep converted: sh, arm, avr32
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a0b2b4d
  30. 19 7月, 2008 1 次提交
    • M
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      Mike Travis 提交于
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
          with new cpumask_of_cpu_ptr macros.  These are patterned after the
          node_to_cpumask_ptr macros.
      
          In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
          the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
          is provided when there is a large NR_CPUS count, reducing
          greatly the amount of code generated and stack space used for
          cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
          calling set_cpus_allowed_ptr() to reduce the amount of stack space
          needed to pass the cpumask_t value.
      
          If there isn't a cpumask_of_cpu_map[], then a temporary variable is
          declared and filled in with value from cpumask_of_cpu(cpu) as well as
          a pointer variable pointing to this temporary variable.  Afterwards,
          the pointer is used to reference the cpumask value.  The compiler
          will optimize out the extra dereference through the pointer as well
          as the stack space used for the pointer, resulting in identical code.
      
          A good example of the orthogonal usages is in net/sunrpc/svc.c:
      
      	case SVC_POOL_PERCPU:
      	{
      		unsigned int cpu = m->pool_to[pidx];
      		cpumask_of_cpu_ptr(cpumask, cpu);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, cpumask);
      		return 1;
      	}
      	case SVC_POOL_PERNODE:
      	{
      		unsigned int node = m->pool_to[pidx];
      		node_to_cpumask_ptr(nodecpumask, node);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, nodecpumask);
      		return 1;
      	}
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      65c01184
  31. 10 7月, 2008 1 次提交
  32. 03 7月, 2008 1 次提交
  33. 21 6月, 2008 1 次提交