Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6520335ybf; Thu, 5 Mar 2020 22:53:59 -0800 (PST) X-Google-Smtp-Source: ADFU+vv+soHfGjk2cj4fAqqn2/IjrS/1nI6cPNuFlqerMT+MZMdUM/VhMsqxi5PQ8mNud1dISN4b X-Received: by 2002:a9d:22e2:: with SMTP id y89mr1346192ota.132.1583477639582; Thu, 05 Mar 2020 22:53:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583477639; cv=none; d=google.com; s=arc-20160816; b=ve1sGaHemub5QAAXZmGJb/4jsxs6+D3rAdVBmka67fN5Mw19ThZhmBoSsE3FfKLc6I mvq4fSQCJTXbGCUVfeHnZix5bk7kDiSJkiYhJ/QOA6nnli00NU08RKZMegE90nOScVf1 1lRuf8D6V8DaRV2obM/nM6pGS63+qJuyHY2ZvTYWsfE15/z6aXjddFMB1FB2Ab/twtN7 xJBoeK/exoDze93Asi+jMUI/M0QRVzhZQHHb9AU4peVN61r0K1wqh5saex+YCbjFTVPw qAe2kjQtAOoAr2oNaZ1C470K/38Tin0FlPltAa0DT0LvG6Q1OYLqRx5CbHwS0xTXlEy6 sT4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/mARJYGslAJ8V9v0TPSw6dreIR1LiKX4t1V7F/dU3ew=; b=Dv0vrRQgHl2GrNhhiawH1ofk5G8VdpYBWddZ2wcKbq1+t7JWgX+LH4PbSqU7Pgt9eU sgkUlJVICuX50XN8rhhcywC8jY6k373/FEeLrMDc1CMbYeMint4zZFP6eKKAluVA2kzi kqECAEHCtX5cJpQK5tTClGyhNTQpXrHVTJc0Z+IkmDIV7brUCuvXN3hp9c3JObeNEA2I bGl+s9vZhK2eTGi9xGhxN8zfIPnxJe+y88j1DyCSfd+2OonFFrjGIaCDmV2aiSv6UIug lmEyjBXgy+QxH44YkNyUndJCH7T8sBdvngNgjSFNh2A0nkdckVnENVcx/v323SgBIp2d NjFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YRWfWW+P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l23si896558otf.181.2020.03.05.22.53.47; Thu, 05 Mar 2020 22:53:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YRWfWW+P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725959AbgCFGxE (ORCPT + 99 others); Fri, 6 Mar 2020 01:53:04 -0500 Received: from mail-io1-f65.google.com ([209.85.166.65]:45206 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbgCFGxE (ORCPT ); Fri, 6 Mar 2020 01:53:04 -0500 Received: by mail-io1-f65.google.com with SMTP id w9so1046880iob.12 for ; Thu, 05 Mar 2020 22:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/mARJYGslAJ8V9v0TPSw6dreIR1LiKX4t1V7F/dU3ew=; b=YRWfWW+PdyHfSJi8ExaraGhfeX3ywJEpqzVaR0lechfwGLoxZMXLGK1taQExIrWiG8 f7PX1JZaQ5oqFVc9EK+KAIuiZw4ej3DT0TAQsbrspHVY7K30dxLJtrHvU0R08CgCdRZM 5fVxO4+8GdjL2jH1+edlQ+EuSO9YD5E36+OZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/mARJYGslAJ8V9v0TPSw6dreIR1LiKX4t1V7F/dU3ew=; b=oluX/pXJUXarJCDdYbaht8djMIrWnAvfrigJseaHwtRlmT/aGy7qNUdOiZc8aathjl zm+7/qsrfes0I+2eQAVuQ38Ut5kMiNEzOHxJ+JfeOsWDK1ckDOwffo/LG+z5ITex4N03 TZ5fZUDgq6CI0MVT/Lwz0969SPMjD3YvzuGSTxtncj7b1W5VE6mgW0EhaZo3ssMD+31c 6eJ707hbcu+EpExI7HFKVaUJh2lsJtlYirSCPBiJQOrQ8QuUKxYp//6+D/Ada5UAPlKo BPjV2BcBLvJ7aCcx1o3+Lggy0dMOtuPCt9UQfiPVe+ce4sp1C+P1bb6T2KU0sGKDjV+6 3VSQ== X-Gm-Message-State: ANhLgQ1yCTAjaA5eZIprS4jSbb4wKrYJJoga9gdcPfwFIq5BxXmnUVBN 3RiOkTlcxUx/SfehNd00QpR2uqdp0QD6qhei3Qh7WQ== X-Received: by 2002:a6b:5b15:: with SMTP id v21mr1895802ioh.100.1583477581773; Thu, 05 Mar 2020 22:53:01 -0800 (PST) MIME-Version: 1.0 References: <20200302044021.97415-1-hsinyi@chromium.org> <46f27a3b-de4c-8d43-d6d7-d6332ee30451@xs4all.nl> In-Reply-To: <46f27a3b-de4c-8d43-d6d7-d6332ee30451@xs4all.nl> From: Hsin-Yi Wang Date: Fri, 6 Mar 2020 14:52:35 +0800 Message-ID: Subject: Re: [PATCH v4] media: mtk-vpu: avoid unaligned access to DTCM buffer. To: Hans Verkuil Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Minghsiu Tsai , Houlong Wei , Andrew-CT Chen , Tiffany Lin , Mauro Carvalho Chehab , Matthias Brugger , Enric Balletbo i Serra , linux-media@vger.kernel.org, linux-mediatek@lists.infradead.org, lkml Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 3, 2020 at 10:24 PM Hans Verkuil wrote: > > On 02/03/2020 05:40, Hsin-Yi Wang wrote: > > media: mtk-vpu: avoid unaligned access to DTCM buffer. > > > > Previously, vpu->recv_buf and send_buf are forced cast from > > void __iomem *tcm. vpu->recv_buf->share_buf is passed to > > vpu_ipi_desc.handler(). It's not able to do unaligned access. Otherwise > > kernel would crash due to unable to handle kernel paging request. > > > > struct vpu_run { > > u32 signaled; > > char fw_ver[VPU_FW_VER_LEN]; > > unsigned int dec_capability; > > unsigned int enc_capability; > > wait_queue_head_t wq; > > }; > > > > fw_ver starts at 4 byte boundary. If system enables > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, strscpy() will do > > read_word_at_a_time(), which tries to read 8-byte: *(unsigned long *)addr > > > > vpu_init_ipi_handler() calls strscpy(), which would lead to crash. > > > > vpu_init_ipi_handler() and several other handlers (eg. > > vpu_dec_ipi_handler) only do read access to this data, so they can be > > const, and we can use memcpy_fromio() to copy the buf to another non iomem > > buffer then pass to handler. > > > > Fixes: 85709cbf1524 ("media: replace strncpy() by strscpy()") > > Signed-off-by: Hsin-Yi Wang > > --- > > Change in v4: > > - Remove forced casting recv_buf from tcm. Copy iomem data before passing > > to handler. > > Change in v2, v3: > > - fix sparse warnings. > > --- > > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 9 ++-- > > .../media/platform/mtk-vcodec/vdec_vpu_if.c | 6 +-- > > .../media/platform/mtk-vcodec/venc_vpu_if.c | 12 ++--- > > drivers/media/platform/mtk-vpu/mtk_vpu.c | 45 ++++++++++--------- > > drivers/media/platform/mtk-vpu/mtk_vpu.h | 2 +- > > 5 files changed, 38 insertions(+), 36 deletions(-) > > > > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c > > index 6720d11f50cf..dc95b8a44759 100644 > > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c > > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c > > @@ -15,7 +15,7 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu) > > return container_of(vpu, struct mtk_mdp_ctx, vpu); > > } > > > > -static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg) > > +static void mtk_mdp_vpu_handle_init_ack(const struct mdp_ipi_comm_ack *msg) > > { > > struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *) > > (unsigned long)msg->ap_inst; > > @@ -26,10 +26,11 @@ static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg) > > vpu->inst_addr = msg->vpu_inst_addr; > > } > > > > -static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv) > > +static void mtk_mdp_vpu_ipi_handler(const void *data, unsigned int len, > > + void *priv) > > { > > - unsigned int msg_id = *(unsigned int *)data; > > - struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data; > > + unsigned int msg_id = *(const unsigned int *)data; > > + const struct mdp_ipi_comm_ack *msg = data; > > Why not just do: > > const struct mdp_ipi_comm_ack *msg = data; > unsigned int msg_id = msg->msg_id; > > Much cleaner. > > Other than this small issue this patch looks nice. No more sparse/smatch warnings > and no more weird casts :-) > > Regards, > > Hans > Updated in V5, thanks :) https://lore.kernel.org/lkml/20200304025851.173570-1-hsinyi@chromium.org/