[PATCH 3/3] rt2x00: Check for errors from skb_pad() calls

[Stefan Bader]

On 02/17/2011 04:23 PM, Seth Forshee wrote:
> On Thu, Feb 17, 2011 at 03:19:35PM +0100, Stefan Bader wrote:
>> On 02/16/2011 10:44 PM, Seth Forshee wrote:
>>> BugLink: http://bugs.launchpad.net/bugs/659143
>>>
>>> Commit 739fd94 ("rt2x00: Pad beacon to multiple of 32 bits")
>>> added calls to skb_pad() without checking the return value,
>>> which could cause problems if any of those calls does happen
>>> to fail. Add checks to prevent this from happening.
>>>
>> - (backported from d76dfc612b40b6a9de0a3fe57fe1fa3db7a1ae3b wireless-next-2.6)
>>> Signed-off-by: Seth Forshee <seth.forshee at canonical.com>
>>> Acked-by: Ivo van Doorn <IvDoorn at gmail.com>
>>> Signed-off-by: John W. Linville <linville at tuxdriver.com>
>> + (backported from d76dfc612b40b6a9de0a3fe57fe1fa3db7a1ae3b wireless-next-2.6)
>> + Signed-off-by: Seth ...
>> ?
>>
>> Generally I am in favour of waiting until everything hits upstream and then play
>> nice and try to get it into upstream stable (which has been become a bit harder
>> as one never knows exactly who that is for which kernel). Though this is a
>> regression and wireless-next should become soonish upstream. So
> 
> This isn't a candidate for stable, as the first two patches (without
> which this patch isn't needed) first appeared in .38-rc1 and afaik
> aren't in stable. And it doesn't look like John Linville plans to submit
> it to Linus until .39 since he put it in the wireless-next tree.
> 
> And in practice I don't know that anyone has actually seen the skb_pad()
> calls failing. I just noticed it when reviewing the patches and fixed
> it, and thought that we should include it in maverick with the first two
> to avoid the possibility of introducing a new regression. But we can
> take the first two and leave this one out if you'd rather.

I did not intend to say that. More that it helps to have everything together in
Linus tree, then one can work on the upstream stable task as well as the sru
task. The third patch does make sense. And I think it is ok to sru it with the
rest in this case of an regression.

The main concern about things not being in Linus tree is that they may be found
wrong before they reach and then missing the correct change when it does. This
also helps to prevent problems thought to be fixed to turn up again in the next
release. In theory the way to sru things (in general/other packages) is to have
the fix tested in the development branch and then take it back to older
releases. Of course we cannot always do that.

-Stefan