On Mon, Jun 25, 2012 at 05:14:08PM +0200, Kevin Wolf wrote: > Am 25.06.2012 16:14, schrieb Michael Roth: > > On Mon, Jun 25, 2012 at 02:58:40PM +0200, Kevin Wolf wrote: > >> Am 23.06.2012 02:33, schrieb Michael Roth: > >>> Hi everyone, > >>> > >>> I've set up a tree for stable-1.1 at: > >>> > >>> git://github.com/mdroth/qemu.git stable-1.1 > >>> > >>> That is simply the initial commit for v1.1.0 > >>> > >>> I've set up a staging tree for the first batch of commits at: > >>> > >>> git://github.com/mdroth/qemu.git stable-1.1-staging > >>> > >>> This should capture everything explicitly tagged for stable/1.1. I've also > >>> pulled in relevant build fixes and a handful of applicable bug fixes. > >>> > >>> Please let me know if I've missed any patches, or if any of these > >>> shouldn't be > >>> applied. > >>> > >>> Testing so far has been all-target builds on x86, make check, qemu-test, > >>> and > >>> installation + old(current stable-1.1)->new and new->old migration for > >>> fc15/fc16/winxp. I plan on doing a more extensive final round of testing > >>> later > >>> next week before committing, as that will more or less be QEMU v1.1.1 > >>> > >>> For the next release I plan on doing weekly or bi-weekly testing of staged > >>> patches and emails of this sort before committing to stable-1.1, > >>> depending on > >>> the number of patches and code churn, and will continue working off my > >>> stable-1.1-staging tree on github for those. > >> > >> Please consider as well: > >> > >> 4bb9c939a57103898f5a51aa6a7336eb3320d923 ahci: SATA FIS is 20 bytes... > > > > I originally had this in the queue but it looks like the only effect is > > to avoid allocating/initializing an extra 16 bytes on the stack. I > > didn't see any other potential side-effects so decided to drop it. Let > > me know if I'm missing something though. > > When I reviewed it, I didn't fully understand if it really matters, but > it does corrupt some other state. It's possible that the overwritten > data isn't used anyway before it's recreated, but as I wasn't sure, I > thought backporting an easy fix wouldn't hurt.
You're right, I'd missed the potential for clobbering 8 bytes of RES_FIS_SDBFIS (which is stored in the same buffer at offset RES_FIS_RFIS + 24). I must've misread the change in initialization as only affecting the temporary buffer whose size had been reduced as part of the patch. Applied to staging, thanks. > > Kevin >
