Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752640AbdGEV4E (ORCPT ); Wed, 5 Jul 2017 17:56:04 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:35571 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752157AbdGEV4C (ORCPT ); Wed, 5 Jul 2017 17:56:02 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705050500.GA72383@beast> From: Linus Torvalds Date: Wed, 5 Jul 2017 14:56:01 -0700 X-Google-Sender-Auth: LrtrN_aVYR5FlobJwn_-hLM77lc Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Arnd Bergmann Cc: Ard Biesheuvel , Kees Cook , Linux Kernel Mailing List , Jean Delvare Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 718 Lines: 18 On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote: > > This particular example should be handled by > scripts/gcc-plugins/structleak_plugin.c, right? .. probably. But we have a ton of other uses that just pass in "result" pointers (not structs), which admittedly don't have the padding issue, but do have the exact same issue otherwise. We have those random "initialize to zero by hand", and I wouldn't actually worry about most of the common cases. KASAN will find them anyway. It tends to be the random odd ioctl-like things that nobody finds because it's only uninitialized for some silly error case that never triggers (or some unusual driver that needs to be loaded). Linus