Questions about task, thread, and tss _struct

Questions about task, thread, and tss _struct

Post by Brian Gers » Sun, 23 Sep 2001 05:20:11

> I have a few points of confusion, and I would deeply appreciate any
> clarifications. They concern the three primary structures task_struct,
> thread_struct, and tss_struct. (in kernel 2.4.x)

task_struct contains architecture independant process information.
thread_struct contains architecture dependant process information.
tss_struct is x86-specific, defined by the hardware.

Quote:> 1) I am having a difficult time understanding how tss_struct could be moved
> out of task_struct (per process basis, as one would expect) to a statically
> allocated array (per CPU basis, ???). How can these registers be saved
> across context switches, when there are only as many such structures as
> there are CPUs? I did not follow the explanation in UTLK.

The TSS (Task State Segment) structure is defined by the processor for
hardware task switching.  Earlier versions of Linux on the x86 used one
TSS for each process and used hardware task switching.  This effectively
limited the number of processes to about 500.  We now have one TSS per
cpu, and do software task switching.

Quote:> 2) Why the multiple stack pointers and stack segments in tss_struct?

The x86 architecture has 4 priviledge levels (aka rings), with Linux
only using ring 3 (user) and ring 0 (kernel).  When moving to a higher
privilege level (smaller numerically), a new stack pointer is loaded
fron the corresponding pointer in the TSS.

Quote:> 3) What is esp0 in thread_struct?

The kernel stack pointer for the current process.  This is copied into
tss->esp0 when the process becomes current on a cpu.

Quote:> 4) What are the members suffixed with 'h' in tss_struct? I thought they were
> the segment shadow registers until I saw the member __ldth, because I didn't
> believe that ldt had a shadow register.

Segment registers are only 16 bits.  the __*h values are the high 16
bits that are filler.

Quote:> 5) Is there a particular reason for the double underscore convention
> prefixing certain members?

To avoid any namespace collisions.

I suggest that you read the Intel documentation:
In particular Chapter 6 Task Management


                                Brian Gerst
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at


1. fs/locks.c: Fix posix locking for threaded tasks

Saurabh Desai believes that locks created by threads should not conflict
with each other.  I'm inclined to agree; I don't know why the test for
->fl_pid was added, but the comment suggests that whoever added it wasn't
sure either.

Frankly, I have no clue about the intended semantics for threads, and
SUS v3 does not offer any enlightenment.  But it seems reasonable that
processes which share a files_struct should share locks.  After all,
if one process closes the fd, they'll remove locks belonging to the
other process.

Here's a patch generated against 2.4; it also applies to 2.5.
Please apply.

===== fs/locks.c 1.9 vs edited =====
--- 1.9/fs/locks.c      Mon Jun  3 18:49:43 2002


- * Check whether two locks have the same owner
- * N.B. Do we need the test on PID as well as owner?
- * (Clone tasks should be considered as one "owner".)
+ * Locks are deemed to have the same owner if the tasks share files_struct.
 static inline int
 locks_same_owner(struct file_lock *fl1, struct file_lock *fl2)
-       return (fl1->fl_owner == fl2->fl_owner) &&
-              (fl1->fl_pid   == fl2->fl_pid);
+       return (fl1->fl_owner == fl2->fl_owner);

 /* Remove waiter from blocker's block list.

Revolutions do not require corporate support.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at

2. "talking" to a "real" phone via a modem?

3. C++ task == C thread ?

4. Which OS?

5. thread, task and process

6. Tracking anonymous FTP

7. Matrox Mystique ands X.

8. VIM Toolbar missing

9. Task and Thread

10. Q: programs to switch task threads in LUNIX.

11. Question: IO on one thread blocks other threads wanting to do IO?

12. Threads, threads, threads

13. Task States; can't kill 'D' tasks