Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Peter Jones]

On Fri, Feb 16, 2018 at 07:32:17PM +, Luck, Tony wrote:
> > tl;dr: I think changing everything to 0600 is probably completely fine,
> > and whitelisting is probably pointless.  
> 
> But do you speak for all users?

No, I just write their tools :)

> It will just take one person complaining that efibootmgr no longer
> shows them what it used to show to bring down the wrath of Linus on
> our (specifically Joe's) head for breaking user space.

The userland use case is gazing idly at the values without intending to
do anything about them.  And most of this is firmware config and
firmware/OS interaction.  Honestly it should never have been user
readable to begin with.

But also, we had a bug for quite some time where efibootmgr created
everything as 0600, and as a result non-root users couldn't do e.g.
"efibootmgr -v" and see the paths of new entries until a reboot
occurred.  Nobody ever reported it in bugzilla.redhat.com or efibootmgr
or efivar's github issues pages.  One person noticed it while commenting
about another issue, but didn't see it as related to his actual issue or
being a bug so much as "weird" that listing worked as non-root before
changing something but not after.

Another user asked about getting permission denied while setting the
boot order on askubuntu here:
https://askubuntu.com/questions/688317/getting-permission-denied-errors-from-efibootmgr
The response was exactly that you have to run it as root.  I think it's
telling that nobody said anything about reading vs writing.

> I've got someone about to start looking at making efivarfs read and save
> the values during mount, so all the read-only options can continue to work
> without making EFI calls.
> 
> This will cost some memory (say 20-30 variables at up to 1K each).

71 variables on my laptop, and the 1K restriction went away a *lng*
time ago.  It was fully excised from the userland tools in 2013.  On my
laptop, 4 of those 71 variables are >5000 bytes.  The total storage of
all of the data in the variables is 38kB.

I still think changing it to 0600 and calling this done is the right
thing to do.

-- 
  Peter

Re: [PATCH 2/3] x86/mm: introduce __PAGE_KERNEL_GLOBAL

[Nadav Amit]

Dave Hansen  wrote:

> On 02/16/2018 10:25 AM, Nadav Amit wrote:
>>> +#ifdef CONFIG_PAGE_TABLE_ISOLATION
>>> +#define __PAGE_KERNEL_GLOBAL   0
>>> +#else
>>> +#define __PAGE_KERNEL_GLOBAL   _PAGE_GLOBAL
>>> +#endif
>> ...
>>> --- a/arch/x86/mm/pageattr.c~kpti-no-global-for-kernel-mappings 
>>> 2018-02-13 15:17:56.148210060 -0800
>>> +++ b/arch/x86/mm/pageattr.c2018-02-13 15:17:56.153210060 -0800
>>> @@ -593,7 +593,8 @@ try_preserve_large_page(pte_t *kpte, uns
>>>  * different bit positions in the two formats.
>>>  */
>>> req_prot = pgprot_4k_2_large(req_prot);
>>> -   req_prot = pgprot_set_on_present(req_prot, _PAGE_GLOBAL | _PAGE_PSE);
>>> +   req_prot = pgprot_set_on_present(req_prot,
>>> +   __PAGE_KERNEL_GLOBAL | _PAGE_PSE);
>>> req_prot = canon_pgprot(req_prot);
>> From these chunks, it seems to me as req_prot will not have the global bit
>> on when “nopti” parameter is provided. What am I missing?
> 
> That's a good point.  The current patch does not allow the use of
> _PAGE_GLOBAL via _PAGE_KERNEL_GLOBAL when CONFIG_PAGE_TABLE_ISOLATION=y,
> but booted with nopti.  It's a simple enough fix.  Logically:
> 
> #ifdef CONFIG_PAGE_TABLE_ISOLATION
> #define __PAGE_KERNEL_GLOBAL  static_cpu_has(X86_FEATURE_PTI) ?
>   0 : _PAGE_GLOBAL
> #else
> #define __PAGE_KERNEL_GLOBAL  _PAGE_GLOBAL
> #endif
> 
> But I don't really want to hide that gunk in a macro like that.  It
> might make more sense as a static inline.  I'll give that a shot and resent.

Since determining whether PTI is on is done in several places in the kernel,
maybe there should a single function to determine whether PTI is on,
something like:

static inline bool is_pti_on(void)
{
return IS_ENABLED(CONFIG_PAGE_TABLE_ISOLATION) && 
static_cpu_has(X86_FEATURE_PTI);
}

Re: [PATCH v1] platform/x86: wmi: Replace kmalloc + sprintf() with kasprintf()

[Darren Hart]

On Fri, Feb 16, 2018 at 03:55:24PM +, David Laight wrote:
> From: Andy Shevchenko
> > Sent: 16 February 2018 15:40
> >
> > kasprintf() does the job of two: kmalloc() and sprintf().
> > Replace two calls with one.
> ...
> > -   buf = kmalloc(strlen(wdriver->driver.name) + 5, GFP_KERNEL);
> > +   buf = kasprintf(GFP_KERNEL, "wmi/%s", wdriver->driver.name);
> ...
> 
> Except that kasprintf() has no idea how long a buffer is needed.
> It might even do the printf twice just to get the length.

Sure, but this is one-time and non-critical path. Unfortunately there
isn't any guidance in Documentation here. Of the 520 or so instances of
kasprintf usages in the kernel, device name or similar is a very common
pattern. Eliminating manual counting of characters for buffer allocation
seems like a good plan to me.

So unless we want to argue that all those use cases are wrong, this
would appear to be at least common practice, if not best practice for
this particular pattern.

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Matthew Garrett]

On Fri, Feb 16, 2018 at 11:31 AM Ard Biesheuvel 
wrote:
> This is why I was leaning towards applying these patches: not breaking
> userland is an important rule, but it does not imply every aspect of
> behavior observable by userland is set in stone. In other words, I
> agree with Peter that making this change does not *break* userland in
> a way anyone is likely to care deeply about.

In some modes tpmtotp will run as non-root and expect to be able to read an
EFI variable.

Re: [PATCH 08/23] kconfig: add 'macro' keyword to support user-defined function

[Nicolas Pitre]

On Sat, 17 Feb 2018, Masahiro Yamada wrote:

> Now, we got a basic ability to test compiler capability in Kconfig.
> 
> config CC_HAS_STACKPROTECTOR
> bool
> default $(shell $CC -Werror -fstack-protector -c -x c /dev/null -o 
> /dev/null)
> 
> This works, but it is ugly to repeat this long boilerplate.
> 
> We want to describe like this:
> 
> config CC_HAS_STACKPROTECTOR
> bool
> default $(cc-option -fstack-protector)
> 
> It is straight-forward to implement a new function, but I do not like
> to hard-code specialized functions like this.  Hence, here is another
> feature to add functions from Kconfig files.
> 
> A user-defined function can be defined as a string type symbol with
> a special keyword 'macro'.  It can be referenced in the same way as
> built-in functions.  This feature was also inspired by Makefile where
> user-defined functions are referenced by $(call func-name, args...),
> but I omitted the 'call' to makes it shorter.
> 
> The macro definition can contain $(1), $(2), ... which will be replaced
> with arguments from the caller.
> 
> Example code:
> 
>   config cc-option
>   string
>   macro $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)

I think this syntax for defining a macro shouldn't start with the 
"config" keyword, unless you want it to be part of the config symbol 
space and land it in .config. And typing it as a "string" while it 
actually returns y/n (hence a bool) is also strange.

What about this instead:

macro cc-option
bool $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)

This makes it easier to extend as well if need be.


Nicolas

Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

[Arjan van de Ven]

On 2/16/2018 11:43 AM, Linus Torvalds wrote:

On Fri, Feb 16, 2018 at 11:38 AM, Linus Torvalds
 wrote:


Of course, your patch still doesn't allow for "we claim to be skylake
for various other independent reasons, but the RSB issue is fixed".


.. maybe nobody ever has a reason to do that, though?


yeah I would be extremely surprised


Who knows, virtualization people may simply want the user to specify
the model, but then make the Spectre decisions be based on actual
hardware capabilities (whether those are "current" or "some minimum
base").


once you fake to be skylake when you're not, you do that for a reason; normallyt
that reason is that you COULD migrate to a skylake.
(and migration is not supposed to be visble to the guest OS)

and at that point you are a skylake for all intents and purposes.

(and the virtualization people also really hate it when the hardware
burst the bubble of this fakeing hardware to be not what it is)

[PATCH v2] iio:pressure:ms5611: Fix coding style in probe function

[rodrigosiqueira]

This patch fixes the checkpatch.pl warning and error:

iio/pressure/ms5611.h:66: ERROR: code indent should use tabs where possible
iio/pressure/ms5611.h:66: WARNING: please, no spaces at the start of a line
iio/pressure/ms5611.h:66: ERROR: "foo* bar" should be "foo *bar"

Signed-off-by: Rodrigo Siqueira 
---
Changes in v2:
  - Make the commit message more clearer.

 drivers/iio/pressure/ms5611.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/pressure/ms5611.h b/drivers/iio/pressure/ms5611.h
index ccda63c5b3c3..ead9e9f85894 100644
--- a/drivers/iio/pressure/ms5611.h
+++ b/drivers/iio/pressure/ms5611.h
@@ -63,7 +63,7 @@ struct ms5611_state {
 };
 
 int ms5611_probe(struct iio_dev *indio_dev, struct device *dev,
- const char* name, int type);
+const char *name, int type);
 int ms5611_remove(struct iio_dev *indio_dev);
 
 #endif /* _MS5611_H */
-- 
2.16.1

Very Important

[Mr. Lee]

Hi, I have a business proposal for you, no risk involved. Pls reply for brief. 
Lee

[PATCH v4] rtc: isl12026: Add driver.

[David Daney]

The ISL12026 is a combination RTC and EEPROM device with I2C
interface.  The standard RTC driver interface is provided.  The EEPROM
is accessed via the NVMEM interface via the "eeprom0" directory in the
sysfs entry for the device.

Reviewed-by: Andy Shevchenko 
Signed-off-by: David Daney 
---
Changes from v3:

o Add Reviewed-by

o s/dev_err/dev_warn/ in one place

o Remove redundant ','

Changes from v2:

o More code cleanups suggested by reviewers.

Changes from v1:

o Fixed device tree bindings document example.

o Use RTC_NVMEM facility for eeprom support.

o Small code cleanups suggested by reviewers.

 .../devicetree/bindings/rtc/isil,isl12026.txt  |  28 ++
 drivers/rtc/Kconfig|   9 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-isl12026.c | 529 +
 4 files changed, 567 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.txt
 create mode 100644 drivers/rtc/rtc-isl12026.c

diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt 
b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
new file mode 100644
index ..2e0be45193bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
@@ -0,0 +1,28 @@
+ISL12026 I2C RTC/EEPROM
+
+ISL12026 is an I2C RTC/EEPROM combination device.  The RTC and control
+registers respond at bus address 0x6f, and the EEPROM array responds
+at bus address 0x57.  The canonical "reg" value will be for the RTC portion.
+
+Required properties supported by the device:
+
+ - "compatible": must be "isil,isl12026"
+ - "reg": I2C bus address of the device (always 0x6f)
+
+Optional properties:
+
+ - "isil,pwr-bsw": If present PWR.BSW bit must be set to the specified
+   value for proper operation.
+
+ - "isil,pwr-sbib": If present PWR.SBIB bit must be set to the specified
+value for proper operation.
+
+
+Example:
+
+   rtc@6f {
+   compatible = "isil,isl12026";
+   reg = <0x6f>;
+   isil,pwr-bsw = <0>;
+   isil,pwr-sbib = <1>;
+   }
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8ab5f0a5d323..85171e9e3ada 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -407,6 +407,15 @@ config RTC_DRV_ISL12022
  This driver can also be built as a module. If so, the module
  will be called rtc-isl12022.
 
+config RTC_DRV_ISL12026
+   tristate "Intersil ISL12026"
+   help
+ If you say yes here you get support for the
+ Intersil ISL12026 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-isl12026.
+
 config RTC_DRV_X1205
tristate "Xicor/Intersil X1205"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 4fbf87e45a7c..f481661a6eae 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
 obj-$(CONFIG_RTC_DRV_HYM8563)  += rtc-hym8563.o
 obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
 obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
+obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
 obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
 obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
 obj-$(CONFIG_RTC_DRV_LP8788)   += rtc-lp8788.o
diff --git a/drivers/rtc/rtc-isl12026.c b/drivers/rtc/rtc-isl12026.c
new file mode 100644
index ..29e5bdf96c67
--- /dev/null
+++ b/drivers/rtc/rtc-isl12026.c
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * An I2C driver for the Intersil ISL 12026
+ *
+ * Copyright (c) 2018 Cavium, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register offsets */
+#define ISL12026_REG_PWR   0x14
+# define ISL12026_REG_PWR_BSW  BIT(6)
+# define ISL12026_REG_PWR_SBIB BIT(7)
+#define ISL12026_REG_SC0x30
+#define ISL12026_REG_HR0x32
+# define ISL12026_REG_HR_MIL   BIT(7)  /* military or 24 hour time */
+#define ISL12026_REG_SR0x3f
+# define ISL12026_REG_SR_RTCF  BIT(0)
+# define ISL12026_REG_SR_WEL   BIT(1)
+# define ISL12026_REG_SR_RWEL  BIT(2)
+# define ISL12026_REG_SR_MBZ   BIT(3)
+# define ISL12026_REG_SR_OSCF  BIT(4)
+
+/* The EEPROM array responds at i2c address 0x57 */
+#define ISL12026_EEPROM_ADDR   0x57
+
+#define ISL12026_PAGESIZE 16
+#define ISL12026_NVMEM_WRITE_TIME 20
+
+struct isl12026 {
+   struct rtc_device *rtc;
+   struct i2c_client *nvm_client;
+   struct nvmem_config nvm_cfg;
+   /*
+* RTC write operations require that multiple messages be
+* transmitted, we hold the lock for all accesses to the
+* device so that these sequences cannot be disrupted.  Also,
+* the write cycle to the nvmem takes many ms during which the
+* device does not respond to commands, so hol

Re: [PATCH 4.9 00/88] 4.9.82-stable review

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 06:19:46AM -0800, Guenter Roeck wrote:
> On 02/15/2018 07:16 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.82 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Feb 17 15:11:46 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 137 fail: 8
> Failed builds:
>   arm:allmodconfig
>   powerpc:defconfig
>   powerpc:allmodconfig
>   powerpc:ppc64e_defconfig
>   powerpc:cell_defconfig
>   powerpc:maple_defconfig
>   powerpc:ppc6xx_defconfig
>   powerpc:mpc83xx_defconfig
> Qemu test results:
>   total: 126 pass: 119 fail: 7
> Failed tests:
>   powerpc:mpc8544ds:mpc85xx_defconfig
>   powerpc:mpc8544ds:mpc85xx_smp_defconfig
>   powerpc:mac99:ppc64_book3s_defconfig:nosmp
>   powerpc:mac99:ppc64_book3s_defconfig:smp4
>   powerpc:pseries:pseries_defconfig
>   powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
>   powerpc:mpc8544ds:ppc64_e5500_defconfig:smp

Yeah, powerpc is b0rked :(

> Build failures:
> 
> Building arm:allmodconfig ... failed
> --
> Error log:
> 
> drivers/clocksource/timer-stm32.c: In function 'stm32_clockevent_init':
> drivers/clocksource/timer-stm32.c:191:2: error: implicit declaration of 
> function 'kfree'

Let me go track this one down.

> Building powerpc:defconfig ... failed
> Building powerpc:allmodconfig ... failed
> Building powerpc:ppc64e_defconfig ... failed
> Building powerpc:cell_defconfig ... failed
> Building powerpc:maple_defconfig ... failed
> --
> Error log:
> arch/powerpc/kernel/entry_64.S: Assembler messages:
> arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode: `rfi_to_user'
> arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode: 
> `rfi_to_kernel'
> arch/powerpc/kernel/entry_64.S:885: Error: unrecognized opcode: `rfi_to_user'
> build/arch/powerpc/kernel/entry_64.S:900: Error: unrecognized opcode: 
> `rfi_to_kernel'

This I know is broken, I think I have a fix somewhere, but haven't dug
through my mbox yet...

> Building powerpc:ppc6xx_defconfig ... failed
> Building powerpc:mpc83xx_defconfig ... failed
> --
> Error log:
> drivers/crypto/talitos.c: In function 'talitos_sg_map':
> drivers/crypto/talitos.c:1131:3: error: too many arguments to function 
> 'to_talitos_ptr'

Offending patch is now dropped.

thanks,

greg k-h

Re: [PATCH 4.14 000/195] 4.14.20-stable review

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 06:27:09AM -0800, Guenter Roeck wrote:
> On 02/15/2018 10:00 PM, Naresh Kamboju wrote:
> > On 15 February 2018 at 20:44, Greg Kroah-Hartman
> >  wrote:
> > > This is the start of the stable review cycle for the 4.14.20 release.
> > > There are 195 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sat Feb 17 15:16:22 UTC 2018.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > >  
> > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.20-rc1.gz
> > > or in the git tree and branch at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > > linux-4.14.y
> > > and the diffstat can be found below.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> 
> I somehow lost the original mail, so I am replying to this one - sorry.
> 
> Build results:
>   total: 145 pass: 143 fail: 2
> Failed builds:
>   powerpc:ppc6xx_defconfig
>   powerpc:mpc83xx_defconfig
> Qemu test results:
>   total: 126 pass: 124 fail: 2
> Failed tests:
>   powerpc:mpc8544ds:mpc85xx_defconfig
>   powerpc:mpc8544ds:mpc85xx_smp_defconfig
> 
> Build failures:
> 
> Building powerpc:ppc6xx_defconfig ... failed
> Building powerpc:mpc83xx_defconfig ... failed
> Building powerpc:mpc8544ds:mpc85xx_defconfig ... failed
> Building powerpc:mpc8544ds:mpc85xx_smp_defconfig ... failed
> --
> Error log:
> drivers/crypto/talitos.c: In function 'talitos_sg_map':
> drivers/crypto/talitos.c:1131:3: error: too many arguments to function 
> 'to_talitos_ptr'

Ugh, sorry about that, now dropping this crypto patch from 4.14.y and
4.9.y to fix this issue.

greg k-h

Re: [PATCH 3.18 00/45] 3.18.95-stable review

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 06:11:44AM -0800, Guenter Roeck wrote:
> On 02/15/2018 07:16 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.95 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Feb 17 14:40:54 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 136 pass: 135 fail: 1
> Failed builds:
>   arm:axm55xx_defconfig
> Qemu test results:
>   total: 112 pass: 112 fail: 0
> 
> Build failure:
> 
> Building arm:axm55xx_defconfig ... failed
> --
> Error log:
> arch/arm/kvm/handle_exit.c: In function 'handle_hvc':
> arch/arm/kvm/handle_exit.c:48:3: error: implicit declaration of function 
> 'vcpu_set_reg'

Oops, I backported an arm kvm patch too far back, sorry about that.
I'll go drop that patch now.

greg k-h

Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

[Linus Torvalds]

On Fri, Feb 16, 2018 at 11:38 AM, Linus Torvalds
 wrote:
>
> Of course, your patch still doesn't allow for "we claim to be skylake
> for various other independent reasons, but the RSB issue is fixed".

.. maybe nobody ever has a reason to do that, though?

Who knows, virtualization people may simply want the user to specify
the model, but then make the Spectre decisions be based on actual
hardware capabilities (whether those are "current" or "some minimum
base").

Two bits allow that. One bit means "if you claim you're running
skylake, we'll always have to stuff, whether you _really_ are or not".

   Linus

Re: [PATCH 4.4 000/108] 4.4.116-stable review

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 06:12:56AM -0800, Guenter Roeck wrote:
> On 02/15/2018 07:15 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.116 release.
> > There are 108 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Feb 17 15:11:36 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 118 pass: 118 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Good, thanks for testing.

greg k-h

[PATCH 04/41] tools lib api fs: Add sysfs__read_xll function

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding sysfs__read_xll function to be able to read sysfs files with hex
numbers in, which do not have 0x prefix.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/api/fs/fs.c | 15 +--
 tools/lib/api/fs/fs.h |  1 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index 8b0e4a4315bd..6a12bbf39f7b 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -432,7 +432,8 @@ int procfs__read_str(const char *entry, char **buf, size_t 
*sizep)
return filename__read_str(path, buf, sizep);
 }
 
-int sysfs__read_ull(const char *entry, unsigned long long *value)
+static int sysfs__read_ull_base(const char *entry,
+   unsigned long long *value, int base)
 {
char path[PATH_MAX];
const char *sysfs = sysfs__mountpoint();
@@ -442,7 +443,17 @@ int sysfs__read_ull(const char *entry, unsigned long long 
*value)
 
snprintf(path, sizeof(path), "%s/%s", sysfs, entry);
 
-   return filename__read_ull(path, value);
+   return filename__read_ull_base(path, value, base);
+}
+
+int sysfs__read_xll(const char *entry, unsigned long long *value)
+{
+   return sysfs__read_ull_base(entry, value, 16);
+}
+
+int sysfs__read_ull(const char *entry, unsigned long long *value)
+{
+   return sysfs__read_ull_base(entry, value, 0);
 }
 
 int sysfs__read_int(const char *entry, int *value)
diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
index 8ebee35a6395..92d03b8396b1 100644
--- a/tools/lib/api/fs/fs.h
+++ b/tools/lib/api/fs/fs.h
@@ -40,6 +40,7 @@ int procfs__read_str(const char *entry, char **buf, size_t 
*sizep);
 int sysctl__read_int(const char *sysctl, int *value);
 int sysfs__read_int(const char *entry, int *value);
 int sysfs__read_ull(const char *entry, unsigned long long *value);
+int sysfs__read_xll(const char *entry, unsigned long long *value);
 int sysfs__read_str(const char *entry, char **buf, size_t *sizep);
 int sysfs__read_bool(const char *entry, bool *value);
 
-- 
2.14.3

Re: [PATCH 4.15 000/202] 4.15.4-stable review

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 06:28:23AM -0800, Guenter Roeck wrote:
> On 02/15/2018 07:15 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.15.4 release.
> > There are 202 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Feb 17 15:16:28 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 147 pass: 147 fail: 0
> Qemu test results:
>   total: 126 pass: 126 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Nice, thanks for testing and letting me know.

greg k-h

[PATCH 01/41] perf record: Put new line after target override warning

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no new-line after target-override warning, now:

  $ perf record -a --per-thread
  Warning:
  SYSTEM/CPU switch overriding PER-THREAD^C[ perf record: Woken up 1 times to 
write data ]
  [ perf record: Captured and wrote 0.705 MB perf.data (2939 samples) ]

with patch:

  $ perf record -a --per-thread
  Warning:
  SYSTEM/CPU switch overriding PER-THREAD
  ^C[ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.705 MB perf.data (2939 samples) ]

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Fixes: 16ad2ffb822c ("perf tools: Introduce perf_target__strerror()")
Link: http://lkml.kernel.org/r/20180206181813.10943-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index bf4ca749d1ac..907267206973 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1803,7 +1803,7 @@ int cmd_record(int argc, const char **argv)
err = target__validate(&rec->opts.target);
if (err) {
target__strerror(&rec->opts.target, err, errbuf, BUFSIZ);
-   ui__warning("%s", errbuf);
+   ui__warning("%s\n", errbuf);
}
 
err = target__parse_uid(&rec->opts.target);
-- 
2.14.3

[PATCH 03/41] tools lib api fs: Add filename__read_xll function

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding filename__read_xll function to be able to read files with hex
numbers in, which do not have 0x prefix.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/api/fs/fs.c | 29 ++---
 tools/lib/api/fs/fs.h |  1 +
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index b24afc0e6e81..8b0e4a4315bd 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -315,12 +315,8 @@ int filename__read_int(const char *filename, int *value)
return err;
 }
 
-/*
- * Parses @value out of @filename with strtoull.
- * By using 0 for base, the strtoull detects the
- * base automatically (see man strtoull).
- */
-int filename__read_ull(const char *filename, unsigned long long *value)
+static int filename__read_ull_base(const char *filename,
+  unsigned long long *value, int base)
 {
char line[64];
int fd = open(filename, O_RDONLY), err = -1;
@@ -329,7 +325,7 @@ int filename__read_ull(const char *filename, unsigned long 
long *value)
return -1;
 
if (read(fd, line, sizeof(line)) > 0) {
-   *value = strtoull(line, NULL, 0);
+   *value = strtoull(line, NULL, base);
if (*value != ULLONG_MAX)
err = 0;
}
@@ -338,6 +334,25 @@ int filename__read_ull(const char *filename, unsigned long 
long *value)
return err;
 }
 
+/*
+ * Parses @value out of @filename with strtoull.
+ * By using 16 for base to treat the number as hex.
+ */
+int filename__read_xll(const char *filename, unsigned long long *value)
+{
+   return filename__read_ull_base(filename, value, 16);
+}
+
+/*
+ * Parses @value out of @filename with strtoull.
+ * By using 0 for base, the strtoull detects the
+ * base automatically (see man strtoull).
+ */
+int filename__read_ull(const char *filename, unsigned long long *value)
+{
+   return filename__read_ull_base(filename, value, 0);
+}
+
 #define STRERR_BUFSIZE  128 /* For the buffer size of strerror_r */
 
 int filename__read_str(const char *filename, char **buf, size_t *sizep)
diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
index dda49deefb52..8ebee35a6395 100644
--- a/tools/lib/api/fs/fs.h
+++ b/tools/lib/api/fs/fs.h
@@ -30,6 +30,7 @@ FS(bpf_fs)
 
 int filename__read_int(const char *filename, int *value);
 int filename__read_ull(const char *filename, unsigned long long *value);
+int filename__read_xll(const char *filename, unsigned long long *value);
 int filename__read_str(const char *filename, char **buf, size_t *sizep);
 
 int filename__write_int(const char *filename, int value);
-- 
2.14.3

[PATCH 02/41] perf script: Add --show-round-event to display PERF_RECORD_FINISHED_ROUND

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding --show-round-event to display PERF_RECORD_FINISHED_ROUND events
like:

  # perf script --show-round-events 2>/dev/null
   yes  8591 [002] 124177.397597: 18 
cpu/mem-stores/P: ff...
   yes  8591 [002] 124177.397615:  1 
cpu/mem-loads,ldlat=30/P: ff...
  PERF_RECORD_FINISHED_ROUND
  perf 10380 [001] 124177.397622:  6 
cpu/mem-loads,ldlat=30/P: ff...
  PERF_RECORD_FINISHED_ROUND
   swapper 0 [000] 124177.400518: 88 
cpu/mem-stores/P: ff...
   swapper 0 [000] 124177.400521: 88 
cpu/mem-stores/P: ff...

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-script.txt |  3 +++
 tools/perf/builtin-script.c  | 17 +
 2 files changed, 20 insertions(+)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 7730c1d2b5d3..36ec0257f8d3 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -303,6 +303,9 @@ OPTIONS
 --show-lost-events
Display lost events i.e. events of type PERF_RECORD_LOST.
 
+--show-round-events
+   Display finished round events i.e. events of type 
PERF_RECORD_FINISHED_ROUND.
+
 --demangle::
Demangle symbol names to human readable form. It's enabled by default,
disable with --no-demangle.
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index ab19a6ee4093..cce926aeb0c0 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1489,6 +1489,7 @@ struct perf_script {
boolshow_switch_events;
boolshow_namespace_events;
boolshow_lost_events;
+   boolshow_round_events;
boolallocated;
boolper_event_dump;
struct cpu_map  *cpus;
@@ -2104,6 +2105,16 @@ process_lost_event(struct perf_tool *tool,
return 0;
 }
 
+static int
+process_finished_round_event(struct perf_tool *tool __maybe_unused,
+union perf_event *event,
+struct ordered_events *oe __maybe_unused)
+
+{
+   perf_event__fprintf(event, stdout);
+   return 0;
+}
+
 static void sig_handler(int sig __maybe_unused)
 {
session_done = 1;
@@ -2200,6 +2211,10 @@ static int __cmd_script(struct perf_script *script)
script->tool.namespaces = process_namespaces_event;
if (script->show_lost_events)
script->tool.lost = process_lost_event;
+   if (script->show_round_events) {
+   script->tool.ordered_events = false;
+   script->tool.finished_round = process_finished_round_event;
+   }
 
if (perf_script__setup_per_event_dump(script)) {
pr_err("Couldn't create the per event dump files\n");
@@ -3139,6 +3154,8 @@ int cmd_script(int argc, const char **argv)
"Show namespace events (if recorded)"),
OPT_BOOLEAN('\0', "show-lost-events", &script.show_lost_events,
"Show lost events (if recorded)"),
+   OPT_BOOLEAN('\0', "show-round-events", &script.show_round_events,
+   "Show round events (if recorded)"),
OPT_BOOLEAN('\0', "per-event-dump", &script.per_event_dump,
"Dump trace output to files named by the monitored events"),
OPT_BOOLEAN('f', "force", &symbol_conf.force, "don't complain, do it"),
-- 
2.14.3

[PATCH 06/41] perf tools: Fix comment for sort__* compare functions

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

In commit 2f15bd8c6c6e ("perf tools: Fix "Command" sort_entry's cmp and
collapse function") we switched from pointer to string comparison.

But failed to remove related comments. Removing them and adding another
one to warn before pointer comparison in here.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-18-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 2da4d0456a03..e8514f651865 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -111,17 +111,20 @@ struct sort_entry sort_thread = {
 
 /* --sort comm */
 
+/*
+ * We can't use pointer comparison in functions below,
+ * because it gives different results based on pointer
+ * values, which could break some sorting assumptions.
+ */
 static int64_t
 sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
 {
-   /* Compare the addr that should be unique among comm */
return strcmp(comm__str(right->comm), comm__str(left->comm));
 }
 
 static int64_t
 sort__comm_collapse(struct hist_entry *left, struct hist_entry *right)
 {
-   /* Compare the addr that should be unique among comm */
return strcmp(comm__str(right->comm), comm__str(left->comm));
 }
 
-- 
2.14.3

[PATCH 07/41] perf report: Ask for ordered events for --tasks option

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

If we have the time in, keep the events in time order.

Committer notes:

Trying to be more verbose, what actual effect this will have in this particular
case?

Before and after this patch shows the artifacts:

  --- /tmp/before 2018-02-06 15:40:29.536411625 -0300
  +++ /tmp/after  2018-02-06 15:40:51.963403599 -0300
  @@ -5,34 +5,34 @@
 2540 2540 1818 |   gnome-terminal-
 3489 3489 2540 |bash
3243332433 3489 | perf
  - 324343243432433 |  perf
  + 324343243432433 |  make
324413244132434 |   make
325143251432441 |make
  511  51132514 | sh
  -   512  512  511 |  sh
  +   512  512  511 |  install


We don't have 'perf' calling 'perf' calling 'make', etc, the second
'perf' actually is 'make', i.e.  there was reordering of the relevant
PERF_RECORD_COMM and PERF_RECORD_FORK records.

Ditto for sh/install later on.

Look for FORK and COMM meta events, for those tids:

  # perf report -D | egrep 'PERF_RECORD_(FORK|COMM)' | egrep '3243[34]'
  0 14774650990679 0x1a3cd8 [0x38]: PERF_RECORD_FORK(32433:32433):(3489:3489)
  1 14774652080381 0x1d6568 [0x30]: PERF_RECORD_COMM exec: perf:32433/32433
  1 14774742473340 0x1dbb48 [0x38]: PERF_RECORD_FORK(32434:32434):(32433:32433)
  0 14774752005779 0x1a4af8 [0x30]: PERF_RECORD_COMM exec: make:32434/32434
  0 14774753997960 0x1a5578 [0x38]: PERF_RECORD_FORK(32435:32435):(32434:32434)
  0 14774756070782 0x1a5618 [0x38]: PERF_RECORD_FORK(32438:32438):(32434:32434)
  0 14774757772939 0x1a5680 [0x38]: PERF_RECORD_FORK(32440:32440):(32434:32434)
  0 14774758230600 0x1a56e8 [0x38]: PERF_RECORD_FORK(32441:32441):(32434:32434)
  #

First column is the cpu, second is the timestamp.

So they are on different CPUs, thus ring buffers, and when we don't use
the ordered_events class, we end up mixing that up, use it to take
advantage of the PERF_RECORD_FINISHED_ROUND meta events to go on
ordering the events using the PERF_SAMPLE_TIME present in the
PERF_RECORD_{FORK,COMM,EXIT,SAMPLE,etc} records in the ring buffer.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-report.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4ad5dc649716..8ef71669e7a0 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -614,6 +614,7 @@ static int stats_print(struct report *rep)
 static void tasks_setup(struct report *rep)
 {
memset(&rep->tool, 0, sizeof(rep->tool));
+   rep->tool.ordered_events = true;
if (rep->mmaps_mode) {
rep->tool.mmap = perf_event__process_mmap;
rep->tool.mmap2 = perf_event__process_mmap2;
-- 
2.14.3

[PATCH 09/41] perf stat: Add support to print counts for fixed times

[Arnaldo Carvalho de Melo]

From: yuzhoujian 

Introduce a new option to print counts for fixed number of times and
update 'perf stat' documentation accordingly.

Show below is the output of the new option for perf stat.

  $ perf stat -I 1000 --interval-count 2 -e cycles -a
  #   time counts unit events
   1.002827089 93,884,870  cycles
   2.004231506 56,573,446  cycles

We can just print the counts for several times with this newly
introduced option. The usage of it is a little like 'vmstat', and it
should be used together with "-I" option.

  $ vmstat -n 1 2
  procs -memory-- --swap- io-- -system-- --cpu---
   r  b swpd   free   buff   cachesi   so  bi   bo  in   cs us sy id wa st
   0  00 78270544 547484 51732076  0   0   0   2011  1  0 99  0 0
   0  00 78270512 547484 51732080  0   0   0   16  477 1555  0  0 100 0 0

Changes since v3:
- merge interval_count check and times check to one line.
- fix the wrong indent in stat.h
- use stat_config.times instead of 'times' in cmd_stat function.

Changes since v2:
- none.

Changes since v1:
- change the name of the new option "times-print" to "interval-count".
- keep the new option interval specifically.

Signed-off-by: yuzhoujian 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Kan Liang 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1517217923-8302-2-git-send-email-ufo19890...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-stat.txt |  5 +
 tools/perf/builtin-stat.c  | 20 +++-
 tools/perf/util/stat.h |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index 823fce7674bb..47a21645f60c 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -146,6 +146,11 @@ Print count deltas every N milliseconds (minimum: 10ms)
 The overhead percentage could be high in some cases, for instance with small, 
sub 100ms intervals.  Use with caution.
example: 'perf stat -I 1000 -e cycles -a sleep 5'
 
+--interval-count times::
+Print count deltas for fixed number of times.
+This option should be used together with "-I" option.
+   example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
+
 --metric-only::
 Only print computed metrics. Print them in a single line.
 Don't show any raw values. Not supported with --per-thread.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 98bf9d32f222..7d1d7613bf56 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -168,6 +168,7 @@ static struct timespec  ref_time;
 static struct cpu_map  *aggr_map;
 static aggr_get_id_t   aggr_get_id;
 static boolappend_file;
+static boolinterval_count;
 static const char  *output_name;
 static int output_fd;
 static int print_free_counters_hint;
@@ -571,6 +572,7 @@ static struct perf_evsel 
*perf_evsel__reset_weak_group(struct perf_evsel *evsel)
 static int __run_perf_stat(int argc, const char **argv)
 {
int interval = stat_config.interval;
+   int times = stat_config.times;
char msg[BUFSIZ];
unsigned long long t0, t1;
struct perf_evsel *counter;
@@ -700,6 +702,8 @@ static int __run_perf_stat(int argc, const char **argv)
while (!waitpid(child_pid, &status, WNOHANG)) {
nanosleep(&ts, NULL);
process_interval();
+   if (interval_count && !(--times))
+   break;
}
}
waitpid(child_pid, &status, 0);
@@ -716,8 +720,11 @@ static int __run_perf_stat(int argc, const char **argv)
enable_counters();
while (!done) {
nanosleep(&ts, NULL);
-   if (interval)
+   if (interval) {
process_interval();
+   if (interval_count && !(--times))
+   break;
+   }
}
}
 
@@ -1891,6 +1898,8 @@ static const struct option stat_options[] = {
"command to run after to the measured command"),
OPT_UINTEGER('I', "interval-print", &stat_config.interval,
"print counts at regular interval in ms (>= 10)"),
+   OPT_INTEGER(0, "interval-count", &stat_config.times,
+   "print counts for fixed number of times"),
OPT_SET_UINT(0, "per-socket", &stat_config.aggr_mode,
 "aggregate c

[PATCH 11/41] tools lib symbol: Skip non-address kallsyms line

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding check on failed attempt to parse the address and skip the line
parsing early in that case.

The address can be replaced with '(null)' string in case user don't have
enough permissions, like:

  $ cat /proc/kallsyms
  (null) A irq_stack_union
  (null) A __per_cpu_start
  ...

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/symbol/kallsyms.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/lib/symbol/kallsyms.c b/tools/lib/symbol/kallsyms.c
index 914cb8e3d40b..689b6a130dd7 100644
--- a/tools/lib/symbol/kallsyms.c
+++ b/tools/lib/symbol/kallsyms.c
@@ -38,6 +38,10 @@ int kallsyms__parse(const char *filename, void *arg,
 
len = hex2u64(line, &start);
 
+   /* Skip the line if we failed to parse the address. */
+   if (!len)
+   continue;
+
len++;
if (len + 2 >= line_len)
continue;
-- 
2.14.3

[PATCH 13/41] perf machine: Free root_dir in machine__init() error path

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Free root_dir in machine__init() error path.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b05a67464c03..c976384f9022 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -50,6 +50,8 @@ static void machine__threads_init(struct machine *machine)
 
 int machine__init(struct machine *machine, const char *root_dir, pid_t pid)
 {
+   int err = -ENOMEM;
+
memset(machine, 0, sizeof(*machine));
map_groups__init(&machine->kmaps, machine);
RB_CLEAR_NODE(&machine->rb_node);
@@ -79,7 +81,7 @@ int machine__init(struct machine *machine, const char 
*root_dir, pid_t pid)
char comm[64];
 
if (thread == NULL)
-   return -ENOMEM;
+   goto out;
 
snprintf(comm, sizeof(comm), "[guest/%d]", pid);
thread__set_comm(thread, comm, 0);
@@ -87,7 +89,11 @@ int machine__init(struct machine *machine, const char 
*root_dir, pid_t pid)
}
 
machine->current_tid = NULL;
+   err = 0;
 
+out:
+   if (err)
+   zfree(&machine->root_dir);
return 0;
 }
 
-- 
2.14.3

Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

[Linus Torvalds]

On Fri, Feb 16, 2018 at 11:17 AM, Dave Hansen
 wrote:
>
> Intel is considering adding a new bit to the IA32_ARCH_CAPABILITIES
> MSR to tell when RSB underflow might be happen.  Feedback on this
> would be greatly appreciated before the specification is finalized.

Yes, please. It would be lovely to not have any "this model" kind of checks.

Of course, your patch still doesn't allow for "we claim to be skylake
for various other independent reasons, but the RSB issue is fixed".

So it might actually be even better with _two_ bits: "explicitly needs
RSB stuffing" and "explicitly fixed and does _not_ need RSB stuffing".

And then if neither bit it set, we fall back to the implicit "we know
Skylake needs it".

If both bits are set, we just go with a "CPU is batshit schitzo"
message, and assume it needs RSB stuffing just because it's obviously
broken.

 Linus

[PATCH 12/41] perf symbols: Check if we read regular file in dso__load()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The current code in dso__load() calls is_regular_file(), but it checks
its return value only after calling symsrc__init().

That can make symsrc__init() block in elf_* functions on reading
the file if the file happens to be device and not regular one.

Call symsrc__init() only for regular files. Also remove the
symsrc__destroy() cleanup, which is not needed now, because we call
symsrc__init() only for regular files.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index cc065d4bfafc..e366e3060e6b 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1582,7 +1582,7 @@ int dso__load(struct dso *dso, struct map *map)
bool next_slot = false;
bool is_reg;
bool nsexit;
-   int sirc;
+   int sirc = -1;
 
enum dso_binary_type symtab_type = binary_type_symtab[i];
 
@@ -1600,16 +1600,14 @@ int dso__load(struct dso *dso, struct map *map)
nsinfo__mountns_exit(&nsc);
 
is_reg = is_regular_file(name);
-   sirc = symsrc__init(ss, dso, name, symtab_type);
+   if (is_reg)
+   sirc = symsrc__init(ss, dso, name, symtab_type);
 
if (nsexit)
nsinfo__mountns_enter(dso->nsinfo, &nsc);
 
-   if (!is_reg || sirc < 0) {
-   if (sirc >= 0)
-   symsrc__destroy(ss);
+   if (!is_reg || sirc < 0)
continue;
-   }
 
if (!syms_ss && symsrc__has_symtab(ss)) {
syms_ss = ss;
-- 
2.14.3

Re: [PATCH 0/7] fujitsu-laptop: Miscellaneous cleanups

[Darren Hart]

On Sun, Feb 11, 2018 at 10:07:20PM +0100, Michał Kępień wrote:
> This is the second of the two patch series I started preparing back in
> June 2017 [1].  It took me this long to post it purely due to permanent
> spare time shortage, not because the changes are complicated. 
> 
> The patch series contains miscellaneous cleanups which I think are worth
> getting done before splitting fujitsu-laptop into two separate modules.
> I am not 100% sure that all the changes in the last patch in this series
> actually help, so please speak your mind.
> 
> This patch series was tested on a Lifebook S7020.  AFAICT it does not
> conflict with the recent draft patch from Jan-Marek Glogowski and may
> thus be applied independently.
> 
> Finally, please forgive me if it takes me weeks or months to address
> review comments.  It is also perfectly fine for reviews to take weeks or
> months ;)
> 

To avoid just having to review everything again in a few months ;-) I've queued
up patches 1-5. I'll await comments to 6 and a respin of 7 based on feedback.

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH 15/41] perf machine: Generalize machine__set_kernel_mmap()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

So it could be called without event object, just with start and end
values. It will be used in following patch.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b1f1961b13f4..292e70c774bd 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1262,15 +1262,15 @@ int machine__create_kernel_maps(struct machine *machine)
return 0;
 }
 
-static void machine__set_kernel_mmap_len(struct machine *machine,
-union perf_event *event)
+static void machine__set_kernel_mmap(struct machine *machine,
+u64 start, u64 end)
 {
int i;
 
for (i = 0; i < MAP__NR_TYPES; i++) {
-   machine->vmlinux_maps[i]->start = event->mmap.start;
-   machine->vmlinux_maps[i]->end   = (event->mmap.start +
-  event->mmap.len);
+   machine->vmlinux_maps[i]->start = start;
+   machine->vmlinux_maps[i]->end   = end;
+
/*
 * Be a bit paranoid here, some perf.data file came with
 * a zero sized synthesized MMAP event for the kernel.
@@ -1375,7 +1375,8 @@ static int machine__process_kernel_mmap_event(struct 
machine *machine,
if (strstr(kernel->long_name, "vmlinux"))
dso__set_short_name(kernel, "[kernel.vmlinux]", false);
 
-   machine__set_kernel_mmap_len(machine, event);
+   machine__set_kernel_mmap(machine, event->mmap.start,
+event->mmap.start + event->mmap.len);
 
/*
 * Avoid using a zero address (kptr_restrict) for the ref reloc
-- 
2.14.3

[PATCH 16/41] perf machine: Don't search for active kernel start in __machine__create_kernel_maps

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

We should not search for the kernel start address in
__machine__create_kernel_maps(), because it's being used in the 'report'
code path, where we are interested in kernel MMAP data address (the one
recorded via 'perf record', possibly on another machine, or an older or
newer kernel on the same machine where analysis is being performed)
instead of in current kernel address.

The __machine__create_kernel_maps() function serves purely for creating
the machines kernel maps and setting up the kmap group. The report code
path then sets the address based on the data from kernel MMAP event in
the machine__set_kernel_mmap() function.

The kallsyms search address logic is used for test code, that calls
machine__create_kernel_maps() to get current maps and calls
machine__get_running_kernel_start() to get kernel starting address.

Use machine__set_kernel_mmap() to set the kernel maps start address and
moving map_groups__fixup_end to be call when all maps are in place.

Also make __machine__create_kernel_maps static, because there's no
external user.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-7-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 55 ++-
 tools/perf/util/machine.h |  1 -
 2 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 292e70c774bd..2db8d7dd0f80 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -856,13 +856,10 @@ static int machine__get_running_kernel_start(struct 
machine *machine,
return 0;
 }
 
-int __machine__create_kernel_maps(struct machine *machine, struct dso *kernel)
+static int
+__machine__create_kernel_maps(struct machine *machine, struct dso *kernel)
 {
int type;
-   u64 start = 0;
-
-   if (machine__get_running_kernel_start(machine, NULL, &start))
-   return -1;
 
/* In case of renewal the kernel map, destroy previous one */
machine__destroy_kernel_maps(machine);
@@ -871,7 +868,7 @@ int __machine__create_kernel_maps(struct machine *machine, 
struct dso *kernel)
struct kmap *kmap;
struct map *map;
 
-   machine->vmlinux_maps[type] = map__new2(start, kernel, type);
+   machine->vmlinux_maps[type] = map__new2(0, kernel, type);
if (machine->vmlinux_maps[type] == NULL)
return -1;
 
@@ -1222,6 +1219,24 @@ static int machine__create_modules(struct machine 
*machine)
return 0;
 }
 
+static void machine__set_kernel_mmap(struct machine *machine,
+u64 start, u64 end)
+{
+   int i;
+
+   for (i = 0; i < MAP__NR_TYPES; i++) {
+   machine->vmlinux_maps[i]->start = start;
+   machine->vmlinux_maps[i]->end   = end;
+
+   /*
+* Be a bit paranoid here, some perf.data file came with
+* a zero sized synthesized MMAP event for the kernel.
+*/
+   if (machine->vmlinux_maps[i]->end == 0)
+   machine->vmlinux_maps[i]->end = ~0ULL;
+   }
+}
+
 int machine__create_kernel_maps(struct machine *machine)
 {
struct dso *kernel = machine__get_kernel(machine);
@@ -1246,40 +1261,22 @@ int machine__create_kernel_maps(struct machine *machine)
 "continuing anyway...\n", machine->pid);
}
 
-   /*
-* Now that we have all the maps created, just set the ->end of them:
-*/
-   map_groups__fixup_end(&machine->kmaps);
-
if (!machine__get_running_kernel_start(machine, &name, &addr)) {
if (name &&
maps__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps, 
name, addr)) {
machine__destroy_kernel_maps(machine);
return -1;
}
+   machine__set_kernel_mmap(machine, addr, 0);
}
 
+   /*
+* Now that we have all the maps created, just set the ->end of them:
+*/
+   map_groups__fixup_end(&machine->kmaps);
return 0;
 }
 
-static void machine__set_kernel_mmap(struct machine *machine,
-u64 start, u64 end)
-{
-   int i;
-
-   for (i = 0; i < MAP__NR_TYPES; i++) {
-   machine->vmlinux_maps[i]->start = start;
-   machine->vmlinux_maps[i]->end   = end;
-
-   /*
-* Be a bit paranoid here, some perf.data file came with
-* a zero sized synthesized MMAP event for the kernel.
-*/
-   if (machine->vmlinux_maps[i]->end == 0)
-   machine->vmlinux_maps[i]->end = ~0ULL;
-   }
-}
-
 static bool machine__uses_kcore(struct machine *machine)
 {
stru

[PATCH 17/41] perf machine: Remove machine__load_kallsyms()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The current machine__load_kallsyms() function has no caller, so replace
it directly with __machine__load_kallsyms().  Also remove the no_kcore
argument as it was always called with a 'true' value.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-8-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/vmlinux-kallsyms.c |  2 +-
 tools/perf/util/machine.c   | 14 --
 tools/perf/util/machine.h   |  2 --
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/tools/perf/tests/vmlinux-kallsyms.c 
b/tools/perf/tests/vmlinux-kallsyms.c
index f6789fb029d6..58349297f9fb 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -56,7 +56,7 @@ int test__vmlinux_matches_kallsyms(struct test *test 
__maybe_unused, int subtest
 * be compacted against the list of modules found in the "vmlinux"
 * code and with the one got from /proc/modules from the "kallsyms" 
code.
 */
-   if (__machine__load_kallsyms(&kallsyms, "/proc/kallsyms", type, true) 
<= 0) {
+   if (machine__load_kallsyms(&kallsyms, "/proc/kallsyms", type) <= 0) {
pr_debug("dso__load_kallsyms ");
goto out;
}
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 2db8d7dd0f80..fe27ef55cbb9 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -151,7 +151,7 @@ struct machine *machine__new_kallsyms(void)
 *ask for not using the kcore parsing code, once this one is fixed
 *to create a map per module.
 */
-   if (machine && __machine__load_kallsyms(machine, "/proc/kallsyms", 
MAP__FUNCTION, true) <= 0) {
+   if (machine && machine__load_kallsyms(machine, "/proc/kallsyms", 
MAP__FUNCTION) <= 0) {
machine__delete(machine);
machine = NULL;
}
@@ -991,11 +991,11 @@ int machines__create_kernel_maps(struct machines 
*machines, pid_t pid)
return machine__create_kernel_maps(machine);
 }
 
-int __machine__load_kallsyms(struct machine *machine, const char *filename,
-enum map_type type, bool no_kcore)
+int machine__load_kallsyms(struct machine *machine, const char *filename,
+enum map_type type)
 {
struct map *map = machine__kernel_map(machine);
-   int ret = __dso__load_kallsyms(map->dso, filename, map, no_kcore);
+   int ret = __dso__load_kallsyms(map->dso, filename, map, true);
 
if (ret > 0) {
dso__set_loaded(map->dso, type);
@@ -1010,12 +1010,6 @@ int __machine__load_kallsyms(struct machine *machine, 
const char *filename,
return ret;
 }
 
-int machine__load_kallsyms(struct machine *machine, const char *filename,
-  enum map_type type)
-{
-   return __machine__load_kallsyms(machine, filename, type, false);
-}
-
 int machine__load_vmlinux_path(struct machine *machine, enum map_type type)
 {
struct map *map = machine__kernel_map(machine);
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 50d587d34459..66cc200ef86f 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -225,8 +225,6 @@ struct map *machine__findnew_module_map(struct machine 
*machine, u64 start,
const char *filename);
 int arch__fix_module_text_start(u64 *start, const char *name);
 
-int __machine__load_kallsyms(struct machine *machine, const char *filename,
-enum map_type type, bool no_kcore);
 int machine__load_kallsyms(struct machine *machine, const char *filename,
   enum map_type type);
 int machine__load_vmlinux_path(struct machine *machine, enum map_type type);
-- 
2.14.3

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Ard Biesheuvel]

On 16 February 2018 at 19:22, Peter Jones  wrote:
> On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
>> On Fri, Feb 16, 2018 at 11:18:12AM +, Ard Biesheuvel wrote:
>> > On 16 February 2018 at 11:08, Borislav Petkov  wrote:
>> > > On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
>> > >> By your own reasoning above, that's a no-no as well.
>> > >
>> > > I'm sure we can come up with some emulation - the same way we did the
>> > > BIOS emulation.
>> > >
>> > >> But thanks for your input. Anyone else got something constructive to 
>> > >> contribute?
>> > >
>> > > The not-breaking userspace is constructive contribution. The last
>> > > paragraph is my usual rant.
>> > >
>> >
>> > Fair enough. And I am not disagreeing with you either.
>> >
>> > So question to Joe: is it well defined which variables may exhibit
>> > this behavior?
>>
>> For brevity's sake, "not yet." Folks-- e.g. firmware writers and
>> equipment makers-- may use SMIs more (or less) than others. So, how many
>> SMIs generated by the reference shell script can, and will, vary
>> platform to platform. I and my colleagues are digging into this.
>
> As a first guess: anything generated during boot is probably not an
> SMI.  Everything else is probably an SMI.  In fact, I would expect that
> for most systems, the entire list of things that *don't* generate an SMI
> (aside from a few IBV specific variables) is all the variables in Table
> 10 of the UEFI spec that don't have the NV flag.
>
>> > Given that UEFI variables are GUID scoped, would whitelisting certain
>> > GUIDs (the ones userland currently relies on to be readable my
>> > non-privileged users) and making everything else user-only solve this
>> > problem as well?
>>
>> Perhaps. I don't want us chasing white rabbits just yet, but the
>> whitelist is but one approach under consideration. We may see some other
>> patches or RFCs about caching and/or shadowing variable values in
>> efivarfs to reduce the number of direct EFI reads, with the goal of
>> reducing how many SMIs are generated.
>>
>> Any obvious EFI variables that userspace tools have come to depend on--
>> those which normal, unprivileged users need to read-- are helpful inputs
>> to this discussion.
>
> So, our big userland consumers are efibootmgr, fwupdate, and
> "systemctl reboot --firmware-setup".  efibootmgr and fwupdate can do the
> "show the current status" half of their job as a user right now, but
> they rely on root for the other half anyway.  I don't think we normally
> use libfwup as non-root even for reading status.  So basically, the use
> case from userland that this will effect looks like:
>
> efibootmgr -v
> *scratch head*
> sudo su -
> efibootmgr -b  -B
> efibootmgr -b  -c -L "fixed entry" ...
> exit
>
> I don't feel really bad about people having to move the third line up to
> the top of that.  It's also not a use case you can have very much of: it
> means you manually booted without any valid boot entries.  fallback.efi
> would have created a valid boot entry if you didn't do it manually.
>
> "systemctl reboot --firmware-setup" effectively runs as root in all
> cases.
>
> The only thing we really must ensure to preserve the other workflows
> is making sure creat() and open() with 0644 doesn't return an error (it
> obviously won't be preserved across a reboot), because that would break
> the existing tools.  But I don't see anything in this patchset which
> will cause that.
>
> tl;dr: I think changing everything to 0600 is probably completely fine,
> and whitelisting is probably pointless.

This is why I was leaning towards applying these patches: not breaking
userland is an important rule, but it does not imply every aspect of
behavior observable by userland is set in stone. In other words, I
agree with Peter that making this change does not *break* userland in
a way anyone is likely to care deeply about.

Adding a caching layer to efivarfs for this purpose is really overkill
IMHO. Also, we need this only on x86, so I'd like to see it proposed
in a way that allows it to be compiled out for architectures that have
no need for it.

[PATCH 19/41] perf tests: Use arch__compare_symbol_names to compare symbols

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The symbol search called by machine__find_kernel_symbol_by_name is using
internally arch__compare_symbol_names function to compare 2 symbol
names, because different archs have different ways of comparing symbols.
Mostly for skipping '.' prefixes and similar.

In test 1 when we try to find matching symbols in kallsyms and vmlinux,
by address and by symbol name. When either is found we compare the pair
symbol names  by simple strcmp, which is not good enough for reasons
explained in previous paragraph.

On powerpc this can cause lockup, because even thought we found the
pair, the compared names are different and don't match simple strcmp.
Following code path is executed, that leads to lockup:

   - we find the pair in kallsyms by sym->start
next_pair:
   - we compare the names and it fails
   - we find the pair by sym->name
   - the pair addresses match so we call goto next_pair
 because we assume the names match in this case

Signed-off-by: Jiri Olsa 
Tested-by: Naveen N. Rao 
Acked-by: Naveen N. Rao 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Fixes: 031b84c407c3 ("perf probe ppc: Enable matching against dot symbols 
automatically")
Link: http://lkml.kernel.org/r/20180215122635.24029-10-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/vmlinux-kallsyms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/vmlinux-kallsyms.c 
b/tools/perf/tests/vmlinux-kallsyms.c
index 58349297f9fb..1e5adb65632a 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -125,7 +125,7 @@ int test__vmlinux_matches_kallsyms(struct test *test 
__maybe_unused, int subtest
 
if (pair && UM(pair->start) == mem_start) {
 next_pair:
-   if (strcmp(sym->name, pair->name) == 0) {
+   if (arch__compare_symbol_names(sym->name, pair->name) 
== 0) {
/*
 * kallsyms don't have the symbol end, so we
 * set that by using the next symbol start - 1,
-- 
2.14.3

[PATCH 20/41] perf cs-etm: Freeing allocated memory

[Arnaldo Carvalho de Melo]

From: Mathieu Poirier 

This patch frees all the memory allocated in function
cs_etm__alloc_queue().

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jin Yao 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518467557-18505-2-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index b9f0a53dfa65..f2c98774e665 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -174,6 +174,12 @@ static void cs_etm__free_queue(void *priv)
 {
struct cs_etm_queue *etmq = priv;
 
+   if (!etmq)
+   return;
+
+   thread__zput(etmq->thread);
+   cs_etm_decoder__free(etmq->decoder);
+   zfree(&etmq->event_buf);
free(etmq);
 }
 
-- 
2.14.3

[PATCH 22/41] perf auxtrace arm: Fixing uninitialised variable

[Arnaldo Carvalho de Melo]

From: Mathieu Poirier 

When working natively on arm64 the compiler gets pesky and complains
that variable 'i' is uninitialised, something that breaks the
compilation.  Here no further checks are needed since variable
'found_spe' can only be true if variable 'i' has been initialised as
part of the for loop.

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jin Yao 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518467557-18505-4-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/arm/util/auxtrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm/util/auxtrace.c 
b/tools/perf/arch/arm/util/auxtrace.c
index 2323581b157d..fa639e3e52ac 100644
--- a/tools/perf/arch/arm/util/auxtrace.c
+++ b/tools/perf/arch/arm/util/auxtrace.c
@@ -68,7 +68,7 @@ struct auxtrace_record
bool found_spe = false;
static struct perf_pmu **arm_spe_pmus = NULL;
static int nr_spes = 0;
-   int i;
+   int i = 0;
 
if (!evlist)
return NULL;
-- 
2.14.3

Re: [PATCH 1/6] nand: davinci: rename the platform driver

[Boris Brezillon]

On Fri, 16 Feb 2018 17:47:07 +0100
Bartosz Golaszewski  wrote:

> From: Bartosz Golaszewski 
> 
> Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
> lookup table") broke the nand support in board file mode for
> da850-based boards. Instead of reverting it and breaking the DT users
> in the process (due to clock lookup), rename the driver to match the
> clock table before renaming the users.
> 
> Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
> table")
> Signed-off-by: Bartosz Golaszewski 
> ---
>  drivers/mtd/nand/davinci_nand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index ccc8c43abcff..4fb143bf1872 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -865,7 +865,7 @@ static struct platform_driver nand_davinci_driver = {
>   .probe  = nand_davinci_probe,
>   .remove = nand_davinci_remove,
>   .driver = {
> - .name   = "davinci_nand",
> + .name   = "davinci-nand",

Another side-effect of this change you should be aware of: by doing
that you also break all users that were defining partitions through the
cmdline using mtdparts=davinci_nand.0:.

Not sure this is a good idea ;-).

>   .of_match_table = of_match_ptr(davinci_nand_of_match),
>   },
>  };



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[PATCH 24/41] perf annotate: Add missing arguments in Man page

[Arnaldo Carvalho de Melo]

From: Jaecheol Shin 

Some options must require an argument. But input, stdio-color, cpu have
no them.  So I added it.

Signed-off-by: Jaecheol Shin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Taeung Song 
Link: http://lkml.kernel.org/r/20180207095205.62715-1-jcgod...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-annotate.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-annotate.txt 
b/tools/perf/Documentation/perf-annotate.txt
index c635eab6af54..292809c3c0ca 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -21,7 +21,7 @@ If there is no debug info in the object, then annotated 
assembly is displayed.
 OPTIONS
 ---
 -i::
---input=::
+--input=::
 Input file name. (default: perf.data unless stdin is a fifo)
 
 -d::
@@ -69,7 +69,7 @@ OPTIONS
 
 --stdio:: Use the stdio interface.
 
---stdio-color::
+--stdio-color=::
'always', 'never' or 'auto', allowing configuring color output
via the command line, in addition to via "color.ui" .perfconfig.
Use '--stdio-color always' to generate color even when redirecting
@@ -84,7 +84,7 @@ OPTIONS
 --gtk:: Use the GTK interface.
 
 -C::
---cpu:: Only report samples for the list of CPUs provided. Multiple CPUs can
+--cpu=:: Only report samples for the list of CPUs provided. Multiple CPUs 
can
be provided as a comma-separated list with no space: 0,1. Ranges of
CPUs are specified with -: 0-2. Default is to report samples on all
CPUs.
-- 
2.14.3

[PATCH 27/41] perf cs-etm: Inject capabilitity for CoreSight traces

[Arnaldo Carvalho de Melo]

From: Robert Walker 

Added user space perf functionality to translate CoreSight traces into
instruction events with branch stack.

To invoke the new functionality, use the perf inject tool with
--itrace=il. For example, to translate the ETM trace from perf.data into
last branch records in a new inj.data file:

$ perf inject --itrace=i10il128 -i perf.data -o perf.data.new

The 'i' parameter to itrace generates periodic instruction events.  The
period between instruction events can be specified as a number of
instructions suffixed by i (default 10).

The parameter to 'l' specifies the number of entries in the branch stack
attached to instruction events.

The 'b' parameter to itrace generates events on taken branches.

This patch also fixes the contents of the branch events used in perf
report - previously branch events were generated for each contiguous
range of instructions executed.  These are fixed to generate branch
events between the last address of a range ending in an executed branch
instruction and the start address of the next range.

Based on patches by Sebastian Pop  with additional fixes
and support for specifying the instruction period.

Originally-by: Sebastian Pop 
Signed-off-by: Robert Walker 
Acked-by: Mathieu Poirier 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518607481-4059-2-git-send-email-robert.wal...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c |  65 +++-
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h |   1 +
 tools/perf/util/cs-etm.c| 434 +---
 3 files changed, 436 insertions(+), 64 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 1fb01849f1c7..8ff69dfd725a 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -78,6 +78,8 @@ int cs_etm_decoder__reset(struct cs_etm_decoder *decoder)
 {
ocsd_datapath_resp_t dp_ret;
 
+   decoder->prev_return = OCSD_RESP_CONT;
+
dp_ret = ocsd_dt_process_data(decoder->dcd_tree, OCSD_OP_RESET,
  0, 0, NULL, NULL);
if (OCSD_DATA_RESP_IS_FATAL(dp_ret))
@@ -253,16 +255,16 @@ static void cs_etm_decoder__clear_buffer(struct 
cs_etm_decoder *decoder)
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
decoder->packet_buffer[i].start_addr = 0xdeadbeefdeadbeefUL;
-   decoder->packet_buffer[i].end_addr   = 0xdeadbeefdeadbeefUL;
-   decoder->packet_buffer[i].exc= false;
-   decoder->packet_buffer[i].exc_ret= false;
-   decoder->packet_buffer[i].cpu= INT_MIN;
+   decoder->packet_buffer[i].end_addr = 0xdeadbeefdeadbeefUL;
+   decoder->packet_buffer[i].last_instr_taken_branch = false;
+   decoder->packet_buffer[i].exc = false;
+   decoder->packet_buffer[i].exc_ret = false;
+   decoder->packet_buffer[i].cpu = INT_MIN;
}
 }
 
 static ocsd_datapath_resp_t
 cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
- const ocsd_generic_trace_elem *elem,
  const u8 trace_chan_id,
  enum cs_etm_sample_type sample_type)
 {
@@ -278,18 +280,16 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder 
*decoder,
return OCSD_RESP_FATAL_SYS_ERR;
 
et = decoder->tail;
+   et = (et + 1) & (MAX_BUFFER - 1);
+   decoder->tail = et;
+   decoder->packet_count++;
+
decoder->packet_buffer[et].sample_type = sample_type;
-   decoder->packet_buffer[et].start_addr = elem->st_addr;
-   decoder->packet_buffer[et].end_addr = elem->en_addr;
decoder->packet_buffer[et].exc = false;
decoder->packet_buffer[et].exc_ret = false;
decoder->packet_buffer[et].cpu = *((int *)inode->priv);
-
-   /* Wrap around if need be */
-   et = (et + 1) & (MAX_BUFFER - 1);
-
-   decoder->tail = et;
-   decoder->packet_count++;
+   decoder->packet_buffer[et].start_addr = 0xdeadbeefdeadbeefUL;
+   decoder->packet_buffer[et].end_addr = 0xdeadbeefdeadbeefUL;
 
if (decoder->packet_count == MAX_BUFFER - 1)
return OCSD_RESP_WAIT;
@@ -297,6 +297,40 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder 
*decoder,
return OCSD_RESP_CONT;
 }
 
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
+const ocsd_generic_trace_elem *elem,
+const uint8_t trace_chan_id)
+{
+   int ret = 0;
+   struct cs_etm_packet *packet;
+
+   ret = cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+   CS_ETM_RANGE);
+   if (ret != OC

[PATCH] x86/microcode/intel: Check microcode revision before updating sibling threads

[Ashok Raj]

After updating microcode on one of the threads in the core, the
thread sibling automatically gets the update since the microcode
resources are shared. Check the ucode revision on the cpu before
performing a ucode update.

Signed-off-by: Ashok Raj 
Cc: X86 ML 
Cc: LKML 
---
 arch/x86/kernel/cpu/microcode/intel.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
b/arch/x86/kernel/cpu/microcode/intel.c
index 09b95a7..036d1db 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -776,7 +776,7 @@ static enum ucode_state apply_microcode_intel(int cpu)
 {
struct microcode_intel *mc;
struct ucode_cpu_info *uci;
-   struct cpuinfo_x86 *c;
+   struct cpuinfo_x86 *c = &cpu_data(cpu);
static int prev_rev;
u32 rev;
 
@@ -793,6 +793,18 @@ static enum ucode_state apply_microcode_intel(int cpu)
return UCODE_NFOUND;
}
 
+   rev = intel_get_microcode_revision();
+   /*
+* Its possible the microcode got udpated
+* because its sibling update was done earlier.
+* Skip the udpate in that case.
+*/
+   if (rev >= mc->hdr.rev) {
+   uci->cpu_sig.rev = rev;
+   c->microcode = rev;
+   return UCODE_OK;
+   }
+
/* write microcode via MSR 0x79 */
wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
 
@@ -813,8 +825,6 @@ static enum ucode_state apply_microcode_intel(int cpu)
prev_rev = rev;
}
 
-   c = &cpu_data(cpu);
-
uci->cpu_sig.rev = rev;
c->microcode = rev;
 
-- 
2.7.4

[PATCH 28/41] perf inject: Emit instruction records on ETM trace discontinuity

[Arnaldo Carvalho de Melo]

From: Robert Walker 

There may be discontinuities in the ETM trace stream due to overflows or
ETM configuration for selective trace.  This patch emits an instruction
sample with the pending branch stack when a TRACE ON packet occurs
indicating a discontinuity in the trace data.

A new packet type CS_ETM_TRACE_ON is added, which is emitted by the low
level decoder when a TRACE ON occurs.  The higher level decoder flushes
the branch stack when this packet is emitted.

Signed-off-by: Robert Walker 
Acked-by: Mathieu Poirier 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518607481-4059-3-git-send-email-robert.wal...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c |  9 +++
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h |  1 +
 tools/perf/util/cs-etm.c| 80 ++---
 3 files changed, 67 insertions(+), 23 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 8ff69dfd725a..640af88331b4 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -328,7 +328,14 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder 
*decoder,
}
 
return ret;
+}
 
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_trace_on(struct cs_etm_decoder *decoder,
+   const uint8_t trace_chan_id)
+{
+   return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+CS_ETM_TRACE_ON);
 }
 
 static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
@@ -347,6 +354,8 @@ static ocsd_datapath_resp_t 
cs_etm_decoder__gen_trace_elem_printer(
decoder->trace_on = false;
break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
+   resp = cs_etm_decoder__buffer_trace_on(decoder,
+  trace_chan_id);
decoder->trace_on = true;
break;
case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index a4fdd285b145..743f5f444304 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -24,6 +24,7 @@ struct cs_etm_buffer {
 
 enum cs_etm_sample_type {
CS_ETM_RANGE = 1 << 0,
+   CS_ETM_TRACE_ON = 1 << 1,
 };
 
 struct cs_etm_packet {
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6e595d96c04d..1b0d422373be 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -867,6 +867,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
 */
if (etm->synth_opts.last_branch &&
etmq->prev_packet &&
+   etmq->prev_packet->sample_type == CS_ETM_RANGE &&
etmq->prev_packet->last_instr_taken_branch)
cs_etm__update_last_branch_rb(etmq);
 
@@ -920,6 +921,40 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
return 0;
 }
 
+static int cs_etm__flush(struct cs_etm_queue *etmq)
+{
+   int err = 0;
+   struct cs_etm_packet *tmp;
+
+   if (etmq->etm->synth_opts.last_branch &&
+   etmq->prev_packet &&
+   etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+   /*
+* Generate a last branch event for the branches left in the
+* circular buffer at the end of the trace.
+*
+* Use the address of the end of the last reported execution
+* range
+*/
+   u64 addr = cs_etm__last_executed_instr(etmq->prev_packet);
+
+   err = cs_etm__synth_instruction_sample(
+   etmq, addr,
+   etmq->period_instructions);
+   etmq->period_instructions = 0;
+
+   /*
+* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
+* the next incoming packet.
+*/
+   tmp = etmq->packet;
+   etmq->packet = etmq->prev_packet;
+   etmq->prev_packet = tmp;
+   }
+
+   return err;
+}
+
 static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
 {
struct cs_etm_auxtrace *etm = etmq->etm;
@@ -971,32 +1006,31 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
 */
break;
 
-   /*
-* If the packet contains an instruction
-* range, generate instruction sequence
-* events.
-*/
-   if (etmq->packet->sample_type & CS_ETM_RANGE)
-

[PATCH 26/41] perf mem: Document a missing option

[Arnaldo Carvalho de Melo]

From: Sangwon Hong 

Add the missing --force option on the man page.

Signed-off-by: Sangwon Hong 
Acked-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Taeung Song 
Link: 
http://lkml.kernel.org/r/1518381517-30766-2-git-send-email-qpa...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-mem.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/Documentation/perf-mem.txt 
b/tools/perf/Documentation/perf-mem.txt
index 4be08a1e3f8d..b0211410969b 100644
--- a/tools/perf/Documentation/perf-mem.txt
+++ b/tools/perf/Documentation/perf-mem.txt
@@ -28,6 +28,10 @@ OPTIONS
 ...::
Any command you can specify in a shell.
 
+-f::
+--force::
+   Don't do ownership validation
+
 -t::
 --type=::
Select the memory operation type: load or store (default: load,store)
-- 
2.14.3

[PATCH 29/41] coresight: Update documentation for perf usage

[Arnaldo Carvalho de Melo]

From: Robert Walker 

Add notes on using perf to collect and analyze CoreSight trace

Signed-off-by: Robert Walker 
Cc: Mathieu Poirier 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518607481-4059-4-git-send-email-robert.wal...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 Documentation/trace/coresight.txt | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index a33c88cd5d1d..6f0120c3a4f1 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -330,3 +330,54 @@ Details on how to use the generic STM API can be found 
here [2].
 
 [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 [2]. Documentation/trace/stm.txt
+
+
+Using perf tools
+
+
+perf can be used to record and analyze trace of programs.
+
+Execution can be recorded using 'perf record' with the cs_etm event,
+specifying the name of the sink to record to, e.g:
+
+perf record -e cs_etm/@2007.etr/u --per-thread
+
+The 'perf report' and 'perf script' commands can be used to analyze execution,
+synthesizing instruction and branch events from the instruction trace.
+'perf inject' can be used to replace the trace data with the synthesized 
events.
+The --itrace option controls the type and frequency of synthesized events
+(see perf documentation).
+
+Note that only 64-bit programs are currently supported - further work is
+required to support instruction decode of 32-bit Arm programs.
+
+
+Generating coverage files for Feedback Directed Optimization: AutoFDO
+-
+
+'perf inject' accepts the --itrace option in which case tracing data is
+removed and replaced with the synthesized events. e.g.
+
+   perf inject --itrace --strip -i perf.data -o perf.data.new
+
+Below is an example of using ARM ETM for autoFDO.  It requires autofdo
+(https://github.com/google/autofdo) and gcc version 5.  The bubble
+sort example is from the AutoFDO tutorial 
(https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
+
+   $ gcc-5 -O3 sort.c -o sort
+   $ taskset -c 2 ./sort
+   Bubble sorting array of 3 elements
+   5910 ms
+
+   $ perf record -e cs_etm/@2007.etr/u --per-thread taskset -c 2 ./sort
+   Bubble sorting array of 3 elements
+   12543 ms
+   [ perf record: Woken up 35 times to write data ]
+   [ perf record: Captured and wrote 69.640 MB perf.data ]
+
+   $ perf inject -i perf.data -o inj.data --itrace=il64 --strip
+   $ create_gcov --binary=./sort --profile=inj.data --gcov=sort.gcov 
-gcov_version=1
+   $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
+   $ taskset -c 2 ./sort_autofdo
+   Bubble sorting array of 3 elements
+   5806 ms
-- 
2.14.3

[PATCH 32/41] perf report: Fix memory corruption in --branch-history mode --branch-history

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Jin Yao reported memory corrupton in perf report with
branch info used for stack trace:

  > Following command lines will cause perf crash.

  > perf record -j call -g -a 
  > perf report --branch-history
  >
  > *** Error in `perf': double free or corruption (!prev): 0x104aa040 
***
  > === Backtrace: =
  > /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725]
  > /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a]
  > /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc]
  > perf[0x51b914]
  > perf(hist_entry_iter__add+0x1e5)[0x51f305]
  > perf[0x43cf01]
  > perf[0x4fa3bf]
  > perf[0x4fa923]
  > perf[0x4fd396]
  > perf[0x4f9614]
  > perf(perf_session__process_events+0x89e)[0x4fc38e]
  > perf(cmd_report+0x15d2)[0x43f202]
  > perf[0x4a059f]
  > perf(main+0x631)[0x427b71]
  > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830]
  > perf(_start+0x29)[0x427d89]

For the cumulative output, we allocate the he_cache array based on the
--max-stack option value and populate it with data from 'callchain_cursor'.

The --max-stack option value does not ensure now the limit for number of
callchain_cursor nodes, so the cumulative iter code will allocate smaller array
than it's actually needed and cause above corruption.

I think the --max-stack limit does not apply here anyway, because we add
callchain data as normal hist entries, while the --max-stack control the limit
of single entry callchain depth.

Using the callchain_cursor.nr as he_cache array count to fix this. Also
removing struct hist_entry_iter::max_stack, because there's no longer any use
for it.

We need more fixes to ensure that the branch stack code follows properly the
logic of --max-stack, which is not the case at the moment.

Original-patch-by: Jin Yao 
Signed-off-by: Jiri Olsa 
Reported-by: Jin Yao 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180216123619.GA9945@krava
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/hist.c | 4 +---
 tools/perf/util/hist.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b6140950301e..44a8456cea10 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -879,7 +879,7 @@ iter_prepare_cumulative_entry(struct hist_entry_iter *iter,
 * cumulated only one time to prevent entries more than 100%
 * overhead.
 */
-   he_cache = malloc(sizeof(*he_cache) * (iter->max_stack + 1));
+   he_cache = malloc(sizeof(*he_cache) * (callchain_cursor.nr + 1));
if (he_cache == NULL)
return -ENOMEM;
 
@@ -1045,8 +1045,6 @@ int hist_entry_iter__add(struct hist_entry_iter *iter, 
struct addr_location *al,
if (err)
return err;
 
-   iter->max_stack = max_stack_depth;
-
err = iter->ops->prepare_entry(iter, al);
if (err)
goto out;
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 02721b579746..e869cad4d89f 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -107,7 +107,6 @@ struct hist_entry_iter {
int curr;
 
bool hide_unresolved;
-   int max_stack;
 
struct perf_evsel *evsel;
struct perf_sample *sample;
-- 
2.14.3

RE: [PATCH 0/2] efivars: reading variables can generate SMIs

[Luck, Tony]

> tl;dr: I think changing everything to 0600 is probably completely fine,
> and whitelisting is probably pointless.  

But do you speak for all users? It will just take one person complaining
that efibootmgr no longer shows them what it used to show to bring down
the wrath of Linus on our (specifically Joe's) head for breaking user space.

I've got someone about to start looking at making efivarfs read and save
the values during mount, so all the read-only options can continue to work
without making EFI calls.

This will cost some memory (say 20-30 variables at up to 1K each).

-Tony

Re: [PATCH v1] platform/x86: wmi: Replace kmalloc + sprintf() with kasprintf()

[Andy Shevchenko]

On Fri, Feb 16, 2018 at 5:55 PM, David Laight  wrote:

>> kasprintf() does the job of two: kmalloc() and sprintf().
>> Replace two calls with one.
> ...
>> - buf = kmalloc(strlen(wdriver->driver.name) + 5, GFP_KERNEL);
>> + buf = kasprintf(GFP_KERNEL, "wmi/%s", wdriver->driver.name);
> ...
>
> Except that kasprintf() has no idea how long a buffer is needed.

Hmm...

> It might even do the printf twice just to get the length.

It does exactly that. So what?

-- 
With Best Regards,
Andy Shevchenko

[PATCH v1 1/7] lib/test_printf: Mark big constant with ULL

[Andy Shevchenko]

Sparse complains that constant is so bit for unsigned long on 64-bit
architecture.

lib/test_printf.c:217:54: warning: constant 0x0123456789ab is so big it is 
unsigned long
lib/test_printf.c:246:54: warning: constant 0x0123456789ab is so big it is 
unsigned long

To satisfy everyone, mark the constant with ULL.

Signed-off-by: Andy Shevchenko 
---
 lib/test_printf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_printf.c b/lib/test_printf.c
index 71ebfa43ad05..309cf8d7e6d4 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -204,7 +204,7 @@ test_string(void)
 #if BITS_PER_LONG == 64
 
 #define PTR_WIDTH 16
-#define PTR ((void *)0x0123456789ab)
+#define PTR ((void *)0x0123456789abULL)
 #define PTR_STR "0123456789ab"
 #define ZEROS ""   /* hex 32 zero bits */
 
-- 
2.15.1

[PATCH v1 3/7] lib/vsprintf: Replace ' ' with '_' before crng is ready

[Andy Shevchenko]

From: Shunyong Yang 

Before crng is ready, output of "%p" composes of "(ptrval)" and
left padding spaces for alignment as no random address can be
generated. This seems a little strange when default string width
is larger than strlen("(ptrval)").

For example, when irq domain names are built with "%p", the nodes
under /sys/kernel/debug/irq/domains like this on AArch64 system,

[root@y irq]# ls domains/
default   irqchip@(ptrval)-2
irqchip@(ptrval)-4  \_SB_.TCS0.QIC1  \_SB_.TCS0.QIC3
irqchip@(ptrval)  irqchip@(ptrval)-3
\_SB_.TCS0.QIC0 \_SB_.TCS0.QIC2

The name "irqchip@(ptrval)-2" is not so readable in console
output.

This patch replaces space with readable "=" when output needs padding.
Following is the output after applying the patch,

[root@y domains]# ls
default   irqchip@(ptrval)-2
irqchip@(ptrval)-4  \_SB_.TCS0.QIC1  \_SB_.TCS0.QIC3
irqchip@(ptrval)  irqchip@(ptrval)-3  \_SB_.TCS0.QIC0
\_SB_.TCS0.QIC2

There is same problem in some subsystem's dmesg output. Moreover,
someone may call "%p" in a similar case. In addition, the timing of
crng initialization done may vary on different system. So, the change
is made in vsprintf.c.

Cc: Joey Zheng 
Suggested-by: Rasmus Villemoes 
Signed-off-by: Shunyong Yang 
Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index b6d254723828..360e751305bf 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1696,12 +1696,13 @@ early_initcall(initialize_ptr_random);
 /* Maps a pointer to a 32 bit unique identifier. */
 static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
 {
+   const char *str = sizeof(ptr) == 8 ? "(ptrval)" : "(ptrval)";
unsigned long hashval;
 
if (unlikely(!have_filled_random_ptr_key)) {
spec.field_width = 2 * sizeof(ptr);
/* string length must be less than default_width */
-   return string(buf, end, "(ptrval)", spec);
+   return string(buf, end, str, spec);
}
 
 #ifdef CONFIG_64BIT
-- 
2.15.1

[PATCH v1 6/7] lib/vsprintf: Make strspec global

[Andy Shevchenko]

There is at least one new user is coming where default specification to print
strings is in use.

Make it global.

Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3a02fcaf8ac8..20c0ab9faba5 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -693,6 +693,11 @@ char *symbol_string(char *buf, char *end, void *ptr,
 #endif
 }
 
+static const struct printf_spec default_str_spec = {
+   .field_width = -1,
+   .precision = -1,
+};
+
 static const struct printf_spec default_dec_spec = {
.base = 10,
.precision = -1,
@@ -1453,10 +1458,6 @@ char *format_flags(char *buf, char *end, unsigned long 
flags,
const struct trace_print_flags *names)
 {
unsigned long mask;
-   const struct printf_spec strspec = {
-   .field_width = -1,
-   .precision = -1,
-   };
const struct printf_spec numspec = {
.flags = SPECIAL|SMALL,
.field_width = -1,
@@ -1469,7 +1470,7 @@ char *format_flags(char *buf, char *end, unsigned long 
flags,
if ((flags & mask) != mask)
continue;
 
-   buf = string(buf, end, names->name, strspec);
+   buf = string(buf, end, names->name, default_str_spec);
 
flags &= ~mask;
if (flags) {
-- 
2.15.1

[PATCH v1 2/7] lib/vsprintf: Deduplicate pointer_string()

[Andy Shevchenko]

There is an exact code at the end of ptr_to_id().
Replace it by calling pointer_string() directly.

This is followup to the commit
  ad67b74d2469 ("printk: hash addresses printed with %p").

Cc: Tobin C. Harding 
Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index d7a708f82559..b6d254723828 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1697,10 +1697,9 @@ early_initcall(initialize_ptr_random);
 static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
 {
unsigned long hashval;
-   const int default_width = 2 * sizeof(ptr);
 
if (unlikely(!have_filled_random_ptr_key)) {
-   spec.field_width = default_width;
+   spec.field_width = 2 * sizeof(ptr);
/* string length must be less than default_width */
return string(buf, end, "(ptrval)", spec);
}
@@ -1715,15 +1714,7 @@ static char *ptr_to_id(char *buf, char *end, void *ptr, 
struct printf_spec spec)
 #else
hashval = (unsigned long)siphash_1u32((u32)ptr, &ptr_key);
 #endif
-
-   spec.flags |= SMALL;
-   if (spec.field_width == -1) {
-   spec.field_width = default_width;
-   spec.flags |= ZEROPAD;
-   }
-   spec.base = 16;
-
-   return number(buf, end, hashval, spec);
+   return pointer_string(buf, end, (const void *)hashval, spec);
 }
 
 /*
-- 
2.15.1

[PATCH v1 4/7] lib/vsprintf: Remove useless NULL checks

[Andy Shevchenko]

The pointer can't be NULL since it's first what has been done in the
pointer().

Remove useless checks.

Note we leave check for !CONFIG_HAVE_CLK to make compiler
to optimize code away when possible.

Cc: Petr Mladek 
Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 360e751305bf..79f27ebdeb6e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -813,10 +813,6 @@ char *hex_string(char *buf, char *end, u8 *addr, struct 
printf_spec spec,
/* nothing to print */
return buf;
 
-   if (ZERO_OR_NULL_PTR(addr))
-   /* NULL pointer */
-   return string(buf, end, NULL, spec);
-
switch (fmt[1]) {
case 'C':
separator = ':';
@@ -1255,10 +1251,6 @@ char *escaped_string(char *buf, char *end, u8 *addr, 
struct printf_spec spec,
if (spec.field_width == 0)
return buf; /* nothing to print */
 
-   if (ZERO_OR_NULL_PTR(addr))
-   return string(buf, end, NULL, spec);/* NULL pointer */
-
-
do {
switch (fmt[count++]) {
case 'a':
@@ -1442,7 +1434,7 @@ static noinline_for_stack
 char *clock(char *buf, char *end, struct clk *clk, struct printf_spec spec,
const char *fmt)
 {
-   if (!IS_ENABLED(CONFIG_HAVE_CLK) || !clk)
+   if (!IS_ENABLED(CONFIG_HAVE_CLK))
return string(buf, end, NULL, spec);
 
switch (fmt[1]) {
@@ -1581,9 +1573,6 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
if (!IS_ENABLED(CONFIG_OF))
return string(buf, end, "(!OF)", spec);
 
-   if ((unsigned long)dn < PAGE_SIZE)
-   return string(buf, end, "(null)", spec);
-
/* simple case without anything any more format specifiers */
fmt++;
if (fmt[0] == '\0' || strcspn(fmt,"fnpPFcC") > 0)
-- 
2.15.1

[PATCH v1 5/7] lib/vsprintf: Make decspec global

[Andy Shevchenko]

There are places where default specification to print decimal numbers
is in use.

Make it global and convert existing users.

Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 79f27ebdeb6e..3a02fcaf8ac8 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -693,6 +693,11 @@ char *symbol_string(char *buf, char *end, void *ptr,
 #endif
 }
 
+static const struct printf_spec default_dec_spec = {
+   .base = 10,
+   .precision = -1,
+};
+
 static noinline_for_stack
 char *resource_string(char *buf, char *end, struct resource *res,
  struct printf_spec spec, const char *fmt)
@@ -722,11 +727,6 @@ char *resource_string(char *buf, char *end, struct 
resource *res,
.precision = -1,
.flags = SMALL | ZEROPAD,
};
-   static const struct printf_spec dec_spec = {
-   .base = 10,
-   .precision = -1,
-   .flags = 0,
-   };
static const struct printf_spec str_spec = {
.field_width = -1,
.precision = 10,
@@ -760,10 +760,10 @@ char *resource_string(char *buf, char *end, struct 
resource *res,
specp = &mem_spec;
} else if (res->flags & IORESOURCE_IRQ) {
p = string(p, pend, "irq ", str_spec);
-   specp = &dec_spec;
+   specp = &default_dec_spec;
} else if (res->flags & IORESOURCE_DMA) {
p = string(p, pend, "dma ", str_spec);
-   specp = &dec_spec;
+   specp = &default_dec_spec;
} else if (res->flags & IORESOURCE_BUS) {
p = string(p, pend, "bus ", str_spec);
specp = &bus_spec;
@@ -899,9 +899,6 @@ char *bitmap_list_string(char *buf, char *end, unsigned 
long *bitmap,
int cur, rbot, rtop;
bool first = true;
 
-   /* reused to print numbers */
-   spec = (struct printf_spec){ .base = 10 };
-
rbot = cur = find_first_bit(bitmap, nr_bits);
while (cur < nr_bits) {
rtop = cur;
@@ -916,13 +913,13 @@ char *bitmap_list_string(char *buf, char *end, unsigned 
long *bitmap,
}
first = false;
 
-   buf = number(buf, end, rbot, spec);
+   buf = number(buf, end, rbot, default_dec_spec);
if (rbot < rtop) {
if (buf < end)
*buf = '-';
buf++;
 
-   buf = number(buf, end, rtop, spec);
+   buf = number(buf, end, rtop, default_dec_spec);
}
 
rbot = cur;
-- 
2.15.1

[PATCH v1 7/7] lib/vsprintf: Mark expected switch fall-through

[Andy Shevchenko]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 20c0ab9faba5..bf0c45788100 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2094,6 +2094,7 @@ int format_decode(const char *fmt, struct printf_spec 
*spec)
 
case 'x':
spec->flags |= SMALL;
+   /* fall through */
 
case 'X':
spec->base = 16;
@@ -3048,8 +3049,10 @@ int vsscanf(const char *buf, const char *fmt, va_list 
args)
break;
case 'i':
base = 0;
+   /* fall through */
case 'd':
is_sign = true;
+   /* fall through */
case 'u':
break;
case '%':
-- 
2.15.1

Re: [PATCH v4 4/4] arm64: dts: sdm845: Add serial console support

[Doug Anderson]

Hi,

On Thu, Feb 15, 2018 at 10:05 PM, Rajendra Nayak  wrote:
> Add the qup uart node and geni se instance needed to
> support the serial console on the MTP.
>
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 39 
> +
>  arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 
> +
>  2 files changed, 78 insertions(+)

Looks nice to me.  Thanks!

As in your cover letter, this patch will almost certainly need to be
spun again because it's based on bindings that have review feedback.
For those of you playing along at home, see
.  Thus, I'm not
providing a Reviewed-by tag at the moemnt.

I will still say thanks for posting this (even though it was based on
old bindings) since it allowed us to make some good progress ahead of
time so we'll be very close to landing when the serial patch is spun
next.


In my ideal world the first 3 patches of this series would land sooner
rather than later and then this 4th patch would simply be re-posted on
its own when the bindings get more finalized (or, even better, if the
first 3 patches have landed then Karthikeyan could just glom this on
to the end of his next spin of the serial driver.  ;-)


-Doug

Re: [PATCH v4 2/4] dt-bindings: qcom: Add SDM845 bindings

[Doug Anderson]

Hi,

On Thu, Feb 15, 2018 at 10:05 PM, Rajendra Nayak  wrote:
> Add a SoC string 'sdm845' for the qualcomm SDM845 SoC
>
> Signed-off-by: Rajendra Nayak 
> ---
>  Documentation/devicetree/bindings/arm/qcom.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson 

Re: [PATCH v4 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

[Doug Anderson]

Hi,

On Thu, Feb 15, 2018 at 10:05 PM, Rajendra Nayak  wrote:
> Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files
>
> Signed-off-by: Rajendra Nayak 
> Reviewed-by: Doug Anderson 
> ---
>  arch/arm64/boot/dts/qcom/Makefile   |   1 +
>  arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  15 ++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi| 277 
> 
>  3 files changed, 293 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> b/arch/arm64/boot/dts/qcom/Makefile
> index 55ec5ee7f7e8..9319e74b8906 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
>  dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
>  dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> new file mode 100644
> index ..979ab49913f1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0

This already has my Reviewed-by tag (and that's great), but just
making it clear that I am in favor of this landing with just the
GPL-2.0 license and not block waiting on the QC lawyers to hash out
whether the device tree can really be dual-licensed.

If lawyers come back soon then it will be easy to have a followup
patch that changes this.  Since (I don't think) any hobbyists have an
SDM845 in their hands right now it seems unlikely to be hard to track
down any authors in the meantime and make sure they're OK.

If lawyers don't come back soon then it will be a good thing that we
didn't block.


Having this skeleton DTS file land sooner rather than later will
unblock other patches to be sent out enabling other peripherals, which
seems like a nice thing.  :)


-Doug

Re: [PATCH v4 1/4] dt-bindings: arm: Document kryo385 cpu

[Doug Anderson]

Hi,

On Thu, Feb 15, 2018 at 10:05 PM, Rajendra Nayak  wrote:
> Document the compatible string for the Kryo385 cpus found in qualcomm
> SoCs.
>
> Signed-off-by: Rajendra Nayak 
> Reviewed-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

FWIW since my review doesn't add much atop Rob's:

Reviewed-by: Douglas Anderson 

[PATCH 33/41] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Will be used for generating the syscall id/string translation table.

Committer notes:

Update it already to catch with these csets applied since Ravi first
submitted this patch:

  3350eb2ea127 powerpc: sys_pkey_mprotect() system call
  9499ec1b5e82 powerpc: sys_pkey_alloc() and sys_pkey_free() system calls

So now 'perf trace' on ppc now knows about the pkey_ syscals.

Signed-off-by: Ravi Bangoria 
Cc: Alexander Shishkin 
Cc: Hendrik Brueckner 
Cc: Jiri Olsa 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/20180129083417.31240-2-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/powerpc/include/uapi/asm/unistd.h | 402 +++
 tools/perf/check-headers.sh  |   1 +
 2 files changed, 403 insertions(+)
 create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h

diff --git a/tools/arch/powerpc/include/uapi/asm/unistd.h 
b/tools/arch/powerpc/include/uapi/asm/unistd.h
new file mode 100644
index ..389c36fd8299
--- /dev/null
+++ b/tools/arch/powerpc/include/uapi/asm/unistd.h
@@ -0,0 +1,402 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * This file contains the system call numbers.
+ *
+ * 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.
+ */
+#ifndef _UAPI_ASM_POWERPC_UNISTD_H_
+#define _UAPI_ASM_POWERPC_UNISTD_H_
+
+
+#define __NR_restart_syscall 0
+#define __NR_exit1
+#define __NR_fork2
+#define __NR_read3
+#define __NR_write   4
+#define __NR_open5
+#define __NR_close   6
+#define __NR_waitpid 7
+#define __NR_creat   8
+#define __NR_link9
+#define __NR_unlink 10
+#define __NR_execve 11
+#define __NR_chdir  12
+#define __NR_time   13
+#define __NR_mknod  14
+#define __NR_chmod  15
+#define __NR_lchown 16
+#define __NR_break  17
+#define __NR_oldstat18
+#define __NR_lseek  19
+#define __NR_getpid 20
+#define __NR_mount  21
+#define __NR_umount 22
+#define __NR_setuid 23
+#define __NR_getuid 24
+#define __NR_stime  25
+#define __NR_ptrace 26
+#define __NR_alarm  27
+#define __NR_oldfstat   28
+#define __NR_pause  29
+#define __NR_utime  30
+#define __NR_stty   31
+#define __NR_gtty   32
+#define __NR_access 33
+#define __NR_nice   34
+#define __NR_ftime  35
+#define __NR_sync   36
+#define __NR_kill   37
+#define __NR_rename 38
+#define __NR_mkdir  39
+#define __NR_rmdir  40
+#define __NR_dup41
+#define __NR_pipe   42
+#define __NR_times  43
+#define __NR_prof   44
+#define __NR_brk45
+#define __NR_setgid 46
+#define __NR_getgid 47
+#define __NR_signal 48
+#define __NR_geteuid49
+#define __NR_getegid50
+#define __NR_acct   51
+#define __NR_umount252
+#define __NR_lock   53
+#define __NR_ioctl  54
+#define __NR_fcntl  55
+#define __NR_mpx56
+#define __NR_setpgid57
+#define __NR_ulimit 58
+#define __NR_oldolduname59
+#define __NR_umask  60
+#define __NR_chroot 61
+#define __NR_ustat  62
+#define __NR_dup2   63
+#define __NR_getppid64
+#define __NR_getpgrp65
+#define __NR_setsid 66
+#define __NR_sigaction  67
+#define __NR_sgetmask   68
+#define __NR_ssetmask   69
+#define __NR_setreuid   70
+#define __NR_setregid   71
+#define __NR_sigsuspend 72
+#define __NR_sigpending 73
+#define __NR_sethostname74
+#define __NR_setrlimit  75
+#define __NR_getrlimit  76
+#define __NR_getrusage  77
+#define __NR_gettimeofday   78
+#define __NR_settimeofday   79
+#define __NR_getgroups  80
+#define __NR_setgroups  81
+#define __NR_select 82
+#define __NR_symlink83
+#define __NR_oldlstat   84
+#define __NR_readlink   85
+#define __NR_uselib 86
+#define __NR_swapon 87
+#define __NR_reboot 88
+#define __NR_readdir89
+#define __NR_mmap   90
+#define __NR_munmap 91
+#define __NR_tru

Re: [PATCH v5 0/3] Support Perf Extension on AMD KVM guests

[Natarajan, Janakarajan]

On 2/5/2018 1:24 PM, Janakarajan Natarajan wrote:

This patchset adds support for Perf Extension on AMD KVM guests.

When perf runs on a guest with family = 15h || 17h, the MSRs that are
accessed, when the Perf Extension flag is made available, differ from
the existing K7 MSRs. The accesses are to the AMD Core Performance
Extension counters which provide 2 extra counters and new MSRs for both
the event select and counter registers.

Since the new event select and counter MSRs are interleaved and K7 MSRs
are contiguous, the logic to map them to the gp_counters[] is changed.

This patchset has been tested with Family 17h and Opteron G1 guests.

v1->v2:
* Rearranged MSR #defines based on Boris's suggestion.

v2->v3:
* Changed the logic of mapping MSR to gp_counters[] index based on
   Boris's feedback.
* Removed use of family checks based on Radim's feedback.
* Removed KVM bugfix patch since it is already applied.

v3->v4:
* Rebased to latest KVM tree.

v4->v5:
* Removed conditional check when exposing Perf Extension flag to
   guests based on Radim's feedback.

Janakarajan Natarajan (3):
   x86/msr: Add AMD Core Perf Extension MSRs
   x86/kvm: Add support for AMD Core Perf Extension in guest
   x86/kvm: Expose AMD Core Perf Extension flag to guests


Are there any concerns regarding this patchset?

Thanks.



  arch/x86/include/asm/msr-index.h |  14 
  arch/x86/kvm/cpuid.c |   2 +-
  arch/x86/kvm/pmu_amd.c   | 140 +++
  arch/x86/kvm/x86.c   |   1 +
  4 files changed, 142 insertions(+), 15 deletions(-)

[PATCH 35/41] perf trace powerpc: Use generated syscall table

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.

It also enables users to specify wildcards, for example, perf trace -e
'open*', just like was already possible on x86 and s390.

Signed-off-by: Ravi Bangoria 
Cc: Alexander Shishkin 
Cc: Hendrik Brueckner 
Cc: Jiri Olsa 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/20180129083417.31240-4-ravi.bango...@linux.vnet.ibm.com
[ Do it for ppc32 as well ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.config   | 2 ++
 tools/perf/util/syscalltbl.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 0dfdaa9fa81e..577a5d2988fe 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -27,6 +27,8 @@ NO_SYSCALL_TABLE := 1
 # Additional ARCH settings for ppc
 ifeq ($(SRCARCH),powerpc)
   NO_PERF_REGS := 0
+  NO_SYSCALL_TABLE := 0
+  CFLAGS += -I$(OUTPUT)arch/powerpc/include/generated
   LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
 endif
 
diff --git a/tools/perf/util/syscalltbl.c b/tools/perf/util/syscalltbl.c
index 303bdb84ab5a..895122d638dd 100644
--- a/tools/perf/util/syscalltbl.c
+++ b/tools/perf/util/syscalltbl.c
@@ -30,6 +30,14 @@ static const char **syscalltbl_native = syscalltbl_x86_64;
 #include 
 const int syscalltbl_native_max_id = SYSCALLTBL_S390_64_MAX_ID;
 static const char **syscalltbl_native = syscalltbl_s390_64;
+#elif defined(__powerpc64__)
+#include 
+const int syscalltbl_native_max_id = SYSCALLTBL_POWERPC_64_MAX_ID;
+static const char **syscalltbl_native = syscalltbl_powerpc_64;
+#elif defined(__powerpc__)
+#include 
+const int syscalltbl_native_max_id = SYSCALLTBL_POWERPC_32_MAX_ID;
+static const char **syscalltbl_native = syscalltbl_powerpc_32;
 #endif
 
 struct syscall {
-- 
2.14.3

[PATCH 36/41] perf record: Provide detailed information on s390 CPU

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

When perf record ... is setup to record data, the s390 cpu information
was a fixed string "IBM/S390".

Replace this string with one containing more information about the
machine. The information included in the cpuid is a comma separated
list:

   manufacturer,type,model-capacity,model[,version,authorization]
with

- manufacturer: up to 16 byte name of the manufacturer (IBM).
- type: a four digit number refering to the machine
  generation.
- model-capacitiy: up to 16 characters describing number
  of cpus etc.
- model: up to 16 characters describing model.
- version: the CPU-MF counter facility version number,
  available on LPARs only, omitted on z/VM guests.
- authorization: the CPU-MF counter facility authorization level,
  available on LPARs only, omitted on z/VM guests.

Before:

  [root@s8360047 perf]# ./perf record -- sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.001 MB perf.data (4 samples) ]
  [root@s8360047 perf]# ./perf report --header | fgrep cpuid
   # cpuid : IBM/S390
  [root@s8360047 perf]#

After:

  [root@s35lp76 perf]# ./perf report --header|fgrep cpuid
   # cpuid : IBM,3906,704,M03,3.5,002f
  [root@s35lp76 perf]#

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180213151419.80737-1-tmri...@linux.vnet.ibm.com
[ Use scnprintf instead of strncat to fix build errors on gcc GNU C99 5.4.0 
20160609 -march=zEC12 -m64 -mzarch -ggdb3 -O6 -std=gnu99 -fPIC 
-fno-omit-frame-pointer -funwind-tables -fstack-protector-all ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/header.c | 130 +++--
 1 file changed, 125 insertions(+), 5 deletions(-)

diff --git a/tools/perf/arch/s390/util/header.c 
b/tools/perf/arch/s390/util/header.c
index 9fa6c3e5782c..a78064c25ced 100644
--- a/tools/perf/arch/s390/util/header.c
+++ b/tools/perf/arch/s390/util/header.c
@@ -1,8 +1,9 @@
 /*
  * Implementation of get_cpuid().
  *
- * Copyright 2014 IBM Corp.
+ * Copyright IBM Corp. 2014, 2018
  * Author(s): Alexander Yarygin 
+ *   Thomas Richter 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License (version 2 only)
@@ -13,16 +14,135 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../util/header.h"
+#include "../../util/util.h"
+
+#define SYSINFO_MANU   "Manufacturer:"
+#define SYSINFO_TYPE   "Type:"
+#define SYSINFO_MODEL  "Model:"
+#define SRVLVL_CPUMF   "CPU-MF:"
+#define SRVLVL_VERSION "version="
+#define SRVLVL_AUTHORIZATION   "authorization="
+#define SYSINFO"/proc/sysinfo"
+#define SRVLVL "/proc/service_levels"
 
 int get_cpuid(char *buffer, size_t sz)
 {
-   const char *cpuid = "IBM/S390";
+   char *cp, *line = NULL, *line2;
+   char type[8], model[33], version[8], manufacturer[32], authorization[8];
+   int tpsize = 0, mdsize = 0, vssize = 0, mfsize = 0, atsize = 0;
+   int read;
+   unsigned long line_sz;
+   size_t nbytes;
+   FILE *sysinfo;
+
+   /*
+* Scan /proc/sysinfo line by line and read out values for
+* Manufacturer:, Type: and Model:, for example:
+* Manufacturer:IBM
+* Type:2964
+* Model:   702  N96
+* The first word is the Model Capacity and the second word is
+* Model (can be omitted). Both words have a maximum size of 16
+* bytes.
+*/
+   memset(manufacturer, 0, sizeof(manufacturer));
+   memset(type, 0, sizeof(type));
+   memset(model, 0, sizeof(model));
+   memset(version, 0, sizeof(version));
+   memset(authorization, 0, sizeof(authorization));
+
+   sysinfo = fopen(SYSINFO, "r");
+   if (sysinfo == NULL)
+   return -1;
+
+   while ((read = getline(&line, &line_sz, sysinfo)) != -1) {
+   if (!strncmp(line, SYSINFO_MANU, strlen(SYSINFO_MANU))) {
+   line2 = line + strlen(SYSINFO_MANU);
+
+   while ((cp = strtok_r(line2, "\n ", &line2))) {
+   mfsize += scnprintf(manufacturer + mfsize,
+   sizeof(manufacturer) - 
mfsize, "%s", cp);
+   }
+   }
+
+   if (!strncmp(line, SYSINFO_TYPE, strlen(SYSINFO_TYPE))) {
+   line2 = line + strlen(SYSINFO_TYPE);
+
+   while ((cp = strtok_r(line2, "\n ", &line2))) {
+   tpsize += scnprintf(type + tpsize,
+   sizeof(type) - tpsize, 
"%s", cp);
+   }
+   }
+
+   if (!strncmp(line, SYSINFO_MODEL, strlen(SYSINFO_MODEL))) {
+   line2 = line + strlen(SYSINFO_MODEL);
+
+   while ((cp 

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Greg Kroah-Hartman]

On Fri, Feb 16, 2018 at 10:10:44AM -0800, Brian Norris wrote:
> On Fri, Feb 16, 2018 at 07:48:50AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:
> > > On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > 
> > > Consider this an objection:
> > > 
> > > I'm currently arguing that this is unnecessarily regressing power
> > > consumption here:
> > > 
> > > https://patchwork.kernel.org/patch/10149195/
> > > 
> > > I'll leave it up to you what to do with this, but if this ends up in
> > > Chromium OS kernels, I'm likely to revert it there...
> > 
> > Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
> > here.
> 
> The link is the original patch, where I'm (too late?) complaining about
> its side effects. Hans and Marcel are discussing potential alternatives.
> This stuff happens in -rc kernels. But you're already ready to push it
> out to -stable users? I can try to push another few reverts into Linus's
> tree if that really helps, or else you can wait on pushing these to
> -stable until 4.16 settles down.

I can drop this for now, but I really like to be "bug compatible" with
Linus's tree if at all possible.  That keeps the pressure on people to
get Linus's tree fixed :)

I'll drop this if the maintainer tells me to do so...

thanks,

greg k-h

Dobrý deň, prosím, môžeme hovoriť?

[KATIE HIGGINS]

Re: [PATCH v5 1/3] sched: Stop nohz stats when decayed

[Valentin Schneider]

On 02/16/2018 05:02 PM, Vincent Guittot wrote:
> On 16 February 2018 at 13:53, Valentin Schneider
>  wrote:
>> On 02/14/2018 03:26 PM, Vincent Guittot wrote:
>>> Stopped the periodic update of blocked load when all idle CPUs have fully
>>> decayed. We introduce a new nohz.has_blocked that reflect if some idle
>>> CPUs has blocked load that have to be periodiccally updated. 
>>> nohz.has_blocked
>>> is set everytime that a Idle CPU can have blocked load and it is then clear
>>> when no more blocked load has been detected during an update. We don't need
>>> atomic operation but only to make cure of the right ordering when updating
>>> nohz.idle_cpus_mask and nohz.has_blocked.
>>>
>>> Suggested-by: Peter Zijlstra (Intel) 
>>> Signed-off-by: Vincent Guittot 
>>> ---
>>>  kernel/sched/fair.c  | 122 
>>> ++-
>>>  kernel/sched/sched.h |   1 +
>>>  2 files changed, 102 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 7af1fa9..5a6835e 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>>
>>> [...]
>>>
>>> -static void update_nohz_stats(struct rq *rq)
>>> +static bool update_nohz_stats(struct rq *rq)
>>>  {
>>>  #ifdef CONFIG_NO_HZ_COMMON
>>>   unsigned int cpu = rq->cpu;
>>>
>>> + if (!rq->has_blocked_load)
>>> + return false;
>>> +
>>>   if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask))
>>> - return;
>>> + return false;
>>>
>>>   if (!time_after(jiffies, rq->last_blocked_load_update_tick))
>>> - return;
>>> + return true;
>>>
>>>   update_blocked_averages(cpu);
>>> +
>>> + return rq->has_blocked_load;
>>> +#else
>>> + return false;
>>>  #endif
>>>  }
>>>
>>
>> (Wrongly thought that this bit was in a different patch, comment should have
>> been squashed in previous reply...)
>>
>> I've been thinking about this, and it's a messy one if we want to
>> skip CPUs in idle_balance() / clear the nohz.has_blocked_flag.
>>
>> AFAICT, the rq->has_blocked_load flag can be wrongly cleared: if we're
>> calling update_nohz_stats() for CPU A, but CPU A got out/in of
>> idle really quickly in that same timeframe, I'm not sure you can guarantee
>> the clearing of rq->has_blocked_load done in update_blocked_averages() will
>> always end up in memory before the setting of the flag in
>> nohz_balance_enter_idle().
> 
> Not sure it's a problem in this case because the clear done in
> update_blocked_averages() only happens if there is no load on the rq
> and new load can't be added in the mean time
> 

You're right, and that's why there's that comment:
>> /*
>>  * Can be set safely without rq->lock held
>>  * If a clear happens, it will have evaluated last additions because
>>  * rq->lock is held during the check and the clear
>>  */
>> rq->has_blocked_load = 1;

Even though it's clearly written there my brain wouldn't process the fact
that the flag is cleared with the rq lock held. So yeah, we can't wrongly
clear rq->has_blocked_load. The only mishap that can happen is that it is
re-raised even though we just went though an update_nohz_stats(), which would
lead to a useless stats update in the future, but that's not as bad.

[RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

[Dave Hansen]

Intel is considering adding a new bit to the IA32_ARCH_CAPABILITIES
MSR to tell when RSB underflow might be happen.  Feedback on this
would be greatly appreciated before the specification is finalized.

---

Background:

The RSB is a microarchitectural structure that attempts to help
predict the branch target of RET instructions.  It is implemented as a
stack that is pushed on CALL and popped on RET.  Being a stack, it can
become empty.  On some processors, an empty condition leads to use of
the other indirect branch predictors which have been targeted by
Spectre variant 2 (branch target injection) exploits.

Processors based on Skylake and its close derivatives have this
fallback behavior and need additional mitigation to avoid RSB-empty
conditions.  Right now, the only place we do this "RSB stuffing"
operation is at context switch.  We currently have a model/family list
to decide where to deploy this.

Problem:

However, that causes a problem in virtualization environments.  They
routinely expose a different model/family to guests than what the
bare-metal hardware has.  This, among other things, makes it easy to
migrate guests between different bare-metal systems with different
capabilities.  However, this defeats the Skylake-generation
model/family detection.

Solution:

To help address this issue, Intel is proposing a new bit in the
IA32_ARCH_CAPABILITIES MSR.  This bit, "RSB Override" (RSBO) would
indicate:

The CPU may predict the target of RET instructions with a
predictor other than the RSB when the RSB is 'empty'.

Hardware implementations may choose to set this, but it can also be
set by a hypervisor that traps RDMSR and simply wants to indicate to a
guest that it should deploy RSB-underflow mitigations.

An OS should assume that RSB-underflow mitigations are needed both
when RSBO=1 or when running on Skylake-generation processors with
RSBO=0.

Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: gno...@lxorguk.ukuu.org.uk
Cc: Rik van Riel 
Cc: Josh Poimboeuf 
Cc: thomas.lenda...@amd.com
Cc: Peter Zijlstra 
Cc: Jiri Kosina 
Cc: Andy Lutomirski 
Cc: Kees Cook 
Cc: Greg Kroah-Hartman 
Cc: Paul Turner 
Cc: David Woodhouse 
Cc: x...@kernel.org
Cc: Andi Kleen 
Cc: Tim Chen 
Cc: Arjan van de Ven 
Cc: Dan Williams 
Cc: Asit Mallick 

---

 b/arch/x86/include/asm/msr-index.h |1 
 b/arch/x86/kernel/cpu/bugs.c   |   47 +
 2 files changed, 43 insertions(+), 5 deletions(-)

diff -puN arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing 
arch/x86/kernel/cpu/bugs.c
--- a/arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing  2018-02-16 
10:06:56.807610157 -0800
+++ b/arch/x86/kernel/cpu/bugs.c2018-02-16 10:43:24.281604702 -0800
@@ -218,6 +218,43 @@ static bool __init is_skylake_era(void)
return false;
 }
 
+/*
+ * This MSR has a bit to indicate whether the processor might fall back to
+ * the BTB.  Hypervisors might lie about the model/family, breaking the
+ * is_skylake_era() check.  They might also want the OS to deploy
+ * mitigations because it *might* get migrated to other hardware that has
+ * this behavior, even if current bare-metal hardware is not exposed.
+ */
+static bool cpu_has_rsb_override(void)
+{
+   u64 ia32_cap = 0;
+
+if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
+   rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
+
+/* RSBO == RSB Override */
+if (ia32_cap & ARCH_CAP_RSBO)
+   return true;
+
+   return false;
+}
+
+/*
+ * Can a RET instruction on this CPU fall back to the BTB?
+ */
+static bool __init cpu_ret_uses_btb(void)
+{
+   /* All Skylake-era processors fall back to BTB */
+   if (is_skylake_era())
+   return true;
+
+   /* Does the ARCH_CAPABILITIES override the model/family we see? */
+   if (cpu_has_rsb_override())
+   return true;
+
+   return false;
+}
+
 static void __init spectre_v2_select_mitigation(void)
 {
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -283,14 +320,14 @@ retpoline_auto:
 * from a shallow call stack to a deeper one. To prevent this fill
 * the entire RSB, even when using IBRS.
 *
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
+* Some CPUs have a separate issue with *underflow* of the RSB,
+* when they will predict 'ret' targets from the generic BTB.  The
+* proper mitigation for this is IBRS. If IBRS is not supported or
+* deactivated in favour of retpolines the RSB fill on context
 * switch is required.
 */
if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
+!boot_cpu_has(X86_FEATU

Re: [PATCH 2/6] ARM: davinci: update the nand driver names

[Boris Brezillon]

On Fri, 16 Feb 2018 13:14:14 -0600
David Lechner  wrote:

> On 02/16/2018 10:47 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski 
> > 
> > Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
> > lookup table") we can no longer correctly lookup the nand clock when
> > booting in legacy mode. Said commit added a dev_id to the nand clock
> > which must match and it doesn't correspond with the device name which
> > is "davinci_nand" instead of "davinci-nand".
> > 
> > The driver name has been changed. Update the board files.
> > 
> > Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
> > table")
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> >   arch/arm/mach-davinci/board-da830-evm.c | 2 +-
> >   arch/arm/mach-davinci/board-da850-evm.c | 2 +-
> >   arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
> >   arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
> >   arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
> >   arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
> >   arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
> >   arch/arm/mach-davinci/board-mityomapl138.c  | 2 +-
> >   arch/arm/mach-davinci/board-neuros-osd2.c   | 2 +-
> >   arch/arm/mach-davinci/board-sffsdr.c| 2 +-
> >   10 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
> > b/arch/arm/mach-davinci/board-da830-evm.c
> > index f673cd7a6766..f8838c7b174b 100644
> > --- a/arch/arm/mach-davinci/board-da830-evm.c
> > +++ b/arch/arm/mach-davinci/board-da830-evm.c
> > @@ -348,7 +348,7 @@ static struct resource da830_evm_nand_resources[] = {
> >   };
> >   
> >   static struct platform_device da830_evm_nand_device = {
> > -   .name   = "davinci_nand",
> > +   .name   = "davinci-nand",
> > .id = 1,
> > .dev= {
> > .platform_data  = &da830_evm_nand_pdata,
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
> > b/arch/arm/mach-davinci/board-da850-evm.c
> > index d898a94f6eae..828194045a2b 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -266,7 +266,7 @@ static struct resource da850_evm_nandflash_resource[] = 
> > {
> >   };
> >   
> >   static struct platform_device da850_evm_nandflash_device = {
> > -   .name   = "davinci_nand",
> > +   .name   = "davinci-nand",
> > .id = 1,  
> 
> The clock lookup uses id == 0 ("davinci-nand.0"), so this is probably
> still broken unless you also change the id.
> 
> > .dev= {
> > .platform_data  = &da850_evm_nandflash_data,
> > diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
> > b/arch/arm/mach-davinci/board-dm355-evm.c
> > index e457f299cd44..58ca7f56e112 100644
> > --- a/arch/arm/mach-davinci/board-dm355-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> > @@ -98,7 +98,7 @@ static struct resource davinci_nand_resources[] = {
> >   };
> >   
> >   static struct platform_device davinci_nand_device = {
> > -   .name   = "davinci_nand",
> > +   .name   = "davinci-nand",
> > .id = 0,
> >   
> > .num_resources  = ARRAY_SIZE(davinci_nand_resources),
> > diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
> > b/arch/arm/mach-davinci/board-dm355-leopard.c
> > index be997243447b..196238117f9a 100644
> > --- a/arch/arm/mach-davinci/board-dm355-leopard.c
> > +++ b/arch/arm/mach-davinci/board-dm355-leopard.c
> > @@ -93,7 +93,7 @@ static struct resource davinci_nand_resources[] = {
> >   };
> >   
> >   static struct platform_device davinci_nand_device = {
> > -   .name   = "davinci_nand",
> > +   .name   = "davinci-nand",
> > .id = 0,
> >   
> > .num_resources  = ARRAY_SIZE(davinci_nand_resources),
> > diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
> > b/arch/arm/mach-davinci/board-dm365-evm.c
> > index e75741fb2c1d..563d66df480b 100644
> > --- a/arch/arm/mach-davinci/board-dm365-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> > @@ -159,7 +159,7 @@ static struct resource davinci_nand_resources[] = {
> >   };
> >   
> >   static struct platform_device davinci_nand_device = {
> > -   .name   = "davinci_nand",
> > +   .name   = "davinci-nand",
> > .id = 0,
> > .num_resources  = ARRAY_SIZE(davinci_nand_resources),
> > .resource   = davinci_nand_resources,
> > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
> > b/arch/arm/mach-davinci/board-dm644x-evm.c
> > index 85e6fb33b1ee..e42ae2163c75 100644
> > --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> > @@ -173,7 +173,7 @@ static struct resource davinci_evm_nandflash_resource[] 
> > = {
> >   };
> >   
> >   static struct platform_device davinci_evm_nand

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Peter Jones]

On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
> On Fri, Feb 16, 2018 at 11:18:12AM +, Ard Biesheuvel wrote:
> > On 16 February 2018 at 11:08, Borislav Petkov  wrote:
> > > On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
> > >> By your own reasoning above, that's a no-no as well.
> > >
> > > I'm sure we can come up with some emulation - the same way we did the
> > > BIOS emulation.
> > >
> > >> But thanks for your input. Anyone else got something constructive to 
> > >> contribute?
> > >
> > > The not-breaking userspace is constructive contribution. The last
> > > paragraph is my usual rant.
> > >
> > 
> > Fair enough. And I am not disagreeing with you either.
> > 
> > So question to Joe: is it well defined which variables may exhibit
> > this behavior?
> 
> For brevity's sake, "not yet." Folks-- e.g. firmware writers and
> equipment makers-- may use SMIs more (or less) than others. So, how many
> SMIs generated by the reference shell script can, and will, vary
> platform to platform. I and my colleagues are digging into this.

As a first guess: anything generated during boot is probably not an
SMI.  Everything else is probably an SMI.  In fact, I would expect that
for most systems, the entire list of things that *don't* generate an SMI
(aside from a few IBV specific variables) is all the variables in Table
10 of the UEFI spec that don't have the NV flag.

> > Given that UEFI variables are GUID scoped, would whitelisting certain
> > GUIDs (the ones userland currently relies on to be readable my
> > non-privileged users) and making everything else user-only solve this
> > problem as well?
> 
> Perhaps. I don't want us chasing white rabbits just yet, but the
> whitelist is but one approach under consideration. We may see some other
> patches or RFCs about caching and/or shadowing variable values in
> efivarfs to reduce the number of direct EFI reads, with the goal of
> reducing how many SMIs are generated.
> 
> Any obvious EFI variables that userspace tools have come to depend on--
> those which normal, unprivileged users need to read-- are helpful inputs
> to this discussion.

So, our big userland consumers are efibootmgr, fwupdate, and
"systemctl reboot --firmware-setup".  efibootmgr and fwupdate can do the
"show the current status" half of their job as a user right now, but
they rely on root for the other half anyway.  I don't think we normally
use libfwup as non-root even for reading status.  So basically, the use
case from userland that this will effect looks like:

efibootmgr -v
*scratch head*
sudo su -
efibootmgr -b  -B
efibootmgr -b  -c -L "fixed entry" ...
exit

I don't feel really bad about people having to move the third line up to
the top of that.  It's also not a use case you can have very much of: it
means you manually booted without any valid boot entries.  fallback.efi
would have created a valid boot entry if you didn't do it manually.

"systemctl reboot --firmware-setup" effectively runs as root in all
cases.

The only thing we really must ensure to preserve the other workflows
is making sure creat() and open() with 0644 doesn't return an error (it
obviously won't be preserved across a reboot), because that would break
the existing tools.  But I don't see anything in this patchset which
will cause that.

tl;dr: I think changing everything to 0600 is probably completely fine,
and whitelisting is probably pointless.  
-- 
  Peter

Re: [PATCH 1/6] nand: davinci: rename the platform driver

[David Lechner]

On 02/16/2018 01:19 PM, Boris Brezillon wrote:

On Fri, 16 Feb 2018 17:47:07 +0100
Bartosz Golaszewski  wrote:


From: Bartosz Golaszewski 

Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") broke the nand support in board file mode for
da850-based boards. Instead of reverting it and breaking the DT users
in the process (due to clock lookup), rename the driver to match the
clock table before renaming the users.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
  drivers/mtd/nand/davinci_nand.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index ccc8c43abcff..4fb143bf1872 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -865,7 +865,7 @@ static struct platform_driver nand_davinci_driver = {
.probe  = nand_davinci_probe,
.remove = nand_davinci_remove,
.driver = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",


Another side-effect of this change you should be aware of: by doing
that you also break all users that were defining partitions through the
cmdline using mtdparts=davinci_nand.0:.

Not sure this is a good idea ;-).


Also, once we move to the common clock framework, the AUXDATA that causes
the DT clock lookup breakage you are trying to avoid will go away, so that
won't be a reason for changing this either.

[PATCH 38/41] perf cpuid: Introduce a platform specific cpuid compare function

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

The function get_cpuid_str() is called by perf_pmu__getcpuid() and on
s390 returns a complete description of the CPU and its capabilities,
which is a comma separated list.

To map the CPU type with the value defined in the
pmu-events/arch/s390/mapfile.csv, introduce an architecture specific
cpuid compare function named strcmp_cpuid_str()

The currently used regex algorithm is defined as the weak default and
will be used if no platform specific one is defined. This matches the
current behavior.

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180213151419.80737-3-tmri...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/header.c | 18 +++
 tools/perf/util/header.h   |  1 +
 tools/perf/util/pmu.c  | 47 +++---
 3 files changed, 48 insertions(+), 18 deletions(-)

diff --git a/tools/perf/arch/s390/util/header.c 
b/tools/perf/arch/s390/util/header.c
index a78064c25ced..231294b80dc4 100644
--- a/tools/perf/arch/s390/util/header.c
+++ b/tools/perf/arch/s390/util/header.c
@@ -146,3 +146,21 @@ char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
zfree(&buf);
return buf;
 }
+
+/*
+ * Compare the cpuid string returned by get_cpuid() function
+ * with the name generated by the jevents file read from
+ * pmu-events/arch/s390/mapfile.csv.
+ *
+ * Parameter mapcpuid is the cpuid as stored in the
+ * pmu-events/arch/s390/mapfile.csv. This is just the type number.
+ * Parameter cpuid is the cpuid returned by function get_cpuid().
+ */
+int strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+{
+   char *cp = strchr(cpuid, ',');
+
+   if (cp == NULL)
+   return -1;
+   return strncmp(cp + 1, mapcpuid, strlen(mapcpuid));
+}
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f283a440..942bdec6d70d 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -174,4 +174,5 @@ int write_padded(struct feat_fd *fd, const void *bf,
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
+int strcmp_cpuid_str(const char *s1, const char *s2);
 #endif /* __PERF_HEADER_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 57e38fdf0b34..d5bf15ca 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -576,6 +576,34 @@ char * __weak get_cpuid_str(struct perf_pmu *pmu 
__maybe_unused)
return NULL;
 }
 
+/* Return zero when the cpuid from the mapfile.csv matches the
+ * cpuid string generated on this platform.
+ * Otherwise return non-zero.
+ */
+int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+{
+   regex_t re;
+   regmatch_t pmatch[1];
+   int match;
+
+   if (regcomp(&re, mapcpuid, REG_EXTENDED) != 0) {
+   /* Warn unable to generate match particular string. */
+   pr_info("Invalid regular expression %s\n", mapcpuid);
+   return 1;
+   }
+
+   match = !regexec(&re, cpuid, 1, pmatch, 0);
+   regfree(&re);
+   if (match) {
+   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
+
+   /* Verify the entire string matched. */
+   if (match_len == strlen(cpuid))
+   return 0;
+   }
+   return 1;
+}
+
 static char *perf_pmu__getcpuid(struct perf_pmu *pmu)
 {
char *cpuid;
@@ -610,31 +638,14 @@ struct pmu_events_map *perf_pmu__find_map(struct perf_pmu 
*pmu)
 
i = 0;
for (;;) {
-   regex_t re;
-   regmatch_t pmatch[1];
-   int match;
-
map = &pmu_events_map[i++];
if (!map->table) {
map = NULL;
break;
}
 
-   if (regcomp(&re, map->cpuid, REG_EXTENDED) != 0) {
-   /* Warn unable to generate match particular string. */
-   pr_info("Invalid regular expression %s\n", map->cpuid);
+   if (!strcmp_cpuid_str(map->cpuid, cpuid))
break;
-   }
-
-   match = !regexec(&re, cpuid, 1, pmatch, 0);
-   regfree(&re);
-   if (match) {
-   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
-
-   /* Verify the entire string matched. */
-   if (match_len == strlen(cpuid))
-   break;
-   }
}
free(cpuid);
return map;
-- 
2.14.3

[PATCH 39/41] perf test: Fix test case 23 for s390 z/VM or KVM guests

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

On s390 perf can be executed on a LPAR with support for hardware events
(i. e. cycles) or on a z/VM or KVM guest where no hardware events are
supported. In this environment use software event named cpu-clock for
this test case.

Use the cpuid infrastructure functions to determine the cpuid on s390
which contains an indication of the cpu counter facility availability.

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180213151419.80737-4-tmri...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/code-reading.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 3bf7b145b826..c7115d369511 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -482,6 +482,34 @@ static void fs_something(void)
}
 }
 
+static const char *do_determine_event(bool excl_kernel)
+{
+   const char *event = excl_kernel ? "cycles:u" : "cycles";
+
+#ifdef __s390x__
+   char cpuid[128], model[16], model_c[16], cpum_cf_v[16];
+   unsigned int family;
+   int ret, cpum_cf_a;
+
+   if (get_cpuid(cpuid, sizeof(cpuid)))
+   goto out_clocks;
+   ret = sscanf(cpuid, "%*[^,],%u,%[^,],%[^,],%[^,],%x", &family, model_c,
+model, cpum_cf_v, &cpum_cf_a);
+   if (ret != 5)/* Not available */
+   goto out_clocks;
+   if (excl_kernel && (cpum_cf_a & 4))
+   return event;
+   if (!excl_kernel && (cpum_cf_a & 2))
+   return event;
+
+   /* Fall through: missing authorization */
+out_clocks:
+   event = excl_kernel ? "cpu-clock:u" : "cpu-clock";
+
+#endif
+   return event;
+}
+
 static void do_something(void)
 {
fs_something();
@@ -592,10 +620,7 @@ static int do_test_code_reading(bool try_kcore)
 
perf_evlist__set_maps(evlist, cpus, threads);
 
-   if (excl_kernel)
-   str = "cycles:u";
-   else
-   str = "cycles";
+   str = do_determine_event(excl_kernel);
pr_debug("Parsing event '%s'\n", str);
ret = parse_events(evlist, str, NULL);
if (ret < 0) {
-- 
2.14.3

[PATCH 40/41] perf test: Fix test case inet_pton to accept inlines.

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

Using Fedora 27 and latest Linux kernel the test case
trace+probe_libc_inet_pton.sh fails again on s390.  This time is the
inlining of functions which does not match.  After an update of the
glibc (from 2.26-16 to 2.26-24) the output is different

The expected output is:

 __inet_pton (/usr/lib64/libc-2.26.so)
 gaih_inet (inlined)
 

The actual output is:

  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms
   0.000 probe_libc:inet_pton:(3ffb2140448))
 __inet_pton (inlined)
 gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
 ...

Fix this by being less strict on 'inlined' verses library name and
accept both

Signed-off-by: Thomas Richter 
Cc: Heiko Carstens 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180214070303.55757-1-tmri...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
index c446c894b297..8c4ab0b390c0 100755
--- a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
@@ -21,12 +21,12 @@ trace_libc_inet_pton_backtrace() {
expected[3]=".*packets transmitted.*"
expected[4]="rtt min.*"

expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)"
-   expected[6]=".*inet_pton[[:space:]]\($libc\)$"
+   expected[6]=".*inet_pton[[:space:]]\($libc|inlined\)$"
case "$(uname -m)" in
s390x)
eventattr='call-graph=dwarf'
-   expected[7]="gaih_inet[[:space:]]\(inlined\)$"
-   expected[8]="__GI_getaddrinfo[[:space:]]\(inlined\)$"
+   expected[7]="gaih_inet.*[[:space:]]\($libc|inlined\)$"
+   expected[8]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$"
expected[9]="main[[:space:]]\(.*/bin/ping.*\)$"
expected[10]="__libc_start_main[[:space:]]\($libc\)$"
expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$"
-- 
2.14.3

[PATCH 37/41] perf annotate: Scan cpuid for s390 and save machine type

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

Scan the cpuid string and extract the type number for later use.

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180213151419.80737-2-tmri...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/annotate/instructions.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/s390/annotate/instructions.c 
b/tools/perf/arch/s390/annotate/instructions.c
index 8c72b4cb..01df9d8303e1 100644
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -23,12 +23,37 @@ static struct ins_ops *s390__associate_ins_ops(struct arch 
*arch, const char *na
return ops;
 }
 
+static int s390__cpuid_parse(struct arch *arch, char *cpuid)
+{
+   unsigned int family;
+   char model[16], model_c[16], cpumf_v[16], cpumf_a[16];
+   int ret;
+
+   /*
+* cpuid string format:
+* 
"IBM,family,model-capacity,model[,cpum_cf-version,cpum_cf-authorization]"
+*/
+   ret = sscanf(cpuid, "%*[^,],%u,%[^,],%[^,],%[^,],%s", &family, model_c,
+model, cpumf_v, cpumf_a);
+   if (ret >= 2) {
+   arch->family = family;
+   arch->model = 0;
+   return 0;
+   }
+
+   return -1;
+}
+
 static int s390__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
 {
+   int err = 0;
+
if (!arch->initialized) {
arch->initialized = true;
arch->associate_instruction_ops = s390__associate_ins_ops;
+   if (cpuid)
+   err = s390__cpuid_parse(arch, cpuid);
}
 
-   return 0;
+   return err;
 }
-- 
2.14.3

[PATCH 41/41] perf tests shell lib: Use a wildcard to remove the vfs_getname probe

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

In some situations the vfs_getname is being added both as requested and
with a _1 suffix (inlines?):

  probe:vfs_getname_1  (on getname_flags:63@acme/git/linux/fs/namei.c with 
pathname)

This ends up making the cleanup to miss that one, as it removes just
'probe:vfs_getname', which makes the second test to use this probe point
to fail, since it finds that leftover from the first test, use a
wildcard to remove both.

Before:

  # perf test 60 61 62 63
  60: Use vfs_getname probe to get syscall args filenames   : FAILED!
  61: probe libc's inet_pton & backtrace it with ping   : Ok
  62: Check open filename arg using perf trace + vfs_getname: FAILED!
  63: Add vfs_getname probe to get syscall args filenames   : Ok

After:

  # perf test 60 61 62 63
  60: Use vfs_getname probe to get syscall args filenames   : Ok
  61: probe libc's inet_pton & backtrace it with ping   : Ok
  62: Check open filename arg using perf trace + vfs_getname: Ok
  63: Add vfs_getname probe to get syscall args filenames   : Ok
  #

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-2k5kutwr4ds36adiakyb4...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh 
b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
index 30a950c9d407..1c16e56cd93e 100644
--- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
@@ -5,7 +5,7 @@ had_vfs_getname=$?
 
 cleanup_probe_vfs_getname() {
if [ $had_vfs_getname -eq 1 ] ; then
-   perf probe -q -d probe:vfs_getname
+   perf probe -q -d probe:vfs_getname*
fi
 }
 
-- 
2.14.3

[PATCH 34/41] perf powerpc: Generate system call table from asm/unistd.h

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.

Signed-off-by: Ravi Bangoria 
Cc: Alexander Shishkin 
Cc: Hendrik Brueckner 
Cc: Jiri Olsa 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/20180129083417.31240-3-ravi.bango...@linux.vnet.ibm.com
[ Made it generate syscall_32.c as well to fix the build on 32-bit ppc ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/Makefile   | 25 +++
 .../perf/arch/powerpc/entry/syscalls/mksyscalltbl  | 37 ++
 2 files changed, 62 insertions(+)
 create mode 100755 tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl

diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 42dab7c8f508..a111239df182 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -6,3 +6,28 @@ endif
 HAVE_KVM_STAT_SUPPORT := 1
 PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
 PERF_HAVE_JITDUMP := 1
+
+#
+# Syscall table generation for perf
+#
+
+out:= $(OUTPUT)arch/powerpc/include/generated/asm
+header32 := $(out)/syscalls_32.c
+header64 := $(out)/syscalls_64.c
+sysdef := $(srctree)/tools/arch/powerpc/include/uapi/asm/unistd.h
+sysprf := $(srctree)/tools/perf/arch/powerpc/entry/syscalls/
+systbl := $(sysprf)/mksyscalltbl
+
+# Create output directory if not already present
+_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
+
+$(header64): $(sysdef) $(systbl)
+   $(Q)$(SHELL) '$(systbl)' '64' '$(CC)' $(sysdef) > $@
+
+$(header32): $(sysdef) $(systbl)
+   $(Q)$(SHELL) '$(systbl)' '32' '$(CC)' $(sysdef) > $@
+
+clean::
+   $(call QUIET_CLEAN, powerpc) $(RM) $(header32) $(header64)
+
+archheaders: $(header32) $(header64)
diff --git a/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl 
b/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
new file mode 100755
index ..ef52e1dd694b
--- /dev/null
+++ b/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
@@ -0,0 +1,37 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Generate system call table for perf. Derived from
+# s390 script.
+#
+# Copyright IBM Corp. 2017
+# Author(s):  Hendrik Brueckner 
+# Changed by: Ravi Bangoria 
+
+wordsize=$1
+gcc=$2
+input=$3
+
+if ! test -r $input; then
+   echo "Could not read input file" >&2
+   exit 1
+fi
+
+create_table()
+{
+   local wordsize=$1
+   local max_nr
+
+   echo "static const char *syscalltbl_powerpc_${wordsize}[] = {"
+   while read sc nr; do
+   printf '\t[%d] = "%s",\n' $nr $sc
+   max_nr=$nr
+   done
+   echo '};'
+   echo "#define SYSCALLTBL_POWERPC_${wordsize}_MAX_ID $max_nr"
+}
+
+$gcc -m${wordsize} -E -dM -x c  $input\
+   |sed -ne 's/^#define __NR_//p' \
+   |sort -t' ' -k2 -nu\
+   |create_table ${wordsize}
-- 
2.14.3

[PATCH 31/41] perf report: Fix wrong jump arrow

[Arnaldo Carvalho de Melo]

From: Jin Yao 

When we use perf report interactive annotate view, we can see
the position of jump arrow is not correct. For example,

1. perf record -b ...
2. perf report
3. In interactive mode, select Annotate 'function'

Percent│ IPC Cycle
   │if (flag)
  1.37 │0.4┌──   1  ↓ je 82
   │   │x += x / y + y / x;
  0.00 │0.4│  1310movsd  (%rsp),%xmm0
  0.00 │0.4│   565movsd  0x8(%rsp),%xmm4
   │0.4│  movsd  0x8(%rsp),%xmm1
   │0.4│  movsd  (%rsp),%xmm3
   │0.4│  divsd  %xmm4,%xmm0
  0.00 │0.4│   579divsd  %xmm3,%xmm1
   │0.4│  movsd  (%rsp),%xmm2
   │0.4│  addsd  %xmm1,%xmm0
   │0.4│  addsd  %xmm2,%xmm0
  0.00 │0.4│  movsd  %xmm0,(%rsp)
   │   │volatile double x = 1212121212, y = 121212;
   │   │
   │   │s_randseed = time(0);
   │   │srand(s_randseed);
   │   │
   │   │for (i = 0; i < 20; i++) {
  1.37 │0.4└─→  82:   sub$0x1,%ebx
 28.21 │0.4817  ↑ jne38

The jump arrow in above example is not correct. It should add the
width of IPC and Cycle.

With this patch, the result is:

Percent│ IPC Cycle
   │if (flag)
  1.37 │0.48 1 ┌──je 82
   │   │x += x / y + y / x;
  0.00 │0.48  1310 │  movsd  (%rsp),%xmm0
  0.00 │0.48   565 │  movsd  0x8(%rsp),%xmm4
   │0.48   │  movsd  0x8(%rsp),%xmm1
   │0.48   │  movsd  (%rsp),%xmm3
   │0.48   │  divsd  %xmm4,%xmm0
  0.00 │0.48   579 │  divsd  %xmm3,%xmm1
   │0.48   │  movsd  (%rsp),%xmm2
   │0.48   │  addsd  %xmm1,%xmm0
   │0.48   │  addsd  %xmm2,%xmm0
  0.00 │0.48   │  movsd  %xmm0,(%rsp)
   │   │volatile double x = 1212121212, y = 121212;
   │   │
   │   │s_randseed = time(0);
   │   │srand(s_randseed);
   │   │
   │   │for (i = 0; i < 20; i++) {
  1.37 │0.4882:└─→sub$0x1,%ebx
 28.21 │0.4817  ↑ jne38

Committer notes:

Please note that only from LBRv5 (according to Jiri) onwards, i.e. >=
Skylake is that we'll have the cycles counts in each branch record
entry, so to see the Cycles and IPC columns, and be able to test this
patch, one need a capable hardware.

While applying this I first tested it on a Broadwell class machine and
couldn't get those columns, will add code to the annotate browser to
warn the user about that, i.e. you have branch records, but no cycles,
use a more recent hardware to get the cycles and IPC columns.

Signed-off-by: Jin Yao 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1517223473-14750-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/annotate.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 286427975112..e2f666391ac4 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -319,6 +319,7 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
struct map_symbol *ms = ab->b.priv;
struct symbol *sym = ms->sym;
u8 pcnt_width = annotate_browser__pcnt_width(ab);
+   int width = 0;
 
/* PLT symbols contain external offsets */
if (strstr(sym->name, "@plt"))
@@ -340,13 +341,17 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
to = (u64)btarget->idx;
}
 
+   if (ab->have_cycles)
+   width = IPC_WIDTH + CYCLES_WIDTH;
+
ui_browser__set_color(browser, HE_COLORSET_JUMP_ARROWS);
-   __ui_browser__line_arrow(browser, pcnt_width + 2 + ab->addr_width,
+   __ui_browser__line_arrow(browser,
+pcnt_width + 2 + ab->addr_width + width,
 from, to);
 
if (is_fused(ab, cursor)) {
ui_browser__mark_fused(browser,
-  pcnt_width + 3 + ab->addr_width,
+  pcnt_width + 3 + ab->addr_width + width,
   from - 1,
   to > from ? true : false);
}
-- 
2.14.3

[PATCH 30/41] perf report: Fix description for --mem-mode

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

The "mem-loads" event only works when PEBS is enabled, so add the "/p"
("precise") suffix to the examples.

Signed-off-by: Andi Kleen 
Cc: Jiri Olsa 
LPU-Reference: 20180209163909.9240-1-a...@firstfloor.org
Link: https://lkml.kernel.org/n/tip-v0gcd4u9tktrvjjsp6y7o...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-report.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index a76b871f78a6..cba16d8a970e 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -368,7 +368,7 @@ OPTIONS
Use the data addresses of samples in addition to instruction addresses
to build the histograms.  To generate meaningful output, the perf.data
file must have been obtained using perf record -d -W and using a
-   special event -e cpu/mem-loads/ or -e cpu/mem-stores/. See
+   special event -e cpu/mem-loads/p or -e cpu/mem-stores/p. See
'perf mem' for simpler access.
 
 --percent-limit::
-- 
2.14.3

[PATCH 25/41] perf kmem: Document a missing option & an argument

[Arnaldo Carvalho de Melo]

From: Sangwon Hong 

First, 'perf kmem' has a '--force' option, but didn't document it on the
man page. So add it.

Second, the '--time' option has to get a value, but isn't documented on
the man page. Describe it.

Signed-off-by: Sangwon Hong 
Acked-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Taeung Song 
Link: 
http://lkml.kernel.org/r/1518381517-30766-1-git-send-email-qpa...@gmail.com
[ Add blank like after --force block, as requested by Namhyung ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-kmem.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-kmem.txt 
b/tools/perf/Documentation/perf-kmem.txt
index 479fc3261a50..85b8ac695c87 100644
--- a/tools/perf/Documentation/perf-kmem.txt
+++ b/tools/perf/Documentation/perf-kmem.txt
@@ -25,6 +25,10 @@ OPTIONS
 --input=::
Select the input file (default: perf.data unless stdin is a fifo)
 
+-f::
+--force::
+   Don't do ownership validation
+
 -v::
 --verbose::
 Be more verbose. (show symbol address, etc)
@@ -61,7 +65,7 @@ OPTIONS
default, but this option shows live (currently allocated) pages
instead.  (This option works with --page option only)
 
---time::
+--time=,::
Only analyze samples within given time window: ,. Times
have the format seconds.microseconds. If start is not given (i.e., time
string is ',x.y') then analysis starts at the beginning of the file. If
-- 
2.14.3

[PATCH 21/41] perf tools: Use target->per_thread and target->system_wide flags

[Arnaldo Carvalho de Melo]

From: Jin Yao 

Mathieu Poirier reports issue in commit ("73c0ca1eee3d perf thread_map:
Enumerate all threads from /proc") that it has negative impact on 'perf
record --per-thread'. It has the effect of creating a kernel event for
each thread in the system for 'perf record --per-thread'.

Mathieu Poirier's patch ("perf util: Do not reuse target->per_thread flag")
can fix this issue by creating a new target->all_threads flag.

This patch is based on Mathieu Poirier's patch but it doesn't use a new
target->all_threads flag. This patch just uses 'target->per_thread &&
target->system_wide' as a condition to check for all threads case.

Signed-off-by: Jin Yao 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: linux-arm-ker...@lists.infradead.org
Fixes: 73c0ca1eee3d ("perf thread_map: Enumerate all threads from /proc")
Link: 
http://lkml.kernel.org/r/1518467557-18505-3-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Mathieu Poirier 
[Fixed checkpatch warning about line over 80 characters]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 21 -
 tools/perf/util/thread_map.c |  4 ++--
 tools/perf/util/thread_map.h |  2 +-
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e5fc14e53c05..7b7d535396f7 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1086,11 +1086,30 @@ int perf_evlist__mmap(struct perf_evlist *evlist, 
unsigned int pages)
 
 int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
 {
+   bool all_threads = (target->per_thread && target->system_wide);
struct cpu_map *cpus;
struct thread_map *threads;
 
+   /*
+* If specify '-a' and '--per-thread' to perf record, perf record
+* will override '--per-thread'. target->per_thread = false and
+* target->system_wide = true.
+*
+* If specify '--per-thread' only to perf record,
+* target->per_thread = true and target->system_wide = false.
+*
+* So target->per_thread && target->system_wide is false.
+* For perf record, thread_map__new_str doesn't call
+* thread_map__new_all_cpus. That will keep perf record's
+* current behavior.
+*
+* For perf stat, it allows the case that target->per_thread and
+* target->system_wide are all true. It means to collect system-wide
+* per-thread data. thread_map__new_str will call
+* thread_map__new_all_cpus to enumerate all threads.
+*/
threads = thread_map__new_str(target->pid, target->tid, target->uid,
- target->per_thread);
+ all_threads);
 
if (!threads)
return -1;
diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index 3e1038f6491c..729dad8f412d 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -323,7 +323,7 @@ struct thread_map *thread_map__new_by_tid_str(const char 
*tid_str)
 }
 
 struct thread_map *thread_map__new_str(const char *pid, const char *tid,
-  uid_t uid, bool per_thread)
+  uid_t uid, bool all_threads)
 {
if (pid)
return thread_map__new_by_pid_str(pid);
@@ -331,7 +331,7 @@ struct thread_map *thread_map__new_str(const char *pid, 
const char *tid,
if (!tid && uid != UINT_MAX)
return thread_map__new_by_uid(uid);
 
-   if (per_thread)
+   if (all_threads)
return thread_map__new_all_cpus();
 
return thread_map__new_by_tid_str(tid);
diff --git a/tools/perf/util/thread_map.h b/tools/perf/util/thread_map.h
index 0a806b99e73c..5ec91cfd1869 100644
--- a/tools/perf/util/thread_map.h
+++ b/tools/perf/util/thread_map.h
@@ -31,7 +31,7 @@ struct thread_map *thread_map__get(struct thread_map *map);
 void thread_map__put(struct thread_map *map);
 
 struct thread_map *thread_map__new_str(const char *pid,
-   const char *tid, uid_t uid, bool per_thread);
+   const char *tid, uid_t uid, bool all_threads);
 
 struct thread_map *thread_map__new_by_tid_str(const char *tid_str);
 
-- 
2.14.3

[PATCH 23/41] perf cs-etm: Properly deal with cpu maps

[Arnaldo Carvalho de Melo]

From: Mathieu Poirier 

This patch allows the CoreSight AUX info section to fit topologies where
only a subset of all available CPUs are present, avoiding at the same
time accessing the ETM configuration areas of CPUs that have been
offlined.

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1518478737-24649-1-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/arm/util/cs-etm.c | 51 +++
 1 file changed, 36 insertions(+), 15 deletions(-)

diff --git a/tools/perf/arch/arm/util/cs-etm.c 
b/tools/perf/arch/arm/util/cs-etm.c
index fbfc055d3f4d..5c655ad4621e 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -298,12 +298,17 @@ cs_etm_info_priv_size(struct auxtrace_record *itr 
__maybe_unused,
 {
int i;
int etmv3 = 0, etmv4 = 0;
-   const struct cpu_map *cpus = evlist->cpus;
+   struct cpu_map *event_cpus = evlist->cpus;
+   struct cpu_map *online_cpus = cpu_map__new(NULL);
 
/* cpu map is not empty, we have specific CPUs to work with */
-   if (!cpu_map__empty(cpus)) {
-   for (i = 0; i < cpu_map__nr(cpus); i++) {
-   if (cs_etm_is_etmv4(itr, cpus->map[i]))
+   if (!cpu_map__empty(event_cpus)) {
+   for (i = 0; i < cpu__max_cpu(); i++) {
+   if (!cpu_map__has(event_cpus, i) ||
+   !cpu_map__has(online_cpus, i))
+   continue;
+
+   if (cs_etm_is_etmv4(itr, i))
etmv4++;
else
etmv3++;
@@ -311,6 +316,9 @@ cs_etm_info_priv_size(struct auxtrace_record *itr 
__maybe_unused,
} else {
/* get configuration for all CPUs in the system */
for (i = 0; i < cpu__max_cpu(); i++) {
+   if (!cpu_map__has(online_cpus, i))
+   continue;
+
if (cs_etm_is_etmv4(itr, i))
etmv4++;
else
@@ -318,6 +326,8 @@ cs_etm_info_priv_size(struct auxtrace_record *itr 
__maybe_unused,
}
}
 
+   cpu_map__put(online_cpus);
+
return (CS_ETM_HEADER_SIZE +
   (etmv4 * CS_ETMV4_PRIV_SIZE) +
   (etmv3 * CS_ETMV3_PRIV_SIZE));
@@ -447,7 +457,9 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
int i;
u32 offset;
u64 nr_cpu, type;
-   const struct cpu_map *cpus = session->evlist->cpus;
+   struct cpu_map *cpu_map;
+   struct cpu_map *event_cpus = session->evlist->cpus;
+   struct cpu_map *online_cpus = cpu_map__new(NULL);
struct cs_etm_recording *ptr =
container_of(itr, struct cs_etm_recording, itr);
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
@@ -458,8 +470,21 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
if (!session->evlist->nr_mmaps)
return -EINVAL;
 
-   /* If the cpu_map is empty all CPUs are involved */
-   nr_cpu = cpu_map__empty(cpus) ? cpu__max_cpu() : cpu_map__nr(cpus);
+   /* If the cpu_map is empty all online CPUs are involved */
+   if (cpu_map__empty(event_cpus)) {
+   cpu_map = online_cpus;
+   } else {
+   /* Make sure all specified CPUs are online */
+   for (i = 0; i < cpu_map__nr(event_cpus); i++) {
+   if (cpu_map__has(event_cpus, i) &&
+   !cpu_map__has(online_cpus, i))
+   return -EINVAL;
+   }
+
+   cpu_map = event_cpus;
+   }
+
+   nr_cpu = cpu_map__nr(cpu_map);
/* Get PMU type as dynamically assigned by the core */
type = cs_etm_pmu->type;
 
@@ -472,15 +497,11 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
 
offset = CS_ETM_SNAPSHOT + 1;
 
-   /* cpu map is not empty, we have specific CPUs to work with */
-   if (!cpu_map__empty(cpus)) {
-   for (i = 0; i < cpu_map__nr(cpus) && offset < priv_size; i++)
-   cs_etm_get_metadata(cpus->map[i], &offset, itr, info);
-   } else {
-   /* get configuration for all CPUs in the system */
-   for (i = 0; i < cpu__max_cpu(); i++)
+   for (i = 0; i < cpu__max_cpu() && offset < priv_size; i++)
+   if (cpu_map__has(cpu_map, i))
cs_etm_get_metadata(i, &offset, itr, info);
-   }
+
+   cpu_map__put(online_cpus);
 
return 0;
 }
-- 
2.14.3

[PATCH 18/41] perf tools: Do not create kernel maps in sample__resolve()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no need for kernel maps to be allocated at this point - sample
processing.

We search for kernel maps using the kernel map_groups in machine::kmaps
which is static. If vmlinux maps for any reason still don't exist, the
search correctly fails because they are not in the map group.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-9-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 4644e751a3e3..f0a6cbd033cc 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1588,17 +1588,6 @@ int machine__resolve(struct machine *machine, struct 
addr_location *al,
return -1;
 
dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread), 
thread->tid);
-   /*
-* Have we already created the kernel maps for this machine?
-*
-* This should have happened earlier, when we processed the kernel MMAP
-* events, but for older perf.data files there was no such thing, so do
-* it now.
-*/
-   if (sample->cpumode == PERF_RECORD_MISC_KERNEL &&
-   machine__kernel_map(machine) == NULL)
-   machine__create_kernel_maps(machine);
-
thread__find_addr_map(thread, sample->cpumode, MAP__FUNCTION, 
sample->ip, al);
dump_printf(" .. dso: %s\n",
al->map ? al->map->dso->long_name :
-- 
2.14.3

[PATCH 10/41] perf stat: Add support to print counts after a period of time

[Arnaldo Carvalho de Melo]

From: yuzhoujian 

Introduce a new option to print counts after N milliseconds and update
'perf stat' documentation accordingly.

Show below is the output of the new option for perf stat.

  $ perf stat --time 2000 -e cycles -a
  Performance counter stats for 'system wide':

157,260,423  cycles

2.003060766 seconds time elapsed

We can print the count deltas after N milliseconds with this new
introduced option. This option is not supported with "-I" option.

In addition, according to Kangliang's patch(19afd10410957), the
monitoring overhead for system-wide core event could be very high if the
interval-print parameter was below 100ms, and the limitation value is
10ms.

So the same warning will be displayed when the time is set between 10ms
to 100ms, and the minimal time is limited to 10ms. Users can make a
decision according to their spcific cases.

Committer notes:

This actually stops the workload after the specified time, then prints
the counts.

So I renamed the option to --timeout and updated the documentation to
state that it will not just print the counts after the specified time,
but will really stop the 'perf stat' session and print the counts.

The rename from 'time' to 'timeout' also fixes the build in systems
where 'time' is used by glibc and can't be used as a name of a variable,
such as centos:5 and centos:6.

Changes since v3:
- none.

Changes since v2:
- modify the time check in __run_perf_stat func to keep some consistency
  with the workload case.
- add the warning when the time is set between 10ms to 100ms.
- add the pr_err when the time is set below 10ms.

Changes since v1:
- none.

Signed-off-by: yuzhoujian 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Kan Liang 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1517217923-8302-3-git-send-email-ufo19890...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-stat.txt |  5 +
 tools/perf/builtin-stat.c  | 33 +++--
 tools/perf/util/stat.h |  1 +
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index 47a21645f60c..2bbe79a50d3c 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -151,6 +151,11 @@ Print count deltas for fixed number of times.
 This option should be used together with "-I" option.
example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
 
+--timeout msecs::
+Stop the 'perf stat' session and print count deltas after N milliseconds 
(minimum: 10 ms).
+This option is not supported with the "-I" option.
+   example: 'perf stat --time 2000 -e cycles -a'
+
 --metric-only::
 Only print computed metrics. Print them in a single line.
 Don't show any raw values. Not supported with --per-thread.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7d1d7613bf56..2d49eccf98f2 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -573,6 +573,7 @@ static int __run_perf_stat(int argc, const char **argv)
 {
int interval = stat_config.interval;
int times = stat_config.times;
+   int timeout = stat_config.timeout;
char msg[BUFSIZ];
unsigned long long t0, t1;
struct perf_evsel *counter;
@@ -586,6 +587,9 @@ static int __run_perf_stat(int argc, const char **argv)
if (interval) {
ts.tv_sec  = interval / USEC_PER_MSEC;
ts.tv_nsec = (interval % USEC_PER_MSEC) * NSEC_PER_MSEC;
+   } else if (timeout) {
+   ts.tv_sec  = timeout / USEC_PER_MSEC;
+   ts.tv_nsec = (timeout % USEC_PER_MSEC) * NSEC_PER_MSEC;
} else {
ts.tv_sec  = 1;
ts.tv_nsec = 0;
@@ -698,9 +702,11 @@ static int __run_perf_stat(int argc, const char **argv)
perf_evlist__start_workload(evsel_list);
enable_counters();
 
-   if (interval) {
+   if (interval || timeout) {
while (!waitpid(child_pid, &status, WNOHANG)) {
nanosleep(&ts, NULL);
+   if (timeout)
+   break;
process_interval();
if (interval_count && !(--times))
break;
@@ -720,6 +726,8 @@ static int __run_perf_stat(int argc, const char **argv)
enable_counters();
while (!done) {
nanosleep(&ts, NULL);
+   if (timeout)
+   break;
if (interval) {
process_interval();
if (interval_count && !(--times))
@@ -1900,6 +1908,8 @@ static co

[PATCH 14/41] perf machine: Move kernel mmap name into struct machine

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

It simplifies and centralizes the code. The kernel mmap name is set for
machine type, which we know from the beginning, so there's no reason to
generate it every time we need it.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180215122635.24029-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/build-id.c | 10 +++
 tools/perf/util/event.c|  5 +---
 tools/perf/util/machine.c  | 67 +++---
 tools/perf/util/machine.h  |  3 +--
 tools/perf/util/symbol.c   |  3 +--
 5 files changed, 39 insertions(+), 49 deletions(-)

diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 7f8553630c4d..537eadd81914 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -316,7 +316,6 @@ static int machine__write_buildid_table(struct machine 
*machine,
struct feat_fd *fd)
 {
int err = 0;
-   char nm[PATH_MAX];
struct dso *pos;
u16 kmisc = PERF_RECORD_MISC_KERNEL,
umisc = PERF_RECORD_MISC_USER;
@@ -338,9 +337,8 @@ static int machine__write_buildid_table(struct machine 
*machine,
name = pos->short_name;
name_len = pos->short_name_len;
} else if (dso__is_kcore(pos)) {
-   machine__mmap_name(machine, nm, sizeof(nm));
-   name = nm;
-   name_len = strlen(nm);
+   name = machine->mmap_name;
+   name_len = strlen(name);
} else {
name = pos->long_name;
name_len = pos->long_name_len;
@@ -813,12 +811,10 @@ static int dso__cache_build_id(struct dso *dso, struct 
machine *machine)
bool is_kallsyms = dso__is_kallsyms(dso);
bool is_vdso = dso__is_vdso(dso);
const char *name = dso->long_name;
-   char nm[PATH_MAX];
 
if (dso__is_kcore(dso)) {
is_kallsyms = true;
-   machine__mmap_name(machine, nm, sizeof(nm));
-   name = nm;
+   name = machine->mmap_name;
}
return build_id_cache__add_b(dso->build_id, sizeof(dso->build_id), name,
 dso->nsinfo, is_kallsyms, is_vdso);
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 44e603c27944..4644e751a3e3 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -894,8 +894,6 @@ int perf_event__synthesize_kernel_mmap(struct perf_tool 
*tool,
   struct machine *machine)
 {
size_t size;
-   const char *mmap_name;
-   char name_buff[PATH_MAX];
struct map *map = machine__kernel_map(machine);
struct kmap *kmap;
int err;
@@ -918,7 +916,6 @@ int perf_event__synthesize_kernel_mmap(struct perf_tool 
*tool,
return -1;
}
 
-   mmap_name = machine__mmap_name(machine, name_buff, sizeof(name_buff));
if (machine__is_host(machine)) {
/*
 * kernel uses PERF_RECORD_MISC_USER for user space maps,
@@ -931,7 +928,7 @@ int perf_event__synthesize_kernel_mmap(struct perf_tool 
*tool,
 
kmap = map__kmap(map);
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
-   "%s%s", mmap_name, kmap->ref_reloc_sym->name) + 1;
+   "%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) 
+ 1;
size = PERF_ALIGN(size, sizeof(u64));
event->mmap.header.type = PERF_RECORD_MMAP;
event->mmap.header.size = (sizeof(event->mmap) -
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index c976384f9022..b1f1961b13f4 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -48,6 +48,27 @@ static void machine__threads_init(struct machine *machine)
}
 }
 
+static int machine__set_mmap_name(struct machine *machine)
+{
+   if (machine__is_host(machine)) {
+   if (symbol_conf.vmlinux_name)
+   machine->mmap_name = strdup(symbol_conf.vmlinux_name);
+   else
+   machine->mmap_name = strdup("[kernel.kallsyms]");
+   } else if (machine__is_default_guest(machine)) {
+   if (symbol_conf.default_guest_vmlinux_name)
+   machine->mmap_name = 
strdup(symbol_conf.default_guest_vmlinux_name);
+   else
+   machine->mmap_name = strdup("[guest.kernel.kallsyms]");
+   } else {
+   if (asprintf(&machine->mmap_name, "[guest.kernel.kallsyms.%d]",
+machine->pid) < 0)
+   machine->mmap_name = NULL;
+   }
+
+   return machine->mmap_name ? 0 : -ENOMEM;
+}
+
 int machine__init(struct machine *machine, const char *root_dir,

[PATCH 05/41] perf tests: Fix dwarf unwind for stripped binaries

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

When we strip the perf binary, dwarf unwind test stop
to work. The reason is that strip will remove static
function symbols, which we need to check for unwind.

This change will keep this test working in cases where
the global symbols are put into dynamic symbol table,
which is the case on x86. It still won't work on powerpc.

Making those 5 local functions global, and adding
'test_dwarf_unwind__' to their names.

Committer testing:

Before:

  # perf test dwarf
  58: DWARF unwind   : Ok
  # strip ~/bin/perf
  # perf test dwarf
  58: DWARF unwind   : FAILED!
  # perf test -v dwarf
  58: DWARF unwind   :
  --- start ---
  test child forked, pid 6590
  unwind: thread map already set, dso=/home/acme/bin/perf
  
  unwind: access_mem addr 0x7ffce6c48098 val 48563f, offset 1144
  unwind: test__dwarf_unwind:ip = 0x4a54e5 (0xa54e5)
  got: test__dwarf_unwind 0xa54e5, expecting test__dwarf_unwind
  unwind: '':ip = 0x4a50bb (0xa50bb)
  failed: got unresolved address 0xa50bb
  unwind failed
  test child finished with -1
   end 
  DWARF unwind: FAILED!
  #

After:

  # perf test dwarf
  58: DWARF unwind   : Ok
  # strip ~/bin/perf
  # perf test dwarf
  58: DWARF unwind   : Ok
  #
  # perf test -v dwarf
  58: DWARF unwind   :
  --- start ---
  test child forked, pid 7219
  unwind: thread map already set, dso=/home/acme/bin/perf
  
  unwind: access_mem addr 0x7fff007da2c8 val 48575f, offset 1144
  unwind: test__arch_unwind_sample:ip = 0x589044 (0x189044)
  got: test__arch_unwind_sample 0x189044, expecting test__arch_unwind_sample
  unwind: test_dwarf_unwind__thread:ip = 0x4a52f7 (0xa52f7)
  got: test_dwarf_unwind__thread 0xa52f7, expecting test_dwarf_unwind__thread
  unwind: test_dwarf_unwind__compare:ip = 0x4a5468 (0xa5468)
  got: test_dwarf_unwind__compare 0xa5468, expecting test_dwarf_unwind__compare
  unwind: bsearch:ip = 0x7f6608ae94d8 (0x394d8)
  got: bsearch 0x394d8, expecting bsearch
  unwind: test_dwarf_unwind__krava_3:ip = 0x4a54d1 (0xa54d1)
  got: test_dwarf_unwind__krava_3 0xa54d1, expecting test_dwarf_unwind__krava_3
  unwind: test_dwarf_unwind__krava_2:ip = 0x4a550b (0xa550b)
  got: test_dwarf_unwind__krava_2 0xa550b, expecting test_dwarf_unwind__krava_2
  unwind: test_dwarf_unwind__krava_1:ip = 0x4a554b (0xa554b)
  got: test_dwarf_unwind__krava_1 0xa554b, expecting test_dwarf_unwind__krava_1
  unwind: test__dwarf_unwind:ip = 0x4a5605 (0xa5605)
  got: test__dwarf_unwind 0xa5605, expecting test__dwarf_unwind
  test child finished with 0
   end 
  DWARF unwind: Ok
  #

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180206181813.10943-17-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/dwarf-unwind.c | 46 +++--
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 260418969120..2f008067d989 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -37,6 +37,19 @@ static int init_live_machine(struct machine *machine)
  mmap_handler, machine, true, 
500);
 }
 
+/*
+ * We need to keep these functions global, despite the
+ * fact that they are used only locally in this object,
+ * in order to keep them around even if the binary is
+ * stripped. If they are gone, the unwind check for
+ * symbol fails.
+ */
+int test_dwarf_unwind__thread(struct thread *thread);
+int test_dwarf_unwind__compare(void *p1, void *p2);
+int test_dwarf_unwind__krava_3(struct thread *thread);
+int test_dwarf_unwind__krava_2(struct thread *thread);
+int test_dwarf_unwind__krava_1(struct thread *thread);
+
 #define MAX_STACK 8
 
 static int unwind_entry(struct unwind_entry *entry, void *arg)
@@ -45,12 +58,12 @@ static int unwind_entry(struct unwind_entry *entry, void 
*arg)
char *symbol = entry->sym ? entry->sym->name : NULL;
static const char *funcs[MAX_STACK] = {
"test__arch_unwind_sample",
-   "unwind_thread",
-   "compare",
+   "test_dwarf_unwind__thread",
+   "test_dwarf_unwind__compare",
"bsearch",
-   "krava_3",
-   "krava_2",
-   "krava_1",
+   "test_dwarf_unwind__krava_3",
+   "test_dwarf_unwind__krava_2",
+   "test_dwarf_unwind__krava_1",
"test__dwarf_unwind"
};
/*
@@ -77,7 +90,7 @@ static int unwind_entry(struct unwind_entry *entry, void *arg)
return strcmp((const char *) symbol, funcs[idx]);
 }
 
-static noinline int unwind_thread(struct thread *thread)
+noinline int test_dwarf_unw

[PATCH 08/41] perf report: Add support to display group output for non group events

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add support to display group output for if non grouped events are
detected and user forces --group option. Now for non-group events
recorded like:

  $ perf record -e 'cycles,instructions' ls

you can still get group output by using --group option
in report:

  $ perf report --group --stdio
  ...
  # Overhead  Command  Shared Object Symbol
  #   ...    ..
  #
  17.67%   0.00%  ls   libc-2.25.so  [.] _IO_do_write@@GLIB
  15.59%  25.94%  ls   ls[.] calculate_columns
  15.41%  31.35%  ls   libc-2.25.so  [.] __strcoll_l
  ...

Committer note:

We should improve on this by making sure that the first line states that
this is not a group, but since the user doesn't have to force group view
when really using grouped events (e.g. '{cycles,instructions}'), the
user better know what is being done...

Requested-by: Stephane Eranian 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Tested-by: Stephane Eranian 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180209092734.GB20449@krava
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-report.txt | 3 ++-
 tools/perf/builtin-report.c  | 6 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 907e505b6309..a76b871f78a6 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -354,7 +354,8 @@ OPTIONS
 Path to objdump binary.
 
 --group::
-   Show event group information together.
+   Show event group information together. It forces group output also
+   if there are no groups defined in data file.
 
 --demangle::
Demangle symbol names to human readable form. It's enabled by default,
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 8ef71669e7a0..1eedb1815c4c 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -938,6 +938,7 @@ int cmd_report(int argc, const char **argv)
"perf report []",
NULL
};
+   bool group_set = false;
struct report report = {
.tool = {
.sample  = process_sample_event,
@@ -1057,7 +1058,7 @@ int cmd_report(int argc, const char **argv)
   "Specify disassembler style (e.g. -M intel for intel 
syntax)"),
OPT_BOOLEAN(0, "show-total-period", &symbol_conf.show_total_period,
"Show a column with the sum of periods"),
-   OPT_BOOLEAN(0, "group", &symbol_conf.event_group,
+   OPT_BOOLEAN_SET(0, "group", &symbol_conf.event_group, &group_set,
"Show event group information together"),
OPT_CALLBACK_NOOPT('b', "branch-stack", &branch_mode, "",
"use branch records for per branch histogram filling",
@@ -1174,6 +1175,9 @@ int cmd_report(int argc, const char **argv)
has_br_stack = perf_header__has_feat(&session->header,
 HEADER_BRANCH_STACK);
 
+   if (group_set && !session->evlist->nr_groups)
+   perf_evlist__set_leader(session->evlist);
+
if (itrace_synth_opts.last_branch)
has_br_stack = true;
 
-- 
2.14.3

[GIT PULL 00/41] perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling, this is on top of tip/perf/urgent.

- Arnaldo

Test results at the end of this message, as usual.

The following changes since commit 297f9233b53a08fd457815e19f1d6f2c3389857b:

  kprobes: Propagate error from disarm_kprobe_ftrace() (2018-02-16 09:12:58 
+0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-core-for-mingo-4.17-20180216

for you to fetch changes up to 21316ac6803d4a1aadd74b896db8d60a92cd1140:

  perf tests shell lib: Use a wildcard to remove the vfs_getname probe 
(2018-02-16 15:31:12 -0300)


perf/core improvements and fixes:

- Fix wrong jump arrow in systems with branch records with cycles,
  i.e. Intel's >= Skylake (Jin Yao)

- Fix 'perf record --per-thread' problem introduced when
  implementing 'perf stat --per-thread (Jin Yao)

- Use arch__compare_symbol_names() to fix 'perf test vmlinux',
  that was using strcmp(symbol names) while the dso routines
  doing symbol lookups used the arch overridable one, making
  this test fail in architectures that overrided that function
  with something other than strcmp() (Jiri Olsa)

- Add 'perf script --show-round-event' to display
  PERF_RECORD_FINISHED_ROUND entries (Jiri Olsa)

- Fix dwarf unwind for stripped binaries in 'perf test' (Jiri Olsa)

- Use ordered_events for 'perf report --tasks', otherwise we may get
  artifacts when PERF_RECORD_FORK gets processed before PERF_RECORD_COMM
  (when they got recorded in different CPUs) (Jiri Olsa)

- Add support to display group output for non group events, i.e.
  now when one uses 'perf report --group' on a perf.data file
  recorded without explicitly grouping events with {} (e.g.
  "perf record -e '{cycles,instructions}'" get the same output
  that would produce, i.e. see all those non-grouped events in
  multiple columns, at the same time (Jiri Olsa)

- Skip non-address kallsyms entries, e.g. '(null)' for !root (Jiri Olsa)

- Kernel maps fixes wrt perf.data(report) versus live system (top)
  (Jiri Olsa)

- Fix memory corruption when using 'perf record -j call -g -a '
  followed by 'perf report --branch-history' (Jiri Olsa)

- ARM CoreSight fixes (Mathieu Poirier)

- Add inject capability for CoreSight Traces (Robert Waker)

- Update documentation for use of 'perf' + ARM CoreSight (Robert Walker)

- Man pages fixes (Sangwon Hong, Jaecheol Shin)

- Fix some 'perf test' cases on s/390 and x86_64 (some backtraces
  changed with a glibc update) (Thomas Richter)

- Add detailed CPUID info in the 'perf.data' headers for s/390 to
  then use it in 'perf annotate' (Thomas Richter)

- Add '--interval-count N' to 'perf stat', to use with -I, i.e.
  'perf stat -I 1000 --interval-count 2' will show stats every
   1000ms, two times (yuzhoujian)

- Add 'perf stat --timeout Nms', that will run for that many
  milliseconds and then stop, printing the counters (yuzhoujian)

- Fix description for 'perf report --mem-modex (Andi Kleen)

- Use a wildcard to remove the vfs_getname probe in the
  'perf test' shell based test cases (Arnaldo Carvalho de Melo)

Signed-off-by: Arnaldo Carvalho de Melo 


Andi Kleen (1):
  perf report: Fix description for --mem-mode

Arnaldo Carvalho de Melo (1):
  perf tests shell lib: Use a wildcard to remove the vfs_getname probe

Jaecheol Shin (1):
  perf annotate: Add missing arguments in Man page

Jin Yao (2):
  perf tools: Use target->per_thread and target->system_wide flags
  perf report: Fix wrong jump arrow

Jiri Olsa (18):
  perf record: Put new line after target override warning
  perf script: Add --show-round-event to display PERF_RECORD_FINISHED_ROUND
  tools lib api fs: Add filename__read_xll function
  tools lib api fs: Add sysfs__read_xll function
  perf tests: Fix dwarf unwind for stripped binaries
  perf tools: Fix comment for sort__* compare functions
  perf report: Ask for ordered events for --tasks option
  perf report: Add support to display group output for non group events
  tools lib symbol: Skip non-address kallsyms line
  perf symbols: Check if we read regular file in dso__load()
  perf machine: Free root_dir in machine__init() error path
  perf machine: Move kernel mmap name into struct machine
  perf machine: Generalize machine__set_kernel_mmap()
  perf machine: Don't search for active kernel start in 
__machine__create_kernel_maps
  perf machine: Remove machine__load_kallsyms()
  perf tools: Do not create kernel maps in sample__resolve()
  perf tests: Use arch__compare_symbol_names to compare symbols
  perf re

Re: [PATCH 11/23] kconfig: add 'shell-stdout' function

[Linus Torvalds]

On Fri, Feb 16, 2018 at 10:38 AM, Masahiro Yamada
 wrote:
> This is the second built-in function, which retrieves the first line
> of stdout from the given shell command.

This is the only part I really don't much like in your patch series.

Most of it is just lovely and looks very nice and powerful, but the
difference between "$(shell ..." and "$(shell-stdout ..." to me is
bvery ugly.

Can we *please* make "shell-stdout" go away, and make this just be "shell"?

The rule would be very simple:

 - if the result of the shell command is a failure, the result is 'n'

 - otherwise, the result is the first line of stdout

 - if the result is empty, we replace it with 'y'.

So doing $(shell true) would be 100% equivalent to $(shell echo y),
and you could still do that

  default $(shell $CC --version | grep -q gcc)

because it would just automatically do the right thing.

Basically, the only difference is how $(shell ) works in the success
case: the result won't necessarily be 'y', it will be whatever output.
But if you want to always turn it into 'y' (say, you don't have a "-q"
flag for the grep equivalent above), you can always do so with

  default $(shell $CC --version | noqgrep gcc > /dev/null)

So it seems to me that there is never any fundamental reason why we'd
want both "shell" and "shell-stdout", since "shell-stdout" is
fundamentally more powerful than "shell", and can always be used as
such (and just renamed to "shell").

Because I really think that it's just much prettier and more intuitive
to be able to say

default "/boot/config-$(shell uname --release)"

without that "-stdout" thing.

Hmm?

But I do want to say how much I liked this series. Just this part
seemed to result in uglier Kconfig scripts.

 Linus

Re: [PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

[Eric W. Biederman]

Ingo Molnar  writes:

> * Baoquan He  wrote:
>
>> This is v5 post. Newly added patch 0002 includes the change
>> related to KEXEC_JUMP path. Patch 0003 only includes the
>> regression fix.
>> 
>> A regression bug was introduced in below commit.
>> commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the 
>> local APIC")
>> 
>> It caused the action to fail that we try to restore boot irq mode
>> in reboot and kexec/kdump. Details can be seen in patch 0003.
>> 
>> Warning can always be seen during kdump kernel boot on qemu/kvm
>> platform. Our customer even saw casual kdump kernel hang once in
>> ~30 attempts during stress testing of kdump on KVM machine.
>> 
>> v4->v5:
>>   Take out the change related to KEXEC_JUMP to a new patch 0002
>>   according to Eric's suggestion.
>>   Patch 0003 in this series only includes the regression fix.
>> 
>> v3->v4:
>>   Eric pointed out that in patch 0002 the change related to
>>   KEXEC_JUMP is not right.
>>   Correct it.
>> 
>>   Add Fixes tag and Cc to stable.
>
> Eric, are these patches looking good to you now?

The result of applying the patches looks good.
Barring whatever fix to header files that kbuild seems to find necessary.

I wish patches 1 2 and 4 were all the same patch.  That I think would
make reading the patches a bit easier, and make the backports clearer.
But at this point that is just me bike-shedding.

Reviewed-by: "Eric W. Biederman" 

Eric

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

[David Woodhouse]

On Fri, 2018-02-16 at 10:44 -0800, Tim Chen wrote:
> 
> I encountered hang on a machine but not others when using the above
> macro.  It is probably an alignment thing with ALTERNATIVE as the
> problem went
> away after I made the change below:
> 
> Tim
> 
> diff --git a/arch/x86/include/asm/nospec-branch.h
> b/arch/x86/include/asm/nospec-branch.h
> index 8f2ff74..0f65bd2 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -148,6 +148,7 @@ extern char __indirect_thunk_end[];
>  
>  #define alternative_msr_write(_msr, _val, _feature)    \
>     asm volatile(ALTERNATIVE("",    \
> +   ".align 16\n\t"    \
>     "movl %[msr], %%ecx\n\t"   \
>     "movl %[val], %%eax\n\t"   \
>     "movl $0, %%edx\n\t"   \

That's weird. Note that .align in an altinstr section isn't actually
going to do what you'd expect; the oldinstr and altinstr sections
aren't necessarily aligned the same, so however many NOPs it inserts
into the alternative, might be deliberately *misaligning* it in the
code that actually gets executed.

Are you sure you're not running a kernel where the alternatives code
would turn that alternative which *starts* with a NOP, into *all* NOPs?

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v9 2/3] arm: dts: add Nuvoton NPCM750 device tree

[Brendan Higgins]

>>Arnd, do we have this documented somewhere for new maintainers to
>>follow?
>
> I would add a few things that we had to go through before for Broadcom SoCs:
>
> - send your pull requests to a...@kernel.org and copy Arnd, Olof and Kevin
>
> - you would want to get your PGP key signed by as many people as people as 
> possible which should not be a problem if you are in an area with lots of 
> kernel people like the Bay Area (which reminds me I should do that)
>
> - if you are going to be reasonably active every cycle consider getting a 
> kernel.org account to host your tree (we are still not doing that...)
>
> - for future pull requests, you might want to break them into e.g: DTS, 
> board/Kconfig, drivers, defconfig, maintainers file, and have as little 
> dependencies between each branch to minimize merge conflicts
>
> - build test and run test your changes against at least one other platform, 
> e.g: QEMU to check for multiplatform issues
>
> In case this is of any value, there is a script here that will automatically 
> generate pull requests emails for you based on branches matching what was 
> mentioned above, it will also take care of CC'ing the people involved in the 
> different patches:
>
> https://github.com/ffainelli/misc-scripts/blob/master/gen-pull.pl
>
> It still requires you to create an appropriate tag for the pull requests, 
> though I might semi-automate that in the future, at least spawn an editor and 
> offer some guidance, based on commit messages as to what should be in the 
> pull request email/tag.
>
> HTH
>
> --
> Florian

Thanks Florian, this was extremely helpful!

Re: [PATCH 2/6] ARM: davinci: update the nand driver names

[David Lechner]

On 02/16/2018 10:47 AM, Bartosz Golaszewski wrote:

From: Bartosz Golaszewski 

Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") we can no longer correctly lookup the nand clock when
booting in legacy mode. Said commit added a dev_id to the nand clock
which must match and it doesn't correspond with the device name which
is "davinci_nand" instead of "davinci-nand".

The driver name has been changed. Update the board files.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
  arch/arm/mach-davinci/board-da830-evm.c | 2 +-
  arch/arm/mach-davinci/board-da850-evm.c | 2 +-
  arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
  arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
  arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
  arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
  arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
  arch/arm/mach-davinci/board-mityomapl138.c  | 2 +-
  arch/arm/mach-davinci/board-neuros-osd2.c   | 2 +-
  arch/arm/mach-davinci/board-sffsdr.c| 2 +-
  10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index f673cd7a6766..f8838c7b174b 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -348,7 +348,7 @@ static struct resource da830_evm_nand_resources[] = {
  };
  
  static struct platform_device da830_evm_nand_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,
.dev= {
.platform_data  = &da830_evm_nand_pdata,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d898a94f6eae..828194045a2b 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -266,7 +266,7 @@ static struct resource da850_evm_nandflash_resource[] = {
  };
  
  static struct platform_device da850_evm_nandflash_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,


The clock lookup uses id == 0 ("davinci-nand.0"), so this is probably
still broken unless you also change the id.


.dev= {
.platform_data  = &da850_evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index e457f299cd44..58ca7f56e112 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -98,7 +98,7 @@ static struct resource davinci_nand_resources[] = {
  };
  
  static struct platform_device davinci_nand_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
  
  	.num_resources		= ARRAY_SIZE(davinci_nand_resources),

diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
b/arch/arm/mach-davinci/board-dm355-leopard.c
index be997243447b..196238117f9a 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -93,7 +93,7 @@ static struct resource davinci_nand_resources[] = {
  };
  
  static struct platform_device davinci_nand_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
  
  	.num_resources		= ARRAY_SIZE(davinci_nand_resources),

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index e75741fb2c1d..563d66df480b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -159,7 +159,7 @@ static struct resource davinci_nand_resources[] = {
  };
  
  static struct platform_device davinci_nand_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
.resource   = davinci_nand_resources,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 85e6fb33b1ee..e42ae2163c75 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -173,7 +173,7 @@ static struct resource davinci_evm_nandflash_resource[] = {
  };
  
  static struct platform_device davinci_evm_nandflash_device = {

-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.dev= {
.platform_data  = &davinci_evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index cb0a41e83582..614dd211e6fc 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/m

[PATCH] pinctrl/amd: add get_direction handler

[Daniel Kurtz]

On boot, gpiochip_add_data() initializes the FLAG_IS_OUT bit in
desc->flags iff its gpio_chip does not have ->direction_input() handler,
else it is initialized to 0, which implies the GPIO is an "input".

Later, the sysfs "direction" handler will use gpiod_get_direction() to
get the current direction, but if no ->get_direction() handler is
installed, the result will just be the current (initial) value of flags,
which will always be OUT irregardless of the initial register value.

Add a get_direction() handler to pinctrl-amd to fix this and always
provide the correct value for direction.

Signed-off-by: Daniel Kurtz 
---
 drivers/pinctrl/pinctrl-amd.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 61d830c2bc17..281b700fe7e9 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -40,6 +40,19 @@
 #include "pinctrl-utils.h"
 #include "pinctrl-amd.h"
 
+static int amd_gpio_get_direction(struct gpio_chip *gc, unsigned offset)
+{
+   unsigned long flags;
+   u32 pin_reg;
+   struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+
+   raw_spin_lock_irqsave(&gpio_dev->lock, flags);
+   pin_reg = readl(gpio_dev->base + offset * 4);
+   raw_spin_unlock_irqrestore(&gpio_dev->lock, flags);
+
+   return !(pin_reg & BIT(OUTPUT_ENABLE_OFF));
+}
+
 static int amd_gpio_direction_input(struct gpio_chip *gc, unsigned offset)
 {
unsigned long flags;
@@ -845,6 +858,7 @@ static int amd_gpio_probe(struct platform_device *pdev)
 #endif
 
gpio_dev->pdev = pdev;
+   gpio_dev->gc.get_direction  = amd_gpio_get_direction;
gpio_dev->gc.direction_input= amd_gpio_direction_input;
gpio_dev->gc.direction_output   = amd_gpio_direction_output;
gpio_dev->gc.get= amd_gpio_get_value;
-- 
2.16.1.291.g4437f3f132-goog

Re: eeepc-wmi loaded on Asus desktop board

[Darren Hart]

On Fri, Feb 16, 2018 at 06:45:20PM +0200, Andy Shevchenko wrote:
> +Cc: Darren (for sure)
> 
> On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel
>  wrote:
> > Dear Linux folks,
> >
> >
> > Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with
> > Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device
> > is created.
> >

Does this driver impact your suspend problem?

> > ```
> > Feb 15 18:49:01 asusf2a85mpro kernel: calling  eeepc_wmi_init+0x0/0x1000
> > [eeepc_wmi] @ 285
> > Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Initialization: 0x0
> > Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: BIOS WMI version: 0.9
> > Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: SFUN value: 0x0
> > Feb 15 18:49:01 asusf2a85mpro kernel: input: Eee PC WMI hotkeys as
> > /devices/platform/eeepc-wmi/input/input7
> > Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Number of fans: 1
> > Feb 15 18:49:01 asusf2a85mpro kernel: initcall eeepc_wmi_init+0x0/0x1000
> > [eeepc_wmi] returned 0 after 12130 usecs
> > ```
> >
> > Please find the full log attached.
> >
> > Is that expected, or should the module not load at all on desktop boards?

The eeepc_wmi driver loads when the EEEPC_ACPI_HID or WMI_EVENT_GUID is
presented by the platform firmware. It is tightly coupled with the Asus wmi
driver, so this isn't surprising that it loads on an Asus board as it isn't
uncommon to use the same GUIDs across platforms. This may suggest a need to
rename this driver to something less specific - assuming of course that it is
performing a necessary function.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] ARM: dts: sun7i: Enable HDMI support on the Banana Pi

[Maxime Ripard]

On Fri, Feb 16, 2018 at 11:16:04AM -0500, Stefan Monnier wrote:
> From: Stefan Monnier 
> 
> Enable the display pipeline and HDMI output
> 
> Signed-off-by: Stefan Monnier 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/3] x86/mm: introduce __PAGE_KERNEL_GLOBAL

[Dave Hansen]

On 02/16/2018 10:25 AM, Nadav Amit wrote:
>> +#ifdef CONFIG_PAGE_TABLE_ISOLATION
>> +#define __PAGE_KERNEL_GLOBAL0
>> +#else
>> +#define __PAGE_KERNEL_GLOBAL_PAGE_GLOBAL
>> +#endif
> ...
>> --- a/arch/x86/mm/pageattr.c~kpti-no-global-for-kernel-mappings  
>> 2018-02-13 15:17:56.148210060 -0800
>> +++ b/arch/x86/mm/pageattr.c 2018-02-13 15:17:56.153210060 -0800
>> @@ -593,7 +593,8 @@ try_preserve_large_page(pte_t *kpte, uns
>>   * different bit positions in the two formats.
>>   */
>>  req_prot = pgprot_4k_2_large(req_prot);
>> -req_prot = pgprot_set_on_present(req_prot, _PAGE_GLOBAL | _PAGE_PSE);
>> +req_prot = pgprot_set_on_present(req_prot,
>> +__PAGE_KERNEL_GLOBAL | _PAGE_PSE);
>>  req_prot = canon_pgprot(req_prot);
> From these chunks, it seems to me as req_prot will not have the global bit
> on when “nopti” parameter is provided. What am I missing?

That's a good point.  The current patch does not allow the use of
_PAGE_GLOBAL via _PAGE_KERNEL_GLOBAL when CONFIG_PAGE_TABLE_ISOLATION=y,
but booted with nopti.  It's a simple enough fix.  Logically:

#ifdef CONFIG_PAGE_TABLE_ISOLATION
#define __PAGE_KERNEL_GLOBALstatic_cpu_has(X86_FEATURE_PTI) ?
0 : _PAGE_GLOBAL
#else
#define __PAGE_KERNEL_GLOBAL_PAGE_GLOBAL
#endif

But I don't really want to hide that gunk in a macro like that.  It
might make more sense as a static inline.  I'll give that a shot and resent.

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

[Greg KH]

On Fri, Feb 16, 2018 at 09:57:12AM -0800, Liam Mark wrote:
> On Fri, 16 Feb 2018, Greg KH wrote:
> 
> > On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > > Fix the dup_sg_table function to initialize the dma_address of the new
> > > sg list entries instead of the source dma_address entries.
> > > 
> > > Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")
> > 
> > So this should be sent to the stable trees as well, right?
> > 
> > Please add that when you resend...
> 
> My understanding was that I should only send this to the stable branch if 
> it fixes a real bug.
> 
> Both myself and Laura can't see any actual problems that result from this 
> issue, the change is more to help future proof the code.
> 
> My commit message wasn't clear about this and could have mislead people 
> into thinking there was a bug.
> I will update the commit message to make it clear that this issue doesn't 
> currently result in any problem.
> 
> Do you still want me to send it to the stable trees?

If it's not a bugfix, no need to.  But please clean up your changelog
text as it implies that it is a bugfix...

thanks,

greg k-h

[PATCH v2] ashmem: Fix lockdep issue during llseek

[Joel Fernandes]

ashmem_mutex create a chain of dependencies like so:

(1)
mmap syscall ->
  mmap_sem ->  (acquired)
  ashmem_mmap
  ashmem_mutex (try to acquire)
  (block)

(2)
llseek syscall ->
  ashmem_llseek ->
  ashmem_mutex ->  (acquired)
  inode_lock ->
  inode->i_rwsem (try to acquire)
  (block)

(3)
getdents ->
  iterate_dir ->
  inode_lock ->
  inode->i_rwsem   (acquired)
  copy_to_user ->
  mmap_sem (try to acquire)

There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.

[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48

Cc: Todd Kjos 
Cc: Arve Hjonnevag 
Cc: Greg Hackmann 
Cc: Greg Kroah-Hartman 
Cc: sta...@vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2...@syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes 
---
Changes since first version:
Don't relock after vfs call since its not needed. Only reason we lock is
to protect races with asma->file.
https://patchwork.kernel.org/patch/10185031/

 drivers/staging/android/ashmem.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index bbdc53b686dd..b330e86b3a49 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -326,24 +326,23 @@ static loff_t ashmem_llseek(struct file *file, loff_t 
offset, int origin)
mutex_lock(&ashmem_mutex);
 
if (asma->size == 0) {
-   ret = -EINVAL;
-   goto out;
+   mutex_unlock(&ashmem_mutex);
+   return -EINVAL;
}
 
if (!asma->file) {
-   ret = -EBADF;
-   goto out;
+   mutex_unlock(&ashmem_mutex);
+   return -EBADF;
}
 
+   mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
-   goto out;
+   return ret;
 
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
-   mutex_unlock(&ashmem_mutex);
return ret;
 }
 
-- 
2.16.1.291.g4437f3f132-goog

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Borislav Petkov]

On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
>  We may see some other patches or RFCs about caching and/or shadowing
> variable values in efivarfs to reduce the number of direct EFI reads,
> with the goal of reducing how many SMIs are generated.

So if you do the caching scheme, the question about narrowing
permissions becomes moot...

> Any obvious EFI variables that userspace tools have come to depend on--
> those which normal, unprivileged users need to read-- are helpful inputs
> to this discussion.

... which solves the aspect of not breaking userspace nicely.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC PATCH ghak21 4/4] audit: add parent of refused symlink to audit_names

[Paul Moore]

On Thu, Feb 15, 2018 at 9:59 PM, Richard Guy Briggs  wrote:
> On 2018-02-15 18:34, Paul Moore wrote:
>> On Wed, Feb 14, 2018 at 11:18 AM, Richard Guy Briggs  wrote:
>> > Audit link denied events for symlinks were missing the parent PATH
>> > record.  Add it.  Since the full pathname may not be available,
>> > reconstruct it from the path in the nameidata supplied.
>> >
>> > See: https://github.com/linux-audit/audit-kernel/issues/21
>> > Signed-off-by: Richard Guy Briggs 
>> > ---
>> >  fs/namei.c | 9 +
>> >  1 file changed, 9 insertions(+)
>> >
>> > diff --git a/fs/namei.c b/fs/namei.c
>> > index 0edf133..bf1c046b 100644
>> > --- a/fs/namei.c
>> > +++ b/fs/namei.c
>> > @@ -923,6 +923,7 @@ static inline int may_follow_link(struct nameidata *nd)
>> > const struct inode *inode;
>> > const struct inode *parent;
>> > kuid_t puid;
>> > +   char *pathname;
>> >
>> > if (!sysctl_protected_symlinks)
>> > return 0;
>> > @@ -945,6 +946,14 @@ static inline int may_follow_link(struct nameidata 
>> > *nd)
>> > if (nd->flags & LOOKUP_RCU)
>> > return -ECHILD;
>> >
>> > +   pathname = kmalloc(PATH_MAX + 1, GFP_KERNEL);
>> > +   if (!pathname)
>> > +   return -ENOMEM;
>> > +   audit_inode(getname_kernel(d_absolute_path(&nd->stack[0].link, 
>> > pathname,
>> > +  PATH_MAX + 1)),
>> > +   nd->stack[0].link.dentry, 0);
>>
>> Hmm, it's been a while since I've looked at the audit vfs/inode code,
>> but isn't the audit_inode() call directly above effectively a
>> duplicate of the audit_inode(nd->name, nd->stack[0].link.dentry, 0)
>> call you added in patch 3/4?
>
> It gets the full pathname string of the link, then converts it to a
> struct filename*, and then below, we feed it that struct filename* with
> the parent's dentry and the LOOKUP_PARENT flag to drop the last part of
> the pathname and set the filetype to PARENT.

I think that last bit is what I was forgetting, thanks.

> I didn't try, it, but I expect if I feed it parent's dentry above, I'd
> get only the parent pathname and when I feed it to audit_inode() below
> it would again drop the last part of the pathname when the LOOKUP_PARENT
> flag is included, or not label it as a filetype PARENT if we don't
> include the flag to get the full parent pathname.
>
>> > +   audit_inode(nd->name, nd->stack[0].link.dentry->d_parent, 
>> > LOOKUP_PARENT);
>> > +
>> > audit_inode(nd->name, nd->stack[0].link.dentry, 0);
>> > audit_log_link_denied("follow_link", &nd->stack[0].link);
>> > return -EACCES;
>> > --
>> > 1.8.3.1

-- 
paul moore
www.paul-moore.com

Re: [PATCH] x86/microcode: Check microcode revision before updating sibling threads

[Borislav Petkov]

On Fri, Feb 16, 2018 at 10:46:48AM -0800, Ashok Raj wrote:
> After updating microcode on one of the threads in the core, the
> thread sibling automatically gets the update since the microcode
> resources are shared. Check the ucode revision on the cpu before
> performing a ucode update.
> 
> Signed-off-by: Ashok Raj 
> Cc: X86 ML 
> Cc: LKML 
> ---
>  arch/x86/kernel/cpu/microcode/intel.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
> b/arch/x86/kernel/cpu/microcode/intel.c
> index 09b95a7..5802c2f 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -786,11 +786,21 @@ static enum ucode_state apply_microcode_intel(int cpu)
>  
>   uci = ucode_cpu_info + cpu;
>   mc = uci->mc;
> +
>   if (!mc) {
>   /* Look for a newer patch in our cache: */
>   mc = find_patch(uci);
>   if (!mc)
>   return UCODE_NFOUND;
> + } else {
> + rev = intel_get_microcode_revision();
> + /*
> +  * Its possible the microcode got udpated
> +  * because its sibling update was done earlier.
> +  * Skip the udpate in that case.
> +  */
> + if (rev == mc->hdr.rev)
> + goto done;
>   }

Make that like the AMD version:

/*
 * Its possible the microcode got udpated
 * because its sibling update was done earlier.
 * Skip the udpate in that case.
 */
rev = intel_get_microcode_revision();
if (rev >= mc->hdr.rev) {
uci->cpu_sig.rev = rev;
c->microcode = rev;

return UCODE_OK;
}

and make the subject prefix "x86/microcode/intel:" for your next
submission.

Thx.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Guenter Roeck]

On Fri, Feb 16, 2018 at 10:10:44AM -0800, Brian Norris wrote:
> On Fri, Feb 16, 2018 at 07:48:50AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:
> > > On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > 
> > > Consider this an objection:
> > > 
> > > I'm currently arguing that this is unnecessarily regressing power
> > > consumption here:
> > > 
> > > https://patchwork.kernel.org/patch/10149195/
> > > 
> > > I'll leave it up to you what to do with this, but if this ends up in
> > > Chromium OS kernels, I'm likely to revert it there...
> > 
> > Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
> > here.
> 
> The link is the original patch, where I'm (too late?) complaining about
> its side effects. Hans and Marcel are discussing potential alternatives.
> This stuff happens in -rc kernels. But you're already ready to push it
> out to -stable users? I can try to push another few reverts into Linus's
> tree if that really helps, or else you can wait on pushing these to
> -stable until 4.16 settles down.

FWIW, here are the various commit SHAs.

Upstream:   61f5acea8737
v4.15 (queued for v4.15.4): e766a2d7f7c2
v4.14 (queued for v4.14.20):736385472dfa
v4.9 (queued for v4.9.82):  1c6fc2167678
v4.4 (queued for v4.4.116): 575538a5371d

I didn't check older stable kernels.

Guenter

[PATCH 09/23] kconfig: add 'cc-option' macro

[Masahiro Yamada]

This will be the most frequently used macro.  It evaluates to 'y' if
the given argument is supported by the compiler, or 'n' otherwise.

Signed-off-by: Masahiro Yamada 
---

 init/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index b4814e6..f026a62 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -8,6 +8,10 @@ config DEFCONFIG_LIST
default ARCH_DEFCONFIG
default "arch/$ARCH/defconfig"
 
+config cc-option
+   string
+   macro $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
+
 config CONSTRUCTORS
bool
depends on !UML
-- 
2.7.4

[PATCH 04/23] kconfig: set SYMBOL_AUTO to the symbol marked with defconfig_list

[Masahiro Yamada]

The 'defconfig_list' is a weird attribute.  If the '.config' is
missing, conf_read_simple() iterates over all visible defaults,
then it uses the first one for which fopen() succeeds.

config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
default "/lib/modules/$UNAME_RELEASE/.config"
default "/etc/kernel-config"
default "/boot/config-$UNAME_RELEASE"
default "$ARCH_DEFCONFIG"
default "arch/$ARCH/defconfig"

However, like other symbols, the first visible default is always
written out to the .config file.  This might be different from what
has been actually used.

For example, on my machine, the third one "/boot/config-$UNAME_RELEASE"
is opened, like follows:

  $ rm .config
  $ make oldconfig 2>/dev/null
  scripts/kconfig/conf  --oldconfig Kconfig
  #
  # using defaults found in /boot/config-4.4.0-112-generic
  #
  *
  * Restart config...
  *
  *
  * IRQ subsystem
  *
  Expose irq internals in debugfs (GENERIC_IRQ_DEBUGFS) [N/y/?] (NEW)

However, the resulted .config file contains the first one since it is
visible:

  $ grep CONFIG_DEFCONFIG_LIST .config
  CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

In order to stop confusing people, prevent this CONFIG option from
being written to the .config file.

Signed-off-by: Masahiro Yamada 
---

I'd like to fix the root case of this weirdness later.
(and other 'option' attributes as well)

But, this series is focusing a more important work in a bigger picture.

For now, I decided to just hide CONFIG_DEFCONFIG_LIST
from the .config file.


 scripts/kconfig/menu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 9922285..36cd3e1 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -212,6 +212,7 @@ void menu_add_option(int token, char *arg)
sym_defconfig_list = current_entry->sym;
else if (sym_defconfig_list != current_entry->sym)
zconf_error("trying to redefine defconfig symbol");
+   sym_defconfig_list->flags |= SYMBOL_AUTO;
break;
case T_OPT_ENV:
prop_add_env(arg);
-- 
2.7.4