linux-kernel - Re: [PATCH] 9p: remove CONFIG_NET_9P

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]

Date:	Wed, 10 Aug 2011 22:47:39 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Eric Van Hensbergen <ericvh@...il.com>
Cc:	Alex Ray <alexjray.ncsu@...il.com>,
	v9fs-developer@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alex Ray <ajray@...u.edu>
Subject: Re: [PATCH] 9p: remove CONFIG_NET_9P_DEBUG option

On Wed, 10 Aug 2011 07:24:56 -0500, Eric Van Hensbergen <ericvh@...il.com> wrote:
> On Wed, Aug 10, 2011 at 4:13 AM, Aneesh Kumar K.V
> <aneesh.kumar@...ux.vnet.ibm.com> wrote:
> >
> > On Mon,  1 Aug 2011 07:14:44 -0500, Alex Ray <alexjray.ncsu@...il.com> wrote:
> >> Remove the CONFIG_NET_9P_DEBUG option, used to completely remove logging
> >> functionality from v9fs.  Logging is (already) controlled with the
> >> run-time debug= option, this gets rid of the compile-time option (which
> >> was being misunderstood and misused).
> >>
> >> Signed-off-by: Alex Ray <ajray@...u.edu>
> >
> > I see this merged to for-next.  Do we know whether enabling debug always have a
> > performance impact ?.
> >
> 
> No clue, but without any debug it makes it impossible for user's to
> generate reasonable bug reports.  If I understand the tracepoint
> collection facility correctly, it incurs exactly the same overhead as
> a DPRINT when the debug mount option is set to 0 (although tracepoints
> are much lower overhead when actually collecting).

I was worried about overhead when we are not collecting any debug info.

>  Now, one could
> make a case that we have too many DPRINT and need to cut back, but if
> that's the case, let's just get around to it and cleanup a bit.
> 
> All that being said, I welcome anyone to send me performance with and
> without CONFIG_NET_9P_DEBUG turned on to convince me differently.

With tracepoints we should not have much performance impact when tracing is
disabled. So may be the right way to go forward is to convert enough P9_DPRINT
to tracepoint that will aid in better debugging of errors, and retain
CONFIG_NET_9P_DEBUG as it is. 

I actually converted protocol dump to tracepoints. Other advantages 
of switching to tracepoints is the ability to get stack trace, 
filtering debug output per mount points, integration with perf tool.

I guess if we can list out which set of P9_DPRINTK will aid better
reporting of bugs then we can look at converting them to
tracepoints. Protocol dump was the immediate one which I found useful.

-aneesh
--
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/