Home| summaryrefslogtreecommitdiff |
diff options
| author | Kernel Build Daemon <kbuild@suse.de> | 2019-10-08 07:24:39 +0200 |
|---|---|---|
| committer | Kernel Build Daemon <kbuild@suse.de> | 2019-10-08 07:24:39 +0200 |
| commit | 8fa306690f3a2397a832d25fcbdfefa7d1f3b4a0 (patch) | |
| tree | b9414053ce28320f64d86380b4ac564bc5c6c061 | |
| parent | e642f4e59626c3f94f2fbe01c7a7926e19d408c8 (diff) | |
| parent | 8ef2efd630f1145eb3410e1e8d0d08389dc28301 (diff) | |
Merge branch 'SLE15-SP1' into SLE15-SP1-AZURErpm-4.12.14-8.16--sle15-sp1-updatesrpm-4.12.14-8.16
18 files changed, 1213 insertions, 354 deletions
diff --git a/blacklist.conf b/blacklist.conf index 9a2a661da3..8ad267f6c1 100644 --- a/blacklist.conf +++ b/blacklist.conf @@ -544,6 +544,7 @@ d125f3f866df88da5a85df00291f88f0baa89f7c # ftrace: see above 8114865ff82e200b383 b1b35f2e218a5b57d03bbc3b0667d5064570dc60 # ftrace: see above 8114865ff82e200b383 3cec638b3d793b7cacdec5b8072364b41caeb0e1 # ftrace: memory leak when set_trigger_filter() fails; should not normally happen; not worth it 2840f84f74035e5a535959d5f17269c69fa6edc5 # ftrace: memory leak in pretty advanced scenario +9f255b632bf12c4dd7fc31caee89aa991ef75176 # livepatch/ftrace: fixes a potential deadlock when loading livepatch and another module in parallel; rather theoretical; also opens can of worms with other possible deadlocks; more than 6 locks involved; see bsc#1152325 7a68d9fb851012829c29e770621905529bd9490b # breaks KABI 81e0403b26d94360abd1f6a57311337973bc82cd # useless without patch breaking kABI diff --git a/patches.kabi/kabi-fix-vmem_altmap.patch b/patches.kabi/kabi-fix-vmem_altmap.patch new file mode 100644 index 0000000000..9d1cb286ba --- /dev/null +++ b/patches.kabi/kabi-fix-vmem_altmap.patch @@ -0,0 +1,33 @@ +From: Johannes Thumshirn <jthumshirn@suse.de> +Date: Mon 7 Oct 13:04:57 CEST 2019 +Subject: KABI protect struct vmem_altmap +References: bsc#1150305 +Patch-mainline: Never, KABI fix + +The patch patches.suse/libnvdimm-altmap-track-namespace-boundaries-in-altmap.patch +introduced a new field 'end_pfn' in struct vmem_altmap. + +Move this field to the end of the struct and guard it by __GENKSYMS__. + +Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> +--- + include/linux/memremap.h | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/include/linux/memremap.h ++++ b/include/linux/memremap.h +@@ -18,11 +18,13 @@ struct device; + */ + struct vmem_altmap { + const unsigned long base_pfn; +- const unsigned long end_pfn; + const unsigned long reserve; + unsigned long free; + unsigned long align; + unsigned long alloc; ++#ifndef __GENKSYMS__ ++ const unsigned long end_pfn; ++#endif + }; + + /* diff --git a/patches.suse/0001-btrfs-qgroup-Fix-the-wrong-target-io_tree-when-freei.patch b/patches.suse/0001-btrfs-qgroup-Fix-the-wrong-target-io_tree-when-freei.patch new file mode 100644 index 0000000000..f0973886fb --- /dev/null +++ b/patches.suse/0001-btrfs-qgroup-Fix-the-wrong-target-io_tree-when-freei.patch @@ -0,0 +1,84 @@ +From bab32fc069ce8829c416e8737c119f62a57970f9 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo <wqu@suse.com> +Date: Mon, 16 Sep 2019 20:02:38 +0800 +Patch-mainline: v5.4-rc1 +Git-commit: bab32fc069ce8829c416e8737c119f62a57970f9 +References: bsc#1152974 +Subject: [PATCH 1/2] btrfs: qgroup: Fix the wrong target io_tree when freeing + reserved data space + +[BUG] +Under the following case with qgroup enabled, if some error happened +after we have reserved delalloc space, then in error handling path, we +could cause qgroup data space leakage: + +From btrfs_truncate_block() in inode.c: + + ret = btrfs_delalloc_reserve_space(inode, &data_reserved, + block_start, blocksize); + if (ret) + goto out; + + again: + page = find_or_create_page(mapping, index, mask); + if (!page) { + btrfs_delalloc_release_space(inode, data_reserved, + block_start, blocksize, true); + btrfs_delalloc_release_extents(BTRFS_I(inode), blocksize, true); + ret = -ENOMEM; + goto out; + } + +[CAUSE] +In the above case, btrfs_delalloc_reserve_space() will call +btrfs_qgroup_reserve_data() and mark the io_tree range with +EXTENT_QGROUP_RESERVED flag. + +In the error handling path, we have the following call stack: +btrfs_delalloc_release_space() +|- btrfs_free_reserved_data_space() + |- btrsf_qgroup_free_data() + |- __btrfs_qgroup_release_data(reserved=@reserved, free=1) + |- qgroup_free_reserved_data(reserved=@reserved) + |- clear_record_extent_bits(); + |- freed += changeset.bytes_changed; + +However due to a completion bug, qgroup_free_reserved_data() will clear +EXTENT_QGROUP_RESERVED flag in BTRFS_I(inode)->io_failure_tree, other +than the correct BTRFS_I(inode)->io_tree. +Since io_failure_tree is never marked with that flag, +btrfs_qgroup_free_data() will not free any data reserved space at all, +causing a leakage. + +This type of error handling can only be triggered by errors outside of +qgroup code. So EDQUOT error from qgroup can't trigger it. + +[FIX] +Fix the wrong target io_tree. + +Reported-by: Josef Bacik <josef@toxicpanda.com> +Fixes: bc42bda22345 ("btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges") +CC: stable@vger.kernel.org # 4.14+ +Reviewed-by: Nikolay Borisov <nborisov@suse.com> +Signed-off-by: Qu Wenruo <wqu@suse.com> +Signed-off-by: David Sterba <dsterba@suse.com> +--- + fs/btrfs/qgroup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c +index 52701c1be109..4ab85555a947 100644 +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -3486,7 +3486,7 @@ static int qgroup_free_reserved_data(struct inode *inode, + * EXTENT_QGROUP_RESERVED, we won't double free. + * So not need to rush. + */ +- ret = clear_record_extent_bits(&BTRFS_I(inode)->io_failure_tree, ++ ret = clear_record_extent_bits(&BTRFS_I(inode)->io_tree, + free_start, free_start + free_len - 1, + EXTENT_QGROUP_RESERVED, &changeset); + if (ret < 0) +-- +2.23.0 + diff --git a/patches.suse/0001-btrfs-relocation-fix-use-after-free-on-dead-relocati.patch b/patches.suse/0001-btrfs-relocation-fix-use-after-free-on-dead-relocati.patch new file mode 100644 index 0000000000..24474dfcdb --- /dev/null +++ b/patches.suse/0001-btrfs-relocation-fix-use-after-free-on-dead-relocati.patch @@ -0,0 +1,212 @@ +From 1fac4a54374f7ef385938f3c6cf7649c0fe4f6cd Mon Sep 17 00:00:00 2001 +From: Qu Wenruo <wqu@suse.com> +Date: Mon, 23 Sep 2019 14:56:14 +0800 +Patch-mainline: v5.4-rc1 +Git-commit: 1fac4a54374f7ef385938f3c6cf7649c0fe4f6cd +References: bsc#1152972 +Subject: [PATCH] btrfs: relocation: fix use-after-free on dead relocation + roots + +[BUG] +One user reported a reproducible KASAN report about use-after-free: + + BTRFS info (device sdi1): balance: start -dvrange=1256811659264..1256811659265 + BTRFS info (device sdi1): relocating block group 1256811659264 flags data|raid0 + ================================================================== + BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2cd/0x340 [btrfs] + Write of size 8 at addr ffff88856f671710 by task kworker/u24:10/261579 + + CPU: 2 PID: 261579 Comm: kworker/u24:10 Tainted: P OE 5.2.11-arch1-1-kasan #4 + Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X99 Extreme4, BIOS P3.80 04/06/2018 + Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] + Call Trace: + dump_stack+0x7b/0xba + print_address_description+0x6c/0x22e + ? btrfs_init_reloc_root+0x2cd/0x340 [btrfs] + __kasan_report.cold+0x1b/0x3b + ? btrfs_init_reloc_root+0x2cd/0x340 [btrfs] + kasan_report+0x12/0x17 + __asan_report_store8_noabort+0x17/0x20 + btrfs_init_reloc_root+0x2cd/0x340 [btrfs] + record_root_in_trans+0x2a0/0x370 [btrfs] + btrfs_record_root_in_trans+0xf4/0x140 [btrfs] + start_transaction+0x1ab/0xe90 [btrfs] + btrfs_join_transaction+0x1d/0x20 [btrfs] + btrfs_finish_ordered_io+0x7bf/0x18a0 [btrfs] + ? lock_repin_lock+0x400/0x400 + ? __kmem_cache_shutdown.cold+0x140/0x1ad + ? btrfs_unlink_subvol+0x9b0/0x9b0 [btrfs] + finish_ordered_fn+0x15/0x20 [btrfs] + normal_work_helper+0x1bd/0xca0 [btrfs] + ? process_one_work+0x819/0x1720 + ? kasan_check_read+0x11/0x20 + btrfs_endio_write_helper+0x12/0x20 [btrfs] + process_one_work+0x8c9/0x1720 + ? pwq_dec_nr_in_flight+0x2f0/0x2f0 + ? worker_thread+0x1d9/0x1030 + worker_thread+0x98/0x1030 + kthread+0x2bb/0x3b0 + ? process_one_work+0x1720/0x1720 + ? kthread_park+0x120/0x120 + ret_from_fork+0x35/0x40 + + Allocated by task 369692: + __kasan_kmalloc.part.0+0x44/0xc0 + __kasan_kmalloc.constprop.0+0xba/0xc0 + kasan_kmalloc+0x9/0x10 + kmem_cache_alloc_trace+0x138/0x260 + btrfs_read_tree_root+0x92/0x360 [btrfs] + btrfs_read_fs_root+0x10/0xb0 [btrfs] + create_reloc_root+0x47d/0xa10 [btrfs] + btrfs_init_reloc_root+0x1e2/0x340 [btrfs] + record_root_in_trans+0x2a0/0x370 [btrfs] + btrfs_record_root_in_trans+0xf4/0x140 [btrfs] + start_transaction+0x1ab/0xe90 [btrfs] + btrfs_start_transaction+0x1e/0x20 [btrfs] + __btrfs_prealloc_file_range+0x1c2/0xa00 [btrfs] + btrfs_prealloc_file_range+0x13/0x20 [btrfs] + prealloc_file_extent_cluster+0x29f/0x570 [btrfs] + relocate_file_extent_cluster+0x193/0xc30 [btrfs] + relocate_data_extent+0x1f8/0x490 [btrfs] + relocate_block_group+0x600/0x1060 [btrfs] + btrfs_relocate_block_group+0x3a0/0xa00 [btrfs] + btrfs_relocate_chunk+0x9e/0x180 [btrfs] + btrfs_balance+0x14e4/0x2fc0 [btrfs] + btrfs_ioctl_balance+0x47f/0x640 [btrfs] + btrfs_ioctl+0x119d/0x8380 [btrfs] + do_vfs_ioctl+0x9f5/0x1060 + ksys_ioctl+0x67/0x90 + __x64_sys_ioctl+0x73/0xb0 + do_syscall_64+0xa5/0x370 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + Freed by task 369692: + __kasan_slab_free+0x14f/0x210 + kasan_slab_free+0xe/0x10 + kfree+0xd8/0x270 + btrfs_drop_snapshot+0x154c/0x1eb0 [btrfs] + clean_dirty_subvols+0x227/0x340 [btrfs] + relocate_block_group+0x972/0x1060 [btrfs] + btrfs_relocate_block_group+0x3a0/0xa00 [btrfs] + btrfs_relocate_chunk+0x9e/0x180 [btrfs] + btrfs_balance+0x14e4/0x2fc0 [btrfs] + btrfs_ioctl_balance+0x47f/0x640 [btrfs] + btrfs_ioctl+0x119d/0x8380 [btrfs] + do_vfs_ioctl+0x9f5/0x1060 + ksys_ioctl+0x67/0x90 + __x64_sys_ioctl+0x73/0xb0 + do_syscall_64+0xa5/0x370 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + The buggy address belongs to the object at ffff88856f671100 + which belongs to the cache kmalloc-4k of size 4096 + The buggy address is located 1552 bytes inside of + 4096-byte region [ffff88856f671100, ffff88856f672100) + The buggy address belongs to the page: + page:ffffea0015bd9c00 refcount:1 mapcount:0 mapping:ffff88864400e600 index:0x0 compound_mapcount: 0 + flags: 0x2ffff0000010200(slab|head) + raw: 02ffff0000010200 dead000000000100 dead000000000200 ffff88864400e600 + raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000 + page dumped because: kasan: bad access detected + + Memory state around the buggy address: + ffff88856f671600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88856f671680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + >ffff88856f671700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ^ + ffff88856f671780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88856f671800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ================================================================== + BTRFS info (device sdi1): 1 enospc errors during balance + BTRFS info (device sdi1): balance: ended with status: -28 + +[CAUSE] +The problem happens when finish_ordered_io() get called with balance +still running, while the reloc root of that subvolume is already dead. +(Tree is swap already done, but tree not yet deleted for possible qgroup +usage.) + +That means root->reloc_root still exists, but that reloc_root can be +under btrfs_drop_snapshot(), thus we shouldn't access it. + +The following race could cause the use-after-free problem: + + CPU1 | CPU2 +-------------------------------------------------------------------------- + | relocate_block_group() + | |- unset_reloc_control(rc) + | |- btrfs_commit_transaction() +btrfs_finish_ordered_io() | |- clean_dirty_subvols() +|- btrfs_join_transaction() | | + |- record_root_in_trans() | | + |- btrfs_init_reloc_root() | | + |- if (root->reloc_root) | | + | | |- root->reloc_root = NULL + | | |- btrfs_drop_snapshot(reloc_root); + |- reloc_root->last_trans| + = trans->transid | + ^^^^^^^^^^^^^^^^^^^^^^ + Use after free + +[FIX] +Fix it by the following modifications: + +- Test if the root has dead reloc tree before accessing root->reloc_root + If the root has BTRFS_ROOT_DEAD_RELOC_TREE, then we don't need to + create or update root->reloc_tree + +- Clear the BTRFS_ROOT_DEAD_RELOC_TREE flag until we have fully dropped + reloc tree + To co-operate with above modification, so as long as + BTRFS_ROOT_DEAD_RELOC_TREE is still set, we won't try to re-create + reloc tree at record_root_in_trans(). + +Reported-by: Cebtenzzre <cebtenzzre@gmail.com> +Fixes: d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots") +CC: stable@vger.kernel.org # 5.1+ +Reviewed-by: Josef Bacik <josef@toxicpanda.com> +Reviewed-by: Filipe Manana <fdmanana@suse.com> +Signed-off-by: Qu Wenruo <wqu@suse.com> +Reviewed-by: David Sterba <dsterba@suse.com> +Signed-off-by: David Sterba <dsterba@suse.com> +--- + fs/btrfs/relocation.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c +index 2f0e25afa486..00504657b602 100644 +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -1435,6 +1435,13 @@ int btrfs_init_reloc_root(struct btrfs_trans_handle *trans, + int clear_rsv = 0; + int ret; + ++ /* ++ * The subvolume has reloc tree but the swap is finished, no need to ++ * create/update the dead reloc tree ++ */ ++ if (test_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state)) ++ return 0; ++ + if (root->reloc_root) { + reloc_root = root->reloc_root; + reloc_root->last_trans = trans->transid; +@@ -2187,7 +2194,6 @@ static int clean_dirty_subvols(struct reloc_control *rc) + /* Merged subvolume, cleanup its reloc root */ + struct btrfs_root *reloc_root = root->reloc_root; + +- clear_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state); + list_del_init(&root->reloc_dirty_list); + root->reloc_root = NULL; + if (reloc_root) { +@@ -2196,6 +2202,7 @@ static int clean_dirty_subvols(struct reloc_control *rc) + if (ret2 < 0 && !ret) + ret = ret2; + } ++ clear_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state); + btrfs_put_fs_root(root); + } else { + /* Orphan reloc tree, just clean it up */ +-- +2.23.0 + diff --git a/patches.suse/0001-xen-netfront-do-not-use-0U-as-error-return-value-for.patch b/patches.suse/0001-xen-netfront-do-not-use-0U-as-error-return-value-for.patch new file mode 100644 index 0000000000..53915468b5 --- /dev/null +++ b/patches.suse/0001-xen-netfront-do-not-use-0U-as-error-return-value-for.patch @@ -0,0 +1,99 @@ +Patch-mainline: v5.4-rc2 +Git-commit: a761129e3625688310aecf26e1be9e98e85f8eb5 +References: bsc#1065600 +From: Dongli Zhang <dongli.zhang@oracle.com> +Date: Tue, 1 Oct 2019 21:56:41 +0800 +Subject: [PATCH] xen-netfront: do not use ~0U as error return value for + xennet_fill_frags() + +xennet_fill_frags() uses ~0U as return value when the sk_buff is not able +to cache extra fragments. This is incorrect because the return type of +xennet_fill_frags() is RING_IDX and 0xffffffff is an expected value for +ring buffer index. + +In the situation when the rsp_cons is approaching 0xffffffff, the return +value of xennet_fill_frags() may become 0xffffffff which xennet_poll() (the +caller) would regard as error. As a result, queue->rx.rsp_cons is set +incorrectly because it is updated only when there is error. If there is no +error, xennet_poll() would be responsible to update queue->rx.rsp_cons. +Finally, queue->rx.rsp_cons would point to the rx ring buffer entries whose +queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL. +This leads to NULL pointer access in the next iteration to process rx ring +buffer entries. + +The symptom is similar to the one fixed in +commit 00b368502d18 ("xen-netfront: do not assume sk_buff_head list is +empty in error handling"). + +This patch changes the return type of xennet_fill_frags() to indicate +whether it is successful or failed. The queue->rx.rsp_cons will be +always updated inside this function. + +Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") +Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> +Reviewed-by: Juergen Gross <jgross@suse.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Juergen Gross <jgross@suse.com> +--- + drivers/net/xen-netfront.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c +index e14ec75b61d6..482c6c8b0fb7 100644 +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -887,9 +887,9 @@ static int xennet_set_skb_gso(struct sk_buff *skb, + return 0; + } + +-static RING_IDX xennet_fill_frags(struct netfront_queue *queue, +- struct sk_buff *skb, +- struct sk_buff_head *list) ++static int xennet_fill_frags(struct netfront_queue *queue, ++ struct sk_buff *skb, ++ struct sk_buff_head *list) + { + RING_IDX cons = queue->rx.rsp_cons; + struct sk_buff *nskb; +@@ -908,7 +908,7 @@ static RING_IDX xennet_fill_frags(struct netfront_queue *queue, + if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) { + queue->rx.rsp_cons = ++cons + skb_queue_len(list); + kfree_skb(nskb); +- return ~0U; ++ return -ENOENT; + } + + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, +@@ -919,7 +919,9 @@ static RING_IDX xennet_fill_frags(struct netfront_queue *queue, + kfree_skb(nskb); + } + +- return cons; ++ queue->rx.rsp_cons = cons; ++ ++ return 0; + } + + static int checksum_setup(struct net_device *dev, struct sk_buff *skb) +@@ -1045,8 +1047,7 @@ static int xennet_poll(struct napi_struct *napi, int budget) + skb->data_len = rx->status; + skb->len += rx->status; + +- i = xennet_fill_frags(queue, skb, &tmpq); +- if (unlikely(i == ~0U)) ++ if (unlikely(xennet_fill_frags(queue, skb, &tmpq))) + goto err; + + if (rx->flags & XEN_NETRXF_csum_blank) +@@ -1056,7 +1057,7 @@ static int xennet_poll(struct napi_struct *napi, int budget) + + __skb_queue_tail(&rxq, skb); + +- queue->rx.rsp_cons = ++i; ++ i = ++queue->rx.rsp_cons; + work_done++; + } + +-- +2.16.4 + diff --git a/patches.suse/0001-xen-xenbus-fix-self-deadlock-after-killing-user-proc.patch b/patches.suse/0001-xen-xenbus-fix-self-deadlock-after-killing-user-proc.patch new file mode 100644 index 0000000000..30bb788a40 --- /dev/null +++ b/patches.suse/0001-xen-xenbus-fix-self-deadlock-after-killing-user-proc.patch @@ -0,0 +1,113 @@ +Patch-mainline: v5.4-rc2 +Git-commit: a8fabb38525c51a094607768bac3ba46b3f4a9d5 +References: bsc#1065600 +From: Juergen Gross <jgross@suse.com> +Date: Tue, 1 Oct 2019 17:03:55 +0200 +Subject: [PATCH] xen/xenbus: fix self-deadlock after killing user process + +In case a user process using xenbus has open transactions and is killed +e.g. via ctrl-C the following cleanup of the allocated resources might +result in a deadlock due to trying to end a transaction in the xenbus +worker thread: + +[ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds. +[ 2551.492215] Tainted: P OE 5.0.0-29-generic #5 +[ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +[ 2551.528585] xenbus D 0 37 2 0x80000080 +[ 2551.528590] Call Trace: +[ 2551.528603] __schedule+0x2c0/0x870 +[ 2551.528606] ? _cond_resched+0x19/0x40 +[ 2551.528632] schedule+0x2c/0x70 +[ 2551.528637] xs_talkv+0x1ec/0x2b0 +[ 2551.528642] ? wait_woken+0x80/0x80 +[ 2551.528645] xs_single+0x53/0x80 +[ 2551.528648] xenbus_transaction_end+0x3b/0x70 +[ 2551.528651] xenbus_file_free+0x5a/0x160 +[ 2551.528654] xenbus_dev_queue_reply+0xc4/0x220 +[ 2551.528657] xenbus_thread+0x7de/0x880 +[ 2551.528660] ? wait_woken+0x80/0x80 +[ 2551.528665] kthread+0x121/0x140 +[ 2551.528667] ? xb_read+0x1d0/0x1d0 +[ 2551.528670] ? kthread_park+0x90/0x90 +[ 2551.528673] ret_from_fork+0x35/0x40 + +Fix this by doing the cleanup via a workqueue instead. + +Reported-by: James Dingwall <james@dingwall.me.uk> +Fixes: fd8aa9095a95c ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") +Cc: <stable@vger.kernel.org> # 4.11 +Signed-off-by: Juergen Gross <jgross@suse.com> +Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> +Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> +--- + drivers/xen/xenbus/xenbus_dev_frontend.c | 20 ++++++++++++++++++-- + 1 file changed, 18 insertions(+), 2 deletions(-) + +diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c +index 08adc590f631..597af455a522 100644 +--- a/drivers/xen/xenbus/xenbus_dev_frontend.c ++++ b/drivers/xen/xenbus/xenbus_dev_frontend.c +@@ -55,6 +55,7 @@ + #include <linux/string.h> + #include <linux/slab.h> + #include <linux/miscdevice.h> ++#include <linux/workqueue.h> + + #include <xen/xenbus.h> + #include <xen/xen.h> +@@ -116,6 +117,8 @@ struct xenbus_file_priv { + wait_queue_head_t read_waitq; + + struct kref kref; ++ ++ struct work_struct wq; + }; + + /* Read out any raw xenbus messages queued up. */ +@@ -300,14 +303,14 @@ static void watch_fired(struct xenbus_watch *watch, + mutex_unlock(&adap->dev_data->reply_mutex); + } + +-static void xenbus_file_free(struct kref *kref) ++static void xenbus_worker(struct work_struct *wq) + { + struct xenbus_file_priv *u; + struct xenbus_transaction_holder *trans, *tmp; + struct watch_adapter *watch, *tmp_watch; + struct read_buffer *rb, *tmp_rb; + +- u = container_of(kref, struct xenbus_file_priv, kref); ++ u = container_of(wq, struct xenbus_file_priv, wq); + + /* + * No need for locking here because there are no other users, +@@ -333,6 +336,18 @@ static void xenbus_file_free(struct kref *kref) + kfree(u); + } + ++static void xenbus_file_free(struct kref *kref) ++{ ++ struct xenbus_file_priv *u; ++ ++ /* ++ * We might be called in xenbus_thread(). ++ * Use workqueue to avoid deadlock. ++ */ ++ u = container_of(kref, struct xenbus_file_priv, kref); ++ schedule_work(&u->wq); ++} ++ + static struct xenbus_transaction_holder *xenbus_get_transaction( + struct xenbus_file_priv *u, uint32_t tx_id) + { +@@ -650,6 +665,7 @@ static int xenbus_file_open(struct inode *inode, struct file *filp) + INIT_LIST_HEAD(&u->watches); + INIT_LIST_HEAD(&u->read_buffers); + init_waitqueue_head(&u->read_waitq); ++ INIT_WORK(&u->wq, xenbus_worker); + + mutex_init(&u->reply_mutex); + mutex_init(&u->msgbuffer_mutex); +-- +2.16.4 + diff --git a/patches.suse/0002-btrfs-qgroup-Fix-reserved-data-space-leak-if-we-have.patch b/patches.suse/0002-btrfs-qgroup-Fix-reserved-data-space-leak-if-we-have.patch new file mode 100644 index 0000000000..cba19a4188 --- /dev/null +++ b/patches.suse/0002-btrfs-qgroup-Fix-reserved-data-space-leak-if-we-have.patch @@ -0,0 +1,90 @@ +From d4e204948fe3e0dc8e1fbf3f8f3290c9c2823be3 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo <wqu@suse.com> +Date: Mon, 16 Sep 2019 20:02:39 +0800 +Patch-mainline: v5.4-rc1 +Git-commit: d4e204948fe3e0dc8e1fbf3f8f3290c9c2823be3 +References: bsc#1152975 +Subject: [PATCH 2/2] btrfs: qgroup: Fix reserved data space leak if we have + multiple reserve calls + +[BUG] +The following script can cause btrfs qgroup data space leak: + + mkfs.btrfs -f $dev + mount $dev -o nospace_cache $mnt + + btrfs subv create $mnt/subv + btrfs quota en $mnt + btrfs quota rescan -w $mnt + btrfs qgroup limit 128m $mnt/subv + + for (( i = 0; i < 3; i++)); do + # Create 3 64M holes for latter fallocate to fail + truncate -s 192m $mnt/subv/file + xfs_io -c "pwrite 64m 4k" $mnt/subv/file > /dev/null + xfs_io -c "pwrite 128m 4k" $mnt/subv/file > /dev/null + sync + + # it's supposed to fail, and each failure will leak at least 64M + # data space + xfs_io -f -c "falloc 0 192m" $mnt/subv/file &> /dev/null + rm $mnt/subv/file + sync + done + + # Shouldn't fail after we removed the file + xfs_io -f -c "falloc 0 64m" $mnt/subv/file + +[CAUSE] +Btrfs qgroup data reserve code allow multiple reservations to happen on +a single extent_changeset: +E.g: + btrfs_qgroup_reserve_data(inode, &data_reserved, 0, SZ_1M); + btrfs_qgroup_reserve_data(inode, &data_reserved, SZ_1M, SZ_2M); + btrfs_qgroup_reserve_data(inode, &data_reserved, 0, SZ_4M); + +Btrfs qgroup code has its internal tracking to make sure we don't +double-reserve in above example. + +The only pattern utilizing this feature is in the main while loop of +btrfs_fallocate() function. + +However btrfs_qgroup_reserve_data()'s error handling has a bug in that +on error it clears all ranges in the io_tree with EXTENT_QGROUP_RESERVED +flag but doesn't free previously reserved bytes. + +This bug has a two fold effect: +- Clearing EXTENT_QGROUP_RESERVED ranges + This is the correct behavior, but it prevents + btrfs_qgroup_check_reserved_leak() to catch the leakage as the + detector is purely EXTENT_QGROUP_RESERVED flag based. + +- Leak the previously reserved data bytes. + +The bug manifests when N calls to btrfs_qgroup_reserve_data are made and +the last one fails, leaking space reserved in the previous ones. + +[FIX] +Also free previously reserved data bytes when btrfs_qgroup_reserve_data +fails. + +Fixes: 524725537023 ("btrfs: qgroup: Introduce btrfs_qgroup_reserve_data function") +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Qu Wenruo <wqu@suse.com> +Signed-off-by: David Sterba <dsterba@suse.com> +--- + fs/btrfs/qgroup.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -3376,6 +3376,9 @@ cleanup: + clear_extent_bit(&BTRFS_I(inode)->io_tree, unode->val, + unode->aux, EXTENT_QGROUP_RESERVED, 0, 0, NULL, + GFP_NOFS); ++ /* Also free data bytes of already reserved one */ ++ btrfs_qgroup_free_refroot(root->fs_info, root->root_key.objectid, ++ orig_reserved, BTRFS_QGROUP_RSV_DATA); + extent_changeset_release(reserved); + return ret; + } diff --git a/patches.suse/PCI-Add-ACS-quirk-for-Amazon-Annapurna-Labs-root-por.patch b/patches.suse/PCI-Add-ACS-quirk-for-Amazon-Annapurna-Labs-root-por.patch new file mode 100644 index 0000000000..9a18c3711d --- /dev/null +++ b/patches.suse/PCI-Add-ACS-quirk-for-Amazon-Annapurna-Labs-root-por.patch @@ -0,0 +1,65 @@ +From: Ali Saidi <alisaidi@amazon.com> +Date: Thu, 12 Sep 2019 16:00:40 +0300 +Subject: PCI: Add ACS quirk for Amazon Annapurna Labs root ports + +Git-commit: 76e67e9e0f0f2debf9df192502a759bdd0cb4dab +Patch-mainline: v5.4-rc1 +References: bsc#1152187,bsc#1152525 + +The Amazon's Annapurna Labs root ports don't advertise an ACS +capability, but they don't allow peer-to-peer transactions and do +validate bus numbers through the SMMU. Additionally, it's not possible +for one RP to pass traffic to another RP. + +Signed-off-by: Ali Saidi <alisaidi@amazon.com> +Signed-off-by: Jonathan Chocron <jonnyc@amazon.com> +Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> +Reviewed-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> +Reviewed-by: Andrew Murray <andrew.murray@arm.com> +Acked-by: Bjorn Helgaas <bhelgaas@google.com> +Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com> +--- + drivers/pci/quirks.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c +index 208aacf39329..e96c03b4e494 100644 +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -4366,6 +4366,24 @@ static int pci_quirk_qcom_rp_acs(struct pci_dev *dev, u16 acs_flags) + return ret; + } + ++static int pci_quirk_al_acs(struct pci_dev *dev, u16 acs_flags) ++{ ++ if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) ++ return -ENOTTY; ++ ++ /* ++ * Amazon's Annapurna Labs root ports don't include an ACS capability, ++ * but do include ACS-like functionality. The hardware doesn't support ++ * peer-to-peer transactions via the root port and each has a unique ++ * segment number. ++ * ++ * Additionally, the root ports cannot send traffic to each other. ++ */ ++ acs_flags &= ~(PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF); ++ ++ return acs_flags ? 0 : 1; ++} ++ + /* + * Sunrise Point PCH root ports implement ACS, but unfortunately as shown in + * the datasheet (Intel 100 Series Chipset Family PCH Datasheet, Vol. 2, +@@ -4559,6 +4577,8 @@ static const struct pci_dev_acs_enabled { + { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs }, + { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs }, + { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs }, ++ /* Amazon Annapurna Labs */ ++ { PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, pci_quirk_al_acs }, + { 0 } + }; + +-- +2.16.4 + diff --git a/patches.suse/PCI-Add-Amazon-s-Annapurna-Labs-vendor-ID.patch b/patches.suse/PCI-Add-Amazon-s-Annapurna-Labs-vendor-ID.patch new file mode 100644 index 0000000000..b8d8c7c630 --- /dev/null +++ b/patches.suse/PCI-Add-Amazon-s-Annapurna-Labs-vendor-ID.patch @@ -0,0 +1,35 @@ +From: Jonathan Chocron <jonnyc@amazon.com> +Date: Thu, 12 Sep 2019 16:00:39 +0300 +Subject: PCI: Add Amazon's Annapurna Labs vendor ID + +Git-commit: 4a36a60c34f42f75e8b4f8cd24fcfade26111334 +Patch-mainline: v5.4-rc1 +References: bsc#1152187,bsc#1152525 + +Add Amazon's Annapurna Labs vendor ID to pci_ids.h. + +Signed-off-by: Jonathan Chocron <jonnyc@amazon.com> +Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> +Reviewed-by: Andrew Murray <andrew.murray@arm.com> +Acked-by: Bjorn Helgaas <bhelgaas@google.com> +Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> +--- + include/linux/pci_ids.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h +index c842735a4f45..5ce83544f38b 100644 +--- a/include/linux/pci_ids.h ++++ b/include/linux/pci_ids.h +@@ -2570,6 +2570,8 @@ + + #define PCI_VENDOR_ID_ASMEDIA 0x1b21 + ++#define PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS 0x1c36 ++ + #define PCI_VENDOR_ID_CIRCUITCO 0x1cc8 + #define PCI_SUBSYSTEM_ID_CIRCUITCO_MINNOWBOARD 0x0001 + +-- +2.16.4 + diff --git a/patches.suse/PCI-Add-quirk-to-disable-MSI-X-support-for-Amazon-s-.patch b/patches.suse/PCI-Add-quirk-to-disable-MSI-X-support-for-Amazon-s-.patch new file mode 100644 index 0000000000..47c4bdf63b --- /dev/null +++ b/patches.suse/PCI-Add-quirk-to-disable-MSI-X-support-for-Amazon-s-.patch @@ -0,0 +1,97 @@ +From: Jonathan Chocron <jonnyc@amazon.com> +Date: Thu, 12 Sep 2019 16:00:42 +0300 +Subject: PCI: Add quirk to disable MSI-X support for Amazon's Annapurna Labs + Root Port + +Git-commit: 738cb37b013e5ba6abd725a22abbd8baebc95082 +Patch-mainline: v5.4-rc1 +References: bsc#1152187,bsc#1152525 + +The Root Port (identified by [1c36:0031]) doesn't support MSI-X. On some +platforms it is configured to not advertise the capability at all, while +on others it (mistakenly) does. This causes a panic during +initialization by the pcieport driver, since it tries to configure the +MSI-X capability. Specifically, when trying to access the MSI-X table +a "non-existing addr" exception occurs. + +Example stacktrace snippet: + + SError Interrupt on CPU2, code 0xbf000000 -- SError + CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc1-Jonny-14847-ge76f1d4a1828-dirty #33 + Hardware name: Annapurna Labs Alpine V3 EVP (DT) + pstate: 80000005 (Nzcv daif -PAN -UAO) + pc : __pci_enable_msix_range+0x4e4/0x608 + lr : __pci_enable_msix_range+0x498/0x608 + sp : ffffff80117db700 + x29: ffffff80117db700 x28: 0000000000000001 + x27: 0000000000000001 x26: 0000000000000000 + x25: ffffffd3e9d8c0b0 x24: 0000000000000000 + x23: 0000000000000000 x22: 0000000000000000 + x21: 0000000000000001 x20: 0000000000000000 + x19: ffffffd3e9d8c000 x18: ffffffffffffffff + x17: 0000000000000000 x16: 0000000000000000 + x15: ffffff80116496c8 x14: ffffffd3e9844503 + x13: ffffffd3e9844502 x12: 0000000000000038 + x11: ffffffffffffff00 x10: 0000000000000040 + x9 : ffffff801165e270 x8 : ffffff801165e268 + x7 : 0000000000000002 x6 : 00000000000000b2 + x5 : ffffffd3e9d8c2c0 x4 : 0000000000000000 + x3 : 0000000000000000 x2 : 0000000000000000 + x1 : 0000000000000000 x0 : ffffffd3e9844680 + Kernel panic - not syncing: Asynchronous SError Interrupt + CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc1-Jonny-14847-ge76f1d4a1828-dirty #33 + Hardware name: Annapurna Labs Alpine V3 EVP (DT) + Call trace: + dump_backtrace+0x0/0x140 + show_stack+0x14/0x20 + dump_stack+0xa8/0xcc + panic+0x140/0x334 + nmi_panic+0x6c/0x70 + arm64_serror_panic+0x74/0x88 + __pte_error+0x0/0x28 + el1_error+0x84/0xf8 + __pci_enable_msix_range+0x4e4/0x608 + pci_alloc_irq_vectors_affinity+0xdc/0x150 + pcie_port_device_register+0x2b8/0x4e0 + pcie_portdrv_probe+0x34/0xf0 + +Notice that this quirk also disables MSI (which may work, but hasn't +been tested nor has a current use case), since currently there is no +standard way to disable only MSI-X. + +Signed-off-by: Jonathan Chocron <jonnyc@amazon.com> +Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> +Reviewed-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> +Reviewed-by: Andrew Murray <andrew.murray@arm.com> +Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> +--- + drivers/pci/quirks.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2859,6 +2859,24 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AT + quirk_msi_intx_disable_qca_bug); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0xe091, + quirk_msi_intx_disable_qca_bug); ++ ++/* ++ * Amazon's Annapurna Labs 1c36:0031 Root Ports don't support MSI-X, so it ++ * should be disabled on platforms where the device (mistakenly) advertises it. ++ * ++ * Notice that this quirk also disables MSI (which may work, but hasn't been ++ * tested), since currently there is no standard way to disable only MSI-X. ++ * ++ * The 0031 device id is reused for other non Root Port device types, ++ * therefore the quirk is registered for the PCI_CLASS_BRIDGE_PCI class. ++ */ ++static void quirk_al_msi_disable(struct pci_dev *dev) ++{ ++ dev->no_msi = 1; ++ pci_warn(dev, "Disabling MSI/MSI-X\n"); ++} ++DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, ++ PCI_CLASS_BRIDGE_PCI, 8, quirk_al_msi_disable); + #endif /* CONFIG_PCI_MSI */ + + /* Allow manual resource allocation for PCI hotplug bridges diff --git a/patches.suse/PCI-VPD-Prevent-VPD-access-for-Amazon-s-Annapurna-La.patch b/patches.suse/PCI-VPD-Prevent-VPD-access-for-Amazon-s-Annapurna-La.patch new file mode 100644 index 0000000000..a66ea6b29a --- /dev/null +++ b/patches.suse/PCI-VPD-Prevent-VPD-access-for-Amazon-s-Annapurna-La.patch @@ -0,0 +1,41 @@ +From: Jonathan Chocron <jonnyc@amazon.com> +Date: Thu, 12 Sep 2019 16:00:41 +0300 +Subject: PCI/VPD: Prevent VPD access for Amazon's Annapurna Labs Root Port + +Git-commit: a638b5de205af40bdadd867b1cb77320bbb2628e +Patch-mainline: v5.4-rc1 +References: bsc#1152187,bsc#1152525 + +The Amazon Annapurna Labs PCIe Root Port exposes the VPD capability, +but there is no actual support for it. + +Trying to access the VPD (for example, as part of lspci -vv or when +reading the vpd sysfs file), results in the following warning print: + + pcieport 0001:00:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update + +Signed-off-by: Jonathan Chocron <jonnyc@amazon.com> +Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> +Reviewed-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> +Reviewed-by: Andrew Murray <andrew.murray@arm.com> +Acked-by: Bjorn Helgaas <bhelgaas@google.com> +Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> +--- + drivers/pci/quirks.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2231,6 +2231,12 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LS + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, + quirk_blacklist_vpd); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_QLOGIC, 0x2261, quirk_blacklist_vpd); ++/* ++ * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port ++ * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class. ++ */ ++DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, ++ PCI_CLASS_BRIDGE_PCI, 8, quirk_blacklist_vpd); + + /* + * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the diff --git a/patches.suse/alarmtimer-Use-EOPNOTSUPP-instead-of-ENOTSUPP.patch b/patches.suse/alarmtimer-Use-EOPNOTSUPP-instead-of-ENOTSUPP.patch new file mode 100644 index 0000000000..c294bfef40 --- /dev/null +++ b/patches.suse/alarmtimer-Use-EOPNOTSUPP-instead-of-ENOTSUPP.patch @@ -0,0 +1,52 @@ +From f18ddc13af981ce3c7b7f26925f099e7c6929aba Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> +Date: Tue, 3 Sep 2019 14:18:02 -0300 +Patch-mainline: v5.4-rc1 +Git-commit: f18ddc13af981ce3c7b7f26925f099e7c6929aba +References: bsc#1151680 +Subject: [PATCH] alarmtimer: Use EOPNOTSUPP instead of ENOTSUPP + +ENOTSUPP is not supposed to be returned to userspace. This was found on an +OpenPower machine, where the RTC does not support set_alarm. + +On that system, a clock_nanosleep(CLOCK_REALTIME_ALARM, ...) results in +"524 Unknown error 524" + +Replace it with EOPNOTSUPP which results in the expected "95 Operation not +supported" error. + +Fixes: 1c6b39ad3f01 (alarmtimers: Return -ENOTSUPP if no RTC device is present) +Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> +Signed-off-by: Thomas Gleixner <tglx@linutronix.de> +Signed-off-by: Petr Vorel <pvorel@suse.cz> +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190903171802.28314-1-cascardo@canonical.com +--- + kernel/time/alarmtimer.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c +index 57518efc3810..b7d75a9e8ccf 100644 +--- a/kernel/time/alarmtimer.c ++++ b/kernel/time/alarmtimer.c +@@ -672,7 +672,7 @@ static int alarm_timer_create(struct k_itimer *new_timer) + enum alarmtimer_type type; + + if (!alarmtimer_get_rtcdev()) +- return -ENOTSUPP; ++ return -EOPNOTSUPP; + + if (!capable(CAP_WAKE_ALARM)) + return -EPERM; +@@ -790,7 +790,7 @@ static int alarm_timer_nsleep(const clockid_t which_clock, int flags, + int ret = 0; + + if (!alarmtimer_get_rtcdev()) +- return -ENOTSUPP; ++ return -EOPNOTSUPP; + + if (flags & ~TIMER_ABSTIME) + return -EINVAL; +-- +2.16.4 + diff --git a/patches.suse/ceph-use-ceph_evict_inode-to-cleanup-inode-s-resource.patch b/patches.suse/ceph-use-ceph_evict_inode-to-cleanup-inode-s-resource.patch new file mode 100644 index 0000000000..daf9331c08 --- /dev/null +++ b/patches.suse/ceph-use-ceph_evict_inode-to-cleanup-inode-s-resource.patch @@ -0,0 +1,90 @@ +From: "Yan, Zheng" <zyan@redhat.com> +Date: Tue, 1 Oct 2019 17:24:25 -0400 +Subject: ceph: use ceph_evict_inode to cleanup inode's resource +Git-commit: 87bc5b895d94a0f40fe170d4cf5771c8e8f85d15 +Patch-mainline: v5.3-rc1 +References: bsc#1148133 + +[ Upstream commit 87bc5b895d94a0f40fe170d4cf5771c8e8f85d15 ] + +remove_session_caps() relies on __wait_on_freeing_inode(), to wait for +freeing inode to remove its caps. But VFS wakes freeing inode waiters +before calling destroy_inode(). + +[ jlayton: mainline moved to ->free_inode before the original patch was + merged. This backport reinstates ceph_destroy_inode and just + has it do the call_rcu call. ] + +Cc: stable@vger.kernel.org +Link: https://tracker.ceph.com/issues/40102 +Signed-off-by: "Yan, Zheng" <zyan@redhat.com> +Reviewed-by: Jeff Layton <jlayton@redhat.com> +Signed-off-by: Ilya Dryomov <idryomov@gmail.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +Acked-by: Luis Henriques <lhenriques@suse.com> +[luis: cherry-pick from stable linux-v4.19] +--- + fs/ceph/inode.c | 10 ++++++++-- + fs/ceph/super.c | 1 + + fs/ceph/super.h | 1 + + 3 files changed, 10 insertions(+), 2 deletions(-) + +diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c +index 11f19432a74c..c06845237cba 100644 +--- a/fs/ceph/inode.c ++++ b/fs/ceph/inode.c +@@ -528,13 +528,16 @@ static void ceph_i_callback(struct rcu_head *head) + kmem_cache_free(ceph_inode_cachep, ci); + } + +-void ceph_destroy_inode(struct inode *inode) ++void ceph_evict_inode(struct inode *inode) + { + struct ceph_inode_info *ci = ceph_inode(inode); + struct ceph_inode_frag *frag; + struct rb_node *n; + +- dout("destroy_inode %p ino %llx.%llx\n", inode, ceph_vinop(inode)); ++ dout("evict_inode %p ino %llx.%llx\n", inode, ceph_vinop(inode)); ++ ++ truncate_inode_pages_final(&inode->i_data); ++ clear_inode(inode); + + ceph_fscache_unregister_inode_cookie(ci); + +@@ -576,7 +579,10 @@ void ceph_destroy_inode(struct inode *inode) + ceph_buffer_put(ci->i_xattrs.prealloc_blob); + + ceph_put_string(rcu_dereference_raw(ci->i_layout.pool_ns)); ++} + ++void ceph_destroy_inode(struct inode *inode) ++{ + call_rcu(&inode->i_rcu, ceph_i_callback); + } + +diff --git a/fs/ceph/super.c b/fs/ceph/super.c +index c5cf46e43f2e..ccab249a37f6 100644 +--- a/fs/ceph/super.c ++++ b/fs/ceph/super.c +@@ -830,6 +830,7 @@ static const struct super_operations ceph_super_ops = { + .destroy_inode = ceph_destroy_inode, + .write_inode = ceph_write_inode, + .drop_inode = ceph_drop_inode, ++ .evict_inode = ceph_evict_inode, + .sync_fs = ceph_sync_fs, + .put_super = ceph_put_super, + .remount_fs = ceph_remount, +diff --git a/fs/ceph/super.h b/fs/ceph/super.h +index 018019309790..8d3eabf06d66 100644 +--- a/fs/ceph/super.h ++++ b/fs/ceph/super.h +@@ -854,6 +854,7 @@ static inline bool __ceph_have_pending_cap_snap(struct ceph_inode_info *ci) + extern const struct inode_operations ceph_file_iops; + + extern struct inode *ceph_alloc_inode(struct super_block *sb); ++extern void ceph_evict_inode(struct inode *inode); + extern void ceph_destroy_inode(struct inode *inode); + extern int ceph_drop_inode(struct inode *inode); + + diff --git a/patches.suse/ftrace-x86-remove-possible-deadlock-between-register_kprobe-and-ftrace_run_update_code.patch b/patches.suse/ftrace-x86-remove-possible-deadlock-between-register_kprobe-and-ftrace_run_update_code.patch deleted file mode 100644 index 7ca190f8d2..0000000000 --- a/patches.suse/ftrace-x86-remove-possible-deadlock-between-register_kprobe-and-ftrace_run_update_code.patch +++ /dev/null @@ -1,182 +0,0 @@ -From: Petr Mladek <pmladek@suse.com> -Date: Thu, 27 Jun 2019 10:13:34 +0200 -Subject: ftrace/x86: Remove possible deadlock between register_kprobe() and - ftrace_run_update_code() -Git-commit: d5b844a2cf507fc7642c9ae80a9d585db3065c28 -Patch-mainline: v5.2 -References: bsc#1071995 fate#323487 - -The commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text -permissions race") causes a possible deadlock between register_kprobe() -and ftrace_run_update_code() when ftrace is using stop_machine(). - -The existing dependency chain (in reverse order) is: - --> #1 (text_mutex){+.+.}: - validate_chain.isra.21+0xb32/0xd70 - __lock_acquire+0x4b8/0x928 - lock_acquire+0x102/0x230 - __mutex_lock+0x88/0x908 - mutex_lock_nested+0x32/0x40 - register_kprobe+0x254/0x658 - init_kprobes+0x11a/0x168 - do_one_initcall+0x70/0x318 - kernel_init_freeable+0x456/0x508 - kernel_init+0x22/0x150 - ret_from_fork+0x30/0x34 - kernel_thread_starter+0x0/0xc - --> #0 (cpu_hotplug_lock.rw_sem){++++}: - check_prev_add+0x90c/0xde0 - validate_chain.isra.21+0xb32/0xd70 - __lock_acquire+0x4b8/0x928 - lock_acquire+0x102/0x230 - cpus_read_lock+0x62/0xd0 - stop_machine+0x2e/0x60 - arch_ftrace_update_code+0x2e/0x40 - ftrace_run_update_code+0x40/0xa0 - ftrace_startup+0xb2/0x168 - register_ftrace_function+0x64/0x88 - klp_patch_object+0x1a2/0x290 - klp_enable_patch+0x554/0x980 - do_one_initcall+0x70/0x318 - do_init_module+0x6e/0x250 - load_module+0x1782/0x1990 - __s390x_sys_finit_module+0xaa/0xf0 - system_call+0xd8/0x2d0 - - Possible unsafe locking scenario: - - CPU0 CPU1 - ---- ---- - lock(text_mutex); - lock(cpu_hotplug_lock.rw_sem); - lock(text_mutex); - lock(cpu_hotplug_lock.rw_sem); - -It is similar problem that has been solved by the commit 2d1e38f56622b9b -("kprobes: Cure hotplug lock ordering issues"). Many locks are involved. -To be on the safe side, text_mutex must become a low level lock taken -after cpu_hotplug_lock.rw_sem. - -This can't be achieved easily with the current ftrace design. -For example, arm calls set_all_modules_text_rw() already in -ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c. -This functions is called: - - + outside stop_machine() from ftrace_run_update_code() - + without stop_machine() from ftrace_module_enable() - -Fortunately, the problematic fix is needed only on x86_64. It is -the only architecture that calls set_all_modules_text_rw() -in ftrace path and supports livepatching at the same time. - -Therefore it is enough to move text_mutex handling from the generic -kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c: - - ftrace_arch_code_modify_prepare() - ftrace_arch_code_modify_post_process() - -This patch basically reverts the ftrace part of the problematic -commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module -text permissions race"). And provides x86_64 specific-fix. - -Some refactoring of the ftrace code will be needed when livepatching -is implemented for arm or nds32. These architectures call -set_all_modules_text_rw() and use stop_machine() at the same time. - -Link: http://lkml.kernel.org/r/20190627081334.12793-1-pmladek@suse.com - -Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text permissions race") -Acked-by: Thomas Gleixner <tglx@linutronix.de> -Reported-by: Miroslav Benes <mbenes@suse.cz> -Reviewed-by: Miroslav Benes <mbenes@suse.cz> -Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> -Signed-off-by: Petr Mladek <pmladek@suse.com> -[ - As reviewed by Miroslav Benes <mbenes@suse.cz>, removed return value of - ftrace_run_update_code() as it is a void function. -] -Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> -Acked-by: Miroslav Benes <mbenes@suse.cz> ---- - arch/x86/kernel/ftrace.c | 3 +++ - kernel/trace/ftrace.c | 10 +--------- - 2 files changed, 4 insertions(+), 9 deletions(-) - ---- a/arch/x86/kernel/ftrace.c -+++ b/arch/x86/kernel/ftrace.c -@@ -21,6 +21,7 @@ - #include <linux/init.h> - #include <linux/list.h> - #include <linux/module.h> -+#include <linux/memory.h> - - #include <trace/syscall.h> - -@@ -34,6 +35,7 @@ - - int ftrace_arch_code_modify_prepare(void) - { -+ mutex_lock(&text_mutex); - set_kernel_text_rw(); - set_all_modules_text_rw(); - return 0; -@@ -43,6 +45,7 @@ int ftrace_arch_code_modify_post_process - { - set_all_modules_text_ro(); - set_kernel_text_ro(); -+ mutex_unlock(&text_mutex); - return 0; - } - ---- a/kernel/trace/ftrace.c -+++ b/kernel/trace/ftrace.c -@@ -33,7 +33,6 @@ - #include <linux/list.h> - #include <linux/hash.h> - #include <linux/rcupdate.h> --#include <linux/memory.h> - - #include <trace/events/sched.h> - -@@ -2630,12 +2629,10 @@ static void ftrace_run_update_code(int c - { - int ret; - -- mutex_lock(&text_mutex); -- - ret = ftrace_arch_code_modify_prepare(); - FTRACE_WARN_ON(ret); - if (ret) -- goto out_unlock; -+ return; - - /* - * By default we use stop_machine() to modify the code. -@@ -2647,9 +2644,6 @@ static void ftrace_run_update_code(int c - - ret = ftrace_arch_code_modify_post_process(); - FTRACE_WARN_ON(ret); -- --out_unlock: -- mutex_unlock(&text_mutex); - } - - static void ftrace_run_modify_code(struct ftrace_ops *ops, int command, -@@ -5415,7 +5409,6 @@ void ftrace_module_enable(struct module - struct ftrace_page *pg; - - mutex_lock(&ftrace_lock); -- mutex_lock(&text_mutex); - - if (ftrace_disabled) - goto out_unlock; -@@ -5476,7 +5469,6 @@ void ftrace_module_enable(struct module - ftrace_arch_code_modify_post_process(); - - out_unlock: -- mutex_unlock(&text_mutex); - mutex_unlock(&ftrace_lock); - } - diff --git a/patches.suse/libnvdimm-altmap-track-namespace-boundaries-in-altmap.patch b/patches.suse/libnvdimm-altmap-track-namespace-boundaries-in-altmap.patch new file mode 100644 index 0000000000..e604cc9fb2 --- /dev/null +++ b/patches.suse/libnvdimm-altmap-track-namespace-boundaries-in-altmap.patch @@ -0,0 +1,129 @@ +From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> +Date: Tue, 10 Sep 2019 11:58:25 +0530 +Subject: libnvdimm/altmap: Track namespace boundaries in altmap +Git-commit: cf387d9644d8c78721cf9b77af9f67bb5b04da16 +Patch-mainline: v5.4-rc1 +References: bsc#1150305 + +With PFN_MODE_PMEM namespace, the memmap area is allocated from the device +area. Some architectures map the memmap area with large page size. On +architectures like ppc64, 16MB page for memap mapping can map 262144 pfns. +This maps a namespace size of 16G. + +When populating memmap region with 16MB page from the device area, +make sure the allocated space is not used to map resources outside this +namespace. Such usage of device area will prevent a namespace destroy. + +Add resource end pnf in altmap and use that to check if the memmap area +allocation can map pfn outside the namespace. On ppc64 in such case we fallback +to allocation from memory. + +This fix kernel crash reported below: + +[ 132.034989] WARNING: CPU: 13 PID: 13719 at mm/memremap.c:133 devm_memremap_pages_release+0x2d8/0x2e0 +[ 133.464754] BUG: Unable to handle kernel data access at 0xc00c00010b204000 +[ 133.464760] Faulting instruction address: 0xc00000000007580c +[ 133.464766] Oops: Kernel access of bad area, sig: 11 [#1] +[ 133.464771] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries +..... +[ 133.464901] NIP [c00000000007580c] vmemmap_free+0x2ac/0x3d0 +[ 133.464906] LR [c0000000000757f8] vmemmap_free+0x298/0x3d0 +[ 133.464910] Call Trace: +[ 133.464914] [c000007cbfd0f7b0] [c0000000000757f8] vmemmap_free+0x298/0x3d0 (unreliable) +[ 133.464921] [c000007cbfd0f8d0] [c000000000370a44] section_deactivate+0x1a4/0x240 +[ 133.464928] [c000007cbfd0f980] [c000000000386270] __remove_pages+0x3a0/0x590 +[ 133.464935] [c000007cbfd0fa50] [c000000000074158] arch_remove_memory+0x88/0x160 +[ 133.464942] [c000007cbfd0fae0] [c0000000003be8c0] devm_memremap_pages_release+0x150/0x2e0 +[ 133.464949] [c000007cbfd0fb70] [c000000000738ea0] devm_action_release+0x30/0x50 +[ 133.464955] [c000007cbfd0fb90] [c00000000073a5a4] release_nodes+0x344/0x400 +[ 133.464961] [c000007cbfd0fc40] [c00000000073378c] device_release_driver_internal+0x15c/0x250 +[ 133.464968] [c000007cbfd0fc80] [c00000000072fd14] unbind_store+0x104/0x110 +[ 133.464973] [c000007cbfd0fcd0] [c00000000072ee24] drv_attr_store+0x44/0x70 +[ 133.464981] [c000007cbfd0fcf0] [c0000000004a32bc] sysfs_kf_write+0x6c/0xa0 +[ 133.464987] [c000007cbfd0fd10] [c0000000004a1dfc] kernfs_fop_write+0x17c/0x250 +[ 133.464993] [c000007cbfd0fd60] [c0000000003c348c] __vfs_write+0x3c/0x70 +[ 133.464999] [c000007cbfd0fd80] [c0000000003c75d0] vfs_write+0xd0/0x250 + +djbw: Aneesh notes that this crash can likely be triggered in any kernel that +supports 'papr_scm', so flagging that commit for -stable consideration. + +Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") +Cc: <stable@vger.kernel.org> +Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> +Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> +Reviewed-by: Pankaj Gupta <pagupta@redhat.com> +Tested-by: Santosh Sivaraj <santosh@fossix.org> +Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> +Link: https://lore.kernel.org/r/20190910062826.10041-1-aneesh.kumar@linux.ibm.com +Signed-off-by: Dan Williams <dan.j.williams@intel.com> +Acked-by: Johannes Thumshirn <jthumshirn@suse.de> +--- + arch/powerpc/mm/init_64.c | 17 ++++++++++++++++- + drivers/nvdimm/pfn_devs.c | 2 ++ + include/linux/memremap.h | 1 + + 3 files changed, 19 insertions(+), 1 deletion(-) + +diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c +index a44f6281ca3a..4e08246acd79 100644 +--- a/arch/powerpc/mm/init_64.c ++++ b/arch/powerpc/mm/init_64.c +@@ -172,6 +172,21 @@ static __meminit void vmemmap_list_populate(unsigned long phys, + vmemmap_list = vmem_back; + } + ++static bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long start, ++ unsigned long page_size) ++{ ++ unsigned long nr_pfn = page_size / sizeof(struct page); ++ unsigned long start_pfn = page_to_pfn((struct page *)start); ++ ++ if ((start_pfn + nr_pfn) > altmap->end_pfn) ++ return true; ++ ++ if (start_pfn < altmap->base_pfn) ++ return true; ++ ++ return false; ++} ++ + int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, + struct vmem_altmap *altmap) + { +@@ -194,7 +209,7 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, + * fail due to alignment issues when using 16MB hugepages, so + * fall back to system memory if the altmap allocation fail. + */ +- if (altmap) { ++ if (altmap && !altmap_cross_boundary(altmap, start, page_size)) { + p = altmap_alloc_block_buf(page_size, altmap); + if (!p) + pr_debug("altmap block allocation failed, falling back to system memory"); +diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c +index 934cdcaaae97..80c7992bc538 100644 +--- a/drivers/nvdimm/pfn_devs.c ++++ b/drivers/nvdimm/pfn_devs.c +@@ -672,9 +672,11 @@ static int __nvdimm_setup_pfn(struct nd_pfn *nd_pfn, struct dev_pagemap *pgmap) + struct nd_namespace_common *ndns = nd_pfn->ndns; + struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev); + resource_size_t base = nsio->res.start + start_pad; ++ resource_size_t end = nsio->res.end - end_trunc; + struct vmem_altmap __altmap = { + .base_pfn = init_altmap_base(base), + .reserve = init_altmap_reserve(base), ++ .end_pfn = PHYS_PFN(end), + }; + + memcpy(res, &nsio->res, sizeof(*res)); +diff --git a/include/linux/memremap.h b/include/linux/memremap.h +index f8a5b2a19945..c70996fe48c8 100644 +--- a/include/linux/memremap.h ++++ b/include/linux/memremap.h +@@ -17,6 +17,7 @@ struct device; + */ + struct vmem_altmap { + const unsigned long base_pfn; ++ const unsigned long end_pfn; + const unsigned long reserve; + unsigned long free; + unsigned long align; + diff --git a/patches.suse/module-fix-livepatch-ftrace-module-text-permissions-race.patch b/patches.suse/module-fix-livepatch-ftrace-module-text-permissions-race.patch deleted file mode 100644 index 66088c57bc..0000000000 --- a/patches.suse/module-fix-livepatch-ftrace-module-text-permissions-race.patch +++ /dev/null @@ -1,170 +0,0 @@ -From: Josh Poimboeuf <jpoimboe@redhat.com> -Date: Thu, 13 Jun 2019 20:07:22 -0500 -Subject: module: Fix livepatch/ftrace module text permissions race -Git-commit: 9f255b632bf12c4dd7fc31caee89aa991ef75176 -Patch-mainline: v5.2-rc5 -References: bsc#1071995 fate#323487 - -It's possible for livepatch and ftrace to be toggling a module's text -permissions at the same time, resulting in the following panic: - - BUG: unable to handle page fault for address: ffffffffc005b1d9 - #PF: supervisor write access in kernel mode - #PF: error_code(0x0003) - permissions violation - PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061 - Oops: 0003 [#1] PREEMPT SMP PTI - CPU: 1 PID: 453 Comm: insmod Tainted: G O K 5.2.0-rc1-a188339ca5 #1 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 - RIP: 0010:apply_relocate_add+0xbe/0x14c - Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33 eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8 74 2e eb 48 83 38 00 75 32 48 29 c1 89 08 - RSP: 0018:ffffb223c00dbb10 EFLAGS: 00010246 - RAX: ffffffffc005b1d9 RBX: 0000000000000000 RCX: ffffffff8b200060 - RDX: 000000000000000b RSI: 0000004b0000000b RDI: ffff96bdfcd33000 - RBP: ffffb223c00dbb38 R08: ffffffffc005d040 R09: ffffffffc005c1f0 - R10: ffff96bdfcd33c40 R11: ffff96bdfcd33b80 R12: 0000000000000018 - R13: ffffffffc005c1f0 R14: ffffffffc005e708 R15: ffffffff8b2fbc74 - FS: 00007f5f447beba8(0000) GS:ffff96bdff900000(0000) knlGS:0000000000000000 - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 - CR2: ffffffffc005b1d9 CR3: 000000003cedc002 CR4: 0000000000360ea0 - DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 - DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 - Call Trace: - klp_init_object_loaded+0x10f/0x219 - ? preempt_latency_start+0x21/0x57 - klp_enable_patch+0x662/0x809 - ? virt_to_head_page+0x3a/0x3c - ? kfree+0x8c/0x126 - patch_init+0x2ed/0x1000 [livepatch_test02] - ? 0xffffffffc0060000 - do_one_initcall+0x9f/0x1c5 - ? kmem_cache_alloc_trace+0xc4/0xd4 - ? do_init_module+0x27/0x210 - do_init_module+0x5f/0x210 - load_module+0x1c41/0x2290 - ? fsnotify_path+0x3b/0x42 - ? strstarts+0x2b/0x2b - ? kernel_read+0x58/0x65 - __do_sys_finit_module+0x9f/0xc3 - ? __do_sys_finit_module+0x9f/0xc3 - __x64_sys_finit_module+0x1a/0x1c - do_syscall_64+0x52/0x61 - entry_SYSCALL_64_after_hwframe+0x44/0xa9 - -The above panic occurs when loading two modules at the same time with -ftrace enabled, where at least one of the modules is a livepatch module: - -CPU0 CPU1 -klp_enable_patch() - klp_init_object_loaded() - module_disable_ro() - ftrace_module_enable() - ftrace_arch_code_modify_post_process() - set_all_modules_text_ro() - klp_write_object_relocations() - apply_relocate_add() - *patches read-only code* - BOOM - -A similar race exists when toggling ftrace while loading a livepatch -module. - -Fix it by ensuring that the livepatch and ftrace code patching -operations -- and their respective permissions changes -- are protected -by the text_mutex. - -Link: http://lkml.kernel.org/r/ab43d56ab909469ac5d2520c5d944ad6d4abd476.1560474114.git.jpoimboe@redhat.com - -Reported-by: Johannes Erdfelt <johannes@erdfelt.com> -Fixes: 444d13ff10fb ("modules: add ro_after_init support") -Acked-by: Jessica Yu <jeyu@kernel.org> -Reviewed-by: Petr Mladek <pmladek@suse.com> -Reviewed-by: Miroslav Benes <mbenes@suse.cz> -Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> -Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> -Acked-by: Miroslav Benes <mbenes@suse.cz> ---- - kernel/livepatch/core.c | 6 ++++++ - kernel/trace/ftrace.c | 10 +++++++++- - 2 files changed, 15 insertions(+), 1 deletion(-) - ---- a/kernel/livepatch/core.c -+++ b/kernel/livepatch/core.c -@@ -30,6 +30,7 @@ - #include <linux/elf.h> - #include <linux/moduleloader.h> - #include <linux/completion.h> -+#include <linux/memory.h> - #include <asm/cacheflush.h> - #include "core.h" - #include "patch.h" -@@ -729,16 +730,21 @@ static int klp_init_object_loaded(struct - struct klp_func *func; - int ret; - -+ mutex_lock(&text_mutex); -+ - module_disable_ro(patch->mod); - ret = klp_write_object_relocations(patch->mod, obj); - if (ret) { - module_enable_ro(patch->mod, true); -+ mutex_unlock(&text_mutex); - return ret; - } - - arch_klp_init_object_loaded(patch, obj); - module_enable_ro(patch->mod, true); - -+ mutex_unlock(&text_mutex); -+ - klp_for_each_func(obj, func) { - ret = klp_find_object_symbol(obj->name, func->old_name, - func->old_sympos, ---- a/kernel/trace/ftrace.c -+++ b/kernel/trace/ftrace.c -@@ -33,6 +33,7 @@ - #include <linux/list.h> - #include <linux/hash.h> - #include <linux/rcupdate.h> -+#include <linux/memory.h> - - #include <trace/events/sched.h> - -@@ -2629,10 +2630,12 @@ static void ftrace_run_update_code(int c - { - int ret; - -+ mutex_lock(&text_mutex); -+ - ret = ftrace_arch_code_modify_prepare(); - FTRACE_WARN_ON(ret); - if (ret) -- return; -+ goto out_unlock; - - /* - * By default we use stop_machine() to modify the code. -@@ -2644,6 +2647,9 @@ static void ftrace_run_update_code(int c - - ret = ftrace_arch_code_modify_post_process(); - FTRACE_WARN_ON(ret); -+ -+out_unlock: -+ mutex_unlock(&text_mutex); - } - - static void ftrace_run_modify_code(struct ftrace_ops *ops, int command, -@@ -5409,6 +5415,7 @@ void ftrace_module_enable(struct module - struct ftrace_page *pg; - - mutex_lock(&ftrace_lock); -+ mutex_lock(&text_mutex); - - if (ftrace_disabled) - goto out_unlock; -@@ -5469,6 +5476,7 @@ void ftrace_module_enable(struct module - ftrace_arch_code_modify_post_process(); - - out_unlock: -+ mutex_unlock(&text_mutex); - mutex_unlock(&ftrace_lock); - } - diff --git a/patches.suse/powerpc-papr_scm-Fix-an-off-by-one-check-in-papr_scm_meta_-get-set.patch b/patches.suse/powerpc-papr_scm-Fix-an-off-by-one-check-in-papr_scm_meta_-get-set.patch new file mode 100644 index 0000000000..1d2c857471 --- /dev/null +++ b/patches.suse/powerpc-papr_scm-Fix-an-off-by-one-check-in-papr_scm_meta_-get-set.patch @@ -0,0 +1,57 @@ +From patchwork Fri Sep 27 06:20:02 2019 +X-Patchwork-Id: 1168278 +Date: Fri, 27 Sep 2019 11:50:02 +0530 +Message-Id: <20190927062002.3169-1-vaibhav@linux.ibm.com> +From: Vaibhav Jain <vaibhav@linux.ibm.com> +Subject: [PATCH] powerpc/papr_scm: Fix an off-by-one check in + papr_scm_meta_{get, set} + +References: bsc#1152243 ltc#181472 +Patch-mainline: submitted https://patchwork.ozlabs.org/patch/1168278/ + +A validation check to prevent out of bounds read/write inside +functions papr_scm_meta_{get,set}() is off-by-one that prevent reads +and writes to the last byte of the label area. + +This bug manifests as a failure to probe a dimm when libnvdimm is +unable to read the entire config-area as advertised by +ND_CMD_GET_CONFIG_SIZE. This usually happens when there are large +number of namespaces created in the region backed by the dimm and the +label-index spans max possible config-area. An error of the form below +usually reported in the kernel logs: + +[ 255.293912] nvdimm: probe of nmem0 failed with error -22 + +The patch fixes these validation checks there by letting libnvdimm +access the entire config-area. + +Fixes: 53e80bd042773('powerpc/nvdimm: Add support for multibyte read/write for metadata') +Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> +Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> +Acked-by: Michal Suchanek <msuchanek@suse.de> +--- + arch/powerpc/platforms/pseries/papr_scm.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c +index a5ac371a3f06..0d0f4974a301 100644 +--- a/arch/powerpc/platforms/pseries/papr_scm.c ++++ b/arch/powerpc/platforms/pseries/papr_scm.c +@@ -124,7 +124,7 @@ static int papr_scm_meta_get(struct papr_scm_priv *p, + int len, read; + int64_t ret; + +- if ((hdr->in_offset + hdr->in_length) >= p->metadata_size) ++ if ((hdr->in_offset + hdr->in_length) > p->metadata_size) + return -EINVAL; + + for (len = hdr->in_length; len; len -= read) { +@@ -178,7 +178,7 @@ static int papr_scm_meta_set(struct papr_scm_priv *p, + __be64 data_be; + int64_t ret; + +- if ((hdr->in_offset + hdr->in_length) >= p->metadata_size) ++ if ((hdr->in_offset + hdr->in_length) > p->metadata_size) + return -EINVAL; + + for (len = hdr->in_length; len; len -= wrote) { diff --git a/series.conf b/series.conf index d045097cc6..bae716c3f6 100644 --- a/series.conf +++ b/series.conf @@ -48595,7 +48595,6 @@ patches.suse/drm-edid-abstract-override-firmware-EDID-retrieval.patch patches.suse/drm-add-fallback-override-firmware-EDID-modes-workar.patch patches.suse/cgroup-use-css_tryget-instead-of-css_tryget_online-in-task_get_css.patch - patches.suse/module-fix-livepatch-ftrace-module-text-permissions-race.patch patches.suse/USB-usb-storage-Add-new-ID-to-ums-realtek.patch patches.suse/USB-Fix-chipmunk-like-voice-when-using-Logitech-C270.patch patches.suse/0001-usb-dwc2-host-Fix-wMaxPacketSize-handling-fix-webcam.patch @@ -48728,7 +48727,6 @@ patches.suse/cpu-speculation-warn-on-unsupported-mitigations-parameter.patch patches.suse/cifs-fix-crash-querying-symlinks-stored-as-reparse-points.patch patches.suse/Bluetooth-Fix-faulty-expression-for-minimum-encrypti.patch - patches.suse/ftrace-x86-remove-possible-deadlock-between-register_kprobe-and-ftrace_run_update_code.patch patches.suse/tracing-snapshot-resize-spare-buffer-if-size-changed.patch patches.suse/ptrace-Fix-ptracer_cred-handling-for-PTRACE_TRACEME.patch patches.suse/ALSA-hda-realtek-Add-quirks-for-several-Clevo-notebo.patch @@ -49383,6 +49381,7 @@ patches.suse/ceph-handle-change_attr-in-cap-messages.patch patches.suse/ceph-increment-change_attribute-on-local-changes.patch patches.suse/ceph-initialize-superblock-s_time_gran-to-1.patch + patches.suse/ceph-use-ceph_evict_inode-to-cleanup-inode-s-resource.patch patches.suse/cifs-Use-kmemdup-in-SMB2_ioctl_init-.patch patches.suse/fs-cifs-Drop-unlikely-before-IS_ERR-_OR_NULL-.patch patches.suse/SMB3-Add-SMB3-1-1-GCM-to-negotiated-crypto-algorigthms.patch @@ -49806,6 +49805,7 @@ patches.suse/iommu-dma-fix-for-dereferencing-before-null-checking patches.suse/qla2xxx-remove-SGI-SN2-support.patch patches.suse/platform-x86-pmc_atom-Add-Siemens-SIMATIC-IPC227E-to.patch + patches.suse/alarmtimer-Use-EOPNOTSUPP-instead-of-ENOTSUPP.patch patches.suse/blk-mq-introduce-blk_mq_request_completed.patch patches.suse/blk-mq-introduce-blk_mq_tagset_wait_completed_reques.patch patches.suse/nvme-don-t-abort-completed-request-in-nvme_cancel_re.patch @@ -50043,6 +50043,10 @@ patches.suse/power-supply-Init-device-wakeup-after-device_add.patch patches.suse/power-reset-gpio-restart-Fix-typo-when-gpio-reset-is.patch patches.suse/livepatch-nullify-obj-mod-in-klp_module_coming-s-error-path.patch + patches.suse/PCI-Add-Amazon-s-Annapurna-Labs-vendor-ID.patch + patches.suse/PCI-Add-ACS-quirk-for-Amazon-Annapurna-Labs-root-por.patch + patches.suse/PCI-VPD-Prevent-VPD-access-for-Amazon-s-Annapurna-La.patch + patches.suse/PCI-Add-quirk-to-disable-MSI-X-support-for-Amazon-s-.patch patches.suse/suse-hv-PCI-hv-Detect-and-fix-Hyper-V-PCI-domain-number-coll.patch patches.suse/powerpc-pseries-Read-TLB-Block-Invalidate-Characteri.patch patches.suse/powerpc-pseries-Call-H_BLOCK_REMOVE-when-supported.patch @@ -50052,6 +50056,12 @@ patches.suse/net-ibmvnic-unlock-rtnl_lock-in-reset-so-linkwatch_e.patch patches.suse/net-ibmvnic-prevent-more-than-one-thread-from-runnin.patch patches.suse/ppp-Fix-memory-leak-in-ppp_write.patch + patches.suse/libnvdimm-altmap-track-namespace-boundaries-in-altmap.patch + patches.suse/0001-btrfs-relocation-fix-use-after-free-on-dead-relocati.patch + patches.suse/0001-btrfs-qgroup-Fix-the-wrong-target-io_tree-when-freei.patch + patches.suse/0002-btrfs-qgroup-Fix-reserved-data-space-leak-if-we-have.patch + patches.suse/0001-xen-xenbus-fix-self-deadlock-after-killing-user-proc.patch + patches.suse/0001-xen-netfront-do-not-use-0U-as-error-return-value-for.patch # jejb/scsi for-next patches.suse/scsi-qla2xxx-Fix-Nport-ID-display-value.patch @@ -50115,6 +50125,7 @@ patches.suse/cifs-handle-netapp-error-codes.patch patches.suse/scsi-qla2xxx-Remove-WARN_ON_ONCE-in-qla2x00_status_c.patch patches.suse/0001-b2c2-flexcop-usb-add-sanity-checking.patch + patches.suse/powerpc-papr_scm-Fix-an-off-by-one-check-in-papr_scm_meta_-get-set.patch ######################################################## # end of sorted patches @@ -50860,6 +50871,8 @@ patches.kabi/NFSv4-Fix-OPEN-CLOSE-race.patch + patches.kabi/kabi-fix-vmem_altmap.patch + ######################################################## # You'd better have a good reason for adding a patch # below here. |