From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932270AbdJYGhu (ORCPT ); Wed, 25 Oct 2017 02:37:50 -0400 Received: from mout.web.de ([212.227.15.3]:64534 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751421AbdJYGhs (ORCPT ); Wed, 25 Oct 2017 02:37:48 -0400 Subject: Re: Clarification for approaches around exception handling To: Dan Carpenter , dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org Cc: David Airlie , Laurent Pinchart , LKML , kernel-janitors@vger.kernel.org References: <7d5e68c7-2d64-0131-1a08-eeb4e03cc113@users.sourceforge.net> <9fafa688-f699-c587-ef77-840efa71bf76@users.sourceforge.net> <20171025060104.vlk546frvmjici37@mwanda> From: SF Markus Elfring Message-ID: <1c595ff5-9534-2b3f-38d4-970418ed8b25@users.sourceforge.net> Date: Wed, 25 Oct 2017 08:35:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171025060104.vlk546frvmjici37@mwanda> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:I+1OLzl6N29Flr11gquH1yOCAMqOFwWOfyOxYeykZU31XG3S6x1 AIANKuQxkaKtARfdtV0cMbpJdw6d09iLziHeM5ZSBMTHJvfSzo8TNJ5Kl82CaO/qgDfl3tS pVY24YJ202+9wUwLFo1Y2+RPz8QOKnRYy4b6T0wfOu6V6GNJdE+pqkK2ayUTUkFN/2k64zt FWhZI6FkDoqRMI2t5BsYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:QSV1Qb6N6BU=:pc8NOPNGLOyKwDs3tZ9Jhb gN9DIU7bAM1ea/9AT9qT7WEVSo6U4Z+1ofQmy361NK8VVfGLAYlf101fv3pF9SK7BvXLaCOgX f3I8HtgC0r+8o0tKEJKfFht5GBp3rKlaFFTY84gpjNG6vCN3zRpUCffc3FooDXh5URrwLyCV1 azJaHiLFbcanJhbT0eoNM48bmzXcPlsC1Cqdx7Kv8gp4mZN9OR6FUncifMk6bz44XPuX9efsy 6/nBWH8+atJb6RFiiFka8JZP4aMkZN6vG/srF8hNOA4tkKsPGfEx0rsM/NOobQhq+9tT5ZJLe P1aRqMs6JO4Nt0FDs2cSd5f2ZalVxL+vZBN1vMf2Jp5bLhRPsnrnuJ99+9fEqfXUnH97KQvWY AcLuEs00LZXyvxfbM46vwHUkc8w90u5vFUlIgrpb8gvsWx9A9MskWWfSOOdSAJ6SczjOnqkFu /bIKuq5CraYIzzjBqVVZ2Uynrt7fn5tWEzSQJujAIC6ZV7DGRd7PQEk/WwlxH8Vls+jSzL6n1 XKxNWx62Pz13+w/yHOfKdNRjfdL/UdxdUSjZUZm2q0QyCU7aE3GUkT7JRn9nYI/SF8tVGZKVW VYrerJ/hI4DQNNpXGI8xUiddl42RUmZh5awcd9YC60PtG4BmmLh+LhqSLcs3QAsoJcJDup9wQ S45RPx/Z72bjUVzAqo9dtM9KWRrjzed0sD0vBIkaqLTDStww7DHRv4V57k3JBI1n1oHq/J2Ji OjANA5hOYfIRBtNEorTY2UNRRsP1d1BsGVh03snADBce6te0uaWyhG04Uf+88+Afarl0CtHyb OX9x2LJE4E73KLrSQKrji0XjHFYKiUaLwS7ZmYs3cGDAw3s230= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > But anyways I guess other people sometimes disagree with me. Am I one of them? ;-) > Unwinding is for when you allocate five things in a row. This is a general issue. I find that it is also needed in this function as usual. > You have to undo four if the last allocation fails. Concrete numbers might help to clarify another example. > But say you have to take a lock part way through and drop it before > the end of the function. The lock/unlock is not part of the list > of five resources that you want the function to take so it doesn't > belong in the unwind code. Such a view is useful to some degree. > If you add the lock/unlock to the unwind code, then it makes things a > bit tricky because then you have to do funny things like: > > free_four: > free(four); > goto free_three: <-- little bunny hop > unlock: <-- less useful label > unlock(); > free_three: > free_three(); > free_two: > free(two); > free_one: > free(one); > > return ret; > > It's better to just do the unlocking before the goto. I would prefer to store such an action also only so often in the code as it is really required. > That way the lock and unlock are close together. It might look nice occasionally. > if (!four) { > unlock(); > ret = -EFAIL; > goto free_three; > } > > Of course, having a big unlock label makes sense if you take a lock at > the start of the function and need to drop it at the end. But in this > case we are taking a lock then dropping it, and taking the next, then > dropping it and so on. It's a different situation. Lock scopes can interfere with a preferred control flow, can't they? I have got the impression that your detailed reply could have been more appropriate for update suggestions around other software modules. Regards, Markus