Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 18 Jun 2018, at 08:06, David Woodhouse wrote: > > On Sat, 2018-06-16 at 08:36 +, Kevin Darbyshire-Bryant via openwrt-devel > wrote: >> Backport a hot off the press upstream kernel ATM fix: >> >> Preserve value of skb->truesize when accounting to vcc >> >> "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize >> for certain skbs. Ideally it would cover ATM too. It doesn't. Just >> stashing the accounted value and using it in atm_raw_pop() is probably >> the easiest way to cope." > > Please use the version that got committed upstream (although the > differences are only in the commit message): > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=9bbe60a67be5a1c6f79b3c9be5003481a50529ff I certainly can do so and considered submitting a v3 yesterday…. I held off on the basis that I’d expect the fix to arrive back at us via the stable backports and the usual stream of kernel bumps that I keep an eye on also. At that point our local patch would disappear anyway. I can be persuaded to not be so bloody lazy :-) Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
On Sat, 2018-06-16 at 08:36 +, Kevin Darbyshire-Bryant via openwrt-devel wrote: > Backport a hot off the press upstream kernel ATM fix: > > Preserve value of skb->truesize when accounting to vcc > > "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize > for certain skbs. Ideally it would cover ATM too. It doesn't. Just > stashing the accounted value and using it in atm_raw_pop() is probably > the easiest way to cope." Please use the version that got committed upstream (although the differences are only in the commit message): https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=9bbe60a67be5a1c6f79b3c9be5003481a50529ff smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
On Sat, 2018-06-16 at 09:48 +, David Woodhouse wrote: > > > Backport a hot off the press upstream kernel ATM fix: > > > > Preserve value of skb->truesize when accounting to vcc > > > > "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize > > for certain skbs. Ideally it would cover ATM too. It doesn't. Just > > stashing the accounted value and using it in atm_raw_pop() is probably > > the easiest way to cope." > > > > The issue was introduced in upstream by: > > > > commit 14afee4b6092fde451ee17604e5f5c89da33e71e > > Author: Reshetova, Elena > > Date: Fri Jun 30 13:08:00 2017 +0300 > > > > net: convert sock.sk_wmem_alloc from atomic_t to refcount_t > > > > Sincerest thanks to Mathias Kresin for debugging > > assistance and to David Woodhouse for further > > guidance, cajoling & patience in interpreting the debug I was giving him > > and producing a fix! > > > > Fixes FS#1567 > > Is it tested with PPPoA+LLC-encaps and (more importantly) PPPoE+BR2684? > (Please) Ah, I see your 5am assertion that it is. Thanks again for going above and beyond to help diagnose and fix this. smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
> Backport a hot off the press upstream kernel ATM fix: > > Preserve value of skb->truesize when accounting to vcc > > "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize > for certain skbs. Ideally it would cover ATM too. It doesn't. Just > stashing the accounted value and using it in atm_raw_pop() is probably > the easiest way to cope." > > The issue was introduced in upstream by: > > commit 14afee4b6092fde451ee17604e5f5c89da33e71e > Author: Reshetova, Elena > Date: Fri Jun 30 13:08:00 2017 +0300 > > net: convert sock.sk_wmem_alloc from atomic_t to refcount_t > > Sincerest thanks to Mathias Kresin for debugging > assistance and to David Woodhouse for further > guidance, cajoling & patience in interpreting the debug I was giving him > and producing a fix! > > Fixes FS#1567 Is it tested with PPPoA+LLC-encaps and (more importantly) PPPoE+BR2684? (Please) -- dwmw2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Backport a hot off the press upstream kernel ATM fix:
Preserve value of skb->truesize when accounting to vcc
"There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
for certain skbs. Ideally it would cover ATM too. It doesn't. Just
stashing the accounted value and using it in atm_raw_pop() is probably
the easiest way to cope."
The issue was introduced in upstream by:
commit 14afee4b6092fde451ee17604e5f5c89da33e71e
Author: Reshetova, Elena
Date: Fri Jun 30 13:08:00 2017 +0300
net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
Sincerest thanks to Mathias Kresin for debugging
assistance and to David Woodhouse for further
guidance, cajoling & patience in interpreting the debug I was giving him
and producing a fix!
Fixes FS#1567
Signed-off-by: Kevin Darbyshire-Bryant
---
...-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch | 186 +
1 file changed, 186 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
diff --git
a/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
new file mode 100644
index 00..8108d99348
--- /dev/null
+++
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
@@ -0,0 +1,186 @@
+From 99967eb67d14b2ed17b194a8dac357d641a06e43 Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 21:00:27 +0100
+Subject: [PATCH] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
+
+On Fri, 2018-06-15 at 14:44 +0100, David Woodhouse wrote:
+>
+> > Or simply use a new field in ATM_SKB(skb) to remember a stable
+> > truesize used in both sides (add/sub)
+>
+> Right, that was my second suggestion ("copy the accounted value...").
+>
+> It's a bit of a hack, and I think that actually *using* sock_wfree()
+> instead of what's currently in atm_pop_raw() would be the better
+> solution. Does anyone remember why we didn't do that in the first
+> place?
+
+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.
+
+From 3368eaeb0a2f09138894dde0f26f879e5228005a Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 20:49:20 +0100
+Subject: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
+
+There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
+for certain skbs. Ideally it would cover ATM too. It doesn't. Just
+stashing the accounted value and using it in atm_raw_pop() is probably
+the easiest way to cope.
+
+Signed-off-by: David Woodhouse
+Signed-off-by: Kevin Darbyshire-Bryant
+---
+ include/linux/atmdev.h | 15 +++
+ net/atm/br2684.c | 3 +--
+ net/atm/clip.c | 3 +--
+ net/atm/common.c | 3 +--
+ net/atm/lec.c | 3 +--
+ net/atm/mpc.c | 3 +--
+ net/atm/pppoatm.c | 3 +--
+ net/atm/raw.c | 4 ++--
+ 8 files changed, 23 insertions(+), 14 deletions(-)
+
+diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
+index 0c27515d..8124815e 100644
+--- a/include/linux/atmdev.h
b/include/linux/atmdev.h
+@@ -214,6 +214,7 @@ struct atmphy_ops {
+ struct atm_skb_data {
+ struct atm_vcc *vcc; /* ATM VCC */
+ unsigned long atm_options;/* ATM layer options */
++ unsigned intacct_truesize; /* truesize accounted to vcc */
+ };
+
+ #define VCC_HTABLE_SIZE 32
+@@ -241,6 +242,20 @@ void vcc_insert_socket(struct sock *sk);
+
+ void atm_dev_release_vccs(struct atm_dev *dev);
+
++static inline void atm_account_tx(struct atm_vcc *vcc, struct sk_buff *skb)
++{
++ /*
++ * Because ATM skbs may not belong to a sock (and we don't
++ * necessarily want to), skb->truesize may be adjusted,
++ * escaping the hack in pskb_expand_head() which avoids
++ * doing so for some cases. So stash the value of truesize
++ * at the time we accounted it, and atm_pop_raw() can use
++ * that value later, in case it changes.
++ */
++ refcount_add(skb->truesize, _atm(vcc)->sk_wmem_alloc);
++ ATM_SKB(skb)->acct_truesize = skb->truesize;
++ ATM_SKB(skb)->atm_options = vcc->atm_options;
++}
+
+ static inline void atm_force_charge(struct atm_vcc *vcc,int truesize)
+ {
+diff --git a/net/atm/br2684.c b/net/atm/br2684.c
+index 4e96..bc21f8e8 100644
+--- a/net/atm/br2684.c
