linux-kernel - Re: [RFC][PATCH 04/12 v3] tracing: Convert seq_buf_path() to be like 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: <20141106141820.GC2001@dhcp128.suse.cz>
Date:	Thu, 6 Nov 2014 15:18:22 +0100
From:	Petr Mladek <pmladek@...e.cz>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 04/12 v3] tracing: Convert seq_buf_path() to be like
 seq_path()

On Wed 2014-11-05 15:10:53, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 15:45:53 +0100
> Petr Mladek <pmladek@...e.cz> wrote:
> 
> 
> > >   */
> > > -int seq_buf_path(struct seq_buf *s, const struct path *path)
> > > +int seq_buf_path(struct seq_buf *s, const struct path *path, const char *esc)
> > >  {
> > > -	unsigned int len = SEQ_BUF_LEFT(s);
> > > -	unsigned char *p;
> > > -
> > > -	WARN_ON(s->size == 0);
> > 
> > I would keep this check.
> 
> Yeah, I could.

great :-)

> > 
> > > -	p = d_path(path, s->buffer + s->len, len);
> > > -	if (!IS_ERR(p)) {
> > > -		p = mangle_path(s->buffer + s->len, p, "\n");
> > > -		if (p) {
> > > -			s->len = p - s->buffer;
> > > -			return 0;
> > > +	char *buf = s->buffer + s->len;
> > > +	size_t size = SEQ_BUF_LEFT(s);
> > 
> > I would use the variable name "len" to make it consistent with
> > the other fucntions in seq_buf.c.
> 
> Note, seq_path() is a different beast than the other seq_*() functions
> (this will be keeping a return code). And the inconsistency is in
> seq_file.c as well. I'm not saying we shouldn't keep it consistent. But
> as this patch is to make seq_buf like seq_file, I'll keep the
> inconsistencies the same too.

Ah, I have missed this.

> We can always do a clean up later.

Fair enough. The result of this patch set (safe printing of
backtraces from all CPUs) is more important than this clean up.

[...]

> > 
> > > -	return -1;
> > > +	if (res > 0)
> > > +		s->len += res;
> > > +
> > > +	return res;
> > 
> > It returns -1 on failure and the number of written characters on
> > success. This is incompatible with the other seq_buf functions
> > and with the comment above this function. Also it changes the
> > return value from trace_seq_path().
> > 
> > I do not mind about the used scheme but I think that we should
> > make it consistent.
> > 
> 
> As seq_file has had this inconsistency for a long time, and this code
> is to try to merge the code between trace_seq and seq_file, I'm going
> to follow seq_file as that has been around much longer than trace_seq.

I see. Well, we still need to fix trace_seq_path() or its callers.
For example, seq_print_user_ip() checks trace_seq_path() return value
and expects 0 on failure.

Best Regards,
Petr
--
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/