1. 07 Aug, 2011 4 commits
    • Boaz Harrosh's avatar
      exofs: Rename raid engine from exofs/ios.c => ore · 8ff660ab
      Boaz Harrosh authored
      ORE stands for "Objects Raid Engine"
      
      This patch is a mechanical rename of everything that was in ios.c
      and its API declaration to an ore.c and an osd_ore.h header. The ore
      engine will later be used by the pnfs objects layout driver.
      
      * File ios.c => ore.c
      
      * Declaration of types and API are moved from exofs.h to a new
        osd_ore.h
      
      * All used types are prefixed by ore_ from their exofs_ name.
      
      * Shift includes from exofs.h to osd_ore.h so osd_ore.h is
        independent, include it from exofs.h.
      
      Other than a pure rename there are no other changes. Next patch
      will move the ore into it's own module and will export the API
      to be used by exofs and later the layout driver
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      8ff660ab
    • Boaz Harrosh's avatar
      exofs: ios: Move to a per inode components & device-table · 9e9db456
      Boaz Harrosh authored
      Exofs raid engine was saving on memory space by having a single layout-info,
      single pid, and a single device-table, global to the filesystem. Then passing
      a credential and object_id info at the io_state level, private for each
      inode. It would also devise this contraption of rotating the device table
      view for each inode->ino to spread out the device usage.
      
      This is not compatible with the pnfs-objects standard, demanding that
      each inode can have it's own layout-info, device-table, and each object
      component it's own pid, oid and creds.
      
      So: Bring exofs raid engine to be usable for generic pnfs-objects use by:
      
      * Define an exofs_comp structure that holds obj_id and credential info.
      
      * Break up exofs_layout struct to an exofs_components structure that holds a
        possible array of exofs_comp and the array of devices + the size of the
        arrays.
      
      * Add a "comps" parameter to get_io_state() that specifies the ids creds
        and device array to use for each IO.
      
        This enables to keep the layout global, but the device-table view, creds
        and IDs at the inode level. It only adds two 64bit to each inode, since
        some of these members already existed in another form.
      
      * ios raid engine now access layout-info and comps-info through the passed
        pointers. Everything is pre-prepared by caller for generic access of
        these structures and arrays.
      
      At the exofs Level:
      
      * Super block holds an exofs_components struct that holds the device
        array, previously in layout. The devices there are in device-table
        order. The device-array is twice bigger and repeats the device-table
        twice so now each inode's device array can point to a random device
        and have a round-robin view of the table, making it compatible to
        previous exofs versions.
      
      * Each inode has an exofs_components struct that is initialized at
        load time, with it's own view of the device table IDs and creds.
        When doing IO this gets passed to the io_state together with the
        layout.
      
      While preforming this change. Bugs where found where credentials with the
      wrong IDs where used to access the different SB objects (super.c). As well
      as some dead code. It was never noticed because the target we use does not
      check the credentials.
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      9e9db456
    • Boaz Harrosh's avatar
      exofs: Move exofs specific osd operations out of ios.c · 85e44df4
      Boaz Harrosh authored
      ios.c will be moving to an external library, for use by the
      objects-layout-driver. Remove from it some exofs specific functions.
      
      Also g_attr_logical_length is used both by inode.c and ios.c
      move definition to the later, to keep it independent
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      85e44df4
    • Boaz Harrosh's avatar
      exofs: Add offset/length to exofs_get_io_state · e1042ba0
      Boaz Harrosh authored
      In future raid code we will need to know the IO offset/length
      and if it's a read or write to determine some of the array
      sizes we'll need.
      
      So add a new exofs_get_rw_state() API for use when
      writeing/reading. All other simple cases are left using the
      old way.
      
      The major change to this is that now we need to call
      exofs_get_io_state later at inode.c::read_exec and
      inode.c::write_exec when we actually know these things. So this
      patch is kept separate so I can test things apart from other
      changes.
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      e1042ba0
  2. 04 Aug, 2011 5 commits
    • Boaz Harrosh's avatar
      exofs: Fix truncate for the raid-groups case · 16f75bb3
      Boaz Harrosh authored
      In the general raid-group case the truncate was wrong in that
      it did not also fix the object length of the neighboring groups.
      
      There are two bad cases in the old code:
      1. Space that should be freed was not.
      2. If a file That was big is truncated small, then made bigger
         again, the holes would not contain zeros but could expose old data.
         (If the growing of the file expands to more than a full
          groups cycle + group size (> S + T))
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      16f75bb3
    • Boaz Harrosh's avatar
      exofs: Small cleanup of exofs_fill_super · 9ce73047
      Boaz Harrosh authored
      Small cleanup that unifies duplicated code used in both the
      error and success cases
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      9ce73047
    • Boaz Harrosh's avatar
      exofs: BUG: Avoid sbi realloc · 6d4073e8
      Boaz Harrosh authored
      Since the beginning we realloced the sbi structure when a bigger
      then one device table was specified. (I know that was really stupid).
      
      Then much later when "register bdi" was added (By Jens) it was
      registering the pointer to sbi->bdi before the realloc.
      
      We never saw this problem because up till now the realloc did not
      do anything since the device table was small enough to fit in the
      original allocation. But once we starting testing with large device
      tables (Bigger then 28) we noticed the crash of writeback operating
      on a deallocated pointer.
      
      * Avoid the all mess by allocating the device-table as a second array
        and get rid of the variable-sized structure and the rest of this
        mess.
      * Take the chance to clean near by structures and comments.
      * Add a needed dprint on startup to indicate the loaded layout.
      * Also move the bdi registration to the very end because it will
        only fail in a low memory, which will probably fail before hand.
        There are many more likely causes to not load before that. This
        way the error handling is made simpler. (Just doing this would be
        enough to fix the BUG)
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      6d4073e8
    • Boaz Harrosh's avatar
      exofs: Remove pnfs-osd private definitions · 26ae93c2
      Boaz Harrosh authored
      Now that pnfs-osd has hit mainline we can remove exofs's
      private header. (And the FIXME comment)
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      26ae93c2
    • Boaz Harrosh's avatar
      nfs_xdr: Move nfs4_string definition out of #ifdef CONFIG_NFS_V4 · 655b1612
      Boaz Harrosh authored
      exofs file system wants to use pnfs_osd_xdr.h file instead of
      redefining pnfs-objects types in it's private "pnfs.h" headr.
      
      Before we do the switch we must make sure pnfs_osd_xdr.h is
      compilable also under NFS versions smaller than 4.1. Since now
      it is needed regardless of version, by the exofs code.
      
      nfs4_string is not the only nfs4 type out in the global scope.
      Ack-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      655b1612
  3. 22 Jul, 2011 2 commits
  4. 21 Jul, 2011 9 commits
  5. 20 Jul, 2011 20 commits
    • Linus Torvalds's avatar
      Merge branch 'core-urgent-for-linus' of... · cf6ace16
      Linus Torvalds authored
      Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        signal: align __lock_task_sighand() irq disabling and RCU
        softirq,rcu: Inform RCU of irq_exit() activity
        sched: Add irq_{enter,exit}() to scheduler_ipi()
        rcu: protect __rcu_read_unlock() against scheduler-using irq handlers
        rcu: Streamline code produced by __rcu_read_unlock()
        rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special
        rcu: decrease rcu_report_exp_rnp coupling with scheduler
      cf6ace16
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of... · acc11eab
      Linus Torvalds authored
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        sched: Avoid creating superfluous NUMA domains on non-NUMA systems
        sched: Allow for overlapping sched_domain spans
        sched: Break out cpu_power from the sched_group structure
      acc11eab
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of... · 919d25a7
      Linus Torvalds authored
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86. reboot: Make Dell Latitude E6320 use reboot=pci
        x86, doc only: Correct real-mode kernel header offset for init_size
        x86: Disable AMD_NUMA for 32bit for now
      919d25a7
    • Ingo Molnar's avatar
      Merge branch 'rcu/urgent' of... · d1e9ae47
      Ingo Molnar authored
      Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu into core/urgent
      d1e9ae47
    • Paul E. McKenney's avatar
      signal: align __lock_task_sighand() irq disabling and RCU · a841796f
      Paul E. McKenney authored
      The __lock_task_sighand() function calls rcu_read_lock() with interrupts
      and preemption enabled, but later calls rcu_read_unlock() with interrupts
      disabled.  It is therefore possible that this RCU read-side critical
      section will be preempted and later RCU priority boosted, which means that
      rcu_read_unlock() will call rt_mutex_unlock() in order to deboost itself, but
      with interrupts disabled. This results in lockdep splats, so this commit
      nests the RCU read-side critical section within the interrupt-disabled
      region of code.  This prevents the RCU read-side critical section from
      being preempted, and thus prevents the attempt to deboost with interrupts
      disabled.
      
      It is quite possible that a better long-term fix is to make rt_mutex_unlock()
      disable irqs when acquiring the rt_mutex structure's ->wait_lock.
      Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      a841796f
    • Peter Zijlstra's avatar
      softirq,rcu: Inform RCU of irq_exit() activity · ec433f0c
      Peter Zijlstra authored
      The rcu_read_unlock_special() function relies on in_irq() to exclude
      scheduler activity from interrupt level.  This fails because exit_irq()
      can invoke the scheduler after clearing the preempt_count() bits that
      in_irq() uses to determine that it is at interrupt level.  This situation
      can result in failures as follows:
      
       $task			IRQ		SoftIRQ
      
       rcu_read_lock()
      
       /* do stuff */
      
       <preempt> |= UNLOCK_BLOCKED
      
       rcu_read_unlock()
         --t->rcu_read_lock_nesting
      
      			irq_enter();
      			/* do stuff, don't use RCU */
      			irq_exit();
      			  sub_preempt_count(IRQ_EXIT_OFFSET);
      			  invoke_softirq()
      
      					ttwu();
      					  spin_lock_irq(&pi->lock)
      					  rcu_read_lock();
      					  /* do stuff */
      					  rcu_read_unlock();
      					    rcu_read_unlock_special()
      					      rcu_report_exp_rnp()
      					        ttwu()
      					          spin_lock_irq(&pi->lock) /* deadlock */
      
         rcu_read_unlock_special(t);
      
      Ed can simply trigger this 'easy' because invoke_softirq() immediately
      does a ttwu() of ksoftirqd/# instead of doing the in-place softirq stuff
      first, but even without that the above happens.
      
      Cure this by also excluding softirqs from the
      rcu_read_unlock_special() handler and ensuring the force_irqthreads
      ksoftirqd/# wakeup is done from full softirq context.
      
      [ Alternatively, delaying the ->rcu_read_lock_nesting decrement
        until after the special handling would make the thing more robust
        in the face of interrupts as well.  And there is a separate patch
        for that. ]
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-and-tested-by: default avatarEd Tomlinson <edt@aei.ca>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      ec433f0c
    • Peter Zijlstra's avatar
      sched: Add irq_{enter,exit}() to scheduler_ipi() · c5d753a5
      Peter Zijlstra authored
      Ensure scheduler_ipi() calls irq_{enter,exit} when it does some actual
      work. Traditionally we never did any actual work from the resched IPI
      and all magic happened in the return from interrupt path.
      
      Now that we do do some work, we need to ensure irq_{enter,exit} are
      called so that we don't confuse things.
      
      This affects things like timekeeping, NO_HZ and RCU, basically
      everything with a hook in irq_enter/exit.
      
      Explicit examples of things going wrong are:
      
        sched_clock_cpu() -- has a callback when leaving NO_HZ state to take
                          a new reading from GTOD and TSC. Without this
                          callback, time is stuck in the past.
      
        RCU -- needs in_irq() to work in order to avoid some nasty deadlocks
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      c5d753a5
    • Paul E. McKenney's avatar
      rcu: protect __rcu_read_unlock() against scheduler-using irq handlers · 10f39bb1
      Paul E. McKenney authored
      The addition of RCU read-side critical sections within runqueue and
      priority-inheritance lock critical sections introduced some deadlock
      cycles, for example, involving interrupts from __rcu_read_unlock()
      where the interrupt handlers call wake_up().  This situation can cause
      the instance of __rcu_read_unlock() invoked from interrupt to do some
      of the processing that would otherwise have been carried out by the
      task-level instance of __rcu_read_unlock().  When the interrupt-level
      instance of __rcu_read_unlock() is called with a scheduler lock held
      from interrupt-entry/exit situations where in_irq() returns false,
      deadlock can result.
      
      This commit resolves these deadlocks by using negative values of
      the per-task ->rcu_read_lock_nesting counter to indicate that an
      instance of __rcu_read_unlock() is in flight, which in turn prevents
      instances from interrupt handlers from doing any special processing.
      This patch is inspired by Steven Rostedt's earlier patch that similarly
      made __rcu_read_unlock() guard against interrupt-mediated recursion
      (see https://lkml.org/lkml/2011/7/15/326), but this commit refines
      Steven's approach to avoid the need for preemption disabling on the
      __rcu_read_unlock() fastpath and to also avoid the need for manipulating
      a separate per-CPU variable.
      
      This patch avoids need for preempt_disable() by instead using negative
      values of the per-task ->rcu_read_lock_nesting counter.  Note that nested
      rcu_read_lock()/rcu_read_unlock() pairs are still permitted, but they will
      never see ->rcu_read_lock_nesting go to zero, and will therefore never
      invoke rcu_read_unlock_special(), thus preventing them from seeing the
      RCU_READ_UNLOCK_BLOCKED bit should it be set in ->rcu_read_unlock_special.
      This patch also adds a check for ->rcu_read_unlock_special being negative
      in rcu_check_callbacks(), thus preventing the RCU_READ_UNLOCK_NEED_QS
      bit from being set should a scheduling-clock interrupt occur while
      __rcu_read_unlock() is exiting from an outermost RCU read-side critical
      section.
      
      Of course, __rcu_read_unlock() can be preempted during the time that
      ->rcu_read_lock_nesting is negative.  This could result in the setting
      of the RCU_READ_UNLOCK_BLOCKED bit after __rcu_read_unlock() checks it,
      and would also result it this task being queued on the corresponding
      rcu_node structure's blkd_tasks list.  Therefore, some later RCU read-side
      critical section would enter rcu_read_unlock_special() to clean up --
      which could result in deadlock if that critical section happened to be in
      the scheduler where the runqueue or priority-inheritance locks were held.
      
      This situation is dealt with by making rcu_preempt_note_context_switch()
      check for negative ->rcu_read_lock_nesting, thus refraining from
      queuing the task (and from setting RCU_READ_UNLOCK_BLOCKED) if we are
      already exiting from the outermost RCU read-side critical section (in
      other words, we really are no longer actually in that RCU read-side
      critical section).  In addition, rcu_preempt_note_context_switch()
      invokes rcu_read_unlock_special() to carry out the cleanup in this case,
      which clears out the ->rcu_read_unlock_special bits and dequeues the task
      (if necessary), in turn avoiding needless delay of the current RCU grace
      period and needless RCU priority boosting.
      
      It is still illegal to call rcu_read_unlock() while holding a scheduler
      lock if the prior RCU read-side critical section has ever had either
      preemption or irqs enabled.  However, the common use case is legal,
      namely where then entire RCU read-side critical section executes with
      irqs disabled, for example, when the scheduler lock is held across the
      entire lifetime of the RCU read-side critical section.
      Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      10f39bb1
    • Peter Zijlstra's avatar
      sched: Avoid creating superfluous NUMA domains on non-NUMA systems · d110235d
      Peter Zijlstra authored
      When creating sched_domains, stop when we've covered the entire
      target span instead of continuing to create domains, only to
      later find they're redundant and throw them away again.
      
      This avoids single node systems from touching funny NUMA
      sched_domain creation code and reduces the risks of the new
      SD_OVERLAP code.
      Requested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: mahesh@linux.vnet.ibm.com
      Cc: benh@kernel.crashing.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/1311180177.29152.57.camel@twinsSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d110235d
    • Peter Zijlstra's avatar
      sched: Allow for overlapping sched_domain spans · e3589f6c
      Peter Zijlstra authored
      Allow for sched_domain spans that overlap by giving such domains their
      own sched_group list instead of sharing the sched_groups amongst
      each-other.
      
      This is needed for machines with more than 16 nodes, because
      sched_domain_node_span() will generate a node mask from the
      16 nearest nodes without regard if these masks have any overlap.
      
      Currently sched_domains have a sched_group that maps to their child
      sched_domain span, and since there is no overlap we share the
      sched_group between the sched_domains of the various CPUs. If however
      there is overlap, we would need to link the sched_group list in
      different ways for each cpu, and hence sharing isn't possible.
      
      In order to solve this, allocate private sched_groups for each CPU's
      sched_domain but have the sched_groups share a sched_group_power
      structure such that we can uniquely track the power.
      Reported-and-tested-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-08bxqw9wis3qti9u5inifh3y@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e3589f6c
    • Peter Zijlstra's avatar
      sched: Break out cpu_power from the sched_group structure · 9c3f75cb
      Peter Zijlstra authored
      In order to prepare for non-unique sched_groups per domain, we need to
      carry the cpu_power elsewhere, so put a level of indirection in.
      Reported-and-tested-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-qkho2byuhe4482fuknss40ad@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9c3f75cb
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc · 47126d80
      Linus Torvalds authored
      * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc:
        davinci: DM365 EVM: fix video input mux bits
        ARM: davinci: Check for NULL return from irq_alloc_generic_chip
        arm: davinci: Fix low level gpio irq handlers' argument
      47126d80
    • Shaohua Li's avatar
      vmscan: fix a livelock in kswapd · 4746efde
      Shaohua Li authored
      I'm running a workload which triggers a lot of swap in a machine with 4
      nodes.  After I kill the workload, I found a kswapd livelock.  Sometimes
      kswapd3 or kswapd2 are keeping running and I can't access filesystem,
      but most memory is free.
      
      This looks like a regression since commit 08951e54 ("mm: vmscan:
      correct check for kswapd sleeping in sleeping_prematurely").
      
      Node 2 and 3 have only ZONE_NORMAL, but balance_pgdat() will return 0
      for classzone_idx.  The reason is end_zone in balance_pgdat() is 0 by
      default, if all zones have watermark ok, end_zone will keep 0.
      
      Later sleeping_prematurely() always returns true.  Because this is an
      order 3 wakeup, and if classzone_idx is 0, both balanced_pages and
      present_pages in pgdat_balanced() are 0.  We add a special case here.
      If a zone has no page, we think it's balanced.  This fixes the livelock.
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4746efde
    • Akinobu Mita's avatar
      fs/libfs.c: fix simple_attr_write() on 32bit machines · f7b88631
      Akinobu Mita authored
      Assume that /sys/kernel/debug/dummy64 is debugfs file created by
      debugfs_create_x64().
      
      	# cd /sys/kernel/debug
      	# echo 0x1234567812345678 > dummy64
      	# cat dummy64
      	0x0000000012345678
      
      	# echo 0x80000000 > dummy64
      	# cat dummy64
      	0xffffffff80000000
      
      A value larger than INT_MAX cannot be written to the debugfs file created
      by debugfs_create_u64 or debugfs_create_x64 on 32bit machine.  Because
      simple_attr_write() uses simple_strtol() for the conversion.
      
      To fix this, use simple_strtoll() instead.
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7b88631
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 · e501f29c
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
        vfs: fix race in rcu lookup of pruned dentry
        Fix cifs_get_root()
      
      [ Edited the last commit to get rid of a 'unused variable "seq"'
        warning due to Al editing the patch.  - Linus ]
      e501f29c
    • Linus Torvalds's avatar
      vfs: fix race in rcu lookup of pruned dentry · 59430262
      Linus Torvalds authored
      Don't update *inode in __follow_mount_rcu() until we'd verified that
      there is mountpoint there.  Kudos to Hugh Dickins for catching that
      one in the first place and eventually figuring out the solution (and
      catching a braino in the earlier version of patch).
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      59430262
    • Paul E. McKenney's avatar
      rcu: Streamline code produced by __rcu_read_unlock() · be0e1e21
      Paul E. McKenney authored
      Given some common flag combinations, particularly -Os, gcc will inline
      rcu_read_unlock_special() despite its being in an unlikely() clause.
      Use noinline to prohibit this misoptimization.
      
      In addition, move the second barrier() in __rcu_read_unlock() so that
      it is not on the common-case code path.  This will allow the compiler to
      generate better code for the common-case path through __rcu_read_unlock().
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      be0e1e21
    • Paul E. McKenney's avatar
      rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special · 7765be2f
      Paul E. McKenney authored
      The RCU_BOOST commits for TREE_PREEMPT_RCU introduced an other-task
      write to a new RCU_READ_UNLOCK_BOOSTED bit in the task_struct structure's
      ->rcu_read_unlock_special field, but, as noted by Steven Rostedt, without
      correctly synchronizing all accesses to ->rcu_read_unlock_special.
      This could result in bits in ->rcu_read_unlock_special being spuriously
      set and cleared due to conflicting accesses, which in turn could result
      in deadlocks between the rcu_node structure's ->lock and the scheduler's
      rq and pi locks.  These deadlocks would result from RCU incorrectly
      believing that the just-ended RCU read-side critical section had been
      preempted and/or boosted.  If that RCU read-side critical section was
      executed with either rq or pi locks held, RCU's ensuing (incorrect)
      calls to the scheduler would cause the scheduler to attempt to once
      again acquire the rq and pi locks, resulting in deadlock.  More complex
      deadlock cycles are also possible, involving multiple rq and pi locks
      as well as locks from multiple rcu_node structures.
      
      This commit fixes synchronization by creating ->rcu_boosted field in
      task_struct that is accessed and modified only when holding the ->lock
      in the rcu_node structure on which the task is queued (on that rcu_node
      structure's ->blkd_tasks list).  This results in tasks accessing only
      their own current->rcu_read_unlock_special fields, making unsynchronized
      access once again legal, and keeping the rcu_read_unlock() fastpath free
      of atomic instructions and memory barriers.
      
      The reason that the rcu_read_unlock() fastpath does not need to access
      the new current->rcu_boosted field is that this new field cannot
      be non-zero unless the RCU_READ_UNLOCK_BLOCKED bit is set in the
      current->rcu_read_unlock_special field.  Therefore, rcu_read_unlock()
      need only test current->rcu_read_unlock_special: if that is zero, then
      current->rcu_boosted must also be zero.
      
      This bug does not affect TINY_PREEMPT_RCU because this implementation
      of RCU accesses current->rcu_read_unlock_special with irqs disabled,
      thus preventing races on the !SMP systems that TINY_PREEMPT_RCU runs on.
      Maybe-reported-by: default avatarDave Jones <davej@redhat.com>
      Maybe-reported-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      7765be2f
    • Paul E. McKenney's avatar
      rcu: decrease rcu_report_exp_rnp coupling with scheduler · 131906b0
      Paul E. McKenney authored
      PREEMPT_RCU read-side critical sections blocking an expedited grace
      period invoke rcu_report_exp_rnp().  When the last such critical section
      has completed, rcu_report_exp_rnp() invokes the scheduler to wake up the
      task that invoked synchronize_rcu_expedited() -- needlessly holding the
      root rcu_node structure's lock while doing so, thus needlessly providing
      a way for RCU and the scheduler to deadlock.
      
      This commit therefore releases the root rcu_node structure's lock before
      calling wake_up().
      Reported-by: default avatarEd Tomlinson <edt@aei.ca>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      131906b0