* Re: Memory leak in ip_dst_cache
From: Eric Dumazet @ 2011-09-12 6:28 UTC (permalink / raw)
To: Kumar S; +Cc: Neil Horman, netdev
In-Reply-To: <1315807643.92529.YahooMailNeo@web113911.mail.gq1.yahoo.com>
Le dimanche 11 septembre 2011 à 23:07 -0700, Kumar S a écrit :
> ----- Original Message -----
> From: Eric Dumazet <eric.dumazet@gmail.com>
> To: Kumar S <ps2kumar@yahoo.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
> Sent: Sunday, September 11, 2011 10:40 PM
> Subject: Re: Memory leak in ip_dst_cache
>
> Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
>
> Please dont top post.
>
> >> Thanks Neil. I did try with prink(). I do see entries getting aged
> >> out, but they are not getting deallocated. This seems to be happening
> >> because of "ref_cnt". When the route entries are added the ref_cnt is
> >> set to 1. Looks this is causing trouble clearing the entries
> >> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
> >> trying to understand whether this is right. Please let me know if you
> >> have any thoughts on it.
>
> >I believe I already explained what was happening.
>
> >A tcp socket has a pointer to a dst, so it holds a reference on it, to
> >make sure no freeing of dst can happen while at least some socket still
> >can reference dst. (It could reference freed memory and crash)
>
> >As soon as the tcp socket will try to transmit some data, the dst will
> >be checked and we notice its obsolete : We then release the refcount and
> >dst pointer.
>
> >Later, the garbage collector can notice dst refcount is zero and can
> >free dst.
>
> >If you have dormant tcp sockets (no trafic at all), they hold their dst.
> >A dormant tcp socket has a pretty more expensive memory cost than its
> >dst. (Socket structure, dentry, inode, and probably in user land a
> >thread or process, and data)
>
> Thanks Eric for detailed explanation. You did mention this before.
> What I see is the cache entries related to the TCP sockets are getting
> cleared, whenever they age out. But the issue we see here is with the
> broadcast messages such as SMB messages and network neighbor hood
> messages. They never get freed. There is no traffic to those
> destinations from our board.
What do you mean ? Your box is a router only ?
Those SMB messages are going through it ?
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 6:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neil Horman, netdev
In-Reply-To: <1315806031.3174.16.camel@edumazet-laptop>
----- Original Message -----
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
Sent: Sunday, September 11, 2011 10:40 PM
Subject: Re: Memory leak in ip_dst_cache
Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
Please dont top post.
>> Thanks Neil. I did try with prink(). I do see entries getting aged
>> out, but they are not getting deallocated. This seems to be happening
>> because of "ref_cnt". When the route entries are added the ref_cnt is
>> set to 1. Looks this is causing trouble clearing the entries
>> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
>> trying to understand whether this is right. Please let me know if you
>> have any thoughts on it.
>I believe I already explained what was happening.
>A tcp socket has a pointer to a dst, so it holds a reference on it, to
>make sure no freeing of dst can happen while at least some socket still
>can reference dst. (It could reference freed memory and crash)
>As soon as the tcp socket will try to transmit some data, the dst will
>be checked and we notice its obsolete : We then release the refcount and
>dst pointer.
>Later, the garbage collector can notice dst refcount is zero and can
>free dst.
>If you have dormant tcp sockets (no trafic at all), they hold their dst.
>A dormant tcp socket has a pretty more expensive memory cost than its
>dst. (Socket structure, dentry, inode, and probably in user land a
>thread or process, and data)
Thanks Eric for detailed explanation. You did mention this before. What I see is the cache entries related to the TCP sockets are getting cleared, whenever they age out. But the issue we see here is with the broadcast messages such as SMB messages and network neighbor hood messages. They never get freed. There is no traffic to those destinations from our board.
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Eric Dumazet @ 2011-09-12 5:40 UTC (permalink / raw)
To: Kumar S; +Cc: Neil Horman, netdev
In-Reply-To: <1315798710.96027.YahooMailNeo@web113913.mail.gq1.yahoo.com>
Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
Please dont top post.
> Thanks Neil. I did try with prink(). I do see entries getting aged
> out, but they are not getting deallocated. This seems to be happening
> because of "ref_cnt". When the route entries are added the ref_cnt is
> set to 1. Looks this is causing trouble clearing the entries
> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
> trying to understand whether this is right. Please let me know if you
> have any thoughts on it.
I believe I already explained what was happening.
A tcp socket has a pointer to a dst, so it holds a reference on it, to
make sure no freeing of dst can happen while at least some socket still
can reference dst. (It could reference freed memory and crash)
As soon as the tcp socket will try to transmit some data, the dst will
be checked and we notice its obsolete : We then release the refcount and
dst pointer.
Later, the garbage collector can notice dst refcount is zero and can
free dst.
If you have dormant tcp sockets (no trafic at all), they hold their dst.
A dormant tcp socket has a pretty more expensive memory cost than its
dst. (Socket structure, dentry, inode, and probably in user land a
thread or process, and data)
^ permalink raw reply
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Paul Menage @ 2011-09-12 5:03 UTC (permalink / raw)
To: Glauber Costa
Cc: Greg Thelen, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal
In-Reply-To: <4E699341.9010606@parallels.com>
On Thu, Sep 8, 2011 at 9:17 PM, Glauber Costa <glommer@parallels.com> wrote:
> On 09/08/2011 06:53 PM, Greg Thelen wrote:
>>
>> On Wed, Sep 7, 2011 at 9:44 PM, Glauber Costa<glommer@parallels.com>
>> wrote:
>>
>> Thanks for your ideas and patience.
>
> Likewise. It is turning out to be a very fruitful
> discussion.
>
This also got a fair bit of attention at LPC on Thursday - shame you
couldn't make it, but I hope you had no problems getting your visa!
I definitely think that there was no consensus reached on unified
versus split charging - but I think that we can work around that and
keep everyone happy, see below.
>
> Risking being a bit polemic here, I think that when we do
> containers, we have to view the kernel a little bit like a shared resource
> that is not accounted to anybody. It is easy to account things like tcp
> buffer, but who do you account page tables for shared pages to? Or pinned
> dentries for shared filesystems ?
I'd say that if filesystems (or page tables) are shared between
containers / cgroups, then it's fair to do first-touch accounting. But
if a filesystem is shared between multiple processes in just one
container / cgroup then it should definitely be charged to that cgroup
(which you get automatically with first-touch accounting).
It might be reasonable to also allow the sysadmin to request a more
expensive form of accounting (probably either charge-all or
equal-share), if the code to support that didn't interfere with the
performance of the normal first-touch charging mechanism, or
complicate the code too much.
On the subject of filesystems specifically, see Greg Thelen's proposal
for using bind mounts to account on a bind mount to a given cgroup -
that could apply to dentries, page tables and other kernel memory as
well as page cache.
> Good that it scares you, it should. OTOH, userspace being
> able to set parameters to it, has nothing scary at all. A daemon in
> userspace can detect that you need more kernel space memory , and
> then - according to a policy you abide to - write to a file allowing
> it more, or maybe not - according to that same policy. It is very
> far away from "userspace driven reclaim".
It can do that, but it's a bit messy when all userspace really wants
to do is say "limit the total to X GB".
> No, I don't necessarily feel that need. I just thought it was
> cleaner to have entities with different purposes in different
> cgroups. If moving it to the memory controller would help you in any
> way, I can just do it. 80 % of this work is independent of where a
> cgroup file lives.
My feeling is also that it's more appropriate for this to live in
memcg. While the ability to mount subsystems separately gives nice
flexibility, in the case of userspace versus kernel memory, I'm having
trouble envisaging a realistic situation where you'd want them mounted
on different hierarchies.
> - kernel_memory_hard_limit.
> - kernel_memory_soft_limit.
>
> tcp memory would be the one defined in /proc, except if it is
> greater than any of the limits. Instead of testing for memory
> allocation against kmem.tcp_allocated_memory, we'd test it against
> memcg.kmem_pinned_memory.
>
This is definitely an improvement, but I'd say it's not enough. I
think we should consider something like:
- a root cgroup file (memory.unified?) that controls whether memory
limits are unified or split.
- this file can only be modified when there are no memory cgroups
created (other than the root, which we shouldn't be charging, I think)
- the 'active' control determines whether (all) child cgroups will
have memory.{limit,usage}_in_bytes files, or
memory.{kernel,user}_{limit,usage}_in_bytes files
- kernel memory will be charged either against 'kernel' or 'total'
depending on the value of unified
- userspace memory will be charged either against 'user' or 'total'
That way the kernel doesn't force a unified or split decision on
anyone, with I think zero performance hit and not much extra code.
You could even take this a step further. The following is probably
straying into the realm of overly-flexible, but I'll throw it into the
discussion anyway:
- define counters for various types of memory (e.g. total, user,
kernel, network, tcp, pagetables, dentries, etc)
- document what kind of memory is potentially charged against each
counter. (e.g. TCP buffers would be potentially charged against 'tcp',
'network', 'kernel' and 'total')
- have a memory.counters root cgroup file that allows the user to
specify which of the available counters are active. (only writeable
when no child cgroups, to avoid inconsistencies caused by changes
while memory is charged)
- default memory.counters to 'total'
- when memory.counters is updated, the memcg code builds the set of
targets for each chargeable entity. (e.g. if you enabled 'network' and
'total', then we'd update the charge_tcp array to contain something
like { &network_counter, &total_counter, NULL })
- charging for an object (TCP allocation, pagecache page, pagetable,
dentry, etc) just involves (trying to) charge all the counters set up
in that object's array. Since these arrays will be immutable once
child cgroups are being charged, they should be fairly well predicted.
This would give complete flexibility to userspace on the policy for
charging and reporting without incurring performance overhead for
systems that didn't care about some particular counter. (And without
complicating the code too much, I think).
Paul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Sridhar Samudrala @ 2011-09-12 4:30 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Michael S. Tsirkin, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA920319.33DE1%roprabhu@cisco.com>
On 9/11/2011 6:18 AM, Roopa Prabhu wrote:
>
>
> On 9/11/11 2:44 AM, "Michael S. Tsirkin"<mst@redhat.com> wrote:
>
>>> AFAIK, though it might maintain a single filter table space in hw, hw does
>>> know which filter belongs to which VF. And the OS driver does not need to do
>>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>>> registered with a VF netdev are registered with the hw by the driver. And hw
>>> will filter and send only pkts that the VF has expressed interest in.
>>>
>>> No special filter partitioning in hw is required.
>>>
>>> Thanks,
>>> Roopa
>> Yes, but what I mean is, if the size of the single filter table
>> is limited, we need to decide how many addresses is
>> each guest allowed. If we let one guest ask for
>> as many as it wants, it can lock others out.
> Yes true. In these cases ie when the number of unicast addresses being
> registered is more than it can handle, The VF driver will put the VF in
> promiscuous mode (Or at least its supposed to do. I think all drivers do
> that).
>
What does putting VF in promiscuous mode mean? How can the NIC decide
which set
of mac addresses are passed to the VF? Does it mean VF sees all the
packets received
by the NIC including packets destined for other VFs/PF?
Thanks
Sridhar
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 3:38 UTC (permalink / raw)
To: Neil Horman; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110910130416.GA2005@neilslaptop.think-freely.org>
Thanks Neil. I did try with prink(). I do see entries getting aged out, but they are not getting deallocated. This seems to be happening because of "ref_cnt". When the route entries are added the ref_cnt is set to 1. Looks this is causing trouble clearing the entries completely. If I set the ref_cnt to 0, I can see it working. Now I'm trying to understand whether this is right. Please let me know if you have any thoughts on it.
----- Original Message -----
From: Neil Horman <nhorman@tuxdriver.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>; netdev <netdev@vger.kernel.org>
Sent: Saturday, September 10, 2011 6:04 AM
Subject: Re: Memory leak in ip_dst_cache
On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
>
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries. The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around. You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.
If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely. It shouldn't be too hard to do.
Neil
>
--
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
^ permalink raw reply
* [PATCH resend] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Wanlong Gao @ 2011-09-12 1:36 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, Gao feng, Gao feng, Eric Dumazet
In-Reply-To: <1315675150-3012-1-git-send-email-wanlong.gao@gmail.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
add new fib rule can cause BUG_ON happen
the reproduce shell is
ip rule add pref 38
ip rule add pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule del pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule add pref 38
then the BUG_ON will happen
del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/fib_rules.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..3231b46 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,8 +384,8 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
- BUG_ON(rtnl_dereference(r->ctarget) != NULL);
+ r->target == rule->pref &&
+ rtnl_dereference(r->ctarget) == NULL) {
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
--
1.7.6
^ permalink raw reply related
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-09-11 20:16 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd
In-Reply-To: <20110823131726.GA21092@electric-eye.fr.zoreil.com>
On Tuesday 23 August 2011 15:17:26 Francois Romieu wrote:
> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
>
> > Yes. There is enough data for me to reproduce the bug with the
> > exact same chipset.
>
> I can not generate a single rx error and the driver refuses to crash :o/
>
> Can you apply the patch below on top of 3.1.0-rc3 and see if it makes
> a difference ?
Sorry for the delay, I have had only two days for email in the last few weeks
and additionally kernel.org was and still is down.
Does it have to be 3.1.0-rc3 or is 3.0.1 ok as well? If so, I have another bad
news: 3.0.1 still crashes with this patch. It took me a lot longer to crash it
but eventually it did happen. Not sure why it took longer, I guess I didn't
generate enough throughput.
If you want me to use 3.1.0 then we'll have to wait until git.kernel.org is
back...
thanks,
Michael
> Thanks.
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 02339b3..c54ed17 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -5326,10 +5326,6 @@ static int rtl8169_rx_interrupt(struct net_device
> *dev, dev->stats.rx_length_errors++;
> if (status & RxCRC)
> dev->stats.rx_crc_errors++;
> - if (status & RxFOVF) {
> - rtl8169_schedule_work(dev, rtl8169_reset_task);
> - dev->stats.rx_fifo_errors++;
> - }
> rtl8169_mark_to_asic(desc, rx_buf_sz);
> } else {
> struct sk_buff *skb;
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 19:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA920319.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> >>
> >> AFAIK, though it might maintain a single filter table space in hw, hw does
> >> know which filter belongs to which VF. And the OS driver does not need to do
> >> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> >> registered with a VF netdev are registered with the hw by the driver. And hw
> >> will filter and send only pkts that the VF has expressed interest in.
> >>
> >> No special filter partitioning in hw is required.
> >>
> >> Thanks,
> >> Roopa
> >
> > Yes, but what I mean is, if the size of the single filter table
> > is limited, we need to decide how many addresses is
> > each guest allowed. If we let one guest ask for
> > as many as it wants, it can lock others out.
>
> Yes true. In these cases ie when the number of unicast addresses being
> registered is more than it can handle, The VF driver will put the VF in
> promiscuous mode (Or at least its supposed to do. I think all drivers do
> that).
>
>
> Thanks,
> Roopa
Right, so that works at least but likely performs worse
than a hardware filter. So we better allocate it in
some fair way, as a minimum. Maybe a way for
the admin to control that allocation is useful.
--
MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 18:52 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <CA92031A.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:02AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
> >>
> >>
> >>
> >> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
> >>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
> >>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
> >>>>>> receive traffic that he requested for
> >>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
> >>>>>> physical nic will see all other guest traffic
> >>>>>> but the filtering at guest virtio-nic
> >>>>>
> >>>>> I don't think guests currently filter anything.
> >>>>>
> >>>> I was referring to Qemu-kvm virtio-net in
> >>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
> >>>> guest OS is interested. It uses the filter table that I am passing to
> >>>> macvtap in this patch.
> >>>
> >>> This happens after userspace thread gets woken up and data
> >>> is copied there. So relying on filtering at that level is
> >>> going to be very inefficient on a system with
> >>> multiple active guests. Further, and for that reason, vhost-net
> >>> doesn't do filtering at all, relying on the backends
> >>> to pass it correct packets.
> >>
> >> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
> >> and for non-PASSTHRU when there is a single guest connected to a VF.
> >> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
> >> better than putting the VF in promiscuous mode.
> >> But to address the concern you mention above, in phase 2 when we have more
> >> than one guest sharing the VF,
> >
> > It's probably more interesting for a card without SRIOV support.
> >
> If its an SRIOV card I am assuming people likely using PASSTHRU mode.
> Non-SRIOV cards will use any of the non-PASSTHRU mode.
>
>
> >> we will have to add filter lookup in macvlan
> >> to filter pkts for each guest.
> >
> > Any chance to enable hardware filters for that?
> >
> NAFAIK. Am not sure how you would do it too. Its still a single device from
> where the host receives traffic from.
>
> Thanks,
> Roopa
VMDQ cards might let you program mac addresses for individula rings.
--
MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <20110911093832.GD27096@redhat.com>
On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>>
>>
>>
>> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
>>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
>>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
>>>>>> receive traffic that he requested for
>>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
>>>>>> physical nic will see all other guest traffic
>>>>>> but the filtering at guest virtio-nic
>>>>>
>>>>> I don't think guests currently filter anything.
>>>>>
>>>> I was referring to Qemu-kvm virtio-net in
>>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
>>>> guest OS is interested. It uses the filter table that I am passing to
>>>> macvtap in this patch.
>>>
>>> This happens after userspace thread gets woken up and data
>>> is copied there. So relying on filtering at that level is
>>> going to be very inefficient on a system with
>>> multiple active guests. Further, and for that reason, vhost-net
>>> doesn't do filtering at all, relying on the backends
>>> to pass it correct packets.
>>
>> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
>> and for non-PASSTHRU when there is a single guest connected to a VF.
>> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
>> better than putting the VF in promiscuous mode.
>> But to address the concern you mention above, in phase 2 when we have more
>> than one guest sharing the VF,
>
> It's probably more interesting for a card without SRIOV support.
>
If its an SRIOV card I am assuming people likely using PASSTHRU mode.
Non-SRIOV cards will use any of the non-PASSTHRU mode.
>> we will have to add filter lookup in macvlan
>> to filter pkts for each guest.
>
> Any chance to enable hardware filters for that?
>
NAFAIK. Am not sure how you would do it too. Its still a single device from
where the host receives traffic from.
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <20110911094449.GF27096@redhat.com>
On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> AFAIK, though it might maintain a single filter table space in hw, hw does
>> know which filter belongs to which VF. And the OS driver does not need to do
>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>> registered with a VF netdev are registered with the hw by the driver. And hw
>> will filter and send only pkts that the VF has expressed interest in.
>>
>> No special filter partitioning in hw is required.
>>
>> Thanks,
>> Roopa
>
> Yes, but what I mean is, if the size of the single filter table
> is limited, we need to decide how many addresses is
> each guest allowed. If we let one guest ask for
> as many as it wants, it can lock others out.
Yes true. In these cases ie when the number of unicast addresses being
registered is more than it can handle, The VF driver will put the VF in
promiscuous mode (Or at least its supposed to do. I think all drivers do
that).
Thanks,
Roopa
^ permalink raw reply
* Re: [PATCH] macmace: disable only the dma interrupt
From: Finn Thain @ 2011-09-11 10:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
In-Reply-To: <20110910.143046.520109083086760748.davem@davemloft.net>
On Sat, 10 Sep 2011, David Miller wrote:
> From: Finn Thain <fthain@telegraphics.com.au>
> Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)
>
> > Don't disable all interrupts, just disable the relevant one.
> >
> > Also move a couple of printk calls outside of local_irq_save/restore.
> >
> > Tested on a Quadra 660av.
> >
> > Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>
> Using disable_irq() is very expensive, and when done from an interrupt
> handler can deadlock especially on SMP (which I understand might not be
> relevant here).
>
> I really can't see why you'd do things this way, especially since
> interrupt handlers under Linux now unconditionally always run with cpu
> interrupts disabled.
I wasn't aware of this (I was under the impression that a higher priority
interrupt could be serviced). Please disregard this patch.
Finn
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 9:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA8ECF75.33BFF%roprabhu@cisco.com>
On Thu, Sep 08, 2011 at 08:00:53PM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/8/11 12:33 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
> >>>
> >>> I think the main usecase for passthru mode is to assign a SR-IOV VF to
> >>> a single guest.
> >>>
> >> Yes and for the passthru usecase this patch should be enough to enable
> >> filtering in hw (eventually like I indicated before I need to fix vlan
> >> filtering too).
> >
> > So with filtering in hw, and in sriov VF case, VFs
> > actually share a filtering table. How will that
> > be partitioned?
>
> AFAIK, though it might maintain a single filter table space in hw, hw does
> know which filter belongs to which VF. And the OS driver does not need to do
> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> registered with a VF netdev are registered with the hw by the driver. And hw
> will filter and send only pkts that the VF has expressed interest in.
>
> No special filter partitioning in hw is required.
>
> Thanks,
> Roopa
Yes, but what I mean is, if the size of the single filter table
is limited, we need to decide how many addresses is
each guest allowed. If we let one guest ask for
as many as it wants, it can lock others out.
--
MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 9:38 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <CA8F8DED.33CF5%roprabhu@cisco.com>
On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
> >>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
> >>>> - In macvlan passthru mode the single guest virtio-nic connected will
> >>>> receive traffic that he requested for
> >>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
> >>>> physical nic will see all other guest traffic
> >>>> but the filtering at guest virtio-nic
> >>>
> >>> I don't think guests currently filter anything.
> >>>
> >> I was referring to Qemu-kvm virtio-net in
> >> virtion_net_receive->receive_filter. I think It only passes pkts that the
> >> guest OS is interested. It uses the filter table that I am passing to
> >> macvtap in this patch.
> >
> > This happens after userspace thread gets woken up and data
> > is copied there. So relying on filtering at that level is
> > going to be very inefficient on a system with
> > multiple active guests. Further, and for that reason, vhost-net
> > doesn't do filtering at all, relying on the backends
> > to pass it correct packets.
>
> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
> and for non-PASSTHRU when there is a single guest connected to a VF.
> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
> better than putting the VF in promiscuous mode.
> But to address the concern you mention above, in phase 2 when we have more
> than one guest sharing the VF,
It's probably more interesting for a card without SRIOV support.
> we will have to add filter lookup in macvlan
> to filter pkts for each guest.
Any chance to enable hardware filters for that?
> This will need some performance tests too.
>
> Will start investigating the netlink interface comments for phase 1 first.
>
> Thanks!
> -Roopa
^ permalink raw reply
* Re: kernel.org extended outage - wait or use alternatives?
From: Eric Dumazet @ 2011-09-11 8:24 UTC (permalink / raw)
To: Jan Ceuleers; +Cc: netdev
In-Reply-To: <4E6C6BAA.3020701@computer.org>
Le dimanche 11 septembre 2011 à 10:04 +0200, Jan Ceuleers a écrit :
> David,
>
> I'm a mere observer of kernel development rather than an active
> participant in it. My observation is that networking development has all
> but come to a standstill while we wait for master.kernel.org to come back.
>
> Linus is now using a github.com account; any reason why the same could
> not apply to net and net-next, so that development can proceed?
>
As an active kernel developer, I would vote for being thankful for this
pause. Its always a good thing to relax and enjoy your time ;)
I actually lost my main development trees because of nasty disk
corruptions in 3.1-rc4, and wrong habit of not doing any backups... Oh
well...
More than a repository for net and net-next, we really want a working
netdev mailing list.
Anyway, everything is queued and you dont have to worry.
http://patchwork.ozlabs.org/project/netdev/list/
^ permalink raw reply
* kernel.org extended outage - wait or use alternatives?
From: Jan Ceuleers @ 2011-09-11 8:04 UTC (permalink / raw)
To: netdev
David,
I'm a mere observer of kernel development rather than an active
participant in it. My observation is that networking development has all
but come to a standstill while we wait for master.kernel.org to come back.
Linus is now using a github.com account; any reason why the same could
not apply to net and net-next, so that development can proceed?
Thanks, Jan
^ permalink raw reply
* Re: [PATCH] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Eric Dumazet @ 2011-09-11 7:12 UTC (permalink / raw)
To: Wanlong Gao; +Cc: linux-kernel, netdev, davem, omarapazanadi, Gao feng
In-Reply-To: <1315675150-3012-1-git-send-email-wanlong.gao@gmail.com>
Le dimanche 11 septembre 2011 à 01:19 +0800, Wanlong Gao a écrit :
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> add new fib rule can cause BUG_ON
> the reproduce shell is
>
> #ip rule add pref 38
> #ip rule add pref 38
> #ip rule add to 192.168.3.0/24 goto 38
> #ip rule del pref 38
> #ip rule add to 192.168.3.0/24 goto 38
> #ip rule add pref 38
>
> then the BUG_ON will happen
> add a var unresolved in struct fib_rule
> and use it to identify whether this rule is unresolved
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> include/net/fib_rules.h | 1 +
> net/core/fib_rules.c | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
> index 075f1e3..e4bae01 100644
> --- a/include/net/fib_rules.h
> +++ b/include/net/fib_rules.h
> @@ -19,6 +19,7 @@ struct fib_rule {
> u32 flags;
> u32 table;
> u8 action;
> + u8 unresolved;
> u32 target;
> struct fib_rule __rcu *ctarget;
> char iifname[IFNAMSIZ];
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index e7ab0c0..aa20560 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -384,9 +384,11 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
> */
> list_for_each_entry(r, &ops->rules_list, list) {
> if (r->action == FR_ACT_GOTO &&
> - r->target == rule->pref) {
> + r->target == rule->pref &&
> + r->unresolved) {
> BUG_ON(rtnl_dereference(r->ctarget) != NULL);
> rcu_assign_pointer(r->ctarget, rule);
> + r->unresolved = 0;
> if (--ops->unresolved_rules == 0)
> break;
> }
> @@ -488,6 +490,7 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
> list_for_each_entry(tmp, &ops->rules_list, list) {
> if (rtnl_dereference(tmp->ctarget) == rule) {
> rcu_assign_pointer(tmp->ctarget, NULL);
> + tmp->unresolved = 1;
> ops->unresolved_rules++;
> }
> }
Hmm, good catch, but you add 'unresolved' field but dont init it
correctly to 1 in all cases.
Following will break :
ip rule add pref 100
ip rule add to 192.168.3.0/24 goto 200
ip rule add pref 200
Normally, we should have
unresolved = (ctarget == NULL);
What about following patch instead ?
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..3231b46 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,8 +384,8 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
- BUG_ON(rtnl_dereference(r->ctarget) != NULL);
+ r->target == rule->pref &&
+ rtnl_dereference(r->ctarget) == NULL) {
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
^ permalink raw reply related
* Re: [PATCH] macmace: disable only the dma interrupt
From: David Miller @ 2011-09-10 18:30 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109110042210.5327@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)
> Don't disable all interrupts, just disable the relevant one.
>
> Also move a couple of printk calls outside of local_irq_save/restore.
>
> Tested on a Quadra 660av.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Using disable_irq() is very expensive, and when done from an interrupt
handler can deadlock especially on SMP (which I understand might not
be relevant here).
I really can't see why you'd do things this way, especially since
interrupt handlers under Linux now unconditionally always run with cpu
interrupts disabled.
^ permalink raw reply
* Re: [PATCH] mac_esp: remove redundant mutual exclusion
From: David Miller @ 2011-09-10 18:28 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109110038500.5327@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Sun, 11 Sep 2011 01:01:34 +1000 (EST)
> Mutual exclusion is redundant here because all the paths in the call graph
> leading to esp_driver_ops.send_dma_cmd() happen under spin_lock_irqsave/
> spin_lock_irqrestore. Remove it.
>
> Tested on a Mac Quadra 660av and a Mac LC 630.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
This patch should be CC:'d to linux-scsi not netdev
I understand how the networking maintainer is very responsive
and the SCSI maintainer generally takes forever, so your
Freudian slip will go unjudged :-)
^ permalink raw reply
* [PATCH] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Wanlong Gao @ 2011-09-10 17:19 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, eric.dumazet, omarapazanadi, Gao feng
From: Gao feng <gaofeng@cn.fujitsu.com>
add new fib rule can cause BUG_ON
the reproduce shell is
#ip rule add pref 38
#ip rule add pref 38
#ip rule add to 192.168.3.0/24 goto 38
#ip rule del pref 38
#ip rule add to 192.168.3.0/24 goto 38
#ip rule add pref 38
then the BUG_ON will happen
add a var unresolved in struct fib_rule
and use it to identify whether this rule is unresolved
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
include/net/fib_rules.h | 1 +
net/core/fib_rules.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 075f1e3..e4bae01 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -19,6 +19,7 @@ struct fib_rule {
u32 flags;
u32 table;
u8 action;
+ u8 unresolved;
u32 target;
struct fib_rule __rcu *ctarget;
char iifname[IFNAMSIZ];
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..aa20560 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,9 +384,11 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
+ r->target == rule->pref &&
+ r->unresolved) {
BUG_ON(rtnl_dereference(r->ctarget) != NULL);
rcu_assign_pointer(r->ctarget, rule);
+ r->unresolved = 0;
if (--ops->unresolved_rules == 0)
break;
}
@@ -488,6 +490,7 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
list_for_each_entry(tmp, &ops->rules_list, list) {
if (rtnl_dereference(tmp->ctarget) == rule) {
rcu_assign_pointer(tmp->ctarget, NULL);
+ tmp->unresolved = 1;
ops->unresolved_rules++;
}
}
--
1.7.6
^ permalink raw reply related
* [PATCH] macmace: disable only the dma interrupt
From: Finn Thain @ 2011-09-10 15:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
Don't disable all interrupts, just disable the relevant one.
Also move a couple of printk calls outside of local_irq_save/restore.
Tested on a Quadra 660av.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Index: linux-m68k/drivers/net/macmace.c
===================================================================
--- linux-m68k.orig/drivers/net/macmace.c 2011-08-28 00:33:33.000000000 +1000
+++ linux-m68k/drivers/net/macmace.c 2011-08-28 00:36:10.000000000 +1000
@@ -458,8 +458,9 @@ static int mace_xmit_start(struct sk_buf
local_irq_save(flags);
netif_stop_queue(dev);
if (!mp->tx_count) {
- printk(KERN_ERR "macmace: tx queue running but no free buffers.\n");
local_irq_restore(flags);
+ printk(KERN_ERR
+ "macmace: tx queue running but no free buffers.\n");
return NETDEV_TX_BUSY;
}
mp->tx_count--;
@@ -563,10 +564,8 @@ static irqreturn_t mace_interrupt(int ir
struct mace_data *mp = netdev_priv(dev);
volatile struct mace *mb = mp->mace;
int intr, fs;
- unsigned long flags;
- /* don't want the dma interrupt handler to fire */
- local_irq_save(flags);
+ disable_irq(mp->dma_intr);
intr = mb->ir; /* read interrupt register */
mace_handle_misc_intrs(dev, intr);
@@ -604,7 +603,7 @@ static irqreturn_t mace_interrupt(int ir
if (mp->tx_count)
netif_wake_queue(dev);
- local_irq_restore(flags);
+ enable_irq(mp->dma_intr);
return IRQ_HANDLED;
}
@@ -615,11 +614,12 @@ static void mace_tx_timeout(struct net_d
volatile struct mace *mb = mp->mace;
unsigned long flags;
+ printk(KERN_ERR "macmace: transmit timeout - resetting\n");
+
local_irq_save(flags);
/* turn off both tx and rx and reset the chip */
mb->maccc = 0;
- printk(KERN_ERR "macmace: transmit timeout - resetting\n");
mace_txdma_reset(dev);
mace_reset(dev);
^ permalink raw reply
* [PATCH] mac_esp: remove redundant mutual exclusion
From: Finn Thain @ 2011-09-10 15:01 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
Mutual exclusion is redundant here because all the paths in the call graph
leading to esp_driver_ops.send_dma_cmd() happen under spin_lock_irqsave/
spin_lock_irqrestore. Remove it.
Tested on a Mac Quadra 660av and a Mac LC 630.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Part of this patch relates to Geert's m68k generic hard irq conversion
work. Under genirq, the disable_irq() in mac_esp leads to deadlock. It
wasn't a problem before because the m68k disable_irq() implementation is
equivalent to genirq's disable_irq_nosync().
Index: linux-m68k/drivers/scsi/mac_esp.c
===================================================================
--- linux-m68k.orig/drivers/scsi/mac_esp.c 2011-08-28 00:33:13.000000000 +1000
+++ linux-m68k/drivers/scsi/mac_esp.c 2011-08-28 00:35:48.000000000 +1000
@@ -230,9 +230,6 @@ static void mac_esp_send_pdma_cmd(struct
u32 dma_count, int write, u8 cmd)
{
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
- unsigned long flags;
-
- local_irq_save(flags);
mep->error = 0;
@@ -270,8 +267,6 @@ static void mac_esp_send_pdma_cmd(struct
esp_count = n;
}
} while (esp_count);
-
- local_irq_restore(flags);
}
/*
@@ -353,8 +348,6 @@ static void mac_esp_send_pio_cmd(struct
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
u8 *fifo = esp->regs + ESP_FDATA * 16;
- disable_irq(esp->host->irq);
-
cmd &= ~ESP_CMD_DMA;
mep->error = 0;
@@ -431,8 +424,6 @@ static void mac_esp_send_pio_cmd(struct
scsi_esp_cmd(esp, ESP_CMD_TI);
}
}
-
- enable_irq(esp->host->irq);
}
static int mac_esp_irq_pending(struct esp *esp)
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Neil Horman @ 2011-09-10 13:04 UTC (permalink / raw)
To: Kumar S; +Cc: Eric Dumazet, netdev
In-Reply-To: <1315608825.98066.YahooMailNeo@web113914.mail.gq1.yahoo.com>
On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
>
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries. The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around. You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.
If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely. It shouldn't be too hard to do.
Neil
>
^ permalink raw reply
* skge: transmit queue 0 timed out
From: Bart Van Assche @ 2011-09-10 9:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAO+b5-p=9NXJrT1h6KQG9BpP=mDp8XjMZsCxsk=WkuBZ_KhtKA@mail.gmail.com>
Hello,
Anyone who can tell me whether I should worry about the kernel warning
shown below ? I've observed that warning for the first time with
3.1-rc5 and hadn't seen it yet with 3.1-rc4 or any older kernel.
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x24f/0x260()
Hardware name: P5Q DELUXE
NETDEV WATCHDOG: eth0 (skge): transmit queue 0 timed out
Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
af_packet rdma_ucm rdma_cm iw_cm ib_addr ib_ipoib ib_cm ib_sa
ib_uverbs ib_umad mlx4_ib ib_mad ib_core microcode
cpufreq_conservative cpufreq_userspaceq mperf dm_mod
snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sr_mod mlx4_core sg cdrom soundcore
i2c_i801 snd_page_alloc i2c_core pcspkr button uhci_hcd ehci_hcd sxt3
mbcache jbd fan ata_generic ata_piix pata_marvell ahci libahci libata
scsi_mod thermal processor thermal_sys hwmon
Pid: 6260, comm: wish Not tainted 3.1.0-rc4-scst-debug+ #2
Call Trace:
<IRQ> [<ffffffff8104564f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff81045746>] warn_slowpath_fmt+0x46/0x50
[<ffffffff813268df>] dev_watchdog+0x24f/0x260
[<ffffffff8105602a>] run_timer_softirq+0x19a/0x3f0
[<ffffffff81055f97>] ? run_timer_softirq+0x107/0x3f0
[<ffffffff81326690>] ? pfifo_fast_init+0xa0/0xa0
[<ffffffff8104cecd>] __do_softirq+0xcd/0x250
[<ffffffff813e5cec>] call_softirq+0x1c/0x30
[<ffffffff810043bd>] do_softirq+0x8d/0xc0
[<ffffffff8104d36e>] irq_exit+0xae/0xe0
[<ffffffff813e637e>] smp_apic_timer_interrupt+0x6e/0x99
[<ffffffff813e4570>] apic_timer_interrupt+0x70/0x80
<EOI> [<ffffffff813dbe0a>] ? retint_swapgs+0xe/0x13
---[ end trace fbbed52d2a66b808 ]---
Bart.
^ 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