* RE: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: YUAN Linyu @ 2016-11-16 3:57 UTC (permalink / raw)
To: David Miller; +Cc: cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <20161115.223111.734917440131578613.davem@davemloft.net>
No, this patch will not change dev->name,
It's care about ifa->ifa_label.
> - if (colon)
> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> - else
> - memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
So we change to
> - else
> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
Then if and else do same thing. Just one line is enough,
memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, November 16, 2016 11:31 AM
> To: YUAN Linyu
> Cc: cugyly@163.com; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
>
> From: YUAN Linyu <Linyu.Yuan@alcatel-sbell.com.cn>
> Date: Wed, 16 Nov 2016 03:13:31 +0000
>
> > So assign label to request name will do same thing as original code.
>
> Nope. dev->name does not have the colon, it was trimmed from the
> string for the device lookup. So the found device's dev->name does
> not have the colon character, even if it was in ifr.ifr_name
>
> This was my entire point.
>
> You are changing the behvaior of the code in an invalid way.
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: John Fastabend @ 2016-11-16 4:30 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161115002552-mutt-send-email-mst@kernel.org>
On 16-11-14 03:01 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 10, 2016 at 08:44:08PM -0800, John Fastabend wrote:
>>
>> ---
>> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/skb_array.h | 25 ++++++++
>> 2 files changed, 161 insertions(+)
>> create mode 100644 include/linux/ptr_ring_ll.h
>>
>> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
>> new file mode 100644
>> index 0000000..bcb11f3
>> --- /dev/null
>> +++ b/include/linux/ptr_ring_ll.h
>> @@ -0,0 +1,136 @@
>> +/*
>> + * Definitions for the 'struct ptr_ring_ll' datastructure.
>> + *
>> + * Author:
>> + * John Fastabend <john.r.fastabend@intel.com>
>> + *
>> + * Copyright (C) 2016 Intel Corp.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
>> + * one CPU producing entries and another consuming entries from a FIFO.
>> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
>
> So when is each one (ptr-ring/ptr-ring-ll) a win? _ll suffix seems to
> imply this gives a better latency, OTOH for a ping/pong I suspect
> ptr-ring would be better as it avoids index cache line bounces.
My observation under qdisc testing with pktgen is that I get better pps
numbers with this code vs ptr_ring using spinlock. I actually wrote
this implementation before the skb_array code was around though and
haven't done a thorough analysis of the two yet only pktgen benchmarks.
In my pktgen benchmarks I test 1:1 producer/consumer and many to one
producer/consumer tests. I'll post some numbers later this week.
[...]
>> + */
>> +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
>> +{
>> + u32 ret, head, tail, next, slots, mask;
>> +
>> + do {
>> + head = READ_ONCE(r->prod_head);
>> + mask = READ_ONCE(r->prod_mask);
>> + tail = READ_ONCE(r->cons_tail);
>> +
>> + slots = mask + tail - head;
>> + if (slots < 1)
>> + return -ENOMEM;
>> +
>> + next = head + 1;
>> + ret = cmpxchg(&r->prod_head, head, next);
>> + } while (ret != head);
>
>
> So why is this preferable to a lock?
>
> I suspect it's nothing else than the qspinlock fairness
> and polling code complexity. It's all not very useful if you
> 1. are just doing a couple of instructions under the lock
> and
> 2. use a finite FIFO which is unfair anyway
>
>
> How about this hack (lifted from virt_spin_lock):
>
> static inline void quick_spin_lock(struct qspinlock *lock)
> {
> do {
> while (atomic_read(&lock->val) != 0)
> cpu_relax();
> } while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0);
> }
>
> Or maybe we should even drop the atomic_read in the middle -
> worth profiling and comparing:
>
> static inline void quick_spin_lock(struct qspinlock *lock)
> {
> while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0)
> cpu_relax();
> }
>
>
> Then, use quick_spin_lock instead of spin_lock everywhere in
> ptr_ring - will that make it more efficient?
>
I think this could be the case. I'll give it a test later this week I
am working on the xdp bits for virtio at the moment. To be honest though
for my qdisc patchset first I need to resolve a bug and then probably in
the first set just use the existing skb_array implementation. Its fun
to micro-optimize this stuff but really any implementation will show
improvement over existing code.
Thanks,
John
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: John Fastabend @ 2016-11-16 4:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev@vger.kernel.org; +Cc: Michael S. Tsirkin
In-Reply-To: <20161115143258.2c46fc9a@redhat.com>
On 16-11-15 05:32 AM, Jesper Dangaard Brouer wrote:
>
> (looks like my message didn't reach the netdev list, due to me sending
> from the wrong email, forwarded message again):
>
> On Thu, 10 Nov 2016 20:44:08 -0800 John Fastabend <john.fastabend@gmail.com> wrote:
>
>> ---
>> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/skb_array.h | 25 ++++++++
>> 2 files changed, 161 insertions(+)
>> create mode 100644 include/linux/ptr_ring_ll.h
>>
>> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
>> new file mode 100644
>> index 0000000..bcb11f3
>> --- /dev/null
>> +++ b/include/linux/ptr_ring_ll.h
>> @@ -0,0 +1,136 @@
>> +/*
>> + * Definitions for the 'struct ptr_ring_ll' datastructure.
>> + *
>> + * Author:
>> + * John Fastabend <john.r.fastabend@intel.com>
> [...]
>> + *
>> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
>> + * one CPU producing entries and another consuming entries from a FIFO.
>> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
>
> It sounds like this is Single Producer Single Consumer (SPSC)
> implementation, but your implementation actually is Multi Producer
> Multi Consumer (MPMC) capable.
Correct qdisc requires a MPMC to handle all the OOO cases.
>
> The implementation looks a lot like my alf_queue[1] implementation:
> [1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/include/linux/alf_queue.h
>
Sure, I was using that implementation originally.
> If the primary use-case is one CPU producing and another consuming,
> then the normal ptr_ring (skb_array) will actually be faster!
>
> The reason is ptr_ring avoids bouncing a cache-line between the CPUs on
> every ring access. This is achieved by having the checks for full
> (__ptr_ring_full) and empty (__ptr_ring_empty) use the contents of the
> array (NULL value).
>
> I actually implemented two micro-benchmarks to measure the difference
> between skb_array[2] and alf_queue[3]:
> [2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_parallel01.c
> [3] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/alf_queue_parallel01.c
>
But :) this doesn't jive with my experiments where this implementation
was actually giving better numbers with pktgen over pfifo_fast even in
the SPSC case. I'll rerun metrics later this week its possible there was
some other issue causing the difference I guess.
As I noted in Michael's email though really I need to fix a bug in my
qdisc code and submit it before I worry too much about this
optimization.
>
>> + */
>> +
>> +#ifndef _LINUX_PTR_RING_LL_H
>> +#define _LINUX_PTR_RING_LL_H 1
>> +
> [...]
>> +
>> +struct ptr_ring_ll {
>> + u32 prod_size;
>> + u32 prod_mask;
>> + u32 prod_head;
>> + u32 prod_tail;
>> + u32 cons_size;
>> + u32 cons_mask;
>> + u32 cons_head;
>> + u32 cons_tail;
>> +
>> + void **queue;
>> +};
>
> Your implementation doesn't even split the consumer and producer into
> different cachelines (which in practice doesn't help much due to how
> the empty/full checks are performed).
Its was just a implementation to get the qdisc patches off the ground. I
expected to follow up with patches to optimize the implementation.
[...]
>> +static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
>> +{
>> + r->queue = __ptr_ring_init_queue_alloc(size, gfp);
>> + if (!r->queue)
>> + return -ENOMEM;
>> +
>> + r->prod_size = r->cons_size = size;
>> + r->prod_mask = r->cons_mask = size - 1;
>
> Shouldn't we have some check like is_power_of_2(size), as this code
> looks like it depend on this.
>
Sure it is required. I was just ensuring callers do it correctly.
>> + r->prod_tail = r->prod_head = 0;
>> + r->cons_tail = r->prod_tail = 0;
>> +
>> + return 0;
>> +}
>> +
[...]
>>
>> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
>> +{
>> + return __ptr_ring_ll_consume(&a->ring);
>> +}
>> +
>
> Note in the Multi Producer Multi Consumer (MPMC) use-case this type of
> queue can be faster than normal ptr_ring. And in patch2 you implement
> bulking, which is where the real benefit shows (in the MPMC case) for
> this kind of queue.
>
> What I would really like to see is a lock-free (locked cmpxchg) queue
> implementation, what like ptr_ring use the array as empty/full check,
> and still (somehow) support bulking.
>
OK perhaps worth experimenting with after if I can _finally_ get the
qdisc series in.
.John
^ permalink raw reply
* Re: [RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
From: John Fastabend @ 2016-11-16 4:42 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161115010140-mutt-send-email-mst@kernel.org>
On 16-11-14 03:06 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 10, 2016 at 08:44:32PM -0800, John Fastabend wrote:
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>
> This will naturally reduce the cache line bounce
> costs, but so will a _many API for ptr-ring,
> doing lock-add many-unlock.
>
> the number of atomics also scales better with the lock:
> one per push instead of one per queue.
>
> Also, when can qdisc use a _many operation?
>
On dequeue we can pull off many skbs instead of one at a time and
then either (a) pass them down as an array to the driver (I started
to write this on top of ixgbe and it seems like a win) or (b) pass
them one by one down to the driver and set the xmit_more bit correctly.
The pass one by one also seems like a win because we avoid the lock
per skb.
On enqueue qdisc side its a bit more evasive to start doing this.
[...]
>> +++ b/net/sched/sch_generic.c
>> @@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc,
>> struct skb_array_ll *q = band2list(priv, band);
>> int err;
>>
>> - err = skb_array_ll_produce(q, skb);
>> + err = skb_array_ll_produce(q, &skb);
>>
>> if (unlikely(err)) {
>> net_warn_ratelimited("drop a packet from fast enqueue\n");
>
> I don't see a pop many operation here.
>
Patches need a bit of cleanup looks like it was part of another patch.
.John
^ permalink raw reply
* Re: [RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
From: Michael S. Tsirkin @ 2016-11-16 5:23 UTC (permalink / raw)
To: John Fastabend; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <582BE39B.9050007@gmail.com>
On Tue, Nov 15, 2016 at 08:42:03PM -0800, John Fastabend wrote:
> On 16-11-14 03:06 PM, Michael S. Tsirkin wrote:
> > On Thu, Nov 10, 2016 at 08:44:32PM -0800, John Fastabend wrote:
> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >
> > This will naturally reduce the cache line bounce
> > costs, but so will a _many API for ptr-ring,
> > doing lock-add many-unlock.
> >
> > the number of atomics also scales better with the lock:
> > one per push instead of one per queue.
> >
> > Also, when can qdisc use a _many operation?
> >
>
> On dequeue we can pull off many skbs instead of one at a time and
> then either (a) pass them down as an array to the driver (I started
> to write this on top of ixgbe and it seems like a win) or (b) pass
> them one by one down to the driver and set the xmit_more bit correctly.
>
> The pass one by one also seems like a win because we avoid the lock
> per skb.
>
> On enqueue qdisc side its a bit more evasive to start doing this.
>
>
> [...]
I see. So we could wrap __ptr_ring_consume and
implement __skb_array_consume. You can call that
in a loop under a lock. I would limit it to something
small like 16 pointers, to make sure lock contention is
not an issue.
--
MST
^ permalink raw reply
* Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: Hangbin Liu @ 2016-11-16 6:20 UTC (permalink / raw)
To: Michal Tesar; +Cc: David Miller, kuznet, jmorris, kaber, netdev
In-Reply-To: <20161108092625.GA14456@sparky-lenivo.brq.redhat.com>
Hi David,
On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote:
> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote:
>
> > From: Michal Tesar <mtesar@redhat.com>
> > Date: Thu, 3 Nov 2016 10:38:34 +0100
> >
> > > 2. If the received Query is a General Query, the interface timer is
> > > used to schedule a response to the General Query after the
> > > selected delay. Any previously pending response to a General
> > > Query is canceled.
> > > --8<--
> > >
> > > Currently the timer is rearmed with new random expiration time for
> > > every incoming query regardless of possibly already pending report.
> > > Which is not aligned with the above RFE.
> >
> > I don't read it that way. #2 says if this is a general query then any
> > pending response to a general query is cancelled. And that's
> > effectively what the code is doing right now.
>
> Hi David,
> I think that it is important to notice that the RFC says also
> that only the first matching rule is applied.
>
> "
> When new Query with the Router-Alert option arrives on an
> interface, provided the system has state to report, a delay for a
> response is randomly selected in the range (0, [Max Resp Time]) where
> Max Resp Time is derived from Max Resp Code in the received Query
> message. The following rules are then used to determine if a Report
> needs to be scheduled and the type of Report to schedule. The rules
> are considered in order and only the first matching rule is applied.
^^
Would you like to reconsider about this? I also agree with Michal that we
need to choose the sooner timer. Or if we receive query very quickly, we
will keep refresh the timer and may never reply the report.
Thanks
Hangbin
>
> 1. If there is a pending response to a previous General Query
> scheduled sooner than the selected delay, no additional response
> needs to be scheduled.
>
> 2. If the received Query is a General Query, the interface timer is
> used to schedule a response to the General Query after the
> selected delay. Any previously pending response to a General
> Query is canceled.
> "
>
> So I would read the above like below:
> If some general query arrives and there is some
> already pending response scheduled sooner,
> no action is needed.
> That is how I understand to the rule [1].
>
> But when an general query arrives and there is some other
> response already pending, but not sooner as rule one says but later,
> new report should be scheduled and the already pending one
> needs to be canceled.
> That is how I understand to the rule [2]
>
> If there is no already pending report scheduled
> the first part of the rule [2] is applied
> and new report is scheduled along the selected delay.
>
> So basically we need to compare the already scheduled response exp time
> with the one coming in and choose the sooner one.
> This is exactly what the patch does.
>
> What do you think?
> Best regards Michal Tesar
^ permalink raw reply
* [PATCH net] virtio-net: add a missing synchronize_net()
From: Eric Dumazet @ 2016-11-16 6:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jason Wang, Michael S. Tsirkin
From: Eric Dumazet <edumazet@google.com>
It seems many drivers do not respect napi_hash_del() contract.
When napi_hash_del() is used before netif_napi_del(), an RCU grace
period is needed before freeing NAPI object.
Fixes: 91815639d880 ("virtio-net: rx busy polling support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index fd8b1e62301f..7276d5a95bd0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1497,6 +1497,11 @@ static void virtnet_free_queues(struct virtnet_info *vi)
netif_napi_del(&vi->rq[i].napi);
}
+ /* We called napi_hash_del() before netif_napi_del(),
+ * we need to respect an RCU grace period before freeing vi->rq
+ */
+ synchronize_net();
+
kfree(vi->rq);
kfree(vi->sq);
}
^ permalink raw reply related
* Re: [PATCH net-next 2/5] net: ethoc: Implement ethtool::nway_reset
From: Tobias Klauser @ 2016-11-16 7:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, andrew, tremyfr, Colin Ian King, open list
In-Reply-To: <20161115191949.15361-3-f.fainelli@gmail.com>
On 2016-11-15 at 20:19:46 +0100, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are
> already using dev->phydev all over the place so this comes for free.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs
From: Leon Romanovsky @ 2016-11-16 8:36 UTC (permalink / raw)
To: Salil Mehta
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Huwei (Xavier),
oulijun, mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm,
Zhangping (ZP)
In-Reply-To: <F4CC6FACFEB3C54C9141D49AD221F7F91A7A2371@lhreml503-mbx>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
On Tue, Nov 15, 2016 at 03:52:46PM +0000, Salil Mehta wrote:
> > -----Original Message-----
> > From: Leon Romanovsky [mailto:leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> > Sent: Wednesday, November 09, 2016 7:22 AM
> > To: Salil Mehta
> > Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun;
> > mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> > Zhangping (ZP)
> > Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of
> > allocating memory using APIs
> >
> > On Fri, Nov 04, 2016 at 04:36:25PM +0000, Salil Mehta wrote:
> > > From: "Wei Hu (Xavier)" <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > >
> > > This patch modified the logic of allocating memory using APIs in
> > > hns RoCE driver. We used kcalloc instead of kmalloc_array and
> > > bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> > > memory.
> > >
> > > Signed-off-by: Wei Hu (Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Ping Zhang <zhangping5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > ---
> > > drivers/infiniband/hw/hns/hns_roce_mr.c | 15 ++++++++-------
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > index fb87883..d3dfb5f 100644
> > > --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct
> > hns_roce_buddy *buddy, int max_order)
> > >
> > > for (i = 0; i <= buddy->max_order; ++i) {
> > > s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> > > - buddy->bits[i] = kmalloc_array(s, sizeof(long),
> > GFP_KERNEL);
> > > - if (!buddy->bits[i])
> > > - goto err_out_free;
> > > -
> > > - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> > > + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> > > + if (!buddy->bits[i]) {
> > > + buddy->bits[i] = vzalloc(s * sizeof(long));
> >
> > I wonder, why don't you use directly vzalloc instead of kcalloc
> > fallback?
> As we know we will have physical contiguous pages if the kcalloc
> call succeeds. This will give us a chance to have better performance
> over the allocations which are just virtually contiguous through the
> function vzalloc(). Therefore, later has only been used as a fallback
> when our memory request cannot be entertained through kcalloc.
>
> Are you suggesting that there will not be much performance penalty
> if we use just vzalloc ?
Not exactly,
I asked it, because we have similar code in our drivers and this
construction looks strange to me.
1. If performance is critical, we will use kmalloc.
2. If performance is not critical, we will use vmalloc.
But in this case, such construction shows me that we can live with
vmalloc performance and kmalloc allocation are not really needed.
In your specific case, I'm not sure that kcalloc will ever fail.
Thanks
>
> >
> > > + if (!buddy->bits[i])
> > > + goto err_out_free;
> > > + }
> > > }
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 8:41 UTC (permalink / raw)
To: avagin; +Cc: davem, netdev, xiyou.wangcong, Nicolas Dichtel
In-Reply-To: <CANaxB-yaizaZbUi-OaJLzy+k2fNOkTCb8L8uwBCw4L5axOCzdg@mail.gmail.com>
Andrei reports the following kmemleak error:
unreferenced object 0xffff91badb543950 (size 2096):
comm "kworker/u4:0", pid 6, jiffies 4295152553 (age 28.418s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 cb 5f df ba 91 ff ff .........._.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffb1865bea>] kmemleak_alloc+0x4a/0xa0
[<ffffffffb1243b38>] kmem_cache_alloc+0x128/0x280
[<ffffffffb142f5ab>] idr_layer_alloc+0x2b/0x90
[<ffffffffb142f9cd>] idr_get_empty_slot+0x34d/0x370
[<ffffffffb142fa4e>] idr_alloc+0x5e/0x110
[<ffffffffb170ac3d>] __peernet2id_alloc+0x6d/0x90
[<ffffffffb170bda5>] peernet2id_alloc+0x55/0xb0
[<ffffffffb1731216>] rtnl_fill_ifinfo+0xaa6/0x10a0
[<ffffffffb1733073>] rtmsg_ifinfo_build_skb+0x73/0xd0
[<ffffffffb17125d5>] rollback_registered_many+0x295/0x390
[<ffffffffb1712765>] unregister_netdevice_many+0x25/0x80
[<ffffffffb17138a5>] default_device_exit_batch+0x145/0x170
[<ffffffffb170ae52>] ops_exit_list.isra.4+0x52/0x60
[<ffffffffb170c17f>] cleanup_net+0x1bf/0x2a0
[<ffffffffb10b616f>] process_one_work+0x1ff/0x660
[<ffffffffb10b661e>] worker_thread+0x4e/0x480
There is no reason to try to allocate an nsid for a netns which is dying.
Reported-by: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Thank you for the report. Can you test this patch?
Regards,
Nicolas
net/core/net_namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f61c0e02a413..f1340ed0d8df 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
max = reqid + 1;
}
+ if (!atomic_read(&net->count) || !&atomic_read(peer->count))
+ return -EINVAL;
+
return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
}
--
2.8.1
^ permalink raw reply related
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 8:42 UTC (permalink / raw)
To: avagin; +Cc: davem, netdev, xiyou.wangcong
In-Reply-To: <1479285671-1298-1-git-send-email-nicolas.dichtel@6wind.com>
Le 16/11/2016 à 09:41, Nicolas Dichtel a écrit :
> Andrei reports the following kmemleak error:
> unreferenced object 0xffff91badb543950 (size 2096):
> comm "kworker/u4:0", pid 6, jiffies 4295152553 (age 28.418s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 cb 5f df ba 91 ff ff .........._.....
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffffb1865bea>] kmemleak_alloc+0x4a/0xa0
> [<ffffffffb1243b38>] kmem_cache_alloc+0x128/0x280
> [<ffffffffb142f5ab>] idr_layer_alloc+0x2b/0x90
> [<ffffffffb142f9cd>] idr_get_empty_slot+0x34d/0x370
> [<ffffffffb142fa4e>] idr_alloc+0x5e/0x110
> [<ffffffffb170ac3d>] __peernet2id_alloc+0x6d/0x90
> [<ffffffffb170bda5>] peernet2id_alloc+0x55/0xb0
> [<ffffffffb1731216>] rtnl_fill_ifinfo+0xaa6/0x10a0
> [<ffffffffb1733073>] rtmsg_ifinfo_build_skb+0x73/0xd0
> [<ffffffffb17125d5>] rollback_registered_many+0x295/0x390
> [<ffffffffb1712765>] unregister_netdevice_many+0x25/0x80
> [<ffffffffb17138a5>] default_device_exit_batch+0x145/0x170
> [<ffffffffb170ae52>] ops_exit_list.isra.4+0x52/0x60
> [<ffffffffb170c17f>] cleanup_net+0x1bf/0x2a0
> [<ffffffffb10b616f>] process_one_work+0x1ff/0x660
> [<ffffffffb10b661e>] worker_thread+0x4e/0x480
>
> There is no reason to try to allocate an nsid for a netns which is dying.
>
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
'Fixes' tag is missing :/
Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
^ permalink raw reply
* [PATCH] net: ethernet: faraday: To support device tree usage.
From: Greentime Hu @ 2016-11-16 8:43 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Greentime Hu
To support device tree usage for ftmac100.
Signed-off-by: Greentime Hu <green.hu@gmail.com>
---
drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index dce5f7b..81dd9e1 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id mac_of_ids[] = {
+ { .compatible = "andestech,atmac100" },
+ { }
+};
+
static struct platform_driver ftmac100_driver = {
.probe = ftmac100_probe,
.remove = __exit_p(ftmac100_remove),
.driver = {
.name = DRV_NAME,
+ .of_match_table = mac_of_ids
},
};
@@ -1200,3 +1206,4 @@ static void __exit ftmac100_exit(void)
MODULE_AUTHOR("Po-Yu Chuang <ratbert@faraday-tech.com>");
MODULE_DESCRIPTION("FTMAC100 driver");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, mac_of_ids);
--
1.7.9.5
^ permalink raw reply related
* 58410 netdev
From: marketing @ 2016-11-16 8:51 UTC (permalink / raw)
To: netdev
[-- Attachment #1: EMAIL_7613265_netdev.zip --]
[-- Type: application/zip, Size: 11263 bytes --]
^ permalink raw reply
* [patch net-next] mlxsw: spectrum_router: Adjust placement of FIB abort warning
From: Jiri Pirko @ 2016-11-16 8:51 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
From: Ido Schimmel <idosch@mellanox.com>
The recent merge commit bb598c1b8c9b ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") would cause
the FIB abort warning to fire whenever we flush the FIB tables - either
during module removal or actual abort.
Move it back to its rightful location in the FIB abort function.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 164bd30..683f045 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1872,9 +1872,6 @@ static void mlxsw_sp_router_fib_flush(struct mlxsw_sp *mlxsw_sp)
struct mlxsw_sp_vr *vr;
int i;
- if (mlxsw_sp->router.aborted)
- return;
- dev_warn(mlxsw_sp->bus_info->dev, "FIB abort triggered. Note that FIB entries are no longer being offloaded to this device.\n");
for (i = 0; i < MLXSW_CORE_RES_GET(mlxsw_sp->core, MAX_VRS); i++) {
vr = &mlxsw_sp->router.vrs[i];
@@ -1899,6 +1896,9 @@ static void mlxsw_sp_router_fib4_abort(struct mlxsw_sp *mlxsw_sp)
{
int err;
+ if (mlxsw_sp->router.aborted)
+ return;
+ dev_warn(mlxsw_sp->bus_info->dev, "FIB abort triggered. Note that FIB entries are no longer being offloaded to this device.\n");
mlxsw_sp_router_fib_flush(mlxsw_sp);
mlxsw_sp->router.aborted = true;
err = mlxsw_sp_router_set_abort_trap(mlxsw_sp);
--
2.7.4
^ permalink raw reply related
* [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alexandru Gagniuc @ 2016-11-16 9:02 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linux-kernel, davem, Alexandru Gagniuc
In-Reply-To: <20161115.221217.2076182289174952941.davem@davemloft.net>
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
---
Changes since v1:
* Added comment detailing applicability to different RGMII interfaces.
drivers/net/phy/vitesse.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..24b4a09 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS 0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW (1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,34 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+/* This adds a skew for both TX and RX clocks, so the skew should only be
+ * applied to "rgmii-id" interfaces. It may not work as expected
+ * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +307,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask = 0x000ffff0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init = &genphy_config_init,
+ .config_init = &vsc8601_config_init,
.config_aneg = &genphy_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] lwtunnel: subtract tunnel headroom from mtu on output redirect
From: David Lebrun @ 2016-11-16 9:05 UTC (permalink / raw)
To: netdev; +Cc: roopa, David Lebrun
This patch changes the lwtunnel_headroom() function which is called
in ipv4_mtu() and ip6_mtu(), to also return the correct headroom
value when the lwtunnel state is OUTPUT_REDIRECT.
This patch enables e.g. SR-IPv6 encapsulations to work without
manually setting the route mtu.
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
include/net/lwtunnel.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h
index 82e76fe..d4c1c75 100644
--- a/include/net/lwtunnel.h
+++ b/include/net/lwtunnel.h
@@ -94,7 +94,8 @@ static inline bool lwtunnel_xmit_redirect(struct lwtunnel_state *lwtstate)
static inline unsigned int lwtunnel_headroom(struct lwtunnel_state *lwtstate,
unsigned int mtu)
{
- if (lwtunnel_xmit_redirect(lwtstate) && lwtstate->headroom < mtu)
+ if ((lwtunnel_xmit_redirect(lwtstate) ||
+ lwtunnel_output_redirect(lwtstate)) && lwtstate->headroom < mtu)
return lwtstate->headroom;
return 0;
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: kbuild test robot @ 2016-11-16 9:10 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: kbuild-all, avagin, davem, netdev, xiyou.wangcong,
Nicolas Dichtel
In-Reply-To: <1479285671-1298-1-git-send-email-nicolas.dichtel@6wind.com>
[-- Attachment #1: Type: text/plain, Size: 11624 bytes --]
Hi Nicolas,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/net-nsid-cannot-be-allocated-for-a-dead-netns/20161116-164739
config: i386-randconfig-x006-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
net/core/net_namespace.c: In function 'alloc_netid':
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
vim +/atomic_read +162 net/core/net_namespace.c
1 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2
> 3 #include <linux/workqueue.h>
4 #include <linux/rtnetlink.h>
5 #include <linux/cache.h>
6 #include <linux/slab.h>
7 #include <linux/list.h>
8 #include <linux/delay.h>
9 #include <linux/sched.h>
10 #include <linux/idr.h>
11 #include <linux/rculist.h>
12 #include <linux/nsproxy.h>
13 #include <linux/fs.h>
14 #include <linux/proc_ns.h>
15 #include <linux/file.h>
16 #include <linux/export.h>
17 #include <linux/user_namespace.h>
18 #include <linux/net_namespace.h>
19 #include <net/sock.h>
20 #include <net/netlink.h>
21 #include <net/net_namespace.h>
22 #include <net/netns/generic.h>
23
24 /*
25 * Our network namespace constructor/destructor lists
26 */
27
28 static LIST_HEAD(pernet_list);
29 static struct list_head *first_device = &pernet_list;
30 DEFINE_MUTEX(net_mutex);
31
32 LIST_HEAD(net_namespace_list);
33 EXPORT_SYMBOL_GPL(net_namespace_list);
34
35 struct net init_net = {
36 .dev_base_head = LIST_HEAD_INIT(init_net.dev_base_head),
37 };
38 EXPORT_SYMBOL(init_net);
39
40 static bool init_net_initialized;
41
42 #define INITIAL_NET_GEN_PTRS 13 /* +1 for len +2 for rcu_head */
43
44 static unsigned int max_gen_ptrs = INITIAL_NET_GEN_PTRS;
45
46 static struct net_generic *net_alloc_generic(void)
47 {
48 struct net_generic *ng;
49 size_t generic_size = offsetof(struct net_generic, ptr[max_gen_ptrs]);
50
51 ng = kzalloc(generic_size, GFP_KERNEL);
52 if (ng)
53 ng->len = max_gen_ptrs;
54
55 return ng;
56 }
57
58 static int net_assign_generic(struct net *net, int id, void *data)
59 {
60 struct net_generic *ng, *old_ng;
61
62 BUG_ON(!mutex_is_locked(&net_mutex));
63 BUG_ON(id == 0);
64
65 old_ng = rcu_dereference_protected(net->gen,
66 lockdep_is_held(&net_mutex));
67 ng = old_ng;
68 if (old_ng->len >= id)
69 goto assign;
70
71 ng = net_alloc_generic();
72 if (ng == NULL)
73 return -ENOMEM;
74
75 /*
76 * Some synchronisation notes:
77 *
78 * The net_generic explores the net->gen array inside rcu
79 * read section. Besides once set the net->gen->ptr[x]
80 * pointer never changes (see rules in netns/generic.h).
81 *
82 * That said, we simply duplicate this array and schedule
83 * the old copy for kfree after a grace period.
84 */
85
86 memcpy(&ng->ptr, &old_ng->ptr, old_ng->len * sizeof(void*));
87
88 rcu_assign_pointer(net->gen, ng);
89 kfree_rcu(old_ng, rcu);
90 assign:
91 ng->ptr[id - 1] = data;
92 return 0;
93 }
94
95 static int ops_init(const struct pernet_operations *ops, struct net *net)
96 {
97 int err = -ENOMEM;
98 void *data = NULL;
99
100 if (ops->id && ops->size) {
101 data = kzalloc(ops->size, GFP_KERNEL);
102 if (!data)
103 goto out;
104
105 err = net_assign_generic(net, *ops->id, data);
106 if (err)
107 goto cleanup;
108 }
109 err = 0;
110 if (ops->init)
111 err = ops->init(net);
112 if (!err)
113 return 0;
114
115 cleanup:
116 kfree(data);
117
118 out:
119 return err;
120 }
121
122 static void ops_free(const struct pernet_operations *ops, struct net *net)
123 {
124 if (ops->id && ops->size) {
125 int id = *ops->id;
126 kfree(net_generic(net, id));
127 }
128 }
129
130 static void ops_exit_list(const struct pernet_operations *ops,
131 struct list_head *net_exit_list)
132 {
133 struct net *net;
134 if (ops->exit) {
135 list_for_each_entry(net, net_exit_list, exit_list)
136 ops->exit(net);
137 }
138 if (ops->exit_batch)
139 ops->exit_batch(net_exit_list);
140 }
141
142 static void ops_free_list(const struct pernet_operations *ops,
143 struct list_head *net_exit_list)
144 {
145 struct net *net;
146 if (ops->size && ops->id) {
147 list_for_each_entry(net, net_exit_list, exit_list)
148 ops_free(ops, net);
149 }
150 }
151
152 /* should be called with nsid_lock held */
153 static int alloc_netid(struct net *net, struct net *peer, int reqid)
154 {
155 int min = 0, max = 0;
156
157 if (reqid >= 0) {
158 min = reqid;
159 max = reqid + 1;
160 }
161
> 162 if (!atomic_read(&net->count) || !&atomic_read(peer->count))
163 return -EINVAL;
164
165 return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27870 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 9:45 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, avagin, davem, netdev, xiyou.wangcong
In-Reply-To: <201611161759.tCk5fdCO%fengguang.wu@intel.com>
Le 16/11/2016 à 10:10, kbuild test robot a écrit :
> Hi Nicolas,
>
> [auto build test ERROR on net/master]
And I finally send the wrong version of the patch :(
^ permalink raw reply
* [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 9:49 UTC (permalink / raw)
To: avagin; +Cc: davem, netdev, xiyou.wangcong, Nicolas Dichtel
In-Reply-To: <201611161759.tCk5fdCO%fengguang.wu@intel.com>
Andrei reports the following kmemleak error:
unreferenced object 0xffff91badb543950 (size 2096):
comm "kworker/u4:0", pid 6, jiffies 4295152553 (age 28.418s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 cb 5f df ba 91 ff ff .........._.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffb1865bea>] kmemleak_alloc+0x4a/0xa0
[<ffffffffb1243b38>] kmem_cache_alloc+0x128/0x280
[<ffffffffb142f5ab>] idr_layer_alloc+0x2b/0x90
[<ffffffffb142f9cd>] idr_get_empty_slot+0x34d/0x370
[<ffffffffb142fa4e>] idr_alloc+0x5e/0x110
[<ffffffffb170ac3d>] __peernet2id_alloc+0x6d/0x90
[<ffffffffb170bda5>] peernet2id_alloc+0x55/0xb0
[<ffffffffb1731216>] rtnl_fill_ifinfo+0xaa6/0x10a0
[<ffffffffb1733073>] rtmsg_ifinfo_build_skb+0x73/0xd0
[<ffffffffb17125d5>] rollback_registered_many+0x295/0x390
[<ffffffffb1712765>] unregister_netdevice_many+0x25/0x80
[<ffffffffb17138a5>] default_device_exit_batch+0x145/0x170
[<ffffffffb170ae52>] ops_exit_list.isra.4+0x52/0x60
[<ffffffffb170c17f>] cleanup_net+0x1bf/0x2a0
[<ffffffffb10b616f>] process_one_work+0x1ff/0x660
[<ffffffffb10b661e>] worker_thread+0x4e/0x480
There is no reason to try to allocate an nsid for a netns which is dying.
Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
Reported-by: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: fix compilation
add the 'Fixes' tag.
Andrei, can you test this new version?
Regards,
Nicolas
net/core/net_namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f61c0e02a413..63f65387f4e1 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
max = reqid + 1;
}
+ if (!atomic_read(&net->count) || !atomic_read(&peer->count))
+ return -EINVAL;
+
return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
}
--
2.8.1
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: marvell: Allow drivers to be built with COMPILE_TEST
From: kbuild test robot @ 2016-11-16 9:50 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, mw, arnd, gregory.clement, Shaohui.Xie,
Igal.Liberman, Florian Fainelli
In-Reply-To: <20161115173548.32567-3-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13954 bytes --]
Hi Florian,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-ethernet-Allow-Marvell-Freescale-to-COMPILE_TEST/20161116-024633
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `jme_open':
>> jme.c:(.text+0xda4a4c): undefined reference to `mvebu_mbus_get_dram_win_info'
drivers/built-in.o: In function `mvneta_bm_pool_use':
(.text+0xdac8dc): undefined reference to `mvebu_mbus_get_dram_win_info'
drivers/built-in.o: In function `pc87427_find':
pc87427.c:(.init.text+0x37bdd): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1449c)
pc87427.c:(.init.text+0x37c19): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144a0)
drivers/built-in.o: In function `pc87427_init':
pc87427.c:(.init.text+0x37d64): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144a8)
pc87427.c:(.init.text+0x37da9): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144ac)
pc87427.c:(.init.text+0x37dc3): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144b0)
pc87427.c:(.init.text+0x37dcd): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144b4)
pc87427.c:(.init.text+0x37dd8): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144b8)
pc87427.c:(.init.text+0x37de0): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144bc)
pc87427.c:(.init.text+0x37dfe): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144c0)
pc87427.c:(.init.text+0x37e1f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144c4)
pc87427.c:(.init.text+0x37e3b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144c8)
drivers/built-in.o: In function `pc87427_find':
pc87427.c:(.init.text+0x37be6): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144a4)
drivers/built-in.o: In function `pc87427_init':
pc87427.c:(.init.text+0x37d6b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144cc)
pc87427.c:(.init.text+0x37d92): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144d0)
pc87427.c:(.init.text+0x37dd2): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144d4)
pc87427.c:(.init.text+0x37de6): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144d8)
pc87427.c:(.init.text+0x37df4): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144dc)
pc87427.c:(.init.text+0x37e03): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144e0)
pc87427.c:(.init.text+0x37e13): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144e4)
pc87427.c:(.init.text+0x37e22): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144e8)
pc87427.c:(.init.text+0x37e30): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144ec)
pc87427.c:(.init.text+0x37e40): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144f0)
pc87427.c:(.init.text+0x37e4a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144f4)
pc87427.c:(.init.text+0x37e54): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144f8)
drivers/built-in.o: In function `pcf8591_init':
pcf8591.c:(.init.text+0x37e5f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x144fc)
pcf8591.c:(.init.text+0x37e6b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14500)
pcf8591.c:(.init.text+0x37e79): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14504)
pcf8591.c:(.init.text+0x37e6e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14508)
pcf8591.c:(.init.text+0x37e7e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1450c)
drivers/built-in.o: In function `powr1220_driver_init':
powr1220.c:(.init.text+0x37e8b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14510)
powr1220.c:(.init.text+0x37e92): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14514)
drivers/built-in.o: In function `pwm_fan_driver_init':
pwm-fan.c:(.init.text+0x37e9f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14518)
pwm-fan.c:(.init.text+0x37ea6): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1451c)
drivers/built-in.o: In function `sch56xx_find':
sch56xx-common.c:(.init.text+0x37eb3): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14520)
sch56xx-common.c:(.init.text+0x37eb6): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14524)
sch56xx-common.c:(.init.text+0x37eb9): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14528)
sch56xx-common.c:(.init.text+0x37ecc): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1452c)
sch56xx-common.c:(.init.text+0x37f01): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14530)
sch56xx-common.c:(.init.text+0x37f09): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14534)
sch56xx-common.c:(.init.text+0x37f11): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14538)
sch56xx-common.c:(.init.text+0x37f1b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1453c)
sch56xx-common.c:(.init.text+0x37f45): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14540)
sch56xx-common.c:(.init.text+0x37f7a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14544)
drivers/built-in.o: In function `sch56xx_init':
sch56xx-common.c:(.init.text+0x37fe9): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14560)
sch56xx-common.c:(.init.text+0x38004): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14564)
sch56xx-common.c:(.init.text+0x3801f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14568)
drivers/built-in.o: In function `sch56xx_find':
sch56xx-common.c:(.init.text+0x37ec4): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14548)
sch56xx-common.c:(.init.text+0x37ed2): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1454c)
sch56xx-common.c:(.init.text+0x37f1e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14550)
sch56xx-common.c:(.init.text+0x37f4a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14554)
sch56xx-common.c:(.init.text+0x37f7f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14558)
sch56xx-common.c:(.init.text+0x37f94): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1455c)
drivers/built-in.o: In function `sch56xx_init':
sch56xx-common.c:(.init.text+0x37fce): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1456c)
sch56xx-common.c:(.init.text+0x37fe3): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14570)
sch56xx-common.c:(.init.text+0x37ffa): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14574)
sch56xx-common.c:(.init.text+0x38007): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14578)
sch56xx-common.c:(.init.text+0x38014): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1457c)
sch56xx-common.c:(.init.text+0x38022): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14580)
sch56xx-common.c:(.init.text+0x3802c): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14584)
drivers/built-in.o: In function `sch5627_driver_init':
sch5627.c:(.init.text+0x38037): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14588)
sch5627.c:(.init.text+0x3803e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1458c)
drivers/built-in.o: In function `sch5636_driver_init':
sch5636.c:(.init.text+0x3804b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14590)
sch5636.c:(.init.text+0x38052): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14594)
drivers/built-in.o: In function `sht15_driver_init':
sht15.c:(.init.text+0x3805f): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x14598)
sht15.c:(.init.text+0x38066): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x1459c)
drivers/built-in.o: In function `sht21_driver_init':
sht21.c:(.init.text+0x38073): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145a0)
sht21.c:(.init.text+0x3807a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145a4)
drivers/built-in.o: In function `sht3x_i2c_driver_init':
sht3x.c:(.init.text+0x38087): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145a8)
sht3x.c:(.init.text+0x3808e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145ac)
drivers/built-in.o: In function `shtc1_i2c_driver_init':
shtc1.c:(.init.text+0x3809b): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145b0)
shtc1.c:(.init.text+0x380a2): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145b4)
drivers/built-in.o: In function `sm_sis5595_init':
sis5595.c:(.init.text+0x380af): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145bc)
sis5595.c:(.init.text+0x380b2): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145b8)
sis5595.c:(.init.text+0x380ba): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145c0)
drivers/built-in.o: In function `smm665_driver_init':
smm665.c:(.init.text+0x380c7): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145c4)
smm665.c:(.init.text+0x380ce): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145c8)
drivers/built-in.o: In function `smsc47b397_init':
smsc47b397.c:(.init.text+0x380e5): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145d8)
smsc47b397.c:(.init.text+0x3810e): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x145d0)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47325 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 9:56 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: netdev, devicetree, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <476b72f3-5efe-3551-6c24-0e378d655a0f@gmail.com>
On Tue, 2016-11-15 at 09:03 -0800, Florian Fainelli wrote:
> On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> >
> > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> > >
> > > On some platforms, energy efficient ethernet with rtl8211 devices
> > > is
> > > causing issue, like throughput drop or broken link.
> > >
> > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > > issue root
> > > cause is not fully understood yet, disabling EEE advertisement
> > > prevent auto
> > > negotiation from enabling EEE.
> > >
> > > This patch provides options to disable 1000T and 100TX EEE
> > > advertisement
> > > individually for the realtek phys supporting this feature.
> >
> > Looking at the code, i don't see anything specific to RealTek
> > here. This all seems generic. So should it be in phy.c and made a
> > generic OF property which can be applied to any PHY which supports
> > EEE.
>
> Agreed.
Good point, Thanks for pointing this out.
> Just to be sure, Jerome, you did verify that with EEE no longer
> advertised, ethtool --set-eee fails, right? The point is that you may
> be
> able to disable EEE on boot, but if there is a way to re-enable it
> later
> on, we would want to disable that too.
I was focused on getting the issue out of way I did not think that
someone could try something like this :)
I just tried and it is possible to re-enable eee, though it is not
simplest thing to do: using ethtool enable eee advertisement, enable
eee, restart the autonegotiation without bringing the interface down
(otherwise the phy config kicks and disable eee again). I reckon this
is not good and I need to address this.
There two kind of PHYs supporting eee, the one advertising eee by
default (like realtek) and the one not advertising it (like micrel).
If the property is going to be generic, I see two options and I'd like
your view on this:
1) The DT provided value could be seen as "preferred" (or boot
setting), which can be cleanly changed with ethtool later on. In this
case, I guess I need to provide a way to force eee advertisement as
well to be consistent.
2) The DT provided value could forbid the advertisement of eee. In this
case I need to return an error if ethtool tries to re-enable it. Phy
with eee advertisement off by default (and not forbidden) would still
need to activate it manually with ethtool after boot. I don't see why
someone would absolutely want eee activated at boot time so I guess
this is OK.
Do you have a preference ?
Thanks for this quick feedback !
Cheers
Jerome
^ permalink raw reply
* [PATCH net-next v6] cadence: Add LSO support.
From: Rafal Ozieblo @ 2016-11-16 10:02 UTC (permalink / raw)
To: nicolas.ferre, netdev, linux-kernel; +Cc: Rafal Ozieblo
In-Reply-To: <1478698862-12924-1-git-send-email-rafalo@cadence.com>
New Cadence GEM hardware support Large Segment Offload (LSO):
TCP segmentation offload (TSO) as well as UDP fragmentation
offload (UFO). Support for those features was added to the driver.
---
Changed in v2:
macb_lso_check_compatibility() changed to macb_features_check()
(with little modifications) and bind to .ndo_features_check.
(after Eric Dumazet suggestion)
---
Changed in v3:
Respin to net-next.
---
Changed in v4:
(struct iphdr*)skb_network_header(skb) changed to ip_hdr(skb)
---
Changed in v5:
Changes after Florian Fainelli comments
---
Changes in v6:
UDP checksum zeroing removed. There is no need to zeroing
UDP checksum during UFO operation.
Signed-off-by: Rafal Ozieblo <rafalo@cadence.com>
---
drivers/net/ethernet/cadence/macb.c | 138 ++++++++++++++++++++++++++++++++----
drivers/net/ethernet/cadence/macb.h | 14 ++++
2 files changed, 140 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index e1847ce..654b5bf 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -32,7 +32,9 @@
#include <linux/of_gpio.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
-
+#include <linux/ip.h>
+#include <linux/udp.h>
+#include <linux/tcp.h>
#include "macb.h"
#define MACB_RX_BUFFER_SIZE 128
@@ -60,10 +62,13 @@
| MACB_BIT(TXERR))
#define MACB_TX_INT_FLAGS (MACB_TX_ERR_FLAGS | MACB_BIT(TCOMP))
-#define MACB_MAX_TX_LEN ((unsigned int)((1 << MACB_TX_FRMLEN_SIZE) - 1))
-#define GEM_MAX_TX_LEN ((unsigned int)((1 << GEM_TX_FRMLEN_SIZE) - 1))
+/* Max length of transmit frame must be a multiple of 8 bytes */
+#define MACB_TX_LEN_ALIGN 8
+#define MACB_MAX_TX_LEN ((unsigned int)((1 << MACB_TX_FRMLEN_SIZE) - 1) & ~((unsigned int)(MACB_TX_LEN_ALIGN - 1)))
+#define GEM_MAX_TX_LEN ((unsigned int)((1 << GEM_TX_FRMLEN_SIZE) - 1) & ~((unsigned int)(MACB_TX_LEN_ALIGN - 1)))
#define GEM_MTU_MIN_SIZE ETH_MIN_MTU
+#define MACB_NETIF_LSO (NETIF_F_TSO | NETIF_F_UFO)
#define MACB_WOL_HAS_MAGIC_PACKET (0x1 << 0)
#define MACB_WOL_ENABLED (0x1 << 1)
@@ -1223,7 +1228,8 @@ static void macb_poll_controller(struct net_device *dev)
static unsigned int macb_tx_map(struct macb *bp,
struct macb_queue *queue,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ unsigned int hdrlen)
{
dma_addr_t mapping;
unsigned int len, entry, i, tx_head = queue->tx_head;
@@ -1231,14 +1237,27 @@ static unsigned int macb_tx_map(struct macb *bp,
struct macb_dma_desc *desc;
unsigned int offset, size, count = 0;
unsigned int f, nr_frags = skb_shinfo(skb)->nr_frags;
- unsigned int eof = 1;
- u32 ctrl;
+ unsigned int eof = 1, mss_mfs = 0;
+ u32 ctrl, lso_ctrl = 0, seq_ctrl = 0;
+
+ /* LSO */
+ if (skb_shinfo(skb)->gso_size != 0) {
+ if (ip_hdr(skb)->protocol == IPPROTO_UDP)
+ /* UDP - UFO */
+ lso_ctrl = MACB_LSO_UFO_ENABLE;
+ else
+ /* TCP - TSO */
+ lso_ctrl = MACB_LSO_TSO_ENABLE;
+ }
/* First, map non-paged data */
len = skb_headlen(skb);
+
+ /* first buffer length */
+ size = hdrlen;
+
offset = 0;
while (len) {
- size = min(len, bp->max_tx_length);
entry = macb_tx_ring_wrap(bp, tx_head);
tx_skb = &queue->tx_skb[entry];
@@ -1258,6 +1277,8 @@ static unsigned int macb_tx_map(struct macb *bp,
offset += size;
count++;
tx_head++;
+
+ size = min(len, bp->max_tx_length);
}
/* Then, map paged data from fragments */
@@ -1311,6 +1332,21 @@ static unsigned int macb_tx_map(struct macb *bp,
desc = &queue->tx_ring[entry];
desc->ctrl = ctrl;
+ if (lso_ctrl) {
+ if (lso_ctrl == MACB_LSO_UFO_ENABLE)
+ /* include header and FCS in value given to h/w */
+ mss_mfs = skb_shinfo(skb)->gso_size +
+ skb_transport_offset(skb) +
+ ETH_FCS_LEN;
+ else /* TSO */ {
+ mss_mfs = skb_shinfo(skb)->gso_size;
+ /* TCP Sequence Number Source Select
+ * can be set only for TSO
+ */
+ seq_ctrl = 0;
+ }
+ }
+
do {
i--;
entry = macb_tx_ring_wrap(bp, i);
@@ -1325,6 +1361,16 @@ static unsigned int macb_tx_map(struct macb *bp,
if (unlikely(entry == (bp->tx_ring_size - 1)))
ctrl |= MACB_BIT(TX_WRAP);
+ /* First descriptor is header descriptor */
+ if (i == queue->tx_head) {
+ ctrl |= MACB_BF(TX_LSO, lso_ctrl);
+ ctrl |= MACB_BF(TX_TCP_SEQ_SRC, seq_ctrl);
+ } else
+ /* Only set MSS/MFS on payload descriptors
+ * (second or later descriptor)
+ */
+ ctrl |= MACB_BF(MSS_MFS, mss_mfs);
+
/* Set TX buffer descriptor */
macb_set_addr(desc, tx_skb->mapping);
/* desc->addr must be visible to hardware before clearing
@@ -1350,6 +1396,43 @@ static unsigned int macb_tx_map(struct macb *bp,
return 0;
}
+static netdev_features_t macb_features_check(struct sk_buff *skb,
+ struct net_device *dev,
+ netdev_features_t features)
+{
+ unsigned int nr_frags, f;
+ unsigned int hdrlen;
+
+ /* Validate LSO compatibility */
+
+ /* there is only one buffer */
+ if (!skb_is_nonlinear(skb))
+ return features;
+
+ /* length of header */
+ hdrlen = skb_transport_offset(skb);
+ if (ip_hdr(skb)->protocol == IPPROTO_TCP)
+ hdrlen += tcp_hdrlen(skb);
+
+ /* For LSO:
+ * When software supplies two or more payload buffers all payload buffers
+ * apart from the last must be a multiple of 8 bytes in size.
+ */
+ if (!IS_ALIGNED(skb_headlen(skb) - hdrlen, MACB_TX_LEN_ALIGN))
+ return features & ~MACB_NETIF_LSO;
+
+ nr_frags = skb_shinfo(skb)->nr_frags;
+ /* No need to check last fragment */
+ nr_frags--;
+ for (f = 0; f < nr_frags; f++) {
+ const skb_frag_t *frag = &skb_shinfo(skb)->frags[f];
+
+ if (!IS_ALIGNED(skb_frag_size(frag), MACB_TX_LEN_ALIGN))
+ return features & ~MACB_NETIF_LSO;
+ }
+ return features;
+}
+
static inline int macb_clear_csum(struct sk_buff *skb)
{
/* no change for packets without checksum offloading */
@@ -1374,7 +1457,28 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct macb *bp = netdev_priv(dev);
struct macb_queue *queue = &bp->queues[queue_index];
unsigned long flags;
- unsigned int count, nr_frags, frag_size, f;
+ unsigned int desc_cnt, nr_frags, frag_size, f;
+ unsigned int hdrlen;
+ bool is_lso, is_udp = 0;
+
+ is_lso = (skb_shinfo(skb)->gso_size != 0);
+
+ if (is_lso) {
+ is_udp = !!(ip_hdr(skb)->protocol == IPPROTO_UDP);
+
+ /* length of headers */
+ if (is_udp)
+ /* only queue eth + ip headers separately for UDP */
+ hdrlen = skb_transport_offset(skb);
+ else
+ hdrlen = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ if (skb_headlen(skb) < hdrlen) {
+ netdev_err(bp->dev, "Error - LSO headers fragmented!!!\n");
+ /* if this is required, would need to copy to single buffer */
+ return NETDEV_TX_BUSY;
+ }
+ } else
+ hdrlen = min(skb_headlen(skb), bp->max_tx_length);
#if defined(DEBUG) && defined(VERBOSE_DEBUG)
netdev_vdbg(bp->dev,
@@ -1389,18 +1493,22 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
* socket buffer: skb fragments of jumbo frames may need to be
* split into many buffer descriptors.
*/
- count = DIV_ROUND_UP(skb_headlen(skb), bp->max_tx_length);
+ if (is_lso && (skb_headlen(skb) > hdrlen))
+ /* extra header descriptor if also payload in first buffer */
+ desc_cnt = DIV_ROUND_UP((skb_headlen(skb) - hdrlen), bp->max_tx_length) + 1;
+ else
+ desc_cnt = DIV_ROUND_UP(skb_headlen(skb), bp->max_tx_length);
nr_frags = skb_shinfo(skb)->nr_frags;
for (f = 0; f < nr_frags; f++) {
frag_size = skb_frag_size(&skb_shinfo(skb)->frags[f]);
- count += DIV_ROUND_UP(frag_size, bp->max_tx_length);
+ desc_cnt += DIV_ROUND_UP(frag_size, bp->max_tx_length);
}
spin_lock_irqsave(&bp->lock, flags);
/* This is a hard error, log it. */
if (CIRC_SPACE(queue->tx_head, queue->tx_tail,
- bp->tx_ring_size) < count) {
+ bp->tx_ring_size) < desc_cnt) {
netif_stop_subqueue(dev, queue_index);
spin_unlock_irqrestore(&bp->lock, flags);
netdev_dbg(bp->dev, "tx_head = %u, tx_tail = %u\n",
@@ -1414,7 +1522,7 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
/* Map socket buffer for DMA transfer */
- if (!macb_tx_map(bp, queue, skb)) {
+ if (!macb_tx_map(bp, queue, skb, hdrlen)) {
dev_kfree_skb_any(skb);
goto unlock;
}
@@ -2354,6 +2462,7 @@ static const struct net_device_ops macb_netdev_ops = {
.ndo_poll_controller = macb_poll_controller,
#endif
.ndo_set_features = macb_set_features,
+ .ndo_features_check = macb_features_check,
};
/* Configure peripheral capabilities according to device tree
@@ -2560,6 +2669,11 @@ static int macb_init(struct platform_device *pdev)
/* Set features */
dev->hw_features = NETIF_F_SG;
+
+ /* Check LSO capability */
+ if (GEM_BFEXT(PBUF_LSO, gem_readl(bp, DCFG6)))
+ dev->hw_features |= MACB_NETIF_LSO;
+
/* Checksum offload is only available on gem with packet buffer */
if (macb_is_gem(bp) && !(bp->caps & MACB_CAPS_FIFO_MODE))
dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 1216950..d67adad 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -382,6 +382,10 @@
#define GEM_TX_PKT_BUFF_OFFSET 21
#define GEM_TX_PKT_BUFF_SIZE 1
+/* Bitfields in DCFG6. */
+#define GEM_PBUF_LSO_OFFSET 27
+#define GEM_PBUF_LSO_SIZE 1
+
/* Constants for CLK */
#define MACB_CLK_DIV8 0
#define MACB_CLK_DIV16 1
@@ -414,6 +418,10 @@
#define MACB_CAPS_SG_DISABLED 0x40000000
#define MACB_CAPS_MACB_IS_GEM 0x80000000
+/* LSO settings */
+#define MACB_LSO_UFO_ENABLE 0x01
+#define MACB_LSO_TSO_ENABLE 0x02
+
/* Bit manipulation macros */
#define MACB_BIT(name) \
(1 << MACB_##name##_OFFSET)
@@ -545,6 +553,12 @@ struct macb_dma_desc {
#define MACB_TX_LAST_SIZE 1
#define MACB_TX_NOCRC_OFFSET 16
#define MACB_TX_NOCRC_SIZE 1
+#define MACB_MSS_MFS_OFFSET 16
+#define MACB_MSS_MFS_SIZE 14
+#define MACB_TX_LSO_OFFSET 17
+#define MACB_TX_LSO_SIZE 2
+#define MACB_TX_TCP_SEQ_SRC_OFFSET 19
+#define MACB_TX_TCP_SEQ_SRC_SIZE 1
#define MACB_TX_BUF_EXHAUSTED_OFFSET 27
#define MACB_TX_BUF_EXHAUSTED_SIZE 1
#define MACB_TX_UNDERRUN_OFFSET 28
--
2.4.5
^ permalink raw reply related
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: kbuild test robot @ 2016-11-16 10:23 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: kbuild-all, avagin, davem, netdev, xiyou.wangcong,
Nicolas Dichtel
In-Reply-To: <1479285671-1298-1-git-send-email-nicolas.dichtel@6wind.com>
[-- Attachment #1: Type: text/plain, Size: 7593 bytes --]
Hi Nicolas,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/net-nsid-cannot-be-allocated-for-a-dead-netns/20161116-164739
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc
All error/warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
net/core/net_namespace.c: In function 'alloc_netid':
>> arch/sparc/include/asm/atomic_32.h:32:48: error: invalid type argument of '->' (have 'atomic_t {aka struct <anonymous>}')
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^
include/linux/compiler.h:545:25: note: in definition of macro '__ACCESS_ONCE'
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
^
>> arch/sparc/include/asm/atomic_32.h:32:33: note: in expansion of macro 'ACCESS_ONCE'
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^~~~~~~~~~~
net/core/net_namespace.c:162:37: note: in expansion of macro 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~~~~~~~~~~
>> arch/sparc/include/asm/atomic_32.h:32:48: error: invalid type argument of '->' (have 'atomic_t {aka struct <anonymous>}')
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^
include/linux/compiler.h:545:52: note: in definition of macro '__ACCESS_ONCE'
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
^
>> arch/sparc/include/asm/atomic_32.h:32:33: note: in expansion of macro 'ACCESS_ONCE'
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^~~~~~~~~~~
net/core/net_namespace.c:162:37: note: in expansion of macro 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~~~~~~~~~~
>> arch/sparc/include/asm/atomic_32.h:32:48: error: invalid type argument of '->' (have 'atomic_t {aka struct <anonymous>}')
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^
include/linux/compiler.h:546:19: note: in definition of macro '__ACCESS_ONCE'
(volatile typeof(x) *)&(x); })
^
>> arch/sparc/include/asm/atomic_32.h:32:33: note: in expansion of macro 'ACCESS_ONCE'
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^~~~~~~~~~~
net/core/net_namespace.c:162:37: note: in expansion of macro 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~~~~~~~~~~
>> arch/sparc/include/asm/atomic_32.h:32:48: error: invalid type argument of '->' (have 'atomic_t {aka struct <anonymous>}')
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^
include/linux/compiler.h:546:26: note: in definition of macro '__ACCESS_ONCE'
(volatile typeof(x) *)&(x); })
^
>> arch/sparc/include/asm/atomic_32.h:32:33: note: in expansion of macro 'ACCESS_ONCE'
#define atomic_read(v) ACCESS_ONCE((v)->counter)
^~~~~~~~~~~
net/core/net_namespace.c:162:37: note: in expansion of macro 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~~~~~~~~~~
vim +32 arch/sparc/include/asm/atomic_32.h
d550bbd4 arch/sparc/include/asm/atomic_32.h David Howells 2012-03-28 16 #include <asm/cmpxchg.h>
56d36489 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-13 17 #include <asm/barrier.h>
aea1181b arch/sparc/include/asm/atomic_32.h Sam Ravnborg 2011-12-27 18 #include <asm-generic/atomic64.h>
aea1181b arch/sparc/include/asm/atomic_32.h Sam Ravnborg 2011-12-27 19
f5e706ad include/asm-sparc/atomic_32.h Sam Ravnborg 2008-07-17 20 #define ATOMIC_INIT(i) { (i) }
f5e706ad include/asm-sparc/atomic_32.h Sam Ravnborg 2008-07-17 21
4f3316c2 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-26 22 int atomic_add_return(int, atomic_t *);
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 23 int atomic_fetch_add(int, atomic_t *);
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 24 int atomic_fetch_and(int, atomic_t *);
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 25 int atomic_fetch_or(int, atomic_t *);
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 26 int atomic_fetch_xor(int, atomic_t *);
f05a6865 arch/sparc/include/asm/atomic_32.h Sam Ravnborg 2014-05-16 27 int atomic_cmpxchg(atomic_t *, int, int);
1a17fdc4 arch/sparc/include/asm/atomic_32.h Andreas Larsson 2014-11-05 28 int atomic_xchg(atomic_t *, int);
f05a6865 arch/sparc/include/asm/atomic_32.h Sam Ravnborg 2014-05-16 29 int __atomic_add_unless(atomic_t *, int, int);
f05a6865 arch/sparc/include/asm/atomic_32.h Sam Ravnborg 2014-05-16 30 void atomic_set(atomic_t *, int);
f5e706ad include/asm-sparc/atomic_32.h Sam Ravnborg 2008-07-17 31
2291059c arch/sparc/include/asm/atomic_32.h Pranith Kumar 2014-09-23 @32 #define atomic_read(v) ACCESS_ONCE((v)->counter)
f5e706ad include/asm-sparc/atomic_32.h Sam Ravnborg 2008-07-17 33
4f3316c2 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-26 34 #define atomic_add(i, v) ((void)atomic_add_return( (int)(i), (v)))
4f3316c2 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-26 35 #define atomic_sub(i, v) ((void)atomic_add_return(-(int)(i), (v)))
4f3316c2 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-26 36 #define atomic_inc(v) ((void)atomic_add_return( 1, (v)))
4f3316c2 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2014-03-26 37 #define atomic_dec(v) ((void)atomic_add_return( -1, (v)))
f5e706ad include/asm-sparc/atomic_32.h Sam Ravnborg 2008-07-17 38
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 39 #define atomic_and(i, v) ((void)atomic_fetch_and((i), (v)))
3a1adb23 arch/sparc/include/asm/atomic_32.h Peter Zijlstra 2016-04-18 40 #define atomic_or(i, v) ((void)atomic_fetch_or((i), (v)))
:::::: The code at line 32 was first introduced by commit
:::::: 2291059c852706c6f5ffb400366042b7625066cd locking,arch: Use ACCESS_ONCE() instead of cast to volatile in atomic_read()
:::::: TO: Pranith Kumar <bobby.prani@gmail.com>
:::::: CC: Ingo Molnar <mingo@kernel.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 11551 bytes --]
^ permalink raw reply
* Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function
From: Kai-Heng Feng @ 2016-11-16 10:29 UTC (permalink / raw)
To: Mathias Nyman
Cc: Oliver Neukum, Bjørn Mork, Alan Stern, linux-kernel,
linux-usb, netdev
In-Reply-To: <CAAd53p6unhMOPRux+HOB9unLy2Et47gcH5SV6H947-=_gS3DPw@mail.gmail.com>
On Mon, Nov 14, 2016 at 3:34 PM, Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
> On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
>> On 10.11.2016 13:22, Oliver Neukum wrote:
>>>
>>> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
>>>>
>>>> Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>>>>>
>>>>> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>>>>>
>>>>>> Oliver Neukum <oneukum@suse.com> writes:
>>>>>>
>>>>>>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>>>>>>
>>>>>>>> These problems could very well be caused by running at SuperSpeed
>>>>>>>> (USB-3) instead of high speed (USB-2).
>>>>>
>>>>>
>>>>> Yes, it's running at SuperSpeed, on a Kabylake laptop.
>>>>>
>>>>> It does not have this issue on a Broadwell laptop, also running at
>>>>> SuperSpeed.
>>>>
>>>>
>>>> Then I must join Oliver, being very surprised by where in the stack you
>>>> attempt to fix the issue. What you write above indicates a problem in
>>>> pci bridge or usb host controller, doesn't it?
>
> Yes, I was totally wrong about that.
>
>>>
>>>
>>> Indeed. And this means we need an XHCI specialist.
>>> Mathias, we have a failure specific to one implementation of XHCI.
>>>
>>
>>
>> Could be related to resume singnalling time.
>> Does the xhci fix for it in 4.9-rc3 help?
>>
>> commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514
>> xhci: use default USB_RESUME_TIMEOUT when resuming ports.
>>
>> It doesn't directly explain why it would work on Broadwell but not Kabylake,
>> but it resolved very similar cases.
>>
>> If not, then adding dynamic debug for xhci could show something.
>
> I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7,
> on for-usb-next branch.
>
> Now the cdc_mbim still probe failed at the first time, but somehow it
> re-probed again with a success.
>
> I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the
> behavior is the same, first time probed failed, second time probed
> success.
>
> The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled.
I filed a bug report on bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=187861
>
>>
>> -Mathias
>>
^ permalink raw reply
* [PATCH 0/2] replace IS_ERR_OR_NULL by IS_ERR
From: Julia Lawall @ 2016-11-16 10:43 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors, linux-kernel, linux-arm-kernel,
Christophe JAILLET
Replace IS_ERR_OR_NULL by IS_ERR on knav_queue_open calls.
---
drivers/net/ethernet/ti/netcp_core.c | 6 +++---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
^ 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