* Re: [PATCH] netdev: Fix sleeping inside wait event
From: Peter Zijlstra @ 2014-10-29 17:31 UTC (permalink / raw)
To: Cong Wang
Cc: Fengguang Wu, LKP, LKML, oleg@redhat.com, Eric W. Biederman,
David Miller, Linux Kernel Network Developers
In-Reply-To: <20141029171345.GO12706@worktop.programming.kicks-ass.net>
On Wed, Oct 29, 2014 at 06:13:45PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 09:29:55AM -0700, Cong Wang wrote:
> > While you are on it, please fix rtnl_lock_unregistering_all() too?
>
> Ah, that's hidden someplace else, sure I can do that. Thanks for
> pointing it out.
Here goes..
---
Subject: netdev: Fix sleeping inside wait event
From: Peter Zijlstra <peterz@infradead.org>
Date: Wed Oct 29 17:04:56 CET 2014
rtnl_lock_unregistering*() take rtnl_lock() -- a mutex -- inside a
wait loop. The wait loop relies on current->state to function, but so
does mutex_lock(), nesting them makes for the inner to destroy the
outer state.
Fix this using the new wait_woken() bits.
Cc: David Miller <davem@davemloft.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
net/core/dev.c | 10 +++++-----
net/core/rtnetlink.c | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7196,11 +7196,10 @@ static void __net_exit rtnl_lock_unregis
*/
struct net *net;
bool unregistering;
- DEFINE_WAIT(wait);
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+ add_wait_queue(&netdev_unregistering_wq, &wait);
for (;;) {
- prepare_to_wait(&netdev_unregistering_wq, &wait,
- TASK_UNINTERRUPTIBLE);
unregistering = false;
rtnl_lock();
list_for_each_entry(net, net_list, exit_list) {
@@ -7212,9 +7211,10 @@ static void __net_exit rtnl_lock_unregis
if (!unregistering)
break;
__rtnl_unlock();
- schedule();
+
+ wait_woken(&wait, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
}
- finish_wait(&netdev_unregistering_wq, &wait);
+ remove_wait_queue(&netdev_unregistering_wq, &wait);
}
static void __net_exit default_device_exit_batch(struct list_head *net_list)
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -365,11 +365,10 @@ static void rtnl_lock_unregistering_all(
{
struct net *net;
bool unregistering;
- DEFINE_WAIT(wait);
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+ add_wait_queue(&netdev_unregistering_wq, &wait);
for (;;) {
- prepare_to_wait(&netdev_unregistering_wq, &wait,
- TASK_UNINTERRUPTIBLE);
unregistering = false;
rtnl_lock();
for_each_net(net) {
@@ -381,9 +380,10 @@ static void rtnl_lock_unregistering_all(
if (!unregistering)
break;
__rtnl_unlock();
- schedule();
+
+ wait_woken(&wait, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
}
- finish_wait(&netdev_unregistering_wq, &wait);
+ remove_wait_queue(&netdev_unregistering_wq, &wait);
}
/**
^ permalink raw reply
* Re: [PATCH] netdev: Fix sleeping inside wait event
From: Peter Zijlstra @ 2014-10-29 17:13 UTC (permalink / raw)
To: Cong Wang
Cc: Fengguang Wu, LKP, LKML, oleg@redhat.com, Eric W. Biederman,
David Miller, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXTyBT_4TrnYAoAuAE_jMto=2B=cutFggpHRMhvSrG7qg@mail.gmail.com>
On Wed, Oct 29, 2014 at 09:29:55AM -0700, Cong Wang wrote:
> (Adding netdev@...)
>
> On Wed, Oct 29, 2014 at 9:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Dave, this relies on bits currently in tip/sched/core, if you're ok I'll
> > merge it through that tree.
> >
> > ---
> > Subject: netdev: Fix sleeping inside wait event
> > From: Peter Zijlstra <peterz@infradead.org>
> > Date: Wed Oct 29 17:04:56 CET 2014
> >
> > rtnl_lock_unregistering() takes rtnl_lock() -- a mutex -- inside a
> > wait loop. The wait loop relies on current->state to function, but so
> > does mutex_lock(), nesting them makes for the inner to destroy the
> > outer state.
> >
>
> While you are on it, please fix rtnl_lock_unregistering_all() too?
Ah, that's hidden someplace else, sure I can do that. Thanks for
pointing it out.
^ permalink raw reply
* Re: [PATCH] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-10-29 17:08 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: linuxppc-dev, Matt Evans, netdev@vger.kernel.org
In-Reply-To: <CAOJe8K0t3G-bHm_24GjrTp9mmKnYZS1_bdGgrwQBLjC_s5is6w@mail.gmail.com>
On Wed, Oct 29, 2014 at 2:21 AM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Any feedback from PPC folks?
not a ppc guy, but looks reasonable to me.
What lib/test_bpf says? Like performance difference before/after
for LD_PKTTYPE test...
^ permalink raw reply
* Re: [PATCH] netdev: Fix sleeping inside wait event
From: Cong Wang @ 2014-10-29 16:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Fengguang Wu, LKP, LKML, oleg@redhat.com, Eric W. Biederman,
David Miller, Linux Kernel Network Developers
In-Reply-To: <20141029161657.GF3337@twins.programming.kicks-ass.net>
(Adding netdev@...)
On Wed, Oct 29, 2014 at 9:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> Dave, this relies on bits currently in tip/sched/core, if you're ok I'll
> merge it through that tree.
>
> ---
> Subject: netdev: Fix sleeping inside wait event
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed Oct 29 17:04:56 CET 2014
>
> rtnl_lock_unregistering() takes rtnl_lock() -- a mutex -- inside a
> wait loop. The wait loop relies on current->state to function, but so
> does mutex_lock(), nesting them makes for the inner to destroy the
> outer state.
>
While you are on it, please fix rtnl_lock_unregistering_all() too?
Thanks!
> Fix this using the new wait_woken() bits.
>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Cc: David Miller <davem@davemloft.net>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> net/core/dev.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7196,11 +7196,10 @@ static void __net_exit rtnl_lock_unregis
> */
> struct net *net;
> bool unregistering;
> - DEFINE_WAIT(wait);
> + DEFINE_WAIT_FUNC(wait, woken_wake_function);
>
> + add_wait_queue(&netdev_unregistering_wq, &wait);
> for (;;) {
> - prepare_to_wait(&netdev_unregistering_wq, &wait,
> - TASK_UNINTERRUPTIBLE);
> unregistering = false;
> rtnl_lock();
> list_for_each_entry(net, net_list, exit_list) {
> @@ -7212,9 +7211,10 @@ static void __net_exit rtnl_lock_unregis
> if (!unregistering)
> break;
> __rtnl_unlock();
> - schedule();
> +
> + wait_woken(&wait, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
> }
> - finish_wait(&netdev_unregistering_wq, &wait);
> + remove_wait_queue(&netdev_unregistering_wq, &wait);
> }
>
> static void __net_exit default_device_exit_batch(struct list_head *net_list)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC] use smp_load_acquire()/smp_store_release()
From: Alexander Duyck @ 2014-10-29 16:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1414594159.631.85.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/29/2014 07:49 AM, Eric Dumazet wrote:
> Hi Alexander
>
> The memory barriers added in commit
> b37c0fbe3f6dfba1f8ad2aed47fb40578a254635
> ("net: Add memory barriers to prevent possible race in byte queue
> limits")
>
> have heavy cost.
>
> It seems we could use smp_load_acquire() and smp_store_release()
> instead ?
>
> I'll post a patch later today. I would be interested if someone was able
> to test it, as your commit apparently was tested and known to fix a
> reproducible race.
>
> Thanks !
Unfortunately Stephen left Intel before I did, so we will need to find
someone else in the validation team to test this if possible. I have
added Jeff to the CC so that he can give the appropriate validation
people a heads up that this patch might be coming.
As I recall what was seen was random Tx hangs on systems with the
original BQL code when interfaces were stressed. It has been a while so
I don't recall the exact set-up for all of it. Also some less
used/tested architectures such as PowerPC can be more susceptible to
synchronization issues such as these as the memory model is more weakly
ordered.
I'm wondering where you are seeing the barrier show up? In
netdev_tx_send_queue you should only hit the barrier if you actually are
triggering the XOFF condition, and in netdev_tx_completed_queue the
barrier should be coalesced in amongst a number of frames reducing the cost.
My concern with this would be that we are actually syncronizing multiple
things, the __QUEUE_STATE_STACK_XOFF flag, dql->adj_limit, and
dql->num_queued, and we might be trading off reducing the cost on x86 to
result in it being increased on other architectures as we may have to
actually add additional synchronization as I suspect we would need to
use acquire/release on both adj_limit and num_queued.
Thanks,
Alex
^ permalink raw reply
* Re: [patch] iwlwifi: cleanup a mask shift in iwlagn_bt_traffic_is_sco()
From: Emmanuel Grumbach @ 2014-10-29 16:16 UTC (permalink / raw)
To: Dan Carpenter
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
John W. Linville, Paul Gortmaker, Larry Finger, linux-wireless,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors
In-Reply-To: <20141029160827.GD5290@mwanda>
On Wed, Oct 29, 2014 at 6:08 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The shift operation is higher precedence so the code is wrong and it
> sets of a static checker warning. But it doesn't affect real life
> because BT_UART_MSG_FRAME3SCOESCO_POS is zero so the shift is a no-op.
>
> I have re-written it in normal style and with parenthesis as a cleanup
> and to silence the static checker warning.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
In my tree already - I got it from Joe.
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-next.git/commit/?id=50f6635afe565a0e1c5ab78f040294fe1dc41de0
^ permalink raw reply
* [patch] Bluetooth: 6lowpan: use after free in disconnect_devices()
From: Dan Carpenter @ 2014-10-29 16:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo Padovan, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel, kernel-janitors
This was accidentally changed from list_for_each_entry_safe() to
list_for_each_entry() so now it has a use after free bug. I've changed
it back.
Fixes: 90305829635d ('Bluetooth: 6lowpan: Converting rwlocks to use RCU')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 7254bdd..eef298d 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -1383,7 +1383,7 @@ static const struct file_operations lowpan_control_fops = {
static void disconnect_devices(void)
{
- struct lowpan_dev *entry, *new_dev;
+ struct lowpan_dev *entry, *tmp, *new_dev;
struct list_head devices;
INIT_LIST_HEAD(&devices);
@@ -1408,7 +1408,7 @@ static void disconnect_devices(void)
rcu_read_unlock();
- list_for_each_entry(entry, &devices, list) {
+ list_for_each_entry_safe(entry, tmp, &devices, list) {
ifdown(entry->netdev);
BT_DBG("Unregistering netdev %s %p",
entry->netdev->name, entry->netdev);
^ permalink raw reply related
* [patch] iwlwifi: cleanup a mask shift in iwlagn_bt_traffic_is_sco()
From: Dan Carpenter @ 2014-10-29 16:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Emmanuel Grumbach, Intel Linux Wireless, John W. Linville,
Paul Gortmaker, Larry Finger, linux-wireless, netdev,
linux-kernel, kernel-janitors
The shift operation is higher precedence so the code is wrong and it
sets of a static checker warning. But it doesn't affect real life
because BT_UART_MSG_FRAME3SCOESCO_POS is zero so the shift is a no-op.
I have re-written it in normal style and with parenthesis as a cleanup
and to silence the static checker warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/iwlwifi/dvm/lib.c b/drivers/net/wireless/iwlwifi/dvm/lib.c
index 2191621..065d3d5 100644
--- a/drivers/net/wireless/iwlwifi/dvm/lib.c
+++ b/drivers/net/wireless/iwlwifi/dvm/lib.c
@@ -418,7 +418,7 @@ void iwlagn_bt_adjust_rssi_monitor(struct iwl_priv *priv, bool rssi_ena)
static bool iwlagn_bt_traffic_is_sco(struct iwl_bt_uart_msg *uart_msg)
{
- return BT_UART_MSG_FRAME3SCOESCO_MSK & uart_msg->frame3 >>
+ return (uart_msg->frame3 & BT_UART_MSG_FRAME3SCOESCO_MSK) >>
BT_UART_MSG_FRAME3SCOESCO_POS;
}
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] cfg80211: fix set but not used warning in nl80211_channel_switch()
From: Johannes Berg @ 2014-10-29 16:04 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel, John W. Linville, David S. Miller, linux-wireless,
netdev
In-Reply-To: <1414252655-20506-1-git-send-email-fabf@skynet.be>
On Sat, 2014-10-25 at 17:57 +0200, Fabian Frederick wrote:
> radar_detect_width is unused since commit 97dc94f1d933
> ("cfg80211: remove channel_switch combination check")
Applied, thanks.
johannes
^ permalink raw reply
* Fw: [Bug 87111] New: hlist_for_each_entry_rcu() returns invalid pointer causing kernel to OOPS
From: Stephen Hemminger @ 2014-10-29 15:57 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 29 Oct 2014 07:16:13 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 87111] New: hlist_for_each_entry_rcu() returns invalid pointer causing kernel to OOPS
https://bugzilla.kernel.org/show_bug.cgi?id=87111
Bug ID: 87111
Summary: hlist_for_each_entry_rcu() returns invalid pointer
causing kernel to OOPS
Product: Networking
Version: 2.5
Kernel Version: 2.6.32.24
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: jith131986@gmail.com
Regression: No
Created attachment 155781
--> https://bugzilla.kernel.org/attachment.cgi?id=155781&action=edit
nf_nat.ko objdump for analysing IP and offset to see exact line where kernel
panic happened
In my setup linux stack is only used for layer 2 network services. when layer 2
packet is recieved by linux for layer 2 functionality, in nf_nat kernel module
hlist_for_each_entry_rcu()(where IP points) function return an invalid pointer
resulting in Oops panic. I have attached panic dump and nf_nat.ko objdump for
further analysis.
Would like to know the issue is seen/reported before and fixed ?. If not is it
possible to get cause or solution for the same.
Pasting the panic dump below and attaching nf_nat.ko objdump
<1>BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
<1>IP: [<ffffffffa003794b>] nf_nat_setup_info+0x1ab/0x740 [nf_nat]
<6>PGD 641576067 PUD 7dd9f3067 PMD 0
<0>Oops: 0000 [#1] PREEMPT SMP
<0>last sysfs file:
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host5/scsi_host/host5/proc_name
<6>CPU 3
<6>Modules linked in: bridge stp llc ixgbe igb ftdi_sio usbserial xt_connlimit
xt_tcpudp xt_mark iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_conntrack iptable_filter ip_tables x_tables
<6>Pid: 0, comm: swapper Tainted: P W 2.6.32.24 #1 S5520UR
<6>RIP: e030:[<ffffffffa003794b>] [<ffffffffa003794b>]
nf_nat_setup_info+0x1ab/0x740 [nf_nat]
<6>RSP: e02b:ffff88002808d910 EFLAGS: 00010282
<6>RAX: 0000000000000000 RBX: ffff880381313b58 RCX: 0000000000000000
<6>RDX: 0000000000000018 RSI: 000000007049f4f6 RDI: ffff88002808d9b0
<6>RBP: ffff88002808da10 R08: ffffffff81393e80 R09: ffffffffa0040790
<6>R10: 0000000000004000 R11: 000000000000002c R12: ffff88002808da20
<6>R13: ffff8807fc8ebfd8 R14: ffff880396c3bb70 R15: 0000000000000000
<6>FS: 00007fde2cd296f0(0000) GS:ffff88002808a000(0000) knlGS:0000000000000000
<6>CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
<6>CR2: 000000000000003e CR3: 000000079ab27000 CR4: 0000000000002660
<6>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<6>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<6>Process swapper (pid: 0, threadinfo ffff8807fc8ea000, task ffff8807fc8da050)
<0>Stack:
<6> 0000000000000000 ffff88002808d980 ffff88002808da2c ffff88002808da2e
<6><0> ffff8807fc8ea000 ffff8807fc8ebfd8 0000000000000100 0000000000000100
<6><0> 0000000000000000 0000000000010001 00000000002ace3f ffff88002809a720
<0>Call Trace:
<0> <IRQ>
<6> [<ffffffff81048b07>] ? local_bh_enable+0x77/0xc0
<6> [<ffffffffa0009945>] ? ipt_do_table+0x2a5/0x3e0 [ip_tables]
<6> [<ffffffffa00400cf>] alloc_null_binding+0x3f/0x70 [iptable_nat]
<6> [<ffffffffa00402fb>] nf_nat_rule_find+0x1fb/0x390 [iptable_nat]
<6> [<ffffffff8138ca3f>] nf_iterate+0x5f/0x90
<6> [<ffffffff81393e80>] ? ip_local_deliver_finish+0x0/0x1e0
<6> [<ffffffff8138cdb0>] nf_hook_slow+0xb0/0x110
<6> [<ffffffff81393e80>] ? ip_local_deliver_finish+0x0/0x1e0
<6> [<ffffffff81394559>] ip_local_deliver+0x69/0x90
<6> [<ffffffff81393ba6>] ip_rcv_finish+0x146/0x420
<6> [<ffffffff8139440d>] ip_rcv+0x27d/0x360
<6> [<ffffffff81371747>] netif_receive_skb+0x2b7/0x390
<6> [<ffffffffa12cce50>] br_handle_frame_finish+0x130/0x170 [bridge]
<6> [<ffffffffa12d1458>] br_netfilter_fini+0x6a8/0x810 [bridge]
<6> [<ffffffff8138cdb0>] ? nf_hook_slow+0xb0/0x110
<6> [<ffffffffa12d1270>] ? br_netfilter_fini+0x4c0/0x810 [bridge]
<6> [<ffffffffa12d2389>] nf_bridge_copy_header+0xdc9/0x10e0 [bridge]
<6> [<ffffffff8138ca3f>] nf_iterate+0x5f/0x90
<6> [<ffffffffa12ccd20>] ? br_handle_frame_finish+0x0/0x170 [bridge]
<6> [<ffffffff8138cdb0>] nf_hook_slow+0xb0/0x110
<6> [<ffffffffa12ccd20>] ? br_handle_frame_finish+0x0/0x170 [bridge]
<6> [<ffffffffa12ccfe6>] br_handle_frame+0x156/0x2b0 [bridge]
<6> [<ffffffff813f2ab8>] ? vlan_skb_recv+0x1a8/0x2f0
<6> [<ffffffff81371699>] netif_receive_skb+0x209/0x390
<6> [<ffffffff81374d79>] process_backlog+0x89/0xc0
<6> [<ffffffff81374b7f>] net_rx_action+0x7f/0x160
<6> [<ffffffffa0078165>] ? igb_reinit_locked+0x1995/0x2900 [igb]
<6> [<ffffffff810484f8>] __do_softirq+0xa8/0x130
<6> [<ffffffff810755a8>] ? handle_level_irq+0xe8/0x130
<6> [<ffffffff81014efc>] call_softirq+0x1c/0x30
<6> [<ffffffff81016765>] do_softirq+0x65/0xa0
<6> [<ffffffff81048358>] irq_exit+0x48/0x50
<6> [<ffffffff81228ddd>] xen_evtchn_do_upcall+0x3d/0x60
<6> [<ffffffff81014f4e>] xen_do_hypervisor_callback+0x1e/0x30
<0> <EOI>
<6> [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1010
<6> [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1010
<6> [<ffffffff8100f8d0>] ? xen_safe_halt+0x10/0x20
<6> [<ffffffff8100c4d5>] ? xen_idle+0x45/0x70
<6> [<ffffffff81012d78>] ? cpu_idle+0x58/0x90
<6> [<ffffffff810101c9>] ? xen_irq_enable_direct_end+0x0/0x7
<6> [<ffffffff8140a86e>] ? cpu_bringup_and_idle+0xe/0x10
<0>Code: ff ff ff 49 8d 44 24 0c 48 89 85 10 ff ff ff eb 0c 48 8b 1b 48 85 db
0f 84 f1 00 00 00 48 8b 4b 20 48 8b 03 48 8d 51 18 0f 18 08 <0f> b6 42 26 3a 45
c6 75 dd 8b 02 3b 45 a0 75 d6 0f b7 42 10 66
<1>RIP [<ffffffffa003794b>] nf_nat_setup_info+0x1ab/0x740 [nf_nat]
<6> RSP <ffff88002808d910>
<0>CR2: 000000000000003e
WARN paging error trying to follow 0x0000000000000000 - level 2, cr3
000000058ea67000
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next
From: Sabrina Dubroca @ 2014-10-29 15:56 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, peterz, jeffrey.t.kirsher
commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included
in today's linux-next added a check that fires on e1000 with netpoll:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
no locks held by systemd/1.
irq event stamp: 10102965
hardirqs last enabled at (10102965): [<ffffffff810cbafd>] vprintk_emit+0x2dd/0x6a0
hardirqs last disabled at (10102964): [<ffffffff810cb897>] vprintk_emit+0x77/0x6a0
softirqs last enabled at (10102342): [<ffffffff810666aa>] __do_softirq+0x27a/0x6f0
softirqs last disabled at (10102337): [<ffffffff81066e86>] irq_exit+0x56/0xe0
Preemption disabled at:[<ffffffff817de50d>] printk_emit+0x31/0x33
CPU: 1 PID: 1 Comm: systemd Not tainted 3.18.0-rc2-next-20141029-dirty #222
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
ffffffff81a82291 ffff88001e743978 ffffffff817df31d 0000000000000000
0000000000000000 ffff88001e7439a8 ffffffff8108dfa2 ffff88001e7439a8
ffffffff81a82291 0000000000000068 0000000000000000 ffff88001e7439d8
Call Trace:
[<ffffffff817df31d>] dump_stack+0x4f/0x7c
[<ffffffff8108dfa2>] ___might_sleep+0x182/0x2b0
[<ffffffff8108e10a>] __might_sleep+0x3a/0xc0
[<ffffffff810ce358>] synchronize_irq+0x38/0xa0
[<ffffffff810ce633>] ? __disable_irq_nosync+0x43/0x70
[<ffffffff810ce690>] disable_irq+0x20/0x30
[<ffffffff815d7253>] e1000_netpoll+0x23/0x60
[<ffffffff81678d02>] netpoll_poll_dev+0x72/0x3a0
[<ffffffff817e9993>] ? _raw_spin_trylock+0x73/0x90
[<ffffffff8167920f>] ? netpoll_send_skb_on_dev+0x1df/0x2e0
[<ffffffff816791e7>] netpoll_send_skb_on_dev+0x1b7/0x2e0
[<ffffffff816795f3>] netpoll_send_udp+0x2e3/0x490
[<ffffffff815d1f61>] ? write_msg+0x51/0x140
[<ffffffff815d1fdf>] write_msg+0xcf/0x140
[<ffffffff810cadbb>] call_console_drivers.constprop.22+0x13b/0x2a0
[<ffffffff810cb6bd>] console_unlock+0x39d/0x500
[<ffffffff810cbb3e>] ? vprintk_emit+0x31e/0x6a0
[<ffffffff810cbb5c>] vprintk_emit+0x33c/0x6a0
[<ffffffff811a6c6e>] ? might_fault+0x5e/0xc0
[<ffffffff817de50d>] printk_emit+0x31/0x33
[<ffffffff810cbfad>] devkmsg_write+0xbd/0x110
[<ffffffff811f24d5>] do_iter_readv_writev+0x65/0xa0
[<ffffffff811f3b72>] do_readv_writev+0xe2/0x290
[<ffffffff810cbef0>] ? vprintk+0x30/0x30
[<ffffffff810d499d>] ? rcu_read_lock_held+0x6d/0x70
[<ffffffff812142d6>] ? __fget_light+0xc6/0xd0
[<ffffffff811f3dac>] vfs_writev+0x3c/0x50
[<ffffffff811f3eed>] SyS_writev+0x4d/0xe0
[<ffffffff817ea16d>] system_call_fastpath+0x16/0x1b
I'm able to reproduce it consistently by sending a lot of packets from
that interface while writing to /dev/kmsg with netconsole
enabled. Just writing to /dev/kmsg isn't enough.
# with ping -f or pktgen running
for i in `seq 1 20` ; do echo '............................................' > /dev/kmsg ; done
--
Sabrina
^ permalink raw reply
* Re: some failures with vxlan offloads..
From: Or Gerlitz @ 2014-10-29 15:56 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org
In-Reply-To: <CA+mtBx9TCtHgW=TegUgjZ6Se=mP+0CNiNHYmbYHPd1cJJGYoBQ@mail.gmail.com>
On 10/29/2014 4:59 PM, Tom Herbert wrote:
>> >OK, I'll look there. Anything that should worries us at that stack trace I
>> >sent in my initial email of this thread, or you think this is related to the
>> >mlx4 driver checksum bug?
>> >
> The trace doesn't seem like it would be related to a checksum bug. Do you only see this with offload enabled?
no, it happened on the server side of configuration #4 in my original
email, which is offloaded client and non-offloaded server.
Or.
^ permalink raw reply
* Re: [patch] SUNRPC: off by one in BUG_ON()
From: J. Bruce Fields @ 2014-10-29 15:38 UTC (permalink / raw)
To: Dan Carpenter
Cc: Trond Myklebust, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141029084416.GC8939@mwanda>
On Wed, Oct 29, 2014 at 11:44:16AM +0300, Dan Carpenter wrote:
> The m->pool_to[] array has "maxpools" number of elements. It's
> allocated in svc_pool_map_alloc_arrays() which we called earlier in the
> function. This test should be >= instead of >.
>
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> This is very old code, but hopefully the off by one doesn't affect
> runtime.
Yeah, doesn't look like a big deal, but thanks, applying for 3.19.--b.
>
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index ca8a795..349c98f 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -189,7 +189,7 @@ svc_pool_map_init_percpu(struct svc_pool_map *m)
> return err;
>
> for_each_online_cpu(cpu) {
> - BUG_ON(pidx > maxpools);
> + BUG_ON(pidx >= maxpools);
> m->to_pool[cpu] = pidx;
> m->pool_to[pidx] = cpu;
> pidx++;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] mac80211_hwsim: release driver when ieee80211_register_hw fails
From: Johannes Berg @ 2014-10-29 15:31 UTC (permalink / raw)
To: Junjie Mao
Cc: Martin Pitt, Fengguang Wu, linux-wireless, netdev, linux-kernel
In-Reply-To: <1414459907-7509-1-git-send-email-eternal.n08@gmail.com>
On Tue, 2014-10-28 at 09:31 +0800, Junjie Mao wrote:
> The driver is not released when ieee80211_register_hw fails in
> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> possibly freed) device in platform_driver_unregister:
Applied.
johannes
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Alexei Starovoitov @ 2014-10-29 15:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1414563627.631.75.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Oct 28, 2014 at 11:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-28 at 22:13 -0700, Alexei Starovoitov wrote:
>
>> tried 50 parallel netperf -t TCP_RR over ixgbe
>> and perf top were tcp stack bits, qdisc locks and netperf itself.
>> What do you see?
>
> You are kidding right ?
>
> If you save 30 nsec ( 2 * 15 nsec) per transaction, and rtt is about 20
> usec, its a 0.15 % gain. Not bad for a trivial patch.
agreed.
I wasn't arguing against the patch at all. Was just curious
what performance gain we'll see. 0.15% is tiny and some might
say the code bloat is not worth it, but imo it's a good one. ack.
> Every atomic op we remove/avoid, every irq masking unmasking we remove,
> every cache line miss or extra bus transaction we remove, TLB miss, is
> the path for better latency.
yes. We're saying the same thing.
^ permalink raw reply
* Re: some failures with vxlan offloads..
From: Tom Herbert @ 2014-10-29 14:59 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev@vger.kernel.org
In-Reply-To: <54508020.1040305@mellanox.com>
On Tue, Oct 28, 2014 at 10:50 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 10/28/2014 5:36 PM, Tom Herbert wrote:
>>>
>>> I wonder if we have another bug somewhere... when both sides were
>>> offloaded,
>>> >it works even with the mlx4 bug, canyou explain that?is it possible that
>>> > the
>>> >GRO stack somehow covers on the bug when both sides are offloaded and
>>> >GRO/VXLAN comes into play?
>>>
>> Look at the receive side. As I mentioned, if the device is returning
>> checksum-unnecessary and setting csum_level to 1 (inner checksum was
>> validated) then stack won't try to verify the outer checksum. So in
>> this case if outer checksum is incorrect nobody complains about it.
>
>
> OK, I'll look there. Anything that should worries us at that stack trace I
> sent in my initial email of this thread, or you think this is related to the
> mlx4 driver checksum bug?
>
The trace doesn't seem like it would be related to a checksum bug. Do
you only see this with offload enabled?
> Or.
>
>>
>
^ permalink raw reply
* [RFC] use smp_load_acquire()/smp_store_release()
From: Eric Dumazet @ 2014-10-29 14:49 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, Stephen Ko
Hi Alexander
The memory barriers added in commit
b37c0fbe3f6dfba1f8ad2aed47fb40578a254635
("net: Add memory barriers to prevent possible race in byte queue
limits")
have heavy cost.
It seems we could use smp_load_acquire() and smp_store_release()
instead ?
I'll post a patch later today. I would be interested if someone was able
to test it, as your commit apparently was tested and known to fix a
reproducible race.
Thanks !
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-29 14:37 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev, davem, ben, lorenzo
In-Reply-To: <1414487474-18201-1-git-send-email-ek@google.com>
On Di, 2014-10-28 at 18:11 +0900, Erik Kline wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
>
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
>
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
>
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
>
> Also, because optimistic nodes can receive frames, issue
> an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
> flag appropriately set). A second RTM_NEWADDR is sent if DAD
> completes (the address flags have changed), otherwise an
> RTM_DELADDR is sent.
>
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
>
> Signed-off-by: Erik Kline <ek@google.com>
> ---
>
> [...]
>
> +static inline bool ipv6_use_optimistic_addr(struct inet6_dev *idev)
> +{
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + return idev && idev->cnf.optimistic_dad && idev->cnf.use_optimistic;
Just a small nit: is this idev != NULL check necessary?
Otherwise:
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-29 14:34 UTC (permalink / raw)
To: Erik Kline
Cc: netdev@vger.kernel.org, David Miller, Ben Hutchings,
Lorenzo Colitti
In-Reply-To: <CAAedzxptbKLrO_0uPVqXiqOACqNNj9BeeakgB3+t+XxemeN3Sw@mail.gmail.com>
Hi Erik,
On Mi, 2014-10-29 at 18:34 +0900, Erik Kline wrote:
> Given that we spoke about this reduction in the number of netlink messages
> earlier, do you still think it's an issue?
No, it would be nice to have but as this is just a minor detail and
complexity would be too high I am fine with your current solution.
> The end result here is that for listeners on netlink sockets on systems
> that (a) have optimistic dad built-in, (b) have optimistic dad enabled, and
> (c) have use_optimistic set: they'll 2 notifications (with different flags)
> for automatically added addresses on these interfaces.
Ack, I see.
> (Personally, given that we appear to send an RTM_NEWADDR when the address
> gets deprecated (I think), I think sending one on every flag change of
> interest is in keeping with existing behaviour.)
It does make sense, I have no objections.
Bye,
Hannes
^ permalink raw reply
* Re: nfs stalls over loopback interface (no sk_data_ready events?)
From: Jeff Layton @ 2014-10-29 14:21 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Christoph Hellwig, Linux NFS Mailing List, Bruce Fields,
Trond Myklebust
In-Reply-To: <20141027152900.4e81a9d5-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Mon, 27 Oct 2014 15:29:00 -0400
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org> wrote:
> (sorry for resend -- I got the netdev address wrong)
>
> Sending this to netdev since I think I've now determined that this is
> not a NFS specific problem. Recently Christoph mentioned that he was
> seeing stalls when running xfstests generic/075 test on NFS over the
> loopback interface with v3.18-rc1-ish kernel.
>
> The configuration in this case is the nfs server and client on same box
> communicating over the lo interface.
>
> Here's are tracepoints from a typical request as it's supposed to work:
>
> mount.nfs-906 [002] ...1 22711.996969: xprt_transmit: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
> nfsd-678 [000] ...1 22711.997082: svc_recv: rq_xid=0xa8a34513 status=164
> nfsd-678 [000] ..s8 22711.997185: xprt_lookup_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
> nfsd-678 [000] ..s8 22711.997186: xprt_complete_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=140
> nfsd-678 [000] ...1 22711.997236: svc_send: rq_xid=0xa8a34513 dropme=0 status=144
> nfsd-678 [000] ...1 22711.997236: svc_process: rq_xid=0xa8a34513 dropme=0 status=144
>
> ...basically, we send a request to the server. Server picks it up and
> sends the reply, and then the client IDs that reply and processes it.
> This runs along just fine for ~ a minute or so. At some point, the
> client stops seeing replies come in:
>
> kworker/2:2-107 [002] ...1 22741.696070: xprt_transmit: xprt=0xffff8800ce961000 xid=0xc3a84513 status=0
> nfsd-678 [002] .N.1 22741.696917: svc_recv: rq_xid=0xc3a84513 status=208
> nfsd-678 [002] ...1 22741.699890: svc_send: rq_xid=0xc3a84513 dropme=0 status=262252
> nfsd-678 [002] ...1 22741.699891: svc_process: rq_xid=0xc3a84513 dropme=0 status=262252
>
>
> ...a bit more tracepoint work seems to show that we just stop getting
> sk_data_ready callbacks on the socket at all. I'm not terribly familiar
> with the lower-level socket code, so I figured I'd email here and ask...
>
> Anyone have insight into why this might be happening?
>
Looks some change that went into -rc2 has fixed the problem for me.
Christoph, can you confirm that this no longer occurs with -rc2?
--
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] mac80211_hwsim: release driver when ieee80211_register_hw fails
From: Fengguang Wu @ 2014-10-29 14:14 UTC (permalink / raw)
To: Junjie Mao
Cc: Martin Pitt, linux-wireless, netdev, linux-kernel, Dan Carpenter
In-Reply-To: <8638a718ft.fsf@MJJ-LAPTOP.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Oct 29, 2014 at 06:23:02PM +0800, Junjie Mao wrote:
> I was not familiar with the acquiring/releasing API either, until I met
> with this bug...
>
> Perhaps we can use static checkers to avoid these issues as early as
> possible. Any suggestions?
CC Dan. His smatch checker might be able (or could be enabled) to
handle the verification of missing device_release_driver() call.
Thanks,
Fengguang
> Martin Pitt <martin.pitt@ubuntu.com> writes:
>
> > Acked-By: Martin Pitt <martin.pitt@ubuntu.com>
> >
> > Hello Junjie,
> >
> > Junjie Mao [2014-10-28 9:31 +0800]:
> >> The driver is not released when ieee80211_register_hw fails in
> >> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> >> possibly freed) device in platform_driver_unregister:
> >
> > Many thanks for fixing this! Sorry about that, I don't know these bits
> > very well.
> >
> > Martin
^ permalink raw reply
* Re: spin lock held between 2 process
From: Eric Dumazet @ 2014-10-29 13:39 UTC (permalink / raw)
To: Chetan C R; +Cc: netdev
In-Reply-To: <CAJ8diHRu+L_kMMfTyPAz+cwTfeQXTOFWm-RBZQzFOp18kO70jQ@mail.gmail.com>
On Wed, 2014-10-29 at 14:32 +0530, Chetan C R wrote:
> Facing this look up issue in 3.4.0 kernel. Any pointers to resolve this issue?
>
3.4.0 is quite old. You should try newer kernels.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-29 12:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141028.165737.2009356944765978630.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Sun, 26 Oct 2014 00:38:47 +0200
>
> > These two patches allow turing on explicit congestion notification
> > based on the destination network.
> >
> > For example, assuming the default tcp_ecn sysctl '2', the following will
> > enable ecn (tcp_ecn=1 behaviour, i.e. request ecn to be enabled for a
> > tcp connection) for all connections to hosts inside the 192.168.2/24 network:
> >
> > ip route change 192.168.2.0/24 dev eth0 features ecn
> >
> > Having a more fine-grained per-route setting can be beneficial for
> > various reasons, for example 1) within data centers, or 2) local ISPs
> > may deploy ECN support for their own video/streaming services [1], etc.
> >
> > Joint work with Daniel Borkmann, feature suggested by Hannes Frederic Sowa.
> >
> > The patch to enable this in iproute2 will be posted shortly, it is currently
> > also available here:
> > http://git.breakpoint.cc/cgit/fw/iproute2.git/commit/?h=iproute_features&id=8843d2d8973fb81c78a7efe6d42e3a17d739003e
> >
> > [1] http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf, p.15
>
> I don't like how the route metric gives less control than the sysctl.
>
> If the tcp_ecn cases of '1' and '2' make sense for the sysctl, I do not
> see why they wouldn't make sense for the per-route knob to.
>
> Implement the following policy, if per-route metric is non-zero use it
> instead of the sysctl setting.
I think that if we add a u32 route attr for a new ecn switch we might as well
support full override of the sysctl.
I had a discussion with Daniel Borkmann, and we came up with this
proposal:
- add RTAX_ECN
- if RTAX_ECN attribute present, set RTAX_FEATURE_ECN in RTAX_FEATURES
- in kernel, when RTAX_FEATURE_ECN set, use dst_metric(dst, RTAX_ECN).
- else, if RTAX_FEATURE_ECN unset, use the sysctl as fallback.
It would allow things like sysctl_tcp_ecn=1 and
ip route change some_blackhole dev eth0 ecn 0
ip route change some_network dev eth0 ecn 2
ip route change other dev eth0 ecn 1
We could do that, if you prefer.
I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
then we want to enable 'passive' ecn for incoming connections only on
a particular route without announcing ecn to the peer. I haven't been
able to find any -- I think if you deem 'route to x' safe for ecn it
might as well be enabled for both initiator and responder. The original
patch would be sufficient for that.
IOW, is 'ecn from a to b but not b to a' a sensible requirement?
sysctl_tcp_ecn=2 seems just to be a convenience solution/intermediate
step to make the stack ecn-aware by default without too much breakage
risk for users (i.e. instead of having sysctl_tcp_ecn=1 as default).
Unrelated to this patch, but I'd like to see sysctl_tcp_ecn=1 as a
default at one point (almost no routers set CE bit at this time, perhaps
that would change if ecn usage is more widespread).
Thanks!
^ permalink raw reply
* [PATCH 1/1 net-next] ipv6: remove assignment in if condition
From: Fabian Frederick @ 2014-10-29 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
Do assignment before if condition and test !skb like in rawv6_recvmsg()
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv6/raw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 896af88..075a0fb 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -548,7 +548,8 @@ static int rawv6_push_pending_frames(struct sock *sk, struct flowi6 *fl6,
if (!rp->checksum)
goto send;
- if ((skb = skb_peek(&sk->sk_write_queue)) == NULL)
+ skb = skb_peek(&sk->sk_write_queue);
+ if (!skb)
goto out;
offset = rp->offset;
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] wireless: rt2x00: add new rt2800usb device
From: Stanislaw Gruszka @ 2014-10-29 11:48 UTC (permalink / raw)
To: Cyril Brulebois
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141029111224.GC29720-xazfMhTT2R0@public.gmane.org>
On Wed, Oct 29, 2014 at 12:12:24PM +0100, Cyril Brulebois wrote:
> Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (2014-10-29):
> > On Tue, Oct 28, 2014 at 04:42:41PM +0100, Cyril Brulebois wrote:
> > > 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
> > >
> > > References: https://bugs.debian.org/766802
> > > Reported-by: Martin Mokrejs <mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
> >
> > Was this patch tested by reporter? I would rather see Reported-and-tested-by tag :-)
>
> The reporter confirmed the following trick worked:
>
> # echo rt2800usb >> /etc/modules
> # echo 'install rt2800usb /sbin/modprobe --ignore-install rt2800usb $CMDLINE_OPTS && echo 1b75 a200 > /sys/bus/usb/drivers/rt2800usb/new_id' > /etc/modprobe.d/ralink.conf
> # modprobe -r rt2800usb ; modprobe rt2800usb
Ok, that's fine .
Acked-by: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ 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