Linux Device Drivers 2nd Edition (779877), страница 29
Текст из файла (страница 29)
It’sinteresting to note how retries are organized in this example, as opposed to theprevious trace. wc is optimized for fast reading and thus bypasses the standardlibrary, trying to read more data with a single system call. You can see from theread lines in the trace how wc tried to read 16 KB at a time.Linux experts can find much useful information in the output of strace. If you’reput off by all the symbols, you can limit yourself to watching how the file methods(open, read, and so on) work.Personally, we find strace most useful for pinpointing runtime errors from systemcalls.
Often the perr or call in the application or demo program isn’t verboseenough to be useful for debugging, and being able to tell exactly which argumentsto which system call triggered the error can be a great help.Debugging System FaultsEven if you’ve used all the monitoring and debugging techniques, sometimes bugsremain in the driver, and the system faults when the driver is executed. When thishappens it’s important to be able to collect as much information as possible tosolve the problem.Note that “fault” doesn’t mean “panic.” The Linux code is robust enough torespond gracefully to most errors: a fault usually results in the destruction of thecurrent process while the system goes on working. The system can panic, and itmay if a fault happens outside of a process’s context, or if some vital part of thesystem is compromised.
But when the problem is due to a driver error, it usuallyresults only in the sudden death of the process unlucky enough to be using thedriver. The only unrecoverable damage when a process is destroyed is that somememory allocated to the process’s context is lost; for instance, dynamic lists allocated by the driver through kmalloc might be lost. However, since the kernel callsthe close operation for any open device when a process dies, your driver canrelease what was allocated by the open method.We’ve already said that when kernel code misbehaves, an informative message isprinted on the console.
The next section explains how to decode and use such11022 June 2001 16:35http://openlib.org.uaDebugging System Faultsmessages. Even though they appear rather obscure to the novice, processor dumpsare full of interesting information, often sufficient to pinpoint a program bug without the need for additional testing.Oops MessagesMost bugs show themselves in NULL pointer dereferences or by the use of otherincorrect pointer values. The usual outcome of such bugs is an oops message.Any address used by the processor is a virtual address and is mapped to physicaladdresses through a complex structure of so-called page tables (see “Page Tables”in Chapter 13). When an invalid pointer is dereferenced, the paging mechanismfails to map the pointer to a physical address and the processor signals a pagefault to the operating system.
If the address is not valid, the kernel is not able to“page in” the missing address; it generates an oops if this happens while the processor is in supervisor mode.It’s worth noting that the first enhancement introduced after version 2.0 was automatic handling of invalid address faults when moving data to and from user space.Linus chose to let the hardware catch erroneous memory references, so that thenormal case (where the addresses are correct) is handled more efficiently.An oops displays the processor status at the time of the fault, including the contents of the CPU registers, the location of page descriptor tables, and other seemingly incomprehensible information.
The message is generated by printkstatements in the fault handler (arch/*/kernel/traps.c) and is dispatched asdescribed earlier, in the section “printk.”Let’s look at one such message. Here’s what results from dereferencing a NULLpointer on a PC running version 2.4 of the kernel. The most relevant informationhere is the instruction pointer (EIP), the address of the faulty instruction.Unable to handle kernel NULL pointer dereference at virtual address \00000000printing eip:c48370c3*pde = 00000000Oops: 0002CPU:0EIP:0010:[<c48370c3>]EFLAGS: 00010286eax: ffffffeaebx: c2281a20ecx: c48370c0edx: c2281a40esi: 4000c000edi: 4000c000ebp: c38adf8cesp: c38adf8cds: 0018es: 0018ss: 0018Process ls (pid: 23171, stackpage=c38ad000)Stack: 0000010e c01356e6 c2281a20 4000c000 0000010e c2281a40 c38ac000 \0000010e4000c000 bffffc1c 00000000 00000000 c38adfc4 c010b860 00000001 \4000c0000000010e 0000010e 4000c000 bffffc1c 00000004 0000002b 0000002b \11122 June 2001 16:35http://openlib.org.uaChapter 4: Debugging Techniques00000004Call Trace: [<c01356e6>] [<c010b860>]Code: c7 05 00 00 00 00 00 00 00 00 31 c0 89 ec 5d c3 8d b6 00 00This message was generated by writing to a device owned by the faulty module, amodule built deliberately to demonstrate failures.
The implementation of the writemethod of faulty.c is trivial:ssize_t faulty_write (struct file *filp, const char *buf, size_t count,loff_t *pos){/* make a simple fault by dereferencing a NULL pointer */*(int *)0 = 0;return 0;}As you can see, what we do here is dereference a NULL pointer. Since 0 is never avalid pointer value, a fault occurs, which the kernel turns into the oops messageshown earlier. The calling process is then killed.The faulty module has more interesting fault conditions in its read implementation:char faulty_buf[1024];ssize_t faulty_read (struct file *filp, char *buf, size_t count,loff_t *pos){int ret, ret2;char stack_buf[4];printk(KERN_DEBUG "read: buf %p, count %li\n", buf, (long)count);/* the next line oopses with 2.0, but not with 2.2 and later */ret = copy_to_user(buf, faulty_buf, count);if (!ret) return count; /* we survived */printk(KERN_DEBUG "didn’t fail: retry\n");/* For 2.2 and 2.4, let’s try a buffer overflow */sprintf(stack_buf, "1234567\n");if (count > 8) count = 8; /* copy 8 bytes to the user */ret2 = copy_to_user(buf, stack_buf, count);if (!ret2) return count;return ret2;}It first reads from a global buffer without checking the size of the data, and thenperforms a buffer overrun by writing to a local buffer.
The first situation results inan oops only in version 2.0 of the kernel, because later versions automatically dealwith user copy functions. The buffer overflow results in an oops with all kernelversions; however, since the return instruction brings the instruction pointer tonowhere land, this kind of fault is much harder to trace, and you can get something like the following:11222 June 2001 16:35http://openlib.org.uaDebugging System FaultsEIP:0010:[<00000000>][...]Call Trace: [<c010b860>]Code: Bad EIP value.The main problem with users dealing with oops messages is in the little intrinsicmeaning carried by hexadecimal values; to be meaningful to the programmer theyneed to be resolved to symbols.
A couple of utilities are available to perform thisresolution for developers: klogd and ksymoops. The former tool performs symboldecoding by itself whenever it is running; the latter needs to be purposely invokedby the user. In the following discussion we use the data generated in our first oopsexample by dereferencing a NULL pointer.Using klogdThe klogd daemon can decode oops messages before they reach the log files. Inmany situations, klogd can provide all the information a developer needs to trackdown a problem, though sometimes the developer must give it a little help.A dump of the oops for faulty, as it reaches the system log, looks like this (notethe decoded symbols on the EIP line and in the stack trace):Unable to handle kernel NULL pointer dereference at virtual address \00000000printing eip:c48370c3*pde = 00000000Oops: 0002CPU:0EIP:0010:[faulty:faulty_write+3/576]EFLAGS: 00010286eax: ffffffeaebx: c2c55ae0ecx: c48370c0edx: c2c55b00esi: 0804d038edi: 0804d038ebp: c2337f8cesp: c2337f8cds: 0018es: 0018ss: 0018Process cat (pid: 23413, stackpage=c2337000)Stack: 00000001 c01356e6 c2c55ae0 0804d038 00000001 c2c55b00 c2336000 \000000010804d038 bffffbd4 00000000 00000000 bffffbd4 c010b860 00000001 \0804d03800000001 00000001 0804d038 bffffbd4 00000004 0000002b 0000002b \00000004Call Trace: [sys_write+214/256] [system_call+52/56]Code: c7 05 00 00 00 00 00 00 00 00 31 c0 89 ec 5d c3 8d b6 00 00klogd provides most of the necessary information to track down the problem.
Inthis case we see that the instruction pointer (EIP) was executing in the functionfaulty_write, so we know where to start looking. The 3/576 string tells us that theprocessor was at byte 3 of a function that appears to be 576 bytes long. Note thatthe values are decimal, not hex.11322 June 2001 16:35http://openlib.org.uaChapter 4: Debugging TechniquesThe developer must exercise some care, however, to get useful information forerrors that occur within loadable modules. klogd loads all of the available symbolinformation when it starts, and uses those symbols thereafter.
If you load a moduleafter klogd has initialized itself (usually at system boot), klogd will not have yourmodule’s symbol information. To force klogd to go out and get that information,send the klogd process a SIGUSR1 signal after your module has been loaded (orreloaded), and before you do anything that could cause it to oops.It is also possible to run klogd with the –p (“paranoid”) option, which will cause itto reread symbol information anytime it sees an oops message.
The klogd manpage recommends against this mode of operation, however, since it makes klogdquery the kernel for information after the problem has occurred. Informationobtained after an error could be plain wrong.For klogd to work properly, it must have a current copy of the System.map symboltable file. Normally this file is found in /boot; if you have built and installed a kernel from a nonstandard location you may have to copy System.map into /boot, ortell klogd to look elsewhere. klogd refuses to decode symbols if the symbol tabledoesn’t match the current kernel. If a symbol is decoded on the system log, youcan be reasonably sure it is decoded correctly.Using ksymoopsAt times klogd may not be enough for your tracing purposes.
Usually, you need toget both the hexadecimal address and the associated symbol, and you often needoffsets printed as hex numbers. You may need more information than addressdecoding. Also, it is common for klogd to get killed during the fault. In such situations, a stronger oops analyzer may be called for; ksymoops is such a tool.Prior to the 2.3 development series, ksymoops was distributed with the kernelsource, in the scripts directory.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
