* Re: [PATCH] bpf: tcp_bpf_recvmsg should return EAGAIN when nonblocking and no data
From: Daniel Borkmann @ 2018-10-30 22:30 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev
In-Reply-To: <1540841488-22023-1-git-send-email-john.fastabend@gmail.com>
On 10/29/2018 08:31 PM, John Fastabend wrote:
> We return 0 in the case of a nonblocking socket that has no data
> available. However, this is incorrect and may confuse applications.
> After this patch we do the correct thing and return the error
> EAGAIN.
>
> Quoting return codes from recvmsg manpage,
>
> EAGAIN or EWOULDBLOCK
> The socket is marked nonblocking and the receive operation would
> block, or a receive timeout had been set and the timeout expired
> before data was received.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied to bpf, thanks!
^ permalink raw reply
* Re: [PATCH bpf] tools/bpf: add unlimited rlimit for flow_dissector_load
From: Daniel Borkmann @ 2018-10-30 22:30 UTC (permalink / raw)
To: Yonghong Song, ast, netdev; +Cc: kernel-team
In-Reply-To: <20181029215648.3043831-1-yhs@fb.com>
On 10/29/2018 10:56 PM, Yonghong Song wrote:
> On our test machine, bpf selftest test_flow_dissector.sh failed
> with the following error:
> # ./test_flow_dissector.sh
> bpffs not mounted. Mounting...
> libbpf: failed to create map (name: 'jmp_table'): Operation not permitted
> libbpf: failed to load object 'bpf_flow.o'
> ./flow_dissector_load: bpf_prog_load bpf_flow.o
> selftests: test_flow_dissector [FAILED]
>
> Let us increase the rlimit to remove the above map
> creation failure.
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied to bpf, thanks!
^ permalink raw reply
* Re: [PATCH net v5] net/ipv6: Add anycast addresses to a global hashtable
From: David Ahern @ 2018-10-30 22:06 UTC (permalink / raw)
To: David Miller, 0xeffeff; +Cc: netdev, kuznet, yoshfuji
In-Reply-To: <20181030.113147.173837020180526004.davem@davemloft.net>
On 10/30/18 12:31 PM, David Miller wrote:
> From: Jeff Barnhill <0xeffeff@gmail.com>
> Date: Tue, 30 Oct 2018 07:10:58 -0400
>
>> I originally started implementing it the way you suggested; however,
>> it seemed to complicate management of that structure because it isn't
>> currently using rcu. Also, assuming that can be worked out, where
>> would I get the net from? Would I need to store a copy in ifcaddr6,
>> or is there some way to access it during ipv6_chk_acast_addr()? It
>> seems that if I don't add a copy of net, but instead access it through
>> aca_rt(?), then freeing the ifcaddr6 memory becomes problematic
>> (detaching it from idev, while read_rcu may still be accessing it).
>> On Mon, Oct 29, 2018 at 11:32 PM David Miller <davem@davemloft.net> wrote:
>
> I don't think converting the structure over to RCU, especially because
> all of the read paths (everything leading to ipv6_chk_acast_dev()) are
> taking RCU locks already.
>
> And I cannot understand how having _two_ structures to manage a piece
> of information can be less complicated than just one.
>
> You can add a backpointer to the 'idev' in ifacaddr6 to get at the
> network namespace. You don't even need to do additional reference
> counting because the idev->ac_list is always purged before an idev
> is destroyed.
>
or make the table per namespace.
^ permalink raw reply
* [PATCH iproute2-next] ip rule: Add ipproto and port range to filter list
From: David Ahern @ 2018-10-30 22:03 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
From: David Ahern <dsahern@gmail.com>
Allow ip rule dumps and flushes to filter based on ipproto, sport
and dport. Example:
$ ip ru ls ipproto udp
99: from all to 8.8.8.8 ipproto udp dport 53 lookup 1001
$ ip ru ls dport 53
99: from all to 8.8.8.8 ipproto udp dport 53 lookup 1001
Signed-off-by: David Ahern <dsahern@gmail.com>
---
ip/iprule.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/ip/iprule.c b/ip/iprule.c
index a85a43904e6e..0713694d4a49 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -78,6 +78,9 @@ static struct
inet_prefix dst;
int protocol;
int protocolmask;
+ struct fib_rule_port_range sport;
+ struct fib_rule_port_range dport;
+ __u8 ipproto;
} filter;
static inline int frh_get_table(struct fib_rule_hdr *frh, struct rtattr **tb)
@@ -174,6 +177,39 @@ static bool filter_nlmsg(struct nlmsghdr *n, struct rtattr **tb, int host_len)
return false;
}
+ if (filter.ipproto) {
+ __u8 ipproto = 0;
+
+ if (tb[FRA_IP_PROTO])
+ ipproto = rta_getattr_u8(tb[FRA_IP_PROTO]);
+ if (filter.ipproto != ipproto)
+ return false;
+ }
+
+ if (filter.sport.start) {
+ const struct fib_rule_port_range *r;
+
+ if (!tb[FRA_SPORT_RANGE])
+ return false;
+
+ r = RTA_DATA(tb[FRA_SPORT_RANGE]);
+ if (r->start != filter.sport.start ||
+ r->end != filter.sport.end)
+ return false;
+ }
+
+ if (filter.dport.start) {
+ const struct fib_rule_port_range *r;
+
+ if (!tb[FRA_DPORT_RANGE])
+ return false;
+
+ r = RTA_DATA(tb[FRA_DPORT_RANGE]);
+ if (r->start != filter.dport.start ||
+ r->end != filter.dport.end)
+ return false;
+ }
+
table = frh_get_table(frh, tb);
if (filter.tb > 0 && filter.tb ^ table)
return false;
@@ -607,6 +643,36 @@ static int iprule_list_flush_or_save(int argc, char **argv, int action)
filter.protocolmask = 0;
}
filter.protocol = prot;
+ } else if (strcmp(*argv, "ipproto") == 0) {
+ int ipproto;
+
+ NEXT_ARG();
+ ipproto = inet_proto_a2n(*argv);
+ if (ipproto < 0)
+ invarg("Invalid \"ipproto\" value\n", *argv);
+ filter.ipproto = ipproto;
+ } else if (strcmp(*argv, "sport") == 0) {
+ struct fib_rule_port_range r;
+ int ret = 0;
+
+ NEXT_ARG();
+ ret = sscanf(*argv, "%hu-%hu", &r.start, &r.end);
+ if (ret == 1)
+ r.end = r.start;
+ else if (ret != 2)
+ invarg("invalid port range\n", *argv);
+ filter.sport = r;
+ } else if (strcmp(*argv, "dport") == 0) {
+ struct fib_rule_port_range r;
+ int ret = 0;
+
+ NEXT_ARG();
+ ret = sscanf(*argv, "%hu-%hu", &r.start, &r.end);
+ if (ret == 1)
+ r.end = r.start;
+ else if (ret != 2)
+ invarg("invalid dport range\n", *argv);
+ filter.dport = r;
} else{
if (matches(*argv, "dst") == 0 ||
matches(*argv, "to") == 0) {
--
2.11.0
^ permalink raw reply related
* Re: WARNING in rds_message_alloc_sgs
From: Leon Romanovsky @ 2018-10-31 6:42 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: syzbot, linux-rdma, netdev, rds-devel, syzkaller-bugs, davem,
linux-kernel
In-Reply-To: <a7a834e0-c300-b5b9-67b5-78fa3eba8ebb@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]
On Tue, Oct 30, 2018 at 12:38:02PM -0700, Santosh Shilimkar wrote:
> On 10/30/2018 12:28 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 6201f31a39f8 Add linux-next specific files for 20181030
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1397d06d400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=2a22859d870756c1
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=26de17458aeda9d305d8
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10bb52eb400000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=118bdfc5400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+26de17458aeda9d305d8@syzkaller.appspotmail.com
> >
> > WARNING: CPU: 0 PID: 19789 at net/rds/message.c:316
> > rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
> > Kernel panic - not syncing: panic_on_warn set ...
> Looks like this kernel build has panic on warn enabled which
> triggers panic for " WARN_ON(!nr_pages)" case. Will look into
> it. Thanks !!
Please don't forget to remove user triggered WARN_ON.
https://lwn.net/Articles/769365/
"Greg Kroah-Hartman raised the problem of core kernel API code that will
use WARN_ON_ONCE() to complain about bad usage; that will not generate
the desired result if WARN_ON_ONCE() is configured to crash the machine.
He was told that the code should just call pr_warn() instead, and that
the called function should return an error in such situations. It was
generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be
triggered from user space need to be fixed."
Thanks
>
> Regards,
> Santosh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH iproute2] ip rule: Require at least one argument for add
From: David Ahern @ 2018-10-30 20:59 UTC (permalink / raw)
To: netdev; +Cc: stephen, David Ahern
From: David Ahern <dsahern@gmail.com>
'ip rule add' with no additional arguments just adds another rule
for the main table - which exists by default. Require at least
1 argument similar to delete.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
ip/iprule.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/ip/iprule.c b/ip/iprule.c
index d89d808d8909..b465a80785b1 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -691,6 +691,11 @@ static int iprule_modify(int cmd, int argc, char **argv)
};
if (cmd == RTM_NEWRULE) {
+ if (argc == 0) {
+ fprintf(stderr,
+ "\"ip rule add\" requires arguments.\n");
+ return -1;
+ }
req.n.nlmsg_flags |= NLM_F_CREATE|NLM_F_EXCL;
req.frh.action = FR_ACT_TO_TBL;
}
--
2.11.0
^ permalink raw reply related
* [PATCH iproute2] ip rule: Honor filter arguments on flush
From: David Ahern @ 2018-10-30 20:58 UTC (permalink / raw)
To: netdev; +Cc: stephen, David Ahern
From: David Ahern <dsahern@gmail.com>
'ip ru flush' currently removes all rules with priority > 0 regardless
of any other command line arguments passed in. Update flush_rule to
call filter_nlmsg to determine if the rule should be flushed or not.
This enables rule flushing such as 'ip ru flush table 1001' and
'ip ru flush pref 99'.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
ip/iprule.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/ip/iprule.c b/ip/iprule.c
index b465a80785b1..a85a43904e6e 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -461,6 +461,7 @@ static int flush_rule(struct nlmsghdr *n, void *arg)
struct fib_rule_hdr *frh = NLMSG_DATA(n);
int len = n->nlmsg_len;
struct rtattr *tb[FRA_MAX+1];
+ int host_len = -1;
len -= NLMSG_LENGTH(sizeof(*frh));
if (len < 0)
@@ -468,6 +469,10 @@ static int flush_rule(struct nlmsghdr *n, void *arg)
parse_rtattr(tb, FRA_MAX, RTM_RTA(frh), len);
+ host_len = af_bit_len(frh->family);
+ if (!filter_nlmsg(n, tb, host_len))
+ return 0;
+
if (tb[FRA_PROTOCOL]) {
__u8 protocol = rta_getattr_u8(tb[FRA_PROTOCOL]);
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net] net: ethernet: cadence: fix socket buffer corruption problem
From: Tristram.Ha @ 2018-10-30 19:36 UTC (permalink / raw)
To: Claudiu.Beznea; +Cc: UNGLinuxDriver, netdev, davem, Nicolas.Ferre
In-Reply-To: <eceb7dd3-c7bc-fa78-26dc-1da2e4a8cf4e@microchip.com>
> Could you check on your side that applying this on top of your patch, your
> scenario is still working?
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index 1d86b4d5645a..e1347d6d1b50 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -1702,12 +1702,8 @@ static int macb_pad_and_fcs(struct sk_buff **skb,
> struct net_device *ndev)
> *skb = nskb;
> }
>
> - if (padlen) {
> - if (padlen >= ETH_FCS_LEN)
> - skb_put_zero(*skb, padlen - ETH_FCS_LEN);
> - else
> - skb_trim(*skb, ETH_FCS_LEN - padlen);
> - }
> + if (padlen > ETH_FCS_LEN)
> + skb_put_zero(*skb, padlen - ETH_FCS_LEN);
I think it is okay but I need to check all paths are covered.
> It was reported in [1] that UDP checksum is offloaded to hardware no matter
> the application previously computed it.
>
> The code should be executed only for packets that has checksum computed
> by
> applications ((*skb)->ip_summed != CHECKSUM_PARTIAL). The idea was to
> not
> recompute checksum for packets with checksum already computed. To do
> so,
> while hardware checksum is enabled (NETIF_F_HW_CSUM), TX_NOCRC bit
> should
> be set on buffer descriptor. But to do so, packets must have a minimum size
> of 64 and FCS to be computed.
>
> The NETIF_F_HW_CSUM check was placed there because the issue
> described in
> [1] is reproducible because hardware checksum is enabled and overrides the
> checksum provided by applications.
>
> [1] https://www.spinics.net/lists/netdev/msg505065.html
I understand the issue now. It is weird that the transmit descriptor does not
have direct control over turning on checksum generation or not, but it wastes
3 bits returning the error codes of such generation. What can the driver do
with such information?
In my opinion then hardware transmit checksumming cannot be supported
In Linux.
> > NETIF_F_SG is not enabled in the MAC I used, so enabling
> NETIF_IF_HW_CSUM
> > is rather pointless. With the padding code the transmit throughput cannot
> get
> > higher than 100Mbps in a gigabit connection.
> >
> > I would recommend to add this option to disable manual padding in one of
> those
> > macb_config structures.
>
> In this way the user would have to know from the beginning what kind of
> packets are used.
>
The kernel already does a good job of calculating checksum. Using hardware to
do that does not improve performance much.
Alternative is to use ethtool to disable hardware tx checksum so that software can
intentionally send wrong checksums.
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: Eric Dumazet @ 2018-10-30 19:03 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, netdev, Eric Dumazet, Eran Ben Elisha,
Saeed Mahameed, Dimitris Michailidis, Paweł Staszewski
In-Reply-To: <CAM_iQpUPWncS22uYURFZ5OsvPZp7aJozPNOcDCak9nRFOS0jig@mail.gmail.com>
On Tue, Oct 30, 2018 at 11:59 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> I wonder how compiler recognizes it as "never fail" when marked with
> __must_check.
__must_check means that you can not ignore the return value of a function.
Here we do use the return value.
Also prior code was not checking skb->length so really my patch does
add explicit
check if in the future skb->len gets wrong after a bug is added in this driver.
(A NULL deref will trap the bug, instead of potentially reading
garbage from skb->data)
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: Cong Wang @ 2018-10-30 18:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Linux Kernel Network Developers, Eric Dumazet,
eranbe, Saeed Mahameed, dmichail, Paweł Staszewski
In-Reply-To: <CANn89iKx7d18v+gG33QyyOPAhVR8bh4t=qRGDaJcM7gTXAOU1w@mail.gmail.com>
On Tue, Oct 30, 2018 at 11:42 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Oct 30, 2018 at 11:09 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> > At least skb_header_pointer() is marked as __must_check, I don't see
> > you check its return value here.
>
> This can not fail here.
>
> skb->length must be above 14+4 at this point.
Never say it is wrong, just saying what compiler thinks.
>
> My compiler seems to be okay with that.
I wonder how compiler recognizes it as "never fail" when marked with
__must_check.
^ permalink raw reply
* Re: [Patch net] net: make pskb_trim_rcsum_slow() robust
From: Cong Wang @ 2018-10-30 18:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <f0639ba8-ba57-4782-1133-443b51d61bb0@gmail.com>
On Mon, Oct 29, 2018 at 8:08 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 10/29/2018 07:41 PM, Cong Wang wrote:
> > On Mon, Oct 29, 2018 at 7:25 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>
> >>
> >>
> >> On 10/29/2018 07:21 PM, Cong Wang wrote:
> >>> On Mon, Oct 29, 2018 at 7:14 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>>>
> >>>> Would not it be simpler to set ip_summed to CHECKSUM_NONE (no need to save old_csum) ?
> >>>
> >>> For !CHECKSUM_COMPLETE, ip_summed should be untouched, right?
> >>>
> >>> If you mean only setting to CHECKSUM_NONE for CHECKSUM_COMPLETE case,
> >>> the end result may not be simpler.
> >>
> >> I meant to reinstate what was there before my patch in this error case
> >>
> >> if (skb->ip_summed == CHECKSUM_COMPLETE)
> >> skb->ip_summed = CHECKSUM_NONE;
> >>
> >> That would only be run in error (quite unlikely) path, instead of saving old_csum in all cases.
> >
> > I know your point, however, I am not sure that is a desired behavior.
> >
> > On failure, I think the whole skb should be restored to its previous state
> > before entering this function, changing it to CHECKSUM_NONE on failure
> > is inconsistent with success case.
> >
>
> Before my patch, we were changing skb->ip_summed to CHECKSUM_NONE,
> so why suddenly we need to be consistent ?
That is because setting it to CHECKSUM_NONE _was_ how the success
case works and nothing _was_ needed for failure case.
You changed how we handle checksum for success case, it is why we need
to change for the failure case too.
>
> In any case, ip_check_defrag() should really drop this skb, as for other allocation
> failures (like skb_share_check()), if really we want consistency.
I have the same feeling, just not brave enough to change the logic of
ip_check_defrag() where pskb_may_pull() failure is treated in a same way.
^ permalink raw reply
* [PATCH 3/4] net: macb: Add pm runtime support
From: Harini Katakam @ 2018-10-31 3:40 UTC (permalink / raw)
To: nicolas.ferre, davem, claudiu.beznea
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam, Harini Katakam, Shubhrajyoti Datta
In-Reply-To: <1540957223-30984-1-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harinik@xilinx.com>
Add runtime pm functions and move clock handling there.
If device is suspended and not a wake device, then return from
mdio read/write functions without performing any action because
the clocks are not active.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
Changes from RFC:
Updated pm get sync/put sync calls.
Removed unecessary clk up in mdio helpers.
drivers/net/ethernet/cadence/macb_main.c | 103 +++++++++++++++++++++++++------
1 file changed, 85 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 7ae8d731..09cb4bb 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -36,6 +36,7 @@
#include <linux/ip.h>
#include <linux/udp.h>
#include <linux/tcp.h>
+#include <linux/pm_runtime.h>
#include "macb.h"
#define MACB_RX_BUFFER_SIZE 128
@@ -78,6 +79,7 @@
* 1 frame time (10 Mbits/s, full-duplex, ignoring collisions)
*/
#define MACB_HALT_TIMEOUT 1230
+#define MACB_PM_TIMEOUT 100 /* ms */
/* DMA buffer descriptor might be different size
* depends on hardware configuration:
@@ -345,6 +347,10 @@ static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
int value;
int err;
+ if (pm_runtime_status_suspended(&bp->pdev->dev) &&
+ !device_may_wakeup(&bp->dev->dev))
+ return -EAGAIN;
+
err = macb_mdio_wait_for_idle(bp);
if (err < 0)
return err;
@@ -370,6 +376,9 @@ static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
struct macb *bp = bus->priv;
int err;
+ if (pm_runtime_status_suspended(&bp->pdev->dev) &&
+ !device_may_wakeup(&bp->dev->dev))
+ return -EAGAIN;
err = macb_mdio_wait_for_idle(bp);
if (err < 0)
@@ -2397,12 +2406,18 @@ static int macb_open(struct net_device *dev)
netdev_dbg(bp->dev, "open\n");
+ err = pm_runtime_get_sync(&bp->pdev->dev);
+ if (err < 0)
+ goto pm_exit;
+
/* carrier starts down */
netif_carrier_off(dev);
/* if the phy is not yet register, retry later*/
- if (!dev->phydev)
- return -EAGAIN;
+ if (!dev->phydev) {
+ err = -EAGAIN;
+ goto pm_exit;
+ }
/* RX buffers initialization */
macb_init_rx_buffer_size(bp, bufsz);
@@ -2411,7 +2426,7 @@ static int macb_open(struct net_device *dev)
if (err) {
netdev_err(dev, "Unable to allocate DMA memory (error %d)\n",
err);
- return err;
+ goto pm_exit;
}
bp->macbgem_ops.mog_init_rings(bp);
@@ -2428,6 +2443,11 @@ static int macb_open(struct net_device *dev)
if (bp->ptp_info)
bp->ptp_info->ptp_init(dev);
+pm_exit:
+ if (err) {
+ pm_runtime_put_sync(&bp->pdev->dev);
+ return err;
+ }
return 0;
}
@@ -2456,6 +2476,8 @@ static int macb_close(struct net_device *dev)
if (bp->ptp_info)
bp->ptp_info->ptp_remove(dev);
+ pm_runtime_put(&bp->pdev->dev);
+
return 0;
}
@@ -4019,6 +4041,11 @@ static int macb_probe(struct platform_device *pdev)
if (err)
return err;
+ pm_runtime_set_autosuspend_delay(&pdev->dev, MACB_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
native_io = hw_is_native_io(mem);
macb_probe_queues(mem, native_io, &queue_mask, &num_queues);
@@ -4150,6 +4177,9 @@ static int macb_probe(struct platform_device *pdev)
macb_is_gem(bp) ? "GEM" : "MACB", macb_readl(bp, MID),
dev->base_addr, dev->irq, dev->dev_addr);
+ pm_runtime_mark_last_busy(&bp->pdev->dev);
+ pm_runtime_put_autosuspend(&bp->pdev->dev);
+
return 0;
err_out_unregister_mdio:
@@ -4169,6 +4199,9 @@ static int macb_probe(struct platform_device *pdev)
clk_disable_unprepare(pclk);
clk_disable_unprepare(rx_clk);
clk_disable_unprepare(tsu_clk);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
return err;
}
@@ -4192,11 +4225,16 @@ static int macb_remove(struct platform_device *pdev)
mdiobus_free(bp->mii_bus);
unregister_netdev(dev);
- clk_disable_unprepare(bp->tx_clk);
- clk_disable_unprepare(bp->hclk);
- clk_disable_unprepare(bp->pclk);
- clk_disable_unprepare(bp->rx_clk);
- clk_disable_unprepare(bp->tsu_clk);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
+ if (!pm_runtime_suspended(&pdev->dev)) {
+ clk_disable_unprepare(bp->tx_clk);
+ clk_disable_unprepare(bp->hclk);
+ clk_disable_unprepare(bp->pclk);
+ clk_disable_unprepare(bp->rx_clk);
+ clk_disable_unprepare(bp->tsu_clk);
+ pm_runtime_set_suspended(&pdev->dev);
+ }
of_node_put(bp->phy_node);
free_netdev(dev);
}
@@ -4217,13 +4255,9 @@ static int __maybe_unused macb_suspend(struct device *dev)
macb_writel(bp, IER, MACB_BIT(WOL));
macb_writel(bp, WOL, MACB_BIT(MAG));
enable_irq_wake(bp->queues[0].irq);
- } else {
- clk_disable_unprepare(bp->tx_clk);
- clk_disable_unprepare(bp->hclk);
- clk_disable_unprepare(bp->pclk);
- clk_disable_unprepare(bp->rx_clk);
}
- clk_disable_unprepare(bp->tsu_clk);
+
+ pm_runtime_force_suspend(dev);
return 0;
}
@@ -4234,11 +4268,43 @@ static int __maybe_unused macb_resume(struct device *dev)
struct net_device *netdev = platform_get_drvdata(pdev);
struct macb *bp = netdev_priv(netdev);
+ pm_runtime_force_resume(dev);
+
if (bp->wol & MACB_WOL_ENABLED) {
macb_writel(bp, IDR, MACB_BIT(WOL));
macb_writel(bp, WOL, 0);
disable_irq_wake(bp->queues[0].irq);
- } else {
+ }
+
+ netif_device_attach(netdev);
+
+ return 0;
+}
+
+static int __maybe_unused macb_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct net_device *netdev = platform_get_drvdata(pdev);
+ struct macb *bp = netdev_priv(netdev);
+
+ if (!(device_may_wakeup(&bp->dev->dev))) {
+ clk_disable_unprepare(bp->tx_clk);
+ clk_disable_unprepare(bp->hclk);
+ clk_disable_unprepare(bp->pclk);
+ clk_disable_unprepare(bp->rx_clk);
+ }
+ clk_disable_unprepare(bp->tsu_clk);
+
+ return 0;
+}
+
+static int __maybe_unused macb_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct net_device *netdev = platform_get_drvdata(pdev);
+ struct macb *bp = netdev_priv(netdev);
+
+ if (!(device_may_wakeup(&bp->dev->dev))) {
clk_prepare_enable(bp->pclk);
clk_prepare_enable(bp->hclk);
clk_prepare_enable(bp->tx_clk);
@@ -4246,12 +4312,13 @@ static int __maybe_unused macb_resume(struct device *dev)
}
clk_prepare_enable(bp->tsu_clk);
- netif_device_attach(netdev);
-
return 0;
}
-static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
+static const struct dev_pm_ops macb_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(macb_suspend, macb_resume)
+ SET_RUNTIME_PM_OPS(macb_runtime_suspend, macb_runtime_resume, NULL)
+};
static struct platform_driver macb_driver = {
.probe = macb_probe,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] net: macb: Check MDIO state before read/write and use timeouts
From: Harini Katakam @ 2018-10-31 3:40 UTC (permalink / raw)
To: nicolas.ferre, davem, claudiu.beznea
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam, Harini Katakam, Shubhrajyoti Datta,
Sai Pavan Boddu
In-Reply-To: <1540957223-30984-1-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harinik@xilinx.com>
Replace the while loop in MDIO read/write functions with a timeout.
In addition, add a check for MDIO bus busy before initiating a new
operation as well to make sure there is no ongoing MDIO operation.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
Changes form RFC:
Cleaned up timeout implementation and moved it to a helper.
drivers/net/ethernet/cadence/macb_main.c | 44 +++++++++++++++++++++++++++-----
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 0acaef3..b4e26c1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -318,10 +318,36 @@ static void macb_get_hwaddr(struct macb *bp)
eth_hw_addr_random(bp->dev);
}
+static int macb_mdio_wait_for_idle(struct macb *bp)
+{
+ ulong timeout;
+
+ timeout = jiffies + msecs_to_jiffies(1000);
+ /* wait for end of transfer */
+ while (1) {
+ if (MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
+ break;
+
+ if (time_after_eq(jiffies, timeout)) {
+ netdev_err(bp->dev, "wait for end of transfer timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ cpu_relax();
+ }
+
+ return 0;
+}
+
static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
{
struct macb *bp = bus->priv;
int value;
+ int err;
+
+ err = macb_mdio_wait_for_idle(bp);
+ if (err < 0)
+ return err;
macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
| MACB_BF(RW, MACB_MAN_READ)
@@ -329,9 +355,9 @@ static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
| MACB_BF(REGA, regnum)
| MACB_BF(CODE, MACB_MAN_CODE)));
- /* wait for end of transfer */
- while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
- cpu_relax();
+ err = macb_mdio_wait_for_idle(bp);
+ if (err < 0)
+ return err;
value = MACB_BFEXT(DATA, macb_readl(bp, MAN));
@@ -342,6 +368,12 @@ static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
u16 value)
{
struct macb *bp = bus->priv;
+ int err;
+
+
+ err = macb_mdio_wait_for_idle(bp);
+ if (err < 0)
+ return err;
macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
| MACB_BF(RW, MACB_MAN_WRITE)
@@ -350,9 +382,9 @@ static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
| MACB_BF(CODE, MACB_MAN_CODE)
| MACB_BF(DATA, value)));
- /* wait for end of transfer */
- while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
- cpu_relax();
+ err = macb_mdio_wait_for_idle(bp);
+ if (err < 0)
+ return err;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] Macb power management support for ZynqMP
From: Harini Katakam @ 2018-10-31 3:40 UTC (permalink / raw)
To: nicolas.ferre, davem, claudiu.beznea
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
This series adds support for macb suspend/resume with system power down
and wake on LAN with ARP packets.
In relation to the above, this series also updates mdio_read/write
function for PM and adds tsu clock management.
Harini Katakam (4):
net: macb: Check MDIO state before read/write and use timeouts
net: macb: Support clock management for tsu_clk
net: macb: Add pm runtime support
net: macb: Add support for suspend/resume with full power down
drivers/net/ethernet/cadence/macb.h | 3 +-
drivers/net/ethernet/cadence/macb_main.c | 207 +++++++++++++++++++++++++++----
2 files changed, 182 insertions(+), 28 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: David Miller @ 2018-10-30 18:43 UTC (permalink / raw)
To: xiyou.wangcong
Cc: edumazet, netdev, eric.dumazet, eranbe, saeedm, dmichail,
pstaszewski
In-Reply-To: <CAM_iQpXS2zp-_6XEmzyfvenomDmHqR3uJWoSiMSJG71OKZ3Sjg@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 30 Oct 2018 11:09:21 -0700
> On Tue, Oct 30, 2018 at 12:57 AM Eric Dumazet <edumazet@google.com> wrote:
>> -static __be32 mlx5e_get_fcs(struct sk_buff *skb)
>> +static u32 mlx5e_get_fcs(const struct sk_buff *skb)
>> {
>> - int last_frag_sz, bytes_in_prev, nr_frags;
>> - u8 *fcs_p1, *fcs_p2;
>> - skb_frag_t *last_frag;
>> - __be32 fcs_bytes;
>> + const void *fcs_bytes;
>> + u32 _fcs_bytes;
>>
>> - if (!skb_is_nonlinear(skb))
>> - return *(__be32 *)(skb->data + skb->len - ETH_FCS_LEN);
>> + fcs_bytes = skb_header_pointer(skb, skb->len - ETH_FCS_LEN,
>> + ETH_FCS_LEN, &_fcs_bytes);
>
> At least skb_header_pointer() is marked as __must_check, I don't see
> you check its return value here.
In this case we reasonably know it is guaranteed to succeed though.
We know skb->len is non-zero and we are asking for the skb->len - 1
byte or something like that.
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: Eric Dumazet @ 2018-10-30 18:42 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, netdev, Eric Dumazet, Eran Ben Elisha,
Saeed Mahameed, Dimitris Michailidis, Paweł Staszewski
In-Reply-To: <CAM_iQpXS2zp-_6XEmzyfvenomDmHqR3uJWoSiMSJG71OKZ3Sjg@mail.gmail.com>
On Tue, Oct 30, 2018 at 11:09 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> At least skb_header_pointer() is marked as __must_check, I don't see
> you check its return value here.
This can not fail here.
skb->length must be above 14+4 at this point.
My compiler seems to be okay with that.
^ permalink raw reply
* Your urgent respond is needed.
From: Dr. Bernard Zoungrana @ 2018-10-30 18:38 UTC (permalink / raw)
Dear Partner,
We want to transfer to overseas ($50.500, 000.00) Fifth Million Five
Hundred Thousand United States Dollars) from the Bank of Africa, I
want to ask you to quietly look for a reliable and honest person who
will be capable and fit to provide either an existing bank account or
to set up a new Bank account immediately to receive this money, even
an empty account can serve to receive this funds quietly.
I am Dr. Bernard Zoungrana, the accountant personal confidant to
Mr.Raymond Beck. Who died together with his wife in a plane crash on
the Tuesday, November 2, 1999 on their way to attend wedding in
Boston. Mr. Raymond Beck, is an American, a physician and
industrialist, he died without having any beneficiary to his assets
including his account here in Burkina Faso which he opened in a Bank
of Africa in the year 1994 as his personal savings for the purpose of
expansion and development of his company before his untimely death in
1999.
The amount involved is ($50,500,000.00) Fifth Million Five Hundred
Thousand United State Dollars, no other person knows about this
account, I am contacting you for us to transfer this funds to your
account as the beneficiary as foreigner, I am only contacting you as a
foreigner because this money cannot be approved to a local person
here, without valid international foreign passport, but can only be
approved to any foreigner with valid international passport or
driver's license and foreign account because the money is in US
Dollars and the former owner of the account Mr. Raymond Beck is a
foreigner too, and as such the money can only be approved into a
foreign account.
However, I am revealing this to you with believe in God that you
will never let me down in this business, you are the first and the
only person that I am contacting for this business, so please reply
urgently so that I will inform you the next step to take urgently.
Send also your private telephone and fax number including the full
details of the account to be used for the deposit. I need your full
co-operation to make this work fine. Because the management is ready
to approve this payment to any foreigner who has correct information
of this account, which I will give to you, upon your positive response
and once I am convinced that you are capable and will meet up with
instruction of a key bank official who is deeply involved with me in
this business at the conclusion of this business, you will be given
40% of the total amount, 50% will be for me, while 10% will be for
expenses both parties might have incurred during the process of
transferring. I look forward to your earliest reply.
(1) YOUR FULL NAME: _________________________ (2) YOUR
AGE:_______________________________
(3) MARITAL STATUS: __________________________(4) YOUR CELL PHONE
NUMBER: ______________
(5) YOUR FAX NUMBER: ________________________ (6) YOUR
COUNTRY:__________________________
(7) YOUR OCCUPATION: ________________________ (8)
SEX:_____________________________________
(9) YOUR RELIGION:___________________________ (10) YOUR PRIVATE E-MAIL
ADDRESS: ___________
NOTE: THIS TRANSACTION IS CONFIDENTIAL.
Thanks for your assistance in advance.
Dr. Bernard Zoungrana.
Bill and Exchange (Executive Director).
^ permalink raw reply
* Re: [PATCH net v5] net/ipv6: Add anycast addresses to a global hashtable
From: David Miller @ 2018-10-30 18:31 UTC (permalink / raw)
To: 0xeffeff; +Cc: netdev, kuznet, yoshfuji
In-Reply-To: <CAL6e_pfB=8RE6XFTVj6Bz2qHRstPciS6x3TdHggxwcJqcAtwVQ@mail.gmail.com>
From: Jeff Barnhill <0xeffeff@gmail.com>
Date: Tue, 30 Oct 2018 07:10:58 -0400
> I originally started implementing it the way you suggested; however,
> it seemed to complicate management of that structure because it isn't
> currently using rcu. Also, assuming that can be worked out, where
> would I get the net from? Would I need to store a copy in ifcaddr6,
> or is there some way to access it during ipv6_chk_acast_addr()? It
> seems that if I don't add a copy of net, but instead access it through
> aca_rt(?), then freeing the ifcaddr6 memory becomes problematic
> (detaching it from idev, while read_rcu may still be accessing it).
> On Mon, Oct 29, 2018 at 11:32 PM David Miller <davem@davemloft.net> wrote:
I don't think converting the structure over to RCU, especially because
all of the read paths (everything leading to ipv6_chk_acast_dev()) are
taking RCU locks already.
And I cannot understand how having _two_ structures to manage a piece
of information can be less complicated than just one.
You can add a backpointer to the 'idev' in ifacaddr6 to get at the
network namespace. You don't even need to do additional reference
counting because the idev->ac_list is always purged before an idev
is destroyed.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: add a missing <net/ip.h> include
From: David Miller @ 2018-10-30 18:19 UTC (permalink / raw)
To: edumazet; +Cc: netdev, tariqt, abdhalee, eric.dumazet
In-Reply-To: <20181030071812.152491-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 30 Oct 2018 00:18:12 -0700
> Abdul Haleem reported a build error on ppc :
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
> iphdr` declared inside parameter list [enabled by default]
> struct iphdr *iph)
> ^
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: its scope is
> only this definition or declaration, which is probably not what you want
> [enabled by default]
> drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function
> get_fixed_ipv4_csum:
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:586:20: error: dereferencing
> pointer to incomplete type
> __u8 ipproto = iph->protocol;
> ^
>
> Fixes: 55469bc6b577 ("drivers: net: remove <net/busy_poll.h> inclusion when not needed")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: Cong Wang @ 2018-10-30 18:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Linux Kernel Network Developers, Eric Dumazet,
eranbe, Saeed Mahameed, dmichail, Paweł Staszewski
In-Reply-To: <20181030075725.195824-1-edumazet@google.com>
On Tue, Oct 30, 2018 at 12:57 AM Eric Dumazet <edumazet@google.com> wrote:
> -static __be32 mlx5e_get_fcs(struct sk_buff *skb)
> +static u32 mlx5e_get_fcs(const struct sk_buff *skb)
> {
> - int last_frag_sz, bytes_in_prev, nr_frags;
> - u8 *fcs_p1, *fcs_p2;
> - skb_frag_t *last_frag;
> - __be32 fcs_bytes;
> + const void *fcs_bytes;
> + u32 _fcs_bytes;
>
> - if (!skb_is_nonlinear(skb))
> - return *(__be32 *)(skb->data + skb->len - ETH_FCS_LEN);
> + fcs_bytes = skb_header_pointer(skb, skb->len - ETH_FCS_LEN,
> + ETH_FCS_LEN, &_fcs_bytes);
At least skb_header_pointer() is marked as __must_check, I don't see
you check its return value here.
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2018-10-31 2:56 UTC (permalink / raw)
To: David Miller; +Cc: doronrk, tom, davejwatson, netdev, linux-kernel
In-Reply-To: <20180918015723.GA26300@nautica>
Dominique Martinet wrote on Tue, Sep 18, 2018:
> David Miller wrote on Mon, Sep 17, 2018:
> > From: Dominique Martinet <asmadeus@codewreck.org>
> > Date: Wed, 12 Sep 2018 07:36:42 +0200
> > > Dominique Martinet wrote on Tue, Sep 11, 2018:
> > >> Hmm, while trying to benchmark this, I sometimes got hangs in
> > >> kcm_wait_data() for the last packet somehow?
> > >> The sender program was done (exited (zombie) so I assumed the sender
> > >> socket flushed), but the receiver was in kcm_wait_data in kcm_recvmsg
> > >> indicating it parsed a header but there was no skb to peek at?
> > >> But the sock is locked so this shouldn't be racy...
> > >>
> > >> I can get it fairly often with this patch and small messages with an
> > >> offset, but I think it's just because the pull changes some timing - I
> > >> can't hit it with just the clone, and I can hit it with a pull without
> > >> clone as well.... And I don't see how pulling a cloned skb can impact
> > >> the original socket, but I'm a bit fuzzy on this.
> > >
> > > This is weird, I cannot reproduce at all without that pull, even if I
> > > add another delay there instead of the pull, so it's not just timing...
> >
> > I really can't apply this patch until you resolve this.
> >
> > It is weird, given your description, though...
>
> Thanks for the reminder! I totally agree with you here and did not
> expect this to be merged as it is (in retrospect, I probably should have
> written something to that extent in the subject, "RFC"?)
Found the issue after some trouble reproducing on other VM, long story
short:
- I was blaming kcm_wait_data's sk_wait_data to wait while there was
something in sk->sk_receive_queue, but after adding a fake timeout and
some debug messages I can see the receive queue is empty.
However going back up from the kcm_sock to the kcm_mux to the kcm_psock,
there are things in the psock's socket's receive_queue... (If I'm
following the code correctly, that would be the underlying tcp socket)
- that psock's strparser contains some hints: the interrupted and
stopped bits are set. strp->interrupted looks like it's only set if
kcm_parse_msg returns something < 0. . .
And surely enough, the skb_pull returns NULL iff there's such a hang...!
I might be tempted to send a patch to strparser to add a pr_debug
message in strp_abort_strp...
Anyway, that probably explains I have no problem with bigger VM
(uselessly more memory available) or without KASAN (I guess there's
overhead?), but I'm sending at most 300k of data and the VM has a 1.5GB
of ram, so if there's an allocation failure there I think there's a
problem ! . . .
So, well, I'm not sure on the way forward. Adding a bpf helper and
document that kcm users should mind the offset?
Thanks,
--
Dominique
^ permalink raw reply
* Re: Latest net-next kernel 4.19.0+
From: Cong Wang @ 2018-10-30 17:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paweł Staszewski, dmichail, Linux Kernel Network Developers
In-Reply-To: <473bee73-b40e-2038-35e2-2c03482f7b75@gmail.com>
On Tue, Oct 30, 2018 at 10:50 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 10/30/2018 10:32 AM, Cong Wang wrote:
>
> > Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
> > it much less frequently than Pawel.
> >
> > Also, it is probably not specific to mlx5, as there is another report which
> > is probably a non-mlx5 driver.
>
> Not sure if you provided a stack trace ?
I said it is the same with Pawel's. Here it is anyway:
[ 3731.075989] eth0: hw csum failure
[ 3731.079316] CPU: 15 PID: 0 Comm: swapper/15 Not tainted 4.14.74.x86_64 #1
[ 3731.086703] Hardware name: Wiwynn F4WW/Y 300-0284/F4WW MAIN BOARD,
BIOS F4WWP02 10/19/2018
[ 3731.094961] Call Trace:
[ 3731.097408] <IRQ>
[ 3731.099432] dump_stack+0x46/0x59
[ 3731.102751] __skb_checksum_complete+0xb8/0xd0
[ 3731.107194] tcp_v4_rcv+0x116/0xa30
[ 3731.110688] ip_local_deliver_finish+0x5d/0x1f0
[ 3731.115218] ip_local_deliver+0x6b/0xe0
[ 3731.119056] ? ip_rcv_finish+0x400/0x400
[ 3731.122973] ip_rcv+0x287/0x360
[ 3731.126112] ? inet_del_offload+0x40/0x40
[ 3731.130124] __netif_receive_skb_core+0x404/0xc10
[ 3731.134831] ? netif_receive_skb_internal+0x34/0xd0
[ 3731.139709] netif_receive_skb_internal+0x34/0xd0
[ 3731.144415] napi_gro_receive+0xb8/0xe0
[ 3731.148271] mlx5e_handle_rx_cqe_mpwrq+0x4e3/0x7f0 [mlx5_core]
[ 3731.154099] ? enqueue_entity+0x103/0x7f0
[ 3731.158114] mlx5e_poll_rx_cq+0xba/0x850 [mlx5_core]
[ 3731.163080] mlx5e_napi_poll+0x91/0x290 [mlx5_core]
[ 3731.167955] net_rx_action+0x14a/0x3e0
[ 3731.171707] ? credit_entropy_bits+0x23d/0x260
[ 3731.176153] __do_softirq+0xe2/0x2c3
[ 3731.179734] irq_exit+0xbc/0xd0
[ 3731.182878] do_IRQ+0x89/0xd0
[ 3731.185851] common_interrupt+0x7a/0x7a
[ 3731.189690] </IRQ>
[ 3731.191799] RIP: 0010:cpuidle_enter_state+0xa6/0x2d0
[ 3731.196761] RSP: 0018:ffffbb950c6f7eb0 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff60
[ 3731.204328] RAX: ffff9fe25fbe14c0 RBX: 00000364b57553af RCX: 000000000000001f
[ 3731.211459] RDX: 20c49ba5e353f7cf RSI: ffff68294248f469 RDI: 0000000000000000
[ 3731.218583] RBP: ffffdb7d003c3300 R08: 000000000000c3be R09: 0000000000008612
[ 3731.225709] R10: ffffbb950c6f7e98 R11: 000000000000c3be R12: 0000000000000003
[ 3731.232841] R13: ffffffff912c9d18 R14: 0000000000000000 R15: 00000364b396207a
[ 3731.239968] do_idle+0x166/0x1a0
[ 3731.243199] cpu_startup_entry+0x6f/0x80
[ 3731.247128] start_secondary+0x19c/0x1f0
[ 3731.251052] secondary_startup_64+0xa5/0xb0
>
> Have you tried IPv6 frags maybe ?
>
We have no IPv6 traffic. I asked people to try to generate IPv4 fragment
traffic to see if it would be more reproducible, no progress yet.
^ permalink raw reply
* Re: Latest net-next kernel 4.19.0+
From: Eric Dumazet @ 2018-10-30 17:50 UTC (permalink / raw)
To: Cong Wang
Cc: Paweł Staszewski, dmichail, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUKTh51maAzht8M3LuJAYDRMRnsGn_+Db0rGG-scW2SnA@mail.gmail.com>
On 10/30/2018 10:32 AM, Cong Wang wrote:
> Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
> it much less frequently than Pawel.
>
> Also, it is probably not specific to mlx5, as there is another report which
> is probably a non-mlx5 driver.
Not sure if you provided a stack trace ?
Have you tried IPv6 frags maybe ?
^ permalink raw reply
* Re: [PATCH iproute2 net-next 0/3] ss: Allow selection of columns to be displayed
From: Stefano Brivio @ 2018-10-30 17:34 UTC (permalink / raw)
To: David Ahern; +Cc: Yoann P., Stephen Hemminger, netdev
In-Reply-To: <7ffc00c8-bdf6-5c75-564e-2663494bda5d@gmail.com>
On Tue, 30 Oct 2018 10:34:45 -0600
David Ahern <dsahern@gmail.com> wrote:
> A more flexible approach is to use format strings to allow users to
> customize the output order and whitespace as well. So for ss and your
> column list (winging it here):
>
> netid = %N
> state = %S
> recv Q = %Qr
> send Q = %Qs
> local address = %Al
> lport port = %Pl
> remote address = %Ar
> remote port = %Pr
> process data = %p
> ...
>
> then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n"
I like the idea indeed, but I see two issues with ss:
- the current column abstraction is rather lightweight, things are
already buffered in the defined column order so we don't have to jump
back and forth in the buffer while rendering. Doing that needs some
extra care to avoid a performance hit, but it's probably doable, I
can put that on my to-do list
- how would you model automatic spacing in a format string? Should we
support width specifiers? Disable automatic spacing if a format
string is given? It might even make sense to allow partial automatic
spacing with a special character in the format string, that is:
"%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n"
would mean "align everything to the right, distribute remaining
whitespace between %S, %Qr and %Qs". But it looks rather complicated
at a glance.
--
Stefano
^ permalink raw reply
* Re: Latest net-next kernel 4.19.0+
From: Cong Wang @ 2018-10-30 17:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paweł Staszewski, dmichail, Linux Kernel Network Developers
In-Reply-To: <76dfbbda-d7f1-b13a-5921-c12c3b0f8e3e@gmail.com>
On Tue, Oct 30, 2018 at 7:16 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 10/30/2018 01:09 AM, Paweł Staszewski wrote:
> >
> >
> > W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
> >>
> >> On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
> >>
> >>> Indeed this is a bug. I would expect it to produce frequent errors
> >>> though as many odd-length
> >>> packets would trigger it. Do you have RXFCS? Regardless, how
> >>> frequently do you see the problem?
> >>>
> >> Old kernels (before 88078d98d1bb) were simply resetting ip_summed to CHECKSUM_NONE
> >>
> >> And before your fix (commit d55bef5059dd057bd), mlx5 bug was canceling the bug you fixed.
> >>
> >> So we now need to also fix mlx5.
> >>
> >> And of course use skb_header_pointer() in mlx5e_get_fcs() as I mentioned earlier,
> >> plus __get_unaligned_cpu32() as you hinted.
> >>
> >>
> >>
> >>
> >
> > No RXFCS
Same with Pawel, RXFCS is disabled by default.
> >
> > And this trace is rly frequently like once per 3/4 seconds
> > like below:
> > [28965.776864] vlan1490: hw csum failure
>
> Might be vlan related.
Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
it much less frequently than Pawel.
Also, it is probably not specific to mlx5, as there is another report which
is probably a non-mlx5 driver.
Thanks.
^ 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