Erik Stromdahl <[email protected]> writes: > This patch fixes a bug with padding of the skb data buffer. > Since skb_trim can only be used to reduce the skb len, it is useless when > we pad (increase the length of) the skb. Instead we allocate a new > buffer with enough space to contain both the TX data and padding. > > Since some skb's have multiple references, we can't use skb_put_padto() > to extend and pad skb->data (since it causes a panic if there is more > than one reference). > > Also, in order to avoid the following possible deadlock issue (reported by > lockdep): > > [ 26.508508] Possible interrupt unsafe locking scenario: > [ 26.508508] > [ 26.515314] CPU0 CPU1 > [ 26.519862] ---- ---- > [ 26.524408] lock(fs_reclaim); > [ 26.527573] local_irq_disable(); > [ 26.533508] lock(_xmit_ETHER#2); > [ 26.539453] lock(fs_reclaim); > [ 26.545135] <Interrupt> > [ 26.547769] lock(_xmit_ETHER#2); > [ 26.551370] > [ 26.551370] *** DEADLOCK *** > > ... we use the GFP_NOFS flag with kzalloc() > > Signed-off-by: Erik Stromdahl <[email protected]>
I replied to v1 about using skb_pad(), let's discuss more there: https://patchwork.kernel.org/patch/10891949/ -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
