1. 11 3月, 2010 1 次提交
  2. 08 2月, 2010 1 次提交
  3. 09 12月, 2009 1 次提交
  4. 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
  5. 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
  6. 12 1月, 2009 1 次提交
  7. 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
  8. 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
  9. 23 9月, 2008 1 次提交
  10. 14 9月, 2008 1 次提交
  11. 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
  12. 20 8月, 2008 2 次提交
  13. 14 8月, 2008 1 次提交
  14. 01 8月, 2008 1 次提交
  15. 29 7月, 2008 7 次提交
  16. 26 7月, 2008 1 次提交
  17. 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
  18. 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
  19. 10 7月, 2008 1 次提交
  20. 03 7月, 2008 1 次提交
  21. 21 6月, 2008 1 次提交
  22. 20 4月, 2008 1 次提交
    • M
      x86: use new set_cpus_allowed_ptr function · fc0e4748
      Mike Travis 提交于
        * Use new set_cpus_allowed_ptr() function added by previous patch,
          which instead of passing the "newly allowed cpus" cpumask_t arg
          by value,  pass it by pointer:
      
          -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
          +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)
      
        * Cleanup uses of CPU_MASK_ALL.
      
        * Collapse other NR_CPUS changes to arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
          Use pointers to cpumask_t arguments whenever possible.
      
      Depends on:
      	[sched-devel]: sched: add new set_cpus_allowed_ptr function
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc0e4748
  23. 17 4月, 2008 1 次提交
  24. 02 2月, 2008 1 次提交
    • S
      x86: fix section mismatch warnings when referencing notifiers · c72258c7
      Sam Ravnborg 提交于
      Fix the following warnings:
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0xf8): Section mismatch in reference from the function msr_exit() to the variable .cpuinit.data:msr_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x158): Section mismatch in reference from the function cpuid_exit() to the variable .cpuinit.data:cpuid_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x171): Section mismatch in reference from the function microcode_exit() to the variable .cpuinit.data:mc_cpu_notifier
      
      In all three cases there were a function annotated __exit
      that referenced a variable annotated __cpuinitdata.
      
      The fix was to replace the annotation of the notifier
      with __refdata to tell modpost that the reference to
      a _cpuinit function in the notifier are OK.
      The unregister call that references the notifier
      variable will simple delete the function pointer
      so there is no problem ignoring the reference.
      
      Note: This looks like another case where __cpuinit
      has been used as replacement for proper use
      of CONFIG_HOTPLUG_CPU to decide what code are used for
      HOTPLUG_CPU.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c72258c7
  25. 30 1月, 2008 1 次提交
  26. 26 1月, 2008 1 次提交
    • G
      cpu-hotplug: replace lock_cpu_hotplug() with get_online_cpus() · 86ef5c9a
      Gautham R Shenoy 提交于
      Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
      get_online_cpus and put_online_cpus instead as it highlights the
      refcount semantics in these operations.
      
      The new API guarantees protection against the cpu-hotplug operation, but
      it doesn't guarantee serialized access to any of the local data
      structures. Hence the changes needs to be reviewed.
      
      In case of pseries_add_processor/pseries_remove_processor, use
      cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
      cpu_present_map there.
      Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      86ef5c9a
  27. 20 10月, 2007 1 次提交
    • M
      x86: convert cpuinfo_x86 array to a per_cpu array · 92cb7612
      Mike Travis 提交于
      cpu_data is currently an array defined using NR_CPUS.  This means that
      we overallocate since we will rarely really use maximum configured cpus.
      When NR_CPU count is raised to 4096 the size of cpu_data becomes
      3,145,728 bytes.
      
      These changes were adopted from the sparc64 (and ia64) code.  An
      additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
      index.  This corresponds to the index into a cpumask_t as well as the
      per_cpu index.  It's used in various places like show_cpuinfo().
      
      cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
      case.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Mark M. Hoffman <mhoffman@lightlink.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      92cb7612
  28. 11 10月, 2007 1 次提交
  29. 30 7月, 2007 1 次提交
    • A
      Remove fs.h from mm.h · 4e950f6f
      Alexey Dobriyan 提交于
      Remove fs.h from mm.h. For this,
       1) Uninline vma_wants_writenotify(). It's pretty huge anyway.
       2) Add back fs.h or less bloated headers (err.h) to files that need it.
      
      As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files
      rebuilt down to 3444 (-12.3%).
      
      Cross-compile tested without regressions on my two usual configs and (sigh):
      
      alpha              arm-mx1ads        mips-bigsur          powerpc-ebony
      alpha-allnoconfig  arm-neponset      mips-capcella        powerpc-g5
      alpha-defconfig    arm-netwinder     mips-cobalt          powerpc-holly
      alpha-up           arm-netx          mips-db1000          powerpc-iseries
      arm                arm-ns9xxx        mips-db1100          powerpc-linkstation
      arm-assabet        arm-omap_h2_1610  mips-db1200          powerpc-lite5200
      arm-at91rm9200dk   arm-onearm        mips-db1500          powerpc-maple
      arm-at91rm9200ek   arm-picotux200    mips-db1550          powerpc-mpc7448_hpc2
      arm-at91sam9260ek  arm-pleb          mips-ddb5477         powerpc-mpc8272_ads
      arm-at91sam9261ek  arm-pnx4008       mips-decstation      powerpc-mpc8313_rdb
      arm-at91sam9263ek  arm-pxa255-idp    mips-e55             powerpc-mpc832x_mds
      arm-at91sam9rlek   arm-realview      mips-emma2rh         powerpc-mpc832x_rdb
      arm-ateb9200       arm-realview-smp  mips-excite          powerpc-mpc834x_itx
      arm-badge4         arm-rpc           mips-fulong          powerpc-mpc834x_itxgp
      arm-carmeva        arm-s3c2410       mips-ip22            powerpc-mpc834x_mds
      arm-cerfcube       arm-shannon       mips-ip27            powerpc-mpc836x_mds
      arm-clps7500       arm-shark         mips-ip32            powerpc-mpc8540_ads
      arm-collie         arm-simpad        mips-jazz            powerpc-mpc8544_ds
      arm-corgi          arm-spitz         mips-jmr3927         powerpc-mpc8560_ads
      arm-csb337         arm-trizeps4      mips-malta           powerpc-mpc8568mds
      arm-csb637         arm-versatile     mips-mipssim         powerpc-mpc85xx_cds
      arm-ebsa110        i386              mips-mpc30x          powerpc-mpc8641_hpcn
      arm-edb7211        i386-allnoconfig  mips-msp71xx         powerpc-mpc866_ads
      arm-em_x270        i386-defconfig    mips-ocelot          powerpc-mpc885_ads
      arm-ep93xx         i386-up           mips-pb1100          powerpc-pasemi
      arm-footbridge     ia64              mips-pb1500          powerpc-pmac32
      arm-fortunet       ia64-allnoconfig  mips-pb1550          powerpc-ppc64
      arm-h3600          ia64-bigsur       mips-pnx8550-jbs     powerpc-prpmc2800
      arm-h7201          ia64-defconfig    mips-pnx8550-stb810  powerpc-ps3
      arm-h7202          ia64-gensparse    mips-qemu            powerpc-pseries
      arm-hackkit        ia64-sim          mips-rbhma4200       powerpc-up
      arm-integrator     ia64-sn2          mips-rbhma4500       s390
      arm-iop13xx        ia64-tiger        mips-rm200           s390-allnoconfig
      arm-iop32x         ia64-up           mips-sb1250-swarm    s390-defconfig
      arm-iop33x         ia64-zx1          mips-sead            s390-up
      arm-ixp2000        m68k              mips-tb0219          sparc
      arm-ixp23xx        m68k-amiga        mips-tb0226          sparc-allnoconfig
      arm-ixp4xx         m68k-apollo       mips-tb0287          sparc-defconfig
      arm-jornada720     m68k-atari        mips-workpad         sparc-up
      arm-kafa           m68k-bvme6000     mips-wrppmc          sparc64
      arm-kb9202         m68k-hp300        mips-yosemite        sparc64-allnoconfig
      arm-ks8695         m68k-mac          parisc               sparc64-defconfig
      arm-lart           m68k-mvme147      parisc-allnoconfig   sparc64-up
      arm-lpd270         m68k-mvme16x      parisc-defconfig     um-x86_64
      arm-lpd7a400       m68k-q40          parisc-up            x86_64
      arm-lpd7a404       m68k-sun3         powerpc              x86_64-allnoconfig
      arm-lubbock        m68k-sun3x        powerpc-cell         x86_64-defconfig
      arm-lusl7200       mips              powerpc-celleb       x86_64-up
      arm-mainstone      mips-atlas        powerpc-chrp32
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4e950f6f
  30. 01 6月, 2007 1 次提交
    • S
      microcode: fix section mismatch warning · f8281a2b
      Sam Ravnborg 提交于
      Fix the following section mismatch warnings in microcode.c:
      WARNING: arch/i386/kernel/built-in.o(.init.text+0x3966): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')
      WARNING: arch/i386/kernel/built-in.o(.init.text+0x3992): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')
      
      The warning are caused by a function marked __init that
      calls a function marked __exit.
      Functions marked __exit may be discarded either during link or run-time
      and thus the reference is not good.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f8281a2b
  31. 10 5月, 2007 2 次提交
  32. 03 4月, 2007 1 次提交
    • R
      [PATCH] Fix microcode-related suspend problem · 1d64b9cb
      Rafael J. Wysocki 提交于
      Fix the regression resulting from the recent change of suspend code
      ordering that causes systems based on Intel x86 CPUs using the microcode
      driver to hang during the resume.
      
      The problem occurs since the microcode driver uses request_firmware() in
      its CPU hotplug notifier, which is called after tasks has been frozen and
      hangs.  It can be fixed by telling the microcode driver to use the
      microcode stored in memory during the resume instead of trying to load it
      from disk.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Adrian Bunk <bunk@stusta.de>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Maxim <maximlevitsky@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d64b9cb