Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

[Dave Jones]

On Tue, Jul 26, 2016 at 11:13:44PM +0800, Fengguang Wu wrote:
 
 > >> The "BUG: kernel test crashed" means the VM reboots by itself while
 > >> the trinity test is running. If the error message is "BUG: kernel boot
 > >> crashed" it'd mean VM abnormally reboots before any test is launched.
 > >
 > >Is it possible to include a url pointing to a page of documentation
 > >holding this information in your emails or alternatively a url pointing
 > >to some source code.  Just so other people don't have to ask you this
 > >question.
 > 
 > Yes that's the right directions to follow. We'll make the reports more
 > understandable and the test/bisects more reliable.
 > 
 > In particular, I suspect this false report might be related to QEMU
 > watchdog. The wild guess is, if trinity touches the watchdog device by
 > accident, it may result in the VM reset w/o any symptom.
 
See ignore_files() in pathnames.c
Adding an entry to the blacklist there is easy enough to prove/disprove this.

Dave

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

[Dave Jones]

On Tue, Jul 26, 2016 at 11:13:44PM +0800, Fengguang Wu wrote:
 
 > >> The "BUG: kernel test crashed" means the VM reboots by itself while
 > >> the trinity test is running. If the error message is "BUG: kernel boot
 > >> crashed" it'd mean VM abnormally reboots before any test is launched.
 > >
 > >Is it possible to include a url pointing to a page of documentation
 > >holding this information in your emails or alternatively a url pointing
 > >to some source code.  Just so other people don't have to ask you this
 > >question.
 > 
 > Yes that's the right directions to follow. We'll make the reports more
 > understandable and the test/bisects more reliable.
 > 
 > In particular, I suspect this false report might be related to QEMU
 > watchdog. The wild guess is, if trinity touches the watchdog device by
 > accident, it may result in the VM reset w/o any symptom.
 
See ignore_files() in pathnames.c
Adding an entry to the blacklist there is easy enough to prove/disprove this.

Dave

[PATCH 1/2] tools lib bpf: Use official ELF e_machine value

[Arnaldo Carvalho de Melo]

From: Wang Nan 

New LLVM will issue newly assigned EM_BPF machine code. The new code
will be propagated to glibc and libelf.

This patch introduces the new machine code to libbpf.

Signed-off-by: Wang Nan 
Acked-by: Alexei Starovoitov 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1468821668-60088-1-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/bpf/libbpf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 32e6b6bc6f7d..b699aea9a025 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -37,6 +37,10 @@
 #include "libbpf.h"
 #include "bpf.h"
 
+#ifndef EM_BPF
+#define EM_BPF 247
+#endif
+
 #define __printf(a, b) __attribute__((format(printf, a, b)))
 
 __printf(1, 2)
@@ -439,7 +443,8 @@ static int bpf_object__elf_init(struct bpf_object *obj)
}
ep = >efile.ehdr;
 
-   if ((ep->e_type != ET_REL) || (ep->e_machine != 0)) {
+   /* Old LLVM set e_machine to EM_NONE */
+   if ((ep->e_type != ET_REL) || (ep->e_machine && (ep->e_machine != 
EM_BPF))) {
pr_warning("%s is not an eBPF object file\n",
obj->path);
err = -LIBBPF_ERRNO__FORMAT;
-- 
2.7.4

[PATCH 1/2] tools lib bpf: Use official ELF e_machine value

[Arnaldo Carvalho de Melo]

From: Wang Nan 

New LLVM will issue newly assigned EM_BPF machine code. The new code
will be propagated to glibc and libelf.

This patch introduces the new machine code to libbpf.

Signed-off-by: Wang Nan 
Acked-by: Alexei Starovoitov 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1468821668-60088-1-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/bpf/libbpf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 32e6b6bc6f7d..b699aea9a025 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -37,6 +37,10 @@
 #include "libbpf.h"
 #include "bpf.h"
 
+#ifndef EM_BPF
+#define EM_BPF 247
+#endif
+
 #define __printf(a, b) __attribute__((format(printf, a, b)))
 
 __printf(1, 2)
@@ -439,7 +443,8 @@ static int bpf_object__elf_init(struct bpf_object *obj)
}
ep = >efile.ehdr;
 
-   if ((ep->e_type != ET_REL) || (ep->e_machine != 0)) {
+   /* Old LLVM set e_machine to EM_NONE */
+   if ((ep->e_type != ET_REL) || (ep->e_machine && (ep->e_machine != 
EM_BPF))) {
pr_warning("%s is not an eBPF object file\n",
obj->path);
err = -LIBBPF_ERRNO__FORMAT;
-- 
2.7.4

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[Robert Foss]

From: Grant Grundler 


For the record, I believe I am not the author of these patches.

I believe the original author is
Signed-off-by: Freddy Xin 

as recorded in the following code reviews (and testing) that I was
responsible for:

https://chromium-review.googlesource.com/#/q/owner:%22Grant+Grundler%22+status:merged+asix+in_pm

And I would certainly be happy to see this code go upstream and
expected ASIX would submit this change upstream.

Thanks for the feedback (for this patch and the other ones)!
I'm preparing a v2 and will submit it withing a day or two.




In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.


FTR, current  drivers/net/usb/ax88179_178a.c uses "in_pm" as well.

Ah! Would you like that to be noted in the commit message?



Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.

Signed-off-by: Grant Grundler 


BTW, I have two additional changes for AX88772x support sitting in my
"needs more work" queue (for quite a while already):
   https://chromium-review.googlesource.com/#/c/229620/
   "asix: autoneg will set WRITE_MEDIUM reg"

   https://chromium-review.googlesource.com/#/c/231162/
   "net: asix: see 802.3 spec for phy reset"

I would certainly approve if _anyone_ picked these up, tested them,
and then submitted them to netdev.

Unfortunately I am without appropriate hardware at the moment.



cheers,
grant


---
 drivers/net/usb/asix.h |  40 +++--
 drivers/net/usb/asix_common.c  | 180 +++-
 drivers/net/usb/asix_devices.c | 373 -
 drivers/net/usb/ax88172a.c |  29 ++--
 4 files changed, 472 insertions(+), 150 deletions(-)

diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index a2d3ea6..d109242 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -46,6 +46,7 @@
 #define AX_CMD_SET_SW_MII  0x06
 #define AX_CMD_READ_MII_REG0x07
 #define AX_CMD_WRITE_MII_REG   0x08
+#define AX_CMD_STATMNGSTS_REG  0x09
 #define AX_CMD_SET_HW_MII  0x0a
 #define AX_CMD_READ_EEPROM 0x0b
 #define AX_CMD_WRITE_EEPROM0x0c
@@ -71,6 +72,17 @@
 #define AX_CMD_SW_RESET0x20
 #define AX_CMD_SW_PHY_STATUS   0x21
 #define AX_CMD_SW_PHY_SELECT   0x22
+#define AX_QCTCTRL 0x2A
+
+#define AX_CHIPCODE_MASK   0x70
+#define AX_AX88772_CHIPCODE0x00
+#define AX_AX88772A_CHIPCODE   0x10
+#define AX_AX88772B_CHIPCODE   0x20
+#define AX_HOST_EN 0x01
+
+#define AX_PHYSEL_PSEL 0x01
+#define AX_PHYSEL_SSMII0
+#define AX_PHYSEL_SSEN 0x10

 #define AX_PHY_SELECT_MASK (BIT(3) | BIT(2))
 #define AX_PHY_SELECT_INTERNAL 0
@@ -173,6 +185,10 @@ struct asix_rx_fixup_info {
 };

 struct asix_common_private {
+   void (*resume)(struct usbnet *dev);
+   void (*suspend)(struct usbnet *dev);
+   u16 presvd_phy_advertise;
+   u16 presvd_phy_bmcr;
struct asix_rx_fixup_info rx_fixup_info;
 };

@@ -182,10 +198,10 @@ extern const struct driver_info ax88172a_info;
 #define FLAG_EEPROM_MAC(1UL << 0)  /* init device MAC from 
eeprom */

 int asix_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
- u16 size, void *data);
+ u16 size, void *data, int in_pm);

 int asix_write_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
-  u16 size, void *data);
+  u16 size, void *data, int in_pm);

 void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 value,
  u16 index, u16 size, void *data);
@@ -197,27 +213,31 @@ int asix_rx_fixup_common(struct usbnet *dev, struct 
sk_buff *skb);
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags);

-int asix_set_sw_mii(struct usbnet *dev);
-int asix_set_hw_mii(struct usbnet *dev);
+int asix_set_sw_mii(struct usbnet *dev, int in_pm);
+int asix_set_hw_mii(struct usbnet *dev, int in_pm);

 int asix_read_phy_addr(struct usbnet *dev, int internal);
 int asix_get_phy_addr(struct usbnet *dev);

-int asix_sw_reset(struct usbnet *dev, u8 flags);
+int asix_sw_reset(struct usbnet *dev, u8 flags, int in_pm);

-u16 asix_read_rx_ctl(struct usbnet *dev);
-int asix_write_rx_ctl(struct usbnet *dev, u16 mode);
+u16 asix_read_rx_ctl(struct usbnet *dev, int in_pm);
+int asix_write_rx_ctl(struct usbnet *dev, u16 mode, int in_pm);

-u16 asix_read_medium_status(struct usbnet *dev);
-int asix_write_medium_mode(struct usbnet *dev, u16 mode);
+u16 asix_read_medium_status(struct usbnet *dev, int in_pm);
+int 

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[Robert Foss]

From: Grant Grundler 


For the record, I believe I am not the author of these patches.

I believe the original author is
Signed-off-by: Freddy Xin 

as recorded in the following code reviews (and testing) that I was
responsible for:

https://chromium-review.googlesource.com/#/q/owner:%22Grant+Grundler%22+status:merged+asix+in_pm

And I would certainly be happy to see this code go upstream and
expected ASIX would submit this change upstream.

Thanks for the feedback (for this patch and the other ones)!
I'm preparing a v2 and will submit it withing a day or two.




In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.


FTR, current  drivers/net/usb/ax88179_178a.c uses "in_pm" as well.

Ah! Would you like that to be noted in the commit message?



Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.

Signed-off-by: Grant Grundler 


BTW, I have two additional changes for AX88772x support sitting in my
"needs more work" queue (for quite a while already):
   https://chromium-review.googlesource.com/#/c/229620/
   "asix: autoneg will set WRITE_MEDIUM reg"

   https://chromium-review.googlesource.com/#/c/231162/
   "net: asix: see 802.3 spec for phy reset"

I would certainly approve if _anyone_ picked these up, tested them,
and then submitted them to netdev.

Unfortunately I am without appropriate hardware at the moment.



cheers,
grant


---
 drivers/net/usb/asix.h |  40 +++--
 drivers/net/usb/asix_common.c  | 180 +++-
 drivers/net/usb/asix_devices.c | 373 -
 drivers/net/usb/ax88172a.c |  29 ++--
 4 files changed, 472 insertions(+), 150 deletions(-)

diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index a2d3ea6..d109242 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -46,6 +46,7 @@
 #define AX_CMD_SET_SW_MII  0x06
 #define AX_CMD_READ_MII_REG0x07
 #define AX_CMD_WRITE_MII_REG   0x08
+#define AX_CMD_STATMNGSTS_REG  0x09
 #define AX_CMD_SET_HW_MII  0x0a
 #define AX_CMD_READ_EEPROM 0x0b
 #define AX_CMD_WRITE_EEPROM0x0c
@@ -71,6 +72,17 @@
 #define AX_CMD_SW_RESET0x20
 #define AX_CMD_SW_PHY_STATUS   0x21
 #define AX_CMD_SW_PHY_SELECT   0x22
+#define AX_QCTCTRL 0x2A
+
+#define AX_CHIPCODE_MASK   0x70
+#define AX_AX88772_CHIPCODE0x00
+#define AX_AX88772A_CHIPCODE   0x10
+#define AX_AX88772B_CHIPCODE   0x20
+#define AX_HOST_EN 0x01
+
+#define AX_PHYSEL_PSEL 0x01
+#define AX_PHYSEL_SSMII0
+#define AX_PHYSEL_SSEN 0x10

 #define AX_PHY_SELECT_MASK (BIT(3) | BIT(2))
 #define AX_PHY_SELECT_INTERNAL 0
@@ -173,6 +185,10 @@ struct asix_rx_fixup_info {
 };

 struct asix_common_private {
+   void (*resume)(struct usbnet *dev);
+   void (*suspend)(struct usbnet *dev);
+   u16 presvd_phy_advertise;
+   u16 presvd_phy_bmcr;
struct asix_rx_fixup_info rx_fixup_info;
 };

@@ -182,10 +198,10 @@ extern const struct driver_info ax88172a_info;
 #define FLAG_EEPROM_MAC(1UL << 0)  /* init device MAC from 
eeprom */

 int asix_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
- u16 size, void *data);
+ u16 size, void *data, int in_pm);

 int asix_write_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
-  u16 size, void *data);
+  u16 size, void *data, int in_pm);

 void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 value,
  u16 index, u16 size, void *data);
@@ -197,27 +213,31 @@ int asix_rx_fixup_common(struct usbnet *dev, struct 
sk_buff *skb);
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags);

-int asix_set_sw_mii(struct usbnet *dev);
-int asix_set_hw_mii(struct usbnet *dev);
+int asix_set_sw_mii(struct usbnet *dev, int in_pm);
+int asix_set_hw_mii(struct usbnet *dev, int in_pm);

 int asix_read_phy_addr(struct usbnet *dev, int internal);
 int asix_get_phy_addr(struct usbnet *dev);

-int asix_sw_reset(struct usbnet *dev, u8 flags);
+int asix_sw_reset(struct usbnet *dev, u8 flags, int in_pm);

-u16 asix_read_rx_ctl(struct usbnet *dev);
-int asix_write_rx_ctl(struct usbnet *dev, u16 mode);
+u16 asix_read_rx_ctl(struct usbnet *dev, int in_pm);
+int asix_write_rx_ctl(struct usbnet *dev, u16 mode, int in_pm);

-u16 asix_read_medium_status(struct usbnet *dev);
-int asix_write_medium_mode(struct usbnet *dev, u16 mode);
+u16 asix_read_medium_status(struct usbnet *dev, int in_pm);
+int asix_write_medium_mode(struct usbnet *dev, u16 mode, int in_pm);

-int 

Re: [PATCH] [RFC] Introduce mmap randomization

[Nick Kralevich]

On Tue, Jul 26, 2016 at 2:02 PM, Roberts, William C
 wrote:
>
>
>> -Original Message-
>> From: Nick Kralevich [mailto:n...@google.com]
>> Sent: Tuesday, July 26, 2016 1:41 PM
>> To: Roberts, William C 
>> Cc: ja...@lakedaemon.net; linux...@vger.kernel.org; lkml > ker...@vger.kernel.org>; kernel-harden...@lists.openwall.com; Andrew
>> Morton ; Kees Cook ;
>> Greg KH ; Jeffrey Vander Stoep
>> ; saly...@android.com; Daniel Cashman
>> 
>> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>>
>> My apologies in advance if I misunderstand the purposes of this patch.
>>
>> IIUC, this patch adds a random gap between various mmap() mappings, with the
>> goal of ensuring that both the mmap base address and gaps between pages are
>> randomized.
>>
>> If that's the goal, please note that this behavior has caused significant
>> performance problems to Android in the past. Specifically, random gaps 
>> between
>> mmap()ed regions causes memory space fragmentation. After a program runs for
>> a long time, the ability to find large contiguous blocks of memory becomes
>> impossible, and mmap()s fail due to lack of a large enough address space.
>
> Yes and fragmentation is definitely a problem here. Especially when the 
> mmaps()
> are not a consistent length for program life.
>
>>
>> This isn't just a theoretical concern. Android actually hit this on kernels 
>> prior to
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa46
>> 6780a754154531b44c2086f6618cee3a8
>> . Before that patch, the gaps between mmap()ed pages were randomized.
>> See the discussion at:
>>
>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2011-
>> November/073082.html
>>   http://marc.info/?t=13207095745=1=2
>>
>> We ended up having to work around this problem in the following commits:
>>
>>
>> https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f59
>> 2d56caab5e2a259c
>>   https://android.googlesource.com/platform/art/+/51e5386
>>   https://android.googlesource.com/platform/art/+/f94b781
>>
>> If this behavior was re-introduced, it's likely to cause hard-to-reproduce
>> problems, and I suspect Android based distributions would tend to disable 
>> this
>> feature either globally, or for applications which make a large number of 
>> mmap()
>> calls.
>
> Yeah and this is the issue I want to see if we can overcome. I see the 
> biggest benefit
> being on libraries loaded by dl. Perhaps a random flag and modify to linkers. 
> Im just
> spit balling here and collecting the feedback, like this. Thanks for the 
> detail, that
> helps a lot.

Android N introduced library load order randomization, which partially
helps with this.

https://android-review.googlesource.com/178130

There's also https://android-review.googlesource.com/248499 which adds
additional gaps for shared libraries.


>
>>
>> -- Nick
>>
>>
>>
>> On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
>> > From: William Roberts 
>> >
>> > This patch introduces the ability randomize mmap locations where the
>> > address is not requested, for instance when ld is allocating pages for
>> > shared libraries. It chooses to randomize based on the current
>> > personality for ASLR.
>> >
>> > Currently, allocations are done sequentially within unmapped address
>> > space gaps. This may happen top down or bottom up depending on scheme.
>> >
>> > For instance these mmap calls produce contiguous mappings:
>> > int size = getpagesize();
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40026000
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40027000
>> >
>> > Note no gap between.
>> >
>> > After patches:
>> > int size = getpagesize();
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x400b4000
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40055000
>> >
>> > Note gap between.
>> >
>> > Using the test program mentioned here, that allocates fixed sized
>> > blocks till exhaustion:
>> > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
>> > no difference was noticed in the number of allocations. Most varied
>> > from run to run, but were always within a few allocations of one
>> > another between patched and un-patched runs.
>> >
>> > Performance Measurements:
>> > Using strace with -T option and filtering for mmap on the program ls
>> > shows a slowdown of approximate 3.7%
>> >
>> > Signed-off-by: William Roberts 
>> > ---
>> >  mm/mmap.c | 24 
>> >  1 file changed, 24 insertions(+)
>> >
>> > diff --git a/mm/mmap.c b/mm/mmap.c
>> > index de2c176..7891272 100644
>> > --- a/mm/mmap.c
>> > +++ b/mm/mmap.c
>> > @@ -43,6 +43,7 @@
>> >  #include 
>> >  #include 
>> 

Re: [PATCH] [RFC] Introduce mmap randomization

[Nick Kralevich]

On Tue, Jul 26, 2016 at 2:02 PM, Roberts, William C
 wrote:
>
>
>> -Original Message-
>> From: Nick Kralevich [mailto:n...@google.com]
>> Sent: Tuesday, July 26, 2016 1:41 PM
>> To: Roberts, William C 
>> Cc: ja...@lakedaemon.net; linux...@vger.kernel.org; lkml > ker...@vger.kernel.org>; kernel-harden...@lists.openwall.com; Andrew
>> Morton ; Kees Cook ;
>> Greg KH ; Jeffrey Vander Stoep
>> ; saly...@android.com; Daniel Cashman
>> 
>> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>>
>> My apologies in advance if I misunderstand the purposes of this patch.
>>
>> IIUC, this patch adds a random gap between various mmap() mappings, with the
>> goal of ensuring that both the mmap base address and gaps between pages are
>> randomized.
>>
>> If that's the goal, please note that this behavior has caused significant
>> performance problems to Android in the past. Specifically, random gaps 
>> between
>> mmap()ed regions causes memory space fragmentation. After a program runs for
>> a long time, the ability to find large contiguous blocks of memory becomes
>> impossible, and mmap()s fail due to lack of a large enough address space.
>
> Yes and fragmentation is definitely a problem here. Especially when the 
> mmaps()
> are not a consistent length for program life.
>
>>
>> This isn't just a theoretical concern. Android actually hit this on kernels 
>> prior to
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa46
>> 6780a754154531b44c2086f6618cee3a8
>> . Before that patch, the gaps between mmap()ed pages were randomized.
>> See the discussion at:
>>
>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2011-
>> November/073082.html
>>   http://marc.info/?t=13207095745=1=2
>>
>> We ended up having to work around this problem in the following commits:
>>
>>
>> https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f59
>> 2d56caab5e2a259c
>>   https://android.googlesource.com/platform/art/+/51e5386
>>   https://android.googlesource.com/platform/art/+/f94b781
>>
>> If this behavior was re-introduced, it's likely to cause hard-to-reproduce
>> problems, and I suspect Android based distributions would tend to disable 
>> this
>> feature either globally, or for applications which make a large number of 
>> mmap()
>> calls.
>
> Yeah and this is the issue I want to see if we can overcome. I see the 
> biggest benefit
> being on libraries loaded by dl. Perhaps a random flag and modify to linkers. 
> Im just
> spit balling here and collecting the feedback, like this. Thanks for the 
> detail, that
> helps a lot.

Android N introduced library load order randomization, which partially
helps with this.

https://android-review.googlesource.com/178130

There's also https://android-review.googlesource.com/248499 which adds
additional gaps for shared libraries.


>
>>
>> -- Nick
>>
>>
>>
>> On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
>> > From: William Roberts 
>> >
>> > This patch introduces the ability randomize mmap locations where the
>> > address is not requested, for instance when ld is allocating pages for
>> > shared libraries. It chooses to randomize based on the current
>> > personality for ASLR.
>> >
>> > Currently, allocations are done sequentially within unmapped address
>> > space gaps. This may happen top down or bottom up depending on scheme.
>> >
>> > For instance these mmap calls produce contiguous mappings:
>> > int size = getpagesize();
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40026000
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40027000
>> >
>> > Note no gap between.
>> >
>> > After patches:
>> > int size = getpagesize();
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x400b4000
>> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x40055000
>> >
>> > Note gap between.
>> >
>> > Using the test program mentioned here, that allocates fixed sized
>> > blocks till exhaustion:
>> > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
>> > no difference was noticed in the number of allocations. Most varied
>> > from run to run, but were always within a few allocations of one
>> > another between patched and un-patched runs.
>> >
>> > Performance Measurements:
>> > Using strace with -T option and filtering for mmap on the program ls
>> > shows a slowdown of approximate 3.7%
>> >
>> > Signed-off-by: William Roberts 
>> > ---
>> >  mm/mmap.c | 24 
>> >  1 file changed, 24 insertions(+)
>> >
>> > diff --git a/mm/mmap.c b/mm/mmap.c
>> > index de2c176..7891272 100644
>> > --- a/mm/mmap.c
>> > +++ b/mm/mmap.c
>> > @@ -43,6 +43,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  #include 
>> >  #include 
>> > @@ -1582,6 +1583,24 @@ unacct_error:
>> > return error;
>> >  }
>> >
>> > +/*
>> > + * Generate a random address within a range. This differs from
>> > +randomize_addr() by randomizing

Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Rob Clark]

On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt  wrote:
> Overflow memory handling is tricky: While it's still referenced by the
> BPO registers, we want to keep it from being freed.  When we are
> putting a new set of overflow memory in the registers, we need to
> assign the old one to the last rendering job using it.
>
> We were looking at "what's currently running in the binner", but since
> the bin/render submission split, we may end up with the binner
> completing and having no new job while the renderer is still
> processing.  So, if we don't find a bin job at all, look at the
> highest-seqno (last) render job to attach our overflow to.

so, drive-by comment.. but can you allocate gem bo's without backing
them immediately with pages?  If so, just always allocate the bo
up-front and attach it as a dependency of the batch, and only pin it
to actual pages when you have to overflow?

BR,
-R

> Signed-off-by: Eric Anholt 
> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
> rendering jobs")
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/vc4/vc4_drv.h | 9 +
>  drivers/gpu/drm/vc4/vc4_irq.c | 4 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 0ced289d7696..87f727932af2 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -321,6 +321,15 @@ vc4_first_render_job(struct vc4_dev *vc4)
> struct vc4_exec_info, head);
>  }
>
> +static inline struct vc4_exec_info *
> +vc4_last_render_job(struct vc4_dev *vc4)
> +{
> +   if (list_empty(>render_job_list))
> +   return NULL;
> +   return list_last_entry(>render_job_list,
> +  struct vc4_exec_info, head);
> +}
> +
>  /**
>   * struct vc4_texture_sample_info - saves the offsets into the UBO for 
> texture
>   * setup parameters.
> diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
> index b0104a346a74..094bc6a475c1 100644
> --- a/drivers/gpu/drm/vc4/vc4_irq.c
> +++ b/drivers/gpu/drm/vc4/vc4_irq.c
> @@ -83,8 +83,10 @@ vc4_overflow_mem_work(struct work_struct *work)
>
> spin_lock_irqsave(>job_lock, irqflags);
> current_exec = vc4_first_bin_job(vc4);
> +   if (!current_exec)
> +   current_exec = vc4_last_render_job(vc4);
> if (current_exec) {
> -   vc4->overflow_mem->seqno = vc4->finished_seqno + 1;
> +   vc4->overflow_mem->seqno = current_exec->seqno;
> list_add_tail(>overflow_mem->unref_head,
>   _exec->unref_list);
> vc4->overflow_mem = NULL;
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Rob Clark]

On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt  wrote:
> Overflow memory handling is tricky: While it's still referenced by the
> BPO registers, we want to keep it from being freed.  When we are
> putting a new set of overflow memory in the registers, we need to
> assign the old one to the last rendering job using it.
>
> We were looking at "what's currently running in the binner", but since
> the bin/render submission split, we may end up with the binner
> completing and having no new job while the renderer is still
> processing.  So, if we don't find a bin job at all, look at the
> highest-seqno (last) render job to attach our overflow to.

so, drive-by comment.. but can you allocate gem bo's without backing
them immediately with pages?  If so, just always allocate the bo
up-front and attach it as a dependency of the batch, and only pin it
to actual pages when you have to overflow?

BR,
-R

> Signed-off-by: Eric Anholt 
> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
> rendering jobs")
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/vc4/vc4_drv.h | 9 +
>  drivers/gpu/drm/vc4/vc4_irq.c | 4 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 0ced289d7696..87f727932af2 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -321,6 +321,15 @@ vc4_first_render_job(struct vc4_dev *vc4)
> struct vc4_exec_info, head);
>  }
>
> +static inline struct vc4_exec_info *
> +vc4_last_render_job(struct vc4_dev *vc4)
> +{
> +   if (list_empty(>render_job_list))
> +   return NULL;
> +   return list_last_entry(>render_job_list,
> +  struct vc4_exec_info, head);
> +}
> +
>  /**
>   * struct vc4_texture_sample_info - saves the offsets into the UBO for 
> texture
>   * setup parameters.
> diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
> index b0104a346a74..094bc6a475c1 100644
> --- a/drivers/gpu/drm/vc4/vc4_irq.c
> +++ b/drivers/gpu/drm/vc4/vc4_irq.c
> @@ -83,8 +83,10 @@ vc4_overflow_mem_work(struct work_struct *work)
>
> spin_lock_irqsave(>job_lock, irqflags);
> current_exec = vc4_first_bin_job(vc4);
> +   if (!current_exec)
> +   current_exec = vc4_last_render_job(vc4);
> if (current_exec) {
> -   vc4->overflow_mem->seqno = vc4->finished_seqno + 1;
> +   vc4->overflow_mem->seqno = current_exec->seqno;
> list_add_tail(>overflow_mem->unref_head,
>   _exec->unref_list);
> vc4->overflow_mem = NULL;
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] perf s390: Fix 'start' address of module's map

[Arnaldo Carvalho de Melo]

From: Song Shan Gong 

At present, when creating module's map, perf gets 'start' address by
parsing '/proc/modules', but it's the module base address, it isn't the
start address of the '.text' section.

In most arches, it's OK. But for s390, it places 'GOT' and 'PLT'
relocations before '.text' section. So there exists an offset between
module base address and '.text' section, which will incur wrong symbol
resolution for modules.

Fix this bug by getting 'start' address of module's map from parsing
'/sys/module/[module name]/sections/.text', not from '/proc/modules'.

Signed-off-by: Song Shan Gong 
Acked-by: Jiri Olsa 
Cc: Christian Borntraeger 
Cc: David Ahern 
Link: 
http://lkml.kernel.org/r/1469070651-6447-2-git-send-email-gon...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/Build |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++
 tools/perf/util/machine.c   |  8 
 tools/perf/util/machine.h   |  1 +
 4 files changed, 30 insertions(+)
 create mode 100644 tools/perf/arch/s390/util/machine.c

diff --git a/tools/perf/arch/s390/util/Build b/tools/perf/arch/s390/util/Build
index 8a61372bb47a..5bd7b9260cc0 100644
--- a/tools/perf/arch/s390/util/Build
+++ b/tools/perf/arch/s390/util/Build
@@ -2,3 +2,5 @@ libperf-y += header.o
 libperf-y += kvm-stat.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
+
+libperf-y += machine.o
diff --git a/tools/perf/arch/s390/util/machine.c 
b/tools/perf/arch/s390/util/machine.c
new file mode 100644
index ..b9a95a1a8e69
--- /dev/null
+++ b/tools/perf/arch/s390/util/machine.c
@@ -0,0 +1,19 @@
+#include 
+#include 
+#include 
+#include "util.h"
+#include "machine.h"
+#include "api/fs/fs.h"
+
+int arch__fix_module_text_start(u64 *start, const char *name)
+{
+   char path[PATH_MAX];
+
+   snprintf(path, PATH_MAX, "module/%.*s/sections/.text",
+   (int)strlen(name) - 2, name + 1);
+
+   if (sysfs__read_ull(path, (unsigned long long *)start) < 0)
+   return -1;
+
+   return 0;
+}
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index bc2cdbd09a25..cb6388dbdd98 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1093,12 +1093,20 @@ static int machine__set_modules_path(struct machine 
*machine)
 
return map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
 }
+int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
+   const char *name __maybe_unused)
+{
+   return 0;
+}
 
 static int machine__create_module(void *arg, const char *name, u64 start)
 {
struct machine *machine = arg;
struct map *map;
 
+   if (arch__fix_module_text_start(, name) < 0)
+   return -1;
+
map = machine__findnew_module_map(machine, start, name);
if (map == NULL)
return -1;
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 41ac9cfd416b..20739f746bc4 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -216,6 +216,7 @@ struct symbol *machine__find_kernel_function_by_name(struct 
machine *machine,
 
 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, symbol_filter_t 
filter);
-- 
2.7.4

[PATCH 2/2] perf s390: Fix 'start' address of module's map

[Arnaldo Carvalho de Melo]

From: Song Shan Gong 

At present, when creating module's map, perf gets 'start' address by
parsing '/proc/modules', but it's the module base address, it isn't the
start address of the '.text' section.

In most arches, it's OK. But for s390, it places 'GOT' and 'PLT'
relocations before '.text' section. So there exists an offset between
module base address and '.text' section, which will incur wrong symbol
resolution for modules.

Fix this bug by getting 'start' address of module's map from parsing
'/sys/module/[module name]/sections/.text', not from '/proc/modules'.

Signed-off-by: Song Shan Gong 
Acked-by: Jiri Olsa 
Cc: Christian Borntraeger 
Cc: David Ahern 
Link: 
http://lkml.kernel.org/r/1469070651-6447-2-git-send-email-gon...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/Build |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++
 tools/perf/util/machine.c   |  8 
 tools/perf/util/machine.h   |  1 +
 4 files changed, 30 insertions(+)
 create mode 100644 tools/perf/arch/s390/util/machine.c

diff --git a/tools/perf/arch/s390/util/Build b/tools/perf/arch/s390/util/Build
index 8a61372bb47a..5bd7b9260cc0 100644
--- a/tools/perf/arch/s390/util/Build
+++ b/tools/perf/arch/s390/util/Build
@@ -2,3 +2,5 @@ libperf-y += header.o
 libperf-y += kvm-stat.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
+
+libperf-y += machine.o
diff --git a/tools/perf/arch/s390/util/machine.c 
b/tools/perf/arch/s390/util/machine.c
new file mode 100644
index ..b9a95a1a8e69
--- /dev/null
+++ b/tools/perf/arch/s390/util/machine.c
@@ -0,0 +1,19 @@
+#include 
+#include 
+#include 
+#include "util.h"
+#include "machine.h"
+#include "api/fs/fs.h"
+
+int arch__fix_module_text_start(u64 *start, const char *name)
+{
+   char path[PATH_MAX];
+
+   snprintf(path, PATH_MAX, "module/%.*s/sections/.text",
+   (int)strlen(name) - 2, name + 1);
+
+   if (sysfs__read_ull(path, (unsigned long long *)start) < 0)
+   return -1;
+
+   return 0;
+}
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index bc2cdbd09a25..cb6388dbdd98 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1093,12 +1093,20 @@ static int machine__set_modules_path(struct machine 
*machine)
 
return map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
 }
+int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
+   const char *name __maybe_unused)
+{
+   return 0;
+}
 
 static int machine__create_module(void *arg, const char *name, u64 start)
 {
struct machine *machine = arg;
struct map *map;
 
+   if (arch__fix_module_text_start(, name) < 0)
+   return -1;
+
map = machine__findnew_module_map(machine, start, name);
if (map == NULL)
return -1;
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 41ac9cfd416b..20739f746bc4 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -216,6 +216,7 @@ struct symbol *machine__find_kernel_function_by_name(struct 
machine *machine,
 
 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, symbol_filter_t 
filter);
-- 
2.7.4

[GIT PULL 0/2] perf/urgent improvement and fix

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling,

- Arnaldo

Build results (some more images added):

  # perf stat dm
  alpine:3.4: Ok
  android-ndk:r12b: Ok
  centos:5: Ok
  centos:6: Ok
  centos:7: Ok
  debian:7: Ok
  debian:8: Ok
  debian:experimental: Ok
  fedora:21: Ok
  fedora:22: Ok
  fedora:23: Ok
  fedora:24: Ok
  fedora:rawhide: Ok
  mageia:5: Ok
  opensuse:13.2: Ok
  opensuse:42.1: Ok
  ubuntu:14.04.4: Ok
  ubuntu:15.10: Ok
  ubuntu:16.04: Ok
  ubuntu:16.04-x-arm64: Ok
  ubuntu:16.04-x-armhf: Ok
  ubuntu:16.04-x-powerpc64: Ok
  ubuntu:16.04-x-powerpc64el: Ok
  ubuntu:16.04-x-s390: Ok

The following changes since commit 674d2d69b14f677a771ceec4b48bfade94a0c5f1:

  Merge tag 'perf-core-for-mingo-20160725' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
(2016-07-25 19:48:41 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo-20160726

for you to fetch changes up to 203d8a4aa6edf2c19206316d439ec5dae52ce581:

  perf s390: Fix 'start' address of module's map (2016-07-26 16:46:12 -0300)


perf/urgent fixes:

- Fix obtaining the 'start' address for a kernel module on s390, where
  .text doesn't coincides with the start of the module as reported on
  /proc/modules (Song Shan Gong)

- Use official ELF e_machine value for BPF objects generated via perf + LLVM
  when specifying BPF scriptlet in 'perf record/trace --event' (Wang Nan)

Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>


Song Shan Gong (1):
  perf s390: Fix 'start' address of module's map

Wang Nan (1):
  tools lib bpf: Use official ELF e_machine value

 tools/lib/bpf/libbpf.c  |  7 ++-
 tools/perf/arch/s390/util/Build |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++
 tools/perf/util/machine.c   |  8 
 tools/perf/util/machine.h   |  1 +
 5 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/arch/s390/util/machine.c

[GIT PULL 0/2] perf/urgent improvement and fix

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling,

- Arnaldo

Build results (some more images added):

  # perf stat dm
  alpine:3.4: Ok
  android-ndk:r12b: Ok
  centos:5: Ok
  centos:6: Ok
  centos:7: Ok
  debian:7: Ok
  debian:8: Ok
  debian:experimental: Ok
  fedora:21: Ok
  fedora:22: Ok
  fedora:23: Ok
  fedora:24: Ok
  fedora:rawhide: Ok
  mageia:5: Ok
  opensuse:13.2: Ok
  opensuse:42.1: Ok
  ubuntu:14.04.4: Ok
  ubuntu:15.10: Ok
  ubuntu:16.04: Ok
  ubuntu:16.04-x-arm64: Ok
  ubuntu:16.04-x-armhf: Ok
  ubuntu:16.04-x-powerpc64: Ok
  ubuntu:16.04-x-powerpc64el: Ok
  ubuntu:16.04-x-s390: Ok

The following changes since commit 674d2d69b14f677a771ceec4b48bfade94a0c5f1:

  Merge tag 'perf-core-for-mingo-20160725' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
(2016-07-25 19:48:41 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo-20160726

for you to fetch changes up to 203d8a4aa6edf2c19206316d439ec5dae52ce581:

  perf s390: Fix 'start' address of module's map (2016-07-26 16:46:12 -0300)


perf/urgent fixes:

- Fix obtaining the 'start' address for a kernel module on s390, where
  .text doesn't coincides with the start of the module as reported on
  /proc/modules (Song Shan Gong)

- Use official ELF e_machine value for BPF objects generated via perf + LLVM
  when specifying BPF scriptlet in 'perf record/trace --event' (Wang Nan)

Signed-off-by: Arnaldo Carvalho de Melo 


Song Shan Gong (1):
  perf s390: Fix 'start' address of module's map

Wang Nan (1):
  tools lib bpf: Use official ELF e_machine value

 tools/lib/bpf/libbpf.c  |  7 ++-
 tools/perf/arch/s390/util/Build |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++
 tools/perf/util/machine.c   |  8 
 tools/perf/util/machine.h   |  1 +
 5 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/arch/s390/util/machine.c

[GIT PULL] ACPI changes for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.8-rc1

to receive core ACPI code updates for v4.8-rc1 with top-most commit
54d0b14ad7cc4ff3c710f092a93638f359c1b14b

 Merge branches 'acpi-drivers', 'acpi-misc' and 'acpi-tools'

on top of commit 523d939ef98fd712632d93a5a2b588e477a7565e

 Linux 4.7

The new feaures here are the support for ACPI overlays (allowing
ACPI tables to be loaded at any time from EFI variables or via
configfs) and the LPI (Low-Power Idle) support.  Also notable
is the ACPI-based NUMA support for ARM64.

Apart from that we have two new drivers, for the DPTF (Dynamic
Power and Thermal Framework) power participant device and for the
Intel Broxton WhiskeyCove PMIC, some more PMIC-related changes,
support for the Boot Error Record Table (BERT) in APEI and support
for platform-initiated graceful shutdown.

Plus two new pieces of documentation and usual assorted fixes and
cleanups in quite a few places.

Specifics:

 - Support for ACPI SSDT overlays allowing Secondary System
   Description Tables (SSDTs) to be loaded at any time from EFI
   variables or via configfs (Octavian Purdila, Mika Westerberg).

 - Support for the ACPI LPI (Low-Power Idle) feature introduced in
   ACPI 6.0 and allowing processor idle states to be represented in
   ACPI tables in a hierarchical way (with the help of Processor
   Container objects) and support for ACPI idle states management
   on ARM64, based on LPI (Sudeep Holla).

 - General improvements of ACPI support for NUMA and ARM64 support
   for ACPI-based NUMA (Hanjun Guo, David Daney, Robert Richter).

 - General improvements of the ACPI table upgrade mechanism and
   ARM64 support for that feature (Aleksey Makarov, Jon Masters).

 - Support for the Boot Error Record Table (BERT) in APEI and
   improvements of kernel messages printed by the error injection
   code (Huang Ying, Borislav Petkov).

 - New driver for the Intel Broxton WhiskeyCove PMIC operation
   region and support for the REGS operation region on Broxton,
   PMIC code cleanups (Bin Gao, Felipe Balbi, Paul Gortmaker).

 - New driver for the power participant device which is part of the
   Dynamic Power and Thermal Framework (DPTF) and DPTF-related code
   reorganization (Srinivas Pandruvada).

 - Support for the platform-initiated graceful shutdown feature
   introduced in ACPI 6.1 (Prashanth Prakash).

 - ACPI button driver update related to lid input events generated
   automatically on initialization and system resume that have been
   problematic for some time (Lv Zheng).

 - ACPI EC driver cleanups (Lv Zheng).

 - Documentation of the ACPICA release automation process and the
   in-kernel ACPI AML debugger (Lv Zheng).

 - New blacklist entry and two fixes for the ACPI backlight driver
   (Alex Hung, Arvind Yadav, Ralf Gerbig).

 - Cleanups of the ACPI pci_slot driver (Joe Perches, Paul Gortmaker).

 - ACPI CPPC code changes to make it more robust against possible
   defects in ACPI tables and new symbol definitions for PCC (Hoan
   Tran).

 - System reboot code modification to execute the ACPI _PTS (Prepare
   To Sleep) method in addition to _TTS (Ocean He).

 - ACPICA-related change to carry out lock ordering checks in ACPICA
   if ACPICA debug is enabled in the kernel (Lv Zheng).

 - Assorted minor fixes and cleanups (Andy Shevchenko, Baoquan He,
   Bhaktipriya Shridhar, Paul Gortmaker, Rafael Wysocki).

Thanks!

---

Aleksey Makarov (4):
  ACPI / tables: table upgrade: use cacheable map for tables
  ACPI / tables: table upgrade: refactor function definitions
  ACPI / tables: move arch-specific symbol to asm/acpi.h
  ACPI / tables: introduce ARCH_HAS_ACPI_TABLE_UPGRADE

Alex Hung (1):
  ACPI / video: skip evaluating _DOD when it does not exist

Andy Shevchenko (1):
  tools/acpi: use CROSS_COMPILE to define prefix

Arvind Yadav (1):
  ACPI / video: Dummy acpi_video_register should return error code

Baoquan He (1):
  ACPI / bus: Correct the comments about acpi_subsystem_init()

Bhaktipriya Shridhar (1):
  ACPI / thermal: Remove create_workqueue()

Bin Gao (2):
  ACPI / PMIC: modify the pen function signature to take bit field
  ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMIC

Borislav Petkov (2):
  ACPI / einj: Convert EINJ_PFX to proper pr_fmt
  ACPI / einj: Make error paths more talkative

David Daney (4):
  arm64, NUMA: Cleanup NUMA disabled messages
  ACPI / NUMA: move bad_srat() and srat_disabled() to drivers/acpi/numa.c
  ACPI / NUMA: Improve SRAT error detection and add messages
  ACPI / processor: Add acpi_map_madt_entry()

Felipe Balbi (2):
  ACPI / PMIC: intel: add REGS operation region support
  ACPI / PMIC: intel: initialize result to 0

Hanjun Guo (10):
  ACPI / NUMA: Use pr_fmt() instead of printk
  ACPI / NUMA: Replace ACPI_DEBUG_PRINT() with pr_debug()
  ACPI / NUMA: remove duplicate NULL check
 

[GIT PULL] ACPI changes for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.8-rc1

to receive core ACPI code updates for v4.8-rc1 with top-most commit
54d0b14ad7cc4ff3c710f092a93638f359c1b14b

 Merge branches 'acpi-drivers', 'acpi-misc' and 'acpi-tools'

on top of commit 523d939ef98fd712632d93a5a2b588e477a7565e

 Linux 4.7

The new feaures here are the support for ACPI overlays (allowing
ACPI tables to be loaded at any time from EFI variables or via
configfs) and the LPI (Low-Power Idle) support.  Also notable
is the ACPI-based NUMA support for ARM64.

Apart from that we have two new drivers, for the DPTF (Dynamic
Power and Thermal Framework) power participant device and for the
Intel Broxton WhiskeyCove PMIC, some more PMIC-related changes,
support for the Boot Error Record Table (BERT) in APEI and support
for platform-initiated graceful shutdown.

Plus two new pieces of documentation and usual assorted fixes and
cleanups in quite a few places.

Specifics:

 - Support for ACPI SSDT overlays allowing Secondary System
   Description Tables (SSDTs) to be loaded at any time from EFI
   variables or via configfs (Octavian Purdila, Mika Westerberg).

 - Support for the ACPI LPI (Low-Power Idle) feature introduced in
   ACPI 6.0 and allowing processor idle states to be represented in
   ACPI tables in a hierarchical way (with the help of Processor
   Container objects) and support for ACPI idle states management
   on ARM64, based on LPI (Sudeep Holla).

 - General improvements of ACPI support for NUMA and ARM64 support
   for ACPI-based NUMA (Hanjun Guo, David Daney, Robert Richter).

 - General improvements of the ACPI table upgrade mechanism and
   ARM64 support for that feature (Aleksey Makarov, Jon Masters).

 - Support for the Boot Error Record Table (BERT) in APEI and
   improvements of kernel messages printed by the error injection
   code (Huang Ying, Borislav Petkov).

 - New driver for the Intel Broxton WhiskeyCove PMIC operation
   region and support for the REGS operation region on Broxton,
   PMIC code cleanups (Bin Gao, Felipe Balbi, Paul Gortmaker).

 - New driver for the power participant device which is part of the
   Dynamic Power and Thermal Framework (DPTF) and DPTF-related code
   reorganization (Srinivas Pandruvada).

 - Support for the platform-initiated graceful shutdown feature
   introduced in ACPI 6.1 (Prashanth Prakash).

 - ACPI button driver update related to lid input events generated
   automatically on initialization and system resume that have been
   problematic for some time (Lv Zheng).

 - ACPI EC driver cleanups (Lv Zheng).

 - Documentation of the ACPICA release automation process and the
   in-kernel ACPI AML debugger (Lv Zheng).

 - New blacklist entry and two fixes for the ACPI backlight driver
   (Alex Hung, Arvind Yadav, Ralf Gerbig).

 - Cleanups of the ACPI pci_slot driver (Joe Perches, Paul Gortmaker).

 - ACPI CPPC code changes to make it more robust against possible
   defects in ACPI tables and new symbol definitions for PCC (Hoan
   Tran).

 - System reboot code modification to execute the ACPI _PTS (Prepare
   To Sleep) method in addition to _TTS (Ocean He).

 - ACPICA-related change to carry out lock ordering checks in ACPICA
   if ACPICA debug is enabled in the kernel (Lv Zheng).

 - Assorted minor fixes and cleanups (Andy Shevchenko, Baoquan He,
   Bhaktipriya Shridhar, Paul Gortmaker, Rafael Wysocki).

Thanks!

---

Aleksey Makarov (4):
  ACPI / tables: table upgrade: use cacheable map for tables
  ACPI / tables: table upgrade: refactor function definitions
  ACPI / tables: move arch-specific symbol to asm/acpi.h
  ACPI / tables: introduce ARCH_HAS_ACPI_TABLE_UPGRADE

Alex Hung (1):
  ACPI / video: skip evaluating _DOD when it does not exist

Andy Shevchenko (1):
  tools/acpi: use CROSS_COMPILE to define prefix

Arvind Yadav (1):
  ACPI / video: Dummy acpi_video_register should return error code

Baoquan He (1):
  ACPI / bus: Correct the comments about acpi_subsystem_init()

Bhaktipriya Shridhar (1):
  ACPI / thermal: Remove create_workqueue()

Bin Gao (2):
  ACPI / PMIC: modify the pen function signature to take bit field
  ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMIC

Borislav Petkov (2):
  ACPI / einj: Convert EINJ_PFX to proper pr_fmt
  ACPI / einj: Make error paths more talkative

David Daney (4):
  arm64, NUMA: Cleanup NUMA disabled messages
  ACPI / NUMA: move bad_srat() and srat_disabled() to drivers/acpi/numa.c
  ACPI / NUMA: Improve SRAT error detection and add messages
  ACPI / processor: Add acpi_map_madt_entry()

Felipe Balbi (2):
  ACPI / PMIC: intel: add REGS operation region support
  ACPI / PMIC: intel: initialize result to 0

Hanjun Guo (10):
  ACPI / NUMA: Use pr_fmt() instead of printk
  ACPI / NUMA: Replace ACPI_DEBUG_PRINT() with pr_debug()
  ACPI / NUMA: remove duplicate NULL check
 

Re: [RESEND][PATCH] kbuild: Abort build on bad stack protector flag

[Michal Marek]

On Tue, Jul 12, 2016 at 03:30:43PM -0700, Kees Cook wrote:
> Before, the stack protector flag was sanity checked before .config had
> been reprocessed. This meant the build couldn't be aborted early, and
> only a warning could be emitted followed later by the compiler blowing
> up with an unknown flag. This has caused a lot of confusion over time,
> so this splits the flag selection from sanity checking and performs the
> sanity checking after the make has been restarted from a reprocessed
> .config, so builds can be aborted as early as possible now.
> 
> Additionally moves the x86-specific sanity check to the same location,
> since it suffered from the same warn-then-wait-for-compiler-failure
> problem.
> 
> Signed-off-by: Kees Cook 

Hi Kees,

sorry for the late review.


> +# Find arch-specific stack protector compiler sanity-checking script.
> +ifdef CONFIG_CC_STACKPROTECTOR
> +  stackp-path := 
> $(srctree)/scripts/gcc-$(ARCH)_$(BITS)-has-stack-protector.sh

You need to use SRCARCH here if you want "x86" on x86.


> +  ifneq ($(wildcard $(stackp-path)),)
> +stackp-check := $(stackp-path)
> +  endif

stackp-check := $(wildcard $(stackp-path))

is more straightforward. But the long version is correct as well.

Michal

Re: [RESEND][PATCH] kbuild: Abort build on bad stack protector flag

[Michal Marek]

On Tue, Jul 12, 2016 at 03:30:43PM -0700, Kees Cook wrote:
> Before, the stack protector flag was sanity checked before .config had
> been reprocessed. This meant the build couldn't be aborted early, and
> only a warning could be emitted followed later by the compiler blowing
> up with an unknown flag. This has caused a lot of confusion over time,
> so this splits the flag selection from sanity checking and performs the
> sanity checking after the make has been restarted from a reprocessed
> .config, so builds can be aborted as early as possible now.
> 
> Additionally moves the x86-specific sanity check to the same location,
> since it suffered from the same warn-then-wait-for-compiler-failure
> problem.
> 
> Signed-off-by: Kees Cook 

Hi Kees,

sorry for the late review.


> +# Find arch-specific stack protector compiler sanity-checking script.
> +ifdef CONFIG_CC_STACKPROTECTOR
> +  stackp-path := 
> $(srctree)/scripts/gcc-$(ARCH)_$(BITS)-has-stack-protector.sh

You need to use SRCARCH here if you want "x86" on x86.


> +  ifneq ($(wildcard $(stackp-path)),)
> +stackp-check := $(stackp-path)
> +  endif

stackp-check := $(wildcard $(stackp-path))

is more straightforward. But the long version is correct as well.

Michal

RE: [PATCH] [RFC] Introduce mmap randomization

[Roberts, William C]

> -Original Message-
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On
> Behalf Of Jason Cooper
> Sent: Tuesday, July 26, 2016 2:00 PM
> To: Roberts, William C 
> Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; kernel-
> harden...@lists.openwall.com; a...@linux-foundation.org;
> keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> Hi William,
> 
> On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > > From: Jason Cooper [mailto:ja...@lakedaemon.net] On Tue, Jul 26,
> > > > 2016 at 11:22:26AM -0700, william.c.robe...@intel.com wrote:
> > > > > Performance Measurements:
> > > > > Using strace with -T option and filtering for mmap on the
> > > > > program ls shows a slowdown of approximate 3.7%
> > > >
> > > > I think it would be helpful to show the effect on the resulting object 
> > > > code.
> > >
> > > Do you mean the maps of the process? I have some captures for
> > > whoopsie on my Ubuntu system I can share.
> 
> No, I mean changes to mm/mmap.o.

Sure I can post the objdump of that, do you just want a diff of old vs new?

> 
> > > One thing I didn't make clear in my commit message is why this is
> > > good. Right now, if you know An address within in a process, you
> > > know all offsets done with mmap(). For instance, an offset To libX
> > > can yield libY by adding/subtracting an offset. This is meant to
> > > make rops a bit harder, or In general any mapping offset mmore difficult 
> > > to
> find/guess.
> 
> Are you able to quantify how many bits of entropy you're imposing on the
> attacker?  Is this a chair in the hallway or a significant increase in the 
> chances of
> crashing the program before finding the desired address?

I'd likely need to take a small sample of programs and examine them, especially 
considering
That as gaps are harder to find, it forces the randomization down and 
randomization can
Be directly altered with length on mmap(), versus randomize_addr() which didn't 
have this
restriction but OOM'd do to fragmented easier.

> 
> thx,
> 
> Jason.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to
> majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

RE: [PATCH] [RFC] Introduce mmap randomization

[Roberts, William C]

> -Original Message-
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On
> Behalf Of Jason Cooper
> Sent: Tuesday, July 26, 2016 2:00 PM
> To: Roberts, William C 
> Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; kernel-
> harden...@lists.openwall.com; a...@linux-foundation.org;
> keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> Hi William,
> 
> On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > > From: Jason Cooper [mailto:ja...@lakedaemon.net] On Tue, Jul 26,
> > > > 2016 at 11:22:26AM -0700, william.c.robe...@intel.com wrote:
> > > > > Performance Measurements:
> > > > > Using strace with -T option and filtering for mmap on the
> > > > > program ls shows a slowdown of approximate 3.7%
> > > >
> > > > I think it would be helpful to show the effect on the resulting object 
> > > > code.
> > >
> > > Do you mean the maps of the process? I have some captures for
> > > whoopsie on my Ubuntu system I can share.
> 
> No, I mean changes to mm/mmap.o.

Sure I can post the objdump of that, do you just want a diff of old vs new?

> 
> > > One thing I didn't make clear in my commit message is why this is
> > > good. Right now, if you know An address within in a process, you
> > > know all offsets done with mmap(). For instance, an offset To libX
> > > can yield libY by adding/subtracting an offset. This is meant to
> > > make rops a bit harder, or In general any mapping offset mmore difficult 
> > > to
> find/guess.
> 
> Are you able to quantify how many bits of entropy you're imposing on the
> attacker?  Is this a chair in the hallway or a significant increase in the 
> chances of
> crashing the program before finding the desired address?

I'd likely need to take a small sample of programs and examine them, especially 
considering
That as gaps are harder to find, it forces the randomization down and 
randomization can
Be directly altered with length on mmap(), versus randomize_addr() which didn't 
have this
restriction but OOM'd do to fragmented easier.

> 
> thx,
> 
> Jason.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to
> majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH v2 1/4] iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub.

[Jonathan Cameron]

On 25/07/16 09:38, Enric Balletbo Serra wrote:
> Hi Jonathan,
> 
> Many thanks for the review, some answers below.
> 
> 2016-07-24 15:51 GMT+02:00 Jonathan Cameron :
>> On 20/07/16 10:22, Enric Balletbo i Serra wrote:
>>> Add the core functions to be able to support the sensors attached behind
>>> the ChromeOS Embedded Controller and used by other IIO cros-ec sensor
>>> drivers.
>>>
>>> The cros_ec_sensor_core driver matches with current driver in ChromeOS
>>> 4.4 tree, so it includes all the fixes at the moment. The support for
>>> this driver was made by Gwendal Grignou. The original patch and all the
>>> fixes has been squashed and rebased on top of mainline.
>>>
>>> Signed-off-by: Gwendal Grignou 
>>> Signed-off-by: Guenter Roeck 
>>> [eballetbo: split, squash and rebase on top of mainline the patches
>>> found in ChromeOS tree]
>>> Signed-off-by: Enric Balletbo i Serra 
>> Few minor bits inline.  I'm happy enough with the ABI (except that I would
>> like a justification for why userspace needs the id one)
>> We should see if anyone else has comments on that.
>>
>> The location one may well become more general in future (to cover other
>> devices).
>>
>> Jonathan
>>> ---
>>>
>>> Changes since v1:
>>>   - Check kernel-doc documentation.
>>>   - Bring this in as an when you need it in the rest of the series.
>>>   - Fix some spelling mistakes.
>>>   - Include ABI documentation.
>>>   - Be more careful with buffer sizes (sprintf -> snprintf)
>>>   - Add cros_ec_sensors prefix to all function.
>>>   - Check return values on some functions.
>>>
>>>  Documentation/ABI/testing/sysfs-bus-iio-cros-ec|  25 +
>>>  drivers/iio/common/Kconfig |   1 +
>>>  drivers/iio/common/Makefile|   1 +
>>>  drivers/iio/common/cros_ec_sensors/Kconfig |  14 +
>>>  drivers/iio/common/cros_ec_sensors/Makefile|   5 +
>>>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  | 505 
>>> +
>>>  .../common/cros_ec_sensors/cros_ec_sensors_core.h  | 177 
>>>  include/linux/mfd/cros_ec.h|   9 +
>>>  include/linux/mfd/cros_ec_commands.h   |  99 +++-
>>>  9 files changed, 831 insertions(+), 5 deletions(-)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Kconfig
>>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Makefile
>>>  create mode 100644 
>>> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>>>  create mode 100644 
>>> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>> new file mode 100644
>>> index 000..3e626b6
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>> @@ -0,0 +1,25 @@
>>> +What:/sys/bus/iio/devices/iio:deviceX/calibrate
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> + Writing '1' will perform a FOC (Fast Online Calibration). The
>>> +corresponding calibration offsets can be read from 
>>> *_calibbias
>>> +entries.
>> This one is fine as far as I'm concerned.
>>> +
>>> +What:/sys/bus/iio/devices/iio:deviceX/id
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> +The id attribute holds an unique number for the motion 
>>> sensor
>>> +identification, as reported by the ChromeOS Embedded 
>>> Controller.
>> Mostly with these, we've just spat the out to the kernel logs as dev_info
>> during startup.
>>
>> Any reason this needs to be more explictly exposed to userspace?
> 
> After think a bit more about this, and to be honest, I'm not sure if
> this is really useful to be exposed to userspace. The only use case
> that I'm thinking is that some userspace app uses it to uniquely
> identify the sensors that hang from the ChromeOS Embedded Controller,
> but I'm not sure about this exist. I'll investigate a bit more for if
> I find a good justification, otherwise I'll remove this.
> 
> Maybe someone from chromium can give us more opinions?
> 
>>> +
>>> +What:/sys/bus/iio/devices/iio:deviceX/location
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> + This attribute returns a string with the physical location 
>>> where
>>> +the motion sensor is placed. For example, in a laptop a 
>>> motion
>>> +sensor can be located on the base or on the lid.
>> Interesting...
>>
>> We'll probably want to ultimately use this one more generally.  This probably
>> 

Re: [PATCH v2 1/4] iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub.

[Jonathan Cameron]

On 25/07/16 09:38, Enric Balletbo Serra wrote:
> Hi Jonathan,
> 
> Many thanks for the review, some answers below.
> 
> 2016-07-24 15:51 GMT+02:00 Jonathan Cameron :
>> On 20/07/16 10:22, Enric Balletbo i Serra wrote:
>>> Add the core functions to be able to support the sensors attached behind
>>> the ChromeOS Embedded Controller and used by other IIO cros-ec sensor
>>> drivers.
>>>
>>> The cros_ec_sensor_core driver matches with current driver in ChromeOS
>>> 4.4 tree, so it includes all the fixes at the moment. The support for
>>> this driver was made by Gwendal Grignou. The original patch and all the
>>> fixes has been squashed and rebased on top of mainline.
>>>
>>> Signed-off-by: Gwendal Grignou 
>>> Signed-off-by: Guenter Roeck 
>>> [eballetbo: split, squash and rebase on top of mainline the patches
>>> found in ChromeOS tree]
>>> Signed-off-by: Enric Balletbo i Serra 
>> Few minor bits inline.  I'm happy enough with the ABI (except that I would
>> like a justification for why userspace needs the id one)
>> We should see if anyone else has comments on that.
>>
>> The location one may well become more general in future (to cover other
>> devices).
>>
>> Jonathan
>>> ---
>>>
>>> Changes since v1:
>>>   - Check kernel-doc documentation.
>>>   - Bring this in as an when you need it in the rest of the series.
>>>   - Fix some spelling mistakes.
>>>   - Include ABI documentation.
>>>   - Be more careful with buffer sizes (sprintf -> snprintf)
>>>   - Add cros_ec_sensors prefix to all function.
>>>   - Check return values on some functions.
>>>
>>>  Documentation/ABI/testing/sysfs-bus-iio-cros-ec|  25 +
>>>  drivers/iio/common/Kconfig |   1 +
>>>  drivers/iio/common/Makefile|   1 +
>>>  drivers/iio/common/cros_ec_sensors/Kconfig |  14 +
>>>  drivers/iio/common/cros_ec_sensors/Makefile|   5 +
>>>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  | 505 
>>> +
>>>  .../common/cros_ec_sensors/cros_ec_sensors_core.h  | 177 
>>>  include/linux/mfd/cros_ec.h|   9 +
>>>  include/linux/mfd/cros_ec_commands.h   |  99 +++-
>>>  9 files changed, 831 insertions(+), 5 deletions(-)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Kconfig
>>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Makefile
>>>  create mode 100644 
>>> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>>>  create mode 100644 
>>> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>> new file mode 100644
>>> index 000..3e626b6
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
>>> @@ -0,0 +1,25 @@
>>> +What:/sys/bus/iio/devices/iio:deviceX/calibrate
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> + Writing '1' will perform a FOC (Fast Online Calibration). The
>>> +corresponding calibration offsets can be read from 
>>> *_calibbias
>>> +entries.
>> This one is fine as far as I'm concerned.
>>> +
>>> +What:/sys/bus/iio/devices/iio:deviceX/id
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> +The id attribute holds an unique number for the motion 
>>> sensor
>>> +identification, as reported by the ChromeOS Embedded 
>>> Controller.
>> Mostly with these, we've just spat the out to the kernel logs as dev_info
>> during startup.
>>
>> Any reason this needs to be more explictly exposed to userspace?
> 
> After think a bit more about this, and to be honest, I'm not sure if
> this is really useful to be exposed to userspace. The only use case
> that I'm thinking is that some userspace app uses it to uniquely
> identify the sensors that hang from the ChromeOS Embedded Controller,
> but I'm not sure about this exist. I'll investigate a bit more for if
> I find a good justification, otherwise I'll remove this.
> 
> Maybe someone from chromium can give us more opinions?
> 
>>> +
>>> +What:/sys/bus/iio/devices/iio:deviceX/location
>>> +Date:July 2015
>>> +KernelVersion:   4.7
>>> +Contact: linux-...@vger.kernel.org
>>> +Description:
>>> + This attribute returns a string with the physical location 
>>> where
>>> +the motion sensor is placed. For example, in a laptop a 
>>> motion
>>> +sensor can be located on the base or on the lid.
>> Interesting...
>>
>> We'll probably want to ultimately use this one more generally.  This probably
>> won't be the last sensor where we have some means of finding this out!
>>
> Ok, I will 

RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs

[Mario_Limonciello]

> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, July 19, 2016 9:48 AM
> To: 'Jean Delvare' ; Hung, Allen 
> Cc: Jean Delvare ; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
> strings to sysfs
> 
> Hi Jean,
> 
> I worked with Allen on this concept, so I've got some comments below.
> 
> > -Original Message-
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen 
> > Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> > Limonciello, Mario 
> > Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
> > strings to sysfs
> >
> > Hello Allen,
> >
> > On Thu, 14 Jul 2016 16:01:23 +0800, Allen Hung wrote:
> > > The oem strings in DMI system identification information of the BIOS
> have
> > > been parsed and stored as dmi devices in dmi_scan.c but they are not
> > > exported to userspace via sysfs.
> >
> > They are intended for internal consumption by the kernel drivers.
> >
> > > The patch intends to export oem strings to sysfs device /sys/class/dmi/id.
> > > As the number of oem strings are dynamic, a group "oem" is added to the
> > > device and the strings will be added to the group as string1, string2, 
> > > ...,
> > > and stringN.
> >
> > What is the use case? You can already get these strings easily using
> > dmidecode:
> >
> > # dmidecode -qt 11
> > OEM Strings
> > String 1: Dell System
> > String 2: 1[05A4]
> > String 3: 3[1.0]
> > String 4: 12[www.dell.com]
> > String 5: 14[1]
> > String 6: 15[3]
> > String 7:
> >
> > If needed, a dedicated option could be added to dmidecode to extract
> > specific OEM strings. Or existing option -s could be extended for that
> > purpose.
> 
> The main purpose was to be able to parse these easily from userspace
> without needing dmidecode installed and handling its output
> (with tools such as grep, sed, and awk).
> 
> For example in an initramfs, typically dmidecode isn't included, but there
> is value to being able to make decisions on things related to the values of
> those OEM strings.
> 
> Instead this allows userspace to iterate the oem/ directory and directly
> look at the values of these strings.
> 
> >
> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> >
> 
> Allen had a mistake in that submission when he was refactoring it prior to
> LKML submission.
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/
> 
> > One comment below though:
> >
> > >
> > > Signed-off-by: Allen Hung 
> > > ---
> > >  drivers/firmware/dmi-id.c | 108
> > ++
> > >  1 file changed, 108 insertions(+)
> > >
> > > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > > index 44c0139..f284a07 100644
> > > --- a/drivers/firmware/dmi-id.c
> > > +++ b/drivers/firmware/dmi-id.c
> > > (...)
> > > +static int __init dmi_id_init_oem_attr_group(void)
> > > +{
> > > + int i, ret;
> > > + const struct dmi_device *dev;
> > > + struct dmi_oem_attribute *oa, *tmp;
> > > + struct device_attribute dev_attr_tmpl =
> > > + __ATTR(, 0444, sys_dmi_oem_show, NULL);
> >
> > I'd be very careful about permissions. OEM strings could contain pretty
> > much everything, including serial numbers or passwords. Making these
> > files world-readable doesn't strike me as the best of the ideas.
> >
> 
> At least on Dell systems, the values in these strings are OK to be world
> readable, but I understand this concern and agree that Allen should adjust
> these permissions in the next version if you agree with the concept of this
> patch.
> 
> Thanks,

Hi jean,

Did you have any comments about Allen's updated patch or my above
comments?

If necessary, Allen can resend with the fix to OEM strings permissions
and we can discuss further then.

Thanks,

RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs

[Mario_Limonciello]

> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, July 19, 2016 9:48 AM
> To: 'Jean Delvare' ; Hung, Allen 
> Cc: Jean Delvare ; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
> strings to sysfs
> 
> Hi Jean,
> 
> I worked with Allen on this concept, so I've got some comments below.
> 
> > -Original Message-
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen 
> > Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> > Limonciello, Mario 
> > Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
> > strings to sysfs
> >
> > Hello Allen,
> >
> > On Thu, 14 Jul 2016 16:01:23 +0800, Allen Hung wrote:
> > > The oem strings in DMI system identification information of the BIOS
> have
> > > been parsed and stored as dmi devices in dmi_scan.c but they are not
> > > exported to userspace via sysfs.
> >
> > They are intended for internal consumption by the kernel drivers.
> >
> > > The patch intends to export oem strings to sysfs device /sys/class/dmi/id.
> > > As the number of oem strings are dynamic, a group "oem" is added to the
> > > device and the strings will be added to the group as string1, string2, 
> > > ...,
> > > and stringN.
> >
> > What is the use case? You can already get these strings easily using
> > dmidecode:
> >
> > # dmidecode -qt 11
> > OEM Strings
> > String 1: Dell System
> > String 2: 1[05A4]
> > String 3: 3[1.0]
> > String 4: 12[www.dell.com]
> > String 5: 14[1]
> > String 6: 15[3]
> > String 7:
> >
> > If needed, a dedicated option could be added to dmidecode to extract
> > specific OEM strings. Or existing option -s could be extended for that
> > purpose.
> 
> The main purpose was to be able to parse these easily from userspace
> without needing dmidecode installed and handling its output
> (with tools such as grep, sed, and awk).
> 
> For example in an initramfs, typically dmidecode isn't included, but there
> is value to being able to make decisions on things related to the values of
> those OEM strings.
> 
> Instead this allows userspace to iterate the oem/ directory and directly
> look at the values of these strings.
> 
> >
> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> >
> 
> Allen had a mistake in that submission when he was refactoring it prior to
> LKML submission.
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/
> 
> > One comment below though:
> >
> > >
> > > Signed-off-by: Allen Hung 
> > > ---
> > >  drivers/firmware/dmi-id.c | 108
> > ++
> > >  1 file changed, 108 insertions(+)
> > >
> > > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > > index 44c0139..f284a07 100644
> > > --- a/drivers/firmware/dmi-id.c
> > > +++ b/drivers/firmware/dmi-id.c
> > > (...)
> > > +static int __init dmi_id_init_oem_attr_group(void)
> > > +{
> > > + int i, ret;
> > > + const struct dmi_device *dev;
> > > + struct dmi_oem_attribute *oa, *tmp;
> > > + struct device_attribute dev_attr_tmpl =
> > > + __ATTR(, 0444, sys_dmi_oem_show, NULL);
> >
> > I'd be very careful about permissions. OEM strings could contain pretty
> > much everything, including serial numbers or passwords. Making these
> > files world-readable doesn't strike me as the best of the ideas.
> >
> 
> At least on Dell systems, the values in these strings are OK to be world
> readable, but I understand this concern and agree that Allen should adjust
> these permissions in the next version if you agree with the concept of this
> patch.
> 
> Thanks,

Hi jean,

Did you have any comments about Allen's updated patch or my above
comments?

If necessary, Allen can resend with the fix to OEM strings permissions
and we can discuss further then.

Thanks,

RE: [PATCH] [RFC] Introduce mmap randomization

[Roberts, William C]

> -Original Message-
> From: Nick Kralevich [mailto:n...@google.com]
> Sent: Tuesday, July 26, 2016 1:41 PM
> To: Roberts, William C 
> Cc: ja...@lakedaemon.net; linux...@vger.kernel.org; lkml  ker...@vger.kernel.org>; kernel-harden...@lists.openwall.com; Andrew
> Morton ; Kees Cook ;
> Greg KH ; Jeffrey Vander Stoep
> ; saly...@android.com; Daniel Cashman
> 
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> My apologies in advance if I misunderstand the purposes of this patch.
> 
> IIUC, this patch adds a random gap between various mmap() mappings, with the
> goal of ensuring that both the mmap base address and gaps between pages are
> randomized.
> 
> If that's the goal, please note that this behavior has caused significant
> performance problems to Android in the past. Specifically, random gaps between
> mmap()ed regions causes memory space fragmentation. After a program runs for
> a long time, the ability to find large contiguous blocks of memory becomes
> impossible, and mmap()s fail due to lack of a large enough address space.

Yes and fragmentation is definitely a problem here. Especially when the mmaps()
are not a consistent length for program life.

> 
> This isn't just a theoretical concern. Android actually hit this on kernels 
> prior to
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa46
> 6780a754154531b44c2086f6618cee3a8
> . Before that patch, the gaps between mmap()ed pages were randomized.
> See the discussion at:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2011-
> November/073082.html
>   http://marc.info/?t=13207095745=1=2
> 
> We ended up having to work around this problem in the following commits:
> 
> 
> https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f59
> 2d56caab5e2a259c
>   https://android.googlesource.com/platform/art/+/51e5386
>   https://android.googlesource.com/platform/art/+/f94b781
> 
> If this behavior was re-introduced, it's likely to cause hard-to-reproduce
> problems, and I suspect Android based distributions would tend to disable this
> feature either globally, or for applications which make a large number of 
> mmap()
> calls.

Yeah and this is the issue I want to see if we can overcome. I see the biggest 
benefit
being on libraries loaded by dl. Perhaps a random flag and modify to linkers. 
Im just
spit balling here and collecting the feedback, like this. Thanks for the 
detail, that
helps a lot.

> 
> -- Nick
> 
> 
> 
> On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
> > From: William Roberts 
> >
> > This patch introduces the ability randomize mmap locations where the
> > address is not requested, for instance when ld is allocating pages for
> > shared libraries. It chooses to randomize based on the current
> > personality for ASLR.
> >
> > Currently, allocations are done sequentially within unmapped address
> > space gaps. This may happen top down or bottom up depending on scheme.
> >
> > For instance these mmap calls produce contiguous mappings:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40026000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40027000
> >
> > Note no gap between.
> >
> > After patches:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x400b4000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40055000
> >
> > Note gap between.
> >
> > Using the test program mentioned here, that allocates fixed sized
> > blocks till exhaustion:
> > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
> > no difference was noticed in the number of allocations. Most varied
> > from run to run, but were always within a few allocations of one
> > another between patched and un-patched runs.
> >
> > Performance Measurements:
> > Using strace with -T option and filtering for mmap on the program ls
> > shows a slowdown of approximate 3.7%
> >
> > Signed-off-by: William Roberts 
> > ---
> >  mm/mmap.c | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index de2c176..7891272 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -43,6 +43,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -1582,6 +1583,24 @@ unacct_error:
> > return error;
> >  }
> >
> > +/*
> > + * Generate a random address within a range. This differs from
> > +randomize_addr() by randomizing
> > + * on len sized chunks. This helps prevent fragmentation of the virtual
> memory map.
> > + */
> > +static unsigned long randomize_mmap(unsigned long start, unsigned
> > +long end, unsigned long len) {
> > +  

RE: [PATCH] [RFC] Introduce mmap randomization

[Roberts, William C]

> -Original Message-
> From: Nick Kralevich [mailto:n...@google.com]
> Sent: Tuesday, July 26, 2016 1:41 PM
> To: Roberts, William C 
> Cc: ja...@lakedaemon.net; linux...@vger.kernel.org; lkml  ker...@vger.kernel.org>; kernel-harden...@lists.openwall.com; Andrew
> Morton ; Kees Cook ;
> Greg KH ; Jeffrey Vander Stoep
> ; saly...@android.com; Daniel Cashman
> 
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> My apologies in advance if I misunderstand the purposes of this patch.
> 
> IIUC, this patch adds a random gap between various mmap() mappings, with the
> goal of ensuring that both the mmap base address and gaps between pages are
> randomized.
> 
> If that's the goal, please note that this behavior has caused significant
> performance problems to Android in the past. Specifically, random gaps between
> mmap()ed regions causes memory space fragmentation. After a program runs for
> a long time, the ability to find large contiguous blocks of memory becomes
> impossible, and mmap()s fail due to lack of a large enough address space.

Yes and fragmentation is definitely a problem here. Especially when the mmaps()
are not a consistent length for program life.

> 
> This isn't just a theoretical concern. Android actually hit this on kernels 
> prior to
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa46
> 6780a754154531b44c2086f6618cee3a8
> . Before that patch, the gaps between mmap()ed pages were randomized.
> See the discussion at:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2011-
> November/073082.html
>   http://marc.info/?t=13207095745=1=2
> 
> We ended up having to work around this problem in the following commits:
> 
> 
> https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f59
> 2d56caab5e2a259c
>   https://android.googlesource.com/platform/art/+/51e5386
>   https://android.googlesource.com/platform/art/+/f94b781
> 
> If this behavior was re-introduced, it's likely to cause hard-to-reproduce
> problems, and I suspect Android based distributions would tend to disable this
> feature either globally, or for applications which make a large number of 
> mmap()
> calls.

Yeah and this is the issue I want to see if we can overcome. I see the biggest 
benefit
being on libraries loaded by dl. Perhaps a random flag and modify to linkers. 
Im just
spit balling here and collecting the feedback, like this. Thanks for the 
detail, that
helps a lot.

> 
> -- Nick
> 
> 
> 
> On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
> > From: William Roberts 
> >
> > This patch introduces the ability randomize mmap locations where the
> > address is not requested, for instance when ld is allocating pages for
> > shared libraries. It chooses to randomize based on the current
> > personality for ASLR.
> >
> > Currently, allocations are done sequentially within unmapped address
> > space gaps. This may happen top down or bottom up depending on scheme.
> >
> > For instance these mmap calls produce contiguous mappings:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40026000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40027000
> >
> > Note no gap between.
> >
> > After patches:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x400b4000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40055000
> >
> > Note gap between.
> >
> > Using the test program mentioned here, that allocates fixed sized
> > blocks till exhaustion:
> > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
> > no difference was noticed in the number of allocations. Most varied
> > from run to run, but were always within a few allocations of one
> > another between patched and un-patched runs.
> >
> > Performance Measurements:
> > Using strace with -T option and filtering for mmap on the program ls
> > shows a slowdown of approximate 3.7%
> >
> > Signed-off-by: William Roberts 
> > ---
> >  mm/mmap.c | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index de2c176..7891272 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -43,6 +43,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -1582,6 +1583,24 @@ unacct_error:
> > return error;
> >  }
> >
> > +/*
> > + * Generate a random address within a range. This differs from
> > +randomize_addr() by randomizing
> > + * on len sized chunks. This helps prevent fragmentation of the virtual
> memory map.
> > + */
> > +static unsigned long randomize_mmap(unsigned long start, unsigned
> > +long end, unsigned long len) {
> > +   unsigned long slots;
> > +
> > +   if ((current->personality & ADDR_NO_RANDOMIZE) ||
> !randomize_va_space)
> > +   return 0;
> > +
> > +   slots = (end - start)/len;
> > +   if (!slots)
> > + 

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 10:03:25AM +0200, Michael Kerrisk (man-pages) wrote:
> On 07/26/2016 04:54 AM, Andrew Vagin wrote:
> > On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote:
> > > "Michael Kerrisk (man-pages)"  writes:
> > 
> > [snip]
> > 
> > > [snip]
> > > > > > So, from my point of view, the important piece that was missing from
> > > > > > your commit message was the note to use readlink("/proc/self/fd/%d")
> > > > > > on the returned FDs. I think that detail needs to be part of the
> > > > > > commit message (and also the man page text). I think it even be
> > > > > > helpful to include the above program as part of the commit message:
> > > > > > it helps people more quickly grasp the API.
> > > > > 
> > > > > Please, please make the standard way to compare these things fstat.
> > > > > That is much less magic than a symlink, and a little more future 
> > > > > proof.
> > > > > Possibly even kcmp.
> > 
> > I like the idea to use kcmp to compare namespaces. I am going to add this
> > functionality to kcmp and describe all these in the man page.
> 
> Hi Andrey,
> 
> Can you briefly sketch out the proposed API and how it would be used?
> I'd find it useful to see that even before the implementation.

Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)

For example, if we want to compare pid namespaces for 1 and 2 processes:

pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")

if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");

Thanks,
Andrew
> 
> Cheers,
> 
> Michael
> 
> 
> -- 
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 10:03:25AM +0200, Michael Kerrisk (man-pages) wrote:
> On 07/26/2016 04:54 AM, Andrew Vagin wrote:
> > On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote:
> > > "Michael Kerrisk (man-pages)"  writes:
> > 
> > [snip]
> > 
> > > [snip]
> > > > > > So, from my point of view, the important piece that was missing from
> > > > > > your commit message was the note to use readlink("/proc/self/fd/%d")
> > > > > > on the returned FDs. I think that detail needs to be part of the
> > > > > > commit message (and also the man page text). I think it even be
> > > > > > helpful to include the above program as part of the commit message:
> > > > > > it helps people more quickly grasp the API.
> > > > > 
> > > > > Please, please make the standard way to compare these things fstat.
> > > > > That is much less magic than a symlink, and a little more future 
> > > > > proof.
> > > > > Possibly even kcmp.
> > 
> > I like the idea to use kcmp to compare namespaces. I am going to add this
> > functionality to kcmp and describe all these in the man page.
> 
> Hi Andrey,
> 
> Can you briefly sketch out the proposed API and how it would be used?
> I'd find it useful to see that even before the implementation.

Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)

For example, if we want to compare pid namespaces for 1 and 2 processes:

pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")

if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");

Thanks,
Andrew
> 
> Cheers,
> 
> Michael
> 
> 
> -- 
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

[GIT PULL] PNP update for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pnp-4.8-rc1

to receive a PNP subsystem update for v4.8-rc1 as commit
917c7fc264abb9c470486b157bc7252e53f68fbb

 PNP: make pnpbios core explicitly non-modular

on top of commit a99cde438de0c4c0cecc1d1af1a55a75b10bfdef

 Linux 4.7-rc6

One simple change to make the PNP core use device_initcall() instead
of module_init() to run pnpbios_thread_init() (Paul Gortmaker).

Thanks!

---

Paul Gortmaker (1):
  PNP: make pnpbios core explicitly non-modular

---

 drivers/pnp/pnpbios/core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

[GIT PULL] PNP update for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pnp-4.8-rc1

to receive a PNP subsystem update for v4.8-rc1 as commit
917c7fc264abb9c470486b157bc7252e53f68fbb

 PNP: make pnpbios core explicitly non-modular

on top of commit a99cde438de0c4c0cecc1d1af1a55a75b10bfdef

 Linux 4.7-rc6

One simple change to make the PNP core use device_initcall() instead
of module_init() to run pnpbios_thread_init() (Paul Gortmaker).

Thanks!

---

Paul Gortmaker (1):
  PNP: make pnpbios core explicitly non-modular

---

 drivers/pnp/pnpbios/core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Kees Cook]

On Tue, Jul 26, 2016 at 1:53 PM, Rafael J. Wysocki  wrote:
> On Tuesday, July 26, 2016 01:33:02 PM Kees Cook wrote:
>> On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  
>> wrote:
>> > On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
>> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
>> >> > Hi,
>> >> >
>> >> > The following commit:
>> >> >
>> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
>> >> > Author: Josh Poimboeuf 
>> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
>> >> >
>> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
>> >> >
>> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
>> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
>> >> >
>> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
>> >> >
>> >> > is reported to cause a resume-from-hibernation regression due to an 
>> >> > attempt
>> >> > to execute an NX page (we've seen quite a bit of that recently).
>> >> >
>> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
>> >> > we'll
>> >> > need to revert the above I'm afraid.
>> >>
>> >> So I can't resume properly from disk too, on the Intel laptop this time. 
>> >> Top
>> >> commit is from tip/master:
>> >>
>> >> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
>> >> Merge: a4823bbffc96 dd9506954539
>> >> Author: Ingo Molnar 
>> >> Date:   Mon Jul 25 08:39:43 2016 +0200
>> >>
>> >> Merge branch 'linus'
>> >>
>> >>
>> >> So I thought it might be Josh's patch above and reverted it. No joy.
>> >>
>> >> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
>> >> microcode loader breakage which we've been debugging. Turned that off
>> >> and machine resumes fine again.
>> >
>> > Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
>> > was no hope it would not break hibernation if you asked me.
>> >
>> >> It looks like
>> >>
>> >>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
>> >>
>> >> broke a bunch of things. Off the top of my head, we probably should make
>> >> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
>> >> was the case with ASLR previously, AFAIR.
>> >
>> > Please no.
>> >
>> > First off, it should be perfectly possible to make hibernation work along
>> > with this new variant of ASLR.  Second, quite obviously, the author of 
>> > these
>> > ASLR changes had not done sufficient research to estimate the possible
>> > impact of them.
>>
>> I think that's a bit unfair: Thomas did a lot of testing, and it has
>> been living in -next for a while.
>
> Well, with all due respect, "a lot of testing" is not quite the same thing as
> "sufficient research" IMO.
>
> It should be known (at least from experience) that hibernation on x86-64 
> doesn't
> play well with ASLR quite as a rule, so it would be good to at least check 
> that
> particular thing or CC a relevant person (ie. me).

Fair enough: we need to practice considering a wider usage model.

> Or even ask me on IRC for that matter.  Give me a heads up ahead of time.
>
> But no.  I'm still on the receiving end of the "hibernation doesn't work with
> ASLR" story which was entirely avoidable this time around.  Sigh.

I'll be sure to keep you in the loop for future x86 KASLR changes;
sorry for the new pain. :(

>> > Honestly, I don't think it is a good idea to introduce random Kconfig 
>> > options
>> > for working around cases in which the author of some changes cannot be 
>> > bothered
>> > with doing things right.  Even if that is security.
>>
>> I would agree: let's try to get this fixed soon.
>>
>> > So IMO, either we should fix the problem, or that whole new ASLR stuff 
>> > should
>> > be reverted.
>> >
>> > I think I know how to fix it, but I won't be able to get to that before the
>> > next week.  I guess it can wait till then, though.
>>
>> Thomas, will you have some time to examine this and estimate the work for a 
>> fix?
>
> FWIW, my hunch ATM is that you need to look at the "Set up the direct mapping
> from scratch" loop in set_up_temporary_mappings() and make it do the right
> thing when the new ASLR stuff is enabled.

Thanks for the pointer!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

[Andy Lutomirski]

On Tue, Jul 26, 2016 at 9:26 AM, Josh Poimboeuf  wrote:
> On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote:
>> On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf  wrote:
>> >> > Unless I'm missing something, I think it should be fine for nested NMIs,
>> >> > since they're all on the same stack.  I can try to test it.  What in
>> >> > particular are you worried about?
>> >> >
>> >>
>> >> The top of the NMI frame contains no less than *three* (SS, SP, FLAGS,
>> >> CS, IP) records.  Off the top of my head, the record that matters is
>> >> the third one, so it should be regs[-15].  If an MCE hits while this
>> >> mess is being set up, good luck unwinding *that*.  If you really want
>> >> to know, take a deep breath, read the long comment in entry_64.S after
>> >> .Lnmi_from_kernel, then give up on x86 and start hacking on some other
>> >> architecture.
>> >
>> > I did read that comment.  Fortunately there's a big difference between
>> > reading and understanding so I can go on being an ignorant x86 hacker!
>> >
>> > For nested NMIs, it does look like the stack of the exception which
>> > interrupted the first NMI would get skipped by the stack dump.  (But
>> > that's a general problem, not specific to my patch set.)
>>
>> If we end up with task -> IST -> NMI -> same IST, we're doomed and
>> we're going to crash, so it doesn't matter much whether the unwinder
>> works.  Is that what you mean?
>
> I read the NMI entry code again, and now I realize my comment was
> completely misinformed, so never mind.
>
> Is "IST -> NMI -> same IST" even possible, since the other IST's are
> higher priority than NMI?

Priority only matters for events that happen concurrently.
Synchronous things like #DB will always fire if the conditions that
trigger them are hit,

>
>> > Am I correct in understanding that there can only be one level of NMI
>> > nesting at any given time?  If so, could we make it easier on the
>> > unwinder by putting the nested NMI on a separate software stack, so the
>> > "next stack" pointers are always in the same place?  Or am I just being
>> > naive?
>>
>> I think you're being naive :)
>>
>> But we don't really need the unwinder to be 100% faithful here.  If we have:
>>
>> task stack
>> NMI
>> nested NMI
>>
>> then the nested NMI code won't call into C and thus it should be
>> impossible to ever invoke your unwinder on that state.  Instead the
>> nested NMI code will fiddle with the saved regs and return in such a
>> way that the outer NMI will be forced to loop through again.  So it
>> *should* (assuming I'm remembering all this crap correctly) be
>> sufficient to find the "outermost" pt_regs, which is sitting at
>> (struct pt_regs *)(end - 12) - 1 or thereabouts and look at it's ->sp
>> value.  This ought to be the same thing that the frame-based unwinder
>> would naturally try to do.  But if you make this change, ISTM you
>> should make it separately because it does change behavior and Linus is
>> understandably leery about that.
>
> Ok, I think that makes sense to me now.  As I understand it, the
> "outermost" RIP is the authoritative one, because it was written by the
> original NMI.  Any nested NMIs will update the original and/or iret
> RIPs, which will only ever point to NMI entry code, and so they should
> be ignored.
>
> But I think there's a case where this wouldn't work:
>
> task stack
> NMI
> IST
> stack dump
>
> If the IST interrupt hits before the NMI has a chance to update the
> outermost regs, the authoritative RIP would be the original one written
> by HW, right?

This should be impossible unless that last entry is MCE.  If we
actually fire an event that isn't MCE early in NMI entry, something
already went very wrong.

For NMI -> MCE -> stack dump, the frame-based unwinder will do better
than get_stack_info() unless get_stack_info() learns to use the
top-of-stack hardware copy if the actual RSP it finds is too high
(above the "outermost" frame).

>
>> Hmm.  I wonder if it would make sense to decode this thing both ways
>> and display it.  So show_trace_log_lvl() could print something like:
>>
>> <#DB (0xwhatever000-0xwhateverfff), next frame is at 0xsomething>
>>
>> and, in the case where the frame unwinder disagrees, it'll at least be
>> visible in that 0xsomething won't be between 0xwhatever000 and
>> 0xwhateverfff.
>>
>> Then Linus is happy because the unwinder works just like it did before
>> but people like me are also happy because it's clearer what's going
>> on.  FWIW, I've personally debugged crashes in the NMI code where the
>> current unwinder falls apart completely and it's not fun -- having a
>> display indicating that the unwinder got confused would be nice.
>
> Hm, maybe.  Another idea would be to have the unwinder print some kind
> of warning if it goes off the rails.  It should be able to detect that,
> because every stack trace should end at a user pt_regs.

I like that.

Be careful, though: 

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Kees Cook]

On Tue, Jul 26, 2016 at 1:53 PM, Rafael J. Wysocki  wrote:
> On Tuesday, July 26, 2016 01:33:02 PM Kees Cook wrote:
>> On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  
>> wrote:
>> > On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
>> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
>> >> > Hi,
>> >> >
>> >> > The following commit:
>> >> >
>> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
>> >> > Author: Josh Poimboeuf 
>> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
>> >> >
>> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
>> >> >
>> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
>> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
>> >> >
>> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
>> >> >
>> >> > is reported to cause a resume-from-hibernation regression due to an 
>> >> > attempt
>> >> > to execute an NX page (we've seen quite a bit of that recently).
>> >> >
>> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
>> >> > we'll
>> >> > need to revert the above I'm afraid.
>> >>
>> >> So I can't resume properly from disk too, on the Intel laptop this time. 
>> >> Top
>> >> commit is from tip/master:
>> >>
>> >> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
>> >> Merge: a4823bbffc96 dd9506954539
>> >> Author: Ingo Molnar 
>> >> Date:   Mon Jul 25 08:39:43 2016 +0200
>> >>
>> >> Merge branch 'linus'
>> >>
>> >>
>> >> So I thought it might be Josh's patch above and reverted it. No joy.
>> >>
>> >> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
>> >> microcode loader breakage which we've been debugging. Turned that off
>> >> and machine resumes fine again.
>> >
>> > Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
>> > was no hope it would not break hibernation if you asked me.
>> >
>> >> It looks like
>> >>
>> >>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
>> >>
>> >> broke a bunch of things. Off the top of my head, we probably should make
>> >> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
>> >> was the case with ASLR previously, AFAIR.
>> >
>> > Please no.
>> >
>> > First off, it should be perfectly possible to make hibernation work along
>> > with this new variant of ASLR.  Second, quite obviously, the author of 
>> > these
>> > ASLR changes had not done sufficient research to estimate the possible
>> > impact of them.
>>
>> I think that's a bit unfair: Thomas did a lot of testing, and it has
>> been living in -next for a while.
>
> Well, with all due respect, "a lot of testing" is not quite the same thing as
> "sufficient research" IMO.
>
> It should be known (at least from experience) that hibernation on x86-64 
> doesn't
> play well with ASLR quite as a rule, so it would be good to at least check 
> that
> particular thing or CC a relevant person (ie. me).

Fair enough: we need to practice considering a wider usage model.

> Or even ask me on IRC for that matter.  Give me a heads up ahead of time.
>
> But no.  I'm still on the receiving end of the "hibernation doesn't work with
> ASLR" story which was entirely avoidable this time around.  Sigh.

I'll be sure to keep you in the loop for future x86 KASLR changes;
sorry for the new pain. :(

>> > Honestly, I don't think it is a good idea to introduce random Kconfig 
>> > options
>> > for working around cases in which the author of some changes cannot be 
>> > bothered
>> > with doing things right.  Even if that is security.
>>
>> I would agree: let's try to get this fixed soon.
>>
>> > So IMO, either we should fix the problem, or that whole new ASLR stuff 
>> > should
>> > be reverted.
>> >
>> > I think I know how to fix it, but I won't be able to get to that before the
>> > next week.  I guess it can wait till then, though.
>>
>> Thomas, will you have some time to examine this and estimate the work for a 
>> fix?
>
> FWIW, my hunch ATM is that you need to look at the "Set up the direct mapping
> from scratch" loop in set_up_temporary_mappings() and make it do the right
> thing when the new ASLR stuff is enabled.

Thanks for the pointer!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

[Andy Lutomirski]

On Tue, Jul 26, 2016 at 9:26 AM, Josh Poimboeuf  wrote:
> On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote:
>> On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf  wrote:
>> >> > Unless I'm missing something, I think it should be fine for nested NMIs,
>> >> > since they're all on the same stack.  I can try to test it.  What in
>> >> > particular are you worried about?
>> >> >
>> >>
>> >> The top of the NMI frame contains no less than *three* (SS, SP, FLAGS,
>> >> CS, IP) records.  Off the top of my head, the record that matters is
>> >> the third one, so it should be regs[-15].  If an MCE hits while this
>> >> mess is being set up, good luck unwinding *that*.  If you really want
>> >> to know, take a deep breath, read the long comment in entry_64.S after
>> >> .Lnmi_from_kernel, then give up on x86 and start hacking on some other
>> >> architecture.
>> >
>> > I did read that comment.  Fortunately there's a big difference between
>> > reading and understanding so I can go on being an ignorant x86 hacker!
>> >
>> > For nested NMIs, it does look like the stack of the exception which
>> > interrupted the first NMI would get skipped by the stack dump.  (But
>> > that's a general problem, not specific to my patch set.)
>>
>> If we end up with task -> IST -> NMI -> same IST, we're doomed and
>> we're going to crash, so it doesn't matter much whether the unwinder
>> works.  Is that what you mean?
>
> I read the NMI entry code again, and now I realize my comment was
> completely misinformed, so never mind.
>
> Is "IST -> NMI -> same IST" even possible, since the other IST's are
> higher priority than NMI?

Priority only matters for events that happen concurrently.
Synchronous things like #DB will always fire if the conditions that
trigger them are hit,

>
>> > Am I correct in understanding that there can only be one level of NMI
>> > nesting at any given time?  If so, could we make it easier on the
>> > unwinder by putting the nested NMI on a separate software stack, so the
>> > "next stack" pointers are always in the same place?  Or am I just being
>> > naive?
>>
>> I think you're being naive :)
>>
>> But we don't really need the unwinder to be 100% faithful here.  If we have:
>>
>> task stack
>> NMI
>> nested NMI
>>
>> then the nested NMI code won't call into C and thus it should be
>> impossible to ever invoke your unwinder on that state.  Instead the
>> nested NMI code will fiddle with the saved regs and return in such a
>> way that the outer NMI will be forced to loop through again.  So it
>> *should* (assuming I'm remembering all this crap correctly) be
>> sufficient to find the "outermost" pt_regs, which is sitting at
>> (struct pt_regs *)(end - 12) - 1 or thereabouts and look at it's ->sp
>> value.  This ought to be the same thing that the frame-based unwinder
>> would naturally try to do.  But if you make this change, ISTM you
>> should make it separately because it does change behavior and Linus is
>> understandably leery about that.
>
> Ok, I think that makes sense to me now.  As I understand it, the
> "outermost" RIP is the authoritative one, because it was written by the
> original NMI.  Any nested NMIs will update the original and/or iret
> RIPs, which will only ever point to NMI entry code, and so they should
> be ignored.
>
> But I think there's a case where this wouldn't work:
>
> task stack
> NMI
> IST
> stack dump
>
> If the IST interrupt hits before the NMI has a chance to update the
> outermost regs, the authoritative RIP would be the original one written
> by HW, right?

This should be impossible unless that last entry is MCE.  If we
actually fire an event that isn't MCE early in NMI entry, something
already went very wrong.

For NMI -> MCE -> stack dump, the frame-based unwinder will do better
than get_stack_info() unless get_stack_info() learns to use the
top-of-stack hardware copy if the actual RSP it finds is too high
(above the "outermost" frame).

>
>> Hmm.  I wonder if it would make sense to decode this thing both ways
>> and display it.  So show_trace_log_lvl() could print something like:
>>
>> <#DB (0xwhatever000-0xwhateverfff), next frame is at 0xsomething>
>>
>> and, in the case where the frame unwinder disagrees, it'll at least be
>> visible in that 0xsomething won't be between 0xwhatever000 and
>> 0xwhateverfff.
>>
>> Then Linus is happy because the unwinder works just like it did before
>> but people like me are also happy because it's clearer what's going
>> on.  FWIW, I've personally debugged crashes in the NMI code where the
>> current unwinder falls apart completely and it's not fun -- having a
>> display indicating that the unwinder got confused would be nice.
>
> Hm, maybe.  Another idea would be to have the unwinder print some kind
> of warning if it goes off the rails.  It should be able to detect that,
> because every stack trace should end at a user pt_regs.

I like that.

Be careful, though: kernel threads might not have a "user" 

Re: [PATCH] [RFC] Introduce mmap randomization

[Jason Cooper]

Hi William,

On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:ja...@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.robe...@intel.com 
> > > wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and filtering for mmap on the program ls
> > > > shows a slowdown of approximate 3.7%
> > >
> > > I think it would be helpful to show the effect on the resulting object 
> > > code.
> > 
> > Do you mean the maps of the process? I have some captures for whoopsie on my
> > Ubuntu system I can share.

No, I mean changes to mm/mmap.o.

> > One thing I didn't make clear in my commit message is why this is good. 
> > Right
> > now, if you know An address within in a process, you know all offsets done 
> > with
> > mmap(). For instance, an offset To libX can yield libY by 
> > adding/subtracting an
> > offset. This is meant to make rops a bit harder, or In general any mapping 
> > offset
> > mmore difficult to find/guess.

Are you able to quantify how many bits of entropy you're imposing on the
attacker?  Is this a chair in the hallway or a significant increase in
the chances of crashing the program before finding the desired address?

thx,

Jason.

Re: [PATCH] [RFC] Introduce mmap randomization

[Jason Cooper]

Hi William,

On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:ja...@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.robe...@intel.com 
> > > wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and filtering for mmap on the program ls
> > > > shows a slowdown of approximate 3.7%
> > >
> > > I think it would be helpful to show the effect on the resulting object 
> > > code.
> > 
> > Do you mean the maps of the process? I have some captures for whoopsie on my
> > Ubuntu system I can share.

No, I mean changes to mm/mmap.o.

> > One thing I didn't make clear in my commit message is why this is good. 
> > Right
> > now, if you know An address within in a process, you know all offsets done 
> > with
> > mmap(). For instance, an offset To libX can yield libY by 
> > adding/subtracting an
> > offset. This is meant to make rops a bit harder, or In general any mapping 
> > offset
> > mmore difficult to find/guess.

Are you able to quantify how many bits of entropy you're imposing on the
attacker?  Is this a chair in the hallway or a significant increase in
the chances of crashing the program before finding the desired address?

thx,

Jason.

Re: [PATCH v2 0/2] Fix issue with alternatives/paravirt patches

[Josh Poimboeuf]

On Thu, Jul 21, 2016 at 01:23:58AM -0400, Jessica Yu wrote:
> Hi,
> 
> A few months ago, Chris Arges reported a bug involving alternatives/paravirt
> patching that was discussed here [1] and here [2]. To briefly summarize the
> bug, patch modules that contained .altinstructions or .parainstructions
> sections would break because these alternative/paravirt patches would be
> applied first by the module loader (see x86 module_finalize()), then
> livepatch would later clobber these patches when applying per-object
> relocations. This lead to crashes and unpredictable behavior.
> 
> One conclusion we reached from our last discussion was that we will
> need to introduce some arch-specific code to address this problem.
> This patchset presents a possible fix for the bug by adding a new
> arch-specific arch_klp_init_object_loaded() function that by default
> does nothing but can be overridden by different arches.
> 
> To fix this issue for x86, since we can access a patch module's Elf
> sections through mod->klp_info, we can simply delay the calls to
> apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
> which is called after relocations have been written for an object.
> In addition, for patch modules, .parainstructions and .altinstructions are
> prefixed by ".klp.arch.${objname}" so that the module loader ignores them
> and livepatch can apply them manually.
> 
> Currently for kpatch, we don't support including jump table sections in
> the patch module, and supporting .smp_locks is currently broken, so we
> don't consider those sections (for now).
> 
> I did some light testing with some patches to kvm and verified that the
> original issue reported in [2] was fixed.
> 
> Based on linux-next.

For the series:

Acked-by: Josh Poimboeuf 

-- 
Josh

Re: [PATCH v2 0/2] Fix issue with alternatives/paravirt patches

[Josh Poimboeuf]

On Thu, Jul 21, 2016 at 01:23:58AM -0400, Jessica Yu wrote:
> Hi,
> 
> A few months ago, Chris Arges reported a bug involving alternatives/paravirt
> patching that was discussed here [1] and here [2]. To briefly summarize the
> bug, patch modules that contained .altinstructions or .parainstructions
> sections would break because these alternative/paravirt patches would be
> applied first by the module loader (see x86 module_finalize()), then
> livepatch would later clobber these patches when applying per-object
> relocations. This lead to crashes and unpredictable behavior.
> 
> One conclusion we reached from our last discussion was that we will
> need to introduce some arch-specific code to address this problem.
> This patchset presents a possible fix for the bug by adding a new
> arch-specific arch_klp_init_object_loaded() function that by default
> does nothing but can be overridden by different arches.
> 
> To fix this issue for x86, since we can access a patch module's Elf
> sections through mod->klp_info, we can simply delay the calls to
> apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
> which is called after relocations have been written for an object.
> In addition, for patch modules, .parainstructions and .altinstructions are
> prefixed by ".klp.arch.${objname}" so that the module loader ignores them
> and livepatch can apply them manually.
> 
> Currently for kpatch, we don't support including jump table sections in
> the patch module, and supporting .smp_locks is currently broken, so we
> don't consider those sections (for now).
> 
> I did some light testing with some patches to kvm and verified that the
> original issue reported in [2] was fixed.
> 
> Based on linux-next.

For the series:

Acked-by: Josh Poimboeuf 

-- 
Josh

Re: [PATCH] lkdtm: fix maybe-uninitialized warning

[Arnd Bergmann]

On Tuesday, July 26, 2016 8:21:37 AM CEST Kees Cook wrote:
> On Tue, Jul 26, 2016 at 5:28 AM, Arnd Bergmann  wrote:
> > The do_usercopy_stack() function uses uninitialized stack data to initialize
> > more of the stack, which causes a warning in some configurations (ARM 
> > allmodconfig):
> >
> > drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> >
> > The warning gets reports by Mark Brown's build bot and looks correct (we 
> > are trying
> > to trick the compiler here, and sometimes the compiler notices), and I 
> > could reproduce
> > it with gcc-4.7 through gcc-5.3 but not gcc-6.1 for some reason.
> >
> > This changes the code to use the low byte of the address of the stack to 
> > initialize
> > the stack data, instead of using data from the stack itself, to avoid the 
> > warning.
> >
> > Signed-off-by: Arnd Bergmann 
> > Fixes: a3dff71c1c88 ("lkdtm: split usercopy tests to separate file")
> 
> Acked-by: Kees Cook 
> 
> I thought I already sent this fix to Greg?

Possible. I mentioned the problem to you when it first showed up,
but noticed today that I didn't have a patch for it in my testing
tree (since I test with gcc-6.1, which doesn't show the bug).

> Maybe it got lost...

More likely that it's still in his backlog then.

Arnd

Re: [PATCH] lkdtm: fix maybe-uninitialized warning

[Arnd Bergmann]

On Tuesday, July 26, 2016 8:21:37 AM CEST Kees Cook wrote:
> On Tue, Jul 26, 2016 at 5:28 AM, Arnd Bergmann  wrote:
> > The do_usercopy_stack() function uses uninitialized stack data to initialize
> > more of the stack, which causes a warning in some configurations (ARM 
> > allmodconfig):
> >
> > drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> >
> > The warning gets reports by Mark Brown's build bot and looks correct (we 
> > are trying
> > to trick the compiler here, and sometimes the compiler notices), and I 
> > could reproduce
> > it with gcc-4.7 through gcc-5.3 but not gcc-6.1 for some reason.
> >
> > This changes the code to use the low byte of the address of the stack to 
> > initialize
> > the stack data, instead of using data from the stack itself, to avoid the 
> > warning.
> >
> > Signed-off-by: Arnd Bergmann 
> > Fixes: a3dff71c1c88 ("lkdtm: split usercopy tests to separate file")
> 
> Acked-by: Kees Cook 
> 
> I thought I already sent this fix to Greg?

Possible. I mentioned the problem to you when it first showed up,
but noticed today that I didn't have a patch for it in my testing
tree (since I test with gcc-6.1, which doesn't show the bug).

> Maybe it got lost...

More likely that it's still in his backlog then.

Arnd

[GIT PULL] Power management changes for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.8-rc1

to receive the main part of power management material for v4.8-rc1
with top-most commit bc841e260c95608921809a2c7481cf6f03bec21a

 Merge branch 'pm-cpu'

on top of commit 523d939ef98fd712632d93a5a2b588e477a7565e

 Linux 4.7

Again, the majority of changes go into the cpufreq subsystem, but there are
no big features this time.  The cpufreq changes that stand out somewhat are the
governor interface rework and improvements related to the handling of frequency
tables.  Apart from those, there are fixes and new device/CPU IDs in drivers,
cleanups and an improvement of the new schedutil governor.

Next, there are some changes in the hibernation core, including a fix for
a nasty problem related to the MONITOR/MWAIT usage by CPU offline during
resume from hibernation, a few core improvements related to memory management
during resume, a couple of additional debug features and cleanups.

Finally, we have some fixes and cleanups in the devfreq subsystem, generic
power domains framework improvements related to system suspend/resume, support
for some new chips in intel_idle and in the power capping RAPL driver, a
new version of the AnalyzeSuspend utility and some assorted fixes and
cleanups.

Specifics:

 - Rework the cpufreq governor interface to make it more straightforward
   and modify the conservative governor to avoid using transition
   notifications (Rafael Wysocki).

 - Rework the handling of frequency tables by the cpufreq core to make
   it more efficient (Viresh Kumar).

 - Modify the schedutil governor to reduce the number of wakeups it
   causes to occur in cases when the CPU frequency doesn't need to be
   changed (Steve Muckle, Viresh Kumar).

 - Fix some minor issues and clean up code in the cpufreq core and
   governors (Rafael Wysocki, Viresh Kumar).

 - Add Intel Broxton support to the intel_pstate driver (Srinivas
   Pandruvada).

 - Fix problems related to the config TDP feature and to the validity
   of the MSR_HWP_INTERRUPT register in intel_pstate (Jan Kiszka,
   Srinivas Pandruvada).

 - Make intel_pstate update the cpu_frequency tracepoint even if
   the frequency doesn't change to avoid confusing powertop (Rafael
   Wysocki).

 - Clean up the usage of __init/__initdata in intel_pstate, mark some
   of its internal variables as __read_mostly and drop an unused
   structure element from it (Jisheng Zhang, Carsten Emde).

 - Clean up the usage of some duplicate MSR symbols in intel_pstate
   and turbostat (Srinivas Pandruvada).

 - Update/fix the powernv, s3c24xx and mvebu cpufreq drivers (Akshay
   Adiga, Viresh Kumar, Ben Dooks).

 - Fix a regression (introduced during the 4.5 cycle) in the
   pcc-cpufreq driver by reverting the problematic commit (Andreas
   Herrmann).

 - Add support for Intel Denverton to intel_idle, clean up Broxton
   support in it and make it explicitly non-modular (Jacob Pan,
   Jan Beulich, Paul Gortmaker).

 - Add support for Denverton and Ivy Bridge server to the Intel RAPL
   power capping driver and make it more careful about the handing
   of MSRs that may not be present (Jacob Pan, Xiaolong Wang).

 - Fix resume from hibernation on x86-64 by making the CPU offline
   during resume avoid using MONITOR/MWAIT in the "play dead" loop
   which may lead to an inadvertent "revival" of a "dead" CPU and
   a page fault leading to a kernel crash from it (Rafael Wysocki).

 - Make memory management during resume from hibernation more
   straightforward (Rafael Wysocki).

 - Add debug features that should help to detect problems related
   to hibernation and resume from it (Rafael Wysocki, Chen Yu).

 - Clean up hibernation core somewhat (Rafael Wysocki).

 - Prevent KASAN from instrumenting the hibernation core which leads
   to large numbers of false-positives from it (James Morse).

 - Prevent PM (hibernate and suspend) notifiers from being called
   during the cleanup phase if they have not been called during the
   corresponding preparation phase which is possible if one of the
   other notifiers returns an error at that time (Lianwei Wang).

 - Improve suspend-related debug printout in the tasks freezer and
   clean up suspend-related console handling (Roger Lu, Borislav
   Petkov).

 - Update the AnalyzeSuspend script in the kernel sources to
   version 4.2 (Todd Brandt).

 - Modify the generic power domains framework to make it handle
   system suspend/resume better (Ulf Hansson).

 - Make the runtime PM framework avoid resuming devices synchronously
   when user space changes the runtime PM settings for them and
   improve its error reporting (Rafael Wysocki, Linus Walleij).

 - Fix error paths in devfreq drivers (exynos, exynos-ppmu, exynos-bus)
   and in the core, make some devfreq code explicitly non-modular and
   change some of it into tristate (Bartlomiej Zolnierkiewicz,
   Peter Chen, Paul Gortmaker).

 - Add DT support to the generic PM clocks 

[GIT PULL] Power management changes for v4.8-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.8-rc1

to receive the main part of power management material for v4.8-rc1
with top-most commit bc841e260c95608921809a2c7481cf6f03bec21a

 Merge branch 'pm-cpu'

on top of commit 523d939ef98fd712632d93a5a2b588e477a7565e

 Linux 4.7

Again, the majority of changes go into the cpufreq subsystem, but there are
no big features this time.  The cpufreq changes that stand out somewhat are the
governor interface rework and improvements related to the handling of frequency
tables.  Apart from those, there are fixes and new device/CPU IDs in drivers,
cleanups and an improvement of the new schedutil governor.

Next, there are some changes in the hibernation core, including a fix for
a nasty problem related to the MONITOR/MWAIT usage by CPU offline during
resume from hibernation, a few core improvements related to memory management
during resume, a couple of additional debug features and cleanups.

Finally, we have some fixes and cleanups in the devfreq subsystem, generic
power domains framework improvements related to system suspend/resume, support
for some new chips in intel_idle and in the power capping RAPL driver, a
new version of the AnalyzeSuspend utility and some assorted fixes and
cleanups.

Specifics:

 - Rework the cpufreq governor interface to make it more straightforward
   and modify the conservative governor to avoid using transition
   notifications (Rafael Wysocki).

 - Rework the handling of frequency tables by the cpufreq core to make
   it more efficient (Viresh Kumar).

 - Modify the schedutil governor to reduce the number of wakeups it
   causes to occur in cases when the CPU frequency doesn't need to be
   changed (Steve Muckle, Viresh Kumar).

 - Fix some minor issues and clean up code in the cpufreq core and
   governors (Rafael Wysocki, Viresh Kumar).

 - Add Intel Broxton support to the intel_pstate driver (Srinivas
   Pandruvada).

 - Fix problems related to the config TDP feature and to the validity
   of the MSR_HWP_INTERRUPT register in intel_pstate (Jan Kiszka,
   Srinivas Pandruvada).

 - Make intel_pstate update the cpu_frequency tracepoint even if
   the frequency doesn't change to avoid confusing powertop (Rafael
   Wysocki).

 - Clean up the usage of __init/__initdata in intel_pstate, mark some
   of its internal variables as __read_mostly and drop an unused
   structure element from it (Jisheng Zhang, Carsten Emde).

 - Clean up the usage of some duplicate MSR symbols in intel_pstate
   and turbostat (Srinivas Pandruvada).

 - Update/fix the powernv, s3c24xx and mvebu cpufreq drivers (Akshay
   Adiga, Viresh Kumar, Ben Dooks).

 - Fix a regression (introduced during the 4.5 cycle) in the
   pcc-cpufreq driver by reverting the problematic commit (Andreas
   Herrmann).

 - Add support for Intel Denverton to intel_idle, clean up Broxton
   support in it and make it explicitly non-modular (Jacob Pan,
   Jan Beulich, Paul Gortmaker).

 - Add support for Denverton and Ivy Bridge server to the Intel RAPL
   power capping driver and make it more careful about the handing
   of MSRs that may not be present (Jacob Pan, Xiaolong Wang).

 - Fix resume from hibernation on x86-64 by making the CPU offline
   during resume avoid using MONITOR/MWAIT in the "play dead" loop
   which may lead to an inadvertent "revival" of a "dead" CPU and
   a page fault leading to a kernel crash from it (Rafael Wysocki).

 - Make memory management during resume from hibernation more
   straightforward (Rafael Wysocki).

 - Add debug features that should help to detect problems related
   to hibernation and resume from it (Rafael Wysocki, Chen Yu).

 - Clean up hibernation core somewhat (Rafael Wysocki).

 - Prevent KASAN from instrumenting the hibernation core which leads
   to large numbers of false-positives from it (James Morse).

 - Prevent PM (hibernate and suspend) notifiers from being called
   during the cleanup phase if they have not been called during the
   corresponding preparation phase which is possible if one of the
   other notifiers returns an error at that time (Lianwei Wang).

 - Improve suspend-related debug printout in the tasks freezer and
   clean up suspend-related console handling (Roger Lu, Borislav
   Petkov).

 - Update the AnalyzeSuspend script in the kernel sources to
   version 4.2 (Todd Brandt).

 - Modify the generic power domains framework to make it handle
   system suspend/resume better (Ulf Hansson).

 - Make the runtime PM framework avoid resuming devices synchronously
   when user space changes the runtime PM settings for them and
   improve its error reporting (Rafael Wysocki, Linus Walleij).

 - Fix error paths in devfreq drivers (exynos, exynos-ppmu, exynos-bus)
   and in the core, make some devfreq code explicitly non-modular and
   change some of it into tristate (Bartlomiej Zolnierkiewicz,
   Peter Chen, Paul Gortmaker).

 - Add DT support to the generic PM clocks 

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

[Arnd Bergmann]

On Tuesday, July 26, 2016 10:18:53 PM CEST Ulf Hansson wrote:
> > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> > b/drivers/mmc/host/sdhci-esdhc-imx.c
> > index 2bb326bbc34a..593e34053c4b 100644
> > --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> > @@ -1293,13 +1293,12 @@ static int sdhci_esdhc_imx_remove(struct 
> > platform_device *pdev)
> > return 0;
> >  }
> >
> > -#ifdef CONFIG_PM
> > -static int sdhci_esdhc_suspend(struct device *dev)
> > +static int __maybe_unused sdhci_esdhc_suspend(struct device *dev)
> 
> Instead of using __maybe_unused, I prefer to change above "#ifdef
> CONFIG_PMf" to "#ifdef CONFIG_PM_SLEEP".
> I do realize that the runtime PM callbacks still requires #ifdef
> CONFIG_PM, so yes that's requires an extra "ifdef".
> 
> Sure, it's more a matter of taste (and micro optimizations).

I was hoping that we could eventually do a mass-conversion to
__maybe_unused, as everybody seems to get the #ifdef wrong.

Any specific reason for your preference?

Arnd

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

[Arnd Bergmann]

On Tuesday, July 26, 2016 10:18:53 PM CEST Ulf Hansson wrote:
> > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> > b/drivers/mmc/host/sdhci-esdhc-imx.c
> > index 2bb326bbc34a..593e34053c4b 100644
> > --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> > @@ -1293,13 +1293,12 @@ static int sdhci_esdhc_imx_remove(struct 
> > platform_device *pdev)
> > return 0;
> >  }
> >
> > -#ifdef CONFIG_PM
> > -static int sdhci_esdhc_suspend(struct device *dev)
> > +static int __maybe_unused sdhci_esdhc_suspend(struct device *dev)
> 
> Instead of using __maybe_unused, I prefer to change above "#ifdef
> CONFIG_PMf" to "#ifdef CONFIG_PM_SLEEP".
> I do realize that the runtime PM callbacks still requires #ifdef
> CONFIG_PM, so yes that's requires an extra "ifdef".
> 
> Sure, it's more a matter of taste (and micro optimizations).

I was hoping that we could eventually do a mass-conversion to
__maybe_unused, as everybody seems to get the #ifdef wrong.

Any specific reason for your preference?

Arnd

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 09:17:31PM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Andrew,
> 
> On 26 July 2016 at 20:25, Andrew Vagin  wrote:
> > On Tue, Jul 26, 2016 at 10:03:25AM +0200, Michael Kerrisk (man-pages) wrote:
> >> On 07/26/2016 04:54 AM, Andrew Vagin wrote:
> >> > On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote:
> >> > > "Michael Kerrisk (man-pages)"  writes:
> >> >
> >> > [snip]
> >> >
> >> > > [snip]
> >> > > > > > So, from my point of view, the important piece that was missing 
> >> > > > > > from
> >> > > > > > your commit message was the note to use 
> >> > > > > > readlink("/proc/self/fd/%d")
> >> > > > > > on the returned FDs. I think that detail needs to be part of the
> >> > > > > > commit message (and also the man page text). I think it even be
> >> > > > > > helpful to include the above program as part of the commit 
> >> > > > > > message:
> >> > > > > > it helps people more quickly grasp the API.
> >> > > > >
> >> > > > > Please, please make the standard way to compare these things fstat.
> >> > > > > That is much less magic than a symlink, and a little more future 
> >> > > > > proof.
> >> > > > > Possibly even kcmp.
> >> >
> >> > I like the idea to use kcmp to compare namespaces. I am going to add this
> >> > functionality to kcmp and describe all these in the man page.
> >>
> >> Hi Andrey,
> >>
> >> Can you briefly sketch out the proposed API and how it would be used?
> >> I'd find it useful to see that even before the implementation.
> >
> > Sure. If a process wants to compare two namespaces, it needs to get file
> > descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> > process which has them),
> > and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
> >
> > For example, if we want to compare pid namespaces for 1 and 2 processes:
> >
> 
> What's the purpose of the following line, and the use of 'pid' in the
> kcmp() call?:

It's the existing interface of kcmp. It's used to check whether the
two processes identified  by pid1  and  pid2 share a kernel resource
such as virtual memory, file descriptors, and so on.

If we want to compare two file descriptors of the current process,
it is one of cases for which kcmp can be used. We can call kcmp to
compare two namespaces which are opened in other processes.

Thanks,
Andrew

> 
> > pid = getpid();
> > ns_fd1 = open("/proc/1/ns/pid")
> > ns_fd2 = open("/proc/2/ns/pid")
> >
> > if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
> > printf("Both processes live in the same pid namespace\n");
> 
> Thanks,
> 
> Michael

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 09:17:31PM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Andrew,
> 
> On 26 July 2016 at 20:25, Andrew Vagin  wrote:
> > On Tue, Jul 26, 2016 at 10:03:25AM +0200, Michael Kerrisk (man-pages) wrote:
> >> On 07/26/2016 04:54 AM, Andrew Vagin wrote:
> >> > On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote:
> >> > > "Michael Kerrisk (man-pages)"  writes:
> >> >
> >> > [snip]
> >> >
> >> > > [snip]
> >> > > > > > So, from my point of view, the important piece that was missing 
> >> > > > > > from
> >> > > > > > your commit message was the note to use 
> >> > > > > > readlink("/proc/self/fd/%d")
> >> > > > > > on the returned FDs. I think that detail needs to be part of the
> >> > > > > > commit message (and also the man page text). I think it even be
> >> > > > > > helpful to include the above program as part of the commit 
> >> > > > > > message:
> >> > > > > > it helps people more quickly grasp the API.
> >> > > > >
> >> > > > > Please, please make the standard way to compare these things fstat.
> >> > > > > That is much less magic than a symlink, and a little more future 
> >> > > > > proof.
> >> > > > > Possibly even kcmp.
> >> >
> >> > I like the idea to use kcmp to compare namespaces. I am going to add this
> >> > functionality to kcmp and describe all these in the man page.
> >>
> >> Hi Andrey,
> >>
> >> Can you briefly sketch out the proposed API and how it would be used?
> >> I'd find it useful to see that even before the implementation.
> >
> > Sure. If a process wants to compare two namespaces, it needs to get file
> > descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> > process which has them),
> > and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
> >
> > For example, if we want to compare pid namespaces for 1 and 2 processes:
> >
> 
> What's the purpose of the following line, and the use of 'pid' in the
> kcmp() call?:

It's the existing interface of kcmp. It's used to check whether the
two processes identified  by pid1  and  pid2 share a kernel resource
such as virtual memory, file descriptors, and so on.

If we want to compare two file descriptors of the current process,
it is one of cases for which kcmp can be used. We can call kcmp to
compare two namespaces which are opened in other processes.

Thanks,
Andrew

> 
> > pid = getpid();
> > ns_fd1 = open("/proc/1/ns/pid")
> > ns_fd2 = open("/proc/2/ns/pid")
> >
> > if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
> > printf("Both processes live in the same pid namespace\n");
> 
> Thanks,
> 
> Michael

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[ivan.khoronzhuk]

On 26.07.16 19:02, Grygorii Strashko wrote:

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:



On 22.07.16 16:58, Grygorii Strashko wrote:

Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
 cpsw_remove()
 - cpdma_ctlr_destroy()
   - spin_lock_irqsave(>lock, flags)
   - cpdma_ctlr_stop()
 - spin_lock_irqsave(>lock, flags); <- deadlock
   - cpdma_chan_destroy()
 - spin_lock_irqsave(>lock, flags); <- deadlock

The issue has not been observed before because CPDMA channels have
been destroyed manually by CPSW until commit d941ebe88a41 ("net:
ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a68652a..89242e9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 if (!ctlr)
 return -EINVAL;

-spin_lock_irqsave(>lock, flags);

Should ctlr->state be checked under lock?
Seems like here should be used unlocked static versions of
cpdma_ctlr_stop() and cpdma_chan_destroy() instead.


As per my understanding it's not expected the ctlr->state will be changed at 
this
moment as all net devices has been unregistered already.

Seems yes, the race can be only in case of incorrect usage, stop while destroy,
destroy while start...etc..all they are mostly unreal use-cases, you are right,
but such check w/o lock always under eyes control, that always makes you think
that smth wrong.






 if (ctlr->state != CPDMA_STATE_IDLE)


May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

Yes, it be more clear.
I was thinking about lock deletion also, as under this destroy function the
ctlr destroys it's resources one by one, ok, the channels are destroyed under 
lock,
but pool (it's good that it's destroyed after channels). I see that it 
should never
happen, but ctrl is external structure, who knows as it can be used while 
destroying.
That was my paranoiac point, so don't pay a lot attention to it. In case of 
normal usage,
as it's currently is and should be, the lock can be removed.




 cpdma_ctlr_stop(ctlr);

@@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 cpdma_chan_destroy(ctlr->channels[i]);

 cpdma_desc_pool_destroy(ctlr->pool);
-spin_unlock_irqrestore(>lock, flags);
 return ret;
 }
 EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[ivan.khoronzhuk]

On 26.07.16 19:02, Grygorii Strashko wrote:

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:



On 22.07.16 16:58, Grygorii Strashko wrote:

Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
 cpsw_remove()
 - cpdma_ctlr_destroy()
   - spin_lock_irqsave(>lock, flags)
   - cpdma_ctlr_stop()
 - spin_lock_irqsave(>lock, flags); <- deadlock
   - cpdma_chan_destroy()
 - spin_lock_irqsave(>lock, flags); <- deadlock

The issue has not been observed before because CPDMA channels have
been destroyed manually by CPSW until commit d941ebe88a41 ("net:
ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a68652a..89242e9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 if (!ctlr)
 return -EINVAL;

-spin_lock_irqsave(>lock, flags);

Should ctlr->state be checked under lock?
Seems like here should be used unlocked static versions of
cpdma_ctlr_stop() and cpdma_chan_destroy() instead.


As per my understanding it's not expected the ctlr->state will be changed at 
this
moment as all net devices has been unregistered already.

Seems yes, the race can be only in case of incorrect usage, stop while destroy,
destroy while start...etc..all they are mostly unreal use-cases, you are right,
but such check w/o lock always under eyes control, that always makes you think
that smth wrong.






 if (ctlr->state != CPDMA_STATE_IDLE)


May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

Yes, it be more clear.
I was thinking about lock deletion also, as under this destroy function the
ctlr destroys it's resources one by one, ok, the channels are destroyed under 
lock,
but pool (it's good that it's destroyed after channels). I see that it 
should never
happen, but ctrl is external structure, who knows as it can be used while 
destroying.
That was my paranoiac point, so don't pay a lot attention to it. In case of 
normal usage,
as it's currently is and should be, the lock can be removed.




 cpdma_ctlr_stop(ctlr);

@@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 cpdma_chan_destroy(ctlr->channels[i]);

 cpdma_desc_pool_destroy(ctlr->pool);
-spin_unlock_irqrestore(>lock, flags);
 return ret;
 }
 EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);

Re: [PATCH] Coccinelle: Script to replace allocate and memcpy with zalloc functions

[Michal Marek]

Dne 23.7.2016 v 23:00 Amitoj Kaur Chawla napsal(a):
> This script finds instances of allocate and memcpy which can be
> replaced with a direct call to zalloc equivalent of a function.
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  scripts/coccinelle/api/zalloc.cocci | 556 
> 
>  1 file changed, 556 insertions(+)
>  create mode 100644 scripts/coccinelle/api/zalloc.cocci
> 
> diff --git a/scripts/coccinelle/api/zalloc.cocci 
> b/scripts/coccinelle/api/zalloc.cocci
> new file mode 100644
> index 000..4f94e43
> --- /dev/null
> +++ b/scripts/coccinelle/api/zalloc.cocci
> @@ -0,0 +1,556 @@
> +/// Prefer zalloc functions instead of using allocate and memcpy.

s/memcpy/memset/ ? The actual spatch names the correct function.

Michal

Re: [PATCH] Coccinelle: Script to replace allocate and memcpy with zalloc functions

[Michal Marek]

Dne 23.7.2016 v 23:00 Amitoj Kaur Chawla napsal(a):
> This script finds instances of allocate and memcpy which can be
> replaced with a direct call to zalloc equivalent of a function.
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  scripts/coccinelle/api/zalloc.cocci | 556 
> 
>  1 file changed, 556 insertions(+)
>  create mode 100644 scripts/coccinelle/api/zalloc.cocci
> 
> diff --git a/scripts/coccinelle/api/zalloc.cocci 
> b/scripts/coccinelle/api/zalloc.cocci
> new file mode 100644
> index 000..4f94e43
> --- /dev/null
> +++ b/scripts/coccinelle/api/zalloc.cocci
> @@ -0,0 +1,556 @@
> +/// Prefer zalloc functions instead of using allocate and memcpy.

s/memcpy/memset/ ? The actual spatch names the correct function.

Michal

[PATCH 4/6] drm/vc4: Free hang state before destroying BO cache.

[Eric Anholt]

The BO cache will complain if BOs are still allocated when we try to
destroy it (since freeing those BOs would try to hit the cache).  You
could hit this if you were to unload the module after a GPU hang.

Signed-off-by: Eric Anholt 
Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state 
after a hang.")
---
 drivers/gpu/drm/vc4/vc4_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index fb2b1c526646..3f60036834e0 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -947,8 +947,8 @@ vc4_gem_destroy(struct drm_device *dev)
vc4->overflow_mem = NULL;
}
 
-   vc4_bo_cache_destroy(dev);
-
if (vc4->hang_state)
vc4_free_hang_state(dev, vc4->hang_state);
+
+   vc4_bo_cache_destroy(dev);
 }
-- 
2.8.1

[PATCH 4/6] drm/vc4: Free hang state before destroying BO cache.

[Eric Anholt]

The BO cache will complain if BOs are still allocated when we try to
destroy it (since freeing those BOs would try to hit the cache).  You
could hit this if you were to unload the module after a GPU hang.

Signed-off-by: Eric Anholt 
Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state 
after a hang.")
---
 drivers/gpu/drm/vc4/vc4_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index fb2b1c526646..3f60036834e0 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -947,8 +947,8 @@ vc4_gem_destroy(struct drm_device *dev)
vc4->overflow_mem = NULL;
}
 
-   vc4_bo_cache_destroy(dev);
-
if (vc4->hang_state)
vc4_free_hang_state(dev, vc4->hang_state);
+
+   vc4_bo_cache_destroy(dev);
 }
-- 
2.8.1

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Rafael J. Wysocki]

On Tuesday, July 26, 2016 01:33:02 PM Kees Cook wrote:
> On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
> >> > Hi,
> >> >
> >> > The following commit:
> >> >
> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
> >> > Author: Josh Poimboeuf 
> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
> >> >
> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
> >> >
> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
> >> >
> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
> >> >
> >> > is reported to cause a resume-from-hibernation regression due to an 
> >> > attempt
> >> > to execute an NX page (we've seen quite a bit of that recently).
> >> >
> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
> >> > we'll
> >> > need to revert the above I'm afraid.
> >>
> >> So I can't resume properly from disk too, on the Intel laptop this time. 
> >> Top
> >> commit is from tip/master:
> >>
> >> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
> >> Merge: a4823bbffc96 dd9506954539
> >> Author: Ingo Molnar 
> >> Date:   Mon Jul 25 08:39:43 2016 +0200
> >>
> >> Merge branch 'linus'
> >>
> >>
> >> So I thought it might be Josh's patch above and reverted it. No joy.
> >>
> >> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
> >> microcode loader breakage which we've been debugging. Turned that off
> >> and machine resumes fine again.
> >
> > Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
> > was no hope it would not break hibernation if you asked me.
> >
> >> It looks like
> >>
> >>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
> >>
> >> broke a bunch of things. Off the top of my head, we probably should make
> >> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
> >> was the case with ASLR previously, AFAIR.
> >
> > Please no.
> >
> > First off, it should be perfectly possible to make hibernation work along
> > with this new variant of ASLR.  Second, quite obviously, the author of these
> > ASLR changes had not done sufficient research to estimate the possible
> > impact of them.
> 
> I think that's a bit unfair: Thomas did a lot of testing, and it has
> been living in -next for a while.

Well, with all due respect, "a lot of testing" is not quite the same thing as
"sufficient research" IMO.

It should be known (at least from experience) that hibernation on x86-64 doesn't
play well with ASLR quite as a rule, so it would be good to at least check that
particular thing or CC a relevant person (ie. me).

Or even ask me on IRC for that matter.  Give me a heads up ahead of time.

But no.  I'm still on the receiving end of the "hibernation doesn't work with
ASLR" story which was entirely avoidable this time around.  Sigh.

> > Honestly, I don't think it is a good idea to introduce random Kconfig 
> > options
> > for working around cases in which the author of some changes cannot be 
> > bothered
> > with doing things right.  Even if that is security.
> 
> I would agree: let's try to get this fixed soon.
> 
> > So IMO, either we should fix the problem, or that whole new ASLR stuff 
> > should
> > be reverted.
> >
> > I think I know how to fix it, but I won't be able to get to that before the
> > next week.  I guess it can wait till then, though.
> 
> Thomas, will you have some time to examine this and estimate the work for a 
> fix?

FWIW, my hunch ATM is that you need to look at the "Set up the direct mapping
from scratch" loop in set_up_temporary_mappings() and make it do the right
thing when the new ASLR stuff is enabled.

Thanks,
Rafael

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Rafael J. Wysocki]

On Tuesday, July 26, 2016 01:33:02 PM Kees Cook wrote:
> On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
> >> > Hi,
> >> >
> >> > The following commit:
> >> >
> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
> >> > Author: Josh Poimboeuf 
> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
> >> >
> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
> >> >
> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
> >> >
> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
> >> >
> >> > is reported to cause a resume-from-hibernation regression due to an 
> >> > attempt
> >> > to execute an NX page (we've seen quite a bit of that recently).
> >> >
> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
> >> > we'll
> >> > need to revert the above I'm afraid.
> >>
> >> So I can't resume properly from disk too, on the Intel laptop this time. 
> >> Top
> >> commit is from tip/master:
> >>
> >> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
> >> Merge: a4823bbffc96 dd9506954539
> >> Author: Ingo Molnar 
> >> Date:   Mon Jul 25 08:39:43 2016 +0200
> >>
> >> Merge branch 'linus'
> >>
> >>
> >> So I thought it might be Josh's patch above and reverted it. No joy.
> >>
> >> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
> >> microcode loader breakage which we've been debugging. Turned that off
> >> and machine resumes fine again.
> >
> > Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
> > was no hope it would not break hibernation if you asked me.
> >
> >> It looks like
> >>
> >>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
> >>
> >> broke a bunch of things. Off the top of my head, we probably should make
> >> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
> >> was the case with ASLR previously, AFAIR.
> >
> > Please no.
> >
> > First off, it should be perfectly possible to make hibernation work along
> > with this new variant of ASLR.  Second, quite obviously, the author of these
> > ASLR changes had not done sufficient research to estimate the possible
> > impact of them.
> 
> I think that's a bit unfair: Thomas did a lot of testing, and it has
> been living in -next for a while.

Well, with all due respect, "a lot of testing" is not quite the same thing as
"sufficient research" IMO.

It should be known (at least from experience) that hibernation on x86-64 doesn't
play well with ASLR quite as a rule, so it would be good to at least check that
particular thing or CC a relevant person (ie. me).

Or even ask me on IRC for that matter.  Give me a heads up ahead of time.

But no.  I'm still on the receiving end of the "hibernation doesn't work with
ASLR" story which was entirely avoidable this time around.  Sigh.

> > Honestly, I don't think it is a good idea to introduce random Kconfig 
> > options
> > for working around cases in which the author of some changes cannot be 
> > bothered
> > with doing things right.  Even if that is security.
> 
> I would agree: let's try to get this fixed soon.
> 
> > So IMO, either we should fix the problem, or that whole new ASLR stuff 
> > should
> > be reverted.
> >
> > I think I know how to fix it, but I won't be able to get to that before the
> > next week.  I guess it can wait till then, though.
> 
> Thomas, will you have some time to examine this and estimate the work for a 
> fix?

FWIW, my hunch ATM is that you need to look at the "Set up the direct mapping
from scratch" loop in set_up_temporary_mappings() and make it do the right
thing when the new ASLR stuff is enabled.

Thanks,
Rafael

[PATCH 0/6] vc4 miscellaneous v3d fixes

[Eric Anholt]

Here are a bunch of miscellaneous fixes for 3D I've come up with while
doing a bunch of piglit runs.  One has a new IGT test sent out, and
I've got a test almost ready for large CLs.

Eric Anholt (6):
  drm/vc4: Use drm_free_large() on handles to match its allocation.
  drm/vc4: Use drm_malloc_ab to fix large rendering jobs.
  drm/vc4: Fix handling of a pm_runtime_get_sync() success case.
  drm/vc4: Free hang state before destroying BO cache.
  drm/vc4: Fix overflow mem unreferencing when the binner runs dry.
  drm/vc4: Fix oops when userspace hands in a bad BO.

 drivers/gpu/drm/vc4/vc4_drv.c |  6 +++---
 drivers/gpu/drm/vc4/vc4_drv.h |  9 +
 drivers/gpu/drm/vc4/vc4_gem.c | 18 +-
 drivers/gpu/drm/vc4/vc4_irq.c |  4 +++-
 4 files changed, 24 insertions(+), 13 deletions(-)

-- 
2.8.1

[PATCH 1/6] drm/vc4: Use drm_free_large() on handles to match its allocation.

[Eric Anholt]

If you managed to exceed the limit to switch to vmalloc, we'd use the
wrong free.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 46899d6de675..f9b13b54c86b 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -574,7 +574,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
spin_unlock(_priv->table_lock);
 
 fail:
-   kfree(handles);
+   drm_free_large(handles);
return 0;
 }
 
-- 
2.8.1

[PATCH 0/6] vc4 miscellaneous v3d fixes

[Eric Anholt]

Here are a bunch of miscellaneous fixes for 3D I've come up with while
doing a bunch of piglit runs.  One has a new IGT test sent out, and
I've got a test almost ready for large CLs.

Eric Anholt (6):
  drm/vc4: Use drm_free_large() on handles to match its allocation.
  drm/vc4: Use drm_malloc_ab to fix large rendering jobs.
  drm/vc4: Fix handling of a pm_runtime_get_sync() success case.
  drm/vc4: Free hang state before destroying BO cache.
  drm/vc4: Fix overflow mem unreferencing when the binner runs dry.
  drm/vc4: Fix oops when userspace hands in a bad BO.

 drivers/gpu/drm/vc4/vc4_drv.c |  6 +++---
 drivers/gpu/drm/vc4/vc4_drv.h |  9 +
 drivers/gpu/drm/vc4/vc4_gem.c | 18 +-
 drivers/gpu/drm/vc4/vc4_irq.c |  4 +++-
 4 files changed, 24 insertions(+), 13 deletions(-)

-- 
2.8.1

[PATCH 1/6] drm/vc4: Use drm_free_large() on handles to match its allocation.

[Eric Anholt]

If you managed to exceed the limit to switch to vmalloc, we'd use the
wrong free.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 46899d6de675..f9b13b54c86b 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -574,7 +574,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
spin_unlock(_priv->table_lock);
 
 fail:
-   kfree(handles);
+   drm_free_large(handles);
return 0;
 }
 
-- 
2.8.1

[PATCH 3/6] drm/vc4: Fix handling of a pm_runtime_get_sync() success case.

[Eric Anholt]

If the device was already up, a 1 is returned instead of 0.  We were
erroring out, leading the 3D driver to sometimes fail at screen
initialization (generally with ENOENT returned to it).

Signed-off-by: Eric Anholt 
Fixes: af713795c59f ("drm/vc4: Add a getparam ioctl for getting the V3D 
identity regs.")
---
 drivers/gpu/drm/vc4/vc4_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 9435894822d5..fb20e03ec7e2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -57,21 +57,21 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
switch (args->param) {
case DRM_VC4_PARAM_V3D_IDENT0:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT0);
pm_runtime_put(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT1);
pm_runtime_put(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT2);
pm_runtime_put(>v3d->pdev->dev);
-- 
2.8.1

[PATCH 3/6] drm/vc4: Fix handling of a pm_runtime_get_sync() success case.

[Eric Anholt]

If the device was already up, a 1 is returned instead of 0.  We were
erroring out, leading the 3D driver to sometimes fail at screen
initialization (generally with ENOENT returned to it).

Signed-off-by: Eric Anholt 
Fixes: af713795c59f ("drm/vc4: Add a getparam ioctl for getting the V3D 
identity regs.")
---
 drivers/gpu/drm/vc4/vc4_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 9435894822d5..fb20e03ec7e2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -57,21 +57,21 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
switch (args->param) {
case DRM_VC4_PARAM_V3D_IDENT0:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT0);
pm_runtime_put(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT1);
pm_runtime_put(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret)
+   if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT2);
pm_runtime_put(>v3d->pdev->dev);
-- 
2.8.1

[PATCH 6/6] drm/vc4: Fix oops when userspace hands in a bad BO.

[Eric Anholt]

We'd end up NULL pointer dereferencing because we didn't take the
error path out in the parent.  Fixes igt vc4_lookup_fail test.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 3f60036834e0..9da024fffbcf 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -575,7 +575,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
 
 fail:
drm_free_large(handles);
-   return 0;
+   return ret;
 }
 
 static int
-- 
2.8.1

[PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Eric Anholt]

Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed.  When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.

We were looking at "what's currently running in the binner", but since
the bin/render submission split, we may end up with the binner
completing and having no new job while the renderer is still
processing.  So, if we don't find a bin job at all, look at the
highest-seqno (last) render job to attach our overflow to.

Signed-off-by: Eric Anholt 
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
rendering jobs")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_drv.h | 9 +
 drivers/gpu/drm/vc4/vc4_irq.c | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 0ced289d7696..87f727932af2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -321,6 +321,15 @@ vc4_first_render_job(struct vc4_dev *vc4)
struct vc4_exec_info, head);
 }
 
+static inline struct vc4_exec_info *
+vc4_last_render_job(struct vc4_dev *vc4)
+{
+   if (list_empty(>render_job_list))
+   return NULL;
+   return list_last_entry(>render_job_list,
+  struct vc4_exec_info, head);
+}
+
 /**
  * struct vc4_texture_sample_info - saves the offsets into the UBO for texture
  * setup parameters.
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index b0104a346a74..094bc6a475c1 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -83,8 +83,10 @@ vc4_overflow_mem_work(struct work_struct *work)
 
spin_lock_irqsave(>job_lock, irqflags);
current_exec = vc4_first_bin_job(vc4);
+   if (!current_exec)
+   current_exec = vc4_last_render_job(vc4);
if (current_exec) {
-   vc4->overflow_mem->seqno = vc4->finished_seqno + 1;
+   vc4->overflow_mem->seqno = current_exec->seqno;
list_add_tail(>overflow_mem->unref_head,
  _exec->unref_list);
vc4->overflow_mem = NULL;
-- 
2.8.1

[PATCH 2/6] drm/vc4: Use drm_malloc_ab to fix large rendering jobs.

[Eric Anholt]

If you exceeded the size that kmalloc would return, you'd get a dmesg
warning and an error from the job submit.  We can handle much larger
allocations with vmalloc, and drm_malloc_ab makes that decision.

Fixes failure in piglit's scissor-many.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_gem.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index f9b13b54c86b..fb2b1c526646 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -536,8 +536,8 @@ vc4_cl_lookup_bos(struct drm_device *dev,
return -EINVAL;
}
 
-   exec->bo = kcalloc(exec->bo_count, sizeof(struct drm_gem_cma_object *),
-  GFP_KERNEL);
+   exec->bo = drm_calloc_large(exec->bo_count,
+   sizeof(struct drm_gem_cma_object *));
if (!exec->bo) {
DRM_ERROR("Failed to allocate validated BO pointers\n");
return -ENOMEM;
@@ -610,7 +610,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
 * read the contents back for validation, and I think the
 * bo->vaddr is uncached access.
 */
-   temp = kmalloc(temp_size, GFP_KERNEL);
+   temp = drm_malloc_ab(temp_size, 1);
if (!temp) {
DRM_ERROR("Failed to allocate storage for copying "
  "in bin/render CLs.\n");
@@ -677,7 +677,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
ret = vc4_validate_shader_recs(dev, exec);
 
 fail:
-   kfree(temp);
+   drm_free_large(temp);
return ret;
 }
 
@@ -692,7 +692,7 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
if (exec->bo) {
for (i = 0; i < exec->bo_count; i++)
drm_gem_object_unreference(>bo[i]->base);
-   kfree(exec->bo);
+   drm_free_large(exec->bo);
}
 
while (!list_empty(>unref_list)) {
-- 
2.8.1

[PATCH 6/6] drm/vc4: Fix oops when userspace hands in a bad BO.

[Eric Anholt]

We'd end up NULL pointer dereferencing because we didn't take the
error path out in the parent.  Fixes igt vc4_lookup_fail test.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 3f60036834e0..9da024fffbcf 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -575,7 +575,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
 
 fail:
drm_free_large(handles);
-   return 0;
+   return ret;
 }
 
 static int
-- 
2.8.1

[PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Eric Anholt]

Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed.  When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.

We were looking at "what's currently running in the binner", but since
the bin/render submission split, we may end up with the binner
completing and having no new job while the renderer is still
processing.  So, if we don't find a bin job at all, look at the
highest-seqno (last) render job to attach our overflow to.

Signed-off-by: Eric Anholt 
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
rendering jobs")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_drv.h | 9 +
 drivers/gpu/drm/vc4/vc4_irq.c | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 0ced289d7696..87f727932af2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -321,6 +321,15 @@ vc4_first_render_job(struct vc4_dev *vc4)
struct vc4_exec_info, head);
 }
 
+static inline struct vc4_exec_info *
+vc4_last_render_job(struct vc4_dev *vc4)
+{
+   if (list_empty(>render_job_list))
+   return NULL;
+   return list_last_entry(>render_job_list,
+  struct vc4_exec_info, head);
+}
+
 /**
  * struct vc4_texture_sample_info - saves the offsets into the UBO for texture
  * setup parameters.
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index b0104a346a74..094bc6a475c1 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -83,8 +83,10 @@ vc4_overflow_mem_work(struct work_struct *work)
 
spin_lock_irqsave(>job_lock, irqflags);
current_exec = vc4_first_bin_job(vc4);
+   if (!current_exec)
+   current_exec = vc4_last_render_job(vc4);
if (current_exec) {
-   vc4->overflow_mem->seqno = vc4->finished_seqno + 1;
+   vc4->overflow_mem->seqno = current_exec->seqno;
list_add_tail(>overflow_mem->unref_head,
  _exec->unref_list);
vc4->overflow_mem = NULL;
-- 
2.8.1

[PATCH 2/6] drm/vc4: Use drm_malloc_ab to fix large rendering jobs.

[Eric Anholt]

If you exceeded the size that kmalloc would return, you'd get a dmesg
warning and an error from the job submit.  We can handle much larger
allocations with vmalloc, and drm_malloc_ab makes that decision.

Fixes failure in piglit's scissor-many.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_gem.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index f9b13b54c86b..fb2b1c526646 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -536,8 +536,8 @@ vc4_cl_lookup_bos(struct drm_device *dev,
return -EINVAL;
}
 
-   exec->bo = kcalloc(exec->bo_count, sizeof(struct drm_gem_cma_object *),
-  GFP_KERNEL);
+   exec->bo = drm_calloc_large(exec->bo_count,
+   sizeof(struct drm_gem_cma_object *));
if (!exec->bo) {
DRM_ERROR("Failed to allocate validated BO pointers\n");
return -ENOMEM;
@@ -610,7 +610,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
 * read the contents back for validation, and I think the
 * bo->vaddr is uncached access.
 */
-   temp = kmalloc(temp_size, GFP_KERNEL);
+   temp = drm_malloc_ab(temp_size, 1);
if (!temp) {
DRM_ERROR("Failed to allocate storage for copying "
  "in bin/render CLs.\n");
@@ -677,7 +677,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
ret = vc4_validate_shader_recs(dev, exec);
 
 fail:
-   kfree(temp);
+   drm_free_large(temp);
return ret;
 }
 
@@ -692,7 +692,7 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
if (exec->bo) {
for (i = 0; i < exec->bo_count; i++)
drm_gem_object_unreference(>bo[i]->base);
-   kfree(exec->bo);
+   drm_free_large(exec->bo);
}
 
while (!list_empty(>unref_list)) {
-- 
2.8.1

Re: [PATCH 1/4] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Bjorn Helgaas]

On Tue, Jul 26, 2016 at 03:19:32PM -0500, Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:14AM +0800, Rui Wang wrote:
> > IOAPICs present during system boot aren't added to ioapic_list,
> > thus are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during root bus enumeration.
> > 
> > Signed-off-by: Rui Wang 

I should have added:

Acked-by: Bjorn Helgaas 

The comments below are minor, and I'm happy if Rafael merges this
series via his tree.

> > ---
> >  drivers/acpi/internal.h |  2 --
> >  drivers/acpi/ioapic.c   |  7 ---
> >  drivers/acpi/pci_root.c | 13 -
> >  drivers/pci/setup-bus.c |  5 -
> >  include/linux/acpi.h|  6 ++
> >  5 files changed, 26 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> > index 27cc7fe..6d8e67e 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -40,10 +40,8 @@ int acpi_sysfs_init(void);
> >  void acpi_container_init(void);
> >  void acpi_memory_hotplug_init(void);
> >  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > -int acpi_ioapic_add(struct acpi_pci_root *root);
> >  int acpi_ioapic_remove(struct acpi_pci_root *root);
> >  #else
> > -static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
> 
> It would be nicer if the interface change and header file munging
> were in a separate patch so they wouldn't obscure the meat of the
> change, i.e., the addition of calls to acpi_ioapic_add().
> 
> >  static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 
> > 0; }
> >  #endif
> >  #ifdef CONFIG_ACPI_DOCK
> > diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
> > index ccdc8db..0f272e2 100644
> > --- a/drivers/acpi/ioapic.c
> > +++ b/drivers/acpi/ioapic.c
> > @@ -189,16 +189,17 @@ exit:
> > return AE_OK;
> >  }
> >  
> > -int acpi_ioapic_add(struct acpi_pci_root *root)
> > +int acpi_ioapic_add(acpi_handle root_handle)
> >  {
> > acpi_status status, retval = AE_OK;
> >  
> > -   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle,
> > +   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
> >  UINT_MAX, handle_ioapic_add, NULL,
> > -root->device->handle, (void **));
> > +root_handle, (void **));
> >  
> > return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV;
> >  }
> > +EXPORT_SYMBOL_GPL(acpi_ioapic_add);
> 
> What loadable module needs to call this?  It shouldn't be exported
> unless there is such a module.
> 
> >  int acpi_ioapic_remove(struct acpi_pci_root *root)
> >  {
> > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > index ae3fe4e..d818c61 100644
> > --- a/drivers/acpi/pci_root.c
> > +++ b/drivers/acpi/pci_root.c
> > @@ -614,7 +614,18 @@ static int acpi_pci_root_add(struct acpi_device 
> > *device,
> > if (hotadd) {
> > pcibios_resource_survey_bus(root->bus);
> > pci_assign_unassigned_root_bus_resources(root->bus);
> > -   acpi_ioapic_add(root);
> > +
> > +   /*
> > +* This is only called for the hotadd case. For the boot-time
> > +* case, we need to wait until after PCI initialization in
> > +* order to deal with IOAPICs mapped in on a PCI BAR.
> > +*
> > +* This is currently x86-specific, because acpi_ioapic_add()
> > +* is an empty function without CONFIG_ACPI_HOTPLUG_IOAPIC.
> > +* And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC
> > +* (see drivers/acpi/Kconfig).
> > +*/
> > +   acpi_ioapic_add(root->device->handle);
> > }
> >  
> > pci_lock_rescan_remove();
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > index 55641a3..e32c356 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include "pci.h"
> >  
> >  unsigned int pci_flags;
> > @@ -1779,8 +1780,10 @@ void __init pci_assign_unassigned_resources(void)
> >  {
> > struct pci_bus *root_bus;
> >  
> > -   list_for_each_entry(root_bus, _root_buses, node)
> > +   list_for_each_entry(root_bus, _root_buses, node) {
> > pci_assign_unassigned_root_bus_resources(root_bus);
> > +   acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
> > +   }
> >  }
> >  
> >  void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 288fac5..f5114dc 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -680,6 +680,12 @@ static inline enum dev_dma_attr 
> > acpi_get_dma_attr(struct acpi_device *adev)
> >  
> >  #endif /* !CONFIG_ACPI */
> >  
> > +#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > +int acpi_ioapic_add(acpi_handle root);
> > +#else
> 

Re: [PATCH 1/4] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Bjorn Helgaas]

On Tue, Jul 26, 2016 at 03:19:32PM -0500, Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:14AM +0800, Rui Wang wrote:
> > IOAPICs present during system boot aren't added to ioapic_list,
> > thus are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during root bus enumeration.
> > 
> > Signed-off-by: Rui Wang 

I should have added:

Acked-by: Bjorn Helgaas 

The comments below are minor, and I'm happy if Rafael merges this
series via his tree.

> > ---
> >  drivers/acpi/internal.h |  2 --
> >  drivers/acpi/ioapic.c   |  7 ---
> >  drivers/acpi/pci_root.c | 13 -
> >  drivers/pci/setup-bus.c |  5 -
> >  include/linux/acpi.h|  6 ++
> >  5 files changed, 26 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> > index 27cc7fe..6d8e67e 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -40,10 +40,8 @@ int acpi_sysfs_init(void);
> >  void acpi_container_init(void);
> >  void acpi_memory_hotplug_init(void);
> >  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > -int acpi_ioapic_add(struct acpi_pci_root *root);
> >  int acpi_ioapic_remove(struct acpi_pci_root *root);
> >  #else
> > -static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
> 
> It would be nicer if the interface change and header file munging
> were in a separate patch so they wouldn't obscure the meat of the
> change, i.e., the addition of calls to acpi_ioapic_add().
> 
> >  static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 
> > 0; }
> >  #endif
> >  #ifdef CONFIG_ACPI_DOCK
> > diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
> > index ccdc8db..0f272e2 100644
> > --- a/drivers/acpi/ioapic.c
> > +++ b/drivers/acpi/ioapic.c
> > @@ -189,16 +189,17 @@ exit:
> > return AE_OK;
> >  }
> >  
> > -int acpi_ioapic_add(struct acpi_pci_root *root)
> > +int acpi_ioapic_add(acpi_handle root_handle)
> >  {
> > acpi_status status, retval = AE_OK;
> >  
> > -   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle,
> > +   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
> >  UINT_MAX, handle_ioapic_add, NULL,
> > -root->device->handle, (void **));
> > +root_handle, (void **));
> >  
> > return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV;
> >  }
> > +EXPORT_SYMBOL_GPL(acpi_ioapic_add);
> 
> What loadable module needs to call this?  It shouldn't be exported
> unless there is such a module.
> 
> >  int acpi_ioapic_remove(struct acpi_pci_root *root)
> >  {
> > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > index ae3fe4e..d818c61 100644
> > --- a/drivers/acpi/pci_root.c
> > +++ b/drivers/acpi/pci_root.c
> > @@ -614,7 +614,18 @@ static int acpi_pci_root_add(struct acpi_device 
> > *device,
> > if (hotadd) {
> > pcibios_resource_survey_bus(root->bus);
> > pci_assign_unassigned_root_bus_resources(root->bus);
> > -   acpi_ioapic_add(root);
> > +
> > +   /*
> > +* This is only called for the hotadd case. For the boot-time
> > +* case, we need to wait until after PCI initialization in
> > +* order to deal with IOAPICs mapped in on a PCI BAR.
> > +*
> > +* This is currently x86-specific, because acpi_ioapic_add()
> > +* is an empty function without CONFIG_ACPI_HOTPLUG_IOAPIC.
> > +* And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC
> > +* (see drivers/acpi/Kconfig).
> > +*/
> > +   acpi_ioapic_add(root->device->handle);
> > }
> >  
> > pci_lock_rescan_remove();
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > index 55641a3..e32c356 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include "pci.h"
> >  
> >  unsigned int pci_flags;
> > @@ -1779,8 +1780,10 @@ void __init pci_assign_unassigned_resources(void)
> >  {
> > struct pci_bus *root_bus;
> >  
> > -   list_for_each_entry(root_bus, _root_buses, node)
> > +   list_for_each_entry(root_bus, _root_buses, node) {
> > pci_assign_unassigned_root_bus_resources(root_bus);
> > +   acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
> > +   }
> >  }
> >  
> >  void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 288fac5..f5114dc 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -680,6 +680,12 @@ static inline enum dev_dma_attr 
> > acpi_get_dma_attr(struct acpi_device *adev)
> >  
> >  #endif /* !CONFIG_ACPI */
> >  
> > +#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > +int acpi_ioapic_add(acpi_handle root);
> > +#else
> > +static inline int 

Re: [PATCH] serial: 8250_pci: Use symbolic constants for EXAR's MPIO registers

[Jan Kiszka]

On 2016-07-26 22:14, Greg Kroah-Hartman wrote:
> On Tue, Jul 26, 2016 at 09:50:37PM +0200, Jan Kiszka wrote:
>> Less magics that only require comments.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  drivers/tty/serial/8250/8250_pci.c | 42 
>> +++---
>>  include/uapi/linux/serial_reg.h| 13 
>>  2 files changed, 34 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c 
>> b/drivers/tty/serial/8250/8250_pci.c
>> index c1d4a8f..7f77060 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -1796,18 +1796,18 @@ pci_xr17v35x_setup(struct serial_private *priv,
>>   * Setup Multipurpose Input/Output pins.
>>   */
>>  if (idx == 0) {
>> -writeb(0x00, p + 0x8f); /*MPIOINT[7:0]*/
>> -writeb(0x00, p + 0x90); /*MPIOLVL[7:0]*/
>> -writeb(0x00, p + 0x91); /*MPIO3T[7:0]*/
>> -writeb(0x00, p + 0x92); /*MPIOINV[7:0]*/
>> -writeb(0x00, p + 0x93); /*MPIOSEL[7:0]*/
>> -writeb(0x00, p + 0x94); /*MPIOOD[7:0]*/
>> -writeb(0x00, p + 0x95); /*MPIOINT[15:8]*/
>> -writeb(0x00, p + 0x96); /*MPIOLVL[15:8]*/
>> -writeb(0x00, p + 0x97); /*MPIO3T[15:8]*/
>> -writeb(0x00, p + 0x98); /*MPIOINV[15:8]*/
>> -writeb(0x00, p + 0x99); /*MPIOSEL[15:8]*/
>> -writeb(0x00, p + 0x9a); /*MPIOOD[15:8]*/
>> +writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
>>  }
>>  writeb(0x00, p + UART_EXAR_8XMODE);
>>  writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
>> @@ -1843,20 +1843,20 @@ pci_fastcom335_setup(struct serial_private *priv,
>>  switch (priv->dev->device) {
>>  case PCI_DEVICE_ID_COMMTECH_4222PCI335:
>>  case PCI_DEVICE_ID_COMMTECH_4224PCI335:
>> -writeb(0x78, p + 0x90); /* MPIOLVL[7:0] */
>> -writeb(0x00, p + 0x92); /* MPIOINV[7:0] */
>> -writeb(0x00, p + 0x93); /* MPIOSEL[7:0] */
>> +writeb(0x78, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
>>  break;
>>  case PCI_DEVICE_ID_COMMTECH_2324PCI335:
>>  case PCI_DEVICE_ID_COMMTECH_2328PCI335:
>> -writeb(0x00, p + 0x90); /* MPIOLVL[7:0] */
>> -writeb(0xc0, p + 0x92); /* MPIOINV[7:0] */
>> -writeb(0xc0, p + 0x93); /* MPIOSEL[7:0] */
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0xc0, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0xc0, p + UART_EXAR_MPIOSEL_7_0);
>>  break;
>>  }
>> -writeb(0x00, p + 0x8f); /* MPIOINT[7:0] */
>> -writeb(0x00, p + 0x91); /* MPIO3T[7:0] */
>> -writeb(0x00, p + 0x94); /* MPIOOD[7:0] */
>> +writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
>>  }
>>  writeb(0x00, p + UART_EXAR_8XMODE);
>>  writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
>> diff --git a/include/uapi/linux/serial_reg.h 
>> b/include/uapi/linux/serial_reg.h
>> index 1e5ac4e7..d176448 100644
>> --- a/include/uapi/linux/serial_reg.h
>> +++ b/include/uapi/linux/serial_reg.h
>> @@ -376,5 +376,18 @@
>>  #define UART_EXAR_TXTRG 0x0a/* Tx FIFO trigger level 
>> write-only */
>>  #define UART_EXAR_RXTRG 0x0b/* Rx FIFO trigger level 
>> write-only */
>>  
>> +#define UART_EXAR_MPIOINT_7_0   0x8f/* MPIOINT[7:0] */
>> +#define UART_EXAR_MPIOLVL_7_0   0x90/* MPIOLVL[7:0] */
>> +#define UART_EXAR_MPIO3T_7_00x91/* MPIO3T[7:0] */
>> +#define UART_EXAR_MPIOINV_7_0   0x92/* MPIOINV[7:0] */
>> +#define UART_EXAR_MPIOSEL_7_0   0x93/* MPIOSEL[7:0] */
>> +#define UART_EXAR_MPIOOD_7_00x94/* MPIOOD[7:0] */
>> +#define UART_EXAR_MPIOINT_15_8  0x95/* MPIOINT[15:8] */
>> +#define UART_EXAR_MPIOLVL_15_8  0x96/* MPIOLVL[15:8] */
>> +#define UART_EXAR_MPIO3T_15_8   0x97/* MPIO3T[15:8] */
>> +#define UART_EXAR_MPIOINV_15_8  

Re: [PATCH] serial: 8250_pci: Use symbolic constants for EXAR's MPIO registers

[Jan Kiszka]

On 2016-07-26 22:14, Greg Kroah-Hartman wrote:
> On Tue, Jul 26, 2016 at 09:50:37PM +0200, Jan Kiszka wrote:
>> Less magics that only require comments.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  drivers/tty/serial/8250/8250_pci.c | 42 
>> +++---
>>  include/uapi/linux/serial_reg.h| 13 
>>  2 files changed, 34 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c 
>> b/drivers/tty/serial/8250/8250_pci.c
>> index c1d4a8f..7f77060 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -1796,18 +1796,18 @@ pci_xr17v35x_setup(struct serial_private *priv,
>>   * Setup Multipurpose Input/Output pins.
>>   */
>>  if (idx == 0) {
>> -writeb(0x00, p + 0x8f); /*MPIOINT[7:0]*/
>> -writeb(0x00, p + 0x90); /*MPIOLVL[7:0]*/
>> -writeb(0x00, p + 0x91); /*MPIO3T[7:0]*/
>> -writeb(0x00, p + 0x92); /*MPIOINV[7:0]*/
>> -writeb(0x00, p + 0x93); /*MPIOSEL[7:0]*/
>> -writeb(0x00, p + 0x94); /*MPIOOD[7:0]*/
>> -writeb(0x00, p + 0x95); /*MPIOINT[15:8]*/
>> -writeb(0x00, p + 0x96); /*MPIOLVL[15:8]*/
>> -writeb(0x00, p + 0x97); /*MPIO3T[15:8]*/
>> -writeb(0x00, p + 0x98); /*MPIOINV[15:8]*/
>> -writeb(0x00, p + 0x99); /*MPIOSEL[15:8]*/
>> -writeb(0x00, p + 0x9a); /*MPIOOD[15:8]*/
>> +writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
>>  }
>>  writeb(0x00, p + UART_EXAR_8XMODE);
>>  writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
>> @@ -1843,20 +1843,20 @@ pci_fastcom335_setup(struct serial_private *priv,
>>  switch (priv->dev->device) {
>>  case PCI_DEVICE_ID_COMMTECH_4222PCI335:
>>  case PCI_DEVICE_ID_COMMTECH_4224PCI335:
>> -writeb(0x78, p + 0x90); /* MPIOLVL[7:0] */
>> -writeb(0x00, p + 0x92); /* MPIOINV[7:0] */
>> -writeb(0x00, p + 0x93); /* MPIOSEL[7:0] */
>> +writeb(0x78, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
>>  break;
>>  case PCI_DEVICE_ID_COMMTECH_2324PCI335:
>>  case PCI_DEVICE_ID_COMMTECH_2328PCI335:
>> -writeb(0x00, p + 0x90); /* MPIOLVL[7:0] */
>> -writeb(0xc0, p + 0x92); /* MPIOINV[7:0] */
>> -writeb(0xc0, p + 0x93); /* MPIOSEL[7:0] */
>> +writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
>> +writeb(0xc0, p + UART_EXAR_MPIOINV_7_0);
>> +writeb(0xc0, p + UART_EXAR_MPIOSEL_7_0);
>>  break;
>>  }
>> -writeb(0x00, p + 0x8f); /* MPIOINT[7:0] */
>> -writeb(0x00, p + 0x91); /* MPIO3T[7:0] */
>> -writeb(0x00, p + 0x94); /* MPIOOD[7:0] */
>> +writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
>> +writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
>>  }
>>  writeb(0x00, p + UART_EXAR_8XMODE);
>>  writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
>> diff --git a/include/uapi/linux/serial_reg.h 
>> b/include/uapi/linux/serial_reg.h
>> index 1e5ac4e7..d176448 100644
>> --- a/include/uapi/linux/serial_reg.h
>> +++ b/include/uapi/linux/serial_reg.h
>> @@ -376,5 +376,18 @@
>>  #define UART_EXAR_TXTRG 0x0a/* Tx FIFO trigger level 
>> write-only */
>>  #define UART_EXAR_RXTRG 0x0b/* Rx FIFO trigger level 
>> write-only */
>>  
>> +#define UART_EXAR_MPIOINT_7_0   0x8f/* MPIOINT[7:0] */
>> +#define UART_EXAR_MPIOLVL_7_0   0x90/* MPIOLVL[7:0] */
>> +#define UART_EXAR_MPIO3T_7_00x91/* MPIO3T[7:0] */
>> +#define UART_EXAR_MPIOINV_7_0   0x92/* MPIOINV[7:0] */
>> +#define UART_EXAR_MPIOSEL_7_0   0x93/* MPIOSEL[7:0] */
>> +#define UART_EXAR_MPIOOD_7_00x94/* MPIOOD[7:0] */
>> +#define UART_EXAR_MPIOINT_15_8  0x95/* MPIOINT[15:8] */
>> +#define UART_EXAR_MPIOLVL_15_8  0x96/* MPIOLVL[15:8] */
>> +#define UART_EXAR_MPIO3T_15_8   0x97/* MPIO3T[15:8] */
>> +#define UART_EXAR_MPIOINV_15_8  0x98/* 

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Kees Cook]

On Tue, Jul 26, 2016 at 10:29 AM, Michael Kerrisk (man-pages)
 wrote:
> On 26 July 2016 at 18:52, Kees Cook  wrote:
>> On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
>>  wrote:
>>> "Michael Kerrisk (man-pages)"  writes:
>>>
 Hello Eric,

 I realized I had a question after the last mail.

 On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>
> This patchset addresses two use cases:
> - Implement a sane upper bound on the number of namespaces.
> - Provide a way for sandboxes to limit the attack surface from
>   namespaces.

 Can you say more about the second point? What exactly is the
 problem that is being addressed, and how does the patch series
 address it? (It would be good to have those details in the
 revised commit message...)
>>>
>>> At some point it was reported that seccomp was not sufficient to disable
>>> namespace creation.  I need to go back and look at that claim to see
>>> which set of circumstances that was referring to.  Seccomp doesn't stack
>>> so I can see why it is an issue.
>>
>> seccomp does stack. The trouble usually comes from a perception that
>> seccomp overhead is not trivial, so setting a system-wide policy is a
>> bit of a large hammer for such a limitiation. Also, at the time,
>> seccomp could be bypasses with ptrace, but this (as of v4.8) is no
>> longer true.
>
> Sounds like someone needs to send me a patch for the seccomp.2 man page?

It's on my TODO list, no worries. :) I'm waiting for it to land in
Linus's tree first. It's only been in -next so far.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Kees Cook]

On Tue, Jul 26, 2016 at 10:29 AM, Michael Kerrisk (man-pages)
 wrote:
> On 26 July 2016 at 18:52, Kees Cook  wrote:
>> On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
>>  wrote:
>>> "Michael Kerrisk (man-pages)"  writes:
>>>
 Hello Eric,

 I realized I had a question after the last mail.

 On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>
> This patchset addresses two use cases:
> - Implement a sane upper bound on the number of namespaces.
> - Provide a way for sandboxes to limit the attack surface from
>   namespaces.

 Can you say more about the second point? What exactly is the
 problem that is being addressed, and how does the patch series
 address it? (It would be good to have those details in the
 revised commit message...)
>>>
>>> At some point it was reported that seccomp was not sufficient to disable
>>> namespace creation.  I need to go back and look at that claim to see
>>> which set of circumstances that was referring to.  Seccomp doesn't stack
>>> so I can see why it is an issue.
>>
>> seccomp does stack. The trouble usually comes from a perception that
>> seccomp overhead is not trivial, so setting a system-wide policy is a
>> bit of a large hammer for such a limitiation. Also, at the time,
>> seccomp could be bypasses with ptrace, but this (as of v4.8) is no
>> longer true.
>
> Sounds like someone needs to send me a patch for the seccomp.2 man page?

It's on my TODO list, no worries. :) I'm waiting for it to land in
Linus's tree first. It's only been in -next so far.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH V2 3/6] perf tools: add infrastructure for PMU specific configuration

[Jiri Olsa]

On Fri, Jul 22, 2016 at 12:24:48PM -0600, Mathieu Poirier wrote:

SNIP

> > diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> > --- a/tools/perf/util/parse-events.y
> > +++ b/tools/perf/util/parse-events.y
> > @@ -602,12 +602,12 @@ PE_NAME array '=' PE_VALUE
> > $$ = term;
> >  }
> >  |
> > -PE_DRV_CFG_TERM
> > +'@' PE_DRV_CFG_TERM
> >  {
> > struct parse_events_term *term;
> >
> > ABORT_ON(parse_events_term__str(, 
> > PARSE_EVENTS__TERM_TYPE_DRV_CFG,
> > -   $1, $1, &@1, NULL));
> > +   $2, $2, &@2, NULL));
> > $$ = term;
> >  }
> >
> 
> I've been experimenting with the above solution and it is not yielding
> the results one might think at first glance.
> 
> If we use the example: -e event/@cfg1/ ...
> 
> First if we leave things exactly the way they are suggested in the
> code snippet flex doesn't know what do to with the '@' character and
> returns an error.  To deal with that a new clause
> 
> "@"{ return '@'; }
> 
> can be inserted in the config state.  But that doesn't link '@' with
> 'cfg1', and 'cfg1' gets interpreted as a PE_NAME.  Introducing a new
> state upon hitting '@' would get us around that but we are moving away
> from our initial goal of keeping things simple.

hum, then how about keeping the flex atoms simple like for the
other terms and do something like below.. untested ;-)

thanks,
jirka


---
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 1f7e11a6c5b3..8ba228e1c150 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -53,16 +53,6 @@ static int str(yyscan_t scanner, int token)
return token;
 }
 
-static int drv_str(yyscan_t scanner, int token)
-{
-   YYSTYPE *yylval = parse_events_get_lval(scanner);
-   char *text = parse_events_get_text(scanner);
-
-   /* Strip off the '@' */
-   yylval->str = strdup(text + 1);
-   return token;
-}
-
 #define REWIND(__alloc)\
 do {   \
YYSTYPE *__yylval = parse_events_get_lval(yyscanner);   \
@@ -134,7 +124,6 @@ num_hex 0x[a-fA-F0-9]+
 num_raw_hex[a-fA-F0-9]+
 name   [a-zA-Z_*?][a-zA-Z0-9_*?.]*
 name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.:]*
-drv_cfg_term   [a-zA-Z0-9_\.]+(=[a-zA-Z0-9_*?\.:]+)?
 /* If you add a modifier you need to update check_modifier() */
 modifier_event [ukhpPGHSDI]+
 modifier_bp[rwx]{1,3}
@@ -216,11 +205,11 @@ no-inherit{ return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_NOINHERIT); }
 overwrite  { return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_OVERWRITE); }
 no-overwrite   { return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_NOOVERWRITE); }
 ,  { return ','; }
+"@"{ return '@'; }
 "/"{ BEGIN(INITIAL); return '/'; }
 {name_minus}   { return str(yyscanner, PE_NAME); }
 \[all\]{ return PE_ARRAY_ALL; }
 "["{ BEGIN(array); return '['; }
-@{drv_cfg_term}{ return drv_str(yyscanner, PE_DRV_CFG_TERM); }
 }
 
 {
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 879115f93edc..7e03e93dabca 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -602,12 +602,12 @@ PE_NAME array '=' PE_VALUE
$$ = term;
 }
 |
-PE_DRV_CFG_TERM
+'@' PE_NAME '=' PE_NAME
 {
struct parse_events_term *term;
 
ABORT_ON(parse_events_term__str(, PARSE_EVENTS__TERM_TYPE_DRV_CFG,
-   $1, $1, &@1, NULL));
+   $2, $4, &@2, &@4));
$$ = term;
 }
 

Re: [PATCH V2 3/6] perf tools: add infrastructure for PMU specific configuration

[Jiri Olsa]

On Fri, Jul 22, 2016 at 12:24:48PM -0600, Mathieu Poirier wrote:

SNIP

> > diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> > --- a/tools/perf/util/parse-events.y
> > +++ b/tools/perf/util/parse-events.y
> > @@ -602,12 +602,12 @@ PE_NAME array '=' PE_VALUE
> > $$ = term;
> >  }
> >  |
> > -PE_DRV_CFG_TERM
> > +'@' PE_DRV_CFG_TERM
> >  {
> > struct parse_events_term *term;
> >
> > ABORT_ON(parse_events_term__str(, 
> > PARSE_EVENTS__TERM_TYPE_DRV_CFG,
> > -   $1, $1, &@1, NULL));
> > +   $2, $2, &@2, NULL));
> > $$ = term;
> >  }
> >
> 
> I've been experimenting with the above solution and it is not yielding
> the results one might think at first glance.
> 
> If we use the example: -e event/@cfg1/ ...
> 
> First if we leave things exactly the way they are suggested in the
> code snippet flex doesn't know what do to with the '@' character and
> returns an error.  To deal with that a new clause
> 
> "@"{ return '@'; }
> 
> can be inserted in the config state.  But that doesn't link '@' with
> 'cfg1', and 'cfg1' gets interpreted as a PE_NAME.  Introducing a new
> state upon hitting '@' would get us around that but we are moving away
> from our initial goal of keeping things simple.

hum, then how about keeping the flex atoms simple like for the
other terms and do something like below.. untested ;-)

thanks,
jirka


---
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 1f7e11a6c5b3..8ba228e1c150 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -53,16 +53,6 @@ static int str(yyscan_t scanner, int token)
return token;
 }
 
-static int drv_str(yyscan_t scanner, int token)
-{
-   YYSTYPE *yylval = parse_events_get_lval(scanner);
-   char *text = parse_events_get_text(scanner);
-
-   /* Strip off the '@' */
-   yylval->str = strdup(text + 1);
-   return token;
-}
-
 #define REWIND(__alloc)\
 do {   \
YYSTYPE *__yylval = parse_events_get_lval(yyscanner);   \
@@ -134,7 +124,6 @@ num_hex 0x[a-fA-F0-9]+
 num_raw_hex[a-fA-F0-9]+
 name   [a-zA-Z_*?][a-zA-Z0-9_*?.]*
 name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.:]*
-drv_cfg_term   [a-zA-Z0-9_\.]+(=[a-zA-Z0-9_*?\.:]+)?
 /* If you add a modifier you need to update check_modifier() */
 modifier_event [ukhpPGHSDI]+
 modifier_bp[rwx]{1,3}
@@ -216,11 +205,11 @@ no-inherit{ return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_NOINHERIT); }
 overwrite  { return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_OVERWRITE); }
 no-overwrite   { return term(yyscanner, 
PARSE_EVENTS__TERM_TYPE_NOOVERWRITE); }
 ,  { return ','; }
+"@"{ return '@'; }
 "/"{ BEGIN(INITIAL); return '/'; }
 {name_minus}   { return str(yyscanner, PE_NAME); }
 \[all\]{ return PE_ARRAY_ALL; }
 "["{ BEGIN(array); return '['; }
-@{drv_cfg_term}{ return drv_str(yyscanner, PE_DRV_CFG_TERM); }
 }
 
 {
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 879115f93edc..7e03e93dabca 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -602,12 +602,12 @@ PE_NAME array '=' PE_VALUE
$$ = term;
 }
 |
-PE_DRV_CFG_TERM
+'@' PE_NAME '=' PE_NAME
 {
struct parse_events_term *term;
 
ABORT_ON(parse_events_term__str(, PARSE_EVENTS__TERM_TYPE_DRV_CFG,
-   $1, $1, &@1, NULL));
+   $2, $4, &@2, &@4));
$$ = term;
 }
 

Re: [PATCH] [RFC] Introduce mmap randomization

[Nick Kralevich]

My apologies in advance if I misunderstand the purposes of this patch.

IIUC, this patch adds a random gap between various mmap() mappings,
with the goal of ensuring that both the mmap base address and gaps
between pages are randomized.

If that's the goal, please note that this behavior has caused
significant performance problems to Android in the past. Specifically,
random gaps between mmap()ed regions causes memory space
fragmentation. After a program runs for a long time, the ability to
find large contiguous blocks of memory becomes impossible, and mmap()s
fail due to lack of a large enough address space.

This isn't just a theoretical concern. Android actually hit this on
kernels prior to
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa466780a754154531b44c2086f6618cee3a8
. Before that patch, the gaps between mmap()ed pages were randomized.
See the discussion at:

  
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073082.html
  http://marc.info/?t=13207095745=1=2

We ended up having to work around this problem in the following commits:

  
https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f592d56caab5e2a259c
  https://android.googlesource.com/platform/art/+/51e5386
  https://android.googlesource.com/platform/art/+/f94b781

If this behavior was re-introduced, it's likely to cause
hard-to-reproduce problems, and I suspect Android based distributions
would tend to disable this feature either globally, or for
applications which make a large number of mmap() calls.

-- Nick



On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
> From: William Roberts 
>
> This patch introduces the ability randomize mmap locations where the
> address is not requested, for instance when ld is allocating pages for
> shared libraries. It chooses to randomize based on the current
> personality for ASLR.
>
> Currently, allocations are done sequentially within unmapped address
> space gaps. This may happen top down or bottom up depending on scheme.
>
> For instance these mmap calls produce contiguous mappings:
> int size = getpagesize();
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40026000
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000
>
> Note no gap between.
>
> After patches:
> int size = getpagesize();
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400b4000
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40055000
>
> Note gap between.
>
> Using the test program mentioned here, that allocates fixed sized blocks
> till exhaustion: 
> https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
> no difference was noticed in the number of allocations. Most varied from
> run to run, but were always within a few allocations of one another
> between patched and un-patched runs.
>
> Performance Measurements:
> Using strace with -T option and filtering for mmap on the program
> ls shows a slowdown of approximate 3.7%
>
> Signed-off-by: William Roberts 
> ---
>  mm/mmap.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index de2c176..7891272 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -1582,6 +1583,24 @@ unacct_error:
> return error;
>  }
>
> +/*
> + * Generate a random address within a range. This differs from 
> randomize_addr() by randomizing
> + * on len sized chunks. This helps prevent fragmentation of the virtual 
> memory map.
> + */
> +static unsigned long randomize_mmap(unsigned long start, unsigned long end, 
> unsigned long len)
> +{
> +   unsigned long slots;
> +
> +   if ((current->personality & ADDR_NO_RANDOMIZE) || !randomize_va_space)
> +   return 0;
> +
> +   slots = (end - start)/len;
> +   if (!slots)
> +   return 0;
> +
> +   return PAGE_ALIGN(start + ((get_random_long() % slots) * len));
> +}
> +
>  unsigned long unmapped_area(struct vm_unmapped_area_info *info)
>  {
> /*
> @@ -1676,6 +1695,8 @@ found:
> if (gap_start < info->low_limit)
> gap_start = info->low_limit;
>
> +   gap_start = randomize_mmap(gap_start, gap_end, length) ? : gap_start;
> +
> /* Adjust gap address to the desired alignment */
> gap_start += (info->align_offset - gap_start) & info->align_mask;
>
> @@ -1775,6 +1796,9 @@ found:
>  found_highest:
> /* Compute highest gap address at the desired alignment */
> gap_end -= info->length;
> +
> +   gap_end = randomize_mmap(gap_start, gap_end, length) ? : gap_end;
> +
> gap_end -= (gap_end - info->align_offset) & info->align_mask;
>
> VM_BUG_ON(gap_end < info->low_limit);
> --
> 1.9.1
>



-- 
Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [PATCH] [RFC] Introduce mmap randomization

[Nick Kralevich]

My apologies in advance if I misunderstand the purposes of this patch.

IIUC, this patch adds a random gap between various mmap() mappings,
with the goal of ensuring that both the mmap base address and gaps
between pages are randomized.

If that's the goal, please note that this behavior has caused
significant performance problems to Android in the past. Specifically,
random gaps between mmap()ed regions causes memory space
fragmentation. After a program runs for a long time, the ability to
find large contiguous blocks of memory becomes impossible, and mmap()s
fail due to lack of a large enough address space.

This isn't just a theoretical concern. Android actually hit this on
kernels prior to
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dbaa466780a754154531b44c2086f6618cee3a8
. Before that patch, the gaps between mmap()ed pages were randomized.
See the discussion at:

  
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073082.html
  http://marc.info/?t=13207095745=1=2

We ended up having to work around this problem in the following commits:

  
https://android.googlesource.com/platform/dalvik/+/311886c6c6fcd3b531531f592d56caab5e2a259c
  https://android.googlesource.com/platform/art/+/51e5386
  https://android.googlesource.com/platform/art/+/f94b781

If this behavior was re-introduced, it's likely to cause
hard-to-reproduce problems, and I suspect Android based distributions
would tend to disable this feature either globally, or for
applications which make a large number of mmap() calls.

-- Nick



On Tue, Jul 26, 2016 at 11:22 AM,   wrote:
> From: William Roberts 
>
> This patch introduces the ability randomize mmap locations where the
> address is not requested, for instance when ld is allocating pages for
> shared libraries. It chooses to randomize based on the current
> personality for ASLR.
>
> Currently, allocations are done sequentially within unmapped address
> space gaps. This may happen top down or bottom up depending on scheme.
>
> For instance these mmap calls produce contiguous mappings:
> int size = getpagesize();
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40026000
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000
>
> Note no gap between.
>
> After patches:
> int size = getpagesize();
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400b4000
> mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40055000
>
> Note gap between.
>
> Using the test program mentioned here, that allocates fixed sized blocks
> till exhaustion: 
> https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
> no difference was noticed in the number of allocations. Most varied from
> run to run, but were always within a few allocations of one another
> between patched and un-patched runs.
>
> Performance Measurements:
> Using strace with -T option and filtering for mmap on the program
> ls shows a slowdown of approximate 3.7%
>
> Signed-off-by: William Roberts 
> ---
>  mm/mmap.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index de2c176..7891272 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -1582,6 +1583,24 @@ unacct_error:
> return error;
>  }
>
> +/*
> + * Generate a random address within a range. This differs from 
> randomize_addr() by randomizing
> + * on len sized chunks. This helps prevent fragmentation of the virtual 
> memory map.
> + */
> +static unsigned long randomize_mmap(unsigned long start, unsigned long end, 
> unsigned long len)
> +{
> +   unsigned long slots;
> +
> +   if ((current->personality & ADDR_NO_RANDOMIZE) || !randomize_va_space)
> +   return 0;
> +
> +   slots = (end - start)/len;
> +   if (!slots)
> +   return 0;
> +
> +   return PAGE_ALIGN(start + ((get_random_long() % slots) * len));
> +}
> +
>  unsigned long unmapped_area(struct vm_unmapped_area_info *info)
>  {
> /*
> @@ -1676,6 +1695,8 @@ found:
> if (gap_start < info->low_limit)
> gap_start = info->low_limit;
>
> +   gap_start = randomize_mmap(gap_start, gap_end, length) ? : gap_start;
> +
> /* Adjust gap address to the desired alignment */
> gap_start += (info->align_offset - gap_start) & info->align_mask;
>
> @@ -1775,6 +1796,9 @@ found:
>  found_highest:
> /* Compute highest gap address at the desired alignment */
> gap_end -= info->length;
> +
> +   gap_end = randomize_mmap(gap_start, gap_end, length) ? : gap_end;
> +
> gap_end -= (gap_end - info->align_offset) & info->align_mask;
>
> VM_BUG_ON(gap_end < info->low_limit);
> --
> 1.9.1
>



-- 
Nick Kralevich | Android Security | n...@google.com | 650.214.4037

[GIT PULL] platform-drivers-x86 for 4.8-1

[Darren Hart]

Hi Linus,

The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5:

  Linux 4.7-rc3 (2016-06-12 07:20:35 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.8-1

for you to fetch changes up to 332e081225fc2a657aa587c42943d5f5a7dae88b:

  intel-vbtn: new driver for Intel Virtual Button (2016-07-22 13:17:40 -0700)

Thanks,

Darren Hart
Intel Open Source Technology Center


platform-drivers-x86 for 4.8-1

Several new quirks and tweaks for new platforms to existing laptop drivers. A
new ACPI virtual power button driver, similar to the intel-hid driver. A rework
of the dell keymap, using a single sparse keymap for all machines. A few fixes
and cleanups.

intel-vbtn:
 - new driver for Intel Virtual Button

intel_pmc_core:
 - Convert to DEFINE_DEBUGFS_ATTRIBUTE

fujitsu-laptop:
 - Rework brightness of eco led

asus-wmi:
 - Add quirk_no_rfkill_wapf4 for the Asus X456UA
 - Add quirk_no_rfkill_wapf4 for the Asus X456UF
 - Add quirk_no_rfkill for the Asus Z550MA
 - Add quirk_no_rfkill for the Asus U303LB
 - Add quirk_no_rfkill for the Asus N552VW
 - Create quirk for airplane_mode LED
 - Add ambient light sensor toggle key

asus-wireless:
 - Toggle airplane mode LED

intel_telemetry:
 - Remove Monitor MWAIT feature dependency

intel-hid:
 - Remove duplicated acpi_remove_notify_handler

fujitsu-laptop:
 - Add support for eco LED
 - Support touchpad toggle hotkey on Skylake-based models
 - Remove unused macros
 - Use module name in debug messages

hp-wmi:
 - Fix wifi cannot be hard-unblocked

toshiba_acpi:
 - Bump driver version and update copyright year
 - Remove the position sysfs entry
 - Add IIO interface for accelerometer axis data

dell-wmi:
 - Add a WMI event code for display on/off
 - Generate one sparse keymap for all machines
 - Add information about other WMI event codes
 - Sort WMI event codes and update comments
 - Ignore WMI event code 0xe045


AceLan Kao (1):
  intel-vbtn: new driver for Intel Virtual Button

Alex Hung (3):
  dell-wmi: Add a WMI event code for display on/off
  hp-wmi: Fix wifi cannot be hard-unblocked
  intel-hid: Remove duplicated acpi_remove_notify_handler

Andy Shevchenko (1):
  intel_pmc_core: Convert to DEFINE_DEBUGFS_ATTRIBUTE

Azael Avalos (3):
  toshiba_acpi: Add IIO interface for accelerometer axis data
  toshiba_acpi: Remove the position sysfs entry
  toshiba_acpi: Bump driver version and update copyright year

João Paulo Rechi Vita (7):
  asus-wireless: Toggle airplane mode LED
  asus-wmi: Create quirk for airplane_mode LED
  asus-wmi: Add quirk_no_rfkill for the Asus N552VW
  asus-wmi: Add quirk_no_rfkill for the Asus U303LB
  asus-wmi: Add quirk_no_rfkill for the Asus Z550MA
  asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF
  asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UA

Matej Groma (2):
  fujitsu-laptop: Add support for eco LED
  fujitsu-laptop: Rework brightness of eco led

Michał Kępień (3):
  fujitsu-laptop: Use module name in debug messages
  fujitsu-laptop: Remove unused macros
  fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

Nick Leiten (1):
  asus-wmi: Add ambient light sensor toggle key

Pali Rohár (4):
  dell-wmi: Ignore WMI event code 0xe045
  dell-wmi: Sort WMI event codes and update comments
  dell-wmi: Add information about other WMI event codes
  dell-wmi: Generate one sparse keymap for all machines

Yu, Ong Hock (1):
  intel_telemetry: Remove Monitor MWAIT feature dependency

 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  15 ++
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/asus-nb-wmi.c |  50 -
 drivers/platform/x86/asus-wireless.c   |  91 +++-
 drivers/platform/x86/asus-wmi.c|   8 +-
 drivers/platform/x86/asus-wmi.h|   1 +
 drivers/platform/x86/dell-wmi.c| 293 ++---
 drivers/platform/x86/fujitsu-laptop.c  |  81 ++-
 drivers/platform/x86/hp-wmi.c  |   7 +-
 drivers/platform/x86/intel-hid.c   |   5 +-
 drivers/platform/x86/intel-vbtn.c  | 188 
 drivers/platform/x86/intel_pmc_core.c  |  45 +---
 drivers/platform/x86/intel_pmc_core.h  |   3 +-
 drivers/platform/x86/intel_telemetry_debugfs.c |   2 +-
 drivers/platform/x86/intel_telemetry_pltdrv.c  |   2 +-
 drivers/platform/x86/toshiba_acpi.c| 136 +---
 17 files changed, 723 insertions(+), 211 deletions(-)
 create mode 100644 drivers/platform/x86/intel-vbtn.c

-- 
Darren Hart
Intel Open Source Technology Center

[GIT PULL] platform-drivers-x86 for 4.8-1

[Darren Hart]

Hi Linus,

The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5:

  Linux 4.7-rc3 (2016-06-12 07:20:35 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.8-1

for you to fetch changes up to 332e081225fc2a657aa587c42943d5f5a7dae88b:

  intel-vbtn: new driver for Intel Virtual Button (2016-07-22 13:17:40 -0700)

Thanks,

Darren Hart
Intel Open Source Technology Center


platform-drivers-x86 for 4.8-1

Several new quirks and tweaks for new platforms to existing laptop drivers. A
new ACPI virtual power button driver, similar to the intel-hid driver. A rework
of the dell keymap, using a single sparse keymap for all machines. A few fixes
and cleanups.

intel-vbtn:
 - new driver for Intel Virtual Button

intel_pmc_core:
 - Convert to DEFINE_DEBUGFS_ATTRIBUTE

fujitsu-laptop:
 - Rework brightness of eco led

asus-wmi:
 - Add quirk_no_rfkill_wapf4 for the Asus X456UA
 - Add quirk_no_rfkill_wapf4 for the Asus X456UF
 - Add quirk_no_rfkill for the Asus Z550MA
 - Add quirk_no_rfkill for the Asus U303LB
 - Add quirk_no_rfkill for the Asus N552VW
 - Create quirk for airplane_mode LED
 - Add ambient light sensor toggle key

asus-wireless:
 - Toggle airplane mode LED

intel_telemetry:
 - Remove Monitor MWAIT feature dependency

intel-hid:
 - Remove duplicated acpi_remove_notify_handler

fujitsu-laptop:
 - Add support for eco LED
 - Support touchpad toggle hotkey on Skylake-based models
 - Remove unused macros
 - Use module name in debug messages

hp-wmi:
 - Fix wifi cannot be hard-unblocked

toshiba_acpi:
 - Bump driver version and update copyright year
 - Remove the position sysfs entry
 - Add IIO interface for accelerometer axis data

dell-wmi:
 - Add a WMI event code for display on/off
 - Generate one sparse keymap for all machines
 - Add information about other WMI event codes
 - Sort WMI event codes and update comments
 - Ignore WMI event code 0xe045


AceLan Kao (1):
  intel-vbtn: new driver for Intel Virtual Button

Alex Hung (3):
  dell-wmi: Add a WMI event code for display on/off
  hp-wmi: Fix wifi cannot be hard-unblocked
  intel-hid: Remove duplicated acpi_remove_notify_handler

Andy Shevchenko (1):
  intel_pmc_core: Convert to DEFINE_DEBUGFS_ATTRIBUTE

Azael Avalos (3):
  toshiba_acpi: Add IIO interface for accelerometer axis data
  toshiba_acpi: Remove the position sysfs entry
  toshiba_acpi: Bump driver version and update copyright year

João Paulo Rechi Vita (7):
  asus-wireless: Toggle airplane mode LED
  asus-wmi: Create quirk for airplane_mode LED
  asus-wmi: Add quirk_no_rfkill for the Asus N552VW
  asus-wmi: Add quirk_no_rfkill for the Asus U303LB
  asus-wmi: Add quirk_no_rfkill for the Asus Z550MA
  asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF
  asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UA

Matej Groma (2):
  fujitsu-laptop: Add support for eco LED
  fujitsu-laptop: Rework brightness of eco led

Michał Kępień (3):
  fujitsu-laptop: Use module name in debug messages
  fujitsu-laptop: Remove unused macros
  fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

Nick Leiten (1):
  asus-wmi: Add ambient light sensor toggle key

Pali Rohár (4):
  dell-wmi: Ignore WMI event code 0xe045
  dell-wmi: Sort WMI event codes and update comments
  dell-wmi: Add information about other WMI event codes
  dell-wmi: Generate one sparse keymap for all machines

Yu, Ong Hock (1):
  intel_telemetry: Remove Monitor MWAIT feature dependency

 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  15 ++
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/asus-nb-wmi.c |  50 -
 drivers/platform/x86/asus-wireless.c   |  91 +++-
 drivers/platform/x86/asus-wmi.c|   8 +-
 drivers/platform/x86/asus-wmi.h|   1 +
 drivers/platform/x86/dell-wmi.c| 293 ++---
 drivers/platform/x86/fujitsu-laptop.c  |  81 ++-
 drivers/platform/x86/hp-wmi.c  |   7 +-
 drivers/platform/x86/intel-hid.c   |   5 +-
 drivers/platform/x86/intel-vbtn.c  | 188 
 drivers/platform/x86/intel_pmc_core.c  |  45 +---
 drivers/platform/x86/intel_pmc_core.h  |   3 +-
 drivers/platform/x86/intel_telemetry_debugfs.c |   2 +-
 drivers/platform/x86/intel_telemetry_pltdrv.c  |   2 +-
 drivers/platform/x86/toshiba_acpi.c| 136 +---
 17 files changed, 723 insertions(+), 211 deletions(-)
 create mode 100644 drivers/platform/x86/intel-vbtn.c

-- 
Darren Hart
Intel Open Source Technology Center

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Rafael J. Wysocki]

On Tuesday, July 26, 2016 01:31:00 PM Kees Cook wrote:
> On Tue, Jul 26, 2016 at 1:15 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, July 26, 2016 09:39:05 AM Josh Poimboeuf wrote:
> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
> >> > Hi,
> >> >
> >> > The following commit:
> >> >
> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
> >> > Author: Josh Poimboeuf 
> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
> >> >
> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
> >> >
> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
> >> >
> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
> >> >
> >> > is reported to cause a resume-from-hibernation regression due to an 
> >> > attempt
> >> > to execute an NX page (we've seen quite a bit of that recently).
> >> >
> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
> >> > we'll
> >> > need to revert the above I'm afraid.
> >
> > So the bug is still there in 4.7 and it goes away after reverting the above
> > commit.  I guess I'll send a revert then.
> 
> To make sure I understand:
> 
> There are two separate bugs here that break hibernation?

Yes, there are.

The first one is the BZ 150021 as reported here.

The second one is the clash with new ASLR-related changes as reported by Boris.

Thanks,
Rafael

Re: [tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

[Kees Cook]

On Tue, Jul 26, 2016 at 10:37 AM, tip-bot for Borislav Petkov
 wrote:
> Commit-ID:  efaad554b4ffae1840a2759e09e21325ddbc8b05
> Gitweb: http://git.kernel.org/tip/efaad554b4ffae1840a2759e09e21325ddbc8b05
> Author: Borislav Petkov 
> AuthorDate: Tue, 26 Jul 2016 11:51:38 +0200
> Committer:  Ingo Molnar 
> CommitDate: Tue, 26 Jul 2016 19:32:57 +0200
>
> x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y
>
> CONFIG_RANDOMIZE_MEMORY=y randomizes the physical memmap and thus the
> address where the initrd is located. Therefore, we need to add the
> offset KASLR put us to in order to find the initrd again on the AP path.
>
> In the future, we will get rid of the initrd address caching and query
> the address on both the BSP and AP paths but that would need more work.
>
> Thanks to Nicolai Stange for the good bisection and debugging work.
>
> Reported-and-tested-by: Nicolai Stange 
> Signed-off-by: Borislav Petkov 
> Cc: Kees Cook 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Link: http://lkml.kernel.org/r/20160726095138.3470-1...@alien8.de
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/kernel/cpu/microcode/intel.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
> b/arch/x86/kernel/cpu/microcode/intel.c
> index 6515c80..0f97ae9 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -793,10 +793,10 @@ void __init load_ucode_intel_bsp(void)
>  void load_ucode_intel_ap(void)
>  {
> struct ucode_blobs *blobs_p;
> +   unsigned long *ptrs, start = 0;
> struct mc_saved_data *mcs;
> struct ucode_cpu_info uci;
> enum ucode_state ret;
> -   unsigned long *ptrs;
>
>  #ifdef CONFIG_X86_32
> mcs = (struct mc_saved_data *)__pa_nodebug(_saved_data);
> @@ -815,8 +815,20 @@ void load_ucode_intel_ap(void)
> if (!mcs->num_saved)
> return;
>
> +   if (blobs_p->valid) {
> +   start = blobs_p->start;
> +
> +#ifdef CONFIG_RANDOMIZE_MEMORY

These ifdefs aren't needed if we added a no-op __PAGE_OFFSET_BASE to
the 32-bit page table headers. Then the compiler will DTRT with the
start calculation. When CONFIG_RANDOMIZE_MEMORY is set, start will
have a non-zero value, and when not set it'll be 0.

> +   /*
> +* Pay attention to CONFIG_RANDOMIZE_MEMORY=y as it shuffles
> +* physmem mapping too and there we have the initrd.
> +*/
> +   start += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +   }
> +
> collect_cpu_info_early();
> -   ret = load_microcode(mcs, ptrs, blobs_p->start, );
> +   ret = load_microcode(mcs, ptrs, start, );
> if (ret != UCODE_OK)
> return;
>



-- 
Kees Cook
Chrome OS & Brillo Security

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Rafael J. Wysocki]

On Tuesday, July 26, 2016 01:31:00 PM Kees Cook wrote:
> On Tue, Jul 26, 2016 at 1:15 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, July 26, 2016 09:39:05 AM Josh Poimboeuf wrote:
> >> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
> >> > Hi,
> >> >
> >> > The following commit:
> >> >
> >> > commit 13523309495cdbd57a0d344c0d5d574987af007f
> >> > Author: Josh Poimboeuf 
> >> > Date:   Thu Jan 21 16:49:21 2016 -0600
> >> >
> >> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
> >> >
> >> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
> >> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
> >> >
> >> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
> >> >
> >> > is reported to cause a resume-from-hibernation regression due to an 
> >> > attempt
> >> > to execute an NX page (we've seen quite a bit of that recently).
> >> >
> >> > I'm asking the reporter to try 4.7, but if the problem is still there, 
> >> > we'll
> >> > need to revert the above I'm afraid.
> >
> > So the bug is still there in 4.7 and it goes away after reverting the above
> > commit.  I guess I'll send a revert then.
> 
> To make sure I understand:
> 
> There are two separate bugs here that break hibernation?

Yes, there are.

The first one is the BZ 150021 as reported here.

The second one is the clash with new ASLR-related changes as reported by Boris.

Thanks,
Rafael

Re: [tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

[Kees Cook]

On Tue, Jul 26, 2016 at 10:37 AM, tip-bot for Borislav Petkov
 wrote:
> Commit-ID:  efaad554b4ffae1840a2759e09e21325ddbc8b05
> Gitweb: http://git.kernel.org/tip/efaad554b4ffae1840a2759e09e21325ddbc8b05
> Author: Borislav Petkov 
> AuthorDate: Tue, 26 Jul 2016 11:51:38 +0200
> Committer:  Ingo Molnar 
> CommitDate: Tue, 26 Jul 2016 19:32:57 +0200
>
> x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y
>
> CONFIG_RANDOMIZE_MEMORY=y randomizes the physical memmap and thus the
> address where the initrd is located. Therefore, we need to add the
> offset KASLR put us to in order to find the initrd again on the AP path.
>
> In the future, we will get rid of the initrd address caching and query
> the address on both the BSP and AP paths but that would need more work.
>
> Thanks to Nicolai Stange for the good bisection and debugging work.
>
> Reported-and-tested-by: Nicolai Stange 
> Signed-off-by: Borislav Petkov 
> Cc: Kees Cook 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Link: http://lkml.kernel.org/r/20160726095138.3470-1...@alien8.de
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/kernel/cpu/microcode/intel.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
> b/arch/x86/kernel/cpu/microcode/intel.c
> index 6515c80..0f97ae9 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -793,10 +793,10 @@ void __init load_ucode_intel_bsp(void)
>  void load_ucode_intel_ap(void)
>  {
> struct ucode_blobs *blobs_p;
> +   unsigned long *ptrs, start = 0;
> struct mc_saved_data *mcs;
> struct ucode_cpu_info uci;
> enum ucode_state ret;
> -   unsigned long *ptrs;
>
>  #ifdef CONFIG_X86_32
> mcs = (struct mc_saved_data *)__pa_nodebug(_saved_data);
> @@ -815,8 +815,20 @@ void load_ucode_intel_ap(void)
> if (!mcs->num_saved)
> return;
>
> +   if (blobs_p->valid) {
> +   start = blobs_p->start;
> +
> +#ifdef CONFIG_RANDOMIZE_MEMORY

These ifdefs aren't needed if we added a no-op __PAGE_OFFSET_BASE to
the 32-bit page table headers. Then the compiler will DTRT with the
start calculation. When CONFIG_RANDOMIZE_MEMORY is set, start will
have a non-zero value, and when not set it'll be 0.

> +   /*
> +* Pay attention to CONFIG_RANDOMIZE_MEMORY=y as it shuffles
> +* physmem mapping too and there we have the initrd.
> +*/
> +   start += PAGE_OFFSET - __PAGE_OFFSET_BASE;
> +#endif
> +   }
> +
> collect_cpu_info_early();
> -   ret = load_microcode(mcs, ptrs, blobs_p->start, );
> +   ret = load_microcode(mcs, ptrs, start, );
> if (ret != UCODE_OK)
> return;
>



-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset

[Maxime Ripard]

Some registers offset were having one 0 too many compared to the others.
Remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 68492808e5fc..3c236eefbb3a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -70,7 +70,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, 
"pll-video0",
0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
-   "osc24M", 0x0018,
+   "osc24M", 0x018,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -100,7 +100,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph0_clk, 
"pll-periph0",
   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
-   "osc24M", 0x0038,
+   "osc24M", 0x038,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -121,7 +121,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_clk, 
"pll-periph1",
   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
-   "osc24M", 0x0048,
+   "osc24M", 0x048,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
-- 
2.9.2

[PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name

[Maxime Ripard]

Since the A64 and H3 have a slightly different clock set, they will have
different opaque clock numbers set as well. Make that obvious by using the
SoC name in the defines.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-h3.dtsi  |  62 -
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c  | 232 +++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h  |  44 +++---
 include/dt-bindings/clock/sun8i-h3-ccu.h | 188 -
 4 files changed, 263 insertions(+), 263 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 9871bad34742..0e7005865e20 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -144,7 +144,7 @@
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
interrupts = ;
-   clocks = < CLK_BUS_DMA>;
+   clocks = < CLK_H3_BUS_DMA>;
resets = < RST_BUS_DMA>;
#dma-cells = <1>;
};
@@ -152,10 +152,10 @@
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c0f000 0x1000>;
-   clocks = < CLK_BUS_MMC0>,
-< CLK_MMC0>,
-< CLK_MMC0_OUTPUT>,
-< CLK_MMC0_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC0>,
+< CLK_H3_MMC0>,
+< CLK_H3_MMC0_OUTPUT>,
+< CLK_H3_MMC0_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -171,10 +171,10 @@
mmc1: mmc@01c1 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c1 0x1000>;
-   clocks = < CLK_BUS_MMC1>,
-< CLK_MMC1>,
-< CLK_MMC1_OUTPUT>,
-< CLK_MMC1_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC1>,
+< CLK_H3_MMC1>,
+< CLK_H3_MMC1_OUTPUT>,
+< CLK_H3_MMC1_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -190,10 +190,10 @@
mmc2: mmc@01c11000 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c11000 0x1000>;
-   clocks = < CLK_BUS_MMC2>,
-< CLK_MMC2>,
-< CLK_MMC2_OUTPUT>,
-< CLK_MMC2_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC2>,
+< CLK_H3_MMC2>,
+< CLK_H3_MMC2_OUTPUT>,
+< CLK_H3_MMC2_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -218,10 +218,10 @@
"pmu1",
"pmu2",
"pmu3";
-   clocks = < CLK_USB_PHY0>,
-< CLK_USB_PHY1>,
-< CLK_USB_PHY2>,
-< CLK_USB_PHY3>;
+   clocks = < CLK_H3_USB_PHY0>,
+< CLK_H3_USB_PHY1>,
+< CLK_H3_USB_PHY2>,
+< CLK_H3_USB_PHY3>;
clock-names = "usb0_phy",
  "usb1_phy",
  "usb2_phy",
@@ -242,7 +242,7 @@
compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
reg = <0x01c1b000 0x100>;
interrupts = ;
-   clocks = < CLK_BUS_EHCI1>, < CLK_BUS_OHCI1>;
+   clocks = < CLK_H3_BUS_EHCI1>, < 
CLK_H3_BUS_OHCI1>;
resets = < RST_BUS_EHCI1>, < RST_BUS_OHCI1>;
phys = < 1>;
phy-names = "usb";
@@ -253,8 +253,8 @@
compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
reg = <0x01c1b400 0x100>;
interrupts = ;
-   clocks = < CLK_BUS_EHCI1>, < CLK_BUS_OHCI1>,
-< CLK_USB_OHCI1>;
+   clocks = < CLK_H3_BUS_EHCI1>, < 
CLK_H3_BUS_OHCI1>,
+< CLK_H3_USB_OHCI1>;
resets = 

[PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi

[Maxime Ripard]

From: Andre Przywara 

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
[Maxime: Convert to CCU binding, drop the MMC support for now]
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
 MAINTAINERS |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi   | 273 
 3 files changed, 275 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc36b0d..7e59d8ba86af 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..440490126bfb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -955,6 +955,7 @@ M:  Chen-Yu Tsai 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 N: sun[x456789]i
+F: arch/arm64/boot/dts/allwinner/
 
 ARM/Allwinner SoC Clock Support
 M: Emilio López 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index ..636165d75373
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,273 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *Copyright (C) 2015 Jens Kuske 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   };
+
+   cpu@2 

[PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset

[Maxime Ripard]

Some registers offset were having one 0 too many compared to the others.
Remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 68492808e5fc..3c236eefbb3a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -70,7 +70,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, 
"pll-video0",
0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
-   "osc24M", 0x0018,
+   "osc24M", 0x018,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -100,7 +100,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph0_clk, 
"pll-periph0",
   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
-   "osc24M", 0x0038,
+   "osc24M", 0x038,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -121,7 +121,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_clk, 
"pll-periph1",
   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
-   "osc24M", 0x0048,
+   "osc24M", 0x048,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
-- 
2.9.2

[PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name

[Maxime Ripard]

Since the A64 and H3 have a slightly different clock set, they will have
different opaque clock numbers set as well. Make that obvious by using the
SoC name in the defines.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-h3.dtsi  |  62 -
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c  | 232 +++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h  |  44 +++---
 include/dt-bindings/clock/sun8i-h3-ccu.h | 188 -
 4 files changed, 263 insertions(+), 263 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 9871bad34742..0e7005865e20 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -144,7 +144,7 @@
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
interrupts = ;
-   clocks = < CLK_BUS_DMA>;
+   clocks = < CLK_H3_BUS_DMA>;
resets = < RST_BUS_DMA>;
#dma-cells = <1>;
};
@@ -152,10 +152,10 @@
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c0f000 0x1000>;
-   clocks = < CLK_BUS_MMC0>,
-< CLK_MMC0>,
-< CLK_MMC0_OUTPUT>,
-< CLK_MMC0_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC0>,
+< CLK_H3_MMC0>,
+< CLK_H3_MMC0_OUTPUT>,
+< CLK_H3_MMC0_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -171,10 +171,10 @@
mmc1: mmc@01c1 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c1 0x1000>;
-   clocks = < CLK_BUS_MMC1>,
-< CLK_MMC1>,
-< CLK_MMC1_OUTPUT>,
-< CLK_MMC1_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC1>,
+< CLK_H3_MMC1>,
+< CLK_H3_MMC1_OUTPUT>,
+< CLK_H3_MMC1_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -190,10 +190,10 @@
mmc2: mmc@01c11000 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c11000 0x1000>;
-   clocks = < CLK_BUS_MMC2>,
-< CLK_MMC2>,
-< CLK_MMC2_OUTPUT>,
-< CLK_MMC2_SAMPLE>;
+   clocks = < CLK_H3_BUS_MMC2>,
+< CLK_H3_MMC2>,
+< CLK_H3_MMC2_OUTPUT>,
+< CLK_H3_MMC2_SAMPLE>;
clock-names = "ahb",
  "mmc",
  "output",
@@ -218,10 +218,10 @@
"pmu1",
"pmu2",
"pmu3";
-   clocks = < CLK_USB_PHY0>,
-< CLK_USB_PHY1>,
-< CLK_USB_PHY2>,
-< CLK_USB_PHY3>;
+   clocks = < CLK_H3_USB_PHY0>,
+< CLK_H3_USB_PHY1>,
+< CLK_H3_USB_PHY2>,
+< CLK_H3_USB_PHY3>;
clock-names = "usb0_phy",
  "usb1_phy",
  "usb2_phy",
@@ -242,7 +242,7 @@
compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
reg = <0x01c1b000 0x100>;
interrupts = ;
-   clocks = < CLK_BUS_EHCI1>, < CLK_BUS_OHCI1>;
+   clocks = < CLK_H3_BUS_EHCI1>, < 
CLK_H3_BUS_OHCI1>;
resets = < RST_BUS_EHCI1>, < RST_BUS_OHCI1>;
phys = < 1>;
phy-names = "usb";
@@ -253,8 +253,8 @@
compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
reg = <0x01c1b400 0x100>;
interrupts = ;
-   clocks = < CLK_BUS_EHCI1>, < CLK_BUS_OHCI1>,
-< CLK_USB_OHCI1>;
+   clocks = < CLK_H3_BUS_EHCI1>, < 
CLK_H3_BUS_OHCI1>,
+< CLK_H3_USB_OHCI1>;
resets = < RST_BUS_EHCI1>, < 

[PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi

[Maxime Ripard]

From: Andre Przywara 

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
[Maxime: Convert to CCU binding, drop the MMC support for now]
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
 MAINTAINERS |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi   | 273 
 3 files changed, 275 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc36b0d..7e59d8ba86af 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..440490126bfb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -955,6 +955,7 @@ M:  Chen-Yu Tsai 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 N: sun[x456789]i
+F: arch/arm64/boot/dts/allwinner/
 
 ARM/Allwinner SoC Clock Support
 M: Emilio López 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index ..636165d75373
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,273 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *Copyright (C) 2015 Jens Kuske 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   };
+
+   cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <2>;
+  

[PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL

[Maxime Ripard]

From: Andre Przywara 

Add required PINCTRL symbol to cover non-defconfig setups.

Signed-off-by: Andre Przywara 
Signed-off-by: Maxime Ripard 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4cc444c3c2e9..83bc4bf3513b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -3,6 +3,7 @@ menu "Platform selection"
 config ARCH_SUNXI
bool "Allwinner sunxi 64-bit SoC Family"
select GENERIC_IRQ_CHIP
+   select PINCTRL
select PINCTRL_SUN50I_A64
help
  This enables support for Allwinner sunxi based SoCs like the A64.
-- 
2.9.2

[PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL

[Maxime Ripard]

From: Andre Przywara 

Add required PINCTRL symbol to cover non-defconfig setups.

Signed-off-by: Andre Przywara 
Signed-off-by: Maxime Ripard 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4cc444c3c2e9..83bc4bf3513b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -3,6 +3,7 @@ menu "Platform selection"
 config ARCH_SUNXI
bool "Allwinner sunxi 64-bit SoC Family"
select GENERIC_IRQ_CHIP
+   select PINCTRL
select PINCTRL_SUN50I_A64
help
  This enables support for Allwinner sunxi based SoCs like the A64.
-- 
2.9.2

[PATCH 13/13] arm64: dts: add Pine64 support

[Maxime Ripard]

From: Andre Przywara 

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara 
[Maxime: Removed the common DTSI and include directly the pine64 DTS]
Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/Makefile   |  1 +
 arch/arm64/boot/dts/allwinner/Makefile |  5 ++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 50 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 70 ++
 4 files changed, 126 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 6e199c903676..ddcbf5a2c17e 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dts-dirs += al
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += amlogic
diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index ..1e29a5ae8282
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
new file mode 100644
index ..790d14daaa6a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64-pine64.dts"
+
+/ {
+   model = "Pine64+";
+   compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
+
+   /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
new file mode 100644
index ..da9bca51f5a9
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this 

[PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around

[Maxime Ripard]

Move the fixed factors clocks before the ccu_common list so that we can
separate the clocks definitions and the registration part.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index f61d2e245ac4..ec8c67201e8e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -484,6 +484,19 @@ static SUNXI_CCU_M_WITH_MUX_GATE(mbus_h3_clk, "mbus", 
mbus_h3_parents,
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 0x1a0, 0, 3, BIT(31), 0);
 
+/* Fixed Factor clocks */
+/* We hardcode the divider to 4 for now */
+static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
+   "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
+   "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
+   "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
+   "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
+   "pll-periph0", 1, 2, 0);
+
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
_cpux_clk.common,
_audio_base_clk.common,
@@ -597,18 +610,6 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
_clk.common,
 };
 
-/* We hardcode the divider to 4 for now */
-static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
-   "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
-   "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
-   "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
-   "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
-   "pll-periph0", 1, 2, 0);
-
 static struct clk_hw_onecell_data sun8i_h3_hw_clks = {
.hws= {
[CLK_PLL_CPUX]  = _cpux_clk.common.hw,
-- 
2.9.2

[PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around

[Maxime Ripard]

Move the fixed factors clocks before the ccu_common list so that we can
separate the clocks definitions and the registration part.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index f61d2e245ac4..ec8c67201e8e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -484,6 +484,19 @@ static SUNXI_CCU_M_WITH_MUX_GATE(mbus_h3_clk, "mbus", 
mbus_h3_parents,
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 0x1a0, 0, 3, BIT(31), 0);
 
+/* Fixed Factor clocks */
+/* We hardcode the divider to 4 for now */
+static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
+   "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
+   "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
+   "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
+   "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
+   "pll-periph0", 1, 2, 0);
+
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
_cpux_clk.common,
_audio_base_clk.common,
@@ -597,18 +610,6 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
_clk.common,
 };
 
-/* We hardcode the divider to 4 for now */
-static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
-   "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
-   "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
-   "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
-   "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
-   "pll-periph0", 1, 2, 0);
-
 static struct clk_hw_onecell_data sun8i_h3_hw_clks = {
.hws= {
[CLK_PLL_CPUX]  = _cpux_clk.common.hw,
-- 
2.9.2

[PATCH 13/13] arm64: dts: add Pine64 support

[Maxime Ripard]

From: Andre Przywara 

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara 
[Maxime: Removed the common DTSI and include directly the pine64 DTS]
Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/Makefile   |  1 +
 arch/arm64/boot/dts/allwinner/Makefile |  5 ++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 50 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 70 ++
 4 files changed, 126 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 6e199c903676..ddcbf5a2c17e 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dts-dirs += al
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += amlogic
diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index ..1e29a5ae8282
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
new file mode 100644
index ..790d14daaa6a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64-pine64.dts"
+
+/ {
+   model = "Pine64+";
+   compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
+
+   /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
new file mode 100644
index ..da9bca51f5a9
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can 

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Kees Cook]

On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  wrote:
> On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
>> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > The following commit:
>> >
>> > commit 13523309495cdbd57a0d344c0d5d574987af007f
>> > Author: Josh Poimboeuf 
>> > Date:   Thu Jan 21 16:49:21 2016 -0600
>> >
>> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
>> >
>> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
>> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
>> >
>> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
>> >
>> > is reported to cause a resume-from-hibernation regression due to an attempt
>> > to execute an NX page (we've seen quite a bit of that recently).
>> >
>> > I'm asking the reporter to try 4.7, but if the problem is still there, 
>> > we'll
>> > need to revert the above I'm afraid.
>>
>> So I can't resume properly from disk too, on the Intel laptop this time. Top
>> commit is from tip/master:
>>
>> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
>> Merge: a4823bbffc96 dd9506954539
>> Author: Ingo Molnar 
>> Date:   Mon Jul 25 08:39:43 2016 +0200
>>
>> Merge branch 'linus'
>>
>>
>> So I thought it might be Josh's patch above and reverted it. No joy.
>>
>> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
>> microcode loader breakage which we've been debugging. Turned that off
>> and machine resumes fine again.
>
> Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
> was no hope it would not break hibernation if you asked me.
>
>> It looks like
>>
>>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
>>
>> broke a bunch of things. Off the top of my head, we probably should make
>> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
>> was the case with ASLR previously, AFAIR.
>
> Please no.
>
> First off, it should be perfectly possible to make hibernation work along
> with this new variant of ASLR.  Second, quite obviously, the author of these
> ASLR changes had not done sufficient research to estimate the possible
> impact of them.

I think that's a bit unfair: Thomas did a lot of testing, and it has
been living in -next for a while.

> Honestly, I don't think it is a good idea to introduce random Kconfig options
> for working around cases in which the author of some changes cannot be 
> bothered
> with doing things right.  Even if that is security.

I would agree: let's try to get this fixed soon.

> So IMO, either we should fix the problem, or that whole new ASLR stuff should
> be reverted.
>
> I think I know how to fix it, but I won't be able to get to that before the
> next week.  I guess it can wait till then, though.

Thomas, will you have some time to examine this and estimate the work for a fix?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Kees Cook]

On Tue, Jul 26, 2016 at 1:24 PM, Rafael J. Wysocki  wrote:
> On Tuesday, July 26, 2016 04:04:42 PM Borislav Petkov wrote:
>> On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > The following commit:
>> >
>> > commit 13523309495cdbd57a0d344c0d5d574987af007f
>> > Author: Josh Poimboeuf 
>> > Date:   Thu Jan 21 16:49:21 2016 -0600
>> >
>> > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
>> >
>> > do_suspend_lowlevel() is a callable non-leaf function which doesn't
>> > honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
>> >
>> > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
>> >
>> > is reported to cause a resume-from-hibernation regression due to an attempt
>> > to execute an NX page (we've seen quite a bit of that recently).
>> >
>> > I'm asking the reporter to try 4.7, but if the problem is still there, 
>> > we'll
>> > need to revert the above I'm afraid.
>>
>> So I can't resume properly from disk too, on the Intel laptop this time. Top
>> commit is from tip/master:
>>
>> commit 516f48acf59722429acd323b3d283f74f02891fe (refs/remotes/tip/master)
>> Merge: a4823bbffc96 dd9506954539
>> Author: Ingo Molnar 
>> Date:   Mon Jul 25 08:39:43 2016 +0200
>>
>> Merge branch 'linus'
>>
>>
>> So I thought it might be Josh's patch above and reverted it. No joy.
>>
>> Then I remembered that I enabled CONFIG_RANDOMIZE_MEMORY for the
>> microcode loader breakage which we've been debugging. Turned that off
>> and machine resumes fine again.
>
> Well, I wasn't aware of *another* flavor of ASLR in the works.  And there
> was no hope it would not break hibernation if you asked me.
>
>> It looks like
>>
>>   0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
>>
>> broke a bunch of things. Off the top of my head, we probably should make
>> suspend to disk and CONFIG_RANDOMIZE_MEMORY mutually exclusive, like it
>> was the case with ASLR previously, AFAIR.
>
> Please no.
>
> First off, it should be perfectly possible to make hibernation work along
> with this new variant of ASLR.  Second, quite obviously, the author of these
> ASLR changes had not done sufficient research to estimate the possible
> impact of them.

I think that's a bit unfair: Thomas did a lot of testing, and it has
been living in -next for a while.

> Honestly, I don't think it is a good idea to introduce random Kconfig options
> for working around cases in which the author of some changes cannot be 
> bothered
> with doing things right.  Even if that is security.

I would agree: let's try to get this fixed soon.

> So IMO, either we should fix the problem, or that whole new ASLR stuff should
> be reverted.
>
> I think I know how to fix it, but I won't be able to get to that before the
> next week.  I guess it can wait till then, though.

Thomas, will you have some time to examine this and estimate the work for a fix?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls

[Maxime Ripard]

In order to deal with the A64 that will have several video and ddr plls,
rename the first ones to add an index.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 9af359544110..68492808e5fc 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -57,8 +57,8 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   0);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-   "osc24M", 0x0010,
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
+   "osc24M", 0x010,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -81,7 +81,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
BIT(28),/* lock */
0);
 
-static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr0_clk, "pll-ddr0",
"osc24M", 0x020,
8, 5,   /* N */
4, 2,   /* K */
@@ -422,7 +422,7 @@ static SUNXI_CCU_GATE(usb_ohci2_clk,"usb-ohci2",
"osc24M",
 static SUNXI_CCU_GATE(usb_ohci3_clk,   "usb-ohci3","osc24M",
  0x0cc, BIT(19), 0);
 
-static const char * const dram_parents[] = { "pll-ddr", "pll-periph0-2x" };
+static const char * const dram_parents[] = { "pll-ddr0", "pll-periph0-2x" };
 static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
 
@@ -439,7 +439,7 @@ static const char * const de_parents[] = { 
"pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
 0x104, 0, 4, 24, 3, BIT(31), 0);
 
-static const char * const tcon_parents[] = { "pll-video" };
+static const char * const tcon_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
 0x118, 0, 4, 24, 3, BIT(31), 0);
 
@@ -458,7 +458,7 @@ static const char * const csi_sclk_parents[] = { 
"pll-periph0", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_sclk_clk, "csi-sclk", csi_sclk_parents,
 0x134, 16, 4, 24, 3, BIT(31), 0);
 
-static const char * const csi_mclk_parents[] = { "osc24M", "pll-video", 
"pll-periph0" };
+static const char * const csi_mclk_parents[] = { "osc24M", "pll-video0", 
"pll-periph0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_clk, "csi-mclk", csi_mclk_parents,
 0x134, 0, 5, 8, 3, BIT(15), 0);
 
@@ -470,14 +470,14 @@ static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig",   
"pll-audio",
 static SUNXI_CCU_GATE(avs_clk, "avs",  "osc24M",
  0x144, BIT(31), 0);
 
-static const char * const hdmi_parents[] = { "pll-video" };
+static const char * const hdmi_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
 0x150, 0, 4, 24, 2, BIT(31), 0);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
  0x154, BIT(31), 0);
 
-static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", 
"pll-ddr" };
+static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", 
"pll-ddr0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
 
@@ -487,9 +487,9 @@ static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
_cpux_clk.common,
_audio_base_clk.common,
-   _video_clk.common,
+   _video0_clk.common,
_ve_clk.common,
-   _ddr_clk.common,
+   _ddr0_clk.common,
_periph0_clk.common,
_gpu_clk.common,
_periph1_clk.common,
-- 
2.9.2

[PATCH 02/13] clk: sunxi-ng: mux: Add mux table support

[Maxime Ripard]

Add support for the table based muxes, and add macros to register them.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 14 ++
 drivers/clk/sunxi-ng/ccu_mux.h | 27 ---
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 58fc36e7dcce..f942044b038a 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -100,6 +100,7 @@ out:
 u8 ccu_mux_helper_get_parent(struct ccu_common *common,
 struct ccu_mux_internal *cm)
 {
+   int num_parents = clk_hw_get_num_parents(>hw);
u32 reg;
u8 parent;
 
@@ -107,6 +108,16 @@ u8 ccu_mux_helper_get_parent(struct ccu_common *common,
parent = reg >> cm->shift;
parent &= (1 << cm->width) - 1;
 
+   if (cm->table) {
+   int i;
+
+   for (i = 0; i < num_parents; i++)
+   if (cm->table[i] == parent)
+   return i;
+
+   return -EINVAL;
+   }
+
return parent;
 }
 
@@ -117,6 +128,9 @@ int ccu_mux_helper_set_parent(struct ccu_common *common,
unsigned long flags;
u32 reg;
 
+   if (cm->table)
+   index = cm->table[index];
+
spin_lock_irqsave(common->lock, flags);
 
reg = readl(common->base + common->reg);
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index 95cfecec3c39..00cec8ac6ae3 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -9,6 +9,8 @@ struct ccu_mux_internal {
u8  shift;
u8  width;
 
+   const u8*table;
+
struct {
u8  index;
u8  div;
@@ -21,12 +23,16 @@ struct ccu_mux_internal {
} variable_prediv;
 };
 
-#define _SUNXI_CCU_MUX(_shift, _width) \
-   {   \
-   .shift  = _shift,   \
-   .width  = _width,   \
+#define _SUNXI_CCU_MUX_TABLE(_shift, _width, _table)   \
+   {   \
+   .shift  = _shift,   \
+   .width  = _width,   \
+   .table  = _table,   \
}
 
+#define _SUNXI_CCU_MUX(_shift, _width) \
+   _SUNXI_CCU_MUX_TABLE(_shift, _width, NULL)
+
 struct ccu_mux {
u16 reg;
u32 enable;
@@ -47,11 +53,12 @@ struct ccu_mux {
}   \
}
 
-#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,
\
-   _shift, _width, _gate, _flags)  \
+#define SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, _table,
\
+ _reg,  _shift, _width, _gate, \
+ _flags)   \
struct ccu_mux _struct = {  \
.enable = _gate,\
-   .mux= _SUNXI_CCU_MUX(_shift, _width),   \
+   .mux= _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \
.common = { \
.reg= _reg, \
.hw.init= CLK_HW_INIT_PARENTS(_name,\
@@ -61,6 +68,12 @@ struct ccu_mux {
}   \
}
 
+#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,
\
+   _shift, _width, _gate, _flags)  \
+   SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, NULL,   \
+ _reg,  _shift, _width, _gate, \
+ _flags)
+
 static inline struct ccu_mux *hw_to_ccu_mux(struct clk_hw *hw)
 {
struct ccu_common *common = hw_to_ccu_common(hw);
-- 
2.9.2

[PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls

[Maxime Ripard]

In order to deal with the A64 that will have several video and ddr plls,
rename the first ones to add an index.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 9af359544110..68492808e5fc 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -57,8 +57,8 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   0);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-   "osc24M", 0x0010,
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
+   "osc24M", 0x010,
8, 7,   /* N */
0, 4,   /* M */
BIT(24),/* frac enable */
@@ -81,7 +81,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
BIT(28),/* lock */
0);
 
-static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr0_clk, "pll-ddr0",
"osc24M", 0x020,
8, 5,   /* N */
4, 2,   /* K */
@@ -422,7 +422,7 @@ static SUNXI_CCU_GATE(usb_ohci2_clk,"usb-ohci2",
"osc24M",
 static SUNXI_CCU_GATE(usb_ohci3_clk,   "usb-ohci3","osc24M",
  0x0cc, BIT(19), 0);
 
-static const char * const dram_parents[] = { "pll-ddr", "pll-periph0-2x" };
+static const char * const dram_parents[] = { "pll-ddr0", "pll-periph0-2x" };
 static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
 
@@ -439,7 +439,7 @@ static const char * const de_parents[] = { 
"pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
 0x104, 0, 4, 24, 3, BIT(31), 0);
 
-static const char * const tcon_parents[] = { "pll-video" };
+static const char * const tcon_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
 0x118, 0, 4, 24, 3, BIT(31), 0);
 
@@ -458,7 +458,7 @@ static const char * const csi_sclk_parents[] = { 
"pll-periph0", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_sclk_clk, "csi-sclk", csi_sclk_parents,
 0x134, 16, 4, 24, 3, BIT(31), 0);
 
-static const char * const csi_mclk_parents[] = { "osc24M", "pll-video", 
"pll-periph0" };
+static const char * const csi_mclk_parents[] = { "osc24M", "pll-video0", 
"pll-periph0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_clk, "csi-mclk", csi_mclk_parents,
 0x134, 0, 5, 8, 3, BIT(15), 0);
 
@@ -470,14 +470,14 @@ static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig",   
"pll-audio",
 static SUNXI_CCU_GATE(avs_clk, "avs",  "osc24M",
  0x144, BIT(31), 0);
 
-static const char * const hdmi_parents[] = { "pll-video" };
+static const char * const hdmi_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
 0x150, 0, 4, 24, 2, BIT(31), 0);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
  0x154, BIT(31), 0);
 
-static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", 
"pll-ddr" };
+static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", 
"pll-ddr0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
 
@@ -487,9 +487,9 @@ static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
_cpux_clk.common,
_audio_base_clk.common,
-   _video_clk.common,
+   _video0_clk.common,
_ve_clk.common,
-   _ddr_clk.common,
+   _ddr0_clk.common,
_periph0_clk.common,
_gpu_clk.common,
_periph1_clk.common,
-- 
2.9.2

[PATCH 02/13] clk: sunxi-ng: mux: Add mux table support

[Maxime Ripard]

Add support for the table based muxes, and add macros to register them.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 14 ++
 drivers/clk/sunxi-ng/ccu_mux.h | 27 ---
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 58fc36e7dcce..f942044b038a 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -100,6 +100,7 @@ out:
 u8 ccu_mux_helper_get_parent(struct ccu_common *common,
 struct ccu_mux_internal *cm)
 {
+   int num_parents = clk_hw_get_num_parents(>hw);
u32 reg;
u8 parent;
 
@@ -107,6 +108,16 @@ u8 ccu_mux_helper_get_parent(struct ccu_common *common,
parent = reg >> cm->shift;
parent &= (1 << cm->width) - 1;
 
+   if (cm->table) {
+   int i;
+
+   for (i = 0; i < num_parents; i++)
+   if (cm->table[i] == parent)
+   return i;
+
+   return -EINVAL;
+   }
+
return parent;
 }
 
@@ -117,6 +128,9 @@ int ccu_mux_helper_set_parent(struct ccu_common *common,
unsigned long flags;
u32 reg;
 
+   if (cm->table)
+   index = cm->table[index];
+
spin_lock_irqsave(common->lock, flags);
 
reg = readl(common->base + common->reg);
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index 95cfecec3c39..00cec8ac6ae3 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -9,6 +9,8 @@ struct ccu_mux_internal {
u8  shift;
u8  width;
 
+   const u8*table;
+
struct {
u8  index;
u8  div;
@@ -21,12 +23,16 @@ struct ccu_mux_internal {
} variable_prediv;
 };
 
-#define _SUNXI_CCU_MUX(_shift, _width) \
-   {   \
-   .shift  = _shift,   \
-   .width  = _width,   \
+#define _SUNXI_CCU_MUX_TABLE(_shift, _width, _table)   \
+   {   \
+   .shift  = _shift,   \
+   .width  = _width,   \
+   .table  = _table,   \
}
 
+#define _SUNXI_CCU_MUX(_shift, _width) \
+   _SUNXI_CCU_MUX_TABLE(_shift, _width, NULL)
+
 struct ccu_mux {
u16 reg;
u32 enable;
@@ -47,11 +53,12 @@ struct ccu_mux {
}   \
}
 
-#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,
\
-   _shift, _width, _gate, _flags)  \
+#define SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, _table,
\
+ _reg,  _shift, _width, _gate, \
+ _flags)   \
struct ccu_mux _struct = {  \
.enable = _gate,\
-   .mux= _SUNXI_CCU_MUX(_shift, _width),   \
+   .mux= _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \
.common = { \
.reg= _reg, \
.hw.init= CLK_HW_INIT_PARENTS(_name,\
@@ -61,6 +68,12 @@ struct ccu_mux {
}   \
}
 
+#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,
\
+   _shift, _width, _gate, _flags)  \
+   SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, NULL,   \
+ _reg,  _shift, _width, _gate, \
+ _flags)
+
 static inline struct ccu_mux *hw_to_ccu_mux(struct clk_hw *hw)
 {
struct ccu_common *common = hw_to_ccu_common(hw);
-- 
2.9.2