* Re: [PATCH iproute2-next] ip-xfrm: Add support for OUTPUT_MARK
From: Lorenzo Colitti @ 2018-06-12 2:33 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: netdev, Stephen Hemminger, David Ahern, Steffen Klassert
In-Reply-To: <1528769493-25435-1-git-send-email-subashab@codeaurora.org>
On Tue, Jun 12, 2018 at 11:12 AM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> This patch adds support for OUTPUT_MARK in xfrm state to exercise the
> functionality added by kernel commit 077fbac405bf
> ("net: xfrm: support setting an output mark.").
>
> Sample output with output-mark -
>
> src 192.168.1.1 dst 192.168.1.2
> proto esp spi 0x00004321 reqid 0 mode tunnel
> replay-window 0 flag af-unspec
> auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
> enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
> output-mark 0x20000
Have you considered putting this earlier up in the output, where the
mark is printed as well?
> + if (tb[XFRMA_OUTPUT_MARK]) {
> + __u32 output_mark = rta_getattr_u32(tb[XFRMA_OUTPUT_MARK]);
> +
> + fprintf(fp, "\toutput-mark 0x%x %s", output_mark, _SL_);
> + }
> }
If you wanted to implement the suggestion above, I think you could do
that by moving this code into xfrm_xfrma_print.
Other than that, LGTM.
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Steffen - what's the status of the set_mark patches? Are you holding
them until the tree opens again? If so, then once they go in, we can
just make "set-mark" behave the same as "output-mark" in the iproute2
code, and add support for the mask as well.
^ permalink raw reply
* Re: [PATCH bpf v2] tools/bpftool: fix a bug in bpftool perf
From: Jakub Kicinski @ 2018-06-12 2:42 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180612020108.125247-1-yhs@fb.com>
On Mon, 11 Jun 2018 19:01:08 -0700, Yonghong Song wrote:
> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
> introduced bpftool subcommand perf to query bpf program
> kuprobe and tracepoint attachments.
>
> The perf subcommand will first test whether bpf subcommand
> BPF_TASK_FD_QUERY is supported in kernel or not. It does it
> by opening a file with argv[0] and feeds the file descriptor
> and current task pid to the kernel for querying.
>
> Such an approach won't work if the argv[0] cannot be opened
> successfully in the current directory. This is especially
> true when bpftool is accessible through PATH env variable.
> The error below reflects the open failure for file argv[0]
> at home directory.
>
> [yhs@localhost ~]$ which bpftool
> /usr/local/sbin/bpftool
> [yhs@localhost ~]$ bpftool perf
> Error: perf_query_support: No such file or directory
>
> To fix the issue, let us open root directory ("/")
> which exists in every linux system. With the fix, the
> error message will correctly reflect the permission issue.
>
> [yhs@localhost ~]$ which bpftool
> /usr/local/sbin/bpftool
> [yhs@localhost ~]$ bpftool perf
> Error: perf_query_support: Operation not permitted
> HINT: non root or kernel doesn't support TASK_FD_QUERY
>
> Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
> Reported-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> tools/bpf/bpftool/perf.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> Changelogs:
> v1 -> v2:
> . remove '\n' in the p_err format string in order to
> have valid json output.
>
> diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
> index ac6b1a12c9b7..239715aa6fb9 100644
> --- a/tools/bpf/bpftool/perf.c
> +++ b/tools/bpf/bpftool/perf.c
> @@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
> if (perf_query_supported)
> goto out;
>
> - fd = open(bin_name, O_RDONLY);
> - if (fd < 0) {
> - p_err("perf_query_support: %s", strerror(errno));
> + fd = open("/", O_RDONLY);
> + if (fd > 0) {
Looking at this again, why change the comparison from less than to
greater than 0?
> + p_err("perf_query_support: cannot open directory \"/\" (%s)",
> + strerror(errno));
> goto out;
> }
>
^ permalink raw reply
* [PATCH RFC v2] rhashtable: implement rhashtable_walk_peek() using rhashtable_walk_last_seen()
From: NeilBrown @ 2018-06-12 2:48 UTC (permalink / raw)
To: Tom Herbert
Cc: Herbert Xu, Thomas Graf, Linux Kernel Network Developers, LKML,
Tom Herbert
In-Reply-To: <CALx6S35GgUOd0dPgv7P96wNNTv5pN7fij0pcAoccqcSWZhvY7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4058 bytes --]
rhashtable_walk_last_seen() does most of the work that
rhashtable_walk_peek() needs done, so use it and put
it in a "static inline".
Also update the documentation for rhashtable_walk_peek() to clarify
the expected use case.
Signed-off-by: NeilBrown <neilb@suse.com>
---
v2 as static-inline - suggested by Tom.
Thanks,
NeilBrown
include/linux/rhashtable.h | 29 ++++++++++++++++++++++++++++-
lib/rhashtable.c | 34 ----------------------------------
2 files changed, 28 insertions(+), 35 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index d63b472e9d50..96ebc2690027 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -247,10 +247,37 @@ static inline void rhashtable_walk_start(struct rhashtable_iter *iter)
}
void *rhashtable_walk_next(struct rhashtable_iter *iter);
-void *rhashtable_walk_peek(struct rhashtable_iter *iter);
void *rhashtable_walk_last_seen(struct rhashtable_iter *iter);
void rhashtable_walk_stop(struct rhashtable_iter *iter) __releases(RCU);
+/**
+ * rhashtable_walk_peek - Return the next object to use in an interrupted walk
+ * @iter: Hash table iterator
+ *
+ * Returns the "current" object or NULL when the end of the table is reached.
+ * When an rhashtable_walk is interrupted with rhashtable_walk_stop(),
+ * it is often because an object was found that could not be processed
+ * immediately, possible because there is no more space to encode details
+ * of the object (e.g. when producing a seq_file from the table).
+ * When the walk is restarted, the same object needs to be processed again,
+ * if possible. The object might have been removed from the table while
+ * the walk was paused, so it might not be available. In that case, the
+ * normal "next" object should be treated as "current".
+ *
+ * To support this common case, rhashtable_walk_peek() returns the
+ * appropriate object to process after an interrupted walk, either the
+ * one that was most recently returned, or if that doesn't exist - the
+ * next one.
+ *
+ * Returns -EAGAIN if resize event occurred. In that case the iterator
+ * will rewind back to the beginning and you may continue to use it.
+ */
+static inline void *rhashtable_walk_peek(struct rhashtable_iter *iter)
+{
+ return rhashtable_walk_last_seen(iter) ?:
+ rhashtable_walk_next(iter);
+}
+
void rhashtable_free_and_destroy(struct rhashtable *ht,
void (*free_fn)(void *ptr, void *arg),
void *arg);
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 45f2554399a5..354275037df3 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -915,40 +915,6 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter)
}
EXPORT_SYMBOL_GPL(rhashtable_walk_next);
-/**
- * rhashtable_walk_peek - Return the next object but don't advance the iterator
- * @iter: Hash table iterator
- *
- * Returns the next object or NULL when the end of the table is reached.
- *
- * Returns -EAGAIN if resize event occurred. Note that the iterator
- * will rewind back to the beginning and you may continue to use it.
- */
-void *rhashtable_walk_peek(struct rhashtable_iter *iter)
-{
- struct rhlist_head *list = iter->list;
- struct rhashtable *ht = iter->ht;
- struct rhash_head *p = iter->p;
-
- if (p)
- return rht_obj(ht, ht->rhlist ? &list->rhead : p);
-
- /* No object found in current iter, find next one in the table. */
-
- if (iter->skip) {
- /* A nonzero skip value points to the next entry in the table
- * beyond that last one that was found. Decrement skip so
- * we find the current value. __rhashtable_walk_find_next
- * will restore the original value of skip assuming that
- * the table hasn't changed.
- */
- iter->skip--;
- }
-
- return __rhashtable_walk_find_next(iter);
-}
-EXPORT_SYMBOL_GPL(rhashtable_walk_peek);
-
/**
* rhashtable_walk_last_seen - Return the previously returned object, if available
* @iter: Hash table iterator
--
2.14.0.rc0.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related
* Re: [PATCH RFC] tcp: Do not reload skb pointer after skb_gro_receive().
From: Eric Dumazet @ 2018-06-12 2:59 UTC (permalink / raw)
To: David Miller, netdev; +Cc: edumazet
In-Reply-To: <20180611.180013.526861738690091217.davem@davemloft.net>
On 06/11/2018 06:00 PM, David Miller wrote:
>
> This is not necessary. skb_gro_receive() will never change what
> 'head' points to.
>
> In it's original implementation (see commit 71d93b39e52e ("net: Add
> skb_gro_receive")), it did:
>
> ====================
> + *head = nskb;
> + nskb->next = p->next;
> + p->next = NULL;
> ====================
>
> This sequence was removed in commit 58025e46ea2d ("net: gro: remove
> obsolete code from skb_gro_receive()")
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
SGTM, thanks David !
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH 1/2] Convert target drivers to use sbitmap
From: Matthew Wilcox @ 2018-06-12 3:06 UTC (permalink / raw)
To: Jens Axboe
Cc: Juergen Gross, kvm, linux-scsi, Matthew Wilcox, netdev, linux-usb,
linux-kernel, virtualization, target-devel, qla2xxx-upstream,
linux1394-devel, Kent Overstreet
In-Reply-To: <02326395-3241-c94b-ad70-3de27a6f5a8c@kernel.dk>
On Mon, Jun 11, 2018 at 07:18:55PM -0600, Jens Axboe wrote:
> Are you going to push this further? I really think we should.
Yes, I'll resubmit it tomorrow. Sorry for dropping the ball on this one.
^ permalink raw reply
* Re: [PATCH iproute2-next] ip-xfrm: Add support for OUTPUT_MARK
From: Stephen Hemminger @ 2018-06-12 3:12 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: lorenzo, netdev, dsahern
In-Reply-To: <1528769493-25435-1-git-send-email-subashab@codeaurora.org>
On Mon, 11 Jun 2018 20:11:33 -0600
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> wrote:
> This patch adds support for OUTPUT_MARK in xfrm state to exercise the
> functionality added by kernel commit 077fbac405bf
> ("net: xfrm: support setting an output mark.").
>
> Sample output with output-mark -
>
> src 192.168.1.1 dst 192.168.1.2
> proto esp spi 0x00004321 reqid 0 mode tunnel
> replay-window 0 flag af-unspec
> auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
> enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
> output-mark 0x20000
>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
This reminds me. It is time to convert xfrm to json output.
^ permalink raw reply
* problems with SCTP GSO
From: David Miller @ 2018-06-12 3:29 UTC (permalink / raw)
To: marcelo.leitner; +Cc: lucien.xin, edumazet, netdev
I would like to bring up some problems with the current GSO
implementation in SCTP.
The most important for me right now is that SCTP uses
"skb_gro_receive()" to build "GSO" frames :-(
Really it just ends up using the slow path (basically, label 'merge'
and onwards).
So, using a GRO helper to build GSO packets is not great.
I want to make major surgery here and the only way I can is if
it is exactly the GRO demuxing path that uses skb_gro_receive().
Those paths pass in the list head from the NAPI struct that initiated
the GRO code paths. That makes it easy for me to change this to use a
list_head or a hash chain.
Probably in the short term SCTP should just have a private helper that
builds the frag list, appending 'skb' to 'head'.
In the long term, SCTP should use the page frags just like TCP to
append the data when building GSO frames. Then it could actually be
offloaded and passed into drivers without linearizing.
^ permalink raw reply
* Re: [PATCH bpf v2] tools/bpftool: fix a bug in bpftool perf
From: Yonghong Song @ 2018-06-12 3:45 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180611194257.5f72219b@cakuba.netronome.com>
On 6/11/18 7:42 PM, Jakub Kicinski wrote:
> On Mon, 11 Jun 2018 19:01:08 -0700, Yonghong Song wrote:
>> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
>> introduced bpftool subcommand perf to query bpf program
>> kuprobe and tracepoint attachments.
>>
>> The perf subcommand will first test whether bpf subcommand
>> BPF_TASK_FD_QUERY is supported in kernel or not. It does it
>> by opening a file with argv[0] and feeds the file descriptor
>> and current task pid to the kernel for querying.
>>
>> Such an approach won't work if the argv[0] cannot be opened
>> successfully in the current directory. This is especially
>> true when bpftool is accessible through PATH env variable.
>> The error below reflects the open failure for file argv[0]
>> at home directory.
>>
>> [yhs@localhost ~]$ which bpftool
>> /usr/local/sbin/bpftool
>> [yhs@localhost ~]$ bpftool perf
>> Error: perf_query_support: No such file or directory
>>
>> To fix the issue, let us open root directory ("/")
>> which exists in every linux system. With the fix, the
>> error message will correctly reflect the permission issue.
>>
>> [yhs@localhost ~]$ which bpftool
>> /usr/local/sbin/bpftool
>> [yhs@localhost ~]$ bpftool perf
>> Error: perf_query_support: Operation not permitted
>> HINT: non root or kernel doesn't support TASK_FD_QUERY
>>
>> Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
>> Reported-by: Alexei Starovoitov <ast@kernel.org>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> tools/bpf/bpftool/perf.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> Changelogs:
>> v1 -> v2:
>> . remove '\n' in the p_err format string in order to
>> have valid json output.
>>
>> diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
>> index ac6b1a12c9b7..239715aa6fb9 100644
>> --- a/tools/bpf/bpftool/perf.c
>> +++ b/tools/bpf/bpftool/perf.c
>> @@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
>> if (perf_query_supported)
>> goto out;
>>
>> - fd = open(bin_name, O_RDONLY);
>> - if (fd < 0) {
>> - p_err("perf_query_support: %s", strerror(errno));
>> + fd = open("/", O_RDONLY);
>> + if (fd > 0) {
>
> Looking at this again, why change the comparison from less than to
> greater than 0?
Totally my fault. I altered the condition to test p_err output since
I cannot trigger it normally, but forgot to change it back.
Will send yet another revision :-(
>> + p_err("perf_query_support: cannot open directory \"/\" (%s)",
>> + strerror(errno));
>> goto out;
>> }
>>
>
^ permalink raw reply
* [PATCH] net: add error handling for kmem_cache_create
From: Zhouyang Jia @ 2018-06-12 4:29 UTC (permalink / raw)
Cc: Zhouyang Jia, David S. Miller, Wei Wang, Martin KaFai Lau,
Kees Cook, Eric Dumazet, Florian Westphal, Joe Perches,
linux-decnet-user, netdev, linux-kernel
When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling kmem_cache_create.
Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
---
net/decnet/dn_route.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index e747650..2b743c7 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1861,6 +1861,9 @@ void __init dn_route_init(void)
dn_dst_ops.kmem_cachep =
kmem_cache_create("dn_dst_cache", sizeof(struct dn_route), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ if (!dn_dst_ops.kmem_cachep)
+ panic("Failed to create dn_dst_cache cache\n");
+
dst_entries_init(&dn_dst_ops);
timer_setup(&dn_route_timer, dn_dst_check_expire, 0);
dn_route_timer.expires = jiffies + decnet_dst_gc_interval * HZ;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: add error handling for kmem_cache_create
From: Eric Dumazet @ 2018-06-12 4:31 UTC (permalink / raw)
To: Zhouyang Jia
Cc: David S. Miller, Wei Wang, Martin KaFai Lau, Kees Cook,
Eric Dumazet, Florian Westphal, Joe Perches, linux-decnet-user,
netdev, linux-kernel
In-Reply-To: <1528777798-40722-1-git-send-email-jiazhouyang09@gmail.com>
On 06/11/2018 09:29 PM, Zhouyang Jia wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
>
> Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
> ---
> net/decnet/dn_route.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
> index e747650..2b743c7 100644
> --- a/net/decnet/dn_route.c
> +++ b/net/decnet/dn_route.c
> @@ -1861,6 +1861,9 @@ void __init dn_route_init(void)
> dn_dst_ops.kmem_cachep =
> kmem_cache_create("dn_dst_cache", sizeof(struct dn_route), 0,
> SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> + if (!dn_dst_ops.kmem_cachep)
> + panic("Failed to create dn_dst_cache cache\n");
> +
Not needed, since SLAB_PANIC would have paniced the box earlier.
> dst_entries_init(&dn_dst_ops);
> timer_setup(&dn_route_timer, dn_dst_check_expire, 0);
> dn_route_timer.expires = jiffies + decnet_dst_gc_interval * HZ;
>
^ permalink raw reply
* [PATCH net 1/4] nfp: don't pad strings in nfp_cpp_resource_find() to avoid gcc 8 warning
From: Jakub Kicinski @ 2018-06-12 4:33 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20180612043338.5447-1-jakub.kicinski@netronome.com>
Once upon a time nfp_cpp_resource_find() took a name parameter,
which could be any user-chosen string. Resources are identified
by a CRC32 hash of a 8 byte string, so we had to pad user input
with zeros to make sure CRC32 gave the correct result.
Since then nfp_cpp_resource_find() was made to operate on allocated
resources only (struct nfp_resource). We kzalloc those so there is
no need to pad the strings and use memcmp.
This avoids a GCC 8 stringop-truncation warning:
In function ‘nfp_cpp_resource_find’,
inlined from ‘nfp_resource_try_acquire’ at .../nfpcore/nfp_resource.c:153:8,
inlined from ‘nfp_resource_acquire’ at .../nfpcore/nfp_resource.c:206:9:
.../nfpcore/nfp_resource.c:108:2: warning: strncpy’ output may be truncated copying 8 bytes from a string of length 8 [-Wstringop-truncation]
strncpy(name_pad, res->name, sizeof(name_pad));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
index 2dd89dba9311..d32af598da90 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
@@ -98,21 +98,18 @@ struct nfp_resource {
static int nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res)
{
- char name_pad[NFP_RESOURCE_ENTRY_NAME_SZ] = {};
struct nfp_resource_entry entry;
u32 cpp_id, key;
int ret, i;
cpp_id = NFP_CPP_ID(NFP_RESOURCE_TBL_TARGET, 3, 0); /* Atomic read */
- strncpy(name_pad, res->name, sizeof(name_pad));
-
/* Search for a matching entry */
- if (!memcmp(name_pad, NFP_RESOURCE_TBL_NAME "\0\0\0\0\0\0\0\0", 8)) {
+ if (!strcmp(res->name, NFP_RESOURCE_TBL_NAME)) {
nfp_err(cpp, "Grabbing device lock not supported\n");
return -EOPNOTSUPP;
}
- key = crc32_posix(name_pad, sizeof(name_pad));
+ key = crc32_posix(res->name, NFP_RESOURCE_ENTRY_NAME_SZ);
for (i = 0; i < NFP_RESOURCE_TBL_ENTRIES; i++) {
u64 addr = NFP_RESOURCE_TBL_BASE +
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/4] nfp: include all ring counters in interface stats
From: Jakub Kicinski @ 2018-06-12 4:33 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20180612043338.5447-1-jakub.kicinski@netronome.com>
We are gathering software statistics on per-ring basis.
.ndo_get_stats64 handler adds the rings up. Unfortunately
we are currently only adding up active rings, which means
that if user decreases the number of active rings the
statistics from deactivated rings will no longer be counted
and total interface statistics may go backwards.
Always sum all possible rings, the stats are allocated
statically for max number of rings, so we don't have to
worry about them being removed. We could add the stats
up when user changes the ring count, but it seems unnecessary..
Adding up inactive rings will be very quick since no datapath
will be touching them.
Fixes: 164d1e9e5d52 ("nfp: add support for ethtool .set_channels")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 75110c8d6a90..ed27176c2bce 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -3121,7 +3121,7 @@ static void nfp_net_stat64(struct net_device *netdev,
struct nfp_net *nn = netdev_priv(netdev);
int r;
- for (r = 0; r < nn->dp.num_r_vecs; r++) {
+ for (r = 0; r < nn->max_r_vecs; r++) {
struct nfp_net_r_vector *r_vec = &nn->r_vecs[r];
u64 data[3];
unsigned int start;
--
2.17.1
^ permalink raw reply related
* [PATCH net 3/4] nfp: remove phys_port_name on flower's vNIC
From: Jakub Kicinski @ 2018-06-12 4:33 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20180612043338.5447-1-jakub.kicinski@netronome.com>
.ndo_get_phys_port_name was recently extended to support multi-vNIC
FWs. These are firmwares which can have more than one vNIC per PF
without associated port (e.g. Adaptive Buffer Management FW), therefore
we need a way of distinguishing the vNICs. Unfortunately, it's too
late to make flower use the same naming. Flower users may depend on
.ndo_get_phys_port_name returning -EOPNOTSUPP, for example the name
udev gave the PF vNIC was just the bare PCI device-based name before
the change, and will have 'nn0' appended after.
To ensure flower's vNIC doesn't have phys_port_name attribute, add
a flag to vNIC struct and set it in flower code. New projects will
not set the flag adhere to the naming scheme from the start.
Fixes: 51c1df83e35c ("nfp: assign vNIC id as phys_port_name of vNICs which are not ports")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/main.c | 1 +
drivers/net/ethernet/netronome/nfp/nfp_net.h | 4 ++++
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index 19cfa162ac65..1decf3a1cad3 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -455,6 +455,7 @@ static int nfp_flower_vnic_alloc(struct nfp_app *app, struct nfp_net *nn,
eth_hw_addr_random(nn->dp.netdev);
netif_keep_dst(nn->dp.netdev);
+ nn->vnic_no_name = true;
return 0;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net.h b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index 57cb035dcc6d..2a71a9ffd095 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -590,6 +590,8 @@ struct nfp_net_dp {
* @vnic_list: Entry on device vNIC list
* @pdev: Backpointer to PCI device
* @app: APP handle if available
+ * @vnic_no_name: For non-port PF vNIC make ndo_get_phys_port_name return
+ * -EOPNOTSUPP to keep backwards compatibility (set by app)
* @port: Pointer to nfp_port structure if vNIC is a port
* @app_priv: APP private data for this vNIC
*/
@@ -663,6 +665,8 @@ struct nfp_net {
struct pci_dev *pdev;
struct nfp_app *app;
+ bool vnic_no_name;
+
struct nfp_port *port;
void *app_priv;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index ed27176c2bce..d4c27f849f9b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -3286,7 +3286,7 @@ nfp_net_get_phys_port_name(struct net_device *netdev, char *name, size_t len)
if (nn->port)
return nfp_port_get_phys_port_name(netdev, name, len);
- if (nn->dp.is_vf)
+ if (nn->dp.is_vf || nn->vnic_no_name)
return -EOPNOTSUPP;
n = snprintf(name, len, "n%d", nn->id);
--
2.17.1
^ permalink raw reply related
* [PATCH net 0/4] nfp: fix a warning, stats, naming and route leak
From: Jakub Kicinski @ 2018-06-12 4:33 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Hi!
Various fixes for the NFP. Patch 1 fixes a harmless GCC 8 warning.
Patch 2 ensures statistics are correct after users decrease the number
of channels/rings. Patch 3 restores phy_port_name behaviour for flower,
ndo_get_phy_port_name used to return -EOPNOTSUPP on one of the netdevs,
and we need to keep it that way otherwise interface names may change.
Patch 4 fixes refcnt leak in flower tunnel offload code.
Jakub Kicinski (3):
nfp: don't pad strings in nfp_cpp_resource_find() to avoid gcc 8
warning
nfp: include all ring counters in interface stats
nfp: remove phys_port_name on flower's vNIC
Pieter Jansen van Vuuren (1):
nfp: flower: free dst_entry in route table
drivers/net/ethernet/netronome/nfp/flower/main.c | 1 +
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 2 ++
drivers/net/ethernet/netronome/nfp/nfp_net.h | 4 ++++
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 4 ++--
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c | 7 ++-----
5 files changed, 11 insertions(+), 7 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 4/4] nfp: flower: free dst_entry in route table
From: Jakub Kicinski @ 2018-06-12 4:33 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Pieter Jansen van Vuuren, Louis Peens
In-Reply-To: <20180612043338.5447-1-jakub.kicinski@netronome.com>
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
We need to release the refcnt on dst_entry in the route table, otherwise
we will leak the route.
Fixes: 8e6a9046b66a ("nfp: flower vxlan neighbour offload")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Signed-off-by: Louis Peens <louis.peens@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
index ec524d97869d..78afe75129ab 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
@@ -381,6 +381,8 @@ nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event,
err = PTR_ERR_OR_ZERO(rt);
if (err)
return NOTIFY_DONE;
+
+ ip_rt_put(rt);
#else
return NOTIFY_DONE;
#endif
--
2.17.1
^ permalink raw reply related
* [PATCH] isdn/i4l: add error handling for try_module_get
From: Zhouyang Jia @ 2018-06-12 4:43 UTC (permalink / raw)
Cc: Zhouyang Jia, Karsten Keil, Kees Cook, Annie Cherkaev, Al Viro,
Jiten Thakkar, netdev, linux-kernel
When try_module_get fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling try_module_get.
Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
---
drivers/isdn/i4l/isdn_common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 7c6f3f5..7e52851 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -71,7 +71,8 @@ static int isdn_add_channels(isdn_driver_t *d, int drvidx, int n, int adding);
static inline void
isdn_lock_driver(isdn_driver_t *drv)
{
- try_module_get(drv->interface->owner);
+ if (!try_module_get(drv->interface->owner))
+ printk(KERN_WARNING "isdn_lock_driver: cannot get module\n");
drv->locks++;
}
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Samudrala, Sridhar @ 2018-06-12 5:02 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: alexander.h.duyck, virtio-dev, aaron.f.brown, jiri, kubakici,
netdev, qemu-devel, loseweigh, virtualization
In-Reply-To: <20180612051432-mutt-send-email-mst@kernel.org>
On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
> On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
>>
>> On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
>>> On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
>>>> This feature bit can be used by hypervisor to indicate virtio_net device to
>>>> act as a standby for another device with the same MAC address.
>>>>
>>>> I tested this with a small change to the patch to mark the STANDBY feature 'true'
>>>> by default as i am using libvirt to start the VMs.
>>>> Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
>>>> XML file?
>>>>
>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>> So I do not think we can commit to this interface: we
>>> really need to control visibility of the primary device.
>> The problem is legacy guest won't use primary device at all if we do this.
> And that's by design - I think it's the only way to ensure the
> legacy guest isn't confused.
Yes. I think so. But i am not sure if Qemu is the right place to control the visibility
of the primary device. The primary device may not be specified as an argument to Qemu. It
may be plugged in later.
The cloud service provider is providing a feature that enables low latency datapath and live
migration capability.
A tenant can use this feature only if he is running a VM that has virtio-net with failover support.
I think Qemu should check if guest virtio-net supports this feature and provide a mechanism for
an upper layer indicating if the STANDBY feature is successfully negotiated or not.
The upper layer can then decide if it should hot plug a VF with the same MAC and manage the 2 links.
If VF is successfully hot plugged, virtio-net link should be disabled.
>
>> How about control the visibility of standby device?
>>
>> Thanks
> standy the always there to guarantee no downtime.
>
>>> However just for testing purposes, we could add a non-stable
>>> interface "x-standby" with the understanding that as any
>>> x- prefix it's unstable and will be changed down the road,
>>> likely in the next release.
>>>
>>>
>>>> ---
>>>> hw/net/virtio-net.c | 2 ++
>>>> include/standard-headers/linux/virtio_net.h | 3 +++
>>>> 2 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>> index 90502fca7c..38b3140670 100644
>>>> --- a/hw/net/virtio-net.c
>>>> +++ b/hw/net/virtio-net.c
>>>> @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
>>>> true),
>>>> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
>>>> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
>>>> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY,
>>>> + false),
>>>> DEFINE_PROP_END_OF_LIST(),
>>>> };
>>>> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
>>>> index e9f255ea3f..01ec09684c 100644
>>>> --- a/include/standard-headers/linux/virtio_net.h
>>>> +++ b/include/standard-headers/linux/virtio_net.h
>>>> @@ -57,6 +57,9 @@
>>>> * Steering */
>>>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>>>> +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
>>>> + * with the same MAC.
>>>> + */
>>>> #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
>>>> #ifndef VIRTIO_NET_NO_LEGACY
>>>> --
>>>> 2.14.3
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net] tls: fix NULL pointer dereference on poll
From: Christoph Hellwig @ 2018-06-12 5:37 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, davejwatson, netdev, ast, Christoph Hellwig
In-Reply-To: <20180611212204.24002-1-daniel@iogearbox.net>
> Looks like the recent conversion from poll to poll_mask callback started
> in 152524231023 ("net: add support for ->poll_mask in proto_ops") missed
> to eventually convert kTLS, too: TCP's ->poll was converted over to the
> ->poll_mask in commit 2c7d3dacebd4 ("net/tcp: convert to ->poll_mask")
> and therefore kTLS wrongly saved the ->poll old one which is now NULL.
Looks like this TLS code was added in the same cycle.
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index 301f224..a127d61 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -712,7 +712,7 @@ static int __init tls_register(void)
> build_protos(tls_prots[TLSV4], &tcp_prot);
>
> tls_sw_proto_ops = inet_stream_ops;
> - tls_sw_proto_ops.poll = tls_sw_poll;
> + tls_sw_proto_ops.poll_mask = tls_sw_poll_mask;
> tls_sw_proto_ops.splice_read = tls_sw_splice_read;
Not new in this patch, but copying ops vectors is a very bad idea, not
only because your new instance can't be marked const and you thus open
up exploit vectors. I would suggest to clean this up eventually.
> +__poll_t tls_sw_poll_mask(struct socket *sock, __poll_t events)
> {
> struct sock *sk = sock->sk;
> struct tls_context *tls_ctx = tls_get_ctx(sk);
> struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
> + __poll_t mask;
>
> + /* Grab EPOLLOUT and EPOLLHUP from the underlying socket */
> + mask = ctx->sk_poll_mask(sock, events);
>
> + /* Clear EPOLLIN bits, and set based on recv_pkt */
> + mask &= ~(EPOLLIN | EPOLLRDNORM);
> if (ctx->recv_pkt)
> + mask |= EPOLLIN | EPOLLRDNORM;
>
> + return mask;
So you call the underlying protocol method on the struct sock of
the TLS code? Again not reall new in this patch, but how is this
even supposed to work?
^ permalink raw reply
* [PATCH bpf v3] tools/bpftool: fix a bug in bpftool perf
From: Yonghong Song @ 2018-06-12 5:35 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[0] and feeds the file descriptor
and current task pid to the kernel for querying.
Such an approach won't work if the argv[0] cannot be opened
successfully in the current directory. This is especially
true when bpftool is accessible through PATH env variable.
The error below reflects the open failure for file argv[0]
at home directory.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: No such file or directory
To fix the issue, let us open root directory ("/")
which exists in every linux system. With the fix, the
error message will correctly reflect the permission issue.
[yhs@localhost ~]$ which bpftool
/usr/local/sbin/bpftool
[yhs@localhost ~]$ bpftool perf
Error: perf_query_support: Operation not permitted
HINT: non root or kernel doesn't support TASK_FD_QUERY
Fixes: b04df400c302 ("tools/bpftool: add perf subcommand")
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/bpf/bpftool/perf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Changelogs:
v2 -> v3:
. fix a stupid error (flippingg the condition) I introduced in v2.
v1 -> v2:
. remove '\n' in the p_err format string in order to
have valid json output.
diff --git a/tools/bpf/bpftool/perf.c b/tools/bpf/bpftool/perf.c
index ac6b1a12c9b7..b76b77dcfd1f 100644
--- a/tools/bpf/bpftool/perf.c
+++ b/tools/bpf/bpftool/perf.c
@@ -29,9 +29,10 @@ static bool has_perf_query_support(void)
if (perf_query_supported)
goto out;
- fd = open(bin_name, O_RDONLY);
+ fd = open("/", O_RDONLY);
if (fd < 0) {
- p_err("perf_query_support: %s", strerror(errno));
+ p_err("perf_query_support: cannot open directory \"/\" (%s)",
+ strerror(errno));
goto out;
}
--
2.14.3
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] xen/netfront: raise max number of slots in xennet_get_responses()
From: Juergen Gross @ 2018-06-12 6:45 UTC (permalink / raw)
To: Boris Ostrovsky, linux-kernel, xen-devel, netdev; +Cc: davem
In-Reply-To: <e970a52b-d4ad-30c1-65ca-15d7679951da@oracle.com>
On 11/06/18 20:59, Boris Ostrovsky wrote:
> On 06/11/2018 03:57 AM, Juergen Gross wrote:
>> The max number of slots used in xennet_get_responses() is set to
>> MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD).
>>
>> In old kernel-xen MAX_SKB_FRAGS was 18, while nowadays it is 17. This
>> difference is resulting in frequent messages "too many slots" and a
>> reduced network throughput for some workloads (factor 10 below that of
>> a kernel-xen based guest).
>>
>> Replacing MAX_SKB_FRAGS by XEN_NETIF_NR_SLOTS_MIN for calculation of
>> the max number of slots to use solves that problem (tests showed no
>> more messages "too many slots" and throughput was as high as with the
>> kernel-xen based guest system).
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> I wonder also whether netfront_tx_slot_available() is meant to be
>
> return (queue->tx.req_prod_pvt - queue->tx.rsp_cons) <
> (NET_TX_RING_SIZE - XEN_NETIF_NR_SLOTS_MIN - 1);
>
> which is the same numeric value but provides a more accurate description
> of what is being tested.
Yes, this is a sensible idea. I'll add that, keeping your R-b.
Juergen
^ permalink raw reply
* [PATCH v2] xen/netfront: raise max number of slots in xennet_get_responses()
From: Juergen Gross @ 2018-06-12 6:57 UTC (permalink / raw)
To: linux-kernel, xen-devel, netdev; +Cc: boris.ostrovsky, davem, Juergen Gross
The max number of slots used in xennet_get_responses() is set to
MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD).
In old kernel-xen MAX_SKB_FRAGS was 18, while nowadays it is 17. This
difference is resulting in frequent messages "too many slots" and a
reduced network throughput for some workloads (factor 10 below that of
a kernel-xen based guest).
Replacing MAX_SKB_FRAGS by XEN_NETIF_NR_SLOTS_MIN for calculation of
the max number of slots to use solves that problem (tests showed no
more messages "too many slots" and throughput was as high as with the
kernel-xen based guest system).
Replace MAX_SKB_FRAGS-2 by XEN_NETIF_NR_SLOTS_MIN-1 in
netfront_tx_slot_available() for making it clearer what is really being
tested without actually modifying the tested value.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
drivers/net/xen-netfront.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 679da1abd73c..922ce0abf5cf 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -239,7 +239,7 @@ static void rx_refill_timeout(struct timer_list *t)
static int netfront_tx_slot_available(struct netfront_queue *queue)
{
return (queue->tx.req_prod_pvt - queue->tx.rsp_cons) <
- (NET_TX_RING_SIZE - MAX_SKB_FRAGS - 2);
+ (NET_TX_RING_SIZE - XEN_NETIF_NR_SLOTS_MIN - 1);
}
static void xennet_maybe_wake_tx(struct netfront_queue *queue)
@@ -790,7 +790,7 @@ static int xennet_get_responses(struct netfront_queue *queue,
RING_IDX cons = queue->rx.rsp_cons;
struct sk_buff *skb = xennet_get_rx_skb(queue, cons);
grant_ref_t ref = xennet_get_rx_ref(queue, cons);
- int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD);
+ int max = XEN_NETIF_NR_SLOTS_MIN + (rx->status <= RX_COPY_THRESHOLD);
int slots = 1;
int err = 0;
unsigned long ret;
--
2.13.7
^ permalink raw reply related
* Re: [PATCH] net: phy: mdio-gpio: Cut surplus includes
From: Andrew Lunn @ 2018-06-12 7:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: Florian Fainelli, netdev
In-Reply-To: <20180611111903.7221-1-linus.walleij@linaro.org>
On Mon, Jun 11, 2018 at 01:19:03PM +0200, Linus Walleij wrote:
> The GPIO MDIO driver now needs only <linux/gpio/consumer.h>
> so cut the legacy <linux/gpio.h> and <linux/of_gpio.h>
> includes that are no longer used.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/3] m68k: coldfire: Normalize clk API
From: Greg Ungerer @ 2018-06-12 7:26 UTC (permalink / raw)
To: Geert Uytterhoeven, Ralf Baechle, James Hogan, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Corentin Labbe, David S . Miller
Cc: Arnd Bergmann, linux-m68k, linux-mips, netdev, linux-kernel
In-Reply-To: <1528706663-20670-2-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 11/06/18 18:44, Geert Uytterhoeven wrote:
> Coldfire still provides its own variant of the clk API rather than using
> the generic COMMON_CLK API. This generally works, but it causes some
> link errors with drivers using the clk_round_rate(), clk_set_rate(),
> clk_set_parent(), or clk_get_parent() functions when a platform lacks
> those interfaces.
>
> This adds empty stub implementations for each of them, and I don't even
> try to do something useful here but instead just print a WARN() message
> to make it obvious what is going on if they ever end up being called.
>
> The drivers that call these won't be used on these platforms (otherwise
> we'd get a link error today), so the added code is harmless bloat and
> will warn about accidental use.
>
> Based on commit bd7fefe1f06ca6cc ("ARM: w90x900: normalize clk API").
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
I am fine with this for ColdFire, so
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Are you going to take this/these via your m68k git tree?
Regards
Greg
> ---
> arch/m68k/coldfire/clk.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
> index 849cd208e2ed99e6..7bc666e482ebe82f 100644
> --- a/arch/m68k/coldfire/clk.c
> +++ b/arch/m68k/coldfire/clk.c
> @@ -129,4 +129,33 @@ unsigned long clk_get_rate(struct clk *clk)
> }
> EXPORT_SYMBOL(clk_get_rate);
>
> +/* dummy functions, should not be called */
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + WARN_ON(clk);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_round_rate);
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + WARN_ON(clk);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_set_rate);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + WARN_ON(clk);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_set_parent);
> +
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + WARN_ON(clk);
> + return NULL;
> +}
> +EXPORT_SYMBOL(clk_get_parent);
> +
> /***************************************************************************/
>
^ permalink raw reply
* Re: [PATCH 1/3] m68k: coldfire: Normalize clk API
From: Geert Uytterhoeven @ 2018-06-12 7:31 UTC (permalink / raw)
To: Greg Ungerer
Cc: Ralf Baechle, James Hogan, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, Corentin Labbe, David S. Miller, Arnd Bergmann,
linux-m68k, Linux MIPS Mailing List, netdev,
Linux Kernel Mailing List
In-Reply-To: <944b08ba-a882-e6cd-42fa-9251bce1d7b1@linux-m68k.org>
Hi Greg,
On Tue, Jun 12, 2018 at 9:27 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 11/06/18 18:44, Geert Uytterhoeven wrote:
> > Coldfire still provides its own variant of the clk API rather than using
> > the generic COMMON_CLK API. This generally works, but it causes some
> > link errors with drivers using the clk_round_rate(), clk_set_rate(),
> > clk_set_parent(), or clk_get_parent() functions when a platform lacks
> > those interfaces.
> >
> > This adds empty stub implementations for each of them, and I don't even
> > try to do something useful here but instead just print a WARN() message
> > to make it obvious what is going on if they ever end up being called.
> >
> > The drivers that call these won't be used on these platforms (otherwise
> > we'd get a link error today), so the added code is harmless bloat and
> > will warn about accidental use.
> >
> > Based on commit bd7fefe1f06ca6cc ("ARM: w90x900: normalize clk API").
> >
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> I am fine with this for ColdFire, so
>
> Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Thanks!
> Are you going to take this/these via your m68k git tree?
I''m fine delagating this to you.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH RFC v2 ipsec-next 0/3] Virtual xfrm interfaces
From: Steffen Klassert @ 2018-06-12 7:56 UTC (permalink / raw)
To: netdev, David Miller
Cc: Steffen Klassert, Eyal Birger, Antony Antony, Benedict Wong,
Lorenzo Colitti, Shannon Nelson
This patchset introduces new virtual xfrm interfaces.
The design of virtual xfrm interfaces interfaces was
discussed at the Linux IPsec workshop 2018. This patchset
implements these interfaces as the IPsec userspace and
kernel developers agreed. The purpose of these interfaces
is to overcome the design limitations that the existing
VTI devices have.
The main limitations that we see with the current VTI are the
following:
- VTI interfaces are L3 tunnels with configurable endpoints.
For xfrm, the tunnel endpoint are already determined by the SA.
So the VTI tunnel endpoints must be either the same as on the
SA or wildcards. In case VTI tunnel endpoints are same as on
the SA, we get a one to one correlation between the SA and
the tunnel. So each SA needs its own tunnel interface.
On the other hand, we can have only one VTI tunnel with
wildcard src/dst tunnel endpoints in the system because the
lookup is based on the tunnel endpoints. The existing tunnel
lookup won't work with multiple tunnels with wildcard
tunnel endpoints. Some usecases require more than on
VTI tunnel of this type, for example if somebody has multiple
namespaces and every namespace requires such a VTI.
- VTI needs separate interfaces for IPv4 and IPv6 tunnels.
So when routing to a VTI, we have to know to which address
family this traffic class is going to be encapsulated.
This is a lmitation because it makes routing more complex
and it is not always possible to know what happens behind the
VTI, e.g. when the VTI is move to some namespace.
- VTI works just with tunnel mode SAs. We need generic interfaces
that ensures transfomation, regardless of the xfrm mode and
the encapsulated address family.
- VTI is configured with a combination GRE keys and xfrm marks.
With this we have to deal with some extra cases in the generic
tunnel lookup because the GRE keys on the VTI are actually
not GRE keys, the GRE keys were just reused for something else.
All extensions to the VTI interfaces would require to add
even more complexity to the generic tunnel lookup.
To overcome this, we started with the following design goal:
- It should be possible to tunnel IPv4 and IPv6 through the same
interface.
- No limitation on xfrm mode (tunnel, transport and beet).
- Should be a generic virtual interface that ensures IPsec
transformation, no need to know what happens behind the
interface.
- Interfaces should be configured with a new key that must match a
new policy/SA lookup key.
- The lookup logic should stay in the xfrm codebase, no need to
change or extend generic routing and tunnel lookups.
- Should be possible to use IPsec hardware offloads of the underlying
interface.
Changes from v1:
- Document the limitations of VTI interfaces and the design of
the new xfrm interfaces more explicit in the commit messages.
- No code changes.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox