Re: [PATCH v4 2/2] dt-bindings: net: Add Cortina device tree bindings

2017-05-31 Thread Rob Herring
On Mon, May 29, 2017 at 09:11:31AM +, Bogdan Purcareata wrote:
> Add device tree description info for Cortina 10G phy devices.
> 
> Signed-off-by: Bogdan Purcareata 
> ---
> v3 -> v4:
> - Consistency nit between phy label and reg value.
> - Add CORTINNA trademark info.
> 
> Patch introduced in v3 of the patchset.
> 
>  Documentation/devicetree/bindings/net/cortina.txt | 21 +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/cortina.txt

Acked-by: Rob Herring 


Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Julian Anastasov

Hello,

On Tue, 30 May 2017, Sowmini Varadhan wrote:

> @@ -1650,6 +1689,7 @@ static int neigh_delete(struct sk_buff *skb, struct 
> nlmsghdr *nlh,
>  NEIGH_UPDATE_F_ADMIN,
>  NETLINK_CB(skb).portid);
>   neigh_release(neigh);
> + neigh_remove_one(neigh, tbl);

So, we do not hold reference to neigh while accessing
its fields. I suspect we need to move the table lock from
neigh_remove_one here, for example:

+   write_lock_bh(&tbl->lock);
neigh_release(neigh);
+   neigh_remove_one(neigh, tbl);
+   write_unlock_bh(&tbl->lock);

Otherwise, neigh_forced_gc can call neigh_destroy
where neigh is freed (and replaced by another neigh entry) after
RCU grace period (which can end prematurely if there are no
running RCU read-side critical sections) and I'm not sure if
our thread can be delayed, so that such pointer replacement
can happen unnoticed by us.

Another solution to cause faster removal would be
to cancel the gc_work and to schedule it after 1 jiffie.
It helps when many entries are deleted at once but the
work prefers to just sleep when gc_thresh1 is not reached,
so such solution is not good enough.

Regards

--
Julian Anastasov 


Re: [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2

2017-05-31 Thread Alexander Duyck
On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov  wrote:
> On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
>> On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
>>  wrote:
>> >
>> > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar 
>> > wrote:
>> > >
>> > > Hello,
>> > >
>> > > we found regression on intel card(XL710) with i40e driver.
>> > > Regression is
>> > > about ~45%
>> > > on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6. Regression
>> > > was first
>> > > visible in kernel-4.12.0-0.rc1.
>> > >
>> > > More details about results you can see in uploaded images in
>> > > bugzilla. [0]
>> > >
>> > >
>> > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
>> > >
>> > >
>> > > Best regards, / S pozdravom,
>> > >
>> > > Adrián Tomašov
>> > > Kernel Performance QE
>> > > atoma...@redhat.com
>> >
>> > I have added the i40e driver maintainer and the intel-wired-lan
>> > mailing list so that we can make are developers aware of the issue.
>> >
>> > Thanks.
>> >
>> > - Alex
>>
>> Adam,
>>
>> We are having some issues trying to reproduce what you reported.
>>
>> Can you provide some additional data. Specifically we would be
>> looking
>> for an "ethtool -i", and an "ethtool -S" for the port before and
>> after
>> the test. If you can attach it to the bugzilla that would be
>> appreciated.
>>
>> Thanks.
>>
>> - Alex
>
> Hello Alex,
>
> requested files are updated in bugzilla.
>
> If you have any questions about testing feel free to ask.
>
>
> Best regards,
>
> Adrian

So looking at the data I wonder if we don't have an MTU mismatch in
the network config. I notice the "after" has rx_length_errors being
reported. Recent changes made it so that i40e doesn't support jumbo
frames by default, whereas before we could. You might want to check
for that as that could cause the kind of performance issues you are
seeing.

- Alex


Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Sowmini Varadhan
On (06/01/17 00:41), Julian Anastasov wrote:
> 
>   So, we do not hold reference to neigh while accessing
> its fields. I suspect we need to move the table lock from
> neigh_remove_one here, for example:

good point, let me think over your suggestion carefully (it sounds
right, I want to make sure I dont miss any other race-windows)
and post patch v4 tomorrow..

>   Another solution to cause faster removal would be
> to cancel the gc_work and to schedule it after 1 jiffie.
> It helps when many entries are deleted at once but the
> work prefers to just sleep when gc_thresh1 is not reached,
> so such solution is not good enough.

Right the other drawback of relying on gc for cleanup is
that it doesn't give higher preference to cleaning up FAILED
entries first- so it can end up cleaning up other useful entries
(as I was pointing out to David Ahern)

--Sowmini


Re: [PATCH net-next v2 4/8] net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup

2017-05-31 Thread David Ahern
On 5/31/17 2:11 PM, John Fastabend wrote:
>> @@ -2721,14 +2724,14 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
>> struct nlmsghdr *nlh,
>>  skb->protocol   = htons(ETH_P_IP);
>>  skb->dev= dev;
>>  skb->mark   = mark;
>> -err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev);
>> +err = ip_route_input_rcu(skb, dst, src, rtm->rtm_tos,
>> + dev, &res);
>>  
>>  rt = skb_rtable(skb);
>>  if (err == 0 && rt->dst.error)
>>  err = -rt->dst.error;
>>  } else {
>> -rt = ip_route_output_key(net, &fl4);
>> -
>> +rt = ip_route_output_key_hash_rcu(net, &fl4, &res, skb);
>>  err = 0;
>>  if (IS_ERR(rt))
>>  err = PTR_ERR(rt);
>> @@ -2737,7 +2740,6 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
>> struct nlmsghdr *nlh,
>>  if (err)
>>  goto errout_free;
>>  
>> -skb_dst_set(skb, &rt->dst);
> 
> 
> Why did you remove this? Neither ip_route_input() or ip_route_output_key()
> seem to justify this with a quick scan on my side. Feel free to correct me
> here.
> 

original patch was done in January. I forget why I took it out. It is
clearly needed to release the dst. Might as well undo the argument
change to rt_fill_info since it is attached to the skb. Something like
this (whitespace damaged on paste - stupid Mac):

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f1f2e5aaa2d6..93cca12a8319 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2547,8 +2547,9 @@ EXPORT_SYMBOL_GPL(ip_route_output_flow);
 /* called with rcu_read_lock held */
 static int rt_fill_info(struct net *net,  __be32 dst, __be32 src, u32
table_id,
struct flowi4 *fl4, struct sk_buff *skb, u32 portid,
-   u32 seq, struct rtable *rt)
+   u32 seq)
 {
+   struct rtable *rt = skb_rtable(skb);
struct rtmsg *r;
struct nlmsghdr *nlh;
unsigned long expires = 0;
@@ -2750,6 +2751,8 @@ static int inet_rtm_getroute(struct sk_buff
*in_skb, struct nlmsghdr *nlh,
if (err)
goto errout_free;

+   skb_dst_set(skb, &rt->dst);
+
if (rtm->rtm_flags & RTM_F_NOTIFY)
rt->rt_flags |= RTCF_NOTIFY;

@@ -2763,8 +2766,7 @@ static int inet_rtm_getroute(struct sk_buff
*in_skb, struct nlmsghdr *nlh,
fl4.flowi4_tos, res.fi, 0);
else
err = rt_fill_info(net, dst, src, table_id, &fl4, skb,
-  NETLINK_CB(in_skb).portid,
nlh->nlmsg_seq,
-  rt);
+  NETLINK_CB(in_skb).portid,
nlh->nlmsg_seq);
if (err < 0)
goto errout_free;


Seems to work for me.


Re: [PATCH v2 net 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume

2017-05-31 Thread Florian Fainelli
On 05/31/2017 03:29 AM, Leonard Crestez wrote:
> These bits seem to be lost after a suspend/resume cycle so just set them
> again. Do this by splitting the handling of these bits into a function
> that is also called on resume.
> 
> This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.
> 
> Signed-off-by: Leonard Crestez 

Reviewed-by: Florian Fainelli 
-- 
Florian


Re: [PATCH v2 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties

2017-05-31 Thread Florian Fainelli
On 05/31/2017 03:29 AM, Leonard Crestez wrote:
> Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same
> register values can be set through the micrel phy driver by using dts
> properties.
> 
> This seems preferable and allows cleanly fixing suspend/resume.
> 
> Signed-off-by: Leonard Crestez 
> Reviewed-by: Fabio Estevam 

Reviewed-by: Florian Fainelli 
-- 
Florian


Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2017-05-31

2017-05-31 Thread David Miller
From: Jeff Kirsher 
Date: Wed, 31 May 2017 03:48:47 -0700

> This series contains updates to i40e and i40evf only.
> 
> Jesse provides a couple of fixes, starting with cleaning up duplicate
> lines of code.  Fixed a missing line which enables RSS as a negotiated
> feature.  Since the VF does not have any way of reporting FCoE enabled,
> so just force the code to always report FCoE as disabled.
> 
> Jake provides several fixes and changes, starting with fixing a race
> condition in i40e.  The hardware has a limitation on transmit PTP packets,
> which requires us to limit the driver to timestamping a single packet at
> once.  This is done using a state bitlock which enforces that only one
> timestamp request is honored at a time, unfortunately this suffers from
> a race condition.  Fixed a corner case where we failed to cleanup the
> bit lock after a failed transmit, and resulted in a state bit being
> locked forever.  Added a new statistic which tracks when a transmit
> timestamp request is skipped/ignored, since the driver can only handle
> one transmit timestamp request at a time.
> 
> Christophe Jaillet fixes a NULL pointer dereference if kzalloc fails.

Pulled, thanks Jeff.


Re: [net-next 00/15][pull request] 10GbE Intel Wired LAN Driver Updates 2017-05-31

2017-05-31 Thread David Miller
From: Jeff Kirsher 
Date: Wed, 31 May 2017 14:19:21 -0700

> This series contains updates to ixgbe and ixgbevf only.

Pulled, thanks Jeff.


Re: [PATCH net-next 0/9] nfp: move BPF offload code into app

2017-05-31 Thread David Miller
From: Jakub Kicinski 
Date: Wed, 31 May 2017 08:06:42 -0700

> This series moves the eBPF offload code out of netdev/vNIC handling and
> starts building the nfp_app.  Port init is moved into the apps as well
> because various apps associate vNICs, representors with ports differently.
> 
> First patch adds a helper for updating tc stats which has been waiting 
> in my tree to be included in any moderately related series.
> 
> Next series will bring communicating with FW using control messages,
> then representors, BPF maps, tc flower... :)

Looks good, series applied.


Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Sowmini Varadhan
On (06/01/17 00:41), Julian Anastasov wrote:
> 
>   So, we do not hold reference to neigh while accessing
> its fields. I suspect we need to move the table lock from
> neigh_remove_one here, for example:

Another thought is to have neigh_remove_one to remove
a neigh only if it is NUD_FAILED - that may potentially remove
more than one entry, but that's probably harmless?

--Sowmini



Re: loosing netdevices with namespaces and unshare?

2017-05-31 Thread Cong Wang
On Wed, May 31, 2017 at 11:11 AM, Harald Welte  wrote:
> I mean, what is the *use case* for loosing any refrence to a physical
> network device and unregistering it from the stack?  Is there any API by
> which a new netdevice structure can be instantiated on the actual
> hardware?  Registering the netdev is what the driver does during
> discovering the system hardware.  If there's a method to "automagically"
> loose devices, at the very least I wold expect some reasonable method to
> resurrect them.  Unloading the kernel module and reloading it is for
> sure not elegant, particularly not if you have multiple Ethernet
> devices/ports sharing the same driver.
>
> One could e.g. also think of something like a special namespace that
> collects all the "orphan" netdevices.  Something analogous to the old
> Unix tradition of "pid 1" collecting all the orphan tasks whose parents
> died.  Transferring them into that "netdev orphanage" could
> automatically set the link down so that no accidential
> routing/forwarding of traffic between the devices is possible.

Understand.

But you have other choices than using the physical interface
directly in non-root ns, for example, creating a virtual pair and
connect it with the physical one with a bridge. There are various
ways to achieve this.


Re: [PATCH net-next 6/9] bpf: fix stack_depth usage by test_bpf.ko

2017-05-31 Thread Alexei Starovoitov

On 5/31/17 11:45 AM, Alexei Starovoitov wrote:

On 5/31/17 11:43 AM, David Miller wrote:

From: Alexei Starovoitov 
Date: Wed, 31 May 2017 11:39:37 -0700


On 5/31/17 11:15 AM, David Miller wrote:

From: Alexei Starovoitov 
Date: Tue, 30 May 2017 13:31:32 -0700


test_bpf.ko doesn't call verifier before selecting interpreter or
JITing,
hence the tests need to manually specify the amount of stack they
consume.

Signed-off-by: Alexei Starovoitov 
Acked-by: Daniel Borkmann 


I do not like this and the previous patch, it seems so error prone.


in what sense 'error prone' ?


In the sense that a human computes these numbers, and nothing checks
if it is correct or not until program perhaps crashes if the value is
wrong.


right. that's how all these tests are.
See bpf_fill_ld_abs_vlan_push_pop() for example.
If that codegen has a bug, it will crash the kernel.
That's why it's done from kernel module to do things
that user space cannot do.


btw, when added a bunch of these '.stack_depth = 40'
I was thinking to randomize these values in [40, 512]
range to stress test interpreter and JITs more,
but then decided not to do that to avoid questions
why these numbers don't match the instructions.
Now I'm thinking we should actually do it for two reasons:
- to stress test stuff
- and to demonstrate more clearly that test_bpf.ko can
really do things that user space cannot and that's the
purpose of this .ko
Thoughts?



Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Julian Anastasov

Hello,

On Wed, 31 May 2017, Sowmini Varadhan wrote:

> On (06/01/17 00:41), Julian Anastasov wrote:
> > 
> > So, we do not hold reference to neigh while accessing
> > its fields. I suspect we need to move the table lock from
> > neigh_remove_one here, for example:
> 
> good point, let me think over your suggestion carefully (it sounds
> right, I want to make sure I dont miss any other race-windows)
> and post patch v4 tomorrow..

Another problem is that neigh_update() changes the
state but before we go and unlink the entry another CPU
can reactivate the entry, i.e. NUD_INCOMPLETE entered
in __neigh_event_send(). So, there will be always some
small window where surprises can happen and the entry is
not really deleted.

Checking for NUD_FAILED may not be needed, the
atomic_read(&n->refcnt) == 1 check under lock ensures
that we are in some state without timer, i.e. not in
NUD_INCOMPLETE, so it is ok to remove the entry.

> > Another solution to cause faster removal would be
> > to cancel the gc_work and to schedule it after 1 jiffie.
> > It helps when many entries are deleted at once but the
> > work prefers to just sleep when gc_thresh1 is not reached,
> > so such solution is not good enough.
> 
> Right the other drawback of relying on gc for cleanup is
> that it doesn't give higher preference to cleaning up FAILED
> entries first- so it can end up cleaning up other useful entries
> (as I was pointing out to David Ahern)

I see, ok.

Regards

--
Julian Anastasov 


Re: net/ipv6: use-after-free in ip6_dst_ifdown

2017-05-31 Thread Cong Wang
On Wed, May 31, 2017 at 9:55 AM, Eric Dumazet  wrote:
> On Wed, May 31, 2017 at 9:45 AM, Cong Wang  wrote:
>> On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov  
>> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
>>>
>>> Unfortunately it's not reproducible.
>>>
>>> ==
>>> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 
>>> net/ipv6/route.c:422
>>> Read of size 8 at addr 88006afa4ad8 by task syz-executor6/23554
>>
>>
>> This one is very interesting.
>>
>> Here we are at:
>>
>> if (dev != loopback_dev) {
>> if (idev && idev->dev == dev) {
>> struct inet6_dev *loopback_idev =
>> in6_dev_get(loopback_dev);
>> if (loopback_idev) {
>> rt->rt6i_idev = loopback_idev;
>> in6_dev_put(idev);
>> }
>> }
>> }
>>
>> clearly no skb involved, it looks like idev is the one used-after-free.
>>
>> But below it is actually skb which is allocated and freed...
>>
>
> skb->head was a kmalloc(X)   with X = 1024 in this case.
>
> So it is very possible the two different objects (skb->head and idev )
>  were accidentally using the same slab (1024 bytes).
>
> KASAN only remember the last pair of alloc/free for a particular memory zone.

I see. So that memory area was freed for idev and then allocated
and freed again for skb->head, this happened so quick that the
use-after-free happened after it... Therefore we lost the track on where
we free the idev.


Re: [PATCH net-next 1/1] netvsc: Add #include's for csum_* function declarations

2017-05-31 Thread Joe Perches
On Wed, 2017-05-31 at 13:59 -0400, David Miller wrote:
> From: Michael Kelley 
> Date: Tue, 30 May 2017 10:43:04 -0700
> 
> > Add direct #include statements for declarations of csum_tcpudp_magic()
> > and csum_ipv6_magic(). While the needed #include's are picked up
> > indirectly for the x86 architecture, they aren't on other
> > architectures, resulting in compile errors.
> > 
> > Signed-off-by: Michael Kelley 
> 
> Applied, thank you.

Did you apply this one or the v2?



Re: loosing netdevices with namespaces and unshare?

2017-05-31 Thread Harald Welte
Hi Cong,

On Wed, May 31, 2017 at 03:40:33PM -0700, Cong Wang wrote:
> But you have other choices than using the physical interface
> directly in non-root ns, for example, creating a virtual pair and
> connect it with the physical one with a bridge. There are various
> ways to achieve this.

Yes, but then those "workarounds" expose the given physical device to
the root namespace, which is exactly what I try to avoid here.  The
interface has no purpose outside of the specific target namespace, and
under no circumstances should the various applications on a normal Linux
system (whether it's network manager or whatever else) start to use the
device.  The same also applies to the kernel itself.  It is not
desirable to have the "root netns" start to do things like ipv6
stateless autoconfiguration, etc.

I of course know that all of those things can be individually disabled.

I just think having a physical netdev inside "single application"
namespaces is more complicated than it could be.

However, I have sufficiently made my argument clear, and I understand
that you don't share my concern.  This is perfectly fine. We agree to
disagree :)

I simply have to find the least intrusive work-around to my liking for
the intentional but so far undocumented behavior of netdevices vanishing
into thin air.  I'll manage.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)


Re: [PATCH net-next 1/1] netvsc: Add #include's for csum_* function declarations

2017-05-31 Thread David Miller
From: Joe Perches 
Date: Wed, 31 May 2017 15:59:31 -0700

> On Wed, 2017-05-31 at 13:59 -0400, David Miller wrote:
>> From: Michael Kelley 
>> Date: Tue, 30 May 2017 10:43:04 -0700
>> 
>> > Add direct #include statements for declarations of csum_tcpudp_magic()
>> > and csum_ipv6_magic(). While the needed #include's are picked up
>> > indirectly for the x86 architecture, they aren't on other
>> > architectures, resulting in compile errors.
>> > 
>> > Signed-off-by: Michael Kelley 
>> 
>> Applied, thank you.
> 
> Did you apply this one or the v2?

I got v2 which used net/checksum.h et al.


Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread David Miller
From: Sowmini Varadhan 
Date: Tue, 30 May 2017 16:52:26 -0700


Just as a side note in the future, if you could fix the date
and time on your computer, that would be awesome :-)


Re: [PATCH net-next 0/9] bpf: stack depth tracking

2017-05-31 Thread David Miller
From: Alexei Starovoitov 
Date: Tue, 30 May 2017 13:31:26 -0700

> Introduce tracking of bpf program stack depth in the verifier and use that
> info to reduce bpf program stack consumption in the interpreter and x64 JIT.
> Other JITs can take advantage of it as well in the future.
> Most of the programs consume very little stack, so it's good optimization
> in general and it's the first step toward bpf to bpf function calls.
> 
> Also use internal opcode for bpf_tail_call() marking to make clear
> that jmp|call|x opcode is not uapi and may be used for actual
> indirect call opcode in the future.

Series applied, thanks Alexei.


Re: [PATCH net-next 6/9] bpf: fix stack_depth usage by test_bpf.ko

2017-05-31 Thread David Miller
From: Alexei Starovoitov 
Date: Wed, 31 May 2017 15:41:09 -0700

> On 5/31/17 11:45 AM, Alexei Starovoitov wrote:
>> On 5/31/17 11:43 AM, David Miller wrote:
>>> From: Alexei Starovoitov 
>>> Date: Wed, 31 May 2017 11:39:37 -0700
>>>
 On 5/31/17 11:15 AM, David Miller wrote:
> From: Alexei Starovoitov 
> Date: Tue, 30 May 2017 13:31:32 -0700
>
>> test_bpf.ko doesn't call verifier before selecting interpreter or
>> JITing,
>> hence the tests need to manually specify the amount of stack they
>> consume.
>>
>> Signed-off-by: Alexei Starovoitov 
>> Acked-by: Daniel Borkmann 
>
> I do not like this and the previous patch, it seems so error prone.

 in what sense 'error prone' ?
>>>
>>> In the sense that a human computes these numbers, and nothing checks
>>> if it is correct or not until program perhaps crashes if the value is
>>> wrong.
>>
>> right. that's how all these tests are.
>> See bpf_fill_ld_abs_vlan_push_pop() for example.
>> If that codegen has a bug, it will crash the kernel.
>> That's why it's done from kernel module to do things
>> that user space cannot do.
> 
> btw, when added a bunch of these '.stack_depth = 40'
> I was thinking to randomize these values in [40, 512]
> range to stress test interpreter and JITs more,
> but then decided not to do that to avoid questions
> why these numbers don't match the instructions.
> Now I'm thinking we should actually do it for two reasons:
> - to stress test stuff
> - and to demonstrate more clearly that test_bpf.ko can
> really do things that user space cannot and that's the
> purpose of this .ko
> Thoughts?

Ok I've applied the base series for now.

Feel free to build that kind of stuff on top.

Thanks for explaining.


Re: [PATCH v2 net-next 0/8] Introduce bpf ID

2017-05-31 Thread David Miller
From: Martin KaFai Lau 
Date: Wed, 31 May 2017 11:58:54 -0700

> This patch series:
> 1) Introduce ID for both bpf_prog and bpf_map.
> 2) Add bpf commands to iterate the prog IDs and map
>IDs of the system.
> 3) Add bpf commands to get a prog/map fd from an ID
> 4) Add bpf command to get prog/map info from a fd.
>The prog/map info is a jump start in this patchset
>and it is not meant to be a complete list.  They can
>be extended in the future patches.
> 
> v2:
> Compiler warning fixes:
> - Remove lockdep_is_held() usage.  Add comment
>   to explain the lock situation instead.
> - Add static for idr related variables
> - Add __user to the uattr param in bpf_prog_get_info_by_fd()
>   and bpf_map_get_info_by_fd().

Series applied, thanks Martin.


Re: net/ipv4: use-after-free in add_grec

2017-05-31 Thread Cong Wang
On Wed, May 31, 2017 at 9:12 AM, Eric Dumazet  wrote:
> On Wed, 2017-05-31 at 11:46 +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
>>
>> Unfortunately it's not reproducible.
>>
>> ==
>> BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
>> Read of size 8 at addr 88003053c1a0 by task swapper/0/0
>>
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>>  
>>  __dump_stack lib/dump_stack.c:16 [inline]
>>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>>  print_address_description+0x73/0x280 mm/kasan/report.c:252
>>  kasan_report_error mm/kasan/report.c:351 [inline]
>>  kasan_report+0x22b/0x340 mm/kasan/report.c:408
>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
>>  add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
>>  igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
>>  igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
>> IPVS: length: 51 != 8
>>  call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
>>  expire_timers kernel/time/timer.c:1307 [inline]
>>  __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
>>  run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
>>  __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
>>  invoke_softirq kernel/softirq.c:364 [inline]
>>  irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>>  exiting_irq arch/x86/include/asm/apic.h:652 [inline]
>>  smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
>>  apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
>> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
>> RSP: 0018:85a079a8 EFLAGS: 0282 ORIG_RAX: ff10
>> RAX: dc20 RBX: 10b40f38 RCX: 
>> RDX:  RSI: 0001 RDI: 85a2a9e4
>> RBP: 85a079a8 R08:  R09: 
>> R10:  R11:  R12: dc00
>> R13: 85a07a60 R14: 86171338 R15: 10b40f5b
>>  
>>  arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
>>  default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
>>  arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
>>  default_idle_call+0x36/0x60 kernel/sched/idle.c:98
>>  cpuidle_idle_call kernel/sched/idle.c:156 [inline]
>>  do_idle+0x348/0x420 kernel/sched/idle.c:245
>>  cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
>>  rest_init+0x18d/0x1a0 init/main.c:415
>>  start_kernel+0x747/0x779 init/main.c:679
>>  x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
>>  x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
>>  secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304
>>
>> Allocated by task 30543:
>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>  set_track mm/kasan/kasan.c:525 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
>>  kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>  kmalloc include/linux/slab.h:492 [inline]
>>  kzalloc include/linux/slab.h:665 [inline]
>>  ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
>>  ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
>>  ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
>>  do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
>>  ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
>>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
>>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
>>  SYSC_setsockopt net/socket.c:1798 [inline]
>>  SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
>>  entry_SYSCALL_64_fastpath+0x1f/0xbe
>>
>> Freed by task 30543:
>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>  set_track mm/kasan/kasan.c:525 [inline]
>>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
>>  slab_free_hook mm/slub.c:1357 [inline]
>>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>>  slab_free mm/slub.c:2961 [inline]
>>  kfree+0xe8/0x2b0 mm/slub.c:3882
>>  ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
>>  ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
>>  ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
>>  inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
>>  sock_release+0x8d/0x1e0 net/socket.c:597
>>  sock_close+0x16/0x20 net/socket.c:1072
>>  __fput+0x332/0x7f0 fs/file_table.c:209
>>  fput+0x15/0x20 fs/file_table.c:245
>>  task_work_run+0x19b/0x270 kernel/task_work.c:116
>>  exit_task_work include/linux/task_work.h:21 [inline]
>>  do_exit+0x18a3/0x2820 kernel/exit.c:878
>>  do_group_exit+0x149/0x420 kernel/exit.c:982
>>  get_signal+0x76d/0x1790 kernel/signal.c:2318
>>  do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
>>  exit_to_usermode_loop+0x17a/0x210 arch/x86/entry/common.c:157
>>  prepare_e

Re: net/ipv4: use-after-free in add_grec

2017-05-31 Thread Eric Dumazet
On Wed, May 31, 2017 at 4:49 PM, Cong Wang  wrote:
> On Wed, May 31, 2017 at 9:12 AM, Eric Dumazet  wrote:
>> On Wed, 2017-05-31 at 11:46 +0200, Andrey Konovalov wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
>>>
>>> Unfortunately it's not reproducible.
>>>
>>> ==
>>> BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
>>> Read of size 8 at addr 88003053c1a0 by task swapper/0/0
>>>
>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  
>>>  __dump_stack lib/dump_stack.c:16 [inline]
>>>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>>>  print_address_description+0x73/0x280 mm/kasan/report.c:252
>>>  kasan_report_error mm/kasan/report.c:351 [inline]
>>>  kasan_report+0x22b/0x340 mm/kasan/report.c:408
>>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
>>>  add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
>>>  igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
>>>  igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
>>> IPVS: length: 51 != 8
>>>  call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
>>>  expire_timers kernel/time/timer.c:1307 [inline]
>>>  __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
>>>  run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
>>>  __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
>>>  invoke_softirq kernel/softirq.c:364 [inline]
>>>  irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>>>  exiting_irq arch/x86/include/asm/apic.h:652 [inline]
>>>  smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
>>>  apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
>>> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
>>> RSP: 0018:85a079a8 EFLAGS: 0282 ORIG_RAX: ff10
>>> RAX: dc20 RBX: 10b40f38 RCX: 
>>> RDX:  RSI: 0001 RDI: 85a2a9e4
>>> RBP: 85a079a8 R08:  R09: 
>>> R10:  R11:  R12: dc00
>>> R13: 85a07a60 R14: 86171338 R15: 10b40f5b
>>>  
>>>  arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
>>>  default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
>>>  arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
>>>  default_idle_call+0x36/0x60 kernel/sched/idle.c:98
>>>  cpuidle_idle_call kernel/sched/idle.c:156 [inline]
>>>  do_idle+0x348/0x420 kernel/sched/idle.c:245
>>>  cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
>>>  rest_init+0x18d/0x1a0 init/main.c:415
>>>  start_kernel+0x747/0x779 init/main.c:679
>>>  x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
>>>  x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
>>>  secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304
>>>
>>> Allocated by task 30543:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>>  set_track mm/kasan/kasan.c:525 [inline]
>>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
>>>  kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>>  kmalloc include/linux/slab.h:492 [inline]
>>>  kzalloc include/linux/slab.h:665 [inline]
>>>  ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
>>>  ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
>>>  ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
>>>  do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
>>>  ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
>>>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
>>>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
>>>  SYSC_setsockopt net/socket.c:1798 [inline]
>>>  SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
>>>  entry_SYSCALL_64_fastpath+0x1f/0xbe
>>>
>>> Freed by task 30543:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>>  set_track mm/kasan/kasan.c:525 [inline]
>>>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
>>>  slab_free_hook mm/slub.c:1357 [inline]
>>>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>>>  slab_free mm/slub.c:2961 [inline]
>>>  kfree+0xe8/0x2b0 mm/slub.c:3882
>>>  ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
>>>  ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
>>>  ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
>>>  inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
>>>  sock_release+0x8d/0x1e0 net/socket.c:597
>>>  sock_close+0x16/0x20 net/socket.c:1072
>>>  __fput+0x332/0x7f0 fs/file_table.c:209
>>>  fput+0x15/0x20 fs/file_table.c:245
>>>  task_work_run+0x19b/0x270 kernel/task_work.c:116
>>>  exit_task_work include/linux/task_work.h:21 [inline]
>>>  do_exit+0x18a3/0x2820 kernel/exit.c:878
>>>  do_group_exit+0x149/0x420 kernel/exit.c:982
>>>  get_signal+0x76d/0x1790 ker

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Larry Finger

On 05/31/2017 10:32 AM, Michael Büsch wrote:

On Wed, 31 May 2017 13:26:43 +0300
Kalle Valo  wrote:


Jia-Ju Bai  writes:


The driver may sleep under a spin lock, and the function call path is:
b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
   b43legacy_synchronize_irq
 synchronize_irq --> may sleep

To fix it, the lock is released before b43legacy_synchronize_irq, and the
lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
b/drivers/net/wireless/broadcom/b43legacy/main.c
index f1e3dad..31ead21 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
ieee80211_hw *hw,
b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
  
  	if (changed & BSS_CHANGED_BSSID) {

+   spin_unlock_irqrestore(&wl->irq_lock, flags);
b43legacy_synchronize_irq(dev);
+   spin_lock_irqsave(&wl->irq_lock, flags);


To me this looks like a fragile workaround and not a real fix. You can
easily add new race conditions with releasing the lock like this.




I think releasing the lock possibly is fine. It certainly is better than
sleeping with a lock held.
We disabled the device interrupts just before this line.

However I think the synchronize_irq should be outside of the
conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
two lines above)
I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
is set.


On the other hand b43 does not have this irq-disabling foobar anymore.
So somebody must have removed it. Maybe you can find the commit that
removed this stuff from b43 and port it to b43legacy?


So I would vote for moving the synchronize_irq up outside of the
conditional and put the unlock/lock sequence around it.
And as a second patch on top of that try to remove this stuff
altogether like b43 did.


The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch 
Date:   Fri Sep 4 22:51:29 2009 +0200

b43: Use a threaded IRQ handler

Use a threaded IRQ handler to allow locking the mutex and
sleeping while executing an interrupt.
This removes usage of the irq_lock spinlock, but introduces
a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

Signed-off-by: Michael Buesch 
Tested-by: Larry Finger 
Signed-off-by: John W. Linville 

I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I can 
test in a PowerBook G4.


I agree with Michael that this is the way to go. Both of Jia-Ju's patches should 
be rejected.


Larry




Re: net/ipv4: use-after-free in add_grec

2017-05-31 Thread Eric Dumazet
On Wed, 2017-05-31 at 16:55 -0700, Eric Dumazet wrote:

> The issue here is the timer firing while ip_mc_clear_src() has been
> already called.
> 
> My patch should fix the problem.
> 
> Or another one using del_timer_sync() instead of del_timer() in
> igmp_stop_timer(), but such a change would be more invasive,
> since the del_timer_sync() would need to happen while im->lock
> spinlock is not held.

BTW, I guess that Andrey could try to add a delay to trigger the bug
more often.

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 
44fd86de2823dd17de16276a8ec01b190e69b8b4..84fff17daab0832c470a613b29b2aaade07cec0a
 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -798,7 +798,7 @@ static void igmp_timer_expire(unsigned long data)
}
im->reporter = 1;
spin_unlock(&im->lock);
-
+   udelay(1);
if (IGMP_V1_SEEN(in_dev))
igmp_send_report(in_dev, im, IGMP_HOST_MEMBERSHIP_REPORT);
else if (IGMP_V2_SEEN(in_dev))




RE: [PATCH net-next 2/2] bpf: Remove the capability check for cgroup skb eBPF program

2017-05-31 Thread YUAN Linyu
hi

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Chenbo Feng
> Sent: Thursday, June 01, 2017 2:07 AM
> To: netdev@vger.kernel.org; David Miller
> Cc: Lorenzo Colitti; Chenbo Feng
> Subject: [PATCH net-next 2/2] bpf: Remove the capability check for cgroup skb
> eBPF program
> - if (type != BPF_PROG_TYPE_SOCKET_FILTER
> && !capable(CAP_SYS_ADMIN))
> + if (type != BPF_PROG_TYPE_SOCKET_FILTER
> + && type != BPF_PROG_TYPE_CGROUP_SKB
> + && !capable(CAP_SYS_ADMIN))

checkpatch.pl prefer put && at end of line

>   return -EPERM;
> 
>   /* plain bpf_prog allocation */
> --
> 2.7.4



Re: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line

2017-05-31 Thread Joe Perches
On Wed, 2017-05-31 at 10:45 -0700, Felix Manlunas wrote:
> > From: Satanand Burla 
> 
> > Signed-off-by: Satanand Burla 
> > Signed-off-by: Derek Chickles 
> > Signed-off-by: Felix Manlunas 
> ---
>  drivers/net/ethernet/cavium/liquidio/lio_ethtool.c |  8 

Much better would be not to separate out the object onto
multiple lines, but use temporaries to make the code "volume"
much smaller and it also saves a bit of object code.

For this file, perhaps

Subject: [PATCH] liquidio: Reduce dereferences

Multiple dereferences of the same object are hard to read.

Use temporaries to reduce the code volume and also reduce
overall object size a bit.

$ size drivers/net/ethernet/cavium/liquidio/lio_ethtool.o*
   text    data bss dec hex filename
  22038   0   0   22038    5616 
drivers/net/ethernet/cavium/liquidio/lio_ethtool.o.new
  22246   0   0   22246    56e6 
drivers/net/ethernet/cavium/liquidio/lio_ethtool.o.old

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 450 ++---
 1 file changed, 215 insertions(+), 235 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c 
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 579dc7336f58..bd2db6382377 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -786,257 +786,245 @@ lio_get_ethtool_stats(struct net_device *netdev,
    struct lio *lio = GET_LIO(netdev);
    struct octeon_device *oct_dev = lio->oct_dev;
    struct net_device_stats *netstats = &netdev->stats;
+   struct nic_tx_stats *tstats = &oct_dev->link_stats.fromhost;
+   struct nic_rx_stats *rstats = &oct_dev->link_stats.fromwire;
    int i = 0, j;
 
    netdev->netdev_ops->ndo_get_stats(netdev);
    octnet_get_link_stats(netdev);
 
-   /*sum of oct->droq[oq_no]->stats->rx_pkts_received */
+   /* sum of oct->droq[oq_no]->stats->rx_pkts_received */
    data[i++] = CVM_CAST64(netstats->rx_packets);
-   /*sum of oct->instr_queue[iq_no]->stats.tx_done */
+   /* sum of oct->instr_queue[iq_no]->stats.tx_done */
    data[i++] = CVM_CAST64(netstats->tx_packets);
-   /*sum of oct->droq[oq_no]->stats->rx_bytes_received */
+   /* sum of oct->droq[oq_no]->stats->rx_bytes_received */
    data[i++] = CVM_CAST64(netstats->rx_bytes);
-   /*sum of oct->instr_queue[iq_no]->stats.tx_tot_bytes */
+   /* sum of oct->instr_queue[iq_no]->stats.tx_tot_bytes */
    data[i++] = CVM_CAST64(netstats->tx_bytes);
    data[i++] = CVM_CAST64(netstats->rx_errors);
    data[i++] = CVM_CAST64(netstats->tx_errors);
-   /*sum of oct->droq[oq_no]->stats->rx_dropped +
-    *oct->droq[oq_no]->stats->dropped_nodispatch +
-    *oct->droq[oq_no]->stats->dropped_toomany +
-    *oct->droq[oq_no]->stats->dropped_nomem
+   /* sum of oct->droq[oq_no]->stats->rx_dropped +
+    * oct->droq[oq_no]->stats->dropped_nodispatch +
+    * oct->droq[oq_no]->stats->dropped_toomany +
+    * oct->droq[oq_no]->stats->dropped_nomem
     */
    data[i++] = CVM_CAST64(netstats->rx_dropped);
-   /*sum of oct->instr_queue[iq_no]->stats.tx_dropped */
+   /* sum of oct->instr_queue[iq_no]->stats.tx_dropped */
    data[i++] = CVM_CAST64(netstats->tx_dropped);
 
    /* firmware tx stats */
-   /*per_core_stats[cvmx_get_core_num()].link_stats[mdata->from_ifidx].
-    *fromhost.fw_total_sent
+   /* per_core_stats[cvmx_get_core_num()].link_stats[mdata->from_ifidx].
+    * fromhost.fw_total_sent
     */
-   data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_total_sent);
-   /*per_core_stats[i].link_stats[port].fromwire.fw_total_fwd */
-   data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_total_fwd);
-   /*per_core_stats[j].link_stats[i].fromhost.fw_err_pko */
-   data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_err_pko);
-   /*per_core_stats[j].link_stats[i].fromhost.fw_err_link */
-   data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_err_link);
-   /*per_core_stats[cvmx_get_core_num()].link_stats[idx].fromhost.
-    *fw_err_drop
+   data[i++] = CVM_CAST64(tstats->fw_total_sent);
+   /* per_core_stats[i].link_stats[port].fromwire.fw_total_fwd */
+   data[i++] = CVM_CAST64(tstats->fw_total_fwd);
+   /* per_core_stats[j].link_stats[i].fromhost.fw_err_pko */
+   data[i++] = CVM_CAST64(tstats->fw_err_pko);
+   /* per_core_stats[j].link_stats[i].fromhost.fw_err_link */
+   data[i++] = CVM_CAST64(tstats->fw_err_link);
+   /* per_core_stats[cvmx_get_core_num()].link_stats[idx].fromhost.
+    * fw_err_drop
     */
-   data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_err_drop);
+   data[i++] = CVM_CAST64(tstats->fw_err_drop);
 
-   /*per_core_stats[cvmx_get_core_num()].link_stats[idx].fromhost.fw_tso */
-   data[i++] = CVM_C

[PATCH] xfrm: fix xfrm_dev_event() missing when compile without CONFIG_XFRM_OFFLOAD

2017-05-31 Thread Hangbin Liu
In commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") we
make xfrm_device.o only compiled when enable option CONFIG_XFRM_OFFLOAD.
But this will make xfrm_dev_event() missing if we only enable default XFRM
options.

So when we set down and unregister an interface with IPsec on it. there
will no xfrm_garbage_collect(), which will cause dev usage count hold and
get error like:

unregister_netdevice: waiting for  to become free. Usage count = 4

Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
Signed-off-by: Hangbin Liu 
---
 net/xfrm/Makefile  | 3 +--
 net/xfrm/xfrm_device.c | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/xfrm/Makefile b/net/xfrm/Makefile
index abf81b3..55b2ac3 100644
--- a/net/xfrm/Makefile
+++ b/net/xfrm/Makefile
@@ -4,8 +4,7 @@
 
 obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_hash.o \
  xfrm_input.o xfrm_output.o \
- xfrm_sysctl.o xfrm_replay.o
-obj-$(CONFIG_XFRM_OFFLOAD) += xfrm_device.o
+ xfrm_sysctl.o xfrm_replay.o xfrm_device.o
 obj-$(CONFIG_XFRM_STATISTICS) += xfrm_proc.o
 obj-$(CONFIG_XFRM_ALGO) += xfrm_algo.o
 obj-$(CONFIG_XFRM_USER) += xfrm_user.o
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 574e6f3..5aba036 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_XFRM_OFFLOAD
 int validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t features)
 {
int err;
@@ -137,6 +138,7 @@ bool xfrm_dev_offload_ok(struct sk_buff *skb, struct 
xfrm_state *x)
return true;
 }
 EXPORT_SYMBOL_GPL(xfrm_dev_offload_ok);
+#endif
 
 int xfrm_dev_register(struct net_device *dev)
 {
-- 
2.5.5



Re: [PATCH v5 net-next 0/5] dsa: add Microchip KSZ9477 DSA driver

2017-05-31 Thread David Miller
From: 
Date: Wed, 31 May 2017 20:19:00 +

> From: Woojung Huh 
> 
> This series of patches is for Microchip KSZ9477 DSA driver.
> KSZ9477 is 7 ports GigE switch with numerous advanced features.
> 5 ports are 10/100/1000 Mbps internal PHYs and 2 ports have
> Interfaces to SGMII, RGMII, MII or RMII.
> 
> This patch supports VLAN, MDB, FDB and port mirroring offloads.
> 
> Welcome reviews and comments from community.
> 
> Note: Tests are performed on internal development board.
> 
> V5
> - add missing MODULE_LICENSE

Series applied, thanks.


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-05-31 Thread Jia-Ju Bai

On 06/01/2017 01:33 AM, Larry Finger wrote:

On 05/31/2017 05:29 AM, Jia-Ju Bai wrote:

The driver may sleep under a spin lock, and the function call path is:
b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave)
   b43legacy_radio_set_interference_mitigation
 b43legacy_radio_interference_mitigation_disable
   b43legacy_calc_nrssi_slope
 b43legacy_synth_pu_workaround
   might_sleep and msleep --> may sleep

Fixing it may be complex, and a possible way is to remove
spin_lock_irqsave and spin_lock_irqrestore in
b43legacy_attr_interfmode_store, and the code has been protected by
mutex_lock and mutex_unlock.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/broadcom/b43legacy/sysfs.c |2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43legacy/sysfs.c 
b/drivers/net/wireless/broadcom/b43legacy/sysfs.c

index 2a1da15..9ede143 100644
--- a/drivers/net/wireless/broadcom/b43legacy/sysfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
@@ -137,14 +137,12 @@ static ssize_t 
b43legacy_attr_interfmode_store(struct device *dev,

  }
mutex_lock(&wldev->wl->mutex);
-spin_lock_irqsave(&wldev->wl->irq_lock, flags);
err = b43legacy_radio_set_interference_mitigation(wldev, mode);
  if (err)
  b43legacyerr(wldev->wl, "Interference Mitigation not "
 "supported by device\n");
  mmiowb();
-spin_unlock_irqrestore(&wldev->wl->irq_lock, flags);
  mutex_unlock(&wldev->wl->mutex);
return err ? err : count;



Jia-Ju,

Did you actually observe the attempt to sleep under the spin lock, or 
did you discover this using some tool? In other words, have either of 
your patches been tested?


Larry


Hi,

In fact, my reported bugs are found by a static analysis tool written by 
me, and they are checked by my review of the driver code.

I admit my patches are not well tested, and they may not well fix the bugs.
I am looking forward to opinions and suggestions :)

Thanks,
Jia-Ju Bai



Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Jia-Ju Bai

On 06/01/2017 08:07 AM, Larry Finger wrote:

On 05/31/2017 10:32 AM, Michael Büsch wrote:

On Wed, 31 May 2017 13:26:43 +0300
Kalle Valo  wrote:


Jia-Ju Bai  writes:


The driver may sleep under a spin lock, and the function call path is:
b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
   b43legacy_synchronize_irq
 synchronize_irq --> may sleep

To fix it, the lock is released before b43legacy_synchronize_irq, 
and the

lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
b/drivers/net/wireless/broadcom/b43legacy/main.c

index f1e3dad..31ead21 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -2859,7 +2859,9 @@ static void 
b43legacy_op_bss_info_changed(struct ieee80211_hw *hw,

  b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
if (changed & BSS_CHANGED_BSSID) {
+spin_unlock_irqrestore(&wl->irq_lock, flags);
  b43legacy_synchronize_irq(dev);
+spin_lock_irqsave(&wl->irq_lock, flags);


To me this looks like a fragile workaround and not a real fix. You can
easily add new race conditions with releasing the lock like this.




I think releasing the lock possibly is fine. It certainly is better than
sleeping with a lock held.
We disabled the device interrupts just before this line.

However I think the synchronize_irq should be outside of the
conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
two lines above)
I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
is set.


On the other hand b43 does not have this irq-disabling foobar anymore.
So somebody must have removed it. Maybe you can find the commit that
removed this stuff from b43 and port it to b43legacy?


So I would vote for moving the synchronize_irq up outside of the
conditional and put the unlock/lock sequence around it.
And as a second patch on top of that try to remove this stuff
altogether like b43 did.


The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch 
Date:   Fri Sep 4 22:51:29 2009 +0200

b43: Use a threaded IRQ handler

Use a threaded IRQ handler to allow locking the mutex and
sleeping while executing an interrupt.
This removes usage of the irq_lock spinlock, but introduces
a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

Signed-off-by: Michael Buesch 
Tested-by: Larry Finger 
Signed-off-by: John W. Linville 

I vaguely remember this patch. Although it is roughly a 1000-line fix, 
I will try to port it to b43legacy. I still have an old BCM4306 PCMCIA 
card that I can test in a PowerBook G4.


I agree with Michael that this is the way to go. Both of Jia-Ju's 
patches should be rejected.


Larry




It is fine to me to fix the bug by porting this former patch.

Thanks,
Jia-Ju Bai



[PATCH net-next v2] bpf: Remove the capability check for cgroup skb eBPF program

2017-05-31 Thread Chenbo Feng
From: Chenbo Feng 

Currently loading a cgroup skb eBPF program require a CAP_SYS_ADMIN
capability while attaching the program to a cgroup only requires the
user have CAP_NET_ADMIN privilege. We can escape the capability
check when load the program just like socket filter program to make
the capability requirement consistent.

Change since v1:
Change the code style in order to be compliant with checkpatch.pl
preference

Signed-off-by: Chenbo Feng 
---
 kernel/bpf/syscall.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 265a0d8..59da103 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -815,7 +815,9 @@ static int bpf_prog_load(union bpf_attr *attr)
attr->kern_version != LINUX_VERSION_CODE)
return -EINVAL;
 
-   if (type != BPF_PROG_TYPE_SOCKET_FILTER && !capable(CAP_SYS_ADMIN))
+   if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
+   type != BPF_PROG_TYPE_CGROUP_SKB &&
+   !capable(CAP_SYS_ADMIN))
return -EPERM;
 
/* plain bpf_prog allocation */
-- 
2.7.4



[PATCH net-next v2 1/2] bpf: Allow CGROUP_SKB eBPF program to access sk_buff

2017-05-31 Thread Chenbo Feng
From: Chenbo Feng 

This allows cgroup eBPF program to classify packet based on their
protocol or other detail information. Currently program need
CAP_NET_ADMIN privilege to attach a cgroup eBPF program, and A
process with CAP_NET_ADMIN can already see all packets on the system,
for example, by creating an iptables rules that causes the packet to
be passed to userspace via NFLOG.

Signed-off-by: Chenbo Feng 
---
 kernel/bpf/verifier.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 339c8a1..94a9bc9 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2419,6 +2419,7 @@ static bool may_access_skb(enum bpf_prog_type type)
case BPF_PROG_TYPE_SOCKET_FILTER:
case BPF_PROG_TYPE_SCHED_CLS:
case BPF_PROG_TYPE_SCHED_ACT:
+   case BPF_PROG_TYPE_CGROUP_SKB:
return true;
default:
return false;
-- 
2.7.4



[PATCH net-next v2 2/2] bpf: Remove the capability check for cgroup skb eBPF program

2017-05-31 Thread Chenbo Feng
From: Chenbo Feng 

Currently loading a cgroup skb eBPF program require a CAP_SYS_ADMIN
capability while attaching the program to a cgroup only requires the
user have CAP_NET_ADMIN privilege. We can escape the capability
check when load the program just like socket filter program to make
the capability requirement consistent.

Change since v1:
Change the code style in order to be compliant with checkpatch.pl
preference

Signed-off-by: Chenbo Feng 
---
 kernel/bpf/syscall.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 265a0d8..59da103 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -815,7 +815,9 @@ static int bpf_prog_load(union bpf_attr *attr)
attr->kern_version != LINUX_VERSION_CODE)
return -EINVAL;
 
-   if (type != BPF_PROG_TYPE_SOCKET_FILTER && !capable(CAP_SYS_ADMIN))
+   if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
+   type != BPF_PROG_TYPE_CGROUP_SKB &&
+   !capable(CAP_SYS_ADMIN))
return -EPERM;
 
/* plain bpf_prog allocation */
-- 
2.7.4



Re: net/ipv6: use-after-free in ip6_dst_ifdown

2017-05-31 Thread David Ahern
On 5/31/17 4:49 PM, Cong Wang wrote:
 ==
 BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 
 net/ipv6/route.c:422
 Read of size 8 at addr 88006afa4ad8 by task syz-executor6/23554
>>>
>>>
>>> This one is very interesting.
>>>
>>> Here we are at:
>>>
>>> if (dev != loopback_dev) {
>>> if (idev && idev->dev == dev) {
>>> struct inet6_dev *loopback_idev =
>>> in6_dev_get(loopback_dev);
>>> if (loopback_idev) {
>>> rt->rt6i_idev = loopback_idev;
>>> in6_dev_put(idev);
>>> }
>>> }
>>> }
>>>
>>> clearly no skb involved, it looks like idev is the one used-after-free.
>>>
>>> But below it is actually skb which is allocated and freed...
>>>
>>
>> skb->head was a kmalloc(X)   with X = 1024 in this case.
>>
>> So it is very possible the two different objects (skb->head and idev )
>>  were accidentally using the same slab (1024 bytes).
>>
>> KASAN only remember the last pair of alloc/free for a particular memory zone.
> 
> I see. So that memory area was freed for idev and then allocated
> and freed again for skb->head, this happened so quick that the
> use-after-free happened after it... Therefore we lost the track on where
> we free the idev.
> 

Andrey: can you add this to your runs? If it triggers again, we can see
if this use-after-free is another problem where the dst hit the gc list
and came back into the IPv6 FIB. The location of the idev entry in
rt6_info is after the size of rtable so if this is an IPv4 dst on the
IPv6 list it could trigger that warning.

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 9d9b5bbea153..237f42144b3e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -418,6 +418,7 @@ static void ip6_dst_ifdown(struct dst_entry *dst,
struct net_device *dev,
struct net_device *loopback_dev =
dev_net(dev)->loopback_dev;

+WARN_ON(dst->ops->family != AF_INET6);
if (dev != loopback_dev) {
if (idev && idev->dev == dev) {
struct inet6_dev *loopback_idev =


Re: [PATCH V3] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Sowmini Varadhan
On (06/01/17 01:41), Julian Anastasov wrote:
>   Another problem is that neigh_update() changes the
> state but before we go and unlink the entry another CPU
> can reactivate the entry, i.e. NUD_INCOMPLETE entered
> in __neigh_event_send(). So, there will be always some
> small window where surprises can happen and the entry is
> not really deleted.

but that would be ok- it's the same as if I did
   arp -d 
   ping 

I think the only danger is that, once we drop the ref with
neigh_release(), we are relying on the table's lock for the neigh
to not disappear under us. Thus as you correctly pointed out,
we need the tbl->lock to make sure we sync with all paths that
can pull the neigh out of the table (and release the table's ref
along the way).

Thanks for catching that, patch v4 (with correct smtp timestamp!)
will be sent out shortly.

--Sowmini



[PATCH V4] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

2017-05-31 Thread Sowmini Varadhan
The command
  # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
adds an entry like the following (listed by "arp -an")
  ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
but the symmetric deletion command
  # arp -i eth2 -d 62.2.0.1
does not remove the PERM entry from the table, and instead leaves behind
  ? (62.2.0.1) at  on eth2

The reason is that there is a refcnt of 1 for the arp_tbl itself
(neigh_alloc starts off the entry with a refcnt of 1), thus
the neigh_release() call from arp_invalidate() will (at best) just
decrement the ref to 1, but will never actually free it from the
table.

To fix this, we need to do something like neigh_forced_gc: if
the refcnt is 1 (i.e., on the table's ref), remove the entry from
the table and free it. This patch refactors and shares common code
between neigh_forced_gc and the newly added neigh_remove_one.

A similar issue exists for IPv6 Neighbor Cache entries, and is fixed
in a similar manner by this patch.

Signed-off-by: Sowmini Varadhan 
---
v2: kbuild-test-robot compile error
v3: do not export_symbol neigh_remove_one (David Miller comment)
v4: rearrange locking for tbl->lock (Julian Anastasov comment)

 include/net/neighbour.h |1 +
 net/core/neighbour.c|   61 ++
 net/ipv4/arp.c  |4 +++
 3 files changed, 55 insertions(+), 11 deletions(-)

diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index e4dd3a2..639b675 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -317,6 +317,7 @@ struct neighbour *__neigh_create(struct neigh_table *tbl, 
const void *pkey,
 int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, u32 flags,
 u32 nlmsg_pid);
 void __neigh_set_probe_once(struct neighbour *neigh);
+bool neigh_remove_one(struct neighbour *ndel, struct neigh_table *tbl);
 void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev);
 int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
 int neigh_resolve_output(struct neighbour *neigh, struct sk_buff *skb);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index d274f81..b473f9f 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -118,6 +118,51 @@ unsigned long neigh_rand_reach_time(unsigned long base)
 EXPORT_SYMBOL(neigh_rand_reach_time);
 
 
+static bool neigh_del(struct neighbour *n, __u8 state,
+ struct neighbour __rcu **np, struct neigh_table *tbl)
+{
+   bool retval = false;
+
+   write_lock(&n->lock);
+   if (atomic_read(&n->refcnt) == 1 && !(n->nud_state & state)) {
+   rcu_assign_pointer(*np,
+  rcu_dereference_protected(n->next,
+  lockdep_is_held(&tbl->lock)));
+   n->dead = 1;
+   retval = true;
+   }
+   write_unlock(&n->lock);
+   if (retval)
+   neigh_cleanup_and_release(n);
+   return retval;
+}
+
+bool neigh_remove_one(struct neighbour *ndel, struct neigh_table *tbl)
+{
+   struct neigh_hash_table *nht;
+   void *pkey = ndel->primary_key;
+   u32 hash_val;
+   struct neighbour *n;
+   struct neighbour __rcu **np;
+   bool retval = false;
+
+   nht = rcu_dereference_protected(tbl->nht,
+   lockdep_is_held(&tbl->lock));
+   hash_val = tbl->hash(pkey, ndel->dev, nht->hash_rnd);
+   hash_val = hash_val >> (32 - nht->hash_shift);
+
+   np = &nht->hash_buckets[hash_val];
+   while ((n = rcu_dereference_protected(*np,
+   lockdep_is_held(&tbl->lock))) != NULL) {
+   if (n == ndel) {
+   retval = neigh_del(n, 0, np, tbl);
+   return retval;
+   }
+   np = &n->next;
+   }
+   return retval;
+}
+
 static int neigh_forced_gc(struct neigh_table *tbl)
 {
int shrunk = 0;
@@ -140,19 +185,10 @@ static int neigh_forced_gc(struct neigh_table *tbl)
 * - nobody refers to it.
 * - it is not permanent
 */
-   write_lock(&n->lock);
-   if (atomic_read(&n->refcnt) == 1 &&
-   !(n->nud_state & NUD_PERMANENT)) {
-   rcu_assign_pointer(*np,
-   rcu_dereference_protected(n->next,
- lockdep_is_held(&tbl->lock)));
-   n->dead = 1;
-   shrunk  = 1;
-   write_unlock(&n->lock);
-   neigh_cleanup_and_release(n);
+   if (neigh_del(n, NUD_PERMANENT, np, tbl)) {
+   shrunk = 1;
continue;
}
-   write_unlock(&n->lock);
np = &n->next;

linux-next: manual merge of the net-next tree with the net tree

2017-05-31 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/phy/marvell.c

between commit:

  898805e0cdf7 ("net: phy: fix marvell phy status reading")

from the net tree and commit:

  e1dde8dc5b27 ("net: phy: marvell: Refactor some bigger functions")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/phy/marvell.c
index 57297ba23987,1a72bebc588a..
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@@ -1082,119 -1133,106 +1133,104 @@@ static int marvell_update_link(struct p
return 0;
  }
  
- /* marvell_read_status_page
-  *
-  * Description:
-  *   Check the link, then figure out the current state
-  *   by comparing what we advertise with what the link partner
-  *   advertises.  Start by checking the gigabit possibilities,
-  *   then move on to 10/100.
-  */
- static int marvell_read_status_page(struct phy_device *phydev, int page)
+ static int marvell_read_status_page_an(struct phy_device *phydev,
+  int fiber)
  {
-   int adv;
-   int err;
+   int status;
int lpa;
int lpagb;
-   int status = 0;
-   int fiber;
+   int adv;
  
-   /* Detect and update the link, but return if there
-* was an error */
-   if (page == MII_M_FIBER)
-   fiber = 1;
-   else
-   fiber = 0;
+   status = phy_read(phydev, MII_M1011_PHY_STATUS);
+   if (status < 0)
+   return status;
  
-   err = marvell_update_link(phydev, fiber);
-   if (err)
-   return err;
+   lpa = phy_read(phydev, MII_LPA);
+   if (lpa < 0)
+   return lpa;
  
-   if (AUTONEG_ENABLE == phydev->autoneg) {
-   status = phy_read(phydev, MII_M1011_PHY_STATUS);
-   if (status < 0)
-   return status;
+   lpagb = phy_read(phydev, MII_STAT1000);
+   if (lpagb < 0)
+   return lpagb;
  
-   lpa = phy_read(phydev, MII_LPA);
-   if (lpa < 0)
-   return lpa;
+   adv = phy_read(phydev, MII_ADVERTISE);
+   if (adv < 0)
+   return adv;
  
-   lpagb = phy_read(phydev, MII_STAT1000);
-   if (lpagb < 0)
-   return lpagb;
 -  lpa &= adv;
 -
+   if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+   phydev->duplex = DUPLEX_FULL;
+   else
+   phydev->duplex = DUPLEX_HALF;
  
-   adv = phy_read(phydev, MII_ADVERTISE);
-   if (adv < 0)
-   return adv;
+   status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+   phydev->pause = 0;
+   phydev->asym_pause = 0;
  
-   if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
-   phydev->duplex = DUPLEX_FULL;
-   else
-   phydev->duplex = DUPLEX_HALF;
+   switch (status) {
+   case MII_M1011_PHY_STATUS_1000:
+   phydev->speed = SPEED_1000;
+   break;
  
-   status = status & MII_M1011_PHY_STATUS_SPD_MASK;
-   phydev->pause = phydev->asym_pause = 0;
+   case MII_M1011_PHY_STATUS_100:
+   phydev->speed = SPEED_100;
+   break;
  
-   switch (status) {
-   case MII_M1011_PHY_STATUS_1000:
-   phydev->speed = SPEED_1000;
-   break;
+   default:
+   phydev->speed = SPEED_10;
+   break;
+   }
  
-   case MII_M1011_PHY_STATUS_100:
-   phydev->speed = SPEED_100;
-   break;
+   if (!fiber) {
+   phydev->lp_advertising =
+   mii_stat1000_to_ethtool_lpa_t(lpagb) |
+   mii_lpa_to_ethtool_lpa_t(lpa);
  
-   default:
-   phydev->speed = SPEED_10;
-   break;
+   if (phydev->duplex == DUPLEX_FULL) {
+   phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+   phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
}
- 
-   if (!fiber) {
-   phydev->lp_advertising = 
mii_stat1000_to_ethtool_lpa_t(lpagb) |
-mii_lpa_to_ethtool_lpa_t(lpa);
- 
-   if (phydev->duplex == DUPLEX_FULL) {
-   phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
-   phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 
0;
- 

RE: [PATCH v2] net: fec: add post PHY reset delay DT property

2017-05-31 Thread Andy Duan
From: Rob Herring  Sent: Thursday, June 01, 2017 12:44 AM
>On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
>> Some PHY require to wait for a bit after the reset GPIO has been
>> toggled. This adds support for the DT property `phy-reset-post-delay`
>> which gives the delay in milliseconds to wait after reset.
>>
>> If the DT property is not given, no delay is observed. Post reset
>> delay greater than 1000ms are invalid.
>>
>> Signed-off-by: Quentin Schulz 
>> ---
>>
>> v2:
>>   - return -EINVAL when phy-reset-post-delay is greater than 1000ms
>>   instead of defaulting to 1ms,
>>   - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
>>   binding doc and commit log,
>>   - move phy-reset-post-delay property reading before
>>   devm_gpio_request_one(),
>>
>>  Documentation/devicetree/bindings/net/fsl-fec.txt |  4 
>>  drivers/net/ethernet/freescale/fec_main.c | 16 +++-
>>  2 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
>> b/Documentation/devicetree/bindings/net/fsl-fec.txt
>> index a1e3693cca16..6f55bdd52f8a 100644
>> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
>> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
>> @@ -15,6 +15,10 @@ Optional properties:
>>  - phy-reset-active-high : If present then the reset sequence using the GPIO
>>specified in the "phy-reset-gpios" property is reversed (H=reset state,
>>L=operation state).
>> +- phy-reset-post-delay : Post reset delay in milliseconds. If present
>> +then
>
>This needs unit suffix minimally. It should also have a vendor prefix or be
>made generic.
>
>But really, this is a property of the phy and should be in the phy node as
>should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
>
Yes, it is better to make it general.
Last year, Uwe Kleine-König's patch "Commit da47b4572056 ("phy: add support for 
a reset-gpio specification")" did this, but it was reverted by commit 
948350140ef0 (Revert "phy: add support for a reset-gpio specification").  And 
in all phy device driver, only at803x.c add the gpio reset in currently. 


Re: [PATCH v2] net: fec: add post PHY reset delay DT property

2017-05-31 Thread Florian Fainelli
Le 05/31/17 à 18:39, Andy Duan a écrit :
> From: Rob Herring  Sent: Thursday, June 01, 2017 12:44 AM
>> On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
>>> Some PHY require to wait for a bit after the reset GPIO has been
>>> toggled. This adds support for the DT property `phy-reset-post-delay`
>>> which gives the delay in milliseconds to wait after reset.
>>>
>>> If the DT property is not given, no delay is observed. Post reset
>>> delay greater than 1000ms are invalid.
>>>
>>> Signed-off-by: Quentin Schulz 
>>> ---
>>>
>>> v2:
>>>   - return -EINVAL when phy-reset-post-delay is greater than 1000ms
>>>   instead of defaulting to 1ms,
>>>   - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
>>>   binding doc and commit log,
>>>   - move phy-reset-post-delay property reading before
>>>   devm_gpio_request_one(),
>>>
>>>  Documentation/devicetree/bindings/net/fsl-fec.txt |  4 
>>>  drivers/net/ethernet/freescale/fec_main.c | 16 +++-
>>>  2 files changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
>>> b/Documentation/devicetree/bindings/net/fsl-fec.txt
>>> index a1e3693cca16..6f55bdd52f8a 100644
>>> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
>>> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
>>> @@ -15,6 +15,10 @@ Optional properties:
>>>  - phy-reset-active-high : If present then the reset sequence using the GPIO
>>>specified in the "phy-reset-gpios" property is reversed (H=reset state,
>>>L=operation state).
>>> +- phy-reset-post-delay : Post reset delay in milliseconds. If present
>>> +then
>>
>> This needs unit suffix minimally. It should also have a vendor prefix or be
>> made generic.
>>
>> But really, this is a property of the phy and should be in the phy node as
>> should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
>>
> Yes, it is better to make it general.
> Last year, Uwe Kleine-König's patch "Commit da47b4572056 ("phy: add support 
> for a reset-gpio specification")" did this, but it was reverted by commit 
> 948350140ef0 (Revert "phy: add support for a reset-gpio specification").  And 
> in all phy device driver, only at803x.c add the gpio reset in currently. 

Getting the binding correct does not prevent us from later moving this
reset code into PHYLIB where it's appropriate. In fact; a correct and
generic binding proposed for FEC here could be used as a basis for all
other MAC and PHY drivers.
-- 
Florian


Re: [PATCH v2 net-next 0/8] Introduce bpf ID

2017-05-31 Thread Jakub Kicinski
On Wed, 31 May 2017 11:58:54 -0700, Martin KaFai Lau wrote:
> This patch series:
> 1) Introduce ID for both bpf_prog and bpf_map.
> 2) Add bpf commands to iterate the prog IDs and map
>IDs of the system.
> 3) Add bpf commands to get a prog/map fd from an ID
> 4) Add bpf command to get prog/map info from a fd.
>The prog/map info is a jump start in this patchset
>and it is not meant to be a complete list.  They can
>be extended in the future patches.

Hi!  IIUC there were plans at some point to store the BPF byte code in
the kernel, the way it was loaded from the user space and before it
went through the verifier.  Are you still planning on implementing that?
It would be handy for offloads to have the original byte code, things
like call inlining make translations of maps calls a bit challenging,
since we try to run through the verifier again..


[PATCH] cw1200: Fix a sleep-in-atomic bug in cw1200_tx_confirm_cb and cw1200_cqm_bssloss_sm

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
cw1200_tx_confirm_cb (acquire the lock by spin_lock)
  __cw1200_cqm_bssloss_sm
cancel_work_sync --> may sleep

cw1200_cqm_bssloss_sm
  __cw1200_cqm_bssloss_sm
cancel_work_sync --> may sleep

To fix it, the lock is released before cancel_work_sync, and the lock 
is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/st/cw1200/sta.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/st/cw1200/sta.c 
b/drivers/net/wireless/st/cw1200/sta.c
index a522248..d5f7698 100644
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -154,7 +154,9 @@ void __cw1200_cqm_bssloss_sm(struct cw1200_common *priv,
int tx = 0;
 
priv->delayed_link_loss = 0;
+   spin_unlock(&priv->bss_loss_lock);
cancel_work_sync(&priv->bss_params_work);
+   spin_lock(&priv->bss_loss_lock);
 
pr_debug("[STA] CQM BSSLOSS_SM: state: %d init %d good %d bad: %d 
txlock: %d uj: %d\n",
 priv->bss_loss_state,
-- 
1.7.9.5




[PATCH net-next] bpf: Take advantage of stack_depth tracking in sparc64 JIT

2017-05-31 Thread David Miller

Signed-off-by: David S. Miller 
---

Committed to net-next.

 arch/sparc/net/bpf_jit_comp_64.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/net/bpf_jit_comp_64.c b/arch/sparc/net/bpf_jit_comp_64.c
index 4a52d34..098874a 100644
--- a/arch/sparc/net/bpf_jit_comp_64.c
+++ b/arch/sparc/net/bpf_jit_comp_64.c
@@ -802,8 +802,13 @@ static void build_prologue(struct jit_ctx *ctx)
 {
s32 stack_needed = BASE_STACKFRAME;
 
-   if (ctx->saw_frame_pointer || ctx->saw_tail_call)
-   stack_needed += MAX_BPF_STACK;
+   if (ctx->saw_frame_pointer || ctx->saw_tail_call) {
+   struct bpf_prog *prog = ctx->prog;
+   u32 stack_depth;
+
+   stack_depth = prog->aux->stack_depth;
+   stack_needed += round_up(stack_depth, 16);
+   }
 
if (ctx->saw_tail_call)
stack_needed += 8;
-- 
2.1.2.532.g19b5d50



Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-05-31 Thread Kalle Valo
Jia-Ju Bai  writes:

>> Did you actually observe the attempt to sleep under the spin lock,
>> or did you discover this using some tool? In other words, have
>> either of your patches been tested?
>
> In fact, my reported bugs are found by a static analysis tool written
> by me, and they are checked by my review of the driver code.

It's valuable information to add to the commit log how you found the
bug. If you check other wireless commits you can see comments like
"Found by spatch", "Coverity reported" quite frequently. So I recommend
that you also mention your tool in the commit log, makes understanding
the background of the patch easier.

-- 
Kalle Valo


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Kalle Valo
Michael Büsch  writes:

>> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
>> > ieee80211_hw *hw,
>> >b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>> >  
>> >if (changed & BSS_CHANGED_BSSID) {
>> > +  spin_unlock_irqrestore(&wl->irq_lock, flags);
>> >b43legacy_synchronize_irq(dev);
>> > +  spin_lock_irqsave(&wl->irq_lock, flags);  
>> 
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>> 
>
>
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.

Sure, but IMHO in general I think the practise of releasing the lock
like this in a middle of function is dangerous as one can easily miss
that upper and lower halves of the function are not actually atomic
anymore. And in this case that it's under a conditional makes it even
worse.

-- 
Kalle Valo


Re: [PATCH net-next v2 4/8] net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup

2017-05-31 Thread Roopa Prabhu
On Wed, May 31, 2017 at 2:48 PM, David Ahern  wrote:
> On 5/31/17 2:11 PM, John Fastabend wrote:
>>> @@ -2721,14 +2724,14 @@ static int inet_rtm_getroute(struct sk_buff 
>>> *in_skb, struct nlmsghdr *nlh,
>>>  skb->protocol   = htons(ETH_P_IP);
>>>  skb->dev= dev;
>>>  skb->mark   = mark;
>>> -err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev);
>>> +err = ip_route_input_rcu(skb, dst, src, rtm->rtm_tos,
>>> + dev, &res);
>>>
>>>  rt = skb_rtable(skb);
>>>  if (err == 0 && rt->dst.error)
>>>  err = -rt->dst.error;
>>>  } else {
>>> -rt = ip_route_output_key(net, &fl4);
>>> -
>>> +rt = ip_route_output_key_hash_rcu(net, &fl4, &res, skb);
>>>  err = 0;
>>>  if (IS_ERR(rt))
>>>  err = PTR_ERR(rt);
>>> @@ -2737,7 +2740,6 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
>>> struct nlmsghdr *nlh,
>>>  if (err)
>>>  goto errout_free;
>>>
>>> -skb_dst_set(skb, &rt->dst);
>>
>>
>> Why did you remove this? Neither ip_route_input() or ip_route_output_key()
>> seem to justify this with a quick scan on my side. Feel free to correct me
>> here.
>>
>
> original patch was done in January. I forget why I took it out. It is
> clearly needed to release the dst.

yes, looking at it now the attach is needed to release the dst.  The original
commit msg said "The rcu lock is held through the creation of the
response, so the
 rtable/dst does not need to be attached to the skb and is passed to
rt_fill_info directly."

> Might as well undo the argument
> change to rt_fill_info since it is attached to the skb. Something like
> this (whitespace damaged on paste - stupid Mac):

agree, I can submit the patch

>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index f1f2e5aaa2d6..93cca12a8319 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2547,8 +2547,9 @@ EXPORT_SYMBOL_GPL(ip_route_output_flow);
>  /* called with rcu_read_lock held */
>  static int rt_fill_info(struct net *net,  __be32 dst, __be32 src, u32
> table_id,
> struct flowi4 *fl4, struct sk_buff *skb, u32 portid,
> -   u32 seq, struct rtable *rt)
> +   u32 seq)
>  {
> +   struct rtable *rt = skb_rtable(skb);
> struct rtmsg *r;
> struct nlmsghdr *nlh;
> unsigned long expires = 0;
> @@ -2750,6 +2751,8 @@ static int inet_rtm_getroute(struct sk_buff
> *in_skb, struct nlmsghdr *nlh,
> if (err)
> goto errout_free;
>
> +   skb_dst_set(skb, &rt->dst);
> +
> if (rtm->rtm_flags & RTM_F_NOTIFY)
> rt->rt_flags |= RTCF_NOTIFY;
>
> @@ -2763,8 +2766,7 @@ static int inet_rtm_getroute(struct sk_buff
> *in_skb, struct nlmsghdr *nlh,
> fl4.flowi4_tos, res.fi, 0);
> else
> err = rt_fill_info(net, dst, src, table_id, &fl4, skb,
> -  NETLINK_CB(in_skb).portid,
> nlh->nlmsg_seq,
> -  rt);
> +  NETLINK_CB(in_skb).portid,
> nlh->nlmsg_seq);
> if (err < 0)
> goto errout_free;
>
>
> Seems to work for me.


Re: [PATCH] xfrm: fix xfrm_dev_event() missing when compile without CONFIG_XFRM_OFFLOAD

2017-05-31 Thread kbuild test robot
Hi Hangbin,

[auto build test ERROR on ipsec/master]
[also build test ERROR on v4.12-rc3 next-20170531]
[cannot apply to ipsec-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hangbin-Liu/xfrm-fix-xfrm_dev_event-missing-when-compile-without-CONFIG_XFRM_OFFLOAD/20170601-112559
base:   https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git 
master
config: x86_64-randconfig-x014-201722 (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=x86_64 

All errors (new ones prefixed by >>):

>> net//xfrm/xfrm_device.c:207:17: error: redefinition of 'xfrm_dev_init'
void __net_init xfrm_dev_init(void)
^
   In file included from net//xfrm/xfrm_device.c:22:0:
   include/net/xfrm.h:1880:31: note: previous definition of 'xfrm_dev_init' was 
here
static inline void __net_init xfrm_dev_init(void)
  ^

vim +/xfrm_dev_init +207 net//xfrm/xfrm_device.c

d77e38e6 Steffen Klassert 2017-04-14  191   case NETDEV_UNREGISTER:
d77e38e6 Steffen Klassert 2017-04-14  192   return 
xfrm_dev_unregister(dev);
d77e38e6 Steffen Klassert 2017-04-14  193  
d77e38e6 Steffen Klassert 2017-04-14  194   case NETDEV_FEAT_CHANGE:
d77e38e6 Steffen Klassert 2017-04-14  195   return 
xfrm_dev_feat_change(dev);
d77e38e6 Steffen Klassert 2017-04-14  196  
21f42cc9 Steffen Klassert 2017-04-14  197   case NETDEV_DOWN:
d77e38e6 Steffen Klassert 2017-04-14  198   return 
xfrm_dev_down(dev);
21f42cc9 Steffen Klassert 2017-04-14  199   }
21f42cc9 Steffen Klassert 2017-04-14  200   return NOTIFY_DONE;
21f42cc9 Steffen Klassert 2017-04-14  201  }
21f42cc9 Steffen Klassert 2017-04-14  202  
21f42cc9 Steffen Klassert 2017-04-14  203  static struct notifier_block 
xfrm_dev_notifier = {
21f42cc9 Steffen Klassert 2017-04-14  204   .notifier_call  = 
xfrm_dev_event,
21f42cc9 Steffen Klassert 2017-04-14  205  };
21f42cc9 Steffen Klassert 2017-04-14  206  
21f42cc9 Steffen Klassert 2017-04-14 @207  void __net_init xfrm_dev_init(void)
21f42cc9 Steffen Klassert 2017-04-14  208  {
21f42cc9 Steffen Klassert 2017-04-14  209   
register_netdevice_notifier(&xfrm_dev_notifier);
21f42cc9 Steffen Klassert 2017-04-14  210  }

:: The code at line 207 was first introduced by commit
:: 21f42cc95f07c1d7827b339c04442e147411e44b xfrm: Move device notifications 
to a sepatate file

:: TO: Steffen Klassert 
:: CC: Steffen Klassert 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Thu, 01 Jun 2017 07:27:20 +0300
Kalle Valo  wrote:

> Michael Büsch  writes:
> 
> >> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >> > ieee80211_hw *hw,
> >> >  b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >> >  
> >> >  if (changed & BSS_CHANGED_BSSID) {
> >> > +spin_unlock_irqrestore(&wl->irq_lock, flags);
> >> >  b43legacy_synchronize_irq(dev);
> >> > +spin_lock_irqsave(&wl->irq_lock, flags);
> >> 
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>   
> >
> >
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.  
> 
> Sure, but IMHO in general I think the practise of releasing the lock
> like this in a middle of function is dangerous as one can easily miss
> that upper and lower halves of the function are not actually atomic
> anymore. And in this case that it's under a conditional makes it even
> worse.
> 


Yes in general I agree. Releasing and re-acquiring a lock is dangerous.
But I think in this special case here it might be harmless.
The irq_lock is used mostly (if not exclusively; I don't fully
remember) to protect against the IRQ top and bottom half.
But we disabled the device IRQs a line above and the purpose of this
synchronize is to make sure the handler will finish and thus make
dropping the lock save.
Of course it does not make sense to do this with the lock held :)

-- 
Michael


pgpCKuuPTGIgU.pgp
Description: OpenPGP digital signature


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Wed, 31 May 2017 19:07:15 -0500
Larry Finger  wrote:

> On 05/31/2017 10:32 AM, Michael Büsch wrote:
> > On Wed, 31 May 2017 13:26:43 +0300
> > Kalle Valo  wrote:
> >   
> >> Jia-Ju Bai  writes:
> >>  
> >>> The driver may sleep under a spin lock, and the function call path is:
> >>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
> >>>b43legacy_synchronize_irq
> >>>  synchronize_irq --> may sleep
> >>>
> >>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
> >>> lock is acquired again after this function.
> >>>
> >>> Signed-off-by: Jia-Ju Bai 
> >>> ---
> >>>   drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
> >>> b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> index f1e3dad..31ead21 100644
> >>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >>> ieee80211_hw *hw,
> >>>   b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >>>   
> >>>   if (changed & BSS_CHANGED_BSSID) {
> >>> + spin_unlock_irqrestore(&wl->irq_lock, flags);
> >>>   b43legacy_synchronize_irq(dev);
> >>> + spin_lock_irqsave(&wl->irq_lock, flags);  
> >>
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>  
> > 
> > 
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.
> > We disabled the device interrupts just before this line.
> > 
> > However I think the synchronize_irq should be outside of the
> > conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> > two lines above)
> > I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> > is set.
> > 
> > 
> > On the other hand b43 does not have this irq-disabling foobar anymore.
> > So somebody must have removed it. Maybe you can find the commit that
> > removed this stuff from b43 and port it to b43legacy?
> > 
> > 
> > So I would vote for moving the synchronize_irq up outside of the
> > conditional and put the unlock/lock sequence around it.
> > And as a second patch on top of that try to remove this stuff
> > altogether like b43 did.  
> 
> The patch that removed it in b43 is
> 
> commit 36dbd9548e92268127b0c31b0e121e63e9207108
> Author: Michael Buesch 
> Date:   Fri Sep 4 22:51:29 2009 +0200

Damn it :D

>  b43: Use a threaded IRQ handler
> 
>  Use a threaded IRQ handler to allow locking the mutex and
>  sleeping while executing an interrupt.
>  This removes usage of the irq_lock spinlock, but introduces
>  a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
>  hard-irq handler. Sleeping busses (SDIO) will use mutex instead.
> 
>  Signed-off-by: Michael Buesch 
>  Tested-by: Larry Finger 
>  Signed-off-by: John W. Linville 
> 
> I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
> try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I 
> can 
> test in a PowerBook G4.
> 
> I agree with Michael that this is the way to go. Both of Jia-Ju's patches 
> should 
> be rejected.


I'm not sure if it's worth it. There is a risk that this would
introduce new bugs.
But sure, please feel free to try it. This way we can find out how big
this change becomes.

-- 
Michael


pgpB8k7rQgxAO.pgp
Description: OpenPGP digital signature


RE: [PATCH v2] net: fec: add post PHY reset delay DT property

2017-05-31 Thread Andy Duan
From: Florian Fainelli  Sent: Thursday, June 01, 2017 
9:53 AM
>To: Andy Duan ; Rob Herring ;
>Quentin Schulz 
>Cc: mark.rutl...@arm.com; netdev@vger.kernel.org;
>devicet...@vger.kernel.org; linux-ker...@vger.kernel.org;
>thomas.petazz...@free-electrons.com
>Subject: Re: [PATCH v2] net: fec: add post PHY reset delay DT property
>
>Le 05/31/17 à 18:39, Andy Duan a écrit :
>> From: Rob Herring  Sent: Thursday, June 01, 2017
>> 12:44 AM
>>> On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
 Some PHY require to wait for a bit after the reset GPIO has been
 toggled. This adds support for the DT property
 `phy-reset-post-delay` which gives the delay in milliseconds to wait after
>reset.

 If the DT property is not given, no delay is observed. Post reset
 delay greater than 1000ms are invalid.

 Signed-off-by: Quentin Schulz 
 ---

 v2:
   - return -EINVAL when phy-reset-post-delay is greater than 1000ms
   instead of defaulting to 1ms,
   - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
   binding doc and commit log,
   - move phy-reset-post-delay property reading before
   devm_gpio_request_one(),

  Documentation/devicetree/bindings/net/fsl-fec.txt |  4 
  drivers/net/ethernet/freescale/fec_main.c | 16 +++-
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
 b/Documentation/devicetree/bindings/net/fsl-fec.txt
 index a1e3693cca16..6f55bdd52f8a 100644
 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
 +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
 @@ -15,6 +15,10 @@ Optional properties:
  - phy-reset-active-high : If present then the reset sequence using the
>GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
 +- phy-reset-post-delay : Post reset delay in milliseconds. If
 +present then
>>>
>>> This needs unit suffix minimally. It should also have a vendor prefix
>>> or be made generic.
>>>
>>> But really, this is a property of the phy and should be in the phy
>>> node as should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
>>>
>> Yes, it is better to make it general.
>> Last year, Uwe Kleine-König's patch "Commit da47b4572056 ("phy: add
>support for a reset-gpio specification")" did this, but it was reverted by
>commit 948350140ef0 (Revert "phy: add support for a reset-gpio
>specification").  And in all phy device driver, only at803x.c add the gpio 
>reset in
>currently.
>
>Getting the binding correct does not prevent us from later moving this reset
>code into PHYLIB where it's appropriate. In fact; a correct and generic binding
>proposed for FEC here could be used as a basis for all other MAC and PHY
>drivers.
>--
>Florian

I agree with your opinion. Just hope to add the general phy reset interface in 
phylib and special device driver.

Andy


Re: [PATCH linux-firmware] Mellanox: Add firmware for mlxsw_spectrum

2017-05-31 Thread Yotam Gigi
On 05/30/2017 10:22 PM, Kyle McMartin wrote:
> On Mon, May 29, 2017 at 01:42:28PM +0300, Yotam Gigi wrote:
>> Add first firmware for the Mellanox Spectrum switch, as a followup to the
>> recently added commit:
>> 6b7421992b8d ("mlxsw: spectrum: Validate firmware revision on init")
>>
>> The version of the firmware release is 13.1420.122
>>
>> Signed-off-by: Yotam Gigi 
>> ---
>>  mlxsw_spectrum-13.1420.122.mfa2 | Bin 0 -> 860424 bytes
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>  create mode 100644 mlxsw_spectrum-13.1420.122.mfa2
>>
>> diff --git a/mlxsw_spectrum-13.1420.122.mfa2 
>> b/mlxsw_spectrum-13.1420.122.mfa2
>> new file mode 100644
> Can we please put this in a subdirectory if we're going to be adding
> more versions of this in the future?
>
> --Kyle


Ok. Will fix.
Thanks!


[PATCH net-next] ipv4: route: restore skb_dst_set in inet_rtm_getroute

2017-05-31 Thread Roopa Prabhu
From: Roopa Prabhu 

recent updates to inet_rtm_getroute dropped skb_dst_set in
inet_rtm_getroute. This patch restores it because it is
needed to release the dst correctly.

Fixes: 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu versions of 
route lookup")
Reported-by: John Fastabend 
Signed-off-by: David Ahern 
Signed-off-by: Roopa Prabhu 
---
 net/ipv4/route.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f1f2e5a..9b38cf1 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2547,8 +2547,9 @@ struct rtable *ip_route_output_flow(struct net *net, 
struct flowi4 *flp4,
 /* called with rcu_read_lock held */
 static int rt_fill_info(struct net *net,  __be32 dst, __be32 src, u32 table_id,
struct flowi4 *fl4, struct sk_buff *skb, u32 portid,
-   u32 seq, struct rtable *rt)
+   u32 seq)
 {
+   struct rtable *rt = skb_rtable(skb);
struct rtmsg *r;
struct nlmsghdr *nlh;
unsigned long expires = 0;
@@ -2750,6 +2751,7 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
struct nlmsghdr *nlh,
if (err)
goto errout_free;
 
+   skb_dst_set(skb, &rt->dst);
if (rtm->rtm_flags & RTM_F_NOTIFY)
rt->rt_flags |= RTCF_NOTIFY;
 
@@ -2763,8 +2765,7 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
struct nlmsghdr *nlh,
fl4.flowi4_tos, res.fi, 0);
else
err = rt_fill_info(net, dst, src, table_id, &fl4, skb,
-  NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
-  rt);
+  NETLINK_CB(in_skb).portid, nlh->nlmsg_seq);
if (err < 0)
goto errout_free;
 
-- 
1.9.1



Re: [PATCH] net: ethernet: stmmac: Fix altr_tse_pcs SGMII Initialization

2017-05-31 Thread Giuseppe CAVALLARO

On 5/31/2017 9:28 PM, thor.tha...@linux.intel.com wrote:

From: Thor Thayer 

Fix NETDEV WATCHDOG timeout on startup by adding missing register
writes that properly setup SGMII.

Signed-off-by: Thor Thayer 

Thanks a lot for this fix.

Acked-by: Giuseppe Cavallaro 


---
  drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c 
b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
index 489ef14..6a9c954 100644
--- a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
@@ -37,6 +37,7 @@
  #define TSE_PCS_CONTROL_AN_EN_MASKBIT(12)
  #define TSE_PCS_CONTROL_REG   0x00
  #define TSE_PCS_CONTROL_RESTART_AN_MASK   BIT(9)
+#define TSE_PCS_CTRL_AUTONEG_SGMII 0x1140
  #define TSE_PCS_IF_MODE_REG   0x28
  #define TSE_PCS_LINK_TIMER_0_REG  0x24
  #define TSE_PCS_LINK_TIMER_1_REG  0x26
@@ -65,6 +66,7 @@
  #define TSE_PCS_SW_RESET_TIMEOUT  100
  #define TSE_PCS_USE_SGMII_AN_MASK BIT(1)
  #define TSE_PCS_USE_SGMII_ENA BIT(0)
+#define TSE_PCS_IF_USE_SGMII   0x03
  
  #define SGMII_ADAPTER_CTRL_REG0x00

  #define SGMII_ADAPTER_DISABLE 0x0001
@@ -101,7 +103,9 @@ int tse_pcs_init(void __iomem *base, struct tse_pcs *pcs)
  {
int ret = 0;
  
-	writew(TSE_PCS_USE_SGMII_ENA, base + TSE_PCS_IF_MODE_REG);

+   writew(TSE_PCS_IF_USE_SGMII, base + TSE_PCS_IF_MODE_REG);
+
+   writew(TSE_PCS_CTRL_AUTONEG_SGMII, base + TSE_PCS_CONTROL_REG);
  
  	writew(TSE_PCS_SGMII_LINK_TIMER_0, base + TSE_PCS_LINK_TIMER_0_REG);

writew(TSE_PCS_SGMII_LINK_TIMER_1, base + TSE_PCS_LINK_TIMER_1_REG);





Re: loosing netdevices with namespaces and unshare?

2017-05-31 Thread Eric W. Biederman
Cong Wang  writes:
> Network namespace does not special-case the physical devices,
> it treats them all equally as abstract net devices.

Absolutely not true.

The relevant code is in net/core/dev.c:default_device_exit

If a network device does not implement rntl_link_ops it is returned to
the initial network namespace.   Anything else will loose physical
devices.

Only for pure software based devices do we delete them.  Perhaps your
sub interface implements rtnl_link_ops?  Either that or something is
still holding a reference to your network namespace, which would prevent
the network device from being returned.

Eric


Re: running an eBPF program

2017-05-31 Thread Adel Fuchs
Hi,
Thanks for your reply. Where do I need to add this workaround?

Thanks,
Adel

On Mon, May 29, 2017 at 8:31 AM, Y Song  wrote:
> On Sun, May 28, 2017 at 12:38 AM, Adel Fuchs  wrote:
>> Hi,
>> Is there any way to run this eBPF program without that patch?
>> Alternatively, is there any other eBPF sample that does run properly? I need
>> to run a program that filters packets according to IP address or port.
>
> The following is temporary workaround you can use:
> int poff, nh_off = BPF_LL_OFF + ETH_HLEN;
> -   __be16 proto = skb->protocol;
> +   __be16 proto = (__be16)*(volatile __u32 *)&skb->protocol;
> __u8 ip_proto;


Re: running an eBPF program

2017-05-31 Thread Adel Fuchs
OK. Found it. Thanks! it works!

On Thu, Jun 1, 2017 at 9:43 AM, Adel Fuchs  wrote:
> Hi,
> Thanks for your reply. Where do I need to add this workaround?
>
> Thanks,
> Adel
>
> On Mon, May 29, 2017 at 8:31 AM, Y Song  wrote:
>> On Sun, May 28, 2017 at 12:38 AM, Adel Fuchs  wrote:
>>> Hi,
>>> Is there any way to run this eBPF program without that patch?
>>> Alternatively, is there any other eBPF sample that does run properly? I need
>>> to run a program that filters packets according to IP address or port.
>>
>> The following is temporary workaround you can use:
>> int poff, nh_off = BPF_LL_OFF + ETH_HLEN;
>> -   __be16 proto = skb->protocol;
>> +   __be16 proto = (__be16)*(volatile __u32 *)&skb->protocol;
>> __u8 ip_proto;


[PATCH v2] xfrm: fix xfrm_dev_event() missing when compile without CONFIG_XFRM_OFFLOAD

2017-05-31 Thread Hangbin Liu
In commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") we
make xfrm_device.o only compiled when enable option CONFIG_XFRM_OFFLOAD.
But this will make xfrm_dev_event() missing if we only enable default XFRM
options.

Then if we set down and unregister an interface with IPsec on it. there
will no xfrm_garbage_collect(), which will cause dev usage count hold and
get error like:

unregister_netdevice: waiting for  to become free. Usage count = 4

Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
Signed-off-by: Hangbin Liu 
---
 include/net/xfrm.h | 7 ++-
 net/xfrm/Makefile  | 3 +--
 net/xfrm/xfrm_device.c | 2 ++
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 7e7e2b0..62f5a25 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1850,8 +1850,9 @@ static inline struct xfrm_offload *xfrm_offload(struct 
sk_buff *skb)
 }
 #endif
 
-#ifdef CONFIG_XFRM_OFFLOAD
 void __net_init xfrm_dev_init(void);
+
+#ifdef CONFIG_XFRM_OFFLOAD
 int validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t features);
 int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
   struct xfrm_user_offload *xuo);
@@ -1877,10 +1878,6 @@ static inline void xfrm_dev_state_free(struct xfrm_state 
*x)
}
 }
 #else
-static inline void __net_init xfrm_dev_init(void)
-{
-}
-
 static inline int validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t 
features)
 {
return 0;
diff --git a/net/xfrm/Makefile b/net/xfrm/Makefile
index abf81b3..55b2ac3 100644
--- a/net/xfrm/Makefile
+++ b/net/xfrm/Makefile
@@ -4,8 +4,7 @@
 
 obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_hash.o \
  xfrm_input.o xfrm_output.o \
- xfrm_sysctl.o xfrm_replay.o
-obj-$(CONFIG_XFRM_OFFLOAD) += xfrm_device.o
+ xfrm_sysctl.o xfrm_replay.o xfrm_device.o
 obj-$(CONFIG_XFRM_STATISTICS) += xfrm_proc.o
 obj-$(CONFIG_XFRM_ALGO) += xfrm_algo.o
 obj-$(CONFIG_XFRM_USER) += xfrm_user.o
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 574e6f3..5aba036 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_XFRM_OFFLOAD
 int validate_xmit_xfrm(struct sk_buff *skb, netdev_features_t features)
 {
int err;
@@ -137,6 +138,7 @@ bool xfrm_dev_offload_ok(struct sk_buff *skb, struct 
xfrm_state *x)
return true;
 }
 EXPORT_SYMBOL_GPL(xfrm_dev_offload_ok);
+#endif
 
 int xfrm_dev_register(struct net_device *dev)
 {
-- 
2.5.5



[PATCH] mISDN: Fix a sleep-in-atomic bug

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a read spin lock, and the function call path is:
send_socklist (acquire the lock by read_lock)
  skb_copy(GFP_KERNEL) --> may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai 
---
 drivers/isdn/mISDN/stack.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/mISDN/stack.c b/drivers/isdn/mISDN/stack.c
index 8b7faea..422dced 100644
--- a/drivers/isdn/mISDN/stack.c
+++ b/drivers/isdn/mISDN/stack.c
@@ -75,7 +75,7 @@
if (sk->sk_state != MISDN_BOUND)
continue;
if (!cskb)
-   cskb = skb_copy(skb, GFP_KERNEL);
+   cskb = skb_copy(skb, GFP_ATOMIC);
if (!cskb) {
printk(KERN_WARNING "%s no skb\n", __func__);
break;
-- 
1.7.9.5




[PATCH v6 10/21] arm: sun8i: orangepi-one: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI One.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 5fea430e0eb1..6880268e8b87 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
 
aliases {
+   ethernet0 = &emac;
serial0 = &uart0;
};
 
@@ -97,6 +98,13 @@
status = "okay";
 };
 
+&emac {
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
-- 
2.13.0



[PATCH v6 21/21] arm64: defconfig: Enable dwmac-sun8i driver on defconfig

2017-05-31 Thread Corentin Labbe
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig.

Signed-off-by: Corentin Labbe 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 000de61802a1..fd7d22b8480c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,7 @@ CONFIG_RAVB=y
 CONFIG_SMC91X=y
 CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_SUN8I=m
 CONFIG_MDIO_BUS_MUX_MMIOREG=y
 CONFIG_MESON_GXL_PHY=m
 CONFIG_MICREL_PHY=y
-- 
2.13.0



[PATCH v6 20/21] arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig

2017-05-31 Thread Corentin Labbe
Enable the dwmac-sun8i driver in the multi_v7 default configuration

Signed-off-by: Corentin Labbe 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 705d908e004a..60c0c01002c2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=y
 CONFIG_STMMAC_PLATFORM=y
 CONFIG_DWMAC_DWC_QOS_ETH=y
+CONFIG_DWMAC_SUN8I=y
 CONFIG_TI_CPSW=y
 CONFIG_XILINX_EMACLITE=y
 CONFIG_AT803X_PHY=y
-- 
2.13.0



[PATCH v6 17/21] arm64: allwinner: pine64-plus: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.

Signed-off-by: Corentin Labbe 
---
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..24f1aac366d6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -46,5 +46,20 @@
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
 
-   /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+   /* TODO: Camera, touchscreen, etc. */
+};
+
+&emac {
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <&ext_rgmii_phy>;
+   status = "okay";
+};
+
+&mdio {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
 };
-- 
2.13.0



[PATCH v6 19/21] arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig

2017-05-31 Thread Corentin Labbe
Enable the dwmac-sun8i driver in the sunxi default configuration

Signed-off-by: Corentin Labbe 
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70bc83..504e02238031 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
 CONFIG_NETDEVICES=y
 CONFIG_SUN4I_EMAC=y
+CONFIG_DWMAC_SUN8I=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
-- 
2.13.0



[PATCH v6 13/21] arm: sun8i: nanopi-neo: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the NanoPi Neo.
It uses the internal PHY.
This patch create the needed emac node.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 8d2cc6e9a03f..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -46,3 +46,10 @@
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
 };
+
+&emac {
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
-- 
2.13.0



[PATCH v6 18/21] arm64: allwinner: bananapi-m64: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i  hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.

Signed-off-by: Corentin Labbe 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 6872135d7f84..0d1f026d831a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -67,6 +67,14 @@
};
 };
 
+&emac {
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <&ext_rgmii_phy>;
+   status = "okay";
+};
+
 &i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -77,6 +85,13 @@
bias-pull-up;
 };
 
+&mdio {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
-- 
2.13.0



[PATCH v6 16/21] arm64: allwinner: pine64: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.

Signed-off-by: Corentin Labbe 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..08cda24ea194 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -78,6 +78,15 @@
status = "okay";
 };
 
+&emac {
+   pinctrl-names = "default";
+   pinctrl-0 = <&rmii_pins>;
+   phy-mode = "rmii";
+   phy-handle = <&ext_rmii_phy1>;
+   status = "okay";
+
+};
+
 &i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -88,6 +97,13 @@
bias-pull-up;
 };
 
+&mdio {
+   ext_rmii_phy1: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
-- 
2.13.0



[PATCH v6 15/21] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.

Signed-off-by: Corentin Labbe 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2eeba0d44074..7a07353ac1f6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -309,6 +309,21 @@
bias-pull-up;
};
 
+   rmii_pins: rmii_pins {
+   pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+  "PD18", "PD19", "PD20", "PD22", "PD23";
+   function = "emac";
+   drive-strength = <40>;
+   };
+
+   rgmii_pins: rgmii_pins {
+   pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+  "PD13", "PD15", "PD16", "PD17", "PD18",
+  "PD19", "PD20", "PD21", "PD22", "PD23";
+   function = "emac";
+   drive-strength = <40>;
+   };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
@@ -433,6 +448,26 @@
#size-cells = <0>;
};
 
+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun50i-a64-emac";
+   syscon = <&syscon>;
+   reg = <0x01c3 0x100>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   resets = <&ccu RST_BUS_EMAC>;
+   reset-names = "stmmaceth";
+   clocks = <&ccu CLK_BUS_EMAC>;
+   clock-names = "stmmaceth";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
-- 
2.13.0



[PATCH v6 12/21] arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high

2017-05-31 Thread Corentin Labbe
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.

Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c781a7..a10281b455f5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
 };
 
+&emac {
+   /* LEDs changed to active high on the plus */
+   /delete-property/ allwinner,leds-active-low;
+};
+
 &mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
-- 
2.13.0



[PATCH v6 14/21] arm64: allwinner: sun50i-a64: Add dt node for the syscon control module

2017-05-31 Thread Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner A64.

Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.

Signed-off-by: Corentin Labbe 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..2eeba0d44074 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -129,6 +129,12 @@
#size-cells = <1>;
ranges;
 
+   syscon: syscon@1c0 {
+   compatible = "allwinner,sun50i-a64-system-controller",
+   "syscon";
+   reg = <0x01c0 0x1000>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.13.0



[PATCH v6 11/21] arm: sun8i: orangepi-2: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 8ff71b1bb45b..17cdeae19c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+   ethernet0 = &emac;
ethernet1 = &rtl8189;
};
 
@@ -117,6 +118,13 @@
status = "okay";
 };
 
+&emac {
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
-- 
2.13.0



[PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig|  11 +
 drivers/net/ethernet/stmicro/stmmac/Makefile   |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  | 990 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  15 +
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   9 +-
 include/linux/stmmac.h |   1 +
 6 files changed, 1025 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cfbe3634dfa1..85c0e41f8021 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -145,6 +145,17 @@ config DWMAC_SUNXI
  This selects Allwinner SoC glue layer support for the
  stmmac device driver. This driver is used for A20/A31
  GMAC ethernet controller.
+
+config DWMAC_SUN8I
+   tristate "Allwinner sun8i GMAC support"
+   default ARCH_SUNXI
+   depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+   ---help---
+ Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for H3/A83T/A64
+ EMAC ethernet controller.
 endif
 
 config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c60336674..fd4937a7fcab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA)   += dwmac-altr-socfpga.o
 obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
 obj-$(CONFIG_DWMAC_STM32)  += dwmac-stm32.o
 obj-$(CONFIG_DWMAC_SUNXI)  += dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_SUN8I)  += dwmac-sun8i.o
 obj-$(CONFIG_DWMAC_DWC_QOS_ETH)+= dwmac-dwc-qos-eth.o
 obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
 stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
new file mode 100644
index ..1a6bfe6c958f
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -0,0 +1,990 @@
+/*
+ * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
+ *
+ * Copyright (C) 2017 Corentin Labbe 
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* General notes on dwmac-sun8i:
+ * Locking: no locking is necessary in this file because all necessary locking
+ * is done in the "stmmac files"
+ */
+
+/* struct emac_variant - Descrive dwmac-sun8i hardware variant
+ * @default_syscon_value:  The default value of the EMAC register in syscon
+ * This value is used for disabling properly EMAC
+ * and used as a good starting value in case of the
+ * boot process(uboot) leave some stuff.
+ * @internal_phy:  Does the MAC embed an internal PHY
+ * @support_mii:   Does the MAC handle MII
+ * @support_rmii:  Does the MAC handle RMII
+ * @support_rgmii: Does the MAC handle RGMII
+ */
+struct emac_variant {
+   u32 default_syscon_value;
+   int internal_phy;
+   bool support_mii;
+   bool support_rmii;
+   bool support_rgmii;
+};
+
+/* struct sunxi_priv_data - hold all sunxi private data
+ * @tx_clk:reference to MAC TX clock
+ * @ephy_clk:  reference to the optional EPHY clock for the internal PHY
+ * @regulator: reference to the optional regulator
+ * @rst_ephy:  reference to the optional EPHY reset for the internal PHY
+ * @variant:   reference to the current board variant
+ * @regmap:regmap for using the syscon
+ * @use_internal_phy: Does the current PHY choice imply using the internal PHY
+ */
+struct sunxi_priv_data {
+   struct clk *tx_clk;
+   struct clk *ephy_clk;
+   struct regulator *regulator;
+   struct reset_control *rst_ephy;
+   const struct emac_variant *variant

[PATCH v6 09/21] arm: sun8i: orangepi-zero: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI Zero.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 9e8b082c134f..dd3525a0f06a 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+   ethernet0 = &emac;
ethernet1 = &xr819;
};
 
@@ -103,6 +104,13 @@
status = "okay";
 };
 
+&emac {
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
-- 
2.13.0



[PATCH v6 06/21] arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module

2017-05-31 Thread Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner H3/H5

Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock..

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d0067fec99de..3a28be5ab641 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -83,6 +83,12 @@
#size-cells = <1>;
ranges;
 
+   syscon: syscon@1c0 {
+   compatible = "allwinner,sun8i-h3-system-controller",
+   "syscon";
+   reg = <0x01c0 0x1000>;
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
-- 
2.13.0



[PATCH v6 07/21] arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.

This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree.
SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 3a28be5ab641..9e4a496f3cca 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -285,6 +285,14 @@
interrupt-controller;
#interrupt-cells = <3>;
 
+   emac_rgmii_pins: emac0 {
+   pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+  "PD5", "PD7", "PD8", "PD9", "PD10",
+  "PD12", "PD13", "PD15", "PD16", "PD17";
+   function = "emac";
+   drive-strength = <40>;
+   };
+
i2c0_pins: i2c0 {
pins = "PA11", "PA12";
function = "i2c0";
@@ -381,6 +389,32 @@
clocks = <&osc24M>;
};
 
+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <&syscon>;
+   reg = <0x01c3 0x104>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   resets = <&ccu RST_BUS_EMAC>;
+   reset-names = "stmmaceth";
+   clocks = <&ccu CLK_BUS_EMAC>;
+   clock-names = "stmmaceth";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   mdio: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   int_mii_phy: ethernet-phy@1 {
+   compatible = 
"ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   clocks = <&ccu CLK_BUS_EPHY>;
+   resets = <&ccu RST_BUS_EPHY>;
+   };
+   };
+   };
+
spi0: spi@01c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
-- 
2.13.0



[PATCH v6 08/21] arm: sun8i: orangepi-pc: Enable dwmac-sun8i

2017-05-31 Thread Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI PC.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 1a044b17d6c6..998b60f8d295 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
 
aliases {
+   ethernet0 = &emac;
serial0 = &uart0;
};
 
@@ -113,6 +114,13 @@
status = "okay";
 };
 
+&emac {
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
-- 
2.13.0



[PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon

2017-05-31 Thread Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.

Signed-off-by: Corentin Labbe 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt

diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt 
b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index ..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+   "allwinner,sun8i-h3-system-controller"
+   "allwinner,sun50i-a64-system-controller"
+   "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@1c0 {
+   compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+   reg = <0x01c0 0x1000>;
+};
-- 
2.13.0



[PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr

2017-05-31 Thread Corentin Labbe
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
 }
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
 
 /* Enable disable MAC RX/TX */
 void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned 
char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
 }
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
-- 
2.13.0



[PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i

2017-05-31 Thread Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.

Signed-off-by: Corentin Labbe 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/net/dwmac-sun8i.txt| 78 ++
 1 file changed, 78 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt 
b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index ..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+   "allwinner,sun8i-a83t-emac"
+   "allwinner,sun8i-h3-emac"
+   "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+  - allwinner,sun8i-h3-system-controller
+  - allwinner,sun50i-a64-system-controller
+  - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 
0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 
0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <&syscon>;
+   reg = <0x01c0b000 0x104>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   resets = <&ccu RST_BUS_EMAC>;
+   reset-names = "stmmaceth";
+   clocks = <&ccu CLK_BUS_EMAC>;
+   clock-names = "stmmaceth";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy-handle = <&int_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   mdio: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   int_mii_phy: ethernet-phy@1 {
+   reg = <1>;
+   clocks = <&ccu CLK_BUS_EPHY>;
+   resets = <&ccu RST_BUS_EPHY>;
+   };
+   };
+};
-- 
2.13.0



[PATCH v6 02/21] net-next: stmmac: add optional setup function

2017-05-31 Thread Corentin Labbe
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
 include/linux/stmmac.h| 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
 
/* Identify the MAC HW device */
-   if (priv->plat->has_gmac) {
+   if (priv->plat->setup) {
+   mac = priv->plat->setup(priv);
+   } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
  priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+   struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
-- 
2.13.0



[PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

2017-05-31 Thread Corentin Labbe
Hello

This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.

This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.

It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.

This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.

The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3

The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.

Regards
Corentin Labbe

Changes since v5:
- Added DT patch for NanoPi neo
- Use the new adjust_link variables (speedxxx/speedmask)
- Made the timeout of readl_poll_timeout from 10 to 100ms
- Fix sun8i_unpower_phy that could be called twice
- Replace phy by phy-handle in doc/dwmac-sun8i.txt

Changes since v4:
- Re-ordered by alphabetical order some DT nodes
- Simplified power/unpower_phy functions by testing the use of internal_phy
- Added a patch for adding dwmac-sun8i to arm64 defconfig
- Fix a typo in sun50i-a64-system-controller (wrongly used sun8i)
- Reworked uc/mc filter address setting

Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further

Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function

Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs

Corentin Labbe (21):
  net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
  net-next: stmmac: add optional setup function
  dt-bindings: net-next: Add DT bindings documentation for Allwinner
dwmac-sun8i
  dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
  net-next: stmmac: Add dwmac-sun8i
  arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
  arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
  arm: sun8i: orangepi-pc: Enable dwmac-sun8i
  arm: sun8i: orangepi-zero: Enable dwmac-sun8i
  arm: sun8i: orangepi-one: Enable dwmac-sun8i
  arm: sun8i: orangepi-2: Enable dwmac-sun8i
  arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
  arm: sun8i: nanopi-neo: Enable dwmac-sun8i
  arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
  arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
  arm64: allwinner: pine64: Enable dwmac-sun8i
  arm64: allwinner: pine64-plus: Enable dwmac-sun8i
  arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
  arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
  arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
  arm64: defconfig: Enable dwmac-sun8i driver on defconfig

 .../devicetree/bindings/misc/allwinner,syscon.txt  |  19 +
 .../devicetree/bindings/net/dwmac-sun8i.txt|  78 ++
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  |   8 +
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts  |   7 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |   8 +
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts|   8 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts|   5 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts |   8 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi |  40 +
 arch/arm/configs/multi_v7_defconfig|   1 +
 arch/arm/configs/sunxi_defconfig   |   1 +
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts |  15 +
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  17 +-
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  16 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  41 +
 arch/arm64/configs/defconfig   |   1 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig|  11 +
 drivers/net/ethernet/stmicro/stmmac/Makefile   |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  | 990 +
 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c|   3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  19 +-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   9 +-
 include/linux/stmmac.h |   2 +
 23 files changed, 1303 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
 create mode 100644 Docu

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

2017-05-31 Thread Bastian Bittorf
* Johannes Berg  [31.05.2017 10:09]:
> > Is there any way to dump out the socket information if we reproduce
> > the problem?
> 
> I have no idea, sorry.
> 
> If you or Bastian can tell me how to reproduce the problem, I can try
> to investigate it.

there was an interesting fix regarding the shell-builtin 'read' in
busybox[1]. I will retest again and report if this changes anything.

bye, bastian

PS: @ben: are you also using 'iw event | while read -r LINE ...'?

[1]
https://git.busybox.net/busybox/commit/?id=f5470419404d643070db99d058405b714695b817


[PATCH net-next] nfp: add MAY_USE_DEVLINK dependency

2017-05-31 Thread Arnd Bergmann
When devlink is configured as a loadable module, a built-in nfp driver
causes a link error:

drivers/net/built-in.o: In function `nfp_devlink_port_register':
(.text+0xb8b05): undefined reference to `devlink_port_type_eth_set'
drivers/net/built-in.o: In function `nfp_devlink_port_register':
(.text+0xb8b16): undefined reference to `devlink_port_split_set'

This adds a special Kconfig dependency on CONFIG_MAY_USE_DEVLINK
to avoid that combination and force nfp to be a module when NET_DEVLINK=m.

Fixes: 1851f93fd2ee ("nfp: add devlink support")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/netronome/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/netronome/Kconfig 
b/drivers/net/ethernet/netronome/Kconfig
index 967d7ca8c28c..0d5a7b9203a4 100644
--- a/drivers/net/ethernet/netronome/Kconfig
+++ b/drivers/net/ethernet/netronome/Kconfig
@@ -19,6 +19,7 @@ config NFP
tristate "Netronome(R) NFP4000/NFP6000 NIC driver"
depends on PCI && PCI_MSI
depends on VXLAN || VXLAN=n
+   depends on MAY_USE_DEVLINK
---help---
  This driver supports the Netronome(R) NFP4000/NFP6000 based
  cards working as a advanced Ethernet NIC.  It works with both
-- 
2.9.0



[PATCH net-next 2/2] sctp: merge sctp_stream_new and sctp_stream_init

2017-05-31 Thread Xin Long
Since last patch, sctp doesn't need to alloc memory for asoc->stream any
more. sctp_stream_new and sctp_stream_init both are used to alloc memory
for stream.in or stream.out, and their names are also confusing.

This patch is to merge them into sctp_stream_init, and only pass stream
and streamcnt parameters into it, instead of the whole asoc.

Signed-off-by: Xin Long 
---
 include/net/sctp/structs.h |  4 ++--
 net/sctp/associola.c   |  3 ++-
 net/sctp/sm_make_chunk.c   |  3 ++-
 net/sctp/stream.c  | 33 +++--
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index c8dbf41..5051317 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -377,8 +377,8 @@ typedef struct sctp_sender_hb_info {
__u64 hb_nonce;
 } sctp_sender_hb_info_t;
 
-int sctp_stream_new(struct sctp_association *asoc, gfp_t gfp);
-int sctp_stream_init(struct sctp_association *asoc, gfp_t gfp);
+int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
+gfp_t gfp);
 void sctp_stream_free(struct sctp_stream *stream);
 void sctp_stream_clear(struct sctp_stream *stream);
 void sctp_stream_update(struct sctp_stream *stream, struct sctp_stream *new);
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 6625b15..288c5e0 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -246,7 +246,8 @@ static struct sctp_association 
*sctp_association_init(struct sctp_association *a
if (!sctp_ulpq_init(&asoc->ulpq, asoc))
goto fail_init;
 
-   if (sctp_stream_new(asoc, gfp))
+   if (sctp_stream_init(&asoc->stream, asoc->c.sinit_num_ostreams,
+0, gfp))
goto fail_init;
 
/* Assume that peer would support both address types unless we are
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 2441814..bd439ed 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2454,7 +2454,8 @@ int sctp_process_init(struct sctp_association *asoc, 
struct sctp_chunk *chunk,
 * stream sequence number shall be set to 0.
 */
 
-   if (sctp_stream_init(asoc, gfp))
+   if (sctp_stream_init(&asoc->stream, asoc->c.sinit_num_ostreams,
+asoc->c.sinit_max_instreams, gfp))
goto clean_up;
 
if (!asoc->temp && sctp_assoc_set_id(asoc, gfp))
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index af6b498..82e6d40 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -35,47 +35,36 @@
 #include 
 #include 
 
-int sctp_stream_new(struct sctp_association *asoc, gfp_t gfp)
+int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
+gfp_t gfp)
 {
-   struct sctp_stream *stream = &asoc->stream;
-   int i;
-
-   stream->outcnt = asoc->c.sinit_num_ostreams;
-   stream->out = kcalloc(stream->outcnt, sizeof(*stream->out), gfp);
-   if (!stream->out)
-   return -ENOMEM;
-
-   for (i = 0; i < stream->outcnt; i++)
-   stream->out[i].state = SCTP_STREAM_OPEN;
-
-   return 0;
-}
-
-int sctp_stream_init(struct sctp_association *asoc, gfp_t gfp)
-{
-   struct sctp_stream *stream = &asoc->stream;
int i;
 
/* Initial stream->out size may be very big, so free it and alloc
 * a new one with new outcnt to save memory.
 */
kfree(stream->out);
-   stream->outcnt = asoc->c.sinit_num_ostreams;
-   stream->out = kcalloc(stream->outcnt, sizeof(*stream->out), gfp);
+
+   stream->out = kcalloc(outcnt, sizeof(*stream->out), gfp);
if (!stream->out)
return -ENOMEM;
 
+   stream->outcnt = outcnt;
for (i = 0; i < stream->outcnt; i++)
stream->out[i].state = SCTP_STREAM_OPEN;
 
-   stream->incnt = asoc->c.sinit_max_instreams;
-   stream->in = kcalloc(stream->incnt, sizeof(*stream->in), gfp);
+   if (!incnt)
+   return 0;
+
+   stream->in = kcalloc(incnt, sizeof(*stream->in), gfp);
if (!stream->in) {
kfree(stream->out);
stream->out = NULL;
return -ENOMEM;
}
 
+   stream->incnt = incnt;
+
return 0;
 }
 
-- 
2.1.0



[PATCH net-next 1/2] sctp: define the member stream as an object instead of pointer in asoc

2017-05-31 Thread Xin Long
As Marcelo's suggestion, stream is a fixed size member of asoc and would
not grow with more streams. To avoid an allocation for it, this patch is
to define it as an object instead of pointer and update the places using
it, also create sctp_stream_update() called in sctp_assoc_update() to
migrate the stream info from one stream to another.

Signed-off-by: Xin Long 
---
 include/net/sctp/structs.h |  3 +-
 net/sctp/associola.c   | 13 -
 net/sctp/chunk.c   |  4 +--
 net/sctp/outqueue.c| 10 +++
 net/sctp/proc.c|  4 +--
 net/sctp/sm_make_chunk.c   |  2 +-
 net/sctp/sm_statefuns.c|  8 +++---
 net/sctp/socket.c  | 14 +-
 net/sctp/stream.c  | 68 ++
 net/sctp/ulpqueue.c|  8 +++---
 10 files changed, 65 insertions(+), 69 deletions(-)

diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index a8b38e1..c8dbf41 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -381,6 +381,7 @@ int sctp_stream_new(struct sctp_association *asoc, gfp_t 
gfp);
 int sctp_stream_init(struct sctp_association *asoc, gfp_t gfp);
 void sctp_stream_free(struct sctp_stream *stream);
 void sctp_stream_clear(struct sctp_stream *stream);
+void sctp_stream_update(struct sctp_stream *stream, struct sctp_stream *new);
 
 /* What is the current SSN number for this stream? */
 #define sctp_ssn_peek(stream, type, sid) \
@@ -1750,7 +1751,7 @@ struct sctp_association {
__u32 default_rcv_context;
 
/* Stream arrays */
-   struct sctp_stream *stream;
+   struct sctp_stream stream;
 
/* All outbound chunks go through this structure.  */
struct sctp_outq outqueue;
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 9523828..6625b15 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -291,7 +291,7 @@ static struct sctp_association 
*sctp_association_init(struct sctp_association *a
return asoc;
 
 stream_free:
-   sctp_stream_free(asoc->stream);
+   sctp_stream_free(&asoc->stream);
 fail_init:
sock_put(asoc->base.sk);
sctp_endpoint_put(asoc->ep);
@@ -365,7 +365,7 @@ void sctp_association_free(struct sctp_association *asoc)
sctp_tsnmap_free(&asoc->peer.tsn_map);
 
/* Free stream information. */
-   sctp_stream_free(asoc->stream);
+   sctp_stream_free(&asoc->stream);
 
if (asoc->strreset_chunk)
sctp_chunk_free(asoc->strreset_chunk);
@@ -1151,7 +1151,7 @@ void sctp_assoc_update(struct sctp_association *asoc,
/* Reinitialize SSN for both local streams
 * and peer's streams.
 */
-   sctp_stream_clear(asoc->stream);
+   sctp_stream_clear(&asoc->stream);
 
/* Flush the ULP reassembly and ordered queue.
 * Any data there will now be stale and will
@@ -1177,11 +1177,8 @@ void sctp_assoc_update(struct sctp_association *asoc,
asoc->ctsn_ack_point = asoc->next_tsn - 1;
asoc->adv_peer_ack_point = asoc->ctsn_ack_point;
 
-   if (sctp_state(asoc, COOKIE_WAIT)) {
-   sctp_stream_free(asoc->stream);
-   asoc->stream = new->stream;
-   new->stream = NULL;
-   }
+   if (sctp_state(asoc, COOKIE_WAIT))
+   sctp_stream_update(&asoc->stream, &new->stream);
 
if (!asoc->assoc_id) {
/* get a new association id since we don't have one
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index 697721a..81466f6 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chunk.c
@@ -307,7 +307,7 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
if (SCTP_PR_TTL_ENABLED(chunk->sinfo.sinfo_flags) &&
time_after(jiffies, chunk->msg->expires_at)) {
struct sctp_stream_out *streamout =
-   &chunk->asoc->stream->out[chunk->sinfo.sinfo_stream];
+   &chunk->asoc->stream.out[chunk->sinfo.sinfo_stream];
 
if (chunk->sent_count) {
chunk->asoc->abandoned_sent[SCTP_PR_INDEX(TTL)]++;
@@ -320,7 +320,7 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
} else if (SCTP_PR_RTX_ENABLED(chunk->sinfo.sinfo_flags) &&
   chunk->sent_count > chunk->sinfo.sinfo_timetolive) {
struct sctp_stream_out *streamout =
-   &chunk->asoc->stream->out[chunk->sinfo.sinfo_stream];
+   &chunk->asoc->stream.out[chunk->sinfo.sinfo_stream];
 
chunk->asoc->abandoned_sent[SCTP_PR_INDEX(RTX)]++;
streamout->abandoned_sent[SCTP_PR_INDEX(RTX)]++;
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index fe4c3d46..20299df 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -363,7 +363,7 @@ static int sctp_prsctp_prune_sent(struct

[PATCH net-next 0/2] sctp: improve asoc streams management

2017-05-31 Thread Xin Long
This patchset changes to define asoc->stream as an object, and also
improve some codes to make it more clearly.

Xin Long (2):
  sctp: define the member stream as an object instead of pointer in asoc
  sctp: merge sctp_stream_new and sctp_stream_init

 include/net/sctp/structs.h |  7 ++--
 net/sctp/associola.c   | 16 
 net/sctp/chunk.c   |  4 +-
 net/sctp/outqueue.c| 10 ++---
 net/sctp/proc.c|  4 +-
 net/sctp/sm_make_chunk.c   |  5 ++-
 net/sctp/sm_statefuns.c|  8 ++--
 net/sctp/socket.c  | 14 +++
 net/sctp/stream.c  | 93 --
 net/sctp/ulpqueue.c|  8 ++--
 10 files changed, 78 insertions(+), 91 deletions(-)

-- 
2.1.0



Re: [PATCH net-next] powerpc: use asm-generic/socket.h as much as possible

2017-05-31 Thread Arnd Bergmann
On Wed, May 31, 2017 at 7:43 AM, Stephen Rothwell  wrote:
> asm-generic/socket.h already has an exception for the differences that
> powerpc needs, so just include it after defining the differences.
>
> Signed-off-by: Stephen Rothwell 

Acked-by: Arnd Bergmann 


Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-05-31 Thread Nicolas Dichtel
Le 30/05/2017 à 23:33, Flavio Leitner a écrit :
> Don't include netns id for notifications broadcasts when the
> socket and the skb are in the same netns because it will be
> an error which can't be distinguished from a peer netns failing
> to allocate an id.
I don't understand the problem. peernet2id() doesn't allocate ids, it only do a
lookup. If you need an id for the current netns, you have to allocate one.

This patch changes the metadata exported to the userland and will break existing
tools.


Re: [PATCH] net: rtnetlink: bail out from rtnl_fdb_dump() on parse error

2017-05-31 Thread Alexander Potapenko
Hi David,

I've noticed that the upstream patch:
https://github.com/torvalds/linux/commit/0ff50e83b5122e836ca492fefb11656b225ac29c
contains the KMSAN report and the repro, despite I've put them under
the triple dash (IIRC Eric told me I shouldn't bloat the patch
descriptions with that information). Did I mess it up somehow?

Alex

On Wed, May 24, 2017 at 9:32 PM, David Miller  wrote:
> From: Alexander Potapenko 
> Date: Tue, 23 May 2017 13:20:28 +0200
>
>> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which led
>> to contents of |ifm| being uninitialized because nlh->nlmsglen was too
>> small to accommodate |ifm|. The uninitialized data may affect some
>> branches and result in unwanted effects, although kernel data doesn't
>> seem to leak to the userspace directly.
>>
>> The bug has been detected with KMSAN and syzkaller.
>>
>> Signed-off-by: Alexander Potapenko 
>
> Applied, thanks.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg


Re: [PATCH net-next] nfp: add MAY_USE_DEVLINK dependency

2017-05-31 Thread Jakub Kicinski
On Wed, 31 May 2017 10:16:50 +0200, Arnd Bergmann wrote:
> When devlink is configured as a loadable module, a built-in nfp driver
> causes a link error:
> 
> drivers/net/built-in.o: In function `nfp_devlink_port_register':
> (.text+0xb8b05): undefined reference to `devlink_port_type_eth_set'
> drivers/net/built-in.o: In function `nfp_devlink_port_register':
> (.text+0xb8b16): undefined reference to `devlink_port_split_set'
> 
> This adds a special Kconfig dependency on CONFIG_MAY_USE_DEVLINK
> to avoid that combination and force nfp to be a module when NET_DEVLINK=m.

Thanks, this should be fixed in net-next already by commit 
d935bc84c940 ("nfp: add MAY_USE_DEVLINK dependency").  Same 
subject/commit title as yours :)


[PATCH] netxen: Fix a sleep-in-atomic bug in netxen_nic_hw_read_wx_2M and netxen_nic_hw_write_wx_2M

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a write spin lock, and function call path is:
netxen_nic_hw_read_wx_2M (acquire the lock by write_lock_irqsave)
  crb_win_lock
netxen_pcie_sem_lock
  msleep --> may sleep
netxen_nic_hw_write_wx_2M (acquire the lock by write_lock_irqsave)
  crb_win_lock
netxen_pcie_sem_lock
  msleep --> may sleep

To fix it, the "msleep" is replaced with "mdelay" in netxen_pcie_sem_lock.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c 
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index a996801..0a9da42 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -329,7 +329,7 @@ static void __iomem *pci_base_offset(struct netxen_adapter 
*adapter,
break;
if (++timeout >= NETXEN_PCIE_SEM_TIMEOUT)
return -EIO;
-   msleep(1);
+   mdelay(1);
}
 
if (id_reg)
-- 
1.7.9.5




Dear Friend,

2017-05-31 Thread Ja Ikh
Dear Friend,

How are you? I want to inquire from you if you can handle a
transaction for mutual benefits/life opportunity for you and me. I am
Dr.Jaslin Ikhsan. The Chief International Relation Foreign
RemittanceUnit of my bank here in Burkina Faso Ouagadougou Branch.

I Have an Opportunity to the Sum of Fifteen Million, Five Hundred
Thousand United States Dollars(US$15.500.000.00), to transfer into
your bank account over there in your country. I will provide the full
details of this business transaction when once we known each other as
business with trust. I personally will contact you and you alone.
(jaslin.ikhsa...@gmail.com)
The fund will be shared at the ratio of 58% for me. 40% for you and 2%
will be set aside to cover any expenses and tax in your bank.

Please treat this business proposal with utmost confidentiality and
send me the following Information's if you areinterested.

Your Full Name:
Your Address:...
Your Age: ...
Your Direct Phone Numbers:.
Your Country:...
Your Profession:...
Your Sex: 

Thanks and best regards.
Dr.Jaslin Ikhsan .M.sc (ECONS)
HousePhone: 00226 79 43 61 08
(jaslin.ikhsa...@gmail.com)


[PATCH] netxen: Fix a sleep-in-atomic bug in netxen_nic_pci_mem_access_direct

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
netxen_nic_pci_mem_access_direct (acquire the lock by spin_lock)
  ioremap --> may sleep

To fix it, the lock is released before "ioremap", and the lock is 
acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c 
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index a996801..5ea553e 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -1419,7 +1419,9 @@ static u32 netxen_nic_io_read_2M(struct netxen_adapter 
*adapter,
 
mem_base = pci_resource_start(adapter->pdev, 0) +
(start & PAGE_MASK);
+   spin_unlock(&adapter->ahw.mem_lock);
mem_ptr = ioremap(mem_base, PAGE_SIZE);
+   spin_lock(&adapter->ahw.mem_lock);
if (mem_ptr == NULL) {
ret = -EIO;
goto unlock;
-- 
1.7.9.5




net/ipv6: use-after-free in ip6_dst_ifdown

2017-05-31 Thread Andrey Konovalov
Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
Read of size 8 at addr 88006afa4ad8 by task syz-executor6/23554

CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x73/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x22b/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
 ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
 dst_ifdown+0x75/0x230 net/core/dst.c:439
 dst_dev_event+0xb1/0x230 net/core/dst.c:466
 notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
 __raw_notifier_call_chain kernel/notifier.c:394 [inline]
 raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
 call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
 call_netdevice_notifiers net/core/dev.c:1665 [inline]
 __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
 dev_change_flags+0xf5/0x140 net/core/dev.c:6671
 dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
 dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:913
 sock_ioctl+0x28f/0x440 net/socket.c:1004
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446179
RSP: 002b:7fd1da4bdc08 EFLAGS: 0282 ORIG_RAX: 0010
RAX: ffda RBX: 3220 RCX: 00446179
RDX: 20d34000 RSI: 8914 RDI: 0005
RBP:  R08:  R09: 
R10:  R11: 0282 R12: 0005
R13: 0390 R14: 006e1450 R15: 

Allocated by task 23235:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
 slab_post_alloc_hook mm/slab.h:456 [inline]
 slab_alloc_node mm/slub.c:2718 [inline]
 __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303
 __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138
 __alloc_skb+0x157/0x770 net/core/skbuff.c:231
 alloc_skb include/linux/skbuff.h:936 [inline]
 alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690
 sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000
 tun_alloc_skb drivers/net/tun.c:1144 [inline]
 tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274
 tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
 call_write_iter include/linux/fs.h:1734 [inline]
 new_sync_write fs/read_write.c:497 [inline]
 __vfs_write+0x483/0x760 fs/read_write.c:510
 vfs_write+0x187/0x500 fs/read_write.c:558
 SYSC_write fs/read_write.c:605 [inline]
 SyS_write+0xfb/0x230 fs/read_write.c:597
 entry_SYSCALL_64_fastpath+0x1f/0xbe

Freed by task 23235:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 skb_free_head+0x74/0xb0 net/core/skbuff.c:579
 skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610
 skb_release_all+0x4a/0x60 net/core/skbuff.c:669
 __kfree_skb+0x15/0x20 net/core/skbuff.c:683
 kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704
 llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214
 __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216
 __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254
 netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416
 netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440
 tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167
 tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339
 tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
 call_write_iter include/linux/fs.h:1734 [inline]
 new_sync_write fs/read_write.c:497 [inline]
 __vfs_write+0x483/0x760 fs/read_write.c:510
 vfs_write+0x187/0x500 fs/read_write.c:558
 SYSC_write fs/read_write.c:605 [inline]
 SyS_write+0xfb/0x230 fs/read_write.c:597
 entry_SYSCALL_64_fastpath+0x1f/0xbe

The buggy address belongs to the object at 88006afa4ad8
 which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 0 bytes inside of
 1024-byte region [88006afa4ad8, 88006afa4ed8)
The buggy address belongs to the page:
page:ea0001abe800 count:1 mapcount:0 mapping:  (null)
index:0x0 compound_mapcount: 0
flags

net/ipv4: use-after-free in add_grec

2017-05-31 Thread Andrey Konovalov
Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
Read of size 8 at addr 88003053c1a0 by task swapper/0/0

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x73/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x22b/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
 add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
 igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
 igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
IPVS: length: 51 != 8
 call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
 expire_timers kernel/time/timer.c:1307 [inline]
 __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
 run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
 __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364 [inline]
 irq_exit+0x19e/0x1d0 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:652 [inline]
 smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
 apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
RSP: 0018:85a079a8 EFLAGS: 0282 ORIG_RAX: ff10
RAX: dc20 RBX: 10b40f38 RCX: 
RDX:  RSI: 0001 RDI: 85a2a9e4
RBP: 85a079a8 R08:  R09: 
R10:  R11:  R12: dc00
R13: 85a07a60 R14: 86171338 R15: 10b40f5b
 
 arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
 default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
 arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
 default_idle_call+0x36/0x60 kernel/sched/idle.c:98
 cpuidle_idle_call kernel/sched/idle.c:156 [inline]
 do_idle+0x348/0x420 kernel/sched/idle.c:245
 cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
 rest_init+0x18d/0x1a0 init/main.c:415
 start_kernel+0x747/0x779 init/main.c:679
 x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
 x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
 secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304

Allocated by task 30543:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
 kmalloc include/linux/slab.h:492 [inline]
 kzalloc include/linux/slab.h:665 [inline]
 ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
 ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
 ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
 do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
 ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
 tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
 SYSC_setsockopt net/socket.c:1798 [inline]
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xbe

Freed by task 30543:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
 ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
 ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
 inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
 sock_release+0x8d/0x1e0 net/socket.c:597
 sock_close+0x16/0x20 net/socket.c:1072
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18a3/0x2820 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x76d/0x1790 kernel/signal.c:2318
 do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x17a/0x210 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
 entry_SYSCALL_64_fastpath+0xbc/0xbe

The buggy address belongs to the object at 88003053c1a0
 which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
 64-byte region [88003053c1a0, 88003053c1e0)
The buggy address belongs to the page:
page:f

[PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
  b43legacy_synchronize_irq
synchronize_irq --> may sleep

To fix it, the lock is released before b43legacy_synchronize_irq, and the 
lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
b/drivers/net/wireless/broadcom/b43legacy/main.c
index f1e3dad..31ead21 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
ieee80211_hw *hw,
b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
 
if (changed & BSS_CHANGED_BSSID) {
+   spin_unlock_irqrestore(&wl->irq_lock, flags);
b43legacy_synchronize_irq(dev);
+   spin_lock_irqsave(&wl->irq_lock, flags);
 
if (conf->bssid)
memcpy(wl->bssid, conf->bssid, ETH_ALEN);
-- 
1.7.9.5




Re: [PATCH net-next] powerpc: use asm-generic/socket.h as much as possible

2017-05-31 Thread Michael Ellerman
Stephen Rothwell  writes:

> asm-generic/socket.h already has an exception for the differences that
> powerpc needs, so just include it after defining the differences.
>
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/include/uapi/asm/socket.h | 92 
> +-
>  1 file changed, 1 insertion(+), 91 deletions(-)
>
> Build tested using powerpc allyesconfig, pseries_le_defconfig, 32 bit
> and 64 bit allnoconfig and ppc44x_defconfig builds.

Did you boot it and test that userspace was happy doing sockety things?

cheers


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Kalle Valo
Jia-Ju Bai  writes:

> The driver may sleep under a spin lock, and the function call path is:
> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
>   b43legacy_synchronize_irq
> synchronize_irq --> may sleep
>
> To fix it, the lock is released before b43legacy_synchronize_irq, and the 
> lock is acquired again after this function.
>
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
> b/drivers/net/wireless/broadcom/b43legacy/main.c
> index f1e3dad..31ead21 100644
> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> ieee80211_hw *hw,
>   b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>  
>   if (changed & BSS_CHANGED_BSSID) {
> + spin_unlock_irqrestore(&wl->irq_lock, flags);
>   b43legacy_synchronize_irq(dev);
> + spin_lock_irqsave(&wl->irq_lock, flags);

To me this looks like a fragile workaround and not a real fix. You can
easily add new race conditions with releasing the lock like this.

-- 
Kalle Valo


[PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave)
  b43legacy_radio_set_interference_mitigation
b43legacy_radio_interference_mitigation_disable
  b43legacy_calc_nrssi_slope
b43legacy_synth_pu_workaround
  might_sleep and msleep --> may sleep

Fixing it may be complex, and a possible way is to remove 
spin_lock_irqsave and spin_lock_irqrestore in 
b43legacy_attr_interfmode_store, and the code has been protected by
mutex_lock and mutex_unlock.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/broadcom/b43legacy/sysfs.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43legacy/sysfs.c 
b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
index 2a1da15..9ede143 100644
--- a/drivers/net/wireless/broadcom/b43legacy/sysfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
@@ -137,14 +137,12 @@ static ssize_t b43legacy_attr_interfmode_store(struct 
device *dev,
}
 
mutex_lock(&wldev->wl->mutex);
-   spin_lock_irqsave(&wldev->wl->irq_lock, flags);
 
err = b43legacy_radio_set_interference_mitigation(wldev, mode);
if (err)
b43legacyerr(wldev->wl, "Interference Mitigation not "
   "supported by device\n");
mmiowb();
-   spin_unlock_irqrestore(&wldev->wl->irq_lock, flags);
mutex_unlock(&wldev->wl->mutex);
 
return err ? err : count;
-- 
1.7.9.5




[PATCH v2 net 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume

2017-05-31 Thread Leonard Crestez
These bits seem to be lost after a suspend/resume cycle so just set them
again. Do this by splitting the handling of these bits into a function
that is also called on resume.

This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.

Signed-off-by: Leonard Crestez 
---
 drivers/net/phy/micrel.c | 42 --
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6a5fd18..b9252b8d8 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -268,23 +268,12 @@ static int kszphy_nand_tree_disable(struct phy_device 
*phydev)
return ret;
 }
 
-static int kszphy_config_init(struct phy_device *phydev)
+/* Some config bits need to be set again on resume, handle them here. */
+static int kszphy_config_reset(struct phy_device *phydev)
 {
struct kszphy_priv *priv = phydev->priv;
-   const struct kszphy_type *type;
int ret;
 
-   if (!priv)
-   return 0;
-
-   type = priv->type;
-
-   if (type->has_broadcast_disable)
-   kszphy_broadcast_disable(phydev);
-
-   if (type->has_nand_tree_disable)
-   kszphy_nand_tree_disable(phydev);
-
if (priv->rmii_ref_clk_sel) {
ret = kszphy_rmii_clk_sel(phydev, priv->rmii_ref_clk_sel_val);
if (ret) {
@@ -295,11 +284,30 @@ static int kszphy_config_init(struct phy_device *phydev)
}
 
if (priv->led_mode >= 0)
-   kszphy_setup_led(phydev, type->led_mode_reg, priv->led_mode);
+   kszphy_setup_led(phydev, priv->type->led_mode_reg, 
priv->led_mode);
 
return 0;
 }
 
+static int kszphy_config_init(struct phy_device *phydev)
+{
+   struct kszphy_priv *priv = phydev->priv;
+   const struct kszphy_type *type;
+
+   if (!priv)
+   return 0;
+
+   type = priv->type;
+
+   if (type->has_broadcast_disable)
+   kszphy_broadcast_disable(phydev);
+
+   if (type->has_nand_tree_disable)
+   kszphy_nand_tree_disable(phydev);
+
+   return kszphy_config_reset(phydev);
+}
+
 static int ksz8041_config_init(struct phy_device *phydev)
 {
struct device_node *of_node = phydev->mdio.dev.of_node;
@@ -700,8 +708,14 @@ static int kszphy_suspend(struct phy_device *phydev)
 
 static int kszphy_resume(struct phy_device *phydev)
 {
+   int ret;
+
genphy_resume(phydev);
 
+   ret = kszphy_config_reset(phydev);
+   if (ret)
+   return ret;
+
/* Enable PHY Interrupts */
if (phy_interrupt_is_valid(phydev)) {
phydev->interrupts = PHY_INTERRUPT_ENABLED;
-- 
2.7.4



  1   2   3   >