<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/char, branch linux-3.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>random: print a warning for the first ten uninitialized random users</title>
<updated>2016-08-20T09:53:20+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-06-13T14:10:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e38c381e0cc02c7d12d1659dcba5d31a96fee41'/>
<id>1e38c381e0cc02c7d12d1659dcba5d31a96fee41</id>
<content type='text'>
commit 9b4d008787f864f17d008c9c15bbe8a0f7e2fc24 upstream.

Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot.  So print the first ten such
complaints instead.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b4d008787f864f17d008c9c15bbe8a0f7e2fc24 upstream.

Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot.  So print the first ten such
complaints instead.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>random: strengthen input validation for RNDADDTOENTCNT</title>
<updated>2016-08-16T07:29:02+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-07-03T21:01:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=25bc549dc31baad563f796c1f9633e12eb944278'/>
<id>25bc549dc31baad563f796c1f9633e12eb944278</id>
<content type='text'>
commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec upstream.

Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
entropy value.  It doesn't make any sense to subtract from the entropy
counter, and it can trigger a warning:

random: negative entropy/overflow: pool input count -40000
------------[ cut here ]------------
WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[&lt;      none
 &gt;] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
Modules linked in:
CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
 fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
 ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82cc838f&gt;] dump_stack+0x12e/0x18f lib/dump_stack.c:51
 [&lt;ffffffff8136d27f&gt;] __warn+0x19f/0x1e0 kernel/panic.c:516
 [&lt;ffffffff8136d48c&gt;] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
 [&lt;ffffffff83283dae&gt;] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
 [&lt;     inline     &gt;] credit_entropy_bits_safe drivers/char/random.c:734
 [&lt;ffffffff8328785d&gt;] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
 [&lt;     inline     &gt;] vfs_ioctl fs/ioctl.c:43
 [&lt;ffffffff8185316c&gt;] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
 [&lt;     inline     &gt;] SYSC_ioctl fs/ioctl.c:689
 [&lt;ffffffff8185405f&gt;] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
 [&lt;ffffffff86a995c0&gt;] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
---[ end trace 5d4902b2ba842f1f ]---

This was triggered using the test program:

// autogenerated by syzkaller (http://github.com/google/syzkaller)

int main() {
        int fd = open("/dev/random", O_RDWR);
        int val = -5000;
        ioctl(fd, RNDADDTOENTCNT, &amp;val);
        return 0;
}

It's harmless in that (a) only root can trigger it, and (b) after
complaining the code never does let the entropy count go negative, but
it's better to simply not allow this userspace from passing in a
negative entropy value altogether.

Google-Bug-Id: #29575089
Reported-By: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec upstream.

Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
entropy value.  It doesn't make any sense to subtract from the entropy
counter, and it can trigger a warning:

random: negative entropy/overflow: pool input count -40000
------------[ cut here ]------------
WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[&lt;      none
 &gt;] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
Modules linked in:
CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
 fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
 ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82cc838f&gt;] dump_stack+0x12e/0x18f lib/dump_stack.c:51
 [&lt;ffffffff8136d27f&gt;] __warn+0x19f/0x1e0 kernel/panic.c:516
 [&lt;ffffffff8136d48c&gt;] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
 [&lt;ffffffff83283dae&gt;] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
 [&lt;     inline     &gt;] credit_entropy_bits_safe drivers/char/random.c:734
 [&lt;ffffffff8328785d&gt;] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
 [&lt;     inline     &gt;] vfs_ioctl fs/ioctl.c:43
 [&lt;ffffffff8185316c&gt;] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
 [&lt;     inline     &gt;] SYSC_ioctl fs/ioctl.c:689
 [&lt;ffffffff8185405f&gt;] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
 [&lt;ffffffff86a995c0&gt;] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
---[ end trace 5d4902b2ba842f1f ]---

This was triggered using the test program:

// autogenerated by syzkaller (http://github.com/google/syzkaller)

int main() {
        int fd = open("/dev/random", O_RDWR);
        int val = -5000;
        ioctl(fd, RNDADDTOENTCNT, &amp;val);
        return 0;
}

It's harmless in that (a) only root can trigger it, and (b) after
complaining the code never does let the entropy count go negative, but
it's better to simply not allow this userspace from passing in a
negative entropy value altogether.

Google-Bug-Id: #29575089
Reported-By: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vTPM: fix memory allocation flag for rtce buffer at kernel boot</title>
<updated>2016-02-17T20:34:35+00:00</updated>
<author>
<name>Hon Ching \(Vicky\) Lo</name>
<email>honclo@linux.vnet.ibm.com</email>
</author>
<published>2015-10-08T00:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2060578571caa130c8483a10fbc4292da6082009'/>
<id>2060578571caa130c8483a10fbc4292da6082009</id>
<content type='text'>
commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream.

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream.

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: move timer init to before irq is setup</title>
<updated>2016-01-29T05:57:05+00:00</updated>
<author>
<name>Jan Stancek</name>
<email>jstancek@redhat.com</email>
</author>
<published>2015-12-08T18:57:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e77c9fa993c8347d3f2655f3ad0624f24120a752'/>
<id>e77c9fa993c8347d3f2655f3ad0624f24120a752</id>
<content type='text'>
commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi-&gt;irq_setup)
                new_smi-&gt;irq_setup(new_smi);

 --&gt; IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer-&gt;function) in __mod_timer().

 Call Trace:
   &lt;IRQ&gt;
   [&lt;ffffffffa0532617&gt;] start_new_msg+0x47/0x80 [ipmi_si]
   [&lt;ffffffffa053269e&gt;] start_check_enables+0x4e/0x60 [ipmi_si]
   [&lt;ffffffffa0532bd8&gt;] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [&lt;ffffffff810f5584&gt;] ? __rcu_process_callbacks+0x54/0x350
   [&lt;ffffffffa053327c&gt;] si_irq_handler+0x3c/0x60 [ipmi_si]
   [&lt;ffffffff810efaf0&gt;] handle_IRQ_event+0x60/0x170
   [&lt;ffffffff810f245e&gt;] handle_edge_irq+0xde/0x180
   [&lt;ffffffff8100fc59&gt;] handle_irq+0x49/0xa0
   [&lt;ffffffff8154643c&gt;] do_IRQ+0x6c/0xf0
   [&lt;ffffffff8100ba53&gt;] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&amp;new_smi-&gt;si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard &lt;minyard@acm.org&gt;
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi-&gt;irq_setup)
                new_smi-&gt;irq_setup(new_smi);

 --&gt; IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer-&gt;function) in __mod_timer().

 Call Trace:
   &lt;IRQ&gt;
   [&lt;ffffffffa0532617&gt;] start_new_msg+0x47/0x80 [ipmi_si]
   [&lt;ffffffffa053269e&gt;] start_check_enables+0x4e/0x60 [ipmi_si]
   [&lt;ffffffffa0532bd8&gt;] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [&lt;ffffffff810f5584&gt;] ? __rcu_process_callbacks+0x54/0x350
   [&lt;ffffffffa053327c&gt;] si_irq_handler+0x3c/0x60 [ipmi_si]
   [&lt;ffffffff810efaf0&gt;] handle_IRQ_event+0x60/0x170
   [&lt;ffffffff810f245e&gt;] handle_edge_irq+0xde/0x180
   [&lt;ffffffff8100fc59&gt;] handle_irq+0x49/0xa0
   [&lt;ffffffff8154643c&gt;] do_IRQ+0x6c/0xf0
   [&lt;ffffffff8100ba53&gt;] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&amp;new_smi-&gt;si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard &lt;minyard@acm.org&gt;
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>agp/intel: Fix typo in needs_ilk_vtd_wa()</title>
<updated>2015-08-03T16:29:59+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2015-06-28T13:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79494ffe93cadb66e6c88d7e67d5eff3699fb266'/>
<id>79494ffe93cadb66e6c88d7e67d5eff3699fb266</id>
<content type='text'>
commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Wed Feb 13 09:31:53 2013 +0000

    drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan &lt;lantw44@gmail.com&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Wed Feb 13 09:31:53 2013 +0000

    drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan &lt;lantw44@gmail.com&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vTPM: set virtual device before passing to ibmvtpm_reset_crq</title>
<updated>2015-08-03T16:29:56+00:00</updated>
<author>
<name>Hon Ching \\(Vicky\\) Lo</name>
<email>honclo@linux.vnet.ibm.com</email>
</author>
<published>2015-05-22T17:23:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce4703c07b3e0af19c84f301e7664baaa3094e65'/>
<id>ce4703c07b3e0af19c84f301e7664baaa3094e65</id>
<content type='text'>
commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.

tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm-&gt;vdev-&gt;unit_address.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.

tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm-&gt;vdev-&gt;unit_address.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send</title>
<updated>2015-03-26T14:06:54+00:00</updated>
<author>
<name>jmlatten@linux.vnet.ibm.com</name>
<email>jmlatten@linux.vnet.ibm.com</email>
</author>
<published>2015-02-21T00:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f49920b9a288d5ddfc7e50d44d380ac4f60862bf'/>
<id>f49920b9a288d5ddfc7e50d44d380ac4f60862bf</id>
<content type='text'>
commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_console: avoid config access from irq</title>
<updated>2015-03-26T14:06:53+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2015-03-05T00:15:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=59cdf18af738eee76a68d0c3557855465e2977a5'/>
<id>59cdf18af738eee76a68d0c3557855465e2977a5</id>
<content type='text'>
commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 upstream.

when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 upstream.

when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_console: init work unconditionally</title>
<updated>2015-03-26T14:06:53+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2015-03-05T00:15:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8b0c4ab4edfb6b8f4d04ab662a116e90de27695a'/>
<id>8b0c4ab4edfb6b8f4d04ab662a116e90de27695a</id>
<content type='text'>
commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Added Little Endian support to vtpm module</title>
<updated>2015-03-06T22:43:29+00:00</updated>
<author>
<name>honclo</name>
<email>honclo@imap.linux.ibm.com</email>
</author>
<published>2015-02-13T02:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c679cbba9e0c86d3b30072d95bc538adc4bc3d2'/>
<id>2c679cbba9e0c86d3b30072d95bc538adc4bc3d2</id>
<content type='text'>
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
