Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
If one were to pursue the crazy and dangerous idea of writing a kernel module in Linux that...
Finds a process specified by PID in the kernel's internal process table
Extracts the begin/end adresses of the process in memory from the table
Overwrites all memory of this process with 0's
then ...
Would this be a way to instantaneously terminate any process?
How "unsafe" would this be? Would it be possible at all without insantly causing a kernel panic?
Overwriting the process's code with zero (in x86) is most likely NOT going to stop the process from executing, but since that becomes a plain instruction, I think ADD EAX, [EAX], it will just walk all the way to the end of the code segment [unless EAX is pointing at invalid memory]. Obviously, if the registers for the process are set to some invalid memory address [in 64-bit, a value that is non-canonical will be good, in 32-bit, something that is write-protected, such as zero], and/or the memory is filled with something that causes an "invalid opcode", then that would be a different matter.
I really don't see how this can be "better" than using SIGKILL (aka KILL -9 pid) - if the process is blocked inside the kernel and somehow not leaving the kernel, it won't help to overwrite the code-space, since the process isn't running that code anyway. If there is a bug in the kernel, it's not really going to matter what you do to the process' userspace memory. Fix the kernel bug!
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I want to view a status of a process among 2000 processes, Without using top and ps
commands.
The name of the process is tom.
A process don't have any name (only the program it is running has one, but see also pthread_setname_np(3)... you might have pathological cases like this). It has a pid (which is some integer number, like 1234, of type pid_t). See credentials(7) and fork(2) and execve(2). Use pidof(1) and pgrep(1) to find the pid of some process. An executable program (e.g. /bin/bash) can be run by several processes (or none, or only one).
You may use kill(2) with a zero signal number to check that the process exists.
Most importantly, you should consider using /proc/ (see proc(5) for more). For the process of pid 1234, see /proc/1234/ which has several files and subdirectories (notably /proc/1234/status and /proc/1234/maps). Try cat /proc/$$/status and cat /proc/$$/maps and stat /proc/$$/exe and ls -l /proc/$$/ in a terminal (then replace $$ by whatever pid is interesting for you).
The top and ps utilities (and also pidof, pgrep, ...) are using that /proc/ (which is the mean by which the Linux kernel shows information on processes, and on the system itself). And you can write your program (or script) doing that too and using /proc/. See also this.
From inside a program, you can explore /proc/ like you would explore other file trees, e.g. using stat(2), opendir(3), readdir(3), nftw(3) etc.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
This is a fairly self-explanatory question. Some background info is appended.
How can I check for a malloc() failure within a CUDA kernel? I googled this and found nothing on what malloc() returns in a CUDA implementation.
In addition, I have no idea how to signal back to the host that there was an error within a CUDA kernel. How can I do this?
I thought one way would be to send an array of chars, one element for each kernel thread, and have the kernel place a 0x01 to signal an error and 0x00 for no error. Then the host could copy this memory back and check for any non zero bytes?
But this seems like a waste of memory. Is there a better way? Something like cudaThrowError()? ... maybe? ...
Appended:
I am running into trouble with a cuda error: GPUassert: the launch timed out and was terminated main.cu
If you google this, you will find info for Linux users (who have hybrid graphics solutions) - the fix is sometimes to run with optirun --no-xorg.
However in my case this isn't working.
If I run my program for a small enough data set, I get no errors. For a large enough data set, but not too large, I have to prevent time out errors by passing the --no-xorg flag. For an even larger dataset I get timeout errors regardless of the --no-xorg flag.
This hints to me that perhaps something else is going wrong?
Perhaps a malloc() failure within my kernel if I run out of memory?
I have checked my code and estimated memory usage - I don't think this is the problem, but I would like to check anyway.
How can I check for a malloc() failure within a CUDA kernel?
The behavior is the same as malloc on the host. If a malloc failure occurs, the returned pointer will be NULL.
So check for NULL after a malloc, and do something to address it:
#include <assert.h>
...
int *data
data = (int *)malloc(dsize*sizeof(int));
assert(data != NULL);
...rest of your code...
Notes:
It's legal to use assert in-kernel this way. If the assert is hit, your kernel will halt, and return an error to the host, which you can observe with proper cuda error checking or cuda-memcheck. This isn't the only possible way to handle a malloc failure, it's just a suggestion.
This may or may not be the problem with your actual code. This is good practice, however.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In the /proc file system, why is that some files have their maps file empty. Is it because no memory has been allocated to them or the data isn't available?
They must be allocated some memory, otherwise how are they running?
First, notice that all the pseudo-files /proc/1234/maps and /proc/self/maps have always a zero size, as reported by the stat(2) syscall and the ls command. However, they are sequentially readable (e.g. by the cat command, or with read(2) syscall, e.g. called by fgets). Try cat /proc/self/maps and ls -ls /proc/self/maps for example.
A probable reason for the /proc/*/maps files to have a 0 size is that computing their size means computing their content, and that could be expensive. So the kernel prefers to say 0 for their size. Think of them as being sort of pipes. You need to read them sequentially, they are not lseek(2)-able.
Read the proc(5) man page for details about /proc/; notice that it is using Unix permissions and ownership, so you cannot access a /proc/1234 directory if the process of pid 1234 is not yours.
And you might also have some zombie processes. These don't have any address space anymore, so I won't be surprised if their maps pseudo-file in /proc is truly empty (in the sense that reading it gives immediately an end-of-file condition), or even missing.
Remember that files under /proc are pseudo-files, in the sense that the kernel is providing them (and giving their data), and they don't involve any real disk I/O. In particular, reading them should be fast.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What are the processes that write to "/var/adm/messages"?
From what I gathered Syslogd does the job. Am i right?
Also I saw multiple files, messages, messages.0, messages.1 and so on. Why is it so?
Also is there any other system process that writes to these files?
Any help is highly appreciated.
Yes, processes that use the syslog framework send messages to syslogd, which reads /etc/syslog.conf to determine where (or if) the message should be written based on the facility and level of the message. For example, if syslog.conf has the entry
user.debug /var/log/mylog
then all messages of a higher level than debug (the lowest level) from processes of the user facility (i.e. non-system processes) will be sent to /var/log/mylog (man syslog.conf for full explanation including possible facilities and levels).
The /var/adm/messages.X files are created as /var/adm/messages is rotated by the logadm cron job (again, see the man pages for logadm and logadm.conf).
NOTE: This answer is based on Solaris experience; file locations and behavior may vary with other *NIX flavors.
You can find out yourself with dtrace:
http://dtracebook.com/index.php/File_Systems
Syscall write(2) by file name: dtrace -n 'syscall::write:entry {
#[fds[arg0].fi_pathname] = count(); }'
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'd like to know this for the first boot and for subsequent boots.
I'm compiling my own kernel and want it to be as lean as possible. I want to build the .config file by hand (mainly as a learning experience), so I need to know everything that can be excluded. I know a possible solution is to look at my current distros list of loaded drivers. However, I'm curious about how my distro discovered what drivers to load initially.
TIA.
How does the Linux kernel know which drivers to load at boot?
The kernel generates events for devices on e.g. the PCI bus when they are plugged (either hot or cold; events are queued until userspace runs AFAIR). udev will receive these events and do modprobe calls which include the PID/VID (product/vendor IDs) of the device(s); this is usually a string with some * in it. modprobe will then calculate the intersection of the set expressed by udev's load request wildcard and the set of aliases of kernel modules (themselves being possibly wildcards).
Since USB/Firewire/etc. controllers are usually attached to the PCI bus, that's how your HCI driver gets loaded. That is how things recurse down; loading is then done with USB/Firewire PID/VIDs of course.
Network protocol modules (e.g. ipv6) are however not dealt with through udev; instead, when a program calls socket(AF_INET6, ...) the kernel directly calls modprobe (more precisely: whatever is in /proc/sys/kernel/modprobe) with a non-wildcarded alias, net-pf-10 in case of IPv6, because AF_INET6 happens to have value 10. modprobe then loads ipv6.ko, because that is what has the net-pf-10 alias.
Similarly for filesystems, attempting to mount -t foo will cause the kernel to also call modprobe (again, via ____call_usermodehelper), this time with foo as argument.
Accessing device nodes (e.g. /dev/loop0, provided it already exists) has the same strategy if loop.ko is not already loaded. The kernel here requests block-major-7-0 (because loop0 usually has (7,0), cf. ls -l), and loop.ko has the fitting block-major-7-* alias.
Greg Kroah give an excellent example on how to find exactly which drivers you need for you kernel. Kindly Greg gives his book away for free online
http://files.kroah.com/lkn/
A quote from Greg's books
I'm especially proud of the chapter on how to figure out how to configure
a custom kernel based on the hardware running on your machine. This is an
essential task for anyone wanting to wring out the best possible speed and
control of your hardware.