<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/x86/kernel/microcode_core.c, branch v2.6.28</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>x86: fix resume (S2R) broken by Intel microcode module, on A110L</title>
<updated>2008-12-20T13:29:20+00:00</updated>
<author>
<name>Dmitry Adamushko</name>
<email>dmitry.adamushko@gmail.com</email>
</author>
<published>2008-12-19T23:15:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=280a9ca5d0663b185ddc4443052076c29652a328'/>
<id>280a9ca5d0663b185ddc4443052076c29652a328</id>
<content type='text'>
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 &lt;andi@lisas.de&gt;
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;

[ 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 &amp;&amp; deadlock...").

In any case, the deadlock situation is a must-have fix.

Reported-by: Andreas Mohr &lt;andi@lisas.de&gt;
Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Tested-by: Andreas Mohr &lt;andi@lisas.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: &lt;stable@kernel.org&gt;

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;andi@lisas.de&gt;
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;

[ 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 &amp;&amp; deadlock...").

In any case, the deadlock situation is a must-have fix.

Reported-by: Andreas Mohr &lt;andi@lisas.de&gt;
Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Tested-by: Andreas Mohr &lt;andi@lisas.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: &lt;stable@kernel.org&gt;

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86: microcode patch loader author update</title>
<updated>2008-10-28T15:41:16+00:00</updated>
<author>
<name>Peter Oruba</name>
<email>peter.oruba@amd.com</email>
</author>
<published>2008-10-17T13:30:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=36b75da27bb51dc34e358d0b7487406132806c46'/>
<id>36b75da27bb51dc34e358d0b7487406132806c46</id>
<content type='text'>
Removed one author's email address from module init message.

Signed-off-by: Peter Oruba &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Removed one author's email address from module init message.

Signed-off-by: Peter Oruba &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: fix sleeping function called from invalid context at kernel/mutex.c</title>
<updated>2008-10-02T15:52:33+00:00</updated>
<author>
<name>Dmitry Adamushko</name>
<email>dmitry.adamushko@gmail.com</email>
</author>
<published>2008-10-02T13:56:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fd1452ebf257317f24e0e285a17a2ec2ce3e6df7'/>
<id>fd1452ebf257317f24e0e285a17a2ec2ce3e6df7</id>
<content type='text'>
Fix the following "sleeping function called from invalid context" bug:

...
__might_sleep
mutex_lock_nested
microcode_update_cpu
mc_sysdev_resume
__sysdev_resume
sysdev_resume
device_power_up
...

Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following "sleeping function called from invalid context" bug:

...
__might_sleep
mutex_lock_nested
microcode_update_cpu
mc_sysdev_resume
__sysdev_resume
sysdev_resume
device_power_up
...

Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86: microcode patch loader bugfix</title>
<updated>2008-09-24T09:02:01+00:00</updated>
<author>
<name>Peter Oruba</name>
<email>peter.oruba@amd.com</email>
</author>
<published>2008-09-24T09:50:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=82b078659ed04e1ecdebf8326e189cf76ed361af'/>
<id>82b078659ed04e1ecdebf8326e189cf76ed361af</id>
<content type='text'>
Corrected CPU vendor check condition for AMD microcode patch loader
initialization.

Signed-off-by: Peter Oruba &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Corrected CPU vendor check condition for AMD microcode patch loader
initialization.

Signed-off-by: Peter Oruba &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86: moved microcode.c to microcode_intel.c</title>
<updated>2008-09-23T10:21:42+00:00</updated>
<author>
<name>Dmitry Adamushko</name>
<email>dmitry.adamushko@gmail.com</email>
</author>
<published>2008-09-23T10:08:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=18dbc9160507dc7df998e00cd1dcd7889557307b'/>
<id>18dbc9160507dc7df998e00cd1dcd7889557307b</id>
<content type='text'>
Combine both generic and arch-specific parts of microcode into a
single module (arch-specific parts are config-dependent).

Also while we are at it, move arch-specific parts from microcode.h
into their respective arch-specific .c files.

Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Cc: "Peter Oruba" &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Combine both generic and arch-specific parts of microcode into a
single module (arch-specific parts are config-dependent).

Also while we are at it, move arch-specific parts from microcode.h
into their respective arch-specific .c files.

Signed-off-by: Dmitry Adamushko &lt;dmitry.adamushko@gmail.com&gt;
Cc: "Peter Oruba" &lt;peter.oruba@amd.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
</feed>
