1========================================= 2How to get printk format specifiers right 3========================================= 4 5.. _printk-specifiers: 6 7:Author: Randy Dunlap <rdunlap@infradead.org> 8:Author: Andrew Murray <amurray@mpc-data.co.uk> 9 10 11Integer types 12============= 13 14:: 15 16 If variable is of Type, use printk format specifier: 17 ------------------------------------------------------------ 18 char %d or %x 19 unsigned char %u or %x 20 short int %d or %x 21 unsigned short int %u or %x 22 int %d or %x 23 unsigned int %u or %x 24 long %ld or %lx 25 unsigned long %lu or %lx 26 long long %lld or %llx 27 unsigned long long %llu or %llx 28 size_t %zu or %zx 29 ssize_t %zd or %zx 30 s8 %d or %x 31 u8 %u or %x 32 s16 %d or %x 33 u16 %u or %x 34 s32 %d or %x 35 u32 %u or %x 36 s64 %lld or %llx 37 u64 %llu or %llx 38 39 40If <type> is dependent on a config option for its size (e.g., sector_t, 41blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a 42format specifier of its largest possible type and explicitly cast to it. 43 44Example:: 45 46 printk("test: sector number/total blocks: %llu/%llu\n", 47 (unsigned long long)sector, (unsigned long long)blockcount); 48 49Reminder: sizeof() returns type size_t. 50 51The kernel's printf does not support %n. Floating point formats (%e, %f, 52%g, %a) are also not recognized, for obvious reasons. Use of any 53unsupported specifier or length qualifier results in a WARN and early 54return from vsnprintf(). 55 56Pointer types 57============= 58 59A raw pointer value may be printed with %p which will hash the address 60before printing. The kernel also supports extended specifiers for printing 61pointers of different types. 62 63Some of the extended specifiers print the data on the given address instead 64of printing the address itself. In this case, the following error messages 65might be printed instead of the unreachable information:: 66 67 (null) data on plain NULL address 68 (efault) data on invalid address 69 (einval) invalid data on a valid address 70 71Plain Pointers 72-------------- 73 74:: 75 76 %p abcdef12 or 00000000abcdef12 77 78Pointers printed without a specifier extension (i.e unadorned %p) are 79hashed to prevent leaking information about the kernel memory layout. This 80has the added benefit of providing a unique identifier. On 64-bit machines 81the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it 82gathers enough entropy. If you *really* want the address see %px below. 83 84Error Pointers 85-------------- 86 87:: 88 89 %pe -ENOSPC 90 91For printing error pointers (i.e. a pointer for which IS_ERR() is true) 92as a symbolic error name. Error values for which no symbolic name is 93known are printed in decimal, while a non-ERR_PTR passed as the 94argument to %pe gets treated as ordinary %p. 95 96Symbols/Function Pointers 97------------------------- 98 99:: 100 101 %pS versatile_init+0x0/0x110 102 %ps versatile_init 103 %pSR versatile_init+0x9/0x110 104 (with __builtin_extract_return_addr() translation) 105 %pB prev_fn_of_versatile_init+0x88/0x88 106 107 108The ``S`` and ``s`` specifiers are used for printing a pointer in symbolic 109format. They result in the symbol name with (S) or without (s) 110offsets. If KALLSYMS are disabled then the symbol address is printed instead. 111 112The ``B`` specifier results in the symbol name with offsets and should be 113used when printing stack backtraces. The specifier takes into 114consideration the effect of compiler optimisations which may occur 115when tail-calls are used and marked with the noreturn GCC attribute. 116 117Kernel Pointers 118--------------- 119 120:: 121 122 %pK 01234567 or 0123456789abcdef 123 124For printing kernel pointers which should be hidden from unprivileged 125users. The behaviour of %pK depends on the kptr_restrict sysctl - see 126Documentation/admin-guide/sysctl/kernel.rst for more details. 127 128Unmodified Addresses 129-------------------- 130 131:: 132 133 %px 01234567 or 0123456789abcdef 134 135For printing pointers when you *really* want to print the address. Please 136consider whether or not you are leaking sensitive information about the 137kernel memory layout before printing pointers with %px. %px is functionally 138equivalent to %lx (or %lu). %px is preferred because it is more uniquely 139grep'able. If in the future we need to modify the way the kernel handles 140printing pointers we will be better equipped to find the call sites. 141 142Pointer Differences 143------------------- 144 145:: 146 147 %td 2560 148 %tx a00 149 150For printing the pointer differences, use the %t modifier for ptrdiff_t. 151 152Example:: 153 154 printk("test: difference between pointers: %td\n", ptr2 - ptr1); 155 156Struct Resources 157---------------- 158 159:: 160 161 %pr [mem 0x60000000-0x6fffffff flags 0x2200] or 162 [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] 163 %pR [mem 0x60000000-0x6fffffff pref] or 164 [mem 0x0000000060000000-0x000000006fffffff pref] 165 166For printing struct resources. The ``R`` and ``r`` specifiers result in a 167printed resource with (R) or without (r) a decoded flags member. 168 169Passed by reference. 170 171Physical address types phys_addr_t 172---------------------------------- 173 174:: 175 176 %pa[p] 0x01234567 or 0x0123456789abcdef 177 178For printing a phys_addr_t type (and its derivatives, such as 179resource_size_t) which can vary based on build options, regardless of the 180width of the CPU data path. 181 182Passed by reference. 183 184DMA address types dma_addr_t 185---------------------------- 186 187:: 188 189 %pad 0x01234567 or 0x0123456789abcdef 190 191For printing a dma_addr_t type which can vary based on build options, 192regardless of the width of the CPU data path. 193 194Passed by reference. 195 196Raw buffer as an escaped string 197------------------------------- 198 199:: 200 201 %*pE[achnops] 202 203For printing raw buffer as an escaped string. For the following buffer:: 204 205 1b 62 20 5c 43 07 22 90 0d 5d 206 207A few examples show how the conversion would be done (excluding surrounding 208quotes):: 209 210 %*pE "\eb \C\a"\220\r]" 211 %*pEhp "\x1bb \C\x07"\x90\x0d]" 212 %*pEa "\e\142\040\\\103\a\042\220\r\135" 213 214The conversion rules are applied according to an optional combination 215of flags (see :c:func:`string_escape_mem` kernel documentation for the 216details): 217 218 - a - ESCAPE_ANY 219 - c - ESCAPE_SPECIAL 220 - h - ESCAPE_HEX 221 - n - ESCAPE_NULL 222 - o - ESCAPE_OCTAL 223 - p - ESCAPE_NP 224 - s - ESCAPE_SPACE 225 226By default ESCAPE_ANY_NP is used. 227 228ESCAPE_ANY_NP is the sane choice for many cases, in particularly for 229printing SSIDs. 230 231If field width is omitted then 1 byte only will be escaped. 232 233Raw buffer as a hex string 234-------------------------- 235 236:: 237 238 %*ph 00 01 02 ... 3f 239 %*phC 00:01:02: ... :3f 240 %*phD 00-01-02- ... -3f 241 %*phN 000102 ... 3f 242 243For printing small buffers (up to 64 bytes long) as a hex string with a 244certain separator. For larger buffers consider using 245:c:func:`print_hex_dump`. 246 247MAC/FDDI addresses 248------------------ 249 250:: 251 252 %pM 00:01:02:03:04:05 253 %pMR 05:04:03:02:01:00 254 %pMF 00-01-02-03-04-05 255 %pm 000102030405 256 %pmR 050403020100 257 258For printing 6-byte MAC/FDDI addresses in hex notation. The ``M`` and ``m`` 259specifiers result in a printed address with (M) or without (m) byte 260separators. The default byte separator is the colon (:). 261 262Where FDDI addresses are concerned the ``F`` specifier can be used after 263the ``M`` specifier to use dash (-) separators instead of the default 264separator. 265 266For Bluetooth addresses the ``R`` specifier shall be used after the ``M`` 267specifier to use reversed byte order suitable for visual interpretation 268of Bluetooth addresses which are in the little endian order. 269 270Passed by reference. 271 272IPv4 addresses 273-------------- 274 275:: 276 277 %pI4 1.2.3.4 278 %pi4 001.002.003.004 279 %p[Ii]4[hnbl] 280 281For printing IPv4 dot-separated decimal addresses. The ``I4`` and ``i4`` 282specifiers result in a printed address with (i4) or without (I4) leading 283zeros. 284 285The additional ``h``, ``n``, ``b``, and ``l`` specifiers are used to specify 286host, network, big or little endian order addresses respectively. Where 287no specifier is provided the default network/big endian order is used. 288 289Passed by reference. 290 291IPv6 addresses 292-------------- 293 294:: 295 296 %pI6 0001:0002:0003:0004:0005:0006:0007:0008 297 %pi6 00010002000300040005000600070008 298 %pI6c 1:2:3:4:5:6:7:8 299 300For printing IPv6 network-order 16-bit hex addresses. The ``I6`` and ``i6`` 301specifiers result in a printed address with (I6) or without (i6) 302colon-separators. Leading zeros are always used. 303 304The additional ``c`` specifier can be used with the ``I`` specifier to 305print a compressed IPv6 address as described by 306http://tools.ietf.org/html/rfc5952 307 308Passed by reference. 309 310IPv4/IPv6 addresses (generic, with port, flowinfo, scope) 311--------------------------------------------------------- 312 313:: 314 315 %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008 316 %piS 001.002.003.004 or 00010002000300040005000600070008 317 %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8 318 %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345 319 %p[Ii]S[pfschnbl] 320 321For printing an IP address without the need to distinguish whether it's of 322type AF_INET or AF_INET6. A pointer to a valid struct sockaddr, 323specified through ``IS`` or ``iS``, can be passed to this format specifier. 324 325The additional ``p``, ``f``, and ``s`` specifiers are used to specify port 326(IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ``:`` prefix, 327flowinfo a ``/`` and scope a ``%``, each followed by the actual value. 328 329In case of an IPv6 address the compressed IPv6 address as described by 330http://tools.ietf.org/html/rfc5952 is being used if the additional 331specifier ``c`` is given. The IPv6 address is surrounded by ``[``, ``]`` in 332case of additional specifiers ``p``, ``f`` or ``s`` as suggested by 333https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 334 335In case of IPv4 addresses, the additional ``h``, ``n``, ``b``, and ``l`` 336specifiers can be used as well and are ignored in case of an IPv6 337address. 338 339Passed by reference. 340 341Further examples:: 342 343 %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789 344 %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890 345 %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789 346 347UUID/GUID addresses 348------------------- 349 350:: 351 352 %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f 353 %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F 354 %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f 355 %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F 356 357For printing 16-byte UUID/GUIDs addresses. The additional ``l``, ``L``, 358``b`` and ``B`` specifiers are used to specify a little endian order in 359lower (l) or upper case (L) hex notation - and big endian order in lower (b) 360or upper case (B) hex notation. 361 362Where no additional specifiers are used the default big endian 363order with lower case hex notation will be printed. 364 365Passed by reference. 366 367dentry names 368------------ 369 370:: 371 372 %pd{,2,3,4} 373 %pD{,2,3,4} 374 375For printing dentry name; if we race with :c:func:`d_move`, the name might 376be a mix of old and new ones, but it won't oops. %pd dentry is a safer 377equivalent of %s dentry->d_name.name we used to use, %pd<n> prints ``n`` 378last components. %pD does the same thing for struct file. 379 380Passed by reference. 381 382block_device names 383------------------ 384 385:: 386 387 %pg sda, sda1 or loop0p1 388 389For printing name of block_device pointers. 390 391struct va_format 392---------------- 393 394:: 395 396 %pV 397 398For printing struct va_format structures. These contain a format string 399and va_list as follows:: 400 401 struct va_format { 402 const char *fmt; 403 va_list *va; 404 }; 405 406Implements a "recursive vsnprintf". 407 408Do not use this feature without some mechanism to verify the 409correctness of the format string and va_list arguments. 410 411Passed by reference. 412 413Device tree nodes 414----------------- 415 416:: 417 418 %pOF[fnpPcCF] 419 420 421For printing device tree node structures. Default behaviour is 422equivalent to %pOFf. 423 424 - f - device node full_name 425 - n - device node name 426 - p - device node phandle 427 - P - device node path spec (name + @unit) 428 - F - device node flags 429 - c - major compatible string 430 - C - full compatible string 431 432The separator when using multiple arguments is ':' 433 434Examples:: 435 436 %pOF /foo/bar@0 - Node full name 437 %pOFf /foo/bar@0 - Same as above 438 %pOFfp /foo/bar@0:10 - Node full name + phandle 439 %pOFfcF /foo/bar@0:foo,device:--P- - Node full name + 440 major compatible string + 441 node flags 442 D - dynamic 443 d - detached 444 P - Populated 445 B - Populated bus 446 447Passed by reference. 448 449Fwnode handles 450-------------- 451 452:: 453 454 %pfw[fP] 455 456For printing information on fwnode handles. The default is to print the full 457node name, including the path. The modifiers are functionally equivalent to 458%pOF above. 459 460 - f - full name of the node, including the path 461 - P - the name of the node including an address (if there is one) 462 463Examples (ACPI):: 464 465 %pfwf \_SB.PCI0.CIO2.port@1.endpoint@0 - Full node name 466 %pfwP endpoint@0 - Node name 467 468Examples (OF):: 469 470 %pfwf /ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name 471 %pfwP endpoint - Node name 472 473Time and date (struct rtc_time) 474------------------------------- 475 476:: 477 478 %ptR YYYY-mm-ddTHH:MM:SS 479 %ptRd YYYY-mm-dd 480 %ptRt HH:MM:SS 481 %ptR[dt][r] 482 483For printing date and time as represented by struct rtc_time structure in 484human readable format. 485 486By default year will be incremented by 1900 and month by 1. Use %ptRr (raw) 487to suppress this behaviour. 488 489Passed by reference. 490 491struct clk 492---------- 493 494:: 495 496 %pC pll1 497 %pCn pll1 498 499For printing struct clk structures. %pC and %pCn print the name of the clock 500(Common Clock Framework) or a unique 32-bit ID (legacy clock framework). 501 502Passed by reference. 503 504bitmap and its derivatives such as cpumask and nodemask 505------------------------------------------------------- 506 507:: 508 509 %*pb 0779 510 %*pbl 0,3-6,8-10 511 512For printing bitmap and its derivatives such as cpumask and nodemask, 513%*pb outputs the bitmap with field width as the number of bits and %*pbl 514output the bitmap as range list with field width as the number of bits. 515 516Passed by reference. 517 518Flags bitfields such as page flags, gfp_flags 519--------------------------------------------- 520 521:: 522 523 %pGp referenced|uptodate|lru|active|private 524 %pGg GFP_USER|GFP_DMA32|GFP_NOWARN 525 %pGv read|exec|mayread|maywrite|mayexec|denywrite 526 527For printing flags bitfields as a collection of symbolic constants that 528would construct the value. The type of flags is given by the third 529character. Currently supported are [p]age flags, [v]ma_flags (both 530expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag 531names and print order depends on the particular type. 532 533Note that this format should not be used directly in the 534:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags() 535functions from <trace/events/mmflags.h>. 536 537Passed by reference. 538 539Network device features 540----------------------- 541 542:: 543 544 %pNF 0x000000000000c000 545 546For printing netdev_features_t. 547 548Passed by reference. 549 550Thanks 551====== 552 553If you add other %p extensions, please extend <lib/test_printf.c> with 554one or more test cases, if at all feasible. 555 556Thank you for your cooperation and attention. 557