From: Konstantin Khlebnikov
Date: Fri, 15 Jun 2018 13:27:31 +0300
> When blackhole is used on top of classful qdisc like hfsc it breaks
> qlen and backlog counters because packets are disappear without notice.
>
> In HFSC non-zero qlen while all classes are inactive triggers warning:
> WARNING:
This breaks the build as this header is not meant to be used in this
way.
./include/linux/unaligned/access_ok.h:8:28: error: redefinition of
‘get_unaligned_le16’
static __always_inline u16 get_unaligned_le16(const void *p)
^~
In file included from dri
From: "David Woodhouse"
Date: Sat, 16 Jun 2018 20:52:33 -
>> This Fixes tag shoots the messenger really.
>>
>> I suggest to instead use :
>>
>> Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
>
>
> Oh, I hadn't realised how recent that was. Sure, let's blame you inst
From: Daniel Borkmann
Date: Sat, 16 Jun 2018 01:06:30 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
> This Fixes tag shoots the messenger really.
>
> I suggest to instead use :
>
> Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
Oh, I hadn't realised how recent that was. Sure, let's blame you instead :)
--
dwmw2
>> Commit 14afee4b609 ("net: convert sock.sk_wmem_alloc from atomic_t to
>> refcount_t") did exactly what it was intended to do, and turned this
>> mostly-theoretical problem into a real one, causing PPPoATM to fail
>> immediately as sk_wmem_alloc underflows and atm_may_send() *immediately*
>> st
On 06/16/2018 03:55 AM, David Woodhouse wrote:
> ATM accounts for in-flight TX packets in sk_wmem_alloc of the VCC on
> which they are to be sent. But it doesn't take ownership of those
> packets from the sock (if any) which originally owned them. They should
> remain owned by their actual sende
On Sat, 2018-06-16 at 03:44 +, Kevin Darbyshire-Bryant wrote:
>
> I can confirm that PPPoA with both vc & llc encapsulations work.
> BR2684 with PPPoE and both vc & llc encapsulations also work. No
> nasty messages noted in dmesg.
Thanks.
> I’m actually gobsmacked at how tolerant TalkTal
ATM accounts for in-flight TX packets in sk_wmem_alloc of the VCC on
which they are to be sent. But it doesn't take ownership of those
packets from the sock (if any) which originally owned them. They should
remain owned by their actual sender until they've left the box.
There's a hack in pskb_expa
