From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933638AbcLSRMz (ORCPT ); Mon, 19 Dec 2016 12:12:55 -0500 Received: from casper.infradead.org ([85.118.1.10]:51368 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763917AbcLSRMw (ORCPT ); Mon, 19 Dec 2016 12:12:52 -0500 Date: Mon, 19 Dec 2016 17:12:48 +0000 (GMT) From: James Simmons To: Bruce Korb cc: Kees Cook , Linux Kernel Mailing List , Oleg Drokin , Andreas Dilger , Greg Kroah-Hartman , "John L. Hammond" , Emoly Liu , Vitaly Fertman , Bruno Faccini , Lustre Development List , devel@driverdev.osuosl.org Subject: Re: [PATCH] staging: lustre: ldlm: use designated initializers In-Reply-To: Message-ID: References: <20161217010045.GA140343@beast> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. Maybe a worthwhile change would be to: > > static const struct ldlm_callback_suite null_cbs; I perfer this as well. > then it is not even necessary to specify an initializer.