perf evlist: Open event on evsel cpus and threads

An evsel may have different cpus and threads than the evlist it is in.

Use it's own cpus and threads, when opening the evsel in 'perf record'.

Signed-off-by: Kan Liang <kan.liang@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/1440138194-17001-1-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

bpf tools: New API to get name from a BPF object

Before this patch there's no way to connect a loaded bpf object
to its source file. However, during applying perf's '--filter' to BPF
object, without this connection makes things harder, because perf loads
all programs together, but '--filter' setting is for each object.

The API of bpf_object__open_buffer() is changed to allow passing a name.
Fortunately, at this time there's only one user of it (perf test LLVM),
so we change it together.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440742821-44548-2-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Fix build on powerpc broken by pt/bts

It is theoretically possible to process perf.data files created on x86
and that contain Intel PT or Intel BTS data, on any other architecture,
which is why it is possible for there to be build errors on powerpc
caused by pt/bts.

The errors were:

util/intel-pt-decoder/intel-pt-insn-decoder.c: In function ‘intel_pt_insn_decoder’:
util/intel-pt-decoder/intel-pt-insn-decoder.c:138:3: error: switch missing default case [-Werror=switch-default]
   switch (insn->immediate.nbytes) {
   ^
cc1: all warnings being treated as errors

linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_synth_branch_sample':
sources/linux-acme.git/tools/perf/util/intel-pt.c:871: undefined reference to `tsc_to_perf_time'
linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_sample':
sources/linux-acme.git/tools/perf/util/intel-pt.c:915: undefined reference to `tsc_to_perf_time'
sources/linux-acme.git/tools/perf/util/intel-pt.c:962: undefined reference to `tsc_to_perf_time'
linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_process_event':
sources/linux-acme.git/tools/perf/util/intel-pt.c:1454: undefined reference to `perf_time_to_tsc'

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1441046384-28663-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'perf-core-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/core

Pull perf/core improvement and fixes from Arnaldo Carvalho de Melo:

User visible changes:

  - Add new compaction-times python script. (Tony Jones)

  - Make the --[no-]-demangle/--[no-]-demangle-kernel command line
    options available in 'perf script' too. (Mark Drayton)

  - Allow for negative numbers in libtraceevent's print format,
    fixing up misformatting in some tracepoints. (Steven Rostedt)

Infrastructure changes:

  - perf_env/perf_evlist changes to allow accessing the data
    structure with the environment where some perf data was
    collected in functions not necessarily related to perf.data
    file processing. (Kan Liang)

  - Cleanups for the tracepoint definition location paths routines. (Jiri Olsa)

  - Introduce sysfs/filename__sprintf_build_id, removing code
    duplication. (Masami Hiramatsu)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'perf/urgent' into perf/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'perf-urgent-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fix from Arnaldo Carvalho de Melo:

  - Use index, not CPU id, to find core/pkg id in 'perf stat' (Kan Liang)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Linux 4.2

thermal: power_allocator: allocate with kcalloc what you free with kfree

Commit cf736ea6f902 ("thermal: power_allocator: do not use devm*
interfaces") forgot to change a devm_kcalloc() to just kcalloc(), but
it's corresponding devm_kfree() was changed to kfree().  Allocate with
kcalloc() to match the kfree().

Fixes: cf736ea6f902 ("thermal: power_allocator: do not use devm* interfaces")
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-4.2-fixes' of git://git./linux/kernel/git/tj/libata

Pull libata fixlet from Tejun Heo:
 "Simple blacklist entry addition"

* 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  Add factory recertified Crucial M500s to blacklist

Merge tag 'sound-fix-4.2' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Here are stable fixes that have been gathered since rc8: fixes for
  HD-audio widget power control regressions since 4.1, a NULL fix for
  HD-audio HDMI, a noise fix for Conexant codecs and a quirk addition
  for USB-Audio DSD"

* tag 'sound-fix-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix path power activation
  ALSA: hda - Check all inputs for is_active_nid_for_any()
  ALSA: hda: fix possible NULL dereference
  ALSA: hda - Shutdown CX20722 on reboot/free to avoid spurious noises
  ALSA: usb: Add native DSD support for Gustard DAC-X20U

perf evlist: Add backpointer for perf_env to evlist

Add backpointer to perf_env in evlist, so we can easily access env when
processing something where we have a evsel or evlist.

Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1440755289-30939-5-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Rename perf_session_env to perf_env

As it is not necessarily tied to a perf.data file and needs using in
places where a perf_session is not required.

Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1440755289-30939-4-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Do not change lib/api/fs/debugfs directly

The tracing_events_path is the variable we want to change via
--debugfs-dir option, not the debugfs_mountpoint.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Raphael Beamonte <raphael.beamonte@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1440596813-12844-4-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add tracing_path and remove unneeded functions

There's no need for find_tracing_dir, because perf already searches for
debugfs/tracefs mount on start and populate tracing_events_path.

Adding tracing_path to carry tracing dir string to be used in
get_tracing_file instead of calling find_tracing_dir.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Raphael Beamonte <raphael.beamonte@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1440596813-12844-3-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf buildid: Introduce sysfs/filename__sprintf_build_id

Introduce sysfs/filename__sprintf_build_id for consolidating similar
code.

Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20150815114259.13642.34685.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf evsel: Add a backpointer to the evlist a evsel is in

So that functions that deal primarily with an evsel to access
information that concerns the whole evlist it is in.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1440677263-21954-5-git-send-email-kan.liang@intel.com
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf trace: Add header with copyright and background info

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-5yqtfs728r1j1u8zmg8ufxwm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf scripts python: Add new compaction-times script

This patch creates a new script (compaction-times) to report time
spent in mm compaction. It is possible to report times in nanoseconds
(default) or microseconds (-u).

The option -p will break down results by process id, -pv will further
decompose by each compaction entry/exit.

For each compaction entry/exit what is reported is controlled by the
options:

  -t   report only timing
  -m   report migration stats
  -ms  report migration scanner stats
  -fs  report free scanner stats

The default is to report all.

Entries may be further filtered by pid, pid-range or comm (regex).

The script is useful when analysing workloads that compact memory. The
most common example will be THP allocations on systems with a lot of
uptime that has fragmented memory.

This is an example of using the script to analyse a thpscale from
mmtests which deliberately fragments memory and allocates THP in 4
separate threads

  # Recording step, one of the following;
  $ perf record -e 'compaction:mm_compaction_*' ./workload
  # or:
  $ perf script record compaction-times

  # Reporting: basic
  total: 2444505743ns migration: moved=357738 failed=39275
  free_scanner: scanned=2705578 isolated=387875
  migration_scanner: scanned=414426 isolated=397013

  # Reporting: Per task stall times
  $ perf script report compaction-times -- -t -p
  total: 2444505743ns
  6384[thpscale]: 740800017ns
  6385[thpscale]: 274119512ns
  6386[thpscale]: 832961337ns
  6383[thpscale]: 596624877ns

  # Reporting: Per-compaction attempts for task 6385
  $ perf script report compaction-times -- -m -pv 6385
  total: 274119512ns migration: moved=14893 failed=24285
  6385[thpscale]: 274119512ns migration: moved=14893 failed=24285
  6385[thpscale].1: 3033277ns migration: moved=511 failed=1
  6385[thpscale].2: 9592094ns migration: moved=1524 failed=12
  6385[thpscale].3: 2495587ns migration: moved=512 failed=0
  6385[thpscale].4: 2561766ns migration: moved=512 failed=0
  6385[thpscale].5: 2523521ns migration: moved=512 failed=0
  ..... output continues ...

Changes since v1:
- report stats for isolate_migratepages and isolate_freepages
  (Vlastimil Babka)
- refactor code to achieve above
- add help text
- output to stdout/stderr explicitly

Signed-off-by: Tony Jones <tonyj@suse.com>
Cc: Mel Gorman <mgorman@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Link: http://lkml.kernel.org/r/1439840932-8933-1-git-send-email-tonyj@suse.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf stat: Get correct cpu id for print_aggr

print_aggr() fails to print per-core/per-socket statistics after commit
582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
if events have differnt cpus. Because in print_aggr(), aggr_get_id needs
index (not cpu id) to find core/pkg id. Also, evsel cpu maps should be
used to get aggregated id.

Here is an example:

Counting events cycles,uncore_imc_0/cas_count_read/. (Uncore event has
cpumask 0,18)

  $ perf stat -e cycles,uncore_imc_0/cas_count_read/ -C0,18 --per-core sleep 2

Without this patch, it failes to get CPU 18 result.

   Performance counter stats for 'CPU(s) 0,18':

  S0-C0           1            7526851      cycles
  S0-C0           1               1.05 MiB  uncore_imc_0/cas_count_read/
  S1-C0           0      <not counted>      cycles
  S1-C0           0      <not counted> MiB  uncore_imc_0/cas_count_read/

With this patch, it can get both CPU0 and CPU18 result.

   Performance counter stats for 'CPU(s) 0,18':

  S0-C0           1            6327768      cycles
  S0-C0           1               0.47 MiB  uncore_imc_0/cas_count_read/
  S1-C0           1             330228      cycles
  S1-C0           1               0.29 MiB  uncore_imc_0/cas_count_read/

Signed-off-by: Kan Liang <kan.liang@intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Stephane Eranian <eranian@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Fixes: 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
Link: http://lkml.kernel.org/r/1435820925-51091-1-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

tools lib traceeveent: Allow for negative numbers in print format

It was reported that "%-8s" does not parse well when used in the printk
format. The '-' is what is throwing it off. Allow that to be included.

Reporter note:

Example before:

  transhuge-stres-10730 [004]  5897.713989: mm_compaction_finished: node=0
  zone=>-<8s order=-2119871790 ret=

Example after:

  transhuge-stres-4235  [000]   453.149280: mm_compaction_finished: node=0
  zone=ffffffff81815d7a order=9 ret=

(I will send patches to fix the string handling in the tracepoints so
it's on par with in-kernel printing via trace_pipe:)

  transhuge-stres-10921 [007] ...1  6307.140205: mm_compaction_finished: node=0
  zone=Normal   order=9 ret=partial

Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150827094601.46518bcc@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf script: Add --[no-]-demangle/--[no-]-demangle-kernel

Sometimes when post-processing output from `perf script` one does not
want to demangle C++ symbol names. Add an option to allow this.

Also add --[no-]demangle-kernel to be consistent with top/report/probe.

Signed-off-by: Mark Drayton <mbd@fb.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/1440616695-32340-1-git-send-email-scientist@fb.com
Signed-off-by: Yannick Brosseau <scientist@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'perf-core-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/core

Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:

User visible changes:

  - Add support for using several Intel PT features (CYC, MTC packets), the
    relevant documentation was updated: tools/perf/Documentation/intel-pt.txt,
    briefly describing those packets, its purposes, how to configure them in
    the event config terms and relevant external documentation for further
    reading. (Adrian Hunter)

  - Introduce support for probing at an absolute address, for user and kernel
    'perf probe's, useful when one have the symbol maps on a developer machine
    but not on an embedded system. (Wang Nan)

  - Fix 'perf probe' list results when a symbol can't be found or the
    address is zero and when an offset is provided without a function (Wang Nan)

  - Do not print '0x (null)' in uprobes when offset is zero (Wang Nan)

  - Clear the progress bar at the end of a ordered_events flush, fixing
    an UI artifact when, after ordering the events the screen doesn't get
    completely redraw, for instance, when an error window covers just the
    center of the screen and waits for user input. (Arnaldo Carvalho de Melo)

  - Fix 'annotate' segfault by resetting the dso find_symbol cache when removing
    symbols. (Arnaldo Carvalho de Melo)

Infrastructure changes:

  - Allow duplicate objects in the object list, just like it is possible to have
    things like this, in the kernel:

      drivers/Makefile:obj-$(CONFIG_PCI)        += usb/
      drivers/Makefile:obj-$(CONFIG_USB_GADGET) += usb/

    (Jiri Olsa)

  - Fix Intel PT 'instructions' sample period. (Adrian Hunter)

  - Prevent segfault when reading probe point with absolute address. (Wang Nan)

Build fixes:

  - Fix tarball build broken by pt/bts. (Adrian Hunter)

  - Remove export.h from MANIFEST, fixing the perf tarball make target. (Jiri Olsa)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'powerpc-4.2-4' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Fix MSI/MSI-X on pseries from Guilherme"

* tag 'powerpc-4.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
  PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:
 "Some straggler bug fixes here:

   1) Netlink_sendmsg() doesn't check iterator type properly in mmap
      case, from Ken-ichirou MATSUZAWA.

   2) Don't sleep in atomic context in bcmgenet driver, from Florian
      Fainelli.

   3) The pfkey_broadcast() code patch can't actually ever use anything
      other than GFP_ATOMIC.  And the cases that right now pass
      GFP_KERNEL or similar will currently trigger an RCU splat.  Just
      use GFP_ATOMIC unconditionally.  From David Ahern.

   4) Fix FD bit timings handling in pcan_usb driver, from Marc
      Kleine-Budde.

   5) Cache dst leaked in ip6_gre tunnel removal, fix from Huaibin Wang.

   6) Traversal into drivers/net/ethernet/renesas should be triggered by
      CONFIG_NET_VENDOR_RENESAS, not a particular driver's config
      option.  From Kazuya Mizuguchi.

   7) Fix regression in handling of igmp_join errors in vxlan, from
      Marcelo Ricardo Leitner.

   8) Make phy_{read,write}_mmd_indirect() properly take the mdio_lock
      mutex when programming the registers.  From Russell King.

   9) Fix non-forced handling in u32_destroy(), from WANG Cong.

  10) Test the EVENT_NO_RUNTIME_PM flag before it is cleared in
      usbnet_stop(), from Eugene Shatokhin.

  11) In sfc driver, don't fetch statistics firmware isn't capable of,
      from Bert Kenward.

  12) Verify ASCONF address parameter location in SCTP, from Xin Long"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state
  sctp: asconf's process should verify address parameter is in the beginning
  sfc: only use vadaptor stats if firmware is capable
  net: phy: fixed: propagate fixed link values to struct
  usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
  drivers: net: xgene: fix: Oops in linkwatch_fire_event
  cls_u32: complete the check for non-forced case in u32_destroy()
  net: fec: use reinit_completion() in mdio accessor functions
  net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect()
  vxlan: re-ignore EADDRINUSE from igmp_join
  net: compile renesas directory if NET_VENDOR_RENESAS is configured
  ip6_gre: release cached dst on tunnel removal
  phylib: Make PHYs children of their MDIO bus, not the bus' parent.
  can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters
  net: Fix RCU splat in af_key
  net: bcmgenet: fix uncleaned dma flags
  net: bcmgenet: Avoid sleeping in bcmgenet_timeout
  netlink: mmap: fix tx type check

Merge branch 'libnvdimm-fixes' of git://git./linux/kernel/git/nvdimm/nvdimm

Pull nvdimm fixlet from Dan Williams:
 "This is a libnvdimm ABI fixup.

  I pushed back on this change quite hard given the late date, that it
  appears to be purely cosmetic, sysfs is not necessarily meant to be a
  user friendly UI, and the kernel interprets the reversed polarity of
  the ACPI_NFIT_MEM_ARMED flag correctly.  When this flag is set, the
  energy source of an NVDIMM is not armed and any new writes to the DIMM
  may not be preserved.

  However, Bob Moore warned me that it is important to get these things
  named correctly wherever they appear otherwise we run the risk of a
  less than cautious firmware engineer implementing the polarity the
  wrong way.  Once a mistake like that escapes into production platforms
  the flag becomes useless and we need to move to a new bit position.

  Bob has agreed to take a change through ACPICA to rename
  ACPI_NFIT_MEM_ARMED to ACPI_NFIT_MEM_NOT_ARMED, and the patch below
  from Toshi brings the sysfs representation of these flags in line with
  their respective polarities.

  Please pull for 4.2 as this is the first kernel to expose the ACPI
  NFIT sysfs representation, and this is likely a kernel that firmware
  developers will be using for checking out their NVDIMM enabling"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  nfit: Clarify memory device state flags strings

sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state

Commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
fixed a problem with excessive retransmissions in the SHUTDOWN_PENDING by not
resetting the association overall_error_count.  This allowed the association
to better enforce assoc.max_retrans limit.

However, the same issue still exists when the association is in SHUTDOWN_RECEIVED
state.  In this state, HB-ACKs will continue to reset the overall_error_count
for the association would extend the lifetime of association unnecessarily.

This patch solves this by resetting the overall_error_count whenever the current
state is small then SCTP_STATE_SHUTDOWN_PENDING.  As a small side-effect, we
end up also handling SCTP_STATE_SHUTDOWN_ACK_SENT and SCTP_STATE_SHUTDOWN_SENT
states, but they are not really impacted because we disable Heartbeats in those
states.

Fixes: Commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sctp: asconf's process should verify address parameter is in the beginning

in sctp_process_asconf(), we get address parameter from the beginning of
the addip params. but we never check if it's really there. if the addr
param is not there, it still can pass sctp_verify_asconf(), then to be
handled by sctp_process_asconf(), it will not be safe.

so add a code in sctp_verify_asconf() to check the address parameter is in
the beginning, or return false to send abort.

note that this can also detect multiple address parameters, and reject it.

Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

nfit: Clarify memory device state flags strings

ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines
NVDIMM status as follows.  These bits indicate multiple info,
such as failures, pending event, and capability.

  Bit [0] set to 1 to indicate that the previous SAVE to the
  Memory Device failed.
  Bit [1] set to 1 to indicate that the last RESTORE from the
  Memory Device failed.
  Bit [2] set to 1 to indicate that platform flush of data to
  Memory Device failed. As a result, the restored data content
  may be inconsistent even if SAVE and RESTORE do not indicate
  failure.
  Bit [3] set to 1 to indicate that the Memory Device is observed
  to be not armed prior to OSPM hand off. A Memory Device is
  considered armed if it is able to accept persistent writes.
  Bit [4] set to 1 to indicate that the Memory Device observed
  SMART and health events prior to OSPM handoff.

/sys/bus/nd/devices/nmemX/nfit/flags shows this flags info.
The output strings associated with the bits are "save", "restore",
"smart", etc., which can be confusing as they may be interpreted
as positive status, i.e. save succeeded.

Change also the dev_info() message in acpi_nfit_register_dimms()
to be consistent with the sysfs flags strings.

Reported-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
[ross: rename 'not_arm' to 'not_armed']
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
[djbw: defer adding bit5, HEALTH_ENABLED, for now]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

sfc: only use vadaptor stats if firmware is capable

Some of the stats handling code differs based on SR-IOV support,
and SRIOV support is only available if full-featured firmware is
used.
Do not use vadaptor stats if firmware mode is not set to
full-featured.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: phy: fixed: propagate fixed link values to struct

The fixed link values parsed from the device tree are stored in
the struct fixed_phy member status. The struct phy_device members
speed, duplex were not updated.

Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull amr64 kvm fix from Will Deacon:
 "We've uncovered a nasty bug in the arm64 KVM code which allows a badly
  behaved 32-bit guest to bring down the host.  The fix is simple (it's
  what I believe we call a "brown paper bag" bug) and I don't think it
  makes sense to sit on this, particularly as Russell ended up
  triggering this rather than just somebody noticing a potential problem
  by inspection.

  Usually arm64 KVM changes would go via Paolo's tree, but he's on
  holiday at the moment and the deal is that anything urgent gets
  shuffled via the arch trees, so here it is.

  Summary:

  Fix arm64 KVM issue when injecting an abort into a 32-bit guest, which
  would lead to an illegal exception return at EL2 and a subsequent host
  crash"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: KVM: Fix host crash when injecting a fault into a 32bit guest

arm64: KVM: Fix host crash when injecting a fault into a 32bit guest

When injecting a fault into a misbehaving 32bit guest, it seems
rather idiotic to also inject a 64bit fault that is only going
to corrupt the guest state. This leads to a situation where we
perform an illegal exception return at EL2 causing the host
to crash instead of killing the guest.

Just fix the stupid bug that has been there from day 1.

Cc: <stable@vger.kernel.org>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

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

Pull block fixes from Jens Axboe:
 "Two fixes in this pull request:

   - The writeback regression fix from Tejun, which has been weeks in
     the making.  This fixes a case where we would sometimes not issue
     writeback when we should have.

   - An older fix for a memory corruption issue in mtip32xx.  It was
     deferred since we wanted a better fix for this (driver should not
     have to handle that case), but given the timing, it's better to put
     the simple fix in for 4.2 release"

* 'for-linus' of git://git.kernel.dk/linux-block:
  mtip32x: fix regression introduced by blk-mq per-hctx flush
  writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes()

Add factory recertified Crucial M500s to blacklist

The Crucial M500 is known to have issues with queued TRIM commands, the
factory recertified SSDs use a different model number naming convention
which causes them to get ignored by the blacklist.

The new naming convention boils down to: s/Crucial_/FC/

Signed-off-by: Guillermo A. Amaral <g@maral.me>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

tracing/uprobes: Do not print '0x (null)' when offset is 0

When manually added uprobe point with zero address, 'uprobe_events'
output '(null)' instead of 0x00000000:

  # echo p:probe_libc/abs_0 /path/to/lib.bin:0x0 arg1=%ax > \
            /sys/kernel/debug/tracing/uprobe_events

  # cat /sys/kernel/debug/tracing/uprobe_events
    p:probe_libc/abs_0 /path/to/lib.bin:0x          (null) arg1=%ax

 This patch fixes this behavior:

  # cat /sys/kernel/debug/tracing/uprobe_events
  p:probe_libc/abs_0 /path/to/lib.bin:0x0000000000000000

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440586666-235233-8-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf probe: Support probing at absolute address

It should be useful to allow 'perf probe' probe at absolute offset of a
target. For example, when (u)probing at a instruction of a shared object
in a embedded system where debuginfo is not avaliable but we know the
offset of that instruction by manually digging.

This patch enables following perf probe command syntax:

  # perf probe 0xffffffff811e6615

And

  # perf probe /lib/x86_64-linux-gnu/libc-2.19.so 0xeb860

In the above example, we don't need a anchor symbol, so it is possible
to compute absolute addresses using other methods and then use 'perf
probe' to create the probing points.

v1 -> v2:
  Drop the leading '+' in cmdline;
  Allow uprobing at offset 0x0;
  Improve 'perf probe -l' result when uprobe at area without debuginfo.

v2 -> v3:
  Split bugfix to a separated patch.

Test result:

  # perf probe 0xffffffff8119d175 %ax
  # perf probe sys_write %ax
  # perf probe /lib64/libc-2.18.so 0x0 %ax
  # perf probe /lib64/libc-2.18.so 0x5 %ax
  # perf probe /lib64/libc-2.18.so 0xd8e40 %ax
  # perf probe /lib64/libc-2.18.so __write %ax
  # perf probe /lib64/libc-2.18.so 0xd8e49 %ax
  # cat /sys/kernel/debug/tracing/uprobe_events

  p:probe_libc/abs_0 /lib64/libc-2.18.so:0x          (null) arg1=%ax
  p:probe_libc/abs_5 /lib64/libc-2.18.so:0x0000000000000005 arg1=%ax
  p:probe_libc/abs_d8e40 /lib64/libc-2.18.so:0x00000000000d8e40 arg1=%ax
  p:probe_libc/__write /lib64/libc-2.18.so:0x00000000000d8e40 arg1=%ax
  p:probe_libc/abs_d8e49 /lib64/libc-2.18.so:0x00000000000d8e49 arg1=%ax

  # cat /sys/kernel/debug/tracing/kprobe_events

  p:probe/abs_ffffffff8119d175 0xffffffff8119d175 arg1=%ax
  p:probe/sys_write _text+1692016 arg1=%ax

  # perf probe -l

  Failed to find debug information for address 5
    probe:abs_ffffffff8119d175 (on sys_write+5 with arg1)
    probe:sys_write      (on sys_write with arg1)
    probe_libc:__write   (on @unix/syscall-template.S:81 in /lib64/libc-2.18.so with arg1)
    probe_libc:abs_0     (on 0x0 in /lib64/libc-2.18.so with arg1)
    probe_libc:abs_5     (on 0x5 in /lib64/libc-2.18.so with arg1)
    probe_libc:abs_d8e40 (on @unix/syscall-template.S:81 in /lib64/libc-2.18.so with arg1)
    probe_libc:abs_d8e49 (on __GI___libc_write+9 in /lib64/libc-2.18.so with arg1)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440586666-235233-7-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf probe: Fix error reported when offset without function

This patch fixes a bug that, when offset is provided but function is
lost, parse_perf_probe_point() will give a "" string as function name,
so the checking code at the end of parse_perf_probe_point() become
useless.  For example:

  # perf probe +0x1234
  Failed to find symbol  in kernel
    Error: Failed to add events.

After this patch:

  # perf probe +0x1234
  Semantic error :Offset requires an entry function.
    Error: Command Parse Error.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440586666-235233-6-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf probe: Fix list result when address is zero

When manually added uprobe point with zero address, 'perf probe -l'
reports error. For example:

  # echo p:probe_libc/abs_0 /path/to/lib.bin:0x0 arg1=%ax > \
           /sys/kernel/debug/tracing/uprobe_events

  # perf probe -l
  Error: Failed to show event list.

Probing at 0x0 is possible and useful when lib.bin is not a normal
shared object but is manually mapped. However, in this case kernel
report:

  # cat /sys/kernel/debug/tracing/uprobe_events
  p:probe_libc/abs_0 /path/to/lib.bin:0x          (null) arg1=%ax

This patch supports the above kernel output.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440586666-235233-5-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf probe: Fix list result when symbol can't be found

'perf probe -l' reports error if it is unable find symbol through
address. Here is an example.

  # echo 'p:probe_libc/abs_5 /lib64/libc.so.6:0x5' >
          /sys/kernel/debug/tracing/uprobe_events
  # cat /sys/kernel/debug/tracing/uprobe_events
   p:probe_libc/abs_5 /lib64/libc.so.6:0x0000000000000005
  # perf probe -l
    Error: Failed to show event list

Also, this situation triggers a logical inconsistency in
convert_to_perf_probe_point() that, it returns ENOMEM but actually it
never try strdup().

This patch removes !tp->module && !is_kprobe condition, so it always
uses address to build function name if symbol not found.

Test result:

  # perf probe -l
    probe_libc:abs_5     (on 0x5 in /lib64/libc.so.6)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440586666-235233-4-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

tools build: Allow duplicate objects in the object list

It's sometimes useful to specify the object affiliation to multiple
config options like:

  libperf-$(CONFIG_X86) += tsc.o
  libperf-$(CONFIG_AUXTRACE) += tsc.o

while the object itself is linked only once. Adding the support for this
and ignoring duplicate objects in the object list.

Suggested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20150826130103.GF22670@krava.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Remove export.h from MANIFEST

We don't carry an export.h wrapper anymore, remove it from the MANIFEST
file to avoid breaking the make perf-tar targets.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20150826080750.GD22670@krava.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf probe: Prevent segfault when reading probe point with absolute address

'perf probe -l' panic if there is a manually inserted probing point with
absolute address. For example:

  # echo 'p:probe/abs_ffffffff811e6615 0xffffffff811e6615' > /sys/kernel/debug/tracing/kprobe_events
  # perf probe -l
  Segmentation fault (core dumped)

This patch fix this problem by considering the situation that
"tp->symbol == NULL" in find_perf_probe_point_from_dwarf() and
find_perf_probe_point_from_map().

After this patch:

  # perf probe -l
  probe:abs_ffffffff811e6615 (on SyS_write+5@fs/read_write.c)

And when debug info is missing:

  # rm -rf ~/.debug
  # mv /lib/modules/4.2.0-rc1+/build/vmlinux /lib/modules/4.2.0-rc1+/build/vmlinux.bak
  # perf probe -l
  probe:abs_ffffffff811e6615 (on sys_write+5)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440509256-193590-1-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

Since commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if
kernel doesn't support MSI"), the setup of dev->msi_cap/msix_cap and the
disable of MSI/MSI-X interrupts isn't being done at PCI probe time, as
the logic responsible for this was moved in the aforementioned commit
from pci_device_add() to pci_setup_device(). The latter function is not
reachable on PowerPC pseries platform during Open Firmware PCI probing
time.

This exhibits as drivers not being able to enable MSI, eg:

  bnx2x 0000:01:00.0: no msix capability found

This patch calls pci_msi_setup_pci_dev() explicitly to disable MSI/MSI-X
during PCI probe time on pSeries platform.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Flesh out change log and clarify comment]
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that initialises
dev->msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
probe time in devices that have this flag set. It moved the code from
pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
called by pci_setup_device().

The pseries PCI probing code does not call pci_setup_device(), so since
the aforementioned commit the function pci_msi_setup_pci_dev() is not
called and MSI/MSI-X interrupts are left enabled. Additionally because
dev->msi_cap/msix_cap are not initialised no driver can ever enable
MSI/MSI-X.

To fix this, the pseries PCI probe should manually call
pci_msi_setup_pci_dev(), so this patch makes it non-static.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Update change log to mention dev->msi_cap/msix_cap]
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared

It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop(), but its value should be read before it is cleared
when dev->flags is set to 0.

The problem was spotted and the fix was provided by
Oliver Neukum <oneukum@suse.de>.

Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/linux-security

Pull LSM regression fix from James Morris.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  LSM: restore certain default error codes

Merge branch 'libnvdimm-fixes' of git://git./linux/kernel/git/nvdimm/nvdimm

Pull nvdimm fix from Dan Williams:
 "A single fix for status register read size in the nd_blk driver.

  The effect of getting the width of this register read wrong is that
  all I/O fails when the read returns non-zero.  Given the availability
  of ACPI 6 NFIT enabled platforms, this could reasonably wait to come
  in during the 4.3 merge window with a tag for 4.2-stable.  Otherwise,
  this makes the 4.2 kernel fully functional with devices that conform
  to the mmio-block-apertures defined in the ACPI 6 NFIT (NVDIMM
  Firmware Interface Table)"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  nfit, nd_blk: BLK status register is only 32 bits

drivers: net: xgene: fix: Oops in linkwatch_fire_event

[ 1065.801569] Internal error: Oops: 96000006 [#1] SMP
...
[ 1065.866655] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Apr 22 2015
[ 1065.873937] Workqueue: events_power_efficient phy_state_machine
[ 1065.879837] task: fffffe01de105e80 ti: fffffe00bcf18000 task.ti: fffffe00bcf18000
[ 1065.887288] PC is at linkwatch_fire_event+0xac/0xc0
[ 1065.892141] LR is at linkwatch_fire_event+0xa0/0xc0
[ 1065.896995] pc : [<fffffe000060284c>] lr : [<fffffe0000602840>] pstate: 200001c5
[ 1065.904356] sp : fffffe00bcf1bd00
...
[ 1066.196813] Call Trace:
[ 1066.199248] [<fffffe000060284c>] linkwatch_fire_event+0xac/0xc0
[ 1066.205140] [<fffffe000061167c>] netif_carrier_off+0x54/0x64
[ 1066.210773] [<fffffe00004f1654>] phy_state_machine+0x120/0x3bc
[ 1066.216578] [<fffffe00000d8d10>] process_one_work+0x15c/0x3a8
[ 1066.222296] [<fffffe00000d9090>] worker_thread+0x134/0x470
[ 1066.227757] [<fffffe00000df014>] kthread+0xe0/0xf8
[ 1066.232525] Code: 97f65ee9 f9420660 d538d082 8b000042 (885f7c40)

The fix is to call phy_disconnect() from xgene_enet_mdio_remove,
which in turn call cancel_delayed_work_sync().

Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cls_u32: complete the check for non-forced case in u32_destroy()

In commit 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
I added a check in u32_destroy() to see if all real filters are gone
for each tp, however, that is only done for root_ht, same is needed
for others.

This can be reproduced by the following tc commands:

tc filter add dev eth0 parent 1:0 prio 5 handle 15: protocol ip u32 divisor 256
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:2 u32
ht 15:2: match ip src 10.0.0.2 flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32
ht 15:2: match ip src 10.0.0.3 flowid 1:10

Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
Reported-by: Akshat Kakkar <akshat.1984@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

LSM: restore certain default error codes

While in most cases commit b1d9e6b064 ("LSM: Switch to lists of hooks")
retained previous error returns, in three cases it altered them without
any explanation in the commit message. Restore all of them - in the
security_old_inode_init_security() case this led to reiserfs using
uninitialized data, sooner or later crashing the system (the only other
user of this function - ocfs2 - was unaffected afaict, since it passes
pre-initialized structures).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

nfit, nd_blk: BLK status register is only 32 bits

Only read 32 bits for the BLK status register in read_blk_stat().

The format and size of this register is defined in the
"NVDIMM Driver Writer's guide":

http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
Tested-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

net: fec: use reinit_completion() in mdio accessor functions

Rather than re-initialising the entire completion on every mdio access,
use reinit_completion() which only resets the completion count.  This
avoids possible reinitialisation of the contained spinlock and waitqueue
while they may be in use (eg, mid-completion.)

Such an event could occur if there's a long delay in interrupt handling
causing the mdio accessor to time out, then a second access comes in
while the interrupt handler on a different CPU has called complete().
Another scenario where this has been observed is while locking has
been missing at the phy layer, allowing concurrent attempts to access
the MDIO bus.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect()

The phy layer is missing locking for the above two functions - it
has been observed that two threads (userspace and the phy worker
thread) can race, entering the bus ->write or ->read functions
simultaneously.

This causes the FEC driver to initialise a completion while another
thread is waiting on it or while the interrupt is calling complete()
on it, which causes spinlock unlock-without-lock, spinlock lockups,
and completion timeouts.

Fixes: a59a4d192 ("phy: add the EEE support and the way to access to the MMD registers.")
Fixes: 0c1d77dfb ("net: libphy: Add phy specific function to access mmd phy registers")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

vxlan: re-ignore EADDRINUSE from igmp_join

Before 56ef9c909b40[1] it used to ignore all errors from igmp_join().
That commit enhanced that and made it error out whatever error happened
with igmp_join(), but that's not good because when using multicast
groups vxlan will try to join it multiple times if the socket is reused
and then the 2nd and further attempts will fail with EADDRINUSE.

As we don't track to which groups the socket is already subscribed, it's
okay to just ignore that error.

Fixes: 56ef9c909b40 ("vxlan: Move socket initialization to within rtnl scope")
Reported-by: John Nielsen <lists@jnielsen.net>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'linux-can-fixes-for-4.2-20150825' of git://git./linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
this is the updated pull request of one patch by me for the peak_usb
driver. It fixes the driver, so that non FD adapters don't provide CAN
FD bittimings.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

net: compile renesas directory if NET_VENDOR_RENESAS is configured

Currently the renesas ethernet driver directory is compiled if SH_ETH is
configured rather than NET_VENDOR_RENESAS. Although incorrect that was
quite harmless as until recently as SH_ETH configured the only driver in
the renesas directory. However, as of c156633f1353 ("Renesas Ethernet AVB
driver proper") the renesas directory includes another driver, configured
by RAVB, and it makes little sense for it to have a hidden dependency on
SH_ETH.

Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[horms: rewrote changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_gre: release cached dst on tunnel removal

When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov <xeb@mail.ru>
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang <huaibin.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mtip32x: fix regression introduced by blk-mq per-hctx flush

Hi,

After commit f70ced091707 (blk-mq: support per-distpatch_queue flush
machinery), the mtip32xx driver may oops upon module load due to walking
off the end of an array in mtip_init_cmd.  On initialization of the
flush_rq, init_request is called with request_index >= the maximum queue
depth the driver supports.  For mtip32xx, this value is used to index
into an array.  What this means is that the driver will walk off the end
of the array, and either oops or cause random memory corruption.

The problem is easily reproduced by doing modprobe/rmmod of the mtip32xx
driver in a loop.  I can typically reproduce the problem in about 30
seconds.

Now, in the case of mtip32xx, it actually doesn't support flush/fua, so
I think we can simply return without doing anything.  In addition, no
other mq-enabled driver does anything with the request_index passed into
init_request(), so no other driver is affected.  However, I'm not really
sure what is expected of drivers.  Ming, what did you envision drivers
would do when initializing the flush requests?

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes()

e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
updated writeback path to avoid kicking writeback work items if there
are no inodes to be written out; unfortunately, the avoidance logic
was too aggressive and broke sync_inodes_sb().

* sync_inodes_sb() must write out I_DIRTY_TIME inodes but I_DIRTY_TIME
  inodes dont't contribute to bdi/wb_has_dirty_io() tests and were
  being skipped over.

* inodes are taken off wb->b_dirty/io/more_io lists after writeback
  starts on them.  sync_inodes_sb() skipping wait_sb_inodes() when
  bdi_has_dirty_io() breaks it by making it return while writebacks
  are in-flight.

This patch fixes the breakages by

* Removing bdi_has_dirty_io() shortcut from bdi_split_work_to_wbs().
  The callers are already testing the condition.

* Removing bdi_has_dirty_io() shortcut from sync_inodes_sb() so that
  it always calls into bdi_split_work_to_wbs() and wait_sb_inodes().

* Making bdi_split_work_to_wbs() consider the b_dirty_time list for
  WB_SYNC_ALL writebacks.

Kudos to Eryu, Dave and Jan for tracking down the issue.

Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
Link: http://lkml.kernel.org/g/20150812101204.GE17933@dhcp-13-216.nay.redhat.com
Reported-and-bisected-by: Eryu Guan <eguan@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.com>
Cc: Ted Ts'o <tytso@google.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

phylib: Make PHYs children of their MDIO bus, not the bus' parent.

commit 18ee49ddb0d2 ("phylib: rename mii_bus::dev to mii_bus::parent")
changed the parent of PHY devices from the bus to the bus parent.

Then, commit 4dea547fef1b ("phylib: rework to prepare for OF
registration of PHYs") moved the code into phy_device.c

At this point, it is somewhat unclear why the change was seen as
necessary.  But, when we look at the device model tree in
/sys/devices, it is clearly incorrect.  The PHYs should be children of
their MDIO bus.

Change the PHY's parent device to be the MDIO bus device.

Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David Daney <david.daney@cavium.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fix from Thomas Gleixner:
 "A single fix for a APIC regression introduced in 4.0 which went
  undetected until now.

  I screwed up the x2apic cleanup in a subtle way.  The screwup is only
  visible on systems which have x2apic preenabled in the BIOS and need
  to disable it during boot"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic: Fix fallout from x2apic cleanup

can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters

The CAN FD data bittiming constants are provided via netlink only when there
are valid CAN FD constants available in priv->data_bittiming_const.

Due to the indirection of pointer assignments in the peak_usb driver the
priv->data_bittiming_const never becomes NULL - not even for non-FD adapters.

The data_bittiming_const points to zero'ed data which leads to this result
when running 'ip -details link show can0':

35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state STOPPED restart-ms 0
  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
  : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0  <== BROKEN!
  clock 8000000

This patch changes the struct peak_usb_adapter::bittiming_const and struct
peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt
problems.

Cc: linux-stable <stable@vger.kernel.org> # >= 4.0
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

ALSA: hda - Fix path power activation

The widget power-saving code tries to turn up/down the power of each
widget in the I/O paths that are modified at each jack plug/unplug.
The recent report revealed that the power activation leaves some
widgets unpowered after plugging.  This is because
snd_hda_activate_path() turns on path->active flag at the end of the
function while the path power management is done before that.  Then
it's regarded as if nothing is active, and the driver turns off the
power.

The fix is simply to set the flag at the beginning of the function,
before trying to power up.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521
Cc: <stable@vger.kernel.org> [v4.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Check all inputs for is_active_nid_for_any()

The is_active_nid_for_any() function in the generic parser is supposed
to check all connections from/to the given widget, but the current
code checks only the first input connection (index = 0).

This patch corrects the code to check all inputs by passing -1 to
index argument.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521
Cc: <stable@vger.kernel.org> [v4.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

nfsd: Add Jeff Layton as co-maintainer

Jeff has been doing a lot of development (including much of the
state-locking rewrite just as one example) plus lots of review and other
miscellaneous nfsd work, so let's acknowledge the status quo.

I'll continue to be the one to send regular pull requests but Jeff will
should be available to cover there occasionally too.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

net: Fix RCU splat in af_key

Hit the following splat testing VRF change for ipsec:

[  113.475692] ===============================
[  113.476194] [ INFO: suspicious RCU usage. ]
[  113.476667] 4.2.0-rc6-1+deb7u2+clUNRELEASED #3.2.65-1+deb7u2+clUNRELEASED Not tainted
[  113.477545] -------------------------------
[  113.478013] /work/monster-14/dsa/kernel.git/include/linux/rcupdate.h:568 Illegal context switch in RCU read-side critical section!
[  113.479288]
[  113.479288] other info that might help us debug this:
[  113.479288]
[  113.480207]
[  113.480207] rcu_scheduler_active = 1, debug_locks = 1
[  113.480931] 2 locks held by setkey/6829:
[  113.481371]  #0:  (&net->xfrm.xfrm_cfg_mutex){+.+.+.}, at: [<ffffffff814e9887>] pfkey_sendmsg+0xfb/0x213
[  113.482509]  #1:  (rcu_read_lock){......}, at: [<ffffffff814e767f>] rcu_read_lock+0x0/0x6e
[  113.483509]
[  113.483509] stack backtrace:
[  113.484041] CPU: 0 PID: 6829 Comm: setkey Not tainted 4.2.0-rc6-1+deb7u2+clUNRELEASED #3.2.65-1+deb7u2+clUNRELEASED
[  113.485422] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[  113.486845]  0000000000000001 ffff88001d4c7a98 ffffffff81518af2 ffffffff81086962
[  113.487732]  ffff88001d538480 ffff88001d4c7ac8 ffffffff8107ae75 ffffffff8180a154
[  113.488628]  0000000000000b30 0000000000000000 00000000000000d0 ffff88001d4c7ad8
[  113.489525] Call Trace:
[  113.489813]  [<ffffffff81518af2>] dump_stack+0x4c/0x65
[  113.490389]  [<ffffffff81086962>] ? console_unlock+0x3d6/0x405
[  113.491039]  [<ffffffff8107ae75>] lockdep_rcu_suspicious+0xfa/0x103
[  113.491735]  [<ffffffff81064032>] rcu_preempt_sleep_check+0x45/0x47
[  113.492442]  [<ffffffff8106404d>] ___might_sleep+0x19/0x1c8
[  113.493077]  [<ffffffff81064268>] __might_sleep+0x6c/0x82
[  113.493681]  [<ffffffff81133190>] cache_alloc_debugcheck_before.isra.50+0x1d/0x24
[  113.494508]  [<ffffffff81134876>] kmem_cache_alloc+0x31/0x18f
[  113.495149]  [<ffffffff814012b5>] skb_clone+0x64/0x80
[  113.495712]  [<ffffffff814e6f71>] pfkey_broadcast_one+0x3d/0xff
[  113.496380]  [<ffffffff814e7b84>] pfkey_broadcast+0xb5/0x11e
[  113.497024]  [<ffffffff814e82d1>] pfkey_register+0x191/0x1b1
[  113.497653]  [<ffffffff814e9770>] pfkey_process+0x162/0x17e
[  113.498274]  [<ffffffff814e9895>] pfkey_sendmsg+0x109/0x213

In pfkey_sendmsg the net mutex is taken and then pfkey_broadcast takes
the RCU lock.

Since pfkey_broadcast takes the RCU lock the allocation argument is
pointless since GFP_ATOMIC must be used between the rcu_read_{,un}lock.
The one call outside of rcu can be done with GFP_KERNEL.

Fixes: 7f6b9dbd5afbd ("af_key: locking change")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

perf tools: Update Intel PT documentation

Update Intel PT documentation to describe new features.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-26-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for decoding TRACESTOP packets

A TRACESTOP packet is produced when an Intel PT trace enters a defined
region of the address space at which point the tracing stops.

This patch just adds decoder support.

Support for specifying TRACESTOP regions is left until later.

For details refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-25-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for using CYC packets

CYC packets are a new Intel PT feature.

CYC packets provide even finer grain timestamp information than MTC and
TSC packets.  A CYC packet contains the number of CPU cycles since the
last CYC packet. Unlike MTC and TSC packets, CYC packets are only sent
when another packet is also sent.

Support for this feature is indicated by:

/sys/bus/event_source/devices/intel_pt/caps/psb_cyc

which contains "1" if the feature is supported and "0" otherwise.

CYC packets can be requested using a PMU config term e.g. perf record -e
intel_pt/cyc/u sleep 1

The frequency of CYC packets can also be specified.  e.g. perf record -e
intel_pt/cyc,cyc_thresh=2/u sleep 1

CYC packets are not requested by default.

Valid cyc_thresh values are given by:

/sys/bus/event_source/devices/intel_pt/caps/cycle_thresholds

which contains a hexadecimal value, the bits of which represent valid
values e.g. bit 2 set means value 2 is valid.

The value represents the minimum number of CPU cycles that must have
passed before a CYC packet can be sent.  The number of CPU cycles is:

    2 ^ (value - 1)

e.g. value 4 means 8 CPU cycles must pass before a CYC packet can be
sent.  Note a CYC packet is still only sent when another packet is sent,
not at, e.g. every 8 CPU cycles.

If an invalid value is entered, the error message will give a list of
valid values e.g.

    $ perf record -e intel_pt/cyc,cyc_thresh=15/u uname
    Invalid cyc_thresh for intel_pt. Valid values are: 0-12

tools/perf/Documentation/intel-pt.txt is updated in a later patch as
there are a number of new features being added.

For more information refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-24-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for decoding CYC packets

CYC packets provide even finer grain timestamp information than MTC and
TSC packets.  A CYC packet contains the number of CPU cycles since the
last CYC packet.

This patch just adds decoder support.  The CPU frequency can be related
to TSC using the Maximum Non-Turbo Ratio in combination with the CBR
(core-to-bus ratio) packet.  However more accuracy is achieved by simply
interpolating the number of cycles between other timing packets like MTC
or TSC.  This patch takes the latter approach.

Support for a default value and validation of values is provided by a
later patch. Also documentation is updated in a separate patch.

For details refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-23-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for using MTC packets

MTC packets are a new Intel PT feature.

MTC packets provide finer grain timestamp information than TSC packets.

Support for this feature is indicated by:

  /sys/bus/event_source/devices/intel_pt/caps/mtc

which contains "1" if the feature is supported and "0" otherwise.

MTC packets can be requested using a PMU config term e.g. perf record -e
intel_pt/mtc/u sleep 1

The frequency of MTC packets can also be specified.  e.g. perf record -e
intel_pt/mtc,mtc_period=2/u sleep 1

The default value is 3 or the nearest lower value that is supported.  0
is always supported.

Valid values are given by:

/sys/bus/event_source/devices/intel_pt/caps/mtc_periods

which contains a hexadecimal value, the bits of which represent valid
values e.g. bit 2 set means value 2 is valid.

The value is converted to the MTC frequency as:

CTC-frequency / (2 ^ value)

e.g. value 3 means one eighth of CTC-frequency

Where CTC is the hardware crystal clock, the frequency of which can be
related to TSC via values provided in cpuid leaf 0x15.

If an invalid value is entered, the error message will give a list of
valid values e.g.

$ perf record -e intel_pt/mtc_period=15/u uname
Invalid mtc_period for intel_pt. Valid values are: 0,3,6,9

tools/perf/Documentation/intel-pt.txt is updated in a later patch as
there are a number of new features being added.

For more information refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-22-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for decoding MTC packets

MTC packets provide finer grain timestamp information than TSC packets.
MTC packets record time using the hardware crystal clock (CTC) which is
related to TSC packets using a TMA packet.

This patch just adds decoder support.

Support for a default value and validation of values is provided by a
later patch. Also documentation is updated in a separate patch.

For details refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-21-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Pass Intel PT information for decoding MTC and CYC

Record additional information in the AUXTRACE_INFO event in preparation
for decoding MTC and CYC packets.  Pass the information to the decoder.

The AUXTRACE_INFO record can be extended by using the size to indicate
the presence of new members.

The additional information includes PMU config bit positions and the TSC
to CTC (hardware crystal clock) ratio needed to decode MTC packets.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-20-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add new Intel PT packet definitions

New features have been added to Intel PT which include a number of new
packet definitions.

This patch adds packet definitions for new packets: TMA, MTC, CYC, VMCS,
TRACESTOP and MNT.  Also another bit in PIP is defined.

This patch only adds support for the definitions. Later patches add
support for decoding TMA, MTC, CYC and TRACESTOP which is where those
packets are explained.

VMCS and the newly defined bit in PIP are used with virtualization which
is not supported yet.  MNT is a maintenance packet which the decoder
should ignore.

For details, refer to the June 2015 or later Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-19-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Add Intel PT support for PSB periods

The PSB packet is a synchronization packet that provides a starting
point for decoding or recovery from errors.

This patch adds support for a new Intel PT feature that allows the
frequency of PSB packets to be specified.

Support for this feature is indicated by
/sys/bus/event_source/devices/intel_pt/caps/psb_cyc which contains "1"
if the feature is supported and "0" otherwise.

The PSB period can be specified as a PMU config term e.g. perf record -e
intel_pt/psb_period=2/u sleep 1

The default value is 3 or the nearest lower value that is supported.  0
is always supported.

Valid values are given by:

/sys/bus/event_source/devices/intel_pt/caps/psb_periods

which contains a hexadecimal value, the bits of which represent valid
values e.g. bit 2 set means value 2 is valid.

The value is converted to the approximate number of trace bytes between
PSB packets as:

2 ^ (value + 11)

e.g. value 3 means 16KiB bytes between PSBs

If an invalid value is entered, the error message will give a list of
valid values e.g.

$ perf record -e intel_pt/psb_period=15/u uname
Invalid psb_period for intel_pt. Valid values are: 0-5

tools/perf/Documentation/intel-pt.txt is updated in a later patch as
there are a number of new features being added.

For more information about PSB periods refer to the Intel 64 and IA-32
Architectures SDM Chapter 36 Intel Processor Trace from June 2015 or
later.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-18-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Fix Intel PT 'instructions' sample period

The period on synthesized 'instructions' samples was being set to a
fixed value, whereas the correct value is the number of instructions
since the last sample, which is a value that the decoder can provide.
So do it that way.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1437150840-31811-14-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf ordered_events: Clear the progress bar at the end of a flush

We were depending on the next screen operation after a flush() being
one that would redraw the whole screen so that the progress bar would
be overwritten, when that didn't happen a screen artifact of, say, a
error dialog window would be overlaid on top of the progress bar, fix
it by calling ui_browser__finish(), that now has a TUI implementation.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-el0fyw6duemnx62lydjzhs8c@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf ui tui progress: Implement the ui_progress_ops->finish() method

So that we can erase the progress bar after we're done with it, avoiding
things like:

-------------------------------------------------------------------

          ┌─Error:──────────────────────────────────────────────────────┐
          │Can't annotate unmapped_area_topdown:                        │
          │                                                             │
          │No vmlinux file with build id a826726b5ddacfab1f0bade868f1a79│
          │was found in the path.                                       │
          │                                                             │
          │Note that annotation using /proc/kcore requires CAP_SYS_RAWIO│
┌Processin│                                                             │──┐
│         │Please use:                                                  │  │
└─────────│                                                             │──┘
          │  perf buildid-cache -vu vmlinux                             │
          │                                                             │
          │or:                                                          │
          │                                                             │
          │  --vmlinux vmlinux                                          │
          │                                                             │
          │                                                             │
          │Press any key...                                             │
          └─────────────────────────────────────────────────────────────┘

Can't annotate unmapped_area_topdown:
-------------------------------------------------------------------

I.e. that finished progress bar behind the error window. It is not a
problem when we end up redrawing the whole screen, but its ugly when
we present such error windows, provide a TUI method so that code like
the above may avoid this situation, as will be done with the annotation
code in the next cset.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-qvktnojzwwe37pweging058t@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf annotate: Reset the dso find_symbol cache when removing symbols

The 'annotate' tool does some filtering in the entries in a DSO but
forgot to reset the cache done in dso__find_symbol(), cauxing a SEGV:

  [root@zoo ~]# perf annotate netlink_poll
  perf: Segmentation fault
  -------- backtrace --------
  perf[0x526ceb]
  /lib64/libc.so.6(+0x34960)[0x7faedfbe0960]
  perf(rb_erase+0x223)[0x499d63]
  perf[0x4213e9]
  perf[0x4bc123]
  perf[0x4bc621]
  perf[0x4bf26b]
  perf[0x4bc855]
  perf(perf_session__process_events+0x340)[0x4bddc0]
  perf(cmd_annotate+0x6bb)[0x421b5b]
  perf[0x479063]
  perf(main+0x60a)[0x42098a]
  /lib64/libc.so.6(__libc_start_main+0xf0)[0x7faedfbcbfe0]
  perf[0x420aa9]
  [0x0]
  [root@zoo ~]#

Fix it by reseting the find cache when removing symbols.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Fixes: b685ac22b436 ("perf symbols: Add front end cache for DSO symbol lookup")
Link: http://lkml.kernel.org/n/tip-b2y9x46y0t8yem1ive41zqyp@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

ALSA: hda: fix possible NULL dereference

After a for-loop was replaced by list_for_each_entry, see
Commit bbbc7e8502c9 ("ALSA: hda - Allocate hda_pcm objects dynamically"),
Commit 751e2216899c ("ALSA: hda: fix possible null dereference"),
a possible NULL pointer dereference has been introduced; this patch adds
the NULL check on pcm->pcm, while leaving a potentially superfluous
check on pcm itself untouched.

Signed-off-by: Markus Osterhoff <linux-kernel@k-raum.org>
Cc: <stable@vger.kernel.org> #v4.1+
Signed-off-by: Takashi Iwai <tiwai@suse.de>

net: bcmgenet: fix uncleaned dma flags

Clean the dma flags of multiq ring buffer int the interface stop
process. This patch fixes that the genet is not running while the
interface is re-enabled.

$ ifup eth0 - running after booting
$ ifdown eth0
$ ifup eth0 - not running and occur tx_timeout

The bcmgenet_dma_disable() in bcmgenet_open() do clean ring16 dma flag
only. If the genet has multiq, the dma register is not cleaned. and
bcmgenet_init_dma() is not done correctly. in case
GENET_V2(tx_queues=4), tdma_ctrl has 0x1e after running
bcmgenet_dma_disable().

Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: bcmgenet: Avoid sleeping in bcmgenet_timeout

bcmgenet_timeout() executes in atomic context, yet we will invoke
napi_disable() which does sleep. Looking back at the changes, disabling
TX napi and re-enabling it is completely useless, since we reclaim all
TX buffers and re-enable interrupts, and wake up the TX queues.

Fixes: 13ea657806cf ("net: bcmgenet: improve TX timeout")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 4.2-rc8

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "A couple of major (hang and deadlock) fixes with fortunately fairly
  rare triggering conditions.  The PM oops is only really triggered by
  people using enclosure services (rare) and the fnic driver is mostly
  used in enterprise environments"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  SCSI: Fix NULL pointer dereference in runtime PM
  fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack

netlink: mmap: fix tx type check

I can't send netlink message via mmaped netlink socket since

    commit: a8866ff6a5bce7d0ec465a63bc482a85c09b0d39
    netlink: make the check for "send from tx_ring" deterministic

msg->msg_iter.type is set to WRITE (1) at

    SYSCALL_DEFINE6(sendto, ...
        import_single_range(WRITE, ...
            iov_iter_init(1, WRITE, ...

call path, so that we need to check the type by iter_is_iovec()
to accept the WRITE.

Signed-off-by: Ken-ichirou MATSUZAWA <chamas@h4.dion.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS bug fixes from Ralf Baechle:
 "Two more fixes for 4.2.

  One fixes a build issue with the LLVM assembler - LLVM assembler macro
  names are case sensitive, GNU as macro names are insensitive; the
  other corrects a license string (GPL v2, not GPLv2) such that the
  module loader will recognice the license correctly"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  FIRMWARE: bcm47xx_nvram: Fix module license.
  MIPS: Fix LLVM build issue.

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs

Pull 9p regression fix from Al Viro:
 "Fix for breakage introduced when switching p9_client_{read,write}() to
  struct iov_iter * (went into 4.1)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  9p: ensure err is initialized to 0 in p9_client_read/write

9p: ensure err is initialized to 0 in p9_client_read/write

Some use of those functions were providing unitialized values to those
functions. Notably, when reading 0 bytes from an empty file on a 9P
filesystem, the return code of read() was not 0.

Tested with this simple program:

    #include <assert.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main(int argc, const char **argv)
    {
        assert(argc == 2);
        char buffer[256];
        int fd = open(argv[1], O_RDONLY|O_NOCTTY);
        assert(fd >= 0);
        assert(read(fd, buffer, 0) == 0);
        return 0;
    }

Cc: stable@vger.kernel.org # v4.1
Signed-off-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Another couple of small ARM fixes.

  A patch from Masahiro Yamada who noticed that "make -jN all zImage"
  would end up generating bad images where N > 1, and a patch from
  Nicolas to fix the Marvell CPU user access optimisation code when page
  faults are disabled"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8418/1: add boot image dependencies to not generate invalid images
  ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage

perf tools: Fix tarball build broken by pt/bts

Fix some include paths and add missing inat_types.h.

Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/55D77696.60102@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Various low level fixes: fix more fallout from the FPU rework and the
  asm entry code rework, plus an MSI rework fix, and an idle-tracing fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu/math-emu: Fix crash in fork()
  x86/fpu/math-emu: Fix math-emu boot crash
  x86/idle: Restore trace_cpu_idle to mwait_idle() calls
  x86/irq: Build correct vector mapping for multiple MSI interrupts
  Revert "sched/x86_64: Don't save flags on context switch"

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

Pull perf fixes from Ingo Molnar:
 "Tooling fixes: a 'perf record' deadlock fix plus debuggability fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf top: Show backtrace when handling a SIGSEGV on --stdio mode
  perf tools: Fix buildid processing
  perf tools: Make fork event processing more resilient
  perf tools: Avoid deadlock when map_groups are broken

x86/apic: Fix fallout from x2apic cleanup

In the recent x2apic cleanup I got two things really wrong:
1) The safety check in __disable_x2apic which allows the function to
   be called unconditionally is backwards. The check is there to
   prevent access to the apic MSR in case that the machine has no
   apic. Though right now it returns if the machine has an apic and
   therefor the disabling of x2apic is never invoked.

2) x2apic_disable() sets x2apic_mode to 0 after registering the local
   apic. That's wrong, because register_lapic_address() checks x2apic
   mode and therefor takes the wrong code path.

This results in boot failures on machines with x2apic preenabled by
BIOS and can also lead to an fatal MSR access on machines without
apic.

The solutions are simple:
1) Correct the sanity check for apic availability
2) Clear x2apic_mode _before_ calling register_lapic_address()

Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function'
Reported-and-tested-by: Javier Monteagudo <javiermon@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
Cc: stable@vger.kernel.org # 4.0+
Cc: Laura Abbott <labbott@redhat.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>

Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "A series of small fixlets for a regression visible on OMAP devices
  caused by the conversion of the OMAP interrupt chips to hierarchical
  interrupt domains.  Mostly one liners on the driver side plus a small
  helper function in the core to avoid open coded mess in the drivers"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/crossbar: Restore set_wake functionality
  irqchip/crossbar: Restore the mask on suspend behaviour
  ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism
  irqchip/crossbar: Restore the irq_set_type() mechanism
  genirq: Introduce irq_chip_set_type_parent() helper
  genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

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

Pull timer fixes from Thomas Gleixner:
 "Two minimalistic fixes for 4.2 regressions:

   - Eric fixed a thinko in the timer_list base switching code caused by
     the overhaul of the timer wheel.  It can cause a cpu to see the
     wrong base for a timer while we move the timer around.

   - Guenter fixed a regression for IMX if booted w/o device tree, where
     the timer interrupt is not initialized and therefor the machine
     fails to boot"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource/imx: Fix boot with non-DT systems
  timer: Write timer->flags atomically

x86/fpu/math-emu: Fix crash in fork()

During later stages of math-emu bootup the following crash triggers:

 math_emulate: 0060:c100d0a8
 Kernel panic - not syncing: Math emulation needed in kernel
 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
 [...]
 Call Trace:
  [<c181d50d>] dump_stack+0x41/0x52
  [<c181c918>] panic+0x77/0x189
  [<c1003530>] ? math_error+0x140/0x140
  [<c164c2d7>] math_emulate+0xba7/0xbd0
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
  [<c136ac20>] ? proc_clear_tty+0x40/0x70
  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
  [<c1003530>] ? math_error+0x140/0x140
  [<c1003575>] do_device_not_available+0x45/0x70
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c18258e6>] error_code+0x5a/0x60
  [<c1003530>] ? math_error+0x140/0x140
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c100c205>] arch_dup_task_struct+0x25/0x30
  [<c1048cea>] copy_process.part.51+0xea/0x1480
  [<c115a8e5>] ? dput+0x175/0x200
  [<c136af70>] ? no_tty+0x30/0x30
  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
  [<c104a21a>] _do_fork+0xca/0x340
  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
  [<c104a557>] SyS_clone+0x27/0x30
  [<c1824a80>] sysenter_do_call+0x12/0x12

The reason is the incorrect assumption in fpu_copy(), that FNSAVE
can be executed from math-emu kernels as well.

Don't try to copy the registers, the soft state will be copied
by fork anyway, so the child task inherits the parent task's
soft math state.

With this fix applied math-emu kernels boot up fine on modern
hardware and the 'no387 nofxsr' boot options.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Bobby Powers <bobbypowers@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

x86/fpu/math-emu: Fix math-emu boot crash

On a math-emu bootup the following crash occurs:

Initializing CPU#0
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/traps.c:779!
invalid opcode: 0000 [#1] SMP
[...]
EIP is at do_device_not_available+0xe/0x70
[...]
Call Trace:
 [<c18238e6>] error_code+0x5a/0x60
 [<c1002bd0>] ? math_error+0x140/0x140
 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
 [<c1012322>] cpu_init+0x202/0x330
 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
 [<c1b56ab0>] trap_init+0x305/0x346
 [<c1b548af>] start_kernel+0x1a5/0x35d
 [<c1b542b4>] i386_start_kernel+0x82/0x86

The reason is that in the following commit:

  b1276c48e91b ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")

I failed to consider math-emu's limitation that it cannot execute the
FNINIT instruction in kernel mode.

The long term fix might be to allow math-emu to execute (certain) kernel
mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
fix: initialize the emulation state explicitly without trapping out to
the FPU emulator.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'perf-core-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/core

Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:

User visible changes:

  - Fix segfault using 'perf script --show-mmap-events', affects
    only current perf/core. (Adrian Hunter)

  - /proc/kcore requires CAP_SYS_RAWIO message too noisy, make it
    debug only. (Adrian Hunter)

  - Fix Intel PT timestamp handling. (Adrian Hunter)

  - Add Intel BTS support, with a call-graph script to show it and
    PT in use in a GUI using 'perf script' python scripting with
    postgresql and Qt. (Adrian Hunter)

  - Add checks for returned EVENT_ERROR type in libtraceevent, fixing
    a bug that surfaced on arm64 systems. (Dean Nelson)

  - Fallback to using kallsyms when libdw fails to handle a vmlinux file,
    that can happen, for instance, when perf is statically linked and
    then libdw fails to load libebl_{arch}.so. (Wang Nan)

Infrastructure changes:

  - Initialize reference counts in map__clone(). (Arnaldo Carvalho de Melo)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Add hch to .get_maintainer.ignore

While the idea behind get_maintainer seems highly useful it's
unfortunately way to trigger happy to grab people that once had a few
commits to files.  For someone like me who does a lot of tree-wide API
work that leads to an incredible amount of Cc spam.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: make page pfmemalloc check more robust

Commit c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb") added
checks for page->pfmemalloc to __skb_fill_page_desc():

        if (page->pfmemalloc && !page->mapping)
                skb->pfmemalloc = true;

It assumes page->mapping == NULL implies that page->pfmemalloc can be
trusted.  However, __delete_from_page_cache() can set set page->mapping
to NULL and leave page->index value alone.  Due to being in union, a
non-zero page->index will be interpreted as true page->pfmemalloc.

So the assumption is invalid if the networking code can see such a page.
And it seems it can.  We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf.  There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.

The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead.  We can reuse the index
again but define it to an impossible value (-1UL).  This is the page
index so it should never see the value that large.  Replace all direct
users of page->pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.

The information will get lost if somebody wants to use page->index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g.  what SLAB and SLUB do).

[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Debugged-by: Vlastimil Babka <vbabka@suse.com>
Debugged-by: Jiri Bohac <jbohac@suse.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org> [3.6+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>