> -----Original Message-----
> From: Dan Carpenter <dan.carpen...@oracle.com>
> Sent: Monday, February 12, 2018 12:42 AM
> To: KY Srinivasan <k...@microsoft.com>; Stephen Hemminger
> <step...@networkplumber.org>
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com; marcelo.ce...@canonical.com; Stephen Hemminger
> <sthem...@microsoft.com>; Michael Kelley (EOSG)
> <michael.h.kel...@microsoft.com>
> Subject: Re: [PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for
> stimer0
>
> On Sun, Feb 11, 2018 at 05:33:16PM -0700, k...@exchange.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
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
