On Mon, 22 Aug 2016 23:17:26 +0200 SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx> wrote: > >>>> @@ -273,10 +273,12 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu, > >>>> vcpu->arch.guestdbg.nr_hw_wp = nr_wp; > >>>> vcpu->arch.guestdbg.hw_wp_info = wp_info; > >>>> return 0; > >>>> -error: > >>>> - kfree(bp_data); > >>>> - kfree(wp_info); > >>>> +free_bp_info: > >>>> kfree(bp_info); > >>>> +free_wp_info: > >>>> + kfree(wp_info); > >>>> +free_bp_data: > >>>> + kfree(bp_data); > >>>> return ret; > >>>> } > >>>> > >>> > >>> This replaces a perfectly fine fallthrough > >> > >> The usage of a single goto label like "error" seems to be convenient. > >> But how do these habits fit to the current Linux coding style convention? > >> > >> > >>> with some horrible labels. > >> > >> Do they explain better which processing steps should be performed > >> for an efficient exception handling in this function implementation? > > > > *sigh* > > > > It's _exception handling_. It does not need to be "efficient", > > I imagine that run time situations could evolve where software efficiency > will also matter for this purpose. *major sigh* We can start to optimize error handling that should never run after we fixed every other performance problem that we have. Not earlier. > > > > it needs to be easily parsable by humans. > > I guess that we have got different preferences for this detail. And I'm maintainer for this code. > > > > If in doubt, the compiler will be _much_ better at optimizing > > that kind of stuff anyway. > > Which compiler (or optimizer) implementation is capable to restructure > the jump targets for you automatically in the way I propose here? No, please stop right here. NACK. EOD. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
