* Re: [net PATCH v3 2/5] net: virtio: wrap rtnl_lock in test for calling with lock already held
From: John Fastabend @ 2017-01-13 23:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jasowang, mst, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <58790F02.8090409@gmail.com>
On 17-01-13 09:31 AM, John Fastabend wrote:
> On 17-01-13 08:34 AM, Stephen Hemminger wrote:
>> On Thu, 12 Jan 2017 18:51:00 -0800
>> John Fastabend <john.fastabend@gmail.com> wrote:
>>
>>>
>>> -static void free_receive_bufs(struct virtnet_info *vi)
>>> +static void free_receive_bufs(struct virtnet_info *vi, bool need_lock)
>>> {
>>> struct bpf_prog *old_prog;
>>> int i;
>>>
>>> - rtnl_lock();
>>> + if (need_lock)
>>> + rtnl_lock();
>>> for (i = 0; i < vi->max_queue_pairs; i++) {
>>> while (vi->rq[i].pages)
>>> __free_pages(get_a_page(&vi->rq[i], GFP_KERNEL), 0);
>>> @@ -1879,7 +1880,8 @@ static void free_receive_bufs(struct virtnet_info *vi)
>>> if (old_prog)
>>> bpf_prog_put(old_prog);
>>> }
>>> - rtnl_unlock();
>>> + if (need_lock)
>>> + rtnl_unlock();
>>> }
>>
>> Conditional locking is bad idea; sparse complains about it and is later source
>> of bugs. The more typical way of doing this in kernel is:
>
> OK I'll use the normal form.
>
>>
>> void _foo(some args)
>> {
>> ASSERT_RTNL();
>>
>> ...
>> }
>>
>> void foo(some args)
>> {
>> rtnl_lock();
>> _foo(some args)
>> rtnl_unlock();
>> }
>>
>>
>
Actually doing this without a rtnl_try_lock() is going to create two more
callbacks in virtio core just for virtio_net. All the other users do not
appear to have locking restrictions. How about the following it at least
helps in that there is no argument passing and if/else on the locks itself
but does use the if around rtnl_try_lock().
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1864,12 +1864,11 @@ static void virtnet_free_queues(struct virtnet_info *vi)
kfree(vi->sq);
}
-static void free_receive_bufs(struct virtnet_info *vi)
+static void _free_receive_bufs(struct virtnet_info *vi)
{
struct bpf_prog *old_prog;
int i;
- rtnl_lock();
for (i = 0; i < vi->max_queue_pairs; i++) {
while (vi->rq[i].pages)
__free_pages(get_a_page(&vi->rq[i], GFP_KERNEL), 0);
@@ -1879,6 +1878,12 @@ static void free_receive_bufs(struct virtnet_info *vi)
if (old_prog)
bpf_prog_put(old_prog);
}
+}
+
+static void free_receive_bufs(struct virtnet_info *vi)
+{
+ rtnl_lock();
+ _free_receive_bufs(vi);
rtnl_unlock();
}
@@ -2358,7 +2363,10 @@ static void remove_vq_common(struct virtnet_info *vi)
/* Free unused buffers in both send and recv, if any. */
free_unused_bufs(vi);
- free_receive_bufs(vi);
+ if (rtnl_is_locked());
+ _free_receive_bufs(vi);
+ else
+ free_receive_bufs(vi);
free_receive_page_frags(vi);
^ permalink raw reply
* Re: [Patch net] atm: remove an unnecessary loop
From: Chas Williams @ 2017-01-13 23:54 UTC (permalink / raw)
To: Cong Wang, David Miller
Cc: Francois Romieu, Linux Kernel Network Developers, Michal Hocko,
Andrey Konovalov
In-Reply-To: <CAM_iQpXd8qTTRT_+CkHnpMNC=CSS9vfB6zKtSjmLV_yya5BL8Q@mail.gmail.com>
On Fri, 2017-01-13 at 10:20 -0800, Cong Wang wrote:
> On Fri, Jan 13, 2017 at 9:10 AM, David Miller <davem@davemloft.net> wrote:
> > From: Francois Romieu <romieu@fr.zoreil.com>
> > Date: Fri, 13 Jan 2017 01:07:00 +0100
> >
> >> Were alloc_skb moved one level up in the call stack, there would be
> >> no need to use the new wait api in the subsequent page, thus easing
> >> pre 3.19 longterm kernel maintenance (at least those on korg page).
> >>
> >> But it tastes a tad bit too masochistic.
> >
> > Lack of error handling of allocation failure is always a huge red
> > flag. We even long ago tried to do something like this for TCP FIN
> > handling.
> >
> > It's dumb, it doesn't work.
> >
> > Therefore I agree that the correct fix is to move the SKB allocation
> > up one level to vcc_sendmsg() and make it handle errors properly.
>
> If you can justify API is not broken by doing that, I am more than happy
> to do it, as I already stated in the latter patch:
The man page for sendmsg() allows for ENOMEM. See below.
>
> "Of course, the logic itself is suspicious, other sendmsg()
> could handle skb allocation failure very well, not sure
> why ATM has to wait for a successful one here. But probably
> it is too late to change since the errno and behavior is
> visible to user-space. So just leave the logic as it is."
>
> For some reason, no one reads that patch. :-/
I read it and I agree. I think it should be moved up/conflated with
vcc_sendmsg(). vcc_sendmsg() can already return an errno for other
conditions so if so has written something where they are explicitly
not expecting a ENOMEM, we really can't help them.
I would certainly prefer to not have to resort to an atomic allocation.
That's just going to make matters worse as far as similarity to the
existing API.
So, as Francois has suggested, just wait for the atm socket to
drain, and then do the allocation after the wait is finished.
^ permalink raw reply
* [PATCH net-next] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Ahern @ 2017-01-13 23:54 UTC (permalink / raw)
To: netdev; +Cc: ddutt, David Ahern
IPv4 allows multipath routes to be deleted using just the prefix and
length. For example:
$ ip ro ls vrf red
unreachable default metric 8192
1.1.1.0/24
nexthop via 10.100.1.254 dev eth1 weight 1
nexthop via 10.11.200.2 dev eth11.200 weight 1
10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
$ ip ro del 1.1.1.0/24 vrf red
$ ip ro ls vrf red
unreachable default metric 8192
10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
The same notation does not work with IPv6 because of how multipath routes
are implemented for IPv6. For IPv6 only the first nexthop of a multipath
route is deleted if the request contains only a prefix and length. This
leads to unnecessary complexity in userspace dealing with IPv6 multipath
routes.
This patch allows all nexthops to be deleted without specifying each one
in the delete request by passing a new flag, RTM_F_ALL_NEXTHOPS, in
rtm_flags.
With this patch (and an updated iproute2 command):
$ ip -6 ro ls vrf red
1111::/120 via 2100:1::62 dev eth1 metric 1024 pref medium
1111::/120 via 2100:1::61 dev eth1 metric 1024 pref medium
1111::/120 via 2100:1::60 dev eth1 metric 1024 pref medium
2100:1::/120 dev eth1 proto kernel metric 256 pref medium
2100:1::/64 dev eth1 proto kernel metric 256 expires 86386sec pref medium
...
$ ip -6 ro del vrf red 1111::1/120
$ ip -6 ro ls vrf red
2100:1::/120 dev eth1 proto kernel metric 256 pref medium
2100:1::/64 dev eth1 proto kernel metric 256 expires 86382sec pref medium
...
The flag is added to fib6_config by converting fc_type to a u16 (as
noted fc_type only uses 8 bits). The new u16 hole is a bitmap with
fc_delete_all_nexthop as the first bit.
Suggested-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/net/ip6_fib.h | 4 +++-
include/uapi/linux/rtnetlink.h | 1 +
net/ipv6/route.c | 10 +++++++++-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index a74e2aa40ef4..11ab99e87c5f 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -37,7 +37,9 @@ struct fib6_config {
int fc_ifindex;
u32 fc_flags;
u32 fc_protocol;
- u32 fc_type; /* only 8 bits are used */
+ u16 fc_type; /* only 8 bits are used */
+ u16 fc_delete_all_nexthop : 1,
+ __unused : 15;
struct in6_addr fc_dst;
struct in6_addr fc_src;
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 8c93ad1ef9ab..7fb206bc42f9 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -276,6 +276,7 @@ enum rt_scope_t {
#define RTM_F_EQUALIZE 0x400 /* Multipath equalizer: NI */
#define RTM_F_PREFIX 0x800 /* Prefix addresses */
#define RTM_F_LOOKUP_TABLE 0x1000 /* set rtm_table to FIB lookup result */
+#define RTM_F_ALL_NEXTHOPS 0x2000 /* delete all nexthops (IPv6) */
/* Reserved table identifiers */
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ce5aaf448c54..8bb5f6a35ba8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2154,6 +2154,7 @@ static int ip6_route_del(struct fib6_config *cfg)
if (!table)
return err;
+again:
read_lock_bh(&table->tb6_lock);
fn = fib6_locate(&table->tb6_root,
@@ -2179,7 +2180,11 @@ static int ip6_route_del(struct fib6_config *cfg)
dst_hold(&rt->dst);
read_unlock_bh(&table->tb6_lock);
- return __ip6_del_rt(rt, &cfg->fc_nlinfo);
+ err = __ip6_del_rt(rt, &cfg->fc_nlinfo);
+ if (err || !cfg->fc_delete_all_nexthop)
+ return err;
+
+ goto again;
}
}
read_unlock_bh(&table->tb6_lock);
@@ -2849,6 +2854,9 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
if (rtm->rtm_flags & RTM_F_CLONED)
cfg->fc_flags |= RTF_CACHE;
+ if (rtm->rtm_flags & RTM_F_ALL_NEXTHOPS)
+ cfg->fc_delete_all_nexthop = 1;
+
cfg->fc_nlinfo.portid = NETLINK_CB(skb).portid;
cfg->fc_nlinfo.nlh = nlh;
cfg->fc_nlinfo.nl_net = sock_net(skb->sk);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net] bpf: rework prog_digest into prog_tag
From: Andy Lutomirski @ 2017-01-13 23:49 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Andrew Lutomirski,
Network Development
In-Reply-To: <58796595.3030904@iogearbox.net>
On Fri, Jan 13, 2017 at 3:41 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 01/14/2017 12:16 AM, Andy Lutomirski wrote:
>>
>> On Fri, Jan 13, 2017 at 2:38 PM, Daniel Borkmann <daniel@iogearbox.net>
>> wrote:
>>>
>>> Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
>>> fdinfo/netlink") was recently discussed, partially due to
>>> admittedly suboptimal name of "prog_digest" in combination
>>> with sha1 hash usage, thus inevitably and rightfully concerns
>>> about its security in terms of collision resistance were
>>> raised with regards to use-cases.
>>
>>
>> Seems reasonable. My only question is whether you'd still want to
>> switch to SHA-256 just from a code cleanliness perspective. With
>> SHA-256 you can use the easy streaming API I wrote, but with SHA-1
>> you're still stuck with the crappy API in lib/, and I'm not
>> volunteering to fix up the SHA-1 API.
>
>
> We'd need to truncate that in kernel anyway to not get a too long
> tag, so given that I'm actually fine with it as-is. I was planning
> to submit the code for testing to bpf selftests for net-next once
> it's merged back, too.
Unless you want to kill off that vmalloc()+vfree() pair...
--Andy
^ permalink raw reply
* [PATCH next] ipvlan: fix dev_id creation corner case.
From: Mahesh Bandewar @ 2017-01-13 23:48 UTC (permalink / raw)
To: David Miller
Cc: netdev, Mahesh Bandewar, Mahesh Bandewar, David Miller,
Eric Dumazet
From: Mahesh Bandewar <maheshb@google.com>
In the last patch da36e13cf65 ("ipvlan: improvise dev_id generation
logic in IPvlan") I missed some part of Dave's suggestion and because
of that the dev_id creation could fail in a corner case scenario. This
would happen when more or less 64k devices have been already created and
several have been deleted. If the devices that are still sticking around
are the last n bits from the bitmap. So in this scenario even if lower
bits are available, the dev_id search is so narrow that it always fails.
Fixes: da36e13cf65 ("ipvlan: improvise dev_id generation logic in IPvlan")
CC: David Miller <davem@davemloft.org>
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/ipvlan/ipvlan_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 92b221a03350..b5c390f0f2b3 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -550,6 +550,9 @@ static int ipvlan_link_new(struct net *src_net, struct net_device *dev,
err = ida_simple_get(&port->ida, port->dev_id_start, 0xFFFE,
GFP_KERNEL);
if (err < 0)
+ err = ida_simple_get(&port->ida, 0x1, port->dev_id_start,
+ GFP_KERNEL);
+ if (err < 0)
goto destroy_ipvlan_port;
dev->dev_id = err;
/* Increment id-base to the next slot for the future assignment */
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* Re: [PATCH net] bpf: rework prog_digest into prog_tag
From: Daniel Borkmann @ 2017-01-13 23:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David S. Miller, Alexei Starovoitov, Andrew Lutomirski,
Network Development
In-Reply-To: <CALCETrUjmscreaadCOn6hSEMBEf83JyhwdVtKj1=fAf3MuiDtQ@mail.gmail.com>
On 01/14/2017 12:16 AM, Andy Lutomirski wrote:
> On Fri, Jan 13, 2017 at 2:38 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
>> fdinfo/netlink") was recently discussed, partially due to
>> admittedly suboptimal name of "prog_digest" in combination
>> with sha1 hash usage, thus inevitably and rightfully concerns
>> about its security in terms of collision resistance were
>> raised with regards to use-cases.
>
> Seems reasonable. My only question is whether you'd still want to
> switch to SHA-256 just from a code cleanliness perspective. With
> SHA-256 you can use the easy streaming API I wrote, but with SHA-1
> you're still stuck with the crappy API in lib/, and I'm not
> volunteering to fix up the SHA-1 API.
We'd need to truncate that in kernel anyway to not get a too long
tag, so given that I'm actually fine with it as-is. I was planning
to submit the code for testing to bpf selftests for net-next once
it's merged back, too.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net] mlx4: do not call napi_schedule() without care
From: Eric Dumazet @ 2017-01-13 23:40 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, netdev, Erez Shitrit, Eugenia Emantayev,
Tariq Toukan
In-Reply-To: <CAKgT0UdgzU1BAjiKyMFeB+KOJbDSdbBS6KdHX2LZ_pWT3XiXjg@mail.gmail.com>
On Fri, 2017-01-13 at 15:07 -0800, Alexander Duyck wrote:
> On Fri, Jan 13, 2017 at 8:39 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Disable BH around the call to napi_schedule() to avoid following warning
> >
> > [ 52.095499] NOHZ: local_softirq_pending 08
> > [ 52.421291] NOHZ: local_softirq_pending 08
> > [ 52.608313] NOHZ: local_softirq_pending 08
> >
> > Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Erez Shitrit <erezsh@mellanox.com>
> > Cc: Eugenia Emantayev <eugenia@mellanox.com>
> > Cc: Tariq Toukan <tariqt@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > index 4910d9af19335d4b97d39760c163b41eecc26242..761f8b12399cab245abccc0f7d7f84fde742c14d 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > @@ -1748,8 +1748,11 @@ int mlx4_en_start_port(struct net_device *dev)
> > /* Process all completions if exist to prevent
> > * the queues freezing if they are full
> > */
> > - for (i = 0; i < priv->rx_ring_num; i++)
> > + for (i = 0; i < priv->rx_ring_num; i++) {
> > + local_bh_disable();
> > napi_schedule(&priv->rx_cq[i]->napi);
> > + local_bh_enable();
> > + }
>
> Couldn't you save yourself a ton of trouble by wrapping the loop
> inside of the local_bh_disable/enable instead of wrapping them up
> inside the loop? It just seems like it might be more efficient to
> schedule them and then process them as a block instead of doing it one
> at a time.
What kind of troubles ?
Given the problem might be happening under flood, I believe it is much
safer to do as I did.
Otherwise, we will have to process a ton of messages at the
local_bh_enable() time and lock the {softirq}IRQ on one cpu.
I chose to do this on purpose.
Batching can be dangerous, and this is exactly the point we do not want
batching, with say 64 queues.
This code is driver starts, hardly fast path.
^ permalink raw reply
* Re: [PATCH net] bpf: rework prog_digest into prog_tag
From: Alexei Starovoitov @ 2017-01-13 23:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Daniel Borkmann, David S. Miller, Andrew Lutomirski,
Network Development
In-Reply-To: <CALCETrUjmscreaadCOn6hSEMBEf83JyhwdVtKj1=fAf3MuiDtQ@mail.gmail.com>
On Fri, Jan 13, 2017 at 03:16:44PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 13, 2017 at 2:38 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> > Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
> > fdinfo/netlink") was recently discussed, partially due to
> > admittedly suboptimal name of "prog_digest" in combination
> > with sha1 hash usage, thus inevitably and rightfully concerns
> > about its security in terms of collision resistance were
> > raised with regards to use-cases.
> >
>
> Seems reasonable. My only question is whether you'd still want to
> switch to SHA-256 just from a code cleanliness perspective. With
> SHA-256 you can use the easy streaming API I wrote, but with SHA-1
> you're still stuck with the crappy API in lib/, and I'm not
> volunteering to fix up the SHA-1 API.
No. As was stated many times before there are only negatives
in switching to sha256.
^ permalink raw reply
* Re: [PATCH net] bpf: rework prog_digest into prog_tag
From: Andy Lutomirski @ 2017-01-13 23:16 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Andrew Lutomirski,
Network Development
In-Reply-To: <384476e29f6a378766c4052187b9b5f840f4030e.1484346362.git.daniel@iogearbox.net>
On Fri, Jan 13, 2017 at 2:38 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
> fdinfo/netlink") was recently discussed, partially due to
> admittedly suboptimal name of "prog_digest" in combination
> with sha1 hash usage, thus inevitably and rightfully concerns
> about its security in terms of collision resistance were
> raised with regards to use-cases.
>
Seems reasonable. My only question is whether you'd still want to
switch to SHA-256 just from a code cleanliness perspective. With
SHA-256 you can use the easy streaming API I wrote, but with SHA-1
you're still stuck with the crappy API in lib/, and I'm not
volunteering to fix up the SHA-1 API.
--Andy
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Daniel Borkmann @ 2017-01-13 23:08 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <CALCETrVhuszdsfayLrBBkSzJ+A3m+hJjdZQWDj9FOg+2UB_ZBw@mail.gmail.com>
On 01/11/2017 07:19 PM, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
[...]
>> Ok. Sleeping over this a bit, how about a general rename into
>> "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
>> the netlink attributes, fwiw, it might reduce any assumptions on
>> this being made? If this would be preferable, I could cook that
>> patch against -net for renaming it?
>
> That would be fine with me.
>
> I think there are two reasonable approaches to computing the actual tag.
>
> 1. Use a standard, modern cryptographic hash. SHA-256, SHA-512,
> Blake2b, whatever. SHA-1 is a bad choice in part because it's partly
> broken and in part because the implementation in lib/ is a real mess
> to use (as you noticed while writing the code).
>
> 2. Use whatever algorithm you like but make the tag so short that it's
> obviously not collision-free. 48 or 64 bits is probably reasonable.
>
> The intermediate versions are just asking for trouble.
Yeah agree, I've just sent a patch to rework this a bit and it got
also reasonably small for net. Cleanups, if needed, can be done in
net-next once that's pulled into it.
Thanks,
Daniel
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Tom Herbert @ 2017-01-13 23:07 UTC (permalink / raw)
To: Rick Jones
Cc: Saeed Mahameed, Leon Romanovsky, David Miller, Saeed Mahameed,
Doug Ledford, Linux Kernel Network Developers,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <10e998b7-0008-2f26-2874-57ec61c8cacb-ZPxbGqLxI0U@public.gmane.org>
On Fri, Jan 13, 2017 at 2:59 PM, Rick Jones <rick.jones2-ZPxbGqLxI0U@public.gmane.org> wrote:
> On 01/13/2017 02:56 PM, Tom Herbert wrote:
>>
>> On Fri, Jan 13, 2017 at 2:45 PM, Saeed Mahameed
>>>
>>> what configuration are you running ? what traffic ?
>>>
>> Nothing fancy. 8 queues and 20 concurrent netperf TCP_STREAMs trips
>> it. Not a lot of them, but I don't think we really should ever see
>> these errors.
>
>
> Straight-up defaults with netperf, or do you use specific -s/S or -m/M
> options?
>
./super_netperf_tput 20 -H test001 -l 100 -t TCP_STREAM
> happy benchmarking,
>
> rick jones
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] mlx4: do not call napi_schedule() without care
From: Alexander Duyck @ 2017-01-13 23:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Erez Shitrit, Eugenia Emantayev,
Tariq Toukan
In-Reply-To: <1484325564.13165.30.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Jan 13, 2017 at 8:39 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Disable BH around the call to napi_schedule() to avoid following warning
>
> [ 52.095499] NOHZ: local_softirq_pending 08
> [ 52.421291] NOHZ: local_softirq_pending 08
> [ 52.608313] NOHZ: local_softirq_pending 08
>
> Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Erez Shitrit <erezsh@mellanox.com>
> Cc: Eugenia Emantayev <eugenia@mellanox.com>
> Cc: Tariq Toukan <tariqt@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 4910d9af19335d4b97d39760c163b41eecc26242..761f8b12399cab245abccc0f7d7f84fde742c14d 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1748,8 +1748,11 @@ int mlx4_en_start_port(struct net_device *dev)
> /* Process all completions if exist to prevent
> * the queues freezing if they are full
> */
> - for (i = 0; i < priv->rx_ring_num; i++)
> + for (i = 0; i < priv->rx_ring_num; i++) {
> + local_bh_disable();
> napi_schedule(&priv->rx_cq[i]->napi);
> + local_bh_enable();
> + }
Couldn't you save yourself a ton of trouble by wrapping the loop
inside of the local_bh_disable/enable instead of wrapping them up
inside the loop? It just seems like it might be more efficient to
schedule them and then process them as a block instead of doing it one
at a time.
- Alex
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Rick Jones @ 2017-01-13 22:59 UTC (permalink / raw)
To: Tom Herbert, Saeed Mahameed
Cc: Leon Romanovsky, David Miller, Saeed Mahameed, Doug Ledford,
Linux Kernel Network Developers,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALx6S35cSnMoBtxi+Eb_mH=LCLy9yY6U5sxofndce9r0eCs8+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/13/2017 02:56 PM, Tom Herbert wrote:
> On Fri, Jan 13, 2017 at 2:45 PM, Saeed Mahameed
>> what configuration are you running ? what traffic ?
>>
> Nothing fancy. 8 queues and 20 concurrent netperf TCP_STREAMs trips
> it. Not a lot of them, but I don't think we really should ever see
> these errors.
Straight-up defaults with netperf, or do you use specific -s/S or -m/M
options?
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Tom Herbert @ 2017-01-13 22:56 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Leon Romanovsky, David Miller, Saeed Mahameed, Doug Ledford,
Linux Kernel Network Developers,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALzJLG_RsvgszVxGZ7+VgYjET9w=XTjq36Z72diOQFNJWz9tQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jan 13, 2017 at 2:45 PM, Saeed Mahameed
<saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> On Sat, Jan 14, 2017 at 12:06 AM, Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org> wrote:
>> On Fri, Jan 13, 2017 at 12:29 PM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Fri, Jan 13, 2017 at 12:14:07PM -0500, David Miller wrote:
>>>> From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>>
>>>> > This pull request includes one patch from Leon, this patch as described
>>>> > below will change the driver directory structure and layout for better,
>>>> > logical and modular driver files separation.
>>>> >
>>>> > This change is important to both rdma and net maintainers in order to
>>>> > have smoother management of driver patches for different mlx5 sub modules
>>>> > and smoother rdma-next vs. net-next features submissions.
>>>> >
>>>> > Please find more info below -in the tag commit message-,
>>>> > review and let us know if there's any problem.
>>>> >
>>>> > This change doesn't introduce any conflicts with the current mlx5
>>>> > fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>>> > worked flawlessly with no issues.
>>>> >
>>>> > This is the last pull request meant for both rdma-next and net-next.
>>>> > Once pulled, this will be the base shared code for both trees.
>>>>
>>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>>> a complete nightmare for myself, Doug, various distribution maintainers
>>>> and many other people who quietly have to maintain their own trees and
>>>> do backporting.
>>>
>>> Hi Dave,
>>>
>>> I understand your worries, but our case is similar to various other
>>> drivers, for example hfi1 which was in staging for years while
>>> supported in RedHat and moved from there to IB. The Chelsio drivers did
>>> similar reorg in 2016 (drivers/net/ethernet/chelsio/libcxgb) while their
>>> drivers were in the tree for long time before.
>>>
>>> Additionally, Doug doesn't need to maintain -stable queue and it is done
>>> by relevant submaintainers who are adding stable tags by themselves. In
>>> the IB case, the burden will continue to be on me and not on Doug.
>>>
>> Recently I had to backport the mlx5 driver from 4.9 to 4.6 in order to
>> get support for XDP. The biggest issue I faced was the lack of
>> modularity in the many driver features that are now supported. The
>> problem with backporting these new features is the spider web of
>> dependencies that they bring in from the rest of the kernel. I ended
>> up taking out en_rep, vxlan, en_tc, eswitch, and dcbnl. The result was
>> ~340 patches which is still a lot but at least this was constrained to
>> patches in the mlx5 directories and are relevant to what we want to
>> do.
>>
>> In lieu of restructuring the directories, I would much rather see more
>> config options so that we can build drivers that don't unnecessarily
>> complicate our lives with features we don't use. This is not just true
>> for Mellanox, but I would say it would be true of any driver that
>> someone is trying to deploy and maintain at large scale.
>>
>
> I think we should have both, if the restructuring made right,
> new whole features (e.g eswitch and eswitch offlaods or any independent module),
> can sit in their own directory and keep their own logic concentrated
> in one place, and only touch the
> main driver code with simple entry points in the main flow, this way
> you can simply compile their whole directories
> out with a config flag directly from the Makefile.
>
>> Btw, we did hit one issue in the backport. We started to get rx csum
>> faults (checksum complete value indicates TCP checksum is bad, but
>> host computation says checksum is good). I ran against 4.9 upstream
>> kernel and do see these, however don't see them in 4.10. I haven't
>> bisected yet. Is this a known issue?
>>
>
> Not to me, I don't recall any csum related fixes or feature submitted
> lately to mlx5,
> Maybe something changed in the stack ?
>
> what configuration are you running ? what traffic ?
>
Nothing fancy. 8 queues and 20 concurrent netperf TCP_STREAMs trips
it. Not a lot of them, but I don't think we really should ever see
these errors.
Tom
>> Thanks,
>> Tom
>>
>>>>
>>>> I really don't think you can justify this rearrangement based upon the
>>>> consequences and how much activity happens in this driver.
>>>>
>>>> You should have thought long and hard about the layout a long time ago
>>>> rather than after the driver has been in the tree for many years.
>>>>
>>>> Sorry.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: bpf: flush the entire JIT buffer
From: Daniel Borkmann @ 2017-01-13 22:55 UTC (permalink / raw)
To: Naveen N. Rao, mpe; +Cc: linuxppc-dev, netdev, ast, davem
In-Reply-To: <897d01cca8cd61a42493a4f6ba6bfca056419686.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
On 01/13/2017 06:10 PM, Naveen N. Rao wrote:
> With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
> the rest of the space with illegal instructions to mitigate BPF spraying
> attacks, while having the actual JIT'ed BPF program at a random location
> within the allocated space. Under this scenario, it would be better to
> flush the entire allocated buffer rather than just the part containing
> the actual program. We already flush the buffer from start to the end of
> the BPF program. Extend this to include the illegal instructions after
> the BPF program.
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 2/2] mpls: Packet stats
From: Roopa Prabhu @ 2017-01-13 22:51 UTC (permalink / raw)
To: Robert Shearman; +Cc: davem, netdev, David Ahern, ebiederm
In-Reply-To: <1484331253-5908-3-git-send-email-rshearma@brocade.com>
On 1/13/17, 10:14 AM, Robert Shearman wrote:
> Having MPLS packet stats is useful for observing network operation and
> for diagnosing network problems. In the absence of anything better,
> RFC2863 and RFC3813 are used for guidance for which stats to expose
> and the semantics of them. In particular rx_noroutes maps to in
> unknown protos in RFC2863. The stats are exposed to userspace via
> AF_MPLS attributes embedded in the IFLA_STATS_AF_SPEC attribute of
> RTM_GETSTATS messages.
>
> All the introduced fields are 64-bit, even error ones, to ensure no
> overflow with long uptimes. Per-CPU counters are used to avoid
> cache-line contention on the commonly used fields. The other fields
> have also been made per-CPU for code to avoid performance problems in
> error conditions on the assumption that on some platforms the cost of
> atomic operations could be more expensive than sending the packet
> (which is what would be done in the success case). If that's not the
> case, we could instead not use per-CPU counters for these fields.
>
> Only unicast and non-fragment are exposed at the moment, but other
> counters can be exposed in the future either by adding to the end of
> struct mpls_link_stats or by additional netlink attributes in the
> AF_MPLS IFLA_STATS_AF_SPEC nested attribute.
>
> Signed-off-by: Robert Shearman <rshearma@brocade.com>
> ---
>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: AF-specific RTM_GETSTATS attributes
From: Roopa Prabhu @ 2017-01-13 22:50 UTC (permalink / raw)
To: Robert Shearman; +Cc: davem, netdev, David Ahern, ebiederm
In-Reply-To: <1484331253-5908-2-git-send-email-rshearma@brocade.com>
On 1/13/17, 10:14 AM, Robert Shearman wrote:
> Add the functionality for including address-family-specific per-link
> stats in RTM_GETSTATS messages. This is done through adding a new
> IFLA_STATS_AF_SPEC attribute under which address family attributes are
> nested and then the AF-specific attributes can be further nested. This
> follows the model of IFLA_AF_SPEC on RTM_*LINK messages and it has the
> advantage of presenting an easily extended hierarchy. The rtnl_af_ops
> structure is extended to provide AFs with the opportunity to fill and
> provide the size of their stats attributes.
>
> One alternative would have been to provide AFs with the ability to add
> attributes directly into the RTM_GETSTATS message without a nested
> hierarchy. I discounted this approach as it increases the rate at
> which the 32 attribute number space is used up and it makes
> implementation a little more tricky for stats dump resuming (at the
> moment the order in which attributes are added to the message has to
> match the numeric order of the attributes).
>
> Another alternative would have been to register per-AF RTM_GETSTATS
> handlers. I discounted this approach as I perceived a common use-case
> to be getting all the stats for an interface and this approach would
> necessitate multiple requests/dumps to retrieve them all.
>
> Signed-off-by: Robert Shearman <rshearma@brocade.com>
>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net-next 0/2] mpls: Packet stats
From: Roopa Prabhu @ 2017-01-13 22:50 UTC (permalink / raw)
To: Robert Shearman; +Cc: davem, netdev, David Ahern, ebiederm
In-Reply-To: <1484331253-5908-1-git-send-email-rshearma@brocade.com>
On 1/13/17, 10:14 AM, Robert Shearman wrote:
> This patchset records per-interface packet stats in the MPLS
> forwarding path and exports them using a nest of attributes root at a
> new IFLA_STATS_AF_SPEC attribute as part of RTM_GETSTATS messages:
>
> [IFLA_STATS_AF_SPEC]
> -> [AF_MPLS]
> -> [MPLS_STATS_LINK]
> -> struct mpls_link_stats
>
> The first patch adds the rtnl infrastructure for this, including a new
> callbacks to per-AF ops of fill_stats_af and get_stats_af_size. The
> second patch records MPLS stats and makes use of the infrastructure to
> export them. The rtnl infrastructure could also be used to export IPv6
> stats in the future.
>
> Robert Shearman (2):
> net: AF-specific RTM_GETSTATS attributes
> mpls: Packet stats
>
LGTM, thanks Robert
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Saeed Mahameed @ 2017-01-13 22:45 UTC (permalink / raw)
To: Tom Herbert
Cc: Leon Romanovsky, David Miller, Saeed Mahameed, Doug Ledford,
Linux Kernel Network Developers, linux-rdma
In-Reply-To: <CALx6S37hb78RJ8tCtsCsX2fg6e-D+naNpSQo6T2AyWMd0U74sQ@mail.gmail.com>
On Sat, Jan 14, 2017 at 12:06 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, Jan 13, 2017 at 12:29 PM, Leon Romanovsky <leon@kernel.org> wrote:
>> On Fri, Jan 13, 2017 at 12:14:07PM -0500, David Miller wrote:
>>> From: Saeed Mahameed <saeedm@mellanox.com>
>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>
>>> > This pull request includes one patch from Leon, this patch as described
>>> > below will change the driver directory structure and layout for better,
>>> > logical and modular driver files separation.
>>> >
>>> > This change is important to both rdma and net maintainers in order to
>>> > have smoother management of driver patches for different mlx5 sub modules
>>> > and smoother rdma-next vs. net-next features submissions.
>>> >
>>> > Please find more info below -in the tag commit message-,
>>> > review and let us know if there's any problem.
>>> >
>>> > This change doesn't introduce any conflicts with the current mlx5
>>> > fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>> > worked flawlessly with no issues.
>>> >
>>> > This is the last pull request meant for both rdma-next and net-next.
>>> > Once pulled, this will be the base shared code for both trees.
>>>
>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>> a complete nightmare for myself, Doug, various distribution maintainers
>>> and many other people who quietly have to maintain their own trees and
>>> do backporting.
>>
>> Hi Dave,
>>
>> I understand your worries, but our case is similar to various other
>> drivers, for example hfi1 which was in staging for years while
>> supported in RedHat and moved from there to IB. The Chelsio drivers did
>> similar reorg in 2016 (drivers/net/ethernet/chelsio/libcxgb) while their
>> drivers were in the tree for long time before.
>>
>> Additionally, Doug doesn't need to maintain -stable queue and it is done
>> by relevant submaintainers who are adding stable tags by themselves. In
>> the IB case, the burden will continue to be on me and not on Doug.
>>
> Recently I had to backport the mlx5 driver from 4.9 to 4.6 in order to
> get support for XDP. The biggest issue I faced was the lack of
> modularity in the many driver features that are now supported. The
> problem with backporting these new features is the spider web of
> dependencies that they bring in from the rest of the kernel. I ended
> up taking out en_rep, vxlan, en_tc, eswitch, and dcbnl. The result was
> ~340 patches which is still a lot but at least this was constrained to
> patches in the mlx5 directories and are relevant to what we want to
> do.
>
> In lieu of restructuring the directories, I would much rather see more
> config options so that we can build drivers that don't unnecessarily
> complicate our lives with features we don't use. This is not just true
> for Mellanox, but I would say it would be true of any driver that
> someone is trying to deploy and maintain at large scale.
>
I think we should have both, if the restructuring made right,
new whole features (e.g eswitch and eswitch offlaods or any independent module),
can sit in their own directory and keep their own logic concentrated
in one place, and only touch the
main driver code with simple entry points in the main flow, this way
you can simply compile their whole directories
out with a config flag directly from the Makefile.
> Btw, we did hit one issue in the backport. We started to get rx csum
> faults (checksum complete value indicates TCP checksum is bad, but
> host computation says checksum is good). I ran against 4.9 upstream
> kernel and do see these, however don't see them in 4.10. I haven't
> bisected yet. Is this a known issue?
>
Not to me, I don't recall any csum related fixes or feature submitted
lately to mlx5,
Maybe something changed in the stack ?
what configuration are you running ? what traffic ?
> Thanks,
> Tom
>
>>>
>>> I really don't think you can justify this rearrangement based upon the
>>> consequences and how much activity happens in this driver.
>>>
>>> You should have thought long and hard about the layout a long time ago
>>> rather than after the driver has been in the tree for many years.
>>>
>>> Sorry.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 08/10] net: dsa: Add support for platform data
From: Florian Fainelli @ 2017-01-13 22:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, open list, gregkh
In-Reply-To: <20170113141110.GI10203@lunn.ch>
On 01/13/2017 06:11 AM, Andrew Lunn wrote:
>> static int _dsa_register_switch(struct dsa_switch *ds, struct device *dev)
>> {
>> + struct dsa_chip_data *pdata = dev->platform_data;
>> struct device_node *np = dev->of_node;
>> struct dsa_switch_tree *dst;
>> struct device_node *ports;
>> u32 tree, index;
>> int i, err;
>>
>> - err = dsa_parse_member_dn(np, &tree, &index);
>> - if (err)
>> - return err;
>> + if (np) {
>> + err = dsa_parse_member_dn(np, &tree, &index);
>> + if (err)
>> + return err;
>>
>> - ports = dsa_get_ports(ds, np);
>> - if (IS_ERR(ports))
>> - return PTR_ERR(ports);
>> + ports = dsa_get_ports(ds, np);
>> + if (IS_ERR(ports))
>> + return PTR_ERR(ports);
>>
>> - err = dsa_parse_ports_dn(ports, ds);
>> - if (err)
>> - return err;
>> + err = dsa_parse_ports_dn(ports, ds);
>> + if (err)
>> + return err;
>> + } else {
>> + err = dsa_parse_member(pdata, &tree, &index);
>
Hello Andrew,
> Hi Florian
>
> Maybe it is hiding, but i don't see anywhere you check that pdata !=
> NULL.
You are right, there is not such a check, it should probably be added
early on.
>
> At least for x86 platforms, i don't expect we are booting using
> platform data like ARM systems used to do. I think it is more likely a
> glue module will be loaded. It looks up the MDIO bus and appends a
> platform data to an MDIO device. The switch driver then needs to load
> and use the platform data. But if things happen in a different order,
> it could be the switch driver probes before the glue driver, meaning
> pdata is NULL.
That's very valid, I will fix this, thanks!
>
> Do we even want to return -EPROBE_DEFERED?
I was trying to exercise that code path a little bit, but could not
quite make sense of what I was seeing, let me try again with more tracing.
--
Florian
^ permalink raw reply
* [PATCH net] bpf: rework prog_digest into prog_tag
From: Daniel Borkmann @ 2017-01-13 22:38 UTC (permalink / raw)
To: davem; +Cc: alexei.starovoitov, luto, netdev, Daniel Borkmann
Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
fdinfo/netlink") was recently discussed, partially due to
admittedly suboptimal name of "prog_digest" in combination
with sha1 hash usage, thus inevitably and rightfully concerns
about its security in terms of collision resistance were
raised with regards to use-cases.
The intended use cases are for debugging resp. introspection
only for providing a stable "tag" over the instruction sequence
that both kernel and user space can calculate independently.
It's not usable at all for making a security relevant decision.
So collisions where two different instruction sequences generate
the same tag can happen, but ideally at a rather low rate. The
"tag" will be dumped in hex and is short enough to introspect
in tracepoints or kallsyms output along with other data such
as stack trace, etc. Thus, this patch performs a rename into
prog_tag and truncates the tag to a short output (64 bits) to
make it obvious it's not collision-free.
Should in future a hash or facility be needed with a security
relevant focus, then we can think about requirements, constraints,
etc that would fit to that situation. For now, rework the exposed
parts for the current use cases as long as nothing has been
released yet. Tested on x86_64 and s390x.
Fixes: 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
---
include/linux/bpf.h | 2 +-
include/linux/filter.h | 6 ++++--
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
kernel/bpf/core.c | 14 ++++++++------
kernel/bpf/syscall.c | 8 ++++----
kernel/bpf/verifier.c | 2 +-
net/sched/act_bpf.c | 5 ++---
net/sched/cls_bpf.c | 4 ++--
9 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index f74ae68..05cf951 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -216,7 +216,7 @@ struct bpf_event_entry {
u64 bpf_get_stackid(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
bool bpf_prog_array_compatible(struct bpf_array *array, const struct bpf_prog *fp);
-int bpf_prog_calc_digest(struct bpf_prog *fp);
+int bpf_prog_calc_tag(struct bpf_prog *fp);
const struct bpf_func_proto *bpf_get_trace_printk_proto(void);
diff --git a/include/linux/filter.h b/include/linux/filter.h
index a0934e6..e4eb254 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -57,6 +57,8 @@
/* BPF program can access up to 512 bytes of stack space. */
#define MAX_BPF_STACK 512
+#define BPF_TAG_SIZE 8
+
/* Helper macros for filter block array initializers. */
/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
@@ -408,7 +410,7 @@ struct bpf_prog {
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
- u32 digest[SHA_DIGEST_WORDS]; /* Program digest */
+ u8 tag[BPF_TAG_SIZE];
struct bpf_prog_aux *aux; /* Auxiliary fields */
struct sock_fprog_kern *orig_prog; /* Original BPF program */
unsigned int (*bpf_func)(const void *ctx,
@@ -519,7 +521,7 @@ static inline u32 bpf_prog_insn_size(const struct bpf_prog *prog)
return prog->len * sizeof(struct bpf_insn);
}
-static inline u32 bpf_prog_digest_scratch_size(const struct bpf_prog *prog)
+static inline u32 bpf_prog_tag_scratch_size(const struct bpf_prog *prog)
{
return round_up(bpf_prog_insn_size(prog) +
sizeof(__be64) + 1, SHA_MESSAGE_BYTES);
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc..a4dcd88 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -397,7 +397,7 @@ enum {
TCA_BPF_NAME,
TCA_BPF_FLAGS,
TCA_BPF_FLAGS_GEN,
- TCA_BPF_DIGEST,
+ TCA_BPF_TAG,
__TCA_BPF_MAX,
};
diff --git a/include/uapi/linux/tc_act/tc_bpf.h b/include/uapi/linux/tc_act/tc_bpf.h
index a6b88a6..975b50d 100644
--- a/include/uapi/linux/tc_act/tc_bpf.h
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -27,7 +27,7 @@ enum {
TCA_ACT_BPF_FD,
TCA_ACT_BPF_NAME,
TCA_ACT_BPF_PAD,
- TCA_ACT_BPF_DIGEST,
+ TCA_ACT_BPF_TAG,
__TCA_ACT_BPF_MAX,
};
#define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 1eb4f13..503d421 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -146,10 +146,11 @@ void __bpf_prog_free(struct bpf_prog *fp)
vfree(fp);
}
-int bpf_prog_calc_digest(struct bpf_prog *fp)
+int bpf_prog_calc_tag(struct bpf_prog *fp)
{
const u32 bits_offset = SHA_MESSAGE_BYTES - sizeof(__be64);
- u32 raw_size = bpf_prog_digest_scratch_size(fp);
+ u32 raw_size = bpf_prog_tag_scratch_size(fp);
+ u32 digest[SHA_DIGEST_WORDS];
u32 ws[SHA_WORKSPACE_WORDS];
u32 i, bsize, psize, blocks;
struct bpf_insn *dst;
@@ -162,7 +163,7 @@ int bpf_prog_calc_digest(struct bpf_prog *fp)
if (!raw)
return -ENOMEM;
- sha_init(fp->digest);
+ sha_init(digest);
memset(ws, 0, sizeof(ws));
/* We need to take out the map fd for the digest calculation
@@ -204,13 +205,14 @@ int bpf_prog_calc_digest(struct bpf_prog *fp)
*bits = cpu_to_be64((psize - 1) << 3);
while (blocks--) {
- sha_transform(fp->digest, todo, ws);
+ sha_transform(digest, todo, ws);
todo += SHA_MESSAGE_BYTES;
}
- result = (__force __be32 *)fp->digest;
+ result = (__force __be32 *)digest;
for (i = 0; i < SHA_DIGEST_WORDS; i++)
- result[i] = cpu_to_be32(fp->digest[i]);
+ result[i] = cpu_to_be32(digest[i]);
+ memcpy(fp->tag, result, sizeof(fp->tag));
vfree(raw);
return 0;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea..1d6b29e 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -688,17 +688,17 @@ static int bpf_prog_release(struct inode *inode, struct file *filp)
static void bpf_prog_show_fdinfo(struct seq_file *m, struct file *filp)
{
const struct bpf_prog *prog = filp->private_data;
- char prog_digest[sizeof(prog->digest) * 2 + 1] = { };
+ char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
- bin2hex(prog_digest, prog->digest, sizeof(prog->digest));
+ bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
seq_printf(m,
"prog_type:\t%u\n"
"prog_jited:\t%u\n"
- "prog_digest:\t%s\n"
+ "prog_tag:\t%s\n"
"memlock:\t%llu\n",
prog->type,
prog->jited,
- prog_digest,
+ prog_tag,
prog->pages * 1ULL << PAGE_SHIFT);
}
#endif
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 83ed2f8..cdc43b8 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2936,7 +2936,7 @@ static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env)
int insn_cnt = env->prog->len;
int i, j, err;
- err = bpf_prog_calc_digest(env->prog);
+ err = bpf_prog_calc_tag(env->prog);
if (err)
return err;
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1c60317..520baa41 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -123,12 +123,11 @@ static int tcf_bpf_dump_ebpf_info(const struct tcf_bpf *prog,
nla_put_string(skb, TCA_ACT_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
- nla = nla_reserve(skb, TCA_ACT_BPF_DIGEST,
- sizeof(prog->filter->digest));
+ nla = nla_reserve(skb, TCA_ACT_BPF_TAG, sizeof(prog->filter->tag));
if (nla == NULL)
return -EMSGSIZE;
- memcpy(nla_data(nla), prog->filter->digest, nla_len(nla));
+ memcpy(nla_data(nla), prog->filter->tag, nla_len(nla));
return 0;
}
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index adc7760..d9c9701 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -555,11 +555,11 @@ static int cls_bpf_dump_ebpf_info(const struct cls_bpf_prog *prog,
nla_put_string(skb, TCA_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
- nla = nla_reserve(skb, TCA_BPF_DIGEST, sizeof(prog->filter->digest));
+ nla = nla_reserve(skb, TCA_BPF_TAG, sizeof(prog->filter->tag));
if (nla == NULL)
return -EMSGSIZE;
- memcpy(nla_data(nla), prog->filter->digest, nla_len(nla));
+ memcpy(nla_data(nla), prog->filter->tag, nla_len(nla));
return 0;
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next v2 08/10] net: dsa: Add support for platform data
From: Florian Fainelli @ 2017-01-13 22:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, open list, gregkh
In-Reply-To: <20170113140459.GH10203@lunn.ch>
On 01/13/2017 06:04 AM, Andrew Lunn wrote:
>> index cd91070b5467..d326fc4afad7 100644
>> --- a/net/dsa/dsa2.c
>> +++ b/net/dsa/dsa2.c
>> @@ -81,17 +81,23 @@ static void dsa_dst_del_ds(struct dsa_switch_tree *dst,
>>
>> static bool dsa_port_is_valid(struct dsa_port *port)
>> {
>> - return !!port->dn;
>> + return !!(port->dn || port->name);
>> }
>
> Does this clash with Viviens recent change to make names optional and
> have the kernel assign it?
So there were two ways to look at this, one was that could check here
that ds->pd is assigned and port->name is assigned, which means that
platform data has to provide valid port name. We can also eliminate this
check entirely because we now support NULL names just fines.
>
> I suppose you could use an name of "eth%d"? Is it worth adding a
> comment to the platform data structure?
Humm, that could be done, maybe for simplicity we can just let
net/dsa/dsa2.c assign names either based on what platform data provided,
or by falling back to eth%d.
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5e: Support bpf_xdp_adjust_head()
From: Martin KaFai Lau @ 2017-01-13 22:31 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Linux Netdev List, Saeed Mahameed, Tariq Toukan, Kernel Team
In-Reply-To: <CALzJLG_9MTsTV4Y=+BgT7MXO+x-rq526fntxLdAOt=nLD6j9mA@mail.gmail.com>
On Fri, Jan 13, 2017 at 03:58:46PM +0200, Saeed Mahameed wrote:
> >> > @@ -680,7 +687,7 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
> >> > memset(wqe, 0, sizeof(*wqe));
> >> >
> >> > /* copy the inline part */
> >> > - memcpy(eseg->inline_hdr_start, data, MLX5E_XDP_MIN_INLINE);
> >> > + memcpy(eseg->inline_hdr_start, xdp->data, MLX5E_XDP_MIN_INLINE);
> >> > eseg->inline_hdr_sz = cpu_to_be16(MLX5E_XDP_MIN_INLINE);
> >> >
> >> > dseg = (struct mlx5_wqe_data_seg *)cseg + (MLX5E_XDP_TX_DS_COUNT - 1);
> >> > @@ -706,22 +713,16 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
> >> > static inline bool mlx5e_xdp_handle(struct mlx5e_rq *rq,
> >> > const struct bpf_prog *prog,
> >> > struct mlx5e_dma_info *di,
> >> > - void *data, u16 len)
> >> > + struct xdp_buff *xdp)
> >> > {
> >> > - struct xdp_buff xdp;
> >> > u32 act;
> >> >
> >> > - if (!prog)
> >> > - return false;
> >> > -
> >> > - xdp.data = data;
> >> > - xdp.data_end = xdp.data + len;
> >> > - act = bpf_prog_run_xdp(prog, &xdp);
> >> > + act = bpf_prog_run_xdp(prog, xdp);
> >> > switch (act) {
> >> > case XDP_PASS:
> >> > return false;
> >> > case XDP_TX:
> >> > - mlx5e_xmit_xdp_frame(rq, di, MLX5_RX_HEADROOM, len);
> >> > + mlx5e_xmit_xdp_frame(rq, di, xdp);
> >> > return true;
> >> > default:
> >> > bpf_warn_invalid_xdp_action(act);
> >> > @@ -737,18 +738,19 @@ static inline
> >> > struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
> >> > u16 wqe_counter, u32 cqe_bcnt)
> >> > {
> >> > + const struct bpf_prog *xdp_prog;
> >> > struct mlx5e_dma_info *di;
> >> > struct sk_buff *skb;
> >> > void *va, *data;
> >> > - bool consumed;
> >> > + u16 rx_headroom = rq->rx_headroom;
> >> >
> >> > di = &rq->dma_info[wqe_counter];
> >> > va = page_address(di->page);
> >> > - data = va + MLX5_RX_HEADROOM;
> >> > + data = va + rx_headroom;
> >> >
> >> > dma_sync_single_range_for_cpu(rq->pdev,
> >> > di->addr,
> >> > - MLX5_RX_HEADROOM,
> >> > + rx_headroom,
> >> > rq->buff.wqe_sz,
> >> > DMA_FROM_DEVICE);
> >> > prefetch(data);
> >> > @@ -760,11 +762,26 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
> >> > }
> >> >
> >> > rcu_read_lock();
> >> > - consumed = mlx5e_xdp_handle(rq, READ_ONCE(rq->xdp_prog), di, data,
> >> > - cqe_bcnt);
> >> > + xdp_prog = READ_ONCE(rq->xdp_prog);
> >> > + if (xdp_prog) {
> >> > + struct xdp_buff xdp;
> >> > + bool consumed;
> >> > +
> >> > + xdp.data = data;
> >> > + xdp.data_end = xdp.data + cqe_bcnt;
> >> > + xdp.data_hard_start = va;
> >> > +
> >> > + consumed = mlx5e_xdp_handle(rq, xdp_prog, di, &xdp);
> >> > +
> >> > + if (consumed) {
> >> > + rcu_read_unlock();
> >> > + return NULL; /* page/packet was consumed by XDP */
> >> > + }
> >> > +
> >> > + rx_headroom = xdp.data - xdp.data_hard_start;
> >> > + cqe_bcnt = xdp.data_end - xdp.data;
> >> > + }
> >>
> >> This whole new logic belongs to mlx5e_xdp_handle, I would like to keep
> >> xdp related code in one place.
> >>
> >> move the xdp_buff initialization back to there and keep the xdp_prog
> >> check in mlx5e_xdp_handle;
> >> + xdp_prog = READ_ONCE(rq->xdp_prog);
> >> + if (!xdp_prog)
> >> + return false
> >>
> >> you can remove "const struct bpf_prog *prog" parameter from
> >> mlx5e_xdp_handle and take it directly from rq.
> >>
> >> if you need va for xdp_buff you can pass it as a paramter to
> >> mlx5e_xdp_handle as well:
> >> mlx5e_xdp_handle(rq, di, va, data, cqe_bcnt);
> >> Make sense ?
> > I moved them because xdp.data could be adjusted which then
> > rx_headroom and cqe_bcnt have to be adjusted accordingly
> > in skb_from_cqe() also.
> >
> > I understand your point. After another quick thought,
> > the adjusted xdp.data is the only one that we want in skb_from_cqe().
> > I will try to make mlx5e_xdp_handle() to return the adjusted xdp.data
> > instead of bool.
> >
>
> hmm, You also need the adjusted cqe_bcnt! this will make
> mlx5e_xdp_handle stuffed with parameters,
>
> what if, in skb_from_cqe we warp data, rx_headroom and cqe_bcnt in one struct.
>
> struct mlx5e_rx_buff {
> void *data;
> u6 headroom;
> u32 bcnt;
> }
>
> initialize it at the start of skb_from_cqe:
>
> struct mlx5e_rx_buff rxb;
>
> rxb.headroom = rq->headroom;
> rxb.data = va + rxb.headroom;
> rxb.bcnt = cqe_bcnt;
>
> pass it to mlx5e_xdp_handle(rq, di, va, &rxb) in case xdp_prog is ON
> and rxb needs adjustment.
>
> At the end use it to build the SKB:
> skb = build_skb(va, RQ_PAGE_SIZE(rq));
> skb_reserve(skb, rxb.headroom);
> skb_put(skb, rxb.bcnt);
How about something like this without introducing a new struct?
-static inline bool mlx5e_xdp_handle(struct mlx5e_rq *rq,
- const struct bpf_prog *prog,
- struct mlx5e_dma_info *di,
- void *data, u16 len)
+static inline int mlx5e_xdp_handle(struct mlx5e_rq *rq,
+ struct mlx5e_dma_info *di,
+ void *va, u16 *rx_headroom, u32 *len)
{
+ const struct bpf_prog *prog = READ_ONCE(rq->xdp_prog);
struct xdp_buff xdp;
u32 act;
if (!prog)
return false;
- xdp.data = data;
- xdp.data_end = xdp.data + len;
+ xdp.data = va + *rx_headroom;
+ xdp.data_end = xdp.data + *len;
+ xdp.data_hard_start = va;
+
act = bpf_prog_run_xdp(prog, &xdp);
switch (act) {
case XDP_PASS:
+ *rx_headroom = xdp.data - xdp.data_hard_start;
+ *len = xdp.data_end - xdp.data;
return false;
case XDP_TX:
- mlx5e_xmit_xdp_frame(rq, di, MLX5_RX_HEADROOM, len);
+ mlx5e_xmit_xdp_frame(rq, di, &xdp);
return true;
default:
bpf_warn_invalid_xdp_action(act);
@@ -740,15 +751,16 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
struct mlx5e_dma_info *di;
struct sk_buff *skb;
void *va, *data;
+ u16 rx_headroom = rq->rx_headroom;
bool consumed;
di = &rq->dma_info[wqe_counter];
va = page_address(di->page);
- data = va + MLX5_RX_HEADROOM;
+ data = va + rx_headroom;
dma_sync_single_range_for_cpu(rq->pdev,
di->addr,
- MLX5_RX_HEADROOM,
+ rx_headroom,
rq->buff.wqe_sz,
DMA_FROM_DEVICE);
prefetch(data);
@@ -760,8 +772,7 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
}
rcu_read_lock();
- consumed = mlx5e_xdp_handle(rq, READ_ONCE(rq->xdp_prog), di, data,
- cqe_bcnt);
+ consumed = mlx5e_xdp_handle(rq, di, va, &rx_headroom, &cqe_bcnt);
rcu_read_unlock();
if (consumed)
return NULL; /* page/packet was consumed by XDP */
@@ -777,7 +788,7 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
page_ref_inc(di->page);
mlx5e_page_release(rq, di, true);
- skb_reserve(skb, MLX5_RX_HEADROOM);
+ skb_reserve(skb, rx_headroom);
skb_put(skb, cqe_bcnt);
return skb;
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Ben Greear @ 2017-01-13 22:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, mikko.rapeli
In-Reply-To: <20170113140806.01f65b8a@xeon-e3>
On 01/13/2017 02:08 PM, Stephen Hemminger wrote:
> On Fri, 13 Jan 2017 11:50:32 -0800
> Ben Greear <greearb@candelatech.com> wrote:
>
>> On 01/13/2017 11:41 AM, Stephen Hemminger wrote:
>>> On Fri, 13 Jan 2017 11:12:32 -0800
>>> Ben Greear <greearb@candelatech.com> wrote:
>>>
>>>> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
>>>> netinet/ip.h.
>>>>
>>>> Maybe my build environment is screwed up, but maybe also it would be better to
>>>> just let the user include appropriate headers before including if_tunnel.h
>>>> and revert this patch?
>>>>
>>>>
>>>> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
>>>>
>>>> Fixes userspace compilation errors like:
>>>>
>>>> error: field ‘iph’ has incomplete type
>>>> error: field ‘prefix’ has incomplete type
>>>>
>>>> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>> What I ended up doing for iproute2 was including all headers used by the source
>>> based on sanitized kernel headers. Basically
>>> $ git grep '^#include <linux/' | \
>>> awk -F: '{print $2}' | \
>>> sed -e 's/^#include <//' -e 's/>.*$//' | \
>>> sort -u >linux.headers
>>> $ for f in $(cat linux.headers)
>>> do cp ~/kernel/net-next/usr/include/$f include/$f
>>> done
>>>
>>> You can't take only some of the headers, once you decide to diverge from glibc provided
>>> headers, you got to take them all.
>>>
>>
>> I do grab a copy of the linux kernel headers and compile against that, but netinet/ip.h is
>> coming from the OS. Do you mean I should not include netinet/ip.h and instead use linux/ip.h?
>
> I don't think you can mix netinet/ip.h and linux/ip.h, yes that is a mess.
>
Well, I still like the idea of reverting this patch..that way user-space does not have to use
linux/ip.h, and that lets them use netinet/ip.h and if_tunnel.h.
Anyway, I'll let Dave and/or the original committer decide....I've reverted it in my local tree
so I am able to build again...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Stephen Hemminger @ 2017-01-13 22:08 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, mikko.rapeli
In-Reply-To: <6c983e7e-dbb3-3542-ffed-95f4d2f3c5bc@candelatech.com>
On Fri, 13 Jan 2017 11:50:32 -0800
Ben Greear <greearb@candelatech.com> wrote:
> On 01/13/2017 11:41 AM, Stephen Hemminger wrote:
> > On Fri, 13 Jan 2017 11:12:32 -0800
> > Ben Greear <greearb@candelatech.com> wrote:
> >
> >> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
> >> netinet/ip.h.
> >>
> >> Maybe my build environment is screwed up, but maybe also it would be better to
> >> just let the user include appropriate headers before including if_tunnel.h
> >> and revert this patch?
> >>
> >>
> >> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
> >>
> >> Fixes userspace compilation errors like:
> >>
> >> error: field ‘iph’ has incomplete type
> >> error: field ‘prefix’ has incomplete type
> >>
> >> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >>
> >> Thanks,
> >> Ben
> >>
> >
> > What I ended up doing for iproute2 was including all headers used by the source
> > based on sanitized kernel headers. Basically
> > $ git grep '^#include <linux/' | \
> > awk -F: '{print $2}' | \
> > sed -e 's/^#include <//' -e 's/>.*$//' | \
> > sort -u >linux.headers
> > $ for f in $(cat linux.headers)
> > do cp ~/kernel/net-next/usr/include/$f include/$f
> > done
> >
> > You can't take only some of the headers, once you decide to diverge from glibc provided
> > headers, you got to take them all.
> >
>
> I do grab a copy of the linux kernel headers and compile against that, but netinet/ip.h is
> coming from the OS. Do you mean I should not include netinet/ip.h and instead use linux/ip.h?
I don't think you can mix netinet/ip.h and linux/ip.h, yes that is a mess.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox