<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch, branch v4.13.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: 8692/1: mm: abort uaccess retries upon fatal signal</title>
<updated>2017-09-13T21:20:54+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2017-08-22T10:36:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=03466e0324224a0de496f4ea720c5e6dd863a3e5'/>
<id>03466e0324224a0de496f4ea720c5e6dd863a3e5</id>
<content type='text'>
commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.

When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Reviewed-by: Steve Capper &lt;steve.capper@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&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 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.

When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Reviewed-by: Steve Capper &lt;steve.capper@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt</title>
<updated>2017-09-13T21:20:54+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2017-07-01T14:16:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f6eba3f72f008766a42a5fe0719f0c8385e337c'/>
<id>2f6eba3f72f008766a42a5fe0719f0c8385e337c</id>
<content type='text'>
commit 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.

The GIC-500 integrated in the Armada-37xx SoCs is compliant with
the GICv3 architecture, and thus provides a maintenance interrupt
that is required for hypervisors to function correctly.

With the interrupt provided in the DT, KVM now works as it should.
Tested on an Espressobin system.

Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.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 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.

The GIC-500 integrated in the Armada-37xx SoCs is compliant with
the GICv3 architecture, and thus provides a maintenance interrupt
that is required for hypervisors to function correctly.

With the interrupt provided in the DT, KVM now works as it should.
Tested on an Espressobin system.

Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: SVM: Limit PFERR_NESTED_GUEST_PAGE error_code check to L1 guest</title>
<updated>2017-09-13T21:20:53+00:00</updated>
<author>
<name>Brijesh Singh</name>
<email>brijesh.singh@amd.com</email>
</author>
<published>2017-08-07T19:11:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d7960e036cc72f46fbd2bec82aacf57382d53d0'/>
<id>9d7960e036cc72f46fbd2bec82aacf57382d53d0</id>
<content type='text'>
commit 64531a3b70b17c8d3e77f2e49e5e1bb70f571266 upstream.

Commit 147277540bbc ("kvm: svm: Add support for additional SVM NPF error
codes", 2016-11-23) added a new error code to aid nested page fault
handling.  The commit unprotects (kvm_mmu_unprotect_page) the page when
we get a NPF due to guest page table walk where the page was marked RO.

However, if an L0-&gt;L2 shadow nested page table can also be marked read-only
when a page is read only in L1's nested page table.  If such a page
is accessed by L2 while walking page tables it can cause a nested
page fault (page table walks are write accesses).  However, after
kvm_mmu_unprotect_page we may get another page fault, and again in an
endless stream.

To cover this use case, we qualify the new error_code check with
vcpu-&gt;arch.mmu_direct_map so that the error_code check would run on L1
guest, and not the L2 guest.  This avoids hitting the above scenario.

Fixes: 147277540bbc54119172481c8ef6d930cc9fbfc2
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Cc: Thomas Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.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 64531a3b70b17c8d3e77f2e49e5e1bb70f571266 upstream.

Commit 147277540bbc ("kvm: svm: Add support for additional SVM NPF error
codes", 2016-11-23) added a new error code to aid nested page fault
handling.  The commit unprotects (kvm_mmu_unprotect_page) the page when
we get a NPF due to guest page table walk where the page was marked RO.

However, if an L0-&gt;L2 shadow nested page table can also be marked read-only
when a page is read only in L1's nested page table.  If such a page
is accessed by L2 while walking page tables it can cause a nested
page fault (page table walks are write accesses).  However, after
kvm_mmu_unprotect_page we may get another page fault, and again in an
endless stream.

To cover this use case, we qualify the new error_code check with
vcpu-&gt;arch.mmu_direct_map so that the error_code check would run on L1
guest, and not the L2 guest.  This avoids hitting the above scenario.

Fixes: 147277540bbc54119172481c8ef6d930cc9fbfc2
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Cc: Thomas Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs</title>
<updated>2017-09-09T15:39:26+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2017-08-24T10:55:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0441819b67fea3e3e96852c7a3fa6807d7a8f22'/>
<id>e0441819b67fea3e3e96852c7a3fa6807d7a8f22</id>
<content type='text'>
commit fa41ba0d08de7c975c3e94d0067553f9b934221f upstream.

Right now there is a potential hang situation for postcopy migrations,
if the guest is enabling storage keys on the target system during the
postcopy process.

For storage key virtualization, we have to forbid the empty zero page as
the storage key is a property of the physical page frame.  As we enable
storage key handling lazily we then drop all mappings for empty zero
pages for lazy refaulting later on.

This does not work with the postcopy migration, which relies on the
empty zero page never triggering a fault again in the future. The reason
is that postcopy migration will simply read a page on the target system
if that page is a known zero page to fault in an empty zero page.  At
the same time postcopy remembers that this page was already transferred
- so any future userfault on that page will NOT be retransmitted again
to avoid races.

If now the guest enters the storage key mode while in postcopy, we will
break this assumption of postcopy.

The solution is to disable the empty zero page for KVM guests early on
and not during storage key enablement. With this change, the postcopy
migration process is guaranteed to start after no zero pages are left.

As guest pages are very likely not empty zero pages anyway the memory
overhead is also pretty small.

While at it this also adds proper page table locking to the zero page
removal.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Acked-by: Janosch Frank &lt;frankja@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.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 fa41ba0d08de7c975c3e94d0067553f9b934221f upstream.

Right now there is a potential hang situation for postcopy migrations,
if the guest is enabling storage keys on the target system during the
postcopy process.

For storage key virtualization, we have to forbid the empty zero page as
the storage key is a property of the physical page frame.  As we enable
storage key handling lazily we then drop all mappings for empty zero
pages for lazy refaulting later on.

This does not work with the postcopy migration, which relies on the
empty zero page never triggering a fault again in the future. The reason
is that postcopy migration will simply read a page on the target system
if that page is a known zero page to fault in an empty zero page.  At
the same time postcopy remembers that this page was already transferred
- so any future userfault on that page will NOT be retransmitted again
to avoid races.

If now the guest enters the storage key mode while in postcopy, we will
break this assumption of postcopy.

The solution is to disable the empty zero page for KVM guests early on
and not during storage key enablement. With this change, the postcopy
migration process is guaranteed to start after no zero pages are left.

As guest pages are very likely not empty zero pages anyway the memory
overhead is also pretty small.

While at it this also adds proper page table locking to the zero page
removal.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Acked-by: Janosch Frank &lt;frankja@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus</title>
<updated>2017-09-03T16:50:26+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-03T16:50:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e3b19d8165c2af2afee313c9b40eee55cf27a55'/>
<id>5e3b19d8165c2af2afee313c9b40eee55cf27a55</id>
<content type='text'>
Pull MIPS fixes from Ralf Baechle:
 "The two indirect syscall fixes have sat in linux-next for a few days.
  I did check back with a hardware designer to ensure a SYNC is really
  what's required for the GIC fix and so the GIC fix didn't make it into
  to linux-next in time for this final pull request.

  It builds in local build tests and passes Imagination's test system"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  irqchip: mips-gic: SYNC after enabling GIC region
  MIPS: Remove pt_regs adjustments in indirect syscall handler
  MIPS: seccomp: Fix indirect syscall args
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull MIPS fixes from Ralf Baechle:
 "The two indirect syscall fixes have sat in linux-next for a few days.
  I did check back with a hardware designer to ensure a SYNC is really
  what's required for the GIC fix and so the GIC fix didn't make it into
  to linux-next in time for this final pull request.

  It builds in local build tests and passes Imagination's test system"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  irqchip: mips-gic: SYNC after enabling GIC region
  MIPS: Remove pt_regs adjustments in indirect syscall handler
  MIPS: seccomp: Fix indirect syscall args
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2017-09-03T16:35:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-03T16:35:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d0fa6ea10e438cfd4471ac196655fbb2c2b1329a'/>
<id>d0fa6ea10e438cfd4471ac196655fbb2c2b1329a</id>
<content type='text'>
Pull x86 fixes from Thomas Gleixner:

 - Expand the space for uncompressing as the LZ4 worst case does not fit
   into the currently reserved space

 - Validate boot parameters more strictly to prevent out of bound access
   in the decompressor/boot code

 - Fix off by one errors in get_segment_base()

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Prevent faulty bootparams.screeninfo from causing harm
  x86/boot: Provide more slack space during decompression
  x86/ldt: Fix off by one in get_segment_base()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull x86 fixes from Thomas Gleixner:

 - Expand the space for uncompressing as the LZ4 worst case does not fit
   into the currently reserved space

 - Validate boot parameters more strictly to prevent out of bound access
   in the decompressor/boot code

 - Fix off by one errors in get_segment_base()

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Prevent faulty bootparams.screeninfo from causing harm
  x86/boot: Provide more slack space during decompression
  x86/ldt: Fix off by one in get_segment_base()
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2017-09-02T00:16:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-02T00:16:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=54f70f52e3b3a26164220d98a712a274bd28502f'/>
<id>54f70f52e3b3a26164220d98a712a274bd28502f</id>
<content type='text'>
Pull ARM SoC fixes from Olof Johansson:
 "A couple of late-arriving fixes before final 4.13:

   - A few reverts of DT bindings on Allwinner for their ethernet
     driver. Discussion didn't converge, and since bindings are
     considered ABI it makes sense to revert instead of having to
     support two bindings long-term.

   - A fix to enumerate GPIOs properly on Marvell Armada AP806"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description
  arm: dts: sunxi: Revert EMAC changes
  arm64: dts: allwinner: Revert EMAC changes
  dt-bindings: net: Revert sun8i dwmac binding
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC fixes from Olof Johansson:
 "A couple of late-arriving fixes before final 4.13:

   - A few reverts of DT bindings on Allwinner for their ethernet
     driver. Discussion didn't converge, and since bindings are
     considered ABI it makes sense to revert instead of having to
     support two bindings long-term.

   - A fix to enumerate GPIOs properly on Marvell Armada AP806"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description
  arm: dts: sunxi: Revert EMAC changes
  arm64: dts: allwinner: Revert EMAC changes
  dt-bindings: net: Revert sun8i dwmac binding
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu into fixes</title>
<updated>2017-09-01T23:37:02+00:00</updated>
<author>
<name>Olof Johansson</name>
<email>olof@lixom.net</email>
</author>
<published>2017-09-01T23:37:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6f71a925761e7843965a704eb6682ea337abb4a5'/>
<id>6f71a925761e7843965a704eb6682ea337abb4a5</id>
<content type='text'>
mvebu fixes for 4.13 (part 3)

Fix number of GPIOs in AP806 description for Armada 7K/8K

* tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu:
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description

Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mvebu fixes for 4.13 (part 3)

Fix number of GPIOs in AP806 description for Armada 7K/8K

* tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu:
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description

Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux</title>
<updated>2017-09-01T17:36:22+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-01T17:36:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bba2a5b8221850418846d62887d5de311df335f9'/>
<id>bba2a5b8221850418846d62887d5de311df335f9</id>
<content type='text'>
Pull s390 fixes from Martin Schwidefsky:
 "Three more bug fixes for v4.13.

  The two memory management related fixes are quite new, they fix kernel
  crashes that can be triggered by user space.

  The third commit fixes a bug in the vfio ccw translation code"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: fix BUG_ON in crst_table_upgrade
  s390/mm: fork vs. 5 level page tabel
  vfio: ccw: fix bad ptr math for TIC cda translation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull s390 fixes from Martin Schwidefsky:
 "Three more bug fixes for v4.13.

  The two memory management related fixes are quite new, they fix kernel
  crashes that can be triggered by user space.

  The third commit fixes a bug in the vfio ccw translation code"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: fix BUG_ON in crst_table_upgrade
  s390/mm: fork vs. 5 level page tabel
  vfio: ccw: fix bad ptr math for TIC cda translation
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: update to new mmu_notifier semantic v2</title>
<updated>2017-08-31T23:13:00+00:00</updated>
<author>
<name>Jérôme Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2017-08-31T21:17:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb1522e099f0c69f36655af233a64e3f55941f5b'/>
<id>fb1522e099f0c69f36655af233a64e3f55941f5b</id>
<content type='text'>
Calls to mmu_notifier_invalidate_page() were replaced by calls to
mmu_notifier_invalidate_range() and are now bracketed by calls to
mmu_notifier_invalidate_range_start()/end()

Remove now useless invalidate_page callback.

Changed since v1 (Linus Torvalds)
    - remove now useless kvm_arch_mmu_notifier_invalidate_page()

Signed-off-by: Jérôme Glisse &lt;jglisse@redhat.com&gt;
Tested-by: Mike Galbraith &lt;efault@gmx.de&gt;
Tested-by: Adam Borowski &lt;kilobyte@angband.pl&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Cc: kvm@vger.kernel.org
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Calls to mmu_notifier_invalidate_page() were replaced by calls to
mmu_notifier_invalidate_range() and are now bracketed by calls to
mmu_notifier_invalidate_range_start()/end()

Remove now useless invalidate_page callback.

Changed since v1 (Linus Torvalds)
    - remove now useless kvm_arch_mmu_notifier_invalidate_page()

Signed-off-by: Jérôme Glisse &lt;jglisse@redhat.com&gt;
Tested-by: Mike Galbraith &lt;efault@gmx.de&gt;
Tested-by: Adam Borowski &lt;kilobyte@angband.pl&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Cc: kvm@vger.kernel.org
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
