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;
Date:   Sat, 29 Oct 2022 13:43:30 +1300
From:   Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To:     Christian =?utf-8?B?S8O2bmln?= <christian.koenig@amd.com>
Cc:     Kees Cook <keescook@chromium.org>,
        Alex Deucher <alexander.deucher@amd.com>,
        "Pan, Xinhui" <Xinhui.Pan@amd.com>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Hans de Goede <hdegoede@redhat.com>,
        Grigory Vasilyev <h0tc0d3@gmail.com>,
        Claudio Suarez <cssk@net-c.es>,
        Slark Xiao <slark_xiao@163.com>,
        Rongguang Wei <weirongguang@kylinos.cn>,
        amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [next] drm/amdgpu: Replace one-element array with
 flexible-array member
Message-ID: <Y1x3MtRJ8ckXxlJn@mail.google.com>
References: <Y1tkWdwPUp+UdpM0@mail.google.com>
 <04e37ee1-53b0-97ab-d6d7-a39edfbdc2ea@amd.com>
 <202210280855.9DF8E4D72@keescook>
 <1052fba8-11ac-cec8-92e7-b994266c6970@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1052fba8-11ac-cec8-92e7-b994266c6970@amd.com>
Precedence: bulk

On Fri, Oct 28, 2022 at 07:33:17PM +0200, Christian König wrote:
> Am 28.10.22 um 18:36 schrieb Kees Cook:
> 
> > All that said, converting away from them can be tricky, and I think such
> > conversions need to explicitly show how they were checked for binary
> > differences[2].
> 
> Oh, that's a great idea! Yes, if this can be guaranteed then the change is
> obviously perfectly ok.
> 
> > 
> > Paulo, can you please check for deltas and report your findings in the
> > commit log? Note that add struct_size() use in the same patch may result
> > in binary differences, so for more complex cases, you may want to split
> > the 1-element conversion from the struct_size() conversions.
> > 
> > -Kees

Noted. I will reporting my findings on commit logs from now onwards. 

Given that I split the if-ternary to avoid checking "fake_edid_record->ucFakeEDIDLength"
twice then (for the current patch), yes, there will be changes to *.o|ko files.

Knowing that Christian would feel more confident with no binary changes
at this point, I will send a different patch aiming solely on the
replacement of 1-elem array without incurring binary changes.

--
Paulo A.