* Re: [QA-TCP] How to send tcp small packages immediately?
From: Rick Jones @ 2014-10-24 15:19 UTC (permalink / raw)
To: Zhangjie (HZ), kvm, Jason Wang, Michael S. Tsirkin, linux-kernel,
netdev, liuyongan, qinchuanyu
In-Reply-To: <544A029D.3080508@huawei.com>
On 10/24/2014 12:41 AM, Zhangjie (HZ) wrote:
> Hi,
>
> I use netperf to test the performance of small tcp package, with TCP_NODELAY set :
>
> netperf -H 129.9.7.164 -l 100 -- -m 512 -D
>
> Among the packages I got by tcpdump, there is not only small packages, also lost of
> big ones (skb->len=65160).
>
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 65160
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 65160
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 80
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 512
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 512
>
> SO, how to test small tcp packages? Including TCP_NODELAY, What else should be set?
Well, I don't think there is anything else you can set. Even with
TCP_NODELAY set, segment size with TCP will still be controlled by
factors such as congestion window.
I am ass-u-me-ing your packet trace is at the sender. I suppose if your
sender were fast enough compared to the path that might combine with
congestion window to result in the very large segments.
Not to say there cannot be a bug somewhere with TSO overriding
TCP_NODELAY, but in broad terms, even TCP_NODELAY does not guarantee
small TCP segments. That has been something of a bane on my attempts to
use TCP for aggregate small-packet performance measurements via netperf
for quite some time.
And since you seem to have included a virtualization mailing list I
would also ass-u-me that virtualization is involved somehow. Knuth only
knows how that will affect the timing of events, which will be very much
involved in matters of congestion window and such. I suppose it is even
possible that if the packet trace is on a VM receiver that some delays
in getting the VM running could mean that GRO would end-up making large
segments being pushed up the stack.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 15:40 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024090857.GA4083@declera.com>
On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > >
> > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
[ . . . ]
> > > > > Indeed, c847f14217d5 it is.
> > > > >
> > > > > Much to my embarrasment I just noticed that in addition to the
> > > > > rcu merge, triggering the bug "requires" my specific Fedora
> > > > > rawhide network
> > > > > setup. Booting in single mode and modprobe ppp_generic is fine.
> > > > > The bug
> > > > > appears when starting with my regular fedora network setup, which
> > > > > in my case
> > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > I am attaching the config.
> > > >
> > > > It does help a lot, thank you!!!
> > > >
> > > > The following patch is a bit of a shot in the dark, and assumes that
> > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled
> > > > idle
> > > > code) introduced the problem. Does this patch fix things up?
> > >
> > > Unfortunately not, This is linus-tip + patch
> >
> > OK. Can't have everything, I guess.
> >
> > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds.
> > > Not tainted 3.18.0-rc1+ #4
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000
> > > Workqueue: netns cleanup_net
> > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00
> > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0
> > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650
> > > Call Trace:
> > > [<ffffffff8185b8e9>] schedule+0x29/0x70
> > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410
> > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0
> > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0
> > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50
> > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200
> > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150
> > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20
> > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200
> > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20
> > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310
> > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0
> > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10
> > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180
> > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0
> > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60
> > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0
> > > [<ffffffff810cca98>] process_one_work+0x218/0x850
> > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850
> > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0
> > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0
> > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850
> > > [<ffffffff810d348b>] kthread+0x10b/0x130
> > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10
> > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0
> > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > 4 locks held by kworker/u16:6/96:
> > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0
> > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200
> > > INFO: task modprobe:1045 blocked for more than 120 seconds.
> > > Not tainted 3.18.0-rc1+ #4
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > modprobe D ffff880218343480 12920 1045 1044 0x00000080
> > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00
> > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480
> > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480
> > > Call Trace:
> > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80
> > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440
> > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > [<ffffffffa0673000>] ? 0xffffffffa0673000
> > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge]
> > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> > > [<ffffffff81153052>] load_module+0x20c2/0x2870
> > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70
> > > [<ffffffff81278717>] ? kernel_read+0x57/0x90
> > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0
> > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17
> > > 1 lock held by modprobe/1045:
> > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> >
> > Presumably the kworker/u16:6 completed, then modprobe hung?
> >
> > If not, I have some very hard questions about why net_mutex can be
> > held by two tasks concurrently, given that it does not appear to be a
> > reader-writer lock...
> >
> > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> > NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> > If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> > Make nocb leader kthreads process pending callbacks after spawning)
> > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
>
> Ok, unless I've messsed up something major, bisecting points to:
>
> 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
>
> Makes any sense ?
Good question. ;-)
Are any of your online CPUs missing rcuo kthreads? There should be
kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> Another thing I noticed is that in failure mode the libvirtd bridge actually
> doesn't show up. So maybe ppp is just the first thing to try that bumps up
> into whatever libvirtd is failing to do to setup those.
>
> Truly hope this is not something with random timing dependency....
Me too. ;-)
Thanx, Paul
> --Yanko
> --
> 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: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck @ 2014-10-24 16:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20141023195526.GH25190@lunn.ch>
On Thu, Oct 23, 2014 at 09:55:26PM +0200, Andrew Lunn wrote:
> On Thu, Oct 23, 2014 at 11:43:22AM -0700, Guenter Roeck wrote:
> > On Thu, Oct 23, 2014 at 08:03:57PM +0200, Andrew Lunn wrote:
> > > > No, I am not saying that. The hwmon device's parent device will tell,
> > > > which is how it works for all other hwmon devices.
> > >
> > > O.K, so parent is important.
> > >
> > > > Not really. Again, the parent device provides that information. libsensors,
> > > > which is the preferred way of accessing sensors information from user space,
> > > > provides the parent device instance as part of the logical sensor device
> > > > name. In this case, the names will end up being dsa-isa-0000, dsa-isa-0001,
> > > > and so on. With your added tags it would be dsa.0.0-isa-0000, dsa.0.1-isa-0001,
> > > > and so on. I don't see how this would add any value.
> > >
> > > isa is the name of the ethernet device? Why is it not eth0? Most
> >
> > isa is just an internal name made up by libsensors, and pretty much just
> > indicates something like "neither i2c nor spi". It is mostly historic,
> > but nowadays almost part of the ABI. It is made up by user space,
> > based on the parent device type, not by the kernel.
>
> So for DSA, since it is not i2c or spi, the parent is actually
> irrelevant, because libsensor ignores it and says "IsSomethingAlien".
> So the name alone needs to identify it.
>
> > You have convinced me that 'dsa' as hwmon attribute name is insufficient,
> > so let's see what we have.
> >
> > - the parent network device in dst->master_netdev
> > - the dsa device in 'parent'
> > - the host device in host_dev
> > - the switch index in 'index'
> >
> > First question is what should be the parent device.
>
> Does it even matter, given the observation above? I would probably go
> for dsa, since as you said, the Ethernet device may have a temperature
> sensor of its own. DSA is a virtual device...
>
> > Second is what to choose for the hwmon device 'name' attribute.
> > 'dsa' is not sufficient, but what to choose instead ? dsa.X or dsa_X,
> > where X is the switch index ? At this point I am open to suggestions.
> > Note that we can not use the name returned from the switch probe
> > functions as it may contain spaces and other invalid characters.
> > Including the ethernet device name (eg as in eth0_dsa_0) may also be
> > problematic if it can contain '-', which is illegal for hwmon devices.
>
> Does hwmon offer a function to sanitise a string?
>
> The switch index definitely should be used and i would probably
> combine that with a sanitised version of the ethernet device name and
> "dsa".
>
Here is another naming option:
em1dsa0-virtual-0
Adapter: Virtual device
temp1: +52.0°C (high = +100.0°C)
I think I'll go with that one. I get it by not specifying
a parent device when registering with the hwmon subsystem.
It is kind of similar to the thermal sensor data reported
through acpi.
acpitz-virtual-0
Adapter: Virtual device
temp1: +52.0°C (crit = +111.0°C)
temp2: +52.0°C (crit = +111.0°C)
Guenter
^ permalink raw reply
* Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option
From: Hagen Paul Pfeifer @ 2014-10-24 16:26 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Kristian Evensen, David Miller, Network Development
In-Reply-To: <CAK6E8=fiHrgicTXy2hBGh0GUcZRWWxpYxw_bNVmRD+ueN9mUdw@mail.gmail.com>
On 24 October 2014 16:58, Yuchung Cheng <ycheng@google.com> wrote:
> Do packets actually get dropped during the handover period? if not
> then the sender can detect spurious RTOs and undo the cwnd reductions
> with timestamps or DSACKs (Eifel). Eifel did not exist when the
> freeze-TCP was published at 2000. Even if the connection does not
> support these options as major TCP stacks do, slow-start on a path
> with new BDP isn't that bad of an idea.
Yes, starting with fresh values for a new links is a good thing to do.
But what I think what Kristian want to address is to reduce larger
idle period due to backoff'ing timeouts followed by larger idle
periods? E.g. like a temporary cork for an exact period of time.
I thought that freeze-TCP was *also* designed to bridge a larger
disconnection? The downside with this approach (compared to SplitTCP)
is that you only send one instance into sleep. The other peer (sender)
may run into timeouts too.
Hagen
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Yanko Kaneti @ 2014-10-24 16:29 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024154006.GP4977@linux.vnet.ibm.com>
On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > >
> > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
>
> [ . . . ]
>
> > > > > > Indeed, c847f14217d5 it is.
> > > > > >
> > > > > > Much to my embarrasment I just noticed that in addition to the
> > > > > > rcu merge, triggering the bug "requires" my specific Fedora
> > > > > > rawhide network
> > > > > > setup. Booting in single mode and modprobe ppp_generic is fine.
> > > > > > The bug
> > > > > > appears when starting with my regular fedora network setup, which
> > > > > > in my case
> > > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup.
> > > > > >
> > > > > > Hope that helps.
> > > > > >
> > > > > > I am attaching the config.
> > > > >
> > > > > It does help a lot, thank you!!!
> > > > >
> > > > > The following patch is a bit of a shot in the dark, and assumes that
> > > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled
> > > > > idle
> > > > > code) introduced the problem. Does this patch fix things up?
> > > >
> > > > Unfortunately not, This is linus-tip + patch
> > >
> > > OK. Can't have everything, I guess.
> > >
> > > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds.
> > > > Not tainted 3.18.0-rc1+ #4
> > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000
> > > > Workqueue: netns cleanup_net
> > > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00
> > > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0
> > > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650
> > > > Call Trace:
> > > > [<ffffffff8185b8e9>] schedule+0x29/0x70
> > > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410
> > > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0
> > > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0
> > > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50
> > > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200
> > > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150
> > > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20
> > > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200
> > > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20
> > > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310
> > > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0
> > > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10
> > > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180
> > > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0
> > > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60
> > > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0
> > > > [<ffffffff810cca98>] process_one_work+0x218/0x850
> > > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850
> > > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0
> > > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0
> > > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850
> > > > [<ffffffff810d348b>] kthread+0x10b/0x130
> > > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10
> > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0
> > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > > 4 locks held by kworker/u16:6/96:
> > > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0
> > > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200
> > > > INFO: task modprobe:1045 blocked for more than 120 seconds.
> > > > Not tainted 3.18.0-rc1+ #4
> > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > > modprobe D ffff880218343480 12920 1045 1044 0x00000080
> > > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00
> > > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480
> > > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480
> > > > Call Trace:
> > > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80
> > > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440
> > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > > [<ffffffffa0673000>] ? 0xffffffffa0673000
> > > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge]
> > > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> > > > [<ffffffff81153052>] load_module+0x20c2/0x2870
> > > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70
> > > > [<ffffffff81278717>] ? kernel_read+0x57/0x90
> > > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0
> > > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17
> > > > 1 lock held by modprobe/1045:
> > > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > >
> > > Presumably the kworker/u16:6 completed, then modprobe hung?
> > >
> > > If not, I have some very hard questions about why net_mutex can be
> > > held by two tasks concurrently, given that it does not appear to be a
> > > reader-writer lock...
> > >
> > > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> > > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> > > NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> > > If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> > > Make nocb leader kthreads process pending callbacks after spawning)
> > > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
> >
> > Ok, unless I've messsed up something major, bisecting points to:
> >
> > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> >
> > Makes any sense ?
>
> Good question. ;-)
>
> Are any of your online CPUs missing rcuo kthreads? There should be
> kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
and the modprobe ppp_generic testcase reliably works, libvirt also manages
to setup its bridge.
Just with linux-tip , the rcuos are 6 but the failure is as reliable as
before.
Awating instructions: :)
^ permalink raw reply
* Re: [PATCH V3.18] rtlwifi: Add check for get_btc_status callback
From: Larry Finger @ 2014-10-24 16:39 UTC (permalink / raw)
To: Mike Galbraith
Cc: linville, linux-wireless, troy_tan, netdev,
Murilo Opsfelder Araujo, Thadeu Cascardo
In-Reply-To: <1414116580.23080.10.camel@marge.simpson.net>
[-- Attachment #1: Type: text/plain, Size: 16941 bytes --]
On 10/23/2014 09:09 PM, Mike Galbraith wrote:
> On Thu, 2014-10-23 at 13:23 -0500, Larry Finger wrote:
>
>> I know "rtl8192se:rtl92se_get_desc(): ERR rxdesc :4 not process" messages will
>> be fixed by the attached patch. Please send the logs after this is applied.
>
> Both applied.
>
> [ 17.717226] cfg80211: World regulatory domain updated:
> [ 17.719760] cfg80211: DFS Master region: unset
> [ 17.719801] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [ 17.724656] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.727087] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.729422] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.731592] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.733702] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.858132] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input13
> [ 17.861052] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14
> [ 17.863153] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
> [ 17.865356] input: HDA Intel HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
> [ 18.259078] toshiba_acpi: Unknown key 401
> [ 18.661507] Adding 2096476k swap on /dev/sda2. Priority:-1 extents:1 across:2096476k FS
> [ 18.984217] rtl8192se 0000:08:00.0: enabling device (0000 -> 0003)
> [ 19.025036] rtl8192se: FW Power Save off (module option)
> [ 19.027195] rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
> [ 19.027195] Loading firmware rtlwifi/rtl8192sefw.bin
> [ 19.095134] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [ 19.152305] ------------[ cut here ]------------
> [ 19.154367] WARNING: CPU: 0 PID: 59 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
> [ 19.156445] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1c.5/0000:08:00.0/ieee80211/phy0'
> [ 19.158562] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 19.170633] CPU: 0 PID: 59 Comm: kworker/0:3 Not tainted 3.18.0-master #52
> [ 19.173036] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 19.175634] Workqueue: events request_firmware_work_func
> [ 19.178247] 0000000000000009 ffff8800379d7a98 ffffffff815878e0 0000000000000001
> [ 19.180947] ffff8800379d7ae8 ffff8800379d7ad8 ffffffff8104c801 00000000000035e0
> [ 19.183573] ffff88003706e000 ffff8800aff86d80 ffff8800b0093d48 ffff88013b027098
> [ 19.186231] Call Trace:
> [ 19.188885] [<ffffffff815878e0>] dump_stack+0x46/0x58
> [ 19.191545] [<ffffffff8104c801>] warn_slowpath_common+0x81/0xa0
> [ 19.194173] [<ffffffff8104c866>] warn_slowpath_fmt+0x46/0x50
> [ 19.196707] [<ffffffff811d06c8>] ? kernfs_path+0x48/0x60
> [ 19.199138] [<ffffffff811d3b48>] sysfs_warn_dup+0x68/0x80
> [ 19.201587] [<ffffffff811d3bee>] sysfs_create_dir_ns+0x8e/0xa0
> [ 19.204057] [<ffffffff81286879>] kobject_add_internal+0xc9/0x400
> [ 19.206495] [<ffffffff81286fe0>] kobject_add+0x60/0xb0
> [ 19.208938] [<ffffffff8158c226>] ? mutex_lock+0x16/0x37
> [ 19.211321] [<ffffffff81380d54>] device_add+0x104/0x600
> [ 19.213692] [<ffffffff8114b98e>] ? lazy_max_pages+0x1e/0x30
> [ 19.216100] [<ffffffffa02e9d0d>] wiphy_register+0x3fd/0x710 [cfg80211]
> [ 19.218504] [<ffffffff8114d352>] ? __vunmap+0xc2/0x110
> [ 19.220957] [<ffffffffa0457cfc>] ? ieee80211_register_hw+0x1ec/0x9a0 [mac80211]
> [ 19.223447] [<ffffffffa0457e78>] ieee80211_register_hw+0x368/0x9a0 [mac80211]
> [ 19.225916] [<ffffffffa050a26b>] rtl92se_fw_cb+0xab/0x1d0 [rtl8192se]
> [ 19.228362] [<ffffffff81393d80>] request_firmware_work_func+0x30/0x60
> [ 19.230779] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 19.233167] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 19.235498] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 19.237861] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 19.240213] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.242534] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 19.244830] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.247125] ---[ end trace 0734244a9269eff8 ]---
> [ 19.249416] ------------[ cut here ]------------
> [ 19.251626] WARNING: CPU: 0 PID: 59 at lib/kobject.c:240 kobject_add_internal+0x294/0x400()
> [ 19.253876] kobject_add_internal failed for phy0 with -EEXIST, don't try to register things with the same name in the same directory.
> [ 19.256197] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 19.269327] CPU: 0 PID: 59 Comm: kworker/0:3 Tainted: G W 3.18.0-master #52
> [ 19.271976] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 19.274674] Workqueue: events request_firmware_work_func
> [ 19.277301] 0000000000000009 ffff8800379d7af8 ffffffff815878e0 0000000000000001
> [ 19.279875] ffff8800379d7b48 ffff8800379d7b38 ffffffff8104c801 ffff8800379d7b38
> [ 19.282376] ffff880137730350 00000000ffffffef ffff880036a9c940 ffff88013b027098
> [ 19.284844] Call Trace:
> [ 19.287151] [<ffffffff815878e0>] dump_stack+0x46/0x58
> [ 19.289474] [<ffffffff8104c801>] warn_slowpath_common+0x81/0xa0
> [ 19.291751] [<ffffffff8104c866>] warn_slowpath_fmt+0x46/0x50
> [ 19.293979] [<ffffffff81286a44>] kobject_add_internal+0x294/0x400
> [ 19.296192] [<ffffffff81286fe0>] kobject_add+0x60/0xb0
> [ 19.298381] [<ffffffff8158c226>] ? mutex_lock+0x16/0x37
> [ 19.300578] [<ffffffff81380d54>] device_add+0x104/0x600
> [ 19.302734] [<ffffffff8114b98e>] ? lazy_max_pages+0x1e/0x30
> [ 19.304909] [<ffffffffa02e9d0d>] wiphy_register+0x3fd/0x710 [cfg80211]
> [ 19.307110] [<ffffffff8114d352>] ? __vunmap+0xc2/0x110
> [ 19.309305] [<ffffffffa0457cfc>] ? ieee80211_register_hw+0x1ec/0x9a0 [mac80211]
> [ 19.311512] [<ffffffffa0457e78>] ieee80211_register_hw+0x368/0x9a0 [mac80211]
> [ 19.313767] [<ffffffffa050a26b>] rtl92se_fw_cb+0xab/0x1d0 [rtl8192se]
> [ 19.315998] [<ffffffff81393d80>] request_firmware_work_func+0x30/0x60
> [ 19.318260] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 19.320501] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 19.322732] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 19.324987] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 19.327246] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.329517] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 19.331757] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.334039] ---[ end trace 0734244a9269eff9 ]---
> [ 19.336275] rtl8192se:rtl92se_fw_cb():<0-0> Can't register mac80211 hw
> [ 20.108822] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: acl
> [ 24.761182] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 24.762764] IP: [< (null)>] (null)
> [ 24.764106] PGD 0
> [ 24.764106] Oops: 0010 [#1] SMP
> [ 24.764106] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 24.764106] CPU: 1 PID: 54 Comm: kworker/1:2 Tainted: G W 3.18.0-master #52
> [ 24.764106] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 24.764106] Workqueue: rtl92s_pci rtl_watchdog_wq_callback [rtlwifi]
> [ 24.764106] task: ffff88013614c350 ti: ffff880136150000 task.ti: ffff880136150000
> [ 24.764106] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> [ 24.764106] RSP: 0018:ffff880136153d80 EFLAGS: 00010293
> [ 24.764106] RAX: ffffffffa05103c0 RBX: ffff8801377319c0 RCX: 0000000000000000
> [ 24.764106] RDX: 0000000000000001 RSI: 000000000000005d RDI: ffff880137730620
> [ 24.764106] RBP: ffff880136153df8 R08: ffff88013fd12380 R09: 0000000000000001
> [ 24.764106] R10: 0000000000000002 R11: 0000000000000293 R12: ffff880137730620
> [ 24.764106] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [ 24.764106] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
> [ 24.764106] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 24.764106] CR2: 0000000000000000 CR3: 000000013b249000 CR4: 00000000000407e0
> [ 24.764106] Stack:
> [ 24.764106] ffffffffa051e51e ffff88013fd12b00 0000000000000000 ffff88013fd12b00
> [ 24.764106] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 24.764106] 0000000000000000 ffff880136153e38 ffff880137731be0 ffff880136126b80
> [ 24.764106] Call Trace:
> [ 24.764106] [<ffffffffa051e51e>] ? rtl_watchdog_wq_callback+0xfe/0x420 [rtlwifi]
> [ 24.764106] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 24.764106] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 24.764106] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 24.764106] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 24.764106] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.764106] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 24.764106] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.764106] Code: Bad RIP value.
> [ 24.764106] RIP [< (null)>] (null)
> [ 24.764106] RSP <ffff880136153d80>
> [ 24.764106] CR2: 0000000000000000
> [ 24.764106] ---[ end trace 0734244a9269effa ]---
> [ 24.855146] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 24.857620] BUG: unable to handle kernel paging request at ffffffffffffffd8
> [ 24.859873] IP: [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] PGD 1a16067 PUD 1a18067 PMD 0
> [ 24.861381] Oops: 0000 [#2] SMP
> [ 24.861381] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 24.861381] CPU: 1 PID: 54 Comm: kworker/1:2 Tainted: G D W 3.18.0-master #52
> [ 24.861381] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 24.861381] task: ffff88013614c350 ti: ffff880136150000 task.ti: ffff880136150000
> [ 24.861381] RIP: 0010:[<ffffffff810678f1>] [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] RSP: 0018:ffff880136153990 EFLAGS: 00010092
> [ 24.861381] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000171a414dc
> [ 24.861381] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88013614c350
> [ 24.861381] RBP: ffff8801361539a8 R08: ffff88013614fcd0 R09: 00000000000003d9
> [ 24.861381] R10: 000000000000bc00 R11: 0000000000008ddc R12: ffff88013fd12b00
> [ 24.861381] R13: 0000000000000001 R14: 0000000000000000 R15: ffff88013614c350
> [ 24.861381] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
> [ 24.861381] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 24.861381] CR2: 0000000000000028 CR3: 0000000035eba000 CR4: 00000000000407e0
> [ 24.861381] Stack:
> [ 24.861381] ffffffff81063145 ffff8801361539a8 ffff88013614c350 ffff880136153a18
> [ 24.861381] ffffffff8158a1ae ffff88013614c350 0000000000012b00 ffff880136153fd8
> [ 24.861381] 0000000000012b00 ffff880136153a08 ffff88013614c350 ffff88013614c350
> [ 24.861381] Call Trace:
> [ 24.861381] [<ffffffff81063145>] ? wq_worker_sleeping+0x15/0xa0
> [ 24.861381] [<ffffffff8158a1ae>] __schedule+0x53e/0x810
> [ 24.861381] [<ffffffff8158a4a9>] schedule+0x29/0x70
> [ 24.861381] [<ffffffff8104dfa2>] do_exit+0x6a2/0x9e0
> [ 24.861381] [<ffffffff8100645e>] oops_end+0x8e/0xd0
> [ 24.861381] [<ffffffff815829aa>] no_context+0x248/0x298
> [ 24.861381] [<ffffffff81582a67>] __bad_area_nosemaphore+0x6d/0x1c6
> [ 24.861381] [<ffffffff81582bd3>] bad_area_nosemaphore+0x13/0x15
> [ 24.861381] [<ffffffff8103d67c>] __do_page_fault+0x9c/0x530
> [ 24.861381] [<ffffffff812843c0>] ? cpumask_next_and+0x30/0x50
> [ 24.861381] [<ffffffff8107a24e>] ? load_balance+0x23e/0x830
> [ 24.861381] [<ffffffff8103db1c>] do_page_fault+0xc/0x10
> [ 24.861381] [<ffffffff8158fe22>] page_fault+0x22/0x30
> [ 24.861381] [<ffffffffa051e51e>] ? rtl_watchdog_wq_callback+0xfe/0x420 [rtlwifi]
> [ 24.861381] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 24.861381] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 24.861381] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 24.861381] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 24.861381] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.861381] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 24.861381] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.861381] Code: 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 87 60 04 00 00 55 48 89 e5 5d <48> 8b 40 d8 c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55
> [ 24.861381] RIP [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] RSP <ffff880136153990>
> [ 24.861381] CR2: ffffffffffffffd8
> [ 24.861381] ---[ end trace 0734244a9269effb ]---
> [ 24.861381] Fixing recursive fault but reboot is needed!
> [ 24.861381] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 1
> [ 24.861381] Shutting down cpus with NMI
> [ 24.861381] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> [ 24.861381] drm_kms_helper: panic occurred, switching back to text console
> [ 24.861381] Rebooting in 60 seconds..
Please try the attached patch. It replaces the second one I sent you. I will
probably redo it before submitting the final copy, but this should work.
Larry
[-- Attachment #2: fix_missing_desc --]
[-- Type: text/plain, Size: 6864 bytes --]
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 58ba718..a23ff78 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1234,7 +1234,8 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
{
rtlpriv->ra.is_special_data = true;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
rtlpriv, 1);
rtlpriv->enter_ps = false;
@@ -1629,7 +1630,8 @@ void rtl_watchdog_wq_callback(void *data)
}
}
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_periodical(rtlpriv);
rtlpriv->link_info.bcn_rx_inperiod = 0;
diff --git a/drivers/net/wireless/rtlwifi/core.c b/drivers/net/wireless/rtlwifi/core.c
index f6179bc..686d256 100644
--- a/drivers/net/wireless/rtlwifi/core.c
+++ b/drivers/net/wireless/rtlwifi/core.c
@@ -1133,7 +1133,8 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
ppsc->report_linked = (mstatus == RT_MEDIA_CONNECT) ?
true : false;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_mediastatus_notify(
rtlpriv, mstatus);
}
@@ -1373,7 +1374,8 @@ static void rtl_op_sw_scan_start(struct ieee80211_hw *hw)
return;
}
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_scan_notify(rtlpriv, 1);
if (rtlpriv->dm.supp_phymode_switch) {
@@ -1425,7 +1427,8 @@ static void rtl_op_sw_scan_complete(struct ieee80211_hw *hw)
}
rtlpriv->cfg->ops->scan_operation_backup(hw, SCAN_OPT_RESTORE);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_scan_notify(rtlpriv, 0);
}
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 25daa87..ed3364d 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -1833,7 +1833,8 @@ static void rtl_pci_stop(struct ieee80211_hw *hw)
unsigned long flags;
u8 RFInProgressTimeOut = 0;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_halt_notify();
/*
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index b69321d..2278af9 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -261,7 +261,8 @@ void rtl_ips_nic_off_wq_callback(void *data)
ppsc->in_powersavemode = true;
/* call before RF off */
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_ips_notify(rtlpriv,
ppsc->inactive_pwrstate);
@@ -306,7 +307,8 @@ void rtl_ips_nic_on(struct ieee80211_hw *hw)
ppsc->in_powersavemode = false;
_rtl_ps_inactive_ps(hw);
/* call after RF on */
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_ips_notify(rtlpriv,
ppsc->inactive_pwrstate);
}
@@ -390,14 +392,16 @@ void rtl_lps_set_psmode(struct ieee80211_hw *hw, u8 rt_psmode)
if (ppsc->p2p_ps_info.opp_ps)
rtl_p2p_ps_cmd(hw , P2P_PS_ENABLE);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_lps_notify(rtlpriv, rt_psmode);
} else {
if (rtl_get_fwlps_doze(hw)) {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
"FW LPS enter ps_mode:%x\n",
ppsc->fwctrl_psmode);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_lps_notify(rtlpriv, rt_psmode);
enter_fwlps = true;
ppsc->pwr_mode = ppsc->fwctrl_psmode;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/def.h b/drivers/net/wireless/rtlwifi/rtl8192se/def.h
index 83c9867..593646e 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/def.h
@@ -453,6 +453,9 @@
GET_RX_STATUS_DESC_RX_MCS(_pdesc) == DESC92_RATE5_5M ||\
GET_RX_STATUS_DESC_RX_MCS(_pdesc) == DESC92_RATE11M)
+#define GET_RX_STATUS_DESC_BUFF_ADDR(__pdesc) \
+ SHIFT_AND_MASK_LE(__pdesc + 24, 0, 32)
+
enum rf_optype {
RF_OP_BY_SW_3WIRE = 0,
RF_OP_BY_FW,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index 1bff2a0..aa99d97 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -87,11 +87,8 @@ static void rtl92s_init_aspm_vars(struct ieee80211_hw *hw)
static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
{
struct ieee80211_hw *hw = context;
- struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_pci *rtlpci = rtl_pcidev(pcipriv);
struct rt_firmware *pfirmware = NULL;
- int err;
RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
"Firmware callback routine entered!\n");
@@ -112,20 +109,6 @@ static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
memcpy(pfirmware->sz_fw_tmpbuffer, firmware->data, firmware->size);
pfirmware->sz_fw_tmpbufferlen = firmware->size;
release_firmware(firmware);
-
- err = ieee80211_register_hw(hw);
- if (err) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Can't register mac80211 hw\n");
- return;
- } else {
- rtlpriv->mac80211.mac80211_registered = 1;
- }
- rtlpci->irq_alloc = 1;
- set_bit(RTL_STATUS_INTERFACE_START, &rtlpriv->status);
-
- /*init rfkill */
- rtl_init_rfkill(hw);
}
static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index b358ebc..672fd3b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -640,6 +640,9 @@ u32 rtl92se_get_desc(u8 *desc, bool istx, u8 desc_name)
case HW_DESC_RXPKT_LEN:
ret = GET_RX_STATUS_DESC_PKT_LEN(desc);
break;
+ case HW_DESC_RXBUFF_ADDR:
+ ret = GET_RX_STATUS_DESC_BUFF_ADDR(desc);
+ break;
default:
RT_ASSERT(false, "ERR rxdesc :%d not process\n",
desc_name);
^ permalink raw reply related
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 16:54 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024162943.GA16621@declera.com>
On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > >
> > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
[ . . . ]
> > > Ok, unless I've messsed up something major, bisecting points to:
> > >
> > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > >
> > > Makes any sense ?
> >
> > Good question. ;-)
> >
> > Are any of your online CPUs missing rcuo kthreads? There should be
> > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
>
> Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> and the modprobe ppp_generic testcase reliably works, libvirt also manages
> to setup its bridge.
>
> Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> before.
Thank you, very interesting. Which 6 of the rcuos are present?
> Awating instructions: :)
Well, I thought I understood the problem until you found that only 6 of
the expected 8 rcuos are present with linux-tip without the revert. ;-)
I am putting together a patch for the part of the problem that I think
I understand, of course, but it would help a lot to know which two of
the rcuos are missing. ;-)
Thanx, Paul
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Yanko Kaneti @ 2014-10-24 17:09 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024165454.GS4977@linux.vnet.ibm.com>
On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > >
> > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
>
> [ . . . ]
>
> > > > Ok, unless I've messsed up something major, bisecting points to:
> > > >
> > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > >
> > > > Makes any sense ?
> > >
> > > Good question. ;-)
> > >
> > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> >
> > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > to setup its bridge.
> >
> > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > before.
> Thank you, very interesting. Which 6 of the rcuos are present?
Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
Phenom II.
> > Awating instructions: :)
>
> Well, I thought I understood the problem until you found that only 6 of
> the expected 8 rcuos are present with linux-tip without the revert. ;-)
>
> I am putting together a patch for the part of the problem that I think
> I understand, of course, but it would help a lot to know which two of
> the rcuos are missing. ;-)
>
Ready to test
--Yanko
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 17:20 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024170931.GA21849@declera.com>
On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote:
> On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > > >
> > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> >
> > [ . . . ]
> >
> > > > > Ok, unless I've messsed up something major, bisecting points to:
> > > > >
> > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > > >
> > > > > Makes any sense ?
> > > >
> > > > Good question. ;-)
> > > >
> > > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> > >
> > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > > to setup its bridge.
> > >
> > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > > before.
>
> > Thank you, very interesting. Which 6 of the rcuos are present?
>
> Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
> Phenom II.
Ah, you get 8 without the patch because it creates them for potential
CPUs as well as real ones. OK, got it.
> > > Awating instructions: :)
> >
> > Well, I thought I understood the problem until you found that only 6 of
> > the expected 8 rcuos are present with linux-tip without the revert. ;-)
> >
> > I am putting together a patch for the part of the problem that I think
> > I understand, of course, but it would help a lot to know which two of
> > the rcuos are missing. ;-)
>
> Ready to test
Well, if you are feeling aggressive, give the following patch a spin.
I am doing sanity tests on it in the meantime.
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 29fb23f33c18..927c17b081c7 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu)
rdp->nocb_leader = rdp_spawn;
if (rdp_last && rdp != rdp_spawn)
rdp_last->nocb_next_follower = rdp;
- rdp_last = rdp;
- rdp = rdp->nocb_next_follower;
- rdp_last->nocb_next_follower = NULL;
+ if (rdp == rdp_spawn) {
+ rdp = rdp->nocb_next_follower;
+ } else {
+ rdp_last = rdp;
+ rdp = rdp->nocb_next_follower;
+ rdp_last->nocb_next_follower = NULL;
+ }
} while (rdp);
rdp_spawn->nocb_next_follower = rdp_old_leader;
}
^ permalink raw reply related
* Re: [PATCH RFC v5 net 0/3] ipv6: Reduce the number of fib6_lookup() calls from ip6_pol_route()
From: Martin Lau @ 2014-10-24 17:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141024.001550.1808591527768047773.davem@davemloft.net>
Hi,
> Can you cook up some clean patches against the net_test_tools repo so
> that people can use it for both ipv4 and ipv6 route lookup measurements?
Yes, will do.
Thanks,
--Martin
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Yanko Kaneti @ 2014-10-24 17:35 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024172009.GV4977@linux.vnet.ibm.com>
On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote:
> On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote:
> > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > > > >
> > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> > >
> > > [ . . . ]
> > >
> > > > > > Ok, unless I've messsed up something major, bisecting points to:
> > > > > >
> > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > > > >
> > > > > > Makes any sense ?
> > > > >
> > > > > Good question. ;-)
> > > > >
> > > > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> > > >
> > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > > > to setup its bridge.
> > > >
> > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > > > before.
> >
> > > Thank you, very interesting. Which 6 of the rcuos are present?
> >
> > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
> > Phenom II.
>
> Ah, you get 8 without the patch because it creates them for potential
> CPUs as well as real ones. OK, got it.
>
> > > > Awating instructions: :)
> > >
> > > Well, I thought I understood the problem until you found that only 6 of
> > > the expected 8 rcuos are present with linux-tip without the revert. ;-)
> > >
> > > I am putting together a patch for the part of the problem that I think
> > > I understand, of course, but it would help a lot to know which two of
> > > the rcuos are missing. ;-)
> >
> > Ready to test
>
> Well, if you are feeling aggressive, give the following patch a spin.
> I am doing sanity tests on it in the meantime.
Doesn't seem to make a difference here
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 29fb23f33c18..927c17b081c7 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu)
> rdp->nocb_leader = rdp_spawn;
> if (rdp_last && rdp != rdp_spawn)
> rdp_last->nocb_next_follower = rdp;
> - rdp_last = rdp;
> - rdp = rdp->nocb_next_follower;
> - rdp_last->nocb_next_follower = NULL;
> + if (rdp == rdp_spawn) {
> + rdp = rdp->nocb_next_follower;
> + } else {
> + rdp_last = rdp;
> + rdp = rdp->nocb_next_follower;
> + rdp_last->nocb_next_follower = NULL;
> + }
> } while (rdp);
> rdp_spawn->nocb_next_follower = rdp_old_leader;
> }
>
^ permalink raw reply
* Re: [PATCH] ovs: Turn vports with dependencies into separate modules
From: Pravin Shelar @ 2014-10-24 17:47 UTC (permalink / raw)
To: Thomas Graf; +Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev
In-Reply-To: <ab9438abe3e23289db6f850eea9626fe8bd0a969.1413991519.git.tgraf-G/eBtMaohhA@public.gmane.org>
On Wed, Oct 22, 2014 at 8:29 AM, Thomas Graf <tgraf@suug.ch> wrote:
> The internal and netdev vport remain part of openvswitch.ko. Encap
> vports including vxlan, gre, and geneve can be built as separate
> modules and are loaded on demand. Modules can be unloaded after use.
> Datapath ports keep a reference to the vport module during their
> lifetime.
>
> Allows to remove the error prone maintenance of the global list
> vport_ops_list.
>
How error prone is this interface, can you give example? Set of ovs
vport type is been pretty stable, so am not sure if we need loadable
module support for vports implementations.
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> net/openvswitch/Kconfig | 18 +++----
> net/openvswitch/Makefile | 14 ++---
> net/openvswitch/datapath.c | 16 +++++-
> net/openvswitch/vport-geneve.c | 23 +++++++-
> net/openvswitch/vport-gre.c | 23 +++++++-
> net/openvswitch/vport-internal_dev.c | 17 +++++-
> net/openvswitch/vport-netdev.c | 14 ++++-
> net/openvswitch/vport-netdev.h | 3 ++
> net/openvswitch/vport-vxlan.c | 23 +++++++-
> net/openvswitch/vport.c | 102 ++++++++++++++++++++++++-----------
> net/openvswitch/vport.h | 14 +++--
> 11 files changed, 199 insertions(+), 68 deletions(-)
>
> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> index ba3bb82..2a9673e 100644
> --- a/net/openvswitch/Kconfig
> +++ b/net/openvswitch/Kconfig
> @@ -29,11 +29,11 @@ config OPENVSWITCH
> If unsure, say N.
>
> config OPENVSWITCH_GRE
> - bool "Open vSwitch GRE tunneling support"
> + tristate "Open vSwitch GRE tunneling support"
> depends on INET
> depends on OPENVSWITCH
> - depends on NET_IPGRE_DEMUX && !(OPENVSWITCH=y && NET_IPGRE_DEMUX=m)
> - default y
> + depends on NET_IPGRE_DEMUX
> + default OPENVSWITCH
> ---help---
> If you say Y here, then the Open vSwitch will be able create GRE
> vport.
> @@ -43,11 +43,11 @@ config OPENVSWITCH_GRE
> If unsure, say Y.
>
> config OPENVSWITCH_VXLAN
> - bool "Open vSwitch VXLAN tunneling support"
> + tristate "Open vSwitch VXLAN tunneling support"
> depends on INET
> depends on OPENVSWITCH
> - depends on VXLAN && !(OPENVSWITCH=y && VXLAN=m)
> - default y
> + depends on VXLAN
> + default OPENVSWITCH
> ---help---
> If you say Y here, then the Open vSwitch will be able create vxlan vport.
>
> @@ -56,11 +56,11 @@ config OPENVSWITCH_VXLAN
> If unsure, say Y.
>
> config OPENVSWITCH_GENEVE
> - bool "Open vSwitch Geneve tunneling support"
> + tristate "Open vSwitch Geneve tunneling support"
> depends on INET
> depends on OPENVSWITCH
> - depends on GENEVE && !(OPENVSWITCH=y && GENEVE=m)
> - default y
> + depends on GENEVE
> + default OPENVSWITCH
> ---help---
> If you say Y here, then the Open vSwitch will be able create geneve vport.
>
> diff --git a/net/openvswitch/Makefile b/net/openvswitch/Makefile
> index 9a33a27..91b9478 100644
> --- a/net/openvswitch/Makefile
> +++ b/net/openvswitch/Makefile
> @@ -15,14 +15,6 @@ openvswitch-y := \
> vport-internal_dev.o \
> vport-netdev.o
>
> -ifneq ($(CONFIG_OPENVSWITCH_GENEVE),)
> -openvswitch-y += vport-geneve.o
> -endif
> -
> -ifneq ($(CONFIG_OPENVSWITCH_VXLAN),)
> -openvswitch-y += vport-vxlan.o
> -endif
> -
> -ifneq ($(CONFIG_OPENVSWITCH_GRE),)
> -openvswitch-y += vport-gre.o
> -endif
> +obj-$(CONFIG_OPENVSWITCH_GENEVE)+= vport-geneve.o
> +obj-$(CONFIG_OPENVSWITCH_VXLAN) += vport-vxlan.o
> +obj-$(CONFIG_OPENVSWITCH_GRE) += vport-gre.o
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index e6d7255..aecddb9 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -59,6 +59,7 @@
> #include "vport-netdev.h"
>
> int ovs_net_id __read_mostly;
> +EXPORT_SYMBOL(ovs_net_id);
>
> static struct genl_family dp_packet_genl_family;
> static struct genl_family dp_flow_genl_family;
> @@ -1764,6 +1765,7 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
> return -ENOMEM;
>
> ovs_lock();
> +restart:
> dp = get_dp(sock_net(skb->sk), ovs_header->dp_ifindex);
> err = -ENODEV;
> if (!dp)
> @@ -1795,8 +1797,11 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
>
> vport = new_vport(&parms);
> err = PTR_ERR(vport);
> - if (IS_ERR(vport))
> + if (IS_ERR(vport)) {
> + if (err == -EAGAIN)
> + goto restart;
> goto exit_unlock_free;
> + }
>
> err = ovs_vport_cmd_fill_info(vport, reply, info->snd_portid,
> info->snd_seq, 0, OVS_VPORT_CMD_NEW);
> @@ -2112,12 +2117,18 @@ static int __init dp_init(void)
> if (err)
> goto error_netns_exit;
>
> + err = ovs_netdev_init();
> + if (err)
> + goto error_unreg_notifier;
> +
> err = dp_register_genl();
> if (err < 0)
> - goto error_unreg_notifier;
> + goto error_unreg_netdev;
>
> return 0;
>
> +error_unreg_netdev:
> + ovs_netdev_exit();
> error_unreg_notifier:
> unregister_netdevice_notifier(&ovs_dp_device_notifier);
> error_netns_exit:
> @@ -2137,6 +2148,7 @@ error:
> static void dp_cleanup(void)
> {
> dp_unregister_genl(ARRAY_SIZE(dp_genl_families));
> + ovs_netdev_exit();
> unregister_netdevice_notifier(&ovs_dp_device_notifier);
> unregister_pernet_device(&ovs_net_ops);
> rcu_barrier();
> diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
> index 106a9d8..70c9765 100644
> --- a/net/openvswitch/vport-geneve.c
> +++ b/net/openvswitch/vport-geneve.c
> @@ -17,6 +17,7 @@
> #include <linux/rculist.h>
> #include <linux/udp.h>
> #include <linux/if_vlan.h>
> +#include <linux/module.h>
>
> #include <net/geneve.h>
> #include <net/icmp.h>
> @@ -28,6 +29,8 @@
> #include "datapath.h"
> #include "vport.h"
>
> +static struct vport_ops ovs_geneve_vport_ops;
> +
> /**
> * struct geneve_port - Keeps track of open UDP ports
> * @gs: The socket created for this port number.
> @@ -225,11 +228,29 @@ static const char *geneve_get_name(const struct vport *vport)
> return geneve_port->name;
> }
>
> -const struct vport_ops ovs_geneve_vport_ops = {
> +static struct vport_ops ovs_geneve_vport_ops = {
> .type = OVS_VPORT_TYPE_GENEVE,
> .create = geneve_tnl_create,
> .destroy = geneve_tnl_destroy,
> .get_name = geneve_get_name,
> .get_options = geneve_get_options,
> .send = geneve_tnl_send,
> + .owner = THIS_MODULE,
> };
> +
> +static int __init ovs_geneve_tnl_init(void)
> +{
> + return ovs_vport_ops_register(&ovs_geneve_vport_ops);
> +}
> +
> +static void __exit ovs_geneve_tnl_exit(void)
> +{
> + ovs_vport_ops_unregister(&ovs_geneve_vport_ops);
> +}
> +
> +module_init(ovs_geneve_tnl_init);
> +module_exit(ovs_geneve_tnl_exit);
> +
> +MODULE_DESCRIPTION("OVS: Geneve swiching port");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("vport-type-5");
> diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
> index 108b82d..00270b6 100644
> --- a/net/openvswitch/vport-gre.c
> +++ b/net/openvswitch/vport-gre.c
> @@ -29,6 +29,7 @@
> #include <linux/jhash.h>
> #include <linux/list.h>
> #include <linux/kernel.h>
> +#include <linux/module.h>
> #include <linux/workqueue.h>
> #include <linux/rculist.h>
> #include <net/route.h>
> @@ -45,6 +46,8 @@
> #include "datapath.h"
> #include "vport.h"
>
> +static struct vport_ops ovs_gre_vport_ops;
> +
> /* Returns the least-significant 32 bits of a __be64. */
> static __be32 be64_get_low32(__be64 x)
> {
> @@ -281,10 +284,28 @@ static void gre_tnl_destroy(struct vport *vport)
> gre_exit();
> }
>
> -const struct vport_ops ovs_gre_vport_ops = {
> +static struct vport_ops ovs_gre_vport_ops = {
> .type = OVS_VPORT_TYPE_GRE,
> .create = gre_create,
> .destroy = gre_tnl_destroy,
> .get_name = gre_get_name,
> .send = gre_tnl_send,
> + .owner = THIS_MODULE,
> };
> +
> +static int __init ovs_gre_tnl_init(void)
> +{
> + return ovs_vport_ops_register(&ovs_gre_vport_ops);
> +}
> +
> +static void __exit ovs_gre_tnl_exit(void)
> +{
> + ovs_vport_ops_unregister(&ovs_gre_vport_ops);
> +}
> +
> +module_init(ovs_gre_tnl_init);
> +module_exit(ovs_gre_tnl_exit);
> +
> +MODULE_DESCRIPTION("OVS: GRE switching port");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("vport-type-3");
> diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
> index 8451612..10dc07e 100644
> --- a/net/openvswitch/vport-internal_dev.c
> +++ b/net/openvswitch/vport-internal_dev.c
> @@ -36,6 +36,8 @@ struct internal_dev {
> struct vport *vport;
> };
>
> +static struct vport_ops ovs_internal_vport_ops;
> +
> static struct internal_dev *internal_dev_priv(struct net_device *netdev)
> {
> return netdev_priv(netdev);
> @@ -238,7 +240,7 @@ static int internal_dev_recv(struct vport *vport, struct sk_buff *skb)
> return len;
> }
>
> -const struct vport_ops ovs_internal_vport_ops = {
> +static struct vport_ops ovs_internal_vport_ops = {
> .type = OVS_VPORT_TYPE_INTERNAL,
> .create = internal_dev_create,
> .destroy = internal_dev_destroy,
> @@ -261,10 +263,21 @@ struct vport *ovs_internal_dev_get_vport(struct net_device *netdev)
>
> int ovs_internal_dev_rtnl_link_register(void)
> {
> - return rtnl_link_register(&internal_dev_link_ops);
> + int err;
> +
> + err = rtnl_link_register(&internal_dev_link_ops);
> + if (err < 0)
> + return err;
> +
> + err = ovs_vport_ops_register(&ovs_internal_vport_ops);
> + if (err < 0)
> + rtnl_link_unregister(&internal_dev_link_ops);
> +
> + return err;
> }
>
> void ovs_internal_dev_rtnl_link_unregister(void)
> {
> + ovs_vport_ops_unregister(&ovs_internal_vport_ops);
> rtnl_link_unregister(&internal_dev_link_ops);
> }
> diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
> index d21f77d..877ee74 100644
> --- a/net/openvswitch/vport-netdev.c
> +++ b/net/openvswitch/vport-netdev.c
> @@ -33,6 +33,8 @@
> #include "vport-internal_dev.h"
> #include "vport-netdev.h"
>
> +static struct vport_ops ovs_netdev_vport_ops;
> +
> /* Must be called with rcu_read_lock. */
> static void netdev_port_receive(struct vport *vport, struct sk_buff *skb)
> {
> @@ -224,10 +226,20 @@ struct vport *ovs_netdev_get_vport(struct net_device *dev)
> return NULL;
> }
>
> -const struct vport_ops ovs_netdev_vport_ops = {
> +static struct vport_ops ovs_netdev_vport_ops = {
> .type = OVS_VPORT_TYPE_NETDEV,
> .create = netdev_create,
> .destroy = netdev_destroy,
> .get_name = ovs_netdev_get_name,
> .send = netdev_send,
> };
> +
> +int __init ovs_netdev_init(void)
> +{
> + return ovs_vport_ops_register(&ovs_netdev_vport_ops);
> +}
> +
> +void ovs_netdev_exit(void)
> +{
> + ovs_vport_ops_unregister(&ovs_netdev_vport_ops);
> +}
> diff --git a/net/openvswitch/vport-netdev.h b/net/openvswitch/vport-netdev.h
> index 8df01c11..6f7038e 100644
> --- a/net/openvswitch/vport-netdev.h
> +++ b/net/openvswitch/vport-netdev.h
> @@ -41,4 +41,7 @@ netdev_vport_priv(const struct vport *vport)
> const char *ovs_netdev_get_name(const struct vport *);
> void ovs_netdev_detach_dev(struct vport *);
>
> +int __init ovs_netdev_init(void);
> +void ovs_netdev_exit(void);
> +
> #endif /* vport_netdev.h */
> diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
> index 2735e01..965e750 100644
> --- a/net/openvswitch/vport-vxlan.c
> +++ b/net/openvswitch/vport-vxlan.c
> @@ -24,6 +24,7 @@
> #include <linux/net.h>
> #include <linux/rculist.h>
> #include <linux/udp.h>
> +#include <linux/module.h>
>
> #include <net/icmp.h>
> #include <net/ip.h>
> @@ -50,6 +51,8 @@ struct vxlan_port {
> char name[IFNAMSIZ];
> };
>
> +static struct vport_ops ovs_vxlan_vport_ops;
> +
> static inline struct vxlan_port *vxlan_vport(const struct vport *vport)
> {
> return vport_priv(vport);
> @@ -192,11 +195,29 @@ static const char *vxlan_get_name(const struct vport *vport)
> return vxlan_port->name;
> }
>
> -const struct vport_ops ovs_vxlan_vport_ops = {
> +static struct vport_ops ovs_vxlan_vport_ops = {
> .type = OVS_VPORT_TYPE_VXLAN,
> .create = vxlan_tnl_create,
> .destroy = vxlan_tnl_destroy,
> .get_name = vxlan_get_name,
> .get_options = vxlan_get_options,
> .send = vxlan_tnl_send,
> + .owner = THIS_MODULE,
> };
> +
> +static int __init ovs_vxlan_tnl_init(void)
> +{
> + return ovs_vport_ops_register(&ovs_vxlan_vport_ops);
> +}
> +
> +static void __exit ovs_vxlan_tnl_exit(void)
> +{
> + ovs_vport_ops_unregister(&ovs_vxlan_vport_ops);
> +}
> +
> +module_init(ovs_vxlan_tnl_init);
> +module_exit(ovs_vxlan_tnl_exit);
> +
> +MODULE_DESCRIPTION("OVS: VXLAN switching port");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("vport-type-4");
> diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
> index 6015802..8168ef0 100644
> --- a/net/openvswitch/vport.c
> +++ b/net/openvswitch/vport.c
> @@ -28,6 +28,7 @@
> #include <linux/rtnetlink.h>
> #include <linux/compat.h>
> #include <net/net_namespace.h>
> +#include <linux/module.h>
>
> #include "datapath.h"
> #include "vport.h"
> @@ -36,22 +37,7 @@
> static void ovs_vport_record_error(struct vport *,
> enum vport_err_type err_type);
>
> -/* List of statically compiled vport implementations. Don't forget to also
> - * add yours to the list at the bottom of vport.h. */
> -static const struct vport_ops *vport_ops_list[] = {
> - &ovs_netdev_vport_ops,
> - &ovs_internal_vport_ops,
> -
> -#ifdef CONFIG_OPENVSWITCH_GRE
> - &ovs_gre_vport_ops,
> -#endif
> -#ifdef CONFIG_OPENVSWITCH_VXLAN
> - &ovs_vxlan_vport_ops,
> -#endif
> -#ifdef CONFIG_OPENVSWITCH_GENEVE
> - &ovs_geneve_vport_ops,
> -#endif
> -};
> +static LIST_HEAD(vport_ops_list);
>
> /* Protected by RCU read lock for reading, ovs_mutex for writing. */
> static struct hlist_head *dev_table;
> @@ -88,6 +74,32 @@ static struct hlist_head *hash_bucket(struct net *net, const char *name)
> return &dev_table[hash & (VPORT_HASH_BUCKETS - 1)];
> }
>
> +int ovs_vport_ops_register(struct vport_ops *ops)
> +{
> + int err = -EEXIST;
> + struct vport_ops *o;
> +
> + ovs_lock();
> + list_for_each_entry(o, &vport_ops_list, list)
> + if (ops->type == o->type)
> + goto errout;
> +
> + list_add_tail(&ops->list, &vport_ops_list);
> + err = 0;
> +errout:
> + ovs_unlock();
> + return err;
> +}
> +EXPORT_SYMBOL(ovs_vport_ops_register);
> +
> +void ovs_vport_ops_unregister(struct vport_ops *ops)
> +{
> + ovs_lock();
> + list_del(&ops->list);
> + ovs_unlock();
> +}
> +EXPORT_SYMBOL(ovs_vport_ops_unregister);
> +
> /**
> * ovs_vport_locate - find a port that has already been created
> *
> @@ -153,6 +165,7 @@ struct vport *ovs_vport_alloc(int priv_size, const struct vport_ops *ops,
>
> return vport;
> }
> +EXPORT_SYMBOL(ovs_vport_alloc);
>
> /**
> * ovs_vport_free - uninitialize and free vport
> @@ -173,6 +186,18 @@ void ovs_vport_free(struct vport *vport)
> free_percpu(vport->percpu_stats);
> kfree(vport);
> }
> +EXPORT_SYMBOL(ovs_vport_free);
> +
> +static struct vport_ops *ovs_vport_lookup(const struct vport_parms *parms)
> +{
> + struct vport_ops *ops;
> +
> + list_for_each_entry(ops, &vport_ops_list, list)
> + if (ops->type == parms->type)
> + return ops;
> +
> + return NULL;
> +}
>
> /**
> * ovs_vport_add - add vport device (for kernel callers)
> @@ -184,31 +209,40 @@ void ovs_vport_free(struct vport *vport)
> */
> struct vport *ovs_vport_add(const struct vport_parms *parms)
> {
> + struct vport_ops *ops;
> struct vport *vport;
> - int err = 0;
> - int i;
>
> - for (i = 0; i < ARRAY_SIZE(vport_ops_list); i++) {
> - if (vport_ops_list[i]->type == parms->type) {
> - struct hlist_head *bucket;
> + ops = ovs_vport_lookup(parms);
> + if (ops) {
> + struct hlist_head *bucket;
>
> - vport = vport_ops_list[i]->create(parms);
> - if (IS_ERR(vport)) {
> - err = PTR_ERR(vport);
> - goto out;
> - }
> + if (!try_module_get(ops->owner))
> + return ERR_PTR(-EAFNOSUPPORT);
>
> - bucket = hash_bucket(ovs_dp_get_net(vport->dp),
> - vport->ops->get_name(vport));
> - hlist_add_head_rcu(&vport->hash_node, bucket);
> + vport = ops->create(parms);
> + if (IS_ERR(vport)) {
> + module_put(ops->owner);
> return vport;
> }
> +
> + bucket = hash_bucket(ovs_dp_get_net(vport->dp),
> + vport->ops->get_name(vport));
> + hlist_add_head_rcu(&vport->hash_node, bucket);
> + return vport;
> }
>
> - err = -EAFNOSUPPORT;
> + /* Unlock to attempt module load and return -EAGAIN if load
> + * was successful as we need to restart the port addition
> + * workflow.
> + */
> + ovs_unlock();
> + request_module("vport-type-%d", parms->type);
> + ovs_lock();
>
> -out:
> - return ERR_PTR(err);
> + if (!ovs_vport_lookup(parms))
> + return ERR_PTR(-EAFNOSUPPORT);
> + else
> + return ERR_PTR(-EAGAIN);
> }
>
> /**
> @@ -242,6 +276,8 @@ void ovs_vport_del(struct vport *vport)
> hlist_del_rcu(&vport->hash_node);
>
> vport->ops->destroy(vport);
> +
> + module_put(vport->ops->owner);
> }
>
> /**
> @@ -457,6 +493,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb,
> }
> ovs_dp_process_packet(skb, &key);
> }
> +EXPORT_SYMBOL(ovs_vport_receive);
>
> /**
> * ovs_vport_send - send a packet on a device
> @@ -535,3 +572,4 @@ void ovs_vport_deferred_free(struct vport *vport)
>
> call_rcu(&vport->rcu, free_vport_rcu);
> }
> +EXPORT_SYMBOL(ovs_vport_deferred_free);
> diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
> index 8942125..e41c3fa 100644
> --- a/net/openvswitch/vport.h
> +++ b/net/openvswitch/vport.h
> @@ -161,6 +161,9 @@ struct vport_ops {
> const char *(*get_name)(const struct vport *);
>
> int (*send)(struct vport *, struct sk_buff *);
> +
> + struct module *owner;
> + struct list_head list;
> };
>
> enum vport_err_type {
> @@ -209,14 +212,6 @@ static inline struct vport *vport_from_priv(void *priv)
> void ovs_vport_receive(struct vport *, struct sk_buff *,
> struct ovs_tunnel_info *);
>
> -/* List of statically compiled vport implementations. Don't forget to also
> - * add yours to the list at the top of vport.c. */
> -extern const struct vport_ops ovs_netdev_vport_ops;
> -extern const struct vport_ops ovs_internal_vport_ops;
> -extern const struct vport_ops ovs_gre_vport_ops;
> -extern const struct vport_ops ovs_vxlan_vport_ops;
> -extern const struct vport_ops ovs_geneve_vport_ops;
> -
> static inline void ovs_skb_postpush_rcsum(struct sk_buff *skb,
> const void *start, unsigned int len)
> {
> @@ -224,4 +219,7 @@ static inline void ovs_skb_postpush_rcsum(struct sk_buff *skb,
> skb->csum = csum_add(skb->csum, csum_partial(start, len, 0));
> }
>
> +int ovs_vport_ops_register(struct vport_ops *ops);
> +void ovs_vport_ops_unregister(struct vport_ops *ops);
> +
> #endif /* vport.h */
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net] net/sched: Fix use of wild pointer in mq_destroy() when qdisc_alloc fail
From: John Fastabend @ 2014-10-24 17:49 UTC (permalink / raw)
To: wang.bo116; +Cc: davem, kaber, netdev, cui.yunfeng
In-Reply-To: <OF7A403C69.2C35464E-ON48257D7B.002E24AA-48257D7B.002F2A62@zte.com.cn>
On 10/24/2014 01:34 AM, wang.bo116@zte.com.cn wrote:
>
[...]
>
> --------------------------------------------------------------------------------
>
> This patch fix this problem, base on linux 3.18-rc-1:
>
> Signed-off-by: Wang Bo <wang.bo116@zte.com.cn>
> Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
> diff --git a/net/sched/sch_mq.c b/net/sched/sch_mq.c
> index 42f72f1..a0c90e7 100755
> --- a/net/sched/sch_mq.c
> +++ b/net/sched/sch_mq.c
> @@ -33,6 +33,7 @@ static void mq_destroy(struct Qdisc *sch)
> for (ntx = 0; ntx < dev->num_tx_queues && priv->qdiscs[ntx]; ntx++)
> qdisc_destroy(priv->qdiscs[ntx]);
> kfree(priv->qdiscs);
> + priv->qdiscs = NULL;
> }
>
> static int mq_init(struct Qdisc *sch, struct nlattr *opt)
>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Patch looks fine, another way to fix this would be drop the
mq_destroy() call in the error path. I'm not convinced one
is any better than the other but maybe some other folks have
opinions, it seems a bit wrong to call mq_destroy twice so in
that sense it may be a bit nicer to drop the mq_destroy().
Also same bug in mqprio do you want to submit a patch for
that qdisc as well? Otherwise I can.
Thanks!
--
John Fastabend Intel Corporation
^ permalink raw reply
* [PATCH net 3/3] cdc-ether: handle promiscuous mode with a set_rx_mode callback
From: Olivier Blin @ 2014-10-24 17:43 UTC (permalink / raw)
To: netdev; +Cc: oneukum, hayeswang, bjorn, davem, Olivier Blin
In-Reply-To: <1414172582-30844-1-git-send-email-olivier.blin@softathome.com>
Promiscuous mode was not supported anymore with my Lenovo adapters
(RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
(cdc-ether: clean packet filter upon probe).
It was not possible to use them in a bridge anymore.
Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
Also-analyzed-by: Loïc Yhuel <loic.yhuel@softathome.com>
---
drivers/net/usb/cdc_ether.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index bee3689..d3920b5 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -76,6 +76,9 @@ static void usbnet_cdc_update_filter(struct usbnet *dev)
USB_CDC_PACKET_TYPE_ALL_MULTICAST | USB_CDC_PACKET_TYPE_DIRECTED |
USB_CDC_PACKET_TYPE_BROADCAST;
+ if (dev->net->flags & IFF_PROMISC)
+ cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
+
/* FIXME cdc-ether has some multicast code too, though it complains
* in routine cases. info->ether describes the multicast support.
* Implement that here, manipulating the cdc filter as needed.
@@ -496,6 +499,7 @@ static const struct driver_info cdc_info = {
.bind = usbnet_cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = usbnet_cdc_status,
+ .set_rx_mode = usbnet_cdc_update_filter,
.manage_power = usbnet_manage_power,
};
@@ -505,6 +509,7 @@ static const struct driver_info wwan_info = {
.bind = usbnet_cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = usbnet_cdc_status,
+ .set_rx_mode = usbnet_cdc_update_filter,
.manage_power = usbnet_manage_power,
};
--
2.1.2
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
^ permalink raw reply related
* [PATCH net 2/3] cdc-ether: extract usbnet_cdc_update_filter function
From: Olivier Blin @ 2014-10-24 17:43 UTC (permalink / raw)
To: netdev; +Cc: oneukum, hayeswang, bjorn, davem, Olivier Blin
In-Reply-To: <1414172582-30844-1-git-send-email-olivier.blin@softathome.com>
This will be used by the set_rx_mode callback.
Also move a comment about multicast filtering in this new function.
Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
---
drivers/net/usb/cdc_ether.c | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 2a32d91..bee3689 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -67,6 +67,32 @@ static const u8 mbm_guid[16] = {
0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
};
+static void usbnet_cdc_update_filter(struct usbnet *dev)
+{
+ struct cdc_state *info = (void *) &dev->data;
+ struct usb_interface *intf = info->control;
+
+ u16 cdc_filter =
+ USB_CDC_PACKET_TYPE_ALL_MULTICAST | USB_CDC_PACKET_TYPE_DIRECTED |
+ USB_CDC_PACKET_TYPE_BROADCAST;
+
+ /* FIXME cdc-ether has some multicast code too, though it complains
+ * in routine cases. info->ether describes the multicast support.
+ * Implement that here, manipulating the cdc filter as needed.
+ */
+
+ usb_control_msg(dev->udev,
+ usb_sndctrlpipe(dev->udev, 0),
+ USB_CDC_SET_ETHERNET_PACKET_FILTER,
+ USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ cdc_filter,
+ intf->cur_altsetting->desc.bInterfaceNumber,
+ NULL,
+ 0,
+ USB_CTRL_SET_TIMEOUT
+ );
+}
+
/* probes control interface, claims data interface, collects the bulk
* endpoints, activates data interface (if needed), maybe sets MTU.
* all pure cdc, except for certain firmware workarounds, and knowing
@@ -347,16 +373,8 @@ next_desc:
* don't do reset all the way. So the packet filter should
* be set to a sane initial value.
*/
- usb_control_msg(dev->udev,
- usb_sndctrlpipe(dev->udev, 0),
- USB_CDC_SET_ETHERNET_PACKET_FILTER,
- USB_TYPE_CLASS | USB_RECIP_INTERFACE,
- USB_CDC_PACKET_TYPE_ALL_MULTICAST | USB_CDC_PACKET_TYPE_DIRECTED | USB_CDC_PACKET_TYPE_BROADCAST,
- intf->cur_altsetting->desc.bInterfaceNumber,
- NULL,
- 0,
- USB_CTRL_SET_TIMEOUT
- );
+ usbnet_cdc_update_filter(dev);
+
return 0;
bad_desc:
@@ -468,10 +486,6 @@ int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
return status;
}
- /* FIXME cdc-ether has some multicast code too, though it complains
- * in routine cases. info->ether describes the multicast support.
- * Implement that here, manipulating the cdc filter as needed.
- */
return 0;
}
EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
--
2.1.2
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
^ permalink raw reply related
* [PATCH net 0/3] cdc-ether: handle promiscuous mode
From: Olivier Blin @ 2014-10-24 17:42 UTC (permalink / raw)
To: netdev; +Cc: oneukum, hayeswang, bjorn, davem, Olivier Blin
Hi,
Since kernel 3.16, my Lenovo USB network adapters (RTL8153) using
cdc-ether are not working anymore in a bridge.
This is due to commit c472ab68ad67db23c9907a27649b7dc0899b61f9, which
resets the packet filter when the device is bound.
The default packet filter set by cdc-ether does not include
promiscuous, while the adapter seemed to have promiscuous enabled by
default.
This patch series allows to support promiscuous mode for cdc-ether, by
hooking into set_rx_mode.
Incidentally, maybe this device should be handled by the r8152 driver,
but this patch series is still nice for other adapters.
Thanks
Olivier Blin (3):
usbnet: add a callback for set_rx_mode
cdc-ether: extract usbnet_cdc_update_filter function
cdc-ether: handle promiscuous mode with a set_rx_mode callback
drivers/net/usb/cdc_ether.c | 47 +++++++++++++++++++++++++++++++--------------
drivers/net/usb/usbnet.c | 20 +++++++++++++++++++
include/linux/usb/usbnet.h | 4 ++++
3 files changed, 57 insertions(+), 14 deletions(-)
--
2.1.2
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
^ permalink raw reply
* [PATCH net 1/3] usbnet: add a callback for set_rx_mode
From: Olivier Blin @ 2014-10-24 17:43 UTC (permalink / raw)
To: netdev; +Cc: oneukum, hayeswang, bjorn, davem, Olivier Blin
In-Reply-To: <1414172582-30844-1-git-send-email-olivier.blin@softathome.com>
To delegate promiscuous mode and multicast filtering to the subdriver.
Signed-off-by: Olivier Blin <olivier.blin@softathome.com>
---
drivers/net/usb/usbnet.c | 20 ++++++++++++++++++++
include/linux/usb/usbnet.h | 4 ++++
2 files changed, 24 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 5173821..53f51fc 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1051,6 +1051,21 @@ static void __handle_link_change(struct usbnet *dev)
clear_bit(EVENT_LINK_CHANGE, &dev->flags);
}
+static void usbnet_set_rx_mode(struct net_device *net)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ usbnet_defer_kevent(dev, EVENT_SET_RX_MODE);
+}
+
+static void __handle_set_rx_mode(struct usbnet *dev)
+{
+ if (dev->driver_info->set_rx_mode)
+ (dev->driver_info->set_rx_mode)(dev);
+
+ clear_bit(EVENT_SET_RX_MODE, &dev->flags);
+}
+
/* work that cannot be done in interrupt context uses keventd.
*
* NOTE: with 2.5 we could do more of this using completion callbacks,
@@ -1156,6 +1171,10 @@ skip_reset:
if (test_bit (EVENT_LINK_CHANGE, &dev->flags))
__handle_link_change(dev);
+ if (test_bit (EVENT_SET_RX_MODE, &dev->flags))
+ __handle_set_rx_mode(dev);
+
+
if (dev->flags)
netdev_dbg(dev->net, "kevent done, flags = 0x%lx\n", dev->flags);
}
@@ -1523,6 +1542,7 @@ static const struct net_device_ops usbnet_netdev_ops = {
.ndo_stop = usbnet_stop,
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
+ .ndo_set_rx_mode = usbnet_set_rx_mode,
.ndo_change_mtu = usbnet_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 26088fe..d9a4905 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -78,6 +78,7 @@ struct usbnet {
# define EVENT_NO_RUNTIME_PM 9
# define EVENT_RX_KILL 10
# define EVENT_LINK_CHANGE 11
+# define EVENT_SET_RX_MODE 12
};
static inline struct usb_driver *driver_of(struct usb_interface *intf)
@@ -159,6 +160,9 @@ struct driver_info {
/* called by minidriver when receiving indication */
void (*indication)(struct usbnet *dev, void *ind, int indlen);
+ /* rx mode change (device changes address list filtering) */
+ void (*set_rx_mode)(struct usbnet *dev);
+
/* for new devices, use the descriptor-reading code instead */
int in; /* rx endpoint */
int out; /* tx endpoint */
--
2.1.2
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
-- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
^ permalink raw reply related
* Re: [PATCH net] net/sched: Fix use of wild pointer in mq_destroy() when qdisc_alloc fail
From: Cong Wang @ 2014-10-24 18:13 UTC (permalink / raw)
To: John Fastabend
Cc: wang.bo116, David Miller, Patrick McHardy, netdev, cui.yunfeng
In-Reply-To: <544A913A.1060100@gmail.com>
On Fri, Oct 24, 2014 at 10:49 AM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> Patch looks fine, another way to fix this would be drop the
> mq_destroy() call in the error path. I'm not convinced one
> is any better than the other but maybe some other folks have
> opinions, it seems a bit wrong to call mq_destroy twice so in
> that sense it may be a bit nicer to drop the mq_destroy().
Dropping mq_destroy() in error path is indeed better,
because upper layer does cleanup intentionally.
Look at what other qdisc's do. :)
^ permalink raw reply
* Re: [PATCH V3.18] rtlwifi: Add check for get_btc_status callback
From: Murilo Opsfelder Araujo @ 2014-10-24 18:13 UTC (permalink / raw)
To: Larry Finger, Mike Galbraith
Cc: linville, linux-wireless, troy_tan, netdev, Thadeu Cascardo
In-Reply-To: <544A80B5.1090604@lwfinger.net>
On 10/24/2014 02:39 PM, Larry Finger wrote:
[...]
>
> Please try the attached patch. It replaces the second one I sent you. I
> will probably redo it before submitting the final copy, but this should
> work.
>
> Larry
>
Hi, Larry.
I've tried your patch on top of next-20141023 and it is still crashing
on my laptop:
http://opsfelder.com/~murilo/lkml/next-20141023_plus_larry_patch_v2.jpg
--
Murilo
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Jay Vosburgh @ 2014-10-24 18:20 UTC (permalink / raw)
To: paulmck
Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang,
Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <20141024145028.GN4977@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote:
>> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
[...]
>> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
>> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
>> >NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
>> >If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
>> >Make nocb leader kthreads process pending callbacks after spawning)
>> >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
>>
>> Just a note to add that I am also reliably inducing what appears
>> to be this issue on a current -net tree, when configuring openvswitch
>> via script. I am available to test patches or bisect tomorrow (Friday)
>> US time if needed.
>
>Thank you, Jay! Could you please check to see if reverting this commit
>fixes things for you?
>
>35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
>
>Reverting is not a long-term fix, as this commit is itself a bug fix,
>but would be good to check to see if you are seeing the same thing that
>Yanko is. ;-)
Just to confirm what Yanko found, reverting this commit makes
the problem go away for me.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 18:33 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang,
Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <5677.1414174811@famine>
On Fri, Oct 24, 2014 at 11:20:11AM -0700, Jay Vosburgh wrote:
> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> >On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote:
> >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> [...]
> >> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> >> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> >> >NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> >> >If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> >> >Make nocb leader kthreads process pending callbacks after spawning)
> >> >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
> >>
> >> Just a note to add that I am also reliably inducing what appears
> >> to be this issue on a current -net tree, when configuring openvswitch
> >> via script. I am available to test patches or bisect tomorrow (Friday)
> >> US time if needed.
> >
> >Thank you, Jay! Could you please check to see if reverting this commit
> >fixes things for you?
> >
> >35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> >
> >Reverting is not a long-term fix, as this commit is itself a bug fix,
> >but would be good to check to see if you are seeing the same thing that
> >Yanko is. ;-)
>
> Just to confirm what Yanko found, reverting this commit makes
> the problem go away for me.
Thank you!
I take it that the patches that don't help Yanko also don't help you?
Thanx, Paul
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 18:32 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024173526.GA26058@declera.com>
On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote:
> On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote:
> > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > > > > >
> > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> > > >
> > > > [ . . . ]
> > > >
> > > > > > > Ok, unless I've messsed up something major, bisecting points to:
> > > > > > >
> > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > > > > >
> > > > > > > Makes any sense ?
> > > > > >
> > > > > > Good question. ;-)
> > > > > >
> > > > > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> > > > >
> > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > > > > to setup its bridge.
> > > > >
> > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > > > > before.
> > >
> > > > Thank you, very interesting. Which 6 of the rcuos are present?
> > >
> > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
> > > Phenom II.
> >
> > Ah, you get 8 without the patch because it creates them for potential
> > CPUs as well as real ones. OK, got it.
> >
> > > > > Awating instructions: :)
> > > >
> > > > Well, I thought I understood the problem until you found that only 6 of
> > > > the expected 8 rcuos are present with linux-tip without the revert. ;-)
> > > >
> > > > I am putting together a patch for the part of the problem that I think
> > > > I understand, of course, but it would help a lot to know which two of
> > > > the rcuos are missing. ;-)
> > >
> > > Ready to test
> >
> > Well, if you are feeling aggressive, give the following patch a spin.
> > I am doing sanity tests on it in the meantime.
>
> Doesn't seem to make a difference here
OK, inspection isn't cutting it, so time for tracing. Does the system
respond to user input? If so, please enable rcu:rcu_barrier ftrace before
the problem occurs, then dump the trace buffer after the problem occurs.
Thanx, Paul
> > ------------------------------------------------------------------------
> >
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 29fb23f33c18..927c17b081c7 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu)
> > rdp->nocb_leader = rdp_spawn;
> > if (rdp_last && rdp != rdp_spawn)
> > rdp_last->nocb_next_follower = rdp;
> > - rdp_last = rdp;
> > - rdp = rdp->nocb_next_follower;
> > - rdp_last->nocb_next_follower = NULL;
> > + if (rdp == rdp_spawn) {
> > + rdp = rdp->nocb_next_follower;
> > + } else {
> > + rdp_last = rdp;
> > + rdp = rdp->nocb_next_follower;
> > + rdp_last->nocb_next_follower = NULL;
> > + }
> > } while (rdp);
> > rdp_spawn->nocb_next_follower = rdp_old_leader;
> > }
> >
>
^ permalink raw reply
* netfilter
From: Jamal Hadi Salim @ 2014-10-24 18:43 UTC (permalink / raw)
To: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: call_for_sponsors3.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 46534 bytes --]
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Jay Vosburgh @ 2014-10-24 18:49 UTC (permalink / raw)
To: paulmck
Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang,
Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos
In-Reply-To: <20141024183226.GW4977@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote:
>> On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote:
>> > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote:
>> > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
>> > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
>> > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
>> > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
>> > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
>> > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
>> > > > > > > > >
>> > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
>> > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
>> > > >
>> > > > [ . . . ]
>> > > >
>> > > > > > > Ok, unless I've messsed up something major, bisecting points to:
>> > > > > > >
>> > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
>> > > > > > >
>> > > > > > > Makes any sense ?
>> > > > > >
>> > > > > > Good question. ;-)
>> > > > > >
>> > > > > > Are any of your online CPUs missing rcuo kthreads? There should be
>> > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
>> > > > >
>> > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
>> > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages
>> > > > > to setup its bridge.
>> > > > >
>> > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
>> > > > > before.
>> > >
>> > > > Thank you, very interesting. Which 6 of the rcuos are present?
>> > >
>> > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
>> > > Phenom II.
>> >
>> > Ah, you get 8 without the patch because it creates them for potential
>> > CPUs as well as real ones. OK, got it.
>> >
>> > > > > Awating instructions: :)
>> > > >
>> > > > Well, I thought I understood the problem until you found that only 6 of
>> > > > the expected 8 rcuos are present with linux-tip without the revert. ;-)
>> > > >
>> > > > I am putting together a patch for the part of the problem that I think
>> > > > I understand, of course, but it would help a lot to know which two of
>> > > > the rcuos are missing. ;-)
>> > >
>> > > Ready to test
>> >
>> > Well, if you are feeling aggressive, give the following patch a spin.
>> > I am doing sanity tests on it in the meantime.
>>
>> Doesn't seem to make a difference here
>
>OK, inspection isn't cutting it, so time for tracing. Does the system
>respond to user input? If so, please enable rcu:rcu_barrier ftrace before
>the problem occurs, then dump the trace buffer after the problem occurs.
My system is up and responsive when the problem occurs, so this
shouldn't be a problem.
Do you want the ftrace with your patch below, or unmodified tip
of tree?
-J
> Thanx, Paul
>
>> > ------------------------------------------------------------------------
>> >
>> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>> > index 29fb23f33c18..927c17b081c7 100644
>> > --- a/kernel/rcu/tree_plugin.h
>> > +++ b/kernel/rcu/tree_plugin.h
>> > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu)
>> > rdp->nocb_leader = rdp_spawn;
>> > if (rdp_last && rdp != rdp_spawn)
>> > rdp_last->nocb_next_follower = rdp;
>> > - rdp_last = rdp;
>> > - rdp = rdp->nocb_next_follower;
>> > - rdp_last->nocb_next_follower = NULL;
>> > + if (rdp == rdp_spawn) {
>> > + rdp = rdp->nocb_next_follower;
>> > + } else {
>> > + rdp_last = rdp;
>> > + rdp = rdp->nocb_next_follower;
>> > + rdp_last->nocb_next_follower = NULL;
>> > + }
>> > } while (rdp);
>> > rdp_spawn->nocb_next_follower = rdp_old_leader;
>> > }
>> >
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH 1/2] staging: lustre: lnet: lnet: do not initialise 0
From: Dmitry Voytik @ 2014-10-24 18:57 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Balavasu, netdev, linux-kernel
In-Reply-To: <54429DAB.4060906@cogentembedded.com>
On Sat, Oct 18, 2014 at 09:04:43PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 10/18/2014 8:03 AM, Balavasu wrote:
>
> >-static int check_routers_before_use = 0;
> >+static int check_routers_before_use = {0};
>
> Eh? I thought {} is only for arrays/structures...
It seems like this is from C++. In C++11 you can even drop '=' like
this:
int i {0};
;)
WBR,
voyt
^ 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