On Wed 2014-11-19 11:00:37, Steven Rostedt wrote:
> On Wed, 19 Nov 2014 15:40:05 +0100
> Petr Mladek wrote:
>
> > > Regardless of overflow or not (or even if trace_seq is full), that if
> > > statement will prevent this from doing any buffer overflows.
> > >
> > > s->seq.len will never be more
On Wed, 19 Nov 2014 15:40:05 +0100
Petr Mladek wrote:
> > Regardless of overflow or not (or even if trace_seq is full), that if
> > statement will prevent this from doing any buffer overflows.
> >
> > s->seq.len will never be more than s->seq.size after the test against
> > TRACE_MAX_PRINT. So
On Wed, 19 Nov 2014 15:40:05 +0100
Petr Mladek wrote:
> > s->seq.len will never be more than s->seq.size after the test against
> > TRACE_MAX_PRINT. So I see no harm here.
>
> Ah, I see. Well, I would feel more comfortable if it uses
> trace_seq_used() or if there is some explanation in a
On Wed 2014-11-19 08:48:00, Steven Rostedt wrote:
> On Wed, 19 Nov 2014 12:40:17 +0100
> Petr Mladek wrote:
>
> > > >
> > > > There is one more dangerous usage in trace_printk_seq(). It is on
> > > > three lines there.
> > >
> > > You totally confused me. What usage in trace_printk_seq(), and
On Wed, 19 Nov 2014 12:40:17 +0100
Petr Mladek wrote:
> > >
> > > There is one more dangerous usage in trace_printk_seq(). It is on
> > > three lines there.
> >
> > You totally confused me. What usage in trace_printk_seq(), and what
> > three lines?
> >
> > In this patch, trace_printk_seq()
On Tue 2014-11-18 12:37:32, Steven Rostedt wrote:
> On Tue, 18 Nov 2014 17:33:54 +0100
> Petr Mladek wrote:
>
> > On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
> > >
> > > > I don't like the fact that I did a code structure change with this
> > > > patch. This patch should be just a simple
On Tue 2014-11-18 12:37:32, Steven Rostedt wrote:
On Tue, 18 Nov 2014 17:33:54 +0100
Petr Mladek pmla...@suse.cz wrote:
On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
I don't like the fact that I did a code structure change with this
patch. This patch should be just a simple
On Wed, 19 Nov 2014 12:40:17 +0100
Petr Mladek pmla...@suse.cz wrote:
There is one more dangerous usage in trace_printk_seq(). It is on
three lines there.
You totally confused me. What usage in trace_printk_seq(), and what
three lines?
In this patch, trace_printk_seq() looks
On Wed 2014-11-19 08:48:00, Steven Rostedt wrote:
On Wed, 19 Nov 2014 12:40:17 +0100
Petr Mladek pmla...@suse.cz wrote:
There is one more dangerous usage in trace_printk_seq(). It is on
three lines there.
You totally confused me. What usage in trace_printk_seq(), and what
On Wed, 19 Nov 2014 15:40:05 +0100
Petr Mladek pmla...@suse.cz wrote:
s-seq.len will never be more than s-seq.size after the test against
TRACE_MAX_PRINT. So I see no harm here.
Ah, I see. Well, I would feel more comfortable if it uses
trace_seq_used() or if there is some explanation in a
On Wed, 19 Nov 2014 15:40:05 +0100
Petr Mladek pmla...@suse.cz wrote:
Regardless of overflow or not (or even if trace_seq is full), that if
statement will prevent this from doing any buffer overflows.
s-seq.len will never be more than s-seq.size after the test against
TRACE_MAX_PRINT.
On Wed 2014-11-19 11:00:37, Steven Rostedt wrote:
On Wed, 19 Nov 2014 15:40:05 +0100
Petr Mladek pmla...@suse.cz wrote:
Regardless of overflow or not (or even if trace_seq is full), that if
statement will prevent this from doing any buffer overflows.
s-seq.len will never be more
On Tue, 18 Nov 2014 17:33:54 +0100
Petr Mladek wrote:
> On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
> >
> > > I don't like the fact that I did a code structure change with this
> > > patch. This patch should be just a simple conversion of len to
> > > seq_buf_used(). I'm going to strip
On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
>
> > I don't like the fact that I did a code structure change with this
> > patch. This patch should be just a simple conversion of len to
> > seq_buf_used(). I'm going to strip this change out and put it before
> > this patch.
>
>
> As the
On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
I don't like the fact that I did a code structure change with this
patch. This patch should be just a simple conversion of len to
seq_buf_used(). I'm going to strip this change out and put it before
this patch.
As the seq_buf-len
On Tue, 18 Nov 2014 17:33:54 +0100
Petr Mladek pmla...@suse.cz wrote:
On Mon 2014-11-17 14:12:15, Steven Rostedt wrote:
I don't like the fact that I did a code structure change with this
patch. This patch should be just a simple conversion of len to
seq_buf_used(). I'm going to strip
> I don't like the fact that I did a code structure change with this
> patch. This patch should be just a simple conversion of len to
> seq_buf_used(). I'm going to strip this change out and put it before
> this patch.
As the seq_buf->len will soon be +1 size when there's an overflow, we
must
I don't like the fact that I did a code structure change with this
patch. This patch should be just a simple conversion of len to
seq_buf_used(). I'm going to strip this change out and put it before
this patch.
As the seq_buf-len will soon be +1 size when there's an overflow, we
must use
18 matches
Mail list logo
