<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs, branch v4.10</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>vfs: fix uninitialized flags in splice_to_pipe()</title>
<updated>2017-02-16T17:09:02+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2017-02-16T16:49:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac'/>
<id>5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac</id>
<content type='text'>
Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the
unused part of the pipe ring buffer.  Previously splice_to_pipe() left
the flags value alone, which could result in incorrect behavior.

Uninitialized flags appears to have been there from the introduction of
the splice syscall.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.17+
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the
unused part of the pipe ring buffer.  Previously splice_to_pipe() left
the flags value alone, which could result in incorrect behavior.

Uninitialized flags appears to have been there from the introduction of
the splice syscall.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.17+
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fuse: fix uninitialized flags in pipe_buffer</title>
<updated>2017-02-16T14:08:20+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2017-02-16T14:08:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=84588a93d097bace24b9233930f82511d4f34210'/>
<id>84588a93d097bace24b9233930f82511d4f34210</id>
<content type='text'>
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Fixes: d82718e348fe ("fuse_dev_splice_read(): switch to add_to_pipe()")
Cc: &lt;stable@vger.kernel.org&gt; # 4.9+
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Fixes: d82718e348fe ("fuse_dev_splice_read(): switch to add_to_pipe()")
Cc: &lt;stable@vger.kernel.org&gt; # 4.9+
</pre>
</div>
</content>
</entry>
<entry>
<title>fuse: fix use after free issue in fuse_dev_do_read()</title>
<updated>2017-02-15T09:28:24+00:00</updated>
<author>
<name>Sahitya Tummala</name>
<email>stummala@codeaurora.org</email>
</author>
<published>2017-02-08T15:00:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6ba4d2722d06960102c981322035239cd66f7316'/>
<id>6ba4d2722d06960102c981322035239cd66f7316</id>
<content type='text'>
There is a potential race between fuse_dev_do_write()
and request_wait_answer() contexts as shown below:

TASK 1:
__fuse_request_send():
  |--spin_lock(&amp;fiq-&gt;waitq.lock);
  |--queue_request();
  |--spin_unlock(&amp;fiq-&gt;waitq.lock);
  |--request_wait_answer():
       |--if (test_bit(FR_SENT, &amp;req-&gt;flags))
       &lt;gets pre-empted after it is validated true&gt;
                                   TASK 2:
                                   fuse_dev_do_write():
                                     |--clears bit FR_SENT,
                                     |--request_end():
                                        |--sets bit FR_FINISHED
                                        |--spin_lock(&amp;fiq-&gt;waitq.lock);
                                        |--list_del_init(&amp;req-&gt;intr_entry);
                                        |--spin_unlock(&amp;fiq-&gt;waitq.lock);
                                        |--fuse_put_request();
       |--queue_interrupt();
       &lt;request gets queued to interrupts list&gt;
            |--wake_up_locked(&amp;fiq-&gt;waitq);
       |--wait_event_freezable();
       &lt;as FR_FINISHED is set, it returns and then
       the caller frees this request&gt;

Now, the next fuse_dev_do_read(), see interrupts list is not empty
and then calls fuse_read_interrupt() which tries to access the request
which is already free'd and gets the below crash:

[11432.401266] Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b6b
...
[11432.418518] Kernel BUG at ffffff80083720e0
[11432.456168] PC is at __list_del_entry+0x6c/0xc4
[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
...
[11432.679999] [&lt;ffffff80083720e0&gt;] __list_del_entry+0x6c/0xc4
[11432.687794] [&lt;ffffff80082c65e0&gt;] fuse_dev_do_read+0x1ac/0x474
[11432.693180] [&lt;ffffff80082c6b14&gt;] fuse_dev_read+0x6c/0x78
[11432.699082] [&lt;ffffff80081d5638&gt;] __vfs_read+0xc0/0xe8
[11432.704459] [&lt;ffffff80081d5efc&gt;] vfs_read+0x90/0x108
[11432.709406] [&lt;ffffff80081d67f0&gt;] SyS_read+0x58/0x94

As FR_FINISHED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().

Signed-off-by: Sahitya Tummala &lt;stummala@codeaurora.org&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Fixes: fd22d62ed0c3 ("fuse: no fc-&gt;lock for iqueue parts")
Cc: &lt;stable@vger.kernel.org&gt; # 4.2+
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is a potential race between fuse_dev_do_write()
and request_wait_answer() contexts as shown below:

TASK 1:
__fuse_request_send():
  |--spin_lock(&amp;fiq-&gt;waitq.lock);
  |--queue_request();
  |--spin_unlock(&amp;fiq-&gt;waitq.lock);
  |--request_wait_answer():
       |--if (test_bit(FR_SENT, &amp;req-&gt;flags))
       &lt;gets pre-empted after it is validated true&gt;
                                   TASK 2:
                                   fuse_dev_do_write():
                                     |--clears bit FR_SENT,
                                     |--request_end():
                                        |--sets bit FR_FINISHED
                                        |--spin_lock(&amp;fiq-&gt;waitq.lock);
                                        |--list_del_init(&amp;req-&gt;intr_entry);
                                        |--spin_unlock(&amp;fiq-&gt;waitq.lock);
                                        |--fuse_put_request();
       |--queue_interrupt();
       &lt;request gets queued to interrupts list&gt;
            |--wake_up_locked(&amp;fiq-&gt;waitq);
       |--wait_event_freezable();
       &lt;as FR_FINISHED is set, it returns and then
       the caller frees this request&gt;

Now, the next fuse_dev_do_read(), see interrupts list is not empty
and then calls fuse_read_interrupt() which tries to access the request
which is already free'd and gets the below crash:

[11432.401266] Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b6b
...
[11432.418518] Kernel BUG at ffffff80083720e0
[11432.456168] PC is at __list_del_entry+0x6c/0xc4
[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
...
[11432.679999] [&lt;ffffff80083720e0&gt;] __list_del_entry+0x6c/0xc4
[11432.687794] [&lt;ffffff80082c65e0&gt;] fuse_dev_do_read+0x1ac/0x474
[11432.693180] [&lt;ffffff80082c6b14&gt;] fuse_dev_read+0x6c/0x78
[11432.699082] [&lt;ffffff80081d5638&gt;] __vfs_read+0xc0/0xe8
[11432.704459] [&lt;ffffff80081d5efc&gt;] vfs_read+0x90/0x108
[11432.709406] [&lt;ffffff80081d67f0&gt;] SyS_read+0x58/0x94

As FR_FINISHED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().

Signed-off-by: Sahitya Tummala &lt;stummala@codeaurora.org&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Fixes: fd22d62ed0c3 ("fuse: no fc-&gt;lock for iqueue parts")
Cc: &lt;stable@vger.kernel.org&gt; # 4.2+
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs</title>
<updated>2017-02-11T17:15:58+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-02-11T17:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2b95550a4323e501e133dac1c9c9cad6ff17f4c1'/>
<id>2b95550a4323e501e133dac1c9c9cad6ff17f4c1</id>
<content type='text'>
Pull btrfs fixes from Chris Mason:
 "This has two last minute fixes. The highest priority here is a
  regression fix for the decompression code, but we also fixed up a
  problem with the 32-bit compat ioctls.

  The decompression bug could hand back the wrong data on big reads when
  zlib was used. I have a larger cleanup to make the math here less
  error prone, but at this stage in the release Omar's patch is the best
  choice"

* 'for-linus-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: fix btrfs_decompress_buf2page()
  btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull btrfs fixes from Chris Mason:
 "This has two last minute fixes. The highest priority here is a
  regression fix for the decompression code, but we also fixed up a
  problem with the 32-bit compat ioctls.

  The decompression bug could hand back the wrong data on big reads when
  zlib was used. I have a larger cleanup to make the math here less
  error prone, but at this stage in the release Omar's patch is the best
  choice"

* 'for-linus-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: fix btrfs_decompress_buf2page()
  btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: fix btrfs_decompress_buf2page()</title>
<updated>2017-02-11T03:11:03+00:00</updated>
<author>
<name>Omar Sandoval</name>
<email>osandov@fb.com</email>
</author>
<published>2017-02-10T23:03:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6e78b3f7a193546b1c00a6d084596e774f147169'/>
<id>6e78b3f7a193546b1c00a6d084596e774f147169</id>
<content type='text'>
If btrfs_decompress_buf2page() is handed a bio with its page in the
middle of the working buffer, then we adjust the offset into the working
buffer. After we copy into the bio, we advance the iterator by the
number of bytes we copied. Then, we have some logic to handle the case
of discontiguous pages and adjust the offset into the working buffer
again. However, if we didn't advance the bio to a new page, we may enter
this case in error, essentially repeating the adjustment that we already
made when we entered the function. The end result is bogus data in the
bio.

Previously, we only checked for this case when we advanced to a new
page, but the conversion to bio iterators changed that. This restores
the old, correct behavior.

A case I saw when testing with zlib was:

    buf_start = 42769
    total_out = 46865
    working_bytes = total_out - buf_start = 4096
    start_byte = 45056

The condition (total_out &gt; start_byte &amp;&amp; buf_start &lt; start_byte) is
true, so we adjust the offset:

    buf_offset = start_byte - buf_start = 2287
    working_bytes -= buf_offset = 1809
    current_buf_start = buf_start = 42769

Then, we copy

    bytes = min(bvec.bv_len, PAGE_SIZE - buf_offset, working_bytes) = 1809
    buf_offset += bytes = 4096
    working_bytes -= bytes = 0
    current_buf_start += bytes = 44578

After bio_advance(), we are still in the same page, so start_byte is the
same. Then, we check (total_out &gt; start_byte &amp;&amp; current_buf_start &lt; start_byte),
which is true! So, we adjust the values again:

    buf_offset = start_byte - buf_start = 2287
    working_bytes = total_out - start_byte = 1809
    current_buf_start = buf_start + buf_offset = 45056

But note that working_bytes was already zero before this, so we should
have stopped copying.

Fixes: 974b1adc3b10 ("btrfs: use bio iterators for the decompression handlers")
Reported-by: Pat Erley &lt;pat-lkml@erley.org&gt;
Reviewed-by: Chris Mason &lt;clm@fb.com&gt;
Signed-off-by: Omar Sandoval &lt;osandov@fb.com&gt;
Signed-off-by: Chris Mason &lt;clm@fb.com&gt;
Reviewed-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
Tested-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If btrfs_decompress_buf2page() is handed a bio with its page in the
middle of the working buffer, then we adjust the offset into the working
buffer. After we copy into the bio, we advance the iterator by the
number of bytes we copied. Then, we have some logic to handle the case
of discontiguous pages and adjust the offset into the working buffer
again. However, if we didn't advance the bio to a new page, we may enter
this case in error, essentially repeating the adjustment that we already
made when we entered the function. The end result is bogus data in the
bio.

Previously, we only checked for this case when we advanced to a new
page, but the conversion to bio iterators changed that. This restores
the old, correct behavior.

A case I saw when testing with zlib was:

    buf_start = 42769
    total_out = 46865
    working_bytes = total_out - buf_start = 4096
    start_byte = 45056

The condition (total_out &gt; start_byte &amp;&amp; buf_start &lt; start_byte) is
true, so we adjust the offset:

    buf_offset = start_byte - buf_start = 2287
    working_bytes -= buf_offset = 1809
    current_buf_start = buf_start = 42769

Then, we copy

    bytes = min(bvec.bv_len, PAGE_SIZE - buf_offset, working_bytes) = 1809
    buf_offset += bytes = 4096
    working_bytes -= bytes = 0
    current_buf_start += bytes = 44578

After bio_advance(), we are still in the same page, so start_byte is the
same. Then, we check (total_out &gt; start_byte &amp;&amp; current_buf_start &lt; start_byte),
which is true! So, we adjust the values again:

    buf_offset = start_byte - buf_start = 2287
    working_bytes = total_out - start_byte = 1809
    current_buf_start = buf_start + buf_offset = 45056

But note that working_bytes was already zero before this, so we should
have stopped copying.

Fixes: 974b1adc3b10 ("btrfs: use bio iterators for the decompression handlers")
Reported-by: Pat Erley &lt;pat-lkml@erley.org&gt;
Reviewed-by: Chris Mason &lt;clm@fb.com&gt;
Signed-off-by: Omar Sandoval &lt;osandov@fb.com&gt;
Signed-off-by: Chris Mason &lt;clm@fb.com&gt;
Reviewed-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
Tested-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'nfsd-4.10-3' of git://linux-nfs.org/~bfields/linux</title>
<updated>2017-02-10T22:23:45+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-02-10T22:23:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7fe654dca20892f37226c31bdd2d5b932f8d843a'/>
<id>7fe654dca20892f37226c31bdd2d5b932f8d843a</id>
<content type='text'>
Pull nfsd revert from Bruce Fields:
 "This patch turned out to have a couple problems. The problems are
  fixable, but at least one of the fixes is a little ugly. The original
  bug has always been there, so we can wait another week or two to get
  this right"

* tag 'nfsd-4.10-3' of git://linux-nfs.org/~bfields/linux:
  nfsd: Revert "nfsd: special case truncates some more"
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull nfsd revert from Bruce Fields:
 "This patch turned out to have a couple problems. The problems are
  fixable, but at least one of the fixes is a little ugly. The original
  bug has always been there, so we can wait another week or two to get
  this right"

* tag 'nfsd-4.10-3' of git://linux-nfs.org/~bfields/linux:
  nfsd: Revert "nfsd: special case truncates some more"
</pre>
</div>
</content>
</entry>
<entry>
<title>nfsd: Revert "nfsd: special case truncates some more"</title>
<updated>2017-02-10T01:49:20+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2017-02-09T19:20:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0839ffb83e44e5ff1843e932592525fc2bff23ff'/>
<id>0839ffb83e44e5ff1843e932592525fc2bff23ff</id>
<content type='text'>
This patch incorrectly attempted nested mnt_want_write, and incorrectly
disabled nfsd's owner override for truncate.  We'll fix those problems
and make another attempt soon, for the moment I think the safest is to
revert.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch incorrectly attempted nested mnt_want_write, and incorrectly
disabled nfsd's owner override for truncate.  We'll fix those problems
and make another attempt soon, for the moment I think the safest is to
revert.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pstore: don't OOPS when there are no ftrace zones</title>
<updated>2017-02-09T19:49:49+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2017-02-09T06:44:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8672aed7bd865774257efd40929702759a869329'/>
<id>8672aed7bd865774257efd40929702759a869329</id>
<content type='text'>
We'll OOPS in ramoops_get_next_prz() if the platform didn't ask for any
ftrace zones (i.e., cxt-&gt;fprzs will be NULL). Let's just skip this
entire FTRACE section if there's no 'fprzs'.

Regression seen on a coreboot/depthcharge-based Chromebook.

Fixes: 2fbea82bbb89 ("pstore: Merge per-CPU ftrace records into one")
Cc: Joel Fernandes &lt;joelaf@google.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We'll OOPS in ramoops_get_next_prz() if the platform didn't ask for any
ftrace zones (i.e., cxt-&gt;fprzs will be NULL). Let's just skip this
entire FTRACE section if there's no 'fprzs'.

Regression seen on a coreboot/depthcharge-based Chromebook.

Fixes: 2fbea82bbb89 ("pstore: Merge per-CPU ftrace records into one")
Cc: Joel Fernandes &lt;joelaf@google.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls</title>
<updated>2017-02-08T16:47:30+00:00</updated>
<author>
<name>Jeff Mahoney</name>
<email>jeffm@suse.com</email>
</author>
<published>2017-02-07T00:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2a362249187a8d0f6d942d6e1d763d150a296f47'/>
<id>2a362249187a8d0f6d942d6e1d763d150a296f47</id>
<content type='text'>
Commit 4c63c2454ef incorrectly assumed that returning -ENOIOCTLCMD would
cause the native ioctl to be called.  The -&gt;compat_ioctl callback is
expected to handle all ioctls, not just compat variants.  As a result,
when using 32-bit userspace on 64-bit kernels, everything except those
three ioctls would return -ENOTTY.

Fixes: 4c63c2454ef ("btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl")
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 4c63c2454ef incorrectly assumed that returning -ENOIOCTLCMD would
cause the native ioctl to be called.  The -&gt;compat_ioctl callback is
expected to handle all ioctls, not just compat variants.  As a result,
when using 32-bit userspace on 64-bit kernels, everything except those
three ioctls would return -ENOTTY.

Fixes: 4c63c2454ef ("btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl")
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm: fix KPF_SWAPCACHE in /proc/kpageflags</title>
<updated>2017-02-07T20:08:32+00:00</updated>
<author>
<name>Hugh Dickins</name>
<email>hughd@google.com</email>
</author>
<published>2017-02-07T19:11:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b6789123bccba8b5feb9901ed2e8c3c39181979d'/>
<id>b6789123bccba8b5feb9901ed2e8c3c39181979d</id>
<content type='text'>
Commit 6326fec1122c ("mm: Use owner_priv bit for PageSwapCache, valid
when PageSwapBacked") aliased PG_swapcache to PG_owner_priv_1 (and
depending on PageSwapBacked being true).

As a result, the KPF_SWAPCACHE bit in '/proc/kpageflags' should now be
synthesized, instead of being shown on unrelated pages which just happen
to have PG_owner_priv_1 set.

Signed-off-by: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: Wu Fengguang &lt;fengguang.wu@intel.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>
Commit 6326fec1122c ("mm: Use owner_priv bit for PageSwapCache, valid
when PageSwapBacked") aliased PG_swapcache to PG_owner_priv_1 (and
depending on PageSwapBacked being true).

As a result, the KPF_SWAPCACHE bit in '/proc/kpageflags' should now be
synthesized, instead of being shown on unrelated pages which just happen
to have PG_owner_priv_1 set.

Signed-off-by: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
