netdev - Re: can: Use common error handling code in vxcan

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: <4d612668-5423-4ce3-a4f5-ee394d7ddd21@hartkopp.net>
Date:   Sat, 28 Oct 2017 21:04:46 +0200
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: can: Use common error handling code in vxcan_newlink()

On 10/28/2017 08:33 PM, SF Markus Elfring wrote:
>> So if you would like to change the if-statement:
> 
> It will need a small adjustment for the shown transformation.
> 
> I was also unsure if the proposal will work in a single update step.
> 
> 
>> 1. Send a patch for vxcan.c to improve the error handling flow
> 
> I am going to send a second approach for this update variant.

Ok.

> 
>> 2. Send a separate patch for all rtnl_configure_link() callers to unify the result check
>>
>> Step 2 is optional ... and prepare yourself for more feedback ;-)
> 
> I am curious on how software development aspects will evolve around
> desired error predicates.
> Which scope did you have in mind?

Oh, I don't have any scope in mind.

I just wanted to make clear that I don't want to have a different kind 
of result handling in vxcan.c and veth.c

So if you suggest to simplify the error flow that would be ok for me.

If you want to change the semantic of the result check - this has to 
done consistently at all rtnl_configure_link() caller sites. And not 
only in vxcan.c

That's what I have in mind.

Regards,
Oliver