Date: Wed, 30 Jan 2008 16:58:48 -0800 From: Sam Leffler <sam@errno.com> To: Alexander Motin <mav@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys proc.h Message-ID: <47A11D48.9040909@errno.com> In-Reply-To: <47A0F6CE.3020407@FreeBSD.org> References: <200801302124.m0ULOANe012024@repoman.freebsd.org> <47A0EDC4.3040301@errno.com> <47A0F6CE.3020407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin wrote:
> Sam Leffler wrote:
>> Alexander Motin wrote:
>>> mav 2008-01-30 21:24:10 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>> sys/sys proc.h Log:
>>> Implement GET_STACK_USAGE() macro to get the current kernel thread
>>> stack usage.
>>> This implemntation made for growing down stack organization like
>>> i386/amd64
>>> platforms have, but prefers different machine dependent version if
>>> it is present.
>>
>> I think it is a mistake to fallback to a MD implementation; your MI
>> implementation is broken on architectures that do not use the model
>> you used so you any user of this will silently fail on such
>> architectures. I suggest you need to fix this before you use this
>> macro in any MI code.
>
> This implementation covers the most of popular architectures. The only
> architecture with different stack organization recalled in maillist
> was ia64 which has two stacks with local variables part is still
> growing down. As I have no work experience with architectures other
> then i386/amd64 I will gladly accept any help with implementing this.
>
> This time I am going to use this as a hint for stack protection engine
> in netgraph subsystem. In case of incorrect implementation there could
> be only two consequences: or nothing will change from present state
> for stack growing down, but differently (ia64). or protection become
> paranoid but slow for stack growing up.
>
Your change guarantees code will silently break at some point in time
(almost certainly long after anyone remembers this email exchange).
Just because you don't have a system where this fails doesn't justify
adding a hack like this. I repeat, please fix it or remove it before
anyone uses it. My suggestion is you make this MD and on architectures
where you haven't tested it you add a #error.
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A11D48.9040909>