Linux x86-32 addr space split

[Mosa Atilles]

I've been testing linux 2.6 kernels from some time on x86 32-bit
machines. But could not quite get the reason behind the need to split
the process address space as 3GB + 1GB (other combinations as well)
between kernel and process-usable ones. Specifically, what is the need
for PAGE_OFFSET?

[Josef Moellers]

Post by Mosa Atilles
I've been testing linux 2.6 kernels from some time on x86 32-bit
machines. But could not quite get the reason behind the need to split
the process address space as 3GB + 1GB (other combinations as well)
between kernel and process-usable ones. Specifically, what is the need
for PAGE_OFFSET?

The advantage is that the kernel will have the current process' address
space as part of its own address space. In a large number of cases, this
makes expensice copies between separate address spaces (user<->kernel)
unnecessary.
Note To stay portable, one should nonetheless use the appropriate
functions/macros when copying between user and kernel space, even if
they will then just to a copy.

[Mosa Atilles]

Post by Josef Moellers
The advantage is that the kernel will have the current process' address
space as part of its own address space. In a large number of cases, this
makes expensice copies between separate address spaces (user<->kernel)
unnecessary.
Note To stay portable, one should nonetheless use the appropriate
functions/macros when copying between user and kernel space, even if
they will then just to a copy.

Thanks Josef. That certainly does reduce a lot of overhead.
But then there is only so much kernel address space to accommodate the
various kernel data structs (pte, vma etc). That in turn constrains the
amount of shared memory that can be mapped into the process addr space.
I guess it's a trade-off in favour of performance.
Thanks again, for imparting that clarity.

[Casper H.S. Dik]

The advantage is that the kernel will have the current process' address=20
space as part of its own address space. In a large number of cases, this =
makes expensice copies between separate address spaces (user<->kernel)=20
unnecessary.

The copies are still necessary, they're just cheaper because you read/write
to the same address space.

Note To stay portable, one should nonetheless use the appropriate=20
functions/macros when copying between user and kernel space, even if=20
they will then just to a copy.

That's not just about portability; referencing user data from the
kernel directly may cause a page fault which won't generally be handled
by the kernel (typically, it won't generate a page fault because system
calls are typically handed data which has just been touched).

When Solaris for UltraSPARC was done, the kernel and userland got
a separate address space as the CPU supports that cheaply. This
flushed out a number of those bugs. If you tried hard, you could
make the kernel panic abusing those bugs before, but nobody noticed
(or they were written of as transient failures)

Casper

[Josef Moellers]

Post by Casper H.S. Dik

The advantage is that the kernel will have the current process' address=20
space as part of its own address space. In a large number of cases, this =
makes expensice copies between separate address spaces (user<->kernel)=20
unnecessary.

The copies are still necessary, they're just cheaper because you read/write
to the same address space.

That's why I wrote "expensive copies". The grouping probably got lost
somwhere between a couple of synapses and the keyboard.

Post by Casper H.S. Dik

Note To stay portable, one should nonetheless use the appropriate=20
functions/macros when copying between user and kernel space, even if=20
they will then just to a copy.

That's not just about portability; referencing user data from the
kernel directly may cause a page fault which won't generally be handled
by the kernel (typically, it won't generate a page fault because system
calls are typically handed data which has just been touched).

ACK. I totally forgot about that.
Blindly copying data between user and kernel address spaces generates
all sorts of problems, not only can a page fault occur, but also the
user might specify some illegal (and dangerous) address.