[PATCH 1/4] drm/ttm: add multihop infrastrucutre (v2)

[Ville Syrjälä]

On Mon, Nov 09, 2020 at 09:48:04PM +0100, Christian König wrote:
> Am 09.11.20 um 17:43 schrieb Ville Syrjälä:
> > On Mon, Nov 09, 2020 at 05:20:17PM +0100, Christian König wrote:
> >> Am 09.11.20 um 17:18 schrieb Ville Syrjälä:
> >>> On Mon, Nov 09, 2020 at 04:57:29PM +0100, Christian König wrote:
> >>>> Am 09.11.20 um 16:16 schrieb Ville Syrjälä:
> >>>>> On Wed, Nov 11, 2020 at 06:13:02PM +0100, Christian König wrote:
> >>>>>> Am 09.11.20 um 01:54 schrieb Dave Airlie:
> >>>>>>> @@ -1432,15 +1479,18 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
> >>>>>>>      	if (bo->mem.mem_type != TTM_PL_SYSTEM) {
> >>>>>>>      		struct ttm_operation_ctx ctx = { false, false };
> >>>>>>>      		struct ttm_resource evict_mem;
> >>>>>>> +		struct ttm_place hop = {};
> >>>>>> Please always use memset() if you want to zero initialize something in
> >>>>>> the kernel, we had enough trouble with that.
> >>>>> What trouble is that? I've not heard of anything, and we use
> >>>>> ={} quite extensively in drm land.
> >>>> ={} initializes only named fields, not padding.
> >>> Has that actually happened?
> >> YES! Numerous times!
> > You wouldn't happen to have links/etc. to the discussion?
> > I'd like to check them out.
> 
> Uff, that was years ago. Just google for something like "mesa memset 
> hash", there was recently (~ the last year) another discussion because 
> somebody ran into exactly that problem once more.

Found this:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2071
which does suprise me a bit. Though I suspect ={} might
behave differently since the compiler might treat it
more like a memset().

Also makes me wonder about padding in general, because IIRC
the standard allows padding to be clobbered even after
initialization whenever any member is getting written. So
I think technically there is no guaranteed way to clear
the padding unless you never store anything into the struct.

-- 
Ville Syrjälä
Intel