why set_fs (was "socket programming in kernel space")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Fawaad

>     * get_fs returns the current segment descriptor stored in FS.
>     * get_ds returns the segment descriptor associated to kernel
> space, currently stored in DS.
>     * set_fs stores a descriptor into FS, so it will be used for data
> transfer instructions.

I do quick check on Redhat 9 stock kernel (2.4.20-19.9), I saw these 
codes:
#define MAKE_MM_SEG(s)  ((mm_segment_t) { (s) })

#define KERNEL_DS       MAKE_MM_SEG(0xFFFFFFFF)
#define USER_DS         MAKE_MM_SEG(PAGE_OFFSET)

#define get_ds()        (KERNEL_DS)
#define get_fs()        (current->addr_limit)
#define set_fs(x)       (current->addr_limit = (x))

What I see here, get_fs() yields the upper limit of user space address 
limit (that is 3GB on 3G/1G VM split). So, set_fs is temporarily set to 
KERNEL_DS because IMHO procedure that handles socket operations (e.g 
sys_socket) assumes the data come from user space. Since we do it in 
kernel space and therefore might allocate something (e.g via kmalloc) 
and then pass them to those procedure, it will trigger segmentation 
fault unless we set the address limit temporarily to 0xFFFFFFFF.

I don't know about the history related with these set_fs/get_fs, so 
someone please CMIIW

regards

Mulyadi


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux