radeon VS amdgpu: _afmt_init() behavior if kzalloc fails

[Alexandre Demers]

Hi again,

I'm talking about modifying radeon's side to mimic amdgpu's behavior, sorry
for the confusion.

Cheers,
Alexandre

On Fri, 12 Aug 2016 at 12:17 StDenis, Tom <Tom.StDenis at amd.com> wrote:

> Hi Alex,
>
>
> I'm unsure of what patch you have specifically.  Are you suggesting to
> modify the radeon side to mimic the behaviour?  Or to revert the amdgpu
> changes?  I  think reverting the amdgpu side won't go over well.  It's
> churn and the current approach is arguably better for a number of reasons
> namely it's better defined behaviour and generally speaking if during
> module init a kmalloc of 100 bytes fails something bad is happening and you
> want to abort init anyways (so failing to load just because part of DCE
> fails is probably a good thing).
>
>
> Tom
>
>
>
>
>
> ------------------------------
> *From:* Alexandre Demers <alexandre.f.demers at gmail.com>
> *Sent:* Friday, August 12, 2016 12:11
> *To:* StDenis, Tom; Freedesktop - AMD-gfx
> *Cc:* Alexander Deucher
> *Subject:* Re: radeon VS amdgpu: _afmt_init() behavior if kzalloc fails
>
> Thanks for the quick answer Tom. I was thinking mostly as you do, but
> before sending the patch to the list, I wanted to be sure it was worth it.
>
> I'll send the patch later then, unless someone says otherwise.
>
> Cheers,
> Alexandre
>
> On Fri, 12 Aug 2016 at 11:50 StDenis, Tom <Tom.StDenis at amd.com> wrote:
>
>> Hi,
>>
>>
>> I wrote those changes back in March as part of a cleanup sweep.  The idea
>> being was that if some had failed the state of the driver would be unknown
>> so it was cleaner to simply abort allocating any memory and set all of the
>> pointers to NULL.
>>
>>
>> Generally speaking if you fail to kmalloc a few bytes you've got bigger
>> problems to worry about than your audio not working ideally.
>>
>>
>> Tom
>>
>>
>> ------------------------------
>> *From:* amd-gfx <amd-gfx-bounces at lists.freedesktop.org> on behalf of
>> Alexandre Demers <alexandre.f.demers at gmail.com>
>> *Sent:* Friday, August 12, 2016 11:43
>> *To:* Freedesktop - AMD-gfx
>> *Cc:* Alexander Deucher
>> *Subject:* radeon VS amdgpu: _afmt_init() behavior if kzalloc fails
>>
>> Hi,
>>
>> While comparing radeon's radeon_afmt_init() to dce_vX_0_afmt_init() on
>> the amdgpu's side, I saw that on the latter:
>> 1- when kzalloc fails to allocate mem for all afmt, an ENOMEM is returned
>> 2- all previously allocated afmt are freed
>>
>> So on the amdgpu's side, it is an "all or none allocated" situation,
>> while on the radeon's side, some afmt may be allocated and initialized.
>>
>> Moreover, returning an ENOMEM prevents any other function calls in
>> dce_vX_0_sw_init() on the amdgpu's side, while it continues on the
>> radeon's side.
>>
>> What is the expected behavior here? Should we rewind the memory
>> allocation as it is done under amdgpu when we can't allocate memory for all
>> afmt or is it OK to do as it is done on radeon? Should we stop any
>> remaining steps in radeon_modeset_init() if it fails (thus, returning a
>> ENOMEM from radeon_afmt_init())?
>>
>> The patch is already ready if needed, I could send it later from home if
>> the amdgpu's behavior is the one that we are looking for.
>>
>> Cheers,
>> Alexandre Demers
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20160812/86d0f6dd/attachment-0001.html>