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

Topic

PXE Boot

Explanation

The Preboot eXecution Environment (PXE, also known as Pre-Execution
Environment;  sometimes pronounced  "pixie") is  an  environment to
boot  computers using  a  network interface  independently of  data
storage devices  (like hard disks) or  installed operating systems.
PXE was introduced as part of the Wired for Management framework by
Intel and is described in the specification (version 2.1) published
by Intel and  Systemsoft on September 20, 1999.[1]  It makes use of
several  network  protocols   like  Internet  Protocol  (IP),  User
Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP)
and  Trivial File  Transfer Protocol  (TFTP) and  of  concepts like
Globally  Unique Identifier  (GUID), Universally  Unique Identifier
(UUID)  and  Universal Network  Device  Interface  and extends  the
firmware of  the PXE  client (the computer  to be  bootstrapped via
PXE) with  a set  of predefined Application  Programming Interfaces
(APIs).


The PXE protocol  is approximately a combination of  DHCP and TFTP,
albeit with  subtle modifications to  both. DHCP is used  to locate
the appropriate boot server or  servers, with TFTP used to download
the initial bootstrap program  and additional files.  To initiate a
PXE bootstrap  session the  PXE firmware broadcasts  a DHCPDISCOVER
packet extended  with PXE-specific options  (extended DHCPDISCOVER)
to port  67/UDP (DHCP  server port). The  PXE options  identify the
firmware as  capable of PXE, but  they will be  ignored by standard
DHCP  servers.  If  the  firmware  receives  DHCPOFFERs  from  such
servers, it may  configure itself by requesting one  of the offered
configurations.

source : http://en.wikipedia.org/wiki/Preboot_Execution_Environment

Get The Hang

 // next, check what the packet type was
        opt = request(43,71);
        if(opt == NULL)
        {
                logger->Event(LEVEL_INFO, "MakeReply", 1,
                  "Received proxy DHCP packet");
                pkttype = 1;
        }
        else
        {
                delete[] opt->data;
                delete opt;
                logger->Event(LEVEL_INFO, "MakeReply", 1,
                  "Received PXE request packet");
                pkttype = 2;
        }

$time php bubble.php

real	0m7.404s
user	0m7.012s
sys	0m0.080s
$time php bubble.php

real	0m7.333s
user	0m7.044s
sys	0m0.068s
$time php bubble.php

real	0m7.393s
user	0m7.068s
sys	0m0.100s
$time php bubble.php

real	0m7.345s
user	0m7.024s
sys	0m0.104s
$time php bubble.php

real	0m7.545s
user	0m7.224s
sys	0m0.080s
$time php bubble.php

real	0m7.275s
user	0m6.992s
sys	0m0.072s
$time php bubble.php

real	0m7.340s
user	0m7.044s
sys	0m0.072s
$