On (10/18/17 01:10), pierre kuo wrote:
[..]
> > Well, it might get quite complicated, see printk_safe_flush_buffer().
>
> BTW, after checking printk_safe_flush_buffer() and related functions,
> we have one question:
> a) Why in printk_safe_log_store(), we need to use atomic_ operation in
>
On (10/18/17 01:10), pierre kuo wrote:
[..]
> > Well, it might get quite complicated, see printk_safe_flush_buffer().
>
> BTW, after checking printk_safe_flush_buffer() and related functions,
> we have one question:
> a) Why in printk_safe_log_store(), we need to use atomic_ operation in
>
hi Petr and Sergey:
> I wonder what is the motivation for the extra buffering. Did you
> have troubles with direct printk() calls? For example, because
> of performance, mixed messages, deadlocks?
Yes, when using direct printk() calls, we suffer performance and mix
message issues.
(Since
hi Petr and Sergey:
> I wonder what is the motivation for the extra buffering. Did you
> have troubles with direct printk() calls? For example, because
> of performance, mixed messages, deadlocks?
Yes, when using direct printk() calls, we suffer performance and mix
message issues.
(Since
hi:
> There are several possible solutions:
>
> + We could update vprintk_emit() to detect all newlines and
> call log_store() for each part. But this would be a waste
> of the space.
>
> + We could increase the size provided by syslog_printk().
> But this is ugly.
>
> + We could go back to
hi:
> There are several possible solutions:
>
> + We could update vprintk_emit() to detect all newlines and
> call log_store() for each part. But this would be a waste
> of the space.
>
> + We could increase the size provided by syslog_printk().
> But this is ugly.
>
> + We could go back to
On Wed 2017-09-27 21:59:52, pierre kuo wrote:
> hi:
> > printk_deferred("%s", local_string[2048]) makes no sense anyway,
> > since we limit the message size to 1024 - HEADER chars in
> > vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
>
> We use the example in this mail since we try to
On Wed 2017-09-27 21:59:52, pierre kuo wrote:
> hi:
> > printk_deferred("%s", local_string[2048]) makes no sense anyway,
> > since we limit the message size to 1024 - HEADER chars in
> > vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
>
> We use the example in this mail since we try to
Hi,
I was curious why you see these results. I think that I finally
understand it.
On Tue 2017-09-12 14:07:09, pierre kuo wrote:
> The experimental steps are list as follows.
> Feel free to give your comments.
>
> Prerequisite:
> a) kernel version:
> commit: a80099a152d0 ("Merge tag
Hi,
I was curious why you see these results. I think that I finally
understand it.
On Tue 2017-09-12 14:07:09, pierre kuo wrote:
> The experimental steps are list as follows.
> Feel free to give your comments.
>
> Prerequisite:
> a) kernel version:
> commit: a80099a152d0 ("Merge tag
On (09/27/17 21:59), pierre kuo wrote:
[..]
> We use the example in this mail since we try to collect the message at
> different places in our driver.
> And batch to printk for saving individual output time and group
> message together.
I see. well, printk batching (buffered mode) is a bit tricky
On (09/27/17 21:59), pierre kuo wrote:
[..]
> We use the example in this mail since we try to collect the message at
> different places in our driver.
> And batch to printk for saving individual output time and group
> message together.
I see. well, printk batching (buffered mode) is a bit tricky
hi:
> printk_deferred("%s", local_string[2048]) makes no sense anyway,
> since we limit the message size to 1024 - HEADER chars in
> vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
In local_string[2048], it will all be 0 from [590] to [2047].
And vprintk_emit() will cut message from
hi:
> printk_deferred("%s", local_string[2048]) makes no sense anyway,
> since we limit the message size to 1024 - HEADER chars in
> vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
In local_string[2048], it will all be 0 from [590] to [2047].
And vprintk_emit() will cut message from
On (09/18/17 03:00), Joe Perches wrote:
[..]
> > which is not a real world example, isn't it?
> >
> > printk_deferred("%s", local_string[2048]) makes no sense anyway,
> > since we limit the message size to 1024 - HEADER chars in
> > vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
> >
>
On (09/18/17 03:00), Joe Perches wrote:
[..]
> > which is not a real world example, isn't it?
> >
> > printk_deferred("%s", local_string[2048]) makes no sense anyway,
> > since we limit the message size to 1024 - HEADER chars in
> > vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
> >
>
On Mon, 2017-09-18 at 18:39 +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/12/17 14:07), pierre kuo wrote:
> [..]
> > int per_cpu_thread_fn(void* data)
> > {
> > unsigned int index = 0;
> > unsigned int len = 0;
> > char* local_string = kzalloc(2048, GFP_KERNEL);
> >
> > do {
On Mon, 2017-09-18 at 18:39 +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/12/17 14:07), pierre kuo wrote:
> [..]
> > int per_cpu_thread_fn(void* data)
> > {
> > unsigned int index = 0;
> > unsigned int len = 0;
> > char* local_string = kzalloc(2048, GFP_KERNEL);
> >
> > do {
Hi,
On (09/12/17 14:07), pierre kuo wrote:
[..]
> int per_cpu_thread_fn(void* data)
> {
> unsigned int index = 0;
> unsigned int len = 0;
> char* local_string = kzalloc(2048, GFP_KERNEL);
>
> do {
> len += sprintf((local_string + len), "this is the %d line\n",
>
Hi,
On (09/12/17 14:07), pierre kuo wrote:
[..]
> int per_cpu_thread_fn(void* data)
> {
> unsigned int index = 0;
> unsigned int len = 0;
> char* local_string = kzalloc(2048, GFP_KERNEL);
>
> do {
> len += sprintf((local_string + len), "this is the %d line\n",
>
hi Sergey and Petr
> Hi,
> On (08/11/17 00:55), pierre kuo wrote:
> [..]
>> And people will be hard to find out some part of message is left behind.
>> (since the tail of original message is elegantly dropped by "\n")
>> That is the reason I try to add such warning in msg_print_text.
>
> have you
hi Sergey and Petr
> Hi,
> On (08/11/17 00:55), pierre kuo wrote:
> [..]
>> And people will be hard to find out some part of message is left behind.
>> (since the tail of original message is elegantly dropped by "\n")
>> That is the reason I try to add such warning in msg_print_text.
>
> have you
Hi,
On (08/11/17 00:55), pierre kuo wrote:
[..]
> And people will be hard to find out some part of message is left behind.
> (since the tail of original message is elegantly dropped by "\n")
> That is the reason I try to add such warning in msg_print_text.
have you ever seen it (the truncation)
Hi,
On (08/11/17 00:55), pierre kuo wrote:
[..]
> And people will be hard to find out some part of message is left behind.
> (since the tail of original message is elegantly dropped by "\n")
> That is the reason I try to add such warning in msg_print_text.
have you ever seen it (the truncation)
On Fri 2017-08-11 00:55:48, pierre kuo wrote:
> hi Sergey:
> (Please ignore previous mail, I apologize for pressing send button too early
> :)
> >> this is not the only place that can truncate the message.
> >> vprintk_emit() can do so as well /* vscnprintf() */. but
> >> I think we don't care
On Fri 2017-08-11 00:55:48, pierre kuo wrote:
> hi Sergey:
> (Please ignore previous mail, I apologize for pressing send button too early
> :)
> >> this is not the only place that can truncate the message.
> >> vprintk_emit() can do so as well /* vscnprintf() */. but
> >> I think we don't care
hi Sergey:
(Please ignore previous mail, I apologize for pressing send button too early :)
>> this is not the only place that can truncate the message.
>> vprintk_emit() can do so as well /* vscnprintf() */. but
>> I think we don't care that much. a user likely will notice
>> truncated messages.
hi Sergey:
(Please ignore previous mail, I apologize for pressing send button too early :)
>> this is not the only place that can truncate the message.
>> vprintk_emit() can do so as well /* vscnprintf() */. but
>> I think we don't care that much. a user likely will notice
>> truncated messages.
hi Sergey
> this is not the only place that can truncate the message.
> vprintk_emit() can do so as well /* vscnprintf() */. but
> I think we don't care that much. a user likely will notice
> truncated messages. we report lost messages, because this
> is a completely different sort of problem.
hi Sergey
> this is not the only place that can truncate the message.
> vprintk_emit() can do so as well /* vscnprintf() */. but
> I think we don't care that much. a user likely will notice
> truncated messages. we report lost messages, because this
> is a completely different sort of problem.
On (07/30/17 21:37), pierre Kuo wrote:
> If the buffer pass to msg_print_text is not big enough to put both all
> prefixes and log_text(msg), kernel will quietly break.
> That means the user may not have the chance to know whether the
> log_text(msg) is fully printed into buffer or not.
>
> In
On (07/30/17 21:37), pierre Kuo wrote:
> If the buffer pass to msg_print_text is not big enough to put both all
> prefixes and log_text(msg), kernel will quietly break.
> That means the user may not have the chance to know whether the
> log_text(msg) is fully printed into buffer or not.
>
> In
If the buffer pass to msg_print_text is not big enough to put both all
prefixes and log_text(msg), kernel will quietly break.
That means the user may not have the chance to know whether the
log_text(msg) is fully printed into buffer or not.
In this patch, once above case happened, we try to
If the buffer pass to msg_print_text is not big enough to put both all
prefixes and log_text(msg), kernel will quietly break.
That means the user may not have the chance to know whether the
log_text(msg) is fully printed into buffer or not.
In this patch, once above case happened, we try to
34 matches
Mail list logo
