From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77B96409621 for ; Thu, 9 Jul 2026 15:46:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783612007; cv=none; b=e1NcqQtJquvorVZe0XFUVPzSVWVM845tO14dAhJeZZqY6ikeiUPKRCitBySRDt5+JffaXoISqycgLe0JMapeHf3UfjM00gw7comLekbEgRHy9x3BxQ4orbnkBmKNx4UIisPB1zqUqC4+B+z0Zl80QbD8NwsGg7/HmiU+KFrWIOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783612007; c=relaxed/simple; bh=YWBKUDKRZRPtU+PtzWhqbylWfF/NGc3GC8ecVfV7g+s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=m4TqvNvGW/a2Td22o/SIDgJsp2hNTwv0HUuEwka7Nl2zkDy6uIxzfaeZdl4eKs7wWNrgeMmrJPtchQ4NMbQnVcrQbumENwSKD+bB8E+374vYbCrvzKmlzFpMtfaS67EcnKaSf6JVlbk3DGwvgTjZ2bRsQZZGNu6xLK+hpdUzYXQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hmA0qLCc; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hmA0qLCc" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-493e4ccccc2so8540415e9.2 for ; Thu, 09 Jul 2026 08:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783612003; x=1784216803; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=26eVrUBn/cVkx7Rxtr9TR48JaobyoAImvrhEAkxHe1E=; b=hmA0qLCcaQ4vAVGLb6e+Vf5CmWDwbjipK7ZBbQLjcXKSH5lF9ODPkBn5BbjeL/U/ed m2oIjZtgxDH6+4T8IVIuu3GMDhWFW1OXYvlEBsG2HCl0JWMNg8akuBKPMFXAzULb6Jk1 igTLMl4QS5v4IjKbDETn3cEjbekir67GOYMYYb7dnA2nle1BkwPNfWG/aboOGwgQa93B 0zdW1YUU9Mn4yxYxqD+rV8W+DXpKUsEUm00z5rQLnwfZnfWtzdbkK9OCoYhTT+dfz4u+ 2gutfZblAFaSvi3KBUMNAeOPULQaf8BRrI3wzcjO5Bhujb/NBUCuv4IghpmLCuv9Fyc6 NjPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783612003; x=1784216803; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=26eVrUBn/cVkx7Rxtr9TR48JaobyoAImvrhEAkxHe1E=; b=hCBsdXCwYKK4Dg7MG2B68Avopq8uqXtvqSPBvN2ooZt0ojV/fk1fvr2xlHxM+9ovax Cja0RZ92k3zFao3bzKvDVFIIg4DVYKfy7tInaB1VAe3/8ZasQSmDfjRg2HjimwVhtePr HUJEHIRlVW6Atc2deHgMahp2CFiGBMC7xa2QG936EnLIyi9Zs2d/XtTrpZ49F5MOvWjV AklGGGo1xmwe8WSFgzecQvo4G86zjorxnXQdjB6uncqBtftBB8iL31ipYJ8IjSRrUL9i mDJZuTriOC34ROTaXc53WxQm91ygdBhlhOrpWObSttPcdCLcgn+W5yaj5WVuDXPAikyQ H7EQ== X-Forwarded-Encrypted: i=1; AHgh+Rp5KqvaYO65jNFJiUnaakKEH563LfpqYqFfQ82itSWwRlnpWw/5Q/dR2dGCWjqh3LbGKJnqaXfeyDxe8Eo=@vger.kernel.org X-Gm-Message-State: AOJu0YwMkBMG9woXLqK2kkn6RV2St+HuHS8kEM2zRilSxr+HSZP2BxZX xPgFNyJjFybJ6qhSmtEjvgx/QSZRE+pUpCXw8VB5lUNR2yl2Lr9PJBgI X-Gm-Gg: AfdE7cmXnsGDLn0nkjD+UQpcZ0iy1mP4nz0SBbLB2YOOqkpmzoceCtzORqPZMpALhAT i6E/JpgX5q7qcBSNH4sLYB1Y0L2c6/ULQpZHh3MA6SfNdYku6P2YesETjrBl+ZlwIaWa3SZ5v+9 shIvtheFrBRIRm6QbOrfVzCt8U3dTJJku/uLbd7wlFUsIBzuXUMFfKk8Q5pNMiHks3bSu9Nj2dd 6pfZc0/5kIxe5okn4IaDyjuoNQbDelqek3+U3YYvjksPFkjwTImb5gBJL6HYhTVdhhw2TeRpjs1 DYQ65L9mBv+/EWC5UpTiBHx6WBLjBgNDW6GfRu0arWtZdeLAVL0H/xoC6K98fsWSlMgNt3QDNbi qO9vN9Xx9K20tMEMUCVlWkN51bPx513Y3hNJzNQLwSSHsp4JVbj9PrywlohiMRZKFM3oxLyI1Ba CxCmv+yyBmisYrrg9dY366z8MymUzp6x2Sg06PKKQmnSKrWA== X-Received: by 2002:a05:600c:6286:b0:493:b7a6:3dac with SMTP id 5b1f17b1804b1-493e68f0746mr70686575e9.33.1783612002553; Thu, 09 Jul 2026 08:46:42 -0700 (PDT) Received: from pumpkin (host-92-21-50-228.as13285.net. [92.21.50.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039afacsm50085771f8f.19.2026.07.09.08.46.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 08:46:42 -0700 (PDT) Date: Thu, 9 Jul 2026 16:46:40 +0100 From: David Laight To: David CARLIER Cc: Jacopo Mondi , Laurent Pinchart , dan.scally@ideasonboard.com, mchehab@kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] media: mali-c55: Fix unaligned access of AEC histogram zone weights Message-ID: <20260709164640.1dba64bf@pumpkin> In-Reply-To: References: <20260702103453.348056-1-devnexen@gmail.com> <20260703221651.41669d55@pumpkin> <20260706104652.GB66892@killaraus.ideasonboard.com> <20260706133956.39a11738@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 9 Jul 2026 06:00:58 +0100 David CARLIER wrote: > > Does it ? > [...] > > seems to clarify this is a non-issue ? > > I think you're right that there's no runtime fault: arm64 has > HAVE_EFFICIENT_UNALIGNED_ACCESS and runs with SCTLR.A off, so the > unaligned load doesn't trap. It's really just a C-level thing - the > (u32 *) cast is UB and -fsanitize=alignment would moan - rather than a > real bug, which is why v2 already dropped Fixes:/stable. > > > I still see zone_weights[] at offset 10 which is not 4 bytes aligned. > > What have I missed ? > > I don't think you missed anything - the union isn't trying to move the > array, offset 10 has to stay. The idea is just the __packed member: it > makes zone_weights_32[i] an alignment-1 read, so the compiler does the > right thing (a plain LDR on arm64) with no cast, no get_unaligned() and > no memcpy(). Same 240-byte layout, and it also avoids David's KASAN > concern about memcpy(). I think you'll also find that gcc will generate a real call to memcpy() on both sparc64 and riscv64 (and possibly all architectures that fault misaligned accesses) even if the char[] is at an aligned structure offset. Either that or, if you include the (u32) cast, it will assume the pointer is a valid 'u32' pointer and generate faulting misaligned access. So while this is arm64 specific code it is a bad idea in general. > > So if you'd like it cleaned up, in mali-c55-config.h: > > union { > __u32 zone_weights_32[56] __attribute__((__packed__)); Should be MALI_C55_MAX_ZONES/4. > __u8 zone_weights[MALI_C55_MAX_ZONES]; > }; > > and index zone_weights_32[i] in the driver. That is the safe way to do it. Even on x86 I've fallen foul of misaligned data traps when gcc has used simd instructions to unroll a loop. I knew the buffer could be unaligned, but needed a sum of all the 32bit words (to set a checksum). Worked find until it didn't... David > And if you'd rather not > carry the uapi churn for something that isn't a fault, I'm equally happy > to just drop it - whichever you prefer. > > Cheers