On Mon, Jun 17, 2024 at 08:38:20PM GMT, Andi Shyti wrote:
On Mon, Jun 17, 2024 at 10:46:07AM -0500, Lucas De Marchi wrote:
On Mon, Jun 17, 2024 at 04:22:11PM GMT, Andi Shyti wrote:
> On Mon, Jun 17, 2024 at 07:55:10AM -0500, Lucas De Marchi wrote:
> > On Sun, Jun 16, 2024 at 09:03:48AM GMT, Andi Shyti wrote:
> > > Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
> > > warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's
> > > supposed to return a pointer to the intel_memory_region
> > > structure.
> > >
> > > Sparse complains with the following message:
> > >
> > > > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c:943:32: sparse: sparse:
> > > Using plain integer as NULL pointer
> > >
> > > The caller checks for errors, and if no error is returned, it
> > > stores the address of the stolen memory. Therefore, we can't
> > > return NULL. Since we are handling a case of out-of-bounds, it's
> > > appropriate to treat the "lmem_size < dsm_base" case as an error.
> >
> > which completely invalidates the point of the commit that introduced this
> > regression. That was commit was supposed to do "let's continue, just
> > disabling stolen".
>
> Yes, correct, I missed the point while fixing stuff. But patch 2
> is still valid.
no, it's not. It's introduced by the same commit. I went to look into
this exactly because of the second issue: it broke 32b build in xe and
all the CI.Hooks in xe are failing.
yes, it's broken because it's using %lli, right? In 32b it should
be %li.
Patch 2 is replacing %lli with %pa which should fix the 32b
build.
I'm sending a new series now.
wait... but instead of reverting you are sending a new series changing
the first patch to return NULL. However in your commit message you said
for this version:
The caller checks for errors, and if no error is returned, it
stores the address of the stolen memory. Therefore, we can't
return NULL. Since we are handling a case of out-of-bounds, it's
appropriate to treat the "lmem_size < dsm_base" case as an error.
Return -EINVAL embedded in a pointer instead of '0' (or NULL).
This way, we avoid a potential NULL pointer dereference.
So... what's it? Can we return NULL or not? Is this tested on that
scenario with with small BAR or does the module
just fail to load later and explode?
Lucas De Marchi
Andi
Lucas De Marchi
>
> Thanks,
> Andi
