In the Linux kernel, given the task_struct's mm I can access the process's list of vm_area_structs. Given these vm_area_structs, how do I get the struct pages which actually correspond to this vma?
I tried looking for functions in mm/memory.c and the like, but I was at a loss.
Edit: the idea is to find which pages in the vma are currently in memory and which are not. But I don't want someone telling me how to do this bit, as that's a small part of a homework assignment that I need to figure out on my own. But I can't seem to figure out how to find the pages that correspond to this vma. If I can find the pages, I figure I can check to see if they have a valid pfn or not.
From your comment to another answer (edit: the other answer seems to have been deleted), it seems you want to read from user space. The function to get the user space pages would be get_user_pages(), but that is most probably not what you want; you probably want copy_from_user/copy_to_user.
I don't have the direct answer off-hand, but it won't take you long to navigate the structures by using lxr.linux.no
Given you already have the struct you want to start from, take a look from http://lxr.linux.no/linux+v2.6.29/+code=vm_area_struct. You can look for definitions, see where a single struct is used, etc... If you already know the final struct name you are looking for, you can go in reverse and navigate up until you reach the mm.
Note that if your net connection is not so good, you may want to install a local copy of the indexed source by getting the lxr packages of your distro and generating the index locally. It used to take 2 hours on a 400mhz / 128mb machine, nowadays it should go much much much faster.
Related
How can I get the label of a filesystem using /sys? I know I can get much of the info about a block device by going to /sys/class/block/<device>, e.g. /sys/class/block/sr1 for a cd that I know has the filesystem label config. I hunted through each item, found everything but the label.
I did dig through the lsblk source code, which, in turn, depends on calling udev_device_new_from_subsystem_sysname in libudev, so I went through that. It does appear to populate the property ID_FS_LABEL_ENC, but I cannot figure out where it takes it from in the tree, unless it is tracking it elsewhere?
I would just use libudev, but need to access outside of a C program.
I think that the problem here is that you seem to think that the label of a volume is a kernel thing, as is the size or the free space.
But AFAIK it is not, the kernel doesn't care at all about volume labels, it is just a thing that goes from the in-disk format to user-land: there is no kernel API to get that information. If you need it, you just open the raw binary volume and read the data from there.
But then, there is the big issue that every filesystem is different, so you need special code to manage every single partition type there is. Fortunately, somebody has done the hard work, and you have blkid, part of util-linux available in most Linux distributions. If you need it, you can call the program directly, or link to the library libblkid that does the hard work.
Naturally, to use blkid/libblkid you need read access to the block device, that is, root access. If you think that root access should not be needed to read a label, the people from udev think the same, and that is why there is a udev rule that copies the label when the filesystem is first dectected (running blkid of course). This is the ID_FS_LABEL_ENC you already know about.
is it possible to get the the path where the program was called from?
I call the program on z/Os like this
call 'MCOE.XXXXXXXX.C.LOAD(args)' 'hi there'
My intention is to get the MCOE.XXXXXXXX.C.LOAD dataset in called program without specifying this path as a parameter.
Thanks!
PetrS
This is a non-trivial exercise, but it can generally be done.
You'd start by using CSVINFO to get some information about your program, and then the trick is to emulate the search z/OS would have done to find your module...private/task library, STEPLIB/JOBLIB, (M)LPA search, LNKLST, etc - once you know the load module name definitely (your "args" program name might be an alias, or something the caller setup with an IDENTIFY macro), you can get a lot of this with BLDL, assuming you know which DCB to use.
Once you figure out the DDNAME and concatenation number (after all, there might be 10 libraries in your STEPLIB!), you'd scan the allocation data structures to get the actual dataset name. Typically, this is done by traversing the data structures in memory (PSATOLD->TCBTIO, then indexing into the TIOT till you find the entry you want...the matching TIOT entry will have a pointer to the JFCB - or a SWA manager token - that you can use to get the JFCB, and the JFCB has the dataset name and all the other details you want).
In the case of a fetch from LNKLST, you have extra work to figure out exactly which dataset in the LNKLST concatenation you were fetched from. Again, possible but it requires a bit of finesse.
If your program happens to be in (M)LPA, I'm not sure you can reliably retrieve the original dataset name it was fetched from - this might be the worst case, although there are no doubt a variety of other potential challenges, such as dealing with UNIX Services executable pathnames.
Good luck if you decide to give it a try!
I am attempting to modify the bio structure (in blk_types.h) for linux-3.2.0 (running Ubuntu). The only thing I need to do to this structure is to add an additional variable to keep track of an integer variable (it is for a tainting algorithm). However, adding a single line such as "int id;" to the structure halts the boot sequence of the OS.
It compiles, but when booting it gives the following error:
>Gave up wiating for root device. Common problems:
>Boot args
>check rootdelay= ...
>check root= ...
>missing modules (cat /proc/modules; ls /dev)
>ALERT! /dev/disk/by-uuid/15448888-84a0-4ccf-a02a-0feb3f150a84 does not exist. Dropping to a shell!
>BusyBox Built In Shell ...
>(initramfs)
I took a look around using the given shell and could not find the desired file system by uuid or otherwise (no /dev/sda). Any ideas what might be going on?
Thanks,
-Misiu
I suppose you are trying to modify the Linux kernel header bio.h, not its userland "friend" bui.h.
Said that I must warn you that in many places around kernel sizeof() may be used which is more portable and perhaps some other implementation or API may expect some fixed size. If the later is true then you'll have problems since bio' struct size has been changed by you.
It is a guessing with no further investigation from my side (I mean I hadn't investigate about bio in detail) but when patching the Linux kernel one must make sure of any possible side effects and take the whole scenario on account, specially when modifying lower levels implementation.
Bio helper functions do lots of low level operations on bio struct, take a loot at bio_integrity.c for example.
I managed to fix the problem with your help Caf. Though re-building/installing the modules did not seem to help immediately, I was able to get the system to boot by building the SATA drivers into the kernel, as advised by this forum thread: https://unix.stackexchange.com/questions/8405/kernel-cant-find-dev-sda-file-during-boot.
Thanks for your help,
-Misiu
if (!wheel) { wheel = new Wheel(); } // or some such
My google goggles aren't working too well today. I figured this one must have been coded a gazillion times already and was looking for some FOSS code, but couldn't find any.
Before I reinvent the spherical axle-surrounding device, can anyone point me at a URL?
I am coding in C for an embedded system (Atmel UC3), but that shouldn't make any difference, just explain why I need a cyclical logfile (because of limited storage).
I want to log events to a file on an SD card and when the reaches a certain size I want to start writing again at the start. Any URLs for that? (fixed entry size is ok; otherwise it might get nasty on wraparound).
Thanks a 1,000,000 in advance!
Sourceforge has a project called Cyclic Logs which may be what you need.
If not, it's not the hardest thing to implement. Just treat it like a normal cyclic memory space. But instead of having it be resident in memory have it reside on the disk.
( maintain a pointer to the head of the log and the end of the log ( increment as needed ))
Store those as headers to the log or as another flat file.
Is there a way to read a file's data but continue reading the data on the hard drive past the end of file? For normal file I/O I could just use fread(), but, obviously, that will only read to the end of the file. And it might be beneficial if I add that I need this on a Windows computer.
All my Googling for a way to do this is instead coming up with results about unrelated topics concerning EOF, such as people having problems with normal I/O.
My reasoning for this is that I accidentally deleted part of the text in a text file I was working on, and it was an entire day's worth of work. I Googled up a bunch of file recovery stuff, but it all seems to be about recovering deleted files, where my problem is that the file is still there but without some of its information, and I'm hoping some of that data still exists directly after the currently marked end of file and is neither fragmented elsewhere or already claimed or otherwise overwritten. Since I can't find a program that helps with this specifically, I'm hoping I can quickly make something up for it (I understand that, depending on what is involved, this might not be as feasible as just redoing the work, but I'm hoping that's not the case).
As far as I can foresee, though I might not be correct (not sure, which is why I'm asking for help), there are 3 possibilities.
Worst of the three: I have to look up Windows API functions that allow direct access to the entire hard drive (similar to its functions for memory, perhaps? those I have experience with) and scan the entire thing for the data that I still have access to from the file and then just continue looking at what's after it.
Second: I can get a pointer to the file, then I still have to get raw access to HD but at least have a pointer to the file in it?
Best of the three: Just open the file for write access, seek to the end, then write a ways past EOF to claim more space, but first hope that Windows won't clean the data before it hands it over to me so that I get garbage data which was the previous data in that spot which would actually be what I'm looking for? This would be awesome if it were that simple, but I'm afraid to test it out because I'd lose the data if it failed, so hopefully someone else already knows. The PC in question is running Vista Home Premium if that matters to anyone that knows the gory details of Windows.
Do either of those three seem plausible? Whether yea or nay, I'm also open (and eager) for other suggestions, especially those which are better than my silly ideas, and especially if they come with direction toward specific functions to use to get the job done.
Also, if anyone else actually has heard of a recovery program that doesn't just recover deleted files but which would actually work for a situation like this, and which is free and trustworthy, that works too.
Thanks in advance for any assistance.
You should get a utility for scanning the free space of a hard drive and recovering data from it, for example PhotoRec or foremost. Note however that if you've been using the machine much at all (even web browsing, which will create files in your cache), the data has likely already been overwritten. Do not save your recovery tools on the same hard drive, or even use the same PC to download them; get them from another computer and save them to a USB device, then run them from that device.
As for the conceptual content of your question, files are abstract objects. There is no such thing as data "past eof" except (depending on the implementation) perhaps up to the next multiple of the filesystem/disk "blocksize". Also it's possible (very likely) that your editor "saved" the file by truncating it and writing everything newly from the beginning, meaning there's not necessarily any correspondence between the old and new storage.
Your question doesn't make a lot of sense -- by definition there is nothing in the file after the EOF. By your further description, it appears that you want to read whatever happens to be on the disk after the last byte that is used by the file, which might be random garbage (unused space) or might be some other file. But in either case, this isn't 'data after the EOF' its just data on the disk that's not part of the file. Its even possible that it might be some other part of the same file, if the filesystem happens to lay out its data that way -- some filesystems scatter blocks in seemingly random ways across the disk and figuring out what bytes belong to which files requires understanding the filesystem metadata.