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: <1226476898.31699.37.camel@ecld0pohly>
Date:	Wed, 12 Nov 2008 09:01:38 +0100
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Octavian Purdila <opurdila@...acom.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Ingo Oeser <netdev@...eo.de>,
	"Ronciak, John" <john.ronciak@...el.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Oliver Hartkopp <oliver@...tkopp.net>
Subject: Re: [RFC PATCH 11/13] time sync: generic infrastructure to map
	between time stamps generated by a clock source and system time

On Tue, 2008-11-11 at 16:18 +0000, Andi Kleen wrote:
> > +
> > +int clocksync_offset(struct clocksync *sync,
> > +		s64 *offset,
> > +		u64 *hwtstamp)
> > +{
> > +	u64 starthw = 0, endhw = 0;
> > +	struct {
> > +		s64 offset;
> > +		s64 duration_sys;
> > +	} samples[100], 
> 
> That should be separately allocated to avoid potential stack overflow.

Good catch. "make checkstack" also complains about it, but I didn't get
around to fixing it yet.

I'd prefer to allocate a very small array on the stack (10 entries = 160
bytes) and only fall back to dynamic allocation if the user of clocksync
wants more samples.

> Also as a style nit there are normally no {} around single line
> statements.

This is the part of the CodingStyle that I had most trouble adapting to
because a) I wrote a lot of code where the required style explicitly
asked for {} and b) I can think of several reasons for adding them
always and only one for not adding them.

Anyway, I'll try to keep this in mind, but would prefer to not reformat
the patches unless I have to touch them for other reasons.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ