* Re: [PATCH iproute2-next] ip: Add violation counters to VF statisctics
From: David Ahern @ 2018-07-25 17:00 UTC (permalink / raw)
To: Eran Ben Elisha, Stephen Hemminger; +Cc: netdev
In-Reply-To: <1532255472-30759-1-git-send-email-eranbe@mellanox.com>
On 7/22/18 4:31 AM, Eran Ben Elisha wrote:
> Extend VFs statistics by receive and transmit violation counters.
>
> Example: "ip -s link show dev enp5s0f0"
>
> 6: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
> link/ether 24:8a:07:a5:28:f0 brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 0 0 0 0 0 2
> TX: bytes packets errors dropped carrier collsns
> 1406 17 0 0 0 0
> vf 0 MAC 00:00:ca:fe:ca:fe, vlan 5, spoof checking off, link-state auto, trust off, query_rss off
> RX: bytes packets mcast bcast dropped
> 1666 29 14 32 0
> TX: bytes packets dropped
> 2880 44 2412
>
> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
> ---
> ip/ipaddress.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [patch iproute2/net-next v4] tc: introduce support for chain templates
From: David Ahern @ 2018-07-25 17:03 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
john.hurley, mlxsw, sridhar.samudrala
In-Reply-To: <20180723072440.4318-1-jiri@resnulli.us>
On 7/23/18 1:24 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> v3->v4:
> - reworked to chain object
> v1->v2:
> - moved the template handling
> from "tc filter template" to "tc chaintemplate"
> ---
> include/uapi/linux/rtnetlink.h | 7 +++
> man/man8/tc.8 | 26 ++++++++
> tc/tc.c | 5 +-
> tc/tc_common.h | 1 +
> tc/tc_filter.c | 131 +++++++++++++++++++++++++++++------------
> tc/tc_monitor.c | 5 +-
> 6 files changed, 135 insertions(+), 40 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH iproute2] iplink: report drop stats for VFs
From: David Ahern @ 2018-07-25 17:04 UTC (permalink / raw)
To: Ivan Vecera, netdev; +Cc: stephen, Eugenia Emantayev, Saeed Mahameed
In-Reply-To: <20180725162212.26212-1-ivecera@redhat.com>
On 7/25/18 10:22 AM, Ivan Vecera wrote:
> Kernel commit c5a9f6f0ab40 ("net/core: Add drop counters to VF
> statistics") added support for Rx/Tx packet drops but these stats are
> not reported by 'ip link'.
>
> Cc: Eugenia Emantayev <eugenia@mellanox.com>
> Cc: Saeed Mahameed <saeedm@mellanox.com>
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> ip/ipaddress.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
duplicates a patch from Eran which I just committed to iproute2-next
^ permalink raw reply
* Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
From: Marcelo Ricardo Leitner @ 2018-07-25 17:09 UTC (permalink / raw)
To: Cong Wang
Cc: Jamal Hadi Salim, Paolo Abeni, Linux Kernel Network Developers,
Jiri Pirko, Daniel Borkmann, Eyal Birger, David Miller
In-Reply-To: <CAM_iQpUpnY=euK99uogzXpUKm9MiX9jn66QRTFJvx_ucRng4kA@mail.gmail.com>
On Wed, Jul 25, 2018 at 09:48:16AM -0700, Cong Wang wrote:
> On Wed, Jul 25, 2018 at 5:27 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >
> > Those changes were there from the beginning (above patch did
> > not introduce them).
> > IIRC, the reason was to distinguish between policy intended
> > drops and drops because of errors.
>
> There must be a limit for "overlimit" to make sense. There is
> no limit in mirred action's context, probably there is only
> such a limit in act_police. So, all rest should not touch overlimit.
+1
^ permalink raw reply
* Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace
From: David Ahern @ 2018-07-25 18:23 UTC (permalink / raw)
To: David Miller
Cc: xiyou.wangcong, netdev, nikita.leshchenko, roopa, stephen, idosch,
jiri, saeedm, alex.aring, linux-wpan, netfilter-devel,
linux-kernel
In-Reply-To: <20180724.101405.797730329231867648.davem@davemloft.net>
On 7/24/18 11:14 AM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Tue, 24 Jul 2018 09:14:01 -0600
>
>> I get the impression there is no longer a strong resistance against
>> moving the tables to per namespace, but deciding what is the right
>> approach to handle backwards compatibility. Correct? Changing the
>> accounting is inevitably going to be noticeable to some use case(s), but
>> with sysctl settings it is a simple runtime update once the user knows
>> to make the change.
>>
>> neighbor entries round up to 512 byte allocations, so with the current
>> gc_thresh defaults (128/512/1024) 512k can be consumed. Using those
>> limits per namespace seems high which is why I suggested a per-namespace
>> default of (16/32/64) which amounts to 32k per namespace limit by
>> default. Open to other suggestions as well.
>
> No objection from me about going to per-ns neigh tables.
>
> About the defaults, I wonder if we can scale them to the amount of
> memory given to the ns or something like that? I bet this will better
> match the intended use of the ns.
>
Not sure how to do that. I am not aware of memory allocations to a
network namespace. As I understand it containers use cgroups to control
memory use, but I am not aware of any direct ties to namespace.
^ permalink raw reply
* Dear Sir/Madam!
From: Paul Willson @ 2018-07-25 17:13 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Dear Sir/Madam!
We are interested in purchasing your products and we sincerely hope to
establish a long-term business relation with your esteemed company.
Please kindly send me your latest catalog. Also, inform me about the
Minimum Order Quantity, Delivery time or FOB, and payment terms
warranty.Please contact us via:[ paulwillson448@gmail.com ]
Your early reply is highly appreciated.
THANKS.
[-- Attachment #2: Type: text/html, Size: 1823 bytes --]
^ permalink raw reply
* Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'
From: Taeung Song @ 2018-07-25 18:27 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau, netdev,
Thomas Girard, Martin Cermak, linux-kernel, acme
In-Reply-To: <20180725175231.GA2121@redhat.com>
Hi Arnaldo,
On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu:
>> Hi,
>>
>> Building bpf programs with .BTF section,
>> I thought it'd be better to convert dwarf info to .BTF by
>> a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of pahole
>> in the future.
>
>> Currently for bpf binary that have .BTF section,
>> we need to use pahole from https://github.com/iamkafai/pahole/tree/btf
>> with the command line such as "pahole -J bpf_prog.o".
>
>> I think it is great but if implementing new 'bpf_dwarf2btf'
>> (dwarf parsing + btf encoder code written by Martin KaFai Lau on
>> the pahole project i.e. btf.h, btf_encoder.c, btf_encoder.h,
>> libbtf.c, libbtf.h),
>> BPF developers would more easily use functionalities based on BTF.
>
> What would be easier exactly? Not having to install a package but build
> it from the kernel sources?
>
> Many kernel developers already have pahole installed for other uses, so
> no need to install anything.
>
Understood, but I think there are many non-kernel developers
developing BPF programs and they mightn't have or use pahole.
So, if providing the 'dwarf2btf' feature on tools/bpf or tools/bpf/bpftool,
non-kernel developers can also more easily build bpf prog with .BPF, no ?
> BTW, Daniel, I just pushed to pahole's main repository at:
>
> git://git.kernel.org/pub/scm/devel/pahole/pahole.git
>
> with the Martin's BTF patch, so no need to pull from the github one,
> I'll tag v1.12 and announce the release so that distro package
> maintainers can update their packages.
>
>> What do you think about this ? Do you think this is needed ?
>> Or, already implementing something like this ?
>
>> If it is needed, I want to try to make 'tools/bpf/bpf_dwarf2btf'
>> based on the pahole code. I'd appreciate it, if you reply to this
>
> The way Martin took advantage of the work done a long time ago to
> support CTF out of the same DWARF reading codebase was really cool, not
> that much work to do, just add a new format to pahole's codebase making
> it more useful.
>
I got it !
Thanks,
Taeung
> I was just so far overly picky with testing it and kept leaving for
> later to have a good documentation about testing it, vacation and perf
> maintainership duties kept making this take like forever, grumble :-\
>
> - Arnaldo
>
--
oh.. :'(
^ permalink raw reply
* [PATCH] net: wireless: ath6kl: Remove unnecessary parentheses
From: Varsha Rao @ 2018-07-25 18:49 UTC (permalink / raw)
To: Lukas Bulwahn, Nicholas Mc Guire, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
Cc: Varsha Rao
Remove extra parentheses to fix the clang warning of extraneous
parentheses.
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/ath/ath6kl/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/main.c b/drivers/net/wireless/ath/ath6kl/main.c
index 808fb30be9ad..451297441532 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -639,7 +639,7 @@ void ath6kl_connect_event(struct ath6kl_vif *vif, u16 channel, u8 *bssid,
memcpy(vif->bssid, bssid, sizeof(vif->bssid));
vif->bss_ch = channel;
- if ((vif->nw_type == INFRA_NETWORK)) {
+ if (vif->nw_type == INFRA_NETWORK) {
ath6kl_wmi_listeninterval_cmd(ar->wmi, vif->fw_vif_idx,
vif->listen_intvl_t, 0);
ath6kl_check_ch_switch(ar, channel);
--
2.17.0
^ permalink raw reply related
* [PATCH] net: wireless: ath9k: Remove unnecessary parentheses
From: Varsha Rao @ 2018-07-25 18:53 UTC (permalink / raw)
To: Lukas Bulwahn, Nicholas Mc Guire, QCA ath9k Development,
Kalle Valo, David S. Miller, linux-wireless, netdev, linux-kernel
Cc: Varsha Rao
Remove extra parentheses to fix the clang warning of extraneous
parentheses.
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/ath/ath9k/debug_sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c b/drivers/net/wireless/ath/ath9k/debug_sta.c
index a6f45f1bb5bb..ed8b77a74630 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -116,7 +116,7 @@ void ath_debug_rate_stats(struct ath_softc *sc,
if (rxs->rate_idx >= ARRAY_SIZE(rstats->ht_stats))
goto exit;
- if ((rxs->bw == RATE_INFO_BW_40))
+ if (rxs->bw == RATE_INFO_BW_40)
rstats->ht_stats[rxs->rate_idx].ht40_cnt++;
else
rstats->ht_stats[rxs->rate_idx].ht20_cnt++;
--
2.17.0
^ permalink raw reply related
* [PATCH] net: wireless: brcmsmac: Remove extra parentheses
From: Varsha Rao @ 2018-07-25 18:56 UTC (permalink / raw)
To: Lukas Bulwahn, Nicholas Mc Guire, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Kalle Valo,
David S. Miller, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel
Cc: Varsha Rao
Remove the unnecessary parentheses to fix the clang warning of
extraneous parentheses.
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 1a187557982e..4deba3075083 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -25453,12 +25453,12 @@ void wlc_phy_cal_perical_nphy_run(struct brcms_phy *pi, u8 caltype)
(pi->cal_type_override ==
PHY_PERICAL_FULL) ? true : false;
- if ((pi->mphase_cal_phase_id > MPHASE_CAL_STATE_INIT)) {
+ if (pi->mphase_cal_phase_id > MPHASE_CAL_STATE_INIT) {
if (pi->nphy_txiqlocal_chanspec != pi->radio_chanspec)
wlc_phy_cal_perical_mphase_restart(pi);
}
- if ((pi->mphase_cal_phase_id == MPHASE_CAL_STATE_RXCAL))
+ if (pi->mphase_cal_phase_id == MPHASE_CAL_STATE_RXCAL)
wlapi_bmac_write_shm(pi->sh->physhim, M_CTS_DURATION, 10000);
wlapi_suspend_mac_and_wait(pi->sh->physhim);
--
2.17.0
^ permalink raw reply related
* [PATCH] net: wireless: cw1200: Remove extra parentheses
From: Varsha Rao @ 2018-07-25 19:00 UTC (permalink / raw)
To: Lukas Bulwahn, Nicholas Mc Guire, Solomon Peachy, Kalle Valo,
David S. Miller, linux-wireless, netdev, linux-kernel
Cc: Varsha Rao
Remove unnecessary parentheses to fix the extraneous parentheses clang
warning.
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/st/cw1200/txrx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/st/cw1200/txrx.c b/drivers/net/wireless/st/cw1200/txrx.c
index f7b1b0062db3..8c800ef23159 100644
--- a/drivers/net/wireless/st/cw1200/txrx.c
+++ b/drivers/net/wireless/st/cw1200/txrx.c
@@ -624,9 +624,9 @@ cw1200_tx_h_bt(struct cw1200_common *priv,
priority = WSM_EPTA_PRIORITY_ACTION;
else if (ieee80211_is_mgmt(t->hdr->frame_control))
priority = WSM_EPTA_PRIORITY_MGT;
- else if ((wsm->queue_id == WSM_QUEUE_VOICE))
+ else if (wsm->queue_id == WSM_QUEUE_VOICE)
priority = WSM_EPTA_PRIORITY_VOICE;
- else if ((wsm->queue_id == WSM_QUEUE_VIDEO))
+ else if (wsm->queue_id == WSM_QUEUE_VIDEO)
priority = WSM_EPTA_PRIORITY_VIDEO;
else
priority = WSM_EPTA_PRIORITY_DATA;
--
2.17.0
^ permalink raw reply related
* Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'
From: Daniel Borkmann @ 2018-07-25 19:06 UTC (permalink / raw)
To: Taeung Song, Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov, Martin KaFai Lau, netdev, Thomas Girard,
Martin Cermak, linux-kernel, acme
In-Reply-To: <35663517-26e1-c2a2-1554-5dd90be2747f@gmail.com>
On 07/25/2018 08:27 PM, Taeung Song wrote:
> On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote:
[...]
>> BTW, Daniel, I just pushed to pahole's main repository at:
>>
>> git://git.kernel.org/pub/scm/devel/pahole/pahole.git
>>
>> with the Martin's BTF patch, so no need to pull from the github one,
>> I'll tag v1.12 and announce the release so that distro package
>> maintainers can update their packages.
Awesome, thanks so much Arnaldo!
^ permalink raw reply
* Re: [PATCH v3] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest()
From: Julian Anastasov @ 2018-07-25 19:12 UTC (permalink / raw)
To: Tan Hu
Cc: wensong, horms, pablo, kadlec, fw, davem, netdev, lvs-devel,
netfilter-devel, coreteam, linux-kernel, zhong.weidong,
jiang.biao2
In-Reply-To: <1532503387-3800-1-git-send-email-tan.hu@zte.com.cn>
Hello,
On Wed, 25 Jul 2018, Tan Hu wrote:
> We came across infinite loop in ipvs when using ipvs in docker
> env.
>
> When ipvs receives new packets and cannot find an ipvs connection,
> it will create a new connection, then if the dest is unavailable
> (i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently.
>
> But if the dropped packet is the first packet of this connection,
> the connection control timer never has a chance to start and the
> ipvs connection cannot be released. This will lead to memory leak, or
> infinite loop in cleanup_net() when net namespace is released like
> this:
>
> ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs]
> __ip_vs_cleanup at ffffffffa0a9f60a [ip_vs]
> ops_exit_list at ffffffff81567a49
> cleanup_net at ffffffff81568b40
> process_one_work at ffffffff810a851b
> worker_thread at ffffffff810a9356
> kthread at ffffffff810b0b6f
> ret_from_fork at ffffffff81697a18
>
> race condition:
> CPU1 CPU2
> ip_vs_in()
> ip_vs_conn_new()
> ip_vs_del_dest()
> __ip_vs_unlink_dest()
> ~IP_VS_DEST_F_AVAILABLE
> cp->dest && !IP_VS_DEST_F_AVAILABLE
> __ip_vs_conn_put
> ...
> cleanup_net ---> infinite looping
>
> Fix this by checking whether the timer already started.
>
> Signed-off-by: Tan Hu <tan.hu@zte.com.cn>
> Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
v3 looks good to me,
Acked-by: Julian Anastasov <ja@ssi.bg>
Simon and Pablo, this can be applied to ipvs/nf tree...
> ---
> v2: fix use-after-free in CONN_ONE_PACKET case suggested by Julian Anastasov
> v3: remove trailing whitespace for patch checking
>
> net/netfilter/ipvs/ip_vs_core.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index 0679dd1..a17104f 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1972,13 +1972,20 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb,
> if (cp->dest && !(cp->dest->flags & IP_VS_DEST_F_AVAILABLE)) {
> /* the destination server is not available */
>
> - if (sysctl_expire_nodest_conn(ipvs)) {
> + __u32 flags = cp->flags;
> +
> + /* when timer already started, silently drop the packet.*/
> + if (timer_pending(&cp->timer))
> + __ip_vs_conn_put(cp);
> + else
> + ip_vs_conn_put(cp);
> +
> + if (sysctl_expire_nodest_conn(ipvs) &&
> + !(flags & IP_VS_CONN_F_ONE_PACKET)) {
> /* try to expire the connection immediately */
> ip_vs_conn_expire_now(cp);
> }
> - /* don't restart its timer, and silently
> - drop the packet. */
> - __ip_vs_conn_put(cp);
> +
> return NF_DROP;
> }
>
> --
> 1.8.3.1
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace
From: Eric W. Biederman @ 2018-07-25 19:17 UTC (permalink / raw)
To: David Ahern
Cc: Cong Wang, David Miller, Linux Kernel Network Developers,
nikita.leshchenko, Roopa Prabhu, Stephen Hemminger, Ido Schimmel,
Jiri Pirko, Saeed Mahameed, Alexander Aring, linux-wpan,
NetFilter, LKML
In-Reply-To: <dacc9322-fd5a-dfeb-e4f1-7a288fb79886@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> On 7/25/18 11:38 AM, Eric W. Biederman wrote:
>>
>> Absolutely NOT. Global thresholds are exactly correct given the fact
>> you are running on a single kernel.
>>
>> Memory is not free (Even though we are swimming in enough of it memory
>> rarely matters). One of the few remaining challenges is for containers
>> is finding was to limit resources in such a way that one application
>> does not mess things up for another container during ordinary usage.
>>
>> It looks like the neighbour tables absolutely are that kind of problem,
>> because the artificial limits are too strict. Completely giving up on
>> limits does not seem right approach either. We need to fix the limits
>> we have (perhaps making them go away entirely), not just apply a
>> band-aid. Let's get to the bottom of this and make the system better.
>
> Eric: yes, they all share the global resource of memory and there should
> be limits on how many entries a remote entity can create.
>
> Network namespaces can provide a separation such that one namespace does
> not disrupt networking in another. It is absolutely appropriate to do
> so. Your rigid stance is inconsistent given the basic meaning of a
> network namespace and the parallels to this same problem -- bridges,
> vxlans, and ip fragments. Only neighbor tables are not per-device or per
> namespace; your insistence on global limits is missing the mark and wrong.
That is not what I said. Let me rephrase and see if you understand.
The problem appears to be of lots of devices. Fundamentally if you use
lots of network devices today unless you adjust gc_thresh3 you will run
out of neighbour table entries.
The problem has a bigger scope than what you are looking at.
If you fix the core problem you won't see the problem in the context
of network namespaces either.
Default limits should be something that will never be hit unless
something goes crazy. We are hitting them. Therefore by definition
there is a bug in these limits.
And yes there is absolutely a place for global limits on things like
inodes, file descriptors etc, that does not care about which part of the
kernel you are in. However hitting those limits in normal operation is
a bug.
We have ourselves a bug.
Eric
p.s. I wrote the definition of network namespaces and it absolutely does
have room for global limits. One of the things Linus has periodically
yelled at me about is that there are not enough of them.
^ permalink raw reply
* Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'
From: Taeung Song @ 2018-07-25 19:21 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Daniel Borkmann
Cc: Alexei Starovoitov, Martin KaFai Lau, netdev, Thomas Girard,
Martin Cermak, linux-kernel, acme
In-Reply-To: <35663517-26e1-c2a2-1554-5dd90be2747f@gmail.com>
On 07/26/2018 03:27 AM, Taeung Song wrote:
> Hi Arnaldo,
>
> On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu:
>>> Hi,
>>>
>>> Building bpf programs with .BTF section,
>>> I thought it'd be better to convert dwarf info to .BTF by
>>> a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of pahole
>>> in the future.
>>> Currently for bpf binary that have .BTF section,
>>> we need to use pahole from https://github.com/iamkafai/pahole/tree/btf
>>> with the command line such as "pahole -J bpf_prog.o".
>>> I think it is great but if implementing new 'bpf_dwarf2btf'
>>> (dwarf parsing + btf encoder code written by Martin KaFai Lau on
>>> the pahole project i.e. btf.h, btf_encoder.c, btf_encoder.h,
>>> libbtf.c, libbtf.h),
>>> BPF developers would more easily use functionalities based on BTF.
>>
>> What would be easier exactly? Not having to install a package but build
>> it from the kernel sources?
>>
>> Many kernel developers already have pahole installed for other uses, so
>> no need to install anything.
>>
>
> Understood, but I think there are many non-kernel developers
> developing BPF programs and they mightn't have or use pahole.
>
> So, if providing the 'dwarf2btf' feature on tools/bpf or tools/bpf/bpftool,
> non-kernel developers can also more easily build bpf prog with .BPF, no ?
>
Or, if tools/lib/bpf/ have the 'dwarf2btf' feature,
I think BPF developers can just use bpf programs that have dwarf info
after compiling with clang '-g' and llc '-mattr=dwarfris', even though
not using pahole.
Isn't it good way ?
>> BTW, Daniel, I just pushed to pahole's main repository at:
>>
>> git://git.kernel.org/pub/scm/devel/pahole/pahole.git
>>
>> with the Martin's BTF patch, so no need to pull from the github one,
>> I'll tag v1.12 and announce the release so that distro package
>> maintainers can update their packages.
>>> What do you think about this ? Do you think this is needed ?
>>> Or, already implementing something like this ?
>>> If it is needed, I want to try to make 'tools/bpf/bpf_dwarf2btf'
>>> based on the pahole code. I'd appreciate it, if you reply to this
>>
>> The way Martin took advantage of the work done a long time ago to
>> support CTF out of the same DWARF reading codebase was really cool, not
>> that much work to do, just add a new format to pahole's codebase making
>> it more useful.
>>
>
> I got it !
>
> Thanks,
> Taeung
>
>> I was just so far overly picky with testing it and kept leaving for
>> later to have a good documentation about testing it, vacation and perf
>> maintainership duties kept making this take like forever, grumble :-\
>>
>> - Arnaldo
>>
>
> --
> oh.. :'(
^ permalink raw reply
* Re: [PATCH net-next v3 3/5] tc/act: remove unneeded RCU lock in action callback
From: Marcelo Ricardo Leitner @ 2018-07-25 18:24 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Paolo Abeni, netdev, Cong Wang, Jiri Pirko, Daniel Borkmann,
Eyal Birger, David S. Miller
In-Reply-To: <f140db13-471c-4753-82de-8522c635fa13@mojatatu.com>
On Wed, Jul 25, 2018 at 07:59:48AM -0400, Jamal Hadi Salim wrote:
> On 24/07/18 04:06 PM, Paolo Abeni wrote:
> > Each lockless action currently does its own RCU locking in ->act().
> > This is allows using plain RCU accessor, even if the context
> > is really RCU BH.
> >
> > This change drops the per action RCU lock, replace the accessors
> > with _bh variant, cleans up a bit the surronding code and documents
> > the RCU status in the relevant header.
> > No functional nor performance change is intended.
> >
> > The goal of this patch is clarifying that the RCU critical section
> > used by the tc actions extends up to the classifier's caller.
> >
>
> This and 2/5 seems to stand on their own merit.
So does 1/5, I think.
>
> cheers,
> jamal
^ permalink raw reply
* [PATCH v1 0/4] PCI: Remove unnecessary includes of <linux/pci-aspm.h>
From: Bjorn Helgaas @ 2018-07-25 19:52 UTC (permalink / raw)
To: linux-pci
Cc: Jeff Kirsher, David S. Miller, Kalle Valo, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, ath9k-devel, linuxwifi,
intel-wired-lan, netdev, linux-kernel, linux-wireless
Remove includes of <linux/pci-aspm.h> from files that don't need
it. I'll apply all these via the PCI tree unless there's objection.
---
Bjorn Helgaas (4):
igb: Remove unnecessary include of <linux/pci-aspm.h>
ath9k: Remove unnecessary include of <linux/pci-aspm.h>
iwlwifi: Remove unnecessary include of <linux/pci-aspm.h>
PCI: Remove unnecessary include of <linux/pci-aspm.h>
drivers/net/ethernet/intel/igb/igb_main.c | 1 -
drivers/net/wireless/ath/ath9k/pci.c | 1 -
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 -
drivers/pci/pci-sysfs.c | 1 -
drivers/pci/pci.c | 1 -
drivers/pci/probe.c | 1 -
drivers/pci/remove.c | 1 -
7 files changed, 7 deletions(-)
^ permalink raw reply
* [PATCH v1 1/4] igb: Remove unnecessary include of <linux/pci-aspm.h>
From: Bjorn Helgaas @ 2018-07-25 19:52 UTC (permalink / raw)
To: linux-pci
Cc: Jeff Kirsher, David S. Miller, Kalle Valo, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, ath9k-devel, linuxwifi,
intel-wired-lan, netdev, linux-kernel, linux-wireless
In-Reply-To: <153254813164.92573.10755585465477668768.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
The igb driver doesn't need anything provided by pci-aspm.h, so remove
the unnecessary include of it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index f707709969ac..c77fda05f683 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -22,7 +22,6 @@
#include <linux/if.h>
#include <linux/if_vlan.h>
#include <linux/pci.h>
-#include <linux/pci-aspm.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/ip.h>
^ permalink raw reply related
* [PATCH v1 3/4] iwlwifi: Remove unnecessary include of <linux/pci-aspm.h>
From: Bjorn Helgaas @ 2018-07-25 19:52 UTC (permalink / raw)
To: linux-pci
Cc: Jeff Kirsher, David S. Miller, Kalle Valo, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, ath9k-devel, linuxwifi,
intel-wired-lan, netdev, linux-kernel, linux-wireless
In-Reply-To: <153254813164.92573.10755585465477668768.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
This part of the iwlwifi driver doesn't need anything provided by
pci-aspm.h, so remove the unnecessary include of it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 38234bda9017..d6c55e111fda 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -72,7 +72,6 @@
#include <linux/module.h>
#include <linux/pm_runtime.h>
#include <linux/pci.h>
-#include <linux/pci-aspm.h>
#include <linux/acpi.h>
#include "fw/acpi.h"
^ permalink raw reply related
* [PATCH v1 4/4] PCI: Remove unnecessary include of <linux/pci-aspm.h>
From: Bjorn Helgaas @ 2018-07-25 19:52 UTC (permalink / raw)
To: linux-pci
Cc: Jeff Kirsher, David S. Miller, Kalle Valo, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, ath9k-devel, linuxwifi,
intel-wired-lan, netdev, linux-kernel, linux-wireless
In-Reply-To: <153254813164.92573.10755585465477668768.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Several PCI core files include pci-aspm.h even though they don't need
anything provided by that file. Remove the unnecessary includes of it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci-sysfs.c | 1 -
drivers/pci/pci.c | 1 -
drivers/pci/probe.c | 1 -
drivers/pci/remove.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 0c4653c1d2ce..91337faae60d 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -23,7 +23,6 @@
#include <linux/fs.h>
#include <linux/capability.h>
#include <linux/security.h>
-#include <linux/pci-aspm.h>
#include <linux/slab.h>
#include <linux/vgaarb.h>
#include <linux/pm_runtime.h>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f5c6ab14fb31..7c2f0e682fc0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -23,7 +23,6 @@
#include <linux/string.h>
#include <linux/log2.h>
#include <linux/logic_pio.h>
-#include <linux/pci-aspm.h>
#include <linux/pm_wakeup.h>
#include <linux/interrupt.h>
#include <linux/device.h>
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e32de4b..1ed2852dee21 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -13,7 +13,6 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/cpumask.h>
-#include <linux/pci-aspm.h>
#include <linux/aer.h>
#include <linux/acpi.h>
#include <linux/hypervisor.h>
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 6f072eae4f7a..01ec7fcb5634 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -1,7 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/pci.h>
#include <linux/module.h>
-#include <linux/pci-aspm.h>
#include "pci.h"
static void pci_free_resources(struct pci_dev *dev)
^ permalink raw reply related
* Re: [PATCH net-next] net: phy: prevent PHYs w/o Clause 22 regs from calling genphy_config_aneg
From: David Miller @ 2018-07-25 20:03 UTC (permalink / raw)
To: camelia.groza; +Cc: andrew, f.fainelli, rmk+kernel, netdev, linux-kernel
In-Reply-To: <1532358375-8146-1-git-send-email-camelia.groza@nxp.com>
From: Camelia Groza <camelia.groza@nxp.com>
Date: Mon, 23 Jul 2018 18:06:15 +0300
> genphy_config_aneg() should be called only by PHYs that implement
> the Clause 22 register set. Prevent Clause 45 PHYs that don't implement
> the register set from calling the genphy function.
>
> Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Applied, thank you.
^ permalink raw reply
* Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'
From: Martin KaFai Lau @ 2018-07-25 20:11 UTC (permalink / raw)
To: Taeung Song, Arnaldo Carvalho de Melo
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, Thomas Girard,
Martin Cermak, linux-kernel, acme
In-Reply-To: <592c6325-23d0-771b-cc28-6a66842a1265@gmail.com>
On Thu, Jul 26, 2018 at 04:21:31AM +0900, Taeung Song wrote:
>
>
> On 07/26/2018 03:27 AM, Taeung Song wrote:
> > Hi Arnaldo,
> >
> > On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu:
> > > > Hi,
> > > >
> > > > Building bpf programs with .BTF section,
> > > > I thought it'd be better to convert dwarf info to .BTF by
> > > > a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of pahole
> > > > in the future.
> > > > Currently for bpf binary that have .BTF section,
> > > > we need to use pahole from https://github.com/iamkafai/pahole/tree/btf
> > > > with the command line such as "pahole -J bpf_prog.o".
> > > > I think it is great but if implementing new 'bpf_dwarf2btf'
> > > > (dwarf parsing + btf encoder code written by Martin KaFai Lau on
> > > > the pahole project i.e. btf.h, btf_encoder.c, btf_encoder.h,
> > > > libbtf.c, libbtf.h),
> > > > BPF developers would more easily use functionalities based on BTF.
> > >
> > > What would be easier exactly? Not having to install a package but build
> > > it from the kernel sources?
> > >
> > > Many kernel developers already have pahole installed for other uses, so
> > > no need to install anything.
> > >
> >
> > Understood, but I think there are many non-kernel developers
> > developing BPF programs and they mightn't have or use pahole.
> >
> > So, if providing the 'dwarf2btf' feature on tools/bpf or tools/bpf/bpftool,
> > non-kernel developers can also more easily build bpf prog with .BPF, no ?
Some quick thoughts,
IMO, I suspect if it is in the distro's pahole package, it should be easy
enough for kernel and non kernel developer to install.
BTF usage is still evolving, we might re-evaluate going forward but at this
point I think leveraging pahole's existing capability is a good option.
> >
>
> Or, if tools/lib/bpf/ have the 'dwarf2btf' feature,
> I think BPF developers can just use bpf programs that have dwarf info
> after compiling with clang '-g' and llc '-mattr=dwarfris', even though not
> using pahole.
> Isn't it good way ?
>
> > > BTW, Daniel, I just pushed to pahole's main repository at:
> > >
> > > git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> > >
> > > with the Martin's BTF patch, so no need to pull from the github one,
> > > I'll tag v1.12 and announce the release so that distro package
> > > maintainers can update their packages.
Awesome! Thanks, Arnaldo!
- Martin
^ permalink raw reply
* Re: [PATCH iproute2] iplink: report drop stats for VFs
From: Ivan Vecera @ 2018-07-25 19:11 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: stephen, Eugenia Emantayev, Saeed Mahameed
In-Reply-To: <6bf1abcc-6fc1-9211-2eec-5a28be412b4b@gmail.com>
On 25.7.2018 19:04, David Ahern wrote:
> On 7/25/18 10:22 AM, Ivan Vecera wrote:
>> Kernel commit c5a9f6f0ab40 ("net/core: Add drop counters to VF
>> statistics") added support for Rx/Tx packet drops but these stats are
>> not reported by 'ip link'.
>>
>> Cc: Eugenia Emantayev <eugenia@mellanox.com>
>> Cc: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
>> ---
>> ip/ipaddress.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>
> duplicates a patch from Eran which I just committed to iproute2-next
>
Oops, I missed it :-)
I.
^ permalink raw reply
* Re: selftests: bpf: test_progs: deadlock at trace_call_bpf
From: Martin KaFai Lau @ 2018-07-25 19:18 UTC (permalink / raw)
To: Naresh Kamboju
Cc: netdev, ast, Daniel Borkmann, rostedt, open list,
open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CA+G9fYs-AzZ4x2x8m5kOYaEg_vagaorjQAkWs9C5ghOnCLYZvA@mail.gmail.com>
On Tue, Jul 24, 2018 at 02:51:42PM +0530, Naresh Kamboju wrote:
> Deadlock warning on x86 machine while testing selftests: bpf:
> test_progs and running linux next 4.18.0-rc3-next-20180705 and still
> happening on 4.18.0-rc5-next-20180720.
>
> Any one noticed this kernel warning about deadlock ?
It should be a false positive. The head->lock is a percpu
lock and is acquired by the bpf prog running on that cpu when
updating a bpf htab. Hence, CPU0 and CPU1 are acquiring
a different head->lock.
When looking at a CPU alone, another bpf prog cannot start
running on the same CPU before the currently running bpf prog
has finished. e.g. There is a percpu "bpf_prog_active" counter
to ensure that in the tracing side.
The head->lock is primary used in bpf htab update which
is used very heavily in most of the bpf progs. Hence,
replacing the lock with the irqsave version is unnecessary
while having performance impact.
Thanks,
Martin
>
> selftests: bpf: test_progs
> libbpf: incorrect bpf_call opcode
> libbpf: incorrect bpf_call opcode
> test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
> test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
> test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
> test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
> test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
> test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
> [ 69.903862] ========================================================
> [ 69.910213] WARNING: possible irq lock inversion dependency detected
> [ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
> [ 69.921428] --------------------------------------------------------
> [ 69.927774] dd/2928 just changed the state of lock:
> [ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
> pcpu_freelist_push+0x28/0x50
> [ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
> in the past:
> [ 69.947420] (&rq->lock){-.-.}
> [ 69.947421]
> [ 69.947421]
> [ 69.947421] and interrupts could create inverse lock ordering between them.
> [ 69.947421]
> [ 69.961842]
> [ 69.961842] other info that might help us debug this:
> [ 69.968357] Possible interrupt unsafe locking scenario:
> [ 69.968357]
> [ 69.975136] CPU0 CPU1
> [ 69.979659] ---- ----
> [ 69.984184] lock(&head->lock);
> [ 69.987406] local_irq_disable();
> [ 69.993319] lock(&rq->lock);
> [ 69.998882] lock(&head->lock);
> [ 70.004618] <Interrupt>
> [ 70.007235] lock(&rq->lock);
> [ 70.010461]
> [ 70.010461] *** DEADLOCK ***
> [ 70.010461]
> [ 70.016372] 1 lock held by dd/2928:
> [ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
> trace_call_bpf+0x37/0x1d0
> [ 70.027768]
> [ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
> [ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
> [ 70.040204] IN-HARDIRQ-W at:
> [ 70.043428] lock_acquire+0xd5/0x1c0
> [ 70.048820] _raw_spin_lock+0x2f/0x40
> [ 70.054299] scheduler_tick+0x51/0xf0
> [ 70.059781] update_process_times+0x47/0x60
> [ 70.065779] tick_periodic+0x2b/0xc0
> [ 70.071171] tick_handle_periodic+0x25/0x70
> [ 70.077168] timer_interrupt+0x15/0x20
> [ 70.082731] __handle_irq_event_percpu+0x48/0x320
> [ 70.089250] handle_irq_event_percpu+0x32/0x80
> [ 70.095505] handle_irq_event+0x39/0x60
> [ 70.101157] handle_level_irq+0x7f/0x100
> [ 70.106893] handle_irq+0x6f/0x110
> [ 70.112112] do_IRQ+0x5c/0x110
> [ 70.116982] ret_from_intr+0x0/0x1d
> [ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
> [ 70.128891] __setup_irq+0x45d/0x700
> [ 70.134281] setup_irq+0x4c/0x90
> [ 70.139324] hpet_time_init+0x25/0x37
> [ 70.144803] x86_late_time_init+0xf/0x1c
> [ 70.150538] start_kernel+0x40c/0x4ca
> [ 70.156017] x86_64_start_reservations+0x24/0x26
> [ 70.162445] x86_64_start_kernel+0x6f/0x72
> [ 70.168357] secondary_startup_64+0xa4/0xb0
> [ 70.174356] IN-SOFTIRQ-W at:
> [ 70.177578] lock_acquire+0xd5/0x1c0
> [ 70.182970] _raw_spin_lock+0x2f/0x40
> [ 70.188448] try_to_wake_up+0x31b/0x540
> [ 70.194097] wake_up_process+0x15/0x20
> [ 70.199661] swake_up_locked+0x24/0x40
> [ 70.205226] swake_up_one+0x1f/0x30
> [ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
> [ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
> [ 70.223048] rcu_process_callbacks+0x111/0x10c0
> [ 70.229396] __do_softirq+0xbf/0x493
> [ 70.234788] irq_exit+0xc3/0xd0
> [ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
> [ 70.246176] apic_timer_interrupt+0xf/0x20
> [ 70.252084] console_unlock+0x4e8/0x620
> [ 70.257737] vprintk_emit+0x254/0x430
> [ 70.263214] vprintk_default+0x1f/0x30
> [ 70.268776] vprintk_func+0x27/0x60
> [ 70.274082] printk+0x52/0x6e
> [ 70.278864] native_cpu_up+0x71b/0x7a0
> [ 70.284431] bringup_cpu+0x2a/0xb0
> [ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
> [ 70.295818] _cpu_up+0xae/0x160
> [ 70.300776] do_cpu_up+0x8d/0xb0
> [ 70.305818] cpu_up+0x13/0x20
> [ 70.310602] smp_init+0x67/0xc4
> [ 70.315559] kernel_init_freeable+0x134/0x259
> [ 70.321731] kernel_init+0xe/0x110
> [ 70.326947] ret_from_fork+0x3a/0x50
> [ 70.332339] INITIAL USE at:
> [ 70.335477] lock_acquire+0xd5/0x1c0
> [ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
> [ 70.346864] rq_attach_root+0x1b/0xc0
> [ 70.352255] sched_init+0x310/0x432
> [ 70.357472] start_kernel+0x26e/0x4ca
> [ 70.362861] x86_64_start_reservations+0x24/0x26
> [ 70.369207] x86_64_start_kernel+0x6f/0x72
> [ 70.375048] secondary_startup_64+0xa4/0xb0
> [ 70.380958] }
> [ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
> [ 70.389310] ... acquired at:
> [ 70.392364] _raw_spin_lock+0x2f/0x40
> [ 70.396192] pcpu_freelist_pop+0x7a/0xd0
> [ 70.400286] bpf_get_stackid+0x1ca/0x470
> [ 70.404383] bpf_get_stackid_tp+0x11/0x20
> [ 70.408559] ___bpf_prog_run+0x7f2/0x1090
> [ 70.412739] __bpf_prog_run32+0x39/0x50
> [ 70.416742] trace_call_bpf+0xc8/0x1d0
> [ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
> [ 70.425444] perf_trace_sched_switch+0x116/0x190
> [ 70.430227] __schedule+0x6d8/0xa20
> [ 70.433883] schedule+0x3d/0x90
> [ 70.437194] worker_thread+0xd0/0x410
> [ 70.441025] kthread+0x10d/0x140
> [ 70.444424] ret_from_fork+0x3a/0x50
> [ 70.448165]
> [ 70.449658] -> (&head->lock){+...} ops: 61660 {
> [ 70.454181] HARDIRQ-ON-W at:
> [ 70.457319] lock_acquire+0xd5/0x1c0
> [ 70.462536] _raw_spin_lock+0x2f/0x40
> [ 70.467841] pcpu_freelist_push+0x28/0x50
> [ 70.473492] bpf_get_stackid+0x43a/0x470
> [ 70.479054] bpf_get_stackid_tp+0x11/0x20
> [ 70.484724] ___bpf_prog_run+0x7f2/0x1090
> [ 70.490372] __bpf_prog_run32+0x39/0x50
> [ 70.495852] trace_call_bpf+0xc8/0x1d0
> [ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
> [ 70.507500] perf_trace_urandom_read+0xbf/0x100
> [ 70.513670] urandom_read+0x1ce/0x340
> [ 70.518975] __vfs_read+0x37/0x160
> [ 70.524027] vfs_read+0xa8/0x150
> [ 70.528898] ksys_read+0x58/0xc0
> [ 70.533766] __x64_sys_read+0x1a/0x20
> [ 70.539092] do_syscall_64+0x4f/0x190
> [ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 70.551092] INITIAL USE at:
> [ 70.554143] lock_acquire+0xd5/0x1c0
> [ 70.559272] _raw_spin_lock+0x2f/0x40
> [ 70.564491] pcpu_freelist_populate+0xb6/0x110
> [ 70.570489] htab_map_alloc+0x3b6/0x4c0
> [ 70.575878] map_create+0xf0/0x370
> [ 70.580836] __x64_sys_bpf+0x10b/0x260
> [ 70.586138] do_syscall_64+0x4f/0x190
> [ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 70.597960] }
> [ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
> [ 70.606142] ... acquired at:
> [ 70.609104] mark_lock+0x392/0x570
> [ 70.612676] __lock_acquire+0x5cd/0x13c0
> [ 70.616767] lock_acquire+0xd5/0x1c0
> [ 70.620511] _raw_spin_lock+0x2f/0x40
> [ 70.624342] pcpu_freelist_push+0x28/0x50
> [ 70.628519] bpf_get_stackid+0x43a/0x470
> [ 70.632610] bpf_get_stackid_tp+0x11/0x20
> [ 70.636785] ___bpf_prog_run+0x7f2/0x1090
> [ 70.640965] __bpf_prog_run32+0x39/0x50
> [ 70.644969] trace_call_bpf+0xc8/0x1d0
> [ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
> [ 70.653668] perf_trace_urandom_read+0xbf/0x100
> [ 70.658366] urandom_read+0x1ce/0x340
> [ 70.662199] __vfs_read+0x37/0x160
> [ 70.665768] vfs_read+0xa8/0x150
> [ 70.669166] ksys_read+0x58/0xc0
> [ 70.672562] __x64_sys_read+0x1a/0x20
> [ 70.676393] do_syscall_64+0x4f/0x190
> [ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 70.685440]
> [ 70.686933]
> [ 70.686933] stack backtrace:
> [ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
> [ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 70.705875] Call Trace:
> [ 70.708321] dump_stack+0x68/0x95
> [ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
> [ 70.716935] check_usage_backwards+0x14b/0x160
> [ 70.721374] mark_lock+0x392/0x570
> [ 70.724771] ? mark_lock+0x392/0x570
> [ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
> [ 70.733904] __lock_acquire+0x5cd/0x13c0
> [ 70.737823] ? find_get_entry+0x1a2/0x2f0
> [ 70.741825] lock_acquire+0xd5/0x1c0
> [ 70.745397] ? lock_acquire+0xd5/0x1c0
> [ 70.749141] ? pcpu_freelist_push+0x28/0x50
> [ 70.753317] _raw_spin_lock+0x2f/0x40
> [ 70.756974] ? pcpu_freelist_push+0x28/0x50
> [ 70.761153] pcpu_freelist_push+0x28/0x50
> [ 70.765156] bpf_get_stackid+0x43a/0x470
> [ 70.769073] bpf_get_stackid_tp+0x11/0x20
> [ 70.773077] ___bpf_prog_run+0x7f2/0x1090
> [ 70.777083] __bpf_prog_run32+0x39/0x50
> [ 70.780912] ? lock_acquire+0xd5/0x1c0
> [ 70.784656] trace_call_bpf+0xc8/0x1d0
> [ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
> [ 70.793013] perf_trace_urandom_read+0xbf/0x100
> [ 70.797544] urandom_read+0x1ce/0x340
> [ 70.801202] __vfs_read+0x37/0x160
> [ 70.804598] ? security_file_permission+0x8d/0xb0
> [ 70.809297] ? security_file_permission+0x8d/0xb0
> [ 70.813993] vfs_read+0xa8/0x150
> [ 70.817218] ksys_read+0x58/0xc0
> [ 70.820442] __x64_sys_read+0x1a/0x20
> [ 70.824106] do_syscall_64+0x4f/0x190
> [ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 70.832807] RIP: 0033:0x7f302526f160
> [ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
> 66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
> 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
> 04 24
> [ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000000
> [ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
> [ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
> [ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
> [ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
> [ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
> e 54
> test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
>
> Full kernel selftest test log,
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkft.validation.linaro.org_scheduler_job_314724-23L2142&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=VQnoQ7LvghIj0gVEaiQSUw&m=jZ-W3Sa5-4fLxWPWxGZCwCp8KROtodYFS8Hz01vayqc&s=N9XPdzKisD7r4k5e94WLyeOinbQRUkmhBtNx6Fj4jhQ&e=
>
> Best regards
> Naresh Kamboju
^ permalink raw reply
* Re: [PATCH v1 0/4] PCI: Remove unnecessary includes of <linux/pci-aspm.h>
From: Sinan Kaya @ 2018-07-25 20:33 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA
Cc: Jeff Kirsher, David S. Miller, Kalle Valo, Johannes Berg,
Emmanuel Grumbach, Luca Coelho,
ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw,
linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <153254813164.92573.10755585465477668768.stgit-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On 7/25/2018 12:52 PM, Bjorn Helgaas wrote:
> emove includes of <linux/pci-aspm.h> from files that don't need
> it. I'll apply all these via the PCI tree unless there's objection.
>
> ---
>
> Bjorn Helgaas (4):
> igb: Remove unnecessary include of <linux/pci-aspm.h>
> ath9k: Remove unnecessary include of <linux/pci-aspm.h>
> iwlwifi: Remove unnecessary include of <linux/pci-aspm.h>
> PCI: Remove unnecessary include of <linux/pci-aspm.h>
Thanks.
Reviewed-by: Sinan Kaya <okaya-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Is it possible to kill that file altogether? I haven't looked who is
using outside of pci directory.
^ 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