1. 25 May, 2005 11 commits
  2. 23 May, 2005 15 commits
  3. 21 May, 2005 8 commits
    • Suparna Bhattacharya's avatar
      [PATCH] fix for __generic_file_aio_read() to return 0 on EOF · b5c44c21
      Suparna Bhattacharya authored
      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: default avatarSuzuki K P <suzuki@in.ibm.com>
      Signed-off-by: default avatarSuparna Bhattacharya <suparna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b5c44c21
    • Vladimir Saveliev's avatar
      [PATCH] reiserfs: max_key fix · f359b74c
      Vladimir Saveliev authored
      This patch fixes a bug introduced by Al Viro's patch: [patch 136/174]
      reiserfs endianness: clone struct reiserfs_key
      
      The problem is MAX_KEY and MAX_IN_CORE_KEY defined in this patch do not
      look equal from reiserfs comp_key's point of view.  This caused reiserfs'
      sanity check to complain.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f359b74c
    • Linus Torvalds's avatar
      1808caff
    • Linus Torvalds's avatar
    • Samuel Thibault's avatar
      [PATCH] spin_unlock_bh() and preempt_check_resched() · 10f02d1c
      Samuel Thibault authored
      In _spin_unlock_bh(lock):
      	do { \
      		_raw_spin_unlock(lock); \
      		preempt_enable(); \
      		local_bh_enable(); \
      		__release(lock); \
      	} while (0)
      
      there is no reason for using preempt_enable() instead of a simple
      preempt_enable_no_resched()
      
      Since we know bottom halves are disabled, preempt_schedule() will always
      return at once (preempt_count!=0), and hence preempt_check_resched() is
      useless here...
      
      This fixes it by using "preempt_enable_no_resched()" instead of the
      "preempt_enable()", and thus avoids the useless preempt_check_resched()
      just before re-enabling bottom halves.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      10f02d1c
    • David Woodhouse's avatar
      When we detect that a 16550 was in fact part of a NatSemi SuperIO chip · 857dde2e
      David Woodhouse authored
      with high-speed mode enabled, we switch it to high-speed mode so that
      baud_base becomes 921600. However, we also need to multiply the baud
      divisor by 8 at the same time, in case it's already in use as a console.
      
      Signed-off-by: David Woodhouse
      Acked-by: Tom Rini
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      857dde2e
    • Pierre Ossman's avatar
      [PATCH] MMC: Proper MMC command classes support · 912490db
      Pierre Ossman authored
      Defines for the different command classes as defined in the MMC and SD
      specifications.
      
      Removes the check for high command classes and instead checks that the
      command classes needed are present.
      Previous solution killed forward compatibility at no apparent gain.
      
      Signed-of-by: Pierre Ossman
      912490db
    • Linus Torvalds's avatar
  4. 20 May, 2005 6 commits