* Re: [net-next][PATCH] net/ipv4: fix a net leak
From: Bjørn Mork @ 2018-10-25 18:43 UTC (permalink / raw)
To: David Ahern; +Cc: Li RongQing, netdev, David Miller
In-Reply-To: <b2fe3de8-44b7-1ba9-3543-ac8abee44bf6@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> On 10/24/18 9:02 AM, David Ahern wrote:
>> On 10/24/18 3:36 AM, Li RongQing wrote:
>>> put net when input a invalid ifindex, otherwise it will be leaked
>>>
>>> Fixes: 5fcd266a9f64("net/ipv4: Add support for dumping addresses for a specific device")
>>> Cc: David Ahern <dsahern@gmail.com>
>>> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>>> ---
>>> net/ipv4/devinet.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>>> index 63d5b58fbfdb..fd0c5a47e742 100644
>>> --- a/net/ipv4/devinet.c
>>> +++ b/net/ipv4/devinet.c
>>> @@ -1775,8 +1775,10 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
>>>
>>> if (fillargs.ifindex) {
>>> dev = __dev_get_by_index(tgt_net, fillargs.ifindex);
>>> - if (!dev)
>>> + if (!dev) {
>>> + put_net(tgt_net);
>>> return -ENODEV;
>>> + }
>>>
>>> in_dev = __in_dev_get_rtnl(dev);
>>> if (in_dev) {
>>>
>>
>> Good catch. IPv6 has the same problem. Will fix that one.
>>
> Actually remove that 'Reviewed-by'. You should only call put_net if
> (fillargs.netnsid >= 0)
>
> DaveM: just want to call this out since I mistakenly added the
> Reviewed-by. This patch should be dropped.
Hmm, I see that you implemented that. But I believe it's still buggy if
called with an invalid netnsid.
inet_valid_dump_ifaddr_req() will bail out with an error, but only
*after* setting fillargs->netnsid:
if (i == IFA_TARGET_NETNSID) {
struct net *net;
fillargs->netnsid = nla_get_s32(tb[i]);
net = rtnl_get_net_ns_capable(sk, fillargs->netnsid);
if (IS_ERR(net)) {
NL_SET_ERR_MSG(extack, "ipv4: Invalid target network namespace id");
return PTR_ERR(net);
}
*tgt_net = net;
} else {
So inet_dump_ifaddr() ends up doing put_net(tgt_net):
err = inet_valid_dump_ifaddr_req(nlh, &fillargs, &tgt_net,
skb->sk, cb);
if (err < 0)
goto put_tgt_net;
..
put_tgt_net:
if (fillargs.netnsid >= 0)
put_net(tgt_net);
I believe you should set fillargs->netnsid back to -1 in the
inet_valid_dump_ifaddr_req() error path, or use a temp variable to avoid
changing it unless get_net is successful.
Bjørn
^ permalink raw reply
* Re: [PATCH net] net: ethernet: cadence: fix socket buffer corruption problem
From: Florian Fainelli @ 2018-10-25 18:41 UTC (permalink / raw)
To: David Miller, Tristram.Ha; +Cc: nicolas.ferre, UNGLinuxDriver, netdev
In-Reply-To: <20181025.113246.2298193822589257914.davem@davemloft.net>
On 10/25/18 11:32 AM, David Miller wrote:
> From: <Tristram.Ha@microchip.com>
> Date: Wed, 24 Oct 2018 14:51:23 -0700
>
>> From: Tristram Ha <Tristram.Ha@microchip.com>
>>
>> Socket buffer is not re-created when headroom is 2 and tailroom is 1.
>>
>> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
>
> Applied.
No fixes tag?
--
Florian
^ permalink raw reply
* Re: [PATCH] octeontx2-af: Use GFP_ATOMIC under spin lock
From: David Miller @ 2018-10-25 18:36 UTC (permalink / raw)
To: weiyongjun1; +Cc: sgoutham, lcherian, gakula, jerinj, netdev, kernel-janitors
In-Reply-To: <1540431746-176759-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Thu, 25 Oct 2018 01:42:26 +0000
> The function nix_update_mce_list() is called from
> nix_update_bcast_mce_list(), and a spin lock is held
> here, so we should use GFP_ATOMIC instead.
>
> Fixes: 4b05528ebf0c ("octeontx2-af: Update bcast list upon NIXLF alloc/free")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
I'm applying this.
I'm really disappointed in how the octeontx2 driver submission has done.
The Intel folks can get an entire new driver in with 2 series
of patches, we're on the 3rd or 4th here and the driver still
isn't completely enough to have basic functionality working.
This driver is huge, overly complicated, and is being submitted in a
very painful way.
^ permalink raw reply
* Re: [PATCH net] net: ethernet: cadence: fix socket buffer corruption problem
From: David Miller @ 2018-10-25 18:32 UTC (permalink / raw)
To: Tristram.Ha; +Cc: nicolas.ferre, UNGLinuxDriver, netdev
In-Reply-To: <1540417883-8476-1-git-send-email-Tristram.Ha@microchip.com>
From: <Tristram.Ha@microchip.com>
Date: Wed, 24 Oct 2018 14:51:23 -0700
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Socket buffer is not re-created when headroom is 2 and tailroom is 1.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
Applied.
^ permalink raw reply
* Re: netif_receive_skb is taking long time
From: David Miller @ 2018-10-25 17:43 UTC (permalink / raw)
To: keyurp; +Cc: eric.dumazet, netdev
In-Reply-To: <BN6PR02MB2641D817810960AAE59B9CDEB7F70@BN6PR02MB2641.namprd02.prod.outlook.com>
From: Keyur Amrutbhai Patel <keyurp@xilinx.com>
Date: Thu, 25 Oct 2018 17:22:02 +0000
> Current time consuming function are " netif_receive_skb " and "
> napi_alloc_skb " these two function calls are taking maximum about
> of time
netif_receive_skb() calls the entire networking stack receive path.
So measuring it by itself it not very useful.
Use 'perf' or a similar tool to fully profile the kernel and get a
more detailed analysis.
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Eric Dumazet @ 2018-10-25 17:38 UTC (permalink / raw)
To: Andre Tomt, Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <aa5628c9-41ae-37cb-6bba-e47c4d16cb78@tomt.net>
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
^ permalink raw reply
* Re: netif_receive_skb is taking long time
From: Eric Dumazet @ 2018-10-25 17:32 UTC (permalink / raw)
To: Keyur Amrutbhai Patel, Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <BN6PR02MB2641D817810960AAE59B9CDEB7F70@BN6PR02MB2641.namprd02.prod.outlook.com>
Please do not top post, and use normal quoting.
On 10/25/2018 10:22 AM, Keyur Amrutbhai Patel wrote:
> Hi Eric,
>
> First of all thank you for replying and giving some spotlight.
>
> First step would be to read Documentation/networking/scaling.txt and see if anything there helps.
> - This is good article. I had gone through it. Any suggestion on RSS? How to configure it? Do I need to take care anything specially in my NIC driver?
Just read the page and apply the various configurations.
>
> Have you tried to profile the kernel and see if some contention or hot function appears ?
> - I have added time stampings in different functions. That is how I came to know that almost ~3375 neno seconds are used by just " netif_receive_skb " don’t know why. With less than that time my DMA operation is finishes and descriptors are managed.
> Current time consuming function are " netif_receive_skb " and " napi_alloc_skb " these two function calls are taking maximum about of time
>
So... networking spend more time in upper stacks than a driver.
A driver does almost nothing, just passing around bits that that NIC put in memory.
In most workloads, a driver would not use more than 5% of total cpu cycles.
Now, if all you need is to impress your friends/boss about some
crazy number of RX packets per second,
just do not allocate skbs, and not call netif_receive_skb(),
use something like XDP to drop incoming frames :)
> Maybe use a faster cpu, or remove not needed features like too heavy netfilter rules.
> - I am using Intex Xeon Platinum series processors. These are fast enough CPUs available in market with 64 cores. 2 CPU nodes (each has 32 core)
>
> We can not really answer your question, you do not provide enough information.
> - Please let me know what additional details you need. We have 6 queues in HW. Each is mapped to MSI-X vector. Each vector is giving interrupt on different CPU. From interrupt I am scheduling napi and from napi poll function I am getting DMA page and constructing skb and passing it to network layer with "netif_receive_skb".
>
> Let me know additional details which are required.
>
> Regards,
> Keyur
>
> -----Original Message-----
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Sent: Thursday, October 25, 2018 10:38 PM
> To: Keyur Amrutbhai Patel <keyurp@xilinx.com>; netdev@vger.kernel.org
> Subject: Re: netif_receive_skb is taking long time
>
> EXTERNAL EMAIL
>
> On 10/25/2018 08:39 AM, Keyur Amrutbhai Patel wrote:
>> Hi,
>>
>> In my NIC driver "netif_receive_skb" is taking too long time. Almost 3375 neno seconds. Which is more than whole packet processing from interrupt.
>>
>> Could anyone please help me to understand what could be the reason behind this? How to solve it to take minimum time?
>>
>> Is there any standard calls which we need to follow in order to get faster performance?
>>
>
> First step would be to read Documentation/networking/scaling.txt and see if anything there helps.
>
> Have you tried to profile the kernel and see if some contention or hot function appears ?
>
> Maybe use a faster cpu, or remove not needed features like too heavy netfilter rules.
>
> We can not really answer your question, you do not provide enough information.
>
^ permalink raw reply
* [PATCH 1/1] ipmr: Make cache queue length configurable
From: Brodie Greenfield @ 2018-10-26 2:02 UTC (permalink / raw)
To: davem, kuznet, yoshfuji
Cc: netdev, linux-kernel, chris.packham, luuk.paulussen,
Brodie Greenfield
We want to be able to keep more spaces available in our queue for
processing incoming multicast traffic (adding (S,G) entries) - this lets
us learn more groups faster, rather than dropping them at this stage.
Signed-off-by: Brodie Greenfield <brodie.greenfield@alliedtelesis.co.nz>
---
Documentation/networking/ip-sysctl.txt | 7 +++++++
include/net/netns/ipv4.h | 1 +
include/uapi/linux/sysctl.h | 1 +
kernel/sysctl_binary.c | 1 +
net/ipv4/af_inet.c | 2 ++
net/ipv4/ipmr.c | 4 +++-
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
7 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 960de8fe3f40..dfc70ef6c42b 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -864,6 +864,13 @@ ip_local_reserved_ports - list of comma separated ranges
Default: Empty
+ip_mr_cache_queue_length - INTEGER
+ Limit the number of multicast packets we can have in the queue to be
+ resolved.
+ Bear in mind that this causes an O(n) traversal of the same size when
+ the queue is full. This should be considered if increasing.
+ Default: 10
+
ip_unprivileged_port_start - INTEGER
This is a per-namespace sysctl. It defines the first
unprivileged port in the network namespace. Privileged ports
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index e47503b4e4d1..1ca5cabe2d3b 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -184,6 +184,7 @@ struct netns_ipv4 {
int sysctl_igmp_max_msf;
int sysctl_igmp_llm_reports;
int sysctl_igmp_qrv;
+ int sysctl_ip_mr_cache_queue_length;
struct ping_group_range ping_group_range;
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index d71013fffaf6..32e32d4904cd 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -425,6 +425,7 @@ enum
NET_TCP_ALLOWED_CONG_CONTROL=123,
NET_TCP_MAX_SSTHRESH=124,
NET_TCP_FRTO_RESPONSE=125,
+ NET_IPV4_IP_MR_CACHE_QUEUE_LENGTH=126,
};
enum {
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 07148b497451..8db94e8d97ed 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -367,6 +367,7 @@ static const struct bin_table bin_net_ipv4_table[] = {
{ CTL_INT, NET_IPV4_LOCAL_PORT_RANGE, "ip_local_port_range" },
{ CTL_INT, NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships" },
{ CTL_INT, NET_IPV4_IGMP_MAX_MSF, "igmp_max_msf" },
+ { CTL_INT, NET_IPV4_IP_MR_CACHE_QUEUE_LENGTH, "ip_mr_cache_queue_length" },
{ CTL_INT, NET_IPV4_INET_PEER_THRESHOLD, "inet_peer_threshold" },
{ CTL_INT, NET_IPV4_INET_PEER_MINTTL, "inet_peer_minttl" },
{ CTL_INT, NET_IPV4_INET_PEER_MAXTTL, "inet_peer_maxttl" },
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 1fbe2f815474..4b78d12aca36 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1818,6 +1818,8 @@ static __net_init int inet_init_net(struct net *net)
net->ipv4.sysctl_igmp_llm_reports = 1;
net->ipv4.sysctl_igmp_qrv = 2;
+ /* ipmr unresolved queue length max */
+ net->ipv4.sysctl_ip_mr_cache_queue_length = 10;
return 0;
}
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 5660adcf7a04..2864f80e2f2a 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1128,6 +1128,7 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
struct mfc_cache *c;
bool found = false;
int err;
+ struct net *net = dev_net(dev);
spin_lock_bh(&mfc_unres_lock);
list_for_each_entry(c, &mrt->mfc_unres_queue, _c.list) {
@@ -1140,7 +1141,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
if (!found) {
/* Create a new entry if allowable */
- if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
+ if (atomic_read(&mrt->cache_resolve_queue_len) >=
+ net->ipv4.sysctl_ip_mr_cache_queue_length ||
(c = ipmr_cache_alloc_unres()) == NULL) {
spin_unlock_bh(&mfc_unres_lock);
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 891ed2f91467..b249932ee24e 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -772,6 +772,13 @@ static struct ctl_table ipv4_net_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "ip_mr_cache_queue_length",
+ .data = &init_net.ipv4.sysctl_ip_mr_cache_queue_length,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
#ifdef CONFIG_IP_MULTICAST
{
.procname = "igmp_qrv",
--
2.19.1
^ permalink raw reply related
* RE: netif_receive_skb is taking long time
From: Keyur Amrutbhai Patel @ 2018-10-25 17:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <5d039fa2-95fc-dbdf-4ab0-d5cccebe8bcc@gmail.com>
Hi Eric,
First of all thank you for replying and giving some spotlight.
First step would be to read Documentation/networking/scaling.txt and see if anything there helps.
- This is good article. I had gone through it. Any suggestion on RSS? How to configure it? Do I need to take care anything specially in my NIC driver?
Have you tried to profile the kernel and see if some contention or hot function appears ?
- I have added time stampings in different functions. That is how I came to know that almost ~3375 neno seconds are used by just " netif_receive_skb " don’t know why. With less than that time my DMA operation is finishes and descriptors are managed.
Current time consuming function are " netif_receive_skb " and " napi_alloc_skb " these two function calls are taking maximum about of time
Maybe use a faster cpu, or remove not needed features like too heavy netfilter rules.
- I am using Intex Xeon Platinum series processors. These are fast enough CPUs available in market with 64 cores. 2 CPU nodes (each has 32 core)
We can not really answer your question, you do not provide enough information.
- Please let me know what additional details you need. We have 6 queues in HW. Each is mapped to MSI-X vector. Each vector is giving interrupt on different CPU. From interrupt I am scheduling napi and from napi poll function I am getting DMA page and constructing skb and passing it to network layer with "netif_receive_skb".
Let me know additional details which are required.
Regards,
Keyur
-----Original Message-----
From: Eric Dumazet <eric.dumazet@gmail.com>
Sent: Thursday, October 25, 2018 10:38 PM
To: Keyur Amrutbhai Patel <keyurp@xilinx.com>; netdev@vger.kernel.org
Subject: Re: netif_receive_skb is taking long time
EXTERNAL EMAIL
On 10/25/2018 08:39 AM, Keyur Amrutbhai Patel wrote:
> Hi,
>
> In my NIC driver "netif_receive_skb" is taking too long time. Almost 3375 neno seconds. Which is more than whole packet processing from interrupt.
>
> Could anyone please help me to understand what could be the reason behind this? How to solve it to take minimum time?
>
> Is there any standard calls which we need to follow in order to get faster performance?
>
First step would be to read Documentation/networking/scaling.txt and see if anything there helps.
Have you tried to profile the kernel and see if some contention or hot function appears ?
Maybe use a faster cpu, or remove not needed features like too heavy netfilter rules.
We can not really answer your question, you do not provide enough information.
^ permalink raw reply
* [PATCH v1 net] lan743x: Remove SPI dependency from Microchip group.
From: Bryan Whitehead @ 2018-10-25 17:09 UTC (permalink / raw)
To: davem; +Cc: netdev, UNGLinuxDriver
In-Reply-To: <1540487378-18986-1-git-send-email-Bryan.Whitehead@microchip.com>
The SPI dependency does not apply to lan743x driver, and other
drivers in the group already state their dependence on SPI.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
---
drivers/net/ethernet/microchip/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/microchip/Kconfig b/drivers/net/ethernet/microchip/Kconfig
index 16bd3f4..cf1d491 100644
--- a/drivers/net/ethernet/microchip/Kconfig
+++ b/drivers/net/ethernet/microchip/Kconfig
@@ -5,7 +5,6 @@
config NET_VENDOR_MICROCHIP
bool "Microchip devices"
default y
- depends on SPI
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
--
2.7.4
^ permalink raw reply related
* [PATCH v1 net] lan743x: Remove SPI dependency from Microchip group
From: Bryan Whitehead @ 2018-10-25 17:09 UTC (permalink / raw)
To: davem; +Cc: netdev, UNGLinuxDriver
The SPI dependency does not apply to lan743x driver, and other
drivers in the group already state their dependence on SPI.
Bryan Whitehead (1):
lan743x: Remove SPI dependency from Microchip group.
drivers/net/ethernet/microchip/Kconfig | 1 -
1 file changed, 1 deletion(-)
--
2.7.4
^ permalink raw reply
* Re: netif_receive_skb is taking long time
From: Eric Dumazet @ 2018-10-25 17:08 UTC (permalink / raw)
To: Keyur Amrutbhai Patel, netdev@vger.kernel.org
In-Reply-To: <BN6PR02MB2641D863865B2498ACD2043DB7F70@BN6PR02MB2641.namprd02.prod.outlook.com>
On 10/25/2018 08:39 AM, Keyur Amrutbhai Patel wrote:
> Hi,
>
> In my NIC driver "netif_receive_skb" is taking too long time. Almost 3375 neno seconds. Which is more than whole packet processing from interrupt.
>
> Could anyone please help me to understand what could be the reason behind this? How to solve it to take minimum time?
>
> Is there any standard calls which we need to follow in order to get faster performance?
>
First step would be to read Documentation/networking/scaling.txt and see if anything there helps.
Have you tried to profile the kernel and see if some contention or hot function appears ?
Maybe use a faster cpu, or remove not needed features like too heavy netfilter rules.
We can not really answer your question, you do not provide enough information.
^ permalink raw reply
* RE: netif_receive_skb is taking long time
From: Keyur Amrutbhai Patel @ 2018-10-25 17:05 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <BN6PR02MB2641D863865B2498ACD2043DB7F70@BN6PR02MB2641.namprd02.prod.outlook.com>
Any help on this would be appreciated.
-----Original Message-----
From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On Behalf Of Keyur Amrutbhai Patel
Sent: Thursday, October 25, 2018 9:09 PM
To: netdev@vger.kernel.org
Subject: netif_receive_skb is taking long time
Hi,
In my NIC driver "netif_receive_skb" is taking too long time. Almost 3375 neno seconds. Which is more than whole packet processing from interrupt.
Could anyone please help me to understand what could be the reason behind this? How to solve it to take minimum time?
Is there any standard calls which we need to follow in order to get faster performance?
Regards,
Keyur
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH net] r8169: fix broken Wake-on-LAN from S5 (poweroff)
From: Heiner Kallweit @ 2018-10-25 16:40 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers
Cc: netdev@vger.kernel.org, Neil MacLeod
It was reported that WoL from S5 is broken (WoL from S3 works) and the
analysis showed that during system shutdown the network interface was
brought down already when the actual kernel shutdown started.
Therefore netif_running() returned false and as a consequence the PHY
was suspended. Obviously WoL wasn't working then.
To fix this the original patch needs to be effectively reverted.
A side effect is that when normally bringing down the interface and
WoL is enabled the PHY will remain powered on (like it was before the
original patch).
Fixes: fe87bef01f9b ("r8169: don't check WoL when powering down PHY and interface is down")
Reported-by: Neil MacLeod <neil@nmacleod.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 0d8070adc..987fedeee 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4162,10 +4162,15 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!netif_running(tp->dev) || !__rtl8169_get_wol(tp))
+ struct phy_device *phydev;
+
+ if (!__rtl8169_get_wol(tp))
return false;
- phy_speed_down(tp->dev->phydev, false);
+ /* phydev may not be attached to netdevice */
+ phydev = mdiobus_get_phy(tp->mii_bus, 0);
+
+ phy_speed_down(phydev, false);
rtl_wol_suspend_quirk(tp);
return true;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH bpf] bpf: add bpf_jit_limit knob to restrict unpriv allocations
From: Alexei Starovoitov @ 2018-10-26 0:17 UTC (permalink / raw)
To: Daniel Borkmann
Cc: ast, rick.p.edgecombe, eric.dumazet, jannh, keescook,
linux-kernel, netdev
In-Reply-To: <20181022231104.3443-1-daniel@iogearbox.net>
On Tue, Oct 23, 2018 at 01:11:04AM +0200, Daniel Borkmann wrote:
> Rick reported that the BPF JIT could potentially fill the entire module
> space with BPF programs from unprivileged users which would prevent later
> attempts to load normal kernel modules or privileged BPF programs, for
> example. If JIT was enabled but unsuccessful to generate the image, then
> before commit 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> we would always fall back to the BPF interpreter. Nowadays in the case
> where the CONFIG_BPF_JIT_ALWAYS_ON could be set, then the load will abort
> with a failure since the BPF interpreter was compiled out.
>
> Add a global limit and enforce it for unprivileged users such that in case
> of BPF interpreter compiled out we fail once the limit has been reached
> or we fall back to BPF interpreter earlier w/o using module mem if latter
> was compiled in. In a next step, fair share among unprivileged users can
> be resolved in particular for the case where we would fail hard once limit
> is reached.
>
> Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
> Co-Developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jann Horn <jannh@google.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: LKML <linux-kernel@vger.kernel.org>
> ---
> Hi Rick, I've reworked the original patch into something much simpler
> which is only focussing on the actual main issue we want to resolve right
> now as a first step to make some forward progress, that is, limiting usage
> on the JIT for unprivileged users. Tested the below on x86 and arm64.
> (Trimmed down massive Cc list as well a bit and Cc'ed people related to
> commits referenced and netdev where BPF patches are usually discussed.)
> Thanks a lot!
Applied to bpf tree. Thanks Daniel.
^ permalink raw reply
* netif_receive_skb is taking long time
From: Keyur Amrutbhai Patel @ 2018-10-25 15:39 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
In my NIC driver "netif_receive_skb" is taking too long time. Almost 3375 neno seconds. Which is more than whole packet processing from interrupt.
Could anyone please help me to understand what could be the reason behind this? How to solve it to take minimum time?
Is there any standard calls which we need to follow in order to get faster performance?
Regards,
Keyur
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH net-next v8 28/28] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-10-26 0:00 UTC (permalink / raw)
To: Andrew Lunn
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <20181025225344.GD6276@lunn.ch>
Hi Andrew,
On Fri, Oct 26, 2018 at 12:53 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > This is on the hot path, actually. Well, it's not on path of data
> > packets, but I do consider handshake packets to be fairly "warm".
>
> So for me, hot path is something called 10 million timers per
> second. How often do handshake packets happen?
I can actually imagine situations in which this rate might happen.
Handshake performance is important.
Jason
^ permalink raw reply
* Re: [PATCH net-next v8 28/28] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-10-25 23:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <20181025223746.GB6276@lunn.ch>
Hi Andrew,
On Fri, Oct 26, 2018 at 12:37 AM Andrew Lunn <andrew@lunn.ch> wrote:
> I can understand that. But on the flip side, CAKE reached something
> like version 19 before it got merged. Wireguard is looking similar.
> An addition like the above, is not controversial. You could submit
> such a single patch in a weeks time when net-next reopens, and
> probably version 1 or 2 will get accepted.
Alright, maybe I'll give it a try that way. Previously, every time I
wanted to send things upstream for WireGuard, I'd be sure to find
other users in the tree of what I was adding, since WireGuard wasn't
ready for patchsets yet. But I guess now that some series have begun,
it's more acceptable to add APIs here and there as you described.
Jason
^ permalink raw reply
* Re: [PATCH net-next v8 28/28] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-10-25 23:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <20181025224426.GC6276@lunn.ch>
Hi Andrew,
On Fri, Oct 26, 2018 at 12:44 AM Andrew Lunn <andrew@lunn.ch> wrote:
> Out of tree is important here. To some degree, mainline does not care
> about out of tree drivers. Putting in a bandaid for them does not help
> get them fixed.
>
> I would drop this bandaid. If the Android community decides to move
> wireguard from mainline into their fork, they can put the bandaid back
> in again, or get the driver fixed.
No out-of-tree is really not important here, and sorry if mentioning
that in my explanation was distracting and caused you to
misunderstand. The issue isn't the crazy wireless driver; the issue is
that suspend on Android happens all the time, and the entire Android
way of using Linux is centered around non-stop suspending, with
triggers to wake up (wifi drivers, for example, like the out-of-tree
qcacld one, but presumably in tree ones too), and ways of controlling
when it goes to sleep (screen blanking, wakelocks, etc). The Android
model of Linux revolves around this, and hence the suspend semantics
for WireGuard respect this model and adjust accordingly, using the
appropriate CONFIG_ANDROID to determine which model we're operating
under. This is not a bandaid, and it doesn't have to do with forks of
the Linux kernel.
Jason
^ permalink raw reply
* Re: [PATCH v2 1/3] bpf: allow zero-initializing hash map seed
From: Lorenz Bauer @ 2018-10-25 15:12 UTC (permalink / raw)
To: liu.song.a23; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-api
In-Reply-To: <CAPhsuW5_1LRw=tjaNWfgrPKaS_Rs12BYAHPOjmXwEs8C9YSy1Q@mail.gmail.com>
On Tue, 9 Oct 2018 at 01:08, Song Liu <liu.song.a23@gmail.com> wrote:
>
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -253,6 +253,8 @@ enum bpf_attach_type {
> > #define BPF_F_NO_COMMON_LRU (1U << 1)
> > /* Specify numa node during map creation */
> > #define BPF_F_NUMA_NODE (1U << 2)
> > +/* Zero-initialize hash function seed. This should only be used for testing. */
> > +#define BPF_F_ZERO_SEED (1U << 6)
>
> Please add this line after
> #define BPF_F_STACK_BUILD_ID (1U << 5)
I wanted to keep the flags for BPF_MAP_CREATE grouped together.
Maybe the correct value is (1U << 3)? It seemed like the other flags
were allocated to avoid
overlap between different BPF commands, however, so I tried to follow suit.
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* Re: [PATCH v2 2/3] tools: sync linux/bpf.h
From: Lorenz Bauer @ 2018-10-25 15:07 UTC (permalink / raw)
To: liu.song.a23; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-api
In-Reply-To: <CAPhsuW5fbhQ1SBurL2q6hm=yV0a_Vw-_gjsz8LHJ76QwcqVXsQ@mail.gmail.com>
On Tue, 9 Oct 2018 at 01:12, Song Liu <liu.song.a23@gmail.com> wrote:
>
> On Mon, Oct 8, 2018 at 3:34 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
> >
> > Synchronize changes to linux/bpf.h from
> > commit 88db241b34bf ("bpf: allow zero-initializing hash map seed").
> I guess we cannot keep this hash during git-am? We probably don't
> need this hash anyway, as the two patches will be applied back to back.
I copied what was done in one of the previous commits that synced the
header. I'm a bit at a
loss what to put in the commit message otherwise.
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* Re: [RFC net-next v2 2/8] net: add netif_is_geneve()
From: John Hurley @ 2018-10-25 14:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Netdev List, oss-drivers, Or Gerlitz, ozsh, Jakub Kicinski,
Simon Horman, avivh
In-Reply-To: <20181025125416.GE2143@nanopsycho>
On Thu, Oct 25, 2018 at 2:00 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Thu, Oct 25, 2018 at 02:26:51PM CEST, john.hurley@netronome.com wrote:
> >Add a helper function to determine if the type of a netdev is geneve based
> >on its rtnl_link_ops. This allows drivers that may wish to ofload tunnels
> >to check the underlying type of the device.
> >
> >A recent patch added a similar helper to vxlan.h
> >
> >Signed-off-by: John Hurley <john.hurley@netronome.com>
> >Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> I don't understand why this and the next patch are part of this
> patchset. They don't seem directly related.
This is used in later patches that implement the indirect block
offload but I suppose it is not directly related.
We can probably move it to a separate patchset.
Thanks
^ permalink raw reply
* Re: [RFC net-next v2 0/8] indirect tc block cb registration
From: John Hurley @ 2018-10-25 14:56 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Netdev List, oss-drivers, Or Gerlitz, ozsh, Jakub Kicinski,
Simon Horman, avivh
In-Reply-To: <20181025125241.GD2143@nanopsycho>
On Thu, Oct 25, 2018 at 1:58 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Thu, Oct 25, 2018 at 02:26:49PM CEST, john.hurley@netronome.com wrote:
> >This patchset introduces an alternative to egdev offload by allowing a
> >driver to register for block updates when an external device (e.g. tunnel
> >netdev) is bound to a TC block. Drivers can track new netdevs or register
> >to existing ones to receive information on such events. Based on this,
> >they may register for block offload rules using already existing
> >functions.
> >
> >The patchset also implements this new indirect block registration in the
> >NFP driver to allow the offloading of tunnel rules. The use of egdev
> >offload (which is currently only used for tunnel offload) is subsequently
> >removed.
>
> John, I'm missing v1->v2 changelog. Could you please add it?
>
> Thanks!
Hi Jiri,
There's little change outside the NFP in v2 but here's short changelog:
v1->v2:
- free allocated owner struct in block_owner_clean function
- add geneve type helper function
- move test stub in NFP (v1 patch 2) to full tunnel offload
implementation via indirect blocks (v2 patches 3-8)
^ permalink raw reply
* for your images 15
From: Kate @ 2018-10-24 11:38 UTC (permalink / raw)
To: netdev
We are an imaging team who can process 300+ images daily.
If you need any image editing service, please contact us today.
We do mainly images cut out and clipping path, masking.
Such as for your ecommerce photos, jewelry photos retouching, also it is
for beauty portraits and skin images
and wedding photos.
We provide test editing if you send some photos.
Thanks,
Kate
^ permalink raw reply
* for your images 15
From: Kate @ 2018-10-24 11:42 UTC (permalink / raw)
To: netdev
We are an imaging team who can process 300+ images daily.
If you need any image editing service, please contact us today.
We do mainly images cut out and clipping path, masking.
Such as for your ecommerce photos, jewelry photos retouching, also it is
for beauty portraits and skin images
and wedding photos.
We provide test editing if you send some photos.
Thanks,
Kate
^ 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