linux-kernel - Re: [RFC PATCH] seq_file: Use seq_puts when 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: <20130316180141.GB21522@ZenIV.linux.org.uk>
Date:	Sat, 16 Mar 2013 18:01:41 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Joe Perches <joe@...ches.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] seq_file: Use seq_puts when seq_printf has only a
 format with no args

On Sat, Mar 16, 2013 at 10:51:18AM -0700, Joe Perches wrote:
> > This is certainly a neat trick.
> > 
> > But I don't really like the fact that it complicates things for every
> > future code reader, especially when a trivial change in the caller
> > would accomplish the same thing.  Do you have any idea how much
> > performance we would gain in exchange for the complication?
> 
> Nope.  I believe it's trivial in any case.
> I just saw Steven's trace hack and thought of seq_printk.
> 
> Is there a real performance sensitive seq_printf anywhere?

... and _that_ is the question that should've been asked first.

> It's trivial to replace seq_printf("constant") with
> seq_puts but there are over a thousand of them.
> 
> It may be better to just leave everything as-is.

Quite.  Note that it's not equivalent to gcc treatment of printf/puts -
there we have cases when it *is* a real hotpath (and I seriously suspect
that it's in part driven by desire to discourage people from uglifying
source by manual equivalents of that micro-optimization).  Moreover,
glibc printf at least used to be heavy; kernel-side we are nowhere near
that bad.
--
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/