* [PATCH -mmotm 28/30] build fix for skb_emergency_protocol
From: Xiaotian Feng @ 2010-07-13 10:22 UTC (permalink / raw)
To: linux-mm, linux-nfs, netdev
Cc: riel, cl, a.p.zijlstra, Xiaotian Feng, linux-kernel, lwang,
penberg, akpm, davem
In-Reply-To: <20100713101650.2835.15245.sendpatchset@danny.redhat>
>From 50d2e72527b3e821544cc97c4dd5b1e5a44b6659 Mon Sep 17 00:00:00 2001
From: Xiaotian Feng <dfeng@redhat.com>
Date: Tue, 13 Jul 2010 13:21:10 +0800
Subject: [PATCH 28/30] build fix for skb_emergency_protocol
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
---
net/core/dev.c | 48 ++++++++++++++++++++++++------------------------
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7169b9b..fd7f8ac 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2791,6 +2791,30 @@ int __skb_bond_should_drop(struct sk_buff *skb, struct net_device *master)
}
EXPORT_SYMBOL(__skb_bond_should_drop);
+/*
+ * Filter the protocols for which the reserves are adequate.
+ *
+ * Before adding a protocol make sure that it is either covered by the existing
+ * reserves, or add reserves covering the memory need of the new protocol's
+ * packet processing.
+ */
+static int skb_emergency_protocol(struct sk_buff *skb)
+{
+ if (skb_emergency(skb))
+ switch (skb->protocol) {
+ case __constant_htons(ETH_P_ARP):
+ case __constant_htons(ETH_P_IP):
+ case __constant_htons(ETH_P_IPV6):
+ case __constant_htons(ETH_P_8021Q):
+ break;
+
+ default:
+ return 0;
+ }
+
+ return 1;
+}
+
static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
@@ -2942,30 +2966,6 @@ out:
return ret;
}
-/*
- * Filter the protocols for which the reserves are adequate.
- *
- * Before adding a protocol make sure that it is either covered by the existing
- * reserves, or add reserves covering the memory need of the new protocol's
- * packet processing.
- */
-static int skb_emergency_protocol(struct sk_buff *skb)
-{
- if (skb_emergency(skb))
- switch (skb->protocol) {
- case __constant_htons(ETH_P_ARP):
- case __constant_htons(ETH_P_IP):
- case __constant_htons(ETH_P_IPV6):
- case __constant_htons(ETH_P_8021Q):
- break;
-
- default:
- return 0;
- }
-
- return 1;
-}
-
/**
* netif_receive_skb - process receive buffer from network
* @skb: buffer to process
--
1.7.1.1
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH -mmotm 29/30] fix null pointer deref in swap_entry_free
From: Xiaotian Feng @ 2010-07-13 10:22 UTC (permalink / raw)
To: linux-mm, linux-nfs, netdev
Cc: riel, cl, a.p.zijlstra, Xiaotian Feng, linux-kernel, lwang,
penberg, akpm, davem
In-Reply-To: <20100713101650.2835.15245.sendpatchset@danny.redhat>
>From ea7b13006f42f7dcadd1bfb874d5e525b4c259e3 Mon Sep 17 00:00:00 2001
From: Xiaotian Feng <dfeng@redhat.com>
Date: Tue, 13 Jul 2010 13:44:08 +0800
Subject: [PATCH 29/30] fix null pointer deref in swap_entry_free
Commit b3a27d uses p->bdev->bd_disk, this will lead a null pointer
deref with swap over nfs.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
---
mm/swapfile.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index d8a05e4..3eb53fc 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -577,7 +577,6 @@ static unsigned char swap_entry_free(struct swap_info_struct *p,
/* free if no reference */
if (!usage) {
- struct gendisk *disk = p->bdev->bd_disk;
if (offset < p->lowest_bit)
p->lowest_bit = offset;
if (offset > p->highest_bit)
@@ -587,9 +586,11 @@ static unsigned char swap_entry_free(struct swap_info_struct *p,
swap_list.next = p->type;
nr_swap_pages++;
p->inuse_pages--;
- if ((p->flags & SWP_BLKDEV) &&
- disk->fops->swap_slot_free_notify)
- disk->fops->swap_slot_free_notify(p->bdev, offset);
+ if (p->flags & SWP_BLKDEV) {
+ struct gendisk *disk = p->bdev->bd_disk;
+ if (disk->fops->swap_slot_free_notify)
+ disk->fops->swap_slot_free_notify(p->bdev, offset);
+ }
}
return usage;
--
1.7.1.1
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH -mmotm 30/30] fix mess up on swap with multi files from same nfs server
From: Xiaotian Feng @ 2010-07-13 10:22 UTC (permalink / raw)
To: linux-mm, linux-nfs, netdev
Cc: riel, cl, a.p.zijlstra, Xiaotian Feng, linux-kernel, lwang,
penberg, akpm, davem
In-Reply-To: <20100713101650.2835.15245.sendpatchset@danny.redhat>
>From fd03848cadf5719228f617b72039cc8302d892ef Mon Sep 17 00:00:00 2001
From: Xiaotian Feng <dfeng@redhat.com>
Date: Tue, 13 Jul 2010 14:00:02 +0800
Subject: [PATCH 30/30] fix mess up on swap with multi files from same nfs server
xs_swapper() will set xprt->swapper when swapon nfs files, unset xprt->swapper
when swapoff nfs files. This will lead a bug if we swapon multi files from
the same nfs server, they had the same xprt, then the reserved memory could
not be disconnected when we swapoff all files.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
---
include/linux/sunrpc/xprt.h | 4 ++--
net/sunrpc/xprtsock.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index ba2330d..bc49091 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -171,8 +171,8 @@ struct rpc_xprt {
unsigned int max_reqs; /* total slots */
unsigned long state; /* transport state */
unsigned char shutdown : 1, /* being shut down */
- resvport : 1, /* use a reserved port */
- swapper : 1; /* we're swapping over this
+ resvport : 1; /* use a reserved port */
+ unsigned int swapper; /* we're swapping over this
transport */
unsigned int bind_index; /* bind function index */
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 5c8b918..30bb8ce 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1662,11 +1662,11 @@ int xs_swapper(struct rpc_xprt *xprt, int enable)
*/
err = sk_adjust_memalloc(1, RPC_RESERVE_PAGES);
if (!err) {
- xprt->swapper = 1;
+ xprt->swapper++;
xs_set_memalloc(xprt);
}
} else if (xprt->swapper) {
- xprt->swapper = 0;
+ xprt->swapper--;
sk_clear_memalloc(transport->inet);
sk_adjust_memalloc(-1, -RPC_RESERVE_PAGES);
}
--
1.7.1.1
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Luciano Coelho @ 2010-07-13 10:23 UTC (permalink / raw)
To: ext Pablo Neira Ayuso
Cc: Changli Gao, Samuel Ortiz, Patrick McHardy, David S. Miller,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
In-Reply-To: <4C3C28EC.2000302@netfilter.org>
On Tue, 2010-07-13 at 10:50 +0200, ext Pablo Neira Ayuso wrote:
> On 13/07/10 08:18, Changli Gao wrote:
> > On Tue, Jul 13, 2010 at 8:11 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> >>
> >> The userspace notification Xtables target sends a netlink notification
> >> whenever a packet hits the target. Notifications have a label attribute
> >> for userspace to match it against a previously set rule. The rules also
> >> take a --all option to switch between sending a notification for all
> >> packets or for the first one only.
> >> Userspace can also send a netlink message to toggle this switch while the
> >> target is in place. This target uses the nefilter netlink framework.
> >>
> >> This target combined with various matches (quota, rateest, etc..) allows
> >> userspace to make decisions on interfaces handling. One could for example
> >> decide to switch between power saving modes depending on estimated rate
> >> thresholds.
> >>
> >
> > It much like the following iptables rules.
> >
> > iptables -N log_and_drop
> > iptables -A log_and_drop -j NFLOG --nflog-group 1 --nflog-prefix "log_and_drop"
> > iptables -A log_and_drop -j DROP
> >
> > ...
> > iptables ... -m quota --quota-bytes 20000 -j log_and_drop
> > ...
>
> Indeed, this looks to me like something that you can do with NFLOG and
> some combination of matches.
Is it possible to have the NFLOG send only one notification to the
userspace? In the example above, once the quota exceeds, the userspace
will be notified of every packet arriving, won't it? That would cause
unnecessary processing in the userspace.
The userspace could remove the rule when it gets the first notification
and only add it again when it needs to get the information again (as a
"toggle" functionality), but I think that would take too long and there
would be several packets going through before the rule could be removed.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH -mmotm 12/30] selinux: tag avc cache alloc as non-critical
From: Mitchell Erblich @ 2010-07-13 10:55 UTC (permalink / raw)
To: Xiaotian Feng
Cc: linux-mm, linux-nfs, netdev, riel, cl, a.p.zijlstra, linux-kernel,
lwang, penberg, akpm, davem
In-Reply-To: <20100713101906.2835.83443.sendpatchset@danny.redhat>
On Jul 13, 2010, at 3:19 AM, Xiaotian Feng wrote:
> From 6c3a91091b2910c23908a9f9953efcf3df14e522 Mon Sep 17 00:00:00 2001
> From: Xiaotian Feng <dfeng@redhat.com>
> Date: Tue, 13 Jul 2010 11:02:41 +0800
> Subject: [PATCH 12/30] selinux: tag avc cache alloc as non-critical
>
> Failing to allocate a cache entry will only harm performance not correctness.
> Do not consume valuable reserve pages for something like that.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
> ---
> security/selinux/avc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index 3662b0f..9029395 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -284,7 +284,7 @@ static struct avc_node *avc_alloc_node(void)
> {
> struct avc_node *node;
>
> - node = kmem_cache_zalloc(avc_node_cachep, GFP_ATOMIC);
> + node = kmem_cache_zalloc(avc_node_cachep, GFP_ATOMIC|__GFP_NOMEMALLOC);
> if (!node)
> goto out;
>
> --
> 1.7.1.1
>
Why not just replace GFP_ATOMIC with GFP_NOWAIT?
This would NOT consume the valuable last pages.
Mitchell Erblich
> --
> 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
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-13 11:09 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Oleg Nesterov, Peter Zijlstra, Tejun Heo, Ingo Molnar, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <4C3C0EBC.40305@us.ibm.com>
On Mon, Jul 12, 2010 at 11:59:08PM -0700, Sridhar Samudrala wrote:
> On 7/4/2010 2:00 AM, Michael S. Tsirkin wrote:
> >On Fri, Jul 02, 2010 at 11:06:37PM +0200, Oleg Nesterov wrote:
> >>On 07/02, Peter Zijlstra wrote:
> >>>On Fri, 2010-07-02 at 11:01 -0700, Sridhar Samudrala wrote:
> >>>> Does it (Tejun's kthread_clone() patch) also inherit the
> >>>>cgroup of the caller?
> >>>Of course, its a simple do_fork() which inherits everything just as you
> >>>would expect from a similar sys_clone()/sys_fork() call.
> >>Yes. And I'm afraid it can inherit more than we want. IIUC, this is called
> >>from ioctl(), right?
> >>
> >>Then the new thread becomes the natural child of the caller, and it shares
> >>->mm with the parent. And files, dup_fd() without CLONE_FS.
> >>
> >>Signals. Say, if you send SIGKILL to this new thread, it can't sleep in
> >>TASK_INTERRUPTIBLE or KILLABLE after that. And this SIGKILL can be sent
> >>just because the parent gets SIGQUIT or abother coredumpable signal.
> >>Or the new thread can recieve SIGSTOP via ^Z.
> >>
> >>Perhaps this is OK, I do not know. Just to remind that kernel_thread()
> >>is merely clone(CLONE_VM).
> >>
> >>Oleg.
> >
> >Right. Doing this might break things like flush. The signal and exit
> >behaviour needs to be examined carefully. I am also unsure whether
> >using such threads might be more expensive than inheriting kthreadd.
> >
> Should we just leave it to the userspace to set the cgroup/cpumask
> after qemu starts the guest and
> the vhost threads?
>
> Thanks
> Sridhar
Yes but we can't trust userspace to do this. It's important
to do it on thread creation: if we don't, malicious userspace
can create large amount of work exceeding the cgroup limits.
And the same applies so the affinity: if the qemu process
is limited to a set of CPUs, it's important to make
the kernel thread that does work our behalf limited to the same
set of CPUs.
This is not unique to vhost, it's just that virt scenarious are affected
by this more: people seem to run untrusted applications and expect the
damage to be contained.
--
MST
^ permalink raw reply
* [PATCH] eth16i: fix memory leak
From: Kulikov Vasiliy @ 2010-07-13 11:22 UTC (permalink / raw)
To: kernel-janitors
Cc: Mika Kuoppala, David S. Miller, Stephen Hemminger, Eric Dumazet,
Tejun Heo, Jiri Pirko, netdev
Free allocated netdev if no probe is expected.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/eth16i.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/eth16i.c b/drivers/net/eth16i.c
index 874973f..2bdd394 100644
--- a/drivers/net/eth16i.c
+++ b/drivers/net/eth16i.c
@@ -1442,8 +1442,10 @@ int __init init_module(void)
dev->if_port = eth16i_parse_mediatype(mediatype[this_dev]);
if(io[this_dev] == 0) {
- if(this_dev != 0) /* Only autoprobe 1st one */
+ if (this_dev != 0) { /* Only autoprobe 1st one */
+ free_netdev(def);
break;
+ }
printk(KERN_NOTICE "eth16i.c: Presently autoprobing (not recommended) for a single card.\n");
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] wd: fix memory leak
From: Kulikov Vasiliy @ 2010-07-13 11:23 UTC (permalink / raw)
To: kernel-janitors; +Cc: David S. Miller, Joe Perches, netdev
Unmap mapped IO in wd_probe1() if register_netdev() failed.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/wd.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wd.c b/drivers/net/wd.c
index 746a5ee..eb72c67 100644
--- a/drivers/net/wd.c
+++ b/drivers/net/wd.c
@@ -358,8 +358,10 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr)
#endif
err = register_netdev(dev);
- if (err)
+ if (err) {
free_irq(dev->irq, dev);
+ iounmap(ei_status.mem);
+ }
return err;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] wireless: airo: delete netdev from list after it is freed
From: Kulikov Vasiliy @ 2010-07-13 11:23 UTC (permalink / raw)
To: kernel-janitors
Cc: John W. Linville, David S. Miller, Matthieu CASTET,
Stanislaw Gruszka, Roel Kluin, linux-wireless, netdev
We must call del_airo_dev() before free_netdev() since we call
add_airo_dev() exactly after alloc_netdev().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/wireless/airo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 6b605df..cce2f8f 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -2931,8 +2931,8 @@ err_out_res:
release_region( dev->base_addr, 64 );
err_out_nets:
airo_networks_free(ai);
- del_airo_dev(ai);
err_out_free:
+ del_airo_dev(ai);
free_netdev(dev);
return NULL;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH NEXT 1/1] netxen: fix for kdump
From: Amit Kumar Salecha @ 2010-07-13 11:33 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
When the crash kernel is loaded after crash, the device is in unknown state.
So reset the device contexts prior to its creation in case of kdump,
depending upon kernel parameter reset_devices.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/netxen/netxen_nic_ctx.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_ctx.c b/drivers/net/netxen/netxen_nic_ctx.c
index 3a41b6a..1261212 100644
--- a/drivers/net/netxen/netxen_nic_ctx.c
+++ b/drivers/net/netxen/netxen_nic_ctx.c
@@ -255,6 +255,19 @@ out_free_rq:
}
static void
+nx_fw_cmd_reset_ctx(struct netxen_adapter *adapter)
+{
+
+ netxen_issue_cmd(adapter, adapter->ahw.pci_func, NXHAL_VERSION,
+ adapter->ahw.pci_func, NX_DESTROY_CTX_RESET, 0,
+ NX_CDRP_CMD_DESTROY_RX_CTX);
+
+ netxen_issue_cmd(adapter, adapter->ahw.pci_func, NXHAL_VERSION,
+ adapter->ahw.pci_func, NX_DESTROY_CTX_RESET, 0,
+ NX_CDRP_CMD_DESTROY_TX_CTX);
+}
+
+static void
nx_fw_cmd_destroy_rx_ctx(struct netxen_adapter *adapter)
{
struct netxen_recv_context *recv_ctx = &adapter->recv_ctx;
@@ -685,7 +698,8 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
if (!NX_IS_REVISION_P2(adapter->ahw.revision_id)) {
if (test_and_set_bit(__NX_FW_ATTACHED, &adapter->state))
goto done;
-
+ if (reset_devices)
+ nx_fw_cmd_reset_ctx(adapter);
err = nx_fw_cmd_create_rx_ctx(adapter);
if (err)
goto err_out_free;
--
1.6.0.2
^ permalink raw reply related
* RE: Splice status
From: Ofer Heifetz @ 2010-07-13 11:41 UTC (permalink / raw)
To: Changli Gao, Eric Dumazet; +Cc: Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <AANLkTinRnDwMOS5NrmzKqYZpczG4nfHSvKA9Gw-_UUzO@mail.gmail.com>
Hi,
I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
iometer using 2G file (file is created before test)
Splice write cpu% iow%
-----------------------
No 58 98 0
Yes 14 100 48
iozone using 2G file (file created during test)
Splice write cpu% iow% re-write cpu% iow%
-------------------------------------------
No 35 85 4 58.2 70 0
Yes 33 85 4 15.7 100 58
Any clue why splice introduces a high iowait?
I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
-Ofer
-----Original Message-----
From: Changli Gao [mailto:xiaosuo@gmail.com]
Sent: Sunday, July 11, 2010 4:09 PM
To: Eric Dumazet
Cc: Jens Axboe; Ofer Heifetz; netdev@vger.kernel.org
Subject: Re: Splice status
On Tue, Jul 6, 2010 at 11:56 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 06 juillet 2010 à 10:01 +0800, Changli Gao a écrit :
>>
>> If we don't drain the pipe before calling splice(2), the data spliced
>> from pipe maybe not be what we expect. Then data corruption occurs.
>>
>
> This is not true. A pipe is a pipe is a buffer. You dont need it to be
> empty when using it. Nowhere in documentation its stated.
Do you mean splice(2) empties the pipe buffer before using it as an
output buffer? If not, the pipe draining is needed to avoid data
corruption.
>
> However, a single skb can fill a pipe, even if "its empty"
>
Yea. Because tcp_splice_read() doesn't know if the __tcp_splice_read
returns due to pipe fulling.
>
>> >
>> > splice(sock, pipe) can block if caller dont use appropriate "non
>> > blocking pipe' splice() mode, even if pipe is empty before a splice()
>> > call.
>>
>> I don't think it is expected. The code of sys_recvfile is much like
>> the sendfile(2) implementation in kernel. If sys_recvfile may block
>> without non_block flag, sendfile(2) may block too.
>
> Then it would be a bug. You might fix it easily.
It seems reasonable. I'll fix it.
>
> Using splice() correctly (ie, not blocking on sock->pipe) should work
> too.
>
> Again, you can block on splice(sock, pipe), iff you have a second thread
> doing the opposite (pipe->file) in parallel to unblock you. But samba
> recvfile algo is using a single thread.
>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] eth16i: fix memory leak
From: Dan Carpenter @ 2010-07-13 11:43 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: kernel-janitors, Mika Kuoppala, David S. Miller,
Stephen Hemminger, Eric Dumazet, Tejun Heo, Jiri Pirko, netdev
In-Reply-To: <1279020138-9398-1-git-send-email-segooon@gmail.com>
On Tue, Jul 13, 2010 at 03:22:18PM +0400, Kulikov Vasiliy wrote:
> Free allocated netdev if no probe is expected.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
> ---
> drivers/net/eth16i.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/eth16i.c b/drivers/net/eth16i.c
> index 874973f..2bdd394 100644
> --- a/drivers/net/eth16i.c
> +++ b/drivers/net/eth16i.c
> @@ -1442,8 +1442,10 @@ int __init init_module(void)
> dev->if_port = eth16i_parse_mediatype(mediatype[this_dev]);
>
> if(io[this_dev] == 0) {
> - if(this_dev != 0) /* Only autoprobe 1st one */
> + if (this_dev != 0) { /* Only autoprobe 1st one */
> + free_netdev(def);
^^^
free_netdev(dev);
regards,
dan carpenter
> break;
> + }
>
> printk(KERN_NOTICE "eth16i.c: Presently autoprobing (not recommended) for a single card.\n");
> }
> --
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Jan Engelhardt @ 2010-07-13 11:49 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Pablo Neira Ayuso, Changli Gao, Samuel Ortiz, Patrick McHardy,
David S. Miller, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
In-Reply-To: <1279016596.12673.11.camel@chilepepper>
On Tuesday 2010-07-13 12:23, Luciano Coelho wrote:
>>
>> Indeed, this looks to me like something that you can do with NFLOG and
>> some combination of matches.
>
>Is it possible to have the NFLOG send only one notification to the
>userspace? In the example above, once the quota exceeds, the userspace
>will be notified of every packet arriving, won't it? That would cause
>unnecessary processing in the userspace.
>
>The userspace could remove the rule when it gets the first notification
>and only add it again when it needs to get the information again (as a
>"toggle" functionality), but I think that would take too long and there
>would be several packets going through before the rule could be removed.
With xt_condition that should not be a problem
(-A INPUT -m condition --name ruleXYZ -j NFLOG..)
This is settable through procfs.
^ permalink raw reply
* Re: IPVS scheduler algorithms (was: [PATCH] ipvs: Kconfig cleanup)
From: Simon Horman @ 2010-07-13 12:29 UTC (permalink / raw)
To: Ismael Luque Valencia
Cc: Patrick McHardy, Michal Marek, lvs-devel, netdev,
Julian Anastasov, Wensong Zhang, linux-kernel
In-Reply-To: <AANLkTim3FfgxTzQ36YYYA8QG605oNW3skHZlSLKAZcjl@mail.gmail.com>
On Sun, Jul 11, 2010 at 07:15:21PM -0500, Ismael Luque Valencia wrote:
> Hi my name is Ismael, I am doing a paper about lvs algorithms but I dont
> undernstand two of them Locality-Based Least-Connection and Locality-Based
> Least-Connection with Replication
> Someone, who can explain me that algorithms please
> If it is in Spanish will better because my English is not good
Hi,
Firstly, please don't reply to emails unless you are actually
replying to the topic at hand. Instead just compose a fresh
message to the people/lists that you want to address.
This helps keep threads in mail-readers that support them sane.
In any case this question would be better sent to the lvs-users list.
But to your question.
These schedulers are described briefly in the ipvsadm(8) man page
and in pseudo code in the source files (ip_vs_lblc.c and ip_vs_lblcr.c)
in the Linux kernel tree. And there is some discussion in the howto
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#DH
The way that I think of these schedulers is as enhanced versions of wlc
designed for use with transparent proxies. That is situations where
there will be a lot of destination addresses.
lblc works by keeping a cache that associates destination addresses with
a real server. This allows accesses, potentially from different end-users,
to be sent to the same real-server. As this is designed to be used
with proxies, this means the request will be sent to a proxy that may
have already retrieved the result.
lblcr is similar, but instead of one real-server per destination, it
allows for multiple real-servers per destination.
^ permalink raw reply
* Re: Splice status
From: Changli Gao @ 2010-07-13 12:32 UTC (permalink / raw)
To: Ofer Heifetz; +Cc: Eric Dumazet, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <EE71107DF0D1F24FA2D95041E64AB9E8ED254E7B66@IL-MB01.marvell.com>
On Tue, Jul 13, 2010 at 7:41 PM, Ofer Heifetz <oferh@marvell.com> wrote:
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
> -Ofer
>
What does the column write means? And what do you mean by saying
re-write? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-13 12:42 UTC (permalink / raw)
To: Changli Gao; +Cc: Eric Dumazet, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <AANLkTimRXMivugXHJswrT5FA93PIjSjU-RneFKs1bkLL@mail.gmail.com>
Write and re-write numbers are in MBps.
Iozone performs re-write meaning reads a chunk of data and writes it back, so basically the performance for this operation should be quiet high since kernel caches usage.
I forgot to mention that I used EXT4 fs.
-Ofer
-----Original Message-----
From: Changli Gao [mailto:xiaosuo@gmail.com]
Sent: Tuesday, July 13, 2010 3:32 PM
To: Ofer Heifetz
Cc: Eric Dumazet; Jens Axboe; netdev@vger.kernel.org
Subject: Re: Splice status
On Tue, Jul 13, 2010 at 7:41 PM, Ofer Heifetz <oferh@marvell.com> wrote:
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
> -Ofer
>
What does the column write means? And what do you mean by saying
re-write? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH -mmotm 00/30] [RFC] swap over nfs -v21
From: Américo Wang @ 2010-07-13 12:53 UTC (permalink / raw)
To: Xiaotian Feng
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, riel-H+wXaHxf7aLQT0dZR+AlfA,
cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, lwang-H+wXaHxf7aLQT0dZR+AlfA,
penberg-bbCR+/B0CizivPeTLB3BmA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20100713101650.2835.15245.sendpatchset-bd3XojVv5Xrm7B5McmCzzQ@public.gmane.org>
On Tue, Jul 13, 2010 at 6:16 PM, Xiaotian Feng <dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
> Here's the latest version of swap over NFS series since -v20 last October. We decide to push
> this feature as it is useful for NAS or virt environment.
>
> The patches are against the mmotm-2010-07-01. We can split the patchset into following parts:
>
> Patch 1 - 12: provides a generic reserve framework. This framework
> could also be used to get rid of some of the __GFP_NOFAIL users.
>
> Patch 13 - 15: Provide some generic network infrastructure needed later on.
>
> Patch 16 - 21: reserve a little pool to act as a receive buffer, this allows us to
> inspect packets before tossing them.
>
> Patch 22 - 23: Generic vm infrastructure to handle swapping to a filesystem instead of a block
> device.
>
> Patch 24 - 27: convert NFS to make use of the new network and vm infrastructure to
> provide swap over NFS.
>
> Patch 28 - 30: minor bug fixing with latest -mmotm.
>
> [some history]
> v19: http://lwn.net/Articles/301915/
> v20: http://lwn.net/Articles/355350/
>
> Changes since v20:
> - rebased to mmotm-2010-07-01
> - dropped the null pointer deref patch for the root cause is wrong SWP_FILE enum
> - some minor build fixes
> - fix a null pointer deref with mmotm-2010-07-01
> - fix a bug when swap with multi files on the same nfs server
Please use the "From:" line correctly, as stated in
Documentation/SubmittingPatches:
The "from" line must be the very first line in the message body,
and has the form:
From: Original Author <author-hcDgGtZH8xNBDgjK7y7TUQ@public.gmane.org>
The "from" line specifies who will be credited as the author of the
patch in the permanent changelog. If the "from" line is missing,
then the "From:" line from the email header will be used to determine
the patch author in the changelog.
I think you are using git format-patch to generate those patches, please supply
--author=<author> to git commit when you commit them to your local
tree. (or git am
if the patches you received already had the correct From: line.)
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Samuel Ortiz @ 2010-07-13 13:19 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Patrick McHardy, David S. Miller, netdev, netfilter-devel,
Luciano Coelho
In-Reply-To: <alpine.LSU.2.01.1007130751360.19472@obet.zrqbmnf.qr>
Hi Jan,
On Tue, Jul 13, 2010 at 07:56:31AM +0200, Jan Engelhardt wrote:
>
> On Tuesday 2010-07-13 02:11, Samuel Ortiz wrote:
> >
> >The userspace notification Xtables target sends a netlink notification
> >whenever a packet hits the target. Notifications have a label attribute
> >for userspace to match it against a previously set rule. The rules also
> >take a --all option to switch between sending a notification for all
> >packets or for the first one only.
> >Userspace can also send a netlink message to toggle this switch while the
> >target is in place. This target uses the nefilter netlink framework.
>
> Would it not make sense to modify that module?
> Sounds an awful lot like NFQUEUE without passing the payload :)
yes, except for the payload, the missing "send one" packet toggle, and the
verdict we'd have to send back, it's almost identical ;)
What I'm trying to achieve with this target is a simple way to send a
userspace notification to userspace, without having to define a complex set of
rules, matches and having to pass some initial netlink message to set the
target properly (to avoid the payload passing in the NFLOG case).
> >+++ b/net/netfilter/xt_NFNOTIF.c
> >+struct nfnotif_tg {
> >+ struct list_head entry;
> >+ struct work_struct work;
> >+
> >+ char *label;
> >+ __u8 all_packets;
> >+ struct net *net;
> >+
> >+ __u8 send_notif;
> >+
> >+ unsigned int refcnt;
> >+};
>
> Has unnecessary padding holes.
Right, I will send a v2 later today.
Thanks for your comments and review.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [patch] net/sched: potential data corruption
From: Dan Carpenter @ 2010-07-13 13:21 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David S. Miller, Stephen Hemminger, netdev, kernel-janitors,
matthew
The reset_policy() does:
memset(d->tcfd_defdata, 0, SIMP_MAX_DATA);
strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
In the original code, the size of d->tcfd_defdata wasn't fixed and if
strlen(defdata) was less than 31, reset_policy() would cause memory
corruption.
Please Note: The original alloc_defdata() assumes defdata is 32
characters and a NUL terminator while reset_policy() assumes defdata is
31 characters and a NUL. This patch updates alloc_defdata() to match
reset_policy() (ie a shorter string). I'm not very familiar with this
code so please review carefully.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index 1b4bc69..4a1d640 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -73,10 +73,10 @@ static int tcf_simp_release(struct tcf_defact *d, int bind)
static int alloc_defdata(struct tcf_defact *d, char *defdata)
{
- d->tcfd_defdata = kstrndup(defdata, SIMP_MAX_DATA, GFP_KERNEL);
+ d->tcfd_defdata = kzalloc(SIMP_MAX_DATA, GFP_KERNEL);
if (unlikely(!d->tcfd_defdata))
return -ENOMEM;
-
+ strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
return 0;
}
^ permalink raw reply related
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Luciano Coelho @ 2010-07-13 13:24 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Pablo Neira Ayuso, Changli Gao, Samuel Ortiz, Patrick McHardy,
David S. Miller, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
In-Reply-To: <alpine.LSU.2.01.1007131349120.778@obet.zrqbmnf.qr>
On Tue, 2010-07-13 at 13:49 +0200, ext Jan Engelhardt wrote:
> On Tuesday 2010-07-13 12:23, Luciano Coelho wrote:
> >>
> >> Indeed, this looks to me like something that you can do with NFLOG and
> >> some combination of matches.
> >
> >Is it possible to have the NFLOG send only one notification to the
> >userspace? In the example above, once the quota exceeds, the userspace
> >will be notified of every packet arriving, won't it? That would cause
> >unnecessary processing in the userspace.
> >
> >The userspace could remove the rule when it gets the first notification
> >and only add it again when it needs to get the information again (as a
> >"toggle" functionality), but I think that would take too long and there
> >would be several packets going through before the rule could be removed.
>
> With xt_condition that should not be a problem
> (-A INPUT -m condition --name ruleXYZ -j NFLOG..)
> This is settable through procfs.
Right. I didn't know about the condition match, because I can't see it
either on net-next-2.6 nor on nf-next-2.6. I found your patch in the
netfilter-devel archives, though. Any idea when it will be applied?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Samuel Ortiz @ 2010-07-13 13:28 UTC (permalink / raw)
To: Changli Gao
Cc: Patrick McHardy, David S. Miller, netdev, netfilter-devel,
Luciano Coelho
In-Reply-To: <AANLkTil2EgQbzUqYNHAYpIWJvyyE6AWq1TpvxrqVsD7k@mail.gmail.com>
On Tue, Jul 13, 2010 at 02:18:26PM +0800, Changli Gao wrote:
> On Tue, Jul 13, 2010 at 8:11 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> >
> > The userspace notification Xtables target sends a netlink notification
> > whenever a packet hits the target. Notifications have a label attribute
> > for userspace to match it against a previously set rule. The rules also
> > take a --all option to switch between sending a notification for all
> > packets or for the first one only.
> > Userspace can also send a netlink message to toggle this switch while the
> > target is in place. This target uses the nefilter netlink framework.
> >
> > This target combined with various matches (quota, rateest, etc..) allows
> > userspace to make decisions on interfaces handling. One could for example
> > decide to switch between power saving modes depending on estimated rate
> > thresholds.
> >
>
> It much like the following iptables rules.
>
> iptables -N log_and_drop
> iptables -A log_and_drop -j NFLOG --nflog-group 1 --nflog-prefix "log_and_drop"
> iptables -A log_and_drop -j DROP
>
> ...
> iptables ... -m quota --quota-bytes 20000 -j log_and_drop
> ...
We'd still be missing the possibility of having only the first packet logged,
and we'd have to also send an initial netlink message to switch the copy_mode
to COPY_NONE. We're not interested in the actual packet, but just by the match
hit.
I know it's not big deal after all, I'm just trying to have one simple target
for that simple task of notifying userspace of a match hit.
> > +static unsigned int nfnotif_tg_target(struct sk_buff *skb,
> > + const struct xt_action_param *par)
> > +{
> > + const struct nfnotif_tg_info *info = par->targinfo;
> > +
> > + BUG_ON(!info->notif);
> > +
> > + if (!info->notif->send_notif)
> > + return XT_CONTINUE;
> > +
> > + pr_debug("Sending notification for %s\n", info->label);
> > +
> > + schedule_work(&info->notif->work);
> > +
>
> Why do you use another kernel activity: kernel thread? netlink
> messages can be sent in atomic context.
That's right, I should have used the ATOMIC gfp flags from my sending routine.
I'll fix that with my next revision of the patch.
Thanks for the review.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* High process latencies due to MPC5200 FEC hard- soft-irq processing
From: Wolfgang Grandegger @ 2010-07-13 13:29 UTC (permalink / raw)
To: Netdev; +Cc: linuxppc-dev@ozlabs.org, LKML
Hello,
we realized, that multiple ping floods (ping -f) can cause very large
high-priority process latencies (up to a many seconds) on a MPC5200
PowerPC system with FEC NAPI support. The latencies are measured with
# cyclictest -p 80 -n
The problem is that processing of the ICMP pakets in the Hard-Irq and
Soft-IRQ context can last for a long time without returning to the
scheduler. Reducing MAX_SOFTIRQ_RESTART from 10 to 2 helps - the latency
goes down to 35 ms with 2 "ping -f" - but it's not a configurable
parameter, even if it somehow depends on the CPU power. And using the
-rt patches seems overkill to me. Any other ideas or comments on how to
get rid of such high process latencies?
Wolfgang.
^ permalink raw reply
* Re: [PATCH] tc35815: fix iomap leak
From: Atsushi Nemoto @ 2010-07-13 13:14 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, davem, jpirko, eric.dumazet, adobriyan, netdev
In-Reply-To: <1278756199-4636-1-git-send-email-segooon@gmail.com>
On Sat, 10 Jul 2010 14:03:18 +0400, Kulikov Vasiliy <segooon@gmail.com> wrote:
> If tc35815_init_one() fails we must unmap mapped regions.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
> ---
> drivers/net/tc35815.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
No, pcim_xxx APIs are _managed_ interfaces. These resources are
released automatically. Actually currently nobody in kernel call
pcim_iounmap_regions() now.
And _if_ there is any reason to call pcim_iounmap_regions()
explicitly, it should be called in tc35815_remove_one() too.
So, NAK.
---
Atsushi Nemoto
^ permalink raw reply
* Re: Splice status
From: Changli Gao @ 2010-07-13 13:58 UTC (permalink / raw)
To: Ofer Heifetz; +Cc: Eric Dumazet, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <EE71107DF0D1F24FA2D95041E64AB9E8ED254E7BAB@IL-MB01.marvell.com>
On Tue, Jul 13, 2010 at 8:42 PM, Ofer Heifetz <oferh@marvell.com> wrote:
> Write and re-write numbers are in MBps.
> Iozone performs re-write meaning reads a chunk of data and writes it back, so basically the performance for this operation should be quiet high since kernel caches usage.
>
> I forgot to mention that I used EXT4 fs.
Maybe it is caused by this line in generic_file_splice_write():
balance_dirty_pages_ratelimited_nr(mapping, nr_pages);
Please try to test it again without this line.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* RE: Splice status
From: Eric Dumazet @ 2010-07-13 14:11 UTC (permalink / raw)
To: Ofer Heifetz; +Cc: Changli Gao, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <EE71107DF0D1F24FA2D95041E64AB9E8ED254E7B66@IL-MB01.marvell.com>
Le mardi 13 juillet 2010 à 14:41 +0300, Ofer Heifetz a écrit :
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
splice(socket -> pipe) provides partial buffers (depending on the MTU)
With typical MTU=1500 and tcp timestamps, each network frame contains
1448 bytes of payload, partially filling one page (of 4096 bytes)
When doing the splice(pipe -> file), kernel has to coalesce partial
data, but amount of written data per syscall() is small (about 20
Kbytes)
Without splice(), the write() syscall provides more data, and vfs
overhead is smaller as buffer size is a power of two.
Samba uses a 128 KBytes TRANSFER_BUF_SIZE in its default_sys_recvfile()
implementation, it easily outperforms splice() implementation.
You could try extending pipe size (fcntl(fd, F_SETPIPE_SZ, 256)), maybe
it will be a bit better. (and ask 256*4096 bytes to splice())
I tried this and got about 256Kbytes per splice() call...
# perf report
# Events: 13K
#
# Overhead Command Shared Object Symbol
# ........ .............. ................. ......
#
8.69% splice-fromnet [kernel.kallsyms] [k] memcpy
3.82% splice-fromnet [kernel.kallsyms] [k] kunmap_atomic
3.51% splice-fromnet [kernel.kallsyms] [k] __block_prepare_write
2.79% splice-fromnet [kernel.kallsyms] [k] __skb_splice_bits
2.58% splice-fromnet [kernel.kallsyms] [k] ext3_mark_iloc_dirty
2.45% splice-fromnet [kernel.kallsyms] [k] do_get_write_access
2.04% splice-fromnet [kernel.kallsyms] [k] __find_get_block
1.89% splice-fromnet [kernel.kallsyms] [k] _raw_spin_lock
1.83% splice-fromnet [kernel.kallsyms] [k] journal_add_journal_head
1.46% splice-fromnet [bnx2x] [k] bnx2x_rx_int
1.46% splice-fromnet [kernel.kallsyms] [k] kfree
1.42% splice-fromnet [kernel.kallsyms] [k] journal_put_journal_head
1.29% splice-fromnet [kernel.kallsyms] [k] __ext3_get_inode_loc
1.26% splice-fromnet [kernel.kallsyms] [k] journal_dirty_metadata
1.25% splice-fromnet [kernel.kallsyms] [k] page_address
1.20% splice-fromnet [kernel.kallsyms] [k] journal_cancel_revoke
1.15% splice-fromnet [kernel.kallsyms] [k] tcp_read_sock
1.09% splice-fromnet [kernel.kallsyms] [k] unlock_buffer
1.09% splice-fromnet [kernel.kallsyms] [k] pipe_to_file
1.05% splice-fromnet [kernel.kallsyms] [k] radix_tree_lookup_element
1.04% splice-fromnet [kernel.kallsyms] [k] kmap_atomic_prot
1.04% splice-fromnet [kernel.kallsyms] [k] kmem_cache_free
1.03% splice-fromnet [kernel.kallsyms] [k] kmem_cache_alloc
1.01% splice-fromnet [bnx2x] [k] bnx2x_poll
^ 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