Sponsored Content
Top Forums UNIX for Dummies Questions & Answers Kernel Stack vs User Mode Stack Post 302586912 by ygemici on Tuesday 3rd of January 2012 03:54:52 PM
Old 01-03-2012
Quote:
Originally Posted by saurabhkoar
@fpmurphy,

That means in Linux each process has a user mode stack and a corresponding Kernel mode stack? So, there is two stacks per process?
actually they are used on the separate [cpu processing] modes.
and in this state lets we split to as modes(user/kernel) for better understanding of its.
shortly,linux process can operates in two modes:

* in user_mode
any process which runs the in user mode refers to private(own) stack area that is used for holds local variables,parameters,frame pointer(very useful while detect relative addres of any func local variables after pushes,pops especially in debug processing[kernel oops]),temporary(as a cpy) values(like in c,c++,java),return address from funcs and automatic variables within functions.

* in kernel mode (after switching to kernel mode by [switch_to] ), portion of the process (code areas),its addresses and core kernel data, starts to use the kernel stack.
[as additonal infos; hardware context informations(like contents of all registers in user mode) also are saved in the kernel stack while the hardware context processing]

linux kernel has many complex structures like kernel control path that is sequence of instructions(* executed several kernel functions) executed by a kernel for an interrupt,system call or exception handling.
so these instructions are belonging to different processes.therefore each kernel path must refers to its kernel stack(8k)
[actually 8140 bytes 52 byte save for thread_info structure]
you can define the size of kernel stacks while compaling if you see the like this message
Code:
Use 4Kb for kernel stacks instead of 8Kb (4KSTACKS) [N/y/?] n

and user mode process can not know where is the address of own kernel stack memory area; (pointer) address, therefore cannot accessed to kernel stack area in the user mode.

while switching to kernel mode with mode switch,process will continue to work in the reentrance kernels.
so it is a reentrance kernel! user mode process executions can be resume in kernel mode and continues processing for new processes by kernel schedulers.[assisgns the another Cpu to the process with schedule()]
but on a single processor system,one process will be process in the Cpu and new processes blocked until the current process turn.

I would recommend for more information below usefull links..
Understanding the Linux Kernel, 3rd Edition
4K Stacks in 2.6 [LWN.net]

regards
ygemici
 

7 More Discussions You Might Find Interesting

1. Programming

User Frame & Stack

Can anybody tell me what a user frame & stack looks like on a sun, hp, powerpc system? (0 Replies)
Discussion started by: John Budnik
0 Replies

2. Programming

what is stack winding and stack unwinding

helo can u tell me what do you mean by stack winding and stack unwinding Regards, Amit (2 Replies)
Discussion started by: amitpansuria
2 Replies

3. Solaris

How to set stack for Oracle's user?

Hi all! I've got a problem. Primary: Sun Sparc V890, 64bit Standby: HP-Proliant ML 350, 64bit In the machine that I've got configured physical standby database, the alert_log_file point me one error: Sat Feb 28 00:40:08 2009 ORA-00202: control file:... (5 Replies)
Discussion started by: trantuananh24hg
5 Replies

4. SCO

SCO Openserver Kernel and network stack

Hi everybody My SCO 5.0.2 OpenServer got its kernel corruptions and network stack was accicentially deleted. I would like to know if we have any chance to rebuild its kernel and network stack. Any help will be great thankfully appreciate TN (1 Reply)
Discussion started by: TinhNhi
1 Replies

5. Programming

which function copies data from user to kernel mode

when transitionaning from user to kernel mode which function copies data from user mode buffer to kernel mode? (5 Replies)
Discussion started by: rupeshkp728
5 Replies

6. UNIX for Dummies Questions & Answers

View User Mode Call Stack of Hung Process

I have a multithreaded usermode program(actually a daemon) which is in hanged state. To debug it I tried attaching the process to gdb, but the gdb hangs. gstack also gets hanged. I peeped into the proc file system and saw the process to be in sleeping state. /proc/sysrq-trigger I guess... (1 Reply)
Discussion started by: rupeshkp728
1 Replies

7. Red Hat

Cannot set 'soft limits' for 'maximum stack size' for a standard user

Hi Guys, I'm trying to install Oracle Database on to Oracle Linux 7.6 but when the database install package checks the OS set-up, it keeps on failing on the soft limits for the stack. It's default value is 8192 but I'm trying to set it to 10240. This is what I added to... (2 Replies)
Discussion started by: ASGR
2 Replies
SIGRETURN(2)						     Linux Programmer's Manual						      SIGRETURN(2)

NAME
sigreturn, rt_sigreturn - return from signal handler and cleanup stack frame SYNOPSIS
int sigreturn(...); DESCRIPTION
If the Linux kernel determines that an unblocked signal is pending for a process, then, at the next transition back to user mode in that process (e.g., upon return from a system call or when the process is rescheduled onto the CPU), it creates a new frame on the user-space stack where it saves various pieces of process context (processor status word, registers, signal mask, and signal stack settings). The kernel also arranges that, during the transition back to user mode, the signal handler is called, and that, upon return from the han- dler, control passes to a piece of user-space code commonly called the "signal trampoline". The signal trampoline code in turn calls sigreturn(). This sigreturn() call undoes everything that was done--changing the process's signal mask, switching signal stacks (see sigaltstack(2))--in order to invoke the signal handler. Using the information that was earlier saved on the user-space stack sigreturn() restores the process's signal mask, switches stacks, and restores the process's context (processor flags and registers, including the stack pointer and instruction pointer), so that the process resumes execution at the point where it was interrupted by the signal. RETURN VALUE
sigreturn() never returns. CONFORMING TO
Many UNIX-type systems have a sigreturn() system call or near equivalent. However, this call is not specified in POSIX, and details of its behavior vary across systems. NOTES
sigreturn() exists only to allow the implementation of signal handlers. It should never be called directly. (Indeed, a simple sigreturn() wrapper in the GNU C library simply returns -1, with errno set to ENOSYS.) Details of the arguments (if any) passed to sigreturn() vary depending on the architecture. (On some architectures, such as x86-64, sigreturn() takes no arguments, since all of the information that it requires is available in the stack frame that was previously created by the kernel on the user-space stack.) Once upon a time, UNIX systems placed the signal trampoline code onto the user stack. Nowadays, pages of the user stack are protected so as to disallow code execution. Thus, on contemporary Linux systems, depending on the architecture, the signal trampoline code lives either in the vdso(7) or in the C library. In the latter case, the C library's sigaction(2) wrapper function informs the kernel of the location of the trampoline code by placing its address in the sa_restorer field of the sigaction structure, and sets the SA_RESTORER flag in the sa_flags field. The saved process context information is placed in a ucontext_t structure (see <sys/ucontext.h>). That structure is visible within the signal handler as the third argument of a handler established via sigaction(2) with the SA_SIGINFO flag. On some other UNIX systems, the operation of the signal trampoline differs a little. In particular, on some systems, upon transitioning back to user mode, the kernel passes control to the trampoline (rather than the signal handler), and the trampoline code calls the signal handler (and then calls sigreturn() once the handler returns). C library/kernel differences The original Linux system call was named sigreturn(). However, with the addition of real-time signals in Linux 2.2, a new system call, rt_sigreturn() was added to support an enlarged sigset_t type. The GNU C library hides these details from us, transparently employing rt_sigreturn() when the kernel provides it. SEE ALSO
kill(2), restart_syscall(2), sigaltstack(2), signal(2), getcontext(3), signal(7), vdso(7) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2017-09-15 SIGRETURN(2)
All times are GMT -4. The time now is 10:37 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy