Mr Kabore Isa.
Greetings Dear Friend. I am Mr Kabore Isa, Staff of Bank Of Africa in Burkina Faso. I would like you to indicate your interest to receive the transfer of ($20.5 Million Dollars) I will like you to stand as the next of kin to my late client whose account is presently dormant for claims. if you are interested, indicate and I will intimate you with the method of application and how you can apply to the bank. This fund was deposited in the bank here by a foreign customer who died accidentally alongside with his entire family members many years ago. Nobody had asked for this fund till now. If you are interested, you have to provide an account where the fund will be remitted because i am highly interested to secure this money from the Bank. Please you can contact me immediately to start the transfer process. Further details about the fund and this transaction will be given to you upon the receipt of your response. Please understand that we have to hurry-up our actions because the bank authority here has plans to redeposit this fund into the treasury of the Central Government as unclaimed fund if nobodyapplies for this fund after the next bank audit which will begin here soon. Please do contact me with your information your Address, telephone and fax number, photograph,occupation,Age,Nationality, Sex. I await your urgent reply. Best Regards Mr Kabore Isa. -- 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] mmc: sdhci-acpi: detect sd card reader on asus x205ta
Add an entry to the sdhci_acpi_uids list to detect the SD card
reader on the Asus X205Ta laptop.
dstd table:
Device (SDHC)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "PNP0FFF") // _HID: Hardware ID
Name (_CID, "PNP0D40" /* SDA Standard Compliant SD Host Controller */)
Name (_DDN, "Intel(R) SD Card Controller - 80860F16") // _DDN: DOS Dev
Name (_UID, 0x03) // _UID: Unique ID
Name (RDEP, Package (0x02)
Signed-off-by: Michele Curti
---
drivers/mmc/host/sdhci-acpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 22d929f..78aa16a 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -247,6 +247,7 @@ static const struct sdhci_acpi_uid_slot sdhci_acpi_uids[] =
{
{ "INT33C6" , NULL, &sdhci_acpi_slot_int_sdio },
{ "INT3436" , NULL, &sdhci_acpi_slot_int_sdio },
{ "INT344D" , NULL, &sdhci_acpi_slot_int_sdio },
+ { "PNP0FFF" , "3" , &sdhci_acpi_slot_int_sd },
{ "PNP0D40" },
{ },
};
--
2.5.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/
[RFC v1 4/4] iio: chemical: add SGX VZ89x VOC sensor support
Add support for VZ89X sensors VOC and CO2 reporting channels in
ppm/ppb units.
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/i2c/trivial-devices.txt| 1 +
drivers/iio/Kconfig| 1 +
drivers/iio/Makefile | 1 +
drivers/iio/chemical/Makefile | 6 +
drivers/iio/chemical/vz89x.c | 237 +
5 files changed, 246 insertions(+)
create mode 100644 drivers/iio/chemical/Makefile
create mode 100644 drivers/iio/chemical/vz89x.c
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index d77d412..a550216 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE
REAL-TIME CLOCK IC
ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
+sgx,vz89x SGX Sensortech VZ89X Sensors
sii,s35390a2-wire CMOS real-time clock
skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with
Touch Panel Bias Supply
st-micro,24c256i2c serial eeprom (24cxx)
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..9664e9c 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER
source "drivers/iio/accel/Kconfig"
source "drivers/iio/adc/Kconfig"
source "drivers/iio/amplifiers/Kconfig"
+source "drivers/iio/chemical/Kconfig"
source "drivers/iio/common/Kconfig"
source "drivers/iio/dac/Kconfig"
source "drivers/iio/frequency/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..2288684 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
obj-y += accel/
obj-y += adc/
obj-y += amplifiers/
+obj-y += chemical/
obj-y += common/
obj-y += dac/
obj-y += gyro/
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
new file mode 100644
index 000..7292f2d
--- /dev/null
+++ b/drivers/iio/chemical/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO chemical sensors
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c
new file mode 100644
index 000..a596a22
--- /dev/null
+++ b/drivers/iio/chemical/vz89x.c
@@ -0,0 +1,237 @@
+/*
+ * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors
+ *
+ * Copyright (C) 2015 Matt Ranostay
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define VZ89X_REG_MEASUREMENT 0x09
+#define VZ89X_REG_MEASUREMENT_SIZE 6
+
+#define VZ89X_VOC_CO2_IDX 0
+#define VZ89X_VOC_SHORT_IDX1
+#define VZ89X_VOC_TVOC_IDX 2
+#define VZ89X_RESISTANCE_IDX 3
+
+struct vz89x_data {
+ struct i2c_client *client;
+ struct mutex lock;
+ unsigned long last_update;
+
+ u8 buffer[VZ89X_REG_MEASUREMENT_SIZE];
+};
+
+static const struct iio_chan_spec vz89x_channels[] = {
+ {
+ .type = IIO_CONCENTRATION,
+ .channel2 = IIO_MOD_PPM,
+ .modified = 1,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_OFFSET) |
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .address = VZ89X_VOC_CO2_IDX,
+ .extend_name = "CO2",
+ },
+ {
+ .type = IIO_CONCENTRATION,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .address = VZ89X_VOC_SHORT_IDX,
+ .extend_name = "VOC_short",
+ },
+ {
+ .type = IIO_CONCENTRATION,
+ .channel2 = IIO_MOD_PPB,
+ .modified = 1,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .address = VZ89X_VOC_TVOC_IDX,
+ .extend_name = "tVOC",
+ },
+ {
+ .type = IIO_RESISTANCE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_C
[RFC v1 3/4] devicetree: add SGX Sensortech vendor id
Signed-off-by: Matt Ranostay --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c3..281e8f0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -191,6 +191,7 @@ sbs Smart Battery System schindler Schindler seagateSeagate Technology PLC semtechSemtech Corporation +sgxSGX Sensortech sharp Sharp Corporation silSilicon Image silabs Silicon Laboratories -- 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/
[RFC v1 2/4] iio: resistance: add IIO_RESISTANCE channel type
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 6 ++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index a3803a1..1084659 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1469,3 +1469,9 @@ Description:
Raw (unscaled no offset etc.) concentration reading of data like
CO2 or VOC (Volatile Organic Compounds) substances with or
without
ppm (Part Per Million) or ppb (Parts Per Billion) channel
modifiers.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) resistance reading in ohms.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index ea9e31a..862c066 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -76,6 +76,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
[IIO_CONCENTRATION] = "concentration",
+ [IIO_RESISTANCE] = "resistance",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index dfb8b8c..22edd4d 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -36,6 +36,7 @@ enum iio_chan_type {
IIO_DISTANCE,
IIO_VELOCITY,
IIO_CONCENTRATION,
+ IIO_RESISTANCE,
};
enum iio_modifier {
--
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/
[RFC v1 0/4] iio: new chemical sensor framework and channel types
Initial RFC for new chemical sensor framework, IIO_CONCENTRATION, and IIO_RESISTANCE channel types. Important notes: * Not been tested on real hardware yet but that isn't the main RFC reason and once hardware is in hand it will be verified * Reason the IIO_CONCENTRATION type isn't in percent but has modifiers for ppm and ppb is the scale value for the latter would cause a integer overflow using IIO_VAL_FRACTIONAL Matt Ranostay (4): iio: chemical: Add IIO_CONCENTRATION channel type iio: resistance: add IIO_RESISTANCE channel type devicetree: add SGX Sensortech vendor id iio: chemical: add SGX VZ89x VOC sensor support Documentation/ABI/testing/sysfs-bus-iio| 16 ++ .../devicetree/bindings/i2c/trivial-devices.txt| 1 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/chemical/Makefile | 6 + drivers/iio/chemical/vz89x.c | 237 + drivers/iio/industrialio-core.c| 4 + include/uapi/linux/iio/types.h | 4 + 9 files changed, 271 insertions(+) create mode 100644 drivers/iio/chemical/Makefile create mode 100644 drivers/iio/chemical/vz89x.c -- 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/
[RFC v1 1/4] iio: chemical: Add IIO_CONCENTRATION channel type
There are air quality sensors that report data back in parts per million
of VOC (Volatile Organic Compounds) which are usually indexed from CO2
or another common pollutant.
This patchset adds an IIO_CONCENTRATION type and IIO_MOD_PPM/PPB modifiers
because no other channels types fit this use case.
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 10 ++
drivers/iio/industrialio-core.c | 3 +++
include/uapi/linux/iio/types.h | 3 +++
3 files changed, 16 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..a3803a1 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1459,3 +1459,13 @@ Description:
measurements and return the average value as output data. Each
value resulted from [_name]_oversampling_ratio
measurements
is considered as one sample for
[_name]_sampling_frequency.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ppm_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ppb_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) concentration reading of data like
+ CO2 or VOC (Volatile Organic Compounds) substances with or
without
+ ppm (Part Per Million) or ppb (Parts Per Billion) channel
modifiers.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..ea9e31a 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -75,6 +75,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_ENERGY] = "energy",
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
+ [IIO_CONCENTRATION] = "concentration",
};
static const char * const iio_modifier_names[] = {
@@ -111,6 +112,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z] = "sqrt(x^2+y^2+z^2)",
[IIO_MOD_I] = "i",
[IIO_MOD_Q] = "q",
+ [IIO_MOD_PPM] = "ppm",
+ [IIO_MOD_PPB] = "ppb",
};
/* relies on pairs of these shared then separate */
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 2f8b117..dfb8b8c 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -35,6 +35,7 @@ enum iio_chan_type {
IIO_ENERGY,
IIO_DISTANCE,
IIO_VELOCITY,
+ IIO_CONCENTRATION,
};
enum iio_modifier {
@@ -72,6 +73,8 @@ enum iio_modifier {
IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z,
IIO_MOD_I,
IIO_MOD_Q,
+ IIO_MOD_PPM,
+ IIO_MOD_PPB,
};
enum iio_event_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/
Re: [PATCH] task_work: remove fifo ordering guarantee
On Sat, Sep 05, 2015 at 06:12:34AM +0100, Al Viro wrote: > First of all, we'd better not count on e.g. delayed fput() *NOT* doing > task_work_add() - we still need to check if any new work had been added. > After all, final close() might very well have done a final mntput() > on a lazy-unmounted filesystem, possibly leaving us with fs shutdown via > task_work_add(). And if that sucker e.g. closes a socket, well, we are > back to closing an opened struct file, with task_work_add() etc. > > I'm a bit nervious about filp_close() (that sucker is exported and widely > abused), but close_files()... sure, shouldn't be a problem. And yes, > we can teach __close_fd() to do the same. I really don't understand what's > the benefit, though - it's about the case when we are closing the last > descriptor for given opened file, so I would be rather surprised if slower > path taken on the way out to userland was not lost in noise... OK, having found the beginning of the thread, I understand what is being attempted, but... why the hell bother with FIFO in the first place? AFAICS, task_work_add() uses in VFS (final fput() and final mntput() alike) do not care about the FIFO at all. Sure, some out-of-tree mer^H^Hodule might rely on that. So what? IMO, unless we have a good in-tree reason for insisting on FIFO, dropping it is the most obvious solution... -- 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] task_work: remove fifo ordering guarantee
On Sat, Aug 29, 2015 at 02:49:21PM +0200, Oleg Nesterov wrote: > Let's look keyctl_session_to_parent(). It does task_work_cancel() > but only because we can not trust user-space. Otherwise we could > remove it and just do task_work_add(), but this needs fifo. > > Fifo just looks more sane to me. Not if it costs us. As far as files closing is concerned, the order really doesn't matter. Ditto for final mntput() uses of that stuff. What *does* matter is task_work_add() issued by callback not getting lost. IMO the obvious solution is to lose the reordering... -- 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] task_work: remove fifo ordering guarantee
On Mon, Aug 31, 2015 at 01:22:26PM +0800, yalin wang wrote: > why not provide API like: > fput() > fput_nosync() ? > > because synchronous version are reasonable and safe in most time, > let the user to select which version to use is more feasible, no matter if it > is kthread or not. Synchronous version is *NOT* safe in a lot of situations, from "deep enough in kernel stack" to "now a function seven levels out in call chain happens to hold a mutex grabbed elsewhere inside a mutex taken by unexpected ->release() instance, causing a deadlock", etc. It's not sync vs. async; we still guarantee execution before return from syscall. The only case when we really get async is kernel threads - there we do *not* return to userland at all, so we have to schedule it really asynchronous. Which is why we need an explicit sync version (for kernel threads only, not exported, don't use unless you really understand what you are doing and can explain why that particular case is safe, etc.) -- 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] task_work: remove fifo ordering guarantee
On Sat, Aug 29, 2015 at 10:08:30AM -0700, Linus Torvalds wrote: > Hmm. > > I'm wondering if we should just make close_files() (or maybe even > filp_close()) use a synchronous fput(). > > Iirc, the reason we delay fput() is that we had some nasty issues for > the generic fput case. It was called from interrupt context by the aio > code, and just in general there's a lot of nasty cases that can cause > the final fput to happen (so there are lockdep issues with the mmap > locks because the last fput being from munmap etc). > > Maybe I forget some detail - it's been several years by now - but I > think we could make the regular "close()" and "exit()" cases just use > the synchronous fput (it's called "__fput_sync()" and currently > explicitly limited to just kernel threads). > > Al? First of all, we'd better not count on e.g. delayed fput() *NOT* doing task_work_add() - we still need to check if any new work had been added. After all, final close() might very well have done a final mntput() on a lazy-unmounted filesystem, possibly leaving us with fs shutdown via task_work_add(). And if that sucker e.g. closes a socket, well, we are back to closing an opened struct file, with task_work_add() etc. I'm a bit nervious about filp_close() (that sucker is exported and widely abused), but close_files()... sure, shouldn't be a problem. And yes, we can teach __close_fd() to do the same. I really don't understand what's the benefit, though - it's about the case when we are closing the last descriptor for given opened file, so I would be rather surprised if slower path taken on the way out to userland was not lost in noise... -- 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 6/6] ebpf: allow BPF_REG_X in src_reg conditional jumps
On Fri, Sep 04, 2015 at 04:43:50PM -0600, Tycho Andersen wrote:
> > The fix should be something like this:
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 13079f03902e..05a04ea87172 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -478,9 +478,9 @@ do_pass:
> > bpf_src = BPF_X;
> > } else {
> > insn->dst_reg = BPF_REG_A;
> > - insn->src_reg = BPF_REG_X;
> > insn->imm = fp->k;
> > bpf_src = BPF_SRC(fp->code);
> > + insn->src_reg = bpf_src == BPF_X ?
> > BPF_REG_X : 0;
> > }
>
> Yep, I just tested this and it works for me. Do you want to manage it
> or should I carry it as part of this set?
Though it's a bug, it doesn't affect anything at the moment
and not worth fixing in net, so please submit it as separate bug
fix when net-next reopens. imo the rest of the patches should
also go via net-next to minimize cross-tree conflicts.
--
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 v1 1/2] soc: ti: display firmware file name as part of boot log
On 9/4/15 5:46 PM, Murali Karicheri wrote: To help the user, print the PDSP file name as part of knav_queue_load_pdsp(). This will be useful for users to know what version of the firmware is loaded to PDSP. Also update the document for the location of the QMSS accumulator PDSP firmware. Signed-off-by: Murali Karicheri --- Looks fine. Will pick both the patches. Regards, Santosh -- 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] MIPS: UAPI: Fix unrecognized opcode WSBH/DSBH/DSHD when using MIPS16.
On 5 September 2015 at 11:29, Yousong Zhou wrote:
> #include
> #include
>
#include was missed out at the top.
yousong
> uint16_t __attribute__((noinline)) f(uint16_t v)
> {
> v = __cpu_to_le16(v);
> return v;
> }
>
> int main()
> {
> printf("%x\n", f(0xbeef));
>
> return 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] MIPS: UAPI: Fix unrecognized opcode WSBH/DSBH/DSHD when using MIPS16.
On 5 September 2015 at 02:52, Maciej W. Rozycki wrote:
> On Thu, 3 Sep 2015, Yousong Zhou wrote:
>
>> The nomips16 has to be added both as function attribute and assembler
>> directive.
>>
>> When only function attribute is specified, the compiler will inline the
>> function with -Os optimization. The generated assembly code cannot be
>> correctly assembled because ISA mode switch has to be done through jump
>> instruction.
>
> This can't be true. The compiler does not intepret the contents of an
> inline asm and therefore cannot decide whether to inline a function
> containing one or not based on the lone presence or the absence of an
> assembly directive within.
>
Most of the time I trust my compiler and never meddle with the
toolchain. Anyway I made a patch because it really did not work for
me. No big deal. It's not the end of world. It started with a
comment from OpenWrt packages feeds [1]. Actually this "unrecognized
opcode" problem have occurred within OpenWrt quite a few times before.
[1]
https://github.com/openwrt/packages/commit/1e29676a8ac74f797f8ca799364681cec575ae6f#commitcomment-12901931
>> When only ".set nomips16" directive is used, the generated assembly code
>> will use MIPS32 code for the inline assembly template and MIPS16 for the
>> function return. The compiled binary is invalid:
>>
>> 00403100 <__arch_swab16>:
>> 403100: 7c0410a0wsbhv0,a0
>> 403104: e820ea31swc2$0,-5583(at)
>>
>> while correct code should be:
>>
>> 00402650 <__arch_swab16>:
>> 402650: 7c0410a0wsbhv0,a0
>> 402654: 03e8jr ra
>> 402658: 3042andiv0,v0,0x
>
> It looks to me you're papering something over here -- when you use a
> `.set nomips16' directive the assembler will happily switch your
> instruction set in the middle of an instruction stream. Consequently if
> this function is (for whatever reason; it should not really) inlined in
> MIPS16 code, then you'll get a MIPS32 instruction in the middle, which
> will obviously be interpreted differently in the MIPS16 execution mode and
> is therefore surely a recipe for disaster.
If by "papering" you mean "made up", then whatever. Yeah, it's
disaster, an "invalid instruction" abort.
>
> How did you test your change and made the conclusion quoted with your
> patch description?
>
Compile the following program with a MIPS 24kc big endian variant compiler with
flag "-mips32r2 -mips16 -Os".
#include
#include
uint16_t __attribute__((noinline)) f(uint16_t v)
{
v = __cpu_to_le16(v);
return v;
}
int main()
{
printf("%x\n", f(0xbeef));
return 0;
}
When only ".set nomips16" was specified in __arch_swab16(), this was output
from objdump.
242 004003e0 :
243 4003e0: 7c0410a0wsbhv0,a0
244 4003e4: e820ea31swc2$0,-5583(at)
245 4003e8: 650065000x65006500
246 4003ec: 650065000x65006500
__arch_swab16() was indeed inlined. That swc2 instruction can be got from
assembler with the following code (it's from the "-S" result of GCC).
.setmips16
.setnoreorder
.setnomacro
j $31
zeh $2
When only nomips16 function attribute was specified, this time GCC failed with
unrecognized opcode
/tmp/ccaGCouL.s: Assembler messages:
/tmp/ccaGCouL.s:21: Error: unrecognized opcode `wsbh $2,$4'
The generated assembly was something in the following form. Looks like the
assembler did not automatically switch to MIPS32 mode when ".set arch=mip32r2"
.set mips16
.ent f
.type f, @function
f
...
.set push
.set arch=mips32r2
wsbh $2,$4
.pop
j $31
zeh $2
.end f
...
The patch was run tested on QEMU Malta and an router with Atheros
AR9331 SoC. I didn't test __arch_swab64() though. I have done many
other trial-and-error tests while preparing this patch. It was a mess
when I was sure I should expect some sensible behaviour from the
compiler while it actually just did not behave that way.
>> Signed-off-by: Yousong Zhou
>> ---
>> arch/mips/include/uapi/asm/swab.h | 12 +---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/mips/include/uapi/asm/swab.h
>> b/arch/mips/include/uapi/asm/swab.h
>> index 8f2d184..c4ddc4f 100644
>> --- a/arch/mips/include/uapi/asm/swab.h
>> +++ b/arch/mips/include/uapi/asm/swab.h
>> @@ -16,11 +16,13 @@
>> #if (defined(__mips_isa_rev) && (__mips_isa_rev >= 2)) ||\
>> defined(_MIPS_ARCH_LOONGSON3A)
>>
>> -static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
>> +static inline __attribute__((nomips16)) __attribute_const__
>> + __u16 __arch_swab16(__u16 x)
>> {
>> __asm__(
>> " .setpush\n"
>> " .setarch=mips32r2 \n"
>> + "
[PATCH 0/2] arm64: Support Hisilicon Hip05-D02 board
Hip05-D02 Development Board is based on Cortex-A57, this patchset contains initial support for Hip05-D02 Soc and Board. Initial support is minimal and includes just the arch configuration, device tree configuration. PSCI is enabled in device tree and there is no problem to boot all the 16 cores, and the CPU hotplug is also working now, you can download and compile the latest firmware based on the following link to run this patch set. https://github.com/hisilicon/estuary/blob/master/README v1->v2: - 1. Change the compatible name for per CPU. 2. Remove the GIC_CPU_MASK_SIMPLE(xx) which is not used for gicv3 from hip05.dtsi. Ding Tianhong (2): arm64: hip05-d02: Document devicetree bindings for Hisilicon Hip05-D02 Board arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board .../bindings/arm/hisilicon/hisilicon.txt | 4 + arch/arm64/boot/dts/hisilicon/Makefile | 2 +- arch/arm64/boot/dts/hisilicon/hip05-d02.dts| 36 +++ arch/arm64/boot/dts/hisilicon/hip05.dtsi | 271 + 4 files changed, 312 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi -- 1.9.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 1/2] arm64: hip05-d02: Document devicetree bindings for Hisilicon Hip05-D02 Board
This patch adds documentation for the devicetree bindings used by the DT files of Hisilicon Hip05-D02 development board. Signed-off-by: Ding Tianhong --- Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index c431c67..f98b39d 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -20,6 +20,10 @@ HiKey Board Required root node properties: - compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220"; +HiP05 D02 Board +Required root node properties: + - compatible = "hisilicon,hip05-d02"; + Hisilicon system controller Required properties: -- 1.9.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 2/2] arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board
Add initial dtsi file to support Hisilicon Hip05-D02 Board with
support of CPUs in four clusters and each cluster has quard Cortex-A57.
Also add dts file to support Hip05-D02 development board.
Signed-off-by: Ding Tianhong
Signed-off-by: Kefeng Wang
---
arch/arm64/boot/dts/hisilicon/Makefile | 2 +-
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 36
arch/arm64/boot/dts/hisilicon/hip05.dtsi| 271
3 files changed, 308 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile
b/arch/arm64/boot/dts/hisilicon/Makefile
index fa81a6e..cd158b8 100644
--- a/arch/arm64/boot/dts/hisilicon/Makefile
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
+dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb hip05-d02.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
new file mode 100644
index 000..ae34e25
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
@@ -0,0 +1,36 @@
+/**
+ * dts file for Hisilicon D02 Development Board
+ *
+ * Copyright (C) 2014,2015 Hisilicon Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+
+#include "hip05.dtsi"
+
+/ {
+ model = "Hisilicon Hip05 D02 Development Board";
+ compatible = "hisilicon,hip05-d02";
+
+ memory@ {
+ device_type = "memory";
+ reg = <0x0 0x 0x0 0x8000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
new file mode 100644
index 000..92d00f4
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -0,0 +1,271 @@
+/**
+ * dts file for Hisilicon D02 Development Board
+ *
+ * Copyright (C) 2014,2015 Hisilicon Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ *
+ */
+
+#include
+
+/ {
+ compatible = "hisilicon,hip05-d02";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ cluster2 {
+ core0 {
+ cpu = <&cpu8>;
+ };
+ core1 {
+ cpu = <&cpu9>;
+ };
+ core2 {
+ cpu = <&cpu10>;
+ };
+ core3 {
+ cpu = <&cpu11>;
+ };
+ };
+ cluster3 {
+ core0 {
+ cpu = <&cpu12>;
+ };
+ core1 {
+ cpu = <&cpu13>;
+ };
+
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 9/4/2015 6:40 PM, David Daney wrote:
> On 09/04/2015 06:14 PM, Frank Rowand wrote:
>> On 9/4/2015 12:12 PM, David Daney wrote:
>>> From: David Daney
>>>
>>> It is perfectly legitimate for a PCI device to have an
>>> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
>>> use interrupts, or on PCIe devices, where only MSI/MSI-X are
>>> supported.
>>>
>>> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
>>> messages by making them conditional on !-ENODEV (which can only be
>>> produced in the PCI_INTERRUPT_PIN == 0 case).
>>>
>>> Signed-off-by: David Daney
>>> ---
>>> drivers/of/of_pci_irq.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
>>> index 1710d9d..33d242a 100644
>>> --- a/drivers/of/of_pci_irq.c
>>> +++ b/drivers/of/of_pci_irq.c
>>> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev,
>>> u8 slot, u8 pin)
>>>
>>> ret = of_irq_parse_pci(dev, &oirq);
>>> if (ret) {
>>> -dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", ret);
>>> +if (ret != -ENODEV)
>>> +dev_err(&dev->dev,
>>> +"of_irq_parse_pci() failed with rc=%d\n", ret);
>>> return 0; /* Proper return code 0 == NO_IRQ */
>>> }
>>>
>>>
>>
>> It is not safe to assume that the functions that of_irq_parse_pci() calls
>> will never be modified to return -ENODEV, thus resulting in
>> of_irq_parse_pci()
>> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>>
>
> Since the current implementation *only ever* returns -ENODEV for
> PCI_INTERRUPT_PIN == 0, we could just document that behavior, and not hack up
> the APIs by adding a second return channel from the function.
And for each function that of_irq_parse_pci() calls and returns status from the
function call you would need to document that behavior, and so on recursively.
For example, you would need to document of_irq_parse_one(). And that returns
status
from more function calls, so you would need to document of_irq_parse_oldworld(),
of_parse_phandle_with_args(), of_irq_parse_raw(), and then anything they call.
>
> The additional change on top of my patch would be to add a comment describing
> this behavior.
>
> David Daney.
< snip >
-Frank
--
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] crypto/testmgr: don't copy from source IV too much
On Fri, Sep 04, 2015 at 07:42:26PM +0300, Andrey Ryabinin wrote: > > But noticed that some algs don't set ivsize (which makes it zero). > E.g. "ecb-cast6-avx" doesn't set it, but test vectors > (cast6_enc_tv_template[], cast6_dec_tv_template[]) > have .iv of 16bytes. ECB should always have an IV size of zero so this is correct. If the test vectors contain an IV it'll simply be ignored. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
Russell, On Fri, Sep 4, 2015 at 5:27 PM, Russell King - ARM Linux wrote: > On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote: >> Russell, >> >> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux >> wrote: >> >> In your case you're probably making the value that Linux >> >> asked you to make, AKA 25.175000 MHz. >> > >> > ... which is the spec value. >> >> This is where we're not on the same page. Where in the spec does it >> say 25.17500 MHz? I see in the spec: >> 25.2 / 1.001 > > Section 4 of CEA-861-B, which defines the video clock rates and their > accuracy of 0.5%. Then perhaps you shouldn't be using a switch statement. You won't catch all values that are within .05% of (25.2 / 1.001). >> ...and this is a crucial difference here. Please double-check my math, but: >> >> (25175000 * 4576) / (128 * 32000.) >> => 28125.1953125 >> >> (25174825 * 4576) / (128 * 32000.) >> => 28125.0 >> >> This calculation is what led to my belief that the goal here is to >> make an integral CTS. If you have 25.175 MHZ clock and N of 4576 you >> _will not_ have an integral CTS. If you instead have 25.174825 MHz >> clock and N of 4576 you _will_ have an integral CTS. > > Right, but 25.175 is close enough to 25.174825. Do this calculation: > > 25175000 * 4576 / 28125 / 128 > > That'll give you the resulting audio sample rate, which is 32000.222Hz. > That's an error of... 0.00069%, which is probably around the typical > error of your average crystal oscillator. Really not worth bothering > with. OK, so do this calculation: 25175000 * 4096 / 25175 / 128 You get 32000.00 I'm not saying there's anything terribly wrong with 32000.222 Hz and I'm sure it will work just dandy for you. I'm saying that you're adding complexity _and_ ending up with a slightly worse rate. AKA: just replace your entire "compute_n" function with: return (128 * freq) / 1000; ...and it's 100% simpler _and_ gets you a (marginally) better rate (assuming you really have 22.175000). If it was just about a 32000.222 vs 32000 I'd not be saying anything right now. It's about adding complexity. >> Said another way: >> >> 1. The reason 25174825 Hz has a different N is to make an integral CTS. >> >> 2. If you are indeed making 25175000 then there is no need for a >> different N to make an integral CTS >> >> 3. If you use 4576 for N but you're making 25175000 Hz, you end up in >> a _worse_ position than if you use the standard 4096 for N. > > Total rubbish. Sorry, but it is. > > Follow the code. Pixel clock is 25175000. For 32kHz, N will be 4576. > 25175000 * 4576 = 1.152008e11. Divide that by the audio clock rate > (128 * 32000) gives 28125.19531. Since we're using integer division, > that gets rounded down to 28125. > > DRM uses a clock rate of "25175" to represent 25.2/1.001 modes. So, > if your hardware sets a video clock rate of 25.2MHz/1.001, then you > end up with a sample rate of exactly 32kHz. If you set exactly > 25.175MHz, you end up with an approximate 32kHz sample rate - one > which is 0.00069% in error, which is (excluse the language) fuck all > different from exactly 32kHz. Agree that the difference is negligible. I will say that IMHO the kind folks who wrote the HDMI spec were still trying their best to make that error 0.00%. That's entirely the reason that they have that table and they don't just use "(128 * freq) / 1000" for everything. AKA, I can imagine something like: Person 1: Is there any reason to pick a N value that's exactly (128 * freq) / 1000? Person 2: Not really Person 1: Hrm, but I notice that I can get a tiny bit more accurate audio clock when I have a pixel clock of (25.2 / 1.001) if I use a N that's not (128 * freq) / 1000. Is that OK? Person 2: Yeah, go ahead. Add it to the spec. Person 1: OK. I've got some nifty tables I can add. Cool! Now we get exactly the right audio clock. Person 2: Nice job! ...but I have no idea if that's really true. > Are you _really_ going to continue arguing over a 0.00069% error? > If you are, I'm not going to listen anymore - it's soo damned small > that it's not worth bothering with. At all. Well, I think I've adequately expressed my opinion. If you want to land your patch, I certainly won't yell. I think it adds extra complexity and produces a (marginally) inferior audio rate, but that's up to the folks who maintain the code to deal with. >> As a side note: I realized one part of the HDMI spec that isn't trying >> to make an integral value but still uses a different value for N: 297 >> MHz. From the DesignWare spec I have it appears that 594 MHz is >> similar. For those cases it looks like we have: > > 297MHz _does_ work. > > 29700 * 3072 / 222750 = 128 * 32000 exactly. I guess I didn't express myself clearly enough. I'm saying that: * The only reason I can discern for using non "(128 * freq) / 1000" N values for rates < 297 Mhz is to try to make an integral CTS. * For rates >= 297 MHz you could make CTS i
Re: [RFC v0 2/9] suspend: Add getter function to report if freezing is active
On Friday, September 04, 2015 03:34:55 PM Daniel Wagner wrote:
> Instead encode the FREEZE state via the CPU state we allow the
> interesting subsystems (MCE, microcode) to query the power
> subsystem directly.
A use case, please.
> Most notifiers are not interested at all
> in this information so rather have explicit calls to freeze_active()
> instead adding complexity to the rest of the users of the CPU
> notifiers.
Why does it has anything to do with CPU notifiers? We don't offline
CPUs for suspend-to-idle.
> Signed-off-by: Daniel Wagner
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Pavel Machek
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> include/linux/suspend.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 5efe743..5e15ade 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -216,6 +216,11 @@ static inline bool idle_should_freeze(void)
> return unlikely(suspend_freeze_state == FREEZE_STATE_ENTER);
> }
>
> +static inline bool freeze_active(void)
> +{
> + return unlikely(suspend_freeze_state != FREEZE_STATE_NONE);
> +}
> +
> extern void freeze_set_ops(const struct platform_freeze_ops *ops);
> extern void freeze_wake(void);
>
> @@ -244,6 +249,7 @@ extern int pm_suspend(suspend_state_t state);
> static inline void suspend_set_ops(const struct platform_suspend_ops *ops) {}
> static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
> static inline bool idle_should_freeze(void) { return false; }
> +static inline bool freeze_active(void) { return false; }
> static inline void freeze_set_ops(const struct platform_freeze_ops *ops) {}
> static inline void freeze_wake(void) {}
> #endif /* !CONFIG_SUSPEND */
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 09/04/2015 06:14 PM, Frank Rowand wrote:
On 9/4/2015 12:12 PM, David Daney wrote:
From: David Daney
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.
Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
messages by making them conditional on !-ENODEV (which can only be
produced in the PCI_INTERRUPT_PIN == 0 case).
Signed-off-by: David Daney
---
drivers/of/of_pci_irq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 1710d9d..33d242a 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8
slot, u8 pin)
ret = of_irq_parse_pci(dev, &oirq);
if (ret) {
- dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n",
ret);
+ if (ret != -ENODEV)
+ dev_err(&dev->dev,
+ "of_irq_parse_pci() failed with rc=%d\n", ret);
return 0; /* Proper return code 0 == NO_IRQ */
}
It is not safe to assume that the functions that of_irq_parse_pci() calls
will never be modified to return -ENODEV, thus resulting in of_irq_parse_pci()
returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
Since the current implementation *only ever* returns -ENODEV for
PCI_INTERRUPT_PIN == 0, we could just document that behavior, and not
hack up the APIs by adding a second return channel from the function.
The additional change on top of my patch would be to add a comment
describing this behavior.
David Daney.
A more robust solution would be something like:
(1) Change of_irq_parse_pci() to _of_irq_parse_pci(), adding an argument and
use it to report the case of PCI_INTERRUPT_PIN == 0.
static int _of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args
*out_irq, int *no_pin)
{
...
*no_pin = 0;
...
/* No pin, exit */
if (pin == 0) {
*no_pin = 1;
return -ENODEV;
}
...
int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args
*out_irq)
{
int no_pin;
return _of_irq_parse_pci(pdev, out_irq, &no_pin)
}
(2) Then the fix to of_irq_parse_and_map_pci() would be:
+ int no_pin;
ret = of_irq_parse_pci(dev, &oirq, &no_pin);
if (ret) {
- dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n",
ret);
+ if (!no_pin)
+ dev_err(&dev->dev,
+ "of_irq_parse_pci() failed with rc=%d\n", ret);
return 0; /* Proper return code 0 == NO_IRQ */
}
I'm not sure I like my solution, there might be a better way.
I also noticed another bug while looking at of_irq_parse_pci(). It returns
the non-zero return value from pci_read_config_byte(). But that value is
one of the PCI function error values from include/linux/pci.h, such as:
#define PCIBIOS_BAD_REGISTER_NUMBER 0x87
instead of a negative errno.
-Frank
--
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/
defects for uses of abs(u64) (was: Re: Regression: can't apply frequency offsets above 1000ppm)
On Fri, 2015-09-04 at 18:00 -0700, John Stultz wrote:
> On Fri, Sep 4, 2015 at 5:57 PM, John Stultz wrote:
> > On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar
> > wrote:
> >> On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote:
> >>> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote:
> >>> > And just installing chrony from the feeds. With any kernel from 3.17
> >>> > you'll have wrong estimates at chronyc sourcestats.
> >>>
> >>> Wrong estimates? Could you be more specific about what the failure
> >>> you're seeing is here? The
> >>>
> >>> I installed the image above, which comes with a 4.1.6 kernel, and
> >>> chrony seems to have gotten my BBB into ~1ms sync w/ servers over the
> >>> internet fairly quickly (at least according to chronyc tracking).
> >>
> >> To see the bug with chronyd the initial offset shouldn't be very close
> >> to zero, so it's forced to correct the offset by adjusting the
> >> frequency in a larger step.
> >>
> >> I'm attaching a simple C program that prints the frequency offset
> >> as measured between the REALTIME and MONOTONIC_RAW clocks when the
> >> adjtimex tick is set to 9000. It should show values close to -10
> >> ppm and I suspect on the BBB it will be much smaller.
> >
> > So I spent some time on this late last night and this afternoon.
> >
> > It was a little odd because things don't seem totally broken, but
> > something isn't quite right.
> >
> > Digging around it seems the iterative logrithmic approximation done in
> > timekeeping_freqadjust() wasn't working right. Instead of making
> > smaller order alternating positive and negative adjustments, it was
> > doing strange growing adjustments for the same value that wern't large
> > enough to actually correct things very quickly. This made it much
> > slower to adapt to specified frequency values.
> >
> > The odd bit, is it seems to come down to:
> > tick_error = abs(tick_error);
> >
> > Haven't chased down why yet, but apparently abs() isn't doing what one
> > would think when passed a s64 value.
>
> Well.. chasing it down wasn't hard.. from include/linux/kernel.h:
> /*
> * abs() handles unsigned and signed longs, ints, shorts and chars. For all
> * input types abs() returns a signed long.
> * abs() should not be used for 64-bit types (s64, u64, long long) - use
> abs64()
> * for those.
> */
>
> Ouch.
Here's a little cocci script that finds more of these in:
lib/percpu_counter.c
drivers/input/joystick/walkera0701.c
drivers/md/raid5.c
drivers/spi/spi-pxa2xx.c
fs/f2fs/debug.c
$ cat abs.cocci
@@
u64 t;
@@
* abs(t)
@@
s64 t;
@@
* abs(t)
@@
long long t;
@@
* abs(t)
@@
unsigned long long t;
@@
* abs(t)
@@
uint64_t t;
@@
* abs(t)
@@
int64_t t;
@@
* abs(t)
$
diff -u -p ./lib/percpu_counter.c /tmp/nothing/lib/percpu_counter.c
--- ./lib/percpu_counter.c
+++ /tmp/nothing/lib/percpu_counter.c
@@ -203,7 +203,6 @@ int __percpu_counter_compare(struct perc
count = percpu_counter_read(fbc);
/* Check to see if rough count will be sufficient for comparison */
- if (abs(count - rhs) > (batch * num_online_cpus())) {
if (count > rhs)
return 1;
else
diff -u -p ./drivers/input/joystick/walkera0701.c
/tmp/nothing/drivers/input/joystick/walkera0701.c
--- ./drivers/input/joystick/walkera0701.c
+++ /tmp/nothing/drivers/input/joystick/walkera0701.c
@@ -150,7 +150,6 @@ static void walkera0701_irq_handler(void
if (w->counter == 24) { /* full frame */
walkera0701_parse_frame(w);
w->counter = NO_SYNC;
- if (abs(pulse_time - SYNC_PULSE) < RESERVE) /* new
frame sync */
w->counter = 0;
} else {
if ((pulse_time > (ANALOG_MIN_PULSE - RESERVE)
@@ -161,7 +160,6 @@ static void walkera0701_irq_handler(void
} else
w->counter = NO_SYNC;
}
- } else if (abs(pulse_time - SYNC_PULSE - BIN0_PULSE) <
RESERVE + BIN1_PULSE - BIN0_PULSE) /*
frame sync .. */
w->counter = 0;
diff -u -p ./drivers/md/raid5.c /tmp/nothing/drivers/md/raid5.c
--- ./drivers/md/raid5.c
+++ /tmp/nothing/drivers/md/raid5.c
@@ -6701,8 +6701,6 @@ static int run(struct mddev *mddev)
* readonly mode so it can take control before
* allowing any writes. So just check for that.
*/
- if (abs(min_offset_diff) >= mddev->chunk_sectors &&
- abs(min_offset_diff) >= mddev->new_chunk_sectors)
/* not really in-place - so OK */;
else if (mddev->ro == 0) {
printk(KERN_ERR "md/raid:%s: in-place reshape "
diff -u -p ./drivers/spi/spi-pxa2xx.c /tmp/nothing
[PATCH 08/15] perf tools: Switch to tracing_path interface on appropriate places
From: Jiri Olsa
Using tracing_path interface on several places, that more or less
copy the functionality of tracing_path interface.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Raphael Beamonte
Cc: Steven Rostedt
Link:
http://lkml.kernel.org/r/1441180605-24737-16-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/openat-syscall-all-cpus.c | 9 +++--
tools/perf/tests/openat-syscall.c | 11 ---
tools/perf/tests/parse-events.c| 16 ++--
tools/perf/util/probe-file.c | 14 ++
4 files changed, 11 insertions(+), 39 deletions(-)
diff --git a/tools/perf/tests/openat-syscall-all-cpus.c
b/tools/perf/tests/openat-syscall-all-cpus.c
index a38adf94c731..495d8126b722 100644
--- a/tools/perf/tests/openat-syscall-all-cpus.c
+++ b/tools/perf/tests/openat-syscall-all-cpus.c
@@ -15,6 +15,7 @@ int test__openat_syscall_event_on_all_cpus(void)
cpu_set_t cpu_set;
struct thread_map *threads = thread_map__new(-1, getpid(), UINT_MAX);
char sbuf[STRERR_BUFSIZE];
+ char errbuf[BUFSIZ];
if (threads == NULL) {
pr_debug("thread_map__new\n");
@@ -31,12 +32,8 @@ int test__openat_syscall_event_on_all_cpus(void)
evsel = perf_evsel__newtp("syscalls", "sys_enter_openat");
if (evsel == NULL) {
- if (tracefs__configured())
- pr_debug("is tracefs mounted on
/sys/kernel/tracing?\n");
- else if (debugfs__configured())
- pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
- else
- pr_debug("Neither tracefs or debugfs is enabled in this
kernel\n");
+ tracing_path__strerror_open_tp(errno, errbuf, sizeof(errbuf),
"syscalls", "sys_enter_openat");
+ pr_err("%s\n", errbuf);
goto out_thread_map_delete;
}
diff --git a/tools/perf/tests/openat-syscall.c
b/tools/perf/tests/openat-syscall.c
index 8048c7d7cd67..08ac9d94a050 100644
--- a/tools/perf/tests/openat-syscall.c
+++ b/tools/perf/tests/openat-syscall.c
@@ -1,4 +1,4 @@
-#include
+#include
#include "thread_map.h"
#include "evsel.h"
#include "debug.h"
@@ -11,6 +11,7 @@ int test__openat_syscall_event(void)
unsigned int nr_openat_calls = 111, i;
struct thread_map *threads = thread_map__new(-1, getpid(), UINT_MAX);
char sbuf[STRERR_BUFSIZE];
+ char errbuf[BUFSIZ];
if (threads == NULL) {
pr_debug("thread_map__new\n");
@@ -19,12 +20,8 @@ int test__openat_syscall_event(void)
evsel = perf_evsel__newtp("syscalls", "sys_enter_openat");
if (evsel == NULL) {
- if (tracefs__configured())
- pr_debug("is tracefs mounted on
/sys/kernel/tracing?\n");
- else if (debugfs__configured())
- pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
- else
- pr_debug("Neither tracefs or debugfs is enabled in this
kernel\n");
+ tracing_path__strerror_open_tp(errno, errbuf, sizeof(errbuf),
"syscalls", "sys_enter_openat");
+ pr_err("%s\n", errbuf);
goto out_thread_map_delete;
}
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 91fbfd593c4a..3a2ebe666192 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -1261,23 +1261,11 @@ test__checkevent_breakpoint_len_rw_modifier(struct
perf_evlist *evlist)
static int count_tracepoints(void)
{
- char events_path[PATH_MAX];
struct dirent *events_ent;
- const char *mountpoint;
DIR *events_dir;
int cnt = 0;
- mountpoint = tracefs__mountpoint();
- if (mountpoint) {
- scnprintf(events_path, PATH_MAX, "%s/events",
- mountpoint);
- } else {
- mountpoint = debugfs__mountpoint();
- scnprintf(events_path, PATH_MAX, "%s/tracing/events",
- mountpoint);
- }
-
- events_dir = opendir(events_path);
+ events_dir = opendir(tracing_events_path);
TEST_ASSERT_VAL("Can't open events dir", events_dir);
@@ -1294,7 +1282,7 @@ static int count_tracepoints(void)
continue;
scnprintf(sys_path, PATH_MAX, "%s/%s",
- events_path, events_ent->d_name);
+ tracing_events_path, events_ent->d_name);
sys_dir = opendir(sys_path);
TEST_ASSERT_VAL("Can't open sys dir", sys_dir);
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 499c83ccd44b..89dbeb92c68e 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -22,7 +22,7 @@
#include "color.h"
#include "symbol.h
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 9/4/2015 12:12 PM, David Daney wrote:
> From: David Daney
>
> It is perfectly legitimate for a PCI device to have an
> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
> use interrupts, or on PCIe devices, where only MSI/MSI-X are
> supported.
>
> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
> messages by making them conditional on !-ENODEV (which can only be
> produced in the PCI_INTERRUPT_PIN == 0 case).
>
> Signed-off-by: David Daney
> ---
> drivers/of/of_pci_irq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
> index 1710d9d..33d242a 100644
> --- a/drivers/of/of_pci_irq.c
> +++ b/drivers/of/of_pci_irq.c
> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev,
> u8 slot, u8 pin)
>
> ret = of_irq_parse_pci(dev, &oirq);
> if (ret) {
> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n",
> ret);
> + if (ret != -ENODEV)
> + dev_err(&dev->dev,
> + "of_irq_parse_pci() failed with rc=%d\n", ret);
> return 0; /* Proper return code 0 == NO_IRQ */
> }
>
>
It is not safe to assume that the functions that of_irq_parse_pci() calls
will never be modified to return -ENODEV, thus resulting in of_irq_parse_pci()
returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
A more robust solution would be something like:
(1) Change of_irq_parse_pci() to _of_irq_parse_pci(), adding an argument and
use it to report the case of PCI_INTERRUPT_PIN == 0.
static int _of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args
*out_irq, int *no_pin)
{
...
*no_pin = 0;
...
/* No pin, exit */
if (pin == 0) {
*no_pin = 1;
return -ENODEV;
}
...
int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args
*out_irq)
{
int no_pin;
return _of_irq_parse_pci(pdev, out_irq, &no_pin)
}
(2) Then the fix to of_irq_parse_and_map_pci() would be:
+ int no_pin;
> ret = of_irq_parse_pci(dev, &oirq, &no_pin);
> if (ret) {
> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n",
> ret);
> + if (!no_pin)
> + dev_err(&dev->dev,
> + "of_irq_parse_pci() failed with rc=%d\n", ret);
> return 0; /* Proper return code 0 == NO_IRQ */
> }
I'm not sure I like my solution, there might be a better way.
I also noticed another bug while looking at of_irq_parse_pci(). It returns
the non-zero return value from pci_read_config_byte(). But that value is
one of the PCI function error values from include/linux/pci.h, such as:
#define PCIBIOS_BAD_REGISTER_NUMBER 0x87
instead of a negative errno.
-Frank
--
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 09/15] perf test: Add entry to test cpu topology
From: Kan Liang
This patch test cpu core_id and socket_id which are stored in perf_env.
Commiter note:
# perf test topo
40: Test topology in session: Ok
# perf test -v topo
40: Test topology in session:
--- start ---
test child forked, pid 31767
templ file: /tmp/perf-test-VTZ1PL
CPU 0, core 0, socket 0
CPU 1, core 1, socket 0
CPU 2, core 0, socket 0
CPU 3, core 1, socket 0
test child finished with 0
end
Test topology in session: Ok
#
Based-on-a-patch-by: Jiri Olsa
Signed-off-by: Kan Liang
Tested-by: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1441357111-64522-1-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 4 ++
tools/perf/tests/tests.h| 1 +
tools/perf/tests/topology.c | 115
4 files changed, 121 insertions(+)
create mode 100644 tools/perf/tests/topology.c
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 51fb737f82fc..c6f198ae65fb 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -33,6 +33,7 @@ perf-y += parse-no-sample-id-all.o
perf-y += kmod-path.o
perf-y += thread-map.o
perf-y += llvm.o
+perf-y += topology.o
perf-$(CONFIG_X86) += perf-time-to-tsc.o
ifdef CONFIG_AUXTRACE
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 69a77f71d594..98b0b2486100 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -187,6 +187,10 @@ static struct test {
#endif
#endif
{
+ .desc = "Test topology in session",
+ .func = test_session_topology,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 4e2c5458269a..0b3549672c16 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -64,6 +64,7 @@ int test__kmod_path__parse(void);
int test__thread_map(void);
int test__llvm(void);
int test__insn_x86(void);
+int test_session_topology(void);
#if defined(__x86_64__) || defined(__i386__) || defined(__arm__) ||
defined(__aarch64__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
new file mode 100644
index ..c3aff53a976a
--- /dev/null
+++ b/tools/perf/tests/topology.c
@@ -0,0 +1,115 @@
+#include
+#include
+#include
+#include "tests.h"
+#include "util.h"
+#include "session.h"
+#include "evlist.h"
+#include "debug.h"
+
+#define TEMPL "/tmp/perf-test-XX"
+#define DATA_SIZE 10
+
+static int get_temp(char *path)
+{
+ int fd;
+
+ strcpy(path, TEMPL);
+
+ fd = mkstemp(path);
+ if (fd < 0) {
+ perror("mkstemp failed");
+ return -1;
+ }
+
+ close(fd);
+ return 0;
+}
+
+static int session_write_header(char *path)
+{
+ struct perf_session *session;
+ struct perf_data_file file = {
+ .path = path,
+ .mode = PERF_DATA_MODE_WRITE,
+ };
+
+ session = perf_session__new(&file, false, NULL);
+ TEST_ASSERT_VAL("can't get session", session);
+
+ session->evlist = perf_evlist__new_default();
+ TEST_ASSERT_VAL("can't get evlist", session->evlist);
+
+ perf_header__set_feat(&session->header, HEADER_CPU_TOPOLOGY);
+ perf_header__set_feat(&session->header, HEADER_NRCPUS);
+
+ session->header.data_size += DATA_SIZE;
+
+ TEST_ASSERT_VAL("failed to write header",
+ !perf_session__write_header(session, session->evlist,
file.fd, true));
+
+ perf_session__delete(session);
+
+ return 0;
+}
+
+static int check_cpu_topology(char *path, struct cpu_map *map)
+{
+ struct perf_session *session;
+ struct perf_data_file file = {
+ .path = path,
+ .mode = PERF_DATA_MODE_READ,
+ };
+ int i;
+
+ session = perf_session__new(&file, false, NULL);
+ TEST_ASSERT_VAL("can't get session", session);
+
+ for (i = 0; i < session->header.env.nr_cpus_online; i++) {
+ pr_debug("CPU %d, core %d, socket %d\n", i,
+session->header.env.cpu[i].core_id,
+session->header.env.cpu[i].socket_id);
+ }
+
+ for (i = 0; i < map->nr; i++) {
+ TEST_ASSERT_VAL("Core ID doesn't match",
+ (session->header.env.cpu[map->map[i]].core_id ==
(cpu_map__get_core(map, i) & 0x)));
+
+ TEST_ASSERT_VAL("Socket ID doesn't match",
+ (session->header.env.cpu[map->map[i]].socket_id ==
cpu_map__get_socket(map, i)));
+ }
+
+ perf_session__delete(session);
+
+ return 0;
+}
+
+int test_session_topology(void)
+{
+ char path[PATH_MAX];
+ struct cpu_map *map;
+ int ret = -1;
+
+ TEST_ASSERT_
[PATCH 06/15] tools lib api fs: Replace debugfs/tracefs objects interface with fs.c
From: Jiri Olsa
Switching to the fs.c related filesystem framework.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Raphael Beamonte
Cc: Steven Rostedt
Link:
http://lkml.kernel.org/r/1441180605-24737-14-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/api/fs/fs.c | 1 -
tools/lib/api/fs/tracing_path.c| 15 +++
tools/perf/builtin-kvm.c | 1 -
tools/perf/builtin-probe.c | 1 -
tools/perf/tests/openat-syscall-all-cpus.c | 5 +++--
tools/perf/tests/openat-syscall.c | 5 +++--
tools/perf/tests/parse-events.c| 7 +++
tools/perf/util/evsel.c| 2 +-
tools/perf/util/probe-event.c | 5 ++---
tools/perf/util/probe-file.c | 7 +++
tools/perf/util/util.h | 3 +--
11 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index 8afe08a99bc6..791509346178 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -11,7 +11,6 @@
#include
#include
-#include "debugfs.h"
#include "fs.h"
#define _STR(x) #x
diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c
index 1e0bb0da5e4f..38aca2dd1946 100644
--- a/tools/lib/api/fs/tracing_path.c
+++ b/tools/lib/api/fs/tracing_path.c
@@ -7,8 +7,7 @@
#include
#include
#include
-#include "debugfs.h"
-#include "tracefs.h"
+#include "fs.h"
#include "tracing_path.h"
@@ -29,7 +28,7 @@ static const char *tracing_path_tracefs_mount(void)
{
const char *mnt;
- mnt = tracefs_mount(NULL);
+ mnt = tracefs__mount();
if (!mnt)
return NULL;
@@ -42,7 +41,7 @@ static const char *tracing_path_debugfs_mount(void)
{
const char *mnt;
- mnt = debugfs_mount(NULL);
+ mnt = debugfs__mount();
if (!mnt)
return NULL;
@@ -96,7 +95,7 @@ static int strerror_open(int err, char *buf, size_t size,
const char *filename)
* want some tracepoint which wasn't compiled in your kernel.
* - jirka
*/
- if (debugfs_configured() || tracefs_configured()) {
+ if (debugfs__configured() || tracefs__configured()) {
snprintf(buf, size,
"Error:\tFile %s/%s not found.\n"
"Hint:\tPerhaps this kernel misses some
CONFIG_ setting to enable this feature?.\n",
@@ -110,13 +109,13 @@ static int strerror_open(int err, char *buf, size_t size,
const char *filename)
"Hint:\tTry 'sudo mount -t debugfs nodev
/sys/kernel/debug'");
break;
case EACCES: {
- const char *mountpoint = debugfs_find_mountpoint();
+ const char *mountpoint = debugfs__mountpoint();
if (!access(mountpoint, R_OK) && strncmp(filename, "tracing/",
8) == 0) {
- const char *tracefs_mntpoint =
tracefs_find_mountpoint();
+ const char *tracefs_mntpoint = tracefs__mountpoint();
if (tracefs_mntpoint)
- mountpoint = tracefs_find_mountpoint();
+ mountpoint = tracefs__mountpoint();
}
snprintf(buf, size,
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index fc1cffb1b7a2..dd94b4ca2213 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -13,7 +13,6 @@
#include "util/parse-options.h"
#include "util/trace-event.h"
#include "util/debug.h"
-#include
#include "util/tool.h"
#include "util/stat.h"
#include "util/top.h"
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index ee2c46d8353e..2bec9c1ef2a3 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -37,7 +37,6 @@
#include "util/strfilter.h"
#include "util/symbol.h"
#include "util/debug.h"
-#include
#include "util/parse-options.h"
#include "util/probe-finder.h"
#include "util/probe-event.h"
diff --git a/tools/perf/tests/openat-syscall-all-cpus.c
b/tools/perf/tests/openat-syscall-all-cpus.c
index a572f87e9c8d..a38adf94c731 100644
--- a/tools/perf/tests/openat-syscall-all-cpus.c
+++ b/tools/perf/tests/openat-syscall-all-cpus.c
@@ -1,3 +1,4 @@
+#include
#include "evsel.h"
#include "tests.h"
#include "thread_map.h"
@@ -30,9 +31,9 @@ int test__openat_syscall_event_on_all_cpus(void)
evsel = perf_evsel__newtp("syscalls", "sys_enter_openat");
if (evsel == NULL) {
- if (tracefs_configured())
+ if (tracefs__configured())
pr_debug("is tracefs mounted on
/sys/kernel/tracing?\n");
- else if (debugfs_configured())
+ else if (debugfs__configured())
[GIT PULL 00/15] perf/core improvements and fixes
Hi Ingo, Please consider pulling, this is on top of the previous pull request, perf-core-for-mingo. - Arnaldo The following changes since commit cf2f33a4e54096f90652cca3511fd6a456ea5abe: perf trace: Add read/write to the file group (2015-09-04 13:22:06 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2 for you to fetch changes up to 0959e527b1593e662cb99639a587eac39ea1232d: perf stat: Move sw clock metrics printout to stat-shadow (2015-09-04 20:30:01 -0300) perf/core improvements and fixes: User visible: - Add 'socket' sort entry, to sort by the processor socket in 'perf top' and 'perf report' (Kan Liang) - Introduce --socket-filter to 'perf report', for filtering by processor socket (Kan Liang) - Add new "Zoom into Processor Socket" operation in the perf hists browser, used in 'perf top' and 'perf report' (Kan Liang) Infrastructure: - 'perf test' fixes for the object code reading entry (Jan Stancek) - Add processor socket and cpu topology 'perf test' entries (Kan Liang) - Move sw clock metrics printout to stat-shadow (Andi Kleen) - Switch to tracing_patch interface (Jiri Olsa) Signed-off-by: Arnaldo Carvalho de Melo Andi Kleen (1): perf stat: Move sw clock metrics printout to stat-shadow Jan Stancek (4): perf tests: Take into account address of each objdump line perf tests: Make objdump disassemble zero blocks perf tests: Stop reading if objdump output crossed sections perf tests: Print objdump/dso buffers if they don't match Jiri Olsa (4): tools lib api fs: Make tracing_path_strerror_open message generic tools lib api fs: Replace debugfs/tracefs objects interface with fs.c tools lib api fs: Remove debugfs, tracefs and findfs objects perf tools: Switch to tracing_path interface on appropriate places Kan Liang (6): perf test: Add entry to test cpu topology perf tools: Add processor socket info to hist_entry and addr_location perf tools: Introduce new sort type "socket" for the processor socket perf report: Introduce --socket-filter option perf hists browser: Zoom in/out for processor socket perf test: Add entry for hists socket filter tools/lib/api/fs/Build | 3 - tools/lib/api/fs/debugfs.c | 77 --- tools/lib/api/fs/debugfs.h | 23 -- tools/lib/api/fs/findfs.c | 63 tools/lib/api/fs/findfs.h | 23 -- tools/lib/api/fs/fs.c | 1 - tools/lib/api/fs/tracefs.c | 78 --- tools/lib/api/fs/tracefs.h | 21 -- tools/lib/api/fs/tracing_path.c| 35 + tools/perf/Documentation/perf-report.txt | 6 +- tools/perf/builtin-kvm.c | 1 - tools/perf/builtin-probe.c | 1 - tools/perf/builtin-report.c| 15 tools/perf/builtin-stat.c | 9 --- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c| 4 + tools/perf/tests/code-reading.c| 74 +++ tools/perf/tests/hists_filter.c| 55 +++--- tools/perf/tests/openat-syscall-all-cpus.c | 10 +-- tools/perf/tests/openat-syscall.c | 10 +-- tools/perf/tests/parse-events.c| 19 + tools/perf/tests/tests.h | 1 + tools/perf/tests/topology.c| 115 + tools/perf/ui/browsers/hists.c | 59 ++- tools/perf/util/event.c| 1 + tools/perf/util/evsel.c| 2 +- tools/perf/util/hist.c | 37 ++ tools/perf/util/hist.h | 6 +- tools/perf/util/probe-event.c | 5 +- tools/perf/util/probe-file.c | 15 +--- tools/perf/util/sort.c | 22 ++ tools/perf/util/sort.h | 2 + tools/perf/util/stat-shadow.c | 3 + tools/perf/util/symbol.h | 1 + tools/perf/util/util.h | 3 +- 35 files changed, 409 insertions(+), 392 deletions(-) delete mode 100644 tools/lib/api/fs/debugfs.c delete mode 100644 tools/lib/api/fs/debugfs.h delete mode 100644 tools/lib/api/fs/findfs.c delete mode 100644 tools/lib/api/fs/findfs.h delete mode 100644 tools/lib/api/fs/tracefs.c delete mode 100644 tools/lib/api/fs/tracefs.h create mode 100644 tools/perf/tests/topology.c -- 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.h
[PATCH 11/15] perf tools: Introduce new sort type "socket" for the processor socket
From: Kan Liang
This patch enable perf report to sort by processor socket:
$ perf report --stdio --sort socket,comm,dso,symbol
# To display the perf.data header info, please use --header/--header-only
options.
#
# Total Lost Samples: 0
#
# Samples: 686 of event 'cycles'
# Event count (approx.): 349215462
#
# Overhead SOCKET Command Shared ObjectSymbol
# .. ...
#
97.05%000 testtest [.] plusB_c
0.98%000 testtest [.] plusA_c
0.93%001 perf[kernel.vmlinux] [k] smp_call_function_single
0.19%001 perf[kernel.vmlinux] [k] page_fault
0.19%001 swapper [kernel.vmlinux] [k] pm_qos_request
0.16%000 test[kernel.vmlinux] [k] add_mm_counter_fast
Signed-off-by: Kan Liang
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1441377946-44429-2-git-send-email-kan.li...@intel.com
[ Fix column calculation, un-allcapsify column header ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-report.txt | 3 ++-
tools/perf/util/hist.c | 1 +
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 22 ++
tools/perf/util/sort.h | 1 +
5 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 9c7981bfddad..92361a7771f4 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -68,7 +68,7 @@ OPTIONS
--sort=::
Sort histogram entries by given key(s) - multiple keys can be specified
in CSV format. Following sort keys are available:
- pid, comm, dso, symbol, parent, cpu, srcline, weight, local_weight.
+ pid, comm, dso, symbol, parent, cpu, socket, srcline, weight,
local_weight.
Each key has following meaning:
@@ -79,6 +79,7 @@ OPTIONS
- parent: name of function matched to the parent regex filter. Unmatched
entries are displayed as "[other]".
- cpu: cpu number the task ran at the time of sample
+ - socket: processor socket number the task ran at the time of sample
- srcline: filename and line number executed at the time of sample. The
DWARF debugging info must be provided.
- srcfile: file name of the source file of the same. Requires dwarf
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 80c4683b3192..b5440a5b5240 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -144,6 +144,7 @@ void hists__calc_col_len(struct hists *hists, struct
hist_entry *h)
hists__set_unres_dso_col_len(hists, HISTC_MEM_DADDR_DSO);
}
+ hists__new_col_len(hists, HISTC_SOCKET, 6);
hists__new_col_len(hists, HISTC_MEM_LOCKED, 6);
hists__new_col_len(hists, HISTC_MEM_TLB, 22);
hists__new_col_len(hists, HISTC_MEM_SNOOP, 12);
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index de6d58e7f0d5..5d04d28eedd7 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -29,6 +29,7 @@ enum hist_column {
HISTC_COMM,
HISTC_PARENT,
HISTC_CPU,
+ HISTC_SOCKET,
HISTC_SRCLINE,
HISTC_SRCFILE,
HISTC_MISPREDICT,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index a97bceeac0e7..5e4ed1779f6f 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -421,6 +421,27 @@ struct sort_entry sort_cpu = {
.se_width_idx = HISTC_CPU,
};
+/* --sort socket */
+
+static int64_t
+sort__socket_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+ return right->socket - left->socket;
+}
+
+static int hist_entry__socket_snprintf(struct hist_entry *he, char *bf,
+ size_t size, unsigned int width)
+{
+ return repsep_snprintf(bf, size, "%*.*d", width, width-3, he->socket);
+}
+
+struct sort_entry sort_socket = {
+ .se_header = "Socket",
+ .se_cmp = sort__socket_cmp,
+ .se_snprintf= hist_entry__socket_snprintf,
+ .se_width_idx = HISTC_SOCKET,
+};
+
/* sort keys for branch stacks */
static int64_t
@@ -1248,6 +1269,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_SYM, "symbol", sort_sym),
DIM(SORT_PARENT, "parent", sort_parent),
DIM(SORT_CPU, "cpu", sort_cpu),
+ DIM(SORT_SOCKET, "socket", sort_socket),
DIM(SORT_SRCLINE, "srcline", sort_srcline),
DIM(SORT_SRCFILE, "srcfile", sort_srcfile),
DIM(SORT_LOCAL_WEIGHT, "local_weight", sort_local_weight),
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 7cf1cf7d2406..654ac8a2c565 100644
--- a/tools/perf/util/sort.h
+++ b/tools/per
[PATCH 12/15] perf report: Introduce --socket-filter option
From: Kan Liang
Introduce --socket-filter option for 'perf report' to only show entries
for a processor socket that match this filter.
$ perf report --socket-filter 1 --stdio
# To display the perf.data header info, please use --header/--header-only
options.
#
# Total Lost Samples: 0
#
# Samples: 752 of event 'cycles'
# Event count (approx.): 350995599
# Processor Socket: 1
#
# Overhead CommandShared Object Symbol
# . .
#
97.02% test test [.] plusB_c
0.97% test test [.] plusA_c
0.23% swapper[kernel.vmlinux] [k] acpi_idle_do_entry
0.09% rcu_sched [kernel.vmlinux] [k] dyntick_save_progress_counter
0.01% swapper[kernel.vmlinux] [k] task_waking_fair
0.00% swapper[kernel.vmlinux] [k] run_timer_softirq
Signed-off-by: Kan Liang
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1441377946-44429-3-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-report.c | 11 +++
tools/perf/ui/browsers/hists.c | 4
tools/perf/util/hist.c | 16
tools/perf/util/hist.h | 4 +++-
5 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 92361a7771f4..b941d5e07e28 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -350,6 +350,9 @@ include::itrace.txt[]
This option extends the perf report to show reference callgraphs,
which collected by reference event, in no callgraph event.
+--socket-filter::
+ Only report the samples on the processor socket that match with this
filter
+
include::callchain-overhead-calculation.txt[]
SEE ALSO
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index affd70d064bc..4b432453922f 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -62,6 +62,7 @@ struct report {
float min_percent;
u64 nr_entries;
u64 queue_size;
+ int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
@@ -290,6 +291,7 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*hists, struct report
struct perf_evsel *evsel = hists_to_evsel(hists);
char buf[512];
size_t size = sizeof(buf);
+ int socket = hists->socket_filter;
if (symbol_conf.filter_relative) {
nr_samples = hists->stats.nr_non_filtered_samples;
@@ -330,6 +332,10 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*hists, struct report
ret += fprintf(fp, "\n# Sort order : %s", sort_order ? :
default_mem_sort_order);
} else
ret += fprintf(fp, "\n# Event count (approx.): %" PRIu64,
nr_events);
+
+ if (socket > -1)
+ ret += fprintf(fp, "\n# Processor Socket: %d", socket);
+
return ret + fprintf(fp, "\n#\n");
}
@@ -454,6 +460,8 @@ static void report__collapse_hists(struct report *rep)
if (pos->idx == 0)
hists->symbol_filter_str = rep->symbol_filter_str;
+ hists->socket_filter = rep->socket_filter;
+
hists__collapse_resort(hists, &prog);
/* Non-group events are considered as leader */
@@ -639,6 +647,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
},
.max_stack = PERF_MAX_STACK_DEPTH,
.pretty_printing_style = "normal",
+ .socket_filter = -1,
};
const struct option options[] = {
OPT_STRING('i', "input", &input_name, "file",
@@ -751,6 +760,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Show full source file name path for source lines"),
OPT_BOOLEAN(0, "show-ref-call-graph", &symbol_conf.show_ref_callgraph,
"Show callgraph from reference event"),
+ OPT_INTEGER(0, "socket-filter", &report.socket_filter,
+ "only show processor socket that match with this filter"),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cf86f2d3a5e7..457f24c8fbe0 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1261,6 +1261,7 @@ static int hists__browser_title(struct hists *hists,
int printed;
const struct dso *dso = hists->dso_filter;
const struct thread
[PATCH 15/15] perf stat: Move sw clock metrics printout to stat-shadow
From: Andi Kleen
The sw clock metrics printing was missed in the earlier move to
stat-shadow of all the other metric printouts. Move it too.
Signed-off-by: Andi Kleen
Acked-by: Jiri Olsa
Link:
http://lkml.kernel.org/r/1441406717-1717-2-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 9 -
tools/perf/util/stat-shadow.c | 3 +++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a96fb5c3bedb..77e578110194 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -510,15 +510,6 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
-
- if (csv_output || stat_config.interval)
- return;
-
- if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
- fprintf(output, " # %8.3f CPUs utilized ",
- avg / avg_stats(&walltime_nsecs_stats));
- else
- fprintf(output, " ");
}
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 2a5d8d7698ae..625ab3b10e41 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -413,6 +413,9 @@ void perf_stat__print_shadow_stats(FILE *out, struct
perf_evsel *evsel,
ratio = total / avg;
fprintf(out, " # %8.0f cycles / elision ", ratio);
+ } else if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK) &&
+ (ratio = avg_stats(&walltime_nsecs_stats)) != 0) {
+ fprintf(out, " # %8.3f CPUs utilized ", avg / ratio);
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
--
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/
[PATCH 13/15] perf hists browser: Zoom in/out for processor socket
From: Kan Liang
Currently, users can zoom in/out for threads and dso in 'perf top' and
'perf report'.
This patch extends it for the processor sockets.
'S' is the short key to zoom into current Processor Socket.
Signed-off-by: Kan Liang
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1441377946-44429-4-git-send-email-kan.li...@intel.com
[ Made it elide the Socket column when zooming into it, just like with the
other zoom ops,
make it use browser->pstack, to unzoom level by level ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 55 +++---
tools/perf/util/hist.c | 19 +++
tools/perf/util/hist.h | 1 +
3 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 457f24c8fbe0..e4fd40f72b4a 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1429,6 +1429,7 @@ struct popup_action {
struct thread *thread;
struct dso *dso;
struct map_symbol ms;
+ int socket;
int (*fn)(struct hist_browser *browser, struct popup_action *act);
};
@@ -1676,6 +1677,41 @@ add_exit_opt(struct hist_browser *browser __maybe_unused,
return 1;
}
+static int
+do_zoom_socket(struct hist_browser *browser, struct popup_action *act)
+{
+ if (browser->hists->socket_filter > -1) {
+ pstack__remove(browser->pstack, &browser->hists->socket_filter);
+ browser->hists->socket_filter = -1;
+ perf_hpp__set_elide(HISTC_SOCKET, false);
+ } else {
+ browser->hists->socket_filter = act->socket;
+ perf_hpp__set_elide(HISTC_SOCKET, true);
+ pstack__push(browser->pstack, &browser->hists->socket_filter);
+ }
+
+ hists__filter_by_socket(browser->hists);
+ hist_browser__reset(browser);
+ return 0;
+}
+
+static int
+add_socket_opt(struct hist_browser *browser, struct popup_action *act,
+ char **optstr, int socket)
+{
+ if (socket < 0)
+ return 0;
+
+ if (asprintf(optstr, "Zoom %s Processor Socket %d",
+(browser->hists->socket_filter > -1) ? "out of" : "into",
+socket) < 0)
+ return 0;
+
+ act->socket = socket;
+ act->fn = do_zoom_socket;
+ return 1;
+}
+
static void hist_browser__update_nr_entries(struct hist_browser *hb)
{
u64 nr_entries = 0;
@@ -1729,6 +1765,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
"E Expand all callchains\n" \
"F Toggle percentage of filtered entries\n" \
"H Display column headers\n"\
+ "S Zoom into current Processor Socket\n"\
/* help messages are sorted by lexical order of the hotkey */
const char report_help[] = HIST_BROWSER_HELP_COMMON
@@ -1759,7 +1796,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
hist_browser__update_nr_entries(browser);
}
- browser->pstack = pstack__new(2);
+ browser->pstack = pstack__new(3);
if (browser->pstack == NULL)
goto out;
@@ -1778,6 +1815,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
struct thread *thread = NULL;
struct dso *dso = NULL;
int choice = 0;
+ int socket = -1;
nr_options = 0;
@@ -1786,6 +1824,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (browser->he_selection != NULL) {
thread = hist_browser__selected_thread(browser);
dso = browser->selection->map ?
browser->selection->map->dso : NULL;
+ socket = browser->he_selection->socket;
}
switch (key) {
case K_TAB:
@@ -1828,6 +1867,10 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
actions->thread = thread;
do_zoom_thread(browser, actions);
continue;
+ case 'S':
+ actions->socket = socket;
+ do_zoom_socket(browser, actions);
+ continue;
case '/':
if (ui_browser__input_window("Symbol to show",
"Please enter the name of symbol you
want to see",
@@ -1903,9 +1946,11 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
[PATCH 14/15] perf test: Add entry for hists socket filter
From: Kan Liang
Add test case for hists socket filter.
Signed-off-by: Kan Liang
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1441377946-44429-5-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/hists_filter.c | 55 +
1 file changed, 45 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/hists_filter.c b/tools/perf/tests/hists_filter.c
index ce48775e6ada..818acf875dd0 100644
--- a/tools/perf/tests/hists_filter.c
+++ b/tools/perf/tests/hists_filter.c
@@ -16,30 +16,31 @@ struct sample {
struct thread *thread;
struct map *map;
struct symbol *sym;
+ int socket;
};
/* For the numbers, see hists_common.c */
static struct sample fake_samples[] = {
/* perf [kernel] schedule() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_KERNEL_SCHEDULE, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_KERNEL_SCHEDULE, .socket = 0 },
/* perf [perf] main() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_PERF_MAIN, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_PERF_MAIN, .socket = 0 },
/* perf [libc] malloc() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_LIBC_MALLOC, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_LIBC_MALLOC, .socket = 0 },
/* perf [perf] main() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_MAIN, }, /* will be merged
*/
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_MAIN, .socket = 0 }, /*
will be merged */
/* perf [perf] cmd_record() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_CMD_RECORD, },
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_CMD_RECORD, .socket = 1 },
/* perf [kernel] page_fault() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_KERNEL_PAGE_FAULT, },
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_KERNEL_PAGE_FAULT, .socket = 1 },
/* bash [bash] main() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_MAIN, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_MAIN, .socket = 2 },
/* bash [bash] xmalloc() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_XMALLOC, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_XMALLOC, .socket = 2 },
/* bash [libc] malloc() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_LIBC_MALLOC, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_LIBC_MALLOC, .socket = 3 },
/* bash [kernel] page_fault() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_KERNEL_PAGE_FAULT, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_KERNEL_PAGE_FAULT, .socket = 3 },
};
static int add_hist_entries(struct perf_evlist *evlist,
@@ -83,6 +84,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
&sample) < 0)
goto out;
+ al.socket = fake_samples[i].socket;
if (hist_entry_iter__add(&iter, &al,
PERF_MAX_STACK_DEPTH, NULL) <
0) {
addr_location__put(&al);
@@ -253,6 +255,39 @@ int test__hists_filter(void)
TEST_ASSERT_VAL("Unmatched total period for symbol filter",
hists->stats.total_non_filtered_period == 300);
+ /* remove symbol filter first */
+ hists->symbol_filter_str = NULL;
+ hists__filter_by_symbol(hists);
+
+ /* now applying socket filters */
+ hists->socket_filter = 2;
+ hists__filter_by_socket(hists);
+
+ if (verbose > 2) {
+ pr_info("Histogram for socket filters\n");
+ print_hists_out(hists);
+ }
+
+ /* normal stats should be invariant */
+ TEST_ASSERT_VAL("Invalid nr samples",
+ hists->stats.nr_events[PERF_RECORD_SAMPLE] ==
10);
+ TEST_ASSERT_VAL("Invalid nr hist entries",
+ hists->nr_entries == 9);
+ TEST_ASSERT_VAL("Invalid total period",
+ hists->stats.total_period == 1000);
+
+ /* but filter stats are changed */
+ TEST_ASSERT_VAL("Unmatched nr samples for socket filter",
+ hists->stats.nr_non_filtered_samples == 2);
+ TEST_ASSERT_VAL("Unmatched nr hist entries for socket filter",
+ hists->nr_non_filtered_entries == 2);
+ TEST_ASSERT_VAL("Unmatched total period for socket filter",
+ hists->stats.total_non_filtered_period == 200);
+
+ /* remove socket filter first */
+ hists->socket_filter = -1;
+ hists__filter_by_socket(hists);
+
/* now applying all
[PATCH 04/15] perf tests: Print objdump/dso buffers if they don't match
From: Jan Stancek
Signed-off-by: Jan Stancek
Acked-by: Adrian Hunter
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/d0f42f786bc0e965918e0f422df25617a12a4021.1441181335.git.jstan...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 8145c67fb43a..2d21183bd661 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -162,6 +162,18 @@ static int read_via_objdump(const char *filename, u64
addr, void *buf,
return ret;
}
+static void dump_buf(unsigned char *buf, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ pr_debug("0x%02x ", buf[i]);
+ if (i % 16 == 15)
+ pr_debug("\n");
+ }
+ pr_debug("\n");
+}
+
static int read_object_code(u64 addr, size_t len, u8 cpumode,
struct thread *thread, struct state *state)
{
@@ -264,6 +276,10 @@ static int read_object_code(u64 addr, size_t len, u8
cpumode,
/* The results should be identical */
if (memcmp(buf1, buf2, len)) {
pr_debug("Bytes read differ from those read by objdump\n");
+ pr_debug("buf1 (dso):\n");
+ dump_buf(buf1, len);
+ pr_debug("buf2 (objdump):\n");
+ dump_buf(buf2, len);
return -1;
}
pr_debug("Bytes read match those read by objdump\n");
--
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/
[PATCH 10/15] perf tools: Add processor socket info to hist_entry and addr_location
From: Kan Liang
Add processor socket id info in hist_entry and addr_location.
Finor 'perf report', the socket id info is from perf.data.
For others, the socket id info is from current system.
Signed-off-by: Kan Liang
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1441377946-44429-1-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 4
tools/perf/util/event.c | 1 +
tools/perf/util/hist.c | 1 +
tools/perf/util/sort.h | 1 +
tools/perf/util/symbol.h| 1 +
5 files changed, 8 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 62b285e32aa5..affd70d064bc 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -149,6 +149,7 @@ static int process_sample_event(struct perf_tool *tool,
.add_entry_cb = hist_iter__report_callback,
};
int ret = 0;
+ struct perf_env *env = evsel->evlist->env;
if (perf_event__preprocess_sample(event, machine, &al, sample) < 0) {
pr_debug("problem processing %d event, skipping it.\n",
@@ -156,6 +157,9 @@ static int process_sample_event(struct perf_tool *tool,
return -1;
}
+ /* read socket id from perf.data for perf report */
+ al.socket = env->cpu[al.cpu].socket_id;
+
if (rep->hide_unresolved && al.sym == NULL)
goto out_put;
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 7ff61274ed57..0bf8c9889fc0 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1021,6 +1021,7 @@ int perf_event__preprocess_sample(const union perf_event
*event,
al->sym = NULL;
al->cpu = sample->cpu;
+ al->socket = cpu_map__get_socket_id(al->cpu);
if (al->map) {
struct dso *dso = al->map->dso;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 08b6cd945f1e..80c4683b3192 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -452,6 +452,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
.map= al->map,
.sym= al->sym,
},
+ .socket = al->socket,
.cpu = al->cpu,
.cpumode = al->cpumode,
.ip = al->addr,
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 3c2a399f8f5b..7cf1cf7d2406 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -90,6 +90,7 @@ struct hist_entry {
struct comm *comm;
u64 ip;
u64 transaction;
+ s32 socket;
s32 cpu;
u8 cpumode;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 440ba8ae888f..40073c60b83d 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -191,6 +191,7 @@ struct addr_location {
u8filtered;
u8cpumode;
s32 cpu;
+ s32 socket;
};
struct symsrc {
--
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/
[PATCH 02/15] perf tests: Make objdump disassemble zero blocks
From: Jan Stancek Add -z parameter to avoid skipping zero blocks: 816704fe : 816704fe: 7b 34 jnp 81670534 ... 81670501 : 81670501: 0f ba e2 03 bt $0x3,%edx 81670505: 73 11 jae 81670518 Signed-off-by: Jan Stancek Acked-by: Adrian Hunter Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/130c6267fbdb9af506633a9efa06f3269ff5bd2c.1441275982.git.jstan...@redhat.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/code-reading.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c index 38ee90bc2228..c409409d7765 100644 --- a/tools/perf/tests/code-reading.c +++ b/tools/perf/tests/code-reading.c @@ -128,7 +128,7 @@ static int read_via_objdump(const char *filename, u64 addr, void *buf, FILE *f; int ret; - fmt = "%s -d --start-address=0x%"PRIx64" --stop-address=0x%"PRIx64" %s"; + fmt = "%s -z -d --start-address=0x%"PRIx64" --stop-address=0x%"PRIx64" %s"; ret = snprintf(cmd, sizeof(cmd), fmt, "objdump", addr, addr + len, filename); if (ret <= 0 || (size_t)ret >= sizeof(cmd)) -- 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/
[PATCH 03/15] perf tests: Stop reading if objdump output crossed sections
From: Jan Stancek
objdump output can span across multiple sections:
Disassembly of section .text:
0008 :
8: 48 89 e5mov%rsp,%rbp
b: 53 push %rbx
c: 8b 01 mov(%rcx),%eax
6b: 90 nop
Disassembly of section .init.text:
0008 :
8: 00 00 add%al,(%rax)
a: 00 00 add%al,(%rax)
c: 48 89 e5
Stop further reading if an address starts going backwards, assuming we
crossed sections.
Signed-off-by: Jan Stancek
Acked-by: Adrian Hunter
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/9d1ea95e5f9884fdff1be6f761a2feabef37412c.1441181335.git.jstan...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index c409409d7765..8145c67fb43a 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -79,7 +79,7 @@ static int read_objdump_output(FILE *f, void *buf, size_t
*len, u64 start_addr)
size_t line_len, off_last = 0;
ssize_t ret;
int err = 0;
- u64 addr;
+ u64 addr, last_addr = start_addr;
while (off_last < *len) {
size_t off, read_bytes, written_bytes;
@@ -101,6 +101,11 @@ static int read_objdump_output(FILE *f, void *buf, size_t
*len, u64 start_addr)
if (sscanf(line, "%"PRIx64, &addr) != 1)
continue;
+ if (addr < last_addr) {
+ pr_debug("addr going backwards, read beyond
section?\n");
+ break;
+ }
+ last_addr = addr;
/* copy it from temporary buffer to 'buf' according
* to address on current objdump line */
--
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/
[PATCH 07/15] tools lib api fs: Remove debugfs, tracefs and findfs objects
From: Jiri Olsa
We have all the functionality in fs.c, let's remove unneeded
objects.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Raphael Beamonte
Cc: Steven Rostedt
Link:
http://lkml.kernel.org/r/1441180605-24737-15-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/api/fs/Build | 3 --
tools/lib/api/fs/debugfs.c | 77 -
tools/lib/api/fs/debugfs.h | 23 --
tools/lib/api/fs/findfs.c | 63 -
tools/lib/api/fs/findfs.h | 23 --
tools/lib/api/fs/tracefs.c | 78 --
tools/lib/api/fs/tracefs.h | 21 -
7 files changed, 288 deletions(-)
delete mode 100644 tools/lib/api/fs/debugfs.c
delete mode 100644 tools/lib/api/fs/debugfs.h
delete mode 100644 tools/lib/api/fs/findfs.c
delete mode 100644 tools/lib/api/fs/findfs.h
delete mode 100644 tools/lib/api/fs/tracefs.c
delete mode 100644 tools/lib/api/fs/tracefs.h
diff --git a/tools/lib/api/fs/Build b/tools/lib/api/fs/Build
index fa726f679b29..f4ed9629ae85 100644
--- a/tools/lib/api/fs/Build
+++ b/tools/lib/api/fs/Build
@@ -1,5 +1,2 @@
libapi-y += fs.o
libapi-y += tracing_path.o
-libapi-y += debugfs.o
-libapi-y += findfs.o
-libapi-y += tracefs.o
diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
deleted file mode 100644
index c707cfb32782..
--- a/tools/lib/api/fs/debugfs.c
+++ /dev/null
@@ -1,77 +0,0 @@
-#define _GNU_SOURCE
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "debugfs.h"
-#include "tracefs.h"
-
-#ifndef DEBUGFS_DEFAULT_PATH
-#define DEBUGFS_DEFAULT_PATH "/sys/kernel/debug"
-#endif
-
-char debugfs_mountpoint[PATH_MAX + 1] = DEBUGFS_DEFAULT_PATH;
-
-static const char * const debugfs_known_mountpoints[] = {
- DEBUGFS_DEFAULT_PATH,
- "/debug",
- 0,
-};
-
-static bool debugfs_found;
-
-bool debugfs_configured(void)
-{
- return debugfs_find_mountpoint() != NULL;
-}
-
-/* find the path to the mounted debugfs */
-const char *debugfs_find_mountpoint(void)
-{
- const char *ret;
-
- if (debugfs_found)
- return (const char *)debugfs_mountpoint;
-
- ret = find_mountpoint("debugfs", (long) DEBUGFS_MAGIC,
- debugfs_mountpoint, PATH_MAX + 1,
- debugfs_known_mountpoints);
- if (ret)
- debugfs_found = true;
-
- return ret;
-}
-
-/* mount the debugfs somewhere if it's not mounted */
-char *debugfs_mount(const char *mountpoint)
-{
- /* see if it's already mounted */
- if (debugfs_find_mountpoint())
- goto out;
-
- /* if not mounted and no argument */
- if (mountpoint == NULL) {
- /* see if environment variable set */
- mountpoint = getenv(PERF_DEBUGFS_ENVIRONMENT);
- /* if no environment variable, use default */
- if (mountpoint == NULL)
- mountpoint = DEBUGFS_DEFAULT_PATH;
- }
-
- if (mount(NULL, mountpoint, "debugfs", 0, NULL) < 0)
- return NULL;
-
- /* save the mountpoint */
- debugfs_found = true;
- strncpy(debugfs_mountpoint, mountpoint, sizeof(debugfs_mountpoint));
-out:
- return debugfs_mountpoint;
-}
diff --git a/tools/lib/api/fs/debugfs.h b/tools/lib/api/fs/debugfs.h
deleted file mode 100644
index 455023698d2b..
--- a/tools/lib/api/fs/debugfs.h
+++ /dev/null
@@ -1,23 +0,0 @@
-#ifndef __API_DEBUGFS_H__
-#define __API_DEBUGFS_H__
-
-#include "findfs.h"
-
-#ifndef DEBUGFS_MAGIC
-#define DEBUGFS_MAGIC 0x64626720
-#endif
-
-#ifndef PERF_DEBUGFS_ENVIRONMENT
-#define PERF_DEBUGFS_ENVIRONMENT "PERF_DEBUGFS_DIR"
-#endif
-
-bool debugfs_configured(void);
-const char *debugfs_find_mountpoint(void);
-char *debugfs_mount(const char *mountpoint);
-
-extern char debugfs_mountpoint[];
-
-int debugfs__strerror_open(int err, char *buf, size_t size, const char
*filename);
-int debugfs__strerror_open_tp(int err, char *buf, size_t size, const char
*sys, const char *name);
-
-#endif /* __API_DEBUGFS_H__ */
diff --git a/tools/lib/api/fs/findfs.c b/tools/lib/api/fs/findfs.c
deleted file mode 100644
index 49946cb6d7af..
--- a/tools/lib/api/fs/findfs.c
+++ /dev/null
@@ -1,63 +0,0 @@
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "findfs.h"
-
-/* verify that a mountpoint is actually the type we want */
-
-int valid_mountpoint(const char *mount, long magic)
-{
- struct statfs st_fs;
-
- if (statfs(mount, &st_fs) < 0)
- return -ENOENT;
- else if ((long)st_fs.f_type != magic)
- return -ENOENT;
-
- return 0;
-}
-
-/* find the path to a mounted file system */
-const char *find_mountpoint(const c
[PATCH 05/15] tools lib api fs: Make tracing_path_strerror_open message generic
From: Jiri Olsa
Making tracing_path__strerror_open_tp message generic by mentioning both
debugfs/tracefs words in error message plus the tracing_path instead of
debugfs_mountpoint.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Raphael Beamonte
Cc: Steven Rostedt
Link:
http://lkml.kernel.org/r/1441180605-24737-7-git-send-email-jo...@kernel.org
[ Add comment for the ENOENT case out of this patch discussion thread ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/api/fs/tracing_path.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c
index 3b3e4f5fc50b..1e0bb0da5e4f 100644
--- a/tools/lib/api/fs/tracing_path.c
+++ b/tools/lib/api/fs/tracing_path.c
@@ -90,33 +90,39 @@ static int strerror_open(int err, char *buf, size_t size,
const char *filename)
switch (err) {
case ENOENT:
- if (debugfs_configured()) {
+ /*
+* We will get here if we can't find the tracepoint, but one of
+* debugfs or tracefs is configured, which means you probably
+* want some tracepoint which wasn't compiled in your kernel.
+* - jirka
+*/
+ if (debugfs_configured() || tracefs_configured()) {
snprintf(buf, size,
"Error:\tFile %s/%s not found.\n"
"Hint:\tPerhaps this kernel misses some
CONFIG_ setting to enable this feature?.\n",
-debugfs_mountpoint, filename);
+tracing_events_path, filename);
break;
}
snprintf(buf, size, "%s",
-"Error:\tUnable to find debugfs\n"
-"Hint:\tWas your kernel compiled with debugfs
support?\n"
-"Hint:\tIs the debugfs filesystem mounted?\n"
+"Error:\tUnable to find debugfs/tracefs\n"
+"Hint:\tWas your kernel compiled with debugfs/tracefs
support?\n"
+"Hint:\tIs the debugfs/tracefs filesystem mounted?\n"
"Hint:\tTry 'sudo mount -t debugfs nodev
/sys/kernel/debug'");
break;
case EACCES: {
- const char *mountpoint = debugfs_mountpoint;
+ const char *mountpoint = debugfs_find_mountpoint();
- if (!access(debugfs_mountpoint, R_OK) && strncmp(filename,
"tracing/", 8) == 0) {
+ if (!access(mountpoint, R_OK) && strncmp(filename, "tracing/",
8) == 0) {
const char *tracefs_mntpoint =
tracefs_find_mountpoint();
if (tracefs_mntpoint)
- mountpoint = tracefs_mntpoint;
+ mountpoint = tracefs_find_mountpoint();
}
snprintf(buf, size,
"Error:\tNo permissions to read %s/%s\n"
"Hint:\tTry 'sudo mount -o remount,mode=755 %s'\n",
-debugfs_mountpoint, filename, mountpoint);
+tracing_events_path, filename, mountpoint);
}
break;
default:
@@ -131,7 +137,7 @@ int tracing_path__strerror_open_tp(int err, char *buf,
size_t size, const char *
{
char path[PATH_MAX];
- snprintf(path, PATH_MAX, "tracing/events/%s/%s", sys, name ?: "*");
+ snprintf(path, PATH_MAX, "%s/%s", sys, name ?: "*");
return strerror_open(err, buf, size, path);
}
--
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] Staging: rtl18192u: fix style issues in ieee80211_softmac_wx.c
On Fri, Sep 04, 2015 at 11:00:06PM +, Mike Dupuis wrote: > This is a patch to the ieee80211_softmac_wx.c file that corrects several > checkpatch.pl warnings and errors. > Signed-off-by: Mike Dupuis You need a blank line before the signed-off-by line. Also, please break this up into multiple patches, each one only doing one type of cleanup. As it is, I can't take it, sorry. thanks, greg k-h -- 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 01/15] perf tests: Take into account address of each objdump line
From: Jan Stancek
objdump output can contain repeated bytes. At the moment test reads all
output sequentially, assuming each address is represented in output only
once:
8164efb3 :
8164efb3: c1 5d 00 ebrcrl $0xeb,0x0(%rbp)
8164efb7: 00 4c 8b 5cadd%cl,0x5c(%rbx,%rcx,4)
8164efb8 :
8164efb8: 4c 8b 5c 24 30 mov0x30(%rsp),%r11
8164efbd: 4c 8b 54 24 38 mov0x38(%rsp),%r10
Store objdump output to buffer according to offset calculated from
address on each line.
Signed-off-by: Jan Stancek
Cc: Adrian Hunter
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/ad13289a55d6350f7717757c7e32c2d4286402bd.1441181335.git.jstan...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 51 ++---
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 39c784a100a9..38ee90bc2228 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -33,20 +33,20 @@ static unsigned int hex(char c)
return c - 'A' + 10;
}
-static void read_objdump_line(const char *line, size_t line_len, void **buf,
- size_t *len)
+static size_t read_objdump_line(const char *line, size_t line_len, void *buf,
+ size_t len)
{
const char *p;
- size_t i;
+ size_t i, j = 0;
/* Skip to a colon */
p = strchr(line, ':');
if (!p)
- return;
+ return 0;
i = p + 1 - line;
/* Read bytes */
- while (*len) {
+ while (j < len) {
char c1, c2;
/* Skip spaces */
@@ -65,20 +65,26 @@ static void read_objdump_line(const char *line, size_t
line_len, void **buf,
if (i < line_len && line[i] && !isspace(line[i]))
break;
/* Store byte */
- *(unsigned char *)*buf = (hex(c1) << 4) | hex(c2);
- *buf += 1;
- *len -= 1;
+ *(unsigned char *)buf = (hex(c1) << 4) | hex(c2);
+ buf += 1;
+ j++;
}
+ /* return number of successfully read bytes */
+ return j;
}
-static int read_objdump_output(FILE *f, void **buf, size_t *len)
+static int read_objdump_output(FILE *f, void *buf, size_t *len, u64 start_addr)
{
char *line = NULL;
- size_t line_len;
+ size_t line_len, off_last = 0;
ssize_t ret;
int err = 0;
+ u64 addr;
+
+ while (off_last < *len) {
+ size_t off, read_bytes, written_bytes;
+ unsigned char tmp[BUFSZ];
- while (1) {
ret = getline(&line, &line_len, f);
if (feof(f))
break;
@@ -87,9 +93,28 @@ static int read_objdump_output(FILE *f, void **buf, size_t
*len)
err = -1;
break;
}
- read_objdump_line(line, ret, buf, len);
+
+ /* read objdump data into temporary buffer */
+ read_bytes = read_objdump_line(line, ret, tmp, sizeof(tmp));
+ if (!read_bytes)
+ continue;
+
+ if (sscanf(line, "%"PRIx64, &addr) != 1)
+ continue;
+
+ /* copy it from temporary buffer to 'buf' according
+* to address on current objdump line */
+ off = addr - start_addr;
+ if (off >= *len)
+ break;
+ written_bytes = MIN(read_bytes, *len - off);
+ memcpy(buf + off, tmp, written_bytes);
+ off_last = off + written_bytes;
}
+ /* len returns number of bytes that could not be read */
+ *len -= off_last;
+
free(line);
return err;
@@ -120,7 +145,7 @@ static int read_via_objdump(const char *filename, u64 addr,
void *buf,
return -1;
}
- ret = read_objdump_output(f, &buf, &len);
+ ret = read_objdump_output(f, buf, &len, addr);
if (len) {
pr_debug("objdump read too few bytes\n");
if (!ret)
--
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: Regression: can't apply frequency offsets above 1000ppm.
On Fri, Sep 4, 2015 at 5:57 PM, John Stultz wrote: > On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar wrote: >> On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote: >>> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote: >>> > And just installing chrony from the feeds. With any kernel from 3.17 >>> > you'll have wrong estimates at chronyc sourcestats. >>> >>> Wrong estimates? Could you be more specific about what the failure >>> you're seeing is here? The >>> >>> I installed the image above, which comes with a 4.1.6 kernel, and >>> chrony seems to have gotten my BBB into ~1ms sync w/ servers over the >>> internet fairly quickly (at least according to chronyc tracking). >> >> To see the bug with chronyd the initial offset shouldn't be very close >> to zero, so it's forced to correct the offset by adjusting the >> frequency in a larger step. >> >> I'm attaching a simple C program that prints the frequency offset >> as measured between the REALTIME and MONOTONIC_RAW clocks when the >> adjtimex tick is set to 9000. It should show values close to -10 >> ppm and I suspect on the BBB it will be much smaller. > > So I spent some time on this late last night and this afternoon. > > It was a little odd because things don't seem totally broken, but > something isn't quite right. > > Digging around it seems the iterative logrithmic approximation done in > timekeeping_freqadjust() wasn't working right. Instead of making > smaller order alternating positive and negative adjustments, it was > doing strange growing adjustments for the same value that wern't large > enough to actually correct things very quickly. This made it much > slower to adapt to specified frequency values. > > The odd bit, is it seems to come down to: > tick_error = abs(tick_error); > > Haven't chased down why yet, but apparently abs() isn't doing what one > would think when passed a s64 value. Well.. chasing it down wasn't hard.. from include/linux/kernel.h: /* * abs() handles unsigned and signed longs, ints, shorts and chars. For all * input types abs() returns a signed long. * abs() should not be used for 64-bit types (s64, u64, long long) - use abs64() * for those. */ Ouch. -john -- 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: Regression: can't apply frequency offsets above 1000ppm.
On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar wrote:
> On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote:
>> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote:
>> > And just installing chrony from the feeds. With any kernel from 3.17
>> > you'll have wrong estimates at chronyc sourcestats.
>>
>> Wrong estimates? Could you be more specific about what the failure
>> you're seeing is here? The
>>
>> I installed the image above, which comes with a 4.1.6 kernel, and
>> chrony seems to have gotten my BBB into ~1ms sync w/ servers over the
>> internet fairly quickly (at least according to chronyc tracking).
>
> To see the bug with chronyd the initial offset shouldn't be very close
> to zero, so it's forced to correct the offset by adjusting the
> frequency in a larger step.
>
> I'm attaching a simple C program that prints the frequency offset
> as measured between the REALTIME and MONOTONIC_RAW clocks when the
> adjtimex tick is set to 9000. It should show values close to -10
> ppm and I suspect on the BBB it will be much smaller.
So I spent some time on this late last night and this afternoon.
It was a little odd because things don't seem totally broken, but
something isn't quite right.
Digging around it seems the iterative logrithmic approximation done in
timekeeping_freqadjust() wasn't working right. Instead of making
smaller order alternating positive and negative adjustments, it was
doing strange growing adjustments for the same value that wern't large
enough to actually correct things very quickly. This made it much
slower to adapt to specified frequency values.
The odd bit, is it seems to come down to:
tick_error = abs(tick_error);
Haven't chased down why yet, but apparently abs() isn't doing what one
would think when passed a s64 value.
Anyway, the attached patch seems to improve things for me. If you can
confirm it resolves things for you I'll run it through some additional
testing after the (long holiday) weekend is over and try to get the
fix pushed out.
Thanks again for the issue report!
-john
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index bca3667..81dc975 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1586,7 +1586,7 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk,
s64 interval = tk->cycle_interval;
s64 xinterval = tk->xtime_interval;
s64 tick_error;
- bool negative;
+ bool negative = 0;
u32 adj;
/* Remove any current error adj from freq calculation */
@@ -1604,10 +1604,12 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk,
return;
/* preserve the direction of correction */
- negative = (tick_error < 0);
+ if (tick_error < 0) {
+ tick_error = -tick_error;
+ negative = 1;
+ }
/* Sort out the magnitude of the correction */
- tick_error = abs(tick_error);
for (adj = 0; tick_error > interval; adj++)
tick_error >>= 1;
Re: [PATCH] spmi-pmic-arb: support configurable number of peripherals
On 09/04, Gilad Avidov wrote:
> On Thu, 3 Sep 2015 17:16:30 -0700
> Stephen Boyd wrote:
>
> > On 09/03, Gilad Avidov wrote:
> > > + supported by HW. Default (minimum
> > > supported) is 128. +
> > > +Example V1 PMIC-Arbiter:
> > >
> > > spmi {
> > > compatible = "qcom,spmi-pmic-arb";
> > > @@ -62,4 +66,32 @@ Example:
> > >
> > > interrupt-controller;
> > > #interrupt-cells = <4>;
> > > +
> > > + qcom,max-peripherals = <256>;
> >
> > If it's v1 isn't it always 128? So having 256 here is just
> > confusing.
>
> Hi Stephen,
>
> Actually some v1 chipsets, such as Dragonboard APQ8074, support 256
> peripherals.
Then the commit text should be updated. It only mentions that v2
HW has sub-versions which support more than 128.
>
> >
> > > + };
> > > +
> > > @@ -129,14 +131,15 @@ struct spmi_pmic_arb_dev {
> > > u8 channel;
> > > int irq;
> > > u8 ee;
> > > - u8 min_apid;
> > > - u8 max_apid;
> > > - u32
> > > mapping_table[SPMI_MAPPING_TABLE_LEN];
> > > + u16 min_irq_apid;
> > > + u16 max_irq_apid;
> > > + u16 max_apid;
> > > + u32 *mapping_table;
> > > struct irq_domain *domain;
> > > struct spmi_controller *spmic;
> > > - u16 apid_to_ppid[256];
> > > + u16 *irq_apid_to_ppid;
> >
> > Please drop all this renaming noise, or at the least, put it in a
> > different patch. More than half the patch is just changing the
> > names of these variables for what seems like no reason.
> >
>
> Regarding the change of max/min_apid to max/min_irq_apid:
> max_apid was already used but the name does not make good sense. Since
> really it is not the max_apid supported. Instead it is the largest apid
> which interrupt is currently requested for. But now we need a value that
> is actually the maximum supported apid. This is why repurposed max_apid
> and corrected the previous naming.
max_apid in this patch is only used in probe, so there's no need
for that variable to be a member of the structure. Meaning we can
leave max_apid alone and call this new variable max_periphs or
something like that and leave it local to the probe function.
>
> > > const struct pmic_arb_ver_ops *ver_ops;
> > > - u8 *ppid_to_chan;
> > > + u16 *ppid_to_chan;
> > > };
> > >
> > > struct spmi_pmic_arb_dev *pa = irq_get_handler_data(irq);
> > > struct irq_chip *chip = irq_get_chip(irq);
> > > void __iomem *intr = pa->intr;
> > > - int first = pa->min_apid >> 5;
> > > - int last = pa->max_apid >> 5;
> > > + int first = pa->min_irq_apid >> 5;
> > > + int last = pa->max_irq_apid >> 5;
> > > u32 status;
> > > int i, id;
> > >
> > > @@ -903,14 +915,30 @@ static int spmi_pmic_arb_probe(struct
> > > platform_device *pdev)
> > > pa->ee = ee;
> > >
> > > - for (i = 0; i < ARRAY_SIZE(pa->mapping_table); ++i)
> > > - pa->mapping_table[i] = readl_relaxed(
> > > - pa->cnfg +
> > > SPMI_MAPPING_TABLE_REG(i));
> > > + pa->irq_apid_to_ppid = devm_kzalloc(&ctrl->dev,
> > > pa->max_apid *
> > > +
> > > sizeof(*pa->irq_apid_to_ppid),
> > > + GFP_KERNEL);
> > > + if (!pa->irq_apid_to_ppid) {
> > > + err = -ENOMEM;
> > > + goto err_put_ctrl;
> > > + }
> > > +
> > > + pa->mapping_table = devm_kzalloc(&ctrl->dev,
> > > + (pa->max_apid - 1) *
> > > sizeof(u32),
> > > + GFP_KERNEL);
> > > + if (!pa->mapping_table) {
> > > + err = -ENOMEM;
> > > + goto err_put_ctrl;
> > > + }
> > > +
> > > + for (i = 0; i < (pa->max_apid - 1); ++i)
> > > + pa->mapping_table[i] = readl_relaxed(pa->cnfg +
> > > +
> > > SPMI_MAPPING_TABLE_REG(i));
>
> > we're searching through the mapping table we can cache the value
> > from the register if the entry isn't 0. This delays the
>
> Greedy approach (reading upto 512 registers from hw) have very small
> upfront penalty since sequential reads take place very fast
> and HW acceleration (prefetching) will improve it. A lazy approach will
> required much more complex algorithm (for example any value
> including zero is valid. So we will need to augment a marker for
> unassigned entries) and prefetching will not help.
That's solvable with a bitmap of 512 entries, not too much of a
complicated algorithm.
We're sort of screwed now that we have to find the channel for a
ppid by reading X number of PMIC_ARB_REG_CHNL registers. We could
lazily do that too though, where we fill in the array linearly
with what we read until we find the ppid we're looking for. We
would need to do a bitmap trick again, but since we know ppid is
at most going to use 12 bits, we can set the highest bit to
indicate the ppid_to_chan entry is valid.
MY BELOVED FRIEND IN THE LORD, PLEASE VIEW THE ATTACHED FILE AND GET BACK TO ME URGENTLY.
PLEASE GET BACK TO ME AS SOON AS POSSIBLE. MY BELOVED FRIEND IN THE LORD..docx Description: MS-Word 2007 document
Re: [PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote: > Russell, > > On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux > wrote: > >> In your case you're probably making the value that Linux > >> asked you to make, AKA 25.175000 MHz. > > > > ... which is the spec value. > > This is where we're not on the same page. Where in the spec does it > say 25.17500 MHz? I see in the spec: > 25.2 / 1.001 Section 4 of CEA-861-B, which defines the video clock rates and their accuracy of 0.5%. > ...and this is a crucial difference here. Please double-check my math, but: > > (25175000 * 4576) / (128 * 32000.) > => 28125.1953125 > > (25174825 * 4576) / (128 * 32000.) > => 28125.0 > > This calculation is what led to my belief that the goal here is to > make an integral CTS. If you have 25.175 MHZ clock and N of 4576 you > _will not_ have an integral CTS. If you instead have 25.174825 MHz > clock and N of 4576 you _will_ have an integral CTS. Right, but 25.175 is close enough to 25.174825. Do this calculation: 25175000 * 4576 / 28125 / 128 That'll give you the resulting audio sample rate, which is 32000.222Hz. That's an error of... 0.00069%, which is probably around the typical error of your average crystal oscillator. Really not worth bothering with. > Said another way: > > 1. The reason 25174825 Hz has a different N is to make an integral CTS. > > 2. If you are indeed making 25175000 then there is no need for a > different N to make an integral CTS > > 3. If you use 4576 for N but you're making 25175000 Hz, you end up in > a _worse_ position than if you use the standard 4096 for N. Total rubbish. Sorry, but it is. Follow the code. Pixel clock is 25175000. For 32kHz, N will be 4576. 25175000 * 4576 = 1.152008e11. Divide that by the audio clock rate (128 * 32000) gives 28125.19531. Since we're using integer division, that gets rounded down to 28125. DRM uses a clock rate of "25175" to represent 25.2/1.001 modes. So, if your hardware sets a video clock rate of 25.2MHz/1.001, then you end up with a sample rate of exactly 32kHz. If you set exactly 25.175MHz, you end up with an approximate 32kHz sample rate - one which is 0.00069% in error, which is (excluse the language) fuck all different from exactly 32kHz. Are you _really_ going to continue arguing over a 0.00069% error? If you are, I'm not going to listen anymore - it's soo damned small that it's not worth bothering with. At all. The only time that you'd need to worry about it is if you wanted a super-accurate system, and for that you'd need an atomic clock to source your system clocks to reduce aging effects, temperature induced drift, etc, maybe locking the atomic clock to a national frequency standard like the Anthorn MSF 60kHz transmitter signal broadcast by the UK National Physics Laboratory. > >> As a first step I'd suggest just removing all the special cases and > >> add a comment. From real world testing it doesn't seem terribly > >> critical to be slightly off on CTS. ...and in any case for any clock > >> rates except the small handful in the HDMI spec we'll be slightly off > >> on CTS anyway... > > > > They're not "special cases" made up to fit something - they're from the > > tables in the HDMI specification. > > They are definitely "special cases". There is a general rule in the > code you posted (aim for 128 * freq) and these are cases for certain > clocks that are an exception to the general rule. AKA they are > special cases. Sorry, I disagree with you. > > That assumes that the audio and video clocks are coherent. On iMX6 > > hardware using this, the audio is clocked at the rate defined by the > > TDMS clock and the CTS/N values. > > I'll admit I haven't looked at the audio section of dw_hdmi much, but > I'd imagine that for all users of this controller / PHY the audio and > video clocks are coherent. Not if the audio clock comes from an I2S master rather than being sourced from the HDMI block. > I think in the perfect world we'd be able to generate exactly > 25174825.174825177 Hz and we'd use all the rates from the HDMI spec. To generate something of that accuracy, you'd need something like a caesium fountain atomic clock. > and we'd get spot on 32 kHz audio. ...but I'm simply saying that > we're not in that perfect world yet. > > Also note that there are many many rates not in the HDMI spec that > could benefit from similar optimization of trying to adjust N to make > an integral CTS. Now go and look at the HDMI spec, where it gives the CTS value for 74.25/1.001 for 32kHz. That can't be represented by an integer CTS value, so using this hardware, we can't generate that sample rate without an error. We'd use a fixed CTS value of 210937 instead, which works out at a 0.00024% error. Again, not worth worrying about. > > --- > > As a side note: I realized one part of the HDMI spec that isn't trying > to make an integral value but still uses a different value for N: 297 > MHz. From the
Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program
On Fri, Sep 04, 2015 at 04:08:53PM -0700, Andy Lutomirski wrote: > On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen > wrote: > > On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: > >> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen > >> wrote: > >> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: > >> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > >> >> wrote: > >> >> > This commit adds a way to dump eBPF programs. The initial > >> >> > implementation > >> >> > doesn't support maps, and therefore only allows dumping seccomp ebpf > >> >> > programs which themselves don't currently support maps. > >> >> > > >> >> > We export the GPL bit as well as a unique ID for the program so that > >> >> > >> >> This unique ID appears to be the heap address for the prog. That's a > >> >> huge leak, and should not be done. We don't want to introduce new > >> >> kernel address leaks while we're trying to fix the remaining ones. > >> >> Shouldn't the "unique ID" be the fd itself? I imagine KCMP_FILE > >> >> could be used, for example. > >> > > >> > No; we acquire the fd per process, so if a task installs a filter and > >> > then forks N times, we'll grab N (+1) copies of the filter from N (+1) > >> > different file descriptors. Ideally, we'd have some way to figure out > >> > that these were all the same. Some sort of prog_id is one way, > >> > although there may be others. > >> > >> I disagree a bit. I think we want the actual hierarchy to be a > >> well-defined thing, because I have plans to make the hierarchy > >> actually do something. That means that we'll need to have a more > >> exact way to dump the hierarchy than "these two filters are identical" > >> or "these two filters are not identical". > > > > Can you elaborate on what this would look like? I think with the > > "these two filters are the same" primitive (the same in the sense that > > they were inherited during a fork, not just that > > memcmp(filter1->insns, filter2->insns) == 0) you can infer the entire > > hierarchy, however clunky it may be to do so. > > > > Another issue is that KCMP_FILE won't work in this case, as it > > effectively compares the struct file *, which will be different since > > we need to call anon_inode_getfd() for each call of > > ptrace(PTRACE_SECCOMP_GET_FILTER_FD). We could add a KCMP_BPF (or just > > a KCMP_FILE_PRIVATE_DATA, since that's effectively what it would be). > > Does that make sense? [added Cyrill] > > > > I don't really know what it would look like. I think we want a way to > compare struct seccomp_filter pointers. Not to complicate things further, but this brings up another interesting issue. Right now, we require PT_SUSPEND_SECCOMP in order to restore seccomp and do things afterwards (otherwise the seccomp filters might kill whatever things the restore process is doing). If we want the struct seccomp_filter pointers to be identical on restore, that means we need to restore when we are real root, because bpf() requires that we be real root. This means that we essentially need to ptrace the entire restore, which we don't want to do. In order to work around this, I was thinking we could change the ancestry check slightly: diff --git a/kernel/seccomp.c b/kernel/seccomp.c index 9c6bea6..efc3f36 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -239,7 +239,7 @@ static int is_ancestor(struct seccomp_filter *parent, if (parent == NULL) return 1; for (; child; child = child->prev) - if (child == parent) + if (child->prog == parent->prog) return 1; return 0; } so that we can do bpf() when we're real root, and just restore seccomp at the very end. This would mean that the struct bpf_prog pointers are shared, but the struct seccomp_filter pointers aren't. Even assuming we have some sort of way to identify shared ancestry, we still need something like the above in order to be able to restore it. This sort of sucks; it would be ideal to to share struct seccomp_filter *s too. We could do something like seccomp(COPY_FROM_PARENT) or something, but given the struggles Kees told me he had with getting SECCOMP_FILTER_FLAG_TSYNC right, I suspect that won't fly. > FWIW, I *hate* kcmp. It might be worth trying to come up with a less > awful way to do this. For example, what if we could generate a kcmpfd > such that each kcmpfd contains (internally) a random symmetric key? > We could have a function that would return kernel pointers encrypted > by that key. We could do what Kees is proposing for struct bpf_prog and just keep a globally unique id on struct seccomp_filter, and allow asking for that via some seccomp(GET_ID, fd) over the same fd we're using to dump the bpf prog. That doesn't solve our restore problem, though. Tycho > Of course, then we need to make sure that no one ever tries to keep a > kcmpfd around long enough that CRIU needs to checkpoint it, because > that's impossible. > > Grr
Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program
On Fri, Sep 4, 2015 at 4:27 PM, Kees Cook wrote: > On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen > wrote: >> On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: >>> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen >>> wrote: >>> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: >>> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen >>> >> wrote: >>> >> > This commit adds a way to dump eBPF programs. The initial >>> >> > implementation >>> >> > doesn't support maps, and therefore only allows dumping seccomp ebpf >>> >> > programs which themselves don't currently support maps. >>> >> > >>> >> > We export the GPL bit as well as a unique ID for the program so that >>> >> >>> >> This unique ID appears to be the heap address for the prog. That's a >>> >> huge leak, and should not be done. We don't want to introduce new >>> >> kernel address leaks while we're trying to fix the remaining ones. >>> >> Shouldn't the "unique ID" be the fd itself? I imagine KCMP_FILE >>> >> could be used, for example. >>> > >>> > No; we acquire the fd per process, so if a task installs a filter and >>> > then forks N times, we'll grab N (+1) copies of the filter from N (+1) >>> > different file descriptors. Ideally, we'd have some way to figure out >>> > that these were all the same. Some sort of prog_id is one way, >>> > although there may be others. >>> >>> I disagree a bit. I think we want the actual hierarchy to be a >>> well-defined thing, because I have plans to make the hierarchy >>> actually do something. That means that we'll need to have a more >>> exact way to dump the hierarchy than "these two filters are identical" >>> or "these two filters are not identical". >> >> Can you elaborate on what this would look like? I think with the >> "these two filters are the same" primitive (the same in the sense that >> they were inherited during a fork, not just that >> memcmp(filter1->insns, filter2->insns) == 0) you can infer the entire >> hierarchy, however clunky it may be to do so. >> >> Another issue is that KCMP_FILE won't work in this case, as it >> effectively compares the struct file *, which will be different since >> we need to call anon_inode_getfd() for each call of >> ptrace(PTRACE_SECCOMP_GET_FILTER_FD). We could add a KCMP_BPF (or just >> a KCMP_FILE_PRIVATE_DATA, since that's effectively what it would be). >> Does that make sense? [added Cyrill] > > If KCMP_FILE_PRIVATE_DATA isn't desired, I think a global counter id > is the next best. The problem is that you can't checkpoint and restore it. We could have a counter relative to the parent filter, though. --Andy > > -Kees > > -- > Kees Cook > Chrome OS Security -- Andy Lutomirski AMA Capital Management, LLC -- 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/
[GIT PULL for v4.3-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.3-1 For the media subsystem patches for Kernel 4.3. This series contain: - New DVB frontend drivers: ascot2e, cxd2841er, horus3a, lnbh25; - New HDMI capture driver: tc358743; - New driver for NetUP DVB new boards (netup_unidvb); - IR support for DVBSky cards (smipcie-ir); - Coda driver has gain macroblock tiling support; - Renesas R-Car gains JPEG codec driver; - New DVB platform driver for STi boards: c8sectpfe; - Added documentation for the media core kABI to device-drivers DocBook; - Lots of driver fixups, cleanups and improvements. Thanks! Mauro - The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.3-1 for you to fetch changes up to 50ef28a6ac216fd8b796257a3768fef8f57b917d: [media] c8sectpfe: Remove select on undefined LIBELF_32 (2015-09-03 14:10:06 -0300) media updates for v4.3-rc1 Abhilash Jindal (2): [media] zoran: Use monotonic time [media] bt8xxx: Use monotonic time Andrzej Pietrasiewicz (1): [media] s5p-jpeg: Eliminate double kfree() Antonio Borneo (1): [media] s5c73m3: Remove redundant spi driver bus initialization Antti Palosaari (11): [media] em28xx: remove unused a8293 SEC config [media] a8293: remove legacy media attach [media] a8293: use i2c_master_send / i2c_master_recv for I2C I/O [media] a8293: improve LNB register programming logic [media] a8293: coding style issues [media] tda10071: remove legacy media attach [media] tda10071: rename device state struct to dev [media] tda10071: convert to regmap I2C API [media] tda10071: protect firmware command exec with mutex [media] tda10071: do not get_frontend() when not ready [media] tda10071: implement DVBv5 statistics Ben Dooks (1): [media] media: adv7180: add of match table Benoit Parrot (2): [media] media: am437x-vpfe: Requested frame size and fmt overwritten by current sensor setting [media] media: am437x-vpfe: Fix a race condition during release Christian Löpke (1): [media] Technisat SkyStar USB HD,(DVB-S/S2) too much URBs for arm devices Damian Hobson-Garcia (1): [media] v4l: vsp1: Align crop rectangle to even boundary for YUV formats Dan Carpenter (2): [media] gspca: sn9c2028: remove an unneeded condition [media] v4l: xilinx: missing error code David Härdeman (5): [media] rc-core: fix remove uevent generation [media] rc-core: use an IDA rather than a bitmap [media] rc-core: remove the LIRC "protocol" [media] lmedm04: NEC scancode cleanup [media] rc-core: improve the lirc protocol reporting Ezequiel Garcia (3): [media] stk1160: Reduce driver verbosity [media] stk1160: Add frame scaling support [media] tw68: Move PCI vendor and device IDs to pci_ids.h Fabian Frederick (6): [media] v4l2-dv-timings: use swap() in v4l2_calc_aspect_ratio() [media] wl128x: use swap() in fm_rdsparse_swapbytes() [media] saa7146: use swap() in sort_and_eliminate() [media] saa6588: use swap() in saa6588_i2c_poll() [media] btcx-risc: use swap() in btcx_sort_clips() [media] ttusb-dec: use swap() in swap_bytes() Fabien Dessenne (3): [media] bdisp: composing support [media] bdisp: add debug info for RGB24 format [media] bdisp: fix debug info memory access Fabio Estevam (2): [media] mantis: Fix error handling in mantis_dma_init() [media] c8sectpfe: Use %pad to print 'dma_addr_t' Fengguang Wu (1): [media] i2c: fix platform_no_drv_owner.cocci warnings Geert Uytterhoeven (4): [media] adv7604/cobalt: Allow compile test if !GPIOLIB [media] dvb-frontends: Make all DVB Frontends visible if COMPILE_TEST=y [media] i2c: Make all i2c devices visible if COMPILE_TEST=y [media] tuners: Make all TV tuners visible if COMPILE_TEST=y Hans Verkuil (60): [media] stk1160: fix sequence handling [media] rc/Kconfig: fix indentation problem [media] v4l2-dv-timings: log if the timing is reduced blanking V2 [media] clock-sh7724.c: fix sh-vou clock identifier [media] sh-vou: use resource managed calls [media] sh-vou: fix querycap support [media] sh-vou: use v4l2_fh [media] sh-vou: support compulsory G/S/ENUM_OUTPUT ioctls [media] sh-vou: fix incorrect initial pixelformat [media] sh-vou: replace g/s_crop/cropcap by g/s_selection [media] sh-vou: let sh_vou_s_fmt_vid_out call sh_vou_try_fmt_vid_out [media] sh-vou: fix bytesperline [media] sh-vou: convert to vb2 [media] sh-vou: add support f
Re: [PATCH 2/2] rcu: Fix up timeouts for forcing the quiescent state
On Fri, Sep 04, 2015 at 02:11:30PM +0200, Petr Mladek wrote:
> The deadline to force the quiescent state (jiffies_force_qs) is currently
> updated only when the previous timeout passed. But the timeout used for
> wait_event() is always the entire original timeout. This is strange.
They tell me that kthreads aren't supposed to every catch signals,
hence the WARN_ON() in the early-exit case stray-signal case.
In the case where we were awakened with an explicit force-quiescent-state
request, we do the scan, and then wait the full time for the next scan.
So the point of the delay is to space out the scans, not to fit a
pre-determined schedule.
The reason we get awakened with an explicit force-quiescent-state
request is that a given CPU just got inundated with RCU callbacks
or that rcutorture wants to hammer this code path.
So I am not seeing this as anything in need of fixing.
Am I missing something subtle here?
Thanx, Paul
> First, we might miss the deadline if we wait after a spurious wake up
> or after sleeping in cond_resched() because we wait too long.
>
> Second, we might do another forcing too early if the previous forcing
> was done earlier because of RCU_GP_FLAG_FQS and we later get a spurious
> wake up. IMHO, we should reset the deadline in this case.
>
> This patch updates the deadline "jiffies_force_qs" right after forcing
> the quiescent state by rcu_gp_fqs().
>
> Also it updates the remaining timeout according to the current jiffies and
> the requested deadline.
>
> It moves the cond_resched_rcu_qs() to a single place. It changes the order
> of the check for the pending signal. But there never should be a pending
> signal. If there was we would have bigger problems because wait_event()
> would never sleep again until someone flushed the signal.
>
> I have found these problems when trying to understand the code. I do not
> have any reproducer. I think that it is hardly visible because
> the spurious wakeup is rather theoretical.
>
> Signed-off-by: Petr Mladek
> ---
> kernel/rcu/tree.c | 77
> ++-
> 1 file changed, 53 insertions(+), 24 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 54af8d5f9f7b..aaeeabcba545 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2035,13 +2035,45 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
> }
>
> /*
> + * Normalize, update, and return the first timeout.
> + */
> +static unsigned long normalize_jiffies_till_first_fqs(void)
> +{
> + unsigned long j = jiffies_till_first_fqs;
> +
> + if (unlikely(j > HZ)) {
> + j = HZ;
> + jiffies_till_first_fqs = HZ;
> + }
> +
> + return j;
> +}
> +
> +/*
> + * Normalize, update, and return the first timeout.
> + */
> +static unsigned long normalize_jiffies_till_next_fqs(void)
> +{
> + unsigned long j = jiffies_till_next_fqs;
> +
> + if (unlikely(j > HZ)) {
> + j = HZ;
> + jiffies_till_next_fqs = HZ;
> + } else if (unlikely(j < 1)) {
> + j = 1;
> + jiffies_till_next_fqs = 1;
> + }
> +
> + return j;
> +}
> +
> +/*
> * Body of kthread that handles grace periods.
> */
> static int __noreturn rcu_gp_kthread(void *arg)
> {
> int gf;
> - unsigned long j;
> - int ret;
> + unsigned long timeout, j;
> struct rcu_state *rsp = arg;
> struct rcu_node *rnp = rcu_get_root(rsp);
>
> @@ -2071,22 +2103,18 @@ static int __noreturn rcu_gp_kthread(void *arg)
>
> /* Handle quiescent-state forcing. */
> rsp->fqs_state = RCU_SAVE_DYNTICK;
> - j = jiffies_till_first_fqs;
> - if (j > HZ) {
> - j = HZ;
> - jiffies_till_first_fqs = HZ;
> - }
> - ret = 0;
> + timeout = normalize_jiffies_till_first_fqs();
> + rsp->jiffies_force_qs = jiffies + timeout;
> for (;;) {
> - if (!ret)
> - rsp->jiffies_force_qs = jiffies + j;
> trace_rcu_grace_period(rsp->name,
> READ_ONCE(rsp->gpnum),
> TPS("fqswait"));
> rsp->gp_state = RCU_GP_WAIT_FQS;
> - ret = wait_event_interruptible_timeout(rsp->gp_wq,
> - rcu_gp_fqs_check_wake(rsp, &gf), j);
> + wait_event_interruptible_timeout(rsp->gp_wq,
> + rcu_gp_fqs_check_wake(rsp, &gf),
> + timeout);
> rsp->gp_state = RCU_GP_DOING_FQS;
> +try_again:
> /* Locking provides needed memory barriers. */
> /* If grace period done, leave loop. */
> if (!READ_ONCE(rnp->qsm
Re: [PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
Russell, On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux wrote: >> Basically the spec is saying that you want both N and CTS to be >> integral. ...as you say you really want: >> CTS = (TMDS * N) / (128 * audio_freq) > > In the case of software-programmed CTS and N values, they have to be > integral because there's no such thing as fractional division here. > The CTS and N values get sent across the HDMI link to the sink, and > they use those in a PLL like arrangement to derive the audio clock. > > More "inteligent" hardware automatically measures the CTS number and > continually updates the sink, which allows the sink to remain in > sync with the audio at non-coherent rates. > >> ...CTS has no other restrictions (other than being integral) and >> you're allowed a bit of slop for N (you aim for 128 * audio_freq but >> can go up or down a bit). > > No. Both CTS and N have to be accurate to generate the correct > sample rate from the TDMS clock. I guess by "other" I meant no restrictions other than that, which is listed above that "CTS = (TMDS * N) / (128 * audio_freq)". Anyway, sounds like we're on the same page here... >> Apparently it's more important to optimize for the CTS formula working >> out then it is for getting close to "128 * audio freq". ...and that's >> the reason for these special case N values... > > The "128 * audio freq" is just a recommendation. Going through the HDMI > spec's recommended values for various clock rates and sample rates > reveals that quite a number of them are far from this "recommendation". > > So I wouldn't read too much into the "128 * audio freq" thing. Again, same page. >> So to put some numbers: >> >> We're perfect when we have exactly 25.2: >> 25200 * 4096 / (128 * 32) >> => 25200, so CTS for 25.2 MHz is 25200. Perfect >> >> ...but when we have 25.2 / 1.001 we get a non-integral CTS: >> (25200 / 1.001) * 4096 / (128 * 32) >> => 25174.82517482518 >> >> ...we can get an integral CTS and still remain in range if: >> (25200 / 1.001) * 4576 / (128 * 32) >> => 28125 > > Correct. These are the values given in the HDMI specification for each > of your clock rates you mention above. > > You can even use 4096 for N _provided_ the source measures and sends > the CTS value (that's basically what happens in the case of > "non-coherent" clocks.) > >> In the case of Linux, I'm afraid we just don't have this type of >> accuracy in our APIs. > > We don't have that kind of precision in the DRM API, but we do have the > precision in the clock API. Yup. On the same page. See my suggestions of using the common clock framework. >> The spec is talking about making 25.17482517482518 MHz. > > +/- 0.5%, according to CEA-861-B. > >> As I said, in my case I'm actually making 25170732. > > ... which is within 0.02%, so is within spec. Yup, that's why we're doing it. Note that total jitter has to be under +/- 0.5% right? ...so if you've got error here you've got to make sure your clock is extra clean I think. >> In your case you're probably making the value that Linux >> asked you to make, AKA 25.175000 MHz. > > ... which is the spec value. This is where we're not on the same page. Where in the spec does it say 25.17500 MHz? I see in the spec: 25.2 / 1.001 ...and this is a crucial difference here. Please double-check my math, but: (25175000 * 4576) / (128 * 32000.) => 28125.1953125 (25174825 * 4576) / (128 * 32000.) => 28125.0 This calculation is what led to my belief that the goal here is to make an integral CTS. If you have 25.175 MHZ clock and N of 4576 you _will not_ have an integral CTS. If you instead have 25.174825 MHz clock and N of 4576 you _will_ have an integral CTS. Said another way: 1. The reason 25174825 Hz has a different N is to make an integral CTS. 2. If you are indeed making 25175000 then there is no need for a different N to make an integral CTS 3. If you use 4576 for N but you're making 25175000 Hz, you end up in a _worse_ position than if you use the standard 4096 for N. >> Unsurprisingly, if you do the >> calculations with 25.175 MHz (or any integral kHz value) you don't >> have to do any special optimization to stay integral: >> >> 25175 * 4096 / (128 * 32) >> => 25175 >> >> >> So unless you have some way to know that the underlying clock is >> actually (25.2 / 1.001) MHz and not just 25.175 MHz then your patch >> looks wrong. > > I don't believe you can make that statement. If you wish to take the > lack of precision up with the authors of the CEA-861 and HDMI > specifications, since they "approximate" to the values I have in this > patch, and are what userspace passes in the mode structures to kernel > space. I will repeat my mantra: I'm a visitor here and decidedly not an expert. However, from my reading of the HDMI spec shows that the spec itself is fine. They are just assuming that you're providing a 25.174825 MHz clock and giving you optimized values for said clock. If the current driver says
Re: [3.13.y-ckt stable] Linux 3.13.11-ckt26
diff --git a/Makefile b/Makefile
index 964e360..aa8e2b6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 13
SUBLEVEL = 11
-EXTRAVERSION = -ckt25
+EXTRAVERSION = -ckt26
NAME = King of Alienated Frog Porn
# *DOCUMENTATION*
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8a1b5e0..f1a4cea 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2444,6 +2444,9 @@ static int of_dev_hwmod_lookup(struct device_node *np,
* registers. This address is needed early so the OCP registers that
* are part of the device's address space can be ioremapped properly.
*
+ * If SYSC access is not needed, the registers will not be remapped
+ * and non-availability of MPU access is not treated as an error.
+ *
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
*/
@@ -2458,6 +2461,11 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data,
_save_mpu_port_index(oh);
+ /* if we don't need sysc access we don't need to ioremap */
+ if (!oh->class->sysc)
+ return 0;
+
+ /* we can't continue without MPU PORT if we need sysc access */
if (oh->_int_flags & _HWMOD_NO_MPU_PORT)
return -ENXIO;
@@ -2467,8 +2475,10 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data,
oh->name);
/* Extract the IO space from device tree blob */
- if (!np)
+ if (!np) {
+ pr_err("omap_hwmod: %s: no dt node\n", oh->name);
return -ENXIO;
+ }
va_start = of_iomap(np, index + oh->mpu_rt_idx);
} else {
@@ -2527,13 +2537,11 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh->name, np->name);
}
- if (oh->class->sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r < 0) {
- WARN(1, "omap_hwmod: %s: doesn't have mpu register
target base\n",
-oh->name);
- return 0;
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r < 0) {
+ WARN(1, "omap_hwmod: %s: doesn't have mpu register target
base\n",
+oh->name);
+ return 0;
}
r = _init_clocks(oh, NULL);
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 74c9172..bdb3ecf 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1146,7 +1146,7 @@ static void __init load_hv_initrd(void)
void __init free_initrd_mem(unsigned long begin, unsigned long end)
{
- free_bootmem(__pa(begin), end - begin);
+ free_bootmem_late(__pa(begin), end - begin);
}
static int __init setup_initrd(char *str)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 3f88561..3898595 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -561,6 +561,10 @@ static efi_status_t setup_e820(struct boot_params *params,
unsigned int e820_type = 0;
unsigned long m = efi->efi_memmap;
+#ifdef CONFIG_X86_64
+ m |= (u64)efi->efi_memmap_hi << 32;
+#endif
+
d = (efi_memory_desc_t *)(m + (i * efi->efi_memdesc_size));
switch (d->type) {
case EFI_RESERVED_TYPE:
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fa6ade7..2cbc2f2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -480,6 +480,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+ unsigned char dummy;
ptep = lookup_address((unsigned long)v, &level);
BUG_ON(ptep == NULL);
@@ -489,6 +490,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte = pfn_pte(pfn, prot);
+ /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables. We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space. In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall. We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution,
Re: [Adi-buildroot-devel] [Consult] blackfin: About one building break issue for STACKTRACE
On 9/3/15 11:05, Chen Gang wrote: > On 4/17/15 22:02, Chen Gang wrote: >> On 4/17/15 11:02, Zhang, Sonic wrote: >>> Hi Gang, >>> >>> Please only use the GCC for Blackfin 2013R1 or 2014R1 from >>> https://sourceforge.net/projects/adi-buildroot/files/ . Upstream GCC5 isn't >>> ported to Blackfin properly. >>> After a simply trying, I guess, this issue is not quite difficult to be fixed. - The current gcc 'think', our current usage is incorrect. - But the original gcc 'think', our current usage is OK. - The related commits is "e52beba PR debug/54694" in gcc git repo. I shall try to consult the gcc related members for it, so we can make sure whether we need fix our code or the new gcc need be fixed. Thanks. > > I shall try to merge the 2014R1 to the latest gcc upstream to support > the related feature in my free time. > > I hope I can finish within 2 months (although I am not quite sure -- > maybe need 3 months or more). > > Welcome any related ideas, suggestions and completions. > > Thanks. > >> >> OK, thank you very much for your reply. :-) >> >> >> For me, I want to let gcc5 support Blackfin properly, but sorry, at >> present I can not. >> >> - In honest, I am still not quite familiar with gcc (although I am >>trying and improving). >> >> - This year, I have no enough time resource for it (I am mainly for >>upstream qemu this year). >> >> But if next year, upstream gcc is still not ported to Blackfin properly, >> I shall try. >> >> However, there are still several another issues for upstream blackfin >> gcc5 (they are all coredumps), I should still try to analyze them and >> find root causes, hope I can finish within this month. >> >> >> Thanks. >> > -- Chen Gang (陈刚) Open, share, and attitude like air, water, and life which God blessed -- 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/
[3.13.y-ckt stable] Linux 3.13.11-ckt26
I am announcing the release of the Linux 3.13.11-ckt26 kernel. The updated 3.13.y-ckt tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y and can be browsed at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.13.y The diff from v3.13.11-ckt25 is posted as a follow-up to this email. The 3.13.y-ckt extended stable tree is maintained by the Canonical Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Kamal -- Makefile | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 24 ++--- arch/tile/kernel/setup.c | 2 +- arch/x86/boot/compressed/eboot.c | 4 ++ arch/x86/xen/enlighten.c | 40 +++ block/blk-cgroup.c | 6 ++- drivers/ata/libata-core.c | 11 +++-- drivers/ata/libata-pmp.c | 7 +++ drivers/ata/libata-scsi.c | 3 +- drivers/gpu/drm/drm_crtc.c | 5 +- drivers/gpu/drm/radeon/radeon_combios.c| 7 ++- drivers/input/touchscreen/usbtouchscreen.c | 3 ++ drivers/isdn/gigaset/ser-gigaset.c | 11 - drivers/md/md.c| 2 +- drivers/md/raid1.c | 2 +- drivers/mmc/card/block.c | 2 + drivers/mmc/host/omap_hsmmc.c | 8 +-- drivers/mmc/host/sdhci-esdhc.h | 2 +- drivers/mmc/host/sdhci-pxav3.c | 1 + drivers/net/bonding/bond_main.c| 14 -- drivers/net/ethernet/mellanox/mlx4/eq.c| 4 +- drivers/net/ethernet/sun/niu.c | 4 +- drivers/scsi/ipr.c | 28 +++ drivers/scsi/ipr.h | 1 + drivers/target/iscsi/iscsi_target.c| 48 ++ drivers/target/iscsi/iscsi_target_core.h | 1 + drivers/target/iscsi/iscsi_target_login.c | 43 ++-- drivers/target/iscsi/iscsi_target_login.h | 3 +- drivers/target/iscsi/iscsi_target_nego.c | 34 - drivers/usb/dwc3/ep0.c | 4 ++ drivers/usb/gadget/mv_udc_core.c | 2 +- drivers/usb/host/ohci-q.c | 7 +-- drivers/usb/host/xhci-hub.c| 22 ++--- drivers/usb/host/xhci-mem.c| 2 +- drivers/usb/host/xhci-ring.c | 3 ++ drivers/usb/host/xhci.c| 3 ++ drivers/usb/host/xhci.h| 1 + drivers/usb/storage/unusual_devs.h | 12 + drivers/vhost/vhost.c | 1 + fs/xfs/xfs_attr_remote.c | 15 -- include/linux/libata.h | 2 + net/bridge/br_mdb.c| 2 +- net/core/datagram.c| 41 ++-- net/ipv4/ip_fragment.c | 7 ++- net/mac80211/debugfs_netdev.c | 1 + net/netfilter/ipvs/ip_vs_core.c| 16 +- net/netfilter/ipvs/ip_vs_ctl.c | 78 +++--- net/netfilter/ipvs/ip_vs_sched.c | 12 ++--- net/netfilter/ipvs/ip_vs_sync.c| 2 +- net/netfilter/ipvs/ip_vs_xmit.c| 1 - net/netfilter/nf_conntrack_expect.c| 3 +- net/netfilter/nf_conntrack_netlink.c | 5 -- net/sched/act_pedit.c | 5 +- sound/pci/hda/patch_cirrus.c | 4 +- sound/pci/hda/patch_hdmi.c | 2 + sound/pci/hda/patch_realtek.c | 2 +- sound/pci/hda/patch_sigmatel.c | 3 +- sound/soc/codecs/pcm1681.c | 2 +- sound/usb/mixer_maps.c | 24 + 59 files changed, 444 insertions(+), 162 deletions(-) AMAN DEEP (1): usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function Aaron Plattner (1): ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda Alan Stern (1): USB: OHCI: Fix race between ED unlink and URB submission Aleksei Mamlin (1): libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER Alex Deucher (1): drm/radeon/combios: add some validation of lvds values Alexey Khoroshilov (1): usb: gadget: mv_udc_core: fix phy_regs I/O memory leak Andy Lutomirski (1): x86/xen: Probe target addresses in set_aliased_prot() before the hypercall Arne Fitzenreiter (2): libata: add ATA_HORKAGE_NOTRIM libata: force disable trim for SuperSSpeed S238 Axel Lin (1): ASoC: pcm1681: Fix setting de-emphasis sampling rate selection Benjamin Randazzo (1): md: use kzalloc() when bitmap is disabled Bernhard Bender (1): Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen Brian Campbell (1): xhci: Calculate old endpoints correctly on device reset Brian King (3): ipr: Fix locking for unit attention handling ipr: Fix incorrect trace indexing ipr: Fix invalid array indexing for H
Linux Plumbers 2016 Call for Organizers
Each year, the Linux Foundation's Technical Advisory Board (TAB) seeks an organizing committee for the annual Linux Plumbers Conference; that process has now begun for the 2016 event. This is your chance to put your stamp on one of our community's most important gatherings in a year when we will be celebrating 25 years of the Linux kernel. In a change from recent years, the Linux Plumbers Conference will not be colocated with a LinuxCon event; instead, it will be held alongside the annual Kernel Summit in Santa Fe, New Mexico, USA. The timing of the event is expected to be the week of October 31st to November 4th, and we have selected a suitable venue. Interested groups should have, at a minimum, an events coordinator, a treasurer, a program committee chair and a chairperson. This group must be able to take the initiative to handle conference-specific details (including social events, the miniconf program, and more) while working with the Linux Foundation to ensure that logistics work smoothly. The process for putting in an application to run the Linux Plumbers Conference is documented here: https://wiki.linuxfoundation.org/en/LPC Applications should be in by October 5th; the TAB then will announce a decision by (at the latest) October 26th. If you're interested in submitting a proposal, but are concerned that you don't know enough about how previous Plumbers has been run, then fear not! The TAB will support the selected organizing committee with additional volunteers with past Plumbers organizing experience. Above all we are looking for a capable and enthusiastic group who we can work with to make the 2016 Linux Plumbers Conference a great success. If you have any questions about the submission process, please email the TAB at tech-bo...@lists.linux-foundation.org. -- 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/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 08:26:18PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Sep 04, 2015 at 08:25:47PM -0300, Arnaldo Carvalho de Melo escreveu: > > > One more fixed, see below, now we have another, using ESC should remove > > > the last applied Zoom operation, just like for the other Zoom operations > > > (DSO, thread, etc), looking at that now. > > > > Fixed, see below, to test, press S, then d to zoom into Socket then DSO > > and then press ESC to unzoom one level (the DSO in this case) then ESC > > again, to unzoom the Socket one. > > > > If you use the left arrow key it will be equivalent to ESC, but we'll > > repurpose the left/right arrows for horizontal scrolling soon. > > > Ooops, here it is: Ok, I have all updated and pushed to my perf/core branch, please take a look/test. - 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 3/6] ebpf: add a way to dump an eBPF program
On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen wrote: > On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: >> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen >> wrote: >> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: >> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen >> >> wrote: >> >> > This commit adds a way to dump eBPF programs. The initial implementation >> >> > doesn't support maps, and therefore only allows dumping seccomp ebpf >> >> > programs which themselves don't currently support maps. >> >> > >> >> > We export the GPL bit as well as a unique ID for the program so that >> >> >> >> This unique ID appears to be the heap address for the prog. That's a >> >> huge leak, and should not be done. We don't want to introduce new >> >> kernel address leaks while we're trying to fix the remaining ones. >> >> Shouldn't the "unique ID" be the fd itself? I imagine KCMP_FILE >> >> could be used, for example. >> > >> > No; we acquire the fd per process, so if a task installs a filter and >> > then forks N times, we'll grab N (+1) copies of the filter from N (+1) >> > different file descriptors. Ideally, we'd have some way to figure out >> > that these were all the same. Some sort of prog_id is one way, >> > although there may be others. >> >> I disagree a bit. I think we want the actual hierarchy to be a >> well-defined thing, because I have plans to make the hierarchy >> actually do something. That means that we'll need to have a more >> exact way to dump the hierarchy than "these two filters are identical" >> or "these two filters are not identical". > > Can you elaborate on what this would look like? I think with the > "these two filters are the same" primitive (the same in the sense that > they were inherited during a fork, not just that > memcmp(filter1->insns, filter2->insns) == 0) you can infer the entire > hierarchy, however clunky it may be to do so. > > Another issue is that KCMP_FILE won't work in this case, as it > effectively compares the struct file *, which will be different since > we need to call anon_inode_getfd() for each call of > ptrace(PTRACE_SECCOMP_GET_FILTER_FD). We could add a KCMP_BPF (or just > a KCMP_FILE_PRIVATE_DATA, since that's effectively what it would be). > Does that make sense? [added Cyrill] If KCMP_FILE_PRIVATE_DATA isn't desired, I think a global counter id is the next best. -Kees -- Kees Cook Chrome OS Security -- 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/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 08:25:47PM -0300, Arnaldo Carvalho de Melo escreveu:
> > One more fixed, see below, now we have another, using ESC should remove
> > the last applied Zoom operation, just like for the other Zoom operations
> > (DSO, thread, etc), looking at that now.
>
> Fixed, see below, to test, press S, then d to zoom into Socket then DSO
> and then press ESC to unzoom one level (the DSO in this case) then ESC
> again, to unzoom the Socket one.
>
> If you use the left arrow key it will be equivalent to ESC, but we'll
> repurpose the left/right arrows for horizontal scrolling soon.
>
Ooops, here it is:
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 67d40feb1880..e4fd40f72b4a 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1681,11 +1681,13 @@ static int
do_zoom_socket(struct hist_browser *browser, struct popup_action *act)
{
if (browser->hists->socket_filter > -1) {
+ pstack__remove(browser->pstack, &browser->hists->socket_filter);
browser->hists->socket_filter = -1;
perf_hpp__set_elide(HISTC_SOCKET, false);
} else {
browser->hists->socket_filter = act->socket;
perf_hpp__set_elide(HISTC_SOCKET, true);
+ pstack__push(browser->pstack, &browser->hists->socket_filter);
}
hists__filter_by_socket(browser->hists);
@@ -1794,7 +1796,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
hist_browser__update_nr_entries(browser);
}
- browser->pstack = pstack__new(2);
+ browser->pstack = pstack__new(3);
if (browser->pstack == NULL)
goto out;
@@ -1944,9 +1946,11 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
* Ditto for thread below.
*/
do_zoom_dso(browser, actions);
- }
- if (top == &browser->hists->thread_filter)
+ } else if (top == &browser->hists->thread_filter) {
do_zoom_thread(browser, actions);
+ } else if (top == &browser->hists->socket_filter) {
+ do_zoom_socket(browser, actions);
+ }
continue;
}
case 'q':
--
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/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 08:06:21PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Sep 04, 2015 at 07:52:55PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Sep 04, 2015 at 07:41:39PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Sep 04, 2015 at 10:45:43AM -0400, kan.li...@intel.com escreveu: > > > > From: Kan Liang > > > > > > > > This patch enable perf report to sort by processor socket > > > > > > > > $ perf report --stdio --sort socket,comm,dso,symbol > > > > # To display the perf.data header info, please use > > > > --header/--header-only options. > > > > # > > > > # > > > > # Total Lost Samples: 0 > > > > # > > > > # Samples: 686 of event 'cycles' > > > > # Event count (approx.): 349215462 > > > > # > > > > # Overhead SOCKET CommandShared Object Symbol > > > > # .. . > > > > . > > > > > > So this works in 'perf top' only for the first screen rendering, when it > > > refreshes we lose the "SOCKET" header (why all caps?) and the colum > > > stops being %03d and instead becomes %d, I am checking now. > > > > Patch below fix this, but we stumble in another problem, when zooming it > > is not eliding the SOCKET column, i.e. if we're zooming into a column, > > it will have the same value for all entries, no use in showing it, save > > some columns, will check that as well. > > > > Will fold the fixes to the patches where the problems were introduced, > > the feature is cool, one more zoom! :-) > > One more fixed, see below, now we have another, using ESC should remove > the last applied Zoom operation, just like for the other Zoom operations > (DSO, thread, etc), looking at that now. Fixed, see below, to test, press S, then d to zoom into Socket then DSO and then press ESC to unzoom one level (the DSO in this case) then ESC again, to unzoom the Socket one. If you use the left arrow key it will be equivalent to ESC, but we'll repurpose the left/right arrows for horizontal scrolling soon. - 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 1/2] rcu: Show the real fqs_state
On Fri, Sep 04, 2015 at 02:11:29PM +0200, Petr Mladek wrote:
> The value of "fqs_state" in struct rcu_state is always RCU_GP_IDLE.
>
> The real state is stored in a local variable in rcu_gp_kthread().
> It is modified by rcu_gp_fqs() via parameter and return value.
> But the actual value is never stored to rsp->fqs_state.
>
> The result is that print_one_rcu_state() does not show the real
> state.
>
> This code has been added 3 years ago by the commit 4cdfc175c25c89ee
> ("rcu: Move quiescent-state forcing into kthread"). I guess that it
> was an overlook or optimization.
>
> Anyway, the value seems to be manipulated only by the thread, except
> for shoving the status. I do not see any risk in updating it directly
> in the struct.
>
> Signed-off-by: Petr Mladek
Good catch, but how about the following fix instead?
Thanx, Paul
rcu: Finish folding ->fqs_state into ->gp_state
Commit commit 4cdfc175c25c89ee ("rcu: Move quiescent-state forcing
into kthread") started the process of folding the old ->fqs_state
into ->gp_state, but did not complete it. This situation does not
cause any malfunction, but can result in extremely confusing trace
output. This commit completes this task of eliminating ->fqs_state
in favor of ->gp_state.
Reported-by: Petr Mladek
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 69ab7ce2cf7b..04234936d897 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -97,7 +97,7 @@ struct rcu_state sname##_state = { \
.level = { &sname##_state.node[0] }, \
.rda = &sname##_data, \
.call = cr, \
- .fqs_state = RCU_GP_IDLE, \
+ .gp_state = RCU_GP_IDLE, \
.gpnum = 0UL - 300UL, \
.completed = 0UL - 300UL, \
.orphan_lock = __RAW_SPIN_LOCK_UNLOCKED(&sname##_state.orphan_lock), \
@@ -1949,16 +1949,15 @@ static bool rcu_gp_fqs_check_wake(struct rcu_state
*rsp, int *gfp)
/*
* Do one round of quiescent-state forcing.
*/
-static int rcu_gp_fqs(struct rcu_state *rsp, int fqs_state_in)
+static void rcu_gp_fqs(struct rcu_state *rsp)
{
- int fqs_state = fqs_state_in;
bool isidle = false;
unsigned long maxj;
struct rcu_node *rnp = rcu_get_root(rsp);
WRITE_ONCE(rsp->gp_activity, jiffies);
rsp->n_force_qs++;
- if (fqs_state == RCU_SAVE_DYNTICK) {
+ if (rsp->gp_state == RCU_SAVE_DYNTICK) {
/* Collect dyntick-idle snapshots. */
if (is_sysidle_rcu_state(rsp)) {
isidle = true;
@@ -1967,7 +1966,7 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
force_qs_rnp(rsp, dyntick_save_progress_counter,
&isidle, &maxj);
rcu_sysidle_report_gp(rsp, isidle, maxj);
- fqs_state = RCU_FORCE_QS;
+ rsp->gp_state = RCU_FORCE_QS;
} else {
/* Handle dyntick-idle and offline CPUs. */
isidle = true;
@@ -1981,7 +1980,6 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
READ_ONCE(rsp->gp_flags) & ~RCU_GP_FLAG_FQS);
raw_spin_unlock_irq(&rnp->lock);
}
- return fqs_state;
}
/*
@@ -2045,7 +2043,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
/* Declare grace period done. */
WRITE_ONCE(rsp->completed, rsp->gpnum);
trace_rcu_grace_period(rsp->name, rsp->completed, TPS("end"));
- rsp->fqs_state = RCU_GP_IDLE;
+ rsp->gp_state = RCU_GP_IDLE;
rdp = this_cpu_ptr(rsp->rda);
/* Advance CBs to reduce false positives below. */
needgp = rcu_advance_cbs(rsp, rnp, rdp) || needgp;
@@ -2063,7 +2061,6 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
*/
static int __noreturn rcu_gp_kthread(void *arg)
{
- int fqs_state;
int gf;
unsigned long j;
int ret;
@@ -2095,7 +2092,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
}
/* Handle quiescent-state forcing. */
- fqs_state = RCU_SAVE_DYNTICK;
+ rsp->gp_state = RCU_SAVE_DYNTICK;
j = jiffies_till_first_fqs;
if (j > HZ) {
j = HZ;
@@ -2123,7 +2120,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
trace_rcu_grace_period(rsp->name,
READ_ONCE(rsp->gpnum),
TPS("fqsstart"));
- fqs_state = rcu_gp_fqs(rsp, fqs_state);
+ rcu_gp_fqs(rsp);
trace_rcu_grace_period(rsp->name,
READ_ONCE(rsp->gpnum),
Re: [PATCH net] openvswitch: Remove conntrack Kconfig option.
On Fri, Sep 4, 2015 at 1:07 PM, Joe Stringer wrote:
> There's no particular desire to have conntrack action support in Open
> vSwitch as an independently configurable bit, rather just to ensure
> there is not a hard dependency. This exposed option doesn't accurately
> reflect the conntrack dependency when enabled, so simplify this by
> removing the option. Compile the support if NF_CONNTRACK is enabled.
>
> Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
> Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
--
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/
DMARC from google posts...
Just FYI, because google.com postings seem to be using DMARC now, significant segments of the internet are not receiving your postings and instead they are all bouncing back to postmaster. This includes all subscribers under hotmail, comcast, etc. You may want to let google's mail group know that this is happening. And well, I kinda expected this to happen when anyone turns on DMARC output and checking, it makes mailing lists completely unusable. This is generating a significant amount of boucnes every time a google employee posts to any mailing list at vger. And I do not have too many options of my own to address this situation. My personal choices are: 1) Ban posters from sites that generate DMARC. 2) Unsubscribe every site that enforces DMARC. Neither is desirable. However, I can't let this go on for much longer and something is going to have to give. Given how mailing lists basically stop working as a result, I really don't think turning on DMARC at all is a really smart idea, personally. Thanks. -- 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: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')
05.09.2015 01:46, Raymond Jennings пишет: On 09/04/15 14:30, Stas Sergeev wrote: 05.09.2015 00:16, Stas Sergeev пишет: I agree. vm86() is a mess. My point is that its risky parts and useless funtionality is _already_ known (even I can point to the particular code parts than can simply be removed). As such, it simply had to be re-visited and cleaned up to match at least 1 and 3 (and then maybe 5). This wasn't done, and the knob was introduced _instead_ of doing this. Grr, I mean it was disabled by default instead of doing this, and the knob was only proposed, not added. You can't just pull vm86 out of the kernel anyway. dosemu is a userspace application that depends on it, so pulling this feature out would be a big fat regression, period. I would personally rather not hear about how "it's a legacy program so its userbase is shrinking" used as any sort of excuse to ignore the fact that we shouldn't break userspace. I can even say as a user that vm86 is important to me. By all means, cleaning up vm86 is a good idea. But removing it or fencing it off with a strong deprecation doesn't sound like the right idea. Yes, that's what I was saying lengthy. Fencing it off may help those who does not use it, and that's what most people here worry about. BUT it will also do a big harm to those who uses it, unless done properly like for modify_ldt(), or *sigh* just with mmap_min_addr. -- 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 3/6] ebpf: add a way to dump an eBPF program
On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen wrote: > On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: >> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen >> wrote: >> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: >> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen >> >> wrote: >> >> > This commit adds a way to dump eBPF programs. The initial implementation >> >> > doesn't support maps, and therefore only allows dumping seccomp ebpf >> >> > programs which themselves don't currently support maps. >> >> > >> >> > We export the GPL bit as well as a unique ID for the program so that >> >> >> >> This unique ID appears to be the heap address for the prog. That's a >> >> huge leak, and should not be done. We don't want to introduce new >> >> kernel address leaks while we're trying to fix the remaining ones. >> >> Shouldn't the "unique ID" be the fd itself? I imagine KCMP_FILE >> >> could be used, for example. >> > >> > No; we acquire the fd per process, so if a task installs a filter and >> > then forks N times, we'll grab N (+1) copies of the filter from N (+1) >> > different file descriptors. Ideally, we'd have some way to figure out >> > that these were all the same. Some sort of prog_id is one way, >> > although there may be others. >> >> I disagree a bit. I think we want the actual hierarchy to be a >> well-defined thing, because I have plans to make the hierarchy >> actually do something. That means that we'll need to have a more >> exact way to dump the hierarchy than "these two filters are identical" >> or "these two filters are not identical". > > Can you elaborate on what this would look like? I think with the > "these two filters are the same" primitive (the same in the sense that > they were inherited during a fork, not just that > memcmp(filter1->insns, filter2->insns) == 0) you can infer the entire > hierarchy, however clunky it may be to do so. > > Another issue is that KCMP_FILE won't work in this case, as it > effectively compares the struct file *, which will be different since > we need to call anon_inode_getfd() for each call of > ptrace(PTRACE_SECCOMP_GET_FILTER_FD). We could add a KCMP_BPF (or just > a KCMP_FILE_PRIVATE_DATA, since that's effectively what it would be). > Does that make sense? [added Cyrill] > I don't really know what it would look like. I think we want a way to compare struct seccomp_filter pointers. FWIW, I *hate* kcmp. It might be worth trying to come up with a less awful way to do this. For example, what if we could generate a kcmpfd such that each kcmpfd contains (internally) a random symmetric key? We could have a function that would return kernel pointers encrypted by that key. Of course, then we need to make sure that no one ever tries to keep a kcmpfd around long enough that CRIU needs to checkpoint it, because that's impossible. Grr. --Andy -- 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/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 07:52:55PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Sep 04, 2015 at 07:41:39PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Sep 04, 2015 at 10:45:43AM -0400, kan.li...@intel.com escreveu:
> > > From: Kan Liang
> > >
> > > This patch enable perf report to sort by processor socket
> > >
> > > $ perf report --stdio --sort socket,comm,dso,symbol
> > > # To display the perf.data header info, please use
> > > --header/--header-only options.
> > > #
> > > #
> > > # Total Lost Samples: 0
> > > #
> > > # Samples: 686 of event 'cycles'
> > > # Event count (approx.): 349215462
> > > #
> > > # Overhead SOCKET CommandShared Object Symbol
> > > # .. .
> > > .
> >
> > So this works in 'perf top' only for the first screen rendering, when it
> > refreshes we lose the "SOCKET" header (why all caps?) and the colum
> > stops being %03d and instead becomes %d, I am checking now.
>
> Patch below fix this, but we stumble in another problem, when zooming it
> is not eliding the SOCKET column, i.e. if we're zooming into a column,
> it will have the same value for all entries, no use in showing it, save
> some columns, will check that as well.
>
> Will fold the fixes to the patches where the problems were introduced,
> the feature is cool, one more zoom! :-)
One more fixed, see below, now we have another, using ESC should remove
the last applied Zoom operation, just like for the other Zoom operations
(DSO, thread, etc), looking at that now.
- Arnaldo
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index d695fd2b6228..67d40feb1880 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1680,12 +1680,14 @@ add_exit_opt(struct hist_browser *browser
__maybe_unused,
static int
do_zoom_socket(struct hist_browser *browser, struct popup_action *act)
{
- if (browser->hists->socket_filter > -1)
+ if (browser->hists->socket_filter > -1) {
browser->hists->socket_filter = -1;
- else
+ perf_hpp__set_elide(HISTC_SOCKET, false);
+ } else {
browser->hists->socket_filter = act->socket;
+ perf_hpp__set_elide(HISTC_SOCKET, true);
+ }
- perf_hpp__set_elide(HISTC_SOCKET, false);
hists__filter_by_socket(browser->hists);
hist_browser__reset(browser);
return 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] perf tools: Fix build errors with mipsel-linux-uclibc compiler
Em Fri, Sep 04, 2015 at 04:01:54PM -0700, Petri Gynther escreveu: > On Fri, Sep 4, 2015 at 3:48 PM, Arnaldo Carvalho de Melo > wrote: > > Em Fri, Sep 04, 2015 at 03:45:03PM -0700, Petri Gynther escreveu: > >> This commit breaks the perf tool MIPS build because MIPS doesn't have > >> CONFIG_PERF_REGS=y in .config-detected: > >> > >> commit bcc84ec65ad1bd9f777a1fade6f8e5e0c5808fa5 > >> Author: Stephane Eranian > >> Date: Mon Aug 31 18:41:12 2015 +0200 > >> > >> perf record: Add ability to name registers to record > > > > There was a fix for another arch that came after this one.. here it is, > > already > > upstream, can you take a look? > > > > commit af4aeadd8c04303c0aa2d112145c3627e2ebd026 > > Author: Stephane Eranian > > Date: Tue Sep 1 11:30:14 2015 +0200 > > > > perf tools: Fix link time error with sample_reg_masks on non x86 > > > > This patch makes perf compile on non x86 platforms by defining a weak > > symbol for sample_reg_masks[] in util/perf_regs.c. > > > > The patch also moves the REG() and REG_END() macros into the > > util/per_regs.h header file. The macros are renamed to > > SMPL_REG/SMPL_REG_END to avoid clashes with other header files. > > > > > > I have the above commit in my tree (as I have the latest Linus' tree > as of right now). > The MIPS build is still broken as I reported. Stephane, can you please take a look? - Arnaldo > tools/perf/util/perf_regs.c doesn't get compiled on MIPS because: > > CONFIG_PERF_REGS is not set on MIPS > and > tools/perf/util/Build: > libperf-$(CONFIG_PERF_REGS) += perf_regs.o > > Converting the above to: > libperf-y += perf_regs.o > > leads to other build errors: > ... > CC util/perf_regs.o > In file included from util/perf_regs.c:2:0: > util/perf_regs.h:26:48: error: expected ‘;’, ‘,’ or ‘)’ before > ‘__maybe_unused’ > static inline const char *perf_reg_name(int id __maybe_unused) > ^ > util/perf_regs.h:31:44: error: expected ‘;’, ‘,’ or ‘)’ before > ‘__maybe_unused’ > static inline int perf_reg_value(u64 *valp __maybe_unused, > ^ > FLEX util/parse-events-flex.c > util/perf_regs.c:9:5: error: no previous prototype for > ‘perf_reg_value’ [-Werror=missing-prototypes] > int perf_reg_value(u64 *valp, struct regs_dump *regs, int id) > ^ > cc1: all warnings being treated as errors > CC util/intel-pt-decoder/intel-pt-log.o > make[4]: *** [util/perf_regs.o] Error 1 > make[4]: *** Waiting for unfinished jobs > CC util/intel-pt-decoder/intel-pt-decoder.o > LD tests/perf-in.o > CC util/intel-pt-decoder/intel-pt-insn-decoder.o > LD perf-in.o > LD util/intel-pt-decoder/libperf-in.o > make[3]: *** [util] Error 2 > make[2]: *** [libperf-in.o] Error 2 > make[1]: *** [all] Error 2 > make: *** [perf] Error 2 > > > >> On Fri, Sep 4, 2015 at 3:19 PM, Petri Gynther wrote: > >> > I see that this patch is now in upstream. However, something else has > >> > now broken the perf tool MIPS build: > >> > > >> > linux/tools$ git describe > >> > v4.2-7656-g51e771c > >> > > >> > linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf > >> > mkdir -p . > >> > make --no-print-directory -C perf O= subdir= > >> > BUILD: Doing 'make -j12' parallel build > >> > > >> > Auto-detecting system features: > >> > ... dwarf: [ OFF ] > >> > ... glibc: [ on ] > >> > ... gtk2: [ OFF ] > >> > ... libaudit: [ OFF ] > >> > ...libbfd: [ OFF ] > >> > ...libelf: [ OFF ] > >> > ... libnuma: [ OFF ] > >> > ... libperl: [ OFF ] > >> > ... libpython: [ OFF ] > >> > ... libslang: [ OFF ] > >> > ... libunwind: [ OFF ] > >> > ...libdw-dwarf-unwind: [ OFF ] > >> > ... zlib: [ OFF ] > >> > ... lzma: [ OFF ] > >> > > >> > ... > >> > > >> > AR libperf.a > >> > LINK perf > >> > libperf.a(libperf-in.o): In function `parse_regs': > >> > (.text+0x9f5b4): undefined reference to `sample_reg_masks' > >> > libperf.a(libperf-in.o): In function `parse_regs': > >> > (.text+0x9f604): undefined reference to `sample_reg_masks' > >> > libperf.a(libperf-in.o): In function `parse_regs': > >> > (.text+0x9f708): undefined reference to `sample_reg_masks' > >> > collect2: error: ld returned 1 exit status > >> > make[2]: *** [perf] Error 1 > >> > make[1]: *** [all] Error 2 > >> > make: *** [perf] Error 2 > >> > > >> > On Tue, Aug 4, 2015 at 5:38 PM, Petri Gynther > >> > wrote: > >> >> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf > >> >> ... > >> >> config/Makefile:256: *** No gnu/libc-version.h found, please install > >> >> glibc-dev[el]. Stop. > >> >> make[1]: *** [all] Error 2 > >>
Re: [PATCH] perf tools: Fix build errors with mipsel-linux-uclibc compiler
On Fri, Sep 4, 2015 at 3:48 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, Sep 04, 2015 at 03:45:03PM -0700, Petri Gynther escreveu: >> This commit breaks the perf tool MIPS build because MIPS doesn't have >> CONFIG_PERF_REGS=y in .config-detected: >> >> commit bcc84ec65ad1bd9f777a1fade6f8e5e0c5808fa5 >> Author: Stephane Eranian >> Date: Mon Aug 31 18:41:12 2015 +0200 >> >> perf record: Add ability to name registers to record > > There was a fix for another arch that came after this one.. here it is, > already > upstream, can you take a look? > > commit af4aeadd8c04303c0aa2d112145c3627e2ebd026 > Author: Stephane Eranian > Date: Tue Sep 1 11:30:14 2015 +0200 > > perf tools: Fix link time error with sample_reg_masks on non x86 > > This patch makes perf compile on non x86 platforms by defining a weak > symbol for sample_reg_masks[] in util/perf_regs.c. > > The patch also moves the REG() and REG_END() macros into the > util/per_regs.h header file. The macros are renamed to > SMPL_REG/SMPL_REG_END to avoid clashes with other header files. > > I have the above commit in my tree (as I have the latest Linus' tree as of right now). The MIPS build is still broken as I reported. tools/perf/util/perf_regs.c doesn't get compiled on MIPS because: CONFIG_PERF_REGS is not set on MIPS and tools/perf/util/Build: libperf-$(CONFIG_PERF_REGS) += perf_regs.o Converting the above to: libperf-y += perf_regs.o leads to other build errors: ... CC util/perf_regs.o In file included from util/perf_regs.c:2:0: util/perf_regs.h:26:48: error: expected ‘;’, ‘,’ or ‘)’ before ‘__maybe_unused’ static inline const char *perf_reg_name(int id __maybe_unused) ^ util/perf_regs.h:31:44: error: expected ‘;’, ‘,’ or ‘)’ before ‘__maybe_unused’ static inline int perf_reg_value(u64 *valp __maybe_unused, ^ FLEX util/parse-events-flex.c util/perf_regs.c:9:5: error: no previous prototype for ‘perf_reg_value’ [-Werror=missing-prototypes] int perf_reg_value(u64 *valp, struct regs_dump *regs, int id) ^ cc1: all warnings being treated as errors CC util/intel-pt-decoder/intel-pt-log.o make[4]: *** [util/perf_regs.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/intel-pt-decoder/intel-pt-decoder.o LD tests/perf-in.o CC util/intel-pt-decoder/intel-pt-insn-decoder.o LD perf-in.o LD util/intel-pt-decoder/libperf-in.o make[3]: *** [util] Error 2 make[2]: *** [libperf-in.o] Error 2 make[1]: *** [all] Error 2 make: *** [perf] Error 2 >> On Fri, Sep 4, 2015 at 3:19 PM, Petri Gynther wrote: >> > I see that this patch is now in upstream. However, something else has >> > now broken the perf tool MIPS build: >> > >> > linux/tools$ git describe >> > v4.2-7656-g51e771c >> > >> > linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf >> > mkdir -p . >> > make --no-print-directory -C perf O= subdir= >> > BUILD: Doing 'make -j12' parallel build >> > >> > Auto-detecting system features: >> > ... dwarf: [ OFF ] >> > ... glibc: [ on ] >> > ... gtk2: [ OFF ] >> > ... libaudit: [ OFF ] >> > ...libbfd: [ OFF ] >> > ...libelf: [ OFF ] >> > ... libnuma: [ OFF ] >> > ... libperl: [ OFF ] >> > ... libpython: [ OFF ] >> > ... libslang: [ OFF ] >> > ... libunwind: [ OFF ] >> > ...libdw-dwarf-unwind: [ OFF ] >> > ... zlib: [ OFF ] >> > ... lzma: [ OFF ] >> > >> > ... >> > >> > AR libperf.a >> > LINK perf >> > libperf.a(libperf-in.o): In function `parse_regs': >> > (.text+0x9f5b4): undefined reference to `sample_reg_masks' >> > libperf.a(libperf-in.o): In function `parse_regs': >> > (.text+0x9f604): undefined reference to `sample_reg_masks' >> > libperf.a(libperf-in.o): In function `parse_regs': >> > (.text+0x9f708): undefined reference to `sample_reg_masks' >> > collect2: error: ld returned 1 exit status >> > make[2]: *** [perf] Error 1 >> > make[1]: *** [all] Error 2 >> > make: *** [perf] Error 2 >> > >> > On Tue, Aug 4, 2015 at 5:38 PM, Petri Gynther wrote: >> >> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf >> >> ... >> >> config/Makefile:256: *** No gnu/libc-version.h found, please install >> >> glibc-dev[el]. Stop. >> >> make[1]: *** [all] Error 2 >> >> make: *** [perf] Error 2 >> >> >> >> ... >> >> In file included from builtin-sched.c:13:0: >> >> util/cloexec.h:8:12: error: redundant redeclaration of ‘sched_getcpu’ >> >> [-Werror=redundant-decls] >> >> extern int sched_getcpu(void) __THROW; >> >> >> >> mipsel-buildroot-linux-uclibc/sysroot/usr/include/bits/sched.h:88:12: >> >> note: previous declaration of ‘sched_get
[PATCH] Staging: rtl18192u: fix style issues in ieee80211_softmac_wx.c
This is a patch to the ieee80211_softmac_wx.c file that corrects several
checkpatch.pl warnings and errors.
Signed-off-by: Mike Dupuis
---
.../rtl8192u/ieee80211/ieee80211_softmac_wx.c | 114 ++--
1 file changed, 54 insertions(+), 60 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac_wx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac_wx.c
index 3e502520..a8acd17 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac_wx.c
@@ -28,11 +28,11 @@ const long ieee80211_wlan_frequencies[] = {
};
EXPORT_SYMBOL(ieee80211_wlan_frequencies);
-int ieee80211_wx_set_freq(struct ieee80211_device *ieee, struct
iw_request_info *a,
-union iwreq_data *wrqu, char *b)
+int ieee80211_wx_set_freq(struct ieee80211_device *ieee,
+ struct iw_request_info *a, union iwreq_data *wrqu, char *b)
{
int ret;
- struct iw_freq *fwrq = & wrqu->freq;
+ struct iw_freq *fwrq = &wrqu->freq;
down(&ieee->wx_sem);
@@ -57,11 +57,11 @@ int ieee80211_wx_set_freq(struct ieee80211_device *ieee,
struct iw_request_info
}
}
- if (fwrq->e > 0 || fwrq->m > 14 || fwrq->m < 1 ){
+ if (fwrq->e > 0 || fwrq->m > 14 || fwrq->m < 1) {
ret = -EOPNOTSUPP;
goto out;
- }else { /* Set the channel */
+ } else { /* Set the channel */
if (!(GET_DOT11D_INFO(ieee)->channel_map)[fwrq->m]) {
ret = -EINVAL;
@@ -70,11 +70,10 @@ int ieee80211_wx_set_freq(struct ieee80211_device *ieee,
struct iw_request_info
ieee->current_network.channel = fwrq->m;
ieee->set_chan(ieee->dev, ieee->current_network.channel);
- if(ieee->iw_mode == IW_MODE_ADHOC || ieee->iw_mode ==
IW_MODE_MASTER)
- if(ieee->state == IEEE80211_LINKED){
-
- ieee80211_stop_send_beacons(ieee);
- ieee80211_start_send_beacons(ieee);
+ if (ieee->iw_mode == IW_MODE_ADHOC || ieee->iw_mode ==
IW_MODE_MASTER)
+ if (ieee->state == IEEE80211_LINKED) {
+ ieee80211_stop_send_beacons(ieee);
+ ieee80211_start_send_beacons(ieee);
}
}
@@ -89,15 +88,15 @@ int ieee80211_wx_get_freq(struct ieee80211_device *ieee,
struct iw_request_info *a,
union iwreq_data *wrqu, char *b)
{
- struct iw_freq *fwrq = & wrqu->freq;
+ struct iw_freq *fwrq = &wrqu->freq;
if (ieee->current_network.channel == 0)
return -1;
- //NM 0.7.0 will not accept channel any more.
+ /* NM 0.7.0 will not accept channel any more. */
fwrq->m = ieee80211_wlan_frequencies[ieee->current_network.channel-1] *
10;
fwrq->e = 1;
-// fwrq->m = ieee->current_network.channel;
-// fwrq->e = 0;
+/* fwrq->m = ieee->current_network.channel; */
+/* fwrq->e = 0; */
return 0;
}
@@ -141,7 +140,7 @@ int ieee80211_wx_set_wap(struct ieee80211_device *ieee,
int ret = 0;
unsigned long flags;
- short ifup = ieee->proto_started;//dev->flags & IFF_UP;
+ short ifup = ieee->proto_started; /* dev->flags & IFF_UP; */
struct sockaddr *temp = (struct sockaddr *)awrq;
ieee->sync_scan_hurryup = 1;
@@ -179,7 +178,8 @@ out:
}
EXPORT_SYMBOL(ieee80211_wx_set_wap);
- int ieee80211_wx_get_essid(struct ieee80211_device *ieee, struct
iw_request_info *a,union iwreq_data *wrqu,char *b)
+int ieee80211_wx_get_essid(struct ieee80211_device *ieee,
+ struct iw_request_info *a, union iwreq_data *wrqu, char *b)
{
int len, ret = 0;
unsigned long flags;
@@ -223,7 +223,7 @@ int ieee80211_wx_set_rate(struct ieee80211_device *ieee,
u32 target_rate = wrqu->bitrate.value;
ieee->rate = target_rate/10;
- //FIXME: we might want to limit rate also in management protocols.
+ /* FIXME: we might want to limit rate also in management protocols. */
return 0;
}
EXPORT_SYMBOL(ieee80211_wx_set_rate);
@@ -233,6 +233,7 @@ int ieee80211_wx_get_rate(struct ieee80211_device *ieee,
union iwreq_data *wrqu, char *extra)
{
u32 tmp_rate;
+
tmp_rate = TxCountToDataRate(ieee,
ieee->softmac_stats.CurrentShowTxate);
wrqu->bitrate.value = tmp_rate * 50;
@@ -247,8 +248,7 @@ int ieee80211_wx_set_rts(struct ieee80211_device *ieee,
{
if (wrqu->rts.disabled || !wrqu->rts.fixed)
ieee->rts = DEFAULT_RTS_THRESHOLD;
- else
- {
+ else {
if (wrqu->rts.value < MIN_RTS_THRESHOLD ||
wrqu->rts.value > MAX_RTS_THRESHOLD)
return -EINVAL;
@@ -269,
Re: [PATCH 2/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 07:41:39PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Sep 04, 2015 at 10:45:43AM -0400, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > This patch enable perf report to sort by processor socket > > > > $ perf report --stdio --sort socket,comm,dso,symbol > > # To display the perf.data header info, please use > > --header/--header-only options. > > # > > # > > # Total Lost Samples: 0 > > # > > # Samples: 686 of event 'cycles' > > # Event count (approx.): 349215462 > > # > > # Overhead SOCKET CommandShared Object Symbol > > # .. . > > . > > So this works in 'perf top' only for the first screen rendering, when it > refreshes we lose the "SOCKET" header (why all caps?) and the colum > stops being %03d and instead becomes %d, I am checking now. Patch below fix this, but we stumble in another problem, when zooming it is not eliding the SOCKET column, i.e. if we're zooming into a column, it will have the same value for all entries, no use in showing it, save some columns, will check that as well. Will fold the fixes to the patches where the problems were introduced, the feature is cool, one more zoom! :-) Thanks, - Arnaldo diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index bb633cd4730a..67b48616ab31 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -146,6 +146,7 @@ void hists__calc_col_len(struct hists *hists, struct hist_entry *h) hists__set_unres_dso_col_len(hists, HISTC_MEM_DADDR_DSO); } + hists__new_col_len(hists, HISTC_SOCKET, 6); hists__new_col_len(hists, HISTC_MEM_LOCKED, 6); hists__new_col_len(hists, HISTC_MEM_TLB, 22); hists__new_col_len(hists, HISTC_MEM_SNOOP, 12); -- 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] perf, tools, stat: Move sw clock metrics printout to stat-shadow
Em Fri, Sep 04, 2015 at 03:45:12PM -0700, Andi Kleen escreveu:
> From: Andi Kleen
>
> The sw clock metrics printing was missed in the earlier move to
> stat-shadow of all the other metric printouts. Move it too.
>
> Acked-by: Jiri Olsa
Merging this one, letting Jiri react to the others,
- Arnaldo
> Signed-off-by: Andi Kleen
> ---
> tools/perf/builtin-stat.c | 9 -
> tools/perf/util/stat-shadow.c | 3 +++
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index a96fb5c..77e5781 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -510,15 +510,6 @@ static void nsec_printout(int id, int nr, struct
> perf_evsel *evsel, double avg)
>
> if (evsel->cgrp)
> fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
> -
> - if (csv_output || stat_config.interval)
> - return;
> -
> - if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
> - fprintf(output, " # %8.3f CPUs utilized ",
> - avg / avg_stats(&walltime_nsecs_stats));
> - else
> - fprintf(output, " ");
> }
>
> static void abs_printout(int id, int nr, struct perf_evsel *evsel, double
> avg)
> diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
> index 2a5d8d7..625ab3b 100644
> --- a/tools/perf/util/stat-shadow.c
> +++ b/tools/perf/util/stat-shadow.c
> @@ -413,6 +413,9 @@ void perf_stat__print_shadow_stats(FILE *out, struct
> perf_evsel *evsel,
> ratio = total / avg;
>
> fprintf(out, " # %8.0f cycles / elision ", ratio);
> + } else if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK) &&
> +(ratio = avg_stats(&walltime_nsecs_stats)) != 0) {
> + fprintf(out, " # %8.3f CPUs utilized ", avg / ratio);
> } else if (runtime_nsecs_stats[cpu].n != 0) {
> char unit = 'M';
>
> --
> 2.4.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] perf tools: Fix build errors with mipsel-linux-uclibc compiler
Em Fri, Sep 04, 2015 at 03:45:03PM -0700, Petri Gynther escreveu:
> This commit breaks the perf tool MIPS build because MIPS doesn't have
> CONFIG_PERF_REGS=y in .config-detected:
>
> commit bcc84ec65ad1bd9f777a1fade6f8e5e0c5808fa5
> Author: Stephane Eranian
> Date: Mon Aug 31 18:41:12 2015 +0200
>
> perf record: Add ability to name registers to record
There was a fix for another arch that came after this one.. here it is, already
upstream, can you take a look?
commit af4aeadd8c04303c0aa2d112145c3627e2ebd026
Author: Stephane Eranian
Date: Tue Sep 1 11:30:14 2015 +0200
perf tools: Fix link time error with sample_reg_masks on non x86
This patch makes perf compile on non x86 platforms by defining a weak
symbol for sample_reg_masks[] in util/perf_regs.c.
The patch also moves the REG() and REG_END() macros into the
util/per_regs.h header file. The macros are renamed to
SMPL_REG/SMPL_REG_END to avoid clashes with other header files.
> On Fri, Sep 4, 2015 at 3:19 PM, Petri Gynther wrote:
> > I see that this patch is now in upstream. However, something else has
> > now broken the perf tool MIPS build:
> >
> > linux/tools$ git describe
> > v4.2-7656-g51e771c
> >
> > linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
> > mkdir -p .
> > make --no-print-directory -C perf O= subdir=
> > BUILD: Doing 'make -j12' parallel build
> >
> > Auto-detecting system features:
> > ... dwarf: [ OFF ]
> > ... glibc: [ on ]
> > ... gtk2: [ OFF ]
> > ... libaudit: [ OFF ]
> > ...libbfd: [ OFF ]
> > ...libelf: [ OFF ]
> > ... libnuma: [ OFF ]
> > ... libperl: [ OFF ]
> > ... libpython: [ OFF ]
> > ... libslang: [ OFF ]
> > ... libunwind: [ OFF ]
> > ...libdw-dwarf-unwind: [ OFF ]
> > ... zlib: [ OFF ]
> > ... lzma: [ OFF ]
> >
> > ...
> >
> > AR libperf.a
> > LINK perf
> > libperf.a(libperf-in.o): In function `parse_regs':
> > (.text+0x9f5b4): undefined reference to `sample_reg_masks'
> > libperf.a(libperf-in.o): In function `parse_regs':
> > (.text+0x9f604): undefined reference to `sample_reg_masks'
> > libperf.a(libperf-in.o): In function `parse_regs':
> > (.text+0x9f708): undefined reference to `sample_reg_masks'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [perf] Error 1
> > make[1]: *** [all] Error 2
> > make: *** [perf] Error 2
> >
> > On Tue, Aug 4, 2015 at 5:38 PM, Petri Gynther wrote:
> >> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
> >> ...
> >> config/Makefile:256: *** No gnu/libc-version.h found, please install
> >> glibc-dev[el]. Stop.
> >> make[1]: *** [all] Error 2
> >> make: *** [perf] Error 2
> >>
> >> ...
> >> In file included from builtin-sched.c:13:0:
> >> util/cloexec.h:8:12: error: redundant redeclaration of ‘sched_getcpu’
> >> [-Werror=redundant-decls]
> >> extern int sched_getcpu(void) __THROW;
> >>
> >> mipsel-buildroot-linux-uclibc/sysroot/usr/include/bits/sched.h:88:12:
> >> note: previous declaration of ‘sched_getcpu’ was here
> >> extern int sched_getcpu (void) __THROW;
> >>
> >> uclibc info:
> >> sysroot/usr/include/bits/uClibc_config.h
> >> __UCLIBC_MAJOR__ 0
> >> __UCLIBC_MINOR__ 9
> >> __UCLIBC_SUBLEVEL__ 33
> >>
> >> sysroot/usr/include/features.h
> >> __UCLIBC__ 1
> >> __GLIBC__ 2
> >> __GLIBC_MINOR__ 2
> >>
> >> Signed-off-by: Petri Gynther
> >> ---
> >> tools/build/feature/test-glibc.c | 11 +++
> >> tools/perf/util/cloexec.h| 2 +-
> >> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/build/feature/test-glibc.c
> >> b/tools/build/feature/test-glibc.c
> >> index b082034..9367f75 100644
> >> --- a/tools/build/feature/test-glibc.c
> >> +++ b/tools/build/feature/test-glibc.c
> >> @@ -1,8 +1,19 @@
> >> +#include
> >> +
> >> +#if !defined(__UCLIBC__)
> >> #include
> >> +#else
> >> +#define XSTR(s) STR(s)
> >> +#define STR(s) #s
> >> +#endif
> >>
> >> int main(void)
> >> {
> >> +#if !defined(__UCLIBC__)
> >> const char *version = gnu_get_libc_version();
> >> +#else
> >> + const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> >> +#endif
> >>
> >> return (long)version;
> >> }
> >> diff --git a/tools/perf/util/cloexec.h b/tools/perf/util/cloexec.h
> >> index 6c2..3bee677 100644
> >> --- a/tools/perf/util/cloexec.h
> >> +++ b/tools/perf/util/cloexec.h
> >> @@ -4,7 +4,7 @@
> >> unsigned long perf_event_open_cloexec_flag(void);
> >>
> >> #ifdef __GLIBC_PREREQ
> >> -#if !__GLIBC_PREREQ(2, 6)
> >> +#if !__GLIBC_PREREQ(2, 6) && !defined(__UCLIBC__)
> >> extern int sched_getcpu(void) __THROW;
> >> #endif
> >> #endif
> >> --
> >> 2.5.0.rc2.392.g76e840b
> >>
--
To unsubscribe from this list: se
[PATCH 3/6] perf, tools, stat: Add support for metrics in interval mode
From: Andi Kleen
Now that we can modify the metrics printout functions easily,
it's straight forward to support metric printing for interval mode.
All that is needed is to print the time stamp on every new line.
Pass the prefix into the context and print it out.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index fbe457c..78b1688 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -486,6 +486,7 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
struct outstate {
FILE *fh;
+ const char *prefix;
};
#define BASE_INDENT 41
@@ -496,13 +497,13 @@ struct outstate {
static void new_line_no_aggr_std(void *ctx)
{
struct outstate *os = ctx;
- fprintf(os->fh, "\n%*s", BASE_INDENT + NA_INDENT, "");
+ fprintf(os->fh, "\n%s%-*s", os->prefix, BASE_INDENT + NA_INDENT, "");
}
static void new_line_std(void *ctx)
{
struct outstate *os = ctx;
- fprintf(os->fh, "\n%-*s", BASE_INDENT + AGGR_INDENT, "");
+ fprintf(os->fh, "\n%s%-*s", os->prefix, BASE_INDENT + AGGR_INDENT, "");
}
static void print_metric_std(void *ctx, const char *color, const char *fmt,
@@ -583,10 +584,14 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
}
-static void printout(int id, int nr, struct perf_evsel *counter, double uval)
+static void printout(int id, int nr, struct perf_evsel *counter, double uval,
+char *prefix)
{
- struct outstate os = { .fh = stat_config.output };
struct perf_stat_output_ctx out;
+ struct outstate os = {
+ .fh = stat_config.output,
+ .prefix = prefix ? prefix : ""
+ };
print_metric_t pm = print_metric_std;
void (*nl)(void *);
@@ -662,7 +667,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval);
+ printout(id, nr, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -693,7 +698,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval);
+ printout(thread, 0, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -743,7 +748,7 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
}
uval = avg * counter->scale;
- printout(-1, 0, counter, uval);
+ printout(-1, 0, counter, uval, prefix);
print_noise(counter, avg);
@@ -796,7 +801,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
- printout(cpu, 0, counter, uval);
+ printout(cpu, 0, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
--
2.4.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: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')
On 09/04/15 14:30, Stas Sergeev wrote: 05.09.2015 00:16, Stas Sergeev пишет: I agree. vm86() is a mess. My point is that its risky parts and useless funtionality is _already_ known (even I can point to the particular code parts than can simply be removed). As such, it simply had to be re-visited and cleaned up to match at least 1 and 3 (and then maybe 5). This wasn't done, and the knob was introduced _instead_ of doing this. Grr, I mean it was disabled by default instead of doing this, and the knob was only proposed, not added. You can't just pull vm86 out of the kernel anyway. dosemu is a userspace application that depends on it, so pulling this feature out would be a big fat regression, period. I would personally rather not hear about how "it's a legacy program so its userbase is shrinking" used as any sort of excuse to ignore the fact that we shouldn't break userspace. I can even say as a user that vm86 is important to me. By all means, cleaning up vm86 is a good idea. But removing it or fencing it off with a strong deprecation doesn't sound like the right idea. -- 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/ -- 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] csiostor:Fix locking requirements for function call in the function csio_alloc_rnode
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Thursday, September 3, 2015 10:44 AM
> To: jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish
> Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] csiostor:Fix locking requirements for function call in the
> function csio_alloc_rnode
>
> This fixes locking requirements for the function call to the function
> csio_rnode_init to properly lock and disable irqs before calling this function
> with spin_lock_irq on the structure pointer hw of type csio_hw and unlocking
> after the function call with spin_unlock_irq in order to prevent concurrent
> access on the shared structure pointer hw of type csio_hw with other
> threads of execution accessing this structure
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/scsi/csiostor/csio_rnode.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/csiostor/csio_rnode.c
> b/drivers/scsi/csiostor/csio_rnode.c
> index e9c3b04..85635f4 100644
> --- a/drivers/scsi/csiostor/csio_rnode.c
> +++ b/drivers/scsi/csiostor/csio_rnode.c
> @@ -222,9 +222,13 @@ csio_alloc_rnode(struct csio_lnode *ln)
> goto err;
>
> memset(rn, 0, sizeof(struct csio_rnode));
> - if (csio_rnode_init(rn, ln))
> + spin_lock_irq(&hw->lock);
> + if (csio_rnode_init(rn, ln)) {
> + spin_unlock_irq(&hw->lock);
> goto err_free;
> -
> + }
> +
> + spin_unlock_irq(&hw->lock);
> CSIO_INC_STATS(ln, n_rnode_alloc);
>
> return rn;
> --
> 2.1.4
NACK. Function called from csio_fcoe_fwevt_handler() with lock held.
--
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/
perf, tools: Refactor and support interval and CSV metrics v4
[v4: Addressed all review feedback.] [v3: Addressed all review feedback. Update manpage for CSV. Various changes (see individual patches). Remove some more redundant code in printout callers.] [v2: Addressed (near) all review feedback. No manpage updates so far. Add support for --per-core metrics. Various cleanups.] [v3: Everything compiles again. Some more cleanups.] Currently perf stat does not support printing computed metrics for interval (-I xxx) or CSV (-x,) mode. For example IPC or TSX metrics over time are quite useful to know. This patch implements them. The main obstacle was that the metrics printing was all open coded all over the metrics computation code. The second patch refactors the metrics printing to work through call backs that can be more easily changed. This also cleans up the metrics printing significantly. The indentation is now handled through printf, no more need to manually count spaces. Then based on that it implements metrics printing for CSV and interval mode. Example output: % perf stat -I1000 -a sleep 1 # time counts unit eventsmetric multiplex 1.001301370 12020.049593 task-clock (msec) (100.00%) 1.001301370 3,952 context-switches #0.329 K/sec(100.00%) 1.001301370 69 cpu-migrations#0.006 K/sec(100.00%) 1.001301370 76 page-faults #0.006 K/sec 1.001301370386,582,789 cycles#0.032 GHz (100.00%) 1.001301370716,441,544 stalled-cycles-frontend # 185.33% frontend cycles idle (100.00%) 1.001301370 stalled-cycles-backend 1.001301370101,751,678 instructions #0.26 insn per cycle 1.001301370 #7.04 stalled cycles per insn (100.00%) 1.001301370 20,914,692 branches #1.740 M/sec(100.00%) 1.001301370 1,943,630 branch-misses #9.29% of all branches CSV mode % perf stat -x, -I1000 -a sleep 1 1.000852081,12016.143006,,task-clock 1.000852081,4457,,context-switches,12015168277,100.00,0.371,K/sec 1.000852081,50,,cpu-migrations,12014024424,100.00,0.004,K/sec 1.000852081,76,,page-faults,12013076716,100.00,0.006,K/sec 1.000852081,515854373,,cycles,12011235336,100.00,0.043,GHz 1.000852081,1030742150,,stalled-cycles-frontend,12010984057,100.00,199.81,frontend cycles idle 1.000852081,,,stalled-cycles-backend,0,100.00 1.000852081,116782495,,instructions,12011130729,100.00,0.23,insn per cycle 1.00085208112011130729,100.00,8.83,stalled cycles per insn 1.000852081,23748237,,branches,12010745125,100.00,1.976,M/sec 1.000852081,1976560,,branch-misses,12010501884,100.00,8.32,of all branches Available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc-2.6 perf/stat-metrics-6 -- 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 2/6] perf, tools, stat: Abstract stat metrics printing
From: Andi Kleen
Abstract the printing of shadow metrics. Instead of every
metric calling fprintf directly and taking care of indentation,
use two call backs: one to print metrics and another to
start a new line.
This will allow adding metrics to CSV mode and also
using them for other purposes.
The computation of padding is now done in the central
callback, instead of every metric doing it manually.
This makes it easier to add new metrics.
v2: Refactor functions, printout now does more. Move
shadow printing. Improve fallback callbacks. Don't
use void * callback data.
v3: Remove unnecessary hunk. Add typedef for new_line
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 100 ++--
tools/perf/util/stat-shadow.c | 212 +++---
tools/perf/util/stat.h| 15 ++-
3 files changed, 197 insertions(+), 130 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 77e5781..fbe457c 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -484,6 +484,47 @@ static void aggr_printout(struct perf_evsel *evsel, int
id, int nr)
}
}
+struct outstate {
+ FILE *fh;
+};
+
+#define BASE_INDENT 41
+#define AGGR_INDENT 8
+#define METRIC_LEN 35
+#define NA_INDENT 16
+
+static void new_line_no_aggr_std(void *ctx)
+{
+ struct outstate *os = ctx;
+ fprintf(os->fh, "\n%*s", BASE_INDENT + NA_INDENT, "");
+}
+
+static void new_line_std(void *ctx)
+{
+ struct outstate *os = ctx;
+ fprintf(os->fh, "\n%-*s", BASE_INDENT + AGGR_INDENT, "");
+}
+
+static void print_metric_std(void *ctx, const char *color, const char *fmt,
+const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ int n;
+
+ if (unit == NULL) {
+ fprintf(out, "%-*s", METRIC_LEN, "");
+ return;
+ }
+
+ n = fprintf(out, " # ");
+ if (color)
+ n += color_fprintf(out, color, fmt, val);
+ else
+ n += fprintf(out, fmt, val);
+ fprintf(out, " %-*s", METRIC_LEN - n - 1, unit);
+}
+
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
FILE *output = stat_config.output;
@@ -517,7 +558,6 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
FILE *output = stat_config.output;
double sc = evsel->scale;
const char *fmt;
- int cpu = cpu_map__id_to_cpu(id);
if (csv_output) {
fmt = sc != 1.0 ? "%.2f%s" : "%.0f%s";
@@ -530,9 +570,6 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
aggr_printout(evsel, id, nr);
- if (stat_config.aggr_mode == AGGR_GLOBAL)
- cpu = 0;
-
fprintf(output, fmt, avg, csv_sep);
if (evsel->unit)
@@ -544,12 +581,32 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
+}
- if (csv_output || stat_config.interval)
- return;
+static void printout(int id, int nr, struct perf_evsel *counter, double uval)
+{
+ struct outstate os = { .fh = stat_config.output };
+ struct perf_stat_output_ctx out;
+ print_metric_t pm = print_metric_std;
+ void (*nl)(void *);
+
+ if (stat_config.aggr_mode == AGGR_NONE)
+ nl = new_line_no_aggr_std;
+ else
+ nl = new_line_std;
- perf_stat__print_shadow_stats(output, evsel, avg, cpu,
- stat_config.aggr_mode);
+ if (nsec_counter(counter))
+ nsec_printout(id, nr, counter, uval);
+ else
+ abs_printout(id, nr, counter, uval);
+
+ out.print_metric = pm;
+ out.new_line = nl;
+ out.ctx = &os;
+ perf_stat__print_shadow_stats(counter, uval,
+ stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
+ cpu_map__id_to_cpu(id),
+ &out);
}
static void print_aggr(char *prefix)
@@ -605,12 +662,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
-
- if (nsec_counter(counter))
- nsec_printout(id, nr, counter, uval);
- else
- abs_printout(id, nr, counter, uval);
-
+ printout(id, nr, counter, uval);
if (!csv_output)
print_noise(counter, 1.0);
@@ -641,11 +693,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
-
- if (ns
[PATCH 4/6] perf, tools, stat: Move noise/running printing into printout
From: Andi Kleen
Move the running/noise printing into printout to avoid
duplicated code in the callers.
v2: Merged with other patches. Remove unnecessary hunk.
Readd hunk that ended in earlier patch.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 52 ++-
1 file changed, 11 insertions(+), 41 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 78b1688..86da2e1 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -585,7 +585,7 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
}
static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix)
+char *prefix, u64 run, u64 ena, double noise)
{
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -612,6 +612,12 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
&out);
+
+ if (!csv_output) {
+ print_noise(counter, noise);
+ if (run != ena)
+ fprintf(stat_config.output, " (%.2f%%)", 100.0 * run /
ena);
+ }
}
static void print_aggr(char *prefix)
@@ -667,11 +673,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -698,12 +700,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval, prefix);
-
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -717,7 +714,6 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
FILE *output = stat_config.output;
struct perf_stat *ps = counter->priv;
double avg = avg_stats(&ps->res_stats[0]);
- int scaled = counter->counts->scaled;
double uval;
double avg_enabled, avg_running;
@@ -727,32 +723,8 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (scaled == -1 || !counter->supported) {
- fprintf(output, "%*s%s",
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s", csv_sep, counter->cgrp->name);
-
- print_running(avg_running, avg_enabled);
- fputc('\n', output);
- return;
- }
-
uval = avg * counter->scale;
- printout(-1, 0, counter, uval, prefix);
-
- print_noise(counter, avg);
-
- print_running(avg_running, avg_enabled);
+ printout(-1, 0, counter, uval, prefix, avg_running, avg_enabled, avg);
fprintf(output, "\n");
}
@@ -801,9 +773,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
- printout(cpu, 0, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
+ printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
--
2.4.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/
[PATCH 1/6] perf, tools, stat: Move sw clock metrics printout to stat-shadow
From: Andi Kleen
The sw clock metrics printing was missed in the earlier move to
stat-shadow of all the other metric printouts. Move it too.
Acked-by: Jiri Olsa
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 9 -
tools/perf/util/stat-shadow.c | 3 +++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a96fb5c..77e5781 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -510,15 +510,6 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
-
- if (csv_output || stat_config.interval)
- return;
-
- if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
- fprintf(output, " # %8.3f CPUs utilized ",
- avg / avg_stats(&walltime_nsecs_stats));
- else
- fprintf(output, " ");
}
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 2a5d8d7..625ab3b 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -413,6 +413,9 @@ void perf_stat__print_shadow_stats(FILE *out, struct
perf_evsel *evsel,
ratio = total / avg;
fprintf(out, " # %8.0f cycles / elision ", ratio);
+ } else if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK) &&
+ (ratio = avg_stats(&walltime_nsecs_stats)) != 0) {
+ fprintf(out, " # %8.3f CPUs utilized ", avg / ratio);
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
--
2.4.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/
[PATCH 6/6] perf, tools, stat: Move non counting counter printing to printout
From: Andi Kleen
Move the special case printing for non-running counters to
printout, so it can be shared by all the output options.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 73 ---
1 file changed, 24 insertions(+), 49 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f582481..9ae8fc0 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -664,6 +664,30 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
os.ena = ena;
}
+ if (run == 0 || ena == 0) {
+ aggr_printout(counter, id, nr);
+
+ fprintf(stat_config.output, "%*s%s",
+ csv_output ? 0 : 18,
+ counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
+ csv_sep);
+
+ fprintf(stat_config.output, "%-*s%s",
+ csv_output ? 0 : unit_width,
+ counter->unit, csv_sep);
+
+ fprintf(stat_config.output, "%*s",
+ csv_output ? 0 : -25,
+ perf_evsel__name(counter));
+
+ if (counter->cgrp)
+ fprintf(stat_config.output, "%s%s",
+ csv_sep, counter->cgrp->name);
+
+ print_running(run, ena);
+ return;
+ }
+
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
@@ -712,30 +736,6 @@ static void print_aggr(char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (run == 0 || ena == 0) {
- aggr_printout(counter, id, nr);
-
- fprintf(output, "%*s%s",
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
-
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
-
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s",
- csv_sep, counter->cgrp->name);
-
- print_running(run, ena);
- fputc('\n', output);
- continue;
- }
uval = val * counter->scale;
printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
@@ -811,31 +811,6 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (run == 0 || ena == 0) {
- fprintf(output, "CPU%*d%s%*s%s",
- csv_output ? 0 : -4,
- perf_evsel__cpus(counter)->map[cpu], csv_sep,
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
-
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
-
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s",
- csv_sep, counter->cgrp->name);
-
- print_running(run, ena);
- fputc('\n', output);
- continue;
- }
-
uval = val * counter->scale;
printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
--
2.4.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/
[PATCH 5/6] perf, tools, stat: Implement CSV metrics output
From: Andi Kleen
Now support CSV output for metrics. With the new output callbacks
this is relatively straight forward by creating new callbacks.
The new line callback needs to know the number of fields to skip them
correctly
v2: Split out function argument changes
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 86da2e1..f582481 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -487,6 +487,8 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
struct outstate {
FILE *fh;
const char *prefix;
+ int nfields;
+ u64 run, ena;
};
#define BASE_INDENT 41
@@ -526,6 +528,49 @@ static void print_metric_std(void *ctx, const char *color,
const char *fmt,
fprintf(out, " %-*s", METRIC_LEN - n - 1, unit);
}
+static void new_line_csv(void *ctx)
+{
+ struct outstate *os = ctx;
+ int i;
+
+ fputc('\n', os->fh);
+ if (os->prefix)
+ fprintf(os->fh, "%s%s", os->prefix, csv_sep);
+ for (i = 0; i < os->nfields; i++)
+ fputs(csv_sep, os->fh);
+}
+
+static void print_metric_csv(void *ctx,
+const char *color __maybe_unused,
+const char *fmt, const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ char buf[64], *vals, *ends;
+
+ if (unit == NULL) {
+ fprintf(out, "%s%s%s%s", csv_sep, csv_sep, csv_sep, csv_sep);
+ return;
+ }
+ fprintf(out, "%s%" PRIu64 "%s%.2f%s",
+ csv_sep,
+ os->run,
+ csv_sep,
+ os->ena ? 100.0 * os->run / os->ena : 100.0,
+ csv_sep);
+ snprintf(buf, sizeof(buf), fmt, val);
+ vals = buf;
+ while (isspace(*vals))
+ vals++;
+ ends = vals;
+ while (isdigit(*ends) || *ends == '.')
+ ends++;
+ *ends = 0;
+ while (isspace(*unit))
+ unit++;
+ fprintf(out, "%s%s%s", vals, csv_sep, unit);
+}
+
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
FILE *output = stat_config.output;
@@ -600,6 +645,25 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
else
nl = new_line_std;
+ if (csv_output) {
+ static int aggr_fields[] = {
+ [AGGR_GLOBAL] = 0,
+ [AGGR_THREAD] = 1,
+ [AGGR_NONE] = 1,
+ [AGGR_SOCKET] = 2,
+ [AGGR_CORE] = 2,
+ };
+
+ pm = print_metric_csv;
+ nl = new_line_csv;
+ os.nfields = 1;
+ os.nfields += aggr_fields[stat_config.aggr_mode];
+ if (counter->cgrp)
+ os.nfields++;
+ os.run = run;
+ os.ena = ena;
+ }
+
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
--
2.4.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] perf tools: Fix build errors with mipsel-linux-uclibc compiler
This commit breaks the perf tool MIPS build because MIPS doesn't have
CONFIG_PERF_REGS=y in .config-detected:
commit bcc84ec65ad1bd9f777a1fade6f8e5e0c5808fa5
Author: Stephane Eranian
Date: Mon Aug 31 18:41:12 2015 +0200
perf record: Add ability to name registers to record
On Fri, Sep 4, 2015 at 3:19 PM, Petri Gynther wrote:
> I see that this patch is now in upstream. However, something else has
> now broken the perf tool MIPS build:
>
> linux/tools$ git describe
> v4.2-7656-g51e771c
>
> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
> mkdir -p .
> make --no-print-directory -C perf O= subdir=
> BUILD: Doing 'make -j12' parallel build
>
> Auto-detecting system features:
> ... dwarf: [ OFF ]
> ... glibc: [ on ]
> ... gtk2: [ OFF ]
> ... libaudit: [ OFF ]
> ...libbfd: [ OFF ]
> ...libelf: [ OFF ]
> ... libnuma: [ OFF ]
> ... libperl: [ OFF ]
> ... libpython: [ OFF ]
> ... libslang: [ OFF ]
> ... libunwind: [ OFF ]
> ...libdw-dwarf-unwind: [ OFF ]
> ... zlib: [ OFF ]
> ... lzma: [ OFF ]
>
> ...
>
> AR libperf.a
> LINK perf
> libperf.a(libperf-in.o): In function `parse_regs':
> (.text+0x9f5b4): undefined reference to `sample_reg_masks'
> libperf.a(libperf-in.o): In function `parse_regs':
> (.text+0x9f604): undefined reference to `sample_reg_masks'
> libperf.a(libperf-in.o): In function `parse_regs':
> (.text+0x9f708): undefined reference to `sample_reg_masks'
> collect2: error: ld returned 1 exit status
> make[2]: *** [perf] Error 1
> make[1]: *** [all] Error 2
> make: *** [perf] Error 2
>
> On Tue, Aug 4, 2015 at 5:38 PM, Petri Gynther wrote:
>> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
>> ...
>> config/Makefile:256: *** No gnu/libc-version.h found, please install
>> glibc-dev[el]. Stop.
>> make[1]: *** [all] Error 2
>> make: *** [perf] Error 2
>>
>> ...
>> In file included from builtin-sched.c:13:0:
>> util/cloexec.h:8:12: error: redundant redeclaration of ‘sched_getcpu’
>> [-Werror=redundant-decls]
>> extern int sched_getcpu(void) __THROW;
>>
>> mipsel-buildroot-linux-uclibc/sysroot/usr/include/bits/sched.h:88:12:
>> note: previous declaration of ‘sched_getcpu’ was here
>> extern int sched_getcpu (void) __THROW;
>>
>> uclibc info:
>> sysroot/usr/include/bits/uClibc_config.h
>> __UCLIBC_MAJOR__ 0
>> __UCLIBC_MINOR__ 9
>> __UCLIBC_SUBLEVEL__ 33
>>
>> sysroot/usr/include/features.h
>> __UCLIBC__ 1
>> __GLIBC__ 2
>> __GLIBC_MINOR__ 2
>>
>> Signed-off-by: Petri Gynther
>> ---
>> tools/build/feature/test-glibc.c | 11 +++
>> tools/perf/util/cloexec.h| 2 +-
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/build/feature/test-glibc.c
>> b/tools/build/feature/test-glibc.c
>> index b082034..9367f75 100644
>> --- a/tools/build/feature/test-glibc.c
>> +++ b/tools/build/feature/test-glibc.c
>> @@ -1,8 +1,19 @@
>> +#include
>> +
>> +#if !defined(__UCLIBC__)
>> #include
>> +#else
>> +#define XSTR(s) STR(s)
>> +#define STR(s) #s
>> +#endif
>>
>> int main(void)
>> {
>> +#if !defined(__UCLIBC__)
>> const char *version = gnu_get_libc_version();
>> +#else
>> + const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
>> +#endif
>>
>> return (long)version;
>> }
>> diff --git a/tools/perf/util/cloexec.h b/tools/perf/util/cloexec.h
>> index 6c2..3bee677 100644
>> --- a/tools/perf/util/cloexec.h
>> +++ b/tools/perf/util/cloexec.h
>> @@ -4,7 +4,7 @@
>> unsigned long perf_event_open_cloexec_flag(void);
>>
>> #ifdef __GLIBC_PREREQ
>> -#if !__GLIBC_PREREQ(2, 6)
>> +#if !__GLIBC_PREREQ(2, 6) && !defined(__UCLIBC__)
>> extern int sched_getcpu(void) __THROW;
>> #endif
>> #endif
>> --
>> 2.5.0.rc2.392.g76e840b
>>
--
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] csiostor:Fix backwards locking in the function __csio_unreg_rnode
> -Original Message- > From: Nicholas Krause [mailto:xerofo...@gmail.com] > Sent: Thursday, September 3, 2015 10:09 AM > To: jbottom...@odin.com > Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish > Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] csiostor:Fix backwards locking in the function > __csio_unreg_rnode > > This fixes backwards locking in the function __csio_unreg_rnode to properly > lock before the call to the function csio_unreg_rnode and not unlock with > spin_unlock_irq as this would not allow the proper protection for concurrent > access on the shared csio_hw structure pointer hw. In addition switch the > locking after the critical region function call to properly unlock instead > with > spin_unlock_irq on the shared structure pointer. > > Signed-off-by: Nicholas Krause > --- > drivers/scsi/csiostor/csio_rnode.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/csiostor/csio_rnode.c > b/drivers/scsi/csiostor/csio_rnode.c > index e9c3b04..029a09e 100644 > --- a/drivers/scsi/csiostor/csio_rnode.c > +++ b/drivers/scsi/csiostor/csio_rnode.c > @@ -580,9 +580,9 @@ __csio_unreg_rnode(struct csio_rnode *rn) > ln->last_scan_ntgts--; > } > > - spin_unlock_irq(&hw->lock); > - csio_unreg_rnode(rn); > spin_lock_irq(&hw->lock); > + csio_unreg_rnode(rn); > + spin_unlock_irq(&hw->lock); > > /* Cleanup I/Os that were waiting for rnode to unregister */ > if (cmpl) > -- > 2.1.4 NACK, function is called with lock held. -- 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 6/6] ebpf: allow BPF_REG_X in src_reg conditional jumps
Hi Alexei,
On Fri, Sep 04, 2015 at 02:06:19PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 10:04:24AM -0600, Tycho Andersen wrote:
> > The classic converter generates conditional jumps with:
> >
> > if (BPF_SRC(fp->code) == BPF_K && (int) fp->k < 0) {
> > ...
> > } else {
> > insn->dst_reg = BPF_REG_A;
> > insn->src_reg = BPF_REG_X;
> > insn->imm = fp->k;
> > bpf_src = BPF_SRC(fp->code);
> > }
> >
> > but here, we enforce that the src_reg == BPF_REG_0. We should also allow
> > BPF_REG_X since that's what the converter generates; this enables us to
> > load eBPF programs that were generated by the converter.
>
> good catch. classic->extended converter is just being untidy.
> It shouldn't be populating unused 'src_reg' field when BPF_SRC == BPF_K
> verifier is doing the right thing. It's rejecting instructions that
> have junk in unused fields to make sure that someday we can extend it
> with something useful.
> The fix should be something like this:
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 13079f03902e..05a04ea87172 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -478,9 +478,9 @@ do_pass:
> bpf_src = BPF_X;
> } else {
> insn->dst_reg = BPF_REG_A;
> - insn->src_reg = BPF_REG_X;
> insn->imm = fp->k;
> bpf_src = BPF_SRC(fp->code);
> + insn->src_reg = bpf_src == BPF_X ? BPF_REG_X
> : 0;
> }
Yep, I just tested this and it works for me. Do you want to manage it
or should I carry it as part of this set?
Tycho
--
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/5] perf,tools: Support new sort type --socket
Em Fri, Sep 04, 2015 at 10:45:43AM -0400, kan.li...@intel.com escreveu:
> From: Kan Liang
>
> This patch enable perf report to sort by processor socket
>
> $ perf report --stdio --sort socket,comm,dso,symbol
> # To display the perf.data header info, please use
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 686 of event 'cycles'
> # Event count (approx.): 349215462
> #
> # Overhead SOCKET CommandShared Object Symbol
> # .. .
> .
So this works in 'perf top' only for the first screen rendering, when it
refreshes we lose the "SOCKET" header (why all caps?) and the colum
stops being %03d and instead becomes %d, I am checking now.
- Arnaldo
> #
> 97.05% 000 test test [.] plusB_c
> 0.98% 000 test test [.] plusA_c
> 0.93% 001 perf [kernel.vmlinux] [k]
> smp_call_function_single
> 0.19% 001 perf [kernel.vmlinux] [k] page_fault
> 0.19% 001 swapper[kernel.vmlinux] [k] pm_qos_request
> 0.16% 000 test [kernel.vmlinux] [k] add_mm_counter_fast
>
> Signed-off-by: Kan Liang
> ---
> tools/perf/Documentation/perf-report.txt | 3 ++-
> tools/perf/util/hist.h | 1 +
> tools/perf/util/sort.c | 22 ++
> tools/perf/util/sort.h | 1 +
> 4 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/Documentation/perf-report.txt
> b/tools/perf/Documentation/perf-report.txt
> index 9c7981b..92361a7 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -68,7 +68,7 @@ OPTIONS
> --sort=::
> Sort histogram entries by given key(s) - multiple keys can be specified
> in CSV format. Following sort keys are available:
> - pid, comm, dso, symbol, parent, cpu, srcline, weight, local_weight.
> + pid, comm, dso, symbol, parent, cpu, socket, srcline, weight,
> local_weight.
>
> Each key has following meaning:
>
> @@ -79,6 +79,7 @@ OPTIONS
> - parent: name of function matched to the parent regex filter. Unmatched
> entries are displayed as "[other]".
> - cpu: cpu number the task ran at the time of sample
> + - socket: processor socket number the task ran at the time of sample
> - srcline: filename and line number executed at the time of sample. The
> DWARF debugging info must be provided.
> - srcfile: file name of the source file of the same. Requires dwarf
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index de6d58e..5d04d28 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -29,6 +29,7 @@ enum hist_column {
> HISTC_COMM,
> HISTC_PARENT,
> HISTC_CPU,
> + HISTC_SOCKET,
> HISTC_SRCLINE,
> HISTC_SRCFILE,
> HISTC_MISPREDICT,
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index a97bcee..c4a32b9 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -421,6 +421,27 @@ struct sort_entry sort_cpu = {
> .se_width_idx = HISTC_CPU,
> };
>
> +/* --sort socket */
> +
> +static int64_t
> +sort__socket_cmp(struct hist_entry *left, struct hist_entry *right)
> +{
> + return right->socket - left->socket;
> +}
> +
> +static int hist_entry__socket_snprintf(struct hist_entry *he, char *bf,
> + size_t size, unsigned int width)
> +{
> + return repsep_snprintf(bf, size, "%*.*d", width, width-3, he->socket);
> +}
> +
> +struct sort_entry sort_socket = {
> + .se_header = "SOCKET",
> + .se_cmp = sort__socket_cmp,
> + .se_snprintf= hist_entry__socket_snprintf,
> + .se_width_idx = HISTC_SOCKET,
> +};
> +
> /* sort keys for branch stacks */
>
> static int64_t
> @@ -1248,6 +1269,7 @@ static struct sort_dimension common_sort_dimensions[] =
> {
> DIM(SORT_SYM, "symbol", sort_sym),
> DIM(SORT_PARENT, "parent", sort_parent),
> DIM(SORT_CPU, "cpu", sort_cpu),
> + DIM(SORT_SOCKET, "socket", sort_socket),
> DIM(SORT_SRCLINE, "srcline", sort_srcline),
> DIM(SORT_SRCFILE, "srcfile", sort_srcfile),
> DIM(SORT_LOCAL_WEIGHT, "local_weight", sort_local_weight),
> diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> index 7cf1cf7..654ac8a 100644
> --- a/tools/perf/util/sort.h
> +++ b/tools/perf/util/sort.h
> @@ -173,6 +173,7 @@ enum sort_type {
> SORT_SYM,
> SORT_PARENT,
> SORT_CPU,
> + SORT_SOCKET,
> SORT_SRCLINE,
> SORT_SRCFILE,
> SORT_LOCAL_WEIGHT,
> --
> 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: [PATCH v7 2/3] KVM: dynamic halt-polling
Hi Paolo,
On 9/3/15 10:07 PM, Wanpeng Li wrote:
[...]
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
if (kvm_arch_vcpu_runnable(vcpu)) {
@@ -1928,7 +1962,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
{
ktime_t start, cur;
DEFINE_WAIT(wait);
- bool waited = false;
+ bool polled = false, waited = false;
+ u64 poll_ns = 0, wait_ns = 0, block_ns = 0;
start = cur = ktime_get();
if (vcpu->halt_poll_ns) {
@@ -1940,11 +1975,16 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
* arrives.
*/
if (kvm_vcpu_check_block(vcpu) < 0) {
+ polled = true;
++vcpu->stat.halt_successful_poll;
- goto out;
+ break;
}
cur = ktime_get();
} while (single_task_running() && ktime_before(cur, stop));
+
+ poll_ns = ktime_to_ns(cur) - ktime_to_ns(start);
+ if (polled)
+ goto out;
Please move poll_ns caculation under if() when you applied, as I
explained in reply to v6.
Regards,
Wanpeng Li
--
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] Docs: dt: Add PCI MSI map bindings
Hi Mark, First of all: Thanks for working on this. I now have a prototype implementation for irq-gic-v3-its.c that is using this binding on Cavium's ThunderX platform. Q: Have you guys had any more thoughts on this that might require changing the binding? If not, I will be sending out my patches for your consideration. Thanks, David Daney On 07/27/2015 01:16 AM, Marc Zyngier wrote: On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used by a few bindings to describe the relationship between a PCI root complex and a single MSI controller, but this property does not have a generic binding document. Additionally, msi-parent is insufficient to describe more complex relationships between MSI controllers and devices under a root complex, where devices may be able to target multiple MSI controllers, or where MSI controllers use (non-probeable) sideband information to distinguish devices. This patch adds a generic binding for mapping PCI devices to MSI controllers. This document covers msi-parent, and a new msi-map property (specific to PCI*) which may be used to map devices (identified by their Requester ID) to sideband data for each MSI controller that they may target. Signed-off-by: Mark Rutland Acked-by: David Daney --- Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++ 1 file changed, 220 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt new file mode 100644 index 000..9b3cc81 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt @@ -0,0 +1,220 @@ +This document describes the generic device tree binding for describing the +relationship between PCI devices and MSI controllers. + +Each PCI device under a root complex is uniquely identified by its Requester ID +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and +Function number. + +For the purpose of this document, when treated as a numeric value, a RID is +formatted such that: + +* Bits [15:8] are the Bus number. +* Bits [7:3] are the Device number. +* Bits [2:0] are the Function number. +* Any other bits required for padding must be zero. + +MSIs may be distinguished in part through the use of sideband data accompanying +writes. In the case of PCI devices, this sideband data may be derived from the +Requester ID. A mechanism is required to associate a device with both the MSI +controllers it can address, and the sideband data that will be associated with +its writes to those controllers. + +For generic MSI bindings, see +Documentation/devicetree/bindings/interrupt-controller/msi.txt. + + +PCI root complex + + +Optional properties +--- + +- msi-map: Maps a Requester ID to an MSI controller and associated + msi-specifier data. The property is an arbitrary number of tuples of + (rid-base,msi-controller,msi-base,length), where: + + * rid-base is a single cell describing the first RID matched by the entry. + + * msi-controller is a single phandle to an MSI controller + + * msi-base is an msi-specifier describing the msi-specifier produced for the +first RID matched by the entry. + + * length is a single cell describing how many consecutive RIDs are matched +following the rid-base. + + Any RID r in the interval [rid-base, rid-base + length) is associated with + the listed msi-controller, with the msi-specifier (r - rid-base + msi-base). + +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped + to an msi-specifier per the msi-map property. + +- msi-parent: Describes the MSI parent of the root complex itself. Where + the root complex and MSI controller do not pass sideband data with MSI + writes, this property may be used to describe the MSI controller(s) + used by PCI devices under the root complex, if defined as such in the + binding for the root complex. Right, this is where I'd expect some details about #msi-cells. Is it meant to be ignored? The lack of symmetry between the PCI and non-PCI use cases feels a bit inelegant (not to mention that it precludes having an unified parser for both cases). This otherwise looks good to me. Thanks, M. -- 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 3/6] ebpf: add a way to dump an eBPF program
On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: > On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen > wrote: > > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: > >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > >> wrote: > >> > This commit adds a way to dump eBPF programs. The initial implementation > >> > doesn't support maps, and therefore only allows dumping seccomp ebpf > >> > programs which themselves don't currently support maps. > >> > > >> > We export the GPL bit as well as a unique ID for the program so that > >> > >> This unique ID appears to be the heap address for the prog. That's a > >> huge leak, and should not be done. We don't want to introduce new > >> kernel address leaks while we're trying to fix the remaining ones. > >> Shouldn't the "unique ID" be the fd itself? I imagine KCMP_FILE > >> could be used, for example. > > > > No; we acquire the fd per process, so if a task installs a filter and > > then forks N times, we'll grab N (+1) copies of the filter from N (+1) > > different file descriptors. Ideally, we'd have some way to figure out > > that these were all the same. Some sort of prog_id is one way, > > although there may be others. > > I disagree a bit. I think we want the actual hierarchy to be a > well-defined thing, because I have plans to make the hierarchy > actually do something. That means that we'll need to have a more > exact way to dump the hierarchy than "these two filters are identical" > or "these two filters are not identical". Can you elaborate on what this would look like? I think with the "these two filters are the same" primitive (the same in the sense that they were inherited during a fork, not just that memcmp(filter1->insns, filter2->insns) == 0) you can infer the entire hierarchy, however clunky it may be to do so. Another issue is that KCMP_FILE won't work in this case, as it effectively compares the struct file *, which will be different since we need to call anon_inode_getfd() for each call of ptrace(PTRACE_SECCOMP_GET_FILTER_FD). We could add a KCMP_BPF (or just a KCMP_FILE_PRIVATE_DATA, since that's effectively what it would be). Does that make sense? [added Cyrill] Tycho -- 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] cpufreq: Add ARM_MT8173_CPUFREQ dependencyon THERMAL
Hi,
On Fri, Sep 4, 2015 at 9:01 PM, Olof Johansson wrote:
> On Thu, Sep 3, 2015 at 8:50 AM, Viresh Kumar wrote:
>> On 03-09-15, 08:20, Guenter Roeck wrote:
>>> If ARM_MT8173_CPUFREQ is configured, and THERMAL is configured as module,
>>> the following build error is seen for arm:allmodconfig and
>>> arm64:allmodconfig.
>>>
>>> drivers/built-in.o: In function `mtk_cpufreq_ready':
>>> :(.text+0x32a20c): undefined reference to `of_cpufreq_cooling_register'
>>> drivers/built-in.o: In function `mtk_cpufreq_exit':
>>> :(.text+0x32a420): undefined reference to `cpufreq_cooling_unregister'
>>>
>>> The fix is similar to CPUFREQ_DT, but more restrictive since
>>> ARM_MT8173_CPUFREQ can not be built as module.
>>>
>>> Fixes: 1453863fb02a ("cpufreq: mediatek: Add MT8173 cpufreq driver")
>>> Signed-off-by: Guenter Roeck
>>> ---
>>> It might also make sense to declare ARM_MT8173_CPUFREQ as tristate
>>> and relax the conditions, but I don't know if that is feasible.
>>>
>>> drivers/cpufreq/Kconfig.arm | 1 +
>>> 1 file changed, 1 insertion(+)
>>
>> Acked-by: Viresh Kumar
>
> Who's applying and sending this up to avoid extended period of build breakage?
I'll queue up this particular one.
Thanks,
Rafael
--
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: Fix build errors with mipsel-linux-uclibc compiler
I see that this patch is now in upstream. However, something else has
now broken the perf tool MIPS build:
linux/tools$ git describe
v4.2-7656-g51e771c
linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
mkdir -p .
make --no-print-directory -C perf O= subdir=
BUILD: Doing 'make -j12' parallel build
Auto-detecting system features:
... dwarf: [ OFF ]
... glibc: [ on ]
... gtk2: [ OFF ]
... libaudit: [ OFF ]
...libbfd: [ OFF ]
...libelf: [ OFF ]
... libnuma: [ OFF ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ OFF ]
... libunwind: [ OFF ]
...libdw-dwarf-unwind: [ OFF ]
... zlib: [ OFF ]
... lzma: [ OFF ]
...
AR libperf.a
LINK perf
libperf.a(libperf-in.o): In function `parse_regs':
(.text+0x9f5b4): undefined reference to `sample_reg_masks'
libperf.a(libperf-in.o): In function `parse_regs':
(.text+0x9f604): undefined reference to `sample_reg_masks'
libperf.a(libperf-in.o): In function `parse_regs':
(.text+0x9f708): undefined reference to `sample_reg_masks'
collect2: error: ld returned 1 exit status
make[2]: *** [perf] Error 1
make[1]: *** [all] Error 2
make: *** [perf] Error 2
On Tue, Aug 4, 2015 at 5:38 PM, Petri Gynther wrote:
> linux/tools$ make ARCH=mips CROSS_COMPILE=mipsel-linux- perf
> ...
> config/Makefile:256: *** No gnu/libc-version.h found, please install
> glibc-dev[el]. Stop.
> make[1]: *** [all] Error 2
> make: *** [perf] Error 2
>
> ...
> In file included from builtin-sched.c:13:0:
> util/cloexec.h:8:12: error: redundant redeclaration of ‘sched_getcpu’
> [-Werror=redundant-decls]
> extern int sched_getcpu(void) __THROW;
>
> mipsel-buildroot-linux-uclibc/sysroot/usr/include/bits/sched.h:88:12:
> note: previous declaration of ‘sched_getcpu’ was here
> extern int sched_getcpu (void) __THROW;
>
> uclibc info:
> sysroot/usr/include/bits/uClibc_config.h
> __UCLIBC_MAJOR__ 0
> __UCLIBC_MINOR__ 9
> __UCLIBC_SUBLEVEL__ 33
>
> sysroot/usr/include/features.h
> __UCLIBC__ 1
> __GLIBC__ 2
> __GLIBC_MINOR__ 2
>
> Signed-off-by: Petri Gynther
> ---
> tools/build/feature/test-glibc.c | 11 +++
> tools/perf/util/cloexec.h| 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/tools/build/feature/test-glibc.c
> b/tools/build/feature/test-glibc.c
> index b082034..9367f75 100644
> --- a/tools/build/feature/test-glibc.c
> +++ b/tools/build/feature/test-glibc.c
> @@ -1,8 +1,19 @@
> +#include
> +
> +#if !defined(__UCLIBC__)
> #include
> +#else
> +#define XSTR(s) STR(s)
> +#define STR(s) #s
> +#endif
>
> int main(void)
> {
> +#if !defined(__UCLIBC__)
> const char *version = gnu_get_libc_version();
> +#else
> + const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> +#endif
>
> return (long)version;
> }
> diff --git a/tools/perf/util/cloexec.h b/tools/perf/util/cloexec.h
> index 6c2..3bee677 100644
> --- a/tools/perf/util/cloexec.h
> +++ b/tools/perf/util/cloexec.h
> @@ -4,7 +4,7 @@
> unsigned long perf_event_open_cloexec_flag(void);
>
> #ifdef __GLIBC_PREREQ
> -#if !__GLIBC_PREREQ(2, 6)
> +#if !__GLIBC_PREREQ(2, 6) && !defined(__UCLIBC__)
> extern int sched_getcpu(void) __THROW;
> #endif
> #endif
> --
> 2.5.0.rc2.392.g76e840b
>
--
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 4/5] perf,tools: zoom in/out for processor socket
On Fri, Sep 04, 2015 at 10:45:45AM -0400, kan.li...@intel.com wrote: > From: Kan Liang > > Currently, users can zoom in/out for threads and dso in perf top and > report. This patch extends it for socket. > 'S' is the short key to zoom into current Processor Socket. Nice feature. Would be nice to also able to zoom into the current logical CPU. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: [4.2, Regression] Queued spinlocks cause major XFS performance regression
On Fri, Sep 04, 2015 at 01:32:33PM +0200, Peter Zijlstra wrote: > On Fri, Sep 04, 2015 at 06:12:34PM +1000, Dave Chinner wrote: > > You probably don't even need a VM to reproduce it - that would > > certainly be an interesting counterpoint if it didn't > > Even though you managed to restore your DEBUG_SPINLOCK performance by > changing virt_queued_spin_lock() to use __delay(1), I ran the thing on > actual hardware just to test. > > [ Note: In any case, I would recommend you use (or at least try) > PARAVIRT_SPINLOCKS if you use VMs, as that is where we were looking for > performance, the test-and-set fallback really wasn't meant as a > performance option (although it clearly sucks worse than expected). I will try it, but that can happen when I've got a bit of spare time... > Pre qspinlock, your setup would have used regular ticket locks on > vCPUs, which mostly works as long as there is almost no vCPU > preemption, if you overload your machine such that the vCPU threads > get preempted that will implode into silly-land. ] I don't tend to overload the host CPUs - all my test loads are IO bound - so this has never really been a problem I've noticed in the past. > So on to native performance: > > - IVB-EX, 4-socket, 15 core, hyperthreaded, for a total of 120 CPUs > - 1.1T of md-stripe (5x200GB) SSDs > - Linux v4.2 (distro style .config) > - Debian "testing" base system > - xfsprogs v3.2.1 > > > # mkfs.xfs -f -m "crc=1,finobt=1" /dev/md0 If you use xfsprogs v3.2.4 (current debian unstable) these are the default options. > log stripe unit (524288 bytes) is too large (maximum is 256KiB) > log stripe unit adjusted to 32KiB > meta-data=/dev/md0 isize=512agcount=32, agsize=9157504 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1finobt=1 > data = bsize=4096 blocks=293038720, imaxpct=5 > = sunit=128swidth=640 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > log =internal log bsize=4096 blocks=143088, version=2 > = sectsz=512 sunit=8 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > # mount -o logbsize=262144,nobarrier /dev/md0 /mnt/scratch > > # ./fs_mark -D 1 -S0 -n 5 -s 0 -L 32 \ > -d /mnt/scratch/0 -d /mnt/scratch/1 \ > -d /mnt/scratch/2 -d /mnt/scratch/3 \ > -d /mnt/scratch/4 -d /mnt/scratch/5 \ > -d /mnt/scratch/6 -d /mnt/scratch/7 \ > -d /mnt/scratch/8 -d /mnt/scratch/9 \ > -d /mnt/scratch/10 -d /mnt/scratch/11 \ > -d /mnt/scratch/12 -d /mnt/scratch/13 \ > -d /mnt/scratch/14 -d /mnt/scratch/15 \ > > > Regular v4.2 (qspinlock) does: > > 0 6400 286491.9 3500179 > 0 7200 293229.5 3963140 > 0 8000 271182.4 3708212 > 0 8800 300592.0 3595722 > > Modified v4.2 (ticket) does: > > 0 6400 310419.6 3343821 > 0 7200 348346.5 4721133 > 0 8000 328098.2 3235753 > 0 8800 316765.3 3238971 > > > Which shows that qspinlock is clearly slower, even for these large-ish > NUMA boxes where it was supposed to be better. Be careful just reading the throughput numbers like that. You can have the files/s number go down, but the benchmark wall time get faster because the userspace portion runs faster (i.e. CPU cache residency effects). In this case, however, both the userspace time is down by 5-10% and the files/s is up by 5-10%, so (without knowing the wall time) I'd say that there is significance in these numbers FWIW. you've got a lot more CPUs than I have - you can scale up the parallelism of the workload by increasing the number of working directories (i.e. -d options). You'd also need to scale up the amount of allocation concurrency in XFS - 32 AGs will be the limiting factor for any more workload concurrency. i.e. use "-d agcount=" on the mkfs.xfs command line to increase the AG count. For artificial scalability testing like this, you want the AG count ot be at least 2x the number of directories you are working in concurrently. > Clearly our benchmarks used before this were not sufficient, and more > works needs to be done. > > > Also, I note that after running to completion, there is only 14G of > actual data on the device, so you don't need silly large storage to run > this -- I expect your previous 275G quote was due to XFS populating the > sparse file with meta-data or something along those lines. Yeah, that would have been after lots of other work being done on the sparse file I use to bac
[PATCH 4/5] perf,tools: zoom in/out for processor socket
From: Kan Liang
Currently, users can zoom in/out for threads and dso in perf top and
report. This patch extends it for socket.
'S' is the short key to zoom into current Processor Socket.
Signed-off-by: Kan Liang
---
tools/perf/ui/browsers/hists.c | 43 +-
tools/perf/util/hist.c | 19 +++
tools/perf/util/hist.h | 1 +
3 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 457f24c..d695fd2 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1429,6 +1429,7 @@ struct popup_action {
struct thread *thread;
struct dso *dso;
struct map_symbol ms;
+ int socket;
int (*fn)(struct hist_browser *browser, struct popup_action *act);
};
@@ -1676,6 +1677,37 @@ add_exit_opt(struct hist_browser *browser __maybe_unused,
return 1;
}
+static int
+do_zoom_socket(struct hist_browser *browser, struct popup_action *act)
+{
+ if (browser->hists->socket_filter > -1)
+ browser->hists->socket_filter = -1;
+ else
+ browser->hists->socket_filter = act->socket;
+
+ perf_hpp__set_elide(HISTC_SOCKET, false);
+ hists__filter_by_socket(browser->hists);
+ hist_browser__reset(browser);
+ return 0;
+}
+
+static int
+add_socket_opt(struct hist_browser *browser, struct popup_action *act,
+ char **optstr, int socket)
+{
+ if (socket < 0)
+ return 0;
+
+ if (asprintf(optstr, "Zoom %s Processor Socket %d",
+(browser->hists->socket_filter > -1) ? "out of" : "into",
+socket) < 0)
+ return 0;
+
+ act->socket = socket;
+ act->fn = do_zoom_socket;
+ return 1;
+}
+
static void hist_browser__update_nr_entries(struct hist_browser *hb)
{
u64 nr_entries = 0;
@@ -1729,6 +1761,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
"E Expand all callchains\n" \
"F Toggle percentage of filtered entries\n" \
"H Display column headers\n"\
+ "S Zoom into current Processor Socket\n"\
/* help messages are sorted by lexical order of the hotkey */
const char report_help[] = HIST_BROWSER_HELP_COMMON
@@ -1778,6 +1811,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
struct thread *thread = NULL;
struct dso *dso = NULL;
int choice = 0;
+ int socket = -1;
nr_options = 0;
@@ -1786,6 +1820,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (browser->he_selection != NULL) {
thread = hist_browser__selected_thread(browser);
dso = browser->selection->map ?
browser->selection->map->dso : NULL;
+ socket = browser->he_selection->socket;
}
switch (key) {
case K_TAB:
@@ -1828,6 +1863,10 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
actions->thread = thread;
do_zoom_thread(browser, actions);
continue;
+ case 'S':
+ actions->socket = socket;
+ do_zoom_socket(browser, actions);
+ continue;
case '/':
if (ui_browser__input_window("Symbol to show",
"Please enter the name of symbol you
want to see",
@@ -1973,7 +2012,9 @@ skip_annotation:
nr_options += add_map_opt(browser, &actions[nr_options],
&options[nr_options],
browser->selection->map);
-
+ nr_options += add_socket_opt(browser, &actions[nr_options],
+&options[nr_options],
+socket);
/* perf script support */
if (browser->he_selection) {
nr_options += add_script_opt(browser,
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index d7e53c2..bb633cd 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1308,6 +1308,25 @@ static bool hists__filter_entry_by_socket(struct hists
*hists,
return false;
}
+void hists__filter_by_socket(struct hists *hists)
+{
+ struct rb_node *nd;
+
+ hists->stats.nr_non_filtered_samples = 0;
+
+ hists__reset_filter_stats(hists);
+ hists__reset_col_len(hists);
+
+ for (nd = rb_first(&hists->entries); n
[PATCH 2/5] perf,tools: Support new sort type --socket
From: Kan Liang
This patch enable perf report to sort by processor socket
$ perf report --stdio --sort socket,comm,dso,symbol
# To display the perf.data header info, please use
--header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 686 of event 'cycles'
# Event count (approx.): 349215462
#
# Overhead SOCKET CommandShared Object Symbol
# .. .
.
#
97.05% 000 test test [.] plusB_c
0.98% 000 test test [.] plusA_c
0.93% 001 perf [kernel.vmlinux] [k]
smp_call_function_single
0.19% 001 perf [kernel.vmlinux] [k] page_fault
0.19% 001 swapper[kernel.vmlinux] [k] pm_qos_request
0.16% 000 test [kernel.vmlinux] [k] add_mm_counter_fast
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-report.txt | 3 ++-
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 22 ++
tools/perf/util/sort.h | 1 +
4 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 9c7981b..92361a7 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -68,7 +68,7 @@ OPTIONS
--sort=::
Sort histogram entries by given key(s) - multiple keys can be specified
in CSV format. Following sort keys are available:
- pid, comm, dso, symbol, parent, cpu, srcline, weight, local_weight.
+ pid, comm, dso, symbol, parent, cpu, socket, srcline, weight,
local_weight.
Each key has following meaning:
@@ -79,6 +79,7 @@ OPTIONS
- parent: name of function matched to the parent regex filter. Unmatched
entries are displayed as "[other]".
- cpu: cpu number the task ran at the time of sample
+ - socket: processor socket number the task ran at the time of sample
- srcline: filename and line number executed at the time of sample. The
DWARF debugging info must be provided.
- srcfile: file name of the source file of the same. Requires dwarf
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index de6d58e..5d04d28 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -29,6 +29,7 @@ enum hist_column {
HISTC_COMM,
HISTC_PARENT,
HISTC_CPU,
+ HISTC_SOCKET,
HISTC_SRCLINE,
HISTC_SRCFILE,
HISTC_MISPREDICT,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index a97bcee..c4a32b9 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -421,6 +421,27 @@ struct sort_entry sort_cpu = {
.se_width_idx = HISTC_CPU,
};
+/* --sort socket */
+
+static int64_t
+sort__socket_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+ return right->socket - left->socket;
+}
+
+static int hist_entry__socket_snprintf(struct hist_entry *he, char *bf,
+ size_t size, unsigned int width)
+{
+ return repsep_snprintf(bf, size, "%*.*d", width, width-3, he->socket);
+}
+
+struct sort_entry sort_socket = {
+ .se_header = "SOCKET",
+ .se_cmp = sort__socket_cmp,
+ .se_snprintf= hist_entry__socket_snprintf,
+ .se_width_idx = HISTC_SOCKET,
+};
+
/* sort keys for branch stacks */
static int64_t
@@ -1248,6 +1269,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_SYM, "symbol", sort_sym),
DIM(SORT_PARENT, "parent", sort_parent),
DIM(SORT_CPU, "cpu", sort_cpu),
+ DIM(SORT_SOCKET, "socket", sort_socket),
DIM(SORT_SRCLINE, "srcline", sort_srcline),
DIM(SORT_SRCFILE, "srcfile", sort_srcfile),
DIM(SORT_LOCAL_WEIGHT, "local_weight", sort_local_weight),
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 7cf1cf7..654ac8a 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -173,6 +173,7 @@ enum sort_type {
SORT_SYM,
SORT_PARENT,
SORT_CPU,
+ SORT_SOCKET,
SORT_SRCLINE,
SORT_SRCFILE,
SORT_LOCAL_WEIGHT,
--
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/
[PATCH 1/5] perf,tools: add processor socket info in hist_entry and addr_location
From: Kan Liang
Add processor socket id info in hist_entry and addr_location.
For perf report, the socket id info is from perf.data.
For others, the socket id info is from current system.
Signed-off-by: Kan Liang
---
tools/perf/builtin-report.c | 4
tools/perf/util/event.c | 1 +
tools/perf/util/hist.c | 1 +
tools/perf/util/sort.h | 1 +
tools/perf/util/symbol.h| 1 +
5 files changed, 8 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 62b285e..affd70d 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -149,6 +149,7 @@ static int process_sample_event(struct perf_tool *tool,
.add_entry_cb = hist_iter__report_callback,
};
int ret = 0;
+ struct perf_env *env = evsel->evlist->env;
if (perf_event__preprocess_sample(event, machine, &al, sample) < 0) {
pr_debug("problem processing %d event, skipping it.\n",
@@ -156,6 +157,9 @@ static int process_sample_event(struct perf_tool *tool,
return -1;
}
+ /* read socket id from perf.data for perf report */
+ al.socket = env->cpu[al.cpu].socket_id;
+
if (rep->hide_unresolved && al.sym == NULL)
goto out_put;
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 7ff6127..0bf8c98 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1021,6 +1021,7 @@ int perf_event__preprocess_sample(const union perf_event
*event,
al->sym = NULL;
al->cpu = sample->cpu;
+ al->socket = cpu_map__get_socket_id(al->cpu);
if (al->map) {
struct dso *dso = al->map->dso;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 08b6cd9..80c4683 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -452,6 +452,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
.map= al->map,
.sym= al->sym,
},
+ .socket = al->socket,
.cpu = al->cpu,
.cpumode = al->cpumode,
.ip = al->addr,
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 3c2a399..7cf1cf7 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -90,6 +90,7 @@ struct hist_entry {
struct comm *comm;
u64 ip;
u64 transaction;
+ s32 socket;
s32 cpu;
u8 cpumode;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 440ba8a..40073c6 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -191,6 +191,7 @@ struct addr_location {
u8filtered;
u8cpumode;
s32 cpu;
+ s32 socket;
};
struct symsrc {
--
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/
[PATCH 3/5] perf,report: introduce socket-filter option
From: Kan Liang
Introduce --socket-filter option for perf report to only show processor
socket that match with this filter.
perf report --socket-filter 1 --stdio
# To display the perf.data header info, please use
--header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 752 of event 'cycles'
# Event count (approx.): 350995599
# Processor Socket: 1
#
# Overhead CommandShared Object Symbol
# .
.
#
97.02% test test [.] plusB_c
0.97% test test [.] plusA_c
0.23% swapper[kernel.vmlinux] [k] acpi_idle_do_entry
0.09% rcu_sched [kernel.vmlinux] [k]
dyntick_save_progress_counter
0.01% swapper[kernel.vmlinux] [k] task_waking_fair
0.00% swapper[kernel.vmlinux] [k] run_timer_softirq
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-report.c | 11 +++
tools/perf/ui/browsers/hists.c | 4
tools/perf/util/hist.c | 16
tools/perf/util/hist.h | 4 +++-
5 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 92361a7..b941d5e 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -350,6 +350,9 @@ include::itrace.txt[]
This option extends the perf report to show reference callgraphs,
which collected by reference event, in no callgraph event.
+--socket-filter::
+ Only report the samples on the processor socket that match with this
filter
+
include::callchain-overhead-calculation.txt[]
SEE ALSO
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index affd70d..4b43245 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -62,6 +62,7 @@ struct report {
float min_percent;
u64 nr_entries;
u64 queue_size;
+ int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
@@ -290,6 +291,7 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*hists, struct report
struct perf_evsel *evsel = hists_to_evsel(hists);
char buf[512];
size_t size = sizeof(buf);
+ int socket = hists->socket_filter;
if (symbol_conf.filter_relative) {
nr_samples = hists->stats.nr_non_filtered_samples;
@@ -330,6 +332,10 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*hists, struct report
ret += fprintf(fp, "\n# Sort order : %s", sort_order ? :
default_mem_sort_order);
} else
ret += fprintf(fp, "\n# Event count (approx.): %" PRIu64,
nr_events);
+
+ if (socket > -1)
+ ret += fprintf(fp, "\n# Processor Socket: %d", socket);
+
return ret + fprintf(fp, "\n#\n");
}
@@ -454,6 +460,8 @@ static void report__collapse_hists(struct report *rep)
if (pos->idx == 0)
hists->symbol_filter_str = rep->symbol_filter_str;
+ hists->socket_filter = rep->socket_filter;
+
hists__collapse_resort(hists, &prog);
/* Non-group events are considered as leader */
@@ -639,6 +647,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
},
.max_stack = PERF_MAX_STACK_DEPTH,
.pretty_printing_style = "normal",
+ .socket_filter = -1,
};
const struct option options[] = {
OPT_STRING('i', "input", &input_name, "file",
@@ -751,6 +760,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Show full source file name path for source lines"),
OPT_BOOLEAN(0, "show-ref-call-graph", &symbol_conf.show_ref_callgraph,
"Show callgraph from reference event"),
+ OPT_INTEGER(0, "socket-filter", &report.socket_filter,
+ "only show processor socket that match with this filter"),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cf86f2d..457f24c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1261,6 +1261,7 @@ static int hists__browser_title(struct hists *hists,
int printed;
const struct dso *dso = hists->dso_filter;
const struct thread *thread = hists->thread_filter;
+ int socket = hists->socket_filter;
unsigned long nr_samples = hists->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = hists->stats.total_period;
struct perf_evsel *evsel = hists_to_evsel(hists);
@@ -1314,6 +1315,
[PATCH 5/5] perf,test: test hists socket filter
From: Kan Liang
Add test case for hists socket filter.
Signed-off-by: Kan Liang
---
tools/perf/tests/hists_filter.c | 55 +
1 file changed, 45 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/hists_filter.c b/tools/perf/tests/hists_filter.c
index ce48775..818acf8 100644
--- a/tools/perf/tests/hists_filter.c
+++ b/tools/perf/tests/hists_filter.c
@@ -16,30 +16,31 @@ struct sample {
struct thread *thread;
struct map *map;
struct symbol *sym;
+ int socket;
};
/* For the numbers, see hists_common.c */
static struct sample fake_samples[] = {
/* perf [kernel] schedule() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_KERNEL_SCHEDULE, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_KERNEL_SCHEDULE, .socket = 0 },
/* perf [perf] main() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_PERF_MAIN, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_PERF_MAIN, .socket = 0 },
/* perf [libc] malloc() */
- { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_LIBC_MALLOC, },
+ { .pid = FAKE_PID_PERF1, .ip = FAKE_IP_LIBC_MALLOC, .socket = 0 },
/* perf [perf] main() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_MAIN, }, /* will be merged
*/
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_MAIN, .socket = 0 }, /*
will be merged */
/* perf [perf] cmd_record() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_CMD_RECORD, },
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_PERF_CMD_RECORD, .socket = 1 },
/* perf [kernel] page_fault() */
- { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_KERNEL_PAGE_FAULT, },
+ { .pid = FAKE_PID_PERF2, .ip = FAKE_IP_KERNEL_PAGE_FAULT, .socket = 1 },
/* bash [bash] main() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_MAIN, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_MAIN, .socket = 2 },
/* bash [bash] xmalloc() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_XMALLOC, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_BASH_XMALLOC, .socket = 2 },
/* bash [libc] malloc() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_LIBC_MALLOC, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_LIBC_MALLOC, .socket = 3 },
/* bash [kernel] page_fault() */
- { .pid = FAKE_PID_BASH, .ip = FAKE_IP_KERNEL_PAGE_FAULT, },
+ { .pid = FAKE_PID_BASH, .ip = FAKE_IP_KERNEL_PAGE_FAULT, .socket = 3 },
};
static int add_hist_entries(struct perf_evlist *evlist,
@@ -83,6 +84,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
&sample) < 0)
goto out;
+ al.socket = fake_samples[i].socket;
if (hist_entry_iter__add(&iter, &al,
PERF_MAX_STACK_DEPTH, NULL) <
0) {
addr_location__put(&al);
@@ -253,6 +255,39 @@ int test__hists_filter(void)
TEST_ASSERT_VAL("Unmatched total period for symbol filter",
hists->stats.total_non_filtered_period == 300);
+ /* remove symbol filter first */
+ hists->symbol_filter_str = NULL;
+ hists__filter_by_symbol(hists);
+
+ /* now applying socket filters */
+ hists->socket_filter = 2;
+ hists__filter_by_socket(hists);
+
+ if (verbose > 2) {
+ pr_info("Histogram for socket filters\n");
+ print_hists_out(hists);
+ }
+
+ /* normal stats should be invariant */
+ TEST_ASSERT_VAL("Invalid nr samples",
+ hists->stats.nr_events[PERF_RECORD_SAMPLE] ==
10);
+ TEST_ASSERT_VAL("Invalid nr hist entries",
+ hists->nr_entries == 9);
+ TEST_ASSERT_VAL("Invalid total period",
+ hists->stats.total_period == 1000);
+
+ /* but filter stats are changed */
+ TEST_ASSERT_VAL("Unmatched nr samples for socket filter",
+ hists->stats.nr_non_filtered_samples == 2);
+ TEST_ASSERT_VAL("Unmatched nr hist entries for socket filter",
+ hists->nr_non_filtered_entries == 2);
+ TEST_ASSERT_VAL("Unmatched total period for socket filter",
+ hists->stats.total_non_filtered_period == 200);
+
+ /* remove socket filter first */
+ hists->socket_filter = -1;
+ hists__filter_by_socket(hists);
+
/* now applying all filters at once. */
hists->thread_filter = fake_samples[1].thread;
hists->dso_filter = fake_samples[1].map->dso;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-k
Re: [PATCH 2/6] seccomp: make underlying bpf ref counted as well
On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen wrote: > Additionally, we mark classic converted seccomp filters as seccomp eBPF > programs, since they are a subset of what is supported in seccomp eBPF. Off the top of my head, I'm okay with this. --Andy -- 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] ebpf: add a seccomp program type
On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
wrote:
> seccomp uses eBPF as its underlying storage and execution format, and eBPF
> has features that seccomp would like to make use of in the future. This
> patch adds a formal seccomp type to the eBPF verifier.
>
> The current implementation of the seccomp eBPF type is very limited, and
> doesn't support some interesting features (notably, maps) of eBPF. However,
> the primary motivation for this patchset is to enable checkpoint/restore
> for seccomp filters later in the series, to this limited feature set is ok
> for now.
>
> Signed-off-by: Tycho Andersen
> CC: Kees Cook
> CC: Will Drewry
> CC: Oleg Nesterov
> CC: Andy Lutomirski
> CC: Pavel Emelyanov
> CC: Serge E. Hallyn
> CC: Alexei Starovoitov
> CC: Daniel Borkmann
> ---
> include/uapi/linux/bpf.h | 1 +
> net/core/filter.c| 95
>
> 2 files changed, 96 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 29ef6f9..79b825a 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -122,6 +122,7 @@ enum bpf_prog_type {
> BPF_PROG_TYPE_KPROBE,
> BPF_PROG_TYPE_SCHED_CLS,
> BPF_PROG_TYPE_SCHED_ACT,
> + BPF_PROG_TYPE_SECCOMP,
> };
>
> #define BPF_PSEUDO_MAP_FD 1
> diff --git a/net/core/filter.c b/net/core/filter.c
> index be3098f..ed339fa 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -1466,6 +1466,39 @@ tc_cls_act_func_proto(enum bpf_func_id func_id)
> }
> }
>
> +static const struct bpf_func_proto *
> +seccomp_func_proto(enum bpf_func_id func_id)
> +{
> + /* Right now seccomp eBPF loading doesn't support maps; seccomp
> filters
> +* are considered to be read-only after they're installed, so map fds
> +* probably need to be invalidated when a seccomp filter with maps is
> +* installed.
> +*
> +* The rest of these might be reasonable to call from seccomp, so we
> +* export them.
> +*/
> + switch (func_id) {
> + case BPF_FUNC_ktime_get_ns:
> + return &bpf_ktime_get_ns_proto;
> + case BPF_FUNC_trace_printk:
> + return bpf_get_trace_printk_proto();
> + case BPF_FUNC_get_prandom_u32:
> + return &bpf_get_prandom_u32_proto;
I don't think we should expose prandom to unprivileged userspace.
This may be an attack vector.
Also, before we allow anything with side effects, we should think
carefully about whether seccomp filters with side effects (other than
through their return value) are okay.
--Andy
--
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] Add correlated clocksource deriving system time from an auxiliary clocksource
On Thu, Sep 3, 2015 at 4:20 PM, Hall, Christopher S wrote: > For example, supply the ART value as an argument and, in the case of the > realtime > clock, keep a short history of clock changes. It would fail in cases where > there > are a lot of calls to adjtimex(), but it will would work most of the time. So, I really don't think something like this would be reasonable. For one, keeping track of the adjtimex adjustments would be difficult enough to do sanely, but the real issue is that the clock has its own long-term error correction adjustments that it does in order to keep long term frequency accuracy with coarsely adjusted clocksources. Trying to track those small oscillation intervals would be even more complicated. I still think that being able to calculate the CLOCK_MONOTONIC_RAW value for a given ART counter value is reasonable, and then one can use the getnstime_raw_and_real() to get a current raw/real sync point, which you can then calculate the raw delta, and subtract that from the sycned real timestamp. You're error there would be bound by the maxium clocksource adjustment rate * the raw-delta interval length. To clarify on the need to understand if this error would be reasonable, can you provide a sense of what the delay from an ART read to trying to calculate a REALTIME value might be? thanks -john -- 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/
