1. 28 10月, 2005 1 次提交
  2. 11 9月, 2005 1 次提交
  3. 05 9月, 2005 2 次提交
    • P
      [PATCH] shmem_populate: avoid an useless check, and some comments · d44ed4f8
      Paolo 'Blaisorblade' Giarrusso 提交于
      Either shmem_getpage returns a failure, or it found a page, or it was told
      it couldn't do any I/O.  So it's useless to check nonblock in the else
      branch.  We could add a BUG() there but I preferred to comment the
      offending function.
      
      This was taken out from one Ingo Molnar's old patch I'm resurrecting.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d44ed4f8
    • H
      [PATCH] swap: swap_lock replace list+device · 5d337b91
      Hugh Dickins 提交于
      The idea of a swap_device_lock per device, and a swap_list_lock over them all,
      is appealing; but in practice almost every holder of swap_device_lock must
      already hold swap_list_lock, which defeats the purpose of the split.
      
      The only exceptions have been swap_duplicate, valid_swaphandles and an
      untrodden path in try_to_unuse (plus a few places added in this series).
      valid_swaphandles doesn't show up high in profiles, but swap_duplicate does
      demand attention.  However, with the hold time in get_swap_pages so much
      reduced, I've not yet found a load and set of swap device priorities to show
      even swap_duplicate benefitting from the split.  Certainly the split is mere
      overhead in the common case of a single swap device.
      
      So, replace swap_list_lock and swap_device_lock by spinlock_t swap_lock
      (generally we seem to prefer an _ in the name, and not hide in a macro).
      
      If someone can show a regression in swap_duplicate, then probably we should
      add a hashlock for the swap_map entries alone (shorts being anatomic), so as
      to help the case of the single swap device too.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d337b91
  4. 26 6月, 2005 2 次提交
  5. 24 6月, 2005 2 次提交
  6. 07 6月, 2005 1 次提交
  7. 22 5月, 2005 1 次提交
    • S
      [PATCH] fix for __generic_file_aio_read() to return 0 on EOF · b5c44c21
      Suparna Bhattacharya 提交于
      I came across the following problem while running ltp-aiodio testcases from
      ltp-full-20050405 on linux-2.6.12-rc3-mm3.  I tried running the tests with
      EXT3 as well as JFS filesystems.
      
      One or two fsx-linux testcases were hung after some time.  These testcases
      were hanging at wait_for_all_aios().
      
      Debugging shows that there were some iocbs which were not getting completed
      eventhough the last retry for those returned -EIOCBQUEUED.  Also all such
      pending iocbs represented READ operation.
      
      Further debugging revealed that all such iocbs hit EOF in the DIO layer.
      To be more precise, the "pos" from which they were trying to read was
      greater than the "size" of the file.  So the generic_file_direct_IO
      returned 0.
      
      This happens rarely as there is already a check in
      __generic_file_aio_read(), for whether "pos" < "size" before calling direct
      IO routine.
      
      >size = i_size_read(inode);
      >if (pos < size) {
      >	  retval = generic_file_direct_IO(READ, iocb,
      >                               iov, pos, nr_segs);
      
      But for READ, we are taking the inode->i_sem only in the DIO layer.  So it
      is possible that some other process can change the size of the file before
      we take the i_sem.  In such a case ( when "pos" > "size"), the
      __generic_file_aio_read() would return -EIOCBQUEUED even though there were
      no I/O requests submitted by the DIO layer.  This would cause the AIO layer
      to expect aio_complete() for THE iocb, which doesnot happen.  And thus the
      test hangs forever, waiting for an I/O completion, where there are no
      requests submitted at all.
      
      The following patch makes __generic_file_aio_read() return 0 (instead of
      returning -EIOCBQUEUED), on getting 0 from generic_file_direct_IO(), so
      that the AIO layer does the aio_complete().
      
      Testing:
      
      I have tested the patch on a SMP machine(with 2 Pentium 4 (HT)) running
      linux-2.6.12-rc3-mm3.  I ran the ltp-aiodio testcases and none of the
      fsx-linux tests hung.  Also the aio-stress tests ran without any problem.
      Signed-off-by: NSuzuki K P <suzuki@in.ibm.com>
      Signed-off-by: NSuparna Bhattacharya <suparna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5c44c21
  8. 06 5月, 2005 1 次提交
  9. 01 5月, 2005 4 次提交
  10. 17 4月, 2005 2 次提交
    • J
      [PATCH] filemap_getpage can block when MAP_NONBLOCK specified · d3457342
      Jeff Moyer 提交于
      We will return NULL from filemap_getpage when a page does not exist in the
      page cache and MAP_NONBLOCK is specified, here:
      
      	page = find_get_page(mapping, pgoff);
      	if (!page) {
      		if (nonblock)
      			return NULL;
      		goto no_cached_page;
      	}
      
      But we forget to do so when the page in the cache is not uptodate.  The
      following could result in a blocking call:
      
      	/*
      	 * Ok, found a page in the page cache, now we need to check
      	 * that it's up-to-date.
      	 */
      	if (!PageUptodate(page))
      		goto page_not_uptodate;
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d3457342
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4