Return-Path: Received: from mail-io0-f181.google.com ([209.85.223.181]:36322 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751490AbeCETSw (ORCPT ); Mon, 5 Mar 2018 14:18:52 -0500 MIME-Version: 1.0 In-Reply-To: References: <6be06ce5-87e6-0d9d-55b9-6c70c3578ecf@maciej.szmigiero.name> From: Linus Torvalds Date: Mon, 5 Mar 2018 11:18:50 -0800 Message-ID: Subject: Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11) To: Masahiro Yamada Cc: "Maciej S. Szmigiero" , Kees Cook , Patrick McLean , Emese Revfy , Al Viro , Bruce Fields , "Darrick J. Wong" , Linux Kernel Mailing List , Linux NFS Mailing List , Thorsten Leemhuis , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada wrote: > > Can I suggest another way to make it less fragile? > __attribute((...)) can be placed after 'struct'. That avoids the actual bug, but it wouldn't have helped _find_ the problem in the first place. If somebody ever does the same thing, they'd hit the same issue. And it's not just __randomize_struct, it's any of our other type markers. We can say "don't do that", but if there is no automated checking, it's still ripe to cause problems just because somebody didn't notice. So I'd rather have something that causes a build failure when something goes wrong, rather than silently accepting syntax that wasn't intended. Linus