* [PATCH] page_pool: fix compile warning when CONFIG_PAGE_POOL is disabled
From: Jesper Dangaard Brouer @ 2019-06-19 22:15 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev
Kbuild test robot reported compile warning:
warning: no return statement in function returning non-void
in function page_pool_request_shutdown, when CONFIG_PAGE_POOL is disabled.
The fix makes the code a little more verbose, with a descriptive variable.
Fixes: 99c07c43c4ea ("xdp: tracking page_pool resources and safe removal")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reported-by: kbuild test robot <lkp@intel.com>
---
include/net/page_pool.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index f09b3f1994e6..f07c518ef8a5 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -156,12 +156,12 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
bool __page_pool_request_shutdown(struct page_pool *pool);
static inline bool page_pool_request_shutdown(struct page_pool *pool)
{
- /* When page_pool isn't compiled-in, net/core/xdp.c doesn't
- * allow registering MEM_TYPE_PAGE_POOL, but shield linker.
- */
+ bool safe_to_remove = false;
+
#ifdef CONFIG_PAGE_POOL
- return __page_pool_request_shutdown(pool);
+ safe_to_remove = __page_pool_request_shutdown(pool);
#endif
+ return safe_to_remove;
}
/* Disconnects a page (from a page_pool). API users can have a need
^ permalink raw reply related
* Re: network unstable on odroid-c1/meson8b.
From: Heiner Kallweit @ 2019-06-19 22:14 UTC (permalink / raw)
To: Aymeric, netdev; +Cc: linux-amlogic@lists.infradead.org, Martin Blumenstingl
In-Reply-To: <ff9a72bf-7eeb-542b-6292-dd70abdc4e79@aplu.fr>
On 19.06.2019 22:18, Aymeric wrote:
> Hello all,
>
> I've an ODROID-C1 board (a meson8b/S805) and I've some network
> unstablity with current mainline kernel; as time of writting, tested
> 5.0.y, 5.1.y, 5.2-rc4 and didn't try with any others versions.
>
> After a few talks on linux-amlogic mailing list, I've been pointed here
> to find and, hoppefully, fix the issue.
> The whole thread on linux-amlogic is available here: [¹]
>
> A short summary:
> 1. With Kernel 3.10.something made by Hardkernel (the one from the board
> vendor), the network link is working at 1 gigabit and stay at 1 gigabit.
> 2. With Kernel 5.0.y, 5.1.y, mainline, the network link goes from up to
> down every few seconds at 1 gigabit (making the board unusable) but is
> working fine when forced at 100Mb (using ethtool command).
> 3. The ethernet cable is not the cause of the issue (see #4).
> 4. After a few more check, I was able to narrow the problem. It's only
> present when the board is connected to my "internet box" (a Livebox
> 3/Sagemcom) but not with a "stupid" d-link switch (both have gigabit
> capability).
> 5. With the help from Martin on linux-amlogic I've tried to disable EEE
> in the dtb but it didn't change anything.
> 6. An extract of the dmesg output grepping ethernet and meson is here
> when the issue is occuring: [²].
>
Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
I assume the genphy driver was used. Do you have a line with
"attached PHY driver" in dmesg output of the vendor kernel?
The dedicated PHY driver takes care of the tx delay, if the genphy
driver is used we have to rely on what uboot configured.
But if we indeed had an issue with a misconfigured delay, I think
the connection shouldn't be fine with just another link partner.
Just to have it tested you could make rtl8211f_config_init() in
drivers/net/phy/realtek.c a no-op (in current kernels).
And you could compare at least the basic PHY registers 0x00 - 0x30
with both kernel versions, e.g. with phytool.
>
> And the last comment from Martin and why I'm sending a mail here:
> - the Amlogic SoCs use a DesignWare MAC (Ethernet controller, the driver
> is called stmmac) with a Relatek RTL8211F Ethernet PHY.
> - there's little Amlogic specific registers involved: they mostly
> control the PHY interface (enabling RMII or RGMII) and the clocks so
> it's very likely that someone on the netdev list has an idea how to
> debug this because a large part of the Ethernet setup is not Amlogic SoC
> specific
>
> So if you've got any idea to fix this issue.. :)
>
> Thanks in advance,
>
> Aymeric.
>
Heiner
>
> [¹]:
> http://lists.infradead.org/pipermail/linux-amlogic/2019-June/012341.html
> [²]:
> https://paste.aplu.fr/?b5eb6df48a9c95b6#sqHk8xhWGwRfagWNpL+u7mIsPGWVWFn2d7xBqika8Kc=
>
>
>
^ permalink raw reply
* Re: [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Cong Wang @ 2019-06-19 22:04 UTC (permalink / raw)
To: Davide Caratti
Cc: Vlad Buslov, David S. Miller, Linux Kernel Network Developers,
Lucas Bates
In-Reply-To: <9068475730862e1d9014c16cee0ad2734a4dd1f9.1560978242.git.dcaratti@redhat.com>
On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti <dcaratti@redhat.com> wrote:
>
> on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> In this situation, the following script:
>
> # tc filter add dev eth0 ingress handle 0xffffffff flower action ok
> # tc filter show dev eth0 ingress
>
> results in an infinite loop. It happened also on other CPUs (e.g x86_64),
> before commit 061775583e35 ("net: sched: flower: introduce reference
> counting for filters"), because 'handle' + 1 made the u32 overflow before
> it was assigned to 'cookie'; but that commit replaced the assignment with
> a self-increment of 'cookie', so the problem was indirectly fixed.
Interesting... Is this really specific to cls_flower? To me it looks like
a bug of idr_*_ul() API's, especially for idr_for_each_entry_ul().
Can you test if the following command has the same problem on i386?
tc actions add action ok index 4294967295
It is hard for me to find a 32bit CPU.
Thanks.
^ permalink raw reply
* Re: [PATCH net] inet: clear num_timeout reqsk_alloc()
From: David Miller @ 2019-06-19 21:48 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ycheng, ncardwell, soheil, syzkaller
In-Reply-To: <20190619163838.150971-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 19 Jun 2019 09:38:38 -0700
> KMSAN caught uninit-value in tcp_create_openreq_child() [1]
> This is caused by a recent change, combined by the fact
> that TCP cleared num_timeout, num_retrans and sk fields only
> when a request socket was about to be queued.
>
> Under syncookie mode, a temporary request socket is used,
> and req->num_timeout could contain garbage.
>
> Lets clear these three fields sooner, there is really no
> point trying to defer this and risk other bugs.
>
> [1]
>
> BUG: KMSAN: uninit-value in tcp_create_openreq_child+0x157f/0x1cc0 net/ipv4/tcp_minisocks.c:526
...
> Fixes: 336c39a03151 ("tcp: undo init congestion window on false SYNACK timeout")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net: fastopen: robustness and endianness fixes for SipHash
From: Ard Biesheuvel @ 2019-06-19 21:47 UTC (permalink / raw)
To: David Miller
Cc: <netdev@vger.kernel.org>, Eric Biggers,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Herbert Xu,
Eric Dumazet, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jason Baron,
Christoph Paasch, David Laight, Yuchung Cheng
In-Reply-To: <20190619.174234.2210089047219514238.davem@davemloft.net>
On Wed, 19 Jun 2019 at 23:42, David Miller <davem@davemloft.net> wrote:
>
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Wed, 19 Jun 2019 08:55:10 +0200
>
> > + ctx->key[0] = (siphash_key_t){
> > + get_unaligned_le64(primary_key),
> > + get_unaligned_le64(primary_key + 8)
> > + };
>
> Please just use normal assignment(s), because not only does this warn
> it looks not so nice.
>
OK
Please disregard the v3 I just sent out, v4 has ordinary assignments.
^ permalink raw reply
* [PATCH v4 1/1] net: fastopen: robustness and endianness fixes for SipHash
From: Ard Biesheuvel @ 2019-06-19 21:46 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
In-Reply-To: <20190619214628.2960-1-ard.biesheuvel@linaro.org>
Some changes to the TCP fastopen code to make it more robust
against future changes in the choice of key/cookie size, etc.
- Instead of keeping the SipHash key in an untyped u8[] buffer
and casting it to the right type upon use, use the correct
type directly. This ensures that the key will appear at the
correct alignment if we ever change the way these data
structures are allocated. (Currently, they are only allocated
via kmalloc so they always appear at the correct alignment)
- Use DIV_ROUND_UP when sizing the u64[] array to hold the
cookie, so it is always of sufficient size, even if
TCP_FASTOPEN_COOKIE_MAX is no longer a multiple of 8.
- Drop the 'len' parameter from the tcp_fastopen_reset_cipher()
function, which is no longer used.
- Add endian swabbing when setting the keys and calculating the hash,
to ensure that cookie values are the same for a given key and
source/destination address pair regardless of the endianness of
the server.
Note that none of these are functional changes wrt the current
state of the code, with the exception of the swabbing, which only
affects big endian systems.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/tcp.h | 2 +-
include/net/tcp.h | 8 ++---
net/ipv4/sysctl_net_ipv4.c | 3 +-
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_fastopen.c | 35 ++++++++++----------
5 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 2689b0b0b68a..f3a85a7fb4b1 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -58,7 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
/* TCP Fast Open Cookie as stored in memory */
struct tcp_fastopen_cookie {
- u64 val[TCP_FASTOPEN_COOKIE_MAX / sizeof(u64)];
+ __le64 val[DIV_ROUND_UP(TCP_FASTOPEN_COOKIE_MAX, sizeof(u64))];
s8 len;
bool exp; /* In RFC6994 experimental option format */
};
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 573c9e9b0d72..9d36cc88d043 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,7 @@
#include <linux/seq_file.h>
#include <linux/memcontrol.h>
#include <linux/bpf-cgroup.h>
+#include <linux/siphash.h>
extern struct inet_hashinfo tcp_hashinfo;
@@ -1612,8 +1613,7 @@ void tcp_free_fastopen_req(struct tcp_sock *tp);
void tcp_fastopen_destroy_cipher(struct sock *sk);
void tcp_fastopen_ctx_destroy(struct net *net);
int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
- void *primary_key, void *backup_key,
- unsigned int len);
+ void *primary_key, void *backup_key);
void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb);
struct sock *tcp_try_fastopen(struct sock *sk, struct sk_buff *skb,
struct request_sock *req,
@@ -1623,14 +1623,14 @@ void tcp_fastopen_init_key_once(struct net *net);
bool tcp_fastopen_cookie_check(struct sock *sk, u16 *mss,
struct tcp_fastopen_cookie *cookie);
bool tcp_fastopen_defer_connect(struct sock *sk, int *err);
-#define TCP_FASTOPEN_KEY_LENGTH 16
+#define TCP_FASTOPEN_KEY_LENGTH sizeof(siphash_key_t)
#define TCP_FASTOPEN_KEY_MAX 2
#define TCP_FASTOPEN_KEY_BUF_LENGTH \
(TCP_FASTOPEN_KEY_LENGTH * TCP_FASTOPEN_KEY_MAX)
/* Fastopen key context */
struct tcp_fastopen_context {
- __u8 key[TCP_FASTOPEN_KEY_MAX][TCP_FASTOPEN_KEY_LENGTH];
+ siphash_key_t key[TCP_FASTOPEN_KEY_MAX];
int num;
struct rcu_head rcu;
};
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 7d802acde040..7d66306b5f39 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -365,8 +365,7 @@ static int proc_tcp_fastopen_key(struct ctl_table *table, int write,
}
}
tcp_fastopen_reset_cipher(net, NULL, key,
- backup_data ? key + 4 : NULL,
- TCP_FASTOPEN_KEY_LENGTH);
+ backup_data ? key + 4 : NULL);
}
bad_key:
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index efd7f2b1d1f0..47c217905864 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2822,8 +2822,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
if (optlen == TCP_FASTOPEN_KEY_BUF_LENGTH)
backup_key = key + TCP_FASTOPEN_KEY_LENGTH;
- return tcp_fastopen_reset_cipher(net, sk, key, backup_key,
- TCP_FASTOPEN_KEY_LENGTH);
+ return tcp_fastopen_reset_cipher(net, sk, key, backup_key);
}
default:
/* fallthru */
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 46b67128e1ca..cb3193d46302 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -7,7 +7,6 @@
#include <linux/tcp.h>
#include <linux/rcupdate.h>
#include <linux/rculist.h>
-#include <linux/siphash.h>
#include <net/inetpeer.h>
#include <net/tcp.h>
@@ -31,7 +30,7 @@ void tcp_fastopen_init_key_once(struct net *net)
* for a valid cookie, so this is an acceptable risk.
*/
get_random_bytes(key, sizeof(key));
- tcp_fastopen_reset_cipher(net, NULL, key, NULL, sizeof(key));
+ tcp_fastopen_reset_cipher(net, NULL, key, NULL);
}
static void tcp_fastopen_ctx_free(struct rcu_head *head)
@@ -68,8 +67,7 @@ void tcp_fastopen_ctx_destroy(struct net *net)
}
int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
- void *primary_key, void *backup_key,
- unsigned int len)
+ void *primary_key, void *backup_key)
{
struct tcp_fastopen_context *ctx, *octx;
struct fastopen_queue *q;
@@ -81,9 +79,11 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
goto out;
}
- memcpy(ctx->key[0], primary_key, len);
+ ctx->key[0].key[0] = get_unaligned_le64(primary_key);
+ ctx->key[0].key[1] = get_unaligned_le64(primary_key + 8);
if (backup_key) {
- memcpy(ctx->key[1], backup_key, len);
+ ctx->key[1].key[0] = get_unaligned_le64(backup_key);
+ ctx->key[1].key[1] = get_unaligned_le64(backup_key + 8);
ctx->num = 2;
} else {
ctx->num = 1;
@@ -110,19 +110,18 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
struct sk_buff *syn,
- const u8 *key,
+ const siphash_key_t *key,
struct tcp_fastopen_cookie *foc)
{
- BUILD_BUG_ON(TCP_FASTOPEN_KEY_LENGTH != sizeof(siphash_key_t));
BUILD_BUG_ON(TCP_FASTOPEN_COOKIE_SIZE != sizeof(u64));
if (req->rsk_ops->family == AF_INET) {
const struct iphdr *iph = ip_hdr(syn);
- foc->val[0] = siphash(&iph->saddr,
- sizeof(iph->saddr) +
- sizeof(iph->daddr),
- (const siphash_key_t *)key);
+ foc->val[0] = cpu_to_le64(siphash(&iph->saddr,
+ sizeof(iph->saddr) +
+ sizeof(iph->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -130,10 +129,10 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
if (req->rsk_ops->family == AF_INET6) {
const struct ipv6hdr *ip6h = ipv6_hdr(syn);
- foc->val[0] = siphash(&ip6h->saddr,
- sizeof(ip6h->saddr) +
- sizeof(ip6h->daddr),
- (const siphash_key_t *)key);
+ foc->val[0] = cpu_to_le64(siphash(&ip6h->saddr,
+ sizeof(ip6h->saddr) +
+ sizeof(ip6h->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -154,7 +153,7 @@ static void tcp_fastopen_cookie_gen(struct sock *sk,
rcu_read_lock();
ctx = tcp_fastopen_get_ctx(sk);
if (ctx)
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[0], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[0], foc);
rcu_read_unlock();
}
@@ -218,7 +217,7 @@ static int tcp_fastopen_cookie_gen_check(struct sock *sk,
if (!ctx)
goto out;
for (i = 0; i < tcp_fastopen_context_len(ctx); i++) {
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[i], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[i], foc);
if (tcp_fastopen_cookie_match(foc, orig)) {
ret = i + 1;
goto out;
--
2.17.1
^ permalink raw reply related
* [PATCH v4 0/1] net: fastopen: follow-up tweaks for SipHash switch
From: Ard Biesheuvel @ 2019-06-19 21:46 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
Some fixes for the fastopen code after switching to SipHash, which were
spotted in review after the change had already been queued.
Changes since v3:
- switch from compount literals to individual assignments of the siphash
key fields
Changes since v2:
- add missing pairs of braces in compound literals used to assign the
fastopen keys
cc: Eric Biggers <ebiggers@kernel.org>
cc: linux-crypto@vger.kernel.org
cc: herbert@gondor.apana.org.au
cc: edumazet@google.com
cc: davem@davemloft.net
cc: kuznet@ms2.inr.ac.ru
cc: yoshfuji@linux-ipv6.org
cc: jbaron@akamai.com
cc: cpaasch@apple.com
cc: David.Laight@aculab.com
cc: ycheng@google.com
Ard Biesheuvel (1):
net: fastopen: robustness and endianness fixes for SipHash
include/linux/tcp.h | 2 +-
include/net/tcp.h | 8 ++---
net/ipv4/sysctl_net_ipv4.c | 3 +-
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_fastopen.c | 35 ++++++++++----------
5 files changed, 24 insertions(+), 27 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next v7 1/9] bpf: implement getsockopt and setsockopt hooks
From: Andrii Nakryiko @ 2019-06-19 21:45 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, Networking, bpf, David S. Miller,
Alexei Starovoitov, Daniel Borkmann, Martin Lau
In-Reply-To: <20190619201710.GB19111@mini-arch>
On Wed, Jun 19, 2019 at 1:17 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/19, Andrii Nakryiko wrote:
> > On Wed, Jun 19, 2019 at 10:00 AM Stanislav Fomichev <sdf@google.com> wrote:
> > >
> > > Implement new BPF_PROG_TYPE_CGROUP_SOCKOPT program type and
> > > BPF_CGROUP_{G,S}ETSOCKOPT cgroup hooks.
> > >
> > > BPF_CGROUP_SETSOCKOPT get a read-only view of the setsockopt arguments.
> > > BPF_CGROUP_GETSOCKOPT can modify the supplied buffer.
> > > Both of them reuse existing PTR_TO_PACKET{,_END} infrastructure.
> > >
> > > The buffer memory is pre-allocated (because I don't think there is
> > > a precedent for working with __user memory from bpf). This might be
> > > slow to do for each {s,g}etsockopt call, that's why I've added
> > > __cgroup_bpf_prog_array_is_empty that exits early if there is nothing
> > > attached to a cgroup. Note, however, that there is a race between
> > > __cgroup_bpf_prog_array_is_empty and BPF_PROG_RUN_ARRAY where cgroup
> > > program layout might have changed; this should not be a problem
> > > because in general there is a race between multiple calls to
> > > {s,g}etsocktop and user adding/removing bpf progs from a cgroup.
> > >
> > > The return code of the BPF program is handled as follows:
> > > * 0: EPERM
> > > * 1: success, continue with next BPF program in the cgroup chain
> > >
> > > v7:
> > > * return only 0 or 1 (Alexei Starovoitov)
> > > * always run all progs (Alexei Starovoitov)
> > > * use optval=0 as kernel bypass in setsockopt (Alexei Starovoitov)
> > > (decided to use optval=-1 instead, optval=0 might be a valid input)
> > > * call getsockopt hook after kernel handlers (Alexei Starovoitov)
> > >
> > > v6:
> > > * rework cgroup chaining; stop as soon as bpf program returns
> > > 0 or 2; see patch with the documentation for the details
> > > * drop Andrii's and Martin's Acked-by (not sure they are comfortable
> > > with the new state of things)
> >
> > I like the general approach, just overall unclear about seemingly
> > artificial restrictions I mentioned below.
> >
> > >
> > > v5:
> > > * skip copy_to_user() and put_user() when ret == 0 (Martin Lau)
> > >
> > > v4:
> > > * don't export bpf_sk_fullsock helper (Martin Lau)
> > > * size != sizeof(__u64) for uapi pointers (Martin Lau)
> > > * offsetof instead of bpf_ctx_range when checking ctx access (Martin Lau)
> > >
> > > v3:
> > > * typos in BPF_PROG_CGROUP_SOCKOPT_RUN_ARRAY comments (Andrii Nakryiko)
> > > * reverse christmas tree in BPF_PROG_CGROUP_SOCKOPT_RUN_ARRAY (Andrii
> > > Nakryiko)
> > > * use __bpf_md_ptr instead of __u32 for optval{,_end} (Martin Lau)
> > > * use BPF_FIELD_SIZEOF() for consistency (Martin Lau)
> > > * new CG_SOCKOPT_ACCESS macro to wrap repeated parts
> > >
> > > v2:
> > > * moved bpf_sockopt_kern fields around to remove a hole (Martin Lau)
> > > * aligned bpf_sockopt_kern->buf to 8 bytes (Martin Lau)
> > > * bpf_prog_array_is_empty instead of bpf_prog_array_length (Martin Lau)
> > > * added [0,2] return code check to verifier (Martin Lau)
> > > * dropped unused buf[64] from the stack (Martin Lau)
> > > * use PTR_TO_SOCKET for bpf_sockopt->sk (Martin Lau)
> > > * dropped bpf_target_off from ctx rewrites (Martin Lau)
> > > * use return code for kernel bypass (Martin Lau & Andrii Nakryiko)
> > >
> > > Cc: Martin Lau <kafai@fb.com>
> > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > ---
> >
> > <snip>
> >
> > >
> > > +struct bpf_sockopt_kern {
> > > + struct sock *sk;
> > > + u8 *optval;
> > > + u8 *optval_end;
> > > + s32 level;
> > > + s32 optname;
> > > + u32 optlen;
> >
> > Optlen is used below as signed integer, so switch it to s32?
> Good catch, should be s32 here and below, thanks!
>
> > > + s32 retval;
> > > +
> > > + /* Small on-stack optval buffer to avoid small allocations.
> > > + */
> > > + u8 buf[64] __aligned(8);
> > > +};
> > > +
> >
> > <snip>
> >
> > >
> > > +struct bpf_sockopt {
> > > + __bpf_md_ptr(struct bpf_sock *, sk);
> > > + __bpf_md_ptr(void *, optval);
> > > + __bpf_md_ptr(void *, optval_end);
> > > +
> > > + __s32 level;
> > > + __s32 optname;
> > > + __u32 optlen;
> >
> > Same as above, we expect BPF program to be able to set it to -1, so __s32?
> >
> > > + __s32 retval;
> > > +};
> > > +
> > > #endif /* _UAPI__LINUX_BPF_H__ */
> > > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> >
> > <snip>
> >
> > > +
> > > + if (ctx.optlen == -1)
> > > + /* optlen set to -1, bypass kernel */
> > > + ret = 1;
> > > + else if (ctx.optlen == optlen)
> > > + /* optlen not changed, run kernel handler */
> > > + ret = 0;
> > > + else
> > > + /* any other value is rejected */
> > > + ret = -EFAULT;
> >
> > I'm consufed about this assymetry between getsockopt and setsockopt
> > behavior. Why we are disallowing setsockopt from changing optlen (and
> > value itself)? Is there any harm in allowing that? Imagining some use
> > case that provides transparent "support" for some option, you'd need
> > to be able to intercept and provide custom values both for setsockopt
> > and getsockopt. So unless I'm missing some security implications, why
> > not make both sides able to write?
> Because kernel setsockopt handlers use get_user to read the data. We
> can definitely allow changing optval+optlen, but we'd have to copy
> that data back to userspace to let kernel handle it. I'm not sure how
> userspace might feel about it. Can it be a buffer in the readonly
> elf section?
Ah, ok, now I see why :) Yeah, I guess it can be in read-only section.
Alright, I don't see an easy solution to that, I guess we can live
with that for now.
>
> > Similar will apply w.r.t. retval, why can't setsockopt return EINVAL
> > to reject some options? This seems very useful and very similar to
> > what sysctl BPF hooks do.
> I was just being defensive because I'm not sure what's the use-case.
> We can already return EPERM, why do we need to return a different
> error code? Are we comfortable letting progs return arbitrary number?
> Or you just want to allow a bunch of pre-defined error codes?
>
> I haven't seen the ability to return arbitrary error from the sysctl
> hooks, but maybe I didn't look hard enough.
Yeah, seems like sysctl is only 0 or EPERM. I missed for a moment that
there is return value from BPF program and retval from the context. I
think it's good enough as is.
>
> > > +
> > > +out:
> > > + sockopt_free_buf(&ctx);
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(__cgroup_bpf_run_filter_setsockopt);
> > > +
> > > +int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
> > > + int optname, char __user *optval,
> > > + int __user *optlen, int max_optlen,
> > > + int retval)
> > > +{
> >
> > <snip>
> >
> > > +
> > > + if (ctx.optlen > max_optlen) {
> > > + ret = -EFAULT;
> > > + goto out;
> > > + }
> > > +
> > > + /* BPF programs only allowed to set retval to 0, not some
> > > + * arbitrary value.
> > > + */
> > > + if (ctx.retval != 0 && ctx.retval != retval) {
> >
> > Lookin at manpage of getsockopt, seems like at least two error codes
> > are relevant and generally useful for BPF program to be able to
> > return: EINVAL and ENOPROTOOPT? Why we are disallowing anything but 0
> > (or preserving original retval)?
> I was thinking about simple use-case where it's either BPF that
> handles the opt or the kernel. And then it's BFP returning success or
> EPERM. I don't think I understand why BPF needs to be able to
> return different error codes. We can certainly do that if you think
> that it makes sense; alternatively, we can start with 0 or kernel retval
> and relax the requirements if someone really needs that in the future.
>
> (I don't have a strong opinion here tbh).
As replied above, EPERM is probably good enough for practical
purposes, I was being a bit pedantic :)
>
> > > + ret = -EFAULT;
> > > + goto out;
> > > + }
> > > +
> > > + if (copy_to_user(optval, ctx.optval, ctx.optlen) ||
> > > + put_user(ctx.optlen, optlen)) {
> > > + ret = -EFAULT;
> > > + goto out;
> > > + }
> > > +
> > > + ret = ctx.retval;
> > > +
> > > +out:
> > > + sockopt_free_buf(&ctx);
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(__cgroup_bpf_run_filter_getsockopt);
> > > +
> >
> > <snip>
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net: fastopen: robustness and endianness fixes for SipHash
From: David Miller @ 2019-06-19 21:42 UTC (permalink / raw)
To: ard.biesheuvel
Cc: netdev, ebiggers, linux-crypto, herbert, edumazet, kuznet,
yoshfuji, jbaron, cpaasch, David.Laight, ycheng
In-Reply-To: <20190619065510.23514-2-ard.biesheuvel@linaro.org>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Wed, 19 Jun 2019 08:55:10 +0200
> + ctx->key[0] = (siphash_key_t){
> + get_unaligned_le64(primary_key),
> + get_unaligned_le64(primary_key + 8)
> + };
Please just use normal assignment(s), because not only does this warn
it looks not so nice.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v1] net: stmmac: initialize the reset delay array
From: David Miller @ 2019-06-19 21:41 UTC (permalink / raw)
To: martin.blumenstingl
Cc: netdev, linux-kernel, joabreu, alexandre.torgue, peppe.cavallaro,
khilman
In-Reply-To: <20190618203927.5862-1-martin.blumenstingl@googlemail.com>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Tue, 18 Jun 2019 22:39:27 +0200
> Commit ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct
> stmmac_mdio_bus_data") moved the reset delay array from struct
> stmmac_mdio_bus_data to a stack variable.
> The values from the array inside struct stmmac_mdio_bus_data were
> previously initialized to 0 because the struct was allocated using
> devm_kzalloc(). The array on the stack has to be initialized
> explicitly, else we might be reading garbage values.
>
> Initialize all reset delays to 0 to ensure that the values are 0 if the
> "snps,reset-delays-us" property is not defined.
> This fixes booting at least two boards (MIPS pistachio marduk and ARM
> sun8i H2+ Orange Pi Zero). These are hanging during boot when
> initializing the stmmac Ethernet controller (as found by Kernel CI).
> Both have in common that they don't define the "snps,reset-delays-us"
> property.
>
> Fixes: ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct stmmac_mdio_bus_data")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied, thanks.
> Please feel free to squash this into net-next commit ce4ab73ab0c27c.
We do not "squash" things into existing net-next commits, as commits in
my tree(s) are permanent and immutable.
^ permalink raw reply
* Re: [PATCH net-next] selftests/net: make udpgso_bench skip unsupported testcases
From: David Miller @ 2019-06-19 21:34 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: netdev, gregkh, naresh.kamboju, linux-kselftest, willemb
In-Reply-To: <20190618200304.63068-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 18 Jun 2019 16:03:04 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Kselftest can be run against older kernels. Instead of failing hard
> when a feature is unsupported, return the KSFT_SKIP exit code.
>
> Specifically, do not fail hard on missing udp zerocopy.
>
> The udp gso bench test runs multiple test cases from a single script.
> Fail if any case fails, else return skip if any test is skipped.
>
> Link: https://lore.kernel.org/lkml/20190618171516.GA17547@kroah.com/
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] PCI: let pci_disable_link_state propagate errors
From: Bjorn Helgaas @ 2019-06-19 21:32 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, David Miller,
linux-pci@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <604f2954-c60c-d2aa-3849-9a2f8872001c@gmail.com>
On Tue, Jun 18, 2019 at 11:13:48PM +0200, Heiner Kallweit wrote:
> Drivers may rely on pci_disable_link_state() having disabled certain
> ASPM link states. If OS can't control ASPM then pci_disable_link_state()
> turns into a no-op w/o informing the caller. The driver therefore may
> falsely assume the respective ASPM link states are disabled.
> Let pci_disable_link_state() propagate errors to the caller, enabling
> the caller to react accordingly.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Thanks, I think this makes good sense.
> ---
> drivers/pci/pcie/aspm.c | 20 +++++++++++---------
> include/linux/pci-aspm.h | 7 ++++---
> 2 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index fd4cb7508..e44af7f4d 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -1062,18 +1062,18 @@ void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
> up_read(&pci_bus_sem);
> }
>
> -static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
> +static int __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
> {
> struct pci_dev *parent = pdev->bus->self;
> struct pcie_link_state *link;
>
> if (!pci_is_pcie(pdev))
> - return;
> + return 0;
>
> if (pdev->has_secondary_link)
> parent = pdev;
> if (!parent || !parent->link_state)
> - return;
> + return -EINVAL;
>
> /*
> * A driver requested that ASPM be disabled on this device, but
> @@ -1085,7 +1085,7 @@ static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
> */
> if (aspm_disabled) {
> pci_warn(pdev, "can't disable ASPM; OS doesn't have ASPM control\n");
> - return;
> + return -EPERM;
> }
>
> if (sem)
> @@ -1105,11 +1105,13 @@ static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
> mutex_unlock(&aspm_lock);
> if (sem)
> up_read(&pci_bus_sem);
> +
> + return 0;
> }
>
> -void pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> {
> - __pci_disable_link_state(pdev, state, false);
> + return __pci_disable_link_state(pdev, state, false);
> }
> EXPORT_SYMBOL(pci_disable_link_state_locked);
>
> @@ -1117,14 +1119,14 @@ EXPORT_SYMBOL(pci_disable_link_state_locked);
> * pci_disable_link_state - Disable device's link state, so the link will
> * never enter specific states. Note that if the BIOS didn't grant ASPM
> * control to the OS, this does nothing because we can't touch the LNKCTL
> - * register.
> + * register. Returns 0 or a negative errno.
> *
> * @pdev: PCI device
> * @state: ASPM link state to disable
> */
> -void pci_disable_link_state(struct pci_dev *pdev, int state)
> +int pci_disable_link_state(struct pci_dev *pdev, int state)
> {
> - __pci_disable_link_state(pdev, state, true);
> + return __pci_disable_link_state(pdev, state, true);
> }
> EXPORT_SYMBOL(pci_disable_link_state);
>
> diff --git a/include/linux/pci-aspm.h b/include/linux/pci-aspm.h
> index df28af5ce..67064145d 100644
> --- a/include/linux/pci-aspm.h
> +++ b/include/linux/pci-aspm.h
> @@ -24,11 +24,12 @@
> #define PCIE_LINK_STATE_CLKPM 4
>
> #ifdef CONFIG_PCIEASPM
> -void pci_disable_link_state(struct pci_dev *pdev, int state);
> -void pci_disable_link_state_locked(struct pci_dev *pdev, int state);
> +int pci_disable_link_state(struct pci_dev *pdev, int state);
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state);
> void pcie_no_aspm(void);
> #else
> -static inline void pci_disable_link_state(struct pci_dev *pdev, int state) { }
> +static inline int pci_disable_link_state(struct pci_dev *pdev, int state)
> +{ return 0; }
> static inline void pcie_no_aspm(void) { }
> #endif
>
> --
> 2.22.0
>
>
^ permalink raw reply
* Re: [PATCH] net/ipv4: fib_trie: Avoid cryptic ternary expressions
From: David Miller @ 2019-06-19 21:29 UTC (permalink / raw)
To: mka; +Cc: kuznet, yoshfuji, alexander.h.duyck, netdev, linux-kernel,
dianders
In-Reply-To: <20190618211440.54179-1-mka@chromium.org>
From: Matthias Kaehlcke <mka@chromium.org>
Date: Tue, 18 Jun 2019 14:14:40 -0700
> empty_child_inc/dec() use the ternary operator for conditional
> operations. The conditions involve the post/pre in/decrement
> operator and the operation is only performed when the condition
> is *not* true. This is hard to parse for humans, use a regular
> 'if' construct instead and perform the in/decrement separately.
>
> This also fixes two warnings that are emitted about the value
> of the ternary expression being unused, when building the kernel
> with clang + "kbuild: Remove unnecessary -Wno-unused-value"
> (https://lore.kernel.org/patchwork/patch/1089869/):
>
> CC net/ipv4/fib_trie.o
> net/ipv4/fib_trie.c:351:2: error: expression result unused [-Werror,-Wunused-value]
> ++tn_info(n)->empty_children ? : ++tn_info(n)->full_children;
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH net-next v3 1/1] net: fastopen: robustness and endianness fixes for SipHash
From: Ard Biesheuvel @ 2019-06-19 21:27 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
In-Reply-To: <20190619212747.25773-1-ard.biesheuvel@linaro.org>
Some changes to the TCP fastopen code to make it more robust
against future changes in the choice of key/cookie size, etc.
- Instead of keeping the SipHash key in an untyped u8[] buffer
and casting it to the right type upon use, use the correct
type directly. This ensures that the key will appear at the
correct alignment if we ever change the way these data
structures are allocated. (Currently, they are only allocated
via kmalloc so they always appear at the correct alignment)
- Use DIV_ROUND_UP when sizing the u64[] array to hold the
cookie, so it is always of sufficient size, even if
TCP_FASTOPEN_COOKIE_MAX is no longer a multiple of 8.
- Drop the 'len' parameter from the tcp_fastopen_reset_cipher()
function, which is no longer used.
- Add endian swabbing when setting the keys and calculating the hash,
to ensure that cookie values are the same for a given key and
source/destination address pair regardless of the endianness of
the server.
Note that none of these are functional changes wrt the current
state of the code, with the exception of the swabbing, which only
affects big endian systems.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/tcp.h | 2 +-
include/net/tcp.h | 8 ++--
net/ipv4/sysctl_net_ipv4.c | 3 +-
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_fastopen.c | 39 +++++++++++---------
5 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 2689b0b0b68a..f3a85a7fb4b1 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -58,7 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
/* TCP Fast Open Cookie as stored in memory */
struct tcp_fastopen_cookie {
- u64 val[TCP_FASTOPEN_COOKIE_MAX / sizeof(u64)];
+ __le64 val[DIV_ROUND_UP(TCP_FASTOPEN_COOKIE_MAX, sizeof(u64))];
s8 len;
bool exp; /* In RFC6994 experimental option format */
};
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 573c9e9b0d72..9d36cc88d043 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,7 @@
#include <linux/seq_file.h>
#include <linux/memcontrol.h>
#include <linux/bpf-cgroup.h>
+#include <linux/siphash.h>
extern struct inet_hashinfo tcp_hashinfo;
@@ -1612,8 +1613,7 @@ void tcp_free_fastopen_req(struct tcp_sock *tp);
void tcp_fastopen_destroy_cipher(struct sock *sk);
void tcp_fastopen_ctx_destroy(struct net *net);
int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
- void *primary_key, void *backup_key,
- unsigned int len);
+ void *primary_key, void *backup_key);
void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb);
struct sock *tcp_try_fastopen(struct sock *sk, struct sk_buff *skb,
struct request_sock *req,
@@ -1623,14 +1623,14 @@ void tcp_fastopen_init_key_once(struct net *net);
bool tcp_fastopen_cookie_check(struct sock *sk, u16 *mss,
struct tcp_fastopen_cookie *cookie);
bool tcp_fastopen_defer_connect(struct sock *sk, int *err);
-#define TCP_FASTOPEN_KEY_LENGTH 16
+#define TCP_FASTOPEN_KEY_LENGTH sizeof(siphash_key_t)
#define TCP_FASTOPEN_KEY_MAX 2
#define TCP_FASTOPEN_KEY_BUF_LENGTH \
(TCP_FASTOPEN_KEY_LENGTH * TCP_FASTOPEN_KEY_MAX)
/* Fastopen key context */
struct tcp_fastopen_context {
- __u8 key[TCP_FASTOPEN_KEY_MAX][TCP_FASTOPEN_KEY_LENGTH];
+ siphash_key_t key[TCP_FASTOPEN_KEY_MAX];
int num;
struct rcu_head rcu;
};
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 7d802acde040..7d66306b5f39 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -365,8 +365,7 @@ static int proc_tcp_fastopen_key(struct ctl_table *table, int write,
}
}
tcp_fastopen_reset_cipher(net, NULL, key,
- backup_data ? key + 4 : NULL,
- TCP_FASTOPEN_KEY_LENGTH);
+ backup_data ? key + 4 : NULL);
}
bad_key:
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index efd7f2b1d1f0..47c217905864 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2822,8 +2822,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
if (optlen == TCP_FASTOPEN_KEY_BUF_LENGTH)
backup_key = key + TCP_FASTOPEN_KEY_LENGTH;
- return tcp_fastopen_reset_cipher(net, sk, key, backup_key,
- TCP_FASTOPEN_KEY_LENGTH);
+ return tcp_fastopen_reset_cipher(net, sk, key, backup_key);
}
default:
/* fallthru */
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 46b67128e1ca..4883b473bf53 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -7,7 +7,6 @@
#include <linux/tcp.h>
#include <linux/rcupdate.h>
#include <linux/rculist.h>
-#include <linux/siphash.h>
#include <net/inetpeer.h>
#include <net/tcp.h>
@@ -31,7 +30,7 @@ void tcp_fastopen_init_key_once(struct net *net)
* for a valid cookie, so this is an acceptable risk.
*/
get_random_bytes(key, sizeof(key));
- tcp_fastopen_reset_cipher(net, NULL, key, NULL, sizeof(key));
+ tcp_fastopen_reset_cipher(net, NULL, key, NULL);
}
static void tcp_fastopen_ctx_free(struct rcu_head *head)
@@ -68,8 +67,7 @@ void tcp_fastopen_ctx_destroy(struct net *net)
}
int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
- void *primary_key, void *backup_key,
- unsigned int len)
+ void *primary_key, void *backup_key)
{
struct tcp_fastopen_context *ctx, *octx;
struct fastopen_queue *q;
@@ -81,9 +79,15 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
goto out;
}
- memcpy(ctx->key[0], primary_key, len);
+ ctx->key[0] = (siphash_key_t){ {
+ get_unaligned_le64(primary_key),
+ get_unaligned_le64(primary_key + 8)
+ } };
if (backup_key) {
- memcpy(ctx->key[1], backup_key, len);
+ ctx->key[1] = (siphash_key_t){ {
+ get_unaligned_le64(backup_key),
+ get_unaligned_le64(backup_key + 8)
+ } };
ctx->num = 2;
} else {
ctx->num = 1;
@@ -110,19 +114,18 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
struct sk_buff *syn,
- const u8 *key,
+ const siphash_key_t *key,
struct tcp_fastopen_cookie *foc)
{
- BUILD_BUG_ON(TCP_FASTOPEN_KEY_LENGTH != sizeof(siphash_key_t));
BUILD_BUG_ON(TCP_FASTOPEN_COOKIE_SIZE != sizeof(u64));
if (req->rsk_ops->family == AF_INET) {
const struct iphdr *iph = ip_hdr(syn);
- foc->val[0] = siphash(&iph->saddr,
- sizeof(iph->saddr) +
- sizeof(iph->daddr),
- (const siphash_key_t *)key);
+ foc->val[0] = cpu_to_le64(siphash(&iph->saddr,
+ sizeof(iph->saddr) +
+ sizeof(iph->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -130,10 +133,10 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
if (req->rsk_ops->family == AF_INET6) {
const struct ipv6hdr *ip6h = ipv6_hdr(syn);
- foc->val[0] = siphash(&ip6h->saddr,
- sizeof(ip6h->saddr) +
- sizeof(ip6h->daddr),
- (const siphash_key_t *)key);
+ foc->val[0] = cpu_to_le64(siphash(&ip6h->saddr,
+ sizeof(ip6h->saddr) +
+ sizeof(ip6h->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -154,7 +157,7 @@ static void tcp_fastopen_cookie_gen(struct sock *sk,
rcu_read_lock();
ctx = tcp_fastopen_get_ctx(sk);
if (ctx)
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[0], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[0], foc);
rcu_read_unlock();
}
@@ -218,7 +221,7 @@ static int tcp_fastopen_cookie_gen_check(struct sock *sk,
if (!ctx)
goto out;
for (i = 0; i < tcp_fastopen_context_len(ctx); i++) {
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[i], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[i], foc);
if (tcp_fastopen_cookie_match(foc, orig)) {
ret = i + 1;
goto out;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v3 0/1] net: fastopen: follow-up tweaks for SipHash switch
From: Ard Biesheuvel @ 2019-06-19 21:27 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
Some fixes for the fastopen code after switching to SipHash, which were
spotted in review after the change had already been queued.
Changes since v2:
- add missing pairs of braces in compound literals used to assign the
fastopen keys
cc: Eric Biggers <ebiggers@kernel.org>
cc: linux-crypto@vger.kernel.org
cc: herbert@gondor.apana.org.au
cc: edumazet@google.com
cc: davem@davemloft.net
cc: kuznet@ms2.inr.ac.ru
cc: yoshfuji@linux-ipv6.org
cc: jbaron@akamai.com
cc: cpaasch@apple.com
cc: David.Laight@aculab.com
cc: ycheng@google.com
Ard Biesheuvel (1):
net: fastopen: robustness and endianness fixes for SipHash
include/linux/tcp.h | 2 +-
include/net/tcp.h | 8 ++--
net/ipv4/sysctl_net_ipv4.c | 3 +-
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_fastopen.c | 39 +++++++++++---------
5 files changed, 28 insertions(+), 27 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net-next 0/2] PCI: let pci_disable_link_state propagate errors
From: David Miller @ 2019-06-19 21:26 UTC (permalink / raw)
To: hkallweit1; +Cc: bhelgaas, nic_swsd, linux-pci, netdev
In-Reply-To: <5ea56278-05e2-794f-5f66-23343e72164c@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 18 Jun 2019 23:12:56 +0200
> Drivers like r8169 rely on pci_disable_link_state() having disabled
> certain ASPM link states. If OS can't control ASPM then
> pci_disable_link_state() turns into a no-op w/o informing the caller.
> The driver therefore may falsely assume the respective ASPM link
> states are disabled. Let pci_disable_link_state() propagate errors
> to the caller, enabling the caller to react accordingly.
>
> I'd propose to let this series go through the netdev tree if the PCI
> core extension is acked by the PCI people.
Bjorn et al., please look at patch #1 and ACK/NACK
Thank you.
^ permalink raw reply
* Re: [PATCH v2] net: mvpp2: debugfs: Add pmap to fs dump
From: David Miller @ 2019-06-19 21:20 UTC (permalink / raw)
To: nhuck; +Cc: maxime.chevallier, netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190619181715.253903-1-nhuck@google.com>
From: Nathan Huckleberry <nhuck@google.com>
Date: Wed, 19 Jun 2019 11:17:15 -0700
> There was an unused variable 'mvpp2_dbgfs_prs_pmap_fops'
> Added a usage consistent with other fops to dump pmap
> to userspace.
>
> Cc: clang-built-linux@googlegroups.com
> Link: https://github.com/ClangBuiltLinux/linux/issues/529
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: Default fib6_type to RTN_UNICAST when not set
From: David Miller @ 2019-06-19 21:15 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190619175024.17936-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Wed, 19 Jun 2019 10:50:24 -0700
> From: David Ahern <dsahern@gmail.com>
>
> A user reported that routes are getting installed with type 0 (RTN_UNSPEC)
> where before the routes were RTN_UNICAST. One example is from accel-ppp
> which apparently still uses the ioctl interface and does not set
> rtmsg_type. Another is the netlink interface where ipv6 does not require
> rtm_type to be set (v4 does). Prior to the commit in the Fixes tag the
> ipv6 stack converted type 0 to RTN_UNICAST, so restore that behavior.
>
> Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH] net: fddi: skfp: Include generic PCI definitions from pci_regs.h
From: David Miller @ 2019-06-19 21:12 UTC (permalink / raw)
To: puranjay12; +Cc: skhan, netdev, linux-kernel, bjorn, linux-kernel-mentees
In-Reply-To: <20190619174556.21194-1-puranjay12@gmail.com>
From: Puranjay Mohan <puranjay12@gmail.com>
Date: Wed, 19 Jun 2019 23:15:56 +0530
> Include the generic PCI definitions from include/uapi/linux/pci_regs.h
> change PCI_REV_ID to PCI_REVISION_ID to make it compatible with the
> generic define.
> This driver uses only one generic PCI define.
>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> ---
> drivers/net/fddi/skfp/drvfbi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/fddi/skfp/drvfbi.c b/drivers/net/fddi/skfp/drvfbi.c
> index bdd5700e71fa..38f6d943385d 100644
> --- a/drivers/net/fddi/skfp/drvfbi.c
> +++ b/drivers/net/fddi/skfp/drvfbi.c
> @@ -20,6 +20,7 @@
> #include "h/supern_2.h"
> #include "h/skfbiinc.h"
> #include <linux/bitrev.h>
> +#include <uapi/linux/pci_regs.h>
You never need to use "uapi/" in header includes from the kernel source,
please just use "linux/pci_regs.h"
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: act_ctinfo: tidy UAPI definition
From: David Miller @ 2019-06-19 21:11 UTC (permalink / raw)
To: ldir; +Cc: netdev
In-Reply-To: <20190619174109.55695-1-ldir@darbyshire-bryant.me.uk>
From: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Date: Wed, 19 Jun 2019 18:41:10 +0100
> Remove some enums from the UAPI definition that were only used
> internally and are NOT part of the UAPI.
>
> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Yeah, this is definitely the right thing to do.
Applied, thanks.
^ permalink raw reply
* [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Davide Caratti @ 2019-06-19 21:09 UTC (permalink / raw)
To: Vlad Buslov, David S. Miller, netdev; +Cc: Cong Wang, Lucas Bates
on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
In this situation, the following script:
# tc filter add dev eth0 ingress handle 0xffffffff flower action ok
# tc filter show dev eth0 ingress
results in an infinite loop. It happened also on other CPUs (e.g x86_64),
before commit 061775583e35 ("net: sched: flower: introduce reference
counting for filters"), because 'handle' + 1 made the u32 overflow before
it was assigned to 'cookie'; but that commit replaced the assignment with
a self-increment of 'cookie', so the problem was indirectly fixed.
Ensure not to call idr_get_next_ul() when 'cookie' contains an overflowed
value, and bail out of fl_walk() when its value is equal to ULONG_MAX.
While at it, add a TDC selftest that can be used to reproduce the problem.
test results (on 5.2.0-0.rc5.git0.1.fc31.i686)
unpatched (or affected) kernel:
# ./tdc.py -e 2ff3 -d dum0
Test 2ff3: Add flower with max handle and then dump it
All test results:
1..1
not ok 1 2ff3 - Add flower with max handle and then dump it
Could not match regex pattern. Verify command output:
Command "/sbin/tc filter show dev dum0 ingress" timed out
patched (or unaffected) kernel:
# ./tdc.py -e 2ff3 -d dum0
Test 2ff3: Add flower with max handle and then dump it
All test results:
1..1
ok 1 2ff3 - Add flower with max handle and then dump it
Fixes: 01683a146999 ("net: sched: refactor flower walk to iterate over idr")
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/cls_flower.c | 2 ++
.../tc-testing/tc-tests/filters/tests.json | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index eedd5786c084..acc86ae159f4 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -1702,6 +1702,8 @@ static void fl_walk(struct tcf_proto *tp, struct tcf_walker *arg,
break;
}
__fl_put(f);
+ if (arg->cookie == ULONG_MAX)
+ break;
arg->cookie++;
arg->count++;
}
diff --git a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
index e2f92cefb8d5..16559c436f21 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
@@ -38,6 +38,25 @@
"$TC qdisc del dev $DEV1 clsact"
]
},
+ {
+ "id": "2ff3",
+ "name": "Add flower with max handle and then dump it",
+ "category": [
+ "filter",
+ "flower"
+ ],
+ "setup": [
+ "$TC qdisc add dev $DEV2 ingress"
+ ],
+ "cmdUnderTest": "$TC filter add dev $DEV2 protocol ip pref 1 parent ffff: handle 0xffffffff flower action ok",
+ "expExitCode": "0",
+ "verifyCmd": "$TC filter show dev $DEV2 ingress",
+ "matchPattern": "filter protocol ip pref 1 flower.*handle 0xffffffff",
+ "matchCount": "1",
+ "teardown": [
+ "$TC qdisc del dev $DEV2 ingress"
+ ]
+ },
{
"id": "d052",
"name": "Add 1M filters with the same action",
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Dan Williams @ 2019-06-19 20:56 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg
Cc: Alex Elder, Subash Abhinov Kasiviswanathan, abhishek.esse,
Ben Chan, Bjorn Andersson, cpratapa, David Miller, DTML,
Eric Caruso, evgreen, Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking, syadagir
In-Reply-To: <CAK8P3a3r95gXMdq7s9GF=37v6t4kR+-2iyC6bnmUDVuM+bn80Q@mail.gmail.com>
On Tue, 2019-06-18 at 23:06 +0200, Arnd Bergmann wrote:
> On Tue, Jun 18, 2019 at 10:39 PM Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote:
> > It seems to me though that this is far more complex than what I'm
> > proposing? What I'm proposing there doesn't even need any userspace
> > involvement, as long as all the pieces are in the different sub-
> > drivers,
> > they'd fall out automatically.
> >
> > And realistically, the wwan_device falls out anyway at some point,
> > the
> > only question is if we really make one specific driver be the
> > "owner" of
> > it. I'm suggesting that we don't, and just make its lifetime depend
> > on
> > the links to parts it has (unless something like IPA actually wants
> > to
> > be an owner).
>
> My feeling so far is that having the wwan_device be owned by a device
> gives a nicer abstraction model that is also simpler for the common
> case. A device driver like ipa would end up with a probe() function
> that does does wwan_device_alloc/wwan_device_register, corresponding
> to alloc_etherdev/register_netdev, and then communicates through
> callbacks.
>
> I agree the compound device case would get more complex by
> shoehorning it into this model, but that can be a valid tradeoff
> if it's the exceptional case rather than the common one.
In my experience, the compound device model is by far the most
prevalent for regular Linux distros or anything *not* running on an SoC
with an integrated modem.
But it's also quite common for Android, no? drivers/net/ethernet/msm/
has rmnet and IPA ethernet drivers while arch/arm/mach-msm/ has various
SMD-related control channel drivers like smd_tty.c and smd_qmi.c and
smd_nmea.c. At least that's how I remember older SMD-based devices
being in the 8xxx and 9xxx time.
Ideally those setups can benefit from this framework as well, without
having to write entirely new composite drivers for those devices.
Dan
^ permalink raw reply
* Re: [PATCH v2] net: mvpp2: debugfs: Add pmap to fs dump
From: Nick Desaulniers @ 2019-06-19 20:46 UTC (permalink / raw)
To: Nathan Huckleberry
Cc: David S. Miller, maxime.chevallier, netdev, LKML,
clang-built-linux
In-Reply-To: <20190619181715.253903-1-nhuck@google.com>
On Wed, Jun 19, 2019 at 11:17 AM 'Nathan Huckleberry' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> There was an unused variable 'mvpp2_dbgfs_prs_pmap_fops'
> Added a usage consistent with other fops to dump pmap
> to userspace.
> Changes from v1 -> v2
> * Fix typo
> * Change commit prefix to debugfs
Compile-
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Requires `make ... W=1` before the patch to observe the warning.
> drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> index 0ee39ea47b6b..274fb07362cb 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> @@ -566,6 +566,9 @@ static int mvpp2_dbgfs_prs_entry_init(struct dentry *parent,
> debugfs_create_file("hits", 0444, prs_entry_dir, entry,
> &mvpp2_dbgfs_prs_hits_fops);
>
> + debugfs_create_file("pmap", 0444, prs_entry_dir, entry,
> + &mvpp2_dbgfs_prs_pmap_fops);
> +
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] bpf: optimize constant blinding
From: Jiong Wang @ 2019-06-19 20:45 UTC (permalink / raw)
To: Edward Cree, Alexei Starovoitov, Andrii Nakryiko
Cc: Jiong Wang, Naveen N. Rao, Daniel Borkmann, bpf,
Network Development, Michael Ellerman, Jakub Kicinski
In-Reply-To: <f2a74aac-7350-8b35-236a-b17323bb79e6@solarflare.com>
Edward Cree writes:
> On 17/06/2019 21:40, Jiong Wang wrote:
>> Now if we don't split patch when patch an insn inside patch, instead, if we
>> replace the patched insn using what you suggested, then the logic looks to
>> me becomes even more complex, something like
>>
>> for (idx = 0; idx < insn_cnt; idx++) {
>> if (insns[idx] is not BPF_LIST_INSN) {
>> do_insn(...)
>> }
>> else if (insns[idx] is BPF_LIST_INSN) {
>> list = pool_base + insn.imm;
>> while (list) {
>> insn = list_head->insn;
>> if (insn is BF_LIST_INSN) {
>> sub_list = ...
>> while ()
>> do_insn()
>> continue;
>> }
>> do_insn(...)
>> list = pool_base + list->next;
>> }
>> }
>> }
> Why can't do_insn() just go like:
> if (insn is BPF_LIST_INSN)
> for (idx = 0; idx < LIST_COUNT(insn); idx++)
> do_insn(pool_base + LIST_START(insn) + idx);
> else
> rest of processing
> ?
>
> Alternatively, iterate with something more sophisticated than 'idx++'
> (standard recursion-to-loop transformation).
> You shouldn't ever need a for() tower statically in the code...
I don't think this changes things much, the point is we still have two data
structures for insns, array + list, so I fell you anyway need some tweak on
existing traverse code while using singly linked list incurs very little
changes, for example:
for (i = 0; i < insn_cnt; i++, insn++) {
=>
for (elem = list; elem; elem = elem->next) {
insn = elem->insn;
>> So, I am thinking what Alexei and Andrii suggested make sense, just use
>> single data structure (singly linked list) to represent everything, so the
>> insn traversal etc could be simple
> But then you have to also store orig_insn_idx with each insn, so you can
> calculate the new jump offsets when you linearise. Having an array of
> patched_orig_insns gives you that for free.
For pool based list, you don't need to store orig_insn_idx, those orig ones
are guaranteed at the bottom of the pool, so just use index < orig_prog_len
then you could know it is the orig insn. And for both pool and non-pool
based list, the order of orig node in the list is the same as in array, so
it quite easy to calculate the orig index as a by-product inside insn copy
traverse, for non-pool base list, each node needs at least one bit to
indicate it is orig node. I also found when patching a patched buffer which
contains jmp insn is an issue (need to double check to see if there is such
case), because then we will need to record the jump destination index of
the jmp insn when it was inserted.
And some updates on my side, did some benchmarking on both pool and
non-pool based list.
Patching time (ns) benchmarked using JIT blinding
===
existing non-pool pool
"scale test 1" no stop ~0x1c600000 ~0x8800000
Bench(~3.4K insns) ~0xc50000 ~0xf1000 ~6b000
(The non-pool means kmalloc a list node for each patch snippet, pool means
vmalloc a big chunk of mem and allocate node from it, node is located using
pool_base + index)
For "scale test 1" which contains ~1M JIT blindable insns, using list based
infra for patching could reduce most of the patching time, and pool based
alloc only consumes 1/3 time of non-pool.
And for a normal program with reasonable size (~3.4K), pool based alloc
only consumes 1/30 time of exsisting infra, and 1/2.3 of non-pool.
On the other hand, non-pool based implementation is cleaner and less error
prone than pool based implementation.
And for both pool and non-pool, I got the following kernel warning when
running "scale test 11" (perhaps needs 3M * 16 ~= 48M mem)
[ 92.319792] WARNING: CPU: 6 PID: 2322 at mm/page_alloc.c:4639 __alloc_pages_nodemask+0x29e/0x330
I am finishing aux adjust and code delete support.
Regards,
Jiong
^ permalink raw reply
* Re: [PATCH v3 06/16] dt-bindings: net: sun4i-emac: Convert the binding to a schemas
From: Rob Herring @ 2019-06-19 20:44 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <CAL_Jsq+A+jspyCpu9USL6FQ9y5qL_yqYS=DTE=aM5YzyeZwd0w@mail.gmail.com>
On Wed, Jun 19, 2019 at 8:46 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Jun 19, 2019 at 3:48 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Switch our Allwinner A10 EMAC controller binding to a YAML schema to enable
> > the DT validation.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >
> > ---
> >
> > Changes from v2:
> > - Switch from the deprecated phy property to phy-handle
> > ---
> > Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt | 19 -------------------
> > 2 files changed, 55 insertions(+), 19 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
> > delete mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
> > new file mode 100644
> > index 000000000000..2ff9e605cd26
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
> > @@ -0,0 +1,55 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/allwinner,sun4i-a10-emac.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Allwinner A10 EMAC Ethernet Controller Device Tree Bindings
> > +
> > +allOf:
> > + - $ref: "ethernet-controller.yaml#"
> > +
> > +maintainers:
> > + - Chen-Yu Tsai <wens@csie.org>
> > + - Maxime Ripard <maxime.ripard@bootlin.com>
> > +
> > +properties:
> > + compatible:
> > + const: allwinner,sun4i-a10-emac
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + allwinner,sram:
> > + description: Phandle to the device SRAM
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - phy-handle
>
> Doesn't this throw an error if not listed in properties?
NM, it doesn't.
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ 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