linux-kernel - Re: [PATCH v3 4/6] staging: r8188eu: add error handling of rtw

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: <a38b05bc-abeb-7d30-736f-1bd68c2517c3@gmail.com>
Date:   Wed, 25 Aug 2021 13:41:51 +0300
From:   Pavel Skripkin <paskripkin@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>,
        Larry.Finger@...inger.net, phil@...lpotter.co.uk,
        gregkh@...uxfoundation.org, straube.linux@...il.com,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/6] staging: r8188eu: add error handling of rtw_read16

On 8/25/21 1:38 PM, Dan Carpenter wrote:
> On Wed, Aug 25, 2021 at 01:13:54PM +0300, Pavel Skripkin wrote:
>> On 8/25/21 1:06 PM, Dan Carpenter wrote:
>> > On Wed, Aug 25, 2021 at 12:55:37PM +0300, Pavel Skripkin wrote:
>> > > The main problem, that no one knows who is the "old". Greg can take patches
>> > > in any order he wants
>> > 
>> > Patches are always taken in first come first serve.
>> > 
>> 
>> 
>> Ok, but if pending patch needs new version, then it will be taken at the
>> end?
> 
> Versions don't matter.  No one is tracking any of that.
> 
> A patch arrives.  It is either applied or rejected.  First come first
> serve.
> 

Ok, big thanks for explanation

>> 
>> Here is the situation we have:
>> 
>> 	I have the patch series based on old function behavior, it was
>> 	posted first
>> 
>> 	Then Fabio posted refactoring of the function and it changes
>> 	return values.
>> 
>> 
>> Both series are pending right now and made on top of staging-next branch.
>> Who needs to rebase? I think, applying these series as-is can broke the
>> driver, since error handling will be broken
> 
> That's a bug then.  The patch should be rejected.  You're not allowed to
> break the code.
> 
> Also don't write patches which lead to merge order breaking the code
> silently.  That makes it difficult for stable as well.  For example,
> don't do this:
> 
> -void frob(int a, int b);
> +void frob(int b, int a);
> 
> In that case, you would change the name of the function so that the
> build would break when people mix old and new code.
> 

Understandable, thank you :)





With regards,
Pavel Skripkin