* [PATCH 05/15] netfilter: nf_tables: nft_compat: fix refcount leak on xt module
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180513223656.10077-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Taehee Yoo reported following bug:
iptables-compat -I OUTPUT -m cpu --cpu 0
iptables-compat -F
lsmod |grep xt_cpu
xt_cpu 16384 1
Quote:
"When above command is given, a netlink message has two expressions that
are the cpu compat and the nft_counter.
The nft_expr_type_get() in the nf_tables_expr_parse() successes
first expression then, calls select_ops callback.
(allocates memory and holds module)
But, second nft_expr_type_get() in the nf_tables_expr_parse()
returns -EAGAIN because of request_module().
In that point, by the 'goto err1',
the 'module_put(info[i].ops->type->owner)' is called.
There is no release routine."
The core problem is that unlike all other expression,
nft_compat select_ops has side effects.
1. it allocates dynamic memory which holds an nft ops struct.
In all other expressions, ops has static storage duration.
2. It grabs references to the xt module that it is supposed to
invoke.
Depending on where things go wrong, error unwinding doesn't
always do the right thing.
In the above scenario, a new nft_compat_expr is created and
xt_cpu module gets loaded with a refcount of 1.
Due to to -EAGAIN, the netlink messages get re-parsed.
When that happens, nft_compat finds that xt_cpu is already present
and increments module refcount again.
This fixes the problem by making select_ops to have no visible
side effects and removes all extra module_get/put.
When select_ops creates a new nft_compat expression, the new
expression has a refcount of 0, and the xt module gets its refcount
incremented.
When error happens, the next call finds existing entry, but will no
longer increase the reference count -- the presence of existing
nft_xt means we already hold a module reference.
Because nft_xt_put is only called from nft_compat destroy hook,
it will never see the initial zero reference count.
->destroy can only be called after ->init(), and that will increase the
refcount.
Lastly, we now free nft_xt struct with kfree_rcu.
Else, we get use-after free in nf_tables_rule_destroy:
while (expr != nft_expr_last(rule) && expr->ops) {
nf_tables_expr_destroy(ctx, expr);
expr = nft_expr_next(expr); // here
nft_expr_next() dereferences expr->ops. This is safe
for all users, as ops have static storage duration.
In nft_compat case however, its ->destroy callback can
free the memory that hold the ops structure.
Tested-by: Taehee Yoo <ap420073@gmail.com>
Reported-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_compat.c | 92 +++++++++++++++++++++++++++++-----------------
1 file changed, 58 insertions(+), 34 deletions(-)
diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c
index 8e23726b9081..870d8c29dae9 100644
--- a/net/netfilter/nft_compat.c
+++ b/net/netfilter/nft_compat.c
@@ -27,14 +27,24 @@ struct nft_xt {
struct list_head head;
struct nft_expr_ops ops;
unsigned int refcnt;
+
+ /* Unlike other expressions, ops doesn't have static storage duration.
+ * nft core assumes they do. We use kfree_rcu so that nft core can
+ * can check expr->ops->size even after nft_compat->destroy() frees
+ * the nft_xt struct that holds the ops structure.
+ */
+ struct rcu_head rcu_head;
};
-static void nft_xt_put(struct nft_xt *xt)
+static bool nft_xt_put(struct nft_xt *xt)
{
if (--xt->refcnt == 0) {
list_del(&xt->head);
- kfree(xt);
+ kfree_rcu(xt, rcu_head);
+ return true;
}
+
+ return false;
}
static int nft_compat_chain_validate_dependency(const char *tablename,
@@ -226,6 +236,7 @@ nft_target_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
struct xt_target *target = expr->ops->data;
struct xt_tgchk_param par;
size_t size = XT_ALIGN(nla_len(tb[NFTA_TARGET_INFO]));
+ struct nft_xt *nft_xt;
u16 proto = 0;
bool inv = false;
union nft_entry e = {};
@@ -236,25 +247,22 @@ nft_target_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
if (ctx->nla[NFTA_RULE_COMPAT]) {
ret = nft_parse_compat(ctx->nla[NFTA_RULE_COMPAT], &proto, &inv);
if (ret < 0)
- goto err;
+ return ret;
}
nft_target_set_tgchk_param(&par, ctx, target, info, &e, proto, inv);
ret = xt_check_target(&par, size, proto, inv);
if (ret < 0)
- goto err;
+ return ret;
/* The standard target cannot be used */
- if (target->target == NULL) {
- ret = -EINVAL;
- goto err;
- }
+ if (!target->target)
+ return -EINVAL;
+ nft_xt = container_of(expr->ops, struct nft_xt, ops);
+ nft_xt->refcnt++;
return 0;
-err:
- module_put(target->me);
- return ret;
}
static void
@@ -271,8 +279,8 @@ nft_target_destroy(const struct nft_ctx *ctx, const struct nft_expr *expr)
if (par.target->destroy != NULL)
par.target->destroy(&par);
- nft_xt_put(container_of(expr->ops, struct nft_xt, ops));
- module_put(target->me);
+ if (nft_xt_put(container_of(expr->ops, struct nft_xt, ops)))
+ module_put(target->me);
}
static int nft_target_dump(struct sk_buff *skb, const struct nft_expr *expr)
@@ -411,6 +419,7 @@ nft_match_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
struct xt_match *match = expr->ops->data;
struct xt_mtchk_param par;
size_t size = XT_ALIGN(nla_len(tb[NFTA_MATCH_INFO]));
+ struct nft_xt *nft_xt;
u16 proto = 0;
bool inv = false;
union nft_entry e = {};
@@ -421,19 +430,18 @@ nft_match_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
if (ctx->nla[NFTA_RULE_COMPAT]) {
ret = nft_parse_compat(ctx->nla[NFTA_RULE_COMPAT], &proto, &inv);
if (ret < 0)
- goto err;
+ return ret;
}
nft_match_set_mtchk_param(&par, ctx, match, info, &e, proto, inv);
ret = xt_check_match(&par, size, proto, inv);
if (ret < 0)
- goto err;
+ return ret;
+ nft_xt = container_of(expr->ops, struct nft_xt, ops);
+ nft_xt->refcnt++;
return 0;
-err:
- module_put(match->me);
- return ret;
}
static void
@@ -450,8 +458,8 @@ nft_match_destroy(const struct nft_ctx *ctx, const struct nft_expr *expr)
if (par.match->destroy != NULL)
par.match->destroy(&par);
- nft_xt_put(container_of(expr->ops, struct nft_xt, ops));
- module_put(match->me);
+ if (nft_xt_put(container_of(expr->ops, struct nft_xt, ops)))
+ module_put(match->me);
}
static int nft_match_dump(struct sk_buff *skb, const struct nft_expr *expr)
@@ -654,13 +662,8 @@ nft_match_select_ops(const struct nft_ctx *ctx,
list_for_each_entry(nft_match, &nft_match_list, head) {
struct xt_match *match = nft_match->ops.data;
- if (nft_match_cmp(match, mt_name, rev, family)) {
- if (!try_module_get(match->me))
- return ERR_PTR(-ENOENT);
-
- nft_match->refcnt++;
+ if (nft_match_cmp(match, mt_name, rev, family))
return &nft_match->ops;
- }
}
match = xt_request_find_match(family, mt_name, rev);
@@ -679,7 +682,7 @@ nft_match_select_ops(const struct nft_ctx *ctx,
goto err;
}
- nft_match->refcnt = 1;
+ nft_match->refcnt = 0;
nft_match->ops.type = &nft_match_type;
nft_match->ops.size = NFT_EXPR_SIZE(XT_ALIGN(match->matchsize));
nft_match->ops.eval = nft_match_eval;
@@ -739,13 +742,8 @@ nft_target_select_ops(const struct nft_ctx *ctx,
list_for_each_entry(nft_target, &nft_target_list, head) {
struct xt_target *target = nft_target->ops.data;
- if (nft_target_cmp(target, tg_name, rev, family)) {
- if (!try_module_get(target->me))
- return ERR_PTR(-ENOENT);
-
- nft_target->refcnt++;
+ if (nft_target_cmp(target, tg_name, rev, family))
return &nft_target->ops;
- }
}
target = xt_request_find_target(family, tg_name, rev);
@@ -764,7 +762,7 @@ nft_target_select_ops(const struct nft_ctx *ctx,
goto err;
}
- nft_target->refcnt = 1;
+ nft_target->refcnt = 0;
nft_target->ops.type = &nft_target_type;
nft_target->ops.size = NFT_EXPR_SIZE(XT_ALIGN(target->targetsize));
nft_target->ops.init = nft_target_init;
@@ -823,6 +821,32 @@ static int __init nft_compat_module_init(void)
static void __exit nft_compat_module_exit(void)
{
+ struct nft_xt *xt, *next;
+
+ /* list should be empty here, it can be non-empty only in case there
+ * was an error that caused nft_xt expr to not be initialized fully
+ * and noone else requested the same expression later.
+ *
+ * In this case, the lists contain 0-refcount entries that still
+ * hold module reference.
+ */
+ list_for_each_entry_safe(xt, next, &nft_target_list, head) {
+ struct xt_target *target = xt->ops.data;
+
+ if (WARN_ON_ONCE(xt->refcnt))
+ continue;
+ module_put(target->me);
+ kfree(xt);
+ }
+
+ list_for_each_entry_safe(xt, next, &nft_match_list, head) {
+ struct xt_match *match = xt->ops.data;
+
+ if (WARN_ON_ONCE(xt->refcnt))
+ continue;
+ module_put(match->me);
+ kfree(xt);
+ }
nfnetlink_subsys_unregister(&nfnl_compat_subsys);
nft_unregister_expr(&nft_target_type);
nft_unregister_expr(&nft_match_type);
--
2.11.0
^ permalink raw reply related
* [PATCH 04/15] netfilter: bridge: stp fix reference to uninitialized data
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180513223656.10077-1-pablo@netfilter.org>
From: Stephen Hemminger <stephen@networkplumber.org>
The destination mac (destmac) is only valid if EBT_DESTMAC flag
is set. Fix by changing the order of the comparison to look for
the flag first.
Reported-by: syzbot+5c06e318fc558cc27823@syzkaller.appspotmail.com
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/bridge/netfilter/ebt_stp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/ebt_stp.c b/net/bridge/netfilter/ebt_stp.c
index 47ba98db145d..46c1fe7637ea 100644
--- a/net/bridge/netfilter/ebt_stp.c
+++ b/net/bridge/netfilter/ebt_stp.c
@@ -161,8 +161,8 @@ static int ebt_stp_mt_check(const struct xt_mtchk_param *par)
/* Make sure the match only receives stp frames */
if (!par->nft_compat &&
(!ether_addr_equal(e->destmac, eth_stp_addr) ||
- !is_broadcast_ether_addr(e->destmsk) ||
- !(e->bitmask & EBT_DESTMAC)))
+ !(e->bitmask & EBT_DESTMAC) ||
+ !is_broadcast_ether_addr(e->destmsk)))
return -EINVAL;
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH 03/15] netfilter: nf_tables: skip synchronize_rcu if transaction log is empty
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180513223656.10077-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
After processing the transaction log, the remaining entries of the log
need to be released.
However, in some cases no entries remain, e.g. because the transaction
did not remove anything.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 04d4e3772584..785d7fcf1fe1 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -5761,7 +5761,7 @@ static void nft_chain_commit_update(struct nft_trans *trans)
}
}
-static void nf_tables_commit_release(struct nft_trans *trans)
+static void nft_commit_release(struct nft_trans *trans)
{
switch (trans->msg_type) {
case NFT_MSG_DELTABLE:
@@ -5790,6 +5790,21 @@ static void nf_tables_commit_release(struct nft_trans *trans)
kfree(trans);
}
+static void nf_tables_commit_release(struct net *net)
+{
+ struct nft_trans *trans, *next;
+
+ if (list_empty(&net->nft.commit_list))
+ return;
+
+ synchronize_rcu();
+
+ list_for_each_entry_safe(trans, next, &net->nft.commit_list, list) {
+ list_del(&trans->list);
+ nft_commit_release(trans);
+ }
+}
+
static int nf_tables_commit(struct net *net, struct sk_buff *skb)
{
struct nft_trans *trans, *next;
@@ -5920,13 +5935,7 @@ static int nf_tables_commit(struct net *net, struct sk_buff *skb)
}
}
- synchronize_rcu();
-
- list_for_each_entry_safe(trans, next, &net->nft.commit_list, list) {
- list_del(&trans->list);
- nf_tables_commit_release(trans);
- }
-
+ nf_tables_commit_release(net);
nf_tables_gen_notify(net, skb, NFT_MSG_NEWGEN);
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH 02/15] netfilter: x_tables: check name length in find_match/target, too
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180513223656.10077-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
ebtables uses find_match() rather than find_request_match in one case
(see bcf4934288402be3464110109a4dae3bd6fb3e93,
"netfilter: ebtables: Fix extension lookup with identical name"), so
extend the check on name length to those functions too.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index 71325fef647d..cb7cb300c3bc 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -183,6 +183,9 @@ struct xt_match *xt_find_match(u8 af, const char *name, u8 revision)
struct xt_match *m;
int err = -ENOENT;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
mutex_lock(&xt[af].mutex);
list_for_each_entry(m, &xt[af].match, list) {
if (strcmp(m->name, name) == 0) {
@@ -229,6 +232,9 @@ struct xt_target *xt_find_target(u8 af, const char *name, u8 revision)
struct xt_target *t;
int err = -ENOENT;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
mutex_lock(&xt[af].mutex);
list_for_each_entry(t, &xt[af].target, list) {
if (strcmp(t->name, name) == 0) {
--
2.11.0
^ permalink raw reply related
* [PATCH 01/15] netfilter: Fix handling simultaneous open in TCP conntrack
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180513223656.10077-1-pablo@netfilter.org>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Dominique Martinet reported a TCP hang problem when simultaneous open was used.
The problem is that the tcp_conntracks state table is not smart enough
to handle the case. The state table could be fixed by introducing a new state,
but that would require more lines of code compared to this patch, due to the
required backward compatibility with ctnetlink.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Reported-by: Dominique Martinet <asmadeus@codewreck.org>
Tested-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/netfilter/nf_conntrack_tcp.h | 3 +++
net/netfilter/nf_conntrack_proto_tcp.c | 11 +++++++++++
2 files changed, 14 insertions(+)
diff --git a/include/uapi/linux/netfilter/nf_conntrack_tcp.h b/include/uapi/linux/netfilter/nf_conntrack_tcp.h
index 74b91151d494..bcba72def817 100644
--- a/include/uapi/linux/netfilter/nf_conntrack_tcp.h
+++ b/include/uapi/linux/netfilter/nf_conntrack_tcp.h
@@ -46,6 +46,9 @@ enum tcp_conntrack {
/* Marks possibility for expected RFC5961 challenge ACK */
#define IP_CT_EXP_CHALLENGE_ACK 0x40
+/* Simultaneous open initialized */
+#define IP_CT_TCP_SIMULTANEOUS_OPEN 0x80
+
struct nf_ct_tcp_flags {
__u8 flags;
__u8 mask;
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index e97cdc1cf98c..8e67910185a0 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -981,6 +981,17 @@ static int tcp_packet(struct nf_conn *ct,
return NF_ACCEPT; /* Don't change state */
}
break;
+ case TCP_CONNTRACK_SYN_SENT2:
+ /* tcp_conntracks table is not smart enough to handle
+ * simultaneous open.
+ */
+ ct->proto.tcp.last_flags |= IP_CT_TCP_SIMULTANEOUS_OPEN;
+ break;
+ case TCP_CONNTRACK_SYN_RECV:
+ if (dir == IP_CT_DIR_REPLY && index == TCP_ACK_SET &&
+ ct->proto.tcp.last_flags & IP_CT_TCP_SIMULTANEOUS_OPEN)
+ new_state = TCP_CONNTRACK_ESTABLISHED;
+ break;
case TCP_CONNTRACK_CLOSE:
if (index == TCP_RST_SET
&& (ct->proto.tcp.seen[!dir].flags & IP_CT_TCP_FLAG_MAXACK_SET)
--
2.11.0
^ permalink raw reply related
* [PATCH 00/15] Netfilter/IPVS fixes for net
From: Pablo Neira Ayuso @ 2018-05-13 22:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter/IPVS fixes for your net tree,
they are:
1) Fix handling of simultaneous open TCP connection in conntrack,
from Jozsef Kadlecsik.
2) Insufficient sanitify check of xtables extension names, from
Florian Westphal.
3) Skip unnecessary synchronize_rcu() call when transaction log
is already empty, from Florian Westphal.
4) Incorrect destination mac validation in ebt_stp, from Stephen
Hemminger.
5) xtables module reference counter leak in nft_compat, from
Florian Westphal.
6) Incorrect connection reference counting logic in IPVS
one-packet scheduler, from Julian Anastasov.
7) Wrong stats for 32-bits CPU in IPVS, also from Julian.
8) Calm down sparse error in netfilter core, also from Florian.
9) Use nla_strlcpy to fix compilation warning in nfnetlink_acct
and nfnetlink_cthelper, again from Florian.
10) Missing module alias in icmp and icmp6 xtables extensions,
from Florian Westphal.
11) Base chain statistics in nf_tables may be unset/null, from Florian.
12) Fix handling of large matchinfo size in nft_compat, this includes
one preparation for before this fix. From Florian.
13) Fix bogus EBUSY error when deleting chains due to incorrect reference
counting from the preparation phase of the two-phase commit protocol.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks.
----------------------------------------------------------------
The following changes since commit 25eb0ea7174c6e84f21fa59dccbddd0318b17b12:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (2018-04-25 22:55:33 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to f0dfd7a2b35b02030949100247d851b793cb275f:
netfilter: nf_tables: fix memory leak on error exit return (2018-05-14 00:21:59 +0200)
----------------------------------------------------------------
Colin Ian King (1):
netfilter: nf_tables: fix memory leak on error exit return
Florian Westphal (9):
netfilter: x_tables: check name length in find_match/target, too
netfilter: nf_tables: skip synchronize_rcu if transaction log is empty
netfilter: nf_tables: nft_compat: fix refcount leak on xt module
netfilter: core: add missing __rcu annotation
netfilter: prefer nla_strlcpy for dealing with NLA_STRING attributes
netfilter: x_tables: add module alias for icmp matches
netfilter: nf_tables: don't assume chain stats are set when jumplabel is set
netfilter: nft_compat: prepare for indirect info storage
netfilter: nft_compat: fix handling of large matchinfo size
Jozsef Kadlecsik (1):
netfilter: Fix handling simultaneous open in TCP conntrack
Julian Anastasov (2):
ipvs: fix refcount usage for conns in ops mode
ipvs: fix stats update from local clients
Pablo Neira Ayuso (1):
netfilter: nf_tables: bogus EBUSY in chain deletions
Stephen Hemminger (1):
netfilter: bridge: stp fix reference to uninitialized data
include/net/netfilter/nf_tables.h | 5 +
include/uapi/linux/netfilter/nf_conntrack_tcp.h | 3 +
net/bridge/netfilter/ebt_stp.c | 4 +-
net/ipv4/netfilter/ip_tables.c | 1 +
net/ipv6/netfilter/ip6_tables.c | 1 +
net/netfilter/core.c | 3 +-
net/netfilter/ipvs/ip_vs_conn.c | 17 +-
net/netfilter/ipvs/ip_vs_core.c | 12 ++
net/netfilter/nf_conntrack_proto_tcp.c | 11 ++
net/netfilter/nf_tables_api.c | 77 +++++++--
net/netfilter/nf_tables_core.c | 21 ++-
net/netfilter/nfnetlink_acct.c | 2 +-
net/netfilter/nfnetlink_cthelper.c | 7 +-
net/netfilter/nft_compat.c | 201 ++++++++++++++++++------
net/netfilter/nft_immediate.c | 15 +-
net/netfilter/x_tables.c | 6 +
16 files changed, 299 insertions(+), 87 deletions(-)
^ permalink raw reply
* Proposal
From: Zeliha Omer Faruk @ 2018-05-13 21:54 UTC (permalink / raw)
--
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the net-next tree
From: Stephen Rothwell @ 2018-05-13 22:02 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Russell King,
Florian Fainelli
[-- Attachment #1: Type: text/plain, Size: 157 bytes --]
Hi all,
Commit
9cd00a8aa42e ("net: phy: phylink: Poll link GPIOs")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] sctp: add asoc and packet to sctp_flush_ctx
From: Marcelo Ricardo Leitner @ 2018-05-13 21:40 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Neil Horman, Vlad Yasevich, Xin Long
In-Reply-To: <8de39e2ff04a8a96440c8b5f66cbc5cbc6303067.1526142994.git.marcelo.leitner@gmail.com>
On Sat, May 12, 2018 at 07:21:51PM -0300, Marcelo Ricardo Leitner wrote:
> @@ -1043,20 +1038,17 @@ static bool sctp_outq_flush_rtx(struct sctp_flush_ctx *ctx,
> static void sctp_outq_flush_data(struct sctp_flush_ctx *ctx,
> int rtx_timeout)
> {
> - struct sctp_packet *packet = ctx->transport ? &ctx->transport->packet :
> - NULL;
> - struct sctp_association *asoc = ctx->q->asoc;
> struct sctp_chunk *chunk;
> enum sctp_xmit status;
>
> /* Is it OK to send data chunks? */
> - switch (asoc->state) {
> + switch (ctx->asoc->state) {
> case SCTP_STATE_COOKIE_ECHOED:
> /* Only allow bundling when this packet has a COOKIE-ECHO
> * chunk.
> */
> - if (!packet || !packet->has_cookie_echo)
> - return;
> + if (!ctx->packet || !ctx->packet->has_cookie_echo)
> + break;
This return/break change was by mistake. Will post v3 tomorrow.
^ permalink raw reply
* Re: general protection fault in rds_ib_get_mr
From: Eric Biggers @ 2018-05-13 21:10 UTC (permalink / raw)
To: linux-rdma, rds-devel, santosh.shilimkar
Cc: syzbot, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <089e082ce58896ad350567ee4825@google.com>
On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3215b9d57a2c75c4305a3956ca303d7004485200 (Wed Mar 21 00:44:27 2018 +0000)
> Merge tag 'clk-fixes-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=b51c77ef956678a65834
>
> So far this crash happened 4 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b51c77ef956678a65834@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1521615317.627:7): avc: denied { map } for
> pid=4240 comm="syzkaller468044" path="/root/syzkaller468044973" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4244 Comm: syzkaller468044 Not tainted 4.16.0-rc6+ #361
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544
> RSP: 0018:ffff8801b059f890 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: ffff8801b07e1300 RCX: ffffffff8562d96e
> RDX: 000000000000000d RSI: 0000000000000001 RDI: 0000000000000068
> RBP: ffff8801b059f8b8 R08: ffffed0036274244 R09: ffff8801b13a1200
> R10: 0000000000000004 R11: ffffed0036274243 R12: ffff8801b13a1200
> R13: 0000000000000001 R14: ffff8801ca09fa9c R15: 0000000000000000
> FS: 00007f4d050af700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f4d050aee78 CR3: 00000001b0d9b006 CR4: 00000000001606e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __rds_rdma_map+0x710/0x1050 net/rds/rdma.c:271
> rds_get_mr_for_dest+0x1d4/0x2c0 net/rds/rdma.c:357
> rds_setsockopt+0x6cc/0x980 net/rds/af_rds.c:347
> SYSC_setsockopt net/socket.c:1849 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1828
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4456d9
> RSP: 002b:00007f4d050aedb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 00000000004456d9
> RDX: 0000000000000007 RSI: 0000000000000114 RDI: 0000000000000004
> RBP: 00000000006dac38 R08: 00000000000000a0 R09: 0000000000000000
> R10: 0000000020000380 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fffbfb36d6f R14: 00007f4d050af9c0 R15: 0000000000000005
> Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 cc 01 00 00 4c 8b bb 80 04 00 00 48
> b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 9c 01 00 00 4d 8b 7f 68 48 b8 00 00 00 00 00
> RIP: rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544 RSP: ffff8801b059f890
> ---[ end trace 7e1cea13b85473b0 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
(next-20180511). Here's a simplified reproducer:
#include <linux/rds.h>
#include <netinet/in.h>
#include <unistd.h>
int main()
{
int transport = RDS_TRANS_IB;
int fd;
fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
setsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, &transport, sizeof(transport));
if (fork()) {
for (;;) {
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_port = 0,
.sin_addr = { htobe32(0x7f000001) },
};
bind(fd, (struct sockaddr *)&addr, sizeof(addr));
}
} else {
for (;;) {
char buf[128] = { 0 };
struct rds_get_mr_for_dest_args args = {
.vec = {
.addr = (unsigned long)buf,
.bytes = sizeof(buf),
},
};
setsockopt(fd, SOL_RDS, RDS_GET_MR_FOR_DEST, &args, sizeof(args));
}
}
}
BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 4 PID: 224 Comm: syz_rdma Not tainted 4.17.0-rc4-next-20180511 #40
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
RIP: 0010:rds_ib_get_mr+0x23/0xb0 net/rds/ib_rdma.c:547
Code: 93 5a a6 ff 5b 5d c3 55 48 89 e5 41 57 49 89 cf 41 56 41 55 49 89 f5 41 54 49 89 fc 53 48 8b 82 68 04 00 00 8b ba 50 04 00 00 <48> 8b 40 68 4c 8b b0 98 00 00 00 e8 fd ef ff ff 48 85 c0 0f 84 a6
RSP: 0018:ffffb39f4088fd10 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8c69f8f05a80 RCX: ffff8c69f986f49c
RDX: ffff8c69f8d75840 RSI: 0000000000000002 RDI: 000000000100007f
RBP: ffffb39f4088fd38 R08: ffff8c69f9a1a980 R09: 0000000000000002
R10: 0000000087654321 R11: 0000000000000000 R12: ffff8c69f8f05a80
R13: 0000000000000002 R14: ffff8c69f986f480 R15: ffff8c69f986f49c
FS: 00007f140caf4740(0000) GS:ffff8c69ffd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000068 CR3: 0000000078c2d000 CR4: 00000000003406e0
Call Trace:
__rds_rdma_map+0x36f/0x4c0 net/rds/rdma.c:271
rds_get_mr_for_dest+0x84/0xb0 net/rds/rdma.c:357
rds_setsockopt+0x176/0x360 net/rds/af_rds.c:350
__sys_setsockopt+0x6d/0xd0 net/socket.c:1910
__do_sys_setsockopt net/socket.c:1921 [inline]
__se_sys_setsockopt net/socket.c:1918 [inline]
__x64_sys_setsockopt+0x1f/0x30 net/socket.c:1918
do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f140c1fd20a
Code: 9c 2b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 36 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e6 9b 2b 00 f7 d8 64 89 01 48
RSP: 002b:00007fffcaa06f18 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fffcaa06f30 RCX: 00007f140c1fd20a
RDX: 0000000000000007 RSI: 0000000000000114 RDI: 0000000000000003
RBP: 00007fffcaa06fd0 R08: 00000000000000a0 R09: 00007f140c8da010
R10: 00007fffcaa06f30 R11: 0000000000000246 R12: 0000000000000003
R13: 00007fffcaa06f30 R14: 0000000000000000 R15: 0000000000000000
CR2: 0000000000000068
---[ end trace fd75e4e4e9b87576 ]---
^ permalink raw reply
* [PATCH net-next] sched: cls: enable verbose logging
From: Marcelo Ricardo Leitner @ 2018-05-13 20:44 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Ahern, Stephen Hemminger, Jiri Pirko,
Alexander Aring, Jamal Hadi Salim, Cong Wang, marcelo.leitner
Currently, when the rule is not to be exclusively executed by the
hardware, extack is not passed along and offloading failures don't
get logged. The idea was that hardware failures are okay because the
rule will get executed in software then and this way it doesn't confuse
unware users.
But this is not helpful in case one needs to understand why a certain
rule failed to get offloaded. Considering it may have been a temporary
failure, like resources exceeded or so, reproducing it later and knowing
that it is triggering the same reason may be challenging.
The ultimate goal is to improve Open vSwitch debuggability when using
flower offloading.
This patch adds a new flag to enable verbose logging. With the flag set,
extack will be passed to the driver, which will be able to log the
error. As the operation itself probably won't fail (not because of this,
at least), current iproute will already log it as a Warning.
The flag is generic, so it can be reused later. No need to restrict it
just for HW offloading. The command line will follow the syntax that
tc-ebpf already uses, tc ... [ verbose ] ... , and extend its meaning.
For example:
# ./tc qdisc add dev p7p1 ingress
# ./tc filter add dev p7p1 parent ffff: protocol ip prio 1 \
flower verbose \
src_mac ed:13:db:00:00:00 dst_mac 01:80:c2:00:00:d0 \
src_ip 56.0.0.0 dst_ip 55.0.0.0 action drop
Warning: TC offload is disabled on net device.
# echo $?
0
# ./tc filter add dev p7p1 parent ffff: protocol ip prio 1 \
flower \
src_mac ff:13:db:00:00:00 dst_mac 01:80:c2:00:00:d0 \
src_ip 56.0.0.0 dst_ip 55.0.0.0 action drop
# echo $?
0
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
Initial RFC was posted with subject "[PATCH RFC 0/2] Add support for
warnings to extack".
Changes since it:
- Use only a single error/warning message (instead of adding support to
multiple messages)
- Make it opt-in, as suggested by Jakub Kicinski.
- Enhanced changelog, as per David Ahern comment.
include/net/pkt_cls.h | 6 ++++--
include/uapi/linux/pkt_cls.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index e828d31be5dae0ae8c69016dfde50379296484aa..0005f0b40fe9310d8160018b3baaccf2cc098c4d 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -683,9 +683,11 @@ static inline bool tc_skip_sw(u32 flags)
/* SKIP_HW and SKIP_SW are mutually exclusive flags. */
static inline bool tc_flags_valid(u32 flags)
{
- if (flags & ~(TCA_CLS_FLAGS_SKIP_HW | TCA_CLS_FLAGS_SKIP_SW))
+ if (flags & ~(TCA_CLS_FLAGS_SKIP_HW | TCA_CLS_FLAGS_SKIP_SW |
+ TCA_CLS_FLAGS_VERBOSE))
return false;
+ flags &= TCA_CLS_FLAGS_SKIP_HW | TCA_CLS_FLAGS_SKIP_SW;
if (!(flags ^ (TCA_CLS_FLAGS_SKIP_HW | TCA_CLS_FLAGS_SKIP_SW)))
return false;
@@ -705,7 +707,7 @@ tc_cls_common_offload_init(struct tc_cls_common_offload *cls_common,
cls_common->chain_index = tp->chain->index;
cls_common->protocol = tp->protocol;
cls_common->prio = tp->prio;
- if (tc_skip_sw(flags))
+ if (tc_skip_sw(flags) || flags & TCA_CLS_FLAGS_VERBOSE)
cls_common->extack = extack;
}
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index be05e66c167b12a70db409242519a9b1958b1000..84e4c1d0f874afec5891fcf95def286c121f71ed 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -129,6 +129,7 @@ enum {
#define TCA_CLS_FLAGS_SKIP_SW (1 << 1) /* don't use filter in SW */
#define TCA_CLS_FLAGS_IN_HW (1 << 2) /* filter is offloaded to HW */
#define TCA_CLS_FLAGS_NOT_IN_HW (1 << 3) /* filter isn't offloaded to HW */
+#define TCA_CLS_FLAGS_VERBOSE (1 << 4) /* verbose logging */
/* U32 filters */
^ permalink raw reply related
* [PATCH iproute2-next] tc: flower: add support for verbose logging
From: Marcelo Ricardo Leitner @ 2018-05-13 20:44 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Ahern, Stephen Hemminger, Jiri Pirko,
Alexander Aring, Jamal Hadi Salim, Cong Wang, marcelo.leitner
In-Reply-To: <763cd60ed7addf605daf8b77c8639c5c08ada219.1526243501.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <mleitner@redhat.com>
Currently there is no way to log offloading errors if the rule is not
explicitly marked as skip_sw, making it hard for other applications such
as Open vSwitch to log why a given could not be offloaded.
This patch adds support for signaling the kernel that more verbose
logging is wanted, which now will include such messages.
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
---
include/uapi/linux/pkt_cls.h | 1 +
man/man8/tc-flower.8 | 7 +++++++
tc/f_flower.c | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index be05e66c167b12a70db409242519a9b1958b1000..84e4c1d0f874afec5891fcf95def286c121f71ed 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -129,6 +129,7 @@ enum {
#define TCA_CLS_FLAGS_SKIP_SW (1 << 1) /* don't use filter in SW */
#define TCA_CLS_FLAGS_IN_HW (1 << 2) /* filter is offloaded to HW */
#define TCA_CLS_FLAGS_NOT_IN_HW (1 << 3) /* filter isn't offloaded to HW */
+#define TCA_CLS_FLAGS_VERBOSE (1 << 4) /* verbose logging */
/* U32 filters */
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index a561443b9978bee55142f7dfed6b46106f7b9baf..4f3714b79544b33f198d711fa9006806685d43a8 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -22,6 +22,8 @@ flower \- flow based traffic control filter
.IR MATCH " := { "
.B indev
.IR ifname " | "
+.BR verbose
+.RI " | "
.BR skip_sw " | " skip_hw
.RI " | { "
.BR dst_mac " | " src_mac " } "
@@ -100,6 +102,11 @@ is the name of an interface which must exist at the time of
.B tc
invocation.
.TP
+.BI verbose
+Enable verbose logging, including offloading errors when not using
+.B skip_sw
+flag.
+.TP
.BI skip_sw
Do not process filter by software. If hardware has no offload support for this
filter, or TC offload is not enabled for the interface, operation will fail.
diff --git a/tc/f_flower.c b/tc/f_flower.c
index ba8eb66cdd111adf4f68f041fb6c4acc48fd1a90..c710765179fb08ac94e04ec664fac0d30cf04931 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -41,7 +41,7 @@ enum flower_icmp_field {
static void explain(void)
{
fprintf(stderr,
- "Usage: ... flower [ MATCH-LIST ]\n"
+ "Usage: ... flower [ MATCH-LIST ] [ verbose ]\n"
" [ skip_sw | skip_hw ]\n"
" [ action ACTION-SPEC ] [ classid CLASSID ]\n"
"\n"
@@ -648,6 +648,8 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
fprintf(stderr, "Illegal \"ip_flags\"\n");
return -1;
}
+ } else if (matches(*argv, "verbose") == 0) {
+ flags |= TCA_CLS_FLAGS_VERBOSE;
} else if (matches(*argv, "skip_hw") == 0) {
flags |= TCA_CLS_FLAGS_SKIP_HW;
} else if (matches(*argv, "skip_sw") == 0) {
--
2.14.3
^ permalink raw reply related
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:29 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Giuseppe Cavallaro, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <CAGb2v64ACc1tQRhy4LhnvCC7VJ3nVM-wMbgUgzviGMWKPFsSuQ@mail.gmail.com>
On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> > Hi Chen-Yu
> >> >
> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> > make it clear here these are MAC imposed delays.
> >>
> >> Yes these are applied on the MAC side. Being described in the device
> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> Are there known exceptions?
> >
> > There is frequent confusion with this. Most of the time, the PHY does
> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> > an exception in itself.
> >
> > Do you actually need these delays for the board you adding support
> > for? Does the PHY not support adding the needed delays? If you don't
> > need the delays, i would not even implement them.
>
> Yes this is already used on the Bananapi M3. This patch merely reformats
> the description and adds a note saying this only applies to RGMII mode.
Yes, the current code is needed for the Bananapi M3. But you have
another patch which extends the code to support a smaller range. Do
you have a board which actually needs this? If not, i would not add
that new code.
Andrew
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:27 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, Chen-Yu Tsai, devicetree, Maxime Ripard, netdev,
Rob Herring, Corentin Labbe, Giuseppe Cavallaro
In-Reply-To: <272E1914-029C-492C-B521-BC63D6A705D7@aosc.io>
On Mon, May 14, 2018 at 04:10:58AM +0800, Icenowy Zheng wrote:
>
>
> 于 2018年5月14日 GMT+08:00 上午4:05:29, Andrew Lunn <andrew@lunn.ch> 写到:
> >> > Hi Chen-Yu
> >> >
> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> > make it clear here these are MAC imposed delays.
> >>
> >> Yes these are applied on the MAC side. Being described in the device
> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> Are there known exceptions?
> >
> >There is frequent confusion with this. Most of the time, the PHY does
> >the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >an exception in itself.
> >
> >Do you actually need these delays for the board you adding support
> >for? Does the PHY not support adding the needed delays? If you don't
> >need the delays, i would not even implement them.
>
> They are needed if the rx/tx have not equal length.
>
> For several boards if the delay is not present, the network
> is unusable. (I have at least met this on Banana Pi M3, an
> Allwinner A83T SBC w/ RTL8211E)
The RTL8211E does not appear to support adding delays, via
registers. You can do it with strapping resistors. The RTL8211F does
support delays via a register. So for the Banana Pi M3 it is
justified.
However, in general, i would recommend letting the PHY do it, if it
can.
Andrew
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Icenowy Zheng @ 2018-05-13 20:10 UTC (permalink / raw)
To: linux-arm-kernel, Andrew Lunn, Chen-Yu Tsai
Cc: devicetree, Maxime Ripard, netdev, Rob Herring, Corentin Labbe,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <20180513200529.GF12738@lunn.ch>
于 2018年5月14日 GMT+08:00 上午4:05:29, Andrew Lunn <andrew@lunn.ch> 写到:
>> > Hi Chen-Yu
>> >
>> > Are these delays the MAC applies? Not the PHY. It would be good to
>> > make it clear here these are MAC imposed delays.
>>
>> Yes these are applied on the MAC side. Being described in the device
>> tree bindings for the MAC, I thought this was implied to be the case?
>> Are there known exceptions?
>
>There is frequent confusion with this. Most of the time, the PHY does
>the delay, not the MAC, based on the phy-mode. So the MAC doing it is
>an exception in itself.
>
>Do you actually need these delays for the board you adding support
>for? Does the PHY not support adding the needed delays? If you don't
>need the delays, i would not even implement them.
They are needed if the rx/tx have not equal length.
For several boards if the delay is not present, the network
is unusable. (I have at least met this on Banana Pi M3, an
Allwinner A83T SBC w/ RTL8211E)
>
> Andrew
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-13 20:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: Giuseppe Cavallaro, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513200529.GF12738@lunn.ch>
On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Hi Chen-Yu
>> >
>> > Are these delays the MAC applies? Not the PHY. It would be good to
>> > make it clear here these are MAC imposed delays.
>>
>> Yes these are applied on the MAC side. Being described in the device
>> tree bindings for the MAC, I thought this was implied to be the case?
>> Are there known exceptions?
>
> There is frequent confusion with this. Most of the time, the PHY does
> the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> an exception in itself.
>
> Do you actually need these delays for the board you adding support
> for? Does the PHY not support adding the needed delays? If you don't
> need the delays, i would not even implement them.
Yes this is already used on the Bananapi M3. This patch merely reformats
the description and adds a note saying this only applies to RGMII mode.
ChenYu
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:05 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Giuseppe Cavallaro, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <CAGb2v66nqWnioS1pwfWFtMZFZSWvf4SwXr_ExnnGvYsK9RU_LA@mail.gmail.com>
> > Hi Chen-Yu
> >
> > Are these delays the MAC applies? Not the PHY. It would be good to
> > make it clear here these are MAC imposed delays.
>
> Yes these are applied on the MAC side. Being described in the device
> tree bindings for the MAC, I thought this was implied to be the case?
> Are there known exceptions?
There is frequent confusion with this. Most of the time, the PHY does
the delay, not the MAC, based on the phy-mode. So the MAC doing it is
an exception in itself.
Do you actually need these delays for the board you adding support
for? Does the PHY not support adding the needed delays? If you don't
need the delays, i would not even implement them.
Andrew
^ permalink raw reply
* Re: INFO: trying to register non-static key in del_timer_sync
From: Eric Biggers @ 2018-05-13 19:59 UTC (permalink / raw)
To: syzbot
Cc: coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs
In-Reply-To: <001a114387b66c88ce0563dab5b8@google.com>
On Sun, Jan 28, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +0000)
> Merge tag 'riscv-for-linus-4.15-maintainers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux
>
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3659f05802671eb8af9c@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1517074079.617:7): avc: denied { map } for
> pid=3685 comm="syzkaller985951" path="/root/syzkaller985951088" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> register_lock_class+0x542/0x2cd0 kernel/locking/lockdep.c:752
> __lock_acquire+0x1de/0x3e00 kernel/locking/lockdep.c:3314
> lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
> del_timer_sync+0xba/0x240 kernel/time/timer.c:1275
> led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
> cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
> __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
> do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
> do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
> nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
> nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
> ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
> SYSC_setsockopt net/socket.c:1831 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1810
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4449fa
> RSP: 002b:00007ffee653a948 EFLAGS: 00000206 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00000000006cd0fc RCX: 00000000004449fa
> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
> RBP: 00000000006cd0fc R08: 00000000000002d8 R09: 000000000117c880
> R10: 00000000006cd528 R11: 0000000000000206 R12: 0000000000000003
> R13: 00000000006d00a4 R14: 00000000006d0050 R15: 00000000004a39ae
> ------------[ cut here ]------------
> ODEBUG: assert_init not available (active state 0) object type: timer_list
> hint: (null)
> WARNING: CPU: 1 PID: 3685 at lib/debugobjects.c:291
> debug_print_object+0x166/0x220 lib/debugobjects.c:288
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1096
> RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
> RSP: 0018:ffff8801d9adf7d0 EFLAGS: 00010282
> RAX: dffffc0000000008 RBX: 0000000000000005 RCX: ffffffff8159ebae
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000293
> RBP: ffff8801d9adf810 R08: 0000000000000000 R09: 1ffff1003b35be97
> R10: ffff8801d9adf6d0 R11: ffffffff86b38678 R12: 0000000000000001
> R13: ffffffff86b49d00 R14: ffffffff86010440 R15: ffffffff815f1530
> debug_object_assert_init+0x303/0x570 lib/debugobjects.c:654
> debug_timer_assert_init kernel/time/timer.c:707 [inline]
> debug_assert_init kernel/time/timer.c:759 [inline]
> try_to_del_timer_sync+0x74/0x130 kernel/time/timer.c:1215
> del_timer_sync+0x18a/0x240 kernel/time/timer.c:1285
> led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
> cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
> __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
> do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
> do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
> nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
> nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
> ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
> SYSC_setsockopt net/socket.c:1831 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1810
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4449fa
> RSP: 002b:00007ffee653a948 EFLAGS: 00000206 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00000000006cd0fc RCX: 00000000004449fa
> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
> RBP: 00000000006cd0fc R08: 00000000000002d8 R09: 000000000117c880
> R10: 00000000006cd528 R11: 0000000000000206 R12: 0000000000000003
> R13: 00000000006d00a4 R14: 00000000006d0050 R15: 00000000004a39ae
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
This was fixed by commit 10414014bc085a:
#syz fix: netfilter: x_tables: fix missing timer initialization in xt_LED
- Eric
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-13 19:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Giuseppe Cavallaro, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513194919.GE12738@lunn.ch>
On Sun, May 13, 2018 at 12:49 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 14, 2018 at 03:14:18AM +0800, Chen-Yu Tsai wrote:
>> The clock delay chains found in the glue layer for dwmac-sun8i are only
>> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
>> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
>> range of possible values for the delay chain.
>>
>> This patch reformats the delay chain section of the device tree binding
>> to make it clear that the delay chains only apply to RGMII PHYs, and
>> make it easier to add the R40-specific bits later.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>> ---
>> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> index 3d6d5fa0c4d5..e04ce75e24a3 100644
>> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> @@ -28,10 +28,13 @@ Required properties:
>> - allwinner,sun8i-a83t-system-controller
>>
>> Optional properties:
>> -- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
>> -- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
>> -Both delay properties need to be a multiple of 100. They control the delay for
>> -external PHY.
>> +- allwinner,tx-delay-ps: TX clock delay chain value in ps.
>> + Range is 0-700. Default is 0.
>> +- allwinner,rx-delay-ps: RX clock delay chain value in ps.
>> + Range is 0-3100. Default is 0.
>> +Both delay properties need to be a multiple of 100. They control the
>> +clock delay for external RGMII PHY. They do not apply to the internal
>> +PHY or external non-RGMII PHYs.
>
> Hi Chen-Yu
>
> Are these delays the MAC applies? Not the PHY. It would be good to
> make it clear here these are MAC imposed delays.
Yes these are applied on the MAC side. Being described in the device
tree bindings for the MAC, I thought this was implied to be the case?
Are there known exceptions?
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 19:49 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Giuseppe Cavallaro, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513191425.9801-2-wens@csie.org>
On Mon, May 14, 2018 at 03:14:18AM +0800, Chen-Yu Tsai wrote:
> The clock delay chains found in the glue layer for dwmac-sun8i are only
> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
> range of possible values for the delay chain.
>
> This patch reformats the delay chain section of the device tree binding
> to make it clear that the delay chains only apply to RGMII PHYs, and
> make it easier to add the R40-specific bits later.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> index 3d6d5fa0c4d5..e04ce75e24a3 100644
> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> @@ -28,10 +28,13 @@ Required properties:
> - allwinner,sun8i-a83t-system-controller
>
> Optional properties:
> -- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
> -- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
> -Both delay properties need to be a multiple of 100. They control the delay for
> -external PHY.
> +- allwinner,tx-delay-ps: TX clock delay chain value in ps.
> + Range is 0-700. Default is 0.
> +- allwinner,rx-delay-ps: RX clock delay chain value in ps.
> + Range is 0-3100. Default is 0.
> +Both delay properties need to be a multiple of 100. They control the
> +clock delay for external RGMII PHY. They do not apply to the internal
> +PHY or external non-RGMII PHYs.
Hi Chen-Yu
Are these delays the MAC applies? Not the PHY. It would be good to
make it clear here these are MAC imposed delays.
Andrew
^ permalink raw reply
* [PATCH] net: ipv4: ipconfig: fix unused variable
From: Anders Roxell @ 2018-05-13 19:48 UTC (permalink / raw)
To: davem, kuznet, yoshfuji; +Cc: netdev, linux-kernel, Anders Roxell
When CONFIG_PROC_FS isn't set, variable ipconfig_dir isn't used.
net/ipv4/ipconfig.c:167:31: warning: ‘ipconfig_dir’ defined but not used [-Wunused-variable]
static struct proc_dir_entry *ipconfig_dir;
^~~~~~~~~~~~
Move the declaration of ipconfig_dir inside the CONFIG_PROC_FS ifdef to
fix the warning.
Fixes: c04d2cb2009f ("ipconfig: Write NTP server IPs to /proc/net/ipconfig/ntp_servers")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
net/ipv4/ipconfig.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index d839d74853fc..86c9f755de3d 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -163,9 +163,6 @@ static u8 ic_domain[64]; /* DNS (not NIS) domain name */
* Private state.
*/
-/* proc_dir_entry for /proc/net/ipconfig */
-static struct proc_dir_entry *ipconfig_dir;
-
/* Name of user-selected boot device */
static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
@@ -1292,6 +1289,8 @@ static int __init ic_dynamic(void)
#endif /* IPCONFIG_DYNAMIC */
#ifdef CONFIG_PROC_FS
+/* proc_dir_entry for /proc/net/ipconfig */
+static struct proc_dir_entry *ipconfig_dir;
/* Name servers: */
static int pnp_seq_show(struct seq_file *seq, void *v)
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Chen-Yu Tsai @ 2018-05-13 19:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
Stephen Boyd, netdev, Michael Turquette, Rob Herring,
Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk
In-Reply-To: <20180502115437.zlu2rafrguufutvp@flea>
On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
>> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> ><maxime.ripard@bootlin.com> wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >>>
>> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >currently
>> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >>> register. As SRAM controller driver can now export regmap for this
>> >>> register, replace the syscon node to the SRAM controller device
>> >node,
>> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >>>
>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >>> ---
>> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >+++++++++++++++----
>> >>> 1 file changed, 19 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> @@ -168,10 +168,25 @@
>> >>> #size-cells = <1>;
>> >>> ranges;
>> >>>
>> >>> - syscon: syscon@1c00000 {
>> >>> - compatible =
>> >"allwinner,sun50i-a64-system-controller",
>> >>> - "syscon";
>> >>> + sram_controller: sram-controller@1c00000 {
>> >>> + compatible =
>> >"allwinner,sun50i-a64-sram-controller";
>> >>
>> >> I don't think there's anything preventing us from keeping the
>> >> -system-controller compatible. It's what was in the DT before, and
>> >> it's how it's called in the datasheet.
>> >
>> >I actually meant to ask you about this. The -system-controller
>> >compatible matches the datasheet better. Maybe we should just
>> >switch to that one?
>>
>> No, if we do the switch the system-controller compatible,
>> the device will be probed on the same memory region with
>> a syscon on old DTs.
>
> The device hasn't magically changed either. Maybe we just need to add
> a check to make sure we don't have the syscon compatible in the SRAM
> driver probe so that the double driver issue doesn't happen?
The syscon interface (which is not even a full blown device driver)
only looks at the "syscon" compatible. Either way we're removing that
part from the device tree so things should be ok for new device trees.
As Maxime mentioned we can do a check for the syscon compatible and
either give a warning to the user asking them to update their device
tree, or not register our custom regmap, or not probe the SRAM driver.
Personally I prefer the first option. The system controller block is
probed before any syscon users, so we should be fine, given the dwmac
driver goes the custom regmap path first.
BTW, I still might end up changing the compatible. The manual uses
"system control", not "system controller", which I think makes sense,
since it is just a bunch of register files, kind of like the GRF
(General Register Files) block found in Rockchip SoCs [1], and not an
actual "controller".
ChenYu
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockchip/grf.txt
^ permalink raw reply
* [PATCH RESEND net-next v2 5/8] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: Giuseppe Cavallaro
Cc: Chen-Yu Tsai, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the Allwinner R40, the "GMAC clock" register is located in the CCU
block, at a different register address than the other SoCs that have
it in the "system control" block.
This patch converts the use of regmap to regmap_field for mapping and
accessing the syscon register, so we can have the register address in
the variants data, and not in the actual register manipulation code.
This patch only converts regmap_read() and regmap_write() calls to
regmap_field_read() and regmap_field_write() calls. There are some
places where it might make sense to switch to regmap_field_update_bits(),
but this is not done here to keep the patch simple.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 42 ++++++++++++++-----
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..bbc051474806 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -42,6 +42,7 @@
* This value is used for disabling properly EMAC
* and used as a good starting value in case of the
* boot process(uboot) leave some stuff.
+ * @syscon_field reg_field for the syscon's gmac register
* @soc_has_internal_phy: Does the MAC embed an internal PHY
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
@@ -49,6 +50,7 @@
*/
struct emac_variant {
u32 default_syscon_value;
+ const struct reg_field *syscon_field;
bool soc_has_internal_phy;
bool support_mii;
bool support_rmii;
@@ -71,13 +73,21 @@ struct sunxi_priv_data {
struct regulator *regulator;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
- struct regmap *regmap;
+ struct regmap_field *regmap_field;
bool internal_phy_powered;
void *mux_handle;
};
+/* EMAC clock register @ 0x30 in the "system control" address range */
+static const struct reg_field sun8i_syscon_reg_field = {
+ .reg = 0x30,
+ .lsb = 0,
+ .msb = 31,
+};
+
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
@@ -86,12 +96,14 @@ static const struct emac_variant emac_variant_h3 = {
static const struct emac_variant emac_variant_v3s = {
.default_syscon_value = 0x38000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true
};
static const struct emac_variant emac_variant_a83t = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rgmii = true
@@ -99,6 +111,7 @@ static const struct emac_variant emac_variant_a83t = {
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
@@ -216,7 +229,6 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_ETCS_MII 0x0
#define SYSCON_ETCS_EXT_GMII 0x1
#define SYSCON_ETCS_INT_GMII 0x2
-#define SYSCON_EMAC_REG 0x30
/* sun8i_dwmac_dma_reset() - reset the EMAC
* Called from stmmac via stmmac_dma_ops->reset
@@ -745,7 +757,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
bool need_power_ephy = false;
if (current_child ^ desired_child) {
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, ®);
+ regmap_field_read(gmac->regmap_field, ®);
switch (desired_child) {
case DWMAC_SUN8I_MDIO_MUX_INTERNAL_ID:
dev_info(priv->device, "Switch mux to internal PHY");
@@ -763,7 +775,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
desired_child);
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, val);
+ regmap_field_write(gmac->regmap_field, val);
if (need_power_ephy) {
ret = sun8i_dwmac_power_internal_phy(priv);
if (ret)
@@ -801,7 +813,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
int ret;
u32 reg, val;
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ regmap_field_read(gmac->regmap_field, &val);
reg = gmac->variant->default_syscon_value;
if (reg != val)
dev_warn(priv->device,
@@ -883,7 +895,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
return 0;
}
@@ -892,7 +904,7 @@ static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
{
u32 reg = gmac->variant->default_syscon_value;
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
}
static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
@@ -980,6 +992,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
int ret;
struct stmmac_priv *priv;
struct net_device *ndev;
+ struct regmap *regmap;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
@@ -1014,14 +1027,21 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
- "syscon");
- if (IS_ERR(gmac->regmap)) {
- ret = PTR_ERR(gmac->regmap);
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
return ret;
}
+ gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
+ *gmac->variant->syscon_field);
+ if (IS_ERR(gmac->regmap_field)) {
+ ret = PTR_ERR(gmac->regmap_field);
+ dev_err(dev, "Unable to map syscon register: %d\n", ret);
+ return ret;
+ }
+
plat_dat->interface = of_get_phy_mode(dev->of_node);
/* platform data specifying hardware features and callbacks.
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 6/8] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: Giuseppe Cavallaro
Cc: Chen-Yu Tsai, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
address space. Using a standard syscon to access it provides no
coordination with the CCU driver for register access. Neither does
it prevent this and other drivers from accessing other, maybe critical,
clock control registers. On other SoCs, the register is in the "system
control" address space, which might also contain controls for mapping
SRAM to devices or the CPU. This hardware has the same issues.
Instead, for these types of setups, we let the device containing the
control register create a regmap tied to it. We can then get the device
from the existing syscon phandle, and retrieve the regmap with
dev_get_regmap().
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 50 ++++++++++++++++++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index bbc051474806..79e104a20e20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -983,6 +983,34 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
return mac;
}
+static struct regmap *sun8i_dwmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static int sun8i_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -1027,7 +1055,27 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ /* The "GMAC clock control" register might be located in the
+ * CCU address range (on the R40), or the system control address
+ * range (on most other sun8i and later SoCs).
+ *
+ * The former controls most if not all clocks in the SoC. The
+ * latter has an SoC identification register, and on some SoCs,
+ * controls to map device specific SRAM to either the intended
+ * peripheral, or the CPU address space.
+ *
+ * In either case, there should be a coordinated and restricted
+ * method of accessing the register needed here. This is done by
+ * having the device export a custom regmap, instead of a generic
+ * syscon, which grants all access to all registers.
+ *
+ * To support old device trees, we fall back to using the syscon
+ * interface if possible.
+ */
+ regmap = sun8i_dwmac_get_syscon_from_dev(pdev->dev.of_node);
+ if (IS_ERR(regmap))
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 7/8] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: Giuseppe Cavallaro
Cc: Chen-Yu Tsai, linux-arm-kernel, devicetree, netdev,
Corentin Labbe, Icenowy Zheng, Maxime Ripard, Rob Herring
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred
picoseconds), instead of 0~31. Also the TX delay chain is completely
absent.
This patch adds support for different ranges by adding per-compatible
maximum values in the variant data. A maximum of 0 indicates that the
delay chain is not supported or absent.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 +++++++++++++------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 79e104a20e20..4f5612a3c855 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -47,6 +47,12 @@
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
* @support_rgmii: Does the MAC handle RGMII
+ *
+ * @rx_delay_max: Maximum raw value for RX delay chain
+ * @tx_delay_max: Maximum raw value for TX delay chain
+ * These two also indicate the bitmask for
+ * the RX and TX delay chain registers. A
+ * value of zero indicates this is not supported.
*/
struct emac_variant {
u32 default_syscon_value;
@@ -55,6 +61,8 @@ struct emac_variant {
bool support_mii;
bool support_rmii;
bool support_rgmii;
+ u8 rx_delay_max;
+ u8 tx_delay_max;
};
/* struct sunxi_priv_data - hold all sunxi private data
@@ -91,7 +99,9 @@ static const struct emac_variant emac_variant_h3 = {
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_v3s = {
@@ -106,7 +116,9 @@ static const struct emac_variant emac_variant_a83t = {
.syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_a64 = {
@@ -115,7 +127,9 @@ static const struct emac_variant emac_variant_a64 = {
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
#define EMAC_BASIC_CTL0 0x00
@@ -219,9 +233,7 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
/* Generic system control EMAC_CLK bits */
-#define SYSCON_ETXDC_MASK GENMASK(2, 0)
#define SYSCON_ETXDC_SHIFT 10
-#define SYSCON_ERXDC_MASK GENMASK(4, 0)
#define SYSCON_ERXDC_SHIFT 5
/* EMAC PHY Interface Type */
#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
@@ -847,8 +859,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set tx-delay to %x\n", val);
- if (val <= SYSCON_ETXDC_MASK) {
- reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ if (val <= gmac->variant->tx_delay_max) {
+ reg &= ~(gmac->variant->tx_delay_max <<
+ SYSCON_ETXDC_SHIFT);
reg |= (val << SYSCON_ETXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid TX clock delay: %d\n",
@@ -864,8 +877,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set rx-delay to %x\n", val);
- if (val <= SYSCON_ERXDC_MASK) {
- reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ if (val <= gmac->variant->rx_delay_max) {
+ reg &= ~(gmac->variant->rx_delay_max <<
+ SYSCON_ERXDC_SHIFT);
reg |= (val << SYSCON_ERXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid RX clock delay: %d\n",
--
2.17.0
^ permalink raw reply related
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