Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2172513iof; Tue, 7 Jun 2022 22:08:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxA9E3xJMwHXCzTXJqpXo9N0HXaHPu3MXwkZruMdUs1+gU3PKXEPSRN6Hiv2kZpJ7m1+phQ X-Received: by 2002:a17:90a:cf0f:b0:1e2:e62b:fd3 with SMTP id h15-20020a17090acf0f00b001e2e62b0fd3mr36363883pju.107.1654664883291; Tue, 07 Jun 2022 22:08:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654664883; cv=none; d=google.com; s=arc-20160816; b=KmVTm/c8xy0RNa7dtv6SkTugkGNnyT9j7l6AljuU6ujCdgzO3CAVqrFG0+2F7mrBZa PjdgERX8x5f1b5OJqfRPr4dy3nyJZ/qxtDk+tUtdU2T3qrawS9pUxfJlx8d7RgayiWQK VrOVg6t62V+yd9aO7XL1aaWxQhNvn90SUOVFkhHJZqW8pmvMBIxOEJD6DsQKJIhBV0Tj dWFbQDhzs3wqKsm9tyd8QdWZhq1edyMgKLS9zACQRuXkn+JMlE7gQDGTy8Q1r5NGjE7r wieFVqjR/ZURqCKlnLG1LXS9VL4iNyvDPA8+q9hpoBDXveG5LbobNZm0+2MXVjvNxnzY x4hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Jlo7y58I5EfzFNj+YCE8kLCe2oJe1f55U5wieElYacc=; b=uBT4urIn7LP3YcECtVoTutE+pn6Ib6otxtuHPgCgASHq0I6MLwomhq7HV9LGsSwRa0 DSu79+B5AdHihkyfzvxBUK/Toi2oA4DC2yTq1t0/HekR+scC5FBkQ1tjqCtR5VE4Vrn5 G9ZNBAtbIFGn2ZwnyJiLKsjmdox4LNdq7jMay/B0VurqEOMourV14W01ft6zd2D2FRIB qMXmyrWBiNxeD1cfgKqZIJzDW+uyGJAcFUOOU1VLGsnOaMK1RUMIalCF8V89jlRd1Tsb AHLjyVes1gnhb2d3LgH2bSqyRm2xSCrd75ytVMWvjdOec4wg7aRVKNmetR5PAvmItcM5 OUuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DaGZvfZr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id mi14-20020a17090b4b4e00b001df53ffe159si14583210pjb.1.2022.06.07.22.08.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 22:08:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DaGZvfZr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6676C52526; Tue, 7 Jun 2022 21:35:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234561AbiFGRiA (ORCPT + 99 others); Tue, 7 Jun 2022 13:38:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347026AbiFGR35 (ORCPT ); Tue, 7 Jun 2022 13:29:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCCBC580E0; Tue, 7 Jun 2022 10:25:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 593ED60DD7; Tue, 7 Jun 2022 17:25:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E7E2C385A5; Tue, 7 Jun 2022 17:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654622724; bh=yWMSUE+b2ncX5czDCiPQY7bzf6YbCvDYDvxWq7W5yjY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DaGZvfZr4BfR/0bb4vKpwXqtt62gIXlmoPURnlnkAL3GLQeHLb7Ti3O5HugOjQ+4D BF5ZkbB0HGXaD76+JZ618NRs8jf64f4u6Ilu/B+FmdsH7yIszz4ARGcZT+6trzPHM+ nyrUnJEmKnsrXTkwHa+E51fCJCBaWv0C90QJq8L4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sudip Mukherjee , Arnd Bergmann , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Linus Torvalds , Sasha Levin Subject: [PATCH 5.10 120/452] drm: fix EDID struct for old ARM OABI format Date: Tue, 7 Jun 2022 18:59:37 +0200 Message-Id: <20220607164912.134730246@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164908.521895282@linuxfoundation.org> References: <20220607164908.521895282@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds [ Upstream commit 47f15561b69e226bfc034e94ff6dbec51a4662af ] When building the kernel for arm with the "-mabi=apcs-gnu" option, gcc will force alignment of all structures and unions to a word boundary (see also STRUCTURE_SIZE_BOUNDARY and the "-mstructure-size-boundary=XX" option if you're a gcc person), even when the members of said structures do not want or need said alignment. This completely messes up the structure alignment of 'struct edid' on those targets, because even though all the embedded structures are marked with "__attribute__((packed))", the unions that contain them are not. This was exposed by commit f1e4c916f97f ("drm/edid: add EDID block count and size helpers"), but the bug is pre-existing. That commit just made the structure layout problem cause a build failure due to the addition of the BUILD_BUG_ON(sizeof(*edid) != EDID_LENGTH); sanity check in drivers/gpu/drm/drm_edid.c:edid_block_data(). This legacy union alignment should probably not be used in the first place, but we can fix the layout by adding the packed attribute to the union entries even when each member is already packed and it shouldn't matter in a sane build environment. You can see this issue with a trivial test program: union { struct { char c[5]; }; struct { char d; unsigned e; } __attribute__((packed)); } a = { "1234" }; where building this with a normal "gcc -S" will result in the expected 5-byte size of said union: .type a, @object .size a, 5 but with an ARM compiler and the old ABI: arm-linux-gnu-gcc -mabi=apcs-gnu -mfloat-abi=soft -S t.c you get .type a, %object .size a, 8 instead, because even though each member of the union is packed, the union itself still gets aligned. This was reported by Sudip for the spear3xx_defconfig target. Link: https://lore.kernel.org/lkml/YpCUzStDnSgQLNFN@debian/ Reported-by: Sudip Mukherjee Acked-by: Arnd Bergmann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- include/drm/drm_edid.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index e97daf6ffbb1..4526b6a1e583 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -121,7 +121,7 @@ struct detailed_data_monitor_range { u8 supported_scalings; u8 preferred_refresh; } __attribute__((packed)) cvt; - } formula; + } __attribute__((packed)) formula; } __attribute__((packed)); struct detailed_data_wpindex { @@ -154,7 +154,7 @@ struct detailed_non_pixel { struct detailed_data_wpindex color; struct std_timing timings[6]; struct cvt_timing cvt[4]; - } data; + } __attribute__((packed)) data; } __attribute__((packed)); #define EDID_DETAIL_EST_TIMINGS 0xf7 @@ -172,7 +172,7 @@ struct detailed_timing { union { struct detailed_pixel_timing pixel_data; struct detailed_non_pixel other_data; - } data; + } __attribute__((packed)) data; } __attribute__((packed)); #define DRM_EDID_INPUT_SERRATION_VSYNC (1 << 0) -- 2.35.1