<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/virtio, branch v3.16.77</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.16.77</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.16.77'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-11-20T18:05:52Z</updated>
<entry>
<title>virtio_balloon: fix another race between migration and ballooning</title>
<updated>2018-11-20T18:05:52Z</updated>
<author>
<name>Jiang Biao</name>
<email>jiang.biao2@zte.com.cn</email>
</author>
<published>2018-07-18T02:29:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0a620f8d2501f295f4139d75f38b5298bdab4304'/>
<id>urn:sha1:0a620f8d2501f295f4139d75f38b5298bdab4304</id>
<content type='text'>
commit 89da619bc18d79bca5304724c11d4ba3b67ce2c6 upstream.

Kernel panic when with high memory pressure, calltrace looks like,

PID: 21439 TASK: ffff881be3afedd0 CPU: 16 COMMAND: "java"
 #0 [ffff881ec7ed7630] machine_kexec at ffffffff81059beb
 #1 [ffff881ec7ed7690] __crash_kexec at ffffffff81105942
 #2 [ffff881ec7ed7760] crash_kexec at ffffffff81105a30
 #3 [ffff881ec7ed7778] oops_end at ffffffff816902c8
 #4 [ffff881ec7ed77a0] no_context at ffffffff8167ff46
 #5 [ffff881ec7ed77f0] __bad_area_nosemaphore at ffffffff8167ffdc
 #6 [ffff881ec7ed7838] __node_set at ffffffff81680300
 #7 [ffff881ec7ed7860] __do_page_fault at ffffffff8169320f
 #8 [ffff881ec7ed78c0] do_page_fault at ffffffff816932b5
 #9 [ffff881ec7ed78f0] page_fault at ffffffff8168f4c8
    [exception RIP: _raw_spin_lock_irqsave+47]
    RIP: ffffffff8168edef RSP: ffff881ec7ed79a8 RFLAGS: 00010046
    RAX: 0000000000000246 RBX: ffffea0019740d00 RCX: ffff881ec7ed7fd8
    RDX: 0000000000020000 RSI: 0000000000000016 RDI: 0000000000000008
    RBP: ffff881ec7ed79a8 R8: 0000000000000246 R9: 000000000001a098
    R10: ffff88107ffda000 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000008 R14: ffff881ec7ed7a80 R15: ffff881be3afedd0
    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

It happens in the pagefault and results in double pagefault
during compacting pages when memory allocation fails.

Analysed the vmcore, the page leads to second pagefault is corrupted
with _mapcount=-256, but private=0.

It's caused by the race between migration and ballooning, and lock
missing in virtballoon_migratepage() of virtio_balloon driver.
This patch fix the bug.

Fixes: e22504296d4f64f ("virtio_balloon: introduce migration primitives to balloon pages")
Signed-off-by: Jiang Biao &lt;jiang.biao2@zte.com.cn&gt;
Signed-off-by: Huang Chong &lt;huang.chong@zte.com.cn&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>virtio: release virtio index when fail to device_register</title>
<updated>2018-03-03T15:51:42Z</updated>
<author>
<name>weiping zhang</name>
<email>zwp10758@gmail.com</email>
</author>
<published>2017-11-29T01:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=85c249d616c94c05947d26c095f739e880fb18b5'/>
<id>urn:sha1:85c249d616c94c05947d26c095f739e880fb18b5</id>
<content type='text'>
commit e60ea67bb60459b95a50a156296041a13e0e380e upstream.

index can be reused by other virtio device.

Signed-off-by: weiping zhang &lt;zhangweiping@didichuxing.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>virtio_balloon: prevent uninitialized variable use</title>
<updated>2017-07-18T17:40:24Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-03-28T16:46:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3b5d8b047896c1685df59e0025ed5d11f9ee05e9'/>
<id>urn:sha1:3b5d8b047896c1685df59e0025ed5d11f9ee05e9</id>
<content type='text'>
commit f0bb2d50dfcc519f06f901aac88502be6ff1df2c upstream.

The latest gcc-7.0.1 snapshot reports a new warning:

virtio/virtio_balloon.c: In function 'update_balloon_stats':
virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in this function [-Werror=uninitialized]

This seems absolutely right, so we should add an extra check to
prevent copying uninitialized stack data into the statistics.
&gt;From all I can tell, this has been broken since the statistics code
was originally added in 2.6.34.

Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Ladi Prosek &lt;lprosek@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>virtio_balloon: init 1st buffer in stats vq</title>
<updated>2017-07-18T17:40:24Z</updated>
<author>
<name>Ladi Prosek</name>
<email>lprosek@redhat.com</email>
</author>
<published>2017-03-23T07:04:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=710aa47c094603809b2218ae8f40b6ce382ba2b0'/>
<id>urn:sha1:710aa47c094603809b2218ae8f40b6ce382ba2b0</id>
<content type='text'>
commit fc8653228c8588a120f6b5dad6983b7b61ff669e upstream.

When init_vqs runs, virtio_balloon.stats is either uninitialized or
contains stale values. The host updates its state with garbage data
because it has no way of knowing that this is just a marker buffer
used for signaling.

This patch updates the stats before pushing the initial buffer.

Alternative fixes:
* Push an empty buffer in init_vqs. Not easily done with the current
  virtio implementation and violates the spec "Driver MUST supply the
  same subset of statistics in all buffers submitted to the statsq".
* Push a buffer with invalid tags in init_vqs. Violates the same
  spec clause, plus "invalid tag" is not really defined.

Note: the spec says:
	When using the legacy interface, the device SHOULD ignore all values in
	the first buffer in the statsq supplied by the driver after device
	initialization. Note: Historically, drivers supplied an uninitialized
	buffer in the first buffer.

Unfortunately QEMU does not seem to implement the recommendation
even for the legacy interface.

Signed-off-by: Ladi Prosek &lt;lprosek@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>balloon: check the number of available pages in leak balloon</title>
<updated>2016-11-20T01:17:03Z</updated>
<author>
<name>Konstantin Neumoin</name>
<email>kneumoin@virtuozzo.com</email>
</author>
<published>2016-07-11T12:28:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f6508315cc915bf41e00868d2336dfdf3a7ace8f'/>
<id>urn:sha1:f6508315cc915bf41e00868d2336dfdf3a7ace8f</id>
<content type='text'>
commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 upstream.

The balloon has a special mechanism that is subscribed to the oom
notification which leads to deflation for a fixed number of pages.
The number is always fixed even when the balloon is fully deflated.
But leak_balloon did not expect that the pages to deflate will be more
than taken, and raise a "BUG" in balloon_page_dequeue when page list
will be empty.

So, the simplest solution would be to check that the number of releases
pages is less or equal to the number taken pages.

Signed-off-by: Konstantin Neumoin &lt;kneumoin@virtuozzo.com&gt;
Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
CC: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mm/balloon_compaction: redesign ballooned pages management</title>
<updated>2016-06-15T20:29:35Z</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>k.khlebnikov@samsung.com</email>
</author>
<published>2014-10-09T22:29:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=514488e2bdbb11da02735f1b864adcfdd7bae0da'/>
<id>urn:sha1:514488e2bdbb11da02735f1b864adcfdd7bae0da</id>
<content type='text'>
commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 upstream.

Sasha Levin reported KASAN splash inside isolate_migratepages_range().
Problem is in the function __is_movable_balloon_page() which tests
AS_BALLOON_MAP in page-&gt;mapping-&gt;flags.  This function has no protection
against anonymous pages.  As result it tried to check address space flags
inside struct anon_vma.

Further investigation shows more problems in current implementation:

* Special branch in __unmap_and_move() never works:
  balloon_page_movable() checks page flags and page_count.  In
  __unmap_and_move() page is locked, reference counter is elevated, thus
  balloon_page_movable() always fails.  As a result execution goes to the
  normal migration path.  virtballoon_migratepage() returns
  MIGRATEPAGE_BALLOON_SUCCESS instead of MIGRATEPAGE_SUCCESS,
  move_to_new_page() thinks this is an error code and assigns
  newpage-&gt;mapping to NULL.  Newly migrated page lose connectivity with
  balloon an all ability for further migration.

* lru_lock erroneously required in isolate_migratepages_range() for
  isolation ballooned page.  This function releases lru_lock periodically,
  this makes migration mostly impossible for some pages.

* balloon_page_dequeue have a tight race with balloon_page_isolate:
  balloon_page_isolate could be executed in parallel with dequeue between
  picking page from list and locking page_lock.  Race is rare because they
  use trylock_page() for locking.

This patch fixes all of them.

Instead of fake mapping with special flag this patch uses special state of
page-&gt;_mapcount: PAGE_BALLOON_MAPCOUNT_VALUE = -256.  Buddy allocator uses
PAGE_BUDDY_MAPCOUNT_VALUE = -128 for similar purpose.  Storing mark
directly in struct page makes everything safer and easier.

PagePrivate is used to mark pages present in page list (i.e.  not
isolated, like PageLRU for normal pages).  It replaces special rules for
reference counter and makes balloon migration similar to migration of
normal pages.  This flag is protected by page_lock together with link to
the balloon device.

Signed-off-by: Konstantin Khlebnikov &lt;k.khlebnikov@samsung.com&gt;
Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Link: http://lkml.kernel.org/p/53E6CEAA.9020105@oracle.com
Cc: Rafael Aquini &lt;aquini@redhat.com&gt;
Cc: Andrey Ryabinin &lt;ryabinin.a.a@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[bwh: Backported to 3.16:
 - Remove an additional check for MIGRATEPAGE_BALLOON_SUCCESS in
   __unmap_and_move()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: jian wang &lt;wangjian@bytedance.com&gt;
</content>
</entry>
<entry>
<title>virtio_pci: fix use after free on release</title>
<updated>2016-02-17T10:22:39Z</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2016-01-14T14:00:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8014c2513d5f595cfde7036ea4b4d98e2c223dd2'/>
<id>urn:sha1:8014c2513d5f595cfde7036ea4b4d98e2c223dd2</id>
<content type='text'>
commit 2989be09a8a9d62a785137586ad941f916e08f83 upstream.

KASan detected a use-after-free error in virtio-pci remove code. In
virtio_pci_remove(), vp_dev is still used after being freed in
unregister_virtio_device() (in virtio_pci_release_dev() more
precisely).

To fix, keep a reference until cleanup is done.

Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback")
Reported-by: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Cc: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Tested-by: Jerome Marchand &lt;jmarchan@redhat.com&gt;
[ luis: backported to 3.16:
  - file rename: virtio_pci_legacy.c -&gt; virtio_pci.c ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>virtio_balloon: fix race by fill and leak</title>
<updated>2016-02-02T19:09:32Z</updated>
<author>
<name>Minchan Kim</name>
<email>minchan@kernel.org</email>
</author>
<published>2015-12-27T23:35:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9f0f48350a29b198a3d8c530ce8376c3346f5151'/>
<id>urn:sha1:9f0f48350a29b198a3d8c530ce8376c3346f5151</id>
<content type='text'>
commit f68b992bbb474641881932c61c92dcfa6f5b3689 upstream.

During my compaction-related stuff, I encountered a bug
with ballooning.

With repeated inflating and deflating cycle, guest memory(
ie, cat /proc/meminfo | grep MemTotal) is decreased and
couldn't be recovered.

The reason is balloon_lock doesn't cover release_pages_balloon
so struct virtio_balloon fields could be overwritten by race
of fill_balloon(e,g, vb-&gt;*pfns could be critical).

This patch fixes it in my test.

Signed-off-by: Minchan Kim &lt;minchan@kernel.org&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>virtio: fix memory leak of virtio ida cache layers</title>
<updated>2016-01-11T10:50:18Z</updated>
<author>
<name>Suman Anna</name>
<email>s-anna@ti.com</email>
</author>
<published>2015-09-17T00:29:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1962eb806c080987c1631c977c0bfe77f0d0063a'/>
<id>urn:sha1:1962eb806c080987c1631c977c0bfe77f0d0063a</id>
<content type='text'>
commit c13f99b7e945dad5273a8b7ee230f4d1f22d3354 upstream.

The virtio core uses a static ida named virtio_index_ida for
assigning index numbers to virtio devices during registration.
The ida core may allocate some internal idr cache layers and
an ida bitmap upon any ida allocation, and all these layers are
truely freed only upon the ida destruction. The virtio_index_ida
is not destroyed at present, leading to a memory leak when using
the virtio core as a module and atleast one virtio device is
registered and unregistered.

Fix this by invoking ida_destroy() in the virtio core module
exit.

Signed-off-by: Suman Anna &lt;s-anna@ti.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>virtio_pci: Clear stale cpumask when setting irq affinity</title>
<updated>2015-06-30T16:15:20Z</updated>
<author>
<name>Jiang Liu</name>
<email>jiang.liu@linux.intel.com</email>
</author>
<published>2015-06-04T08:41:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9ca6d16448ea5351ca69e561eed2a34edcbd390a'/>
<id>urn:sha1:9ca6d16448ea5351ca69e561eed2a34edcbd390a</id>
<content type='text'>
commit 210d150e1f5da506875e376422ba31ead2d49621 upstream.

The cpumask vp_dev-&gt;msix_affinity_masks[info-&gt;msix_vector] may contain
staled information when vp_set_vq_affinity() gets called, so clear it
before setting the new cpu bit mask.

Signed-off-by: Jiang Liu &lt;jiang.liu@linux.intel.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
[ luis: backported to 3.16:
  - file rename: virtio_pci_common.c -&gt; virtio_pci.c ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
</feed>
