* [PATCH 1/2] igb: fix rtnl race in PM resume path
From: Benjamin Poirier @ 2012-04-05 15:11 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Emil Tantilov, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Fastabend, John Ronciak, netdev,
David S. Miller
Since the caller (PM resume code) is not the one holding rtnl, when taking the
'else' branch rtnl may be released at any moment, thereby defeating the whole
purpose of this code block.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
---
drivers/net/ethernet/intel/igb/igb_main.c | 20 ++++++--------------
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index f022ff7..4854ab6 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1083,9 +1083,12 @@ msi_only:
adapter->flags |= IGB_FLAG_HAS_MSI;
out:
/* Notify the stack of the (possibly) reduced queue counts. */
+ rtnl_lock();
netif_set_real_num_tx_queues(adapter->netdev, adapter->num_tx_queues);
- return netif_set_real_num_rx_queues(adapter->netdev,
- adapter->num_rx_queues);
+ err = netif_set_real_num_rx_queues(adapter->netdev,
+ adapter->num_rx_queues);
+ rtnl_unlock();
+ return err;
}
/**
@@ -6646,18 +6649,7 @@ static int igb_resume(struct device *dev)
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
- if (!rtnl_is_locked()) {
- /*
- * shut up ASSERT_RTNL() warning in
- * netif_set_real_num_tx/rx_queues.
- */
- rtnl_lock();
- err = igb_init_interrupt_scheme(adapter);
- rtnl_unlock();
- } else {
- err = igb_init_interrupt_scheme(adapter);
- }
- if (err) {
+ if (igb_init_interrupt_scheme(adapter)) {
dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
return -ENOMEM;
}
--
1.7.7
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* [PATCH 2/2] ixgbe: add missing rtnl_lock in PM resume path
From: Benjamin Poirier @ 2012-04-05 15:11 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Emil Tantilov, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Fastabend, John Ronciak, netdev,
David S. Miller
In-Reply-To: <1333638664-17062-1-git-send-email-bpoirier@suse.de>
Upon resume from standby, ixgbe may trigger the ASSERT_RTNL() in
netif_set_real_num_tx_queues(). The call stack is:
netif_set_real_num_tx_queues
ixgbe_set_num_queues
ixgbe_init_interrupt_scheme
ixgbe_resume
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
---
Unlike patch 1 for igb, we cannot lock rtnl closer to the point where
netif_set_real_num_tx_queues() is called because ixgbe_init_interrupt_scheme()
is also called by the dcb code, already under rtnl.
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 3e26b1f..ff6edab 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4836,7 +4836,9 @@ static int ixgbe_resume(struct pci_dev *pdev)
pci_wake_from_d3(pdev, false);
+ rtnl_lock();
err = ixgbe_init_interrupt_scheme(adapter);
+ rtnl_unlock();
if (err) {
e_dev_err("Cannot initialize interrupts for device\n");
return err;
--
1.7.7
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [RFC PATCH 0/1] NUMA aware scheduling per cpu vhost thread patch
From: Shirley Ma @ 2012-04-05 15:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, netdev, kvm, tahm, vivek
In-Reply-To: <20120405122824.GB31982@redhat.com>
On Thu, 2012-04-05 at 15:28 +0300, Michael S. Tsirkin wrote:
> On Tue, Mar 27, 2012 at 10:43:03AM -0700, Shirley Ma wrote:
> > On Tue, 2012-03-27 at 18:09 +0800, Jason Wang wrote:
> > > Hi:
> > >
> > > Thanks for the work and it looks very reasonable, some questions
> > > below.
>
> Yes I am happy to see the per-cpu work resurrected.
> Some comments below.
Glad to see you have time on reviewing this.
> > > On 03/23/2012 07:48 AM, Shirley Ma wrote:
> > > > Sorry for being late to submit this patch. I have spent lots of
> time
> > > > trying to find the best approach. This effort is still going
> on...
> > > >
> > > > This patch is built against net-next tree.
> > > >
> > > > This is an experimental RFC patch. The purpose of this patch is
> to
> > > > address KVM networking scalability and NUMA scheduling issue.
> > >
> > > Need also test for non-NUMA machine, I see that you just choose
> the
> > > cpu
> > > that initiates the work for non-numa machine which seems sub
> optimal.
> >
> > Good suggestions. I don't have any non-numa systems. But KK run some
> > tests on non-numa system. He could see around 20% performance gain
> for
> > single VMs local host to guest. I hope we can run a full test on
> > non-numa system.
> >
> > On non-numa system, the same per vhost-cpu thread will be always
> picked
> > up consistently for a particular vq since all cores are on same cpu
> > socket. So there will be two per-cpu vhost threads handle TX/RX
> > simultaneously.
> >
> > > > The existing implementation of vhost creats a vhost thread
> > > per-device
> > > > (virtio_net) based. RX and TX work of a VMs per-device is
> handled by
> > > > same vhost thread.
> > > >
> > > > One of the limitation of this implementation is with increasing
> the
> > > > number VMs or the number of virtio-net interfces, more vhost
> threads
> > > are
> > > > created, it will consume more kernel resources, and induce more
> > > threads
> > > > context switches/scheduling overhead. We noticed that the KVM
> > > network
> > > > performance doesn't scale with increasing number of VMs.
> > > >
> > > > The other limitation is to have single vhost thread to process
> both
> > > RX
> > > > and TX, the work will be blocked. So we create this per cpu
> vhost
> > > thread
> > > > implementation. The number of vhost cpu threads is limited to
> the
> > > number
> > > > of cpus on the host.
> > > >
> > > > To address these limitations, we are propsing a per-cpu vhost
> thread
> > > > model where the number of vhost threads are limited and equal to
> the
> > > > number of online cpus on the host.
> > >
> > > The number of vhost thread needs more consideration. Consider that
> we
> > > have a 1024 cores host with a card have 16 tx/rx queues, do we
> really
> > > need 1024 vhost threads?
> >
> > In this case, we could add a module parameter to limit the number of
> > cores/sockets to be used.
>
> Hmm. And then which cores would we run on?
> Also, is the parameter different between guests?
> Another idea is to scale the # of threads on demand.
If we are able to pass number of guests/vcpus info to vhost, we can
scale the vhost threads. Any API to get this info?
> Sharing the same thread between guests is also an
> interesting approach, if we did this then per-cpu
> won't be so expensive but making this work well
> with cgroups would be a challenge.
Yes, I am comparing vhost thread pool to share among guests approach
with per-cpu vhost approach now.
It's challenge to work with cgroups anyway.
>
> > > >
> > > > Based on our testing experience, the vcpus can be scheduled
> across
> > > cpu
> > > > sockets even when the number of vcpus is smaller than the number
> of
> > > > cores per cpu socket and there is no other activities besides
> KVM
> > > > networking workload. We found that if vhost thread is scheduled
> on
> > > the
> > > > same socket as the work is received, the performance will be
> better.
> > > >
> > > > So in this per cpu vhost thread implementation, a vhost thread
> is
> > > > selected dynamically based on where the TX/RX work is initiated.
> A
> > > vhost
> > > > thread on the same cpu socket is selected but not on the same
> cpu as
> > > the
> > > > vcpu/interrupt thread that initizated the TX/RX work.
> > > >
> > > > When we test this RFC patch, the other interesting thing we
> found is
> > > the
> > > > performance results also seem related to NIC flow steering. We
> are
> > > > spending time on evaluate different NICs flow director
> > > implementation
> > > > now. We will enhance this patch based on our findings later.
> > > >
> > > > We have tried different scheduling: per-device based, per vq
> based
> > > and
> > > > per work type (tx_kick, rx_kick, tx_net, rx_net) based vhost
> > > scheduling,
> > > > we found that so far the per vq based scheduling is good enough
> for
> > > now.
> > >
> > > Could you please explain more about those scheduling strategies?
> Does
> > > per-device based means let a dedicated vhost thread to handle all
> > > work
> > > from that vhost device? As you mentioned, maybe an improvement of
> the
> > > scheduling to take flow steering info (queue mapping, rxhash etc.)
> of
> > > skb in host into account.
> >
> > Yes, per-device scheduling means one per-cpu vhost theads handle all
> > works from one particular vhost-device.
> >
> > Yes, we think scheduling to take flow steering info would help
> > performance. I am studying this now.
>
> Did anything interesing turn up?
Not yet, still investigating.
>
> > > >
> > > > We also tried different algorithm to select which cpu vhost
> thread
> > > will
> > > > running on a specific cpu socket: avg_load balance, and
> randomly...
> > >
> > > May worth to account the out-of-oder packet during the test as for
> a
> > > single stream as different cpu/vhost/physical queue may be chose
> to
> > > do
> > > the packet transmission/reception?
> >
> > Good point. I haven't gone through all data yet. netstat output
> might
> > tell us something.
> >
> > We used Intel 10G NIC to run all test. For a single steam test,
> Intel
> > NIC receiving irq steers with same irq/queue which TX packets have
> been
> > sent. So when we mask vcpus from same VM on one socket, we shouldn't
> hit
> > packet out-of-order case. We might hit packet out of order when
> vcpus
> > run across sockets.
> >
> > > >
> > > > > From our test results, we found that the scalability has been
> > > > significantly improved. And this patch is also helpful for small
> > > packets
> > > > performance.
> > > >
> > > > Hoever, we are seeing some regressions in a local guest to guest
> > > > scenario on a 8 cpu NUMA system.
> > > > In one case, 24 VMs 256 bytes tcp_stream test shows it has
> improved
> > > from
> > > > 810Mb/s to 9.1Gb/s. :)
> > > > (We created two local VMs, and each VM has 2 vcpus. W/o this
> patch,
> > > the
> > > > number of threads is 4 vcpus + 2 vhosts = 6, w/i this patch is 4
> > > vcpus +
> > > > 8 vhosts = 12. It causes more context switches. When I change
> the
> > > > scheduling to use 2-4 vhost threads, the regressions are gone. I
> am
> > > > continue investigation on how to make small number of VMs, local
> > > guest
> > > > to gues performance better. Once I find the clue, I will share
> > > here.)
>
> So, that's one obvious reason. But there could be other explanations:
> 1. You explicitly mask out the same CPU. But if the socket
> is very small (it's likely each socket is 2 CPUs or even 1 here),
> this might limit the scheduler drastically.
Only if we limit guest vcpus on same socket. The default host schedules
vcpus across sockets.
> 2. If guest ends up running on the same socket, you cause
> more IPIs which cause exists for the other guest.
I used different approaches to schedule vhost thread: 1. check loadavg
on a particular cpu; 2. randomly pick up a cpu, the performance didn't
make much difference in a small amount of VMs.
On Tom's 1-24 VMs scalability test, it had impressive results when
amount of VMs are increased compared to existing approach. So it might
not be a big issue.
> > > >
> > > > The cpu hotplug support hasn't in place yet. I will post it
> later.
>
> Not yet done, right?
Done now, under testing.
> > > Another question is why not just using workqueue? It has full
> support
> > > for cpu hotplug and allow more polices.
> >
> > Yes, it's good to use workqueue. I just did everything on top of
> current
> > implementation so it's easy to compare/analyze the performance data.
> >
> > I remembered the vhost implementation changed from workqueue to
> thread
> > for some reason. I couldn't recall the reason.
>
> At the time the implementation didn't perform well with per-cpu
> threads. We wanted a single thread so switched to use just that.
>
> > > >
> > > > Since we have per cpu vhost thread, each vhost thread will
> handle
> > > > multiple vqs, so we will be able to reduce/remove vq
> notification
> > > when
> > > > the work is heavy loaded in future.
> > >
> > > Does this issue still exist if event index is used? If vhost does
> not
> > > publish new used index, guest would not kick again.
> >
> > Since the vhost model has been changed to handle multiple VMs' vqs
> work,
> > then it's not necessary to enable these VMs' vqs notification
> (published
> > new used idex) where these vqs' future work will be processed on the
> > same per-cpu vhost thread, as long as the per-cpu vhost thread is
> still
> > running.
> >
> > > >
> > > > Here is my test results for remote host to guest test: tcp_rrs,
> > > udp_rrs,
> > > > tcp_stream with guest has 2 vpus, host has two cpu socket, each
> > > socket
> > > > has 4 cores.
> > > >
> > > > TCP_STREAM 256 512 1K 2K 4K 8K
> 16K
> > > >
> --------------------------------------------------------------------
> > > > Original
> > > >
> > > H->Guest 2501 4238 4744 5256 7203 6975 5799
> Patch
> > > >
> > > H->Guest 1676 2290 3149 8026 8439 8283
> 8216
> > > >
> > > > Original
> > > >
> > > Guest->H 744 1773 5675 1397 8207 7296
> 8117
> > > > Patch
> > > > Guest->Host 1041 1386 5407 7057 8298 8127
> 8241
> > >
> > > Looks like there's some noise in the result, the throughput of
> > > "original
> > > guest -> Host 2K" looks too low. And some strange is that I see
> > > regressions of packet transmission of guest when testing this
> patch.
> > > (
> > > Guest to Local Host TCP_STREAM in a NUMA machine).
> >
> > Yes, since I didn't mask the vcpus on the same socket, it might come
> > from packets out of order. I will rerun the test w/i masking vcpus
> on
> > the same socket to see any difference.
>
> Did anything interesting turn up?
Haven't had time to focus on single stream result yet.
>
> > You can reference Tom's results. His test is more formal than mine.
> >
> > > >
> > > > 60 instances TCP_RRs: Patch 150K trans/s vs. 91K trans/sec
> > > > 65% improved with taskset vcpus on the same socket
> > > > 60 instances UDP_RRs: Patch 172K trans/s vs. 103K trans/s
> > > > 67% improved with taskset vcpus on the same socket
> > > >
> > > > Tom has run 1VM to 24 VMs test for different work. He will post
> it
> > > here
> > > > soon.
> > > >
> > > > If the host scheduler ensures that the VM's vcpus are not
> scheduled
> > > to
> > > > another socket (i.e. cpu mask the vcpus on same socket) then the
> > > > performance will be better.
> > > >
> > > > Signed-off-by: Shirley Ma<xma@us.ibm.com>
> > > > Signed-off-by: Krishna Kumar<krkumar2@in.ibm.com>
> > > > Tested-by: Tom Lendacky<toml@us.ibm.com>
> > > > ---
> > > >
> > > > drivers/vhost/net.c | 26 ++-
> > > > drivers/vhost/vhost.c | 289
> > > > +++++++++++++++++++++++----------
> > > > drivers/vhost/vhost.h | 16 ++-
> > > > 3 files changed, 232 insertions(+), 103 deletions(-)
> > > >
> > > > Thanks
> > > > Shirley
> > > >
> > > > --
> > > > 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
> > >
> > >
>
> Also a question: how does this interact with zero copy tx?
Yes, I tested this with zero copy tx. The vhost thread which handles tx
work has been significantly reduced.
Thanks
Shirley
^ permalink raw reply
* Re: kernel BUG at include/net/netns/generic.h:41
From: Stanislav Kinsbursky @ 2012-04-05 16:08 UTC (permalink / raw)
To: Myklebust, Trond, Dave Jones; +Cc: Linux Kernel, netdev@vger.kernel.org
In-Reply-To: <1333390230.13718.34.camel@lade.trondhjem.org>
02.04.2012 22:10, Myklebust, Trond пишет:
> This looks related to the recent net namespace changes, so I'm adding
> Stanislav.
>
Hi, Trond.
Looks like we stepped into exactly that situation, what Al Viro was talking on
LFS about early registering of file system before other module "init" operations
completed.
I.e. SUNRPC registers it's file system, and then we have races between
register_pernet_subsys() call and mount of SUNRPC PipeFS.
BTW, these races can be triggered only if mount of SUNRPC PipeFS is called prior
to SUNRPC module insertion is completed. In spite of it, I'll send the patch soon.
But I'm not 100% sure, that this patch will solve Dave's problem.
So, there are few questions to you, Dave:
1) can this happen (PipeFS mount attempt before SUNPRC module insertion has
returned any value) in your case?
2) how often do you experience this problem? Not every boot, I suppose?
3) And is it easy for you to reproduce?
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: kernel BUG at include/net/netns/generic.h:41
From: Dave Jones @ 2012-04-05 16:12 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Myklebust, Trond, Linux Kernel, netdev@vger.kernel.org
In-Reply-To: <4F7DC37F.7090404@parallels.com>
On Thu, Apr 05, 2012 at 08:08:31PM +0400, Stanislav Kinsbursky wrote:
> So, there are few questions to you, Dave:
> 1) can this happen (PipeFS mount attempt before SUNPRC module insertion has
> returned any value) in your case?
I don't know enough of what systemd is doing to answer this.
> 2) how often do you experience this problem? Not every boot, I suppose?
> 3) And is it easy for you to reproduce?
It happens most the time, but not every time.
Dave
^ permalink raw reply
* Re: kernel BUG at include/net/netns/generic.h:41
From: Stanislav Kinsbursky @ 2012-04-05 16:14 UTC (permalink / raw)
To: Dave Jones, Myklebust, Trond, Linux Kernel,
netdev@vger.kernel.org
In-Reply-To: <20120405161241.GA23658@redhat.com>
05.04.2012 20:12, Dave Jones пишет:
> On Thu, Apr 05, 2012 at 08:08:31PM +0400, Stanislav Kinsbursky wrote:
>
> > So, there are few questions to you, Dave:
> > 1) can this happen (PipeFS mount attempt before SUNPRC module insertion has
> > returned any value) in your case?
>
> I don't know enough of what systemd is doing to answer this.
>
> > 2) how often do you experience this problem? Not every boot, I suppose?
> > 3) And is it easy for you to reproduce?
>
> It happens most the time, but not every time.
>
Ok, I'll send the patch soon.
Hope, it will help.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [RFC PATCH 2/2] PID-based packet filtering support
From: chetan loke @ 2012-04-05 16:29 UTC (permalink / raw)
To: Nuno Martins; +Cc: netdev, Alfredo Matos, Paulo Trezentos
In-Reply-To: <CALKxAXVK9EhJiNOuq0JYqWiw75q3TYCScp+bGf-qqF_irKYtbA@mail.gmail.com>
On Thu, Apr 5, 2012 at 5:41 AM, Nuno Martins
<nuno.martins@caixamagica.pt> wrote:
> Our tests with 1024 node tree gives us something like 1.3 us on
> average. Your suggestion makes a lot of sense, and we will definitely
> look into.
> This doesn't seem hard to do as we are considering introducing a pid
> based hash table, with a tree in each entry, which can and possibly
> should be pre-allocated.
Also as a defensive mechanism(and if not present already) it may not
be a bad idea to add the following check whenever you are adding or
deleting a node:
if (pidmonitor->curr_num_monitored_pid_nodes >
pidmax_or_whichever_runtime_max_scheduler_uses) {
WARN_ONCE(....);
delete_all_nodes_from_the_tree(); // including the current one -
if you were in the middle of a new insert.
// This way at least your monitoring tool might pick this up and
the user/sysadmin might dig into it.
}
Note: pidmonitor is some global struct and
curr_num_monitored_pid_nodes == number of pids you are currently
monitoring.
By adding this minimal code, if there are any stray nodes in the
tree(over a period of time) because of a bug in the clean up logic
then we might be able to detect it.
> Nuno Martins
Chetan
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: Ben Hutchings @ 2012-04-05 16:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jeff Kirsher, davem, Don Skidmore, netdev, gospo, sassmann
In-Reply-To: <4F7D8DD4.5080205@openwrt.org>
On Thu, 2012-04-05 at 14:19 +0200, Florian Fainelli wrote:
> Hi,
>
> Le 04/05/12 12:47, Jeff Kirsher a écrit :
> > From: Don Skidmore<donald.c.skidmore@intel.com>
> >
> > This patch exports non-thermal (which was done via hwmon in an earlier
> > patch) data to syfs. All of the fields are read only as this interface
> > is to only export driver data.
> >
> > Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com>
> > Tested-by: Stephen Ko<stephen.s.ko@intel.com>
> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> > ---
>
> I only looked briefly at the exported attributes, but most of them can
> already be queried using ethtool, can't they?
[...]
I agree, it looks like most of these are:
(1) already exposed through ethtool commands (ETHTOOL_GSET,
ETHTOOL_GDRVINFO, ETHTOOL_GLINK and ETHTOOL_GPERMADDR), or
(2) already exposed through rtnetlink or the net device in sysfs, or
(3) statistics that should be exposed through ETHTOOL_GSTATS
I imagine there are some that don't fall into those categories, but I
don't see why they should *all* be exposed in a non-standard and/or
redundant way.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Cloud Hosting and Server
From: woody @ 2012-04-05 16:27 UTC (permalink / raw)
Dear All,
We are one of the top Cloud Solution provider base in Hong Kong, with over 10+ years experience,
we providing better than good and lower cost service of CLoud Hosting (Cloud Server / Hosting / CDN)
Starting at $1.99, let's come to experience and enjoy our powerful cloud system.
Thanks for your time and appreciated to look arround our website.
http://www.dedicatedserver.com.hk/
Best Regards,
The 36cloud Team
If you do not wish to further receive this event message, email "subscriber@dedicatedserver.com.hk" to unsubscribe this message or revoe your email from the list.
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Jay Vosburgh @ 2012-04-05 16:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
Veaceslav Falico <vfalico@redhat.com> wrote:
>When a slave comes up, we're unsetting the current_arp_slave without
>removing active flags from it, which can lead to situations where we have
>more than one slave with active flags in active-backup mode.
>
>To avoid this situation we must remove the active flags from a slave before
>removing it as a current_arp_slave.
>
>Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>---
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 0c76186..ad731a1 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3001,7 +3001,11 @@ static void bond_ab_arp_commit(struct bonding *bond, int delta_in_ticks)
> trans_start + delta_in_ticks)) ||
> bond->curr_active_slave != slave) {
> slave->link = BOND_LINK_UP;
>- bond->current_arp_slave = NULL;
>+ if (bond->current_arp_slave) {
>+ bond_set_slave_inactive_flags(
>+ bond->current_arp_slave);
>+ bond->current_arp_slave = NULL;
>+ }
>
> pr_info("%s: link status definitely up for interface %s.\n",
> bond->dev->name, slave->dev->name);
>
^ permalink raw reply
* Re: [RFC PATCH 0/1] NUMA aware scheduling per cpu vhost thread patch
From: Shirley Ma @ 2012-04-05 16:48 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, netdev, kvm, tahm, vivek
In-Reply-To: <1333639327.6061.20.camel@oc3660625478.ibm.com>
On Thu, 2012-04-05 at 08:22 -0700, Shirley Ma wrote:
> Haven't had time to focus on single stream result yet.
I forgot to mention that if I switch the vhost scheduling to per-device
based from per vq based, this minor single stream test regression will
be gone. However the improvement of tcp_rrs, udp_rrs and other stream
case performance will also gone.
Shirley
^ permalink raw reply
* [PATCH] SUNRPC: register PipeFS file system after pernet sybsystem
From: Stanislav Kinsbursky @ 2012-04-05 17:04 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davej, davem, devel
PipeFS superblock creation routine relays on SUNRPC pernet data presense, which
is created on register_pernet_subsys() call in SUNRPC module init function.
Registering of PipeFS filesystem prior to registering of per-net subsystem
leads to races (mount of PipeFS can dereference uninitialized data).
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/sunrpc_syms.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index 8adfc88..3d6498a 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -75,20 +75,21 @@ static struct pernet_operations sunrpc_net_ops = {
static int __init
init_sunrpc(void)
{
- int err = register_rpc_pipefs();
+ int err = rpc_init_mempool();
if (err)
goto out;
- err = rpc_init_mempool();
- if (err)
- goto out2;
err = rpcauth_init_module();
if (err)
- goto out3;
+ goto out2;
cache_initialize();
err = register_pernet_subsys(&sunrpc_net_ops);
if (err)
+ goto out3;
+
+ err = register_rpc_pipefs();
+ if (err)
goto out4;
#ifdef RPC_DEBUG
rpc_register_sysctl();
@@ -98,11 +99,11 @@ init_sunrpc(void)
return 0;
out4:
- rpcauth_remove_module();
+ unregister_pernet_subsys(&sunrpc_net_ops);
out3:
- rpc_destroy_mempool();
+ rpcauth_remove_module();
out2:
- unregister_rpc_pipefs();
+ rpc_destroy_mempool();
out:
return err;
}
^ permalink raw reply related
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Andy Gospodarek @ 2012-04-05 18:06 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
On Thu, Apr 05, 2012 at 03:47:43PM +0200, Veaceslav Falico wrote:
> When a slave comes up, we're unsetting the current_arp_slave without
> removing active flags from it, which can lead to situations where we have
> more than one slave with active flags in active-backup mode.
>
> To avoid this situation we must remove the active flags from a slave before
> removing it as a current_arp_slave.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Maciej Rutecki @ 2012-04-05 18:37 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Johannes Berg, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev
In-Reply-To: <20120405103254.GE2378@redhat.com>
On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > -ilw
> > +netdev
> >
> > I have no idea what this could be, but I'm almost certain it's not
> > caused by our wireless driver. Looks more like rtl8169 is to blame.
>
> I'm not sure. Looks like there is deadlock or infinite loop in process
> that holds rtnl lock. This can be wireless driver, wired driver or
> generic network code bug.
>
> Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> find any deadlock. If not, when problem will happen please do
Did you mean "CONFIG_LOCKDEP_SUPPORT"?
$ cat /boot/config-3.4.0-rc1 | grep CONFIG_LOCKDEP
CONFIG_LOCKDEP_SUPPORT=y
>
> echo w > /proc/sysrq-trigger
> dmesg -c > dmesg1.txt
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg1.txt
> echo t > /proc/sysrq-trigger
> dmesg > dmesg2.txt
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg2.txt
>
> and provide those files.
>
> Additionally there are also lot in dmesg:
>
> netlink: 140 bytes leftover after parsing attributes.
>
> This need to be investigated as well. Perhaps you could modify error
> message, to show what netlink messages/attributes are processed.
>
> Thanks
> Stanislaw
BTW. From tomorrow till Tuesday I'll be on vacation, so until then I could
respond to the e-mails.
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply
* [PATCH net-next] tcp: Fix bug when gap in rcv sequence is filled
From: Vijay Subramanian @ 2012-04-05 18:46 UTC (permalink / raw)
To: netdev; +Cc: davem, ncardwell, ilpo.jarvinen, Vijay Subramanian
As per RFC2581 and the newer RFC5681, "the receiver SHOULD send an immediate ACK
when it receives a data segment that fills in all or part of a gap in the
sequence space." When TCP receiver gets the next in-sequence packet, we move
data from ofo queue to receive queue. At this point, we should send an immediate
ack by entering quickack mode. In the current code, instead of entering
quickack mode upon requeing packets from ofo queue to receive_queue, we enter
quickack mode only when ofo queue becomes empty after requeuing. This ignores
the possibility that there may be further packets left in ofo queue. This patch
fixes this behavior and enters quickack mode whenever packets are moved from ofo
queue to receive queue.
Also, comment has been updated to reflect that RFC5681 obsoletes RFC2581.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
net/ipv4/tcp_input.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..ebed78d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4388,12 +4388,14 @@ static void tcp_sack_remove(struct tcp_sock *tp)
/* This one checks to see if we can put data from the
* out_of_order queue into the receive_queue.
+ * Return 1 if data is moved from ofo queue to receive_queue and 0 otherwise.
*/
-static void tcp_ofo_queue(struct sock *sk)
+static int tcp_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
__u32 dsack_high = tp->rcv_nxt;
struct sk_buff *skb;
+ bool requeued = false; /*true if an skb is requeued to receive_queue*/
while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {
if (after(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
@@ -4418,10 +4420,12 @@ static void tcp_ofo_queue(struct sock *sk)
__skb_unlink(skb, &tp->out_of_order_queue);
__skb_queue_tail(&sk->sk_receive_queue, skb);
+ requeued = true;
tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;
if (tcp_hdr(skb)->fin)
tcp_fin(sk);
}
+ return requeued ? 1 : 0 ;
}
static int tcp_prune_ofo_queue(struct sock *sk);
@@ -4636,12 +4640,11 @@ queue_and_out:
tcp_fin(sk);
if (!skb_queue_empty(&tp->out_of_order_queue)) {
- tcp_ofo_queue(sk);
- /* RFC2581. 4.2. SHOULD send immediate ACK, when
- * gap in queue is filled.
+ /* RFC5681 (which obsoletes RFC2581.) 4.2. SHOULD send
+ * immediate ACK, when gap in queue is filled.
*/
- if (skb_queue_empty(&tp->out_of_order_queue))
+ if (tcp_ofo_queue(sk))
inet_csk(sk)->icsk_ack.pingpong = 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Johannes Berg @ 2012-04-05 18:56 UTC (permalink / raw)
To: maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <201204052037.37497.maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2012-04-05 at 20:37 +0200, Maciej Rutecki wrote:
> On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> > On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > > -ilw
> > > +netdev
> > >
> > > I have no idea what this could be, but I'm almost certain it's not
> > > caused by our wireless driver. Looks more like rtl8169 is to blame.
> >
> > I'm not sure. Looks like there is deadlock or infinite loop in process
> > that holds rtnl lock. This can be wireless driver, wired driver or
> > generic network code bug.
> >
> > Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> > find any deadlock. If not, when problem will happen please do
>
> Did you mean "CONFIG_LOCKDEP_SUPPORT"?
No, _SUPPORT means you could enable CONFIG_LOCKDEP, but we would like to
see this with CONFIG_LOCKDEP enabled.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] phonet: Check input from user before allocating
From: Sasha Levin @ 2012-04-05 22:07 UTC (permalink / raw)
To: remi.denis-courmont, davem; +Cc: davej, netdev, linux-kernel, Sasha Levin
A phonet packet is limited to USHRT_MAX bytes, this is never checked during
tx which means that the user can specify any size he wishes, and the kernel
will attempt to allocate that size.
In the good case, it'll lead to the following warning, but it may also cause
the kernel to kick in the OOM and kill a random task on the server.
[ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730()
[ 8921.749770] Pid: 5081, comm: trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46
[ 8921.756672] Call Trace:
[ 8921.758185] [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
[ 8921.762868] [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
[ 8921.765399] [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
[ 8921.769226] [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
[ 8921.771686] [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
[ 8921.773919] [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
[ 8921.776248] [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
[ 8921.778294] [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
[ 8921.780847] [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
[ 8921.783179] [<ffffffff821b3c65>] __alloc_skb+0x75/0x170
[ 8921.784971] [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
[ 8921.787111] [<ffffffff821b002e>] ? release_sock+0x7e/0x90
[ 8921.788973] [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
[ 8921.791052] [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380
[ 8921.792931] [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
[ 8921.794917] [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
[ 8921.797053] [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
[ 8921.798992] [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
[ 8921.801395] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.803501] [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
[ 8921.805505] [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
[ 8921.807860] [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
[ 8921.809986] [<ffffffff811958e7>] ? might_fault+0x97/0xa0
[ 8921.811998] [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
[ 8921.814595] [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
[ 8921.816702] [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
[ 8921.818819] [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
[ 8921.820863] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.823318] [<ffffffff811e1926>] vfs_writev+0x46/0x60
[ 8921.825219] [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0
[ 8921.827127] [<ffffffff82658039>] system_call_fastpath+0x16/0x1b
[ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/phonet/pep.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index 9f60008..caee99e 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -1130,6 +1130,9 @@ static int pep_sendmsg(struct kiocb *iocb, struct sock *sk,
int flags = msg->msg_flags;
int err, done;
+ if (len > USHRT_MAX)
+ return -EMSGSIZE;
+
if ((msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|
MSG_CMSG_COMPAT)) ||
!(msg->msg_flags & MSG_EOR))
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH v2] phonet: Check input from user before allocating
From: Rémi Denis-Courmont @ 2012-04-05 19:14 UTC (permalink / raw)
To: Sasha Levin; +Cc: remi.denis-courmont, davem, davej, netdev, linux-kernel
In-Reply-To: <1333663665-3999-1-git-send-email-levinsasha928@gmail.com>
Le vendredi 6 avril 2012 01:07:45 Sasha Levin, vous avez écrit :
> A phonet packet is limited to USHRT_MAX bytes, this is never checked during
> tx which means that the user can specify any size he wishes, and the kernel
> will attempt to allocate that size.
>
> In the good case, it'll lead to the following warning, but it may also
> cause the kernel to kick in the OOM and kill a random task on the server.
>
> [ 8921.744094] WARNING: at mm/page_alloc.c:2255
> __alloc_pages_slowpath+0x65/0x730() [ 8921.749770] Pid: 5081, comm:
> trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46 [
> 8921.756672] Call Trace:
> [ 8921.758185] [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
> [ 8921.762868] [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
> [ 8921.765399] [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
> [ 8921.769226] [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
> [ 8921.771686] [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
> [ 8921.773919] [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
> [ 8921.776248] [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
> [ 8921.778294] [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
> [ 8921.780847] [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
> [ 8921.783179] [<ffffffff821b3c65>] __alloc_skb+0x75/0x170
> [ 8921.784971] [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
> [ 8921.787111] [<ffffffff821b002e>] ? release_sock+0x7e/0x90
> [ 8921.788973] [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
> [ 8921.791052] [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380
> [ 8921.792931] [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
> [ 8921.794917] [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
> [ 8921.797053] [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
> [ 8921.798992] [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
> [ 8921.801395] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
> [ 8921.803501] [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
> [ 8921.805505] [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
> [ 8921.807860] [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
> [ 8921.809986] [<ffffffff811958e7>] ? might_fault+0x97/0xa0
> [ 8921.811998] [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
> [ 8921.814595] [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
> [ 8921.816702] [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
> [ 8921.818819] [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
> [ 8921.820863] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
> [ 8921.823318] [<ffffffff811e1926>] vfs_writev+0x46/0x60
> [ 8921.825219] [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0
> [ 8921.827127] [<ffffffff82658039>] system_call_fastpath+0x16/0x1b
> [ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> ---
> net/phonet/pep.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/phonet/pep.c b/net/phonet/pep.c
> index 9f60008..caee99e 100644
> --- a/net/phonet/pep.c
> +++ b/net/phonet/pep.c
> @@ -1130,6 +1130,9 @@ static int pep_sendmsg(struct kiocb *iocb, struct
> sock *sk, int flags = msg->msg_flags;
> int err, done;
>
> + if (len > USHRT_MAX)
> + return -EMSGSIZE;
> +
> if ((msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|
> MSG_CMSG_COMPAT)) ||
> !(msg->msg_flags & MSG_EOR))
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Ben Hutchings @ 2012-04-05 19:21 UTC (permalink / raw)
To: David Miller; +Cc: arvid.brodin, shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <20120404.201739.672373176675875061.davem@davemloft.net>
On Wed, 2012-04-04 at 20:17 -0400, David Miller wrote:
> From: Arvid Brodin <arvid.brodin@enea.com>
> Date: Thu, 5 Apr 2012 01:09:48 +0200
>
> > - icmp_param.data.icmph = *icmp_hdr(skb);
> > + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
> > + sizeof(icmp_param.data.icmph));
>
> GCC can and will optimize this into an inline assignment, and thus
> have the same unaligned access problems, because it determines
> alignment based upon the types involved.
So presumably icmp_hdr() should be changed to skb_transport_header().
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] tcp: Fix bug when gap in rcv sequence is filled
From: chetan loke @ 2012-04-05 19:21 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, davem, ncardwell, ilpo.jarvinen
In-Reply-To: <1333651563-3279-1-git-send-email-subramanian.vijay@gmail.com>
On Thu, Apr 5, 2012 at 2:46 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
> +static int tcp_ofo_queue(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> __u32 dsack_high = tp->rcv_nxt;
> struct sk_buff *skb;
> + bool requeued = false; /*true if an skb is requeued to receive_queue*/
why introduce a bool then ? Change it to int(init to 0) and then
'return requeued' ?
Chetan
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Maciej Rutecki @ 2012-04-05 20:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev
In-Reply-To: <1333652183.3494.21.camel@jlt3.sipsolutions.net>
On czwartek, 5 kwietnia 2012 o 20:56:23 Johannes Berg wrote:
> On Thu, 2012-04-05 at 20:37 +0200, Maciej Rutecki wrote:
> > On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> > > On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > > > -ilw
> > > > +netdev
> > > >
> > > > I have no idea what this could be, but I'm almost certain it's not
> > > > caused by our wireless driver. Looks more like rtl8169 is to blame.
> > >
> > > I'm not sure. Looks like there is deadlock or infinite loop in process
> > > that holds rtnl lock. This can be wireless driver, wired driver or
> > > generic network code bug.
> > >
> > > Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> > > find any deadlock. If not, when problem will happen please do
> >
> > Did you mean "CONFIG_LOCKDEP_SUPPORT"?
>
> No, _SUPPORT means you could enable CONFIG_LOCKDEP, but we would like to
> see this with CONFIG_LOCKDEP enabled.
>
> johannes
Dmesg when CONFIG_LOCKDEP is set:
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Marcelo Leitner @ 2012-04-05 20:22 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
On 04/05/2012 10:47 AM, Veaceslav Falico wrote:
> When a slave comes up, we're unsetting the current_arp_slave without
> removing active flags from it, which can lead to situations where we have
> more than one slave with active flags in active-backup mode.
>
> To avoid this situation we must remove the active flags from a slave before
> removing it as a current_arp_slave.
>
> Signed-off-by: Veaceslav Falico<vfalico@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Johannes Berg @ 2012-04-05 20:23 UTC (permalink / raw)
To: maciej.rutecki
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev, Francois Romieu
In-Reply-To: <201204052208.21270.maciej.rutecki@gmail.com>
On Thu, 2012-04-05 at 22:08 +0200, Maciej Rutecki wrote:
> Dmesg when CONFIG_LOCKDEP is set:
>
> http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
Looks like rtl8169's fault:
[ 240.541718] 2 locks held by ifconfig/4964:
[ 240.541722] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8138c86c>]
rtnl_lock+0x12/0x14
[ 240.541737] #1: (&tp->wk.mutex){+.+...}, at: [<ffffffffa00c1556>]
rtl_lock_work+0x12/0x14 [r8169]
[ 360.350345] INFO: task nmbd:2378 blocked for more than 120 seconds.
[ 360.353186] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 360.356124] nmbd D ffffffff81a76ab8 0 2378 1
0x00000000
[ 360.359078] ffff88022f573ab8 0000000000000046 ffff880233aa8040
ffff88022f573fd8
[ 360.362098] ffff88022f573fd8 0000000000013a40 ffff8802351b8040
ffff880233aa8040
[ 360.365170] ffffffff814532aa 000000001e3e7680 ffffffff81a76ab0
ffff880233aa8040
[ 360.368208] Call Trace:
[ 360.371129] [<ffffffff814532aa>] ? __mutex_lock_common+0x230/0x36e
[ 360.374159] [<ffffffff814543ca>] schedule+0x5f/0x61
[ 360.377195] [<ffffffff8145458e>] schedule_preempt_disabled+0x9/0xb
[ 360.380240] [<ffffffff814532b7>] __mutex_lock_common+0x23d/0x36e
[ 360.383262] [<ffffffff8138c86c>] ? rtnl_lock+0x12/0x14
[ 360.386260] [<ffffffff8139fe60>] ? netlink_lookup+0x2b/0x7e
[ 360.389279] [<ffffffff8138c86c>] ? rtnl_lock+0x12/0x14
[ 360.392352] [<ffffffff814534a7>] mutex_lock_nested+0x2a/0x31
[ 360.395393] [<ffffffff8138c86c>] rtnl_lock+0x12/0x14
[ 360.398376] [<ffffffff8138c87f>] rtnetlink_rcv+0x11/0x28
[ 360.401292] [<ffffffff813a1d9a>] netlink_unicast+0xe7/0x151
[ 360.404192] [<ffffffff813a2002>] netlink_sendmsg+0x1fe/0x236
[ 360.407089] [<ffffffff8136cd79>] sock_sendmsg+0xea/0x10d
[ 360.409971] [<ffffffff81080679>] ? lock_acquire+0xef/0xfe
[ 360.412825] [<ffffffff810e6bf8>] ? might_fault+0x40/0x90
[ 360.415640] [<ffffffff81080679>] ? lock_acquire+0xef/0xfe
[ 360.418447] [<ffffffff810e6bf8>] ? might_fault+0x40/0x90
[ 360.421239] [<ffffffff8108057e>] ? lock_release+0x175/0x181
[ 360.424039] [<ffffffff810e6c41>] ? might_fault+0x89/0x90
[ 360.426896] [<ffffffff8136b5ec>] ? copy_from_user+0x2a/0x2c
[ 360.429661] [<ffffffff8136e9e5>] sys_sendto+0x12a/0x16c
[ 360.432430] [<ffffffff8107d74f>] ? trace_hardirqs_off_caller
+0x33/0x90
[ 360.435219] [<ffffffff81455515>] ? retint_swapgs+0x13/0x1b
[ 360.437978] [<ffffffff81080a85>] ? trace_hardirqs_on_caller
+0x121/0x158
[ 360.440795] [<ffffffff8121250e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 360.443868] [<ffffffff8145acb9>] system_call_fastpath+0x16/0x1b
johannes
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Francois Romieu @ 2012-04-05 21:01 UTC (permalink / raw)
To: Johannes Berg
Cc: maciej.rutecki, Stanislaw Gruszka, Linux Kernel Mailing List,
Rafael J. Wysocki, linux-wireless, netdev
In-Reply-To: <1333657409.3494.22.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> :
> On Thu, 2012-04-05 at 22:08 +0200, Maciej Rutecki wrote:
>
> > Dmesg when CONFIG_LOCKDEP is set:
> >
> > http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
>
> Looks like rtl8169's fault:
Fix is on the way to mainline, see http://patchwork.ozlabs.org/patch/150541
--
Ueimor
Will code drivers for food.
^ permalink raw reply
* Re: [PATCH] m68k/atari: EtherNEC - rewrite to use mainstream ne.c, take two
From: Michael Schmitz @ 2012-04-05 22:10 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Paul Gortmaker, linux-m68k, netdev
In-Reply-To: <CAMuHMdWSzG4npwjpJ=cwNFKhyBZjvgPn1sp6nZ2re6QsRWPpXg@mail.gmail.com>
Geert,
>> How much lower? Enough to matter? Implicit in that question is
>> the assumption that this is largely a hobbyist platform and nobody
>> is using it in a closet to route gigabytes of traffic.
>>
>
> One other thing we could do is increase CONFIG_HZ to 250.
>
Making 3.x kernels run even more sluggish than they already do?
>> Also, the only advantage to modifying ne.c is to allow dumping
>> the old driver. What is the "remove soon" plan? Any reason
>> for it to not be synchronous? That would eliminate the Kconfig
>> churn and the introduction of the _OLD option. Modifying ne.c
>> and then deciding to keep the old driver because it is "faster"
>> would make this change pointless.
>>
>
> From my point of view, "remove soon" means it will never hit mainline.
>
That's what I meant to say - my patch is based on the m68k tree which
currently has another driver for this hardware, based on an older
version of ne.c which was never submitted to mainline. The old driver
would be removed from the m68k tree as soon as possible.
>> This seems more klunky than it needs to be. If we assume that anyone
>> building ne.c on atari is hence trying to drive an ethernec device
>> than it can just be
>>
>> #ifdef CONFIG_ATARI
>> #define EI_IRQ_FLAGS IRQF_SHARED
>> #else
>> #define EI_IRQ_FLAGS 0
>> #endif
>>
>
> Indeed, with a small modification (keep multi-platform kernels in mind):
>
> #ifdef CONFIG_ATARI
> #define EI_IRQ_FLAGS (MACH_IS_ATARI ? IRQF_SHARED : 0)
> #else
> #define EI_IRQ_FLAGS 0
> #endif
>
Right you are. Is any other m68k platform using ne.c directly, or do you
plan to convert all other NE2000 based drivers to ne.c now?
Cheers,
Michael
^ 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