1. 19 Jul, 2014 4 commits
  2. 18 Jul, 2014 12 commits
  3. 17 Jul, 2014 11 commits
  4. 16 Jul, 2014 8 commits
  5. 15 Jul, 2014 5 commits
    • Martin Lau's avatar
      ring-buffer: Fix polling on trace_pipe · 97b8ee84
      Martin Lau authored
      ring_buffer_poll_wait() should always put the poll_table to its wait_queue
      even there is immediate data available.  Otherwise, the following epoll and
      read sequence will eventually hang forever:
      
      1. Put some data to make the trace_pipe ring_buffer read ready first
      2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee)
      3. epoll_wait()
      4. read(trace_pipe_fd) till EAGAIN
      5. Add some more data to the trace_pipe ring_buffer
      6. epoll_wait() -> this epoll_wait() will block forever
      
      ~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2,
        ring_buffer_poll_wait() returns immediately without adding poll_table,
        which has poll_table->_qproc pointing to ep_poll_callback(), to its
        wait_queue.
      ~ During the epoll_wait() call in step 3 and step 6,
        ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue
        because the poll_table->_qproc is NULL and it is how epoll works.
      ~ When there is new data available in step 6, ring_buffer does not know
        it has to call ep_poll_callback() because it is not in its wait queue.
        Hence, block forever.
      
      Other poll implementation seems to call poll_wait() unconditionally as the very
      first thing to do.  For example, tcp_poll() in tcp.c.
      
      Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com
      
      Cc: stable@vger.kernel.org # 2.6.27
      Fixes: 2a2cc8f7 "ftrace: allow the event pipe to be polled"
      Reviewed-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarMartin Lau <kafai@fb.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      97b8ee84
    • Niu Yawei's avatar
      quota: missing lock in dqcache_shrink_scan() · d68aab6b
      Niu Yawei authored
      Commit 1ab6c499 (fs: convert fs shrinkers to new scan/count API)
      accidentally removed locking from quota shrinker. Fix it -
      dqcache_shrink_scan() should use dq_list_lock to protect the
      scan on free_dquots list.
      
      CC: stable@vger.kernel.org
      Fixes: 1ab6c499Signed-off-by: default avatarNiu Yawei <yawei.niu@intel.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      d68aab6b
    • Mike Snitzer's avatar
      dm cache metadata: do not allow the data block size to change · 048e5a07
      Mike Snitzer authored
      The block size for the dm-cache's data device must remained fixed for
      the life of the cache.  Disallow any attempt to change the cache's data
      block size.
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Cc: stable@vger.kernel.org
      048e5a07
    • Mike Snitzer's avatar
      dm thin metadata: do not allow the data block size to change · 9aec8629
      Mike Snitzer authored
      The block size for the thin-pool's data device must remained fixed for
      the life of the thin-pool.  Disallow any attempt to change the
      thin-pool's data block size.
      
      It should be noted that attempting to change the data block size via
      thin-pool table reload will be ignored as a side-effect of the thin-pool
      handover that the thin-pool target does during thin-pool table reload.
      
      Here is an example outcome of attempting to load a thin-pool table that
      reduced the thin-pool's data block size from 1024K to 512K.
      
      Before:
      kernel: device-mapper: thin: 253:4: growing the data device from 204800 to 409600 blocks
      
      After:
      kernel: device-mapper: thin metadata: changing the data block size (from 2048 to 1024) is not supported
      kernel: device-mapper: table: 253:4: thin-pool: Error creating metadata object
      kernel: device-mapper: ioctl: error adding target to table
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Cc: stable@vger.kernel.org
      9aec8629
    • zhangwei(Jovi)'s avatar
      tracing: Add TRACE_ITER_PRINTK flag check in __trace_puts/__trace_bputs · f0160a5a
      zhangwei(Jovi) authored
      The TRACE_ITER_PRINTK check in __trace_puts/__trace_bputs is missing,
      so add it, to be consistent with __trace_printk/__trace_bprintk.
      Those functions are all called by the same function: trace_printk().
      
      Link: http://lkml.kernel.org/p/51E7A7D6.8090900@huawei.com
      
      Cc: stable@vger.kernel.org # 3.11+
      Signed-off-by: default avatarzhangwei(Jovi) <jovi.zhangwei@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f0160a5a