1. 09 Sep, 2002 35 commits
  2. 08 Sep, 2002 5 commits
    • Alexander Viro's avatar
      [PATCH] handle_initrd() and request_module() · 09589177
      Alexander Viro authored
      There are 4 different scenarios of late boot:
      
      1.	no initrd or ROOT_DEV is ram0.  That's the simplest one - we want
      	whatever is on ROOT_DEV as final root.
      
      2.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd doesn't
      	exit.   We want initrd mounted, /linuxrc launched and /linuxrc
      	will mount whatever it wants, maybe do pivot_root and exec init
      	itself.  Task with PID 1 (parent of linuxrc) will sit there reaping
      	zombies, never leaving the kernel mode.
      
      3.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd does exit
      	and sets real-root-dev to 256 (1:0, aka. ram0).   We want initrd
      	mounted, /linuxrc launched and we expect linuxrc to mount all stuff
      	we need, maybe do pivot root and exit.  Parent of /linuxrc (PID 1)
      	will proceed to exec init once /linuxrc is done.
      
      4.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd might have
      	done something or not, but when it exits real-root-dev is not ram0.
      	We want initrd mounted, /linuxrc launched and when it exits we are
      	going to mount final root according to real-root-dev.  If there is
      	/initrd on the final root, initrd will be moved there.  Otherwise
      	initrd will be unmounted and its memory (if possible) freed.  Then
      	we exec init from final root.
      
      Note that we want the parent of linuxrc chrooted to initrd while linuxrc
      runs - otherwise things like request_module() will be rather unhappy.  That
      goes for all variants that run linuxrc.
      
      Scenarios above go in order of increasing complexity.  Let's start with #4:
      
      	we had loaded initrd
      	we mount initrd on /root
      	we open / and /old (on initrd)
      	chdir /root
      	mount -- move . /
      	chroot .
      
      Now we have initrd mounted on /, we are chrooted into it but keep opened
      descriptors of / and /old, so we'll be able to break out of jail later.
      
      	we fork a child that will be linuxrc
      	child closes opened descriptors, opens /dev/console, dups it to stdout
      and stderr, does setsid and execs /linuxrc.
      
      	parent sits there reaping zombies until child is finished.
      
      Note that both parent and linuxrc are chrooted into /initrd and if linuxrc
      calls pivot_root, the parent will also have its root/cwd switched.
      
      	OK, child is finished and after checking real_root_dev we see that
      it's not MKDEV(1,0).  Now we know that it's scenario #4.
      We break out of jail, doing the following:
      
      	fchdir to /old on rootfs
      	mount --move / .
      	fchdir to / on rootfs
      	chroot to .
      
      That will move initrd to /old and leave us with root and cwd in / of rootfs.
      We can close these two descriptors now - they'd done their job.
      
      	We mount final root to /root
      	We attempt to mount -- move /old /root/initrd; if we are successful -
      we chdir to /root, mount --move . / and chroot to .  That will leave us with
      	* final root on /
      	* initrd on /initrd of final root
      	* cwd and root on final root.
      
      At that point we simply exec init.
      
      	Now, if mount --move had failed, we got to clean up the mess.  We
      unmount (with MNT_DETACH) initrd from /old and do BLKFLSBUF on ram0.  After
      that we have final root on /root, initrd maybe still alive, but not mounted
      anywhere and our root/cwd in / of rootfs.  Again,
      
      	chdir /root
      	mount --move . /
      	chroot to .
      
      and we have final root mounted on /, we are chrooted into it and it's time
      for exec init.
      
      	That's it for scenario 4.  The rest will be simpler - there's less
      work to do.
      
      #3 diverges from #4 after linuxrc had finished and we had already broken out
      of jail.  Whatever we got from linuxrc is mounted on /old now, so we move it
      back to /, get chrooted there and exec init.   We could've left earlier
      (skipping the move to /old and move back parts), but that would lead to
      even messier logics in prepare_namespace() ;-/
      
      #2 means that parent of /linuxrc never gets past waiting its child to finish.
      End of story.
      
      #1 is the simplest variant - it mounts final root on /root and then does usual
      "chdir there, mount --move . /, chroot to ." and execs init.
      
      Relevant code is in prepare_namespace()/handle_initrd() and yes, it's messy.
      Had been even worse... ;-/
      09589177
    • Hugh Dickins's avatar
      [PATCH] M386 flush_one_tlb invlpg · 43b138da
      Hugh Dickins authored
      CONFIG_M386 kernel running on PPro+ processor with X86_FEATURE_PGE may
      set _PAGE_GLOBAL bit: then __flush_tlb_one must use invlpg instruction.
      H. J. Lu reports (LKML 8 Sept) that his P4 reboots due to this problem.
      43b138da
    • Ingo Molnar's avatar
      [PATCH] Re: pinpointed: PANIC caused by dequeue_signal() in current Linus · 49ba178c
      Ingo Molnar authored
      This fixes the bootup crash.  There were two initialization bugs:
      
      	- INIT_SIGNAL needs to set shared_pending.
      
      	- exec() needs to set up newsig properly.
      
      the second one caused the crash Anton saw.
      49ba178c
    • Andrew Morton's avatar
      [PATCH] Use kmap_atomic() for generic_file_write() · 86ee4c5d
      Andrew Morton authored
      This patch uses the atomic copy_from_user() facility in
      generic_file_write().
      
      This required a change in the prepare_write/commit_write API
      definition.  It is no longer the case that these functions will kmap
      the page for you.
      
      If any part of the kernel wants to get at the page in the write path,
      it now has to kmap it for itself.  The best way to do this is with
      kmap_atomic(KM_USER0).
      
      This patch updates all callers.  It also converts several places which
      were unnecessarily using kmap() over to using kmap_atomic().
      
      The reiserfs changes here are Oleg Drokin's revised version.
      
      The patch has been tested with loop, ext2, ext3, reiserfs, jfs,
      minixfs, vfat, iso9660, nfs and the ramdisk driver.
      
      I haven't fixed the racy deadlock avoidance thing in
      generic_file_write() - the case where we take a fault when the source
      and dest of the copy are both the same pagecache page.
      
      There is a printk in there now which will trigger if the page was
      unexpectedly not present.  And guess what?  I get 50-100 of them when
      running `dbench 64' on mem=48m.   This deadlock can happen.
      86ee4c5d
    • Andrew Morton's avatar
      [PATCH] Use kmap_atomic() for generic_file_read() · 88a3b490
      Andrew Morton authored
      This patch allows the kernel to hold atomic kmaps in file_read_actor().
      
      We try to fault in the page, then take an atomic kmap.  If the atomic
      copy_to_user() then faults, drop a printk and fall back to kmap().
      88a3b490