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() respectivel
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 am looking at the 4.3-stable code
Hi!
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_next
: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
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
:
: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.
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,
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
--- 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
(
>
> --- 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
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.
:
:
: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
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
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
--- 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
--- 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
fault land in a
hurry.
On Fri, 27 Jul 2001, 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
> e
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
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
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
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
>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:
>
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:
> 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
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 t
what is the reason of
keeping kernel stack size so small ? I understand there should be no
need in huge stack, but why so damn small ? Would someone explain please ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
PCB
> > to catch overruns.
>
> Maybe I'm just dumb, but I still don't understand, what is the reason of
> keeping kernel stack size so small ? I understand there should be no
> need in huge stack, but why so damn small ? Would someone explain please ?
>
> Regar
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
Hi
We have implemented a device driver on FreeBSD 4.0 and x86 architecture.
The device driver has routines for servicing I/O requests. I understand
that these routines run in the top part of the kernel stack.
The routines have a nesting of 10-12 functions having 10-100 lines each.
Could you tell
> Hi
>
> We have implemented a device driver on FreeBSD 4.0 and x86 architecture.
> The device driver has routines for servicing I/O requests. I understand
> that these routines run in the top part of the kernel stack.
>
> The routines have a nesting of 10-12 functions having 10-100 lines each.
On Thu, 30 Nov 2000, Mike Smith wrote:
> > The routines have a nesting of 10-12 functions having 10-100 lines each.
> > Could you tell us what is the minimum available run time memory in the
> > per-process kernel stack for running these routines?
> You can generally assume that you have about
31 matches
Mail list logo
