1. 02 Oct, 2006 4 commits
    • Eric W. Biederman's avatar
      [PATCH] proc: readdir race fix (take 3) · 0804ef4b
      Eric W. Biederman authored
      The problem: An opendir, readdir, closedir sequence can fail to report
      process ids that are continually in use throughout the sequence of system
      calls.  For this race to trigger the process that proc_pid_readdir stops at
      must exit before readdir is called again.
      
      This can cause ps to fail to report processes, and it is in violation of
      posix guarantees and normal application expectations with respect to
      readdir.
      
      Currently there is no way to work around this problem in user space short
      of providing a gargantuan buffer to user space so the directory read all
      happens in on system call.
      
      This patch implements the normal directory semantics for proc, that
      guarantee that a directory entry that is neither created nor destroyed
      while reading the directory entry will be returned.  For directory that are
      either created or destroyed during the readdir you may or may not see them.
       Furthermore you may seek to a directory offset you have previously seen.
      
      These are the guarantee that ext[23] provides and that posix requires, and
      more importantly that user space expects.  Plus it is a simple semantic to
      implement reliable service.  It is just a matter of calling readdir a
      second time if you are wondering if something new has show up.
      
      These better semantics are implemented by scanning through the pids in
      numerical order and by making the file offset a pid plus a fixed offset.
      
      The pid scan happens on the pid bitmap, which when you look at it is
      remarkably efficient for a brute force algorithm.  Given that a typical
      cache line is 64 bytes and thus covers space for 64*8 == 200 pids.  There
      are only 40 cache lines for the entire 32K pid space.  A typical system
      will have 100 pids or more so this is actually fewer cache lines we have to
      look at to scan a linked list, and the worst case of having to scan the
      entire pid bitmap is pretty reasonable.
      
      If we need something more efficient we can go to a more efficient data
      structure for indexing the pids, but for now what we have should be
      sufficient.
      
      In addition this takes no additional locks and is actually less code than
      what we are doing now.
      
      Also another very subtle bug in this area has been fixed.  It is possible
      to catch a task in the middle of de_thread where a thread is assuming the
      thread of it's thread group leader.  This patch carefully handles that case
      so if we hit it we don't fail to return the pid, that is undergoing the
      de_thread dance.
      
      Thanks to KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> for
      providing the first fix, pointing this out and working on it.
      
      [oleg@tv-sign.ru: fix it]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Acked-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Jean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0804ef4b
    • Randy Dunlap's avatar
      [PATCH] list module taint flags in Oops/panic · 2bc2d61a
      Randy Dunlap authored
      When listing loaded modules during an oops or panic, also list each
      module's Tainted flags if non-zero (P: Proprietary or F: Forced load only).
      
      If a module is did not taint the kernel, it is just listed like
      	usbcore
      but if it did taint the kernel, it is listed like
      	wizmodem(PF)
      
      Example:
      [ 3260.121718] Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
      [ 3260.121729]  [<ffffffff8804c099>] :dump_test:proc_dump_test+0x99/0xc8
      [ 3260.121742] PGD fe8d067 PUD 264a6067 PMD 0
      [ 3260.121748] Oops: 0002 [1] SMP
      [ 3260.121753] CPU 1
      [ 3260.121756] Modules linked in: dump_test(P) snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ide_cd generic ohci1394 snd_hda_intel snd_hda_codec snd_pcm snd_timer snd ieee1394 snd_page_alloc piix ide_core arcmsr aic79xx scsi_transport_spi usblp
      [ 3260.121785] Pid: 5556, comm: bash Tainted: P      2.6.18-git10 #1
      
      [Alternatively, I can look into listing tainted flags with 'lsmod',
      but that won't help in oopsen/panics so much.]
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2bc2d61a
    • Dean Nelson's avatar
      [PATCH] make genpool allocator adhere to kernel-doc standards · a58cbd7c
      Dean Nelson authored
      The exported kernel interfaces of genpool allocator need to adhere to
      the requirements of kernel-doc.
      Signed-off-by: default avatarDean Nelson <dcn@sgi.com>
      Cc: Steve Wise <swise@opengridcomputing.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a58cbd7c
    • Steve Wise's avatar
      [PATCH] LIB: add gen_pool_destroy() · 322acc96
      Steve Wise authored
      Modules using the genpool allocator need to be able to destroy the data
      structure when unloading.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Dean Nelson <dcn@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      322acc96
  2. 01 Oct, 2006 36 commits