aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2015-01-25net: llc: use correct size for sysctl timeout entriesSasha Levin1-4/+4
The timeout entries are sizeof(int) rather than sizeof(long), which means that when they were getting read we'd also leak kernel memory to userspace along with the timeout values. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-25netxen: fix netxen_nic_poll() logicEric Dumazet1-1/+4
NAPI poll logic now enforces that a poller returns exactly the budget when it wants to be called again. If a driver limits TX completion, it has to return budget as well when the limit is hit, not the number of received packets. Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: d75b1ade567f ("net: less interrupt masking in NAPI") Cc: Manish Chopra <manish.chopra@qlogic.com> Acked-by: Manish Chopra <manish.chopra@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-24enic: fix rx napi poll return valueGovindarajulu Varadarajan1-1/+1
With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi repoll is done only when work_done == budget. When we are in busy_poll we return 0 in napi_poll. We should return budget. Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-24ARM: dts: imx6sx: correct i.MX6sx sdb board enet phy addressNimrod Andy1-4/+4
The commit (3d125f9c91c5) cause i.MX6SX sdb enet cannot work. The cause is the commit add mdio node with un-correct phy address. The patch just correct i.MX6sx sdb board enet phy address. V2: * As Shawn's suggestion that unit-address should match 'reg' property, so update ethernet-phy unit-address. Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Fugang Duan <B38611@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-23amd-xgbe: Use proper Rx flow control registerLendacky, Thomas2-6/+7
Updated hardware documention shows the Rx flow control settings were moved from the Rx queue operation mode register to a new Rx queue flow control register. The old flow control settings are now reserved areas of the Rx queue operation mode register. Update the code to use the new register. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19s2io: use snprintf() as a safety featureDan Carpenter1-3/+8
"sp->desc[i]" has 25 characters. "dev->name" has 15 characters. If we used all 15 characters then the sprintf() would overflow. I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as well, even though it can't overflow just to be consistent. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19r8152: remove sram_readhayeswang1-18/+6
Read OCP register 0xa43a~0xa43b would clear some flags which the hw would use, and it may let the device lost. However, the unit of reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling sram_read() to read OCP_SRAM_DATA. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19r8152: remove generic_ocp_read before writinghayeswang1-6/+0
For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read() which is used to read the whole 4 byte data, keep the unchanged bytes, and modify the expected bytes. However, the "byen" could be used to determine which bytes of the 4 bytes to write, so the action could be removed. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19bgmac: activate irqs only if there is nothing to pollHauke Mehrtens1-3/+3
IRQs should only get activated when there is nothing to poll in the queue any more and to after every poll. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19bgmac: register napi before the deviceHauke Mehrtens1-3/+3
napi should get registered before the netdev and not after. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19sh_eth: Fix ethtool operation crash when net device is downBen Hutchings1-0/+10
The driver connects and disconnects the PHY device whenever the net device is brought up and down. The ethtool get_settings, set_settings and nway_reset operations will dereference a null or dangling pointer if called while it is down. I think it would be preferable to keep the PHY connected, but there may be good reasons not to. As an immediate fix for this bug: - Set the phydev pointer to NULL after disconnecting the PHY - Change those three operations to return -ENODEV while the PHY is not connected Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19sh_eth: Fix promiscuous mode on chips without TSUBen Hutchings1-9/+9
Currently net_device_ops::set_rx_mode is only implemented for chips with a TSU (multiple address table). However we do need to turn the PRM (promiscuous) flag on and off for other chips. - Remove the unlikely() from the TSU functions that we may safely call for chips without a TSU - Make setting of the MCT flag conditional on the tsu capability flag - Rename sh_eth_set_multicast_list() to sh_eth_set_rx_mode() and plumb it into both net_device_ops structures - Remove the previously-unreachable branch in sh_eth_rx_mode() that would otherwise reset the flags to defaults for non-TSU chips Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19ipv6: stop sending PTB packets for MTU < 1280Hagen Paul Pfeifer1-5/+2
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments. See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused. [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00 Signed-off-by: Fernando Gont <fgont@si6networks.com> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-19ath9k: fix race condition in irq processing during hardware resetFelix Fietkau1-4/+3
To fix invalid hardware accesses, the commit 872b5d814f99 ("ath9k: do not access hardware on IRQs during reset") made the irq handler ignore interrupts emitted after queueing a hardware reset (which disables the IRQ). This left a small time window for the IRQ to get re-enabled by the tasklet, which caused IRQ storms. Instead of returning IRQ_NONE when ATH_OP_HW_RESET is set, disable the IRQ entirely for the duration of the reset. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-01-19pinctrl: MAINTAINERS: add git tree referenceLinus Walleij1-0/+1
Reference my pinctrl GIT tree @kernel.org Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-19pinctrl: qcom: Don't iterate past end of function arrayStephen Boyd1-2/+2
Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by: Timur Tabi <timur@codeaurora.org> Cc: Pramod Gurav <pramod.gurav@smartplayin.com> Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Ivan T. Ivanov <iivanov@mm-sol.com> Cc: Andy Gross <agross@codeaurora.org> Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-18iwlwifi: mvm: abort scheduled scan upon RFKILLEmmanuel Grumbach1-0/+7
When we have an active scheduled scan, and the RFKILL interrupt kicks in, the stack will cancel the scheduled scan as part of the down flow. But cancelling scheduled scan usually implies sending a command to the firwmare which has been killed as part of the RFKILL interrupt handling. Because of that, we returned an error to mac80211 when it asked to stop the scheduled scan and didn't notify the end of the scheduled scan. Besides a fat warning, this led to a situation in which cfg80211 would refuse any new scan request. To disentangle this, fake that the scheduled scan has been stopped without sending the command to the firwmare, return 0 after having properly let cfg80211 know that the scan has been cancelled. This is basically the same as: commit 9b520d84957d63348e87c0f2cbd21d86e1e8f2f2 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Tue Nov 4 15:54:11 2014 +0200 iwlwifi: mvm: abort scan upon RFKILL This code existed but not for all the different FW APIs we support. Fix this. but for the scheduled scan case. Link: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/133232 Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2015-01-18Linux 3.19-rc5Linus Torvalds1-1/+1
2015-01-17net: sctp: fix race for one-to-many sockets in sendmsg's auto associateDaniel Borkmann1-1/+7
I.e. one-to-many sockets in SCTP are not required to explicitly call into connect(2) or sctp_connectx(2) prior to data exchange. Instead, they can directly invoke sendmsg(2) and the SCTP stack will automatically trigger connection establishment through 4WHS via sctp_primitive_ASSOCIATE(). However, this in its current implementation is racy: INIT is being sent out immediately (as it cannot be bundled anyway) and the rest of the DATA chunks are queued up for later xmit when connection is established, meaning sendmsg(2) will return successfully. This behaviour can result in an undesired side-effect that the kernel made the application think the data has already been transmitted, although none of it has actually left the machine, worst case even after close(2)'ing the socket. Instead, when the association from client side has been shut down e.g. first gracefully through SCTP_EOF and then close(2), the client could afterwards still receive the server's INIT_ACK due to a connection with higher latency. This INIT_ACK is then considered out of the blue and hence responded with ABORT as there was no alive assoc found anymore. This can be easily reproduced f.e. with sctp_test application from lksctp. One way to fix this race is to wait for the handshake to actually complete. The fix defers waiting after sctp_primitive_ASSOCIATE() and sctp_primitive_SEND() succeeded, so that DATA chunks cooked up from sctp_sendmsg() have already been placed into the output queue through the side-effect interpreter, and therefore can then be bundeled together with COOKIE_ECHO control chunks. strace from example application (shortened): socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF close(3) = 0 tcpdump before patch (fooling the application): 22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684] 22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591] 22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT] tcpdump after patch: 14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729] 14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492] 14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...] 14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0] 14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...] 14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] 14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...] 14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0] 14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN] 14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK] 14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE] Looks like this bug is from the pre-git history museum. ;) Fixes: 08707d5482df ("lksctp-2_5_31-0_5_1.patch") Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-17clk: fix possible null pointer dereferenceStanimir Varbanov1-1/+1
The commit 646cafc6 (clk: Change clk_ops->determine_rate to return a clk_hw as the best parent) opens a possibility for null pointer dereference, fix this. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-17Revert "clk: ppc-corenet: Fix Section mismatch warning"Kevin Hao1-1/+1
This reverts commit da788acb28386aa896224e784954bb73c99ff26c. That commit tried to fix the section mismatch warning by moving the ppc_corenet_clk_driver struct to init section. This is definitely wrong because the kernel would free the memories occupied by this struct after boot while this driver is still registered in the driver core. The kernel would panic when accessing this driver struct. Cc: stable@vger.kernel.org # 3.17 Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-17clk: rockchip: fix deadlock possibility in cpuclkHeiko Stübner1-4/+6
Lockdep reported a possible deadlock between the cpuclk lock and for example the i2c driver. CPU0 CPU1 ---- ---- lock(clk_lock); local_irq_disable(); lock(&(&i2c->lock)->rlock); lock(clk_lock); <Interrupt> lock(&(&i2c->lock)->rlock); *** DEADLOCK *** The generic clock-types of the core ccf already use spin_lock_irqsave when touching clock registers, so do the same for the cpuclk. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> [mturquette@linaro.org: removed initialization of "flags"]
2015-01-16reset: sunxi: fix spinlock initializationTyler Baker1-0/+4
Call spin_lock_init() before the spinlocks are used, both in early init and probe functions preventing a lockdep splat. I have been observing lockdep complaining [1] during boot on my a80 optimus [2] when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat, and has been tested on a few other sunxi platforms without issue. [1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html [2] http://kernelci.org/boot/?a80-optimus Signed-off-by: Tyler Baker <tyler.baker@linaro.org> Cc: <stable@vger.kernel.org> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-16ARM: dts: disable CCI on exynos5420 based arndale-octaAbhilash Kesavan2-1/+5
The arndale-octa board was giving "imprecise external aborts" during boot-up with MCPM enabled. CCI enablement of the boot cluster was found to be the cause of these aborts (possibly because the secure f/w was not allowing it). Hence, disable CCI for the arndale-octa board. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Kevin Hilman <khilman@linaro.org> Tested-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-16drivers: bus: check cci device tree node statusAbhilash Kesavan1-0/+3
The arm-cci driver completes the probe sequence even if the cci node is marked as disabled. Add a check in the driver to honour the cci status in the device tree. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-16ARM: rockchip: disable jtag/sdmmc autoswitching on rk3288Heiko Stübner1-0/+27
rk3288 SoCs have a function to automatically switch between jtag/sdmmc pinmux settings depending on the card state. This collides with a lot of assumptions. It only works when using the internal card-detect mechanism and breaks horribly when using either the normal card-detect via the slot-gpio function or via any other pin. Also there is of course no link between the mmc and jtag on the software-side, so the jtag clocks may very well be disabled when the card is ejected and the soc switches back to the jtag pinmux. Leaving the switching function enabled did result in mmc timeouts and rcu stalls thus hanging the system on 3.19-rc1. Therefore disable it in all cases, as we expect the devicetree to explicitly select either mmc or jtag pinmuxes anyway. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-16ARM: nomadik: fix up leftover device tree pinsLinus Walleij1-4/+4
We altered the device tree bindings for the Nomadik family of pin controllers to be standard, this file was merged out-of-order so we missed fixing this. Fix it up. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-16genetlink: synchronize socket closing and family removalJohannes Berg5-15/+35
In addition to the problem Jeff Layton reported, I looked at the code and reproduced the same warning by subscribing and removing the genl family with a socket still open. This is a fairly tricky race which originates in the fact that generic netlink allows the family to go away while sockets are still open - unlike regular netlink which has a module refcount for every open socket so in general this cannot be triggered. Trying to resolve this issue by the obvious locking isn't possible as it will result in deadlocks between unregistration and group unbind notification (which incidentally lockdep doesn't find due to the home grown locking in the netlink table.) To really resolve this, introduce a "closing socket" reference counter (for generic netlink only, as it's the only affected family) in the core netlink code and use that in generic netlink to wait for all the sockets that are being closed at the same time as a generic netlink family is removed. This fixes the race that when a socket is closed, it will should call the unbind, but if the family is removed at the same time the unbind will not find it, leading to the warning. The real problem though is that in this case the unbind could actually find a new family that is registered to have a multicast group with the same ID, and call its mcast_unbind() leading to confusing. Also remove the warning since it would still trigger, but is now no longer a problem. This also moves the code in af_netlink.c to before unreferencing the module to avoid having the same problem in the normal non-genl case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16genetlink: disallow subscribing to unknown mcast groupsJohannes Berg1-1/+1
Jeff Layton reported that he could trigger the multicast unbind warning in generic netlink using trinity. I originally thought it was a race condition between unregistering the generic netlink family and closing the socket, but there's a far simpler explanation: genetlink currently allows subscribing to groups that don't (yet) exist, and the warning is triggered when unsubscribing again while the group still doesn't exist. Originally, I had a warning in the subscribe case and accepted it out of userspace API concerns, but the warning was of course wrong and removed later. However, I now think that allowing userspace to subscribe to groups that don't exist is wrong and could possibly become a security problem: Consider a (new) genetlink family implementing a permission check in the mcast_bind() function similar to the like the audit code does today; it would be possible to bypass the permission check by guessing the ID and subscribing to the group it exists. This is only possible in case a family like that would be dynamically loaded, but it doesn't seem like a huge stretch, for example wireless may be loaded when you plug in a USB device. To avoid this reject such subscription attempts. If this ends up causing userspace issues we may need to add a workaround in af_netlink to deny such requests but not return an error. Reported-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16genetlink: document parallel_opsJohannes Berg1-0/+2
The kernel-doc for the parallel_ops family struct member is missing, add it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-17kernel: avoid overflow in cmp_rangeLouis Langholtz1-5/+5
Avoid overflow possibility. [ The overflow is purely theoretical, since this is used for memory ranges that aren't even close to using the full 64 bits, but this is the right thing to do regardless. - Linus ] Signed-off-by: Louis Langholtz <lou_langholtz@me.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Peter Anvin <hpa@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-01-16perf tools powerpc: Use dwfl_report_elf() instead of offline.Sukadev Bhattiprolu1-8/+11
dwfl_report_offline() works only when libraries are prelinked. Replace dwfl_report_offline() with dwfl_report_elf() so we correctly extract debug info even from libraries that are not prelinked. Reported-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Jiri Olsa <jolsa@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Link: http://lkml.kernel.org/r/20150114221045.GA17703@us.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf tools: Fix segfault for symbol annotation on TUINamhyung Kim1-7/+1
Currently the symbol structure is allocated with symbol_conf.priv_size to carry sideband information like annotation, map browser on TUI and sort-by-name tree node. So retrieving these information from symbol needs to care about the details of such placement. However the annotation code just assumes that the symbol is placed after the struct annotation. But actually there's other info between them. So accessing those struct will lead to an undefined behavior (usually a crash) after they write their info to the same location. To reproduce the problem, please follow the steps below: 1. run perf report (TUI of course) with -v option 2. open map browser (by pressing right arrow key for any entry) 3. search any function (by pressing '/' key and input whatever..) 4. return to the hist browser (by pressing 'q' or left arrow key) 5. open annotation window for the same entry (by pressing 'a' key) Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf test: Fix dwarf unwind using libunwind.Wang Nan2-3/+61
Perf tool fails to unwind user stack if the event raises in a shared object. This patch improves tests/dwarf-unwind.c to demonstrate the problem by utilizing commonly used glibc function "bsearch". If perf is not statically linked, the testcase will try to unwind a mixed call trace. By debugging libunwind I found that there is a bug in unwind-libunwind: it always passes 0 as segbase to libunwind, cause libunwind unable to locate debug_frame entry fir first level ip address (I add some more debugging output into libunwind to make things clear): >_Uarm_dwarf_find_debug_frame: start_ip = 10be98, end_ip = 10c2a4 >_Uarm_dwarf_find_debug_frame: found debug_frame table `/lib/libc-2.18.so': segbase=0x0, len=7, gp=0x0, table_data=0x449388 >_Uarm_dwarf_search_unwind_table: call lookup:ip = b6cd3bcc, segbase = 0, rel_ip = b6cd3bcc >lookup: e->start_ip_offset = bcf18 (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 6d314 (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 33d0c (rel_ip = b6cd3bcc) ... >lookup: e->start_ip_offset = 15d0c (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 15c40 (rel_ip = b6cd3bcc) >_Uarm_dwarf_search_unwind_table: IP b6cd3bcc inside range b6c12000-b6d4c000, but no explicit unwind info found >put_rs_cache: unmasking signals/interrupts and releasing lock >_Uarm_dwarf_step: returning -10 >_Uarm_step: dwarf_step()=-10 This patch passes map->start as segbase to dwarf_find_debug_frame(), so di will be initialized correctly. In addition, dso and executable are different when setting segbase. This patch first check whether the elf is executable, and pass segbase only for shared object. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Li Zefan <lizefan@huawei.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> 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/1421203007-75799-1-git-send-email-wangnan0@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf tools: Avoid build splat for syscall numbers with uclibcVineet Gupta3-3/+1
This is due to duplicated unistd inclusion (via uClibc headers + kernel headers) Also seen on ARM uClibc based tools ------- ARC build ---------->8------------- CC util/evlist.o In file included from ~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0, from util/../perf-sys.h:10, from util/../perf.h:15, from util/event.h:7, from util/event.c:3: ~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0: warning: "__NR_fcntl64" redefined [enabled by default] #define __NR_fcntl64 __NR3264_fcntl ^ In file included from ~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0, from util/../perf-sys.h:6, ----------------->8------------------- ------- ARM build ---------->8------------- CC FPIC plugin_scsi.o In file included from util/../perf-sys.h:9:0, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0: warning: "__NR_restart_syscall" redefined [enabled by default] In file included from ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0, from util/../perf-sys.h:6, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0: note: this is the location of the previous definition ----------------->8------------------- Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf tools: Elide strlcpy warning with uclibcVineet Gupta1-0/+2
----------------->8------------------ CC bench/sched-pipe.o In file included from builtin-annotate.c:13:0: util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy' [-Wredundant-decls] extern size_t strlcpy(char *dest, const char *src, size_t size); ^ In file included from util/util.h:55:0, from builtin.h:4, from builtin-annotate.c:8: ~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15: note: previous declaration of 'strlcpy' was here extern size_t strlcpy(char *__restrict dst, const char *__restrict src, ----------------->8------------------ Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf tools: Fix statfs.f_type data type mismatch build error with uclibcAlexey Brodkin2-2/+2
ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers statfs defines f_type to be U32 which causes perf build breakage http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h ----------->8--------------- CC fs/fs.o fs/fs.c: In function 'fs__valid_mount': fs/fs.c:82:24: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] else if (st_fs.f_type != magic) ^ cc1: all warnings being treated as errors ----------->8--------------- Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Cody P Schafer <dev@codyps.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com> Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16tools: Remove bitops/hweight usage of bits in tools/perfArnaldo Carvalho de Melo10-42/+30
We need to use lib/hweight.c for that, just like we do for lib/rbtree.c, so tools need to link hweight.o. For now do it directly, but we need to have a tools/lib/lk.a or .so that collects these goodies... Reported-by: Jan Beulich <JBeulich@suse.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-a1e91dx3apzqw5kbdt7ut21s@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf machine: Fix __machine__findnew_thread() error pathNamhyung Kim1-1/+3
When thread__init_map_groups() fails, a new thread should be removed from the rbtree since it's gonna be freed. Also update last match cache only if the function succeeded. Reported-by: David Ahern <dsahern@gmail.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf tools: Fix building error in x86_64 when dwarf unwind is onNamhyung Kim3-15/+17
When build with 'make ARCH=x86' and dwarf unwind is on, there is a compiling error: CC /home/wn/perf/arch/x86/util/unwind-libdw.o CC /home/wn/perf/arch/x86/tests/regs_load.o arch/x86/tests/regs_load.S: Assembler messages: arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push' arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop' make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1 make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24! make: *** [all] Error 2 ... Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT. 'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'. However, when building x86_64 kernel, ARCH=x86 is valid and commonly used. Build systems, such as yocto, uses x86_64 compiler with 'ARCH=x86' to build x86_64 perf, which causes mismatching. As __LP64__ is defined for x86_64 as well, we can consolidate the __x86_64__ check to the __LP64__ check and get rid of the IS_X86_64 IMHO. (This patch is made by Namhyung Kim when replying my v1 patch: https://lkml.org/lkml/2015/1/7/17 I modified the code to remove dependency on RAW_ARCH: https://lkml.org/lkml/2015/1/7/865 Namhyung Kim didn't provide his SOB in his original email. I add mine only for my modification.) Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/1421029255-23039-1-git-send-email-wangnan0@huawei.com [ Namhyung provided his S-o-B on a followup to this patch thread on lkml ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16perf probe: Propagate error code when write(2) failedNamhyung Kim1-1/+3
When it failed to write probe commands to the probe_event file in debugfs, it needs to propagate the error code properly. Current code blindly uses the return value of the write(2) so it always uses -1 (-EPERM) and it might confuse users. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1420886028-15135-4-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-01-16arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned"Catalin Marinas1-7/+1
This patch partially reverts commit 421520ba98290a73b35b7644e877a48f18e06004 (only the arm64 part). There is no guarantee that the boot-loader places other images like dtb in a different page than initrd start/end, especially when the kernel is built with 64KB pages. When this happens, such pages must not be freed. The free_reserved_area() already takes care of rounding up "start" and rounding down "end" to avoid freeing partially used pages. Cc: <stable@vger.kernel.org> # 3.17+ Reported-by: Peter Maydell <Peter.Maydell@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-01-16perf/x86/intel: Fix bug for "cycles:p" and "cycles:pp" on SLMKan Liang1-2/+2
cycles:p and cycles:pp do not work on SLM since commit: 86a04461a99f ("perf/x86: Revamp PEBS event selection") UOPS_RETIRED.ALL is not a PEBS capable event, so it should not be used to count cycle number. Actually SLM calls intel_pebs_aliases_core2() which uses INST_RETIRED.ANY_P to count the number of cycles. It's a PEBS capable event. But inv and cmask must be set to count cycles. Considering SLM allows all events as PEBS with no flags, only INST_RETIRED.ANY_P, inv=1, cmask=16 needs to handled specially. Signed-off-by: Kan Liang <kan.liang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421084541-31639-1-git-send-email-kan.liang@intel.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-16perf/rapl: Fix sysfs_show() initialization for RAPL PMUStephane Eranian1-12/+32
This patch fixes a problem with the initialization of the sysfs_show() routine for the RAPL PMU. The current code was wrongly relying on the EVENT_ATTR_STR() macro which uses the events_sysfs_show() function in the x86 PMU code. That function itself was relying on the x86_pmu data structure. Yet RAPL and the core PMU (x86_pmu) have nothing to do with each other. They should therefore not interact with each other. The x86_pmu structure is initialized at boot time based on the host CPU model. When the host CPU is not supported, the x86_pmu remains uninitialized and some of the callbacks it contains are NULL. The false dependency with x86_pmu could potentially cause crashes in case the x86_pmu is not initialized while the RAPL PMU is. This may, for instance, be the case in virtualized environments. This patch fixes the problem by using a private sysfs_show() routine for exporting the RAPL PMU events. Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/20150113225953.GA21525@thinkpad Cc: vincent.weaver@maine.edu Cc: jolsa@redhat.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-16net: rps: fix cpu unplugEric Dumazet1-5/+15
softnet_data.input_pkt_queue is protected by a spinlock that we must hold when transferring packets from victim queue to an active one. This is because other cpus could still be trying to enqueue packets into victim queue. A second problem is that when we transfert the NAPI poll_list from victim to current cpu, we absolutely need to special case the percpu backlog, because we do not want to add complex locking to protect process_queue : Only owner cpu is allowed to manipulate it, unless cpu is offline. Based on initial patch from Prasad Sodagudi & Subash Abhinov Kasiviswanathan. This version is better because we do not slow down packet processing, only make migration safer. Reported-by: Prasad Sodagudi <psodagud@codeaurora.org> Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16net: davinci_emac: Add support for emac on dm816xTony Lindgren2-1/+7
On dm816x we have two emac controllers with separate memory areas. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address spaceTony Lindgren1-3/+12
Some devices like dm816x have the MDIO registers within the first EMAC instance address space. Let's fix the issue by allowing to pass an optional second IO range for the EMAC control register area. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16net: davinci_emac: Fix incomplete code for getting the phy from device treeTony Lindgren1-5/+18
Looks like the phy_id is never set up beyond getting the phandle. Note that we can remove the ifdef for phy_node as there is a stub for of_phy_connec() if CONFIG_OF is not set. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16net: davinci_emac: Free clock after checking the frequencyTony Lindgren1-0/+1
We only use clk_get() to get the frequency, the rest is done by the runtime PM calls. Let's free the clock too. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-16net: davinci_emac: Fix runtime pm calls for davinci_emacTony Lindgren1-4/+29
Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support") added support for runtime PM, but it causes issues on omap3 related devices that actually gate the clocks: Unhandled fault: external abort on non-linefetch (0x1008) ... [<c04160f0>] (emac_dev_getnetstats) from [<c04d6a3c>] (dev_get_stats+0x78/0xc8) [<c04d6a3c>] (dev_get_stats) from [<c04e9ccc>] (rtnl_fill_ifinfo+0x3b8/0x938) [<c04e9ccc>] (rtnl_fill_ifinfo) from [<c04eade4>] (rtmsg_ifinfo+0x68/0xd8) [<c04eade4>] (rtmsg_ifinfo) from [<c04dd35c>] (register_netdevice+0x3a0/0x4ec) [<c04dd35c>] (register_netdevice) from [<c04dd4bc>] (register_netdev+0x14/0x24) [<c04dd4bc>] (register_netdev) from [<c041755c>] (davinci_emac_probe+0x408/0x5c8) [<c041755c>] (davinci_emac_probe) from [<c0396d78>] (platform_drv_probe+0x48/0xa4) Let's fix it by moving the pm_runtime_get() call earlier, and also add it to the emac_dev_getnetstats(). Also note that we want to use pm_runtime_get_sync() as we don't want to have deferred_resume happen. And let's also check the return value for pm_runtime_get_sync() as noted by Felipe Balbi <balbi@ti.com>. Cc: Brian Hutchinson <b.hutchman@gmail.com> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.