1. 26 4月, 2013 1 次提交
  2. 10 4月, 2013 1 次提交
  3. 04 3月, 2013 1 次提交
  4. 28 2月, 2013 1 次提交
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  5. 24 2月, 2013 2 次提交
  6. 23 7月, 2012 1 次提交
  7. 01 6月, 2012 2 次提交
  8. 22 5月, 2012 1 次提交
    • L
      vfs: make AIO use the proper rw_verify_area() area helpers · a70b52ec
      Linus Torvalds 提交于
      We had for some reason overlooked the AIO interface, and it didn't use
      the proper rw_verify_area() helper function that checks (for example)
      mandatory locking on the file, and that the size of the access doesn't
      cause us to overflow the provided offset limits etc.
      
      Instead, AIO did just the security_file_permission() thing (that
      rw_verify_area() also does) directly.
      
      This fixes it to do all the proper helper functions, which not only
      means that now mandatory file locking works with AIO too, we can
      actually remove lines of code.
      Reported-by: NManish Honap <manish_honap_vit@yahoo.co.in>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a70b52ec
  9. 21 4月, 2012 3 次提交
  10. 01 4月, 2012 2 次提交
  11. 21 3月, 2012 6 次提交
  12. 20 3月, 2012 1 次提交
  13. 10 3月, 2012 2 次提交
    • A
      aio: fix the "too late munmap()" race · c7b28555
      Al Viro 提交于
      Current code has put_ioctx() called asynchronously from aio_fput_routine();
      that's done *after* we have killed the request that used to pin ioctx,
      so there's nothing to stop io_destroy() waiting in wait_for_all_aios()
      from progressing.  As the result, we can end up with async call of
      put_ioctx() being the last one and possibly happening during exit_mmap()
      or elf_core_dump(), neither of which expects stray munmap() being done
      to them...
      
      We do need to prevent _freeing_ ioctx until aio_fput_routine() is done
      with that, but that's all we care about - neither io_destroy() nor
      exit_aio() will progress past wait_for_all_aios() until aio_fput_routine()
      does really_put_req(), so the ioctx teardown won't be done until then
      and we don't care about the contents of ioctx past that point.
      
      Since actual freeing of these suckers is RCU-delayed, we don't need to
      bump ioctx refcount when request goes into list for async removal.
      All we need is rcu_read_lock held just over the ->ctx_lock-protected
      area in aio_fput_routine().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NBenjamin LaHaise <bcrl@kvack.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c7b28555
    • A
      aio: fix io_setup/io_destroy race · 86b62a2c
      Al Viro 提交于
      Have ioctx_alloc() return an extra reference, so that caller would drop it
      on success and not bother with re-grabbing it on failure exit.  The current
      code is obviously broken - io_destroy() from another thread that managed
      to guess the address io_setup() would've returned would free ioctx right
      under us; gets especially interesting if aio_context_t * we pass to
      io_setup() points to PROT_READ mapping, so put_user() fails and we end
      up doing io_destroy() on kioctx another thread has just got freed...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: NBenjamin LaHaise <bcrl@kvack.org>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86b62a2c
  14. 06 3月, 2012 1 次提交
    • J
      aio: wake up waiters when freeing unused kiocbs · 880641bb
      Jeff Moyer 提交于
      Bart Van Assche reported a hung fio process when either hot-removing
      storage or when interrupting the fio process itself.  The (pruned) call
      trace for the latter looks like so:
      
        fio             D 0000000000000001     0  6849   6848 0x00000004
         ffff880092541b88 0000000000000046 ffff880000000000 ffff88012fa11dc0
         ffff88012404be70 ffff880092541fd8 ffff880092541fd8 ffff880092541fd8
         ffff880128b894d0 ffff88012404be70 ffff880092541b88 000000018106f24d
        Call Trace:
          schedule+0x3f/0x60
          io_schedule+0x8f/0xd0
          wait_for_all_aios+0xc0/0x100
          exit_aio+0x55/0xc0
          mmput+0x2d/0x110
          exit_mm+0x10d/0x130
          do_exit+0x671/0x860
          do_group_exit+0x44/0xb0
          get_signal_to_deliver+0x218/0x5a0
          do_signal+0x65/0x700
          do_notify_resume+0x65/0x80
          int_signal+0x12/0x17
      
      The problem lies with the allocation batching code.  It will
      opportunistically allocate kiocbs, and then trim back the list of iocbs
      when there is not enough room in the completion ring to hold all of the
      events.
      
      In the case above, what happens is that the pruning back of events ends
      up freeing up the last active request and the context is marked as dead,
      so it is thus responsible for waking up waiters.  Unfortunately, the
      code does not check for this condition, so we end up with a hung task.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Reported-by: NBart Van Assche <bvanassche@acm.org>
      Tested-by: NBart Van Assche <bvanassche@acm.org>
      Cc: <stable@kernel.org>		[3.2.x only]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      880641bb
  15. 29 2月, 2012 1 次提交
  16. 14 1月, 2012 1 次提交
    • G
      Unused iocbs in a batch should not be accounted as active. · 69e4747e
      Gleb Natapov 提交于
      Since commit 080d676d ("aio: allocate kiocbs in batches") iocbs are
      allocated in a batch during processing of first iocbs.  All iocbs in a
      batch are automatically added to ctx->active_reqs list and accounted in
      ctx->reqs_active.
      
      If one (not the last one) of iocbs submitted by an user fails, further
      iocbs are not processed, but they are still present in ctx->active_reqs
      and accounted in ctx->reqs_active.  This causes process to stuck in a D
      state in wait_for_all_aios() on exit since ctx->reqs_active will never
      go down to zero.  Furthermore since kiocb_batch_free() frees iocb
      without removing it from active_reqs list the list become corrupted
      which may cause oops.
      
      Fix this by removing iocb from ctx->active_reqs and updating
      ctx->reqs_active in kiocb_batch_free().
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: stable@kernel.org   # 3.2
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69e4747e
  17. 03 11月, 2011 1 次提交
    • J
      aio: allocate kiocbs in batches · 080d676d
      Jeff Moyer 提交于
      In testing aio on a fast storage device, I found that the context lock
      takes up a fair amount of cpu time in the I/O submission path.  The reason
      is that we take it for every I/O submitted (see __aio_get_req).  Since we
      know how many I/Os are passed to io_submit, we can preallocate the kiocbs
      in batches, reducing the number of times we take and release the lock.
      
      In my testing, I was able to reduce the amount of time spent in
      _raw_spin_lock_irq by .56% (average of 3 runs).  The command I used to
      test this was:
      
         aio-stress -O -o 2 -o 3 -r 8 -d 128 -b 32 -i 32 -s 16384 <dev>
      
      I also tested the patch with various numbers of events passed to
      io_submit, and I ran the xfstests aio group of tests to ensure I didn't
      break anything.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: Daniel Ehrenberg <dehrenberg@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      080d676d
  18. 01 11月, 2011 1 次提交
    • C
      Cross Memory Attach · fcf63409
      Christopher Yeoh 提交于
      The basic idea behind cross memory attach is to allow MPI programs doing
      intra-node communication to do a single copy of the message rather than a
      double copy of the message via shared memory.
      
      The following patch attempts to achieve this by allowing a destination
      process, given an address and size from a source process, to copy memory
      directly from the source process into its own address space via a system
      call.  There is also a symmetrical ability to copy from the current
      process's address space into a destination process's address space.
      
      - Use of /proc/pid/mem has been considered, but there are issues with
        using it:
        - Does not allow for specifying iovecs for both src and dest, assuming
          preadv or pwritev was implemented either the area read from or
        written to would need to be contiguous.
        - Currently mem_read allows only processes who are currently
        ptrace'ing the target and are still able to ptrace the target to read
        from the target. This check could possibly be moved to the open call,
        but its not clear exactly what race this restriction is stopping
        (reason  appears to have been lost)
        - Having to send the fd of /proc/self/mem via SCM_RIGHTS on unix
        domain socket is a bit ugly from a userspace point of view,
        especially when you may have hundreds if not (eventually) thousands
        of processes  that all need to do this with each other
        - Doesn't allow for some future use of the interface we would like to
        consider adding in the future (see below)
        - Interestingly reading from /proc/pid/mem currently actually
        involves two copies! (But this could be fixed pretty easily)
      
      As mentioned previously use of vmsplice instead was considered, but has
      problems.  Since you need the reader and writer working co-operatively if
      the pipe is not drained then you block.  Which requires some wrapping to
      do non blocking on the send side or polling on the receive.  In all to all
      communication it requires ordering otherwise you can deadlock.  And in the
      example of many MPI tasks writing to one MPI task vmsplice serialises the
      copying.
      
      There are some cases of MPI collectives where even a single copy interface
      does not get us the performance gain we could.  For example in an
      MPI_Reduce rather than copy the data from the source we would like to
      instead use it directly in a mathops (say the reduce is doing a sum) as
      this would save us doing a copy.  We don't need to keep a copy of the data
      from the source.  I haven't implemented this, but I think this interface
      could in the future do all this through the use of the flags - eg could
      specify the math operation and type and the kernel rather than just
      copying the data would apply the specified operation between the source
      and destination and store it in the destination.
      
      Although we don't have a "second user" of the interface (though I've had
      some nibbles from people who may be interested in using it for intra
      process messaging which is not MPI).  This interface is something which
      hardware vendors are already doing for their custom drivers to implement
      fast local communication.  And so in addition to this being useful for
      OpenMPI it would mean the driver maintainers don't have to fix things up
      when the mm changes.
      
      There was some discussion about how much faster a true zero copy would
      go. Here's a link back to the email with some testing I did on that:
      
      http://marc.info/?l=linux-mm&m=130105930902915&w=2
      
      There is a basic man page for the proposed interface here:
      
      http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt
      
      This has been implemented for x86 and powerpc, other architecture should
      mainly (I think) just need to add syscall numbers for the process_vm_readv
      and process_vm_writev. There are 32 bit compatibility versions for
      64-bit kernels.
      
      For arch maintainers there are some simple tests to be able to quickly
      verify that the syscalls are working correctly here:
      
      http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgzSigned-off-by: NChris Yeoh <yeohc@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: <linux-man@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fcf63409
  19. 23 3月, 2011 1 次提交
    • R
      aio: wake all waiters when destroying ctx · e91f90bb
      Roland Dreier 提交于
      The test program below will hang because io_getevents() uses
      add_wait_queue_exclusive(), which means the wake_up() in io_destroy() only
      wakes up one of the threads.  Fix this by using wake_up_all() in the aio
      code paths where we want to make sure no one gets stuck.
      
      	// t.c -- compile with gcc -lpthread -laio t.c
      
      	#include <libaio.h>
      	#include <pthread.h>
      	#include <stdio.h>
      	#include <unistd.h>
      
      	static const int nthr = 2;
      
      	void *getev(void *ctx)
      	{
      		struct io_event ev;
      		io_getevents(ctx, 1, 1, &ev, NULL);
      		printf("io_getevents returned\n");
      		return NULL;
      	}
      
      	int main(int argc, char *argv[])
      	{
      		io_context_t ctx = 0;
      		pthread_t thread[nthr];
      		int i;
      
      		io_setup(1024, &ctx);
      
      		for (i = 0; i < nthr; ++i)
      			pthread_create(&thread[i], NULL, getev, ctx);
      
      		sleep(1);
      
      		io_destroy(ctx);
      
      		for (i = 0; i < nthr; ++i)
      			pthread_join(thread[i], NULL);
      
      		return 0;
      	}
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e91f90bb
  20. 10 3月, 2011 3 次提交
  21. 26 2月, 2011 2 次提交
  22. 27 1月, 2011 1 次提交
    • T
      fs/aio: aio_wq isn't used in memory reclaim path · d37adaa1
      Tejun Heo 提交于
      aio_wq isn't used during memory reclaim.  Convert to alloc_workqueue()
      without WQ_MEM_RECLAIM.  It's possible to use system_wq but given that
      the number of work items is determined from userland and the work item
      may block, enforcing strict concurrency limit would be a good idea.
      
      Also, move fput_work to system_wq so that aio_wq is used soley to
      throttle the max concurrency of aio work items and fput_work doesn't
      interact with other work items.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Cc: linux-aio@kvack.org
      d37adaa1
  23. 17 1月, 2011 1 次提交
  24. 14 1月, 2011 2 次提交
  25. 26 10月, 2010 1 次提交