From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2567C433F5 for ; Tue, 31 May 2022 06:27:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244274AbiEaG1M (ORCPT ); Tue, 31 May 2022 02:27:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244265AbiEaG1G (ORCPT ); Tue, 31 May 2022 02:27:06 -0400 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26682AE5E for ; Mon, 30 May 2022 23:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=q0Ly3VYEbjYqQhjsAGdFo317POmXxxJct8nswHWSNRc=; b=Crq9x9JaUkBocQegHBPU2uNvvPdzl7EqK4zJYsHxWYYL5HcLcVQKBQhr 9tKuFo4YEJfEvBXWsmN1GfpzCc9ktKDJvTauHuIUpWxwmBLsgMis++m5C Ba6RU42SUSSqvNgQInV27Hpf6StFB0/GJyvwCR0C7IBQj6mFE9YtEzGyK c=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=Julia.Lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.91,264,1647298800"; d="scan'208";a="38688098" Received: from 193.92-254-62.static.virginmediabusiness.co.uk (HELO [172.16.3.59]) ([62.254.92.193]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2022 08:26:55 +0200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Julia Lawall Mime-Version: 1.0 (1.0) Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers") Date: Tue, 31 May 2022 07:26:53 +0100 Message-Id: <91E67F46-A3C7-4159-9E0C-C6C6306F3669@inria.fr> References: Cc: Jani Nikula , Linus Torvalds , Sudip Mukherjee , Russell King , Viresh Kumar , Shiraz Hashim , =?utf-8?Q?Ville_Syrj=C3=A4l=C3=A4?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel , Linux Kernel Mailing List , Linux ARM , SoC Team In-Reply-To: To: Arnd Bergmann X-Mailer: iPhone Mail (17A860) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On 30 May 2022, at 15:27, Arnd Bergmann wrote: >=20 > =EF=BB=BFOn Mon, May 30, 2022 at 4:08 PM Jani Nikula wrote: >>> On Mon, 30 May 2022, Arnd Bergmann wrote: >>> struct my_driver_priv { >>> struct device dev; >>> u8 causes_misalignment; >>> spinlock_t lock; >>> atomic_t counter; >>> } __packed; /* this annotation is harmful because it breaks the atomics *= / >>=20 >> I wonder if this is something that could be caught with coccinelle. Or >> sparse. Are there any cases where this combo is necessary? (I can't >> think of any, but it's a low bar. ;) >>=20 >> Cc: Julia. >=20 > I think one would first have to make a list of data types that are not > meant to be in a packed structure. It could be a good start to > search for any packed aggregates with a pointer, atomic_t or spinlock_t > in them, but there are of course many more types that you won't > find in hardware structures. >=20 >>> or if the annotation does not change the layout like >>>=20 >>> struct my_dma_descriptor { >>> __le64 address; >>> __le64 length; >>> } __packed; /* does not change layout but makes access slow on some >>> architectures */ >>=20 >> Why is this the case, though? I'd imagine the compiler could figure this >> out. >=20 > When you annotate the entire structure as __packed without an > extra __aligned() annotation, the compiler has to assume that the > structure itself is unaligned as well. On many of the older architectures,= > this will result in accessing the values one byte at a time. Marking > the structure as "__packed __aligned(8)" instead would be harmless. >=20 > When I have a structure with a few misaligned members, I generally > prefer to only annotate the members that are not naturally aligned, > but this approach is not very common. Searching for specific types in a packed structure would be easy. Coccinelle could duplicate the structure without the packed and see if any o= ffsets change, using build bug on, but that would be architecture specific s= o maybe not useful. Julia > Arnd