* Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: David Miller @ 2017-04-25 14:36 UTC (permalink / raw)
To: al.kochet
Cc: f.fainelli, netdev, linux-kernel, sergei.shtylyov, rogerq,
madalin.bucur
In-Reply-To: <1492686004-30527-2-git-send-email-al.kochet@gmail.com>
From: Alexander Kochetkov <al.kochet@gmail.com>
Date: Thu, 20 Apr 2017 14:00:04 +0300
> The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet
> cable was plugged before the Ethernet interface was brought up.
>
> The patch trigger PHY state machine to update link state if PHY was requested to
> do auto-negotiation and auto-negotiation complete flag already set.
>
> During power-up cycle the PHY do auto-negotiation, generate interrupt and set
> auto-negotiation complete flag. Interrupt is handled by PHY state machine but
> doesn't update link state because PHY is in PHY_READY state. After some time
> MAC bring up, start and request PHY to do auto-negotiation. If there are no new
> settings to advertise genphy_config_aneg() doesn't start PHY auto-negotiation.
> PHY continue to stay in auto-negotiation complete state and doesn't fire
> interrupt. At the same time PHY state machine expect that PHY started
> auto-negotiation and is waiting for interrupt from PHY and it won't get it.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> Cc: stable <stable@vger.kernel.org> # v4.9+
So... what are we doing here?
My understanding is that this should fix the same problem that commit
99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
negotiation on startup") fixed and that this micrel commit should thus
be reverted to improve MAC startup times which regressed.
Florian, any guidance?
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] virtio-net: transmit napi
From: Willem de Bruijn @ 2017-04-25 14:32 UTC (permalink / raw)
To: Jason Wang
Cc: Network Development, Willem de Bruijn, virtualization,
David Miller, Michael S. Tsirkin
In-Reply-To: <2c5491c0-4473-75d1-fa0f-a0dbd4dc626d@redhat.com>
On Tue, Apr 25, 2017 at 4:36 AM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2017年04月25日 01:49, Willem de Bruijn wrote:
>>
>> @@ -1371,8 +1419,10 @@ static int virtnet_close(struct net_device *dev)
>> /* Make sure refill_work doesn't re-enable napi! */
>> cancel_delayed_work_sync(&vi->refill);
>> - for (i = 0; i < vi->max_queue_pairs; i++)
>> + for (i = 0; i < vi->max_queue_pairs; i++) {
>> napi_disable(&vi->rq[i].napi);
>> + napi_disable(&vi->sq[i].napi);
>> + }
>
>
> Looks like this will wait for ever if napi_tx is false because we never
> enable the NAPI so we will wait for NAPI_STATE_SCHED to be cleared.
Indeed, thanks! I'll send a fix.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] usb: plusb: Add support for PL-27A1
From: David Miller @ 2017-04-25 14:29 UTC (permalink / raw)
To: roed-4Uo9UdwAbX8
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170420100410.3296-1-roed-4Uo9UdwAbX8@public.gmane.org>
From: Roman Spychała <roed-4Uo9UdwAbX8@public.gmane.org>
Date: Thu, 20 Apr 2017 12:04:10 +0200
> From: Roman Spychała <roed-4Uo9UdwAbX8@public.gmane.org>
>
> This patch adds support for the PL-27A1 by adding the appropriate
> USB ID's. This chip is used in the goobay Active USB 3.0 Data Link
> and Unitek Y-3501 cables.
>
> Signed-off-by: Roman Spychała <roed-4Uo9UdwAbX8@public.gmane.org>
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net-next 3/3] samples/bpf: check before defining offsetof
From: David Laight @ 2017-04-25 14:27 UTC (permalink / raw)
To: 'Daniel Borkmann', Alexander Alemayhu,
netdev@vger.kernel.org
Cc: ast@fb.com
In-Reply-To: <58FE0E96.9020403@iogearbox.net>
From: Daniel Borkmann
> Sent: 24 April 2017 15:41
> To: Alexander Alemayhu; netdev@vger.kernel.org
> Cc: ast@fb.com
> Subject: Re: [PATCH net-next 3/3] samples/bpf: check before defining offsetof
>
> On 04/24/2017 03:31 PM, Alexander Alemayhu wrote:
> > Fixes the following warning
> >
> > samples/bpf/test_lru_dist.c:28:0: warning: "offsetof" redefined
> > #define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
> >
> > In file included from ./tools/lib/bpf/bpf.h:25:0,
> > from samples/bpf/libbpf.h:5,
> > from samples/bpf/test_lru_dist.c:24:
> > /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include/stddef.h:417:0: note: this is the location of the
> previous definition
> > #define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
> >
> > Signed-off-by: Alexander Alemayhu <alexander@alemayhu.com>
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Isn't the correct fix to include stddef.h ?
David
^ permalink raw reply
* [PATCH v3 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: Jason A. Donenfeld @ 2017-04-25 14:21 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425141609.28459-1-Jason@zx2c4.com>
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
Sorry for the completely stupid amount of churn - v1,v2,v3 in the span of
two minutes. It's just that after noticing first that nsg needs to be checked,
I also noticed something a bit worse: that there was a bug (exploitable?) where
if skb_to_sgvec was called with empty values, there would be an out-of-bounds
write into sg[0 - 1]. So, this third (and hopefully final!) patch fixes that
bug while we're at it.
net/core/skbuff.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f86bf69cfb8d..d103134deddb 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3489,7 +3489,9 @@ void __init skb_init(void)
* @len: Length of buffer space to be mapped
*
* Fill the specified scatter-gather list with mappings/pointers into a
- * region of the buffer space attached to a socket buffer.
+ * region of the buffer space attached to a socket buffer. Returns either
+ * the number of scatterlist items used, or -EMSGSIZE if the contents
+ * could not fit.
*/
static int
__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
@@ -3512,6 +3514,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
int end;
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
WARN_ON(start > offset + len);
end = start + skb_frag_size(&skb_shinfo(skb)->frags[i]);
@@ -3535,6 +3540,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
WARN_ON(start > offset + len);
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
end = start + frag_iter->len;
if ((copy = end - offset) > 0) {
if (copy > len)
@@ -3581,6 +3589,9 @@ int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int le
{
int nsg = __skb_to_sgvec(skb, sg, offset, len);
+ if (nsg <= 0)
+ return nsg;
+
sg_mark_end(&sg[nsg - 1]);
return nsg;
--
2.12.2
^ permalink raw reply related
* Re: [RFC 3/4] nfp: make use of extended ack message reporting
From: David Miller @ 2017-04-25 14:20 UTC (permalink / raw)
To: jhs
Cc: jakub.kicinski, netdev, johannes, dsa, daniel, alexei.starovoitov,
bblanco, john.fastabend, kubakici, oss-drivers
In-Reply-To: <9765d004-de19-7cf2-fcfc-1d2e72cded43@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue, 25 Apr 2017 08:42:32 -0400
> So are we going to standardize these strings?
No.
> i.e what if some user has written a bash script that depends on this
> string and it gets changed later.
They can't do that.
It's free form extra information an application may or not provide
to the user when the kernel emits it.
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: remove insecure_max_entries param
From: Florian Westphal @ 2017-04-25 14:17 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20170425132837.GA25657@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Apr 25, 2017 at 01:23:56PM +0200, Florian Westphal wrote:
> >
> > What extra cost?
> >
> > The only change is that ht->nelems has to be right-shifted by one,
> > I don't think that warrants extra space in struct rhashtable, its
> > already way too large (I think we can reduce its size further).
>
> I see at least one hole on 64-bit which means that you can fit
> it into struct rhashtable for free.
I'd rather close that hole by removing more stuff from rhastable and
rhashtable_params structs instead.
F.e. why do we need to have two key_len (one in params, one in
struct rhashtable)?
Or why does rhashtable use size_t in rhashtable_params to e.g. store
a key offset? Just using 'unsigned int' instead would shrink
rhashtable_params by 16 bytes.
I'd have less of an issue with this if we'd be talking about
something computationally expensive, but this is about storing
an extra value inside a struct just to avoid one "shr" in insert path...
^ permalink raw reply
* [PATCH v2 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: Jason A. Donenfeld @ 2017-04-25 14:16 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425140809.23881-1-Jason@zx2c4.com>
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
net/core/skbuff.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f86bf69cfb8d..7ed2cdf54c0a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3489,7 +3489,9 @@ void __init skb_init(void)
* @len: Length of buffer space to be mapped
*
* Fill the specified scatter-gather list with mappings/pointers into a
- * region of the buffer space attached to a socket buffer.
+ * region of the buffer space attached to a socket buffer. Returns either
+ * the number of scatterlist items used, or -EMSGSIZE if the contents
+ * could not fit.
*/
static int
__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
@@ -3512,6 +3514,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
int end;
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
WARN_ON(start > offset + len);
end = start + skb_frag_size(&skb_shinfo(skb)->frags[i]);
@@ -3535,6 +3540,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
WARN_ON(start > offset + len);
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
end = start + frag_iter->len;
if ((copy = end - offset) > 0) {
if (copy > len)
@@ -3581,6 +3589,9 @@ int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int le
{
int nsg = __skb_to_sgvec(skb, sg, offset, len);
+ if (nsg < 0)
+ return nsg;
+
sg_mark_end(&sg[nsg - 1]);
return nsg;
--
2.12.2
^ permalink raw reply related
* admin
From: administrador @ 2017-04-25 13:16 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: Ar..No,hat2rq7hs;z.Ar
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* [PATCH 5/5] virtio_net: check return value of skb_to_sgvec always
From: Jason A. Donenfeld @ 2017-04-25 14:08 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425140809.23881-1-Jason@zx2c4.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/net/virtio_net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f36584616e7d..1709fd0b4bf7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1081,7 +1081,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
struct virtio_net_hdr_mrg_rxbuf *hdr;
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
struct virtnet_info *vi = sq->vq->vdev->priv;
- unsigned num_sg;
+ int num_sg;
unsigned hdr_len = vi->hdr_len;
bool can_push;
@@ -1114,6 +1114,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
sg_set_buf(sq->sg, hdr, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
}
+ if (unlikely(num_sg < 0))
+ return num_sg;
return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
}
--
2.12.2
^ permalink raw reply related
* [PATCH 3/5] rxrpc: check return value of skb_to_sgvec always
From: Jason A. Donenfeld @ 2017-04-25 14:08 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425140809.23881-1-Jason@zx2c4.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
net/rxrpc/rxkad.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 4374e7b9c7bf..dcf46c9c3ece 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -229,7 +229,9 @@ static int rxkad_secure_packet_encrypt(const struct rxrpc_call *call,
len &= ~(call->conn->size_align - 1);
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, 0, len);
+ err = skb_to_sgvec(skb, sg, 0, len);
+ if (unlikely(err < 0))
+ goto out;
skcipher_request_set_crypt(req, sg, sg, len, iv.x);
crypto_skcipher_encrypt(req);
@@ -342,7 +344,8 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb,
goto nomem;
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, offset, 8);
+ if (unlikely(skb_to_sgvec(skb, sg, offset, 8) < 0))
+ goto nomem;
/* start the decryption afresh */
memset(&iv, 0, sizeof(iv));
@@ -429,7 +432,8 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
}
sg_init_table(sg, nsg);
- skb_to_sgvec(skb, sg, offset, len);
+ if (unlikely(skb_to_sgvec(skb, sg, offset, len) < 0))
+ goto nomem;
/* decrypt from the session key */
token = call->conn->params.key->payload.data[0];
--
2.12.2
^ permalink raw reply related
* [PATCH 4/5] macsec: check return value of skb_to_sgvec always
From: Jason A. Donenfeld @ 2017-04-25 14:08 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425140809.23881-1-Jason@zx2c4.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/net/macsec.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index dbab05afcdbe..d846f42b99ec 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -733,7 +733,12 @@ static struct sk_buff *macsec_encrypt(struct sk_buff *skb,
macsec_fill_iv(iv, secy->sci, pn);
sg_init_table(sg, MAX_SKB_FRAGS + 1);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ macsec_txsa_put(tx_sa);
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (tx_sc->encrypt) {
int len = skb->len - macsec_hdr_len(sci_present) -
@@ -937,7 +942,11 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
macsec_fill_iv(iv, sci, ntohl(hdr->packet_number));
sg_init_table(sg, MAX_SKB_FRAGS + 1);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (hdr->tci_an & MACSEC_TCI_E) {
/* confidentiality: ethernet + macsec header
--
2.12.2
^ permalink raw reply related
* [PATCH 2/5] ipsec: check return value of skb_to_sgvec always
From: Jason A. Donenfeld @ 2017-04-25 14:08 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
In-Reply-To: <20170425140809.23881-1-Jason@zx2c4.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
net/ipv4/ah4.c | 8 ++++++--
net/ipv4/esp4.c | 30 ++++++++++++++++++++----------
net/ipv6/ah6.c | 8 ++++++--
net/ipv6/esp6.c | 31 +++++++++++++++++++++----------
4 files changed, 53 insertions(+), 24 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 22377c8ff14b..e8f862358518 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -220,7 +220,9 @@ static int ah_output(struct xfrm_state *x, struct sk_buff *skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -393,7 +395,9 @@ static int ah_input(struct xfrm_state *x, struct sk_buff *skb)
skb_push(skb, ihl);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b1e24446e297..42cb09cc8533 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -360,9 +360,13 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
esph = esp_output_set_extra(skb, esph, extra);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0)) {
+ spin_unlock_bh(&x->lock);
+ goto error;
+ }
allocsize = ALIGN(skb->data_len, L1_CACHE_BYTES);
@@ -381,11 +385,13 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
pfrag->offset = pfrag->offset + allocsize;
sg_init_table(dsg, skb_shinfo(skb)->nr_frags + 1);
- skb_to_sgvec(skb, dsg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, dsg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
spin_unlock_bh(&x->lock);
+ if (unlikely(err < 0))
+ goto error;
goto skip_cow2;
}
@@ -422,9 +428,11 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
esph = esp_output_set_extra(skb, esph, extra);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0))
+ goto error;
skip_cow2:
if ((x->props.flags & XFRM_STATE_ESN))
@@ -658,7 +666,9 @@ static int esp_input(struct xfrm_state *x, struct sk_buff *skb)
esp_input_set_header(skb, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ err = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out;
skb->ip_summed = CHECKSUM_NONE;
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index dda6035e3b84..755f38271dd5 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -423,7 +423,9 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff *skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -606,7 +608,9 @@ static int ah6_input(struct xfrm_state *x, struct sk_buff *skb)
ip6h->hop_limit = 0;
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index ff54faa75631..017e2c2d36e1 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -339,9 +339,13 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
esph = esp_output_set_esn(skb, esph, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0)) {
+ spin_unlock_bh(&x->lock);
+ goto error;
+ }
allocsize = ALIGN(skb->data_len, L1_CACHE_BYTES);
@@ -360,12 +364,15 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
pfrag->offset = pfrag->offset + allocsize;
sg_init_table(dsg, skb_shinfo(skb)->nr_frags + 1);
- skb_to_sgvec(skb, dsg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, dsg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
spin_unlock_bh(&x->lock);
+ if (unlikely(err < 0))
+ goto error;
+
goto skip_cow2;
}
}
@@ -403,9 +410,11 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
esph = esp_output_set_esn(skb, esph, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
- (unsigned char *)esph - skb->data,
- assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0))
+ goto error;
skip_cow2:
if ((x->props.flags & XFRM_STATE_ESN))
@@ -600,7 +609,9 @@ static int esp6_input(struct xfrm_state *x, struct sk_buff *skb)
esp_input_set_header(skb, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0))
+ goto out;
skb->ip_summed = CHECKSUM_NONE;
--
2.12.2
^ permalink raw reply related
* [PATCH 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: Jason A. Donenfeld @ 2017-04-25 14:08 UTC (permalink / raw)
To: netdev, linux-kernel, davem, David.Laight, kernel-hardening
Cc: Jason A. Donenfeld
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
net/core/skbuff.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f86bf69cfb8d..3c2a7f323722 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3489,7 +3489,9 @@ void __init skb_init(void)
* @len: Length of buffer space to be mapped
*
* Fill the specified scatter-gather list with mappings/pointers into a
- * region of the buffer space attached to a socket buffer.
+ * region of the buffer space attached to a socket buffer. Returns either
+ * the number of scatterlist items used, or -EMSGSIZE if the contents
+ * could not fit.
*/
static int
__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
@@ -3512,6 +3514,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
int end;
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
WARN_ON(start > offset + len);
end = start + skb_frag_size(&skb_shinfo(skb)->frags[i]);
@@ -3535,6 +3540,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
WARN_ON(start > offset + len);
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
end = start + frag_iter->len;
if ((copy = end - offset) > 0) {
if (copy > len)
--
2.12.2
^ permalink raw reply related
* Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled
From: Nikolay Aleksandrov @ 2017-04-25 14:03 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: David S. Miller, roopa
In-Reply-To: <a96ddd28-6d99-84d0-563a-2493a09a9e60@brocade.com>
On 25/04/17 16:32, Mike Manning wrote:
> On 24/04/17 20:52, Nikolay Aleksandrov wrote:
>> On 24/04/17 17:09, Mike Manning wrote:
>>> Flood suppression for packets that are not unicast needs to be handled
>>> consistently by also not flooding broadcast packets. As broadcast is a
>>> special case of multicast, the same kernel parameter should be used to
>>> suppress flooding for both of these packet types.
>>>
>>> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
>>> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>>> ---
>>> net/bridge/br_forward.c | 17 ++++++++++-------
>>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>>
>>
>> I do not agree that this is a bug fix, the behaviour was intentional and is close to how HW
>> handles this flag. It has been like that for a few releases and changing it may impact setups
>> that use the flag since up until now they've seen the broadcast but not multicast packets and
>> suddenly their broadcast will stop.
>>
>> I think it would be better to introduce a third flag for bcast in net-next and use that to
>> filter it since that would give us the ability to program HW that can distinguish these
>> and have both options available, moreover it will not break any user setups relying on
>> the current flag behaviour and we have such setups.
>>
>> Thanks,
>> Nik
>>
>>
>
> Hi Nik,
> What is the usecase for flooding broadcast but not multicast please? Is the lack of flood
> suppression for broadcast just something that has not been explicitly tested for in those
> setups? This is the case for us, the bug raised only at this stage of the release cycle.
> While adding another kernel param is an option, I would only do so if absolutely necessary
> so as to avoid proliferation of params. Also to justify adding such a flag for broadcast
> suppression, I would need to add a comment to explain that while broadcast is a subset of
> multicast, the multicast flood suppression flag excludes broadcast.
>
> Thanks
> Mike
>
Hi Mike,
Stopping non-locally originating ARP requests is a pretty serious change
that affects many setups and changes the intended behaviour of this
option which was introduced specifically for unknown multicast flooding.
There're other options - you could filter the broadcast at the firewall
level, at least now you have that option but with this patch applied it
will be gone. Most network vendors differentiate the same types of
traffic as the ones listed below and allow to control them separately
which is much more flexible, I would like to keep it that way.
Currently the bridge differentiates intentionally between:
- known/unknown unicast controlled via fdbs/BR_FLOOD respectively
- known/unknown multicast controlled via mdbs/BR_MCAST_FLOOD respectively
- broadcast controlled only via firewall at this point
Fortunately the broadcast traffic doesn't have any dependent internal
state and can easily be controlled via the firewall thus rendering such
option unnecessary indeed, but I don't mind having it for completeness.
As for the comment, feel free to add it, I've actually added the exact
same comment some time ago in commit 8addd5e7d3a5 ("net: bridge: change
unicast boolean to exact pkt_type").
Cheers,
Nik
^ permalink raw reply
* [PATCH net] ipv6: fix source routing
From: Sabrina Dubroca @ 2017-04-25 13:56 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Hannes Frederic Sowa, David Lebrun
Commit a149e7c7ce81 ("ipv6: sr: add support for SRH injection through
setsockopt") introduced handling of IPV6_SRCRT_TYPE_4, but at the same
time restricted it to only IPV6_SRCRT_TYPE_0 and
IPV6_SRCRT_TYPE_4. Previously, ipv6_push_exthdr() and fl6_update_dst()
would also handle other values (ie STRICT and TYPE_2).
Restore previous source routing behavior, by handling IPV6_SRCRT_STRICT
and IPV6_SRCRT_TYPE_2 the same way as IPV6_SRCRT_TYPE_0 in
ipv6_push_exthdr() and fl6_update_dst().
Fixes: a149e7c7ce81 ("ipv6: sr: add support for SRH injection through setsockopt")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/exthdrs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 25192a3b0cd7..d32e2110aff2 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -909,6 +909,8 @@ static void ipv6_push_rthdr(struct sk_buff *skb, u8 *proto,
{
switch (opt->type) {
case IPV6_SRCRT_TYPE_0:
+ case IPV6_SRCRT_STRICT:
+ case IPV6_SRCRT_TYPE_2:
ipv6_push_rthdr0(skb, proto, opt, addr_p, saddr);
break;
case IPV6_SRCRT_TYPE_4:
@@ -1163,6 +1165,8 @@ struct in6_addr *fl6_update_dst(struct flowi6 *fl6,
switch (opt->srcrt->type) {
case IPV6_SRCRT_TYPE_0:
+ case IPV6_SRCRT_STRICT:
+ case IPV6_SRCRT_TYPE_2:
fl6->daddr = *((struct rt0_hdr *)opt->srcrt)->addr;
break;
case IPV6_SRCRT_TYPE_4:
--
2.12.2
^ permalink raw reply related
* Re: [RFC PATCH 3/7] net: add option to get information about timestamped packets
From: Miroslav Lichvar @ 2017-04-25 13:56 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, Richard Cochran, Willem de Bruijn,
Soheil Hassas Yeganeh, Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <CAF=yD-+ErPH6Qb4y9TcAMi-7X+ebxW3epq3Zxch_vrt1r3gspQ@mail.gmail.com>
On Mon, Apr 24, 2017 at 11:18:13AM -0400, Willem de Bruijn wrote:
> On Mon, Apr 24, 2017 at 5:00 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > Would "skb->data - skb->head -
> > skb->mac_header + skb->len" always work as the L2 length for received
> > packets at the time when the cmsg is prepared?
>
> (skb->data - skb->head) - skb->mac_header computes the length
> of data before the mac, such as reserve?
data - head includes the reserve, but mac_header does too, so I think
it should be just the length of MAC header and everything up to the
data.
> Do you mean skb->data -
> skb->mac_header (or - skb_mac_offset(skb))?
That would give me a pointer? If I used skb_mac_offset(), the total
length would be just skb->len - skb_mac_offset()?
> > As for the original ifindex, it seems to me it does need to be saved
> > to a new field since __netif_receive_skb_core() intentionally
> > overwrites skb->skb_iif. What would be the best place for it, sk_buff
> > or skb_shared_info?
>
> Finding storage space on the receive path will not be easy.
>
> One shortcut to avoid storing this information explicitly is to look up
> the device from skb->napi_id.
Thanks. This looks promising. It will depend on CONFIG_NET_RX_BUSY_POLL,
but I guess that's ok. It nicely isolates all costs to the timestamping
option.
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH net] net: batman-adv: Fix possible memleaks when fail to register_netdevice
From: Sven Eckelmann @ 2017-04-25 13:53 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: mareklindner-rVWd3aGhH2z5bpWLKbzFeg,
netdev-u79uwXL29TY76Z2rM5mHXA, a, Gao Feng,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, gfree.wind-H32Fclmsjq1BDgjK7y7TUQ
In-Reply-To: <1493121800-28066-1-git-send-email-gfree.wind-H32Fclmsjq1BDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On Dienstag, 25. April 2017 20:03:20 CEST gfree.wind-H32Fclmsjq1BDgjK7y7TUQ@public.gmane.org wrote:
> From: Gao Feng <fgao-KlmEoCYek3zQT0dZR+AlfA@public.gmane.org>
>
> Because the func batadv_softif_init_late allocate some resources and
> it would be invoked in register_netdevice. So we need to invoke the
> func batadv_softif_free instead of free_netdev to cleanup when fail
> to register_netdevice.
I could be wrong, but shouldn't the destructor be replaced with free_netdevice
and the batadv_softif_free (without the free_netdev) used as ndo_uninit? The
line you've changed should then be kept as free_netdevice.
At least this seems to be important when using rtnl_newlink() instead of the
legacy sysfs netdev stuff from batman-adv. rtnl_newlink() would also only call
free_netdevice and thus also not run batadv_softif_free. This seems to be only
fixable by calling ndo_uninit.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Network cooling device and how to control NIC speed on thermal condition
From: Alan Cox @ 2017-04-25 13:45 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: netdev, linux-kernel
In-Reply-To: <CAHKzcEMQPQzg6PYCSuv7Ufad+4AZ2gnqMgz3-VH5NTeb_pv4zQ@mail.gmail.com>
> I am looking on Linux thermal framework and on how to cool down the
> system effectively when it hits thermal condition. Already existing
> cooling methods cpu_cooling and clock_cooling are good. However, I
> wanted to go further and dynamically control also a switch ports'
> speed based on thermal condition. Lowering speed means less power,
> less power means lower temp.
>
> Is there any in-kernel interface to configure switch port/NIC from other driver?
No but you can always hook that kind of functionality to the thermal
daemon. However I'd be careful with your assumptions. Lower speed also
means more time active.
https://github.com/01org/thermal_daemon
For example if you run a big encoding job on an atom instead of an Intel
i7, the atom will often not only take way longer but actually use more
total power than the i7 did.
Thus it would often be far more efficient to time synchronize your
systems, batch up data on the collecting end, have the processing node
wake up on an alarm, collect data from the other node and then actually
go back into suspend.
Modern processors are generally very good in idle state (less so
sometimes the platform around them) so trying to lower speeds may
actually be the wrong thing to do, versus say trying to batch up activity
so that you handle a burst and then sleep the entire platform.
It also makes sense to keep policy like that mostly user space - because
what you do is going to be very device specific - eg with things like
dimming the screen, lowering the wifi power, pausing some system
services, pausing battery charge etc.
Now at platform design time there are some interesting trade offs between
100Mbit and 1Gbit ethernet although less so than there used to be 8)
Alan
^ permalink raw reply
* RE: [PATCH net-next] qed: fix invalid use of sizeof in qed_alloc_qm_data()
From: Mintz, Yuval @ 2017-04-25 13:43 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, netdev@vger.kernel.org, Elior, Ariel
In-Reply-To: <20170425070718.14790-1-weiyj.lk@gmail.com>
> sizeof() when applied to a pointer typed expression gives the size of the
> pointer, not that of the pointed data.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Thanks!
Acked-by: Yuval Mintz <Yuval.Mintz@cavium.com>
I'd also mention that -
Fixes: b5a9ee7cf3be ("qed: Revise QM configuration")
^ permalink raw reply
* Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled
From: Mike Manning @ 2017-04-25 13:32 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: David S. Miller, roopa
In-Reply-To: <5266c6fd-54e9-01c7-2379-0b7f11a3cde3@cumulusnetworks.com>
On 24/04/17 20:52, Nikolay Aleksandrov wrote:
> On 24/04/17 17:09, Mike Manning wrote:
>> Flood suppression for packets that are not unicast needs to be handled
>> consistently by also not flooding broadcast packets. As broadcast is a
>> special case of multicast, the same kernel parameter should be used to
>> suppress flooding for both of these packet types.
>>
>> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
>> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>> ---
>> net/bridge/br_forward.c | 17 ++++++++++-------
>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>
>
> I do not agree that this is a bug fix, the behaviour was intentional and is close to how HW
> handles this flag. It has been like that for a few releases and changing it may impact setups
> that use the flag since up until now they've seen the broadcast but not multicast packets and
> suddenly their broadcast will stop.
>
> I think it would be better to introduce a third flag for bcast in net-next and use that to
> filter it since that would give us the ability to program HW that can distinguish these
> and have both options available, moreover it will not break any user setups relying on
> the current flag behaviour and we have such setups.
>
> Thanks,
> Nik
>
>
Hi Nik,
What is the usecase for flooding broadcast but not multicast please? Is the lack of flood
suppression for broadcast just something that has not been explicitly tested for in those
setups? This is the case for us, the bug raised only at this stage of the release cycle.
While adding another kernel param is an option, I would only do so if absolutely necessary
so as to avoid proliferation of params. Also to justify adding such a flag for broadcast
suppression, I would need to add a comment to explain that while broadcast is a subset of
multicast, the multicast flood suppression flag excludes broadcast.
Thanks
Mike
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: remove insecure_max_entries param
From: Herbert Xu @ 2017-04-25 13:28 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20170425112356.GB11322@breakpoint.cc>
On Tue, Apr 25, 2017 at 01:23:56PM +0200, Florian Westphal wrote:
>
> What extra cost?
>
> The only change is that ht->nelems has to be right-shifted by one,
> I don't think that warrants extra space in struct rhashtable, its
> already way too large (I think we can reduce its size further).
I see at least one hole on 64-bit which means that you can fit
it into struct rhashtable for free.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ipv6: ensure message length for raw socket is at least sizeof(ipv6hdr)
From: Alexander Potapenko @ 2017-04-25 13:18 UTC (permalink / raw)
To: dvyukov, kcc, edumazet, davem, kuznet; +Cc: linux-kernel, netdev
rawv6_send_hdrinc() expects that the buffer copied from the userspace
contains the IPv6 header, so if too few bytes are copied parts of the
header may remain uninitialized.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <glider@google.com>
---
For the record, the KMSAN report:
==================================================================
BUG: KMSAN: use of unitialized memory in nf_ct_frag6_gather+0xf5a/0x44a0
inter: 0
CPU: 0 PID: 1036 Comm: probe Not tainted 4.11.0-rc5+ #2455
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x143/0x1b0 lib/dump_stack.c:52
kmsan_report+0x16b/0x1e0 mm/kmsan/kmsan.c:1078
__kmsan_warning_32+0x5c/0xa0 mm/kmsan/kmsan_instr.c:510
nf_ct_frag6_gather+0xf5a/0x44a0 net/ipv6/netfilter/nf_conntrack_reasm.c:577
ipv6_defrag+0x1d9/0x280 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
nf_hook_entry_hookfn ./include/linux/netfilter.h:102
nf_hook_slow+0x13f/0x3c0 net/netfilter/core.c:310
nf_hook ./include/linux/netfilter.h:212
NF_HOOK ./include/linux/netfilter.h:255
rawv6_send_hdrinc net/ipv6/raw.c:673
rawv6_sendmsg+0x2fcb/0x41a0 net/ipv6/raw.c:919
inet_sendmsg+0x3f8/0x6d0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633
sock_sendmsg net/socket.c:643
SYSC_sendto+0x6a5/0x7c0 net/socket.c:1696
SyS_sendto+0xbc/0xe0 net/socket.c:1664
do_syscall_64+0x72/0xa0 arch/x86/entry/common.c:285
entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:246
RIP: 0033:0x436e03
RSP: 002b:00007ffce48baf38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000436e03
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007ffce48baf90 R08: 00007ffce48baf50 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000401790 R14: 0000000000401820 R15: 0000000000000000
origin: 00000000d9400053
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:362
kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:257
kmsan_poison_shadow+0x6d/0xc0 mm/kmsan/kmsan.c:270
slab_alloc_node mm/slub.c:2735
__kmalloc_node_track_caller+0x1f4/0x390 mm/slub.c:4341
__kmalloc_reserve net/core/skbuff.c:138
__alloc_skb+0x2cd/0x740 net/core/skbuff.c:231
alloc_skb ./include/linux/skbuff.h:933
alloc_skb_with_frags+0x209/0xbc0 net/core/skbuff.c:4678
sock_alloc_send_pskb+0x9ff/0xe00 net/core/sock.c:1903
sock_alloc_send_skb+0xe4/0x100 net/core/sock.c:1920
rawv6_send_hdrinc net/ipv6/raw.c:638
rawv6_sendmsg+0x2918/0x41a0 net/ipv6/raw.c:919
inet_sendmsg+0x3f8/0x6d0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633
sock_sendmsg net/socket.c:643
SYSC_sendto+0x6a5/0x7c0 net/socket.c:1696
SyS_sendto+0xbc/0xe0 net/socket.c:1664
do_syscall_64+0x72/0xa0 arch/x86/entry/common.c:285
return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
==================================================================
, triggered by the following syscalls:
socket(PF_INET6, SOCK_RAW, IPPROTO_RAW) = 3
sendto(3, NULL, 0, 0, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "ff00::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EPERM
---
net/ipv6/raw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index f174e76e6505..805464668bd8 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -632,6 +632,8 @@ static int rawv6_send_hdrinc(struct sock *sk, struct msghdr *msg, int length,
ipv6_local_error(sk, EMSGSIZE, fl6, rt->dst.dev->mtu);
return -EMSGSIZE;
}
+ if (length < sizeof(struct ipv6hdr))
+ return -EINVAL;
if (flags&MSG_PROBE)
goto out;
--
2.13.0.rc0.306.g87b477812d-goog
^ permalink raw reply related
* Re: Network cooling device and how to control NIC speed on thermal condition
From: Andrew Lunn @ 2017-04-25 13:17 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: netdev, linux-kernel
In-Reply-To: <CAHKzcEMQPQzg6PYCSuv7Ufad+4AZ2gnqMgz3-VH5NTeb_pv4zQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 10:36:28AM +0200, Waldemar Rymarkiewicz wrote:
> Hi,
>
> I am not much aware of linux networking architecture so I'd like to
> ask first before will start to dig into the code. Appreciate any
> feedback.
>
> I am looking on Linux thermal framework and on how to cool down the
> system effectively when it hits thermal condition. Already existing
> cooling methods cpu_cooling and clock_cooling are good. However, I
> wanted to go further and dynamically control also a switch ports'
> speed based on thermal condition. Lowering speed means less power,
> less power means lower temp.
>
> Is there any in-kernel interface to configure switch port/NIC from other driver?
Hi Waldemar
Linux models switch ports as network interfaces, so mostly, there is
little difference between a NIC and a switch port. What you define for
one, should work for the other. Mostly.
However, i don't think you need to be too worried about the NIC level
of the stack. You can mostly do this higher up in the stack. I would
expect there is a relationship between Packets per Second and
generated heat. You might want the NIC to give you some sort of
heating coefficient, 1PPS is ~ 10uC. Given that, you want to throttle
the PPS in the generic queuing layers. This sounds like a TC filter.
You have userspace install a TC filter, which is a net_cooling device.
This however does not directly work for so called 'fastpath' traffic
in switches. Frames which ingress one switch port and egress another
switch port are mostly never seen by Linux. So a software TC filter
will not affect them. However, there is infrastructure in place to
accelerate TC filters by pushing them down into the hardware. So the
same basic concept can be used for switch fastpath traffic, but
requires a bit more work.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] virtio-net tx napi
From: David Miller @ 2017-04-25 13:09 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, virtualization, willemb, mst
In-Reply-To: <20170424174930.82623-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 24 Apr 2017 13:49:25 -0400
> Add napi for virtio-net transmit completion processing.
Series applied, thanks.
^ 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