* pull request: wireless 2011-11-14
From: John W. Linville @ 2011-11-14 19:32 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 3.2. This includes an
mwifiex fix to enable association with "hidden" APs, a fix for avoiding
an unhandled RF kill interrupt when unloading iwlwifi, a NULL pointer
fix in the mac80211 radiotap code, a fix for ieee80211_build_probe_req
to pass-up a proper return code when ieee80211_probereq_get fails, a
race fix for mac80211 to avoid a WARNING in ieee80211_can_queue_work, a
NULL pointer fix in the cfg80211 regulatory code, and a fix for an
unaligned memory access in the libertas driver.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1e49570171117e547e6324c58371db4a0dc2f1db:
net: Fix references to deleted NET_ETHERNET Kconfig setting. (2011-11-09 19:26:53 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Amitkumar Karwar (1):
mwifiex: fix association issue with AP configured in hidden SSID mode
Emmanuel Grumbach (1):
iwlwifi: avoid a panic when unloading the module with RF Kill
Johannes Berg (3):
mac80211: fix NULL dereference in radiotap code
mac80211: fix bug in ieee80211_build_probe_req
mac80211: fix race between connection monitor & suspend
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Luis R. Rodriguez (1):
cfg80211: fix bug on regulatory core exit on access to last_request
Steven Miao (1):
wireless: libertas: fix unaligned le64 accesses
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 33 +++++++++++++------------
drivers/net/wireless/libertas/cfg.c | 2 +-
drivers/net/wireless/mwifiex/scan.c | 6 +++-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 9 ++++--
net/mac80211/util.c | 4 +++
net/wireless/reg.c | 3 ++
7 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
index da34110..ce91898 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -990,29 +990,16 @@ static int iwl_trans_tx_stop(struct iwl_trans *trans)
return 0;
}
-static void iwl_trans_pcie_disable_sync_irq(struct iwl_trans *trans)
+static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
{
unsigned long flags;
- struct iwl_trans_pcie *trans_pcie =
- IWL_TRANS_GET_PCIE_TRANS(trans);
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+ /* tell the device to stop sending interrupts */
spin_lock_irqsave(&trans->shrd->lock, flags);
iwl_disable_interrupts(trans);
spin_unlock_irqrestore(&trans->shrd->lock, flags);
- /* wait to make sure we flush pending tasklet*/
- synchronize_irq(bus(trans)->irq);
- tasklet_kill(&trans_pcie->irq_tasklet);
-}
-
-static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
-{
- /* stop and reset the on-board processor */
- iwl_write32(bus(trans), CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
-
- /* tell the device to stop sending interrupts */
- iwl_trans_pcie_disable_sync_irq(trans);
-
/* device going down, Stop using ICT table */
iwl_disable_ict(trans);
@@ -1039,6 +1026,20 @@ static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
/* Stop the device, and put it in low power state */
iwl_apm_stop(priv(trans));
+
+ /* Upon stop, the APM issues an interrupt if HW RF kill is set.
+ * Clean again the interrupt here
+ */
+ spin_lock_irqsave(&trans->shrd->lock, flags);
+ iwl_disable_interrupts(trans);
+ spin_unlock_irqrestore(&trans->shrd->lock, flags);
+
+ /* wait to make sure we flush pending tasklet*/
+ synchronize_irq(bus(trans)->irq);
+ tasklet_kill(&trans_pcie->irq_tasklet);
+
+ /* stop and reset the on-board processor */
+ iwl_write32(bus(trans), CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
}
static int iwl_trans_pcie_tx(struct iwl_trans *trans, struct sk_buff *skb,
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 4fcd653..a7f1ab2 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -634,7 +634,7 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned long dummy,
if (channel &&
!(channel->flags & IEEE80211_CHAN_DISABLED))
cfg80211_inform_bss(wiphy, channel,
- bssid, le64_to_cpu(*(__le64 *)tsfdesc),
+ bssid, get_unaligned_le64(tsfdesc),
capa, intvl, ie, ielen,
LBS_SCAN_RSSI_TO_MBM(rssi),
GFP_KERNEL);
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index 8a3f959..8d3ab37 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -819,8 +819,10 @@ mwifiex_scan_setup_scan_config(struct mwifiex_private *priv,
wildcard_ssid_tlv->header.len = cpu_to_le16(
(u16) (ssid_len + sizeof(wildcard_ssid_tlv->
max_ssid_length)));
- wildcard_ssid_tlv->max_ssid_length =
- user_scan_in->ssid_list[ssid_idx].max_len;
+
+ /* max_ssid_length = 0 tells firmware to perform
+ specific scan for the SSID filled */
+ wildcard_ssid_tlv->max_ssid_length = 0;
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[ssid_idx].ssid,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 234ffc2..b1b1bb3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2288,6 +2288,7 @@ void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
cancel_work_sync(&ifmgd->request_smps_work);
+ cancel_work_sync(&ifmgd->monitor_work);
cancel_work_sync(&ifmgd->beacon_connection_loss_work);
if (del_timer_sync(&ifmgd->timer))
set_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running);
@@ -2296,7 +2297,6 @@ void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
if (del_timer_sync(&ifmgd->chswitch_timer))
set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
- cancel_work_sync(&ifmgd->monitor_work);
/* these will just be re-established on connection */
del_timer_sync(&ifmgd->conn_mon_timer);
del_timer_sync(&ifmgd->bcn_mon_timer);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bb53726..fb123e2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -141,8 +141,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
pos++;
/* IEEE80211_RADIOTAP_RATE */
- if (status->flag & RX_FLAG_HT) {
+ if (!rate || status->flag & RX_FLAG_HT) {
/*
+ * Without rate information don't add it. If we have,
* MCS information is a separate field in radiotap,
* added below. The byte here is needed as padding
* for the channel though, so initialise it to 0.
@@ -163,12 +164,14 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
else if (status->flag & RX_FLAG_HT)
put_unaligned_le16(IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ,
pos);
- else if (rate->flags & IEEE80211_RATE_ERP_G)
+ else if (rate && rate->flags & IEEE80211_RATE_ERP_G)
put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
pos);
- else
+ else if (rate)
put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
pos);
+ else
+ put_unaligned_le16(IEEE80211_CHAN_2GHZ, pos);
pos += 2;
/* IEEE80211_RADIOTAP_DBM_ANTSIGNAL */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 51e256c..eca0fad 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -881,6 +881,8 @@ struct sk_buff *ieee80211_build_probe_req(struct ieee80211_sub_if_data *sdata,
skb = ieee80211_probereq_get(&local->hw, &sdata->vif,
ssid, ssid_len,
buf, buf_len);
+ if (!skb)
+ goto out;
if (dst) {
mgmt = (struct ieee80211_mgmt *) skb->data;
@@ -889,6 +891,8 @@ struct sk_buff *ieee80211_build_probe_req(struct ieee80211_sub_if_data *sdata,
}
IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+
+ out:
kfree(buf);
return skb;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 6acba9d..e71f5a6 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2265,6 +2265,9 @@ void /* __init_or_exit */ regulatory_exit(void)
kfree(last_request);
+ last_request = NULL;
+ dev_set_uevent_suppress(®_pdev->dev, true);
+
platform_device_unregister(reg_pdev);
spin_lock_bh(®_pending_beacons_lock);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 2/4] ipv4: Update pmtu informations on inetpeer only for output routes
From: David Miller @ 2011-11-14 19:33 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20111114101244.GB20943@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 14 Nov 2011 11:12:44 +0100
> So for the moment I'm thinking about adding an ip_dst_mtu()
> function that returns dst->ops->default_mtu() for input routes
> and dst_mtu() for output routes. Then we could convert the
> dst_mtu() users in net/ipv4/ over to this one.
We'll need something similar for ipv6 eventually...
I would suggest that we do away with dst_ops->default_mtu() and just
have dst_ops->mtu() which gets invoked unconditionally by dst_mtu().
You can integrate the ->default_mtu() handling and the input route
check into this new method. Then IPv6 can be fixed in a
straightforward manner later.
^ permalink raw reply
* Re: [PATCH RESUBMIT3 net-next 1/2] IPv6 routing, NLM_F_* flag support: warn if new route is created without NLM_F_CREATE
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1321265689.1858.27.camel@hakki>
From: Matti Vaittinen <matti.vaittinen@nsn.com>
Date: Mon, 14 Nov 2011 12:14:49 +0200
> The support for NLM_F_* flags at IPv6 routing requests.
>
> Warn if NLM_F_CREATE flag is not defined for RTM_NEWROUTE request,
> creating new table. Later NLM_F_CREATE may be required for
> new route creation.
>
> Patch created against linux-3.2-rc1
>
> Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH RESUBMIT3 net-next 2/2] IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1321265714.1858.28.camel@hakki>
From: Matti Vaittinen <matti.vaittinen@nsn.com>
Date: Mon, 14 Nov 2011 12:15:14 +0200
>
> The support for NLM_F_* flags at IPv6 routing requests.
>
> If NLM_F_CREATE flag is not defined for RTM_NEWROUTE request,
> warning is printed, but no error is returned. Instead new route is
> added. Later NLM_F_CREATE may be required for
> new route creation.
>
> Exception is when NLM_F_REPLACE flag is given without NLM_F_CREATE, and
> no matching route is found. In this case it should be safe to assume
> that the request issuer is familiar with NLM_F_* flags, and does really
> not want route to be created.
>
> Specifying NLM_F_REPLACE flag will now make the kernel to search for
> matching route, and replace it with new one. If no route is found and
> NLM_F_CREATE is specified as well, then new route is created.
>
> Also, specifying NLM_F_EXCL will yield returning of error if matching
> route is found.
>
> Patch created against linux-3.2-rc1
>
> Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: add endline at end of message
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: dmitry; +Cc: netdev
In-Reply-To: <1321260039-19254-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 14 Nov 2011 10:40:39 +0200
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv4: fix a memory leak in ic_bootp_send_if
From: David Miller @ 2011-11-14 19:38 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1321257248-14175-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Mon, 14 Nov 2011 15:54:08 +0800
> From: RongQing.Li <roy.qing.li@gmail.com>
>
> when dev_hard_header() failed, the newly allocated skb should be freed.
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH Kernel-3.1.0] mdio-gpio: Add reset functionality to mdio-gpio driver.
From: David Miller @ 2011-11-14 19:42 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: netdev, stuart.menefy
In-Reply-To: <1320845931-25782-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Wed, 9 Nov 2011 13:38:51 +0000
> + mdio_gpio_ops.reset = pdata->reset;
What if I have multiple types of devices backing a mdio_gpio, each using
different reset operations?
You can't write this variable method into a globally used set of ops.
^ permalink raw reply
* Re: pull request: wireless 2011-11-14
From: David Miller @ 2011-11-14 19:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111114193253.GA2499@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 14 Nov 2011 14:32:54 -0500
> Here is another batch of fixes intended for 3.2. This includes an
> mwifiex fix to enable association with "hidden" APs, a fix for avoiding
> an unhandled RF kill interrupt when unloading iwlwifi, a NULL pointer
> fix in the mac80211 radiotap code, a fix for ieee80211_build_probe_req
> to pass-up a proper return code when ieee80211_probereq_get fails, a
> race fix for mac80211 to avoid a WARNING in ieee80211_can_queue_work, a
> NULL pointer fix in the cfg80211 regulatory code, and a fix for an
> unaligned memory access in the libertas driver.
...
> The following changes since commit 1e49570171117e547e6324c58371db4a0dc2f1db:
>
> net: Fix references to deleted NET_ETHERNET Kconfig setting. (2011-11-09 19:26:53 -0500)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Pulled, thanks John!
^ permalink raw reply
* EMAIL FROM MARTIN BUSINESS PROPOSAL
From: Martin Robert Byrnes @ 2011-11-14 19:16 UTC (permalink / raw)
My name is Martin Robert Byrnes and I am a United States citizen. I was the
head storage keeper for the United Nations storage facility in Iraq for 6
years. During that time I was involved in some lucrative business deals with
Iraqi citizens.
Unfortunately I was transferred from Iraq before I was able to safely move my
money out of Iraq. Due to this I am in need of some assistance to move my
money to ensure that it is safe. I was transferred to Afghanistan which has
limited my ability to be able to move my money on my own. It is for this
reason that I writing to you to ask for your assistance.
To move forward together I am offering you a business proposal. In order for
your help in moving my money out of Iraq I am willing to offer you a
percentage
of the total money. The amounts involved in this proposal will be disclosed
once we have established an open dialogue together.
I appreciate your understanding and I know that I will hear from you
as soon as
possible as this proposal is time sensitive.
Martin Robert Byrnes
CW5 OD
(RET)
EMAIL: byrnesmartin2009@gmail.com
^ permalink raw reply
* RE: net: Add network priority cgroup
From: Shyam_Iyer @ 2011-11-14 20:02 UTC (permalink / raw)
To: nhorman; +Cc: dave.taht, netdev, john.r.fastabend, robert.w.love, davem
In-Reply-To: <20111114172404.GC27284@hmsreliant.think-freely.org>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Neil Horman
> Sent: Monday, November 14, 2011 12:24 PM
> Subject: Re: net: Add network priority cgroup
> > >
> > > On Mon, Nov 14, 2011 at 01:32:04PM +0100, Dave Taht wrote:
> > > > On Mon, Nov 14, 2011 at 12:47 PM, Neil Horman
> <nhorman@tuxdriver.com>
> > > wrote:
> > > > > On Wed, Nov 09, 2011 at 02:57:33PM -0500, Neil Horman wrote:
> > > > >> Data Center Bridging environments are currently somewhat
> limited
> > > in their
> > > > >> ability to provide a general mechanism for controlling traffic
> > > priority.
> > > > >> Specifically they are unable to administratively control the
> > > priority at which
> > > > >> various types of network traffic are sent.
> > > > >>
> > > > >> Currently, the only ways to set the priority of a network
> buffer
> > > are:
> > > > >>
> > > > >> 1) Through the use of the SO_PRIORITY socket option
> > > > >> 2) By using low level hooks, like a tc action
> > > > >>
> > > > >> (1) is difficult from an administrative perspective because it
> > > requires that the
> > > > >> application to be coded to not just assume the default
> priority is
> > > sufficient,
> > > > >> and must expose an administrative interface to allow priority
> > > adjustment. Such
> > > > >> a solution is not scalable in a DCB environment
> > > > >>
> > > > >> (2) is also difficult, as it requires constant administrative
> > > oversight of
> > > > >> applications so as to build appropriate rules to match traffic
> > > belonging to
> > > > >> various classes, so that priority can be appropriately set. It
> is
> > > further
> > > > >> limiting when DCB enabled hardware is in use, due to the fact
> that
> > > tc rules are
> > > > >> only run after a root qdisc has been selected (DCB enabled
> > > hardware may reserve
> > > > >> hw queues for various traffic classes and needs the priority
> to be
> > > set prior to
> > > > >> selecting the root qdisc)
> > > > >>
> > > > >>
> > > > >> I've discussed various solutions with John Fastabend, and we
> saw a
> > > cgroup as
> > > > >> being a good general solution to this problem. The network
> > > priority cgroup
> > > > >> allows for a per-interface priority map to be built per
> cgroup.
> > > Any traffic
> > > > >> originating from an application in a cgroup, that does not
> > > explicitly set its
> > > > >> priority with SO_PRIORITY will have its priority assigned to
> the
> > > value
> > > > >> designated for that group on that interface. This allows a
> user
> > > space daemon,
> > > > >> when conducting LLDP negotiation with a DCB enabled peer to
> create
> > > a cgroup
> > > > >> based on the APP_TLV value received and administratively
> assign
> > > applications to
> > > > >> that priority using the existing cgroup utility
> infrastructure.
> > > > >>
> > > > >> Tested by John and myself, with good results
> > > > >>
> > > > >> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > > >> CC: John Fastabend <john.r.fastabend@intel.com>
> > > > >> CC: Robert Love <robert.w.love@intel.com>
> > > > >> CC: "David S. Miller" <davem@davemloft.net>
> > > > >> --
> > > > >> 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
> > > > >>
> > > > >
> > > > > Bump, any other thoughts here? Dave T. has some reasonable
> > > thoughts regarding
> > > > > the use of skb->priority, but IMO they really seem orthogonal
> to
> > > the purpose of
> > > > > this change. Any other reviews would be welcome.
> > > >
> > > > Well, in part I've been playing catchup in the hope that lldp and
> > > > openlldp and/or this dcb netlink layer that I don't know anything
> > > > about (pointers please?) could help somehow to resolve the
> semantic
> > > > mess skb->priority has become in the first place.
> > > >
> > > > I liked what was described here.
> > > >
> > > > "What if we did at least carve out the DCB functionality away
> from
> > > > skb->priority? Since, AIUI, we're only concerning ourselves with
> > > > locally generated traffic here, we're talking
> > > > about skbs that have a socket attached to them. We could,
> instead of
> > > indexing
> > > > the prio_tc_map with skb->priority, we could index it with
> > > > skb->dev->priomap[skb->sk->prioidx] (as provided by this patch).
> The
> > > cgroup
> > > > then could be, instead of a strict priority cgroup, a
> queue_selector
> > > cgroup (or
> > > > something more appropriately named), and we don't have to touch
> skb-
> > > >priority at
> > > > all. I'd really rather not start down that road until I got more
> > > opinions and
> > > > consensus on that, but it seems like a pretty good solution, one
> that
> > > would
> > > > allow hardware queue selection in systems that use things like
> DCB to
> > > co-exist
> > > > with software queueing features."
> > > >
> > > I was initially ok with this, but the more I think about it, the
> more I
> > > think
> > > its just not needed (see further down in this email for my
> reasoning).
> > > John,
> > > Rob, do you have any thoughts here?
> > >
> > > > The piece that still kind of bothered me about the original
> proposal
> > > > (and perhaps this one) was that setting SO_PRIORITY in an app
> means
> > > > 'give my packets more mojo'.
> > > >
> > > > Taking something that took unprioritized packets and assigned
> them
> > > and
> > > > *them only* to a hardware queue struck me as possibly
> deprioritizing
> > > > the 'more mojo wanted' packets in the app(s), as they would end
> up in
> > > > some other, possibly overloaded, hardware queue.
> > > >
> > > I don't really see what you mean by this at all. Taking packets
> with
> > > no
> > > priority and assigning them a priority doesn't really have an
> effect on
> > > pre-prioritized packets. Or rather it shouldn't. You can
> certainly
> > > create a
> > > problem by having apps prioritized according to conflicting
> semantic
> > > rules, but
> > > that strikes me as administrative error. Garbage in...Garbage out.
> > >
> > > > So a cgroup that moves all of the packets from an application
> into a
> > > > given hardware queue, and then gets scheduled normally according
> to
> > > > skb->priority and friends (software queue, default of pfifo_fast,
> > > > etc), seems to make some sense to me. (I wouldn't mind if we had
> > > > abstractions for software queues, too, like, I need a software
> queue
> > > > with these properties, find me a place for it on the hardware -
> but
> > > > I'm dreaming)
> > > >
> > > > One open question is where do packets generated from other
> subsystems
> > > > end up, if you are using a cgroup for the app? arp, dns, etc?
> > > >
> > > The overriding rule is the association of an skb to a socket. If a
> > > transmitted
> > > frame has skb->sk set in dev_queue_xmit, then we interrogate its
> > > priority index
> > > as set when we passed through the sendmsg code at the top of the
> stack.
> > > Otherwise its behavior is unchanged from its current standpoint.
> > >
> > > > So to rephrase your original description from this:
> > > >
> > > > >> Any traffic originating from an application in a cgroup, that
> does
> > > not explicitly set its
> > > > >> priority with SO_PRIORITY will have its priority assigned to
> the
> > > value
> > > > >> designated for that group on that interface. This allows a
> user
> > > space daemon,
> > > > >> when conducting LLDP negotiation with a DCB enabled peer to
> create
> > > a cgroup
> > > > >> based on the APP_TLV value received and administratively
> assign
> > > applications to
> > > > >> that priority using the existing cgroup utility
> infrastructure.
> > > > > John, Robert, if you're supportive of these changes, some Acks
> > > would be
> > > > > appreciated.
> > > >
> > > > To this:
> > > >
> > > > "Any traffic originating from an application in a cgroup, will
> have
> > > > its hardware queue assigned to the value designated for that
> group
> > > on
> > > > that interface. This allows a user space daemon, when conducting
> > > LLDP
> > > > negotiation with a DCB enabled peer to create a cgroup based on
> the
> > > > APP_TLV value received and administratively assign applications
> to
> > > > that hardware queue using the existing cgroup utility
> > > infrastructure."
> > > >
> > > As above, I'm split brained about this. I'm ok with the idea of
> making
> > > this a
> > > queue selection cgroup, and separating it from priority, but at the
> > > same time,
> > > in the context of DCB, we really are assigning priority here, so it
> > > seems a bit
> > > false to do something that is not priority. I also like the fact
> that
> > > it
> > > provides administrative control in a way that netfilter and tc
> don't
> > > really
> > > enable.
> > >
> > > > Assuming we're on the same page here, what the heck is APP_TLV?
> > > >
> > > LLDP does layer 2 discovery with peer networking devices. It does
> so
> > > using sets
> > > of Type/length/value tuples. The types carry various bits of
> > > information, such
> > > as which priority groups are available on the network. The APP tlv
> > > conveys
> > > application or feature specific information. for instance, There
> is an
> > > ISCSI
> > > app tlv that tells the host that "on the interface you received
> this
> > > tlv, iscsi
> > > traffic must be sent at priority X". The idea being that, on
> receipt
> > > of this
> > > tlv, the DCB daemon can create an ISCSI network priority cgroup
> > > instance, and
> > > augment the cgroup rules file such that, when the user space iscsi
> > > daemon is
> > > started, its traffic automatically transmits at the appropriate
> > > priority.
> >
> > Love this !
> >
> > I guess if this is integrated to libvirt via libcgroups VMs could be
> assigned a network priority..
> >
> As the patch stand currently, absolutely. Just drop a qemu process
> into the
> approriate cgroup, and (assuming you're using a tun/tap type device),
> all the
> traffic from that vm will get assigned the corresponding priority. You
> can do
> the same thing with classification using net_cls already. I did a
> video of it
> here:
> http://www.youtube.com/watch?v=KX5QV4LId_c
Yes.. But I guess the present implementation allows iSCSI daemon to be grouped in an iSCSI network priority cgroup.
This is nicer since then we don't have to deal with a network cgroup + disk cgroup for the iSCSI use case.
Now.. since this is on the skb->priority I suspect this could become a per-session priority cgroup.
Is that the case or does the iscsid form just one cgroup?
> Neil
> > http://linuxplumbersconf.org/2010/ocw/proposals/843
> >
> >
> >
>
^ permalink raw reply
* Hitting BUG_ON() from napi_enable in e1000e
From: Mike McElroy @ 2011-11-14 19:37 UTC (permalink / raw)
To: netdev
Hitting the BUG_ON in napi_enable(). Code inspection shows that this can
only be triggered by calling napi_enable() twice without an intervening
napi_disable().
I saw the following sequence of events in the stack trace:
1) We simulated a cable pull using an Extreme switch.
2) e1000_tx_timeout() was entered.
3) e1000_reset_task() was called. Saw the message from e_err() in the
console log.
4) e1000_reinit_locked was called. This function calls e1000_down() and
e1000_up(). These functions call napi_disable() and napi_enable()
respectively.
5) Then on another thread, a monitor task saw carrier was down and
executed 'ip set link down' and 'ip set link up' commands.
6) Saw the '_E1000_RESETTING'warning fron the e1000_close function.
7) Either the e1000_open() executed between the e1000_down() and
e1000_up() calls in step 4 or the e1000_open() call executed after the
e0001_up() call. In either case, napi_enable() is called twice which
triggers the BUG_ON.
This code sequence is present in the e1000 driver also.
There are two bugs here:
1) The napi_enable() and napi_disable() should only be called in the
e1000_open and e1000_close functions respectively
2) There no synchronization preventing a call to the driver close while
executing error processing.
Here is a patch for the napi_enable BUG_ON:
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 5ec1f99..e1af6fa 100755
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4242,9 +4242,6 @@ int e1000e_up(struct e1000_adapter *adapter)
clear_bit(__E1000_DOWN, &adapter->state);
-#ifdef CONFIG_E1000E_NAPI
- napi_enable(&adapter->napi);
-#endif
#ifdef CONFIG_E1000E_MSIX
if (adapter->msix_entries)
e1000_configure_msix(adapter);
@@ -4307,10 +4304,6 @@ void e1000e_down(struct e1000_adapter *adapter)
/* flush both disables and wait for them to finish */
e1e_flush();
usleep_range(10000, 20000);
-
-#ifdef CONFIG_E1000E_NAPI
- napi_disable(&adapter->napi);
-#endif
e1000_irq_disable(adapter);
del_timer_sync(&adapter->watchdog_timer);
@@ -4677,6 +4670,10 @@ static int e1000_close(struct net_device *netdev)
pm_runtime_get_sync(&pdev->dev);
+#ifdef CONFIG_E1000E_NAPI
+ napi_disable(&adapter->napi);
+#endif
+
if (!test_bit(__E1000_DOWN, &adapter->state)) {
e1000e_down(adapter);
e1000_free_irq(adapter);
^ permalink raw reply related
* Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during fast recovery
From: David Miller @ 2011-11-14 20:23 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, ilpo.jarvinen, nanditad, ycheng, therbert
In-Reply-To: <1320775631-16341-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Tue, 8 Nov 2011 13:07:11 -0500
> (2) When the ACK field is below snd_una (the "old_ack" goto label),
> process any DSACKs and try to send out more packets based on
> newly-SACKed packets.
This seems dubious.
An older ACK should not have more uptodate SACK information than a newer
ACK.
^ permalink raw reply
* EMAIL FROM MARTIN BUSINESS PROPOSAL
From: Martin Robert Byrnes @ 2011-11-14 20:34 UTC (permalink / raw)
My name is Martin Robert Byrnes and I am a United States citizen. I was the
head storage keeper for the United Nations storage facility in Iraq for 6
years. During that time I was involved in some lucrative business deals with
Iraqi citizens.
Unfortunately I was transferred from Iraq before I was able to safely move my
money out of Iraq. Due to this I am in need of some assistance to move my
money to ensure that it is safe. I was transferred to Afghanistan which has
limited my ability to be able to move my money on my own. It is for this
reason that I writing to you to ask for your assistance.
To move forward together I am offering you a business proposal. In order for
your help in moving my money out of Iraq I am willing to offer you a
percentage
of the total money. The amounts involved in this proposal will be disclosed
once we have established an open dialogue together.
I appreciate your understanding and I know that I will hear from you
as soon as
possible as this proposal is time sensitive.
Martin Robert Byrnes
CW5 OD
(RET)
EMAIL: byrnesmartin2009@gmail.com
^ permalink raw reply
* Re: [3.1] Divide by zero in __tcp_select_window()
From: David Miller @ 2011-11-14 20:36 UTC (permalink / raw)
To: eric.dumazet
Cc: sim, tglx, netdev, a.p.zijlstra, linux-kernel, davej, schwidefsky,
mingo
In-Reply-To: <1320787405.26025.10.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Nov 2011 22:23:25 +0100
> OK, it seems we let a timer running while we free the socket (same error
> path than your previous bug report, because of the NULL route)
>
> We arm this keepalive timer in tcp_create_openreq_child()
>
> net/ipv4/tcp_minisocks.c:513
> if (sock_flag(newsk, SOCK_KEEPOPEN))
> inet_csk_reset_keepalive_timer(newsk,
> keepalive_time_when(newtp));
>
> I would try to add a call to tcp_clear_xmit_timers() as well
>
> Please try following patch :
We've been waiting quite some time to get some testing validation on
this patch, but I think it's correct.
Eric can you formally submit this? Thanks!
^ permalink raw reply
* EMAIL FROM MARTIN BUSINESS PROPOSAL
From: Martin Robert Byrnes @ 2011-11-14 20:44 UTC (permalink / raw)
My name is Martin Robert Byrnes and I am a United States citizen. I was the
head storage keeper for the United Nations storage facility in Iraq for 6
years. During that time I was involved in some lucrative business deals with
Iraqi citizens.
Unfortunately I was transferred from Iraq before I was able to safely move my
money out of Iraq. Due to this I am in need of some assistance to move my
money to ensure that it is safe. I was transferred to Afghanistan which has
limited my ability to be able to move my money on my own. It is for this
reason that I writing to you to ask for your assistance.
To move forward together I am offering you a business proposal. In order for
your help in moving my money out of Iraq I am willing to offer you a
percentage
of the total money. The amounts involved in this proposal will be disclosed
once we have established an open dialogue together.
I appreciate your understanding and I know that I will hear from you
as soon as
possible as this proposal is time sensitive.
Martin Robert Byrnes
CW5 OD
(RET)
EMAIL: byrnesmartin2009@gmail.com
^ permalink raw reply
* Re: [3.1] Divide by zero in __tcp_select_window()
From: Simon Kirby @ 2011-11-14 20:44 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, tglx, netdev, a.p.zijlstra, linux-kernel, davej,
schwidefsky, mingo
In-Reply-To: <20111114.153608.2064552703690099046.davem@davemloft.net>
On Mon, Nov 14, 2011 at 03:36:08PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 08 Nov 2011 22:23:25 +0100
>
> > OK, it seems we let a timer running while we free the socket (same error
> > path than your previous bug report, because of the NULL route)
> >
> > We arm this keepalive timer in tcp_create_openreq_child()
> >
> > net/ipv4/tcp_minisocks.c:513
> > if (sock_flag(newsk, SOCK_KEEPOPEN))
> > inet_csk_reset_keepalive_timer(newsk,
> > keepalive_time_when(newtp));
> >
> > I would try to add a call to tcp_clear_xmit_timers() as well
> >
> > Please try following patch :
>
> We've been waiting quite some time to get some testing validation on
> this patch, but I think it's correct.
>
> Eric can you formally submit this? Thanks!
Sorry, I'm still testing slowly, with the "crash into the new kernel"
method. :) I'll reboot the rest shortly, but so far no recurrences on
boxes running with this fix, and no other problems noted with it applied.
Simon-
^ permalink raw reply
* Re: net: Add network priority cgroup
From: Neil Horman @ 2011-11-14 20:56 UTC (permalink / raw)
To: Shyam_Iyer; +Cc: dave.taht, netdev, john.r.fastabend, robert.w.love, davem
In-Reply-To: <DBFB1B45AF80394ABD1C807E9F28D157077D7D8E83@BLRX7MCDC203.AMER.DELL.COM>
On Mon, Nov 14, 2011 at 12:02:59PM -0800, Shyam_Iyer@Dell.com wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Neil Horman
> > Sent: Monday, November 14, 2011 12:24 PM
> > Subject: Re: net: Add network priority cgroup
> > > >
> > > > On Mon, Nov 14, 2011 at 01:32:04PM +0100, Dave Taht wrote:
> > > > > On Mon, Nov 14, 2011 at 12:47 PM, Neil Horman
> > <nhorman@tuxdriver.com>
> > > > wrote:
> > > > > > On Wed, Nov 09, 2011 at 02:57:33PM -0500, Neil Horman wrote:
> > > > > >> Data Center Bridging environments are currently somewhat
> > limited
> > > > in their
> > > > > >> ability to provide a general mechanism for controlling traffic
> > > > priority.
> > > > > >> Specifically they are unable to administratively control the
> > > > priority at which
> > > > > >> various types of network traffic are sent.
> > > > > >>
> > > > > >> Currently, the only ways to set the priority of a network
> > buffer
> > > > are:
> > > > > >>
> > > > > >> 1) Through the use of the SO_PRIORITY socket option
> > > > > >> 2) By using low level hooks, like a tc action
> > > > > >>
> > > > > >> (1) is difficult from an administrative perspective because it
> > > > requires that the
> > > > > >> application to be coded to not just assume the default
> > priority is
> > > > sufficient,
> > > > > >> and must expose an administrative interface to allow priority
> > > > adjustment. Such
> > > > > >> a solution is not scalable in a DCB environment
> > > > > >>
> > > > > >> (2) is also difficult, as it requires constant administrative
> > > > oversight of
> > > > > >> applications so as to build appropriate rules to match traffic
> > > > belonging to
> > > > > >> various classes, so that priority can be appropriately set. It
> > is
> > > > further
> > > > > >> limiting when DCB enabled hardware is in use, due to the fact
> > that
> > > > tc rules are
> > > > > >> only run after a root qdisc has been selected (DCB enabled
> > > > hardware may reserve
> > > > > >> hw queues for various traffic classes and needs the priority
> > to be
> > > > set prior to
> > > > > >> selecting the root qdisc)
> > > > > >>
> > > > > >>
> > > > > >> I've discussed various solutions with John Fastabend, and we
> > saw a
> > > > cgroup as
> > > > > >> being a good general solution to this problem. The network
> > > > priority cgroup
> > > > > >> allows for a per-interface priority map to be built per
> > cgroup.
> > > > Any traffic
> > > > > >> originating from an application in a cgroup, that does not
> > > > explicitly set its
> > > > > >> priority with SO_PRIORITY will have its priority assigned to
> > the
> > > > value
> > > > > >> designated for that group on that interface. This allows a
> > user
> > > > space daemon,
> > > > > >> when conducting LLDP negotiation with a DCB enabled peer to
> > create
> > > > a cgroup
> > > > > >> based on the APP_TLV value received and administratively
> > assign
> > > > applications to
> > > > > >> that priority using the existing cgroup utility
> > infrastructure.
> > > > > >>
> > > > > >> Tested by John and myself, with good results
> > > > > >>
> > > > > >> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > > > >> CC: John Fastabend <john.r.fastabend@intel.com>
> > > > > >> CC: Robert Love <robert.w.love@intel.com>
> > > > > >> CC: "David S. Miller" <davem@davemloft.net>
> > > > > >> --
> > > > > >> 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
> > > > > >>
> > > > > >
> > > > > > Bump, any other thoughts here? Dave T. has some reasonable
> > > > thoughts regarding
> > > > > > the use of skb->priority, but IMO they really seem orthogonal
> > to
> > > > the purpose of
> > > > > > this change. Any other reviews would be welcome.
> > > > >
> > > > > Well, in part I've been playing catchup in the hope that lldp and
> > > > > openlldp and/or this dcb netlink layer that I don't know anything
> > > > > about (pointers please?) could help somehow to resolve the
> > semantic
> > > > > mess skb->priority has become in the first place.
> > > > >
> > > > > I liked what was described here.
> > > > >
> > > > > "What if we did at least carve out the DCB functionality away
> > from
> > > > > skb->priority? Since, AIUI, we're only concerning ourselves with
> > > > > locally generated traffic here, we're talking
> > > > > about skbs that have a socket attached to them. We could,
> > instead of
> > > > indexing
> > > > > the prio_tc_map with skb->priority, we could index it with
> > > > > skb->dev->priomap[skb->sk->prioidx] (as provided by this patch).
> > The
> > > > cgroup
> > > > > then could be, instead of a strict priority cgroup, a
> > queue_selector
> > > > cgroup (or
> > > > > something more appropriately named), and we don't have to touch
> > skb-
> > > > >priority at
> > > > > all. I'd really rather not start down that road until I got more
> > > > opinions and
> > > > > consensus on that, but it seems like a pretty good solution, one
> > that
> > > > would
> > > > > allow hardware queue selection in systems that use things like
> > DCB to
> > > > co-exist
> > > > > with software queueing features."
> > > > >
> > > > I was initially ok with this, but the more I think about it, the
> > more I
> > > > think
> > > > its just not needed (see further down in this email for my
> > reasoning).
> > > > John,
> > > > Rob, do you have any thoughts here?
> > > >
> > > > > The piece that still kind of bothered me about the original
> > proposal
> > > > > (and perhaps this one) was that setting SO_PRIORITY in an app
> > means
> > > > > 'give my packets more mojo'.
> > > > >
> > > > > Taking something that took unprioritized packets and assigned
> > them
> > > > and
> > > > > *them only* to a hardware queue struck me as possibly
> > deprioritizing
> > > > > the 'more mojo wanted' packets in the app(s), as they would end
> > up in
> > > > > some other, possibly overloaded, hardware queue.
> > > > >
> > > > I don't really see what you mean by this at all. Taking packets
> > with
> > > > no
> > > > priority and assigning them a priority doesn't really have an
> > effect on
> > > > pre-prioritized packets. Or rather it shouldn't. You can
> > certainly
> > > > create a
> > > > problem by having apps prioritized according to conflicting
> > semantic
> > > > rules, but
> > > > that strikes me as administrative error. Garbage in...Garbage out.
> > > >
> > > > > So a cgroup that moves all of the packets from an application
> > into a
> > > > > given hardware queue, and then gets scheduled normally according
> > to
> > > > > skb->priority and friends (software queue, default of pfifo_fast,
> > > > > etc), seems to make some sense to me. (I wouldn't mind if we had
> > > > > abstractions for software queues, too, like, I need a software
> > queue
> > > > > with these properties, find me a place for it on the hardware -
> > but
> > > > > I'm dreaming)
> > > > >
> > > > > One open question is where do packets generated from other
> > subsystems
> > > > > end up, if you are using a cgroup for the app? arp, dns, etc?
> > > > >
> > > > The overriding rule is the association of an skb to a socket. If a
> > > > transmitted
> > > > frame has skb->sk set in dev_queue_xmit, then we interrogate its
> > > > priority index
> > > > as set when we passed through the sendmsg code at the top of the
> > stack.
> > > > Otherwise its behavior is unchanged from its current standpoint.
> > > >
> > > > > So to rephrase your original description from this:
> > > > >
> > > > > >> Any traffic originating from an application in a cgroup, that
> > does
> > > > not explicitly set its
> > > > > >> priority with SO_PRIORITY will have its priority assigned to
> > the
> > > > value
> > > > > >> designated for that group on that interface. This allows a
> > user
> > > > space daemon,
> > > > > >> when conducting LLDP negotiation with a DCB enabled peer to
> > create
> > > > a cgroup
> > > > > >> based on the APP_TLV value received and administratively
> > assign
> > > > applications to
> > > > > >> that priority using the existing cgroup utility
> > infrastructure.
> > > > > > John, Robert, if you're supportive of these changes, some Acks
> > > > would be
> > > > > > appreciated.
> > > > >
> > > > > To this:
> > > > >
> > > > > "Any traffic originating from an application in a cgroup, will
> > have
> > > > > its hardware queue assigned to the value designated for that
> > group
> > > > on
> > > > > that interface. This allows a user space daemon, when conducting
> > > > LLDP
> > > > > negotiation with a DCB enabled peer to create a cgroup based on
> > the
> > > > > APP_TLV value received and administratively assign applications
> > to
> > > > > that hardware queue using the existing cgroup utility
> > > > infrastructure."
> > > > >
> > > > As above, I'm split brained about this. I'm ok with the idea of
> > making
> > > > this a
> > > > queue selection cgroup, and separating it from priority, but at the
> > > > same time,
> > > > in the context of DCB, we really are assigning priority here, so it
> > > > seems a bit
> > > > false to do something that is not priority. I also like the fact
> > that
> > > > it
> > > > provides administrative control in a way that netfilter and tc
> > don't
> > > > really
> > > > enable.
> > > >
> > > > > Assuming we're on the same page here, what the heck is APP_TLV?
> > > > >
> > > > LLDP does layer 2 discovery with peer networking devices. It does
> > so
> > > > using sets
> > > > of Type/length/value tuples. The types carry various bits of
> > > > information, such
> > > > as which priority groups are available on the network. The APP tlv
> > > > conveys
> > > > application or feature specific information. for instance, There
> > is an
> > > > ISCSI
> > > > app tlv that tells the host that "on the interface you received
> > this
> > > > tlv, iscsi
> > > > traffic must be sent at priority X". The idea being that, on
> > receipt
> > > > of this
> > > > tlv, the DCB daemon can create an ISCSI network priority cgroup
> > > > instance, and
> > > > augment the cgroup rules file such that, when the user space iscsi
> > > > daemon is
> > > > started, its traffic automatically transmits at the appropriate
> > > > priority.
> > >
> > > Love this !
> > >
> > > I guess if this is integrated to libvirt via libcgroups VMs could be
> > assigned a network priority..
> > >
> > As the patch stand currently, absolutely. Just drop a qemu process
> > into the
> > approriate cgroup, and (assuming you're using a tun/tap type device),
> > all the
> > traffic from that vm will get assigned the corresponding priority. You
> > can do
> > the same thing with classification using net_cls already. I did a
> > video of it
> > here:
> > http://www.youtube.com/watch?v=KX5QV4LId_c
>
> Yes.. But I guess the present implementation allows iSCSI daemon to be grouped in an iSCSI network priority cgroup.
> This is nicer since then we don't have to deal with a network cgroup + disk cgroup for the iSCSI use case.
>
Thats my understanding, yes.
> Now.. since this is on the skb->priority I suspect this could become a per-session priority cgroup.
>
Correct.
> Is that the case or does the iscsid form just one cgroup?
>
The cgroups are actually formed by administrative tools like dcbx/lldapd/etc.
Placement into appropriate cgroups is then handled by appropriate configuration
of cgroups.conf (which may be done administratively by hand, or by the
aforementinoed utilities). So iscsid, when started, would be assigned the
appropriate cgroup by virtue of said configuration file.
Neil
> > Neil
> > > http://linuxplumbersconf.org/2010/ocw/proposals/843
> > >
> > >
> > >
> >
> --
> 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
* Re: [3.1] Divide by zero in __tcp_select_window()
From: Eric Dumazet @ 2011-11-14 20:56 UTC (permalink / raw)
To: David Miller
Cc: sim, tglx, netdev, a.p.zijlstra, linux-kernel, davej, schwidefsky,
mingo
In-Reply-To: <20111114.153608.2064552703690099046.davem@davemloft.net>
Le lundi 14 novembre 2011 à 15:36 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 08 Nov 2011 22:23:25 +0100
>
> > OK, it seems we let a timer running while we free the socket (same error
> > path than your previous bug report, because of the NULL route)
> >
> > We arm this keepalive timer in tcp_create_openreq_child()
> >
> > net/ipv4/tcp_minisocks.c:513
> > if (sock_flag(newsk, SOCK_KEEPOPEN))
> > inet_csk_reset_keepalive_timer(newsk,
> > keepalive_time_when(newtp));
> >
> > I would try to add a call to tcp_clear_xmit_timers() as well
> >
> > Please try following patch :
>
> We've been waiting quite some time to get some testing validation on
> this patch, but I think it's correct.
>
> Eric can you formally submit this? Thanks!
Sure, here it is.
Please Simon feel free to add your "Tested-by" signature
Thanks
[PATCH] tcp: clear xmit timers in tcp_v4_syn_recv_sock()
Simon Kirby reported divides by zero errors in __tcp_select_window()
This happens when inet_csk_route_child_sock() returns a NULL pointer :
We free new socket while we eventually armed keepalive timer in
tcp_create_openreq_child()
Fix this by a call to tcp_clear_xmit_timers()
[ This is a followup to commit 918eb39962dff (net: add missing
bh_unlock_sock() calls) ]
Reported-by: Simon Kirby <sim@hostway.ca>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_ipv4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a744315..a9db4b1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1510,6 +1510,7 @@ exit:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return NULL;
put_and_exit:
+ tcp_clear_xmit_timers(newsk);
bh_unlock_sock(newsk);
sock_put(newsk);
goto exit;
^ permalink raw reply related
* Re: [PATCH] net: fsl_pq_mdio: fix non tbi phy access
From: Fleming Andy-AFLEMING @ 2011-11-14 21:04 UTC (permalink / raw)
To: Baruch Siach; +Cc: netdev@vger.kernel.org, Baruch Siach
In-Reply-To: <b693b45a689d42b60a8a9e29dcdd2fb27e20df82.1321251618.git.baruch@tkos.co.il>
Well, this got applied quickly, so I guess I can't NAK, but this requires discussion.
On Nov 14, 2011, at 0:22, "Baruch Siach" <baruch@tkos.co.il> wrote:
> Since 952c5ca1 (fsl_pq_mdio: Clean up tbi address configuration) .probe returns
> -EBUSY when the "tbi-phy" node is missing. Fix this.
It returns an error because it finds no tbi node. Because without the tbi node, there is no way for the driver to determine which address to set.
Your solution is to ignore the error, and hope. That's a broken approach. The real solution for a p1010 should be to have a tbi node in the dts.
And looking at the p1010si.dtsi, I see that it's automatically there for you.
How were you breaking?
Andy
^ permalink raw reply
* Re: tc: deleting single entry from filter hashtable
From: Miroslav Kratochvil @ 2011-11-14 21:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1321287325.2272.52.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
> > Question: Is the single deletion/modification possible? If not --
> > judging from the lack of the documentation on given subject I kindof
> > expect that it's not possible -- is there any other possibility to
> > delete at least some reasonably small subset of the hash table that
> > could be modified and recreated quickly?
>
> Not sure I understand the exact problem, but it is possible to delete a
> single filter, and add a new one.
>
That would be nice! Could you possibly show me an exact command to
remove one specific filter from the hash table? (In last post you only
demonstrated adding, which works for me, and I have problems exactly
at constructing a deletion command..)
Thanks in advance,
-mk
^ permalink raw reply
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-11-14 21:35 UTC (permalink / raw)
To: Andy Gospodarek
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka, ivecera
In-Reply-To: <20111114171840.GD20605@gospo.rdu.redhat.com>
Mon, Nov 14, 2011 at 06:18:40PM CET, andy@greyhouse.net wrote:
>On Sat, Nov 12, 2011 at 09:16:48AM +0100, Jiri Pirko wrote:
>> This patch introduces new network device called team. It supposes to be
>> very fast, simple, userspace-driven alternative to existing bonding
>> driver.
>>
>> Userspace library called libteam with couple of demo apps is available
>> here:
>> https://github.com/jpirko/libteam
>> Note it's still in its dipers atm.
>>
>> team<->libteam use generic netlink for communication. That and rtnl
>> suppose to be the only way to configure team device, no sysfs etc.
>>
>> Python binding of libteam was recently introduced.
>> Daemon providing arpmon/miimon active-backup functionality will be
>> introduced shortly. All what's necessary is already implemented in
>> kernel team driver.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> v7->v8:
>> - check ndo_ndo_vlan_rx_[add/kill]_vid functions before calling
>> them.
>> - use dev_kfree_skb_any() instead of dev_kfree_skb()
>>
>> v6->v7:
>> - transmit and receive functions are not checked in hot paths.
>> That also resolves memory leak on transmit when no port is
>> present
>>
>> v5->v6:
>> - changed couple of _rcu calls to non _rcu ones in non-readers
>>
>> v4->v5:
>> - team_change_mtu() uses team->lock while travesing though port
>> list
>> - mac address changes are moved completely to jurisdiction of
>> userspace daemon. This way the daemon can do FOM1, FOM2 and
>> possibly other weird things with mac addresses.
>> Only round-robin mode sets up all ports to bond's address then
>> enslaved.
>> - Extended Kconfig text
>>
>> v3->v4:
>> - remove redundant synchronize_rcu from __team_change_mode()
>> - revert "set and clear of mode_ops happens per pointer, not per
>> byte"
>> - extend comment of function __team_change_mode()
>>
>> v2->v3:
>> - team_change_mtu() uses rcu version of list traversal to unwind
>> - set and clear of mode_ops happens per pointer, not per byte
>> - port hashlist changed to be embedded into team structure
>> - error branch in team_port_enter() does cleanup now
>> - fixed rtln->rtnl
>>
>> v1->v2:
>> - modes are made as modules. Makes team more modular and
>> extendable.
>> - several commenters' nitpicks found on v1 were fixed
>> - several other bugs were fixed.
>> - note I ignored Eric's comment about roundrobin port selector
>> as Eric's way may be easily implemented as another mode (mode
>> "random") in future.
>
>You better get ready for v9.
>
>Running the command:
>
># team_manual_control team0 set mode roundrobin
>
>on a system with team0 running in roundrobin mode produces this:
>
>[ 2127.785321] BUG: unable to handle kernel NULL pointer dereference at (null)
>[ 2127.788079] IP: [<ffffffffa0196edd>] team_nl_fill_options_get_changed+0xc5/0x240 [team]
>[ 2127.790847] PGD 13eecf067 PUD 13f758067 PMD 0
>[ 2127.793603] Oops: 0000 [#1] SMP
>[ 2127.796352] CPU 7
>[ 2127.796370] Modules linked in: team_mode_roundrobin(O) team(O) fcoe libfcoe libfc scsi_transport_fc scsi_tgt 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_state nf_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device i2c_i801 joydev microcode shpchp snd_pcm snd_timer snd soundcore snd_page_alloc bnx2 iTCO_wdt iTCO_vendor_support e1000e uinput firewire_ohci firewire_core crc_itu_t i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: nf_defrag_ipv4]
>[ 2127.808223]
>[ 2127.811261] Pid: 7085, comm: team_manual_con Tainted: G O 3.2.0-rc1+ #1 Intel Corporation 2012 Client Platform/LosLunas CRB
>[ 2127.814421] RIP: 0010:[<ffffffffa0196edd>] [<ffffffffa0196edd>] team_nl_fill_options_get_changed+0xc5/0x240 [team]
>[ 2127.817597] RSP: 0018:ffff88012ec3d968 EFLAGS: 00010286
>[ 2127.820758] RAX: 0000000000000000 RBX: ffff8801397bb600 RCX: ffffffffffffffff
>[ 2127.823947] RDX: ffff88013f4ba048 RSI: 0000000000000000 RDI: 0000000000000000
>[ 2127.827154] RBP: ffff88012ec3d9c8 R08: ffff88013f4ba048 R09: 0000000000000004
>[ 2127.830365] R10: 0000000000001bad R11: 0000000000000000 R12: ffff880143a8b740
>[ 2127.833599] R13: ffff880143aca7e8 R14: ffff88013f4ba014 R15: ffff88013f4ba048
>[ 2127.836838] FS: 00007fd65cdc8700(0000) GS:ffff88014e2e0000(0000) knlGS:0000000000000000
>[ 2127.840102] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 2127.843386] CR2: 0000000000000000 CR3: 0000000128531000 CR4: 00000000001406e0
>[ 2127.846688] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>[ 2127.849987] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>[ 2127.853278] Process team_manual_con (pid: 7085, threadinfo ffff88012ec3c000, task ffff88013e842e40)
>[ 2127.856605] Stack:
>[ 2127.859898] 0000000000000000 ffff880143a8b7e8 0000000000000000 ffff88013f4ba01c
>[ 2127.863261] ffffffffa0019140 0000000500000000 0000000000000000 ffff8801397bb600
>[ 2127.866623] ffff88012ec3da58 ffffffffa0197058 ffff880143a8b740 00000000fffffff4
>[ 2127.869993] Call Trace:
>[ 2127.873344] [<ffffffffa0197058>] ? team_nl_fill_options_get_changed+0x240/0x240 [team]
>[ 2127.876750] [<ffffffffa0197078>] team_nl_fill_options_get+0x20/0x22 [team]
>[ 2127.880152] [<ffffffffa019763c>] team_nl_send_generic+0x41/0x85 [team]
>[ 2127.880156] [<ffffffffa01976f5>] team_nl_cmd_options_get+0x36/0x3f [team]
>[ 2127.880162] [<ffffffff813fbdce>] genl_rcv_msg+0x1d8/0x203
>[ 2127.880165] [<ffffffff813fbbf6>] ? genl_rcv+0x2d/0x2d
>[ 2127.880169] [<ffffffff813fb7b2>] netlink_rcv_skb+0x42/0x8d
>[ 2127.880172] [<ffffffff813fbbef>] genl_rcv+0x26/0x2d
>[ 2127.880174] [<ffffffff813fb341>] netlink_unicast+0xec/0x156
>[ 2127.880178] [<ffffffff813fb5a6>] netlink_sendmsg+0x1fb/0x233
>[ 2127.880182] [<ffffffff813ca577>] sock_sendmsg+0xe6/0x109
>[ 2127.880188] [<ffffffff81120c76>] ? __mem_cgroup_commit_charge+0x9d/0xa9
>[ 2127.880192] [<ffffffff8112333b>] ? mem_cgroup_charge_common+0xb1/0xc3
>[ 2127.880197] [<ffffffff81043ff5>] ? should_resched+0xe/0x2d
>[ 2127.880203] [<ffffffff814b6208>] ? _cond_resched+0xe/0x22
>[ 2127.880206] [<ffffffff81043ff5>] ? should_resched+0xe/0x2d
>[ 2127.880209] [<ffffffff813d4433>] ? copy_from_user+0x2f/0x31
>[ 2127.880212] [<ffffffff813d481e>] ? verify_iovec+0x52/0xa4
>[ 2127.880215] [<ffffffff813ca85c>] __sys_sendmsg+0x213/0x2ba
>[ 2127.880220] [<ffffffff810fb1eb>] ? handle_mm_fault+0x1c8/0x1db
>[ 2127.880224] [<ffffffff814bab67>] ? do_page_fault+0x30c/0x37e
>[ 2127.880228] [<ffffffff814b7914>] ? _raw_spin_unlock_irqrestore+0x17/0x19
>[ 2127.880232] [<ffffffff81045079>] ? __wake_up+0x44/0x4d
>[ 2127.880235] [<ffffffff813cc459>] sys_sendmsg+0x42/0x60
>[ 2127.880239] [<ffffffff814be042>] system_call_fastpath+0x16/0x1b
>[ 2127.880241] Code: e9 24 01 00 00 be 01 00 00 00 48 89 df e8 aa f3 ff ff 48 85 c0 49 89 c7 0f 84 4b 01 00 00 49 8b 75 10 31 c0 48 83 c9 ff 48 89 f7 <f2> ae 48 89 df 89 ca 48 89 f1 be 01 00 00 00 f7 d2 e8 2f 4c 0a
>[ 2127.880263] RIP [<ffffffffa0196edd>] team_nl_fill_options_get_changed+0xc5/0x240 [team]
>[ 2127.880268] RSP <ffff88012ec3d968>
>[ 2127.880269] CR2: 0000000000000000
>[ 2127.880287] ---[ end trace 3e104c6acd231d26 ]---
>
>Can you provide a detailed report of the testing you have done on the
>team device? It seems proper testing would have found something like
>this.
I just encountered the same bug now. Goind to investigate this. Did not
happen during my previous testing :( Sorry Andy.
Jirka
>
^ permalink raw reply
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-11-14 21:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andy Gospodarek, David Miller, netdev, bhutchings, shemminger,
fubar, tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka, ivecera
In-Reply-To: <1321294672.2719.9.camel@edumazet-laptop>
Mon, Nov 14, 2011 at 07:17:52PM CET, eric.dumazet@gmail.com wrote:
>Le lundi 14 novembre 2011 à 12:31 -0500, Andy Gospodarek a écrit :
>
>> I'm a bit surprised by this. Not only is this new function currently
>> difficult to setup (it took me over an hour to go from a a fresh F16
>> install to one that had all the necessary libraries and tools to even
>> configure a team device for the first time), but I was able to cause an
>> Oops with v8 in only a few minutes of testing.
>>
>> I have no problem with this functionality as an add-on and possibly
>> future replacement to some of what currently exists with bonding, but it
>> seems like what is included in the initial support should should:
>>
>> 1. Not panic easily.
>> 2. Have userspace bits in place to actually test all the proposed kernel
>> code. (Jiri admits there is no way to verify the active-backup code).
>> 3. Have some known, published test results.
>>
>> I hope Jiri will reconsider having a separate team tree for the next few
>> weeks or months until these issues are worked out. I think the hard
>> work will pay off and it is close to being ready; it just doesn't seem
>> like it is right now.
>>
>
>Its marked EXPERIMENTAL, so probably some changes are expected before
>production mode :)
Exactly. The primary goal was to get this broader audience so people
use this and find bugs, like you did Andy :)
>
>
>
^ permalink raw reply
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-11-14 21:51 UTC (permalink / raw)
To: Rick Jones
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka, ivecera
In-Reply-To: <4EC160B4.2040709@hp.com>
Mon, Nov 14, 2011 at 07:40:52PM CET, rick.jones2@hp.com wrote:
>On 11/12/2011 12:16 AM, Jiri Pirko wrote:
>>This patch introduces new network device called team. It supposes to be
>>very fast, simple, userspace-driven alternative to existing bonding
>>driver.
>
>What is the definition of "very" here - relative to bonding I
>presume? Are there actual performance figures available at this
>point? Something along the lines of test through both on the same
>hardware. I don't have HW on which to run myself but would be quite
>happy to help with say netperf command selection to demonstrate the
>difference between the two.
Rick, I will provide this.
But the simple fact how bond and team path differ suggests the results.
Stay tuned.
Jirka
>
>happy benchmrking,
>
>rick jones
^ permalink raw reply
* [RFC PATCH net-next] enable virtio_net to return bus_info in ethtool -i consistent with emulated NICs
From: Rick Jones @ 2011-11-14 21:52 UTC (permalink / raw)
To: netdev, Rusty Russell, Michael Tsirkin, virtualization
From: Rick Jones <rick.jones2@hp.com>
Add a new .bus_name to virtio_config_ops then modify virtio_net to
call through to it in an ethtool .get_drvinfo routine to report
bus_info in ethtool -i output which is consistent with other
emulated NICs and the output of lspci.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
The changes to drivers/lguest/lguest_device.c, drivers/s390/kvm/kvm_virtio.c,
and drivers/virtio/virtio_mmio.c code inspected only, not compiled.
raj@raj-ubuntu-guest:~$ ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
bus-info: 0000:00:03.0
raj@raj-ubuntu-guest:~$ lspci | grep Ether
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
drivers/lguest/lguest_device.c | 6 ++++++
drivers/net/virtio_net.c | 15 +++++++++++++++
drivers/s390/kvm/kvm_virtio.c | 6 ++++++
drivers/virtio/virtio_mmio.c | 6 ++++++
drivers/virtio/virtio_pci.c | 8 ++++++++
include/linux/virtio_config.h | 14 ++++++++++++++
6 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
index 0dc30ff..3724d45 100644
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
@@ -381,6 +381,11 @@ error:
return PTR_ERR(vqs[i]);
}
+static const char *lg_bus_name(struct virtio_device *vdev)
+{
+ return "Not Implemented";
+}
+
/* The ops structure which hooks everything together. */
static struct virtio_config_ops lguest_config_ops = {
.get_features = lg_get_features,
@@ -392,6 +397,7 @@ static struct virtio_config_ops lguest_config_ops = {
.reset = lg_reset,
.find_vqs = lg_find_vqs,
.del_vqs = lg_del_vqs,
+ .bus_name = lg_bus_name,
};
/*
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6ee8410..4dc9d84 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -39,6 +39,7 @@ module_param(gso, bool, 0444);
#define GOOD_COPY_LEN 128
#define VIRTNET_SEND_COMMAND_SG_MAX 2
+#define VIRTNET_DRIVER_VERSION "1.0.0"
struct virtnet_stats {
struct u64_stats_sync syncp;
@@ -889,7 +890,21 @@ static void virtnet_get_ringparam(struct net_device *dev,
}
+
+static void virtnet_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct virtio_device *vdev = vi->vdev;
+
+ strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
+ strlcpy(info->version, VIRTNET_DRIVER_VERSION, sizeof(info->version));
+ strlcpy(info->bus_info, virtio_bus_name(vdev), sizeof(info->bus_info));
+
+}
+
static const struct ethtool_ops virtnet_ethtool_ops = {
+ .get_drvinfo = virtnet_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ringparam = virtnet_get_ringparam,
};
diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 94f49ff..725d90e 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -263,6 +263,11 @@ error:
return PTR_ERR(vqs[i]);
}
+static const char *kvm_bus_name(struct virtio_device *vdev)
+{
+ return "Not Implemented";
+}
+
/*
* The config ops structure as defined by virtio config
*/
@@ -276,6 +281,7 @@ static struct virtio_config_ops kvm_vq_configspace_ops = {
.reset = kvm_reset,
.find_vqs = kvm_find_vqs,
.del_vqs = kvm_del_vqs,
+ .bus_name = kvm_bus_name,
};
/*
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index acc5e43..2f57380 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -361,7 +361,12 @@ static int vm_find_vqs(struct virtio_device *vdev, unsigned nvqs,
return 0;
}
+static const char *vm_bus_name(struct virtio_device *vdev)
+{
+ struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
+ return vm_dev->pdev->name;
+}
static struct virtio_config_ops virtio_mmio_config_ops = {
.get = vm_get,
@@ -373,6 +378,7 @@ static struct virtio_config_ops virtio_mmio_config_ops = {
.del_vqs = vm_del_vqs,
.get_features = vm_get_features,
.finalize_features = vm_finalize_features,
+ .bus_name = vm_bus_name,
};
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 79a31e5..764ec05 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -580,6 +580,13 @@ static int vp_find_vqs(struct virtio_device *vdev, unsigned nvqs,
false, false);
}
+static const char *vp_bus_name(struct virtio_device *vdev)
+{
+ struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+
+ return pci_name(vp_dev->pci_dev);
+}
+
static struct virtio_config_ops virtio_pci_config_ops = {
.get = vp_get,
.set = vp_set,
@@ -590,6 +597,7 @@ static struct virtio_config_ops virtio_pci_config_ops = {
.del_vqs = vp_del_vqs,
.get_features = vp_get_features,
.finalize_features = vp_finalize_features,
+ .bus_name = vp_bus_name,
};
static void virtio_pci_release_dev(struct device *_d)
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index add4790..63f98d0 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -100,6 +100,10 @@
* vdev: the virtio_device
* This gives the final feature bits for the device: it can change
* the dev->feature bits if it wants.
+ * @bus_name: return the bus name associated with the device
+ * vdev: the virtio_device
+ * This returns a pointer to the bus name a la pci_name from which
+ * the caller can then copy.
*/
typedef void vq_callback_t(struct virtqueue *);
struct virtio_config_ops {
@@ -117,6 +121,7 @@ struct virtio_config_ops {
void (*del_vqs)(struct virtio_device *);
u32 (*get_features)(struct virtio_device *vdev);
void (*finalize_features)(struct virtio_device *vdev);
+ const char *(*bus_name)(struct virtio_device *vdev);
};
/* If driver didn't advertise the feature, it will never appear. */
@@ -182,5 +187,14 @@ struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev,
return ERR_PTR(err);
return vq;
}
+
+static inline
+const char *virtio_bus_name(struct virtio_device *vdev)
+{
+ if (!vdev->config->bus_name)
+ return "virtio";
+ return vdev->config->bus_name(vdev);
+}
+
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
^ permalink raw reply related
* Re: [RFC PATCH net-next] enable virtio_net to return bus_info in ethtool -i consistent with emulated NICs
From: Ben Hutchings @ 2011-11-14 22:30 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, Rusty Russell, Michael Tsirkin, virtualization
In-Reply-To: <20111114215241.5B8BF2900307@tardy>
On Mon, 2011-11-14 at 13:52 -0800, Rick Jones wrote:
> From: Rick Jones <rick.jones2@hp.com>
>
> Add a new .bus_name to virtio_config_ops then modify virtio_net to
> call through to it in an ethtool .get_drvinfo routine to report
> bus_info in ethtool -i output which is consistent with other
> emulated NICs and the output of lspci.
[...]
> diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
> index 0dc30ff..3724d45 100644
> --- a/drivers/lguest/lguest_device.c
> +++ b/drivers/lguest/lguest_device.c
> @@ -381,6 +381,11 @@ error:
> return PTR_ERR(vqs[i]);
> }
>
> +static const char *lg_bus_name(struct virtio_device *vdev)
> +{
> + return "Not Implemented";
> +}
[...]
> +static const char *kvm_bus_name(struct virtio_device *vdev)
> +{
> + return "Not Implemented";
> +}
[...]
Please use the existing 'not implemented' value, which is the empty
string. If you think ethtool should print some helpful message instead
of an empty string, please submit a patch for ethtool.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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