From patchwork Mon Jul 9 13:45:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Brodkin X-Patchwork-Id: 941291 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=synopsys.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OabajbPv"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=synopsys.com header.i=@synopsys.com header.b="OGNWP7j0"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41PRSS6Cvbz9s1b for ; Mon, 9 Jul 2018 23:46:16 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=JoJsUogdSv4RnBcqipAPTwVl0adccgse2vRDTagnV3A=; b=Oab ajbPvgVYe2yERgfbOdBDWE+uwYqMPKbU9CIpQzotLbw+7fhHX3dzzQJ6kBp8aN7mfDOVQl7pVkKua QKrD+3Au62KTMmKsHJtCY4xYgAaNxNCznTMwoWaGu8ljfYJL1YPR3vCQzoXsuVzr8ND//x02q1ZUC OvI1C91FYb+NlG3pYmt3sf0lWi7BGxXeP6HN8WOLVJMtIp4G3qnf5+wT5JaBcSZ+YItLjiQAGlIEi 1589TawAcMaY7sWSTm37npPkvrgNVtE2/8ul30mqJ26hlO3vkpBcm7UhzOmKqLMexGUmvVg1N6sN9 afo14cJcxiQvGBiVHUC40YRDjT5PlPg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fcWUY-0008OO-SI; Mon, 09 Jul 2018 13:46:14 +0000 Received: from smtprelay2.synopsys.com ([198.182.60.111] helo=smtprelay.synopsys.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fcWUW-0008N8-BT for linux-snps-arc@lists.infradead.org; Mon, 09 Jul 2018 13:46:13 +0000 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id 1CB0410C1AEC; Mon, 9 Jul 2018 06:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1531143961; bh=3aWVddgH12qJ2jufho7qehBlYzGcE/wYwvNkcazYKjY=; h=From:To:Cc:Subject:Date:From; b=OGNWP7j0Nw8OowbXlaQ/TFAdyPEL5EgSZdGhiMOLUnbLsDfJY4OGqEOU7ow6b7LWO K5LKOaFqUfI4tIBMUdLsr58AU9ibGX/uE1gLbxDz7+K00AF5hrsM5n5r9DtHzrzLm/ FFOB7q8QaQ1dV6UA+0pwDECBNZZfnjpg+kxu7ltEeGWz7y6s6ER0ewZe17Mz4VEdDH CtJXd85vBw1JncdFwIHI46BNvjLu0ifj9DZ+KW59K/A0dLgOdNtzncfUDdHeoTVQGL bf0a33nY4/pSc+iWYnzPbP8t5RPyYoGio+EczEwTuycDkYI3nFUtltFctHe1iG7waT E73YZ363BTLig== Received: from abrodkin-7480l.internal.synopsys.com (unknown [10.121.8.87]) by mailhost.synopsys.com (Postfix) with ESMTP id 382273717; Mon, 9 Jul 2018 06:45:58 -0700 (PDT) From: Alexey Brodkin To: linux-kernel@vger.kernel.org Subject: [PATCH v3] devres: Explicitly align datai[] to 64-bit Date: Mon, 9 Jul 2018 16:45:50 +0300 Message-Id: <20180709134550.29541-1-abrodkin@synopsys.com> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180709_064612_401859_4A38247C X-CRM114-Status: GOOD ( 11.68 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.182.60.111 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Peter Zijlstra , Greg Kroah-Hartman , Alexey Brodkin , Will Deacon , stable@vger.kernel.org, David Laight , Geert Uytterhoeven , Greg KH , Thomas Gleixner , linux-snps-arc@lists.infradead.org MIME-Version: 1.0 Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org data[] must be 64-bit aligned even on 32-bit architectures because it might be accessed by instructions that require aligned memory arguments. One example is "atomic64_t" type accessed by special atomic instructions which may read/write entire 64-bit word. Atomic instructions are a bit special compared to normal loads and stores. Even if normal loads and stores may deal with unaligned data, atomic instructions still require data to be aligned because it's hard to manage atomic value that spans through multiple cache lines or even MMU pages. And hardware just raises an alignment fault exception. The problem with previously used approach is that depending on ABI "long long" type of a particular 32-bit CPU might be aligned to 8-, 16-, 32- or 64-bit boundary. Which will get in the way of mentioned above atomic instructions. Consider the following snippet: | struct mystruct { | atomic64_t myvar; | } | | struct mystruct *p; | p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL); Here address of "myvar" will match data[] in "struct devres", that said if "data" is not 64-bit aligned atomic instruction will fail on the first access to "myvar". Signed-off-by: Alexey Brodkin Cc: Greg Kroah-Hartman Cc: Geert Uytterhoeven Cc: David Laight Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: Greg KH Cc: # 4.8+ --- Changes v2 -> v3: * Align explicitly to 8 bytes [David] * Rephrased in-line comment [David] * Added more techinical details to commit message [Greg] * Mention more alignment options in commit message [Geert] Changes v1 -> v2: * Reworded commit message * Inserted comment right in source [Thomas] drivers/base/devres.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/base/devres.c b/drivers/base/devres.c index f98a097e73f2..d65327cb83c9 100644 --- a/drivers/base/devres.c +++ b/drivers/base/devres.c @@ -24,8 +24,12 @@ struct devres_node { struct devres { struct devres_node node; - /* -- 3 pointers */ - unsigned long long data[]; /* guarantee ull alignment */ + /* + * data[] must be 64 bit aligned even on 32 bit architectures + * because it might be accessed by instructions that require + * aligned memory arguments such as atomic64_t. + */ + u8 __aligned(8) data[]; }; struct devres_group {