From patchwork Mon Mar 8 12:30:29 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395912 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11BC9C43333 for ; Mon, 8 Mar 2021 12:34:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C2A58651CF for ; Mon, 8 Mar 2021 12:34:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231171AbhCHMdn (ORCPT ); Mon, 8 Mar 2021 07:33:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:42422 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230124AbhCHMde (ORCPT ); Mon, 8 Mar 2021 07:33:34 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C391864EBC; Mon, 8 Mar 2021 12:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206814; bh=EKdBxPTN/7OYDFTT4DV2RP4BAKF17ymlpS1yh2CbRMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DjeBz0owUDXnZUs06aBidPGdIbIrelgkuNEyAhveUJ0DnsAxJfcpVvaEjtPERXG6u H3qJcFud8mcnJKX0bXCfy4Aq0jpLqSQpEwMhr1KPIHgCZCHHGK548F0HPNnyM6/TiS BaBw4FHg+NAl04ajreu8VyOpKjKp6QeLZYbs4J+0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Takashi Iwai Subject: [PATCH 5.10 03/42] ALSA: usb-audio: Drop bogus dB range in too low level Date: Mon, 8 Mar 2021 13:30:29 +0100 Message-Id: <20210308122718.297797810@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Takashi Iwai commit 21cba9c5359dd9d1bffe355336cfec0b66d1ee52 upstream. Some USB audio firmware seem to report broken dB values for the volume controls, and this screws up applications like PulseAudio who blindly trusts the given data. For example, Edifier G2000 reports a PCM volume from -128dB to -127dB, and this results in barely inaudible sound. This patch adds a sort of sanity check at parsing the dB values in USB-audio driver and disables the dB reporting if the range looks bogus. Here, we assume -96dB as the bottom line of the max dB. Note that, if one can figure out that proper dB range later, it can be patched in the mixer maps. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211929 Cc: Link: https://lore.kernel.org/r/20210227105737.3656-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/usb/mixer.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1301,6 +1301,17 @@ no_res_check: /* totally crap, return an error */ return -EINVAL; } + } else { + /* if the max volume is too low, it's likely a bogus range; + * here we use -96dB as the threshold + */ + if (cval->dBmax <= -9600) { + usb_audio_info(cval->head.mixer->chip, + "%d:%d: bogus dB values (%d/%d), disabling dB reporting\n", + cval->head.id, mixer_ctrl_intf(cval->head.mixer), + cval->dBmin, cval->dBmax); + cval->dBmin = cval->dBmax = 0; + } } return 0; From patchwork Mon Mar 8 12:30:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395910 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F341AC433E0 for ; Mon, 8 Mar 2021 12:34:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A776F651FF for ; Mon, 8 Mar 2021 12:34:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229646AbhCHMeP (ORCPT ); Mon, 8 Mar 2021 07:34:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:42604 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231195AbhCHMdn (ORCPT ); Mon, 8 Mar 2021 07:33:43 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9691064EBC; Mon, 8 Mar 2021 12:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206823; bh=McBes+rk6Ag/RBx+10Y6ij8K1VSk8jk+U/BI5de1v50=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v1TwlBG4mzrP/0sNti+6tL0h3bB5s0nzGCcuw2MzYHn6jXtfa3bmQ3wtFvf4mZKiv fHDbxLE7odrAAG3NAwuUL2uLg3+OYHryYoisyjbAE9PFc3L4kjeDB7tij1dlJ4+hTo guNybJQ/1rzFiBTcv5p0WxuyQkhO8Uxf+NdK5TiI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba Subject: [PATCH 5.10 06/42] btrfs: avoid double put of block group when emptying cluster Date: Mon, 8 Mar 2021 13:30:32 +0100 Message-Id: <20210308122718.442849402@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Josef Bacik commit 95c85fba1f64c3249c67f0078a29f8a125078189 upstream. It's wrong calling btrfs_put_block_group in __btrfs_return_cluster_to_free_space if the block group passed is different than the block group the cluster represents. As this means the cluster doesn't have a reference to the passed block group. This results in double put and a use-after-free bug. Fix this by simply bailing if the block group we passed in does not match the block group on the cluster. Fixes: fa9c0d795f7b ("Btrfs: rework allocation clustering") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ update changelog ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/free-space-cache.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -2714,8 +2714,10 @@ static void __btrfs_return_cluster_to_fr struct rb_node *node; spin_lock(&cluster->lock); - if (cluster->block_group != block_group) - goto out; + if (cluster->block_group != block_group) { + spin_unlock(&cluster->lock); + return; + } cluster->block_group = NULL; cluster->window_start = 0; @@ -2753,8 +2755,6 @@ static void __btrfs_return_cluster_to_fr entry->offset, &entry->offset_index, bitmap); } cluster->root = RB_ROOT; - -out: spin_unlock(&cluster->lock); btrfs_put_block_group(block_group); } From patchwork Mon Mar 8 12:30:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395909 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E69AC43381 for ; Mon, 8 Mar 2021 12:34:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E603651FF for ; Mon, 8 Mar 2021 12:34:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230460AbhCHMeS (ORCPT ); Mon, 8 Mar 2021 07:34:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:42652 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230124AbhCHMdt (ORCPT ); Mon, 8 Mar 2021 07:33:49 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id ABCB464EBC; Mon, 8 Mar 2021 12:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206829; bh=cAi4nQNijKsWYg8iCBuMfr+4zEf1832AXGofRwk0I40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O+pJosUiZwxvWwBI+kYPrZeN1yqx66E72Pkzn+QjrlPhZ6shCfGvunRtcBiXcR3bN Gr6Y6gD6RSEaCHF5VYPvmPRQMMVTlSz5uoczhp4AgV1zh5fwwHIq+pKKC8dIdp7oj5 SBjqM60yQ7nciH3t+FHOdd+7mXSraPOLuqOdlr0k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Anand Jain , Josef Bacik , Filipe Manana , David Sterba Subject: [PATCH 5.10 08/42] btrfs: fix race between writes to swap files and scrub Date: Mon, 8 Mar 2021 13:30:34 +0100 Message-Id: <20210308122718.541153771@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Filipe Manana commit 195a49eaf655eb914896c92cecd96bc863c9feb3 upstream. When we active a swap file, at btrfs_swap_activate(), we acquire the exclusive operation lock to prevent the physical location of the swap file extents to be changed by operations such as balance and device replace/resize/remove. We also call there can_nocow_extent() which, among other things, checks if the block group of a swap file extent is currently RO, and if it is we can not use the extent, since a write into it would result in COWing the extent. However we have no protection against a scrub operation running after we activate the swap file, which can result in the swap file extents to be COWed while the scrub is running and operating on the respective block group, because scrub turns a block group into RO before it processes it and then back again to RW mode after processing it. That means an attempt to write into a swap file extent while scrub is processing the respective block group, will result in COWing the extent, changing its physical location on disk. Fix this by making sure that block groups that have extents that are used by active swap files can not be turned into RO mode, therefore making it not possible for a scrub to turn them into RO mode. When a scrub finds a block group that can not be turned to RO due to the existence of extents used by swap files, it proceeds to the next block group and logs a warning message that mentions the block group was skipped due to active swap files - this is the same approach we currently use for balance. Fixes: ed46ff3d42378 ("Btrfs: support swap files") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Anand Jain Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/block-group.c | 33 ++++++++++++++++++++++++++++++++- fs/btrfs/block-group.h | 9 +++++++++ fs/btrfs/ctree.h | 5 +++++ fs/btrfs/inode.c | 19 ++++++++++++++++++- fs/btrfs/scrub.c | 9 ++++++++- 5 files changed, 72 insertions(+), 3 deletions(-) --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1229,6 +1229,11 @@ static int inc_block_group_ro(struct btr spin_lock(&sinfo->lock); spin_lock(&cache->lock); + if (cache->swap_extents) { + ret = -ETXTBSY; + goto out; + } + if (cache->ro) { cache->ro++; ret = 0; @@ -2274,7 +2279,7 @@ again: } ret = inc_block_group_ro(cache, 0); - if (!do_chunk_alloc) + if (!do_chunk_alloc || ret == -ETXTBSY) goto unlock_out; if (!ret) goto out; @@ -2283,6 +2288,8 @@ again: if (ret < 0) goto out; ret = inc_block_group_ro(cache, 0); + if (ret == -ETXTBSY) + goto unlock_out; out: if (cache->flags & BTRFS_BLOCK_GROUP_SYSTEM) { alloc_flags = btrfs_get_alloc_profile(fs_info, cache->flags); @@ -3363,6 +3370,7 @@ int btrfs_free_block_groups(struct btrfs ASSERT(list_empty(&block_group->io_list)); ASSERT(list_empty(&block_group->bg_list)); ASSERT(refcount_read(&block_group->refs) == 1); + ASSERT(block_group->swap_extents == 0); btrfs_put_block_group(block_group); spin_lock(&info->block_group_cache_lock); @@ -3429,3 +3437,26 @@ void btrfs_unfreeze_block_group(struct b __btrfs_remove_free_space_cache(block_group->free_space_ctl); } } + +bool btrfs_inc_block_group_swap_extents(struct btrfs_block_group *bg) +{ + bool ret = true; + + spin_lock(&bg->lock); + if (bg->ro) + ret = false; + else + bg->swap_extents++; + spin_unlock(&bg->lock); + + return ret; +} + +void btrfs_dec_block_group_swap_extents(struct btrfs_block_group *bg, int amount) +{ + spin_lock(&bg->lock); + ASSERT(!bg->ro); + ASSERT(bg->swap_extents >= amount); + bg->swap_extents -= amount; + spin_unlock(&bg->lock); +} --- a/fs/btrfs/block-group.h +++ b/fs/btrfs/block-group.h @@ -181,6 +181,12 @@ struct btrfs_block_group { */ int needs_free_space; + /* + * Number of extents in this block group used for swap files. + * All accesses protected by the spinlock 'lock'. + */ + int swap_extents; + /* Record locked full stripes for RAID5/6 block group */ struct btrfs_full_stripe_locks_tree full_stripe_locks_root; }; @@ -299,4 +305,7 @@ int btrfs_rmap_block(struct btrfs_fs_inf u64 physical, u64 **logical, int *naddrs, int *stripe_len); #endif +bool btrfs_inc_block_group_swap_extents(struct btrfs_block_group *bg); +void btrfs_dec_block_group_swap_extents(struct btrfs_block_group *bg, int amount); + #endif /* BTRFS_BLOCK_GROUP_H */ --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -522,6 +522,11 @@ struct btrfs_swapfile_pin { * points to a struct btrfs_device. */ bool is_block_group; + /* + * Only used when 'is_block_group' is true and it is the number of + * extents used by a swapfile for this block group ('ptr' field). + */ + int bg_extent_count; }; bool btrfs_pinned_by_swapfile(struct btrfs_fs_info *fs_info, void *ptr); --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9993,6 +9993,7 @@ static int btrfs_add_swapfile_pin(struct sp->ptr = ptr; sp->inode = inode; sp->is_block_group = is_block_group; + sp->bg_extent_count = 1; spin_lock(&fs_info->swapfile_pins_lock); p = &fs_info->swapfile_pins.rb_node; @@ -10006,6 +10007,8 @@ static int btrfs_add_swapfile_pin(struct (sp->ptr == entry->ptr && sp->inode > entry->inode)) { p = &(*p)->rb_right; } else { + if (is_block_group) + entry->bg_extent_count++; spin_unlock(&fs_info->swapfile_pins_lock); kfree(sp); return 1; @@ -10031,8 +10034,11 @@ static void btrfs_free_swapfile_pins(str sp = rb_entry(node, struct btrfs_swapfile_pin, node); if (sp->inode == inode) { rb_erase(&sp->node, &fs_info->swapfile_pins); - if (sp->is_block_group) + if (sp->is_block_group) { + btrfs_dec_block_group_swap_extents(sp->ptr, + sp->bg_extent_count); btrfs_put_block_group(sp->ptr); + } kfree(sp); } node = next; @@ -10246,6 +10252,17 @@ static int btrfs_swap_activate(struct sw ret = -EINVAL; goto out; } + + if (!btrfs_inc_block_group_swap_extents(bg)) { + btrfs_warn(fs_info, + "block group for swapfile at %llu is read-only%s", + bg->start, + atomic_read(&fs_info->scrubs_running) ? + " (scrub running)" : ""); + btrfs_put_block_group(bg); + ret = -EINVAL; + goto out; + } ret = btrfs_add_swapfile_pin(inode, bg, true); if (ret) { --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -3568,6 +3568,13 @@ int scrub_enumerate_chunks(struct scrub_ * commit_transactions. */ ro_set = 0; + } else if (ret == -ETXTBSY) { + btrfs_warn(fs_info, + "skipping scrub of block group %llu due to active swapfile", + cache->start); + scrub_pause_off(fs_info); + ret = 0; + goto skip_unfreeze; } else { btrfs_warn(fs_info, "failed setting block group ro: %d", ret); @@ -3657,7 +3664,7 @@ int scrub_enumerate_chunks(struct scrub_ } else { spin_unlock(&cache->lock); } - +skip_unfreeze: btrfs_unfreeze_block_group(cache); btrfs_put_block_group(cache); if (ret) From patchwork Mon Mar 8 12:30:38 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395913 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84BADC43331 for ; Mon, 8 Mar 2021 12:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E9EA651D3 for ; Mon, 8 Mar 2021 12:34:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230488AbhCHMdm (ORCPT ); Mon, 8 Mar 2021 07:33:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:42370 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229904AbhCHMdZ (ORCPT ); Mon, 8 Mar 2021 07:33:25 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C313364EBC; Mon, 8 Mar 2021 12:33:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206805; bh=wzhuPkANCXCaekNYRQaxmpc/vxCAdUc0q3IvCWdgKbk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UQRe60Z0n2M2BJ8KYlxnJFi7lBNtiHdcFAttnpSSwNY+nXRVSoTtH3UHv2GD6Rqe3 Yb6KOvPm9GGpKRdqW1V2KR3IBJTvzMLgY3EOz/pYuY4mLsk43zmfcEx9n2lW1AB2A7 4kmJO71zuej91T2R8xwnTosXs9ZOHxByM+OfREMw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , David Sterba Subject: [PATCH 5.10 12/42] btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl Date: Mon, 8 Mar 2021 13:30:38 +0100 Message-Id: <20210308122718.731384148@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dan Carpenter commit 5011c5a663b9c6d6aff3d394f11049b371199627 upstream. The problem is we're copying "inherit" from user space but we don't necessarily know that we're copying enough data for a 64 byte struct. Then the next problem is that 'inherit' has a variable size array at the end, and we have to verify that array is the size we expected. Fixes: 6f72c7e20dba ("Btrfs: add qgroup inheritance") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/ioctl.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1914,7 +1914,10 @@ static noinline int btrfs_ioctl_snap_cre if (vol_args->flags & BTRFS_SUBVOL_RDONLY) readonly = true; if (vol_args->flags & BTRFS_SUBVOL_QGROUP_INHERIT) { - if (vol_args->size > PAGE_SIZE) { + u64 nums; + + if (vol_args->size < sizeof(*inherit) || + vol_args->size > PAGE_SIZE) { ret = -EINVAL; goto free_args; } @@ -1923,6 +1926,20 @@ static noinline int btrfs_ioctl_snap_cre ret = PTR_ERR(inherit); goto free_args; } + + if (inherit->num_qgroups > PAGE_SIZE || + inherit->num_ref_copies > PAGE_SIZE || + inherit->num_excl_copies > PAGE_SIZE) { + ret = -EINVAL; + goto free_inherit; + } + + nums = inherit->num_qgroups + 2 * inherit->num_ref_copies + + 2 * inherit->num_excl_copies; + if (vol_args->size != struct_size(inherit, qgroups, nums)) { + ret = -EINVAL; + goto free_inherit; + } } ret = __btrfs_ioctl_snap_create(file, vol_args->name, vol_args->fd, From patchwork Mon Mar 8 12:30:39 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395911 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AA4DC4332D for ; Mon, 8 Mar 2021 12:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33CD1651DE for ; Mon, 8 Mar 2021 12:34:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230512AbhCHMdm (ORCPT ); Mon, 8 Mar 2021 07:33:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:42388 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230046AbhCHMd2 (ORCPT ); Mon, 8 Mar 2021 07:33:28 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 57F73651C9; Mon, 8 Mar 2021 12:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206807; bh=vU+pvwp5dlACVFnrSOUzkjpmXmMpOWVu0r+vg3eKMbs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZvMwekgxUEeD/WmLqWVILb3mPnAuoJj3HJtQrgspLMi36BucoVjOs7Bc0a4EWoriZ 2mXMqnIZgfdlcqPlFBYajUizIbCyFwaEqPyizcASiAr0OGtGKMtmyxYuFjHBCGMO8c sCOAOlBVc9O2GFbdTnAGftQZ7aMSDXbQu2dtGGSs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qu Wenruo , Nikolay Borisov , David Sterba Subject: [PATCH 5.10 13/42] btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata Date: Mon, 8 Mar 2021 13:30:39 +0100 Message-Id: <20210308122718.784006137@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Nikolay Borisov commit 0f9c03d824f6f522d3bc43629635c9765546ebc5 upstream. Following commit f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") this function now reserves num_bytes, rather than the fixed amount of nodesize. As such this requires the same amount to be freed in case of failure. Fix this by adjusting the amount we are freeing. Fixes: f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/delayed-inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -649,7 +649,7 @@ static int btrfs_delayed_inode_reserve_m btrfs_ino(inode), num_bytes, 1); } else { - btrfs_qgroup_free_meta_prealloc(root, fs_info->nodesize); + btrfs_qgroup_free_meta_prealloc(root, num_bytes); } return ret; } From patchwork Mon Mar 8 12:30:41 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395908 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0222C43331 for ; Mon, 8 Mar 2021 12:34:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 81A60651D3 for ; Mon, 8 Mar 2021 12:34:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230113AbhCHMeV (ORCPT ); Mon, 8 Mar 2021 07:34:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:42734 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231203AbhCHMd5 (ORCPT ); Mon, 8 Mar 2021 07:33:57 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E89CF651C3; Mon, 8 Mar 2021 12:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206837; bh=2McWRBxUwSx2egTeDxtKrJL6qhs5FY+OLg2fcUVemVs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=035eL9zY7fQDu9FsHNtnkkv+1xUzzfUFQCY+tD33aMWe6dxZVbTYNnM7WO8bzcXzx 4v4Ur4qCL8l/SixeuUg//7ieNyAIhZxUPF/VqkGM1Z7vBQ6FQ9UufBAoCJdYAI5BPV jj0ObUrAplsaITuw5faQqGkEdPwdxZhdfiV7PUZw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Casey Schaufler , Filipe Manana , David Sterba Subject: [PATCH 5.10 15/42] btrfs: fix warning when creating a directory with smack enabled Date: Mon, 8 Mar 2021 13:30:41 +0100 Message-Id: <20210308122718.890230109@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Filipe Manana commit fd57a98d6f0c98fa295813087f13afb26c224e73 upstream. When we have smack enabled, during the creation of a directory smack may attempt to add a "smack transmute" xattr on the inode, which results in the following warning and trace: WARNING: CPU: 3 PID: 2548 at fs/btrfs/transaction.c:537 start_transaction+0x489/0x4f0 Modules linked in: nft_objref nf_conntrack_netbios_ns (...) CPU: 3 PID: 2548 Comm: mkdir Not tainted 5.9.0-rc2smack+ #81 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:start_transaction+0x489/0x4f0 Code: e9 be fc ff ff (...) RSP: 0018:ffffc90001887d10 EFLAGS: 00010202 RAX: ffff88816f1e0000 RBX: 0000000000000201 RCX: 0000000000000003 RDX: 0000000000000201 RSI: 0000000000000002 RDI: ffff888177849000 RBP: ffff888177849000 R08: 0000000000000001 R09: 0000000000000004 R10: ffffffff825e8f7a R11: 0000000000000003 R12: ffffffffffffffe2 R13: 0000000000000000 R14: ffff88803d884270 R15: ffff8881680d8000 FS: 00007f67317b8440(0000) GS:ffff88817bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f67247a22a8 CR3: 000000004bfbc002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? slab_free_freelist_hook+0xea/0x1b0 ? trace_hardirqs_on+0x1c/0xe0 btrfs_setxattr_trans+0x3c/0xf0 __vfs_setxattr+0x63/0x80 smack_d_instantiate+0x2d3/0x360 security_d_instantiate+0x29/0x40 d_instantiate_new+0x38/0x90 btrfs_mkdir+0x1cf/0x1e0 vfs_mkdir+0x14f/0x200 do_mkdirat+0x6d/0x110 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f673196ae6b Code: 8b 05 11 (...) RSP: 002b:00007ffc3c679b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000000001ff RCX: 00007f673196ae6b RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007ffc3c67a30d RBP: 00007ffc3c67a30d R08: 00000000000001ff R09: 0000000000000000 R10: 000055d3e39fe930 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc3c679cd8 R14: 00007ffc3c67a30d R15: 00007ffc3c679ce0 irq event stamp: 11029 hardirqs last enabled at (11037): [] console_unlock+0x486/0x670 hardirqs last disabled at (11044): [] console_unlock+0xa1/0x670 softirqs last enabled at (8864): [] asm_call_on_stack+0xf/0x20 softirqs last disabled at (8851): [] asm_call_on_stack+0xf/0x20 This happens because at btrfs_mkdir() we call d_instantiate_new() while holding a transaction handle, which results in the following call chain: btrfs_mkdir() trans = btrfs_start_transaction(root, 5); d_instantiate_new() smack_d_instantiate() __vfs_setxattr() btrfs_setxattr_trans() btrfs_start_transaction() start_transaction() WARN_ON() --> a tansaction start has TRANS_EXTWRITERS set in its type h->orig_rsv = h->block_rsv h->block_rsv = NULL btrfs_end_transaction(trans) Besides the warning triggered at start_transaction, we set the handle's block_rsv to NULL which may cause some surprises later on. So fix this by making btrfs_setxattr_trans() not start a transaction when we already have a handle on one, stored in current->journal_info, and use that handle. We are good to use the handle because at btrfs_mkdir() we did reserve space for the xattr and the inode item. Reported-by: Casey Schaufler CC: stable@vger.kernel.org # 5.4+ Acked-by: Casey Schaufler Tested-by: Casey Schaufler Link: https://lore.kernel.org/linux-btrfs/434d856f-bd7b-4889-a6ec-e81aaebfa735@schaufler-ca.com/ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/xattr.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) --- a/fs/btrfs/xattr.c +++ b/fs/btrfs/xattr.c @@ -229,11 +229,33 @@ int btrfs_setxattr_trans(struct inode *i { struct btrfs_root *root = BTRFS_I(inode)->root; struct btrfs_trans_handle *trans; + const bool start_trans = (current->journal_info == NULL); int ret; - trans = btrfs_start_transaction(root, 2); - if (IS_ERR(trans)) - return PTR_ERR(trans); + if (start_trans) { + /* + * 1 unit for inserting/updating/deleting the xattr + * 1 unit for the inode item update + */ + trans = btrfs_start_transaction(root, 2); + if (IS_ERR(trans)) + return PTR_ERR(trans); + } else { + /* + * This can happen when smack is enabled and a directory is being + * created. It happens through d_instantiate_new(), which calls + * smack_d_instantiate(), which in turn calls __vfs_setxattr() to + * set the transmute xattr (XATTR_NAME_SMACKTRANSMUTE) on the + * inode. We have already reserved space for the xattr and inode + * update at btrfs_mkdir(), so just use the transaction handle. + * We don't join or start a transaction, as that will reset the + * block_rsv of the handle and trigger a warning for the start + * case. + */ + ASSERT(strncmp(name, XATTR_SECURITY_PREFIX, + XATTR_SECURITY_PREFIX_LEN) == 0); + trans = current->journal_info; + } ret = btrfs_setxattr(trans, inode, name, value, size, flags); if (ret) @@ -244,7 +266,8 @@ int btrfs_setxattr_trans(struct inode *i ret = btrfs_update_inode(trans, root, inode); BUG_ON(ret); out: - btrfs_end_transaction(trans); + if (start_trans) + btrfs_end_transaction(trans); return ret; } From patchwork Mon Mar 8 12:30:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395896 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7AD5C43333 for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C7D47651CF for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230250AbhCHMfU (ORCPT ); Mon, 8 Mar 2021 07:35:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:44178 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231934AbhCHMfE (ORCPT ); Mon, 8 Mar 2021 07:35:04 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C9145651CF; Mon, 8 Mar 2021 12:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206904; bh=+RgNA1ZBYhKK+ZrC08MdTJPnKPajaLov2A12pLs/go0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kRL23qf3Km1q/fDQ/MKJS0Rb1dKz5Cc80ipvrIgz669edoGCp74VICncFU+xe+mOI Vm0YpQRK580eMw+7nrQxvN1QQnrRkLJbO9We3D/TRwLvL9N77u4GP7r3/pz3yEmqwi xvVIOJqlnE5KJ5MaJ5xY3lq2tbMTptsH0gMlpKP4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Milan Broz , =?utf-8?b?SsOpcsO0bWUgQ2FycmV0ZXJv?= , Sami Tolvanen , Mike Snitzer Subject: [PATCH 5.10 20/42] dm verity: fix FEC for RS roots unaligned to block size Date: Mon, 8 Mar 2021 13:30:46 +0100 Message-Id: <20210308122719.122169408@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Milan Broz commit df7b59ba9245c4a3115ebaa905e3e5719a3810da upstream. Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24. The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding. Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes). Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes. This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.) Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it. The problem is easily reproduced using veritysetup, e.g. for roots=13: # create verity device with RS FEC dd if=/dev/urandom of=data.img bs=4096 count=8 status=none veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash # create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none # try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test With this fix, errors are properly repaired. device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors ... Without it, FEC code usually ends on unrecoverable failure in RS decoder: device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74 ... This problem is present in all kernels since the FEC code's introduction (kernel 4.5). It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2. Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size") Signed-off-by: Milan Broz Tested-by: Jérôme Carretero Reviewed-by: Sami Tolvanen Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman --- drivers/md/dm-verity-fec.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) --- a/drivers/md/dm-verity-fec.c +++ b/drivers/md/dm-verity-fec.c @@ -61,19 +61,18 @@ static int fec_decode_rs8(struct dm_veri static u8 *fec_read_parity(struct dm_verity *v, u64 rsb, int index, unsigned *offset, struct dm_buffer **buf) { - u64 position, block; + u64 position, block, rem; u8 *res; position = (index + rsb) * v->fec->roots; - block = position >> v->data_dev_block_bits; - *offset = (unsigned)(position - (block << v->data_dev_block_bits)); + block = div64_u64_rem(position, v->fec->roots << SECTOR_SHIFT, &rem); + *offset = (unsigned)rem; - res = dm_bufio_read(v->fec->bufio, v->fec->start + block, buf); + res = dm_bufio_read(v->fec->bufio, block, buf); if (IS_ERR(res)) { DMERR("%s: FEC %llu: parity read failed (block %llu): %ld", v->data_dev->name, (unsigned long long)rsb, - (unsigned long long)(v->fec->start + block), - PTR_ERR(res)); + (unsigned long long)block, PTR_ERR(res)); *buf = NULL; } @@ -155,7 +154,7 @@ static int fec_decode_bufs(struct dm_ver /* read the next block when we run out of parity bytes */ offset += v->fec->roots; - if (offset >= 1 << v->data_dev_block_bits) { + if (offset >= v->fec->roots << SECTOR_SHIFT) { dm_bufio_release(buf); par = fec_read_parity(v, rsb, block_offset, &offset, &buf); @@ -674,7 +673,7 @@ int verity_fec_ctr(struct dm_verity *v) { struct dm_verity_fec *f = v->fec; struct dm_target *ti = v->ti; - u64 hash_blocks; + u64 hash_blocks, fec_blocks; int ret; if (!verity_fec_is_enabled(v)) { @@ -744,15 +743,17 @@ int verity_fec_ctr(struct dm_verity *v) } f->bufio = dm_bufio_client_create(f->dev->bdev, - 1 << v->data_dev_block_bits, + f->roots << SECTOR_SHIFT, 1, 0, NULL, NULL); if (IS_ERR(f->bufio)) { ti->error = "Cannot initialize FEC bufio client"; return PTR_ERR(f->bufio); } - if (dm_bufio_get_device_size(f->bufio) < - ((f->start + f->rounds * f->roots) >> v->data_dev_block_bits)) { + dm_bufio_set_sector_offset(f->bufio, f->start << (v->data_dev_block_bits - SECTOR_SHIFT)); + + fec_blocks = div64_u64(f->rounds * f->roots, v->fec->roots << SECTOR_SHIFT); + if (dm_bufio_get_device_size(f->bufio) < fec_blocks) { ti->error = "FEC device is too small"; return -E2BIG; } From patchwork Mon Mar 8 12:30:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395894 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46E09C43603 for ; Mon, 8 Mar 2021 12:35:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 097F6651CF for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230078AbhCHMfV (ORCPT ); Mon, 8 Mar 2021 07:35:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:44216 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232064AbhCHMfL (ORCPT ); Mon, 8 Mar 2021 07:35:11 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6E54864EBC; Mon, 8 Mar 2021 12:35:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206910; bh=Rh/ElCYixtjbU3HjllVEZDy8BptIUC+6CwBIuGiiYNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pkc4HSWIGGntrRL9r9t8v+rMYifDfyR8PUEHSwgXs12Pd/5Zp5Q0GZdRfo2aowz9D sQ1qV9hO+klQvxZp0Fbbb1M2YAvNhPlZVPo/o7XrIwivYki8bf33gNPkJ2Xa0WW79/ ZhPSLGI/vL6tEIDb8ToNwlQRPaAvwiNoaVh0wDdE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kevin Wang , Lijo Lazar , Alex Deucher Subject: [PATCH 5.10 22/42] drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie Date: Mon, 8 Mar 2021 13:30:48 +0100 Message-Id: <20210308122719.214925954@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kevin Wang commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff upstream. the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c @@ -355,7 +355,7 @@ static ssize_t amdgpu_debugfs_regs_pcie_ while (size) { uint32_t value; - value = RREG32_PCIE(*pos >> 2); + value = RREG32_PCIE(*pos); r = put_user(value, (uint32_t *)buf); if (r) { pm_runtime_mark_last_busy(adev_to_drm(adev)->dev); @@ -422,7 +422,7 @@ static ssize_t amdgpu_debugfs_regs_pcie_ return r; } - WREG32_PCIE(*pos >> 2, value); + WREG32_PCIE(*pos, value); result += 4; buf += 4; From patchwork Mon Mar 8 12:30:49 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395895 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09707C432C3 for ; Mon, 8 Mar 2021 12:35:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0E036520E for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230410AbhCHMfW (ORCPT ); Mon, 8 Mar 2021 07:35:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:44232 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231864AbhCHMfN (ORCPT ); Mon, 8 Mar 2021 07:35:13 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A8086651C9; Mon, 8 Mar 2021 12:35:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206913; bh=YDVCP2lX8XkTA53jIjKsJ0XzxGvlpkbhjDHf1OVepeM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LhcbSqSXfd2HcXhfiqfOJ8s0/JJcpZetfYcnufefvuw2CKilEONZfWHpR6zNRU1mG 1xy+gUT4K6Cw8On5Jc/UuUUasVJ/p3oAmVXsZiV4IdeUu1SvEa2rvM7tMQ8ii4AgX3 ruZSDvF4s5brOeUerejRwh0c4ggj7o4YPEwxBkUE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , Herbert Xu Subject: [PATCH 5.10 23/42] crypto - shash: reduce minimum alignment of shash_desc structure Date: Mon, 8 Mar 2021 13:30:49 +0100 Message-Id: <20210308122719.264148779@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ard Biesheuvel commit 660d2062190db131d2feaf19914e90f868fe285c upstream. Unlike many other structure types defined in the crypto API, the 'shash_desc' structure is permitted to live on the stack, which implies its contents may not be accessed by DMA masters. (This is due to the fact that the stack may be located in the vmalloc area, which requires a different virtual-to-physical translation than the one implemented by the DMA subsystem) Our definition of CRYPTO_MINALIGN_ATTR is based on ARCH_KMALLOC_MINALIGN, which may take DMA constraints into account on architectures that support non-cache coherent DMA such as ARM and arm64. In this case, the value is chosen to reflect the largest cacheline size in the system, in order to ensure that explicit cache maintenance as required by non-coherent DMA masters does not affect adjacent, unrelated slab allocations. On arm64, this value is currently set at 128 bytes. This means that applying CRYPTO_MINALIGN_ATTR to struct shash_desc is both unnecessary (as it is never used for DMA), and undesirable, given that it wastes stack space (on arm64, performing the alignment costs 112 bytes in the worst case, and the hole between the 'tfm' and '__ctx' members takes up another 120 bytes, resulting in an increased stack footprint of up to 232 bytes.) So instead, let's switch to the minimum SLAB alignment, which does not take DMA constraints into account. Note that this is a no-op for x86. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman --- include/crypto/hash.h | 8 ++++---- include/linux/crypto.h | 9 ++++++--- 2 files changed, 10 insertions(+), 7 deletions(-) --- a/include/crypto/hash.h +++ b/include/crypto/hash.h @@ -149,7 +149,7 @@ struct ahash_alg { struct shash_desc { struct crypto_shash *tfm; - void *__ctx[] CRYPTO_MINALIGN_ATTR; + void *__ctx[] __aligned(ARCH_SLAB_MINALIGN); }; #define HASH_MAX_DIGESTSIZE 64 @@ -162,9 +162,9 @@ struct shash_desc { #define HASH_MAX_STATESIZE 512 -#define SHASH_DESC_ON_STACK(shash, ctx) \ - char __##shash##_desc[sizeof(struct shash_desc) + \ - HASH_MAX_DESCSIZE] CRYPTO_MINALIGN_ATTR; \ +#define SHASH_DESC_ON_STACK(shash, ctx) \ + char __##shash##_desc[sizeof(struct shash_desc) + HASH_MAX_DESCSIZE] \ + __aligned(__alignof__(struct shash_desc)); \ struct shash_desc *shash = (struct shash_desc *)__##shash##_desc /** --- a/include/linux/crypto.h +++ b/include/linux/crypto.h @@ -151,9 +151,12 @@ * The macro CRYPTO_MINALIGN_ATTR (along with the void * type in the actual * declaration) is used to ensure that the crypto_tfm context structure is * aligned correctly for the given architecture so that there are no alignment - * faults for C data types. In particular, this is required on platforms such - * as arm where pointers are 32-bit aligned but there are data types such as - * u64 which require 64-bit alignment. + * faults for C data types. On architectures that support non-cache coherent + * DMA, such as ARM or arm64, it also takes into account the minimal alignment + * that is required to ensure that the context struct member does not share any + * cachelines with the rest of the struct. This is needed to ensure that cache + * maintenance for non-coherent DMA (cache invalidation in particular) does not + * affect data that may be accessed by the CPU concurrently. */ #define CRYPTO_MINALIGN ARCH_KMALLOC_MINALIGN From patchwork Mon Mar 8 12:30:51 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395906 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41D17C43333 for ; Mon, 8 Mar 2021 12:34:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 08A40651D3 for ; Mon, 8 Mar 2021 12:34:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231204AbhCHMeW (ORCPT ); Mon, 8 Mar 2021 07:34:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:42772 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230475AbhCHMeD (ORCPT ); Mon, 8 Mar 2021 07:34:03 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8F8AB651C3; Mon, 8 Mar 2021 12:34:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206843; bh=rgtfOThl5RleC5R0DkgkKuXN24d/MZxjLtdFDzxwxTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CISCgB6k9xG/0G6YCufYgjNp4cij19x8wmLbuEqQpkSZ/VgMM4KWq/JwpDg8K2Bfh rPea+/DohbEQ1Myzs/azzWx6v/dEzSapLQbggb1XTGwsf8COG2vwFxpzbipnadZKbv odFinUyrEj44MRv0asy4ELRMSPH4xKrFEs/y3vc8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Saenz Julienne , Jeremy Linton , Catalin Marinas , Jing Xiangfeng Subject: [PATCH 5.10 25/42] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() Date: Mon, 8 Mar 2021 13:30:51 +0100 Message-Id: <20210308122719.366047742@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Nicolas Saenz Julienne commit 9804f8c69b04a39d0ba41d19e6bdc6aa91c19725 upstream zone_dma_bits's initialization happens earlier that it's actually needed, in arm64_memblock_init(). So move it into the more suitable zone_sizes_init(). Signed-off-by: Nicolas Saenz Julienne Tested-by: Jeremy Linton Link: https://lore.kernel.org/r/20201119175400.9995-3-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman --- arch/arm64/mm/init.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -190,6 +190,8 @@ static void __init zone_sizes_init(unsig unsigned long max_zone_pfns[MAX_NR_ZONES] = {0}; #ifdef CONFIG_ZONE_DMA + zone_dma_bits = ARM64_ZONE_DMA_BITS; + arm64_dma_phys_limit = max_zone_phys(zone_dma_bits); max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); #endif #ifdef CONFIG_ZONE_DMA32 @@ -376,11 +378,6 @@ void __init arm64_memblock_init(void) early_init_fdt_scan_reserved_mem(); - if (IS_ENABLED(CONFIG_ZONE_DMA)) { - zone_dma_bits = ARM64_ZONE_DMA_BITS; - arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS); - } - if (IS_ENABLED(CONFIG_ZONE_DMA32)) arm64_dma32_phys_limit = max_zone_phys(32); else From patchwork Mon Mar 8 12:30:52 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395907 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0423EC43332 for ; Mon, 8 Mar 2021 12:34:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1FF8651C3 for ; Mon, 8 Mar 2021 12:34:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231255AbhCHMeW (ORCPT ); Mon, 8 Mar 2021 07:34:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:42802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhCHMeG (ORCPT ); Mon, 8 Mar 2021 07:34:06 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7631B651DC; Mon, 8 Mar 2021 12:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206846; bh=8/sAaKwax+Ge2FF1sEl2qj5pzin6DpC3zaVom/++uhk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hks8KXwzBiytI2jQLi6h6ciSkAQDqS4zsTrQ1CTjqNWxR/I8N78FRfrCrPtWKk0Ly FIOJ7yNZTUdaLNX9nL9CziptKbPuBmWxkp0E4r4vZBZG936oLiHR3iUQBalUvMuXcv MoeZEWJpRZ61/pcPO5qYKN0+QBM6Zit2IxlpsK4k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Saenz Julienne , Rob Herring , Catalin Marinas , Jing Xiangfeng Subject: [PATCH 5.10 26/42] of/address: Introduce of_dma_get_max_cpu_address() Date: Mon, 8 Mar 2021 13:30:52 +0100 Message-Id: <20210308122719.416632219@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Nicolas Saenz Julienne commit 964db79d6c186cc2ecc6ae46f98eed7e0ea8cf71 upstream Introduce of_dma_get_max_cpu_address(), which provides the highest CPU physical address addressable by all DMA masters in the system. It's specially useful for setting memory zones sizes at early boot time. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman --- drivers/of/address.c | 42 ++++++++++++++++++++++++++++++++++++++++++ include/linux/of.h | 7 +++++++ 2 files changed, 49 insertions(+) --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -1025,6 +1025,48 @@ out: #endif /* CONFIG_HAS_DMA */ /** + * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA + * @np: The node to start searching from or NULL to start from the root + * + * Gets the highest CPU physical address that is addressable by all DMA masters + * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no + * DMA constrained device is found, it returns PHYS_ADDR_MAX. + */ +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np) +{ + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX; + struct of_range_parser parser; + phys_addr_t subtree_max_addr; + struct device_node *child; + struct of_range range; + const __be32 *ranges; + u64 cpu_end = 0; + int len; + + if (!np) + np = of_root; + + ranges = of_get_property(np, "dma-ranges", &len); + if (ranges && len) { + of_dma_range_parser_init(&parser, np); + for_each_of_range(&parser, &range) + if (range.cpu_addr + range.size > cpu_end) + cpu_end = range.cpu_addr + range.size - 1; + + if (max_cpu_addr > cpu_end) + max_cpu_addr = cpu_end; + } + + for_each_available_child_of_node(np, child) { + subtree_max_addr = of_dma_get_max_cpu_address(child); + if (max_cpu_addr > subtree_max_addr) + max_cpu_addr = subtree_max_addr; + } + + return max_cpu_addr; +} + +/** * of_dma_is_coherent - Check if device is coherent * @np: device node * --- a/include/linux/of.h +++ b/include/linux/of.h @@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u3 const char *map_name, const char *map_mask_name, struct device_node **target, u32 *id_out); +phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); + #else /* CONFIG_OF */ static inline void of_core_init(void) @@ -995,6 +997,11 @@ static inline int of_map_id(struct devic return -EINVAL; } +static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np) +{ + return PHYS_ADDR_MAX; +} + #define of_match_ptr(_ptr) NULL #define of_match_node(_matches, _node) NULL #endif /* CONFIG_OF */ From patchwork Mon Mar 8 12:30:53 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395905 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24A50C433E0 for ; Mon, 8 Mar 2021 12:35:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D4284651DC for ; Mon, 8 Mar 2021 12:35:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231881AbhCHMeo (ORCPT ); Mon, 8 Mar 2021 07:34:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:42834 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbhCHMeJ (ORCPT ); Mon, 8 Mar 2021 07:34:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 67724651CF; Mon, 8 Mar 2021 12:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206848; bh=F5akjDWHp3LV9bRAZxw84XdwjvgbxiVEz7QpotCOHbs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y2/pI5y0cw3ohcO89n/4/mOoj/9GI+r2WTz3ZClYtq+BP2uXd6WB8bALsQ3ugdmWr GBTOCqeby0fLW8Yb9DM1QP6qex87JSAQvckHyQ+WQlGPte6KtIZhx8MCdjjuBBEOuy rlfGt4E1JsN8EwGXBTRres6g1RRMGx+p+dMHicoU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Saenz Julienne , Rob Herring , Catalin Marinas , Jing Xiangfeng Subject: [PATCH 5.10 27/42] of: unittest: Add test for of_dma_get_max_cpu_address() Date: Mon, 8 Mar 2021 13:30:53 +0100 Message-Id: <20210308122719.466319281@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Nicolas Saenz Julienne commit 07d13a1d6120d453c3c1f020578693d072deded5 upstream Introduce a test for of_dma_get_max_cup_address(), it uses the same DT data as the rest of dma-ranges unit tests. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman --- drivers/of/unittest.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/of/unittest.c +++ b/drivers/of/unittest.c @@ -869,6 +869,23 @@ static void __init of_unittest_changeset #endif } +static void __init of_unittest_dma_get_max_cpu_address(void) +{ + struct device_node *np; + phys_addr_t cpu_addr; + + np = of_find_node_by_path("/testcase-data/address-tests"); + if (!np) { + pr_err("missing testcase data\n"); + return; + } + + cpu_addr = of_dma_get_max_cpu_address(np); + unittest(cpu_addr == 0x4fffffff, + "of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting %x)\n", + &cpu_addr, 0x4fffffff); +} + static void __init of_unittest_dma_ranges_one(const char *path, u64 expect_dma_addr, u64 expect_paddr) { @@ -3266,6 +3283,7 @@ static int __init of_unittest(void) of_unittest_changeset(); of_unittest_parse_interrupts(); of_unittest_parse_interrupts_extended(); + of_unittest_dma_get_max_cpu_address(); of_unittest_parse_dma_ranges(); of_unittest_pci_dma_ranges(); of_unittest_match_node(); From patchwork Mon Mar 8 12:30:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395903 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43EA7C433E6 for ; Mon, 8 Mar 2021 12:35:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E9E2651CF for ; Mon, 8 Mar 2021 12:35:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229756AbhCHMep (ORCPT ); Mon, 8 Mar 2021 07:34:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:42926 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229674AbhCHMeO (ORCPT ); Mon, 8 Mar 2021 07:34:14 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C545651C3; Mon, 8 Mar 2021 12:34:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206853; bh=ZJ2P9Sn9EZ2ds0a2af3EMkmaDD1/NP4KPE/I4wlxXfg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GBGtE3kDXJP1c9pyvC6NMcaxY+L9TEULppeCfjmwm4ldJlxv3dZPENtO2wGoWZn8/ l4MJU2nMFWnk3C3JrQ5teHZhVoLll/j9/jJsmN+RLVqTGvG3ZgtC5ovtqoC7SMUZA7 RIx0nsU++yzNU0Ttc/YqSZO+pa5nKKx8UcQw8UOQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , Nicolas Saenz Julienne , Jeremy Linton , Lorenzo Pieralisi , Hanjun Guo , Rob Herring , Christoph Hellwig , Robin Murphy , Sudeep Holla , Anshuman Khandual , Catalin Marinas , Jing Xiangfeng Subject: [PATCH 5.10 29/42] arm64: mm: Set ZONE_DMA size based on early IORT scan Date: Mon, 8 Mar 2021 13:30:55 +0100 Message-Id: <20210308122719.557568557@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ard Biesheuvel commit 2b8652936f0ca9ca2e6c984ae76c7bfcda1b3f22 upstream We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge can only access the bottom 3 GB) Instructing the DMA layer about these limitations is straight-forward, even though we had to fix some issues regarding memory limits set in the IORT for named components, and regarding the handling of ACPI _DMA methods. However, the DMA layer also needs to be able to allocate memory that is guaranteed to meet those DMA constraints, for bounce buffering as well as allocating the backing for consistent mappings. This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately, it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and potentially in other places where allocations cannot cross zone boundaries. Therefore, we should avoid having two separate DMA zones when possible. So let's do an early scan of the IORT, and only create the ZONE_DMA if we encounter any devices that need it. This puts the burden on the firmware to describe such limitations in the IORT, which may be redundant (and less precise) if _DMA methods are also being provided. However, it should be noted that this situation is highly unusual for arm64 ACPI machines. Also, the DMA subsystem still gives precedence to the _DMA method if implemented, and so we will not lose the ability to perform streaming DMA outside the ZONE_DMA if the _DMA method permits it. [nsaenz: unified implementation with DT's counterpart] Signed-off-by: Ard Biesheuvel Signed-off-by: Nicolas Saenz Julienne Tested-by: Jeremy Linton Acked-by: Lorenzo Pieralisi Acked-by: Hanjun Guo Cc: Jeremy Linton Cc: Lorenzo Pieralisi Cc: Nicolas Saenz Julienne Cc: Rob Herring Cc: Christoph Hellwig Cc: Robin Murphy Cc: Hanjun Guo Cc: Sudeep Holla Cc: Anshuman Khandual Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman --- arch/arm64/mm/init.c | 5 +++- drivers/acpi/arm64/iort.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/acpi_iort.h | 4 +++ 3 files changed, 63 insertions(+), 1 deletion(-) --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -186,11 +187,13 @@ static phys_addr_t __init max_zone_phys( static void __init zone_sizes_init(unsigned long min, unsigned long max) { unsigned long max_zone_pfns[MAX_NR_ZONES] = {0}; + unsigned int __maybe_unused acpi_zone_dma_bits; unsigned int __maybe_unused dt_zone_dma_bits; #ifdef CONFIG_ZONE_DMA + acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address()); dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL)); - zone_dma_bits = min(32U, dt_zone_dma_bits); + zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits); arm64_dma_phys_limit = max_zone_phys(zone_dma_bits); max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); #endif --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1730,3 +1730,58 @@ void __init acpi_iort_init(void) iort_init_platform_devices(); } + +#ifdef CONFIG_ZONE_DMA +/* + * Extract the highest CPU physical address accessible to all DMA masters in + * the system. PHYS_ADDR_MAX is returned when no constrained device is found. + */ +phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void) +{ + phys_addr_t limit = PHYS_ADDR_MAX; + struct acpi_iort_node *node, *end; + struct acpi_table_iort *iort; + acpi_status status; + int i; + + if (acpi_disabled) + return limit; + + status = acpi_get_table(ACPI_SIG_IORT, 0, + (struct acpi_table_header **)&iort); + if (ACPI_FAILURE(status)) + return limit; + + node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset); + end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length); + + for (i = 0; i < iort->node_count; i++) { + if (node >= end) + break; + + switch (node->type) { + struct acpi_iort_named_component *ncomp; + struct acpi_iort_root_complex *rc; + phys_addr_t local_limit; + + case ACPI_IORT_NODE_NAMED_COMPONENT: + ncomp = (struct acpi_iort_named_component *)node->node_data; + local_limit = DMA_BIT_MASK(ncomp->memory_address_limit); + limit = min_not_zero(limit, local_limit); + break; + + case ACPI_IORT_NODE_PCI_ROOT_COMPLEX: + if (node->revision < 1) + break; + + rc = (struct acpi_iort_root_complex *)node->node_data; + local_limit = DMA_BIT_MASK(rc->memory_address_limit); + limit = min_not_zero(limit, local_limit); + break; + } + node = ACPI_ADD_PTR(struct acpi_iort_node, node, node->length); + } + acpi_put_table(&iort->header); + return limit; +} +#endif --- a/include/linux/acpi_iort.h +++ b/include/linux/acpi_iort.h @@ -38,6 +38,7 @@ void iort_dma_setup(struct device *dev, const struct iommu_ops *iort_iommu_configure_id(struct device *dev, const u32 *id_in); int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head); +phys_addr_t acpi_iort_dma_get_max_cpu_address(void); #else static inline void acpi_iort_init(void) { } static inline u32 iort_msi_map_id(struct device *dev, u32 id) @@ -55,6 +56,9 @@ static inline const struct iommu_ops *io static inline int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head) { return 0; } + +static inline phys_addr_t acpi_iort_dma_get_max_cpu_address(void) +{ return PHYS_ADDR_MAX; } #endif #endif /* __ACPI_IORT_H__ */ From patchwork Mon Mar 8 12:30:58 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395904 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDA87C43381 for ; Mon, 8 Mar 2021 12:35:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A65C651FF for ; Mon, 8 Mar 2021 12:35:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229497AbhCHMer (ORCPT ); Mon, 8 Mar 2021 07:34:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:43346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231246AbhCHMeW (ORCPT ); Mon, 8 Mar 2021 07:34:22 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 813B2651C3; Mon, 8 Mar 2021 12:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206862; bh=QxnzNqd3JmxvYCMrytiF2UlvP860pukbOaMnEkprWHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bRhBu9TEWMUw6vAEY1m62QRHTdcR8JACt5lnxsYZGJ1h0nFHy3aEiXxKPRs/6nvcm OZAn8FDVG39SNi12LBYJw5kbhhEO/7f4BXwR9S3TXZlwcyRgYr0KNJz45LomYkF+mH a4rMosJ3lhzlnCQZaOdS9Uk/SVWRd38B3Xksf7/s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Saeed Mahameed , Jason Gunthorpe , Leon Romanovsky , Sasha Levin Subject: [PATCH 5.10 32/42] RDMA/cm: Fix IRQ restore in ib_send_cm_sidr_rep Date: Mon, 8 Mar 2021 13:30:58 +0100 Message-Id: <20210308122719.699019203@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Saeed Mahameed [ Upstream commit 221384df6123747d2a75517dd06cc01752f81518 ] ib_send_cm_sidr_rep() { spin_lock_irqsave() cm_send_sidr_rep_locked() { ... spin_lock_irq() .... spin_unlock_irq() <--- this will enable interrupts } spin_unlock_irqrestore() } spin_unlock_irqrestore() expects interrupts to be disabled but the internal spin_unlock_irq() will always enable hard interrupts. Fix this by replacing the internal spin_{lock,unlock}_irq() with irqsave/restore variants. It fixes the following kernel trace: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 2 PID: 20001 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 Call Trace: _raw_spin_unlock_irqrestore+0x4e/0x50 ib_send_cm_sidr_rep+0x3a/0x50 [ib_cm] cma_send_sidr_rep+0xa1/0x160 [rdma_cm] rdma_accept+0x25e/0x350 [rdma_cm] ucma_accept+0x132/0x1cc [rdma_ucm] ucma_write+0xbf/0x140 [rdma_ucm] vfs_write+0xc1/0x340 ksys_write+0xb3/0xe0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 87c4c774cbef ("RDMA/cm: Protect access to remote_sidr_table") Link: https://lore.kernel.org/r/20210301081844.445823-1-leon@kernel.org Signed-off-by: Saeed Mahameed Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin --- drivers/infiniband/core/cm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index 8e578f73a074..bbba0cd42c89 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -3650,6 +3650,7 @@ static int cm_send_sidr_rep_locked(struct cm_id_private *cm_id_priv, struct ib_cm_sidr_rep_param *param) { struct ib_mad_send_buf *msg; + unsigned long flags; int ret; lockdep_assert_held(&cm_id_priv->lock); @@ -3675,12 +3676,12 @@ static int cm_send_sidr_rep_locked(struct cm_id_private *cm_id_priv, return ret; } cm_id_priv->id.state = IB_CM_IDLE; - spin_lock_irq(&cm.lock); + spin_lock_irqsave(&cm.lock, flags); if (!RB_EMPTY_NODE(&cm_id_priv->sidr_id_node)) { rb_erase(&cm_id_priv->sidr_id_node, &cm.remote_sidr_table); RB_CLEAR_NODE(&cm_id_priv->sidr_id_node); } - spin_unlock_irq(&cm.lock); + spin_unlock_irqrestore(&cm.lock, flags); return 0; } From patchwork Mon Mar 8 12:31:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395900 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8CFBC43332 for ; Mon, 8 Mar 2021 12:35:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7A0365205 for ; Mon, 8 Mar 2021 12:35:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231321AbhCHMeu (ORCPT ); Mon, 8 Mar 2021 07:34:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:43426 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231626AbhCHMeb (ORCPT ); Mon, 8 Mar 2021 07:34:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6B6AA651DC; Mon, 8 Mar 2021 12:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206871; bh=tnoAFpH92WX0AZZAGK6Dc455NpjQPsEbYeWmdW/Y9TE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BHvpMgsftfBjhERwo+5PTBHoHBThCJTB4pCCmdqfmvjjSjh6tj71+174x4fJyQpcU +5wCbWlhPCt2WRrmf3FsJ6UjCgfnz08gJdwf+M9jnRhOUVg/xErG1n6p4iNpM8C5Dh 6iW/Ge3GaES2cR/xm7lo8sRRYQ8Oyrk+gN3Ab05k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, YueHaibing , Leon Romanovsky , Jason Gunthorpe , Sasha Levin Subject: [PATCH 5.10 34/42] IB/mlx5: Add missing error code Date: Mon, 8 Mar 2021 13:31:00 +0100 Message-Id: <20210308122719.793712314@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: YueHaibing [ Upstream commit 3a9b3d4536e0c25bd3906a28c1f584177e49dd0f ] Set err to -ENOMEM if kzalloc fails instead of 0. Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX") Link: https://lore.kernel.org/r/20210222122343.19720-1-yuehaibing@huawei.com Signed-off-by: YueHaibing Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin --- drivers/infiniband/hw/mlx5/devx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c index 26564e7d3457..efb9ec99b68b 100644 --- a/drivers/infiniband/hw/mlx5/devx.c +++ b/drivers/infiniband/hw/mlx5/devx.c @@ -1973,8 +1973,10 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT)( num_alloc_xa_entries++; event_sub = kzalloc(sizeof(*event_sub), GFP_KERNEL); - if (!event_sub) + if (!event_sub) { + err = -ENOMEM; goto err; + } list_add_tail(&event_sub->event_list, &sub_list); uverbs_uobject_get(&ev_file->uobj); From patchwork Mon Mar 8 12:31:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395901 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CB79C4321A for ; Mon, 8 Mar 2021 12:35:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B289651FC for ; Mon, 8 Mar 2021 12:35:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231424AbhCHMev (ORCPT ); Mon, 8 Mar 2021 07:34:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:43474 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231314AbhCHMeg (ORCPT ); Mon, 8 Mar 2021 07:34:36 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C22F8651CF; Mon, 8 Mar 2021 12:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206876; bh=glepnS2PyHI4cIirF6sXbPDf6waIMx8obG42NtzmUmo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1WfwevuresGkZ6FllRbAlRgCF/8xZOAFiqDfzxaxugTHYWdvDRqs3DUVCx8c1W7TG 3Md8YjK/KzSr+doRO0cmPTONZ4JMn/N+j9TS/a1mvoARnoBNnjDFtVRYG0iXAgQI2f j0+2Jxe0oC5sDyr/Ycpek60pqLPbr8qE5/y8ej/M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Will Deacon , Chen Jun , "Steven Rostedt (VMware)" , Sasha Levin Subject: [PATCH 5.10 36/42] ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount Date: Mon, 8 Mar 2021 13:31:02 +0100 Message-Id: <20210308122719.881477587@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Chen Jun [ Upstream commit 999340d51174ce4141dd723105d4cef872b13ee9 ] On little endian system, Use aarch64_be(gcc v7.3) downloaded from linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y, CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y. gcc will create symbols of _mcount but recordmcount can not create mcount_loc for *.o. aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount 00000000000000d0 R_AARCH64_CALL26 _mcount ... 0000000000007190 R_AARCH64_CALL26 _mcount The reason is than funciton arm64_is_fake_mcount can not work correctly. A symbol of _mcount in *.o compiled with big endian compiler likes: 00 00 00 2d 00 00 01 1b w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes uint32_t as parameter, which truncates rp->r_info. Use w8() instead w() to read relp->r_info Link: https://lkml.kernel.org/r/20210222135840.56250-1-chenjun102@huawei.com Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.") Acked-by: Will Deacon Signed-off-by: Chen Jun Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin --- scripts/recordmcount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c index b9c2ee7ab43f..cce12e1971d8 100644 --- a/scripts/recordmcount.c +++ b/scripts/recordmcount.c @@ -438,7 +438,7 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp) static int arm64_is_fake_mcount(Elf64_Rel const *rp) { - return ELF64_R_TYPE(w(rp->r_info)) != R_AARCH64_CALL26; + return ELF64_R_TYPE(w8(rp->r_info)) != R_AARCH64_CALL26; } /* 64-bit EM_MIPS has weird ELF64_Rela.r_info. From patchwork Mon Mar 8 12:31:03 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395902 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43961C433E0 for ; Mon, 8 Mar 2021 12:35:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF567651DC for ; Mon, 8 Mar 2021 12:35:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231589AbhCHMev (ORCPT ); Mon, 8 Mar 2021 07:34:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:43498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhCHMej (ORCPT ); Mon, 8 Mar 2021 07:34:39 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 76D76651C3; Mon, 8 Mar 2021 12:34:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206879; bh=0XrOwaHgvfjbL088LeHoqB7jc9U+zNxCKkws2sLNpzM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EgOkVd8V6bS1uMI/u2Usjw276LF6tMzHBhGHHnYh/LHvZWhtir9rc+aCC2D5Qf7+L p1Pxt/RewNxPwafxezTGFhWbEaiq21brIyqLcAI01SE+rwSiAiDsNZb2R0o4NwBBR4 /466M25HVHHuM22LYk7FFQqniFPCSyaaqZpUi/xQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Jens Axboe , Sasha Levin Subject: [PATCH 5.10 37/42] rsxx: Return -EFAULT if copy_to_user() fails Date: Mon, 8 Mar 2021 13:31:03 +0100 Message-Id: <20210308122719.928917471@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dan Carpenter [ Upstream commit 77516d25f54912a7baedeeac1b1b828b6f285152 ] The copy_to_user() function returns the number of bytes remaining but we want to return -EFAULT to the user if it can't complete the copy. The "st" variable only holds zero on success or negative error codes on failure so the type should be int. Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.") Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- drivers/block/rsxx/core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c index 63f549889f87..5ac1881396af 100644 --- a/drivers/block/rsxx/core.c +++ b/drivers/block/rsxx/core.c @@ -165,15 +165,17 @@ static ssize_t rsxx_cram_read(struct file *fp, char __user *ubuf, { struct rsxx_cardinfo *card = file_inode(fp)->i_private; char *buf; - ssize_t st; + int st; buf = kzalloc(cnt, GFP_KERNEL); if (!buf) return -ENOMEM; st = rsxx_creg_read(card, CREG_ADD_CRAM + (u32)*ppos, cnt, buf, 1); - if (!st) - st = copy_to_user(ubuf, buf, cnt); + if (!st) { + if (copy_to_user(ubuf, buf, cnt)) + st = -EFAULT; + } kfree(buf); if (st) return st; From patchwork Mon Mar 8 12:31:05 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395899 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3A26C433E0 for ; Mon, 8 Mar 2021 12:35:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 593856520A for ; Mon, 8 Mar 2021 12:35:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230095AbhCHMfQ (ORCPT ); Mon, 8 Mar 2021 07:35:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:43566 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229474AbhCHMep (ORCPT ); Mon, 8 Mar 2021 07:34:45 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0DFB664EBC; Mon, 8 Mar 2021 12:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206884; bh=hpFS5Mt+/sKWEA++sZSRWAjmJI0iaLKwzasAjqc8TPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v7CMXxy8xRrluJqSIDcgG+LdL5wmEy8dlIFmcVH5V8cL+JwWyvRrpjTLZEK5m44Pc U4b9ubvZ+rvUHYptDOXJWt/QwcpwRWfu/RXFb+FKFwfC79LYKFHNSevIHs8DewaSzR vkGZ8DoUPxMnMF1HDJIX9o5lR0CMB8H0IG6xxG+A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Corentin Labbe , =?utf-8?b?SsOpcsO0bWUgQnJ1bmV0?= , Neil Armstrong , Kevin Hilman Subject: [PATCH 5.10 39/42] Revert "arm64: dts: amlogic: add missing ethernet reset ID" Date: Mon, 8 Mar 2021 13:31:05 +0100 Message-Id: <20210308122720.021070104@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Neil Armstrong commit 19f6fe976a61f9afc289b062b7ef67f99b72e7b9 upstream. It has been reported on IRC and in KernelCI boot tests, this change breaks internal PHY support on the Amlogic G12A/SM1 Based boards. We suspect the added signal to reset more than the Ethernet MAC but also the MDIO/(RG)MII mux used to redirect the MAC signals to the internal PHY. This reverts commit f3362f0c18174a1f334a419ab7d567a36bd1b3f3 while we find and acceptable solution to cleanly reset the Ethernet MAC. Reported-by: Corentin Labbe Acked-by: Jérôme Brunet Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20210126080951.2383740-1-narmstrong@baylibre.com Signed-off-by: Greg Kroah-Hartman --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 -- arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 -- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 3 --- 3 files changed, 7 deletions(-) --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi @@ -227,8 +227,6 @@ "timing-adjustment"; rx-fifo-depth = <4096>; tx-fifo-depth = <2048>; - resets = <&reset RESET_ETHERNET>; - reset-names = "stmmaceth"; status = "disabled"; }; --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi @@ -224,8 +224,6 @@ "timing-adjustment"; rx-fifo-depth = <4096>; tx-fifo-depth = <2048>; - resets = <&reset RESET_ETHERNET>; - reset-names = "stmmaceth"; status = "disabled"; mdio0: mdio { --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi @@ -13,7 +13,6 @@ #include #include #include -#include #include / { @@ -576,8 +575,6 @@ interrupt-names = "macirq"; rx-fifo-depth = <4096>; tx-fifo-depth = <2048>; - resets = <&reset RESET_ETHERNET>; - reset-names = "stmmaceth"; power-domains = <&pwrc PWRC_GXBB_ETHERNET_MEM_ID>; status = "disabled"; }; From patchwork Mon Mar 8 12:31:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395406 Delivered-To: patch@linaro.org Received: by 2002:a02:8562:0:0:0:0:0 with SMTP id g89csp1672659jai; Mon, 8 Mar 2021 04:35:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJzuzoMee2EJppt/Pc90EfU8JAWG7Wi4sMUSsd908Upl29Lzz0Y30L8Slm6LyaVXdgKSNFg5 X-Received: by 2002:a17:906:c09:: with SMTP id s9mr14765012ejf.539.1615206951578; Mon, 08 Mar 2021 04:35:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615206951; cv=none; d=google.com; s=arc-20160816; b=wEtg1xr4Vc7tseeoxPJ3ai7QCcdX93Q687V5lvNEypCVjhdQWIarlSf00jVg7Fr2VJ J7vrdmr7hLhE73OARzyQOyF8uQNVInlTMeaw403R44erOkxi2voi0zN7ZS+Q3C8iiEEe yWEQoCAN46BrhvAaPQbTuqUgoJpAvndIivHkwp7R3stC3Fkx3cD56FnTMDfIhB+gYB12 Q2tAt5tPRx065NJnQb/djcSa677kjtWYo5ek7NLIW3Db5d1W7ZW9WOPmNbp6COBgYYKS A/AJz6RODd+BnVA0JSN3N+NR0UVLJegj+LN5r3SVzfbT66UQB7nD6EvMQS41OQSd5lRE jfjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=bVuV99UDH0Uc6Fajpn3FL5ACcGlrbDmP9zEkdQLatMM=; b=uBffgH6Nwr7gCTupLO48F7F+R6hqKyySrpJf6fvgDdCZqft+hAi1azee1ZT2nbfLtE d+pOgER46vEsoN9KmvHr+Rek3ndIjg9QhfoX2acR+8eQHnRQTF4H/DRd555nl05wxMk7 WvngrSCVb250bvQOwI1N63ZYpjkmUjGYMAkwDlx9esAKZp8z4BNlD0hCb572q3yGzKZT j/I5Yy2J/BcMeuq3dJXi6bhzZ7AEl3Qa7N6Axj1UT4LNafEpOpgqdnraXW5AHArQ1v9P NNy9TltpJDk2mrluY0itRk+maIvgREPYUofAcLG9c0S6/774WXEfP6q3YHGKJMCLJi1I XpmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oYCZkk0I; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si5490958edc.448.2021.03.08.04.35.51; Mon, 08 Mar 2021 04:35:51 -0800 (PST) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oYCZkk0I; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229637AbhCHMfR (ORCPT + 13 others); Mon, 8 Mar 2021 07:35:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:43756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229950AbhCHMes (ORCPT ); Mon, 8 Mar 2021 07:34:48 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D9D5D651C9; Mon, 8 Mar 2021 12:34:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206887; bh=ym8wd/Ubr9g/GbZG3aJ84RYjH82G13HigPDID7JJF6c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oYCZkk0Iefqrm74tNw0WNV+NkgMGWHjWsJXnKMR1pPCIgcBlbmLxKsNVpg2Cb036G Bc1pOn+rWE70wk9TBJ7fNdajyA+zrh6Vf5WhEYvol3x25KMF8fUVzcmZSmNndrq8vg kuIFWMaI3StGiKKd/W9X7Qmjp/T/UUKtC0gXmMPs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , Catalin Marinas , Jing Xiangfeng Subject: [PATCH 5.10 40/42] of: unittest: Fix build on architectures without CONFIG_OF_ADDRESS Date: Mon, 8 Mar 2021 13:31:06 +0100 Message-Id: <20210308122720.062508474@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Catalin Marinas commit aed5041ef9a3f594ed9dc0bb5ee7e1bbccfd3366 upstream. of_dma_get_max_cpu_address() is not defined if !CONFIG_OF_ADDRESS, so return early in of_unittest_dma_get_max_cpu_address(). Fixes: 07d13a1d6120 ("of: unittest: Add test for of_dma_get_max_cpu_address()") Reported-by: kernel test robot Signed-off-by: Catalin Marinas Cc: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman --- drivers/of/unittest.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/of/unittest.c +++ b/drivers/of/unittest.c @@ -874,6 +874,9 @@ static void __init of_unittest_dma_get_m struct device_node *np; phys_addr_t cpu_addr; + if (!IS_ENABLED(CONFIG_OF_ADDRESS)) + return; + np = of_find_node_by_path("/testcase-data/address-tests"); if (!np) { pr_err("missing testcase data\n"); From patchwork Mon Mar 8 12:31:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 395897 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F4FFC43331 for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 20E99651CF for ; Mon, 8 Mar 2021 12:35:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229474AbhCHMfS (ORCPT ); Mon, 8 Mar 2021 07:35:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:44076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231601AbhCHMex (ORCPT ); Mon, 8 Mar 2021 07:34:53 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 883DA651C9; Mon, 8 Mar 2021 12:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206893; bh=OkDafQvKTcFdS2IodSiW4vL2ELzOLKubu5fv56H+DuQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jFlblVGCJfO8rgF4UvSaREL8o5dA5Loi682GNTf9qLeU4yIrsfNyjSAoIIrjzdlE7 AuPpj0IPw1q2KMRSn1d8Td6fJzesiawReC3OGcVS22lEvP5VP3Bm8gXLZjEhLu36L2 0l20FYVviVu2+mQMTz9bGwiCpl8+gwgwbNvivKdE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Armin Wolf , Heiner Kallweit , "David S. Miller" Subject: [PATCH 5.10 42/42] r8169: fix resuming from suspend on RTL8105e if machine runs on battery Date: Mon, 8 Mar 2021 13:31:08 +0100 Message-Id: <20210308122720.144343202@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Heiner Kallweit commit d2a04370817fc7b0172dad2ef2decf907e1a304e upstream. Armin reported that after referenced commit his RTL8105e is dead when resuming from suspend and machine runs on battery. This patch has been confirmed to fix the issue. Fixes: e80bd76fbf56 ("r8169: work around power-saving bug on some chip versions") Reported-by: Armin Wolf Tested-by: Armin Wolf Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/realtek/r8169_main.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -2244,6 +2244,7 @@ static void rtl_pll_power_down(struct rt switch (tp->mac_version) { case RTL_GIGA_MAC_VER_25 ... RTL_GIGA_MAC_VER_26: + case RTL_GIGA_MAC_VER_29 ... RTL_GIGA_MAC_VER_30: case RTL_GIGA_MAC_VER_32 ... RTL_GIGA_MAC_VER_33: case RTL_GIGA_MAC_VER_37: case RTL_GIGA_MAC_VER_39: @@ -2271,6 +2272,7 @@ static void rtl_pll_power_up(struct rtl8 { switch (tp->mac_version) { case RTL_GIGA_MAC_VER_25 ... RTL_GIGA_MAC_VER_26: + case RTL_GIGA_MAC_VER_29 ... RTL_GIGA_MAC_VER_30: case RTL_GIGA_MAC_VER_32 ... RTL_GIGA_MAC_VER_33: case RTL_GIGA_MAC_VER_37: case RTL_GIGA_MAC_VER_39: