linux-kernel - Re: iio/accel/stk8312: Improve unlocking of a mutex in two functions

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]

Message-ID: <alpine.DEB.2.20.1710271254570.17368@vps.pmeerw.net>
Date:   Fri, 27 Oct 2017 13:15:58 +0200 (CEST)
From:   Peter Meerwald-Stadler <pmeerw@...erw.net>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
cc:     Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: iio/accel/stk8312: Improve unlocking of a mutex in two
 functions

Hello,

> Maybe …
> But I proposed an other source code layout for useful reasons.

I think there is a (hidden) cost of having pure cleanup patches:
they make backporting fixes harder (across the cleanup)

stylistic changes must have a clear benefit, readability is subjective, 
consistency per se doesn't buy anything

the discussion how code should be written in the first place is separate
from the discussion what is worth fixing up lateron (IMHO)

> > There is no firm rule about error handling in one place.
> 
> There are some design options available.
> 
> 
> > If it leads to more complex flow as here, don't do it.
> 
> I would appreciate to clarify such a view a bit more.
> How would you like to achieve a complete and efficient
> exception handling in shown places?

regards, p.

-- 

Peter Meerwald-Stadler
Mobile: +43 664 24 44 418