* Re: [PATCH] CAIF: fix indentation for function arguments
From: Joe Perches @ 2013-03-07 0:07 UTC (permalink / raw)
To: Silviu-Mihai Popescu; +Cc: netdev, sjur.brandeland, davem, linux-kernel
In-Reply-To: <1362606521-16848-1-git-send-email-silviupopescu1990@gmail.com>
On Wed, 2013-03-06 at 23:48 +0200, Silviu-Mihai Popescu wrote:
> This lines up function arguments on second and subsequent lines at the
> first column after the openning parenthesis of the first line.
[]
> diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
[]
> @@ -301,10 +301,10 @@ static void dev_flowctrl(struct net_device *dev, int on)
> }
>
> void caif_enroll_dev(struct net_device *dev, struct caif_dev_common *caifdev,
> - struct cflayer *link_support, int head_room,
> - struct cflayer **layer, int (**rcv_func)(
> - struct sk_buff *, struct net_device *,
> - struct packet_type *, struct net_device *))
> + struct cflayer *link_support, int head_room,
> + struct cflayer **layer, int (**rcv_func)(
> + struct sk_buff *, struct net_device *,
> + struct packet_type *, struct net_device *))
This makes it seem that caif_enroll_dev takes more args.
I think this style is better (aligned to appropriate open paren)
void caif_enroll_dev(struct net_device *dev, struct caif_dev_common *caifdev,
struct cflayer *link_support, int head_room,
struct cflayer **layer,
int (**rcv_func)(struct sk_buff *, struct net_device *,
struct packet_type *, struct net_device *))
[]
> @@ -301,8 +301,8 @@ static int caif_connect_req_to_link_param(struct cfcnfg *cnfg,
>
> int caif_connect_client(struct net *net, struct caif_connect_request *conn_req,
> struct cflayer *adap_layer, int *ifindex,
> - int *proto_head,
> - int *proto_tail)
> + int *proto_head,
> + int *proto_tail)
You could fill to 80 here.
^ permalink raw reply
* [PATCH] MAINTAINERS: Update qlcnic maintainers list
From: Sony Chacko @ 2013-03-06 23:03 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
From: Sony Chacko <sony.chacko@qlogic.com>
Please apply.
Thanks.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cdb8fe8..0ac189c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6211,6 +6211,8 @@ F: Documentation/networking/LICENSE.qla3xxx
F: drivers/net/ethernet/qlogic/qla3xxx.*
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
+M: Rajesh Borundia <rajesh.borundia@qlogic.com>
+M: Shahed Shaikh <shahed.shaikh@qlogic.com>
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
M: Sony Chacko <sony.chacko@qlogic.com>
M: linux-driver@qlogic.com
--
1.8.0.2
^ permalink raw reply related
* [PATCH net-next] tcp: uninline tcp_prequeue()
From: Eric Dumazet @ 2013-03-06 22:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
tcp_prequeue() became too big to be inlined.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 45 ------------------------------------------
net/ipv4/tcp_ipv4.c | 44 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index cf0694d..a2baa5e 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1030,50 +1030,7 @@ static inline void tcp_prequeue_init(struct tcp_sock *tp)
#endif
}
-/* Packet is added to VJ-style prequeue for processing in process
- * context, if a reader task is waiting. Apparently, this exciting
- * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93)
- * failed somewhere. Latency? Burstiness? Well, at least now we will
- * see, why it failed. 8)8) --ANK
- *
- * NOTE: is this not too big to inline?
- */
-static inline bool tcp_prequeue(struct sock *sk, struct sk_buff *skb)
-{
- struct tcp_sock *tp = tcp_sk(sk);
-
- if (sysctl_tcp_low_latency || !tp->ucopy.task)
- return false;
-
- if (skb->len <= tcp_hdrlen(skb) &&
- skb_queue_len(&tp->ucopy.prequeue) == 0)
- return false;
-
- __skb_queue_tail(&tp->ucopy.prequeue, skb);
- tp->ucopy.memory += skb->truesize;
- if (tp->ucopy.memory > sk->sk_rcvbuf) {
- struct sk_buff *skb1;
-
- BUG_ON(sock_owned_by_user(sk));
-
- while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) {
- sk_backlog_rcv(sk, skb1);
- NET_INC_STATS_BH(sock_net(sk),
- LINUX_MIB_TCPPREQUEUEDROPPED);
- }
-
- tp->ucopy.memory = 0;
- } else if (skb_queue_len(&tp->ucopy.prequeue) == 1) {
- wake_up_interruptible_sync_poll(sk_sleep(sk),
- POLLIN | POLLRDNORM | POLLRDBAND);
- if (!inet_csk_ack_scheduled(sk))
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
- (3 * tcp_rto_min(sk)) / 4,
- TCP_RTO_MAX);
- }
- return true;
-}
-
+extern bool tcp_prequeue(struct sock *sk, struct sk_buff *skb);
#undef STATE_TRACE
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 4a8ec45..8cdee12 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1950,6 +1950,50 @@ void tcp_v4_early_demux(struct sk_buff *skb)
}
}
+/* Packet is added to VJ-style prequeue for processing in process
+ * context, if a reader task is waiting. Apparently, this exciting
+ * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93)
+ * failed somewhere. Latency? Burstiness? Well, at least now we will
+ * see, why it failed. 8)8) --ANK
+ *
+ */
+bool tcp_prequeue(struct sock *sk, struct sk_buff *skb)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ if (sysctl_tcp_low_latency || !tp->ucopy.task)
+ return false;
+
+ if (skb->len <= tcp_hdrlen(skb) &&
+ skb_queue_len(&tp->ucopy.prequeue) == 0)
+ return false;
+
+ __skb_queue_tail(&tp->ucopy.prequeue, skb);
+ tp->ucopy.memory += skb->truesize;
+ if (tp->ucopy.memory > sk->sk_rcvbuf) {
+ struct sk_buff *skb1;
+
+ BUG_ON(sock_owned_by_user(sk));
+
+ while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) {
+ sk_backlog_rcv(sk, skb1);
+ NET_INC_STATS_BH(sock_net(sk),
+ LINUX_MIB_TCPPREQUEUEDROPPED);
+ }
+
+ tp->ucopy.memory = 0;
+ } else if (skb_queue_len(&tp->ucopy.prequeue) == 1) {
+ wake_up_interruptible_sync_poll(sk_sleep(sk),
+ POLLIN | POLLRDNORM | POLLRDBAND);
+ if (!inet_csk_ack_scheduled(sk))
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
+ (3 * tcp_rto_min(sk)) / 4,
+ TCP_RTO_MAX);
+ }
+ return true;
+}
+EXPORT_SYMBOL(tcp_prequeue);
+
/*
* From tcp_input.c
*/
^ permalink raw reply related
* RE: hv_netvsc: WARNING in softirq.c
From: Haiyang Zhang @ 2013-03-06 22:45 UTC (permalink / raw)
To: Richard Genoud
Cc: KY Srinivasan, devel@linuxdriverproject.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACQ1gAgyYp+Dxmk-0C3zfKK+CkEwQX51NvWjzkV7=8GC3CD=Qg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
> -----Original Message-----
> From: Richard Genoud [mailto:richard.genoud@gmail.com]
> Sent: Friday, March 01, 2013 3:39 AM
> To: Haiyang Zhang
> Cc: KY Srinivasan; devel@linuxdriverproject.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: hv_netvsc: WARNING in softirq.c
>
> 2013/2/28 Haiyang Zhang <haiyangz@microsoft.com>:
> > We will look into this. And further info around the time will also be
> helpful.
> >
> > Thanks,
> > - Haiyang
>
> The only thing the admin sys could think about is a rsync process
> between the windows host and ANOTHER linux guest that ends at 22h30
> more or less.
> (the other linux guest is a debian 6, without any HV driver)
I have found a simple way to reproduce this kind of warning:
1) reboot the VM (because this warning can be displayed only once.)
2) login to the host and open the VM [Settings]
3) Temporarily change the Network adapter's option [Virtual Switch] to "Not connected".
4) run dmesg, you should see the warning.
The reason for the warning is -- netif_tx_disable() is called when the NIC
is disconnected. And it's called within irq context. netif_tx_disable()
calls local_bh_enable() which displays warning if in irq.
The fix is to remove the unnecessary netif_tx_disable() in the netvsc_linkstatus_callback().
I attached a patch. Would you like to test it on your side as well?
Thanks,
- Haiyang
[-- Attachment #2: net_stat_warn_test.patch --]
[-- Type: application/octet-stream, Size: 562 bytes --]
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5f85205..8341b62 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -241,13 +241,11 @@ void netvsc_linkstatus_callback(struct hv_device *device_obj,
if (status == 1) {
netif_carrier_on(net);
- netif_wake_queue(net);
ndev_ctx = netdev_priv(net);
schedule_delayed_work(&ndev_ctx->dwork, 0);
schedule_delayed_work(&ndev_ctx->dwork, msecs_to_jiffies(20));
} else {
netif_carrier_off(net);
- netif_tx_disable(net);
}
}
^ permalink raw reply related
* Re: [PATCH] CAIF: fix indentation for function arguments
From: Sjur Brændeland @ 2013-03-06 22:36 UTC (permalink / raw)
To: Silviu-Mihai Popescu; +Cc: netdev, davem, linux-kernel, Erwan YVIN
In-Reply-To: <1362606521-16848-1-git-send-email-silviupopescu1990@gmail.com>
On Wed, Mar 6, 2013 at 10:48 PM, Silviu-Mihai Popescu
<silviupopescu1990@gmail.com> wrote:
> This lines up function arguments on second and subsequent lines at the
> first column after the openning parenthesis of the first line.
>
> Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990@gmail.com>
There is quite a bit of churn for stuff not even noticed by checkpatch --strict,
but it does improve the style...
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Re: [PATCH net-next] vmxnet3: prevent div-by-zero panic when ring resizing uninitialized dev
From: David Miller @ 2013-03-06 22:09 UTC (permalink / raw)
To: bhavesh; +Cc: netdev, linux-kernel, pv-drivers, sbhatewara
In-Reply-To: <1362607493-5634-1-git-send-email-bhavesh@vmware.com>
From: Bhavesh Davda <bhavesh@vmware.com>
Date: Wed, 6 Mar 2013 14:04:53 -0800
> Linux is free to call ethtool ops as soon as a netdev exists when probe
> finishes. However, we only allocate vmxnet3 tx/rx queues and initialize the
> rx_buf_per_pkt field in struct vmxnet3_adapter when the interface is
> opened (UP).
>
> Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Maybe this is more appropriate for 'net' rather than 'net-next'?
^ permalink raw reply
* Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real server
From: David Miller @ 2013-03-06 22:06 UTC (permalink / raw)
To: ja; +Cc: horms, lvs-devel, netdev
In-Reply-To: <alpine.LFD.2.00.1303062321230.1899@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Wed, 6 Mar 2013 23:58:09 +0200 (EET)
> There are two choices: __ip_vs_get_out_rt
> to return refdst as implemented in this patchset or
> to return dst with additional 'bool *noref' argument,
> so that caller can decide between skb_dst_set or
> skb_set_dst_noref. Then may be we will need just
> a new skb_dst_set_noref_{always,force} func that will
> contain the old skb_set_dst_noref code, i.e. without
> dst_hold? Not sure which variant sounds better.
Both variants are starting to sound equally ugly :-)
Let me ask about this situation in another way.
IP input route lookup clients handle this transparently,
even for routes with next-hop exceptions and nocache
routes, by passing the SKB into the lookup function and
there it will sort out whether noref is actually possible.
Is there a reason that IPVS's route lookup architecture
can't work this way too?
^ permalink raw reply
* [PATCH net-next] vmxnet3: prevent div-by-zero panic when ring resizing uninitialized dev
From: Bhavesh Davda @ 2013-03-06 22:04 UTC (permalink / raw)
To: davem, netdev, linux-kernel
Cc: pv-drivers, Bhavesh Davda, Shreyas N Bhatewara
In-Reply-To: <1362591984-16587-1-git-send-email-bhavesh@vmware.com>
Linux is free to call ethtool ops as soon as a netdev exists when probe
finishes. However, we only allocate vmxnet3 tx/rx queues and initialize the
rx_buf_per_pkt field in struct vmxnet3_adapter when the interface is
opened (UP).
Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethtool.c | 6 ++++++
drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 4aad350..eae7a03 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2958,6 +2958,7 @@ vmxnet3_probe_device(struct pci_dev *pdev,
adapter->num_rx_queues = num_rx_queues;
adapter->num_tx_queues = num_tx_queues;
+ adapter->rx_buf_per_pkt = 1;
size = sizeof(struct Vmxnet3_TxQueueDesc) * adapter->num_tx_queues;
size += sizeof(struct Vmxnet3_RxQueueDesc) * adapter->num_rx_queues;
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index a0feb17..63a1243 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -472,6 +472,12 @@ vmxnet3_set_ringparam(struct net_device *netdev,
VMXNET3_RX_RING_MAX_SIZE)
return -EINVAL;
+ /* if adapter not yet initialized, do nothing */
+ if (adapter->rx_buf_per_pkt == 0) {
+ netdev_err(netdev, "adapter not completely initialized, "
+ "ring size cannot be changed yet\n");
+ return -EOPNOTSUPP;
+ }
/* round it up to a multiple of VMXNET3_RING_SIZE_ALIGN */
new_tx_ring_size = (param->tx_pending + VMXNET3_RING_SIZE_MASK) &
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 3198384..3541814 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -70,10 +70,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.1.29.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.1.30.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01011D00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01011E00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] vmxnet3: prevent div-by-zero panic when ring resizing uninitialized dev
From: Bhavesh Davda @ 2013-03-06 22:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, pv-drivers, sbhatewara
In-Reply-To: <20130306.153841.784919874486534382.davem@davemloft.net>
> > ---
> > drivers/net/vmxnet3/vmxnet3_drv.c | 3 ++-
> > drivers/net/vmxnet3/vmxnet3_ethtool.c | 6 ++++++
> > drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
> > 3 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
> > b/drivers/net/vmxnet3/vmxnet3_drv.c
> > index 4aad350..bfc5898 100644
> > --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> > +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> > @@ -2922,7 +2922,7 @@ vmxnet3_probe_device(struct pci_dev *pdev,
> > (int)num_online_cpus());
> > else
> > #endif
> > - num_rx_queues = 1;
> > + num_rx_queues = 1;
>
> Why are you un-indenting this else branch? Please don't do that
>
Just to annoy you :) [Sorry, couldn't resist.]
I'm sorry I didn't notice I was breaking the indent of the else branch. For some reason checkpatch didn't complain.
While at it, I'm also changing the netdev_info to netdev_err in vmxnet3_ethtool.c.
You didn't explicitly ask for it, so I wasn't sure if I should repost the patch. I'm going to repost it any way and leave it up to you on which patch you want to apply.
Thanks.
- Bhavesh
^ permalink raw reply
* Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real server
From: Julian Anastasov @ 2013-03-06 21:58 UTC (permalink / raw)
To: David Miller; +Cc: horms, lvs-devel, netdev
In-Reply-To: <20130306.151810.1494132480233578627.davem@davemloft.net>
Hello,
On Wed, 6 Mar 2013, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Wed, 6 Mar 2013 10:42:16 +0200
>
> > Currently when forwarding requests to real servers
> > we use dst_lock and atomic operations when cloning the
> > dst_cache value. As the dst_cache value does not change
> > most of the time it is better to use RCU and to lock
> > dst_lock only when we need to replace the obsoleted dst.
> > For this to work we keep dst_cache in new structure protected
> > by RCU. For packets to remote real servers we will use noref
> > version of dst_cache, it will be valid while we are in RCU
> > read-side critical section because now dst_release for replaced
> > dsts will be invoked after the grace period. NAT-ed packets
> > via loopback that are not sent but are passed to local stack
> > with NF_ACCEPT need a dst clone (skb_dst_force).
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
>
> It think it's much cleaner to have the callers of route lookups do
> skb_set_dst_noref().
This was my first thought but commit 27b75c95f1
(net: avoid RCU for NOCACHE dst) uses dst_hold for
DST_NOCACHE dsts. IPVS wants to cache DST_NOCACHE entries
(due to known-NH reasons) and later to use them for
noref dsts...
Also, in the IPVS case we can not set skb_dst
at the time when route is looked up because due to
MTU and other checks we can fail, functions like
icmp_send() will need the original skb_dst in
such case.
There are two choices: __ip_vs_get_out_rt
to return refdst as implemented in this patchset or
to return dst with additional 'bool *noref' argument,
so that caller can decide between skb_dst_set or
skb_set_dst_noref. Then may be we will need just
a new skb_dst_set_noref_{always,force} func that will
contain the old skb_set_dst_noref code, i.e. without
dst_hold? Not sure which variant sounds better.
> Then you don't need any new interfaces, and you therefore don't need
> to expose bits of the noref implementation and semantics at all.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: Eric Dumazet @ 2013-03-06 21:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eilong, jhs, herbert, Tom Herbert
In-Reply-To: <20130306.145947.1445904594058156164.davem@davemloft.net>
On Wed, 2013-03-06 at 14:59 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 05 Mar 2013 23:03:18 -0800
>
> > On Tue, 2013-03-05 at 23:37 -0500, David Miller wrote:
> >
> >> Thanks for the explanation.
> >>
> >> Since you haven't completely resolved the issues you were running into
> >> I'll target this to net-next for now.
> >
> > Thanks David
> >
> > An other issue is the spin_trylock() attempted in net_tx_action()
> >
> > It seems we can miss a qdisc_run(), and have to wait the following
> > NET_TX softirq(s) to send more data. NET_RX being interleaved, we can
> > have to wait a long time (not mentioning other softirq handlers like
> > RCU ...)
> >
> > I might be too tired right now, but cant see the reason of the trylock.
> >
> > qdisc lock is already BH safe, so we should do a spinlock
> ...
> > @@ -3201,22 +3201,11 @@ static void net_tx_action(struct softirq_action *h)
> > head = head->next_sched;
> >
> > root_lock = qdisc_lock(q);
> > - if (spin_trylock(root_lock)) {
> > - smp_mb__before_clear_bit();
> > - clear_bit(__QDISC_STATE_SCHED,
> > - &q->state);
> > - qdisc_run(q);
> > - spin_unlock(root_lock);
>
> I think this trylock is intentional, but not to deal with BH safeness,
> but rather to allow another cpu already processing the qdisc to
> continue doing so.
>
> I think this is what Jamal's amazing flash animations back at netconf
> in Toronto were all about :-)
Yes, but with :
- BQL (incurring more TX completion rounds and possibility to
block/unblock a qdisc)
- ticket spinlocks, and even with the guard of qdisc busylock
-> we can have a starvation problem.
I noticed on perf top sessions once cpu kept scheduling NET_TX softirqs
in (almost) infinite loops.
(if trylock() doesn't succeed, this cpu requeue this qdisc for another
net_tx_action() run)
BTW, I wonder if we should not exchange NET_TX_SOFTIRQ & NET_RX_SOFTIRQ
Usually the net_rx_action() calls napi poll() and TX completion, and
netdev_tx_completed_queue() unblocks a qdisc (requesting a
netif_schedule_queue() -> scheduling a NT_TX_SOFTIRQ)
Or... maybe netdev_tx_completed_queue() should directly call qdisc_run()
instead of deferring it ?
^ permalink raw reply
* [PATCH] CAIF: fix indentation for function arguments
From: Silviu-Mihai Popescu @ 2013-03-06 21:48 UTC (permalink / raw)
To: netdev; +Cc: sjur.brandeland, davem, linux-kernel
This lines up function arguments on second and subsequent lines at the
first column after the openning parenthesis of the first line.
Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990@gmail.com>
---
net/caif/caif_dev.c | 8 ++++----
net/caif/caif_socket.c | 22 +++++++++++-----------
net/caif/caif_usb.c | 4 ++--
net/caif/cfcnfg.c | 20 ++++++++++----------
net/caif/cfctrl.c | 14 +++++++-------
net/caif/cffrml.c | 4 ++--
net/caif/cfmuxl.c | 4 ++--
net/caif/cfpkt_skbuff.c | 8 ++++----
net/caif/cfrfml.c | 4 ++--
net/caif/cfserl.c | 4 ++--
net/caif/cfsrvl.c | 13 ++++++-------
net/caif/chnl_net.c | 6 +++---
12 files changed, 55 insertions(+), 56 deletions(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 21760f0..42f10a6 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -301,10 +301,10 @@ static void dev_flowctrl(struct net_device *dev, int on)
}
void caif_enroll_dev(struct net_device *dev, struct caif_dev_common *caifdev,
- struct cflayer *link_support, int head_room,
- struct cflayer **layer, int (**rcv_func)(
- struct sk_buff *, struct net_device *,
- struct packet_type *, struct net_device *))
+ struct cflayer *link_support, int head_room,
+ struct cflayer **layer, int (**rcv_func)(
+ struct sk_buff *, struct net_device *,
+ struct packet_type *, struct net_device *))
{
struct caif_device_entry *caifd;
enum cfcnfg_phy_preference pref;
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 095259f..1d337e0 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -197,8 +197,8 @@ static void cfsk_put(struct cflayer *layr)
/* Packet Control Callback function called from CAIF */
static void caif_ctrl_cb(struct cflayer *layr,
- enum caif_ctrlcmd flow,
- int phyid)
+ enum caif_ctrlcmd flow,
+ int phyid)
{
struct caifsock *cf_sk = container_of(layr, struct caifsock, layer);
switch (flow) {
@@ -274,7 +274,7 @@ static void caif_check_flow_release(struct sock *sk)
* changed locking, address handling and added MSG_TRUNC.
*/
static int caif_seqpkt_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *m, size_t len, int flags)
+ struct msghdr *m, size_t len, int flags)
{
struct sock *sk = sock->sk;
@@ -346,8 +346,8 @@ static long caif_stream_data_wait(struct sock *sk, long timeo)
* changed locking calls, changed address handling.
*/
static int caif_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, size_t size,
- int flags)
+ struct msghdr *msg, size_t size,
+ int flags)
{
struct sock *sk = sock->sk;
int copied = 0;
@@ -462,7 +462,7 @@ out:
* CAIF flow-on and sock_writable.
*/
static long caif_wait_for_flow_on(struct caifsock *cf_sk,
- int wait_writeable, long timeo, int *err)
+ int wait_writeable, long timeo, int *err)
{
struct sock *sk = &cf_sk->sk;
DEFINE_WAIT(wait);
@@ -516,7 +516,7 @@ static int transmit_skb(struct sk_buff *skb, struct caifsock *cf_sk,
/* Copied from af_unix:unix_dgram_sendmsg, and adapted to CAIF */
static int caif_seqpkt_sendmsg(struct kiocb *kiocb, struct socket *sock,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -591,7 +591,7 @@ err:
* and other minor adaptations.
*/
static int caif_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -670,7 +670,7 @@ out_err:
}
static int setsockopt(struct socket *sock,
- int lvl, int opt, char __user *ov, unsigned int ol)
+ int lvl, int opt, char __user *ov, unsigned int ol)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -932,7 +932,7 @@ static int caif_release(struct socket *sock)
/* Copied from af_unix.c:unix_poll(), added CAIF tx_flow handling */
static unsigned int caif_poll(struct file *file,
- struct socket *sock, poll_table *wait)
+ struct socket *sock, poll_table *wait)
{
struct sock *sk = sock->sk;
unsigned int mask;
@@ -1022,7 +1022,7 @@ static void caif_sock_destructor(struct sock *sk)
}
static int caif_create(struct net *net, struct socket *sock, int protocol,
- int kern)
+ int kern)
{
struct sock *sk = NULL;
struct caifsock *cf_sk = NULL;
diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
index ef8ebaa..d76278d 100644
--- a/net/caif/caif_usb.c
+++ b/net/caif/caif_usb.c
@@ -75,7 +75,7 @@ static int cfusbl_transmit(struct cflayer *layr, struct cfpkt *pkt)
}
static void cfusbl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
if (layr->up && layr->up->ctrlcmd)
layr->up->ctrlcmd(layr->up, ctrl, layr->id);
@@ -121,7 +121,7 @@ static struct packet_type caif_usb_type __read_mostly = {
};
static int cfusbl_device_notify(struct notifier_block *me, unsigned long what,
- void *arg)
+ void *arg)
{
struct net_device *dev = arg;
struct caif_dev_common common;
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index f1dbddb..5b9fe1b 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -61,11 +61,11 @@ struct cfcnfg {
};
static void cfcnfg_linkup_rsp(struct cflayer *layer, u8 channel_id,
- enum cfctrl_srv serv, u8 phyid,
- struct cflayer *adapt_layer);
+ enum cfctrl_srv serv, u8 phyid,
+ struct cflayer *adapt_layer);
static void cfcnfg_linkdestroy_rsp(struct cflayer *layer, u8 channel_id);
static void cfcnfg_reject_rsp(struct cflayer *layer, u8 channel_id,
- struct cflayer *adapt_layer);
+ struct cflayer *adapt_layer);
static void cfctrl_resp_func(void);
static void cfctrl_enum_resp(void);
@@ -131,7 +131,7 @@ static void cfctrl_resp_func(void)
}
static struct cfcnfg_phyinfo *cfcnfg_get_phyinfo_rcu(struct cfcnfg *cnfg,
- u8 phyid)
+ u8 phyid)
{
struct cfcnfg_phyinfo *phy;
@@ -216,8 +216,8 @@ static const int protohead[CFCTRL_SRV_MASK] = {
static int caif_connect_req_to_link_param(struct cfcnfg *cnfg,
- struct caif_connect_request *s,
- struct cfctrl_link_param *l)
+ struct caif_connect_request *s,
+ struct cfctrl_link_param *l)
{
struct dev_info *dev_info;
enum cfcnfg_phy_preference pref;
@@ -301,8 +301,8 @@ static int caif_connect_req_to_link_param(struct cfcnfg *cnfg,
int caif_connect_client(struct net *net, struct caif_connect_request *conn_req,
struct cflayer *adap_layer, int *ifindex,
- int *proto_head,
- int *proto_tail)
+ int *proto_head,
+ int *proto_tail)
{
struct cflayer *frml;
struct cfcnfg_phyinfo *phy;
@@ -364,7 +364,7 @@ unlock:
EXPORT_SYMBOL(caif_connect_client);
static void cfcnfg_reject_rsp(struct cflayer *layer, u8 channel_id,
- struct cflayer *adapt_layer)
+ struct cflayer *adapt_layer)
{
if (adapt_layer != NULL && adapt_layer->ctrlcmd != NULL)
adapt_layer->ctrlcmd(adapt_layer,
@@ -526,7 +526,7 @@ out_err:
EXPORT_SYMBOL(cfcnfg_add_phy_layer);
int cfcnfg_set_phy_state(struct cfcnfg *cnfg, struct cflayer *phy_layer,
- bool up)
+ bool up)
{
struct cfcnfg_phyinfo *phyinfo;
diff --git a/net/caif/cfctrl.c b/net/caif/cfctrl.c
index a376ec1..9cd057c 100644
--- a/net/caif/cfctrl.c
+++ b/net/caif/cfctrl.c
@@ -20,12 +20,12 @@
#ifdef CAIF_NO_LOOP
static int handle_loop(struct cfctrl *ctrl,
- int cmd, struct cfpkt *pkt){
+ int cmd, struct cfpkt *pkt){
return -1;
}
#else
static int handle_loop(struct cfctrl *ctrl,
- int cmd, struct cfpkt *pkt);
+ int cmd, struct cfpkt *pkt);
#endif
static int cfctrl_recv(struct cflayer *layr, struct cfpkt *pkt);
static void cfctrl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
@@ -72,7 +72,7 @@ void cfctrl_remove(struct cflayer *layer)
}
static bool param_eq(const struct cfctrl_link_param *p1,
- const struct cfctrl_link_param *p2)
+ const struct cfctrl_link_param *p2)
{
bool eq =
p1->linktype == p2->linktype &&
@@ -197,8 +197,8 @@ void cfctrl_enum_req(struct cflayer *layer, u8 physlinkid)
}
int cfctrl_linkup_request(struct cflayer *layer,
- struct cfctrl_link_param *param,
- struct cflayer *user_layer)
+ struct cfctrl_link_param *param,
+ struct cflayer *user_layer)
{
struct cfctrl *cfctrl = container_obj(layer);
u32 tmp32;
@@ -301,7 +301,7 @@ int cfctrl_linkup_request(struct cflayer *layer,
}
int cfctrl_linkdown_req(struct cflayer *layer, u8 channelid,
- struct cflayer *client)
+ struct cflayer *client)
{
int ret;
struct cfpkt *pkt;
@@ -555,7 +555,7 @@ error:
}
static void cfctrl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
struct cfctrl *this = container_obj(layr);
switch (ctrl) {
diff --git a/net/caif/cffrml.c b/net/caif/cffrml.c
index 0a7df7e..204c5e2 100644
--- a/net/caif/cffrml.c
+++ b/net/caif/cffrml.c
@@ -28,7 +28,7 @@ struct cffrml {
static int cffrml_receive(struct cflayer *layr, struct cfpkt *pkt);
static int cffrml_transmit(struct cflayer *layr, struct cfpkt *pkt);
static void cffrml_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid);
+ int phyid);
static u32 cffrml_rcv_error;
static u32 cffrml_rcv_checsum_error;
@@ -167,7 +167,7 @@ static int cffrml_transmit(struct cflayer *layr, struct cfpkt *pkt)
}
static void cffrml_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
if (layr->up && layr->up->ctrlcmd)
layr->up->ctrlcmd(layr->up, ctrl, layr->id);
diff --git a/net/caif/cfmuxl.c b/net/caif/cfmuxl.c
index 94b0861..154d9f8 100644
--- a/net/caif/cfmuxl.c
+++ b/net/caif/cfmuxl.c
@@ -42,7 +42,7 @@ struct cfmuxl {
static int cfmuxl_receive(struct cflayer *layr, struct cfpkt *pkt);
static int cfmuxl_transmit(struct cflayer *layr, struct cfpkt *pkt);
static void cfmuxl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid);
+ int phyid);
static struct cflayer *get_up(struct cfmuxl *muxl, u16 id);
struct cflayer *cfmuxl_create(void)
@@ -244,7 +244,7 @@ static int cfmuxl_transmit(struct cflayer *layr, struct cfpkt *pkt)
}
static void cfmuxl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
struct cfmuxl *muxl = container_obj(layr);
struct cflayer *layer;
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index 863dedd..e8f9c14 100644
--- a/net/caif/cfpkt_skbuff.c
+++ b/net/caif/cfpkt_skbuff.c
@@ -266,8 +266,8 @@ inline u16 cfpkt_getlen(struct cfpkt *pkt)
}
inline u16 cfpkt_iterate(struct cfpkt *pkt,
- u16 (*iter_func)(u16, void *, u16),
- u16 data)
+ u16 (*iter_func)(u16, void *, u16),
+ u16 data)
{
/*
* Don't care about the performance hit of linearizing,
@@ -307,8 +307,8 @@ int cfpkt_setlen(struct cfpkt *pkt, u16 len)
}
struct cfpkt *cfpkt_append(struct cfpkt *dstpkt,
- struct cfpkt *addpkt,
- u16 expectlen)
+ struct cfpkt *addpkt,
+ u16 expectlen)
{
struct sk_buff *dst = pkt_to_skb(dstpkt);
struct sk_buff *add = pkt_to_skb(addpkt);
diff --git a/net/caif/cfrfml.c b/net/caif/cfrfml.c
index 2b563ad..db51830 100644
--- a/net/caif/cfrfml.c
+++ b/net/caif/cfrfml.c
@@ -43,7 +43,7 @@ static void cfrfml_release(struct cflayer *layer)
}
struct cflayer *cfrfml_create(u8 channel_id, struct dev_info *dev_info,
- int mtu_size)
+ int mtu_size)
{
int tmp;
struct cfrfml *this = kzalloc(sizeof(struct cfrfml), GFP_ATOMIC);
@@ -69,7 +69,7 @@ struct cflayer *cfrfml_create(u8 channel_id, struct dev_info *dev_info,
}
static struct cfpkt *rfm_append(struct cfrfml *rfml, char *seghead,
- struct cfpkt *pkt, int *err)
+ struct cfpkt *pkt, int *err)
{
struct cfpkt *tmppkt;
*err = -EPROTO;
diff --git a/net/caif/cfserl.c b/net/caif/cfserl.c
index 8e68b97..147c232 100644
--- a/net/caif/cfserl.c
+++ b/net/caif/cfserl.c
@@ -29,7 +29,7 @@ struct cfserl {
static int cfserl_receive(struct cflayer *layr, struct cfpkt *pkt);
static int cfserl_transmit(struct cflayer *layr, struct cfpkt *pkt);
static void cfserl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid);
+ int phyid);
struct cflayer *cfserl_create(int instance, bool use_stx)
{
@@ -182,7 +182,7 @@ static int cfserl_transmit(struct cflayer *layer, struct cfpkt *newpkt)
}
static void cfserl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
layr->up->ctrlcmd(layr->up, ctrl, phyid);
}
diff --git a/net/caif/cfsrvl.c b/net/caif/cfsrvl.c
index ba217e9..95f7f5e 100644
--- a/net/caif/cfsrvl.c
+++ b/net/caif/cfsrvl.c
@@ -25,7 +25,7 @@
#define container_obj(layr) container_of(layr, struct cfsrvl, layer)
static void cfservl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
- int phyid)
+ int phyid)
{
struct cfsrvl *service = container_obj(layr);
@@ -158,10 +158,9 @@ static void cfsrvl_release(struct cflayer *layer)
}
void cfsrvl_init(struct cfsrvl *service,
- u8 channel_id,
- struct dev_info *dev_info,
- bool supports_flowctrl
- )
+ u8 channel_id,
+ struct dev_info *dev_info,
+ bool supports_flowctrl)
{
caif_assert(offsetof(struct cfsrvl, layer) == 0);
service->open = false;
@@ -207,8 +206,8 @@ void caif_free_client(struct cflayer *adap_layer)
EXPORT_SYMBOL(caif_free_client);
void caif_client_register_refcnt(struct cflayer *adapt_layer,
- void (*hold)(struct cflayer *lyr),
- void (*put)(struct cflayer *lyr))
+ void (*hold)(struct cflayer *lyr),
+ void (*put)(struct cflayer *lyr))
{
struct cfsrvl *service;
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index e597733..26a4e4e 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -167,7 +167,7 @@ static void chnl_put(struct cflayer *lyr)
}
static void chnl_flowctrl_cb(struct cflayer *layr, enum caif_ctrlcmd flow,
- int phyid)
+ int phyid)
{
struct chnl_net *priv = container_of(layr, struct chnl_net, chnl);
pr_debug("NET flowctrl func called flow: %s\n",
@@ -443,7 +443,7 @@ nla_put_failure:
}
static void caif_netlink_parms(struct nlattr *data[],
- struct caif_connect_request *conn_req)
+ struct caif_connect_request *conn_req)
{
if (!data) {
pr_warn("no params data found\n");
@@ -488,7 +488,7 @@ static int ipcaif_newlink(struct net *src_net, struct net_device *dev,
}
static int ipcaif_changelink(struct net_device *dev, struct nlattr *tb[],
- struct nlattr *data[])
+ struct nlattr *data[])
{
struct chnl_net *caifdev;
ASSERT_RTNL();
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next] bond: add support to read speed and duplex via ethtool
From: Jay Vosburgh @ 2013-03-06 21:46 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20130306200140.GB19544@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>On Wed, Mar 06, 2013 at 11:25:12AM -0800, Jay Vosburgh wrote:
>> Andy Gospodarek <andy@greyhouse.net> wrote:
>>
>> >This patch adds support for the get_settings ethtool op to the bonding
>> >driver. This was motivated by users who wanted to get the speed of the
>> >bond and compare that against throughput to understand utilization.
>> >The behavior before this patch was added was problematic when computing
>> >line utilization after trying to get link-speed and throughput via SNMP.
>> >
>> >The general plan for computing link-speed was as follows:
>> >
>> >Mode Formula
>> >---- -------
>> >active-backup speed of current active slave
>> >broadcast speed of first slave with known speed
>> >all other modes aggregate speed of all slaves with known speed
>>
>> I'll just point out that the balance-tlb mode is asymmetric; it
>> uses all slaves for transmission, but only one slave for reception.
>> Ethtool only has a single speed for both directions, so this is probably
>> the best choice, but it should still be noted.
>
>Thanks for pointing that out. I have a feeling there will be a v2, so
>I'll try and update the changelog to reflect that. For the record, this
>same limitation exists when connecting to most switches and using
>round-robin, so I didn't feel the need to differentiate possibly
>asymmetric speeds.
>
>> >Output from ethtool looks like this for a round-robin bond:
>> >
>> >Settings for bond0:
>> > Supported ports: [ ]
>> > Supported link modes: Not reported
>> > Supported pause frame use: No
>> > Supports auto-negotiation: No
>> > Advertised link modes: Not reported
>> > Advertised pause frame use: No
>> > Advertised auto-negotiation: No
>> > Speed: 11000Mb/s
>> > Duplex: Full
>> > Port: Twisted Pair
>> > PHYAD: 0
>> > Transceiver: internal
>> > Auto-negotiation: off
>> > MDI-X: Unknown
>> > Link detected: yes
>> >
>> >I tested this and verified it works as expected. A test was also done
>> >on a version backported to an older kernel and it worked well there.
>> >
>> >Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>> >---
>> > drivers/net/bonding/bond_main.c | 47 +++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 47 insertions(+)
>> >
>> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> >index 7bd068a..6e70ff0 100644
>> >--- a/drivers/net/bonding/bond_main.c
>> >+++ b/drivers/net/bonding/bond_main.c
>> >@@ -4224,6 +4224,52 @@ void bond_set_mode_ops(struct bonding *bond, int mode)
>> > }
>> > }
>> >
>> >+static int bond_ethtool_get_settings(struct net_device *bond_dev,
>> >+ struct ethtool_cmd *ecmd)
>> >+{
>> >+ struct bonding *bond = netdev_priv(bond_dev);
>> >+ struct slave *slave;
>> >+ int i;
>> >+ unsigned long speed = 0;
>> >+
>> >+ ecmd->speed = SPEED_UNKNOWN;
>> >+ ecmd->duplex = DUPLEX_UNKNOWN;
>> >+
>> >+ read_lock(&bond->lock);
>> >+ switch (bond->params.mode) {
>> >+ case BOND_MODE_ACTIVEBACKUP:
>> >+ read_lock(&bond->curr_slave_lock);
>> >+ if (bond->curr_active_slave &&
>> >+ bond->curr_active_slave->speed != SPEED_UNKNOWN) {
>> >+ ecmd->speed = bond->curr_active_slave->speed;
>> >+ ecmd->duplex = bond->curr_active_slave->duplex;
>> >+ }
>> >+ read_unlock(&bond->curr_slave_lock);
>> >+ break;
>> >+ case BOND_MODE_BROADCAST:
>> >+ bond_for_each_slave(bond, slave, i) {
>> >+ if (slave->speed != SPEED_UNKNOWN) {
>> >+ ecmd->speed = slave->speed;
>> >+ ecmd->duplex = slave->duplex;
>> >+ break;
>> >+ }
>> >+ }
>> >+ break;
>>
>> Does anybody really use broadcast mode? Not that I'm saying
>> this is incorrect, I'm just wondering in general.
>>
>
>I don't imagine they do, but wanted to add something for it since it
>would not reallyu fall into the default case well.
>
>> >+ default:
>> >+ bond_for_each_slave(bond, slave, i) {
>> >+ if (slave->speed != SPEED_UNKNOWN) {
>> >+ speed += slave->speed;
>> >+ }
>> >+ if (ecmd->duplex == DUPLEX_UNKNOWN &&
>> >+ slave->duplex != DUPLEX_UNKNOWN)
>> >+ ecmd->duplex = slave->duplex;
>>
>> Should the calculations skip slaves that are not BOND_LINK_UP?
>> If the ARP monitor is running, some slaves may be carrier up (and have
>> slave->speed set), but are not actually in use by the bond, at least for
>> transmission.
>>
>
>That would be fine with me. If you would like I can add that for a v2.
>It would produce a more honest estimate of what the maximum throughput
>would be at that point in time.
Yes, I think so; it's going to be an estimate for any of the
load balance modes, but it ought to be as close as is reasonable to what
kind of throughput would be expected.
I also think it might be odd if it were possible for a bond to
simultaneously show as carrier down, but speed as something very high.
-J
>> >+ }
>> >+ ecmd->speed = speed;
>> >+ }
>> >+ read_unlock(&bond->lock);
>> >+ return 0;
>> >+}
>> >+
>> > static void bond_ethtool_get_drvinfo(struct net_device *bond_dev,
>> > struct ethtool_drvinfo *drvinfo)
>> > {
>> >@@ -4235,6 +4281,7 @@ static void bond_ethtool_get_drvinfo(struct net_device *bond_dev,
>> >
>> > static const struct ethtool_ops bond_ethtool_ops = {
>> > .get_drvinfo = bond_ethtool_get_drvinfo,
>> >+ .get_settings = bond_ethtool_get_settings,
>> > .get_link = ethtool_op_get_link,
>> > };
>> >
>> >--
>> >1.7.11.7
>>
>> ---
>> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] netlabel: correctly list all the static label mappings
From: Paul Moore @ 2013-03-06 21:45 UTC (permalink / raw)
To: netdev
When we have a large number of static label mappings that spill across
the netlink message boundary we fail to properly save our state in the
netlink_callback struct which causes us to repeat the same listings.
This patch fixes this problem by saving the state correctly between
calls to the NetLabel static label netlink "dumpit" routines.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Cc: stable@vger.kernel.org
---
net/netlabel/netlabel_unlabeled.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 847d495..85742b7 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1250,10 +1250,10 @@ static int netlbl_unlabel_staticlist(struct sk_buff *skb,
unlabel_staticlist_return:
rcu_read_unlock();
- cb->args[0] = skip_bkt;
- cb->args[1] = skip_chain;
- cb->args[2] = skip_addr4;
- cb->args[3] = skip_addr6;
+ cb->args[0] = iter_bkt;
+ cb->args[1] = iter_chain;
+ cb->args[2] = iter_addr4;
+ cb->args[3] = iter_addr6;
return skb->len;
}
@@ -1320,8 +1320,8 @@ static int netlbl_unlabel_staticlistdef(struct sk_buff *skb,
unlabel_staticlistdef_return:
rcu_read_unlock();
- cb->args[0] = skip_addr4;
- cb->args[1] = skip_addr6;
+ cb->args[0] = iter_addr4;
+ cb->args[1] = iter_addr6;
return skb->len;
}
^ permalink raw reply related
* Re: [PATCH 3/3 net-next] tcp: implement RFC5682 F-RTO
From: Vijay Subramanian @ 2013-03-06 21:34 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: davem, ncardwell, edumazet, nanditad, ilpo.jarvinen, netdev
In-Reply-To: <1362603130-16501-3-git-send-email-ycheng@google.com>
On 6 March 2013 12:52, Yuchung Cheng <ycheng@google.com> wrote:
> This patch implements F-RTO (foward RTO recovery):
>
You may want to fix the following checkpatch errors:
ERROR: trailing whitespace
#129: FILE: net/ipv4/tcp_input.c:1893:
+^I/* F-RTO RFC5682 sec 3.1 step 1: retransmit SND.UNA if no previous $
ERROR: trailing whitespace
#184: FILE: net/ipv4/tcp_input.c:2694:
+^I^I^I/* Step 3.b. A timeout is spurious if not all data are $
ERROR: trailing whitespace
#216: FILE: net/ipv4/tcp_input.c:2722:
+^I^I/* A Reno DUPACK means new data in F-RTO step 2.b above are $
-Vijay
^ permalink raw reply
* Re: [PATCH] 8139too: send NETDEV_CHANGE manually when autoneg is disabled
From: Francois Romieu @ 2013-03-06 21:35 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, vfalico, netdev, wfp5p, jasowang, junchangwang,
greearb, ivecera
In-Reply-To: <20130306.155323.344491888348815531.davem@davemloft.net>
David Miller <davem@davemloft.net> :
> From: Ben Hutchings <bhutchings@solarflare.com>
[...]
> > Isn't this really a bug in mii_check_media()? It shouldn't shortcut the
> > calls to netif_carrier_{off,on}() just because mii->force_media is set.
>
> I think mii_check_media() is responsible for handling this too.
There are a few drivers that use mii_ethtool_sset as 8139too does
while not relying upon mii_check_media.
What ought to be done for those ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 03/12] ipvs: prefer NETDEV_DOWN event to free cached dsts
From: Julian Anastasov @ 2013-03-06 21:21 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: Simon Horman, lvs-devel, netdev
In-Reply-To: <1362563789.17102.69.camel@hawk.mlab.se>
Hello,
On Wed, 6 Mar 2013, Hans Schillstrom wrote:
> Hi Julian
>
> On Wed, 2013-03-06 at 10:42 +0200, Julian Anastasov wrote:
> > The real server becomes unreachable on down event,
> > no need to wait device unregistration. Should help in
> > releasing dsts early before dst->dev is replaced with lo.
>
> Have you test this in a network namespace ?
> i.e. kill the namespace with heave traffic through it
This should not be a problem. Even without ns exit
situation, we can have a case where device goes down,
the output routes will start to fail and we will
not cache route anymore. It can happen while the
input device floods us with requests.
> From what I remember this was a tricky area...
>
> I have some test cases for this, should I run them ?
If it is easy...
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > ---
> > net/netfilter/ipvs/ip_vs_ctl.c | 8 +++-----
> > 1 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > index c68198b..76fc8f2 100644
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -1512,10 +1512,8 @@ __ip_vs_dev_reset(struct ip_vs_dest *dest, struct net_device *dev)
> > spin_unlock_bh(&dest->dst_lock);
> >
> > }
> > -/*
> > - * Netdev event receiver
> > - * Currently only NETDEV_UNREGISTER is handled, i.e. if we hold a reference to
> > - * a device that is "unregister" it must be released.
> > +/* Netdev event receiver
> > + * Currently only NETDEV_DOWN is handled to release refs to cached dsts
> > */
> > static int ip_vs_dst_event(struct notifier_block *this, unsigned long event,
> > void *ptr)
> > @@ -1527,7 +1525,7 @@ static int ip_vs_dst_event(struct notifier_block *this, unsigned long event,
> > struct ip_vs_dest *dest;
> > unsigned int idx;
> >
> > - if (event != NETDEV_UNREGISTER || !ipvs)
> > + if (event != NETDEV_DOWN || !ipvs)
> > return NOTIFY_DONE;
> > IP_VS_DBG(3, "%s() dev=%s\n", __func__, dev->name);
> > EnterFunction(2);
>
>
> Regards
> Hans
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tcp: implement RFC5682 F-RTO
From: Neal Cardwell @ 2013-03-06 21:08 UTC (permalink / raw)
To: Yuchung Cheng
Cc: David Miller, Eric Dumazet, Nandita Dukkipati, ilpo.jarvinen,
Netdev
In-Reply-To: <1362603130-16501-3-git-send-email-ycheng@google.com>
On Wed, Mar 6, 2013 at 3:52 PM, Yuchung Cheng <ycheng@google.com> wrote:
> This patch implements F-RTO (foward RTO recovery):
>
> When the first retransmission after timeout is acknowledged, F-RTO
> sends new data instead of old data. If the next ACK acknowledges
> some never-retransmitted data, then the timeout was spurious and the
> congestion state is reverted. Otherwise if the next ACK selectively
> acknowledges the new data, then the timeout was genuine and the
> loss recovery continues. This idea applies to recurring timeouts
> as well. While F-RTO sends different data during timeout recovery,
> it does not (and should not) change the congestion control.
>
> The implementaion follows the three steps of SACK enhanced algorithm
> (section 3) in RFC5682. Step 1 is in tcp_enter_loss(). Step 2 and
> 3 are in tcp_process_loss(). The basic version is not supported
> because SACK enhanced version also works for non-SACK connections.
>
> The new implementation is functionally in parity with the old F-RTO
> implementation except the one case where it increases undo events:
> In addition to the RFC algorithm, a spurious timeout may be detected
> without sending data in step 2, as long as the SACK confirms not
> all the original data are dropped. When this happens, the sender
> will undo the cwnd and perhaps enter fast recovery instead. This
> additional check increases the F-RTO undo events by 5x compared
> to the prior implementation on Google Web servers, since the sender
> often does not have new data to send for HTTP.
>
> Note F-RTO may detect spurious timeout before Eifel with timestamps
> does so.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* Re: [PATCH 2/3 net-next] tcp: refactor CA_Loss state processing
From: Neal Cardwell @ 2013-03-06 21:07 UTC (permalink / raw)
To: Yuchung Cheng
Cc: David Miller, Eric Dumazet, Nandita Dukkipati, ilpo.jarvinen,
Netdev
In-Reply-To: <1362603130-16501-2-git-send-email-ycheng@google.com>
On Wed, Mar 6, 2013 at 3:52 PM, Yuchung Cheng <ycheng@google.com> wrote:
> Consolidate all of TCP CA_Loss state processing in
> tcp_fastretrans_alert() into a new function called tcp_process_loss().
> This is to prepare the new F-RTO implementation in the next patch.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* Re: [PATCH 1/3 net-next] tcp: refactor F-RTO
From: David Miller @ 2013-03-06 21:06 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, nanditad, ilpo.jarvinen, netdev
In-Reply-To: <1362603130-16501-1-git-send-email-ycheng@google.com>
I'll give Ilpo some time to review this series since he wrote
the original F-RTO code.
Thanks.
^ permalink raw reply
* Re: [PATCH] tun: add a missing nf_reset() in tun_net_xmit()
From: David Miller @ 2013-03-06 21:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev, kernel-team
In-Reply-To: <1362603757.15793.186.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Mar 2013 13:02:37 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Dave reported following crash :
...
> This is because tun_net_xmit() needs to call nf_reset()
> before queuing skb into receive_queue
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/3 net-next] tcp: refactor F-RTO
From: Neal Cardwell @ 2013-03-06 21:05 UTC (permalink / raw)
To: Yuchung Cheng
Cc: David Miller, Eric Dumazet, Nandita Dukkipati, ilpo.jarvinen,
Netdev
In-Reply-To: <1362603130-16501-1-git-send-email-ycheng@google.com>
On Wed, Mar 6, 2013 at 3:52 PM, Yuchung Cheng <ycheng@google.com> wrote:
> The patch series refactor the F-RTO feature (RFC4138/5682).
>
> This is to simplify the loss recovery processing. Existing F-RTO
> was developed during the experimental stage (RFC4138) and has
> many experimental features. It takes a separate code path from
> the traditional timeout processing by overloading CA_Disorder
> instead of using CA_Loss state. This complicates CA_Disorder state
> handling because it's also used for handling dubious ACKs and undos.
> While the algorithm in the RFC does not change the congestion control,
> the implementation intercepts congestion control in various places
> (e.g., frto_cwnd in tcp_ack()).
>
> The new code implements newer F-RTO RFC5682 using CA_Loss processing
> path. F-RTO becomes a small extension in the timeout processing
> and interfaces with congestion control and Eifel undo modules.
> It lets congestion control (module) determines how many to send
> independently. F-RTO only chooses what to send in order to detect
> spurious retranmission. If timeout is found spurious it invokes
> existing Eifel undo algorithms like DSACK or TCP timestamp based
> detection.
>
> The first patch removes all F-RTO code except the sysctl_tcp_frto is
> left for the new implementation. Since CA_EVENT_FRTO is removed, TCP
> westwood now computes ssthresh on regular timeout CA_EVENT_LOSS event.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* [PATCH] tun: add a missing nf_reset() in tun_net_xmit()
From: Eric Dumazet @ 2013-03-06 21:02 UTC (permalink / raw)
To: David Miller; +Cc: davej, netdev, kernel-team
In-Reply-To: <20130306.154641.1893414808816499940.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
Dave reported following crash :
general protection fault: 0000 [#1] SMP
CPU 2
Pid: 25407, comm: qemu-kvm Not tainted 3.7.9-205.fc18.x86_64 #1 Hewlett-Packard HP Z400 Workstation/0B4Ch
RIP: 0010:[<ffffffffa0399bd5>] [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack]
RSP: 0018:ffff880276913d78 EFLAGS: 00010206
RAX: 50626b6b7876376c RBX: ffff88026e530d68 RCX: ffff88028d158e00
RDX: ffff88026d0d5470 RSI: 0000000000000011 RDI: 0000000000000002
RBP: ffff880276913d88 R08: 0000000000000000 R09: ffff880295002900
R10: 0000000000000000 R11: 0000000000000003 R12: ffffffff81ca3b40
R13: ffffffff8151a8e0 R14: ffff880270875000 R15: 0000000000000002
FS: 00007ff3bce38a00(0000) GS:ffff88029fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fd1430bd000 CR3: 000000027042b000 CR4: 00000000000027e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-kvm (pid: 25407, threadinfo ffff880276912000, task ffff88028c369720)
Stack:
ffff880156f59100 ffff880156f59100 ffff880276913d98 ffffffff815534f7
ffff880276913db8 ffffffff8151a74b ffff880270875000 ffff880156f59100
ffff880276913dd8 ffffffff8151a5a6 ffff880276913dd8 ffff88026d0d5470
Call Trace:
[<ffffffff815534f7>] nf_conntrack_destroy+0x17/0x20
[<ffffffff8151a74b>] skb_release_head_state+0x7b/0x100
[<ffffffff8151a5a6>] __kfree_skb+0x16/0xa0
[<ffffffff8151a666>] kfree_skb+0x36/0xa0
[<ffffffff8151a8e0>] skb_queue_purge+0x20/0x40
[<ffffffffa02205f7>] __tun_detach+0x117/0x140 [tun]
[<ffffffffa022184c>] tun_chr_close+0x3c/0xd0 [tun]
[<ffffffff8119669c>] __fput+0xec/0x240
[<ffffffff811967fe>] ____fput+0xe/0x10
[<ffffffff8107eb27>] task_work_run+0xa7/0xe0
[<ffffffff810149e1>] do_notify_resume+0x71/0xb0
[<ffffffff81640152>] int_signal+0x12/0x17
Code: 00 00 04 48 89 e5 41 54 53 48 89 fb 4c 8b a7 e8 00 00 00 0f 85 de 00 00 00 0f b6 73 3e 0f b7 7b 2a e8 10 40 00 00 48 85 c0 74 0e <48> 8b 40 28 48 85 c0 74 05 48 89 df ff d0 48 c7 c7 08 6a 3a a0
RIP [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack]
RSP <ffff880276913d78>
This is because tun_net_xmit() needs to call nf_reset()
before queuing skb into receive_queue
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/tun.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2c6a22e..b7c457a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -747,6 +747,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
skb_orphan(skb);
+ nf_reset(skb);
+
/* Enqueue packet */
skb_queue_tail(&tfile->socket.sk->sk_receive_queue, skb);
^ permalink raw reply related
* Re: [PATCH net-next 11/12] ipvs: reorder keys in connection structure
From: Julian Anastasov @ 2013-03-06 21:01 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: Simon Horman, lvs-devel, netdev
In-Reply-To: <1362563014.17102.63.camel@hawk.mlab.se>
Hello,
On Wed, 6 Mar 2013, Hans Schillstrom wrote:
> Hi Julian
> Great job you have done !
> I'll test it immediate...
Thanks, it would be good to catch the problems
in early phase...
> On Wed, 2013-03-06 at 10:42 +0200, Julian Anastasov wrote:
> > __ip_vs_conn_in_get and ip_vs_conn_out_get are
> > hot places. Optimize them, so that ports are matched first.
> > By moving net and fwmark below, on 32-bit arch we can fit
> > caddr in 32-byte cache line and all addresses in 64-byte
> > cache line.
>
> Earlier I made some rearrangements like the one you have made.
> My conclusion at that time was that the best gain was to have
> fwmark and net within the first 64 bytes, and move daddr to the next
> cache line.
But fwmark is used only for lookups in backup
server. The net field is checked first only in
ip_vs_ct_in_get (on scheduling), it can be optimized too.
Modern CPUs have 64-byte cache line and may be the
places of these fields do not play much because checking
the two ports is enough to differentiate most of the
connections. The addresses play when ports do not
differ, i.e. mostly for persistent connections. So,
on 64-byte cache line it would be more difficult to
see any difference.
> I uesd UDP at ~7Gbit/sec and 256k source address into a x86_64 machine,
> and a 50/50 mix of fwmarks and port in that tests.
>
> I guess that you have made similar test, and even take
> ip_vs_conn_out_get() into your calculations ?
No, I have only virtual boxes for tests...
> Regards
> Hans
>
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > ---
> > include/net/ip_vs.h | 12 ++++++------
> > net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
> > 2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index 9059360..2bc30e6 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -566,20 +566,19 @@ struct ip_vs_conn_param {
> > */
> > struct ip_vs_conn {
> > struct hlist_node c_list; /* hashed list heads */
> > -#ifdef CONFIG_NET_NS
> > - struct net *net; /* Name space */
> > -#endif
> > /* Protocol, addresses and port numbers */
> > - u16 af; /* address family */
> > __be16 cport;
> > - __be16 vport;
> > __be16 dport;
> > - __u32 fwmark; /* Fire wall mark from skb */
> > + __be16 vport;
> > + u16 af; /* address family */
> > union nf_inet_addr caddr; /* client address */
> > union nf_inet_addr vaddr; /* virtual address */
> > union nf_inet_addr daddr; /* destination address */
> > volatile __u32 flags; /* status flags */
> > __u16 protocol; /* Which protocol (TCP/UDP) */
> > +#ifdef CONFIG_NET_NS
> > + struct net *net; /* Name space */
> > +#endif
> >
> > /* counter and timer */
> > atomic_t refcnt; /* reference count */
> > @@ -593,6 +592,7 @@ struct ip_vs_conn {
> > * state transition triggerd
> > * synchronization
> > */
> > + __u32 fwmark; /* Fire wall mark from skb */
> > unsigned long sync_endtime; /* jiffies + sent_retries */
> >
> > /* Control members */
> > diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> > index b0cd2be..a4d8ec5 100644
> > --- a/net/netfilter/ipvs/ip_vs_conn.c
> > +++ b/net/netfilter/ipvs/ip_vs_conn.c
> > @@ -265,8 +265,8 @@ __ip_vs_conn_in_get(const struct ip_vs_conn_param *p)
> > rcu_read_lock();
> >
> > hlist_for_each_entry_rcu(cp, &ip_vs_conn_tab[hash], c_list) {
> > - if (cp->af == p->af &&
> > - p->cport == cp->cport && p->vport == cp->vport &&
> > + if (p->cport == cp->cport && p->vport == cp->vport &&
> > + cp->af == p->af &&
> > ip_vs_addr_equal(p->af, p->caddr, &cp->caddr) &&
> > ip_vs_addr_equal(p->af, p->vaddr, &cp->vaddr) &&
> > ((!p->cport) ^ (!(cp->flags & IP_VS_CONN_F_NO_CPORT))) &&
> > @@ -404,8 +404,8 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
> > rcu_read_lock();
> >
> > hlist_for_each_entry_rcu(cp, &ip_vs_conn_tab[hash], c_list) {
> > - if (cp->af == p->af &&
> > - p->vport == cp->cport && p->cport == cp->dport &&
> > + if (p->vport == cp->cport && p->cport == cp->dport &&
> > + cp->af == p->af &&
> > ip_vs_addr_equal(p->af, p->vaddr, &cp->caddr) &&
> > ip_vs_addr_equal(p->af, p->caddr, &cp->daddr) &&
> > p->protocol == cp->protocol &&
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: hitting lockdep warning as of too early VF probe with 3.9-rc1
From: Or Gerlitz @ 2013-03-06 20:54 UTC (permalink / raw)
To: Ming Lei
Cc: Or Gerlitz, Greg Kroah-Hartman, David Miller, Roland Dreier,
netdev, Yan Burman, Jack Morgenstein, Liran Liss
In-Reply-To: <CACVXFVM2MLR6HxYyvKRnqddqvRbHvzL59+_NxqFek7YN7nDhQQ@mail.gmail.com>
On Wed, Mar 6, 2013 at 4:43 AM, Ming Lei <ming.lei@canonical.com> wrote:
> You are adding one new PCI device inside another PCI device's probe(),
> so the new device will be probed, since PCI probe() is scheduled by
> work_on_cpu, then cause flush_work() called inside worker function,
> which might be a real deadlock.
So if I understand correct, you recommend to somehow avoid this nested probing?
> I am wondering why this commit can cause the problem, since the PCI
> device will be probed with its driver if there is one driver for it. There is no
> any limit on when the driver should be loaded into system, either before
> device is added or after.
FWIW to undertstanding the issue - the same driver (mlx4_core) is used
by the PF and VF, so the VF driver is already loaded at the time its
been added as new PCI device.
> From driver core view, looks no wrong things are found.
So this got me confused, you pointed on possible deadlock, are you
saying the deadlock wouldn't be the result of how the driver code is
going nor the commited we bisected?
Or.
^ 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