* Re: C45 support and mdiobus_scan
From: Andrew Lunn @ 2018-08-09 15:03 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <3bbd1d78-b896-2a81-83cf-7dad2f73bae9@synopsys.com>
On Thu, Aug 09, 2018 at 02:54:11PM +0100, Jose Abreu wrote:
> Hi All,
>
> I'm preparing to add support for 10G in stmmac and I noticed that
> Generic 10G PHY needs C45 support. Digging through the
> registration callbacks for phy that are used in stmmac I reached
> to mdiobus_scan() and the following call:
>
> phydev = get_phy_device(bus, addr, false);
>
> The last parameter is "is_c45", and is always being set to false ...
>
> Does this mean that I can't use the Generic 10G PHY in stmmac? I
> don't mind link being fixed for 10G for now.
Hi Jose
So far, all MACs which support 10G have used phy-handle to point to a
PHY on am MDIO bus, and that PHY uses .compatible =
"ethernet-phy-ieee802.3-c45". of_mdiobus_register() will then find the
PHY and register it. You really should try to follow this, if you can.
> (Notice I'm using a PCI based setup so no DT bindings can help me
> for this).
That is not necessarily true. Take a look at:
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
status = "okay";
host@0 {
reg = <0 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
i210: i210@0 {
reg = <0 0 0 0 0>;
};
};
};
The PCIe core will look in the device tree and when it creates the
platform device for the i210 on the pcie bus, it points
pdev->dev.of_node at this node. So long as you are using a platform
with DT, you can do this. I hope you are not using x86..
Andrew
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-08-09 15:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180809125637.GC1813@lunn.ch>
Hi,
On Thu, Aug 9, 2018 at 1:56 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Aug 09, 2018 at 01:45:52PM +0100, Lad, Prabhakar wrote:
> > On Thu, Aug 9, 2018 at 1:02 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote:
> > > > Hi Andrew,
> > > >
> > > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > >
> > > > > > I dont see any Reply's on the PC with tcpdump on PC
> > > > >
> > > > > So try ethool -S on the PC. Any packets dropped because of errors?
> > > > >
> > > > I dont see any drops/errors on the PC, following is the dump from PC:
> > > >
> > > > sudo ethtool -S enx00e04c68c229
> > > > [sudo] password for prabhakar:
> > > > NIC statistics:
> > > > tx_packets: 1659
> > > > rx_packets: 485
> > > > tx_errors: 0
> > > > rx_errors: 0
> > > > rx_missed: 0
> > > > align_errors: 0
> > > > tx_single_collisions: 0
> > > > tx_multi_collisions: 0
> > > > rx_unicast: 18
> > > > rx_broadcast: 295
> > > > rx_multicast: 172
> > > > tx_aborted: 0
> > > > tx_underrun: 0
> > >
> > > So there are received packets at the PC. Not many unicast, mostly
> > > broadcast, which fits with ARP. What does wireshark tell you about
> > > these received packets? Are they ARP replies? Are they something else?
> > > If they are ARP replies, why are they being ignored? I don't know if
> > > tshark will show you CRC problems. Wireshark does, when you unfold a
> > > packet, and look at the fields in detail.
> > >
> > > > Seems like the packet is not being transmitted from the switch at all
> > > > ? (as ping from switch lan4 to PC fails)
> > >
> > > I don't think you can make that conclusion yet. The PC is receiving
> > > something, rx_packets=485. What are those packets?
> > >
> > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > are causing the rx
> > packet counter go up:
>
> And where are these packets coming from? The target device? Or some
> other device on your network?
>
AFIK, MDNS is also kind of a bcast its sending MDNS requests and
receiving itself,
that’s the reason rx packets are incrementing (correct me if I am wrong)
On the PC where lan4 is connected , tx has high count because of ping requests
prabhakar@tango-charlie:~/Desktop/test$ ifconfig enx00e04c68c229
enx00e04c68c229 Link encap:Ethernet HWaddr 00:e0:4c:68:c2:29
inet addr:169.254.78.251 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::2f12:3d45:7cca:57fa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:502 errors:0 dropped:0 overruns:0 frame:0
TX packets:4811 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79843 (79.8 KB) TX bytes:252647 (252.6 KB)
> > I don’t see any packets reaching the PC for the ping request. I can see the
> > RX and TX on the switch for lan4 increasing every second. seems like the
> > switch itself is consuming it and not forwarding(but then lan4 TX
> > shouldn’t have incremented ?).
>
> Which lan4 counters are going up? tx_packets, rx_packets, tx_errors,
> rx_errors are software counters, and are incremented by the DSA
> core. Other counters are hardware counters, and the DSA driver will
> read them from the actual switch port. If the hardware counters show
> packets are being transmitted, then the packets are probably on the
> cable.
>
I can see the RX and TX incrementing every second, no errors counters go up
$ watch -n1 ifconfig lan4
lan4 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F
inet addr:169.254.126.126 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::18b9:d16c:7ff:ab73%3201178264/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2168 errors:0 dropped:0 overruns:0 frame:0
TX packets:1724 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:117816 (115.0 KiB) TX bytes:99940 (97.5 KiB)
~$ ethtool -S eth1
NIC statistics:
Good Rx Frames: 800
Broadcast Rx Frames: 729
Multicast Rx Frames: 71
Pause Rx Frames: 0
Rx CRC Errors: 0
Rx Align/Code Errors: 0
Oversize Rx Frames: 0
Rx Jabbers: 0
Undersize (Short) Rx Frames: 0
Rx Fragments: 0
Rx Octets: 65472
Good Tx Frames: 369
Broadcast Tx Frames: 16
Multicast Tx Frames: 139
Pause Tx Frames: 0
Deferred Tx Frames: 0
Collisions: 0
Single Collision Tx Frames: 0
Multiple Collision Tx Frames: 0
Excessive Collisions: 0
Late Collisions: 0
Tx Underrun: 0
Carrier Sense Errors: 0
Tx Octets: 40990
Rx + Tx 64 Octet Frames: 0
Rx + Tx 65-127 Octet Frames: 1031
Rx + Tx 128-255 Octet Frames: 73
Rx + Tx 256-511 Octet Frames: 65
Rx + Tx 512-1023 Octet Frames: 0
Rx + Tx 1024-Up Octet Frames: 0
Net Octets: 106462
Rx Start of Frame Overruns: 0
Rx Middle of Frame Overruns: 0
Rx DMA Overruns: 0
Rx DMA chan 0: head_enqueue: 1
Rx DMA chan 0: tail_enqueue: 918
Rx DMA chan 0: pad_enqueue: 0
Rx DMA chan 0: misqueued: 0
Rx DMA chan 0: desc_alloc_fail: 0
Rx DMA chan 0: pad_alloc_fail: 0
Rx DMA chan 0: runt_receive_buf: 0
Rx DMA chan 0: runt_transmit_bu: 0
Rx DMA chan 0: empty_dequeue: 0
Rx DMA chan 0: busy_dequeue: 772
Rx DMA chan 0: good_dequeue: 791
Rx DMA chan 0: requeue: 0
Rx DMA chan 0: teardown_dequeue: 0
Tx DMA chan 0: head_enqueue: 369
Tx DMA chan 0: tail_enqueue: 0
Tx DMA chan 0: pad_enqueue: 0
Tx DMA chan 0: misqueued: 0
Tx DMA chan 0: desc_alloc_fail: 0
Tx DMA chan 0: pad_alloc_fail: 0
Tx DMA chan 0: runt_receive_buf: 0
Tx DMA chan 0: runt_transmit_bu: 221
Tx DMA chan 0: empty_dequeue: 369
Tx DMA chan 0: busy_dequeue: 0
Tx DMA chan 0: good_dequeue: 369
Tx DMA chan 0: requeue: 0
Tx DMA chan 0: teardown_dequeue: 0
p05_rx_hi: 0
p05_rx_undersize: 0
p05_rx_fragments: 0
p05_rx_oversize: 0
p05_rx_jabbers: 0
p05_rx_symbol_err: 0
p05_rx_crc_err: 0
p05_rx_align_err: 0
p05_rx_mac_ctrl: 0
p05_rx_pause: 0
p05_rx_bcast: 651
p05_rx_mcast: 208
p05_rx_ucast: 214
p05_rx_64_or_less: 593
p05_rx_65_127: 343
p05_rx_128_255: 73
p05_rx_256_511: 64
p05_rx_512_1023: 0
p05_rx_1024_1522: 0
p05_rx_1523_2000: 0
p05_rx_2001: 0
p05_tx_hi: 0
p05_tx_late_col: 0
p05_tx_pause: 0
p05_tx_bcast: 744
p05_tx_mcast: 177
p05_tx_ucast: 0
p05_tx_deferred: 0
p05_tx_total_col: 0
p05_tx_exc_col: 0
p05_tx_single_col: 0
p05_tx_mult_col: 0
p05_rx_total: 99380
p05_tx_total: 86102
p05_rx_discards: 224
p05_tx_discards: 0
~$ ethtool -S lan4
NIC statistics:
tx_packets: 563
tx_bytes: 41522
rx_packets: 1010
rx_bytes: 61155
rx_hi: 0
rx_undersize: 0
rx_fragments: 0
rx_oversize: 0
rx_jabbers: 0
rx_symbol_err: 0
rx_crc_err: 0
rx_align_err: 0
rx_mac_ctrl: 0
rx_pause: 0
rx_bcast: 958
rx_mcast: 222
rx_ucast: 214
rx_64_or_less: 898
rx_65_127: 350
rx_128_255: 80
rx_256_511: 66
rx_512_1023: 0
rx_1024_1522: 0
rx_1523_2000: 0
rx_2001: 0
tx_hi: 0
tx_late_col: 0
tx_pause: 0
tx_bcast: 749
tx_mcast: 212
tx_ucast: 0
tx_deferred: 0
tx_total_col: 0
tx_exc_col: 0
tx_single_col: 0
tx_mult_col: 0
rx_total: 121503
tx_total: 92530
rx_discards: 224
tx_discards: 0
Only weird thing I notice on target, when its replying for ping
requests ( (oui Unknown) is that something which is causing issues ?
08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
Cheers,
--Prabhakar
^ permalink raw reply
* Re: C45 support and mdiobus_scan
From: Jose Abreu @ 2018-08-09 15:07 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180809150309.GA20006@lunn.ch>
Hi Andrew,
Thanks for your answer :)
On 09-08-2018 16:03, Andrew Lunn wrote:
> On Thu, Aug 09, 2018 at 02:54:11PM +0100, Jose Abreu wrote:
>> Hi All,
>>
>> I'm preparing to add support for 10G in stmmac and I noticed that
>> Generic 10G PHY needs C45 support. Digging through the
>> registration callbacks for phy that are used in stmmac I reached
>> to mdiobus_scan() and the following call:
>>
>> phydev = get_phy_device(bus, addr, false);
>>
>> The last parameter is "is_c45", and is always being set to false ...
>>
>> Does this mean that I can't use the Generic 10G PHY in stmmac? I
>> don't mind link being fixed for 10G for now.
> Hi Jose
>
> So far, all MACs which support 10G have used phy-handle to point to a
> PHY on am MDIO bus, and that PHY uses .compatible =
> "ethernet-phy-ieee802.3-c45". of_mdiobus_register() will then find the
> PHY and register it. You really should try to follow this, if you can.
>
>> (Notice I'm using a PCI based setup so no DT bindings can help me
>> for this).
> That is not necessarily true. Take a look at:
>
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>
> &pcie {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pcie>;
> reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
> status = "okay";
>
> host@0 {
> reg = <0 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
>
> i210: i210@0 {
> reg = <0 0 0 0 0>;
> };
> };
> };
>
> The PCIe core will look in the device tree and when it creates the
> platform device for the i210 on the pcie bus, it points
> pdev->dev.of_node at this node. So long as you are using a platform
> with DT, you can do this. I hope you are not using x86..
Yes I am :( Any possible solution for this?
I guess in ultimate case I will have to switch to ARM based setup.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Andrew
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
From: Kalle Valo @ 2018-08-09 15:14 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20180803134224.2609-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> fix spelling mistake in rx stats text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
26b701adc378 iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
--
https://patchwork.kernel.org/patch/10555115/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Andrew Lunn @ 2018-08-09 15:14 UTC (permalink / raw)
To: Anssi Hannula; +Cc: Claudiu Beznea, Nicolas Ferre, David S. Miller, netdev
In-Reply-To: <3c3a606e-b3e1-41fc-fcd8-7b98968fd06b@bitwise.fi>
Hi Anssi
> macb_reset_hw() is called in init path too, though, so maybe clearing
> all bits is intentional / wanted to get the controller to a known state,
> even though the comment only mentions TX/RX?
You need to be careful here. Once of_mdiobus_register() is called, the
MDIO should be usable. If you happen to have an Ethernet switch on the
bus, it could be probed then. The DSA driver will start using the bus.
Or if you have a second PHY, connected to some other MAC, it could be
used by the other MAC. This all happens in the macb_probe function.
Sometime later, the interface will be up'ed. At this point macb_open()
is called, which calls macb_init_hw(), which calls
macb_reset_hw(). What you don't want happening is changes to the NCR
at this point breaking an MDIO transaction which might be going on.
Ideally, the MPE should be enabled before of_mdiobus_register(), and
left alone until mdiobus_unregister() is called in macb_remove().
Andrew
^ permalink raw reply
* [PATCH iproute2/net-next] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Eelco Chaudron @ 2018-08-09 15:16 UTC (permalink / raw)
To: netdev; +Cc: davem, stephen
Add support for showing hardware specific counters to easily
troubleshoot hardware offload.
$ tc -s filter show dev enp3s0np0 parent ffff:
filter protocol ip pref 1 flower chain 0
filter protocol ip pref 1 flower chain 0 handle 0x1
eth_type ipv4
dst_ip 2.0.0.0
src_ip 1.0.0.0
ip_flags nofrag
in_hw
action order 1: mirred (Egress Redirect to device eth1) stolen
index 1 ref 1 bind 1 installed 0 sec used 0 sec
Action statistics:
Sent 534884742 bytes 8915697 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 187542 bytes 4077 pkt
Sent hardware 534697200 bytes 8911620 pkt
backlog 0b 0p requeues 0
cookie 89173e6a44447001becfd486bda17e29
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
include/uapi/linux/gen_stats.h | 1 +
tc/tc_util.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/uapi/linux/gen_stats.h b/include/uapi/linux/gen_stats.h
index 24a861c..065408e 100644
--- a/include/uapi/linux/gen_stats.h
+++ b/include/uapi/linux/gen_stats.h
@@ -12,6 +12,7 @@ enum {
TCA_STATS_APP,
TCA_STATS_RATE_EST64,
TCA_STATS_PAD,
+ TCA_STATS_BASIC_HW,
__TCA_STATS_MAX,
};
#define TCA_STATS_MAX (__TCA_STATS_MAX - 1)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index d757852..43a2013 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -800,6 +800,41 @@ void print_tm(FILE *f, const struct tcf_t *tm)
}
}
+static void print_tcstats_basic_hw(struct rtattr **tbs, char *prefix)
+{
+ struct gnet_stats_basic bs = {0};
+ struct gnet_stats_basic bs_hw = {0};
+
+ if (!tbs[TCA_STATS_BASIC_HW])
+ return;
+
+ memcpy(&bs_hw, RTA_DATA(tbs[TCA_STATS_BASIC_HW]),
+ MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC_HW]), sizeof(bs_hw)));
+
+ if (bs_hw.bytes == 0 && bs_hw.packets == 0)
+ return;
+
+ if (tbs[TCA_STATS_BASIC]) {
+ memcpy(&bs, RTA_DATA(tbs[TCA_STATS_BASIC]),
+ MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC]),
+ sizeof(bs)));
+ }
+
+ if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
+ print_string(PRINT_FP, NULL, "\n%s", prefix);
+ print_lluint(PRINT_ANY, "sw_bytes",
+ "Sent software %llu bytes",
+ bs.bytes - bs_hw.bytes);
+ print_uint(PRINT_ANY, "sw_packets", " %u pkt",
+ bs.packets - bs_hw.packets);
+ }
+
+ print_string(PRINT_FP, NULL, "\n%s", prefix);
+ print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
+ bs_hw.bytes);
+ print_uint(PRINT_ANY, "hw_packets", " %u pkt", bs_hw.packets);
+}
+
void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtattr **xstats)
{
SPRINT_BUF(b1);
@@ -826,6 +861,9 @@ void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtat
print_uint(PRINT_ANY, "requeues", " requeues %u) ", q.requeues);
}
+ if (tbs[TCA_STATS_BASIC_HW])
+ print_tcstats_basic_hw(tbs, prefix);
+
if (tbs[TCA_STATS_RATE_EST64]) {
struct gnet_stats_rate_est64 re = {0};
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix bpffs non-array map seq_show issue
From: Yonghong Song @ 2018-08-09 15:15 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: ast, netdev, kernel-team
In-Reply-To: <c8c3b728-adf7-77d8-70a9-f6c9684e771d@iogearbox.net>
On 8/9/18 7:24 AM, Daniel Borkmann wrote:
> On 08/09/2018 05:55 AM, Yonghong Song wrote:
>> On 8/8/18 7:25 PM, Alexei Starovoitov wrote:
>>> On Wed, Aug 08, 2018 at 06:25:19PM -0700, Yonghong Song wrote:
>>>> In function map_seq_next() of kernel/bpf/inode.c,
>>>> the first key will be the "0" regardless of the map type.
>>>> This works for array. But for hash type, if it happens
>>>> key "0" is in the map, the bpffs map show will miss
>>>> some items if the key "0" is not the first element of
>>>> the first bucket.
>>>>
>>>> This patch fixed the issue by guaranteeing to get
>>>> the first element, if the seq_show is just started,
>>>> by passing NULL pointer key to map_get_next_key() callback.
>>>> This way, no missing elements will occur for
>>>> bpffs hash table show even if key "0" is in the map.
>>
>> Currently, map_seq_show_elem callback is only implemented
>> for arraymap. So the problem actually is not exposed.
>>
>> The issue is discovered when I tried to implement
>> map_seq_show_elem for hash maps, and I will have followup
>> patches for it.
>>
>> So this patch probably should apply to bpf-next or
>> I can include this patch in my later patch set
>> which implements map_seq_show_elem for hash map
>> which can demonstrate the problem.
>>
>> Please let me know.
>>
>>>> Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap")
>>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>>
>>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> Given this doesn't affect any current code, I think bpf-next
> would be fine.
>
> Anyway, this cannot be used as-is, results in following compile
> warning ...
Thanks and will fix the problem and resubmit the patch set to
bpf-next.
>
> # make -j4 kernel/bpf/
> DESCEND objtool
> CALL scripts/checksyscalls.sh
> CC kernel/bpf/verifier.o
> CC kernel/bpf/inode.o
> kernel/bpf/inode.c: In function ‘map_seq_next’:
> kernel/bpf/inode.c:214:1: warning: label ‘done’ defined but not used [-Wunused-label]
> done:
> ^~~~
> AR kernel/bpf/built-in.a
>
^ permalink raw reply
* Re: C45 support and mdiobus_scan
From: Andrew Lunn @ 2018-08-09 15:25 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <568ff5ce-02ac-40f9-ccf7-fa00fb9c6b2a@synopsys.com>
> > The PCIe core will look in the device tree and when it creates the
> > platform device for the i210 on the pcie bus, it points
> > pdev->dev.of_node at this node. So long as you are using a platform
> > with DT, you can do this. I hope you are not using x86..
>
> Yes I am :( Any possible solution for this?
Well, DT can be used with x86. I think Edison did that. But i assume
your PCIe host is in ACPI, not DT. So getting this linking working
will not be easy.
There has been some work to add an ACPI binding for PHYs. I don't know
if it actually got far enough that you can hack your DSDT to add a
PHY. But i'm sure it did not get far enough that you can describe an
MDIO bus in DSDT, so it probably is not going to help you.
> I guess in ultimate case I will have to switch to ARM based setup.
Yes, or MIPS.
Andrew
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Andrew Lunn @ 2018-08-09 15:35 UTC (permalink / raw)
To: Lad, Prabhakar; +Cc: netdev
In-Reply-To: <CA+V-a8sEKfe+vRkxM7EKwH9h3HwLcW_k1Ygso2K3h5jY3TtaiA@mail.gmail.com>
> > > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > > are causing the rx
> > > packet counter go up:
> >
> > And where are these packets coming from? The target device? Or some
> > other device on your network?
> >
> AFIK, MDNS is also kind of a bcast its sending MDNS requests and
> receiving itself,
> that’s the reason rx packets are incrementing (correct me if I am wrong)
Your Ethernet device should not be receiving its own
transmissions. Looping back for broadcast and multicast packets
happens higher up in the network stack.
Look at the source MAC address for these packets. Where are the coming
from?
> ~$ ethtool -S lan4
> NIC statistics:
...
> tx_hi: 0
> tx_late_col: 0
> tx_pause: 0
> tx_bcast: 749
> tx_mcast: 212
This suggest the switch is putting packets onto the wire.
> Only weird thing I notice on target, when its replying for ping
> requests ( (oui Unknown) is that something which is causing issues ?
These are not ping requests. These are ARP requests/replies.
> 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
c4:f3:12 is the OUI. It is actually registers to TI:
https://aruljohn.com/mac/C4F312
But tcpdump probably does not know this, or the build you have has the
oui table removed to keep the binary small.
Andrew
^ permalink raw reply
* Re: [net-next, PATCH 1/2] net: socionext: Use descriptor info instead of MMIO reads on Rx
From: Arnd Bergmann @ 2018-08-09 15:37 UTC (permalink / raw)
To: Ilias Apalodimas; +Cc: Networking, Jassi Brar
In-Reply-To: <1533801739-15312-1-git-send-email-ilias.apalodimas@linaro.org>
On Thu, Aug 9, 2018 at 10:02 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> MMIO reads for remaining packets in queue occur (at least)twice per
> invocation of netsec_process_rx(). We can use the packet descriptor to
> identify if it's owned by the hardware and break out, avoiding the more
> expensive MMIO read operations. This has a ~2% increase on the pps of the
> Rx path when tested with 64byte packets
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
> drivers/net/ethernet/socionext/netsec.c | 19 +++++--------------
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> index 01589b6..ae32909 100644
> --- a/drivers/net/ethernet/socionext/netsec.c
> +++ b/drivers/net/ethernet/socionext/netsec.c
> @@ -657,8 +657,6 @@ static struct sk_buff *netsec_get_rx_pkt_data(struct netsec_priv *priv,
> + if (de->attr & (1U << NETSEC_RX_PKT_OWN_FIELD))
> + break;
> done++;
Should this use READ_ONCE() to prevent the compiler from moving the
access around? I see that netsec_get_rx_pkt_data() has a dma_rmb()
before reading the data, which prevents the CPU from doing something
wrong here, but not the compiler.
Arnd
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Andy Lutomirski @ 2018-08-09 18:08 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Ingo Molnar, Thomas Gleixner, linux-arch, Eric Biggers,
Linux Crypto Mailing List, LKML, Netdev, David Miller,
Andrew Lutomirski, Greg Kroah-Hartman, Samuel Neves,
Daniel J . Bernstein, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <CAHmME9rG8VFfuuCy=rCVmxb1CdneYGv1d4xmsyqSPooBozoOJw@mail.gmail.com>
On Tue, Aug 7, 2018 at 6:51 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Tue, Aug 7, 2018 at 6:49 PM Andy Lutomirski <luto@amacapital.net> wrote:
>> I really wish we had a way to see that we use asm-generic’s copy of a header in all cases except where an arch opts out.
>
> It's really not that hard to do -- symlink asm-generic to a target
> called "asm" inside an otherwise empty directory, and add that
> otherwise empty directory to the -I paths just after arch/include.
> Since it's searched second, it's only used if the first fails. Maybe
> I'm missing something though, as this seems a bit too obvious. Perhaps
> a project for another day.
The problem here (I think) is that it's preferable for stray files in
the kernel tree to have no effect and, with this scheme, stray files
in arch/*/include/asm could affect the build. So something explicit
has an advantage. I just think there should be way to say "this
asm-generic file should affect all arches unless they generic-n or
override-generic-y it or whatever".
^ permalink raw reply
* [PATCH bpf-next 2/3] bpf: btf: add pretty print for hash/lru_hash maps
From: Yonghong Song @ 2018-08-09 15:55 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180809155521.1544888-1-yhs@fb.com>
Commit a26ca7c982cb ("bpf: btf: Add pretty print support to
the basic arraymap") added pretty print support to array map.
This patch adds pretty print for hash and lru_hash maps.
The following example shows the pretty-print result of
a pinned hashmap:
struct map_value {
int count_a;
int count_b;
};
cat /sys/fs/bpf/pinned_hash_map:
87907: {87907,87908}
57354: {37354,57355}
76625: {76625,76626}
...
Signed-off-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/hashtab.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 513d9dfcf4ee..d6110042e0d9 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -11,9 +11,11 @@
* General Public License for more details.
*/
#include <linux/bpf.h>
+#include <linux/btf.h>
#include <linux/jhash.h>
#include <linux/filter.h>
#include <linux/rculist_nulls.h>
+#include <uapi/linux/btf.h>
#include "percpu_freelist.h"
#include "bpf_lru_list.h"
#include "map_in_map.h"
@@ -1162,6 +1164,44 @@ static void htab_map_free(struct bpf_map *map)
kfree(htab);
}
+static void htab_map_seq_show_elem(struct bpf_map *map, void *key,
+ struct seq_file *m)
+{
+ void *value;
+
+ rcu_read_lock();
+
+ value = htab_map_lookup_elem(map, key);
+ if (!value) {
+ rcu_read_unlock();
+ return;
+ }
+
+ btf_type_seq_show(map->btf, map->btf_key_type_id, key, m);
+ seq_puts(m, ": ");
+ btf_type_seq_show(map->btf, map->btf_value_type_id, value, m);
+ seq_puts(m, "\n");
+
+ rcu_read_unlock();
+}
+
+static int htab_map_check_btf(const struct bpf_map *map, const struct btf *btf,
+ u32 btf_key_id, u32 btf_value_id)
+{
+ const struct btf_type *key_type, *value_type;
+ u32 key_size, value_size;
+
+ key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
+ if (!key_type || key_size != map->key_size)
+ return -EINVAL;
+
+ value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
+ if (!value_type || value_size != map->value_size)
+ return -EINVAL;
+
+ return 0;
+}
+
const struct bpf_map_ops htab_map_ops = {
.map_alloc_check = htab_map_alloc_check,
.map_alloc = htab_map_alloc,
@@ -1171,6 +1211,8 @@ const struct bpf_map_ops htab_map_ops = {
.map_update_elem = htab_map_update_elem,
.map_delete_elem = htab_map_delete_elem,
.map_gen_lookup = htab_map_gen_lookup,
+ .map_seq_show_elem = htab_map_seq_show_elem,
+ .map_check_btf = htab_map_check_btf,
};
const struct bpf_map_ops htab_lru_map_ops = {
@@ -1182,6 +1224,8 @@ const struct bpf_map_ops htab_lru_map_ops = {
.map_update_elem = htab_lru_map_update_elem,
.map_delete_elem = htab_lru_map_delete_elem,
.map_gen_lookup = htab_lru_map_gen_lookup,
+ .map_seq_show_elem = htab_map_seq_show_elem,
+ .map_check_btf = htab_map_check_btf,
};
/* Called from eBPF program */
--
2.14.3
^ permalink raw reply related
* [PATCH bpf-next 0/3] bpf: add bpffs pretty print for hash/lru_hash maps
From: Yonghong Song @ 2018-08-09 15:55 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
Commit a26ca7c982cb ("bpf: btf: Add pretty print support to
the basic arraymap") added pretty print support to array map.
This patch adds pretty print for hash and lru_hash maps.
The following example shows the pretty-print result of a pinned hashmap.
Without this patch set, user will get an error instead.
struct map_value {
int count_a;
int count_b;
};
cat /sys/fs/bpf/pinned_hash_map:
87907: {87907,87908}
57354: {37354,57355}
76625: {76625,76626}
...
Patch #1 fixed a bug in bpffs map_seq_next() function so that
all elements in the hash table will be traversed.
Patch #2 implemented map_seq_show_elem() and map_check_btf()
callback functions for hash and lru hash maps.
Patch #3 enhanced tools/testing/selftests/bpf/test_btf.c to
test bpffs hash and lru hash map pretty print.
Yonghong Song (3):
bpf: fix bpffs non-array map seq_show issue
bpf: btf: add pretty print for hash/lru_hash maps
tools/bpf: add bpffs pretty print btf test for hash/lru_hash maps
kernel/bpf/hashtab.c | 44 +++++++++++++++++
kernel/bpf/inode.c | 8 ++--
tools/testing/selftests/bpf/test_btf.c | 87 ++++++++++++++++++++++++++++------
3 files changed, 121 insertions(+), 18 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH bpf-next 3/3] tools/bpf: add bpffs pretty print btf test for hash/lru_hash maps
From: Yonghong Song @ 2018-08-09 15:55 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180809155521.1544888-1-yhs@fb.com>
Pretty print tests for hash/lru_hash maps are added in test_btf.c.
The btf type blob is the same as pretty print array map test.
The test result:
$ mount -t bpf bpf /sys/fs/bpf
$ ./test_btf -p
BTF pretty print array......OK
BTF pretty print hash......OK
BTF pretty print lru hash......OK
PASS:3 SKIP:0 FAIL:0
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/testing/selftests/bpf/test_btf.c | 87 ++++++++++++++++++++++++++++------
1 file changed, 72 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_btf.c b/tools/testing/selftests/bpf/test_btf.c
index ffdd27737c9e..7fa8c800c540 100644
--- a/tools/testing/selftests/bpf/test_btf.c
+++ b/tools/testing/selftests/bpf/test_btf.c
@@ -131,6 +131,8 @@ struct btf_raw_test {
__u32 max_entries;
bool btf_load_err;
bool map_create_err;
+ bool ordered_map;
+ bool lossless_map;
int hdr_len_delta;
int type_off_delta;
int str_off_delta;
@@ -2093,8 +2095,7 @@ struct pprint_mapv {
} aenum;
};
-static struct btf_raw_test pprint_test = {
- .descr = "BTF pretty print test #1",
+static struct btf_raw_test pprint_test_template = {
.raw_types = {
/* unsighed char */ /* [1] */
BTF_TYPE_INT_ENC(NAME_TBD, 0, 0, 8, 1),
@@ -2146,8 +2147,6 @@ static struct btf_raw_test pprint_test = {
},
.str_sec = "\0unsigned char\0unsigned short\0unsigned int\0int\0unsigned long long\0uint8_t\0uint16_t\0uint32_t\0int32_t\0uint64_t\0ui64\0ui8a\0ENUM_ZERO\0ENUM_ONE\0ENUM_TWO\0ENUM_THREE\0pprint_mapv\0ui32\0ui16\0si32\0unused_bits2a\0bits28\0unused_bits2b\0aenum",
.str_sec_size = sizeof("\0unsigned char\0unsigned short\0unsigned int\0int\0unsigned long long\0uint8_t\0uint16_t\0uint32_t\0int32_t\0uint64_t\0ui64\0ui8a\0ENUM_ZERO\0ENUM_ONE\0ENUM_TWO\0ENUM_THREE\0pprint_mapv\0ui32\0ui16\0si32\0unused_bits2a\0bits28\0unused_bits2b\0aenum"),
- .map_type = BPF_MAP_TYPE_ARRAY,
- .map_name = "pprint_test",
.key_size = sizeof(unsigned int),
.value_size = sizeof(struct pprint_mapv),
.key_type_id = 3, /* unsigned int */
@@ -2155,6 +2154,40 @@ static struct btf_raw_test pprint_test = {
.max_entries = 128 * 1024,
};
+static struct btf_pprint_test_meta {
+ const char *descr;
+ enum bpf_map_type map_type;
+ const char *map_name;
+ bool ordered_map;
+ bool lossless_map;
+} pprint_tests_meta[] = {
+{
+ .descr = "BTF pretty print array",
+ .map_type = BPF_MAP_TYPE_ARRAY,
+ .map_name = "pprint_test_array",
+ .ordered_map = true,
+ .lossless_map = true,
+},
+
+{
+ .descr = "BTF pretty print hash",
+ .map_type = BPF_MAP_TYPE_HASH,
+ .map_name = "pprint_test_hash",
+ .ordered_map = false,
+ .lossless_map = true,
+},
+
+{
+ .descr = "BTF pretty print lru hash",
+ .map_type = BPF_MAP_TYPE_LRU_HASH,
+ .map_name = "pprint_test_lru_hash",
+ .ordered_map = false,
+ .lossless_map = false,
+},
+
+};
+
+
static void set_pprint_mapv(struct pprint_mapv *v, uint32_t i)
{
v->ui32 = i;
@@ -2166,10 +2199,12 @@ static void set_pprint_mapv(struct pprint_mapv *v, uint32_t i)
v->aenum = i & 0x03;
}
-static int test_pprint(void)
+static int do_test_pprint(void)
{
- const struct btf_raw_test *test = &pprint_test;
+ const struct btf_raw_test *test = &pprint_test_template;
struct bpf_create_map_attr create_attr = {};
+ unsigned int key, nr_read_elems;
+ bool ordered_map, lossless_map;
int map_fd = -1, btf_fd = -1;
struct pprint_mapv mapv = {};
unsigned int raw_btf_size;
@@ -2178,7 +2213,6 @@ static int test_pprint(void)
char pin_path[255];
size_t line_len = 0;
char *line = NULL;
- unsigned int key;
uint8_t *raw_btf;
ssize_t nread;
int err, ret;
@@ -2251,14 +2285,18 @@ static int test_pprint(void)
goto done;
}
- key = 0;
+ nr_read_elems = 0;
+ ordered_map = test->ordered_map;
+ lossless_map = test->lossless_map;
do {
ssize_t nexpected_line;
+ unsigned int next_key;
- set_pprint_mapv(&mapv, key);
+ next_key = ordered_map ? nr_read_elems : atoi(line);
+ set_pprint_mapv(&mapv, next_key);
nexpected_line = snprintf(expected_line, sizeof(expected_line),
"%u: {%u,0,%d,0x%x,0x%x,0x%x,{%lu|[%u,%u,%u,%u,%u,%u,%u,%u]},%s}\n",
- key,
+ next_key,
mapv.ui32, mapv.si32,
mapv.unused_bits2a, mapv.bits28, mapv.unused_bits2b,
mapv.ui64,
@@ -2281,11 +2319,12 @@ static int test_pprint(void)
}
nread = getline(&line, &line_len, pin_file);
- } while (++key < test->max_entries && nread > 0);
+ } while (++nr_read_elems < test->max_entries && nread > 0);
- if (CHECK(key < test->max_entries,
- "Unexpected EOF. key:%u test->max_entries:%u",
- key, test->max_entries)) {
+ if (lossless_map &&
+ CHECK(nr_read_elems < test->max_entries,
+ "Unexpected EOF. nr_read_elems:%u test->max_entries:%u",
+ nr_read_elems, test->max_entries)) {
err = -1;
goto done;
}
@@ -2314,6 +2353,24 @@ static int test_pprint(void)
return err;
}
+static int test_pprint(void)
+{
+ unsigned int i;
+ int err = 0;
+
+ for (i = 0; i < ARRAY_SIZE(pprint_tests_meta); i++) {
+ pprint_test_template.descr = pprint_tests_meta[i].descr;
+ pprint_test_template.map_type = pprint_tests_meta[i].map_type;
+ pprint_test_template.map_name = pprint_tests_meta[i].map_name;
+ pprint_test_template.ordered_map = pprint_tests_meta[i].ordered_map;
+ pprint_test_template.lossless_map = pprint_tests_meta[i].lossless_map;
+
+ err |= count_result(do_test_pprint());
+ }
+
+ return err;
+}
+
static void usage(const char *cmd)
{
fprintf(stderr, "Usage: %s [-l] [[-r test_num (1 - %zu)] | [-g test_num (1 - %zu)] | [-f test_num (1 - %zu)] | [-p]]\n",
@@ -2409,7 +2466,7 @@ int main(int argc, char **argv)
err |= test_file();
if (args.pprint_test)
- err |= count_result(test_pprint());
+ err |= test_pprint();
if (args.raw_test || args.get_info_test || args.file_test ||
args.pprint_test)
--
2.14.3
^ permalink raw reply related
* [PATCH bpf-next 1/3] bpf: fix bpffs non-array map seq_show issue
From: Yonghong Song @ 2018-08-09 15:55 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180809155521.1544888-1-yhs@fb.com>
In function map_seq_next() of kernel/bpf/inode.c,
the first key will be the "0" regardless of the map type.
This works for array. But for hash type, if it happens
key "0" is in the map, the bpffs map show will miss
some items if the key "0" is not the first element of
the first bucket.
This patch fixed the issue by guaranteeing to get
the first element, if the seq_show is just started,
by passing NULL pointer key to map_get_next_key() callback.
This way, no missing elements will occur for
bpffs hash table show even if key "0" is in the map.
Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap")
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/inode.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index 76efe9a183f5..fc5b103512e7 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -196,19 +196,21 @@ static void *map_seq_next(struct seq_file *m, void *v, loff_t *pos)
{
struct bpf_map *map = seq_file_to_map(m);
void *key = map_iter(m)->key;
+ void *prev_key;
if (map_iter(m)->done)
return NULL;
if (unlikely(v == SEQ_START_TOKEN))
- goto done;
+ prev_key = NULL;
+ else
+ prev_key = key;
- if (map->ops->map_get_next_key(map, key, key)) {
+ if (map->ops->map_get_next_key(map, prev_key, key)) {
map_iter(m)->done = true;
return NULL;
}
-done:
++(*pos);
return key;
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix bpffs non-array map seq_show issue
From: Daniel Borkmann @ 2018-08-09 15:59 UTC (permalink / raw)
To: Yonghong Song, Alexei Starovoitov
Cc: ast, netdev, kernel-team, jakub.kicinski
In-Reply-To: <e984a0f6-16f4-73f3-70bb-177e787529a4@fb.com>
On 08/09/2018 05:15 PM, Yonghong Song wrote:
> On 8/9/18 7:24 AM, Daniel Borkmann wrote:
>> On 08/09/2018 05:55 AM, Yonghong Song wrote:
>>> On 8/8/18 7:25 PM, Alexei Starovoitov wrote:
>>>> On Wed, Aug 08, 2018 at 06:25:19PM -0700, Yonghong Song wrote:
>>>>> In function map_seq_next() of kernel/bpf/inode.c,
>>>>> the first key will be the "0" regardless of the map type.
>>>>> This works for array. But for hash type, if it happens
>>>>> key "0" is in the map, the bpffs map show will miss
>>>>> some items if the key "0" is not the first element of
>>>>> the first bucket.
>>>>>
>>>>> This patch fixed the issue by guaranteeing to get
>>>>> the first element, if the seq_show is just started,
>>>>> by passing NULL pointer key to map_get_next_key() callback.
>>>>> This way, no missing elements will occur for
>>>>> bpffs hash table show even if key "0" is in the map.
>>>
>>> Currently, map_seq_show_elem callback is only implemented
>>> for arraymap. So the problem actually is not exposed.
>>>
>>> The issue is discovered when I tried to implement
>>> map_seq_show_elem for hash maps, and I will have followup
>>> patches for it.
Btw, on that note, I would also prefer if we could decouple
BTF from the map_seq_show_elem() as there is really no reason
to have it on a per-map. I had a patch below which would enable
it for all map types generically, and bpftool works out of the
box for it. Also, array doesn't really have to be 'int' type
enforced as long as it's some data structure with 4 bytes, it's
all fine, so this can be made fully generic (we only eventually
care about the match in size).
>From 0a8be27cbc2ac0c6fc2632865b5afe37222a1fc7 Mon Sep 17 00:00:00 2001
Message-Id: <0a8be27cbc2ac0c6fc2632865b5afe37222a1fc7.1533830053.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 9 Aug 2018 16:50:21 +0200
Subject: [PATCH bpf-next] bpf, btf: enable for all maps
# bpftool m dump id 19
[{
"key": {
"": {
"vip": 0,
"vipv6": []
},
"port": 0,
"family": 0,
"proto": 0
},
"value": {
"flags": 0,
"vip_num": 0
}
}
]
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/bpf.h | 4 +---
kernel/bpf/arraymap.c | 27 ---------------------------
kernel/bpf/inode.c | 3 ++-
kernel/bpf/syscall.c | 24 ++++++++++++++++++++----
4 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cd8790d..91aa4be 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -48,8 +48,6 @@ struct bpf_map_ops {
u32 (*map_fd_sys_lookup_elem)(void *ptr);
void (*map_seq_show_elem)(struct bpf_map *map, void *key,
struct seq_file *m);
- int (*map_check_btf)(const struct bpf_map *map, const struct btf *btf,
- u32 key_type_id, u32 value_type_id);
};
struct bpf_map {
@@ -118,7 +116,7 @@ static inline bool bpf_map_offload_neutral(const struct bpf_map *map)
static inline bool bpf_map_support_seq_show(const struct bpf_map *map)
{
- return map->ops->map_seq_show_elem && map->ops->map_check_btf;
+ return map->ops->map_seq_show_elem;
}
extern const struct bpf_map_ops bpf_map_offload_ops;
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 2aa55d030..67f0bdf 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -358,32 +358,6 @@ static void array_map_seq_show_elem(struct bpf_map *map, void *key,
rcu_read_unlock();
}
-static int array_map_check_btf(const struct bpf_map *map, const struct btf *btf,
- u32 btf_key_id, u32 btf_value_id)
-{
- const struct btf_type *key_type, *value_type;
- u32 key_size, value_size;
- u32 int_data;
-
- key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
- if (!key_type || BTF_INFO_KIND(key_type->info) != BTF_KIND_INT)
- return -EINVAL;
-
- int_data = *(u32 *)(key_type + 1);
- /* bpf array can only take a u32 key. This check makes
- * sure that the btf matches the attr used during map_create.
- */
- if (BTF_INT_BITS(int_data) != 32 || key_size != 4 ||
- BTF_INT_OFFSET(int_data))
- return -EINVAL;
-
- value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
- if (!value_type || value_size != map->value_size)
- return -EINVAL;
-
- return 0;
-}
-
const struct bpf_map_ops array_map_ops = {
.map_alloc_check = array_map_alloc_check,
.map_alloc = array_map_alloc,
@@ -394,7 +368,6 @@ const struct bpf_map_ops array_map_ops = {
.map_delete_elem = array_map_delete_elem,
.map_gen_lookup = array_map_gen_lookup,
.map_seq_show_elem = array_map_seq_show_elem,
- .map_check_btf = array_map_check_btf,
};
const struct bpf_map_ops percpu_array_map_ops = {
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index 76efe9a..400f27d 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -332,7 +332,8 @@ static int bpf_mkmap(struct dentry *dentry, umode_t mode, void *arg)
struct bpf_map *map = arg;
return bpf_mkobj_ops(dentry, mode, arg, &bpf_map_iops,
- map->btf ? &bpffs_map_fops : &bpffs_obj_fops);
+ bpf_map_support_seq_show(map) ?
+ &bpffs_map_fops : &bpffs_obj_fops);
}
static struct dentry *
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5af4e9e..0b6f6e8 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -455,6 +455,23 @@ static int bpf_obj_name_cpy(char *dst, const char *src)
return 0;
}
+static int map_check_btf(const struct bpf_map *map, const struct btf *btf,
+ u32 btf_key_id, u32 btf_value_id)
+{
+ const struct btf_type *key_type, *value_type;
+ u32 key_size, value_size;
+
+ key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
+ if (!key_type || key_size != map->key_size)
+ return -EINVAL;
+
+ value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
+ if (!value_type || value_size != map->value_size)
+ return -EINVAL;
+
+ return 0;
+}
+
#define BPF_MAP_CREATE_LAST_FIELD btf_value_type_id
/* called via syscall */
static int map_create(union bpf_attr *attr)
@@ -489,8 +506,7 @@ static int map_create(union bpf_attr *attr)
atomic_set(&map->refcnt, 1);
atomic_set(&map->usercnt, 1);
- if (bpf_map_support_seq_show(map) &&
- (attr->btf_key_type_id || attr->btf_value_type_id)) {
+ if (attr->btf_key_type_id || attr->btf_value_type_id) {
struct btf *btf;
if (!attr->btf_key_type_id || !attr->btf_value_type_id) {
@@ -504,8 +520,8 @@ static int map_create(union bpf_attr *attr)
goto free_map_nouncharge;
}
- err = map->ops->map_check_btf(map, btf, attr->btf_key_type_id,
- attr->btf_value_type_id);
+ err = map_check_btf(map, btf, attr->btf_key_type_id,
+ attr->btf_value_type_id);
if (err) {
btf_put(btf);
goto free_map_nouncharge;
--
2.9.5
^ permalink raw reply related
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-08-09 16:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180809153543.GD20006@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
Hi Andrew,
Thanks for your support.
On Thu, Aug 9, 2018 at 4:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > > > are causing the rx
> > > > packet counter go up:
> > >
> > > And where are these packets coming from? The target device? Or some
> > > other device on your network?
> > >
> > AFIK, MDNS is also kind of a bcast its sending MDNS requests and
> > receiving itself,
> > that’s the reason rx packets are incrementing (correct me if I am wrong)
>
> Your Ethernet device should not be receiving its own
> transmissions. Looping back for broadcast and multicast packets
> happens higher up in the network stack.
>
> Look at the source MAC address for these packets. Where are the coming
> from?
>
Its coming from the switch lan4 I have attached the png, where
C4:F3:12:08:FE:7F is
the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is
causing rx counter on
PC to go up.
> > ~$ ethtool -S lan4
> > NIC statistics:
> ...
> > tx_hi: 0
> > tx_late_col: 0
> > tx_pause: 0
> > tx_bcast: 749
> > tx_mcast: 212
>
> This suggest the switch is putting packets onto the wire.
>
> > Only weird thing I notice on target, when its replying for ping
> > requests ( (oui Unknown) is that something which is causing issues ?
>
> These are not ping requests. These are ARP requests/replies.
>
Yes my bad.
> > 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > VB4-SN00000000 tell tango-charlie.local, length 46
> > 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> > 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > VB4-SN00000000 tell tango-charlie.local, length 46
> > 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> > 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > VB4-SN00000000 tell tango-charlie.local, length 46
> > 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
>
> c4:f3:12 is the OUI. It is actually registers to TI:
>
> https://aruljohn.com/mac/C4F312
>
> But tcpdump probably does not know this, or the build you have has the
> oui table removed to keep the binary small.
>
Yes I built it on yocto, probably to reduce they have small build.
Cheers,
--Prabhakar
[-- Attachment #2: frame.png --]
[-- Type: image/png, Size: 1281475 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next] BPF: helpers: New helper to obtain namespace data from current task
From: Carlos Neira @ 2018-08-09 16:07 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Carlos Neira, netdev, ebiederm, quentin.monnet, ys114321
In-Reply-To: <20180809154653.40396ce3@redhat.com>
Jesper,
Here is the updated patch.
>From 92633f6819423093932e8d04aa3dc99a5913f6fd Mon Sep 17 00:00:00 2001
From: Carlos Neira <cneirabustos@gmail.com>
Date: Thu, 9 Aug 2018 09:55:32 -0400
Subject: [PATCH bpf-next] BPF: helpers: New helper to obtain namespace
data from current task
This helper obtains the active namespace from current and returns pid, tgid,
device and namespace id as seen from that namespace, allowing to instrument
a process inside a container.
Device is read from /proc/self/ns/pid, as in the future it's possible that
different pid_ns files may belong to different devices, according
to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
conference.
Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
scripts but this helper returns the pid as seen by the root namespace which is
fine when a bcc script is not executed inside a container.
When the process of interest is inside a container, pid filtering will not work
if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
returning the pid as it's seen by the current namespace where the script is
executing.
This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
used to do pid filtering even inside a container.
For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):
u32 pid = bpf_get_current_pid_tgid() >> 32;
if (pid != <pid_arg_passed_in>)
return 0;
Could be modified to use bpf_get_current_pidns_info() as follows:
struct bpf_pidns pidns;
bpf_get_current_pidns_info(&pidns, sizeof(struct bpf_pidns));
u32 pid = pidns.tgid;
u32 nsid = pidns.nsid;
if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
return 0;
To find out the name PID namespace id of a process, you could use this command:
$ ps -h -o pidns -p <pid_of_interest>
Or this other command:
$ ls -Li /proc/<pid_of_interest>/ns/pid
Signed-off-by: Carlos Antonio Neira Bustos <cneirabustos@gmail.com>
---
include/linux/bpf.h | 1 +
include/uapi/linux/bpf.h | 24 +++++++++++-
kernel/bpf/core.c | 1 +
kernel/bpf/helpers.c | 64 +++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 2 +
samples/bpf/Makefile | 3 ++
samples/bpf/trace_ns_info_user.c | 35 +++++++++++++++++
samples/bpf/trace_ns_info_user_kern.c | 45 ++++++++++++++++++++++
tools/include/uapi/linux/bpf.h | 24 +++++++++++-
tools/testing/selftests/bpf/bpf_helpers.h | 3 ++
10 files changed, 200 insertions(+), 2 deletions(-)
create mode 100644 samples/bpf/trace_ns_info_user.c
create mode 100644 samples/bpf/trace_ns_info_user_kern.c
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cd8790d2c6ed..3f4b999f7c99 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -787,6 +787,7 @@ extern const struct bpf_func_proto bpf_get_stack_proto;
extern const struct bpf_func_proto bpf_sock_map_update_proto;
extern const struct bpf_func_proto bpf_sock_hash_update_proto;
extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
+extern const struct bpf_func_proto bpf_get_current_pidns_info_proto;
extern const struct bpf_func_proto bpf_get_local_storage_proto;
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index dd5758dc35d3..8462f9881465 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2113,6 +2113,18 @@ union bpf_attr {
* the shared data.
* Return
* Pointer to the local storage area.
+ *
+ * int bpf_get_current_pidns_info(struct bpf_pidns_info *pidns, u32 size_of_pidns)
+ * Description
+ * Copies into *pidns* pid, namespace id and tgid as seen by the
+ * current namespace and also device from /proc/self/ns/pid.
+ * *size_of_pidns* must be the size of *pidns*
+ *
+ * This helper is used when pid filtering is needed inside a
+ * container as bpf_get_current_tgid() helper returns always the
+ * pid id as seen by the root namespace.
+ * Return
+ * 0 on success -EINVAL on error.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -2196,7 +2208,8 @@ union bpf_attr {
FN(rc_keydown), \
FN(skb_cgroup_id), \
FN(get_current_cgroup_id), \
- FN(get_local_storage),
+ FN(get_local_storage), \
+ FN(get_current_pidns_info),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
@@ -2724,4 +2737,13 @@ enum bpf_task_fd_type {
BPF_FD_TYPE_URETPROBE, /* filename + offset */
};
+/* helper bpf_get_current_pidns_info will store the following
+ * data, dev will contain major/minor from /proc/self/ns/pid.
+ */
+struct bpf_pidns_info {
+ __u32 dev;
+ __u32 nsid;
+ __u32 tgid;
+ __u32 pid;
+};
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 4d09e610777f..98ce53ce2ea6 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1796,6 +1796,7 @@ const struct bpf_func_proto bpf_sock_map_update_proto __weak;
const struct bpf_func_proto bpf_sock_hash_update_proto __weak;
const struct bpf_func_proto bpf_get_current_cgroup_id_proto __weak;
const struct bpf_func_proto bpf_get_local_storage_proto __weak;
+const struct bpf_func_proto bpf_get_current_pidns_info __weak;
const struct bpf_func_proto * __weak bpf_get_trace_printk_proto(void)
{
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 1991466b8327..d06d723b9cff 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -18,6 +18,9 @@
#include <linux/sched.h>
#include <linux/uidgid.h>
#include <linux/filter.h>
+#include <linux/pid_namespace.h>
+#include <linux/major.h>
+#include <linux/stat.h>
/* If kernel subsystem is allowing eBPF programs to call this function,
* inside its own verifier_ops->get_func_proto() callback it should return
@@ -214,3 +217,64 @@ const struct bpf_func_proto bpf_get_local_storage_proto = {
.arg2_type = ARG_ANYTHING,
};
#endif
+
+BPF_CALL_2(bpf_get_current_pidns_info, struct bpf_pidns_info *, pidns_info, u32,
+ size)
+{
+ const char *ppath = "/proc/self/ns/pid";
+ struct pid_namespace *pidns = NULL;
+ mm_segment_t oldsegfs;
+ struct kstat stat;
+ pid_t tgid = 0;
+ pid_t pid = 0;
+ int res = 0;
+
+ if (unlikely(size != sizeof(struct bpf_pidns_info)))
+ goto clear;
+
+ pidns = task_active_pid_ns(current);
+
+ if (unlikely(!pidns))
+ goto clear;
+
+ pidns_info->nsid = pidns->ns.inum;
+ pid = task_pid_nr_ns(current, pidns);
+
+ if (unlikely(!pid))
+ goto clear;
+
+ tgid = task_tgid_nr_ns(current, pidns);
+
+ if (unlikely(!tgid))
+ goto clear;
+
+ pidns_info->tgid = (u32) tgid;
+ pidns_info->pid = (u32) pid;
+
+ oldsegfs = get_fs();
+ set_fs(KERNEL_DS);
+ res = vfs_stat((const char __user *)ppath, &stat);
+ set_fs(oldsegfs);
+
+ if (unlikely(res))
+ goto clear;
+
+ pidns_info->dev = stat.dev;
+
+ return 0;
+
+clear:
+ if (pidns_info)
+ memset((void *)pidns, 0, (size_t) size);
+
+ return -EINVAL;
+}
+
+const struct bpf_func_proto bpf_get_current_pidns_info_proto = {
+ .func = bpf_get_current_pidns_info,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_UNINIT_MEM,
+ .arg2_type = ARG_CONST_SIZE,
+};
+
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 0ae6829804bc..f70be29e49ab 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -568,6 +568,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
case BPF_FUNC_get_current_cgroup_id:
return &bpf_get_current_cgroup_id_proto;
#endif
+ case BPF_FUNC_get_current_pidns_info:
+ return &bpf_get_current_pidns_info_proto;
default:
return NULL;
}
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index f88d5683d6ee..fdcde00554ce 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -53,6 +53,7 @@ hostprogs-y += xdpsock
hostprogs-y += xdp_fwd
hostprogs-y += task_fd_query
hostprogs-y += xdp_sample_pkts
+hostprogs-y += trace_ns_info
# Libbpf dependencies
LIBBPF = $(TOOLS_PATH)/lib/bpf/libbpf.a
@@ -109,6 +110,7 @@ xdpsock-objs := xdpsock_user.o
xdp_fwd-objs := xdp_fwd_user.o
task_fd_query-objs := bpf_load.o task_fd_query_user.o $(TRACE_HELPERS)
xdp_sample_pkts-objs := xdp_sample_pkts_user.o $(TRACE_HELPERS)
+trace_ns_info-objs := bpf_load.o trace_ns_info_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -166,6 +168,7 @@ always += xdpsock_kern.o
always += xdp_fwd_kern.o
always += task_fd_query_kern.o
always += xdp_sample_pkts_kern.o
+always += trace_ns_info_user_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS += -I$(srctree)/tools/lib/
diff --git a/samples/bpf/trace_ns_info_user.c b/samples/bpf/trace_ns_info_user.c
new file mode 100644
index 000000000000..e06d08db6f30
--- /dev/null
+++ b/samples/bpf/trace_ns_info_user.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018 Carlos Neira cneirabustos@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+
+#include <stdio.h>
+#include <linux/bpf.h>
+#include <unistd.h>
+#include "bpf/libbpf.h"
+#include "bpf_load.h"
+
+/* This code was taken verbatim from tracex1_user.c, it's used
+ * to exercize bpf_get_current_pidns_info() helper call.
+ */
+int main(int ac, char **argv)
+{
+ FILE *f;
+ char filename[256];
+
+ snprintf(filename, sizeof(filename), "%s_user_kern.o", argv[0]);
+ printf("loading %s\n", filename);
+
+ if (load_bpf_file(filename)) {
+ printf("%s", bpf_log_buf);
+ return 1;
+ }
+
+ f = popen("taskset 1 ping localhost", "r");
+ (void) f;
+ read_trace_pipe();
+ return 0;
+}
diff --git a/samples/bpf/trace_ns_info_user_kern.c b/samples/bpf/trace_ns_info_user_kern.c
new file mode 100644
index 000000000000..ceaf3e83c8e7
--- /dev/null
+++ b/samples/bpf/trace_ns_info_user_kern.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018 Carlos Neira cneirabustos@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+#include <linux/version.h>
+#include <uapi/linux/bpf.h>
+#include "bpf_helpers.h"
+
+typedef __u64 u64;
+typedef __u32 u32;
+
+
+/* kprobe is NOT a stable ABI
+ * kernel functions can be removed, renamed or completely change semantics.
+ * Number of arguments and their positions can change, etc.
+ * In such case this bpf+kprobe example will no longer be meaningful
+ */
+
+/* This will call bpf_get_current_pidns_info() to display pid and ns values
+ * as seen by the current namespace, on the far left you will see the pid as
+ * seen as by the root namespace.
+ */
+
+SEC("kprobe/__netif_receive_skb_core")
+int bpf_prog1(struct pt_regs *ctx)
+{
+ char fmt[] = "nsid:%u, dev: %u, pid:%u\n";
+ struct bpf_pidns_info nsinfo;
+ int ok = 0;
+
+ ok = bpf_get_current_pidns_info(&nsinfo, sizeof(nsinfo));
+ if (ok == 0)
+ bpf_trace_printk(fmt, sizeof(fmt), (u32)nsinfo.nsid,
+ (u32) nsinfo.dev, (u32)nsinfo.pid);
+
+ return 0;
+}
+
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index dd5758dc35d3..8462f9881465 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -2113,6 +2113,18 @@ union bpf_attr {
* the shared data.
* Return
* Pointer to the local storage area.
+ *
+ * int bpf_get_current_pidns_info(struct bpf_pidns_info *pidns, u32 size_of_pidns)
+ * Description
+ * Copies into *pidns* pid, namespace id and tgid as seen by the
+ * current namespace and also device from /proc/self/ns/pid.
+ * *size_of_pidns* must be the size of *pidns*
+ *
+ * This helper is used when pid filtering is needed inside a
+ * container as bpf_get_current_tgid() helper returns always the
+ * pid id as seen by the root namespace.
+ * Return
+ * 0 on success -EINVAL on error.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -2196,7 +2208,8 @@ union bpf_attr {
FN(rc_keydown), \
FN(skb_cgroup_id), \
FN(get_current_cgroup_id), \
- FN(get_local_storage),
+ FN(get_local_storage), \
+ FN(get_current_pidns_info),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
@@ -2724,4 +2737,13 @@ enum bpf_task_fd_type {
BPF_FD_TYPE_URETPROBE, /* filename + offset */
};
+/* helper bpf_get_current_pidns_info will store the following
+ * data, dev will contain major/minor from /proc/self/ns/pid.
+ */
+struct bpf_pidns_info {
+ __u32 dev;
+ __u32 nsid;
+ __u32 tgid;
+ __u32 pid;
+};
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
index cb9fcfbc9307..c3060f3284e0 100644
--- a/tools/testing/selftests/bpf/bpf_helpers.h
+++ b/tools/testing/selftests/bpf/bpf_helpers.h
@@ -137,6 +137,9 @@ static unsigned long long (*bpf_get_current_cgroup_id)(void) =
(void *) BPF_FUNC_get_current_cgroup_id;
static void *(*bpf_get_local_storage)(void *map, unsigned long long flags) =
(void *) BPF_FUNC_get_local_storage;
+static int (*bpf_get_current_pidns_info)(struct bpf_pidns_info *buf,
+ unsigned int buf_size) =
+ (void *) BPF_FUNC_get_current_pidns_info;
/* llvm builtin functions that eBPF C program may use to
* emit BPF_LD_ABS and BPF_LD_IND instructions
--
2.11.0
On Thu, Aug 09, 2018 at 03:46:53PM +0200, Jesper Dangaard Brouer wrote:
> On Thu, 9 Aug 2018 09:18:00 -0400
> Carlos Neira <cneirabustos@gmail.com> wrote:
>
> > From: cneira <cneirabustos@gmail.com>
> >
> > This helper obtains the active namespace from current and returns pid, tgid,
> > device and namespace id as seen from that namespace, allowing to instrument
> > a process inside a container.
> > Device is read from /proc/self/ns/pid, as in the future it's possible that
> > different pid_ns files may belong to different devices, according
> > to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
> > conference.
> >
> > Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
> > scripts but this helper returns the pid as seen by the root namespace which is
> > fine when a bcc script is not executed inside a container.
> > When the process of interest is inside a container, pid filtering will not work
> > if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
> > returning the pid as it's seen by the current namespace where the script is
> > executing.
> >
> > This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
> > used to do pid filtering even inside a container.
> >
> > For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):
> >
> > u32 pid = bpf_get_current_pid_tgid() >> 32;
> > if (pid != <pid_arg_passed_in>)
> > return 0;
> >
> > Could be modified to use bpf_get_current_pidns_info() as follows:
> >
> > struct bpf_pidns pidns;
> > bpf_get_current_pid_tgid(&pidns, sizeof(struct bpf_pidns));
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> Shouldn't this be:
> bpf_get_current_pidns_info(...)
>
> > u32 pid = pidns.tgid;
> > u32 nsid = pidns.nsid;
> > if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
> > return 0;
> >
>
> [...]
>
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index dd5758dc35d3..031e7d9dba09 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -2113,6 +2113,18 @@ union bpf_attr {
> > * the shared data.
> > * Return
> > * Pointer to the local storage area.
> > + *
> > + * int bpf_get_current_pidns(struct bpf_pidns_info *pidns, u32 size_of_pidns)
>
> Should this be:
> bpf_get_current_pidns_info(...)
>
> > + * Description
> > + * Copies into *pidns* pid, namespace id and tgid as seen by the
> > + * current namespace and also device from /proc/self/ns/pid.
> > + * *size_of_pidns* must be the size of *pidns*
> > + *
> > + * This helper is used when pid filtering is needed inside a
> > + * container as bpf_get_current_tgid() helper returns always the
> > + * pid id as seen by the root namespace.
> > + * Return
> > + * 0 on success -EINVAL on error.
> > */
> > #define __BPF_FUNC_MAPPER(FN) \
> > FN(unspec), \
> > @@ -2196,7 +2208,8 @@ union bpf_attr {
> > FN(rc_keydown), \
> > FN(skb_cgroup_id), \
> > FN(get_current_cgroup_id), \
> > - FN(get_local_storage),
> > + FN(get_local_storage), \
> > + FN(get_current_pidns_info),
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply related
* Re: [PATCH iproute2/net-next] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Stephen Hemminger @ 2018-08-09 16:07 UTC (permalink / raw)
To: Eelco Chaudron; +Cc: netdev, davem
In-Reply-To: <20180809151602.5951.21421.stgit@wsfd-netdev20.ntdv.lab.eng.bos.redhat.com>
On Thu, 9 Aug 2018 11:16:02 -0400
Eelco Chaudron <echaudro@redhat.com> wrote:
>
> +static void print_tcstats_basic_hw(struct rtattr **tbs, char *prefix)
> +{
> + struct gnet_stats_basic bs = {0};
If not present don't print it rather than printing zero.
> + struct gnet_stats_basic bs_hw = {0};
This initialization is unnecessary since you always overwrite it.
> +
> + if (!tbs[TCA_STATS_BASIC_HW])
> + return;
> +
> + memcpy(&bs_hw, RTA_DATA(tbs[TCA_STATS_BASIC_HW]),
> + MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC_HW]), sizeof(bs_hw)));
> +
> + if (bs_hw.bytes == 0 && bs_hw.packets == 0)
> + return;
> +
> + if (tbs[TCA_STATS_BASIC]) {
> + memcpy(&bs, RTA_DATA(tbs[TCA_STATS_BASIC]),
> + MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC]),
> + sizeof(bs)));
> + }
> +
> + if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
> + print_string(PRINT_FP, NULL, "\n%s", prefix);
Please use the magic string _SL_ to allow supporting single line output mode.
> + print_lluint(PRINT_ANY, "sw_bytes",
> + "Sent software %llu bytes",
> + bs.bytes - bs_hw.bytes);
> + print_uint(PRINT_ANY, "sw_packets", " %u pkt",
> + bs.packets - bs_hw.packets);
> + }
> +
> + print_string(PRINT_FP, NULL, "\n%s", prefix);
> + print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
> + bs_hw.bytes);
> + print_uint(PRINT_ANY, "hw_packets", " %u pkt", bs_hw.packets);
> +}
^ permalink raw reply
* we found that
From: Tony @ 2018-08-09 13:43 UTC (permalink / raw)
To: netdev
We just found that you need image editing.
We are an image studio, we do all kinds of image editing such as for
e-commerce photos, jewelry images
and portrait mages.
Our service includes cutting out and clipping path etc , we also do
retouching.
You may send us a photo, testing will be provided to check our quality
Thanks,
Tony Glenn
^ permalink raw reply
* in our studio
From: Tony @ 2018-08-09 14:01 UTC (permalink / raw)
To: netdev
We just found that you need image editing.
We are an image studio, we do all kinds of image editing such as for
e-commerce photos, jewelry images
and portrait mages.
Our service includes cutting out and clipping path etc , we also do
retouching.
You may send us a photo, testing will be provided to check our quality
Thanks,
Tony Glenn
^ permalink raw reply
* provide image solutions
From: Tony @ 2018-08-09 12:13 UTC (permalink / raw)
To: netdev
We just found that you need image editing.
We are an image studio, we do all kinds of image editing such as for
e-commerce photos, jewelry images
and portrait mages.
Our service includes cutting out and clipping path etc , we also do
retouching.
You may send us a photo, testing will be provided to check our quality
Thanks,
Tony Glenn
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net/tls: Combined memory allocation for decryption request
From: Dave Watson @ 2018-08-09 16:25 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180808232623.18075-2-vakul.garg@nxp.com>
On 08/09/18 04:56 AM, Vakul Garg wrote:
> For preparing decryption request, several memory chunks are required
> (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
> an accelerator, it is required that the buffers which are read by the
> accelerator must be dma-able and not come from stack. The buffers for
> aad and iv can be separately kmalloced each, but it is inefficient.
> This patch does a combined allocation for preparing decryption request
> and then segments into aead_req || sgin || sgout || iv || aad.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Reviewed-by: Dave Watson <davejwatson@fb.com>
Thanks, looks good to me now.
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] bpf: add bpf queue map
From: Alexei Starovoitov @ 2018-08-09 16:23 UTC (permalink / raw)
To: Mauricio Vasquez; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <867e95e1-cb45-54c8-ce66-d3e49161d5e6@polito.it>
On Thu, Aug 09, 2018 at 09:51:49AM -0500, Mauricio Vasquez wrote:
>
> > Agree that existing ops are not the right alias, but deferring to user
> > space as inline function also doesn't really seem like a good fit, imho,
> > so I'd prefer rather to have something native. (Aside from that, the
> > above inline bpf_pop() would also race between CPUs.)
>
> I think we should have push/pop/peek syscalls as well, having a bpf_pop()
> that is race prone would create problems. Users expected maps operations to
> be safe, so having one that is not will confuse them.
agree the races are not acceptable.
How about a mixed solution:
- introduce bpf_push/pop/peak helpers that programs will use, so
they don't need to pass useless key=NULL
- introduce map->ops->lookup_and_delete and map->ops->lookup_or_init
that prog-side helpers can use and syscall has 1-1 mapping for
Native lookup_or_init() helper for programs and syscall is badly missing.
Most of the bcc scripts use it and bcc has a racy workaround.
Similarly lookup_and_delete() syscall is 1-1 to pop() for stack/queue
and useful for regular hash maps.
At the end for stack/queue map the programs will use:
int bpf_push(map, value);
value_or_null = bpf_pop(map); // guaranteed non-racy for multi-cpu
value_or_null = bpf_peak(map); // racy if 2+ cpus doing it
from syscall:
bpf_map_lookup_elem(map, NULL, &value); // returns top of stack
bpf_map_lookup_and_delete_elem(map, NULL, &value); // returns top and deletes top atomically
bpf_map_update_elem(map, NULL, &value); // pushes new value into stack atomically
Eventually hash and other maps will implement bpf_map_lookup_and_delete()
for both bpf progs and syscall.
The main point that prog-side api doesn't have to match 1-1 to syscall-side,
since they're different enough already.
Like lookup_or_init() is badly needed for programs, but unnecessary for syscall.
Thoughts?
^ permalink raw reply
* [PATCH net-next 0/4] new mechanism to ACK immediately
From: Yuchung Cheng @ 2018-08-09 16:38 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, ncardwell, brakmo, weiwan, Yuchung Cheng
This patch is a follow-up feature improvement to the recent fixes on
the performance issues in ECN (delayed) ACKs. Many of the fixes use
tcp_enter_quickack_mode routine to force immediate ACKs. However the
routine also reset tracking interactive session. This is not ideal
because these immediate ACKs are required by protocol specifics
unrelated to the interactiveness nature of the application.
This patch set introduces a new flag to send a one-time immediate ACK
without changing the status of interactive session tracking. With this
patch set the immediate ACKs are generated upon these protocol states:
1) When a hole is repaired
2) When CE status changes between subsequent data packets received
3) When a data packet carries CWR flag
Yuchung Cheng (4):
tcp: mandate a one-time immediate ACK
tcp: avoid resetting ACK timer in DCTCP
tcp: always ACK immediately on hole repairs
tcp: avoid resetting ACK timer upon receiving packet with ECN CWR flag
include/net/inet_connection_sock.h | 3 ++-
net/ipv4/tcp_dctcp.c | 4 ++--
net/ipv4/tcp_input.c | 16 +++++++++-------
3 files changed, 13 insertions(+), 10 deletions(-)
--
2.18.0.597.ga71716f1ad-goog
^ 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