* Re: pull request net: 2013-10-02
From: David Miller @ 2013-10-03 20:27 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20131003201413.GC3668@neomailbox.net>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Thu, 3 Oct 2013 22:14:13 +0200
> please consider queuing the patch for stable as it is rather important (if you
> already did so then I can't see this in patchwork).
Queued up for -stable, thanks.
^ permalink raw reply
* Re: pull request net: 2013-10-02
From: Antonio Quartulli @ 2013-10-03 20:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20131003.155802.929707046474176566.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Thu, Oct 03, 2013 at 03:58:02PM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Wed, 2 Oct 2013 22:03:20 +0200
>
> > this is a "one-change" pull request intended for net/linux-3.{12,11,10}.
> >
> > This patch from Matthias Schiffer is fixing the init routine of the Network
> > Coding component by preventing it from registering the handler for the CODED
> > packet type each time a new soft-interface is created.
> >
> > Without this fix a second soft-interface cannot be created unless the Network
> > Coding component is not part of the module (not compiled-in).
> >
> > As I mentioned before, this fix should be queued for stable as it aims
> > kernels older than linux-3.12.
> >
> > Please pull or let me know of any problem.
>
> Pulled, thanks Antonio.
>
David,
please consider queuing the patch for stable as it is rather important (if you
already did so then I can't see this in patchwork).
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* pull request: wireless 2013-10-03
From: John W. Linville @ 2013-10-03 20:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 9847 bytes --]
Dave,
Here is another batch of fixes intended for the 3.12 stream...
For the mac80211 bits, Johannes says:
"This time I have two fixes for IBSS (including one for wext, hah), a fix
for extended rates IEs, an active monitor checking fix and a sysfs
registration race fix."
On top of those...
Amitkumar Karwar brings an mwifiex fix for an interrupt loss issue
w/ SDIO devices. The problem was due to a command timeout issue
introduced by an earlier patch.
Felix Fietkau a stall in the ath9k driver. This patch fixes the
regression introduced in the commit "ath9k: use software queues for
un-aggregated data packets".
Stanislaw Gruszka reverts an rt2x00 patch that was found to cause
connection problems with some devices.
Please let me know if there are problems!
John
---
The following changes since commit 569943d0639c85a451ea853087cbd5f738247dd9:
Merge branch 'mv643xx' (2013-10-02 17:11:50 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 1eea72f03a139146f341e450cf56934b2e01a4d3:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-10-03 16:00:03 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: fix SDIO interrupt lost issue
Bruno Randolf (1):
cfg80211: fix warning when using WEXT for IBSS
Chun-Yeow Yeoh (1):
mac80211: fix the setting of extended supported rate IE
Felix Fietkau (2):
mac80211: drop spoofed packets in ad-hoc mode
ath9k: fix powersave response handling for BA session packets
Johannes Berg (1):
cfg80211: fix sysfs registration race
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Luciano Coelho (1):
cfg80211: use the correct macro to check for active monitor support
Stanislaw Gruszka (1):
Revert "rt2x00pci: Use PCI MSIs whenever possible"
drivers/net/wireless/ath/ath9k/xmit.c | 9 ++++++---
drivers/net/wireless/mwifiex/main.c | 6 ++++--
drivers/net/wireless/rt2x00/rt2x00pci.c | 9 +--------
net/mac80211/rx.c | 3 +++
net/mac80211/util.c | 5 +----
net/wireless/core.c | 21 +++++++++++++--------
net/wireless/ibss.c | 3 +++
net/wireless/nl80211.c | 4 ++--
8 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 5ac713d..dd30452 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1969,15 +1969,18 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
static void ath_tx_send_normal(struct ath_softc *sc, struct ath_txq *txq,
struct ath_atx_tid *tid, struct sk_buff *skb)
{
+ struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ath_frame_info *fi = get_frame_info(skb);
struct list_head bf_head;
- struct ath_buf *bf;
-
- bf = fi->bf;
+ struct ath_buf *bf = fi->bf;
INIT_LIST_HEAD(&bf_head);
list_add_tail(&bf->list, &bf_head);
bf->bf_state.bf_type = 0;
+ if (tid && (tx_info->flags & IEEE80211_TX_CTL_AMPDU)) {
+ bf->bf_state.bf_type = BUF_AMPDU;
+ ath_tx_addto_baw(sc, tid, bf);
+ }
bf->bf_next = NULL;
bf->bf_lastbf = bf;
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index fd77833..c2b91f5 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -358,10 +358,12 @@ process_start:
}
} while (true);
- if ((adapter->int_status) || IS_CARD_RX_RCVD(adapter))
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
+ if ((adapter->int_status) || IS_CARD_RX_RCVD(adapter)) {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
goto process_start;
+ }
- spin_lock_irqsave(&adapter->main_proc_lock, flags);
adapter->mwifiex_processing = false;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 76d95de..dc49e52 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -105,13 +105,11 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct rt2x00_ops *ops)
goto exit_release_regions;
}
- pci_enable_msi(pci_dev);
-
hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
if (!hw) {
rt2x00_probe_err("Failed to allocate hardware\n");
retval = -ENOMEM;
- goto exit_disable_msi;
+ goto exit_release_regions;
}
pci_set_drvdata(pci_dev, hw);
@@ -152,9 +150,6 @@ exit_free_reg:
exit_free_device:
ieee80211_free_hw(hw);
-exit_disable_msi:
- pci_disable_msi(pci_dev);
-
exit_release_regions:
pci_release_regions(pci_dev);
@@ -179,8 +174,6 @@ void rt2x00pci_remove(struct pci_dev *pci_dev)
rt2x00pci_free_reg(rt2x00dev);
ieee80211_free_hw(hw);
- pci_disable_msi(pci_dev);
-
/*
* Free the PCI device data.
*/
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 54395d7..674eac1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3056,6 +3056,9 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
case NL80211_IFTYPE_ADHOC:
if (!bssid)
return 0;
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2) ||
+ ether_addr_equal(sdata->u.ibss.bssid, hdr->addr2))
+ return 0;
if (ieee80211_is_beacon(hdr->frame_control)) {
return 1;
} else if (!ieee80211_bssid_match(bssid, sdata->u.ibss.bssid)) {
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..9c3200b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2103,7 +2103,7 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_supported_band *sband;
- int rate, skip, shift;
+ int rate, shift;
u8 i, exrates, *pos;
u32 basic_rates = sdata->vif.bss_conf.basic_rates;
u32 rate_flags;
@@ -2131,14 +2131,11 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
pos = skb_put(skb, exrates + 2);
*pos++ = WLAN_EID_EXT_SUPP_RATES;
*pos++ = exrates;
- skip = 0;
for (i = 8; i < sband->n_bitrates; i++) {
u8 basic = 0;
if ((rate_flags & sband->bitrates[i].flags)
!= rate_flags)
continue;
- if (skip++ < 8)
- continue;
if (need_basic && basic_rates & BIT(i))
basic = 0x80;
rate = DIV_ROUND_UP(sband->bitrates[i].bitrate,
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6715396..fe8d4f2 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -566,18 +566,13 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
-
+ rtnl_lock();
res = device_add(&rdev->wiphy.dev);
- if (res)
- return res;
-
- res = rfkill_register(rdev->rfkill);
if (res) {
- device_del(&rdev->wiphy.dev);
+ rtnl_unlock();
return res;
}
- rtnl_lock();
/* set up regulatory info */
wiphy_regulatory_register(wiphy);
@@ -606,6 +601,15 @@ int wiphy_register(struct wiphy *wiphy)
rdev->wiphy.registered = true;
rtnl_unlock();
+
+ res = rfkill_register(rdev->rfkill);
+ if (res) {
+ rfkill_destroy(rdev->rfkill);
+ rdev->rfkill = NULL;
+ wiphy_unregister(&rdev->wiphy);
+ return res;
+ }
+
return 0;
}
EXPORT_SYMBOL(wiphy_register);
@@ -640,7 +644,8 @@ void wiphy_unregister(struct wiphy *wiphy)
rtnl_unlock();
__count == 0; }));
- rfkill_unregister(rdev->rfkill);
+ if (rdev->rfkill)
+ rfkill_unregister(rdev->rfkill);
rtnl_lock();
rdev->wiphy.registered = false;
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 39bff7d..403fe29 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -263,6 +263,8 @@ int cfg80211_ibss_wext_join(struct cfg80211_registered_device *rdev,
if (chan->flags & IEEE80211_CHAN_DISABLED)
continue;
wdev->wext.ibss.chandef.chan = chan;
+ wdev->wext.ibss.chandef.center_freq1 =
+ chan->center_freq;
break;
}
@@ -347,6 +349,7 @@ int cfg80211_ibss_wext_siwfreq(struct net_device *dev,
if (chan) {
wdev->wext.ibss.chandef.chan = chan;
wdev->wext.ibss.chandef.width = NL80211_CHAN_WIDTH_20_NOHT;
+ wdev->wext.ibss.chandef.center_freq1 = freq;
wdev->wext.ibss.channel_fixed = true;
} else {
/* cfg80211_ibss_wext_join will pick one if needed */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index af8d84a..626dc3b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2421,7 +2421,7 @@ static int nl80211_set_interface(struct sk_buff *skb, struct genl_info *info)
change = true;
}
- if (flags && (*flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (flags && (*flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
@@ -2483,7 +2483,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
info->attrs[NL80211_ATTR_MNTR_FLAGS] : NULL,
&flags);
- if (!err && (flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (!err && (flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [patch v2] net: heap overflow in __audit_sockaddr()
From: David Miller @ 2013-10-03 20:06 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, security, juri.aedla
In-Reply-To: <20131002212720.GA30492@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 3 Oct 2013 00:27:20 +0300
> We need to cap ->msg_namelen or it leads to a buffer overflow when we
> to the memcpy() in __audit_sockaddr(). It requires CAP_AUDIT_CONTROL to
> exploit this bug.
>
> The call tree is:
> ___sys_recvmsg()
> move_addr_to_user()
> audit_sockaddr()
> __audit_sockaddr()
>
> Reported-by: Jüri Aedla <juri.aedla@gmail.com>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: The limit check to the compat code was missing as pointed out by
> Ben Hutchings.
Applied and queued up for -stable, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next] tcp/dccp: remove twchain
From: Ben Hutchings @ 2013-10-03 20:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1380784922.19002.198.camel@edumazet-glaptop.roam.corp.google.com>
On Thu, 2013-10-03 at 00:22 -0700, Eric Dumazet wrote:
[...]
> @@ -146,26 +150,21 @@ void __inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
> spin_lock(lock);
>
> /*
> - * Step 2: Hash TW into TIMEWAIT chain.
> - * Should be done before removing sk from established chain
> - * because readers are lockless and search established first.
> + * Step 2: Hash TW into tcp ehash chain.
> + * Notes :
> + * - tw_refcnt is set to 3 because :
> + * - We have one reference from bhash chain.
> + * - We have one reference from ehash chain.
> + * We can use atomic_set() because prior spin_lock()/spin_unlock()
> + * committed into memory all tw fields.
> */
> - inet_twsk_add_node_rcu(tw, &ehead->twchain);
> + atomic_set(&tw->tw_refcnt, 1 + 1 + 1);
> + inet_twsk_add_node_rcu(tw, &ehead->chain);
[...]
'will commit' rather than 'committed'?
But isn't this also a separate optimisation?
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
* Re: [PATCH net-next] tcp: shrink tcp6_timewait_sock by one cache line
From: David Miller @ 2013-10-03 20:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380829642.19002.225.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Oct 2013 12:47:22 -0700
> On Thu, 2013-10-03 at 15:31 -0400, David Miller wrote:
>
>> Eric just use tcp_time_stamp in all of these locations, then you can
>> lose the casts and still achieve your stated objective.
>
> I thought about this, but this would break if tcp_time_stamp was no
> longer tied to jiffies.
>
> Van Jacobson had the idea of using finer resolution tcp_time_stamp for
> TCP flows in data centers, for better RTT estimation and and cwin
> control, but also for better diagnostics.
>
> Note we used this (u32)jiffies thing in net/ipv4/inetpeer.c in the past,
> and tp->tso_deferred is also a u32 value.
I am sure that you could define a set of interfaces which are named
such that the intent and usage is clear, would do the u32 cast, and
would be updated by whoever changes the timestamp implementation in
the future.
The cast is really ugly, even if we do it in inetpeer already, and
you're already here cleaning things up, so please do it right.
Thank you.
^ permalink raw reply
* Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: David Miller @ 2013-10-03 20:00 UTC (permalink / raw)
To: hns; +Cc: j.dumon, marek.belisko, linux-usb, netdev, linux-kernel
In-Reply-To: <C7520082-95CC-4D4F-BCE4-96A7D6346DB3@goldelico.com>
From: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>
Date: Thu, 3 Oct 2013 21:40:34 +0200
> I have made the bug observation from debug log that this bit is set in a response
> each time the modem has a RING message. It might be specific to this modem
> and firmware version, i.e. a firmware bug. But we have no means to verify or even
> change it in the firmware.
>
> I.e. the driver must handle it in a better way.
>
> Because the notification is rejected by the driver, the driver will hang up and the
> whole modem connection breaks down.
>
> With this patch, the problem was never observed again in ~2 years.
>
> I'd hope the maintainer of this driver can shed some light on it.
I think if you suspect the bit is set in response to RING messages
then you should define a macro so that the number is not just magic,
and put a descriptrive comment above the macro definition for that
bit.
^ permalink raw reply
* Re: pull request net: 2013-10-02
From: David Miller @ 2013-10-03 19:58 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1380744201-2074-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Wed, 2 Oct 2013 22:03:20 +0200
> this is a "one-change" pull request intended for net/linux-3.{12,11,10}.
>
> This patch from Matthias Schiffer is fixing the init routine of the Network
> Coding component by preventing it from registering the handler for the CODED
> packet type each time a new soft-interface is created.
>
> Without this fix a second soft-interface cannot be created unless the Network
> Coding component is not part of the module (not compiled-in).
>
> As I mentioned before, this fix should be queued for stable as it aims
> kernels older than linux-3.12.
>
> Please pull or let me know of any problem.
Pulled, thanks Antonio.
^ permalink raw reply
* Re: [PATCH net-next] 3com: Fix drivers/net/ethernet/3com/Kconfig references to PCMCIA and 3c515
From: David Miller @ 2013-10-03 19:55 UTC (permalink / raw)
To: tedheadster; +Cc: netdev
In-Reply-To: <1380726483-17247-1-git-send-email-tedheadster@gmail.com>
From: Matthew Whitehead <tedheadster@gmail.com>
Date: Wed, 2 Oct 2013 11:08:03 -0400
> The Vortex driver works with PCI and Cardbus devices, not PCMCIA.
>
> There never was an EISA 3c515 card, only ISA, so remove that option.
>
> Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH RFC 50/77] mlx5: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-03 19:48 UTC (permalink / raw)
To: Eli Cohen
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-dr
In-Reply-To: <20131003071433.GA7299@mtldesk30>
On Thu, Oct 03, 2013 at 10:14:33AM +0300, Eli Cohen wrote:
> On Wed, Oct 02, 2013 at 12:49:06PM +0200, Alexander Gordeev wrote:
> >
> > + err = pci_msix_table_size(dev->pdev);
> > + if (err < 0)
> > + return err;
> > +
> > nvec = dev->caps.num_ports * num_online_cpus() + MLX5_EQ_VEC_COMP_BASE;
> > nvec = min_t(int, nvec, num_eqs);
> > + nvec = min_t(int, nvec, err);
> > if (nvec <= MLX5_EQ_VEC_COMP_BASE)
> > return -ENOSPC;
>
> Making sure we don't request more vectors then the device's is capable
> of -- looks good.
> >
> > @@ -131,20 +136,15 @@ static int mlx5_enable_msix(struct mlx5_core_dev *dev)
> > for (i = 0; i < nvec; i++)
> > table->msix_arr[i].entry = i;
> >
> > -retry:
> > - table->num_comp_vectors = nvec - MLX5_EQ_VEC_COMP_BASE;
> > err = pci_enable_msix(dev->pdev, table->msix_arr, nvec);
> > - if (err <= 0) {
> > + if (err) {
> > + kfree(table->msix_arr);
> > return err;
> > - } else if (err > MLX5_EQ_VEC_COMP_BASE) {
> > - nvec = err;
> > - goto retry;
> > }
> >
>
> According to latest sources, pci_enable_msix() may still fail so why
> do you want to remove this code?
pci_enable_msix() may fail, but it can not return a positive number.
We first calculate how many MSI-Xs we need, adjust to what we can get,
check if that is enough and only then go for it.
> > - mlx5_core_dbg(dev, "received %d MSI vectors out of %d requested\n", err, nvec);
> > - kfree(table->msix_arr);
> > + table->num_comp_vectors = nvec - MLX5_EQ_VEC_COMP_BASE;
> >
> > - return -ENOSPC;
> > + return 0;
> > }
> >
> > static void mlx5_disable_msix(struct mlx5_core_dev *dev)
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH net-next] tcp: shrink tcp6_timewait_sock by one cache line
From: Eric Dumazet @ 2013-10-03 19:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20131003.153158.1558578931500427624.davem@davemloft.net>
On Thu, 2013-10-03 at 15:31 -0400, David Miller wrote:
> Eric just use tcp_time_stamp in all of these locations, then you can
> lose the casts and still achieve your stated objective.
I thought about this, but this would break if tcp_time_stamp was no
longer tied to jiffies.
Van Jacobson had the idea of using finer resolution tcp_time_stamp for
TCP flows in data centers, for better RTT estimation and and cwin
control, but also for better diagnostics.
Note we used this (u32)jiffies thing in net/ipv4/inetpeer.c in the past,
and tp->tso_deferred is also a u32 value.
^ permalink raw reply
* Re: [PATCH net] be2net: Warn users of possible broken functionality on BE2 cards with very old F/W versions with latest driver.
From: Ben Hutchings @ 2013-10-03 19:45 UTC (permalink / raw)
To: Somnath Kotur; +Cc: netdev, davem
In-Reply-To: <e84f68dc-6ab3-4e56-b2f5-70e51c46d1c3@CMEXHTCAS1.ad.emulex.com>
On Thu, 2013-10-03 at 12:33 +0530, Somnath Kotur wrote:
> On very old F/W versions < 4.0, the mailbox command to set interrupts on the
> card succeeds even though it is not supported and should have failed leading to
> interrupts not working.
> Hence warn users to upgrade to a suitable F/W version to avoid seeing broken
> functionality.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..f4bbc92 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -3247,6 +3247,11 @@ static int be_setup(struct be_adapter *adapter)
>
> be_cmd_get_fw_ver(adapter, adapter->fw_ver, adapter->fw_on_flash);
>
> + if (BE2_chip(adapter) && memcmp(adapter->fw_ver, "4.", 2) < 0) {
Are you sure the firmware major version will never go up to 2 digits?
This seems like a job for simple_strtol(), except that's now deprecated.
I don't know what one is supposed to do now when parsing a string that
has more than just a single integer in it.
> + dev_err(dev, "F/W version is very old. IRQs may not work\n");
> + dev_err(dev, "Pls upgrade to F/W version >= 4.0\n");
'Please' is spelt thus. And it seems odd to say 'very old' when you
also have a very specific idea of how old that is (< 4.0).
Ben.
> + }
> +
> if (adapter->vlans_added)
> be_vid_config(adapter);
>
--
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
* Re: [PATCH 09/19 v2] net: bnx2x: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: eilong, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-2-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:49 +0200
> The variable rc is only assigned the values true and false.
> The function bnx2x_prev_is_path_marked already returns bool.
> Change rc type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 10/19 v2] net: myri10ge: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: hykim, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-3-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:50 +0200
> There is the rc variable on both myri10ge_ss_lock_napi and
> myri10ge_ss_lock_poll functions. In both cases rc is only assigned the
> values true and false. Both functions already return bool. Change rc
> type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 19/19 v2] net: ipv4: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: kuznet, jmorris, kaber, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-4-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:51 +0200
> The variable fully_acked is only assigned the values true and false.
> Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 08/19 v2] net: atl1c: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna
Cc: jcliburn, chris.snook, jkosina, rdunlap, standby24x7, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-1-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:48 +0200
> The variable ret is only assigned the values true and false.
> The function atl1c_read_eeprom already returns bool. Change
> ret type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: Dr. H. Nikolaus Schaller @ 2013-10-03 19:40 UTC (permalink / raw)
To: David Miller
Cc: Jan Dumon, Belisko Marek, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131003.152907.2144013596237714581.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi,
Am 03.10.2013 um 21:29 schrieb David Miller:
> From: "Dr. H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> Date: Wed, 2 Oct 2013 09:00:18 +0200
>
>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>> From: "H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
>> GTM601 during RING indication
>>
>> It has been observed that the GTM601 with 1.7 firmware sometimes sends a value
>> wIndex that has bit 0x04 set instead of being reset as the code expects. So we
>> mask it for the error check.
>>
>> See http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>>
>> Signed-off-by: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
>> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVIAdwXzzRB9H2Q@public.gmane.org>
>
> I think we should look more deeply into what this bit might mean
> and why the firmware might be setting it before we even consider
> applying a patch like this one.
Yes, that would be the right way.
The problem is that the firmware is a black box and the packet format has no
(public) documentation (unless someone inside OPTION has access to it).
I have made the bug observation from debug log that this bit is set in a response
each time the modem has a RING message. It might be specific to this modem
and firmware version, i.e. a firmware bug. But we have no means to verify or even
change it in the firmware.
I.e. the driver must handle it in a better way.
Because the notification is rejected by the driver, the driver will hang up and the
whole modem connection breaks down.
With this patch, the problem was never observed again in ~2 years.
I'd hope the maintainer of this driver can shed some light on it.
BR,
Nikolaus Schaller
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] bonding: modify the current and add new hash functions
From: David Miller @ 2013-10-03 19:37 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar, eric.dumazet, vfalico
In-Reply-To: <1380713966-3891-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Wed, 2 Oct 2013 13:39:23 +0200
> This is a complete remake of my old patch that modified the bonding hash
> functions to use skb_flow_dissect which was suggested by Eric Dumazet.
> This time around I've left the old modes although using a new hash function
> again suggested by Eric, which is the same for all modes. The only
> difference is the way the headers are obtained. The old modes obtain them
> as before in order to address concerns about speed, but the 2 new ones use
> skb_flow_dissect. The unification of the hash function allows to remove a
> pointer from struct bonding and also a few extra functions that dealt with
> it. Two new functions are added which take care of the hashing based on
> bond->params.xmit_policy only:
> bond_xmit_hash() - global function, used by XOR and 3ad modes
> bond_flow_dissect() - used by bond_xmit_hash() to obtain the necessary
> headers and combine them according to bond->params.xmit_policy.
> Also factor out the ports extraction from skb_flow_dissect and add a new
> function - skb_flow_get_ports() which can be re-used.
>
> v2: add the flow_dissector patch and use skb_flow_get_ports in patch 02
> v3: fix a bug in the flow_dissector patch that caused a different thoff
> by modifying the thoff argument in skb_flow_get_ports directly, most
> of the users already do it anyway.
> Also add the necessary export symbol for skb_flow_get_ports.
> v4: integrate the thoff bug fix in patch 01
> v5: disintegrate the thoff bug fix and re-base on top of Eric's fix
Series applied, thanks al ot.
^ permalink raw reply
* Re: [PATCH net-next] inet: consolidate INET_TW_MATCH
From: David Miller @ 2013-10-03 19:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380713390.19002.87.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Oct 2013 04:29:50 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 2 :
>
> We can use a generic lookup, sockets being in whatever state, if
> we are sure all relevant fields are at the same place in all socket
> types (ESTABLISH, TIME_WAIT, SYN_RECV)
>
> This patch removes these macros :
>
> inet_addrpair, inet_addrpair, tw_addrpair, tw_portpair
>
> And adds :
>
> sk_portpair, sk_addrpair, sk_daddr, sk_rcv_saddr
>
> Then, INET_TW_MATCH() is really the same than INET_MATCH()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Nice simplification, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] tcp: shrink tcp6_timewait_sock by one cache line
From: David Miller @ 2013-10-03 19:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380711604.19002.78.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Oct 2013 04:00:04 -0700
> + tmo = tw->tw_ttd - (u32)jiffies;
...
> + tw->tw_ttd = (u32)(jiffies + timeo);
...
> + tw->tw_ttd = (u32)(jiffies + (slot << INET_TWDR_RECYCLE_TICK));
...
> + s32 delta = tw->tw_ttd - (u32)jiffies;
...
> + s32 delta = tw->tw_ttd - (u32)jiffies;
Eric just use tcp_time_stamp in all of these locations, then you can
lose the casts and still achieve your stated objective.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: David Miller @ 2013-10-03 19:29 UTC (permalink / raw)
To: hns; +Cc: j.dumon, marek.belisko, linux-usb, netdev, linux-kernel
In-Reply-To: <B1808224-5850-41E3-9A8F-0F350F84FF89@goldelico.com>
From: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>
Date: Wed, 2 Oct 2013 09:00:18 +0200
> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Thu, 15 Nov 2012 14:40:57 +0100
> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
> GTM601 during RING indication
>
> It has been observed that the GTM601 with 1.7 firmware sometimes sends a value
> wIndex that has bit 0x04 set instead of being reset as the code expects. So we
> mask it for the error check.
>
> See http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>
> Signed-off-by: NeilBrown <neilb@suse.de>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.de>
I think we should look more deeply into what this bit might mean
and why the firmware might be setting it before we even consider
applying a patch like this one.
^ permalink raw reply
* [PATCH] atl1e: enable support for NETIF_F_RXALL and NETIF_F_RXCRC features
From: Andrea Merello @ 2013-10-03 19:18 UTC (permalink / raw)
To: jie.yang, xiong.huang; +Cc: davem, netdev, linux-kernel, Andrea Merello
This patch allows (optionally, via ethtool) the atl1e NIC to:
- Receive bad frames (runt, bad-fcs, etc..)
- Receive full frames without stripping the FCS.
This has been tested on my board by injecting runt and bad-fcs
frames with a FPGA-based device.
The particular scenario of receiving very short frames (<4 bytes)
without passing FCS to the upper layer has been also tested:
This could be potentially dangerous because the driver performs a
4 byte subtraction on the frame length, but I finally have NOT
added anything to avoid this because it seems the NIC always
discards frames so much short..
If someone still have some reason to worry about this, please
tell me.. I will add an explicit SW check..
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 46 ++++++++++++++++++++++---
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 1966444..7a73f3a 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -313,6 +313,34 @@ static void atl1e_set_multi(struct net_device *netdev)
}
}
+static void __atl1e_rx_mode(netdev_features_t features, u32 *mac_ctrl_data)
+{
+
+ if (features & NETIF_F_RXALL) {
+ /* enable RX of ALL frames */
+ *mac_ctrl_data |= MAC_CTRL_DBG;
+ } else {
+ /* disable RX of ALL frames */
+ *mac_ctrl_data &= ~MAC_CTRL_DBG;
+ }
+}
+
+static void atl1e_rx_mode(struct net_device *netdev,
+ netdev_features_t features)
+{
+ struct atl1e_adapter *adapter = netdev_priv(netdev);
+ u32 mac_ctrl_data = 0;
+
+ netdev_dbg(adapter->netdev, "%s\n", __func__);
+
+ atl1e_irq_disable(adapter);
+ mac_ctrl_data = AT_READ_REG(&adapter->hw, REG_MAC_CTRL);
+ __atl1e_rx_mode(features, &mac_ctrl_data);
+ AT_WRITE_REG(&adapter->hw, REG_MAC_CTRL, mac_ctrl_data);
+ atl1e_irq_enable(adapter);
+}
+
+
static void __atl1e_vlan_mode(netdev_features_t features, u32 *mac_ctrl_data)
{
if (features & NETIF_F_HW_VLAN_CTAG_RX) {
@@ -394,6 +422,10 @@ static int atl1e_set_features(struct net_device *netdev,
if (changed & NETIF_F_HW_VLAN_CTAG_RX)
atl1e_vlan_mode(netdev, features);
+ if (changed & NETIF_F_RXALL)
+ atl1e_rx_mode(netdev, features);
+
+
return 0;
}
@@ -1057,7 +1089,8 @@ static void atl1e_setup_mac_ctrl(struct atl1e_adapter *adapter)
value |= MAC_CTRL_PROMIS_EN;
if (netdev->flags & IFF_ALLMULTI)
value |= MAC_CTRL_MC_ALL_EN;
-
+ if (netdev->features & NETIF_F_RXALL)
+ value |= MAC_CTRL_DBG;
AT_WRITE_REG(hw, REG_MAC_CTRL, value);
}
@@ -1405,7 +1438,8 @@ static void atl1e_clean_rx_irq(struct atl1e_adapter *adapter, u8 que,
rx_page_desc[que].rx_nxseq++;
/* error packet */
- if (prrs->pkt_flag & RRS_IS_ERR_FRAME) {
+ if ((prrs->pkt_flag & RRS_IS_ERR_FRAME) &&
+ !(netdev->features & NETIF_F_RXALL)) {
if (prrs->err_flag & (RRS_ERR_BAD_CRC |
RRS_ERR_DRIBBLE | RRS_ERR_CODE |
RRS_ERR_TRUNC)) {
@@ -1418,7 +1452,10 @@ static void atl1e_clean_rx_irq(struct atl1e_adapter *adapter, u8 que,
}
packet_size = ((prrs->word1 >> RRS_PKT_SIZE_SHIFT) &
- RRS_PKT_SIZE_MASK) - 4; /* CRC */
+ RRS_PKT_SIZE_MASK);
+ if (likely(!(netdev->features & NETIF_F_RXFCS)))
+ packet_size -= 4; /* CRC */
+
skb = netdev_alloc_skb_ip_align(netdev, packet_size);
if (skb == NULL)
goto skip_pkt;
@@ -2245,7 +2282,8 @@ static int atl1e_init_netdev(struct net_device *netdev, struct pci_dev *pdev)
NETIF_F_HW_VLAN_CTAG_RX;
netdev->features = netdev->hw_features | NETIF_F_LLTX |
NETIF_F_HW_VLAN_CTAG_TX;
-
+ /* not enabled by default */
+ netdev->hw_features |= NETIF_F_RXALL | NETIF_F_RXFCS;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 19:17 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linux-wireless@vger.kernel.org
In-Reply-To: <524DBC93.1070400@hp.com>
On 10/03/2013 11:50 AM, Rick Jones wrote:
> On 10/03/2013 11:27 AM, Ben Greear wrote:
>> I'm seeing something a bit strange and wondering if anyone had an
>> opinion on why...
>>
>> I am testing up to 200 wifi station systems, each with a TCP connection
>> running on them (download only, from VAP to stations).
>>
>> Without encryption (ie, open network), I see total throughput go from
>> about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
>> so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
>>
>> However, if I enable encryption, the throughput is actually higher
>> (111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
>> bit of CPU load in this test. The numbers bounce around since this is
>> wifi after all, but in general encryption tends to win reliably in this
>> test.
>>
>> When testing with a single station (and 5 tcp streams with jacked up
>> snd/rcv buffers) the open networks perform significantly better at total throughput:
>> 263Mbps vs 246Mbps.
>>
>> Maybe the extra delay for decryption increases odds that GRO will take
>> affect for the many, slower streams (and maybe that will decrease ACK
>> traffic?)
>>
>> Any other ideas?
>
> Fewer times two or more stations step on one another? The recievers will only try to transmit when they receive data. Modulo timing, if the individual
> downloads are a bit slower, less chance of the receivers looking to send ACKs back through at the same time? Got any low-level stats for the health and well
> being of the wireless network?
The tcp connection stats are taken after running for 60 seconds, and I take 3-sec running averages
as well as 60 second averages. So, I think that it would have to be total decrease in ACKs,
not just timing, to make a difference. The 3 and 60 second stats show consistently higher throughput
with encryption when using 25+ stations/connections.
Also, it works out that the sending sockets all sort of send randomly as they
are able, so I don't think there would be any particular ACK flood seen..
I have great quantities of low level stats, but I have not dug into them in detail
just yet. In general, my RF environment in this test is fairly controlled, as
I am cabling the systems using good semi-rigid SMA cables and an RF attenuator.
There will be some external interference of course, as they are not in an
isolation chamber.
As for the difference in 1 stations vs 25+, then it is very likely related to
low level things like MPDU working better with a single station, and probably
better ACK avoidance (I recall about 20kpps download, 4kpps upload in a previous
test with a single station, which indicates to me we must not be acking every
packet-on-the-air..somehow).
(For grins, I played with the delayed-ack-segs from an out-of-tree patch and
can get TCP throughput up to 300Mbps by setting delayed ack segs to 64 in
single station/5 stream, open network test).
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [stable 3.0] add some CVE fixes
From: Jiri Slaby @ 2013-10-03 19:11 UTC (permalink / raw)
To: Greg KH; +Cc: stable, netdev
In-Reply-To: <20131003184411.GG8901@kroah.com>
On 10/03/2013 08:44 PM, Greg KH wrote:
> On Thu, Oct 03, 2013 at 11:20:28AM +0200, Jiri Slaby wrote:
>> Plus the backports that are replied to this mail?
>
> I don't see any backports, did you forget to send them?
I don't think so, they were sent and this is a log of one of them:
OK. Log says:
Sendmail: /usr/sbin/sendmail -f jslaby@suse.cz -i stable@vger.kernel.org
jslaby@suse.cz
From: Jiri Slaby <jslaby@suse.cz>
To: <stable@vger.kernel.org>
Cc: jslaby@suse.cz
Subject: [PATCH 4/4] Tools: hv: verify origin of netlink connector message
Date: Thu, 3 Oct 2013 11:23:50 +0200
Message-Id: <1380792230-27255-4-git-send-email-jslaby@suse.cz>
X-Mailer: git-send-email 1.8.4
In-Reply-To: <1380792230-27255-1-git-send-email-jslaby@suse.cz>
References: <524D36DC.5070506@suse.cz>
<1380792230-27255-1-git-send-email-jslaby@suse.cz>
Result: OK
Could you check your spam folder? Or I can bounce them directly to you?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH net-next] dev: add support of flag IFF_NOPROC
From: David Miller @ 2013-10-03 19:09 UTC (permalink / raw)
To: stephen; +Cc: nicolas.dichtel, netdev
In-Reply-To: <20131003104627.411f5cc4@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 3 Oct 2013 10:46:27 -0700
> What about speeding up proc or sysfs? Or providing a bulk create/destroy.
+1 +1 +1
This will benefit more people than the just the envisioned users for
this IFF_NOPROC thing.
I really don't want to take the IFF_NOPROC approach.
^ 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