1.Classroom

maps   Memory maps to executables and library files

Get The Hang

$sudo cat /proc/971/maps
00400000-00408000 r-xp 00000000 08:01 7422174                            /sbin/syslogd
00607000-00608000 rw-p 00007000 08:01 7422174                            /sbin/syslogd
00608000-00609000 rw-p 00000000 00:00 0
01429000-0144a000 rw-p 00000000 00:00 0                                  [heap]
7fd360fa5000-7fd360fb0000 r-xp 00000000 08:01 1466895                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fd360fb0000-7fd3611af000 ---p 0000b000 08:01 1466895                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fd3611af000-7fd3611b0000 r--p 0000a000 08:01 1466895                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fd3611b0000-7fd3611b1000 rw-p 0000b000 08:01 1466895                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fd3611b1000-7fd3611bb000 r-xp 00000000 08:01 1466891                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fd3611bb000-7fd3613ba000 ---p 0000a000 08:01 1466891                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fd3613ba000-7fd3613bb000 r--p 00009000 08:01 1466891                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fd3613bb000-7fd3613bc000 rw-p 0000a000 08:01 1466891                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fd3613bc000-7fd3613d1000 r-xp 00000000 08:01 1466681                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fd3613d1000-7fd3615d0000 ---p 00015000 08:01 1466681                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fd3615d0000-7fd3615d1000 r--p 00014000 08:01 1466681                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fd3615d1000-7fd3615d2000 rw-p 00015000 08:01 1466681                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fd3615d2000-7fd3615d4000 rw-p 00000000 00:00 0
7fd3615d4000-7fd3615db000 r-xp 00000000 08:01 1466617                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fd3615db000-7fd3617da000 ---p 00007000 08:01 1466617                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fd3617da000-7fd3617db000 r--p 00006000 08:01 1466617                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fd3617db000-7fd3617dc000 rw-p 00007000 08:01 1466617                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fd3617dc000-7fd361956000 r-xp 00000000 08:01 1466612                    /lib/x86_64-linux-gnu/libc-2.13.so
7fd361956000-7fd361b56000 ---p 0017a000 08:01 1466612                    /lib/x86_64-linux-gnu/libc-2.13.so
7fd361b56000-7fd361b5a000 r--p 0017a000 08:01 1466612                    /lib/x86_64-linux-gnu/libc-2.13.so
7fd361b5a000-7fd361b5b000 rw-p 0017e000 08:01 1466612                    /lib/x86_64-linux-gnu/libc-2.13.so
7fd361b5b000-7fd361b60000 rw-p 00000000 00:00 0
7fd361b60000-7fd361b7f000 r-xp 00000000 08:01 1466901                    /lib/x86_64-linux-gnu/ld-2.13.so
7fd361d58000-7fd361d5b000 rw-p 00000000 00:00 0
7fd361d7c000-7fd361d7d000 rw-p 00000000 00:00 0
7fd361d7d000-7fd361d7f000 rw-p 00000000 00:00 0
7fd361d7f000-7fd361d80000 r--p 0001f000 08:01 1466901                    /lib/x86_64-linux-gnu/ld-2.13.so
7fd361d80000-7fd361d81000 rw-p 00020000 08:01 1466901                    /lib/x86_64-linux-gnu/ld-2.13.so
7fd361d81000-7fd361d82000 rw-p 00000000 00:00 0
7fff96afb000-7fff96b1c000 rw-p 00000000 00:00 0                          [stack]
7fff96bbc000-7fff96bbd000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed.
Aborted
$

1. mca_disable_dma – channel to disable DMA on

void mca_disable_dma(unsigned int dmanr);
dmanr  DMA channel

2. Classroom

First  of  all,  DMA  (per  se) is  almost  entirely  obsolete.  As
originally defined,  DMA controllers  depended on thefact  that the
bus had  separate lines  to assert for  memory read/write,  and I/O
read/write. The DMA controller  took advantage of that by asserting
both  a memory  read and  I/O  write (or  vice versa)  at the  same
time. The DMA controller then generated successive addresses on the
bus, and  data was read from  memory and written to  an output port
(or vice versa) each bus cycle.

The  PCI bus,  however, does  not  have separate  lines for  memory
read/write and  I/O read/write. Instead,  it encodes one  (and only
one) command for  any given transaction. Instead of  using DMA, PCI
normally does  bus-masteringtransfers. This means instead  of a DMA
controller that transfers memory between the I/O device and memory,
the I/O device itself transfers data directly to or from memory.

As for what else  the CPU can do at the time,  it all depends. Back
when  DMA was  common, the  answer was  usually "not  much"  -- for
example,  under early  versions of  Windows, reading  or  writing a
floppy disk (which  did use the DMA controller)  pretty much locked
up the system for the duration.

Nowadays,  however, the memory  typically has  considerably greater
bandwidth than the  I/O bus, so even while  a peripheral is reading
or writing memory, there's usually  a fair amount of bandwidth left
over for the CPU to use.  In addition, a modern CPU typically has a
fair large cache, so it  can often execute some instruction without
using main memory at all.

source : http://stackoverflow.com/questions/5150719/direct-memory-access-dma-how-does-it-work

1. write_inode_now – write an inode to disk

This  function  commits an  inode  to  disk  immediately if  it  is
dirty. This is primarily needed by knfsd.

1. vfs_lock_file – file byte range lock

2. Manual

 int vfs_lock_file(struct file * filp, unsigned int cmd, struct file_lock * fl, struct file_lock * conf);

 filp
           The file to apply the lock to

       cmd
           type of locking operation (F_SETLK, F_GETLK, etc.)

       fl
           The lock to be applied

       conf
           Place to return a copy of the conflicting lock, if found.

[PATCH] udf: Fix deadlock when converting file from in-ICB one to normal one

During  BKL removal,  conversion  of files  from  in-ICB format  to
normal format got broken.  We call ->writepage with i_data_sem held
but  udf_get_block()  also acquires  i_data_sem  thus creating  A-A
deadlock.

We  fix   the  problem   by  dropping  i_data_sem   before  calling
->writepage() which is safe since i_mutex still protects us against
any  changes in  the  file.  Also fix  pagelock  - i_data_sem  lock
inversion  in   udf_expand_file_adinicb()  by  dropping  i_data_sem
before calling find_or_create_page().

Big Kernel Lock

Linux  contains  a  global   kernel  lock,  kernel_flag,  that  was
originally introduced  in kernel 2.0  as the only SMP  lock. During
2.2 and 2.4, much work went  into removing the global lock from the
kernel and replacing it  with finer-grained localized locks. Today,
the global  lock's use  is minimal. It  still exists,  however, and
developers need to be aware of it.

The global kernel lock is called  the big kernel lock or BKL. It is
a  spinning  lock  that  is recursive;  therefore  two  consecutive
requests for it will not deadlock  the process (as they would for a
spinlock).  Further,  a  process  can  sleep  and  even  enter  the
scheduler while  holding the  BKL. When a  process holding  the BKL
enters the  scheduler, the lock  is dropped so other  processes can
obtain it. These attributes of the BKL helped ease the introduction
of SMP  during the 2.0  kernel series. Today, however,  they should
provide plenty of reason not to use the lock.

source : http://www.linuxjournal.com/article/5833?page=0,2

1. mutex_init

Initialize the mutex to unlocked state.

2. Classroom

The point of a mutex  is to synchronize two threads. When
you  have  two  threads  attempting to  access  a  single
resource, the general pattern  is to have the first block
of  code  attempting  access  to  set  the  mutex  before
entering the  code. When  the second code  block attempts
access,  it sees  the mutex  is set  and waits  until the
first block of code  is complete (and un-sets the mutex),
then continues.

source : http://stackoverflow.com/questions/34524/what-is-a-mutex