[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0958392-8325-4f56-cded-0ff6691893cf@users.sourceforge.net>
Date: Fri, 20 Jan 2017 08:08:55 +0100
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>,
linuxppc-dev@...ts.ozlabs.org
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Daniel Axtens <dja@...ens.net>,
Geliang Tang <geliangtang@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Nathan Fontenot <nfont@...ux.vnet.ibm.com>,
Pan Xinhui <xinhui.pan@...ux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Paul Mackerras <paulus@...ba.org>,
kernel-janitors@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: powerpc/nvram: Move an assignment for the variable "ret" in
dev_nvram_write()
> I think you really could have squashed patches 1-3 into a single patch
> that returns directly after any failure.
Thanks for your constructive feedback.
I have got software development concerns around such patch squashing.
> At this point you might as well remove that label and move the kfree(tmp) call up
> and return directly after the failure and at the nvram_write() call site
> doing away completely with the "ret" variable.
Your idea might look nice at first glance. But I would interpret the previous
implementation of the discussed function in the way that the memory which was
dynamically allocated here should always (not only in the failure case) be released
before returning here.
Would you really like to change the life time for this “temporary” data item?
Regards,
Markus
Powered by blists - more mailing lists