From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756932AbcLTHLa (ORCPT ); Tue, 20 Dec 2016 02:11:30 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:20992 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751559AbcLTHL1 (ORCPT ); Tue, 20 Dec 2016 02:11:27 -0500 Date: Tue, 20 Dec 2016 10:10:34 +0300 From: Dan Carpenter To: Bruce Korb Cc: James Simmons , devel@driverdev.osuosl.org, Andreas Dilger , Kees Cook , Greg Kroah-Hartman , Linux Kernel Mailing List , Bruno Faccini , Oleg Drokin , Vitaly Fertman , "John L. Hammond" , Emoly Liu , Lustre Development List Subject: Re: [PATCH] staging: lustre: ldlm: use designated initializers Message-ID: <20161220071034.GL8176@mwanda> References: <20161217010045.GA140343@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags, > >> int added = (mode == LCK_NL); > >> int overlaps = 0; > >> int splitted = 0; > >> - const struct ldlm_callback_suite null_cbs = { NULL }; > >> + const struct ldlm_callback_suite null_cbs = { }; > >> > >> CDEBUG(D_DLMTRACE, > >> "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n", > > > > Nak. Filling null_cbs with random data is a bad idea. If you look at > > ldlm_lock_create() where this is used you have > > > > if (cbs) { > > lock->l_blocking_ast = cbs->lcs_blocking; > > lock->l_completion_ast = cbs->lcs_completion; > > lock->l_glimpse_ast = cbs->lcs_glimpse; > > } > > > > Having lock->l_* point to random addresses is a bad idea. > > What really needs to be done is proper initialization of that > > structure. A bunch of patches will be coming to address this. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. They are equivalent, yes, but people want to use a GCC plugin that randomizes struct layouts for internal structures and the plugin doesn't work when you use struct ordering to initialize the struct. The plugin requires that you use designated intializers. regards, dan carpenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Carpenter Date: Tue, 20 Dec 2016 10:10:34 +0300 Subject: [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers In-Reply-To: References: <20161217010045.GA140343@beast> Message-ID: <20161220071034.GL8176@mwanda> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bruce Korb Cc: James Simmons , devel@driverdev.osuosl.org, Andreas Dilger , Kees Cook , Greg Kroah-Hartman , Linux Kernel Mailing List , Bruno Faccini , Oleg Drokin , Vitaly Fertman , "John L. Hammond" , Emoly Liu , Lustre Development List On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags, > >> int added = (mode == LCK_NL); > >> int overlaps = 0; > >> int splitted = 0; > >> - const struct ldlm_callback_suite null_cbs = { NULL }; > >> + const struct ldlm_callback_suite null_cbs = { }; > >> > >> CDEBUG(D_DLMTRACE, > >> "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n", > > > > Nak. Filling null_cbs with random data is a bad idea. If you look at > > ldlm_lock_create() where this is used you have > > > > if (cbs) { > > lock->l_blocking_ast = cbs->lcs_blocking; > > lock->l_completion_ast = cbs->lcs_completion; > > lock->l_glimpse_ast = cbs->lcs_glimpse; > > } > > > > Having lock->l_* point to random addresses is a bad idea. > > What really needs to be done is proper initialization of that > > structure. A bunch of patches will be coming to address this. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. They are equivalent, yes, but people want to use a GCC plugin that randomizes struct layouts for internal structures and the plugin doesn't work when you use struct ordering to initialize the struct. The plugin requires that you use designated intializers. regards, dan carpenter