Operating Systems 2021F: Tutorial 9 - Revision history

Soma at 15:56, 27 November 2021

2021-11-27T15:56:05Z

← Older revision		Revision as of 15:56, 27 November 2021
Line 1:		Line 1:
	~~'''This tutorial is still being developed.'''~~

	==Introduction==		==Introduction==
	WARNING: The commands and programs in this tutorial are potentially extremely dangerous and		WARNING: The commands and programs in this tutorial are potentially extremely dangerous and

Soma: /* Watching kernel memory allocations */

2021-11-27T15:55:36Z

Watching kernel memory allocations

← Older revision		Revision as of 15:55, 27 November 2021
Line 33:		Line 33:
	#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?		#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?

	==Watching ~~kernel memory allocations~~==		==Watching Kernel Memory Allocations==
	Now let's trace various kernel memory allocations outside of our module.		Now let's trace various kernel memory allocations outside of our module.
	# Run <tt>sudo trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.		# Run <tt>sudo trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.

Soma: /* Watching kernel memory allocations */

2021-11-27T15:55:05Z

Watching kernel memory allocations

← Older revision		Revision as of 15:55, 27 November 2021
Line 34:		Line 34:

	==Watching kernel memory allocations==		==Watching kernel memory allocations==
	Now let's trace various kernel memory allocations outside of our module. ~~Run the following trace commands:~~		Now let's trace various kernel memory allocations outside of our module.
	# <tt>trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.		# Run <tt>sudo trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.
	# <tt>trace -M 100 -K 't:kmem:mm_page_alloc printf "allocted 2^%d pages at page frame number %lu" args->order, args->pfn'</tt> to trace the next 100 page allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. Based on what you can see, does page allocation seem to differ from slab allocation? How so?		# Run <tt>sudo trace -M 100 -K 't:kmem:mm_page_alloc printf "allocted 2^%d pages at page frame number %lu" args->order, args->pfn'</tt> to trace the next 100 page allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. Based on what you can see, does page allocation seem to differ from slab allocation? How so?

	==Code==		==Code==

Soma: /* 3000memview2.c */

2021-11-27T15:52:45Z

3000memview2.c

← Older revision		Revision as of 15:52, 27 November 2021
Line 105:		Line 105:

	printf("Memory map report (virtual -> physical)\n");		printf("Memory map report (virtual -> physical)\n");
	report_memory("argv: ", fd, (unsigned long)argv);		report_memory("argv: ", fd, (unsigned long)argv);
	report_memory("argv[0]: ", fd, (unsigned long)argv[0]);		report_memory("argv[0]: ", fd, (unsigned long)argv[0]);
	report_memory("envp: ", fd, (unsigned long)envp);		report_memory("envp: ", fd, (unsigned long)envp);

Soma: /* 3000memview2.c */

2021-11-27T15:52:04Z

3000memview2.c

← Older revision		Revision as of 15:52, 27 November 2021
Line 105:		Line 105:

	printf("Memory map report (virtual -> physical)\n");		printf("Memory map report (virtual -> physical)\n");
	report_memory("argv: ", fd, (unsigned long)argv);		report_memory("argv: ", fd, (unsigned long)argv);
	report_memory("argv[0]: ", fd, (unsigned long)argv[0]);		report_memory("argv[0]: ", fd, (unsigned long)argv[0]);
	report_memory("envp: ", fd, (unsigned long)envp);		report_memory("envp: ", fd, (unsigned long)envp);
Line 114:		Line 114:
	report_memory("gmsg: ", fd, (unsigned long)gmsg);		report_memory("gmsg: ", fd, (unsigned long)gmsg);
	report_memory("&gmsg: ", fd, (unsigned long)&gmsg);		report_memory("&gmsg: ", fd, (unsigned long)&gmsg);

	~~report_memory("main: ", fd, (unsigned long)&main);~~

	report_memory("&buf: ", fd, (unsigned long)&buf);		report_memory("&buf: ", fd, (unsigned long)&buf);
Line 124:		Line 122:
	report_memory(format, fd, (unsigned long)buf[i]);		report_memory(format, fd, (unsigned long)buf[i]);
	}		}

			report_memory("main: ", fd, (unsigned long)&main);
			report_memory("puts: ", fd, (unsigned long)&puts);

	return 0;		return 0;

Soma: /* Code */

2021-11-27T15:50:36Z

Code

← Older revision		Revision as of 15:50, 27 November 2021
Line 40:		Line 40:
	==Code==		==Code==

	[https://homeostasis.scs.carleton.ca/~soma/os-~~2020w~~/code/3000physicalview.tar.gz 3000physicalview.tar.gz]		[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000physicalview.tar.gz 3000physicalview.tar.gz]

	===3000memview2.c===		===3000memview2.c===

Soma: /* Introduction */

2021-11-27T15:50:25Z

Introduction

← Older revision		Revision as of 15:50, 27 November 2021
Line 12:		Line 12:
	[https://en.m.wikipedia.org/wiki/Intel_5-level_paging read about 5-level paging].		[https://en.m.wikipedia.org/wiki/Intel_5-level_paging read about 5-level paging].

	To get started, we will first examine the source code for <tt>3000physicalview.c</tt> and <tt>3000memview2.c</tt>, both of which are in [https://homeostasis.scs.carleton.ca/~soma/os-~~2020w~~/code/3000physicalview.tar.gz 3000physicalview.tar.gz].		To get started, we will first examine the source code for <tt>3000physicalview.c</tt> and <tt>3000memview2.c</tt>, both of which are in [https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000physicalview.tar.gz 3000physicalview.tar.gz].

	==Getting Started==		==Getting Started==

Soma: /* Getting Started */

2021-11-27T15:50:08Z

Getting Started

← Older revision		Revision as of 15:50, 27 November 2021
Line 15:		Line 15:

	==Getting Started==		==Getting Started==
	# Download [https://homeostasis.scs.carleton.ca/~soma/os-~~2020w~~/code/3000physicalview.tar.gz 3000physicalview.tar.gz] and unpack with the command <tt>tar xzf 3000physicalview.tar.gz</tt>. Compile <tt>3000physicalview</tt> and <tt>3000memview2</tt> using the provided Makefile (i.e. by running <tt>make</tt>).		# Download [https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000physicalview.tar.gz 3000physicalview.tar.gz] and unpack with the command <tt>tar xzf 3000physicalview.tar.gz</tt>. Compile <tt>3000physicalview</tt> and <tt>3000memview2</tt> using the provided Makefile (i.e. by running <tt>make</tt>).
	# Insert <tt>3000physicalview</tt> by running <tt>make insert</tt>. Confirm that the module is inserted using <tt>lsmod</tt>.		# Insert <tt>3000physicalview</tt> by running <tt>make insert</tt>. Confirm that the module is inserted using <tt>lsmod</tt>.
	# Examine the call to <tt>copy_from_user</tt> and <tt>copy_to_user</tt> on lines 120 and 132 of <tt>3000physicalview.c</tt>. Consider the following:		# Examine the call to <tt>copy_from_user</tt> and <tt>copy_to_user</tt> on lines 120 and 132 of <tt>3000physicalview.c</tt>. Consider the following:

Soma: /* Revisiting Trace */

2021-11-27T15:39:04Z

Revisiting Trace

← Older revision		Revision as of 15:39, 27 November 2021
Line 33:		Line 33:
	#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?		#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?

	==~~Revisiting Trace~~==		==Watching kernel memory allocations==
	# Modify <tt>3000memview2.c</tt> by adding a call to <tt>sleep(10);</tt> at the beginning of <tt>main</tt>. This will give you a chance to run <tt>trace</tt> attached to its pid. Compile with the Makefile as before. For the following questions, run your new <tt>3000memview2</tt> in one terminal, and the <tt>trace</tt> command in another.		Now let's trace various kernel memory allocations outside of our module. Run the following trace commands:
	~~#* Run <tt>trace -p `pidof 3000memview2` -K 'p::_copy_to_user'</tt> to get the kernel stack trace every time the module invokes <tt>copy_to_user</tt>. What functions are being called?~~		# <tt>trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.
	#* Run <tt>trace -p `pidof 3000memview2` -K 'p::_copy_from_user'</tt> to get the kernel stack trace every time the module invokes <tt>copy_from_user</tt>. Compare this stack trace with that of the previous question.		# <tt>trace -M 100 -K 't:kmem:mm_page_alloc printf "allocted 2^%d pages at page frame number %lu" args->order, args->pfn'</tt> to trace the next 100 page allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. Based on what you can see, does page allocation seem to differ from slab allocation? How so?
	# Now let's trace various kernel memory allocations outside of our module. Run the following trace commands:
	#* <tt>trace -M 100 -K 't:kmem:kmalloc printf "allocated %d bytes at address 0x%llx" args->bytes_alloc, args->ptr'</tt> to trace the next 100 slab allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. What do you notice about the kernel's virtual addresses compared to what you have seen in userspace? Hint: Check the most significant hex digits.
	#* <tt>trace -M 100 -K 't:kmem:mm_page_alloc printf "allocted 2^%d pages at page frame number %lu" args->order, args->pfn'</tt> to trace the next 100 page allocations and print the kernel stack. You may wish to pipe this output into <tt>less</tt> to read it more easily. Based on what you can see, does page allocation seem to differ from slab allocation? How so?

	==Code==		==Code==

Soma: /* Examining Physical Memory Mappings */

2021-11-27T15:33:08Z

Examining Physical Memory Mappings

← Older revision		Revision as of 15:33, 27 November 2021
Line 32:		Line 32:
	#* Are the virtual addresses the same or different between runs? How about physical addresses?		#* Are the virtual addresses the same or different between runs? How about physical addresses?
	#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?		#* Some physical addresses don't seem to be changing between runs. Which ones? Why do you think this might be the case?
	# Spawn a root shell with <tt>sudo su</tt> and force the kernel to drop the virtual memory cache using <tt>sync && echo 3 > /proc/sys/vm/drop_caches</tt>. Run <tt>3000memview2</tt> one more time and note that the physical addresses that stayed the same previously have now changed. What do you think just happened?

	==Revisiting Trace==		==Revisiting Trace==