1. 05 Sep, 2009 7 commits
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2 · ac7ac9f2
      Linus Torvalds authored
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
        ocfs2: ocfs2_write_begin_nolock() should handle len=0
        ocfs2: invalidate dentry if its dentry_lock isn't initialized.
      ac7ac9f2
    • Linus Torvalds's avatar
      pty: don't limit the writes to 'pty_space()' inside 'pty_write()' · ac89a917
      Linus Torvalds authored
      The whole write-room thing is something that is up to the _caller_ to
      worry about, not the pty layer itself.  The total buffer space will
      still be limited by the buffering routines themselves, so there is no
      advantage or need in having pty_write() artificially limit the size
      somehow.
      
      And what happened was that the caller (the n_tty line discipline, in
      this case) may have verified that there is room for 2 bytes to be
      written (for NL -> CRNL expansion), and it used to then do those writes
      as two single-byte writes.  And if the first byte written (CR) then
      caused a new tty buffer to be allocated, pty_space() may have returned
      zero when trying to write the second byte (LF), and then incorrectly
      failed the write - leading to a lost newline character.
      
      This should finally fix
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=14015Reported-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ac89a917
    • Linus Torvalds's avatar
      n_tty: do O_ONLCR translation as a single write · 37f81fa1
      Linus Torvalds authored
      When translating CR to CRNL in the n_tty line discipline, we did it as
      two tty_put_char() calls.  Which works, but is stupid, and has caused
      problems before too with bad interactions with the write_room() logic.
      The generic USB serial driver had that problem, for example.
      
      Now the pty layer had similar issues after being moved to the generic
      tty buffering code (in commit d945cb9c:
      "pty: Rework the pty layer to use the normal buffering logic").
      
      So stop doing the silly separate two writes, and do it as a single write
      instead.  That's what the n_tty layer already does for the space
      expansion of tabs (XTABS), and it means that we'll now always have just
      a single write for the CRNL to match the single 'tty_write_room()' test,
      which hopefully means that the next time somebody screws up buffering,
      it won't cause weeks of debugging.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37f81fa1
    • Oleg Nesterov's avatar
      exec: do not sleep in TASK_TRACED under ->cred_guard_mutex · a2a8474c
      Oleg Nesterov authored
      Tom Horsley reports that his debugger hangs when it tries to read
      /proc/pid_of_tracee/maps, this happens since
      
      	"mm_for_maps: take ->cred_guard_mutex to fix the race with exec"
      	04b836cbf19e885f8366bccb2e4b0474346c02d
      
      commit in 2.6.31.
      
      But the root of the problem lies in the fact that do_execve() path calls
      tracehook_report_exec() which can stop if the tracer sets PT_TRACE_EXEC.
      
      The tracee must not sleep in TASK_TRACED holding this mutex.  Even if we
      remove ->cred_guard_mutex from mm_for_maps() and proc_pid_attr_write(),
      another task doing PTRACE_ATTACH should not hang until it is killed or the
      tracee resumes.
      
      With this patch do_execve() does not use ->cred_guard_mutex directly and
      we do not hold it throughout, instead:
      
      	- introduce prepare_bprm_creds() helper, it locks the mutex
      	  and calls prepare_exec_creds() to initialize bprm->cred.
      
      	- install_exec_creds() drops the mutex after commit_creds(),
      	  and thus before tracehook_report_exec()->ptrace_stop().
      
      	  or, if exec fails,
      
      	  free_bprm() drops this mutex when bprm->cred != NULL which
      	  indicates install_exec_creds() was not called.
      Reported-by: default avatarTom Horsley <tom.horsley@att.net>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a2a8474c
    • Mel Gorman's avatar
      page-allocator: always change pageblock ownership when anti-fragmentation is disabled · dd5d241e
      Mel Gorman authored
      On low-memory systems, anti-fragmentation gets disabled as fragmentation
      cannot be avoided on a sufficiently large boundary to be worthwhile.  Once
      disabled, there is a period of time when all the pageblocks are marked
      MOVABLE and the expectation is that they get marked UNMOVABLE at each call
      to __rmqueue_fallback().
      
      However, when MAX_ORDER is large the pageblocks do not change ownership
      because the normal criteria are not met.  This has the effect of
      prematurely breaking up too many large contiguous blocks.  This is most
      serious on NOMMU systems which depend on high-order allocations to boot.
      This patch causes pageblocks to change ownership on every fallback when
      anti-fragmentation is disabled.  This prevents the large blocks being
      prematurely broken up.
      
      This is a fix to commit 49255c61 [page
      allocator: move check for disabled anti-fragmentation out of fastpath] and
      the problem affects 2.6.31-rc8.
      Signed-off-by: default avatarMel Gorman <mel@csn.ul.ie>
      Tested-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: default avatarGreg Ungerer <gerg@snapgear.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd5d241e
    • David Howells's avatar
      nommu: fix error handling in do_mmap_pgoff() · a190887b
      David Howells authored
      Fix the error handling in do_mmap_pgoff().  If do_mmap_shared_file() or
      do_mmap_private() fail, we jump to the error_put_region label at which
      point we cann __put_nommu_region() on the region - but we haven't yet
      added the region to the tree, and so __put_nommu_region() may BUG
      because the region tree is empty or it may corrupt the region tree.
      
      To get around this, we can afford to add the region to the region tree
      before calling do_mmap_shared_file() or do_mmap_private() as we keep
      nommu_region_sem write-locked, so no-one can race with us by seeing a
      transient region.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Acked-by: default avatarGreg Ungerer <gerg@snapgear.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a190887b
    • Oleg Nesterov's avatar
      workqueues: introduce __cancel_delayed_work() · 4e49627b
      Oleg Nesterov authored
      cancel_delayed_work() has to use del_timer_sync() to guarantee the timer
      function is not running after return.  But most users doesn't actually
      need this, and del_timer_sync() has problems: it is not useable from
      interrupt, and it depends on every lock which could be taken from irq.
      
      Introduce __cancel_delayed_work() which calls del_timer() instead.
      
      The immediate reason for this patch is
      http://bugzilla.kernel.org/show_bug.cgi?id=13757
      but hopefully this helper makes sense anyway.
      
      As for 13757 bug, actually we need requeue_delayed_work(), but its
      semantics are not yet clear.
      
      Merge this patch early to resolves cross-tree interdependencies between
      input and infiniband.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Roland Dreier <rdreier@cisco.com>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4e49627b
  2. 04 Sep, 2009 1 commit
  3. 01 Sep, 2009 6 commits
  4. 31 Aug, 2009 10 commits
  5. 30 Aug, 2009 2 commits
  6. 29 Aug, 2009 6 commits
  7. 28 Aug, 2009 8 commits