linux-kernel - RE: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for stimer0

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:   Wed, 14 Feb 2018 02:58:41 +0000
From:   "Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <stephen@...workplumber.org>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "apw@...onical.com" <apw@...onical.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "leann.ogasawara@...onical.com" <leann.ogasawara@...onical.com>,
        "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>
Subject: RE: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for
 stimer0

> -----Original Message-----
> From: Dan Carpenter <dan.carpenter@...cle.com>
> Sent: Monday, February 12, 2018 12:42 AM
> To: KY Srinivasan <kys@...rosoft.com>; Stephen Hemminger
> <stephen@...workplumber.org>
> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> olaf@...fle.de; apw@...onical.com; vkuznets@...hat.com; jasowang@...hat.com;
> leann.ogasawara@...onical.com; marcelo.cerri@...onical.com; Stephen Hemminger
> <sthemmin@...rosoft.com>; Michael Kelley (EOSG) <Michael.H.Kelley@...rosoft.com>
> Subject: Re: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for stimer0
> 
> On Sun, Feb 11, 2018 at 05:33:16PM -0700, kys@...hange.microsoft.com wrote:
> > @@ -116,9 +146,29 @@ static int hv_ce_set_oneshot(struct clock_event_device *evt)
> >  {
> >  	union hv_timer_config timer_cfg;
> >
> > +	timer_cfg.as_uint64 = 0;
> >  	timer_cfg.enable = 1;
> >  	timer_cfg.auto_enable = 1;
> > -	timer_cfg.sintx = VMBUS_MESSAGE_SINT;
> > +	if (direct_mode_enabled)
> > +		/*
> > +		 * When it expires, the timer will directly interrupt
> > +		 * on the specified hardware vector/IRQ.
> > +		 */
> > +		{
> > +		timer_cfg.direct_mode = 1;
> > +		timer_cfg.apic_vector = stimer0_vector;
> > +		hv_enable_stimer0_percpu_irq(stimer0_irq);
> > +		}
> > +	else
> > +		/*
> > +		 * When it expires, the timer will generate a VMbus message,
> > +		 * to be handled by the normal VMbus interrupt handler.
> > +		 */
> > +		{
> > +		timer_cfg.direct_mode = 0;
> > +		timer_cfg.sintx = VMBUS_MESSAGE_SINT;
> > +		}
> > +
> 
> This indenting isn't right.  We should probably zero out .apic_vector
> if .direct_mode is zero.  Or maybe it's fine.  I don't know if any
> static analysis tools will complain...

I'll fix the indenting.  Old habits ....

The " timer_cfg.as_uint64 = 0" statement already zero's out .apic_vector
along with all the other unused fields in the 64-bit value, as required by
the Hyper-V spec.

> 
> >  	hv_init_timer_config(HV_X64_MSR_STIMER0_CONFIG, timer_cfg.as_uint64);
> >
> >  	return 0;
> > @@ -191,6 +241,10 @@ int hv_synic_alloc(void)
> >  		INIT_LIST_HEAD(&hv_cpu->chan_list);
> >  	}
> >
> > +	if (direct_mode_enabled && hv_setup_stimer0_irq(
> > +		&stimer0_irq, &stimer0_vector, hv_stimer0_isr))
> > +		goto err;
> 
> 
> Can you indent it like this:
> 
> 	if (direct_mode_enabled &&
> 	    hv_setup_stimer0_irq(&stimer0_irq, &stimer0_vector,
> 				 hv_stimer0_isr))
> 		goto err;

OK -- will change.

> 
> 
> [ What follows is a long rant not directed at you ]
> 
> It's annoying because as soon as I see the "goto err;", I know the error
> handling for this function is going to be buggy...
> 
> Some rules of error handling are:
> 
> 1)  Each function should clean up after itself instead returning
>     partially allocated structures.
> 2)  Each allocation function should have a matching free function.
> 3)  Give meaningful label names based on what the label location so that
>     we can tell what the goto does just by looking at it, such as,
>     "goto free_some_variable".  This way we can just keep a mental tally
>     of the most recently allocated resource and verify based on the
>     "goto free_resource;" statemetn that it frees the correct thing.  We
>     don't need to scroll to the bottom of the function.
> 
>     Using good names means that we should avoid do-nothing gotos
>     because, by definition, the label name for a do-nothing goto is
>     going to be vague.
> 
> In this case the label looks like this:
> 
> > +
> >  	return 0;
> >  err:
> >  	return -ENOMEM;
> 
> We allocate a bunch of stuff in this function so at first glance this
> looks like we leak everything but, actually, the cleanup is done in
> vmbus_bus_init().  This is a layering violation.
> 
> Later on, we changed hv_synic_alloc() in 37cdd991fac8 ("vmbus: put
> related per-cpu variable together") and we started allocating:
> 
> 	hv_cpu->clk_evt = kzalloc(...
> 
> but we forgot to update the error handling because it was in the wrong
> place.  It's a very predictable, avoidable bug if we just use proper
> error handling style.

We'll fix this is a separate patch.  There are a couple other minor things
that should be cleaned up in hv.c as well, and can do them together.

Michael

> 
> Anyway...  Sorry for the long rant.  Summary:  Always distrust vague
> label names.
> 
> regards,
> dan carpenter