<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/xen, branch v4.4.74</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>xen/privcmd: Support correctly 64KB page granularity when mapping memory</title>
<updated>2017-06-14T11:16:22+00:00</updated>
<author>
<name>Julien Grall</name>
<email>julien.grall@arm.com</email>
</author>
<published>2017-05-31T13:03:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4467b3a145577b3806339e2766f9b2640b61d7bf'/>
<id>4467b3a145577b3806339e2766f9b2640b61d7bf</id>
<content type='text'>
commit 753c09b5652bb4fe53e2db648002ec64b32b8827 upstream.

Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.

The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma-&gt;vm_private_data)
contain one page per 64KB. Fix it by incrementing st-&gt;index correctly.

Furthermore, st-&gt;va is not correctly incremented as PAGE_SIZE !=
XEN_PAGE_SIZE.

Fixes: 5995a68 ("xen/privcmd: Add support for Linux 64KB page granularity")
Reported-by: Feng Kan &lt;fkan@apm.com&gt;
Signed-off-by: Julien Grall &lt;julien.grall@arm.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.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 753c09b5652bb4fe53e2db648002ec64b32b8827 upstream.

Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.

The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma-&gt;vm_private_data)
contain one page per 64KB. Fix it by incrementing st-&gt;index correctly.

Furthermore, st-&gt;va is not correctly incremented as PAGE_SIZE !=
XEN_PAGE_SIZE.

Fixes: 5995a68 ("xen/privcmd: Add support for Linux 64KB page granularity")
Reported-by: Feng Kan &lt;fkan@apm.com&gt;
Signed-off-by: Julien Grall &lt;julien.grall@arm.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/acpi: upload PM state from init-domain to Xen</title>
<updated>2017-03-30T07:35:18+00:00</updated>
<author>
<name>Ankur Arora</name>
<email>ankur.a.arora@oracle.com</email>
</author>
<published>2017-03-21T22:43:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c856b66c8aac95c74c0ddad4ce1d55a6741e23db'/>
<id>c856b66c8aac95c74c0ddad4ce1d55a6741e23db</id>
<content type='text'>
commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Based-on-patch-by: Konrad Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: Ankur Arora &lt;ankur.a.arora@oracle.com&gt;
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.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 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Based-on-patch-by: Konrad Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Reviewed-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: Ankur Arora &lt;ankur.a.arora@oracle.com&gt;
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing</title>
<updated>2017-01-06T10:16:17+00:00</updated>
<author>
<name>Boris Ostrovsky</name>
<email>boris.ostrovsky@oracle.com</email>
</author>
<published>2016-11-21T14:56:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9397e79c4b2dc3ef0666b9a832941e87e701eeac'/>
<id>9397e79c4b2dc3ef0666b9a832941e87e701eeac</id>
<content type='text'>
commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.

It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().


Reported-by: Olaf Hering &lt;olaf@aepfle.de&gt;
Suggested-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Tested-by: Olaf Hering &lt;olaf@aepfle.de&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.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 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.

It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().


Reported-by: Olaf Hering &lt;olaf@aepfle.de&gt;
Suggested-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Tested-by: Olaf Hering &lt;olaf@aepfle.de&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xenbus: don't look up transaction IDs for ordinary writes</title>
<updated>2016-10-31T10:13:58+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2016-08-15T15:02:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=03cebefe8926d836d736e31d3f8259cd94e7814b'/>
<id>03cebefe8926d836d736e31d3f8259cd94e7814b</id>
<content type='text'>
commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea upstream.

This should really only be done for XS_TRANSACTION_END messages, or
else at least some of the xenstore-* tools don't work anymore.

Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
Reported-by: Richard Schütz &lt;rschuetz@uni-koblenz.de&gt;
Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Tested-by: Richard Schütz &lt;rschuetz@uni-koblenz.de&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: "M. Vefa Bicakci" &lt;m.v.b@runbox.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 9a035a40f7f3f6708b79224b86c5777a3334f7ea upstream.

This should really only be done for XS_TRANSACTION_END messages, or
else at least some of the xenstore-* tools don't work anymore.

Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
Reported-by: Richard Schütz &lt;rschuetz@uni-koblenz.de&gt;
Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Tested-by: Richard Schütz &lt;rschuetz@uni-koblenz.de&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: "M. Vefa Bicakci" &lt;m.v.b@runbox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xenbus: don't bail early from xenbus_dev_request_and_reply()</title>
<updated>2016-08-10T09:49:26+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2016-07-07T07:32:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ee8b7ff00d5b8fc931a63d31349e9a7189cc72d7'/>
<id>ee8b7ff00d5b8fc931a63d31349e9a7189cc72d7</id>
<content type='text'>
commit 7469be95a487319514adce2304ad2af3553d2fc9 upstream.

xenbus_dev_request_and_reply() needs to track whether a transaction is
open.  For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().

If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.

If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.

Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open.  This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.

It appears that the problematic change was added accidentally, so just
remove it.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.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 7469be95a487319514adce2304ad2af3553d2fc9 upstream.

xenbus_dev_request_and_reply() needs to track whether a transaction is
open.  For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().

If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.

If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.

Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open.  This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.

It appears that the problematic change was added accidentally, so just
remove it.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xenbus: don't BUG() on user mode induced condition</title>
<updated>2016-08-10T09:49:26+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2016-07-07T07:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d1e6344e0b97f8c7d2e14a5bd892d0180274e0c5'/>
<id>d1e6344e0b97f8c7d2e14a5bd892d0180274e0c5</id>
<content type='text'>
commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream.

Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.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 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream.

Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/pciback: Fix conf_space read/write overlap check.</title>
<updated>2016-08-10T09:49:26+00:00</updated>
<author>
<name>Andrey Grodzovsky</name>
<email>andrey2805@gmail.com</email>
</author>
<published>2016-06-21T18:26:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=66af4230b41fe0fe4d88e011a849437f176e7732'/>
<id>66af4230b41fe0fe4d88e011a849437f176e7732</id>
<content type='text'>
commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream.

Current overlap check is evaluating to false a case where a filter
field is fully contained (proper subset) of a r/w request.  This
change applies classical overlap check instead to include all the
scenarios.

More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver
the logic is such that the entire confspace is read and written in 4
byte chunks. In this case as an example, CACHE_LINE_SIZE,
LATENCY_TIMER and PCI_BIST are arriving together in one call to
xen_pcibk_config_write() with offset == 0xc and size == 4.  With the
exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length
== 1) is fully contained in the write request and hence is excluded
from write, which is incorrect.

Signed-off-by: Andrey Grodzovsky &lt;andrey2805@gmail.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Reviewed-by: Jan Beulich &lt;JBeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.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 02ef871ecac290919ea0c783d05da7eedeffc10e upstream.

Current overlap check is evaluating to false a case where a filter
field is fully contained (proper subset) of a r/w request.  This
change applies classical overlap check instead to include all the
scenarios.

More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver
the logic is such that the entire confspace is read and written in 4
byte chunks. In this case as an example, CACHE_LINE_SIZE,
LATENCY_TIMER and PCI_BIST are arriving together in one call to
xen_pcibk_config_write() with offset == 0xc and size == 4.  With the
exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length
== 1) is fully contained in the write request and hence is excluded
from write, which is incorrect.

Signed-off-by: Andrey Grodzovsky &lt;andrey2805@gmail.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Reviewed-by: Jan Beulich &lt;JBeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7</title>
<updated>2016-07-27T16:47:39+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2016-07-08T12:15:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=32d10678d42f807310e752410696117b4a3185e7'/>
<id>32d10678d42f807310e752410696117b4a3185e7</id>
<content type='text'>
commit 6f2d9d99213514360034c6d52d2c3919290b3504 upstream.

As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.

Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.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 6f2d9d99213514360034c6d52d2c3919290b3504 upstream.

As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.

Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/balloon: Fix declared-but-not-defined warning</title>
<updated>2016-07-27T16:47:36+00:00</updated>
<author>
<name>Ross Lagerwall</name>
<email>ross.lagerwall@citrix.com</email>
</author>
<published>2016-05-10T09:27:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe29254aed62f14742a9d7fc6056aebac5ae8876'/>
<id>fe29254aed62f14742a9d7fc6056aebac5ae8876</id>
<content type='text'>
commit 842775f1509054ea969f1787f38d6a0ec2ccfaba upstream.

Fix a declared-but-not-defined warning when building with
XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
commit dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32
bit PAE").

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Acked-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.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 842775f1509054ea969f1787f38d6a0ec2ccfaba upstream.

Fix a declared-but-not-defined warning when building with
XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
commit dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32
bit PAE").

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Acked-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/events: Don't move disabled irqs</title>
<updated>2016-06-08T01:14:36+00:00</updated>
<author>
<name>Ross Lagerwall</name>
<email>ross.lagerwall@citrix.com</email>
</author>
<published>2016-05-10T15:11:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6232876e14a5a7fc0b0449a740bda8ffe2ed59ed'/>
<id>6232876e14a5a7fc0b0449a740bda8ffe2ed59ed</id>
<content type='text'>
commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc-&gt;lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[&lt;ffffffff810e26e2&gt;]  [&lt;ffffffff810e26e2&gt;] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [&lt;ffffffff814c8d92&gt;] eoi_pirq+0xb2/0xf0
 [&lt;ffffffff814c8f66&gt;] __startup_pirq+0xe6/0x150
 [&lt;ffffffff814ca659&gt;] xen_irq_resume+0x319/0x360
 [&lt;ffffffff814c7e75&gt;] xen_suspend+0xb5/0x180
 [&lt;ffffffff81120155&gt;] multi_cpu_stop+0xb5/0xe0
 [&lt;ffffffff811200a0&gt;] ? cpu_stop_queue_work+0x80/0x80
 [&lt;ffffffff811203d0&gt;] cpu_stopper_thread+0xb0/0x140
 [&lt;ffffffff810a94e6&gt;] ? finish_task_switch+0x76/0x220
 [&lt;ffffffff810ca731&gt;] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [&lt;ffffffff810a3935&gt;] smpboot_thread_fn+0x105/0x160
 [&lt;ffffffff810a3830&gt;] ? sort_range+0x30/0x30
 [&lt;ffffffff810a0588&gt;] kthread+0xd8/0xf0
 [&lt;ffffffff810a04b0&gt;] ? kthread_create_on_node+0x1e0/0x1e0
 [&lt;ffffffff8182568f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810a04b0&gt;] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.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 f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc-&gt;lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[&lt;ffffffff810e26e2&gt;]  [&lt;ffffffff810e26e2&gt;] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [&lt;ffffffff814c8d92&gt;] eoi_pirq+0xb2/0xf0
 [&lt;ffffffff814c8f66&gt;] __startup_pirq+0xe6/0x150
 [&lt;ffffffff814ca659&gt;] xen_irq_resume+0x319/0x360
 [&lt;ffffffff814c7e75&gt;] xen_suspend+0xb5/0x180
 [&lt;ffffffff81120155&gt;] multi_cpu_stop+0xb5/0xe0
 [&lt;ffffffff811200a0&gt;] ? cpu_stop_queue_work+0x80/0x80
 [&lt;ffffffff811203d0&gt;] cpu_stopper_thread+0xb0/0x140
 [&lt;ffffffff810a94e6&gt;] ? finish_task_switch+0x76/0x220
 [&lt;ffffffff810ca731&gt;] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [&lt;ffffffff810a3935&gt;] smpboot_thread_fn+0x105/0x160
 [&lt;ffffffff810a3830&gt;] ? sort_range+0x30/0x30
 [&lt;ffffffff810a0588&gt;] kthread+0xd8/0xf0
 [&lt;ffffffff810a04b0&gt;] ? kthread_create_on_node+0x1e0/0x1e0
 [&lt;ffffffff8182568f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810a04b0&gt;] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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