From patchwork Mon Sep 20 16:40: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: 514345 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2280936jao; Mon, 20 Sep 2021 10:38:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9xs2Cmpo5Bwoa0Ao84cibj5YcFpVLSMV3FlW0Z4NrSo5T1HENIV+yy5I4+lLvvncQxU5f X-Received: by 2002:a05:6e02:1a67:: with SMTP id w7mr18033034ilv.24.1632159519549; Mon, 20 Sep 2021 10:38:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632159519; cv=none; d=google.com; s=arc-20160816; b=g1ItiLuGhw9vAg3idJUFGXbHHwzk4o/9Qg1DwRDT0ybiEQKZVf9jtFlv0kYr3fk2Jw Sj+rIzlzCQGvdNpCccBMm3qkwwy7q85q66Q7+QjcJHLCdyM44gJD976K201QnRdDPluK lC+ADAyPDg8eQ6MxR13HBn0EuhHbyVhbdjpeXuIy+5ggu7r+p/uJdJJJ4oPckbE9nT4u HVHB17PI2MC3Fg2xH6hDmRFwPsK0ixy+cR3ns6rSDQ4AS5qd2MZ+mKU2WInDEYf/Q4Ru gvSQAXZ41EbqPW1z2YZvjbqESwq03qAxMnqEWWkr3qIb5LBKc5C2NtWQCj8y11oxLkqy tl7Q== 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=iBZUTkfVehrhruvZD9/hTYPGEmrGFpE69+Bsg8ZOTaY=; b=InVIQW6sh4vpZXS9HAx477SKwM4h/dIEl1GWRSTxjVzqNC9VEUa4jr2QUCiAhLo8YF 0HM2yoy3/bFT7U0FBpOw3MRuAC55pVUl017dAjcppy3wZIf1eGk0How3DWEAaDVmNV8E 1ttSioZhI2fsMSIkZ9DjueItxv/9sKgR8z2c4iLSzchfIXb7DRM6w1unXsM6EccrBIBM yCR9zZRyXG4NcbtEMlUj+wraUpc8KetUHiQTjeQOdjmpfqpXuyMTHv5uUy+zhaEZytRk 7gnB8HJS3aB4eZHkvk2XpdvSuGdlE3lOz3EriKG7sagjs2OWXPo6l1CDsVNgAtb0WLDy Pasw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YZf6Rzea; 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 i185si13671545iof.61.2021.09.20.10.38.38; Mon, 20 Sep 2021 10:38:39 -0700 (PDT) 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=YZf6Rzea; 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 S1348030AbhITRkA (ORCPT + 11 others); Mon, 20 Sep 2021 13:40:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:42622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352094AbhITRhs (ORCPT ); Mon, 20 Sep 2021 13:37:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1457161B31; Mon, 20 Sep 2021 17:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632157624; bh=4HeXLVWGu15t8OzVzGD9ee3B3H4cMlCbN/2q9IrAUqs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YZf6RzeaPBNI3KGwlPuP3TicoXb8bUCOnyR5meuocOnyqbtS3WDDBJEWWGX24BNOk gWb9k6pQ2x1N+AiOG5NF8IEHkdU/9mgCI6fIDmZP2thgRvEa8T4bGAcKS9yyk7Owub k8O/ExV9/zR2X0b6VZGR0bZBjYM220MGw80h0O0M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Baryshkov , Rob Clark , Sasha Levin Subject: [PATCH 4.19 077/293] drm/msm/dpu: make dpu_hw_ctl_clear_all_blendstages clear necessary LMs Date: Mon, 20 Sep 2021 18:40:39 +0200 Message-Id: <20210920163935.900630287@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dmitry Baryshkov [ Upstream commit a41cdb693595ae1904dd793fc15d6954f4295e27 ] dpu_hw_ctl_clear_all_blendstages() clears settings for the few first LMs instead of mixers actually used for the CTL. Change it to clear necessary data, using provided mixer ids. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210704230519.4081467-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.30.2 diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c index 79bafea66354..a40ea5c68572 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c @@ -296,10 +296,12 @@ static void dpu_hw_ctl_clear_all_blendstages(struct dpu_hw_ctl *ctx) int i; for (i = 0; i < ctx->mixer_count; i++) { - DPU_REG_WRITE(c, CTL_LAYER(LM_0 + i), 0); - DPU_REG_WRITE(c, CTL_LAYER_EXT(LM_0 + i), 0); - DPU_REG_WRITE(c, CTL_LAYER_EXT2(LM_0 + i), 0); - DPU_REG_WRITE(c, CTL_LAYER_EXT3(LM_0 + i), 0); + enum dpu_lm mixer_id = ctx->mixer_hw_caps[i].id; + + DPU_REG_WRITE(c, CTL_LAYER(mixer_id), 0); + DPU_REG_WRITE(c, CTL_LAYER_EXT(mixer_id), 0); + DPU_REG_WRITE(c, CTL_LAYER_EXT2(mixer_id), 0); + DPU_REG_WRITE(c, CTL_LAYER_EXT3(mixer_id), 0); } } From patchwork Mon Sep 20 16:41:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 514346 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2283474jao; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylWQGOzBOzDhlR04p5eYKCwkNEaVYJQ/0REXFmHaitfmyRDtffaIuc9lb3I7LN6BJLodef X-Received: by 2002:a6b:f604:: with SMTP id n4mr11002890ioh.99.1632159716138; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632159716; cv=none; d=google.com; s=arc-20160816; b=0SbZcs6v4jVGfFKcOCoIuQnpvZ27cysZXzdF8cMj5TTEigskqEVrVnaVp5Cdh3oF8i /tpdHAIy/Ou2ciMEpln4ZU0JmPN6r0UctIYQsqUUbVf4afl9HdbjWUk0sK7piDpB9Ofv xA9CxKj4YmkVywpe8/MvOVPNjzhLCJYiOij/T9mXNBBSsXigIvCEgFEpT4rs3KEbBWdA v1idhH0iR39DJxufVvCQsh7QFtI3hjLnqpahpbDIwfg/eoXdmjTWVgbj3kFgspNiPsUp dw6lfkttnUi01GifMXC9UYIaNmGq8AYPC18Z/cdSxv36HbYDYmZj2G7A0r+zuvf7kRgd cupw== 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=ZP5DxhEHnCwahdObDwEC9IrloEq8tk0J72RJRrNl3IA=; b=ltzxZyD5Cksla8IwTuqx4grDsQHc2hmHIf3/HKYjeKcVAD3lkg8YwIdqAP1eAjhj7A 0uIw6XrLP6HfPYA/oK/X4RpA67e7XvzFQ8GJLjJoCfdMO+3PyxsunK4NyIDwshPesSu9 DzVrZJi0Xg6inIMtNAeOlG5XqZBX9wt4od1fGLDrnpQTnQ/GZ91+Yamp6cFfrEvH1j4+ eIm8rWwHKVHYtlNFX0sLHuJX3++KCAqZmWPVknkEvqUSpp82f1jIQ60Z/yDt6pLWaOFH HPDoyZqiQbcOn2e+X7gEt2xwWuVZbe/TXvkbYBhRUEKGNpw5q9NduKcZE/ONwGhx68RV MF5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=whEkZ9pJ; 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 i2si14844182ilv.102.2021.09.20.10.41.55; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) 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=whEkZ9pJ; 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 S1353024AbhITRnU (ORCPT + 11 others); Mon, 20 Sep 2021 13:43:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:48100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348600AbhITRlQ (ORCPT ); Mon, 20 Sep 2021 13:41:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D5A3F617E6; Mon, 20 Sep 2021 17:08:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632157709; bh=+UH3HGxHCFzLXDr38uEq/UrnQqdTMy+u4tvGFugt1EQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=whEkZ9pJiGtp4pBbOTJDTCNKw1Xuyjb8vVtRCVyPWoQFbSYdlzurfsL7Rpqwi+rZf ueZDW5BRIYKfmC8r5Cua5hT39yqKp2h+/nO8owBvE3XqrARbBaBMugIfiYh2om01pk 7I4dRP4KPHfmau/egdcwsZ96tGadK/Uhmgu4zEfU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Vasut , Daniel Thompson , Lee Jones Subject: [PATCH 4.19 116/293] backlight: pwm_bl: Improve bootloader/kernel device handover Date: Mon, 20 Sep 2021 18:41:18 +0200 Message-Id: <20210920163937.232034394@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Daniel Thompson commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream. Currently there are (at least) two problems in the way pwm_bl starts managing the enable_gpio pin. Both occur when the backlight is initially off and the driver finds the pin not already in output mode and, as a result, unconditionally switches it to output-mode and asserts the signal. Problem 1: This could cause the backlight to flicker since, at this stage in driver initialisation, we have no idea what the PWM and regulator are doing (an unconfigured PWM could easily "rest" at 100% duty cycle). Problem 2: This will cause us not to correctly honour the post_pwm_on_delay (which also risks flickers). Fix this by moving the code to configure the GPIO output mode until after we have examines the handover state. That allows us to initialize enable_gpio to off if the backlight is currently off and on if the backlight is on. Cc: stable@vger.kernel.org Reported-by: Marek Vasut Signed-off-by: Daniel Thompson Acked-by: Marek Vasut Tested-by: Marek Vasut Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- drivers/video/backlight/pwm_bl.c | 54 ++++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 26 deletions(-) --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -400,6 +400,33 @@ int pwm_backlight_brightness_default(str static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) { struct device_node *node = pb->dev->of_node; + bool active = true; + + /* + * If the enable GPIO is present, observable (either as input + * or output) and off then the backlight is not currently active. + * */ + if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) + active = false; + + if (!regulator_is_enabled(pb->power_supply)) + active = false; + + if (!pwm_is_enabled(pb->pwm)) + active = false; + + /* + * Synchronize the enable_gpio with the observed state of the + * hardware. + */ + if (pb->enable_gpio) + gpiod_direction_output(pb->enable_gpio, active); + + /* + * Do not change pb->enabled here! pb->enabled essentially + * tells us if we own one of the regulator's use counts and + * right now we do not. + */ /* Not booted with device tree or no phandle link to the node */ if (!node || !node->phandle) @@ -411,20 +438,7 @@ static int pwm_backlight_initial_power_s * assume that another driver will enable the backlight at the * appropriate time. Therefore, if it is disabled, keep it so. */ - - /* if the enable GPIO is disabled, do not enable the backlight */ - if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) - return FB_BLANK_POWERDOWN; - - /* The regulator is disabled, do not enable the backlight */ - if (!regulator_is_enabled(pb->power_supply)) - return FB_BLANK_POWERDOWN; - - /* The PWM is disabled, keep it like this */ - if (!pwm_is_enabled(pb->pwm)) - return FB_BLANK_POWERDOWN; - - return FB_BLANK_UNBLANK; + return active ? FB_BLANK_UNBLANK: FB_BLANK_POWERDOWN; } static int pwm_backlight_probe(struct platform_device *pdev) @@ -494,18 +508,6 @@ static int pwm_backlight_probe(struct pl pb->enable_gpio = gpio_to_desc(data->enable_gpio); } - /* - * If the GPIO is not known to be already configured as output, that - * is, if gpiod_get_direction returns either 1 or -EINVAL, change the - * direction to output and set the GPIO as active. - * Do not force the GPIO to active when it was already output as it - * could cause backlight flickering or we would enable the backlight too - * early. Leave the decision of the initial backlight state for later. - */ - if (pb->enable_gpio && - gpiod_get_direction(pb->enable_gpio) != 0) - gpiod_direction_output(pb->enable_gpio, 1); - pb->power_supply = devm_regulator_get(&pdev->dev, "power"); if (IS_ERR(pb->power_supply)) { ret = PTR_ERR(pb->power_supply); From patchwork Mon Sep 20 16:41:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 514347 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2283483jao; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYFH9BcmCErVwWSm1Gu6sGz4L3is8IBk1SRhQvuq6ndEEALcsLBSCg0JClWB9wS2BIrqek X-Received: by 2002:a05:6638:140f:: with SMTP id k15mr20598898jad.113.1632159716664; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632159716; cv=none; d=google.com; s=arc-20160816; b=A//FAsbbiMgYUyjb9tlus9DDxdyqbErVjcDDkdJmrK9viVM8z+HynI8Yk+HYEXmVVC 4DOMVz91sXrN2InUFVjlbEFhPkrawbfAH42Ks559+w916tPsOx3bgiPI2/VTiTcw+thI gilKxZdK5WvtiZpI2NWTXT2sqAOVyhAmfn2krXCq8ERhSg3rRIKGRWgpVvGek3MdJCAg RmmhfO14kOjmGrV5eFqQE6UGf2s7KAjIcaJpuAWvt7qzOJXr86Pv6WUFljtzvxEG3ka0 TgmXslAsgiHy6K4gGIQxV6ErR9jfti9IsrkSbunZ78uWaEsxBlyhGZbH4eq8zAvUCTWO UOtw== 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=4Cx/80a6QwNfQ3OTcfHgdKUL4h7zU0pKU0Xgh9Xyy9Q=; b=b9AyRhz3EfErtzrMSH5bRUaSCqM4kjgD/Hdv8kJ+8eth5c8NNM/2DVmnckYi3w+dID mLyp+H9F+s/P8Aq5rL/jvA143jy4qz08Cw+zRjFkDSg8pCLWmmL8nQj6oQ3PHH3kMCq3 WOeFu3Ohw9fTYgn0XkfHARJBu3u75nSye6mAzzAN+SXRnvDuXpot11DD+opcBeooCWxK NgEpnQhTKeJSTb/0x11W4vEJfNJRHkvww0S6gJ0OdWria33BMr7qR3rxSX/2P5RcOJQl 5Qz5OwGP6aAdL80sRt88/Ek2f3KEwDXAvxBbJGTQyzioWNs2Zn6jD8k3ec7S0ptJJS7B hDqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="uW+S/wvy"; 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 i2si14844182ilv.102.2021.09.20.10.41.56; Mon, 20 Sep 2021 10:41:56 -0700 (PDT) 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="uW+S/wvy"; 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 S1349010AbhITRnW (ORCPT + 11 others); Mon, 20 Sep 2021 13:43:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:48148 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352700AbhITRlU (ORCPT ); Mon, 20 Sep 2021 13:41:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0F98261B4B; Mon, 20 Sep 2021 17:08:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632157711; bh=2+69YOaFMQV3IeG+2xp7JYf6jg/oriN58muh/MO/R1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uW+S/wvymrnGJGKxbQaYE/L8ZCRQdXq6LA5lM0fsjPMoWWHD0YSjbLYiqNifyjvIa Jl62ExOHacUdaWTIdj9zzVDRaNGf7o9wQFAFKlVs7/FYMHzcYq/9oW5wpvqmJN7I0A Z9+7H79AxsdMAqMCpFS89mutG4XrlGcFRPjDQlH8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrew Lunn , Chris Packham , Gregory CLEMENT , Sebastian Hesselbarth , Linus Walleij , Stephen Boyd Subject: [PATCH 4.19 117/293] clk: kirkwood: Fix a clocking boot regression Date: Mon, 20 Sep 2021 18:41:19 +0200 Message-Id: <20210920163937.267418935@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Linus Walleij commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. Since a few kernel releases the Pogoplug 4 has crashed like this during boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 (...) [] (strlen) from [] (kstrdup+0x1c/0x4c) [] (kstrdup) from [] (__clk_register+0x44/0x37c) [] (__clk_register) from [] (clk_hw_register+0x20/0x44) [] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4) [] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c) [] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) [] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214) [] (of_clk_init) from [] (time_init+0x20/0x2c) [] (time_init) from [] (start_kernel+0x3dc/0x56c) [] (start_kernel) from [<00000000>] (0x0) Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) This is because the "powersave" mux clock 0 was provided in an unterminated array, which is required by the loop in the driver: /* Count, allocate, and register clock muxes */ for (n = 0; desc[n].name;) n++; Here n will go out of bounds and then call clk_register_mux() on random memory contents after the mux clock. Fix this by terminating the array with a blank entry. Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") Cc: stable@vger.kernel.org Cc: Andrew Lunn Cc: Chris Packham Cc: Gregory CLEMENT Cc: Sebastian Hesselbarth Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org Reviewed-by: Andrew Lunn Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman --- drivers/clk/mvebu/kirkwood.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/clk/mvebu/kirkwood.c +++ b/drivers/clk/mvebu/kirkwood.c @@ -254,6 +254,7 @@ static const char *powersave_parents[] = static const struct clk_muxing_soc_desc kirkwood_mux_desc[] __initconst = { { "powersave", powersave_parents, ARRAY_SIZE(powersave_parents), 11, 1, 0 }, + { } }; static struct clk *clk_muxing_get_src( From patchwork Mon Sep 20 16:42:54 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 514348 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2293541jao; Mon, 20 Sep 2021 10:54:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzm4i6K+OBb/Q3/u+YKREQHbZNcymdnlAL4/s91OPnIcNcQqmkY0UcKwewVv/52ohZF5kLi X-Received: by 2002:a05:6638:ac1:: with SMTP id m1mr4041681jab.74.1632160483381; Mon, 20 Sep 2021 10:54:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632160483; cv=none; d=google.com; s=arc-20160816; b=sQVICFAwWAlEEgSNNeub784udR4RxBxhBVt64z5CNUwgn2zEubYnDcZl8p/xyTeADN pBPhMUnmBnTDTDuW6s4+6IcGcBsNCXUlLJHzv9dHnBOGPUS2uhx31PCs+/ocRU9r2j7j 21ov7pmesdWvc52qhNkL+rxCTxGD+cnlM0seh0Rq32DWXbMOHi66VgsmLr5ZALBhpkpL v2XTWYqIn7HpE2zKx+CDXoSNrYjNj6udobOOkBJ7MS1FPfT5iAJcjNat76RjxUMiRG7d aJSviVFdAviqbi/vxQ7rumFGQxclpDb+fQ9HOWI8oBplY4RCYXrDxcaQMKt+WZDgtc2c pP5Q== 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=gt14tFor7lX6XIsPDtFPsOxHBd9ddIN8zXKNFhbO68k=; b=ookWXDdmwXPnPoBHbO33/fLeaPLq7qfTiicGJNoGMEmSN82rdPvDZ1KMBMlSxJqRtE xwmngNHQBR3QRqlCoTTvhFPBAVlm1i8yifVcRoEwdUZ0dFTjurY9G4wChxvivM9HM9x3 7yqjTlR3Bp0xi3zU5hezh4Dw1IYyrw4RRZ2pTsXx8RXfA9FepJVQEWzeUhd5AyGJEgfY wXVfmIxb8asGPQDdPABjK9j7puIE/TA7ZuuwydJBnoTXpHvuvrwjuacGYa519BPoQlHJ odXMBz5ZkqGDnC5xASD8IxPkvrRlSBfJXnKj+2NuydB5HjxyKqQnEaPWOMRt33w4Qz9f XpWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jzwUHdHM; 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 i21si3180695ioj.27.2021.09.20.10.54.43; Mon, 20 Sep 2021 10:54:43 -0700 (PDT) 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=jzwUHdHM; 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 S1352185AbhITRzy (ORCPT + 11 others); Mon, 20 Sep 2021 13:55:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:54994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349811AbhITRxa (ORCPT ); Mon, 20 Sep 2021 13:53:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C59AF6197A; Mon, 20 Sep 2021 17:13:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632157990; bh=h08e8F4P8w/l1YEy/TuFnEdjIweC5EMttMZkLs3tubM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jzwUHdHMQsFY0Yuo5pYMFN0isgFHOw0Dh34Vms1yFfOEGHLYbV7HfvOJDCRQYddhF h6gJyRJ6FYMecnFmPPhACa0z5Zf5DPNGvupVohPiByTeqpuJijD1+C1OfHgcf0Hx4x 7pddpldk6bnCkgAlcRBcXHztdR2fe2dhGhzAn35s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vinod Koul , Bjorn Andersson , Sasha Levin Subject: [PATCH 4.19 212/293] arm64: dts: qcom: sdm660: use reg value for memory node Date: Mon, 20 Sep 2021 18:42:54 +0200 Message-Id: <20210920163940.526016230@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Vinod Koul [ Upstream commit c81210e38966cfa1c784364e4035081c3227cf5b ] memory node like other node should be node@reg, which is missing in this case, so fix it up arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 1073741824, 0, 536870912]]} Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-18-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin --- arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.30.2 diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts index c13ddee8262b..58acf21d8d33 100644 --- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts +++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts @@ -28,7 +28,7 @@ chosen { stdout-path = "serial0"; }; - memory { + memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x0 0x20000000>; }; From patchwork Mon Sep 20 16:43:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 514349 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2293600jao; Mon, 20 Sep 2021 10:54:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJwuEYTT3qvWfGcrnSU78wgstsC0hbYhIiOa8kjfM27QBj3vedmq1MTYM+E7bfI3kYIzIm X-Received: by 2002:a5d:9958:: with SMTP id v24mr20212421ios.201.1632160486275; Mon, 20 Sep 2021 10:54:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632160486; cv=none; d=google.com; s=arc-20160816; b=bZF9c7NHfdRXS4QzovBoa7zSQnue0yDCe5F10v2SWHu+afGIpzvPgKzogM2mNs72cx T7vtSa3kxgnGnqUeYjYl0naJ/5Ta9/MIOPXL43VPykKqH8SriuSzMk/APPqG+Lw2vxfN JFNxnduXaU+E9i2/W0wEydwtxBm6pAZoezlnQoWZi9hjXjLazcXGcir4c3N/MVgVCcMh jAZThbTpwoxggIDO9tmJ5J2FS9msZt7I/Up8vvxbn/glDj08kgzMdhJnajlkd/gWTIYS f63fw7AZLZlQf5RkFDeL5DIjYOtgnnbtgrkPMNqovBIaa5ybLUcqpJHLywWOkAM2OPly Isyw== 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=hfFxfOg5zwWl+gfvWSmMt5W+ZuAKoKhHyTxFu1OpByA=; b=b6RrmXE/glAcrU9CsUzEnedcpmuNrWMjNQ86gCY9qDUdkp+7ltq74VfpFaYxXxIemR lHMI8oCwwd8bauoUGa1P2UWvTwDpasKu8bYgY1o9cyTW8xbYlO9ZKQjriH7bUgRqU7/W AeKsYrfYosp5u59hfT2VaykpDiIzBZusbLpRMi019GODYf9WRXjhsAX639DGQa8BxXtc 13jpTGRaEgeDSqLtujdhVmKSNaldaDxYYlcrfJxRRaGU/wOyHrkcf/hgFcl15FUx1G0u vrRYQxxt5XVHD6hvnYrCiHl+zq6Q6iNvJfyHnyIkgNWqDcC9IQpF9abp3p+dj5inCwNF FLuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LK7p6P1O; 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 i21si3180695ioj.27.2021.09.20.10.54.46; Mon, 20 Sep 2021 10:54:46 -0700 (PDT) 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=LK7p6P1O; 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 S1343957AbhITRz6 (ORCPT + 11 others); Mon, 20 Sep 2021 13:55:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:54556 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355190AbhITRyS (ORCPT ); Mon, 20 Sep 2021 13:54:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7D46A61BFE; Mon, 20 Sep 2021 17:13:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632158007; bh=dE7Vn0lCqonUuO3g+fvfTT795OVoIb9npFsBKYR+cKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LK7p6P1Od8gYwADdlspmLgiSOFLOcgoXc+5uSjh6VW2pkmTyZUuyjcWkb3Xk/oqmU KZSZhEK/mGu9iLSRejUzZT8oZxnOphF3jbw884EpAMy2X5FOy8IB9eHYkgqF+6GOfF vlJroQTdgx2ycFDbTk7dgHcFiCkOHngOs5hBA4zs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Brown , Catalin Marinas Subject: [PATCH 4.19 253/293] arm64/sve: Use correct size when reinitialising SVE state Date: Mon, 20 Sep 2021 18:43:35 +0200 Message-Id: <20210920163942.047521269@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Brown commit e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 upstream. When we need a buffer for SVE register state we call sve_alloc() to make sure that one is there. In order to avoid repeated allocations and frees we keep the buffer around unless we change vector length and just memset() it to ensure a clean register state. The function that deals with this takes the task to operate on as an argument, however in the case where we do a memset() we initialise using the SVE state size for the current task rather than the task passed as an argument. This is only an issue in the case where we are setting the register state for a task via ptrace and the task being configured has a different vector length to the task tracing it. In the case where the buffer is larger in the traced process we will leak old state from the traced process to itself, in the case where the buffer is smaller in the traced process we will overflow the buffer and corrupt memory. Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Cc: # 4.15.x Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210909165356.10675-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kernel/fpsimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -434,7 +434,7 @@ size_t sve_state_size(struct task_struct void sve_alloc(struct task_struct *task) { if (task->thread.sve_state) { - memset(task->thread.sve_state, 0, sve_state_size(current)); + memset(task->thread.sve_state, 0, sve_state_size(task)); return; } From patchwork Mon Sep 20 16:44:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 514350 Delivered-To: patch@linaro.org Received: by 2002:a02:c816:0:0:0:0:0 with SMTP id p22csp2297449jao; Mon, 20 Sep 2021 11:00:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyp2tZ1zZArbD9YbaSeATJMxgplZi1/A7+xm5ysuDlaNm2Rkk0Cgr1+ZOANrYSTn9TONm3C X-Received: by 2002:a05:6e02:1523:: with SMTP id i3mr14989932ilu.252.1632160802383; Mon, 20 Sep 2021 11:00:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632160802; cv=none; d=google.com; s=arc-20160816; b=vn6X6tz35aDZiuIR6cTVtZa9nCzG/alpd1q3yTeTymG7CDkKMFJfIjCYZy+MXF0ltC 4lhwQficOkUYZnCwG5YYDuofSiHte6u9FOkoH/w2ybxj7SVwBBaAau85bZWKzM1RR/oL hPztMzN6o8egXWL8ZswSP7uKtHqDofvaZI+Ta+qtQSR/WIzkodlUgSv3bTKnyiBb1dLP YruP1RwbVuX+qKMgHQITqvPjU0Ccoj0habbncNp3xg/a6vVnTCbyodl26xsHv1QkHs/U C5OLf5Qa4nSdptlVxpIbQCrYIUt9+hr2Yx923R1Bm5ytbxOWvHlMAQY7XJtcEChvJgEu Tgxg== 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=mXovP2SDQgv4rGSJ6ZdzDAg11J+5+Cb/kpuXcKoCRZ8=; b=S0rwM2bnx06wtN5zKI3TTdMtZhyVuw1HQKeaqUaGGd3XARkIE5KtVgObdb0Ygz1PQs nyYjCXo9b7hHFwB7+v2X4MrDW0AA8x3MSvwv1M2CgM9tgctYQm4BAoMiZTxySRSlZwzd roXyBgNeqm8IXOhi9AD1UHyUXsOHQhWPHk0QyuClTNtAvVIv9ltL8OkzjElwGriq+DBF MvpW+mM3RrQps/PYzo5DzaQ/N9Y1zIkV5EotkMHknajsuV7FKWqJSKmfzM4K0BK19n38 XYpFI1H+bFKFvklLDx0p1zyZUR6FhtEQ2o6ZV+uwyRi5HaN1CMxMPClRPzMhLcB/Ript u26w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eoZB5ACH; 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 b3si11882680iot.102.2021.09.20.11.00.01; Mon, 20 Sep 2021 11:00:02 -0700 (PDT) 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=eoZB5ACH; 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 S1350827AbhITSB0 (ORCPT + 11 others); Mon, 20 Sep 2021 14:01:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:57658 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355975AbhITR54 (ORCPT ); Mon, 20 Sep 2021 13:57:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0C90863216; Mon, 20 Sep 2021 17:14:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632158099; bh=ax2mhvkpee7ckuHwy+/FhcIhJe52nfgBGEDZ1nqYX9Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eoZB5ACHcVc8hB8pXSBCX498JnHxnl8kAuSP25hEVL2h6WmxVK7oAj5bn+qQMXumm K6dEPzs0P7AVZemaHTT2FsbCmvWeGKNNTUa1yuuvISmSZEjzm/eqeClz62MASt423r lRs6burllrrfhxw8yz6DbMMA8GeLzCgDB8ymm0gQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Davide Zini , Paolo Valente , Jens Axboe , Sasha Levin Subject: [PATCH 4.19 279/293] block, bfq: honor already-setup queue merges Date: Mon, 20 Sep 2021 18:44:01 +0200 Message-Id: <20210920163942.966284849@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163933.258815435@linuxfoundation.org> References: <20210920163933.258815435@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Paolo Valente [ Upstream commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b ] The function bfq_setup_merge prepares the merging between two bfq_queues, say bfqq and new_bfqq. To this goal, it assigns bfqq->new_bfqq = new_bfqq. Then, each time some I/O for bfqq arrives, the process that generated that I/O is disassociated from bfqq and associated with new_bfqq (merging is actually a redirection). In this respect, bfq_setup_merge increases new_bfqq->ref in advance, adding the number of processes that are expected to be associated with new_bfqq. Unfortunately, the stable-merging mechanism interferes with this setup. After bfqq->new_bfqq has been set by bfq_setup_merge, and before all the expected processes have been associated with bfqq->new_bfqq, bfqq may happen to be stably merged with a different queue than the current bfqq->new_bfqq. In this case, bfqq->new_bfqq gets changed. So, some of the processes that have been already accounted for in the ref counter of the previous new_bfqq will not be associated with that queue. This creates an unbalance, because those references will never be decremented. This commit fixes this issue by reestablishing the previous, natural behaviour: once bfqq->new_bfqq has been set, it will not be changed until all expected redirections have occurred. Signed-off-by: Davide Zini Signed-off-by: Paolo Valente Link: https://lore.kernel.org/r/20210802141352.74353-2-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- block/bfq-iosched.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.30.2 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index b2bad345c523..c8c94e8e0f72 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2137,6 +2137,15 @@ bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq) * are likely to increase the throughput. */ bfqq->new_bfqq = new_bfqq; + /* + * The above assignment schedules the following redirections: + * each time some I/O for bfqq arrives, the process that + * generated that I/O is disassociated from bfqq and + * associated with new_bfqq. Here we increases new_bfqq->ref + * in advance, adding the number of processes that are + * expected to be associated with new_bfqq as they happen to + * issue I/O. + */ new_bfqq->ref += process_refs; return new_bfqq; } @@ -2196,6 +2205,10 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, { struct bfq_queue *in_service_bfqq, *new_bfqq; + /* if a merge has already been setup, then proceed with that first */ + if (bfqq->new_bfqq) + return bfqq->new_bfqq; + /* * Prevent bfqq from being merged if it has been created too * long ago. The idea is that true cooperating processes, and @@ -2210,9 +2223,6 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (bfq_too_late_for_merging(bfqq)) return NULL; - if (bfqq->new_bfqq) - return bfqq->new_bfqq; - if (!io_struct || unlikely(bfqq == &bfqd->oom_bfqq)) return NULL;