1. 10 8月, 2010 7 次提交
    • N
      NFS: allow close-to-open cache semantics to apply to root of NFS filesystem · f5a73672
      Neil Brown 提交于
      
      
      To obey NFS cache semantics, the client must verify the cached
      attributes when a file is opened.  In most cases this is done by a call to
      d_validate as one of the last steps in path_walk.
      
      However for the root of a filesystem, d_validate is only ever called
      on the mounted-on filesystem (except when the path ends '.' or '..').
      So NFS has no chance to validate the attributes.
      
      So, in nfs_opendir, we revalidate the attributes if the opened
      directory is the mountpoint.  This may cause double-validation for "."
      and ".." lookups, but that is better than missing regular /path/name
      lookups completely.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f5a73672
    • K
      vfs: fix warning: 'dirent' is used uninitialized in this function · 85c9fe8f
      Kevin Winchester 提交于
      Using:
      
      	gcc (GCC) 4.5.0 20100610 (prerelease)
      
      The following warnings appear:
      
      	fs/readdir.c: In function `filldir64':
      	fs/readdir.c:240:15: warning: `dirent' is used uninitialized in this function
      	fs/readdir.c: In function `filldir':
      	fs/readdir.c:155:15: warning: `dirent' is used uninitialized in this function
      	fs/compat.c: In function `compat_filldir64':
      	fs/compat.c:1071:11: warning: `dirent' is used uninitialized in this function
      	fs/compat.c: In function `compat_filldir':
      	fs/compat.c:984:15: warning: `dirent' is used uninitialized in this function
      
      The warnings are related to the use of the NAME_OFFSET() macro.  Luckily,
      it appears as though the standard offsetof() macro is what is being
      implemented by NAME_OFFSET(), thus we can fix the warning and use a more
      standard code construct at the same time.
      Signed-off-by: NKevin Winchester <kjwinchester@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      85c9fe8f
    • J
      mm: avoid resetting wb_start after each writeback round · 7624ee72
      Jan Kara 提交于
      WB_SYNC_NONE writeback is done in rounds of 1024 pages so that we don't
      write out some huge inode for too long while starving writeout of other
      inodes.  To avoid livelocks, we record time we started writeback in
      wbc->wb_start and do not write out inodes which were dirtied after this
      time.  But currently, writeback_inodes_wb() resets wb_start each time it
      is called thus effectively invalidating this logic and making any
      WB_SYNC_NONE writeback prone to livelocks.
      
      This patch makes sure wb_start is set only once when we start writeback.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Reviewed-by: NWu Fengguang <fengguang.wu@intel.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Acked-by: NJens Axboe <jaxboe@fusionio.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7624ee72
    • D
      oom: deprecate oom_adj tunable · 51b1bd2a
      David Rientjes 提交于
      /proc/pid/oom_adj is now deprecated so that that it may eventually be
      removed.  The target date for removal is August 2012.
      
      A warning will be printed to the kernel log if a task attempts to use this
      interface.  Future warning will be suppressed until the kernel is rebooted
      to prevent spamming the kernel log.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      51b1bd2a
    • D
      oom: badness heuristic rewrite · a63d83f4
      David Rientjes 提交于
      This a complete rewrite of the oom killer's badness() heuristic which is
      used to determine which task to kill in oom conditions.  The goal is to
      make it as simple and predictable as possible so the results are better
      understood and we end up killing the task which will lead to the most
      memory freeing while still respecting the fine-tuning from userspace.
      
      Instead of basing the heuristic on mm->total_vm for each task, the task's
      rss and swap space is used instead.  This is a better indication of the
      amount of memory that will be freeable if the oom killed task is chosen
      and subsequently exits.  This helps specifically in cases where KDE or
      GNOME is chosen for oom kill on desktop systems instead of a memory
      hogging task.
      
      The baseline for the heuristic is a proportion of memory that each task is
      currently using in memory plus swap compared to the amount of "allowable"
      memory.  "Allowable," in this sense, means the system-wide resources for
      unconstrained oom conditions, the set of mempolicy nodes, the mems
      attached to current's cpuset, or a memory controller's limit.  The
      proportion is given on a scale of 0 (never kill) to 1000 (always kill),
      roughly meaning that if a task has a badness() score of 500 that the task
      consumes approximately 50% of allowable memory resident in RAM or in swap
      space.
      
      The proportion is always relative to the amount of "allowable" memory and
      not the total amount of RAM systemwide so that mempolicies and cpusets may
      operate in isolation; they shall not need to know the true size of the
      machine on which they are running if they are bound to a specific set of
      nodes or mems, respectively.
      
      Root tasks are given 3% extra memory just like __vm_enough_memory()
      provides in LSMs.  In the event of two tasks consuming similar amounts of
      memory, it is generally better to save root's task.
      
      Because of the change in the badness() heuristic's baseline, it is also
      necessary to introduce a new user interface to tune it.  It's not possible
      to redefine the meaning of /proc/pid/oom_adj with a new scale since the
      ABI cannot be changed for backward compatability.  Instead, a new tunable,
      /proc/pid/oom_score_adj, is added that ranges from -1000 to +1000.  It may
      be used to polarize the heuristic such that certain tasks are never
      considered for oom kill while others may always be considered.  The value
      is added directly into the badness() score so a value of -500, for
      example, means to discount 50% of its memory consumption in comparison to
      other tasks either on the system, bound to the mempolicy, in the cpuset,
      or sharing the same memory controller.
      
      /proc/pid/oom_adj is changed so that its meaning is rescaled into the
      units used by /proc/pid/oom_score_adj, and vice versa.  Changing one of
      these per-task tunables will rescale the value of the other to an
      equivalent meaning.  Although /proc/pid/oom_adj was originally defined as
      a bitshift on the badness score, it now shares the same linear growth as
      /proc/pid/oom_score_adj but with different granularity.  This is required
      so the ABI is not broken with userspace applications and allows oom_adj to
      be deprecated for future removal.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a63d83f4
    • A
      oom: move badness() declaration into oom.h · 74bcbf40
      Andrew Morton 提交于
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      74bcbf40
    • K
      oom: /proc/<pid>/oom_score treat kernel thread honestly · 26ebc984
      KOSAKI Motohiro 提交于
      If a kernel thread is using use_mm(), badness() returns a positive value.
      This is not a big issue because caller take care of it correctly.  But
      there is one exception, /proc/<pid>/oom_score calls badness() directly and
      doesn't care that the task is a regular process.
      
      Another example, /proc/1/oom_score return !0 value.  But it's unkillable.
      This incorrectness makes administration a little confusing.
      
      This patch fixes it.
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26ebc984
  2. 08 8月, 2010 1 次提交
    • D
      AFS: Fix the module init error handling · df44f9f4
      David Howells 提交于
      Fix the module init error handling.  There are a bunch of goto labels for
      aborting the init procedure at different points and just undoing what needs
      undoing - they aren't all in the right places, however.
      
      This can lead to an oops like the following:
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
      	IP: [<ffffffff81042a31>] destroy_workqueue+0x17/0xc0
      	...
      	Modules linked in: kafs(+) dns_resolver rxkad af_rxrpc fscache
      
      	Pid: 2171, comm: insmod Not tainted 2.6.35-cachefs+ #319 DG965RY/
      	...
      	Process insmod (pid: 2171, threadinfo ffff88003ca6a000, task ffff88003dcc3050)
      	...
      	Call Trace:
      	 [<ffffffffa0055994>] afs_callback_update_kill+0x10/0x12 [kafs]
      	 [<ffffffffa007d1c5>] afs_init+0x190/0x1ce [kafs]
      	 [<ffffffffa007d035>] ? afs_init+0x0/0x1ce [kafs]
      	 [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
      	 [<ffffffff8105f7ee>] sys_init_module+0x9c/0x1de
      	 [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df44f9f4
  3. 07 8月, 2010 10 次提交
  4. 06 8月, 2010 14 次提交
  5. 05 8月, 2010 2 次提交
    • E
      ext4: re-inline ext4_rec_len_(to|from)_disk functions · 0cfc9255
      Eric Sandeen 提交于
      commit 3d0518f4, "ext4: New rec_len encoding for very
      large blocksizes" made several changes to this path, but from
      a perf perspective, un-inlining ext4_rec_len_from_disk() seems
      most significant.  This function is called from ext4_check_dir_entry(),
      which on a file-creation workload is called extremely often.
      
      I tested this with bonnie:
      
      # bonnie++ -u root -s 0 -f -x 200 -d /mnt/test -n 32
      
      (this does 200 iterations) and got this for the file creations:
      
      ext4 stock:   Average =  21206.8 files/s
      ext4 inlined: Average =  22346.7 files/s  (+5%)
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      0cfc9255
    • T
      block_dev: always serialize exclusive open attempts · e75aa858
      Tejun Heo 提交于
      bd_prepare_to_claim() incorrectly allowed multiple attempts for
      exclusive open to progress in parallel if the attempting holders are
      identical.  This triggered BUG_ON() as reported in the following bug.
      
        https://bugzilla.kernel.org/show_bug.cgi?id=16393
      
      __bd_abort_claiming() is used to finish claiming blocks and doesn't
      work if multiple openers are inside a claiming block.  Allowing
      multiple parallel open attempts to continue doesn't gain anything as
      those are serialized down in the call chain anyway.  Fix it by always
      allowing only single open attempt in a claiming block.
      
      This problem can easily be reproduced by adding a delay after
      bd_prepare_to_claim() and attempting to mount two partitions of a
      disk.
      
      stable: only applicable to v2.6.35
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e75aa858
  6. 04 8月, 2010 6 次提交