Re: How to determine the value of 'current' is valid or not?

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

 



On Tue, May 04, 2004 at 13:14:40 +0900, Tetsuo Handa wrote:
> Hello, Jan.
> 
> Thank you for your reply.
> 
> 
> On Mon, May 03, 2004 at 23:09:38 +0200, Jan Hudec wrote:
> > Every function in fs/*.c has known calling rules that state, whether it
> > can be called in interrupt (either (1) or (2)) context or not. If it
> > can, it must never use current.
> 
> I made hooks (that refer to 'current') inside the following functions.
> 
> fs/exec.c
>     do_execve()

This is the workhorse of exec syscall. It only makes sense in process
context and thus has curent.

>     sys_uselib()

This is a syscall. Syscalls can only be called by processes, thus have
current.

> fs/open.c
>     filp_open()

This is a workhorse of open syscall... It also uses semaphores, which
rules interrupt context out.

>     do_sys_truncate()

-"- of truncate syscall...

>     sys_chroot()

A syscall...

> fs/namei.c
>     open_namei()

Another part of open syscall. In process context only.

>     sys_mknod()
>     sys_mkdir()
>     sys_rmdir()
>     sys_unlink()
>     sys_symlink()
>     sys_link()

Syscalls. Process context only (all of them take i_sem, which is another
reason).

>     do_rename()

Part of syscall. Takes semaphore.

>     link_path_walk()

This function is a helper that resolves paths to dentries. It is always
called in process context, because it calls ->lookup and takes i_sem
(lookup must have i_sem locked). However, when accounting it to
processes, you should notice, that it operates on a cache and as such
uses results, obtained for one process, for other processes too.

> fs/namespace.c
>     sys_mount()

Syscall.

>     sys_pivot_root()

Syscall.

Summary: All of the functions can safely use current without any special
precautions whatsoever. All of them may (and usualy do) sleep, since
they need 

If you look carefuly, they all actualy already access current! They all
may block, and blocking is done by scheduling another process. But that
means you must be in a process, so you can be scheduled back. All of
these function sleep either on a wait_queue (using wait_event macro or
sleep_on function) or lock a semaphore (which uses wait_queue
internaly).

Be sure to find and read a list of things that can't be done in
interrupt context. It is quite restrictive.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Attachment: signature.asc
Description: Digital signature


[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