lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 17 Jul 2014 12:50:17 -0700 From: Julius Werner <jwerner@...omium.org> To: Paul Zimmerman <Paul.Zimmerman@...opsys.com> Cc: Maciej Puzio <mx34567@...il.com>, Julius Werner <jwerner@...omium.org>, Mathias Nyman <mathias.nyman@...el.com>, David Laight <David.Laight@...lab.com>, Sarah Sharp <sarah.a.sharp@...ux.intel.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs > Hmm. Wouldn't it be safer to have a quirk for this, and only enable > the workaround if the Asmedia controller is detected? This code is so > complicated that it is difficult to see whether this could have a > harmful effect on controllers without the bug. Sorry for making it complicated, but it kinda has been like that before already... I don't think the new patch adds much confusion on its own. I would really advise against making this a quirk: checking for it in every case essentially doesn't cost us anything (just one more register compare that is negligible against all the cache-coherent memory accesses of walking the ring), and hardcoding a quirk would mean that we have to identify and add every host controller that does this individually. I still haven't seen anything in the XHCI spec that actually forbids this behavior, so it might be a perfectly legal interpretation and who knows how many host controllers chose to do it that way. Until we find them all, we would have some really bad and hard to track down bugs on those controllers (we really just got lucky this time that Maciej was able to catch it in a bisect). I think it's better to program the driver defensively and able to deal with unexpected situations in general. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists