In the Linux kernel, is there a way to traverse down to the buffer_heads from within a module?
I can see how to get to struct bio (task_struct macro: current->bio). But how can I get to the buffer heads? The buffer_head struct holds some information I'd like to obtain at any point regarding physical block numbers.
Nevermind. I was looking at this wrong.
Related
I'm trying to read the memory of a Windows program based on a pointer I find by using ModuleInfo to get the address starting point and size of the module. But that pointer points to memory outside that modules address space, is there a way to find out the program uses that section of memory without having to find a pointer to it first?
See if the program in question has an interface ( https://en.m.wikipedia.org/wiki/Interface_(computing) ) that can be used to interface with said program. If there is no documented interface, attempting to tamper with that programs memory is a bad idea; and will most likely result in undefined behaviour. If this does not answer your question I suggest you edit it to specify exactly which program this is about.
I am trying to get an idea on how does memory mapping take place using the system call mmap.
So far I know mmap takes arguments from the user and returns a logical address of where the file is stored. When the user tries to access it takes this address to the map table converts it to a a physical address and carries the operation as requested.
However I found articles as code example and Theoretical explanation
What it mentions is the memory mapping is carried out as:
A. Using system call mmap ()
B. file operations using (struct file *filp, struct vm_area_struct *vma)
What I am trying to figure out is:
How the arguments passed in the mmap system call are used in the struct vm_area_struct *vma) More generally how are these 2 related.
for instance: the struct vm_area_struct has arguments such as starting address, ending address permissions,etc. How are the values sent by the user used to fill values of these variables.
I am trying to write a driver so, Does the kernal fill the values for variables in the structure for us and I simply use it to call and pass values to remap_pfn_range
And a more fundamental question, why is a different file systems operation needed. The fact that mmap returns the virtual address means that it has already achieved a mapping doesnt it ?
Finally I am not that clear about how the entire process would work in user as well as kernal space. Any documentation explaining the process in details would be helpful.
Suppose I get a pointer to struct page from allocator, how could I get corresponding physical address? Whether does kernel provide functions to achieve it?
Thanks.
The answer is page_to_phys(), but please make sure that this is really what you need. e.g., if you want the physical address in order to hand it off to some device for DMA it is very likely what you need is the bus address for the page, which may or may not be the physical address.
http://lxr.free-electrons.com/source/include/asm-generic/page.h#L90
I am using the esp value of kernel stack to calculate the process descriptor pointer value.
According to ULK book, I just need to mask 13 least significant bits of esp to obtain the base address of the thread_info structure.
My test is:
write a kernel module because I need to get value of kernel stack
In the kernel init function, get the value of kernel stack
use following formula to get the process descriptor pointer of the process running on the CPU: *((unsigned int*) esp & 0xffffe000)
use the current macro, print out its value.
I think the value of step3 should be same as the value of step 4.
But my experiment results shows: sometimes they are same, and sometimes they are different. Could any explain why? Or am I missing anything?
This is because at the base of the kernel stack you will find a struct thread_info instance (platform dependent) and not a struct task_struct. The current() macro provides a pointer to the current task_struct.
Try the following:
struct thread_info *info = (struct thread_info*)(esp & 0xfffe000);
struct task_struct *my_current = info->task;
Now you can compare my_current with current().
Finally, I solved this problem. Everything is correct expect for the size of kernel stack. My kernel use 4KB stack instead of 8KB stack. So I just need to mask low 12 bits of the ESP.
Thanks for all the suggestions and answer!
What I am trying to do is have application A send application B a pointer to an object which A has allocated on shared memory ( using boost::interprocess ). For that pointer transfer I intend to use boost::interprocess::message_queue. Obviously a direct raw pointer from A is not valid in B so I try to transfer an offset_ptr allocated on the shared memory. However that also does not seem to work.
Process A does this:
typedef offset_ptr<MyVector> MyVectorPtr;
MyVectorPtr * myvector;
myvector = segment->construct<MyVectorPtr>( boost::interprocess::anonymous_instance )();
*myvector = segment->construct<MyVector>( boost::interprocess::anonymous_instance )
(*alloc_inst_vec); ;
// myvector gets filled with data here
//Send on the message queue
mq->send(myvector, sizeof(MyVectorPtr), 0);
Process B does this:
// Create a "buffer" on this side of the queue
MyVectorPtr * myvector;
myvector = segment->construct<MyVectorPtr>( boost::interprocess::anonymous_instance )();
mq->receive( myvector, sizeof(MyVectorPtr), recvd_size, priority);
As I see it, in this way a do a bit copy of the offset pointer which invalidates him in process B. How do I do this right?
It seems you can address it as described in this post on the boost mailing list.
I agree there is some awkwardness here and offset_ptr doesn't really work for what you are trying to do. offset_ptr is useful if the pointer itself is stored inside of another class/struct which also is allocated in your shared memory segment, but generally you have some top-level item which is not a member of some object allocated in shared memory.
You'll notice the offset_ptr example kindof glosses over this - it just has a comment "Communicate list to other processes" with no details. In some cases you may have a single named top-level object and that name can be how you communicate it, but if you have an arbitrary number of top-level objects to communicate, it seems like just sending the offset from the shared memory's base address is the best you can do.
You calculate the offset on the sending in, send it, and then add to the base adddress on the receiving end. If you want to be able to send nullptr as well, you could do like offset_ptr does and agree that 1 is an offset that is sufficiently unlikely to be used, or pick another unlikely sentinel value.