From: Marijn Suijten <marijn.suijten@somainline.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: phone-devel@vger.kernel.org, "Rob Clark" <robdclark@gmail.com>,
"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
"Vinod Koul" <vkoul@kernel.org>,
~postmarketos/upstreaming@lists.sr.ht,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@somainline.org>,
"Konrad Dybcio" <konrad.dybcio@somainline.org>,
"Martin Botka" <martin.botka@somainline.org>,
"Jami Kettunen" <jami.kettunen@somainline.org>,
"Sean Paul" <sean@poorly.run>, "David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Stephen Boyd" <swboyd@chromium.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Jessica Zhang" <quic_jesszhan@quicinc.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Kuogee Hsieh" <quic_khsieh@quicinc.com>,
"Jani Nikula" <jani.nikula@intel.com>,
sunliming <sunliming@kylinos.cn>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Haowen Bai" <baihaowen@meizu.com>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Loic Poulain" <loic.poulain@linaro.org>,
"Vinod Polimera" <quic_vpolimer@quicinc.com>,
"Douglas Anderson" <dianders@chromium.org>,
"Vladimir Lypak" <vladimir.lypak@gmail.com>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Drew Davenport" <ddavenport@chromium.org>
Subject: Re: [PATCH v2 4/8] drm/msm/dpu: Disallow unallocated resources to be returned
Date: Mon, 9 Jan 2023 18:12:23 +0100 [thread overview]
Message-ID: <20230109171223.vjkigcj7xwfwow2a@SoMainline.org> (raw)
In-Reply-To: <CAA8EJppqocjgTbZLhcJtmRGjE4X2u_jDEGDWS9Bsp7MEgD+Ldg@mail.gmail.com>
On 2023-01-09 11:06:45, Dmitry Baryshkov wrote:
> On Mon, 9 Jan 2023 at 10:24, Marijn Suijten
> <marijn.suijten@somainline.org> wrote:
> >
> > On 2023-01-09 01:30:29, Dmitry Baryshkov wrote:
> > > On 09/01/2023 01:28, Dmitry Baryshkov wrote:
> > > > On 22/12/2022 01:19, Marijn Suijten wrote:
> > > >> In the event that the topology requests resources that have not been
> > > >> created by the system (because they are typically not represented in
> > > >> dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC
> > > >> blocks) remain NULL but will still be returned out of
> > > >> dpu_rm_get_assigned_resources, where the caller expects to get an array
> > > >> containing num_blks valid pointers (but instead gets these NULLs).
> > > >>
> > > >> To prevent this from happening, where null-pointer dereferences
> > > >> typically result in a hard-to-debug platform lockup, num_blks shouldn't
> > > >> increase past NULL blocks and will print an error and break instead.
> > > >> After all, max_blks represents the static size of the maximum number of
> > > >> blocks whereas the actual amount varies per platform.
> > > >>
> > > >> ^1: which can happen after a git rebase ended up moving additions to
> > > >> _dpu_cfg to a different struct which has the same patch context.
> > > >>
> > > >> Fixes: bb00a452d6f7 ("drm/msm/dpu: Refactor resource manager")
> > > >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > > >> ---
> > > >> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 5 +++++
> > > >> 1 file changed, 5 insertions(+)
> > > >
> > > > I think the patch is not fully correct. Please check resource
> > > > availability during allocation. I wouldn't expect an error from
> > > > get_assigned_resources because of resource exhaustion.
> >
> > Theoretically patch 5/8 should take care of this, and we should never
> > reach this failure condition. Emphasis on /should/, this may happen
> > again if/when another block type is added with sub-par resource
> > allocation and assignment implementation.
>
> Yeah. Maybe swapping 4/8 and 5/8 makes sense.
Ack.
> > > Another option, since allocation functions (except DSC) already have
> > > these safety checks: check error message to mention internal
> > > inconstency: allocated resource doesn't exist.
> >
> > Is this a suggestion for the wording of the error message?
>
> Yes. Because the current message makes one think that it is output
> during allocation / assignment to encoder, while this is a safety net.
Good. So the patch is correct, just the wording is off, which I fully
agree on. This isn't allocating anything, just handing out what was
previously allocated (and is a safety net).
- Marijn
next prev parent reply other threads:[~2023-01-09 17:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 23:19 [PATCH v2 0/8] drm/msm: DSC Electric Boogaloo for sm8[12]50 Marijn Suijten
2022-12-21 23:19 ` [PATCH v2 1/8] drm/msm/dpu: Wire up DSC mask for active CTL configuration Marijn Suijten
2023-01-08 23:23 ` Dmitry Baryshkov
2022-12-21 23:19 ` [PATCH v2 2/8] drm/msm/dsi: Use DSC slice(s) packet size to compute word count Marijn Suijten
2022-12-21 23:19 ` [PATCH v2 3/8] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf Marijn Suijten
2022-12-21 23:19 ` [PATCH v2 4/8] drm/msm/dpu: Disallow unallocated resources to be returned Marijn Suijten
2023-01-08 23:28 ` Dmitry Baryshkov
2023-01-08 23:30 ` Dmitry Baryshkov
2023-01-09 8:23 ` Marijn Suijten
2023-01-09 9:06 ` Dmitry Baryshkov
2023-01-09 17:12 ` Marijn Suijten [this message]
2023-01-09 18:24 ` Dmitry Baryshkov
2022-12-21 23:19 ` [PATCH v2 5/8] drm/msm/dpu: Reject topologies for which no DSC blocks are available Marijn Suijten
2023-01-08 23:29 ` Dmitry Baryshkov
2022-12-21 23:19 ` [PATCH v2 6/8] drm/msm/dpu: Remove num_enc from topology struct in favour of num_dsc Marijn Suijten
2023-01-08 23:31 ` Dmitry Baryshkov
2023-01-09 8:21 ` Marijn Suijten
2023-01-09 9:08 ` Dmitry Baryshkov
2022-12-21 23:19 ` [PATCH v2 7/8] drm/msm/dpu: Implement DSC binding to PP block for CTL V1 Marijn Suijten
2022-12-21 23:19 ` [PATCH v2 8/8] drm/msm/dpu: Add DSC configuration for SM8150 and SM8250 Marijn Suijten
2023-01-05 14:49 ` [PATCH v2 0/8] drm/msm: DSC Electric Boogaloo for sm8[12]50 Daniel Vetter
2023-01-09 7:59 ` Marijn Suijten
2023-01-09 22:41 ` Dmitry Baryshkov
2023-01-09 23:43 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230109171223.vjkigcj7xwfwow2a@SoMainline.org \
--to=marijn.suijten@somainline.org \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@somainline.org \
--cc=baihaowen@meizu.com \
--cc=daniel@ffwll.ch \
--cc=ddavenport@chromium.org \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jami.kettunen@somainline.org \
--cc=jani.nikula@intel.com \
--cc=konrad.dybcio@linaro.org \
--cc=konrad.dybcio@somainline.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=martin.botka@somainline.org \
--cc=phone-devel@vger.kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=quic_vpolimer@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sam@ravnborg.org \
--cc=sean@poorly.run \
--cc=sunliming@kylinos.cn \
--cc=swboyd@chromium.org \
--cc=ville.syrjala@linux.intel.com \
--cc=vkoul@kernel.org \
--cc=vladimir.lypak@gmail.com \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).