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.