When upstream kernel introduced commit c55fa3cccbc2c672e7f118be8f7484e53a8e9e77 we incorrectly updated our hack integration patch that updates atm/common.c +++ b/net/atm/common.c @@ -62,10 +62,16 @@ static void vcc_remove_socket(struct soc write_unlock_irq(&vcc_sklist_lock); } +struct sk_buff* (*ifx_atm_alloc_tx)(struct atm_vcc *, unsigned int) = NULL; +EXPORT_SYMBOL(ifx_atm_alloc_tx); + static bool vcc_tx_ready(struct atm_vcc *vcc, unsigned int size) { struct sock *sk = sk_atm(vcc); + if (ifx_atm_alloc_tx != NULL) + return ifx_atm_alloc_tx(vcc, size) The correct solution is to drop our ifx_atm_alloc_tx replacement hack entirely and let the kernel do its thing. In reality neither pppoatm or BR2684 interfaces actually hit this code, so the incorrect integration would only be noticed with direct socket calls which we are unaware of a use-case. This is not the solution to pppoatm vc-mux failing to work which started the whole investigation, but let's fix it up anyway. With sincerest thanks to David Woodhouse <dwmw2@infradead.org> & Mathias Kresin <dev@kresin.me>. Tested-on: lantiq, BT HomeHub 5a Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>master
parent
510f2efab6
commit
0276e1f760
Loading…
Reference in new issue