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