Message ID | 20230712092606.2508-1-jammy_huang@aspeedtech.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1036400vqm; Wed, 12 Jul 2023 03:02:07 -0700 (PDT) X-Google-Smtp-Source: APBJJlHaAvpSByd0gscg/03LCmQBAKHo5YXpvZ3kp/RdO8bQZAsYbee9zrY9KFqWR86HvK29W7pB X-Received: by 2002:a05:6a00:3920:b0:67e:bf65:ae68 with SMTP id fh32-20020a056a00392000b0067ebf65ae68mr15571168pfb.3.1689156127545; Wed, 12 Jul 2023 03:02:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689156127; cv=none; d=google.com; s=arc-20160816; b=IdCsWZFTeHTemf/kBdHcSsHc4sRfkodSMto2vDMtphM3n25ttckairKd8WFtButCf9 V9OF8X9Uqm77AjwKZphEamMeIk8WYIGStmksh0WfaBDBIlei38cbw38ZCNcEBmv5hUmH T7cTql3tapKrQSrizjUx47Pm5toqNSXpEyQILiHCGETr3qanI3fLHUwtjccih0tu0gHx 6+SeUb4VTnlpqJD8YZlC5b3EWn6rR4ecG5Z1wddJb4STzFD2avYhNYMkWHdlDcqyNlqA EpPNgIJfU0i0DHICdpjsrNe1c4cZSWbUZCuU+Lbj/B11E+43fpn9/b3KqnnOd5PbGe1X BWaA== 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 :message-id:date:subject:to:from; bh=mXmAo8SNM3+cvqoHh+6giP8OfOwimtzhOg6I1Nxf3vw=; fh=UHrYfwX39AA1q4czusZlJFtSsgOVyN7bmwctWlneOnk=; b=TfcJiyqCQwI6jw7MhtZ/IrURKPMrVPNOubq5LgQ8AGWQHEPLCjhB0i0XFPaHRsW8dJ 1aDjRkSFaObKcIy7SNP41KwMzF1uZHMluDnDi3OCCIK+8jyVLcLuF5q1NYmvfW+s/q7v 5sSs3+8hk4Rjq3Bpenb4TA9RFQV879SZhLeNYMW+4VO4FmaoWkYG/NI7K7po5xXV9Hme 5dsQSTrtYEBVMsboRZDsCTrZsAmmGZTWNrHb6GVaGXYGX+n7ScN1TwtfJH4tIZfhretg I8yb3T8/F28GkZsjyykaCw92isGY43semXD/noLVR0TlCawPAFebD8kkT2aTQlT7ecPP i/rg== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i64-20020a638743000000b0055baf9fc37esi2885427pge.30.2023.07.12.03.01.54; Wed, 12 Jul 2023 03:02:07 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233151AbjGLJ2W (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Wed, 12 Jul 2023 05:28:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232371AbjGLJ2S (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 12 Jul 2023 05:28:18 -0400 X-Greylist: delayed 62 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 12 Jul 2023 02:28:15 PDT Received: from mail.aspeedtech.com (211-20-114-226.hinet-ip.hinet.net [211.20.114.226]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B590FB; Wed, 12 Jul 2023 02:28:15 -0700 (PDT) Received: from JammyHuang-PC.aspeed.com (192.168.2.181) by TWMBX02.aspeed.com (192.168.0.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Jul 2023 17:26:09 +0800 From: Jammy Huang <jammy_huang@aspeedtech.com> To: <eajames@linux.ibm.com>, <mchehab@kernel.org>, <joel@jms.id.au>, <andrew@aj.id.au>, <linux-media@vger.kernel.org>, <openbmc@lists.ozlabs.org>, <linux-arm-kernel@lists.infradead.org>, <linux-aspeed@lists.ozlabs.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] media: aspeed: Fix memory overwrite if timing is 1600x900 Date: Wed, 12 Jul 2023 17:26:06 +0800 Message-ID: <20230712092606.2508-1-jammy_huang@aspeedtech.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [192.168.2.181] X-ClientProxiedBy: TWMBX02.aspeed.com (192.168.0.24) To TWMBX02.aspeed.com (192.168.0.24) X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771208575596881693 X-GMAIL-MSGID: 1771208575596881693 |
Series |
media: aspeed: Fix memory overwrite if timing is 1600x900
|
|
Commit Message
Jammy Huang
July 12, 2023, 9:26 a.m. UTC
When capturing 1600x900, system could crash when system memory usage is
tight.
The size of macro block captured is 8x8. Therefore, we should make sure
the height of src-buf is 8 aligned to fix this issue.
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
---
drivers/media/platform/aspeed/aspeed-video.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
base-commit: 2605e80d3438c77190f55b821c6575048c68268e
Comments
Dear Jammy, Thank you very much for your patch. Am 12.07.23 um 11:26 schrieb Jammy Huang: > When capturing 1600x900, system could crash when system memory usage is > tight. Please provide part of the trace, and if you have a commend to reproduce it, please also add it. Is it documented somewhere, that it needs to be aligned? > The size of macro block captured is 8x8. Therefore, we should make sure > the height of src-buf is 8 aligned to fix this issue. > > Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com> > --- > drivers/media/platform/aspeed/aspeed-video.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/aspeed/aspeed-video.c b/drivers/media/platform/aspeed/aspeed-video.c > index 374eb7781936..14594f55a77f 100644 > --- a/drivers/media/platform/aspeed/aspeed-video.c > +++ b/drivers/media/platform/aspeed/aspeed-video.c > @@ -1130,7 +1130,7 @@ static void aspeed_video_get_resolution(struct aspeed_video *video) > static void aspeed_video_set_resolution(struct aspeed_video *video) > { > struct v4l2_bt_timings *act = &video->active_timings; > - unsigned int size = act->width * act->height; > + unsigned int size = act->width * ALIGN(act->height, 8); > > /* Set capture/compression frame sizes */ > aspeed_video_calc_compressed_size(video, size); > @@ -1147,7 +1147,7 @@ static void aspeed_video_set_resolution(struct aspeed_video *video) > u32 width = ALIGN(act->width, 64); > > aspeed_video_write(video, VE_CAP_WINDOW, width << 16 | act->height); > - size = width * act->height; > + size = width * ALIGN(act->height, 8); Maybe add a comment. Excuse my ignorance, but as `width` is already 64 bit aligned, how does aligning the second factor make a difference for `size`? Can you give an example? > } else { > aspeed_video_write(video, VE_CAP_WINDOW, > act->width << 16 | act->height); > > base-commit: 2605e80d3438c77190f55b821c6575048c68268e Kind regards, Paul
Hi Paul, On 2023/7/12 下午 06:09, Paul Menzel wrote: > Dear Jammy, > > > Thank you very much for your patch. > > Am 12.07.23 um 11:26 schrieb Jammy Huang: >> When capturing 1600x900, system could crash when system memory usage is >> tight. > > Please provide part of the trace, and if you have a commend to > reproduce it, please also add it. Is it documented somewhere, that it > needs to be aligned? Sorry, but I didn't find trace when this issue happened.The system just crash and reboot. It just takes a few minutes to reproduce this issue using the way as below, 1. Use 1600x900 to display on host 2. Mount ISO through 'Virtual media' on OpenBMC's web 3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. Open KVM on OpenBMC's web I will add above information to next patch. > >> The size of macro block captured is 8x8. Therefore, we should make sure >> the height of src-buf is 8 aligned to fix this issue. >> >> Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com> >> --- >> drivers/media/platform/aspeed/aspeed-video.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/platform/aspeed/aspeed-video.c >> b/drivers/media/platform/aspeed/aspeed-video.c >> index 374eb7781936..14594f55a77f 100644 >> --- a/drivers/media/platform/aspeed/aspeed-video.c >> +++ b/drivers/media/platform/aspeed/aspeed-video.c >> @@ -1130,7 +1130,7 @@ static void aspeed_video_get_resolution(struct >> aspeed_video *video) >> static void aspeed_video_set_resolution(struct aspeed_video *video) >> { >> struct v4l2_bt_timings *act = &video->active_timings; >> - unsigned int size = act->width * act->height; >> + unsigned int size = act->width * ALIGN(act->height, 8); >> /* Set capture/compression frame sizes */ >> aspeed_video_calc_compressed_size(video, size); >> @@ -1147,7 +1147,7 @@ static void aspeed_video_set_resolution(struct >> aspeed_video *video) >> u32 width = ALIGN(act->width, 64); >> aspeed_video_write(video, VE_CAP_WINDOW, width << 16 | >> act->height); >> - size = width * act->height; >> + size = width * ALIGN(act->height, 8); > > Maybe add a comment. > > Excuse my ignorance, but as `width` is already 64 bit aligned, how > does aligning the second factor make a difference for `size`? Can you > give an example? > >> } else { >> aspeed_video_write(video, VE_CAP_WINDOW, >> act->width << 16 | act->height); >> >> base-commit: 2605e80d3438c77190f55b821c6575048c68268e > > > Kind regards, > > Paul
diff --git a/drivers/media/platform/aspeed/aspeed-video.c b/drivers/media/platform/aspeed/aspeed-video.c index 374eb7781936..14594f55a77f 100644 --- a/drivers/media/platform/aspeed/aspeed-video.c +++ b/drivers/media/platform/aspeed/aspeed-video.c @@ -1130,7 +1130,7 @@ static void aspeed_video_get_resolution(struct aspeed_video *video) static void aspeed_video_set_resolution(struct aspeed_video *video) { struct v4l2_bt_timings *act = &video->active_timings; - unsigned int size = act->width * act->height; + unsigned int size = act->width * ALIGN(act->height, 8); /* Set capture/compression frame sizes */ aspeed_video_calc_compressed_size(video, size); @@ -1147,7 +1147,7 @@ static void aspeed_video_set_resolution(struct aspeed_video *video) u32 width = ALIGN(act->width, 64); aspeed_video_write(video, VE_CAP_WINDOW, width << 16 | act->height); - size = width * act->height; + size = width * ALIGN(act->height, 8); } else { aspeed_video_write(video, VE_CAP_WINDOW, act->width << 16 | act->height);