linux-kernel - Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

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: <874lym7roy.fsf@kamboji.qca.qualcomm.com>
Date:   Tue, 21 Mar 2017 14:14:05 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Amitkumar Karwar <akarwar@...vell.com>,
        Nishant Sarmukadam <nishants@...vell.com>,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rajat Jain <rajatja@...gle.com>
Subject: Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

Brian Norris <briannorris@...omium.org> writes:

> On Mon, Mar 20, 2017 at 05:08:35PM +0000, Kalle Valo wrote:
>> Brian Norris <briannorris@...omium.org> wrote:
>> > This code was duplicated as part of the PCIe FLR code added to this
>> > driver. Let's de-duplicate it to:
>> > 
>> >  * make things easier to read (mwifiex_pcie_free_buffers() now has a
>> >    corresponding mwifiex_pcie_alloc_buffers())
>> >  * reduce likelihood of bugs
>> >  * make error logging equally verbose
>> >  * save lines of code!
>> > 
>> > Also drop some of the commentary that isn't really needed.
>> > 
>> > Signed-off-by: Brian Norris <briannorris@...omium.org>
>> 
>> Failed to apply:
>> 
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/pcie.c).
>> error: could not build fake ancestor
>> Applying: mwifiex: pcie: de-duplicate buffer allocation code
>> Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code
>> The copy of the patch that failed is found in: .git/rebase-apply/patch
>> 
>> Patch set to Changes Requested.
>
> This applies fine to your wireless-drivers/master branch for me, where
> patches 1-3 were applied. Are you applying this to
> wireless-drivers-next? It's quite understandable that patch 4 wouldn't
> apply there, as you've stripped out the previous patches...

I (wrongly) understood that patches 1-3 are for 4.11 and patch 4 is for
4.12, don't remember anymore how I got that impression. But I don't
think a cleanup patch like this is justified for 4.11 so I'm not
comfortable applying this to wireless-drivers (which should only contain
fixes to important bugs or regressions).

What I could do is to wait for the patches 1-3 trickle down to w-d-next
and then apply this patch. It usually takes few weeks, but with bad luck
it might happen only after the merge window. Would that work?

-- 
Kalle Valo