* [PATCH v9 20/20] crypto: adapt api sample to use async. op wait
From: Gilad Ben-Yossef @ 2017-10-15 9:20 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
Documentation/crypto/api-samples.rst | 52 +++++++-----------------------------
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst
index 2531948..006827e 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation
::
- struct tcrypt_result {
- struct completion completion;
- int err;
- };
-
/* tie all data structures together */
struct skcipher_def {
struct scatterlist sg;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
- struct tcrypt_result result;
+ struct crypto_wait wait;
};
- /* Callback function */
- static void test_skcipher_cb(struct crypto_async_request *req, int error)
- {
- struct tcrypt_result *result = req->data;
-
- if (error == -EINPROGRESS)
- return;
- result->err = error;
- complete(&result->completion);
- pr_info("Encryption finished successfully\n");
- }
-
/* Perform cipher operation */
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
- int rc = 0;
+ int rc;
if (enc)
- rc = crypto_skcipher_encrypt(sk->req);
+ rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait);
else
- rc = crypto_skcipher_decrypt(sk->req);
-
- switch (rc) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- rc = wait_for_completion_interruptible(
- &sk->result.completion);
- if (!rc && !sk->result.err) {
- reinit_completion(&sk->result.completion);
- break;
- }
- default:
- pr_info("skcipher encrypt returned with %d result %d\n",
- rc, sk->result.err);
- break;
- }
- init_completion(&sk->result.completion);
+ rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait);
+
+ if (rc)
+ pr_info("skcipher encrypt returned with result %d\n", rc);
return rc;
}
@@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation
}
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- test_skcipher_cb,
- &sk.result);
+ crypto_req_done,
+ &sk.wait);
/* AES 256 with random key */
get_random_bytes(&key, 32);
@@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation
/* We encrypt one block */
sg_init_one(&sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
- init_completion(&sk.result.completion);
+ crypto_init_wait(&sk.wait);
/* encrypt data */
ret = test_skcipher_encdec(&sk, 1);
--
2.7.4
^ permalink raw reply related
* [PATCH v9 06/20] crypto: introduce crypto wait for async op
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, Eric Biggers, Jonathan Cameron, linux-crypto,
linux-doc, linux-kernel, keyrings, linux-arm-kernel,
linux-mediatek, linux-cifs, samba-technical, linux-fscrypt,
netdev, linux-ima-devel, linux-ima-user, linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.
This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: Eric Biggers <ebiggers3@gmail.com>
CC: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
crypto/api.c | 13 +++++++++++++
include/linux/crypto.h | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/crypto/api.c b/crypto/api.c
index 941cd4c..2a2479d 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -24,6 +24,7 @@
#include <linux/sched/signal.h>
#include <linux/slab.h>
#include <linux/string.h>
+#include <linux/completion.h>
#include "internal.h"
LIST_HEAD(crypto_alg_list);
@@ -595,5 +596,17 @@ int crypto_has_alg(const char *name, u32 type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_has_alg);
+void crypto_req_done(struct crypto_async_request *req, int err)
+{
+ struct crypto_wait *wait = req->data;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ wait->err = err;
+ complete(&wait->completion);
+}
+EXPORT_SYMBOL_GPL(crypto_req_done);
+
MODULE_DESCRIPTION("Cryptographic core API");
MODULE_LICENSE("GPL");
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 84da997..78508ca 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/uaccess.h>
+#include <linux/completion.h>
/*
* Autoloaded crypto modules should only use a prefixed name to avoid allowing
@@ -468,6 +469,45 @@ struct crypto_alg {
} CRYPTO_MINALIGN_ATTR;
/*
+ * A helper struct for waiting for completion of async crypto ops
+ */
+struct crypto_wait {
+ struct completion completion;
+ int err;
+};
+
+/*
+ * Macro for declaring a crypto op async wait object on stack
+ */
+#define DECLARE_CRYPTO_WAIT(_wait) \
+ struct crypto_wait _wait = { \
+ COMPLETION_INITIALIZER_ONSTACK((_wait).completion), 0 }
+
+/*
+ * Async ops completion helper functioons
+ */
+void crypto_req_done(struct crypto_async_request *req, int err);
+
+static inline int crypto_wait_req(int err, struct crypto_wait *wait)
+{
+ switch (err) {
+ case -EINPROGRESS:
+ case -EBUSY:
+ wait_for_completion(&wait->completion);
+ reinit_completion(&wait->completion);
+ err = wait->err;
+ break;
+ };
+
+ return err;
+}
+
+static inline void crypto_init_wait(struct crypto_wait *wait)
+{
+ init_completion(&wait->completion);
+}
+
+/*
* Algorithm registration interface.
*/
int crypto_register_alg(struct crypto_alg *alg);
--
2.7.4
^ permalink raw reply related
* [PATCH v9 16/20] crypto: tcrypt: move to generic async completion
From: Gilad Ben-Yossef @ 2017-10-15 9:20 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
tcrypt starts several async crypto ops and waits for their completions.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
crypto/tcrypt.c | 84 +++++++++++++++++----------------------------------------
1 file changed, 25 insertions(+), 59 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index a371c072..7fa7047 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -79,34 +79,11 @@ static char *check[] = {
NULL
};
-struct tcrypt_result {
- struct completion completion;
- int err;
-};
-
-static void tcrypt_complete(struct crypto_async_request *req, int err)
-{
- struct tcrypt_result *res = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
static inline int do_one_aead_op(struct aead_request *req, int ret)
{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- struct tcrypt_result *tr = req->base.data;
+ struct crypto_wait *wait = req->base.data;
- ret = wait_for_completion_interruptible(&tr->completion);
- if (!ret)
- ret = tr->err;
- reinit_completion(&tr->completion);
- }
-
- return ret;
+ return crypto_wait_req(ret, wait);
}
static int test_aead_jiffies(struct aead_request *req, int enc,
@@ -248,7 +225,7 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs,
char *axbuf[XBUFSIZE];
unsigned int *b_size;
unsigned int iv_len;
- struct tcrypt_result result;
+ struct crypto_wait wait;
iv = kzalloc(MAX_IVLEN, GFP_KERNEL);
if (!iv)
@@ -284,7 +261,7 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs,
goto out_notfm;
}
- init_completion(&result.completion);
+ crypto_init_wait(&wait);
printk(KERN_INFO "\ntesting speed of %s (%s) %s\n", algo,
get_driver_name(crypto_aead, tfm), e);
@@ -296,7 +273,7 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs,
}
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &result);
+ crypto_req_done, &wait);
i = 0;
do {
@@ -396,21 +373,16 @@ static void test_hash_sg_init(struct scatterlist *sg)
static inline int do_one_ahash_op(struct ahash_request *req, int ret)
{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- struct tcrypt_result *tr = req->base.data;
+ struct crypto_wait *wait = req->base.data;
- wait_for_completion(&tr->completion);
- reinit_completion(&tr->completion);
- ret = tr->err;
- }
- return ret;
+ return crypto_wait_req(ret, wait);
}
struct test_mb_ahash_data {
struct scatterlist sg[TVMEMSIZE];
char result[64];
struct ahash_request *req;
- struct tcrypt_result tresult;
+ struct crypto_wait wait;
char *xbuf[XBUFSIZE];
};
@@ -439,7 +411,7 @@ static void test_mb_ahash_speed(const char *algo, unsigned int sec,
if (testmgr_alloc_buf(data[i].xbuf))
goto out;
- init_completion(&data[i].tresult.completion);
+ crypto_init_wait(&data[i].wait);
data[i].req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!data[i].req) {
@@ -448,8 +420,8 @@ static void test_mb_ahash_speed(const char *algo, unsigned int sec,
goto out;
}
- ahash_request_set_callback(data[i].req, 0,
- tcrypt_complete, &data[i].tresult);
+ ahash_request_set_callback(data[i].req, 0, crypto_req_done,
+ &data[i].wait);
test_hash_sg_init(data[i].sg);
}
@@ -491,16 +463,16 @@ static void test_mb_ahash_speed(const char *algo, unsigned int sec,
if (ret)
break;
- complete(&data[k].tresult.completion);
- data[k].tresult.err = 0;
+ crypto_req_done(&data[k].req->base, 0);
}
for (j = 0; j < k; j++) {
- struct tcrypt_result *tr = &data[j].tresult;
+ struct crypto_wait *wait = &data[j].wait;
+ int wait_ret;
- wait_for_completion(&tr->completion);
- if (tr->err)
- ret = tr->err;
+ wait_ret = crypto_wait_req(-EINPROGRESS, wait);
+ if (wait_ret)
+ ret = wait_ret;
}
end = get_cycles();
@@ -678,7 +650,7 @@ static void test_ahash_speed_common(const char *algo, unsigned int secs,
struct hash_speed *speed, unsigned mask)
{
struct scatterlist sg[TVMEMSIZE];
- struct tcrypt_result tresult;
+ struct crypto_wait wait;
struct ahash_request *req;
struct crypto_ahash *tfm;
char *output;
@@ -707,9 +679,9 @@ static void test_ahash_speed_common(const char *algo, unsigned int secs,
goto out;
}
- init_completion(&tresult.completion);
+ crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &tresult);
+ crypto_req_done, &wait);
output = kmalloc(MAX_DIGEST_SIZE, GFP_KERNEL);
if (!output)
@@ -764,15 +736,9 @@ static void test_hash_speed(const char *algo, unsigned int secs,
static inline int do_one_acipher_op(struct skcipher_request *req, int ret)
{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- struct tcrypt_result *tr = req->base.data;
-
- wait_for_completion(&tr->completion);
- reinit_completion(&tr->completion);
- ret = tr->err;
- }
+ struct crypto_wait *wait = req->base.data;
- return ret;
+ return crypto_wait_req(ret, wait);
}
static int test_acipher_jiffies(struct skcipher_request *req, int enc,
@@ -852,7 +818,7 @@ static void test_skcipher_speed(const char *algo, int enc, unsigned int secs,
unsigned int tcount, u8 *keysize, bool async)
{
unsigned int ret, i, j, k, iv_len;
- struct tcrypt_result tresult;
+ struct crypto_wait wait;
const char *key;
char iv[128];
struct skcipher_request *req;
@@ -865,7 +831,7 @@ static void test_skcipher_speed(const char *algo, int enc, unsigned int secs,
else
e = "decryption";
- init_completion(&tresult.completion);
+ crypto_init_wait(&wait);
tfm = crypto_alloc_skcipher(algo, 0, async ? 0 : CRYPTO_ALG_ASYNC);
@@ -886,7 +852,7 @@ static void test_skcipher_speed(const char *algo, int enc, unsigned int secs,
}
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &tresult);
+ crypto_req_done, &wait);
i = 0;
do {
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2 1/1] tests: Revert back /bin/sh in shebang
From: Petr Vorel @ 2017-10-15 9:59 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel
This was added by mistake in commit ecd44e68
("tests: Remove bashisms (s/source/.)")
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
---
testsuite/tests/ip/route/add_default_route.t | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuite/tests/ip/route/add_default_route.t b/testsuite/tests/ip/route/add_default_route.t
index 0b566f1f..569ba1f8 100755
--- a/testsuite/tests/ip/route/add_default_route.t
+++ b/testsuite/tests/ip/route/add_default_route.t
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
. lib/generic.sh
--
2.14.2
^ permalink raw reply related
* RFC: making cn_proc work in {pid,user} namespaces
From: Aleksa Sarai @ 2017-10-15 10:05 UTC (permalink / raw)
To: Linux Containers, netdev
Cc: linux-kernel, Christian Brauner, Eric W. Biederman,
Evgeniy Polyakov, dev, cyphar@cyphar.com >> Aleksa Sarai
Hi all,
At the moment, cn_proc is not usable by containers or container
runtimes. In addition, all connectors have an odd relationship with
init_net (for example, /proc/net/connectors only exists in init_net).
There are two main use-cases that would be perfect for cn_proc, which is
the reason for me pushing this:
First, when adding a process to an existing container, in certain modes
runc would like to know that process's exit code. But, when joining a
PID namespace, it is advisable[1] to always double-fork after doing the
setns(2) to reparent the joining process to the init of the container
(this causes the SIGCHLD to be received by the container init). It would
also be useful to be able to monitor the exit code of the init process
in a container without being its parent. At the moment, cn_proc doesn't
allow unprivileged users to use it (making it a problem for user
namespaces and "rootless containers"). In addition, it also doesn't
allow nested containers to use it, because it requires the process to be
in init_pid. As a result, runc cannot use cn_proc and relies on SIGCHLD
(which can only be used if we don't double-fork, or keep around a
long-running process which is something that runc also cannot do).
Secondly, there are/were some init systems that rely on cn_proc to
manage service state. From a "it would be neat" perspective, I think it
would be quite nice if such init systems could be used inside
containers. But that requires cn_proc to be able to be used as an
unprivileged user and in a pid namespace other than init_pid.
The /proc/net/connectors thing is quite easily resolved (just make it
the connector driver perdev and make some small changes to make sure the
interfaces stay sane inside of a container's network namespace). I'm
sure that we'll probably have to make some changes to the registration
API, so that a connector can specify whether they want to be visible to
non-init_net namespaces.
However, the cn_proc problem is a bit harder to resolve nicely and there
are quite a few interface questions that would need to be agreed upon.
The basic idea would be that a process can only get cn_proc events if it
has ptrace_may_access rights over said process (effectively a forced
filter -- which would ideally be done send-side but it looks like it
might have to be done receive-side). This should resolve possible
concerns about an unprivileged process being able to inspect (fairly
granular) information about the host. And obviously the pids, uids, and
gids would all be translated according to the receiving process's user
namespaces (if it cannot be translated then the message is not
received). I guess that the translation would be done in the same way as
SCM_CREDENTIALS (and cgroup.procs files), which is that it's done on the
receive side not the send side.
My reason for sending this email rather than just writing the patch is
to see whether anyone has any solid NACKs against the use-case or
whether there is some fundamental issue that I'm not seeing. If nobody
objects, I'll be happy to work on this.
[1]: https://lwn.net/Articles/532748/
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
^ permalink raw reply
* Re: [PATCH] tests: Remove bashisms (s/source/.)
From: Petr Vorel @ 2017-10-15 10:05 UTC (permalink / raw)
To: Rustad, Mark D; +Cc: netdev@vger.kernel.org
In-Reply-To: <C7ED1FFD-C1B2-4543-9DBD-B633E7D0AA30@intel.com>
Hi Mark,
> > --- a/testsuite/tests/ip/route/add_default_route.t
> > +++ b/testsuite/tests/ip/route/add_default_route.t
> > @@ -1,6 +1,6 @@
> > -#!/bin/sh
> > +#!/bin/bash
> Funny - ^^^ choosing bash explicitly while
> vvvv removing the bashism?
Eh, this is really silly, sorry. I've sent a patch to revert it back as it was unintentional.
> I noticed a couple other files already specified /bin/bash, yet you removed the bashisms. But the above struck me as something that would not seem to have been intended.
I plan to remove all bashisms. Although having explicit dependency on bash (i.e. /bin/bash
in shebang), it would be nice have posix compliant shell scripts (as Randy Dunlap also
noted). Or at least don't have bashisms in script with /bin/sh shebang.
Kind regards,
Petr
^ permalink raw reply
* [PATCH net 0/6] rtnetlink: a bunch of fixes for userspace notifications in changing dev properties
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
Whenever any property of a link, address, route, etc. changes by whatever way,
kernel should notify the programs that listen for such events in userspace.
The patchet "rtnetlink: Cleanup user notifications for netdev events" tried to
fix a redundant notifications issue, but it also introduced a side effect.
After that, user notifications could only be sent when changing dev properties
via netlink api. As it removed some events process in rtnetlink_event where
the notifications was sent to users.
It resulted in no notification generated when dev properties are changed via
other ways, like ioctl, sysfs, etc. It may cause some user programs doesn't
work as expected because of the missing notifications.
This patchset will fix it by bringing some of these netdev events back and
also fix the old redundant notifications issue with a proper way.
Xin Long (6):
rtnetlink: bring NETDEV_CHANGEMTU event process back in
rtnetlink_event
rtnetlink: bring NETDEV_CHANGE_TX_QUEUE_LEN event process back in
rtnetlink_event
rtnetlink: bring NETDEV_POST_TYPE_CHANGE event process back in
rtnetlink_event
rtnetlink: bring NETDEV_CHANGEUPPER event process back in
rtnetlink_event
rtnetlink: check DO_SETLINK_NOTIFY correctly in do_setlink
rtnetlink: do not set notification for tx_queue_len in do_setlink
net/core/rtnetlink.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 1/6] rtnetlink: bring NETDEV_CHANGEMTU event process back in rtnetlink_event
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
Commit 085e1a65f04f ("rtnetlink: Do not generate notifications for MTU
events") tried to fix the redundant notifications issue when ip link
set mtu by removing NETDEV_CHANGEMTU event process in rtnetlink_event.
But it also resulted in no notification generated when dev's mtu is
changed via other methods, like:
'ifconfig eth1 mtu 1400' or 'echo 1400 > /sys/class/net/eth1/mtu'
It would cause users not to be notified by this change.
This patch is to fix it by bringing NETDEV_CHANGEMTU event back into
rtnetlink_event, and the redundant notifications issue will be fixed
in the later patch 'rtnetlink: check DO_SETLINK_NOTIFY correctly in
do_setlink'.
Fixes: 085e1a65f04f ("rtnetlink: Do not generate notifications for MTU events")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d4bcdcc..72053ed 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4279,6 +4279,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
switch (event) {
case NETDEV_REBOOT:
+ case NETDEV_CHANGEMTU:
case NETDEV_CHANGEADDR:
case NETDEV_CHANGENAME:
case NETDEV_FEAT_CHANGE:
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/6] rtnetlink: bring NETDEV_CHANGE_TX_QUEUE_LEN event process back in rtnetlink_event
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
The same fix for changing mtu in the patch 'rtnetlink: bring
NETDEV_CHANGEMTU event process back in rtnetlink_event' is
needed for changing tx_queue_len.
Note that the redundant notifications issue for tx_queue_len
will be fixed in the later patch 'rtnetlink: do not send
notification for tx_queue_len in do_setlink'.
Fixes: 27b3b551d8a7 ("rtnetlink: Do not generate notifications for NETDEV_CHANGE_TX_QUEUE_LEN event")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 72053ed..bf47360 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4287,6 +4287,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_NOTIFY_PEERS:
case NETDEV_RESEND_IGMP:
case NETDEV_CHANGEINFODATA:
+ case NETDEV_CHANGE_TX_QUEUE_LEN:
rtmsg_ifinfo_event(RTM_NEWLINK, dev, 0, rtnl_get_event(event),
GFP_KERNEL);
break;
--
2.1.0
^ permalink raw reply related
* [PATCH net 3/6] rtnetlink: bring NETDEV_POST_TYPE_CHANGE event process back in rtnetlink_event
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
As I said in patch 'rtnetlink: bring NETDEV_CHANGEMTU event process back
in rtnetlink_event', removing NETDEV_POST_TYPE_CHANGE event was not the
right fix for the redundant notifications issue.
So bring this event process back to rtnetlink_event and the old redundant
notifications issue would be fixed in the later patch 'rtnetlink: check
DO_SETLINK_NOTIFY correctly in do_setlink'.
Fixes: aef091ae58aa ("rtnetlink: Do not generate notifications for POST_TYPE_CHANGE event")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index bf47360..8e44fd5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4284,6 +4284,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_CHANGENAME:
case NETDEV_FEAT_CHANGE:
case NETDEV_BONDING_FAILOVER:
+ case NETDEV_POST_TYPE_CHANGE:
case NETDEV_NOTIFY_PEERS:
case NETDEV_RESEND_IGMP:
case NETDEV_CHANGEINFODATA:
--
2.1.0
^ permalink raw reply related
* [PATCH net 4/6] rtnetlink: bring NETDEV_CHANGEUPPER event process back in rtnetlink_event
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
libteam needs this event notification in userspace when dev's master
dev has been changed. After this, the redundant notifications issue
would be fixed in the later patch 'rtnetlink: check DO_SETLINK_NOTIFY
correctly in do_setlink'.
Fixes: b6b36eb23a46 ("rtnetlink: Do not generate notifications for NETDEV_CHANGEUPPER event")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8e44fd5..ab98c1c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4286,6 +4286,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_BONDING_FAILOVER:
case NETDEV_POST_TYPE_CHANGE:
case NETDEV_NOTIFY_PEERS:
+ case NETDEV_CHANGEUPPER:
case NETDEV_RESEND_IGMP:
case NETDEV_CHANGEINFODATA:
case NETDEV_CHANGE_TX_QUEUE_LEN:
--
2.1.0
^ permalink raw reply related
* [PATCH net 5/6] rtnetlink: check DO_SETLINK_NOTIFY correctly in do_setlink
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
The check 'status & DO_SETLINK_NOTIFY' in do_setlink doesn't really
work after status & DO_SETLINK_MODIFIED, as:
DO_SETLINK_MODIFIED 0x1
DO_SETLINK_NOTIFY 0x3
Considering that notifications are suppposed to be sent only when
status have the flag DO_SETLINK_NOTIFY, the right check would be:
(status & DO_SETLINK_NOTIFY) == DO_SETLINK_NOTIFY
This would avoid lots of duplicated notifications when setting some
properties of a link.
Fixes: ba9989069f4e ("rtnl/do_setlink(): notify when a netdev is modified")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ab98c1c..3e98fb5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2248,7 +2248,7 @@ static int do_setlink(const struct sk_buff *skb,
errout:
if (status & DO_SETLINK_MODIFIED) {
- if (status & DO_SETLINK_NOTIFY)
+ if ((status & DO_SETLINK_NOTIFY) == DO_SETLINK_NOTIFY)
netdev_state_change(dev);
if (err < 0)
--
2.1.0
^ permalink raw reply related
* [PATCH net 6/6] rtnetlink: do not set notification for tx_queue_len in do_setlink
From: Xin Long @ 2017-10-15 10:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, hannes
In-Reply-To: <cover.1508062280.git.lucien.xin@gmail.com>
NETDEV_CHANGE_TX_QUEUE_LEN event process in rtnetlink_event would
send a notification for userspace and tx_queue_len's setting in
do_setlink would trigger NETDEV_CHANGE_TX_QUEUE_LEN.
So it shouldn't set DO_SETLINK_NOTIFY status for this change to
send a notification any more.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 3e98fb5..a6bcf86 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2093,7 +2093,7 @@ static int do_setlink(const struct sk_buff *skb,
dev->tx_queue_len = orig_len;
goto errout;
}
- status |= DO_SETLINK_NOTIFY;
+ status |= DO_SETLINK_MODIFIED;
}
}
--
2.1.0
^ permalink raw reply related
* [PATCH] ipvs: Fix inappropriate output of procfs
From: KUWAZAWA Takuya @ 2017-10-15 11:54 UTC (permalink / raw)
To: Wensong Zhang, Simon Horman, Julian Anastasov
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, netdev, lvs-devel, netfilter-devel, coreteam,
linux-kernel
Information about ipvs in different network namespace can be seen via procfs.
How to reproduce:
# ip netns add ns01
# ip netns add ns02
# ip netns exec ns01 ip a add dev lo 127.0.0.1/8
# ip netns exec ns02 ip a add dev lo 127.0.0.1/8
# ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
# ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80
The ipvsadm displays information about its own network namespace only.
# ip netns exec ns01 ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.1.1.1:80 wlc
# ip netns exec ns02 ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.1.1.2:80 wlc
But I can see information about other network namespace via procfs.
# ip netns exec ns01 cat /proc/net/ip_vs
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 0A010101:0050 wlc
TCP 0A010102:0050 wlc
# ip netns exec ns02 cat /proc/net/ip_vs
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 0A010102:0050 wlc
Signed-off-by: KUWAZAWA Takuya <albatross0@gmail.com>
---
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 4f940d7..b3245f9 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct seq_file *seq, void *v)
seq_puts(seq,
" -> RemoteAddress:Port Forward Weight ActiveConn InActConn\n");
} else {
+ struct net *net = seq_file_net(seq);
+ struct netns_ipvs *ipvs = net_ipvs(net);
const struct ip_vs_service *svc = v;
const struct ip_vs_iter *iter = seq->private;
const struct ip_vs_dest *dest;
struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
char *sched_name = sched ? sched->name : "none";
+ if (svc->ipvs != ipvs)
+ return 0;
if (iter->table == ip_vs_svc_table) {
#ifdef CONFIG_IP_VS_IPV6
if (svc->af == AF_INET6)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: only update __use and lastusetime once per jiffy at most
From: Paolo Abeni @ 2017-10-15 13:01 UTC (permalink / raw)
To: Martin KaFai Lau, Wei Wang; +Cc: David Miller, netdev, Eric Dumazet
In-Reply-To: <20171014000924.dcfuqxwlalaigqdq@kafai-mbp.dhcp.thefacebook.com>
On Fri, 2017-10-13 at 17:09 -0700, Martin KaFai Lau wrote:
> On Fri, Oct 13, 2017 at 10:08:07PM +0000, Wei Wang wrote:
> > From: Wei Wang <weiwan@google.com>
> >
> > In order to not dirty the cacheline too often, we try to only update
> > dst->__use and dst->lastusetime at most once per jiffy.
>
>
> > As dst->lastusetime is only used by ipv6 garbage collector, it should
> > be good enough time resolution.
>
> Make sense.
>
> > And __use is only used in ipv6_route_seq_show() to show how many times a
> > dst has been used. And as __use is not atomic_t right now, it does not
> > show the precise number of usage times anyway. So we think it should be
> > OK to only update it at most once per jiffy.
>
> If __use is only bumped HZ number of times per second and we can do ~3Mpps now,
> would __use be way off?
It would, but even nowaday such value could not be trusted, due to the
cuncurrent non atomic operation used to update it.
This:
https://marc.info/?l=linux-netdev&m=150653252930953&w=2
was an attempt to preserve a more meaningful value for '__use', but it
requires an additional cacheline.
I'm fine with either options.
Paolo
^ permalink raw reply
* [REGRESSION] rtl8723bs (r8723bs) WiFi stopped working on 4.14 on Chuwi Hi12 (Intel CherryTrail SoC)
From: Михаил Новоселов, ШЭМ Думалогия @ 2017-10-15 13:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello,
I've found a regression in kernel 4.14, the last tested kernel was the yesterday daily build http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/ , it worked on 4.12 and 4.13 and now on 4.14 it is able to scan for available networks, but is not able to get an IP adress.
I reported a bug to the kernel's bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197137
---------------------------------------------------------------------------------
Hardware platform: Chuwi Hi12 (intell cherrytrail tablet)
On Linux kernels 4.12 and 4.13 the WiFi does work, starting from 4.14 not release builds it does not, including some dily builds of the times somewhere near rc1, the rc3 release and the letest daily build of the code state for 2017-10-04 http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2017-10-05/
I will provide logs from 4.14 a bit later, bellow are LOGS FROM 4.13.1 with working WiFi
Full information on hardware and logs (including full dmesg) are here: https://linux-hardware.org/index.php?probe=01521aa6cf (kernel 4.13 and working wifi)
$ dmesg | grep rtl
[ 7.899105] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[ 7.899106] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
[ 10.570755] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin
Logs from 4.14 with WiFi not working: https://linux-hardware.org/index.php?probe=5c7b00c4cb
^ permalink raw reply
* (unknown),
From: marketing @ 2017-10-15 13:57 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 29848250.zip --]
[-- Type: application/zip, Size: 2816 bytes --]
^ permalink raw reply
* Re: [PATCH] ipvs: Fix inappropriate output of procfs
From: Julian Anastasov @ 2017-10-15 14:11 UTC (permalink / raw)
To: KUWAZAWA Takuya
Cc: Wensong Zhang, Simon Horman, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, netdev, lvs-devel,
netfilter-devel, coreteam, linux-kernel
In-Reply-To: <20171015115406.GA11429@nuc02.localdomain>
Hello,
On Sun, 15 Oct 2017, KUWAZAWA Takuya wrote:
> Information about ipvs in different network namespace can be seen via procfs.
>
> How to reproduce:
>
> # ip netns add ns01
> # ip netns add ns02
> # ip netns exec ns01 ip a add dev lo 127.0.0.1/8
> # ip netns exec ns02 ip a add dev lo 127.0.0.1/8
> # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
> # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80
>
> The ipvsadm displays information about its own network namespace only.
>
> # ip netns exec ns01 ipvsadm -Ln
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.1.1.1:80 wlc
>
> # ip netns exec ns02 ipvsadm -Ln
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.1.1.2:80 wlc
>
> But I can see information about other network namespace via procfs.
>
> # ip netns exec ns01 cat /proc/net/ip_vs
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 0A010101:0050 wlc
> TCP 0A010102:0050 wlc
>
> # ip netns exec ns02 cat /proc/net/ip_vs
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 0A010102:0050 wlc
>
> Signed-off-by: KUWAZAWA Takuya <albatross0@gmail.com>
Looks good to me
Acked-by: Julian Anastasov <ja@ssi.bg>
Simon, please apply to ipvs tree.
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 4f940d7..b3245f9 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct seq_file *seq, void *v)
> seq_puts(seq,
> " -> RemoteAddress:Port Forward Weight ActiveConn InActConn\n");
> } else {
> + struct net *net = seq_file_net(seq);
> + struct netns_ipvs *ipvs = net_ipvs(net);
> const struct ip_vs_service *svc = v;
> const struct ip_vs_iter *iter = seq->private;
> const struct ip_vs_dest *dest;
> struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
> char *sched_name = sched ? sched->name : "none";
>
> + if (svc->ipvs != ipvs)
> + return 0;
> if (iter->table == ip_vs_svc_table) {
> #ifdef CONFIG_IP_VS_IPV6
> if (svc->af == AF_INET6)
> --
> 1.8.3.1
Regards
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Masahiro Yamada @ 2017-10-15 14:52 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: netdev, Andrew Lunn, Florian Fainelli, Rob Herring, Mark Rutland,
linux-arm-kernel, Linux Kernel Mailing List, devicetree,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <1507854928-4357-2-git-send-email-hayashi.kunihiko@socionext.com>
2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@socionext.com>:
> DT bindings for the AVE ethernet controller found on Socionext's
> UniPhier platforms.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
> .../bindings/net/socionext,uniphier-ave4.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
>
> diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> new file mode 100644
> index 0000000..25f4d92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> @@ -0,0 +1,53 @@
> +* Socionext AVE ethernet controller
> +
> +This describes the devicetree bindings for AVE ethernet controller
> +implemented on Socionext UniPhier SoCs.
> +
> +Required properties:
> + - compatible: Should be
> + - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> + - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> + - "socionext,uniphier-ld20-ave4" : for LD20 SoC
> + - "socionext,uniphier-ld11-ave4" : for LD11 SoC
> + - reg: Address where registers are mapped and size of region.
> + - interrupts: Should contain the MAC interrupt.
> + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> + "rgmii", "rmii", or "mii" according to the PHY.
> + - pinctrl-names: List of assigned state names, see pinctrl
> + binding documentation.
> + - pinctrl-0: List of phandles to configure the GPIO pin,
> + see pinctrl binding documentation. Choose this appropriately
> + according to phy-mode.
> + - <&pinctrl_ether_rgmii> if phy-mode is "rgmii".
> + - <&pinctrl_ether_rmii> if phy-mode is "rmii".
> + - <&pinctrl_ether_mii> if phy-mode is "mii".
> + - phy-handle: Should point to the external phy device.
> + See ethernet.txt file in the same directory.
> + - mdio subnode: Should be device tree subnode with the following required
> + properties:
> + - #address-cells: Must be <1>.
> + - #size-cells: Must be <0>.
> + - reg: phy ID number, usually a small integer.
> +
> +Optional properties:
> + - local-mac-address: See ethernet.txt in the same directory.
> +
> +Example:
> +
> + ether: ethernet@65000000 {
> + compatible = "socionext,uniphier-ld20-ave4";
> + reg = <0x65000000 0x8500>;
> + interrupts = <0 66 4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ether_rgmii>;
> + phy-mode = "rgmii";
> + phy-handle = <ðphy>;
> + local-mac-address = [00 00 00 00 00 00];
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethphy@1 {
> + reg = <1>;
> + };
> + };
> + };
> --
> 2.7.4
>
I found the following code in 2/2.
+ /* get clock */
+ priv->clk = clk_get(dev, NULL);
+ if (IS_ERR(priv->clk))
+ priv->clk = NULL;
+
+ /* get reset */
+ priv->rst = reset_control_get(dev, NULL);
+ if (IS_ERR(priv->rst))
+ priv->rst = NULL;
+
This doc needs to describe "clocks", "resets".
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-15 15:03 UTC (permalink / raw)
To: Alexander Duyck
Cc: Anders K. Pedersen | Cohaesio, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, alexander.h.duyck@intel.com
In-Reply-To: <CAKgT0UcOWxnrsGEjTopPP-JKyKGTG3j6KNKUbhQRgaCStyzr_A@mail.gmail.com>
Previously attached graphs was for:
4.14.0-rc4-next-20171012
from git:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
In kernel drivers.
Just tested by replacing cards in server from 8x10G based on 82599 to
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 01)
02:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 01)
02:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 01)
02:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 01)
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 02)
03:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 02)
03:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 02)
03:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710
for 10GbE SFP+ (rev 02)
And with same configuration - have leaking memory somewhere - there is
no process that can
ps aux --sort -rss
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 5103 41.2 31.1 10357508 10242860 ? Sl Oct14 1010:33
/usr/local/sbin/bgpd -d -A 127.0.0.1 -u root -g root -I
--ignore_warnings -F /usr/local/etc/Quagga.conf -t
root 5094 0.0 0.8 295372 270868 ? Ss Oct14 1:26
/usr/local/sbin/zebra -d -A 127.0.0.1 -u root -g root -I
--ignore_warnings -F /usr/local/etc/Quagga.conf
root 4356 3.4 0.2 98780 75852 ? S Oct14 84:21
/usr/sbin/snmpd -p /var/run/snmpd.pid -Ln -I -smux
root 3448 0.0 0.0 32172 6204 ? Ss Oct14 0:00
/sbin/udevd --daemon
root 5385 0.0 0.0 61636 5044 ? Ss Oct14 0:00 sshd:
paol [priv]
root 4116 0.0 0.0 346312 4804 ? Ss Oct14 0:33
/usr/sbin/syslog-ng --persist-file /var/lib/syslog-ng/syslog-ng.persist
--cfgfile /etc/syslog-ng/syslog-ng.conf --pidfile /run/syslog-ng.pid
paol 5390 0.0 0.0 61636 3564 ? S Oct14 0:06 sshd:
paol@pts/1
root 5403 0.0 0.0 709344 3520 ? Ssl Oct14 0:26
/opt/collectd/sbin/collectd
root 5397 0.0 0.0 18280 3288 pts/1 S Oct14 0:00 -su
root 4384 0.0 0.0 30472 3016 ? Ss Oct14 0:00
/usr/sbin/sshd
paol 5391 0.0 0.0 18180 2884 pts/1 Ss Oct14 0:00 -bash
root 5394 0.0 0.0 43988 2376 pts/1 S Oct14 0:00 su -
root 20815 0.0 0.0 17744 2312 pts/1 R+ 16:58 0:00 ps aux
--sort -rss
root 4438 0.0 0.0 28820 2256 ? S Oct14 0:00 teamd
-d -f /etc/teamd.conf
root 4030 0.0 0.0 6976 2024 ? Ss Oct14 0:00 mdadm
--monitor --scan --daemonise --pid-file /var/run/mdadm.pid --syslog
root 4408 0.0 0.0 16768 1884 ? Ss Oct14 0:00
/usr/sbin/cron
root 5357 0.0 0.0 120532 1724 tty6 Ss+ Oct14 0:00
/sbin/agetty 38400 tty6 linux
root 5352 0.0 0.0 120532 1712 tty1 Ss+ Oct14 0:00
/sbin/agetty 38400 tty1 linux
root 5356 0.0 0.0 120532 1692 tty5 Ss+ Oct14 0:00
/sbin/agetty 38400 tty5 linux
root 5353 0.0 0.0 120532 1648 tty2 Ss+ Oct14 0:00
/sbin/agetty 38400 tty2 linux
root 5355 0.0 0.0 120532 1628 tty4 Ss+ Oct14 0:00
/sbin/agetty 38400 tty4 linux
root 5354 0.0 0.0 120532 1620 tty3 Ss+ Oct14 0:00
/sbin/agetty 38400 tty3 linux
root 1 0.0 0.0 4184 1420 ? Ss Oct14 0:02 init [3]
root 4115 0.0 0.0 34336 608 ? S Oct14 0:00
supervising syslog-ng
root 2 0.0 0.0 0 0 ? S Oct14 0:00 [kthreadd]
root 4 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/0:0H]
root 6 0.0 0.0 0 0 ? I< Oct14 0:00
[mm_percpu_wq]
root 7 0.8 0.0 0 0 ? S Oct14 22:01
[ksoftirqd/0]
root 8 0.0 0.0 0 0 ? I Oct14 1:36 [rcu_sched]
root 9 0.0 0.0 0 0 ? I Oct14 0:00 [rcu_bh]
root 10 0.0 0.0 0 0 ? S Oct14 0:00
[migration/0]
root 11 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/0]
root 12 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/1]
root 13 0.0 0.0 0 0 ? S Oct14 0:00
[migration/1]
root 14 0.8 0.0 0 0 ? S Oct14 21:39
[ksoftirqd/1]
root 16 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/1:0H]
root 17 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/2]
root 18 0.0 0.0 0 0 ? S Oct14 0:00
[migration/2]
root 19 0.8 0.0 0 0 ? S Oct14 20:48
[ksoftirqd/2]
root 21 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/2:0H]
root 22 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/3]
root 23 0.0 0.0 0 0 ? S Oct14 0:00
[migration/3]
root 24 1.0 0.0 0 0 ? S Oct14 24:36
[ksoftirqd/3]
root 26 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/3:0H]
root 27 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/4]
root 28 0.0 0.0 0 0 ? S Oct14 0:00
[migration/4]
root 29 0.8 0.0 0 0 ? S Oct14 20:14
[ksoftirqd/4]
root 31 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/4:0H]
root 32 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/5]
root 33 0.0 0.0 0 0 ? S Oct14 0:00
[migration/5]
root 34 0.8 0.0 0 0 ? S Oct14 20:22
[ksoftirqd/5]
root 36 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/5:0H]
root 37 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/6]
root 38 0.0 0.0 0 0 ? S Oct14 0:00
[migration/6]
root 39 0.8 0.0 0 0 ? S Oct14 20:43
[ksoftirqd/6]
root 41 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/6:0H]
root 42 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/7]
root 43 0.0 0.0 0 0 ? S Oct14 0:00
[migration/7]
root 44 0.8 0.0 0 0 ? S Oct14 21:51
[ksoftirqd/7]
root 46 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/7:0H]
root 47 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/8]
root 48 0.0 0.0 0 0 ? S Oct14 0:00
[migration/8]
root 49 0.7 0.0 0 0 ? S Oct14 18:49
[ksoftirqd/8]
root 51 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/8:0H]
root 52 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/9]
root 53 0.0 0.0 0 0 ? S Oct14 0:00
[migration/9]
root 54 0.8 0.0 0 0 ? S Oct14 20:48
[ksoftirqd/9]
root 56 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/9:0H]
root 57 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/10]
root 58 0.0 0.0 0 0 ? S Oct14 0:00
[migration/10]
root 59 0.7 0.0 0 0 ? S Oct14 19:07
[ksoftirqd/10]
root 61 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/10:0H]
root 62 0.0 0.0 0 0 ? S Oct14 0:00 [cpuhp/11]
root 63 0.0 0.0 0 0 ? S Oct14 0:00
[migration/11]
root 64 0.8 0.0 0 0 ? S Oct14 19:54
[ksoftirqd/11]
root 66 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/11:0H]
root 67 0.0 0.0 0 0 ? S Oct14 0:00 [kdevtmpfs]
root 70 0.0 0.0 0 0 ? S Oct14 0:00 [kauditd]
root 410 0.0 0.0 0 0 ? S Oct14 0:00
[khungtaskd]
root 411 0.0 0.0 0 0 ? S Oct14 0:00
[oom_reaper]
root 412 0.0 0.0 0 0 ? I< Oct14 0:00 [writeback]
root 414 0.0 0.0 0 0 ? S Oct14 0:00
[kcompactd0]
root 415 0.0 0.0 0 0 ? SN Oct14 0:00 [ksmd]
root 416 0.0 0.0 0 0 ? SN Oct14 0:00
[khugepaged]
root 417 0.0 0.0 0 0 ? I< Oct14 0:00 [crypto]
root 419 0.0 0.0 0 0 ? I< Oct14 0:00 [kblockd]
root 1314 0.0 0.0 0 0 ? I< Oct14 0:00 [ata_sff]
root 1329 0.0 0.0 0 0 ? I< Oct14 0:00 [md]
root 1425 0.0 0.0 0 0 ? I< Oct14 0:00 [rpciod]
root 1426 0.0 0.0 0 0 ? I< Oct14 0:00 [xprtiod]
root 1515 0.0 0.0 0 0 ? S Oct14 0:00 [kswapd0]
root 1614 0.0 0.0 0 0 ? I< Oct14 0:00 [nfsiod]
root 1684 0.0 0.0 0 0 ? I< Oct14 0:00
[acpi_thermal_pm]
root 1801 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_0]
root 1802 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_0]
root 1806 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_1]
root 1807 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_1]
root 1810 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_2]
root 1811 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_2]
root 1814 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_3]
root 1815 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_3]
root 1838 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_4]
root 1839 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_4]
root 1842 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_5]
root 1843 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_5]
root 1846 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_6]
root 1847 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_6]
root 1850 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_7]
root 1851 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_7]
root 1854 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_8]
root 1855 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_8]
root 1858 0.0 0.0 0 0 ? S Oct14 0:00 [scsi_eh_9]
root 1859 0.0 0.0 0 0 ? I< Oct14 0:00
[scsi_tmf_9]
root 1921 0.0 0.0 0 0 ? I< Oct14 0:00 [ixgbe]
root 1923 0.0 0.0 0 0 ? I< Oct14 0:00 [i40e]
root 3058 0.0 0.0 0 0 ? I< Oct14 0:00
[ipv6_addrconf]
root 3087 0.0 0.0 0 0 ? S Oct14 0:01 [md3_raid1]
root 3092 0.0 0.0 0 0 ? S Oct14 0:00 [md2_raid1]
root 3097 0.0 0.0 0 0 ? S Oct14 0:00 [md1_raid1]
root 3099 0.0 0.0 0 0 ? I< Oct14 0:00
[reiserfs/md2]
root 3100 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/0:1H]
root 3124 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/6:1H]
root 3155 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/1:1H]
root 3244 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/11:1H]
root 3351 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/5:1H]
root 3467 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/8:1H]
root 3502 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/9:1H]
root 3503 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/2:1H]
root 3521 0.0 0.0 0 0 ? SN Oct14 0:00 [kipmi0]
root 3757 0.0 0.0 0 0 ? I< Oct14 0:00
[reiserfs/md3]
root 5096 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/10:1H]
root 5280 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/7:1H]
root 5447 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/3:1H]
root 6573 0.0 0.0 0 0 ? I 16:10 0:00
[kworker/3:0]
root 6584 0.0 0.0 0 0 ? I 16:11 0:00
[kworker/6:0]
root 6660 0.0 0.0 0 0 ? I< Oct14 0:00
[kworker/4:1H]
root 6967 0.0 0.0 0 0 ? I 16:15 0:00
[kworker/5:2]
root 6976 0.0 0.0 0 0 ? I 16:17 0:00
[kworker/10:1]
root 7036 0.0 0.0 0 0 ? I 06:19 0:02
[kworker/0:4]
root 7750 0.0 0.0 0 0 ? I 16:22 0:00
[kworker/4:2]
root 9555 0.0 0.0 0 0 ? I 16:25 0:00
[kworker/2:2]
root 9557 0.0 0.0 0 0 ? I 16:26 0:00
[kworker/6:2]
root 10146 0.0 0.0 0 0 ? I 16:27 0:00
[kworker/8:2]
root 10148 0.0 0.0 0 0 ? I 16:27 0:00
[kworker/1:2]
root 13804 0.0 0.0 0 0 ? I 13:42 0:00
[kworker/0:1]
root 16109 0.0 0.0 0 0 ? I 16:33 0:00
[kworker/9:2]
root 16156 0.0 0.0 0 0 ? I 16:39 0:00
[kworker/4:0]
root 16422 0.0 0.0 0 0 ? I 16:39 0:00
[kworker/5:1]
root 16423 0.0 0.0 0 0 ? I 16:39 0:00
[kworker/9:0]
root 17118 0.0 0.0 0 0 ? I 16:40 0:00
[kworker/11:2]
root 17250 0.0 0.0 0 0 ? I 16:42 0:00
[kworker/3:1]
root 17620 0.0 0.0 0 0 ? I 16:43 0:00
[kworker/0:0]
root 17629 0.0 0.0 0 0 ? I 16:45 0:00
[kworker/2:1]
root 17639 0.0 0.0 0 0 ? I 16:47 0:00
[kworker/u24:0]
root 17640 0.0 0.0 0 0 ? I 16:47 0:00
[kworker/10:0]
root 17642 0.0 0.0 0 0 ? I 16:48 0:00
[kworker/0:5]
root 19577 0.0 0.0 0 0 ? I 16:49 0:00
[kworker/8:1]
root 19578 0.0 0.0 0 0 ? I 16:49 0:00
[kworker/8:3]
root 19819 0.0 0.0 0 0 ? I 16:49 0:00
[kworker/1:1]
root 19820 0.0 0.0 0 0 ? I 16:49 0:00
[kworker/1:3]
root 19972 0.0 0.0 0 0 ? I 16:52 0:00
[kworker/7:1]
root 19973 0.0 0.0 0 0 ? I 16:52 0:00
[kworker/7:3]
root 19974 0.0 0.0 0 0 ? I 16:52 0:00
[kworker/11:1]
root 19976 0.0 0.0 0 0 ? I 16:52 0:00
[kworker/u24:1]
root 20106 0.0 0.0 0 0 ? I 16:53 0:00
[kworker/4:1]
root 20107 0.0 0.0 0 0 ? I 16:53 0:00
[kworker/4:3]
root 20108 0.0 0.0 0 0 ? I 16:54 0:00
[kworker/3:2]
root 20109 0.0 0.0 0 0 ? I 16:54 0:00
[kworker/3:3]
root 20110 0.0 0.0 0 0 ? I 16:54 0:00
[kworker/0:6]
root 20217 0.0 0.0 0 0 ? I 16:55 0:00
[kworker/1:0]
root 20219 0.0 0.0 0 0 ? I 16:56 0:00
[kworker/9:1]
root 20222 0.0 0.0 0 0 ? I 16:56 0:00
[kworker/9:3]
root 20354 0.0 0.0 0 0 ? I 16:57 0:00
[kworker/5:0]
root 20355 0.0 0.0 0 0 ? I 16:57 0:00
[kworker/5:3]
root 20814 0.0 0.0 0 0 ? I 16:57 0:00
[kworker/u24:2]
root 26845 0.0 0.0 0 0 ? I 15:40 0:00
[kworker/7:2]
root 26979 0.0 0.0 0 0 ? I 15:43 0:00
[kworker/0:3]
root 27375 0.0 0.0 0 0 ? I 15:48 0:00
[kworker/0:2]
but free -m
free -m
total used free shared buff/cache
available
Mem: 32113 18345 13598 0 169 13419
Swap: 3911 0 3911
less and less about 0.5MB per hour
it looks like this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
Is not included in:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Ok will upgrade tomorrow - and will check with that fix.
W dniu 2017-10-15 o 02:58, Alexander Duyck pisze:
> Hi Pawel,
>
> To clarify is that Dave Miller's tree or Linus's that you are talking
> about? If it is Dave's tree how long ago was it you pulled it since I
> think the fix was just pushed by Jeff Kirsher a few days ago.
>
> The issue should be fixed in the following commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>
> Thanks.
>
> - Alex
>
> On Sat, Oct 14, 2017 at 3:03 PM, Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>> Forgot to add - this graphs are tested with Kernel 4.14-rc4-next
>>
>>
>> W dniu 2017-10-15 o 00:00, Paweł Staszewski pisze:
>>
>> Same problem here
>>
>> Also only difference is change 82599 intel to x710 and have memleak
>>
>> mem with ixgbe driver over time - same config saame kernel
>>
>>
>>
>> changed NIC's to x710 i40e driver (this is the only change)
>>
>> And mem over time:
>>
>>
>>
>> There is no process that is eating memory - looks like there is some problem
>> with i40e driver - but it not a surprise :) this driver is really buggy -
>> with many things - most tickets on e1000e sourceforge that i openned have no
>> reply for year or more - or if somebody reply after year they are closing
>> ticket after 1 day with info about no activity :)
>>
>>
>>
>> W dniu 2017-10-05 o 07:19, Anders K. Pedersen | Cohaesio pisze:
>>
>> On ons, 2017-10-04 at 08:32 -0700, Alexander Duyck wrote:
>>
>> On Wed, Oct 4, 2017 at 5:56 AM, Anders K. Pedersen | Cohaesio
>> <akp@cohaesio.com> wrote:
>>
>> Hello,
>>
>> After updating one of our Linux based routers to kernel 4.13 it
>> began
>> leaking memory quite fast (about 1 GB every half hour). To narrow
>> we
>> tried various kernel versions and found that 4.11.12 is okay, while
>> 4.12 also leaks, so we did a bisection between 4.11 and 4.12.
>>
>> The first bisection ended at
>> "[6964e53f55837b0c49ed60d36656d2e0ee4fc27b] i40e: fix handling of
>> HW
>> ATR eviction", which fixes some flag handling that was broken by
>> 47994c119a36 "i40e: remove hw_disabled_flags in favor of using
>> separate
>> flag bits", so I did a second bisection, where I added 6964e53f5583
>> "i40e: fix handling of HW ATR eviction" to the steps that had
>> 47994c119a36 "i40e: remove hw_disabled_flags in favor of using
>> separate
>> flag bits" in them.
>>
>> The second bisection ended at
>> "[0e626ff7ccbfc43c6cc4aeea611c40b899682382] i40e: Fix support for
>> flow
>> director programming status", where I don't see any obvious
>> problems,
>> so I'm hoping for some assistance.
>>
>> The router is a PowerEdge R730 server (Haswell based) with three
>> Intel
>> NICs (all using the i40e driver):
>>
>> X710 quad port 10 GbE SFP+: eth0 eth1 eth2 eth3
>> X710 quad port 10 GbE SFP+: eth4 eth5 eth6 eth7
>> XL710 dual port 40 GbE QSFP+: eth8 eth9
>>
>> The NICs are aggregated with LACP with the team driver:
>>
>> team0: eth9 (40 GbE selected primary), and eth3, eth7 (10 GbE non-
>> selected backups)
>> team1: eth0, eth1, eth4, eth5 (all 10 GbE selected)
>>
>> team0 is used for internal networks and has one untagged and four
>> tagged VLAN interfaces, while team1 has an external uplink
>> connection
>> without any VLANs.
>>
>> The router runs an eBGP session on team1 to one of our uplinks, and
>> iBGP via team0 to our other border routers. It also runs OSPF on
>> the
>> internal VLANs on team0. One thing I've noticed is that when OSPF
>> is
>> not announcing a default gateway to the internal networks, so there
>> is
>> almost no traffic coming in on team0 and out on team1, but still
>> plenty
>> of traffic coming in on team1 and out via team0, there's no memory
>> leak
>> (or at least it is so small that we haven't detected it). But as
>> soon
>> as we configure OSPF to announce a default gateway to the internal
>> VLANs, so we get traffic from team0 to team1 the leaking begins.
>> Stopping the OSPF default gateway announcement again also stops the
>> leaking, but does not release already leaked memory.
>>
>> So this leads to me suspect that the leaking is related to RX on
>> team0
>> (where XL710 eth9 is normally the only active interface) or TX on
>> team1
>> (X710 eth0, eth1, eth4, eth5). The first bad commit is related to
>> RX
>> cleaning, which suggests RX on team0. Since we're only seeing the
>> leak
>> for our outbound traffic, I suspect either a difference between the
>> X710 vs. XL710 NICs, or that the inbound traffic is for relatively
>> few
>> destination addresses (only our own systems) while the outbound
>> traffic
>> is for many different addresses on the internet. But I'm just
>> guessing
>> here.
>>
>> I've tried kmemleak, but it only found a few kB of suspected memory
>> leaks (several of which disappeared again after a while).
>>
>> Below I've included more details - git bisect logs, ethtool -i,
>> dmesg,
>> Kernel .config, and various memory related /proc files. Any help or
>> suggestions would be much appreciated, and please let me know if
>> more
>> information is needed or there's something I should try.
>>
>> Regards,
>> Anders K. Pedersen
>>
>> Hi Anders,
>>
>> I think I see the problem and should have a patch submitted shortly
>> to
>> address it. From what I can tell it looks like the issue is that we
>> weren't properly recycling the pages associated with descriptors that
>> contained an Rx programming status. For now the workaround would be
>> to
>> try disabling ATR via the "ethtool --set-priv-flags" command. I
>> should
>> have a patch out in the next hour or so that you can try testing to
>> verify if it addresses the issue.
>>
>> Thanks.
>>
>> - Alex
>>
>> Thanks Alex,
>>
>> I will test the patch in our next service window on Tuesday morning.
>>
>> Regards,
>> Anders
>>
>>
>>
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Masahiro Yamada @ 2017-10-15 15:08 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn, Florian Fainelli,
Rob Herring, Mark Rutland, linux-arm-kernel,
Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <1507854928-4357-3-git-send-email-hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>:
> +static int ave_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + u32 ave_id;
> + struct ave_private *priv;
> + const struct ave_soc_data *data;
> + phy_interface_t phy_mode;
> + struct net_device *ndev;
> + struct resource *res;
> + void __iomem *base;
> + int irq, ret = 0;
> + char buf[ETHTOOL_FWVERS_LEN];
> + const void *mac_addr;
> +
> + data = of_device_get_match_data(dev);
> + if (WARN_ON(!data))
> + return -EINVAL;
> +
> + phy_mode = of_get_phy_mode(np);
> + if (phy_mode < 0) {
> + dev_err(dev, "phy-mode not found\n");
> + return -EINVAL;
> + }
> + if ((!phy_interface_mode_is_rgmii(phy_mode)) &&
> + phy_mode != PHY_INTERFACE_MODE_RMII &&
> + phy_mode != PHY_INTERFACE_MODE_MII) {
> + dev_err(dev, "phy-mode is invalid\n");
> + return -EINVAL;
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(dev, "IRQ not found\n");
> + return irq;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + /* alloc netdevice */
> + ndev = alloc_etherdev(sizeof(struct ave_private));
> + if (!ndev) {
> + dev_err(dev, "can't allocate ethernet device\n");
> + return -ENOMEM;
> + }
> +
> + ndev->netdev_ops = &ave_netdev_ops;
> + ndev->ethtool_ops = &ave_ethtool_ops;
> + SET_NETDEV_DEV(ndev, dev);
> +
> + /* support hardware checksum */
> + ndev->features |= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> + ndev->hw_features |= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> +
> + ndev->max_mtu = AVE_MAX_ETHFRAME - (ETH_HLEN + ETH_FCS_LEN);
> +
> + /* get mac address */
> + mac_addr = of_get_mac_address(np);
> + if (mac_addr)
> + ether_addr_copy(ndev->dev_addr, mac_addr);
> +
> + /* if the mac address is invalid, use random mac address */
> + if (!is_valid_ether_addr(ndev->dev_addr)) {
> + eth_hw_addr_random(ndev);
> + dev_warn(dev, "Using random MAC address: %pM\n",
> + ndev->dev_addr);
> + }
> +
> + priv = netdev_priv(ndev);
> + priv->base = base;
> + priv->irq = irq;
> + priv->ndev = ndev;
> + priv->msg_enable = netif_msg_init(-1, AVE_DEFAULT_MSG_ENABLE);
> + priv->phy_mode = phy_mode;
> + priv->data = data;
> +
> + if (IS_DESC_64BIT(priv)) {
> + priv->desc_size = AVE_DESC_SIZE_64;
> + priv->tx.daddr = AVE_TXDM_64;
> + priv->rx.daddr = AVE_RXDM_64;
> + } else {
> + priv->desc_size = AVE_DESC_SIZE_32;
> + priv->tx.daddr = AVE_TXDM_32;
> + priv->rx.daddr = AVE_RXDM_32;
> + }
> + priv->tx.ndesc = AVE_NR_TXDESC;
> + priv->rx.ndesc = AVE_NR_RXDESC;
> +
> + u64_stats_init(&priv->stats_rx.syncp);
> + u64_stats_init(&priv->stats_tx.syncp);
> +
> + /* get clock */
Please remove this super-obvious comment.
> + priv->clk = clk_get(dev, NULL);
Missing clk_put() in the failure path.
Why don't you use devm?
> + if (IS_ERR(priv->clk))
> + priv->clk = NULL;
So, clk is optional, but
you need to check EPROBE_DEFER.
> + /* get reset */
Remove.
> + priv->rst = reset_control_get(dev, NULL);
> + if (IS_ERR(priv->rst))
> + priv->rst = NULL;
reset_control_get() is deprecated. Do not use it in a new driver.
Again, missing reset_control_put(). devm?
The reset seems optional (again, ignoring EPROBE_DEFER)
but you did not use reset_control_get_optional, why?
>From your code, this reset is used as shared.
priv->rst = devm_reset_control_get_optional_shared(dev, NULL);
if (IS_ERR(priv->rst))
return PTR_ERR(priv->rst);
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv6: addrconf: cleanup locking in ipv6_add_addr
From: David Ahern @ 2017-10-15 15:24 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <20171015075052.GA10604@shredder.mtl.com>
On 10/15/17 1:50 AM, Ido Schimmel wrote:
> On Fri, Oct 13, 2017 at 04:02:09PM -0700, David Ahern wrote:
>> ipv6_add_addr is called in process context with rtnl lock held
>> (e.g., manual config of an address) or during softirq processing
>> (e.g., autoconf and address from a router advertisement).
>>
>> Currently, ipv6_add_addr calls rcu_read_lock_bh shortly after entry
>> and does not call unlock until exit, minus the call around the address
>> validator notifier. Similarly, addrconf_hash_lock is taken after the
>> validator notifier and held until exit. This forces the allocation of
>> inet6_ifaddr to always be atomic.
>>
>> Refactor ipv6_add_addr as follows:
>> 1. add an input boolean to discriminate the call path (process context
>> or softirq). This new flag controls whether the alloc can be done
>> with GFP_KERNEL or GFP_ATOMIC.
>>
>> 2. Move the rcu_read_lock_bh and unlock calls only around functions that
>> do rcu updates.
>>
>> 3. Remove the in6_dev_hold and put added by 3ad7d2468f79f ("Ipvlan should
>> return an error when an address is already in use."). This was done
>> presumably because rcu_read_unlock_bh needs to be called before calling
>> the validator. Since rcu_read_lock is not needed before the validator
>> runs revert the hold and put added by 3ad7d2468f79f and only do the
>> hold when setting ifp->idev.
>>
>> 4. move duplicate address check and insertion of new address in the global
>> address hash into a helper. The helper is called after an ifa is
>> allocated and filled in.
>>
>> This allows the ifa for manually configured addresses to be done with
>> GFP_KERNEL and reduces the overall amount of time with rcu_read_lock held
>> and hash table spinlock held.
>>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>
> [...]
>
>> @@ -1073,21 +1085,19 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
>>
>> in6_ifa_hold(ifa);
>> write_unlock(&idev->lock);
>> -out2:
>> +
>> rcu_read_unlock_bh();
>>
>> - if (likely(err == 0))
>> - inet6addr_notifier_call_chain(NETDEV_UP, ifa);
>> - else {
>> + inet6addr_notifier_call_chain(NETDEV_UP, ifa);
>> +out:
>> + if (unlikely(err < 0)) {
>> + if (rt)
>> + ip6_rt_put(rt);
>
> I believe 'rt' needs to be set to NULL after addrconf_dst_alloc()
> fails.
The above frees rt and the line below frees the ifa and resets the value
to an error, so after the line above rt is no longer referenced.
Taking a look at this again, I think I am missing an idev put in the
error path here.
>
>> kfree(ifa);
>> - in6_dev_put(idev);
>> ifa = ERR_PTR(err);
>> }
>>
>> return ifa;
>> -out:
>> - spin_unlock(&addrconf_hash_lock);
>> - goto out2;
>> }
^ permalink raw reply
* Re: [PATCH v9 00/20] simplify crypto wait for async op
From: Herbert Xu @ 2017-10-15 15:38 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Mike Snitzer, linux-doc, Gary Hook, David Howells, dm-devel,
keyrings, linux-ima-devel, Alasdair Kergon, Steffen Klassert,
Boris Brezillon, Jonathan Corbet, Alexey Kuznetsov, Mimi Zohar,
Serge E. Hallyn, Tom Lendacky, linux-cifs, linux-ima-user,
Arnaud Ebalard, linux-fscrypt, linux-mediatek, James Morris,
Matthias Brugger, Jaegeuk Kim, linux-arm-kernel, Ofir
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>
> Changes from v8:
> - Remove the translation of EAGAIN return code to the
> previous return code of EBUSY for the user space
> interface of algif as no one seems to rely on it as
> requested by Herbert Xu.
Sorry, but I forgot to mention that EAGAIN is not a good value
to use because it's used by the network system calls for other
meanings (interrupted by a signal).
So if we stop doing the translation then we also need to pick
a different value, perhaps E2BIG or something similar that have
no current use within the crypto API or network API.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv6: addrconf: cleanup locking in ipv6_add_addr
From: Ido Schimmel @ 2017-10-15 15:59 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <11052db4-0608-a11b-5d71-896a2154a96c@gmail.com>
On Sun, Oct 15, 2017 at 09:24:07AM -0600, David Ahern wrote:
> On 10/15/17 1:50 AM, Ido Schimmel wrote:
> > On Fri, Oct 13, 2017 at 04:02:09PM -0700, David Ahern wrote:
> >> ipv6_add_addr is called in process context with rtnl lock held
> >> (e.g., manual config of an address) or during softirq processing
> >> (e.g., autoconf and address from a router advertisement).
> >>
> >> Currently, ipv6_add_addr calls rcu_read_lock_bh shortly after entry
> >> and does not call unlock until exit, minus the call around the address
> >> validator notifier. Similarly, addrconf_hash_lock is taken after the
> >> validator notifier and held until exit. This forces the allocation of
> >> inet6_ifaddr to always be atomic.
> >>
> >> Refactor ipv6_add_addr as follows:
> >> 1. add an input boolean to discriminate the call path (process context
> >> or softirq). This new flag controls whether the alloc can be done
> >> with GFP_KERNEL or GFP_ATOMIC.
> >>
> >> 2. Move the rcu_read_lock_bh and unlock calls only around functions that
> >> do rcu updates.
> >>
> >> 3. Remove the in6_dev_hold and put added by 3ad7d2468f79f ("Ipvlan should
> >> return an error when an address is already in use."). This was done
> >> presumably because rcu_read_unlock_bh needs to be called before calling
> >> the validator. Since rcu_read_lock is not needed before the validator
> >> runs revert the hold and put added by 3ad7d2468f79f and only do the
> >> hold when setting ifp->idev.
> >>
> >> 4. move duplicate address check and insertion of new address in the global
> >> address hash into a helper. The helper is called after an ifa is
> >> allocated and filled in.
> >>
> >> This allows the ifa for manually configured addresses to be done with
> >> GFP_KERNEL and reduces the overall amount of time with rcu_read_lock held
> >> and hash table spinlock held.
> >>
> >> Signed-off-by: David Ahern <dsahern@gmail.com>
> >
> > [...]
> >
> >> @@ -1073,21 +1085,19 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
> >>
> >> in6_ifa_hold(ifa);
> >> write_unlock(&idev->lock);
> >> -out2:
> >> +
> >> rcu_read_unlock_bh();
> >>
> >> - if (likely(err == 0))
> >> - inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> >> - else {
> >> + inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> >> +out:
> >> + if (unlikely(err < 0)) {
> >> + if (rt)
> >> + ip6_rt_put(rt);
> >
> > I believe 'rt' needs to be set to NULL after addrconf_dst_alloc()
> > fails.
>
> The above frees rt and the line below frees the ifa and resets the value
> to an error, so after the line above rt is no longer referenced.
Earlier in the code we have:
rt = addrconf_dst_alloc(idev, addr, false);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
goto out;
}
So we end up calling ip6_rt_put() with an error value. I believe it
should be:
rt = addrconf_dst_alloc(idev, addr, false);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
rt = NULL;
goto out;
}
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv6: addrconf: cleanup locking in ipv6_add_addr
From: David Ahern @ 2017-10-15 16:03 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <20171015155938.GA24270@shredder.mtl.com>
On 10/15/17 9:59 AM, Ido Schimmel wrote:
> On Sun, Oct 15, 2017 at 09:24:07AM -0600, David Ahern wrote:
>> On 10/15/17 1:50 AM, Ido Schimmel wrote:
>>> On Fri, Oct 13, 2017 at 04:02:09PM -0700, David Ahern wrote:
>>>> ipv6_add_addr is called in process context with rtnl lock held
>>>> (e.g., manual config of an address) or during softirq processing
>>>> (e.g., autoconf and address from a router advertisement).
>>>>
>>>> Currently, ipv6_add_addr calls rcu_read_lock_bh shortly after entry
>>>> and does not call unlock until exit, minus the call around the address
>>>> validator notifier. Similarly, addrconf_hash_lock is taken after the
>>>> validator notifier and held until exit. This forces the allocation of
>>>> inet6_ifaddr to always be atomic.
>>>>
>>>> Refactor ipv6_add_addr as follows:
>>>> 1. add an input boolean to discriminate the call path (process context
>>>> or softirq). This new flag controls whether the alloc can be done
>>>> with GFP_KERNEL or GFP_ATOMIC.
>>>>
>>>> 2. Move the rcu_read_lock_bh and unlock calls only around functions that
>>>> do rcu updates.
>>>>
>>>> 3. Remove the in6_dev_hold and put added by 3ad7d2468f79f ("Ipvlan should
>>>> return an error when an address is already in use."). This was done
>>>> presumably because rcu_read_unlock_bh needs to be called before calling
>>>> the validator. Since rcu_read_lock is not needed before the validator
>>>> runs revert the hold and put added by 3ad7d2468f79f and only do the
>>>> hold when setting ifp->idev.
>>>>
>>>> 4. move duplicate address check and insertion of new address in the global
>>>> address hash into a helper. The helper is called after an ifa is
>>>> allocated and filled in.
>>>>
>>>> This allows the ifa for manually configured addresses to be done with
>>>> GFP_KERNEL and reduces the overall amount of time with rcu_read_lock held
>>>> and hash table spinlock held.
>>>>
>>>> Signed-off-by: David Ahern <dsahern@gmail.com>
>>>
>>> [...]
>>>
>>>> @@ -1073,21 +1085,19 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
>>>>
>>>> in6_ifa_hold(ifa);
>>>> write_unlock(&idev->lock);
>>>> -out2:
>>>> +
>>>> rcu_read_unlock_bh();
>>>>
>>>> - if (likely(err == 0))
>>>> - inet6addr_notifier_call_chain(NETDEV_UP, ifa);
>>>> - else {
>>>> + inet6addr_notifier_call_chain(NETDEV_UP, ifa);
>>>> +out:
>>>> + if (unlikely(err < 0)) {
>>>> + if (rt)
>>>> + ip6_rt_put(rt);
>>>
>>> I believe 'rt' needs to be set to NULL after addrconf_dst_alloc()
>>> fails.
>>
>> The above frees rt and the line below frees the ifa and resets the value
>> to an error, so after the line above rt is no longer referenced.
>
> Earlier in the code we have:
>
> rt = addrconf_dst_alloc(idev, addr, false);
> if (IS_ERR(rt)) {
> err = PTR_ERR(rt);
> goto out;
> }
>
> So we end up calling ip6_rt_put() with an error value. I believe it
> should be:
>
> rt = addrconf_dst_alloc(idev, addr, false);
> if (IS_ERR(rt)) {
> err = PTR_ERR(rt);
> rt = NULL;
> goto out;
> }
>
gotcha. Will fix.
^ 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