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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org