Learning the core_pattern in linux kernel

The Core Pattern (core_pattern), or how to specify filename and path for core dumps | SIGQUIT

https://sigquit.wordpress.com/2009/03/13/the-core-pattern/

http://forum.odin.com/threads/proc-sys-kernel-core_pattern-permission-denied.338549/

http://www.cathaycenturies.com/blog/?p=1892

http://askubuntu.com/questions/420410/how-to-permanently-edit-the-core-pattern-file

http://stackoverflow.com/questions/12760220/unable-to-create-a-core-file-for-my-crashed-program

Operating Systems: File-System Implementation

A very good writeup on Filesystem Implementation internals:

https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/12_FileSystemImplementation.html

Figure 12.11 – I/O without a unified buffer cache.

Figure 12.12 – I/O using a unified buffer cache.

• Page replacement strategies can be complicated with a unified cache, as one needs to decide whether to replace process or file pages, and how many pages to guarantee to each category of pages. Solaris, for example, has gone through many variations, resulting in priority paging giving process pages priority over file I/O pages, and setting limits so that neither can knock the other completely out of memory.
• Another issue affecting performance is the question of whether to implement synchronous writes or asynchronous writes. Synchronous writes occur in the order in which the disk subsystem receives them, without caching; Asynchronous writes are cached, allowing the disk subsystem to schedule writes in a more efficient order ( See Chapter 12. ) Metadata writes are often done synchronously. Some systems support flags to the open call requiring that writes be synchronous, for example for the benefit of database systems that require their writes be performed in a required order.
• The type of file access can also have an impact on optimal page replacement policies. For example, LRU is not necessarily a good policy for sequential access files. For these types of files progression normally goes in a forward direction only, and the most recently used page will not be needed again until after the file has been rewound and re-read from the beginning, ( if it is ever needed at all. ) On the other hand, we can expect to need the next page in the file fairly soon. For this reason sequential access files often take advantage of two special policies:
  • Free-behind frees up a page as soon as the next page in the file is requested, with the assumption that we are now done with the old page and won’t need it again for a long time.
  • Read-ahead reads the requested page and several subsequent pages at the same time, with the assumption that those pages will be needed in the near future. This is similar to the track caching that is already performed by the disk controller, except it saves the future latency of transferring data from the disk controller memory into motherboard main memory.
• The caching system and asynchronous writes speed up disk writes considerably, because the disk subsystem can schedule physical writes to the disk to minimize head movement and disk seek times. ( See Chapter 12. ) Reads, on the other hand, must be done more synchronously in spite of the caching system, with the result that disk writes can counter-intuitively be much faster on average than disk reads.

Linux kernel memory exploitation via PTE

http://slideplayer.com/slide/9160576/

An introduction to KProbes LWN.net

https://lwn.net/Articles/132196/

This article answer the question:

How does kprobe worked?

How does jprobe worked?

Where in the kernel source is kprobe and jprobe detected and handled?

What is the hardware mechanisms used for probing?