linux.git/kernel, branch v4.1-rc7

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2015-06-05T17:00:53+00:00

Pull perf fixes from Ingo Molnar:
 "The biggest chunk of the changes are two regression fixes: a HT
  workaround fix and an event-group scheduling fix.  It's been verified
  with 5 days of fuzzer testing.

  Other fixes:

   - eBPF fix
   - a BIOS breakage detection fix
   - PMU driver fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel/pt: Fix a refactoring bug
  perf/x86: Tweak broken BIOS rules during check_hw_exists()
  perf/x86/intel/pt: Untangle pt_buffer_reset_markers()
  perf: Disallow sparse AUX allocations for non-SG PMUs in overwrite mode
  perf/x86: Improve HT workaround GP counter constraint
  perf/x86: Fix event/group validation
  perf: Fix race in BPF program unregister

compat: cleanup coding in compat_get_bitmap() and compat_put_bitmap()

2015-06-04T21:57:18+00:00

In the functions compat_get_bitmap() and compat_put_bitmap() the
variable nr_compat_longs stores how many compat_ulong_t words should be
copied in a loop.

The copy loop itself is this:
  if (nr_compat_longs-- > 0) {
      if (__get_user(um, umask)) return -EFAULT;
  } else {
      um = 0;
  }

Since nr_compat_longs gets unconditionally decremented in each loop and
since it's type is unsigned this could theoretically lead to out of
bounds accesses to userspace if nr_compat_longs wraps around to
(unsigned)(-1).

Although the callers currently do not trigger out-of-bounds accesses, we
should better implement the loop in a safe way to completely avoid such
warp-arounds.

Signed-off-by: Helge Deller 
Cc: Linus Torvalds 
Cc: Al Viro

Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

2015-05-29T18:24:28+00:00

Pull fixes for cpumask and modules from Rusty Russell:
 "** NOW WITH TESTING! **

  Two fixes which got lost in my recent distraction.  One is a weird
  cpumask function which needed to be rewritten, the other is a module
  bug which is cc:stable"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  cpumask_set_cpu_local_first => cpumask_local_spread, lament
  module: Call module notifier on failure after complete_formation()

perf: Disallow sparse AUX allocations for non-SG PMUs in overwrite mode

2015-05-27T07:16:20+00:00

PMUs that don't support hardware scatter tables require big contiguous
chunks of memory and a PMI to switch between them. However, in overwrite
using a PMI for this purpose adds extra overhead that the users would
like to avoid. Thus, in overwrite mode for such PMUs we can only allow
one contiguous chunk for the entire requested buffer.

This patch changes the behavior accordingly, so that if the buddy allocator
fails to come up with a single high-order chunk for the entire requested
buffer, the allocation will fail.

Signed-off-by: Alexander Shishkin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: acme@infradead.org
Cc: adrian.hunter@intel.com
Cc: hpa@zytor.com
Link: http://lkml.kernel.org/r/1432308626-18845-2-git-send-email-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar

perf: Fix race in BPF program unregister

2015-05-27T06:46:15+00:00

there is a race between perf_event_free_bpf_prog() and free_trace_kprobe():

	__free_event()
	  event->destroy(event)
	    tp_perf_event_destroy()
	      perf_trace_destroy()
		perf_trace_event_unreg()

which is dropping event->tp_event->perf_refcount and allows to proceed in:

	unregister_trace_kprobe()
	  unregister_kprobe_event()
	      trace_remove_event_call()
		    probe_remove_event_call()
	free_trace_kprobe()

while __free_event does:

	call_rcu(&event->rcu_head, free_event_rcu);
	  free_event_rcu()
	    perf_event_free_bpf_prog()

To fix the race simply move perf_event_free_bpf_prog() before
event->destroy(), since event->tp_event is still valid at that point.

Note, perf_trace_destroy() is not racing with trace_remove_event_call()
since they both grab event_mutex.

Reported-by: Wang Nan 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: lizefan@huawei.com
Cc: pi3orama@163.com
Fixes: 2541517c32be ("tracing, perf: Implement BPF programs attached to kprobes")
Link: http://lkml.kernel.org/r/1431717321-28772-1-git-send-email-ast@plumgrid.com
Signed-off-by: Ingo Molnar

Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2015-05-24T00:57:40+00:00

Pull timer fix from Thomas Gleixner:
 "One more fix from the timer departement:

    - Handle division of negative nanosecond values proper on 32bit.

      A recent cleanup wrecked the sign handling of the dividend and
      dropped the check for negative divisors"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  ktime: Fix ktime_divns to do signed division

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

2015-05-22T22:15:30+00:00

Pull block fixes from Jens Axboe:
 "Three small fixes that have been picked up the last few weeks.
  Specifically:

   - Fix a memory corruption issue in NVMe with malignant user
     constructed request.  From Christoph.

   - Kill (now) unused blk_queue_bio(), dm was changed to not need this
     anymore.  From Mike Snitzer.

   - Always use blk_schedule_flush_plug() from the io_schedule() path
     when flushing a plug, fixing a !TASK_RUNNING warning with md.  From
     Shaohua"

* 'for-linus' of git://git.kernel.dk/linux-block:
  sched: always use blk_schedule_flush_plug in io_schedule_out
  nvme: fix kernel memory corruption with short INQUIRY buffers
  block: remove export for blk_queue_bio

watchdog: fix double lock in watchdog_nmi_enable_all

2015-05-19T17:57:03+00:00

Commit ab992dc38f9a ("watchdog: Fix merge 'conflict'") has introduced an
obvious deadlock because of a typo.  watchdog_proc_mutex should be
unlocked on exit.

Thanks to Miroslav Benes who was staring at the code with me and noticed
this.

Signed-off-by: Michal Hocko 
Duh-by: Peter Zijlstra 
Signed-off-by: Linus Torvalds

sched: always use blk_schedule_flush_plug in io_schedule_out

2015-05-18T22:06:41+00:00

block plug callback could sleep, so we introduce a parameter
'from_schedule' and corresponding drivers can use it to destinguish a
schedule plug flush or a plug finish. Unfortunately io_schedule_out
still uses blk_flush_plug(). This causes below output (Note, I added a
might_sleep() in raid1_unplug to make it trigger faster, but the whole
thing doesn't matter if I add might_sleep). In raid1/10, this can cause
deadlock.

This patch makes io_schedule_out always uses blk_schedule_flush_plug.
This should only impact drivers (as far as I know, raid 1/10) which are
sensitive to the 'from_schedule' parameter.

[  370.817949] ------------[ cut here ]------------
[  370.817960] WARNING: CPU: 7 PID: 145 at ../kernel/sched/core.c:7306 __might_sleep+0x7f/0x90()
[  370.817969] do not call blocking ops when !TASK_RUNNING; state=2 set at [] prepare_to_wait+0x2f/0x90
[  370.817971] Modules linked in: raid1
[  370.817976] CPU: 7 PID: 145 Comm: kworker/u16:9 Tainted: G        W       4.0.0+ #361
[  370.817977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
[  370.817983] Workqueue: writeback bdi_writeback_workfn (flush-9:1)
[  370.817985]  ffffffff81cd83be ffff8800ba8cb298 ffffffff819dd7af 0000000000000001
[  370.817988]  ffff8800ba8cb2e8 ffff8800ba8cb2d8 ffffffff81051afc ffff8800ba8cb2c8
[  370.817990]  ffffffffa00061a8 000000000000041e 0000000000000000 ffff8800ba8cba28
[  370.817993] Call Trace:
[  370.817999]  [] dump_stack+0x4f/0x7b
[  370.818002]  [] warn_slowpath_common+0x8c/0xd0
[  370.818004]  [] warn_slowpath_fmt+0x46/0x50
[  370.818006]  [] ? prepare_to_wait+0x2f/0x90
[  370.818008]  [] ? prepare_to_wait+0x2f/0x90
[  370.818010]  [] __might_sleep+0x7f/0x90
[  370.818014]  [] raid1_unplug+0xd3/0x170 [raid1]
[  370.818024]  [] blk_flush_plug_list+0x8a/0x1e0
[  370.818028]  [] ? bit_wait+0x50/0x50
[  370.818031]  [] io_schedule_timeout+0x130/0x140
[  370.818033]  [] bit_wait_io+0x36/0x50
[  370.818034]  [] __wait_on_bit+0x65/0x90
[  370.818041]  [] ? ext4_read_block_bitmap_nowait+0xbc/0x630
[  370.818043]  [] ? bit_wait+0x50/0x50
[  370.818045]  [] out_of_line_wait_on_bit+0x72/0x80
[  370.818047]  [] ? autoremove_wake_function+0x40/0x40
[  370.818050]  [] __wait_on_buffer+0x44/0x50
[  370.818053]  [] ext4_wait_block_bitmap+0xe0/0xf0
[  370.818058]  [] ext4_mb_init_cache+0x206/0x790
[  370.818062]  [] ? lru_cache_add+0x1c/0x50
[  370.818064]  [] ext4_mb_init_group+0x11e/0x200
[  370.818066]  [] ext4_mb_load_buddy+0x341/0x360
[  370.818068]  [] ext4_mb_find_by_goal+0x93/0x2f0
[  370.818070]  [] ? ext4_mb_normalize_request+0x1e4/0x5b0
[  370.818072]  [] ext4_mb_regular_allocator+0x67/0x460
[  370.818074]  [] ? ext4_mb_normalize_request+0x1e4/0x5b0
[  370.818076]  [] ext4_mb_new_blocks+0x4cb/0x620
[  370.818079]  [] ext4_ext_map_blocks+0x4c6/0x14d0
[  370.818081]  [] ? ext4_es_lookup_extent+0x4e/0x290
[  370.818085]  [] ext4_map_blocks+0x14d/0x4f0
[  370.818088]  [] ext4_writepages+0x76d/0xe50
[  370.818094]  [] do_writepages+0x21/0x50
[  370.818097]  [] __writeback_single_inode+0x60/0x490
[  370.818099]  [] writeback_sb_inodes+0x2da/0x590
[  370.818103]  [] ? trylock_super+0x1b/0x50
[  370.818105]  [] ? trylock_super+0x1b/0x50
[  370.818107]  [] __writeback_inodes_wb+0x9f/0xd0
[  370.818109]  [] wb_writeback+0x34b/0x3c0
[  370.818111]  [] bdi_writeback_workfn+0x23f/0x550
[  370.818116]  [] process_one_work+0x1c8/0x570
[  370.818117]  [] ? process_one_work+0x14b/0x570
[  370.818119]  [] worker_thread+0x11b/0x470
[  370.818121]  [] ? process_one_work+0x570/0x570
[  370.818124]  [] kthread+0xf8/0x110
[  370.818126]  [] ? kthread_create_on_node+0x210/0x210
[  370.818129]  [] ret_from_fork+0x42/0x70
[  370.818131]  [] ? kthread_create_on_node+0x210/0x210
[  370.818132] ---[ end trace 7b4deb71e68b6605 ]---

V2: don't change ->in_iowait

Cc: NeilBrown 
Signed-off-by: Shaohua Li 
Reviewed-by: Jeff Moyer 
Signed-off-by: Jens Axboe

watchdog: Fix merge 'conflict'

2015-05-18T17:08:29+00:00

Two watchdog changes that came through different trees had a non
conflicting conflict, that is, one changed the semantics of a variable
but no actual code conflict happened. So the merge appeared fine, but
the resulting code did not behave as expected.

Commit 195daf665a62 ("watchdog: enable the new user interface of the
watchdog mechanism") changes the semantics of watchdog_user_enabled,
which thereafter is only used by the functions introduced by
b3738d293233 ("watchdog: Add watchdog enable/disable all functions").

There further appears to be a distinct lack of serialization between
setting and using watchdog_enabled, so perhaps we should wrap the
{en,dis}able_all() things in watchdog_proc_mutex.

This patch fixes a s2r failure reported by Michal; which I cannot
readily explain. But this does make the code internally consistent
again.

Reported-and-tested-by: Michal Hocko 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Linus Torvalds