Bug#622937: [squeeze] Include important changes from 2.6.32.37
On Sat, Apr 16, 2011 at 02:49:28AM +0100, Ben Hutchings wrote:
> On Fri, 2011-04-15 at 17:52 -0600, dann frazier wrote:
> [...]
> > > bd378dd net: fix rds_iovec page count overflow
> >
> > overflow fix, looks pretty straightforward
>
> but needs a fix-up, which is in 2.6.32.38.
*nod* - yeah noticed that later
> [...]
> > > f101d38 ext4: fix credits computing for indirect mapped files
> >
> > I'm not sure what improvement this provides users
>
> When using delayed allocation, ext4 still needs to count how many blocks
> the pending writes will need and fail any writes that would overflow the
> disk. This is a fix for under-counting which would result in data loss
> (or a crash?) when a disk fills up.
ok
> [...]
> > > 483cb5a atm/solos-pci: Don't include frame pseudo-header on transmit hex-dump
> >
> > This seems to be a fixup for debug code? I suggest omitting.
>
> I would rather not diverge from upstream here. It has no effect if the
> user doesn't set the atmdebug parameter.
That's less conservative than we have been for previous stable
releases, but I do agree it won't affect the vast majority of users.
> [...]
> > > ba7eb95 Squashfs: handle corruption of directory structure
> >
> > Adds some sanity checks that might avoid an oops; looks good to me
>
> I asked Vince Sanders to eyeball this as he has done some work with
> squashfs. He didn't see anything wrong with it.
Thanks
> [...]
> > > 6373cc6 x86, microcode, AMD: Extend ucode size verification
>
> That hash is ambiguous here. Full hash is
> 6373cc665a7f5859bcd7772a45a581ecbc86e2cd.
>
> > I'll defer to Ben who commented on this upstream.
>
> The code is dumb but this doesn't seem to make it any worse. It raises
> the maximum allowed size for microcode updates to AMD family 15h
> processors, and will presumably be necessary to apply microcode updates
> at some point.
ok
> [...]
> > > 5381fb8 gro: reset skb_iif on reuse
> >
> > Doesn't apply to our tree
>
> It depends on the next one; did you try to apply them in reverse order?
perhaps..
> > > 2863e5a gro: Reset dev pointer on reuse
> >
> > This looks like it'd apply, but I'll defer to Ben's network expertise here
>
> I think the bug is likely to result in a crash.
>
> [...]
> > > 6216277 Treat writes as new when holes span across page boundaries
> >
> > looks like a data corruption fix
>
> and information leak.
> [...]
> > > d7c7517 mm: avoid wrapping vm_pgoff in mremap()
> >
> > avoids a BUG()
>
> which is a trivial local DoS.
right
> [...]
> > > bd94ab2 Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfo
> >
> > looks like a good correctness fix
>
> Not sure about correctness, but it's important for compatibility.
>
> > > 11ab449 staging: hv: use sync_bitops when interacting with the hypervisor
> > > af352e4 staging: hv: Fix GARP not sent after Quick Migration
> >
> > we don't enable HYPERV, but might be good for those who build from our source
>
> I'm intending to enable them at some point. I may just backport the
> current upstream versions though.
>
> > > 1ed34c9 staging: usbip: bugfix for isochronous packets and optimization
> > > d9638d9 staging: usbip: bugfix add number of packets for isochronous frames
> > > 98d7db5 staging: usbip: bugfixes related to kthread conversion
> >
> > I'm a bit concerned about the size of these patches, but they *seem*
> > important for compatibility (and the last one avoids a deadlock)
> [...]
>
> This is staging. It was crap to start with and these will probably make
> it marginally less crap. :-)
I've started preparing a commit but I'll be mostly offline today so I
won't be able to finish it up before this evening.
- dann
Reply to: