From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753702AbcHWP2m (ORCPT ); Tue, 23 Aug 2016 11:28:42 -0400 Received: from smtprelay0096.hostedemail.com ([216.40.44.96]:37518 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753500AbcHWP2X (ORCPT ); Tue, 23 Aug 2016 11:28:23 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1431:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2393:2559:2562:2691:2828:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3870:3874:4321:5007:6119:7576:7903:10004:10400:10848:11026:11232:11658:11914:12043:12296:12517:12519:12740:13069:13311:13357:13439:13894:14181:14659:14721:21080:21434:21451:30051:30054:30070:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: sheet76_6861fce56d73c X-Filterd-Recvd-Size: 2601 Message-ID: <1471964716.3746.103.camel@perches.com> Subject: Re: net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() From: Joe Perches To: Eric Dumazet , Luis Henriques Cc: Avijit Kanti Das , "David S . Miller" , Ben Hutchings , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 23 Aug 2016 08:05:16 -0700 In-Reply-To: <1471962096.14381.15.camel@edumazet-glaptop3.roam.corp.google.com> References: <1471959668-18209-1-git-send-email-luis.henriques@canonical.com> <1471959668-18209-2-git-send-email-luis.henriques@canonical.com> <1471962096.14381.15.camel@edumazet-glaptop3.roam.corp.google.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-08-23 at 07:21 -0700, Eric Dumazet wrote: > On Tue, 2016-08-23 at 14:41 +0100, Luis Henriques wrote: > > From: Avijit Kanti Das > > > > memset() the structure ethtool_wolinfo that has padded bytes > > but the padded bytes have not been zeroed out. [] > > diff --git a/net/core/ethtool.c b/net/core/ethtool.c [] > > @@ -1435,11 +1435,13 @@ static int ethtool_reset(struct net_device *dev, char __user *useraddr) > >   > >  static int ethtool_get_wol(struct net_device *dev, char __user *useraddr) > >  { > > - struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL }; > > + struct ethtool_wolinfo wol; > >   > >   if (!dev->ethtool_ops->get_wol) > >   return -EOPNOTSUPP; > >   > > + memset(&wol, 0, sizeof(struct ethtool_wolinfo)); > > + wol.cmd = ETHTOOL_GWOL; > >   dev->ethtool_ops->get_wol(dev, &wol); > >   > >   if (copy_to_user(useraddr, &wol, sizeof(wol))) > This would suggest a compiler bug to me. A compiler does not have a standards based requirement to initialize arbitrary padding bytes. I believe gcc always does zero all padding anyway. > I checked that my compiler does properly put zeros there, even in the > padding area. > > If we can not rely on such constructs, we have hundreds of similar > patches to submit. True. >>From a practical point of view, does any compiler used for kernel compilation (gcc/icc/llvm/any others?) not always perform zero padding of alignment bytes?