1. 04 Feb, 2008 38 commits
  2. 02 Feb, 2008 2 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6 · 9135f190
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (95 commits)
        ide-tape: remove idetape_config_t typedef
        ide-tape: remove mtio.h related comments
        ide-tape: make function name more accurate
        ide-tape: remove unused sense packet commands.
        ide-tape: use generic byteorder macros
        ide-tape: remove EXPERIMENTAL driver status
        ide-tape: use generic scsi commands
        ide-tape: remove struct idetape_block_size_page_t
        ide-tape: remove structs os_partition_t, os_dat_entry_t, os_dat_t
        ide-tape: remove struct idetape_parameter_block_descriptor_t
        ide-tape: remove struct idetape_medium_partition_page_t
        ide-tape: remove struct idetape_data_compression_page_t
        ide-tape: remove struct idetape_inquiry_result_t
        ide-tape: remove struct idetape_capabilities_page_t
        ide-tape: remove IDETAPE_DEBUG_BUGS
        ide-tape: remove IDETAPE_DEBUG_INFO
        ide-tape: dump gcw fields on error in idetape_identify_device()
        ide-tape: remove struct idetape_mode_parameter_header_t
        ide-tape: remove struct idetape_request_sense_result_t
        ide-tape: remove dead code
        ...
      9135f190
    • Nick Piggin's avatar
      fix writev regression: pan hanging unkillable and un-straceable · 124d3b70
      Nick Piggin authored
      Frederik Himpe reported an unkillable and un-straceable pan process.
      
      Zero length iovecs can go into an infinite loop in writev, because the
      iovec iterator does not always advance over them.
      
      The sequence required to trigger this is not trivial. I think it
      requires that a zero-length iovec be followed by a non-zero-length iovec
      which causes a pagefault in the atomic usercopy. This causes the writev
      code to drop back into single-segment copy mode, which then tries to
      copy the 0 bytes of the zero-length iovec; a zero length copy looks like
      a failure though, so it loops.
      
      Put a test into iov_iter_advance to catch zero-length iovecs. We could
      just put the test in the fallback path, but I feel it is more robust to
      skip over zero-length iovecs throughout the code (iovec iterator may be
      used in filesystems too, so it should be robust).
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      124d3b70