Dccp verifies packet integrity, including length, at initial rcv in
dccp_invalid_packet, later pulls headers in dccp_enqueue_skb.
A call to sk_filter in-between can cause __skb_pull to wrap skb->len.
skb_copy_datagram_msg interprets this as a negative value, so
(correctly) fails with EFAULT. The negative length is reported in
ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close.
Introduce an sk_receive_skb variant that caps how small a filter
program can trim packets, and call this in dccp with the header
length. Excessively trimmed packets are now processed normally and
queued for reception as 0B payloads.
Fixes: 7c657876b6 ("[DCCP]: Initial implementation")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sockets can have a filter program attached that drops or trims
incoming packets based on the filter program return value.
Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
verifies this on arrival in rose_route_frame and unconditionally pulls
the bytes in rose_recvmsg. The filter can trim packets to below this
value in-between, causing pull to fail, leaving the partial header at
the time of skb_copy_datagram_msg.
Place a lower bound on the size to which sk_filter may trim packets
by introducing sk_filter_trim_cap and call this for rose packets.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Not all libelf implementations have this "Please, ELF_C_READ, but use
mmap if possible" elf_begin() cmd, so provide a fallback to plain old
ELF_C_READ.
Case in point: Alpine Linux 3.4.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-1fctuknrawgoi5xqon4mu9dv@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Saeed Mahameed says:
====================
mlx5 tx timeout watchdog fixes
This patch set provides two trivial fixes for the tx timeout series lately
applied into net 4.7.
From Daniel, detect stuck queues due to BQL
From Mohamad, fix tx timeout watchdog false alarm
Hopefully those two fixes will make it to -stable, assuming
3947ca1859 ('net/mlx5e: Implement ndo_tx_timeout callback') was also backported to -stable.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Start all tx queues (including inactive ones) when opening the netdev.
Stop all tx queues (including inactive ones) when closing the netdev.
This is a workaround for the tx timeout watchdog false alarm issue in
which the netdev watchdog is polling all the tx queues which may include
inactive queues and thus once lowering the real tx queues number
(ethtool -L) it will generate tx timeout watchdog false alarms.
Fixes: 3947ca1859 ('net/mlx5e: Implement ndo_tx_timeout callback')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change netif_tx_queue_stopped to netif_xmit_stopped. This will show
when queues are stopped due to byte queue limits.
Fixes: 3947ca1859 ('net/mlx5e: Implement ndo_tx_timeout callback')
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It was set based on CONFIG_64BIT, that is available only when using
Kconfig, which we're working towards but not to the point of having this
CONFIG variable set, so synthesize it from available compiler defined
defines, __SIZEOF_LONG__ or, lacking that, __WORDSIZE.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-og5fmkr17856lhupacihwxvb@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The move of calc_load_migrate() from CPU_DEAD to CPU_DYING did not take into
account that the function is now called from a thread running on the outgoing
CPU. As a result a cpu unplug leakes a load of 1 into the global load
accounting mechanism.
Fix it by adjusting for the currently running thread which calls
calc_load_migrate().
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: rt@linutronix.de
Cc: shreyas@linux.vnet.ibm.com
Fixes: e9cd8fa4fc: ("sched/migration: Move calc_load_migrate() into CPU_DYING")
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1607121744350.4083@nanos
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXhhNXAAoJEAhfPr2O5OEVydgP/A6DOW7KTQ/0yRlKxvvGObqV
Fdxwt2bUypksRhSh0r/cMpI2ILDGbXJyVseyz3zJ8LfRPw5Sm+BqkqiMfNte47c9
fc1faaIR6MHkfPbzjBYM+4i2GGuHJ6ltjWGrL+ZnaXwYmJQcbGQGBZu/JX5N+gjm
qc++PFb8P3IieK4IL5+xRWaaXeCceyVIc8KK4f3LHPH7zH5dsuPQEeEOhjK74PLI
5uxmI6S15tK0OB+PqYAlwIwaGGhXWGOuVboXpCFQ+T6SEHmpblnC90XGjfFDGsIo
ai5BXGiiokTSD5vvZwa/f0rnEiqk+uxLpibercaI2zUQaoLxqysnDIVZGH9wmMZD
Ddh2QayZO3xFdGDIt/pXQuxAj/IvRI5IbRJqzKPOw3bJGjrkpJRXqRXUS7nMWCbF
OJns6HbFq4UaCpxmHjutPA3xE7rWRer25aok1hEMkqAGjFmVK1dmTvinO8eolgc9
MZlX/J/fGwkcNXzUOAwzrO52DC6qVQbxNfpZ/8daLDjSMNA0IjV/ubpm8TJ/PRn4
fyefImTiswpq1vJSO9sINitzQIMQEpAA/VokPAkVuDCs7Bu2YLvcSLU2IRIWXetB
D7ayQxaZnGsbCOCi95IfUvEAdvOpauRf0QvRDnEW4puHvJxrt1a1vjKD8VoArV8M
U6RVqs7kjqw6FNDAwp3J
=L9yq
-----END PGP SIGNATURE-----
Merge tag 'media/v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Two regression fixes:
- a regression when handling VIDIOC_CROPCAP at the media core;
- a regression at adv7604 that was ignoring pad number in subdev ops"
* tag 'media/v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] adv7604: Don't ignore pad number in subdev DV timings pad operations
[media] v4l2-ioctl: fix stupid mistake in cropcap condition
Use the same code structure when determining preferred consoles for
Linux running as KVM guest as with Linux running in LPAR and z/VM
guest:
- Extend the console_mode variable to cover vt220 and hvc consoles
- Determine sensible console defaults in conmode_default()
- Remove KVM-special handling in set_preferred_console()
Ensure that the sclp line mode console is also registered when the
vt220 console was selected to not change existing behavior that
someone might be relying on.
As an externally visible change, KVM guest users can now select
the 3270 or 3215 console devices using the conmode= kernel parameter,
provided that support for the corresponding driver was compiled into
the kernel.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
__tlb_flush_asce() should never be used if multiple asce belong to a mm.
As this function changes mm logic determining if local or global tlb
flushes will be neded, we might end up flushing only the gmap asce on all
CPUs and a follow up mm asce flushes will only flush on the local CPU,
although that asce ran on multiple CPUs.
The missing tlb flushes will provoke strange faults in user space and even
low address protections in user space, crashing the kernel.
Fixes: 1b948d6cae ("s390/mm,tlb: optimize TLB flushing for zEC12")
Cc: stable@vger.kernel.org # 3.15+
Reported-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The page table manipulation code seems to have grown a couple of
sites that are looking for empty PTEs. Just in case one of these
entries got a stray bit set, use pte_none() instead of checking
for a zero pte_val().
The use pte_same() makes me a bit nervous. If we were doing a
pte_same() check against two cleared entries and one of them had
a stray bit set, it might fail the pte_same() check. But, I
don't think we ever _do_ pte_same() for cleared entries. It is
almost entirely used for checking for races in fault-in paths.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: dave.hansen@intel.com
Cc: linux-mm@kvack.org
Cc: mhocko@suse.com
Link: http://lkml.kernel.org/r/20160708001915.813703D9@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights
Landing) has an erratum where a processor thread setting the Accessed
or Dirty bits may not do so atomically against its checks for the
Present bit. This may cause a thread (which is about to page fault)
to set A and/or D, even though the Present bit had already been
atomically cleared.
These bits are truly "stray". In the case of the Dirty bit, the
thread associated with the stray set was *not* allowed to write to
the page. This means that we do not have to launder the bit(s); we
can simply ignore them.
If the PTE is used for storing a swap index or a NUMA migration index,
the A bit could be misinterpreted as part of the swap type. The stray
bits being set cause a software-cleared PTE to be interpreted as a
swap entry. In some cases (like when the swap index ends up being
for a non-existent swapfile), the kernel detects the stray value
and WARN()s about it, but there is no guarantee that the kernel can
always detect it.
When we have 64-bit PTEs (64-bit mode or 32-bit PAE), we were able
to move the swap PTE format around to avoid these troublesome bits.
But, 32-bit non-PAE is tight on bits. So, disallow it from running
on this hardware. I can't imagine anyone wanting to run 32-bit
non-highmem kernels on this hardware, but disallowing them from
running entirely is surely the safe thing to do.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: dave.hansen@intel.com
Cc: linux-mm@kvack.org
Cc: mhocko@suse.com
Link: http://lkml.kernel.org/r/20160708001914.D0B50110@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The erratum we are fixing here can lead to stray setting of the
A and D bits. That means that a pte that we cleared might
suddenly have A/D set. So, stop considering those bits when
determining if a pte is pte_none(). The same goes for the
other pmd_none() and pud_none(). pgd_none() can be skipped
because it is not affected; we do not use PGD entries for
anything other than pagetables on affected configurations.
This adds a tiny amount of overhead to all pte_none() checks.
I doubt we'll be able to measure it anywhere.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: dave.hansen@intel.com
Cc: linux-mm@kvack.org
Cc: mhocko@suse.com
Link: http://lkml.kernel.org/r/20160708001912.5216F89C@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This erratum can result in Accessed/Dirty getting set by the hardware
when we do not expect them to be (on !Present PTEs).
Instead of trying to fix them up after this happens, we just
allow the bits to get set and try to ignore them. We do this by
shifting the layout of the bits we use for swap offset/type in
our 64-bit PTEs.
It looks like this:
bitnrs: | ... | 11| 10| 9|8|7|6|5| 4| 3|2|1|0|
names: | ... |SW3|SW2|SW1|G|L|D|A|CD|WT|U|W|P|
before: | OFFSET (9-63) |0|X|X| TYPE(1-5) |0|
after: | OFFSET (14-63) | TYPE (9-13) |0|X|X|X| X| X|X|X|0|
Note that D was already a don't care (X) even before. We just
move TYPE up and turn its old spot (which could be hit by the
A bit) into all don't cares.
We take 5 bits away from the offset, but that still leaves us
with 50 bits which lets us index into a 62-bit swapfile (4 EiB).
I think that's probably fine for the moment. We could
theoretically reclaim 5 of the bits (1, 2, 3, 4, 7) but it
doesn't gain us anything.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: dave.hansen@intel.com
Cc: linux-mm@kvack.org
Cc: mhocko@suse.com
Link: http://lkml.kernel.org/r/20160708001911.9A3FD2B6@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The objtool build fails with the recent changes to the bits-per-long
headers:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
Which got introduced by:
bb9707077b tools: Copy the bitsperlong.h files from the kernel
Work it around for the time being.
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Xiaolong Ye reported lock debug warnings triggered by the following commit:
8de4a0066106 ("perf/x86: Convert the core to the hotplug state machine")
The bug is the following: the cpuhp_bp_states[] array is cut short when
CONFIG_SMP=n, but the dynamically registered callbacks are stored nevertheless
and happily scribble outside of the array bounds...
We need to store them in case that the state is unregistered so we can invoke
the teardown function. That's independent of CONFIG_SMP. Make sure the array
is large enough.
Reported-by: kernel test robot <xiaolong.ye@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Adam Borowski <kilobyte@angband.pl>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: lkp@01.org
Cc: stable@vger.kernel.org
Cc: tipbuild@zytor.com
Fixes: cff7d378d3 "cpu/hotplug: Convert to a state machine for the control processor"
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1607122144560.4083@nanos
Signed-off-by: Ingo Molnar <mingo@kernel.org>
SFI specification v0.8.2 defines type of devices which are connected to
SD bus. In particularly WiFi dongle is a such.
Add a callback to enumerate the devices connected to SD bus.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1468322192-62080-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Everywhere in the kernel the MRFLD is used as abbreviation of Intel Merrifield.
Do the same in intel_mid_pci.c module.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1468321462-136016-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
User visible:
- Add demangling of symbols in programs written in the Rust language (David Tolnay)
- Add support for tracepoints in the python binding, including an example, that
sets up and parses sched:sched_switch events, tools/perf/python/tracepoint.py
(Jiri Olsa)
- Introduce --stdio-color to setup the color output mode selection in
'annotate' and 'report', allowing emit color escape sequences when
redirecting the output of these tools (Arnaldo Carvalho de Melo)
Infrastructure:
- Various tweaks to allow the 'perf trace' beautifiers to build without using
kernel headers and in a wider range of Linux distributions/releases (Arnaldo Carvalho de Melo)
- Stop using kernel source files, instead copy what is needed and
check when the original kernel source file gets modified, warning
the developers about it. This helps in building the tool in older
systems and even in recent ones, for just added kernel features
for which ABI details (struct changes, defines, etc) still are not
available on system headers (Arnaldo Carvalho de Melo)
- Be consistent in how to use strerror_r, adding a wrapper that makes sure that
it returns a pointer to passed buffer, and using the XSI variant, that is
available in more libc implementations (Arnaldo Carvalho de Melo)
- Avoid checking code drift on busibox's diff perf intel-pt-decoder, as it
doesn't have the '-I' command line switch to check for regexps (Arnaldo Carvalho de Melo)
- Add missing headers in various places (Arnaldo Carvalho de Melo)
- Remove unneeded headers from various other places (Arnaldo Carvalho de Melo)
- Add feature detection for gelf_getnote(), disabling SDT support if not
present (Arnaldo Carvalho de Melo)
- Fix oddities with gcc 5.3.0 by initializing some variables (Arnaldo Carvalho de Melo)
- With those changes in place perf now builds on Alpine Linux 3.4, in addition to
on centos (5, 6, 7), debian (7, 8, experimental), fedora (21, 22, 23, 24, rawhide),
mageia 5, opensuse (13.2, 42.1) and ubuntu (12.04.5, 14.04.4, 15.10, 16.04) and
will be test build on those systems prior to future pull requests.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXhWxYAAoJENZQFvNTUqpAiKwP/3RmS3dkTOjKo2GSYOdtKPAm
vBuv6LFLLNG0W/sye8QOYa3YbwfA1q3dWs38ZusXTrwATIB9kieLLhETLQ4nHtvk
N1czaOynyINJKfnwCc8CiGm9OgtG9ytOUO2+I9HRqO8ep81kbRfE3diDD01h2Rh6
YhJzIIUojqxk3wFebkN2RWOEMlCngRx4cKwPiY1C3cVIfrXOTBjWeUN+BHeVpKDb
XlYDFnuKZdVVhNZNh3eTr9eEwMFGlEv3tx7aOZfauuSSfxlWNF4t2UQDGUQ7D85v
fHoHzSJ929QjVniuOcqnQISB9tyWddpjZ8/dT/OFuzIH9JyNRSWOARfA1Lp+zxNG
OZlVvNjZZmD9KNDAMbMLWcJS9TWIkUsOs9T3m15borB3nvpZUdxWw/taAh3/m22r
hxDNUp2NXlg6oQea2DA/rXU9XUTkH/BCln4kxlYHsgZhfhpw94tIzj3tIyYF+85D
JZwherpUpVOoaEEAIBQR46bPrNI39nnA/u3Xex/GsfXbQkvEhzdNKdH9Av8WG0EI
onLY16ta1kv37PaTGwZAY7U8GJnSss9K8nV0JADQ+/vjBSVMBUnIC6J/WuorDi0N
GPVF5AuckZGICEMLzyQfr7AMItMwhw+ADo5EwX2irR1F6gLyBMx51xZwSSfHf5wR
6dtFYt0Z5NewXlrT195O
=4IXA
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo-20160712' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
User visible changes:
- Add demangling of symbols in programs written in the Rust language (David Tolnay)
- Add support for tracepoints in the python binding, including an example, that
sets up and parses sched:sched_switch events, tools/perf/python/tracepoint.py
(Jiri Olsa)
- Introduce --stdio-color to set up the color output mode selection in
'annotate' and 'report', allowing emit color escape sequences when
redirecting the output of these tools (Arnaldo Carvalho de Melo)
Infrastructure changes:
- Various tweaks to allow the 'perf trace' beautifiers to build without using
kernel headers and in a wider range of Linux distributions/releases
(Arnaldo Carvalho de Melo)
- Stop using kernel source files, instead copy what is needed and
check when the original kernel source file gets modified, warning
the developers about it. This helps in building the tool in older
systems and even in recent ones, for just added kernel features
for which ABI details (struct changes, defines, etc) still are not
available on system headers (Arnaldo Carvalho de Melo)
- Be consistent in how to use strerror_r, adding a wrapper that makes sure that
it returns a pointer to passed buffer, and using the XSI variant, that is
available in more libc implementations (Arnaldo Carvalho de Melo)
- Avoid checking code drift on busibox's diff perf intel-pt-decoder, as it
doesn't have the '-I' command line switch to check for regexps
(Arnaldo Carvalho de Melo)
- Add missing headers in various places (Arnaldo Carvalho de Melo)
- Remove unneeded headers from various other places (Arnaldo Carvalho de Melo)
- Add feature detection for gelf_getnote(), disabling SDT support if not
present (Arnaldo Carvalho de Melo)
- Fix oddities with GCC 5.3.0 by initializing some variables
(Arnaldo Carvalho de Melo)
- With those changes in place perf now builds on Alpine Linux 3.4, in addition to
on centos (5, 6, 7), debian (7, 8, experimental), fedora (21, 22, 23, 24, rawhide),
mageia 5, opensuse (13.2, 42.1) and ubuntu (12.04.5, 14.04.4, 15.10, 16.04) and
will be test build on those systems prior to future pull requests.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Florian Fainelli says:
====================
net: ethoc: Error path and transmit fixes
This patch series contains two patches for the ethoc driver while testing on a
TS-7300 board where ethoc is provided by an on-board FPGA.
First patch was cooked after chasing crashes with invalid resources passed to
the driver.
Second patch was cooked after seeing that an interface configured with IP
192.168.2.2 was sending ARP packets for 192.168.0.0, no wonder why it could not
work.
I don't have access to any other platform using an ethoc interface so
it could be good to some testing on Xtensa for instance.
Changes in v3:
- corrected the error path if skb_put_padto() fails, thanks to Max
for spotting this!
Changes in v2:
- fixed the first commit message
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Even though the hardware can be doing zero padding, we want the SKB to
be going out on the wire with the appropriate size. This fixes packet
truncations observed with e.g: ARP packets.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case any operation fails before we can successfully go the point
where we would register a MDIO bus, we would be going to an error label
which involves unregistering then freeing this yet to be created MDIO
bus. Update all error paths to go to label free which is the only one
valid until either the clock is enabled, or the MDIO bus is allocated
and registered. This fixes kernel oops observed while trying to
dereference the MDIO bus structure which is not yet allocated.
Fixes: a170285772 ("net: Add support for the OpenCores 10/100 Mbps Ethernet MAC.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix a recent regression in the ACPI EC driver introduced by a fix
of another problem that uncovered a latent code ordering issue in
the driver (Lv Zheng).
- Revert a recent ACPICA commit that attempted to address a lock
ordering issue introduced by a previous fix, but caused Dell
Precision 5510 to fail to boot, revert that previous fix too and
finally revert the commit that caused the original problem (a
deadlock in the ACPICA code) to happen (Rafael Wysocki).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJXhVOqAAoJEILEb/54YlRxWXsP/2W3HYWabMnCWVobJYyxP0TO
mCmyZZmPpGqzPi9HV9VLTcKPZrhrLzFwk3LnDkxWWH6aEfDz5gTjrME4DNJdhTsu
SqNXf77bDdCYX6lgbdvB/ZsZkStV8b5k8gldXaBJHs7MNi33+/xepqXgoUcawB0n
H/M5udwiDMQyh8m78pkOksuicD+phO+QfdpxTW/qvmFfu7IlqeFlTCepYUyEXu5l
XwNoaptrWfsEDprg04z4jeB+xta92eUQ+BUzqpQcGAfmXYVUm7XPjhE0wepqgtta
sfxkdtM66uNZw/r3XbErVPwM/8Fl7Rywdi8qIR5KaQol+icgM62e+WWL1+XMiIiw
IZSk7XYF7QQVgwMSzPXhBd6HOzYgAgYH5UITtWlQKyi15C1R2ULSW91g92xcjSFP
Zyb6sN2/VWbN30WVsaZJ1GEGTFUOSE/iE2/R3rnRdgmb5nh4b5d83HmAXf90uBSX
2U008aqW1mQoRQrVupk/j4Lf6YKZjAGlwb0pmfguI6YROzgCcuaopTEI69bUpgfj
4LfbNi/b6tOtNrCAsJSvS8A+vYmRuqk5HpJNuECefJbJgSy2xCBWBFT9Il50o/6V
zl6IOE6WS/Rz77l0tAkzsiQhq4vYWTbQsrtQp7op98R1XHioLABp4fA00kkQpzbw
SQcHzGFA7sMoWOcuKDbi
=hkH2
-----END PGP SIGNATURE-----
Merge tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"One ACPI EC driver regression fix (code ordering) and three reverts of
ACPICA commits, one that introduced a problem and two unsuccessful
attempted fixes on top of it.
Specifics:
- Fix a recent regression in the ACPI EC driver introduced by a fix
of another problem that uncovered a latent code ordering issue in
the driver (Lv Zheng).
- Revert a recent ACPICA commit that attempted to address a lock
ordering issue introduced by a previous fix, but caused Dell
Precision 5510 to fail to boot, revert that previous fix too and
finally revert the commit that caused the original problem (a
deadlock in the ACPICA code) to happen (Rafael Wysocki)"
* tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI 2.0 / AML: Improve module level execution by moving the If/Else/While execution to per-table basis"
Revert "ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading"
Revert "ACPICA: Namespace: Fix namespace/interpreter lock ordering"
ACPI / EC: Fix code ordering issue in ec_remove_handlers()
With this change, JC-42.4 compatible temperature sensors can be configured
in devicetree by providing a generic "jedec,jc-42.4-temp" binding.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Provide generic bindings for all Jedec JC-42.4 compatible temperature
sensor chips.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
By converting the driver to regmap, we can use regmap to cache non-volatile
registers. Stop caching the temperature register; while potentially reading
it more often can result in reading it more often than necessary, this is
offset by the gain due to not re-reading the limit registers.
A positive side effect of this change is that limit registers can now be
read and updated before the first temperature conversion is complete.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
So far the chip was forced into polarity 0, even if it was preconfigured
differently. Do not touch the polarity when configuring the chip.
Also, the configuration register was read beack to check if the
configuration 'sticks'. Ultimately, that is similar to checking if the
chip is a tmp102 in the first place. Checking if a write into the
configuration register was successful is really not the way to do it,
and quite risky if the chip is not a tmp102, so drop that check.
Instead, verify if the configuration register has unexpected bits set
before writing into it.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the chip was in shutdown mode when the driver was loaded, the first
conversion is ready no more than 35 milli-seconds after the chip was
taken out of shutdown. The driver delay was so far set to 333 ms (HZ / 3),
which is much higher than the maximum time needed by the chip.
Reduce the time to 35 milli-seconds.
Introduce a 'valid' flag to ensure that sensor data is actually read
even if requested less than 333 ms after the driver was loaded.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
During commit b54b8c2d6e
("net: ezchip: adapt driver to little endian architecture")
adapting to little endian architecture,
zeroing of controller was left out.
Signed-off-by: Elad Kanfi <eladkan@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a 'CPU' special field to allow the filter in trace-cmd report to
filter on the task's CPU.
By adding a special field 'CPU' (all caps) the user can now filter out
tasks based on which CPU they are on. This is useful when filtering out
(or in) a bunch of threads.
-F 'CPU == 0'
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20160712093306.5b058103@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit looks like a cleanup but in fact by causing the core to go
down some simplified code paths for noop regulators it avoids a boot
time crash for msm8974 platforms which was introduced in v4.7. It has
been in -next for a while, the issues in mainline for these platforms
weren't flagged up to me until yesterday (I think it took some time to
figure out what was going wrong).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXhQPCAAoJECTWi3JdVIfQZAQH/AqXEFh1oZywnf6daYraLUfd
7W8OXf4nLywazeVaHBaa3hCSrIT4CYiCKcxB8vDm1//nFVcsRJnlxWQxw62/A8dx
u3ovQjwM1UfTsrR68WmnR47RO71jruex+gtISFCbYvE8NQqPPDHBlA9Q6B4VTd+n
IcoS8fdUc6QD4M+yveUcsLcppROpCm7/sba49v2qJMWZ62h2CSpZyO7ImYwkmalt
PJvmkKF7Vl/pnpiWMpGByMvz5o4jDNtaZjVr9wFF3T7otlC62sLi16AnIo+zmWam
+T9nI+ltZPtV/C46nfXyAPEqtmPyLSueVKpNgTflJPEPKUanXLWpIFZu7+MHpnI=
=nwMu
-----END PGP SIGNATURE-----
Merge tag 'qcom-smd-list-voltage' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"Fix qcom-smd list voltage issues for msm8974
This commit looks like a cleanup but in fact by causing the core to go
down some simplified code paths for noop regulators it avoids a boot
time crash for msm8974 platforms which was introduced in v4.7. It has
been in -next for a while, the issues in mainline for these platforms
weren't flagged up to me until yesterday (I think it took some time to
figure out what was going wrong)"
* tag 'qcom-smd-list-voltage' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: qcom_smd: Remove list_voltage callback for rpm_smps_ldo_ops_fixed
Adding tp_getattro callback for sample event. It resolves tracepoint
fields in runtime.
It's now possible to access tracepoint fields in normal fashion like
hardcoded ones (see the example in the next patch).
Reported-and-Tested-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-9-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To be able to find out event configuration info during sample parsing.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-8-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To get id of the tracepoint from subsystem and name strings. The
interface is:
id = perf.tracepoint(sys, name)
In case of error -1 is returned.
It will be used to get python tracepoint event's config value for
tracepoint event.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-7-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Make perf.event object parts of the perf module dictionary so we can
address them by name.
The following objects/names are added:
mmap_event
lost_event
comm_event
task_event
throttle_event
task_event
read_event
sample_event
switch_event
We can now use it in python script like:
...
event = evlist.read_on_cpu(cpu)
...
if not isinstance(event, perf.sample_event):
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-6-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We can't consume the event before parsing it. Under heavy load we could
get caught by kernel writer overwriting the event we're trying to parse.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-5-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently 0 is passed as perf_event_attr::size, which could block usage
of new features.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-4-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To get struct event_format object from tracepoint ID. It will be used
in following patches.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-3-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It will be used outside of evlist.c object in folowing patches.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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/1468148882-10362-2-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That is not present on some libelf implementations, such as the one used
in Alpine Linux: libelf-0.8.13.
This ends up disabling the SDT code, that relies on this function.
One alternative would be to provide an weak fallback implementation or
the open coded variant used by the buildid sysfs notes reading code.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-82lh22ybedy9b9lych8xj12g@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That doesn't have -I to match lines.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-7nz9hnbk7a9p91ou927ye5yh@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We've decided not to access kernel source files because changes there
could break the tooling side, this is one more step in that direction.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-ar0hupkxl45h5hk09l2rprj3@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we don't end up using the kernel one when building out of tree,
via a detached tarball.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 737ef7d32c ("tools include: Copy linux/stringify.h from the kernel")
Link: http://lkml.kernel.org/n/tip-t8yn1d7y0magk889ymc8jlai@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We use it in bitops/__ffs.h and bitops/atomic.h, that we also got from
the kernel, but were getting it from either newer systems that carry it
in /usr/include, or from the kernel sources, that we decided not to
touch from tools/ code. Fix it.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-lwqvgbuitjmrdpjmjp6zqnyx@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This one can be safely defined to be Elf64_Nhdr, as it is in elfutils's
libelf, but not on musl libc, as both Elf64_Nhdr and Elf32_Nhdr have
the same layout.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-w8z8614l03lc8bip4ijbywbt@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
