* [PATCH v8 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
From: Dexuan Cui @ 2016-04-08 1:36 UTC (permalink / raw)
To: gregkh, davem, netdev, linux-kernel, devel, olaf, apw, jasowang,
cavery, kys, haiyangz
Cc: joe
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.
With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.
Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service
The patch implements the necessary support in the guest side by
introducing a new socket address family AF_HYPERV.
Note: the VMBus driver side's supporting patches have been in the mainline
tree.
I know the kernel has already had a VM Sockets driver (AF_VSOCK) based
on VMware VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is
proposing AF_VSOCK of virtio version:
http://marc.info/?l=linux-netdev&m=145952064004765&w=2
However, though Hyper-V Sockets may seem conceptually similar to
AF_VOSCK, there are differences in the transportation layer, and IMO these
make the direct code reusing impractical:
1. In AF_VSOCK, the endpoint type is: <u32 ContextID, u32 Port>, but in
AF_HYPERV, the endpoint type is: <GUID VM_ID, GUID ServiceID>. Here GUID
is 128-bit.
2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't.
3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE,
SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT.
These are meaningless to AF_HYPERV.
4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus,
like .notify_recv_init
.notify_recv_pre_block
.notify_recv_pre_dequeue
.notify_recv_post_dequeue
.notify_send_init
.notify_send_pre_block
.notify_send_pre_enqueue
.notify_send_post_enqueue
etc.
So I think we'd better introduce a new address family: AF_HYPERV.
Please review the patch.
Looking forward to your comments!
Changes since v1:
- updated "[PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature"
- added __init and __exit for the module init/exit functions
- net/hv_sock/Kconfig: "default m" -> "default m if HYPERV"
- MODULE_LICENSE: "Dual MIT/GPL" -> "Dual BSD/GPL"
Changes since v2:
- fixed various coding issue pointed out by David Miller
- fixed indentation issues
- removed pr_debug in net/hv_sock/af_hvsock.c
- used reverse-Chrismas-tree style for local variables.
- EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL
Changes since v3:
- fixed a few coding issue pointed by Vitaly Kuznetsov and Dan Carpenter
- fixed the ret value in vmbus_recvpacket_hvsock on error
- fixed the style of multi-line comment: vmbus_get_hvsock_rw_status()
Changes since v4 (https://lkml.org/lkml/2015/7/28/404):
- addressed all the comments about V4.
- treat the hvsock offers/channels as special VMBus devices
- add a mechanism to pass hvsock events to the hvsock driver
- fixed some corner cases with proper locking when a connection is closed
- rebased to the latest Greg's tree
Changes since v5 (https://lkml.org/lkml/2015/12/24/103):
- addressed the coding style issues (Vitaly Kuznetsov & David Miller, thanks!)
- used a better coding for the per-channel rescind callback (Thank Vitaly!)
- avoided the introduction of new VMBUS driver APIs vmbus_sendpacket_hvsock()
and vmbus_recvpacket_hvsock() and used vmbus_sendpacket()/vmbus_recvpacket()
in the higher level (i.e., the vmsock driver). Thank Vitaly!
Changes since v6 (http://lkml.iu.edu/hypermail/linux/kernel/1601.3/01813.html)
- only a few minor changes of coding style and comments
Changes since v7
- a few minor changes of coding style: thanks, Joe Perches!
- added some lines of comments about GUID/UUID before the struct sockaddr_hv.
Dexuan Cui (1):
hv_sock: introduce Hyper-V Sockets
MAINTAINERS | 2 +
include/linux/hyperv.h | 16 +
include/linux/socket.h | 5 +-
include/net/af_hvsock.h | 51 ++
include/uapi/linux/hyperv.h | 25 +
net/Kconfig | 1 +
net/Makefile | 1 +
net/hv_sock/Kconfig | 10 +
net/hv_sock/Makefile | 3 +
net/hv_sock/af_hvsock.c | 1483 +++++++++++++++++++++++++++++++++++++++++++
10 files changed, 1595 insertions(+), 2 deletions(-)
create mode 100644 include/net/af_hvsock.h
create mode 100644 net/hv_sock/Kconfig
create mode 100644 net/hv_sock/Makefile
create mode 100644 net/hv_sock/af_hvsock.c
--
2.1.0
^ permalink raw reply
* Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
From: Joe Perches @ 2016-04-08 1:15 UTC (permalink / raw)
To: Dexuan Cui, gregkh, davem, netdev, linux-kernel, devel, olaf, apw,
jasowang, cavery, kys, haiyangz
Cc: vkuznets
In-Reply-To: <1460079411-31982-1-git-send-email-decui@microsoft.com>
On Thu, 2016-04-07 at 18:36 -0700, Dexuan Cui wrote:
> Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
> mechanism between the host and the guest. It's somewhat like TCP over
> VMBus, but the transportation layer (VMBus) is much simpler than IP.
[]
> diff --git a/include/net/af_hvsock.h b/include/net/af_hvsock.h
[]
> +#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE)
> +#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (5 * PAGE_SIZE)
> +
> +#define HVSOCK_RCV_BUF_SZ VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV
> +#define HVSOCK_SND_BUF_SZ PAGE_SIZE
[]
> +struct hvsock_sock {
[]
> + struct {
> + struct vmpipe_proto_header hdr;
> + char buf[HVSOCK_SND_BUF_SZ];
> + } __packed send;
> +
> + struct {
> + struct vmpipe_proto_header hdr;
> + char buf[HVSOCK_RCV_BUF_SZ];
> + unsigned int data_len;
> + unsigned int data_offset;
> + } __packed recv;
> +};
These bufs are not page aligned and so can span pages.
Is there any value in allocating these bufs separately
as pages instead of as a kmalloc?
^ permalink raw reply
* [PATCH net-next] macvlan: Set nocarrier when lowerdev admin down
From: Debabrata Banerjee @ 2016-04-08 1:06 UTC (permalink / raw)
To: Nikolay Aleksandrov, Patrick McHardy, netdev; +Cc: Debabrata Banerjee
In-Reply-To: <57063EDD.3040406@cumulusnetworks.com>
When the lowerdev is set administratively down disable carrier on the
macvlan interface. This means operstate gets set properly instead of
still being "up".
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
drivers/net/macvlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..16d0e56 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1525,10 +1525,14 @@ static int macvlan_device_event(struct notifier_block *unused,
switch (event) {
case NETDEV_UP:
+ case NETDEV_DOWN:
case NETDEV_CHANGE:
- list_for_each_entry(vlan, &port->vlans, list)
+ list_for_each_entry(vlan, &port->vlans, list) {
netif_stacked_transfer_operstate(vlan->lowerdev,
vlan->dev);
+ if (!(vlan->lowerdev->flags & IFF_UP))
+ netif_carrier_off(vlan->dev);
+ }
break;
case NETDEV_FEAT_CHANGE:
list_for_each_entry(vlan, &port->vlans, list) {
--
2.8.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 00/10] allow bpf attach to tracepoints
From: David Miller @ 2016-04-08 1:04 UTC (permalink / raw)
To: ast
Cc: rostedt, peterz, mingo, daniel, acme, wangnan0, jbacik,
brendan.d.gregg, netdev, linux-kernel, kernel-team
In-Reply-To: <1459993411-2754735-1-git-send-email-ast@fb.com>
Series applied, thanks Alexei.
^ permalink raw reply
* Re: [PATCH net-next v2] macvlan: Support interface operstate properly
From: Banerjee, Debabrata @ 2016-04-08 1:03 UTC (permalink / raw)
To: Nikolay Aleksandrov, Patrick McHardy, netdev@vger.kernel.org
In-Reply-To: <57063EDD.3040406@cumulusnetworks.com>
On 4/7/16, 7:05 AM, "Nikolay Aleksandrov" <nikolay@cumulusnetworks.com> wrote:
>On 04/07/2016 12:36 AM, Debabrata Banerjee wrote:
>> Set appropriate macvlan interface status based on lower device and our
>> status. Can be up, down, or lowerlayerdown.
>What about dormant ?
>
>That being said I understand the need to switch to lowerlayerdown when the lower
>device is in "down", which is basically the most important change of this patch.
>The rest is already handled by link watch based on carrier state. By now people
>are used to having lowerlayerdown when there's no carrier, now it can also mean
>that the lower device has been brought admin down.
>
>Here's another interesting state:
>6: mac1@eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP,DORMANT,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
>Prior to this patch the macvlan would stay in dormant state and it will also propagate
>to devices stacked on top of it.
The no carrier issue gave me an idea. What if we just set no carrier on the macvlan device?
This seems appropriate, but it doesn't directly address the dormant issue, although that could
be a separate patch. Will this cause any new issues? It's very simple, new patch incoming.
^ permalink raw reply
* Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver
From: Andrew Lunn @ 2016-04-08 0:53 UTC (permalink / raw)
To: Timur Tabi
Cc: Rob Herring, Gilad Avidov, netdev, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-msm, Sagar Dharia, shankerd,
Greg Kroah-Hartman, vikrams, Christopher Covington
In-Reply-To: <5706D493.8020700@codeaurora.org>
On Thu, Apr 07, 2016 at 04:43:47PM -0500, Timur Tabi wrote:
> On my platform, firmware (UEFI) configures all of the GPIOs. I need
> to get confirmation, but it appears that we don't actually make any
> GPIO calls at all. I see code that looks like this:
>
> for (i = 0; (!adpt->no_mdio_gpio) && i < EMAC_NUM_GPIO; i++) {
> gpio_info = &adpt->gpio_info[i];
> retval = of_get_named_gpio(node, gpio_info->name, 0);
> if (retval < 0)
> return retval;
>
> And on our ACPI system, adpt->no_mdio_gpio is always true:
>
> /* Assume GPIOs required for MDC/MDIO are enabled in firmware */
> adpt->no_mdio_gpio = true;
There are two different things here. One is configuring the pin to be
a GPIO. The second is using the GPIO as a GPIO. In this case,
bit-banging the MDIO bus.
The firmware could be doing the configuration, setting the pin as a
GPIO. However, the firmware cannot be doing the MDIO bit-banging to
make an MDIO bus available. Linux has to do that.
Or it could be we have all completely misunderstood the hardware, and
we are not doing bit-banging GPIO MDIO. There is a real MDIO
controller there, we don't use these pins as GPIOs, etc....
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2] sock: make lockdep_sock_is_held inline and conditional on LOCKDEP
From: David Miller @ 2016-04-08 0:40 UTC (permalink / raw)
To: hannes; +Cc: netdev, eric.dumazet
In-Reply-To: <1460072118-10006-1-git-send-email-hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 8 Apr 2016 01:35:18 +0200
> lockdep_is_held is only specified if CONFIG_LOCKDEP is defined, so make
> it depending on it.
>
> Also add the missing inline keyword, so no warnings about unused functions
> show up during complilation.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
I already applied your inline patch, I applied the following:
====================
[PATCH] net: Fix build failure due to lockdep_sock_is_held().
Needs to be protected with CONFIG_LOCKDEP.
Based upon a patch by Hannes Frederic Sowa.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/sock.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 46b2937..81d6fec 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1360,6 +1360,7 @@ do { \
lockdep_init_map(&(sk)->sk_lock.dep_map, (name), (key), 0); \
} while (0)
+#ifdef CONFIG_LOCKDEP
static inline bool lockdep_sock_is_held(const struct sock *csk)
{
struct sock *sk = (struct sock *)csk;
@@ -1367,6 +1368,7 @@ static inline bool lockdep_sock_is_held(const struct sock *csk)
return lockdep_is_held(&sk->sk_lock) ||
lockdep_is_held(&sk->sk_lock.slock);
}
+#endif
void lock_sock_nested(struct sock *sk, int subclass);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline
From: David Miller @ 2016-04-07 22:01 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <1460066015-22105-1-git-send-email-hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 7 Apr 2016 23:53:35 +0200
> I forgot to add inline to lockdep_sock_is_held, so it generated all
> kinds of build warnings if not build with lockdep support.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO
From: Alexander Duyck @ 2016-04-07 23:52 UTC (permalink / raw)
To: Jesse Gross
Cc: Alexander Duyck, Herbert Xu, Tom Herbert, Eric Dumazet,
Linux Kernel Network Developers, David Miller
In-Reply-To: <CAEh+42jyh0EWwaOAu3KNSQKEv3NRgjPT_4QRYUmLRSXtsMgWJw@mail.gmail.com>
On Thu, Apr 7, 2016 at 4:22 PM, Jesse Gross <jesse@kernel.org> wrote:
> On Thu, Apr 7, 2016 at 7:32 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
>> This patch adds support for a feature I am calling IP ID mangling. It is
>> basically just another way of saying the IP IDs that are transmitted by the
>> tunnel may not match up with what would normally be expected. Specifically
>> what will happen is in the case of TSO the IP IDs on the headers will be a
>> fixed value so a given TSO will repeat the same inner IP ID value gso_segs
>> number of times.
>>
>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>
> If I'm understanding this correctly, enabling IP ID mangling will help
> performance on ixgbe since it will allow it to do GSO partial instead
> of plain GSO but it will hurt performance on i40e since it will drop
> from TSO to plain GSO.
Right. However the option is currently defaulted to off, and can be
enabled per tunnel endpoint. So if you had an ixgbe to i40e link you
could enable it on the end with the ixgbe and you should see good
performance in both directions.
> Assuming that's right, it seems like it will make it hard to chose the
> right setting without knowledge of which hardware is in use. I guess
> what we really want is "I care about nicely incrementing IP IDs" vs.
> "I don't care as long as the DF bit is set". That second case is
> really what this flag is trying to say but it seems like it is
> enforcing too much in the i40e case - I don't think anyone wants to go
> out of their way to make IP IDs jump around if incrementing is faster.
Right. The problem is trying to sort out all the GRO/GSO bits. I was
probably being a bit too conservative after the last few iterations
for the GRO fixes.
Just a thought. What if I replaced NETIF_F_TSO_FIXEDID with something
that meant we could mange the IP ID like a NETIF_F_TSO_IPID_MANGLE
(advice for better name welcome). Instead of the feature flag meaning
we are going to transmit packets with a fixed ID it would mean we
don't care about the ID and are free to mangle it as we see fit. The
GSO type can retain the same meaning as far as that requiring the same
ID for all, but the feature would mean we will take fixed and convert
it to incrementing, or incrementing and convert it to fixed.
- Alex
^ permalink raw reply
* [PATCH net-next v2] sock: make lockdep_sock_is_held inline and conditional on LOCKDEP
From: Hannes Frederic Sowa @ 2016-04-07 23:35 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, David Miller
In-Reply-To: <1460066015-22105-1-git-send-email-hannes@stressinduktion.org>
lockdep_is_held is only specified if CONFIG_LOCKDEP is defined, so make
it depending on it.
Also add the missing inline keyword, so no warnings about unused functions
show up during complilation.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/sock.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index eb2d7c3e120b25..81d6fecec0a2c0 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1360,13 +1360,15 @@ do { \
lockdep_init_map(&(sk)->sk_lock.dep_map, (name), (key), 0); \
} while (0)
-static bool lockdep_sock_is_held(const struct sock *csk)
+#ifdef CONFIG_LOCKDEP
+static inline bool lockdep_sock_is_held(const struct sock *csk)
{
struct sock *sk = (struct sock *)csk;
return lockdep_is_held(&sk->sk_lock) ||
lockdep_is_held(&sk->sk_lock.slock);
}
+#endif
void lock_sock_nested(struct sock *sk, int subclass);
--
2.5.5
^ permalink raw reply related
* Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO
From: Jesse Gross @ 2016-04-07 23:22 UTC (permalink / raw)
To: Alexander Duyck
Cc: herbert, Tom Herbert, Alexander Duyck, edumazet,
Linux Kernel Network Developers, David Miller
In-Reply-To: <20160407223237.11142.33072.stgit@ahduyck-xeon-server>
On Thu, Apr 7, 2016 at 7:32 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
> This patch adds support for a feature I am calling IP ID mangling. It is
> basically just another way of saying the IP IDs that are transmitted by the
> tunnel may not match up with what would normally be expected. Specifically
> what will happen is in the case of TSO the IP IDs on the headers will be a
> fixed value so a given TSO will repeat the same inner IP ID value gso_segs
> number of times.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
If I'm understanding this correctly, enabling IP ID mangling will help
performance on ixgbe since it will allow it to do GSO partial instead
of plain GSO but it will hurt performance on i40e since it will drop
from TSO to plain GSO.
Assuming that's right, it seems like it will make it hard to chose the
right setting without knowledge of which hardware is in use. I guess
what we really want is "I care about nicely incrementing IP IDs" vs.
"I don't care as long as the DF bit is set". That second case is
really what this flag is trying to say but it seems like it is
enforcing too much in the i40e case - I don't think anyone wants to go
out of their way to make IP IDs jump around if incrementing is faster.
^ permalink raw reply
* Re: [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled
From: Hannes Frederic Sowa @ 2016-04-07 23:21 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Peter Zijlstra, Ingo Molnar, Eric Dumazet, David Miller
In-Reply-To: <1460070722-18652-1-git-send-email-hannes@stressinduktion.org>
On 08.04.2016 01:12, Hannes Frederic Sowa wrote:
> I need this to provide a generic lockdep_sock_is_held function which can
> be easily used in the kernel without using ifdef PROVEN macros.
>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> Hello Peter and Ingo,
>
> if it is possible coud this go in via the net-tree, as this problem is
> visible there already? Would be happy to get a review.
I take this patch back, as some call sites test if the lock is
definitely not held. I come up with a better approach.
^ permalink raw reply
* Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline
From: Hannes Frederic Sowa @ 2016-04-07 23:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1460070528.6473.425.camel@edumazet-glaptop3.roam.corp.google.com>
On 08.04.2016 01:08, Eric Dumazet wrote:
> On Fri, 2016-04-08 at 00:47 +0200, Hannes Frederic Sowa wrote:
>
>> I see... hmpf.
>>
>> Wouldn't it be nicer if I include a helper a la:
>>
>> #define lockdep_is_held(lock) 1
>>
>> in lockdep.h in case lockdep is globally not enabled? I do actually have
>> already another user for this outside of PROVE_RCU.
>
> It probably had been discussed on lkml a long time ago.
>
> My guess is that you can not do that, but am too lazy to tell you why ;)
I will simply try it and otherwise go with your solution. My other cases
would need to be ifdefed then as well, but also possible.
Patch is send out and I will now research after your tip that it was
already tried.
Thanks,
Hannes
^ permalink raw reply
* [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled
From: Hannes Frederic Sowa @ 2016-04-07 23:12 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Peter Zijlstra, Ingo Molnar, Eric Dumazet, David Miller
I need this to provide a generic lockdep_sock_is_held function which can
be easily used in the kernel without using ifdef PROVEN macros.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
Hello Peter and Ingo,
if it is possible coud this go in via the net-tree, as this problem is
visible there already? Would be happy to get a review.
Thanks,
Hannes
include/linux/lockdep.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index d026b190c53066..dc8d447cb3ab1c 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -428,6 +428,8 @@ struct lock_class_key { };
#define lockdep_pin_lock(l) do { (void)(l); } while (0)
#define lockdep_unpin_lock(l) do { (void)(l); } while (0)
+#define lockdep_is_held(l) ({ (void)(l); (1); })
+
#endif /* !LOCKDEP */
#ifdef CONFIG_LOCK_STAT
--
2.5.5
^ permalink raw reply related
* [PATCH ipoute2] iplink: display number of rx/tx queues
From: Eric Dumazet @ 2016-04-07 23:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
We can set the attributes, so would be nice to display them when
provided by the kernel.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 3998d8c..f7bd1c7 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -894,6 +894,12 @@ int print_linkinfo(const struct sockaddr_nl *who,
if (do_link && tb[IFLA_AF_SPEC] && show_details)
print_af_spec(fp, tb[IFLA_AF_SPEC]);
+ if (tb[IFLA_NUM_TX_QUEUES] && show_details)
+ fprintf(fp, "numtxqueues %u ", rta_getattr_u32(tb[IFLA_NUM_TX_QUEUES]));
+
+ if (tb[IFLA_NUM_RX_QUEUES] && show_details)
+ fprintf(fp, "numrxqueues %u ", rta_getattr_u32(tb[IFLA_NUM_RX_QUEUES]));
+
if ((do_link || show_details) && tb[IFLA_IFALIAS]) {
fprintf(fp, "%s alias %s", _SL_,
rta_getattr_str(tb[IFLA_IFALIAS]));
^ permalink raw reply related
* Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline
From: Eric Dumazet @ 2016-04-07 23:08 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <5706E39D.3060206@stressinduktion.org>
On Fri, 2016-04-08 at 00:47 +0200, Hannes Frederic Sowa wrote:
> I see... hmpf.
>
> Wouldn't it be nicer if I include a helper a la:
>
> #define lockdep_is_held(lock) 1
>
> in lockdep.h in case lockdep is globally not enabled? I do actually have
> already another user for this outside of PROVE_RCU.
It probably had been discussed on lkml a long time ago.
My guess is that you can not do that, but am too lazy to tell you why ;)
^ permalink raw reply
* [PATCH V3 8/8] net: mediatek: do not set the QID field in the TX DMA descriptors
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
The QID field gets set to the mac id. This made the DMA linked list queue
the traffic of each MAC on a different internal queue. However during long
term testing we found that this will cause traffic stalls as the multi
queue setup requires a more complete initialisation which is not part of
the upstream driver yet.
This patch removes the code setting the QID field, resulting in all
traffic ending up in queue 0 which works without any special setup.
Signed-off-by: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index eb0d554..c984462 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -603,8 +603,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
WRITE_ONCE(txd->txd1, mapped_addr);
WRITE_ONCE(txd->txd3, (TX_DMA_SWC |
TX_DMA_PLEN0(frag_map_size) |
- last_frag * TX_DMA_LS0) |
- mac->id);
+ last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, 0);
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 7/8] net: mediatek: move the pending_work struct to the device generic struct
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, Matthias Brugger,
Sean Wang (王志亘), netdev, linux-mediatek,
linux-kernel, John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic@openwrt.org>
The worker always touches both netdevs. It is ethernet core and not MAC
specific. We only need one worker, which belongs into the ethernets core
struct.
Signed-off-by: John Crispin <blogic@openwrt.org>
---
Changes in V3
* make the patch bisectable
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 13 +++++--------
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 4 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index cd5d0c9..eb0d554 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1193,7 +1193,7 @@ static void mtk_tx_timeout(struct net_device *dev)
eth->netdev[mac->id]->stats.tx_errors++;
netif_err(eth, tx_err, dev,
"transmit timed out\n");
- schedule_work(&mac->pending_work);
+ schedule_work(ð->pending_work);
}
static irqreturn_t mtk_handle_irq(int irq, void *_eth)
@@ -1430,8 +1430,7 @@ static int mtk_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
static void mtk_pending_work(struct work_struct *work)
{
- struct mtk_mac *mac = container_of(work, struct mtk_mac, pending_work);
- struct mtk_eth *eth = mac->hw;
+ struct mtk_eth *eth = container_of(work, struct mtk_eth, pending_work);
int err, i;
unsigned long restart = 0;
@@ -1439,7 +1438,7 @@ static void mtk_pending_work(struct work_struct *work)
/* stop all devices to make sure that dma is properly shut down */
for (i = 0; i < MTK_MAC_COUNT; i++) {
- if (!netif_oper_up(eth->netdev[i]))
+ if (!eth->netdev[i])
continue;
mtk_stop(eth->netdev[i]);
__set_bit(i, &restart);
@@ -1464,15 +1463,13 @@ static int mtk_cleanup(struct mtk_eth *eth)
int i;
for (i = 0; i < MTK_MAC_COUNT; i++) {
- struct mtk_mac *mac = netdev_priv(eth->netdev[i]);
-
if (!eth->netdev[i])
continue;
unregister_netdev(eth->netdev[i]);
free_netdev(eth->netdev[i]);
- cancel_work_sync(&mac->pending_work);
}
+ cancel_work_sync(ð->pending_work);
return 0;
}
@@ -1660,7 +1657,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
mac->id = id;
mac->hw = eth;
mac->of_node = np;
- INIT_WORK(&mac->pending_work, mtk_pending_work);
mac->hw_stats = devm_kzalloc(eth->dev,
sizeof(*mac->hw_stats),
@@ -1762,6 +1758,7 @@ static int mtk_probe(struct platform_device *pdev)
eth->dev = &pdev->dev;
eth->msg_enable = netif_msg_init(mtk_msg_level, MTK_DEFAULT_MSG_ENABLE);
+ INIT_WORK(ð->pending_work, mtk_pending_work);
err = mtk_hw_init(eth);
if (err)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 48a5292..eed626d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -363,6 +363,7 @@ struct mtk_rx_ring {
* @clk_gp1: The gmac1 clock
* @clk_gp2: The gmac2 clock
* @mii_bus: If there is a bus we need to create an instance for it
+ * @pending_work: The workqueue used to reset the dma ring
*/
struct mtk_eth {
@@ -389,6 +390,7 @@ struct mtk_eth {
struct clk *clk_gp1;
struct clk *clk_gp2;
struct mii_bus *mii_bus;
+ struct work_struct pending_work;
};
/* struct mtk_mac - the structure that holds the info about the MACs of the
@@ -398,7 +400,6 @@ struct mtk_eth {
* @hw: Backpointer to our main datastruture
* @hw_stats: Packet statistics counter
* @phy_dev: The attached PHY if available
- * @pending_work: The workqueue used to reset the dma ring
*/
struct mtk_mac {
int id;
@@ -406,7 +407,6 @@ struct mtk_mac {
struct mtk_eth *hw;
struct mtk_hw_stats *hw_stats;
struct phy_device *phy_dev;
- struct work_struct pending_work;
};
/* the struct describing the SoC. these are declared in the soc_xyz.c files */
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 6/8] net: mediatek: fix mtk_pending_work
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
The driver supports 2 MACs. Both run on the same DMA ring. If we hit a TX
timeout we need to stop both netdevs before restarting them again. If we
don't do this, mtk_stop() wont shutdown DMA and the consecutive call to
mtk_open() wont restart DMA and enable IRQs.
Signed-off-by: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
Changes in V3
* make the patch bisectable
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 28 +++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7b76075..cd5d0c9 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1432,17 +1432,29 @@ static void mtk_pending_work(struct work_struct *work)
{
struct mtk_mac *mac = container_of(work, struct mtk_mac, pending_work);
struct mtk_eth *eth = mac->hw;
- struct net_device *dev = eth->netdev[mac->id];
- int err;
+ int err, i;
+ unsigned long restart = 0;
rtnl_lock();
- mtk_stop(dev);
- err = mtk_open(dev);
- if (err) {
- netif_alert(eth, ifup, dev,
- "Driver up/down cycle failed, closing device.\n");
- dev_close(dev);
+ /* stop all devices to make sure that dma is properly shut down */
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!netif_oper_up(eth->netdev[i]))
+ continue;
+ mtk_stop(eth->netdev[i]);
+ __set_bit(i, &restart);
+ }
+
+ /* restart DMA and enable IRQs */
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!test_bit(i, &restart))
+ continue;
+ err = mtk_open(eth->netdev[i]);
+ if (err) {
+ netif_alert(eth, ifup, eth->netdev[i],
+ "Driver up/down cycle failed, closing device.\n");
+ dev_close(eth->netdev[i]);
+ }
}
rtnl_unlock();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 5/8] net: mediatek: fix TX locking
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, Matthias Brugger,
Sean Wang (王志亘), netdev, linux-mediatek,
linux-kernel, John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic@openwrt.org>
Inside the TX path there is a lock inside the tx_map function. This is
however too late. The patch moves the lock to the start of the xmit
function right before the free count check of the DMA ring happens.
If we do not do this, the code becomes racy leading to TX stalls and
dropped packets. This happens as there are 2 netdevs running on the
same physical DMA ring.
Signed-off-by: John Crispin <blogic@openwrt.org>
---
Changes in V3
* fix a typo in the comment
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4ebc42e..7b76075 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -536,7 +536,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
struct mtk_tx_buf *tx_buf;
- unsigned long flags;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -568,11 +567,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
if (unlikely(dma_mapping_error(&dev->dev, mapped_addr)))
return -ENOMEM;
- /* normally we can rely on the stack not calling this more than once,
- * however we have 2 queues running ont he same ring so we need to lock
- * the ring access
- */
- spin_lock_irqsave(ð->page_lock, flags);
WRITE_ONCE(itxd->txd1, mapped_addr);
tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
@@ -632,8 +626,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
(!nr_frags * TX_DMA_LS0)));
- spin_unlock_irqrestore(ð->page_lock, flags);
-
netdev_sent_queue(dev, skb->len);
skb_tx_timestamp(skb);
@@ -661,8 +653,6 @@ err_dma:
itxd = mtk_qdma_phys_to_virt(ring, itxd->txd2);
} while (itxd != txd);
- spin_unlock_irqrestore(ð->page_lock, flags);
-
return -ENOMEM;
}
@@ -712,14 +702,22 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct mtk_eth *eth = mac->hw;
struct mtk_tx_ring *ring = ð->tx_ring;
struct net_device_stats *stats = &dev->stats;
+ unsigned long flags;
bool gso = false;
int tx_num;
+ /* normally we can rely on the stack not calling this more than once,
+ * however we have 2 queues running on the same ring so we need to lock
+ * the ring access
+ */
+ spin_lock_irqsave(ð->page_lock, flags);
+
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(&ring->free_count) <= tx_num)) {
mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
"Tx Ring full when queue awake!\n");
+ spin_unlock_irqrestore(ð->page_lock, flags);
return NETDEV_TX_BUSY;
}
@@ -747,10 +745,12 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
ring->thresh))
mtk_wake_queue(eth);
}
+ spin_unlock_irqrestore(ð->page_lock, flags);
return NETDEV_TX_OK;
drop:
+ spin_unlock_irqrestore(ð->page_lock, flags);
stats->tx_dropped++;
dev_kfree_skb(skb);
return NETDEV_TX_OK;
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 4/8] net: mediatek: fix stop and wakeup of queue
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
The driver supports 2 MACs. Both run on the same DMA ring. If we go
above/below the TX rings threshold value, we always need to wake/stop
the queue of both devices. Not doing to can cause TX stalls and packet
drops on one of the devices.
Signed-off-by: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 37 +++++++++++++++++++--------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a4982e4..4ebc42e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -684,6 +684,28 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
return nfrags;
}
+static void mtk_wake_queue(struct mtk_eth *eth)
+{
+ int i;
+
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!eth->netdev[i])
+ continue;
+ netif_wake_queue(eth->netdev[i]);
+ }
+}
+
+static void mtk_stop_queue(struct mtk_eth *eth)
+{
+ int i;
+
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!eth->netdev[i])
+ continue;
+ netif_stop_queue(eth->netdev[i]);
+ }
+}
+
static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mtk_mac *mac = netdev_priv(dev);
@@ -695,7 +717,7 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(&ring->free_count) <= tx_num)) {
- netif_stop_queue(dev);
+ mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
"Tx Ring full when queue awake!\n");
return NETDEV_TX_BUSY;
@@ -720,10 +742,10 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
if (unlikely(atomic_read(&ring->free_count) <= ring->thresh)) {
- netif_stop_queue(dev);
+ mtk_stop_queue(eth);
if (unlikely(atomic_read(&ring->free_count) >
ring->thresh))
- netif_wake_queue(dev);
+ mtk_wake_queue(eth);
}
return NETDEV_TX_OK;
@@ -897,13 +919,8 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, bool *tx_again)
if (!total)
return 0;
- for (i = 0; i < MTK_MAC_COUNT; i++) {
- if (!eth->netdev[i] ||
- unlikely(!netif_queue_stopped(eth->netdev[i])))
- continue;
- if (atomic_read(&ring->free_count) > ring->thresh)
- netif_wake_queue(eth->netdev[i]);
- }
+ if (atomic_read(&ring->free_count) > ring->thresh)
+ mtk_wake_queue(eth);
return total;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 2/8] net: mediatek: mtk_cal_txd_req() returns bad value
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
The code used to also support the PDMA engine, which had 2 packet pointers
per descriptor. Because of this we had to divide the result by 2 and round
it up. This is no longer needed as the code only supports QDMA.
Signed-off-by: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bb10d57..94cceb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -681,7 +681,7 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
nfrags += skb_shinfo(skb)->nr_frags;
}
- return DIV_ROUND_UP(nfrags, 2);
+ return nfrags;
}
static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 1/8] net: mediatek: watchdog_timeo was not set
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
In-Reply-To: <1460069651-1234-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
The original commit failed to set watchdog_timeo. This patch sets
watchdog_timeo to HZ.
Signed-off-by: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e0b68af..bb10d57 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1645,6 +1645,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
mac->hw_stats->reg_offset = id * MTK_STAT_OFFSET;
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
+ eth->netdev[id]->watchdog_timeo = HZ;
eth->netdev[id]->netdev_ops = &mtk_netdev_ops;
eth->netdev[id]->base_addr = (unsigned long)eth->base;
eth->netdev[id]->vlan_features = MTK_HW_FEATURES &
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 0/8] net: mediatek: make the driver pass stress tests
From: John Crispin @ 2016-04-07 22:54 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang (王志亘),
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
John Crispin
While testing the driver we managed to get the TX path to stall and fail
to recover. When dual MAC support was added to the driver, the whole queue
stop/wake code was not properly adapted. There was also a regression in the
locking of the xmit function. The fact that watchdog_timeo was not set and
that the tx_timeout code failed to properly reset the dma, irq and queue
just made the mess complete.
This series make the driver pass stress testing. With this series applied
the testbed has been running for several days and still has not locked up.
We have a second setup that has a small hack patch applied to randomly stop
irqs and/or one of the queues and successfully manages to recover from these
simulated tx stalls.
John Crispin (8):
net: mediatek: watchdog_timeo was not set
net: mediatek: mtk_cal_txd_req() returns bad value
net: mediatek: remove superfluous reset call
net: mediatek: fix stop and wakeup of queue
net: mediatek: fix TX locking
net: mediatek: fix mtk_pending_work
net: mediatek: move the pending_work struct to the device generic
struct
net: mediatek: do not set the QID field in the TX DMA descriptors
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 106 ++++++++++++++++-----------
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 4 +-
2 files changed, 66 insertions(+), 44 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline
From: Hannes Frederic Sowa @ 2016-04-07 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1460068652.6473.423.camel@edumazet-glaptop3.roam.corp.google.com>
On 08.04.2016 00:37, Eric Dumazet wrote:
> On Thu, 2016-04-07 at 15:30 -0700, Eric Dumazet wrote:
>
>> But... this wont solve the compiler error ?
>>
>> include/net/sock.h: In function 'lockdep_sock_is_held':
>> include/net/sock.h:1367:2: error: implicit declaration of function
>> 'lockdep_is_held' [-Werror=implicit-function-declaration]
>> In file included from security/lsm_audit.c:20:0:
>> include/net/sock.h: In function 'lockdep_sock_is_held':
>> include/net/sock.h:1367:2: error: implicit declaration of function
>> 'lockdep_is_held' [-Werror=implicit-function-declaration]
>>
>> $ egrep "LOCKDEP|PROVE" .config
>> CONFIG_LOCKDEP_SUPPORT=y
>> # CONFIG_PROVE_LOCKING is not set
>> # CONFIG_PROVE_RCU is not set
>>
>
> Better use something like :
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index eb2d7c3e120b..ab6b6b9469ad 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1360,13 +1360,15 @@ do { \
> lockdep_init_map(&(sk)->sk_lock.dep_map, (name), (key), 0); \
> } while (0)
>
> -static bool lockdep_sock_is_held(const struct sock *csk)
> +#ifdef CONFIG_PROVE_RCU
> +static inline bool lockdep_sock_is_held(const struct sock *csk)
> {
> struct sock *sk = (struct sock *)csk;
>
> return lockdep_is_held(&sk->sk_lock) ||
> lockdep_is_held(&sk->sk_lock.slock);
> }
> +#endif
I see... hmpf.
Wouldn't it be nicer if I include a helper a la:
#define lockdep_is_held(lock) 1
in lockdep.h in case lockdep is globally not enabled? I do actually have
already another user for this outside of PROVE_RCU.
Thanks,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox