diff options
| -rw-r--r-- | Documentation/00-INDEX | 4 | ||||
| -rw-r--r-- | Documentation/admin-guide/bug-bisect.rst | 78 | ||||
| -rw-r--r-- | Documentation/admin-guide/bug-hunting.rst | 426 | ||||
| -rw-r--r-- | Documentation/admin-guide/index.rst | 11 | ||||
| -rw-r--r-- | Documentation/admin-guide/oops-tracing.rst | 300 | ||||
| -rw-r--r-- | Documentation/admin-guide/tainted-kernels.rst | 59 | ||||
| -rw-r--r-- | Documentation/core-api/conf.py | 5 | ||||
| -rw-r--r-- | Documentation/core-api/index.rst | 17 | ||||
| -rw-r--r-- | Documentation/core-api/workqueue.rst (renamed from Documentation/workqueue.txt) | 260 | ||||
| -rw-r--r-- | Documentation/index.rst | 1 | ||||
| -rw-r--r-- | Documentation/ko_KR/HOWTO | 162 | ||||
| -rw-r--r-- | Documentation/process/howto.rst | 15 | ||||
| -rw-r--r-- | MAINTAINERS | 2 | ||||
| -rw-r--r-- | include/linux/workqueue.h | 35 | ||||
| -rwxr-xr-x | scripts/kernel-doc | 8 |
15 files changed, 723 insertions, 660 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 903ebc494f29..e2e74448d425 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -126,6 +126,8 @@ connector/ - docs on the netlink based userspace<->kernel space communication mod. console/ - documentation on Linux console drivers. +core-api/ + - documentation on kernel core components. cpu-freq/ - info on CPU frequency and voltage scaling. cpu-hotplug.txt @@ -470,7 +472,7 @@ watchdog/ - how to auto-reboot Linux if it has "fallen and can't get up". ;-) wimax/ - directory with info about Intel Wireless Wimax Connections -workqueue.txt +core-api/workqueue.rst - information on the Concurrency Managed Workqueue implementation x86/x86_64/ - directory with info on Linux support for AMD x86-64 (Hammer) machines. diff --git a/Documentation/admin-guide/bug-bisect.rst b/Documentation/admin-guide/bug-bisect.rst new file mode 100644 index 000000000000..5682d742017c --- /dev/null +++ b/Documentation/admin-guide/bug-bisect.rst @@ -0,0 +1,78 @@ +Bisecting a bug ++++++++++++++++ + +Last updated: 28 October 2016 + +Introduction +============ + +Always try the latest kernel from kernel.org and build from source. If you are +not confident in doing that please report the bug to your distribution vendor +instead of to a kernel developer. + +Finding bugs is not always easy. Have a go though. If you can't find it don't +give up. Report as much as you have found to the relevant maintainer. See +MAINTAINERS for who that is for the subsystem you have worked on. + +Before you submit a bug report read +:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`. + +Devices not appearing +===================== + +Often this is caused by udev/systemd. Check that first before blaming it +on the kernel. + +Finding patch that caused a bug +=============================== + +Using the provided tools with ``git`` makes finding bugs easy provided the bug +is reproducible. + +Steps to do it: + +- build the Kernel from its git source +- start bisect with [#f1]_:: + + $ git bisect start + +- mark the broken changeset with:: + + $ git bisect bad [commit] + +- mark a changeset where the code is known to work with:: + + $ git bisect good [commit] + +- rebuild the Kernel and test +- interact with git bisect by using either:: + + $ git bisect good + + or:: + + $ git bisect bad + + depending if the bug happened on the changeset you're testing +- After some interactions, git bisect will give you the changeset that + likely caused the bug. + +- For example, if you know that the current version is bad, and version + 4.8 is good, you could do:: + + $ git bisect start + $ git bisect bad # Current version is bad + $ git bisect good v4.8 + + +.. [#f1] You can, optionally, provide both good and bad arguments at git + start:: + + git bisect start [BAD] [GOOD] + +For further references, please read: + +- The man page for ``git-bisect`` +- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_ +- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_ +- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_ diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index d35dd9fd1af0..08c4b1308189 100644 --- a/Documentation/admin-guide/bug-hunting.rst +++ b/Documentation/admin-guide/bug-hunting.rst @@ -1,145 +1,190 @@ Bug hunting -+++++++++++ +=========== + +Kernel bug reports often come with a stack dump like the one below:: + + ------------[ cut here ]------------ + WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70 + Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore nvidia(PO) [last unloaded: rc_core] + CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O 4.8.4-build.1 #1 + Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009 + 00000000 c12ba080 00000000 00000000 c103ed6a c1616014 00000001 00006dc6 + c1615862 00000454 c109e8a7 c109e8a7 00000009 ffffffff 00000000 f13f6a10 + f5f5a600 c103ee33 00000009 00000000 00000000 c109e8a7 f80ca4d0 c109f617 + Call Trace: + [<c12ba080>] ? dump_stack+0x44/0x64 + [<c103ed6a>] ? __warn+0xfa/0x120 + [<c109e8a7>] ? module_put+0x57/0x70 + [<c109e8a7>] ? module_put+0x57/0x70 + [<c103ee33>] ? warn_slowpath_null+0x23/0x30 + [<c109e8a7>] ? module_put+0x57/0x70 + [<f80ca4d0>] ? gp8psk_fe_set_frontend+0x460/0x460 [dvb_usb_gp8psk] + [<c109f617>] ? symbol_put_addr+0x27/0x50 + [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb] + [<f80bb3bf>] ? dvb_usb_exit+0x2f/0xd0 [dvb_usb] + [<c13d03bc>] ? usb_disable_endpoint+0x7c/0xb0 + [<f80bb48a>] ? dvb_usb_device_exit+0x2a/0x50 [dvb_usb] + [<c13d2882>] ? usb_unbind_interface+0x62/0x250 + [<c136b514>] ? __pm_runtime_idle+0x44/0x70 + [<c13620d8>] ? __device_release_driver+0x78/0x120 + [<c1362907>] ? driver_detach+0x87/0x90 + [<c1361c48>] ? bus_remove_driver+0x38/0x90 + [<c13d1c18>] ? usb_deregister+0x58/0xb0 + [<c109fbb0>] ? SyS_delete_module+0x130/0x1f0 + [<c1055654>] ? task_work_run+0x64/0x80 + [<c1000fa5>] ? exit_to_usermode_loop+0x85/0x90 + [<c10013f0>] ? do_fast_syscall_32+0x80/0x130 + [<c1549f43>] ? sysenter_past_esp+0x40/0x6a + ---[ end trace 6ebc60ef3981792f ]--- + +Such stack traces provide enough information to identify the line inside the +Kernel's source code where the bug happened. Depending on the severity of +the issue, it may also contain the word **Oops**, as on this one:: + + BUG: unable to handle kernel NULL pointer dereference at (null) + IP: [<c06969d4>] iret_exc+0x7d0/0xa59 + *pdpt = 000000002258a001 *pde = 0000000000000000 + Oops: 0002 [#1] PREEMPT SMP + ... + +Despite being an **Oops** or some other sort of stack trace, the offended +line is usually required to identify and handle the bug. Along this chapter, +we'll refer to "Oops" for all kinds of stack traces that need to be analized. -Last updated: 20 December 2005 - -Introduction -============ - -Always try the latest kernel from kernel.org and build from source. If you are -not confident in doing that please report the bug to your distribution vendor -instead of to a kernel developer. - -Finding bugs is not always easy. Have a go though. If you can't find it don't -give up. Report as much as you have found to the relevant maintainer. See -MAINTAINERS for who that is for the subsystem you have worked on. - -Before you submit a bug report read -:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`. +.. note:: -Devices not appearing -===================== + ``ksymoops`` is useless on 2.6 or upper. Please use the Oops in its original + format (from ``dmesg``, etc). Ignore any references in this or other docs to + "decoding the Oops" or "running it through ksymoops". + If you post an Oops from 2.6+ that has been run through ``ksymoops``, + people will just tell you to repost it. -Often this is caused by udev. Check that first before blaming it on the -kernel. +Where is the Oops message is located? +------------------------------------- -Finding patch that caused a bug -=============================== +Normally the Oops text is read from the kernel buffers by klogd and +handed to ``syslogd`` which writes it to a syslog file, typically +``/var/log/messages`` (depends on ``/etc/syslog.conf``). On systems with +systemd, it may also be stored by the ``journald`` daemon, and accessed +by running ``journalctl`` command. +Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to +read the data from the kernel buffers and save it. Or you can +``cat /proc/kmsg > file``, however you have to break in to stop the transfer, +``kmsg`` is a "never ending file". +If the machine has crashed so badly that you cannot enter commands or +the disk is not available then you have three options: -Finding using ``git-bisect`` ----------------------------- +(1) Hand copy the text from the screen and type it in after the machine + has restarted. Messy but it is the only option if you have not + planned for a crash. Alternatively, you can take a picture of + the screen with a digital camera - not nice, but better than + nothing. If the messages scroll off the top of the console, you + may find that booting with a higher resolution (eg, ``vga=791``) + will allow you to read more of the text. (Caveat: This needs ``vesafb``, + so won't help for 'early' oopses) -Using the provided tools with ``git`` makes finding bugs easy provided the bug -is reproducible. +(2) Boot with a serial console (see + :ref:`Documentation/admin-guide/serial-console.rst <serial_console>`), + run a null modem to a second machine and capture the output there + using your favourite communication program. Minicom works well. -Steps to do it: +(3) Use Kdump (see Documentation/kdump/kdump.txt), + extract the kernel ring buffer from old memory with using dmesg + gdbmacro in Documentation/kdump/gdbmacros.txt. -- start using git for the kernel source -- read the man page for ``git-bisect`` -- have fun +Finding the bug's location +-------------------------- -Finding it the old way ----------------------- +Reporting a bug works best if you point the location of the bug at the +Kernel source file. There are two methods for doing that. Usually, using +``gdb`` is easier, but the Kernel should be pre-compiled with debug info. -[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO [email protected] (Larry McVoy)] +gdb +^^^ -This is how to track down a bug if you know nothing about kernel hacking. -It's a brute force approach but it works pretty well. +The GNU debug (``gdb``) is the best way to figure out the exact file and line +number of the OOPS from the ``vmlinux`` file. -You need: +The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``. +This can be set by running:: - - A reproducible bug - it has to happen predictably (sorry) - - All the kernel tar files from a revision that worked to the - revision that doesn't + $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO -You will then do: +On a kernel compiled with ``CONFIG_DEBUG_INFO``, you can simply copy the +EIP value from the OOPS:: - - Rebuild a revision that you believe works, install, and verify that. - - Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but - you know that 1.3.69 does. Pick a kernel in the middle and build - that, like 1.3.50. Build & test; if it works, pick the mid point - between .50 and .69, else the mid point between .28 and .50. - - You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + EIP: 0060:[<c021e50e>] Not tainted VLI - - Narrow it down to a subdirectory +And use GDB to translate that to human-readable form:: - - Copy kernel that works into "test". Let's say that 3.62 works, - but 3.63 doesn't. So you diff -r those two kernels and come - up with a list of directories that changed. For each of those - directories: + $ gdb vmlinux + (gdb) l *0xc021e50e - Copy the non-working directory next to the working directory - as "dir.63". - One directory at time, try moving the working directory to - "dir.62" and mv dir.63 dir"time, try:: +If you don't have ``CONFIG_DEBUG_INFO`` enabled, you use the function +offset from the OOPS:: - mv dir dir.62 - mv dir.63 dir - find dir -name '*.[oa]' -print | xargs rm -f + EIP is at vt_ioctl+0xda8/0x1482 - And then rebuild and retest. Assuming that all related - changes were contained in the sub directory, this should - isolate the change to a directory. +And recompile the kernel with ``CONFIG_DEBUG_INFO`` enabled:: - Problems: changes in header files may have occurred; I've - found in my case that they were self explanatory - you may - or may not want to give up when that happens. + $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO + $ make vmlinux + $ gdb vmlinux + (gdb) l *vt_ioctl+0xda8 + 0x1888 is in vt_ioctl (drivers/tty/vt/vt_ioctl.c:293). + 288 { + 289 struct vc_data *vc = NULL; + 290 int ret = 0; + 291 + 292 console_lock(); + 293 if (VT_BUSY(vc_num)) + 294 ret = -EBUSY; + 295 else if (vc_num) + 296 vc = vc_deallocate(vc_num); + 297 console_unlock(); + +or, if you want to be more verbose:: - - Narrow it down to a file + (gdb) p vt_ioctl + $1 = {int (struct tty_struct *, unsigned int, unsigned long)} 0xae0 <vt_ioctl> + (gdb) l *0xae0+0xda8 - - You can apply the same technique to each file in the directory, - hoping that the changes in that file are self contained. +You could, instead, use the object file:: - - Narrow it down to a routine + $ make drivers/tty/ + $ gdb drivers/tty/vt/vt_ioctl.o + (gdb) l *vt_ioctl+0xda8 - - You can take the old file and the new file and manually create - a merged file that has:: +If you have a call trace, such as:: - #ifdef VER62 - routine() - { - ... - } - #else - routine() - { - ... - } - #endif + Call Trace: + [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5 + [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e + [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee + ... - And then walk through that file, one routine at a time and - prefix it with:: +this shows the problem likely in the :jbd: module. You can load that module +in gdb and list the relevant code:: - #define VER62 - /* both routines here */ - #undef VER62 + $ gdb fs/jbd/jbd.ko + (gdb) l *log_wait_commit+0xa3 - Then recompile, retest, move the ifdefs until you find the one - that makes the difference. +.. note:: -Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass -that off to whomever you believe is the maintainer of that section. -A post to linux.dev.kernel isn't such a bad idea if you've done some -work to narrow it down. + You can also do the same for any function call at the stack trace, + like this one:: -If you get it down to a routine, you'll probably get a fix in 24 hours. + [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb] -My apologies to Linus and the other kernel hackers for describing this -brute force approach, it's hardly what a kernel hacker would do. However, -it does work and it lets non-hackers help fix bugs. And it is cool -because Linux snapshots will let you do this - something that you can't -do with vendor supplied releases. + The position where the above call happened can be seen with:: -Fixing the bug -============== + $ gdb drivers/media/usb/dvb-usb/dvb-usb.o + (gdb) l *dvb_usb_adapter_frontend_exit+0x3a -Nobody is going to tell you how to fix bugs. Seriously. You need to work it -out. But below are some hints on how to use the tools. +objdump +^^^^^^^ To debug a kernel, use objdump and look for the hex offset from the crash output to find the valid line of code/assembler. Without debug symbols, you @@ -147,7 +192,7 @@ will see the assembler code for the routine shown, but if your kernel has debug symbols the C code will also be available. (Debug symbols can be enabled in the kernel hacking menu of the menu configuration.) For example:: - objdump -r -S -l --disassemble net/dccp/ipv4.o + $ objdump -r -S -l --disassemble net/dccp/ipv4.o .. note:: @@ -157,7 +202,7 @@ in the kernel hacking menu of the menu configuration.) For example:: If you don't have access to the code you can also debug on some crash dumps e.g. crash dump output as shown by Dave Miller:: - EIP is at ip_queue_xmit+0x14/0x4c0 + EIP is at +0x14/0x4c0 ... Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08 @@ -185,65 +230,140 @@ e.g. crash dump output as shown by Dave Miller:: mov 0x8(%ebp), %ebx ! %ebx = skb->sk mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt -In addition, you can use GDB to figure out the exact file and line -number of the OOPS from the ``vmlinux`` file. If you have -``CONFIG_DEBUG_INFO`` enabled, you can simply copy the EIP value from the -OOPS:: - - EIP: 0060:[<c021e50e>] Not tainted VLI - -And use GDB to translate that to human-readable form:: - - gdb vmlinux - (gdb) l *0xc021e50e - -If you don't have ``CONFIG_DEBUG_INFO`` enabled, you use the function -offset from the OOPS:: - - EIP is at vt_ioctl+0xda8/0x1482 - -And recompile the kernel with ``CONFIG_DEBUG_INFO`` enabled:: +Reporting the bug +----------------- - make vmlinux - gdb vmlinux - (gdb) p vt_ioctl - (gdb) l *(0x<address of vt_ioctl> + 0xda8) +Once you find where the bug happened, by inspecting its location, +you could either try to fix it yourself or report it upstream. -or, as one command:: +In order to report it upstream, you should identify the mailing list +used for the development of the affected code. This can be done by using +the ``get_maintainer.pl`` script. - (gdb) l *(vt_ioctl + 0xda8) +For example, if you find a bug at the gspca's conex.c file, you can get +their maintainers with:: -If you have a call trace, such as:: + $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c + Hans Verkuil <[email protected]> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%) + Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%) + Tejun Heo <[email protected]> (commit_signer:1/1=100%) + Bhaktipriya Shridhar <[email protected]> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:4/4=100%,removed_lines:9/9=100%) + [email protected] (open list:GSPCA USB WEBCAM DRIVER) + [email protected] (open list) - Call Trace: - [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5 - [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e - [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee - ... +Please notice that it will point to: -this shows the problem in the :jbd: module. You can load that module in gdb -and list the relevant code:: +- The last developers that touched on the source code. On the above example, + Tejun and Bhaktipriya (in this specific case, none really envolved on the + development of this file); +- The driver maintainer (Hans Verkuil); +- The subsystem maintainer (Mauro Carvalho Chehab) +- The driver and/or subsystem mailing list ([email protected]); +- the Linux Kernel mailing list ([email protected]). - gdb fs/jbd/jbd.ko - (gdb) p log_wait_commit - (gdb) l *(0x<address> + 0xa3) +Usually, the fastest way to have your bug fixed is to report it to mailing +list used for the development of the code (linux-media ML) copying the driver maintainer (Hans). -or:: +If you are totally stumped as to whom to send the report, and +``get_maintainer.pl`` didn't provide you anything useful, send it to - (gdb) l *(log_wait_commit + 0xa3) +Thanks for your help in making Linux as stable as humanly possible. +Fixing the bug +-------------- -Another very useful option of the Kernel Hacking section in menuconfig is -Debug memory allocations. This will help you see whether data has been -initialised and not set before use etc. To see the values that get assigned -with this look at ``mm/slab.c`` and search for ``POISON_INUSE``. When using -this an Oops will often show the poisoned data instead of zero which is the -default. +If you know programming, you could help us by not only reporting the bug, +but also providing us with a solution. After all open source is about +sharing what you do and don't you want to be recognised for your genius? -Once you have worked out a fix please submit it upstream. After all open -source is about sharing what you do and don't you want to be recognised for -your genius? +If you decide to take this way, once you have worked out a fix please submit +it upstream. Please do read ref:`Documentation/process/submitting-patches.rst <submittingpatches>` though to help your code get accepted. + + +--------------------------------------------------------------------------- + +Notes on Oops tracing with ``klogd`` +------------------------------------ + +In order to help Linus and the other kernel developers there has been +substantial support incorporated into ``klogd`` for processing protection +faults. In order to have full support for address resolution at least +version 1.3-pl3 of the ``sysklogd`` package should be used. + +When a protection fault occurs the ``klogd`` daemon automatically +translates important addresses in the kernel log messages to their +symbolic equivalents. This translated kernel message is then +forwarded through whatever reporting mechanism ``klogd`` is using. The +protection fault message can be simply cut out of the message files +and forwarded to the kernel developers. + +Two types of address resolution are performed by ``klogd``. The first is +static translation and the second is dynamic translation. Static +translation uses the System.map file in much the same manner that +ksymoops does. In order to do static translation the ``klogd`` daemon +must be able to find a system map file at daemon initialization time. +See the klogd man page for information on how ``klogd`` searches for map +files. + +Dynamic address translation is important when kernel loadable modules +are being used. Since memory for kernel modules is allocated from the +kernel's dynamic memory pools there are no fixed locations for either +the start of the module or for functions and symbols in the module. + +The kernel supports system calls which allow a program to determine +which modules are loaded and their location in memory. Using these +system calls the klogd daemon builds a symbol table which can be used +to debug a protection fault which occurs in a loadable kernel module. + +At the very minimum klogd will provide the name of the module which +generated the protection fault. There may be additional symbolic +information available if the developer of the loadable module chose to +export symbol information from the module. + +Since the kernel module environment can be dynamic there must be a +mechanism for notifying the ``klogd`` daemon when a change in module +environment occurs. There are command line options available which +allow klogd to signal the currently executing daemon that symbol +information should be refreshed. See the ``klogd`` manual page for more +information. + +A patch is included with the sysklogd distribution which modifies the +``modules-2.0.0`` package to automatically signal klogd whenever a module +is loaded or unloaded. Applying this patch provides essentially +seamless support for debugging protection faults which occur with +kernel loadable modules. + +The following is an example of a protection fault in a loadable module +processed by ``klogd``:: + + Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc + Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000 + Aug 29 09:51:01 blizard kernel: *pde = 00000000 + Aug 29 09:51:01 blizard kernel: Oops: 0002 + Aug 29 09:51:01 blizard kernel: CPU: 0 + Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868] + Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212 + Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c + Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c + Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 + Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000) + Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 + Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 + Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 + Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] + Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 + +--------------------------------------------------------------------------- + +:: + + Dr. G.W. Wettstein Oncology Research Div. Computing Facility + Roger Maris Cancer Center INTERNET: [email protected] + 820 4th St. N. + Fargo, ND 58122 + Phone: 701-234-7556 diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 368845e9900a..2681cbd24cdd 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -8,7 +8,7 @@ document! With luck things will improve quickly over time. This initial section contains overall information, including the README file describing the kernel as a whole, documentation on kernel parameters, -etc. +etc. .. toctree:: :maxdepth: 1 @@ -22,11 +22,12 @@ problems and bugs in particular. .. toctree:: :maxdepth: 1 - + reporting-bugs security-bugs bug-hunting - oops-tracing + bug-bisect + tainted-kernels ramoops dynamic-debug-howto init @@ -37,7 +38,7 @@ ABI will be found here. .. toctree:: :maxdepth: 1 - + sysfs-rules The rest of this manual consists of various unordered guides on how to @@ -45,7 +46,7 @@ configure specific aspects of kernel behavior to your liking. .. toctree:: :maxdepth: 1 - + initrd serial-console braille-console diff --git a/Documentation/admin-guide/oops-tracing.rst b/Documentation/admin-guide/oops-tracing.rst deleted file mode 100644 index 13be8d7bcfe7..000000000000 --- a/Documentation/admin-guide/oops-tracing.rst +++ /dev/null @@ -1,300 +0,0 @@ -OOPS tracing -============ - -.. note:: - - ``ksymoops`` is useless on 2.6 or upper. Please use the Oops in its original - format (from ``dmesg``, etc). Ignore any references in this or other docs to - "decoding the Oops" or "running it through ksymoops". - If you post an Oops from 2.6+ that has been run through ``ksymoops``, - people will just tell you to repost it. - -Quick Summary -------------- - -Find the Oops and send it to the maintainer of the kernel area that seems to be -involved with the problem. Don't worry too much about getting the wrong person. -If you are unsure send it to the person responsible for the code relevant to -what you were doing. If it occurs repeatably try and describe how to recreate -it. That's worth even more than the oops. - -If you are totally stumped as to whom to send the report, send it to [email protected]. Thanks for your help in making Linux as -stable as humanly possible. - -Where is the Oops? ----------------------- - -Normally the Oops text is read from the kernel buffers by klogd and -handed to ``syslogd`` which writes it to a syslog file, typically -``/var/log/messages`` (depends on ``/etc/syslog.conf``). Sometimes ``klogd`` -dies, in which case you can run ``dmesg > file`` to read the data from the -kernel buffers and save it. Or you can ``cat /proc/kmsg > file``, however you -have to break in to stop the transfer, ``kmsg`` is a "never ending file". -If the machine has crashed so badly that you cannot enter commands or -the disk is not available then you have three options : - -(1) Hand copy the text from the screen and type it in after the machine - has restarted. Messy but it is the only option if you have not - planned for a crash. Alternatively, you can take a picture of - the screen with a digital camera - not nice, but better than - nothing. If the messages scroll off the top of the console, you - may find that booting with a higher resolution (eg, ``vga=791``) - will allow you to read more of the text. (Caveat: This needs ``vesafb``, - so won't help for 'early' oopses) - -(2) Boot with a serial console (see - :ref:`Documentation/admin-guide/serial-console.rst <serial_console>`), - run a null modem to a second machine and capture the output there - using your favourite communication program. Minicom works well. - -(3) Use Kdump (see Documentation/kdump/kdump.txt), - extract the kernel ring buffer from old memory with using dmesg - gdbmacro in Documentation/kdump/gdbmacros.txt. - - -Full Information ----------------- - -.. note:: - - the message from Linus below applies to 2.4 kernel. I have preserved it - for historical reasons, and because some of the information in it still - applies. Especially, please ignore any references to ksymoops. - - :: - - From: Linus Torvalds <[email protected]> - - How to track down an Oops.. [originally a mail to linux-kernel] - - The main trick is having 5 years of experience with those pesky oops - messages ;-) - -Actually, there are things you can do that make this easier. I have two -separate approaches:: - - gdb /usr/src/linux/vmlinux - gdb> disassemble <offending_function> - -That's the easy way to find the problem, at least if the bug-report is -well made (like this one was - run through ``ksymoops`` to get the -information of which function and the offset in the function that it -happened in). - -Oh, it helps if the report happens on a kernel that is compiled with the -same compiler and similar setups. - -The other thing to do is disassemble the "Code:" part of the bug report: -ksymoops will do this too with the correct tools, but if you don't have -the tools you can just do a silly program:: - - char str[] = "\xXX\xXX\xXX..."; - main(){} - -and compile it with ``gcc -g`` and then do ``disassemble str`` (where the ``XX`` -stuff are the values reported by the Oops - you can just cut-and-paste -and do a replace of spaces to ``\x`` - that's what I do, as I'm too lazy -to write a program to automate this all). - -Alternatively, you can use the shell script in ``scripts/decodecode``. -Its usage is:: - - decodecode < oops.txt - -The hex bytes that follow "Code:" may (in some architectures) have a series -of bytes that precede the current instruction pointer as well as bytes at and -following the current instruction pointer. In some cases, one instruction -byte or word is surrounded by ``<>`` or ``()``, as in ``<86>`` or ``(f00d)``. -These ``<>`` or ``()`` markings indicate the current instruction pointer. - -Example from i386, split into multiple lines for readability:: - - Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1 - 64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54 - 7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0 - -Finally, if you want to see where the code comes from, you can do:: - - cd /usr/src/linux - make fs/buffer.s # or whatever file the bug happened in - -and then you get a better idea of what happens than with the gdb -disassembly. - -Now, the trick is just then to combine all the data you have: the C -sources (and general knowledge of what it **should** do), the assembly -listing and the code disassembly (and additionally the register dump you -also get from the "oops" message - that can be useful to see **what** the -corrupted pointers were, and when you have the assembler listing you can -also match the other registers to whatever C expressions they were used -for). - -Essentially, you just look at what doesn't match (in this case it was the -"Code" disassembly that didn't match with what the compiler generated). -Then you need to find out **why** they don't match. Often it's simple - you -see that the code uses a NULL pointer and then you look at the code and -wonder how the NULL pointer got there, and if it's a valid thing to do -you just check against it.. - -Now, if somebody gets the idea that this is time-consuming and requires -some small amount of concentration, you're right. Which is why I will -mostly just ignore any panic reports that don't have the symbol table -info etc looked up: it simply gets too hard to look it up (I have some -programs to search for specific patterns in the kernel code segment, and -sometimes I have been able to look up those kinds of panics too, but -that really requires pretty good knowledge of the kernel just to be able -to pick out the right sequences etc..) - -**Sometimes** it happens that I just see the disassembled code sequence -from the panic, and I know immediately where it's coming from. That's when -I get worried that I've been doing this for too long ;-) - - Linus - - ---------------------------------------------------------------------------- - -Notes on Oops tracing with ``klogd`` ------------------------------------- - -In order to help Linus and the other kernel developers there has been -substantial support incorporated into ``klogd`` for processing protection -faults. In order to have full support for address resolution at least -version 1.3-pl3 of the ``sysklogd`` package should be used. - -When a protection fault occurs the ``klogd`` daemon automatically -translates important addresses in the kernel log messages to their -symbolic equivalents. This translated kernel message is then -forwarded through whatever reporting mechanism ``klogd`` is using. The -protection fault message can be simply cut out of the message files -and forwarded to the kernel developers. - -Two types of address resolution are performed by ``klogd``. The first is -static translation and the second is dynamic translation. Static -translation uses the System.map file in much the same manner that -ksymoops does. In order to do static translation the ``klogd`` daemon -must be able to find a system map file at daemon initialization time. -See the klogd man page for information on how ``klogd`` searches for map -files. - -Dynamic address translation is important when kernel loadable modules -are being used. Since memory for kernel modules is allocated from the -kernel's dynamic memory pools there are no fixed locations for either -the start of the module or for functions and symbols in the module. - -The kernel supports system calls which allow a program to determine -which modules are loaded and their location in memory. Using these -system calls the klogd daemon builds a symbol table which can be used -to debug a protection fault which occurs in a loadable kernel module. - -At the very minimum klogd will provide the name of the module which -generated the protection fault. There may be additional symbolic -information available if the developer of the loadable module chose to -export symbol information from the module. - -Since the kernel module environment can be dynamic there must be a -mechanism for notifying the ``klogd`` daemon when a change in module -environment occurs. There are command line options available which -allow klogd to signal the currently executing daemon that symbol -information should be refreshed. See the ``klogd`` manual page for more -information. - -A patch is included with the sysklogd distribution which modifies the -``modules-2.0.0`` package to automatically signal klogd whenever a module -is loaded or unloaded. Applying this patch provides essentially -seamless support for debugging protection faults which occur with -kernel loadable modules. - -The following is an example of a protection fault in a loadable module -processed by ``klogd``:: - - Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc - Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000 - Aug 29 09:51:01 blizard kernel: *pde = 00000000 - Aug 29 09:51:01 blizard kernel: Oops: 0002 - Aug 29 09:51:01 blizard kernel: CPU: 0 - Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868] - Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212 - Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c - Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c - Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 - Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000) - Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 - Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 - Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 - Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] - Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 - ---------------------------------------------------------------------------- - -:: - - Dr. G.W. Wettstein Oncology Research Div. Computing Facility - Roger Maris Cancer Center INTERNET: [email protected] - 820 4th St. N. - Fargo, ND 58122 - Phone: 701-234-7556 - - ---------------------------------------------------------------------------- - -Tainted kernels ---------------- - -Some oops reports contain the string **'Tainted: '** after the program -counter. This indicates that the kernel has been tainted by some -mechanism. The string is followed by a series of position-sensitive -characters, each representing a particular tainted value. - - 1) 'G' if all modules loaded have a GPL or compatible license, 'P' if - any proprietary module has been loaded. Modules without a - MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by - insmod as GPL compatible are assumed to be proprietary. - - 2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all - modules were loaded normally. - - 3) ``S`` if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. - - 4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all - modules were unloaded normally. - - 5) ``M`` if any processor has reported a Machine Check Exception, - ``' '`` if no Machine Check Exceptions have occurred. - - 6) ``B`` if a page-release function has found a bad page reference or - some unexpected page flags. - - 7) ``U`` if a user or user application specifically requested that the - Tainted flag be set, ``' '`` otherwise. - - 8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG. - - 9) ``A`` if the ACPI table has been overridden. - - 10) ``W`` if a warning has previously been issued by the kernel. - (Though some warnings may set more specific taint flags.) - - 11) ``C`` if a staging driver has been loaded. - - 12) ``I`` if the kernel is working around a severe bug in the platform - firmware (BIOS or similar). - - 13) ``O`` if an externally-built ("out-of-tree") module has been loaded. - - 14) ``E`` if an unsigned module has been loaded in a kernel supporting - module signature. - - 15) ``L`` if a soft lockup has previously occurred on the system. - - 16) ``K`` if the kernel has been live patched. - -The primary reason for the **'Tainted: '** string is to tell kernel -debuggers if this is a clean kernel or if anything unusual has -occurred. Tainting is permanent: even if an offending module is -unloaded, the tainted value remains to indicate that the kernel is not -trustworthy. diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst new file mode 100644 index 000000000000..1df03b5cb02f --- /dev/null +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -0,0 +1,59 @@ +Tainted kernels +--------------- + +Some oops reports contain the string **'Tainted: '** after the program +counter. This indicates that the kernel has been tainted by some +mechanism. The string is followed by a series of position-sensitive +characters, each representing a particular tainted value. + + 1) 'G' if all modules loaded have a GPL or compatible license, 'P' if + any proprietary module has been loaded. Modules without a + MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by + insmod as GPL compatible are assumed to be proprietary. + + 2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all + modules were loaded normally. + + 3) ``S`` if the oops occurred on an SMP kernel running on hardware that + hasn't been certified as safe to run multiprocessor. + Currently this occurs only on various Athlons that are not + SMP capable. + + 4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all + modules were unloaded normally. + + 5) ``M`` if any processor has reported a Machine Check Exception, + ``' '`` if no Machine Check Exceptions have occurred. + + 6) ``B`` if a page-release function has found a bad page reference or + some unexpected page flags. + + 7) ``U`` if a user or user application specifically requested that the + Tainted flag be set, ``' '`` otherwise. + + 8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG. + + 9) ``A`` if the ACPI table has been overridden. + + 10) ``W`` if a warning has previously been issued by the kernel. + (Though some warnings may set more specific taint flags.) + + 11) ``C`` if a staging driver has been loaded. + + 12) ``I`` if the kernel is working around a severe bug in the platform + firmware (BIOS or similar). + + 13) ``O`` if an externally-built ("out-of-tree") module has been loaded. + + 14) ``E`` if an unsigned module has been loaded in a kernel supporting + module signature. + + 15) ``L`` if a soft lockup has previously occurred on the system. + + 16) ``K`` if the kernel has been live patched. + +The primary reason for the **'Tainted: '** string is to tell kernel +debuggers if this is a clean kernel or if anything unusual has +occurred. Tainting is permanent: even if an offending module is +unloaded, the tainted value remains to indicate that the kernel is not +trustworthy. diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py new file mode 100644 index 000000000000..fed87ab7f486 --- /dev/null +++ b/Documentation/core-api/conf.py @@ -0,0 +1,5 @@ +# -*- coding: utf-8; mode: python -*- + +project = "Core-API Documentation" + +tags.add("subproject") diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst new file mode 100644 index 000000000000..f7ef7fda5763 --- /dev/null +++ b/Documentation/core-api/index.rst @@ -0,0 +1,17 @@ +====================== +Core-API Documentation +====================== + +Kernel and driver related documentation. + +.. toctree:: + :maxdepth: 1 + + workqueue + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/workqueue.txt b/Documentation/core-api/workqueue.rst index c49e3178178d..ffdec94fbca1 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/core-api/workqueue.rst @@ -1,21 +1,14 @@ - +==================================== Concurrency Managed Workqueue (cmwq) +==================================== -September, 2010 Tejun Heo <[email protected]> - Florian Mickler <[email protected]> - -CONTENTS - -1. Introduction -2. Why cmwq? -3. The Design -4. Application Programming Interface (API) -5. Example Execution Scenarios -6. Guidelines -7. Debugging +:Date: September, 2010 +:Author: Tejun Heo <[email protected]> +:Author: Florian Mickler <[email protected]> -1. Introduction +Introduction +============ There are many cases where an asynchronous process execution context is needed and the workqueue (wq) API is the most commonly used @@ -32,7 +25,8 @@ there is no work item left on the workqueue the worker becomes idle. When a new work item gets queued, the worker begins executing again. -2. Why cmwq? +Why cmwq? +========= In the original wq implementation, a multi threaded (MT) wq had one worker thread per CPU and a single threaded (ST) wq had one worker @@ -71,7 +65,8 @@ focus on the following goals. the API users don't need to worry about such details. -3. The Design +The Design +========== In order to ease the asynchronous execution of functions a new abstraction, the work item, is introduced. @@ -102,7 +97,7 @@ aspects of the way the work items are executed by setting flags on the workqueue they are putting the work item on. These flags include things like CPU locality, concurrency limits, priority and more. To get a detailed overview refer to the API description of -alloc_workqueue() below. +``alloc_workqueue()`` below. When a work item is queued to a workqueue, the target worker-pool is determined according to the queue parameters and workqueue attributes @@ -136,7 +131,7 @@ them. For unbound workqueues, the number of backing pools is dynamic. Unbound workqueue can be assigned custom attributes using -apply_workqueue_attrs() and workqueue will automatically create +``apply_workqueue_attrs()`` and workqueue will automatically create backing worker pools matching the attributes. The responsibility of regulating concurrency level is on the users. There is also a flag to mark a bound wq to ignore the concurrency management. Please refer to @@ -151,94 +146,95 @@ pressure. Else it is possible that the worker-pool deadlocks waiting for execution contexts to free up. -4. Application Programming Interface (API) +Application Programming Interface (API) +======================================= -alloc_workqueue() allocates a wq. The original create_*workqueue() -functions are deprecated and scheduled for removal. alloc_workqueue() -takes three arguments - @name, @flags and @max_active. @name is the -name of the wq and also used as the name of the rescuer thread if -there is one. +``alloc_workqueue()`` allocates a wq. The original +``create_*workqueue()`` functions are deprecated and scheduled for +removal. ``alloc_workqueue()`` takes three arguments - @``name``, +``@flags`` and ``@max_active``. ``@name`` is the name of the wq and +also used as the name of the rescuer thread if there is one. A wq no longer manages execution resources but serves as a domain for -forward progress guarantee, flush and work item attributes. @flags -and @max_active control how work items are assigned execution +forward progress guarantee, flush and work item attributes. ``@flags`` +and ``@max_active`` control how work items are assigned execution resources, scheduled and executed. -@flags: - - WQ_UNBOUND - - Work items queued to an unbound wq are served by the special - worker-pools which host workers which are not bound to any - specific CPU. This makes the wq behave as a simple execution - context provider without concurrency management. The unbound - worker-pools try to start execution of work items as soon as - possible. Unbound wq sacrifices locality but is useful for - the following cases. - - * Wide fluctuation in the concurrency level requirement is - expected and using bound wq may end up creating large number - of mostly unused workers across different CPUs as the issuer - hops through different CPUs. - - * Long running CPU intensive workloads which can be better - managed by the system scheduler. - - WQ_FREEZABLE - - A freezable wq participates in the freeze phase of the system - suspend operations. Work items on the wq are drained and no - new work item starts execution until thawed. - - WQ_MEM_RECLAIM - - All wq which might be used in the memory reclaim paths _MUST_ - have this flag set. The wq is guaranteed to have at least one - execution context regardless of memory pressure. - - WQ_HIGHPRI - Work items of a highpri wq are queued to the highpri - worker-pool of the target cpu. Highpri worker-pools are - served by worker threads with elevated nice level. - - Note that normal and highpri worker-pools don't interact with - each other. Each maintain its separate pool of workers and - implements concurrency management among its workers. - - WQ_CPU_INTENSIVE - - Work items of a CPU intensive wq do not contribute to the - concurrency level. In other words, runnable CPU intensive - work items will not prevent other work items in the same - worker-pool from starting execution. This is useful for bound - work items which are expected to hog CPU cycles so that their - execution is regulated by the system scheduler. - - Although CPU intensive work items don't contribute to the - concurrency level, start of their executions is still - regulated by the concurrency management and runnable - non-CPU-intensive work items can delay execution of CPU - intensive work items. - - This flag is meaningless for unbound wq. - -Note that the flag WQ_NON_REENTRANT no longer exists as all workqueues -are now non-reentrant - any work item is guaranteed to be executed by -at most one worker system-wide at any given time. - -@max_active: - -@max_active determines the maximum number of execution contexts per -CPU which can be assigned to the work items of a wq. For example, -with @max_active of 16, at most 16 work items of the wq can be +``flags`` +--------- + +``WQ_UNBOUND`` + Work items queued to an unbound wq are served by the special + worker-pools which host workers which are not bound to any + specific CPU. This makes the wq behave as a simple execution + context provider without concurrency management. The unbound + worker-pools try to start execution of work items as soon as + possible. Unbound wq sacrifices locality but is useful for + the following cases. + + * Wide fluctuation in the concurrency level requirement is + expected and using bound wq may end up creating large number + of mostly unused workers across different CPUs as the issuer + hops through different CPUs. + + * Long running CPU intensive workloads which can be better + managed by the system scheduler. + +``WQ_FREEZABLE`` + A freezable wq participates in the freeze phase of the system + suspend operations. Work items on the wq are drained and no + new work item starts execution until thawed. + +``WQ_MEM_RECLAIM`` + All wq which might be used in the memory reclaim paths **MUST** + have this flag set. The wq is guaranteed to have at least one + execution context regardless of memory pressure. + +``WQ_HIGHPRI`` + Work items of a highpri wq are queued to the highpri + worker-pool of the target cpu. Highpri worker-pools are + served by worker threads with elevated nice level. + + Note that normal and highpri worker-pools don't interact with + each other. Each maintain its separate pool of workers and + implements concurrency management among its workers. + +``WQ_CPU_INTENSIVE`` + Work items of a CPU intensive wq do not contribute to the + concurrency level. In other words, runnable CPU intensive + work items will not prevent other work items in the same + worker-pool from starting execution. This is useful for bound + work items which are expected to hog CPU cycles so that their + execution is regulated by the system scheduler. + + Although CPU intensive work items don't contribute to the + concurrency level, start of their executions is still + regulated by the concurrency management and runnable + non-CPU-intensive work items can delay execution of CPU + intensive work items. + + This flag is meaningless for unbound wq. + +Note that the flag ``WQ_NON_REENTRANT`` no longer exists as all +workqueues are now non-reentrant - any work item is guaranteed to be +executed by at most one worker system-wide at any given time. + + +``max_active`` +-------------- + +``@max_active`` determines the maximum number of execution contexts +per CPU which can be assigned to the work items of a wq. For example, +with ``@max_active`` of 16, at most 16 work items of the wq can be executing at the same time per CPU. -Currently, for a bound wq, the maximum limit for @max_active is 512 -and the default value used when 0 is specified is 256. For an unbound -wq, the limit is higher of 512 and 4 * num_possible_cpus(). These -values are chosen sufficiently high such that they are not the -limiting factor while providing protection in runaway cases. +Currently, for a bound wq, the maximum limit for ``@max_active`` is +512 and the default value used when 0 is specified is 256. For an +unbound wq, the limit is higher of 512 and 4 * +``num_possible_cpus()``. These values are chosen sufficiently high +such that they are not the limiting factor while providing protection +in runaway cases. The number of active work items of a wq is usually regulated by the users of the wq, more specifically, by how many work items the users @@ -247,13 +243,14 @@ throttling the number of active work items, specifying '0' is recommended. Some users depend on the strict execution ordering of ST wq. The -combination of @max_active of 1 and WQ_UNBOUND is used to achieve this -behavior. Work items on such wq are always queued to the unbound -worker-pools and only one work item can be active at any given time thus -achieving the same ordering property as ST wq. +combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` is used to +achieve this behavior. Work items on such wq are always queued to the +unbound worker-pools and only one work item can be active at any given +time thus achieving the same ordering property as ST wq. -5. Example Execution Scenarios +Example Execution Scenarios +=========================== The following example execution scenarios try to illustrate how cmwq behave under different configurations. @@ -265,7 +262,7 @@ behave under different configurations. Ignoring all other tasks, works and processing overhead, and assuming simple FIFO scheduling, the following is one highly simplified version -of possible sequences of events with the original wq. +of possible sequences of events with the original wq. :: TIME IN MSECS EVENT 0 w0 starts and burns CPU @@ -279,7 +276,7 @@ of possible sequences of events with the original wq. 40 w2 sleeps 50 w2 wakes up and finishes -And with cmwq with @max_active >= 3, +And with cmwq with ``@max_active`` >= 3, :: TIME IN MSECS EVENT 0 w0 starts and burns CPU @@ -293,7 +290,7 @@ And with cmwq with @max_active >= 3, 20 w1 wakes up and finishes 25 w2 wakes up and finishes -If @max_active == 2, +If ``@max_active`` == 2, :: TIME IN MSECS EVENT 0 w0 starts and burns CPU @@ -308,7 +305,7 @@ If @max_active == 2, 35 w2 wakes up and finishes Now, let's assume w1 and w2 are queued to a different wq q1 which has -WQ_CPU_INTENSIVE set, +``WQ_CPU_INTENSIVE`` set, :: TIME IN MSECS EVENT 0 w0 starts and burns CPU @@ -322,13 +319,15 @@ WQ_CPU_INTENSIVE set, 25 w2 wakes up and finishes -6. Guidelines +Guidelines +========== -* Do not forget to use WQ_MEM_RECLAIM if a wq may process work items - which are used during memory reclaim. Each wq with WQ_MEM_RECLAIM - set has an execution context reserved for it. If there is - dependency among multiple work items used during memory reclaim, - they should be queued to separate wq each with WQ_MEM_RECLAIM. +* Do not forget to use ``WQ_MEM_RECLAIM`` if a wq may process work + items which are used during memory reclaim. Each wq with + ``WQ_MEM_RECLAIM`` set has an execution context reserved for it. If + there is dependency among multiple work items used during memory + reclaim, they should be queued to separate wq each with + ``WQ_MEM_RECLAIM``. * Unless strict ordering is required, there is no need to use ST wq. @@ -337,30 +336,31 @@ WQ_CPU_INTENSIVE set, well under the default limit. * A wq serves as a domain for forward progress guarantee - (WQ_MEM_RECLAIM, flush and work item attributes. Work items which - are not involved in memory reclaim and don't need to be flushed as a - part of a group of work items, and don't require any special - attribute, can use one of the system wq. There is no difference in - execution characteristics between using a dedicated wq and a system - wq. + (``WQ_MEM_RECLAIM``, flush and work item attributes. Work items + which are not involved in memory reclaim and don't need to be + flushed as a part of a group of work items, and don't require any + special attribute, can use one of the system wq. There is no + difference in execution characteristics between using a dedicated wq + and a system wq. * Unless work items are expected to consume a huge amount of CPU cycles, using a bound wq is usually beneficial due to the increased level of locality in wq operations and work item execution. -7. Debugging +Debugging +========= Because the work functions are executed by generic worker threads there are a few tricks needed to shed some light on misbehaving workqueue users. -Worker threads show up in the process list as: +Worker threads show up in the process list as: :: -root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1] -root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2] -root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0] -root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0] + root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1] + root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2] + root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0] + root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0] If kworkers are going crazy (using too much cpu), there are two types of possible problems: @@ -368,7 +368,7 @@ of possible problems: 1. Something being scheduled in rapid succession 2. A single work item that consumes lots of cpu cycles -The first one can be tracked using tracing: +The first one can be tracked using tracing: :: $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt @@ -380,9 +380,15 @@ the output and the offender can be determined with the work item function. For the second type of problems it should be possible to just check -the stack trace of the offending worker thread. +the stack trace of the offending worker thread. :: $ cat /proc/THE_OFFENDING_KWORKER/stack The work item's function should be trivially visible in the stack trace. + + +Kernel Inline Documentations Reference +====================================== + +.. kernel-doc:: include/linux/workqueue.h diff --git a/Documentation/index.rst b/Documentation/index.rst index 85a66270f96c..3bb82fb11a4d 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -53,6 +53,7 @@ needed). :maxdepth: 2 driver-api/index + core-api/index media/index gpu/index 80211/index diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO index 025252731af5..3b0c15b277e0 100644 --- a/Documentation/ko_KR/HOWTO +++ b/Documentation/ko_KR/HOWTO @@ -9,17 +9,20 @@ read for non English (read: korean) speakers and is not intended as a fork. So if you have any comments or updates for this file please try to update the original English file first. -================================== +---------------------------------- + 이 문서는 Documentation/process/howto.rst 의 한글 번역입니다. 역자： 김민찬 <[email protected]> 감수： 이제이미 <[email protected]> -================================== + +---------------------------------- + 어떻게 리눅스 커널 개발을 하는가 ---------------------------------- +================================ 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는 @@ -46,6 +49,7 @@ Documentation/process/howto.rst 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다. 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는 못하지만 적어도 참고 용도로는 좋을 것이다 + - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] - "Practical C Programming" by Steve Oualline [O'Reilly] - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] @@ -79,7 +83,8 @@ Documentation/process/howto.rst 그들의 말에 의지해서는 안된다. GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라. - http://www.gnu.org/licenses/gpl-faq.html + + https://www.gnu.org/licenses/gpl-faq.html 문서 @@ -93,55 +98,61 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라. [email protected]의 메인테이너에게 보낼 것을 권장한다. 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다. + README 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서 시작해야 한다. - Documentation/process/changes.rst + :ref:`Documentation/process/changes.rst <changes>` 이 파일은 커널을 성공적으로 빌드하고 실행시키기 위해 필요한 다양한 소프트웨어 패키지들의 최소 버젼을 나열한다. - Documentation/process/coding-style.rst + :ref:`Documentation/process/coding-style.rst <codingstyle>` 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다. 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의 메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다. - Documentation/process/submitting-patches.rst - Documentation/process/submitting-drivers.rst + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 와 :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다). + - Email 내용들 - Email 양식 - 그것을 누구에게 보낼지 + 이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을 보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다. 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. + "The Perfect Patch" - http://www.ozlabs.org/~akpm/stuff/tpp.txt + https://www.ozlabs.org/~akpm/stuff/tpp.txt + "Linux kernel patch submission format" http://linux.yyz.us/patch-format.html - Documentation/process/stable-api-nonsense.rst + :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>` 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한 이유를 설명하며 다음과 같은 것들을 포함한다. + - 서브시스템 shim-layer(호환성을 위해?) - 운영체제들간의 드라이버 이식성 - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것) + 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서 리눅스로 전향하는 사람들에게는 매우 중요하다. - Documentation/admin-guide/security-bugs.rst + :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` 여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에 나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록 도와 달라. - Documentation/process/management-style.rst + :ref:`Documentation/process/management-style.rst <managementstyle>` 이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는 정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이 @@ -149,38 +160,52 @@ [email protected]의 메인테이너에게 보낼 것을 권장한다. 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기 때문이다. - Documentation/process/stable-kernel-rules.rst + :ref:`Documentation/process/stable_kernel_rules.rst <stable_kernel_rules>` 이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며 여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면 무엇을 해야 하는지를 설명한다. - Documentation/process/kernel-docs.rst + :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` 커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들 중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를 살펴보라. - Documentation/process/applying-patches.rst + :ref:`Documentation/process/applying-patches.rst <applying_patches>` 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다. -커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을 -가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을 -올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는 -Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML, -그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다. +커널은 소스 코드 그 자체에서 또는 이것과 같은 ReStructuredText 마크업 (ReST) 을 +통해 자동적으로 만들어질 수 있는 많은 문서들을 가지고 있다. 이것은 커널 내의 +API에 대한 모든 설명, 그리고 락킹을 올바르게 처리하는 법에 관한 규칙을 포함하고 +있다. + +모든 그런 문서들은 커널 소스 디렉토리에서 다음 커맨드를 실행하는 것을 통해 PDF +나 HTML 의 형태로 만들어질 수 있다:: + make pdfdocs - make psdocs make htmldocs - make mandocs -각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다. +ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된다. 해당 +문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다:: + + make latexdocs + make epubdocs + +현재, ReST 로의 변환이 진행중인, DocBook 으로 쓰인 문서들이 존재한다. 그런 +문서들은 Documentation/DocBook/ 디렉토리 안에 생성될 것이고 다음 커맨드를 통해 +Postscript 나 man page 로도 만들어질 수 있다:: + + make psdocs + make mandocs 커널 개발자가 되는 것 --------------------- 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies 프로젝트를 봐야 한다. - http://kernelnewbies.org + + https://kernelnewbies.org + 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도 @@ -192,7 +217,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라. - http://kernelnewbies.org/KernelJanitors + + https://kernelnewbies.org/KernelJanitors + 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에 @@ -204,7 +231,8 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며 다음에서 참조할 수 있다. - http://selenic.com/mailman/listinfo/kernel-mentors + + https://selenic.com/mailman/listinfo/kernel-mentors 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의 @@ -213,6 +241,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 코드 저장소는 다음을 통하여 참조할 수 있다. + http://lxr.free-electrons.com/ @@ -222,6 +251,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인 브랜치들은 다음과 같다. + - main 4.x 커널 트리 - 4.x.y - 안정된 커널 트리 - 4.x -git 커널 패치들 @@ -229,15 +259,16 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H - 4.x - 통합 테스트를 위한 next 커널 트리 4.x 커널 트리 ---------------- +~~~~~~~~~~~~~ + +4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의 +pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. -4.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/ -디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 - http://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한 + https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는 것도 무관하다. - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다. @@ -256,12 +287,13 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의 Andrew Morton의 글이 있다. - "커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진 + + *"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 - 배포되는 것은 아니기 때문이다." + 배포되는 것은 아니기 때문이다."* 4.x.y - 안정 커널 트리 ------------------------- +~~~~~~~~~~~~~~~~~~~~~~ 3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을 @@ -280,16 +312,17 @@ Andrew Morton의 글이 있다. 종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게 진행되는지를 설명한다. - 4.x -git 패치들 ------------------- +~~~~~~~~~~~~~~~ + git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다. 서브시스템 커널 트리들과 패치들 -------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도 커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이 @@ -300,33 +333,37 @@ Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인� 대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt 시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS -파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다. +파일에 나열되어 있다. 대부분은 https://git.kernel.org 에서 볼 수 있다. 제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해 리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이 리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와 패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고, 메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다. -대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는 +대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는 http://patchwork.ozlabs.org/ 에 나열되어 있다. 4.x - 통합 테스트를 위한 next 커널 트리 ------------------------------------------ +--------------------------------------- 서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합 테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 매일 받아가는 특수한 테스트 저장소가 존재한다: - http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git + + https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git 이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를 수행하는 것도 좋을 것이다. + 버그 보고 --------- -bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다. -사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다. -kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. - http://test.kernel.org/bugzilla/faq.html + +https://bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 +곳이다. 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 +권장한다. kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. + + https://bugzilla.kernel.org/page.cgi?id=faq.html 메인 커널 소스 디렉토리에 있는 admin-guide/reporting-bugs.rst 파일은 커널 버그라고 생각되는 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널 @@ -344,13 +381,14 @@ kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다. -이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를 -참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 +이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org +를 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다) bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다) 에 등록하면 된다. https://lists.linux-foundation.org/mailman/listinfo/bugme-new + https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors @@ -361,10 +399,14 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� 위의 몇몇 문서들이 설명하였지만 핵심 커널 개발자들의 대다수는 리눅스 커널 메일링 리스트에 참여하고 있다. 리스트에 등록하고 해지하는 방법에 관한 자세한 사항은 다음에서 참조할 수 있다. + http://vger.kernel.org/vger-lists.html#linux-kernel + 웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다. 이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어: + http://dir.gmane.org/gmane.linux.kernel + 여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 관한 것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은 것들이 메일링 리스트의 아카이브에 기록되어 있다. @@ -374,11 +416,13 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� 있는지는 MAINTAINERS 파일을 참조하라. 많은 리스트들은 kernel.org에서 호스트되고 있다. 그 정보들은 다음에서 참조될 수 있다. + http://vger.kernel.org/vger-lists.html 리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라. 대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한 가이드라인을 가지고 있다. + http://www.albion.com/netiquette/ 여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게 @@ -405,11 +449,12 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� 커뮤니티와 협력하는 법 --------------------- +---------------------- 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이 받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다. 그럼 여러분들은 무엇을 기대하고 있어야 하는가? + - 비판 - 의견 - 변경을 위한 요구 @@ -423,6 +468,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� 기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다. 여러분은 무엇을 해서는 안되는가? + - 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것 - 방어적이 되는 것 - 의견을 무시하는 것 @@ -443,10 +489,12 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� 커널 커뮤니티와 기업 조직간의 차이점 ------------------------------------------------------------------ +------------------------------------ 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 문제를 피하기 위한 목록이 있다. + 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : + - "이것은 여러 문제들을 해결합니다." - "이것은 2000 라인의 코드를 줄입니다." - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." @@ -455,6 +503,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� - "이것은 일반적인 머신에서 성능을 향상함으로..." 여러분들이 말할 때 피해야 할 좋지 않은 것들 : + - "우리는 그것을 AIX/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀림없다..." - "나는 20년동안 이것을 해왔다. 그러므로..." - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다." @@ -514,14 +563,15 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� 간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다. 여기에 커널 개발자 Al Viro의 이야기가 있다. - "학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이 + + *"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이 답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고 - 마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다. + 마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.* - 커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를 + *커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은 - 간결하고 멋진 답을 보길 원한다." + 간결하고 멋진 답을 보길 원한다."* 커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들 사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의 @@ -549,16 +599,17 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� 생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될 것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될 것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다. + - 변경이 왜 필요한지 - 패치에 관한 전체 설계 접근(approach) - 구현 상세들 - 테스트 결과들 이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라. - "The Perfect Patch" - http://www.ozlabs.org/~akpm/stuff/tpp.txt + "The Perfect Patch" + http://www.ozlabs.org/~akpm/stuff/tpp.txt 이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이 @@ -570,7 +621,8 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� ---------- -"개발 프로세스"(http://lwn.net/Articles/94386/) 섹션을 + +"개발 프로세스"(https://lwn.net/Articles/94386/) 섹션을 작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게 감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준 Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고 diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 3f66a1980726..449ca1f199f4 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -254,7 +254,8 @@ branches. These different branches are: - the 4.x -next kernel tree for integration tests 4.x kernel tree ------------------ +~~~~~~~~~~~~~~~ + 4.x kernels are maintained by Linus Torvalds, and can be found on https://kernel.org in the pub/linux/kernel/v4.x/ directory. Its development process is as follows: @@ -289,7 +290,8 @@ mailing list about kernel releases: preconceived timeline."* 4.x.y -stable kernel tree -------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~ + Kernels with 3-part versions are -stable kernels. They contain relatively small and critical fixes for security problems or significant regressions discovered in a given 4.x kernel. @@ -312,7 +314,8 @@ documents what kinds of changes are acceptable for the -stable tree, and how the release process works. 4.x -git patches ----------------- +~~~~~~~~~~~~~~~~ + These are daily snapshots of Linus' kernel tree which are managed in a git repository (hence the name.) These patches are usually released daily and represent the current state of Linus' tree. They are more @@ -320,7 +323,8 @@ experimental than -rc kernels since they are generated automatically without even a cursory glance to see if they are sane. Subsystem Specific kernel trees and patches -------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The maintainers of the various kernel subsystems --- and also many kernel subsystem developers --- expose their current state of development in source repositories. That way, others can see what is @@ -344,7 +348,8 @@ accepted, or rejected. Most of these patchwork sites are listed at https://patchwork.kernel.org/. 4.x -next kernel tree for integration tests -------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Before updates from subsystem trees are merged into the mainline 4.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are diff --git a/MAINTAINERS b/MAINTAINERS index 69820b75b2e0..489a913a0bd4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13101,7 +13101,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git S: Maintained F: include/linux/workqueue.h F: kernel/workqueue.c -F: Documentation/workqueue.txt +F: Documentation/core-api/workqueue.rst X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS M: Chen-Yu Tsai <[email protected]> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index fc6e22186405..d4f16cf6281c 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -119,18 +119,30 @@ struct delayed_work { int cpu; }; -/* - * A struct for workqueue attributes. This can be used to change - * attributes of an unbound workqueue. +/** + * struct workqueue_attrs - A struct for workqueue attributes. * - * Unlike other fields, ->no_numa isn't a property of a worker_pool. It - * only modifies how apply_workqueue_attrs() select pools and thus doesn't - * participate in pool hash calculations or equality comparisons. + * This can be used to change attributes of an unbound workqueue. */ struct workqueue_attrs { - int nice; /* nice level */ - cpumask_var_t cpumask; /* allowed CPUs */ - bool no_numa; /* disable NUMA affinity */ + /** + * @nice: nice level + */ + int nice; + + /** + * @cpumask: allowed CPUs + */ + cpumask_var_t cpumask; + + /** + * @no_numa: disable NUMA affinity + * + * Unlike other fields, ``no_numa`` isn't a property of a worker_pool. It + * only modifies how :c:func:`apply_workqueue_attrs` select pools and thus + * doesn't participate in pool hash calculations or equality comparisons. + */ + bool no_numa; }; static inline struct delayed_work *to_delayed_work(struct work_struct *work) @@ -272,7 +284,7 @@ static inline unsigned int work_static(struct work_struct *work) { return 0; } /* * Workqueue flags and constants. For details, please refer to - * Documentation/workqueue.txt. + * Documentation/core-api/workqueue.rst. */ enum { WQ_UNBOUND = 1 << 1, /* not bound to any cpu */ @@ -370,7 +382,8 @@ __alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active, * @args...: args for @fmt * * Allocate a workqueue with the specified parameters. For detailed - * information on WQ_* flags, please refer to Documentation/workqueue.txt. + * information on WQ_* flags, please refer to + * Documentation/core-api/workqueue.rst. * * The __lock_name macro dance is to guarantee that single lock_class_key * doesn't end up with different namesm, which isn't allowed by lockdep. diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 93721f3c91bf..e10378f769f9 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -204,6 +204,7 @@ EOF ## init lots of data + my $errors = 0; my $warnings = 0; my $anon_struct_union = 0; @@ -211,7 +212,7 @@ my $anon_struct_union = 0; # match expressions used to find embedded type information my $type_constant = '\%([-_\w]+)'; my $type_func = '(\w+)\(\)'; -my $type_param = '\@(\w+)'; +my $type_param = '\@(\w+(\.\.\.)?)'; my $type_fp_param = '\@(\w+)\(\)'; # Special RST handling for func ptr params my $type_struct = '\&((struct\s*)*[_\w]+)'; my $type_struct_xml = '\\&((struct\s*)*[_\w]+)'; @@ -2353,7 +2354,10 @@ sub push_parameter($$$) { if ($type eq "" && $param =~ /\.\.\.$/) { - $param = "..."; + if (!$param =~ /\w\.\.\.$/) { + # handles unnamed variable parameters + $param = "..."; + } if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq "") { $parameterdescs{$param} = "variable arguments"; } |