* Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors
From: Tom Lendacky @ 2017-01-10 18:40 UTC (permalink / raw)
To: Christoph Hellwig, linux-pci; +Cc: Mauro Carvalho Chehab, netdev, linux-media
In-Reply-To: <1483994260-19797-3-git-send-email-hch@lst.de>
On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
> The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
> and pci_enable_msix_range interfaces. Switch it to use
> pci_irq_alloc_vectors instead.
I was just working on switching over to this API with some additional
changes / simplification. I'm ok with using this patch so that you get
the API removal accomplished. Going through the PCI tree just means
it will probably be easier for me to hold off on the additional changes
I wanted to make until later.
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 47 +++++++++++++-------------------
> drivers/net/ethernet/amd/xgbe/xgbe.h | 1 -
> 2 files changed, 19 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> index e76b7f6..be2690e 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> @@ -133,12 +133,13 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
> pdata->tx_ring_count);
> msi_count = roundup_pow_of_two(msi_count);
>
> - ret = pci_enable_msi_exact(pdata->pcidev, msi_count);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, msi_count, msi_count,
> + PCI_IRQ_MSI);
> if (ret < 0) {
> dev_info(pdata->dev, "MSI request for %u interrupts failed\n",
> msi_count);
>
> - ret = pci_enable_msi(pdata->pcidev);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, 1, 1, PCI_IRQ_MSI);
> if (ret < 0) {
> dev_info(pdata->dev, "MSI enablement failed\n");
> return ret;
> @@ -149,25 +150,26 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
>
> pdata->irq_count = msi_count;
>
> - pdata->dev_irq = pdata->pcidev->irq;
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
>
> if (msi_count > 1) {
> - pdata->ecc_irq = pdata->pcidev->irq + 1;
> - pdata->i2c_irq = pdata->pcidev->irq + 2;
> - pdata->an_irq = pdata->pcidev->irq + 3;
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
>
> for (i = XGBE_MSIX_BASE_COUNT, j = 0;
> (i < msi_count) && (j < XGBE_MAX_DMA_CHANNELS);
> i++, j++)
> - pdata->channel_irq[j] = pdata->pcidev->irq + i;
> + pdata->channel_irq[j] =
> + pci_irq_vector(pdata->pcidev, i);
> pdata->channel_irq_count = j;
>
> pdata->per_channel_irq = 1;
> pdata->channel_irq_mode = XGBE_IRQ_MODE_LEVEL;
> } else {
> - pdata->ecc_irq = pdata->pcidev->irq;
> - pdata->i2c_irq = pdata->pcidev->irq;
> - pdata->an_irq = pdata->pcidev->irq;
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 0);
> }
>
> if (netif_msg_probe(pdata))
> @@ -186,33 +188,22 @@ static int xgbe_config_msix(struct xgbe_prv_data *pdata)
> msix_count += max(pdata->rx_ring_count,
> pdata->tx_ring_count);
>
> - pdata->msix_entries = devm_kcalloc(pdata->dev, msix_count,
> - sizeof(struct msix_entry),
> - GFP_KERNEL);
> - if (!pdata->msix_entries)
> - return -ENOMEM;
> -
> - for (i = 0; i < msix_count; i++)
> - pdata->msix_entries[i].entry = i;
> -
> - ret = pci_enable_msix_range(pdata->pcidev, pdata->msix_entries,
> - XGBE_MSIX_MIN_COUNT, msix_count);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, XGBE_MSIX_MIN_COUNT,
> + msix_count, PCI_IRQ_MSIX);
> if (ret < 0) {
> dev_info(pdata->dev, "MSI-X enablement failed\n");
> - devm_kfree(pdata->dev, pdata->msix_entries);
> - pdata->msix_entries = NULL;
> return ret;
> }
>
> pdata->irq_count = ret;
>
> - pdata->dev_irq = pdata->msix_entries[0].vector;
> - pdata->ecc_irq = pdata->msix_entries[1].vector;
> - pdata->i2c_irq = pdata->msix_entries[2].vector;
> - pdata->an_irq = pdata->msix_entries[3].vector;
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
>
> for (i = XGBE_MSIX_BASE_COUNT, j = 0; i < ret; i++, j++)
> - pdata->channel_irq[j] = pdata->msix_entries[i].vector;
> + pdata->channel_irq[j] = pci_irq_vector(pdata->pcidev, i);
> pdata->channel_irq_count = j;
>
> pdata->per_channel_irq = 1;
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h b/drivers/net/ethernet/amd/xgbe/xgbe.h
> index f52a9bd..3bcb6f5 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe.h
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
> @@ -980,7 +980,6 @@ struct xgbe_prv_data {
> unsigned int desc_ded_count;
> unsigned int desc_sec_count;
>
> - struct msix_entry *msix_entries;
> int dev_irq;
> int ecc_irq;
> int i2c_irq;
>
^ permalink raw reply
* Re: [PATCH iproute2 2/3] ip: add ip sr command to control SR-IPv6 internal structures
From: Stephen Hemminger @ 2017-01-10 18:35 UTC (permalink / raw)
To: David Lebrun; +Cc: netdev
In-Reply-To: <1484066486-22152-3-git-send-email-david.lebrun@uclouvain.be>
On Tue, 10 Jan 2017 17:41:25 +0100
David Lebrun <david.lebrun@uclouvain.be> wrote:
> This patch add commands to support the tunnel source properties
> ("ip sr tunsrc") and the HMAC key -> secret, algorithm binding
> ("ip sr hmac").
>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
> ---
Man page?
^ permalink raw reply
* Re: [PATCH iproute2 1/3] sr: add header files for SR-IPv6
From: Stephen Hemminger @ 2017-01-10 18:33 UTC (permalink / raw)
To: David Lebrun; +Cc: netdev
In-Reply-To: <1484066486-22152-2-git-send-email-david.lebrun@uclouvain.be>
On Tue, 10 Jan 2017 17:41:24 +0100
David Lebrun <david.lebrun@uclouvain.be> wrote:
> This patch add the necessary header files to interface with the SR-IPv6 kernel
> implementation.
>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
> ---
> include/linux/seg6.h | 54 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/seg6_genl.h | 32 +++++++++++++++++++++++++
> include/linux/seg6_hmac.h | 21 +++++++++++++++++
> include/linux/seg6_iptunnel.h | 38 ++++++++++++++++++++++++++++++
> 4 files changed, 145 insertions(+)
> create mode 100644 include/linux/seg6.h
> create mode 100644 include/linux/seg6_genl.h
> create mode 100644 include/linux/seg6_hmac.h
> create mode 100644 include/linux/seg6_iptunnel.h
I get all headers from santized kernel headers generated by
$ make headers_install
but the segmentation stuff is missing.
When you added segment routing headers you forgot to export them.
Please send a patch to include/uapi/linux/Kbuild, after that is merged
I will pick them up.
Also this patch is only for net-next.
^ permalink raw reply
* Re: [PATCH net-next 1/7] flow_dissector: make local function static
From: David Miller @ 2017-01-10 18:32 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170110181816.18991-2-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 10 Jan 2017 10:18:10 -0800
> Fix warning: no previous prototype for ‘skb_flow_get_be16’
> Function is only used in this file, make it static.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Eric Dumazet already posted a patch which does this.
^ permalink raw reply
* Re: [PATCH net] net: skb_flow_get_be16() can be static
From: David Miller @ 2017-01-10 18:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1483989481.21472.16.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 09 Jan 2017 11:18:01 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Removes following sparse complain :
>
> net/core/flow_dissector.c:70:8: warning: symbol 'skb_flow_get_be16'
> was not declared. Should it be static?
>
> Fixes: 972d3876faa8 ("flow dissector: ICMP support")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix BUG in HMAC init when preemption is enabled
From: ericnetdev dumazet @ 2017-01-10 18:31 UTC (permalink / raw)
To: David Miller; +Cc: David Lebrun, netdev
In-Reply-To: <20170110.132946.149711848864334015.davem@davemloft.net>
2017-01-10 10:29 GMT-08:00 David Miller <davem@davemloft.net>:
> From: ericnetdev dumazet <erdnetdev@gmail.com>
>
> Oh noez, do we have an imposter? :-)
My normal gmail account seems to have a huge lag , or maybe this is
the IMAP access only.
;)
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix BUG in HMAC init when preemption is enabled
From: David Miller @ 2017-01-10 18:29 UTC (permalink / raw)
To: erdnetdev; +Cc: david.lebrun, netdev
In-Reply-To: <CAHTyZGxoCV=fUjbUq2r5vtH2rDqGScrf=ty2HYOL8KLhdf4R4w@mail.gmail.com>
From: ericnetdev dumazet <erdnetdev@gmail.com>
Oh noez, do we have an imposter? :-)
^ permalink raw reply
* Re: [PATCH] [v3] net: qcom/emac: add ethtool support
From: David Miller @ 2017-01-10 18:28 UTC (permalink / raw)
To: timur; +Cc: f.fainelli, netdev, alokc
In-Reply-To: <1483984992-21236-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Mon, 9 Jan 2017 12:03:12 -0600
> Add support for some ethtool methods: get/set link settings, get/set
> message level, get statistics, get link status, get ring params, get
> pause params, and restart autonegotiation.
>
> The code to collect the hardware statistics is moved into its own
> function so that it can be used by "get statistics" method.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Dave Taht @ 2017-01-10 18:24 UTC (permalink / raw)
To: Felix Fietkau
Cc: Johannes Berg, Linus Lüssing, Stephen Hemminger, M. Braun,
netdev@vger.kernel.org, David S . Miller, bridge,
linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <99c01ce6-d80c-790e-25e5-157be31aee9a@nbd.name>
On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau <nbd@nbd.name> wrote:
> On 2017-01-10 18:17, Dave Taht wrote:
>> In the case of wifi I have 3 issues with this line of thought.
>>
>> multicast in wifi has generally supposed to be unreliable. This makes
>> it reliable. reliability comes at a cost -
>>
>> multicast is typically set at a fixed low rate today. unicast is
>> retried at different rates until it succeeds - for every station
>> listening. If one station is already at the lowest rate, the total
>> cost of the transmit increases, rather than decreases.
>>
>> unicast gets block acks until it succeeds. Again, more delay.
>>
>> I think there is something like 31 soft-retries in the ath9k driver....
> If I remember correctly, hardware retries are counted here as well.
I chopped this to something more reasonable but never got around to
quantifying it, so never pushed the patch. I figured I'd measure ATF
in a noisy environment (which I'd be doing now if it weren't for
https://bugs.lede-project.org/index.php?do=details&task_id=368 )
first.
>> what happens to diffserv markings here? for unicast CS1 goes into the
>> BE queue, CS6, the VO queue. Do we go from one flat queue for all of
>> multicast to punching it through one of the hardware queues based on
>> the diffserv mark now with this patch?
I meant CS1=BK here. Tracing the path through the bridge code made my
head hurt, I can go look at some aircaps to see if the mcast->unicast
conversion respects those markings or not (my vote is *not*).
>> I would like it if there was a way to preserve the unreliability
>> (which multiple mesh protocols depend on), send stuff with QoSNoack,
>> etc - or dynamically choose (based on the rates of the stations)
>> between conventional multicast and unicast.
>>
>> Or - better, IMHO, keep sending multicast as is but pick the best of
>> the rates available to all the listening stations for it.
> The advantage of the multicast-to-unicast conversion goes beyond simply
> selecting a better rate - aggregation matters a lot as well, and that is
> simply incompatible with normal multicast.
Except for the VO queue which cannot aggregate. And for that matter,
using any other hardware queue than BE tends to eat a txop that would
otherwise possibly be combined with an aggregate.
(and the VI queue has always misbehaved, long on my todo list)
> Some multicast streams use lots of small-ish packets, the airtime impact
> of those is vastly reduced, even if the transmission has to be
> duplicated for a few stations.
The question was basically how far up does it scale. Arguably, for a
very few, well connected stations, this patch would help. For a
network with more - and more badly connected stations, I think it
would hurt.
What sorts of multicast traffic are being observed that flood the
network sufficiently to be worth optimizing out? arp? nd? upnp? mdns?
uftp? tv?
(my questions above are related to basically trying to setup a sane
a/b test, I've been building up a new testbed in noisy environment to
match the one I have in a quiet one, and don't have any "good" mcast
tests defined. Has anyone done an a/b test of this code with some
repeatable test already?)
(In my observations... The only truly heavy creator of a multicast
"burp" has tended to be upnp and mdns on smaller networks. Things like
nd and arp get more problematic as the number of stations go up also.
I can try things like abusing vlc or uftp to see what happens?)
I certainly agree multicast is a "problem" (I've seen 20-80% or more
of a given wifi network eaten by multicast) but I'm not convinced that
making it reliable, aggregatable unicast scales much past
basement-level testing of a few "good" stations, and don't know which
protocols are making it worse, the worst, in typical environments.
Certainly apple gear puts out a lot of multicast.
...
As best as I recall a recommendation in the 802.11-2012 standard was
that multicast packets be rate-limited so that you'd have a fixed
amount of crap after each beacon sufficient to keep the rest of the
unicast traffic flowing rapidly, instead of dumping everything into a
given beacon transmit.
That, combined with (maybe) picking the "best" union of known rates
per station, was essentially the strategy I'd intended[1] to pursue
for tackling the currently infinite wifi multicast queue - fq the
entries, have a fairly short queue (codel is not the best choice here)
drop from head, and limit the number of packets transmitted per beacon
to spread them out. That would solve the issue for sparse multicast
(dhcp etc), and smooth out the burps from bigger chunks while
impacting conventional unicast minimally.
There's also the pursuit of less multicast overall at least in some protocols
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05
>
> - Felix
[1] but make-wifi-fast has been out of funding since august
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* [PATCH net-next 7/7] fq_codel: fix set never used warning
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
prev_backlog was set in fq_codel_dequeue but never used.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/sched/sch_fq_codel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index a5ea0e9b6be4..6709c62123ad 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -290,7 +290,6 @@ static struct sk_buff *fq_codel_dequeue(struct Qdisc *sch)
struct fq_codel_flow *flow;
struct list_head *head;
u32 prev_drop_count, prev_ecn_mark;
- unsigned int prev_backlog;
begin:
head = &q->new_flows;
@@ -309,7 +308,6 @@ static struct sk_buff *fq_codel_dequeue(struct Qdisc *sch)
prev_drop_count = q->cstats.drop_count;
prev_ecn_mark = q->cstats.ecn_mark;
- prev_backlog = sch->qstats.backlog;
skb = codel_dequeue(sch, &sch->qstats.backlog, &q->cparams,
&flow->cvars, &q->cstats, qdisc_pkt_len,
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 6/7] ipv6: make udpv6_queue_rcv_skb static
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
Only called once, and no prototype.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/ipv6/udp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 4d5c4eee4b3f..2f8ad6477eaf 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -555,7 +555,7 @@ void udpv6_encap_enable(void)
}
EXPORT_SYMBOL(udpv6_encap_enable);
-int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
struct udp_sock *up = udp_sk(sk);
int is_udplite = IS_UDPLITE(sk);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 5/7] tcp_nv: make tcpnv_get_info static
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
Function only used in this file.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/ipv4/tcp_nv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_nv.c b/net/ipv4/tcp_nv.c
index 5de82a8d4d87..0065f44c40c1 100644
--- a/net/ipv4/tcp_nv.c
+++ b/net/ipv4/tcp_nv.c
@@ -424,8 +424,8 @@ static void tcpnv_acked(struct sock *sk, const struct ack_sample *sample)
}
/* Extract info for Tcp socket info provided via netlink */
-size_t tcpnv_get_info(struct sock *sk, u32 ext, int *attr,
- union tcp_cc_info *info)
+static size_t tcpnv_get_info(struct sock *sk, u32 ext, int *attr,
+ union tcp_cc_info *info)
{
const struct tcpnv *ca = inet_csk_ca(sk);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 4/7] dcb: validate netlink attribute link
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
The dcb netlink code was not validating that the IEEE_APP netlink
element was correctly formed. Initially discovered because of the
warning ‘dcbnl_ieee_app’ defined but not used.
This indicated that the message was not being fully validated.
Compile tested only. Do not have DCB setup.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/dcb/dcbnl.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 3202d75329b5..52f0f2fc0a51 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -178,10 +178,6 @@ static const struct nla_policy dcbnl_ieee_policy[DCB_ATTR_IEEE_MAX + 1] = {
[DCB_ATTR_IEEE_QCN_STATS] = {.len = sizeof(struct ieee_qcn_stats)},
};
-static const struct nla_policy dcbnl_ieee_app[DCB_ATTR_IEEE_APP_MAX + 1] = {
- [DCB_ATTR_IEEE_APP] = {.len = sizeof(struct dcb_app)},
-};
-
/* DCB number of traffic classes nested attributes. */
static const struct nla_policy dcbnl_featcfg_nest[DCB_FEATCFG_ATTR_MAX + 1] = {
[DCB_FEATCFG_ATTR_ALL] = {.type = NLA_FLAG},
@@ -1466,8 +1462,15 @@ static int dcbnl_ieee_set(struct net_device *netdev, struct nlmsghdr *nlh,
nla_for_each_nested(attr, ieee[DCB_ATTR_IEEE_APP_TABLE], rem) {
struct dcb_app *app_data;
+
if (nla_type(attr) != DCB_ATTR_IEEE_APP)
continue;
+
+ if (nla_len(attr) != sizeof(struct dcb_app)) {
+ err = -ERANGE;
+ goto err;
+ }
+
app_data = nla_data(attr);
if (ops->ieee_setapp)
err = ops->ieee_setapp(netdev, app_data);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/7] vxlan: remove unused variable
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
Fix drivers/net/vxlan.c: In function ‘neigh_reduce’:
warning: variable ‘saddr’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
drivers/net/vxlan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bb70dd5723b5..4147fd6a4837 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1553,7 +1553,7 @@ static int neigh_reduce(struct net_device *dev, struct sk_buff *skb)
struct vxlan_dev *vxlan = netdev_priv(dev);
struct nd_msg *msg;
const struct ipv6hdr *iphdr;
- const struct in6_addr *saddr, *daddr;
+ const struct in6_addr *daddr;
struct neighbour *n;
struct inet6_dev *in6_dev;
@@ -1562,7 +1562,6 @@ static int neigh_reduce(struct net_device *dev, struct sk_buff *skb)
goto out;
iphdr = ipv6_hdr(skb);
- saddr = &iphdr->saddr;
daddr = &iphdr->daddr;
msg = (struct nd_msg *)skb_transport_header(skb);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 3/7] socket: make sockfs_setattr static
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
Fix warning introduced by commit ead05568c7d5e
("net: core: Add a UID field to struct sock.")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index 3ef02e97ecf3..b7a63d5bc915 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -531,7 +531,7 @@ static ssize_t sockfs_listxattr(struct dentry *dentry, char *buffer,
return used;
}
-int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
+static int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
{
int err = simple_setattr(dentry, iattr);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 1/7] flow_dissector: make local function static
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20170110181816.18991-1-sthemmin@microsoft.com>
Fix warning: no previous prototype for ‘skb_flow_get_be16’
Function is only used in this file, make it static.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/core/flow_dissector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index fe4e1531976c..1b7673aac59d 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -67,8 +67,8 @@ EXPORT_SYMBOL(skb_flow_dissector_init);
* The function will try to retrieve a be32 entity at
* offset poff
*/
-__be16 skb_flow_get_be16(const struct sk_buff *skb, int poff, void *data,
- int hlen)
+static __be16 skb_flow_get_be16(const struct sk_buff *skb, int poff,
+ void *data, int hlen)
{
__be16 *u, _u;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 0/7] warning related fixes
From: Stephen Hemminger @ 2017-01-10 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
These are all patches to fix other warnings found while cleaning
up netvsc driver.
Stephen Hemminger (7):
flow_dissector: make local function static
vxlan: remove unused variable
socket: make sockfs_setattr static
dcb: validate netlink attribute link
tcp_nv: make tcpnv_get_info static
ipv6: make udpv6_queue_rcv_skb static
fq_codel: fix set never used warning
drivers/net/vxlan.c | 3 +--
net/core/flow_dissector.c | 4 ++--
net/dcb/dcbnl.c | 11 +++++++----
net/ipv4/tcp_nv.c | 4 ++--
net/ipv6/udp.c | 2 +-
net/sched/sch_fq_codel.c | 2 --
net/socket.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix BUG in HMAC init when preemption is enabled
From: ericnetdev dumazet @ 2017-01-10 18:16 UTC (permalink / raw)
To: David Lebrun; +Cc: netdev
In-Reply-To: <1484055562-6414-1-git-send-email-david.lebrun@uclouvain.be>
2017-01-10 5:39 GMT-08:00 David Lebrun <david.lebrun@uclouvain.be>:
> When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
> seg6_hmac_init() is called during the initialization of the ipv6 module.
> This causes a subsequent call to smp_processor_id() with preemption
> enabled, resulting in the following trace.
I disagree with your fix. Keeping GFP_KERNEL for all these per cpu
allocations is needed.
What about the simpler :
Rationale : we only need to get the size of the allocation, we do not
care of migration here, all cpus having the same allocation.
Another issue with this is code is that in case of an allocation
error, no cleanup is performed to free prior allocations.
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a46e7aceee45b2044d4b4338dc3aed88807..b31d682816503129e12d3eae5b70a8cbce8525a7
100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -400,7 +400,7 @@ static int seg6_hmac_init_algo(void)
*p_tfm = tfm;
}
- p_tfm = this_cpu_ptr(algo->tfms);
+ p_tfm = __this_cpu_ptr(algo->tfms);
tfm = *p_tfm;
shsize = sizeof(*shash) + crypto_shash_descsize(tfm);
^ permalink raw reply
* Re: next-20170110 build: 1 failures 4 warnings (next-20170110)
From: Mark Brown @ 2017-01-10 18:16 UTC (permalink / raw)
To: Michael Scherban, Murali Karicheri, Sekhar Nori, David S. Miller
Cc: kernel-build-reports, linaro-kernel, linux-next, linux-arm-kernel,
netdev
In-Reply-To: <E1cQqkO-0005XB-2K@optimist>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Tue, Jan 10, 2017 at 07:21:32AM +0000, Build bot for Mark Brown wrote:
Today's -next fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
caused by 6a8162e99ef344 (net: netcp: store network statistics in 64
bits). It's assigning the function
static struct rtnl_link_stats64 *
netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
to ndo_get_stats64 which expects a function returning void.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 1/3] Revert "icmp: avoid allocating large struct on stack"
From: David Miller @ 2017-01-10 18:12 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: eric.dumazet, brouer, netdev
In-Reply-To: <CAM_iQpUbcVogq7jGePkgPJ0z_J=46hnK8KcTiX1svVXr1Hoh-w@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 10 Jan 2017 10:06:01 -0800
> On Mon, Jan 9, 2017 at 10:52 AM, David Miller <davem@davemloft.net> wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 09 Jan 2017 10:07:04 -0800
>>
>>> You really should come to netdev conferences so that you understand
>>> goals and efforts, instead of living in your cave.
>>
>> I completely agree with Eric.
>>
>> Cong we have a very serious problem with you exactly because you make
>> quite vicious emotional statements targetted at other developers
>> merely when they say something you disagree with.
>
> What emotional? Pointing out Eris's words from 4 years ago is NOT
> emotional, it is just a help.
Saying "Facepalm" is emotional and has nothing to do with the
technical issues.
You can keep showing us how expertly you can deflect the real
issue we are discussion here, but that won't improve the situation
at all I am afraid.
> Not everyone is as free to travel to Canada without a visa as you,
> unfortunately.
We hold netdev in other countries all over the world, stop making
excuses.
^ permalink raw reply
* Re: [net-next PATCH 1/3] Revert "icmp: avoid allocating large struct on stack"
From: Cong Wang @ 2017-01-10 18:06 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, Jesper Dangaard Brouer,
Linux Kernel Network Developers
In-Reply-To: <20170109.135259.988711786570465428.davem@davemloft.net>
On Mon, Jan 9, 2017 at 10:52 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 09 Jan 2017 10:07:04 -0800
>
>> You really should come to netdev conferences so that you understand
>> goals and efforts, instead of living in your cave.
>
> I completely agree with Eric.
>
> Cong we have a very serious problem with you exactly because you make
> quite vicious emotional statements targetted at other developers
> merely when they say something you disagree with.
What emotional? Pointing out Eris's words from 4 years ago is NOT
emotional, it is just a help.
>
> This is completely unacceptable behavior, and you must stop doing
> this, now.
>
> And I am absolutely positive that if you had met us all in person at
> netdev you would not be treating us like this.
This is not an invitation from any point of view, David.
>
> So please do us a _HUGE_ favor, and leave your cave, and come to
> an upcoming netdev.
>
Not everyone is as free to travel to Canada without a visa as you,
unfortunately.
^ permalink raw reply
* Re: [net-next PATCH 1/3] Revert "icmp: avoid allocating large struct on stack"
From: Cong Wang @ 2017-01-10 18:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesper Dangaard Brouer, Linux Kernel Network Developers
In-Reply-To: <1483985224.21472.3.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, Jan 9, 2017 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> We are in 2017. Whatever was said in 2013 is irrelevant.
>
> You really should come to netdev conferences so that you understand
> goals and efforts, instead of living in your cave.
>
> Then you can slap me in the face, since this is obviously your desire.
>
> Then, we will drink a beer and relax.
LOL...
Eric, you really need to focus on the technical part, which is you
asked for a question you already knew the answer 4 years ago,
and now you are going to be against yourself.
/me don't contribute anything expect helping you to remember
what you said.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2
From: Florian Fainelli @ 2017-01-10 17:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Andrew Lunn, Uwe Kleine-König, Andrey Smirnov
In-Reply-To: <20170110095524.GA1827@nanopsycho>
On 01/10/2017 01:55 AM, Jiri Pirko wrote:
> Mon, Jan 09, 2017 at 07:06:39PM CET, f.fainelli@gmail.com wrote:
>> On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@gmail.com wrote:
>>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@savoirfairelinux.com wrote:
>>>>>> Hi Jiri,
>>>>>>
>>>>>> Jiri Pirko <jiri@resnulli.us> writes:
>>>>>>
>>>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>>>
>>>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>>>> from dsa because its use there is incorrect.
>>>>>>
>>>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>>>
>>>>> Yes, please revert it. It is only in net-next.
>>>>
>>>> Maybe the use case can be understood before reverting the change. How do
>>>> we actually the physical port number of an Ethernet switch per-port
>>>> network device? The name is not enough, because there are plenty of
>>>> cases where we need to manipulate a physical port number (be it just for
>>>> informational purposes).
>>>
>>> Like what?
>>
>> Specifying the physical port number (and derive a queue number
>> eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>> where there is an action/queue/port destination argument that gets
>> programmed into the hardware.
>
> Could you point me to a real example? User command?
ethtool --config-nfc moca flow-type udp4 src-ip 192.168.1.20 dst-ip \
192.168.1.10 src-port 49884 dst-port 5001 action 2
Where 2 here designates a port number, users need to be able to look up
the physical port number corresponding to an interface to know which
value to put in this command.
Yes I know we can do the same thing with cls_flower, possibly by
referencing network devices directly.
>
>
>>
>> You already have the originating port number from the interface you call
>> the method against, but you also need the destination port number since
>> that is what the HW understands.
>
> This is internal to kernel? I fail to understand what you mean exactly.
See the command above, from using the "moca" netdev here, we can access
the DSA private network device (dsa_slave_priv) structure and get the
port number from there, and pass this down to the switch driver. The
switch driver also takes another port number (and eventually a queue
number) to program classification filters.
>
>
>>
>> Aside from that, it is useful for allowing interface naming in user
>> space if you don't want to use labels.
>>
>>>
>>> Why the name is not enough? This is something propagated to userspace
>>> and never used internally in kernel.
>>
>> Because the name is not reflective of the port number in some switches.
>> In my case for instance, we have 5 ports that are named after the
>> entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>> MoCA interface, and the CPU)
>>
>
> Again, I'm missing why you need a portnumber as a Integer to userspace.
> From driver, you can expose phys_port_name:
If we are exposing the port name here, we may as well expose the DSA
"label" instead of the physical port number number?
I don't deny my change may be misusing what phys_port_id was originally
designed for, but providing "p0" instead of "0" to user-space, what
value is there in adding the "p" in front really?
--
Florian
^ permalink raw reply
* ATENCIÓN
From: administrador @ 2017-01-10 16:27 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: 006524
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] net: switchdev: Prepare for deferred functions modifying objects
From: Florian Fainelli @ 2017-01-10 17:57 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, vivien.didelot, andrew, marcelo.leitner
In-Reply-To: <20170110100901.GB1827@nanopsycho>
On 01/10/2017 02:09 AM, Jiri Pirko wrote:
> Mon, Jan 09, 2017 at 09:45:20PM CET, f.fainelli@gmail.com wrote:
>> In preparation for adding support for deferred dump operations, allow
>> specifying a deferred function whose signature allows read/write
>> objects.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> net/switchdev/switchdev.c | 21 ++++++++++++++++-----
>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>> index 017801f9dbaa..3d70ad02c617 100644
>> --- a/net/switchdev/switchdev.c
>> +++ b/net/switchdev/switchdev.c
>> @@ -100,11 +100,14 @@ static DEFINE_SPINLOCK(deferred_lock);
>>
>> typedef void switchdev_deferred_func_t(struct net_device *dev,
>> const void *data);
>> +typedef void switchdev_deferred_func_rw_t(struct net_device *dev,
>> + void *data);
>>
>> struct switchdev_deferred_item {
>> struct list_head list;
>> struct net_device *dev;
>> switchdev_deferred_func_t *func;
>> + switchdev_deferred_func_rw_t *func_rw;
>
> I'm missing why you need to have 2 funcs here. Why you just can't re-use
> func?
I wanted to let the existing callers be passed down a const void *data,
and not update them with void *data, since there is value in keeping
that annotated. This may be considered overkill, I don't know.
--
Florian
^ 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