On Thu, 2012-12-27 at 20:09 +0100, Ben Hutchings wrote: > On Thu, 2012-12-27 at 13:01 +0000, Malcolm Priestley wrote: > > upstream > > commit e2efba763b472835fdface597fe2216b3403967e > > > > Tested on kernels 2.6.35, 3.0, 3.2, 3.5 & 3.7 > > > > staging: vt6656: 64 bit- Correctly address void structure. > > > > Fixes 64 bit deadlock on successful association. > > > > Cc: [email protected] # 2.6.35+ > > Signed-off-by: Malcolm Priestley <[email protected]> > > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > > > diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c > > index 0f35a9a..1f87213 100644 > > --- a/drivers/staging/vt6656/rxtx.c > > +++ b/drivers/staging/vt6656/rxtx.c > > @@ -1452,12 +1452,10 @@ s_bPacketToWirelessUsb( > > > > > > pvRrvTime = pMICHDR = pvRTS = pvCTS = pvTxDataHd = NULL; > > - if ((bNeedEncryption) && (pTransmitKey != NULL)) { > > - if (((PSKeyTable) (pTransmitKey->pvKeyTable))->bSoftWEP == TRUE) { > > - // WEP 256 > > - bSoftWEP = TRUE; > > - } > > - } > > + if (bNeedEncryption && pTransmitKey->pvKeyTable) { > > + if (((PSKeyTable)&pTransmitKey->pvKeyTable)->bSoftWEP == TRUE) > > + bSoftWEP = TRUE; /* WEP 256 */ > > + } > > This cast is blatantly wrong - pvKeyTable points to and SKeyTable; it's > not the first element of an SKeyTable. > > Greg, I suggest you revert this upstream as it's only 'fixing' the > problem by chance. > Hi Ben,
Ah, you are correct. However, as it stands, reverting upstream on 64 bit will cause a regression. I haven't found any regressions on 32bit and it is only a condition check. Only WEP 256 users affected and the chances of the address hitting TRUE(1) during WEP/WPA negotiation. I would prefer to submit a patch to correct upstream. Regards Malcolm > Ben. > > > pTxBufHead = (PTX_BUFFER) usbPacketBuf; > > memset(pTxBufHead, 0, sizeof(TX_BUFFER)); > > > > > > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
