Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754505AbdCBQvj (ORCPT ); Thu, 2 Mar 2017 11:51:39 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:50692 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750779AbdCBQvV (ORCPT ); Thu, 2 Mar 2017 11:51:21 -0500 Subject: Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE To: Arnd Bergmann , kasan-dev@googlegroups.com References: <20170302163834.2273519-1-arnd@arndb.de> <20170302163834.2273519-3-arnd@arndb.de> Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-wireless@vger.kernel.org, kernel-build-reports@lists.linaro.org, "David S . Miller" , Paul McKenney From: Christian Borntraeger Date: Thu, 2 Mar 2017 17:51:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170302163834.2273519-3-arnd@arndb.de> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17030216-0044-0000-0000-000002B3B05C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006709; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000206; SDB=6.00829116; UDB=6.00406442; IPR=6.00606614; BA=6.00005186; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014499; XFM=3.00000012; UTC=2017-03-02 16:51:19 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17030216-0045-0000-0000-000006E1B1C4 Message-Id: <76790664-a7a9-193c-2e30-edaee1308cb0@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-02_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703020149 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2314 Lines: 46 On 03/02/2017 05:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause > rather large kernel stacks, e.g.: > > mm/vmscan.c: In function 'shrink_page_list': > mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > block/cfq-iosched.c: In function 'cfqg_stats_add_aux': > block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > fs/btrfs/disk-io.c: In function 'open_ctree': > fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > fs/btrfs/relocation.c: In function 'build_backref_tree': > fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > fs/fscache/stats.c: In function 'fscache_stats_show': > fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction': > fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > > This attempts a rewrite of the two macros, using a simpler implementation > for the most common case of having a naturally aligned 1, 2, 4, or (on > 64-bit architectures) 8 byte object that can be accessed with a single > instruction. For these, we go back to a volatile pointer dereference > that we had with the ACCESS_ONCE macro. We had changed that back then because gcc 4.6 and 4.7 had a bug that could removed the volatile statement on aggregate types like the following one union ipte_control { unsigned long val; struct { unsigned long k : 1; unsigned long kh : 31; unsigned long kg : 32; }; }; See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 If I see that right, your __ALIGNED_WORD(x) macro would say that for above structure sizeof(x) == sizeof(long)) is true, so it would fall back to the old volatile cast and might reintroduce the old compiler bug? Could you maybe you fence your simple macro for anything older than 4.9? After all there was no kasan support anyway on these older gcc version. Christian