* Re: [PATCH] tcp: do not update snd_una if it is same with ack_seq
From: Joe Perches @ 2018-11-03 17:04 UTC (permalink / raw)
To: Yafang Shao, davem, edumazet; +Cc: netdev, linux-kernel
In-Reply-To: <1541264071-9905-1-git-send-email-laoar.shao@gmail.com>
On Sun, 2018-11-04 at 00:54 +0800, Yafang Shao wrote:
> In the slow path, TCP_SKB_SB(skb)->ack_seq may be same with tp->snd_una,
> and under this condition we don't need to update the snd_una.
>
> Furthermore, tcp_ack_update_window() is only called in slow path,
> so introducing this check won't affect the fast path processing.
[]
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
[]
> @@ -3610,7 +3611,7 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
> if (flag & FLAG_UPDATE_TS_RECENT)
> tcp_replace_ts_recent(tp, TCP_SKB_CB(skb)->seq);
>
> - if (!(flag & FLAG_SLOWPATH) && after(ack, prior_snd_una)) {
> + if (!(flag & FLAG_SLOWPATH) && flag & FLAG_SND_UNA_ADVANCED) {
stylistic nit:
While the precedence is correct in any case,
perhaps adding parentheses around
flag & FLAG_SND_UNA_ADVANCED
would make it more obvious.
^ permalink raw reply
* Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
From: Masami Hiramatsu @ 2018-11-04 2:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Josh Poimboeuf, Aleksa Sarai, Naveen N. Rao, Anil S Keshavamurthy,
David S. Miller, Jonathan Corbet, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Brendan Gregg, Christian Brauner, Aleksa Sarai, netdev, linux-doc
In-Reply-To: <20181103133021.6676708c@vmware.local.home>
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sun, 4 Nov 2018 01:34:30 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > > I was thinking of a bitmask that represents the handlers, and use that
> > > to map which handler gets called for which shadow entry for a
> > > particular task.
> >
> > Hmm, I doubt that is too complicated and not scalable. I rather like to see
> > the open shadow entry...
>
> It can scale and not too complex (I already played a little with it).
> But that said, I'm not committed to it, and using the shadow stack is
> also an interesting idea.
>
> >
> > entry: [[original_retaddr][function][modified_retaddr]]
> >
> > So if there are many users on same function, the entries will be like this
> >
> > [[original_return_address][function][trampoline_A]]
> > [[trampline_A][function][trampoline_B]]
> > [[trampline_B][function][trampoline_C]]
> >
> > And on the top of the stack, there is trampline_C instead of original_return_address.
> > In this case, return to trampoline_C(), it jumps back to trampline_B() and then
> > it jumps back to trampline_A(). And eventually it jumps back to
> > original_return_address.
>
> Where are trampolines A, B, and C made? Do we also need to dynamically
> create them? If I register multiple function tracing ones, each one
> will need its own trampoline?
>
No, I think tramplines are very limited. currently we will only have ftrace
and kretprobe trampolines.
> > This way, we don't need allocate another bitmap/pages for the shadow stack.
> > We only need a shadow stack for each task.
> > Also, unwinder can easily find the trampline_C from the shadow stack and restores
> > original_return_address. (of course trampline_A,B,C must be registered so that
> > search function can skip it.)
>
> What I was thinking was to store a count and the functions to be called:
>
>
> [original_return_address]
> [function_A]
> [function_B]
> [function_C]
> [ 3 ]
>
> Then the trampoline that processes the return codes for ftrace (and
> kretprobes and everyone else) can simply do:
>
> count = pop_shadow_stack();
> for (i = 0; i < count; i++) {
> func = pop_shadow_stack();
> func(...);
> }
> return_address = pop_shadow_stack();
Ah, that's a good idea. I think we also have to store the called function
entry address with the number header, but basically I agree with you.
If we have a space to store a data with the function address, that is also
good to kretprobe. systemtap heavily uses "entry data" for saving some data
at function entry for exit handler.
> That way we only need to register a function to the return handler and
> it will be called, without worrying about making trampolines. There
> will just be a single trampoline that handles all the work.
OK, and could you make it independent from func graph tracer, so that
CONFIG_KPROBES=y but CONFIG_FUNCTION_GRAPH_TRACER=n kernel can support
kretprobes too.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] openvswitch: fix linking without CONFIG_NF_CONNTRACK_LABELS
From: David Miller @ 2018-11-04 2:29 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: dev-yBygre7rU0TnMu66kgdUjQ,
eswierk-FilZDy9cOaHkQYj/0HfcvtBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA, fw-HFFVJYpyMKqzQB+pC5nmwQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Julia.Lawall-L2FTfq7BK8M,
gfree.wind-GveOkT2v/s5BDgjK7y7TUQ, thierry-EDrxZYgYwg/bB1ukUYwELw,
fbl-H+wXaHxf7aLQT0dZR+AlfA, pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <20181102153705.1664786-1-arnd-r2nGTMty4D4@public.gmane.org>
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Date: Fri, 2 Nov 2018 16:36:55 +0100
> When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler
> fails to optimize out a dead code path, which leads to a link failure:
>
> net/openvswitch/conntrack.o: In function `ovs_ct_set_labels':
> conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace'
>
> In this configuration, we can take a shortcut, and completely
> remove the contrack label code. This may also help the regular
> optimization.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Applied, thanks Arnd.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: David Ahern @ 2018-11-03 17:32 UTC (permalink / raw)
To: Paweł Staszewski, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <a63df254-3791-cd5c-ddfc-6c9b8d38c559@itcare.pl>
On 11/1/18 11:30 AM, Paweł Staszewski wrote:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/xdp_fwd_kern.c
>>>>
>>>>
>>> I can try some tests on same hw but testlab configuration - will give it
>>> a try :)
>>>
>> That version does not work with VLANs. I have patches for it but it
>> needs a bit more work before sending out. Perhaps I can get back to it
>> next week.
>>
> Will be nice - next week i will be able to replace network controller
> and install separate two 100Gbit nics into two pciex x16 slots - so can
> test without hitting pcie bandwidth limits.
>
>
Does your setup have any other device types besides physical ports with
VLANs (e.g., any macvlans or bonds)?
^ permalink raw reply
* Re: [PATCH net 0/6] s390/qeth: fixes 2018-11-02
From: David Miller @ 2018-11-03 17:44 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20181102180413.53020-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 2 Nov 2018 19:04:07 +0100
> please apply one round of qeth fixes for -net.
>
> Patch 1 is rather large and removes a use-after-free hazard from many of our
> debug trace entries.
> Patch 2 is yet another fix-up for the L3 subdriver's new IP address management
> code.
> Patch 3 and 4 resolve some fallout from the recent changes wrt how/when qeth
> allocates its net_device.
> Patch 5 makes sure we don't set reserved bits when building HW commands from
> user-provided data.
> And finally, patch 6 allows ethtool to play nice with new HW.
Series applied.
^ permalink raw reply
* Re: [PATCH v2] libertas: return errno from lbs_add_card()
From: Pavel Machek @ 2018-11-03 19:43 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Kalle Valo, David S. Miller, libertas-dev, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20181007003327.2806010-1-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
On Sun 2018-10-07 02:33:27, Lubomir Rintel wrote:
> This makes the error handling somewhat cleaner -- lbs_add_card() does no
> logner throw away the errno and lets its callers propagate it.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net 0/3] net: bql: better deal with GSO
From: David Miller @ 2018-11-03 22:40 UTC (permalink / raw)
To: edumazet; +Cc: netdev, tariqt, willemb, eric.dumazet
In-Reply-To: <20181031153914.132127-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 31 Oct 2018 08:39:11 -0700
> While BQL bulk dequeue works well for TSO packets, it is
> not very efficient as soon as GSO is involved.
>
> On a GSO only workload (UDP or TCP), this patch series
> can save about 8 % of cpu cycles on a 40Gbit mlx4 NIC,
> by keeping optimal batching, and avoiding expensive
> doorbells, qdisc requeues and reschedules.
>
> This patch series :
>
> - Add __netdev_tx_sent_queue() so that drivers
> can implement efficient BQL and xmit_more support.
>
> - Implement a work around in dev_hard_start_xmit()
> for drivers not using __netdev_tx_sent_queue()
>
> - changes mlx4 to use __netdev_tx_sent_queue()
>
> v2: Tariq and Willem feedback addressed.
> added __netdev_tx_sent_queue() (Willem suggestion)
Series applied, but I wonder how many other commonly used drivers we
should update the same way mlx4 is here?
^ permalink raw reply
* Re: [PATCH net] net: hns3: Fix for out-of-bounds access when setting pfc back pressure
From: David Miller @ 2018-11-03 22:42 UTC (permalink / raw)
To: linyunsheng
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, john.garry, linuxarm,
salil.mehta, lipeng321, netdev, linux-kernel
In-Reply-To: <1541074363-98630-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Thu, 1 Nov 2018 20:12:43 +0800
> The vport should be initialized to hdev->vport for each bp group,
> otherwise it will cause out-of-bounds access and bp setting not
> correct problem.
...
> Fixes: 67bf2541f4b9 ("net: hns3: Fixes the back pressure setting when sriov is enabled")
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net 0/3] net: bql: better deal with GSO
From: Eric Dumazet @ 2018-11-03 23:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tariq Toukan, Willem de Bruijn, Eric Dumazet
In-Reply-To: <20181103.154028.1864906755289829872.davem@davemloft.net>
On Sat, Nov 3, 2018 at 3:40 PM David Miller <davem@davemloft.net> wrote:
> Series applied, but I wonder how many other commonly used drivers we
> should update the same way mlx4 is here?
I can provide patches but can not test them, so probably we should get
Tested-by tags before applying them.
Thanks.
^ permalink raw reply
* [PATCH] e1000e: Change watchdog task to be delayed work
From: Robert Eshleman @ 2018-11-04 0:17 UTC (permalink / raw)
Cc: Robert Eshleman, Jeff Kirsher, David S. Miller, intel-wired-lan,
netdev, linux-kernel
This completes a pending TODO to use queue_delayed_work() instead of
schedule_work().
Signed-off-by: Robert Eshleman <bobbyeshleman@gmail.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 16a73bd..a387b21 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -39,6 +39,8 @@ static int debug = -1;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+struct workqueue_struct *e1000e_workqueue;
+
static const struct e1000_info *e1000_info_tbl[] = {
[board_82571] = &e1000_82571_info,
[board_82572] = &e1000_82572_info,
@@ -5137,9 +5139,9 @@ static void e1000_watchdog(struct timer_list *t)
struct e1000_adapter *adapter = from_timer(adapter, t, watchdog_timer);
/* Do the rest outside of interrupt context */
- schedule_work(&adapter->watchdog_task);
+ struct delayed_work *dwork = to_delayed_work(&adapter->watchdog_task);
- /* TODO: make this use queue_delayed_work() */
+ queue_delayed_work(e1000e_workqueue, dwork, 1);
}
static void e1000_watchdog_task(struct work_struct *work)
@@ -7572,6 +7574,13 @@ static int __init e1000_init_module(void)
e1000e_driver_version);
pr_info("Copyright(c) 1999 - 2015 Intel Corporation.\n");
+ e1000e_workqueue = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0,
+ e1000e_driver_name);
+ if (!e1000e_workqueue) {
+ pr_err("%s: Failed to create workqueue\n", e1000e_driver_name);
+ return -ENOMEM;
+ }
+
return pci_register_driver(&e1000_driver);
}
module_init(e1000_init_module);
@@ -7585,6 +7594,7 @@ module_init(e1000_init_module);
static void __exit e1000_exit_module(void)
{
pci_unregister_driver(&e1000_driver);
+ destroy_workqueue(e1000e_workqueue);
}
module_exit(e1000_exit_module);
--
2.7.4
^ permalink raw reply related
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-04 0:24 UTC (permalink / raw)
To: David Ahern, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <f6188534-38d7-fc3e-189d-443a76bcb47d@gmail.com>
n
W dniu 03.11.2018 o 18:32, David Ahern pisze:
> On 11/1/18 11:30 AM, Paweł Staszewski wrote:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/xdp_fwd_kern.c
>>>>>
>>>>>
>>>> I can try some tests on same hw but testlab configuration - will give it
>>>> a try :)
>>>>
>>> That version does not work with VLANs. I have patches for it but it
>>> needs a bit more work before sending out. Perhaps I can get back to it
>>> next week.
>>>
>> Will be nice - next week i will be able to replace network controller
>> and install separate two 100Gbit nics into two pciex x16 slots - so can
>> test without hitting pcie bandwidth limits.
>>
>>
> Does your setup have any other device types besides physical ports with
> VLANs (e.g., any macvlans or bonds)?
>
>
no.
just
phy(mlnx)->vlans only config
And today again after allpy patch for page allocator - reached again
64/64 Gbit/s
with only 50-60% cpu load
today no slowpath hit for netwoking :)
But again dropped pckt at 64GbitRX and 64TX ....
And as it should not be pcie express limit -i think something more is
going on there - and hard to catch - cause perf top doestn chenged
besides there is no queued slowpath hit now
I ordered now also intel cards to compare - but 3 weeks eta
Faster - cause 3 days - i will have mellanox connectx 5 - so can
separate traffic to two different x16 pcie busses
^ permalink raw reply
* Re: [PATCH v2 net 0/3] net: bql: better deal with GSO
From: David Miller @ 2018-11-04 0:26 UTC (permalink / raw)
To: edumazet; +Cc: netdev, tariqt, willemb, eric.dumazet
In-Reply-To: <CANn89iLJcc4o7ftTL3Sb0GEd3tYvexKn-tHyDWzqEo2Pk1ECRA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 3 Nov 2018 16:00:39 -0700
> On Sat, Nov 3, 2018 at 3:40 PM David Miller <davem@davemloft.net> wrote:
>
>> Series applied, but I wonder how many other commonly used drivers we
>> should update the same way mlx4 is here?
>
> I can provide patches but can not test them, so probably we should get
> Tested-by tags before applying them.
Ok, agreed.
^ permalink raw reply
* Re: pull-request: bpf 2018-11-03
From: David Miller @ 2018-11-04 2:34 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20181103004703.6007-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 3 Nov 2018 01:47:03 +0100
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix BPF prog kallsyms and bpf_prog_get_info_by_fd() jited address export
> to not use page start but actual start instead to work correctly with
> profiling e.g. finding hot instructions from stack traces. Also fix latter
> with regards to dumping address and jited len for !multi prog, from Song.
>
> 2) Fix bpf_prog_get_info_by_fd() for !root to zero info.nr_jited_func_lens
> instead of leaving the user provided length, from Daniel.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [RFC PATCH] net/mlx5e: Temp software stats variable is not required
From: David Miller @ 2018-11-04 2:36 UTC (permalink / raw)
To: saeedm; +Cc: netdev, arnd, akpm, jgg, eric.dumazet, eranbe, leonro
In-Reply-To: <20181103015422.22978-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 2 Nov 2018 18:54:22 -0700
> +static void mlx5e_fold_sw_stats(struct mlx5e_priv *priv, struct rtnl_link_stats64 *s)
> +{
> + int i;
> +
> + /* not required ? */
> + memset(s, 0, sizeof(*s));
Why wouldn't this be required?
I can see that perhaps you can only zero out the statistics that are used in
the ndo_get_stats64() code path, but that's different.
^ permalink raw reply
* Re: [PATCH] qed: fix link config error handling
From: David Miller @ 2018-11-04 2:27 UTC (permalink / raw)
To: arnd
Cc: Ariel.Elior, everest-linux-l2, sudarsana.kalluru, Tomer.Tayar,
denis.bolotin, Rahul.Verma, netdev, linux-kernel
In-Reply-To: <20181102153632.1646632-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 2 Nov 2018 16:36:24 +0100
> gcc-8 notices that qed_mcp_get_transceiver_data() may fail to
> return a result to the caller:
>
> drivers/net/ethernet/qlogic/qed/qed_mcp.c: In function 'qed_mcp_trans_speed_mask':
> drivers/net/ethernet/qlogic/qed/qed_mcp.c:1955:2: error: 'transceiver_type' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> When an error is returned by qed_mcp_get_transceiver_data(), we
> should propagate that to the caller of qed_mcp_trans_speed_mask()
> rather than continuing with uninitialized data.
>
> Fixes: c56a8be7e7aa ("qed: Add supported link and advertise link to display in ethtool.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net-sysfs: fix formatting of tx_timeout attribute
From: David Miller @ 2018-11-04 2:31 UTC (permalink / raw)
To: jwi; +Cc: netdev
In-Reply-To: <20181102183317.2017-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 2 Nov 2018 19:33:17 +0100
> Add a missing newline.
>
> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
> ---
> net/core/net-sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index bd67c4d0fcfd..ef06409d768e 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -1039,7 +1039,7 @@ static ssize_t tx_timeout_show(struct netdev_queue *queue, char *buf)
> trans_timeout = queue->trans_timeout;
> spin_unlock_irq(&queue->_xmit_lock);
>
> - return sprintf(buf, "%lu", trans_timeout);
> + return sprintf(buf, "%lu\n", trans_timeout);
Maybe use 'fmt_ulong' instead?
^ permalink raw reply
* Re: [PATCH net] sctp: fix strchange_flags name for Stream Change Event
From: David Miller @ 2018-11-04 2:39 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <34b8e0475a841d258c2165b5a46a72c373e52976.1541224785.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 3 Nov 2018 13:59:45 +0800
> As defined in rfc6525#section-6.1.3, SCTP_STREAM_CHANGE_DENIED
> and SCTP_STREAM_CHANGE_FAILED should be used instead of
> SCTP_ASSOC_CHANGE_DENIED and SCTP_ASSOC_CHANGE_FAILED.
>
> To keep the compatibility, fix it by adding two macros.
>
> Fixes: b444153fb5a6 ("sctp: add support for generating add stream change event notification")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] sctp: define SCTP_SS_DEFAULT for Stream schedulers
From: David Miller @ 2018-11-04 2:41 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <4986625e9c58cccdfbb6c809a82c77a83b57a541.1541224891.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 3 Nov 2018 14:01:31 +0800
> According to rfc8260#section-4.3.2, SCTP_SS_DEFAULT is required to
> defined as SCTP_SS_FCFS or SCTP_SS_RR.
>
> SCTP_SS_FCFS is used for SCTP_SS_DEFAULT's value in this patch.
>
> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Also applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum: Fix IP2ME CPU policer configuration
From: David Miller @ 2018-11-04 2:32 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, shalomt, mlxsw
In-Reply-To: <20181102194840.31107-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Fri, 2 Nov 2018 19:49:15 +0000
> From: Shalom Toledo <shalomt@mellanox.com>
>
> The CPU policer used to police packets being trapped via a local route
> (IP2ME) was incorrectly configured to police based on bytes per second
> instead of packets per second.
>
> Change the policer to police based on packets per second and avoid
> packet loss under certain circumstances.
>
> Fixes: 9148e7cf73ce ("mlxsw: spectrum: Add policers for trap groups")
> Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Update
From: Dr Kannan @ 2018-11-03 16:26 UTC (permalink / raw)
To: Recipients
Hello dear
Greetings to you,I am Dr.Kannan, a personal account manager to Late Engr. Richard Hernandez, who died with his family in the missing Malaysian Air crash
of 2014. His account with us is in intestate with no claim his fixed deposit of U$D 7 Million.
I have been mandated by the Bank Management as his personal account officer, to present his relative or next of kin.
I have searched through notary register of his country here all to no avail, so I wish to present you to the Bank as his only relative and next of kin.
kindly contact me for more details, terms and condition shall be clarified upon your response. There is no risk whatsoever to this transaction as I have all papers and documents to pose of you the inheritance to this.
I wait for your prompt response.
My regards,
Dr. Kannan.
^ permalink raw reply
* Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
From: Aleksa Sarai @ 2018-11-04 11:59 UTC (permalink / raw)
To: Steven Rostedt
Cc: Naveen N. Rao, Anil S Keshavamurthy, David S. Miller,
Masami Hiramatsu, Jonathan Corbet, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Brendan Gregg, Christian Brauner, Aleksa Sarai, netdev, linux-doc,
linux-kernel
In-Reply-To: <20181103070253.ajrqzs5xu2vf5stu@yavin>
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On 2018-11-03, Aleksa Sarai <cyphar@cyphar.com> wrote:
> This is actually a general bug in ftrace as well, because (for
> instance) while the unwinder calls into ftrace_graph_ret_addr() while
> walking up the stack this isn't used to correct regs->ip in
> perf_callchain_kernel(). I think this is the cause of the bug in
> ftrace-graph (if you switch to the "frame" unwinder you might be able
> to see it more clearly) -- but when trying to fix it I'm having
> trouble figuring out what retp should be (stack_addr(regs) doesn't
> give the right result for some reason).
@Steven, @Masami: Can you verify whether this is an actual bug? The
snippet is like (arch/x86/events/core.c):
void
perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)
{
/* ... */
if (perf_callchain_store(entry, regs->ip))
return;
/* rest of unwind code */
}
And it seems to me that there's an ftrace_graph_ret_addr missing here
(though I was having trouble figuring out what the right retp would be
in this context -- both stack_addr(regs) and ®s->sp appear to be
wrong when I was trying to get this to work with kretprobes -- while my
patch worked with all other kretprobe_trampoline cases in the unwinder).
The same issue is present in __save_stack_trace
(arch/x86/kernel/stacktrace.c). This is likely the only reason that --
as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
with the refactor both of you are discussing).
Thanks.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-11-04 5:43 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <973f5f0e-fc25-7a99-70b5-3b53f7c69fca@tomt.net>
On 31.10.2018 05:08, Andre Tomt wrote:
> On 30.10.2018 12:04, Andre Tomt wrote:
>> On 30.10.2018 11:58, Andre Tomt wrote:
>>> On 27.10.2018 23:41, Andre Tomt wrote:
>>>> On 26.10.2018 13:45, Andre Tomt wrote:
>>>>> On 25.10.2018 19:38, Eric Dumazet wrote:
>>>>>>
>>>>>>
>>>>>> On 10/24/2018 12:41 PM, Andre Tomt wrote:
>>>>>>>
>>>>>>> It eventually showed up again with mlx4, on 4.18.16 + fix and
>>>>>>> also on 4.19. I still do not have a useful packet capture.
>>>>>>>
>>>>>>> It is running a torrent client serving up various linux
>>>>>>> distributions.
>>>>>>>
>>>>>>
>>>>>> Have you also applied this fix ?
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
>>>>>>
>>>>>>
>>>>>
>>>>> No. I've applied it now to 4.19 and will report back if anything
>>>>> shows up.
>>>>
>>>> Just hit it on the simpler server; no VRF, no tunnels, no
>>>> nat/conntrack. Only a basic stateless nftables ruleset and a vlan
>>>> netdev (unlikely to be the one triggering this I guess; it has only
>>>> v4 traffic).
>>>
>>> I'm currently testing 4.19 with the recomended commit added, plus
>>> these to sort out some GRO issues (on a hunch, unsure if related):
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=a8305bff685252e80b7c60f4f5e7dd2e63e38218
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=992cba7e276d438ac8b0a8c17b147b37c8c286f7
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=ece23711dd956cd5053c9cb03e9fe0668f9c8894
>>>
>>>
>>> and I *think* it is behaving better now? it's not conclusive as it
>>> could take a while to trip in this environment but some of the test
>>> servers have not shown anything bad in almost 24h.
>>
>> Sorry, s/some of the/none of the
>
> I think it is fairly safe to say 4.19 + mlx4 + these 4 commits is OK. At
> least for my workload. Servers are now 51-61 hours in, no splats. I also
> added ntp pool traffic to one of them to make things a little more
> exciting.
>
> Not sure what is needed for 4.18, I dont have the mental bandwidth to
> test that right now. Also no idea about the similar looking mlx5 splats
> reported elsewhere.
As expected conntrack/nat + vlan + forwarding still splats.
sch_cake, IFB and VRF was removed from this setup.
Here is a conntrack splat without IFB/VRF/Cake inteference:
> [34458.506346] wanib: hw csum failure
> [34458.506371] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-1 #1
> [34458.506374] Hardware name: Supermicro Super Server/X10SDV-4C-TLN2F, BIOS 2.0 06/13/2018
> [34458.506377] Call Trace:
> [34458.506381] <IRQ>
> [34458.506388] dump_stack+0x5c/0x80
> [34458.506392] __skb_checksum_complete+0xac/0xc0
> [34458.506402] icmp_error+0x1c8/0x1f0 [nf_conntrack]
> [34458.506406] ? skb_copy_bits+0x13d/0x220
> [34458.506411] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
> [34458.506416] ? ___pskb_trim+0x192/0x330
> [34458.506421] nf_hook_slow+0x43/0xc0
> [34458.506426] ip_rcv+0x90/0xb0
> [34458.506430] ? ip_rcv_finish_core.isra.0+0x310/0x310
> [34458.506435] __netif_receive_skb_one_core+0x42/0x50
> [34458.506438] netif_receive_skb_internal+0x24/0xb0
> [34458.506441] napi_gro_frags+0x177/0x210
> [34458.506446] mlx4_en_process_rx_cq+0x8df/0xb50 [mlx4_en]
> [34458.506459] ? mlx4_eq_int+0x38f/0xcb0 [mlx4_core]
> [34458.506463] mlx4_en_poll_rx_cq+0x55/0xf0 [mlx4_en]
> [34458.506466] net_rx_action+0xe1/0x2c0
> [34458.506469] __do_softirq+0xe7/0x2d3
> [34458.506475] irq_exit+0x96/0xd0
> [34458.506478] do_IRQ+0x85/0xd0
> [34458.506483] common_interrupt+0xf/0xf
> [34458.506486] </IRQ>
> [34458.506491] RIP: 0010:cpuidle_enter_state+0xb9/0x320
> [34458.506495] Code: e8 3c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 5e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
> [34458.506497] RSP: 0018:ffff978d41943ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
> [34458.506500] RAX: ffff8d8f6fa60fc0 RBX: 00001f56ff07af28 RCX: 000000000000001f
> [34458.506501] RDX: 00001f56ff07af28 RSI: 000000003a2e90d6 RDI: 0000000000000000
> [34458.506503] RBP: ffff8d8f6fa698c0 R08: 0000000000000002 R09: 0000000000020840
> [34458.506504] R10: 0004ea58f2899595 R11: ffff8d8f6fa601e8 R12: 0000000000000001
> [34458.506505] R13: ffffffff8a0ac638 R14: 0000000000000001 R15: 0000000000000000
> [34458.506509] ? cpuidle_enter_state+0x94/0x320
> [34458.506512] do_idle+0x1e4/0x220
> [34458.506515] cpu_startup_entry+0x5f/0x70
> [34458.506519] start_secondary+0x185/0x1a0
> [34458.506521] secondary_startup_64+0xa4/0xb0
Stateless filtered non-forwarding host still looks like it has been
fixed (the udp6_gro_* splats are still all gone). Also seems fine when
moving the traffic over a vlan device. These fixes went into 4.19.1-rc1
(checksum_complete + unlink gro packets on overflow fixes)
^ permalink raw reply
* may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Toralf Förster @ 2018-11-04 16:14 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel
compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
net/core/rtnetlink.c: In function ‘rtnl_newlink’:
net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
--
Toralf
PGP C4EACDDE 0076E94E
^ permalink raw reply
* Re: may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Joe Perches @ 2018-11-04 17:15 UTC (permalink / raw)
To: Toralf Förster, netdev, Kees Cook; +Cc: Linux Kernel
In-Reply-To: <0cfb892c-b358-4bd6-f7c9-071a0039bc71@gmx.de>
On Sun, 2018-11-04 at 17:14 +0100, Toralf Förster wrote:
> compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
>
>
> net/core/rtnetlink.c: In function ‘rtnl_newlink’:
> net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
>
> with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
>
This was introduce by a desire to eliminate variable length array
declarations by
commit ccf8dbcd062a930e64741c939ca784d15316aa0c
Author: Kees Cook <
keescook@chromium.org>
Date: Wed May 30 15:20:52 2018 -0700
rtnetlink: Remove VLA usage
It does make the stack use here unfortunately obviously large, but
it could have been this large, just unreported.
Perhaps no obvious solution here as an alloc instead of stack use
may be costly.
^ permalink raw reply
* Re: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Shawn Guo @ 2018-11-04 8:45 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Andrew Lunn, Florian Fainelli, Leo Li, netdev@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <HE1PR0402MB3323371C130088B2A26F1627F1F60@HE1PR0402MB3323.eurprd04.prod.outlook.com>
On Wed, Oct 24, 2018 at 01:18:32PM +0000, Pankaj Bansal wrote:
> Hi All,
>
> As per the device tree ePappr https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
> section 2.2.1
>
> Each node in the device tree is named according to the following convention:
> node-name@unit-address
>
> The node-name shall start with a lower or uppercase character and should describe the general class of device.
> The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree.
>
> I am having a hard time following this convention when defining mdio-mux nodes for LX2160AQDS.
> The mdio-mux in LX2160AQDS is controlled by same register in fpga. Only some bits are different for the two buses' mux.
> How to differentiate between the node names for two buses' muxes?
>
> For now I have made their names as mdio-mux@54_f8 and mdio-mux@54_07.
> The first number is register address and second number indicates the bit mask that is used to select the bits from that register for a bus.
No. DTC will report warnings against that, because unit-address has to
match 'reg' property. I would suggest mdio-mux-1@54, mdio-mux-2@54 etc.
Shawn
>
> Any better alternatives?
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Pankaj Bansal
> Sent: Wednesday, October 24, 2018 6:35 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Subject: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
>
> The two external MDIO buses used to communicate with phy devices that
> are external to SOC are muxed in LX2160AQDS board.
>
> These buses can be routed to any one of the eight IO slots on LX2160AQDS
> board depending on value in fpga register 0x54.
>
> Additionally the external MDIO1 is used to communicate to the onboard
> RGMII phy devices.
>
> The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is controlled by
> bits 0-3 of fpga register.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> ---
>
> Notes:
> This patch depends on below patches:
> [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=369563
> [2] https://patchwork.kernel.org/patch/10645287/
>
> This patch is used by below patches:
> [1]https://patchwork.ozlabs.org/project/netdev/list/?series=69426&state=%2A&archive=both
>
> .../boot/dts/freescale/fsl-lx2160a-qds.dts | 115 +++++++++++++++++
> .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 ++++
> 2 files changed, 137 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index 99a22abbe725..4b282bf6c36a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -46,6 +46,121 @@
> &i2c0 {
> status = "okay";
>
> + fpga@66 {
> + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> + reg = <0x66>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio-mux@54_f8 {
> + mdio-parent-bus = <&emdio1>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0xf8>; /* EMI1_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@40 {
> + reg = <0x40>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c0 {
> + reg = <0xc0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c8 {
> + reg = <0xc8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d0 {
> + reg = <0xd0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d8 {
> + reg = <0xd8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e0 {
> + reg = <0xe0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e8 {
> + reg = <0xe8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f0 {
> + reg = <0xf0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f8 {
> + reg = <0xf8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + mdio-mux@54_07 {
> + mdio-parent-bus = <&emdio2>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0x07>; /* EMI2_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@1 {
> + reg = <0x01>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@2 {
> + reg = <0x02>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@3 {
> + reg = <0x03>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@4 {
> + reg = <0x04>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@5 {
> + reg = <0x05>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@6 {
> + reg = <0x06>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@7 {
> + reg = <0x07>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + };
> +
> i2c-mux@77 {
> compatible = "nxp,pca9547";
> reg = <0x77>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 56f846c55812..e16b1643595b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -761,5 +761,27 @@
> <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> dma-coherent;
> };
> +
> + /* TODO: WRIOP (CCSR?) */
> + emdio1: mdio@0x8B96000 { /* WRIOP0: 0x8B8_0000, E-MDIO1: 0x1_6000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B96000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + /* Not necessary on the QDS, but needed on the RDB*/
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + emdio2: mdio@0x8B97000 { /* WRIOP0: 0x8B8_0000, E-MDIO2: 0x1_7000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B97000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
> };
> --
> 2.17.1
>
^ 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