<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/include/linux, branch v4.8.6</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.8.6</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.8.6'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2016-10-31T11:02:16+00:00</updated>
<entry>
<title>libnvdimm: clear the internal poison_list when clearing badblocks</title>
<updated>2016-10-31T11:02:16+00:00</updated>
<author>
<name>Vishal Verma</name>
<email>vishal.l.verma@intel.com</email>
</author>
<published>2016-09-30T23:19:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=13c06fcc4a776dca0e23e15677d4884c9f4f40f9'/>
<id>urn:sha1:13c06fcc4a776dca0e23e15677d4884c9f4f40f9</id>
<content type='text'>
commit e046114af5fcafe8d6d3f0b6ccb99804bad34bfb upstream.

nvdimm_clear_poison cleared the user-visible badblocks, and sent
commands to the NVDIMM to clear the areas marked as 'poison', but it
neglected to clear the same areas from the internal poison_list which is
used to marshal ARS results before sorting them by namespace. As a
result, once on-demand ARS functionality was added:

37b137f nfit, libnvdimm: allow an ARS scrub to be triggered on demand

A scrub triggered from either sysfs or an MCE was found to be adding
stale entries that had been cleared from gendisk-&gt;badblocks, but were
still present in nvdimm_bus-&gt;poison_list. Additionally, the stale entries
could be triggered into producing stale disk-&gt;badblocks by simply disabling
and re-enabling the namespace or region.

This adds the missing step of clearing poison_list entries when clearing
poison, so that it is always in sync with badblocks.

Fixes: 37b137f ("nfit, libnvdimm: allow an ARS scrub to be triggered on demand")
Signed-off-by: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm/hugetlb: check for reserved hugepages during memory offline</title>
<updated>2016-10-31T11:02:11+00:00</updated>
<author>
<name>Gerald Schaefer</name>
<email>gerald.schaefer@de.ibm.com</email>
</author>
<published>2016-10-08T00:01:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=8f858254414942cff6fcdc6a91cfbb4b81dc9036'/>
<id>urn:sha1:8f858254414942cff6fcdc6a91cfbb4b81dc9036</id>
<content type='text'>
commit 082d5b6b60e9f25e1511557fcfcb21eedd267446 upstream.

In dissolve_free_huge_pages(), free hugepages will be dissolved without
making sure that there are enough of them left to satisfy hugepage
reservations.

Fix this by adding a return value to dissolve_free_huge_pages() and
checking h-&gt;free_huge_pages vs.  h-&gt;resv_huge_pages.  Note that this may
lead to the situation where dissolve_free_huge_page() returns an error
and all free hugepages that were dissolved before that error are lost,
while the memory block still cannot be set offline.

Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Link: http://lkml.kernel.org/r/20160926172811.94033-3-gerald.schaefer@de.ibm.com
Signed-off-by: Gerald Schaefer &lt;gerald.schaefer@de.ibm.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Cc: "Kirill A . Shutemov" &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Mike Kravetz &lt;mike.kravetz@oracle.com&gt;
Cc: "Aneesh Kumar K . V" &lt;aneesh.kumar@linux.vnet.ibm.com&gt;
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Rui Teng &lt;rui.teng@linux.vnet.ibm.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>posix_acl: Clear SGID bit when setting file permissions</title>
<updated>2016-10-31T11:02:08+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2016-09-19T15:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=ea288a690cc4e53a528ae6a1d37cd6e14320ed27'/>
<id>urn:sha1:ea288a690cc4e53a528ae6a1d37cd6e14320ed27</id>
<content type='text'>
commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>irqchip/gic-v3-its: Fix entry size mask for GITS_BASER</title>
<updated>2016-10-28T07:45:28+00:00</updated>
<author>
<name>Vladimir Murzin</name>
<email>vladimir.murzin@arm.com</email>
</author>
<published>2016-10-17T15:00:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=ee13e8a1ae2f2ed434bdcc24011bd722fb3b32d9'/>
<id>urn:sha1:ee13e8a1ae2f2ed434bdcc24011bd722fb3b32d9</id>
<content type='text'>
commit 9224eb77e63f70f16c0b6b7a20ca7d395f3bc077 upstream.

Entry Size in GITS_BASER&lt;n&gt; occupies 5 bits [52:48], but we mask out 8
bits.

Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
Signed-off-by: Vladimir Murzin &lt;vladimir.murzin@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: fix overflow in cpufreq_table_find_index_dl()</title>
<updated>2016-10-28T07:45:19+00:00</updated>
<author>
<name>Sergey Senozhatsky</name>
<email>sergey.senozhatsky@gmail.com</email>
</author>
<published>2016-10-17T15:41:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=73fe3f93108a39d2b353569fbfc96cfbf2b2657a'/>
<id>urn:sha1:73fe3f93108a39d2b353569fbfc96cfbf2b2657a</id>
<content type='text'>
commit c6fe46a79ecd79606bb96fada4515f6b23f87b62 upstream.

'best' is always less or equals to 'pos', so `best - pos' returns
a negative value which is then getting casted to `unsigned int'
and passed to __cpufreq_driver_target()-&gt;acpi_cpufreq_target()
for policy-&gt;freq_table selection. This results in

 BUG: unable to handle kernel paging request at ffff881019b469f8
 IP: [&lt;ffffffffa00356c1&gt;] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
 PGD 267f067
 PUD 0

 Oops: 0000 [#1] PREEMPT SMP
 CPU: 6 PID: 70 Comm: kworker/6:1 Not tainted 4.9.0-rc1-next-20161017-dbg-dirty
 Workqueue: events dbs_work_handler
 task: ffff88041b808000 task.stack: ffff88041b810000
 RIP: 0010:[&lt;ffffffffa00356c1&gt;]  [&lt;ffffffffa00356c1&gt;] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
 RSP: 0018:ffff88041b813c60  EFLAGS: 00010282
 RAX: ffff880419b46a00 RBX: ffff88041b848400 RCX: ffff880419b20f80
 RDX: 00000000001dff38 RSI: 00000000ffffffff RDI: ffff88041b848400
 RBP: ffff88041b813cb0 R08: 0000000000000006 R09: 0000000000000040
 R10: ffffffff8207f9e0 R11: ffffffff8173595b R12: 0000000000000000
 R13: ffff88041f1dff38 R14: 0000000000262900 R15: 0000000bfffffff4
 FS:  0000000000000000(0000) GS:ffff88041f000000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffff881019b469f8 CR3: 000000041a2d3000 CR4: 00000000001406e0
 Stack:
  ffff88041b813cb0 ffffffff813347f9 ffff88041b813ca0 ffffffff81334663
  ffff88041f1d4bc0 ffff88041b848400 0000000000000000 0000000000000000
  0000000000262900 0000000000000000 ffff88041b813d00 ffffffff813355dc
 Call Trace:
  [&lt;ffffffff813347f9&gt;] ? cpufreq_freq_transition_begin+0xf1/0xfc
  [&lt;ffffffff81334663&gt;] ? get_cpu_idle_time+0x97/0xa6
  [&lt;ffffffff813355dc&gt;] __cpufreq_driver_target+0x3b6/0x44e
  [&lt;ffffffff81336ca3&gt;] cs_dbs_timer+0x11a/0x135
  [&lt;ffffffff81336fda&gt;] dbs_work_handler+0x39/0x62
  [&lt;ffffffff81057823&gt;] process_one_work+0x280/0x4a5
  [&lt;ffffffff81058719&gt;] worker_thread+0x24f/0x397
  [&lt;ffffffff810584ca&gt;] ? rescuer_thread+0x30b/0x30b
  [&lt;ffffffff81418380&gt;] ? nl80211_get_key+0x29/0x36a
  [&lt;ffffffff8105d2b7&gt;] kthread+0xfc/0x104
  [&lt;ffffffff8107ceea&gt;] ? put_lock_stats.isra.9+0xe/0x20
  [&lt;ffffffff8105d1bb&gt;] ? kthread_create_on_node+0x3f/0x3f
  [&lt;ffffffff814b2092&gt;] ret_from_fork+0x22/0x30
 Code: 56 4d 6b ff 0c 41 55 41 54 53 48 83 ec 28 48 8b 15 ad 1e 00 00 44 8b 41
 08 48 8b 87 c8 00 00 00 49 89 d5 4e 03 2c c5 80 b2 78 81 &lt;46&gt; 8b 74 38 04 45
 3b 75 00 75 11 31 c0 83 39 00 0f 84 1c 01 00
 RIP  [&lt;ffffffffa00356c1&gt;] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
  RSP &lt;ffff88041b813c60&gt;
 CR2: ffff881019b469f8
 ---[ end trace 16d9fc7a17897d37 ]---

[ rjw: In some cases this bug may also cause incorrect frequencies to
  be selected by cpufreq governors. ]

Fixes: 899bb6642f2a (cpufreq: skip invalid entries when searching the frequency)
Link: http://marc.info/?l=linux-kernel&amp;m=147672030714331&amp;w=2
Reported-and-tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Reported-and-tested-by: Jörg Otte &lt;jrg.otte@gmail.com&gt;
Signed-off-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: skip invalid entries when searching the frequency</title>
<updated>2016-10-28T07:45:19+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2016-10-12T03:15:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=80143d9f6e5c62211b27af2bb703f9a2b40b70c3'/>
<id>urn:sha1:80143d9f6e5c62211b27af2bb703f9a2b40b70c3</id>
<content type='text'>
commit 899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 upstream.

Skip invalid entries when searching the frequency. This fixes cpufreq
at least on loongson2 MIPS board.

Fixes: da0c6dc00c69 (cpufreq: Handle sorted frequency tables more efficiently)
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>PM / devfreq: event: remove duplicate devfreq_event_get_drvdata()</title>
<updated>2016-10-28T07:45:18+00:00</updated>
<author>
<name>Lin Huang</name>
<email>hl@rock-chips.com</email>
</author>
<published>2016-08-04T10:32:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=cf2bf9597b5c445a200a0a7e01af5e05479f218d'/>
<id>urn:sha1:cf2bf9597b5c445a200a0a7e01af5e05479f218d</id>
<content type='text'>
commit c8a9a6daccad495c48d5435d3487956ce01bc6a1 upstream.

there define two devfreq_event_get_drvdata() function in devfreq-event.h
when disable CONFIG_PM_DEVFREQ_EVENT, it will lead to build fail. So
remove devfreq_event_get_drvdata() function.

Fixes: f262f28c1470 ("PM / devfreq: event: Add devfreq_event class")
Signed-off-by: Lin Huang &lt;hl@rock-chips.com&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: MyungJoo Ham &lt;myungjoo.ham@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vfs: move permission checking into notify_change() for utimes(NULL)</title>
<updated>2016-10-22T10:40:26+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2016-09-16T10:44:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=7bf998961fe67e37e044d5fb950a6a9e71dbb4d7'/>
<id>urn:sha1:7bf998961fe67e37e044d5fb950a6a9e71dbb4d7</id>
<content type='text'>
commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b upstream.

This fixes a bug where the permission was not properly checked in
overlayfs.  The testcase is ltp/utimensat01.

It is also cleaner and safer to do the permission checking in the vfs
helper instead of the caller.

This patch introduces an additional ia_valid flag ATTR_TOUCH (since
touch(1) is the most obvious user of utimes(NULL)) that is passed into
notify_change whenever the conditions for this special permission checking
mode are met.

Reported-by: Aihua Zhang &lt;zhangaihua1@huawei.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Tested-by: Aihua Zhang &lt;zhangaihua1@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipc/sem.c: fix complex_count vs. simple op race</title>
<updated>2016-10-22T10:40:24+00:00</updated>
<author>
<name>Manfred Spraul</name>
<email>manfred@colorfullife.com</email>
</author>
<published>2016-10-11T20:54:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=a9d465bedb6a1bb727fa3c7c1af41b517935a7e4'/>
<id>urn:sha1:a9d465bedb6a1bb727fa3c7c1af41b517935a7e4</id>
<content type='text'>
commit 5864a2fd3088db73d47942370d0f7210a807b9bc upstream.

Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a
race:

sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in parallel:
 - a non-simple operations is ongoing (sma-&gt;sem_perm.lock held)
 - a complex operation is sleeping (sma-&gt;complex_count != 0)

As both facts are stored independently, a thread can bypass the current
checks by sleeping in the right positions.  See below for more details
(or kernel bugzilla 105651).

The patch fixes that by creating one variable (complex_mode)
that tracks both reasons why parallel operations are not possible.

The patch also updates stale documentation regarding the locking.

With regards to stable kernels:
The patch is required for all kernels that include the
commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") (3.10?)

The alternative is to revert the patch that introduced the race.

The patch is safe for backporting, i.e. it makes no assumptions
about memory barriers in spin_unlock_wait().

Background:
Here is the race of the current implementation:

Thread A: (simple op)
- does the first "sma-&gt;complex_count == 0" test

Thread B: (complex op)
- does sem_lock(): This includes an array scan. But the scan can't
  find Thread A, because Thread A does not own sem-&gt;lock yet.
- the thread does the operation, increases complex_count,
  drops sem_lock, sleeps

Thread A:
- spin_lock(&amp;sem-&gt;lock), spin_is_locked(sma-&gt;sem_perm.lock)
- sleeps before the complex_count test

Thread C: (complex op)
- does sem_lock (no array scan, complex_count==1)
- wakes up Thread B.
- decrements complex_count

Thread A:
- does the complex_count test

Bug:
Now both thread A and thread C operate on the same array, without
any synchronization.

Fixes: 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()")
Link: http://lkml.kernel.org/r/1469123695-5661-1-git-send-email-manfred@colorfullife.com
Reported-by: &lt;felixh@informatik.uni-bremen.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Davidlohr Bueso &lt;dave@stgolabs.net&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: &lt;1vier1@web.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: filemap: don't plant shadow entries without radix tree node</title>
<updated>2016-10-22T10:40:23+00:00</updated>
<author>
<name>Johannes Weiner</name>
<email>hannes@cmpxchg.org</email>
</author>
<published>2016-10-04T20:02:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=7d5d3b13596da50b6fa835997823f419f9c818c4'/>
<id>urn:sha1:7d5d3b13596da50b6fa835997823f419f9c818c4</id>
<content type='text'>
commit d3798ae8c6f3767c726403c2ca6ecc317752c9dd upstream.

When the underflow checks were added to workingset_node_shadow_dec(),
they triggered immediately:

  kernel BUG at ./include/linux/swap.h:276!
  invalid opcode: 0000 [#1] SMP
  Modules linked in: isofs usb_storage fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6
   soundcore wmi acpi_als pinctrl_sunrisepoint kfifo_buf tpm_tis industrialio acpi_pad pinctrl_intel tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_crypt
  CPU: 0 PID: 20929 Comm: blkid Not tainted 4.8.0-rc8-00087-gbe67d60ba944 #1
  Hardware name: System manufacturer System Product Name/Z170-K, BIOS 1803 05/06/2016
  task: ffff8faa93ecd940 task.stack: ffff8faa7f478000
  RIP: page_cache_tree_insert+0xf1/0x100
  Call Trace:
    __add_to_page_cache_locked+0x12e/0x270
    add_to_page_cache_lru+0x4e/0xe0
    mpage_readpages+0x112/0x1d0
    blkdev_readpages+0x1d/0x20
    __do_page_cache_readahead+0x1ad/0x290
    force_page_cache_readahead+0xaa/0x100
    page_cache_sync_readahead+0x3f/0x50
    generic_file_read_iter+0x5af/0x740
    blkdev_read_iter+0x35/0x40
    __vfs_read+0xe1/0x130
    vfs_read+0x96/0x130
    SyS_read+0x55/0xc0
    entry_SYSCALL_64_fastpath+0x13/0x8f
  Code: 03 00 48 8b 5d d8 65 48 33 1c 25 28 00 00 00 44 89 e8 75 19 48 83 c4 18 5b 41 5c 41 5d 41 5e 5d c3 0f 0b 41 bd ef ff ff ff eb d7 &lt;0f&gt; 0b e8 88 68 ef ff 0f 1f 84 00
  RIP  page_cache_tree_insert+0xf1/0x100

This is a long-standing bug in the way shadow entries are accounted in
the radix tree nodes. The shrinker needs to know when radix tree nodes
contain only shadow entries, no pages, so node-&gt;count is split in half
to count shadows in the upper bits and pages in the lower bits.

Unfortunately, the radix tree implementation doesn't know of this and
assumes all entries are in node-&gt;count. When there is a shadow entry
directly in root-&gt;rnode and the tree is later extended, the radix tree
implementation will copy that entry into the new node and and bump its
node-&gt;count, i.e. increases the page count bits. Once the shadow gets
removed and we subtract from the upper counter, node-&gt;count underflows
and triggers the warning. Afterwards, without node-&gt;count reaching 0
again, the radix tree node is leaked.

Limit shadow entries to when we have actual radix tree nodes and can
count them properly. That means we lose the ability to detect refaults
from files that had only the first page faulted in at eviction time.

Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check")
Signed-off-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Reported-and-tested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
