linux-kernel - Re: [RFC][PATCH 17/23 v4] tracing: Have seq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141114123001.4d19721d@gandalf.local.home>
Date:	Fri, 14 Nov 2014 12:30:01 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Petr Mladek <pmladek@...e.cz>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [RFC][PATCH 17/23 v4] tracing: Have seq_buf use full buffer

On Fri, 14 Nov 2014 18:07:16 +0100
Petr Mladek <pmladek@...e.cz> wrote:

> On Thu 2014-11-13 20:13:01, Steven Rostedt wrote:
> > From: "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>
> > 
> > Currently seq_buf is full when all but one byte of the buffer is
> > filled. Change it so that the seq_buf is full when all of the
> > buffer is filled.
> > 
> > Some of the functions would fill the buffer completely and report
> > everything was fine. This was inconsistent with the max of size - 1.
> > Changing this to be max of size makes all functions consistent.
> > 
> > Link: http://lkml.kernel.org/r/20141104160222.502133196@goodmis.org
> > 
> > Tested-by: Jiri Kosina <jkosina@...e.cz>
> > Acked-by: Jiri Kosina <jkosina@...e.cz>
> > Reviewed-by: Petr Mladek <pmladek@...e.cz>
> > Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> 
> Hmm, we should not apply this patch before we fix all other locations
> accessing seq.len. We need to make sure that they do not access
> outside of the buffer when seq.len = seq.size  + 1.
> 
> See my comments for "[RFC][PATCH 13/23 v4] tracing: Create seq_buf
> layer in trace_seq"

I agree. As I replied there, I'll add a patch before this gets applied
(right after seq_buf_left() is introduced), that will fix those issues.

> 
> BTW: Are these patches applied in some public branch, please? The
> patch series is getting long. I would like to see it applied but I do
> not want to copy all the patches and apply manually :-)

I'll start pushing them up to my repo under rfc/seq-buf

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git

That branch will always be rebasing. I have it applied on top of my
ftrace/core branch that will become my next for-next soon (after it
passes all my tests).


> 
> Best Regards,
> Petr
> 
> PS: I will need to go in a while. I am not sure that I will be able to
> review the whole patchset before the weekend. I do the review in the
> order of patches. I sent reply only when I had something to add. The
> non-commented other patches (< 17) looks fine to me.

Thanks, I'll add your Reviewed-by tags on them.

To ease the pain of review, I'll reply to your email comments with the
patches as I fix them up (as I've already done). I'll keep the commit
ids as well so that you can verify them. I'll try to remember to
constantly update my rfc/seq-buf branch.

Thanks a lot for your reviews. I really do appreciate it.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/