* Re: [PATCH net-next] netfilter: xt_quota: fix the behavior of xt_quota module
From: Pablo Neira Ayuso @ 2018-10-02 10:52 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Chenbo Feng, Linux NetDev, netfilter-devel, kernel-team,
Lorenzo Colitti, Chenbo Feng
In-Reply-To: <20181002105125.uv7mcitvaalpjueo@salvia>
On Tue, Oct 02, 2018 at 12:51:25PM +0200, Pablo Neira Ayuso wrote:
> On Tue, Oct 02, 2018 at 03:38:24AM -0700, Maciej Żenczykowski wrote:
> > > Well, you will need a kernel + userspace update anyway, right?
> >
> > It's true you need new iptables userspace to *see* during dump and/or
> > manually *set* during restore the remain counter.
> >
> > However, (and I believe Chenbo tested this) just a new kernel is
> > enough to fix the problem of modifications within the table resetting
> > the counter.
> > This is because the data gets copied out of kernel and back into
> > kernel by old iptables without any further modifications.
> > ie. the new kernel not clearing the field on copy to userspace and
> > honouring it on copy to kernel is sufficient.
>
> I see, Willem removed this behaviour in newer kernels. The private
> area is now zeroed, is that what you mean right? So I guess this
> cannot be done transparently.
>
> Anyway, I think the --remain approach to fix this longstanding
> problem from iptables :-).
Argh, broken sentence: I mean, I think it's the way to go for
iptables.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Jiri Benc @ 2018-10-02 10:54 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, christian, stephen, David Ahern
In-Reply-To: <20181002002851.5002-3-dsahern@kernel.org>
On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
> Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
> into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
> NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
IFA_TARGET_NETNSID is not a filter.
"Filter" returns a subset of the results. It's kind of optimization
when one is interested only in some data but not all of them. Instead
of dumping everything, going through the results and picking only the
data one is interested in, it's better to pass a filter and get only
the relevant data. But you're not really required to: you can filter in
your app.
By contrast, IFA_TARGET_NETNSID returns a completely different set of
data. It's impossible to not set it and filter the results in your app.
As the consequence, IFA_TARGET_NETNSID must not set NLM_F_DUMP_FILTERED
(if not complemented by a real filter).
I understand that you want to differentiate between data dumped without
and with IFA_TARGET_NETNSID present. But we already have that: the
IFA_TARGET_NETNSID attribute is returned back in the latter case.
Nacked-by: Jiri Benc <jbenc@redhat.com>
Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Christian Brauner @ 2018-10-02 11:03 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002125425.35e96876@redhat.com>
On Tue, Oct 02, 2018 at 12:54:25PM +0200, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
> > Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
> > into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
> > NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
>
> IFA_TARGET_NETNSID is not a filter.
Well, it's a namespace filter that's how I saw it.
>
> "Filter" returns a subset of the results. It's kind of optimization
That's an argument I can buy.
> when one is interested only in some data but not all of them. Instead
> of dumping everything, going through the results and picking only the
> data one is interested in, it's better to pass a filter and get only
> the relevant data. But you're not really required to: you can filter in
> your app.
>
> By contrast, IFA_TARGET_NETNSID returns a completely different set of
> data. It's impossible to not set it and filter the results in your app.
>
> As the consequence, IFA_TARGET_NETNSID must not set NLM_F_DUMP_FILTERED
> (if not complemented by a real filter).
>
> I understand that you want to differentiate between data dumped without
> and with IFA_TARGET_NETNSID present. But we already have that: the
> IFA_TARGET_NETNSID attribute is returned back in the latter case.
>
> Nacked-by: Jiri Benc <jbenc@redhat.com>
>
> Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Jiri Benc @ 2018-10-02 11:06 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, christian, stephen, David Ahern
In-Reply-To: <20181002002851.5002-4-dsahern@kernel.org>
On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> kernel that it believes it is sending the right header struct for the
> dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
Why is this limited to dumps? Other kind of netlink messages contain
the common struct, too. When introducing such mechanism, please make it
generic.
Last time when we were discussing strict checking in netlink, it was
suggested to add a socket option instead of adding NLM flags[1].
It makes a lot of sense: the number of flags is very limited and we'd
run out of them pretty fast. It's not just the header structure that
is currently checked sloppily. It's also attributes, flags in
attributes, etc. We can't assign a flag to all of them.
You should also consider a different name for the flag: it should
reflect what the effect of the flag is. "Proper header" is not an
effect, it's a requirement for the message to pass. The effect is
enforced strict checking of the header.
Jiri
[1] https://marc.info/?l=linux-netdev&m=144492718118955
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 01/25] net/netlink: Pass extack to dump callbacks
From: Christian Brauner @ 2018-10-02 11:07 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-2-dsahern@kernel.org>
On Mon, Oct 01, 2018 at 05:28:27PM -0700, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Pass extack to dump callbacks by adding extack to netlink_dump_control,
> transferring to netlink_callback and adding to the netlink_dump. Update
> rtnetlink as the first user. Update netlink_dump to add any message after
> the dump_done_errno.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
This makes sense to me as it would allow us to report back more
meaningful errors to userspace.
> ---
> include/linux/netlink.h | 2 ++
> net/core/rtnetlink.c | 1 +
> net/netlink/af_netlink.c | 20 +++++++++++++++-----
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/netlink.h b/include/linux/netlink.h
> index 71f121b66ca8..8fc90308a653 100644
> --- a/include/linux/netlink.h
> +++ b/include/linux/netlink.h
> @@ -176,6 +176,7 @@ struct netlink_callback {
> void *data;
> /* the module that dump function belong to */
> struct module *module;
> + struct netlink_ext_ack *extack;
> u16 family;
> u16 min_dump_alloc;
> unsigned int prev_seq, seq;
> @@ -197,6 +198,7 @@ struct netlink_dump_control {
> int (*done)(struct netlink_callback *);
> void *data;
> struct module *module;
> + struct netlink_ext_ack *extack;
> u16 min_dump_alloc;
> };
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 35162e1b06ad..da91b38297d3 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -4689,6 +4689,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> .dump = dumpit,
> .min_dump_alloc = min_dump_alloc,
> .module = owner,
> + .extack = extack
> };
> err = netlink_dump_start(rtnl, skb, nlh, &c);
> /* netlink_dump_start() will keep a reference on
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index e3a0538ec0be..7094156c94f0 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -129,7 +129,7 @@ static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
> "nlk_cb_mutex-MAX_LINKS"
> };
>
> -static int netlink_dump(struct sock *sk);
> +static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack);
>
> /* nl_table locking explained:
> * Lookup and traversal are protected with an RCU read-side lock. Insertion
> @@ -1981,7 +1981,7 @@ static int netlink_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>
> if (nlk->cb_running &&
> atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
> - ret = netlink_dump(sk);
> + ret = netlink_dump(sk, NULL);
> if (ret) {
> sk->sk_err = -ret;
> sk->sk_error_report(sk);
> @@ -2168,7 +2168,7 @@ EXPORT_SYMBOL(__nlmsg_put);
> * It would be better to create kernel thread.
> */
>
> -static int netlink_dump(struct sock *sk)
> +static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack)
> {
> struct netlink_sock *nlk = nlk_sk(sk);
> struct netlink_callback *cb;
> @@ -2222,8 +2222,11 @@ static int netlink_dump(struct sock *sk)
> skb_reserve(skb, skb_tailroom(skb) - alloc_size);
> netlink_skb_set_owner_r(skb, sk);
>
> - if (nlk->dump_done_errno > 0)
> + if (nlk->dump_done_errno > 0) {
> + cb->extack = extack;
> nlk->dump_done_errno = cb->dump(skb, cb);
> + cb->extack = NULL;
> + }
>
> if (nlk->dump_done_errno > 0 ||
> skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) {
> @@ -2246,6 +2249,12 @@ static int netlink_dump(struct sock *sk)
> memcpy(nlmsg_data(nlh), &nlk->dump_done_errno,
> sizeof(nlk->dump_done_errno));
>
> + if (extack && extack->_msg && nlk->flags & NETLINK_F_EXT_ACK) {
> + nlh->nlmsg_flags |= NLM_F_ACK_TLVS;
> + if (!nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
> + nlmsg_end(skb, nlh);
> + }
> +
> if (sk_filter(sk, skb))
> kfree_skb(skb);
> else
> @@ -2307,6 +2316,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
> cb->module = control->module;
> cb->min_dump_alloc = control->min_dump_alloc;
> cb->skb = skb;
> + cb->extack = control->extack;
>
> if (control->start) {
> ret = control->start(cb);
> @@ -2319,7 +2329,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
>
> mutex_unlock(nlk->cb_mutex);
>
> - ret = netlink_dump(sk);
> + ret = netlink_dump(sk, cb->extack);
>
> sock_put(sk);
>
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Jiri Benc @ 2018-10-02 11:07 UTC (permalink / raw)
To: Christian Brauner; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002110259.tqh4uz46g3ihakir@brauner.io>
On Tue, 2 Oct 2018 13:03:00 +0200, Christian Brauner wrote:
> Well, it's a namespace filter that's how I saw it.
That would imply that without it, you get data from all name spaces
(= unfiltered by name space), which is not what's happening :-)
Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Christian Brauner @ 2018-10-02 11:09 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002130749.422272fc@redhat.com>
On Tue, Oct 02, 2018 at 01:07:49PM +0200, Jiri Benc wrote:
> On Tue, 2 Oct 2018 13:03:00 +0200, Christian Brauner wrote:
> > Well, it's a namespace filter that's how I saw it.
>
> That would imply that without it, you get data from all name spaces
> (= unfiltered by name space), which is not what's happening :-)
Yeah, you convinced me already. I'm not one to argue for the sake of
winning an argument (At least I hope so.) :)
Christian
^ permalink raw reply
* Re: [PATCH] team: set IFF_SLAVE on team ports
From: Jiri Pirko @ 2018-10-02 11:12 UTC (permalink / raw)
To: Chas Williams; +Cc: Stephen Hemminger, Jan Blunck, LKML, netdev
In-Reply-To: <b3cf1799-7ee2-47b3-e9ed-98e41ae56853@gmail.com>
Mon, Oct 01, 2018 at 04:06:16PM CEST, 3chas3@gmail.com wrote:
>
>
>On 09/30/18 05:34, Jiri Pirko wrote:
>> Sun, Sep 30, 2018 at 11:38:05AM CEST, stephen@networkplumber.org wrote:
>> > On Sun, 30 Sep 2018 09:14:14 +0200
>> > Jiri Pirko <jiri@resnulli.us> wrote:
>> >
>> > > Thu, Sep 27, 2018 at 04:04:26PM CEST, 3chas3@gmail.com wrote:
>> > > >
>> > > >
>> > > > On 07/10/15 02:41, Jiri Pirko wrote:
>> > > > > Thu, Jul 09, 2015 at 05:36:55PM CEST, jblunck@infradead.org wrote:
>> > > > > > On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> > > > > > > Thu, Jul 09, 2015 at 11:58:34AM CEST, jblunck@infradead.org wrote:
>> > > > > > > > The code in net/ipv6/addrconf.c:addrconf_notify() tests for IFF_SLAVE to
>> > > > > > > > decide if it should start the address configuration. Since team ports
>> > > > > > > > shouldn't get link-local addresses assigned lets set IFF_SLAVE when linking
>> > > > > > > > a port to the team master.
>> > > > > > >
>> > > > > > > I don't want to use IFF_SLAVE in team. Other master-slave devices are
>> > > > > > > not using that as well, for example bridge, ovs, etc.
>> > > > > >
>> > > > > > Maybe they need to get fixed too. I've used that flag because it is
>> > > > > > documented as
>> > > > > > a "slave of a load balancer" which describes what a team port is.
>> > > > > >
>> > > > > > > I think that this should be fixed in addrconf_notify. It should lookup
>> > > > > > > if there is a master on top and bail out in that case.
>> > > > > >
>> > > > > > There are other virtual interfaces that have a master assigned and want to
>> > > > > > participate in IPv6 address configuration.
>> > > > >
>> > > > > Can you give me an example?
>> > > >
>> > > > I would like to revisit this patch (yes, I know it has been a while). I
>> > > > believe the VRF implementation uses master to group the interfaces under
>> > > > a single interface.
>> > > >
>> > > > I don't see a reason not to use IFF_SLAVE since team and bonding are fairly
>> > > > similar.
>> > >
>> > > Again, why do you need team port to have IFF_SLAVE flag? What do you
>> > > want to achieve
>> >
>> > Without setting this flag IPv6 will try and make a link specific address.
You are talking about addrconf_notify() right? Easy to fix to check
something more convenient. Like netif_is_lag_port() if you want to avoid
it for bond/team. netif_is_ovs_port(), netif_is_bridge_port() etc. Lot's
of helpers to cover this.
>>
>> Why is it not an issue with bridge, ovs, and other master-slave devices?
>>
>
>It very well might be an issue for bridge and ovs. Other master-slave
>devices include the existing VRF implementation in the kernel and those slave
>interfaces will certainly want to use IPv6.
>
>However, IFF_SLAVE has a specific meaning:
>
>./include/uapi/linux/if.h: * @IFF_SLAVE: slave of a load balancer. Volatile.
I know that some userspace apps are using this flag to determine a
"bonding slave". I don't think that they care much about eql...
>
>The bonding driver is not the only user:
>
>./drivers/net/eql.c:#define eql_is_slave(dev) ((dev->flags & IFF_SLAVE) ==
>IFF_SLAVE)
>./drivers/net/eql.c: slave->dev->flags &= ~IFF_SLAVE;
>./drivers/net/eql.c: slave->dev->flags |= IFF_SLAVE;
>
>The team driver would like to use this same flag since it is a load balancer
>as well. The side effect of not assigning IPv6 is a bonus. The fact that
No, please leave IFF_SLAVE as it is. Both kernel and userspace have
their clear indications right now about the master/slave relationships.
>bridges and ovs are also likely broken is a different issue. Should there be
>a another flag that says "layer 2 only"? Very possibly, but that is
>something all these interfaces should be using to include bonding, team, eql,
>obs, bridge etc. That's not a reasonable objection to labeling the team
>slave as slaves since they are literally slaves of a load balancer.
>
>
>
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Christian Brauner @ 2018-10-02 11:18 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002130614.77856ff8@redhat.com>
On Tue, Oct 02, 2018 at 01:06:14PM +0200, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> > Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> > kernel that it believes it is sending the right header struct for the
> > dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
>
> Why is this limited to dumps? Other kind of netlink messages contain
> the common struct, too. When introducing such mechanism, please make it
> generic.
>
> Last time when we were discussing strict checking in netlink, it was
> suggested to add a socket option instead of adding NLM flags[1].
I didn't find this in the linked thread. What I find interesting and
convincing is one of Dave's points:
"I'm beginning to wonder if we can just change this unilaterally to
not ignore unrecognized attributes.
I am increasingly certain that things that would "break" we wouldn't
want to succeed anyways." [1]
:)
But a socket option or this header flag both sound acceptable to me. Was
there any more detail on how a socket option would look like, i.e. an
api proposal or something?
[1]: https://marc.info/?l=linux-netdev&m=144522081220166&w=2
> It makes a lot of sense: the number of flags is very limited and we'd
> run out of them pretty fast. It's not just the header structure that
> is currently checked sloppily. It's also attributes, flags in
> attributes, etc. We can't assign a flag to all of them.
>
> You should also consider a different name for the flag: it should
> reflect what the effect of the flag is. "Proper header" is not an
> effect, it's a requirement for the message to pass. The effect is
> enforced strict checking of the header.
>
> Jiri
>
> [1] https://marc.info/?l=linux-netdev&m=144492718118955
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Jiri Benc @ 2018-10-02 11:27 UTC (permalink / raw)
To: Christian Brauner; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002111831.j6ov4bqhy3zi3vj6@brauner.io>
On Tue, 2 Oct 2018 13:18:32 +0200, Christian Brauner wrote:
> I didn't find this in the linked thread.
Maybe it was suggested in another thread or in person on a conference,
I can't remember, it's too long ago, sorry.
> What I find interesting and convincing is one of Dave's points:
>
> "I'm beginning to wonder if we can just change this unilaterally to
> not ignore unrecognized attributes.
>
> I am increasingly certain that things that would "break" we wouldn't
> want to succeed anyways." [1]
It's unfortunate we can't do that. I'd like it.
> But a socket option or this header flag both sound acceptable to me. Was
> there any more detail on how a socket option would look like, i.e. an
> api proposal or something?
Look at how NETLINK_CAP_ACK and NETLINK_EXT_ACK is implemented.
Jiri
^ permalink raw reply
* [PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results
From: Mike Manning @ 2018-10-02 11:40 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
smaller than min mtu"). While one should not get fragments smaller than
the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
conformance test suite (v6eval) for IPv6 Ready Logo results in 18
failures representing over 5% of the score.
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
The failures which are reverted by this fix are:
Section 1: RFC 2460 - IPv6 Specification
Test v6LC.1.2.4: Extension Header Processing Order
33-34
Test v6LC.1.3.1: Fragment Reassembly
67-72
Test v6LC.1.3.2: Reassembly Time Exceeded
73-76
Test v6LC.1.3.3: Fragment Header M-Bit Set, Payload Length Invalid
78
Section 5: RFC 4443 - ICMPv6
Test v6LC.5.1.6: Erroneous Header Field (Parameter Problem Generation)
20 Erroneous Header Field (Parameter Problem Generation)
Test v6LC.5.1.10: Error Condition With Multicast Destination
31 Part B: Echo Request Reassembly Timeout
Test v6LC.5.1.11: Error Condition With Non-Unique Source - Unspecified
35 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.12: Error Condition With Non-Unique Source - Multicast
40 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.13: Error Condition With Non-Unique Source Anycast (Routers Only)
45 Part C: Echo Request Reassembly Timeout
net/ipv6/netfilter/nf_conntrack_reasm.c | 4 ----
net/ipv6/reassembly.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 8f68a518d9db..8c69c4fc78d8 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -559,10 +559,6 @@ int nf_ct_frag6_gather(struct net *net, struct sk_buff *skb, u32 user)
hdr = ipv6_hdr(skb);
fhdr = (struct frag_hdr *)skb_transport_header(skb);
- if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
- fhdr->frag_off & htons(IP6_MF))
- return -EINVAL;
-
skb_orphan(skb);
fq = fq_find(net, fhdr->identification, user, hdr,
skb->dev ? skb->dev->ifindex : 0);
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 5c5b4f79296e..b4e558ab39fa 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -456,10 +456,6 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
return 1;
}
- if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
- fhdr->frag_off & htons(IP6_MF))
- goto fail_hdr;
-
iif = skb->dev ? skb->dev->ifindex : 0;
fq = fq_find(net, fhdr->identification, hdr, iif);
if (fq) {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] isdn/hisax: Fix fall-through annotation
From: David Miller @ 2018-10-02 18:24 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <20181002102832.GA4873@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 2 Oct 2018 12:28:32 +0200
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] declance: Fix continuation with the adapter identification message
From: David Miller @ 2018-10-02 18:32 UTC (permalink / raw)
To: macro; +Cc: netdev, linux-kernel
In-Reply-To: <alpine.LFD.2.21.1810021401530.5483@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 2 Oct 2018 14:23:45 +0100 (BST)
> Fix a commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
> continuation lines") regression with the `declance' driver, which caused
> the adapter identification message to be split between two lines, e.g.:
>
> declance.c: v0.011 by Linux MIPS DECstation task force
> tc6: PMAD-AA
> , addr = 08:00:2b:1b:2a:6a, irq = 14
> tc6: registered as eth0.
>
> Address that properly, by printing identification with a single call,
> making the messages now look like:
>
> declance.c: v0.011 by Linux MIPS DECstation task force
> tc6: PMAD-AA, addr = 08:00:2b:1b:2a:6a, irq = 14
> tc6: registered as eth0.
>
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
Applied.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2018-10-02
From: David Miller @ 2018-10-02 18:47 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87ftxojn1l.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 02 Oct 2018 20:06:30 +0300
> here's the first pull request to net-next for 4.20. This is rather large
> due to mt76 refactoring and me not being able to send the pull request
> earlier, sorry about that.
>
> Most of this has been in linux-next for some time now so I'm hoping
> there should not be any nasty surprises, but please let me know if you
> have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Or Gerlitz @ 2018-10-02 12:21 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <20180927125339.GA14666@orbyte.nwl.cc>
On Thu, Sep 27, 2018 at 3:53 PM Phil Sutter <phil@nwl.cc> wrote:
> On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote:
> > Something is still broken also after commit b45e300 "libnetlink: don't
> > return error on success" - when error is returned, the error code is
> > success..
> >
> > $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> > ip_flags nofirstfrag action drop && echo "success" || echo "failed"
> >
> > RTNETLINK answers: Operation not supported
> > success
>
> Hmm, I can't reproduce this. My HEAD is at the commit you mentioned:
>
> | % sudo ./tc/tc filter add dev d0 protocol ip parent ffff: flower skip_sw ip_flags nofirstfrag action drop
> | RTNETLINK answers: Operation not supported
> | We have an error talking to the kernel, -1
> | % echo $?
> | 2
>
> Are you sure you tested the right binary?
double checked now, seems broken on my end:
$ git log --oneline -3
b45e300 libnetlink: don't return error on success
5dc2204 testsuite: add libmnl
8804a8c Makefile: Add check target
$./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower
skip_sw ip_flags frag action drop && echo "success" || echo "failed"
success
$ ./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower
skip_sw ip_flags firstfrag action drop && echo "success" || echo
"failed"
RTNETLINK answers: Operation not supported
success
$ ./tc/tc filter show dev enp33s0f0 ingress
filter protocol ip pref 49152 flower chain 0
filter protocol ip pref 49152 flower chain 0 handle 0x1
eth_type ipv4
ip_flags frag
skip_sw
in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] nfp: bpf: support big map entries
From: Daniel Borkmann @ 2018-10-02 12:41 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: netdev, oss-drivers
In-Reply-To: <20181002013034.8144-1-jakub.kicinski@netronome.com>
On 10/02/2018 03:30 AM, Jakub Kicinski wrote:
> Hi!
>
> This series makes the control message parsing for interacting
> with BPF maps more flexible. Up until now we had a hard limit
> in the ABI for key and value size to be 64B at most. Using
> TLV capability allows us to support large map entries.
>
> Jakub Kicinski (3):
> nfp: bpf: parse global BPF ABI version capability
> nfp: allow apps to request larger MTU on control vNIC
> nfp: bpf: allow control message sizing for map ops
>
> drivers/net/ethernet/netronome/nfp/bpf/cmsg.c | 70 ++++++++++++++++---
> drivers/net/ethernet/netronome/nfp/bpf/fw.h | 11 ++-
> drivers/net/ethernet/netronome/nfp/bpf/main.c | 52 ++++++++++++--
> drivers/net/ethernet/netronome/nfp/bpf/main.h | 11 +++
> drivers/net/ethernet/netronome/nfp/nfp_app.h | 4 ++
> .../ethernet/netronome/nfp/nfp_net_common.c | 14 +++-
> .../net/ethernet/netronome/nfp/nfp_net_ctrl.h | 2 +-
> 7 files changed, 142 insertions(+), 22 deletions(-)
>
Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/5] xsk: fix bug when trying to use both copy and zero-copy mode
From: Magnus Karlsson @ 2018-10-02 12:49 UTC (permalink / raw)
To: jakub.kicinski
Cc: Karlsson, Magnus, Björn Töpel, ast, Daniel Borkmann,
Network Development, Jesper Dangaard Brouer
In-Reply-To: <20181001133146.1b8f3810@cakuba.netronome.com>
On Mon, Oct 1, 2018 at 10:34 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 1 Oct 2018 14:51:32 +0200, Magnus Karlsson wrote:
> > Jakub, please take a look at your patches. The last one I had to
> > change slightly to make it fit with the new interface
> > xdp_get_umem_from_qid(). An added bonus with this function is that we,
> > in the future, can also use it from the driver to get a umem, thus
> > simplifying driver implementations (and later remove the umem from the
> > NDO completely). Björn will mail patches, at a later point in time,
> > using this in the i40e and ixgbe drivers, that removes a good chunk of
> > code from the ZC implementations.
>
> Nice, drivers which don't follow the prepare/commit model of handling
> reconfigurations will benefit!
>
> > I also made your code aware of Tx queues. If we create a socket that
> > only has a Tx queue, then the queue id will refer to a Tx queue id
> > only and could be larger than the available amount of Rx queues.
> > Please take a look at it.
>
> The semantics of Tx queue id are slightly unclear. To me XDP is
> associated with Rx, so the qid in driver context can only refer to
> Rx queue and its associated XDP Tx queue. It does not mean the Tx
> queue stack uses, like it does for copy fallback. If one doesn't have
> a Rx queue $id, there will be no associated XDP Tx queue $id (in all
> drivers but Intel, and virtio, which use per-CPU Tx queues making TX
> queue even more meaningless).
>
> Its to be seen how others implement AF_XDP. My general feeling is
> that we should only talk about Rx queues in context of driver XDP.
This is the way I see it. From an uapi point of view we can create a
socket that can only do Rx, only Tx or both. We then bind this socket
to a specific queue id on a device. If a packet is received on this
queue id it is sent (by the default xdpsock sample program) to the
socket. If a packet is sent on this socket it goes out on this same
queue id. If you have not registered an Rx ring (in user space) for
this socket, you cannot receive anything on this socket. And
conversely, if you have no Tx ring, you will not be able to send
anything.
But if we take a look at this from the driver perspective and the NDO
XDP_SETUP_XSK_UMEM, today it does not know anything about if Rx and Tx
rings have been setup in the socket. It will always initialize the HW
Rx and Tx queues of the supplied queue id. So with today's NDO
interface you will always get a Rx/Tx queue pair. In order to realize
the uapi above in an efficient manner and to support devices with more
Tx queues than Rx, we need to change the NDO.
Just as a note, in the applications I am used to work on, radio base
stations and other telecom apps, it is the common case to have many
more Tx queues than Rx queues just to be able to use scheduling,
shaping and other QoS features that are important on egress in those
systems. Therefore the interest in supporting Tx only queues. But
maybe this is just a weird case, do not know.
^ permalink raw reply
* [PATCH 0/1] net: fec: fix rare tx timeout
From: rickard.andersson @ 2018-10-02 12:49 UTC (permalink / raw)
To: fugang.duan, netdev; +Cc: Rickard x Andersson
From: Rickard x Andersson <rickaran@axis.com>
This patch is not fully verified yet but I would much
appreciate feedback.
Rickard x Andersson (1):
net: fec: fix rare tx timeout
drivers/net/ethernet/freescale/fec_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/1] net: fec: fix rare tx timeout
From: rickard.andersson @ 2018-10-02 12:49 UTC (permalink / raw)
To: fugang.duan, netdev; +Cc: Rickard x Andersson
In-Reply-To: <20181002124932.14810-1-rickard.andersson@axis.com>
From: Rickard x Andersson <rickaran@axis.com>
During certain heavy network loads TX could time out
with TX ring dump.
TX is sometimes never restarted after reaching
"tx_stop_threshold" because function "fec_enet_tx_queue"
only tests the first queue.
In addition the TX timeout callback function failed to
recover because it also operated only on the first queue.
Signed-off-by: Rickard x Andersson <rickaran@axis.com>
---
drivers/net/ethernet/freescale/fec_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index eb2ea231c7..8bfa6ef826 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1155,7 +1155,7 @@ static void fec_enet_timeout_work(struct work_struct *work)
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
@@ -1270,7 +1270,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
/* Since we have freed up a buffer, the ring is no longer full
*/
- if (netif_queue_stopped(ndev)) {
+ if (netif_tx_queue_stopped(nq)) {
entries_free = fec_enet_get_free_txdesc_num(txq);
if (entries_free >= txq->tx_wake_threshold)
netif_tx_wake_queue(nq);
@@ -1747,7 +1747,7 @@ static void fec_enet_adjust_link(struct net_device *ndev)
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
@@ -2249,7 +2249,7 @@ static int fec_enet_set_pauseparam(struct net_device *ndev,
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH ethtool v2] ethtool: Fix uninitialized variable use at qsfp dump
From: Andrew Lunn @ 2018-10-02 12:50 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, John W. Linville, Chris Preimesberger, Neil Horman,
Vidya Sagar Ravipati
In-Reply-To: <1538465059-24645-1-git-send-email-eranbe@mellanox.com>
On Tue, Oct 02, 2018 at 10:24:19AM +0300, Eran Ben Elisha wrote:
> Struct sff_diags can be used uninitialized at sff8636_show_dom, this
> caused the tool to show unreported fields (supports_alarms) by the lower
> level driver.
>
> In addition, make sure the same struct is being initialized at
> sff8472_parse_eeprom function, to avoid the same issue here.
>
> Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Hi Eran
Thanks for fixing both cases.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-02 13:16 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CACT4Y+YH92M_X7h21W-unhp73tXV+itxuL0JjrfEd4B4Lohjig@mail.gmail.com>
On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
> and inet_frags_exit_net() are synchronized.
> Since you use smp_store_release()/READ_ONCE() they seem to run in
> parallel. But then isn't it possible that inet_frag_kill() reads
> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
> have the same race on concurrent removal? Or, isn't it possible that
> inet_frag_kill() reads nf->dead == 1, but does not set
> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
> INET_FRAG_HASH_DEAD flag?
>
Yes this is kind of implied in my patch.
I put the smp_store_release() and READ_ONCE exactly to document the
possible races.
This was the reason for my attempt in V1, doing a walk, but Herbert
said walk was not designed for doing deletes.
Proper synch will need a synchronize_rcu(), and thus a future
conversion in net-next because we can not really
add new synchronize_rcu() calls in an (struct
pernet_operations.)exit() without considerable performance hit of
netns dismantles.
So this will require a conversion of all inet_frags_exit_net() callers
to .exit_batch() to mitigate the cost.
I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
^ permalink raw reply
* [PATCH net-next 1/2] qed: Add driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20181002131612.10859-1-sudarsana.kalluru@cavium.com>
Add driver support for configuring/reading the 20G link speed.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 11 +++++++++++
include/linux/qed/qed_if.h | 9 +++++----
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 0fbeafe..7ceb2b9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -2679,6 +2679,9 @@ static int qed_hw_get_nvm_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
case NVM_CFG1_PORT_DRV_LINK_SPEED_10G:
link->speed.forced_speed = 10000;
break;
+ case NVM_CFG1_PORT_DRV_LINK_SPEED_20G:
+ link->speed.forced_speed = 20000;
+ break;
case NVM_CFG1_PORT_DRV_LINK_SPEED_25G:
link->speed.forced_speed = 25000;
break;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index d4d0838..56578f8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -13154,6 +13154,7 @@ struct nvm_cfg1_port {
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_OFFSET 0
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G 0x1
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G 0x2
+#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G 0x4
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G 0x8
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G 0x10
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G 0x20
@@ -13164,6 +13165,7 @@ struct nvm_cfg1_port {
#define NVM_CFG1_PORT_DRV_LINK_SPEED_AUTONEG 0x0
#define NVM_CFG1_PORT_DRV_LINK_SPEED_1G 0x1
#define NVM_CFG1_PORT_DRV_LINK_SPEED_10G 0x2
+#define NVM_CFG1_PORT_DRV_LINK_SPEED_20G 0x3
#define NVM_CFG1_PORT_DRV_LINK_SPEED_25G 0x4
#define NVM_CFG1_PORT_DRV_LINK_SPEED_40G 0x5
#define NVM_CFG1_PORT_DRV_LINK_SPEED_50G 0x6
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 2094d86..75d217a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1337,6 +1337,9 @@ static int qed_set_link(struct qed_dev *cdev, struct qed_link_params *params)
if (params->adv_speeds & QED_LM_10000baseKR_Full_BIT)
link_params->speed.advertised_speeds |=
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G;
+ if (params->adv_speeds & QED_LM_20000baseKR2_Full_BIT)
+ link_params->speed.advertised_speeds |=
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G;
if (params->adv_speeds & QED_LM_25000baseKR_Full_BIT)
link_params->speed.advertised_speeds |=
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G;
@@ -1503,6 +1506,9 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
if_link->advertised_caps |= QED_LM_10000baseKR_Full_BIT;
if (params.speed.advertised_speeds &
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
+ if_link->advertised_caps |= QED_LM_20000baseKR2_Full_BIT;
+ if (params.speed.advertised_speeds &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
if_link->advertised_caps |= QED_LM_25000baseKR_Full_BIT;
if (params.speed.advertised_speeds &
@@ -1523,6 +1529,9 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
if_link->supported_caps |= QED_LM_10000baseKR_Full_BIT;
if (link_caps.speed_capabilities &
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
+ if_link->supported_caps |= QED_LM_20000baseKR2_Full_BIT;
+ if (link_caps.speed_capabilities &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
if_link->supported_caps |= QED_LM_25000baseKR_Full_BIT;
if (link_caps.speed_capabilities &
@@ -1559,6 +1568,8 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->lp_caps |= QED_LM_1000baseT_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_10G)
if_link->lp_caps |= QED_LM_10000baseKR_Full_BIT;
+ if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_20G)
+ if_link->lp_caps |= QED_LM_20000baseKR2_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_25G)
if_link->lp_caps |= QED_LM_25000baseKR_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_40G)
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 8cd3464..dee3c9c 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -670,10 +670,11 @@ enum qed_link_mode_bits {
QED_LM_1000baseT_Half_BIT = BIT(4),
QED_LM_1000baseT_Full_BIT = BIT(5),
QED_LM_10000baseKR_Full_BIT = BIT(6),
- QED_LM_25000baseKR_Full_BIT = BIT(7),
- QED_LM_40000baseLR4_Full_BIT = BIT(8),
- QED_LM_50000baseKR2_Full_BIT = BIT(9),
- QED_LM_100000baseKR4_Full_BIT = BIT(10),
+ QED_LM_20000baseKR2_Full_BIT = BIT(7),
+ QED_LM_25000baseKR_Full_BIT = BIT(8),
+ QED_LM_40000baseLR4_Full_BIT = BIT(9),
+ QED_LM_50000baseKR2_Full_BIT = BIT(10),
+ QED_LM_100000baseKR4_Full_BIT = BIT(11),
QED_LM_COUNT = 11
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] qed*: Driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
The patch series adds driver support for configuring/reading the 20G link
speed.
Please consider applying this to "net-next".
Sudarsana Reddy Kalluru (2):
qed: Add driver support for 20G link speed.
qede: Add driver support for 20G link speed.
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 11 +++++++++++
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 9 +++++++++
include/linux/qed/qed_if.h | 9 +++++----
5 files changed, 30 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v3] PCI: Reprogram bridge prefetch registers on resume
From: Bjorn Helgaas @ 2018-10-02 20:03 UTC (permalink / raw)
To: Thomas Martitz
Cc: andy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ, Linux PM, Linux PCI,
Wysocki, Rafael J, Linux Kernel, Daniel Drake, Keith Busch,
netdev, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Bjorn Helgaas,
rchang-eYqpPyKDWXRBDgjK7y7TUQ, Linux Upstreaming Team,
David Miller, Jon Derrick, Heiner Kallweit
In-Reply-To: <7b0a5388-5b3a-a6e0-347f-94f87fc2e540-UCKwuKHb1aVAfugRpC6u6w@public.gmane.org>
Hi Thomas,
On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote:
> Am 01.10.18 um 06:57 schrieb Daniel Drake:
> > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel@rockbox.org> wrote:
> > > The latest iteration does not work on my HP system. The GPU fails to
> > > power up just like the unpatched kernel.
> >
> > That's weird, I would not expect a behaviour change in the latest
> > patch. pci_restore_config_dword() has some debug messages, could you
> > please make them visible and show logs again?
> > Also remind us of the PCI device address of the parent bridge (lspci -vt)
>
> I'll follow up with more the requested information on bugzilla
> (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069).
>
> On a quick re-check, it seems to depend on if I used the eGPU before
> the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it
> seems fine.
Does the patch ([1]) make things *worse* compared to v4.19-rc5?
If so, I'll drop the patch until we figure this out. But if the GPU
power issue also occurs in v4.19-rc5, I think we can assume it's a
different problem and we can go ahead and merge [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=083874549fdfefa629dfa752785e20427dde1511
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH net-next 2/2] qede: Add driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20181002131612.10859-1-sudarsana.kalluru@cavium.com>
Add driver support for reading/configuring the 20G link speed via ethtool.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 19652cd..7ff50b4 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -420,6 +420,7 @@ struct qede_link_mode_mapping {
{QED_LM_1000baseT_Half_BIT, ETHTOOL_LINK_MODE_1000baseT_Half_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseKR_Full_BIT, ETHTOOL_LINK_MODE_10000baseKR_Full_BIT},
+ {QED_LM_20000baseKR2_Full_BIT, ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT},
{QED_LM_25000baseKR_Full_BIT, ETHTOOL_LINK_MODE_25000baseKR_Full_BIT},
{QED_LM_40000baseLR4_Full_BIT, ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT},
{QED_LM_50000baseKR2_Full_BIT, ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT},
@@ -535,6 +536,14 @@ static int qede_set_link_ksettings(struct net_device *dev,
}
params.adv_speeds = QED_LM_10000baseKR_Full_BIT;
break;
+ case SPEED_20000:
+ if (!(current_link.supported_caps &
+ QED_LM_20000baseKR2_Full_BIT)) {
+ DP_INFO(edev, "20G speed not supported\n");
+ return -EINVAL;
+ }
+ params.adv_speeds = QED_LM_20000baseKR2_Full_BIT;
+ break;
case SPEED_25000:
if (!(current_link.supported_caps &
QED_LM_25000baseKR_Full_BIT)) {
--
1.8.3.1
^ permalink raw reply related
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