Heading 1

HIGH MEM
 Memory above the physical address of 896MB are temporarily mapped into kernel virtual memory
whenever the kernel needs to access that memory.
 Data which the kernel frequently needs to access is allocated in the lower 896MB of memory
(ZONE_NORMAL) and can be immediately accessed by the kernel .
 Data which the kernel only needs to access occasionally, including page cache, process memory and
page tables, are preferentially allocated from ZONE_HIGHMEM.
 The system can have additional physical memory zones to deal with devices that can only perform DMA
to a limited amount of physical memory, ZONE_DMA and ZONE_DMA32.
 The temporary mapping of data from highmem into kernel virtual memory is done using the functions
kmap(), kunmap(), kmap_atomic() and kunmap_atomic().
 The function kmap() gives you a persistant mapping, ie. one that will still be there after you schedule
and/or move to another CPU. However, this kind of mapping is allocated under a global lock, which can
be a bottleneck on SMP systems. The kmap() function is discouraged.
 The reason for this is that applications might want to use all 2GB of memory. If the system ended up
allocating and reclaiming high memory much faster than low memory, then the application would have
part of its data swapped out from high memory, instead of resident in low memory. However, the better
the system balances allocations and recycling between high and low memory, the closer the
application's effective available memory size approaches the full 2GB.

MEMORY PRESSURE
 How do you tell you are under memory pressure? Look for the entries in /proc/vmstat. Virtually all the entries
that say "scan" in them are reacting to memory pressure. These counters also have per-zone counterparts in
/proc/zoneinfo.

Drop Cache
 To free pagecache 1
 To free dentries and inodes 2 echo $val > /proc/sys/vm/drop_caches
 To free pagecache, dentries and inodes 3

Forking
 fork() -> do_fork() -> copy_process(). This Copy_Process is defined
as /*
* This creates a new process as a copy of the old one,
* but does not actually start it yet.
*
* It copies the registers, and all the appropriate
* parts of the process environment (as per the clone
* flags). The actual kick-off is left to the caller.
*/

System Call
 System call implementation link : https://lkml.org/lkml/2016/3/31/1109 ,
http://blog.techveda.org/adding-system-calls-linux-kernel-3-5-x/

Heading
 Find file with particular extension and change it permission:
find . -type f -name '*.sh' | args chmod +x 755

Queries/Answer
On Thu, Mar 10, 2016 at 02:59:31PM +0530, Chetan Nanda wrote:
> Hi,
>
> As per book (Linux kernel development)
>
> "Whoever locked a mutex must unlock it.That is, you cannot lock a mutex
in one
> context and then unlock it in another
> "
> but 'mutex_unlock' code is not checking the owner field at all.

If you look at the definition of mutex structure in mutex.h:50,

you'll see that the owner field will be compiled in if one of
CONFIG_DEBUG_MUTEXES or CONFIG_MUTEX_SPIN_ON_OWNER is defined.

And debug_mutex_unlock function in mutex-debug.c:72 will check

the owner and emits warning if it finds out that the mutex isn't
unlocked by its owner.

http://lxr.free-electrons.com/source/include/linux/mutex.h#L50
http://lxr.free-electrons.com/source/kernel/locking/mutex-debug.c#L72

>
> Also, I tried with locking the mutex from normal process context and
> unlocking from separate context (work context) and it is allowed
> without any error from kernel.
>
> Is it the mutex user responsibility to keep track of it? Ideally
> mutex_unlock should check if owner is same as current?

-------------------------------------------------------FINISH----------------------------------------------------------------------
> Hello,
>
> While reading a section in Linux Kernel Development, I came across the
> following:
>
> "If process context code and a bottom half share data, you need to
> disable bottom-half processing and obtain a lock before accessing the
> data."
>
> Why is this the case? Can one not disable/lock the process context
> code instead of the bottom-half and access data?

You need to do it in both.

You need to grab the lock in BH in case other threads also calls the same
syscall. You need to lock in from user process context to avoid being
interrupted and having a BH walk in and update the data.

A Thread
|
do_something()
do_a_syscall()
// update a var in kernel, but on behalf of thread
read shared var A
* Interrupt *
irq_entry
// ack interrupt, do critical stuff
 // trigger softirq do the rest
irq_exit
softirq_entry
Update shared var A
softirq_exit

(now back in thread A, inside kernel)

write old value of A back // updated A from softirq now lost!

> Similarly, for the statement,

>
> "If interrupt context code and a bottom half share data, you need to
> disable interrupts and obtain a lock before accessing the data."
>
> Any help in clarifying this would be much appreciated.

Same as for userprocess vs. BH, an ISR can interrupt a BH and update data
unless you have disabled interrupt.

HTH,

--
Henrik Austad

-------------------------------------------------------FINISH----------------------------------------------------------------------
>How does __user macro works? I know it is defined in
>include/linux/compiler.h as:
># define __user. __attribute__((noderef, address_space(1)))
>I could write thesse macros defs too but my real problem is: what does
>this
>stuff do? Some functions use this macro and other does not. For example
>compat_do_execve (from include/linux/comtap.h) use normal pointer named
>filename and second pointer named argv as __user pointer. Why does argv
>needs __user but filename not?

In the kernel, some memory is the user-space memory (which can be

swapped out and - therefore - shouldn't dereferenced directly) and some
of it is kernel-space memory (which is always in real RAM).
That macro tells static checkers in which of those the pointer points to
so that errors are compile-time visible.
-------------------------------------------------------FINISH----------------------------------------------------------------------
>what is the relation between page-cache and file operation?
file operations for data access like read/write will look into page-cache
first before going to disk.
-------------------------------------------------------FINISH----------------------------------------------------------------------
Default read/write inerfaces are better suited for sequential read/write
within your program. Although you can seek to any location within the file,
you still have overhead to issue system calls to get data. However mmap
allows you to map a section of file into program address space. Now if your
access patter is rather random, modifying few bytes here and there, but at
random offset. You just get continous memory array, which is much easier
than issuing read and write at different file offsets.

A most common and mandatory use case of mmap is in mapping executable

binary program image, and libraries into process address spaces. Access
pattern for a program is not sequential, you can have multiple jump (if,
else, for loop), so it is better suited with mmap. It is read only and
private memory mapping, Any modifications you do will create a COW page
which if private to your process, so that is another advantage of mmap
which is completely transparent to user mode. If your filesystem does not
support, this basic mmap mode, you can not execute a binary file stored in
this filesystem, unless you copy it to some other filesystem which does.

Apart from this, read more about mmap from UTLK book.
-------------------------------------------------------FINISH----------------------------------------------------------------------

> Export symbol after studying kBuild.

Sometimes, an external module uses exported symbols from
another external module. kbuild needs to have full knowledge of
all symbols to avoid spliitting out warnings about undefined
symbols. Three solutions exist for this situation.

Use a top-level kbuild file

If you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout:

./foo/ <= contains foo.ko

./bar/ <= contains bar.ko

The top-level kbuild file would then look like:

#./Kbuild (or ./Makefile):

obj-y := foo/ bar/

And executing

$ make -C $KDIR M=$PWD

will then do the expected and compile both modules with

full knowledge of symbols from either module.

Use an extra Module.symvers file

When an external module is built, a Module.symvers file
is generated containing all exported symbols which are
not defined in the kernel. To get access to symbols
from bar.ko, copy the Module.symvers file from the
compilation of bar.ko to the directory where foo.ko is
built. During the module build, kbuild will read the
Module.symvers file in the directory of the external
module, and when the build is finished, a new
Module.symvers file is created containing the sum of
all symbols defined and not part of the kernel.

Use "make" variable KBUILD_EXTRA_SYMBOLS

If it is impractical to copy Module.symvers from
another module, you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.
-------------------------------------------------------FINISH----------------------------------------------------------------------
> I allocate memory in my driver and I passed this address to my HW
> register to write to. My question is when the HW done writing (my
> driver get notified by an interrupt). How can I flush the cache so
> that my driver can see what has been written by the HW?
>
There are some basic problems in your design.

If you are using external agents like DMA( or any other HW capable of
writing to DDR), do not cache Memory.
Because if you do, your processor will cache the memory and will not see
the updates done by external agents.
If you want to maintain coherency, allocate memory using
dma_allocate_coherent.

-------------------------------------------------------FINISH----------------------------------------------------------------------

mount -t vboxsf Shared_Folder /media/shared/

diff -r dir1 dir2 | grep dir1 | awk '{print $4}' > difference1.txt
du –sh folder name