* [PATCH COMMITTED] bluetooth: hci_nokia: Don't include linux/unaligned/le_struct.h directly.
From: David Miller @ 2018-06-16 23:40 UTC (permalink / raw)
To: marcel; +Cc: johan.hedberg, linux-bluetooth, netdev
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 drivers/bluetooth/hci_nokia.c:32:
./include/linux/unaligned/le_struct.h:7:19: note: previous definition of ‘get_unaligned_le16’ was here
static inline u16 get_unaligned_le16(const void *p)
Use asm/unaligned.h instead.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/bluetooth/hci_nokia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_nokia.c b/drivers/bluetooth/hci_nokia.c
index 14d159e2042d..2dc33e65d2d0 100644
--- a/drivers/bluetooth/hci_nokia.c
+++ b/drivers/bluetooth/hci_nokia.c
@@ -29,7 +29,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/types.h>
-#include <linux/unaligned/le_struct.h>
+#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
From: David Miller @ 2018-06-16 23:27 UTC (permalink / raw)
To: dwmw2; +Cc: eric.dumazet, netdev, ldir
In-Reply-To: <d7644be784f3164bbc5f79154260160d.squirrel@twosheds.infradead.org>
From: "David Woodhouse" <dwmw2@infradead.org>
Date: Sat, 16 Jun 2018 20:52:33 -0000
>> 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 :)
Patch applied with adjusted Fixes: tag, and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: pull-request: bpf 2018-06-16
From: David Miller @ 2018-06-16 22:54 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180615230630.12117-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
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.
^ permalink raw reply
* [PATCH] xfrm4: Remove export declaration from xfrm4_protocol_init
From: efremov @ 2018-06-16 20:58 UTC (permalink / raw)
To: Steffen Klassert
Cc: Denis Efremov, David S. Miller, netdev, linux-kernel, ldv-project
From: Denis Efremov <efremov@linux.com>
The function xfrm4_protocol_init is exported as GPL symbol and
annotated as __init. That is reasonable only in the case when
this function is called from another's module __init section.
Otherwise, we will face section mismatch error. xfrm4_protocol_init
is used in xfrm4_init along with xfrm4_state_init and xfrm4_policy_init.
The last two functions are not exported as GPL symbols. According to
this, it seem's like there is no reason to export xfrm4_protocol_init too.
Fix potential section mismatch by removing export declaration
from xfrm4_protocol_init.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <efremov@linux.com>
---
net/ipv4/xfrm4_protocol.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/xfrm4_protocol.c b/net/ipv4/xfrm4_protocol.c
index 8dd0e6ab8606..0e1f5dc2766b 100644
--- a/net/ipv4/xfrm4_protocol.c
+++ b/net/ipv4/xfrm4_protocol.c
@@ -297,4 +297,3 @@ void __init xfrm4_protocol_init(void)
{
xfrm_input_register_afinfo(&xfrm4_input_afinfo);
}
-EXPORT_SYMBOL(xfrm4_protocol_init);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
From: David Woodhouse @ 2018-06-16 20:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Woodhouse, netdev, ldir
In-Reply-To: <62fbc51a-4738-6c21-8c53-d84fee7a9bbd@gmail.com>
> 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
^ permalink raw reply
* Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
From: David Woodhouse @ 2018-06-16 15:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Woodhouse, netdev, ldir
In-Reply-To: <62fbc51a-4738-6c21-8c53-d84fee7a9bbd@gmail.com>
>> 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*
>> starts refusing to allow new packets.
...
>> Fixes: 14afee4b ("net: convert sock.sk_wmem_alloc from atomic_t to
>> refcount_t")
>
> This Fixes tag shoots the messenger really.
A little bit, yes. The text hopefully made that clear.
> I suggest to instead use :
>
> Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
>
> Because even without the conversion to refcount_t, we could have a LOCKDEP
> splat in :
>
> filter = rcu_dereference_check(sk->sk_filter,
> atomic_read(&sk->sk_wmem_alloc) == 0);
>
> Note that some places make a further check even when LOCKDEP is not used.
>
> net/ipv4/af_inet.c:154: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/iucv/af_iucv.c:405: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/key/af_key.c:112: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/netlink/af_netlink.c:410: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/packet/af_packet.c:1286: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/rxrpc/af_rxrpc.c:852: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
> net/unix/af_unix.c:490: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
>
>
> We might factorize these checks into __sk_destruct()
>
How many of those were likely to trigger in practice on an ATM VCC though?
If we are taking the Fixes: tag as a hint about which stable kernels we
might want to backport to, rather than a moral assignment of blame, then
14afee4b is probably not the worst place to point it. But I don't mind
much...
--
dwmw2
^ permalink raw reply
* Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
From: Eric Dumazet @ 2018-06-16 12:57 UTC (permalink / raw)
To: David Woodhouse, netdev, ldir
In-Reply-To: <20180616105544.246714-1-dwmw2@infradead.org>
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 sender until they've left the box.
>
> There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
> for certain skbs, precisely to avoid messing up sk_wmem_alloc
> accounting. Ideally that hack would cover the ATM use case too, but it
> doesn't — skbs which aren't owned by any sock, for example PPP control
> frames, still get their truesize adjusted when the low-level ATM driver
> adds headroom.
>
> This has always been an issue, it seems. The truesize of a packet
> increases, and sk_wmem_alloc on the VCC goes negative. But this wasn't
> for normal traffic, only for control frames. So I think we just got away
> with it, and we probably needed to send 2GiB of LCP echo frames before
> the misaccounting would ever have caused a problem and caused
> atm_may_send() to start refusing packets.
>
> 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*
> starts refusing to allow new packets.
>
> The least intrusive solution to this problem is to stash the value of
> skb->truesize that was accounted to the VCC, in a new member of the
> ATM_SKB(skb) structure. Then in atm_pop_raw() subtract precisely that
> value instead of the then-current value of skb->truesize.
>
> Fixes: 14afee4b ("net: convert sock.sk_wmem_alloc from atomic_t to refcount_t")
This Fixes tag shoots the messenger really.
I suggest to instead use :
Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
Because even without the conversion to refcount_t, we could have a LOCKDEP
splat in :
filter = rcu_dereference_check(sk->sk_filter,
atomic_read(&sk->sk_wmem_alloc) == 0);
Note that some places make a further check even when LOCKDEP is not used.
net/ipv4/af_inet.c:154: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/iucv/af_iucv.c:405: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/key/af_key.c:112: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/netlink/af_netlink.c:410: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/packet/af_packet.c:1286: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/rxrpc/af_rxrpc.c:852: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
net/unix/af_unix.c:490: WARN_ON(refcount_read(&sk->sk_wmem_alloc));
We might factorize these checks into __sk_destruct()
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Eric Dumazet @ 2018-06-16 12:45 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: David S. Miller, Eric Dumazet, LKML, Christophe LEROY,
Meelis Roos, schwab, netdev, linuxppc-dev
In-Reply-To: <CA+7wUsysaip70ARGQ7Byg1Zktfg0Y1esjEc9HxBGU4sKL8crhg@mail.gmail.com>
On 06/16/2018 12:14 AM, Mathieu Malaterre wrote:
> Hi Eric,
>
> On Fri, Jun 15, 2018 at 9:14 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>>
>> On 06/15/2018 11:56 AM, Mathieu Malaterre wrote:
>>> This reverts commit 88078d98d1bb085d72af8437707279e203524fa5.
>>>
>>> It causes regressions for people using chips driven by the sungem
>>> driver. Suspicion is that the skb->csum value isn't being adjusted
>>> properly.
>>>
>>> Symptoms as seen on G4+sungem are:
>>>
>>> [ 34.023281] eth0: hw csum failure
>>> [ 34.023438] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #2
>>> [ 34.023618] Call Trace:
>>> [ 34.023707] [dffedbd0] [c069ddac] __skb_checksum_complete+0xf0/0x108 (unreliable)
>>> [ 34.023948] [dffedbf0] [c0777a70] tcp_v4_rcv+0x604/0xe00
>>> [ 34.024118] [dffedc70] [c0731624] ip_local_deliver_finish+0xa8/0x3c4
>>> [ 34.024315] [dffedcb0] [c0732430] ip_local_deliver+0xf0/0x154
>>> [ 34.024493] [dffedcf0] [c07328dc] ip_rcv+0x448/0x774
>>> [ 34.024653] [dffedd50] [c06aeae0] __netif_receive_skb_core+0x5e8/0x1184
>>> [ 34.024857] [dffedde0] [c06bba20] napi_gro_receive+0x160/0x22c
>>> [ 34.025044] [dffede10] [e14b2590] gem_poll+0x7fc/0x1ac0 [sungem]
>>> [ 34.025228] [dffedee0] [c06bacf0] net_rx_action+0x34c/0x618
>>> [ 34.025402] [dffedf60] [c07fd27c] __do_softirq+0x16c/0x5f0
>>> [ 34.025575] [dffedfd0] [c0064c7c] irq_exit+0x110/0x1a8
>>> [ 34.025738] [dffedff0] [c0016170] call_do_irq+0x24/0x3c
>>> [ 34.025903] [c0cf7e80] [c0009a84] do_IRQ+0x98/0x1a0
>>> [ 34.026055] [c0cf7eb0] [c001b474] ret_from_except+0x0/0x14
>>> [ 34.026225] --- interrupt: 501 at arch_cpu_idle+0x30/0x78
>>> LR = arch_cpu_idle+0x30/0x78
>>> [ 34.026510] [c0cf7f70] [c0cf6000] 0xc0cf6000 (unreliable)
>>> [ 34.026682] [c0cf7f80] [c00a3868] do_idle+0xc4/0x158
>>> [ 34.026835] [c0cf7fb0] [c00a3ab0] cpu_startup_entry+0x20/0x28
>>> [ 34.027013] [c0cf7fc0] [c0998820] start_kernel+0x47c/0x490
>>> [ 34.027181] [c0cf7ff0] [00003444] 0x3444
>>>
>>> See commit 7ce5a27f2ef8 ("Revert "net: Handle CHECKSUM_COMPLETE more
>>> adequately in pskb_trim_rcsum()."") for previous reference.
>>
>> This fix seems to hide a bug in csum functions on this architecture.
>
> That's odd since it seems to only affect g4+sungem user. None of the
> ppc64 seems to be having it. And some ppc32 users are not even seeing
> it.
>
>> Or a bug on this NIC when receiving a small packet (less than 60 bytes).
>> Maybe the padding bytes are not included in NIC provided csum, and not 0.
>
> Ok in that case the bug is located in
> ./drivers/net/ethernet/sun/sungem.c that seems more likely. I'll try
> to understand that code, then.
I would try something like :
Basically do not bother using CHECKSUM_COMPLETE for small frames that might have been padded.
Since we need to bring one cache line in eth_type_trans() and further header processing,
computing the checksum in software will be almost free anyway.
diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
index 7a16d40a72d13cf1d522e8a3a396c826fe76f9b9..071039f211a8a33153e888bd4014314ba5e686a4 100644
--- a/drivers/net/ethernet/sun/sungem.c
+++ b/drivers/net/ethernet/sun/sungem.c
@@ -855,9 +855,11 @@ static int gem_rx(struct gem *gp, int work_to_do)
skb = copy_skb;
}
- csum = (__force __sum16)htons((status & RXDCTRL_TCPCSUM) ^ 0xffff);
- skb->csum = csum_unfold(csum);
- skb->ip_summed = CHECKSUM_COMPLETE;
+ if (len > ETH_ZLEN) {
+ csum = (__force __sum16)htons((status & RXDCTRL_TCPCSUM) ^ 0xffff);
+ skb->csum = csum_unfold(csum);
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ }
skb->protocol = eth_type_trans(skb, gp->dev);
napi_gro_receive(&gp->napi, skb);
^ permalink raw reply related
* Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
From: David Woodhouse @ 2018-06-16 11:30 UTC (permalink / raw)
To: Kevin Darbyshire-Bryant
Cc: Eric Dumazet, Elena Reshetova, netdev@vger.kernel.org,
Krzysztof Mazur, 3chas3@gmail.com, Mathias Kresin
In-Reply-To: <60894922-D59A-4F6D-862B-9933DE06F1BD@darbyshire-bryant.me.uk>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
On Sat, 2018-06-16 at 03:44 +0000, 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 TalkTalk/BT are of what
> I’ve thrown at them, they clearly just look for PPP frames :-)
We weren't saying that in the days when they stupidly assumed all PPP
data frames contained Legacy IP, and then dropped any short frames
which, if they *had* been Legacy IP, would have had zeroes in the
'length' field.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]
^ permalink raw reply
* [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
From: David Woodhouse @ 2018-06-16 10:55 UTC (permalink / raw)
To: netdev, ldir
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_expand_head() to avoid adjusting skb->truesize
for certain skbs, precisely to avoid messing up sk_wmem_alloc
accounting. Ideally that hack would cover the ATM use case too, but it
doesn't — skbs which aren't owned by any sock, for example PPP control
frames, still get their truesize adjusted when the low-level ATM driver
adds headroom.
This has always been an issue, it seems. The truesize of a packet
increases, and sk_wmem_alloc on the VCC goes negative. But this wasn't
for normal traffic, only for control frames. So I think we just got away
with it, and we probably needed to send 2GiB of LCP echo frames before
the misaccounting would ever have caused a problem and caused
atm_may_send() to start refusing packets.
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*
starts refusing to allow new packets.
The least intrusive solution to this problem is to stash the value of
skb->truesize that was accounted to the VCC, in a new member of the
ATM_SKB(skb) structure. Then in atm_pop_raw() subtract precisely that
value instead of the then-current value of skb->truesize.
Fixes: 14afee4b ("net: convert sock.sk_wmem_alloc from atomic_t to refcount_t")
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Tested-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
---
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 0c27515d2cf6..8124815eb121 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 int acct_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, &sk_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 36b3adacc0dd..10462de734ea 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -252,8 +252,7 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
ATM_SKB(skb)->vcc = atmvcc = brvcc->atmvcc;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, atmvcc, atmvcc->dev);
- refcount_add(skb->truesize, &sk_atm(atmvcc)->sk_wmem_alloc);
- ATM_SKB(skb)->atm_options = atmvcc->atm_options;
+ atm_account_tx(atmvcc, skb);
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
diff --git a/net/atm/clip.c b/net/atm/clip.c
index 66caa48a27c2..d795b9c5aea4 100644
--- a/net/atm/clip.c
+++ b/net/atm/clip.c
@@ -381,8 +381,7 @@ static netdev_tx_t clip_start_xmit(struct sk_buff *skb,
memcpy(here, llc_oui, sizeof(llc_oui));
((__be16 *) here)[3] = skb->protocol;
}
- refcount_add(skb->truesize, &sk_atm(vcc)->sk_wmem_alloc);
- ATM_SKB(skb)->atm_options = vcc->atm_options;
+ atm_account_tx(vcc, skb);
entry->vccs->last_use = jiffies;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, vcc, vcc->dev);
old = xchg(&entry->vccs->xoff, 1); /* assume XOFF ... */
diff --git a/net/atm/common.c b/net/atm/common.c
index 1f2af59935db..ff5748b2190f 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -630,10 +630,9 @@ int vcc_sendmsg(struct socket *sock, struct msghdr *m, size_t size)
goto out;
}
pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
- refcount_add(skb->truesize, &sk->sk_wmem_alloc);
+ atm_account_tx(vcc, skb);
skb->dev = NULL; /* for paths shared with net_device interfaces */
- ATM_SKB(skb)->atm_options = vcc->atm_options;
if (!copy_from_iter_full(skb_put(skb, size), size, &m->msg_iter)) {
kfree_skb(skb);
error = -EFAULT;
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 5a95fcf6f9b6..d7f5cf5b7594 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -182,9 +182,8 @@ lec_send(struct atm_vcc *vcc, struct sk_buff *skb)
struct net_device *dev = skb->dev;
ATM_SKB(skb)->vcc = vcc;
- ATM_SKB(skb)->atm_options = vcc->atm_options;
+ atm_account_tx(vcc, skb);
- refcount_add(skb->truesize, &sk_atm(vcc)->sk_wmem_alloc);
if (vcc->send(vcc, skb) < 0) {
dev->stats.tx_dropped++;
return;
diff --git a/net/atm/mpc.c b/net/atm/mpc.c
index 75620c2f2617..24b53c4c39c6 100644
--- a/net/atm/mpc.c
+++ b/net/atm/mpc.c
@@ -555,8 +555,7 @@ static int send_via_shortcut(struct sk_buff *skb, struct mpoa_client *mpc)
sizeof(struct llc_snap_hdr));
}
- refcount_add(skb->truesize, &sk_atm(entry->shortcut)->sk_wmem_alloc);
- ATM_SKB(skb)->atm_options = entry->shortcut->atm_options;
+ atm_account_tx(entry->shortcut, skb);
entry->shortcut->send(entry->shortcut, skb);
entry->packets_fwded++;
mpc->in_ops->put(entry);
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 21d9d341a619..af8c4b38b746 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -350,8 +350,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
return 1;
}
- refcount_add(skb->truesize, &sk_atm(ATM_SKB(skb)->vcc)->sk_wmem_alloc);
- ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
+ atm_account_tx(vcc, skb);
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
diff --git a/net/atm/raw.c b/net/atm/raw.c
index ee10e8d46185..b3ba44aab0ee 100644
--- a/net/atm/raw.c
+++ b/net/atm/raw.c
@@ -35,8 +35,8 @@ static void atm_pop_raw(struct atm_vcc *vcc, struct sk_buff *skb)
struct sock *sk = sk_atm(vcc);
pr_debug("(%d) %d -= %d\n",
- vcc->vci, sk_wmem_alloc_get(sk), skb->truesize);
- WARN_ON(refcount_sub_and_test(skb->truesize, &sk->sk_wmem_alloc));
+ vcc->vci, sk_wmem_alloc_get(sk), ATM_SKB(skb)->acct_truesize);
+ WARN_ON(refcount_sub_and_test(ATM_SKB(skb)->acct_truesize, &sk->sk_wmem_alloc));
dev_kfree_skb_any(skb);
sk->sk_write_space(sk);
}
--
2.17.0
^ permalink raw reply related
* (unknown)
From: Mrs Mavis Wanczyk @ 2018-06-16 8:15 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mrs Mavis L. Wanczyk
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Mathieu Malaterre @ 2018-06-16 7:14 UTC (permalink / raw)
To: eric.dumazet
Cc: David S. Miller, Eric Dumazet, LKML, Christophe LEROY,
Meelis Roos, schwab, netdev, linuxppc-dev
In-Reply-To: <fbb95c11-240c-1a11-0a62-0483908c577e@gmail.com>
Hi Eric,
On Fri, Jun 15, 2018 at 9:14 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 06/15/2018 11:56 AM, Mathieu Malaterre wrote:
> > This reverts commit 88078d98d1bb085d72af8437707279e203524fa5.
> >
> > It causes regressions for people using chips driven by the sungem
> > driver. Suspicion is that the skb->csum value isn't being adjusted
> > properly.
> >
> > Symptoms as seen on G4+sungem are:
> >
> > [ 34.023281] eth0: hw csum failure
> > [ 34.023438] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #2
> > [ 34.023618] Call Trace:
> > [ 34.023707] [dffedbd0] [c069ddac] __skb_checksum_complete+0xf0/0x108 (unreliable)
> > [ 34.023948] [dffedbf0] [c0777a70] tcp_v4_rcv+0x604/0xe00
> > [ 34.024118] [dffedc70] [c0731624] ip_local_deliver_finish+0xa8/0x3c4
> > [ 34.024315] [dffedcb0] [c0732430] ip_local_deliver+0xf0/0x154
> > [ 34.024493] [dffedcf0] [c07328dc] ip_rcv+0x448/0x774
> > [ 34.024653] [dffedd50] [c06aeae0] __netif_receive_skb_core+0x5e8/0x1184
> > [ 34.024857] [dffedde0] [c06bba20] napi_gro_receive+0x160/0x22c
> > [ 34.025044] [dffede10] [e14b2590] gem_poll+0x7fc/0x1ac0 [sungem]
> > [ 34.025228] [dffedee0] [c06bacf0] net_rx_action+0x34c/0x618
> > [ 34.025402] [dffedf60] [c07fd27c] __do_softirq+0x16c/0x5f0
> > [ 34.025575] [dffedfd0] [c0064c7c] irq_exit+0x110/0x1a8
> > [ 34.025738] [dffedff0] [c0016170] call_do_irq+0x24/0x3c
> > [ 34.025903] [c0cf7e80] [c0009a84] do_IRQ+0x98/0x1a0
> > [ 34.026055] [c0cf7eb0] [c001b474] ret_from_except+0x0/0x14
> > [ 34.026225] --- interrupt: 501 at arch_cpu_idle+0x30/0x78
> > LR = arch_cpu_idle+0x30/0x78
> > [ 34.026510] [c0cf7f70] [c0cf6000] 0xc0cf6000 (unreliable)
> > [ 34.026682] [c0cf7f80] [c00a3868] do_idle+0xc4/0x158
> > [ 34.026835] [c0cf7fb0] [c00a3ab0] cpu_startup_entry+0x20/0x28
> > [ 34.027013] [c0cf7fc0] [c0998820] start_kernel+0x47c/0x490
> > [ 34.027181] [c0cf7ff0] [00003444] 0x3444
> >
> > See commit 7ce5a27f2ef8 ("Revert "net: Handle CHECKSUM_COMPLETE more
> > adequately in pskb_trim_rcsum()."") for previous reference.
>
> This fix seems to hide a bug in csum functions on this architecture.
That's odd since it seems to only affect g4+sungem user. None of the
ppc64 seems to be having it. And some ppc32 users are not even seeing
it.
> Or a bug on this NIC when receiving a small packet (less than 60 bytes).
> Maybe the padding bytes are not included in NIC provided csum, and not 0.
Ok in that case the bug is located in
./drivers/net/ethernet/sun/sungem.c that seems more likely. I'll try
to understand that code, then.
Thanks
>
>
>
^ permalink raw reply
* Re: [PATCH] net_sched: blackhole: tell upper qdisc about dropped packets
From: Cong Wang @ 2018-06-16 4:03 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Eric Dumazet, Linux Kernel Network Developers, David S. Miller,
Jiri Pirko, Jamal Hadi Salim
In-Reply-To: <CAM_iQpWtVQnfrj8KKE79ea9s9Goj+biF1LEahNYTcb1PgSff5g@mail.gmail.com>
On Fri, Jun 15, 2018 at 9:00 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Fri, Jun 15, 2018 at 6:21 AM, Konstantin Khlebnikov
> <khlebnikov@yandex-team.ru> wrote:
>> On 15.06.2018 16:13, Eric Dumazet wrote:
>>>
>>>
>>>
>>> On 06/15/2018 03:27 AM, Konstantin Khlebnikov wrote:
>>>>
>>>> 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: ... at net/sched/sch_hfsc.c:1393 hfsc_dequeue+0xba4/0xe90
>>>> [sch_hfsc]
>>>> and schedules watchdog work endlessly.
>>>>
>>>> This patch return __NET_XMIT_BYPASS in addition to NET_XMIT_SUCCESS,
>>>> this flag tells upper layer: this packet is gone and isn't queued.
>>>>
>>>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>>> ---
>>>> net/sched/sch_blackhole.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/sched/sch_blackhole.c b/net/sched/sch_blackhole.c
>>>> index c98a61e980ba..9c4c2bb547d7 100644
>>>> --- a/net/sched/sch_blackhole.c
>>>> +++ b/net/sched/sch_blackhole.c
>>>> @@ -21,7 +21,7 @@ static int blackhole_enqueue(struct sk_buff *skb,
>>>> struct Qdisc *sch,
>>>> struct sk_buff **to_free)
>>>> {
>>>> qdisc_drop(skb, sch, to_free);
>>>> - return NET_XMIT_SUCCESS;
>>>> + return NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
>>>
>>>
>>> Why do not we use instead :
>>>
>>> return qdisc_drop(skb, sch, to_free);
>>>
>>> Although noop_enqueue() seems to use :
>>>
>>> return NET_XMIT_CN;
>>>
>>> Oh well.
>>>
>>>
>>
>> I suppose "blackhole" should work like "successful" xmit, but counted as
>> drop.
>
> But anything !NET_XMIT_SUCCESS is basically same for upper
> layer:
>
> err = qdisc_enqueue(skb, cl->qdisc, to_free);
> if (unlikely(err != NET_XMIT_SUCCESS)) {
> if (net_xmit_drop_count(err)) {
> cl->qstats.drops++;
> qdisc_qstats_drop(sch);
> }
> return err;
> }
>
> So using NET_XMIT_DROP is same in this case?
Not same for __dev_xmit_skb()... Yeah, we should keep
the NET_XMIT_SUCCESS bit.
^ permalink raw reply
* Re: [PATCH] net_sched: blackhole: tell upper qdisc about dropped packets
From: Cong Wang @ 2018-06-16 4:00 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Eric Dumazet, Linux Kernel Network Developers, David S. Miller,
Jiri Pirko, Jamal Hadi Salim
In-Reply-To: <fe86812c-f0bb-157f-d489-ba08a02b43c7@yandex-team.ru>
On Fri, Jun 15, 2018 at 6:21 AM, Konstantin Khlebnikov
<khlebnikov@yandex-team.ru> wrote:
> On 15.06.2018 16:13, Eric Dumazet wrote:
>>
>>
>>
>> On 06/15/2018 03:27 AM, Konstantin Khlebnikov wrote:
>>>
>>> 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: ... at net/sched/sch_hfsc.c:1393 hfsc_dequeue+0xba4/0xe90
>>> [sch_hfsc]
>>> and schedules watchdog work endlessly.
>>>
>>> This patch return __NET_XMIT_BYPASS in addition to NET_XMIT_SUCCESS,
>>> this flag tells upper layer: this packet is gone and isn't queued.
>>>
>>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>> ---
>>> net/sched/sch_blackhole.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/sched/sch_blackhole.c b/net/sched/sch_blackhole.c
>>> index c98a61e980ba..9c4c2bb547d7 100644
>>> --- a/net/sched/sch_blackhole.c
>>> +++ b/net/sched/sch_blackhole.c
>>> @@ -21,7 +21,7 @@ static int blackhole_enqueue(struct sk_buff *skb,
>>> struct Qdisc *sch,
>>> struct sk_buff **to_free)
>>> {
>>> qdisc_drop(skb, sch, to_free);
>>> - return NET_XMIT_SUCCESS;
>>> + return NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
>>
>>
>> Why do not we use instead :
>>
>> return qdisc_drop(skb, sch, to_free);
>>
>> Although noop_enqueue() seems to use :
>>
>> return NET_XMIT_CN;
>>
>> Oh well.
>>
>>
>
> I suppose "blackhole" should work like "successful" xmit, but counted as
> drop.
But anything !NET_XMIT_SUCCESS is basically same for upper
layer:
err = qdisc_enqueue(skb, cl->qdisc, to_free);
if (unlikely(err != NET_XMIT_SUCCESS)) {
if (net_xmit_drop_count(err)) {
cl->qstats.drops++;
qdisc_qstats_drop(sch);
}
return err;
}
So using NET_XMIT_DROP is same in this case?
^ permalink raw reply
* Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
From: Kevin Darbyshire-Bryant @ 2018-06-16 3:44 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Elena Reshetova, netdev@vger.kernel.org,
Krzysztof Mazur, 3chas3@gmail.com, Mathias Kresin
In-Reply-To: <1529096226.27158.51.camel@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
> On 15 Jun 2018, at 21:57, David Woodhouse <dwmw2@infradead.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@darbyshire-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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/multicast: clean change record if add new INCLUDE group
From: Hangbin Liu @ 2018-06-16 3:10 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Paolo Abeni, Stefano Brivio, Daniel Borkmann,
WANG Cong, hideaki.yoshifuji
In-Reply-To: <1528871551-17879-1-git-send-email-liuhangbin@gmail.com>
Self NAK this patch, there is some issue I need to fix.
On Wed, Jun 13, 2018 at 02:32:31PM +0800, Hangbin Liu wrote:
> Based on RFC3376 5.1 and RFC3810 6.1:
> If no interface
> state existed for that multicast address before the change (i.e., the
> change consisted of creating a new per-interface record), or if no
> state exists after the change (i.e., the change consisted of deleting
> a per-interface record), then the "non-existent" state is considered
> to have a filter mode of INCLUDE and an empty source list.
>
> Which means a new multicast group should start with state IN(). That is
> exactly what we did with ip_mc_join_group()/ipv6_sock_mc_join(), which
> adds a group with state EX() and init crcount to mc_qrv. The kernel will
> send a TO_EX() report message after adding group. This is what IGMPv3/MLDv2
> ASM(Any-Source Multicast) mode should look like.
>
> But for IGMPv3/MLDv2 SSM JOIN_SOURCE_GROUP mode, we split the group
> joining into two steps. First step we join the group like ASM, i.e. via
> ip_mc_join_group()/ipv6_sock_mc_join(). So the state changes from IN() to EX().
>
> Then we add the Source-specific address with INCLUDE mode. So the state
> changes from EX() to IN(A).
>
> Before the first step sends a group change record, we finished the second step.
> So we will only send the second change record. i.e. TO_IN(A)
>
> Regarding the RFC stands, we should actually send an ALLOW(A) message for
> SSM JOIN_SOURCE_GROUP as the state should mimic the 'IN() to IN(A)' transition.
>
> The issue was exposed by commit a052517a8ff65 ("net/multicast: should not send
> source list records when have filter mode change"). Before this commit we will
> send both ALLOW(A) and TO_IN(A). After this commit we only send TO_IN(A).
>
> Fix it by adding a is_new key to clean the crcount when we add a new
> INCLUDE SSM group.
>
> Fixes: a052517a8ff65 ("net/multicast: should not send source list records when have filter mode change")
> Reviewed-by: Paolo Abeni <pabeni@redhat.com>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> include/linux/igmp.h | 2 +-
> include/net/ipv6.h | 2 +-
> net/ipv4/igmp.c | 27 ++++++++++++++++++++++++++-
> net/ipv4/ip_sockglue.c | 8 ++++++--
> net/ipv6/ipv6_sockglue.c | 4 +++-
> net/ipv6/mcast.c | 25 ++++++++++++++++++++++++-
> 6 files changed, 61 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/igmp.h b/include/linux/igmp.h
> index f823185..32cb02b 100644
> --- a/include/linux/igmp.h
> +++ b/include/linux/igmp.h
> @@ -112,7 +112,7 @@ extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
> extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
> extern void ip_mc_drop_socket(struct sock *sk);
> extern int ip_mc_source(int add, int omode, struct sock *sk,
> - struct ip_mreq_source *mreqs, int ifindex);
> + struct ip_mreq_source *mreqs, int ifindex, bool is_new);
> extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
> extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
> struct ip_msfilter __user *optval, int __user *optlen);
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 836f31a..754c5cb 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -1065,7 +1065,7 @@ struct group_source_req;
> struct group_filter;
>
> int ip6_mc_source(int add, int omode, struct sock *sk,
> - struct group_source_req *pgsr);
> + struct group_source_req *pgsr, bool is_new);
> int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf);
> int ip6_mc_msfget(struct sock *sk, struct group_filter *gsf,
> struct group_filter __user *optval, int __user *optlen);
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index b26a81a..8d6ecc3 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -2249,8 +2249,27 @@ int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr)
> }
> EXPORT_SYMBOL(ip_mc_leave_group);
>
> +static void ip_mc_clear_cr(struct in_device *in_dev, __be32 pmca)
> +{
> +#ifdef CONFIG_IP_MULTICAST
> + struct ip_mc_list *pmc;
> +
> + rcu_read_lock();
> + for_each_pmc_rcu(in_dev, pmc) {
> + if (pmca == pmc->multiaddr)
> + break;
> + }
> + if (pmc) {
> + spin_lock_bh(&pmc->lock);
> + pmc->crcount = 0;
> + spin_unlock_bh(&pmc->lock);
> + }
> + rcu_read_unlock();
> +#endif
> +}
> +
> int ip_mc_source(int add, int omode, struct sock *sk, struct
> - ip_mreq_source *mreqs, int ifindex)
> + ip_mreq_source *mreqs, int ifindex, bool is_new)
> {
> int err;
> struct ip_mreqn imr;
> @@ -2301,6 +2320,12 @@ int ip_mc_source(int add, int omode, struct sock *sk, struct
> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
> NULL, 0);
> pmc->sfmode = omode;
> + /* Based on RFC3376 5.1, for newly added INCLUDE SSM, we should
> + * not send filter-mode change record as the mode should be
> + * from IN() to IN(A).
> + */
> + if (is_new)
> + ip_mc_clear_cr(in_dev, mreqs->imr_multiaddr);
> }
>
> psl = rtnl_dereference(pmc->sflist);
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index 57bbb06..8d8c0cd 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -962,6 +962,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> case IP_DROP_SOURCE_MEMBERSHIP:
> {
> struct ip_mreq_source mreqs;
> + bool is_new = false;
> int omode, add;
>
> if (optlen != sizeof(struct ip_mreq_source))
> @@ -987,11 +988,12 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> break;
> omode = MCAST_INCLUDE;
> add = 1;
> + is_new = true;
> } else /* IP_DROP_SOURCE_MEMBERSHIP */ {
> omode = MCAST_INCLUDE;
> add = 0;
> }
> - err = ip_mc_source(add, omode, sk, &mreqs, 0);
> + err = ip_mc_source(add, omode, sk, &mreqs, 0, is_new);
> break;
> }
> case MCAST_JOIN_GROUP:
> @@ -1027,6 +1029,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> struct group_source_req greqs;
> struct ip_mreq_source mreqs;
> struct sockaddr_in *psin;
> + bool is_new = false;
> int omode, add;
>
> if (optlen != sizeof(struct group_source_req))
> @@ -1065,12 +1068,13 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> greqs.gsr_interface = mreq.imr_ifindex;
> omode = MCAST_INCLUDE;
> add = 1;
> + is_new = true;
> } else /* MCAST_LEAVE_SOURCE_GROUP */ {
> omode = MCAST_INCLUDE;
> add = 0;
> }
> err = ip_mc_source(add, omode, sk, &mreqs,
> - greqs.gsr_interface);
> + greqs.gsr_interface, is_new);
> break;
> }
> case MCAST_MSFILTER:
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 4d780c7..36e7c40 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -695,6 +695,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> case MCAST_UNBLOCK_SOURCE:
> {
> struct group_source_req greqs;
> + bool is_new = false;
> int omode, add;
>
> if (optlen < sizeof(struct group_source_req))
> @@ -725,11 +726,12 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> break;
> omode = MCAST_INCLUDE;
> add = 1;
> + is_new = true;
> } else /* MCAST_LEAVE_SOURCE_GROUP */ {
> omode = MCAST_INCLUDE;
> add = 0;
> }
> - retv = ip6_mc_source(add, omode, sk, &greqs);
> + retv = ip6_mc_source(add, omode, sk, &greqs, is_new);
> break;
> }
> case MCAST_MSFILTER:
> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> index 793159d..f508a1c 100644
> --- a/net/ipv6/mcast.c
> +++ b/net/ipv6/mcast.c
> @@ -315,8 +315,25 @@ void ipv6_sock_mc_close(struct sock *sk)
> rtnl_unlock();
> }
>
> +static void ip6_mc_clear_cr(struct inet6_dev *idev, const struct in6_addr *pmca)
> +{
> + struct ifmcaddr6 *pmc;
> +
> + read_lock_bh(&idev->lock);
> + for (pmc = idev->mc_list; pmc; pmc = pmc->next) {
> + if (ipv6_addr_equal(pmca, &pmc->mca_addr))
> + break;
> + }
> + if (pmc) {
> + spin_lock_bh(&pmc->mca_lock);
> + pmc->mca_crcount = 0;
> + spin_unlock_bh(&pmc->mca_lock);
> + }
> + read_unlock_bh(&idev->lock);
> +}
> +
> int ip6_mc_source(int add, int omode, struct sock *sk,
> - struct group_source_req *pgsr)
> + struct group_source_req *pgsr, bool is_new)
> {
> struct in6_addr *source, *group;
> struct ipv6_mc_socklist *pmc;
> @@ -365,6 +382,12 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
> ip6_mc_add_src(idev, group, omode, 0, NULL, 0);
> ip6_mc_del_src(idev, group, pmc->sfmode, 0, NULL, 0);
> pmc->sfmode = omode;
> + /* Based on RFC3810 6.1, for newly added INCLUDE SSM, we
> + * should not send filter-mode change record as the mode
> + * should be from IN() to IN(A).
> + */
> + if (is_new)
> + ip6_mc_clear_cr(idev, group);
> }
>
> write_lock(&pmc->sflock);
> --
> 2.5.5
>
^ permalink raw reply
* [PATCH iproute2-next v3] ip-xfrm: Add support for OUTPUT_MARK
From: Subash Abhinov Kasiviswanathan @ 2018-06-16 2:32 UTC (permalink / raw)
To: lorenzo, netdev, stephen, dsahern, steffen.klassert
Cc: Subash Abhinov Kasiviswanathan
This patch adds support for OUTPUT_MARK in xfrm state to exercise the
functionality added by kernel commit 077fbac405bf
("net: xfrm: support setting an output mark.").
Sample output-
(with mark and output-mark)
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x00004321 reqid 0 mode tunnel
replay-window 0 flag af-unspec
mark 0x10000/0x3ffff output-mark 0x20000
auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
(with mark only)
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x00004321 reqid 0 mode tunnel
replay-window 0 flag af-unspec
mark 0x10000/0x3ffff
auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
(with output-mark only)
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x00004321 reqid 0 mode tunnel
replay-window 0 flag af-unspec
output-mark 0x20000
auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
(no mark and output-mark)
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x00004321 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
v1->v2: Moved the XFRMA_OUTPUT_MARK print after XFRMA_MARK in
xfrm_xfrma_print() as mentioned by Lorenzo
v2->v3: Fix one help formatting error as mentioned by Lorenzo.
Keep mark and output-mark on the same line and add man page info as
mentioned by David.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
ip/ipxfrm.c | 17 ++++++++++++++++-
ip/xfrm_state.c | 9 +++++++++
man/man8/ip-xfrm.8 | 11 +++++++++++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index 12c2f72..17ab4ab 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -637,6 +637,13 @@ static void xfrm_tmpl_print(struct xfrm_user_tmpl *tmpls, int len,
}
}
+static void xfrm_output_mark_print(struct rtattr *tb[], FILE *fp)
+{
+ __u32 output_mark = rta_getattr_u32(tb[XFRMA_OUTPUT_MARK]);
+
+ fprintf(fp, "output-mark 0x%x", output_mark);
+}
+
int xfrm_parse_mark(struct xfrm_mark *mark, int *argcp, char ***argvp)
{
int argc = *argcp;
@@ -677,7 +684,15 @@ void xfrm_xfrma_print(struct rtattr *tb[], __u16 family,
struct rtattr *rta = tb[XFRMA_MARK];
struct xfrm_mark *m = RTA_DATA(rta);
- fprintf(fp, "\tmark %#x/%#x", m->v, m->m);
+ fprintf(fp, "\tmark %#x/%#x ", m->v, m->m);
+
+ if (tb[XFRMA_OUTPUT_MARK])
+ xfrm_output_mark_print(tb, fp);
+ fprintf(fp, "%s", _SL_);
+ } else if (tb[XFRMA_OUTPUT_MARK]) {
+ fprintf(fp, "\t");
+
+ xfrm_output_mark_print(tb, fp);
fprintf(fp, "%s", _SL_);
}
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 85d959c..913e9fa 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -61,6 +61,7 @@ static void usage(void)
fprintf(stderr, " [ flag FLAG-LIST ] [ sel SELECTOR ] [ LIMIT-LIST ] [ encap ENCAP ]\n");
fprintf(stderr, " [ coa ADDR[/PLEN] ] [ ctx CTX ] [ extra-flag EXTRA-FLAG-LIST ]\n");
fprintf(stderr, " [ offload [dev DEV] dir DIR ]\n");
+ fprintf(stderr, " [ output-mark OUTPUT-MARK ]\n");
fprintf(stderr, "Usage: ip xfrm state allocspi ID [ mode MODE ] [ mark MARK [ mask MASK ] ]\n");
fprintf(stderr, " [ reqid REQID ] [ seq SEQ ] [ min SPI max SPI ]\n");
fprintf(stderr, "Usage: ip xfrm state { delete | get } ID [ mark MARK [ mask MASK ] ]\n");
@@ -322,6 +323,7 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
struct xfrm_user_sec_ctx sctx;
char str[CTX_BUF_SIZE];
} ctx = {};
+ __u32 output_mark = 0;
while (argc > 0) {
if (strcmp(*argv, "mode") == 0) {
@@ -437,6 +439,10 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
invarg("value after \"offload dir\" is invalid", *argv);
is_offload = false;
}
+ } else if (strcmp(*argv, "output-mark") == 0) {
+ NEXT_ARG();
+ if (get_u32(&output_mark, *argv, 0))
+ invarg("value after \"output-mark\" is invalid", *argv);
} else {
/* try to assume ALGO */
int type = xfrm_algotype_getbyname(*argv);
@@ -720,6 +726,9 @@ static int xfrm_state_modify(int cmd, unsigned int flags, int argc, char **argv)
}
}
+ if (output_mark)
+ addattr32(&req.n, sizeof(req.buf), XFRMA_OUTPUT_MARK, output_mark);
+
if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0)
exit(1);
diff --git a/man/man8/ip-xfrm.8 b/man/man8/ip-xfrm.8
index 988cc6a..839e06a 100644
--- a/man/man8/ip-xfrm.8
+++ b/man/man8/ip-xfrm.8
@@ -59,6 +59,8 @@ ip-xfrm \- transform configuration
.IR CTX " ]"
.RB "[ " extra-flag
.IR EXTRA-FLAG-LIST " ]"
+.RB "[ " output-mark
+.IR OUTPUT-MARK " ]"
.ti -8
.B "ip xfrm state allocspi"
@@ -537,6 +539,15 @@ encapsulates packets with protocol
.RI "using source port " SPORT ", destination port " DPORT
.RI ", and original address " OADDR "."
+.TP
+.I MARK
+used to match xfrm policies and states
+
+.TP
+.I OUTPUT-MARK
+used to set the output mark to influence the routing
+of the packets emitted by the state
+
.sp
.PP
.TS
--
1.9.1
^ permalink raw reply related
* pull-request: bpf 2018-06-16
From: Daniel Borkmann @ 2018-06-15 23:06 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix a panic in devmap handling in generic XDP where return type
of __devmap_lookup_elem() got changed recently but generic XDP
code missed the related update, from Toshiaki.
2) Fix a freeze when BPF progs are loaded that include BPF to BPF
calls when JIT is enabled where we would later bail out via error
path w/o dropping kallsyms, and another one to silence syzkaller
splats from locking prog read-only, from Daniel.
3) Fix a bug in test_offloads.py BPF selftest which must not assume
that the underlying system have no BPF progs loaded prior to test,
and one in bpftool to fix accuracy of program load time, from Jakub.
4) Fix a bug in bpftool's probe for availability of the bpf(2)
BPF_TASK_FD_QUERY subcommand, from Yonghong.
5) Fix a regression in AF_XDP's XDP_SKB receive path where queue
id check got erroneously removed, from Björn.
6) Fix missing state cleanup in BPF's xfrm tunnel test, from William.
7) Check tunnel type more accurately in BPF's tunnel collect metadata
kselftest, from Jian.
8) Fix missing Kconfig fragments for BPF kselftests, from Anders.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 6892286e9c09925780fe2cb6db3585b56b71fe8e:
tcp: Do not reload skb pointer after skb_gro_receive(). (2018-06-11 20:00:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 6d5fc1957989266006db6ef3dfb9159b42cf0189:
xdp: Fix handling of devmap in generic XDP (2018-06-15 23:47:15 +0200)
----------------------------------------------------------------
Alexei Starovoitov (1):
Merge branch 'bpf-fixes'
Anders Roxell (1):
selftests: bpf: config: add config fragments
Björn Töpel (1):
xsk: re-add queue id check for XDP_SKB path
Daniel Borkmann (3):
Merge branch 'bpf-misc-fixes'
bpf: fix panic in prog load calls cleanup
bpf: reject any prog that failed read-only lock
Jakub Kicinski (2):
tools: bpftool: improve accuracy of load time
selftests/bpf: test offloads even with BPF programs present
Jian Wang (1):
bpf, selftest: check tunnel type more accurately
Toshiaki Makita (1):
xdp: Fix handling of devmap in generic XDP
William Tu (1):
bpf, selftests: delete xfrm tunnel when test exits.
Yonghong Song (1):
tools/bpftool: fix a bug in bpftool perf
include/linux/bpf.h | 12 +++++
include/linux/filter.h | 79 +++++++++++++++++++++--------
kernel/bpf/core.c | 69 ++++++++++++++++++++++---
kernel/bpf/devmap.c | 14 +++++
kernel/bpf/syscall.c | 12 ++---
net/core/filter.c | 21 ++------
net/xdp/xsk.c | 3 ++
tools/bpf/bpftool/perf.c | 5 +-
tools/bpf/bpftool/prog.c | 4 +-
tools/testing/selftests/bpf/config | 10 ++++
tools/testing/selftests/bpf/test_offload.py | 12 ++++-
tools/testing/selftests/bpf/test_tunnel.sh | 26 +++++-----
12 files changed, 195 insertions(+), 72 deletions(-)
^ permalink raw reply
* Re: [PATCH bpf v2] xdp: Fix handling of devmap in generic XDP
From: Daniel Borkmann @ 2018-06-15 22:27 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Toshiaki Makita; +Cc: Alexei Starovoitov, netdev
In-Reply-To: <20180614113302.30472d4e@redhat.com>
On 06/14/2018 11:33 AM, Jesper Dangaard Brouer wrote:
> On Thu, 14 Jun 2018 18:00:22 +0900
> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>> On 2018/06/14 17:49, Jesper Dangaard Brouer wrote:
>>> On Thu, 14 Jun 2018 11:07:42 +0900
>>> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>
>>>> Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
>>>> the return value type of __devmap_lookup_elem() from struct net_device *
>>>> to struct bpf_dtab_netdev * but forgot to modify generic XDP code
>>>> accordingly.
>>>> Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
>>>> net_device is expected, then skb->dev was set to invalid value.
>>>>
>>>> v2:
>>>> - Fix compiler warning without CONFIG_BPF_SYSCALL.
>>>>
>>>> Fixes: 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue")
>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>
>>> Thanks for catching this!
>>>
>>> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied to bpf, thanks Toshiaki!
^ permalink raw reply
* Re: KASAN: use-after-free Write in free_htab_elem
From: Daniel Borkmann @ 2018-06-15 21:42 UTC (permalink / raw)
To: syzbot, ast, linux-kernel, netdev, syzkaller-bugs, john.fastabend
In-Reply-To: <000000000000394fd9056eb28b51@google.com>
On 06/15/2018 08:40 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f0dc7f9c6dd9 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11dad428400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=fa9c20c48788d1c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=ce67d3e4fa77eedee964
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ce67d3e4fa77eedee964@syzkaller.appspotmail.com
(John, if you do the respin would be great to double check all the open
reports on sock{map,hash} and annotate with syzkaller Reported-by tags.
Looks like on https://syzkaller.appspot.com/ we have 5 in total that may
be all related to your series of fixes you have. 2 of the reports have
wrong syz-fix tag, though, so we should clarify tracking them a bit. Thx)
> ==================================================================
> BUG: KASAN: use-after-free in atomic_dec include/asm-generic/atomic-instrumented.h:114 [inline]
> BUG: KASAN: use-after-free in free_htab_elem+0x23/0x40 kernel/bpf/sockmap.c:224
> Write of size 4 at addr ffff8801b3dce648 by task syz-executor1/8114
>
> CPU: 0 PID: 8114 Comm: syz-executor1 Not tainted 4.17.0+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
> kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
> atomic_dec include/asm-generic/atomic-instrumented.h:114 [inline]
> free_htab_elem+0x23/0x40 kernel/bpf/sockmap.c:224
> bpf_tcp_close+0x8c1/0xf80 kernel/bpf/sockmap.c:273
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:603
> sock_close+0x19/0x20 net/socket.c:1186
> __fput+0x353/0x890 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1e4/0x290 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1aee/0x2730 kernel/exit.c:865
> do_group_exit+0x16f/0x430 kernel/exit.c:968
> get_signal+0x886/0x1960 kernel/signal.c:2468
> do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2cf/0x360 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x455b29
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f3bbf323ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: fffffffffffffe00 RBX: 000000000072bf78 RCX: 0000000000455b29
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bf78
> RBP: 000000000072bf78 R08: 0000000000000000 R09: 000000000072bf50
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffd7addc2cf R14: 00007f3bbf3249c0 R15: 0000000000000001
>
> Allocated by task 8104:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
> kmalloc include/linux/slab.h:513 [inline]
> kzalloc include/linux/slab.h:706 [inline]
> sock_hash_alloc+0x20d/0x6a0 kernel/bpf/sockmap.c:2003
> find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
> map_create+0x393/0x1010 kernel/bpf/syscall.c:453
> __do_sys_bpf kernel/bpf/syscall.c:2351 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2328 [inline]
> __x64_sys_bpf+0x303/0x510 kernel/bpf/syscall.c:2328
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 2131:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xd9/0x260 mm/slab.c:3813
> sock_hash_free+0x51c/0x6e0 kernel/bpf/sockmap.c:2098
> bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:262
> process_one_work+0xc64/0x1b70 kernel/workqueue.c:2153
> worker_thread+0x181/0x13a0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> The buggy address belongs to the object at ffff8801b3dce540
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 264 bytes inside of
> 512-byte region [ffff8801b3dce540, ffff8801b3dce740)
> The buggy address belongs to the page:
> page:ffffea0006cf7380 count:1 mapcount:0 mapping:ffff8801da800940 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffffea0006caccc8 ffffea0006f57b08 ffff8801da800940
> raw: 0000000000000000 ffff8801b3dce040 0000000100000006 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801b3dce500: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8801b3dce580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff8801b3dce600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801b3dce680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801b3dce700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH v3 16/27] docs: Fix more broken references
From: Stephen Boyd @ 2018-06-15 21:42 UTC (permalink / raw)
To: Linux Doc Mailing List, Mauro Carvalho Chehab
Cc: linux-hwmon, devicetree, alsa-devel, linux-samsung-soc,
linux-mediatek, Jonathan Corbet, netdev, linux-pm, linux-mmc,
linux-kernel, dri-devel, Mauro Carvalho Chehab, linux-rockchip,
linux-usb, intel-wired-lan, Mauro Carvalho Chehab, linux-fsdevel,
linux-clk, linux-arm-kernel
In-Reply-To: <e1bf52a721005b2017434acc54ec5ddc152d6fe4.1528990947.git.mchehab+samsung@kernel.org>
Quoting Mauro Carvalho Chehab (2018-06-14 09:09:01)
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../devicetree/bindings/clock/st/st,clkgen.txt | 8 ++++----
> .../devicetree/bindings/clock/ti/gate.txt | 2 +-
> .../devicetree/bindings/clock/ti/interface.txt | 2 +-
Acked-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH bpf 0/2] Two bpf fixes
From: Daniel Borkmann @ 2018-06-15 21:16 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: ast, netdev
In-Reply-To: <20180615193143.6dyizhdq345lgwf2@ast-mbp.dhcp.thefacebook.com>
On 06/15/2018 09:31 PM, Alexei Starovoitov wrote:
> On Fri, Jun 15, 2018 at 02:30:46AM +0200, Daniel Borkmann wrote:
>> First one is a panic I ran into while testing the second
>> one where we got several syzkaller reports. Series here
>> fixes both.
>>
>> Thanks!
>
> Applied, thanks.
>
> The second patch looks dubious to me though.
> Nothing in the kernel tree checks the return value of set_memory_ro()
> and my understanding that it can fail only when part of huge page
> is being marked and pages have to be split. In bpf case I don't think
> it's ever the case, so the patch is silencing purely theoretical
> syzbot splat that can happen with artificial error injection.
> I bet we're still going to see this splat in set_memory_rw.
> imo the better fix would have been to drop WARN_ON from both.
I think it should be pretty unlikely to trigger them in real world,
we have them in place for ~4yrs now as fixed-builtin and I haven't
heard any issues with it so far aside from the syzkaller splats which
triggered it with a total of 54 times via fault injection, fwiw.
Dropping second warn doesn't make sense actually since if we ever
run into it there's no option to recover, so we would want to know
where it breaks first.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
From: David Woodhouse @ 2018-06-15 20:57 UTC (permalink / raw)
To: Kevin Darbyshire-Bryant
Cc: Eric Dumazet, Elena Reshetova, netdev@vger.kernel.org,
Krzysztof Mazur, 3chas3@gmail.com, Mathias Kresin
In-Reply-To: <32BB74EA-234B-484F-B981-9F3D0027FD82@darbyshire-bryant.me.uk>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
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@darbyshire-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?
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]
^ permalink raw reply
* Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
From: Kevin Darbyshire-Bryant @ 2018-06-15 20:49 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Elena Reshetova, netdev@vger.kernel.org,
Krzysztof Mazur, 3chas3@gmail.com, Mathias Kresin
In-Reply-To: <00520334446ffa4671513bb42ebeeecfab4107e7.camel@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 7853 bytes --]
> On 15 Jun 2018, at 21:00, David Woodhouse <dwmw2@infradead.org> wrote:
>
> 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.
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@darbyshire-bryant.me.uk>
>
>
> From 3368eaeb0a2f09138894dde0f26f879e5228005a Mon Sep 17 00:00:00 2001
> From: David Woodhouse <dwmw2@infradead.org>
> 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 <dwmw2@infradead.org>
> ---
> 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 0c27515d2cf6..8124815eb121 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 int acct_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, &sk_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 4e111196f902..bc21f8e8daf2 100644
> --- a/net/atm/br2684.c
> +++ b/net/atm/br2684.c
> @@ -252,8 +252,7 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
>
> ATM_SKB(skb)->vcc = atmvcc = brvcc->atmvcc;
> pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, atmvcc, atmvcc->dev);
> - refcount_add(skb->truesize, &sk_atm(atmvcc)->sk_wmem_alloc);
> - ATM_SKB(skb)->atm_options = atmvcc->atm_options;
> + atm_account_tx(atmvcc, skb);
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += skb->len;
>
> diff --git a/net/atm/clip.c b/net/atm/clip.c
> index 65f706e4344c..60920a42f640 100644
> --- a/net/atm/clip.c
> +++ b/net/atm/clip.c
> @@ -381,8 +381,7 @@ static netdev_tx_t clip_start_xmit(struct sk_buff *skb,
> memcpy(here, llc_oui, sizeof(llc_oui));
> ((__be16 *) here)[3] = skb->protocol;
> }
> - refcount_add(skb->truesize, &sk_atm(vcc)->sk_wmem_alloc);
> - ATM_SKB(skb)->atm_options = vcc->atm_options;
> + atm_account_tx(vcc, skb);
> entry->vccs->last_use = jiffies;
> pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, vcc, vcc->dev);
> old = xchg(&entry->vccs->xoff, 1); /* assume XOFF ... */
> diff --git a/net/atm/common.c b/net/atm/common.c
> index 8a4f99114cd2..9e812c782a37 100644
> --- a/net/atm/common.c
> +++ b/net/atm/common.c
> @@ -630,10 +630,9 @@ int vcc_sendmsg(struct socket *sock, struct msghdr *m, size_t size)
> goto out;
> }
> pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
> - refcount_add(skb->truesize, &sk->sk_wmem_alloc);
> + atm_account_tx(vcc, skb);
>
> skb->dev = NULL; /* for paths shared with net_device interfaces */
> - ATM_SKB(skb)->atm_options = vcc->atm_options;
> if (!copy_from_iter_full(skb_put(skb, size), size, &m->msg_iter)) {
> kfree_skb(skb);
> error = -EFAULT;
> diff --git a/net/atm/lec.c b/net/atm/lec.c
> index a3d93a1bb133..d7cc165e24e0 100644
> --- a/net/atm/lec.c
> +++ b/net/atm/lec.c
> @@ -179,9 +179,8 @@ lec_send(struct atm_vcc *vcc, struct sk_buff *skb)
> struct net_device *dev = skb->dev;
>
> ATM_SKB(skb)->vcc = vcc;
> - ATM_SKB(skb)->atm_options = vcc->atm_options;
> + atm_account_tx(vcc, skb);
>
> - refcount_add(skb->truesize, &sk_atm(vcc)->sk_wmem_alloc);
> if (vcc->send(vcc, skb) < 0) {
> dev->stats.tx_dropped++;
> return;
> diff --git a/net/atm/mpc.c b/net/atm/mpc.c
> index 5677147209e8..db9a1838687c 100644
> --- a/net/atm/mpc.c
> +++ b/net/atm/mpc.c
> @@ -555,8 +555,7 @@ static int send_via_shortcut(struct sk_buff *skb, struct mpoa_client *mpc)
> sizeof(struct llc_snap_hdr));
> }
>
> - refcount_add(skb->truesize, &sk_atm(entry->shortcut)->sk_wmem_alloc);
> - ATM_SKB(skb)->atm_options = entry->shortcut->atm_options;
> + atm_account_tx(entry->shortcut, skb);
> entry->shortcut->send(entry->shortcut, skb);
> entry->packets_fwded++;
> mpc->in_ops->put(entry);
> diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
> index 21d9d341a619..af8c4b38b746 100644
> --- a/net/atm/pppoatm.c
> +++ b/net/atm/pppoatm.c
> @@ -350,8 +350,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
> return 1;
> }
>
> - refcount_add(skb->truesize, &sk_atm(ATM_SKB(skb)->vcc)->sk_wmem_alloc);
> - ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
> + atm_account_tx(vcc, skb);
> pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
> skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
> ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
> diff --git a/net/atm/raw.c b/net/atm/raw.c
> index ee10e8d46185..b3ba44aab0ee 100644
> --- a/net/atm/raw.c
> +++ b/net/atm/raw.c
> @@ -35,8 +35,8 @@ static void atm_pop_raw(struct atm_vcc *vcc, struct sk_buff *skb)
> struct sock *sk = sk_atm(vcc);
>
> pr_debug("(%d) %d -= %d\n",
> - vcc->vci, sk_wmem_alloc_get(sk), skb->truesize);
> - WARN_ON(refcount_sub_and_test(skb->truesize, &sk->sk_wmem_alloc));
> + vcc->vci, sk_wmem_alloc_get(sk), ATM_SKB(skb)->acct_truesize);
> + WARN_ON(refcount_sub_and_test(ATM_SKB(skb)->acct_truesize, &sk->sk_wmem_alloc));
> dev_kfree_skb_any(skb);
> sk->sk_write_space(sk);
> }
> --
> 2.17.0
>
> --
> dwmw2
Tested-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] leds: drop led_trigger_rename_static()
From: Jacek Anaszewski @ 2018-06-15 20:49 UTC (permalink / raw)
To: Uwe Kleine-König, Pavel Machek, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, netdev
Cc: linux-leds, linux-can, kernel
In-Reply-To: <20180518085333.26187-1-u.kleine-koenig@pengutronix.de>
Hi,
I need can or net maintainer's ack for merging this
set via LED tree. It's been awaiting feedback for a few weeks
now and it is blocking another set depending on it.
On 05/18/2018 10:53 AM, Uwe Kleine-König wrote:
> Hello,
>
> initially I prepared a patch to fix the broken things in
> led_trigger_rename_static(), but given that there is only the
> can-trigger driver that makes use of this function and the netdev
> trigger implements a super set of the can-trigger, removing both the
> can-trigger and the broken function seems sensible.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (2):
> can: drop led trigger support
> leds: remove unused function led_trigger_rename_static()
>
> drivers/leds/led-triggers.c | 13 ---
> drivers/net/can/Kconfig | 11 --
> drivers/net/can/Makefile | 2 -
> drivers/net/can/at91_can.c | 10 --
> drivers/net/can/c_can/c_can.c | 11 --
> drivers/net/can/dev.c | 5 -
> drivers/net/can/flexcan.c | 8 --
> drivers/net/can/ifi_canfd/ifi_canfd.c | 9 --
> drivers/net/can/led.c | 143 --------------------------
> drivers/net/can/m_can/m_can.c | 9 --
> drivers/net/can/rcar/rcar_can.c | 8 --
> drivers/net/can/rcar/rcar_canfd.c | 7 --
> drivers/net/can/rx-offload.c | 2 -
> drivers/net/can/sja1000/sja1000.c | 15 +--
> drivers/net/can/spi/hi311x.c | 8 --
> drivers/net/can/spi/mcp251x.c | 10 --
> drivers/net/can/sun4i_can.c | 7 --
> drivers/net/can/ti_hecc.c | 9 --
> drivers/net/can/usb/mcba_usb.c | 7 --
> drivers/net/can/usb/usb_8dev.c | 11 --
> drivers/net/can/xilinx_can.c | 9 --
> include/linux/can/dev.h | 10 --
> include/linux/can/led.h | 54 ----------
> include/linux/leds.h | 18 ----
> 24 files changed, 1 insertion(+), 395 deletions(-)
> delete mode 100644 drivers/net/can/led.c
> delete mode 100644 include/linux/can/led.h
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox