<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/include/linux, branch v4.8.5</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.8.5</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.8.5'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2016-10-28T07:45:28+00:00</updated>
<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>
<entry>
<title>debugfs: introduce a public file_operations accessor</title>
<updated>2016-10-22T10:40:21+00:00</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@googlemail.com</email>
</author>
<published>2016-09-17T19:43:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=7c646634d46304baf6118bc43b4df5294c1c0f5d'/>
<id>urn:sha1:7c646634d46304baf6118bc43b4df5294c1c0f5d</id>
<content type='text'>
commit 86f0e06767dda7863d6d2a8f0b3b857e6ea876a0 upstream.

This patch introduces an accessor which can be used
by the users of debugfs (drivers, fs, ...) to get the
original file_operations struct. It also removes the
REAL_FOPS_DEREF macro in file.c and converts the code
to use the public version.

Previously, REAL_FOPS_DEREF was only available within
the file.c of debugfs. But having a public getter
available for debugfs users is important as some
drivers (carl9170 and b43) use the pointer of the
original file_operations in conjunction with container_of()
within their debugfs implementations.

Reviewed-by: Nicolai Stange &lt;nicstange@gmail.com&gt;
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: remove gup_flags FOLL_WRITE games from __get_user_pages()</title>
<updated>2016-10-20T08:03:30+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-10-13T20:07:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=89eeba1594ac641a30b91942961e80fae978f839'/>
<id>urn:sha1:89eeba1594ac641a30b91942961e80fae978f839</id>
<content type='text'>
commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.

This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better).  The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9.  Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.

Reported-and-tested-by: Phil "not Paul" Oester &lt;kernel@linuxace.com&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Reviewed-by: Michal Hocko &lt;mhocko@suse.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Nick Piggin &lt;npiggin@gmail.com&gt;
Cc: Greg Thelen &lt;gthelen@google.com&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>mfd: 88pm80x: Double shifting bug in suspend/resume</title>
<updated>2016-10-16T16:03:38+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-08-04T05:26:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=ceeddeea91552a88740212224df7f425a0e9f1f6'/>
<id>urn:sha1:ceeddeea91552a88740212224df7f425a0e9f1f6</id>
<content type='text'>
commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.

set_bit() and clear_bit() take the bit number so this code is really
doing "1 &lt;&lt; (1 &lt;&lt; irq)" which is a double shift bug.  It's done
consistently so it won't cause a problem unless "irq" is more than 4.

Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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