[PATCH 3/3] rt2x00: Check for errors from skb_pad() calls
Seth Forshee
seth.forshee at canonical.com
Thu Feb 17 15:23:23 UTC 2011
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.
More information about the kernel-team
mailing list