1 If variable is of Type, use printk format specifier:
2 ---------------------------------------------------------
6 unsigned long %lu or %lx
8 unsigned long long %llu or %llx
16 If <type> is dependent on a config option for its size (e.g., sector_t,
17 blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
18 format specifier of its largest possible type and explicitly cast to it.
21 printk("test: sector number/total blocks: %llu/%llu\n",
22 (unsigned long long)sector, (unsigned long long)blockcount);
24 Reminder: sizeof() result is of type size_t.
26 The kernel's printf does not support %n. For obvious reasons, floating
27 point formats (%e, %f, %g, %a) are also not recognized. Use of any
28 unsupported specifier or length qualifier results in a WARN and early
29 return from vsnprintf.
31 Raw pointer value SHOULD be printed with %p. The kernel supports
32 the following extended format specifiers for pointer types:
36 Pointers printed without a specifier extension (i.e unadorned %p) are
37 hashed to give a unique identifier without leaking kernel addresses to user
38 space. On 64 bit machines the first 32 bits are zeroed. If you _really_
39 want the address see %px below.
41 %p abcdef12 or 00000000abcdef12
43 Symbols/Function Pointers:
45 %pF versatile_init+0x0/0x110
47 %pS versatile_init+0x0/0x110
48 %pSR versatile_init+0x9/0x110
49 (with __builtin_extract_return_addr() translation)
51 %pB prev_fn_of_versatile_init+0x88/0x88
53 For printing symbols and function pointers. The 'S' and 's' specifiers
54 result in the symbol name with ('S') or without ('s') offsets. Where
55 this is used on a kernel without KALLSYMS - the symbol address is
58 The 'B' specifier results in the symbol name with offsets and should be
59 used when printing stack backtraces. The specifier takes into
60 consideration the effect of compiler optimisations which may occur
61 when tail-call's are used and marked with the noreturn GCC attribute.
63 On ia64, ppc64 and parisc64 architectures function pointers are
64 actually function descriptors which must first be resolved. The 'F' and
65 'f' specifiers perform this resolution and then provide the same
66 functionality as the 'S' and 's' specifiers.
70 %pK 01234567 or 0123456789abcdef
72 For printing kernel pointers which should be hidden from unprivileged
73 users. The behaviour of %pK depends on the kptr_restrict sysctl - see
74 Documentation/sysctl/kernel.txt for more details.
78 %px 01234567 or 0123456789abcdef
80 For printing pointers when you _really_ want to print the address. Please
81 consider whether or not you are leaking sensitive information about the
82 Kernel layout in memory before printing pointers with %px. %px is
83 functionally equivalent to %lx. %px is preferred to %lx because it is more
84 uniquely grep'able. If, in the future, we need to modify the way the Kernel
85 handles printing pointers it will be nice to be able to find the call
90 %pr [mem 0x60000000-0x6fffffff flags 0x2200] or
91 [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
92 %pR [mem 0x60000000-0x6fffffff pref] or
93 [mem 0x0000000060000000-0x000000006fffffff pref]
95 For printing struct resources. The 'R' and 'r' specifiers result in a
96 printed resource with ('R') or without ('r') a decoded flags member.
99 Physical addresses types phys_addr_t:
101 %pa[p] 0x01234567 or 0x0123456789abcdef
103 For printing a phys_addr_t type (and its derivatives, such as
104 resource_size_t) which can vary based on build options, regardless of
105 the width of the CPU data path. Passed by reference.
107 DMA addresses types dma_addr_t:
109 %pad 0x01234567 or 0x0123456789abcdef
111 For printing a dma_addr_t type which can vary based on build options,
112 regardless of the width of the CPU data path. Passed by reference.
114 Raw buffer as an escaped string:
118 For printing raw buffer as an escaped string. For the following buffer
120 1b 62 20 5c 43 07 22 90 0d 5d
122 few examples show how the conversion would be done (the result string
123 without surrounding quotes):
125 %*pE "\eb \C\a"\220\r]"
126 %*pEhp "\x1bb \C\x07"\x90\x0d]"
127 %*pEa "\e\142\040\\\103\a\042\220\r\135"
129 The conversion rules are applied according to an optional combination
130 of flags (see string_escape_mem() kernel documentation for the
139 By default ESCAPE_ANY_NP is used.
141 ESCAPE_ANY_NP is the sane choice for many cases, in particularly for
144 If field width is omitted the 1 byte only will be escaped.
146 Raw buffer as a hex string:
149 %*phC 00:01:02: ... :3f
150 %*phD 00-01-02- ... -3f
153 For printing a small buffers (up to 64 bytes long) as a hex string with
154 certain separator. For the larger buffers consider to use
159 %pM 00:01:02:03:04:05
160 %pMR 05:04:03:02:01:00
161 %pMF 00-01-02-03-04-05
165 For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
166 specifiers result in a printed address with ('M') or without ('m') byte
167 separators. The default byte separator is the colon (':').
169 Where FDDI addresses are concerned the 'F' specifier can be used after
170 the 'M' specifier to use dash ('-') separators instead of the default
173 For Bluetooth addresses the 'R' specifier shall be used after the 'M'
174 specifier to use reversed byte order suitable for visual interpretation
175 of Bluetooth addresses which are in the little endian order.
185 For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
186 specifiers result in a printed address with ('i4') or without ('I4')
189 The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
190 host, network, big or little endian order addresses respectively. Where
191 no specifier is provided the default network/big endian order is used.
197 %pI6 0001:0002:0003:0004:0005:0006:0007:0008
198 %pi6 00010002000300040005000600070008
199 %pI6c 1:2:3:4:5:6:7:8
201 For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6'
202 specifiers result in a printed address with ('I6') or without ('i6')
203 colon-separators. Leading zeros are always used.
205 The additional 'c' specifier can be used with the 'I' specifier to
206 print a compressed IPv6 address as described by
207 http://tools.ietf.org/html/rfc5952
211 IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
213 %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008
214 %piS 001.002.003.004 or 00010002000300040005000600070008
215 %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8
216 %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
219 For printing an IP address without the need to distinguish whether it's
220 of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr',
221 specified through 'IS' or 'iS', can be passed to this format specifier.
223 The additional 'p', 'f', and 's' specifiers are used to specify port
224 (IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix,
225 flowinfo a '/' and scope a '%', each followed by the actual value.
227 In case of an IPv6 address the compressed IPv6 address as described by
228 http://tools.ietf.org/html/rfc5952 is being used if the additional
229 specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in
230 case of additional specifiers 'p', 'f' or 's' as suggested by
231 https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
233 In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l'
234 specifiers can be used as well and are ignored in case of an IPv6
241 %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789
242 %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890
243 %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
247 %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
248 %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
249 %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
250 %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
252 For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
253 'b' and 'B' specifiers are used to specify a little endian order in
254 lower ('l') or upper case ('L') hex characters - and big endian order
255 in lower ('b') or upper case ('B') hex characters.
257 Where no additional specifiers are used the default big endian
258 order with lower case hex characters will be printed.
267 For printing dentry name; if we race with d_move(), the name might be
268 a mix of old and new ones, but it won't oops. %pd dentry is a safer
269 equivalent of %s dentry->d_name.name we used to use, %pd<n> prints
270 n last components. %pD does the same thing for struct file.
276 %pg sda, sda1 or loop0p1
278 For printing name of block_device pointers.
284 For printing struct va_format structures. These contain a format string
285 and va_list as follows:
292 Implements a "recursive vsnprintf".
294 Do not use this feature without some mechanism to verify the
295 correctness of the format string and va_list arguments.
304 For printing struct clk structures. '%pC' and '%pCn' print the name
305 (Common Clock Framework) or address (legacy clock framework) of the
310 bitmap and its derivatives such as cpumask and nodemask:
315 For printing bitmap and its derivatives such as cpumask and nodemask,
316 %*pb output the bitmap with field width as the number of bits and %*pbl
317 output the bitmap as range list with field width as the number of bits.
321 Flags bitfields such as page flags, gfp_flags:
323 %pGp referenced|uptodate|lru|active|private
324 %pGg GFP_USER|GFP_DMA32|GFP_NOWARN
325 %pGv read|exec|mayread|maywrite|mayexec|denywrite
327 For printing flags bitfields as a collection of symbolic constants that
328 would construct the value. The type of flags is given by the third
329 character. Currently supported are [p]age flags, [v]ma_flags (both
330 expect unsigned long *) and [g]fp_flags (expects gfp_t *). The flag
331 names and print order depends on the particular type.
333 Note that this format should not be used directly in TP_printk() part
334 of a tracepoint. Instead, use the show_*_flags() functions from
335 <trace/events/mmflags.h>.
339 Network device features:
341 %pNF 0x000000000000c000
343 For printing netdev_features_t.
347 If you add other %p extensions, please extend lib/test_printf.c with
348 one or more test cases, if at all feasible.
351 Thank you for your cooperation and attention.
354 By Randy Dunlap <rdunlap@infradead.org> and
355 Andrew Murray <amurray@mpc-data.co.uk>