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