* [RFC -next v0 1/3] bpf: modular maps
From: Aaron Conole @ 2018-11-25 18:09 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, netfilter-devel, coreteam, Alexei Starovoitov,
Daniel Borkmann, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, John Fastabend, Jesper Brouer, David S . Miller,
Andy Gospodarek, Rony Efraim, Simon Horman, Marcelo Leitner
In-Reply-To: <20181125180919.13996-1-aconole@bytheb.org>
This commit allows for map operations to be loaded by an lkm, rather than
needing to be baked into the kernel at compile time.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
---
include/linux/bpf.h | 6 +++++
init/Kconfig | 8 +++++++
kernel/bpf/syscall.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 33014ae73103..bf4531f076ca 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -553,6 +553,7 @@ static inline int bpf_map_attr_numa_node(const union bpf_attr *attr)
struct bpf_prog *bpf_prog_get_type_path(const char *name, enum bpf_prog_type type);
int array_map_alloc_check(union bpf_attr *attr);
+void bpf_map_insert_ops(size_t id, const struct bpf_map_ops *ops);
#else /* !CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get(u32 ufd)
@@ -665,6 +666,11 @@ static inline struct bpf_prog *bpf_prog_get_type_path(const char *name,
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline void bpf_map_insert_ops(size_t id,
+ const struct bpf_map_ops *ops)
+{
+}
#endif /* CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get_type(u32 ufd,
diff --git a/init/Kconfig b/init/Kconfig
index a4112e95724a..aa4eb98af656 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1489,6 +1489,14 @@ config BPF_JIT_ALWAYS_ON
Enables BPF JIT and removes BPF interpreter to avoid
speculative execution of BPF instructions by the interpreter
+config BPF_LOADABLE_MAPS
+ bool "Allow map types to be loaded with modules"
+ depends on BPF_SYSCALL && MODULES
+ help
+ Enables BPF map types to be provided by loadable modules
+ instead of always compiled in. Maps provided dynamically
+ may only be used by super users.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index cf5040fd5434..fa1db9ab81e1 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -49,6 +49,8 @@ static DEFINE_SPINLOCK(map_idr_lock);
int sysctl_unprivileged_bpf_disabled __read_mostly;
+const struct bpf_map_ops loadable_map = {};
+
static const struct bpf_map_ops * const bpf_map_types[] = {
#define BPF_PROG_TYPE(_id, _ops)
#define BPF_MAP_TYPE(_id, _ops) \
@@ -58,6 +60,15 @@ static const struct bpf_map_ops * const bpf_map_types[] = {
#undef BPF_MAP_TYPE
};
+static const struct bpf_map_ops * bpf_loadable_map_types[] = {
+#define BPF_PROG_TYPE(_id, _ops)
+#define BPF_MAP_TYPE(_id, _ops) \
+ [_id] = NULL,
+#include <linux/bpf_types.h>
+#undef BPF_PROG_TYPE
+#undef BPF_MAP_TYPE
+};
+
/*
* If we're handed a bigger struct than we know of, ensure all the unknown bits
* are 0 - i.e. new user-space does not rely on any kernel feature extensions
@@ -105,6 +116,48 @@ const struct bpf_map_ops bpf_map_offload_ops = {
.map_check_btf = map_check_no_btf,
};
+/*
+ * Fills in the modular ops map, provided that the entry is not already
+ * filled, and that the caller has CAP_SYS_ADMIN. */
+void bpf_map_insert_ops(size_t id, const struct bpf_map_ops *ops)
+{
+#ifdef CONFIG_BPF_LOADABLE_MAPS
+ if (!capable(CAP_SYS_ADMIN))
+ return;
+
+ if (id >= ARRAY_SIZE(bpf_loadable_map_types))
+ return;
+
+ id = array_index_nospec(id, ARRAY_SIZE(bpf_loadable_map_types));
+ if (bpf_loadable_map_types[id] == NULL)
+ bpf_loadable_map_types[id] = ops;
+#endif
+}
+EXPORT_SYMBOL_GPL(bpf_map_insert_ops);
+
+static const struct bpf_map_ops *find_loadable_ops(u32 type)
+{
+ struct user_struct *user = get_current_user();
+ const struct bpf_map_ops *ops = NULL;
+
+ if (user->uid.val)
+ goto done;
+
+#ifdef CONFIG_BPF_LOADABLE_MAPS
+ if (!capable(CAP_SYS_ADMIN))
+ goto done;
+
+ if (type >= ARRAY_SIZE(bpf_loadable_map_types))
+ goto done;
+ type = array_index_nospec(type, ARRAY_SIZE(bpf_loadable_map_types));
+ ops = bpf_loadable_map_types[type];
+#endif
+
+done:
+ free_uid(user);
+ return ops;
+}
+
static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
{
const struct bpf_map_ops *ops;
@@ -115,7 +168,8 @@ static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
if (type >= ARRAY_SIZE(bpf_map_types))
return ERR_PTR(-EINVAL);
type = array_index_nospec(type, ARRAY_SIZE(bpf_map_types));
- ops = bpf_map_types[type];
+ ops = (bpf_map_types[type] != &loadable_map) ? bpf_map_types[type] :
+ find_loadable_ops(type);
if (!ops)
return ERR_PTR(-EINVAL);
@@ -180,6 +234,7 @@ int bpf_map_precharge_memlock(u32 pages)
return -EPERM;
return 0;
}
+EXPORT_SYMBOL_GPL(bpf_map_precharge_memlock);
static int bpf_charge_memlock(struct user_struct *user, u32 pages)
{
--
2.19.1
^ permalink raw reply related
* [RFC -next v0 2/3] netfilter: nf_flow_table: support a new 'snoop' mode
From: Aaron Conole @ 2018-11-25 18:09 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, netfilter-devel, coreteam, Alexei Starovoitov,
Daniel Borkmann, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, John Fastabend, Jesper Brouer, David S . Miller,
Andy Gospodarek, Rony Efraim, Simon Horman, Marcelo Leitner
In-Reply-To: <20181125180919.13996-1-aconole@bytheb.org>
This patch adds the ability for a flow table to receive updates on
all flows added/removed to any flow table in the system. This will
allow other subsystems in the kernel to register a lookup mechanism
into the nftables connection tracker for those connections which
should be sent to a flow offload table.
Each flow table can now be set with some kinds of flags, and if
one of those flags is the new 'snoop' flag, it will be updated
whenever a flow entry is added or removed to any flow table.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
---
include/net/netfilter/nf_flow_table.h | 5 +++
include/uapi/linux/netfilter/nf_tables.h | 2 ++
net/netfilter/nf_flow_table_core.c | 44 ++++++++++++++++++++++--
net/netfilter/nf_tables_api.c | 13 ++++++-
4 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/include/net/netfilter/nf_flow_table.h b/include/net/netfilter/nf_flow_table.h
index 77e2761d4f2f..3fdfeb17f500 100644
--- a/include/net/netfilter/nf_flow_table.h
+++ b/include/net/netfilter/nf_flow_table.h
@@ -20,9 +20,14 @@ struct nf_flowtable_type {
struct module *owner;
};
+enum nf_flowtable_flags {
+ NF_FLOWTABLE_F_SNOOP = 0x1,
+};
+
struct nf_flowtable {
struct list_head list;
struct rhashtable rhashtable;
+ u32 flags;
const struct nf_flowtable_type *type;
struct delayed_work gc_work;
};
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 7de4f1bdaf06..f1cfe30aecde 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -1482,6 +1482,7 @@ enum nft_object_attributes {
* @NFTA_FLOWTABLE_HOOK: netfilter hook configuration(NLA_U32)
* @NFTA_FLOWTABLE_USE: number of references to this flow table (NLA_U32)
* @NFTA_FLOWTABLE_HANDLE: object handle (NLA_U64)
+ * @NFTA_FLOWTABLE_FLAGS: flags (NLA_U32)
*/
enum nft_flowtable_attributes {
NFTA_FLOWTABLE_UNSPEC,
@@ -1491,6 +1492,7 @@ enum nft_flowtable_attributes {
NFTA_FLOWTABLE_USE,
NFTA_FLOWTABLE_HANDLE,
NFTA_FLOWTABLE_PAD,
+ NFTA_FLOWTABLE_FLAGS,
__NFTA_FLOWTABLE_MAX
};
#define NFTA_FLOWTABLE_MAX (__NFTA_FLOWTABLE_MAX - 1)
diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index b7a4816add76..289a2299eea2 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -15,6 +15,7 @@
struct flow_offload_entry {
struct flow_offload flow;
struct nf_conn *ct;
+ struct nf_flow_route route;
struct rcu_head rcu_head;
};
@@ -78,6 +79,7 @@ flow_offload_alloc(struct nf_conn *ct, struct nf_flow_route *route)
goto err_dst_cache_reply;
entry->ct = ct;
+ entry->route = *route;
flow_offload_fill_dir(flow, ct, route, FLOW_OFFLOAD_DIR_ORIGINAL);
flow_offload_fill_dir(flow, ct, route, FLOW_OFFLOAD_DIR_REPLY);
@@ -100,6 +102,18 @@ flow_offload_alloc(struct nf_conn *ct, struct nf_flow_route *route)
}
EXPORT_SYMBOL_GPL(flow_offload_alloc);
+static struct flow_offload *flow_offload_clone(struct flow_offload *flow)
+{
+ struct flow_offload *clone_flow_val;
+ struct flow_offload_entry *e;
+
+ e = container_of(flow, struct flow_offload_entry, flow);
+
+ clone_flow_val = flow_offload_alloc(e->ct, &e->route);
+
+ return clone_flow_val;
+}
+
static void flow_offload_fixup_tcp(struct ip_ct_tcp *tcp)
{
tcp->state = TCP_CONNTRACK_ESTABLISHED;
@@ -182,7 +196,7 @@ static const struct rhashtable_params nf_flow_offload_rhash_params = {
.automatic_shrinking = true,
};
-int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)
+static void __flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)
{
flow->timeout = (u32)jiffies;
@@ -192,12 +206,30 @@ int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)
rhashtable_insert_fast(&flow_table->rhashtable,
&flow->tuplehash[FLOW_OFFLOAD_DIR_REPLY].node,
nf_flow_offload_rhash_params);
+}
+
+int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)
+{
+ struct nf_flowtable *flowtable;
+
+ __flow_offload_add(flow_table, flow);
+
+ mutex_lock(&flowtable_lock);
+ list_for_each_entry(flowtable, &flowtables, list) {
+ if (flowtable != flow_table &&
+ flowtable->flags & NF_FLOWTABLE_F_SNOOP) {
+ struct flow_offload *flow_clone =
+ flow_offload_clone(flow);
+ __flow_offload_add(flowtable, flow_clone);
+ }
+ }
+ mutex_unlock(&flowtable_lock);
return 0;
}
EXPORT_SYMBOL_GPL(flow_offload_add);
-static void flow_offload_del(struct nf_flowtable *flow_table,
- struct flow_offload *flow)
+static void __flow_offload_del(struct nf_flowtable *flow_table,
+ struct flow_offload *flow)
{
struct flow_offload_entry *e;
@@ -210,6 +242,12 @@ static void flow_offload_del(struct nf_flowtable *flow_table,
e = container_of(flow, struct flow_offload_entry, flow);
clear_bit(IPS_OFFLOAD_BIT, &e->ct->status);
+}
+
+static void flow_offload_del(struct nf_flowtable *flow_table,
+ struct flow_offload *flow)
+{
+ __flow_offload_del(flow_table, flow);
flow_offload_free(flow);
}
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 42487d01a3ed..8148de9f9a54 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -5569,6 +5569,15 @@ static int nf_tables_newflowtable(struct net *net, struct sock *nlsk,
if (err < 0)
goto err3;
+ if (nla[NFTA_FLOWTABLE_FLAGS]) {
+ flowtable->data.flags =
+ ntohl(nla_get_be32(nla[NFTA_FLOWTABLE_FLAGS]));
+ if (flowtable->data.flags & ~NF_FLOWTABLE_F_SNOOP) {
+ err = -EINVAL;
+ goto err4;
+ }
+ }
+
err = nf_tables_flowtable_parse_hook(&ctx, nla[NFTA_FLOWTABLE_HOOK],
flowtable);
if (err < 0)
@@ -5694,7 +5703,9 @@ static int nf_tables_fill_flowtable_info(struct sk_buff *skb, struct net *net,
nla_put_string(skb, NFTA_FLOWTABLE_NAME, flowtable->name) ||
nla_put_be32(skb, NFTA_FLOWTABLE_USE, htonl(flowtable->use)) ||
nla_put_be64(skb, NFTA_FLOWTABLE_HANDLE, cpu_to_be64(flowtable->handle),
- NFTA_FLOWTABLE_PAD))
+ NFTA_FLOWTABLE_PAD) ||
+ nla_put_be32(skb, NFTA_FLOWTABLE_FLAGS,
+ htonl(flowtable->data.flags)))
goto nla_put_failure;
nest = nla_nest_start(skb, NFTA_FLOWTABLE_HOOK);
--
2.19.1
^ permalink raw reply related
* [PATCH bpf-next 2/2] tools/bpf: change selftest test_btf for both jit and non-jit
From: Yonghong Song @ 2018-11-25 7:20 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20181125072045.1389189-1-yhs@fb.com>
The selftest test_btf is changed to test both jit and non-jit.
The test result should be the same regardless of whether jit
is enabled or not.
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/testing/selftests/bpf/test_btf.c | 33 +++-----------------------
1 file changed, 3 insertions(+), 30 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_btf.c b/tools/testing/selftests/bpf/test_btf.c
index bcbda7037840..b4c8725b3004 100644
--- a/tools/testing/selftests/bpf/test_btf.c
+++ b/tools/testing/selftests/bpf/test_btf.c
@@ -29,7 +29,6 @@
static uint32_t pass_cnt;
static uint32_t error_cnt;
static uint32_t skip_cnt;
-static bool jit_enabled;
#define CHECK(condition, format...) ({ \
int __ret = !!(condition); \
@@ -65,24 +64,6 @@ static int __base_pr(const char *format, ...)
return err;
}
-static bool is_jit_enabled(void)
-{
- const char *jit_sysctl = "/proc/sys/net/core/bpf_jit_enable";
- bool enabled = false;
- int sysctl_fd;
-
- sysctl_fd = open(jit_sysctl, 0, O_RDONLY);
- if (sysctl_fd != -1) {
- char tmpc;
-
- if (read(sysctl_fd, &tmpc, sizeof(tmpc)) == 1)
- enabled = (tmpc != '0');
- close(sysctl_fd);
- }
-
- return enabled;
-}
-
#define BTF_INFO_ENC(kind, root, vlen) \
((!!(root) << 31) | ((kind) << 24) | ((vlen) & BTF_MAX_VLEN))
@@ -2547,8 +2528,8 @@ static int do_test_file(unsigned int test_num)
test->btf_kv_notfound))
goto done;
- if (!jit_enabled || !has_btf_ext)
- goto skip_jit;
+ if (!has_btf_ext)
+ goto skip;
/* get necessary program info */
info_len = sizeof(struct bpf_prog_info);
@@ -2636,7 +2617,7 @@ static int do_test_file(unsigned int test_num)
finfo = (void *)finfo + rec_size;
}
-skip_jit:
+skip:
fprintf(stderr, "OK");
done:
@@ -3270,12 +3251,6 @@ static int do_test_func_type(int test_num)
err = -1;
goto done;
}
- if (!jit_enabled) {
- skip_cnt++;
- fprintf(stderr, "SKIPPED, please enable sysctl bpf_jit_enable\n");
- err = 0;
- goto done;
- }
/* get necessary lens */
info_len = sizeof(struct bpf_prog_info);
@@ -3452,8 +3427,6 @@ int main(int argc, char **argv)
if (args.always_log)
libbpf_set_print(__base_pr, __base_pr, __base_pr);
- jit_enabled = is_jit_enabled();
-
if (args.raw_test)
err |= test_raw();
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/2] bpf: btf: support proper non-jit func info
From: Yonghong Song @ 2018-11-25 7:20 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20181125072045.1389189-1-yhs@fb.com>
Commit 838e96904ff3 ("bpf: Introduce bpf_func_info")
added bpf func info support. The userspace is able
to get better ksym's for bpf programs with jit, and
is able to print out func prototypes.
For a program containing func-to-func calls, the existing
implementation returns user specified number of function
calls and BTF types if jit is enabled. If the jit is not
enabled, it only returns the type for the main function.
This is undesirable. Interpreter may still be used
and we should keep feature identical regardless of
whether jit is enabled or not.
This patch fixed this discrepancy.
Fixes: 838e96904ff3 ("bpf: Introduce bpf_func_info")
Signed-off-by: Yonghong Song <yhs@fb.com>
---
include/linux/bpf.h | 6 ++--
include/linux/bpf_verifier.h | 1 -
kernel/bpf/core.c | 3 +-
kernel/bpf/syscall.c | 33 ++++++----------------
kernel/bpf/verifier.c | 55 +++++++++++++++++++++++++-----------
5 files changed, 52 insertions(+), 46 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 7f0e225bf630..e82b7039fc66 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -299,7 +299,8 @@ struct bpf_prog_aux {
u32 max_pkt_offset;
u32 stack_depth;
u32 id;
- u32 func_cnt;
+ u32 func_cnt; /* used by non-func prog as the number of func progs */
+ u32 func_idx; /* 0 for non-func prog, the index in func array for func prog */
bool offload_requested;
struct bpf_prog **func;
void *jit_data; /* JIT specific data. arch dependent */
@@ -317,7 +318,8 @@ struct bpf_prog_aux {
#endif
struct bpf_prog_offload *offload;
struct btf *btf;
- u32 type_id; /* type id for this prog/func */
+ struct bpf_func_info *func_info;
+ u32 func_info_cnt;
union {
struct work_struct work;
struct rcu_head rcu;
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 204382f46fd8..11f5df1092d9 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -204,7 +204,6 @@ static inline bool bpf_verifier_log_needed(const struct bpf_verifier_log *log)
struct bpf_subprog_info {
u32 start; /* insn idx of function entry point */
u16 stack_depth; /* max. stack depth used by this function */
- u32 type_id; /* btf type_id for this subprog */
};
/* single container for all structs
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 16d77012ad3e..002d67c62c8b 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -411,7 +411,8 @@ static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
/* prog->aux->name will be ignored if full btf name is available */
if (prog->aux->btf) {
- type = btf_type_by_id(prog->aux->btf, prog->aux->type_id);
+ type = btf_type_by_id(prog->aux->btf,
+ prog->aux->func_info[prog->aux->func_idx].type_id);
func_name = btf_name_by_offset(prog->aux->btf, type->name_off);
snprintf(sym, (size_t)(end - sym), "_%s", func_name);
return;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 998377808102..85cbeec06e50 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1214,6 +1214,7 @@ static void __bpf_prog_put(struct bpf_prog *prog, bool do_idr_lock)
bpf_prog_free_id(prog, do_idr_lock);
bpf_prog_kallsyms_del_all(prog);
btf_put(prog->aux->btf);
+ kvfree(prog->aux->func_info);
call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
}
@@ -2219,46 +2220,28 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
}
if (prog->aux->btf) {
+ u32 krec_size = sizeof(struct bpf_func_info);
u32 ucnt, urec_size;
info.btf_id = btf_id(prog->aux->btf);
ucnt = info.func_info_cnt;
- info.func_info_cnt = prog->aux->func_cnt ? : 1;
+ info.func_info_cnt = prog->aux->func_info_cnt;
urec_size = info.func_info_rec_size;
- info.func_info_rec_size = sizeof(struct bpf_func_info);
+ info.func_info_rec_size = krec_size;
if (ucnt) {
/* expect passed-in urec_size is what the kernel expects */
if (urec_size != info.func_info_rec_size)
return -EINVAL;
if (bpf_dump_raw_ok()) {
- struct bpf_func_info kern_finfo;
char __user *user_finfo;
- u32 i, insn_offset;
user_finfo = u64_to_user_ptr(info.func_info);
- if (prog->aux->func_cnt) {
- ucnt = min_t(u32, info.func_info_cnt, ucnt);
- insn_offset = 0;
- for (i = 0; i < ucnt; i++) {
- kern_finfo.insn_offset = insn_offset;
- kern_finfo.type_id = prog->aux->func[i]->aux->type_id;
- if (copy_to_user(user_finfo, &kern_finfo,
- sizeof(kern_finfo)))
- return -EFAULT;
-
- /* func[i]->len holds the prog len */
- insn_offset += prog->aux->func[i]->len;
- user_finfo += urec_size;
- }
- } else {
- kern_finfo.insn_offset = 0;
- kern_finfo.type_id = prog->aux->type_id;
- if (copy_to_user(user_finfo, &kern_finfo,
- sizeof(kern_finfo)))
- return -EFAULT;
- }
+ ucnt = min_t(u32, info.func_info_cnt, ucnt);
+ if (copy_to_user(user_finfo, prog->aux->func_info,
+ krec_size * ucnt))
+ return -EFAULT;
} else {
info.func_info_cnt = 0;
}
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f102c4fd0c5a..05d95c0e4a26 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4650,7 +4650,7 @@ static int check_btf_func(struct bpf_prog *prog, struct bpf_verifier_env *env,
{
u32 i, nfuncs, urec_size, min_size, prev_offset;
u32 krec_size = sizeof(struct bpf_func_info);
- struct bpf_func_info krecord = {};
+ struct bpf_func_info *krecord = NULL;
const struct btf_type *type;
void __user *urecord;
struct btf *btf;
@@ -4682,6 +4682,12 @@ static int check_btf_func(struct bpf_prog *prog, struct bpf_verifier_env *env,
urecord = u64_to_user_ptr(attr->func_info);
min_size = min_t(u32, krec_size, urec_size);
+ krecord = kvcalloc(nfuncs, krec_size, GFP_KERNEL | __GFP_NOWARN);
+ if (!krecord) {
+ ret = -ENOMEM;
+ goto free_btf;
+ }
+
for (i = 0; i < nfuncs; i++) {
ret = bpf_check_uarg_tail_zero(urecord, krec_size, urec_size);
if (ret) {
@@ -4696,59 +4702,69 @@ static int check_btf_func(struct bpf_prog *prog, struct bpf_verifier_env *env,
goto free_btf;
}
- if (copy_from_user(&krecord, urecord, min_size)) {
+ if (copy_from_user(&krecord[i], urecord, min_size)) {
ret = -EFAULT;
goto free_btf;
}
/* check insn_offset */
if (i == 0) {
- if (krecord.insn_offset) {
+ if (krecord[i].insn_offset) {
verbose(env,
"nonzero insn_offset %u for the first func info record",
- krecord.insn_offset);
+ krecord[i].insn_offset);
ret = -EINVAL;
goto free_btf;
}
- } else if (krecord.insn_offset <= prev_offset) {
+ } else if (krecord[i].insn_offset <= prev_offset) {
verbose(env,
"same or smaller insn offset (%u) than previous func info record (%u)",
- krecord.insn_offset, prev_offset);
+ krecord[i].insn_offset, prev_offset);
ret = -EINVAL;
goto free_btf;
}
- if (env->subprog_info[i].start != krecord.insn_offset) {
+ if (env->subprog_info[i].start != krecord[i].insn_offset) {
verbose(env, "func_info BTF section doesn't match subprog layout in BPF program\n");
ret = -EINVAL;
goto free_btf;
}
/* check type_id */
- type = btf_type_by_id(btf, krecord.type_id);
+ type = btf_type_by_id(btf, krecord[i].type_id);
if (!type || BTF_INFO_KIND(type->info) != BTF_KIND_FUNC) {
verbose(env, "invalid type id %d in func info",
- krecord.type_id);
+ krecord[i].type_id);
ret = -EINVAL;
goto free_btf;
}
- if (i == 0)
- prog->aux->type_id = krecord.type_id;
- env->subprog_info[i].type_id = krecord.type_id;
-
- prev_offset = krecord.insn_offset;
+ prev_offset = krecord[i].insn_offset;
urecord += urec_size;
}
prog->aux->btf = btf;
+ prog->aux->func_info = krecord;
+ prog->aux->func_info_cnt = nfuncs;
return 0;
free_btf:
btf_put(btf);
+ kvfree(krecord);
return ret;
}
+static void adjust_btf_func(struct bpf_verifier_env *env)
+{
+ int i;
+
+ if (!env->prog->aux->func_info)
+ return;
+
+ for (i = 0; i < env->subprog_cnt; i++)
+ env->prog->aux->func_info[i].insn_offset = env->subprog_info[i].start;
+}
+
/* check %cur's range satisfies %old's */
static bool range_within(struct bpf_reg_state *old,
struct bpf_reg_state *cur)
@@ -6043,15 +6059,17 @@ static int jit_subprogs(struct bpf_verifier_env *env)
if (bpf_prog_calc_tag(func[i]))
goto out_free;
func[i]->is_func = 1;
+ func[i]->aux->func_idx = i;
+ /* the btf and func_info will be freed only at prog->aux */
+ func[i]->aux->btf = prog->aux->btf;
+ func[i]->aux->func_info = prog->aux->func_info;
+
/* Use bpf_prog_F_tag to indicate functions in stack traces.
* Long term would need debug info to populate names
*/
func[i]->aux->name[0] = 'F';
func[i]->aux->stack_depth = env->subprog_info[i].stack_depth;
func[i]->jit_requested = 1;
- /* the btf will be freed only at prog->aux */
- func[i]->aux->btf = prog->aux->btf;
- func[i]->aux->type_id = env->subprog_info[i].type_id;
func[i] = bpf_int_jit_compile(func[i]);
if (!func[i]->jited) {
err = -ENOTSUPP;
@@ -6572,6 +6590,9 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
convert_pseudo_ld_imm64(env);
}
+ if (ret == 0)
+ adjust_btf_func(env);
+
err_release_maps:
if (!env->prog->aux->used_maps)
/* if we didn't copy map pointers into bpf_prog_info, release
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 0/2] bpf: support proper non-jit func info
From: Yonghong Song @ 2018-11-25 7:20 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
Commit 838e96904ff3 ("bpf: Introduce bpf_func_info")
added bpf func info support. The userspace is able
to get better ksym's for bpf programs with jit, and
is able to print out func prototypes.
For a program containing func-to-func calls, the existing
implementation returns user specified number of function
calls and BTF types if jit is enabled. If the jit is not
enabled, it only returns the type for the main function.
This is undesirable. Interpreter may still be used
and we should keep feature identical regardless of
whether jit is enabled or not.
This patch fixed this discrepancy.
The following example shows bpftool output for
the bpf program in selftests test_btf_haskv.o when jit
is disabled:
$ bpftool prog dump xlated id 1490
int _dummy_tracepoint(struct dummy_tracepoint_args * arg):
0: (85) call pc+2#__bpf_prog_run_args32
1: (b7) r0 = 0
2: (95) exit
int test_long_fname_1(struct dummy_tracepoint_args * arg):
3: (85) call pc+1#__bpf_prog_run_args32
4: (95) exit
int test_long_fname_2(struct dummy_tracepoint_args * arg):
5: (b7) r2 = 0
6: (63) *(u32 *)(r10 -4) = r2
7: (79) r1 = *(u64 *)(r1 +8)
8: (15) if r1 == 0x0 goto pc+9
9: (bf) r2 = r10
10: (07) r2 += -4
11: (18) r1 = map[id:1173]
13: (85) call bpf_map_lookup_elem#77088
14: (15) if r0 == 0x0 goto pc+3
15: (61) r1 = *(u32 *)(r0 +4)
16: (07) r1 += 1
17: (63) *(u32 *)(r0 +4) = r1
18: (95) exit
$ bpftool prog dump jited id 1490
no instructions returned
Yonghong Song (2):
bpf: btf: support proper non-jit func info
tools/bpf: change selftest test_btf for both jit and non-jit
include/linux/bpf.h | 6 ++-
include/linux/bpf_verifier.h | 1 -
kernel/bpf/core.c | 3 +-
kernel/bpf/syscall.c | 33 ++++------------
kernel/bpf/verifier.c | 55 ++++++++++++++++++--------
tools/testing/selftests/bpf/test_btf.c | 33 ++--------------
6 files changed, 55 insertions(+), 76 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net-next v3 4/4] enetc: Add RFS and RSS support
From: kbuild test robot @ 2018-11-25 7:28 UTC (permalink / raw)
To: Claudiu Manoil
Cc: kbuild-all, David S . Miller, netdev, linux-kernel,
alexandru.marginean, catalin.horghidan
In-Reply-To: <1542969963-10676-5-git-send-email-claudiu.manoil@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
Hi Claudiu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Claudiu-Manoil/Introduce-ENETC-ethernet-drivers/20181124-111823
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> drivers/net/ethernet/freescale/enetc/enetc_hw.h:310:16: warning: cast to restricted __le64
vim +310 drivers/net/ethernet/freescale/enetc/enetc_hw.h
58399e118 Claudiu Manoil 2018-11-23 292
58399e118 Claudiu Manoil 2018-11-23 293 /* general register accessors */
58399e118 Claudiu Manoil 2018-11-23 294 #define enetc_rd_reg(reg) ioread32((reg))
58399e118 Claudiu Manoil 2018-11-23 295 #define enetc_wr_reg(reg, val) iowrite32((val), (reg))
7b02f2a09 Claudiu Manoil 2018-11-23 296 #ifdef ioread64
7b02f2a09 Claudiu Manoil 2018-11-23 297 #define enetc_rd_reg64(reg) ioread64((reg))
7b02f2a09 Claudiu Manoil 2018-11-23 298 #else
7b02f2a09 Claudiu Manoil 2018-11-23 299 /* using this to read out stats on 32b systems */
7b02f2a09 Claudiu Manoil 2018-11-23 300 static inline u64 enetc_rd_reg64(void __iomem *reg)
7b02f2a09 Claudiu Manoil 2018-11-23 301 {
7b02f2a09 Claudiu Manoil 2018-11-23 302 u32 low, high, tmp;
7b02f2a09 Claudiu Manoil 2018-11-23 303
7b02f2a09 Claudiu Manoil 2018-11-23 304 do {
7b02f2a09 Claudiu Manoil 2018-11-23 305 high = ioread32(reg + 4);
7b02f2a09 Claudiu Manoil 2018-11-23 306 low = ioread32(reg);
7b02f2a09 Claudiu Manoil 2018-11-23 307 tmp = ioread32(reg + 4);
7b02f2a09 Claudiu Manoil 2018-11-23 308 } while (high != tmp);
7b02f2a09 Claudiu Manoil 2018-11-23 309
7b02f2a09 Claudiu Manoil 2018-11-23 @310 return le64_to_cpu((u64)high << 32 | low);
7b02f2a09 Claudiu Manoil 2018-11-23 311 }
7b02f2a09 Claudiu Manoil 2018-11-23 312 #endif
58399e118 Claudiu Manoil 2018-11-23 313
:::::: The code at line 310 was first introduced by commit
:::::: 7b02f2a0900df6d70fa9ddc8f4cb9a438db6e115 enetc: Add ethtool statistics
:::::: TO: Claudiu Manoil <claudiu.manoil@nxp.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66614 bytes --]
^ permalink raw reply
* Re: [PATCH][V2] net: bridge: remove redundant checks for null p->dev and p->br
From: David Miller @ 2018-11-25 18:26 UTC (permalink / raw)
To: colin.king; +Cc: nikolay, netdev, roopa, bridge, kernel-janitors, linux-kernel
In-Reply-To: <20181125160851.6919-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 25 Nov 2018 16:08:51 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> A recent change added a null check on p->dev after p->dev was being
> dereferenced by the ns_capable check on p->dev. It turns out that
> neither the p->dev and p->br null checks are necessary, and can be
> removed, which cleans up a static analyis warning.
>
> As Nikolay Aleksandrov noted, these checks can be removed because:
>
> "My reasoning of why it shouldn't be possible:
> - On port add new_nbp() sets both p->dev and p->br before creating
> kobj/sysfs
>
> - On port del (trickier) del_nbp() calls kobject_del() before call_rcu()
> to destroy the port which in turn calls sysfs_remove_dir() which uses
> kernfs_remove() which deactivates (shouldn't be able to open new
> files) and calls kernfs_drain() to drain current open/mmaped files in
> the respective dir before continuing, thus making it impossible to
> open a bridge port sysfs file with p->dev and p->br equal to NULL.
>
> So I think it's safe to remove those checks altogether. It'd be nice to
> get a second look over my reasoning as I might be missing something in
> sysfs/kernfs call path."
>
> Thanks to Nikolay Aleksandrov's suggestion to remove the check and
> David Miller for sanity checking this.
>
> Detected by CoverityScan, CID#751490 ("Dereference before null check")
>
> Fixes: a5f3ea54f3cc ("net: bridge: add support for raw sysfs port options")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: bridge: add support for user-controlled bool options
From: Nikolay Aleksandrov @ 2018-11-25 8:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <98A5C526-DBF7-40F0-9CB0-1C7AF7A5CF32@cumulusnetworks.com>
On 24/11/2018 18:46, nikolay@cumulusnetworks.com wrote:
> On 24 November 2018 18:25:41 EET, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Sat, Nov 24, 2018 at 06:18:33PM +0200, nikolay@cumulusnetworks.com
>> wrote:
>>> On 24 November 2018 18:10:41 EET, Andrew Lunn <andrew@lunn.ch> wrote:
>>>>> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id
>> opt,
>>>> bool on,
>>>>> + struct netlink_ext_ack *extack)
>>>>> +{
>>>>> + switch (opt) {
>>>>> + default:
>>>>> + /* shouldn't be called with unsupported options */
>>>>> + WARN_ON(1);
>>>>> + break;
>>>>
>>>> So you return 0 here, meaning the br_debug() lower down will not
>>>> happen. Maybe return -EOPNOTSUPP?
>>>>
>>>
>>> No, the idea here is that some option in the future might return an
>> error.
>>> This function cannot be called with unsupported option thus the warn.
>>
>>
>> O.K, i was trying to make it easier to see which option caused it to
>> happen.
>>
>>>>> + }
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>
>>>>> +int br_boolopt_multi_toggle(struct net_bridge *br,
>>>>> + struct br_boolopt_multi *bm,
>>>>> + struct netlink_ext_ack *extack)
>>>>> +{
>>>>> + unsigned long bitmap = bm->optmask;
>>>>> + int err = 0;
>>>>> + int opt_id;
>>>>> +
>>>>> + for_each_set_bit(opt_id, &bitmap, BR_BOOLOPT_MAX) {
>>>>> + bool on = !!(bm->optval & BIT(opt_id));
>>>>> +
>>>>> + err = br_boolopt_toggle(br, opt_id, on, extack);
>>>>> + if (err) {
>>>>> + br_debug(br, "boolopt multi-toggle error: option: %d current:
>> %d
>>>> new: %d error: %d\n",
>>>>> + opt_id, br_boolopt_get(br, opt_id), on, err);
>>>>> + break;
>>>>> + }
>>>>> + }
>>>>
>>>> Does the semantics of extack allow you to return something even when
>>>> there is no error? If there are bits > BR_BOOLOPT_MAX you could
>> return
>>>> 0, but also add a warning in extack that some bits where not
>> supported
>>>> by this kernel.
>>>
>>> If we return 0 there's no reason to check extack.
>>
>> Well, the caller can check to see if extack is present, even on
>> success. This is extack, not extnack after all...
>>
>
> Evenif it's possible to return it without an error (I need to confirm that), the real problem is extack doesn't support
> format strings, i. e. we can't say which bit is missing which makes it useless in this case IMO.
>
One more thing I forgot to mention is the case with newer iproute2 and older kernel without
these patches, then the whole boolopt option will be ignored without setting extact which
makes it inconsistent if user-space would rely on that to check if options were set.
I think the best way to go if one wants to check for support is to dump the boolopts
if they're present, then optmask could be used to see what will be set (or was set).
That would be reliable in all cases.
>> Andrew
>
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add __weak hook for allocating executable memory
From: kbuild test robot @ 2018-11-25 19:17 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, Eric Dumazet, Daniel Borkmann, Ard Biesheuvel,
Catalin Marinas, Jann Horn, Will Deacon, Alexei Starovoitov,
linux-kernel, netdev, Arnd Bergmann, kbuild-all, Jessica Yu,
Rick Edgecombe, David S. Miller, linux-arm-kernel, Kees Cook
In-Reply-To: <20181123094152.21368-2-ard.biesheuvel@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]
Hi Ard,
I love your patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v4.20-rc3 next-20181123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/bpf-permit-JIT-allocations-to-be-served-outside-the-module-region/20181126-024110
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: x86_64-randconfig-x007-201847 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
kernel//bpf/core.c: In function 'bpf_jit_free_exec':
>> kernel//bpf/core.c:619:17: warning: passing argument 1 of 'module_memfree' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
module_memfree(addr);
^~~~
In file included from kernel//bpf/core.c:28:0:
include/linux/moduleloader.h:30:6: note: expected 'void *' but argument is of type 'const void *'
void module_memfree(void *module_region);
^~~~~~~~~~~~~~
vim +619 kernel//bpf/core.c
616
617 void __weak bpf_jit_free_exec(const void *addr)
618 {
> 619 module_memfree(addr);
620 }
621
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28772 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v3 13/13] nvme-tcp: add NVMe over TCP host driver
From: Sagi Grimberg @ 2018-11-25 9:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-nvme, linux-block, netdev, Keith Busch, David S. Miller
In-Reply-To: <20181122080224.GA26504@lst.de>
>> +static enum nvme_tcp_recv_state nvme_tcp_recv_state(struct nvme_tcp_queue *queue)
>> +{
>> + return (queue->pdu_remaining) ? NVME_TCP_RECV_PDU :
>> + (queue->ddgst_remaining) ? NVME_TCP_RECV_DDGST :
>> + NVME_TCP_RECV_DATA;
>> +}
>
> This just seems to be used in a single switch statement. Why the detour
> theough the state enum?
I think its clearer that the calling switch statement is switching on
an explicit state...
I can add the queue an explicit recv_state that would transition
these states like the target does, would that be better?
>> + /*
>> + * FIXME: This assumes that data comes in-order,
>> + * need to handle the out-of-order case.
>> + */
>
> That sounds like something we should really address before merging.
That is an old comment from the first days where the
spec didn't explicitly state that data is transferred in
order for a single request. Will drop the comment.
>> + read_lock(&sk->sk_callback_lock);
>> + queue = sk->sk_user_data;
>> + if (unlikely(!queue || !queue->rd_enabled))
>> + goto done;
>> +
>> + queue_work_on(queue->io_cpu, nvme_tcp_wq, &queue->io_work);
>> +done:
>> + read_unlock(&sk->sk_callback_lock);
>
> Don't we need a rcu_dereference_sk_user_data here?
If I'm protected with the sk_callback_lock I don't need
it do I? I wander if I can remove the sk_callback_lock
and move to rcu only? That would require careful look
as when I change the callbacks I need to synchronize rcu
before clearing sk_user_data..
It seems that only tunneling ulps are using it so I'm not
sure that the actual user should use it...
> Also why not:
>
> queue = rcu_dereference_sk_user_data(sk);
> if (likely(queue && queue->rd_enabled))
> queue_work_on(queue->io_cpu, nvme_tcp_wq, &queue->io_work);
> read_unlock(&sk->sk_callback_lock);
That I'll change...
>> +static void nvme_tcp_fail_request(struct nvme_tcp_request *req)
>> +{
>> + union nvme_result res = {};
>> +
>> + nvme_end_request(blk_mq_rq_from_pdu(req),
>> + NVME_SC_DATA_XFER_ERROR, res);
>
> This looks like odd formatting, needs one more tab. But
> NVME_SC_DATA_XFER_ERROR is also generally a status that should be
> returned from the nvme controller, not made up on the host.
Well.. the driver did fail to transfer data... What would be a
better completion status then?
>> + if (req->state == NVME_TCP_SEND_CMD_PDU) {
>> + ret = nvme_tcp_try_send_cmd_pdu(req);
>> + if (ret <= 0)
>> + goto done;
>> + if (!nvme_tcp_has_inline_data(req))
>> + return ret;
>> + }
>> +
>> + if (req->state == NVME_TCP_SEND_H2C_PDU) {
>> + ret = nvme_tcp_try_send_data_pdu(req);
>> + if (ret <= 0)
>> + goto done;
>> + }
>> +
>> + if (req->state == NVME_TCP_SEND_DATA) {
>> + ret = nvme_tcp_try_send_data(req);
>> + if (ret <= 0)
>> + goto done;
>> + }
>> +
>> + if (req->state == NVME_TCP_SEND_DDGST)
>> + ret = nvme_tcp_try_send_ddgst(req);
>
> Use a switch statement here?
The code flow is expected to fallthru as the command sequence continues
such that I don't need to "re-call" the routine...
For example, for in-capsule write, we will start in SEND_CMD_PDU,
continue to SEND_DATA and then to SEND_DDGST (if data digest exists)..
>> +static void nvme_tcp_free_tagset(struct nvme_ctrl *nctrl,
>> + struct blk_mq_tag_set *set)
>> +{
>> + blk_mq_free_tag_set(set);
>> +}
>
> Please drop this wrapper.
>
>> +static struct blk_mq_tag_set *nvme_tcp_alloc_tagset(struct nvme_ctrl *nctrl,
>> + bool admin)
>> +{
>
> This function does two entirely different things based on the admin
> paramter.
These two were left as such from my attempts to converge some
code over in the core.. I can remove them if you insist...
>> +int nvme_tcp_configure_admin_queue(struct nvme_ctrl *ctrl, bool new)
>
> Shouldn't this (or anything in this file for that matter) be static?
Again, leftovers from my attempts to converge code...
>> +static void nvme_tcp_delete_ctrl(struct nvme_ctrl *ctrl)
>> +{
>> + nvme_tcp_teardown_ctrl(ctrl, true);
>> +}
>
> Pointless wrapper.
nvme_tcp_delete_ctrl() is a callback.
>> +static void nvme_tcp_set_sg_null(struct nvme_command *c)
>> +{
>> + struct nvme_sgl_desc *sg = &c->common.dptr.sgl;
>> +
>> + sg->addr = 0;
>> + sg->length = 0;
>> + sg->type = (NVME_TRANSPORT_SGL_DATA_DESC << 4) |
>> + NVME_SGL_FMT_TRANSPORT_A;
>> +}
>> +
>> +static void nvme_tcp_set_sg_host_data(struct nvme_tcp_request *req,
>> + struct nvme_command *c)
>> +{
>> + struct nvme_sgl_desc *sg = &c->common.dptr.sgl;
>> +
>> + sg->addr = 0;
>> + sg->length = cpu_to_le32(req->data_len);
>> + sg->type = (NVME_TRANSPORT_SGL_DATA_DESC << 4) |
>> + NVME_SGL_FMT_TRANSPORT_A;
>> +}
>
> Do we really need nvme_tcp_set_sg_null? Any command it is called
> on should have a request with a 0 length, so it could use
> nvme_tcp_set_sg_host_data.
We don't..
>> +static enum blk_eh_timer_return
>> +nvme_tcp_timeout(struct request *rq, bool reserved)
>> +{
>> + struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
>> + struct nvme_tcp_ctrl *ctrl = req->queue->ctrl;
>> + struct nvme_tcp_cmd_pdu *pdu = req->pdu;
>> +
>> + dev_dbg(ctrl->ctrl.device,
>> + "queue %d: timeout request %#x type %d\n",
>> + nvme_tcp_queue_id(req->queue), rq->tag,
>> + pdu->hdr.type);
>> +
>> + if (ctrl->ctrl.state != NVME_CTRL_LIVE) {
>> + union nvme_result res = {};
>> +
>> + nvme_req(rq)->flags |= NVME_REQ_CANCELLED;
>> + nvme_end_request(rq, NVME_SC_ABORT_REQ, res);
>> + return BLK_EH_DONE;
>
> This looks odd. It's not really the timeout handlers job to
> call nvme_end_request here.
Well.. if we are not yet LIVE, we will not trigger error
recovery, which means nothing will complete this command so
something needs to do it...
I think that we need it for rdma too..
...
The rest of the comments will be addressed in the next submission..
^ permalink raw reply
* Re: [PATCH v3 11/13] nvmet-tcp: add NVMe over TCP target driver
From: Sagi Grimberg @ 2018-11-25 9:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-nvme, linux-block, netdev, Keith Busch, David S. Miller
In-Reply-To: <20181122090655.GA27707@lst.de>
>> + if (!cmd || queue->state == NVMET_TCP_Q_DISCONNECTING) {
>> + cmd = nvmet_tcp_fetch_send_command(queue);
>> + if (unlikely(!cmd))
>> + return 0;
>> + }
>> +
>> + if (cmd->state == NVMET_TCP_SEND_DATA_PDU) {
>> + ret = nvmet_try_send_data_pdu(cmd);
>> + if (ret <= 0)
>> + goto done_send;
>> + }
>> +
>> + if (cmd->state == NVMET_TCP_SEND_DATA) {
>> + ret = nvmet_try_send_data(cmd);
>> + if (ret <= 0)
>> + goto done_send;
>> + }
>> +
>> + if (cmd->state == NVMET_TCP_SEND_DDGST) {
>> + ret = nvmet_try_send_ddgst(cmd);
>> + if (ret <= 0)
>> + goto done_send;
>> + }
>> +
>> + if (cmd->state == NVMET_TCP_SEND_R2T) {
>> + ret = nvmet_try_send_r2t(cmd, last_in_batch);
>> + if (ret <= 0)
>> + goto done_send;
>> + }
>> +
>> + if (cmd->state == NVMET_TCP_SEND_RESPONSE)
>> + ret = nvmet_try_send_response(cmd, last_in_batch);
>
> Use a switch statement?
The intent would be such that the state would transition with
the progression of the routine...
...
The rest of the comments will be addressed in the next submission..
^ permalink raw reply
* [PATCH net-next 0/5] mlxsw: Prepare for VLAN-aware bridge w/VxLAN
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
The driver is using 802.1Q filtering identifiers (FIDs) to represent the
different VLANs in the VLAN-aware bridge (only one is supported).
However, the device cannot assign a VNI to such FIDs, which prevents the
driver from supporting the enslavement of VxLAN devices to the
VLAN-aware bridge.
This patchset works around this limitation by emulating 802.1Q FIDs
using 802.1D FIDs, which can be assigned a VNI and so far have only been
used in conjunction with VLAN-unaware bridges.
The downside of this approach is that multiple {Port,VID}->FID entries
are required, whereas a single VID->FID entry is required with "true"
802.1Q FIDs.
First four patches introduce the new FID family of emulated 802.1Q FIDs
and the associated type of router interfaces (RIFs). Last patch flips
the driver to use this new FID family.
The diff is relatively small because the internal implementation of each
FID family is contained and hidden in spectrum_fid.c. Different internal
users (e.g., bridge, router) are aware of the different FID types, but
do not care about their internal implementation. This makes it trivial
to swap the current implementation of 802.1Q FIDs with the new one,
using 802.1D FIDs.
Ido Schimmel (5):
mlxsw: spectrum_switchdev: Do not set field when it is reserved
mlxsw: spectrum_fid: Make flood index calculation more robust
mlxsw: spectrum_fid: Introduce emulated 802.1Q FIDs
mlxsw: spectrum_router: Introduce emulated VLAN RIFs
mlxsw: spectrum: Flip driver to use emulated 802.1Q FIDs
.../net/ethernet/mellanox/mlxsw/spectrum.c | 14 +++---
.../net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
.../ethernet/mellanox/mlxsw/spectrum_fid.c | 44 ++++++++++++++++++-
.../ethernet/mellanox/mlxsw/spectrum_router.c | 11 ++++-
.../mellanox/mlxsw/spectrum_switchdev.c | 3 +-
5 files changed, 63 insertions(+), 10 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH net-next 1/5] mlxsw: spectrum_switchdev: Do not set field when it is reserved
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20181125094210.17298-1-idosch@mellanox.com>
When configuring an FDB entry pointing to a LAG netdev (or its upper),
the driver should only set the 'lag_vid' field when the FID (filtering
identifier) is of 802.1D type.
Extend the 802.1D FID family with an attribute indicating whether this
field should be set and based on its value set the field or leave it
blank.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 7 +++++++
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 3 ++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 973a9d2901f7..244972bf8b0a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -721,6 +721,7 @@ int mlxsw_sp_setup_tc_prio(struct mlxsw_sp_port *mlxsw_sp_port,
struct tc_prio_qopt_offload *p);
/* spectrum_fid.c */
+bool mlxsw_sp_fid_lag_vid_valid(const struct mlxsw_sp_fid *fid);
struct mlxsw_sp_fid *mlxsw_sp_fid_lookup_by_index(struct mlxsw_sp *mlxsw_sp,
u16 fid_index);
int mlxsw_sp_fid_nve_ifindex(const struct mlxsw_sp_fid *fid, int *nve_ifindex);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
index 71b2d20afcc2..5008bf63d73b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
@@ -98,6 +98,7 @@ struct mlxsw_sp_fid_family {
enum mlxsw_sp_rif_type rif_type;
const struct mlxsw_sp_fid_ops *ops;
struct mlxsw_sp *mlxsw_sp;
+ u8 lag_vid_valid:1;
};
static const int mlxsw_sp_sfgc_uc_packet_types[MLXSW_REG_SFGC_TYPE_MAX] = {
@@ -122,6 +123,11 @@ static const int *mlxsw_sp_packet_type_sfgc_types[] = {
[MLXSW_SP_FLOOD_TYPE_MC] = mlxsw_sp_sfgc_mc_packet_types,
};
+bool mlxsw_sp_fid_lag_vid_valid(const struct mlxsw_sp_fid *fid)
+{
+ return fid->fid_family->lag_vid_valid;
+}
+
struct mlxsw_sp_fid *mlxsw_sp_fid_lookup_by_index(struct mlxsw_sp *mlxsw_sp,
u16 fid_index)
{
@@ -792,6 +798,7 @@ static const struct mlxsw_sp_fid_family mlxsw_sp_fid_8021d_family = {
.nr_flood_tables = ARRAY_SIZE(mlxsw_sp_fid_8021d_flood_tables),
.rif_type = MLXSW_SP_RIF_TYPE_FID,
.ops = &mlxsw_sp_fid_8021d_ops,
+ .lag_vid_valid = 1,
};
static int mlxsw_sp_fid_rfid_configure(struct mlxsw_sp_fid *fid)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 73e5db176d7e..3c2428404b2e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -2482,7 +2482,8 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct mlxsw_sp *mlxsw_sp,
bridge_device = bridge_port->bridge_device;
vid = bridge_device->vlan_enabled ? mlxsw_sp_port_vlan->vid : 0;
- lag_vid = mlxsw_sp_port_vlan->vid;
+ lag_vid = mlxsw_sp_fid_lag_vid_valid(mlxsw_sp_port_vlan->fid) ?
+ mlxsw_sp_port_vlan->vid : 0;
do_fdb_op:
err = mlxsw_sp_port_fdb_uc_lag_op(mlxsw_sp, lag_id, mac, fid, lag_vid,
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 2/5] mlxsw: spectrum_fid: Make flood index calculation more robust
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20181125094210.17298-1-idosch@mellanox.com>
802.1D FIDs use a per-FID flood table, where the flood index into the
table is calculated by subtracting 4K from the FID's index.
Currently, 802.1D FIDs start at 4K, so the calculation is correct, but
if it was ever to change, the calculation will no longer be correct.
In addition, this change will allow us to reuse the flood index
calculation function in the next patch, where we are going to emulate
802.1Q FIDs using 802.1D FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
index 5008bf63d73b..e1739cda25cb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
@@ -607,7 +607,7 @@ mlxsw_sp_fid_8021d_compare(const struct mlxsw_sp_fid *fid, const void *arg)
static u16 mlxsw_sp_fid_8021d_flood_index(const struct mlxsw_sp_fid *fid)
{
- return fid->fid_index - fid->fid_family->start_index;
+ return fid->fid_index - VLAN_N_VID;
}
static int mlxsw_sp_port_vp_mode_trans(struct mlxsw_sp_port *mlxsw_sp_port)
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 3/5] mlxsw: spectrum_fid: Introduce emulated 802.1Q FIDs
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20181125094210.17298-1-idosch@mellanox.com>
The driver uses 802.1Q FIDs when offloading a VLAN-aware bridge.
Unfortunately, it is not possible to assign a VNI to such FIDs, which
prompts the driver to forbid the enslavement of VxLAN devices to a
VLAN-aware bridge.
Workaround this hardware limitation by creating a new family of FIDs,
emulated 802.1Q FIDs. These FIDs are emulated using 802.1D FIDs, which
can be assigned a VNI.
The downside of this approach is that multiple {Port, VID}->FID entries
are required, whereas only a single VID->FID is required with "true"
802.1Q FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_fid.c | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
index e1739cda25cb..99ccb11405a5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
@@ -801,6 +801,39 @@ static const struct mlxsw_sp_fid_family mlxsw_sp_fid_8021d_family = {
.lag_vid_valid = 1,
};
+static const struct mlxsw_sp_fid_ops mlxsw_sp_fid_8021q_emu_ops = {
+ .setup = mlxsw_sp_fid_8021q_setup,
+ .configure = mlxsw_sp_fid_8021d_configure,
+ .deconfigure = mlxsw_sp_fid_8021d_deconfigure,
+ .index_alloc = mlxsw_sp_fid_8021d_index_alloc,
+ .compare = mlxsw_sp_fid_8021q_compare,
+ .flood_index = mlxsw_sp_fid_8021d_flood_index,
+ .port_vid_map = mlxsw_sp_fid_8021d_port_vid_map,
+ .port_vid_unmap = mlxsw_sp_fid_8021d_port_vid_unmap,
+ .vni_set = mlxsw_sp_fid_8021d_vni_set,
+ .vni_clear = mlxsw_sp_fid_8021d_vni_clear,
+ .nve_flood_index_set = mlxsw_sp_fid_8021d_nve_flood_index_set,
+ .nve_flood_index_clear = mlxsw_sp_fid_8021d_nve_flood_index_clear,
+};
+
+/* There are 4K-2 emulated 802.1Q FIDs, starting right after the 802.1D FIDs */
+#define MLXSW_SP_FID_8021Q_EMU_START (VLAN_N_VID + MLXSW_SP_FID_8021D_MAX)
+#define MLXSW_SP_FID_8021Q_EMU_END (MLXSW_SP_FID_8021Q_EMU_START + \
+ VLAN_VID_MASK - 2)
+
+/* Range and flood configuration must match mlxsw_config_profile */
+static const struct mlxsw_sp_fid_family mlxsw_sp_fid_8021q_emu_family = {
+ .type = MLXSW_SP_FID_TYPE_8021Q,
+ .fid_size = sizeof(struct mlxsw_sp_fid_8021q),
+ .start_index = MLXSW_SP_FID_8021Q_EMU_START,
+ .end_index = MLXSW_SP_FID_8021Q_EMU_END,
+ .flood_tables = mlxsw_sp_fid_8021d_flood_tables,
+ .nr_flood_tables = ARRAY_SIZE(mlxsw_sp_fid_8021d_flood_tables),
+ .rif_type = MLXSW_SP_RIF_TYPE_VLAN,
+ .ops = &mlxsw_sp_fid_8021q_emu_ops,
+ .lag_vid_valid = 1,
+};
+
static int mlxsw_sp_fid_rfid_configure(struct mlxsw_sp_fid *fid)
{
/* rFIDs are allocated by the device during init */
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 4/5] mlxsw: spectrum_router: Introduce emulated VLAN RIFs
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20181125094210.17298-1-idosch@mellanox.com>
Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of
"VLAN" type, whereas RIFs constructed on top of VLAN-unaware bridges of
"FID" type.
In other words, the RIF type is derived from the underlying FID type.
VLAN RIFs are used on top of 802.1Q FIDs, whereas FID RIFs are used on
top of 802.1D FIDs.
Since the previous patch emulated 802.1Q FIDs using 802.1D FIDs, this
patch emulates VLAN RIFs using FID RIFs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 9e9bb57134f2..5cdd4ceee7a9 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -7296,6 +7296,15 @@ static const struct mlxsw_sp_rif_ops mlxsw_sp_rif_fid_ops = {
.fdb_del = mlxsw_sp_rif_fid_fdb_del,
};
+static const struct mlxsw_sp_rif_ops mlxsw_sp_rif_vlan_emu_ops = {
+ .type = MLXSW_SP_RIF_TYPE_VLAN,
+ .rif_size = sizeof(struct mlxsw_sp_rif),
+ .configure = mlxsw_sp_rif_fid_configure,
+ .deconfigure = mlxsw_sp_rif_fid_deconfigure,
+ .fid_get = mlxsw_sp_rif_vlan_fid_get,
+ .fdb_del = mlxsw_sp_rif_vlan_fdb_del,
+};
+
static struct mlxsw_sp_rif_ipip_lb *
mlxsw_sp_rif_ipip_lb_rif(struct mlxsw_sp_rif *rif)
{
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 5/5] mlxsw: spectrum: Flip driver to use emulated 802.1Q FIDs
From: Ido Schimmel @ 2018-11-25 9:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20181125094210.17298-1-idosch@mellanox.com>
Replace 802.1Q FIDs and VLAN RIFs with their emulated counterparts.
The emulated 802.1Q FIDs are actually 802.1D FIDs and thus use the same
flood tables, of per-FID type. Therefore, add 4K-1 entries to the
per-FID flood tables for the new FIDs and get rid of the FID-offset
flood tables that were used by the old 802.1Q FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 14 ++++++++------
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 2 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 637e2ef76abe..93378d507962 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4111,16 +4111,20 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_kvdl_fini(mlxsw_sp);
}
+/* Per-FID flood tables are used for both "true" 802.1D FIDs and emulated
+ * 802.1Q FIDs
+ */
+#define MLXSW_SP_FID_FLOOD_TABLE_SIZE (MLXSW_SP_FID_8021D_MAX + \
+ VLAN_VID_MASK - 1)
+
static const struct mlxsw_config_profile mlxsw_sp1_config_profile = {
.used_max_mid = 1,
.max_mid = MLXSW_SP_MID_MAX,
.used_flood_tables = 1,
.used_flood_mode = 1,
.flood_mode = 3,
- .max_fid_offset_flood_tables = 3,
- .fid_offset_flood_table_size = VLAN_N_VID - 1,
.max_fid_flood_tables = 3,
- .fid_flood_table_size = MLXSW_SP_FID_8021D_MAX,
+ .fid_flood_table_size = MLXSW_SP_FID_FLOOD_TABLE_SIZE,
.used_max_ib_mc = 1,
.max_ib_mc = 0,
.used_max_pkey = 1,
@@ -4143,10 +4147,8 @@ static const struct mlxsw_config_profile mlxsw_sp2_config_profile = {
.used_flood_tables = 1,
.used_flood_mode = 1,
.flood_mode = 3,
- .max_fid_offset_flood_tables = 3,
- .fid_offset_flood_table_size = VLAN_N_VID - 1,
.max_fid_flood_tables = 3,
- .fid_flood_table_size = MLXSW_SP_FID_8021D_MAX,
+ .fid_flood_table_size = MLXSW_SP_FID_FLOOD_TABLE_SIZE,
.used_max_ib_mc = 1,
.max_ib_mc = 0,
.used_max_pkey = 1,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
index 99ccb11405a5..6830e79aed93 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
@@ -961,7 +961,7 @@ static const struct mlxsw_sp_fid_family mlxsw_sp_fid_dummy_family = {
};
static const struct mlxsw_sp_fid_family *mlxsw_sp_fid_family_arr[] = {
- [MLXSW_SP_FID_TYPE_8021Q] = &mlxsw_sp_fid_8021q_family,
+ [MLXSW_SP_FID_TYPE_8021Q] = &mlxsw_sp_fid_8021q_emu_family,
[MLXSW_SP_FID_TYPE_8021D] = &mlxsw_sp_fid_8021d_family,
[MLXSW_SP_FID_TYPE_RFID] = &mlxsw_sp_fid_rfid_family,
[MLXSW_SP_FID_TYPE_DUMMY] = &mlxsw_sp_fid_dummy_family,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 5cdd4ceee7a9..1557c5fc6d10 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -7373,7 +7373,7 @@ static const struct mlxsw_sp_rif_ops mlxsw_sp_rif_ipip_lb_ops = {
static const struct mlxsw_sp_rif_ops *mlxsw_sp_rif_ops_arr[] = {
[MLXSW_SP_RIF_TYPE_SUBPORT] = &mlxsw_sp_rif_subport_ops,
- [MLXSW_SP_RIF_TYPE_VLAN] = &mlxsw_sp_rif_vlan_ops,
+ [MLXSW_SP_RIF_TYPE_VLAN] = &mlxsw_sp_rif_vlan_emu_ops,
[MLXSW_SP_RIF_TYPE_FID] = &mlxsw_sp_rif_fid_ops,
[MLXSW_SP_RIF_TYPE_IPIP_LB] = &mlxsw_sp_rif_ipip_lb_ops,
};
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 6/8] socket: Add struct sock_timeval
From: Arnd Bergmann @ 2018-11-25 20:50 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Willem de Bruijn, David Miller, Linux Kernel Mailing List,
Networking, Al Viro, y2038 Mailman List
In-Reply-To: <CABeXuvrV+xN3O8BSmJ7bGR+8uYmtrCk2YL37HQZrBSO8YSvzJQ@mail.gmail.com>
On Sun, Nov 25, 2018 at 5:52 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Sat, Nov 24, 2018 at 11:38 AM Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> > On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > >
> > > The new type is meant to be used as a y2038 safe structure
> > > to be used as part of cmsg data.
> > > Presently the SO_TIMESTAMP socket option uses struct timeval
> > > for timestamps. This is not y2038 safe.
> > > Subsequent patches in the series add new y2038 safe socket
> > > option to be used in the place of SO_TIMESTAMP_OLD.
> > > struct sock_timeval will be used as the timestamp format
> > > at that time.
> > >
> > > struct sock_timeval also maintains the same layout across
> > > 32 bit and 64 bit ABIs.
> > >
> > > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > > ---
> > > include/uapi/linux/time.h | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
> > > index 04d5587f30d3..106f9398c285 100644
> > > --- a/include/uapi/linux/time.h
> > > +++ b/include/uapi/linux/time.h
> > > @@ -70,6 +70,11 @@ struct __kernel_old_timeval {
> > > };
> > > #endif
> > >
> > > +struct sock_timeval {
> > > + long long tv_sec;
> > > + long long tv_usec;
> >
> > should these use fixed-width type __u64?
>
> We have avoided using __u64/__s64 types for time types in uapi.
> I think we did this for portability reasons.
> Although this new type might not be required to be interpreted in
> libc, I would prefer for this to be long long.
> If there is a strong preference then I can change it.
I think we want signed types to keep it closer to what we
have today with 'timeval'. as long as linux/types.h is included
first (it is).
Between __s64 or long long, I don't think it makes a difference,
so let's just go with Willem's suggestion. We already rely on
'long long' being exactly 64 bit wide in 'struct __kernel_timespec'
as well.
We could however debate whether 'sock_timeval' should
be visible to user space in linux/tme.h like this, or if it
should be put in a namespace like '__kernel_sock_timeval'
to ensure it won't conflict with user space headers defining
a type of the same name.
Arnd
^ permalink raw reply
* [PATCH 03/13] net: stmmac: dwmac-rk: Allow the driver to probe when phy-supply is not present
From: Otavio Salvador @ 2018-11-25 21:18 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-rockchip
Cc: Otavio Salvador, Jose Abreu, Giuseppe Cavallaro, netdev,
Alexandre Torgue, Maxime Coquelin, linux-stm32, David S. Miller
In-Reply-To: <20181125211907.9895-1-otavio@ossystems.com.br>
The phy-supply is an optional regulator, so we should not treat
as an error when phy-supply is not passed in the device tree.
This allows the dwmac-rk driver to probe when phy-supply is not
present in the dts.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 7b923362ee55..73855622445b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1205,7 +1205,7 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
if (!ldo) {
dev_err(dev, "no regulator found\n");
- return -1;
+ return 0;
}
if (enable) {
--
2.19.1
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8192de: fix spelling mistake "althougth" -> "although"
From: Colin King @ 2018-11-25 22:10 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a RT_TRACE message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
index de98d88199d6..dcb5d839bbfd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
@@ -812,7 +812,7 @@ bool rtl92d_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
* pathA or mac1 has to set phy0&phy1 pathA */
if ((content == radiob_txt) && (rfpath == RF90_PATH_A)) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
- " ===> althougth Path A, we load radiob.txt\n");
+ " ===> although Path A, we load radiob.txt\n");
radioa_arraylen = radiob_arraylen;
radioa_array_table = radiob_array_table;
}
--
2.19.1
^ permalink raw reply related
* Re: Can decnet be deprecated?
From: Bjørn Mork @ 2018-11-25 11:30 UTC (permalink / raw)
To: David Miller; +Cc: dsahern, netdev
In-Reply-To: <20181124.172509.1739636063027441678.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: David Ahern <dsahern@gmail.com>
> Date: Sat, 24 Nov 2018 17:12:48 -0700
>
>> IPX was moved to staging at the end of last year. Can decnet follow
>> suit? git log seems to indicate no active development in a very long time.
>
> Last time I tried to do that someone immediately said on the list
> "Don't, we're using that!"
Not sure about that. What I can see is a claim that it has no bugs:
http://patchwork.ozlabs.org/patch/837484/
The V1 received only support for removal:
http://patchwork.ozlabs.org/patch/837261/
But no one claimed they were using decnet.
Bjørn
^ permalink raw reply
* Re: Can decnet be deprecated?
From: Loganaden Velvindron @ 2018-11-25 11:38 UTC (permalink / raw)
To: dsahern; +Cc: netdev, David Miller
In-Reply-To: <2c63cb14-ddba-dda3-4ef6-79b31101f162@gmail.com>
On Sun, Nov 25, 2018 at 4:14 AM David Ahern <dsahern@gmail.com> wrote:
>
> IPX was moved to staging at the end of last year. Can decnet follow
> suit? git log seems to indicate no active development in a very long time.
>
> David
Kill it :)
^ permalink raw reply
* Re: WARNING: bad usercopy in corrupted (2)
From: Matthew Wilcox @ 2018-11-25 23:07 UTC (permalink / raw)
To: syzbot; +Cc: crecklin, keescook, linux-kernel, linux-mm, syzkaller-bugs,
netdev
In-Reply-To: <20181125212708.GD3065@bombadil.infradead.org>
On Sun, Nov 25, 2018 at 01:27:09PM -0800, Matthew Wilcox wrote:
> On Sun, Nov 25, 2018 at 07:30:04AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: aea0a897af9e ptp: Fix pass zero to ERR_PTR() in ptp_clock_..
> > git tree: net-next
>
> If you found it on net-next, I'd suggets cc'ing linux-net ...
Uh. I meant netdev. Oops.
> > console output: https://syzkaller.appspot.com/x/log.txt?x=101b91d5400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c36a72af2123e78a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=d89b30c46434c433dbf8
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170f6a47400000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e1df7b400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+d89b30c46434c433dbf8@syzkaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > DEBUG_LOCKS_WARN_ON(!hlock->nest_lock)
> > ------------[ cut here ]------------
> > Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected
> > to SLAB object 'task_struct' (offset 1432, size 2)!
> > WARNING: CPU: 1 PID: 38 at mm/usercopy.c:83 usercopy_warn+0xee/0x110
> > mm/usercopy.c:78
> > Kernel panic - not syncing: panic_on_warn set ...
> > list_add corruption. next->prev should be prev (ffff8881daf2d798), but was
> > 0b7e0c8e49cc0400. (next=ffff8881d9b4a4f0).
> > CPU: 1 PID: 38 Comm: ���ف���d\v������ Not tainted 4.20.0-rc3+ #312
> > ------------[ cut here ]------------
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > kernel BUG at lib/list_debug.c:25!
> > ------------[ cut here ]------------
> > invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> > kernel BUG at mm/slab.c:4425!
> > CPU: 0 PID: 8652 Comm: syz-executor607 Not tainted 4.20.0-rc3+ #312
> > WARNING: CPU: 1 PID: 38 at kernel/rcu/tree_plugin.h:438
> > __rcu_read_unlock+0x266/0x2e0 kernel/rcu/tree_plugin.h:432
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Modules linked in:
> > RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23
> > CPU: 1 PID: 38 Comm: ���ف���d\v������ Not tainted 4.20.0-rc3+ #312
> > Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37
> > d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48
> > c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RSP: 0000:ffff8881dae07588 EFLAGS: 00010082
> > usercopy: Kernel memory overwrite attempt detected to SLAB object
> > 'signal_cache' (offset 1328, size 23)!
> > RAX: 0000000000000075 RBX: ffff8881d9b4a4f0 RCX: 0000000000000000
> > ------------[ cut here ]------------
> > RDX: 0000000000000000 RSI: ffffffff8165eaf5 RDI: 0000000000000005
> > kernel BUG at mm/usercopy.c:102!
> > RBP: ffff8881dae075a0 R08: ffff8881d25ce100 R09: ffffed103b5c5020
> > R10: ffffed103b5c5020 R11: ffff8881dae28107 R12: ffff8881bd890230
> > R13: dffffc0000000000 R14: ffff8881dae07980 R15: ffff8881daf2d798
> > FS: 000000000083c880(0000) GS:ffff8881dae00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fff14476600 CR3: 00000001d2a59000 CR4: 00000000001406f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <IRQ>
> > __list_add include/linux/list.h:60 [inline]
> > list_add include/linux/list.h:79 [inline]
> > list_move include/linux/list.h:171 [inline]
> > detach_tasks kernel/sched/fair.c:7298 [inline]
> > load_balance+0x1b8d/0x39a0 kernel/sched/fair.c:8731
> > rebalance_domains+0x845/0xdc0 kernel/sched/fair.c:9109
> > run_rebalance_domains+0x38d/0x500 kernel/sched/fair.c:9731
> > __do_softirq+0x308/0xb7e kernel/softirq.c:292
> > invoke_softirq kernel/softirq.c:373 [inline]
> > irq_exit+0x17f/0x1c0 kernel/softirq.c:413
> > exiting_irq arch/x86/include/asm/apic.h:536 [inline]
> > smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061
> > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804
> > </IRQ>
> > RIP: 0033:0x4005dd
> > Code: c9 00 04 00 66 0f 1f 84 00 00 00 00 00 48 8b 05 f1 2e 2d 00 48 85 c0
> > 74 11 bf 3c e8 4b 00 b9 0e 00 00 00 48 89 c6 f3 a6 75 01 <c3> 48 89 c7 e9 9a
> > ec 01 00 66 2e 0f 1f 84 00 00 00 00 00 8b 05 4a
> > RSP: 002b:00007fff144765a8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
> > RAX: 0000000000000000 RBX: 0000000000000002 RCX: 00000000006d2190
> > RDX: 0000000000402410 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 00000000006cc0a8 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> > R13: 00000000006d2180 R14: 0000000000000000 R15: 0000000000000000
> > Modules linked in:
> > ---[ end trace eeb5734c13709e17 ]---
> > invalid opcode: 0000 [#2] PREEMPT SMP KASAN
> > CPU: 1 PID: 38 Comm: ���ف���d\v������ Tainted: G D 4.20.0-rc3+
> > #312
> > RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37
> > d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48
> > c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b
> > RIP: 0010:usercopy_abort+0xbb/0xbd mm/usercopy.c:90
> > RSP: 0000:ffff8881dae07588 EFLAGS: 00010082
> > Code: c0 e8 f7 dc b1 ff 48 8b 55 c0 49 89 d9 4d 89 f0 ff 75 c8 4c 89 e1 4c
> > 89 ee 48 c7 c7 80 d5 34 88 ff 75 d0 41 57 e8 e7 28 98 ff <0f> 0b e8 cc dc b1
> > ff e8 97 13 f5 ff 8b 95 e4 fe ff ff 4c 89 e1 31
> > RAX: 0000000000000075 RBX: ffff8881d9b4a4f0 RCX: 0000000000000000
> > RSP: 0018:ffff8881d9b49438 EFLAGS: 00010086
> > RDX: 0000000000000000 RSI: ffffffff8165eaf5 RDI: 0000000000000005
> > RAX: 0000000000000068 RBX: ffffffff88291020 RCX: 0000000000000000
> > RBP: ffff8881dae075a0 R08: ffff8881d25ce100 R09: ffffed103b5c5020
> > RDX: 0000000000000000 RSI: ffffffff8165eaf5 RDI: 0000000000000005
> > R10: ffffed103b5c5020 R11: ffff8881dae28107 R12: ffff8881bd890230
> > RBP: ffff8881d9b49490 R08: ffff8881d9b4a440 R09: ffffed103b5e3ef8
> > R13: dffffc0000000000 R14: ffff8881dae07980 R15: ffff8881daf2d798
> > R10: ffffed103b5e3ef8 R11: ffff8881daf1f7c7 R12: ffffffff8914da1d
> > FS: 000000000083c880(0000) GS:ffff8881dae00000(0000) knlGS:0000000000000000
> > R13: ffffffff8834d3e0 R14: ffffffff8834d320 R15: ffffffff8834d2e0
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > FS: 0000000000000000(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
> > CR2: 00007fff14476600 CR3: 00000001d2a59000 CR4: 00000000001406f0
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > CR2: 0000000000000130 CR3: 00000001d7880000 CR4: 00000000001406e0
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > Modules linked in:
> > ---[ end trace eeb5734c13709e18 ]---
> > RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23
> > Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37
> > d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48
> > c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b
> > RSP: 0000:ffff8881dae07588 EFLAGS: 00010082
> > RAX: 0000000000000075 RBX: ffff8881d9b4a4f0 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: ffffffff8165eaf5 RDI: 0000000000000005
> > RBP: ffff8881dae075a0 R08: ffff8881d25ce100 R09: ffffed103b5c5020
> > R10: ffffed103b5c5020 R11: ffff8881dae28107 R12: ffff8881bd890230
> > R13: dffffc0000000000 R14: ffff8881dae07980 R15: ffff8881daf2d798
> > FS: 0000000000000000(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000000130 CR3: 00000001d7880000 CR4: 00000000001406e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
>
^ permalink raw reply
* [PATCH] firestream: fix spelling mistake: "Inititing" -> "Initializing"
From: Colin King @ 2018-11-25 23:21 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are spelling mistakes in debug messages, fix them.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/atm/firestream.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index 4e46dc9e41ad..11e1663bdc4d 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -1410,7 +1410,7 @@ static int init_q(struct fs_dev *dev, struct queue *txq, int queue,
func_enter ();
- fs_dprintk (FS_DEBUG_INIT, "Inititing queue at %x: %d entries:\n",
+ fs_dprintk (FS_DEBUG_INIT, "Initializing queue at %x: %d entries:\n",
queue, nentries);
p = aligned_kmalloc (sz, GFP_KERNEL, 0x10);
@@ -1443,7 +1443,7 @@ static int init_fp(struct fs_dev *dev, struct freepool *fp, int queue,
{
func_enter ();
- fs_dprintk (FS_DEBUG_INIT, "Inititing free pool at %x:\n", queue);
+ fs_dprintk (FS_DEBUG_INIT, "Initializing free pool at %x:\n", queue);
write_fs (dev, FP_CNF(queue), (bufsize * RBFP_RBS) | RBFP_RBSVAL | RBFP_CME);
write_fs (dev, FP_SA(queue), 0);
--
2.19.1
^ permalink raw reply related
* [PATCH] net: ethernet: ti: cpsw: allow to configure min tx packet size
From: Grygorii Strashko @ 2018-11-25 23:43 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: Sekhar Nori, linux-kernel, linux-omap, Grygorii Strashko
For proper VLAN packets forwarding CPSW driver uses min tx packet size of
64bytes (VLAN_ETH_ZLEN, excluding ETH_FCS) which was corrected by
commit 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size").
Unfortunately, this breaks some industrial automation protocols, as
reported by TI customers [1], which can work only with min TX packet size
from 60 byte (ecluding FCS).
Hence, introduce module boot parameter "tx_packet_min" to allow configure
min TX packet size at boot time.
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
Fixes: 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index ceaec56..15d563c 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -188,6 +188,10 @@ static int rx_packet_max = CPSW_MAX_PACKET_SIZE;
module_param(rx_packet_max, int, 0);
MODULE_PARM_DESC(rx_packet_max, "maximum receive packet size (bytes)");
+static int tx_packet_min = CPSW_MIN_PACKET_SIZE;
+module_param(tx_packet_min, int, 0444);
+MODULE_PARM_DESC(tx_packet_min, "minimum tx packet size (bytes)");
+
static int descs_pool_size = CPSW_CPDMA_DESCS_POOL_SIZE_DEFAULT;
module_param(descs_pool_size, int, 0444);
MODULE_PARM_DESC(descs_pool_size, "Number of CPDMA CPPI descriptors in pool");
@@ -2131,7 +2135,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff *skb,
struct cpdma_chan *txch;
int ret, q_idx;
- if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
+ if (skb_padto(skb, tx_packet_min)) {
cpsw_err(priv, tx_err, "packet pad failed\n");
ndev->stats.tx_dropped++;
return NET_XMIT_DROP;
@@ -3636,7 +3640,7 @@ static int cpsw_probe(struct platform_device *pdev)
dma_params.num_chan = data->channels;
dma_params.has_soft_reset = true;
- dma_params.min_packet_size = CPSW_MIN_PACKET_SIZE;
+ dma_params.min_packet_size = tx_packet_min;
dma_params.desc_mem_size = data->bd_ram_size;
dma_params.desc_align = 16;
dma_params.has_ext_regs = true;
--
2.10.5
^ 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