<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/mm/z3fold.c, branch linux-5.5.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.5.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.5.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-12-01T20:59:07Z</updated>
<entry>
<title>mm/z3fold.c: add inter-page compaction</title>
<updated>2019-12-01T20:59:07Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2019-12-01T01:56:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4a3ac9311dac3850d1fbaa8bcad4cf10c4fc6296'/>
<id>urn:sha1:4a3ac9311dac3850d1fbaa8bcad4cf10c4fc6296</id>
<content type='text'>
For each page scheduled for compaction (e.  g.  by z3fold_free()), try to
apply inter-page compaction before running the traditional/ existing
intra-page compaction.  That means, if the page has only one buddy, we
treat that buddy as a new object that we aim to place into an existing
z3fold page.  If such a page is found, that object is transferred and the
old page is freed completely.  The transferred object is named "foreign"
and treated slightly differently thereafter.

Namely, we increase "foreign handle" counter for the new page.  Pages with
non-zero "foreign handle" count become unmovable.  This patch implements
"foreign handle" detection when a handle is freed to decrement the foreign
handle counter accordingly, so a page may as well become movable again as
the time goes by.

As a result, we almost always have exactly 3 objects per page and
significantly better average compression ratio.

[cai@lca.pw: fix -Wunused-but-set-variable warnings]
  Link: http://lkml.kernel.org/r/1570542062-29144-1-git-send-email-cai@lca.pw
[vitalywool@gmail.com: avoid subtle race when freeing slots]
  Link: http://lkml.kernel.org/r/20191127152118.6314b99074b0626d4c5a8835@gmail.com
[vitalywool@gmail.com: compact objects more accurately]
  Link: http://lkml.kernel.org/r/20191127152216.6ad33745a21ba71c53606acb@gmail.com
[vitalywool@gmail.com: protect handle reads]
  Link: http://lkml.kernel.org/r/20191127152345.8059852f60947686674d726d@gmail.com
Link: http://lkml.kernel.org/r/20191006041457.24113-1-vitalywool@gmail.com
Signed-off-by: Vitaly Wool &lt;vitaly.vul@sony.com&gt;
Cc: Dan Streetman &lt;ddstreet@ieee.org&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/z3fold.c: claim page in the beginning of free</title>
<updated>2019-10-07T22:47:19Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2019-10-07T00:58:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5b6807de11445c05b537df8324f5d7ab1c2782f9'/>
<id>urn:sha1:5b6807de11445c05b537df8324f5d7ab1c2782f9</id>
<content type='text'>
There's a really hard to reproduce race in z3fold between z3fold_free()
and z3fold_reclaim_page().  z3fold_reclaim_page() can claim the page
after z3fold_free() has checked if the page was claimed and
z3fold_free() will then schedule this page for compaction which may in
turn lead to random page faults (since that page would have been
reclaimed by then).

Fix that by claiming page in the beginning of z3fold_free() and not
forgetting to clear the claim in the end.

[vitalywool@gmail.com: v2]
  Link: http://lkml.kernel.org/r/20190928113456.152742cf@bigdell
Link: http://lkml.kernel.org/r/20190926104844.4f0c6efa1366b8f5741eaba9@gmail.com
Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Reported-by: Markus Linnala &lt;markus.linnala@gmail.com&gt;
Cc: Dan Streetman &lt;ddstreet@ieee.org&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Markus Linnala &lt;markus.linnala@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>z3fold: fix memory leak in kmem cache</title>
<updated>2019-09-24T22:54:10Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2019-09-23T22:36:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=63398413c00c7836ea87a1fa205c91d2199b25cf'/>
<id>urn:sha1:63398413c00c7836ea87a1fa205c91d2199b25cf</id>
<content type='text'>
Currently there is a leak in init_z3fold_page() -- it allocates handles
from kmem cache even for headless pages, but then they are never used and
never freed, so eventually kmem cache may get exhausted.  This patch
provides a fix for that.

Link: http://lkml.kernel.org/r/20190917185352.44cf285d3ebd9e64548de5de@gmail.com
Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Reported-by: Markus Linnala &lt;markus.linnala@gmail.com&gt;
Tested-by: Markus Linnala &lt;markus.linnala@gmail.com&gt;
Cc: Dan Streetman &lt;ddstreet@ieee.org&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>z3fold: fix retry mechanism in page reclaim</title>
<updated>2019-09-24T22:54:06Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2019-09-23T22:33:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3f9d2b5766aea06042630ac60b7316fd0cebf06f'/>
<id>urn:sha1:3f9d2b5766aea06042630ac60b7316fd0cebf06f</id>
<content type='text'>
z3fold_page_reclaim()'s retry mechanism is broken: on a second iteration
it will have zhdr from the first one so that zhdr is no longer in line
with struct page.  That leads to crashes when the system is stressed.

Fix that by moving zhdr assignment up.

While at it, protect against using already freed handles by using own
local slots structure in z3fold_page_reclaim().

Link: http://lkml.kernel.org/r/20190908162919.830388dc7404d1e2c80f4095@gmail.com
Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Reported-by: Markus Linnala &lt;markus.linnala@gmail.com&gt;
Reported-by: Chris Murphy &lt;bugzilla@colorremedies.com&gt;
Reported-by: Agustin Dall'Alba &lt;agustin@dallalba.com.ar&gt;
Cc: "Maciej S. Szmigiero" &lt;mail@maciej.szmigiero.name&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "mm/z3fold.c: fix race between migration and destruction"</title>
<updated>2019-09-24T22:54:06Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2019-09-23T22:32:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6e73fd25e2c7510b7dfadbaf701f31d4bff9c75b'/>
<id>urn:sha1:6e73fd25e2c7510b7dfadbaf701f31d4bff9c75b</id>
<content type='text'>
With the original commit applied, z3fold_zpool_destroy() may get blocked
on wait_event() for indefinite time.  Revert this commit for the time
being to get rid of this problem since the issue the original commit
addresses is less severe.

Link: http://lkml.kernel.org/r/20190910123142.7a9c8d2de4d0acbc0977c602@gmail.com
Fixes: d776aaa9895eb6eb77 ("mm/z3fold.c: fix race between migration and destruction")
Reported-by: Agustín Dall'Alba &lt;agustin@dallalba.com.ar&gt;
Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Jonathan Adams &lt;jwadams@google.com&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/z3fold.c: fix lock/unlock imbalance in z3fold_page_isolate</title>
<updated>2019-08-31T01:00:50Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2019-08-30T23:04:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=14108b9131a47ff18a3c640f583eb2d625c75c0d'/>
<id>urn:sha1:14108b9131a47ff18a3c640f583eb2d625c75c0d</id>
<content type='text'>
Fix lock/unlock imbalance by unlocking *zhdr* before return.

Addresses Coverity ID 1452811 ("Missing unlock")

Link: http://lkml.kernel.org/r/20190826030634.GA4379@embeddedor
Fixes: d776aaa9895e ("mm/z3fold.c: fix race between migration and destruction")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Reviewed-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/z3fold.c: fix race between migration and destruction</title>
<updated>2019-08-25T02:48:42Z</updated>
<author>
<name>Henry Burns</name>
</author>
<published>2019-08-25T00:54:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d776aaa9895eb6eb770908e899cb7f5bd5025b3c'/>
<id>urn:sha1:d776aaa9895eb6eb770908e899cb7f5bd5025b3c</id>
<content type='text'>
In z3fold_destroy_pool() we call destroy_workqueue(&amp;pool-&gt;compact_wq).
However, we have no guarantee that migration isn't happening in the
background at that time.

Migration directly calls queue_work_on(pool-&gt;compact_wq), if destruction
wins that race we are using a destroyed workqueue.

Link: http://lkml.kernel.org/r/20190809213828.202833-1-henryburns@google.com
Signed-off-by: Henry Burns &lt;henryburns@google.com&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Jonathan Adams &lt;jwadams@google.com&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/z3fold.c: fix z3fold_destroy_pool() race condition</title>
<updated>2019-08-13T23:06:52Z</updated>
<author>
<name>Henry Burns</name>
</author>
<published>2019-08-13T22:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b997052bc3ac444a0bceab1093aff7ae71ed419e'/>
<id>urn:sha1:b997052bc3ac444a0bceab1093aff7ae71ed419e</id>
<content type='text'>
The constraint from the zpool use of z3fold_destroy_pool() is there are
no outstanding handles to memory (so no active allocations), but it is
possible for there to be outstanding work on either of the two wqs in
the pool.

Calling z3fold_deregister_migration() before the workqueues are drained
means that there can be allocated pages referencing a freed inode,
causing any thread in compaction to be able to trip over the bad pointer
in PageMovable().

Link: http://lkml.kernel.org/r/20190726224810.79660-2-henryburns@google.com
Fixes: 1f862989b04a ("mm/z3fold.c: support page migration")
Signed-off-by: Henry Burns &lt;henryburns@google.com&gt;
Reviewed-by: Shakeel Butt &lt;shakeelb@google.com&gt;
Reviewed-by: Jonathan Adams &lt;jwadams@google.com&gt;
Cc: Vitaly Vul &lt;vitaly.vul@sony.com&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/z3fold.c: fix z3fold_destroy_pool() ordering</title>
<updated>2019-08-13T23:06:52Z</updated>
<author>
<name>Henry Burns</name>
</author>
<published>2019-08-13T22:37:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6051d3bd3b91e96c59e62b8be2dba1cc2b19ee40'/>
<id>urn:sha1:6051d3bd3b91e96c59e62b8be2dba1cc2b19ee40</id>
<content type='text'>
The constraint from the zpool use of z3fold_destroy_pool() is there are
no outstanding handles to memory (so no active allocations), but it is
possible for there to be outstanding work on either of the two wqs in
the pool.

If there is work queued on pool-&gt;compact_workqueue when it is called,
z3fold_destroy_pool() will do:

   z3fold_destroy_pool()
     destroy_workqueue(pool-&gt;release_wq)
     destroy_workqueue(pool-&gt;compact_wq)
       drain_workqueue(pool-&gt;compact_wq)
         do_compact_page(zhdr)
           kref_put(&amp;zhdr-&gt;refcount)
             __release_z3fold_page(zhdr, ...)
               queue_work_on(pool-&gt;release_wq, &amp;pool-&gt;work) *BOOM*

So compact_wq needs to be destroyed before release_wq.

Link: http://lkml.kernel.org/r/20190726224810.79660-1-henryburns@google.com
Fixes: 5d03a6613957 ("mm/z3fold.c: use kref to prevent page free/compact race")
Signed-off-by: Henry Burns &lt;henryburns@google.com&gt;
Reviewed-by: Shakeel Butt &lt;shakeelb@google.com&gt;
Reviewed-by: Jonathan Adams &lt;jwadams@google.com&gt;
Cc: Vitaly Vul &lt;vitaly.vul@sony.com&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk
Cc: Henry Burns &lt;henrywolfeburns@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2019-07-19T17:42:02Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2019-07-19T17:42:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=933a90bf4f3505f8ec83bda21a3c7d70d7c2b426'/>
<id>urn:sha1:933a90bf4f3505f8ec83bda21a3c7d70d7c2b426</id>
<content type='text'>
Pull vfs mount updates from Al Viro:
 "The first part of mount updates.

  Convert filesystems to use the new mount API"

* 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits)
  mnt_init(): call shmem_init() unconditionally
  constify ksys_mount() string arguments
  don't bother with registering rootfs
  init_rootfs(): don't bother with init_ramfs_fs()
  vfs: Convert smackfs to use the new mount API
  vfs: Convert selinuxfs to use the new mount API
  vfs: Convert securityfs to use the new mount API
  vfs: Convert apparmorfs to use the new mount API
  vfs: Convert openpromfs to use the new mount API
  vfs: Convert xenfs to use the new mount API
  vfs: Convert gadgetfs to use the new mount API
  vfs: Convert oprofilefs to use the new mount API
  vfs: Convert ibmasmfs to use the new mount API
  vfs: Convert qib_fs/ipathfs to use the new mount API
  vfs: Convert efivarfs to use the new mount API
  vfs: Convert configfs to use the new mount API
  vfs: Convert binfmt_misc to use the new mount API
  convenience helper: get_tree_single()
  convenience helper get_tree_nodev()
  vfs: Kill sget_userns()
  ...
</content>
</entry>
</feed>
