Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4100668imj; Tue, 12 Feb 2019 09:46:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IaYug1a889/senup9ZtjSQMOMx9uHZajrWeMjA3OpohZEMr1x4DfCo+mphrHoEXBie7+HwW X-Received: by 2002:a63:3dc8:: with SMTP id k191mr2874807pga.368.1549993613548; Tue, 12 Feb 2019 09:46:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549993613; cv=none; d=google.com; s=arc-20160816; b=iYQFiQdrRl5Z/BkGo+w3QfOS1wSJuO/qaiUR/RkA6O6KBm9CLYZKTOd1Roq3hAdZoU /gr1b8HCElwWFc2q64EIW6kbEtGk851vhFoziPTlx4tbgz1QzOH2a/lcWCNgKTVTb05y peFxmc/9VuK+TtSWOykeavnHHZCj9OrxsK5Nu8Bb62rIF299bWXNI98Z+O0m156TljAS /jJrXLEpeIA4nKWNTp30VAqr8Htc5fimxGoqWdIHhusMG2X1+EvyWh+Mho7Gt2dI1h50 i4eZXQZb3GX/hQiCNa/75DvL4s2BNHYfOq/COtV9oHMe3CwM4KJhqsOiBMZiu/8nCe6h q5mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:newsgroups:cc:to :subject:dkim-signature; bh=dnBntVpMMfwJCWSl/cuc5H4KMc8qYEP2N1a+i6hveQc=; b=ZYsYqXfogWzcxS0d/KNWShdP2OZcWow/jRe1qRaSNSII+3ou7hB7yszolntdZTp6aN Uqe4SdDJ2KEiXTqzfSclQswJi+vxUHCj63ap1UAfmTgAsMjc6nZ3KN0EqWepc9N9bekU JwcnY+nFUyOzvNooY8m14EU1G5UlNBRmh8VY7jDhHcK4Cz4Uj2OBq4xEwI8oGZNQ1Px+ x8VEq1eha/lyCDmCZkPPtUJ2sGGicnvyGeGym+CmY0qJ/QNDRqB37diDPhsrZKcREq6K 6U8inSeMFJ0teZWi+yek7lVntZLv09lInIJPB67IE/9TMcbq4GlmKoWf22iCyVChaLgy DyFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b="kYd6gU/0"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y129si5037718pgy.175.2019.02.12.09.46.37; Tue, 12 Feb 2019 09:46:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b="kYd6gU/0"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729649AbfBLRT1 (ORCPT + 99 others); Tue, 12 Feb 2019 12:19:27 -0500 Received: from smtprelay4.synopsys.com ([198.182.47.9]:33588 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729347AbfBLRT0 (ORCPT ); Tue, 12 Feb 2019 12:19:26 -0500 Received: from mailhost.synopsys.com (dc2-mailhost2.synopsys.com [10.12.135.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtprelay.synopsys.com (Postfix) with ESMTPS id 1791E24E138C; Tue, 12 Feb 2019 09:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1549991966; bh=XdfyAzVvy5MIDdZ2SbnUXNZW12NBCdwDNe8k3TzI3DE=; h=Subject:To:CC:References:From:Date:In-Reply-To:From; b=kYd6gU/03DpbJpsITqqiygVc3NQ9SMN9IXbVGh3s7jNWHr1qvqKsDKYVxIUZKBcwq X8cMfsB06qB2m0Gfc+KOHwLjsZ+icL5aReaBwzHakd7dVsafUcVZKvLYEWzc2oW3Fi ZSnSFC68OtEEahWtTxGEGeYz24MtAV9GWZZ4lrm7T/JbbDnX1yk4QwA6P0KwPnVMbR T2zIMtMLufl5cZXVOFOFVMQitMeJ28vbp5d3F2ensEyyl5ySQcdFET756sca4ASOse vJ2HPF8LMRZsKqcUqnfVeU0TCB2VWMG9ACzavT1oeRohdBtFIl9902VfYUaKGu6R2N XrIMcpFTobWqQ== Received: from US01WEHTC2.internal.synopsys.com (us01wehtc2.internal.synopsys.com [10.12.239.237]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by mailhost.synopsys.com (Postfix) with ESMTPS id 08776A0090; Tue, 12 Feb 2019 17:19:25 +0000 (UTC) Received: from IN01WEHTCA.internal.synopsys.com (10.144.199.104) by US01WEHTC2.internal.synopsys.com (10.12.239.237) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 09:17:24 -0800 Received: from IN01WEHTCB.internal.synopsys.com (10.144.199.105) by IN01WEHTCA.internal.synopsys.com (10.144.199.103) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 22:47:29 +0530 Received: from [10.10.161.59] (10.10.161.59) by IN01WEHTCB.internal.synopsys.com (10.144.199.243) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 22:47:28 +0530 Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8 To: Alexey Brodkin , CC: , Vineet Gupta , Newsgroups: gmane.linux.kernel.stable,gmane.linux.kernel.arc,gmane.linux.kernel References: <20190208105519.26750-1-abrodkin@synopsys.com> From: Vineet Gupta Openpgp: preference=signencrypt Autocrypt: addr=vgupta@synopsys.com; keydata= mQINBFEffBMBEADIXSn0fEQcM8GPYFZyvBrY8456hGplRnLLFimPi/BBGFA24IR+B/Vh/EFk B5LAyKuPEEbR3WSVB1x7TovwEErPWKmhHFbyugdCKDv7qWVj7pOB+vqycTG3i16eixB69row lDkZ2RQyy1i/wOtHt8Kr69V9aMOIVIlBNjx5vNOjxfOLux3C0SRl1veA8sdkoSACY3McOqJ8 zR8q1mZDRHCfz+aNxgmVIVFN2JY29zBNOeCzNL1b6ndjU73whH/1hd9YMx2Sp149T8MBpkuQ cFYUPYm8Mn0dQ5PHAide+D3iKCHMupX0ux1Y6g7Ym9jhVtxq3OdUI5I5vsED7NgV9c8++baM 7j7ext5v0l8UeulHfj4LglTaJIvwbUrCGgtyS9haKlUHbmey/af1j0sTrGxZs1ky1cTX7yeF nSYs12GRiVZkh/Pf3nRLkjV+kH++ZtR1GZLqwamiYZhAHjo1Vzyl50JT9EuX07/XTyq/Bx6E dcJWr79ZphJ+mR2HrMdvZo3VSpXEgjROpYlD4GKUApFxW6RrZkvMzuR2bqi48FThXKhFXJBd JiTfiO8tpXaHg/yh/V9vNQqdu7KmZIuZ0EdeZHoXe+8lxoNyQPcPSj7LcmE6gONJR8ZqAzyk F5voeRIy005ZmJJ3VOH3Gw6Gz49LVy7Kz72yo1IPHZJNpSV5xwARAQABtCpWaW5lZXQgR3Vw dGEgKGFsaWFzKSA8dmd1cHRhQHN5bm9wc3lzLmNvbT6JAj4EEwECACgCGwMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheABQJbBYpwBQkLx0HcAAoJEGnX8d3iisJeChAQAMR2UVbJyydOv3aV jmqP47gVFq4Qml1weP5z6czl1I8n37bIhdW0/lV2Zll+yU1YGpMgdDTHiDqnGWi4pJeu4+c5 xsI/VqkH6WWXpfruhDsbJ3IJQ46//jb79ogjm6VVeGlOOYxx/G/RUUXZ12+CMPQo7Bv+Jb+t NJnYXYMND2Dlr2TiRahFeeQo8uFbeEdJGDsSIbkOV0jzrYUAPeBwdN8N0eOB19KUgPqPAC4W HCg2LJ/o6/BImN7bhEFDFu7gTT0nqFVZNXlOw4UcGGpM3dq/qu8ZgRE0turY9SsjKsJYKvg4 djAaOh7H9NJK72JOjUhXY/sMBwW5vnNwFyXCB5t4ZcNxStoxrMtyf35synJVinFy6wCzH3eJ XYNfFsv4gjF3l9VYmGEJeI8JG/ljYQVjsQxcrU1lf8lfARuNkleUL8Y3rtxn6eZVtAlJE8q2 hBgu/RUj79BKnWEPFmxfKsaj8of+5wubTkP0I5tXh0akKZlVwQ3lbDdHxznejcVCwyjXBSny d0+qKIXX1eMh0/5sDYM06/B34rQyq9HZVVPRHdvsfwCU0s3G+5Fai02mK68okr8TECOzqZtG cuQmkAeegdY70Bpzfbwxo45WWQq8dSRURA7KDeY5LutMphQPIP2syqgIaiEatHgwetyVCOt6 tf3ClCidHNaGky9KcNSQuQINBFEffBMBEADXZ2pWw4Regpfw+V+Vr6tvZFRl245PV9rWFU72 xNuvZKq/WE3xMu+ZE7l2JKpSjrEoeOHejtT0cILeQ/Yhf2t2xAlrBLlGOMmMYKK/K0Dc2zf0 MiPRbW/NCivMbGRZdhAAMx1bpVhInKjU/6/4mT7gcE57Ep0tl3HBfpxCK8RRlZc3v8BHOaEf cWSQD7QNTZK/kYJo+Oyux+fzyM5TTuKAaVE63NHCgWtFglH2vt2IyJ1XoPkAMueLXay6enSK Nci7qAG2UwicyVDCK9AtEub+ps8NakkeqdSkDRp5tQldJbfDaMXuWxJuPjfSojHIAbFqP6Qa ANXvTCSuBgkmGZ58skeNopasrJA4z7OsKRUBvAnharU82HGemtIa4Z83zotOGNdaBBOHNN2M HyfGLm+kEoccQheH+my8GtbH1a8eRBtxlk4c02ONkq1Vg1EbIzvgi4a56SrENFx4+4sZcm8o ItShAoKGIE/UCkj/jPlWqOcM/QIqJ2bR8hjBny83ONRf2O9nJuEYw9vZAPFViPwWG8tZ7J+R euXKai4DDr+8oFOi/40mIDe/Bat3ftyd+94Z1RxDCngd3Q85bw13t2ttNLw5eHufLIpoEyAh TCLNQ58eT91YGVGvFs39IuH0b8ovVvdkKGInCT59Vr0MtfgcsqpDxWQXJXYZYTFHd3/RswAR AQABiQIlBBgBAgAPAhsMBQJbBYpwBQkLx0HdAAoJEGnX8d3iisJewe8P/36pkZrVTfO+U+Gl 1OQh4m6weozuI8Y98/DHLMxEujKAmRzy+zMHYlIl3WgSih1UMOZ7U84yVZQwXQkLItcwXoih ChKD5D2BKnZYEOLM+7f9DuJuWhXpee80aNPzEaubBYQ7dYt8rcmB7SdRz/yZq3lALOrF/zb6 SRleBh0DiBLP/jKUV74UAYV3OYEDHN9blvhWUEFFE0Z+j96M4/kuRdxvbDmp04Nfx79AmJEn fv1Vvc9CFiWVbBrNPKomIN+JV7a7m2lhbfhlLpUk0zGFDTWcWejl4qz/pCYSoIUU4r/VBsCV ZrOun4vd4cSi/yYJRY4kaAJGCL5k7qhflL2tgldUs+wERH8ZCzimWVDBzHTBojz0Ff3w2+gY 6FUbAJBrBZANkymPpdAB/lTsl8D2ZRWyy90f4VVc8LB/QIWY/GiS2towRXQBjHOfkUB1JiEX YH/i93k71mCaKfzKGXTVxObU2I441w7r4vtNlu0sADRHCMUqHmkpkjV1YbnYPvBPFrDBS1V9 OfD9SutXeDjJYe3N+WaLRp3T3x7fYVnkfjQIjDSOdyPWlTzqQv0I3YlUk7KjFrh1rxtrpoYS IQKf5HuMowUNtjyiK2VhA5V2XDqd+ZUT3RqfAPf3Y5HjkhKJRqoIDggUKMUKmXaxCkPGi91T hhqBJlyU6MVUa6vZNv8E Message-ID: <81017fe4-b31f-4942-e822-a7b70008b74d@synopsys.com> Date: Tue, 12 Feb 2019 09:17:17 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190208105519.26750-1-abrodkin@synopsys.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.161.59] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/8/19 2:55 AM, Alexey Brodkin wrote: > By default ARCH_SLAB_MINALIGN is defined in "include/linux/slab.h" as > "__alignof__(unsigned long long)" which looks fine but not for ARC. Just for the record, the issue happens because a LLOCKD (exclusive 64-bit load) was trying to use a 32-bit aligned effective address (for atomic64_t), not allowed by ISA (LLOCKD can only take 64-bit aligned address, even when the CPU has unaligned access enabled). This in turn was happening because this word is embedded in some other struct and happens to be 4 byte aligned > ARC tools ABI sets align of "long long" the same as for "long" = 4 > instead of 8 one may think of. Right, this was indeed unexpected and not like most other arches. ARCv2 ISA allows regular 64-bit loads/stores (LDD/STD) to take 32-bit aligned addresses. Thus ABI relaxing the alignment for 64-bit data potentially causes more packing and less space waste. But on the flip side we need to waste space at arbitrary places liek this. So this is all good and theory, but I'm not 100% sure how slab alignment helps here (and is future proof). So the outer struct with embedded atomic64_t was allocated via slab and your patch ensures that outer struct is 64-bit aligned ? But how does that guarantee that all embedded atomic64_t in there will be 64-bit aligned (in future say) in the light of ARC ABI and the gcc bug/feature which Peter alluded to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360 > Thus slab allocator may easily allocate a buffer which is 32-bit aligned. > And most of the time it's OK until we start dealing with 64-bit atomics > with special LLOCKD/SCONDD instructions which (as opposed to their 32-bit > counterparts LLOCK/SCOND) operate with full 64-bit words but those words > must be 64-bit aligned. Some of this text needed to go above to give more context. > > Fixes Ext4 folder removal: > --------------------->8------------------- > [ 4.015732] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) > [ 4.167881] .. > > Signed-off-by: Alexey Brodkin > Cc: # 4.8+ > --- > arch/arc/include/asm/cache.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h > index f393b663413e..74f8fcaaef5c 100644 > --- a/arch/arc/include/asm/cache.h > +++ b/arch/arc/include/asm/cache.h > @@ -52,6 +52,16 @@ > #define cache_line_size() SMP_CACHE_BYTES > #define ARCH_DMA_MINALIGN SMP_CACHE_BYTES > > +/* > + * Make sure slab-allocated buffers are 64-bit aligned. > + * This is required for llockd/scondd to deal with 64-bit aligned dwords. > + * By default ARCH_SLAB_MINALIGN is __alignof__(long long) which in > + * case of ARC is 4 instead of 8! > + */ > +#ifdef CONFIG_ARC_HAS_LL64 > +#define ARCH_SLAB_MINALIGN 8 > +#endif > + > extern void arc_cache_init(void); > extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len); > extern void read_decode_cache_bcr(void); >