* Re: [PATCH v2 0/2] hv_netvsc: associate VF and PV device by serial number
From: Lorenzo Pieralisi @ 2018-09-20 14:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kys, haiyangz, sthemmin, devel, netdev, linux-pci
In-Reply-To: <20180914195457.20433-1-sthemmin@microsoft.com>
On Fri, Sep 14, 2018 at 12:54:55PM -0700, Stephen Hemminger wrote:
> The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> (not to be confused with PCI-E serial number). This value is sent in the protocol
> from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
>
> Using the serial number (instead of MAC address) to associate the two devices
> avoids lots of potential problems when there are duplicate MAC addresses from
> tunnels or layered devices.
>
> The patch set is broken into two parts, one is for the PCI controller
> and the other is for the netvsc device. Normally, these go through different
> trees but sending them together here for better review. The PCI changes
> were submitted previously, but the main review comment was "why do you
> need this?". This is why.
The question was more whether we should convert this serial number into
a PCI slot number (that has user space visibility and that is what you are
after) to improve the current matching, I do not question why you need
it, just for the records.
Lorenzo
> v2 - slot name can be shorter.
> remove locking when creating pci_slots; see comment for explaination
>
> Stephen Hemminger (2):
> PCI: hv: support reporting serial number as slot information
> hv_netvsc: pair VF based on serial number
>
> drivers/net/hyperv/netvsc.c | 3 ++
> drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++-------------
> drivers/pci/controller/pci-hyperv.c | 37 ++++++++++++++++++
> 3 files changed, 73 insertions(+), 25 deletions(-)
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH net] sctp: update dst pmtu with the correct daddr
From: Marcelo Ricardo Leitner @ 2018-09-20 14:17 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <dbed84b3964b13a0c15b3a5c8e825940819a2918.1537435648.git.lucien.xin@gmail.com>
On Thu, Sep 20, 2018 at 05:27:28PM +0800, Xin Long wrote:
> When processing pmtu update from an icmp packet, it calls .update_pmtu
> with sk instead of skb in sctp_transport_update_pmtu.
>
> However for sctp, the daddr in the transport might be different from
> inet_sock->inet_daddr or sk->sk_v6_daddr, which is used to update or
> create the route cache. The incorrect daddr will cause a different
> route cache created for the path.
>
> So before calling .update_pmtu, inet_sock->inet_daddr/sk->sk_v6_daddr
> should be updated with the daddr in the transport, and update it back
> after it's done.
>
> The issue has existed since route exceptions introduction.
>
> Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
> Reported-by: ian.periam@dialogic.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/transport.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/transport.c b/net/sctp/transport.c
> index 12cac85..033696e 100644
> --- a/net/sctp/transport.c
> +++ b/net/sctp/transport.c
> @@ -260,6 +260,7 @@ void sctp_transport_pmtu(struct sctp_transport *transport, struct sock *sk)
> bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
> {
> struct dst_entry *dst = sctp_transport_dst_check(t);
> + struct sock *sk = t->asoc->base.sk;
> bool change = true;
>
> if (unlikely(pmtu < SCTP_DEFAULT_MINSEGMENT)) {
> @@ -271,12 +272,19 @@ bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
> pmtu = SCTP_TRUNC4(pmtu);
>
> if (dst) {
> - dst->ops->update_pmtu(dst, t->asoc->base.sk, NULL, pmtu);
> + struct sctp_pf *pf = sctp_get_pf_specific(dst->ops->family);
> + union sctp_addr addr;
> +
> + pf->af->from_sk(&addr, sk);
> + pf->to_sk_daddr(&t->ipaddr, sk);
> + dst->ops->update_pmtu(dst, sk, NULL, pmtu);
> + pf->to_sk_daddr(&addr, sk);
> +
> dst = sctp_transport_dst_check(t);
> }
>
> if (!dst) {
> - t->af_specific->get_dst(t, &t->saddr, &t->fl, t->asoc->base.sk);
> + t->af_specific->get_dst(t, &t->saddr, &t->fl, sk);
> dst = t->dst;
> }
>
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Jakub Kicinski @ 2018-09-20 14:14 UTC (permalink / raw)
To: Eelco Chaudron
Cc: David Miller, netdev, jhs, xiyou.wangcong, jiri, simon.horman,
Marcelo Ricardo Leitner, louis.peens, Paolo, Davide Caratti
In-Reply-To: <C997079A-1449-4D38-84AC-FF6E57F66ED3@redhat.com>
On Thu, 20 Sep 2018 09:14:08 +0200, Eelco Chaudron wrote:
> Is there anything else blocking from getting this into net-next?
>
> I still think this patch is beneficial for the full user experience, and
> I’ve got requests from QA and others for this.
Not from my perspective, the numbers look okay, feel free to repost!
^ permalink raw reply
* Re: array bounds warning in xfrm_output_resume
From: Florian Westphal @ 2018-09-20 14:06 UTC (permalink / raw)
To: David Ahern; +Cc: Florian Westphal, netdev@vger.kernel.org
In-Reply-To: <8808f8a3-ea1c-f91b-8288-cc4952086f04@gmail.com>
David Ahern <dsahern@gmail.com> wrote:
> > $ make O=kbuild/perf -j 24 -s
> > In file included from /home/dsa/kernel-3.git/include/linux/kernel.h:10:0,
> > from /home/dsa/kernel-3.git/include/linux/list.h:9,
> > from /home/dsa/kernel-3.git/include/linux/module.h:9,
> > from /home/dsa/kernel-3.git/net/xfrm/xfrm_output.c:13:
> > /home/dsa/kernel-3.git/net/xfrm/xfrm_output.c: In function
> > ‘xfrm_output_resume’:
> > /home/dsa/kernel-3.git/include/linux/compiler.h:252:20: warning: array
> > subscript is above array bounds [-Warray-bounds]
> > __read_once_size(&(x), __u.__c, sizeof(x)); \
Does this thing avoid the warning?
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -143,6 +143,8 @@ int xfrm_output_resume(struct sk_buff *skb, int err)
struct net *net = xs_net(skb_dst(skb)->xfrm);
while (likely((err = xfrm_output_one(skb, err)) == 0)) {
+ unsigned short pf;
+
nf_reset(skb);
err = skb_dst(skb)->ops->local_out(net, skb->sk, skb);
@@ -152,11 +154,19 @@ int xfrm_output_resume(struct sk_buff *skb, int err)
if (!skb_dst(skb)->xfrm)
return dst_output(net, skb->sk, skb);
- err = nf_hook(skb_dst(skb)->ops->family,
- NF_INET_POST_ROUTING, net, skb->sk, skb,
- NULL, skb_dst(skb)->dev, xfrm_output2);
- if (unlikely(err != 1))
- goto out;
+ pf = skb_dst(skb)->ops->family;
+ switch (pf) {
+ case AF_INET: /* fallthrough */
+ case AF_INET6:
+ err = nf_hook(pf,
+ NF_INET_POST_ROUTING, net, skb->sk, skb,
+ NULL, skb_dst(skb)->dev, xfrm_output2);
+ if (unlikely(err != 1))
+ goto out;
+ break;
+ default:
+ break;
+ }
}
if (err == -EINPROGRESS)
^ permalink raw reply
* Re: [PATCH perf 3/3] tools/perf: recognize and process RECORD_MMAP events for bpf progs
From: Arnaldo Carvalho de Melo @ 2018-09-20 14:05 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David S . Miller, daniel, peterz, netdev, kernel-team
In-Reply-To: <20180920133617.GB19861@kernel.org>
Em Thu, Sep 20, 2018 at 10:36:17AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Sep 19, 2018 at 03:39:35PM -0700, Alexei Starovoitov escreveu:
> > Recognize JITed bpf prog load/unload events.
> > Add/remove kernel symbols accordingly.
> >
> > Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> > ---
> > tools/perf/util/machine.c | 27 +++++++++++++++++++++++++++
> > tools/perf/util/symbol.c | 13 +++++++++++++
> > tools/perf/util/symbol.h | 1 +
> > 3 files changed, 41 insertions(+)
> >
> > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> > index c4acd2001db0..ae4f8a0fdc7e 100644
> > --- a/tools/perf/util/machine.c
> > +++ b/tools/perf/util/machine.c
> > @@ -25,6 +25,7 @@
> > #include "sane_ctype.h"
> > #include <symbol/kallsyms.h>
> > #include <linux/mman.h>
> > +#include <linux/magic.h>
> >
> > static void __machine__remove_thread(struct machine *machine, struct thread *th, bool lock);
> >
> > @@ -1460,6 +1461,32 @@ static int machine__process_kernel_mmap_event(struct machine *machine,
> > enum dso_kernel_type kernel_type;
> > bool is_kernel_mmap;
> >
> > + /* process JITed bpf programs load/unload events */
> > + if (event->mmap.pid == ~0u && event->mmap.tid == BPF_FS_MAGIC) {
>
>
> So, this would be in machine__process_kernel_munmap-event(machine), etc,
> no check for BPF_FS_MAGIC would be needed with a PERF_RECORD_MUNMAP.
>
> > + struct symbol *sym;
> > + u64 ip;
> > +
> > + map = map_groups__find(&machine->kmaps, event->mmap.start);
> > + if (!map) {
> > + pr_err("No kernel map for IP %lx\n", event->mmap.start);
> > + goto out_problem;
> > + }
> > + ip = event->mmap.start - map->start + map->pgoff;
> > + if (event->mmap.filename[0]) {
> > + sym = symbol__new(ip, event->mmap.len, 0, 0,
> > + event->mmap.filename);
>
> Humm, so the bpf program would be just one symbol... bpf-to-bpf calls
> will be to a different bpf program, right?
>
> /me goes to read https://lwn.net/Articles/741773/
> "[PATCH bpf-next 00/13] bpf: introduce function calls"
After reading it, yeah, I think we need some way to access a symbol
table for a BPF program, and also its binary so that we can do
annotation, static (perf annotate) and live (perf top), was this already
considered? I think one can get the binary for a program giving
sufficient perms somehow, right? One other thing I need to catch up 8-)
- Arnaldo
> > + dso__insert_symbol(map->dso, sym);
> > + } else {
> > + if (symbols__erase(&map->dso->symbols, ip)) {
> > + pr_err("No bpf prog at IP %lx/%lx\n",
> > + event->mmap.start, ip);
> > + goto out_problem;
> > + }
> > + dso__reset_find_symbol_cache(map->dso);
> > + }
> > + return 0;
> > + }
> > +
> > /* If we have maps from kcore then we do not need or want any others */
> > if (machine__uses_kcore(machine))
> > return 0;
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index d188b7588152..0653f313661d 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -353,6 +353,19 @@ static struct symbol *symbols__find(struct rb_root *symbols, u64 ip)
> > return NULL;
> > }
> >
> > +int symbols__erase(struct rb_root *symbols, u64 ip)
> > +{
> > + struct symbol *s;
> > +
> > + s = symbols__find(symbols, ip);
> > + if (!s)
> > + return -ENOENT;
> > +
> > + rb_erase(&s->rb_node, symbols);
> > + symbol__delete(s);
> > + return 0;
> > +}
> > +
> > static struct symbol *symbols__first(struct rb_root *symbols)
> > {
> > struct rb_node *n = rb_first(symbols);
> > diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> > index f25fae4b5743..92ef31953d9a 100644
> > --- a/tools/perf/util/symbol.h
> > +++ b/tools/perf/util/symbol.h
> > @@ -310,6 +310,7 @@ char *dso__demangle_sym(struct dso *dso, int kmodule, const char *elf_name);
> >
> > void __symbols__insert(struct rb_root *symbols, struct symbol *sym, bool kernel);
> > void symbols__insert(struct rb_root *symbols, struct symbol *sym);
> > +int symbols__erase(struct rb_root *symbols, u64 ip);
> > void symbols__fixup_duplicate(struct rb_root *symbols);
> > void symbols__fixup_end(struct rb_root *symbols);
> > void map_groups__fixup_end(struct map_groups *mg);
> > --
> > 2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Peter Zijlstra @ 2018-09-20 13:56 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov, David S . Miller, daniel, netdev, kernel-team
In-Reply-To: <20180920132545.GA19861@kernel.org>
On Thu, Sep 20, 2018 at 10:25:45AM -0300, Arnaldo Carvalho de Melo wrote:
> PeterZ provided a patch introducing PERF_RECORD_MUNMAP, went nowhere due
> to having to cope with munmapping parts of existing mmaps, etc.
>
> I'm still more in favour of introduce PERF_RECORD_MUNMAP, even if for
> now it would be used just in this clean case for undoing a
> PERF_RECORD_MMAP for a BPF program.
>
> The ABI is already complicated, starting to use something called
> PERF_RECORD_MMAP for unmmaping by just using a NULL name... too clever,
> I think.
Agreed, the PERF_RECORD_MUNMAP patch was fairly trivial, the difficult
part was getting the perf tool to dtrt for that use-case. But if we need
unmap events, doing the unmap record now is the right thing.
^ permalink raw reply
* Re: [PATCH][next-next][v2] netlink: avoid to allocate full skb when sending to many devices
From: Eric Dumazet @ 2018-09-20 13:51 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <a9b4a4b9-04c4-bf55-3f08-b7889524374a@gmail.com>
On 09/20/2018 06:43 AM, Eric Dumazet wrote:
>
> And lastly this patch looks way too complicated to me.
> You probably can write something much simpler.
Something like :
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 930d17fa906c9ebf1cf7b6031ce0a22f9f66c0e4..e0a81beb4f37751421dbbe794ccf3d5a46bdf900 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -278,22 +278,26 @@ static bool netlink_filter_tap(const struct sk_buff *skb)
return false;
}
-static int __netlink_deliver_tap_skb(struct sk_buff *skb,
+static int __netlink_deliver_tap_skb(struct sk_buff **pskb,
struct net_device *dev)
{
- struct sk_buff *nskb;
+ struct sk_buff *nskb, *skb = *pskb;
struct sock *sk = skb->sk;
int ret = -ENOMEM;
if (!net_eq(dev_net(dev), sock_net(sk)))
return 0;
- dev_hold(dev);
-
- if (is_vmalloc_addr(skb->head))
+ if (is_vmalloc_addr(skb->head)) {
nskb = netlink_to_full_skb(skb, GFP_ATOMIC);
- else
- nskb = skb_clone(skb, GFP_ATOMIC);
+ if (!nskb)
+ return -ENOMEM;
+ consume_skb(skb);
+ skb = nskb;
+ *pskb = skb;
+ }
+ dev_hold(dev);
+ nskb = skb_clone(skb, GFP_ATOMIC);
if (nskb) {
nskb->dev = dev;
nskb->protocol = htons((u16) sk->sk_protocol);
@@ -318,7 +322,7 @@ static void __netlink_deliver_tap(struct sk_buff *skb, struct netlink_tap_net *n
return;
list_for_each_entry_rcu(tmp, &nn->netlink_tap_all, list) {
- ret = __netlink_deliver_tap_skb(skb, tmp->dev);
+ ret = __netlink_deliver_tap_skb(&skb, tmp->dev);
if (unlikely(ret))
break;
}
^ permalink raw reply related
* [PATCH] DRIVERS: net: macsec: Fix multiple coding style issues
From: Romain Aviolat @ 2018-09-20 19:33 UTC (permalink / raw)
To: davem
Cc: elena.reshetova, ishkamiel, sd, dan.carpenter, felix.walter,
r.aviolat, netdev, linux-kernel
This patch fixes a couple of issues highlighted by checkpatch.pl:
* Missing a blank line after declarations
* Alignment should match open parenthesis
Signed-off-by: Romain Aviolat <r.aviolat@gmail.com>
---
drivers/net/macsec.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 7de88b33d5b9..4bb90b6867a2 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -64,9 +64,9 @@ struct macsec_eth_header {
#define MACSEC_NUM_AN 4 /* 2 bits for the association number */
-#define for_each_rxsc(secy, sc) \
+#define for_each_rxsc(secy, sc) \
for (sc = rcu_dereference_bh(secy->rx_sc); \
- sc; \
+ sc; \
sc = rcu_dereference_bh(sc->next))
#define for_each_rxsc_rtnl(secy, sc) \
for (sc = rtnl_dereference(secy->rx_sc); \
@@ -1142,6 +1142,7 @@ static rx_handler_result_t macsec_handle_frame(struct sk_buff **pskb)
list_for_each_entry_rcu(macsec, &rxd->secys, secys) {
struct macsec_rx_sc *sc = find_rx_sc(&macsec->secy, sci);
+
sc = sc ? macsec_rxsc_get(sc) : NULL;
if (sc) {
@@ -1584,7 +1585,6 @@ static struct macsec_rx_sa *get_rxsa_from_nl(struct net *net,
return rx_sa;
}
-
static const struct nla_policy macsec_genl_policy[NUM_MACSEC_ATTR] = {
[MACSEC_ATTR_IFINDEX] = { .type = NLA_U32 },
[MACSEC_ATTR_RXSC_CONFIG] = { .type = NLA_NESTED },
@@ -2156,7 +2156,7 @@ static int macsec_upd_rxsc(struct sk_buff *skb, struct genl_info *info)
}
static int copy_tx_sa_stats(struct sk_buff *skb,
- struct macsec_tx_sa_stats __percpu *pstats)
+ struct macsec_tx_sa_stats __percpu *pstats)
{
struct macsec_tx_sa_stats sum = {0, };
int cpu;
@@ -2176,7 +2176,7 @@ static int copy_tx_sa_stats(struct sk_buff *skb,
}
static int copy_rx_sa_stats(struct sk_buff *skb,
- struct macsec_rx_sa_stats __percpu *pstats)
+ struct macsec_rx_sa_stats __percpu *pstats)
{
struct macsec_rx_sa_stats sum = {0, };
int cpu;
@@ -2202,7 +2202,7 @@ static int copy_rx_sa_stats(struct sk_buff *skb,
}
static int copy_rx_sc_stats(struct sk_buff *skb,
- struct pcpu_rx_sc_stats __percpu *pstats)
+ struct pcpu_rx_sc_stats __percpu *pstats)
{
struct macsec_rx_sc_stats sum = {0, };
int cpu;
@@ -2266,7 +2266,7 @@ static int copy_rx_sc_stats(struct sk_buff *skb,
}
static int copy_tx_sc_stats(struct sk_buff *skb,
- struct pcpu_tx_sc_stats __percpu *pstats)
+ struct pcpu_tx_sc_stats __percpu *pstats)
{
struct macsec_tx_sc_stats sum = {0, };
int cpu;
@@ -2306,7 +2306,7 @@ static int copy_tx_sc_stats(struct sk_buff *skb,
}
static int copy_secy_stats(struct sk_buff *skb,
- struct pcpu_secy_stats __percpu *pstats)
+ struct pcpu_secy_stats __percpu *pstats)
{
struct macsec_dev_stats sum = {0, };
int cpu;
@@ -2962,13 +2962,11 @@ static int macsec_get_iflink(const struct net_device *dev)
return macsec_priv(dev)->real_dev->ifindex;
}
-
static int macsec_get_nest_level(struct net_device *dev)
{
return macsec_priv(dev)->nest_level;
}
-
static const struct net_device_ops macsec_netdev_ops = {
.ndo_init = macsec_dev_init,
.ndo_uninit = macsec_dev_uninit,
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH ethtool] ethtool: better syntax for combinations of FEC modes
From: Michal Kubecek @ 2018-09-20 13:46 UTC (permalink / raw)
To: Edward Cree; +Cc: John W. Linville, netdev
In-Reply-To: <a5312743-9d54-b239-80ee-cc7aff77b6aa@solarflare.com>
On Wed, Sep 19, 2018 at 05:06:25PM +0100, Edward Cree wrote:
> Instead of commas, just have them as separate argvs.
>
> The parsing state machine might look heavyweight, but it makes it easy to add
> more parameters later and distinguish parameter names from encoding names.
>
> Suggested-by: Michal Kubecek <mkubecek@suse.cz>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
Looks good, thank you.
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
> ethtool.8.in | 6 +++---
> ethtool.c | 63 ++++++++++++++++------------------------------------------
> test-cmdline.c | 10 +++++-----
> 3 files changed, 25 insertions(+), 54 deletions(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 414eaa1..7ea2cc0 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -390,7 +390,7 @@ ethtool \- query or control network driver and hardware settings
> .B ethtool \-\-set\-fec
> .I devname
> .B encoding
> -.BR auto | off | rs | baser [ , ...]
> +.BR auto | off | rs | baser \ [...]
> .
> .\" Adjust lines (i.e. full justification) and hyphenate.
> .ad
> @@ -1120,11 +1120,11 @@ current FEC mode, the driver or firmware must take the link down
> administratively and report the problem in the system logs for users to correct.
> .RS 4
> .TP
> -.BR encoding\ auto | off | rs | baser [ , ...]
> +.BR encoding\ auto | off | rs | baser \ [...]
>
> Sets the FEC encoding for the device. Combinations of options are specified as
> e.g.
> -.B auto,rs
> +.B encoding auto rs
> ; the semantics of such combinations vary between drivers.
> .TS
> nokeep;
> diff --git a/ethtool.c b/ethtool.c
> index 9997930..2f7e96b 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4979,39 +4979,6 @@ static int fecmode_str_to_type(const char *str)
> return 0;
> }
>
> -/* Takes a comma-separated list of FEC modes, returns the bitwise OR of their
> - * corresponding ETHTOOL_FEC_* constants.
> - * Accepts repetitions (e.g. 'auto,auto') and trailing comma (e.g. 'off,').
> - */
> -static int parse_fecmode(const char *str)
> -{
> - int fecmode = 0;
> - char buf[6];
> -
> - if (!str)
> - return 0;
> - while (*str) {
> - size_t next;
> - int mode;
> -
> - next = strcspn(str, ",");
> - if (next >= 6) /* Bad mode, longest name is 5 chars */
> - return 0;
> - /* Copy into temp buffer and nul-terminate */
> - memcpy(buf, str, next);
> - buf[next] = 0;
> - mode = fecmode_str_to_type(buf);
> - if (!mode) /* Bad mode encountered */
> - return 0;
> - fecmode |= mode;
> - str += next;
> - /* Skip over ',' (but not nul) */
> - if (*str)
> - str++;
> - }
> - return fecmode;
> -}
> -
> static int do_gfec(struct cmd_context *ctx)
> {
> struct ethtool_fecparam feccmd = { 0 };
> @@ -5041,22 +5008,26 @@ static int do_gfec(struct cmd_context *ctx)
>
> static int do_sfec(struct cmd_context *ctx)
> {
> - char *fecmode_str = NULL;
> + enum { ARG_NONE, ARG_ENCODING } state = ARG_NONE;
> struct ethtool_fecparam feccmd;
> - struct cmdline_info cmdline_fec[] = {
> - { "encoding", CMDL_STR, &fecmode_str, &feccmd.fec},
> - };
> - int changed;
> - int fecmode;
> - int rv;
> + int fecmode = 0, newmode;
> + int rv, i;
>
> - parse_generic_cmdline(ctx, &changed, cmdline_fec,
> - ARRAY_SIZE(cmdline_fec));
> -
> - if (!fecmode_str)
> + for (i = 0; i < ctx->argc; i++) {
> + if (!strcmp(ctx->argp[i], "encoding")) {
> + state = ARG_ENCODING;
> + continue;
> + }
> + if (state == ARG_ENCODING) {
> + newmode = fecmode_str_to_type(ctx->argp[i]);
> + if (!newmode)
> + exit_bad_args();
> + fecmode |= newmode;
> + continue;
> + }
> exit_bad_args();
> + }
>
> - fecmode = parse_fecmode(fecmode_str);
> if (!fecmode)
> exit_bad_args();
>
> @@ -5265,7 +5236,7 @@ static const struct option {
> " [ all ]\n"},
> { "--show-fec", 1, do_gfec, "Show FEC settings"},
> { "--set-fec", 1, do_sfec, "Set FEC settings",
> - " [ encoding auto|off|rs|baser ]\n"},
> + " [ encoding auto|off|rs|baser [...]]\n"},
> { "-h|--help", 0, show_usage, "Show this help" },
> { "--version", 0, do_version, "Show version number" },
> {}
> diff --git a/test-cmdline.c b/test-cmdline.c
> index 9c51cca..84630a5 100644
> --- a/test-cmdline.c
> +++ b/test-cmdline.c
> @@ -268,12 +268,12 @@ static struct test_case {
> { 1, "--set-eee devname advertise foo" },
> { 1, "--set-fec devname" },
> { 0, "--set-fec devname encoding auto" },
> - { 0, "--set-fec devname encoding off," },
> - { 0, "--set-fec devname encoding baser,rs" },
> - { 0, "--set-fec devname encoding auto,auto," },
> + { 0, "--set-fec devname encoding off" },
> + { 0, "--set-fec devname encoding baser rs" },
> + { 0, "--set-fec devname encoding auto auto" },
> { 1, "--set-fec devname encoding foo" },
> - { 1, "--set-fec devname encoding auto,foo" },
> - { 1, "--set-fec devname encoding auto,," },
> + { 1, "--set-fec devname encoding auto foo" },
> + { 1, "--set-fec devname encoding none" },
> { 1, "--set-fec devname auto" },
> /* can't test --set-priv-flags yet */
> { 0, "-h" },
^ permalink raw reply
* Re: [PATCH][next-next][v2] netlink: avoid to allocate full skb when sending to many devices
From: Eric Dumazet @ 2018-09-20 13:43 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <1537433690-24335-1-git-send-email-lirongqing@baidu.com>
On 09/20/2018 01:54 AM, Li RongQing wrote:
> if skb->head is vmalloc address, when this skb is delivered, full
> allocation for this skb is required, if there are many devices,
> the full allocation will be called for every devices
>
> now if it is vmalloc, allocate a new skb, whose data is not vmalloc
> address, and use new allocated skb to clone and send, to avoid to
> allocate full skb everytime.
>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
This looks a broken Signed-off-by chain to me.
Who really wrote this patch ?
Also, given that I gave feedback to your first version,
it is customary to CC me for future versions, unless you want me to not notice them.
And lastly this patch looks way too complicated to me.
You probably can write something much simpler.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/2] hv_netvsc: pair VF based on serial number
From: Lorenzo Pieralisi @ 2018-09-20 13:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kys, haiyangz, sthemmin, devel, netdev, linux-pci
In-Reply-To: <20180914195457.20433-3-sthemmin@microsoft.com>
On Fri, Sep 14, 2018 at 12:54:57PM -0700, Stephen Hemminger wrote:
> Matching network device based on MAC address is problematic
> since a non VF network device can be creted with a duplicate MAC
> address causing confusion and problems. The VMBus API does provide
> a serial number that is a better matching method.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/hyperv/netvsc.c | 3 ++
> drivers/net/hyperv/netvsc_drv.c | 58 +++++++++++++++++++--------------
> 2 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 31c3d77b4733..fe01e141c8f8 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_device *ndev,
>
> net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated;
> net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial;
> + netdev_info(ndev, "VF slot %u %s\n",
> + net_device_ctx->vf_serial,
> + net_device_ctx->vf_alloc ? "added" : "removed");
> }
>
> static void netvsc_receive_inband(struct net_device *ndev,
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 1121a1ec407c..9dedc1463e88 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -1894,20 +1894,6 @@ static void netvsc_link_change(struct work_struct *w)
> rtnl_unlock();
> }
>
> -static struct net_device *get_netvsc_bymac(const u8 *mac)
> -{
> - struct net_device_context *ndev_ctx;
> -
> - list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) {
> - struct net_device *dev = hv_get_drvdata(ndev_ctx->device_ctx);
> -
> - if (ether_addr_equal(mac, dev->perm_addr))
> - return dev;
> - }
> -
> - return NULL;
> -}
> -
> static struct net_device *get_netvsc_byref(struct net_device *vf_netdev)
> {
> struct net_device_context *net_device_ctx;
> @@ -2036,26 +2022,48 @@ static void netvsc_vf_setup(struct work_struct *w)
> rtnl_unlock();
> }
>
> +/* Find netvsc by VMBus serial number.
> + * The PCI hyperv controller records the serial number as the slot.
> + */
> +static struct net_device *get_netvsc_byslot(const struct net_device *vf_netdev)
> +{
> + struct device *parent = vf_netdev->dev.parent;
> + struct net_device_context *ndev_ctx;
> + struct pci_dev *pdev;
> +
> + if (!parent || !dev_is_pci(parent))
> + return NULL; /* not a PCI device */
> +
> + pdev = to_pci_dev(parent);
> + if (!pdev->slot) {
> + netdev_notice(vf_netdev, "no PCI slot information\n");
> + return NULL;
> + }
> +
> + list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) {
> + if (!ndev_ctx->vf_alloc)
> + continue;
> +
> + if (ndev_ctx->vf_serial == pdev->slot->number)
> + return hv_get_drvdata(ndev_ctx->device_ctx);
In patch 1, pdev->slot->number is set to:
PCI_SLOT(wslot_to_devfn(hpdev->desc.win_slot.slot))
so I assume vf_serial is initialized (I have no knowledge of VMBUS and
hyper-V internals) to that value, somehow.
I also do not know how the wslot stuff is handled but I assume 5 bits
(ie dev bits in devfn) are enough.
BTW, I have noticed this patch (and patch 1) are already in -next so I will
drop them from the PCI patch queue.
Lorenzo
> + }
> +
> + netdev_notice(vf_netdev,
> + "no netdev found for slot %u\n", pdev->slot->number);
> + return NULL;
> +}
> +
> static int netvsc_register_vf(struct net_device *vf_netdev)
> {
> - struct net_device *ndev;
> struct net_device_context *net_device_ctx;
> - struct device *pdev = vf_netdev->dev.parent;
> struct netvsc_device *netvsc_dev;
> + struct net_device *ndev;
> int ret;
>
> if (vf_netdev->addr_len != ETH_ALEN)
> return NOTIFY_DONE;
>
> - if (!pdev || !dev_is_pci(pdev) || dev_is_pf(pdev))
> - return NOTIFY_DONE;
> -
> - /*
> - * We will use the MAC address to locate the synthetic interface to
> - * associate with the VF interface. If we don't find a matching
> - * synthetic interface, move on.
> - */
> - ndev = get_netvsc_bymac(vf_netdev->perm_addr);
> + ndev = get_netvsc_byslot(vf_netdev);
> if (!ndev)
> return NOTIFY_DONE;
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: net: qcom: Add binding for shared mdio bus
From: Timur Tabi @ 2018-09-20 13:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: Wang, Dongsheng, Florian Fainelli, davem@davemloft.net,
Zheng, Joey, netdev@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20180919152052.GD17466@lunn.ch>
On 9/19/18 10:20 AM, Andrew Lunn wrote:
> I suspect that is not going to be easy. Last time i looked, the ACPI
> standard had nothing about MDIO busses or PHYs. Marcin Wojtas did some
> work in this area a while back for the mvpp2, but if i remember
> correctly, he worked around this by simply not having a PHY when using
> ACPI, and making use of a MAC interrupt which indicated when there was
> link.
>
> Whoever implements this first needs to be an ACPI expert and probably
> needs to write it up and submit it as an amendment to the ACPI
> standard.
If that's what it takes, then so be it. But adding DT support for a
device that is only used on ACPI platforms is not a worthwhile endeavor.
After ACPI support is merged, Dongsheng can choose to add DT support to
maintain parity, if he wants. Maybe one day the MSM developers will use
the upstream driver on one of their SOCs.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Peter Zijlstra @ 2018-09-20 13:36 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David S . Miller, daniel, acme, netdev, kernel-team
In-Reply-To: <20180920084424.GN24124@hirez.programming.kicks-ass.net>
On Thu, Sep 20, 2018 at 10:44:24AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 19, 2018 at 03:39:34PM -0700, Alexei Starovoitov wrote:
> > void bpf_prog_kallsyms_del(struct bpf_prog *fp)
> > {
> > + unsigned long symbol_start, symbol_end;
> > + /* mmap_record.filename cannot be NULL and has to be u64 aligned */
> > + char buf[sizeof(u64)] = {};
> > +
> > if (!bpf_prog_kallsyms_candidate(fp))
> > return;
> >
> > spin_lock_bh(&bpf_lock);
> > bpf_prog_ksym_node_del(fp->aux);
> > spin_unlock_bh(&bpf_lock);
> > + bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
> > + perf_event_mmap_bpf_prog(symbol_start, symbol_end - symbol_start,
> > + buf, sizeof(buf));
> > }
>
> So perf doesn't normally issue unmap events.. We've talked about doing
> that, but so far it's never really need needed I think.
>
> I feels a bit weird to start issuing unmap events for this.
FWIW:
https://lkml.kernel.org/r/20170127130702.GI6515@twins.programming.kicks-ass.net
has talk of PERF_RECORD_MUNMAP
^ permalink raw reply
* Re: [PATCH perf 3/3] tools/perf: recognize and process RECORD_MMAP events for bpf progs
From: Arnaldo Carvalho de Melo @ 2018-09-20 13:36 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David S . Miller, daniel, peterz, netdev, kernel-team
In-Reply-To: <20180919223935.999270-4-ast@kernel.org>
Em Wed, Sep 19, 2018 at 03:39:35PM -0700, Alexei Starovoitov escreveu:
> Recognize JITed bpf prog load/unload events.
> Add/remove kernel symbols accordingly.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> tools/perf/util/machine.c | 27 +++++++++++++++++++++++++++
> tools/perf/util/symbol.c | 13 +++++++++++++
> tools/perf/util/symbol.h | 1 +
> 3 files changed, 41 insertions(+)
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index c4acd2001db0..ae4f8a0fdc7e 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -25,6 +25,7 @@
> #include "sane_ctype.h"
> #include <symbol/kallsyms.h>
> #include <linux/mman.h>
> +#include <linux/magic.h>
>
> static void __machine__remove_thread(struct machine *machine, struct thread *th, bool lock);
>
> @@ -1460,6 +1461,32 @@ static int machine__process_kernel_mmap_event(struct machine *machine,
> enum dso_kernel_type kernel_type;
> bool is_kernel_mmap;
>
> + /* process JITed bpf programs load/unload events */
> + if (event->mmap.pid == ~0u && event->mmap.tid == BPF_FS_MAGIC) {
So, this would be in machine__process_kernel_munmap-event(machine), etc,
no check for BPF_FS_MAGIC would be needed with a PERF_RECORD_MUNMAP.
> + struct symbol *sym;
> + u64 ip;
> +
> + map = map_groups__find(&machine->kmaps, event->mmap.start);
> + if (!map) {
> + pr_err("No kernel map for IP %lx\n", event->mmap.start);
> + goto out_problem;
> + }
> + ip = event->mmap.start - map->start + map->pgoff;
> + if (event->mmap.filename[0]) {
> + sym = symbol__new(ip, event->mmap.len, 0, 0,
> + event->mmap.filename);
Humm, so the bpf program would be just one symbol... bpf-to-bpf calls
will be to a different bpf program, right?
/me goes to read https://lwn.net/Articles/741773/
"[PATCH bpf-next 00/13] bpf: introduce function calls"
> + dso__insert_symbol(map->dso, sym);
> + } else {
> + if (symbols__erase(&map->dso->symbols, ip)) {
> + pr_err("No bpf prog at IP %lx/%lx\n",
> + event->mmap.start, ip);
> + goto out_problem;
> + }
> + dso__reset_find_symbol_cache(map->dso);
> + }
> + return 0;
> + }
> +
> /* If we have maps from kcore then we do not need or want any others */
> if (machine__uses_kcore(machine))
> return 0;
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index d188b7588152..0653f313661d 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -353,6 +353,19 @@ static struct symbol *symbols__find(struct rb_root *symbols, u64 ip)
> return NULL;
> }
>
> +int symbols__erase(struct rb_root *symbols, u64 ip)
> +{
> + struct symbol *s;
> +
> + s = symbols__find(symbols, ip);
> + if (!s)
> + return -ENOENT;
> +
> + rb_erase(&s->rb_node, symbols);
> + symbol__delete(s);
> + return 0;
> +}
> +
> static struct symbol *symbols__first(struct rb_root *symbols)
> {
> struct rb_node *n = rb_first(symbols);
> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> index f25fae4b5743..92ef31953d9a 100644
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -310,6 +310,7 @@ char *dso__demangle_sym(struct dso *dso, int kmodule, const char *elf_name);
>
> void __symbols__insert(struct rb_root *symbols, struct symbol *sym, bool kernel);
> void symbols__insert(struct rb_root *symbols, struct symbol *sym);
> +int symbols__erase(struct rb_root *symbols, u64 ip);
> void symbols__fixup_duplicate(struct rb_root *symbols);
> void symbols__fixup_end(struct rb_root *symbols);
> void map_groups__fixup_end(struct map_groups *mg);
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net] af_key: free SKBs under RCU protection
From: Eric Dumazet @ 2018-09-20 13:29 UTC (permalink / raw)
To: Sean Tranchetti, netdev, steffen.klassert
In-Reply-To: <1537402712-12875-1-git-send-email-stranche@codeaurora.org>
On 09/19/2018 05:18 PM, Sean Tranchetti wrote:
> pfkey_broadcast() can make calls to pfkey_broadcast_one() which
> will clone or copy the passed in SKB. This new SKB will be assigned
> the sock_rfree() function as its destructor, which requires that
> the socket reference the SKB contains is valid when the SKB is freed.
>
> If this SKB is ever passed to pfkey_broadcast() again by some other
> function (such as pkfey_dump() or pfkey_promisc) it will then be
> freed there. However, since this free occurs outside of RCU protection,
> it is possible that userspace could close the socket and trigger
> pfkey_release() to free the socket before sock_rfree() can run, creating
> the following race condition:
>
> 1: An SKB belonging to the pfkey socket is passed to pfkey_broadcast().
> It performs the broadcast to any other sockets, and calls
> rcu_read_unlock(), but does not yet reach kfree_skb().
> 2: Userspace closes the socket, triggering pfkey_realse(). Since no one
> holds the RCU lock, synchronize_rcu() returns and it is allowed to
> continue. It calls sock_put() to free the socket.
> 3: pfkey_broadcast() now calls kfree_skb() on the original SKB it was
> passed, triggering a call to sock_rfree(). This function now accesses
> the freed struct sock * via skb->sk, and attempts to update invalid
> memory.
>
> By ensuring that the pfkey_broadcast() also frees the SKBs while it holds
> the RCU lock, we can ensure that the socket will remain valid when the SKB
> is freed, avoiding crashes like the following:
>
> Unable to handle kernel paging request at virtual address 6b6b6b6b6b6c4b
> [006b6b6b6b6b6c4b] address between user and kernel address ranges
> Internal error: Oops: 96000004 [#1] PREEMPT SMP
> task: fffffff78f65b380 task.stack: ffffff8049a88000
> pc : sock_rfree+0x38/0x6c
> lr : skb_release_head_state+0x6c/0xcc
> Process repro (pid: 7117, stack limit = 0xffffff8049a88000)
> Call trace:
> sock_rfree+0x38/0x6c
> skb_release_head_state+0x6c/0xcc
> skb_release_all+0x1c/0x38
> __kfree_skb+0x1c/0x30
> kfree_skb+0xd0/0xf4
> pfkey_broadcast+0x14c/0x18c
> pfkey_sendmsg+0x1d8/0x408
> sock_sendmsg+0x44/0x60
> ___sys_sendmsg+0x1d0/0x2a8
> __sys_sendmsg+0x64/0xb4
> SyS_sendmsg+0x34/0x4c
> el0_svc_naked+0x34/0x38
> Kernel panic - not syncing: Fatal exception
>
> Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
> ---
> net/key/af_key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index 9d61266..dd257c7 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -275,13 +275,13 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t allocation,
> if ((broadcast_flags & BROADCAST_REGISTERED) && err)
> err = err2;
> }
> - rcu_read_unlock();
>
> if (one_sk != NULL)
> err = pfkey_broadcast_one(skb, &skb2, allocation, one_sk);
>
> kfree_skb(skb2);
> kfree_skb(skb);
> + rcu_read_unlock();
> return err;
> }
>
>
I do not believe the changelog or the patch makes sense.
Having skb still referencing a socket prevents this socket being released.
If you think about it, what would prevent the freeing happening
_before_ the rcu_read_lock() in pfkey_broadcast() ?
Maybe the correct fix is that pfkey_broadcast_one() should ensure the socket is still valid.
I would suggest something like :
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 9d61266526e767770d9a1ce184ac8cdd59de309a..5ce309d020dda5e46e4426c4a639bfb551e2260d 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -201,7 +201,9 @@ static int pfkey_broadcast_one(struct sk_buff *skb, struct sk_buff **skb2,
{
int err = -ENOBUFS;
- sock_hold(sk);
+ if (!refcount_inc_not_zero(&sk->sk_refcnt))
+ return -ENOENT;
+
if (*skb2 == NULL) {
if (refcount_read(&skb->users) != 1) {
*skb2 = skb_clone(skb, allocation);
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Arnaldo Carvalho de Melo @ 2018-09-20 13:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Peter Zijlstra, David S . Miller, daniel, netdev, kernel-team
In-Reply-To: <20180920084424.GN24124@hirez.programming.kicks-ass.net>
Em Thu, Sep 20, 2018 at 10:44:24AM +0200, Peter Zijlstra escreveu:
> On Wed, Sep 19, 2018 at 03:39:34PM -0700, Alexei Starovoitov wrote:
> > void bpf_prog_kallsyms_del(struct bpf_prog *fp)
> > {
> > + unsigned long symbol_start, symbol_end;
> > + /* mmap_record.filename cannot be NULL and has to be u64 aligned */
> > + char buf[sizeof(u64)] = {};
> > +
> > if (!bpf_prog_kallsyms_candidate(fp))
> > return;
> >
> > spin_lock_bh(&bpf_lock);
> > bpf_prog_ksym_node_del(fp->aux);
> > spin_unlock_bh(&bpf_lock);
> > + bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
> > + perf_event_mmap_bpf_prog(symbol_start, symbol_end - symbol_start,
> > + buf, sizeof(buf));
> > }
>
> So perf doesn't normally issue unmap events.. We've talked about doing
> that, but so far it's never really need needed I think.
> I feels a bit weird to start issuing unmap events for this.
For reference, this surfaced here:
https://lkml.org/lkml/2017/1/27/452
Start of the thread, that involves postgresql, JIT, LLVM, perf is here:
https://lkml.org/lkml/2016/12/10/1
PeterZ provided a patch introducing PERF_RECORD_MUNMAP, went nowhere due
to having to cope with munmapping parts of existing mmaps, etc.
I'm still more in favour of introduce PERF_RECORD_MUNMAP, even if for
now it would be used just in this clean case for undoing a
PERF_RECORD_MMAP for a BPF program.
The ABI is already complicated, starting to use something called
PERF_RECORD_MMAP for unmmaping by just using a NULL name... too clever,
I think.
- Arnaldo
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Andrew Lunn @ 2018-09-20 13:25 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <20180918105817.z2o5yybcth7diqsu@verge.net.au>
> 1. net-next: cf7d97e1e54d ("net: mdio: remove duplicated include from mdio_bus.c")
>
> # mii-tool -vv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: no link
> registers for MII PHY 0:
> 1140 7949 0022 1622 0d81 c1e1 000f 0000
> 0000 0300 0000 0000 0000 0000 0000 3000
> 0000 0000 0000 0078 7002 0000 0000 0200
> 0000 0000 0000 0528 0000 0000 0000 0000
> product info: vendor 00:08:85, model 34 rev 2
> basic mode: autonegotiation enabled
> basic status: no link
> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD flow-control
> link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> 2. net-next with this patch reverted
>
> # mii-tool -vv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD, link ok
> registers for MII PHY 0:
> 1140 796d 0022 1622 0181 c1e1 000f 0000
Hi Simon
Word 5 is what we are advertising. Bits 10 and 11 are Pause and Asym
Pause. In the good case here, neither are set. In this bad case above,
both bits are set.
The patch i asked you to try only cleared the Pause bit, not the
Asymmetric Pause bit. mii-tool only saying 'flow-control' did not
help.
Word 6 is what the partner is advertising. c1e1 indicates the partner
does not support flow control, both bits are 0. I don't see why this
is preventing auto-net though. But in the bad case, the status
register indicates auto-neg has not completed.
Anyway, please can you try this patch, which also removes Aysm Pause.
Thanks
Andrew
>From 00a061304af51831ca1dc86bf6ce23d01f724229 Mon Sep 17 00:00:00 2001
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 18 Sep 2018 18:12:54 -0500
Subject: [PATCH] ravb: Disable Pause Advertisement
The previous commit to ravb had the side effect of making the PHY
advertise Pause. This previously did not happen, and it appears the
MAC does not support Pause. By default, phydev->supported has Pause
enabled, but phydev->advertising does not. Rather than rely on this,
be explicit, and remove the Pause link mode.
Reported-by: Simon Horman <horms@verge.net.au>
Fixes: 41124fa64d4b ("net: ethernet: Add helper to remove a supported link mode")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index fb2a1125780d..b0f2612ad226 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1073,9 +1073,11 @@ static int ravb_phy_init(struct net_device *ndev)
netdev_info(ndev, "limited PHY to 100Mbit/s\n");
}
- /* 10BASE is not supported */
+ /* 10BASE, Pause and Asym Pause is not supported */
phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Full_BIT);
+ phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Pause_BIT);
+ phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
phy_attached_info(phydev);
--
2.19.0.rc1
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Li Yang @ 2018-09-20 19:07 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: robin.murphy,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Netdev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
madalin.bucur, Roy Pledge, Shawn Guo, David Miller
In-Reply-To: <33eac426-cbb7-f899-5a35-aea28f8e5dc4@nxp.com>
On Thu, Sep 20, 2018 at 5:39 AM Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote:
>
>
>
> On 19.09.2018 17:37, Robin Murphy wrote:
> > On 19/09/18 15:18, Laurentiu Tudor wrote:
> >> Hi Robin,
> >>
> >> On 19.09.2018 16:25, Robin Murphy wrote:
> >>> Hi Laurentiu,
> >>>
> >>> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
> >>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >>>>
> >>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
> >>>> and consists mostly in important driver fixes and the required device
> >>>> tree updates. It touches several subsystems and consists of three main
> >>>> parts:
> >>>> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
> >>>> reserved memory areas, fixes and defered probe support
> >>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
> >>>> consisting in misc dma mapping related fixes and probe ordering
> >>>> - addition of the actual arm smmu device tree node together with
> >>>> various adjustments to the device trees
> >>>>
> >>>> Performance impact
> >>>>
> >>>> Running iperf benchmarks in a back-to-back setup (both sides
> >>>> having smmu enabled) on a 10GBps port show an important
> >>>> networking performance degradation of around %40 (9.48Gbps
> >>>> linerate vs 5.45Gbps). If you need performance but without
> >>>> SMMU support you can use "iommu.passthrough=1" to disable
> >>>> SMMU.
> >>>>
> >>>> USB issue and workaround
> >>>>
> >>>> There's a problem with the usb controllers in these chips
> >>>> generating smaller, 40-bit wide dma addresses instead of the
> >>>> 48-bit
> >>>> supported at the smmu input. So you end up in a situation
> >>>> where the
> >>>> smmu is mapped with 48-bit address translations, but the device
> >>>> generates transactions with clipped 40-bit addresses, thus smmu
> >>>> context faults are triggered. I encountered a similar
> >>>> situation for
> >>>> mmc that I managed to fix in software [1] however for USB I
> >>>> did not
> >>>> find a proper place in the code to add a similar fix. The only
> >>>> workaround I found was to add this kernel parameter which
> >>>> limits the
> >>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
> >>>> This workaround if far from ideal, so any suggestions for a code
> >>>> based workaround in this area would be greatly appreciated.
> >>>
> >>> If you have a nominally-64-bit device with a
> >>> narrower-than-the-main-interconnect link in front of it, that should
> >>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
> >>> provided the interconnect hierarchy can be described appropriately (or
> >>> at least massaged sufficiently to satisfy the binding), e.g.:
> >>>
> >>> / {
> >>> ...
> >>>
> >>> soc {
> >>> ranges;
> >>> dma-ranges = <0 0 10000 0>;
> >>>
> >>> dev_48bit { ... };
> >>>
> >>> periph_bus {
> >>> ranges;
> >>> dma-ranges = <0 0 100 0>;
> >>>
> >>> dev_40bit { ... };
> >>> };
> >>> };
> >>> };
> >>>
> >>> and if that fails to work as expected (except for PCI hosts where
> >>> handling dma-ranges properly still needs sorting out), please do let us
> >>> know ;)
> >>>
> >>
> >> Just to confirm, Is this [1] the change I was supposed to test?
> >
> > Not quite - dma-ranges is only valid for nodes representing a bus, so
> > putting it directly in the USB device nodes doesn't work (FWIW that's
> > why PCI is broken, because the parser doesn't expect the
> > bus-as-leaf-node case). That's teh point of that intermediate simple-bus
> > node represented by "periph_bus" in my example (sorry, I should have put
> > compatibles in to make it clearer) - often that's actually true to life
> > (i.e. "soc" is something like a CCI and "periph_bus" is something like
> > an AXI NIC gluing a bunch of lower-bandwidth DMA masters to one of the
> > CCI ports) but at worst it's just a necessary evil to make the binding
> > happy (if it literally only represents the point-to-point link between
> > the device master port and interconnect slave port).
> >
>
> Quick update: so I adjusted to device tree according to your example and
> it works so now I can get rid of that nasty kernel arg based workaround,
> yey! :-)
Great that we have a generic solution like I hoped for! So you will
submit a new revision of the series to include these dts updates,
right?
Regards,
Leo
^ permalink raw reply
* Re: [PATCH net-next 4/5] ipv6: do not drop vrf udp multicast packets
From: Paolo Abeni @ 2018-09-20 13:02 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Dewi Morgan
In-Reply-To: <20180920085848.17721-5-mmanning@vyatta.att-mail.com>
Hi,
On Thu, 2018-09-20 at 09:58 +0100, Mike Manning wrote:
> diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
> index 108f5f88ec98..fc60f297d95b 100644
> --- a/net/ipv6/ip6_input.c
> +++ b/net/ipv6/ip6_input.c
> @@ -325,9 +325,12 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
> {
> const struct inet6_protocol *ipprot;
> struct inet6_dev *idev;
> + struct net_device *dev;
> unsigned int nhoff;
> + int sdif = inet6_sdif(skb);
> int nexthdr;
> bool raw;
> + bool deliver;
> bool have_final = false;
Please, try instead to sort the variable in reverse x-mas tree order.
>
> /*
> @@ -371,9 +374,27 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
> skb_postpull_rcsum(skb, skb_network_header(skb),
> skb_network_header_len(skb));
> hdr = ipv6_hdr(skb);
> - if (ipv6_addr_is_multicast(&hdr->daddr) &&
> - !ipv6_chk_mcast_addr(skb->dev, &hdr->daddr,
> - &hdr->saddr) &&
> +
> + /* skb->dev passed may be master dev for vrfs. */
> + if (sdif) {
> + rcu_read_lock();
AFAICS, the rcu lock is already acquired at the beginning of
ip6_input_finish(), not need to acquire it here again.
+ dev = dev_get_by_index_rcu(dev_net(skb->dev),
> + sdif);
> + if (!dev) {
> + rcu_read_unlock();
> + kfree_skb(skb);
> + return -ENODEV;
> + }
> + } else {
> + dev = skb->dev;
The above fragment of code is a recurring pattern in this series,
perhaps adding an helper for it would reduce code duplication ?
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH net-next] vhost_net: add a missing error return
From: Michael S. Tsirkin @ 2018-09-20 12:51 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Jason Wang, kvm, virtualization, netdev, kernel-janitors
In-Reply-To: <20180920100158.GA9551@mwanda>
On Thu, Sep 20, 2018 at 01:01:59PM +0300, Dan Carpenter wrote:
> We accidentally left out this error return so it leads to some use after
> free bugs later on.
>
> Fixes: 0a0be13b8fe2 ("vhost_net: batch submitting XDP buffers to underlayer sockets")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Ouch.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index dd4e0a301635..1bff6bc8161a 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -1244,6 +1244,7 @@ static int vhost_net_open(struct inode *inode, struct file *f)
> kfree(vqs);
> kvfree(n);
> kfree(queue);
> + return -ENOMEM;
> }
> n->vqs[VHOST_NET_VQ_TX].xdp = xdp;
>
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Andrew Lunn @ 2018-09-20 12:51 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, netdev, Florian Fainelli, Sergei Shtylyov,
linux-renesas-soc
In-Reply-To: <20180920080506.qxiy2zeg6xd3xxfz@verge.net.au>
> eth0: no link
> registers for MII PHY 0:
> 1140 7949 0022 1622 0981 c1e1 000d 0000
Hi Simon
The ID registers 0022 1622 indicate this is a Micrel KSZ9031.
Are you using the micrel PHY driver?
> I note a difference in the 3rd line of hex output: 7002 vs 6002
> but I am unsure if that is relevant.
Register 20, or 0x14. The datasheet says "Reserved" and there is no
description given :-(
I will decode the other registers and see if i can find anything.
Andrew
^ permalink raw reply
* [PATCH net-next 19/22] net: plip: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/plip/plip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index feb92ec..0b354e6 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -146,7 +146,7 @@
static void plip_interrupt(void *dev_id);
/* Functions for DEV methods */
-static int plip_tx_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t plip_tx_packet(struct sk_buff *skb, struct net_device *dev);
static int plip_hard_header(struct sk_buff *skb, struct net_device *dev,
unsigned short type, const void *daddr,
const void *saddr, unsigned len);
@@ -962,7 +962,7 @@ static __be16 plip_type_trans(struct sk_buff *skb, struct net_device *dev)
spin_unlock_irqrestore(&nl->lock, flags);
}
-static int
+static netdev_tx_t
plip_tx_packet(struct sk_buff *skb, struct net_device *dev)
{
struct net_local *nl = netdev_priv(dev);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 16/22] usbnet: ipheth: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/usb/ipheth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 7275761..53eab6fb 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -413,7 +413,7 @@ static int ipheth_close(struct net_device *net)
return 0;
}
-static int ipheth_tx(struct sk_buff *skb, struct net_device *net)
+static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct net_device *net)
{
struct ipheth_device *dev = netdev_priv(net);
struct usb_device *udev = dev->udev;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 13/22] net: xen-netback: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:32 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/xen-netback/interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 92274c2..7e3ea39 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -165,7 +165,8 @@ static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
return vif->hash.mapping[skb_get_hash_raw(skb) % size];
}
-static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 08/22] net: apple: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:32 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/apple/bmac.c | 4 ++--
drivers/net/ethernet/apple/mace.c | 4 ++--
drivers/net/ethernet/apple/macmace.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/apple/bmac.c b/drivers/net/ethernet/apple/bmac.c
index 024998d..6a8e256 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -154,7 +154,7 @@ struct bmac_data {
static irqreturn_t bmac_rxdma_intr(int irq, void *dev_id);
static void bmac_set_timeout(struct net_device *dev);
static void bmac_tx_timeout(struct timer_list *t);
-static int bmac_output(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t bmac_output(struct sk_buff *skb, struct net_device *dev);
static void bmac_start(struct net_device *dev);
#define DBDMA_SET(x) ( ((x) | (x) << 16) )
@@ -1456,7 +1456,7 @@ static int bmac_close(struct net_device *dev)
spin_unlock_irqrestore(&bp->lock, flags);
}
-static int
+static netdev_tx_t
bmac_output(struct sk_buff *skb, struct net_device *dev)
{
struct bmac_data *bp = netdev_priv(dev);
diff --git a/drivers/net/ethernet/apple/mace.c b/drivers/net/ethernet/apple/mace.c
index 0b5429d..68b9ee4 100644
--- a/drivers/net/ethernet/apple/mace.c
+++ b/drivers/net/ethernet/apple/mace.c
@@ -78,7 +78,7 @@ struct mace_data {
static int mace_open(struct net_device *dev);
static int mace_close(struct net_device *dev);
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
static void mace_set_multicast(struct net_device *dev);
static void mace_reset(struct net_device *dev);
static int mace_set_address(struct net_device *dev, void *addr);
@@ -525,7 +525,7 @@ static inline void mace_set_timeout(struct net_device *dev)
mp->timeout_active = 1;
}
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
{
struct mace_data *mp = netdev_priv(dev);
volatile struct dbdma_regs __iomem *td = mp->tx_dma;
diff --git a/drivers/net/ethernet/apple/macmace.c b/drivers/net/ethernet/apple/macmace.c
index 137cbb4..376f2c2 100644
--- a/drivers/net/ethernet/apple/macmace.c
+++ b/drivers/net/ethernet/apple/macmace.c
@@ -89,7 +89,7 @@ struct mace_frame {
static int mace_open(struct net_device *dev);
static int mace_close(struct net_device *dev);
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
static void mace_set_multicast(struct net_device *dev);
static int mace_set_address(struct net_device *dev, void *addr);
static void mace_reset(struct net_device *dev);
@@ -444,7 +444,7 @@ static int mace_close(struct net_device *dev)
* Transmit a frame
*/
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
{
struct mace_data *mp = netdev_priv(dev);
unsigned long flags;
--
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