Michal Kazior <michal.kazior@xxxxxxxxx> writes: > Some firmware revisions don't wait for beacon tx > completion before sending another SWBA event. This > could lead to hardware using old (freed) beacon > data in some cases, e.g. tx credit starvation > combined with missed TBTT. This is very very rare. > > On non-IOMMU-enabled hosts this could be a > possible security issue because hw could beacon > some random data on the air. On IOMMU-enabled > hosts DMAR faults would occur in most cases and > target device would crash. > > Since there are no beacon tx completions (implicit > nor explicit) propagated to host the only > workaround for this is to allocate a DMA-coherent > buffer for a lifetime of a vif and use it for all > beacon tx commands. Worst case for this approach > is some beacons may become corrupted, e.g. garbled > IEs or out-of-date TIM bitmap. > > Keep the original beacon-related code as-is in > case future firmware revisions solve this problem > so that the old path can be easily re-enabled with > a fw_feature flag. > > Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx> Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
