Skip to content
  1. Oct 14, 2014
  3. Oct 05, 2014
  5. Oct 04, 2014
  7. Oct 03, 2014
  9. Oct 02, 2014
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Fix infinite spin in reading buffer · 24607f11
      Steven Rostedt (Red Hat) authored 
      Commit 651e22f2 "ring-buffer: Always reset iterator to reader page"
fixed one bug but in the process caused another one. The reset is to
update the header page, but that fix also changed the way the cached
reads were updated. The cache reads are used to test if an iterator
needs to be updated or not.

A ring buffer iterator, when created, disables writes to the ring buffer
but does not stop other readers or consuming reads from happening.
Although all readers are synchronized via a lock, they are only
synchronized when in the ring buffer functions. Those functions may
be called by any number of readers. The iterator continues down when
its not interrupted by a consuming reader. If a consuming read
occurs, the iterator starts from the beginning of the buffer.

The way the iterator sees that a consuming read has happened since
its last read is by checking the reader "cache". The cache holds the
last counts of the read and the reader page itself.

Commit 651e22f2 changed what was saved by the cache_read when
the rb_iter_reset() occurred, making the iterator never match the cache.
Then if the iterator calls rb_iter_reset(), it will go into an
infinite loop by checking if the cache doesn't match, doing the reset
and retrying, just to see that the cache still doesn't match! Which
should never happen as the reset is suppose to set the cache to the
current value and there's locks that keep a consuming reader from
having access to the data.

Fixes: 651e22f2

 "ring-buffer: Always reset iterator to reader page"
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      24607f11
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.17-8' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 80ec7ce7
      Linus Torvalds authored 
      Pull parisc fix from Helge Deller:
 "One late but trivial patch to fix the serial console on parisc
  machines which got broken during the 3.17 release cycle"

* 'parisc-3.17-8' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix serial console for machines with serial port on superio chip
      80ec7ce7
    • Pavel Shilovsky's avatar
      CIFS: Fix readpages retrying on reconnects · 1209bbdf
      Pavel Shilovsky authored 
      

If we got a reconnect error from async readv we re-add pages back
to page_list and continue loop. That is wrong because these pages
have been already added to the pagecache but page_list has pages that
have not been added to the pagecache yet. This ends up with a general
protection fault in put_pages after readpages. Fix it by not retrying
the read of these pages and falling back to readpage instead.

Fixes debian bug 762306

Signed-off-by: default avatarPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: default avatarSteve French <smfrench@gmail.com>
Tested-by: default avatarArthur Marsh <arthur.marsh@internode.on.net>
      1209bbdf
    • Steve French's avatar
      Fix problem recognizing symlinks · 19e81573
      Steve French authored 
      Changeset eb85d94b

 introduced a problem where if a cifs open
fails during query info of a file we
will still try to close the file (happens with certain types
of reparse points) even though the file handle is not valid.

In addition for SMB2/SMB3 we were not mapping the return code returned
by Windows when trying to open a file (like a Windows NFS symlink)
which is a reparse point.

Signed-off-by: default avatarSteve French <smfrench@gmail.com>
Reviewed-by: default avatarPavel Shilovsky <pshilovsky@samba.org>
CC: stable <stable@vger.kernel.org> #v3.13+
      19e81573
    • Linus Torvalds's avatar
      Merge branch 'numa-migration-fixes' (fixes from Mel Gorman) · f9220c23
      Linus Torvalds authored 
      Merge NUMA balancing related fixlets from Mel Gorman:
 "There were a few minor changes so am resending just the two patches
  that are mostly likely to affect the bug Dave and Sasha saw and marked
  them for stable.

  I'm less confident it will address Sasha's problem because while I
  have not kept up to date, I believe he's also seeing memory corruption
  issues in next from an unknown source.  Still, it would be nice to see
  how they affect trinity testing.

  I'll send the MPOL_MF_LAZY patch separately because it's not urgent"

* emailed patches from Mel Gorman <mgorman@suse.de>:
  mm: numa: Do not mark PTEs pte_numa when splitting huge pages
  mm: migrate: Close race between migration completion and mprotect
      f9220c23
    • Mel Gorman's avatar
      mm: numa: Do not mark PTEs pte_numa when splitting huge pages · abc40bd2
      Mel Gorman authored 
      This patch reverts 1ba6e0b5

 ("mm: numa: split_huge_page: transfer the
NUMA type from the pmd to the pte"). If a huge page is being split due
a protection change and the tail will be in a PROT_NONE vma then NUMA
hinting PTEs are temporarily created in the protected VMA.

 VM_RW|VM_PROTNONE
|-----------------|
      ^
      split here

In the specific case above, it should get fixed up by change_pte_range()
but there is a window of opportunity for weirdness to happen. Similarly,
if a huge page is shrunk and split during a protection update but before
pmd_numa is cleared then a pte_numa can be left behind.

Instead of adding complexity trying to deal with the case, this patch
will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults
will not be triggered which is marginal in comparison to the complexity
in dealing with the corner cases during THP split.

Cc: stable@vger.kernel.org
Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
Acked-by: default avatarRik van Riel <riel@redhat.com>
Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      abc40bd2