On Tue, 10 Nov 2020 at 07:27, Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> wrote:
>
> 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().
It doesn't there's a bit of info out there on what happens, it really
only matters for structs we are passing to userspace, but it's
unlikely to matter here,
but I've changed this to memset in my local tree, because why not.
Dave
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
