[PATCH] bcm2835-v4l2: Fix buffer overflow problem

[Dave Stevenson]

On 16 March 2017 at 05:11, Eric Anholt <eric at anholt.net> wrote:
> Greg KH <gregkh at linuxfoundation.org> writes:
>
>> On Wed, Mar 15, 2017 at 03:32:56PM +0000, Dave Stevenson wrote:
>>> You've got a reason. It's GPLv2 licenced code so I have no control
>>> over what happens to it.
>>> Everywhere I have worked, when a patch has issues it is better to "-1"
>>> to stop/delay the merge even (or particularly) on your own patches,
>>> but this is your playground so your rules.
>>
>> It's fine to say "don't apply, for _THIS REASON_".  You didn't specify a
>> reason, which is why I complained.
>>
>>> Anyway, I'll go back to working with the downstream tree (pull request
>>> for the full fix there) and stop bothering you.
>>
>> Ah, fun, we will diverge even more in the future, not good.  Any reason
>> why I shouldn't just delete this whole in-kernel tree if you are going
>> to spend time maintaining a different version?
>>
>> If you want to maintain this driver, in the kernel tree, by all means I
>> would love the help as I don't have hardware or the ability to test
>> anything.  Having two different trees for the source guarantees that
>> there are going to be constant problems here, and that's not good for
>> anyone.
>
> If Dave doesn't do the upstreaming work for his future work, I'll be
> forced to.  The rpi tree still hasn't diverged, yet (other than this
> patch and the related one being discussed).

Firstly, sorry. Bad day and frustrations vented inappropriately.
I'll consider this my baptism of fire in the ways of the mainline
kernel. Lessons learnt: Justify everything, provide defined timelines
for fixes, and develop a thick skin.

Upstreaming this driver isn't my main task at the moment, but I do
intend to come back to it, in particular to address the issues raised
on linux-media. Timescales of 4-6 weeks all being well (defined
timeline!).
There are no current developments on this driver that I am aware of,
so that delay shouldn't be critical for divergence. My next set of
changes to it are dependent on the current tasks.
I will also be undertaking backporting the changes made in staging to
the out-of-tree driver, so divergence will be minimised. Out-of-tree
is currently 4.4 but about to adopt 4.9, so is not in a position to
take the current staging as-is.

Michael's request was an interrupt serviced badly. Having no existing
tree to test staging with it was taking me a little while after
getting the code reviewed internally to get a tree working and confirm
all was good (at least a basic compile test). To suddenly find that
wasted was annoying and I reacted :-(


Take this patch as is, and I'll liase with Michael so that one of us
creates and sends the follow up patch to complete the fix.

I'm learning :-)

  Dave