On Mon, 4 Nov 2013 15:38:13 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
>> >
>> > But. Perhaps it makes sense to at least add a couple of trivial
>> > helpers in 10/13? Something like arg_buf_get/put/init, just to
>> >
Hi Oleg,
On Mon, 4 Nov 2013 15:35:17 +0100, Oleg Nesterov wrote:
> Hi Namhyung,
>
> On 11/04, Namhyung Kim wrote:
>>
>> >>
>> >> + if (atomic_dec_and_test(_buffer_ref)) {
>> >> + free_percpu(uprobe_cpu_buffer);
>> >> + uprobe_cpu_buffer = NULL;
>> >> + }
>> >> +
>> >>
On 11/04, Namhyung Kim wrote:
>
> On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
> >
> > But. Perhaps it makes sense to at least add a couple of trivial
> > helpers in 10/13? Something like arg_buf_get/put/init, just to
> > simplify the potential changes.
>
> Good idea. How about
Hi Namhyung,
On 11/04, Namhyung Kim wrote:
>
> >>
> >> + if (atomic_dec_and_test(_buffer_ref)) {
> >> + free_percpu(uprobe_cpu_buffer);
> >> + uprobe_cpu_buffer = NULL;
> >> + }
> >> +
> >>WARN_ON(!uprobe_filter_is_empty(>filter));
> >
> > Do we really need atomic_t?
On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
> On 11/01, Oleg Nesterov wrote:
>>
>> Ah, please ignore... handler_chain() is not self-serialized, so
>> tu->buffer needs locking/waiting too.
>
> Still I have to admit that I strongly dislike this yet another
> (and imho strange) memory
Hi Oleg,
On Thu, 31 Oct 2013 19:16:54 +0100, Oleg Nesterov wrote:
> On 10/29, Namhyung Kim wrote:
>>
>> @@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
>> filter_func_t filter)
>> if (trace_probe_is_enabled(>p))
>> return -EINTR;
>>
>> +if
Hi Oleg,
On Mon, 4 Nov 2013 15:35:17 +0100, Oleg Nesterov wrote:
Hi Namhyung,
On 11/04, Namhyung Kim wrote:
+ if (atomic_dec_and_test(uprobe_buffer_ref)) {
+ free_percpu(uprobe_cpu_buffer);
+ uprobe_cpu_buffer = NULL;
+ }
+
On Mon, 4 Nov 2013 15:38:13 +0100, Oleg Nesterov wrote:
On 11/04, Namhyung Kim wrote:
On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
But. Perhaps it makes sense to at least add a couple of trivial
helpers in 10/13? Something like arg_buf_get/put/init, just to
simplify the
Hi Oleg,
On Thu, 31 Oct 2013 19:16:54 +0100, Oleg Nesterov wrote:
On 10/29, Namhyung Kim wrote:
@@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
filter_func_t filter)
if (trace_probe_is_enabled(tu-p))
return -EINTR;
+if
On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
On 11/01, Oleg Nesterov wrote:
Ah, please ignore... handler_chain() is not self-serialized, so
tu-buffer needs locking/waiting too.
Still I have to admit that I strongly dislike this yet another
(and imho strange) memory pool. However,
Hi Namhyung,
On 11/04, Namhyung Kim wrote:
+ if (atomic_dec_and_test(uprobe_buffer_ref)) {
+ free_percpu(uprobe_cpu_buffer);
+ uprobe_cpu_buffer = NULL;
+ }
+
WARN_ON(!uprobe_filter_is_empty(tu-filter));
Do we really need atomic_t?
On 11/04, Namhyung Kim wrote:
On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
But. Perhaps it makes sense to at least add a couple of trivial
helpers in 10/13? Something like arg_buf_get/put/init, just to
simplify the potential changes.
Good idea. How about something like
On 11/01, Oleg Nesterov wrote:
>
> Ah, please ignore... handler_chain() is not self-serialized, so
> tu->buffer needs locking/waiting too.
Still I have to admit that I strongly dislike this yet another
(and imho strange) memory pool. However, I am not going to argue
because I can't suggest
On 11/01, Oleg Nesterov wrote:
Ah, please ignore... handler_chain() is not self-serialized, so
tu-buffer needs locking/waiting too.
Still I have to admit that I strongly dislike this yet another
(and imho strange) memory pool. However, I am not going to argue
because I can't suggest something
On 11/01, Oleg Nesterov wrote:
>
> Hi Namhyung,
>
> Sorry if this was already discussed. But I can't really understand
> the idea of this per-cpu buffer...
>
> On 10/29, Namhyung Kim wrote:
> >
> > Fetching from user space should be done in a non-atomic context. So
> > use a per-cpu buffer and
Hi Namhyung,
Sorry if this was already discussed. But I can't really understand
the idea of this per-cpu buffer...
On 10/29, Namhyung Kim wrote:
>
> Fetching from user space should be done in a non-atomic context. So
> use a per-cpu buffer and copy its content to the ring buffer
> atomically.
Hi Oleg,
Thank you for reviewing this patchset!
On Thu, 31 Oct 2013 19:16:54 +0100, Oleg Nesterov wrote:
> On 10/29, Namhyung Kim wrote:
>>
>> @@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
>> filter_func_t filter)
>> if (trace_probe_is_enabled(>p))
>>
Hi Oleg,
Thank you for reviewing this patchset!
On Thu, 31 Oct 2013 19:16:54 +0100, Oleg Nesterov wrote:
On 10/29, Namhyung Kim wrote:
@@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
filter_func_t filter)
if (trace_probe_is_enabled(tu-p))
Hi Namhyung,
Sorry if this was already discussed. But I can't really understand
the idea of this per-cpu buffer...
On 10/29, Namhyung Kim wrote:
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note
On 11/01, Oleg Nesterov wrote:
Hi Namhyung,
Sorry if this was already discussed. But I can't really understand
the idea of this per-cpu buffer...
On 10/29, Namhyung Kim wrote:
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its
On 10/29, Namhyung Kim wrote:
>
> @@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
> filter_func_t filter)
> if (trace_probe_is_enabled(>p))
> return -EINTR;
>
> + if (atomic_inc_return(_buffer_ref) == 1) {
> + int cpu;
> +
> +
On 10/29, Namhyung Kim wrote:
@@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
filter_func_t filter)
if (trace_probe_is_enabled(tu-p))
return -EINTR;
+ if (atomic_inc_return(uprobe_buffer_ref) == 1) {
+ int cpu;
+
+
From: Namhyung Kim
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
This is needed since
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
Hi Jovi,
[SNIP]
On Tue, 3 Sep 2013 19:10:04 +0800, zhangwei wrote:
>> +if (atomic_inc_return(_buffer_ref) == 1) {
>> +int cpu;
>> +
>> +uprobe_cpu_buffer = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
>> +if (uprobe_cpu_buffer == NULL)
>> +
On Tue, 03 Sep 2013 19:50:28 +0900, Masami Hiramatsu wrote:
> (2013/09/03 14:44), Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> Fetching from user space should be done in a non-atomic context. So
>> use a per-cpu buffer and copy its content to the ring buffer
>> atomically. Note that we can
On Tue, 03 Sep 2013 19:50:28 +0900, Masami Hiramatsu wrote:
(2013/09/03 14:44), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note
Hi Jovi,
[SNIP]
On Tue, 3 Sep 2013 19:10:04 +0800, zhangwei wrote:
+if (atomic_inc_return(uprobe_buffer_ref) == 1) {
+int cpu;
+
+uprobe_cpu_buffer = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
+if (uprobe_cpu_buffer == NULL)
+return
On 2013/9/3 13:44, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Fetching from user space should be done in a non-atomic context. So
> use a per-cpu buffer and copy its content to the ring buffer
> atomically. Note that we can migrate during accessing user memory
> thus use a per-cpu mutex to
(2013/09/03 14:44), Namhyung Kim wrote:
> From: Namhyung Kim
>
> Fetching from user space should be done in a non-atomic context. So
> use a per-cpu buffer and copy its content to the ring buffer
> atomically. Note that we can migrate during accessing user memory
> thus use a per-cpu mutex to
(2013/09/03 14:44), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a
On 2013/9/3 13:44, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a
From: Namhyung Kim
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
This is needed since
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
(2013/08/27 17:07), Namhyung Kim wrote:
> Hi Steven,
>
> On Thu, 22 Aug 2013 21:08:30 -0400, Steven Rostedt wrote:
>> On Fri, 23 Aug 2013 07:57:15 +0800
>> "zhangwei(Jovi)" wrote:
>>
>>
What about creating a per cpu buffer when uprobes are registered, and
delete them when they are
From: Namhyung Kim
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
This is needed since
Hi Steven,
On Thu, 22 Aug 2013 21:08:30 -0400, Steven Rostedt wrote:
> On Fri, 23 Aug 2013 07:57:15 +0800
> "zhangwei(Jovi)" wrote:
>
>
>> >
>> > What about creating a per cpu buffer when uprobes are registered, and
>> > delete them when they are finished? Basically what trace_printk() does
>>
Hi Steven,
On Thu, 22 Aug 2013 21:08:30 -0400, Steven Rostedt wrote:
On Fri, 23 Aug 2013 07:57:15 +0800
zhangwei(Jovi) jovi.zhang...@huawei.com wrote:
What about creating a per cpu buffer when uprobes are registered, and
delete them when they are finished? Basically what trace_printk()
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
(2013/08/27 17:07), Namhyung Kim wrote:
Hi Steven,
On Thu, 22 Aug 2013 21:08:30 -0400, Steven Rostedt wrote:
On Fri, 23 Aug 2013 07:57:15 +0800
zhangwei(Jovi) jovi.zhang...@huawei.com wrote:
What about creating a per cpu buffer when uprobes are registered, and
delete them when they are
(2013/08/23 8:57), zhangwei(Jovi) wrote:
> On 2013/8/23 0:42, Steven Rostedt wrote:
>> On Fri, 09 Aug 2013 18:56:54 +0900
>> Masami Hiramatsu wrote:
>>
>>> (2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim
Fetching from user space should be done in a non-atomic context.
On Fri, 23 Aug 2013 07:57:15 +0800
"zhangwei(Jovi)" wrote:
> >
> > What about creating a per cpu buffer when uprobes are registered, and
> > delete them when they are finished? Basically what trace_printk() does
> > if it detects that there are users of trace_printk() in the kernel.
> > Note,
On 2013/8/23 0:42, Steven Rostedt wrote:
> On Fri, 09 Aug 2013 18:56:54 +0900
> Masami Hiramatsu wrote:
>
>> (2013/08/09 17:45), Namhyung Kim wrote:
>>> From: Namhyung Kim
>>>
>>> Fetching from user space should be done in a non-atomic context. So
>>> use a temporary buffer and copy its
On Fri, 09 Aug 2013 18:56:54 +0900
Masami Hiramatsu wrote:
> (2013/08/09 17:45), Namhyung Kim wrote:
> > From: Namhyung Kim
> >
> > Fetching from user space should be done in a non-atomic context. So
> > use a temporary buffer and copy its content to the ring buffer
> > atomically.
> >
> >
(2013/08/23 8:57), zhangwei(Jovi) wrote:
On 2013/8/23 0:42, Steven Rostedt wrote:
On Fri, 09 Aug 2013 18:56:54 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be
On Fri, 09 Aug 2013 18:56:54 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a temporary buffer and copy its content to
On 2013/8/23 0:42, Steven Rostedt wrote:
On Fri, 09 Aug 2013 18:56:54 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a
On Fri, 23 Aug 2013 07:57:15 +0800
zhangwei(Jovi) jovi.zhang...@huawei.com wrote:
What about creating a per cpu buffer when uprobes are registered, and
delete them when they are finished? Basically what trace_printk() does
if it detects that there are users of trace_printk() in the
On Sat, Aug 10, 2013 at 9:41 AM, zhangwei(Jovi) wrote:
> On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi)
> wrote:
>> On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>>>
>>> Sorry, I didn't read this series yet. Not that I think this needs my
>>> help, but I'll try to do this a later...
On Sat, Aug 10, 2013 at 9:41 AM, zhangwei(Jovi) jovi.zhang...@gmail.com wrote:
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) jovi.zhang...@gmail.com
wrote:
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think this
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) wrote:
> On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>>
>> Sorry, I didn't read this series yet. Not that I think this needs my
>> help, but I'll try to do this a later...
>>
>> On 08/09, Masami Hiramatsu wrote:
>> >
>> > I just concern
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>
> Sorry, I didn't read this series yet. Not that I think this needs my
> help, but I'll try to do this a later...
>
> On 08/09, Masami Hiramatsu wrote:
> >
> > I just concern using kmalloc() in the event handler.
>
> GFP_KERNEL should be
On 08/09, Oleg Nesterov wrote:
>
> Steven, Jovi, what should we do with that patch? It seems that it
> was forgotten.
>
> I can take these patches into my ubprobes branch
I meant that patch from Jovi, sorry for confusion.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu wrote:
>
> I just concern using kmalloc() in the event handler.
GFP_KERNEL should be fine for uprobe handler.
However, iirc this conflicts with the patches
(2013/08/09 17:45), Namhyung Kim wrote:
> From: Namhyung Kim
>
> Fetching from user space should be done in a non-atomic context. So
> use a temporary buffer and copy its content to the ring buffer
> atomically.
>
> While at it, use __get_data_size() and store_trace_args() to reduce
> code
From: Namhyung Kim
Fetching from user space should be done in a non-atomic context. So
use a temporary buffer and copy its content to the ring buffer
atomically.
While at it, use __get_data_size() and store_trace_args() to reduce
code duplication.
Cc: Masami Hiramatsu
Cc: Srikar Dronamraju
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a temporary buffer and copy its content to the ring buffer
atomically.
While at it, use __get_data_size() and store_trace_args() to reduce
code duplication.
Cc: Masami Hiramatsu
(2013/08/09 17:45), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a temporary buffer and copy its content to the ring buffer
atomically.
While at it, use __get_data_size() and store_trace_args() to
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu wrote:
I just concern using kmalloc() in the event handler.
GFP_KERNEL should be fine for uprobe handler.
However, iirc this conflicts with the patches from
On 08/09, Oleg Nesterov wrote:
Steven, Jovi, what should we do with that patch? It seems that it
was forgotten.
I can take these patches into my ubprobes branch
I meant that patch from Jovi, sorry for confusion.
Oleg.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu wrote:
I just concern using kmalloc() in the event handler.
GFP_KERNEL should
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) jovi.zhang...@gmail.com wrote:
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov o...@redhat.com wrote:
Sorry, I didn't read this series yet. Not that I think this needs my
help, but I'll try to do this a later...
On 08/09, Masami Hiramatsu
62 matches
Mail list logo
