- Your name: Ronit Halder
- FAS Account: Ronit
- Fedora userpage: https://fedoraproject.org/wiki/User:Ronit
- Email Address: ronit.crj@gmail.com
- Blog URL: rcodin.github.io
- Freenode IRC Nick: ronith
Questions to answer
Why do you want to work with the Fedora Project?
I am using Fedora for some time. The thing different about fedora is that it keeps the software packages up to date and it's stable. This is main reason for me choosing fedora as a linux distribution. Fedora community consists of experienced redhat employees and volunteers.This community provides opportunity work with and learn from great people. I already felt that by talking to the mentor of the project idea.
Do you have any past involvement with the Fedora project or any other open source project as a contributor?
I don't have any involvement with Fedora Project till now. I contributed to linux kernel. I have done some bug fixes in staging tree.
Did you participate with the past GSoC programs, if so which years, which organizations?
Not yet but I'm looking forward to work with Fedora.
Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with?
Yes. It is not possible to implement the whole project idea mentioned in the idea page in 3 months. I will leave out some less important parts which I'll finish after summer. Also I would love to maintain Tinykdump in future.
Why should we choose you over other applicants?
- I am enthusiastic, tenacious and hard working.
- I have done bug fixes in the mainline kernel and have also completed the eudyptula challenge, theses activities have given me hands-on experience and exposure on the practical nuances and complexities of efficient kernel programming. I have read some of the essential textbooks, documentation and online resources(mainly lwn.net) on linux kernel programming which have made my fundamentals strong. This project needs good amount of linux kernel programming knowledge. Also I have familiarity with the codebase of current kdump tool and dracut.Tinykdump is fundamentally similar to fedora's kdump tool also some part of dracut can be used in Tinykdump.
- I am very interested in this project. I am learning about linux kernel for last 1 year. Now I want to implement something. By this project I can fulfill my dream.
- I am fascinated to learn new algorithms. I have experience in competitive coding (codechef). It is not directly related to open source. But, I think competitive coding problems have improved the way I approach a problem in general. This has helped me learn how to analyse different test cases and has improved my testing and debugging ability.
Have you contributed to any other open source organizations or projects? If so, do you have artifacts you can show so we can see your skill set(s)?
Yes, I have contributed to linux kernel. I have done some bug fixes in staging tree. This is the link to my patches https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?qt=grep&q=Ronit+Halder
No, except the linux kernel, I haven't contributed to any other project. Essentially I'm very new to open source.
Proposal Description
Implementation of “Tinykdump”, an improved tool to replace kdump
Overview and the need:
Debugging is the most challenging part of linux kernel programming. Linux kernel behaves very differently depending on the current devices attached and the kernel configuration. This makes reproduction of some bugs very hard. For example if an unknown bug creates a kernel panic then we have no easy way to find the bug. The only way to get some evidence is to take the crash dump using the kdump tool.
In case of a kernel panic, the kdump tool boots a new kernel (known as capture kernel) from the crashed kernel using the kexec system call (a kernel to kernel bootloader) and retrieves the memory of crashed kernel by the /proc/vmcore interface.
Drawbacks with kdump:
1. Memory allocation:
Currently, The memory for capture kernel is allocated in the boot time. This is very inflexible. It makes some part of the RAM unusable. Sometime, The memory requirement may not be known in boot time.
2. Initramfs image:
Fedora’s kdump tool (kexec-tools from fedora package) generates initramfs using dracut. It depends on dracut to support complex network and storage drivers. This makes the memory footprint of the capture kernel unpredictable and sometime it takes a lot of memory causing the system to run out of space.
3. Kernel security data:
Also the kdump tool uses makedumpfile dump_level 31 by default, which excludes zero pages, cache pages, free pages and user data from kernel crash dump. But there may be some some data like security keys in the kernel pages that are dumped, which may create some security concern in certain scenarios. These sections should ideally be exclude from the dump.
- The intention of this project is to make a more flexible, reliable and lightweight (with less memory footprint) kernel crash dumping tool that can replace kdump.
Benefits for Fedora and open-source community
- By implementing a minimal tool with no dependency to any initramfs generator, the maintaining efforts can be reduced. This makes porting the tool to other platforms much easier.
- By implementing the feature to allocate memory in run time, we can give the user more flexibility and more usable RAM.
- By creating a minimal initramfs for capture kernel the memory requirement can be brought down. System programmers generally use separate system for testing purpose. This is generally a low end system. So, by bringing down the memory requirement this people will get a huge advantage. This will allow more people to participate.
- Sometime the kernel crash dump is analysed by different person than the creator of the crash dump. By, filtering out kernel security data the user don’t have to worry about security issues.
Implementation Plan:
1. Runtime memory allocation:
This problem can be solved by using linux kernel’s CMA (Contiguous Memory Allocator) API. It can allocate up to 1GB of physically contiguous memory. CMA uses existing memory allocators of linux kernel. A new CMA area can be created for the capture kernel. This will create a pageblock with MIGRATE_CMA migrate type. This ensures that this part of the memory will be allocated only for movable page blocks(generally used for cache) until we allocate pages from this CMA area for our capture kernel. Hence this part of the memory will remain usable until the memory allocation for capture kernel is done. Currently, /sys/kernel/kexec_crash_size is used to see the size of the allocated memory(allocated at boot time for capture kernel) and resize it into a smaller size allocation for capture kernel to free the memory but no extra memory can be allocated. The new implementation will allow us to allocate as much memory as needed from the CMA are during runtime.
2. Creating python based Tinykdump daemon:
Tinykdump daemon will be written in python and will only support usb storage as the storage option. We will have a simple configuration file for tinykdump as it only supports usb storage for storing crash dump and log. This daemon will have most parts similar to kdump. Only the initramfs generator will be different.
3. Creating a minimal initramfs generator:
A small script can be created which generates a initramfs image. This initramfs will contain only essential things for dump capture like makedumpfile, usb storage drivers and BusyBox. BusyBox will provide basic functions needed to store kernel crash dump and kernel log. We need to call the makedumpfile after capture kernel starts.Init script(s) and systemd service file(s) can be written for this purpose which will be included in the initramfs of capture kernel. Dracut’s kdumpbase does the same thing for kdump. I will reuse as much code of kdumpbase as possible. This module will be simpler than kdumpbase as it only supports usb storage.
4. Adding makedumpfile.conf to filter out certain data structure
makedumpfile supports filtering out certain kernel symbols and it’s members. This can be done using makedumpfile config file . We will create a makedump.conf file and include it in the initramfs image of capture kernel.
Timeline:
- Note: My semester exams are from 18 April to 6 May(tentative). So, I won’t be completely available in that period.
Community Bonding Period (7 May to 22 May)
- Discuss in detail about the Tinykdump daemon with mentor.
- Go through codebase of fedora’s Kdump tool. Mark the parts of kdump tool that will be similar in Tinykdump.
- Get some experience in creating cpio archive.
- Mark the parts that are related to kexec system call in linux kernel. This will give me idea of how to integrate a CMA area with kexec system call.
First Coding Period:
Week 1
Write a patch which allocates a new CMA area and allocates memory from that CMA area.
Week 2-3
Integrate this to the kexec system call. So, that kexec can allocate memory from this CMA area. Create the sysfs entry. Start testing the code.
Week 4-5
More testing and bug fixes. Submit this patch for community review.
[Midterm Evaluation]
Second Coding Period:
Week 6-7
Start writing the tinykdump daemon. I will look at the code of kdump (kexec-tools fromfedora package) and port the similar parts of kdump into tinykdump.
Week 8
Write the script for tinykdump which will create the initramfs image. This programme will take the necessary things and create a cpio archive which will be used as initramfs.
Week 9
Write the script(s) which will call makedumpfile in the capture kernel. Look into dracut’s kdumpbase module and try to reuse as much code as possible. Write a systemd service file(s) for this script.
Week 10-11
Finish writing tinykdump tool. Test Tinykdump and do bug fixes. Complete anything that is left.
Week 12
Will create the makedumpfile configuration file. Include this file in initramfs generator.Start writing the documentation and create a man page for tinykdump.
Week 13
Finish writing the documentation and create a man page for tinykdump.
Any other details you feel we should consider
I am in touch with the mentor with last 1 month. I have removed some part of the original idea proposed in idea page by consulting with my mentor as I think the whole idea can't be implemented in 3 months. I will finish the leftover part after 3 months.