* [PATCH net-next] net: init sk_cookie for inet socket
From: Yafang Shao @ 2018-04-22 13:50 UTC (permalink / raw)
To: eric.dumazet, alexei.starovoitov, davem; +Cc: netdev, linux-kernel, Yafang Shao
With sk_cookie we can identify a socket, that is very helpful for
traceing and statistic, i.e. tcp tracepiont and ebpf.
So we'd better init it by default for inet socket.
When using it, we just need call atomic64_read(&sk->sk_cookie).
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/linux/sock_diag.h | 9 +++++++++
net/ipv4/tcp_input.c | 8 +++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 15fe980..5c916e6 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -25,6 +25,15 @@ struct sock_diag_handler {
void sock_diag_register_inet_compat(int (*fn)(struct sk_buff *skb, struct nlmsghdr *nlh));
void sock_diag_unregister_inet_compat(int (*fn)(struct sk_buff *skb, struct nlmsghdr *nlh));
+static inline
+void sock_init_cookie(struct sock *sk)
+{
+ u64 res;
+
+ res = atomic64_inc_return(&sock_net(sk)->cookie_gen);
+ atomic64_set(&sk->sk_cookie, res);
+}
+
u64 sock_gen_cookie(struct sock *sk);
int sock_diag_check_cookie(struct sock *sk, const __u32 *cookie);
void sock_diag_save_cookie(struct sock *sk, __u32 *cookie);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0396fb9..e6a64a3 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -78,6 +78,7 @@
#include <linux/errqueue.h>
#include <trace/events/tcp.h>
#include <linux/static_key.h>
+#include <linux/sock_diag.h>
int sysctl_tcp_max_orphans __read_mostly = NR_FILE;
@@ -6188,10 +6189,15 @@ struct request_sock *inet_reqsk_alloc(const struct request_sock_ops *ops,
#if IS_ENABLED(CONFIG_IPV6)
ireq->pktopts = NULL;
#endif
- atomic64_set(&ireq->ir_cookie, 0);
ireq->ireq_state = TCP_NEW_SYN_RECV;
write_pnet(&ireq->ireq_net, sock_net(sk_listener));
ireq->ireq_family = sk_listener->sk_family;
+
+ BUILD_BUG_ON(offsetof(struct inet_request_sock, ir_cookie) !=
+ offsetof(struct sock, sk_cookie));
+ BUILD_BUG_ON(offsetof(struct inet_request_sock, ireq_net) !=
+ offsetof(struct sock, sk_net));
+ sock_init_cookie((struct sock *)ireq);
}
return req;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
From: Michal Hocko @ 2018-04-22 13:03 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mikulas Patocka, David Miller, Andrew Morton, linux-mm,
eric.dumazet, edumazet, bhutchings, netdev, linux-kernel, mst,
jasowang, virtualization, dm-devel, Vlastimil Babka
In-Reply-To: <20180421144757.GC14610@bombadil.infradead.org>
On Sat 21-04-18 07:47:57, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > No way. This is just wrong! First of all, you will explode most likely
> > > > > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be
> > > > > enabled quite often.
> > > >
> > > > You're an evil person who doesn't want to fix bugs.
> > >
> > > Steady on. There's no need for that. Michal isn't evil. Please
> > > apologise.
> >
> > I see this attitude from Michal again and again.
>
> Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes
> I agree with him, sometimes I don't. I think he genuinely wants the best
> code in the kernel, and saying "No" is part of it.
Exactly! We have a lot of legacy herritage and random semantic because
we were too eager to merge stuff. I think it is time to stop that and
think twice before merging someothing. If you call that evil then I am
fine to be evil.
> > He didn't want to fix vmalloc(GFP_NOIO)
>
> I don't remember that conversation, so I don't know whether I agree with
> his reasoning or not. But we are supposed to be moving away from GFP_NOIO
> towards marking regions with memalloc_noio_save() / restore. If you do
> that, you won't need vmalloc(GFP_NOIO).
It was basically to detect GFP_NOIO context _inside_ vmalloc and use the
scope API to enforce it there. Does it solve potential problems? Yes it
does. Does it solve any existing report, no I am not aware of any. Is
it a good fix longterm? Absolutely no, because the scope API should be
used _at the place_ where the scope starts rather than a random utility
function. If we are going the easier way now, we will never teach users
to use the API properly. And I am willing to risk to keep a broken
code which we have for years rather than allow a random hack that will
seemingly fix it.
Btw. I was pretty much explicit with this reasoning when rejecting the
patch. Do you still call that evil?
> > he didn't want to fix alloc_pages sleeping when __GFP_NORETRY is used.
>
> The GFP flags are a mess, still.
I do not remember that one but __GFP_NORETRY is _allowed_ to sleep. And
yes I do _agree_ gfp flags are a mess which is really hard to get fixed
because they are lacking a good design from the very beginning. Fixing
some of those issues today is a completely PITA.
> > So what should I say? Fix them and
> > you won't be evil :-)
>
> No, you should reserve calling somebody evil for truly evil things.
>
> > (he could also fix the oom killer, so that it is triggered when
> > free_memory+cache+free_swap goes beyond a threshold and not when you loop
> > too long in the allocator)
>
> ... that also doesn't make somebody evil.
And again, it is way much more easier to claim that something will get
fixed when the reality is much more complicated. I've tried to explain
those risks as well.
> > I already said that we can change it from CONFIG_DEBUG_VM to
> > CONFIG_DEBUG_SG - or to whatever other option you may want, just to make
> > sure that it is enabled in distro debug kernels by default.
>
> Yes, and I think that's the right idea. So send a v2 and ignore the
> replies that are clearly relating to an earlier version of the patch.
> Not everybody reads every mail in the thread before responding to one they
> find interesting. Yes, ideally, one would, but sometimes one doesn't.
And look here. This is yet another ad-hoc idea. We have many users of
kvmalloc which have no relation to SG, yet you are going to control
their behavior by CONFIG_DEBUG_SG? No way! (yeah evil again)
Really, we have a fault injection framework and this sounds like
something to hook in there.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Woody Suwalski @ 2018-04-22 12:19 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, kernel list, Linux-pm mailing list,
Netdev list
In-Reply-To: <20180415161551.GF10802@amd>
Pavel Machek wrote:
> On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:
>> Woody Suwalski wrote:
>>> Pavel Machek wrote:
>>>> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
>>>>> Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>> With recent linux-next, after resume networkmanager often claims that
>>>>>> "network is disabled". Sometimes suspend/resume clears that.
>>>>>>
>>>>>> Any ideas? Does it work for you?
>>>>>> Pavel
>>>>> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
>>>> Thanks for testing... but yes, 4.16 should be ok. If not fixed,
>>>> problem will appear in 4.17-rc1.
>>>>
>>> Works here OK. Tried ~10 suspends, all restarted OK.
>>> kernel next-20180320
>>> nmcli shows that Wifi always connects OK
>>>
>>> Woody
>>>
>> Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
>> I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
>> hibernate results in a message:
>> Failed to hibernate system via logind: There's already a shutdown or sleep
>> operation in progress.
>>
>> And ps shows "Ds /lib/systemd/systemd-sleep suspend"...
> Problem now seems to be in the mainline.
>
> But no, I don't see systemd-sleep in my process list :-(.
>
> I guess you can't reproduce it easily? I tried bisecting, but while it
> happens often enough to make v4.17 hard to use, it does not permit
> reliable bisect.
>
> These should be bad according to my notes
>
> b04240a33b99b32cf6fbdf5c943c04e505a0cb07
> ed80dc19e4dd395c951f745acd1484d61c4cfb20
> 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
> 4fc97ef94bbfa185d16b3e44199b7559d0668747
> 14ebdb2c814f508936fe178a2abc906a16a3ab48
> 639adbeef5ae1bb8eeebbb0cde0b885397bde192
>
> bisection claimed
>
> c16add24522547bf52c189b3c0d1ab6f5c2b4375
>
> is first bad commit, but I'm not sure if I trust that.
> Pavel
It has not happen on any of my systems in the last month. Good, but bad
for getting more info :-(
Woody
^ permalink raw reply
* [net-next:master 211/214] net/ipv6/route.c:3357:41: sparse: incorrect type in argument 2 (different address spaces)
From: kbuild test robot @ 2018-04-22 11:57 UTC (permalink / raw)
To: David Ahern; +Cc: kbuild-all, netdev
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: e0ada51db907ed2db5d46ad7ff86a8b5df68e59b
commit: a68886a691804d3f6d479ebf6825480fbafb6a00 [211/214] net/ipv6: Make from in rt6_info rcu protected
reproduce:
# apt-get install sparse
git checkout a68886a691804d3f6d479ebf6825480fbafb6a00
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/ipv6/route.c:2584:15: sparse: expression using sizeof(void)
>> net/ipv6/route.c:3357:41: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct fib6_info *ort @@ got struct fib6_info struct fib6_info *ort @@
net/ipv6/route.c:3357:41: expected struct fib6_info *ort
net/ipv6/route.c:3357:41: got struct fib6_info [noderef] <asn:4>*from
net/ipv6/route.c:1391:15: sparse: expression using sizeof(void)
>> net/ipv6/route.c:1544:36: sparse: incorrect type in initializer (different address spaces) @@ expected struct fib6_info *from @@ got struct fib6_info struct fib6_info *from @@
net/ipv6/route.c:1544:36: expected struct fib6_info *from
net/ipv6/route.c:1544:36: got struct fib6_info [noderef] <asn:4>*from
net/ipv6/route.c:1589:36: sparse: incorrect type in initializer (different address spaces) @@ expected struct fib6_info *from @@ got struct fib6_info struct fib6_info *from @@
net/ipv6/route.c:1589:36: expected struct fib6_info *from
net/ipv6/route.c:1589:36: got struct fib6_info [noderef] <asn:4>*from
net/ipv6/route.c:1962:39: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [unsigned] [usertype] flow_label @@ got gned] [usertype] flow_label @@
net/ipv6/route.c:1962:39: expected unsigned int [unsigned] [usertype] flow_label
net/ipv6/route.c:1962:39: got restricted __be32
net/ipv6/route.c:2304:15: sparse: expression using sizeof(void)
net/ipv6/route.c:3189:12: sparse: context imbalance in 'ip6_route_del' - wrong count at exit
vim +3357 net/ipv6/route.c
^1da177e4 Linus Torvalds 2005-04-16 3250
6700c2709 David S. Miller 2012-07-17 3251 static void rt6_do_redirect(struct dst_entry *dst, struct sock *sk, struct sk_buff *skb)
a6279458c YOSHIFUJI Hideaki 2006-08-23 3252 {
a6279458c YOSHIFUJI Hideaki 2006-08-23 3253 struct netevent_redirect netevent;
e8599ff4b David S. Miller 2012-07-11 3254 struct rt6_info *rt, *nrt = NULL;
e8599ff4b David S. Miller 2012-07-11 3255 struct ndisc_options ndopts;
e8599ff4b David S. Miller 2012-07-11 3256 struct inet6_dev *in6_dev;
e8599ff4b David S. Miller 2012-07-11 3257 struct neighbour *neigh;
a68886a69 David Ahern 2018-04-20 3258 struct fib6_info *from;
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3259 struct rd_msg *msg;
6e157b6ac David S. Miller 2012-07-12 3260 int optlen, on_link;
6e157b6ac David S. Miller 2012-07-12 3261 u8 *lladdr;
e8599ff4b David S. Miller 2012-07-11 3262
29a3cad5c Simon Horman 2013-05-28 3263 optlen = skb_tail_pointer(skb) - skb_transport_header(skb);
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3264 optlen -= sizeof(*msg);
e8599ff4b David S. Miller 2012-07-11 3265
e8599ff4b David S. Miller 2012-07-11 3266 if (optlen < 0) {
6e157b6ac David S. Miller 2012-07-12 3267 net_dbg_ratelimited("rt6_do_redirect: packet too short\n");
e8599ff4b David S. Miller 2012-07-11 3268 return;
e8599ff4b David S. Miller 2012-07-11 3269 }
e8599ff4b David S. Miller 2012-07-11 3270
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3271 msg = (struct rd_msg *)icmp6_hdr(skb);
e8599ff4b David S. Miller 2012-07-11 3272
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3273 if (ipv6_addr_is_multicast(&msg->dest)) {
6e157b6ac David S. Miller 2012-07-12 3274 net_dbg_ratelimited("rt6_do_redirect: destination address is multicast\n");
e8599ff4b David S. Miller 2012-07-11 3275 return;
e8599ff4b David S. Miller 2012-07-11 3276 }
e8599ff4b David S. Miller 2012-07-11 3277
6e157b6ac David S. Miller 2012-07-12 3278 on_link = 0;
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3279 if (ipv6_addr_equal(&msg->dest, &msg->target)) {
e8599ff4b David S. Miller 2012-07-11 3280 on_link = 1;
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3281 } else if (ipv6_addr_type(&msg->target) !=
e8599ff4b David S. Miller 2012-07-11 3282 (IPV6_ADDR_UNICAST|IPV6_ADDR_LINKLOCAL)) {
6e157b6ac David S. Miller 2012-07-12 3283 net_dbg_ratelimited("rt6_do_redirect: target address is not link-local unicast\n");
e8599ff4b David S. Miller 2012-07-11 3284 return;
e8599ff4b David S. Miller 2012-07-11 3285 }
e8599ff4b David S. Miller 2012-07-11 3286
e8599ff4b David S. Miller 2012-07-11 3287 in6_dev = __in6_dev_get(skb->dev);
e8599ff4b David S. Miller 2012-07-11 3288 if (!in6_dev)
e8599ff4b David S. Miller 2012-07-11 3289 return;
e8599ff4b David S. Miller 2012-07-11 3290 if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_redirects)
e8599ff4b David S. Miller 2012-07-11 3291 return;
e8599ff4b David S. Miller 2012-07-11 3292
e8599ff4b David S. Miller 2012-07-11 3293 /* RFC2461 8.1:
e8599ff4b David S. Miller 2012-07-11 3294 * The IP source address of the Redirect MUST be the same as the current
e8599ff4b David S. Miller 2012-07-11 3295 * first-hop router for the specified ICMP Destination Address.
e8599ff4b David S. Miller 2012-07-11 3296 */
e8599ff4b David S. Miller 2012-07-11 3297
f997c55c1 Alexander Aring 2016-06-15 3298 if (!ndisc_parse_options(skb->dev, msg->opt, optlen, &ndopts)) {
e8599ff4b David S. Miller 2012-07-11 3299 net_dbg_ratelimited("rt6_redirect: invalid ND options\n");
e8599ff4b David S. Miller 2012-07-11 3300 return;
e8599ff4b David S. Miller 2012-07-11 3301 }
6e157b6ac David S. Miller 2012-07-12 3302
6e157b6ac David S. Miller 2012-07-12 3303 lladdr = NULL;
e8599ff4b David S. Miller 2012-07-11 3304 if (ndopts.nd_opts_tgt_lladdr) {
e8599ff4b David S. Miller 2012-07-11 3305 lladdr = ndisc_opt_addr_data(ndopts.nd_opts_tgt_lladdr,
e8599ff4b David S. Miller 2012-07-11 3306 skb->dev);
e8599ff4b David S. Miller 2012-07-11 3307 if (!lladdr) {
e8599ff4b David S. Miller 2012-07-11 3308 net_dbg_ratelimited("rt6_redirect: invalid link-layer address length\n");
e8599ff4b David S. Miller 2012-07-11 3309 return;
e8599ff4b David S. Miller 2012-07-11 3310 }
e8599ff4b David S. Miller 2012-07-11 3311 }
e8599ff4b David S. Miller 2012-07-11 3312
6e157b6ac David S. Miller 2012-07-12 3313 rt = (struct rt6_info *) dst;
ec13ad1d7 Matthias Schiffer 2015-11-02 3314 if (rt->rt6i_flags & RTF_REJECT) {
6e157b6ac David S. Miller 2012-07-12 3315 net_dbg_ratelimited("rt6_redirect: source isn't a valid nexthop for redirect target\n");
e8599ff4b David S. Miller 2012-07-11 3316 return;
6e157b6ac David S. Miller 2012-07-12 3317 }
e8599ff4b David S. Miller 2012-07-11 3318
6e157b6ac David S. Miller 2012-07-12 3319 /* Redirect received -> path was valid.
6e157b6ac David S. Miller 2012-07-12 3320 * Look, redirects are sent only in response to data packets,
6e157b6ac David S. Miller 2012-07-12 3321 * so that this nexthop apparently is reachable. --ANK
6e157b6ac David S. Miller 2012-07-12 3322 */
0dec879f6 Julian Anastasov 2017-02-06 3323 dst_confirm_neigh(&rt->dst, &ipv6_hdr(skb)->saddr);
a6279458c YOSHIFUJI Hideaki 2006-08-23 3324
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3325 neigh = __neigh_lookup(&nd_tbl, &msg->target, skb->dev, 1);
6e157b6ac David S. Miller 2012-07-12 3326 if (!neigh)
6e157b6ac David S. Miller 2012-07-12 3327 return;
a6279458c YOSHIFUJI Hideaki 2006-08-23 3328
^1da177e4 Linus Torvalds 2005-04-16 3329 /*
^1da177e4 Linus Torvalds 2005-04-16 3330 * We have finally decided to accept it.
^1da177e4 Linus Torvalds 2005-04-16 3331 */
^1da177e4 Linus Torvalds 2005-04-16 3332
f997c55c1 Alexander Aring 2016-06-15 3333 ndisc_update(skb->dev, neigh, lladdr, NUD_STALE,
^1da177e4 Linus Torvalds 2005-04-16 3334 NEIGH_UPDATE_F_WEAK_OVERRIDE|
^1da177e4 Linus Torvalds 2005-04-16 3335 NEIGH_UPDATE_F_OVERRIDE|
^1da177e4 Linus Torvalds 2005-04-16 3336 (on_link ? 0 : (NEIGH_UPDATE_F_OVERRIDE_ISROUTER|
f997c55c1 Alexander Aring 2016-06-15 3337 NEIGH_UPDATE_F_ISROUTER)),
f997c55c1 Alexander Aring 2016-06-15 3338 NDISC_REDIRECT, &ndopts);
^1da177e4 Linus Torvalds 2005-04-16 3339
4d85cd0c2 David Ahern 2018-04-20 3340 rcu_read_lock();
a68886a69 David Ahern 2018-04-20 3341 from = rcu_dereference(rt->from);
a68886a69 David Ahern 2018-04-20 3342 nrt = ip6_rt_cache_alloc(from, &msg->dest, NULL);
4d85cd0c2 David Ahern 2018-04-20 3343 rcu_read_unlock();
383084739 David S. Miller 2011-12-03 3344 if (!nrt)
^1da177e4 Linus Torvalds 2005-04-16 3345 goto out;
^1da177e4 Linus Torvalds 2005-04-16 3346
^1da177e4 Linus Torvalds 2005-04-16 3347 nrt->rt6i_flags = RTF_GATEWAY|RTF_UP|RTF_DYNAMIC|RTF_CACHE;
^1da177e4 Linus Torvalds 2005-04-16 3348 if (on_link)
^1da177e4 Linus Torvalds 2005-04-16 3349 nrt->rt6i_flags &= ~RTF_GATEWAY;
^1da177e4 Linus Torvalds 2005-04-16 3350
4e3fd7a06 Alexey Dobriyan 2011-11-21 3351 nrt->rt6i_gateway = *(struct in6_addr *)neigh->primary_key;
^1da177e4 Linus Torvalds 2005-04-16 3352
2b760fcf5 Wei Wang 2017-10-06 3353 /* No need to remove rt from the exception table if rt is
2b760fcf5 Wei Wang 2017-10-06 3354 * a cached route because rt6_insert_exception() will
2b760fcf5 Wei Wang 2017-10-06 3355 * takes care of it
2b760fcf5 Wei Wang 2017-10-06 3356 */
d4ead6b34 David Ahern 2018-04-17 @3357 if (rt6_insert_exception(nrt, rt->from)) {
2b760fcf5 Wei Wang 2017-10-06 3358 dst_release_immediate(&nrt->dst);
2b760fcf5 Wei Wang 2017-10-06 3359 goto out;
2b760fcf5 Wei Wang 2017-10-06 3360 }
^1da177e4 Linus Torvalds 2005-04-16 3361
d8d1f30b9 Changli Gao 2010-06-10 3362 netevent.old = &rt->dst;
d8d1f30b9 Changli Gao 2010-06-10 3363 netevent.new = &nrt->dst;
71bcdba06 YOSHIFUJI Hideaki / 吉藤英明 2013-01-05 3364 netevent.daddr = &msg->dest;
605928337 YOSHIFUJI Hideaki / 吉藤英明 2013-01-14 3365 netevent.neigh = neigh;
8d71740c5 Tom Tucker 2006-07-30 3366 call_netevent_notifiers(NETEVENT_REDIRECT, &netevent);
8d71740c5 Tom Tucker 2006-07-30 3367
^1da177e4 Linus Torvalds 2005-04-16 3368 out:
e8599ff4b David S. Miller 2012-07-11 3369 neigh_release(neigh);
6e157b6ac David S. Miller 2012-07-12 3370 }
6e157b6ac David S. Miller 2012-07-12 3371
:::::: The code at line 3357 was first introduced by commit
:::::: d4ead6b34b67fd711639324b6465a050bcb197d4 net/ipv6: move metrics from dst to rt6_info
:::::: TO: David Ahern <dsahern@gmail.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache
From: Paolo Abeni @ 2018-04-22 11:22 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Eric Dumazet, Willem de Bruijn
Cc: netdev, David S. Miller, Tariq Toukan
In-Reply-To: <20180420154836.3690a39e@redhat.com>
On Fri, 2018-04-20 at 15:48 +0200, Jesper Dangaard Brouer wrote:
> On Thu, 19 Apr 2018 06:47:10 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On 04/19/2018 12:40 AM, Paolo Abeni wrote:
> > > On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote:
> > > > On 04/18/2018 10:15 AM, Paolo Abeni wrote:
>
> [...]
> > >
> > > Any suggestions for better results are more than welcome!
> >
> > Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in
> > Seoul (netdev conference). Not tied to UDP, but a generic solution.
>
> Yes, I remember. I think... was it the idea, where you basically
> wanted to queue back SKBs to the CPU that allocated them, right?
>
> Freeing an SKB on the same CPU that allocated it, have multiple
> advantages. (1) the SLUB allocator can use a non-atomic
> "cpu-local" (double)cmpxchg. (2) the 4 cache-lines memset cleared of
> the SKB stay local. (3) the atomic SKB refcnt/users stay local.
By the time the skb is returned to the ingress cpu, isn't that skb most
probably out of the cache?
> We just have to avoid that queue back SKB's mechanism, doesn't cost
> more than the operations we expect to save. Bulk transfer is an
> obvious approach. For storing SKBs until they are returned, we already
> have a fast mechanism see napi_consume_skb calling _kfree_skb_defer,
> which SLUB/SLAB-bulk free to amortize cost (1).
>
> I guess, the missing information is that we don't know what CPU the SKB
> were created on...
>
> Where to store this CPU info?
>
> (a) In struct sk_buff, in a cache-line that is already read on remote
> CPU in UDP code?
>
> (b) In struct page, as SLUB alloc hand-out objects/SKBs on a per page
> basis, we could have SLUB store a hint about the CPU it was allocated
> on, and bet on returning to that CPU ? (might be bad to read the
> struct-page cache-line)
Bulking would be doable only for connected sockets, elsewhere would be
difficult to assemble a burst long enough to amortize the handshake
with the remote CPU (spinlock + ipi needed ?!?)
Would be good enough for unconnected sockets sending a whole skb burst
back to one of the (several) ingress CPU? e.g. peeking the CPU
associated with the first skb inside the burst, we would somewhat
balance the load between the ingress CPUs.
Cheers,
Paolo
^ permalink raw reply
* [PATCH net] bonding: do not set slave_dev npinfo before slave_enable_netpoll in bond_enslave
From: Xin Long @ 2018-04-22 11:11 UTC (permalink / raw)
To: network dev; +Cc: davem, Andy Gospodarek, Jiri Pirko, Cong Wang
After Commit 8a8efa22f51b ("bonding: sync netpoll code with bridge"), it
would set slave_dev npinfo in slave_enable_netpoll when enslaving a dev
if bond->dev->npinfo was set.
However now slave_dev npinfo is set with bond->dev->npinfo before calling
slave_enable_netpoll. With slave_dev npinfo set, __netpoll_setup called
in slave_enable_netpoll will not call slave dev's .ndo_netpoll_setup().
It causes that the lower dev of this slave dev can't set its npinfo.
One way to reproduce it:
# modprobe bonding
# brctl addbr br0
# brctl addif br0 eth1
# ifconfig bond0 192.168.122.1/24 up
# ifenslave bond0 eth2
# systemctl restart netconsole
# ifenslave bond0 br0
# ifconfig eth2 down
# systemctl restart netconsole
The netpoll won't really work.
This patch is to remove that slave_dev npinfo setting in bond_enslave().
Fixes: 8a8efa22f51b ("bonding: sync netpoll code with bridge")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/bonding/bond_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b7b1130..718e491 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1660,8 +1660,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
} /* switch(bond_mode) */
#ifdef CONFIG_NET_POLL_CONTROLLER
- slave_dev->npinfo = bond->dev->npinfo;
- if (slave_dev->npinfo) {
+ if (bond->dev->npinfo) {
if (slave_enable_netpoll(new_slave)) {
netdev_info(bond_dev, "master_dev is using netpoll, but new slave device does not support netpoll\n");
res = -EBUSY;
--
2.1.0
^ permalink raw reply related
* [PATCH net] team: check team dev npinfo when adding a port only
From: Xin Long @ 2018-04-22 11:08 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko, stephen hemminger
Now when netconsole sets up netpoll on a team dev, __netpoll_setup
will invoke team dev's .ndo_netpoll_setup first, then set
team->dev->npinfo.
However Commit 0fb52a27a04a ("team: cleanup netpoll clode") added
!team->dev->npinfo check in team_port_enable_netpoll(), which is
also invoked by team dev's .ndo_netpoll_setup. It will cause that
port dev npinfo can't be set due to team->dev->npinfo is not yet
set before invoking team dev's .ndo_netpoll_setup.
Team dev only needs to check team->dev->npinfo for setting a port
dev npinfo when adding the port, like before that cleanup.
Fixes: 0fb52a27a04a ("team: cleanup netpoll clode")
Reported-by: João Avelino Bellomo Filho <jbellomo@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/team/team.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index acbe849..f4a0346 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1077,9 +1077,6 @@ static int team_port_enable_netpoll(struct team *team, struct team_port *port)
struct netpoll *np;
int err;
- if (!team->dev->npinfo)
- return 0;
-
np = kzalloc(sizeof(*np), GFP_KERNEL);
if (!np)
return -ENOMEM;
@@ -1221,11 +1218,13 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
goto err_vids_add;
}
- err = team_port_enable_netpoll(team, port);
- if (err) {
- netdev_err(dev, "Failed to enable netpoll on device %s\n",
- portname);
- goto err_enable_netpoll;
+ if (team->dev->npinfo) {
+ err = team_port_enable_netpoll(team, port);
+ if (err) {
+ netdev_err(dev, "Failed to enable netpoll on device %s\n",
+ portname);
+ goto err_enable_netpoll;
+ }
}
if (!(dev->features & NETIF_F_LRO))
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need
From: Hans Verkuil @ 2018-04-22 11:06 UTC (permalink / raw)
To: Robert Jarzmik, Daniel Mack, Haojian Zhuang,
Bartlomiej Zolnierkiewicz, Tejun Heo, Vinod Koul,
Mauro Carvalho Chehab, Ulf Hansson, Ezequiel Garcia,
Boris Brezillon, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Nicolas Pitre, Samuel Ortiz,
Greg Kroah-Hartman, Jaroslav Kysela, Takashi Iwai, Liam Girdwood,
Mark Brown, A
Cc: devel, alsa-devel, netdev, linux-mmc, linux-kernel, linux-ide,
linux-mtd, dmaengine, Niklas Söderlund, linux-arm-kernel,
linux-media
In-Reply-To: <20180402142656.26815-5-robert.jarzmik@free.fr>
On 04/02/2018 04:26 PM, Robert Jarzmik wrote:
> From: Robert Jarzmik <robert.jarzmik@renault.com>
>
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
>
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Regards,
Hans
> ---
> drivers/media/platform/pxa_camera.c | 22 +++-------------------
> 1 file changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
> index c71a00736541..4c82d1880753 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device *pdev)
> .src_maxburst = 8,
> .direction = DMA_DEV_TO_MEM,
> };
> - dma_cap_mask_t mask;
> - struct pxad_param params;
> char clk_name[V4L2_CLK_NAME_SIZE];
> int irq;
> int err = 0, i;
> @@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device *pdev)
> pcdev->base = base;
>
> /* request dma */
> - dma_cap_zero(mask);
> - dma_cap_set(DMA_SLAVE, mask);
> - dma_cap_set(DMA_PRIVATE, mask);
> -
> - params.prio = 0;
> - params.drcmr = 68;
> - pcdev->dma_chans[0] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> - ¶ms, &pdev->dev, "CI_Y");
> + pcdev->dma_chans[0] = dma_request_slave_channel(&pdev->dev, "CI_Y");
> if (!pcdev->dma_chans[0]) {
> dev_err(&pdev->dev, "Can't request DMA for Y\n");
> return -ENODEV;
> }
>
> - params.drcmr = 69;
> - pcdev->dma_chans[1] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> - ¶ms, &pdev->dev, "CI_U");
> + pcdev->dma_chans[1] = dma_request_slave_channel(&pdev->dev, "CI_U");
> if (!pcdev->dma_chans[1]) {
> dev_err(&pdev->dev, "Can't request DMA for Y\n");
> err = -ENODEV;
> goto exit_free_dma_y;
> }
>
> - params.drcmr = 70;
> - pcdev->dma_chans[2] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> - ¶ms, &pdev->dev, "CI_V");
> + pcdev->dma_chans[2] = dma_request_slave_channel(&pdev->dev, "CI_V");
> if (!pcdev->dma_chans[2]) {
> dev_err(&pdev->dev, "Can't request DMA for V\n");
> err = -ENODEV;
>
^ permalink raw reply
* Re: KMSAN: uninit-value in __udp4_lib_rcv
From: Dmitry Vyukov @ 2018-04-22 10:57 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Alexey Kuznetsov, LKML, netdev, syzkaller-bugs,
Hideaki YOSHIFUJI
In-Reply-To: <000000000000116485056a369609@google.com>
On Thu, Apr 19, 2018 at 7:06 PM, syzbot
<syzbot+493bccc5b8cfe9d5035e@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on https://github.com/google/kmsan.git/master
> commit
> 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +0000)
> Merge pull request #11 from parkerduckworth/readme
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=493bccc5b8cfe9d5035e
>
> So far this crash happened 11 times on
> https://github.com/google/kmsan.git/master.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4935004320694272
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5133260011077632
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5329144879513600
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
> compiler: clang version 7.0.0 (trunk 329391)
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+493bccc5b8cfe9d5035e@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
This does not reproduce after:
https://github.com/google/kmsan/commit/a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe
so let's consider this as false positive related to checksums:
#syz invalid
> ==================================================================
> BUG: KMSAN: uninit-value in __udp4_lib_rcv+0x628/0x4740 net/ipv4/udp.c:2066
> CPU: 1 PID: 3573 Comm: syzkaller192717 Not tainted 4.16.0+ #83
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
> __udp4_lib_rcv+0x628/0x4740 net/ipv4/udp.c:2066
> udp_rcv+0x5c/0x70 net/ipv4/udp.c:2287
> ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
> dst_input include/net/dst.h:449 [inline]
> ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
> __netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
> __netif_receive_skb net/core/dev.c:4627 [inline]
> process_backlog+0x62d/0xe20 net/core/dev.c:5307
> napi_poll net/core/dev.c:5705 [inline]
> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
> __do_softirq+0x56d/0x93d kernel/softirq.c:285
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
> </IRQ>
> do_softirq kernel/softirq.c:329 [inline]
> __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
> local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
> rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
> ip_finish_output2+0x124e/0x1380 net/ipv4/ip_output.c:231
> ip_finish_output+0xcb0/0xff0 net/ipv4/ip_output.c:317
> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> ip_output+0x502/0x5c0 net/ipv4/ip_output.c:405
> dst_output include/net/dst.h:443 [inline]
> ip_local_out net/ipv4/ip_output.c:124 [inline]
> ip_send_skb+0x5f3/0x820 net/ipv4/ip_output.c:1414
> ip_push_pending_frames+0x105/0x170 net/ipv4/ip_output.c:1434
> raw_sendmsg+0x2960/0x3ed0 net/ipv4/raw.c:684
> inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
> sock_sendmsg_nosec net/socket.c:630 [inline]
> sock_sendmsg net/socket.c:640 [inline]
> ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
> __sys_sendmsg net/socket.c:2080 [inline]
> SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
> SyS_sendmsg+0x54/0x80 net/socket.c:2087
> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> RIP: 0033:0x43fe99
> RSP: 002b:00007ffca5bf5be8 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fe99
> RDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004017c0
> R13: 0000000000401850 R14: 0000000000000000 R15: 0000000000000000
>
> Uninit was stored to memory at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
> kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
> kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
> kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:526
> __msan_memcpy+0x19f/0x1f0 mm/kmsan/kmsan_instr.c:470
> skb_copy_bits+0x63a/0xdb0 net/core/skbuff.c:2046
> __pskb_pull_tail+0x483/0x22e0 net/core/skbuff.c:1883
> pskb_may_pull include/linux/skbuff.h:2112 [inline]
> __udp4_lib_rcv+0x55f/0x4740 net/ipv4/udp.c:2058
> udp_rcv+0x5c/0x70 net/ipv4/udp.c:2287
> ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
> dst_input include/net/dst.h:449 [inline]
> ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
> __netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
> __netif_receive_skb net/core/dev.c:4627 [inline]
> process_backlog+0x62d/0xe20 net/core/dev.c:5307
> napi_poll net/core/dev.c:5705 [inline]
> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
> __do_softirq+0x56d/0x93d kernel/softirq.c:285
> Uninit was created at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
> kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:814
> kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:868
> __alloc_pages_nodemask+0xf5b/0x5dc0 mm/page_alloc.c:4283
> alloc_pages_current+0x6b5/0x970 mm/mempolicy.c:2055
> alloc_pages include/linux/gfp.h:494 [inline]
> skb_page_frag_refill+0x3ba/0x5e0 net/core/sock.c:2208
> sk_page_frag_refill+0xa4/0x340 net/core/sock.c:2228
> __ip_append_data+0x107e/0x3d10 net/ipv4/ip_output.c:1057
> ip_append_data+0x2fb/0x440 net/ipv4/ip_output.c:1170
> raw_sendmsg+0x287b/0x3ed0 net/ipv4/raw.c:678
> inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
> sock_sendmsg_nosec net/socket.c:630 [inline]
> sock_sendmsg net/socket.c:640 [inline]
> ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
> __sys_sendmsg net/socket.c:2080 [inline]
> SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
> SyS_sendmsg+0x54/0x80 net/socket.c:2087
> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000116485056a369609%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 15/39] acpi/battery: simplify procfs code
From: Rafael J. Wysocki @ 2018-04-22 9:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, devel,
Linux Kernel Mailing List, open list:TARGET SUBSYSTEM,
Corey Minyard, linux-ide, Greg Kroah-Hartman, jfs-discussion,
linux-afs, ACPI Devel Maling List, netdev, netfilter-devel,
Alexander Viro, Jiri Slaby, Andrew Morton, Ext4 Developers List,
Alexey Dobriyan, megaraidlinux.pdl, drbd-dev
In-Reply-To: <20180419124140.9309-16-hch@lst.de>
On Thu, Apr 19, 2018 at 2:41 PM, Christoph Hellwig <hch@lst.de> wrote:
> Use remove_proc_subtree to remove the whole subtree on cleanup, and
> unwind the registration loop into individual calls. Switch to use
> proc_create_seq where applicable.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
It is OK AFAICS.
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^ permalink raw reply
* Re: [PATCH net] net: ethtool: Add missing kernel doc for FEC parameters
From: Sergei Shtylyov @ 2018-04-22 8:51 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, vidya.chowdary, dustin, roopa
In-Reply-To: <20180421231848.17450-1-f.fainelli@gmail.com>
Hello!
On 4/22/2018 2:18 AM, Florian Fainelli wrote:
> While adding support for ethtool::get_fecparam and set_param, kernel doc for
set_fecparam.
> these functions was missed, add those.
>
> Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
From: Laurent Pinchart @ 2018-04-22 8:46 UTC (permalink / raw)
To: Laurent Pinchart
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, devel, Mauro Carvalho Chehab, Geert Uytterhoeven,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, linux-arm-kernel, Sergei Shtylyov,
Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-renesas-soc,
Simon Horman, netdev, dmaengine
In-Reply-To: <3039853.rivznOVBTv@avalon>
Hi Geert,
On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
> > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
> > only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
> > ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
> > than the legacy ARCH_SHMOBILE, hence use the former.
> >
> > This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> > future.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> How would you like to get this merged ?
Unless you would like to merge the whole series in one go, I'll take this in
my tree as I have a conflicting patch I would like to submit for v4.18.
> > ---
> >
> > drivers/media/platform/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index f9235e8f8e962d2e..7ad4725f9d1f9627
> > 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -396,7 +396,7 @@ config VIDEO_SH_VEU
> > config VIDEO_RENESAS_FDP1
> > tristate "Renesas Fine Display Processor"
> > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> > - depends on ARCH_SHMOBILE || COMPILE_TEST
> > + depends on ARCH_RENESAS || COMPILE_TEST
> > depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
> > select VIDEOBUF2_DMA_CONTIG
> > select V4L2_MEM2MEM_DEV
--
Regards,
Laurent Pinchart
^ permalink raw reply
* How to detect libbfd when building tools/bpf?
From: Wang Sheng-Hui @ 2018-04-22 7:51 UTC (permalink / raw)
To: ast, daniel, kstewart, gregkh, tglx, pombredanne; +Cc: netdev
Sorry to trouble you !
I run debian and installed binutils-dev beforehand.
Then I copied tools/build/feature/test-libbfd.c to t.c and run:
------------------------------------------------------------------------
root@lazyfintech:~# cat t.c
#include <bfd.h>
extern int printf(const char *format, ...);
int main(void)
{
char symbol[4096] = "FieldName__9ClassNameFd";
char *tmp;
tmp = bfd_demangle(0, symbol, 0);
printf("demangled symbol: {%s}\n", tmp);
return 0;
}
root@lazyfintech:~# gcc t.c -lbfd
root@lazyfintech:~# ./a.out
demangled symbol: {ClassName::FieldName}
I thought libbfd can be reached from above.
But when I built tools/bpf, libbfd cannot be detected:
-------------------------------------------------------------------------
/linux# make O=../buildkernel/ tools/bpf
make[1]: Entering directory '/root/buildkernel'
DESCEND bpf
Auto-detecting system features:
... libbfd: [ OFF ]
... disassembler-four-args: [ on ]
DESCEND bpftool
Auto-detecting system features:
... libbfd: [ OFF ]
... disassembler-four-args: [ on ]
make[1]: Leaving directory '/root/buildkernel'
I wonder how should I do to get libbfd auto detected when building bpf tool?
Regards,
shenghui
^ permalink raw reply
* Bluetooth/lock_sock: false positive "WARNING: possible recursive locking detected"
From: Jiri Slaby @ 2018-04-22 7:57 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg; +Cc: BlueZ development, ML netdev
Hi,
I have just got this lockdep warning during suspend:
> [ 2891.586061] ============================================
> [ 2891.586063] WARNING: possible recursive locking detected
> [ 2891.586065] 4.16.2-10.ge881e16-default #1 Not tainted
> [ 2891.586067] --------------------------------------------
> [ 2891.586068] kworker/u9:3/873 is trying to acquire lock:
> [ 2891.586070] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<000000007b85e829>] bt_accept_enqueue+0x29/0x90 [bluetooth]
> [ 2891.586086]
> but task is already holding lock:
> [ 2891.586088] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<0000000042f0b4a5>] l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth]
> [ 2891.586109]
> other info that might help us debug this:
> [ 2891.586111] Possible unsafe locking scenario:
>
> [ 2891.586115] CPU0
> [ 2891.586116] ----
> [ 2891.586117] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 2891.586120] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 2891.586122]
> *** DEADLOCK ***
>
> [ 2891.586125] May be due to missing lock nesting notation
>
> [ 2891.586127] 5 locks held by kworker/u9:3/873:
> [ 2891.586128] #0: ((wq_completion)"%s"hdev->name#2){+.+.}, at: [<000000004aa1a273>] process_one_work+0x1e3/0x6a0
> [ 2891.586135] #1: ((work_completion)(&hdev->rx_work)){+.+.}, at: [<000000004aa1a273>] process_one_work+0x1e3/0x6a0
> [ 2891.586140] #2: (&conn->chan_lock){+.+.}, at: [<00000000fbad6c82>] l2cap_connect+0x88/0x540 [bluetooth]
> [ 2891.586155] #3: (&chan->lock/2){+.+.}, at: [<000000007c38e27e>] l2cap_connect+0xa0/0x540 [bluetooth]
> [ 2891.586170] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<0000000042f0b4a5>] l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth]
> [ 2891.586183]
> stack backtrace:
> [ 2891.586187] CPU: 2 PID: 873 Comm: kworker/u9:3 Not tainted 4.16.2-10.ge881e16-default #1 openSUSE Tumbleweed (unreleased)
> [ 2891.586189] Hardware name: Dell Inc. Latitude 7280/0KK5D1, BIOS 1.9.3 03/09/2018
> [ 2891.586200] Workqueue: hci0 hci_rx_work [bluetooth]
> [ 2891.586202] Call Trace:
> [ 2891.586207] dump_stack+0x85/0xc5
> [ 2891.586211] __lock_acquire+0x6b4/0x1370
> [ 2891.586221] lock_acquire+0x9f/0x210
> [ 2891.586237] lock_sock_nested+0x5a/0x80
> [ 2891.586256] bt_accept_enqueue+0x29/0x90 [bluetooth]
> [ 2891.586268] l2cap_sock_new_connection_cb+0x5d/0xa0 [bluetooth]
> [ 2891.586280] l2cap_connect+0x126/0x540 [bluetooth]
> [ 2891.586315] l2cap_sig_channel+0x443/0x13b0 [bluetooth]
> [ 2891.586330] l2cap_recv_frame+0x1a4/0x300 [bluetooth]
> [ 2891.586341] hci_rx_work+0x1c8/0x5c0 [bluetooth]
> [ 2891.586345] process_one_work+0x269/0x6a0
> [ 2891.586350] worker_thread+0x2b/0x3d0
> [ 2891.586356] kthread+0x113/0x130
> [ 2891.586363] ret_from_fork+0x24/0x50
> [ 4954.622809] e1000e: eth0 NIC Link is Down
> [ 4955.299532] PM: suspend entry (deep)
> [ 4955.299538] PM: Syncing filesystems ... done.
This is:
lock_sock(sk); in bt_accept_enqueue
nested in
lock_sock(parent); in l2cap_sock_new_connection_cb
So this looks like a false positive to me. So I believe this is a fix:
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1232,7 +1232,7 @@ static struct l2cap_chan
*l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
{
struct sock *sk, *parent = chan->data;
- lock_sock(parent);
+ lock_sock_nested(parent, L2CAP_NESTING_PARENT);
/* Check for backlog size */
if (sk_acceptq_is_full(parent)) {
?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: Clean up btf.h in uapi
From: Alexei Starovoitov @ 2018-04-22 4:57 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180421164823.1059397-1-kafai@fb.com>
On Sat, Apr 21, 2018 at 09:48:23AM -0700, Martin KaFai Lau wrote:
> This patch cleans up btf.h in uapi:
> 1) Rename "name" to "name_off" to better reflect it is an offset to the
> string section instead of a char array.
> 2) Remove unused value BTF_FLAGS_COMPR and BTF_MAGIC_SWAP
>
> Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH] netfilter: fix nf_tables filter chain type build
From: Randy Dunlap @ 2018-04-22 4:10 UTC (permalink / raw)
To: netdev@vger.kernel.org, LKML
Cc: coreteam, netfilter-devel, Florian Westphal, Jozsef Kadlecsik,
Pablo Neira Ayuso, kbuild test robot
From: Randy Dunlap <rdunlap@infradead.org>
Fix build errors due to a missing Kconfig dependency term.
Fixes these build errors:
net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_nat_do_chain':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:37: undefined reference to `nft_do_chain'
net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_exit':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:94: undefined reference to `nft_unregister_chain_type'
net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_init':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:87: undefined reference to `nft_register_chain_type'
Fixes: 02c7b25e5f54 ("netfilter: nf_tables: build-in filter chain type")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org
---
net/ipv6/netfilter/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20180419.orig/net/ipv6/netfilter/Kconfig
+++ linux-next-20180419/net/ipv6/netfilter/Kconfig
@@ -108,7 +108,7 @@ config NF_NAT_IPV6
if NF_NAT_IPV6
config NFT_CHAIN_NAT_IPV6
- depends on NF_TABLES_IPV6
+ depends on NF_TABLES_IPV6 && NF_TABLES
tristate "IPv6 nf_tables nat chain support"
help
This option enables the "nat" chain for IPv6 in nf_tables. This
^ permalink raw reply
* Re: Charity Venture
From: Mik. M. Fridman @ 2018-04-22 3:59 UTC (permalink / raw)
--
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to
give
my fortune as charity.
Check the link below for confirmation:
http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV
From: Alexander Duyck @ 2018-04-22 0:22 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Alexander Duyck, Bjorn Helgaas, linux-pci, virtio-dev, kvm,
Netdev, Daly, Dan, LKML, linux-nvme, Keith Busch, netanel,
Don Dutile, Maximilian Heyne, Wang, Liang-min, Rustad, Mark D,
David Woodhouse, Christoph Hellwig, dwmw
In-Reply-To: <20180421203437.GW28657@bhelgaas-glaptop.roam.corp.google.com>
On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote:
>> This series is meant to add support for SR-IOV on devices when the VFs are
>> not managed by the kernel. Examples of recent patches attempting to do this
>> include:
>> virto - https://patchwork.kernel.org/patch/10241225/
>> pci-stub - https://patchwork.kernel.org/patch/10109935/
>> vfio - https://patchwork.kernel.org/patch/10103353/
>> uio - https://patchwork.kernel.org/patch/9974031/
>>
>> Since this is quickly blowing up into a multi-driver problem it is probably
>> best to implement this solution as generically as possible.
>>
>> This series is an attempt to do that. What we do with this patch set is
>> provide a generic framework to enable SR-IOV in the case that the PF driver
>> doesn't support managing the VFs itself.
>>
>> I based my patch set originally on the patch by Mark Rustad but there isn't
>> much left after going through and cleaning out the bits that were no longer
>> needed, and after incorporating the feedback from David Miller. At this point
>> the only items to be fully reused was his patch description which is now
>> present in patch 3 of the set.
>>
>> This solution is limited in scope to just adding support for devices that
>> provide no functionality for SR-IOV other than allocating the VFs by
>> calling pci_enable_sriov. Previous sets had included patches for VFIO, but
>> for now I am dropping that as the scope of that work is larger then I
>> think I can take on at this time.
>>
>> v2: Reduced scope back to just virtio_pci and vfio-pci
>> Broke into 3 patch set from single patch
>> Changed autoprobe behavior to always set when num_vfs is set non-zero
>> v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
>> Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
>> v4: Dropped vfio-pci patch
>> Added ena and nvme to drivers now using pci_sriov_configure_unmanaged
>> Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
>> v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
>> Added new patch that enables pci_sriov_configure_simple
>> Updated drivers to use pci_sriov_configure_simple
>> v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
>> Updated drivers to drop "#ifdef" checks for IOV
>> Added pci-pf-stub as place for PF-only drivers to add support
>> v7: Dropped pci_id table explanation from pci-pf-stub driver
>> Updated pci_sriov_configure_simple to drop need for err value
>> Fixed comment explaining why pci_sriov_configure_simple is NULL
>> v8: Dropped virtio from the set, support to be added later after TC approval
>>
>> Cc: Mark Rustad <mark.d.rustad@intel.com>
>> Cc: Maximilian Heyne <mheyne@amazon.de>
>> Cc: Liang-Min Wang <liang-min.wang@intel.com>
>> Cc: David Woodhouse <dwmw@amazon.co.uk>
>>
>> ---
>>
>> Alexander Duyck (4):
>> pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
>> ena: Migrate over to unmanaged SR-IOV support
>> nvme: Migrate over to unmanaged SR-IOV support
>> pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
>>
>>
>> drivers/net/ethernet/amazon/ena/ena_netdev.c | 28 -------------
>> drivers/nvme/host/pci.c | 20 ----------
>> drivers/pci/Kconfig | 12 ++++++
>> drivers/pci/Makefile | 2 +
>> drivers/pci/iov.c | 31 +++++++++++++++
>> drivers/pci/pci-pf-stub.c | 54 ++++++++++++++++++++++++++
>> include/linux/pci.h | 3 +
>> include/linux/pci_ids.h | 2 +
>> 8 files changed, 106 insertions(+), 46 deletions(-)
>> create mode 100644 drivers/pci/pci-pf-stub.c
>
> I tentatively applied these to pci/virtualization-review.
>
> The code changes look fine, but I want to flesh out the changelogs a
> little bit before merging them.
Thanks.
> For example, I'm not sure what you mean by "devices where the PF is
> not capable of managing VF resources."
>
> It *sounds* like you're saying the hardware works differently on some
> devices, but I don't think that's what you mean. I think you're
> saying something about which drivers are used for the PF and the VF.
That is sort of what I am saying.
So for example with ixgbe there is functionality which is controlled
in the MMIO space of the PF that affects the functionality of the VFs
that are generated on the device. The PF has to rearrange the
resources such as queues and interrupts on the device before it can
enable SR-IOV, and it could alter those later to limit what the VF is
capable of doing.
The model I am dealing with via this patch set has a PF that is not
much different than the VFs other than the fact that it has some
extended configuration space bits in place for SR-IOV, ARI, ACS, and
whatever other bits are needed in order to support spawning isolated
VFs.
> I think a trivial example of how this will be used might help. I
> assume this involves a virtualization scenario where the host uses the
> PF to enable several VFs, but the host doesn't use the PF for much
> else. Then you assign the VFs to guests, and drivers in the guest
> OSes use the VFs.
So this description would work for the pci-pf-stub driver. Basically
the idea here is that you have a device that is nothing more than a
function there to spawn VFs.
The other scenario that I am supporting are the ena and nvme models.
They match what I have described above where the PF is really just
another VF with some extra configuration space bits that add support
for spawning what amount to peer VFs to the already present PF.
> Since .sriov_configure() is only used by sriov_numvfs_store(), I
> assume the usage model involves writing to the sysfs sriov_numvfs
> attribute to enable the VFs, then assigning them to guests?
>
> Bjorn
Yes. The assumption for this function is that we are only supporting
the sysfs approach for spawning VFs.
- Alex
^ permalink raw reply
* [PATCH net] net: ethtool: Add missing kernel doc for FEC parameters
From: Florian Fainelli @ 2018-04-21 23:18 UTC (permalink / raw)
To: netdev; +Cc: davem, vidya.chowdary, dustin, roopa, Florian Fainelli
While adding support for ethtool::get_fecparam and set_param, kernel doc for
these functions was missed, add those.
Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/linux/ethtool.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index ebe41811ed34..f95d47b4d545 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -310,6 +310,10 @@ bool ethtool_convert_link_mode_to_legacy_u32(u32 *legacy_u32,
* fields should be ignored (use %__ETHTOOL_LINK_MODE_MASK_NBITS
* instead of the latter), any change to them will be overwritten
* by kernel. Returns a negative error code or zero.
+ * @get_fecparam: Get the network device Forward Error Correction
+ * parameters.
+ * @sec_fecparam: Set the network device Forward Error Correction
+ * parameters.
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must
--
2.14.1
^ permalink raw reply related
* Re: [PATCH/RFC net-next 4/5] ravb: remove undocumented processing
From: Sergei Shtylyov @ 2018-04-21 20:59 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, netdev, linux-renesas-soc, Wolfram Sang,
Kazuya Mizuguchi
In-Reply-To: <20180417085030.32650-5-horms+renesas@verge.net.au>
On 04/17/2018 11:50 AM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
How about the description (or 2)?
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/net/ethernet/renesas/ravb.h | 5 -----
> drivers/net/ethernet/renesas/ravb_main.c | 15 ---------------
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index 57eea4a77826..fcd04dbc7dde 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -197,15 +197,11 @@ enum ravb_reg {
> MAHR = 0x05c0,
> MALR = 0x05c8,
> TROCR = 0x0700, /* Undocumented? */
> - CDCR = 0x0708, /* Undocumented? */
> - LCCR = 0x0710, /* Undocumented? */
> CEFCR = 0x0740,
> FRECR = 0x0748,
> TSFRCR = 0x0750,
> TLFRCR = 0x0758,
> RFCR = 0x0760,
> - CERCR = 0x0768, /* Undocumented? */
> - CEECR = 0x0770, /* Undocumented? */
> MAFCR = 0x0778,
> };
>
I think this is a material of patch #1...
> @@ -223,7 +219,6 @@ enum CCC_BIT {
> CCC_CSEL_HPB = 0x00010000,
> CCC_CSEL_ETH_TX = 0x00020000,
> CCC_CSEL_GMII_REF = 0x00030000,
> - CCC_BOC = 0x00100000, /* Undocumented? */
> CCC_LBME = 0x01000000,
... and this -- of patch #2. Or vice versa. :-)
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits
From: Sergei Shtylyov @ 2018-04-21 20:53 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, netdev, linux-renesas-soc, Wolfram Sang,
Kazuya Mizuguchi
In-Reply-To: <20180417085030.32650-4-horms+renesas@verge.net.au>
On 04/17/2018 11:50 AM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch corrects writing 1 to reserved bits.
> The write value should be 0.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/net/ethernet/renesas/ravb.h | 12 ++++++++++++
> drivers/net/ethernet/renesas/ravb_main.c | 9 +++++----
> drivers/net/ethernet/renesas/ravb_ptp.c | 2 +-
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index b81f4faf7b10..57eea4a77826 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -433,6 +433,8 @@ enum EIS_BIT {
> EIS_QFS = 0x00010000,
> };
>
> +#define EIS_RESERVED_BITS (u32)(GENMASK(31, 17) | GENMASK(15, 11))
> +
> /* RIC0 */
> enum RIC0_BIT {
> RIC0_FRE0 = 0x00000001,
> @@ -477,6 +479,8 @@ enum RIS0_BIT {
> RIS0_FRF17 = 0x00020000,
> };
>
> +#define RIS0_RESERVED_BITS (u32)GENMASK(31, 18)
> +
> /* RIC1 */
> enum RIC1_BIT {
> RIC1_RFWE = 0x80000000,
> @@ -533,6 +537,8 @@ enum RIS2_BIT {
> RIS2_RFFF = 0x80000000,
> };
>
> +#define RIS2_RESERVED_BITS (u32)GENMASK_ULL(30, 18)
> +
> /* TIC */
> enum TIC_BIT {
> TIC_FTE0 = 0x00000001, /* Undocumented? */
> @@ -549,6 +555,10 @@ enum TIS_BIT {
> TIS_TFWF = 0x00000200,
> };
>
> +#define TIS_RESERVED_BITS (u32)(GENMASK_ULL(31, 20) | \
> + GENMASK_ULL(15, 12) | \
> + GENMASK_ULL(7, 4))
> +
> /* ISS */
> enum ISS_BIT {
> ISS_FRS = 0x00000001, /* Undocumented? */
> @@ -622,6 +632,8 @@ enum GIS_BIT {
> GIS_PTMF = 0x00000004,
> };
>
> +#define GIS_RESERVED_BITS (u32)GENMASK(15, 10)
> +
> /* GIE (R-Car Gen3 only) */
> enum GIE_BIT {
> GIE_PTCS = 0x00000001,
[...]
Perhaps we can do what the MUSB driver does: declare the writing-zero-clears
masks (inside *enum*!), and then set them before writing th register...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits
From: Sergei Shtylyov @ 2018-04-21 20:44 UTC (permalink / raw)
To: David Miller, horms+renesas
Cc: magnus.damm, netdev, linux-renesas-soc, wsa+renesas,
kazuya.mizuguchi.ks
In-Reply-To: <20180417.101553.1512039208518397234.davem@davemloft.net>
Hello!
On 04/17/2018 05:15 PM, David Miller wrote:
>> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>
>> This patch corrects writing 1 to reserved bits.
>> The write value should be 0.
>>
>> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> How are we ending up in situations where the driver is trying to write
> non-zero values to those fields in the first place?
The brain damaged AVB core design is to blame here. You have to write 0 to
clear the set bits and, at the same time, you can't write 1 to the reserved
bits... :-/
> The places creating those values should be making sure that the
> reserved bits are never set.
That's basically what this patch is doing.
> If you mask out the reserved bits in the register writing locations,
> this just hides bugs.
There are no *other* locations in some cases...
And I don't think that forcing the reserved bits to 1 after a register is
read would look better. :-(
MBR, Sergei
^ permalink raw reply
* Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV
From: Bjorn Helgaas @ 2018-04-21 20:34 UTC (permalink / raw)
To: Alexander Duyck
Cc: bhelgaas, linux-pci, virtio-dev, kvm, netdev, dan.daly,
linux-kernel, linux-nvme, keith.busch, netanel, ddutile, mheyne,
liang-min.wang, mark.d.rustad, dwmw2, hch, dwmw
In-Reply-To: <20180420162633.46077.49012.stgit@ahduyck-green-test.jf.intel.com>
On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote:
> This series is meant to add support for SR-IOV on devices when the VFs are
> not managed by the kernel. Examples of recent patches attempting to do this
> include:
> virto - https://patchwork.kernel.org/patch/10241225/
> pci-stub - https://patchwork.kernel.org/patch/10109935/
> vfio - https://patchwork.kernel.org/patch/10103353/
> uio - https://patchwork.kernel.org/patch/9974031/
>
> Since this is quickly blowing up into a multi-driver problem it is probably
> best to implement this solution as generically as possible.
>
> This series is an attempt to do that. What we do with this patch set is
> provide a generic framework to enable SR-IOV in the case that the PF driver
> doesn't support managing the VFs itself.
>
> I based my patch set originally on the patch by Mark Rustad but there isn't
> much left after going through and cleaning out the bits that were no longer
> needed, and after incorporating the feedback from David Miller. At this point
> the only items to be fully reused was his patch description which is now
> present in patch 3 of the set.
>
> This solution is limited in scope to just adding support for devices that
> provide no functionality for SR-IOV other than allocating the VFs by
> calling pci_enable_sriov. Previous sets had included patches for VFIO, but
> for now I am dropping that as the scope of that work is larger then I
> think I can take on at this time.
>
> v2: Reduced scope back to just virtio_pci and vfio-pci
> Broke into 3 patch set from single patch
> Changed autoprobe behavior to always set when num_vfs is set non-zero
> v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
> Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
> v4: Dropped vfio-pci patch
> Added ena and nvme to drivers now using pci_sriov_configure_unmanaged
> Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
> v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
> Added new patch that enables pci_sriov_configure_simple
> Updated drivers to use pci_sriov_configure_simple
> v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
> Updated drivers to drop "#ifdef" checks for IOV
> Added pci-pf-stub as place for PF-only drivers to add support
> v7: Dropped pci_id table explanation from pci-pf-stub driver
> Updated pci_sriov_configure_simple to drop need for err value
> Fixed comment explaining why pci_sriov_configure_simple is NULL
> v8: Dropped virtio from the set, support to be added later after TC approval
>
> Cc: Mark Rustad <mark.d.rustad@intel.com>
> Cc: Maximilian Heyne <mheyne@amazon.de>
> Cc: Liang-Min Wang <liang-min.wang@intel.com>
> Cc: David Woodhouse <dwmw@amazon.co.uk>
>
> ---
>
> Alexander Duyck (4):
> pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
> ena: Migrate over to unmanaged SR-IOV support
> nvme: Migrate over to unmanaged SR-IOV support
> pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
>
>
> drivers/net/ethernet/amazon/ena/ena_netdev.c | 28 -------------
> drivers/nvme/host/pci.c | 20 ----------
> drivers/pci/Kconfig | 12 ++++++
> drivers/pci/Makefile | 2 +
> drivers/pci/iov.c | 31 +++++++++++++++
> drivers/pci/pci-pf-stub.c | 54 ++++++++++++++++++++++++++
> include/linux/pci.h | 3 +
> include/linux/pci_ids.h | 2 +
> 8 files changed, 106 insertions(+), 46 deletions(-)
> create mode 100644 drivers/pci/pci-pf-stub.c
I tentatively applied these to pci/virtualization-review.
The code changes look fine, but I want to flesh out the changelogs a
little bit before merging them.
For example, I'm not sure what you mean by "devices where the PF is
not capable of managing VF resources."
It *sounds* like you're saying the hardware works differently on some
devices, but I don't think that's what you mean. I think you're
saying something about which drivers are used for the PF and the VF.
I think a trivial example of how this will be used might help. I
assume this involves a virtualization scenario where the host uses the
PF to enable several VFs, but the host doesn't use the PF for much
else. Then you assign the VFs to guests, and drivers in the guest
OSes use the VFs.
Since .sriov_configure() is only used by sriov_numvfs_store(), I
assume the usage model involves writing to the sysfs sriov_numvfs
attribute to enable the VFs, then assigning them to guests?
Bjorn
^ permalink raw reply
* Re: [PATCH/RFC net-next 2/5] ravb: correct ptp does failure after suspend and resume
From: Sergei Shtylyov @ 2018-04-21 20:33 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, netdev, linux-renesas-soc, Wolfram Sang,
Kazuya Mizuguchi
In-Reply-To: <20180417085030.32650-3-horms+renesas@verge.net.au>
Hello!
s/failure/fail/ in the subject.
On 04/17/2018 11:50 AM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch fixes the problem that ptp4l command does not work after
> suspend and resume.
> Add the initial setting in ravb_suspend() and ravb_resume(),
> because ptp does not work.
>
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
Other than the earlier comments, this seems good:
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 0/7] net/ipv6: Another followup to the fib6_info change
From: David Miller @ 2018-04-21 20:06 UTC (permalink / raw)
To: dsahern; +Cc: netdev, idosch, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180420223803.15743-1-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 20 Apr 2018 15:37:56 -0700
> Last one - for this week.
>
> Patches 1, 2 and 7 are more cleanup patches - removing dead code,
> moving code from a header to near its single caller, and updating
> function name.
>
> Patches 3-5 do some refactoring leading up to patch 6 which fixes
> a NULL dereference. I have only managed to trigger a panic once, so
> I can not definitively confirm it addresses the problem but it seems
> pretty clear that it is a race on removing a 'from' reference on
> an rt6_info and another path using that 'from' value to do
> cookie checking.
Great work, series applied.
^ 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