* Re: [PATCH v3 6/6] cgroup: Assign subsystem IDs during compile time
From: Tejun Heo @ 2012-08-14 17:27 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Andrew Morton, Eric Dumazet,
Gao feng, Glauber Costa, Jamal Hadi Salim, John Fastabend,
Kamezawa Hiroyuki, Li Zefan, Neil Horman
In-Reply-To: <1344949343-26090-8-git-send-email-wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
On Tue, Aug 14, 2012 at 03:02:23PM +0200, Daniel Wagner wrote:
> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>
> We are able to safe some space when we assign the subsystem
> IDs at compile time. Instead of allocating per cgroup
> cgroup->subsys[CGROUP_SUBSYS_COUNT] where CGROUP_SUBSYS_COUNT is
> always 64, we allocate 12 + 1 at max (at this point there are 12
> subsystem). The additinal one is the price we have to pay to
> distinguish between builtin and module subsystems.
>
> We should only access task_cls_classid() and task_netprioidx()
> if the subsystem is ready to be used using jump labels for this.
I think I want to like this patch but it's kinda confusing to review.
Is there any reasonable way that you can split the core changes from
net_cls ones?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 00/16] generic hashtable implementation
From: J. Bruce Fields @ 2012-08-14 18:16 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <1344961490-4068-1-git-send-email-levinsasha928@gmail.com>
On Tue, Aug 14, 2012 at 06:24:34PM +0200, Sasha Levin wrote:
> SUNRPC/cache: use new hashtable implementation
..
> lockd: use new hashtable implementation
FWIW, these look fine (and I ran them through some nfs tests and didn't
see any problems).
--b.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Patch] net: allow calling rtmsg_ifinfo() in atomic
From: Ben Hutchings @ 2012-08-14 18:40 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, John Fastabend, Greg Rose, Thomas Graf,
Eric Dumazet
In-Reply-To: <1344940096-5548-1-git-send-email-amwang@redhat.com>
On Tue, 2012-08-14 at 18:28 +0800, Cong Wang wrote:
> (Against net tree.)
>
> When running 'systemctl restart network.service', I got the following
> warning:
>
> [ 1123.199677]
> [ 1123.310275] ===============================
> [ 1123.442202] [ INFO: suspicious RCU usage. ]
> [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
> [ 1123.665204] -------------------------------
> [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
> [ 1123.992320]
> [ 1123.992320] other info that might help us debug this:
> [ 1123.992320]
> [ 1124.307382]
> [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
> [ 1124.522220] 2 locks held by sysctl/5710:
> [ 1124.648364] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
> [ 1124.882211] #1: (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
[...]
> This is due to that we call rtmsg_ifinfo() with RCU read lock held,
> and because rtmsg_ifinfo() may block, this is invalid.
>
> This patch fixes it by allowing callees to specify GFP when
> calling it. In this case, netdev_features_change() calls it
> with GFP_ATOMIC.
[...]
This is not the right fix; netdev notifiers *should* be able to assume
they are called with only the RTNL lock held. Anyway,
addrconf_forward_change() is called with the RTNL lock held so there is
no need for it to use RCU-protected iteration.
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
* [PATCH net] ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
From: Ben Hutchings @ 2012-08-14 18:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, John Fastabend, Greg Rose, Thomas Graf, Eric Dumazet,
Ben Hutchings, Cong Wang
In-Reply-To: <1344940096-5548-1-git-send-email-amwang@redhat.com>
Cong Wang reports that lockdep detected suspicious RCU usage while
enabling IPV6 forwarding:
[ 1123.310275] ===============================
[ 1123.442202] [ INFO: suspicious RCU usage. ]
[ 1123.558207] 3.6.0-rc1+ #109 Not tainted
[ 1123.665204] -------------------------------
[ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
[ 1123.992320]
[ 1123.992320] other info that might help us debug this:
[ 1123.992320]
[ 1124.307382]
[ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
[ 1124.522220] 2 locks held by sysctl/5710:
[ 1124.648364] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
[ 1124.882211] #1: (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
[ 1125.085209]
[ 1125.085209] stack backtrace:
[ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
[ 1125.441291] Call Trace:
[ 1125.545281] [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
[ 1125.667212] [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
[ 1125.781838] [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
[...]
[ 1127.445223] [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
[...]
[ 1127.772188] [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
[ 1127.885174] [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
[ 1128.013214] [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5
[...]
addrconf_forward_change() uses RCU iteration over the netdev list,
which is unnecessary since it already holds the RTNL lock. We also
cannot reasonably require netdevice notifier functions not to sleep.
Reported-by: Cong Wang <amwang@redhat.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
net/ipv6/addrconf.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7918181..6bc85f7 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -494,8 +494,7 @@ static void addrconf_forward_change(struct net *net, __s32 newf)
struct net_device *dev;
struct inet6_dev *idev;
- rcu_read_lock();
- for_each_netdev_rcu(net, dev) {
+ for_each_netdev(net, dev) {
idev = __in6_dev_get(dev);
if (idev) {
int changed = (!idev->cnf.forwarding) ^ (!newf);
@@ -504,7 +503,6 @@ static void addrconf_forward_change(struct net *net, __s32 newf)
dev_forward_change(idev);
}
}
- rcu_read_unlock();
}
static int addrconf_fixup_forwarding(struct ctl_table *table, int *p, int newf)
--
1.7.7.6
--
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 related
* pull request: wireless 2012-08-14
From: John W. Linville @ 2012-08-14 19:02 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
commit 1e55217e174f4e6920fd441dcd3aaf8e37645460
Dave,
This batch of fixes is intended for 3.6.
Alexey Khoroshilov provides a potential memory leak in rndis_wlan.
Bob Copeland gives us an ath5k fix for a lockdep problem.
Dan Carpenter fixes a signedness mismatch in at76c50x.
Felix Fietkau corrects a regression caused by an earlier commit that can
lead to an IRQ storm.
Lorenzo Bianconi offers a fix for a bad variable initialization in ath9k
that can cause it to improperly mark decrypted frames.
Rajkumar Manoharan fixes ath9k to prevent the btcoex time from running
when the hardware is asleep.
The remainder are Bluetooth fixes, about which Gustavo says:
"Here goes some fixes for 3.6-rc1, there are a few fix to
thte inquiry code by Ram Malovany, support for 2 new devices,
and few others fixes for NULL dereference, possible deadlock
and a memory leak."
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 3bf671af14d591ede9251acb0085e8017f3705e7:
Merge branch 'fixes-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds (2012-08-13 09:59:04 +0300)
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 1e55217e174f4e6920fd441dcd3aaf8e37645460:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2012-08-14 14:42:54 -0400)
----------------------------------------------------------------
Alexey Khoroshilov (1):
rndis_wlan: Fix potential memory leak in update_pmkid()
Andrei Emeltchenko (1):
Bluetooth: smp: Fix possible NULL dereference
Bob Copeland (1):
ath5k: fix spin_lock_irqsave/spin_lock_bh nesting in mesh
Dan Carpenter (1):
wireless: at76c50x: signedness bug in at76_dfu_get_state()
Felix Fietkau (1):
ath9k: fix interrupt storms on queued hardware reset
Gustavo Padovan (1):
Bluetooth: Fix possible deadlock in SCO code
Jaganath Kanakkassery (1):
Bluetooth: Fix socket not getting freed if l2cap channel create fails
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Lorenzo Bianconi (1):
ath9k: fix decrypt_error initialization in ath_rx_tasklet()
Manoj Iyer (1):
Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
Peng Chen (1):
Bluetooth: add support for atheros 0489:e057
Rajkumar Manoharan (1):
ath9k: stop btcoex on device suspend
Ram Malovany (3):
Bluetooth: Fix using NULL inquiry entry
Bluetooth: Fix using a NULL inquiry cache entry
Bluetooth: Set name_state to unknown when entry name is empty
Szymon Janc (1):
Bluetooth: Fix legacy pairing with some devices
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 2 ++
drivers/net/wireless/at76c50x-usb.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 6 ++----
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 5 ++---
drivers/net/wireless/ath/ath9k/mac.c | 18 +++++++++++------
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 4 +++-
drivers/net/wireless/ath/ath9k/pci.c | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/rndis_wlan.c | 6 ++++--
net/bluetooth/hci_event.c | 28 +++++++++++++++++++++------
net/bluetooth/l2cap_core.c | 1 +
net/bluetooth/l2cap_sock.c | 2 +-
net/bluetooth/sco.c | 19 +++++++++---------
net/bluetooth/smp.c | 5 ++++-
16 files changed, 68 insertions(+), 36 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 10308cd..11f36e5 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -79,6 +79,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
+ { USB_DEVICE(0x0489, 0xe057) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -104,6 +105,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e272214..cef3bac 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -98,6 +98,7 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x0a5c, 0x21e6) },
{ USB_DEVICE(0x0a5c, 0x21e8) },
{ USB_DEVICE(0x0a5c, 0x21f3) },
+ { USB_DEVICE(0x0a5c, 0x21f4) },
{ USB_DEVICE(0x413c, 0x8197) },
/* Foxconn - Hon Hai */
@@ -133,6 +134,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index efc162e..88b8d64 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -342,7 +342,7 @@ static int at76_dfu_get_status(struct usb_device *udev,
return ret;
}
-static u8 at76_dfu_get_state(struct usb_device *udev, u8 *state)
+static int at76_dfu_get_state(struct usb_device *udev, u8 *state)
{
int ret;
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 8c4c040..2aab20e 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2056,9 +2056,7 @@ ath5k_beacon_update_timers(struct ath5k_hw *ah, u64 bc_tsf)
void
ath5k_beacon_config(struct ath5k_hw *ah)
{
- unsigned long flags;
-
- spin_lock_irqsave(&ah->block, flags);
+ spin_lock_bh(&ah->block);
ah->bmisscount = 0;
ah->imask &= ~(AR5K_INT_BMISS | AR5K_INT_SWBA);
@@ -2085,7 +2083,7 @@ ath5k_beacon_config(struct ath5k_hw *ah)
ath5k_hw_set_imr(ah, ah->imask);
mmiowb();
- spin_unlock_irqrestore(&ah->block, flags);
+ spin_unlock_bh(&ah->block);
}
static void ath5k_tasklet_beacon(unsigned long data)
diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index 260e7dc..d56453e 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -254,7 +254,6 @@ ath5k_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ath5k_vif *avf = (void *)vif->drv_priv;
struct ath5k_hw *ah = hw->priv;
struct ath_common *common = ath5k_hw_common(ah);
- unsigned long flags;
mutex_lock(&ah->lock);
@@ -300,9 +299,9 @@ ath5k_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
}
if (changes & BSS_CHANGED_BEACON) {
- spin_lock_irqsave(&ah->block, flags);
+ spin_lock_bh(&ah->block);
ath5k_beacon_update(hw, vif);
- spin_unlock_irqrestore(&ah->block, flags);
+ spin_unlock_bh(&ah->block);
}
if (changes & BSS_CHANGED_BEACON_ENABLED)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 7990cd5..b42be91 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -773,15 +773,10 @@ bool ath9k_hw_intrpend(struct ath_hw *ah)
}
EXPORT_SYMBOL(ath9k_hw_intrpend);
-void ath9k_hw_disable_interrupts(struct ath_hw *ah)
+void ath9k_hw_kill_interrupts(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
- if (!(ah->imask & ATH9K_INT_GLOBAL))
- atomic_set(&ah->intr_ref_cnt, -1);
- else
- atomic_dec(&ah->intr_ref_cnt);
-
ath_dbg(common, INTERRUPT, "disable IER\n");
REG_WRITE(ah, AR_IER, AR_IER_DISABLE);
(void) REG_READ(ah, AR_IER);
@@ -793,6 +788,17 @@ void ath9k_hw_disable_interrupts(struct ath_hw *ah)
(void) REG_READ(ah, AR_INTR_SYNC_ENABLE);
}
}
+EXPORT_SYMBOL(ath9k_hw_kill_interrupts);
+
+void ath9k_hw_disable_interrupts(struct ath_hw *ah)
+{
+ if (!(ah->imask & ATH9K_INT_GLOBAL))
+ atomic_set(&ah->intr_ref_cnt, -1);
+ else
+ atomic_dec(&ah->intr_ref_cnt);
+
+ ath9k_hw_kill_interrupts(ah);
+}
EXPORT_SYMBOL(ath9k_hw_disable_interrupts);
void ath9k_hw_enable_interrupts(struct ath_hw *ah)
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 0eba36d..4a745e6 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -738,6 +738,7 @@ bool ath9k_hw_intrpend(struct ath_hw *ah);
void ath9k_hw_set_interrupts(struct ath_hw *ah);
void ath9k_hw_enable_interrupts(struct ath_hw *ah);
void ath9k_hw_disable_interrupts(struct ath_hw *ah);
+void ath9k_hw_kill_interrupts(struct ath_hw *ah);
void ar9002_hw_attach_mac_ops(struct ath_hw *ah);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6049d8b..a22df74 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -462,8 +462,10 @@ irqreturn_t ath_isr(int irq, void *dev)
if (!ath9k_hw_intrpend(ah))
return IRQ_NONE;
- if(test_bit(SC_OP_HW_RESET, &sc->sc_flags))
+ if (test_bit(SC_OP_HW_RESET, &sc->sc_flags)) {
+ ath9k_hw_kill_interrupts(ah);
return IRQ_HANDLED;
+ }
/*
* Figure out the reason(s) for the interrupt. Note
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index d455de9..a978984 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -321,6 +321,7 @@ static int ath_pci_suspend(struct device *device)
* Otherwise the chip never moved to full sleep,
* when no interface is up.
*/
+ ath9k_stop_btcoex(sc);
ath9k_hw_disable(sc->sc_ah);
ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_FULL_SLEEP);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 12aca02..4480c0c 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1044,7 +1044,6 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_hdr *hdr;
int retval;
- bool decrypt_error = false;
struct ath_rx_status rs;
enum ath9k_rx_qtype qtype;
bool edma = !!(ah->caps.hw_caps & ATH9K_HW_CAP_EDMA);
@@ -1066,6 +1065,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
tsf_lower = tsf & 0xffffffff;
do {
+ bool decrypt_error = false;
/* If handling rx interrupt and flush is in progress => exit */
if (test_bit(SC_OP_RXFLUSH, &sc->sc_flags) && (flush == 0))
break;
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 241162e..7a4ae9e 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1803,6 +1803,7 @@ static struct ndis_80211_pmkid *update_pmkid(struct usbnet *usbdev,
struct cfg80211_pmksa *pmksa,
int max_pmkids)
{
+ struct ndis_80211_pmkid *new_pmkids;
int i, err, newlen;
unsigned int count;
@@ -1833,11 +1834,12 @@ static struct ndis_80211_pmkid *update_pmkid(struct usbnet *usbdev,
/* add new pmkid */
newlen = sizeof(*pmkids) + (count + 1) * sizeof(pmkids->bssid_info[0]);
- pmkids = krealloc(pmkids, newlen, GFP_KERNEL);
- if (!pmkids) {
+ new_pmkids = krealloc(pmkids, newlen, GFP_KERNEL);
+ if (!new_pmkids) {
err = -ENOMEM;
goto error;
}
+ pmkids = new_pmkids;
pmkids->length = cpu_to_le32(newlen);
pmkids->bssid_info_count = cpu_to_le32(count + 1);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 41ff978..715d7e3 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1365,6 +1365,9 @@ static bool hci_resolve_next_name(struct hci_dev *hdev)
return false;
e = hci_inquiry_cache_lookup_resolve(hdev, BDADDR_ANY, NAME_NEEDED);
+ if (!e)
+ return false;
+
if (hci_resolve_name(hdev, e) == 0) {
e->name_state = NAME_PENDING;
return true;
@@ -1393,12 +1396,20 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
return;
e = hci_inquiry_cache_lookup_resolve(hdev, bdaddr, NAME_PENDING);
- if (e) {
+ /* If the device was not found in a list of found devices names of which
+ * are pending. there is no need to continue resolving a next name as it
+ * will be done upon receiving another Remote Name Request Complete
+ * Event */
+ if (!e)
+ return;
+
+ list_del(&e->list);
+ if (name) {
e->name_state = NAME_KNOWN;
- list_del(&e->list);
- if (name)
- mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00,
- e->data.rssi, name, name_len);
+ mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00,
+ e->data.rssi, name, name_len);
+ } else {
+ e->name_state = NAME_NOT_KNOWN;
}
if (hci_resolve_next_name(hdev))
@@ -1762,7 +1773,12 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
if (conn->type == ACL_LINK) {
conn->state = BT_CONFIG;
hci_conn_hold(conn);
- conn->disc_timeout = HCI_DISCONN_TIMEOUT;
+
+ if (!conn->out && !hci_conn_ssp_enabled(conn) &&
+ !hci_find_link_key(hdev, &ev->bdaddr))
+ conn->disc_timeout = HCI_PAIRING_TIMEOUT;
+ else
+ conn->disc_timeout = HCI_DISCONN_TIMEOUT;
} else
conn->state = BT_CONNECTED;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index a8964db..daa149b 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1181,6 +1181,7 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
sk = chan->sk;
hci_conn_hold(conn->hcon);
+ conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index a4bb27e..b94abd3 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1174,7 +1174,7 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock, int p
chan = l2cap_chan_create();
if (!chan) {
- l2cap_sock_kill(sk);
+ sk_free(sk);
return NULL;
}
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 40bbe25..3589e21 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -131,6 +131,15 @@ static int sco_conn_del(struct hci_conn *hcon, int err)
sco_sock_clear_timer(sk);
sco_chan_del(sk, err);
bh_unlock_sock(sk);
+
+ sco_conn_lock(conn);
+ conn->sk = NULL;
+ sco_pi(sk)->conn = NULL;
+ sco_conn_unlock(conn);
+
+ if (conn->hcon)
+ hci_conn_put(conn->hcon);
+
sco_sock_kill(sk);
}
@@ -821,16 +830,6 @@ static void sco_chan_del(struct sock *sk, int err)
BT_DBG("sk %p, conn %p, err %d", sk, conn, err);
- if (conn) {
- sco_conn_lock(conn);
- conn->sk = NULL;
- sco_pi(sk)->conn = NULL;
- sco_conn_unlock(conn);
-
- if (conn->hcon)
- hci_conn_put(conn->hcon);
- }
^ permalink raw reply related
* Do I need to skb_put() Ethernet frames to a minimum of 60 bytes?
From: Arvid Brodin @ 2012-08-14 18:53 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Nicolas Ferre
Hi,
If I create an sk_buff with a payload of less than 28 bytes (ethheader + data),
and send it using the cadence/macb (Ethernet) driver, I get
eth0: TX underrun, resetting buffers
Now I know the minimum Ethernet frame size is 64 bytes (including the 4-byte
FCS), but whose responsibility is it to pad the frame to this size if necessary?
Mine or the driver's - i.e. should I just skb_put() to the minimum size or
should I report the underrun as a driver bug?
--
Arvid Brodin | Consultant (Linux)
XDIN AB | Jan Stenbecks Torg 17 | SE-164 40 Kista | Sweden | xdin.com
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: Tabi Timur-B04825 @ 2012-08-14 19:19 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: david.daney@cavium.com, David Miller, netdev@vger.kernel.org
In-Reply-To: <1344358266-5450-1-git-send-email-timur@freescale.com>
On Tue, Aug 7, 2012 at 11:51 AM, Timur Tabi <timur@freescale.com> wrote:
> The mdio-mux driver scans all child mdio nodes, without regard to whether
> the node is actually used. Some device trees include all possible
> mdio-mux nodes and rely on the boot loader to disable those that are not
> present, based on some run-time configuration. Those nodes need to be
> skipped.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
Mr. Miller,
Any chance this patch can get into 3.6? I don't know if it qualifies
as a fix or not, but getting it into 3.6 would make it easier for me
to apply other patches to the powerpc tree.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [patch net-next v2 00/15] net: introduce upper device lists and remove dev->master
From: Andy Gospodarek @ 2012-08-14 20:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
edumazet-hpIqsD4AKlfQT0dZR+AlfA,
faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
fubar-r/Jw6+rmf7HQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
divy-ut6Up61K2wZBDgjK7y7TUQ,
jitendra.kalsaria-h88ZbnxC6KDQT0dZR+AlfA,
sony.chacko-h88ZbnxC6KDQT0dZR+AlfA,
linux-driver-h88ZbnxC6KDQT0dZR+AlfA, kaber-dcUjhNyLwpNeoWH0uzbU5w,
ursula.braun-tA70FqPdS9bQT0dZR+AlfA,
blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux390-tA70FqPdS9bQT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w, joe-6d6DIl74uiNBDgjK7y7TUQ,
gregory.v.rose-ral2JQCrhuEAvxtiuMwx3w,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
fbl-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1344956748-2099-1-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
> Hi all.
>
> Recent discussion around
> "[net-next] bonding: don't allow the master to become its slave"
> forced me to think about upper<->lower device connections.
>
> This patchset adds a possibility to record upper device linkage.
> All upper<->lower devices are converted to use this mechanism right after.
> That leads to dev->master removal because this info becomes redundant since
> "unique links" have the same value.
>
> After all changes, there is no longer possible to do:
> "bond->someotherdevice->samebond"
>
> Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
> in future by being able to get more appropriate info about l3 addresses.
>
> v1->v2:
> - s/unique/master/ better naming + stays closer to the history
> - fixed vlan err goto
> - original patch 15 (WARN_ON change) is squashed into the first patch
> - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
I just started to review v1 when v2 came out, but luckily the changes
were not too significant that I need to start all over.
The first note is that I didn't like the use of the term 'upper' -- it
seems like 'stacked' might be a better alternative as these are stacked
devices.
One thing to note is that I don't see any clear changelog that states
the current goals for this. You have stated in several places that it
will no longer be possible to create bonds of bonds, but there are
probably a few more things it might be wise to intentionally outlaw.
What about teams of teams? Or teams of bonds? Or bonds of teams?
Bonds of vlans?
>
> Jiri Pirko (15):
> net: introduce upper device lists
> macvlan: add link to upper device
> vlan: add link to upper device
> rtnetlink: remove usage of dev->master
> team: remove usage of netdev_set_master()
> bridge: remove usage of netdev_set_master()
> netpoll: remove usage of dev->master
> cxgb3: remove usage of dev->master
> qlcnic: guard __vlan_find_dev_deep() by rcu_read_lock
> qeth: ensure that __vlan_find_dev_deep() is called with rcu_read_lock
> vlan: remove usage of dev->master in __vlan_find_dev_deep()
> nes: remove usage of dev->master
> bonding: remove usage of dev->master
> net: remove no longer used netdev_set_bond_master() and
> netdev_set_master()
> net: kill dev->master
>
> drivers/infiniband/hw/nes/nes.c | 8 +-
> drivers/infiniband/hw/nes/nes_cm.c | 2 +-
> drivers/net/bonding/bond_3ad.c | 30 +--
> drivers/net/bonding/bond_alb.c | 6 +-
> drivers/net/bonding/bond_main.c | 94 ++++----
> drivers/net/bonding/bonding.h | 14 +-
> drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 11 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +
> drivers/net/macvlan.c | 9 +-
> drivers/net/team/team.c | 13 +-
> drivers/s390/net/qeth_l3_main.c | 21 +-
> include/linux/netdevice.h | 22 +-
> net/8021q/vlan.c | 10 +-
> net/8021q/vlan_core.c | 18 +-
> net/bridge/br_if.c | 6 +-
> net/core/dev.c | 239 +++++++++++++++++---
> net/core/netpoll.c | 8 +-
> net/core/rtnetlink.c | 45 ++--
> 18 files changed, 391 insertions(+), 167 deletions(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 v2 00/15] net: introduce upper device lists and remove dev->master
From: Ben Hutchings @ 2012-08-14 20:32 UTC (permalink / raw)
To: Andy Gospodarek
Cc: bridge, ursula.braun, john.r.fastabend, edumazet, shemminger,
sean.hefty, therbert, roland, linux-s390, linux-rdma, fubar, fbl,
hal.rosenstock, Jiri Pirko, faisal.latif, blaschka, sony.chacko,
linux-driver, xiyou.wangcong, jitendra.kalsaria, divy,
gregory.v.rose, netdev, linux-kernel, kaber, joe, linux390, davem
In-Reply-To: <20120814201950.GA17781@quad.redhat.com>
On Tue, 2012-08-14 at 16:19 -0400, Andy Gospodarek wrote:
> On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
> > Hi all.
> >
> > Recent discussion around
> > "[net-next] bonding: don't allow the master to become its slave"
> > forced me to think about upper<->lower device connections.
> >
> > This patchset adds a possibility to record upper device linkage.
> > All upper<->lower devices are converted to use this mechanism right after.
> > That leads to dev->master removal because this info becomes redundant since
> > "unique links" have the same value.
> >
> > After all changes, there is no longer possible to do:
> > "bond->someotherdevice->samebond"
> >
> > Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
> > in future by being able to get more appropriate info about l3 addresses.
> >
> > v1->v2:
> > - s/unique/master/ better naming + stays closer to the history
> > - fixed vlan err goto
> > - original patch 15 (WARN_ON change) is squashed into the first patch
> > - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
> I just started to review v1 when v2 came out, but luckily the changes
> were not too significant that I need to start all over.
>
> The first note is that I didn't like the use of the term 'upper' -- it
> seems like 'stacked' might be a better alternative as these are stacked
> devices.
When linking any two devices in a stack, one will be upper and the other
lower. The lower device might itself be stacked on top of a further
device, so 'stacked' is not a useful distinguishing adjective in
variable names. It might be a useful term in the commit messages and
kernel-doc, though.
> One thing to note is that I don't see any clear changelog that states
> the current goals for this. You have stated in several places that it
> will no longer be possible to create bonds of bonds, but there are
> probably a few more things it might be wise to intentionally outlaw.
>
> What about teams of teams? Or teams of bonds? Or bonds of teams?
> Bonds of vlans?
[...]
It doesn't disallow bonds of bonds (unless I'm missing something). It
disallows loops that involve any or all of those types of stacked
devices.
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: Do I need to skb_put() Ethernet frames to a minimum of 60 bytes?
From: Ben Hutchings @ 2012-08-14 20:35 UTC (permalink / raw)
To: Arvid Brodin; +Cc: netdev@vger.kernel.org, Nicolas Ferre
In-Reply-To: <502A9EC4.4040208@xdin.com>
On Tue, 2012-08-14 at 18:53 +0000, Arvid Brodin wrote:
> Hi,
>
> If I create an sk_buff with a payload of less than 28 bytes (ethheader + data),
> and send it using the cadence/macb (Ethernet) driver, I get
>
> eth0: TX underrun, resetting buffers
>
> Now I know the minimum Ethernet frame size is 64 bytes (including the 4-byte
> FCS), but whose responsibility is it to pad the frame to this size if necessary?
> Mine or the driver's - i.e. should I just skb_put() to the minimum size or
> should I report the underrun as a driver bug?
If the hardware doesn't pad frames automatically then it's the driver's
reponsibility to do so.
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 0/5] Call netif_carrier_off() after register_netdev()
From: David Miller @ 2012-08-14 21:00 UTC (permalink / raw)
To: shchepetkov; +Cc: netdev, linux-kernel, ldv-project
In-Reply-To: <1344940135-17079-1-git-send-email-shchepetkov@ispras.ru>
From: Ilya Shchepetkov <shchepetkov@ispras.ru>
Date: Tue, 14 Aug 2012 14:28:50 +0400
> Hi,
>
> There are several patches on the subject:
>
> 31bde1ceaa873bcaecd49e829bfabceacc4c512d
> c55ad8e56b983f03589b38b4504b5d1f41161ff8
> e826eafa65c6f1f7c8db5a237556cebac57ebcc5
> 0d672e9f8ac320c6d1ea9103db6df7f99ea20361
> 6a3c869a6021f4abcd69aa5fbb15c63f69eb36fe
>
> In 2008, David Miller wrote in his commit:
> (b47300168e770b60ab96c8924854c3b0eb4260eb)
>
>>net: Do not fire linkwatch events until the device is registered.
>
>>Several device drivers try to do things like netif_carrier_off()
>>before register_netdev() is invoked. This is bogus, but too many
>>drivers do this to fix them all up in one go.
>
> But I don't understand what will happen in this case?
Sigh... I would strongly suggest that when you don't understand
something you leave it alone until you do.
You can't do the netif_carrier_off() after the device register because
at the precise moment the device is registered it can be openned in
parallel on another cpu and thus cause the entire carrier state
to be changed.
Therefore if you do the netif_carrier_off() afterwards, it might
be overwriting state changes made in another context.
Please just leave this code alone.
^ permalink raw reply
* Re: [PATCH v3 6/6] cgroup: Assign subsystem IDs during compile time
From: Daniel Wagner @ 2012-08-14 21:01 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Andrew Morton, Eric Dumazet,
Gao feng, Glauber Costa, Jamal Hadi Salim, John Fastabend,
Kamezawa Hiroyuki, Li Zefan, Neil Horman
In-Reply-To: <20120814172749.GL25632-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Tejun,
On 08/14/2012 07:27 PM, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 03:02:23PM +0200, Daniel Wagner wrote:
>> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>>
>> We are able to safe some space when we assign the subsystem
>> IDs at compile time. Instead of allocating per cgroup
>> cgroup->subsys[CGROUP_SUBSYS_COUNT] where CGROUP_SUBSYS_COUNT is
>> always 64, we allocate 12 + 1 at max (at this point there are 12
>> subsystem). The additinal one is the price we have to pay to
>> distinguish between builtin and module subsystems.
>>
>> We should only access task_cls_classid() and task_netprioidx()
>> if the subsystem is ready to be used using jump labels for this.
>
> I think I want to like this patch but it's kinda confusing to review.
> Is there any reasonable way that you can split the core changes from
> net_cls ones?
My bad, sorry about that. Sure, I'll split the patches into smaller
pieces and remove net_cls updating part as Neil has requested. You will
get someting to review on Thursday, since tomorrow I am out of office.
thanks,
daniel
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-14 21:07 UTC (permalink / raw)
To: B04825; +Cc: david.daney, netdev
In-Reply-To: <CAOZdJXUB7jLZ_p3TmOs+p=jQM4Xs0a=HUdFia5N46M--LYyXJg@mail.gmail.com>
From: Tabi Timur-B04825 <B04825@freescale.com>
Date: Tue, 14 Aug 2012 19:19:58 +0000
> On Tue, Aug 7, 2012 at 11:51 AM, Timur Tabi <timur@freescale.com> wrote:
>> The mdio-mux driver scans all child mdio nodes, without regard to whether
>> the node is actually used. Some device trees include all possible
>> mdio-mux nodes and rely on the boot loader to disable those that are not
>> present, based on some run-time configuration. Those nodes need to be
>> skipped.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>
> Any chance this patch can get into 3.6? I don't know if it qualifies
> as a fix or not, but getting it into 3.6 would make it easier for me
> to apply other patches to the powerpc tree.
>
I want you to implement it the way David Daney said to do so.
And you never need to ask me questions like this, I clearly mark the
state of your patch:
http://patchwork.ozlabs.org/patch/175750/
So that you can just monitor it instead of wasting my time asking what
is happening to your patch.
Time of mine you consume forcing me to reply to you in situations like
this, which you could handle on your own, is time that I can't spend
reviewing patches from oher people that really are ready to go into
the tree.
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: Timur Tabi @ 2012-08-14 21:12 UTC (permalink / raw)
To: David Miller; +Cc: david.daney, netdev
In-Reply-To: <20120814.140736.812697309119422215.davem@davemloft.net>
David Miller wrote:
>> Any chance this patch can get into 3.6? I don't know if it qualifies
>> as a fix or not, but getting it into 3.6 would make it easier for me
>> to apply other patches to the powerpc tree.
>>
>
> I want you to implement it the way David Daney said to do so.
So you're saying that you don't want this fixed for 3.6? Because David
Daney's suggestion would require me to introduce a new device tree
function, and that won't be accepted until 3.7 at the earliest.
> And you never need to ask me questions like this, I clearly mark the
> state of your patch:
>
> http://patchwork.ozlabs.org/patch/175750/
>
> So that you can just monitor it instead of wasting my time asking what
> is happening to your patch.
Sorry.
> Time of mine you consume forcing me to reply to you in situations like
> this, which you could handle on your own, is time that I can't spend
> reviewing patches from oher people that really are ready to go into
> the tree.
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH net-next 0/7] sctp: network namespace support Part 2: per net tunables
From: David Miller @ 2012-08-14 21:14 UTC (permalink / raw)
To: ebiederm
Cc: vyasevich, linux-sctp, netdev, linux-kernel, jan.ariyasu,
jan.ariyasu, nhorman, tgraf, xi.wang
In-Reply-To: <20120808.232058.1128673474849407813.davem@davemloft.net>
Come on Vlad, please review this stuff some time this century. If you
want inclusion to be dependent upon your review, then the onus is on
you to review it in a timely manner. And you are not doing so here.
I'm not letting Eric's patches rot in patchwork for more than a week,
this is completely unacceptable.
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-14 21:16 UTC (permalink / raw)
To: timur; +Cc: david.daney, netdev
In-Reply-To: <502ABF2A.9070605@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 16:12:10 -0500
> David Miller wrote:
>
>>> Any chance this patch can get into 3.6? I don't know if it qualifies
>>> as a fix or not, but getting it into 3.6 would make it easier for me
>>> to apply other patches to the powerpc tree.
>>>
>>
>> I want you to implement it the way David Daney said to do so.
>
> So you're saying that you don't want this fixed for 3.6? Because David
> Daney's suggestion would require me to introduce a new device tree
> function, and that won't be accepted until 3.7 at the earliest.
If it is infrastrucure needed to fix a bug, it would be accepted. Stop
talking nonsense.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-08-14 21:22 UTC (permalink / raw)
To: brutus; +Cc: edumazet, netdev
In-Reply-To: <1344559958-29162-1-git-send-email-brutus@google.com>
Bruce, could you integrate (and unlike your submission, actually build
and run test) Weiping's bug fixes?
Actually, I'm actually a little bit alarmed at Weiping's fixes,
because it makes it look as if you didn't test things at all under
net-next, as it appears that without his fixes any loopback TCP
connection would OOPS the kernel.
In fact, it wouldn't even build without the sysctl_tcp_friends typo.
Indeed:
net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
I hope I don't need to tell you how unacceptable this is.
That also means that all of your measurements in the commit message
weren't even made in the context where this patch will be applied.
Also unacceptable.
All of this makes for an extremely poor quality submission, please
correct these issues.
^ permalink raw reply
* Re: [PATCH 1/2] net: move and rename netif_notify_peers()
From: David Miller @ 2012-08-14 21:28 UTC (permalink / raw)
To: amwang; +Cc: netdev, Ian.Campbell
In-Reply-To: <1344586497-2702-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 16:14:56 +0800
> I believe net/core/dev.c is a better place for netif_notify_peers(),
> because other net event notify functions also stay in this file.
>
> And rename it to netdev_notify_peers().
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH 2/2] net: remove netdev_bonding_change()
From: David Miller @ 2012-08-14 21:29 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1344586497-2702-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 16:14:57 +0800
> I don't see any benifits to use netdev_bonding_change() than
> using call_netdevice_notifiers() directly.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH RESEND net-next v3] GRE over IPv6
From: David Miller @ 2012-08-14 21:29 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <5380798.tqMsGTAipf@dima>
From: Kozlov Dmitry <xeb@mail.ru>
Date: Fri, 10 Aug 2012 14:51:50 +0400
> GRE over IPv6 implementation.
>
> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
> ---
> Changes: fixed 'new blank line at EOF' issue.
>
Applied to net-next
^ permalink raw reply
* Re: [PATCH v5 00/15] some netpoll and netconsole fixes
From: David Miller @ 2012-08-14 21:41 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1344597891-32242-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 19:24:36 +0800
> This patchset fixes serval problems in netconsole and netpoll.
>
> I ran this patchset in my KVM guest with some netpoll test cases,
> even covered with some corner cases, everything worked as expected.
Ok looks good, applied to 'net', thanks.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: Bruce Curtis @ 2012-08-14 21:45 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, netdev
In-Reply-To: <20120814.142228.85041202742435369.davem@davemloft.net>
On Tue, Aug 14, 2012 at 2:22 PM, David Miller <davem@davemloft.net> wrote:
>
> Bruce, could you integrate (and unlike your submission, actually build
> and run test) Weiping's bug fixes?
>
> Actually, I'm actually a little bit alarmed at Weiping's fixes,
> because it makes it look as if you didn't test things at all under
> net-next, as it appears that without his fixes any loopback TCP
> connection would OOPS the kernel.
>
??? rebase, build, boot a dev machine, run several hours of testing,
take numbers from test and updated commit message (commit message test
results changed from patch to patch submit because of this) so ???
> In fact, it wouldn't even build without the sysctl_tcp_friends typo.
> Indeed:
>
> net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
> net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
> net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
>
Didn't build with CONFIG_NET_DMA and wasn't caught as part of
rebase/local var name change.
> I hope I don't need to tell you how unacceptable this is.
>
> That also means that all of your measurements in the commit message
> weren't even made in the context where this patch will be applied.
>
> Also unacceptable.
>
I stand by my numbers!!!
> All of this makes for an extremely poor quality submission, please
> correct these issues.
Looking into Weiping's bug, can't simple use
lock_sock()/release_sock() due to A<>B locking issues (i.e.
bi-directional socket I/O).
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS
From: Kumar Gala @ 2012-08-14 21:45 UTC (permalink / raw)
To: Timur Tabi; +Cc: Andy Fleming, Scott Wood, ddaney.cavm, linuxppc-dev, netdev
In-Reply-To: <1344637896-14267-2-git-send-email-timur@freescale.com>
On Aug 10, 2012, at 5:31 PM, Timur Tabi wrote:
> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c b/arch/powerpc/platforms/85xx/corenet_ds.c
> index 925b028..a79fc79 100644
> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> @@ -106,6 +106,13 @@ static const struct of_device_id of_device_ids[] __devinitconst = {
> {
> .name = "handles",
> },
> + {
> + /*
> + * Warning: this entry might need to be located before those
> + * for the Fman Ethernet nodes.
> + */
> + .compatible = "mdio-mux",
> + },
> {}
> };
Under what condition would that be the case?
- k
^ permalink raw reply
* Re: [PATCH] net: Fix incorrect comment in netif_tx_stop_queue()
From: David Miller @ 2012-08-14 21:46 UTC (permalink / raw)
To: shchepetkov; +Cc: netdev, linux-kernel, ldv-project
In-Reply-To: <1344869014-7110-1-git-send-email-shchepetkov@ispras.ru>
From: Ilya Shchepetkov <shchepetkov@ispras.ru>
Date: Mon, 13 Aug 2012 18:43:34 +0400
> netif_stop_queue() can be called before register_netdev() because now
> TX queues are allocated inside alloc_netdev_mqs().
>
> (since ed9af2e839c06c18f721da2c768fbb444c4a10e5 commit)
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Ilya Shchepetkov <shchepetkov@ispras.ru>
You're not changing a "comment", you're changing a kernel log message.
Have you actually triggered this condition?
I doubt it, and I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH net 0/3] qmi_wwan: simplify device matching and add a few new devices
From: David Miller @ 2012-08-14 21:46 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1344798992-10176-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 12 Aug 2012 21:16:29 +0200
> The home cooked whitelisting code can be removed now that
> the USB core supports interface number matching.
>
> The second patch adds a few new devices.
>
> The third patch improves device list readability by using
> existing macros where possible.
>
> I hope this can go in 3.6-rc2/3. The series is based on
> the current net/master (commit 2359a476)
Ok I changed my mind and applied this to 'net'.
^ 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