1. 14 4月, 2010 2 次提交
    • D
      rcu: Better explain the condition parameter of rcu_dereference_check() · c08c68dd
      David Howells 提交于
      Better explain the condition parameter of
      rcu_dereference_check() that describes the conditions under
      which the dereference is permitted to take place (and
      incorporate Yong Zhang's suggestion).  This condition is only
      checked under lockdep proving.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: eric.dumazet@gmail.com
      LKML-Reference: <1270852752-25278-2-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c08c68dd
    • P
      rcu: Add rcu_access_pointer and rcu_dereference_protected · b62730ba
      Paul E. McKenney 提交于
      This patch adds variants of rcu_dereference() that handle
      situations where the RCU-protected data structure cannot change,
      perhaps due to our holding the update-side lock, or where the
      RCU-protected pointer is only to be fetched, not dereferenced.
      These are needed due to some performance concerns with using
      rcu_dereference() where it is not required, aside from the need
      for lockdep/sparse checking.
      
      The new rcu_access_pointer() primitive is for the case where the
      pointer is be fetch and not dereferenced.  This primitive may be
      used without protection, RCU or otherwise, due to the fact that
      it uses ACCESS_ONCE().
      
      The new rcu_dereference_protected() primitive is for the case
      where updates are prevented, for example, due to holding the
      update-side lock.  This primitive does neither ACCESS_ONCE() nor
      smp_read_barrier_depends(), so can only be used when updates are
      somehow prevented.
      Suggested-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      Cc: eric.dumazet@gmail.com
      LKML-Reference: <1270852752-25278-1-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b62730ba
  2. 12 4月, 2010 1 次提交
    • T
      NFSv4: fix delegated locking · 0df5dd4a
      Trond Myklebust 提交于
      Arnaud Giersch reports that NFSv4 locking is broken when we hold a
      delegation since commit 8e469ebd (NFSv4:
      Don't allow posix locking against servers that don't support it).
      
      According to Arnaud, the lock succeeds the first time he opens the file
      (since we cannot do a delegated open) but then fails after we start using
      delegated opens.
      
      The following patch fixes it by ensuring that locking behaviour is
      governed by a per-filesystem capability flag that is initially set, but
      gets cleared if the server ever returns an OPEN without the
      NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set.
      Reported-by: NArnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      0df5dd4a
  3. 10 4月, 2010 2 次提交
    • D
      radix_tree_tag_get() is not as safe as the docs make out [ver #2] · ce82653d
      David Howells 提交于
      radix_tree_tag_get() is not safe to use concurrently with radix_tree_tag_set()
      or radix_tree_tag_clear().  The problem is that the double tag_get() in
      radix_tree_tag_get():
      
      		if (!tag_get(node, tag, offset))
      			saw_unset_tag = 1;
      		if (height == 1) {
      			int ret = tag_get(node, tag, offset);
      
      may see the value change due to the action of set/clear.  RCU is no protection
      against this as no pointers are being changed, no nodes are being replaced
      according to a COW protocol - set/clear alter the node directly.
      
      The documentation in linux/radix-tree.h, however, says that
      radix_tree_tag_get() is an exception to the rule that "any function modifying
      the tree or tags (...) must exclude other modifications, and exclude any
      functions reading the tree".
      
      The problem is that the next statement in radix_tree_tag_get() checks that the
      tag doesn't vary over time:
      
      			BUG_ON(ret && saw_unset_tag);
      
      This has been seen happening in FS-Cache:
      
      	https://www.redhat.com/archives/linux-cachefs/2010-April/msg00013.html
      
      To this end, remove the BUG_ON() from radix_tree_tag_get() and note in various
      comments that the value of the tag may change whilst the RCU read lock is held,
      and thus that the return value of radix_tree_tag_get() may not be relied upon
      unless radix_tree_tag_set/clear() and radix_tree_delete() are excluded from
      running concurrently with it.
      Reported-by: NRomain DEGEZ <romain.degez@smartjog.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ce82653d
    • P
      slab: Generify kernel pointer validation · fc1c1833
      Pekka Enberg 提交于
      As suggested by Linus, introduce a kern_ptr_validate() helper that does some
      sanity checks to make sure a pointer is a valid kernel pointer.  This is a
      preparational step for fixing SLUB kmem_ptr_validate().
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc1c1833
  4. 09 4月, 2010 1 次提交
  5. 08 4月, 2010 1 次提交
  6. 07 4月, 2010 7 次提交
  7. 06 4月, 2010 2 次提交
    • T
      libata: unlock HPA if device shrunk · 445d211b
      Tejun Heo 提交于
      Some BIOSes don't configure HPA during boot but do so while resuming.
      This causes harddrives to shrink during resume making libata detach
      and reattach them.  This can be worked around by unlocking HPA if old
      size equals native size.
      
      Add ATA_DFLAG_UNLOCK_HPA so that HPA unlocking can be controlled
      per-device and update ata_dev_revalidate() such that it sets
      ATA_DFLAG_UNLOCK_HPA and fails with -EIO when the above condition is
      detected.
      
      This patch fixes the following bug.
      
        https://bugzilla.kernel.org/show_bug.cgi?id=15396Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NOleksandr Yermolenko <yaa.bta@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      445d211b
    • N
      Fix up possibly racy module refcounting · 5fbfb18d
      Nick Piggin 提交于
      Module refcounting is implemented with a per-cpu counter for speed.
      However there is a race when tallying the counter where a reference may
      be taken by one CPU and released by another.  Reference count summation
      may then see the decrement without having seen the previous increment,
      leading to lower than expected count.  A module which never has its
      actual reference drop below 1 may return a reference count of 0 due to
      this race.
      
      Module removal generally runs under stop_machine, which prevents this
      race causing bugs due to removal of in-use modules.  However there are
      other real bugs in module.c code and driver code (module_refcount is
      exported) where the callers do not run under stop_machine.
      
      Fix this by maintaining running per-cpu counters for the number of
      module refcount increments and the number of refcount decrements.  The
      increments are tallied after the decrements, so any decrement seen will
      always have its corresponding increment counted.  The final refcount is
      the difference of the total increments and decrements, preventing a
      low-refcount from being returned.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fbfb18d
  8. 02 4月, 2010 1 次提交
    • Y
      ibft, x86: Change reserve_ibft_region() to find_ibft_region() · 042be38e
      Yinghai Lu 提交于
      This allows arch code could decide the way to reserve the ibft.
      
      And we should reserve ibft as early as possible, instead of BOOTMEM
      stage, in case the table is in RAM range and is not reserved by BIOS
      (this will often be the case.)
      
      Move to just after find_smp_config().
      
      Also when CONFIG_NO_BOOTMEM=y, We will not have reserve_bootmem() anymore.
      
      -v2: fix typo about ibft pointed by Konrad Rzeszutek Wilk <konrad@darnok.org>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4BB510FB.80601@kernel.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      CC: Jan Beulich <jbeulich@novell.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      042be38e
  9. 01 4月, 2010 2 次提交
    • H
      ide: Requeue request after DMA timeout · 6072f749
      Herbert Xu 提交于
      I noticed that my KVM virtual machines were experiencing IDE
      issues resulting in processes stuck on waiting for buffers to
      complete.
      
      The root cause is of course race conditions in the ancient qemu
      backend that I'm using.  However, the fact that the guest isn't
      recovering is a bug.
      
      I've tracked it down to the change made last year to dequeue
      requests at the start rather than at the end in the IDE layer.
      
      commit 8f6205cd
      Author: Tejun Heo <tj@kernel.org>
      Date:   Fri May 8 11:53:59 2009 +0900
      
          ide: dequeue in-flight request
      
      The problem is that the function ide_dma_timeout_retry does not
      requeue the current request, causing one request to be lost for
      each DMA timeout.
      
      This patch fixes this by requeueing the request.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6072f749
    • F
      perf: Use hot regs with software sched switch/migrate events · e49a5bd3
      Frederic Weisbecker 提交于
      Scheduler's task migration events don't work because they always
      pass NULL regs perf_sw_event(). The event hence gets filtered
      in perf_swevent_add().
      
      Scheduler's context switches events use task_pt_regs() to get
      the context when the event occured which is a wrong thing to
      do as this won't give us the place in the kernel where we went
      to sleep but the place where we left userspace. The result is
      even more wrong if we switch from a kernel thread.
      
      Use the hot regs snapshot for both events as they belong to the
      non-interrupt/exception based events family. Unlike page faults
      or so that provide the regs matching the exact origin of the event,
      we need to save the current context.
      
      This makes the task migration event working and fix the context
      switch callchains and origin ip.
      
      Example: perf record -a -e cs
      
      Before:
      
          10.91%      ksoftirqd/0                  0  [k] 0000000000000000
                      |
                      --- (nil)
                          perf_callchain
                          perf_prepare_sample
                          __perf_event_overflow
                          perf_swevent_overflow
                          perf_swevent_add
                          perf_swevent_ctx_event
                          do_perf_sw_event
                          __perf_sw_event
                          perf_event_task_sched_out
                          schedule
                          run_ksoftirqd
                          kthread
                          kernel_thread_helper
      
      After:
      
          23.77%  hald-addon-stor  [kernel.kallsyms]  [k] schedule
                  |
                  --- schedule
                     |
                     |--60.00%-- schedule_timeout
                     |          wait_for_common
                     |          wait_for_completion
                     |          blk_execute_rq
                     |          scsi_execute
                     |          scsi_execute_req
                     |          sr_test_unit_ready
                     |          |
                     |          |--66.67%-- sr_media_change
                     |          |          media_changed
                     |          |          cdrom_media_changed
                     |          |          sr_block_media_changed
                     |          |          check_disk_change
                     |          |          cdrom_open
      
      v2: Always build perf_arch_fetch_caller_regs() now that software
      events need that too. They don't need it from modules, unlike trace
      events, so we keep the EXPORT_SYMBOL in trace_event_perf.c
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David Miller <davem@davemloft.net>
      e49a5bd3
  10. 31 3月, 2010 1 次提交
  11. 30 3月, 2010 6 次提交
    • T
      percpu: don't implicitly include slab.h from percpu.h · de380b55
      Tejun Heo 提交于
      percpu.h has always been including slab.h to get k[mz]alloc/free() for
      UP inline implementation.  percpu.h being used by very low level
      headers including module.h and sched.h, this meant that a lot files
      unintentionally got slab.h inclusion.
      
      Lee Schermerhorn was trying to make topology.h use percpu.h and got
      bitten by this implicit inclusion.  The right thing to do is break
      this ultimately unnecessary dependency.  The previous patch added
      explicit inclusion of either gfp.h or slab.h to the source files using
      them.  This patch updates percpu.h such that slab.h is no longer
      included from percpu.h.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      de380b55
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
    • L
      ext3: fix broken handling of EXT3_STATE_NEW · de329820
      Linus Torvalds 提交于
      In commit 9df93939 ("ext3: Use bitops to read/modify
      EXT3_I(inode)->i_state") ext3 changed its internal 'i_state' variable to
      use bitops for its state handling.  However, unline the same ext4
      change, it didn't actually change the name of the field when it changed
      the semantics of it.
      
      As a result, an old use of 'i_state' remained in fs/ext3/ialloc.c that
      initialized the field to EXT3_STATE_NEW.  And that does not work
      _at_all_ when we're now working with individually named bits rather than
      values that get masked.  So the code tried to mark the state to be new,
      but in actual fact set the field to EXT3_STATE_JDATA.  Which makes no
      sense at all, and screws up all the code that checks whether the inode
      was newly allocated.
      
      In particular, it made the xattr code unhappy, and caused various random
      behavior, like apparently
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=577911
      
      So fix the initialization, and rename the field to match ext4 so that we
      don't have this happen again.
      
      Cc: James Morris <jmorris@namei.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Daniel J Walsh <dwalsh@redhat.com>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      de329820
    • V
      ARM: 6003/1: removing compilation warning from pl061.h · 367d6acc
      viresh kumar 提交于
      pl061.h is using u8 type. including <linux/types.h> in pl061.h to avoid
      warning.
      Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
      Acked-by: NBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      367d6acc
    • V
      ARM: 5999/1: Including device.h and resource.h header files in linux/amba/bus.h · c36207a4
      viresh kumar 提交于
      linux/amba/bus.h have dependencies on linux/device.h and linux/resource.h, but
      it doesn't include them. We get compilation errors in our files which include
      bus.h but doesn't include device.h and resource.h. This patch includes device.h
      and resource.h in linux/amba/bus.h file.
      Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
      Acked-by: NLinux Walleij <linux.ml.walleij@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c36207a4
    • D
      SLOW_WORK: CONFIG_SLOW_WORK_PROC should be CONFIG_SLOW_WORK_DEBUG · a53f4f9e
      David Howells 提交于
      CONFIG_SLOW_WORK_PROC was changed to CONFIG_SLOW_WORK_DEBUG, but not in all
      instances.  Change the remaining instances.  This makes the debugfs file
      display the time mark and the owner's description again.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a53f4f9e
  12. 29 3月, 2010 2 次提交
  13. 27 3月, 2010 2 次提交
    • B
      net: Add MSG_WAITFORONE flag to recvmmsg · 71c5c159
      Brandon L Black 提交于
      Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
      When this flag is specified for a blocking socket, recvmmsg()
      will only block until at least 1 packet is available.  The
      default behavior is to block until all vlen packets are
      available.  This flag has no effect on non-blocking sockets
      or when used in combination with MSG_DONTWAIT.
      Signed-off-by: NBrandon L Black <blblack@gmail.com>
      Acked-by: NUlrich Drepper <drepper@redhat.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71c5c159
    • M
      Freezer: Fix buggy resume test for tasks frozen with cgroup freezer · 5a7aadfe
      Matt Helsley 提交于
      When the cgroup freezer is used to freeze tasks we do not want to thaw
      those tasks during resume. Currently we test the cgroup freezer
      state of the resuming tasks to see if the cgroup is FROZEN.  If so
      then we don't thaw the task. However, the FREEZING state also indicates
      that the task should remain frozen.
      
      This also avoids a problem pointed out by Oren Ladaan: the freezer state
      transition from FREEZING to FROZEN is updated lazily when userspace reads
      or writes the freezer.state file in the cgroup filesystem. This means that
      resume will thaw tasks in cgroups which should be in the FROZEN state if
      there is no read/write of the freezer.state file to trigger this
      transition before suspend.
      
      NOTE: Another "simple" solution would be to always update the cgroup
      freezer state during resume. However it's a bad choice for several reasons:
      Updating the cgroup freezer state is somewhat expensive because it requires
      walking all the tasks in the cgroup and checking if they are each frozen.
      Worse, this could easily make resume run in N^2 time where N is the number
      of tasks in the cgroup. Finally, updating the freezer state from this code
      path requires trickier locking because of the way locks must be ordered.
      
      Instead of updating the freezer state we rely on the fact that lazy
      updates only manage the transition from FREEZING to FROZEN. We know that
      a cgroup with the FREEZING state may actually be FROZEN so test for that
      state too. This makes sense in the resume path even for partially-frozen
      cgroups -- those that really are FREEZING but not FROZEN.
      Reported-by: NOren Ladaan <orenl@cs.columbia.edu>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Cc: stable@kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5a7aadfe
  14. 25 3月, 2010 6 次提交
  15. 24 3月, 2010 2 次提交
  16. 23 3月, 2010 1 次提交
  17. 22 3月, 2010 1 次提交