We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was introduced by commit
2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable rx
buffers to page frag allocators).
Cc: Michael Dalton mwdal...@google.com
Cc:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was introduced by commit
2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable rx
buffers to page frag
On Tue, Nov 19, 2013 at 06:03:48AM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was introduced by commit
On Tue, Nov 19, 2013 at 06:03:48AM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was introduced by commit
On Tue, 2013-11-19 at 22:49 +0200, Michael S. Tsirkin wrote:
On Tue, Nov 19, 2013 at 06:03:48AM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for
frag
list, otherwise it will be
Great catch Jason. I agree this now raises the larger issue of how to
handle a memory alloc failure in the middle of receive. As Eric mentioned,
we can drop the packet and free the remaining (num_buf) frags.
Michael, perhaps I'm missing something, but why would you prefer
pre-allocating buffers
On Tue, Nov 19, 2013 at 01:36:36PM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 22:49 +0200, Michael S. Tsirkin wrote:
On Tue, Nov 19, 2013 at 06:03:48AM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to
On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote:
Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a
it didn't drop packets received from host as far as I can tell.
virtio is more like a pipe than a real NIC in this respect.
Prior/after to this patch, you were not
Hi,
After further reflection I think we're looking at two related issues:
(a) a memory leak that Jason has identified that occurs when a memory
allocation fails in receive_mergeable. Jasons commit solves this issue.
(b) virtio-net does not dequeue all buffers for a packet in the
case that an
On 11/19/2013 10:03 PM, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was introduced by commit
2613af0ed18a11d5c566a81f9a6510b73180660a
On 11/20/2013 04:49 AM, Michael S. Tsirkin wrote:
On Tue, Nov 19, 2013 at 06:03:48AM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 16:05 +0800, Jason Wang wrote:
We need to drop the refcnt of page when we fail to allocate an skb for frag
list, otherwise it will be leaked. The bug was
Eric Dumazet eric.duma...@gmail.com writes:
On Wed, 2013-11-13 at 15:10 +0800, Jason Wang wrote:
There's one concern with EWMA. How well does it handle multiple streams
each with different packet size? E.g there may be two flows, one with
256 bytes each packet another is 64K. Looks like it
On 11/20/2013 09:34 AM, Michael Dalton wrote:
Hi,
After further reflection I think we're looking at two related issues:
(a) a memory leak that Jason has identified that occurs when a memory
allocation fails in receive_mergeable. Jasons commit solves this issue.
(b) virtio-net does not
Hi,
Here is the version 3 of NOKPORBE_SYMBOL series.
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've introduced NOKPROBE_SYMBOL() macro
for making kprobe blacklist at
There is no need to prohibit probing on the functions
used in preparation phase. Those are safely probed because
those are not invoked from breakpoint/fault/debug handlers,
there is no chance to cause recursive exceptions.
Following functions are now removed from the kprobes blacklist.
can_boost
To blacklist the functions in a module (e.g. user-defined
kprobe handler and the functions invoked from it), expand
blacklist support for modules.
With this change, users can use NOKPROBE_SYMBOL() macro in
their own modules.
Changes from previous:
- Fix the type of kprobe_blacklist_seq_stop()
Show blacklist entries (function names with the address
range) via /sys/kernel/debug/kprobes/blacklist.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com
Cc: David S. Miller da...@davemloft.net
---
kernel/kprobes.c | 61
Use NOKPROBE_SYMBOL() to protect handlers from kprobes
in sample modules.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Ananth N Mavinakayanahalli ana...@in.ibm.com
---
samples/kprobes/jprobe_example.c|1 +
samples/kprobes/kprobe_example.c|3 +++
.entry.text is a code area which is used for interrupt/syscall
entries, and there are many sensitive codes.
Thus, it is better to prohibit probing on all of such codes
instead of a part of that.
Since some symbols are already registered on kprobe blacklist,
this also removes them from the
Introduce NOKPROBE_SYMBOL() macro which builds a kprobe
blacklist in build time. The usage of this macro is similar
to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just
after the function definition.
If CONFIG_KPROBES=y, the macro is expanded to the definition
of a static data structure
Use NOKPROBE_SYMBOL macro for protecting functions
from kprobes instead of __kprobes annotation in x86
kprobes code.
This applies __always_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by
referring the symbol address.
Signed-off-by: Masami Hiramatsu
There is no need to prohibit probing on the functions
used for preparation, registeration, optimization,
controll etc. Those are safely probed because those are
not invoked from breakpoint/fault/debug handlers,
there is no chance to cause recursive exceptions.
Following functions are now removed
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in ftrace.
This applies __always_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by
referring the symbol address.
Signed-off-by: Masami Hiramatsu
There is no need to prohibit probing on the functions
used for preparation. Those are safely probed because
those are not invoked from breakpoint/fault/debug handlers,
there is no chance to cause recursive exceptions.
Following functions are now removed from the kprobes blacklist.
Use NOKPROBE_SYMBOL macro to protect functions from kprobes
instead of __kprobe annotation in hw_breakpoint.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Andrew Morton
Use NOKPROBE_SYMBOL macro to protect functions from kprobes
instead of __kprobes annotation in fault.c.
This applies __always_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by
referring the symbol address.
Signed-off-by: Masami Hiramatsu
Use NOKPROBE_SYMBOL macro to protect functions from kprobes
instead of __kprobes annotation in alternative.c.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jiri Kosina
Use NOKPROBE_SYMBOL macro to protect functions from kprobes
instead of __kprobes annotation in trap.c.
This also applies __always_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by referring
the symbol address.
Signed-off-by: Masami Hiramatsu
Use NOKPROBE_SYMBOL macro for protecting functions
from kprobes instead of __kprobes annotation in kvm.c.
This also adds kvm_read_and_reset_pf_reason in
the blacklist because it can be called before
do_page_fault.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation for nmi handlers.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Peter
Use NOKPROBE_SYMBOL macro for protecting functions
from kprobes instead of __kprobes annotation in
dumpstack.c.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Andrew
Prohibit probing on func_ptr_is_kernel_text() by adding
it to the kprobe_blacklist.
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in sched/core.c.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Peter Zijlstra pet...@infradead.org
---
kernel/sched/core.c |6 --
1 file
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in notifier.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
kernel/notifier.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git
Use kprobe_blackpoint for blacklisting .entry.text and .kprobes.text
instead of arch_within_kprobe_blacklist. This also makes them visible
via (debugfs)/kprobes/blacklist.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar
35 matches
Mail list logo
