* [PATCH net 1/3] bonding: Fix race condition between bond_enslave() and bond_3ad_update_lacp_rate()
From: Nikolay Aleksandrov @ 2013-02-18 17:59 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy
port->slave can be NULL since it's being initialized in bond_enslave
thus dereferencing a NULL pointer in bond_3ad_update_lacp_rate()
Also fix a minor bug, which could cause a port not to have
AD_STATE_LACP_TIMEOUT since there's no sync between
bond_3ad_update_lacp_rate() and bond_3ad_bind_slave(), by changing
the read_lock to a write_lock_bh in bond_3ad_update_lacp_rate().
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index a030e63..1720742 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2494,11 +2494,13 @@ void bond_3ad_update_lacp_rate(struct bonding *bond)
struct port *port = NULL;
int lacp_fast;
- read_lock(&bond->lock);
+ write_lock_bh(&bond->lock);
lacp_fast = bond->params.lacp_fast;
bond_for_each_slave(bond, slave, i) {
port = &(SLAVE_AD_INFO(slave).port);
+ if (port->slave == NULL)
+ continue;
__get_state_machine_lock(port);
if (lacp_fast)
port->actor_oper_port_state |= AD_STATE_LACP_TIMEOUT;
@@ -2507,5 +2509,5 @@ void bond_3ad_update_lacp_rate(struct bonding *bond)
__release_state_machine_lock(port);
}
- read_unlock(&bond->lock);
+ write_unlock_bh(&bond->lock);
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next 3/3] bonding: fix bond_release_all inconsistencies
From: Nikolay Aleksandrov @ 2013-02-18 17:59 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy
In-Reply-To: <1361210344-14907-1-git-send-email-nikolay@redhat.com>
This patch fixes the following inconsistencies in bond_release_all:
- IFF_BONDING flag is not stripped from slaves
- MTU is not restored
- no netdev notifiers are sent
Instead of trying to keep bond_release and bond_release_all in sync
I think we can re-use bond_release as the environment for calling it
is correct (RTNL is held). I have been running tests for the past
week and they came out successful. The only way for bond_release to fail
is for the slave to be attached in a different bond or to not be a slave
but that cannot happen as RTNL is held and no slave manipulations can be
achieved.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_main.c | 106 ++--------------------------------------
1 file changed, 5 insertions(+), 101 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 94c1534..fcfc880 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2140,113 +2140,17 @@ static int bond_release_and_destroy(struct net_device *bond_dev,
/*
* This function releases all slaves.
*/
-static int bond_release_all(struct net_device *bond_dev)
+static void bond_release_all(struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
- struct slave *slave;
- struct net_device *slave_dev;
- struct sockaddr addr;
-
- write_lock_bh(&bond->lock);
-
- netif_carrier_off(bond_dev);
if (bond->slave_cnt == 0)
- goto out;
-
- bond->current_arp_slave = NULL;
- bond->primary_slave = NULL;
- bond_change_active_slave(bond, NULL);
-
- while ((slave = bond->first_slave) != NULL) {
- /* Inform AD package of unbinding of slave
- * before slave is detached from the list.
- */
- if (bond->params.mode == BOND_MODE_8023AD)
- bond_3ad_unbind_slave(slave);
-
- slave_dev = slave->dev;
- bond_detach_slave(bond, slave);
-
- /* now that the slave is detached, unlock and perform
- * all the undo steps that should not be called from
- * within a lock.
- */
- write_unlock_bh(&bond->lock);
-
- /* unregister rx_handler early so bond_handle_frame wouldn't
- * be called for this slave anymore.
- */
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
-
- if (bond_is_lb(bond)) {
- /* must be called only after the slave
- * has been detached from the list
- */
- bond_alb_deinit_slave(bond, slave);
- }
-
- bond_destroy_slave_symlinks(bond_dev, slave_dev);
- bond_del_vlans_from_slave(bond, slave_dev);
-
- /* If the mode USES_PRIMARY, then we should only remove its
- * promisc and mc settings if it was the curr_active_slave, but that was
- * already taken care of above when we detached the slave
- */
- if (!USES_PRIMARY(bond->params.mode)) {
- /* unset promiscuity level from slave */
- if (bond_dev->flags & IFF_PROMISC)
- dev_set_promiscuity(slave_dev, -1);
-
- /* unset allmulti level from slave */
- if (bond_dev->flags & IFF_ALLMULTI)
- dev_set_allmulti(slave_dev, -1);
-
- /* flush master's mc_list from slave */
- netif_addr_lock_bh(bond_dev);
- bond_mc_list_flush(bond_dev, slave_dev);
- netif_addr_unlock_bh(bond_dev);
- }
-
- bond_upper_dev_unlink(bond_dev, slave_dev);
-
- slave_disable_netpoll(slave);
-
- /* close slave before restoring its mac address */
- dev_close(slave_dev);
-
- if (!bond->params.fail_over_mac) {
- /* restore original ("permanent") mac address*/
- memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN);
- addr.sa_family = slave_dev->type;
- dev_set_mac_address(slave_dev, &addr);
- }
-
- kfree(slave);
-
- /* re-acquire the lock before getting the next slave */
- write_lock_bh(&bond->lock);
- }
-
- eth_hw_addr_random(bond_dev);
- bond->dev_addr_from_first = true;
-
- if (bond_vlan_used(bond)) {
- pr_warning("%s: Warning: clearing HW address of %s while it still has VLANs.\n",
- bond_dev->name, bond_dev->name);
- pr_warning("%s: When re-adding slaves, make sure the bond's HW address matches its VLANs'.\n",
- bond_dev->name);
- }
-
+ return;
+ while (bond->first_slave != NULL)
+ bond_release(bond_dev, bond->first_slave->dev);
pr_info("%s: released all slaves\n", bond_dev->name);
-out:
- write_unlock_bh(&bond->lock);
-
- bond_compute_features(bond);
-
- return 0;
+ return;
}
/*
--
1.7.11.7
^ permalink raw reply related
* [PATCH net 2/3] bonding: Fix initialize after use for 3ad machine state spinlock
From: Nikolay Aleksandrov @ 2013-02-18 17:59 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy
In-Reply-To: <1361210344-14907-1-git-send-email-nikolay@redhat.com>
The 3ad machine state spinlock can be used before it is inititialized
while doing bond_enslave() (and the port is being initialized) since
port->slave is set before the lock is prepared, thus causing soft
lock-ups and a multitude of other nasty bugs.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 1720742..96d471e 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -389,13 +389,13 @@ static u8 __get_duplex(struct port *port)
/**
* __initialize_port_locks - initialize a port's STATE machine spinlock
- * @port: the port we're looking at
+ * @port: the slave of the port we're looking at
*
*/
-static inline void __initialize_port_locks(struct port *port)
+static inline void __initialize_port_locks(struct slave *port)
{
// make sure it isn't called twice
- spin_lock_init(&(SLAVE_AD_INFO(port->slave).state_machine_lock));
+ spin_lock_init(&(SLAVE_AD_INFO(port).state_machine_lock));
}
//conversions
@@ -1910,6 +1910,7 @@ int bond_3ad_bind_slave(struct slave *slave)
ad_initialize_port(port, bond->params.lacp_fast);
+ __initialize_port_locks(slave);
port->slave = slave;
port->actor_port_number = SLAVE_AD_INFO(slave).id;
// key is determined according to the link speed, duplex and user key(which is yet not supported)
@@ -1932,8 +1933,6 @@ int bond_3ad_bind_slave(struct slave *slave)
port->next_port_in_aggregator = NULL;
__disable_port(port);
- __initialize_port_locks(port);
-
// aggregator initialization
aggregator = &(SLAVE_AD_INFO(slave).aggregator);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] bonding: Fix initialize after use for 3ad machine state spinlock
From: Nikolay Aleksandrov @ 2013-02-18 17:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andy, fubar
In-Reply-To: <20130218.124422.842748240449456145.davem@davemloft.net>
On 18/02/13 18:44, David Miller wrote:
> From: Nikolay Aleksandrov <nikolay@redhat.com>
> Date: Mon, 18 Feb 2013 18:43:13 +0100
>
>> Should I post a v2 with numbering ?
>
> You should resubmit all 3 bonding patches you submitted, with proper
> numbering.
Okay, will do. Just to note 2 of the patches are for net, and 1 is for
the net-next tree. That information will be included in the subject as
usual.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Srivatsa S. Bhat @ 2013-02-18 17:56 UTC (permalink / raw)
To: Michel Lespinasse
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg,
vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <5122551E.1080703@linux.vnet.ibm.com>
On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
> Hi Michel,
>
> On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
>> Hi Srivasta,
>>
>> I admit not having followed in detail the threads about the previous
>> iteration, so some of my comments may have been discussed already
>> before - apologies if that is the case.
>>
>> On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
>> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>>> Reader-writer locks and per-cpu counters are recursive, so they can be
>>> used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
>>> recursive. Also, this design of switching the synchronization scheme ensures
>>> that you can safely nest and use these locks in a very flexible manner.
[...]
>>> void percpu_write_lock(struct percpu_rwlock *pcpu_rwlock)
>>> {
>>> + unsigned int cpu;
>>> +
>>> + /*
>>> + * Tell all readers that a writer is becoming active, so that they
>>> + * start switching over to the global rwlock.
>>> + */
>>> + for_each_possible_cpu(cpu)
>>> + per_cpu_ptr(pcpu_rwlock->rw_state, cpu)->writer_signal = true;
>>
>> I don't see anything preventing a race with the corresponding code in
>> percpu_write_unlock() that sets writer_signal back to false. Did I
>> miss something here ? It seems to me we don't have any guarantee that
>> all writer signals will be set to true at the end of the loop...
>>
>
> Ah, thanks for pointing that out! IIRC Oleg had pointed this issue in the last
> version, but back then, I hadn't fully understood what he meant. Your
> explanation made it clear. I'll work on fixing this.
>
We can fix this by using the simple patch (untested) shown below.
The alternative would be to acquire the rwlock for write, update the
->writer_signal values, release the lock, wait for readers to switch,
again acquire the rwlock for write with interrupts disabled etc... which
makes it kinda messy, IMHO. So I prefer the simple version shown below.
diff --git a/lib/percpu-rwlock.c b/lib/percpu-rwlock.c
index bf95e40..64ccd3f 100644
--- a/lib/percpu-rwlock.c
+++ b/lib/percpu-rwlock.c
@@ -50,6 +50,12 @@
(__this_cpu_read((pcpu_rwlock)->rw_state->writer_signal))
+/*
+ * Spinlock to synchronize access to the writer's data-structures
+ * (->writer_signal) from multiple writers.
+ */
+static DEFINE_SPINLOCK(writer_side_lock);
+
int __percpu_init_rwlock(struct percpu_rwlock *pcpu_rwlock,
const char *name, struct lock_class_key *rwlock_key)
{
@@ -191,6 +197,8 @@ void percpu_write_lock_irqsave(struct percpu_rwlock *pcpu_rwlock,
{
unsigned int cpu;
+ spin_lock(&writer_side_lock);
+
/*
* Tell all readers that a writer is becoming active, so that they
* start switching over to the global rwlock.
@@ -252,5 +260,6 @@ void percpu_write_unlock_irqrestore(struct percpu_rwlock *pcpu_rwlock,
per_cpu_ptr(pcpu_rwlock->rw_state, cpu)->writer_signal = false;
write_unlock_irqrestore(&pcpu_rwlock->global_rwlock, *flags);
+ spin_unlock(&writer_side_lock);
}
^ permalink raw reply related
* Re: [PATCH 2/2] tg3: Use different macros for pci_chip_rev_id accesses
From: David Miller @ 2013-02-18 17:46 UTC (permalink / raw)
To: mchan; +Cc: joe, mcarlson, netdev, linux-kernel
In-Reply-To: <1361052585.2240.4.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 16 Feb 2013 14:09:45 -0800
> On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote:
>> Upper case macros for various chip attributes are slightly
>> difficult to read and are a bit out of characterto the other
>> tg3_<foo> attribute functions.
>>
>> Convert:
>>
>> GET_ASIC_REV(tp->pci_chip_rev_id) -> tg3_asic_rev(tp)
>> GET_CHIP_REV(tp->pci_chip_rev_id) -> tg3_chip_rev(tp)
>>
>> Remove:
>> GET_METAL_REV(tp->pci_chip_rev_id) -> tg3_metal_rev(tp) (unused)
>>
>> Add:
>> tg3_chip_rev_id(tp) for tp->pci_chip_rev_id so access styles
>> are similar to tg3_asic_rev and tg3_chip_rev.
>>
>> These macros are not converted to static inline functions
>> because gcc (tested with 4.7.2) is currently unable to
>> optimize the object code it produces the same way and code
>> is otherwise larger.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] tg3: Remove define and single use of GET_CHIP_REV_ID
From: David Miller @ 2013-02-18 17:46 UTC (permalink / raw)
To: mchan; +Cc: joe, mcarlson, netdev, linux-kernel
In-Reply-To: <1361051064.2240.2.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 16 Feb 2013 13:44:24 -0800
> On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote:
>> It's the same value as tp->pci_chip_rev_id so use that
>> instead. This makes all CHIPREV_ID_<foo> tests the same.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] bgmac: fix unaligned accesses to network headers
From: David Miller @ 2013-02-18 17:45 UTC (permalink / raw)
To: hauke; +Cc: zajec5, netdev, stephen
In-Reply-To: <1361049038-25924-1-git-send-email-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat, 16 Feb 2013 22:10:38 +0100
> Without this patch I get many unaligned access warnings per packet,
> this patches fixes them all. This should improve performance on some
> systems like mips.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: Fix initialize after use for 3ad machine state spinlock
From: David Miller @ 2013-02-18 17:44 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <51226831.4030105@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Mon, 18 Feb 2013 18:43:13 +0100
> Should I post a v2 with numbering ?
You should resubmit all 3 bonding patches you submitted, with proper
numbering.
^ permalink raw reply
* PPPOE lockdep report in dev_queue_xmit+0x8b8/0x900
From: Yanko Kaneti @ 2013-02-18 17:43 UTC (permalink / raw)
To: netdev; +Cc: linux-ppp
Hello,
I've had the following lockdep report for the last couple of years of
kernels. I don't think I've had a lockup during that time related to
pppoe.
The pppoe entry in the MAINTAINERS file lists Michal Ostrowski <mostrows@earthlink.net>
which unfortunately bounces.
Regards
Yanko
[ 123.603836] ======================================================
[ 123.603838] [ INFO: possible circular locking dependency detected ]
[ 123.603842] 3.8.0-0.rc7.git3.1.fc19.x86_64 #1 Not tainted
[ 123.603844] -------------------------------------------------------
[ 123.603846] liferea/2399 is trying to acquire lock:
[ 123.603848] (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff815c9478>] dev_queue_xmit+0x8b8/0x900
[ 123.603860]
but task is already holding lock:
[ 123.603862] (&(&pch->downl)->rlock){+.-...}, at: [<ffffffffa0637d6d>] ppp_push+0x12d/0x630 [ppp_generic]
[ 123.603872]
which lock already depends on the new lock.
[ 123.603875]
the existing dependency chain (in reverse order) is:
[ 123.603877]
-> #3 (&(&pch->downl)->rlock){+.-...}:
[ 123.603881] [<ffffffff810db302>] lock_acquire+0xa2/0x1f0
[ 123.603887] [<ffffffff81704d2b>] _raw_spin_lock_bh+0x4b/0x80
[ 123.603892] [<ffffffffa0637d6d>] ppp_push+0x12d/0x630 [ppp_generic]
[ 123.603896] [<ffffffffa063a9df>] ppp_xmit_process+0x43f/0x670 [ppp_generic]
[ 123.603900] [<ffffffffa063afb0>] ppp_write+0xf0/0x110 [ppp_generic]
[ 123.603904] [<ffffffff811d8f32>] vfs_write+0xa2/0x170
[ 123.603908] [<ffffffff811d90ec>] sys_write+0x4c/0xa0
[ 123.603910] [<ffffffff8170eb59>] system_call_fastpath+0x16/0x1b
[ 123.603916]
-> #2 (&(&ppp->wlock)->rlock){+.-...}:
[ 123.603920] [<ffffffff810db302>] lock_acquire+0xa2/0x1f0
[ 123.603923] [<ffffffff81704d2b>] _raw_spin_lock_bh+0x4b/0x80
[ 123.603926] [<ffffffffa063a5cc>] ppp_xmit_process+0x2c/0x670 [ppp_generic]
[ 123.603930] [<ffffffffa063ae3d>] ppp_start_xmit+0x13d/0x1c0 [ppp_generic]
[ 123.603933] [<ffffffff815c8209>] dev_hard_start_xmit+0x259/0x6c0
[ 123.603936] [<ffffffff815e9dfe>] sch_direct_xmit+0xee/0x290
[ 123.603940] [<ffffffff815c8db6>] dev_queue_xmit+0x1f6/0x900
[ 123.603943] [<ffffffff815cfda1>] neigh_direct_output+0x11/0x20
[ 123.603946] [<ffffffff8160a0c9>] ip_finish_output+0x2b9/0x7f0
[ 123.603950] [<ffffffff8160c2bc>] ip_output+0x5c/0x100
[ 123.603952] [<ffffffff8160b649>] ip_local_out+0x29/0x90
[ 123.603955] [<ffffffff8160cdf5>] ip_send_skb+0x15/0x50
[ 123.603958] [<ffffffff8160ce63>] ip_push_pending_frames+0x33/0x40
[ 123.603960] [<ffffffff8163f6b5>] icmp_push_reply+0xf5/0x130
[ 123.603964] [<ffffffff8164096d>] icmp_send+0x49d/0xc80
[ 123.603966] [<ffffffff8163c709>] __udp4_lib_rcv+0x469/0xa80
[ 123.603969] [<ffffffff8163cd3a>] udp_rcv+0x1a/0x20
[ 123.603971] [<ffffffff8160497e>] ip_local_deliver_finish+0x19e/0x4c0
[ 123.603974] [<ffffffff81605697>] ip_local_deliver+0x47/0x80
[ 123.603977] [<ffffffff81604e00>] ip_rcv_finish+0x160/0x760
[ 123.603979] [<ffffffff816058e9>] ip_rcv+0x219/0x340
[ 123.603982] [<ffffffff815c6712>] __netif_receive_skb+0xad2/0xdc0
[ 123.603985] [<ffffffff815c7b1e>] process_backlog+0xbe/0x1a0
[ 123.603988] [<ffffffff815c7112>] net_rx_action+0x172/0x380
[ 123.603990] [<ffffffff81072b6f>] __do_softirq+0xef/0x3d0
[ 123.603994] [<ffffffff8170fefc>] call_softirq+0x1c/0x30
[ 123.603998] [<ffffffff8101c495>] do_softirq+0x85/0xc0
[ 123.604002] [<ffffffff81073035>] irq_exit+0xd5/0xe0
[ 123.604005] [<ffffffff817107a6>] do_IRQ+0x56/0xc0
[ 123.604008] [<ffffffff81705c32>] ret_from_intr+0x0/0x1a
[ 123.604011] [<ffffffff81022add>] default_idle+0x5d/0x550
[ 123.604015] [<ffffffff810243fc>] cpu_idle+0x10c/0x170
[ 123.604018] [<ffffffff816f11dd>] start_secondary+0x263/0x265
[ 123.604022]
-> #1 (_xmit_PPP#2){+.-...}:
[ 123.604026] [<ffffffff810db302>] lock_acquire+0xa2/0x1f0
[ 123.604029] [<ffffffff81704ca6>] _raw_spin_lock+0x46/0x80
[ 123.604032] [<ffffffff815e9dc0>] sch_direct_xmit+0xb0/0x290
[ 123.604035] [<ffffffff815c8db6>] dev_queue_xmit+0x1f6/0x900
[ 123.604038] [<ffffffff815cfda1>] neigh_direct_output+0x11/0x20
[ 123.604040] [<ffffffff8160a0c9>] ip_finish_output+0x2b9/0x7f0
[ 123.604043] [<ffffffff8160c2bc>] ip_output+0x5c/0x100
[ 123.604046] [<ffffffff8160b649>] ip_local_out+0x29/0x90
[ 123.604048] [<ffffffff8160bad3>] ip_queue_xmit+0x1b3/0x670
[ 123.604051] [<ffffffff81625e62>] tcp_transmit_skb+0x3e2/0xa60
[ 123.604054] [<ffffffff81626676>] tcp_write_xmit+0x196/0xad0
[ 123.604057] [<ffffffff8162721e>] __tcp_push_pending_frames+0x2e/0xc0
[ 123.604060] [<ffffffff81616ebd>] tcp_sendmsg+0x11d/0xe00
[ 123.604063] [<ffffffff81646b17>] inet_sendmsg+0x117/0x230
[ 123.604066] [<ffffffff815a971a>] sock_sendmsg+0xaa/0xe0
[ 123.604071] [<ffffffff815ac079>] sys_sendto+0x129/0x1d0
[ 123.604073] [<ffffffff8170eb59>] system_call_fastpath+0x16/0x1b
[ 123.604077]
-> #0 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}:
[ 123.604080] [<ffffffff810da8b1>] __lock_acquire+0x17e1/0x1a80
[ 123.604083] [<ffffffff810db302>] lock_acquire+0xa2/0x1f0
[ 123.604086] [<ffffffff81704ca6>] _raw_spin_lock+0x46/0x80
[ 123.604089] [<ffffffff815c9478>] dev_queue_xmit+0x8b8/0x900
[ 123.604091] [<ffffffffa06562b2>] __pppoe_xmit+0x142/0x190 [pppoe]
[ 123.604095] [<ffffffffa0656311>] pppoe_xmit+0x11/0x20 [pppoe]
[ 123.604098] [<ffffffffa0637d88>] ppp_push+0x148/0x630 [ppp_generic]
[ 123.604101] [<ffffffffa063a9df>] ppp_xmit_process+0x43f/0x670 [ppp_generic]
[ 123.604105] [<ffffffffa063ae3d>] ppp_start_xmit+0x13d/0x1c0 [ppp_generic]
[ 123.604108] [<ffffffff815c8209>] dev_hard_start_xmit+0x259/0x6c0
[ 123.604111] [<ffffffff815e9dfe>] sch_direct_xmit+0xee/0x290
[ 123.604114] [<ffffffff815c8db6>] dev_queue_xmit+0x1f6/0x900
[ 123.604117] [<ffffffff815cfda1>] neigh_direct_output+0x11/0x20
[ 123.604120] [<ffffffff8160a0c9>] ip_finish_output+0x2b9/0x7f0
[ 123.604123] [<ffffffff8160c2bc>] ip_output+0x5c/0x100
[ 123.604125] [<ffffffff8160b649>] ip_local_out+0x29/0x90
[ 123.604128] [<ffffffff8160bad3>] ip_queue_xmit+0x1b3/0x670
[ 123.604131] [<ffffffff81625e62>] tcp_transmit_skb+0x3e2/0xa60
[ 123.604134] [<ffffffff81628b74>] tcp_send_ack+0xa4/0xf0
[ 123.604137] [<ffffffff81617c46>] tcp_cleanup_rbuf+0x76/0x120
[ 123.604140] [<ffffffff816189ca>] tcp_recvmsg+0x72a/0xd50
[ 123.604143] [<ffffffff81646fc9>] inet_recvmsg+0x129/0x220
[ 123.604146] [<ffffffff815a9859>] sock_recvmsg+0xb9/0xf0
[ 123.604149] [<ffffffff815ac227>] sys_recvfrom+0xe7/0x160
[ 123.604152] [<ffffffff8170eb59>] system_call_fastpath+0x16/0x1b
[ 123.604155]
other info that might help us debug this:
[ 123.604158] Chain exists of:
dev->qdisc_tx_busylock ?: &qdisc_tx_busylock --> &(&ppp->wlock)->rlock --> &(&pch->downl)->rlock
[ 123.604163] Possible unsafe locking scenario:
[ 123.604165] CPU0 CPU1
[ 123.604167] ---- ----
[ 123.604168] lock(&(&pch->downl)->rlock);
[ 123.604171] lock(&(&ppp->wlock)->rlock);
[ 123.604173] lock(&(&pch->downl)->rlock);
[ 123.604175] lock(dev->qdisc_tx_busylock ?: &qdisc_tx_busylock);
[ 123.604178]
*** DEADLOCK ***
[ 123.604181] 8 locks held by liferea/2399:
[ 123.604182] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff816182d2>] tcp_recvmsg+0x32/0xd50
[ 123.604188] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff8160b925>] ip_queue_xmit+0x5/0x670
[ 123.604194] #2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81609f48>] ip_finish_output+0x138/0x7f0
[ 123.604199] #3: (rcu_read_lock_bh){.+....}, at: [<ffffffff815c8bc5>] dev_queue_xmit+0x5/0x900
[ 123.604204] #4: (_xmit_PPP#2){+.-...}, at: [<ffffffff815e9dc0>] sch_direct_xmit+0xb0/0x290
[ 123.604210] #5: (&(&ppp->wlock)->rlock){+.-...}, at: [<ffffffffa063a5cc>] ppp_xmit_process+0x2c/0x670 [ppp_generic]
[ 123.604216] #6: (&(&pch->downl)->rlock){+.-...}, at: [<ffffffffa0637d6d>] ppp_push+0x12d/0x630 [ppp_generic]
[ 123.604222] #7: (rcu_read_lock_bh){.+....}, at: [<ffffffff815c8bc5>] dev_queue_xmit+0x5/0x900
[ 123.604227]
stack backtrace:
[ 123.604231] Pid: 2399, comm: liferea Not tainted 3.8.0-0.rc7.git3.1.fc19.x86_64 #1
[ 123.604233] Call Trace:
[ 123.604239] [<ffffffff816f9c6e>] print_circular_bug+0x201/0x210
[ 123.604243] [<ffffffff810da8b1>] __lock_acquire+0x17e1/0x1a80
[ 123.604246] [<ffffffff810d93b5>] ? __lock_acquire+0x2e5/0x1a80
[ 123.604250] [<ffffffff810db302>] lock_acquire+0xa2/0x1f0
[ 123.604253] [<ffffffff815c9478>] ? dev_queue_xmit+0x8b8/0x900
[ 123.604257] [<ffffffff81704ca6>] _raw_spin_lock+0x46/0x80
[ 123.604260] [<ffffffff815c9478>] ? dev_queue_xmit+0x8b8/0x900
[ 123.604263] [<ffffffff815c9478>] dev_queue_xmit+0x8b8/0x900
[ 123.604267] [<ffffffff815c8bc5>] ? dev_queue_xmit+0x5/0x900
[ 123.604270] [<ffffffffa06562b2>] __pppoe_xmit+0x142/0x190 [pppoe]
[ 123.604274] [<ffffffffa0656311>] pppoe_xmit+0x11/0x20 [pppoe]
[ 123.604278] [<ffffffffa0637d88>] ppp_push+0x148/0x630 [ppp_generic]
[ 123.604282] [<ffffffff810d8c9c>] ? trace_hardirqs_on_caller+0xac/0x190
[ 123.604285] [<ffffffff810d8d8d>] ? trace_hardirqs_on+0xd/0x10
[ 123.604289] [<ffffffffa063a9df>] ppp_xmit_process+0x43f/0x670 [ppp_generic]
[ 123.604292] [<ffffffff810d8d8d>] ? trace_hardirqs_on+0xd/0x10
[ 123.604296] [<ffffffffa063ae3d>] ppp_start_xmit+0x13d/0x1c0 [ppp_generic]
[ 123.604300] [<ffffffff815c8209>] dev_hard_start_xmit+0x259/0x6c0
[ 123.604303] [<ffffffff815e9dfe>] sch_direct_xmit+0xee/0x290
[ 123.604307] [<ffffffff815c8db6>] dev_queue_xmit+0x1f6/0x900
[ 123.604310] [<ffffffff815c8bc5>] ? dev_queue_xmit+0x5/0x900
[ 123.604313] [<ffffffff815cfda1>] neigh_direct_output+0x11/0x20
[ 123.604316] [<ffffffff8160a0c9>] ip_finish_output+0x2b9/0x7f0
[ 123.604319] [<ffffffff81609f48>] ? ip_finish_output+0x138/0x7f0
[ 123.604323] [<ffffffff8160c2bc>] ip_output+0x5c/0x100
[ 123.604326] [<ffffffff8160b649>] ip_local_out+0x29/0x90
[ 123.604329] [<ffffffff8160bad3>] ip_queue_xmit+0x1b3/0x670
[ 123.604332] [<ffffffff8160b925>] ? ip_queue_xmit+0x5/0x670
[ 123.604335] [<ffffffff81625e62>] tcp_transmit_skb+0x3e2/0xa60
[ 123.604339] [<ffffffff811b8a19>] ? ksize+0x19/0xc0
[ 123.604342] [<ffffffff81628b74>] tcp_send_ack+0xa4/0xf0
[ 123.604346] [<ffffffff81617c46>] tcp_cleanup_rbuf+0x76/0x120
[ 123.604350] [<ffffffff816189ca>] tcp_recvmsg+0x72a/0xd50
[ 123.604354] [<ffffffff810ad465>] ? sched_clock_cpu+0xb5/0x100
[ 123.604358] [<ffffffff81646fc9>] inet_recvmsg+0x129/0x220
[ 123.604361] [<ffffffff815a9859>] sock_recvmsg+0xb9/0xf0
[ 123.604365] [<ffffffff810d93b5>] ? __lock_acquire+0x2e5/0x1a80
[ 123.604368] [<ffffffff815ac227>] sys_recvfrom+0xe7/0x160
[ 123.604372] [<ffffffff8170eb85>] ? sysret_check+0x22/0x5d
[ 123.604376] [<ffffffff810d8ced>] ? trace_hardirqs_on_caller+0xfd/0x190
[ 123.604381] [<ffffffff8136094e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 123.604385] [<ffffffff8170eb59>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH] bonding: Fix initialize after use for 3ad machine state spinlock
From: Nikolay Aleksandrov @ 2013-02-18 17:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andy, fubar
In-Reply-To: <20130218.120232.679284201789150959.davem@davemloft.net>
On 18/02/13 18:02, David Miller wrote:
>
> When submitting multiple changes to the same area in a group, you must
> number your changes.
>
> Using tools such as "git send-email ..." will do this automatically
> for you, otherwise you must put numberings into your subject lines
> by hand.
Thanks for the advice, I must've accidentally removed the numbering
while re-basing as I used git send-email.
Should I post a v2 with numbering ?
The actual order of applying these 2 doesn't matter as they touch
different parts, and if applied in reverse will only spill an offset -1.
Nik
^ permalink raw reply
* Re: [PATCH net-next] ip: fix warning in xfrm4_mode_tunnel_input
From: David Miller @ 2013-02-18 17:43 UTC (permalink / raw)
To: stephen; +Cc: pshelar, netdev
In-Reply-To: <20130216094029.4d2fc993@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 16 Feb 2013 09:40:29 -0800
> Same problem as IPv6
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix warning in xfrm6_mode_tunnel_input
From: David Miller @ 2013-02-18 17:43 UTC (permalink / raw)
To: stephen; +Cc: pshelar, netdev
In-Reply-To: <20130216093815.45e2d8b2@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 16 Feb 2013 09:38:15 -0800
> Should not use assignment in conditional:
> warning: suggest parentheses around assignment used as truth value [-Wparentheses]
>
> Problem introduced by:
> commit 14bbd6a565e1bcdc240d44687edb93f721cfdf99
> Author: Pravin B Shelar <pshelar@nicira.com>
> Date: Thu Feb 14 09:44:49 2013 +0000
>
> net: Add skb_unclone() helper function.
>
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv4: xfrm4_mode_tunnel: Fix warning
From: David Miller @ 2013-02-18 17:42 UTC (permalink / raw)
To: fabio.estevam; +Cc: pshelar, edumazet, netdev
In-Reply-To: <1361195127-17889-1-git-send-email-fabio.estevam@freescale.com>
Stephen Hemminger already submitted the patches necessary to fix these
warnings.
^ permalink raw reply
* Re: [PATCH net-next 3/9] bnx2x: handle spurious interrupts
From: David Miller @ 2013-02-18 17:39 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1361175398-12888-4-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Mon, 18 Feb 2013 10:16:32 +0200
> In scenarios in which a previous driver was removed without proper cleanup
> (e.g., kdump), it is possible for the chip to generate an interrupt without
> any apparent reason.
> This would cause improper behaviour at best, possibly resulting in NULL
> pointer dereferences as interrupts might be sent to an ISR accessing
> uninitialized structures and memories.
>
> This causes the driver to ignore any interrupt which arrives in an
> inappropriate time, i.e., when the driver has not yet properly configured
> its interrupt routines.
>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
I cannot accept this patch.
You must not request_irq() until your software state is completely
setup, there are no exceptions to this rule.
^ permalink raw reply
* AW: AW: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
From: Stefan Behte @ 2013-02-18 17:38 UTC (permalink / raw)
To: Oleg, Tantilov, Emil S, netdev
Cc: Skidmore, Donald C, Kirsher, Jeffrey T, Fujinaka, Todd,
Ronciak, John
In-Reply-To: <146051361207312@web23e.yandex.ru>
Hi,
printk("DEBUG comp_codes_1g: %u\n", comp_codes_1g);
results in:
Feb 18 18:36:09 n128 kernel: [26043.714408] DEBUG comp_codes_1g: 2
Best regards,
Stefan Behte
-----Ursprüngliche Nachricht-----
Von: Oleg [mailto:sysoleg@yandex.ru]
Gesendet: Montag, 18. Februar 2013 18:09
An: Stefan Behte; Tantilov, Emil S; netdev@vger.kernel.org
Cc: Skidmore, Donald C; Kirsher, Jeffrey T; Fujinaka, Todd; Ronciak, John
Betreff: Re: AW: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
18.02.2013, 16:13, "Stefan Behte" <s.behte@babiel.com>:
>> 1. What is the SFP+ module you are using (make/model/type)?
>
> The module is a TP-Link TL-SM311LS 1000BASE-LX LC.
I've seen some transceivers that have "Code for electronic or
optical compatibility" EEPROM field (see SFF-8472) set to
all-zeroes. Maybe this is your case. Could you please printk
value of comp_codes_1g variable somewhere?
--
wbr, Oleg.
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
^ permalink raw reply
* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates 2013.02.16
From: David Miller @ 2013-02-18 17:37 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1361003616-3422-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 16 Feb 2013 00:33:21 -0800
> This series contains updates to e1000, e1000e, igb, igbvf and ixgbe.
> The e1000, e1000e, igb and igbvf are single patch changes and the
> remaining 11 patches are all against ixgbe.
...
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled.
I trust that Emil will work out the I2C mutex locking issues being
discussed with Michał Mirosław wrt. patch #13.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: fix a compile error when SOCK_REFCNT_DEBUG is enabled
From: David Miller @ 2013-02-18 17:31 UTC (permalink / raw)
To: ying.xue; +Cc: netdev
In-Reply-To: <1361003305-1198-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Sat, 16 Feb 2013 16:28:25 +0800
> When SOCK_REFCNT_DEBUG is enabled, below build error is met:
>
> kernel/sysctl_binary.o: In function `sk_refcnt_debug_release':
> include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
> kernel/sysctl.o:include/net/sock.h:1025: first defined here
> kernel/audit.o: In function `sk_refcnt_debug_release':
> include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
> kernel/sysctl.o:include/net/sock.h:1025: first defined here
> make[1]: *** [kernel/built-in.o] Error 1
> make: *** [kernel] Error 2
>
> So we decide to make sk_refcnt_debug_release static to eliminate
> the error.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net-next] net: move ioctl functions into a separated file
From: David Miller @ 2013-02-18 17:28 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <1361002846-18088-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Sat, 16 Feb 2013 16:20:46 +0800
> From: Cong Wang <xiyou.wangcong@gmail.com>
>
> They well deserve a separated unit.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH]net: ehea module param description fix
From: David Miller @ 2013-02-18 17:26 UTC (permalink / raw)
To: dyoung; +Cc: linux-kernel, netdev
In-Reply-To: <511f24e7.iqc1+9PTu6xF8JTF%dyoung@redhat.com>
From: dyoung@redhat.com
Date: Sat, 16 Feb 2013 14:19:19 +0800
> In ehea.h the minimal entries is 2^7 - 1:
> #define EHEA_MIN_ENTRIES_QP 127
>
> Thus change the module param description accordinglly
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: optimize inet6_hash_frag()
From: David Miller @ 2013-02-18 17:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1360988088.19353.46.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 15 Feb 2013 20:14:48 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Use ipv6_addr_hash() and a single jhash invocation.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] tipc: two cleanups, plus overload respin
From: David Miller @ 2013-02-18 17:22 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, jon.maloy, ying.xue, nhorman
In-Reply-To: <1360969067-29956-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 15 Feb 2013 17:57:44 -0500
> Two relatively small cleanup patches here, plus a reimplementation
> of the patch Neil had questions about[1] in the last development
> cycle.
>
> Tested on today's net-next, between 32 and 64 bit x86 machines using
> the server/client in tipc-utils, as usual.
>
> [1] http://patchwork.ozlabs.org/patch/204507/
Pulled, thanks Paul.
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Michel Lespinasse @ 2013-02-18 17:21 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: tglx, peterz, tj, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel, vincent.guittot
In-Reply-To: <51225A36.40600@linux.vnet.ibm.com>
On Tue, Feb 19, 2013 at 12:43 AM, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
>> I am wondering though, if you could take care of recursive uses in
>> get/put_online_cpus_atomic() instead of doing it as a property of your
>> rwlock:
>>
>> get_online_cpus_atomic()
>> {
>> unsigned long flags;
>> local_irq_save(flags);
>> if (this_cpu_inc_return(hotplug_recusion_count) == 1)
>> percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
>> local_irq_restore(flags);
>> }
>>
>> Once again, the idea there is to avoid baking the reader side
>> recursive properties into your rwlock itself, so that it won't be
>> impossible to implement reader/writer fairness into your rwlock in the
>> future (which may be not be very important for the hotplug use, but
>> could be when other uses get introduced).
>
> Hmm, your proposal above looks good to me, at first glance.
> (Sorry, I had mistaken your earlier mails to mean that you were against
> recursive reader-side, while you actually meant that you didn't like
> implementing the recursive reader-side logic using the recursive property
> of rwlocks).
To be honest, I was replying as I went through the series, so I hadn't
digested your hotplug use case yet :)
But yes - I don't like having the rwlock itself be recursive, but I do
understand that you have a legitimate requirement for
get_online_cpus_atomic() to be recursive. This IMO points to the
direction I suggested, of explicitly handling the recusion in
get_online_cpus_atomic() so that the underlying rwlock doesn't have to
support recursive reader side itself.
(And this would work for the idea of making writers own the reader
side as well - you can do it with the hotplug_recursion_count instead
of with the underlying rwlock).
> While your idea above looks good, it might introduce more complexity
> in the unlock path, since this would allow nesting of heterogeneous readers
> (ie., if hotplug_recursion_count == 1, you don't know whether you need to
> simply decrement the counter or unlock the rwlock as well).
Well, I think the idea doesn't make the underlying rwlock more
complex, since you could in principle keep your existing
percpu_read_lock_irqsafe implementation as is and just remove the
recursive behavior from its documentation.
Now ideally if we're adding a bit of complexity in
get_online_cpus_atomic() it'd be nice if we could remove some from
percpu_read_lock_irqsafe, but I haven't thought about that deeply
either. I think you'd still want to have the equivalent of a percpu
reader_refcnt, except it could now be a bool instead of an int, and
percpu_read_lock_irqsafe would still set it to back to 0/false after
acquiring the global read side if a writer is signaled. Basically your
existing percpu_read_lock_irqsafe code should still work, and we could
remove just the parts that were only there to deal with the recursive
property.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: AW: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
From: Oleg @ 2013-02-18 17:08 UTC (permalink / raw)
To: Stefan Behte, Tantilov, Emil S, netdev@vger.kernel.org
Cc: Skidmore, Donald C, Kirsher, Jeffrey T, Fujinaka, Todd,
Ronciak, John
In-Reply-To: <D76AF9B3DDF5FF49833AC0A1396549060314FC0C@s554.babiel.com>
18.02.2013, 16:13, "Stefan Behte" <s.behte@babiel.com>:
>> 1. What is the SFP+ module you are using (make/model/type)?
>
> The module is a TP-Link TL-SM311LS 1000BASE-LX LC.
I've seen some transceivers that have "Code for electronic or
optical compatibility" EEPROM field (see SFF-8472) set to
all-zeroes. Maybe this is your case. Could you please printk
value of comp_codes_1g variable somewhere?
--
wbr, Oleg.
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
^ permalink raw reply
* Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
From: Andy King @ 2013-02-18 17:09 UTC (permalink / raw)
To: Sasha Levin
Cc: netdev, linux-kernel, virtualization, gregkh, davem, pv-drivers,
kraxel
In-Reply-To: <CA+1xoqfWGUuFjruFk1UV1BAXwzZvX4_i0MShQEpsq69B6P9ieg@mail.gmail.com>
Hi Sasha,
> > + * Specifically, we initialize the vsock_bind_table array to a size of
> > + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
...
> Why isn't it using the kernel's linux/hashtable.h?
Gah, that's a leftover from when it was platform independent :/ I have a
patch lying around to address this, once we have some more fixes batched
up I'll send it out. Sorry about that!
Thanks!
- Andy
^ 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