Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp926220rwb; Thu, 18 Aug 2022 15:04:33 -0700 (PDT) X-Google-Smtp-Source: AA6agR6TpYrqz4NrlyOdzkwMa0dutuKvpoeh0Jb6l9hYORNIKA9TT/X2ElWN9zbhyBgHR6K4LNI6 X-Received: by 2002:a65:5205:0:b0:41d:f6f7:b38a with SMTP id o5-20020a655205000000b0041df6f7b38amr3794858pgp.121.1660860272823; Thu, 18 Aug 2022 15:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660860272; cv=none; d=google.com; s=arc-20160816; b=sReFZCR+WCfUAG6x1UBxPBBgT0oHAEUm9tI5O3r849pf9r/wXRLxCHOIdPnhRe3pYP x5SuAWtQLGwOEVNkuPWltLO3FcLNjEUevf9FAHXRVKTRtdA0etPrzk6rNGH1L+3krSoB mmtJhr3y6tYRcbqQqTjH3yditxwXkIeNEZMw/kd1wme5Fads5N8jL1S5AGLVLrTDEk4X cyMxqYGtlW3gVGBNymWWQopC1Txuc0SjhjzU3DmV4Somyq49L2dkskRIL2q4x+4gAjBj hZ/XARHYWfnpgGLOHEcA8gGqAo56PnRrX/TtqZIB0c6y1hYqKnVOl12eueRHJcOxG8nf U4lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=7W3xuCK7zFltGJ2TtasP50TVrg6WzFb6GQ6/FvOm7E4=; b=wVCU/guaOVEeSnBDaRMHejDmoTx9lyIygftYvRVFQETBJBb4NDRF5LXkrgivxe0JFj cuvy3dd1EP4+k3JncNKxRpVUtt8Gg1NPzVQl5xkz+OtA+88MW78nfRDl86vG5KmF3i4S 6IT/VBbm2Jd8ZrZWV1AxaHiSUCU3G7QR9JbZERUL+O9KIRx3R4ZVLRYYPEcQbqxxlMlW ugwmEqulwUICg+48kbEDninNmky+V7e54ak1go+VE4oxzSJlPC6jZEoHHUjshlwQ+1Rd i2+gFQYNZyXJZsyDMKzxoztxM+yns/ZsX4CpcRTUgPHQBaMAb7P3vCeBeV5zkSkj8xVv Wuxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Z7Pw0o0g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e13-20020a17090301cd00b0016ce8847b4dsi2409653plh.27.2022.08.18.15.04.21; Thu, 18 Aug 2022 15:04:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Z7Pw0o0g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244251AbiHRUkO (ORCPT + 99 others); Thu, 18 Aug 2022 16:40:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344732AbiHRUj4 (ORCPT ); Thu, 18 Aug 2022 16:39:56 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D3FAD2EA8; Thu, 18 Aug 2022 13:39:55 -0700 (PDT) Received: from [192.168.2.145] (109-252-119-13.nat.spd-mgts.ru [109.252.119.13]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 4BF276601B7A; Thu, 18 Aug 2022 21:39:53 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1660855194; bh=Emk87kB1bYtzutO6QswP9IPNXnW89sucuVH09hsng5k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Z7Pw0o0gnWPWmZc6NGY0rwGVgWxEM8Ox/f0Qru6PEcbXfg/hpT4nECwSEvaHNKWcN PCtD7bI01TG92ZmmgESKi8+aWT5bnRDIwQKiIaBJf7Vh+GrSJCyJ/YKma3nCKrqnss JGWIYuupLKiRqrFb6IbpeF92NR364iucQjlajtAjTlli/e/gkJbUfqHH9oytV6HNQ0 T6MovmAhiaSuR4nhkiveLcQrfcyE1RazFKffiDoNbKZJtc+ePQLnEBnhxwkCsd5a5z j7uwLfTmid70TJ2r/ayvb9JiKiNj7iuUsxg0nZ+PmeQ708Q2aCSNNgD35MvEjK+Jbi AW/6meAPhrgmQ== Message-ID: <2182ae07-4c0a-5937-7acc-3fad68d28baa@collabora.com> Date: Thu, 18 Aug 2022 23:39:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v1 3/3] media: cedrus: Fix endless loop in cedrus_h265_skip_bits() Content-Language: en-US To: Nicolas Dufresne , linux-media@vger.kernel.org, Maxime Ripard , Paul Kocialkowski , Mauro Carvalho Chehab , Greg Kroah-Hartman , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland Cc: kernel@collabora.com, stable@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org References: <20220818203308.439043-1-nicolas.dufresne@collabora.com> <20220818203308.439043-4-nicolas.dufresne@collabora.com> From: Dmitry Osipenko In-Reply-To: <20220818203308.439043-4-nicolas.dufresne@collabora.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/18/22 23:33, Nicolas Dufresne wrote: > From: Dmitry Osipenko > > The busy status bit may never de-assert if number of programmed skip > bits is incorrect, resulting in a kernel hang because the bit is polled > endlessly in the code. Fix it by adding timeout for the bit-polling. > This problem is reproducible by setting the data_bit_offset field of > the HEVC slice params to a wrong value by userspace. > > Cc: stable@vger.kernel.org > Reported-by: Nicolas Dufresne > Signed-off-by: Dmitry Osipenko > Signed-off-by: Nicolas Dufresne > --- > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > index f703c585d91c5..f0bc118021b0a 100644 > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > @@ -227,6 +227,7 @@ static void cedrus_h265_pred_weight_write(struct cedrus_dev *dev, > static void cedrus_h265_skip_bits(struct cedrus_dev *dev, int num) > { > int count = 0; > + u32 reg; This "reg" variable isn't needed anymore after switching to cedrus_wait_for(). Sorry, I missed it :) > while (count < num) { > int tmp = min(num - count, 32); > @@ -234,8 +235,9 @@ static void cedrus_h265_skip_bits(struct cedrus_dev *dev, int num) > cedrus_write(dev, VE_DEC_H265_TRIGGER, > VE_DEC_H265_TRIGGER_FLUSH_BITS | > VE_DEC_H265_TRIGGER_TYPE_N_BITS(tmp)); > - while (cedrus_read(dev, VE_DEC_H265_STATUS) & VE_DEC_H265_STATUS_VLD_BUSY) > - udelay(1); > + > + if (cedrus_wait_for(dev, VE_DEC_H265_STATUS, VE_DEC_H265_STATUS_VLD_BUSY)) > + dev_err_ratelimited(dev->dev, "timed out waiting to skip bits\n"); > > count += tmp; > } -- Best regards, Dmitry