netdev - Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 16 Jun 2018 03:44:16 +0000
From:   Kevin Darbyshire-Bryant <kevin@...byshire-bryant.me.uk>
To:     David Woodhouse <dwmw2@...radead.org>
CC:     Eric Dumazet <eric.dumazet@...il.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Krzysztof Mazur <krzysiek@...lesie.net>,
        "3chas3@...il.com" <3chas3@...il.com>,
        Mathias Kresin <dev@...sin.me>
Subject: Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to
 refcount_t



> On 15 Jun 2018, at 21:57, David Woodhouse <dwmw2@...radead.org> wrote:
> 
> 
> 
> On Fri, 2018-06-15 at 20:49 +0000, Kevin Darbyshire-Bryant wrote:
>> 
>>> That does end up being quite hairy. I don't think it's worth doing.
>>> 
>>> This should probably suffice to fix it...
>>> 
>>> Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in
>>> the tree you're working on, but that needs to be killed with fire
>>> anyway. It's utterly pointless as discussed.
>> 
>> I had already done so as part of the last pastebin debug info round :-)
>> 
>> As regards your patch… MAGIC!  Works an absolute treat.  Will get
>> that submitted along with the ‘nuke ifx_atm_alloc_skb’ patch to
>> OpenWrt tomorrow.  For now, maybe my brain will let me sleep :-)
>> 
>> Thank you soooooo much for your help & patience.
>> 
>> Tested-by: Kevin Darbyshire-Bryant <ldir@...byshire-bryant.me.uk>
> 
> Thanks. In the morning please could I trouble you to test the other
> variants that you can manage — PPPoA with llc-encap, as well as br2684
> and PPPoE over that?

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.  I’m actually gobsmacked at how tolerant TalkTalk/BT are of what I’ve thrown at them, they clearly just look for PPP frames :-)

Kevin


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)