linux-kernel - Re: [PATCH] staging: lustre: ldlm: use designated initializers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Dec 2016 10:10:34 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Bruce Korb <bruce.korb@...il.com>
Cc:     James Simmons <jsimmons@...radead.org>, devel@...verdev.osuosl.org,
        Andreas Dilger <andreas.dilger@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bruno Faccini <bruno.faccini@...el.com>,
        Oleg Drokin <oleg.drokin@...el.com>,
        Vitaly Fertman <vitaly_fertman@...atex.com>,
        "John L. Hammond" <john.hammond@...el.com>,
        Emoly Liu <emoly.liu@...el.com>,
        Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH] staging: lustre: ldlm: use designated initializers

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