kernel_samsung_smdk4412/arch/x86/kernel/microcode_intel.c, branch replicant-6.0

x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree()

2010-12-27T13:33:30+00:00

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: Jesper Juhl 
Acked-by: Tigran Aivazian 
Cc: Shaohua Li 
LKML-Reference: 
Signed-off-by: Ingo Molnar

Update broken web addresses in arch directory.

2010-10-18T09:03:21+00:00

The patch below updates broken web addresses in the arch directory.

Signed-off-by: Justin P. Mattock 
Signed-off-by: Maciej W. Rozycki 
Cc: Finn Thain 
Cc: Randy Dunlap 
Reviewed-by: Finn Thain 
Signed-off-by: Jiri Kosina

x86: Improve Intel microcode loader performance

2010-03-11T12:49:06+00:00

We've noticed that on large SGI UV system configurations,
running microcode.ctl can take very long periods of time.  This
is due to the large number of vmalloc/vfree calls made by the
Intel generic_load_microcode() logic.

By reusing allocated space, the following patch reduces the time
to run microcode.ctl on a 1024 cpu system from approximately 80
seconds down to 1 or 2 seconds.

Signed-off-by: Dimitri Sivanich 
Acked-by: Dmitry Adamushko 
Cc: Avi Kivity 
Cc: Bill Davidsen 
LKML-Reference: <20100305174203.GA19638@sgi.com>
Signed-off-by: Ingo Molnar

x86: Remove trailing spaces in messages

2010-02-07T16:47:51+00:00

Signed-off-by: Frans Pop 
Cc: Avi Kivity 
Cc: x86@kernel.org
LKML-Reference: <1265478443-31072-10-git-send-email-elendil@planet.nl>
[ Left out the KVM bits. ]
Signed-off-by: Ingo Molnar

arch/x86/kernel/microcode*: Use pr_fmt() and remove duplicated KERN_ERR prefix

2009-12-09T07:25:57+00:00

- Use #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
- Remove "microcode: " prefix from each pr_
- Fix duplicated KERN_ERR prefix
- Coalesce pr_ format strings
- Add a space after an exclamation point

No other change in output.

Signed-off-by: Joe Perches 
Cc: Andy Whitcroft 
Cc: Andreas Herrmann 
LKML-Reference: <1260340250.27677.191.camel@Joe-Laptop.home>
Signed-off-by: Ingo Molnar

x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic

2009-05-12T08:36:44+00:00

* Solve issues described in 6f66cbc63081fd70e3191b4dbb796746780e5ae1
  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: Dmitry Adamushko 
Acked-by: Hugh Dickins 
Cc: Andrew Morton 
Cc: Rusty Russell 
Cc: Andreas Herrmann 
Cc: Peter Oruba 
Cc: Arjan van de Ven 
LKML-Reference: <1242078507.5560.9.camel@earth>
[ did some more cleanups ]
Signed-off-by: Ingo Molnar 
 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)

x86: microcode: cleanup

2009-03-18T12:51:17+00:00

Impact: cleanup

Cc: Rusty Russell 
Cc: Andrew Morton 
Cc: Dmitry Adamushko 
Cc: Peter Oruba 
LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar

x86: microcode_intel.c fix style problems

2009-01-12T10:22:40+00:00

Impact: cleanup

Fix:

 WARNING: Use #include  instead of 
 ERROR: trailing whitespace
 ERROR: "(foo*)" should be "(foo *)"

 total: 3 errors, 1 warnings

Signed-off-by: Jaswinder Singh Rajput 
Signed-off-by: Ingo Molnar

Merge branches 'x86/apic', 'x86/cleanups', 'x86/cpufeature', 'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/detect-hyper', 'x86/doc', 'x86/dumpstack', 'x86/early-printk', 'x86/fpu', 'x86/idle', 'x86/io', 'x86/memory-corruption-check', 'x86/microcode', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/pat2', 'x86/pci-ioapic-boot-irq-quirks', 'x86/ptrace', 'x86/quirks', 'x86/reboot', 'x86/setup-memory', 'x86/signal', 'x86/sparse-fixes', 'x86/time', 'x86/uv' and 'x86/xen' into x86/core

2008-12-23T15:27:23+00:00

x86: fix resume (S2R) broken by Intel microcode module, on A110L

2008-12-20T13:29:20+00:00

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 
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko 

[ 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: Andreas Mohr 
Signed-off-by: Dmitry Adamushko 
Tested-by: Andreas Mohr 
Signed-off-by: Ingo Molnar 
Cc: 

Signed-off-by: Ingo Molnar