Eric Lee / smarc-ti-linux-kernel

Download as
Browse Code ยป

Commit 4ff4d8d342fe25c4d1106fb0ffdd310a43d0ace0

Authored by Nolan Leake
Committed by Linus Torvalds
1 parent d634f194d4
Exists in master and in 20 other branches dlt-processor-sdk-linux-03.00.00.04, newt-ti-linux-3.12.y, processor-sdk-linux-01.00.00, processor-sdk-linux-02.00.01, smarc-ti-linux-3.12.10, smarc-ti-linux-3.12.y, smarc-ti-linux-3.14.y, smarc-ti-linux-3.15.y, smarc-ti-lsk-linux-4.1.y, smarct3x-processor-sdk-04.01.00.06, smarct3x-processor-sdk-linux-02.00.01, smarct3x-processor-sdk-linux-03.00.00.04, smarct4x-800-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-04.01.00.06, smarct4x-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-linux-03.00.00.04, ti-linux-3.12.y, ti-linux-3.14.y, ti-linux-3.15.y, ti-lsk-linux-4.1.y

um: add ucast ethernet transport 

The ucast transport is similar to the mcast transport (and, in fact,
shares most of its code), only it uses UDP unicast to move packets.

Obviously this is only useful for point-to-point connections between
virtual ethernet devices.

Signed-off-by: Nolan Leake <nolan@cumulusnetworks.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Showing 8 changed files with 413 additions and 311 deletions Inline Diff

Documentation/virtual/uml/UserModeLinux-HOWTO.txt
Diff comments   View file @ 4ff4d8d
1 User Mode Linux HOWTO 1 User Mode Linux HOWTO
2 User Mode Linux Core Team 2 User Mode Linux Core Team
3 Mon Nov 18 14:16:16 EST 2002 3 Mon Nov 18 14:16:16 EST 2002
4 4
5 This document describes the use and abuse of Jeff Dike's User Mode 5 This document describes the use and abuse of Jeff Dike's User Mode
6 Linux: a port of the Linux kernel as a normal Intel Linux process. 6 Linux: a port of the Linux kernel as a normal Intel Linux process.
7 ______________________________________________________________________ 7 ______________________________________________________________________
8 8
9 Table of Contents 9 Table of Contents
10 10
11 1. Introduction 11 1. Introduction
12 12
13 1.1 How is User Mode Linux Different? 13 1.1 How is User Mode Linux Different?
14 1.2 Why Would I Want User Mode Linux? 14 1.2 Why Would I Want User Mode Linux?
15 15
16 2. Compiling the kernel and modules 16 2. Compiling the kernel and modules
17 17
18 2.1 Compiling the kernel 18 2.1 Compiling the kernel
19 2.2 Compiling and installing kernel modules 19 2.2 Compiling and installing kernel modules
20 2.3 Compiling and installing uml_utilities 20 2.3 Compiling and installing uml_utilities
21 21
22 3. Running UML and logging in 22 3. Running UML and logging in
23 23
24 3.1 Running UML 24 3.1 Running UML
25 3.2 Logging in 25 3.2 Logging in
26 3.3 Examples 26 3.3 Examples
27 27
28 4. UML on 2G/2G hosts 28 4. UML on 2G/2G hosts
29 29
30 4.1 Introduction 30 4.1 Introduction
31 4.2 The problem 31 4.2 The problem
32 4.3 The solution 32 4.3 The solution
33 33
34 5. Setting up serial lines and consoles 34 5. Setting up serial lines and consoles
35 35
36 5.1 Specifying the device 36 5.1 Specifying the device
37 5.2 Specifying the channel 37 5.2 Specifying the channel
38 5.3 Examples 38 5.3 Examples
39 39
40 6. Setting up the network 40 6. Setting up the network
41 41
42 6.1 General setup 42 6.1 General setup
43 6.2 Userspace daemons 43 6.2 Userspace daemons
44 6.3 Specifying ethernet addresses 44 6.3 Specifying ethernet addresses
45 6.4 UML interface setup 45 6.4 UML interface setup
46 6.5 Multicast 46 6.5 Multicast
47 6.6 TUN/TAP with the uml_net helper 47 6.6 TUN/TAP with the uml_net helper
48 6.7 TUN/TAP with a preconfigured tap device 48 6.7 TUN/TAP with a preconfigured tap device
49 6.8 Ethertap 49 6.8 Ethertap
50 6.9 The switch daemon 50 6.9 The switch daemon
51 6.10 Slip 51 6.10 Slip
52 6.11 Slirp 52 6.11 Slirp
53 6.12 pcap 53 6.12 pcap
54 6.13 Setting up the host yourself 54 6.13 Setting up the host yourself
55 55
56 7. Sharing Filesystems between Virtual Machines 56 7. Sharing Filesystems between Virtual Machines
57 57
58 7.1 A warning 58 7.1 A warning
59 7.2 Using layered block devices 59 7.2 Using layered block devices
60 7.3 Note! 60 7.3 Note!
61 7.4 Another warning 61 7.4 Another warning
62 7.5 uml_moo : Merging a COW file with its backing file 62 7.5 uml_moo : Merging a COW file with its backing file
63 63
64 8. Creating filesystems 64 8. Creating filesystems
65 65
66 8.1 Create the filesystem file 66 8.1 Create the filesystem file
67 8.2 Assign the file to a UML device 67 8.2 Assign the file to a UML device
68 8.3 Creating and mounting the filesystem 68 8.3 Creating and mounting the filesystem
69 69
70 9. Host file access 70 9. Host file access
71 71
72 9.1 Using hostfs 72 9.1 Using hostfs
73 9.2 hostfs as the root filesystem 73 9.2 hostfs as the root filesystem
74 9.3 Building hostfs 74 9.3 Building hostfs
75 75
76 10. The Management Console 76 10. The Management Console
77 10.1 version 77 10.1 version
78 10.2 halt and reboot 78 10.2 halt and reboot
79 10.3 config 79 10.3 config
80 10.4 remove 80 10.4 remove
81 10.5 sysrq 81 10.5 sysrq
82 10.6 help 82 10.6 help
83 10.7 cad 83 10.7 cad
84 10.8 stop 84 10.8 stop
85 10.9 go 85 10.9 go
86 86
87 11. Kernel debugging 87 11. Kernel debugging
88 88
89 11.1 Starting the kernel under gdb 89 11.1 Starting the kernel under gdb
90 11.2 Examining sleeping processes 90 11.2 Examining sleeping processes
91 11.3 Running ddd on UML 91 11.3 Running ddd on UML
92 11.4 Debugging modules 92 11.4 Debugging modules
93 11.5 Attaching gdb to the kernel 93 11.5 Attaching gdb to the kernel
94 11.6 Using alternate debuggers 94 11.6 Using alternate debuggers
95 95
96 12. Kernel debugging examples 96 12. Kernel debugging examples
97 97
98 12.1 The case of the hung fsck 98 12.1 The case of the hung fsck
99 12.2 Episode 2: The case of the hung fsck 99 12.2 Episode 2: The case of the hung fsck
100 100
101 13. What to do when UML doesn't work 101 13. What to do when UML doesn't work
102 102
103 13.1 Strange compilation errors when you build from source 103 13.1 Strange compilation errors when you build from source
104 13.2 (obsolete) 104 13.2 (obsolete)
105 13.3 A variety of panics and hangs with /tmp on a reiserfs filesystem 105 13.3 A variety of panics and hangs with /tmp on a reiserfs filesystem
106 13.4 The compile fails with errors about conflicting types for 'open', 'dup', and 'waitpid' 106 13.4 The compile fails with errors about conflicting types for 'open', 'dup', and 'waitpid'
107 13.5 UML doesn't work when /tmp is an NFS filesystem 107 13.5 UML doesn't work when /tmp is an NFS filesystem
108 13.6 UML hangs on boot when compiled with gprof support 108 13.6 UML hangs on boot when compiled with gprof support
109 13.7 syslogd dies with a SIGTERM on startup 109 13.7 syslogd dies with a SIGTERM on startup
110 13.8 TUN/TAP networking doesn't work on a 2.4 host 110 13.8 TUN/TAP networking doesn't work on a 2.4 host
111 13.9 You can network to the host but not to other machines on the net 111 13.9 You can network to the host but not to other machines on the net
112 13.10 I have no root and I want to scream 112 13.10 I have no root and I want to scream
113 13.11 UML build conflict between ptrace.h and ucontext.h 113 13.11 UML build conflict between ptrace.h and ucontext.h
114 13.12 The UML BogoMips is exactly half the host's BogoMips 114 13.12 The UML BogoMips is exactly half the host's BogoMips
115 13.13 When you run UML, it immediately segfaults 115 13.13 When you run UML, it immediately segfaults
116 13.14 xterms appear, then immediately disappear 116 13.14 xterms appear, then immediately disappear
117 13.15 Any other panic, hang, or strange behavior 117 13.15 Any other panic, hang, or strange behavior
118 118
119 14. Diagnosing Problems 119 14. Diagnosing Problems
120 120
121 14.1 Case 1 : Normal kernel panics 121 14.1 Case 1 : Normal kernel panics
122 14.2 Case 2 : Tracing thread panics 122 14.2 Case 2 : Tracing thread panics
123 14.3 Case 3 : Tracing thread panics caused by other threads 123 14.3 Case 3 : Tracing thread panics caused by other threads
124 14.4 Case 4 : Hangs 124 14.4 Case 4 : Hangs
125 125
126 15. Thanks 126 15. Thanks
127 127
128 15.1 Code and Documentation 128 15.1 Code and Documentation
129 15.2 Flushing out bugs 129 15.2 Flushing out bugs
130 15.3 Buglets and clean-ups 130 15.3 Buglets and clean-ups
131 15.4 Case Studies 131 15.4 Case Studies
132 15.5 Other contributions 132 15.5 Other contributions
133 133
134 134
135 ______________________________________________________________________ 135 ______________________________________________________________________
136 136
137 11.. IInnttrroodduuccttiioonn 137 11.. IInnttrroodduuccttiioonn
138 138
139 Welcome to User Mode Linux. It's going to be fun. 139 Welcome to User Mode Linux. It's going to be fun.
140 140
141 141
142 142
143 11..11.. HHooww iiss UUsseerr MMooddee LLiinnuuxx DDiiffffeerreenntt?? 143 11..11.. HHooww iiss UUsseerr MMooddee LLiinnuuxx DDiiffffeerreenntt??
144 144
145 Normally, the Linux Kernel talks straight to your hardware (video 145 Normally, the Linux Kernel talks straight to your hardware (video
146 card, keyboard, hard drives, etc), and any programs which run ask the 146 card, keyboard, hard drives, etc), and any programs which run ask the
147 kernel to operate the hardware, like so: 147 kernel to operate the hardware, like so:
148 148
149 149
150 150
151 +-----------+-----------+----+ 151 +-----------+-----------+----+
152 | Process 1 | Process 2 | ...| 152 | Process 1 | Process 2 | ...|
153 +-----------+-----------+----+ 153 +-----------+-----------+----+
154 | Linux Kernel | 154 | Linux Kernel |
155 +----------------------------+ 155 +----------------------------+
156 | Hardware | 156 | Hardware |
157 +----------------------------+ 157 +----------------------------+
158 158
159 159
160 160
161 161
162 The User Mode Linux Kernel is different; instead of talking to the 162 The User Mode Linux Kernel is different; instead of talking to the
163 hardware, it talks to a `real' Linux kernel (called the `host kernel' 163 hardware, it talks to a `real' Linux kernel (called the `host kernel'
164 from now on), like any other program. Programs can then run inside 164 from now on), like any other program. Programs can then run inside
165 User-Mode Linux as if they were running under a normal kernel, like 165 User-Mode Linux as if they were running under a normal kernel, like
166 so: 166 so:
167 167
168 168
169 169
170 +----------------+ 170 +----------------+
171 | Process 2 | ...| 171 | Process 2 | ...|
172 +-----------+----------------+ 172 +-----------+----------------+
173 | Process 1 | User-Mode Linux| 173 | Process 1 | User-Mode Linux|
174 +----------------------------+ 174 +----------------------------+
175 | Linux Kernel | 175 | Linux Kernel |
176 +----------------------------+ 176 +----------------------------+
177 | Hardware | 177 | Hardware |
178 +----------------------------+ 178 +----------------------------+
179 179
180 180
181 181
182 182
183 183
184 11..22.. WWhhyy WWoouulldd II WWaanntt UUsseerr MMooddee LLiinnuuxx?? 184 11..22.. WWhhyy WWoouulldd II WWaanntt UUsseerr MMooddee LLiinnuuxx??
185 185
186 186
187 1. If User Mode Linux crashes, your host kernel is still fine. 187 1. If User Mode Linux crashes, your host kernel is still fine.
188 188
189 2. You can run a usermode kernel as a non-root user. 189 2. You can run a usermode kernel as a non-root user.
190 190
191 3. You can debug the User Mode Linux like any normal process. 191 3. You can debug the User Mode Linux like any normal process.
192 192
193 4. You can run gprof (profiling) and gcov (coverage testing). 193 4. You can run gprof (profiling) and gcov (coverage testing).
194 194
195 5. You can play with your kernel without breaking things. 195 5. You can play with your kernel without breaking things.
196 196
197 6. You can use it as a sandbox for testing new apps. 197 6. You can use it as a sandbox for testing new apps.
198 198
199 7. You can try new development kernels safely. 199 7. You can try new development kernels safely.
200 200
201 8. You can run different distributions simultaneously. 201 8. You can run different distributions simultaneously.
202 202
203 9. It's extremely fun. 203 9. It's extremely fun.
204 204
205 205
206 206
207 207
208 208
209 22.. CCoommppiilliinngg tthhee kkeerrnneell aanndd mmoodduulleess 209 22.. CCoommppiilliinngg tthhee kkeerrnneell aanndd mmoodduulleess
210 210
211 211
212 212
213 213
214 22..11.. CCoommppiilliinngg tthhee kkeerrnneell 214 22..11.. CCoommppiilliinngg tthhee kkeerrnneell
215 215
216 216
217 Compiling the user mode kernel is just like compiling any other 217 Compiling the user mode kernel is just like compiling any other
218 kernel. Let's go through the steps, using 2.4.0-prerelease (current 218 kernel. Let's go through the steps, using 2.4.0-prerelease (current
219 as of this writing) as an example: 219 as of this writing) as an example:
220 220
221 221
222 1. Download the latest UML patch from 222 1. Download the latest UML patch from
223 223
224 the download page <http://user-mode-linux.sourceforge.net/ 224 the download page <http://user-mode-linux.sourceforge.net/
225 225
226 In this example, the file is uml-patch-2.4.0-prerelease.bz2. 226 In this example, the file is uml-patch-2.4.0-prerelease.bz2.
227 227
228 228
229 2. Download the matching kernel from your favourite kernel mirror, 229 2. Download the matching kernel from your favourite kernel mirror,
230 such as: 230 such as:
231 231
232 ftp://ftp.ca.kernel.org/pub/kernel/v2.4/linux-2.4.0-prerelease.tar.bz2 232 ftp://ftp.ca.kernel.org/pub/kernel/v2.4/linux-2.4.0-prerelease.tar.bz2
233 <ftp://ftp.ca.kernel.org/pub/kernel/v2.4/linux-2.4.0-prerelease.tar.bz2> 233 <ftp://ftp.ca.kernel.org/pub/kernel/v2.4/linux-2.4.0-prerelease.tar.bz2>
234 . 234 .
235 235
236 236
237 3. Make a directory and unpack the kernel into it. 237 3. Make a directory and unpack the kernel into it.
238 238
239 239
240 240
241 host% 241 host%
242 mkdir ~/uml 242 mkdir ~/uml
243 243
244 244
245 245
246 246
247 247
248 248
249 host% 249 host%
250 cd ~/uml 250 cd ~/uml
251 251
252 252
253 253
254 254
255 255
256 256
257 host% 257 host%
258 tar -xzvf linux-2.4.0-prerelease.tar.bz2 258 tar -xzvf linux-2.4.0-prerelease.tar.bz2
259 259
260 260
261 261
262 262
263 263
264 264
265 4. Apply the patch using 265 4. Apply the patch using
266 266
267 267
268 268
269 host% 269 host%
270 cd ~/uml/linux 270 cd ~/uml/linux
271 271
272 272
273 273
274 host% 274 host%
275 bzcat uml-patch-2.4.0-prerelease.bz2 | patch -p1 275 bzcat uml-patch-2.4.0-prerelease.bz2 | patch -p1
276 276
277 277
278 278
279 279
280 280
281 281
282 5. Run your favorite config; `make xconfig ARCH=um' is the most 282 5. Run your favorite config; `make xconfig ARCH=um' is the most
283 convenient. `make config ARCH=um' and 'make menuconfig ARCH=um' 283 convenient. `make config ARCH=um' and 'make menuconfig ARCH=um'
284 will work as well. The defaults will give you a useful kernel. If 284 will work as well. The defaults will give you a useful kernel. If
285 you want to change something, go ahead, it probably won't hurt 285 you want to change something, go ahead, it probably won't hurt
286 anything. 286 anything.
287 287
288 288
289 Note: If the host is configured with a 2G/2G address space split 289 Note: If the host is configured with a 2G/2G address space split
290 rather than the usual 3G/1G split, then the packaged UML binaries 290 rather than the usual 3G/1G split, then the packaged UML binaries
291 will not run. They will immediately segfault. See ``UML on 2G/2G 291 will not run. They will immediately segfault. See ``UML on 2G/2G
292 hosts'' for the scoop on running UML on your system. 292 hosts'' for the scoop on running UML on your system.
293 293
294 294
295 295
296 6. Finish with `make linux ARCH=um': the result is a file called 296 6. Finish with `make linux ARCH=um': the result is a file called
297 `linux' in the top directory of your source tree. 297 `linux' in the top directory of your source tree.
298 298
299 Make sure that you don't build this kernel in /usr/src/linux. On some 299 Make sure that you don't build this kernel in /usr/src/linux. On some
300 distributions, /usr/include/asm is a link into this pool. The user- 300 distributions, /usr/include/asm is a link into this pool. The user-
301 mode build changes the other end of that link, and things that include 301 mode build changes the other end of that link, and things that include
302 <asm/anything.h> stop compiling. 302 <asm/anything.h> stop compiling.
303 303
304 The sources are also available from cvs at the project's cvs page, 304 The sources are also available from cvs at the project's cvs page,
305 which has directions on getting the sources. You can also browse the 305 which has directions on getting the sources. You can also browse the
306 CVS pool from there. 306 CVS pool from there.
307 307
308 If you get the CVS sources, you will have to check them out into an 308 If you get the CVS sources, you will have to check them out into an
309 empty directory. You will then have to copy each file into the 309 empty directory. You will then have to copy each file into the
310 corresponding directory in the appropriate kernel pool. 310 corresponding directory in the appropriate kernel pool.
311 311
312 If you don't have the latest kernel pool, you can get the 312 If you don't have the latest kernel pool, you can get the
313 corresponding user-mode sources with 313 corresponding user-mode sources with
314 314
315 315
316 host% cvs co -r v_2_3_x linux 316 host% cvs co -r v_2_3_x linux
317 317
318 318
319 319
320 320
321 where 'x' is the version in your pool. Note that you will not get the 321 where 'x' is the version in your pool. Note that you will not get the
322 bug fixes and enhancements that have gone into subsequent releases. 322 bug fixes and enhancements that have gone into subsequent releases.
323 323
324 324
325 22..22.. CCoommppiilliinngg aanndd iinnssttaalllliinngg kkeerrnneell mmoodduulleess 325 22..22.. CCoommppiilliinngg aanndd iinnssttaalllliinngg kkeerrnneell mmoodduulleess
326 326
327 UML modules are built in the same way as the native kernel (with the 327 UML modules are built in the same way as the native kernel (with the
328 exception of the 'ARCH=um' that you always need for UML): 328 exception of the 'ARCH=um' that you always need for UML):
329 329
330 330
331 host% make modules ARCH=um 331 host% make modules ARCH=um
332 332
333 333
334 334
335 335
336 Any modules that you want to load into this kernel need to be built in 336 Any modules that you want to load into this kernel need to be built in
337 the user-mode pool. Modules from the native kernel won't work. 337 the user-mode pool. Modules from the native kernel won't work.
338 338
339 You can install them by using ftp or something to copy them into the 339 You can install them by using ftp or something to copy them into the
340 virtual machine and dropping them into /lib/modules/`uname -r`. 340 virtual machine and dropping them into /lib/modules/`uname -r`.
341 341
342 You can also get the kernel build process to install them as follows: 342 You can also get the kernel build process to install them as follows:
343 343
344 1. with the kernel not booted, mount the root filesystem in the top 344 1. with the kernel not booted, mount the root filesystem in the top
345 level of the kernel pool: 345 level of the kernel pool:
346 346
347 347
348 host% mount root_fs mnt -o loop 348 host% mount root_fs mnt -o loop
349 349
350 350
351 351
352 352
353 353
354 354
355 2. run 355 2. run
356 356
357 357
358 host% 358 host%
359 make modules_install INSTALL_MOD_PATH=`pwd`/mnt ARCH=um 359 make modules_install INSTALL_MOD_PATH=`pwd`/mnt ARCH=um
360 360
361 361
362 362
363 363
364 364
365 365
366 3. unmount the filesystem 366 3. unmount the filesystem
367 367
368 368
369 host% umount mnt 369 host% umount mnt
370 370
371 371
372 372
373 373
374 374
375 375
376 4. boot the kernel on it 376 4. boot the kernel on it
377 377
378 378
379 When the system is booted, you can use insmod as usual to get the 379 When the system is booted, you can use insmod as usual to get the
380 modules into the kernel. A number of things have been loaded into UML 380 modules into the kernel. A number of things have been loaded into UML
381 as modules, especially filesystems and network protocols and filters, 381 as modules, especially filesystems and network protocols and filters,
382 so most symbols which need to be exported probably already are. 382 so most symbols which need to be exported probably already are.
383 However, if you do find symbols that need exporting, let us 383 However, if you do find symbols that need exporting, let us
384 <http://user-mode-linux.sourceforge.net/> know, and 384 <http://user-mode-linux.sourceforge.net/> know, and
385 they'll be "taken care of". 385 they'll be "taken care of".
386 386
387 387
388 388
389 22..33.. CCoommppiilliinngg aanndd iinnssttaalllliinngg uummll__uuttiilliittiieess 389 22..33.. CCoommppiilliinngg aanndd iinnssttaalllliinngg uummll__uuttiilliittiieess
390 390
391 Many features of the UML kernel require a user-space helper program, 391 Many features of the UML kernel require a user-space helper program,
392 so a uml_utilities package is distributed separately from the kernel 392 so a uml_utilities package is distributed separately from the kernel
393 patch which provides these helpers. Included within this is: 393 patch which provides these helpers. Included within this is:
394 394
395 +o port-helper - Used by consoles which connect to xterms or ports 395 +o port-helper - Used by consoles which connect to xterms or ports
396 396
397 +o tunctl - Configuration tool to create and delete tap devices 397 +o tunctl - Configuration tool to create and delete tap devices
398 398
399 +o uml_net - Setuid binary for automatic tap device configuration 399 +o uml_net - Setuid binary for automatic tap device configuration
400 400
401 +o uml_switch - User-space virtual switch required for daemon 401 +o uml_switch - User-space virtual switch required for daemon
402 transport 402 transport
403 403
404 The uml_utilities tree is compiled with: 404 The uml_utilities tree is compiled with:
405 405
406 406
407 host# 407 host#
408 make && make install 408 make && make install
409 409
410 410
411 411
412 412
413 Note that UML kernel patches may require a specific version of the 413 Note that UML kernel patches may require a specific version of the
414 uml_utilities distribution. If you don't keep up with the mailing 414 uml_utilities distribution. If you don't keep up with the mailing
415 lists, ensure that you have the latest release of uml_utilities if you 415 lists, ensure that you have the latest release of uml_utilities if you
416 are experiencing problems with your UML kernel, particularly when 416 are experiencing problems with your UML kernel, particularly when
417 dealing with consoles or command-line switches to the helper programs 417 dealing with consoles or command-line switches to the helper programs
418 418
419 419
420 420
421 421
422 422
423 423
424 424
425 425
426 33.. RRuunnnniinngg UUMMLL aanndd llooggggiinngg iinn 426 33.. RRuunnnniinngg UUMMLL aanndd llooggggiinngg iinn
427 427
428 428
429 429
430 33..11.. RRuunnnniinngg UUMMLL 430 33..11.. RRuunnnniinngg UUMMLL
431 431
432 It runs on 2.2.15 or later, and all 2.4 kernels. 432 It runs on 2.2.15 or later, and all 2.4 kernels.
433 433
434 434
435 Booting UML is straightforward. Simply run 'linux': it will try to 435 Booting UML is straightforward. Simply run 'linux': it will try to
436 mount the file `root_fs' in the current directory. You do not need to 436 mount the file `root_fs' in the current directory. You do not need to
437 run it as root. If your root filesystem is not named `root_fs', then 437 run it as root. If your root filesystem is not named `root_fs', then
438 you need to put a `ubd0=root_fs_whatever' switch on the linux command 438 you need to put a `ubd0=root_fs_whatever' switch on the linux command
439 line. 439 line.
440 440
441 441
442 You will need a filesystem to boot UML from. There are a number 442 You will need a filesystem to boot UML from. There are a number
443 available for download from here <http://user-mode- 443 available for download from here <http://user-mode-
444 linux.sourceforge.net/> . There are also several tools 444 linux.sourceforge.net/> . There are also several tools
445 <http://user-mode-linux.sourceforge.net/> which can be 445 <http://user-mode-linux.sourceforge.net/> which can be
446 used to generate UML-compatible filesystem images from media. 446 used to generate UML-compatible filesystem images from media.
447 The kernel will boot up and present you with a login prompt. 447 The kernel will boot up and present you with a login prompt.
448 448
449 449
450 Note: If the host is configured with a 2G/2G address space split 450 Note: If the host is configured with a 2G/2G address space split
451 rather than the usual 3G/1G split, then the packaged UML binaries will 451 rather than the usual 3G/1G split, then the packaged UML binaries will
452 not run. They will immediately segfault. See ``UML on 2G/2G hosts'' 452 not run. They will immediately segfault. See ``UML on 2G/2G hosts''
453 for the scoop on running UML on your system. 453 for the scoop on running UML on your system.
454 454
455 455
456 456
457 33..22.. LLooggggiinngg iinn 457 33..22.. LLooggggiinngg iinn
458 458
459 459
460 460
461 The prepackaged filesystems have a root account with password 'root' 461 The prepackaged filesystems have a root account with password 'root'
462 and a user account with password 'user'. The login banner will 462 and a user account with password 'user'. The login banner will
463 generally tell you how to log in. So, you log in and you will find 463 generally tell you how to log in. So, you log in and you will find
464 yourself inside a little virtual machine. Our filesystems have a 464 yourself inside a little virtual machine. Our filesystems have a
465 variety of commands and utilities installed (and it is fairly easy to 465 variety of commands and utilities installed (and it is fairly easy to
466 add more), so you will have a lot of tools with which to poke around 466 add more), so you will have a lot of tools with which to poke around
467 the system. 467 the system.
468 468
469 There are a couple of other ways to log in: 469 There are a couple of other ways to log in:
470 470
471 +o On a virtual console 471 +o On a virtual console
472 472
473 473
474 474
475 Each virtual console that is configured (i.e. the device exists in 475 Each virtual console that is configured (i.e. the device exists in
476 /dev and /etc/inittab runs a getty on it) will come up in its own 476 /dev and /etc/inittab runs a getty on it) will come up in its own
477 xterm. If you get tired of the xterms, read ``Setting up serial 477 xterm. If you get tired of the xterms, read ``Setting up serial
478 lines and consoles'' to see how to attach the consoles to 478 lines and consoles'' to see how to attach the consoles to
479 something else, like host ptys. 479 something else, like host ptys.
480 480
481 481
482 482
483 +o Over the serial line 483 +o Over the serial line
484 484
485 485
486 In the boot output, find a line that looks like: 486 In the boot output, find a line that looks like:
487 487
488 488
489 489
490 serial line 0 assigned pty /dev/ptyp1 490 serial line 0 assigned pty /dev/ptyp1
491 491
492 492
493 493
494 494
495 Attach your favorite terminal program to the corresponding tty. I.e. 495 Attach your favorite terminal program to the corresponding tty. I.e.
496 for minicom, the command would be 496 for minicom, the command would be
497 497
498 498
499 host% minicom -o -p /dev/ttyp1 499 host% minicom -o -p /dev/ttyp1
500 500
501 501
502 502
503 503
504 504
505 505
506 +o Over the net 506 +o Over the net
507 507
508 508
509 If the network is running, then you can telnet to the virtual 509 If the network is running, then you can telnet to the virtual
510 machine and log in to it. See ``Setting up the network'' to learn 510 machine and log in to it. See ``Setting up the network'' to learn
511 about setting up a virtual network. 511 about setting up a virtual network.
512 512
513 When you're done using it, run halt, and the kernel will bring itself 513 When you're done using it, run halt, and the kernel will bring itself
514 down and the process will exit. 514 down and the process will exit.
515 515
516 516
517 33..33.. EExxaammpplleess 517 33..33.. EExxaammpplleess
518 518
519 Here are some examples of UML in action: 519 Here are some examples of UML in action:
520 520
521 +o A login session <http://user-mode-linux.sourceforge.net/login.html> 521 +o A login session <http://user-mode-linux.sourceforge.net/login.html>
522 522
523 +o A virtual network <http://user-mode-linux.sourceforge.net/net.html> 523 +o A virtual network <http://user-mode-linux.sourceforge.net/net.html>
524 524
525 525
526 526
527 527
528 528
529 529
530 530
531 44.. UUMMLL oonn 22GG//22GG hhoossttss 531 44.. UUMMLL oonn 22GG//22GG hhoossttss
532 532
533 533
534 534
535 535
536 44..11.. IInnttrroodduuccttiioonn 536 44..11.. IInnttrroodduuccttiioonn
537 537
538 538
539 Most Linux machines are configured so that the kernel occupies the 539 Most Linux machines are configured so that the kernel occupies the
540 upper 1G (0xc0000000 - 0xffffffff) of the 4G address space and 540 upper 1G (0xc0000000 - 0xffffffff) of the 4G address space and
541 processes use the lower 3G (0x00000000 - 0xbfffffff). However, some 541 processes use the lower 3G (0x00000000 - 0xbfffffff). However, some
542 machine are configured with a 2G/2G split, with the kernel occupying 542 machine are configured with a 2G/2G split, with the kernel occupying
543 the upper 2G (0x80000000 - 0xffffffff) and processes using the lower 543 the upper 2G (0x80000000 - 0xffffffff) and processes using the lower
544 2G (0x00000000 - 0x7fffffff). 544 2G (0x00000000 - 0x7fffffff).
545 545
546 546
547 547
548 548
549 44..22.. TThhee pprroobblleemm 549 44..22.. TThhee pprroobblleemm
550 550
551 551
552 The prebuilt UML binaries on this site will not run on 2G/2G hosts 552 The prebuilt UML binaries on this site will not run on 2G/2G hosts
553 because UML occupies the upper .5G of the 3G process address space 553 because UML occupies the upper .5G of the 3G process address space
554 (0xa0000000 - 0xbfffffff). Obviously, on 2G/2G hosts, this is right 554 (0xa0000000 - 0xbfffffff). Obviously, on 2G/2G hosts, this is right
555 in the middle of the kernel address space, so UML won't even load - it 555 in the middle of the kernel address space, so UML won't even load - it
556 will immediately segfault. 556 will immediately segfault.
557 557
558 558
559 559
560 560
561 44..33.. TThhee ssoolluuttiioonn 561 44..33.. TThhee ssoolluuttiioonn
562 562
563 563
564 The fix for this is to rebuild UML from source after enabling 564 The fix for this is to rebuild UML from source after enabling
565 CONFIG_HOST_2G_2G (under 'General Setup'). This will cause UML to 565 CONFIG_HOST_2G_2G (under 'General Setup'). This will cause UML to
566 load itself in the top .5G of that smaller process address space, 566 load itself in the top .5G of that smaller process address space,
567 where it will run fine. See ``Compiling the kernel and modules'' if 567 where it will run fine. See ``Compiling the kernel and modules'' if
568 you need help building UML from source. 568 you need help building UML from source.
569 569
570 570
571 571
572 572
573 573
574 574
575 575
576 576
577 577
578 578
579 55.. SSeettttiinngg uupp sseerriiaall lliinneess aanndd ccoonnssoolleess 579 55.. SSeettttiinngg uupp sseerriiaall lliinneess aanndd ccoonnssoolleess
580 580
581 581
582 It is possible to attach UML serial lines and consoles to many types 582 It is possible to attach UML serial lines and consoles to many types
583 of host I/O channels by specifying them on the command line. 583 of host I/O channels by specifying them on the command line.
584 584
585 585
586 You can attach them to host ptys, ttys, file descriptors, and ports. 586 You can attach them to host ptys, ttys, file descriptors, and ports.
587 This allows you to do things like 587 This allows you to do things like
588 588
589 +o have a UML console appear on an unused host console, 589 +o have a UML console appear on an unused host console,
590 590
591 +o hook two virtual machines together by having one attach to a pty 591 +o hook two virtual machines together by having one attach to a pty
592 and having the other attach to the corresponding tty 592 and having the other attach to the corresponding tty
593 593
594 +o make a virtual machine accessible from the net by attaching a 594 +o make a virtual machine accessible from the net by attaching a
595 console to a port on the host. 595 console to a port on the host.
596 596
597 597
598 The general format of the command line option is device=channel. 598 The general format of the command line option is device=channel.
599 599
600 600
601 601
602 55..11.. SSppeecciiffyyiinngg tthhee ddeevviiccee 602 55..11.. SSppeecciiffyyiinngg tthhee ddeevviiccee
603 603
604 Devices are specified with "con" or "ssl" (console or serial line, 604 Devices are specified with "con" or "ssl" (console or serial line,
605 respectively), optionally with a device number if you are talking 605 respectively), optionally with a device number if you are talking
606 about a specific device. 606 about a specific device.
607 607
608 608
609 Using just "con" or "ssl" describes all of the consoles or serial 609 Using just "con" or "ssl" describes all of the consoles or serial
610 lines. If you want to talk about console #3 or serial line #10, they 610 lines. If you want to talk about console #3 or serial line #10, they
611 would be "con3" and "ssl10", respectively. 611 would be "con3" and "ssl10", respectively.
612 612
613 613
614 A specific device name will override a less general "con=" or "ssl=". 614 A specific device name will override a less general "con=" or "ssl=".
615 So, for example, you can assign a pty to each of the serial lines 615 So, for example, you can assign a pty to each of the serial lines
616 except for the first two like this: 616 except for the first two like this:
617 617
618 618
619 ssl=pty ssl0=tty:/dev/tty0 ssl1=tty:/dev/tty1 619 ssl=pty ssl0=tty:/dev/tty0 ssl1=tty:/dev/tty1
620 620
621 621
622 622
623 623
624 The specificity of the device name is all that matters; order on the 624 The specificity of the device name is all that matters; order on the
625 command line is irrelevant. 625 command line is irrelevant.
626 626
627 627
628 628
629 55..22.. SSppeecciiffyyiinngg tthhee cchhaannnneell 629 55..22.. SSppeecciiffyyiinngg tthhee cchhaannnneell
630 630
631 There are a number of different types of channels to attach a UML 631 There are a number of different types of channels to attach a UML
632 device to, each with a different way of specifying exactly what to 632 device to, each with a different way of specifying exactly what to
633 attach to. 633 attach to.
634 634
635 +o pseudo-terminals - device=pty pts terminals - device=pts 635 +o pseudo-terminals - device=pty pts terminals - device=pts
636 636
637 637
638 This will cause UML to allocate a free host pseudo-terminal for the 638 This will cause UML to allocate a free host pseudo-terminal for the
639 device. The terminal that it got will be announced in the boot 639 device. The terminal that it got will be announced in the boot
640 log. You access it by attaching a terminal program to the 640 log. You access it by attaching a terminal program to the
641 corresponding tty: 641 corresponding tty:
642 642
643 +o screen /dev/pts/n 643 +o screen /dev/pts/n
644 644
645 +o screen /dev/ttyxx 645 +o screen /dev/ttyxx
646 646
647 +o minicom -o -p /dev/ttyxx - minicom seems not able to handle pts 647 +o minicom -o -p /dev/ttyxx - minicom seems not able to handle pts
648 devices 648 devices
649 649
650 +o kermit - start it up, 'open' the device, then 'connect' 650 +o kermit - start it up, 'open' the device, then 'connect'
651 651
652 652
653 653
654 654
655 655
656 +o terminals - device=tty:tty device file 656 +o terminals - device=tty:tty device file
657 657
658 658
659 This will make UML attach the device to the specified tty (i.e 659 This will make UML attach the device to the specified tty (i.e
660 660
661 661
662 con1=tty:/dev/tty3 662 con1=tty:/dev/tty3
663 663
664 664
665 665
666 666
667 will attach UML's console 1 to the host's /dev/tty3). If the tty that 667 will attach UML's console 1 to the host's /dev/tty3). If the tty that
668 you specify is the slave end of a tty/pty pair, something else must 668 you specify is the slave end of a tty/pty pair, something else must
669 have already opened the corresponding pty in order for this to work. 669 have already opened the corresponding pty in order for this to work.
670 670
671 671
672 672
673 673
674 674
675 +o xterms - device=xterm 675 +o xterms - device=xterm
676 676
677 677
678 UML will run an xterm and the device will be attached to it. 678 UML will run an xterm and the device will be attached to it.
679 679
680 680
681 681
682 682
683 683
684 +o Port - device=port:port number 684 +o Port - device=port:port number
685 685
686 686
687 This will attach the UML devices to the specified host port. 687 This will attach the UML devices to the specified host port.
688 Attaching console 1 to the host's port 9000 would be done like 688 Attaching console 1 to the host's port 9000 would be done like
689 this: 689 this:
690 690
691 691
692 con1=port:9000 692 con1=port:9000
693 693
694 694
695 695
696 696
697 Attaching all the serial lines to that port would be done similarly: 697 Attaching all the serial lines to that port would be done similarly:
698 698
699 699
700 ssl=port:9000 700 ssl=port:9000
701 701
702 702
703 703
704 704
705 You access these devices by telnetting to that port. Each active tel- 705 You access these devices by telnetting to that port. Each active tel-
706 net session gets a different device. If there are more telnets to a 706 net session gets a different device. If there are more telnets to a
707 port than UML devices attached to it, then the extra telnet sessions 707 port than UML devices attached to it, then the extra telnet sessions
708 will block until an existing telnet detaches, or until another device 708 will block until an existing telnet detaches, or until another device
709 becomes active (i.e. by being activated in /etc/inittab). 709 becomes active (i.e. by being activated in /etc/inittab).
710 710
711 This channel has the advantage that you can both attach multiple UML 711 This channel has the advantage that you can both attach multiple UML
712 devices to it and know how to access them without reading the UML boot 712 devices to it and know how to access them without reading the UML boot
713 log. It is also unique in allowing access to a UML from remote 713 log. It is also unique in allowing access to a UML from remote
714 machines without requiring that the UML be networked. This could be 714 machines without requiring that the UML be networked. This could be
715 useful in allowing public access to UMLs because they would be 715 useful in allowing public access to UMLs because they would be
716 accessible from the net, but wouldn't need any kind of network 716 accessible from the net, but wouldn't need any kind of network
717 filtering or access control because they would have no network access. 717 filtering or access control because they would have no network access.
718 718
719 719
720 If you attach the main console to a portal, then the UML boot will 720 If you attach the main console to a portal, then the UML boot will
721 appear to hang. In reality, it's waiting for a telnet to connect, at 721 appear to hang. In reality, it's waiting for a telnet to connect, at
722 which point the boot will proceed. 722 which point the boot will proceed.
723 723
724 724
725 725
726 726
727 727
728 +o already-existing file descriptors - device=file descriptor 728 +o already-existing file descriptors - device=file descriptor
729 729
730 730
731 If you set up a file descriptor on the UML command line, you can 731 If you set up a file descriptor on the UML command line, you can
732 attach a UML device to it. This is most commonly used to put the 732 attach a UML device to it. This is most commonly used to put the
733 main console back on stdin and stdout after assigning all the other 733 main console back on stdin and stdout after assigning all the other
734 consoles to something else: 734 consoles to something else:
735 735
736 736
737 con0=fd:0,fd:1 con=pts 737 con0=fd:0,fd:1 con=pts
738 738
739 739
740 740
741 741
742 742
743 743
744 744
745 745
746 +o Nothing - device=null 746 +o Nothing - device=null
747 747
748 748
749 This allows the device to be opened, in contrast to 'none', but 749 This allows the device to be opened, in contrast to 'none', but
750 reads will block, and writes will succeed and the data will be 750 reads will block, and writes will succeed and the data will be
751 thrown out. 751 thrown out.
752 752
753 753
754 754
755 755
756 756
757 +o None - device=none 757 +o None - device=none
758 758
759 759
760 This causes the device to disappear. 760 This causes the device to disappear.
761 761
762 762
763 763
764 You can also specify different input and output channels for a device 764 You can also specify different input and output channels for a device
765 by putting a comma between them: 765 by putting a comma between them:
766 766
767 767
768 ssl3=tty:/dev/tty2,xterm 768 ssl3=tty:/dev/tty2,xterm
769 769
770 770
771 771
772 772
773 will cause serial line 3 to accept input on the host's /dev/tty3 and 773 will cause serial line 3 to accept input on the host's /dev/tty3 and
774 display output on an xterm. That's a silly example - the most common 774 display output on an xterm. That's a silly example - the most common
775 use of this syntax is to reattach the main console to stdin and stdout 775 use of this syntax is to reattach the main console to stdin and stdout
776 as shown above. 776 as shown above.
777 777
778 778
779 If you decide to move the main console away from stdin/stdout, the 779 If you decide to move the main console away from stdin/stdout, the
780 initial boot output will appear in the terminal that you're running 780 initial boot output will appear in the terminal that you're running
781 UML in. However, once the console driver has been officially 781 UML in. However, once the console driver has been officially
782 initialized, then the boot output will start appearing wherever you 782 initialized, then the boot output will start appearing wherever you
783 specified that console 0 should be. That device will receive all 783 specified that console 0 should be. That device will receive all
784 subsequent output. 784 subsequent output.
785 785
786 786
787 787
788 55..33.. EExxaammpplleess 788 55..33.. EExxaammpplleess
789 789
790 There are a number of interesting things you can do with this 790 There are a number of interesting things you can do with this
791 capability. 791 capability.
792 792
793 793
794 First, this is how you get rid of those bleeding console xterms by 794 First, this is how you get rid of those bleeding console xterms by
795 attaching them to host ptys: 795 attaching them to host ptys:
796 796
797 797
798 con=pty con0=fd:0,fd:1 798 con=pty con0=fd:0,fd:1
799 799
800 800
801 801
802 802
803 This will make a UML console take over an unused host virtual console, 803 This will make a UML console take over an unused host virtual console,
804 so that when you switch to it, you will see the UML login prompt 804 so that when you switch to it, you will see the UML login prompt
805 rather than the host login prompt: 805 rather than the host login prompt:
806 806
807 807
808 con1=tty:/dev/tty6 808 con1=tty:/dev/tty6
809 809
810 810
811 811
812 812
813 You can attach two virtual machines together with what amounts to a 813 You can attach two virtual machines together with what amounts to a
814 serial line as follows: 814 serial line as follows:
815 815
816 Run one UML with a serial line attached to a pty - 816 Run one UML with a serial line attached to a pty -
817 817
818 818
819 ssl1=pty 819 ssl1=pty
820 820
821 821
822 822
823 823
824 Look at the boot log to see what pty it got (this example will assume 824 Look at the boot log to see what pty it got (this example will assume
825 that it got /dev/ptyp1). 825 that it got /dev/ptyp1).
826 826
827 Boot the other UML with a serial line attached to the corresponding 827 Boot the other UML with a serial line attached to the corresponding
828 tty - 828 tty -
829 829
830 830
831 ssl1=tty:/dev/ttyp1 831 ssl1=tty:/dev/ttyp1
832 832
833 833
834 834
835 835
836 Log in, make sure that it has no getty on that serial line, attach a 836 Log in, make sure that it has no getty on that serial line, attach a
837 terminal program like minicom to it, and you should see the login 837 terminal program like minicom to it, and you should see the login
838 prompt of the other virtual machine. 838 prompt of the other virtual machine.
839 839
840 840
841 66.. SSeettttiinngg uupp tthhee nneettwwoorrkk 841 66.. SSeettttiinngg uupp tthhee nneettwwoorrkk
842 842
843 843
844 844
845 This page describes how to set up the various transports and to 845 This page describes how to set up the various transports and to
846 provide a UML instance with network access to the host, other machines 846 provide a UML instance with network access to the host, other machines
847 on the local net, and the rest of the net. 847 on the local net, and the rest of the net.
848 848
849 849
850 As of 2.4.5, UML networking has been completely redone to make it much 850 As of 2.4.5, UML networking has been completely redone to make it much
851 easier to set up, fix bugs, and add new features. 851 easier to set up, fix bugs, and add new features.
852 852
853 853
854 There is a new helper, uml_net, which does the host setup that 854 There is a new helper, uml_net, which does the host setup that
855 requires root privileges. 855 requires root privileges.
856 856
857 857
858 There are currently five transport types available for a UML virtual 858 There are currently five transport types available for a UML virtual
859 machine to exchange packets with other hosts: 859 machine to exchange packets with other hosts:
860 860
861 +o ethertap 861 +o ethertap
862 862
863 +o TUN/TAP 863 +o TUN/TAP
864 864
865 +o Multicast 865 +o Multicast
866 866
867 +o a switch daemon 867 +o a switch daemon
868 868
869 +o slip 869 +o slip
870 870
871 +o slirp 871 +o slirp
872 872
873 +o pcap 873 +o pcap
874 874
875 The TUN/TAP, ethertap, slip, and slirp transports allow a UML 875 The TUN/TAP, ethertap, slip, and slirp transports allow a UML
876 instance to exchange packets with the host. They may be directed 876 instance to exchange packets with the host. They may be directed
877 to the host or the host may just act as a router to provide access 877 to the host or the host may just act as a router to provide access
878 to other physical or virtual machines. 878 to other physical or virtual machines.
879 879
880 880
881 The pcap transport is a synthetic read-only interface, using the 881 The pcap transport is a synthetic read-only interface, using the
882 libpcap binary to collect packets from interfaces on the host and 882 libpcap binary to collect packets from interfaces on the host and
883 filter them. This is useful for building preconfigured traffic 883 filter them. This is useful for building preconfigured traffic
884 monitors or sniffers. 884 monitors or sniffers.
885 885
886 886
887 The daemon and multicast transports provide a completely virtual 887 The daemon and multicast transports provide a completely virtual
888 network to other virtual machines. This network is completely 888 network to other virtual machines. This network is completely
889 disconnected from the physical network unless one of the virtual 889 disconnected from the physical network unless one of the virtual
890 machines on it is acting as a gateway. 890 machines on it is acting as a gateway.
891 891
892 892
893 With so many host transports, which one should you use? Here's when 893 With so many host transports, which one should you use? Here's when
894 you should use each one: 894 you should use each one:
895 895
896 +o ethertap - if you want access to the host networking and it is 896 +o ethertap - if you want access to the host networking and it is
897 running 2.2 897 running 2.2
898 898
899 +o TUN/TAP - if you want access to the host networking and it is 899 +o TUN/TAP - if you want access to the host networking and it is
900 running 2.4. Also, the TUN/TAP transport is able to use a 900 running 2.4. Also, the TUN/TAP transport is able to use a
901 preconfigured device, allowing it to avoid using the setuid uml_net 901 preconfigured device, allowing it to avoid using the setuid uml_net
902 helper, which is a security advantage. 902 helper, which is a security advantage.
903 903
904 +o Multicast - if you want a purely virtual network and you don't want 904 +o Multicast - if you want a purely virtual network and you don't want
905 to set up anything but the UML 905 to set up anything but the UML
906 906
907 +o a switch daemon - if you want a purely virtual network and you 907 +o a switch daemon - if you want a purely virtual network and you
908 don't mind running the daemon in order to get somewhat better 908 don't mind running the daemon in order to get somewhat better
909 performance 909 performance
910 910
911 +o slip - there is no particular reason to run the slip backend unless 911 +o slip - there is no particular reason to run the slip backend unless
912 ethertap and TUN/TAP are just not available for some reason 912 ethertap and TUN/TAP are just not available for some reason
913 913
914 +o slirp - if you don't have root access on the host to setup 914 +o slirp - if you don't have root access on the host to setup
915 networking, or if you don't want to allocate an IP to your UML 915 networking, or if you don't want to allocate an IP to your UML
916 916
917 +o pcap - not much use for actual network connectivity, but great for 917 +o pcap - not much use for actual network connectivity, but great for
918 monitoring traffic on the host 918 monitoring traffic on the host
919 919
920 Ethertap is available on 2.4 and works fine. TUN/TAP is preferred 920 Ethertap is available on 2.4 and works fine. TUN/TAP is preferred
921 to it because it has better performance and ethertap is officially 921 to it because it has better performance and ethertap is officially
922 considered obsolete in 2.4. Also, the root helper only needs to 922 considered obsolete in 2.4. Also, the root helper only needs to
923 run occasionally for TUN/TAP, rather than handling every packet, as 923 run occasionally for TUN/TAP, rather than handling every packet, as
924 it does with ethertap. This is a slight security advantage since 924 it does with ethertap. This is a slight security advantage since
925 it provides fewer opportunities for a nasty UML user to somehow 925 it provides fewer opportunities for a nasty UML user to somehow
926 exploit the helper's root privileges. 926 exploit the helper's root privileges.
927 927
928 928
929 66..11.. GGeenneerraall sseettuupp 929 66..11.. GGeenneerraall sseettuupp
930 930
931 First, you must have the virtual network enabled in your UML. If are 931 First, you must have the virtual network enabled in your UML. If are
932 running a prebuilt kernel from this site, everything is already 932 running a prebuilt kernel from this site, everything is already
933 enabled. If you build the kernel yourself, under the "Network device 933 enabled. If you build the kernel yourself, under the "Network device
934 support" menu, enable "Network device support", and then the three 934 support" menu, enable "Network device support", and then the three
935 transports. 935 transports.
936 936
937 937
938 The next step is to provide a network device to the virtual machine. 938 The next step is to provide a network device to the virtual machine.
939 This is done by describing it on the kernel command line. 939 This is done by describing it on the kernel command line.
940 940
941 The general format is 941 The general format is
942 942
943 943
944 eth <n> = <transport> , <transport args> 944 eth <n> = <transport> , <transport args>
945 945
946 946
947 947
948 948
949 For example, a virtual ethernet device may be attached to a host 949 For example, a virtual ethernet device may be attached to a host
950 ethertap device as follows: 950 ethertap device as follows:
951 951
952 952
953 eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254 953 eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254
954 954
955 955
956 956
957 957
958 This sets up eth0 inside the virtual machine to attach itself to the 958 This sets up eth0 inside the virtual machine to attach itself to the
959 host /dev/tap0, assigns it an ethernet address, and assigns the host 959 host /dev/tap0, assigns it an ethernet address, and assigns the host
960 tap0 interface an IP address. 960 tap0 interface an IP address.
961 961
962 962
963 963
964 Note that the IP address you assign to the host end of the tap device 964 Note that the IP address you assign to the host end of the tap device
965 must be different than the IP you assign to the eth device inside UML. 965 must be different than the IP you assign to the eth device inside UML.
966 If you are short on IPs and don't want to consume two per UML, then 966 If you are short on IPs and don't want to consume two per UML, then
967 you can reuse the host's eth IP address for the host ends of the tap 967 you can reuse the host's eth IP address for the host ends of the tap
968 devices. Internally, the UMLs must still get unique IPs for their eth 968 devices. Internally, the UMLs must still get unique IPs for their eth
969 devices. You can also give the UMLs non-routable IPs (192.168.x.x or 969 devices. You can also give the UMLs non-routable IPs (192.168.x.x or
970 10.x.x.x) and have the host masquerade them. This will let outgoing 970 10.x.x.x) and have the host masquerade them. This will let outgoing
971 connections work, but incoming connections won't without more work, 971 connections work, but incoming connections won't without more work,
972 such as port forwarding from the host. 972 such as port forwarding from the host.
973 Also note that when you configure the host side of an interface, it is 973 Also note that when you configure the host side of an interface, it is
974 only acting as a gateway. It will respond to pings sent to it 974 only acting as a gateway. It will respond to pings sent to it
975 locally, but is not useful to do that since it's a host interface. 975 locally, but is not useful to do that since it's a host interface.
976 You are not talking to the UML when you ping that interface and get a 976 You are not talking to the UML when you ping that interface and get a
977 response. 977 response.
978 978
979 979
980 You can also add devices to a UML and remove them at runtime. See the 980 You can also add devices to a UML and remove them at runtime. See the
981 ``The Management Console'' page for details. 981 ``The Management Console'' page for details.
982 982
983 983
984 The sections below describe this in more detail. 984 The sections below describe this in more detail.
985 985
986 986
987 Once you've decided how you're going to set up the devices, you boot 987 Once you've decided how you're going to set up the devices, you boot
988 UML, log in, configure the UML side of the devices, and set up routes 988 UML, log in, configure the UML side of the devices, and set up routes
989 to the outside world. At that point, you will be able to talk to any 989 to the outside world. At that point, you will be able to talk to any
990 other machines, physical or virtual, on the net. 990 other machines, physical or virtual, on the net.
991 991
992 992
993 If ifconfig inside UML fails and the network refuses to come up, run 993 If ifconfig inside UML fails and the network refuses to come up, run
994 tell you what went wrong. 994 tell you what went wrong.
995 995
996 996
997 997
998 66..22.. UUsseerrssppaaccee ddaaeemmoonnss 998 66..22.. UUsseerrssppaaccee ddaaeemmoonnss
999 999
1000 You will likely need the setuid helper, or the switch daemon, or both. 1000 You will likely need the setuid helper, or the switch daemon, or both.
1001 They are both installed with the RPM and deb, so if you've installed 1001 They are both installed with the RPM and deb, so if you've installed
1002 either, you can skip the rest of this section. 1002 either, you can skip the rest of this section.
1003 1003
1004 1004
1005 If not, then you need to check them out of CVS, build them, and 1005 If not, then you need to check them out of CVS, build them, and
1006 install them. The helper is uml_net, in CVS /tools/uml_net, and the 1006 install them. The helper is uml_net, in CVS /tools/uml_net, and the
1007 daemon is uml_switch, in CVS /tools/uml_router. They are both built 1007 daemon is uml_switch, in CVS /tools/uml_router. They are both built
1008 with a plain 'make'. Both need to be installed in a directory that's 1008 with a plain 'make'. Both need to be installed in a directory that's
1009 in your path - /usr/bin is recommend. On top of that, uml_net needs 1009 in your path - /usr/bin is recommend. On top of that, uml_net needs
1010 to be setuid root. 1010 to be setuid root.
1011 1011
1012 1012
1013 1013
1014 66..33.. SSppeecciiffyyiinngg eetthheerrnneett aaddddrreesssseess 1014 66..33.. SSppeecciiffyyiinngg eetthheerrnneett aaddddrreesssseess
1015 1015
1016 Below, you will see that the TUN/TAP, ethertap, and daemon interfaces 1016 Below, you will see that the TUN/TAP, ethertap, and daemon interfaces
1017 allow you to specify hardware addresses for the virtual ethernet 1017 allow you to specify hardware addresses for the virtual ethernet
1018 devices. This is generally not necessary. If you don't have a 1018 devices. This is generally not necessary. If you don't have a
1019 specific reason to do it, you probably shouldn't. If one is not 1019 specific reason to do it, you probably shouldn't. If one is not
1020 specified on the command line, the driver will assign one based on the 1020 specified on the command line, the driver will assign one based on the
1021 device IP address. It will provide the address fe:fd:nn:nn:nn:nn 1021 device IP address. It will provide the address fe:fd:nn:nn:nn:nn
1022 where nn.nn.nn.nn is the device IP address. This is nearly always 1022 where nn.nn.nn.nn is the device IP address. This is nearly always
1023 sufficient to guarantee a unique hardware address for the device. A 1023 sufficient to guarantee a unique hardware address for the device. A
1024 couple of exceptions are: 1024 couple of exceptions are:
1025 1025
1026 +o Another set of virtual ethernet devices are on the same network and 1026 +o Another set of virtual ethernet devices are on the same network and
1027 they are assigned hardware addresses using a different scheme which 1027 they are assigned hardware addresses using a different scheme which
1028 may conflict with the UML IP address-based scheme 1028 may conflict with the UML IP address-based scheme
1029 1029
1030 +o You aren't going to use the device for IP networking, so you don't 1030 +o You aren't going to use the device for IP networking, so you don't
1031 assign the device an IP address 1031 assign the device an IP address
1032 1032
1033 If you let the driver provide the hardware address, you should make 1033 If you let the driver provide the hardware address, you should make
1034 sure that the device IP address is known before the interface is 1034 sure that the device IP address is known before the interface is
1035 brought up. So, inside UML, this will guarantee that: 1035 brought up. So, inside UML, this will guarantee that:
1036 1036
1037 1037
1038 1038
1039 UML# 1039 UML#
1040 ifconfig eth0 192.168.0.250 up 1040 ifconfig eth0 192.168.0.250 up
1041 1041
1042 1042
1043 1043
1044 1044
1045 If you decide to assign the hardware address yourself, make sure that 1045 If you decide to assign the hardware address yourself, make sure that
1046 the first byte of the address is even. Addresses with an odd first 1046 the first byte of the address is even. Addresses with an odd first
1047 byte are broadcast addresses, which you don't want assigned to a 1047 byte are broadcast addresses, which you don't want assigned to a
1048 device. 1048 device.
1049 1049
1050 1050
1051 1051
1052 66..44.. UUMMLL iinntteerrffaaccee sseettuupp 1052 66..44.. UUMMLL iinntteerrffaaccee sseettuupp
1053 1053
1054 Once the network devices have been described on the command line, you 1054 Once the network devices have been described on the command line, you
1055 should boot UML and log in. 1055 should boot UML and log in.
1056 1056
1057 1057
1058 The first thing to do is bring the interface up: 1058 The first thing to do is bring the interface up:
1059 1059
1060 1060
1061 UML# ifconfig ethn ip-address up 1061 UML# ifconfig ethn ip-address up
1062 1062
1063 1063
1064 1064
1065 1065
1066 You should be able to ping the host at this point. 1066 You should be able to ping the host at this point.
1067 1067
1068 1068
1069 To reach the rest of the world, you should set a default route to the 1069 To reach the rest of the world, you should set a default route to the
1070 host: 1070 host:
1071 1071
1072 1072
1073 UML# route add default gw host ip 1073 UML# route add default gw host ip
1074 1074
1075 1075
1076 1076
1077 1077
1078 Again, with host ip of 192.168.0.4: 1078 Again, with host ip of 192.168.0.4:
1079 1079
1080 1080
1081 UML# route add default gw 192.168.0.4 1081 UML# route add default gw 192.168.0.4
1082 1082
1083 1083
1084 1084
1085 1085
1086 This page used to recommend setting a network route to your local net. 1086 This page used to recommend setting a network route to your local net.
1087 This is wrong, because it will cause UML to try to figure out hardware 1087 This is wrong, because it will cause UML to try to figure out hardware
1088 addresses of the local machines by arping on the interface to the 1088 addresses of the local machines by arping on the interface to the
1089 host. Since that interface is basically a single strand of ethernet 1089 host. Since that interface is basically a single strand of ethernet
1090 with two nodes on it (UML and the host) and arp requests don't cross 1090 with two nodes on it (UML and the host) and arp requests don't cross
1091 networks, they will fail to elicit any responses. So, what you want 1091 networks, they will fail to elicit any responses. So, what you want
1092 is for UML to just blindly throw all packets at the host and let it 1092 is for UML to just blindly throw all packets at the host and let it
1093 figure out what to do with them, which is what leaving out the network 1093 figure out what to do with them, which is what leaving out the network
1094 route and adding the default route does. 1094 route and adding the default route does.
1095 1095
1096 1096
1097 Note: If you can't communicate with other hosts on your physical 1097 Note: If you can't communicate with other hosts on your physical
1098 ethernet, it's probably because of a network route that's 1098 ethernet, it's probably because of a network route that's
1099 automatically set up. If you run 'route -n' and see a route that 1099 automatically set up. If you run 'route -n' and see a route that
1100 looks like this: 1100 looks like this:
1101 1101
1102 1102
1103 1103
1104 1104
1105 Destination Gateway Genmask Flags Metric Ref Use Iface 1105 Destination Gateway Genmask Flags Metric Ref Use Iface
1106 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 1106 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
1107 1107
1108 1108
1109 1109
1110 1110
1111 with a mask that's not 255.255.255.255, then replace it with a route 1111 with a mask that's not 255.255.255.255, then replace it with a route
1112 to your host: 1112 to your host:
1113 1113
1114 1114
1115 UML# 1115 UML#
1116 route del -net 192.168.0.0 dev eth0 netmask 255.255.255.0 1116 route del -net 192.168.0.0 dev eth0 netmask 255.255.255.0
1117 1117
1118 1118
1119 1119
1120 1120
1121 1121
1122 1122
1123 UML# 1123 UML#
1124 route add -host 192.168.0.4 dev eth0 1124 route add -host 192.168.0.4 dev eth0
1125 1125
1126 1126
1127 1127
1128 1128
1129 This, plus the default route to the host, will allow UML to exchange 1129 This, plus the default route to the host, will allow UML to exchange
1130 packets with any machine on your ethernet. 1130 packets with any machine on your ethernet.
1131 1131
1132 1132
1133 1133
1134 66..55.. MMuullttiiccaasstt 1134 66..55.. MMuullttiiccaasstt
1135 1135
1136 The simplest way to set up a virtual network between multiple UMLs is 1136 The simplest way to set up a virtual network between multiple UMLs is
1137 to use the mcast transport. This was written by Harald Welte and is 1137 to use the mcast transport. This was written by Harald Welte and is
1138 present in UML version 2.4.5-5um and later. Your system must have 1138 present in UML version 2.4.5-5um and later. Your system must have
1139 multicast enabled in the kernel and there must be a multicast-capable 1139 multicast enabled in the kernel and there must be a multicast-capable
1140 network device on the host. Normally, this is eth0, but if there is 1140 network device on the host. Normally, this is eth0, but if there is
1141 no ethernet card on the host, then you will likely get strange error 1141 no ethernet card on the host, then you will likely get strange error
1142 messages when you bring the device up inside UML. 1142 messages when you bring the device up inside UML.
1143 1143
1144 1144
1145 To use it, run two UMLs with 1145 To use it, run two UMLs with
1146 1146
1147 1147
1148 eth0=mcast 1148 eth0=mcast
1149 1149
1150 1150
1151 1151
1152 1152
1153 on their command lines. Log in, configure the ethernet device in each 1153 on their command lines. Log in, configure the ethernet device in each
1154 machine with different IP addresses: 1154 machine with different IP addresses:
1155 1155
1156 1156
1157 UML1# ifconfig eth0 192.168.0.254 1157 UML1# ifconfig eth0 192.168.0.254
1158 1158
1159 1159
1160 1160
1161 1161
1162 1162
1163 1163
1164 UML2# ifconfig eth0 192.168.0.253 1164 UML2# ifconfig eth0 192.168.0.253
1165 1165
1166 1166
1167 1167
1168 1168
1169 and they should be able to talk to each other. 1169 and they should be able to talk to each other.
1170 1170
1171 The full set of command line options for this transport are 1171 The full set of command line options for this transport are
1172 1172
1173 1173
1174 1174
1175 ethn=mcast,ethernet address,multicast 1175 ethn=mcast,ethernet address,multicast
1176 address,multicast port,ttl 1176 address,multicast port,ttl
1177 1177
1178 1178
1179 1179
1180 1180
1181 Harald's original README is here <http://user-mode-linux.source- 1181 Harald's original README is here <http://user-mode-linux.source-
1182 forge.net/> and explains these in detail, as well as 1182 forge.net/> and explains these in detail, as well as
1183 some other issues. 1183 some other issues.
1184 1184
1185 There is also a related point-to-point only "ucast" transport.
1186 This is useful when your network does not support multicast, and
1187 all network connections are simple point to point links.
1188
1189 The full set of command line options for this transport are
1190
1191
1192 ethn=ucast,ethernet address,remote address,listen port,remote port
1193
1194
1185 1195
1186 1196
1187 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr 1197 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr
1188 1198
1189 TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the 1199 TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the
1190 host. The TUN/TAP backend has been in UML since 2.4.9-3um. 1200 host. The TUN/TAP backend has been in UML since 2.4.9-3um.
1191 1201
1192 1202
1193 The easiest way to get up and running is to let the setuid uml_net 1203 The easiest way to get up and running is to let the setuid uml_net
1194 helper do the host setup for you. This involves insmod-ing the tun.o 1204 helper do the host setup for you. This involves insmod-ing the tun.o
1195 module if necessary, configuring the device, and setting up IP 1205 module if necessary, configuring the device, and setting up IP
1196 forwarding, routing, and proxy arp. If you are new to UML networking, 1206 forwarding, routing, and proxy arp. If you are new to UML networking,
1197 do this first. If you're concerned about the security implications of 1207 do this first. If you're concerned about the security implications of
1198 the setuid helper, use it to get up and running, then read the next 1208 the setuid helper, use it to get up and running, then read the next
1199 section to see how to have UML use a preconfigured tap device, which 1209 section to see how to have UML use a preconfigured tap device, which
1200 avoids the use of uml_net. 1210 avoids the use of uml_net.
1201 1211
1202 1212
1203 If you specify an IP address for the host side of the device, the 1213 If you specify an IP address for the host side of the device, the
1204 uml_net helper will do all necessary setup on the host - the only 1214 uml_net helper will do all necessary setup on the host - the only
1205 requirement is that TUN/TAP be available, either built in to the host 1215 requirement is that TUN/TAP be available, either built in to the host
1206 kernel or as the tun.o module. 1216 kernel or as the tun.o module.
1207 1217
1208 The format of the command line switch to attach a device to a TUN/TAP 1218 The format of the command line switch to attach a device to a TUN/TAP
1209 device is 1219 device is
1210 1220
1211 1221
1212 eth <n> =tuntap,,, <IP address> 1222 eth <n> =tuntap,,, <IP address>
1213 1223
1214 1224
1215 1225
1216 1226
1217 For example, this argument will attach the UML's eth0 to the next 1227 For example, this argument will attach the UML's eth0 to the next
1218 available tap device and assign an ethernet address to it based on its 1228 available tap device and assign an ethernet address to it based on its
1219 IP address 1229 IP address
1220 1230
1221 1231
1222 eth0=tuntap,,,192.168.0.254 1232 eth0=tuntap,,,192.168.0.254
1223 1233
1224 1234
1225 1235
1226 1236
1227 1237
1228 1238
1229 Note that the IP address that must be used for the eth device inside 1239 Note that the IP address that must be used for the eth device inside
1230 UML is fixed by the routing and proxy arp that is set up on the 1240 UML is fixed by the routing and proxy arp that is set up on the
1231 TUN/TAP device on the host. You can use a different one, but it won't 1241 TUN/TAP device on the host. You can use a different one, but it won't
1232 work because reply packets won't reach the UML. This is a feature. 1242 work because reply packets won't reach the UML. This is a feature.
1233 It prevents a nasty UML user from doing things like setting the UML IP 1243 It prevents a nasty UML user from doing things like setting the UML IP
1234 to the same as the network's nameserver or mail server. 1244 to the same as the network's nameserver or mail server.
1235 1245
1236 1246
1237 There are a couple potential problems with running the TUN/TAP 1247 There are a couple potential problems with running the TUN/TAP
1238 transport on a 2.4 host kernel 1248 transport on a 2.4 host kernel
1239 1249
1240 +o TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host 1250 +o TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host
1241 kernel or use the ethertap transport. 1251 kernel or use the ethertap transport.
1242 1252
1243 +o With an upgraded kernel, TUN/TAP may fail with 1253 +o With an upgraded kernel, TUN/TAP may fail with
1244 1254
1245 1255
1246 File descriptor in bad state 1256 File descriptor in bad state
1247 1257
1248 1258
1249 1259
1250 1260
1251 This is due to a header mismatch between the upgraded kernel and the 1261 This is due to a header mismatch between the upgraded kernel and the
1252 kernel that was originally installed on the machine. The fix is to 1262 kernel that was originally installed on the machine. The fix is to
1253 make sure that /usr/src/linux points to the headers for the running 1263 make sure that /usr/src/linux points to the headers for the running
1254 kernel. 1264 kernel.
1255 1265
1256 These were pointed out by Tim Robinson <timro at trkr dot net> in 1266 These were pointed out by Tim Robinson <timro at trkr dot net> in
1257 <http://www.geocrawler.com/> name="this uml- 1267 <http://www.geocrawler.com/> name="this uml-
1258 user post"> . 1268 user post"> .
1259 1269
1260 1270
1261 1271
1262 66..77.. TTUUNN//TTAAPP wwiitthh aa pprreeccoonnffiigguurreedd ttaapp ddeevviiccee 1272 66..77.. TTUUNN//TTAAPP wwiitthh aa pprreeccoonnffiigguurreedd ttaapp ddeevviiccee
1263 1273
1264 If you prefer not to have UML use uml_net (which is somewhat 1274 If you prefer not to have UML use uml_net (which is somewhat
1265 insecure), with UML 2.4.17-11, you can set up a TUN/TAP device 1275 insecure), with UML 2.4.17-11, you can set up a TUN/TAP device
1266 beforehand. The setup needs to be done as root, but once that's done, 1276 beforehand. The setup needs to be done as root, but once that's done,
1267 there is no need for root assistance. Setting up the device is done 1277 there is no need for root assistance. Setting up the device is done
1268 as follows: 1278 as follows:
1269 1279
1270 +o Create the device with tunctl (available from the UML utilities 1280 +o Create the device with tunctl (available from the UML utilities
1271 tarball) 1281 tarball)
1272 1282
1273 1283
1274 1284
1275 1285
1276 host# tunctl -u uid 1286 host# tunctl -u uid
1277 1287
1278 1288
1279 1289
1280 1290
1281 where uid is the user id or username that UML will be run as. This 1291 where uid is the user id or username that UML will be run as. This
1282 will tell you what device was created. 1292 will tell you what device was created.
1283 1293
1284 +o Configure the device IP (change IP addresses and device name to 1294 +o Configure the device IP (change IP addresses and device name to
1285 suit) 1295 suit)
1286 1296
1287 1297
1288 1298
1289 1299
1290 host# ifconfig tap0 192.168.0.254 up 1300 host# ifconfig tap0 192.168.0.254 up
1291 1301
1292 1302
1293 1303
1294 1304
1295 1305
1296 +o Set up routing and arping if desired - this is my recipe, there are 1306 +o Set up routing and arping if desired - this is my recipe, there are
1297 other ways of doing the same thing 1307 other ways of doing the same thing
1298 1308
1299 1309
1300 host# 1310 host#
1301 bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward' 1311 bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
1302 1312
1303 host# 1313 host#
1304 route add -host 192.168.0.253 dev tap0 1314 route add -host 192.168.0.253 dev tap0
1305 1315
1306 1316
1307 1317
1308 1318
1309 1319
1310 1320
1311 host# 1321 host#
1312 bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp' 1322 bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'
1313 1323
1314 1324
1315 1325
1316 1326
1317 1327
1318 1328
1319 host# 1329 host#
1320 arp -Ds 192.168.0.253 eth0 pub 1330 arp -Ds 192.168.0.253 eth0 pub
1321 1331
1322 1332
1323 1333
1324 1334
1325 Note that this must be done every time the host boots - this configu- 1335 Note that this must be done every time the host boots - this configu-
1326 ration is not stored across host reboots. So, it's probably a good 1336 ration is not stored across host reboots. So, it's probably a good
1327 idea to stick it in an rc file. An even better idea would be a little 1337 idea to stick it in an rc file. An even better idea would be a little
1328 utility which reads the information from a config file and sets up 1338 utility which reads the information from a config file and sets up
1329 devices at boot time. 1339 devices at boot time.
1330 1340
1331 +o Rather than using up two IPs and ARPing for one of them, you can 1341 +o Rather than using up two IPs and ARPing for one of them, you can
1332 also provide direct access to your LAN by the UML by using a 1342 also provide direct access to your LAN by the UML by using a
1333 bridge. 1343 bridge.
1334 1344
1335 1345
1336 host# 1346 host#
1337 brctl addbr br0 1347 brctl addbr br0
1338 1348
1339 1349
1340 1350
1341 1351
1342 1352
1343 1353
1344 host# 1354 host#
1345 ifconfig eth0 0.0.0.0 promisc up 1355 ifconfig eth0 0.0.0.0 promisc up
1346 1356
1347 1357
1348 1358
1349 1359
1350 1360
1351 1361
1352 host# 1362 host#
1353 ifconfig tap0 0.0.0.0 promisc up 1363 ifconfig tap0 0.0.0.0 promisc up
1354 1364
1355 1365
1356 1366
1357 1367
1358 1368
1359 1369
1360 host# 1370 host#
1361 ifconfig br0 192.168.0.1 netmask 255.255.255.0 up 1371 ifconfig br0 192.168.0.1 netmask 255.255.255.0 up
1362 1372
1363 1373
1364 1374
1365 1375
1366 1376
1367 1377
1368 1378
1369 host# 1379 host#
1370 brctl stp br0 off 1380 brctl stp br0 off
1371 1381
1372 1382
1373 1383
1374 1384
1375 1385
1376 1386
1377 host# 1387 host#
1378 brctl setfd br0 1 1388 brctl setfd br0 1
1379 1389
1380 1390
1381 1391
1382 1392
1383 1393
1384 1394
1385 host# 1395 host#
1386 brctl sethello br0 1 1396 brctl sethello br0 1
1387 1397
1388 1398
1389 1399
1390 1400
1391 1401
1392 1402
1393 host# 1403 host#
1394 brctl addif br0 eth0 1404 brctl addif br0 eth0
1395 1405
1396 1406
1397 1407
1398 1408
1399 1409
1400 1410
1401 host# 1411 host#
1402 brctl addif br0 tap0 1412 brctl addif br0 tap0
1403 1413
1404 1414
1405 1415
1406 1416
1407 Note that 'br0' should be setup using ifconfig with the existing IP 1417 Note that 'br0' should be setup using ifconfig with the existing IP
1408 address of eth0, as eth0 no longer has its own IP. 1418 address of eth0, as eth0 no longer has its own IP.
1409 1419
1410 +o 1420 +o
1411 1421
1412 1422
1413 Also, the /dev/net/tun device must be writable by the user running 1423 Also, the /dev/net/tun device must be writable by the user running
1414 UML in order for the UML to use the device that's been configured 1424 UML in order for the UML to use the device that's been configured
1415 for it. The simplest thing to do is 1425 for it. The simplest thing to do is
1416 1426
1417 1427
1418 host# chmod 666 /dev/net/tun 1428 host# chmod 666 /dev/net/tun
1419 1429
1420 1430
1421 1431
1422 1432
1423 Making it world-writable looks bad, but it seems not to be 1433 Making it world-writable looks bad, but it seems not to be
1424 exploitable as a security hole. However, it does allow anyone to cre- 1434 exploitable as a security hole. However, it does allow anyone to cre-
1425 ate useless tap devices (useless because they can't configure them), 1435 ate useless tap devices (useless because they can't configure them),
1426 which is a DOS attack. A somewhat more secure alternative would to be 1436 which is a DOS attack. A somewhat more secure alternative would to be
1427 to create a group containing all the users who have preconfigured tap 1437 to create a group containing all the users who have preconfigured tap
1428 devices and chgrp /dev/net/tun to that group with mode 664 or 660. 1438 devices and chgrp /dev/net/tun to that group with mode 664 or 660.
1429 1439
1430 1440
1431 +o Once the device is set up, run UML with 'eth0=tuntap,device name' 1441 +o Once the device is set up, run UML with 'eth0=tuntap,device name'
1432 (i.e. 'eth0=tuntap,tap0') on the command line (or do it with the 1442 (i.e. 'eth0=tuntap,tap0') on the command line (or do it with the
1433 mconsole config command). 1443 mconsole config command).
1434 1444
1435 +o Bring the eth device up in UML and you're in business. 1445 +o Bring the eth device up in UML and you're in business.
1436 1446
1437 If you don't want that tap device any more, you can make it non- 1447 If you don't want that tap device any more, you can make it non-
1438 persistent with 1448 persistent with
1439 1449
1440 1450
1441 host# tunctl -d tap device 1451 host# tunctl -d tap device
1442 1452
1443 1453
1444 1454
1445 1455
1446 Finally, tunctl has a -b (for brief mode) switch which causes it to 1456 Finally, tunctl has a -b (for brief mode) switch which causes it to
1447 output only the name of the tap device it created. This makes it 1457 output only the name of the tap device it created. This makes it
1448 suitable for capture by a script: 1458 suitable for capture by a script:
1449 1459
1450 1460
1451 host# TAP=`tunctl -u 1000 -b` 1461 host# TAP=`tunctl -u 1000 -b`
1452 1462
1453 1463
1454 1464
1455 1465
1456 1466
1457 1467
1458 66..88.. EEtthheerrttaapp 1468 66..88.. EEtthheerrttaapp
1459 1469
1460 Ethertap is the general mechanism on 2.2 for userspace processes to 1470 Ethertap is the general mechanism on 2.2 for userspace processes to
1461 exchange packets with the kernel. 1471 exchange packets with the kernel.
1462 1472
1463 1473
1464 1474
1465 To use this transport, you need to describe the virtual network device 1475 To use this transport, you need to describe the virtual network device
1466 on the UML command line. The general format for this is 1476 on the UML command line. The general format for this is
1467 1477
1468 1478
1469 eth <n> =ethertap, <device> , <ethernet address> , <tap IP address> 1479 eth <n> =ethertap, <device> , <ethernet address> , <tap IP address>
1470 1480
1471 1481
1472 1482
1473 1483
1474 So, the previous example 1484 So, the previous example
1475 1485
1476 1486
1477 eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254 1487 eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254
1478 1488
1479 1489
1480 1490
1481 1491
1482 attaches the UML eth0 device to the host /dev/tap0, assigns it the 1492 attaches the UML eth0 device to the host /dev/tap0, assigns it the
1483 ethernet address fe:fd:0:0:0:1, and assigns the IP address 1493 ethernet address fe:fd:0:0:0:1, and assigns the IP address
1484 192.168.0.254 to the tap device. 1494 192.168.0.254 to the tap device.
1485 1495
1486 1496
1487 1497
1488 The tap device is mandatory, but the others are optional. If the 1498 The tap device is mandatory, but the others are optional. If the
1489 ethernet address is omitted, one will be assigned to it. 1499 ethernet address is omitted, one will be assigned to it.
1490 1500
1491 1501
1492 The presence of the tap IP address will cause the helper to run and do 1502 The presence of the tap IP address will cause the helper to run and do
1493 whatever host setup is needed to allow the virtual machine to 1503 whatever host setup is needed to allow the virtual machine to
1494 communicate with the outside world. If you're not sure you know what 1504 communicate with the outside world. If you're not sure you know what
1495 you're doing, this is the way to go. 1505 you're doing, this is the way to go.
1496 1506
1497 1507
1498 If it is absent, then you must configure the tap device and whatever 1508 If it is absent, then you must configure the tap device and whatever
1499 arping and routing you will need on the host. However, even in this 1509 arping and routing you will need on the host. However, even in this
1500 case, the uml_net helper still needs to be in your path and it must be 1510 case, the uml_net helper still needs to be in your path and it must be
1501 setuid root if you're not running UML as root. This is because the 1511 setuid root if you're not running UML as root. This is because the
1502 tap device doesn't support SIGIO, which UML needs in order to use 1512 tap device doesn't support SIGIO, which UML needs in order to use
1503 something as a source of input. So, the helper is used as a 1513 something as a source of input. So, the helper is used as a
1504 convenient asynchronous IO thread. 1514 convenient asynchronous IO thread.
1505 1515
1506 If you're using the uml_net helper, you can ignore the following host 1516 If you're using the uml_net helper, you can ignore the following host
1507 setup - uml_net will do it for you. You just need to make sure you 1517 setup - uml_net will do it for you. You just need to make sure you
1508 have ethertap available, either built in to the host kernel or 1518 have ethertap available, either built in to the host kernel or
1509 available as a module. 1519 available as a module.
1510 1520
1511 1521
1512 If you want to set things up yourself, you need to make sure that the 1522 If you want to set things up yourself, you need to make sure that the
1513 appropriate /dev entry exists. If it doesn't, become root and create 1523 appropriate /dev entry exists. If it doesn't, become root and create
1514 it as follows: 1524 it as follows:
1515 1525
1516 1526
1517 mknod /dev/tap <minor> c 36 <minor> + 16 1527 mknod /dev/tap <minor> c 36 <minor> + 16
1518 1528
1519 1529
1520 1530
1521 1531
1522 For example, this is how to create /dev/tap0: 1532 For example, this is how to create /dev/tap0:
1523 1533
1524 1534
1525 mknod /dev/tap0 c 36 0 + 16 1535 mknod /dev/tap0 c 36 0 + 16
1526 1536
1527 1537
1528 1538
1529 1539
1530 You also need to make sure that the host kernel has ethertap support. 1540 You also need to make sure that the host kernel has ethertap support.
1531 If ethertap is enabled as a module, you apparently need to insmod 1541 If ethertap is enabled as a module, you apparently need to insmod
1532 ethertap once for each ethertap device you want to enable. So, 1542 ethertap once for each ethertap device you want to enable. So,
1533 1543
1534 1544
1535 host# 1545 host#
1536 insmod ethertap 1546 insmod ethertap
1537 1547
1538 1548
1539 1549
1540 1550
1541 will give you the tap0 interface. To get the tap1 interface, you need 1551 will give you the tap0 interface. To get the tap1 interface, you need
1542 to run 1552 to run
1543 1553
1544 1554
1545 host# 1555 host#
1546 insmod ethertap unit=1 -o ethertap1 1556 insmod ethertap unit=1 -o ethertap1
1547 1557
1548 1558
1549 1559
1550 1560
1551 1561
1552 1562
1553 1563
1554 66..99.. TThhee sswwiittcchh ddaaeemmoonn 1564 66..99.. TThhee sswwiittcchh ddaaeemmoonn
1555 1565
1556 NNoottee: This is the daemon formerly known as uml_router, but which was 1566 NNoottee: This is the daemon formerly known as uml_router, but which was
1557 renamed so the network weenies of the world would stop growling at me. 1567 renamed so the network weenies of the world would stop growling at me.
1558 1568
1559 1569
1560 The switch daemon, uml_switch, provides a mechanism for creating a 1570 The switch daemon, uml_switch, provides a mechanism for creating a
1561 totally virtual network. By default, it provides no connection to the 1571 totally virtual network. By default, it provides no connection to the
1562 host network (but see -tap, below). 1572 host network (but see -tap, below).
1563 1573
1564 1574
1565 The first thing you need to do is run the daemon. Running it with no 1575 The first thing you need to do is run the daemon. Running it with no
1566 arguments will make it listen on a default pair of unix domain 1576 arguments will make it listen on a default pair of unix domain
1567 sockets. 1577 sockets.
1568 1578
1569 1579
1570 If you want it to listen on a different pair of sockets, use 1580 If you want it to listen on a different pair of sockets, use
1571 1581
1572 1582
1573 -unix control socket data socket 1583 -unix control socket data socket
1574 1584
1575 1585
1576 1586
1577 1587
1578 1588
1579 If you want it to act as a hub rather than a switch, use 1589 If you want it to act as a hub rather than a switch, use
1580 1590
1581 1591
1582 -hub 1592 -hub
1583 1593
1584 1594
1585 1595
1586 1596
1587 1597
1588 If you want the switch to be connected to host networking (allowing 1598 If you want the switch to be connected to host networking (allowing
1589 the umls to get access to the outside world through the host), use 1599 the umls to get access to the outside world through the host), use
1590 1600
1591 1601
1592 -tap tap0 1602 -tap tap0
1593 1603
1594 1604
1595 1605
1596 1606
1597 1607
1598 Note that the tap device must be preconfigured (see "TUN/TAP with a 1608 Note that the tap device must be preconfigured (see "TUN/TAP with a
1599 preconfigured tap device", above). If you're using a different tap 1609 preconfigured tap device", above). If you're using a different tap
1600 device than tap0, specify that instead of tap0. 1610 device than tap0, specify that instead of tap0.
1601 1611
1602 1612
1603 uml_switch can be backgrounded as follows 1613 uml_switch can be backgrounded as follows
1604 1614
1605 1615
1606 host% 1616 host%
1607 uml_switch [ options ] < /dev/null > /dev/null 1617 uml_switch [ options ] < /dev/null > /dev/null
1608 1618
1609 1619
1610 1620
1611 1621
1612 The reason it doesn't background by default is that it listens to 1622 The reason it doesn't background by default is that it listens to
1613 stdin for EOF. When it sees that, it exits. 1623 stdin for EOF. When it sees that, it exits.
1614 1624
1615 1625
1616 The general format of the kernel command line switch is 1626 The general format of the kernel command line switch is
1617 1627
1618 1628
1619 1629
1620 ethn=daemon,ethernet address,socket 1630 ethn=daemon,ethernet address,socket
1621 type,control socket,data socket 1631 type,control socket,data socket
1622 1632
1623 1633
1624 1634
1625 1635
1626 You can leave off everything except the 'daemon'. You only need to 1636 You can leave off everything except the 'daemon'. You only need to
1627 specify the ethernet address if the one that will be assigned to it 1637 specify the ethernet address if the one that will be assigned to it
1628 isn't acceptable for some reason. The rest of the arguments describe 1638 isn't acceptable for some reason. The rest of the arguments describe
1629 how to communicate with the daemon. You should only specify them if 1639 how to communicate with the daemon. You should only specify them if
1630 you told the daemon to use different sockets than the default. So, if 1640 you told the daemon to use different sockets than the default. So, if
1631 you ran the daemon with no arguments, running the UML on the same 1641 you ran the daemon with no arguments, running the UML on the same
1632 machine with 1642 machine with
1633 eth0=daemon 1643 eth0=daemon
1634 1644
1635 1645
1636 1646
1637 1647
1638 will cause the eth0 driver to attach itself to the daemon correctly. 1648 will cause the eth0 driver to attach itself to the daemon correctly.
1639 1649
1640 1650
1641 1651
1642 66..1100.. SSlliipp 1652 66..1100.. SSlliipp
1643 1653
1644 Slip is another, less general, mechanism for a process to communicate 1654 Slip is another, less general, mechanism for a process to communicate
1645 with the host networking. In contrast to the ethertap interface, 1655 with the host networking. In contrast to the ethertap interface,
1646 which exchanges ethernet frames with the host and can be used to 1656 which exchanges ethernet frames with the host and can be used to
1647 transport any higher-level protocol, it can only be used to transport 1657 transport any higher-level protocol, it can only be used to transport
1648 IP. 1658 IP.
1649 1659
1650 1660
1651 The general format of the command line switch is 1661 The general format of the command line switch is
1652 1662
1653 1663
1654 1664
1655 ethn=slip,slip IP 1665 ethn=slip,slip IP
1656 1666
1657 1667
1658 1668
1659 1669
1660 The slip IP argument is the IP address that will be assigned to the 1670 The slip IP argument is the IP address that will be assigned to the
1661 host end of the slip device. If it is specified, the helper will run 1671 host end of the slip device. If it is specified, the helper will run
1662 and will set up the host so that the virtual machine can reach it and 1672 and will set up the host so that the virtual machine can reach it and
1663 the rest of the network. 1673 the rest of the network.
1664 1674
1665 1675
1666 There are some oddities with this interface that you should be aware 1676 There are some oddities with this interface that you should be aware
1667 of. You should only specify one slip device on a given virtual 1677 of. You should only specify one slip device on a given virtual
1668 machine, and its name inside UML will be 'umn', not 'eth0' or whatever 1678 machine, and its name inside UML will be 'umn', not 'eth0' or whatever
1669 you specified on the command line. These problems will be fixed at 1679 you specified on the command line. These problems will be fixed at
1670 some point. 1680 some point.
1671 1681
1672 1682
1673 1683
1674 66..1111.. SSlliirrpp 1684 66..1111.. SSlliirrpp
1675 1685
1676 slirp uses an external program, usually /usr/bin/slirp, to provide IP 1686 slirp uses an external program, usually /usr/bin/slirp, to provide IP
1677 only networking connectivity through the host. This is similar to IP 1687 only networking connectivity through the host. This is similar to IP
1678 masquerading with a firewall, although the translation is performed in 1688 masquerading with a firewall, although the translation is performed in
1679 user-space, rather than by the kernel. As slirp does not set up any 1689 user-space, rather than by the kernel. As slirp does not set up any
1680 interfaces on the host, or changes routing, slirp does not require 1690 interfaces on the host, or changes routing, slirp does not require
1681 root access or setuid binaries on the host. 1691 root access or setuid binaries on the host.
1682 1692
1683 1693
1684 The general format of the command line switch for slirp is: 1694 The general format of the command line switch for slirp is:
1685 1695
1686 1696
1687 1697
1688 ethn=slirp,ethernet address,slirp path 1698 ethn=slirp,ethernet address,slirp path
1689 1699
1690 1700
1691 1701
1692 1702
1693 The ethernet address is optional, as UML will set up the interface 1703 The ethernet address is optional, as UML will set up the interface
1694 with an ethernet address based upon the initial IP address of the 1704 with an ethernet address based upon the initial IP address of the
1695 interface. The slirp path is generally /usr/bin/slirp, although it 1705 interface. The slirp path is generally /usr/bin/slirp, although it
1696 will depend on distribution. 1706 will depend on distribution.
1697 1707
1698 1708
1699 The slirp program can have a number of options passed to the command 1709 The slirp program can have a number of options passed to the command
1700 line and we can't add them to the UML command line, as they will be 1710 line and we can't add them to the UML command line, as they will be
1701 parsed incorrectly. Instead, a wrapper shell script can be written or 1711 parsed incorrectly. Instead, a wrapper shell script can be written or
1702 the options inserted into the /.slirprc file. More information on 1712 the options inserted into the /.slirprc file. More information on
1703 all of the slirp options can be found in its man pages. 1713 all of the slirp options can be found in its man pages.
1704 1714
1705 1715
1706 The eth0 interface on UML should be set up with the IP 10.2.0.15, 1716 The eth0 interface on UML should be set up with the IP 10.2.0.15,
1707 although you can use anything as long as it is not used by a network 1717 although you can use anything as long as it is not used by a network
1708 you will be connecting to. The default route on UML should be set to 1718 you will be connecting to. The default route on UML should be set to
1709 use 1719 use
1710 1720
1711 1721
1712 UML# 1722 UML#
1713 route add default dev eth0 1723 route add default dev eth0
1714 1724
1715 1725
1716 1726
1717 1727
1718 slirp provides a number of useful IP addresses which can be used by 1728 slirp provides a number of useful IP addresses which can be used by
1719 UML, such as 10.0.2.3 which is an alias for the DNS server specified 1729 UML, such as 10.0.2.3 which is an alias for the DNS server specified
1720 in /etc/resolv.conf on the host or the IP given in the 'dns' option 1730 in /etc/resolv.conf on the host or the IP given in the 'dns' option
1721 for slirp. 1731 for slirp.
1722 1732
1723 1733
1724 Even with a baudrate setting higher than 115200, the slirp connection 1734 Even with a baudrate setting higher than 115200, the slirp connection
1725 is limited to 115200. If you need it to go faster, the slirp binary 1735 is limited to 115200. If you need it to go faster, the slirp binary
1726 needs to be compiled with FULL_BOLT defined in config.h. 1736 needs to be compiled with FULL_BOLT defined in config.h.
1727 1737
1728 1738
1729 1739
1730 66..1122.. ppccaapp 1740 66..1122.. ppccaapp
1731 1741
1732 The pcap transport is attached to a UML ethernet device on the command 1742 The pcap transport is attached to a UML ethernet device on the command
1733 line or with uml_mconsole with the following syntax: 1743 line or with uml_mconsole with the following syntax:
1734 1744
1735 1745
1736 1746
1737 ethn=pcap,host interface,filter 1747 ethn=pcap,host interface,filter
1738 expression,option1,option2 1748 expression,option1,option2
1739 1749
1740 1750
1741 1751
1742 1752
1743 The expression and options are optional. 1753 The expression and options are optional.
1744 1754
1745 1755
1746 The interface is whatever network device on the host you want to 1756 The interface is whatever network device on the host you want to
1747 sniff. The expression is a pcap filter expression, which is also what 1757 sniff. The expression is a pcap filter expression, which is also what
1748 tcpdump uses, so if you know how to specify tcpdump filters, you will 1758 tcpdump uses, so if you know how to specify tcpdump filters, you will
1749 use the same expressions here. The options are up to two of 1759 use the same expressions here. The options are up to two of
1750 'promisc', control whether pcap puts the host interface into 1760 'promisc', control whether pcap puts the host interface into
1751 promiscuous mode. 'optimize' and 'nooptimize' control whether the pcap 1761 promiscuous mode. 'optimize' and 'nooptimize' control whether the pcap
1752 expression optimizer is used. 1762 expression optimizer is used.
1753 1763
1754 1764
1755 Example: 1765 Example:
1756 1766
1757 1767
1758 1768
1759 eth0=pcap,eth0,tcp 1769 eth0=pcap,eth0,tcp
1760 1770
1761 eth1=pcap,eth0,!tcp 1771 eth1=pcap,eth0,!tcp
1762 1772
1763 1773
1764 1774
1765 will cause the UML eth0 to emit all tcp packets on the host eth0 and 1775 will cause the UML eth0 to emit all tcp packets on the host eth0 and
1766 the UML eth1 to emit all non-tcp packets on the host eth0. 1776 the UML eth1 to emit all non-tcp packets on the host eth0.
1767 1777
1768 1778
1769 1779
1770 66..1133.. SSeettttiinngg uupp tthhee hhoosstt yyoouurrsseellff 1780 66..1133.. SSeettttiinngg uupp tthhee hhoosstt yyoouurrsseellff
1771 1781
1772 If you don't specify an address for the host side of the ethertap or 1782 If you don't specify an address for the host side of the ethertap or
1773 slip device, UML won't do any setup on the host. So this is what is 1783 slip device, UML won't do any setup on the host. So this is what is
1774 needed to get things working (the examples use a host-side IP of 1784 needed to get things working (the examples use a host-side IP of
1775 192.168.0.251 and a UML-side IP of 192.168.0.250 - adjust to suit your 1785 192.168.0.251 and a UML-side IP of 192.168.0.250 - adjust to suit your
1776 own network): 1786 own network):
1777 1787
1778 +o The device needs to be configured with its IP address. Tap devices 1788 +o The device needs to be configured with its IP address. Tap devices
1779 are also configured with an mtu of 1484. Slip devices are 1789 are also configured with an mtu of 1484. Slip devices are
1780 configured with a point-to-point address pointing at the UML ip 1790 configured with a point-to-point address pointing at the UML ip
1781 address. 1791 address.
1782 1792
1783 1793
1784 host# ifconfig tap0 arp mtu 1484 192.168.0.251 up 1794 host# ifconfig tap0 arp mtu 1484 192.168.0.251 up
1785 1795
1786 1796
1787 1797
1788 1798
1789 1799
1790 1800
1791 host# 1801 host#
1792 ifconfig sl0 192.168.0.251 pointopoint 192.168.0.250 up 1802 ifconfig sl0 192.168.0.251 pointopoint 192.168.0.250 up
1793 1803
1794 1804
1795 1805
1796 1806
1797 1807
1798 +o If a tap device is being set up, a route is set to the UML IP. 1808 +o If a tap device is being set up, a route is set to the UML IP.
1799 1809
1800 1810
1801 UML# route add -host 192.168.0.250 gw 192.168.0.251 1811 UML# route add -host 192.168.0.250 gw 192.168.0.251
1802 1812
1803 1813
1804 1814
1805 1815
1806 1816
1807 +o To allow other hosts on your network to see the virtual machine, 1817 +o To allow other hosts on your network to see the virtual machine,
1808 proxy arp is set up for it. 1818 proxy arp is set up for it.
1809 1819
1810 1820
1811 host# arp -Ds 192.168.0.250 eth0 pub 1821 host# arp -Ds 192.168.0.250 eth0 pub
1812 1822
1813 1823
1814 1824
1815 1825
1816 1826
1817 +o Finally, the host is set up to route packets. 1827 +o Finally, the host is set up to route packets.
1818 1828
1819 1829
1820 host# echo 1 > /proc/sys/net/ipv4/ip_forward 1830 host# echo 1 > /proc/sys/net/ipv4/ip_forward
1821 1831
1822 1832
1823 1833
1824 1834
1825 1835
1826 1836
1827 1837
1828 1838
1829 1839
1830 1840
1831 77.. SShhaarriinngg FFiilleessyysstteemmss bbeettwweeeenn VViirrttuuaall MMaacchhiinneess 1841 77.. SShhaarriinngg FFiilleessyysstteemmss bbeettwweeeenn VViirrttuuaall MMaacchhiinneess
1832 1842
1833 1843
1834 1844
1835 1845
1836 77..11.. AA wwaarrnniinngg 1846 77..11.. AA wwaarrnniinngg
1837 1847
1838 Don't attempt to share filesystems simply by booting two UMLs from the 1848 Don't attempt to share filesystems simply by booting two UMLs from the
1839 same file. That's the same thing as booting two physical machines 1849 same file. That's the same thing as booting two physical machines
1840 from a shared disk. It will result in filesystem corruption. 1850 from a shared disk. It will result in filesystem corruption.
1841 1851
1842 1852
1843 1853
1844 77..22.. UUssiinngg llaayyeerreedd bblloocckk ddeevviicceess 1854 77..22.. UUssiinngg llaayyeerreedd bblloocckk ddeevviicceess
1845 1855
1846 The way to share a filesystem between two virtual machines is to use 1856 The way to share a filesystem between two virtual machines is to use
1847 the copy-on-write (COW) layering capability of the ubd block driver. 1857 the copy-on-write (COW) layering capability of the ubd block driver.
1848 As of 2.4.6-2um, the driver supports layering a read-write private 1858 As of 2.4.6-2um, the driver supports layering a read-write private
1849 device over a read-only shared device. A machine's writes are stored 1859 device over a read-only shared device. A machine's writes are stored
1850 in the private device, while reads come from either device - the 1860 in the private device, while reads come from either device - the
1851 private one if the requested block is valid in it, the shared one if 1861 private one if the requested block is valid in it, the shared one if
1852 not. Using this scheme, the majority of data which is unchanged is 1862 not. Using this scheme, the majority of data which is unchanged is
1853 shared between an arbitrary number of virtual machines, each of which 1863 shared between an arbitrary number of virtual machines, each of which
1854 has a much smaller file containing the changes that it has made. With 1864 has a much smaller file containing the changes that it has made. With
1855 a large number of UMLs booting from a large root filesystem, this 1865 a large number of UMLs booting from a large root filesystem, this
1856 leads to a huge disk space saving. It will also help performance, 1866 leads to a huge disk space saving. It will also help performance,
1857 since the host will be able to cache the shared data using a much 1867 since the host will be able to cache the shared data using a much
1858 smaller amount of memory, so UML disk requests will be served from the 1868 smaller amount of memory, so UML disk requests will be served from the
1859 host's memory rather than its disks. 1869 host's memory rather than its disks.
1860 1870
1861 1871
1862 1872
1863 1873
1864 To add a copy-on-write layer to an existing block device file, simply 1874 To add a copy-on-write layer to an existing block device file, simply
1865 add the name of the COW file to the appropriate ubd switch: 1875 add the name of the COW file to the appropriate ubd switch:
1866 1876
1867 1877
1868 ubd0=root_fs_cow,root_fs_debian_22 1878 ubd0=root_fs_cow,root_fs_debian_22
1869 1879
1870 1880
1871 1881
1872 1882
1873 where 'root_fs_cow' is the private COW file and 'root_fs_debian_22' is 1883 where 'root_fs_cow' is the private COW file and 'root_fs_debian_22' is
1874 the existing shared filesystem. The COW file need not exist. If it 1884 the existing shared filesystem. The COW file need not exist. If it
1875 doesn't, the driver will create and initialize it. Once the COW file 1885 doesn't, the driver will create and initialize it. Once the COW file
1876 has been initialized, it can be used on its own on the command line: 1886 has been initialized, it can be used on its own on the command line:
1877 1887
1878 1888
1879 ubd0=root_fs_cow 1889 ubd0=root_fs_cow
1880 1890
1881 1891
1882 1892
1883 1893
1884 The name of the backing file is stored in the COW file header, so it 1894 The name of the backing file is stored in the COW file header, so it
1885 would be redundant to continue specifying it on the command line. 1895 would be redundant to continue specifying it on the command line.
1886 1896
1887 1897
1888 1898
1889 77..33.. NNoottee!! 1899 77..33.. NNoottee!!
1890 1900
1891 When checking the size of the COW file in order to see the gobs of 1901 When checking the size of the COW file in order to see the gobs of
1892 space that you're saving, make sure you use 'ls -ls' to see the actual 1902 space that you're saving, make sure you use 'ls -ls' to see the actual
1893 disk consumption rather than the length of the file. The COW file is 1903 disk consumption rather than the length of the file. The COW file is
1894 sparse, so the length will be very different from the disk usage. 1904 sparse, so the length will be very different from the disk usage.
1895 Here is a 'ls -l' of a COW file and backing file from one boot and 1905 Here is a 'ls -l' of a COW file and backing file from one boot and
1896 shutdown: 1906 shutdown:
1897 host% ls -l cow.debian debian2.2 1907 host% ls -l cow.debian debian2.2
1898 -rw-r--r-- 1 jdike jdike 492504064 Aug 6 21:16 cow.debian 1908 -rw-r--r-- 1 jdike jdike 492504064 Aug 6 21:16 cow.debian
1899 -rwxrw-rw- 1 jdike jdike 537919488 Aug 6 20:42 debian2.2 1909 -rwxrw-rw- 1 jdike jdike 537919488 Aug 6 20:42 debian2.2
1900 1910
1901 1911
1902 1912
1903 1913
1904 Doesn't look like much saved space, does it? Well, here's 'ls -ls': 1914 Doesn't look like much saved space, does it? Well, here's 'ls -ls':
1905 1915
1906 1916
1907 host% ls -ls cow.debian debian2.2 1917 host% ls -ls cow.debian debian2.2
1908 880 -rw-r--r-- 1 jdike jdike 492504064 Aug 6 21:16 cow.debian 1918 880 -rw-r--r-- 1 jdike jdike 492504064 Aug 6 21:16 cow.debian
1909 525832 -rwxrw-rw- 1 jdike jdike 537919488 Aug 6 20:42 debian2.2 1919 525832 -rwxrw-rw- 1 jdike jdike 537919488 Aug 6 20:42 debian2.2
1910 1920
1911 1921
1912 1922
1913 1923
1914 Now, you can see that the COW file has less than a meg of disk, rather 1924 Now, you can see that the COW file has less than a meg of disk, rather
1915 than 492 meg. 1925 than 492 meg.
1916 1926
1917 1927
1918 1928
1919 77..44.. AAnnootthheerr wwaarrnniinngg 1929 77..44.. AAnnootthheerr wwaarrnniinngg
1920 1930
1921 Once a filesystem is being used as a readonly backing file for a COW 1931 Once a filesystem is being used as a readonly backing file for a COW
1922 file, do not boot directly from it or modify it in any way. Doing so 1932 file, do not boot directly from it or modify it in any way. Doing so
1923 will invalidate any COW files that are using it. The mtime and size 1933 will invalidate any COW files that are using it. The mtime and size
1924 of the backing file are stored in the COW file header at its creation, 1934 of the backing file are stored in the COW file header at its creation,
1925 and they must continue to match. If they don't, the driver will 1935 and they must continue to match. If they don't, the driver will
1926 refuse to use the COW file. 1936 refuse to use the COW file.
1927 1937
1928 1938
1929 1939
1930 1940
1931 If you attempt to evade this restriction by changing either the 1941 If you attempt to evade this restriction by changing either the
1932 backing file or the COW header by hand, you will get a corrupted 1942 backing file or the COW header by hand, you will get a corrupted
1933 filesystem. 1943 filesystem.
1934 1944
1935 1945
1936 1946
1937 1947
1938 Among other things, this means that upgrading the distribution in a 1948 Among other things, this means that upgrading the distribution in a
1939 backing file and expecting that all of the COW files using it will see 1949 backing file and expecting that all of the COW files using it will see
1940 the upgrade will not work. 1950 the upgrade will not work.
1941 1951
1942 1952
1943 1953
1944 1954
1945 77..55.. uummll__mmoooo :: MMeerrggiinngg aa CCOOWW ffiillee wwiitthh iittss bbaacckkiinngg ffiillee 1955 77..55.. uummll__mmoooo :: MMeerrggiinngg aa CCOOWW ffiillee wwiitthh iittss bbaacckkiinngg ffiillee
1946 1956
1947 Depending on how you use UML and COW devices, it may be advisable to 1957 Depending on how you use UML and COW devices, it may be advisable to
1948 merge the changes in the COW file into the backing file every once in 1958 merge the changes in the COW file into the backing file every once in
1949 a while. 1959 a while.
1950 1960
1951 1961
1952 1962
1953 1963
1954 The utility that does this is uml_moo. Its usage is 1964 The utility that does this is uml_moo. Its usage is
1955 1965
1956 1966
1957 host% uml_moo COW file new backing file 1967 host% uml_moo COW file new backing file
1958 1968
1959 1969
1960 1970
1961 1971
1962 There's no need to specify the backing file since that information is 1972 There's no need to specify the backing file since that information is
1963 already in the COW file header. If you're paranoid, boot the new 1973 already in the COW file header. If you're paranoid, boot the new
1964 merged file, and if you're happy with it, move it over the old backing 1974 merged file, and if you're happy with it, move it over the old backing
1965 file. 1975 file.
1966 1976
1967 1977
1968 1978
1969 1979
1970 uml_moo creates a new backing file by default as a safety measure. It 1980 uml_moo creates a new backing file by default as a safety measure. It
1971 also has a destructive merge option which will merge the COW file 1981 also has a destructive merge option which will merge the COW file
1972 directly into its current backing file. This is really only usable 1982 directly into its current backing file. This is really only usable
1973 when the backing file only has one COW file associated with it. If 1983 when the backing file only has one COW file associated with it. If
1974 there are multiple COWs associated with a backing file, a -d merge of 1984 there are multiple COWs associated with a backing file, a -d merge of
1975 one of them will invalidate all of the others. However, it is 1985 one of them will invalidate all of the others. However, it is
1976 convenient if you're short of disk space, and it should also be 1986 convenient if you're short of disk space, and it should also be
1977 noticeably faster than a non-destructive merge. 1987 noticeably faster than a non-destructive merge.
1978 1988
1979 1989
1980 1990
1981 1991
1982 uml_moo is installed with the UML deb and RPM. If you didn't install 1992 uml_moo is installed with the UML deb and RPM. If you didn't install
1983 UML from one of those packages, you can also get it from the UML 1993 UML from one of those packages, you can also get it from the UML
1984 utilities <http://user-mode-linux.sourceforge.net/ 1994 utilities <http://user-mode-linux.sourceforge.net/
1985 utilities> tar file in tools/moo. 1995 utilities> tar file in tools/moo.
1986 1996
1987 1997
1988 1998
1989 1999
1990 2000
1991 2001
1992 2002
1993 2003
1994 88.. CCrreeaattiinngg ffiilleessyysstteemmss 2004 88.. CCrreeaattiinngg ffiilleessyysstteemmss
1995 2005
1996 2006
1997 You may want to create and mount new UML filesystems, either because 2007 You may want to create and mount new UML filesystems, either because
1998 your root filesystem isn't large enough or because you want to use a 2008 your root filesystem isn't large enough or because you want to use a
1999 filesystem other than ext2. 2009 filesystem other than ext2.
2000 2010
2001 2011
2002 This was written on the occasion of reiserfs being included in the 2012 This was written on the occasion of reiserfs being included in the
2003 2.4.1 kernel pool, and therefore the 2.4.1 UML, so the examples will 2013 2.4.1 kernel pool, and therefore the 2.4.1 UML, so the examples will
2004 talk about reiserfs. This information is generic, and the examples 2014 talk about reiserfs. This information is generic, and the examples
2005 should be easy to translate to the filesystem of your choice. 2015 should be easy to translate to the filesystem of your choice.
2006 2016
2007 2017
2008 88..11.. CCrreeaattee tthhee ffiilleessyysstteemm ffiillee 2018 88..11.. CCrreeaattee tthhee ffiilleessyysstteemm ffiillee
2009 2019
2010 dd is your friend. All you need to do is tell dd to create an empty 2020 dd is your friend. All you need to do is tell dd to create an empty
2011 file of the appropriate size. I usually make it sparse to save time 2021 file of the appropriate size. I usually make it sparse to save time
2012 and to avoid allocating disk space until it's actually used. For 2022 and to avoid allocating disk space until it's actually used. For
2013 example, the following command will create a sparse 100 meg file full 2023 example, the following command will create a sparse 100 meg file full
2014 of zeroes. 2024 of zeroes.
2015 2025
2016 2026
2017 host% 2027 host%
2018 dd if=/dev/zero of=new_filesystem seek=100 count=1 bs=1M 2028 dd if=/dev/zero of=new_filesystem seek=100 count=1 bs=1M
2019 2029
2020 2030
2021 2031
2022 2032
2023 2033
2024 2034
2025 88..22.. AAssssiiggnn tthhee ffiillee ttoo aa UUMMLL ddeevviiccee 2035 88..22.. AAssssiiggnn tthhee ffiillee ttoo aa UUMMLL ddeevviiccee
2026 2036
2027 Add an argument like the following to the UML command line: 2037 Add an argument like the following to the UML command line:
2028 2038
2029 ubd4=new_filesystem 2039 ubd4=new_filesystem
2030 2040
2031 2041
2032 2042
2033 2043
2034 making sure that you use an unassigned ubd device number. 2044 making sure that you use an unassigned ubd device number.
2035 2045
2036 2046
2037 2047
2038 88..33.. CCrreeaattiinngg aanndd mmoouunnttiinngg tthhee ffiilleessyysstteemm 2048 88..33.. CCrreeaattiinngg aanndd mmoouunnttiinngg tthhee ffiilleessyysstteemm
2039 2049
2040 Make sure that the filesystem is available, either by being built into 2050 Make sure that the filesystem is available, either by being built into
2041 the kernel, or available as a module, then boot up UML and log in. If 2051 the kernel, or available as a module, then boot up UML and log in. If
2042 the root filesystem doesn't have the filesystem utilities (mkfs, fsck, 2052 the root filesystem doesn't have the filesystem utilities (mkfs, fsck,
2043 etc), then get them into UML by way of the net or hostfs. 2053 etc), then get them into UML by way of the net or hostfs.
2044 2054
2045 2055
2046 Make the new filesystem on the device assigned to the new file: 2056 Make the new filesystem on the device assigned to the new file:
2047 2057
2048 2058
2049 host# mkreiserfs /dev/ubd/4 2059 host# mkreiserfs /dev/ubd/4
2050 2060
2051 2061
2052 <----------- MKREISERFSv2 -----------> 2062 <----------- MKREISERFSv2 ----------->
2053 2063
2054 ReiserFS version 3.6.25 2064 ReiserFS version 3.6.25
2055 Block size 4096 bytes 2065 Block size 4096 bytes
2056 Block count 25856 2066 Block count 25856
2057 Used blocks 8212 2067 Used blocks 8212
2058 Journal - 8192 blocks (18-8209), journal header is in block 8210 2068 Journal - 8192 blocks (18-8209), journal header is in block 8210
2059 Bitmaps: 17 2069 Bitmaps: 17
2060 Root block 8211 2070 Root block 8211
2061 Hash function "r5" 2071 Hash function "r5"
2062 ATTENTION: ALL DATA WILL BE LOST ON '/dev/ubd/4'! (y/n)y 2072 ATTENTION: ALL DATA WILL BE LOST ON '/dev/ubd/4'! (y/n)y
2063 journal size 8192 (from 18) 2073 journal size 8192 (from 18)
2064 Initializing journal - 0%....20%....40%....60%....80%....100% 2074 Initializing journal - 0%....20%....40%....60%....80%....100%
2065 Syncing..done. 2075 Syncing..done.
2066 2076
2067 2077
2068 2078
2069 2079
2070 Now, mount it: 2080 Now, mount it:
2071 2081
2072 2082
2073 UML# 2083 UML#
2074 mount /dev/ubd/4 /mnt 2084 mount /dev/ubd/4 /mnt
2075 2085
2076 2086
2077 2087
2078 2088
2079 and you're in business. 2089 and you're in business.
2080 2090
2081 2091
2082 2092
2083 2093
2084 2094
2085 2095
2086 2096
2087 2097
2088 2098
2089 99.. HHoosstt ffiillee aacccceessss 2099 99.. HHoosstt ffiillee aacccceessss
2090 2100
2091 2101
2092 If you want to access files on the host machine from inside UML, you 2102 If you want to access files on the host machine from inside UML, you
2093 can treat it as a separate machine and either nfs mount directories 2103 can treat it as a separate machine and either nfs mount directories
2094 from the host or copy files into the virtual machine with scp or rcp. 2104 from the host or copy files into the virtual machine with scp or rcp.
2095 However, since UML is running on the host, it can access those 2105 However, since UML is running on the host, it can access those
2096 files just like any other process and make them available inside the 2106 files just like any other process and make them available inside the
2097 virtual machine without needing to use the network. 2107 virtual machine without needing to use the network.
2098 2108
2099 2109
2100 This is now possible with the hostfs virtual filesystem. With it, you 2110 This is now possible with the hostfs virtual filesystem. With it, you
2101 can mount a host directory into the UML filesystem and access the 2111 can mount a host directory into the UML filesystem and access the
2102 files contained in it just as you would on the host. 2112 files contained in it just as you would on the host.
2103 2113
2104 2114
2105 99..11.. UUssiinngg hhoossttffss 2115 99..11.. UUssiinngg hhoossttffss
2106 2116
2107 To begin with, make sure that hostfs is available inside the virtual 2117 To begin with, make sure that hostfs is available inside the virtual
2108 machine with 2118 machine with
2109 2119
2110 2120
2111 UML# cat /proc/filesystems 2121 UML# cat /proc/filesystems
2112 2122
2113 2123
2114 2124
2115 . hostfs should be listed. If it's not, either rebuild the kernel 2125 . hostfs should be listed. If it's not, either rebuild the kernel
2116 with hostfs configured into it or make sure that hostfs is built as a 2126 with hostfs configured into it or make sure that hostfs is built as a
2117 module and available inside the virtual machine, and insmod it. 2127 module and available inside the virtual machine, and insmod it.
2118 2128
2119 2129
2120 Now all you need to do is run mount: 2130 Now all you need to do is run mount:
2121 2131
2122 2132
2123 UML# mount none /mnt/host -t hostfs 2133 UML# mount none /mnt/host -t hostfs
2124 2134
2125 2135
2126 2136
2127 2137
2128 will mount the host's / on the virtual machine's /mnt/host. 2138 will mount the host's / on the virtual machine's /mnt/host.
2129 2139
2130 2140
2131 If you don't want to mount the host root directory, then you can 2141 If you don't want to mount the host root directory, then you can
2132 specify a subdirectory to mount with the -o switch to mount: 2142 specify a subdirectory to mount with the -o switch to mount:
2133 2143
2134 2144
2135 UML# mount none /mnt/home -t hostfs -o /home 2145 UML# mount none /mnt/home -t hostfs -o /home
2136 2146
2137 2147
2138 2148
2139 2149
2140 will mount the hosts's /home on the virtual machine's /mnt/home. 2150 will mount the hosts's /home on the virtual machine's /mnt/home.
2141 2151
2142 2152
2143 2153
2144 99..22.. hhoossttffss aass tthhee rroooott ffiilleessyysstteemm 2154 99..22.. hhoossttffss aass tthhee rroooott ffiilleessyysstteemm
2145 2155
2146 It's possible to boot from a directory hierarchy on the host using 2156 It's possible to boot from a directory hierarchy on the host using
2147 hostfs rather than using the standard filesystem in a file. 2157 hostfs rather than using the standard filesystem in a file.
2148 2158
2149 To start, you need that hierarchy. The easiest way is to loop mount 2159 To start, you need that hierarchy. The easiest way is to loop mount
2150 an existing root_fs file: 2160 an existing root_fs file:
2151 2161
2152 2162
2153 host# mount root_fs uml_root_dir -o loop 2163 host# mount root_fs uml_root_dir -o loop
2154 2164
2155 2165
2156 2166
2157 2167
2158 You need to change the filesystem type of / in etc/fstab to be 2168 You need to change the filesystem type of / in etc/fstab to be
2159 'hostfs', so that line looks like this: 2169 'hostfs', so that line looks like this:
2160 2170
2161 /dev/ubd/0 / hostfs defaults 1 1 2171 /dev/ubd/0 / hostfs defaults 1 1
2162 2172
2163 2173
2164 2174
2165 2175
2166 Then you need to chown to yourself all the files in that directory 2176 Then you need to chown to yourself all the files in that directory
2167 that are owned by root. This worked for me: 2177 that are owned by root. This worked for me:
2168 2178
2169 2179
2170 host# find . -uid 0 -exec chown jdike {} \; 2180 host# find . -uid 0 -exec chown jdike {} \;
2171 2181
2172 2182
2173 2183
2174 2184
2175 Next, make sure that your UML kernel has hostfs compiled in, not as a 2185 Next, make sure that your UML kernel has hostfs compiled in, not as a
2176 module. Then run UML with the boot device pointing at that directory: 2186 module. Then run UML with the boot device pointing at that directory:
2177 2187
2178 2188
2179 ubd0=/path/to/uml/root/directory 2189 ubd0=/path/to/uml/root/directory
2180 2190
2181 2191
2182 2192
2183 2193
2184 UML should then boot as it does normally. 2194 UML should then boot as it does normally.
2185 2195
2186 2196
2187 99..33.. BBuuiillddiinngg hhoossttffss 2197 99..33.. BBuuiillddiinngg hhoossttffss
2188 2198
2189 If you need to build hostfs because it's not in your kernel, you have 2199 If you need to build hostfs because it's not in your kernel, you have
2190 two choices: 2200 two choices:
2191 2201
2192 2202
2193 2203
2194 +o Compiling hostfs into the kernel: 2204 +o Compiling hostfs into the kernel:
2195 2205
2196 2206
2197 Reconfigure the kernel and set the 'Host filesystem' option under 2207 Reconfigure the kernel and set the 'Host filesystem' option under
2198 2208
2199 2209
2200 +o Compiling hostfs as a module: 2210 +o Compiling hostfs as a module:
2201 2211
2202 2212
2203 Reconfigure the kernel and set the 'Host filesystem' option under 2213 Reconfigure the kernel and set the 'Host filesystem' option under
2204 be in arch/um/fs/hostfs/hostfs.o. Install that in 2214 be in arch/um/fs/hostfs/hostfs.o. Install that in
2205 /lib/modules/`uname -r`/fs in the virtual machine, boot it up, and 2215 /lib/modules/`uname -r`/fs in the virtual machine, boot it up, and
2206 2216
2207 2217
2208 UML# insmod hostfs 2218 UML# insmod hostfs
2209 2219
2210 2220
2211 2221
2212 2222
2213 2223
2214 2224
2215 2225
2216 2226
2217 2227
2218 2228
2219 2229
2220 2230
2221 1100.. TThhee MMaannaaggeemmeenntt CCoonnssoollee 2231 1100.. TThhee MMaannaaggeemmeenntt CCoonnssoollee
2222 2232
2223 2233
2224 2234
2225 The UML management console is a low-level interface to the kernel, 2235 The UML management console is a low-level interface to the kernel,
2226 somewhat like the i386 SysRq interface. Since there is a full-blown 2236 somewhat like the i386 SysRq interface. Since there is a full-blown
2227 operating system under UML, there is much greater flexibility possible 2237 operating system under UML, there is much greater flexibility possible
2228 than with the SysRq mechanism. 2238 than with the SysRq mechanism.
2229 2239
2230 2240
2231 There are a number of things you can do with the mconsole interface: 2241 There are a number of things you can do with the mconsole interface:
2232 2242
2233 +o get the kernel version 2243 +o get the kernel version
2234 2244
2235 +o add and remove devices 2245 +o add and remove devices
2236 2246
2237 +o halt or reboot the machine 2247 +o halt or reboot the machine
2238 2248
2239 +o Send SysRq commands 2249 +o Send SysRq commands
2240 2250
2241 +o Pause and resume the UML 2251 +o Pause and resume the UML
2242 2252
2243 2253
2244 You need the mconsole client (uml_mconsole) which is present in CVS 2254 You need the mconsole client (uml_mconsole) which is present in CVS
2245 (/tools/mconsole) in 2.4.5-9um and later, and will be in the RPM in 2255 (/tools/mconsole) in 2.4.5-9um and later, and will be in the RPM in
2246 2.4.6. 2256 2.4.6.
2247 2257
2248 2258
2249 You also need CONFIG_MCONSOLE (under 'General Setup') enabled in UML. 2259 You also need CONFIG_MCONSOLE (under 'General Setup') enabled in UML.
2250 When you boot UML, you'll see a line like: 2260 When you boot UML, you'll see a line like:
2251 2261
2252 2262
2253 mconsole initialized on /home/jdike/.uml/umlNJ32yL/mconsole 2263 mconsole initialized on /home/jdike/.uml/umlNJ32yL/mconsole
2254 2264
2255 2265
2256 2266
2257 2267
2258 If you specify a unique machine id one the UML command line, i.e. 2268 If you specify a unique machine id one the UML command line, i.e.
2259 2269
2260 2270
2261 umid=debian 2271 umid=debian
2262 2272
2263 2273
2264 2274
2265 2275
2266 you'll see this 2276 you'll see this
2267 2277
2268 2278
2269 mconsole initialized on /home/jdike/.uml/debian/mconsole 2279 mconsole initialized on /home/jdike/.uml/debian/mconsole
2270 2280
2271 2281
2272 2282
2273 2283
2274 That file is the socket that uml_mconsole will use to communicate with 2284 That file is the socket that uml_mconsole will use to communicate with
2275 UML. Run it with either the umid or the full path as its argument: 2285 UML. Run it with either the umid or the full path as its argument:
2276 2286
2277 2287
2278 host% uml_mconsole debian 2288 host% uml_mconsole debian
2279 2289
2280 2290
2281 2291
2282 2292
2283 or 2293 or
2284 2294
2285 2295
2286 host% uml_mconsole /home/jdike/.uml/debian/mconsole 2296 host% uml_mconsole /home/jdike/.uml/debian/mconsole
2287 2297
2288 2298
2289 2299
2290 2300
2291 You'll get a prompt, at which you can run one of these commands: 2301 You'll get a prompt, at which you can run one of these commands:
2292 2302
2293 +o version 2303 +o version
2294 2304
2295 +o halt 2305 +o halt
2296 2306
2297 +o reboot 2307 +o reboot
2298 2308
2299 +o config 2309 +o config
2300 2310
2301 +o remove 2311 +o remove
2302 2312
2303 +o sysrq 2313 +o sysrq
2304 2314
2305 +o help 2315 +o help
2306 2316
2307 +o cad 2317 +o cad
2308 2318
2309 +o stop 2319 +o stop
2310 2320
2311 +o go 2321 +o go
2312 2322
2313 2323
2314 1100..11.. vveerrssiioonn 2324 1100..11.. vveerrssiioonn
2315 2325
2316 This takes no arguments. It prints the UML version. 2326 This takes no arguments. It prints the UML version.
2317 2327
2318 2328
2319 (mconsole) version 2329 (mconsole) version
2320 OK Linux usermode 2.4.5-9um #1 Wed Jun 20 22:47:08 EDT 2001 i686 2330 OK Linux usermode 2.4.5-9um #1 Wed Jun 20 22:47:08 EDT 2001 i686
2321 2331
2322 2332
2323 2333
2324 2334
2325 There are a couple actual uses for this. It's a simple no-op which 2335 There are a couple actual uses for this. It's a simple no-op which
2326 can be used to check that a UML is running. It's also a way of 2336 can be used to check that a UML is running. It's also a way of
2327 sending an interrupt to the UML. This is sometimes useful on SMP 2337 sending an interrupt to the UML. This is sometimes useful on SMP
2328 hosts, where there's a bug which causes signals to UML to be lost, 2338 hosts, where there's a bug which causes signals to UML to be lost,
2329 often causing it to appear to hang. Sending such a UML the mconsole 2339 often causing it to appear to hang. Sending such a UML the mconsole
2330 version command is a good way to 'wake it up' before networking has 2340 version command is a good way to 'wake it up' before networking has
2331 been enabled, as it does not do anything to the function of the UML. 2341 been enabled, as it does not do anything to the function of the UML.
2332 2342
2333 2343
2334 2344
2335 1100..22.. hhaalltt aanndd rreebboooott 2345 1100..22.. hhaalltt aanndd rreebboooott
2336 2346
2337 These take no arguments. They shut the machine down immediately, with 2347 These take no arguments. They shut the machine down immediately, with
2338 no syncing of disks and no clean shutdown of userspace. So, they are 2348 no syncing of disks and no clean shutdown of userspace. So, they are
2339 pretty close to crashing the machine. 2349 pretty close to crashing the machine.
2340 2350
2341 2351
2342 (mconsole) halt 2352 (mconsole) halt
2343 OK 2353 OK
2344 2354
2345 2355
2346 2356
2347 2357
2348 2358
2349 2359
2350 1100..33.. ccoonnffiigg 2360 1100..33.. ccoonnffiigg
2351 2361
2352 "config" adds a new device to the virtual machine. Currently the ubd 2362 "config" adds a new device to the virtual machine. Currently the ubd
2353 and network drivers support this. It takes one argument, which is the 2363 and network drivers support this. It takes one argument, which is the
2354 device to add, with the same syntax as the kernel command line. 2364 device to add, with the same syntax as the kernel command line.
2355 2365
2356 2366
2357 2367
2358 2368
2359 (mconsole) 2369 (mconsole)
2360 config ubd3=/home/jdike/incoming/roots/root_fs_debian22 2370 config ubd3=/home/jdike/incoming/roots/root_fs_debian22
2361 2371
2362 OK 2372 OK
2363 (mconsole) config eth1=mcast 2373 (mconsole) config eth1=mcast
2364 OK 2374 OK
2365 2375
2366 2376
2367 2377
2368 2378
2369 2379
2370 2380
2371 1100..44.. rreemmoovvee 2381 1100..44.. rreemmoovvee
2372 2382
2373 "remove" deletes a device from the system. Its argument is just the 2383 "remove" deletes a device from the system. Its argument is just the
2374 name of the device to be removed. The device must be idle in whatever 2384 name of the device to be removed. The device must be idle in whatever
2375 sense the driver considers necessary. In the case of the ubd driver, 2385 sense the driver considers necessary. In the case of the ubd driver,
2376 the removed block device must not be mounted, swapped on, or otherwise 2386 the removed block device must not be mounted, swapped on, or otherwise
2377 open, and in the case of the network driver, the device must be down. 2387 open, and in the case of the network driver, the device must be down.
2378 2388
2379 2389
2380 (mconsole) remove ubd3 2390 (mconsole) remove ubd3
2381 OK 2391 OK
2382 (mconsole) remove eth1 2392 (mconsole) remove eth1
2383 OK 2393 OK
2384 2394
2385 2395
2386 2396
2387 2397
2388 2398
2389 2399
2390 1100..55.. ssyyssrrqq 2400 1100..55.. ssyyssrrqq
2391 2401
2392 This takes one argument, which is a single letter. It calls the 2402 This takes one argument, which is a single letter. It calls the
2393 generic kernel's SysRq driver, which does whatever is called for by 2403 generic kernel's SysRq driver, which does whatever is called for by
2394 that argument. See the SysRq documentation in Documentation/sysrq.txt 2404 that argument. See the SysRq documentation in Documentation/sysrq.txt
2395 in your favorite kernel tree to see what letters are valid and what 2405 in your favorite kernel tree to see what letters are valid and what
2396 they do. 2406 they do.
2397 2407
2398 2408
2399 2409
2400 1100..66.. hheellpp 2410 1100..66.. hheellpp
2401 2411
2402 "help" returns a string listing the valid commands and what each one 2412 "help" returns a string listing the valid commands and what each one
2403 does. 2413 does.
2404 2414
2405 2415
2406 2416
2407 1100..77.. ccaadd 2417 1100..77.. ccaadd
2408 2418
2409 This invokes the Ctl-Alt-Del action on init. What exactly this ends 2419 This invokes the Ctl-Alt-Del action on init. What exactly this ends
2410 up doing is up to /etc/inittab. Normally, it reboots the machine. 2420 up doing is up to /etc/inittab. Normally, it reboots the machine.
2411 With UML, this is usually not desired, so if a halt would be better, 2421 With UML, this is usually not desired, so if a halt would be better,
2412 then find the section of inittab that looks like this 2422 then find the section of inittab that looks like this
2413 2423
2414 2424
2415 # What to do when CTRL-ALT-DEL is pressed. 2425 # What to do when CTRL-ALT-DEL is pressed.
2416 ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now 2426 ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
2417 2427
2418 2428
2419 2429
2420 2430
2421 and change the command to halt. 2431 and change the command to halt.
2422 2432
2423 2433
2424 2434
2425 1100..88.. ssttoopp 2435 1100..88.. ssttoopp
2426 2436
2427 This puts the UML in a loop reading mconsole requests until a 'go' 2437 This puts the UML in a loop reading mconsole requests until a 'go'
2428 mconsole command is received. This is very useful for making backups 2438 mconsole command is received. This is very useful for making backups
2429 of UML filesystems, as the UML can be stopped, then synced via 'sysrq 2439 of UML filesystems, as the UML can be stopped, then synced via 'sysrq
2430 s', so that everything is written to the filesystem. You can then copy 2440 s', so that everything is written to the filesystem. You can then copy
2431 the filesystem and then send the UML 'go' via mconsole. 2441 the filesystem and then send the UML 'go' via mconsole.
2432 2442
2433 2443
2434 Note that a UML running with more than one CPU will have problems 2444 Note that a UML running with more than one CPU will have problems
2435 after you send the 'stop' command, as only one CPU will be held in a 2445 after you send the 'stop' command, as only one CPU will be held in a
2436 mconsole loop and all others will continue as normal. This is a bug, 2446 mconsole loop and all others will continue as normal. This is a bug,
2437 and will be fixed. 2447 and will be fixed.
2438 2448
2439 2449
2440 2450
2441 1100..99.. ggoo 2451 1100..99.. ggoo
2442 2452
2443 This resumes a UML after being paused by a 'stop' command. Note that 2453 This resumes a UML after being paused by a 'stop' command. Note that
2444 when the UML has resumed, TCP connections may have timed out and if 2454 when the UML has resumed, TCP connections may have timed out and if
2445 the UML is paused for a long period of time, crond might go a little 2455 the UML is paused for a long period of time, crond might go a little
2446 crazy, running all the jobs it didn't do earlier. 2456 crazy, running all the jobs it didn't do earlier.
2447 2457
2448 2458
2449 2459
2450 2460
2451 2461
2452 2462
2453 2463
2454 2464
2455 1111.. KKeerrnneell ddeebbuuggggiinngg 2465 1111.. KKeerrnneell ddeebbuuggggiinngg
2456 2466
2457 2467
2458 NNoottee:: The interface that makes debugging, as described here, possible 2468 NNoottee:: The interface that makes debugging, as described here, possible
2459 is present in 2.4.0-test6 kernels and later. 2469 is present in 2.4.0-test6 kernels and later.
2460 2470
2461 2471
2462 Since the user-mode kernel runs as a normal Linux process, it is 2472 Since the user-mode kernel runs as a normal Linux process, it is
2463 possible to debug it with gdb almost like any other process. It is 2473 possible to debug it with gdb almost like any other process. It is
2464 slightly different because the kernel's threads are already being 2474 slightly different because the kernel's threads are already being
2465 ptraced for system call interception, so gdb can't ptrace them. 2475 ptraced for system call interception, so gdb can't ptrace them.
2466 However, a mechanism has been added to work around that problem. 2476 However, a mechanism has been added to work around that problem.
2467 2477
2468 2478
2469 In order to debug the kernel, you need build it from source. See 2479 In order to debug the kernel, you need build it from source. See
2470 ``Compiling the kernel and modules'' for information on doing that. 2480 ``Compiling the kernel and modules'' for information on doing that.
2471 Make sure that you enable CONFIG_DEBUGSYM and CONFIG_PT_PROXY during 2481 Make sure that you enable CONFIG_DEBUGSYM and CONFIG_PT_PROXY during
2472 the config. These will compile the kernel with -g, and enable the 2482 the config. These will compile the kernel with -g, and enable the
2473 ptrace proxy so that gdb works with UML, respectively. 2483 ptrace proxy so that gdb works with UML, respectively.
2474 2484
2475 2485
2476 2486
2477 2487
2478 1111..11.. SSttaarrttiinngg tthhee kkeerrnneell uunnddeerr ggddbb 2488 1111..11.. SSttaarrttiinngg tthhee kkeerrnneell uunnddeerr ggddbb
2479 2489
2480 You can have the kernel running under the control of gdb from the 2490 You can have the kernel running under the control of gdb from the
2481 beginning by putting 'debug' on the command line. You will get an 2491 beginning by putting 'debug' on the command line. You will get an
2482 xterm with gdb running inside it. The kernel will send some commands 2492 xterm with gdb running inside it. The kernel will send some commands
2483 to gdb which will leave it stopped at the beginning of start_kernel. 2493 to gdb which will leave it stopped at the beginning of start_kernel.
2484 At this point, you can get things going with 'next', 'step', or 2494 At this point, you can get things going with 'next', 'step', or
2485 'cont'. 2495 'cont'.
2486 2496
2487 2497
2488 There is a transcript of a debugging session here <debug- 2498 There is a transcript of a debugging session here <debug-
2489 session.html> , with breakpoints being set in the scheduler and in an 2499 session.html> , with breakpoints being set in the scheduler and in an
2490 interrupt handler. 2500 interrupt handler.
2491 1111..22.. EExxaammiinniinngg sslleeeeppiinngg pprroocceesssseess 2501 1111..22.. EExxaammiinniinngg sslleeeeppiinngg pprroocceesssseess
2492 2502
2493 Not every bug is evident in the currently running process. Sometimes, 2503 Not every bug is evident in the currently running process. Sometimes,
2494 processes hang in the kernel when they shouldn't because they've 2504 processes hang in the kernel when they shouldn't because they've
2495 deadlocked on a semaphore or something similar. In this case, when 2505 deadlocked on a semaphore or something similar. In this case, when
2496 you ^C gdb and get a backtrace, you will see the idle thread, which 2506 you ^C gdb and get a backtrace, you will see the idle thread, which
2497 isn't very relevant. 2507 isn't very relevant.
2498 2508
2499 2509
2500 What you want is the stack of whatever process is sleeping when it 2510 What you want is the stack of whatever process is sleeping when it
2501 shouldn't be. You need to figure out which process that is, which is 2511 shouldn't be. You need to figure out which process that is, which is
2502 generally fairly easy. Then you need to get its host process id, 2512 generally fairly easy. Then you need to get its host process id,
2503 which you can do either by looking at ps on the host or at 2513 which you can do either by looking at ps on the host or at
2504 task.thread.extern_pid in gdb. 2514 task.thread.extern_pid in gdb.
2505 2515
2506 2516
2507 Now what you do is this: 2517 Now what you do is this:
2508 2518
2509 +o detach from the current thread 2519 +o detach from the current thread
2510 2520
2511 2521
2512 (UML gdb) det 2522 (UML gdb) det
2513 2523
2514 2524
2515 2525
2516 2526
2517 2527
2518 +o attach to the thread you are interested in 2528 +o attach to the thread you are interested in
2519 2529
2520 2530
2521 (UML gdb) att <host pid> 2531 (UML gdb) att <host pid>
2522 2532
2523 2533
2524 2534
2525 2535
2526 2536
2527 +o look at its stack and anything else of interest 2537 +o look at its stack and anything else of interest
2528 2538
2529 2539
2530 (UML gdb) bt 2540 (UML gdb) bt
2531 2541
2532 2542
2533 2543
2534 2544
2535 Note that you can't do anything at this point that requires that a 2545 Note that you can't do anything at this point that requires that a
2536 process execute, e.g. calling a function 2546 process execute, e.g. calling a function
2537 2547
2538 +o when you're done looking at that process, reattach to the current 2548 +o when you're done looking at that process, reattach to the current
2539 thread and continue it 2549 thread and continue it
2540 2550
2541 2551
2542 (UML gdb) 2552 (UML gdb)
2543 att 1 2553 att 1
2544 2554
2545 2555
2546 2556
2547 2557
2548 2558
2549 2559
2550 (UML gdb) 2560 (UML gdb)
2551 c 2561 c
2552 2562
2553 2563
2554 2564
2555 2565
2556 Here, specifying any pid which is not the process id of a UML thread 2566 Here, specifying any pid which is not the process id of a UML thread
2557 will cause gdb to reattach to the current thread. I commonly use 1, 2567 will cause gdb to reattach to the current thread. I commonly use 1,
2558 but any other invalid pid would work. 2568 but any other invalid pid would work.
2559 2569
2560 2570
2561 2571
2562 1111..33.. RRuunnnniinngg dddddd oonn UUMMLL 2572 1111..33.. RRuunnnniinngg dddddd oonn UUMMLL
2563 2573
2564 ddd works on UML, but requires a special kludge. The process goes 2574 ddd works on UML, but requires a special kludge. The process goes
2565 like this: 2575 like this:
2566 2576
2567 +o Start ddd 2577 +o Start ddd
2568 2578
2569 2579
2570 host% ddd linux 2580 host% ddd linux
2571 2581
2572 2582
2573 2583
2574 2584
2575 2585
2576 +o With ps, get the pid of the gdb that ddd started. You can ask the 2586 +o With ps, get the pid of the gdb that ddd started. You can ask the
2577 gdb to tell you, but for some reason that confuses things and 2587 gdb to tell you, but for some reason that confuses things and
2578 causes a hang. 2588 causes a hang.
2579 2589
2580 +o run UML with 'debug=parent gdb-pid=<pid>' added to the command line 2590 +o run UML with 'debug=parent gdb-pid=<pid>' added to the command line
2581 - it will just sit there after you hit return 2591 - it will just sit there after you hit return
2582 2592
2583 +o type 'att 1' to the ddd gdb and you will see something like 2593 +o type 'att 1' to the ddd gdb and you will see something like
2584 2594
2585 2595
2586 0xa013dc51 in __kill () 2596 0xa013dc51 in __kill ()
2587 2597
2588 2598
2589 (gdb) 2599 (gdb)
2590 2600
2591 2601
2592 2602
2593 2603
2594 2604
2595 +o At this point, type 'c', UML will boot up, and you can use ddd just 2605 +o At this point, type 'c', UML will boot up, and you can use ddd just
2596 as you do on any other process. 2606 as you do on any other process.
2597 2607
2598 2608
2599 2609
2600 1111..44.. DDeebbuuggggiinngg mmoodduulleess 2610 1111..44.. DDeebbuuggggiinngg mmoodduulleess
2601 2611
2602 gdb has support for debugging code which is dynamically loaded into 2612 gdb has support for debugging code which is dynamically loaded into
2603 the process. This support is what is needed to debug kernel modules 2613 the process. This support is what is needed to debug kernel modules
2604 under UML. 2614 under UML.
2605 2615
2606 2616
2607 Using that support is somewhat complicated. You have to tell gdb what 2617 Using that support is somewhat complicated. You have to tell gdb what
2608 object file you just loaded into UML and where in memory it is. Then, 2618 object file you just loaded into UML and where in memory it is. Then,
2609 it can read the symbol table, and figure out where all the symbols are 2619 it can read the symbol table, and figure out where all the symbols are
2610 from the load address that you provided. It gets more interesting 2620 from the load address that you provided. It gets more interesting
2611 when you load the module again (i.e. after an rmmod). You have to 2621 when you load the module again (i.e. after an rmmod). You have to
2612 tell gdb to forget about all its symbols, including the main UML ones 2622 tell gdb to forget about all its symbols, including the main UML ones
2613 for some reason, then load then all back in again. 2623 for some reason, then load then all back in again.
2614 2624
2615 2625
2616 There's an easy way and a hard way to do this. The easy way is to use 2626 There's an easy way and a hard way to do this. The easy way is to use
2617 the umlgdb expect script written by Chandan Kudige. It basically 2627 the umlgdb expect script written by Chandan Kudige. It basically
2618 automates the process for you. 2628 automates the process for you.
2619 2629
2620 2630
2621 First, you must tell it where your modules are. There is a list in 2631 First, you must tell it where your modules are. There is a list in
2622 the script that looks like this: 2632 the script that looks like this:
2623 set MODULE_PATHS { 2633 set MODULE_PATHS {
2624 "fat" "/usr/src/uml/linux-2.4.18/fs/fat/fat.o" 2634 "fat" "/usr/src/uml/linux-2.4.18/fs/fat/fat.o"
2625 "isofs" "/usr/src/uml/linux-2.4.18/fs/isofs/isofs.o" 2635 "isofs" "/usr/src/uml/linux-2.4.18/fs/isofs/isofs.o"
2626 "minix" "/usr/src/uml/linux-2.4.18/fs/minix/minix.o" 2636 "minix" "/usr/src/uml/linux-2.4.18/fs/minix/minix.o"
2627 } 2637 }
2628 2638
2629 2639
2630 2640
2631 2641
2632 You change that to list the names and paths of the modules that you 2642 You change that to list the names and paths of the modules that you
2633 are going to debug. Then you run it from the toplevel directory of 2643 are going to debug. Then you run it from the toplevel directory of
2634 your UML pool and it basically tells you what to do: 2644 your UML pool and it basically tells you what to do:
2635 2645
2636 2646
2637 2647
2638 2648
2639 ******** GDB pid is 21903 ******** 2649 ******** GDB pid is 21903 ********
2640 Start UML as: ./linux <kernel switches> debug gdb-pid=21903 2650 Start UML as: ./linux <kernel switches> debug gdb-pid=21903
2641 2651
2642 2652
2643 2653
2644 GNU gdb 5.0rh-5 Red Hat Linux 7.1 2654 GNU gdb 5.0rh-5 Red Hat Linux 7.1
2645 Copyright 2001 Free Software Foundation, Inc. 2655 Copyright 2001 Free Software Foundation, Inc.
2646 GDB is free software, covered by the GNU General Public License, and you are 2656 GDB is free software, covered by the GNU General Public License, and you are
2647 welcome to change it and/or distribute copies of it under certain conditions. 2657 welcome to change it and/or distribute copies of it under certain conditions.
2648 Type "show copying" to see the conditions. 2658 Type "show copying" to see the conditions.
2649 There is absolutely no warranty for GDB. Type "show warranty" for details. 2659 There is absolutely no warranty for GDB. Type "show warranty" for details.
2650 This GDB was configured as "i386-redhat-linux"... 2660 This GDB was configured as "i386-redhat-linux"...
2651 (gdb) b sys_init_module 2661 (gdb) b sys_init_module
2652 Breakpoint 1 at 0xa0011923: file module.c, line 349. 2662 Breakpoint 1 at 0xa0011923: file module.c, line 349.
2653 (gdb) att 1 2663 (gdb) att 1
2654 2664
2655 2665
2656 2666
2657 2667
2658 After you run UML and it sits there doing nothing, you hit return at 2668 After you run UML and it sits there doing nothing, you hit return at
2659 the 'att 1' and continue it: 2669 the 'att 1' and continue it:
2660 2670
2661 2671
2662 Attaching to program: /home/jdike/linux/2.4/um/./linux, process 1 2672 Attaching to program: /home/jdike/linux/2.4/um/./linux, process 1
2663 0xa00f4221 in __kill () 2673 0xa00f4221 in __kill ()
2664 (UML gdb) c 2674 (UML gdb) c
2665 Continuing. 2675 Continuing.
2666 2676
2667 2677
2668 2678
2669 2679
2670 At this point, you debug normally. When you insmod something, the 2680 At this point, you debug normally. When you insmod something, the
2671 expect magic will kick in and you'll see something like: 2681 expect magic will kick in and you'll see something like:
2672 2682
2673 2683
2674 2684
2675 2685
2676 2686
2677 2687
2678 2688
2679 2689
2680 2690
2681 2691
2682 2692
2683 2693
2684 2694
2685 2695
2686 2696
2687 2697
2688 2698
2689 *** Module hostfs loaded *** 2699 *** Module hostfs loaded ***
2690 Breakpoint 1, sys_init_module (name_user=0x805abb0 "hostfs", 2700 Breakpoint 1, sys_init_module (name_user=0x805abb0 "hostfs",
2691 mod_user=0x8070e00) at module.c:349 2701 mod_user=0x8070e00) at module.c:349
2692 349 char *name, *n_name, *name_tmp = NULL; 2702 349 char *name, *n_name, *name_tmp = NULL;
2693 (UML gdb) finish 2703 (UML gdb) finish
2694 Run till exit from #0 sys_init_module (name_user=0x805abb0 "hostfs", 2704 Run till exit from #0 sys_init_module (name_user=0x805abb0 "hostfs",
2695 mod_user=0x8070e00) at module.c:349 2705 mod_user=0x8070e00) at module.c:349
2696 0xa00e2e23 in execute_syscall (r=0xa8140284) at syscall_kern.c:411 2706 0xa00e2e23 in execute_syscall (r=0xa8140284) at syscall_kern.c:411
2697 411 else res = EXECUTE_SYSCALL(syscall, regs); 2707 411 else res = EXECUTE_SYSCALL(syscall, regs);
2698 Value returned is $1 = 0 2708 Value returned is $1 = 0
2699 (UML gdb) 2709 (UML gdb)
2700 p/x (int)module_list + module_list->size_of_struct 2710 p/x (int)module_list + module_list->size_of_struct
2701 2711
2702 $2 = 0xa9021054 2712 $2 = 0xa9021054
2703 (UML gdb) symbol-file ./linux 2713 (UML gdb) symbol-file ./linux
2704 Load new symbol table from "./linux"? (y or n) y 2714 Load new symbol table from "./linux"? (y or n) y
2705 Reading symbols from ./linux... 2715 Reading symbols from ./linux...
2706 done. 2716 done.
2707 (UML gdb) 2717 (UML gdb)
2708 add-symbol-file /home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o 0xa9021054 2718 add-symbol-file /home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o 0xa9021054
2709 2719
2710 add symbol table from file "/home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o" at 2720 add symbol table from file "/home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o" at
2711 .text_addr = 0xa9021054 2721 .text_addr = 0xa9021054
2712 (y or n) y 2722 (y or n) y
2713 2723
2714 Reading symbols from /home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o... 2724 Reading symbols from /home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o...
2715 done. 2725 done.
2716 (UML gdb) p *module_list 2726 (UML gdb) p *module_list
2717 $1 = {size_of_struct = 84, next = 0xa0178720, name = 0xa9022de0 "hostfs", 2727 $1 = {size_of_struct = 84, next = 0xa0178720, name = 0xa9022de0 "hostfs",
2718 size = 9016, uc = {usecount = {counter = 0}, pad = 0}, flags = 1, 2728 size = 9016, uc = {usecount = {counter = 0}, pad = 0}, flags = 1,
2719 nsyms = 57, ndeps = 0, syms = 0xa9023170, deps = 0x0, refs = 0x0, 2729 nsyms = 57, ndeps = 0, syms = 0xa9023170, deps = 0x0, refs = 0x0,
2720 init = 0xa90221f0 <init_hostfs>, cleanup = 0xa902222c <exit_hostfs>, 2730 init = 0xa90221f0 <init_hostfs>, cleanup = 0xa902222c <exit_hostfs>,
2721 ex_table_start = 0x0, ex_table_end = 0x0, persist_start = 0x0, 2731 ex_table_start = 0x0, ex_table_end = 0x0, persist_start = 0x0,
2722 persist_end = 0x0, can_unload = 0, runsize = 0, kallsyms_start = 0x0, 2732 persist_end = 0x0, can_unload = 0, runsize = 0, kallsyms_start = 0x0,
2723 kallsyms_end = 0x0, 2733 kallsyms_end = 0x0,
2724 archdata_start = 0x1b855 <Address 0x1b855 out of bounds>, 2734 archdata_start = 0x1b855 <Address 0x1b855 out of bounds>,
2725 archdata_end = 0xe5890000 <Address 0xe5890000 out of bounds>, 2735 archdata_end = 0xe5890000 <Address 0xe5890000 out of bounds>,
2726 kernel_data = 0xf689c35d <Address 0xf689c35d out of bounds>} 2736 kernel_data = 0xf689c35d <Address 0xf689c35d out of bounds>}
2727 >> Finished loading symbols for hostfs ... 2737 >> Finished loading symbols for hostfs ...
2728 2738
2729 2739
2730 2740
2731 2741
2732 That's the easy way. It's highly recommended. The hard way is 2742 That's the easy way. It's highly recommended. The hard way is
2733 described below in case you're interested in what's going on. 2743 described below in case you're interested in what's going on.
2734 2744
2735 2745
2736 Boot the kernel under the debugger and load the module with insmod or 2746 Boot the kernel under the debugger and load the module with insmod or
2737 modprobe. With gdb, do: 2747 modprobe. With gdb, do:
2738 2748
2739 2749
2740 (UML gdb) p module_list 2750 (UML gdb) p module_list
2741 2751
2742 2752
2743 2753
2744 2754
2745 This is a list of modules that have been loaded into the kernel, with 2755 This is a list of modules that have been loaded into the kernel, with
2746 the most recently loaded module first. Normally, the module you want 2756 the most recently loaded module first. Normally, the module you want
2747 is at module_list. If it's not, walk down the next links, looking at 2757 is at module_list. If it's not, walk down the next links, looking at
2748 the name fields until find the module you want to debug. Take the 2758 the name fields until find the module you want to debug. Take the
2749 address of that structure, and add module.size_of_struct (which in 2759 address of that structure, and add module.size_of_struct (which in
2750 2.4.10 kernels is 96 (0x60)) to it. Gdb can make this hard addition 2760 2.4.10 kernels is 96 (0x60)) to it. Gdb can make this hard addition
2751 for you :-): 2761 for you :-):
2752 2762
2753 2763
2754 2764
2755 (UML gdb) 2765 (UML gdb)
2756 printf "%#x\n", (int)module_list module_list->size_of_struct 2766 printf "%#x\n", (int)module_list module_list->size_of_struct
2757 2767
2758 2768
2759 2769
2760 2770
2761 The offset from the module start occasionally changes (before 2.4.0, 2771 The offset from the module start occasionally changes (before 2.4.0,
2762 it was module.size_of_struct + 4), so it's a good idea to check the 2772 it was module.size_of_struct + 4), so it's a good idea to check the
2763 init and cleanup addresses once in a while, as describe below. Now 2773 init and cleanup addresses once in a while, as describe below. Now
2764 do: 2774 do:
2765 2775
2766 2776
2767 (UML gdb) 2777 (UML gdb)
2768 add-symbol-file /path/to/module/on/host that_address 2778 add-symbol-file /path/to/module/on/host that_address
2769 2779
2770 2780
2771 2781
2772 2782
2773 Tell gdb you really want to do it, and you're in business. 2783 Tell gdb you really want to do it, and you're in business.
2774 2784
2775 2785
2776 If there's any doubt that you got the offset right, like breakpoints 2786 If there's any doubt that you got the offset right, like breakpoints
2777 appear not to work, or they're appearing in the wrong place, you can 2787 appear not to work, or they're appearing in the wrong place, you can
2778 check it by looking at the module structure. The init and cleanup 2788 check it by looking at the module structure. The init and cleanup
2779 fields should look like: 2789 fields should look like:
2780 2790
2781 2791
2782 init = 0x588066b0 <init_hostfs>, cleanup = 0x588066c0 <exit_hostfs> 2792 init = 0x588066b0 <init_hostfs>, cleanup = 0x588066c0 <exit_hostfs>
2783 2793
2784 2794
2785 2795
2786 2796
2787 with no offsets on the symbol names. If the names are right, but they 2797 with no offsets on the symbol names. If the names are right, but they
2788 are offset, then the offset tells you how much you need to add to the 2798 are offset, then the offset tells you how much you need to add to the
2789 address you gave to add-symbol-file. 2799 address you gave to add-symbol-file.
2790 2800
2791 2801
2792 When you want to load in a new version of the module, you need to get 2802 When you want to load in a new version of the module, you need to get
2793 gdb to forget about the old one. The only way I've found to do that 2803 gdb to forget about the old one. The only way I've found to do that
2794 is to tell gdb to forget about all symbols that it knows about: 2804 is to tell gdb to forget about all symbols that it knows about:
2795 2805
2796 2806
2797 (UML gdb) symbol-file 2807 (UML gdb) symbol-file
2798 2808
2799 2809
2800 2810
2801 2811
2802 Then reload the symbols from the kernel binary: 2812 Then reload the symbols from the kernel binary:
2803 2813
2804 2814
2805 (UML gdb) symbol-file /path/to/kernel 2815 (UML gdb) symbol-file /path/to/kernel
2806 2816
2807 2817
2808 2818
2809 2819
2810 and repeat the process above. You'll also need to re-enable break- 2820 and repeat the process above. You'll also need to re-enable break-
2811 points. They were disabled when you dumped all the symbols because 2821 points. They were disabled when you dumped all the symbols because
2812 gdb couldn't figure out where they should go. 2822 gdb couldn't figure out where they should go.
2813 2823
2814 2824
2815 2825
2816 1111..55.. AAttttaacchhiinngg ggddbb ttoo tthhee kkeerrnneell 2826 1111..55.. AAttttaacchhiinngg ggddbb ttoo tthhee kkeerrnneell
2817 2827
2818 If you don't have the kernel running under gdb, you can attach gdb to 2828 If you don't have the kernel running under gdb, you can attach gdb to
2819 it later by sending the tracing thread a SIGUSR1. The first line of 2829 it later by sending the tracing thread a SIGUSR1. The first line of
2820 the console output identifies its pid: 2830 the console output identifies its pid:
2821 tracing thread pid = 20093 2831 tracing thread pid = 20093
2822 2832
2823 2833
2824 2834
2825 2835
2826 When you send it the signal: 2836 When you send it the signal:
2827 2837
2828 2838
2829 host% kill -USR1 20093 2839 host% kill -USR1 20093
2830 2840
2831 2841
2832 2842
2833 2843
2834 you will get an xterm with gdb running in it. 2844 you will get an xterm with gdb running in it.
2835 2845
2836 2846
2837 If you have the mconsole compiled into UML, then the mconsole client 2847 If you have the mconsole compiled into UML, then the mconsole client
2838 can be used to start gdb: 2848 can be used to start gdb:
2839 2849
2840 2850
2841 (mconsole) (mconsole) config gdb=xterm 2851 (mconsole) (mconsole) config gdb=xterm
2842 2852
2843 2853
2844 2854
2845 2855
2846 will fire up an xterm with gdb running in it. 2856 will fire up an xterm with gdb running in it.
2847 2857
2848 2858
2849 2859
2850 1111..66.. UUssiinngg aalltteerrnnaattee ddeebbuuggggeerrss 2860 1111..66.. UUssiinngg aalltteerrnnaattee ddeebbuuggggeerrss
2851 2861
2852 UML has support for attaching to an already running debugger rather 2862 UML has support for attaching to an already running debugger rather
2853 than starting gdb itself. This is present in CVS as of 17 Apr 2001. 2863 than starting gdb itself. This is present in CVS as of 17 Apr 2001.
2854 I sent it to Alan for inclusion in the ac tree, and it will be in my 2864 I sent it to Alan for inclusion in the ac tree, and it will be in my
2855 2.4.4 release. 2865 2.4.4 release.
2856 2866
2857 2867
2858 This is useful when gdb is a subprocess of some UI, such as emacs or 2868 This is useful when gdb is a subprocess of some UI, such as emacs or
2859 ddd. It can also be used to run debuggers other than gdb on UML. 2869 ddd. It can also be used to run debuggers other than gdb on UML.
2860 Below is an example of using strace as an alternate debugger. 2870 Below is an example of using strace as an alternate debugger.
2861 2871
2862 2872
2863 To do this, you need to get the pid of the debugger and pass it in 2873 To do this, you need to get the pid of the debugger and pass it in
2864 with the 2874 with the
2865 2875
2866 2876
2867 If you are using gdb under some UI, then tell it to 'att 1', and 2877 If you are using gdb under some UI, then tell it to 'att 1', and
2868 you'll find yourself attached to UML. 2878 you'll find yourself attached to UML.
2869 2879
2870 2880
2871 If you are using something other than gdb as your debugger, then 2881 If you are using something other than gdb as your debugger, then
2872 you'll need to get it to do the equivalent of 'att 1' if it doesn't do 2882 you'll need to get it to do the equivalent of 'att 1' if it doesn't do
2873 it automatically. 2883 it automatically.
2874 2884
2875 2885
2876 An example of an alternate debugger is strace. You can strace the 2886 An example of an alternate debugger is strace. You can strace the
2877 actual kernel as follows: 2887 actual kernel as follows:
2878 2888
2879 +o Run the following in a shell 2889 +o Run the following in a shell
2880 2890
2881 2891
2882 host% 2892 host%
2883 sh -c 'echo pid=$$; echo -n hit return; read x; exec strace -p 1 -o strace.out' 2893 sh -c 'echo pid=$$; echo -n hit return; read x; exec strace -p 1 -o strace.out'
2884 2894
2885 2895
2886 2896
2887 +o Run UML with 'debug' and 'gdb-pid=<pid>' with the pid printed out 2897 +o Run UML with 'debug' and 'gdb-pid=<pid>' with the pid printed out
2888 by the previous command 2898 by the previous command
2889 2899
2890 +o Hit return in the shell, and UML will start running, and strace 2900 +o Hit return in the shell, and UML will start running, and strace
2891 output will start accumulating in the output file. 2901 output will start accumulating in the output file.
2892 2902
2893 Note that this is different from running 2903 Note that this is different from running
2894 2904
2895 2905
2896 host% strace ./linux 2906 host% strace ./linux
2897 2907
2898 2908
2899 2909
2900 2910
2901 That will strace only the main UML thread, the tracing thread, which 2911 That will strace only the main UML thread, the tracing thread, which
2902 doesn't do any of the actual kernel work. It just oversees the vir- 2912 doesn't do any of the actual kernel work. It just oversees the vir-
2903 tual machine. In contrast, using strace as described above will show 2913 tual machine. In contrast, using strace as described above will show
2904 you the low-level activity of the virtual machine. 2914 you the low-level activity of the virtual machine.
2905 2915
2906 2916
2907 2917
2908 2918
2909 2919
2910 1122.. KKeerrnneell ddeebbuuggggiinngg eexxaammpplleess 2920 1122.. KKeerrnneell ddeebbuuggggiinngg eexxaammpplleess
2911 2921
2912 1122..11.. TThhee ccaassee ooff tthhee hhuunngg ffsscckk 2922 1122..11.. TThhee ccaassee ooff tthhee hhuunngg ffsscckk
2913 2923
2914 When booting up the kernel, fsck failed, and dropped me into a shell 2924 When booting up the kernel, fsck failed, and dropped me into a shell
2915 to fix things up. I ran fsck -y, which hung: 2925 to fix things up. I ran fsck -y, which hung:
2916 2926
2917 2927
2918 2928
2919 2929
2920 2930
2921 2931
2922 2932
2923 2933
2924 2934
2925 2935
2926 2936
2927 2937
2928 2938
2929 2939
2930 2940
2931 2941
2932 2942
2933 2943
2934 2944
2935 2945
2936 2946
2937 2947
2938 2948
2939 2949
2940 2950
2941 2951
2942 2952
2943 2953
2944 2954
2945 2955
2946 2956
2947 2957
2948 2958
2949 2959
2950 2960
2951 2961
2952 2962
2953 Setting hostname uml [ OK ] 2963 Setting hostname uml [ OK ]
2954 Checking root filesystem 2964 Checking root filesystem
2955 /dev/fhd0 was not cleanly unmounted, check forced. 2965 /dev/fhd0 was not cleanly unmounted, check forced.
2956 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. 2966 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780.
2957 2967
2958 /dev/fhd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. 2968 /dev/fhd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
2959 (i.e., without -a or -p options) 2969 (i.e., without -a or -p options)
2960 [ FAILED ] 2970 [ FAILED ]
2961 2971
2962 *** An error occurred during the file system check. 2972 *** An error occurred during the file system check.
2963 *** Dropping you to a shell; the system will reboot 2973 *** Dropping you to a shell; the system will reboot
2964 *** when you leave the shell. 2974 *** when you leave the shell.
2965 Give root password for maintenance 2975 Give root password for maintenance
2966 (or type Control-D for normal startup): 2976 (or type Control-D for normal startup):
2967 2977
2968 [root@uml /root]# fsck -y /dev/fhd0 2978 [root@uml /root]# fsck -y /dev/fhd0
2969 fsck -y /dev/fhd0 2979 fsck -y /dev/fhd0
2970 Parallelizing fsck version 1.14 (9-Jan-1999) 2980 Parallelizing fsck version 1.14 (9-Jan-1999)
2971 e2fsck 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 2981 e2fsck 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
2972 /dev/fhd0 contains a file system with errors, check forced. 2982 /dev/fhd0 contains a file system with errors, check forced.
2973 Pass 1: Checking inodes, blocks, and sizes 2983 Pass 1: Checking inodes, blocks, and sizes
2974 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. Ignore error? yes 2984 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. Ignore error? yes
2975 2985
2976 Inode 19780, i_blocks is 1548, should be 540. Fix? yes 2986 Inode 19780, i_blocks is 1548, should be 540. Fix? yes
2977 2987
2978 Pass 2: Checking directory structure 2988 Pass 2: Checking directory structure
2979 Error reading block 49405 (Attempt to read block from filesystem resulted in short read). Ignore error? yes 2989 Error reading block 49405 (Attempt to read block from filesystem resulted in short read). Ignore error? yes
2980 2990
2981 Directory inode 11858, block 0, offset 0: directory corrupted 2991 Directory inode 11858, block 0, offset 0: directory corrupted
2982 Salvage? yes 2992 Salvage? yes
2983 2993
2984 Missing '.' in directory inode 11858. 2994 Missing '.' in directory inode 11858.
2985 Fix? yes 2995 Fix? yes
2986 2996
2987 Missing '..' in directory inode 11858. 2997 Missing '..' in directory inode 11858.
2988 Fix? yes 2998 Fix? yes
2989 2999
2990 3000
2991 3001
2992 3002
2993 3003
2994 The standard drill in this sort of situation is to fire up gdb on the 3004 The standard drill in this sort of situation is to fire up gdb on the
2995 signal thread, which, in this case, was pid 1935. In another window, 3005 signal thread, which, in this case, was pid 1935. In another window,
2996 I run gdb and attach pid 1935. 3006 I run gdb and attach pid 1935.
2997 3007
2998 3008
2999 3009
3000 3010
3001 ~/linux/2.3.26/um 1016: gdb linux 3011 ~/linux/2.3.26/um 1016: gdb linux
3002 GNU gdb 4.17.0.11 with Linux support 3012 GNU gdb 4.17.0.11 with Linux support
3003 Copyright 1998 Free Software Foundation, Inc. 3013 Copyright 1998 Free Software Foundation, Inc.
3004 GDB is free software, covered by the GNU General Public License, and you are 3014 GDB is free software, covered by the GNU General Public License, and you are
3005 welcome to change it and/or distribute copies of it under certain conditions. 3015 welcome to change it and/or distribute copies of it under certain conditions.
3006 Type "show copying" to see the conditions. 3016 Type "show copying" to see the conditions.
3007 There is absolutely no warranty for GDB. Type "show warranty" for details. 3017 There is absolutely no warranty for GDB. Type "show warranty" for details.
3008 This GDB was configured as "i386-redhat-linux"... 3018 This GDB was configured as "i386-redhat-linux"...
3009 3019
3010 (gdb) att 1935 3020 (gdb) att 1935
3011 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 1935 3021 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 1935
3012 0x100756d9 in __wait4 () 3022 0x100756d9 in __wait4 ()
3013 3023
3014 3024
3015 3025
3016 3026
3017 3027
3018 3028
3019 Let's see what's currently running: 3029 Let's see what's currently running:
3020 3030
3021 3031
3022 3032
3023 (gdb) p current_task.pid 3033 (gdb) p current_task.pid
3024 $1 = 0 3034 $1 = 0
3025 3035
3026 3036
3027 3037
3028 3038
3029 3039
3030 It's the idle thread, which means that fsck went to sleep for some 3040 It's the idle thread, which means that fsck went to sleep for some
3031 reason and never woke up. 3041 reason and never woke up.
3032 3042
3033 3043
3034 Let's guess that the last process in the process list is fsck: 3044 Let's guess that the last process in the process list is fsck:
3035 3045
3036 3046
3037 3047
3038 (gdb) p current_task.prev_task.comm 3048 (gdb) p current_task.prev_task.comm
3039 $13 = "fsck.ext2\000\000\000\000\000\000" 3049 $13 = "fsck.ext2\000\000\000\000\000\000"
3040 3050
3041 3051
3042 3052
3043 3053
3044 3054
3045 It is, so let's see what it thinks it's up to: 3055 It is, so let's see what it thinks it's up to:
3046 3056
3047 3057
3048 3058
3049 (gdb) p current_task.prev_task.thread 3059 (gdb) p current_task.prev_task.thread
3050 $14 = {extern_pid = 1980, tracing = 0, want_tracing = 0, forking = 0, 3060 $14 = {extern_pid = 1980, tracing = 0, want_tracing = 0, forking = 0,
3051 kernel_stack_page = 0, signal_stack = 1342627840, syscall = {id = 4, args = { 3061 kernel_stack_page = 0, signal_stack = 1342627840, syscall = {id = 4, args = {
3052 3, 134973440, 1024, 0, 1024}, have_result = 0, result = 50590720}, 3062 3, 134973440, 1024, 0, 1024}, have_result = 0, result = 50590720},
3053 request = {op = 2, u = {exec = {ip = 1350467584, sp = 2952789424}, fork = { 3063 request = {op = 2, u = {exec = {ip = 1350467584, sp = 2952789424}, fork = {
3054 regs = {1350467584, 2952789424, 0 <repeats 15 times>}, sigstack = 0, 3064 regs = {1350467584, 2952789424, 0 <repeats 15 times>}, sigstack = 0,
3055 pid = 0}, switch_to = 0x507e8000, thread = {proc = 0x507e8000, 3065 pid = 0}, switch_to = 0x507e8000, thread = {proc = 0x507e8000,
3056 arg = 0xaffffdb0, flags = 0, new_pid = 0}, input_request = { 3066 arg = 0xaffffdb0, flags = 0, new_pid = 0}, input_request = {
3057 op = 1350467584, fd = -1342177872, proc = 0, pid = 0}}}} 3067 op = 1350467584, fd = -1342177872, proc = 0, pid = 0}}}}
3058 3068
3059 3069
3060 3070
3061 3071
3062 3072
3063 The interesting things here are the fact that its .thread.syscall.id 3073 The interesting things here are the fact that its .thread.syscall.id
3064 is __NR_write (see the big switch in arch/um/kernel/syscall_kern.c or 3074 is __NR_write (see the big switch in arch/um/kernel/syscall_kern.c or
3065 the defines in include/asm-um/arch/unistd.h), and that it never 3075 the defines in include/asm-um/arch/unistd.h), and that it never
3066 returned. Also, its .request.op is OP_SWITCH (see 3076 returned. Also, its .request.op is OP_SWITCH (see
3067 arch/um/include/user_util.h). These mean that it went into a write, 3077 arch/um/include/user_util.h). These mean that it went into a write,
3068 and, for some reason, called schedule(). 3078 and, for some reason, called schedule().
3069 3079
3070 3080
3071 The fact that it never returned from write means that its stack should 3081 The fact that it never returned from write means that its stack should
3072 be fairly interesting. Its pid is 1980 (.thread.extern_pid). That 3082 be fairly interesting. Its pid is 1980 (.thread.extern_pid). That
3073 process is being ptraced by the signal thread, so it must be detached 3083 process is being ptraced by the signal thread, so it must be detached
3074 before gdb can attach it: 3084 before gdb can attach it:
3075 3085
3076 3086
3077 3087
3078 3088
3079 3089
3080 3090
3081 3091
3082 3092
3083 3093
3084 3094
3085 (gdb) call detach(1980) 3095 (gdb) call detach(1980)
3086 3096
3087 Program received signal SIGSEGV, Segmentation fault. 3097 Program received signal SIGSEGV, Segmentation fault.
3088 <function called from gdb> 3098 <function called from gdb>
3089 The program being debugged stopped while in a function called from GDB. 3099 The program being debugged stopped while in a function called from GDB.
3090 When the function (detach) is done executing, GDB will silently 3100 When the function (detach) is done executing, GDB will silently
3091 stop (instead of continuing to evaluate the expression containing 3101 stop (instead of continuing to evaluate the expression containing
3092 the function call). 3102 the function call).
3093 (gdb) call detach(1980) 3103 (gdb) call detach(1980)
3094 $15 = 0 3104 $15 = 0
3095 3105
3096 3106
3097 3107
3098 3108
3099 3109
3100 The first detach segfaults for some reason, and the second one 3110 The first detach segfaults for some reason, and the second one
3101 succeeds. 3111 succeeds.
3102 3112
3103 3113
3104 Now I detach from the signal thread, attach to the fsck thread, and 3114 Now I detach from the signal thread, attach to the fsck thread, and
3105 look at its stack: 3115 look at its stack:
3106 3116
3107 3117
3108 (gdb) det 3118 (gdb) det
3109 Detaching from program: /home/dike/linux/2.3.26/um/linux Pid 1935 3119 Detaching from program: /home/dike/linux/2.3.26/um/linux Pid 1935
3110 (gdb) att 1980 3120 (gdb) att 1980
3111 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 1980 3121 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 1980
3112 0x10070451 in __kill () 3122 0x10070451 in __kill ()
3113 (gdb) bt 3123 (gdb) bt
3114 #0 0x10070451 in __kill () 3124 #0 0x10070451 in __kill ()
3115 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30 3125 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30
3116 #2 0x1006a03f in _switch_to (prev=0x50072000, next=0x507e8000) 3126 #2 0x1006a03f in _switch_to (prev=0x50072000, next=0x507e8000)
3117 at process_kern.c:156 3127 at process_kern.c:156
3118 #3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000) 3128 #3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)
3119 at process_kern.c:161 3129 at process_kern.c:161
3120 #4 0x10001d12 in schedule () at sched.c:777 3130 #4 0x10001d12 in schedule () at sched.c:777
3121 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71 3131 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
3122 #6 0x1006aa10 in __down_failed () at semaphore.c:157 3132 #6 0x1006aa10 in __down_failed () at semaphore.c:157
3123 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174 3133 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
3124 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182 3134 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3125 #9 <signal handler called> 3135 #9 <signal handler called>
3126 #10 0x10155404 in errno () 3136 #10 0x10155404 in errno ()
3127 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50 3137 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50
3128 #12 0x1006c5d8 in segv_handler (sc=0x5006eaf8) at trap_user.c:174 3138 #12 0x1006c5d8 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3129 #13 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182 3139 #13 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3130 #14 <signal handler called> 3140 #14 <signal handler called>
3131 #15 0xc0fd in ?? () 3141 #15 0xc0fd in ?? ()
3132 #16 0x10016647 in sys_write (fd=3, 3142 #16 0x10016647 in sys_write (fd=3,
3133 buf=0x80b8800 <Address 0x80b8800 out of bounds>, count=1024) 3143 buf=0x80b8800 <Address 0x80b8800 out of bounds>, count=1024)
3134 at read_write.c:159 3144 at read_write.c:159
3135 #17 0x1006d5b3 in execute_syscall (syscall=4, args=0x5006ef08) 3145 #17 0x1006d5b3 in execute_syscall (syscall=4, args=0x5006ef08)
3136 at syscall_kern.c:254 3146 at syscall_kern.c:254
3137 #18 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35 3147 #18 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35
3138 #19 <signal handler called> 3148 #19 <signal handler called>
3139 #20 0x400dc8b0 in ?? () 3149 #20 0x400dc8b0 in ?? ()
3140 3150
3141 3151
3142 3152
3143 3153
3144 3154
3145 The interesting things here are : 3155 The interesting things here are :
3146 3156
3147 +o There are two segfaults on this stack (frames 9 and 14) 3157 +o There are two segfaults on this stack (frames 9 and 14)
3148 3158
3149 +o The first faulting address (frame 11) is 0x50000800 3159 +o The first faulting address (frame 11) is 0x50000800
3150 3160
3151 (gdb) p (void *)1342179328 3161 (gdb) p (void *)1342179328
3152 $16 = (void *) 0x50000800 3162 $16 = (void *) 0x50000800
3153 3163
3154 3164
3155 3165
3156 3166
3157 3167
3158 The initial faulting address is interesting because it is on the idle 3168 The initial faulting address is interesting because it is on the idle
3159 thread's stack. I had been seeing the idle thread segfault for no 3169 thread's stack. I had been seeing the idle thread segfault for no
3160 apparent reason, and the cause looked like stack corruption. In hopes 3170 apparent reason, and the cause looked like stack corruption. In hopes
3161 of catching the culprit in the act, I had turned off all protections 3171 of catching the culprit in the act, I had turned off all protections
3162 to that stack while the idle thread wasn't running. This apparently 3172 to that stack while the idle thread wasn't running. This apparently
3163 tripped that trap. 3173 tripped that trap.
3164 3174
3165 3175
3166 However, the more immediate problem is that second segfault and I'm 3176 However, the more immediate problem is that second segfault and I'm
3167 going to concentrate on that. First, I want to see where the fault 3177 going to concentrate on that. First, I want to see where the fault
3168 happened, so I have to go look at the sigcontent struct in frame 8: 3178 happened, so I have to go look at the sigcontent struct in frame 8:
3169 3179
3170 3180
3171 3181
3172 (gdb) up 3182 (gdb) up
3173 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30 3183 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30
3174 30 kill(pid, SIGUSR1); 3184 30 kill(pid, SIGUSR1);
3175 (gdb) 3185 (gdb)
3176 #2 0x1006a03f in _switch_to (prev=0x50072000, next=0x507e8000) 3186 #2 0x1006a03f in _switch_to (prev=0x50072000, next=0x507e8000)
3177 at process_kern.c:156 3187 at process_kern.c:156
3178 156 usr1_pid(getpid()); 3188 156 usr1_pid(getpid());
3179 (gdb) 3189 (gdb)
3180 #3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000) 3190 #3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)
3181 at process_kern.c:161 3191 at process_kern.c:161
3182 161 _switch_to(prev, next); 3192 161 _switch_to(prev, next);
3183 (gdb) 3193 (gdb)
3184 #4 0x10001d12 in schedule () at sched.c:777 3194 #4 0x10001d12 in schedule () at sched.c:777
3185 777 switch_to(prev, next, prev); 3195 777 switch_to(prev, next, prev);
3186 (gdb) 3196 (gdb)
3187 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71 3197 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
3188 71 schedule(); 3198 71 schedule();
3189 (gdb) 3199 (gdb)
3190 #6 0x1006aa10 in __down_failed () at semaphore.c:157 3200 #6 0x1006aa10 in __down_failed () at semaphore.c:157
3191 157 } 3201 157 }
3192 (gdb) 3202 (gdb)
3193 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174 3203 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
3194 174 segv(sc->cr2, sc->err & 2); 3204 174 segv(sc->cr2, sc->err & 2);
3195 (gdb) 3205 (gdb)
3196 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182 3206 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3197 182 segv_handler(sc); 3207 182 segv_handler(sc);
3198 (gdb) p *sc 3208 (gdb) p *sc
3199 Cannot access memory at address 0x0. 3209 Cannot access memory at address 0x0.
3200 3210
3201 3211
3202 3212
3203 3213
3204 That's not very useful, so I'll try a more manual method: 3214 That's not very useful, so I'll try a more manual method:
3205 3215
3206 3216
3207 (gdb) p *((struct sigcontext *) (&sig + 1)) 3217 (gdb) p *((struct sigcontext *) (&sig + 1))
3208 $19 = {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, 3218 $19 = {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43,
3209 __dsh = 0, edi = 1342179328, esi = 1350378548, ebp = 1342630440, 3219 __dsh = 0, edi = 1342179328, esi = 1350378548, ebp = 1342630440,
3210 esp = 1342630420, ebx = 1348150624, edx = 1280, ecx = 0, eax = 0, 3220 esp = 1342630420, ebx = 1348150624, edx = 1280, ecx = 0, eax = 0,
3211 trapno = 14, err = 4, eip = 268480945, cs = 35, __csh = 0, eflags = 66118, 3221 trapno = 14, err = 4, eip = 268480945, cs = 35, __csh = 0, eflags = 66118,
3212 esp_at_signal = 1342630420, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, 3222 esp_at_signal = 1342630420, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0,
3213 cr2 = 1280} 3223 cr2 = 1280}
3214 3224
3215 3225
3216 3226
3217 The ip is in handle_mm_fault: 3227 The ip is in handle_mm_fault:
3218 3228
3219 3229
3220 (gdb) p (void *)268480945 3230 (gdb) p (void *)268480945
3221 $20 = (void *) 0x1000b1b1 3231 $20 = (void *) 0x1000b1b1
3222 (gdb) i sym $20 3232 (gdb) i sym $20
3223 handle_mm_fault + 57 in section .text 3233 handle_mm_fault + 57 in section .text
3224 3234
3225 3235
3226 3236
3227 3237
3228 3238
3229 Specifically, it's in pte_alloc: 3239 Specifically, it's in pte_alloc:
3230 3240
3231 3241
3232 (gdb) i line *$20 3242 (gdb) i line *$20
3233 Line 124 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3243 Line 124 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3234 starts at address 0x1000b1b1 <handle_mm_fault+57> 3244 starts at address 0x1000b1b1 <handle_mm_fault+57>
3235 and ends at 0x1000b1b7 <handle_mm_fault+63>. 3245 and ends at 0x1000b1b7 <handle_mm_fault+63>.
3236 3246
3237 3247
3238 3248
3239 3249
3240 3250
3241 To find where in handle_mm_fault this is, I'll jump forward in the 3251 To find where in handle_mm_fault this is, I'll jump forward in the
3242 code until I see an address in that procedure: 3252 code until I see an address in that procedure:
3243 3253
3244 3254
3245 3255
3246 (gdb) i line *0x1000b1c0 3256 (gdb) i line *0x1000b1c0
3247 Line 126 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3257 Line 126 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3248 starts at address 0x1000b1b7 <handle_mm_fault+63> 3258 starts at address 0x1000b1b7 <handle_mm_fault+63>
3249 and ends at 0x1000b1c3 <handle_mm_fault+75>. 3259 and ends at 0x1000b1c3 <handle_mm_fault+75>.
3250 (gdb) i line *0x1000b1d0 3260 (gdb) i line *0x1000b1d0
3251 Line 131 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3261 Line 131 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3252 starts at address 0x1000b1d0 <handle_mm_fault+88> 3262 starts at address 0x1000b1d0 <handle_mm_fault+88>
3253 and ends at 0x1000b1da <handle_mm_fault+98>. 3263 and ends at 0x1000b1da <handle_mm_fault+98>.
3254 (gdb) i line *0x1000b1e0 3264 (gdb) i line *0x1000b1e0
3255 Line 61 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3265 Line 61 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3256 starts at address 0x1000b1da <handle_mm_fault+98> 3266 starts at address 0x1000b1da <handle_mm_fault+98>
3257 and ends at 0x1000b1e1 <handle_mm_fault+105>. 3267 and ends at 0x1000b1e1 <handle_mm_fault+105>.
3258 (gdb) i line *0x1000b1f0 3268 (gdb) i line *0x1000b1f0
3259 Line 134 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3269 Line 134 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3260 starts at address 0x1000b1f0 <handle_mm_fault+120> 3270 starts at address 0x1000b1f0 <handle_mm_fault+120>
3261 and ends at 0x1000b200 <handle_mm_fault+136>. 3271 and ends at 0x1000b200 <handle_mm_fault+136>.
3262 (gdb) i line *0x1000b200 3272 (gdb) i line *0x1000b200
3263 Line 135 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3273 Line 135 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3264 starts at address 0x1000b200 <handle_mm_fault+136> 3274 starts at address 0x1000b200 <handle_mm_fault+136>
3265 and ends at 0x1000b208 <handle_mm_fault+144>. 3275 and ends at 0x1000b208 <handle_mm_fault+144>.
3266 (gdb) i line *0x1000b210 3276 (gdb) i line *0x1000b210
3267 Line 139 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h" 3277 Line 139 of "/home/dike/linux/2.3.26/um/include/asm/pgalloc.h"
3268 starts at address 0x1000b210 <handle_mm_fault+152> 3278 starts at address 0x1000b210 <handle_mm_fault+152>
3269 and ends at 0x1000b219 <handle_mm_fault+161>. 3279 and ends at 0x1000b219 <handle_mm_fault+161>.
3270 (gdb) i line *0x1000b220 3280 (gdb) i line *0x1000b220
3271 Line 1168 of "memory.c" starts at address 0x1000b21e <handle_mm_fault+166> 3281 Line 1168 of "memory.c" starts at address 0x1000b21e <handle_mm_fault+166>
3272 and ends at 0x1000b222 <handle_mm_fault+170>. 3282 and ends at 0x1000b222 <handle_mm_fault+170>.
3273 3283
3274 3284
3275 3285
3276 3286
3277 3287
3278 Something is apparently wrong with the page tables or vma_structs, so 3288 Something is apparently wrong with the page tables or vma_structs, so
3279 lets go back to frame 11 and have a look at them: 3289 lets go back to frame 11 and have a look at them:
3280 3290
3281 3291
3282 3292
3283 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50 3293 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50
3284 50 handle_mm_fault(current, vma, address, is_write); 3294 50 handle_mm_fault(current, vma, address, is_write);
3285 (gdb) call pgd_offset_proc(vma->vm_mm, address) 3295 (gdb) call pgd_offset_proc(vma->vm_mm, address)
3286 $22 = (pgd_t *) 0x80a548c 3296 $22 = (pgd_t *) 0x80a548c
3287 3297
3288 3298
3289 3299
3290 3300
3291 3301
3292 That's pretty bogus. Page tables aren't supposed to be in process 3302 That's pretty bogus. Page tables aren't supposed to be in process
3293 text or data areas. Let's see what's in the vma: 3303 text or data areas. Let's see what's in the vma:
3294 3304
3295 3305
3296 (gdb) p *vma 3306 (gdb) p *vma
3297 $23 = {vm_mm = 0x507d2434, vm_start = 0, vm_end = 134512640, 3307 $23 = {vm_mm = 0x507d2434, vm_start = 0, vm_end = 134512640,
3298 vm_next = 0x80a4f8c, vm_page_prot = {pgprot = 0}, vm_flags = 31200, 3308 vm_next = 0x80a4f8c, vm_page_prot = {pgprot = 0}, vm_flags = 31200,
3299 vm_avl_height = 2058, vm_avl_left = 0x80a8c94, vm_avl_right = 0x80d1000, 3309 vm_avl_height = 2058, vm_avl_left = 0x80a8c94, vm_avl_right = 0x80d1000,
3300 vm_next_share = 0xaffffdb0, vm_pprev_share = 0xaffffe63, 3310 vm_next_share = 0xaffffdb0, vm_pprev_share = 0xaffffe63,
3301 vm_ops = 0xaffffe7a, vm_pgoff = 2952789626, vm_file = 0xafffffec, 3311 vm_ops = 0xaffffe7a, vm_pgoff = 2952789626, vm_file = 0xafffffec,
3302 vm_private_data = 0x62} 3312 vm_private_data = 0x62}
3303 (gdb) p *vma.vm_mm 3313 (gdb) p *vma.vm_mm
3304 $24 = {mmap = 0x507d2434, mmap_avl = 0x0, mmap_cache = 0x8048000, 3314 $24 = {mmap = 0x507d2434, mmap_avl = 0x0, mmap_cache = 0x8048000,
3305 pgd = 0x80a4f8c, mm_users = {counter = 0}, mm_count = {counter = 134904288}, 3315 pgd = 0x80a4f8c, mm_users = {counter = 0}, mm_count = {counter = 134904288},
3306 map_count = 134909076, mmap_sem = {count = {counter = 135073792}, 3316 map_count = 134909076, mmap_sem = {count = {counter = 135073792},
3307 sleepers = -1342177872, wait = {lock = <optimized out or zero length>, 3317 sleepers = -1342177872, wait = {lock = <optimized out or zero length>,
3308 task_list = {next = 0xaffffe63, prev = 0xaffffe7a}, 3318 task_list = {next = 0xaffffe63, prev = 0xaffffe7a},
3309 __magic = -1342177670, __creator = -1342177300}, __magic = 98}, 3319 __magic = -1342177670, __creator = -1342177300}, __magic = 98},
3310 page_table_lock = {}, context = 138, start_code = 0, end_code = 0, 3320 page_table_lock = {}, context = 138, start_code = 0, end_code = 0,
3311 start_data = 0, end_data = 0, start_brk = 0, brk = 0, start_stack = 0, 3321 start_data = 0, end_data = 0, start_brk = 0, brk = 0, start_stack = 0,
3312 arg_start = 0, arg_end = 0, env_start = 0, env_end = 0, rss = 1350381536, 3322 arg_start = 0, arg_end = 0, env_start = 0, env_end = 0, rss = 1350381536,
3313 total_vm = 0, locked_vm = 0, def_flags = 0, cpu_vm_mask = 0, swap_cnt = 0, 3323 total_vm = 0, locked_vm = 0, def_flags = 0, cpu_vm_mask = 0, swap_cnt = 0,
3314 swap_address = 0, segments = 0x0} 3324 swap_address = 0, segments = 0x0}
3315 3325
3316 3326
3317 3327
3318 3328
3319 3329
3320 This also pretty bogus. With all of the 0x80xxxxx and 0xaffffxxx 3330 This also pretty bogus. With all of the 0x80xxxxx and 0xaffffxxx
3321 addresses, this is looking like a stack was plonked down on top of 3331 addresses, this is looking like a stack was plonked down on top of
3322 these structures. Maybe it's a stack overflow from the next page: 3332 these structures. Maybe it's a stack overflow from the next page:
3323 3333
3324 3334
3325 3335
3326 (gdb) p vma 3336 (gdb) p vma
3327 $25 = (struct vm_area_struct *) 0x507d2434 3337 $25 = (struct vm_area_struct *) 0x507d2434
3328 3338
3329 3339
3330 3340
3331 3341
3332 3342
3333 That's towards the lower quarter of the page, so that would have to 3343 That's towards the lower quarter of the page, so that would have to
3334 have been pretty heavy stack overflow: 3344 have been pretty heavy stack overflow:
3335 3345
3336 3346
3337 3347
3338 3348
3339 3349
3340 3350
3341 3351
3342 3352
3343 3353
3344 3354
3345 3355
3346 3356
3347 3357
3348 3358
3349 (gdb) x/100x $25 3359 (gdb) x/100x $25
3350 0x507d2434: 0x507d2434 0x00000000 0x08048000 0x080a4f8c 3360 0x507d2434: 0x507d2434 0x00000000 0x08048000 0x080a4f8c
3351 0x507d2444: 0x00000000 0x080a79e0 0x080a8c94 0x080d1000 3361 0x507d2444: 0x00000000 0x080a79e0 0x080a8c94 0x080d1000
3352 0x507d2454: 0xaffffdb0 0xaffffe63 0xaffffe7a 0xaffffe7a 3362 0x507d2454: 0xaffffdb0 0xaffffe63 0xaffffe7a 0xaffffe7a
3353 0x507d2464: 0xafffffec 0x00000062 0x0000008a 0x00000000 3363 0x507d2464: 0xafffffec 0x00000062 0x0000008a 0x00000000
3354 0x507d2474: 0x00000000 0x00000000 0x00000000 0x00000000 3364 0x507d2474: 0x00000000 0x00000000 0x00000000 0x00000000
3355 0x507d2484: 0x00000000 0x00000000 0x00000000 0x00000000 3365 0x507d2484: 0x00000000 0x00000000 0x00000000 0x00000000
3356 0x507d2494: 0x00000000 0x00000000 0x507d2fe0 0x00000000 3366 0x507d2494: 0x00000000 0x00000000 0x507d2fe0 0x00000000
3357 0x507d24a4: 0x00000000 0x00000000 0x00000000 0x00000000 3367 0x507d24a4: 0x00000000 0x00000000 0x00000000 0x00000000
3358 0x507d24b4: 0x00000000 0x00000000 0x00000000 0x00000000 3368 0x507d24b4: 0x00000000 0x00000000 0x00000000 0x00000000
3359 0x507d24c4: 0x00000000 0x00000000 0x00000000 0x00000000 3369 0x507d24c4: 0x00000000 0x00000000 0x00000000 0x00000000
3360 0x507d24d4: 0x00000000 0x00000000 0x00000000 0x00000000 3370 0x507d24d4: 0x00000000 0x00000000 0x00000000 0x00000000
3361 0x507d24e4: 0x00000000 0x00000000 0x00000000 0x00000000 3371 0x507d24e4: 0x00000000 0x00000000 0x00000000 0x00000000
3362 0x507d24f4: 0x00000000 0x00000000 0x00000000 0x00000000 3372 0x507d24f4: 0x00000000 0x00000000 0x00000000 0x00000000
3363 0x507d2504: 0x00000000 0x00000000 0x00000000 0x00000000 3373 0x507d2504: 0x00000000 0x00000000 0x00000000 0x00000000
3364 0x507d2514: 0x00000000 0x00000000 0x00000000 0x00000000 3374 0x507d2514: 0x00000000 0x00000000 0x00000000 0x00000000
3365 0x507d2524: 0x00000000 0x00000000 0x00000000 0x00000000 3375 0x507d2524: 0x00000000 0x00000000 0x00000000 0x00000000
3366 0x507d2534: 0x00000000 0x00000000 0x507d25dc 0x00000000 3376 0x507d2534: 0x00000000 0x00000000 0x507d25dc 0x00000000
3367 0x507d2544: 0x00000000 0x00000000 0x00000000 0x00000000 3377 0x507d2544: 0x00000000 0x00000000 0x00000000 0x00000000
3368 0x507d2554: 0x00000000 0x00000000 0x00000000 0x00000000 3378 0x507d2554: 0x00000000 0x00000000 0x00000000 0x00000000
3369 0x507d2564: 0x00000000 0x00000000 0x00000000 0x00000000 3379 0x507d2564: 0x00000000 0x00000000 0x00000000 0x00000000
3370 0x507d2574: 0x00000000 0x00000000 0x00000000 0x00000000 3380 0x507d2574: 0x00000000 0x00000000 0x00000000 0x00000000
3371 0x507d2584: 0x00000000 0x00000000 0x00000000 0x00000000 3381 0x507d2584: 0x00000000 0x00000000 0x00000000 0x00000000
3372 0x507d2594: 0x00000000 0x00000000 0x00000000 0x00000000 3382 0x507d2594: 0x00000000 0x00000000 0x00000000 0x00000000
3373 0x507d25a4: 0x00000000 0x00000000 0x00000000 0x00000000 3383 0x507d25a4: 0x00000000 0x00000000 0x00000000 0x00000000
3374 0x507d25b4: 0x00000000 0x00000000 0x00000000 0x00000000 3384 0x507d25b4: 0x00000000 0x00000000 0x00000000 0x00000000
3375 3385
3376 3386
3377 3387
3378 3388
3379 3389
3380 It's not stack overflow. The only "stack-like" piece of this data is 3390 It's not stack overflow. The only "stack-like" piece of this data is
3381 the vma_struct itself. 3391 the vma_struct itself.
3382 3392
3383 3393
3384 At this point, I don't see any avenues to pursue, so I just have to 3394 At this point, I don't see any avenues to pursue, so I just have to
3385 admit that I have no idea what's going on. What I will do, though, is 3395 admit that I have no idea what's going on. What I will do, though, is
3386 stick a trap on the segfault handler which will stop if it sees any 3396 stick a trap on the segfault handler which will stop if it sees any
3387 writes to the idle thread's stack. That was the thing that happened 3397 writes to the idle thread's stack. That was the thing that happened
3388 first, and it may be that if I can catch it immediately, what's going 3398 first, and it may be that if I can catch it immediately, what's going
3389 on will be somewhat clearer. 3399 on will be somewhat clearer.
3390 3400
3391 3401
3392 1122..22.. EEppiissooddee 22:: TThhee ccaassee ooff tthhee hhuunngg ffsscckk 3402 1122..22.. EEppiissooddee 22:: TThhee ccaassee ooff tthhee hhuunngg ffsscckk
3393 3403
3394 After setting a trap in the SEGV handler for accesses to the signal 3404 After setting a trap in the SEGV handler for accesses to the signal
3395 thread's stack, I reran the kernel. 3405 thread's stack, I reran the kernel.
3396 3406
3397 3407
3398 fsck hung again, this time by hitting the trap: 3408 fsck hung again, this time by hitting the trap:
3399 3409
3400 3410
3401 3411
3402 3412
3403 3413
3404 3414
3405 3415
3406 3416
3407 3417
3408 3418
3409 3419
3410 3420
3411 3421
3412 3422
3413 3423
3414 3424
3415 Setting hostname uml [ OK ] 3425 Setting hostname uml [ OK ]
3416 Checking root filesystem 3426 Checking root filesystem
3417 /dev/fhd0 contains a file system with errors, check forced. 3427 /dev/fhd0 contains a file system with errors, check forced.
3418 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. 3428 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780.
3419 3429
3420 /dev/fhd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. 3430 /dev/fhd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
3421 (i.e., without -a or -p options) 3431 (i.e., without -a or -p options)
3422 [ FAILED ] 3432 [ FAILED ]
3423 3433
3424 *** An error occurred during the file system check. 3434 *** An error occurred during the file system check.
3425 *** Dropping you to a shell; the system will reboot 3435 *** Dropping you to a shell; the system will reboot
3426 *** when you leave the shell. 3436 *** when you leave the shell.
3427 Give root password for maintenance 3437 Give root password for maintenance
3428 (or type Control-D for normal startup): 3438 (or type Control-D for normal startup):
3429 3439
3430 [root@uml /root]# fsck -y /dev/fhd0 3440 [root@uml /root]# fsck -y /dev/fhd0
3431 fsck -y /dev/fhd0 3441 fsck -y /dev/fhd0
3432 Parallelizing fsck version 1.14 (9-Jan-1999) 3442 Parallelizing fsck version 1.14 (9-Jan-1999)
3433 e2fsck 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 3443 e2fsck 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
3434 /dev/fhd0 contains a file system with errors, check forced. 3444 /dev/fhd0 contains a file system with errors, check forced.
3435 Pass 1: Checking inodes, blocks, and sizes 3445 Pass 1: Checking inodes, blocks, and sizes
3436 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. Ignore error? yes 3446 Error reading block 86894 (Attempt to read block from filesystem resulted in short read) while reading indirect blocks of inode 19780. Ignore error? yes
3437 3447
3438 Pass 2: Checking directory structure 3448 Pass 2: Checking directory structure
3439 Error reading block 49405 (Attempt to read block from filesystem resulted in short read). Ignore error? yes 3449 Error reading block 49405 (Attempt to read block from filesystem resulted in short read). Ignore error? yes
3440 3450
3441 Directory inode 11858, block 0, offset 0: directory corrupted 3451 Directory inode 11858, block 0, offset 0: directory corrupted
3442 Salvage? yes 3452 Salvage? yes
3443 3453
3444 Missing '.' in directory inode 11858. 3454 Missing '.' in directory inode 11858.
3445 Fix? yes 3455 Fix? yes
3446 3456
3447 Missing '..' in directory inode 11858. 3457 Missing '..' in directory inode 11858.
3448 Fix? yes 3458 Fix? yes
3449 3459
3450 Untested (4127) [100fe44c]: trap_kern.c line 31 3460 Untested (4127) [100fe44c]: trap_kern.c line 31
3451 3461
3452 3462
3453 3463
3454 3464
3455 3465
3456 I need to get the signal thread to detach from pid 4127 so that I can 3466 I need to get the signal thread to detach from pid 4127 so that I can
3457 attach to it with gdb. This is done by sending it a SIGUSR1, which is 3467 attach to it with gdb. This is done by sending it a SIGUSR1, which is
3458 caught by the signal thread, which detaches the process: 3468 caught by the signal thread, which detaches the process:
3459 3469
3460 3470
3461 kill -USR1 4127 3471 kill -USR1 4127
3462 3472
3463 3473
3464 3474
3465 3475
3466 3476
3467 Now I can run gdb on it: 3477 Now I can run gdb on it:
3468 3478
3469 3479
3470 3480
3471 3481
3472 3482
3473 3483
3474 3484
3475 3485
3476 3486
3477 3487
3478 3488
3479 3489
3480 3490
3481 ~/linux/2.3.26/um 1034: gdb linux 3491 ~/linux/2.3.26/um 1034: gdb linux
3482 GNU gdb 4.17.0.11 with Linux support 3492 GNU gdb 4.17.0.11 with Linux support
3483 Copyright 1998 Free Software Foundation, Inc. 3493 Copyright 1998 Free Software Foundation, Inc.
3484 GDB is free software, covered by the GNU General Public License, and you are 3494 GDB is free software, covered by the GNU General Public License, and you are
3485 welcome to change it and/or distribute copies of it under certain conditions. 3495 welcome to change it and/or distribute copies of it under certain conditions.
3486 Type "show copying" to see the conditions. 3496 Type "show copying" to see the conditions.
3487 There is absolutely no warranty for GDB. Type "show warranty" for details. 3497 There is absolutely no warranty for GDB. Type "show warranty" for details.
3488 This GDB was configured as "i386-redhat-linux"... 3498 This GDB was configured as "i386-redhat-linux"...
3489 (gdb) att 4127 3499 (gdb) att 4127
3490 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 4127 3500 Attaching to program `/home/dike/linux/2.3.26/um/linux', Pid 4127
3491 0x10075891 in __libc_nanosleep () 3501 0x10075891 in __libc_nanosleep ()
3492 3502
3493 3503
3494 3504
3495 3505
3496 3506
3497 The backtrace shows that it was in a write and that the fault address 3507 The backtrace shows that it was in a write and that the fault address
3498 (address in frame 3) is 0x50000800, which is right in the middle of 3508 (address in frame 3) is 0x50000800, which is right in the middle of
3499 the signal thread's stack page: 3509 the signal thread's stack page:
3500 3510
3501 3511
3502 (gdb) bt 3512 (gdb) bt
3503 #0 0x10075891 in __libc_nanosleep () 3513 #0 0x10075891 in __libc_nanosleep ()
3504 #1 0x1007584d in __sleep (seconds=1000000) 3514 #1 0x1007584d in __sleep (seconds=1000000)
3505 at ../sysdeps/unix/sysv/linux/sleep.c:78 3515 at ../sysdeps/unix/sysv/linux/sleep.c:78
3506 #2 0x1006ce9a in stop () at user_util.c:191 3516 #2 0x1006ce9a in stop () at user_util.c:191
3507 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31 3517 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31
3508 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174 3518 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3509 #5 0x1006c63c in kern_segv_handler (sig=11) at trap_user.c:182 3519 #5 0x1006c63c in kern_segv_handler (sig=11) at trap_user.c:182
3510 #6 <signal handler called> 3520 #6 <signal handler called>
3511 #7 0xc0fd in ?? () 3521 #7 0xc0fd in ?? ()
3512 #8 0x10016647 in sys_write (fd=3, buf=0x80b8800 "R.", count=1024) 3522 #8 0x10016647 in sys_write (fd=3, buf=0x80b8800 "R.", count=1024)
3513 at read_write.c:159 3523 at read_write.c:159
3514 #9 0x1006d603 in execute_syscall (syscall=4, args=0x5006ef08) 3524 #9 0x1006d603 in execute_syscall (syscall=4, args=0x5006ef08)
3515 at syscall_kern.c:254 3525 at syscall_kern.c:254
3516 #10 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35 3526 #10 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35
3517 #11 <signal handler called> 3527 #11 <signal handler called>
3518 #12 0x400dc8b0 in ?? () 3528 #12 0x400dc8b0 in ?? ()
3519 #13 <signal handler called> 3529 #13 <signal handler called>
3520 #14 0x400dc8b0 in ?? () 3530 #14 0x400dc8b0 in ?? ()
3521 #15 0x80545fd in ?? () 3531 #15 0x80545fd in ?? ()
3522 #16 0x804daae in ?? () 3532 #16 0x804daae in ?? ()
3523 #17 0x8054334 in ?? () 3533 #17 0x8054334 in ?? ()
3524 #18 0x804d23e in ?? () 3534 #18 0x804d23e in ?? ()
3525 #19 0x8049632 in ?? () 3535 #19 0x8049632 in ?? ()
3526 #20 0x80491d2 in ?? () 3536 #20 0x80491d2 in ?? ()
3527 #21 0x80596b5 in ?? () 3537 #21 0x80596b5 in ?? ()
3528 (gdb) p (void *)1342179328 3538 (gdb) p (void *)1342179328
3529 $3 = (void *) 0x50000800 3539 $3 = (void *) 0x50000800
3530 3540
3531 3541
3532 3542
3533 3543
3534 3544
3535 Going up the stack to the segv_handler frame and looking at where in 3545 Going up the stack to the segv_handler frame and looking at where in
3536 the code the access happened shows that it happened near line 110 of 3546 the code the access happened shows that it happened near line 110 of
3537 block_dev.c: 3547 block_dev.c:
3538 3548
3539 3549
3540 3550
3541 3551
3542 3552
3543 3553
3544 3554
3545 3555
3546 3556
3547 (gdb) up 3557 (gdb) up
3548 #1 0x1007584d in __sleep (seconds=1000000) 3558 #1 0x1007584d in __sleep (seconds=1000000)
3549 at ../sysdeps/unix/sysv/linux/sleep.c:78 3559 at ../sysdeps/unix/sysv/linux/sleep.c:78
3550 ../sysdeps/unix/sysv/linux/sleep.c:78: No such file or directory. 3560 ../sysdeps/unix/sysv/linux/sleep.c:78: No such file or directory.
3551 (gdb) 3561 (gdb)
3552 #2 0x1006ce9a in stop () at user_util.c:191 3562 #2 0x1006ce9a in stop () at user_util.c:191
3553 191 while(1) sleep(1000000); 3563 191 while(1) sleep(1000000);
3554 (gdb) 3564 (gdb)
3555 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31 3565 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31
3556 31 KERN_UNTESTED(); 3566 31 KERN_UNTESTED();
3557 (gdb) 3567 (gdb)
3558 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174 3568 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3559 174 segv(sc->cr2, sc->err & 2); 3569 174 segv(sc->cr2, sc->err & 2);
3560 (gdb) p *sc 3570 (gdb) p *sc
3561 $1 = {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, 3571 $1 = {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43,
3562 __dsh = 0, edi = 1342179328, esi = 134973440, ebp = 1342631484, 3572 __dsh = 0, edi = 1342179328, esi = 134973440, ebp = 1342631484,
3563 esp = 1342630864, ebx = 256, edx = 0, ecx = 256, eax = 1024, trapno = 14, 3573 esp = 1342630864, ebx = 256, edx = 0, ecx = 256, eax = 1024, trapno = 14,
3564 err = 6, eip = 268550834, cs = 35, __csh = 0, eflags = 66070, 3574 err = 6, eip = 268550834, cs = 35, __csh = 0, eflags = 66070,
3565 esp_at_signal = 1342630864, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, 3575 esp_at_signal = 1342630864, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0,
3566 cr2 = 1342179328} 3576 cr2 = 1342179328}
3567 (gdb) p (void *)268550834 3577 (gdb) p (void *)268550834
3568 $2 = (void *) 0x1001c2b2 3578 $2 = (void *) 0x1001c2b2
3569 (gdb) i sym $2 3579 (gdb) i sym $2
3570 block_write + 1090 in section .text 3580 block_write + 1090 in section .text
3571 (gdb) i line *$2 3581 (gdb) i line *$2
3572 Line 209 of "/home/dike/linux/2.3.26/um/include/asm/arch/string.h" 3582 Line 209 of "/home/dike/linux/2.3.26/um/include/asm/arch/string.h"
3573 starts at address 0x1001c2a1 <block_write+1073> 3583 starts at address 0x1001c2a1 <block_write+1073>
3574 and ends at 0x1001c2bf <block_write+1103>. 3584 and ends at 0x1001c2bf <block_write+1103>.
3575 (gdb) i line *0x1001c2c0 3585 (gdb) i line *0x1001c2c0
3576 Line 110 of "block_dev.c" starts at address 0x1001c2bf <block_write+1103> 3586 Line 110 of "block_dev.c" starts at address 0x1001c2bf <block_write+1103>
3577 and ends at 0x1001c2e3 <block_write+1139>. 3587 and ends at 0x1001c2e3 <block_write+1139>.
3578 3588
3579 3589
3580 3590
3581 3591
3582 3592
3583 Looking at the source shows that the fault happened during a call to 3593 Looking at the source shows that the fault happened during a call to
3584 copy_to_user to copy the data into the kernel: 3594 copy_to_user to copy the data into the kernel:
3585 3595
3586 3596
3587 107 count -= chars; 3597 107 count -= chars;
3588 108 copy_from_user(p,buf,chars); 3598 108 copy_from_user(p,buf,chars);
3589 109 p += chars; 3599 109 p += chars;
3590 110 buf += chars; 3600 110 buf += chars;
3591 3601
3592 3602
3593 3603
3594 3604
3595 3605
3596 p is the pointer which must contain 0x50000800, since buf contains 3606 p is the pointer which must contain 0x50000800, since buf contains
3597 0x80b8800 (frame 8 above). It is defined as: 3607 0x80b8800 (frame 8 above). It is defined as:
3598 3608
3599 3609
3600 p = offset + bh->b_data; 3610 p = offset + bh->b_data;
3601 3611
3602 3612
3603 3613
3604 3614
3605 3615
3606 I need to figure out what bh is, and it just so happens that bh is 3616 I need to figure out what bh is, and it just so happens that bh is
3607 passed as an argument to mark_buffer_uptodate and mark_buffer_dirty a 3617 passed as an argument to mark_buffer_uptodate and mark_buffer_dirty a
3608 few lines later, so I do a little disassembly: 3618 few lines later, so I do a little disassembly:
3609 3619
3610 3620
3611 3621
3612 3622
3613 (gdb) disas 0x1001c2bf 0x1001c2e0 3623 (gdb) disas 0x1001c2bf 0x1001c2e0
3614 Dump of assembler code from 0x1001c2bf to 0x1001c2d0: 3624 Dump of assembler code from 0x1001c2bf to 0x1001c2d0:
3615 0x1001c2bf <block_write+1103>: addl %eax,0xc(%ebp) 3625 0x1001c2bf <block_write+1103>: addl %eax,0xc(%ebp)
3616 0x1001c2c2 <block_write+1106>: movl 0xfffffdd4(%ebp),%edx 3626 0x1001c2c2 <block_write+1106>: movl 0xfffffdd4(%ebp),%edx
3617 0x1001c2c8 <block_write+1112>: btsl $0x0,0x18(%edx) 3627 0x1001c2c8 <block_write+1112>: btsl $0x0,0x18(%edx)
3618 0x1001c2cd <block_write+1117>: btsl $0x1,0x18(%edx) 3628 0x1001c2cd <block_write+1117>: btsl $0x1,0x18(%edx)
3619 0x1001c2d2 <block_write+1122>: sbbl %ecx,%ecx 3629 0x1001c2d2 <block_write+1122>: sbbl %ecx,%ecx
3620 0x1001c2d4 <block_write+1124>: testl %ecx,%ecx 3630 0x1001c2d4 <block_write+1124>: testl %ecx,%ecx
3621 0x1001c2d6 <block_write+1126>: jne 0x1001c2e3 <block_write+1139> 3631 0x1001c2d6 <block_write+1126>: jne 0x1001c2e3 <block_write+1139>
3622 0x1001c2d8 <block_write+1128>: pushl $0x0 3632 0x1001c2d8 <block_write+1128>: pushl $0x0
3623 0x1001c2da <block_write+1130>: pushl %edx 3633 0x1001c2da <block_write+1130>: pushl %edx
3624 0x1001c2db <block_write+1131>: call 0x1001819c <__mark_buffer_dirty> 3634 0x1001c2db <block_write+1131>: call 0x1001819c <__mark_buffer_dirty>
3625 End of assembler dump. 3635 End of assembler dump.
3626 3636
3627 3637
3628 3638
3629 3639
3630 3640
3631 At that point, bh is in %edx (address 0x1001c2da), which is calculated 3641 At that point, bh is in %edx (address 0x1001c2da), which is calculated
3632 at 0x1001c2c2 as %ebp + 0xfffffdd4, so I figure exactly what that is, 3642 at 0x1001c2c2 as %ebp + 0xfffffdd4, so I figure exactly what that is,
3633 taking %ebp from the sigcontext_struct above: 3643 taking %ebp from the sigcontext_struct above:
3634 3644
3635 3645
3636 (gdb) p (void *)1342631484 3646 (gdb) p (void *)1342631484
3637 $5 = (void *) 0x5006ee3c 3647 $5 = (void *) 0x5006ee3c
3638 (gdb) p 0x5006ee3c+0xfffffdd4 3648 (gdb) p 0x5006ee3c+0xfffffdd4
3639 $6 = 1342630928 3649 $6 = 1342630928
3640 (gdb) p (void *)$6 3650 (gdb) p (void *)$6
3641 $7 = (void *) 0x5006ec10 3651 $7 = (void *) 0x5006ec10
3642 (gdb) p *((void **)$7) 3652 (gdb) p *((void **)$7)
3643 $8 = (void *) 0x50100200 3653 $8 = (void *) 0x50100200
3644 3654
3645 3655
3646 3656
3647 3657
3648 3658
3649 Now, I look at the structure to see what's in it, and particularly, 3659 Now, I look at the structure to see what's in it, and particularly,
3650 what its b_data field contains: 3660 what its b_data field contains:
3651 3661
3652 3662
3653 (gdb) p *((struct buffer_head *)0x50100200) 3663 (gdb) p *((struct buffer_head *)0x50100200)
3654 $13 = {b_next = 0x50289380, b_blocknr = 49405, b_size = 1024, b_list = 0, 3664 $13 = {b_next = 0x50289380, b_blocknr = 49405, b_size = 1024, b_list = 0,
3655 b_dev = 15872, b_count = {counter = 1}, b_rdev = 15872, b_state = 24, 3665 b_dev = 15872, b_count = {counter = 1}, b_rdev = 15872, b_state = 24,
3656 b_flushtime = 0, b_next_free = 0x501001a0, b_prev_free = 0x50100260, 3666 b_flushtime = 0, b_next_free = 0x501001a0, b_prev_free = 0x50100260,
3657 b_this_page = 0x501001a0, b_reqnext = 0x0, b_pprev = 0x507fcf58, 3667 b_this_page = 0x501001a0, b_reqnext = 0x0, b_pprev = 0x507fcf58,
3658 b_data = 0x50000800 "", b_page = 0x50004000, 3668 b_data = 0x50000800 "", b_page = 0x50004000,
3659 b_end_io = 0x10017f60 <end_buffer_io_sync>, b_dev_id = 0x0, 3669 b_end_io = 0x10017f60 <end_buffer_io_sync>, b_dev_id = 0x0,
3660 b_rsector = 98810, b_wait = {lock = <optimized out or zero length>, 3670 b_rsector = 98810, b_wait = {lock = <optimized out or zero length>,
3661 task_list = {next = 0x50100248, prev = 0x50100248}, __magic = 1343226448, 3671 task_list = {next = 0x50100248, prev = 0x50100248}, __magic = 1343226448,
3662 __creator = 0}, b_kiobuf = 0x0} 3672 __creator = 0}, b_kiobuf = 0x0}
3663 3673
3664 3674
3665 3675
3666 3676
3667 3677
3668 The b_data field is indeed 0x50000800, so the question becomes how 3678 The b_data field is indeed 0x50000800, so the question becomes how
3669 that happened. The rest of the structure looks fine, so this probably 3679 that happened. The rest of the structure looks fine, so this probably
3670 is not a case of data corruption. It happened on purpose somehow. 3680 is not a case of data corruption. It happened on purpose somehow.
3671 3681
3672 3682
3673 The b_page field is a pointer to the page_struct representing the 3683 The b_page field is a pointer to the page_struct representing the
3674 0x50000000 page. Looking at it shows the kernel's idea of the state 3684 0x50000000 page. Looking at it shows the kernel's idea of the state
3675 of that page: 3685 of that page:
3676 3686
3677 3687
3678 3688
3679 (gdb) p *$13.b_page 3689 (gdb) p *$13.b_page
3680 $17 = {list = {next = 0x50004a5c, prev = 0x100c5174}, mapping = 0x0, 3690 $17 = {list = {next = 0x50004a5c, prev = 0x100c5174}, mapping = 0x0,
3681 index = 0, next_hash = 0x0, count = {counter = 1}, flags = 132, lru = { 3691 index = 0, next_hash = 0x0, count = {counter = 1}, flags = 132, lru = {
3682 next = 0x50008460, prev = 0x50019350}, wait = { 3692 next = 0x50008460, prev = 0x50019350}, wait = {
3683 lock = <optimized out or zero length>, task_list = {next = 0x50004024, 3693 lock = <optimized out or zero length>, task_list = {next = 0x50004024,
3684 prev = 0x50004024}, __magic = 1342193708, __creator = 0}, 3694 prev = 0x50004024}, __magic = 1342193708, __creator = 0},
3685 pprev_hash = 0x0, buffers = 0x501002c0, virtual = 1342177280, 3695 pprev_hash = 0x0, buffers = 0x501002c0, virtual = 1342177280,
3686 zone = 0x100c5160} 3696 zone = 0x100c5160}
3687 3697
3688 3698
3689 3699
3690 3700
3691 3701
3692 Some sanity-checking: the virtual field shows the "virtual" address of 3702 Some sanity-checking: the virtual field shows the "virtual" address of
3693 this page, which in this kernel is the same as its "physical" address, 3703 this page, which in this kernel is the same as its "physical" address,
3694 and the page_struct itself should be mem_map[0], since it represents 3704 and the page_struct itself should be mem_map[0], since it represents
3695 the first page of memory: 3705 the first page of memory:
3696 3706
3697 3707
3698 3708
3699 (gdb) p (void *)1342177280 3709 (gdb) p (void *)1342177280
3700 $18 = (void *) 0x50000000 3710 $18 = (void *) 0x50000000
3701 (gdb) p mem_map 3711 (gdb) p mem_map
3702 $19 = (mem_map_t *) 0x50004000 3712 $19 = (mem_map_t *) 0x50004000
3703 3713
3704 3714
3705 3715
3706 3716
3707 3717
3708 These check out fine. 3718 These check out fine.
3709 3719
3710 3720
3711 Now to check out the page_struct itself. In particular, the flags 3721 Now to check out the page_struct itself. In particular, the flags
3712 field shows whether the page is considered free or not: 3722 field shows whether the page is considered free or not:
3713 3723
3714 3724
3715 (gdb) p (void *)132 3725 (gdb) p (void *)132
3716 $21 = (void *) 0x84 3726 $21 = (void *) 0x84
3717 3727
3718 3728
3719 3729
3720 3730
3721 3731
3722 The "reserved" bit is the high bit, which is definitely not set, so 3732 The "reserved" bit is the high bit, which is definitely not set, so
3723 the kernel considers the signal stack page to be free and available to 3733 the kernel considers the signal stack page to be free and available to
3724 be used. 3734 be used.
3725 3735
3726 3736
3727 At this point, I jump to conclusions and start looking at my early 3737 At this point, I jump to conclusions and start looking at my early
3728 boot code, because that's where that page is supposed to be reserved. 3738 boot code, because that's where that page is supposed to be reserved.
3729 3739
3730 3740
3731 In my setup_arch procedure, I have the following code which looks just 3741 In my setup_arch procedure, I have the following code which looks just
3732 fine: 3742 fine:
3733 3743
3734 3744
3735 3745
3736 bootmap_size = init_bootmem(start_pfn, end_pfn - start_pfn); 3746 bootmap_size = init_bootmem(start_pfn, end_pfn - start_pfn);
3737 free_bootmem(__pa(low_physmem) + bootmap_size, high_physmem - low_physmem); 3747 free_bootmem(__pa(low_physmem) + bootmap_size, high_physmem - low_physmem);
3738 3748
3739 3749
3740 3750
3741 3751
3742 3752
3743 Two stack pages have already been allocated, and low_physmem points to 3753 Two stack pages have already been allocated, and low_physmem points to
3744 the third page, which is the beginning of free memory. 3754 the third page, which is the beginning of free memory.
3745 The init_bootmem call declares the entire memory to the boot memory 3755 The init_bootmem call declares the entire memory to the boot memory
3746 manager, which marks it all reserved. The free_bootmem call frees up 3756 manager, which marks it all reserved. The free_bootmem call frees up
3747 all of it, except for the first two pages. This looks correct to me. 3757 all of it, except for the first two pages. This looks correct to me.
3748 3758
3749 3759
3750 So, I decide to see init_bootmem run and make sure that it is marking 3760 So, I decide to see init_bootmem run and make sure that it is marking
3751 those first two pages as reserved. I never get that far. 3761 those first two pages as reserved. I never get that far.
3752 3762
3753 3763
3754 Stepping into init_bootmem, and looking at bootmem_map before looking 3764 Stepping into init_bootmem, and looking at bootmem_map before looking
3755 at what it contains shows the following: 3765 at what it contains shows the following:
3756 3766
3757 3767
3758 3768
3759 (gdb) p bootmem_map 3769 (gdb) p bootmem_map
3760 $3 = (void *) 0x50000000 3770 $3 = (void *) 0x50000000
3761 3771
3762 3772
3763 3773
3764 3774
3765 3775
3766 Aha! The light dawns. That first page is doing double duty as a 3776 Aha! The light dawns. That first page is doing double duty as a
3767 stack and as the boot memory map. The last thing that the boot memory 3777 stack and as the boot memory map. The last thing that the boot memory
3768 manager does is to free the pages used by its memory map, so this page 3778 manager does is to free the pages used by its memory map, so this page
3769 is getting freed even its marked as reserved. 3779 is getting freed even its marked as reserved.
3770 3780
3771 3781
3772 The fix was to initialize the boot memory manager before allocating 3782 The fix was to initialize the boot memory manager before allocating
3773 those two stack pages, and then allocate them through the boot memory 3783 those two stack pages, and then allocate them through the boot memory
3774 manager. After doing this, and fixing a couple of subsequent buglets, 3784 manager. After doing this, and fixing a couple of subsequent buglets,
3775 the stack corruption problem disappeared. 3785 the stack corruption problem disappeared.
3776 3786
3777 3787
3778 3788
3779 3789
3780 3790
3781 1133.. WWhhaatt ttoo ddoo wwhheenn UUMMLL ddooeessnn''tt wwoorrkk 3791 1133.. WWhhaatt ttoo ddoo wwhheenn UUMMLL ddooeessnn''tt wwoorrkk
3782 3792
3783 3793
3784 3794
3785 3795
3786 1133..11.. SSttrraannggee ccoommppiillaattiioonn eerrrroorrss wwhheenn yyoouu bbuuiilldd ffrroomm ssoouurrccee 3796 1133..11.. SSttrraannggee ccoommppiillaattiioonn eerrrroorrss wwhheenn yyoouu bbuuiilldd ffrroomm ssoouurrccee
3787 3797
3788 As of test11, it is necessary to have "ARCH=um" in the environment or 3798 As of test11, it is necessary to have "ARCH=um" in the environment or
3789 on the make command line for all steps in building UML, including 3799 on the make command line for all steps in building UML, including
3790 clean, distclean, or mrproper, config, menuconfig, or xconfig, dep, 3800 clean, distclean, or mrproper, config, menuconfig, or xconfig, dep,
3791 and linux. If you forget for any of them, the i386 build seems to 3801 and linux. If you forget for any of them, the i386 build seems to
3792 contaminate the UML build. If this happens, start from scratch with 3802 contaminate the UML build. If this happens, start from scratch with
3793 3803
3794 3804
3795 host% 3805 host%
3796 make mrproper ARCH=um 3806 make mrproper ARCH=um
3797 3807
3798 3808
3799 3809
3800 3810
3801 and repeat the build process with ARCH=um on all the steps. 3811 and repeat the build process with ARCH=um on all the steps.
3802 3812
3803 3813
3804 See ``Compiling the kernel and modules'' for more details. 3814 See ``Compiling the kernel and modules'' for more details.
3805 3815
3806 3816
3807 Another cause of strange compilation errors is building UML in 3817 Another cause of strange compilation errors is building UML in
3808 /usr/src/linux. If you do this, the first thing you need to do is 3818 /usr/src/linux. If you do this, the first thing you need to do is
3809 clean up the mess you made. The /usr/src/linux/asm link will now 3819 clean up the mess you made. The /usr/src/linux/asm link will now
3810 point to /usr/src/linux/asm-um. Make it point back to 3820 point to /usr/src/linux/asm-um. Make it point back to
3811 /usr/src/linux/asm-i386. Then, move your UML pool someplace else and 3821 /usr/src/linux/asm-i386. Then, move your UML pool someplace else and
3812 build it there. Also see below, where a more specific set of symptoms 3822 build it there. Also see below, where a more specific set of symptoms
3813 is described. 3823 is described.
3814 3824
3815 3825
3816 3826
3817 1133..33.. AA vvaarriieettyy ooff ppaanniiccss aanndd hhaannggss wwiitthh //ttmmpp oonn aa rreeiisseerrffss ffiilleessyyss-- 3827 1133..33.. AA vvaarriieettyy ooff ppaanniiccss aanndd hhaannggss wwiitthh //ttmmpp oonn aa rreeiisseerrffss ffiilleessyyss--
3818 tteemm 3828 tteemm
3819 3829
3820 I saw this on reiserfs 3.5.21 and it seems to be fixed in 3.5.27. 3830 I saw this on reiserfs 3.5.21 and it seems to be fixed in 3.5.27.
3821 Panics preceded by 3831 Panics preceded by
3822 3832
3823 3833
3824 Detaching pid nnnn 3834 Detaching pid nnnn
3825 3835
3826 3836
3827 3837
3828 are diagnostic of this problem. This is a reiserfs bug which causes a 3838 are diagnostic of this problem. This is a reiserfs bug which causes a
3829 thread to occasionally read stale data from a mmapped page shared with 3839 thread to occasionally read stale data from a mmapped page shared with
3830 another thread. The fix is to upgrade the filesystem or to have /tmp 3840 another thread. The fix is to upgrade the filesystem or to have /tmp
3831 be an ext2 filesystem. 3841 be an ext2 filesystem.
3832 3842
3833 3843
3834 3844
3835 1133..44.. TThhee ccoommppiillee ffaaiillss wwiitthh eerrrroorrss aabboouutt ccoonnfflliiccttiinngg ttyyppeess ffoorr 3845 1133..44.. TThhee ccoommppiillee ffaaiillss wwiitthh eerrrroorrss aabboouutt ccoonnfflliiccttiinngg ttyyppeess ffoorr
3836 ''ooppeenn'',, ''dduupp'',, aanndd ''wwaaiittppiidd'' 3846 ''ooppeenn'',, ''dduupp'',, aanndd ''wwaaiittppiidd''
3837 3847
3838 This happens when you build in /usr/src/linux. The UML build makes 3848 This happens when you build in /usr/src/linux. The UML build makes
3839 the include/asm link point to include/asm-um. /usr/include/asm points 3849 the include/asm link point to include/asm-um. /usr/include/asm points
3840 to /usr/src/linux/include/asm, so when that link gets moved, files 3850 to /usr/src/linux/include/asm, so when that link gets moved, files
3841 which need to include the asm-i386 versions of headers get the 3851 which need to include the asm-i386 versions of headers get the
3842 incompatible asm-um versions. The fix is to move the include/asm link 3852 incompatible asm-um versions. The fix is to move the include/asm link
3843 back to include/asm-i386 and to do UML builds someplace else. 3853 back to include/asm-i386 and to do UML builds someplace else.
3844 3854
3845 3855
3846 3856
3847 1133..55.. UUMMLL ddooeessnn''tt wwoorrkk wwhheenn //ttmmpp iiss aann NNFFSS ffiilleessyysstteemm 3857 1133..55.. UUMMLL ddooeessnn''tt wwoorrkk wwhheenn //ttmmpp iiss aann NNFFSS ffiilleessyysstteemm
3848 3858
3849 This seems to be a similar situation with the ReiserFS problem above. 3859 This seems to be a similar situation with the ReiserFS problem above.
3850 Some versions of NFS seems not to handle mmap correctly, which UML 3860 Some versions of NFS seems not to handle mmap correctly, which UML
3851 depends on. The workaround is have /tmp be a non-NFS directory. 3861 depends on. The workaround is have /tmp be a non-NFS directory.
3852 3862
3853 3863
3854 1133..66.. UUMMLL hhaannggss oonn bboooott wwhheenn ccoommppiilleedd wwiitthh ggpprrooff ssuuppppoorrtt 3864 1133..66.. UUMMLL hhaannggss oonn bboooott wwhheenn ccoommppiilleedd wwiitthh ggpprrooff ssuuppppoorrtt
3855 3865
3856 If you build UML with gprof support and, early in the boot, it does 3866 If you build UML with gprof support and, early in the boot, it does
3857 this 3867 this
3858 3868
3859 3869
3860 kernel BUG at page_alloc.c:100! 3870 kernel BUG at page_alloc.c:100!
3861 3871
3862 3872
3863 3873
3864 3874
3865 you have a buggy gcc. You can work around the problem by removing 3875 you have a buggy gcc. You can work around the problem by removing
3866 UM_FASTCALL from CFLAGS in arch/um/Makefile-i386. This will open up 3876 UM_FASTCALL from CFLAGS in arch/um/Makefile-i386. This will open up
3867 another bug, but that one is fairly hard to reproduce. 3877 another bug, but that one is fairly hard to reproduce.
3868 3878
3869 3879
3870 3880
3871 1133..77.. ssyyssllooggdd ddiieess wwiitthh aa SSIIGGTTEERRMM oonn ssttaarrttuupp 3881 1133..77.. ssyyssllooggdd ddiieess wwiitthh aa SSIIGGTTEERRMM oonn ssttaarrttuupp
3872 3882
3873 The exact boot error depends on the distribution that you're booting, 3883 The exact boot error depends on the distribution that you're booting,
3874 but Debian produces this: 3884 but Debian produces this:
3875 3885
3876 3886
3877 /etc/rc2.d/S10sysklogd: line 49: 93 Terminated 3887 /etc/rc2.d/S10sysklogd: line 49: 93 Terminated
3878 start-stop-daemon --start --quiet --exec /sbin/syslogd -- $SYSLOGD 3888 start-stop-daemon --start --quiet --exec /sbin/syslogd -- $SYSLOGD
3879 3889
3880 3890
3881 3891
3882 3892
3883 This is a syslogd bug. There's a race between a parent process 3893 This is a syslogd bug. There's a race between a parent process
3884 installing a signal handler and its child sending the signal. See 3894 installing a signal handler and its child sending the signal. See
3885 this uml-devel post <http://www.geocrawler.com/lists/3/Source- 3895 this uml-devel post <http://www.geocrawler.com/lists/3/Source-
3886 Forge/709/0/6612801> for the details. 3896 Forge/709/0/6612801> for the details.
3887 3897
3888 3898
3889 3899
3890 1133..88.. TTUUNN//TTAAPP nneettwwoorrkkiinngg ddooeessnn''tt wwoorrkk oonn aa 22..44 hhoosstt 3900 1133..88.. TTUUNN//TTAAPP nneettwwoorrkkiinngg ddooeessnn''tt wwoorrkk oonn aa 22..44 hhoosstt
3891 3901
3892 There are a couple of problems which were 3902 There are a couple of problems which were
3893 <http://www.geocrawler.com/lists/3/SourceForge/597/0/> name="pointed 3903 <http://www.geocrawler.com/lists/3/SourceForge/597/0/> name="pointed
3894 out"> by Tim Robinson <timro at trkr dot net> 3904 out"> by Tim Robinson <timro at trkr dot net>
3895 3905
3896 +o It doesn't work on hosts running 2.4.7 (or thereabouts) or earlier. 3906 +o It doesn't work on hosts running 2.4.7 (or thereabouts) or earlier.
3897 The fix is to upgrade to something more recent and then read the 3907 The fix is to upgrade to something more recent and then read the
3898 next item. 3908 next item.
3899 3909
3900 +o If you see 3910 +o If you see
3901 3911
3902 3912
3903 File descriptor in bad state 3913 File descriptor in bad state
3904 3914
3905 3915
3906 3916
3907 when you bring up the device inside UML, you have a header mismatch 3917 when you bring up the device inside UML, you have a header mismatch
3908 between the original kernel and the upgraded one. Make /usr/src/linux 3918 between the original kernel and the upgraded one. Make /usr/src/linux
3909 point at the new headers. This will only be a problem if you build 3919 point at the new headers. This will only be a problem if you build
3910 uml_net yourself. 3920 uml_net yourself.
3911 3921
3912 3922
3913 3923
3914 1133..99.. YYoouu ccaann nneettwwoorrkk ttoo tthhee hhoosstt bbuutt nnoott ttoo ootthheerr mmaacchhiinneess oonn tthhee 3924 1133..99.. YYoouu ccaann nneettwwoorrkk ttoo tthhee hhoosstt bbuutt nnoott ttoo ootthheerr mmaacchhiinneess oonn tthhee
3915 nneett 3925 nneett
3916 3926
3917 If you can connect to the host, and the host can connect to UML, but 3927 If you can connect to the host, and the host can connect to UML, but
3918 you cannot connect to any other machines, then you may need to enable 3928 you cannot connect to any other machines, then you may need to enable
3919 IP Masquerading on the host. Usually this is only experienced when 3929 IP Masquerading on the host. Usually this is only experienced when
3920 using private IP addresses (192.168.x.x or 10.x.x.x) for host/UML 3930 using private IP addresses (192.168.x.x or 10.x.x.x) for host/UML
3921 networking, rather than the public address space that your host is 3931 networking, rather than the public address space that your host is
3922 connected to. UML does not enable IP Masquerading, so you will need 3932 connected to. UML does not enable IP Masquerading, so you will need
3923 to create a static rule to enable it: 3933 to create a static rule to enable it:
3924 3934
3925 3935
3926 host% 3936 host%
3927 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 3937 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
3928 3938
3929 3939
3930 3940
3931 3941
3932 Replace eth0 with the interface that you use to talk to the rest of 3942 Replace eth0 with the interface that you use to talk to the rest of
3933 the world. 3943 the world.
3934 3944
3935 3945
3936 Documentation on IP Masquerading, and SNAT, can be found at 3946 Documentation on IP Masquerading, and SNAT, can be found at
3937 www.netfilter.org <http://www.netfilter.org> . 3947 www.netfilter.org <http://www.netfilter.org> .
3938 3948
3939 3949
3940 If you can reach the local net, but not the outside Internet, then 3950 If you can reach the local net, but not the outside Internet, then
3941 that is usually a routing problem. The UML needs a default route: 3951 that is usually a routing problem. The UML needs a default route:
3942 3952
3943 3953
3944 UML# 3954 UML#
3945 route add default gw gateway IP 3955 route add default gw gateway IP
3946 3956
3947 3957
3948 3958
3949 3959
3950 The gateway IP can be any machine on the local net that knows how to 3960 The gateway IP can be any machine on the local net that knows how to
3951 reach the outside world. Usually, this is the host or the local net- 3961 reach the outside world. Usually, this is the host or the local net-
3952 work's gateway. 3962 work's gateway.
3953 3963
3954 3964
3955 Occasionally, we hear from someone who can reach some machines, but 3965 Occasionally, we hear from someone who can reach some machines, but
3956 not others on the same net, or who can reach some ports on other 3966 not others on the same net, or who can reach some ports on other
3957 machines, but not others. These are usually caused by strange 3967 machines, but not others. These are usually caused by strange
3958 firewalling somewhere between the UML and the other box. You track 3968 firewalling somewhere between the UML and the other box. You track
3959 this down by running tcpdump on every interface the packets travel 3969 this down by running tcpdump on every interface the packets travel
3960 over and see where they disappear. When you find a machine that takes 3970 over and see where they disappear. When you find a machine that takes
3961 the packets in, but does not send them onward, that's the culprit. 3971 the packets in, but does not send them onward, that's the culprit.
3962 3972
3963 3973
3964 3974
3965 1133..1100.. II hhaavvee nnoo rroooott aanndd II wwaanntt ttoo ssccrreeaamm 3975 1133..1100.. II hhaavvee nnoo rroooott aanndd II wwaanntt ttoo ssccrreeaamm
3966 3976
3967 Thanks to Birgit Wahlich for telling me about this strange one. It 3977 Thanks to Birgit Wahlich for telling me about this strange one. It
3968 turns out that there's a limit of six environment variables on the 3978 turns out that there's a limit of six environment variables on the
3969 kernel command line. When that limit is reached or exceeded, argument 3979 kernel command line. When that limit is reached or exceeded, argument
3970 processing stops, which means that the 'root=' argument that UML 3980 processing stops, which means that the 'root=' argument that UML
3971 usually adds is not seen. So, the filesystem has no idea what the 3981 usually adds is not seen. So, the filesystem has no idea what the
3972 root device is, so it panics. 3982 root device is, so it panics.
3973 3983
3974 3984
3975 The fix is to put less stuff on the command line. Glomming all your 3985 The fix is to put less stuff on the command line. Glomming all your
3976 setup variables into one is probably the best way to go. 3986 setup variables into one is probably the best way to go.
3977 3987
3978 3988
3979 3989
3980 1133..1111.. UUMMLL bbuuiilldd ccoonnfflliicctt bbeettwweeeenn ppttrraaccee..hh aanndd uuccoonntteexxtt..hh 3990 1133..1111.. UUMMLL bbuuiilldd ccoonnfflliicctt bbeettwweeeenn ppttrraaccee..hh aanndd uuccoonntteexxtt..hh
3981 3991
3982 On some older systems, /usr/include/asm/ptrace.h and 3992 On some older systems, /usr/include/asm/ptrace.h and
3983 /usr/include/sys/ucontext.h define the same names. So, when they're 3993 /usr/include/sys/ucontext.h define the same names. So, when they're
3984 included together, the defines from one completely mess up the parsing 3994 included together, the defines from one completely mess up the parsing
3985 of the other, producing errors like: 3995 of the other, producing errors like:
3986 /usr/include/sys/ucontext.h:47: parse error before 3996 /usr/include/sys/ucontext.h:47: parse error before
3987 `10' 3997 `10'
3988 3998
3989 3999
3990 4000
3991 4001
3992 plus a pile of warnings. 4002 plus a pile of warnings.
3993 4003
3994 4004
3995 This is a libc botch, which has since been fixed, and I don't see any 4005 This is a libc botch, which has since been fixed, and I don't see any
3996 way around it besides upgrading. 4006 way around it besides upgrading.
3997 4007
3998 4008
3999 4009
4000 1133..1122.. TThhee UUMMLL BBooggooMMiippss iiss eexxaaccttllyy hhaallff tthhee hhoosstt''ss BBooggooMMiippss 4010 1133..1122.. TThhee UUMMLL BBooggooMMiippss iiss eexxaaccttllyy hhaallff tthhee hhoosstt''ss BBooggooMMiippss
4001 4011
4002 On i386 kernels, there are two ways of running the loop that is used 4012 On i386 kernels, there are two ways of running the loop that is used
4003 to calculate the BogoMips rating, using the TSC if it's there or using 4013 to calculate the BogoMips rating, using the TSC if it's there or using
4004 a one-instruction loop. The TSC produces twice the BogoMips as the 4014 a one-instruction loop. The TSC produces twice the BogoMips as the
4005 loop. UML uses the loop, since it has nothing resembling a TSC, and 4015 loop. UML uses the loop, since it has nothing resembling a TSC, and
4006 will get almost exactly the same BogoMips as a host using the loop. 4016 will get almost exactly the same BogoMips as a host using the loop.
4007 However, on a host with a TSC, its BogoMips will be double the loop 4017 However, on a host with a TSC, its BogoMips will be double the loop
4008 BogoMips, and therefore double the UML BogoMips. 4018 BogoMips, and therefore double the UML BogoMips.
4009 4019
4010 4020
4011 4021
4012 1133..1133.. WWhheenn yyoouu rruunn UUMMLL,, iitt iimmmmeeddiiaatteellyy sseeggffaauullttss 4022 1133..1133.. WWhheenn yyoouu rruunn UUMMLL,, iitt iimmmmeeddiiaatteellyy sseeggffaauullttss
4013 4023
4014 If the host is configured with the 2G/2G address space split, that's 4024 If the host is configured with the 2G/2G address space split, that's
4015 why. See ``UML on 2G/2G hosts'' for the details on getting UML to 4025 why. See ``UML on 2G/2G hosts'' for the details on getting UML to
4016 run on your host. 4026 run on your host.
4017 4027
4018 4028
4019 4029
4020 1133..1144.. xxtteerrmmss aappppeeaarr,, tthheenn iimmmmeeddiiaatteellyy ddiissaappppeeaarr 4030 1133..1144.. xxtteerrmmss aappppeeaarr,, tthheenn iimmmmeeddiiaatteellyy ddiissaappppeeaarr
4021 4031
4022 If you're running an up to date kernel with an old release of 4032 If you're running an up to date kernel with an old release of
4023 uml_utilities, the port-helper program will not work properly, so 4033 uml_utilities, the port-helper program will not work properly, so
4024 xterms will exit straight after they appear. The solution is to 4034 xterms will exit straight after they appear. The solution is to
4025 upgrade to the latest release of uml_utilities. Usually this problem 4035 upgrade to the latest release of uml_utilities. Usually this problem
4026 occurs when you have installed a packaged release of UML then compiled 4036 occurs when you have installed a packaged release of UML then compiled
4027 your own development kernel without upgrading the uml_utilities from 4037 your own development kernel without upgrading the uml_utilities from
4028 the source distribution. 4038 the source distribution.
4029 4039
4030 4040
4031 4041
4032 1133..1155.. AAnnyy ootthheerr ppaanniicc,, hhaanngg,, oorr ssttrraannggee bbeehhaavviioorr 4042 1133..1155.. AAnnyy ootthheerr ppaanniicc,, hhaanngg,, oorr ssttrraannggee bbeehhaavviioorr
4033 4043
4034 If you're seeing truly strange behavior, such as hangs or panics that 4044 If you're seeing truly strange behavior, such as hangs or panics that
4035 happen in random places, or you try running the debugger to see what's 4045 happen in random places, or you try running the debugger to see what's
4036 happening and it acts strangely, then it could be a problem in the 4046 happening and it acts strangely, then it could be a problem in the
4037 host kernel. If you're not running a stock Linus or -ac kernel, then 4047 host kernel. If you're not running a stock Linus or -ac kernel, then
4038 try that. An early version of the preemption patch and a 2.4.10 SuSE 4048 try that. An early version of the preemption patch and a 2.4.10 SuSE
4039 kernel have caused very strange problems in UML. 4049 kernel have caused very strange problems in UML.
4040 4050
4041 4051
4042 Otherwise, let me know about it. Send a message to one of the UML 4052 Otherwise, let me know about it. Send a message to one of the UML
4043 mailing lists - either the developer list - user-mode-linux-devel at 4053 mailing lists - either the developer list - user-mode-linux-devel at
4044 lists dot sourceforge dot net (subscription info) or the user list - 4054 lists dot sourceforge dot net (subscription info) or the user list -
4045 user-mode-linux-user at lists dot sourceforge do net (subscription 4055 user-mode-linux-user at lists dot sourceforge do net (subscription
4046 info), whichever you prefer. Don't assume that everyone knows about 4056 info), whichever you prefer. Don't assume that everyone knows about
4047 it and that a fix is imminent. 4057 it and that a fix is imminent.
4048 4058
4049 4059
4050 If you want to be super-helpful, read ``Diagnosing Problems'' and 4060 If you want to be super-helpful, read ``Diagnosing Problems'' and
4051 follow the instructions contained therein. 4061 follow the instructions contained therein.
4052 1144.. DDiiaaggnnoossiinngg PPrroobblleemmss 4062 1144.. DDiiaaggnnoossiinngg PPrroobblleemmss
4053 4063
4054 4064
4055 If you get UML to crash, hang, or otherwise misbehave, you should 4065 If you get UML to crash, hang, or otherwise misbehave, you should
4056 report this on one of the project mailing lists, either the developer 4066 report this on one of the project mailing lists, either the developer
4057 list - user-mode-linux-devel at lists dot sourceforge dot net 4067 list - user-mode-linux-devel at lists dot sourceforge dot net
4058 (subscription info) or the user list - user-mode-linux-user at lists 4068 (subscription info) or the user list - user-mode-linux-user at lists
4059 dot sourceforge dot net (subscription info). When you do, it is 4069 dot sourceforge dot net (subscription info). When you do, it is
4060 likely that I will want more information. So, it would be helpful to 4070 likely that I will want more information. So, it would be helpful to
4061 read the stuff below, do whatever is applicable in your case, and 4071 read the stuff below, do whatever is applicable in your case, and
4062 report the results to the list. 4072 report the results to the list.
4063 4073
4064 4074
4065 For any diagnosis, you're going to need to build a debugging kernel. 4075 For any diagnosis, you're going to need to build a debugging kernel.
4066 The binaries from this site aren't debuggable. If you haven't done 4076 The binaries from this site aren't debuggable. If you haven't done
4067 this before, read about ``Compiling the kernel and modules'' and 4077 this before, read about ``Compiling the kernel and modules'' and
4068 ``Kernel debugging'' UML first. 4078 ``Kernel debugging'' UML first.
4069 4079
4070 4080
4071 1144..11.. CCaassee 11 :: NNoorrmmaall kkeerrnneell ppaanniiccss 4081 1144..11.. CCaassee 11 :: NNoorrmmaall kkeerrnneell ppaanniiccss
4072 4082
4073 The most common case is for a normal thread to panic. To debug this, 4083 The most common case is for a normal thread to panic. To debug this,
4074 you will need to run it under the debugger (add 'debug' to the command 4084 you will need to run it under the debugger (add 'debug' to the command
4075 line). An xterm will start up with gdb running inside it. Continue 4085 line). An xterm will start up with gdb running inside it. Continue
4076 it when it stops in start_kernel and make it crash. Now ^C gdb and 4086 it when it stops in start_kernel and make it crash. Now ^C gdb and
4077 4087
4078 4088
4079 If the panic was a "Kernel mode fault", then there will be a segv 4089 If the panic was a "Kernel mode fault", then there will be a segv
4080 frame on the stack and I'm going to want some more information. The 4090 frame on the stack and I'm going to want some more information. The
4081 stack might look something like this: 4091 stack might look something like this:
4082 4092
4083 4093
4084 (UML gdb) backtrace 4094 (UML gdb) backtrace
4085 #0 0x1009bf76 in __sigprocmask (how=1, set=0x5f347940, oset=0x0) 4095 #0 0x1009bf76 in __sigprocmask (how=1, set=0x5f347940, oset=0x0)
4086 at ../sysdeps/unix/sysv/linux/sigprocmask.c:49 4096 at ../sysdeps/unix/sysv/linux/sigprocmask.c:49
4087 #1 0x10091411 in change_sig (signal=10, on=1) at process.c:218 4097 #1 0x10091411 in change_sig (signal=10, on=1) at process.c:218
4088 #2 0x10094785 in timer_handler (sig=26) at time_kern.c:32 4098 #2 0x10094785 in timer_handler (sig=26) at time_kern.c:32
4089 #3 0x1009bf38 in __restore () 4099 #3 0x1009bf38 in __restore ()
4090 at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125 4100 at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125
4091 #4 0x1009534c in segv (address=8, ip=268849158, is_write=2, is_user=0) 4101 #4 0x1009534c in segv (address=8, ip=268849158, is_write=2, is_user=0)
4092 at trap_kern.c:66 4102 at trap_kern.c:66
4093 #5 0x10095c04 in segv_handler (sig=11) at trap_user.c:285 4103 #5 0x10095c04 in segv_handler (sig=11) at trap_user.c:285
4094 #6 0x1009bf38 in __restore () 4104 #6 0x1009bf38 in __restore ()
4095 4105
4096 4106
4097 4107
4098 4108
4099 I'm going to want to see the symbol and line information for the value 4109 I'm going to want to see the symbol and line information for the value
4100 of ip in the segv frame. In this case, you would do the following: 4110 of ip in the segv frame. In this case, you would do the following:
4101 4111
4102 4112
4103 (UML gdb) i sym 268849158 4113 (UML gdb) i sym 268849158
4104 4114
4105 4115
4106 4116
4107 4117
4108 and 4118 and
4109 4119
4110 4120
4111 (UML gdb) i line *268849158 4121 (UML gdb) i line *268849158
4112 4122
4113 4123
4114 4124
4115 4125
4116 The reason for this is the __restore frame right above the segv_han- 4126 The reason for this is the __restore frame right above the segv_han-
4117 dler frame is hiding the frame that actually segfaulted. So, I have 4127 dler frame is hiding the frame that actually segfaulted. So, I have
4118 to get that information from the faulting ip. 4128 to get that information from the faulting ip.
4119 4129
4120 4130
4121 1144..22.. CCaassee 22 :: TTrraacciinngg tthhrreeaadd ppaanniiccss 4131 1144..22.. CCaassee 22 :: TTrraacciinngg tthhrreeaadd ppaanniiccss
4122 4132
4123 The less common and more painful case is when the tracing thread 4133 The less common and more painful case is when the tracing thread
4124 panics. In this case, the kernel debugger will be useless because it 4134 panics. In this case, the kernel debugger will be useless because it
4125 needs a healthy tracing thread in order to work. The first thing to 4135 needs a healthy tracing thread in order to work. The first thing to
4126 do is get a backtrace from the tracing thread. This is done by 4136 do is get a backtrace from the tracing thread. This is done by
4127 figuring out what its pid is, firing up gdb, and attaching it to that 4137 figuring out what its pid is, firing up gdb, and attaching it to that
4128 pid. You can figure out the tracing thread pid by looking at the 4138 pid. You can figure out the tracing thread pid by looking at the
4129 first line of the console output, which will look like this: 4139 first line of the console output, which will look like this:
4130 4140
4131 4141
4132 tracing thread pid = 15851 4142 tracing thread pid = 15851
4133 4143
4134 4144
4135 4145
4136 4146
4137 or by running ps on the host and finding the line that looks like 4147 or by running ps on the host and finding the line that looks like
4138 this: 4148 this:
4139 4149
4140 4150
4141 jdike 15851 4.5 0.4 132568 1104 pts/0 S 21:34 0:05 ./linux [(tracing thread)] 4151 jdike 15851 4.5 0.4 132568 1104 pts/0 S 21:34 0:05 ./linux [(tracing thread)]
4142 4152
4143 4153
4144 4154
4145 4155
4146 If the panic was 'segfault in signals', then follow the instructions 4156 If the panic was 'segfault in signals', then follow the instructions
4147 above for collecting information about the location of the seg fault. 4157 above for collecting information about the location of the seg fault.
4148 4158
4149 4159
4150 If the tracing thread flaked out all by itself, then send that 4160 If the tracing thread flaked out all by itself, then send that
4151 backtrace in and wait for our crack debugging team to fix the problem. 4161 backtrace in and wait for our crack debugging team to fix the problem.
4152 4162
4153 4163
4154 1144..33.. CCaassee 33 :: TTrraacciinngg tthhrreeaadd ppaanniiccss ccaauusseedd bbyy ootthheerr tthhrreeaaddss 4164 1144..33.. CCaassee 33 :: TTrraacciinngg tthhrreeaadd ppaanniiccss ccaauusseedd bbyy ootthheerr tthhrreeaaddss
4155 4165
4156 However, there are cases where the misbehavior of another thread 4166 However, there are cases where the misbehavior of another thread
4157 caused the problem. The most common panic of this type is: 4167 caused the problem. The most common panic of this type is:
4158 4168
4159 4169
4160 wait_for_stop failed to wait for <pid> to stop with <signal number> 4170 wait_for_stop failed to wait for <pid> to stop with <signal number>
4161 4171
4162 4172
4163 4173
4164 4174
4165 In this case, you'll need to get a backtrace from the process men- 4175 In this case, you'll need to get a backtrace from the process men-
4166 tioned in the panic, which is complicated by the fact that the kernel 4176 tioned in the panic, which is complicated by the fact that the kernel
4167 debugger is defunct and without some fancy footwork, another gdb can't 4177 debugger is defunct and without some fancy footwork, another gdb can't
4168 attach to it. So, this is how the fancy footwork goes: 4178 attach to it. So, this is how the fancy footwork goes:
4169 4179
4170 In a shell: 4180 In a shell:
4171 4181
4172 4182
4173 host% kill -STOP pid 4183 host% kill -STOP pid
4174 4184
4175 4185
4176 4186
4177 4187
4178 Run gdb on the tracing thread as described in case 2 and do: 4188 Run gdb on the tracing thread as described in case 2 and do:
4179 4189
4180 4190
4181 (host gdb) call detach(pid) 4191 (host gdb) call detach(pid)
4182 4192
4183 4193
4184 If you get a segfault, do it again. It always works the second time. 4194 If you get a segfault, do it again. It always works the second time.
4185 4195
4186 Detach from the tracing thread and attach to that other thread: 4196 Detach from the tracing thread and attach to that other thread:
4187 4197
4188 4198
4189 (host gdb) detach 4199 (host gdb) detach
4190 4200
4191 4201
4192 4202
4193 4203
4194 4204
4195 4205
4196 (host gdb) attach pid 4206 (host gdb) attach pid
4197 4207
4198 4208
4199 4209
4200 4210
4201 If gdb hangs when attaching to that process, go back to a shell and 4211 If gdb hangs when attaching to that process, go back to a shell and
4202 do: 4212 do:
4203 4213
4204 4214
4205 host% 4215 host%
4206 kill -CONT pid 4216 kill -CONT pid
4207 4217
4208 4218
4209 4219
4210 4220
4211 And then get the backtrace: 4221 And then get the backtrace:
4212 4222
4213 4223
4214 (host gdb) backtrace 4224 (host gdb) backtrace
4215 4225
4216 4226
4217 4227
4218 4228
4219 4229
4220 1144..44.. CCaassee 44 :: HHaannggss 4230 1144..44.. CCaassee 44 :: HHaannggss
4221 4231
4222 Hangs seem to be fairly rare, but they sometimes happen. When a hang 4232 Hangs seem to be fairly rare, but they sometimes happen. When a hang
4223 happens, we need a backtrace from the offending process. Run the 4233 happens, we need a backtrace from the offending process. Run the
4224 kernel debugger as described in case 1 and get a backtrace. If the 4234 kernel debugger as described in case 1 and get a backtrace. If the
4225 current process is not the idle thread, then send in the backtrace. 4235 current process is not the idle thread, then send in the backtrace.
4226 You can tell that it's the idle thread if the stack looks like this: 4236 You can tell that it's the idle thread if the stack looks like this:
4227 4237
4228 4238
4229 #0 0x100b1401 in __libc_nanosleep () 4239 #0 0x100b1401 in __libc_nanosleep ()
4230 #1 0x100a2885 in idle_sleep (secs=10) at time.c:122 4240 #1 0x100a2885 in idle_sleep (secs=10) at time.c:122
4231 #2 0x100a546f in do_idle () at process_kern.c:445 4241 #2 0x100a546f in do_idle () at process_kern.c:445
4232 #3 0x100a5508 in cpu_idle () at process_kern.c:471 4242 #3 0x100a5508 in cpu_idle () at process_kern.c:471
4233 #4 0x100ec18f in start_kernel () at init/main.c:592 4243 #4 0x100ec18f in start_kernel () at init/main.c:592
4234 #5 0x100a3e10 in start_kernel_proc (unused=0x0) at um_arch.c:71 4244 #5 0x100a3e10 in start_kernel_proc (unused=0x0) at um_arch.c:71
4235 #6 0x100a383f in signal_tramp (arg=0x100a3dd8) at trap_user.c:50 4245 #6 0x100a383f in signal_tramp (arg=0x100a3dd8) at trap_user.c:50
4236 4246
4237 4247
4238 4248
4239 4249
4240 If this is the case, then some other process is at fault, and went to 4250 If this is the case, then some other process is at fault, and went to
4241 sleep when it shouldn't have. Run ps on the host and figure out which 4251 sleep when it shouldn't have. Run ps on the host and figure out which
4242 process should not have gone to sleep and stayed asleep. Then attach 4252 process should not have gone to sleep and stayed asleep. Then attach
4243 to it with gdb and get a backtrace as described in case 3. 4253 to it with gdb and get a backtrace as described in case 3.
4244 4254
4245 4255
4246 4256
4247 4257
4248 4258
4249 4259
4250 1155.. TThhaannkkss 4260 1155.. TThhaannkkss
4251 4261
4252 4262
4253 A number of people have helped this project in various ways, and this 4263 A number of people have helped this project in various ways, and this
4254 page gives recognition where recognition is due. 4264 page gives recognition where recognition is due.
4255 4265
4256 4266
4257 If you're listed here and you would prefer a real link on your name, 4267 If you're listed here and you would prefer a real link on your name,
4258 or no link at all, instead of the despammed email address pseudo-link, 4268 or no link at all, instead of the despammed email address pseudo-link,
4259 let me know. 4269 let me know.
4260 4270
4261 4271
4262 If you're not listed here and you think maybe you should be, please 4272 If you're not listed here and you think maybe you should be, please
4263 let me know that as well. I try to get everyone, but sometimes my 4273 let me know that as well. I try to get everyone, but sometimes my
4264 bookkeeping lapses and I forget about contributions. 4274 bookkeeping lapses and I forget about contributions.
4265 4275
4266 4276
4267 1155..11.. CCooddee aanndd DDooccuummeennttaattiioonn 4277 1155..11.. CCooddee aanndd DDooccuummeennttaattiioonn
4268 4278
4269 Rusty Russell <rusty at linuxcare.com.au> - 4279 Rusty Russell <rusty at linuxcare.com.au> -
4270 4280
4271 +o wrote the HOWTO <http://user-mode- 4281 +o wrote the HOWTO <http://user-mode-
4272 linux.sourceforge.net/UserModeLinux-HOWTO.html> 4282 linux.sourceforge.net/UserModeLinux-HOWTO.html>
4273 4283
4274 +o prodded me into making this project official and putting it on 4284 +o prodded me into making this project official and putting it on
4275 SourceForge 4285 SourceForge
4276 4286
4277 +o came up with the way cool UML logo <http://user-mode- 4287 +o came up with the way cool UML logo <http://user-mode-
4278 linux.sourceforge.net/uml-small.png> 4288 linux.sourceforge.net/uml-small.png>
4279 4289
4280 +o redid the config process 4290 +o redid the config process
4281 4291
4282 4292
4283 Peter Moulder <reiter at netspace.net.au> - Fixed my config and build 4293 Peter Moulder <reiter at netspace.net.au> - Fixed my config and build
4284 processes, and added some useful code to the block driver 4294 processes, and added some useful code to the block driver
4285 4295
4286 4296
4287 Bill Stearns <wstearns at pobox.com> - 4297 Bill Stearns <wstearns at pobox.com> -
4288 4298
4289 +o HOWTO updates 4299 +o HOWTO updates
4290 4300
4291 +o lots of bug reports 4301 +o lots of bug reports
4292 4302
4293 +o lots of testing 4303 +o lots of testing
4294 4304
4295 +o dedicated a box (uml.ists.dartmouth.edu) to support UML development 4305 +o dedicated a box (uml.ists.dartmouth.edu) to support UML development
4296 4306
4297 +o wrote the mkrootfs script, which allows bootable filesystems of 4307 +o wrote the mkrootfs script, which allows bootable filesystems of
4298 RPM-based distributions to be cranked out 4308 RPM-based distributions to be cranked out
4299 4309
4300 +o cranked out a large number of filesystems with said script 4310 +o cranked out a large number of filesystems with said script
4301 4311
4302 4312
4303 Jim Leu <jleu at mindspring.com> - Wrote the virtual ethernet driver 4313 Jim Leu <jleu at mindspring.com> - Wrote the virtual ethernet driver
4304 and associated usermode tools 4314 and associated usermode tools
4305 4315
4306 Lars Brinkhoff <http://lars.nocrew.org/> - Contributed the ptrace 4316 Lars Brinkhoff <http://lars.nocrew.org/> - Contributed the ptrace
4307 proxy from his own project <http://a386.nocrew.org/> to allow easier 4317 proxy from his own project <http://a386.nocrew.org/> to allow easier
4308 kernel debugging 4318 kernel debugging
4309 4319
4310 4320
4311 Andrea Arcangeli <andrea at suse.de> - Redid some of the early boot 4321 Andrea Arcangeli <andrea at suse.de> - Redid some of the early boot
4312 code so that it would work on machines with Large File Support 4322 code so that it would work on machines with Large File Support
4313 4323
4314 4324
4315 Chris Emerson <http://www.chiark.greenend.org.uk/~cemerson/> - Did 4325 Chris Emerson <http://www.chiark.greenend.org.uk/~cemerson/> - Did
4316 the first UML port to Linux/ppc 4326 the first UML port to Linux/ppc
4317 4327
4318 4328
4319 Harald Welte <laforge at gnumonks.org> - Wrote the multicast 4329 Harald Welte <laforge at gnumonks.org> - Wrote the multicast
4320 transport for the network driver 4330 transport for the network driver
4321 4331
4322 4332
4323 Jorgen Cederlof - Added special file support to hostfs 4333 Jorgen Cederlof - Added special file support to hostfs
4324 4334
4325 4335
4326 Greg Lonnon <glonnon at ridgerun dot com> - Changed the ubd driver 4336 Greg Lonnon <glonnon at ridgerun dot com> - Changed the ubd driver
4327 to allow it to layer a COW file on a shared read-only filesystem and 4337 to allow it to layer a COW file on a shared read-only filesystem and
4328 wrote the iomem emulation support 4338 wrote the iomem emulation support
4329 4339
4330 4340
4331 Henrik Nordstrom <http://hem.passagen.se/hno/> - Provided a variety 4341 Henrik Nordstrom <http://hem.passagen.se/hno/> - Provided a variety
4332 of patches, fixes, and clues 4342 of patches, fixes, and clues
4333 4343
4334 4344
4335 Lennert Buytenhek - Contributed various patches, a rewrite of the 4345 Lennert Buytenhek - Contributed various patches, a rewrite of the
4336 network driver, the first implementation of the mconsole driver, and 4346 network driver, the first implementation of the mconsole driver, and
4337 did the bulk of the work needed to get SMP working again. 4347 did the bulk of the work needed to get SMP working again.
4338 4348
4339 4349
4340 Yon Uriarte - Fixed the TUN/TAP network backend while I slept. 4350 Yon Uriarte - Fixed the TUN/TAP network backend while I slept.
4341 4351
4342 4352
4343 Adam Heath - Made a bunch of nice cleanups to the initialization code, 4353 Adam Heath - Made a bunch of nice cleanups to the initialization code,
4344 plus various other small patches. 4354 plus various other small patches.
4345 4355
4346 4356
4347 Matt Zimmerman - Matt volunteered to be the UML Debian maintainer and 4357 Matt Zimmerman - Matt volunteered to be the UML Debian maintainer and
4348 is doing a real nice job of it. He also noticed and fixed a number of 4358 is doing a real nice job of it. He also noticed and fixed a number of
4349 actually and potentially exploitable security holes in uml_net. Plus 4359 actually and potentially exploitable security holes in uml_net. Plus
4350 the occasional patch. I like patches. 4360 the occasional patch. I like patches.
4351 4361
4352 4362
4353 James McMechan - James seems to have taken over maintenance of the ubd 4363 James McMechan - James seems to have taken over maintenance of the ubd
4354 driver and is doing a nice job of it. 4364 driver and is doing a nice job of it.
4355 4365
4356 4366
4357 Chandan Kudige - wrote the umlgdb script which automates the reloading 4367 Chandan Kudige - wrote the umlgdb script which automates the reloading
4358 of module symbols. 4368 of module symbols.
4359 4369
4360 4370
4361 Steve Schmidtke - wrote the UML slirp transport and hostaudio drivers, 4371 Steve Schmidtke - wrote the UML slirp transport and hostaudio drivers,
4362 enabling UML processes to access audio devices on the host. He also 4372 enabling UML processes to access audio devices on the host. He also
4363 submitted patches for the slip transport and lots of other things. 4373 submitted patches for the slip transport and lots of other things.
4364 4374
4365 4375
4366 David Coulson <http://davidcoulson.net> - 4376 David Coulson <http://davidcoulson.net> -
4367 4377
4368 +o Set up the usermodelinux.org <http://usermodelinux.org> site, 4378 +o Set up the usermodelinux.org <http://usermodelinux.org> site,
4369 which is a great way of keeping the UML user community on top of 4379 which is a great way of keeping the UML user community on top of
4370 UML goings-on. 4380 UML goings-on.
4371 4381
4372 +o Site documentation and updates 4382 +o Site documentation and updates
4373 4383
4374 +o Nifty little UML management daemon UMLd 4384 +o Nifty little UML management daemon UMLd
4375 <http://uml.openconsultancy.com/umld/> 4385 <http://uml.openconsultancy.com/umld/>
4376 4386
4377 +o Lots of testing and bug reports 4387 +o Lots of testing and bug reports
4378 4388
4379 4389
4380 4390
4381 4391
4382 1155..22.. FFlluusshhiinngg oouutt bbuuggss 4392 1155..22.. FFlluusshhiinngg oouutt bbuuggss
4383 4393
4384 4394
4385 4395
4386 +o Yuri Pudgorodsky 4396 +o Yuri Pudgorodsky
4387 4397
4388 +o Gerald Britton 4398 +o Gerald Britton
4389 4399
4390 +o Ian Wehrman 4400 +o Ian Wehrman
4391 4401
4392 +o Gord Lamb 4402 +o Gord Lamb
4393 4403
4394 +o Eugene Koontz 4404 +o Eugene Koontz
4395 4405
4396 +o John H. Hartman 4406 +o John H. Hartman
4397 4407
4398 +o Anders Karlsson 4408 +o Anders Karlsson
4399 4409
4400 +o Daniel Phillips 4410 +o Daniel Phillips
4401 4411
4402 +o John Fremlin 4412 +o John Fremlin
4403 4413
4404 +o Rainer Burgstaller 4414 +o Rainer Burgstaller
4405 4415
4406 +o James Stevenson 4416 +o James Stevenson
4407 4417
4408 +o Matt Clay 4418 +o Matt Clay
4409 4419
4410 +o Cliff Jefferies 4420 +o Cliff Jefferies
4411 4421
4412 +o Geoff Hoff 4422 +o Geoff Hoff
4413 4423
4414 +o Lennert Buytenhek 4424 +o Lennert Buytenhek
4415 4425
4416 +o Al Viro 4426 +o Al Viro
4417 4427
4418 +o Frank Klingenhoefer 4428 +o Frank Klingenhoefer
4419 4429
4420 +o Livio Baldini Soares 4430 +o Livio Baldini Soares
4421 4431
4422 +o Jon Burgess 4432 +o Jon Burgess
4423 4433
4424 +o Petru Paler 4434 +o Petru Paler
4425 4435
4426 +o Paul 4436 +o Paul
4427 4437
4428 +o Chris Reahard 4438 +o Chris Reahard
4429 4439
4430 +o Sverker Nilsson 4440 +o Sverker Nilsson
4431 4441
4432 +o Gong Su 4442 +o Gong Su
4433 4443
4434 +o johan verrept 4444 +o johan verrept
4435 4445
4436 +o Bjorn Eriksson 4446 +o Bjorn Eriksson
4437 4447
4438 +o Lorenzo Allegrucci 4448 +o Lorenzo Allegrucci
4439 4449
4440 +o Muli Ben-Yehuda 4450 +o Muli Ben-Yehuda
4441 4451
4442 +o David Mansfield 4452 +o David Mansfield
4443 4453
4444 +o Howard Goff 4454 +o Howard Goff
4445 4455
4446 +o Mike Anderson 4456 +o Mike Anderson
4447 4457
4448 +o John Byrne 4458 +o John Byrne
4449 4459
4450 +o Sapan J. Batia 4460 +o Sapan J. Batia
4451 4461
4452 +o Iris Huang 4462 +o Iris Huang
4453 4463
4454 +o Jan Hudec 4464 +o Jan Hudec
4455 4465
4456 +o Voluspa 4466 +o Voluspa
4457 4467
4458 4468
4459 4469
4460 4470
4461 1155..33.. BBuugglleettss aanndd cclleeaann--uuppss 4471 1155..33.. BBuugglleettss aanndd cclleeaann--uuppss
4462 4472
4463 4473
4464 4474
4465 +o Dave Zarzycki 4475 +o Dave Zarzycki
4466 4476
4467 +o Adam Lazur 4477 +o Adam Lazur
4468 4478
4469 +o Boria Feigin 4479 +o Boria Feigin
4470 4480
4471 +o Brian J. Murrell 4481 +o Brian J. Murrell
4472 4482
4473 +o JS 4483 +o JS
4474 4484
4475 +o Roman Zippel 4485 +o Roman Zippel
4476 4486
4477 +o Wil Cooley 4487 +o Wil Cooley
4478 4488
4479 +o Ayelet Shemesh 4489 +o Ayelet Shemesh
4480 4490
4481 +o Will Dyson 4491 +o Will Dyson
4482 4492
4483 +o Sverker Nilsson 4493 +o Sverker Nilsson
4484 4494
4485 +o dvorak 4495 +o dvorak
4486 4496
4487 +o v.naga srinivas 4497 +o v.naga srinivas
4488 4498
4489 +o Shlomi Fish 4499 +o Shlomi Fish
4490 4500
4491 +o Roger Binns 4501 +o Roger Binns
4492 4502
4493 +o johan verrept 4503 +o johan verrept
4494 4504
4495 +o MrChuoi 4505 +o MrChuoi
4496 4506
4497 +o Peter Cleve 4507 +o Peter Cleve
4498 4508
4499 +o Vincent Guffens 4509 +o Vincent Guffens
4500 4510
4501 +o Nathan Scott 4511 +o Nathan Scott
4502 4512
4503 +o Patrick Caulfield 4513 +o Patrick Caulfield
4504 4514
4505 +o jbearce 4515 +o jbearce
4506 4516
4507 +o Catalin Marinas 4517 +o Catalin Marinas
4508 4518
4509 +o Shane Spencer 4519 +o Shane Spencer
4510 4520
4511 +o Zou Min 4521 +o Zou Min
4512 4522
4513 4523
4514 +o Ryan Boder 4524 +o Ryan Boder
4515 4525
4516 +o Lorenzo Colitti 4526 +o Lorenzo Colitti
4517 4527
4518 +o Gwendal Grignou 4528 +o Gwendal Grignou
4519 4529
4520 +o Andre' Breiler 4530 +o Andre' Breiler
4521 4531
4522 +o Tsutomu Yasuda 4532 +o Tsutomu Yasuda
4523 4533
4524 4534
4525 4535
4526 1155..44.. CCaassee SSttuuddiieess 4536 1155..44.. CCaassee SSttuuddiieess
4527 4537
4528 4538
4529 +o Jon Wright 4539 +o Jon Wright
4530 4540
4531 +o William McEwan 4541 +o William McEwan
4532 4542
4533 +o Michael Richardson 4543 +o Michael Richardson
4534 4544
4535 4545
4536 4546
4537 1155..55.. OOtthheerr ccoonnttrriibbuuttiioonnss 4547 1155..55.. OOtthheerr ccoonnttrriibbuuttiioonnss
4538 4548
4539 4549
4540 Bill Carr <Bill.Carr at compaq.com> made the Red Hat mkrootfs script 4550 Bill Carr <Bill.Carr at compaq.com> made the Red Hat mkrootfs script
4541 work with RH 6.2. 4551 work with RH 6.2.
4542 4552
4543 Michael Jennings <mikejen at hevanet.com> sent in some material which 4553 Michael Jennings <mikejen at hevanet.com> sent in some material which
4544 is now gracing the top of the index page <http://user-mode- 4554 is now gracing the top of the index page <http://user-mode-
4545 linux.sourceforge.net/> of this site. 4555 linux.sourceforge.net/> of this site.
4546 4556
4547 SGI <http://www.sgi.com> (and more specifically Ralf Baechle <ralf at 4557 SGI <http://www.sgi.com> (and more specifically Ralf Baechle <ralf at
4548 uni-koblenz.de> ) gave me an account on oss.sgi.com 4558 uni-koblenz.de> ) gave me an account on oss.sgi.com
4549 <http://www.oss.sgi.com> . The bandwidth there made it possible to 4559 <http://www.oss.sgi.com> . The bandwidth there made it possible to
4550 produce most of the filesystems available on the project download 4560 produce most of the filesystems available on the project download
4551 page. 4561 page.
4552 4562
4553 Laurent Bonnaud <Laurent.Bonnaud at inpg.fr> took the old grotty 4563 Laurent Bonnaud <Laurent.Bonnaud at inpg.fr> took the old grotty
4554 Debian filesystem that I've been distributing and updated it to 2.2. 4564 Debian filesystem that I've been distributing and updated it to 2.2.
4555 It is now available by itself here. 4565 It is now available by itself here.
4556 4566
4557 Rik van Riel gave me some ftp space on ftp.nl.linux.org so I can make 4567 Rik van Riel gave me some ftp space on ftp.nl.linux.org so I can make
4558 releases even when Sourceforge is broken. 4568 releases even when Sourceforge is broken.
4559 4569
4560 Rodrigo de Castro looked at my broken pte code and told me what was 4570 Rodrigo de Castro looked at my broken pte code and told me what was
4561 wrong with it, letting me fix a long-standing (several weeks) and 4571 wrong with it, letting me fix a long-standing (several weeks) and
4562 serious set of bugs. 4572 serious set of bugs.
4563 4573
4564 Chris Reahard built a specialized root filesystem for running a DNS 4574 Chris Reahard built a specialized root filesystem for running a DNS
4565 server jailed inside UML. It's available from the download 4575 server jailed inside UML. It's available from the download
4566 <http://user-mode-linux.sourceforge.net/dl-sf.html> page in the Jail 4576 <http://user-mode-linux.sourceforge.net/dl-sf.html> page in the Jail
4567 Filesystems section. 4577 Filesystems section.
4568 4578
4569 4579
4570 4580
4571 4581
4572 4582
4573 4583
4574 4584
4575 4585
4576 4586
4577 4587
4578 4588
4579 4589
4580 4590
arch/um/drivers/Makefile
Diff comments   View file @ 4ff4d8d
1 # 1 #
2 # Copyright (C) 2000, 2002, 2003 Jeff Dike (jdike@karaya.com) 2 # Copyright (C) 2000, 2002, 2003 Jeff Dike (jdike@karaya.com)
3 # Licensed under the GPL 3 # Licensed under the GPL
4 # 4 #
5 5
6 # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked 6 # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
7 # in to pcap.o 7 # in to pcap.o
8 8
9 slip-objs := slip_kern.o slip_user.o 9 slip-objs := slip_kern.o slip_user.o
10 slirp-objs := slirp_kern.o slirp_user.o 10 slirp-objs := slirp_kern.o slirp_user.o
11 daemon-objs := daemon_kern.o daemon_user.o 11 daemon-objs := daemon_kern.o daemon_user.o
12 mcast-objs := mcast_kern.o mcast_user.o 12 umcast-objs := umcast_kern.o umcast_user.o
13 net-objs := net_kern.o net_user.o 13 net-objs := net_kern.o net_user.o
14 mconsole-objs := mconsole_kern.o mconsole_user.o 14 mconsole-objs := mconsole_kern.o mconsole_user.o
15 hostaudio-objs := hostaudio_kern.o 15 hostaudio-objs := hostaudio_kern.o
16 ubd-objs := ubd_kern.o ubd_user.o 16 ubd-objs := ubd_kern.o ubd_user.o
17 port-objs := port_kern.o port_user.o 17 port-objs := port_kern.o port_user.o
18 harddog-objs := harddog_kern.o harddog_user.o 18 harddog-objs := harddog_kern.o harddog_user.o
19 19
20 LDFLAGS_pcap.o := -r $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a) 20 LDFLAGS_pcap.o := -r $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a)
21 21
22 LDFLAGS_vde.o := -r $(shell $(CC) $(CFLAGS) -print-file-name=libvdeplug.a) 22 LDFLAGS_vde.o := -r $(shell $(CC) $(CFLAGS) -print-file-name=libvdeplug.a)
23 23
24 targets := pcap_kern.o pcap_user.o vde_kern.o vde_user.o 24 targets := pcap_kern.o pcap_user.o vde_kern.o vde_user.o
25 25
26 $(obj)/pcap.o: $(obj)/pcap_kern.o $(obj)/pcap_user.o 26 $(obj)/pcap.o: $(obj)/pcap_kern.o $(obj)/pcap_user.o
27 $(LD) -r -dp -o $@ $^ $(LDFLAGS) $(LDFLAGS_pcap.o) 27 $(LD) -r -dp -o $@ $^ $(LDFLAGS) $(LDFLAGS_pcap.o)
28 28
29 $(obj)/vde.o: $(obj)/vde_kern.o $(obj)/vde_user.o 29 $(obj)/vde.o: $(obj)/vde_kern.o $(obj)/vde_user.o
30 $(LD) -r -dp -o $@ $^ $(LDFLAGS) $(LDFLAGS_vde.o) 30 $(LD) -r -dp -o $@ $^ $(LDFLAGS) $(LDFLAGS_vde.o)
31 31
32 #XXX: The call below does not work because the flags are added before the 32 #XXX: The call below does not work because the flags are added before the
33 # object name, so nothing from the library gets linked. 33 # object name, so nothing from the library gets linked.
34 #$(call if_changed,ld) 34 #$(call if_changed,ld)
35 35
36 # When the above is fixed, don't forget to add this too! 36 # When the above is fixed, don't forget to add this too!
37 #targets += $(obj)/pcap.o 37 #targets += $(obj)/pcap.o
38 38
39 obj-y := stdio_console.o fd.o chan_kern.o chan_user.o line.o 39 obj-y := stdio_console.o fd.o chan_kern.o chan_user.o line.o
40 obj-$(CONFIG_SSL) += ssl.o 40 obj-$(CONFIG_SSL) += ssl.o
41 obj-$(CONFIG_STDERR_CONSOLE) += stderr_console.o 41 obj-$(CONFIG_STDERR_CONSOLE) += stderr_console.o
42 42
43 obj-$(CONFIG_UML_NET_SLIP) += slip.o slip_common.o 43 obj-$(CONFIG_UML_NET_SLIP) += slip.o slip_common.o
44 obj-$(CONFIG_UML_NET_SLIRP) += slirp.o slip_common.o 44 obj-$(CONFIG_UML_NET_SLIRP) += slirp.o slip_common.o
45 obj-$(CONFIG_UML_NET_DAEMON) += daemon.o 45 obj-$(CONFIG_UML_NET_DAEMON) += daemon.o
46 obj-$(CONFIG_UML_NET_VDE) += vde.o 46 obj-$(CONFIG_UML_NET_VDE) += vde.o
47 obj-$(CONFIG_UML_NET_MCAST) += mcast.o 47 obj-$(CONFIG_UML_NET_MCAST) += umcast.o
48 obj-$(CONFIG_UML_NET_PCAP) += pcap.o 48 obj-$(CONFIG_UML_NET_PCAP) += pcap.o
49 obj-$(CONFIG_UML_NET) += net.o 49 obj-$(CONFIG_UML_NET) += net.o
50 obj-$(CONFIG_MCONSOLE) += mconsole.o 50 obj-$(CONFIG_MCONSOLE) += mconsole.o
51 obj-$(CONFIG_MMAPPER) += mmapper_kern.o 51 obj-$(CONFIG_MMAPPER) += mmapper_kern.o
52 obj-$(CONFIG_BLK_DEV_UBD) += ubd.o 52 obj-$(CONFIG_BLK_DEV_UBD) += ubd.o
53 obj-$(CONFIG_HOSTAUDIO) += hostaudio.o 53 obj-$(CONFIG_HOSTAUDIO) += hostaudio.o
54 obj-$(CONFIG_NULL_CHAN) += null.o 54 obj-$(CONFIG_NULL_CHAN) += null.o
55 obj-$(CONFIG_PORT_CHAN) += port.o 55 obj-$(CONFIG_PORT_CHAN) += port.o
56 obj-$(CONFIG_PTY_CHAN) += pty.o 56 obj-$(CONFIG_PTY_CHAN) += pty.o
57 obj-$(CONFIG_TTY_CHAN) += tty.o 57 obj-$(CONFIG_TTY_CHAN) += tty.o
58 obj-$(CONFIG_XTERM_CHAN) += xterm.o xterm_kern.o 58 obj-$(CONFIG_XTERM_CHAN) += xterm.o xterm_kern.o
59 obj-$(CONFIG_UML_WATCHDOG) += harddog.o 59 obj-$(CONFIG_UML_WATCHDOG) += harddog.o
60 obj-$(CONFIG_BLK_DEV_COW_COMMON) += cow_user.o 60 obj-$(CONFIG_BLK_DEV_COW_COMMON) += cow_user.o
61 obj-$(CONFIG_UML_RANDOM) += random.o 61 obj-$(CONFIG_UML_RANDOM) += random.o
62 62
63 # pcap_user.o must be added explicitly. 63 # pcap_user.o must be added explicitly.
64 USER_OBJS := fd.o null.o pty.o tty.o xterm.o slip_common.o pcap_user.o vde_user.o 64 USER_OBJS := fd.o null.o pty.o tty.o xterm.o slip_common.o pcap_user.o vde_user.o
65 CFLAGS_null.o = -DDEV_NULL=$(DEV_NULL_PATH) 65 CFLAGS_null.o = -DDEV_NULL=$(DEV_NULL_PATH)
66 66
67 include arch/um/scripts/Makefile.rules 67 include arch/um/scripts/Makefile.rules
68 68
arch/um/drivers/mcast.h
View file @ 4ff4d8d
1 /* File was deleted
2 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
3 * Licensed under the GPL
4 */
5
6 #ifndef __DRIVERS_MCAST_H
7 #define __DRIVERS_MCAST_H
8
9 #include "net_user.h"
10
11 struct mcast_data {
12 char *addr;
13 unsigned short port;
14 void *mcast_addr;
15 int ttl;
16 void *dev;
17 };
18
19 extern const struct net_user_info mcast_user_info;
20
21 extern int mcast_user_write(int fd, void *buf, int len,
22 struct mcast_data *pri);
23
24 #endif
25 1 /*
arch/um/drivers/mcast_kern.c
View file @ 4ff4d8d
1 /* File was deleted
2 * user-mode-linux networking multicast transport
3 * Copyright (C) 2001 by Harald Welte <laforge@gnumonks.org>
4 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
5 *
6 * based on the existing uml-networking code, which is
7 * Copyright (C) 2001 Lennert Buytenhek (buytenh@gnu.org) and
8 * James Leu (jleu@mindspring.net).
9 * Copyright (C) 2001 by various other people who didn't put their name here.
10 *
11 * Licensed under the GPL.
12 */
13
14 #include "linux/init.h"
15 #include <linux/netdevice.h>
16 #include "mcast.h"
17 #include "net_kern.h"
18
19 struct mcast_init {
20 char *addr;
21 int port;
22 int ttl;
23 };
24
25 static void mcast_init(struct net_device *dev, void *data)
26 {
27 struct uml_net_private *pri;
28 struct mcast_data *dpri;
29 struct mcast_init *init = data;
30
31 pri = netdev_priv(dev);
32 dpri = (struct mcast_data *) pri->user;
33 dpri->addr = init->addr;
34 dpri->port = init->port;
35 dpri->ttl = init->ttl;
36 dpri->dev = dev;
37
38 printk("mcast backend multicast address: %s:%u, TTL:%u\n",
39 dpri->addr, dpri->port, dpri->ttl);
40 }
41
42 static int mcast_read(int fd, struct sk_buff *skb, struct uml_net_private *lp)
43 {
44 return net_recvfrom(fd, skb_mac_header(skb),
45 skb->dev->mtu + ETH_HEADER_OTHER);
46 }
47
48 static int mcast_write(int fd, struct sk_buff *skb, struct uml_net_private *lp)
49 {
50 return mcast_user_write(fd, skb->data, skb->len,
51 (struct mcast_data *) &lp->user);
52 }
53
54 static const struct net_kern_info mcast_kern_info = {
55 .init = mcast_init,
56 .protocol = eth_protocol,
57 .read = mcast_read,
58 .write = mcast_write,
59 };
60
61 static int mcast_setup(char *str, char **mac_out, void *data)
62 {
63 struct mcast_init *init = data;
64 char *port_str = NULL, *ttl_str = NULL, *remain;
65 char *last;
66
67 *init = ((struct mcast_init)
68 { .addr = "239.192.168.1",
69 .port = 1102,
70 .ttl = 1 });
71
72 remain = split_if_spec(str, mac_out, &init->addr, &port_str, &ttl_str,
73 NULL);
74 if (remain != NULL) {
75 printk(KERN_ERR "mcast_setup - Extra garbage on "
76 "specification : '%s'\n", remain);
77 return 0;
78 }
79
80 if (port_str != NULL) {
81 init->port = simple_strtoul(port_str, &last, 10);
82 if ((*last != '\0') || (last == port_str)) {
83 printk(KERN_ERR "mcast_setup - Bad port : '%s'\n",
84 port_str);
85 return 0;
86 }
87 }
88
89 if (ttl_str != NULL) {
90 init->ttl = simple_strtoul(ttl_str, &last, 10);
91 if ((*last != '\0') || (last == ttl_str)) {
92 printk(KERN_ERR "mcast_setup - Bad ttl : '%s'\n",
93 ttl_str);
94 return 0;
95 }
96 }
97
98 printk(KERN_INFO "Configured mcast device: %s:%u-%u\n", init->addr,
99 init->port, init->ttl);
100
101 return 1;
102 }
103
104 static struct transport mcast_transport = {
105 .list = LIST_HEAD_INIT(mcast_transport.list),
106 .name = "mcast",
107 .setup = mcast_setup,
108 .user = &mcast_user_info,
109 .kern = &mcast_kern_info,
110 .private_size = sizeof(struct mcast_data),
111 .setup_size = sizeof(struct mcast_init),
112 };
113
114 static int register_mcast(void)
115 {
116 register_transport(&mcast_transport);
117 return 0;
118 }
119
120 late_initcall(register_mcast);
121 1 /*
arch/um/drivers/mcast_user.c
View file @ 4ff4d8d
1 /* File was deleted
2 * user-mode-linux networking multicast transport
3 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
4 * Copyright (C) 2001 by Harald Welte <laforge@gnumonks.org>
5 *
6 * based on the existing uml-networking code, which is
7 * Copyright (C) 2001 Lennert Buytenhek (buytenh@gnu.org) and
8 * James Leu (jleu@mindspring.net).
9 * Copyright (C) 2001 by various other people who didn't put their name here.
10 *
11 * Licensed under the GPL.
12 *
13 */
14
15 #include <unistd.h>
16 #include <errno.h>
17 #include <netinet/in.h>
18 #include "kern_constants.h"
19 #include "mcast.h"
20 #include "net_user.h"
21 #include "um_malloc.h"
22 #include "user.h"
23
24 static struct sockaddr_in *new_addr(char *addr, unsigned short port)
25 {
26 struct sockaddr_in *sin;
27
28 sin = uml_kmalloc(sizeof(struct sockaddr_in), UM_GFP_KERNEL);
29 if (sin == NULL) {
30 printk(UM_KERN_ERR "new_addr: allocation of sockaddr_in "
31 "failed\n");
32 return NULL;
33 }
34 sin->sin_family = AF_INET;
35 sin->sin_addr.s_addr = in_aton(addr);
36 sin->sin_port = htons(port);
37 return sin;
38 }
39
40 static int mcast_user_init(void *data, void *dev)
41 {
42 struct mcast_data *pri = data;
43
44 pri->mcast_addr = new_addr(pri->addr, pri->port);
45 pri->dev = dev;
46 return 0;
47 }
48
49 static void mcast_remove(void *data)
50 {
51 struct mcast_data *pri = data;
52
53 kfree(pri->mcast_addr);
54 pri->mcast_addr = NULL;
55 }
56
57 static int mcast_open(void *data)
58 {
59 struct mcast_data *pri = data;
60 struct sockaddr_in *sin = pri->mcast_addr;
61 struct ip_mreq mreq;
62 int fd, yes = 1, err = -EINVAL;
63
64
65 if ((sin->sin_addr.s_addr == 0) || (sin->sin_port == 0))
66 goto out;
67
68 fd = socket(AF_INET, SOCK_DGRAM, 0);
69
70 if (fd < 0) {
71 err = -errno;
72 printk(UM_KERN_ERR "mcast_open : data socket failed, "
73 "errno = %d\n", errno);
74 goto out;
75 }
76
77 if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0) {
78 err = -errno;
79 printk(UM_KERN_ERR "mcast_open: SO_REUSEADDR failed, "
80 "errno = %d\n", errno);
81 goto out_close;
82 }
83
84 /* set ttl according to config */
85 if (setsockopt(fd, SOL_IP, IP_MULTICAST_TTL, &pri->ttl,
86 sizeof(pri->ttl)) < 0) {
87 err = -errno;
88 printk(UM_KERN_ERR "mcast_open: IP_MULTICAST_TTL failed, "
89 "error = %d\n", errno);
90 goto out_close;
91 }
92
93 /* set LOOP, so data does get fed back to local sockets */
94 if (setsockopt(fd, SOL_IP, IP_MULTICAST_LOOP, &yes, sizeof(yes)) < 0) {
95 err = -errno;
96 printk(UM_KERN_ERR "mcast_open: IP_MULTICAST_LOOP failed, "
97 "error = %d\n", errno);
98 goto out_close;
99 }
100
101 /* bind socket to mcast address */
102 if (bind(fd, (struct sockaddr *) sin, sizeof(*sin)) < 0) {
103 err = -errno;
104 printk(UM_KERN_ERR "mcast_open : data bind failed, "
105 "errno = %d\n", errno);
106 goto out_close;
107 }
108
109 /* subscribe to the multicast group */
110 mreq.imr_multiaddr.s_addr = sin->sin_addr.s_addr;
111 mreq.imr_interface.s_addr = 0;
112 if (setsockopt(fd, SOL_IP, IP_ADD_MEMBERSHIP,
113 &mreq, sizeof(mreq)) < 0) {
114 err = -errno;
115 printk(UM_KERN_ERR "mcast_open: IP_ADD_MEMBERSHIP failed, "
116 "error = %d\n", errno);
117 printk(UM_KERN_ERR "There appears not to be a multicast-"
118 "capable network interface on the host.\n");
119 printk(UM_KERN_ERR "eth0 should be configured in order to use "
120 "the multicast transport.\n");
121 goto out_close;
122 }
123
124 return fd;
125
126 out_close:
127 close(fd);
128 out:
129 return err;
130 }
131
132 static void mcast_close(int fd, void *data)
133 {
134 struct ip_mreq mreq;
135 struct mcast_data *pri = data;
136 struct sockaddr_in *sin = pri->mcast_addr;
137
138 mreq.imr_multiaddr.s_addr = sin->sin_addr.s_addr;
139 mreq.imr_interface.s_addr = 0;
140 if (setsockopt(fd, SOL_IP, IP_DROP_MEMBERSHIP,
141 &mreq, sizeof(mreq)) < 0) {
142 printk(UM_KERN_ERR "mcast_open: IP_DROP_MEMBERSHIP failed, "
143 "error = %d\n", errno);
144 }
145
146 close(fd);
147 }
148
149 int mcast_user_write(int fd, void *buf, int len, struct mcast_data *pri)
150 {
151 struct sockaddr_in *data_addr = pri->mcast_addr;
152
153 return net_sendto(fd, buf, len, data_addr, sizeof(*data_addr));
154 }
155
156 const struct net_user_info mcast_user_info = {
157 .init = mcast_user_init,
158 .open = mcast_open,
159 .close = mcast_close,
160 .remove = mcast_remove,
161 .add_address = NULL,
162 .delete_address = NULL,
163 .mtu = ETH_MAX_PACKET,
164 .max_packet = ETH_MAX_PACKET + ETH_HEADER_OTHER,
165 };
166 1 /*
arch/um/drivers/umcast.h
Diff comments   View file @ 4ff4d8d
File was created 1 /*
2 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
3 * Licensed under the GPL
4 */
5
6 #ifndef __DRIVERS_UMCAST_H
7 #define __DRIVERS_UMCAST_H
8
9 #include "net_user.h"
10
11 struct umcast_data {
12 char *addr;
13 unsigned short lport;
14 unsigned short rport;
15 void *listen_addr;
16 void *remote_addr;
17 int ttl;
18 int unicast;
19 void *dev;
20 };
21
22 extern const struct net_user_info umcast_user_info;
23
24 extern int umcast_user_write(int fd, void *buf, int len,
25 struct umcast_data *pri);
26
27 #endif
28
arch/um/drivers/umcast_kern.c
Diff comments   View file @ 4ff4d8d
File was created 1 /*
2 * user-mode-linux networking multicast transport
3 * Copyright (C) 2001 by Harald Welte <laforge@gnumonks.org>
4 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
5 *
6 * based on the existing uml-networking code, which is
7 * Copyright (C) 2001 Lennert Buytenhek (buytenh@gnu.org) and
8 * James Leu (jleu@mindspring.net).
9 * Copyright (C) 2001 by various other people who didn't put their name here.
10 *
11 * Licensed under the GPL.
12 */
13
14 #include "linux/init.h"
15 #include <linux/netdevice.h>
16 #include "umcast.h"
17 #include "net_kern.h"
18
19 struct umcast_init {
20 char *addr;
21 int lport;
22 int rport;
23 int ttl;
24 bool unicast;
25 };
26
27 static void umcast_init(struct net_device *dev, void *data)
28 {
29 struct uml_net_private *pri;
30 struct umcast_data *dpri;
31 struct umcast_init *init = data;
32
33 pri = netdev_priv(dev);
34 dpri = (struct umcast_data *) pri->user;
35 dpri->addr = init->addr;
36 dpri->lport = init->lport;
37 dpri->rport = init->rport;
38 dpri->unicast = init->unicast;
39 dpri->ttl = init->ttl;
40 dpri->dev = dev;
41
42 if (dpri->unicast) {
43 printk(KERN_INFO "ucast backend address: %s:%u listen port: "
44 "%u\n", dpri->addr, dpri->rport, dpri->lport);
45 } else {
46 printk(KERN_INFO "mcast backend multicast address: %s:%u, "
47 "TTL:%u\n", dpri->addr, dpri->lport, dpri->ttl);
48 }
49 }
50
51 static int umcast_read(int fd, struct sk_buff *skb, struct uml_net_private *lp)
52 {
53 return net_recvfrom(fd, skb_mac_header(skb),
54 skb->dev->mtu + ETH_HEADER_OTHER);
55 }
56
57 static int umcast_write(int fd, struct sk_buff *skb, struct uml_net_private *lp)
58 {
59 return umcast_user_write(fd, skb->data, skb->len,
60 (struct umcast_data *) &lp->user);
61 }
62
63 static const struct net_kern_info umcast_kern_info = {
64 .init = umcast_init,
65 .protocol = eth_protocol,
66 .read = umcast_read,
67 .write = umcast_write,
68 };
69
70 static int mcast_setup(char *str, char **mac_out, void *data)
71 {
72 struct umcast_init *init = data;
73 char *port_str = NULL, *ttl_str = NULL, *remain;
74 char *last;
75
76 *init = ((struct umcast_init)
77 { .addr = "239.192.168.1",
78 .lport = 1102,
79 .ttl = 1 });
80
81 remain = split_if_spec(str, mac_out, &init->addr, &port_str, &ttl_str,
82 NULL);
83 if (remain != NULL) {
84 printk(KERN_ERR "mcast_setup - Extra garbage on "
85 "specification : '%s'\n", remain);
86 return 0;
87 }
88
89 if (port_str != NULL) {
90 init->lport = simple_strtoul(port_str, &last, 10);
91 if ((*last != '\0') || (last == port_str)) {
92 printk(KERN_ERR "mcast_setup - Bad port : '%s'\n",
93 port_str);
94 return 0;
95 }
96 }
97
98 if (ttl_str != NULL) {
99 init->ttl = simple_strtoul(ttl_str, &last, 10);
100 if ((*last != '\0') || (last == ttl_str)) {
101 printk(KERN_ERR "mcast_setup - Bad ttl : '%s'\n",
102 ttl_str);
103 return 0;
104 }
105 }
106
107 init->unicast = false;
108 init->rport = init->lport;
109
110 printk(KERN_INFO "Configured mcast device: %s:%u-%u\n", init->addr,
111 init->lport, init->ttl);
112
113 return 1;
114 }
115
116 static int ucast_setup(char *str, char **mac_out, void *data)
117 {
118 struct umcast_init *init = data;
119 char *lport_str = NULL, *rport_str = NULL, *remain;
120 char *last;
121
122 *init = ((struct umcast_init)
123 { .addr = "",
124 .lport = 1102,
125 .rport = 1102 });
126
127 remain = split_if_spec(str, mac_out, &init->addr,
128 &lport_str, &rport_str, NULL);
129 if (remain != NULL) {
130 printk(KERN_ERR "ucast_setup - Extra garbage on "
131 "specification : '%s'\n", remain);
132 return 0;
133 }
134
135 if (lport_str != NULL) {
136 init->lport = simple_strtoul(lport_str, &last, 10);
137 if ((*last != '\0') || (last == lport_str)) {
138 printk(KERN_ERR "ucast_setup - Bad listen port : "
139 "'%s'\n", lport_str);
140 return 0;
141 }
142 }
143
144 if (rport_str != NULL) {
145 init->rport = simple_strtoul(rport_str, &last, 10);
146 if ((*last != '\0') || (last == rport_str)) {
147 printk(KERN_ERR "ucast_setup - Bad remote port : "
148 "'%s'\n", rport_str);
149 return 0;
150 }
151 }
152
153 init->unicast = true;
154
155 printk(KERN_INFO "Configured ucast device: :%u -> %s:%u\n",
156 init->lport, init->addr, init->rport);
157
158 return 1;
159 }
160
161 static struct transport mcast_transport = {
162 .list = LIST_HEAD_INIT(mcast_transport.list),
163 .name = "mcast",
164 .setup = mcast_setup,
165 .user = &umcast_user_info,
166 .kern = &umcast_kern_info,
167 .private_size = sizeof(struct umcast_data),
168 .setup_size = sizeof(struct umcast_init),
169 };
170
171 static struct transport ucast_transport = {
172 .list = LIST_HEAD_INIT(ucast_transport.list),
173 .name = "ucast",
174 .setup = ucast_setup,
175 .user = &umcast_user_info,
176 .kern = &umcast_kern_info,
177 .private_size = sizeof(struct umcast_data),
178 .setup_size = sizeof(struct umcast_init),
179 };
180
181 static int register_umcast(void)
182 {
183 register_transport(&mcast_transport);
184 register_transport(&ucast_transport);
185 return 0;
186 }
187
188 late_initcall(register_umcast);
189
arch/um/drivers/umcast_user.c
Diff comments   View file @ 4ff4d8d
File was created 1 /*
2 * user-mode-linux networking multicast transport
3 * Copyright (C) 2001 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
4 * Copyright (C) 2001 by Harald Welte <laforge@gnumonks.org>
5 *
6 * based on the existing uml-networking code, which is
7 * Copyright (C) 2001 Lennert Buytenhek (buytenh@gnu.org) and
8 * James Leu (jleu@mindspring.net).
9 * Copyright (C) 2001 by various other people who didn't put their name here.
10 *
11 * Licensed under the GPL.
12 *
13 */
14
15 #include <unistd.h>
16 #include <errno.h>
17 #include <netinet/in.h>
18 #include "kern_constants.h"
19 #include "umcast.h"
20 #include "net_user.h"
21 #include "um_malloc.h"
22 #include "user.h"
23
24 static struct sockaddr_in *new_addr(char *addr, unsigned short port)
25 {
26 struct sockaddr_in *sin;
27
28 sin = uml_kmalloc(sizeof(struct sockaddr_in), UM_GFP_KERNEL);
29 if (sin == NULL) {
30 printk(UM_KERN_ERR "new_addr: allocation of sockaddr_in "
31 "failed\n");
32 return NULL;
33 }
34 sin->sin_family = AF_INET;
35 if (addr)
36 sin->sin_addr.s_addr = in_aton(addr);
37 else
38 sin->sin_addr.s_addr = INADDR_ANY;
39 sin->sin_port = htons(port);
40 return sin;
41 }
42
43 static int umcast_user_init(void *data, void *dev)
44 {
45 struct umcast_data *pri = data;
46
47 pri->remote_addr = new_addr(pri->addr, pri->rport);
48 if (pri->unicast)
49 pri->listen_addr = new_addr(NULL, pri->lport);
50 else
51 pri->listen_addr = pri->remote_addr;
52 pri->dev = dev;
53 return 0;
54 }
55
56 static void umcast_remove(void *data)
57 {
58 struct umcast_data *pri = data;
59
60 kfree(pri->listen_addr);
61 if (pri->unicast)
62 kfree(pri->remote_addr);
63 pri->listen_addr = pri->remote_addr = NULL;
64 }
65
66 static int umcast_open(void *data)
67 {
68 struct umcast_data *pri = data;
69 struct sockaddr_in *lsin = pri->listen_addr;
70 struct sockaddr_in *rsin = pri->remote_addr;
71 struct ip_mreq mreq;
72 int fd, yes = 1, err = -EINVAL;
73
74
75 if ((!pri->unicast && lsin->sin_addr.s_addr == 0) ||
76 (rsin->sin_addr.s_addr == 0) ||
77 (lsin->sin_port == 0) || (rsin->sin_port == 0))
78 goto out;
79
80 fd = socket(AF_INET, SOCK_DGRAM, 0);
81
82 if (fd < 0) {
83 err = -errno;
84 printk(UM_KERN_ERR "umcast_open : data socket failed, "
85 "errno = %d\n", errno);
86 goto out;
87 }
88
89 if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0) {
90 err = -errno;
91 printk(UM_KERN_ERR "umcast_open: SO_REUSEADDR failed, "
92 "errno = %d\n", errno);
93 goto out_close;
94 }
95
96 if (!pri->unicast) {
97 /* set ttl according to config */
98 if (setsockopt(fd, SOL_IP, IP_MULTICAST_TTL, &pri->ttl,
99 sizeof(pri->ttl)) < 0) {
100 err = -errno;
101 printk(UM_KERN_ERR "umcast_open: IP_MULTICAST_TTL "
102 "failed, error = %d\n", errno);
103 goto out_close;
104 }
105
106 /* set LOOP, so data does get fed back to local sockets */
107 if (setsockopt(fd, SOL_IP, IP_MULTICAST_LOOP,
108 &yes, sizeof(yes)) < 0) {
109 err = -errno;
110 printk(UM_KERN_ERR "umcast_open: IP_MULTICAST_LOOP "
111 "failed, error = %d\n", errno);
112 goto out_close;
113 }
114 }
115
116 /* bind socket to the address */
117 if (bind(fd, (struct sockaddr *) lsin, sizeof(*lsin)) < 0) {
118 err = -errno;
119 printk(UM_KERN_ERR "umcast_open : data bind failed, "
120 "errno = %d\n", errno);
121 goto out_close;
122 }
123
124 if (!pri->unicast) {
125 /* subscribe to the multicast group */
126 mreq.imr_multiaddr.s_addr = lsin->sin_addr.s_addr;
127 mreq.imr_interface.s_addr = 0;
128 if (setsockopt(fd, SOL_IP, IP_ADD_MEMBERSHIP,
129 &mreq, sizeof(mreq)) < 0) {
130 err = -errno;
131 printk(UM_KERN_ERR "umcast_open: IP_ADD_MEMBERSHIP "
132 "failed, error = %d\n", errno);
133 printk(UM_KERN_ERR "There appears not to be a "
134 "multicast-capable network interface on the "
135 "host.\n");
136 printk(UM_KERN_ERR "eth0 should be configured in order "
137 "to use the multicast transport.\n");
138 goto out_close;
139 }
140 }
141
142 return fd;
143
144 out_close:
145 close(fd);
146 out:
147 return err;
148 }
149
150 static void umcast_close(int fd, void *data)
151 {
152 struct umcast_data *pri = data;
153
154 if (!pri->unicast) {
155 struct ip_mreq mreq;
156 struct sockaddr_in *lsin = pri->listen_addr;
157
158 mreq.imr_multiaddr.s_addr = lsin->sin_addr.s_addr;
159 mreq.imr_interface.s_addr = 0;
160 if (setsockopt(fd, SOL_IP, IP_DROP_MEMBERSHIP,
161 &mreq, sizeof(mreq)) < 0) {
162 printk(UM_KERN_ERR "umcast_close: IP_DROP_MEMBERSHIP "
163 "failed, error = %d\n", errno);
164 }
165 }
166
167 close(fd);
168 }
169
170 int umcast_user_write(int fd, void *buf, int len, struct umcast_data *pri)
171 {
172 struct sockaddr_in *data_addr = pri->remote_addr;
173
174 return net_sendto(fd, buf, len, data_addr, sizeof(*data_addr));
175 }
176
177 const struct net_user_info umcast_user_info = {
178 .init = umcast_user_init,
179 .open = umcast_open,
180 .close = umcast_close,
181 .remove = umcast_remove,
182 .add_address = NULL,
183 .delete_address = NULL,
184 .mtu = ETH_MAX_PACKET,
185 .max_packet = ETH_MAX_PACKET + ETH_HEADER_OTHER,
186 };
187