* [PATCH 0/5] atm: Adjustments for some function implementations
From: SF Markus Elfring @ 2017-05-21 20:12 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 22:09:11 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (5):
Improve a size determination in four functions
Delete an error message for a failed memory allocation in make_entry()
Adjust 19 checks for null pointers
Use seq_puts() in lec_info()
Use seq_putc() in lec_info()
net/atm/lec.c | 55 +++++++++++++++++++++++++++----------------------------
1 file changed, 27 insertions(+), 28 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/5] atm: Improve a size determination in four functions
From: SF Markus Elfring @ 2017-05-21 20:14 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:20:44 +0200
Replace the specification of four data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 09cfe87f0a44..6ad3ca625a44 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -518,5 +518,5 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
return -1;
skb->len = sizeof(struct atmlec_msg);
mesg = (struct atmlec_msg *)skb->data;
- memset(mesg, 0, sizeof(struct atmlec_msg));
+ memset(mesg, 0, sizeof(*mesg));
mesg->type = type;
@@ -690,5 +690,5 @@ static int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg)
if (ioc_data.dev_num < 0 || ioc_data.dev_num >= MAX_LEC_ITF ||
!dev_lec[ioc_data.dev_num])
return -EINVAL;
- vpriv = kmalloc(sizeof(struct lec_vcc_priv), GFP_KERNEL);
+ vpriv = kmalloc(sizeof(*vpriv), GFP_KERNEL);
if (!vpriv)
@@ -1552,5 +1552,5 @@ static struct lec_arp_table *make_entry(struct lec_priv *priv,
{
struct lec_arp_table *to_return;
- to_return = kzalloc(sizeof(struct lec_arp_table), GFP_ATOMIC);
+ to_return = kzalloc(sizeof(*to_return), GFP_ATOMIC);
if (!to_return) {
@@ -2156,5 +2156,5 @@ static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc)
struct lec_vcc_priv *vpriv;
int err = 0;
- vpriv = kmalloc(sizeof(struct lec_vcc_priv), GFP_KERNEL);
+ vpriv = kmalloc(sizeof(*vpriv), GFP_KERNEL);
if (!vpriv)
--
2.13.0
^ permalink raw reply related
* [PATCH 2/5] atm: Delete an error message for a failed memory allocation in make_entry()
From: SF Markus Elfring @ 2017-05-21 20:15 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:24:45 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 6ad3ca625a44..a11dbd3a5119 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1556,7 +1556,6 @@ static struct lec_arp_table *make_entry(struct lec_priv *priv,
- if (!to_return) {
- pr_info("LEC: Arp entry kmalloc failed\n");
+ if (!to_return)
return NULL;
- }
+
ether_addr_copy(to_return->mac_addr, mac_addr);
INIT_HLIST_NODE(&to_return->next);
setup_timer(&to_return->timer, lec_arp_expire_arp,
--
2.13.0
^ permalink raw reply related
* [PATCH 3/5] atm: Adjust 19 checks for null pointers
From: SF Markus Elfring @ 2017-05-21 20:16 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:34:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix the affected source code places.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index a11dbd3a5119..ca3aec0c0743 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -139,7 +139,7 @@ static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev)
struct atmlec_msg *mesg;
skb2 = alloc_skb(sizeof(struct atmlec_msg), GFP_ATOMIC);
- if (skb2 == NULL)
+ if (!skb2)
return;
skb2->len = sizeof(struct atmlec_msg);
mesg = (struct atmlec_msg *)skb2->data;
@@ -264,7 +264,7 @@ static netdev_tx_t lec_start_xmit(struct sk_buff *skb,
min_frame_size - skb->truesize,
GFP_ATOMIC);
dev_kfree_skb(skb);
- if (skb2 == NULL) {
+ if (!skb2) {
dev->stats.tx_dropped++;
return NETDEV_TX_OK;
}
@@ -431,7 +431,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
pr_debug("%s: bridge zeppelin asks about %pM\n",
dev->name, mesg->content.proxy.mac_addr);
- if (br_fdb_test_addr_hook == NULL)
+ if (!br_fdb_test_addr_hook)
break;
if (br_fdb_test_addr_hook(dev, mesg->content.proxy.mac_addr)) {
@@ -442,7 +442,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
pr_debug("%s: entry found, responding to zeppelin\n",
dev->name);
skb2 = alloc_skb(sizeof(struct atmlec_msg), GFP_ATOMIC);
- if (skb2 == NULL)
+ if (!skb2)
break;
skb2->len = sizeof(struct atmlec_msg);
skb_copy_to_linear_data(skb2, mesg, sizeof(*mesg));
@@ -520,7 +520,7 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
mesg = (struct atmlec_msg *)skb->data;
memset(mesg, 0, sizeof(*mesg));
mesg->type = type;
- if (data != NULL)
+ if (data)
mesg->sizeoftlvs = data->len;
if (mac_addr)
ether_addr_copy(mesg->content.normal.mac_addr, mac_addr);
@@ -534,7 +534,7 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
skb_queue_tail(&sk->sk_receive_queue, skb);
sk->sk_data_ready(sk);
- if (data != NULL) {
+ if (data) {
pr_debug("about to send %d bytes of data\n", data->len);
atm_force_charge(priv->lecd, data->truesize);
skb_queue_tail(&sk->sk_receive_queue, data);
@@ -663,7 +663,7 @@ static void lec_pop(struct atm_vcc *vcc, struct sk_buff *skb)
struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
struct net_device *dev = skb->dev;
- if (vpriv == NULL) {
+ if (!vpriv) {
pr_info("vpriv = NULL!?!?!?\n");
return;
}
@@ -1066,7 +1066,7 @@ static void __exit lane_module_cleanup(void)
deregister_atm_ioctl(&lane_ioctl_ops);
for (i = 0; i < MAX_LEC_ITF; i++) {
- if (dev_lec[i] != NULL) {
+ if (dev_lec[i]) {
unregister_netdev(dev_lec[i]);
free_netdev(dev_lec[i]);
dev_lec[i] = NULL;
@@ -1097,11 +1097,11 @@ static int lane2_resolve(struct net_device *dev, const u8 *dst_mac, int force,
spin_lock_irqsave(&priv->lec_arp_lock, flags);
table = lec_arp_find(priv, dst_mac);
spin_unlock_irqrestore(&priv->lec_arp_lock, flags);
- if (table == NULL)
+ if (!table)
return -1;
*tlvs = kmemdup(table->tlvs, table->sizeoftlvs, GFP_ATOMIC);
- if (*tlvs == NULL)
+ if (!*tlvs)
return -1;
*sizeoftlvs = table->sizeoftlvs;
@@ -1109,12 +1109,12 @@ static int lane2_resolve(struct net_device *dev, const u8 *dst_mac, int force,
return 0;
}
- if (sizeoftlvs == NULL)
+ if (!sizeoftlvs)
retval = send_to_lecd(priv, l_arp_xmt, dst_mac, NULL, NULL);
else {
skb = alloc_skb(*sizeoftlvs, GFP_ATOMIC);
- if (skb == NULL)
+ if (!skb)
return -1;
skb->len = *sizeoftlvs;
skb_copy_to_linear_data(skb, *tlvs, *sizeoftlvs);
@@ -1143,12 +1143,12 @@ static int lane2_associate_req(struct net_device *dev, const u8 *lan_dst,
kfree(priv->tlvs); /* NULL if there was no previous association */
priv->tlvs = kmemdup(tlvs, sizeoftlvs, GFP_KERNEL);
- if (priv->tlvs == NULL)
+ if (!priv->tlvs)
return 0;
priv->sizeoftlvs = sizeoftlvs;
skb = alloc_skb(sizeoftlvs, GFP_ATOMIC);
- if (skb == NULL)
+ if (!skb)
return 0;
skb->len = sizeoftlvs;
skb_copy_to_linear_data(skb, tlvs, sizeoftlvs);
@@ -1181,13 +1181,13 @@ static void lane2_associate_ind(struct net_device *dev, const u8 *mac_addr,
*/
struct lec_arp_table *entry = lec_arp_find(priv, mac_addr);
- if (entry == NULL)
+ if (!entry)
return; /* should not happen */
kfree(entry->tlvs);
entry->tlvs = kmemdup(tlvs, sizeoftlvs, GFP_KERNEL);
- if (entry->tlvs == NULL)
+ if (!entry->tlvs)
return;
entry->sizeoftlvs = sizeoftlvs;
#endif
@@ -1854,7 +1854,7 @@ lec_arp_update(struct lec_priv *priv, const unsigned char *mac_addr,
spin_lock_irqsave(&priv->lec_arp_lock, flags);
entry = lec_arp_find(priv, mac_addr);
- if (entry == NULL && targetless_le_arp)
+ if (!entry && targetless_le_arp)
goto out; /*
* LANE2: ignore targetless LE_ARPs for which
* we have no entry in the cache. 7.1.30
@@ -1965,7 +1965,7 @@ lec_vcc_added(struct lec_priv *priv, const struct atmlec_ioc *ioc_data,
entry->old_recv_push = old_push;
#endif
entry = make_entry(priv, bus_mac);
- if (entry == NULL)
+ if (!entry)
goto out;
del_timer(&entry->timer);
memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN);
@@ -1990,7 +1990,7 @@ lec_vcc_added(struct lec_priv *priv, const struct atmlec_ioc *ioc_data,
ioc_data->atm_addr[16], ioc_data->atm_addr[17],
ioc_data->atm_addr[18], ioc_data->atm_addr[19]);
entry = make_entry(priv, bus_mac);
- if (entry == NULL)
+ if (!entry)
goto out;
memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN);
eth_zero_addr(entry->mac_addr);
--
2.13.0
^ permalink raw reply related
* [PATCH 4/5] atm: Use seq_puts() in lec_info()
From: SF Markus Elfring @ 2017-05-21 20:17 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:49:10 +0200
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index ca3aec0c0743..752891434074 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -804,7 +804,7 @@ static void lec_info(struct seq_file *seq, struct lec_arp_table *entry)
if (entry->vcc)
seq_printf(seq, "%3d %3d ", entry->vcc->vpi, entry->vcc->vci);
else
- seq_printf(seq, " ");
+ seq_puts(seq, " ");
if (entry->recv_vcc) {
seq_printf(seq, " %3d %3d", entry->recv_vcc->vpi,
entry->recv_vcc->vci);
--
2.13.0
^ permalink raw reply related
* [PATCH 5/5] atm: Use seq_putc() in lec_info()
From: SF Markus Elfring @ 2017-05-21 20:18 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:50:44 +0200
A single space character should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 752891434074..1d4edf093987 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -796,7 +796,7 @@ static void lec_info(struct seq_file *seq, struct lec_arp_table *entry)
for (i = 0; i < ETH_ALEN; i++)
seq_printf(seq, "%2.2x", entry->mac_addr[i] & 0xff);
- seq_printf(seq, " ");
+ seq_putc(seq, ' ');
for (i = 0; i < ATM_ESA_LEN; i++)
seq_printf(seq, "%2.2x", entry->atm_addr[i] & 0xff);
seq_printf(seq, " %s %4.4x", lec_arp_get_status_string(entry->status),
--
2.13.0
^ permalink raw reply related
* Re: [PATCH net-next v5] net: ipv6: fix code style error and warning of ndisc.c
From: Joe Perches @ 2017-05-21 21:14 UTC (permalink / raw)
To: David Miller, dsahern; +Cc: cugyly, netdev, Linyu.Yuan
In-Reply-To: <20170521.125404.420857788471820007.davem@davemloft.net>
On Sun, 2017-05-21 at 12:54 -0400, David Miller wrote:
> From: David Ahern <dsahern@gmail.com> Date: Sun, 21 May 2017 10:17:47 -0600
> > On 5/21/17 10:05 AM, Joe Perches wrote:
> >> But really, why bother?
> >>
> >> Just because checkpatch bleats some message doesn't
> >> mean it _has_ to be fixed.
> >>
> >> Please strive to make the code more readable and
> >> intelligible for _humans_. Compilers don't care.
> >
> > +1
> >
> > broad cleanups like this make 'git blame' harder to use to find root causes.
I don't have any issue with broad cleanups and I think
the git blame argument is overblown.
If and when broad cleanups are done, it's best if there
is some other concurrent desire to improve logic, reduce
object code size, and/or other code refactoring other
than mere whitespace changes.
^ permalink raw reply
* Viable partnership request.
From: Mr Albert Yang @ 2017-05-18 22:12 UTC (permalink / raw)
To: netdev
Compliment of the day,
I have access to very vital information that can be used to move a huge amount of money.
I have done my homework very well and i have the machineries in place to get it done.
Ultimately I need an honest person to play an important role in the completion of this business transaction.
Regards,
Albert.
^ permalink raw reply
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Tom Herbert @ 2017-05-21 22:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov,
Linux Kernel Network Developers
In-Reply-To: <20170521180435.56dcd76b@redhat.com>
On Sun, May 21, 2017 at 9:04 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Sat, 20 May 2017 09:16:09 -0700
> Tom Herbert <tom@herbertland.com> wrote:
>
>> > +/* XDP rxhash have an associated type, which is related to the RSS
>> > + * (Receive Side Scaling) standard, but NIC HW have different mapping
>> > + * and support. Thus, create mapping that is interesting for XDP. XDP
>> > + * would primarly want insight into L3 and L4 protocol info.
>> > + *
>> > + * TODO: Likely need to get extended with "L3_IPV6_EX" due RSS standard
>> > + *
>> > + * The HASH_TYPE will be returned from bpf helper as the top 32-bit of
>> > + * the 64-bit rxhash (internally type stored in xdp_buff->flags).
>> > + */
>> > +#define XDP_HASH(x) ((x) & ((1ULL << 32)-1))
>> > +#define XDP_HASH_TYPE(x) ((x) >> 32)
>> > +
>> > +#define XDP_HASH_TYPE_L3_SHIFT 0
>> > +#define XDP_HASH_TYPE_L3_BITS 3
>> > +#define XDP_HASH_TYPE_L3_MASK ((1ULL << XDP_HASH_TYPE_L3_BITS)-1)
>> > +#define XDP_HASH_TYPE_L3(x) ((x) & XDP_HASH_TYPE_L3_MASK)
>> > +enum {
>> > + XDP_HASH_TYPE_L3_IPV4 = 1,
>> > + XDP_HASH_TYPE_L3_IPV6,
>> > +};
>> > +
>> > +#define XDP_HASH_TYPE_L4_SHIFT XDP_HASH_TYPE_L3_BITS
>> > +#define XDP_HASH_TYPE_L4_BITS 5
>> > +#define XDP_HASH_TYPE_L4_MASK \
>> > + (((1ULL << XDP_HASH_TYPE_L4_BITS)-1) << XDP_HASH_TYPE_L4_SHIFT)
>> > +#define XDP_HASH_TYPE_L4(x) ((x) & XDP_HASH_TYPE_L4_MASK)
>> > +enum {
>> > + _XDP_HASH_TYPE_L4_TCP = 1,
>> > + _XDP_HASH_TYPE_L4_UDP,
>> > +};
>> > +#define XDP_HASH_TYPE_L4_TCP (_XDP_HASH_TYPE_L4_TCP << XDP_HASH_TYPE_L4_SHIFT)
>> > +#define XDP_HASH_TYPE_L4_UDP (_XDP_HASH_TYPE_L4_UDP << XDP_HASH_TYPE_L4_SHIFT)
>> > +
>> Hi Jesper,
>>
>> Why do we need these indicators for protocol specific hash? It seems
>> like L4 and L3 is useful differentiation and protocol agnostic (I'm
>> still holding out hope that SCTP will be deployed some day ;-) )
>
> I'm not sure I understood the question fully, but let me try to answer
> anyway. To me it seems obvious that you would want to know the
> protocol/L4 type, as this helps avoid hash collisions between UDP and
> TCP flows. I can easily imagine someone constructing an UDP packet
> that could hash collide with a given TCP flow.
>
> And yes, i40 support matching SCTP, and we will create a
> XDP_HASH_TYPE_L4_SCTP when adding XDP rxhash support for that driver.
>
But where would this information be used? We don't save it in skbuff,
don't use it in RPS, RFS. RSS doesn't use it for packet steering so
the hash collision problem already exists at the device level. If
there is a collision problem between two protocols then maybe hash
should be over 5-tuple instead...
Tom
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter/IPVS fixes for net
From: Pablo Neira Ayuso @ 2017-05-21 22:25 UTC (permalink / raw)
To: David Miller; +Cc: netfilter-devel, netdev
In-Reply-To: <20170521.130033.1427773613973278051.davem@davemloft.net>
On Sun, May 21, 2017 at 01:00:33PM -0400, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Fri, 19 May 2017 10:33:41 +0200
>
> > The following patchset contains Netfilter/IPVS fixes for your net tree,
> > they are:
> ...
> > You can pull these changes from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
>
> Pulled, thanks Pablo.
Thanks David!
Could you merge net into net-next as well? I have several patches for
net-next that need to apply on these fixes. No rush BTW.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
From: Alexander Duyck @ 2017-05-21 22:35 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Amritha Nambiar, intel-wired-lan, Linux Netdev List
In-Reply-To: <CAJ3xEMjTDW7sQ5CFmTyR5xMpin_WFFQg-S8imWMBpXWuS1zvVw@mail.gmail.com>
On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
> <amritha.nambiar@intel.com> wrote:
>> The following series introduces a new harware offload mode in tc/mqprio
>
> Wait, we have already a HW QoS model introduced by John F and Co
> couple of years ago, right?
I assume you are referring to the ETS portion of DCBX? If so then yes
we have something there, but there is a fairly high level of
complexity and dependencies in order to enable that. What we have in
mind doesn't really fit with DCBX and the problem is the spec calls
out that you really have to have support for DCBX in order to make use
of ETS. What we are trying to do here is provide a lightweight way of
doing this configuration similar to how mqprio was already providing a
lightweight way of enabling multiple traffic classes.
> Please elaborate in few sentence if you are extending it/replacing it,
> why we want to do that and what are the implications on existing
> applications UAPI wise.
This is meant to be an extension of the existing structure. It can be
ignored by the driver and instead only have the basic hw offload
supported. In such a case the command will still return success but
any rate limits and queue configuration can be ignored. In the case of
the current implementation the queue configuration was already being
ignored so we opted to re-purpose the "hw" flag so that if you pass a
value greater than 1 and the driver doesn't recognize the value it has
the option to just ignore the extra bits it doesn't recognize and
return 1 as it did before for the hw flag in mqprio.
> Below you just say in the new mode Qos is configured with knobs XYZ --
> this is way not enough
Can you clarify what you are asking for here? Amritha included an
example in patch 1 of a command line that enabled 2 traffic classes
with rate limits. Is there something more specific you are looking
for?
Thanks.
- Alex
^ permalink raw reply
* (unknown),
From: mari.kayhko @ 2017-05-22 0:57 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 58679201840822.zip --]
[-- Type: application/zip, Size: 3176 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2017-05-22 1:16 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Miroslav Lichvar, Willem de Bruijn
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/socket.c: In function 'put_ts_pktinfo':
net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
^
Caused by commit
aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
This probably broke every architecture that has its own
arch/<arch>/include/uapi/asm/socket.h that does not include
include/uapi/asm-generic/socket.h :-(
I have used the net-next tree from next-20170519 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] H.245 ALG dropping packets
From: Blair Steven @ 2017-05-22 2:07 UTC (permalink / raw)
To: netdev; +Cc: Blair Steven
We have a setup where two VoIP phones are communicating through a
router on a trusted LAN where the H.245 ALG is dropping some of the
traffic, so far as I can tell without good cause. These two devices
are configured differently, one with Fast Connect and one without -
this might be the reason, but from my (limited) understanding of ALGs
this isn't a good enough reason.
Does it ever make sense to drop packets in an ALG?
Blair Steven (1):
Accept packets that the H.245 ALG can't process
net/netfilter/nf_conntrack_h323_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH] Accept packets that the H.245 ALG can't process
From: Blair Steven @ 2017-05-22 2:07 UTC (permalink / raw)
To: netdev; +Cc: Blair Steven
In-Reply-To: <20170522020753.16712-1-blair.steven@alliedtelesis.co.nz>
When two VoIP end points are configured differently (fast connect /
not fast connect) the ALG was failing to find a matching expectation
and dropping packets in one direction.
Dropping packets not the job of an ALG, and as such the behaviour
has been changed to allow the packet to be send to the forwarding
engine.
Signed-off-by: Blair Steven <blair.steven@alliedtelesis.co.nz>
---
net/netfilter/nf_conntrack_h323_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
index 3bcdc71..6161375 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -625,7 +625,7 @@ static int h245_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process H.245 message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
@@ -1200,7 +1200,7 @@ static int q931_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process Q.931 message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
@@ -1785,7 +1785,7 @@ static int ras_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process RAS message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
--
2.9.3
^ permalink raw reply related
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2017-05-22 3:14 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170522111605.14f93676@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 May 2017 11:16:05 +1000
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>
> This probably broke every architecture that has its own
> arch/<arch>/include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
>
> I have used the net-next tree from next-20170519 for today.
I've just pushed the following, thanks for the report:
====================
net: Define SCM_TIMESTAMPING_PKTINFO on all architectures.
A definition was only provided for asm-generic/socket.h
using platforms, define it for the others as well
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 148d7a3..0926de6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 1ccf456..e491ff0 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b4..8693724 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index ae6548d..5d97890 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 3418ec9..365ff51 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92..d013c0d 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 5147018..784b871 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0..bc4ca72 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf..fb9769d 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19..5d67330 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 1eb6d2f..982c253 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -109,4 +109,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _XTENSA_SOCKET_H */
--
2.7.4
^ permalink raw reply related
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Alexei Starovoitov @ 2017-05-22 3:21 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20170521175550.762b2cf8@redhat.com>
On Sun, May 21, 2017 at 05:55:50PM +0200, Jesper Dangaard Brouer wrote:
> > And it looks useful to me, but
>
> > 1. i'm worried that we'd be relying on something that mellanox didn't
> > implement in their drivers before. Was it tested and guarnteed to
> > exist in the future revisions of firmware? Is it cx4 or cx4-lx or cx5
> > feature?
>
> It is not a hidden mlx5 or specific feature. Due to the Microsoft RSS
> standard/requirements[2] most NICs actually implement this.
>
> [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types
...
> > 2. but the main concern that it is mellanox only feature. At least I cannot
> > see anything like this in broadcom and intel nics
>
> All the drivers I looked at have support for an RSS hash type.
> Including Broadcom[3] and Intel. Just grep after NETIF_F_RXHASH, and
> follow data-structs. The Intel i40 NIC have the most elaborate rss type
> system (it can e.g. tell if this was SCTP).
>
> [3] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h#L4198
yes and bnxt too.
msft spec requires RSS to be configured in these different ways, but
it doesn't mean that HW descriptor will have 'is_v4' and 'is_v6' bits set.
imo this is mlx specific behavior.
If you want to piggy back on msft spec and make linux rss to be configurable
the same way, I guess that's fine, but imo it's orthogonal to xdp.
> > How about exposing 'struct mlx5_cqe64 *' to XDP programs as-is?
> > We can make sure that XDP program does read only access into it and
> > it will see cqe->rss_hash_result, cqe->rss_hash_type and everything else
> > in there, but this will not be uapi and it will be pretty obvious
> > to program authors that their programs are vendor specific.
>
> This sounds EXTREMELY dangerous to me... IHMO this will lead to vendor
> lock-in. As BPF program authors will become dependent on vendor
> specific features, and their program are no longer portable to run on
> other NICs.
>
> How are you going to avoid vendor lock-in with this model?
It looked to me that that was the intent of your patch set, hence
counter proposal to make it much simpler.
I'm not going to use vendor specific features. The proposal
to expose hw rx descriptor as-is is for people who desperately want
that info without burdening core xdp with it.
> > 'not uapi' here means that mellanox is free to change their HW descriptor
> > and its contents as they wish.
>
> Hmmm... IMHO directly exposing the HW descriptor to userspace, will
> limit vendors ability to change its contents.
kprobes can already look at hw rx descriptor.
if somebody really wants to look into it, they have a way to do it already:
- add kprobe to mlx5e_handle_rx_cqe(), look into cqe, store the outcome on a side
- use that info in the xdp program
All I proposed is to make it first class citizen and avoid kprobe.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
From: Or Gerlitz @ 2017-05-22 3:25 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Amritha Nambiar, intel-wired-lan, Linux Netdev List
In-Reply-To: <CAKgT0Ue6tDOE8L4thktyje-erGkVMmtO7zyp0FRgmRPYOppjQA@mail.gmail.com>
On Mon, May 22, 2017 at 1:35 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
>> <amritha.nambiar@intel.com> wrote:
>>> The following series introduces a new harware offload mode in tc/mqprio
>>
>> Wait, we have already a HW QoS model introduced by John F and Co
>> couple of years ago, right?
>
> I assume you are referring to the ETS portion of DCBX? If so then yes
> we have something there, but there is a fairly high level of
> complexity and dependencies in order to enable that. What we have in
> mind doesn't really fit with DCBX and the problem is the spec calls
> out that you really have to have support for DCBX in order to make use
> of ETS. What we are trying to do here is provide a lightweight way of
> doing this configuration similar to how mqprio was already providing a
> lightweight way of enabling multiple traffic classes.
UAPI wise, we are talking on DCB, not DCBX, right? the X-portion comes
into play if some user-space entity run LLDP traffic and calls into
the kernel to configure (say) ETS. If there are some issues to use the
existing user-space tool (lldpad tool/daemon) to do DCB without X, one
can/should fix them or introduce another/simpler tool that in a
lightweight manner only configures things w.o exchanging.
So to clarify, the essence of this series is introducing a 2nd way to
configure ETS and rate limit?
>> Please elaborate in few sentence if you are extending it/replacing it,
>> why we want to do that and what are the implications on existing
>> applications UAPI wise.
> This is meant to be an extension of the existing structure. It can be
> ignored by the driver and instead only have the basic hw offload
> supported. In such a case the command will still return success but
> any rate limits and queue configuration can be ignored. In the case of
> the current implementation the queue configuration was already being
> ignored so we opted to re-purpose the "hw" flag so that if you pass a
> value greater than 1 and the driver doesn't recognize the value it has
> the option to just ignore the extra bits it doesn't recognize and
> return 1 as it did before for the hw flag in mqprio.
So the user asked to configure something and the kernel returned
success but the config was not plugged to the hw? sounds to me like
possible (probable) source of troubles and complaints.
>> Below you just say in the new mode Qos is configured with knobs XYZ --
>> this is way not enough
> Can you clarify what you are asking for here? Amritha included an
> example in patch 1 of a command line that enabled 2 traffic classes
> with rate limits. Is there something more specific you are looking for?
you were referring to the questions I posted, so we can continue the
discussion from here.
^ permalink raw reply
* [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: Willem de Bruijn @ 2017-05-22 3:31 UTC (permalink / raw)
To: netdev; +Cc: davem, mlichvar, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
is defined in asm-generic/socket.h. Also define it in the architecture
specific versions.
Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 148d7a32754e..0926de63a62b 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 1ccf45657472..e491ff08b9a9 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b48042a..869372413333 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index ae6548d29a18..5d97890a8704 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 3418ec9c1c50..365ff51f033a 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92301a6..d013c0da0256 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 514701840bd9..b893ca14fade 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 0x4033
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0310fc..bc4ca72faf99 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf673fd..fb9769d7e74e 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19d9ec7..5d673302fd41 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 1eb6d2fe70d3..982c2533f912 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -109,4 +109,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _XTENSA_SOCKET_H */
--
2.13.0.303.g4ebf302169-goog
^ permalink raw reply related
* Re: [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: David Miller @ 2017-05-22 3:35 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, mlichvar, willemb
In-Reply-To: <20170522033147.17264-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 21 May 2017 23:31:47 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
> is defined in asm-generic/socket.h. Also define it in the architecture
> specific versions.
>
> Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Miroslav Lichvar <mlichvar@redhat.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
I pushed a fix for this about 15 minutes ago :-)
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Willem de Bruijn @ 2017-05-22 3:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Miroslav Lichvar, Willem de Bruijn
In-Reply-To: <20170522111605.14f93676@canb.auug.org.au>
On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
>
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>
> This probably broke every architecture that has its own
> arch/<arch>/include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
Indeed. I added the architecture specific versions in patch
http://patchwork.ozlabs.org/patch/765238/
That fixes the powerpc build for me. The new option is now
defined in every file that also defines the last added such
option SCM_TIMESTAMPING_OPT_STATS. Apologies for
missing this earlier.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2017-05-22 3:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170521.231410.1999783448679718181.davem@davemloft.net>
Hi Dave,
On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 22 May 2017 11:16:05 +1000
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > net/socket.c: In function 'put_ts_pktinfo':
> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> > ^
> > Caused by commit
> >
> > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
> >
> > This probably broke every architecture that has its own
> > arch/<arch>/include/uapi/asm/socket.h that does not include
> > include/uapi/asm-generic/socket.h :-(
> >
> > I have used the net-next tree from next-20170519 for today.
>
> I've just pushed the following, thanks for the report:
Looks good except:
> diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
> index 5147018..784b871 100644
> --- a/arch/parisc/include/uapi/asm/socket.h
> +++ b/arch/parisc/include/uapi/asm/socket.h
> @@ -97,4 +97,6 @@
>
> #define SO_COOKIE 0x4032
>
> +#define SCM_TIMESTAMPING_PKTINFO 58
Does this need to be 0x4033 (or something)?
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: Willem de Bruijn @ 2017-05-22 3:50 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Miroslav Lichvar, Willem de Bruijn
In-Reply-To: <20170521.233552.1330381397679616478.davem@davemloft.net>
On Sun, May 21, 2017 at 11:35 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Sun, 21 May 2017 23:31:47 -0400
>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
>> is defined in asm-generic/socket.h. Also define it in the architecture
>> specific versions.
>>
>> Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> CC: Miroslav Lichvar <mlichvar@redhat.com>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> I pushed a fix for this about 15 minutes ago :-).
Thanks, David!
Then ignore this one. Apologies for not spotting this sooner.
^ permalink raw reply
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: John Fastabend @ 2017-05-22 4:12 UTC (permalink / raw)
To: Alexei Starovoitov, Jesper Dangaard Brouer; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20170522032129.kjxf465zbj6dfoaw@ast-mbp>
On 05/21/2017 08:21 PM, Alexei Starovoitov wrote:
> On Sun, May 21, 2017 at 05:55:50PM +0200, Jesper Dangaard Brouer wrote:
>>> And it looks useful to me, but
>>
>>> 1. i'm worried that we'd be relying on something that mellanox didn't
>>> implement in their drivers before. Was it tested and guarnteed to
>>> exist in the future revisions of firmware? Is it cx4 or cx4-lx or cx5
>>> feature?
>>
>> It is not a hidden mlx5 or specific feature. Due to the Microsoft RSS
>> standard/requirements[2] most NICs actually implement this.
>>
>> [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types
>
> ...
>
>>> 2. but the main concern that it is mellanox only feature. At least I cannot
>>> see anything like this in broadcom and intel nics
>>
>> All the drivers I looked at have support for an RSS hash type.
>> Including Broadcom[3] and Intel. Just grep after NETIF_F_RXHASH, and
>> follow data-structs. The Intel i40 NIC have the most elaborate rss type
>> system (it can e.g. tell if this was SCTP).
>>
>> [3] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h#L4198
>
> yes and bnxt too.
> msft spec requires RSS to be configured in these different ways, but
> it doesn't mean that HW descriptor will have 'is_v4' and 'is_v6' bits set.
> imo this is mlx specific behavior.
> If you want to piggy back on msft spec and make linux rss to be configurable
> the same way, I guess that's fine, but imo it's orthogonal to xdp.
>
>>> How about exposing 'struct mlx5_cqe64 *' to XDP programs as-is?
>>> We can make sure that XDP program does read only access into it and
>>> it will see cqe->rss_hash_result, cqe->rss_hash_type and everything else
>>> in there, but this will not be uapi and it will be pretty obvious
>>> to program authors that their programs are vendor specific.
>>
>> This sounds EXTREMELY dangerous to me... IHMO this will lead to vendor
>> lock-in. As BPF program authors will become dependent on vendor
>> specific features, and their program are no longer portable to run on
>> other NICs.
>>
>> How are you going to avoid vendor lock-in with this model?
>
> It looked to me that that was the intent of your patch set, hence
> counter proposal to make it much simpler.
> I'm not going to use vendor specific features. The proposal
> to expose hw rx descriptor as-is is for people who desperately want
> that info without burdening core xdp with it.
>
>>> 'not uapi' here means that mellanox is free to change their HW descriptor
>>> and its contents as they wish.
>>
>> Hmmm... IMHO directly exposing the HW descriptor to userspace, will
>> limit vendors ability to change its contents.
>
> kprobes can already look at hw rx descriptor.
> if somebody really wants to look into it, they have a way to do it already:
> - add kprobe to mlx5e_handle_rx_cqe(), look into cqe, store the outcome on a side
> - use that info in the xdp program
> All I proposed is to make it first class citizen and avoid kprobe.
>
Another solution is to have hardware prepend meta-data to the front of the
packet and have the XDP program read it out. Of course the hardware and
XDP program need to be in sync at this point, but it works today assuming
a mechanism to program hardware exists.
The nice part of the above is you push all the complexity of feature negotiation
and hardware initialization out of XDP core completely.
This would be my preferred solution, except I'm not sure if some hardware
would have issue with this.
.John
^ permalink raw reply
* Fw: [Bug 195835] New: regression: tcp_fastretrans_alert
From: Stephen Hemminger @ 2017-05-22 4:14 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 21 May 2017 08:53:17 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195835] New: regression: tcp_fastretrans_alert
https://bugzilla.kernel.org/show_bug.cgi?id=195835
Bug ID: 195835
Summary: regression: tcp_fastretrans_alert
Product: Networking
Version: 2.5
Kernel Version: 4.11.2
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: nanericwang@gmail.com
Regression: No
The issue can be reproduced in 4.11 running netfilter and Transmission
BitTorrent. However 4.10.x has no such issue.
[May21 16:38] ------------[ cut here ]------------
[ +0.000044] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2819
tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] Modules linked in: xt_TPROXY iptable_mangle xt_owner xt_REDIRECT
nf_nat_redirect xt_set af_packet iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_set_hash_net i
[ +0.000100] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.11.2 #2
[ +0.000004] Hardware name: BIOSTAR Group A68N-5000/A68N-5000, BIOS 4.6.5
04/22/2014
[ +0.000002] Call Trace:
[ +0.000007] <IRQ>
[ +0.000010] ? dump_stack+0x46/0x5e
[ +0.000009] ? __warn+0xb4/0xd0
[ +0.000006] ? tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] ? tcp_ack+0xe95/0x1448
[ +0.000009] ? __ip_flush_pending_frames.isra.51+0x70/0x70
[ +0.000007] ? tcp_rcv_established+0x1ae/0x6b0
[ +0.000007] ? tcp_v4_do_rcv+0x12b/0x1e8
[ +0.000006] ? tcp_v4_rcv+0x7c4/0x880
[ +0.000011] ? nf_nat_ipv4_fn+0x53/0x150 [nf_nat_ipv4]
[ +0.000007] ? ip_local_deliver_finish+0x49/0x110
[ +0.000006] ? ip_local_deliver+0x66/0xd8
[ +0.000006] ? inet_del_offload+0x30/0x30
[ +0.000008] ? ip_sabotage_in+0x26/0x30 [br_netfilter]
[ +0.000009] ? nf_hook_slow+0x21/0xa0
[ +0.000005] ? ip_rcv+0x2e8/0x370
[ +0.000006] ? ip_local_deliver_finish+0x110/0x110
[ +0.000008] ? __netif_receive_skb_core+0x363/0x700
[ +0.000007] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000014] ? br_pass_frame_up+0x60/0xd8 [bridge]
[ +0.000012] ? br_handle_frame_finish+0x132/0x330 [bridge]
[ +0.000015] ? nf_ct_get_tuple+0x56/0x90 [nf_conntrack]
[ +0.000011] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? br_nf_hook_thresh+0xa7/0xb8 [br_netfilter]
[ +0.000009] ? ipt_do_table+0x2b5/0x3e0 [ip_tables]
[ +0.000007] ? br_nf_pre_routing_finish+0x173/0x2f8 [br_netfilter]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? nf_nat_ipv4_in+0x23/0x70 [nf_nat_ipv4]
[ +0.000007] ? br_nf_pre_routing+0x2c4/0x420 [br_netfilter]
[ +0.000007] ? br_nf_forward_arp+0x250/0x250 [br_netfilter]
[ +0.000007] ? nf_hook_slow+0x21/0xa0
[ +0.000010] ? br_handle_frame+0x1ae/0x2c8 [bridge]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000010] ? br_handle_local_finish+0x38/0x38 [bridge]
[ +0.000006] ? __netif_receive_skb_core+0x1d7/0x700
[ +0.000006] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000006] ? napi_gro_receive+0x6a/0xb0
[ +0.000012] ? rtl8169_poll+0x2c9/0x690 [r8169]
[ +0.000007] ? net_rx_action+0x1c6/0x2b8
[ +0.000007] ? __do_softirq+0xd8/0x200
[ +0.000005] ? irq_exit+0xa3/0xa8
[ +0.000007] ? do_IRQ+0x45/0xc0
[ +0.000009] ? common_interrupt+0x7f/0x7f
[ +0.000003] </IRQ>
[ +0.000013] ? acpi_idle_do_entry+0x2b/0xed0 [processor]
[ +0.000007] ? acpi_idle_enter+0xe1/0x288 [processor]
[ +0.000009] ? cpuidle_enter_state+0x128/0x1f0
[ +0.000008] ? do_idle+0x17a/0x1d8
[ +0.000006] ? cpu_startup_entry+0x68/0x70
[ +0.000009] ? start_secondary+0x138/0x158
[ +0.000005] ? start_cpu+0x14/0x14
[ +0.000008] ---[ end trace ab2d840ff39c9793 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ 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