4.14.37-stable review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 145/183 PM / domains: Fix up domain-idle-states OF parsing
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <[email protected]>
[ Upstream commit a3381e3a65cbaf612c8f584906c4dba27e84267c ]
Commit b539cc82d493 (PM / Domains: Ignore domain-idle-states that are not compatible), made it possible to ignore non-compatible domain-idle-states OF nodes. However, in case that happens while doing the OF parsing, the number of elements in the allocated array would exceed the numbers actually needed, thus wasting memory.
Fix this by pre-iterating the genpd OF node and counting the number of compatible domain-idle-states nodes, before doing the allocation. While doing this, it makes sense to rework the code a bit to avoid open coding, of parts responsible for the OF node iteration.
Let's also take the opportunity to clarify the function header for of_genpd_parse_idle_states(), about what is being returned in case of errors.
--- drivers/base/power/domain.c | 76 ++++++++++++++++++++++++++------------------ 1 file changed, 45 insertions(+), 31 deletions(-)
drivers/base/power/domain.c +45 -31
@@ -2206,6 +2206,38 @@ static int genpd_parse_state(struct genpreturn 0 ; } +static int genpd_iterate_idle_states (struct device_node *dn, +struct genpd_power_state *states) +{ +int ret; +struct of_phandle_iterator it; +struct device_node *np; +int i =0 ; + + ret =of_count_phandle_with_args (dn,"domain-idle-states" ,NULL ); +if (ret <=0 ) +return ret; + +/* Loop over the phandles until all the requested entry is found */ +of_for_each_phandle (&it, ret, dn,"domain-idle-states" ,NULL ,0 ) { + np = it.node; +if (!of_match_node (idle_state_match, np)) +continue ; +if (states) { + ret =genpd_parse_state (&states[i], np); +if (ret) { +pr_err ("Parsing idle state node %pOF failed with err %d\n" , + np, ret); +of_node_put (np); +return ret; + } + } + i++; + } + +return i; +} +/** * of_genpd_parse_idle_states: Return array of idle states for the genpd. *
@@ -2215,49 +2247,31 @@ static int genpd_parse_state(struct genp* * Returns the device states parsed from the OF node. The memory for the states * is allocated by this function and is the responsibility of the caller to -* free the memory after use. +* free the memory after use. If no domain idle states is found it returns +* -EINVAL and in case of errors, a negative error code. */ int of_genpd_parse_idle_states (struct device_node *dn,struct genpd_power_state **states,int *n) {struct genpd_power_state *st; -struct device_node *np; -int i =0 ; -int err, ret; -int count; -struct of_phandle_iterator it; -const struct of_device_id *match_id; +int ret; - count =of_count_phandle_with_args (dn,"domain-idle-states" ,NULL ); -if (count <=0 ) -return -EINVAL ; + ret =genpd_iterate_idle_states (dn,NULL ); +if (ret <=0 ) +return ret <0 ? ret : -EINVAL ; - st =kcalloc (count,sizeof (*st),GFP_KERNEL ); + st =kcalloc (ret,sizeof (*st),GFP_KERNEL );if (!st)return -ENOMEM ; -/* Loop over the phandles until all the requested entry is found */ -of_for_each_phandle (&it, err, dn,"domain-idle-states" ,NULL ,0 ) { - np = it.node; - match_id =of_match_node (idle_state_match, np); -if (!match_id) -continue ; - ret =genpd_parse_state (&st[i++], np); -if (ret) { -pr_err - ("Parsing idle state node %pOF failed with err %d\n" , - np, ret); -of_node_put (np); -kfree (st); -return ret; - } + ret =genpd_iterate_idle_states (dn, st); +if (ret <=0 ) { +kfree (st); +return ret <0 ? ret : -EINVAL ; } - *n = i; -if (!i) -kfree (st); -else - *states = st; + *states = st; + *n = ret;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 146/183 cifs: silence compiler warnings showing up with gcc-8.0.0
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit ade7db991b47ab3016a414468164f4966bd08202 ]
This bug was fixed before, but came up again with the latest compiler in another function:
fs/cifs/cifssmb.c: In function 'CIFSSMBSetEA':fs/cifs/cifssmb.c:6362:3: error: 'strncpy' offset 8 is out of the bounds [0, 4] [-Werror=array-bounds]
strncpy(parm_data->list[0].name, ea_name, name_len);
Let's apply the same fix that was used for the other instances.
--- fs/cifs/cifssmb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
fs/cifs/cifssmb.c +1 -3
@@ -6331,9 +6331,7 @@ SetEARetry: pSMB->InformationLevel =cpu_to_le16 (SMB_SET_FILE_EA ); - parm_data = - (struct fealist *) (((char *) &pSMB->hdr.Protocol) + - offset); + parm_data = (void *)pSMB + offsetof(struct smb_hdr , Protocol) + offset; pSMB->ParameterOffset =cpu_to_le16 (param_offset); pSMB->DataOffset =cpu_to_le16 (offset); pSMB->SetupCount =1 ;
Greg Kroah-Hartman
maintainerPATCH 147/183 bcache: properly set task state in bch_writeback_thread()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Coly Li <[email protected]>
[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]
Kernel thread routine bch_writeback_thread() has the following code block,
447 down_write(&dc->writeback_lock);
448~450 if (check conditions) {
451 up_write(&dc->writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }
If condition check is true, its task state is set to TASK_INTERRUPTIBLE and call schedule() to wait for others to wake up it.
There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
another process changes the condition and call wake_up_process(dc-> writeback_thread), then at line 452 task state is set back to TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and call do_exit(). It is not good to enter do_exit() with task state TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a warning message is reported by __might_sleep(): "WARNING: do not call blocking ops when !TASK_RUNNING; state=1 set at [xxxx]".
For the first issue, task state should be set before condition checks. Ineed because dc->writeback_lock is required when modifying all the conditions, calling set_current_state() inside code block where dc-> writeback_lock is hold is safe. But this is quite implicit, so I still move set_current_state() before all the condition checks.
For the second issue, frankley speaking it does not hurt when kernel thread exits with TASK_INTERRUPTIBLE state, but this warning message scares users, makes them feel there might be something risky with bcache and hurt their data. Setting task state to TASK_RUNNING before returning fixes this problem.
In alloc.c:allocator_wait(), there is also a similar issue, and is also fixed in this patch.
Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.
--- drivers/md/bcache/alloc.c | 4 +++- drivers/md/bcache/writeback.c | 7 +++++-- 2 files changed, 8 insertions(+), 3 deletions(-)
drivers/md/bcache/alloc.c +3 -1
@@ -287,8 +287,10 @@ do { \break ; \ \mutex_unlock (&(ca)->set->bucket_lock); \ -if (kthread_should_stop ()) \ +if (kthread_should_stop ()) { \ +set_current_state (TASK_RUNNING ); \return 0 ; \ + } \ \schedule (); \mutex_lock (&(ca)->set->bucket_lock); \
drivers/md/bcache/writeback.c +5 -2
@@ -420,18 +420,21 @@ static int bch_writeback_thread(void *arwhile (!kthread_should_stop ()) {down_write (&dc->writeback_lock); +set_current_state (TASK_INTERRUPTIBLE );if (!atomic_read (&dc->has_dirty) || (!test_bit (BCACHE_DEV_DETACHING , &dc->disk.flags) && !dc->writeback_running)) {up_write (&dc->writeback_lock); -set_current_state (TASK_INTERRUPTIBLE ); -if (kthread_should_stop ()) +if (kthread_should_stop ()) { +set_current_state (TASK_RUNNING );return 0 ; + }schedule ();continue ; } +set_current_state (TASK_RUNNING ); searched_full_index =refill_dirty (dc);
Greg Kroah-Hartman
maintainerPATCH 148/183 bcache: fix for allocator and register thread race
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tang Junhui <[email protected]>
[ Upstream commit 682811b3ce1a5a4e20d700939a9042f01dbc66c4 ]
After long time running of random small IO writing, I reboot the machine, and after the machine power on, I found bcache got stuck, the stack is:
[root@ceph153 ~]# cat /proc/2510/task/*/stack
[<ffffffffa06b2455>] closure_sync+0x25/0x90 [bcache] [<ffffffffa06b6be8>] bch_journal+0x118/0x2b0 [bcache] [<ffffffffa06b6dc7>] bch_journal_meta+0x47/0x70 [bcache] [<ffffffffa06be8f7>] bch_prio_write+0x237/0x340 [bcache] [<ffffffffa06a8018>] bch_allocator_thread+0x3c8/0x3d0 [bcache] [<ffffffff810a631f>] kthread+0xcf/0xe0 [<ffffffff8164c318>] ret_from_fork+0x58/0x90 [<ffffffffffffffff>] 0xffffffffffffffff [root@ceph153 ~]# cat /proc/2038/task/*/stack [<ffffffffa06b1abd>] __bch_btree_map_nodes+0x12d/0x150 [bcache] [<ffffffffa06b1bd1>] bch_btree_insert+0xf1/0x170 [bcache] [<ffffffffa06b637f>] bch_journal_replay+0x13f/0x230 [bcache] [<ffffffffa06c75fe>] run_cache_set+0x79a/0x7c2 [bcache] [<ffffffffa06c0cf8>] register_bcache+0xd48/0x1310 [bcache] [<ffffffff812f702f>] kobj_attr_store+0xf/0x20 [<ffffffff8125b216>] sysfs_write_file+0xc6/0x140 [<ffffffff811dfbfd>] vfs_write+0xbd/0x1e0 [<ffffffff811e069f>] SyS_write+0x7f/0xe0 [<ffffffff8164c3c9>] system_call_fastpath+0x16/0x1
The stack shows the register thread and allocator thread were getting stuck when registering cache device.
I reboot the machine several times, the issue always exsit in this machine.
I debug the code, and found the call trace as bellow:register_bcache()
==>run_cache_set()
==>bch_journal_replay()
==>bch_btree_insert()
==>__bch_btree_map_nodes()
==>btree_insert_fn()
==>btree_split() //node need split
==>btree_check_reserve()In btree_check_reserve(), It will check if there is enough buckets of RESERVE_BTREE type, since allocator thread did not work yet, so no buckets of RESERVE_BTREE type allocated, so the register thread waits on c->btree_cache_wait, and goes to sleep.
Then the allocator thread initialized, the call trace is bellow:bch_allocator_thread()
==>bch_prio_write()
==>bch_journal_meta()
==>bch_journal()
==>journal_wait_for_write()In journal_wait_for_write(), It will check if journal is full by journal_full(), but the long time random small IO writing causes the exhaustion of journal buckets(journal.blocks_free=0), In order to release the journal buckets,
the allocator calls btree_flush_write() to flush keys to btree nodes, and waits on c->journal.wait until btree nodes writing over or there has already some journal buckets space, then the allocator thread goes to sleep. but in btree_flush_write(), since bch_journal_replay() is not finished, so no btree nodes have journal (condition "if (btree_current_write(b)->journal)" never satisfied), so we got no btree node to flush, no journal bucket released, and allocator sleep all the times.
Through the above analysis, we can see that:
1) Register thread wait for allocator thread to allocate buckets of RESERVE_BTREE type;
2) Alloctor thread wait for register thread to replay journal, so it can flush btree nodes and get journal bucket.
then they are all got stuck by waiting for each other.
Hua Rui provided a patch for me, by allocating some buckets of RESERVE_BTREE type in advance, so the register thread can get bucket when btree node splitting and no need to waiting for the allocator thread. I tested it, it has effect, and register thread run a step forward, but finally are still got stuck, the reason is only 8 bucket of RESERVE_BTREE type were allocated, and in bch_journal_replay(), after 2 btree nodes splitting, only 4 bucket of RESERVE_BTREE type left, then btree_check_reserve() is not satisfied anymore, so it goes to sleep again, and in the same time, alloctor thread did not flush enough btree nodes to release a journal bucket, so they all got stuck again.
So we need to allocate more buckets of RESERVE_BTREE type in advance, but how much is enough? By experience and test, I think it should be as much as journal buckets. Then I modify the code as this patch, and test in the machine, and it works.
This patch modified base on Hua Rui’s patch, and allocate more buckets of RESERVE_BTREE type in advance to avoid register thread and allocate thread going to wait for each other.
[patch v2] ca->sb.njournal_buckets would be 0 in the first time after cache creation, and no journal exists, so just 8 btree buckets is OK.
--- drivers/md/bcache/btree.c | 9 ++++++--- drivers/md/bcache/super.c | 13 ++++++++++++- 2 files changed, 18 insertions(+), 4 deletions(-)
drivers/md/bcache/btree.c +6 -3
@@ -1868,14 +1868,17 @@ void bch_initial_gc_finish(struct cache_*/ for_each_cache (ca, c, i) {for_each_bucket (b, ca) { -if (fifo_full (&ca->free[RESERVE_PRIO ])) +if (fifo_full (&ca->free[RESERVE_PRIO ]) && +fifo_full (&ca->free[RESERVE_BTREE ]))break ;if (bch_can_invalidate_bucket (ca, b) && !GC_MARK (b)) {__bch_invalidate_one_bucket (ca, b); -fifo_push (&ca->free[RESERVE_PRIO ], - b - ca->buckets); +if (!fifo_push (&ca->free[RESERVE_PRIO ], + b - ca->buckets)) +fifo_push (&ca->free[RESERVE_BTREE ], + b - ca->buckets); } } }
drivers/md/bcache/super.c +12 -1
@@ -1829,6 +1829,7 @@ void bch_cache_release(struct kobject *kstatic int cache_alloc (struct cache *ca) {size_t free; +size_t btree_buckets;struct bucket *b;__module_get (THIS_MODULE );
@@ -1836,9 +1837,19 @@ static int cache_alloc(struct cache *ca)bio_init (&ca->journal.bio, ca->journal.bio.bi_inline_vecs,8 ); +/* +* when ca->sb.njournal_buckets is not zero, journal exists, +* and in bch_journal_replay(), tree node may split, +* so bucket of RESERVE_BTREE type is needed, +* the worst situation is all journal buckets are valid journal, +* and all the keys need to replay, +* so the number of RESERVE_BTREE type buckets should be as much +* as journal buckets +*/ + btree_buckets = ca->sb.njournal_buckets ?:8 ; free =roundup_pow_of_two (ca->sb.nbuckets) >>10 ; - if (!init_fifo(&ca->free[RESERVE_BTREE], 8, GFP_KERNEL) || + if (!init_fifo(&ca->free[RESERVE_BTREE], btree_buckets, GFP_KERNEL) || !init_fifo_exact(&ca->free[RESERVE_PRIO], prio_buckets(ca), GFP_KERNEL) || !init_fifo(&ca->free[RESERVE_MOVINGGC], free, GFP_KERNEL) || !init_fifo(&ca->free[RESERVE_NONE], free, GFP_KERNEL) ||
Greg Kroah-Hartman
maintainerPATCH 149/183 bcache: fix for data collapse after re-attaching an attached device
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tang Junhui <[email protected]>
[ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]
back-end device sdm has already attached a cache_set with ID f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with another cache set, and it returns with an error:
[root]# cd /sys/block/sdm/bcache
[root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach -bash: echo: write error: Invalid argument
After that, execute a command to modify the label of bcache device:
[root]# echo data_disk1 > label
Then we reboot the system, when the system power on, the back-end device can not attach to cache_set, a messages show in the log:
Feb 5 12:05:52 ceph152 kernel: [922385.508498] bcache:
bch_cached_dev_attach() couldn't find uuid for sdm in set
In sysfs_attach(), dc->sb.set_uuid was assigned to the value which input through sysfs, no matter whether it is success or not in bch_cached_dev_attach(). For example, If the back-end device has already attached to an cache set, bch_cached_dev_attach() would fail, but dc->sb.set_uuid was changed. Then modify the label of bcache device, it will call bch_write_bdev_super(), which would write the dc->sb.set_uuid to the super block, so we record a wrong cache set ID in the super block, after the system reboot, the cache set couldn't find the uuid of the back-end device, so the bcache device couldn't exist and use any more.
In this patch, we don't assigned cache set ID to dc->sb.set_uuid in sysfs_attach() directly, but input it into bch_cached_dev_attach(), and assigned dc->sb.set_uuid to the cache set ID after the back-end device attached to the cache set successful.
--- drivers/md/bcache/bcache.h | 2 +- drivers/md/bcache/super.c | 10 ++++++---- drivers/md/bcache/sysfs.c | 6 ++++-- 3 files changed, 11 insertions(+), 7 deletions(-)
drivers/md/bcache/bcache.h +1 -1
@@ -906,7 +906,7 @@ void bcache_write_super(struct cache_setint bch_flash_dev_create (struct cache_set *c,uint64_t size); -int bch_cached_dev_attach (struct cached_dev *,struct cache_set *); +int bch_cached_dev_attach (struct cached_dev *,struct cache_set *,uint8_t *);void bch_cached_dev_detach (struct cached_dev *);void bch_cached_dev_run (struct cached_dev *);void bcache_device_stop (struct bcache_device *);
drivers/md/bcache/super.c +6 -4
@@ -939,7 +939,8 @@ void bch_cached_dev_detach(struct cachedcached_dev_put (dc); } -int bch_cached_dev_attach (struct cached_dev *dc,struct cache_set *c) +int bch_cached_dev_attach (struct cached_dev *dc,struct cache_set *c, +uint8_t *set_uuid) {uint32_t rtime =cpu_to_le32 (get_seconds ());struct uuid_entry *u;
@@ -948,7 +949,8 @@ int bch_cached_dev_attach(struct cached_bdevname (dc->bdev, buf); -if (memcmp (dc->sb.set_uuid, c->sb.set_uuid,16 )) +if ((set_uuid &&memcmp (set_uuid, c->sb.set_uuid,16 )) || + (!set_uuid &&memcmp (dc->sb.set_uuid, c->sb.set_uuid,16 )))return -ENOENT ;if (dc->disk.c) {
@@ -1190,7 +1192,7 @@ static void register_bdev(struct cache_slist_add (&dc->list, &uncached_devices);list_for_each_entry (c, &bch_cache_sets, list) -bch_cached_dev_attach (dc, c); +bch_cached_dev_attach (dc, c,NULL );if (BDEV_STATE (&dc->sb) ==BDEV_STATE_NONE ||BDEV_STATE (&dc->sb) ==BDEV_STATE_STALE )
@@ -1712,7 +1714,7 @@ static void run_cache_set(struct cache_sbcache_write_super (c);list_for_each_entry_safe (dc, t, &uncached_devices, list) -bch_cached_dev_attach (dc, c); +bch_cached_dev_attach (dc, c,NULL );flash_devs_run (c);
drivers/md/bcache/sysfs.c +4 -2
@@ -265,11 +265,13 @@ STORE(__cached_dev) }if (attr == &sysfs_attach) { -if (bch_parse_uuid (buf, dc->sb.set_uuid) <16 ) +uint8_t set_uuid[16 ]; + +if (bch_parse_uuid (buf, set_uuid) <16 )return -EINVAL ;list_for_each_entry (c, &bch_cache_sets, list) { - v =bch_cached_dev_attach (dc, c); + v =bch_cached_dev_attach (dc, c, set_uuid);if (!v)return size; }
Greg Kroah-Hartman
maintainerPATCH 150/183 bcache: return attach error when no cache set exist
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tang Junhui <[email protected]>
[ Upstream commit 7f4fc93d4713394ee8f1cd44c238e046e11b4f15 ]
I attach a back-end device to a cache set, and the cache set is not registered yet, this back-end device did not attach successfully, and no error returned:
[root]# echo 87859280-fec6-4bcc-20df7ca8f86b > /sys/block/sde/bcache/attach [root]#
In sysfs_attach(), the return value "v" is initialized to "size" in the beginning, and if no cache set exist in bch_cache_sets, the "v" value would not change any more, and return to sysfs, sysfs regard it as success since the "size" is a positive number.
This patch fixes this issue by assigning "v" with "-ENOENT" in the initialization.
--- drivers/md/bcache/sysfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/md/bcache/sysfs.c +3 -2
@@ -193,7 +193,7 @@ STORE(__cached_dev) { struct cached_dev *dc = container_of(kobj, struct cached_dev, disk.kobj); -ssize_t v = size; +ssize_t v;struct cache_set *c;struct kobj_uevent_env *env;
@@ -270,6 +270,7 @@ STORE(__cached_dev)if (bch_parse_uuid (buf, set_uuid) <16 )return -EINVAL ; + v = -ENOENT ;list_for_each_entry (c, &bch_cache_sets, list) { v =bch_cached_dev_attach (dc, c, set_uuid);if (!v)
@@ -277,7 +278,7 @@ STORE(__cached_dev) }pr_err ("Can't attach %s: cache set not found" , buf); - size = v; +return v; }if (attr == &sysfs_detach && dc->disk.c)
Greg Kroah-Hartman
maintainerPATCH 151/183 cpufreq: intel_pstate: Enable HWP during system resume on CPU0
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Yu <[email protected]>
[ Upstream commit 70f6bf2a3b7e40c3f802b0ea837762a8bc6c1430 ]
When maxcpus=1 is in the kernel command line, the BP is responsible for re-enabling the HWP - because currently only the APs invoke intel_pstate_hwp_enable() during their online process - which might put the system into unstable state after resume.
Fix this by enabling the HWP explicitly on BP during resume.
--- drivers/cpufreq/intel_pstate.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/cpufreq/intel_pstate.c +5 -0
@@ -779,6 +779,8 @@ static int intel_pstate_hwp_save_state(sreturn 0 ; } +static void intel_pstate_hwp_enable (struct cpudata *cpudata); +static int intel_pstate_resume (struct cpufreq_policy *policy) {if (!hwp_active)
@@ -786,6 +788,9 @@ static int intel_pstate_resume(struct cpmutex_lock (&intel_pstate_limits_lock); +if (policy->cpu ==0 ) +intel_pstate_hwp_enable (all_cpu_data[policy->cpu]); + all_cpu_data[policy->cpu]->epp_policy =0 ;intel_pstate_hwp_set (policy->cpu);
Greg Kroah-Hartman
maintainerPATCH 152/183 selftests/ftrace: Add some missing glob checks
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (VMware)" <[email protected]>
[ Upstream commit 97fe22adf33f06519bfdf7dad33bcd562e366c8f ]
Al Viro discovered a bug in the glob ftrace filtering code where "*a*b" is treated the same as "a*b", and functions that would be selected by "*a*b" but not "a*b" are not selected with "*a*b".
Add tests for patterns "*a*b" and "a*b*" to the glob selftest.
--- tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc | 6 ++++++ 1 file changed, 6 insertions(+)
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc +6 -0
@@ -29,6 +29,12 @@ ftrace_filter_check '*schedule*' '^.*sch # filter by *, end match ftrace_filter_check 'schedule*' '^schedule.*$' +# filter by *mid*end +ftrace_filter_check '*aw*lock' '.*aw.*lock$' + +# filter by start*mid* +ftrace_filter_check 'mutex*try*' '^mutex.*try.*' + # Advanced full-glob matching feature is recently supported. # Skip the tests if we are sure the kernel does not support it. if grep -q 'accepts: .* glob-matching-pattern' README ; then
Greg Kroah-Hartman
maintainerPATCH 153/183 rxrpc: Dont put crypto buffers on the stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 8c2f826dc36314059ac146c78d3bf8056b626446 ]
Don't put buffers of data to be handed to crypto on the stack as this may cause an assertion failure in the kernel (see below). Fix this by using an kmalloc'd buffer instead.
kernel BUG at ./include/linux/scatterlist.h:147!
...
RIP: 0010:rxkad_encrypt_response.isra.6+0x191/0x1b0 [rxrpc] RSP: 0018:ffffbe2fc06cfca8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff989277d59900 RCX: 0000000000000028 RDX: 0000259dc06cfd88 RSI: 0000000000000025 RDI: ffffbe30406cfd88 RBP: ffffbe2fc06cfd60 R08: ffffbe2fc06cfd08 R09: ffffbe2fc06cfd08 R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff7c5f80d9f95 R13: ffffbe2fc06cfd88 R14: ffff98927a3f7aa0 R15: ffffbe2fc06cfd08 FS: 0000000000000000(0000) GS:ffff98927fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b1ff28f0f8 CR3: 000000001b412003 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxkad_respond_to_challenge+0x297/0x330 [rxrpc] rxrpc_process_connection+0xd1/0x690 [rxrpc] ? process_one_work+0x1c3/0x680 ? __lock_is_held+0x59/0xa0 process_one_work+0x249/0x680 worker_thread+0x3a/0x390 ? process_one_work+0x680/0x680 kthread+0x121/0x140 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x3a/0x50
--- net/rxrpc/conn_event.c | 1 net/rxrpc/rxkad.c | 92 +++++++++++++++++++++++++++---------------------- 2 files changed, 52 insertions(+), 41 deletions(-)
net/rxrpc/conn_event.c +1 -0
@@ -404,6 +404,7 @@ void rxrpc_process_connection(struct worcase -EKEYEXPIRED :case -EKEYREJECTED : goto protocol_error; +case -ENOMEM :case -EAGAIN : goto requeue_and_leave;case -ECONNABORTED :
net/rxrpc/rxkad.c +51 -41
174 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 154/183 svcrdma: Fix Read chunk round-up
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever <[email protected]>
[ Upstream commit 175e03101d36c3034f3c80038d4c28838351a7f2 ]
A single NFSv4 WRITE compound can often have three operations:
PUTFH, WRITE, then GETATTR.
When the WRITE payload is sent in a Read chunk, the client places the GETATTR in the inline part of the RPC/RDMA message, just after the WRITE operation (sans payload). The position value in the Read chunk enables the receiver to insert the Read chunk at the correct place in the received XDR stream; that is between the WRITE and GETATTR.
According to RFC 8166, an NFS/RDMA client does not have to add XDR round-up to the Read chunk that carries the WRITE payload. The receiver adds XDR round-up padding if it is absent and the receiver's XDR decoder requires it to be present.
Commit 193bcb7b3719 ("svcrdma: Populate tail iovec when receiving") attempted to add support for receiving such a compound so that just the WRITE payload appears in rq_arg's page list, and the trailing GETATTR is placed in rq_arg's tail iovec. (TCP just strings the whole compound into the head iovec and page list, without regard to the alignment of the WRITE payload).
The server transport logic also had to accommodate the optional XDR round-up of the Read chunk, which it did simply by lengthening the tail iovec when round-up was needed. This approach is adequate for the NFSv2 and NFSv3 WRITE decoders.
Unfortunately it is not sufficient for nfsd4_decode_write. When the Read chunk length is a couple of bytes less than PAGE_SIZE, the computation at the end of nfsd4_decode_write allows argp->pagelen to go negative, which breaks the logic in read_buf that looks for the tail iovec.
The result is that a WRITE operation whose payload length is just less than a multiple of a page succeeds, but the subsequent GETATTR in the same compound fails with NFS4ERR_OP_ILLEGAL because the XDR decoder can't find it. Clients ignore the error, but they must update their attribute cache via a separate round trip.
As nfsd4_decode_write appears to expect the payload itself to always have appropriate XDR round-up, have svc_rdma_build_normal_read_chunk add the Read chunk XDR round-up to the page_len rather than lengthening the tail iovec.
--- net/sunrpc/xprtrdma/svc_rdma_rw.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
net/sunrpc/xprtrdma/svc_rdma_rw.c +8 -4
@@ -727,12 +727,16 @@ static int svc_rdma_build_normal_read_ch head->arg.head[0 ].iov_len - info->ri_position; head->arg.head[0 ].iov_len = info->ri_position; -/* Read chunk may need XDR roundup (see RFC 5666, s. 3.7). +/* Read chunk may need XDR roundup (see RFC 8166, s. 3.4.5.2). * -* NFSv2/3 write decoders need the length of the tail to -* contain the size of the roundup padding. +* If the client already rounded up the chunk length, the +* length does not change. Otherwise, the length of the page +* list is increased to include XDR round-up. +* +* Currently these chunks always start at page offset 0, +* thus the rounded-up length never crosses a page boundary. */ - head->arg.tail[0 ].iov_len +=4 - (info->ri_chunklen &3 ); + info->ri_chunklen =XDR_QUADLEN (info->ri_chunklen) <<2 ; head->arg.page_len = info->ri_chunklen; head->arg.len += info->ri_chunklen;
Greg Kroah-Hartman
maintainerPATCH 155/183 net: Extra _get in declaration of arch_get_platform_mac_address
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathieu Malaterre <[email protected]>
[ Upstream commit e728789c52afccc1275cba1dd812f03abe16ea3c ]
In commit c7f5d105495a ("net: Add eth_platform_get_mac_address() helper."), two declarations were added:
int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr); unsigned char *arch_get_platform_get_mac_address(void);
An extra '_get' was introduced in arch_get_platform_get_mac_address, remove it. Fix compile warning using W=1:
CC net/ethernet/eth.onet/ethernet/eth.c:523:24: warning: no previous prototype for ‘arch_get_platform_mac_address’ [-Wmissing-prototypes]
unsigned char * __weak arch_get_platform_mac_address(void)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AR net/ethernet/built-in.o
--- include/linux/etherdevice.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/etherdevice.h +1 -1
@@ -31,7 +31,7 @@#ifdef __KERNEL__struct device ;int eth_platform_get_mac_address (struct device *dev,u8 *mac_addr); -unsigned char *arch_get_platform_get_mac_address (void ); +unsigned char *arch_get_platform_mac_address (void );u32 eth_get_headlen (void *data,unsigned int max_len);__be16 eth_type_trans (struct sk_buff *skb,struct net_device *dev);extern const struct header_ops eth_header_ops;
Greg Kroah-Hartman
maintainerPATCH 156/183 tools/libbpf: handle issues with bpf ELF objects containing .eh_frames
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesper Dangaard Brouer <[email protected]>
[ Upstream commit e3d91b0ca523d53158f435a3e13df7f0cb360ea2 ]
V3: More generic skipping of relo-section (suggested by Daniel)
If clang >= 4.0.1 is missing the option '-target bpf', it will cause llc/llvm to create two ELF sections for "Exception Frames", with section names '.eh_frame' and '.rel.eh_frame'.
The BPF ELF loader library libbpf fails when loading files with these sections. The other in-kernel BPF ELF loader in samples/bpf/bpf_load.c, handle this gracefully. And iproute2 loader also seems to work with these "eh" sections.
The issue in libbpf is caused by bpf_object__elf_collect() skipping some sections, and later when performing relocation it will be pointing to a skipped section, as these sections cannot be found by bpf_object__find_prog_by_idx() in bpf_object__collect_reloc().
This is a general issue that also occurs for other sections, like debug sections which are also skipped and can have relo section.
As suggested by Daniel. To avoid keeping state about all skipped sections, instead perform a direct qlookup in the ELF object. Lookup the section that the relo-section points to and check if it contains executable machine instructions (denoted by the sh_flags SHF_EXECINSTR). Use this check to also skip irrelevant relo-sections.
Note, for samples/bpf/ the '-target bpf' parameter to clang cannot be used due to incompatibility with asm embedded headers, that some of the samples include. This is explained in more details by Yonghong Song in bpf_devel_QA.
--- tools/lib/bpf/libbpf.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
tools/lib/bpf/libbpf.c +26 -0
@@ -661,6 +661,24 @@ bpf_object__init_maps(struct bpf_objectreturn bpf_object__validate_maps (obj); } +static bool section_have_execinstr (struct bpf_object *obj,int idx) +{ +Elf_Scn *scn; +GElf_Shdr sh; + + scn =elf_getscn (obj->efile.elf, idx); +if (!scn) +return false; + +if (gelf_getshdr (scn, &sh) != &sh) +return false; + +if (sh.sh_flags &SHF_EXECINSTR ) +return true; + +return false; +} +static int bpf_object__elf_collect (struct bpf_object *obj) {Elf *elf = obj->efile.elf;
@@ -742,6 +760,14 @@ static int bpf_object__elf_collect(struc }else if (sh.sh_type ==SHT_REL ) {void *reloc = obj->efile.reloc;int nr_reloc = obj->efile.nr_reloc +1 ; +int sec = sh.sh_info;/* points to other section */ + +/* Only do relo for section with exec instructions */ +if (!section_have_execinstr (obj, sec)) { +pr_debug ("skip relo %s(%d) for section(%d)\n" , + name, idx, sec); +continue ; + } reloc =realloc (reloc,sizeof (*obj->efile.reloc) * nr_reloc);
Greg Kroah-Hartman
maintainerPATCH 157/183 KVM: PPC: Book3S HV: Fix handling of secondary HPTEG in HPT resizing code
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Mackerras <[email protected]>
[ Upstream commit 05f2bb0313a2855e491dadfc8319b7da261d7074 ]
This fixes the computation of the HPTE index to use when the HPT resizing code encounters a bolted HPTE which is stored in its secondary HPTE group. The code inverts the HPTE group number, which is correct, but doesn't then mask it with new_hash_mask. As a result, new_pteg will be effectively negative, resulting in new_hptep pointing before the new HPT, which will corrupt memory.
In addition, this removes two BUG_ON statements. The condition that the BUG_ONs were testing -- that we have computed the hash value incorrectly -- has never been observed in testing, and if it did occur, would only affect the guest, not the host. Given that BUG_ON should only be used in conditions where the kernel (i.e. the host kernel, in this case) can't possibly continue execution, it is not appropriate here.
--- arch/powerpc/kvm/book3s_64_mmu_hv.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
arch/powerpc/kvm/book3s_64_mmu_hv.c +2 -6
@@ -1348,12 +1348,8 @@ static unsigned long resize_hpt_rehash_h } new_pteg = hash & new_hash_mask; -if (vpte &HPTE_V_SECONDARY ) { -BUG_ON (~pteg != (hash & old_hash_mask)); - new_pteg = ~new_pteg; - }else { -BUG_ON (pteg != (hash & old_hash_mask)); - } +if (vpte &HPTE_V_SECONDARY ) + new_pteg = ~hash & new_hash_mask; new_idx = new_pteg *HPTES_PER_GROUP + (idx %HPTES_PER_GROUP ); new_hptep = (__be64 *)(new->virt + (new_idx <<4 ));
Greg Kroah-Hartman
maintainerPATCH 158/183 SUNRPC: Dont call __UDPX_INC_STATS() from a preemptible context
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit 0afa6b4412988019db14c6bfb8c6cbdf120ca9ad ]
Calling __UDPX_INC_STATS() from a preemptible context leads to a warning of the form:
BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u5:0/31 caller is xs_udp_data_receive_workfn+0x194/0x270 CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1 #2 Workqueue: xprtiod xs_udp_data_receive_workfn Call Trace: dump_stack+0x85/0xc1 check_preemption_disabled+0xce/0xe0 xs_udp_data_receive_workfn+0x194/0x270 process_one_work+0x318/0x620 worker_thread+0x20a/0x390 ? process_one_work+0x620/0x620 kthread+0x120/0x130 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x24/0x30
Since we're taking a spinlock in those functions anyway, let's fix the issue by moving the call so that it occurs under the spinlock.
--- net/sunrpc/xprtsock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/sunrpc/xprtsock.c +2 -2
@@ -1069,18 +1069,18 @@ static void xs_udp_data_read_skb(struct/* Suck it into the iovec, verify checksum if not done by hw. */ if (csum_partial_copy_to_xdr (&rovr->rq_private_buf, skb)) { -__UDPX_INC_STATS (sk,UDP_MIB_INERRORS );spin_lock (&xprt->recv_lock); +__UDPX_INC_STATS (sk,UDP_MIB_INERRORS ); goto out_unpin; } -__UDPX_INC_STATS (sk,UDP_MIB_INDATAGRAMS );spin_lock_bh (&xprt->transport_lock);xprt_adjust_cwnd (xprt, task, copied);spin_unlock_bh (&xprt->transport_lock);spin_lock (&xprt->recv_lock);xprt_complete_rqst (task, copied); +__UDPX_INC_STATS (sk,UDP_MIB_INDATAGRAMS ); out_unpin:xprt_unpin_rqst (rovr); out_unlock:
Greg Kroah-Hartman
maintainerPATCH 159/183 net: stmmac: discard disabled flags in interrupt status register
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 1b84ca187510f60f00f4e15255043ce19bb30410 ]
The interrupt status register in both dwmac1000 and dwmac4 ignores interrupt enable (for dwmac4) / interrupt mask (for dwmac1000). Therefore, if we want to check only the bits that can actually trigger an irq, we have to filter the interrupt status register manually.
Commit 0a764db10337 ("stmmac: Discard masked flags in interrupt status register") fixed this for dwmac1000. Fix the same issue for dwmac4.
Just like commit 0a764db10337 ("stmmac: Discard masked flags in interrupt status register"), this makes sure that we do not get spurious link up/link down prints.
--- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +4 -2
@@ -562,10 +562,12 @@ static int dwmac4_irq_status(struct mac_ struct stmmac_extra_stats *x) {void __iomem *ioaddr = hw->pcsr; -u32 intr_status; +u32 intr_status =readl (ioaddr +GMAC_INT_STATUS ); +u32 intr_enable =readl (ioaddr +GMAC_INT_EN );int ret =0 ; - intr_status =readl (ioaddr +GMAC_INT_STATUS ); +/* Discard disabled bits */ + intr_status &= intr_enable;/* Not used events (e.g. MMC interrupts) are not handled. */ if ((intr_status & mmc_tx_irq))
Greg Kroah-Hartman
maintainerPATCH 160/183 bpf: fix rlimit in reuseport net selftest
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <[email protected]>
[ Upstream commit 941ff6f11c020913f5cddf543a9ec63475d7c082 ]
Fix two issues in the reuseport_bpf selftests that were reported by Linaro CI:
[...]
+ ./reuseport_bpf
---- IPv4 UDP ----
Testing EBPF mod 10...
Reprograming, testing mod 5...
./reuseport_bpf: ebpf error. log:
0: (bf) r6 = r1
1: (20) r0 = *(u32 *)skb[0]
2: (97) r0 %= 10
3: (95) exit
processed 4 insns
: Operation not permitted
+ echo FAIL
[...]
---- IPv4 TCP ----
Testing EBPF mod 10...
./reuseport_bpf: failed to bind send socket: Address already in use
+ echo FAIL
[...]
For the former adjust rlimit since this was the cause of failure for loading the BPF prog, and for the latter add SO_REUSEADDR.
--- tools/testing/selftests/net/reuseport_bpf.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
tools/testing/selftests/net/reuseport_bpf.c +20 -1
@@ -21,6 +21,7 @@#include <sys/epoll.h> #include <sys/types.h> #include <sys/socket.h> +#include <sys/resource.h> #include <unistd.h> #ifndef ARRAY_SIZE
@@ -190,11 +191,14 @@ static void send_from(struct test_paramsstruct sockaddr *const saddr =new_any_sockaddr (p.send_family, sport);struct sockaddr *const daddr =new_loopback_sockaddr (p.send_family, p.recv_port); -const int fd =socket (p.send_family, p.protocol,0 ); +const int fd =socket (p.send_family, p.protocol,0 ), one =1 ;if (fd <0 )error (1 , errno,"failed to create send socket" ); +if (setsockopt (fd,SOL_SOCKET ,SO_REUSEADDR , &one,sizeof (one))) +error (1 , errno,"failed to set reuseaddr" ); +if (bind (fd, saddr,sockaddr_size ()))error (1 , errno,"failed to bind send socket" );
@@ -433,6 +437,21 @@ void enable_fastopen(void) } } +static struct rlimit rlim_old, rlim_new; + +static __attribute__((constructor))void main_ctor (void ) +{ +getrlimit (RLIMIT_MEMLOCK , &rlim_old); + rlim_new.rlim_cur = rlim_old.rlim_cur + (1UL <<20 ); + rlim_new.rlim_max = rlim_old.rlim_max + (1UL <<20 ); +setrlimit (RLIMIT_MEMLOCK , &rlim_new); +} + +static __attribute__((destructor))void main_dtor (void ) +{ +setrlimit (RLIMIT_MEMLOCK , &rlim_old); +} +int main (void ) {fprintf (stderr,"---- IPv4 UDP ----\n" );
Greg Kroah-Hartman
maintainerPATCH 161/183 ACPI / EC: Restore polling during noirq suspend/resume phases
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
[ Upstream commit 3cd091a773936c54344a519f7ee1379ccb620bee ]
Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) modified the ACPI EC driver so that it doesn't switch over to busy polling mode during noirq stages of system suspend and resume in an attempt to fix an issue resulting from that behavior.
However, that modification introduced a system resume regression on Thinkpad X240, so make the EC driver switch over to the polling mode during noirq stages of system suspend and resume again, which effectively reverts the problematic commit.
--- drivers/acpi/ec.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/acpi/ec.c +6 -0
@@ -1927,6 +1927,9 @@ static int acpi_ec_suspend_noirq(struct ec->reference_count >= 1)acpi_set_gpe (NULL , ec->gpe,ACPI_GPE_DISABLE ); +if (acpi_sleep_no_ec_events ()) +acpi_ec_enter_noirq (ec); +return 0 ; }
@@ -1934,6 +1937,9 @@ static int acpi_ec_resume_noirq(struct d {struct acpi_ec *ec =acpi_driver_data (to_acpi_device (dev)); +if (acpi_sleep_no_ec_events ()) +acpi_ec_leave_noirq (ec); +if (ec_no_wakeup &&test_bit (EC_FLAGS_STARTED , &ec->flags) && ec->reference_count >=1 )acpi_set_gpe (NULL , ec->gpe,ACPI_GPE_ENABLE );
Greg Kroah-Hartman
maintainerPATCH 162/183 PM / wakeirq: Fix unbalanced IRQ enable for wakeirq
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
[ Upstream commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 ]
If a device is runtime PM suspended when we enter suspend and has a dedicated wake IRQ, we can get the following warning:
WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94 [ 102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [<c06117a8>] (dev_pm_arm_wake_irq+0x4c/0x60) (dev_pm_arm_wake_irq) from [<c0618360>]
(device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from [<c0615948>] (dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from [<c01ac7ac>] (suspend_devices_and_enter+0x30c/0xf14) (suspend_devices_and_enter) from [<c01adf20>] (enter_state+0xad4/0xbd8)
(enter_state) from [<c01ad3ec>] (pm_suspend+0x38/0x98) (pm_suspend) from [<c01ab3e8>] (state_store+0x68/0xc8)
This is because the dedicated wake IRQ for the device may have been already enabled earlier by dev_pm_enable_wake_irq_check(). Fix the issue by checking for runtime PM suspended status.
This issue can be easily reproduced by setting serial console log level to zero, letting the serial console idle, and suspend the system from an ssh terminal. On resume, dmesg will have the warning above.
The reason why I have not run into this issue earlier has been that I typically run my PM test cases from on a serial console instead over ssh.
--- drivers/base/power/wakeirq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/base/power/wakeirq.c +4 -2
@@ -323,7 +323,8 @@ void dev_pm_arm_wake_irq(struct wake_irqreturn ;if (device_may_wakeup (wirq->dev)) { -if (wirq->status &WAKE_IRQ_DEDICATED_ALLOCATED ) +if (wirq->status &WAKE_IRQ_DEDICATED_ALLOCATED && + !pm_runtime_status_suspended (wirq->dev))enable_irq (wirq->irq);enable_irq_wake (wirq->irq);
@@ -345,7 +346,8 @@ void dev_pm_disarm_wake_irq(struct wake_if (device_may_wakeup (wirq->dev)) {disable_irq_wake (wirq->irq); -if (wirq->status &WAKE_IRQ_DEDICATED_ALLOCATED ) +if (wirq->status &WAKE_IRQ_DEDICATED_ALLOCATED && + !pm_runtime_status_suspended (wirq->dev))disable_irq_nosync (wirq->irq); } }
Greg Kroah-Hartman
maintainerPATCH 163/183 vfs/proc/kcore, x86/mm/kcore: Fix SMAP fault when dumping vsyscall user page
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia Zhang <[email protected]>
[ Upstream commit 595dd46ebfc10be041a365d0a3fa99df50b6ba73 ]
Commit:
df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
... introduced a bounce buffer to work around CONFIG_HARDENED_USERCOPY=y. However, accessing the vsyscall user page will cause an SMAP fault.
Replace memcpy() with copy_from_user() to fix this bug works, but adding a common way to handle this sort of user page may be useful for future.
Currently, only vsyscall page requires KCORE_USER.
--- arch/x86/mm/init_64.c | 3 +-- fs/proc/kcore.c | 4 ++++ include/linux/kcore.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-)
arch/x86/mm/init_64.c +1 -2
@@ -1180,8 +1180,7 @@ void __init mem_init(void) after_bootmem =1 ;/* Register memory areas for /proc/kcore */ -kclist_add (&kcore_vsyscall, (void *)VSYSCALL_ADDR , -PAGE_SIZE ,KCORE_OTHER ); +kclist_add (&kcore_vsyscall, (void *)VSYSCALL_ADDR ,PAGE_SIZE ,KCORE_USER );mem_init_print_info (NULL ); }
fs/proc/kcore.c +4 -0
@@ -510,6 +510,10 @@ read_kcore(struct file *file, char __use/* we have to zero-fill user buffer even if no read */ if (copy_to_user (buffer, buf, tsz))return -EFAULT ; + }else if (m->type ==KCORE_USER ) { +/* User page is handled prior to normal kernel page: */ +if (copy_to_user (buffer, (char *)start, tsz)) +return -EFAULT ; }else {if (kern_addr_valid (start)) {/*
include/linux/kcore.h +1 -0
@@ -10,6 +10,7 @@ enum kcore_type {KCORE_VMALLOC ,KCORE_RAM ,KCORE_VMEMMAP , +KCORE_USER , KCORE_OTHER, };
Greg Kroah-Hartman
maintainerPATCH 164/183 powerpc/mm/hash64: Zero PGD pages on allocation
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Aneesh Kumar K.V" <[email protected]>
[ Upstream commit fc5c2f4a55a2c258e12013cdf287cf266dbcd2a7 ]
On powerpc we allocate page table pages from slab caches of different sizes. Currently we have a constructor that zeroes out the objects when we allocate them for the first time.
We expect the objects to be zeroed out when we free the the object back to slab cache. This happens in the unmap path. For hugetlb pages we call huge_pte_get_and_clear() to do that.
With the current configuration of page table size, both PUD and PGD level tables are allocated from the same slab cache. At the PUD level, we use the second half of the table to store the slot information. But we never clear that when unmapping.
When such a freed object is then allocated for a PGD page, the second half of the page table page will not be zeroed as expected. This results in a kernel crash.
Fix it by always clearing PGD pages when they're allocated.
--- arch/powerpc/include/asm/book3s/64/pgalloc.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
arch/powerpc/include/asm/book3s/64/pgalloc.h +8 -2
@@ -73,10 +73,16 @@ static inline void radix__pgd_free(strucstatic inline pgd_t *pgd_alloc (struct mm_struct *mm) { +pgd_t *pgd; +if (radix_enabled ())return radix__pgd_alloc (mm); -return kmem_cache_alloc (PGT_CACHE (PGD_INDEX_SIZE ), -pgtable_gfp_flags (mm,GFP_KERNEL )); + + pgd =kmem_cache_alloc (PGT_CACHE (PGD_INDEX_SIZE ), +pgtable_gfp_flags (mm,GFP_KERNEL )); +memset (pgd,0 ,PGD_TABLE_SIZE ); + +return pgd; }static inline void pgd_free (struct mm_struct *mm,pgd_t *pgd)
Greg Kroah-Hartman
maintainerPATCH 165/183 x86/platform/UV: Fix GAM Range Table entries less than 1GB
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
[ Upstream commit c25d99d20ba69824a1e2cc118e04b877cd427afc ]
The latest UV platforms include the new ApachePass NVDIMMs into the UV address space. This has introduced address ranges in the Global Address Map Table that are less than the previous lowest range, which was 2GB. Fix the address calculation so it accommodates address ranges from bytes to exabytes.
--- arch/x86/kernel/apic/x2apic_uv_x.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
arch/x86/kernel/apic/x2apic_uv_x.c +12 -3
@@ -1140,16 +1140,25 @@ static void __init decode_gam_rng_tbl(un uv_gre_table = gre;for (; gre->type !=UV_GAM_RANGE_TYPE_UNUSED ; gre++) { +unsigned long size = ((unsigned long )(gre->limit - lgre) + <<UV_GAM_RANGE_SHFT ); +int order =0 ; +char suffix[] =" KMGTPE" ; + +while (size >9999 && order <sizeof (suffix)) { + size /=1024 ; + order++; + } +if (!index) {pr_info ("UV: GAM Range Table...\n" );pr_info ("UV: # %20s %14s %5s %4s %5s %3s %2s\n" ,"Range" ,"" ,"Size" ,"Type" ,"NASID" ,"SID" ,"PN" ); } -pr_info ("UV: %2d: 0x%014lx-0x%014lx %5luG %3d %04x %02x %02x\n" , +pr_info ("UV: %2d: 0x%014lx-0x%014lx %5lu%c %3d %04x %02x %02x\n" , index++, (unsigned long )lgre <<UV_GAM_RANGE_SHFT , (unsigned long )gre->limit <<UV_GAM_RANGE_SHFT , - ((unsigned long )(gre->limit - lgre)) >> - (30 -UV_GAM_RANGE_SHFT ),/* 64M -> 1G */ + size, suffix[order], gre->type, gre->nasid, gre->sockid, gre->pnode); lgre = gre->limit;
Greg Kroah-Hartman
maintainerPATCH 166/183 locking/qspinlock: Ensure node->count is updated before initialising node
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
[ Upstream commit 11dc13224c975efcec96647a4768a6f1bb7a19a8 ]
When queuing on the qspinlock, the count field for the current CPU's head node is incremented. This needn't be atomic because locking in e.g. IRQ context is balanced and so an IRQ will return with node->count as it found it.
However, the compiler could in theory reorder the initialisation of node[idx] before the increment of the head node->count, causing an IRQ to overwrite the initialised node and potentially corrupt the lock state.
Avoid the potential for this harmful compiler reordering by placing a barrier() between the increment of the head node->count and the subsequent node initialisation.
--- kernel/locking/qspinlock.c | 8 ++++++++ 1 file changed, 8 insertions(+)
kernel/locking/qspinlock.c +8 -0
@@ -379,6 +379,14 @@ queue: tail =encode_tail (smp_processor_id (), idx); node += idx; + +/* +* Ensure that we increment the head node->count before initialising +* the actual node. If the compiler is kind enough to reorder these +* stores, then an IRQ could overwrite our assignments. +*/ +barrier (); + node->locked =0 ; node->next =NULL ;pv_init_node (node);
Greg Kroah-Hartman
maintainerPATCH 167/183 powerpc/powernv: IMC fix out of bounds memory access at shutdown
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit e7bde88cdb4f0e432398a7d29ca2a15d2c18952a ]
The OPAL IMC driver's shutdown handler disables nest PMU counters by walking nodes and taking the first CPU out of their cpumask, which is used to index into the paca (get_hard_smp_processor_id()). This does not always do the right thing, and in particular for CPU-less nodes it returns NR_CPUS and that overruns the paca and dereferences random memory.
Fix it by being more careful about checking returned CPU, and only using online CPUs. It's not clear this shutdown code makes sense after commit 885dcd709b ("powerpc/perf: Add nest IMC PMU support"), but this should not make things worse
Currently the bug causes us to call OPAL with a junk CPU number. A separate patch in development to change the way pacas are allocated escalates this bug into a crash:
Unable to handle kernel paging request for data at address 0x2a21af1eeb000076 Faulting instruction address: 0xc0000000000a5468 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP opal_imc_counters_shutdown+0x148/0x1d0 LR opal_imc_counters_shutdown+0x134/0x1d0 Call Trace: opal_imc_counters_shutdown+0x134/0x1d0 (unreliable) platform_drv_shutdown+0x44/0x60 device_shutdown+0x1f8/0x350 kernel_restart_prepare+0x54/0x70 kernel_restart+0x28/0xc0 SyS_reboot+0x1d0/0x2c0 system_call+0x58/0x6c
--- arch/powerpc/platforms/powernv/opal-imc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/powerpc/platforms/powernv/opal-imc.c +4 -2
@@ -126,9 +126,11 @@ static void disable_nest_pmu_counters(voconst struct cpumask *l_cpumask;get_online_cpus (); -for_each_online_node (nid) { +for_each_node_with_cpus (nid) { l_cpumask =cpumask_of_node (nid); - cpu =cpumask_first (l_cpumask); + cpu =cpumask_first_and (l_cpumask, cpu_online_mask); +if (cpu >= nr_cpu_ids) +continue ;opal_imc_counters_stop (OPAL_IMC_COUNTERS_NEST ,get_hard_smp_processor_id (cpu)); }
Greg Kroah-Hartman
maintainerPATCH 168/183 perf test: Fix test trace+probe_libc_inet_pton.sh for s390x
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Richter <[email protected]>
[ Upstream commit 7a92453620d42c3a5fea94a864dc6aa04c262b93 ]
On Intel test case trace+probe_libc_inet_pton.sh succeeds and the output is:
[root@f27 perf]# ./perf trace --no-syscalls
-e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.037 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms
0.000 probe_libc:inet_pton:(7fa40ac618a0))
__GI___inet_pton (/usr/lib64/libc-2.26.so)
getaddrinfo (/usr/lib64/libc-2.26.so)
main (/usr/bin/ping)The kernel stack unwinder is used, it is specified implicitly as call-graph=fp (frame pointer).
On s390x only dwarf is available for stack unwinding. It is also done in user space. This requires different parameter setup and result checking for s390x and Intel.
This patch adds separate perf trace setup and result checking for Intel and s390x. On s390x specify this command line to get a call-graph and handle the different call graph result checking:
[root@s35lp76 perf]# ./perf trace --no-syscalls
-e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.041 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms
0.000 probe_libc:inet_pton:(3ffb9942060))
__GI___inet_pton (/usr/lib64/libc-2.26.so)
gaih_inet (inlined)
__GI_getaddrinfo (inlined)
main (/usr/bin/ping)
__libc_start_main (/usr/lib64/libc-2.26.so)
_start (/usr/bin/ping)[root@s35lp76 perf]#
Before:
[root@s8360047 perf]# ./perf test -vv 58
58: probe libc's inet_pton & backtrace it with ping :
--- start ---
test child forked, pid 26349
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.079 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.079/0.079/0.079/0.000 ms 0.000 probe_libc:inet_pton:(3ff925c2060))
test child finished with -1
---- end ----
probe libc's inet_pton & backtrace it with ping: FAILED! [root@s8360047 perf]#
After:
[root@s35lp76 perf]# ./perf test -vv 57
57: probe libc's inet_pton & backtrace it with ping :
--- start ---
test child forked, pid 38708
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.038 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms 0.000 probe_libc:inet_pton:(3ff87342060)) __GI___inet_pton (/usr/lib64/libc-2.26.so) gaih_inet (inlined)__GI_getaddrinfo (inlined)
main (/usr/bin/ping)__libc_start_main (/usr/lib64/libc-2.26.so)_start (/usr/bin/ping)
test child finished with 0
---- end ----
probe libc's inet_pton & backtrace it with ping: Ok [root@s35lp76 perf]#
On Intel the test case runs unchanged and succeeds.
--- tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 21 +++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
tools/perf/tests/shell/trace+probe_libc_inet_pton.sh +17 -4
@@ -22,10 +22,23 @@ trace_libc_inet_pton_backtrace() { expected[4]="rtt min.*" expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)" expected[6]=".*inet_pton[[:space:]]\($libc\)$" - expected[7]="getaddrinfo[[:space:]]\($libc\)$" - expected[8]=".*\(.*/bin/ping.*\)$" + case "$(uname -m)" in + s390x) + eventattr='call-graph=dwarf' + expected[7]="gaih_inet[[:space:]]\(inlined\)$" + expected[8]="__GI_getaddrinfo[[:space:]]\(inlined\)$" + expected[9]="main[[:space:]]\(.*/bin/ping.*\)$" + expected[10]="__libc_start_main[[:space:]]\($libc\)$" + expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$" + ;; + *) + eventattr='max-stack=3' + expected[7]="getaddrinfo[[:space:]]\($libc\)$" + expected[8]=".*\(.*/bin/ping.*\)$" + ;; + esac - perf trace --no-syscalls -e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1 2>&1 | grep -v ^$ | while read line ; do + perf trace --no-syscalls -e probe_libc:inet_pton/$eventattr/ ping -6 -c 1 ::1 2>&1 | grep -v ^$ | while read line ; do echo $line echo "$line" | egrep -q "${expected[$idx]}" if [ $? -ne 0 ] ; then
@@ -33,7 +46,7 @@ trace_libc_inet_pton_backtrace() { exit 1 fi let idx+=1 - [ $idx -eq 9 ] && break + [ -z "${expected[$idx]}" ] && break done }
Greg Kroah-Hartman
maintainerPATCH 169/183 irqchip/gic-v3: Ignore disabled ITS nodes
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Boyd <[email protected]>
[ Upstream commit 95a2562590c2f64a0398183f978d5cf3db6d0284 ]
On some platforms there's an ITS available but it's not enabled because reading or writing the registers is denied by the firmware. In fact, reading or writing them will cause the system to reset. We could remove the node from DT in such a case, but it's better to skip nodes that are marked as "disabled" in DT so that we can describe the hardware that exists and use the status property to indicate how the firmware has configured things.
--- drivers/irqchip/irq-gic-v3-its-pci-msi.c | 2 ++ drivers/irqchip/irq-gic-v3-its-platform-msi.c | 2 ++ drivers/irqchip/irq-gic-v3-its.c | 2 ++ drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 2 ++ 4 files changed, 8 insertions(+)
drivers/irqchip/irq-gic-v3-its-pci-msi.c +2 -0
@@ -132,6 +132,8 @@ static int __init its_pci_of_msi_init(vofor (np =of_find_matching_node (NULL , its_device_id); np; np =of_find_matching_node (np, its_device_id)) { +if (!of_device_is_available (np)) +continue ;if (!of_property_read_bool (np,"msi-controller" ))continue ;
drivers/irqchip/irq-gic-v3-its-platform-msi.c +2 -0
@@ -154,6 +154,8 @@ static void __init its_pmsi_of_init(voidfor (np =of_find_matching_node (NULL , its_device_id); np; np =of_find_matching_node (np, its_device_id)) { +if (!of_device_is_available (np)) +continue ;if (!of_property_read_bool (np,"msi-controller" ))continue ;
drivers/irqchip/irq-gic-v3-its.c +2 -0
@@ -3083,6 +3083,8 @@ static int __init its_of_probe(struct defor (np =of_find_matching_node (node, its_device_id); np; np =of_find_matching_node (np, its_device_id)) { +if (!of_device_is_available (np)) +continue ;if (!of_property_read_bool (np,"msi-controller" )) {pr_warn ("%pOF: no msi-controller property, ITS ignored\n" , np);
drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c +2 -0
@@ -75,6 +75,8 @@ int __init its_fsl_mc_msi_init(void)for (np =of_find_matching_node (NULL , its_device_id); np; np =of_find_matching_node (np, its_device_id)) { +if (!of_device_is_available (np)) +continue ;if (!of_property_read_bool (np,"msi-controller" ))continue ;
Greg Kroah-Hartman
maintainerPATCH 170/183 cpumask: Make for_each_cpu_wrap() available on UP as well
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Kelley <[email protected]>
[ Upstream commit d207af2eab3f8668b95ad02b21930481c42806fd ]
for_each_cpu_wrap() was originally added in the #else half of a large "#if NR_CPUS == 1" statement, but was omitted in the #if half. This patch adds the missing #if half to prevent compile errors when NR_CPUS is 1.
--- include/linux/cpumask.h | 2 ++ 1 file changed, 2 insertions(+)
include/linux/cpumask.h +2 -0
@@ -165,6 +165,8 @@ static inline unsigned int cpumask_local for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)#define for_each_cpu_not (cpu, mask) \ for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask) +#define for_each_cpu_wrap (cpu, mask, start) \ + for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)(start))#define for_each_cpu_and (cpu, mask, and) \ for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)and)#else
Greg Kroah-Hartman
maintainerPATCH 171/183 irqchip/gic-v3: Change pr_debug message to pr_devel
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Salter <[email protected]>
[ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]
The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking warning:
GICv3: CPU10: ICC_SGI1R_EL1 5000400
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #1 Tainted: G W
------------------------------------------------------
dynamic_debug01/1873 is trying to acquire lock:
((console_sem).lock){-...}, at: [<0000000099c891ec>] down_trylock+0x20/0x4c
but task is already holding lock:
(&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&rq->lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock+0x4c/0x60
task_fork_fair+0x3c/0x148
sched_fork+0x10c/0x214
copy_process.isra.32.part.33+0x4e8/0x14f0
_do_fork+0xe8/0x78c
kernel_thread+0x48/0x54
rest_init+0x34/0x2a4
start_kernel+0x45c/0x488-> #1 (&p->pi_lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
try_to_wake_up+0x48/0x600
wake_up_process+0x28/0x34
__up.isra.0+0x60/0x6c
up+0x60/0x68
__up_console_sem+0x4c/0x7c
console_unlock+0x328/0x634
vprintk_emit+0x25c/0x390
dev_vprintk_emit+0xc4/0x1fc
dev_printk_emit+0x88/0xa8
__dev_printk+0x58/0x9c
_dev_info+0x84/0xa8
usb_new_device+0x100/0x474
hub_port_connect+0x280/0x92c
hub_event+0x740/0xa84
process_one_work+0x240/0x70c
worker_thread+0x60/0x400
kthread+0x110/0x13c
ret_from_fork+0x10/0x18-> #0 ((console_sem).lock){-...}:
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4other info that might help us debug this:
Chain exists of: (console_sem).lock --> &p->pi_lock --> &rq->lock Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&rq->lock);
lock(&p->pi_lock);
lock(&rq->lock);lock((console_sem).lock);
*** DEADLOCK ***
2 locks held by dynamic_debug01/1873:
#0: (&p->pi_lock){-.-.}, at: [<000000001366df53>] wake_up_new_task+0x40/0x470 #1: (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc
stack backtrace: CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G W 4.15.0+ #1 Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017 Call trace: dump_backtrace+0x0/0x188 show_stack+0x24/0x2c dump_stack+0xa4/0xe0 print_circular_bug.isra.31+0x29c/0x2b8 check_prev_add.constprop.39+0x6c8/0x6dc validate_chain.isra.34+0x6e4/0xa20 __lock_acquire+0x3b4/0x6e0 lock_acquire+0xf4/0x2a8 _raw_spin_lock_irqsave+0x58/0x70 down_trylock+0x20/0x4c __down_trylock_console_sem+0x3c/0x9c console_trylock+0x20/0xb0 vprintk_emit+0x254/0x390 vprintk_default+0x58/0x90 vprintk_func+0xbc/0x164 printk+0x80/0xa0 __dynamic_pr_debug+0x84/0xac gic_raise_softirq+0x184/0x18c smp_cross_call+0xac/0x218 smp_send_reschedule+0x3c/0x48 resched_curr+0x60/0x9c check_preempt_curr+0x70/0xdc wake_up_new_task+0x310/0x470 _do_fork+0x188/0x78c SyS_clone+0x44/0x50 __sys_trace_return+0x0/0x4 GICv3: CPU0: ICC_SGI1R_EL1 12000
This could be fixed with printk_deferred() but that might lessen its usefulness for debugging. So change it to pr_devel to keep it out of production kernels. Developers working on gic-v3 can enable it as needed in their kernels.
--- drivers/irqchip/irq-gic-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/irqchip/irq-gic-v3.c +1 -1
@@ -645,7 +645,7 @@ static void gic_send_sgi(u64 cluster_id,MPIDR_TO_SGI_AFFINITY (cluster_id,1 ) | tlist << ICC_SGI1R_TARGET_LIST_SHIFT); -pr_debug ("CPU%d: ICC_SGI1R_EL1 %llx\n" ,smp_processor_id (), val); +pr_devel ("CPU%d: ICC_SGI1R_EL1 %llx\n" ,smp_processor_id (), val);gic_write_sgi1r (val); }
Greg Kroah-Hartman
maintainerPATCH 172/183 RDMA/core: Reduce poll batch for direct cq polling
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Gurtovoy <[email protected]>
[ Upstream commit d3b9e8ad425cfd5b9116732e057f1b48e4d3bcb8 ]
Fix warning limit for kernel stack consumption:
drivers/infiniband/core/cq.c: In function 'ib_process_cq_direct':drivers/infiniband/core/cq.c:78:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Using smaller ib_wc array on the stack brings us comfortably below that limit again.
--- drivers/infiniband/core/cq.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
drivers/infiniband/core/cq.c +11 -10
@@ -17,6 +17,7 @@/* # of WCs to poll for with a single call to ib_poll_cq */ #define IB_POLL_BATCH 16 +#define IB_POLL_BATCH_DIRECT 8/* # of WCs to iterate over before yielding */ #define IB_POLL_BUDGET_IRQ 256
@@ -25,18 +26,18 @@#define IB_POLL_FLAGS \ (IB_CQ_NEXT_COMP | IB_CQ_REPORT_MISSED_EVENTS) -static int __ib_process_cq (struct ib_cq *cq,int budget,struct ib_wc *poll_wc) +static int __ib_process_cq (struct ib_cq *cq,int budget,struct ib_wc *wcs, +int batch) {int i, n, completed =0 ; -struct ib_wc *wcs = poll_wc ? : cq->wc;/* * budget might be (-1) if the caller does not * want to bound this call, thus we need unsigned * minimum here. */ -while ((n =ib_poll_cq (cq,min_t (u32,IB_POLL_BATCH , - budget - completed), wcs)) >0 ) { +while ((n =ib_poll_cq (cq,min_t (u32, batch, + budget - completed), wcs)) >0 ) {for (i =0 ; i < n; i++) {struct ib_wc *wc = &wcs[i];
@@ -48,8 +49,7 @@ static int __ib_process_cq(struct ib_cq completed += n; -if (n !=IB_POLL_BATCH || - (budget !=-1 && completed >= budget)) +if (n != batch || (budget !=-1 && completed >= budget))break ; }
@@ -72,9 +72,9 @@ static int __ib_process_cq(struct ib_cq*/ int ib_process_cq_direct (struct ib_cq *cq,int budget) { -struct ib_wc wcs[IB_POLL_BATCH ]; +struct ib_wc wcs[IB_POLL_BATCH_DIRECT ]; -return __ib_process_cq (cq, budget, wcs); +return __ib_process_cq (cq, budget, wcs,IB_POLL_BATCH_DIRECT ); }EXPORT_SYMBOL (ib_process_cq_direct);
@@ -88,7 +88,7 @@ static int ib_poll_handler(struct irq_po struct ib_cq *cq = container_of(iop, struct ib_cq, iop);int completed; - completed =__ib_process_cq (cq, budget,NULL ); + completed =__ib_process_cq (cq, budget, cq->wc,IB_POLL_BATCH );if (completed < budget) {irq_poll_complete (&cq->iop);if (ib_req_notify_cq (cq,IB_POLL_FLAGS ) >0 )
@@ -108,7 +108,8 @@ static void ib_cq_poll_work(struct work_ struct ib_cq *cq = container_of(work, struct ib_cq, work);int completed; - completed =__ib_process_cq (cq,IB_POLL_BUDGET_WORKQUEUE ,NULL ); + completed =__ib_process_cq (cq,IB_POLL_BUDGET_WORKQUEUE , cq->wc, +IB_POLL_BATCH );if (completed >=IB_POLL_BUDGET_WORKQUEUE ||ib_req_notify_cq (cq,IB_POLL_FLAGS ) >0 )queue_work (ib_comp_wq, &cq->work);
Greg Kroah-Hartman
maintainerPATCH 173/183 alarmtimer: Init nanosleep alarm timer on stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit bd03143007eb9b03a7f2316c677780561b68ba2a upstream.
syszbot reported the following debugobjects splat:
ODEBUG: object is on stack, but not annotated
WARNING: CPU: 0 PID: 4185 at lib/debugobjects.c:328 RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:327 [inline] debug_object_init+0x17/0x20 lib/debugobjects.c:391 debug_hrtimer_init kernel/time/hrtimer.c:410 [inline] debug_init kernel/time/hrtimer.c:458 [inline] hrtimer_init+0x8c/0x410 kernel/time/hrtimer.c:1259 alarm_init kernel/time/alarmtimer.c:339 [inline] alarm_timer_nsleep+0x164/0x4d0 kernel/time/alarmtimer.c:787 SYSC_clock_nanosleep kernel/time/posix-timers.c:1226 [inline] SyS_clock_nanosleep+0x235/0x330 kernel/time/posix-timers.c:1204 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7
This happens because the hrtimer for the alarm nanosleep is on stack, but the code does not use the proper debug objects initialization.
Split out the code for the allocated use cases and invoke hrtimer_init_on_stack() for the nanosleep related functions.
--- kernel/time/alarmtimer.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-)
kernel/time/alarmtimer.c +26 -8
@@ -326,6 +326,17 @@ static int alarmtimer_resume(struct devi }#endif +static void +__alarm_init (struct alarm *alarm,enum alarmtimer_type type, +enum alarmtimer_restart (*function)(struct alarm *,ktime_t )) +{ +timerqueue_init (&alarm->node); + alarm->timer.function = alarmtimer_fired; + alarm->function = function; + alarm->type = type; + alarm->state =ALARMTIMER_STATE_INACTIVE ; +} +/** * alarm_init - Initialize an alarm structure * @alarm: ptr to alarm to be initialized
@@ -335,13 +346,9 @@ static int alarmtimer_resume(struct devivoid alarm_init (struct alarm *alarm,enum alarmtimer_type type,enum alarmtimer_restart (*function)(struct alarm *,ktime_t )) { -timerqueue_init (&alarm->node);hrtimer_init (&alarm->timer, alarm_bases[type].base_clockid, -HRTIMER_MODE_ABS ); - alarm->timer.function = alarmtimer_fired; - alarm->function = function; - alarm->type = type; - alarm->state =ALARMTIMER_STATE_INACTIVE ; +HRTIMER_MODE_ABS ); +__alarm_init (alarm, type, function); }EXPORT_SYMBOL_GPL (alarm_init);
@@ -719,6 +726,8 @@ static int alarmtimer_do_nsleep(struct a__set_current_state (TASK_RUNNING ); +destroy_hrtimer_on_stack (&alarm->timer); +if (!alarm->data)return 0 ;
@@ -740,6 +749,15 @@ static int alarmtimer_do_nsleep(struct areturn -ERESTART_RESTARTBLOCK ; } +static void +alarm_init_on_stack (struct alarm *alarm,enum alarmtimer_type type, +enum alarmtimer_restart (*function)(struct alarm *,ktime_t )) +{ +hrtimer_init_on_stack (&alarm->timer, alarm_bases[type].base_clockid, +HRTIMER_MODE_ABS ); +__alarm_init (alarm, type, function); +} +/** * alarm_timer_nsleep_restart - restartblock alarmtimer nsleep * @restart: ptr to restart block
@@ -752,7 +770,7 @@ static long __sched alarm_timer_nsleep_rktime_t exp = restart->nanosleep.expires;struct alarm alarm; -alarm_init (&alarm, type, alarmtimer_nsleep_wakeup); +alarm_init_on_stack (&alarm, type, alarmtimer_nsleep_wakeup);return alarmtimer_do_nsleep (&alarm, exp, type); }
@@ -784,7 +802,7 @@ static int alarm_timer_nsleep(const clocif (!capable (CAP_WAKE_ALARM ))return -EPERM ; -alarm_init (&alarm, type, alarmtimer_nsleep_wakeup); +alarm_init_on_stack (&alarm, type, alarmtimer_nsleep_wakeup); exp =timespec64_to_ktime (*tsreq);/* Convert (if necessary) to absolute time */
Greg Kroah-Hartman
maintainerPATCH 174/183 netfilter: x_tables: cap allocations at 512 mbyte
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit 19926968ea86a286aa6fbea16ee3f2e7442f10f0 upstream.
Arbitrary limit, however, this still allows huge rulesets (> 1 million rules). This helps with automated fuzzer as it prevents oom-killer invocation.
--- net/netfilter/x_tables.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/netfilter/x_tables.c +2 -1
@@ -40,6 +40,7 @@ MODULE_AUTHOR("Harald Welte <laforge@netMODULE_DESCRIPTION ("{ip,ip6,arp,eb}_tables backend module" );#define XT_PCPU_BLOCK_SIZE 4096 +#define XT_MAX_TABLE_SIZE (512 * 1024 * 1024)struct compat_delta {unsigned int offset;/* offset in kernel */
@@ -1031,7 +1032,7 @@ struct xt_table_info *xt_alloc_table_infstruct xt_table_info *info =NULL ;size_t sz =sizeof (*info) + size; -if (sz <sizeof (*info)) +if (sz <sizeof (*info) || sz >=XT_MAX_TABLE_SIZE )return NULL ;/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
Greg Kroah-Hartman
maintainerPATCH 175/183 netfilter: x_tables: add counters allocation wrapper
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit c84ca954ac9fa67a6ce27f91f01e4451c74fd8f6 upstream.
allows to have size checks in a single spot.
This is supposed to reduce oom situations when fuzz-testing xtables.
--- include/linux/netfilter/x_tables.h | 1 + net/ipv4/netfilter/arp_tables.c | 2 +- net/ipv4/netfilter/ip_tables.c | 2 +- net/ipv6/netfilter/ip6_tables.c | 2 +- net/netfilter/x_tables.c | 15 +++++++++++++++ 5 files changed, 19 insertions(+), 3 deletions(-)
include/linux/netfilter/x_tables.h +1 -0
@@ -301,6 +301,7 @@ int xt_data_to_user(void __user *dst, covoid *xt_copy_counters_from_user (const void __user *user,unsigned int len,struct xt_counters_info *info,bool compat); +struct xt_counters *xt_counters_alloc (unsigned int counters); struct xt_table *xt_register_table(struct net *net, const struct xt_table *table,
net/ipv4/netfilter/arp_tables.c +1 -1
@@ -883,7 +883,7 @@ static int __do_replace(struct net *net,struct arpt_entry *iter; ret =0 ; - counters =vzalloc (num_counters *sizeof (struct xt_counters )); + counters =xt_counters_alloc (num_counters);if (!counters) { ret = -ENOMEM ; goto out;
net/ipv4/netfilter/ip_tables.c +1 -1
@@ -1044,7 +1044,7 @@ __do_replace(struct net *net, const charstruct ipt_entry *iter; ret =0 ; - counters =vzalloc (num_counters *sizeof (struct xt_counters )); + counters =xt_counters_alloc (num_counters);if (!counters) { ret = -ENOMEM ; goto out;
net/ipv6/netfilter/ip6_tables.c +1 -1
@@ -1063,7 +1063,7 @@ __do_replace(struct net *net, const charstruct ip6t_entry *iter; ret =0 ; - counters =vzalloc (num_counters *sizeof (struct xt_counters )); + counters =xt_counters_alloc (num_counters);if (!counters) { ret = -ENOMEM ; goto out;
net/netfilter/x_tables.c +15 -0
@@ -1187,6 +1187,21 @@ static int xt_jumpstack_alloc(struct xt_return 0 ; } +struct xt_counters *xt_counters_alloc (unsigned int counters) +{ +struct xt_counters *mem; + +if (counters ==0 || counters >INT_MAX /sizeof (*mem)) +return NULL ; + + counters *=sizeof (*mem); +if (counters >XT_MAX_TABLE_SIZE ) +return NULL ; + +return vzalloc (counters); +} +EXPORT_SYMBOL (xt_counters_alloc); +struct xt_table_info * xt_replace_table(struct xt_table *table, unsigned int num_counters,
Greg Kroah-Hartman
maintainerPATCH 176/183 netfilter: compat: prepare xt_compat_init_offsets to return errors
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit 9782a11efc072faaf91d4aa60e9d23553f918029 upstream.
should have no impact, function still always returns 0. This patch is only to ease review.
--- include/linux/netfilter/x_tables.h | 2 +- net/bridge/netfilter/ebtables.c | 10 ++++++++-- net/ipv4/netfilter/arp_tables.c | 10 +++++++--- net/ipv4/netfilter/ip_tables.c | 8 ++++++-- net/ipv6/netfilter/ip6_tables.c | 10 +++++++--- net/netfilter/x_tables.c | 4 +++- 6 files changed, 32 insertions(+), 12 deletions(-)
include/linux/netfilter/x_tables.h +1 -1
@@ -508,7 +508,7 @@ void xt_compat_unlock(u_int8_t af);int xt_compat_add_offset (u_int8_t af,unsigned int offset,int delta);void xt_compat_flush_offsets (u_int8_t af); -void xt_compat_init_offsets (u_int8_t af,unsigned int number); +int xt_compat_init_offsets (u8 af,unsigned int number);int xt_compat_calc_jump (u_int8_t af,unsigned int offset);int xt_compat_match_offset (const struct xt_match *match);
net/bridge/netfilter/ebtables.c +8 -2
@@ -1819,10 +1819,14 @@ static int compat_table_info(const struc {unsigned int size = info->entries_size;const void *entries = info->entries; +int ret; newinfo->entries_size = size; -xt_compat_init_offsets (NFPROTO_BRIDGE , info->nentries); + ret =xt_compat_init_offsets (NFPROTO_BRIDGE , info->nentries); +if (ret) +return ret; +return EBT_ENTRY_ITERATE (entries, size, compat_calc_entry, info, entries, newinfo); }
@@ -2257,7 +2261,9 @@ static int compat_do_replace(struct netxt_compat_lock (NFPROTO_BRIDGE ); -xt_compat_init_offsets (NFPROTO_BRIDGE , tmp.nentries); + ret =xt_compat_init_offsets (NFPROTO_BRIDGE , tmp.nentries); +if (ret <0 ) + goto out_unlock; ret =compat_copy_entries (entries_tmp, tmp.entries_size, &state);if (ret <0 ) goto out_unlock;
net/ipv4/netfilter/arp_tables.c +7 -3
@@ -768,7 +768,9 @@ static int compat_table_info(const strucmemcpy (newinfo, info, offsetof(struct xt_table_info , entries)); newinfo->initial_entries =0 ; loc_cpu_entry = info->entries; -xt_compat_init_offsets (NFPROTO_ARP , info->number); + ret =xt_compat_init_offsets (NFPROTO_ARP , info->number); +if (ret) +return ret; xt_entry_foreach(iter, loc_cpu_entry, info->size) { ret =compat_calc_entry (iter, info, loc_cpu_entry, newinfo);if (ret !=0 )
@@ -1157,7 +1159,7 @@ static int translate_compat_table(structstruct compat_arpt_entry *iter0;struct arpt_replace repl;unsigned int size; -int ret =0 ; +int ret; info = *pinfo; entry0 = *pentry0;
@@ -1166,7 +1168,9 @@ static int translate_compat_table(struct j =0 ;xt_compat_lock (NFPROTO_ARP ); -xt_compat_init_offsets (NFPROTO_ARP , compatr->num_entries); + ret =xt_compat_init_offsets (NFPROTO_ARP , compatr->num_entries); +if (ret) + goto out_unlock;/* Walk through entries, checking offsets. */ xt_entry_foreach(iter0, entry0, compatr->size) { ret = check_compat_entry_size_and_hooks(iter0, info, &size,
net/ipv4/netfilter/ip_tables.c +6 -2
@@ -931,7 +931,9 @@ static int compat_table_info(const strucmemcpy (newinfo, info, offsetof(struct xt_table_info , entries)); newinfo->initial_entries =0 ; loc_cpu_entry = info->entries; -xt_compat_init_offsets (AF_INET , info->number); + ret =xt_compat_init_offsets (AF_INET , info->number); +if (ret) +return ret; xt_entry_foreach(iter, loc_cpu_entry, info->size) { ret =compat_calc_entry (iter, info, loc_cpu_entry, newinfo);if (ret !=0 )
@@ -1407,7 +1409,9 @@ translate_compat_table(struct net *net, j =0 ;xt_compat_lock (AF_INET ); -xt_compat_init_offsets (AF_INET , compatr->num_entries); + ret =xt_compat_init_offsets (AF_INET , compatr->num_entries); +if (ret) + goto out_unlock;/* Walk through entries, checking offsets. */ xt_entry_foreach(iter0, entry0, compatr->size) { ret = check_compat_entry_size_and_hooks(iter0, info, &size,
net/ipv6/netfilter/ip6_tables.c +7 -3
@@ -949,7 +949,9 @@ static int compat_table_info(const strucmemcpy (newinfo, info, offsetof(struct xt_table_info , entries)); newinfo->initial_entries =0 ; loc_cpu_entry = info->entries; -xt_compat_init_offsets (AF_INET6 , info->number); + ret =xt_compat_init_offsets (AF_INET6 , info->number); +if (ret) +return ret; xt_entry_foreach(iter, loc_cpu_entry, info->size) { ret =compat_calc_entry (iter, info, loc_cpu_entry, newinfo);if (ret !=0 )
@@ -1415,7 +1417,7 @@ translate_compat_table(struct net *net,struct compat_ip6t_entry *iter0;struct ip6t_replace repl;unsigned int size; -int ret =0 ; +int ret; info = *pinfo; entry0 = *pentry0;
@@ -1424,7 +1426,9 @@ translate_compat_table(struct net *net, j =0 ;xt_compat_lock (AF_INET6 ); -xt_compat_init_offsets (AF_INET6 , compatr->num_entries); + ret =xt_compat_init_offsets (AF_INET6 , compatr->num_entries); +if (ret) + goto out_unlock;/* Walk through entries, checking offsets. */ xt_entry_foreach(iter0, entry0, compatr->size) { ret = check_compat_entry_size_and_hooks(iter0, info, &size,
net/netfilter/x_tables.c +3 -1
@@ -605,10 +605,12 @@ int xt_compat_calc_jump(u_int8_t af, uns }EXPORT_SYMBOL_GPL (xt_compat_calc_jump); -void xt_compat_init_offsets (u_int8_t af,unsigned int number) +int xt_compat_init_offsets (u8 af,unsigned int number) { xt[af].number = number; xt[af].cur =0 ; + +return 0 ; }EXPORT_SYMBOL (xt_compat_init_offsets);
Greg Kroah-Hartman
maintainerPATCH 177/183 netfilter: compat: reject huge allocation requests
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit 7d7d7e02111e9a4dc9d0658597f528f815d820fd upstream.
no need to bother even trying to allocating huge compat offset arrays, such ruleset is rejected later on anyway becaus we refuse to allocate overly large rule blobs.
However, compat translation happens before blob allocation, so we should add a check there too.
This is supposed to help with fuzzing by avoiding oom-killer.
--- net/netfilter/x_tables.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)
net/netfilter/x_tables.c +18 -8
@@ -555,14 +555,8 @@ int xt_compat_add_offset(u_int8_t af, un {struct xt_af *xp = &xt[af]; -if (!xp->compat_tab) { -if (!xp->number) -return -EINVAL ; - xp->compat_tab =vmalloc (sizeof (struct compat_delta ) * xp->number); -if (!xp->compat_tab) -return -ENOMEM ; - xp->cur =0 ; - } +if (WARN_ON (!xp->compat_tab)) +return -ENOMEM ;if (xp->cur >= xp->number)return -EINVAL ;
@@ -607,6 +601,22 @@ EXPORT_SYMBOL_GPL(xt_compat_calc_jump);int xt_compat_init_offsets (u8 af,unsigned int number) { +size_t mem; + +if (!number || number > (INT_MAX /sizeof (struct compat_delta ))) +return -EINVAL ; + +if (WARN_ON (xt[af].compat_tab)) +return -EINVAL ; + + mem =sizeof (struct compat_delta ) * number; +if (mem >XT_MAX_TABLE_SIZE ) +return -ENOMEM ; + + xt[af].compat_tab =vmalloc (mem); +if (!xt[af].compat_tab) +return -ENOMEM ; + xt[af].number = number; xt[af].cur =0 ;
Greg Kroah-Hartman
maintainerPATCH 178/183 netfilter: x_tables: limit allocation requests for blob rule heads
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit 9d5c12a7c08f67999772065afd50fb222072114e upstream.
This is a very conservative limit (134217728 rules), but good enough to not trigger frequent oom from syzkaller.
--- net/netfilter/x_tables.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/x_tables.c +3 -0
@@ -819,6 +819,9 @@ EXPORT_SYMBOL(xt_check_entry_offsets);*/ unsigned int *xt_alloc_entry_offsets (unsigned int size) { +if (size >XT_MAX_TABLE_SIZE /sizeof (unsigned int )) +return NULL ; +return kvmalloc_array (size,sizeof (unsigned int ),GFP_KERNEL | __GFP_ZERO); }
Greg Kroah-Hartman
maintainerPATCH 179/183 perf: Fix sample_max_stack maximum check
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 5af44ca53d019de47efe6dbc4003dd518e5197ed upstream.
The syzbot hit KASAN bug in perf_callchain_store having the entry stored behind the allocated bounds [1].
We miss the sample_max_stack check for the initial event that allocates callchain buffers. This missing check allows to create an event with sample_max_stack value bigger than the global sysctl maximum:
# sysctl -a | grep perf_event_max_stack kernel.perf_event_max_stack = 127
# perf record -vv -C 1 -e cycles/max-stack=256/ kill
...
perf_event_attr:
size 112
...
sample_max_stack 256
------------------------------------------------------------
sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 4Note the '-C 1', which forces perf record to create just single event. Otherwise it opens event for every cpu, then the sample_max_stack check fails on the second event and all's fine.
The fix is to run the sample_max_stack check also for the first event with callchains.
[1] https://marc.info/?l=linux-kernel&m=152352732920874&w=2
--- kernel/events/callchain.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
kernel/events/callchain.c +12 -9
@@ -119,19 +119,22 @@ int get_callchain_buffers(int event_max_ goto exit; } +/* +* If requesting per event more than the global cap, +* return a different error to help userspace figure +* this out. +* +* And also do it here so that we have &callchain_mutex held. +*/ +if (event_max_stack > sysctl_perf_event_max_stack) { + err = -EOVERFLOW ; + goto exit; + } +if (count >1 ) {/* If the allocation failed, give up */ if (!callchain_cpus_entries) err = -ENOMEM ; -/* -* If requesting per event more than the global cap, -* return a different error to help userspace figure -* this out. -* -* And also do it here so that we have &callchain_mutex held. -*/ -if (event_max_stack > sysctl_perf_event_max_stack) - err = -EOVERFLOW ; goto exit; }
Greg Kroah-Hartman
maintainerPATCH 180/183 perf: Return proper values for user stack errors
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 78b562fbfa2cf0a9fcb23c3154756b690f4905c1 upstream.
Return immediately when we find issue in the user stack checks. The error value could get overwritten by following check for PERF_SAMPLE_REGS_INTR.
--- kernel/events/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/events/core.c +2 -2
@@ -9750,9 +9750,9 @@ static int perf_copy_attr(struct perf_ev* __u16 sample size limit. */ if (attr->sample_stack_user >=USHRT_MAX ) - ret = -EINVAL ; +return -EINVAL ;else if (!IS_ALIGNED (attr->sample_stack_user,sizeof (u64))) - ret = -EINVAL ; +return -EINVAL ; }if (attr->sample_type &PERF_SAMPLE_REGS_INTR )
Greg Kroah-Hartman
maintainerPATCH 181/183 RDMA/mlx5: Fix NULL dereference while accessing XRC_TGT QPs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
commit 75a4598209cbe45540baa316c3b51d9db222e96e upstream.
mlx5 modify_qp() relies on FW that the error will be thrown if wrong state is supplied. The missing check in FW causes the following crash while using XRC_TGT QPs.
[ 14.769632] BUG: unable to handle kernel NULL pointer dereference at (null) [ 14.771085] IP: mlx5_ib_modify_qp+0xf60/0x13f0 [ 14.771894] PGD 800000001472e067 P4D 800000001472e067 PUD 14529067 PMD 0 [ 14.773126] Oops: 0002 [#1] SMP PTI [ 14.773763] CPU: 0 PID: 365 Comm: ubsan Not tainted 4.16.0-rc1-00038-g8151138c0793 #119 [ 14.775192] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 14.777522] RIP: 0010:mlx5_ib_modify_qp+0xf60/0x13f0 [ 14.778417] RSP: 0018:ffffbf48001c7bd8 EFLAGS: 00010246 [ 14.779346] RAX: 0000000000000000 RBX: ffff9a8f9447d400 RCX: 0000000000000000 [ 14.780643] RDX: 0000000000000000 RSI: 000000000000000a RDI: 0000000000000000 [ 14.781930] RBP: 0000000000000000 R08: 00000000000217b0 R09: ffffffffbc9c1504 [ 14.783214] R10: fffff4a180519480 R11: ffff9a8f94523600 R12: ffff9a8f9493e240 [ 14.784507] R13: ffff9a8f9447d738 R14: 000000000000050a R15: 0000000000000000 [ 14.785800] FS: 00007f545b466700(0000) GS:ffff9a8f9fc00000(0000) knlGS:0000000000000000 [ 14.787073] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 14.787792] CR2: 0000000000000000 CR3: 00000000144be000 CR4: 00000000000006b0 [ 14.788689] Call Trace: [ 14.789007] _ib_modify_qp+0x71/0x120 [ 14.789475] modify_qp.isra.20+0x207/0x2f0 [ 14.790010] ib_uverbs_modify_qp+0x90/0xe0 [ 14.790532] ib_uverbs_write+0x1d2/0x3c0 [ 14.791049] ? __handle_mm_fault+0x93c/0xe40 [ 14.791644] __vfs_write+0x36/0x180 [ 14.792096] ? handle_mm_fault+0xc1/0x210 [ 14.792601] vfs_write+0xad/0x1e0 [ 14.793018] SyS_write+0x52/0xc0 [ 14.793422] do_syscall_64+0x75/0x180 [ 14.793888] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 14.794527] RIP: 0033:0x7f545ad76099 [ 14.794975] RSP: 002b:00007ffd78787468 EFLAGS: 00000287 ORIG_RAX: 0000000000000001 [ 14.795958] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f545ad76099 [ 14.797075] RDX: 0000000000000078 RSI: 0000000020009000 RDI: 0000000000000003 [ 14.798140] RBP: 00007ffd78787470 R08: 00007ffd78787480 R09: 00007ffd78787480 [ 14.799207] R10: 00007ffd78787480 R11: 0000000000000287 R12: 00005599ada98760 [ 14.800277] R13: 00007ffd78787560 R14: 0000000000000000 R15: 0000000000000000 [ 14.801341] Code: 4c 8b 1c 24 48 8b 83 70 02 00 00 48 c7 83 cc 02 00 00 00 00 00 00 48 c7 83 24 03 00 00 00 00 00 00 c7 83 2c 03 00 00 00 00 00 00 <c7> 00 00 00 00 00 48 8b 83 70 02 00 00 c7 40 04 00 00 00 00 4c [ 14.804012] RIP: mlx5_ib_modify_qp+0xf60/0x13f0 RSP: ffffbf48001c7bd8 [ 14.804838] CR2: 0000000000000000 [ 14.805288] ---[ end trace 3f1da0df5c8b7c37 ]---
--- drivers/infiniband/hw/mlx5/qp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/hw/mlx5/qp.c +2 -1
@@ -2923,7 +2923,8 @@ static int __mlx5_ib_modify_qp(struct ib* If we moved a kernel QP to RESET, clean up all old CQ * entries and reinitialize the QP. */ -if (new_state ==IB_QPS_RESET && !ibqp->uobject) { +if (new_state ==IB_QPS_RESET && + !ibqp->uobject && ibqp->qp_type !=IB_QPT_XRC_TGT ) {mlx5_ib_cq_clean (recv_cq, base->mqp.qpn, ibqp->srq ?to_msrq (ibqp->srq) :NULL );if (send_cq != recv_cq)
Greg Kroah-Hartman
maintainerPATCH 182/183 Revert "KVM: X86: Fix SMRAM accessing even if VM is shutdown"
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 2c151b25441ae5c2da66472abd165af785c9ecd2 upstream.
The bug that led to commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 was a benign warning (no adverse affects other than the warning itself) that was detected by syzkaller. Further inspection shows that the WARN_ON in question, in handle_ept_misconfig(), is unnecessary and flawed (this was also briefly discussed in the original patch: https://patchwork.kernel.org/patch/10204649).
* The WARN_ON is unnecessary as kvm_mmu_page_fault() will WARN if reserved bits are set in the SPTEs, i.e. it covers the case where an EPT misconfig occurred because of a KVM bug.
* The WARN_ON is flawed because it will fire on any system error code that is hit while handling the fault, e.g. -ENOMEM can be returned by mmu_topup_memory_caches() while handling a legitmate MMIO EPT misconfig.
The original behavior of returning -EFAULT when userspace munmaps an HVA without first removing the memslot is correct and desirable, i.e. KVM is letting userspace know it has generated a bad address. Returning RET_PF_EMULATE masks the WARN_ON in the EPT misconfig path, but does not fix the underlying bug, i.e. the WARN_ON is bogus.
Furthermore, returning RET_PF_EMULATE has the unwanted side effect of causing KVM to attempt to emulate an instruction on any page fault with an invalid HVA translation, e.g. a not-present EPT violation on a VM_PFNMAP VMA whose fault handler failed to insert a PFN.
* There is no guarantee that the fault is directly related to the instruction, i.e. the fault could have been triggered by a side effect memory access in the guest, e.g. while vectoring a #DB or writing a tracing record. This could cause KVM to effectively mask the fault if KVM doesn't model the behavior leading to the fault, i.e. emulation could succeed and resume the guest.
* If emulation does fail, KVM will return EMULATION_FAILED instead of -EFAULT, which is a red herring as the user will either debug a bogus emulation attempt or scratch their head wondering why we were attempting emulation in the first place.
TL;DR: revert to returning -EFAULT and remove the bogus WARN_ON in handle_ept_misconfig in a future patch.
This reverts commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5.
--- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/mmu.c +1 -1
@@ -3019,7 +3019,7 @@ static int kvm_handle_bad_page(struct kvreturn RET_PF_RETRY ; } -return RET_PF_EMULATE ; +return -EFAULT ; } static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu,
Greg Kroah-Hartman
maintainerPATCH 183/183 mac80211_hwsim: fix use-after-free bug in hwsim_exit_net
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Beichler <[email protected]>
commit 8cfd36a0b53aeb4ec21d81eb79706697b84dfc3d upstream.
When destroying a net namespace, all hwsim interfaces, which are not created in default namespace are deleted. But the async deletion of the interfaces could last longer than the actual destruction of the namespace, which results to an use after free bug. Therefore use synchronous deletion in this case.
--- drivers/net/wireless/mac80211_hwsim.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/wireless/mac80211_hwsim.c +5 -2
@@ -3427,8 +3427,11 @@ static void __net_exit hwsim_exit_net(stcontinue ;list_del (&data->list); -INIT_WORK (&data->destroy_work, destroy_radio); -schedule_work (&data->destroy_work); +spin_unlock_bh (&hwsim_radio_lock); +mac80211_hwsim_del_radio (data,wiphy_name (data->hw->wiphy), +NULL ); +spin_lock_bh (&hwsim_radio_lock); + }spin_unlock_bh (&hwsim_radio_lock); }
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
Build results:
total: 146 pass: 145 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 141 pass: 141 fail: 0
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_report_resume':arch/powerpc/kernel/eeh_driver.c:395:13: error: 'struct eeh_ops' has no member named 'notify_resume'
Details are available at http://kerneltests.org/builders/.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
Build results:
Quoted 8 lines
total: 146 pass: 145 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 141 pass: 141 fail: 0
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_report_resume':arch/powerpc/kernel/eeh_driver.c:395:13: error: 'structeeh_ops' has no member named 'notify_resume'
Thanks for the report, I've now dropped the offending patch.
greg k-h
Quoted 17 lines · Greg Kroah-Hartman
Quoted 16 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
Build results:
total: 146 pass: 145 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 141 pass: 141 fail: 0
Quoted 5 lines
Quoted 2 lines
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_report_resume':arch/powerpc/kernel/eeh_driver.c:395:13: error: 'structeeh_ops' has no member named 'notify_resume'Thanks for the report, I've now dropped the offending patch.
For v4.14.36-183-g55d212d:
Build results:
total: 146 pass: 146 fail: 0 Qemu test results: total: 141 pass: 141 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 24 lines · Guenter Roeck
Quoted 17 lines · Greg Kroah-Hartman
Quoted 16 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
Build results:
total: 146 pass: 145 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 141 pass: 141 fail: 0Quoted 5 lines
Quoted 2 lines
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_report_resume':arch/powerpc/kernel/eeh_driver.c:395:13: error: 'structeeh_ops' has no member named 'notify_resume'Thanks for the report, I've now dropped the offending patch.
Quoted 6 lines
For v4.14.36-183-g55d212d:
Build results:
total: 146 pass: 146 fail: 0 Qemu test results: total: 141 pass: 141 fail: 0
Great! Thanks for testing and letting me know.
greg k-h
stable-rc/linux-4.14.y boot: 155 boots: 4 failed, 133 passed with 16 offline, 2 conflicts (v4.14.36-184-g3cd53e436ee2)
stable-rc/linux-4.14.y boot: 155 boots: 4 failed, 133 passed with 16 offline, 2 conflicts (v4.14.36-184-g3cd53e436ee2)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.36-184-g3cd53e436ee2/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.36-184-g3cd53e436ee2/
Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.36-184-g3cd53e436ee2
Git Commit: 3cd53e436ee26a473b4055caa62e594ff14b7511
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 79 unique boards, 24 SoC families, 17 builds out of 185
Boot Regressions Detected:
arm:
multi_v7_defconfig:
dra7-evm:
lab-baylibre: new failure (last pass: v4.14.36)
sun8i-a33-sinlinx-sina33:
lab-free-electrons: new failure (last pass: v4.14.36)
omap2plus_defconfig:
dra7-evm:
lab-baylibre: failing since 1 day (last pass: v4.14.26 - first fail: v4.14.36)
sama5_defconfig:
at91-sama5d4_xplained:
lab-free-electrons: new failure (last pass: v4.14.36)
sunxi_defconfig:
sun8i-a83t-allwinner-h8homlet-v2:
lab-free-electrons: new failure (last pass: v4.14.36)arm64:
defconfig:
meson-gxl-s905x-khadas-vim:
lab-baylibre: new failure (last pass: v4.14.26-140-g2a1700a4929f)Boot Failures Detected:
arm:
omap2plus_defconfig
dra7-evm: 1 failed lab
multi_v7_defconfig
dra7-evm: 1 failed lab
sun8i-a33-sinlinx-sina33: 1 failed lab
sunxi_defconfig
sun8i-a83t-allwinner-h8homlet-v2: 1 failed lab
Offline Platforms:
arm:
tegra_defconfig:
tegra20-iris-512: 1 offline lab
multi_v7_defconfig:
meson8b-odroidc1: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
tegra20-iris-512: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
imx_v6_v7_defconfig:
vf610-colibri-eval-v3: 1 offline lab
davinci_all_defconfig:
da850-lcdk: 1 offline lab
qcom_defconfig:
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline labarm64:
defconfig:
apq8016-sbc: 1 offline lab
meson-gxbb-odroidc2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
meson-gxl-s905x-nexbox-a95x: 1 offline lab
meson-gxl-s905x-p212: 1 offline lab
rk3399-firefly: 1 offline labConflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm:
sama5_defconfig:
at91-sama5d4_xplained:
lab-free-electrons: FAIL
lab-baylibre-seattle: PASSarm64:
defconfig:
meson-gxl-s905x-khadas-vim:
lab-baylibre-seattle: PASS
lab-baylibre: FAIL---
For more info write to <[email protected]>
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.37-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Merged, compiled, and installed onto my Raspberry Pi 3.
No initial issues noticed in dmesg or general usage.
Thanks!
Nathan
Greg Kroah-Hartman
maintainerQuoted 15 lines · Nathan Chancellor
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.37-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 4 lines
thanks,
greg k-h
Merged, compiled, and installed onto my Raspberry Pi 3.
No initial issues noticed in dmesg or general usage.
Thanks for testing and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.37-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.37 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Fri Apr 27 10:32:04 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.37-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
There is one regression noted in the report, which is a timing test that sometimes fails under qemu due to competing load on the host system.
Summary
------------------------------------------------------------------------
kernel: 4.14.37-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 55d212d6a1d3e81a94c486e25cecc173af1fec29
git describe: v4.14.36-183-g55d212d6a1d3
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.36-183-g55d212d6a1d3
Regressions (compared to build v4.14.36-184-g3cd53e436ee2)
------------------------------------------------------------------------
qemu_arm64:
kselftest:
* set-timer-lat
* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.16.tar.xz
Boards, architectures and test suites:
-------------------------------------
dragonboard-410c
* boot - pass: 21, fail: 1,
* kselftest - pass: 41, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 2032, skip: 268
* ltp-timers-tests - pass: 13,
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 44, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1015, skip: 135
* ltp-timers-tests - pass: 13,
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 43, skip: 25
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1016, skip: 134
* ltp-timers-tests - pass: 13,
qemu_arm
* boot - pass: 16, fail: 4,
* kselftest - pass: 37, fail: 2, skip: 29
* libhugetlbfs - pass: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 62, fail: 2, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-fs-tests - pass: 58, skip: 5
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-ipc-tests - pass: 9,
* ltp-nptl-tests - pass: 2,
* ltp-securebits-tests - pass: 4,
qemu_arm64
* boot - pass: 23,
* kselftest - pass: 40, fail: 1, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 460, fail: 1, skip: 54
* ltp-timers-tests - pass: 13,
qemu_x86_64
* boot - pass: 22,
* kselftest - pass: 50, skip: 30
* kselftest-vsyscall-mode-native - pass: 50, skip: 30
* kselftest-vsyscall-mode-none - pass: 50, skip: 30
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 998, skip: 152
* ltp-timers-tests - pass: 13,
x15 - arm
* boot - pass: 20,
* kselftest - pass: 37, fail: 2, skip: 26
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 58, skip: 5
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1075, skip: 75
* ltp-timers-tests - pass: 13,
x86_64
* boot - pass: 22,
* kselftest - pass: 54, skip: 22
* kselftest-vsyscall-mode-native - pass: 53, fail: 1, skip: 21
* kselftest-vsyscall-mode-none - pass: 54, skip: 22
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 58, skip: 5
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1034, skip: 116
* ltp-timers-tests - pass: 13,
Signature · 2 lines
Linaro QA (BETA) https://qa-reports.linaro.org