In message <[EMAIL PROTECTED]> Julian
Elischer writes:
: We may go to 2 pages but really 1 page is enough as long as people
: don't store structures on the stack. It's been kept small to keep the
: overhead of processes and threads down. When we get threads (KSE) we may
: have theoretically thou
We may go to 2 pages but really 1 page is enough as long as people
don't store structures on the stack. It's been kept small to keep the
overhead of processes and threads down. When we get threads (KSE) we may
have theoretically thousands more of these, on potentially smaller boxes..
The main po
> In 5-0-KSE there is a single page that contains the stack and
> the PCB (which is about 660 bytes). We are also looking at adding
> code to set a hardware watchpoint between the stack and the PCB
> to catch overruns.
Maybe I'm just dumb, but I still don't understand, what is the reason of
keep
Weiguang SHI wrote:
>
> A closer look at the code /usr/src/sys/i386/i386/locore.s astonished
> me with the fact that the kernel stack size for a process, at least
> for process 0, is 2*4096-sizeof(struct user) = 3988 bytes, less than
> even one page.
>
> Anyone to verify this, please?
> BTW, I a
> I'm developing some code running in kernel that use a lot of stack. And it
> seems i run into stack overflow. This results in some proc structure
> related parts overwrite (particulary p->p_stats->p_timer[ITIMER_PROF]) and
> unexpected signals. (Otherwise, it usually page faults inside
> swi_net
CTED]>
> >To: "Semen A. Ustimenko" <[EMAIL PROTECTED]>
> >CC: [EMAIL PROTECTED]
> >Subject: Re: Kernel stack size
> >Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT)
> >
> >
> >
> >On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
>From: Julian Elischer <[EMAIL PROTECTED]>
>To: "Semen A. Ustimenko" <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Kernel stack size
>Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT)
>
>
>
>On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
>
Julian Elischer wrote:
>
> the kernel stack is a VERY LIMITED resource
> basically you have about 4 or 5 Kbytes per process.
> if you overflow it you write over your signal information..
>
> you should MALLOC space and use a pointer to it..
Would adding an unmapped or read-only guard page be
un
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
> Hi! Thanks for light speed response!
>
> On Tue, 7 Aug 2001, Julian Elischer wrote:
>
> > the kernel stack is a VERY LIMITED resource
> > basically you have about 4 or 5 Kbytes per process.
> Oops... And there is no hope to enlarge it?
none rea
Hi! Thanks for light speed response!
On Tue, 7 Aug 2001, Julian Elischer wrote:
> the kernel stack is a VERY LIMITED resource
> basically you have about 4 or 5 Kbytes per process.
Oops... And there is no hope to enlarge it?
> if you overflow it you write over your signal information..
>
That's
the kernel stack is a VERY LIMITED resource
basically you have about 4 or 5 Kbytes per process.
if you overflow it you write over your signal information..
you should MALLOC space and use a pointer to it..
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
> Hi!
>
> I'm developing some code runnin
The kernel will grow the size of the userland stack if need be.
Look for vm_map_growstack().
Also just a FYI that size sounds about right for the kernel stack. Be
very careful not to use function recursion or to many on the stack large
sized variables or else youll blow yourself into double faul
--- Matt Dillon <[EMAIL PROTECTED]> wrote:
> You can theoretically increase UPAGES in
> /usr/src/sys/i386/include/param.h
I increased UPAGES from 2 to 8 and everything seems to
be working as it should. The device in question will
very much be a dedicated IPsec device and will not be
running t
--- Julian Elischer <[EMAIL PROTECTED]> wrote:
> Why are you not using the netgraph system, which was
> specifically
> designed
> for this? it allows you to divert eherne packets
When we started on this, (~2years ago) I was not aware
of the netgraph functionality. I agree that it would
be better
Jacques Fourie wrote:
>
> Hi
>
> Please excuse any silly questions, but I am stuck with
> a problem that I can't find the answer for.
>
> I wrote a KLD module that performs encryption on
> network packets in the kernel. Packets are intercepted
> for encryption on a ethernet level (in ether_inpu
Jacques Fourie wrote:
>
> Would it be possible to pre-allocate a block of memory
> and then "switch" stacks in my interrupt routine? This
> may be far off, but my only other option is going
> through ~1 lines of code and examining all places
> where local variables are declared. If I could so
:
:
:Would it be possible to pre-allocate a block of memory
:and then "switch" stacks in my interrupt routine? This
:may be far off, but my only other option is going
:through ~1 lines of code and examining all places
:where local variables are declared. If I could somehow
:do this in a diffe
First of all, I would like to say a big thanks for all
of the replies I got so far. I really appreciate it.
Here is a more detailed description of what the code
does. It is for a commercial IPsec product. I know
that IPsec is available in FreeBSD, but this started
long before KAME was available.
>
> --- Warner Losh <[EMAIL PROTECTED]> wrote:
>
> > 10k lines in an interrupt routine sounds to be way
> > more work than you
> > want to do in an interrupt routine. Maybe you could
> > use a work queue
> > and deal with it that way. There isn't much I can
>
> The ~10k lines of code is in a
--- Warner Losh <[EMAIL PROTECTED]> wrote:
> 10k lines in an interrupt routine sounds to be way
> more work than you
> want to do in an interrupt routine. Maybe you could
> use a work queue
> and deal with it that way. There isn't much I can
The ~10k lines of code is in a software interrupt
(
In message <[EMAIL PROTECTED]> Jacques Fourie writes:
: Would it be possible to pre-allocate a block of memory
: and then "switch" stacks in my interrupt routine? This
: may be far off, but my only other option is going
: through ~1 lines of code and examining all places
: where local variable
Would it be possible to pre-allocate a block of memory
and then "switch" stacks in my interrupt routine? This
may be far off, but my only other option is going
through ~1 lines of code and examining all places
where local variables are declared. If I could somehow
do this in a different way,
:
:Hi
:
:Thanks for your reply. I have two other questions
:regarding this matter.
:
:Would it be possible to extend the kernel stack?
:The reason is that some of the crypto and hashing
:algorithms use relatively large contexts which for
:performance reasons are currently allocated on the
:stack.
Hi
Thanks for your reply. I have two other questions
regarding this matter.
Would it be possible to extend the kernel stack?
The reason is that some of the crypto and hashing
algorithms use relatively large contexts which for
performance reasons are currently allocated on the
stack.
If this is
:Hi
:
:Please excuse any silly questions, but I am stuck with
:a problem that I can't find the answer for.
:
:I wrote a KLD module that performs encryption on
:network packets in the kernel. Packets are intercepted
:for encryption on a ethernet level (in ether_input()
:and ether_output_frame() re
25 matches
Mail list logo
