linux-kernel - RE: [PATCH v1 1/1] Extended events (platform-specific) support in perf

Open Source and information security mailing list archives

Date:	Fri, 22 Jan 2010 14:08:35 +0100
From:	Tomasz Fujak <t.fujak@...sung.com>
To:	'Arnaldo Carvalho de Melo' <acme@...radead.org>
Cc:	jpihet@...sta.com, peterz@...radead.org,
	Pawel Osciak <p.osciak@...sung.com>, jamie.iles@...ochip.com,
	will.deacon@....com, linux-kernel@...r.kernel.org,
	kyungmin.park@...sung.com, mingo@...e.hu,
	linux-arm-kernel@...ts.infradead.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: RE: [PATCH v1 1/1] Extended events (platform-specific) support in perf

> -----Original Message-----
> From: linux-arm-kernel-bounces@...ts.infradead.org [mailto:linux-arm-
> kernel-bounces@...ts.infradead.org] On Behalf Of Arnaldo Carvalho de
> Melo
> Sent: Friday, January 22, 2010 1:26 PM
> To: Tomasz Fujak
> Cc: jpihet@...sta.com; peterz@...radead.org; p.osciak@...sung.com;
> jamie.iles@...ochip.com; will.deacon@....com; linux-
> kernel@...r.kernel.org; kyungmin.park@...sung.com; mingo@...e.hu;
> linux-arm-kernel@...ts.infradead.org; m.szyprowski@...sung.com
> Subject: Re: [PATCH v1 1/1] Extended events (platform-specific) support
> in perf
> 
> Em Fri, Jan 22, 2010 at 01:08:59PM +0100, Tomasz Fujak escreveu:
> > Signed-off-by: Tomasz Fujak <t.fujak@...sung.com>
> > Reviewed-by: Pawel Osciak <p.osciak@...sung.com>
> > Reviewed-by: Marek Szyprowski <m.szyprowski@...sung.com>
> > Reviewed-by: Kyungmin Park <kuyngmin.park@...sung.com>
> 
> "Extended" seems vague, I think in this context "platform_" would be a
> better namespace specifier.

Right.

> > +#define	BYTES_PER_CHUNK 4096
> > +/* returns the number of lines read;
> > +   on fail the return is negative and no memory is allocated
> > +   otherwise the *buf contains a memory chunk of which first
> > +   *size bytes are used for file contents
> > + */
> > +static int read_file(int fd, char **buf, unsigned *size)
> > +{
> > +	unsigned bytes = BYTES_PER_CHUNK;
> > +	int lines = 0;
> > +	char *ptr = malloc(bytes);
> 
> malloc can fail... Also why is that you can't process the lines one by
> one instead of reading the whole (albeit small) file at once?

Right, no malloc check.
The purpose of not processing line-by-line is that then the collection needs
to be dynamic.

Since the file buffer gets dropped after it's processed, the overallocated
memory is returned to the system.
In case of the collection (here an array and a counter) it'd require tricks
not to overallocate, and still be O(#events).

But you're right I didn't do it right - in case the a line does not parse,
memory reserved for it is not freed. Fixing.

> > +
> > +		if (name && description) {
> > +			symbols[count].symbol = name;
> > +			symbols[count].alias = "";
> > +			++count;
> > +			/* description gets lost here */
> > +			free(description);
> > +		} else {
> > +			free(description);
> > +			free(name);
> > +		}
> 
> Having "free(description);" in both cases seems funny :-)

I wasn't so bold as to upgrade the perf with human-readable event
description.
Otherwise yes, moving it outside.

> 
> - Arnaldo
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

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