1. 18 Mar, 2016 1 commit
    • Rabin Vincent's avatar
      splice: handle zero nr_pages in splice_to_pipe() · d6785d91
      Rabin Vincent authored
      Running the following command:
      
       busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null
      
      with any tracing enabled pretty very quickly leads to various NULL
      pointer dereferences and VM BUG_ON()s, such as these:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       IP: [<ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d
      
       page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
       kernel BUG at include/linux/mm.h:367!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       RIP: [<ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cd1e>] tracesys_phase2+0x84/0x89
      
      (busybox's cat uses sendfile(2), unlike the coreutils version)
      
      This is because tracing_splice_read_pipe() can call splice_to_pipe()
      with spd->nr_pages == 0.  spd_pages underflows in splice_to_pipe() and
      we fill the page pointers and the other fields of the pipe_buffers with
      garbage.
      
      All other callers of splice_to_pipe() avoid calling it when nr_pages ==
      0, and we could make tracing_splice_read_pipe() do that too, but it
      seems reasonable to have splice_to_page() handle this condition
      gracefully.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      d6785d91
  2. 16 Mar, 2016 1 commit
  3. 01 Feb, 2016 1 commit
    • David Howells's avatar
      CacheFiles: Provide read-and-reset release counters for cachefilesd · a5b3a80b
      David Howells authored
      Provide read-and-reset objects- and blocks-released counters for cachefilesd
      to use to work out whether there's anything new that can be culled.
      
      One of the problems cachefilesd has is that if all the objects in the cache
      are pinned by inodes lying dormant in the kernel inode cache, there isn't
      anything for it to cull.  In such a case, it just spins around walking the
      filesystem tree and scanning for something to cull.  This eats up a lot of
      CPU time.
      
      By telling cachefilesd if there have been any releases, the daemon can
      sleep until there is the possibility of something to do.
      
      cachefilesd finds this information by the following means:
      
       (1) When the control fd is read, the kernel presents a list of values of
           interest.  "freleased=N" and "breleased=N" are added to this list to
           indicate the number of files released and number of blocks released
           since the last read call.  At this point the counters are reset.
      
       (2) POLLIN is signalled if the number of files released becomes greater
           than 0.
      
      Note that by 'released' it just means that the kernel has released its
      interest in those files for the moment, not necessarily that the files
      should be deleted from the cache.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarSteve Dickson <steved@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a5b3a80b
  4. 24 Jan, 2016 37 commits