Re: [PATCH 5.1 000/138] 5.1.18-stable review

[Kelsey Skunberg]

On Fri, Jul 12, 2019 at 02:17:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.18 release.
> There are 138 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.18-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.1.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 


Compiled and booted with no regressions on my system.

Cheers,
Kelsey

Re: [PATCH 5.2 00/61] 5.2.1-stable review

[Kelsey Skunberg]

On Fri, Jul 12, 2019 at 02:19:13PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.1 release.
> There are 61 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.1-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.2.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h


Compiled and booted with no regressions on my system.

Cheers,
Kelsey
 

[PATCH 4/4] Documentation:kernel-per-CPU-kthreads.txt: Remove reference to elevator=

[Marcos Paulo de Souza]

This argument was not being considered since blk-mq was set by default,
so removed this documentation to avoid confusion.

Signed-off-by: Marcos Paulo de Souza 
---
 Documentation/kernel-per-CPU-kthreads.txt | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Documentation/kernel-per-CPU-kthreads.txt 
b/Documentation/kernel-per-CPU-kthreads.txt
index 5623b9916411..c68c6c8c26a4 100644
--- a/Documentation/kernel-per-CPU-kthreads.txt
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -274,9 +274,7 @@ To reduce its OS jitter, do any of the following:
(based on an earlier one from Gilad Ben-Yossef) that
reduces or even eliminates vmstat overhead for some
workloads at https://lkml.org/lkml/2013/9/4/379.
-   e.  Boot with "elevator=noop" to avoid workqueue use by
-   the block layer.
-   f.  If running on high-end powerpc servers, build with
+   e.  If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n.  This prevents the RTAS
daemon from running on each CPU every second or so.
(This will require editing Kconfig files and will defeat
@@ -284,12 +282,12 @@ To reduce its OS jitter, do any of the following:
due to the rtas_event_scan() function.
WARNING:  Please check your CPU specifications to
make sure that this is safe on your particular system.
-   g.  If running on Cell Processor, build your kernel with
+   f.  If running on Cell Processor, build your kernel with
CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
spu_gov_work().
WARNING:  Please check your CPU specifications to
make sure that this is safe on your particular system.
-   h.  If running on PowerMAC, build your kernel with
+   g.  If running on PowerMAC, build your kernel with
CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
avoiding OS jitter from rackmeter_do_timer().
 
-- 
2.22.0

[PATCH 2/4] kernel-parameters.txt: Remove elevator argument

[Marcos Paulo de Souza]

This argument was not being used since the legacy IO path was removed,
when blk-mq was enabled by default. So removed it from the kernel
parameters documentation.

Signed-off-by: Marcos Paulo de Souza 
---
 Documentation/admin-guide/kernel-parameters.txt | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 099c5a4be95b..2f47b20ee413 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1197,12 +1197,6 @@
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
 
-   elevator=   [IOSCHED]
-   Format: { "mq-deadline" | "kyber" | "bfq" }
-   See Documentation/block/deadline-iosched.txt,
-   Documentation/block/kyber-iosched.txt and
-   Documentation/block/bfq-iosched.txt for details.
-
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
-- 
2.22.0

[PATCH 1/4] block: elevator.c: Remove now unused elevator= argument

[Marcos Paulo de Souza]

Since the inclusion of blk-mq, elevator argument was not being
considered anymore, and it's utility died long with the legacy IO path,
now removed too.

Signed-off-by: Marcos Paulo de Souza 
---
 block/elevator.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/block/elevator.c b/block/elevator.c
index 2f17d66d0e61..f56d9c7d5cbc 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -135,20 +135,6 @@ static struct elevator_type *elevator_get(struct 
request_queue *q,
return e;
 }
 
-static char chosen_elevator[ELV_NAME_MAX];
-
-static int __init elevator_setup(char *str)
-{
-   /*
-* Be backwards-compatible with previous kernels, so users
-* won't get the wrong elevator.
-*/
-   strncpy(chosen_elevator, str, sizeof(chosen_elevator) - 1);
-   return 1;
-}
-
-__setup("elevator=", elevator_setup);
-
 static struct kobj_type elv_ktype;
 
 struct elevator_queue *elevator_alloc(struct request_queue *q,
-- 
2.22.0

Re: [PATCH 4.19 00/91] 4.19.59-stable review

[Kelsey Skunberg]

On Fri, Jul 12, 2019 at 02:18:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.59 release.
> There are 91 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.59-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 


Compiled and booted with no regressions on my system.

Cheers,
Kelsey

Re: [PATCH] proc: revert /proc/*/cmdline rewrite

[Linus Torvalds]

[ Apparently this thread wasn't on the lists, and I didn't even
notice. So re-sending the patches ]

On Sat, Jul 13, 2019 at 9:16 PM Eric W. Biederman  wrote:
> Given that this fixes a regression and a bug.
>
> Acked-by: "Eric W. Biederman" 

I'd much rather start from scratch. Like the attached.

Alexey Izbyshev has a third patch that then limits the setproctitle()
case to only allow looking into the env[] area, which looks
reasonable.

   Linus
From 5563a2fb39fe0ad42f239d2f583128d50155002b Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Sat, 13 Jul 2019 13:40:13 -0700
Subject: [PATCH 1/2] /proc//cmdline: remove all the special cases

Start off with a clean slate that only reads exactly from arg_start to
arg_end, without any oddities.

We'll add back the setproctitle() special case very differently in the
next commit.

Signed-off-by: Linus Torvalds 
---
 fs/proc/base.c | 71 ++
 1 file changed, 8 insertions(+), 63 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 255f6754c70d..8040f9d1cf07 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -212,7 +212,7 @@ static int proc_root_link(struct dentry *dentry, struct path *path)
 static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
 			  size_t count, loff_t *ppos)
 {
-	unsigned long arg_start, arg_end, env_start, env_end;
+	unsigned long arg_start, arg_end;
 	unsigned long pos, len;
 	char *page;
 
@@ -223,36 +223,18 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
 	spin_lock(>arg_lock);
 	arg_start = mm->arg_start;
 	arg_end = mm->arg_end;
-	env_start = mm->env_start;
-	env_end = mm->env_end;
 	spin_unlock(>arg_lock);
 
 	if (arg_start >= arg_end)
 		return 0;
 
-	/*
-	 * We have traditionally allowed the user to re-write
-	 * the argument strings and overflow the end result
-	 * into the environment section. But only do that if
-	 * the environment area is contiguous to the arguments.
-	 */
-	if (env_start != arg_end || env_start >= env_end)
-		env_start = env_end = arg_end;
-
-	/* .. and limit it to a maximum of one page of slop */
-	if (env_end >= arg_end + PAGE_SIZE)
-		env_end = arg_end + PAGE_SIZE - 1;
-
 	/* We're not going to care if "*ppos" has high bits set */
-	pos = arg_start + *ppos;
-
 	/* .. but we do check the result is in the proper range */
-	if (pos < arg_start || pos >= env_end)
+	pos = arg_start + *ppos;
+	if (pos < arg_start || pos >= arg_end)
 		return 0;
-
-	/* .. and we never go past env_end */
-	if (env_end - pos < count)
-		count = env_end - pos;
+	if (count > arg_end - pos)
+		count = arg_end - pos;
 
 	page = (char *)__get_free_page(GFP_KERNEL);
 	if (!page)
@@ -262,48 +244,11 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
 	while (count) {
 		int got;
 		size_t size = min_t(size_t, PAGE_SIZE, count);
-		long offset;
 
-		/*
-		 * Are we already starting past the official end?
-		 * We always include the last byte that is *supposed*
-		 * to be NUL
-		 */
-		offset = (pos >= arg_end) ? pos - arg_end + 1 : 0;
-
-		got = access_remote_vm(mm, pos - offset, page, size + offset, FOLL_ANON);
-		if (got <= offset)
+		got = access_remote_vm(mm, pos, page, size, FOLL_ANON);
+		if (got <= 0)
 			break;
-		got -= offset;
-
-		/* Don't walk past a NUL character once you hit arg_end */
-		if (pos + got >= arg_end) {
-			int n = 0;
-
-			/*
-			 * If we started before 'arg_end' but ended up
-			 * at or after it, we start the NUL character
-			 * check at arg_end-1 (where we expect the normal
-			 * EOF to be).
-			 *
-			 * NOTE! This is smaller than 'got', because
-			 * pos + got >= arg_end
-			 */
-			if (pos < arg_end)
-n = arg_end - pos - 1;
-
-			/* Cut off at first NUL after 'n' */
-			got = n + strnlen(page+n, offset+got-n);
-			if (got < offset)
-break;
-			got -= offset;
-
-			/* Include the NUL if it existed */
-			if (got < size)
-got++;
-		}
-
-		got -= copy_to_user(buf, page+offset, got);
+		got -= copy_to_user(buf, page, got);
 		if (unlikely(!got)) {
 			if (!len)
 len = -EFAULT;
-- 
2.22.0.193.g083935f9a2

From 63dd14999c6b210fbe33f780fec53faefa867d95 Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Sat, 13 Jul 2019 14:27:14 -0700
Subject: [PATCH 2/2] /proc//cmdline: add back the setproctitle() special
 case

This makes the setproctitle() special case very explicit indeed, and
handles it with a separate helper function entirely.

This makes the logic about when we use the string lengths etc much more
obvious, and makes it easy to see what we do.

[ Fixed for missing 'count' check noted by Alexey Izbyshev ]
Signed-off-by: Linus Torvalds 
---
 fs/proc/base.c | 54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8040f9d1cf07..3ad3ff4cc12c 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -209,12 +209,54 @@ static int proc_root_link(struct dentry *dentry, struct 

Re: [PATCH] proc: revert /proc/*/cmdline rewrite

[Eric W. Biederman]

Alexey Dobriyan  writes:

> /proc/*/cmdline continues to cause problems:
>
>   https://lkml.org/lkml/2019/4/5/825
>   Subject get_mm_cmdline and userspace (Perl) changing argv0
>
>   https://marc.info/?l=linux-kernel=156294831308786=4
>   [PATCH] proc: Fix uninitialized byte read in get_mm_cmdline()
>
> This patch reverts implementation to the last known good state.
> Revert
>
>   commit f5b65348fd77839b50e79bc0a5e536832ea52d8d
>   proc: fix missing final NUL in get_mm_cmdline() rewrite
>
>   commit 5ab8271899658042fabc5ae7e6a99066a210bc0e
>   fs/proc: simplify and clarify get_mm_cmdline() function
>
> Signed-off-by: Alexey Dobriyan 

Given that this fixes a regression and a bug.

Acked-by: "Eric W. Biederman" 

> ---
>
>   Cc lists
>
>  fs/proc/base.c |  198 
> +
>  1 file changed, 118 insertions(+), 80 deletions(-)
>
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -210,16 +210,24 @@ static int proc_root_link(struct dentry *dentry, struct 
> path *path)
>  }
>  
>  static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
> -   size_t count, loff_t *ppos)
> +   size_t _count, loff_t *pos)
>  {
> + unsigned long count = _count;
>   unsigned long arg_start, arg_end, env_start, env_end;
> - unsigned long pos, len;
> + unsigned long len1, len2, len;
> + unsigned long p;
>   char *page;
> + ssize_t rv;
> + char c;
>  
>   /* Check if process spawned far enough to have cmdline. */
>   if (!mm->env_end)
>   return 0;
>  
> + page = (char *)__get_free_page(GFP_KERNEL);
> + if (!page)
> + return -ENOMEM;
> +
>   spin_lock(>arg_lock);
>   arg_start = mm->arg_start;
>   arg_end = mm->arg_end;
> @@ -227,96 +235,126 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, 
> char __user *buf,
>   env_end = mm->env_end;
>   spin_unlock(>arg_lock);
>  
> - if (arg_start >= arg_end)
> - return 0;
> + BUG_ON(arg_start > arg_end);
> + BUG_ON(env_start > env_end);
> +
> + len1 = arg_end - arg_start;
> + len2 = env_end - env_start;
>  
> + /* Empty ARGV. */
> + if (len1 == 0) {
> + rv = 0;
> + goto out_free_page;
> + }
>   /*
> -  * We have traditionally allowed the user to re-write
> -  * the argument strings and overflow the end result
> -  * into the environment section. But only do that if
> -  * the environment area is contiguous to the arguments.
> +  * Inherently racy -- command line shares address space
> +  * with code and data.
>*/
> - if (env_start != arg_end || env_start >= env_end)
> - env_start = env_end = arg_end;
> -
> - /* .. and limit it to a maximum of one page of slop */
> - if (env_end >= arg_end + PAGE_SIZE)
> - env_end = arg_end + PAGE_SIZE - 1;
> -
> - /* We're not going to care if "*ppos" has high bits set */
> - pos = arg_start + *ppos;
> -
> - /* .. but we do check the result is in the proper range */
> - if (pos < arg_start || pos >= env_end)
> - return 0;
> -
> - /* .. and we never go past env_end */
> - if (env_end - pos < count)
> - count = env_end - pos;
> -
> - page = (char *)__get_free_page(GFP_KERNEL);
> - if (!page)
> - return -ENOMEM;
> -
> - len = 0;
> - while (count) {
> - int got;
> - size_t size = min_t(size_t, PAGE_SIZE, count);
> - long offset;
> + rv = access_remote_vm(mm, arg_end - 1, , 1, FOLL_ANON);
> + if (rv <= 0)
> + goto out_free_page;
> +
> + rv = 0;
> +
> + if (c == '\0') {
> + /* Command line (set of strings) occupies whole ARGV. */
> + if (len1 <= *pos)
> + goto out_free_page;
> +
> + p = arg_start + *pos;
> + len = len1 - *pos;
> + while (count > 0 && len > 0) {
> + unsigned int _count;
> + int nr_read;
> +
> + _count = min3(count, len, PAGE_SIZE);
> + nr_read = access_remote_vm(mm, p, page, _count, 
> FOLL_ANON);
> + if (nr_read < 0)
> + rv = nr_read;
> + if (nr_read <= 0)
> + goto out_free_page;
> +
> + if (copy_to_user(buf, page, nr_read)) {
> + rv = -EFAULT;
> + goto out_free_page;
> + }
>  
> + p   += nr_read;
> + len -= nr_read;
> + buf += nr_read;
> + count   -= nr_read;
> + rv  += nr_read;
> + }
> + } else {
>   /*
> -  * Are we already starting 

Re: INFO: task hung in unregister_netdevice_notifier (3)

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:a2d79c71 Merge tag 'for-5.3/io_uring-20190711' of git://gi..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10e45f0fa0
kernel config:  https://syzkaller.appspot.com/x/.config?x=3539b1747f03988e
dashboard link: https://syzkaller.appspot.com/bug?extid=0f1827363a305f74996f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1765c52fa0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0f1827363a305f749...@syzkaller.appspotmail.com

INFO: task syz-executor.4:9527 blocked for more than 143 seconds.
  Not tainted 5.2.0+ #80
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.4  D28136  9527   9356 0x0004
Call Trace:
 context_switch kernel/sched/core.c:3252 [inline]
 __schedule+0x755/0x1580 kernel/sched/core.c:3878
 schedule+0xa8/0x270 kernel/sched/core.c:3942
 rwsem_down_write_slowpath+0x70a/0xf70 kernel/locking/rwsem.c:1198
 __down_write kernel/locking/rwsem.c:1349 [inline]
 down_write+0x13c/0x150 kernel/locking/rwsem.c:1485
 unregister_netdevice_notifier+0x7e/0x390 net/core/dev.c:1713
 bcm_release+0x93/0x5e0 net/can/bcm.c:1525
 __sock_release+0xce/0x280 net/socket.c:586
 sock_close+0x1e/0x30 net/socket.c:1264
 __fput+0x2ff/0x890 fs/file_table.c:280
 fput+0x16/0x20 fs/file_table.c:313
 task_work_run+0x145/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:185 [inline]
 exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
 do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x413501
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48  
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48  
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01

RSP: 002b:00a6fbc0 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0005 RCX: 00413501
RDX:  RSI:  RDI: 0004
RBP: 0001 R08:  R09: 
R10: 00a6fca0 R11: 0293 R12: 0075c9a0
R13: 0075c9a0 R14: 007619c8 R15: 
INFO: task syz-executor.2:9528 blocked for more than 145 seconds.
  Not tainted 5.2.0+ #80
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.2  D28136  9528   9354 0x0004
Call Trace:
 context_switch kernel/sched/core.c:3252 [inline]
 __schedule+0x755/0x1580 kernel/sched/core.c:3878
 schedule+0xa8/0x270 kernel/sched/core.c:3942
 rwsem_down_write_slowpath+0x70a/0xf70 kernel/locking/rwsem.c:1198
 __down_write kernel/locking/rwsem.c:1349 [inline]
 down_write+0x13c/0x150 kernel/locking/rwsem.c:1485
 unregister_netdevice_notifier+0x7e/0x390 net/core/dev.c:1713
 bcm_release+0x93/0x5e0 net/can/bcm.c:1525
 __sock_release+0xce/0x280 net/socket.c:586
 sock_close+0x1e/0x30 net/socket.c:1264
 __fput+0x2ff/0x890 fs/file_table.c:280
 fput+0x16/0x20 fs/file_table.c:313
 task_work_run+0x145/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:185 [inline]
 exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
 do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x413501
Code: 5f fe ff ff 31 c9 31 f6 41 b9 b0 20 41 00 41 b8 8c d6 65 00 ba 02 00  
00 00 bf 28 38 44 00 ff 15 7d a1 24 00 85 c0 0f 85 37 fe  ff 31 c9 31  
f6 41 b9 b0 20 41 00 41 b8 90 d6 65 00 ba 03 00 00

RSP: 002b:00a6fbc0 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0005 RCX: 00413501
RDX:  RSI:  RDI: 0004
RBP: 0001 R08:  R09: 
R10: 00a6fca0 R11: 0293 R12: 0075c9a0
R13: 0075c9a0 R14: 007619c8 R15: 
INFO: task syz-executor.0:9529 blocked for more than 147 seconds.
  Not tainted 5.2.0+ #80
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0  D28136  9529   9353 0x0004
Call Trace:
 context_switch kernel/sched/core.c:3252 [inline]
 __schedule+0x755/0x1580 kernel/sched/core.c:3878
 schedule+0xa8/0x270 kernel/sched/core.c:3942
 rwsem_down_write_slowpath+0x70a/0xf70 kernel/locking/rwsem.c:1198
 __down_write kernel/locking/rwsem.c:1349 [inline]
 down_write+0x13c/0x150 kernel/locking/rwsem.c:1485
 unregister_netdevice_notifier+0x7e/0x390 net/core/dev.c:1713
 bcm_release+0x93/0x5e0 net/can/bcm.c:1525
 

[PATCH] mtd: phram: Module parameters add writable permissions

[Xiaoming Ni]

The phram code implements managing multiple devices through a linked
list.
However, due to the module parameter permission of 0, the
/sys/module/phram/parameters/phram interface is missing.
The command line arguments in insmod can only create one device.

Therefore, add writable permissions to the module parameters, create
/sys/module/phram/parameters/phram interface, and create multi-device
support.

Signed-off-by: Xiaoming Ni 
---
 drivers/mtd/devices/phram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index c467286..931e5c2 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -294,7 +294,7 @@ static int phram_param_call(const char *val, const struct 
kernel_param *kp)
 #endif
 }
 
-module_param_call(phram, phram_param_call, NULL, NULL, 000);
+module_param_call(phram, phram_param_call, NULL, NULL, 0200);
 MODULE_PARM_DESC(phram, "Memory region to map. 
\"phram=,,\"");
 
 
-- 
1.8.5.6

Re: [PATCH v3 0/3] kernel/notifier.c: avoid duplicate registration

[Xiaoming Ni]

On 2019/7/12 22:07, gre...@linuxfoundation.org wrote:
> On Fri, Jul 12, 2019 at 09:11:57PM +0800, Xiaoming Ni wrote:
>> On 2019/7/11 21:57, Vasily Averin wrote:
>>> On 7/11/19 4:55 AM, Nixiaoming wrote:
 On Wed, July 10, 2019 1:49 PM Vasily Averin wrote:
> On 7/10/19 6:09 AM, Xiaoming Ni wrote:
>> Registering the same notifier to a hook repeatedly can cause the hook
>> list to form a ring or lose other members of the list.
>
> I think is not enough to _prevent_ 2nd register attempt,
> it's enough to detect just attempt and generate warning to mark host in 
> bad state.
>

 Duplicate registration is prevented in my patch, not just "mark host in 
 bad state"

 Duplicate registration is checked and exited in 
 notifier_chain_cond_register()

 Duplicate registration was checked in notifier_chain_register() but only 
 the alarm was triggered without exiting. added by commit 831246570d34692e 
 ("kernel/notifier.c: double register detection")

 My patch is like a combination of 831246570d34692e and 
 notifier_chain_cond_register(),
  which triggers an alarm and exits when a duplicate registration is 
 detected.

> Unexpected 2nd register of the same hook most likely will lead to 2nd 
> unregister,
> and it can lead to host crash in any time: 
> you can unregister notifier on first attempt it can be too early, it can 
> be still in use.
> on the other hand you can never call 2nd unregister at all.

 Since the member was not added to the linked list at the time of the 
 second registration, 
 no linked list ring was formed. 
 The member is released on the first unregistration and -ENOENT on the 
 second unregistration.
 After patching, the fault has been alleviated
>>>
>>> You are wrong here.
>>> 2nd notifier's registration is a pure bug, this should never happen.
>>> If you know the way to reproduce this situation -- you need to fix it. 
>>>
>>> 2nd registration can happen in 2 cases:
>>> 1) missed rollback, when someone forget to call unregister after 
>>> successfull registration, 
>>> and then tried to call register again. It can lead to crash for example 
>>> when according module will be unloaded.
>>> 2) some subsystem is registered twice, for example from  different 
>>> namespaces.
>>> in this case unregister called during sybsystem cleanup in first namespace 
>>> will incorrectly remove notifier used 
>>> in second namespace, it also can lead to unexpacted behaviour.
>>>
>> So in these two cases, is it more reasonable to trigger BUG() directly when 
>> checking for duplicate registration ?
>> But why does current notifier_chain_register() just trigger WARN() without 
>> exiting ?
>> notifier_chain_cond_register() direct exit without triggering WARN() ?
> 
> It should recover from this, if it can be detected.  The main point is
> that not all apis have to be this "robust" when used within the kernel
> as we do allow for the callers to know what they are doing :)
> 
In the notifier_chain_register(), the condition ( (*nl) == n) is the same 
registration of the same hook.
 We can intercept this situation and avoid forming a linked list ring to make 
the API more rob

> If this does not cause any additional problems or slow downs, it's
> probably fine to add.
> 
Notifier_chain_register() is not a system hotspot function.
At the same time, there is already a WARN_ONCE judgment. There is no new 
judgment in the new patch.
It only changes the processing under the condition of (*nl) == n, which will 
not cause performance problems.
At the same time, avoiding the formation of a link ring can make the system 
more robust.

> thanks,
> 
> greg k-h
> 
> .
> 
Thanks

Xiaoming Ni

net/netfilter/nf_tables_offload.c:135:24: sparse: sparse: incorrect type in initializer (different base types)

[kbuild test robot]

tree:   
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   a2d79c7174aeb43b13020dd53d85a7aefdd9f3e5
commit: c9626a2cbdb20e26587b3fad99960520a023432b netfilter: nf_tables: add 
hardware offload support
date:   4 days ago
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
git checkout c9626a2cbdb20e26587b3fad99960520a023432b
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> net/netfilter/nf_tables_offload.c:135:24: sparse: sparse: incorrect type in 
>> initializer (different base types) @@expected restricted __be16 
>> [usertype] proto @@got e] proto @@
>> net/netfilter/nf_tables_offload.c:135:24: sparse:expected restricted 
>> __be16 [usertype] proto
>> net/netfilter/nf_tables_offload.c:135:24: sparse:got int

vim +135 net/netfilter/nf_tables_offload.c

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v3 5/7] sched: SIS_CORE to disable idle core search

[Subhra Mazumdar]

On 7/4/19 6:04 PM, Parth Shah wrote:

Same experiment with hackbench and with perf analysis shows increase in L1
cache miss rate with these patches
(Lower is better)
   Baseline(%)   Patch(%)
  --- - ---
   Total Cache miss rate 17.01   19(-11%)
   L1 icache miss rate5.45   6.7(-22%)



So is is possible for idle_cpu search to try checking target_cpu first and
then goto sliding window if not found.
Below diff works as expected in IBM POWER9 system and resolves the problem
of far wakeup upto large extent.

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ff2e9b5c3ac5..fae035ce1162 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6161,6 +6161,7 @@ static int select_idle_cpu(struct task_struct *p, struct 
sched_domain *sd, int t
 u64 time, cost;
 s64 delta;
 int cpu, limit, floor, target_tmp, nr = INT_MAX;
+   struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
  
 this_sd = rcu_dereference(*this_cpu_ptr(_llc));

 if (!this_sd)
@@ -6198,16 +6199,22 @@ static int select_idle_cpu(struct task_struct *p, 
struct sched_domain *sd, int t
  
 time = local_clock();
  
-   for_each_cpu_wrap(cpu, sched_domain_span(sd), target_tmp) {

+   cpumask_and(cpus, sched_domain_span(sd), >cpus_allowed);
+   for_each_cpu_wrap(cpu, cpu_smt_mask(target), target) {
+   __cpumask_clear_cpu(cpu, cpus);
+   if (available_idle_cpu(cpu))
+   goto idle_cpu_exit;
+   }
+
+   for_each_cpu_wrap(cpu, cpus, target_tmp) {
 per_cpu(next_cpu, target) = cpu;
 if (!--nr)
 return -1;
-   if (!cpumask_test_cpu(cpu, >cpus_allowed))
-   continue;
 if (available_idle_cpu(cpu))
 break;
 }
  
+idle_cpu_exit:

 time = local_clock() - time;
 cost = this_sd->avg_scan_cost;
 delta = (s64)(time - cost) / 8;



Best,
Parth

How about calling select_idle_smt before select_idle_cpu from
select_idle_sibling? That should have the same effect.

Re: [GIT PULL] xfs: new features for 5.3

[Linus Torvalds]

On Fri, Jul 12, 2019 at 9:07 PM Darrick J. Wong  wrote:
>
> Doh, it turns out I was merging against the same HEAD as my last two
> pull requests because I forgot to re-pull.  Sorry about that.  It's been
> too long of a week. :/

Heh, no problem, I was just surprised when my merge result didn't
match expectations.

As mentioned, it wasn't like the conflict was complicated, only unexpected.

 Linus

Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

[Finn Thain]

On Sat, 13 Jul 2019, Alexandre Belloni wrote:

> On 26/06/2019 14:42:31+1000, Finn Thain wrote:
> > > Userspace is certainly adjusting the timezone after the kernel did. 
> > > Can you run the same commands without running your init?
> > > 
> > 
> > Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc 
> > and /dev, and got this:
> > 
> > # dmesg | grep rtc_cmos
> > [0.544046] rtc_cmos 00:02: RTC can wake from S4
> > [0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> > [0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes 
> > nvram, hpet irqs
> > [0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 
> > UTC (1561558780)
> > # grep . /etc/adjtime /etc/timezone
> > /etc/adjtime:0.000120 1550184138 0.00
> > /etc/adjtime:1550184138
> > /etc/adjtime:LOCAL
> > /etc/timezone:Australia/Melbourne
> > # hwclock --show
> > 2019-06-26 14:22:25.437089+10:00
> > # date --iso-8601=s
> > 2019-06-27T00:22:45+10:00
> > 
> > As expected, the kernel message still agrees with the output from 
> > hwclock.
> > 
> 
> hwclock has the information that the RTC is in localtime

Right. From the man page:

  The time shown is always in local time, even if you keep your 
  Hardware Clock in UTC.

The output from hwclock is fine, the output from the kernel is confusing.

> but hctosys correctly set the system time to 2019-06-26T14:19:40+00:00, 
> that is 2019-06-27T00:19:40+10:00 so the kernel message is right and the 
> system time is wrong, unless you invoke hwclock -s
> 

I would not say, "correctly set". The system time is wrong here.

> > > On stable, you have /etc/init.d/hwclock.sh that still runs and does 
> > > the correct thing. My understanding is that systemd also handles the 
> > > TZ properly after hctosys (see clock_is_localtime()).
> > > 
> > 
> > This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly 
> > the same: the kernel messages report local time whilst claiming that 
> > it's UTC.
> > 
> 
> That is not what it is reporting, it is reporting that it is setting the 
> system time, thinking that the RTC is in UTC time. Your test shows that 
> this is what happens on x86.
> 

Thanks for your explanation. Please disregard my patch. I see that the 
printk is sensible (i.e. the system clock value is printed in UTC) even 
though the system clock value itself is bogus (up until the init scripts 
fix it).

> > > Seriously, hctosys does a really bad job at setting the system time, 
> > > it is guaranteed to be always wrong on most platforms. My plan is 
> > > still to try to get distros to stop enabling it and do that properly 
> > > in userspace. This is already ok when using sysV but systemd would 
> > > need a few changes to stop relying on it when then is no hwclock 
> > > initscript. Unfortunately, I didn't have time to work on that yet.
> > > 
> > 
> > It doesn't help if you are able to change all of the future distros. 
> > If you remove hctosys you will break some distros which have already 
> > shipped.
> > 
> > For example, I've seen a Debian release that will force a fsck of the 
> > root filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial 
> > of service not a failure, but in general a backward jump by a few 
> > hours can have bad consequences, such as services that refuse to 
> > start.
> > 
> > Anyway, this bug is about a misleading printk, it isn't about removing 
> > functionality. Why conflate these two issues?
> 
> Again, your test shows that I'm correct and hctosys is setting the 
> system time using the RTC time as UTC time. This gets fixed later by 
> userspace.
> 
> PowerPC is the only different platform because it is able to set sys_tz. 
> It is the only platform doing so. What you can do is check 
> sys_tz.tz_minuteswest, keep UTC if it is 0 and print the timezone if it 
> is not.
> 

If userland is responsible for setting sys_tz.tz_minuteswest then we 
probably should not rely on it here.

PowerMacs may set sys_tz.tz_minuteswest because the NVRAM on that platform 
contains the GMT Bias, thanks to Mac OS. Linux never sets this value in 
NVRAM, AFAIK, and Windows doesn't make this value available either.

On PowerMacs, this value already gets logged by the kernel. So I don't 
think any logging change is needed here.

-- 

GOOD DAY

[Dr. Bukola Saraki]

The President of Nigeria MUHAMMADU BUHARI and SENATORS have agree to
compensate all the foreign investors that has business with Nigerians
or the other but didn't receive their fund,they have decide to
compensate the person with sum one million seven hundred thousand
united states dollars if you are one of the victim get back to us with
your full information to show that you are the rightful person.

President of the Senate
Dr. Bukola Saraki
Email:dr.bukolasarak...@gmail.com

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

[Segher Boessenkool]

On Sun, Jul 14, 2019 at 07:45:15AM +0900, Masahiro Yamada wrote:
> On Sat, Jul 13, 2019 at 10:17 PM Segher Boessenkool
>  wrote:
> > On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> > > On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> > > > The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> > > > in a useful way because it is always overridden by the following code
> > > > in the top Makefile:
> > > >
> > > >   # use the deterministic mode of AR if available
> > > >   KBUILD_ARFLAGS := $(call ar-option,D)
> > > >
> > > > The code in the top Makefile was added in 2011, by commit 40df759e2b9e
> > > > ("kbuild: Fix build with binutils <= 2.19").
> > > >
> > > > The KBUILD_ARFLAGS addition for ppc has always been dead code from the
> > > > beginning.
> > >
> > > That was added in 43c9127d94d6 to replace my 8995ac870273 from 2007.
> > >
> > > Is it no longer supported to build a 64-bit kernel with a toolchain
> > > that defaults to 32-bit, or the other way around?  And with non-native
> > > toolchains (this one didn't run on Linux, even).
> >
> > It was an --enable-targets=all toolchain, somewhat common for crosses,
> > if that matters.
> 
> I always use the same toolchain
> for compile-testing PPC32/64.
> 
> I have never been hit by the issue you mention.
> Somebody would have reported it if it were still a problem.

But did you use --enable-targets=all?

The problem was empty archives IIRC.  Not a problem anymore with thin
archives, maybe?

> Moreover, commit 43c9127d94d6
> translated the environment variable "GNUTARGET"
> into the command option "--target="
> 
> My powerpc-linux-ar does not know it:
> 
> powerpc-linux-ar: -t: No such file or directory

Yes, that is why I used the environment variable, all binutils work
with that.  There was no --target option in GNU ar before 2.22.


Segher

[GIT PULL] Mailbox changes for v5.3

[Jassi Brar]

Hi Linus,

The following changes since commit 6fbc7275c7a9ba97877050335f290341a1fd8dbf:

  Linux 5.2-rc7 (2019-06-30 11:25:36 +0800)

are available in the Git repository at:

  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
tags/mailbox-v5.3

for you to fetch changes up to 25777e5784a7b417967460d4fcf9660d05a0c320:

  mailbox: handle failed named mailbox channel request (2019-07-11
10:19:00 -0500)


- stm32: race fix by adding a spinlock
- mhu: trim included headers
- omap: add support for K3 SoCs
- imx: Irq disable fix
- bcm: tidy up extracting driver data
- tegra: make resume 'noirq'
- api: fix error handling


Arnaud Pouliquen (1):
  mailbox: stm32_ipcc: add spinlock to fix channels concurrent access

Bitan Biswas (2):
  mailbox: tegra: hsp: add noirq resume
  mailbox: tegra: avoid resume NULL mailboxes

Daniel Baluta (1):
  mailbox: imx: Clear GIEn bit at shutdown

Fuqian Huang (1):
  mailbox: bcm-flexrm-mailbox: using dev_get_drvdata directly

Sudeep Holla (1):
  mailbox: arm_mhu: reorder header inclusion and drop unneeded ones

Suman Anna (2):
  dt-bindings: mailbox: omap: Update bindings for TI K3 SoCs
  mailbox: omap: Add support for TI K3 SoCs

morten petersen (1):
  mailbox: handle failed named mailbox channel request

 .../devicetree/bindings/mailbox/omap-mailbox.txt   | 59 ++
 drivers/mailbox/Kconfig|  2 +-
 drivers/mailbox/arm_mhu.c  | 11 ++--
 drivers/mailbox/bcm-flexrm-mailbox.c   |  6 +--
 drivers/mailbox/imx-mailbox.c  |  4 +-
 drivers/mailbox/mailbox.c  |  6 ++-
 drivers/mailbox/omap-mailbox.c | 43 +---
 drivers/mailbox/stm32-ipcc.c   | 37 ++
 drivers/mailbox/tegra-hsp.c| 20 ++--
 include/linux/omap-mailbox.h   |  4 +-
 10 files changed, 134 insertions(+), 58 deletions(-)

Re: [PATCH v2] jffs2: remove C++ style comments from uapi header

[Masahiro Yamada]

On Thu, Jun 27, 2019 at 4:39 PM Richard Weinberger  wrote:
>
> - Ursprüngliche Mail -
> > Von: "Masahiro Yamada" 
> > An: "richard" 
> > CC: "Vignesh Raghavendra" , "Boris Brezillon" 
> > , "linux-kernel"
> > , "Marek Vasut" , 
> > "linux-mtd" ,
> > "Miquel Raynal" , "Brian Norris" 
> > , "David Woodhouse"
> > 
> > Gesendet: Donnerstag, 27. Juni 2019 09:06:31
> > Betreff: Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
>
> > On Tue, Jun 18, 2019 at 3:20 PM Richard Weinberger  wrote:
> >>
> >> - Ursprüngliche Mail -
> >> > Von: "Masahiro Yamada" 
> >> > An: "linux-mtd" 
> >> > CC: "Boris Brezillon" , "Miquel Raynal"
> >> > , "Brian Norris"
> >> > , "Vignesh Raghavendra" , 
> >> > "Marek
> >> > Vasut" ,
> >> > "Masahiro Yamada" , "richard" 
> >> > ,
> >> > "David Woodhouse" ,
> >> > "linux-kernel" 
> >> > Gesendet: Dienstag, 18. Juni 2019 05:09:26
> >> > Betreff: [PATCH v2] jffs2: remove C++ style comments from uapi header
> >>
> >> > Linux kernel tolerates C++ style comments these days. Actually, the
> >> > SPDX License tags for .c files start with //.
> >> >
> >> > On the other hand, uapi headers are written in more strict C, where
> >> > the C++ comment style is forbidden.
> >> >
> >> > I simply dropped these lines instead of fixing the comment style.
> >> >
> >> > This code has been always commented out since it was added around
> >> > Linux 2.4.9 (i.e. commented out for more than 17 years).
> >> >
> >> > 'Maybe later...' will never happen.
> >>
> >> :-)
> >>
> >> > Signed-off-by: Masahiro Yamada 
> >>
> >> Acked-by: Richard Weinberger 
> >>
> >> Thanks,
> >> //richard
> >
> >
> > Will this be picked up for v5.3-rc1 ?
>
> Yes.
>
> Thanks,
> //richard



Looks like this trivial patch missed the pull request.


My motivation is to make sure UAPI headers
are really compilable in user-space,
and now checked by the following commit:

commit d6fc9fcbaa655cff2d2be05e16867d1918f78b85
Author: Masahiro Yamada 
Date:   Mon Jul 1 09:58:40 2019 +0900

kbuild: compile-test exported headers to ensure they are self-contained



Is there a chance for it being merged,
or must wait until v5.4-rc1 ?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] phy: Change the configuration interface param to void* to make it more general

[kbuild test robot]

Hi Zeng,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[cannot apply to v5.2 next-20190712]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Zeng-Tao/phy-Change-the-configuration-interface-param-to-void-to-make-it-more-general/20190713-213420
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

>> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:155:16: warning: 'struct 
>> phy_configure_opts_mipi_dphy' declared inside parameter list will not be 
>> visible outside of this definition or declaration
struct phy_configure_opts_mipi_dphy *dphy_opts,
   ^~~~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: In function 
'mixel_dphy_config_from_opts':
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:165:15: error: dereferencing 
pointer to incomplete type 'struct phy_configure_opts_mipi_dphy'
 if (dphy_opts->hs_clk_rate > DATA_RATE_MAX_SPEED ||
  ^~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: At top level:
>> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:320:56: warning: 'union 
>> phy_configure_opts' declared inside parameter list will not be visible 
>> outside of this definition or declaration
static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
   ^~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: In function 
'mixel_dphy_configure':
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:326:46: error: dereferencing 
pointer to incomplete type 'union phy_configure_opts'
 ret = mixel_dphy_config_from_opts(phy, >mipi_dphy, );
 ^~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: At top level:
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:349:17: warning: 'union 
phy_configure_opts' declared inside parameter list will not be visible outside 
of this definition or declaration
  union phy_configure_opts *opts)
^~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: In function 
'mixel_dphy_validate':
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:356:47: error: dereferencing 
pointer to incomplete type 'union phy_configure_opts'
 return mixel_dphy_config_from_opts(phy, >mipi_dphy, );
  ^~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: At top level:
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:419:15: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types]
 .configure = mixel_dphy_configure,
  ^~~~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:419:15: note: (near 
initialization for 'mixel_dphy_phy_ops.configure')
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:420:14: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types]
 .validate = mixel_dphy_validate,
 ^~~
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:420:14: note: (near 
initialization for 'mixel_dphy_phy_ops.validate')
   drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c: In function 
'mixel_dphy_validate':
>> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:357:1: warning: control 
>> reaches end of non-void function [-Wreturn-type]
}
^
   cc1: some warnings being treated as errors
--
   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 
'sun6i_dsi_encoder_enable':
   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: variable 'opts' has 
initializer but incomplete type
 union phy_configure_opts opts = { 0 };
   ^~
>> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:36: warning: excess elements in 
>> union initializer
 union phy_configure_opts opts = { 0 };
   ^
   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:36: note: (near initialization 
for 'opts')
   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:27: error: storage size of 'opts' 
isn't known
 union phy_configure_opts opts = { 0 };
  ^~~~
   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:27: warning: unused variable 
'opts' [-Wunused-variable]

vim +155 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c

f4c8116e294b12c Guido G??nther 2019-06-20  153  
f4c8116e294b12c Guido G??

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-1 tag

[pr-tracker-bot]

The pull request you sent on Sat, 13 Jul 2019 14:28:00 +1000:

> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
> tags/powerpc-5.3-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/192f0f8e9db7efe4ac98d47f5fa4334e43c1204d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 23:17:42 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec9249752465b87b5b26d03f476eebaf872ebd12

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Networking

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 23:17:04 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d12109291ccbef7e879cc0d0733f31685cd80854

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Ide

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 23:17:24 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1fa91854dcdf7829e2694873b19f96b65947112d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

DHL

[Pastor David]

Re: [REGRESSION] Xorg segfaults on Asus Chromebook CP101 with Linux v5.2 (was Asus C101P Chromeboot fails to boot with Linux 5.2)

[Ezequiel Garcia]

On Sat, 13 Jul 2019 at 13:43, Alex Dewar  wrote:
>
> On 13/07/2019 16:17, Heiko Stuebner wrote:
> > Hi,
> >
> > Am Samstag, 13. Juli 2019, 13:38:45 CEST schrieb Alex Dewar:
> >> I initially thought my machine was failing to boot entirely, but it
> >> turns out it was just failing to start the display manager. I managed to
> >> escape to a tty by hammering the keyboard a bit.
> >>
> >> I suspect the culprit is the rockchip_vpu driver (in staging/media),
> >> which has been renamed to hantro in this merge window. When I run startx
> >> from a terminal, X fails to start and Xorg segfaults (log here:
> >> http://users.sussex.ac.uk/~ad374/xorg.log). X seems to work without any
> >> issues in v5.1.
> >
> > 5.2 also has support for Panfrost (Mali-Midgard GPUs) but I'm not
> > sure if it already can support X11 yet and your X11 log mentions
> > libglamoregl in the segfault stack trace.
> >
> > Apart from it bisect that Greg suggested you could also just try
> > blacklisting either panfrost or vpu kernel modules
> > /etc/udev/somewhere . This would prevent them from loading
> >
> > Hope that helps
> > Heiko
> >
> >
>
> Hi Heiko,
>
> Thanks for this. I blacklisted the panfrost driver and X magically
> started working again.
>
> I'll try to do a bisect later to find the offending commit though.
>
> In related news, it also seems that the sound and wifi drivers aren't
> working either in 5.2 (although I need to do a bit more testing to
> confirm the latter).
>

Adding myself and Tomeu.

Perhaps we need to disable Panfrost from defconfig from now?

Regards,
Eze

Re: [GIT PULL] Pin control bulk changes for v5.3

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 11:10:34 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git 
> tags/pinctrl-v5.3-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/43c95d3694cc448fdf50bd53b7ff3a5bb4655883

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [git pull] Input updates for v5.3-rc0

[pr-tracker-bot]

The pull request you sent on Thu, 11 Jul 2019 22:41:58 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/073c916bc00571d8662b89a294eba265481b6fbb

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] IPMI bug fixes for 5.3

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 06:52:04 -0500:

> https://github.com/cminyard/linux-ipmi.git tags/for-linus-5.3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/92adeb616c9172dea9678f53ea6e5501fc4f4338

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

[Masahiro Yamada]

On Sat, Jul 13, 2019 at 10:17 PM Segher Boessenkool
 wrote:
>
> On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> > On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> > > The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> > > in a useful way because it is always overridden by the following code
> > > in the top Makefile:
> > >
> > >   # use the deterministic mode of AR if available
> > >   KBUILD_ARFLAGS := $(call ar-option,D)
> > >
> > > The code in the top Makefile was added in 2011, by commit 40df759e2b9e
> > > ("kbuild: Fix build with binutils <= 2.19").
> > >
> > > The KBUILD_ARFLAGS addition for ppc has always been dead code from the
> > > beginning.
> >
> > That was added in 43c9127d94d6 to replace my 8995ac870273 from 2007.
> >
> > Is it no longer supported to build a 64-bit kernel with a toolchain
> > that defaults to 32-bit, or the other way around?  And with non-native
> > toolchains (this one didn't run on Linux, even).
>
> It was an --enable-targets=all toolchain, somewhat common for crosses,
> if that matters.


I always use the same toolchain
for compile-testing PPC32/64.

I have never been hit by the issue you mention.
Somebody would have reported it if it were still a problem.

Moreover, commit 43c9127d94d6
translated the environment variable "GNUTARGET"
into the command option "--target="

My powerpc-linux-ar does not know it:

powerpc-linux-ar: -t: No such file or directory




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4.19 00/91] 4.19.59-stable review

[Guenter Roeck]

On 7/12/19 5:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.59 release.
There are 91 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
Anything received after that time might be too late.



For v4.19.58-91-g778a2640e781:

Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 364 pass: 364 fail: 0

Guenter

Re: [PATCH 5.2 00/61] 5.2.1-stable review

[Guenter Roeck]

On 7/12/19 5:19 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.2.1 release.
There are 61 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
Anything received after that time might be too late.



For v5.2-61-g0a498a7d2850:

Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 364 pass: 364 fail: 0

Guenter

Re: [PATCH 5.1 000/138] 5.1.18-stable review

[Guenter Roeck]

On 7/12/19 5:17 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.1.18 release.
There are 138 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
Anything received after that time might be too late.



For v5.1.17-134-gd68c746af314:

Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 364 pass: 364 fail: 0

Guenter

Re: [PATCH] mm: page_alloc: document kmemleak's non-blockable __GFP_NOFAIL case

[Matthew Wilcox]

On Sat, Jul 13, 2019 at 04:49:04AM +0800, Yang Shi wrote:
> When running ltp's oom test with kmemleak enabled, the below warning was
> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> passed in:

There are lots of places where kmemleak will call kmalloc with
__GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM (including the XArray code, which
is how I know about it).  It needs to be fixed to allow its internal
allocations to fail and return failure of the original allocation as
a consequence.

Re: [v3,1/2] rtc/fsl: add FTM alarm driver as the wakeup source

[Alexandre Belloni]

Hi,

On 11/07/2019 22:37:48+0800, Biwen Li wrote:
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 9d997fa..5cccb07 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += 
> rtc-hid-sensor-time.o
>  obj-$(CONFIG_RTC_DRV_HYM8563)+= rtc-hym8563.o
>  obj-$(CONFIG_RTC_DRV_IMXDI)  += rtc-imxdi.o
>  obj-$(CONFIG_RTC_DRV_IMX_SC) += rtc-imx-sc.o
> +obj-$(CONFIG_RTC_DRV_FSL_FTM_ALARM)  += rtc-fsl-ftm-alarm.o

This file is sorted alphabetically.

>  obj-$(CONFIG_RTC_DRV_ISL12022)   += rtc-isl12022.o
>  obj-$(CONFIG_RTC_DRV_ISL12026)   += rtc-isl12026.o
>  obj-$(CONFIG_RTC_DRV_ISL1208)+= rtc-isl1208.o
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
> new file mode 100644
> index 000..4fd0d6b
> --- /dev/null
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Freescale FlexTimer Module (FTM) alarm device driver.
> + *
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2019 NXP
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
> +
> +/*
> + * Select Fixed frequency clock (32KHz) as clock source
> + * of FlexTimer Module
> + */
> +#define FTM_SC_CLKS_FIXED_FREQ   0x02
> +#define FIXED_FREQ_CLK   32000
> +
> +/* Select 128 (2^7) as divider factor */
> +#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
> +
> +/* Maximum counter value in FlexTimer's CNT registers */
> +#define MAX_COUNT_VAL0x
> +
> +struct ftm_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + bool big_endian;
> + u32 alarm_freq;
> +};
> +
> +static inline u32 rtc_readl(struct ftm_rtc *dev, u32 reg)
> +{
> + if (dev->big_endian)
> + return ioread32be(dev->base + reg);
> + else
> + return ioread32(dev->base + reg);
> +}
> +
> +static inline void rtc_writel(struct ftm_rtc *dev, u32 reg, u32 val)
> +{
> + if (dev->big_endian)
> + iowrite32be(val, dev->base + reg);
> + else
> + iowrite32(val, dev->base + reg);
> +}
> +
> +static inline void ftm_counter_enable(struct ftm_rtc *rtc)
> +{
> + u32 val;
> +
> + /* select and enable counter clock source */
> + val = rtc_readl(rtc, FTM_SC);
> + val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
> + val |= (FTM_SC_PS_MASK | FTM_SC_CLK(FTM_SC_CLKS_FIXED_FREQ));
> + rtc_writel(rtc, FTM_SC, val);
> +}
> +
> +static inline void ftm_counter_disable(struct ftm_rtc *rtc)
> +{
> + u32 val;
> +
> + /* disable counter clock source */
> + val = rtc_readl(rtc, FTM_SC);
> + val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
> + rtc_writel(rtc, FTM_SC, val);
> +}
> +
> +static inline void ftm_irq_acknowledge(struct ftm_rtc *rtc)
> +{
> + unsigned int timeout = 100;
> +
> + /*
> +  *Fix errata A-007728 for flextimer
> +  *  If the FTM counter reaches the FTM_MOD value between
> +  *  the reading of the TOF bit and the writing of 0 to
> +  *  the TOF bit, the process of clearing the TOF bit
> +  *  does not work as expected when FTMx_CONF[NUMTOF] != 0
> +  *  and the current TOF count is less than FTMx_CONF[NUMTOF].
> +  *  If the above condition is met, the TOF bit remains set.
> +  *  If the TOF interrupt is enabled (FTMx_SC[TOIE] = 1),the
> +  *  TOF interrupt also remains asserted.
> +  *
> +  *  Above is the errata discription
> +  *
> +  *  In one word: software clearing TOF bit not works when
> +  *  FTMx_CONF[NUMTOF] was seted as nonzero and FTM counter
> +  *  reaches the FTM_MOD value.
> +  *
> +  *  The workaround is clearing TOF bit until it works
> +  *  (FTM counter doesn't always reache the FTM_MOD anyway),
> +  *  which may cost some cycles.
> +  */
> + while ((FTM_SC_TOF & rtc_readl(rtc, FTM_SC)) && timeout--)
> + rtc_writel(rtc, FTM_SC, rtc_readl(rtc, FTM_SC) & (~FTM_SC_TOF));
> +}
> +
> +static inline void ftm_irq_enable(struct ftm_rtc *rtc)
> +{
> + u32 val;
> +
> + val = rtc_readl(rtc, FTM_SC);
> + val |= FTM_SC_TOIE;
> + rtc_writel(rtc, FTM_SC, val);
> +}
> +
> +static inline void ftm_irq_disable(struct ftm_rtc *rtc)
> +{
> + u32 val;
> +
> + val = rtc_readl(rtc, FTM_SC);
> + val &= ~FTM_SC_TOIE;
> + rtc_writel(rtc, FTM_SC, val);
> +}
> +
> +static inline void ftm_reset_counter(struct ftm_rtc *rtc)
> +{
> + /*
> +  * The CNT register contains the FTM counter value.
> +  * Reset clears the CNT register. Writing any value to COUNT
> +  * updates the counter with its initial value, CNTIN.
> +  */
> + 

Re: [PATCH 2/3] rtc: Add support for the MediaTek MT2712 RTC

[Alexandre Belloni]

Hi,

On 02/07/2019 11:21:19+0800, Ran Bi wrote:
> diff --git a/drivers/rtc/rtc-mt2712.c b/drivers/rtc/rtc-mt2712.c
> new file mode 100644
> index ..f98f0ab114c5
> --- /dev/null
> +++ b/drivers/rtc/rtc-mt2712.c
> @@ -0,0 +1,495 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Ran Bi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MTK_RTC_DEV  KBUILD_MODNAME
> +
> +#define RTC_BBPU 0x
> +#define RTC_BBPU_CLRPKY  (1U << 4)

Please use BIT(). Also, I don't feel that the RTC prefix is adding any
value. MT2712 would be a better choice here.

> +#define RTC_BBPU_RELOAD  (1U << 5)
> +#define RTC_BBPU_CBUSY   (1U << 6)
> +#define RTC_BBPU_KEY (0x43 << 8)
> +
> +#define RTC_IRQ_STA  0x0004
> +#define RTC_IRQ_STA_AL   (1U << 0)
> +#define RTC_IRQ_STA_TC   (1U << 1)
> +
> +#define RTC_IRQ_EN   0x0008
> +#define RTC_IRQ_EN_AL(1U << 0)
> +#define RTC_IRQ_EN_TC(1U << 1)
> +#define RTC_IRQ_EN_ONESHOT   (1U << 2)
> +#define RTC_IRQ_EN_ONESHOT_AL(RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
> +
> +#define RTC_CII_EN   0x000c
> +
> +#define RTC_AL_MASK  0x0010
> +#define RTC_AL_MASK_DOW  (1U << 4)
> +
> +#define RTC_TC_SEC   0x0014
> +#define RTC_TC_MIN   0x0018
> +#define RTC_TC_HOU   0x001c
> +#define RTC_TC_DOM   0x0020
> +#define RTC_TC_DOW   0x0024
> +#define RTC_TC_MTH   0x0028
> +#define RTC_TC_YEA   0x002c
> +
> +#define RTC_AL_SEC   0x0030
> +#define RTC_AL_MIN   0x0034
> +#define RTC_AL_HOU   0x0038
> +#define RTC_AL_DOM   0x003c
> +#define RTC_AL_DOW   0x0040
> +#define RTC_AL_MTH   0x0044
> +#define RTC_AL_YEA   0x0048
> +
> +#define RTC_SEC_MASK 0x003f
> +#define RTC_MIN_MASK 0x003f
> +#define RTC_HOU_MASK 0x001f
> +#define RTC_DOM_MASK 0x001f
> +#define RTC_DOW_MASK 0x0007
> +#define RTC_MTH_MASK 0x000f
> +#define RTC_YEA_MASK 0x007f
> +
> +#define RTC_POWERKEY10x004c
> +#define RTC_POWERKEY20x0050
> +#define RTC_POWERKEY1_KEY0xa357
> +#define RTC_POWERKEY2_KEY0x67d2
> +
> +#define RTC_CON0 0x005c
> +#define RTC_CON1 0x0060
> +
> +#define RTC_PROT 0x0070
> +#define RTC_PROT_UNLOCK1 0x9136
> +#define RTC_PROT_UNLOCK2 0x586a
> +
> +#define RTC_WRTGR0x0078
> +
> +/* we map HW YEAR 0 to 1968 not 1970 because 2000 is the leap year */
> +#define RTC_MIN_YEAR 1968
> +#define RTC_BASE_YEAR1900
> +#define RTC_MIN_YEAR_OFFSET  (RTC_MIN_YEAR - RTC_BASE_YEAR)

Do not do that. If this RTC range starts in 200, ths is what the driver
has to support, you should not care about dates before 2000. Note that
the RTC core can still properly shift the range if it is absolutely
necessary.

> +
> +#define RTC_DEFAULT_YEA  2010
> +#define RTC_DEFAULT_MTH  1
> +#define RTC_DEFAULT_DOM  1
> +
> +struct mt2712_rtc {
> + struct device   *dev;
> + struct rtc_device   *rtc_dev;
> + void __iomem*base;
> + struct mutexlock;
> + int irq;
> + u8  irq_wake_enabled;
> +};
> +
> +static inline u32 rtc_readl(struct mt2712_rtc *rtc, u32 reg)

Please use a more descriptive prefix than just rtc_.

> +{
> + return readl(rtc->base + reg);
> +}
> +
> +static inline void rtc_writel(struct mt2712_rtc *rtc, u32 reg, u32 val)
> +{
> + writel(val, rtc->base + reg);
> +}
> +
> +static void rtc_write_trigger(struct mt2712_rtc *rtc)
> +{
> + unsigned long timeout = jiffies + HZ/10;
> +
> + rtc_writel(rtc, RTC_WRTGR, 1);
> + while (1) {
> + if (!(rtc_readl(rtc, RTC_BBPU) & RTC_BBPU_CBUSY))
> + break;
> +
> + if (time_after(jiffies, timeout)) {
> + dev_err(rtc->dev, "%s time out!\n", __func__);
> + break;
> + }
> + cpu_relax();
> + }
> +}
> +
> +static void rtc_writeif_unlock(struct mt2712_rtc *rtc)
> +{
> + rtc_writel(rtc, RTC_PROT, RTC_PROT_UNLOCK1);
> + rtc_write_trigger(rtc);
> + rtc_writel(rtc, RTC_PROT, RTC_PROT_UNLOCK2);
> + rtc_write_trigger(rtc);
> +}
> +
> +static irqreturn_t rtc_irq_handler_thread(int irq, void *data)
> +{
> + struct mt2712_rtc *rtc = data;
> + u16 irqsta, irqen;
> +
> + irqsta = rtc_readl(rtc, RTC_IRQ_STA);
> + if (irqsta & RTC_IRQ_STA_AL) {
> + rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
> + irqen = irqsta & ~RTC_IRQ_EN_AL;
> +
> + mutex_lock(>lock);

You should take rtc->rtc_dev->ops_lock. 

Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

[Alexandre Belloni]

On 26/06/2019 14:42:31+1000, Finn Thain wrote:
> > Userspace is certainly adjusting the timezone after the kernel did. Can 
> > you run the same commands without running your init?
> > 
> 
> Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc and 
> /dev, and got this:
> 
> # dmesg | grep rtc_cmos
> [0.544046] rtc_cmos 00:02: RTC can wake from S4
> [0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> [0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, 
> hpet irqs
> [0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 
> UTC (1561558780)
> # grep . /etc/adjtime /etc/timezone
> /etc/adjtime:0.000120 1550184138 0.00
> /etc/adjtime:1550184138
> /etc/adjtime:LOCAL
> /etc/timezone:Australia/Melbourne
> # hwclock --show
> 2019-06-26 14:22:25.437089+10:00
> # date --iso-8601=s
> 2019-06-27T00:22:45+10:00
> 
> As expected, the kernel message still agrees with the output from hwclock.
> 

hwclock has the information that the RTC is in localtime but hctosys
correctly set the system time to 2019-06-26T14:19:40+00:00, that is
2019-06-27T00:19:40+10:00 so the kernel message is right and the system
time is wrong, unless you invoke hwclock -s

> > On stable, you have /etc/init.d/hwclock.sh that still runs and does the 
> > correct thing. My understanding is that systemd also handles the TZ 
> > properly after hctosys (see clock_is_localtime()).
> > 
> 
> This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly the 
> same: the kernel messages report local time whilst claiming that it's UTC.
> 

That is not what it is reporting, it is reporting that it is setting the
system time, thinking that the RTC is in UTC time. Your test shows that
this is what happens on x86.

> > Seriously, hctosys does a really bad job at setting the system time, it 
> > is guaranteed to be always wrong on most platforms. My plan is still to 
> > try to get distros to stop enabling it and do that properly in 
> > userspace. This is already ok when using sysV but systemd would need a 
> > few changes to stop relying on it when then is no hwclock initscript. 
> > Unfortunately, I didn't have time to work on that yet.
> > 
> 
> It doesn't help if you are able to change all of the future distros. If 
> you remove hctosys you will break some distros which have already shipped.
> 
> For example, I've seen a Debian release that will force a fsck of the root 
> filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial of 
> service not a failure, but in general a backward jump by a few hours can 
> have bad consequences, such as services that refuse to start.
> 
> Anyway, this bug is about a misleading printk, it isn't about removing 
> functionality. Why conflate these two issues?

Again, your test shows that I'm correct and hctosys is setting the
system time using the RTC time as UTC time. This gets fixed later by
userspace.

PowerPC is the only different platform because it is able to set sys_tz.
It is the only platform doing so. What you can do is check
sys_tz.tz_minuteswest, keep UTC if it is 0 and print the timezone if it
is not.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 5.1 000/138] 5.1.18-stable review

[Luke Nowakowski-Krijger]

On Fri, Jul 12, 2019 at 02:17:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.18 release.
> There are 138 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.18-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.1.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on x86_64. No dmesg regressions.

Thanks, 

Luke

Re: [PATCH 4.19 00/91] 4.19.59-stable review

[Luke Nowakowski-Krijger]

On Fri, Jul 12, 2019 at 02:18:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.59 release.
> There are 91 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.59-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my x86_64 system. No dmesg regressions. 

Thanks,

Luke

Re: [PATCH 5.2 00/61] 5.2.1-stable review

[Luke Nowakowski-Krijger]

On Fri, Jul 12, 2019 at 02:19:13PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.1 release.
> There are 61 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.1-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.2.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my x86_64 system. No dmesg regressions. 

Thanks, 

Luke

Re: [PATCH] phy: Change the configuration interface param to void* to make it more general

[Sakari Ailus]

On Fri, Jul 12, 2019 at 09:21:45AM +0200, Maxime Ripard wrote:
> On Fri, Jul 12, 2019 at 05:26:04PM +0800, Zeng Tao wrote:
> > The phy framework now allows runtime configurations, but only limited
> > to mipi now, and it's not reasonable to introduce user specified
> > configurations into the union phy_configure_opts structure. An simple
> > way is to replace with a void *.
> >
> > We have already got some phy drivers which introduce private phy API
> > for runtime configurations, and with this patch, they can switch to
> > the phy_configure as a replace.
> >
> > Signed-off-by: Zeng Tao 
> 
> I still don't believe this is the right approach, for the reasons
> exposed in my first review of that patch.

I agree.

The very reason for having PHY type specific structs is to allow configuring
the PHY independently of the PHY device. This patch breaks that.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH] drivers: rtc: rtc-wm831x: Add IRQF_ONESHOT flag

[Alexandre Belloni]

On 11/07/2019 23:26:15+0530, Hariprasad Kelam wrote:
> fix below issue reported by coccicheck
> drivers//rtc/rtc-wm831x.c:436:7-32: ERROR: Threaded IRQ with no primary
> handler requested without IRQF_ONESHOT
> 
> Signed-off-by: Hariprasad Kelam 
> ---
>  drivers/rtc/rtc-wm831x.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] mm: page_alloc: document kmemleak's non-blockable __GFP_NOFAIL case

[David Rientjes]

On Sat, 13 Jul 2019, Yang Shi wrote:

> When running ltp's oom test with kmemleak enabled, the below warning was
> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> passed in:
> 
> WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 
> __alloc_pages_nodemask+0x1c31/0x1d50
> Modules linked in: loop dax_pmem dax_pmem_core
> ip_tables x_tables xfs virtio_net net_failover virtio_blk failover
> ata_generic virtio_pci virtio_ring virtio libata
> CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
> ...
>  kmemleak_alloc+0x4e/0xb0
>  kmem_cache_alloc+0x2a7/0x3e0
>  ? __kmalloc+0x1d6/0x470
>  ? ___might_sleep+0x9c/0x170
>  ? mempool_alloc+0x2b0/0x2b0
>  mempool_alloc_slab+0x2d/0x40
>  mempool_alloc+0x118/0x2b0
>  ? __kasan_check_read+0x11/0x20
>  ? mempool_resize+0x390/0x390
>  ? lock_downgrade+0x3c0/0x3c0
>  bio_alloc_bioset+0x19d/0x350
>  ? __swap_duplicate+0x161/0x240
>  ? bvec_alloc+0x1b0/0x1b0
>  ? do_raw_spin_unlock+0xa8/0x140
>  ? _raw_spin_unlock+0x27/0x40
>  get_swap_bio+0x80/0x230
>  ? __x64_sys_madvise+0x50/0x50
>  ? end_swap_bio_read+0x310/0x310
>  ? __kasan_check_read+0x11/0x20
>  ? check_chain_key+0x24e/0x300
>  ? bdev_write_page+0x55/0x130
>  __swap_writepage+0x5ff/0xb20
> 
> The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, kmemleak has
> __GFP_NOFAIL set all the time due to commit
> d9570ee3bd1d4f20ce63485f5ef05663866fe6c0 ("kmemleak: allow to coexist
> with fault injection").
> 

It only clears __GFP_DIRECT_RECLAIM provisionally to see if the allocation 
would immediately succeed before falling back to the elements in the 
mempool.  If that fails, and the mempool is empty, mempool_alloc() 
attempts the allocation with __GFP_DIRECT_RECLAIM.  So for the problem 
described here, I think what we really want is this:

diff --git a/mm/mempool.c b/mm/mempool.c
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -386,7 +386,7 @@ void *mempool_alloc(mempool_t *pool, gfp_t gfp_mask)
gfp_mask |= __GFP_NORETRY;  /* don't loop in __alloc_pages */
gfp_mask |= __GFP_NOWARN;   /* failures are OK */
 
-   gfp_temp = gfp_mask & ~(__GFP_DIRECT_RECLAIM|__GFP_IO);
+   gfp_temp = gfp_mask & ~(__GFP_DIRECT_RECLAIM|__GFP_IO|__GFP_NOFAIL);
 
 repeat_alloc:
 
But bio_alloc_bioset() plays with gfp_mask itself: are we sure that it 
isn't the one clearing __GFP_DIRECT_RECLAIM itself before falling back to 
saved_gfp?

In other words do we also want this?

diff --git a/block/bio.c b/block/bio.c
--- a/block/bio.c
+++ b/block/bio.c
@@ -462,16 +462,16 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, unsigned int 
nr_iovecs,
 * We solve this, and guarantee forward progress, with a rescuer
 * workqueue per bio_set. If we go to allocate and there are
 * bios on current->bio_list, we first try the allocation
-* without __GFP_DIRECT_RECLAIM; if that fails, we punt those
-* bios we would be blocking to the rescuer workqueue before
-* we retry with the original gfp_flags.
+* without __GFP_DIRECT_RECLAIM or __GFP_NOFAIL; if that fails,
+* we punt those bios we would be blocking to the rescuer
+* workqueue before we retry with the original gfp_flags.
 */
-
if (current->bio_list &&
(!bio_list_empty(>bio_list[0]) ||
 !bio_list_empty(>bio_list[1])) &&
bs->rescue_workqueue)
-   gfp_mask &= ~__GFP_DIRECT_RECLAIM;
+   gfp_mask &= ~(__GFP_DIRECT_RECLAIM |
+ __GFP_NOFAIL);
 
p = mempool_alloc(>bio_pool, gfp_mask);
if (!p && gfp_mask != saved_gfp) {

Re: [PATCH] rtc: pcf2123: Fix build error

[Alexandre Belloni]

On 04/07/2019 16:55:42+0800, YueHaibing wrote:
> If REGMAP_SPI is m and RTC_DRV_PCF2123 is y,
> 
> drivers/rtc/rtc-pcf2123.o: In function `pcf2123_probe':
> rtc-pcf2123.c:(.text+0xb2b): undefined reference to `__devm_regmap_init_spi'
> 
> Select REGMAP_SPI as RTC_DRV_DS1347 driver does.
> 
> Reported-by: Hulk Robot 
> Fixes: 790d033933b8 ("rtc: pcf2123: port to regmap")
> Signed-off-by: YueHaibing 
> ---
>  drivers/rtc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
Applied, thanks.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 5.1 000/138] 5.1.18-stable review

[Jon Hunter]

On 13/07/2019 15:31, Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2019 at 10:16:58AM +0100, Jon Hunter wrote:
>>
>> On 12/07/2019 16:30, Greg Kroah-Hartman wrote:
>>> On Fri, Jul 12, 2019 at 02:26:57PM +0100, Jon Hunter wrote:
 Hi Greg,

 On 12/07/2019 13:17, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.18 release.
> There are 138 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.18-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -
> Pseudo-Shortlog of commits:

 ...

> Keerthy 
> ARM: dts: dra71x: Disable usb4_tm target module

 ...

> Keerthy 
> ARM: dts: dra76x: Disable usb4_tm target module

 The above commits are generating the following compilation errors for
 ARM ...

 Error:
 /dvs/git/dirty/git-master_l4t-upstream/kernel/arch/arm/boot/dts/dra71x.dtsi:15.1-9
 Label or path usb4_tm not found

 Error:
 /dvs/git/dirty/git-master_l4t-upstream/kernel/arch/arm/boot/dts/dra76x.dtsi:89.1-9
 Label or path usb4_tm not found

 After reverting these two, I no longer see these errors.
>>>
>>> Both are now dropped, thanks.  I'll push out a -rc2 with that changed.
>>
>> Hmmm ... -rc2 still not building ...
>>
>> Error:
>> /dvs/git/dirty/git-master_l4t-upstream/kernel/arch/arm/boot/dts/dra71x.dtsi:11.1-11
>> Label or path rtctarget not found
>> Error:
>> /dvs/git/dirty/git-master_l4t-upstream/kernel/arch/arm/boot/dts/dra71x.dtsi:15.1-9
>> Label or path usb4_tm not found
>>
>> I still see the following commit in -rc2 ...
>>
>> commit 0caa574b3244cd863dd74bde680a6309cb8803ad
>> Author: Keerthy 
>> Date:   Fri May 17 06:44:09 2019 +0530
>>
>> ARM: dts: dra71x: Disable usb4_tm target module
>>
>> In -rc1 I see there were 4 changes from Keerthy, any chance you reverted
>> one of the rtc patches and not the above? Looks like the following is
>> missing from -rc2 ...
>>
>> Keerthy 
>> ARM: dts: dra76x: Disable rtc target module
> 
> Sorry, I dropped one, but not the other.  Both now gone.

Great! This looks better. All tests passing now ...

Test results for stable-v5.1:
12 builds:  12 pass, 0 fail
22 boots:   22 pass, 0 fail
32 tests:   32 pass, 0 fail

Linux version:  5.1.18-rc3-gd68c746af314
Boards tested:  tegra124-jetson-tk1, tegra186-p2771-,
tegra194-p2972-, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

USB on EBV Socrates

[Pavel Machek]

Hi!

(First, I'd like to thank Detlev for fpgasoc-quickstart, it made
getting Socrates to run way easier. I used some older version... so I
had to delete your public key from it. If there's more than one, I'd
like to know :-) ).

Now, I'd like to get USB host to work; I don't have cable with right
pullups, so host-only would be nice, but I noticed USB is not enabled
at all in arch/arm/boot/dts/socfpga_cyclone5_socrates.dts . I tried
enabling it but could not get it to work. Perhaps someone knows what
is going on there?

Thanks,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

Re: [PATCH v4 00/11] add thermal driver for h6

[Vasily Khoruzhick]

On Wed, Jul 10, 2019 at 4:09 PM Vasily Khoruzhick  wrote:
>
> On Sun, Jun 23, 2019 at 9:42 AM Yangtao Li  wrote:
> >
> > This patchset add support for H3 and H6 thermal sensor.
> >
> > BTY, do a cleanup in thermal makfile.
> >
> > Yangtao Li (11):
> >   thermal: sun8i: add thermal driver for h6
> >   dt-bindings: thermal: add binding document for h6 thermal controller
> >   thermal: fix indentation in makefile
> >   thermal: sun8i: get ths sensor number from device compatible
> >   thermal: sun8i: rework for sun8i_ths_get_temp()
> >   thermal: sun8i: get ths init func from device compatible
> >   thermal: sun8i: rework for ths irq handler func
> >   thermal: sun8i: support ahb clocks
> >   thermal: sun8i: rework for ths calibrate func
> >   dt-bindings: thermal: add binding document for h3 thermal controller
> >   thermal: sun8i: add thermal driver for h3
>
> It would be nice to add dts changes to this series. It's unlikely that
> you'll get any "Tested-by" otherwise.

I added A64 support on top of this series, see
https://github.com/anarsoul/linux-2.6/tree/v5.2-thermal

Branch also contains patches to enable DVFS on A64, feel free to
cherry pick only those related to thermal driver if you want to
include A64 support into v5 series.

>
> >  .../bindings/thermal/sun8i-thermal.yaml   |  94 +++
> >  MAINTAINERS   |   7 +
> >  drivers/thermal/Kconfig   |  14 +
> >  drivers/thermal/Makefile  |   9 +-
> >  drivers/thermal/sun8i_thermal.c   | 534 ++
> >  5 files changed, 654 insertions(+), 4 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> >  create mode 100644 drivers/thermal/sun8i_thermal.c
> >
> > ---
> > v4:
> > -add h3 support
> > -fix yaml file
> > ---
> > 2.17.1
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [alsa-devel] [PATCH] sound: pci: emu10k1: Remove unneeded variable "change"

[Takashi Iwai]

On Fri, 12 Jul 2019 10:06:23 +0200,
 Wasko, Michal  wrote:
> 
> 
> On 7/11/2019 7:17 PM, Hariprasad Kelam wrote:
> 
> fix below issue reported by coccicheck
> sound/pci/emu10k1/emu10k1x.c:1077:5-11: Unneeded variable: "change".
> Return "0" on line 1092
> 
> Signed-off-by: Hariprasad Kelam 
> 
> Since the  function always return 0 and you perform code clean-up then
> maybe it would be a good idea to just change function to void instead
> of returning int value which does not seem to have use.

No, it's a callback function.


Takashi

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

[Paul E. McKenney]

On Sat, Jul 13, 2019 at 11:42:57AM -0400, Joel Fernandes wrote:
> On Sat, Jul 13, 2019 at 08:13:30AM -0700, Paul E. McKenney wrote:
> > On Sat, Jul 13, 2019 at 10:20:02AM -0400, Joel Fernandes wrote:
> > > On Sat, Jul 13, 2019 at 4:47 AM Byungchul Park
> > >  wrote:
> > > >
> > > > On Fri, Jul 12, 2019 at 9:51 PM Joel Fernandes  
> > > > wrote:
> > > > >
> > > > > On Fri, Jul 12, 2019 at 03:32:40PM +0900, Byungchul Park wrote:
> > > > > > On Thu, Jul 11, 2019 at 03:58:39PM -0400, Joel Fernandes wrote:
> > > > > > > Hmm, speaking of grace period durations, it seems to me the 
> > > > > > > maximum grace
> > > > > > > period ever is recorded in rcu_state.gp_max. However it is not 
> > > > > > > read from
> > > > > > > anywhere.
> > > > > > >
> > > > > > > Any idea why it was added but not used?
> > > > > > >
> > > > > > > I am interested in dumping this value just for fun, and seeing 
> > > > > > > what I get.
> > > > > > >
> > > > > > > I wonder also it is useful to dump it in rcutorture/rcuperf to 
> > > > > > > find any
> > > > > > > issues, or even expose it in sys/proc fs to see what worst case 
> > > > > > > grace periods
> > > > > > > look like.
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > >   commit ae91aa0adb14dc33114d566feca2f7cb7a96b8b7
> > > > > >   rcu: Remove debugfs tracing
> > > > > >
> > > > > > removed all debugfs tracing, gp_max also included.
> > > > > >
> > > > > > And you sounds great. And even looks not that hard to add it like,
> > > > > >
> > > > > > :)
> > > > > >
> > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > > index ad9dc86..86095ff 100644
> > > > > > --- a/kernel/rcu/tree.c
> > > > > > +++ b/kernel/rcu/tree.c
> > > > > > @@ -1658,8 +1658,10 @@ static void rcu_gp_cleanup(void)
> > > > > >   raw_spin_lock_irq_rcu_node(rnp);
> > > > > >   rcu_state.gp_end = jiffies;
> > > > > >   gp_duration = rcu_state.gp_end - rcu_state.gp_start;
> > > > > > - if (gp_duration > rcu_state.gp_max)
> > > > > > + if (gp_duration > rcu_state.gp_max) {
> > > > > >   rcu_state.gp_max = gp_duration;
> > > > > > + trace_rcu_grace_period(something something);
> > > > > > + }
> > > > >
> > > > > Yes, that makes sense. But I think it is much better off as a 
> > > > > readable value
> > > > > from a virtual fs. The drawback of tracing for this sort of thing are:
> > > > >  - Tracing will only catch it if tracing is on
> > > > >  - Tracing data can be lost if too many events, then no one has a 
> > > > > clue what
> > > > >the max gp time is.
> > > > >  - The data is already available in rcu_state::gp_max so copying it 
> > > > > into the
> > > > >trace buffer seems a bit pointless IMHO
> > > > >  - It is a lot easier on ones eyes to process a single counter than 
> > > > > process
> > > > >heaps of traces.
> > > > >
> > > > > I think a minimal set of RCU counters exposed to /proc or /sys should 
> > > > > not
> > > > > hurt and could do more good than not. The scheduler already does this 
> > > > > for
> > > > > scheduler statistics. I have seen Peter complain a lot about new 
> > > > > tracepoints
> > > > > but not much (or never) about new statistics.
> > > > >
> > > > > Tracing has its strengths but may not apply well here IMO. I think a 
> > > > > counter
> > > > > like this could be useful for tuning of things like the 
> > > > > jiffies_*_sched_qs,
> > > > > the stall timeouts and also any other RCU knobs. What do you think?
> > > >
> > > > I prefer proc/sys knob for it to tracepoint. Why I've considered it is 
> > > > just it
> > > > looks like undoing what Paul did at ae91aa0ad.
> > > >
> > > > I think you're rational enough. I just wondered how Paul think of it.
> > > 
> > > I believe at least initially, a set of statistics can be made
> > > available only when rcutorture or rcuperf module is loaded. That way
> > > they are purely only for debugging and nothing needs to be exposed to
> > > normal kernels distributed thus reducing testability concerns.
> > > 
> > > rcu_state::gp_max would be trivial to expose through this, but for
> > > other statistics that are more complicated - perhaps
> > > tracepoint_probe_register can be used to add hooks on to the
> > > tracepoints and generate statistics from them. Again the registration
> > > of the probe and the probe handler itself would all be in
> > > rcutorture/rcuperf test code and not a part of the kernel proper.
> > > Thoughts?
> > 
> > It still feels like you guys are hyperfocusing on this one particular
> > knob.  I instead need you to look at the interrelating knobs as a group.
> 
> Thanks for the hints, we'll do that.
> 
> > On the debugging side, suppose someone gives you an RCU bug report.
> > What information will you need?  How can you best get that information
> > without excessive numbers of over-and-back interactions with the guy
> > reporting the bug?  As part of this last question, what information is
> > normally supplied with the bug?  

Re: [RFC PATCH v4 1/3] selftests/x86/sgx: Fix Makefile for SGX selftest

[Xing, Cedric]

On 7/13/2019 8:15 AM, Jarkko Sakkinen wrote:

On Sat, 2019-07-13 at 18:10 +0300, Jarkko Sakkinen wrote:

On Fri, 2019-07-12 at 23:51 -0700, Cedric Xing wrote:

The original x86/sgx/Makefile didn't work when "x86/sgx" was specified as the
test target, nor did it work with "run_tests" as the make target. Yet another
problem was that it breaks 32-bit only build. This patch fixes those problems,
along with adjustments to compiler/linker options and simplifications to the
build rules.

Signed-off-by: Cedric Xing 


You must split this in quite a few separate patches:

1. One for each fix.
2. At least one patch for each change in compiler and linker options with a
commit message clearly expalaining why the change was made.
3. One for each simplification.

We don't support 32-bit build:

config INTEL_SGX
bool "Intel SGX core functionality"
depends on X86_64 && CPU_SUP_INTEL


This is not to say that changes suck. This just in "unreviewable" state as far
as the kernel processes go...


Please note that your patchset hasn't been upstreamed yet. Your Makefile 
is problematic to begin with. Technically it's your job to make it work 
before sending out any patches. You didn't explain what's done for each 
line of Makefile in your commit message either.


Not saying documentation is unimportant, but the purposes for those 
changes are obvious and easy to understand for anyone having reasonable 
knowledge on how Makefile works.


I'm totally fine not fixing the Makefile. You can just leave them out.


/Jarkko

[PATCH v21 27/28] docs: x86/sgx: Document kernel internals

[Jarkko Sakkinen]

From: Sean Christopherson 

Document some of the more tricky parts of the kernel implementation
internals.

Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 Documentation/x86/sgx/2.Kernel-internals.rst | 76 
 Documentation/x86/sgx/index.rst  |  1 +
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/x86/sgx/2.Kernel-internals.rst

diff --git a/Documentation/x86/sgx/2.Kernel-internals.rst 
b/Documentation/x86/sgx/2.Kernel-internals.rst
new file mode 100644
index ..5c90a65936f2
--- /dev/null
+++ b/Documentation/x86/sgx/2.Kernel-internals.rst
@@ -0,0 +1,76 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Kernel Internals
+
+
+CPU configuration
+=
+
+Because SGX has an ever evolving and expanding feature set, it's possible for
+a BIOS or VMM to configure a system in such a way that not all CPUs are equal,
+e.g. where Launch Control is only enabled on a subset of CPUs.  Linux does
+*not* support such a heterogeneous system configuration, nor does it even
+attempt to play nice in the face of a misconfigured system.  With the exception
+of Launch Control's hash MSRs, which can vary per CPU, Linux assumes that all
+CPUs have a configuration that is identical to the boot CPU.
+
+EPC management
+==
+
+Because the kernel can't arbitrarily read EPC memory or share RO backing pages
+between enclaves, traditional memory models such as CoW and fork() do not work
+with enclaves.  In other words, the architectural rules of EPC forces it to be
+treated as MAP_SHARED at all times.
+
+The inability to employ traditional memory models also means that EPC memory
+must be isolated from normal memory pools, e.g. attempting to use EPC memory
+for normal mappings would result in faults and/or perceived data corruption.
+Furthermore, EPC is not enumerated by as normal memory, e.g. BIOS enumerates
+EPC as reserved memory in the e820 tables, or not at all.  As a result, EPC
+memory is directly managed by the SGX subsystem, e.g. SGX employs VM_PFNMAP to
+manually insert/zap/swap page table entries, and exposes EPC to userspace via
+a well known device, /dev/sgx/enclave.
+
+The net effect is that all enclave VMAs must be MAP_SHARED and are backed by
+a single file, /dev/sgx/enclave.
+
+EPC oversubscription
+
+
+SGX allows to have larger enclaves than amount of available EPC by providing a
+subset of leaf instruction for swapping EPC pages to the system memory.  The
+details of these instructions are discussed in the architecture document. Due
+to the unique requirements for swapping EPC pages, and because EPC pages do not
+have associated page structures, management of the EPC is not handled by the
+standard memory subsystem.
+
+SGX directly handles swapping of EPC pages, including a thread to initiate the
+reclaiming process and a rudimentary LRU mechanism. When the amount of free EPC
+pages goes below a low watermark the swapping thread starts reclaiming pages.
+The pages that have not been recently accessed (i.e. do not have the A bit set)
+are selected as victim pages. Each enclave holds an shmem file as a backing
+storage for reclaimed pages.
+
+Launch Control
+==
+
+The current kernel implementation supports only writable MSRs. The launch is
+performed by setting the MSRs to the hash of the public key modulus of the
+enclave signer and a token with the valid bit set to zero. Because kernel makes
+ultimately all the launch decisions token are not needed for anything.  We
+don't need or have a launch enclave for generating them as the MSRs must always
+be writable.
+
+Provisioning
+
+
+The use of provisioning must be controlled because it allows to get access to
+the provisioning keys to attest to a remote party that the software is running
+inside a legit enclave. This could be used by a malware network to ensure that
+its nodes are running inside legit enclaves.
+
+The driver introduces a special device file /dev/sgx/provision and a special
+ioctl SGX_IOC_ENCLAVE_SET_ATTRIBUTE to accomplish this. A file descriptor
+pointing to /dev/sgx/provision is passed to ioctl from which kernel authorizes
+the PROVISION_KEY attribute to the enclave.
diff --git a/Documentation/x86/sgx/index.rst b/Documentation/x86/sgx/index.rst
index c5dfef62e612..5d660e83d984 100644
--- a/Documentation/x86/sgx/index.rst
+++ b/Documentation/x86/sgx/index.rst
@@ -14,3 +14,4 @@ potentially malicious.
:maxdepth: 1
 
1.Architecture
+   2.Kernel-internals
-- 
2.20.1

[PATCH v21 28/28] docs: x86/sgx: Document the enclave API

[Jarkko Sakkinen]

Document the enclave driver API i.e. the set of ioctl's used to create
and manage enclaves and set their privileges

Signed-off-by: Jarkko Sakkinen 
---
 Documentation/x86/sgx/3.API.rst | 27 +++
 Documentation/x86/sgx/index.rst |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 Documentation/x86/sgx/3.API.rst

diff --git a/Documentation/x86/sgx/3.API.rst b/Documentation/x86/sgx/3.API.rst
new file mode 100644
index ..b113aeb05f54
--- /dev/null
+++ b/Documentation/x86/sgx/3.API.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+API
+===
+
+The enclave life-cycle starts by opening `/dev/sgx/enclave`. After this there 
is
+already a data structure inside kernel tracking the enclave that is initially
+uncreated. After this a set of ioctl's can be used to create, populate and
+initialize the enclave.
+
+You can close (if you want) the fd after you've mmap()'d. As long as the file 
is
+open the enclave stays alive so you might want to do that after you don't need
+it anymore. Even munmap() won't destruct the enclave if the file is open.
+Neither will closing the fd as long as you have mmap() done over the fd (even
+if it does not across the range defined in SECS).
+
+Finally, there is ioctl to authorize priviliged attributes:
+`SGX_IOC_ENCLAVE_SET_ATTRIBUTE`. Each of them is presented by a file inside
+`/dev/sgx/`. Right now there is only one such file `/dev/sgx/provision`, which
+controls the `PROVISON_KEY` attribute.
+
+.. kernel-doc:: arch/x86/kernel/cpu/sgx/driver/ioctl.c
+   :functions: sgx_ioc_enclave_create
+   sgx_ioc_enclave_add_page
+   sgx_ioc_enclave_init
+   sgx_ioc_enclave_set_attribute
diff --git a/Documentation/x86/sgx/index.rst b/Documentation/x86/sgx/index.rst
index 5d660e83d984..de0b78328611 100644
--- a/Documentation/x86/sgx/index.rst
+++ b/Documentation/x86/sgx/index.rst
@@ -15,3 +15,4 @@ potentially malicious.
 
1.Architecture
2.Kernel-internals
+   3.API
-- 
2.20.1

[PATCH v21 26/28] docs: x86/sgx: Add Architecture documentation

[Jarkko Sakkinen]

From: Sean Christopherson 

Document microarchitectural features of SGX relevant to the kernel.
They are documented in detail enough to understand the implementation.

Signed-off-by: Sean Christopherson 
---
 Documentation/x86/index.rst  |   1 +
 Documentation/x86/sgx/1.Architecture.rst | 431 +++
 Documentation/x86/sgx/index.rst  |  16 +
 3 files changed, 448 insertions(+)
 create mode 100644 Documentation/x86/sgx/1.Architecture.rst
 create mode 100644 Documentation/x86/sgx/index.rst

diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index f2de1b2d3ac7..dadcd3691e06 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -28,3 +28,4 @@ x86-specific Documentation
usb-legacy-support
i386/index
x86_64/index
+   sgx/index
diff --git a/Documentation/x86/sgx/1.Architecture.rst 
b/Documentation/x86/sgx/1.Architecture.rst
new file mode 100644
index ..a4de6c610231
--- /dev/null
+++ b/Documentation/x86/sgx/1.Architecture.rst
@@ -0,0 +1,431 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Architecture
+
+
+Introduction
+
+
+SGX is a set of instructions and mechanisms that enable ring 3 applications to
+set aside private regions of code and data for the purpose of establishing and
+running enclaves.  An enclave is a secure entity whose private memory can only
+be accessed by code running within the enclave.  Accesses from outside the
+enclave, including software running at a higher privilege level and other
+enclaves, are disallowed by hardware.
+
+SGX also provides for local and remote attestation.  `Attestation`_ allows an
+enclave to attest its identity, that it has not been tampered with, that it is
+running on a genuine platform with Intel SGX enabled, and the security
+properties of the platform on which it is running.
+
+You can determine if your CPU supports SGX by querying ``/proc/cpuinfo``:
+
+   ``cat /proc/cpuinfo | grep sgx``
+
+
+Enclave Page Cache
+==
+
+SGX utilizes an Enclave Page Cache (EPC) to store pages that are associated
+with an enclave.  The EPC is secure storage whose exact physical implementation
+is micro-architecture specific (see `EPC Implemenations`_).  Similar to normal
+system memory, the EPC is managed by privileged software using conventional
+paging mechanisms, e.g. the kernel can grant/deny access to EPC memory by
+manipulating a process' page tables, and can swap pages in/out of the EPC in
+order to oversubscribe the EPC.
+
+Unlikely regular memory, hardware prevents arbitrary insertion, eviction,
+deletion, access, etc... to/from the EPC.  Software must instead use dedicated
+`SGX instructions`_ to operate on the EPC, which enables the processor to
+provide SGX's security guarantees by enforcing various restrictions and
+behaviors, e.g. limits concurrent accesses to EPC pages and ensures proper TLB
+flushing when moving pages in/out of the EPC.
+
+Accesses to EPC pages are allowed if and only if the access is classified as an
+"enclave access".  There are two categories of allowed enclave accesses: direct
+and indirect.  Direct enclave accesses are generated if and only the processor
+is executing in Enclave Mode (see `Enclave execution`_).  Indirect enclave
+accesses are generated by various ENCL{S,U,V} functions, many of which can be
+executed outside of Enclave Mode.
+
+Non-enclave accesses to the EPC result in undefined behavior.  Conversely,
+enclave accesses to non-EPC memory result in a page fault (#PF)[1]_.  Page
+faults due to invalid enclave accesses set the PF_SGX flag (bit 15) in the page
+fault error code[2]_.
+
+Although all EPC implementations will undoubtedly encrypt the EPC itself, all
+all EPC code/data is stored unencrypted in the processor's caches.  I.e. SGX
+relies on the aforementioned mechanisms to protect an enclave's secrets while
+they are resident in the cache.
+
+Note, EPC pages are always 4KB sized and aligned.  Software can map EPC using
+using large pages, but the processor always operates on a 4KB granularity when
+working with EPC pages.
+
+
+SGX instructions
+
+
+SGX introduces three new instructions, ENCLS, ENCLU and ENCLV, for Supervisor,
+User and Virtualization respectively.  ENCL{S,U,V} are umbrella instructions,
+using a single opcode as the front end to a variety of SGX functions.  The leaf
+function to execute is specified via %eax, with %rbx, %rcx and %rdx optionally
+used for leaf-specific purposes.
+
+Note that supervisor software, i.e. the kernel, creates and manages enclaves,
+but only user-level software can execute/enter an enclave.
+
+ENCLS Leafs
+---
+
+ - ECREATE: create an enclave
+ - EADD: add page to an uninitialized enclave
+ - EAUG: add page to an initialized enclave
+ - EEXTEND: extended the measurement of an (uninitialized) enclave
+ - EINIT: verify and initialize enclave
+ - EDBG{RD,WR}: read/write from/to a debug enclave???s memory
+ - 

[PATCH v21 25/28] x86/sgx: Update MAINTAINERS

[Jarkko Sakkinen]

Add the maintainer information for the SGX subsystem.

Signed-off-by: Jarkko Sakkinen 
---
 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 133ec3cc11ae..96f779dd22a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8296,6 +8296,18 @@ L:   linux-g...@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-intel-mid.c
 
+INTEL SGX
+M: Jarkko Sakkinen 
+M: Sean Christopherson 
+L: linux-...@vger.kernel.org
+S: Maintained
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git https://github.com/jsakkine-intel/linux-sgx.git
+F: arch/x86/include/asm/sgx.h
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+K: \bSGX_
+
 INTERCONNECT API
 M: Georgi Djakov 
 L: linux...@vger.kernel.org
-- 
2.20.1

[PATCH v21 24/28] selftests/x86: Add a selftest for SGX

[Jarkko Sakkinen]

Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations given to
the enclave as arguments.

Signed-off-by: Jarkko Sakkinen 
---
 tools/testing/selftests/x86/Makefile  |  10 +
 tools/testing/selftests/x86/sgx/Makefile  |  48 ++
 tools/testing/selftests/x86/sgx/defines.h |  39 ++
 tools/testing/selftests/x86/sgx/encl.c|  20 +
 tools/testing/selftests/x86/sgx/encl.lds  |  33 ++
 .../selftests/x86/sgx/encl_bootstrap.S|  94 
 tools/testing/selftests/x86/sgx/encl_piggy.S  |  18 +
 tools/testing/selftests/x86/sgx/encl_piggy.h  |  14 +
 tools/testing/selftests/x86/sgx/main.c| 301 +++
 tools/testing/selftests/x86/sgx/sgx_call.S|  49 ++
 tools/testing/selftests/x86/sgx/sgxsign.c | 508 ++
 .../testing/selftests/x86/sgx/signing_key.pem |  39 ++
 12 files changed, 1173 insertions(+)
 create mode 100644 tools/testing/selftests/x86/sgx/Makefile
 create mode 100644 tools/testing/selftests/x86/sgx/defines.h
 create mode 100644 tools/testing/selftests/x86/sgx/encl.c
 create mode 100644 tools/testing/selftests/x86/sgx/encl.lds
 create mode 100644 tools/testing/selftests/x86/sgx/encl_bootstrap.S
 create mode 100644 tools/testing/selftests/x86/sgx/encl_piggy.S
 create mode 100644 tools/testing/selftests/x86/sgx/encl_piggy.h
 create mode 100644 tools/testing/selftests/x86/sgx/main.c
 create mode 100644 tools/testing/selftests/x86/sgx/sgx_call.S
 create mode 100644 tools/testing/selftests/x86/sgx/sgxsign.c
 create mode 100644 tools/testing/selftests/x86/sgx/signing_key.pem

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index fa07d526fe39..a1831406fd01 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -1,4 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
+
+SUBDIRS_64 := sgx
+
 all:
 
 include ../lib.mk
@@ -68,6 +71,13 @@ all_32: $(BINARIES_32)
 
 all_64: $(BINARIES_64)
 
+all_64: $(SUBDIRS_64)
+   @for DIR in $(SUBDIRS_64); do   \
+   BUILD_TARGET=$(OUTPUT)/$$DIR;   \
+   mkdir $$BUILD_TARGET  -p;   \
+   make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
+   done
+
 EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64)
 
 $(BINARIES_32): $(OUTPUT)/%_32: %.c
diff --git a/tools/testing/selftests/x86/sgx/Makefile 
b/tools/testing/selftests/x86/sgx/Makefile
new file mode 100644
index ..10136b73096b
--- /dev/null
+++ b/tools/testing/selftests/x86/sgx/Makefile
@@ -0,0 +1,48 @@
+top_srcdir = ../../../../..
+
+include ../../lib.mk
+
+HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -z noexecstack
+ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \
+  -fno-stack-protector -mrdrnd $(INCLUDES)
+
+TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx
+all_64: $(TEST_CUSTOM_PROGS)
+
+$(TEST_CUSTOM_PROGS): $(OUTPUT)/main.o $(OUTPUT)/sgx_call.o \
+ $(OUTPUT)/encl_piggy.o
+   $(CC) $(HOST_CFLAGS) -o $@ $^
+
+$(OUTPUT)/main.o: main.c
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/sgx_call.o: sgx_call.S
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/encl_piggy.o: $(OUTPUT)/encl.bin $(OUTPUT)/encl.ss
+   $(CC) $(HOST_CFLAGS) -c encl_piggy.S -o $@
+
+$(OUTPUT)/encl.bin: $(OUTPUT)/encl.elf $(OUTPUT)/sgxsign
+   objcopy --remove-section=.got.plt -O binary $< $@
+
+$(OUTPUT)/encl.elf: $(OUTPUT)/encl.o $(OUTPUT)/encl_bootstrap.o
+   $(CC) $(ENCL_CFLAGS) -T encl.lds -o $@ $^
+
+$(OUTPUT)/encl.o: encl.c
+   $(CC) $(ENCL_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/encl_bootstrap.o: encl_bootstrap.S
+   $(CC) $(ENCL_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/encl.ss: $(OUTPUT)/encl.bin  $(OUTPUT)/sgxsign
+   $(OUTPUT)/sgxsign signing_key.pem $(OUTPUT)/encl.bin $(OUTPUT)/encl.ss
+
+$(OUTPUT)/sgxsign: sgxsign.c
+   $(CC) -o $@ $< -lcrypto
+
+EXTRA_CLEAN := $(OUTPUT)/sgx-selftest $(OUTPUT)/sgx-selftest.o \
+  $(OUTPUT)/sgx_call.o $(OUTPUT)/encl.bin $(OUTPUT)/encl.ss \
+  $(OUTPUT)/encl.elf $(OUTPUT)/encl.o $(OUTPUT)/encl_bootstrap.o \
+  $(OUTPUT)/sgxsign
+
+.PHONY: clean
diff --git a/tools/testing/selftests/x86/sgx/defines.h 
b/tools/testing/selftests/x86/sgx/defines.h
new file mode 100644
index ..3ff73a9d9b93
--- /dev/null
+++ b/tools/testing/selftests/x86/sgx/defines.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+
+#ifndef TYPES_H
+#define TYPES_H
+
+#include 
+
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+
+#define __aligned(x) __attribute__((__aligned__(x)))
+#define __packed __attribute__((packed))
+
+/* Derived from asm-generic/bitsperlong.h. */
+#if __x86_64__
+#define BITS_PER_LONG 64
+#else
+#define BITS_PER_LONG 32
+#endif
+#define BITS_PER_LONG_LONG 64
+
+/* Taken from linux/bits.h. */
+#define BIT(nr)(1UL << 

[PATCH v21 22/28] x86/traps: Attempt to fixup exceptions in vDSO before signaling

[Jarkko Sakkinen]

From: Sean Christopherson 

vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup.  For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal.  This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.

Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information.  Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.

Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal.  Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.

Suggested-by: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Jarkko Sakkinen 
Cc: Dave Hansen 
Cc: Josh Triplett 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kernel/traps.c | 14 ++
 arch/x86/mm/fault.c |  7 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 87095a477154..2d5e06278f6e 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -210,6 +211,9 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, 
const char *str,
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = trapnr;
die(str, regs, error_code);
+   } else {
+   if (fixup_vdso_exception(regs, trapnr, error_code, 0))
+   return 0;
}
 
/*
@@ -561,6 +565,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
return;
}
 
+   if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
+   return;
+
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = X86_TRAP_GP;
 
@@ -775,6 +782,10 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
SIGTRAP) == NOTIFY_STOP)
goto exit;
 
+   if (user_mode(regs) &&
+   fixup_vdso_exception(regs, X86_TRAP_DB, error_code, 0))
+   goto exit;
+
/*
 * Let others (NMI) know that the debug stack is in use
 * as we may switch to the interrupt stack.
@@ -855,6 +866,9 @@ static void math_error(struct pt_regs *regs, int 
error_code, int trapnr)
if (!si_code)
return;
 
+   if (fixup_vdso_exception(regs, trapnr, error_code, 0))
+   return;
+
force_sig_fault(SIGFPE, si_code,
(void __user *)uprobe_get_trap_addr(regs));
 }
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 140f1196f819..fa874656fd14 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -29,6 +29,7 @@
 #include/* efi_recover_from_page_fault()*/
 #include   /* store_idt(), ... */
 #include /* exception stack  
*/
+#include   /* fixup_vdso_exception()   */
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -921,6 +922,9 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long 
error_code,
 
sanitize_error_code(address, _code);
 
+   if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code, 
address))
+   return;
+
if (likely(show_unhandled_signals))
show_signal_msg(regs, error_code, address, tsk);
 
@@ -1038,6 +1042,9 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, 
unsigned long address,
 
sanitize_error_code(address, _code);
 
+   if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code, address))
+   return;
+
set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.20.1

[PATCH v21 23/28] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

[Jarkko Sakkinen]

From: Sean Christopherson 

Intel Software Guard Extensions (SGX) introduces a new CPL3-only enclave
mode that runs as a sort of black box shared object that is hosted by an
untrusted normal CPL3 process.

Skipping over a great deal of gory architecture details[1], SGX was
designed in such a way that the host process can utilize a library to
build, launch and run an enclave.  This is roughly analogous to how
e.g. libc implementations are used by most applications so that the
application can focus on its business logic.

The big gotcha is that because enclaves can generate *and* handle
exceptions, any SGX library must be prepared to handle nearly any
exception at any time (well, any time a thread is executing in an
enclave).  In Linux, this means the SGX library must register a
signal handler in order to intercept relevant exceptions and forward
them to the enclave (or in some cases, take action on behalf of the
enclave).  Unfortunately, Linux's signal mechanism doesn't mesh well
with libraries, e.g. signal handlers are process wide, are difficult
to chain, etc...  This becomes particularly nasty when using multiple
levels of libraries that register signal handlers, e.g. running an
enclave via cgo inside of the Go runtime.

In comes vDSO to save the day.  Now that vDSO can fixup exceptions,
add a function, __vdso_sgx_enter_enclave(), to wrap enclave transitions
and intercept any exceptions that occur when running the enclave.

__vdso_sgx_enter_enclave() does NOT adhere to the x86-64 ABI and instead
uses a custom calling convention.  The primary motivation is to avoid
issues that arise due to asynchronous enclave exits.  The x86-64 ABI
requires that EFLAGS.DF, MXCSR and FCW be preserved by the callee, and
unfortunately for the vDSO, the aformentioned registers/bits are not
restored after an asynchronous exit, e.g. EFLAGS.DF is in an unknown
state while MXCSR and FCW are reset to their init values.  So the vDSO
cannot simply pass the buck by requiring enclaves to adhere to the
x86-64 ABI.  That leaves three somewhat reasonable options:

  1) Save/restore non-volatile GPRs, MXCSR and FCW, and clear EFLAGS.DF

 + 100% compliant with the x86-64 ABI
 + Callable from any code
 + Minimal documentation required
 - Restoring MXCSR/FCW is likely unnecessary 99% of the time
 - Slow

  2) Save/restore non-volatile GPRs and clear EFLAGS.DF

 + Mostly compliant with the x86-64 ABI
 + Callable from any code that doesn't use SIMD registers
 - Need to document deviations from x86-64 ABI, i.e. MXCSR and FCW

  3) Require the caller to save/restore everything.

 + Fast
 + Userspace can pass all GPRs to the enclave (minus EAX, RBX and RCX)
 - Custom ABI
 - For all intents and purposes must be called from an assembly wrapper

__vdso_sgx_enter_enclave() implements option (3).  The custom ABI is
mostly a documentation issue, and even that is offset by the fact that
being more similar to hardware's ENCLU[EENTER/ERESUME] ABI reduces the
amount of documentation needed for the vDSO, e.g. options (2) and (3)
would need to document which registers are marshalled to/from enclaves.
Requiring an assembly wrapper imparts minimal pain on userspace as SGX
libraries and/or applications need a healthy chunk of assembly, e.g. in
the enclave, regardless of the vDSO's implementation.

Note, the C-like pseudocode describing the assembly routine is wrapped
in a non-existent macro instead of in a comment to trick kernel-doc into
auto-parsing the documentation and function prototype.  This is a double
win as the pseudocode is intended to aid kernel developers, not userland
enclave developers.

[1] Documentation/x86/sgx/1.Architecture.rst

Suggested-by: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Jarkko Sakkinen 
Cc: Dave Hansen 
Cc: Josh Triplett 
Cc: Haitao Huang 
Cc: Jethro Beekman 
Cc: Dr. Greg Wettstein 
Signed-off-by: Sean Christopherson 
Co-developed-by: Cedric Xing 
Signed-off-by: Cedric Xing 
---
 arch/x86/entry/vdso/Makefile |   2 +
 arch/x86/entry/vdso/vdso.lds.S   |   1 +
 arch/x86/entry/vdso/vsgx_enter_enclave.S | 169 +++
 arch/x86/include/uapi/asm/sgx.h  |  18 +++
 4 files changed, 190 insertions(+)
 create mode 100644 arch/x86/entry/vdso/vsgx_enter_enclave.S

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 715106395c71..1ae23e7d54a9 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -24,6 +24,7 @@ VDSO32-$(CONFIG_IA32_EMULATION)   := y
 
 # files to link into the vdso
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
+vobjs-$(VDSO64-y)  += vsgx_enter_enclave.o
 
 # files to link into kernel
 obj-y  += vma.o extable.o
@@ -92,6 +93,7 @@ CFLAGS_REMOVE_vdso-note.o = -pg
 CFLAGS_REMOVE_vclock_gettime.o = -pg
 CFLAGS_REMOVE_vgetcpu.o = -pg
 CFLAGS_REMOVE_vvar.o = -pg
+CFLAGS_REMOVE_vsgx_enter_enclave.o = -pg
 
 #
 # X32 processes use x32 vDSO to 

[PATCH v21 20/28] x86/vdso: Add support for exception fixup in vDSO functions

[Jarkko Sakkinen]

From: Sean Christopherson 

The basic concept and implementation is very similar to the kernel's
exception fixup mechanism.  The key differences are that the kernel
handler is hardcoded and the fixup entry addresses are relative to
the overall table as opposed to individual entries.

Hardcoding the kernel handler avoids the need to figure out how to
get userspace code to point at a kernel function.  Given that the
expected usage is to propagate information to userspace, dumping all
fault information into registers is likely the desired behavior for
the vast majority of yet-to-be-created functions.  Use registers
DI, SI and DX to communicate fault information, which follows Linux's
ABI for register consumption and hopefully avoids conflict with
hardware features that might leverage the fixup capabilities, e.g.
register usage for SGX instructions was at least partially designed
with calling conventions in mind.

Making fixup addresses relative to the overall table allows the table
to be stripped from the final vDSO image (it's a kernel construct)
without complicating the offset logic, e.g. entry-relative addressing
would also need to account for the table's location relative to the
image.

Regarding stripping the table, modify vdso2c to extract the table from
the raw, a.k.a. unstripped, data and dump it as a standalone byte array
in the resulting .c file.  The original base of the table, its length
and a pointer to the byte array are captured in struct vdso_image.
Alternatively, the table could be dumped directly into the struct,
but because the number of entries can vary per image, that would
require either hardcoding a max sized table into the struct definition
or defining the table as a flexible length array.  The flexible length
array approach has zero benefits, e.g. the base/size are still needed,
and prevents reusing the extraction code, while hardcoding the max size
adds ongoing maintenance just to avoid exporting the explicit size.

The immediate use case is for Intel Software Guard Extensions (SGX).
SGX introduces a new CPL3-only "enclave" mode that runs as a sort of
black box shared object that is hosted by an untrusted "normal" CPl3
process.

Entering an enclave can only be done through SGX-specific instructions,
EENTER and ERESUME, and is a non-trivial process.  Because of the
complexity of transitioning to/from an enclave, the vast majority of
enclaves are expected to utilize a library to handle the actual
transitions.  This is roughly analogous to how e.g. libc implementations
are used by most applications.

Another crucial characteristic of SGX enclaves is that they can generate
exceptions as part of their normal (at least as "normal" as SGX can be)
operation that need to be handled *in* the enclave and/or are unique
to SGX.

And because they are essentially fancy shared objects, a process can
host any number of enclaves, each of which can execute multiple threads
simultaneously.

Putting everything together, userspace enclaves will utilize a library
that must be prepared to handle any and (almost) all exceptions any time
at least one thread may be executing in an enclave.  Leveraging signals
to handle the enclave exceptions is unpleasant, to put it mildly, e.g.
the SGX library must constantly (un)register its signal handler based
on whether or not at least one thread is executing in an enclave, and
filter and forward exceptions that aren't related to its enclaves.  This
becomes particularly nasty when using multiple levels of libraries that
register signal handlers, e.g. running an enclave via cgo inside of the
Go runtime.

Enabling exception fixup in vDSO allows the kernel to provide a vDSO
function that wraps the low-level transitions to/from the enclave, i.e.
the EENTER and ERESUME instructions.  The vDSO function can intercept
exceptions that would otherwise generate a signal and return the fault
information directly to its caller, thus avoiding the need to juggle
signal handlers.

Note that unlike the kernel's _ASM_EXTABLE_HANDLE implementation, the
'C' version of _ASM_VDSO_EXTABLE_HANDLE doesn't use a pre-compiled
assembly macro.  Duplicating four lines of code is simpler than adding
the necessary infrastructure to generate pre-compiled assembly and the
intended benefit of massaging GCC's inlining algorithm is unlikely to
realized in the vDSO any time soon, if ever.

Suggested-by: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Jarkko Sakkinen 
Cc: Dave Hansen 
Cc: Josh Triplett 
Signed-off-by: Sean Christopherson 
---
 arch/x86/entry/vdso/Makefile  |  6 +--
 arch/x86/entry/vdso/extable.c | 46 +
 arch/x86/entry/vdso/extable.h | 29 ++
 arch/x86/entry/vdso/vdso-layout.lds.S |  9 -
 arch/x86/entry/vdso/vdso2c.h  | 58 +++
 arch/x86/include/asm/vdso.h   |  5 +++
 6 files changed, 141 insertions(+), 12 deletions(-)
 create mode 100644 arch/x86/entry/vdso/extable.c
 create mode 100644 

[PATCH v21 21/28] x86/fault: Add helper function to sanitize error code

[Jarkko Sakkinen]

From: Sean Christopherson 

...to prepare for vDSO exception fixup, which will expose the error code
to userspace and runs before set_signal_archinfo(), i.e. suppresses the
signal when fixup is successful.

Signed-off-by: Sean Christopherson 
---
 arch/x86/mm/fault.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 117262676e93..140f1196f819 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -701,6 +701,18 @@ pgtable_bad(struct pt_regs *regs, unsigned long error_code,
oops_end(flags, regs, sig);
 }
 
+static void sanitize_error_code(unsigned long address,
+   unsigned long *error_code)
+{
+   /*
+* To avoid leaking information about the kernel page
+* table layout, pretend that user-mode accesses to
+* kernel addresses are always protection faults.
+*/
+   if (address >= TASK_SIZE_MAX)
+   *error_code |= X86_PF_PROT;
+}
+
 static void set_signal_archinfo(unsigned long address,
unsigned long error_code)
 {
@@ -757,6 +769,8 @@ no_context(struct pt_regs *regs, unsigned long error_code,
 * faulting through the emulate_vsyscall() logic.
 */
if (current->thread.sig_on_uaccess_err && signal) {
+   sanitize_error_code(address, _code);
+
set_signal_archinfo(address, error_code);
 
/* XXX: hwpoison faults will set the wrong code. */
@@ -905,13 +919,7 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long 
error_code,
if (is_errata100(regs, address))
return;
 
-   /*
-* To avoid leaking information about the kernel page table
-* layout, pretend that user-mode accesses to kernel addresses
-* are always protection faults.
-*/
-   if (address >= TASK_SIZE_MAX)
-   error_code |= X86_PF_PROT;
+   sanitize_error_code(address, _code);
 
if (likely(show_unhandled_signals))
show_signal_msg(regs, error_code, address, tsk);
@@ -1028,6 +1036,8 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, 
unsigned long address,
if (is_prefetch(regs, error_code, address))
return;
 
+   sanitize_error_code(address, _code);
+
set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.20.1

[PATCH v21 15/28] mm: Introduce vm_ops->may_mprotect()

[Jarkko Sakkinen]

From: Sean Christopherson 

SGX will use ->may_mprotect() to invoke and enforce SGX variations on
the existing file_mprotect() and mmap_file() LSM hooks.

The name may_mprotect() is intended to reflect the hook's purpose as a
way to restrict mprotect() as opposed to a wholesale replacement.

Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave
VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be
MAP_SHARED.  Furthermore, all enclaves need read, write and execute
VMAs.  As a result, applying W^X restrictions on /dev/sgx/enclave using
existing LSM hooks is for all intents and purposes impossible, e.g.
denying either W or X would deny access to *any* enclave.

By hooking mprotect(), SGX can enforce maximal PTE protections that are
checked by LSMs at enclave load time (when the source file is available)
and can also invoke LSM hooks at the time of mapping, e.g. an enclave
specific hook or a modified call to file_mprotect(), e.g. to check
W+X mappings.

Signed-off-by: Sean Christopherson 
---
 include/linux/mm.h |  2 ++
 mm/mprotect.c  | 13 ++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index dd0b5f4e1e45..0099b638836b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -469,6 +469,8 @@ struct vm_operations_struct {
void (*close)(struct vm_area_struct * area);
int (*split)(struct vm_area_struct * area, unsigned long addr);
int (*mremap)(struct vm_area_struct * area);
+   int (*may_mprotect)(struct vm_area_struct *vma, unsigned long start,
+   unsigned long end, unsigned long prot);
vm_fault_t (*fault)(struct vm_fault *vmf);
vm_fault_t (*huge_fault)(struct vm_fault *vmf,
enum page_entry_size pe_size);
diff --git a/mm/mprotect.c b/mm/mprotect.c
index bf38dfbbb4b4..18732543b295 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -547,13 +547,20 @@ static int do_mprotect_pkey(unsigned long start, size_t 
len,
goto out;
}
 
+   tmp = vma->vm_end;
+   if (tmp > end)
+   tmp = end;
+
+   if (vma->vm_ops && vma->vm_ops->may_mprotect) {
+   error = vma->vm_ops->may_mprotect(vma, nstart, tmp, 
prot);
+   if (error)
+   goto out;
+   }
+
error = security_file_mprotect(vma, reqprot, prot);
if (error)
goto out;
 
-   tmp = vma->vm_end;
-   if (tmp > end)
-   tmp = end;
error = mprotect_fixup(vma, , nstart, tmp, newflags);
if (error)
goto out;
-- 
2.20.1

[PATCH v21 19/28] x86/sgx: ptrace() support for the SGX driver

[Jarkko Sakkinen]

Add VMA callbacks for ptrace() that can be used with debug enclaves.
With debug enclaves data can be read and write the memory word at a time
by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.

Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/encl.c | 98 ++
 1 file changed, 98 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 6bde020e8cfa..836c55d4352d 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -329,6 +329,7 @@ int sgx_encl_may_map(struct sgx_encl *encl, unsigned long 
start,
return 0;
 }
 
+
 static int sgx_vma_mprotect(struct vm_area_struct *vma, unsigned long start,
unsigned long end, unsigned long prot)
 {
@@ -336,10 +337,107 @@ static int sgx_vma_mprotect(struct vm_area_struct *vma, 
unsigned long start,
calc_vm_prot_bits(prot, 0));
 }
 
+static int sgx_edbgrd(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+   unsigned long offset;
+   int ret;
+
+   offset = addr & ~PAGE_MASK;
+
+   if ((page->desc & SGX_ENCL_PAGE_TCS) &&
+   offset > offsetof(struct sgx_tcs, gs_limit))
+   return -ECANCELED;
+
+   ret = __edbgrd(sgx_epc_addr(page->epc_page) + offset, data);
+   if (ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int sgx_edbgwr(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+   unsigned long offset;
+   int ret;
+
+   offset = addr & ~PAGE_MASK;
+
+   /* Writing anything else than flags will cause #GP */
+   if ((page->desc & SGX_ENCL_PAGE_TCS) &&
+   offset != offsetof(struct sgx_tcs, flags))
+   return -ECANCELED;
+
+   ret = __edbgwr(sgx_epc_addr(page->epc_page) + offset, data);
+   if (ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int sgx_vma_access(struct vm_area_struct *vma, unsigned long addr,
+ void *buf, int len, int write)
+{
+   struct sgx_encl *encl = vma->vm_private_data;
+   struct sgx_encl_page *entry = NULL;
+   unsigned long align;
+   char data[sizeof(unsigned long)];
+   int offset;
+   int cnt;
+   int ret = 0;
+   int i;
+
+   /* If process was forked, VMA is still there but vm_private_data is set
+* to NULL.
+*/
+   if (!encl)
+   return -EFAULT;
+
+   if (!(encl->flags & SGX_ENCL_DEBUG) ||
+   !(encl->flags & SGX_ENCL_INITIALIZED) ||
+   (encl->flags & SGX_ENCL_DEAD))
+   return -EFAULT;
+
+   for (i = 0; i < len; i += cnt) {
+   entry = sgx_encl_reserve_page(encl, (addr + i) & PAGE_MASK);
+   if (IS_ERR(entry)) {
+   ret = PTR_ERR(entry);
+   break;
+   }
+
+   align = ALIGN_DOWN(addr + i, sizeof(unsigned long));
+   offset = (addr + i) & (sizeof(unsigned long) - 1);
+   cnt = sizeof(unsigned long) - offset;
+   cnt = min(cnt, len - i);
+
+   ret = sgx_edbgrd(encl, entry, align, data);
+   if (ret)
+   goto out;
+
+   if (write) {
+   memcpy(data + offset, buf + i, cnt);
+   ret = sgx_edbgwr(encl, entry, align, data);
+   if (ret)
+   goto out;
+   } else
+   memcpy(buf + i, data + offset, cnt);
+
+out:
+   mutex_unlock(>lock);
+
+   if (ret)
+   break;
+   }
+
+   return ret < 0 ? ret : i;
+}
+
 const struct vm_operations_struct sgx_vm_ops = {
.open = sgx_vma_open,
.fault = sgx_vma_fault,
.may_mprotect = sgx_vma_mprotect,
+   .access = sgx_vma_access,
 };
 
 /**
-- 
2.20.1

[PATCH v21 17/28] x86/sgx: Add provisioning

[Jarkko Sakkinen]

In order to provide a mechanism for devilering provisoning rights:

1. Add a new device file /dev/sgx/provision that works as a token for
   allowing an enclave to have the provisioning privileges.
2. Add a new ioctl called SGX_IOC_ENCLAVE_SET_ATTRIBUTE that accepts the
   following data structure:

   struct sgx_enclave_set_attribute {
   __u64 addr;
   __u64 attribute_fd;
   };

A daemon could sit on top of /dev/sgx/provision and send a file
descriptor of this file to a process that needs to be able to provision
enclaves.

The way this API is used is straight-forward. Lets assume that dev_fd is
a handle to /dev/sgx/enclave and prov_fd is a handle to
/dev/sgx/provision.  You would allow SGX_IOC_ENCLAVE_CREATE to
initialize an enclave with the PROVISIONKEY attribute by

params.addr = ;
params.token_fd = prov_fd;

ioctl(dev_fd, SGX_IOC_ENCLAVE_SET_ATTRIBUTE, );

Cc: James Morris 
Cc: Serge E. Hallyn 
Cc: linux-security-mod...@vger.kernel.org
Suggested-by: Andy Lutomirski 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/uapi/asm/sgx.h | 11 ++
 arch/x86/kernel/cpu/sgx/driver/driver.h |  2 +-
 arch/x86/kernel/cpu/sgx/driver/ioctl.c  | 45 +
 arch/x86/kernel/cpu/sgx/driver/main.c   | 23 -
 4 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index 37d6770a654b..f17d37ca3496 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -16,6 +16,8 @@
_IOW(SGX_MAGIC, 0x01, struct sgx_enclave_add_page)
 #define SGX_IOC_ENCLAVE_INIT \
_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_SET_ATTRIBUTE \
+   _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_set_attribute)
 
 /**
  * struct sgx_enclave_create - parameter structure for the
@@ -52,4 +54,13 @@ struct sgx_enclave_init {
__u64 sigstruct;
 };
 
+/**
+ * struct sgx_enclave_set_attribute - parameter structure for the
+ *   %SGX_IOC_ENCLAVE_SET_ATTRIBUTE ioctl
+ * @attribute_fd:  file handle of the attribute file in the securityfs
+ */
+struct sgx_enclave_set_attribute {
+   __u64 attribute_fd;
+};
+
 #endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/driver/driver.h 
b/arch/x86/kernel/cpu/sgx/driver/driver.h
index 52f41426434b..da60839b133a 100644
--- a/arch/x86/kernel/cpu/sgx/driver/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver/driver.h
@@ -28,7 +28,7 @@ extern u64 sgx_attributes_reserved_mask;
 extern u64 sgx_xfrm_reserved_mask;
 extern u32 sgx_xsave_size_tbl[64];
 
-extern const struct file_operations sgx_fs_provision_fops;
+extern const struct file_operations sgx_provision_fops;
 
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
 
diff --git a/arch/x86/kernel/cpu/sgx/driver/ioctl.c 
b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
index 1cbebcd3f397..958c1dbc02e7 100644
--- a/arch/x86/kernel/cpu/sgx/driver/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
@@ -718,6 +718,49 @@ static long sgx_ioc_enclave_init(struct file *filep, void 
__user *arg)
return ret;
 }
 
+/**
+ * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_SET_ATTRIBUTE
+ * @filep: open file to /dev/sgx
+ * @arg:   userspace pointer to a struct sgx_enclave_set_attribute instance
+ *
+ * Mark the enclave as being allowed to access a restricted attribute bit.
+ * The requested attribute is specified via the attribute_fd field in the
+ * provided struct sgx_enclave_set_attribute.  The attribute_fd must be a
+ * handle to an SGX attribute file, e.g. ???/dev/sgx/provision".
+ *
+ * Failure to explicitly request access to a restricted attribute will cause
+ * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
+ * is access to the PROVISION_KEY.
+ *
+ * Note, access to the EINITTOKEN_KEY is disallowed entirely.
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+static long sgx_ioc_enclave_set_attribute(struct file *filep, void __user *arg)
+{
+   struct sgx_encl *encl = filep->private_data;
+   struct sgx_enclave_set_attribute params;
+   struct file *attribute_file;
+   int ret;
+
+   if (copy_from_user(, arg, sizeof(params)))
+   return -EFAULT;
+
+   attribute_file = fget(params.attribute_fd);
+   if (!attribute_file->f_op)
+   return -EINVAL;
+
+   if (attribute_file->f_op != _provision_fops) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   encl->allowed_attributes |= SGX_ATTR_PROVISIONKEY;
+
+out:
+   fput(attribute_file);
+   return ret;
+}
 
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 {
@@ -728,6 +771,8 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, 
unsigned long arg)
return sgx_ioc_enclave_add_page(filep, (void __user *)arg);
case SGX_IOC_ENCLAVE_INIT:
return 

[PATCH v21 16/28] x86/sgx: Add the Linux SGX Enclave Driver

[Jarkko Sakkinen]

Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
can be used by applications to set aside private regions of code and
data. The code outside the enclave is disallowed to access the memory
inside the enclave by the CPU access control.

This commit adds the Linux SGX Enclave Driver that provides an ioctl API
to manage enclaves. The address range for an enclave, commonly referred
as ELRANGE in the documentation (e.g. Intel SDM), is reserved with
mmap() against /dev/sgx/enclave. After that a set ioctls is used to
build the enclave to the ELRANGE.

Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Co-developed-by: Serge Ayoun 
Signed-off-by: Serge Ayoun 
Co-developed-by: Shay Katz-zamir 
Signed-off-by: Shay Katz-zamir 
Co-developed-by: Suresh Siddha 
Signed-off-by: Suresh Siddha 
---
 Documentation/ioctl/ioctl-number.txt|   1 +
 arch/x86/Kconfig|  16 +
 arch/x86/include/uapi/asm/sgx.h |  55 ++
 arch/x86/kernel/cpu/sgx/Makefile|   3 +-
 arch/x86/kernel/cpu/sgx/driver/Makefile |   3 +
 arch/x86/kernel/cpu/sgx/driver/driver.h |  44 ++
 arch/x86/kernel/cpu/sgx/driver/ioctl.c  | 734 
 arch/x86/kernel/cpu/sgx/driver/main.c   | 264 +
 arch/x86/kernel/cpu/sgx/encl.c  | 362 
 arch/x86/kernel/cpu/sgx/encl.h  | 100 
 arch/x86/kernel/cpu/sgx/main.c  |  25 +-
 arch/x86/kernel/cpu/sgx/reclaim.c   |   2 +-
 arch/x86/kernel/cpu/sgx/sgx.h   |   1 +
 13 files changed, 1598 insertions(+), 12 deletions(-)
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 arch/x86/kernel/cpu/sgx/driver/Makefile
 create mode 100644 arch/x86/kernel/cpu/sgx/driver/driver.h
 create mode 100644 arch/x86/kernel/cpu/sgx/driver/ioctl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/driver/main.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index c9558146ac58..ef2694221cd0 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -312,6 +312,7 @@ Code  Seq#(hex) Include FileComments

 0xA3   90-9F   linux/dtlk.h
 0xA4   00-1F   uapi/linux/tee.hGeneric TEE subsystem
+0xA4   00-02   uapi/asm/sgx.h  conflict!
 0xAA   00-3F   linux/uapi/linux/userfaultfd.h
 0xAB   00-1F   linux/nbd.h
 0xAC   00-1F   linux/raw.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 815328adf561..74ccb1bdea16 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1936,6 +1936,8 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
 config INTEL_SGX
bool "Intel SGX core functionality"
depends on X86_64 && CPU_SUP_INTEL
+   select SRCU
+   select MMU_NOTIFIER
---help---
  Intel(R) SGX is a set of CPU instructions that can be used by
  applications to set aside private regions of code and data, referred
@@ -1945,6 +1947,20 @@ config INTEL_SGX
 
  If unsure, say N.
 
+config INTEL_SGX_DRIVER
+   bool "Intel(R) SGX Driver"
+   depends on X86_64 && CPU_SUP_INTEL && INTEL_SGX
+   select CRYPTO
+   select CRYPTO_SHA256
+   ---help---
+ This options enables the kernel SGX driver that allows to construct
+ enclaves to the process memory by using a device node (by default
+ /dev/sgx) and a set of ioctls. The driver requires that the MSRs
+ specifying the public key hash for the launch enclave are writable so
+ that Linux has the full control to run enclaves.
+
+ If unsure, say N.
+
 config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
new file mode 100644
index ..37d6770a654b
--- /dev/null
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/*
+ * Copyright(c) 2016-18 Intel Corporation.
+ */
+#ifndef _UAPI_ASM_X86_SGX_H
+#define _UAPI_ASM_X86_SGX_H
+
+#include 
+#include 
+
+#define SGX_MAGIC 0xA4
+
+#define SGX_IOC_ENCLAVE_CREATE \
+   _IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
+#define SGX_IOC_ENCLAVE_ADD_PAGE \
+   _IOW(SGX_MAGIC, 0x01, struct sgx_enclave_add_page)
+#define SGX_IOC_ENCLAVE_INIT \
+   _IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+
+/**
+ * struct sgx_enclave_create - parameter structure for the
+ * %SGX_IOC_ENCLAVE_CREATE ioctl
+ * @src:   address for the SECS page data
+ */
+struct sgx_enclave_create  {
+   __u64   src;
+};
+
+/**
+ * struct sgx_enclave_add_page - parameter structure for the
+ *   %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
+ * @addr:  address within the ELRANGE
+ * @src:   address 

[PATCH v21 18/28] x86/sgx: Add swapping code to the core and SGX driver

[Jarkko Sakkinen]

Because the kernel is untrusted, swapping pages in/out of the Enclave
Page Cache (EPC) has specialized requirements:

* The kernel cannot directly access EPC memory, i.e. cannot copy data
  to/from the EPC.
* To evict a page from the EPC, the kernel must "prove" to hardware that
  are no valid TLB entries for said page since a stale TLB entry would
  allow an attacker to bypass SGX access controls.
* When loading a page back into the EPC, hardware must be able to verify
  the integrity and freshness of the data.
* When loading an enclave page, e.g. regular pages and Thread Control
  Structures (TCS), hardware must be able to associate the page with a
  Secure Enclave Control Structure (SECS).

To satisfy the above requirements, the CPU provides dedicated ENCLS
functions to support paging data in/out of the EPC:

* EBLOCK:   Mark a page as blocked in the EPC Map (EPCM).  Attempting
to access a blocked page that misses the TLB will fault.
* ETRACK:   Activate blocking tracking.  Hardware verifies that all
translations for pages marked as "blocked" have been flushed
from the TLB.
* EPA:  Add version array page to the EPC.  As the name suggests, a
VA page is an 512-entry array of version numbers that are
used to uniquely identify pages evicted from the EPC.
* EWB:  Write back a page from EPC to memory, e.g. RAM.  Software
must supply a VA slot, memory to hold the a Paging Crypto
Metadata (PCMD) of the page and obviously backing for the
evicted page.
* ELD{B,U}: Load a page in {un}blocked state from memory to EPC.  The
driver only uses the ELDU variant as there is no use case
for loading a page as "blocked" in a bare metal environment.

To top things off, all of the above ENCLS functions are subject to
strict concurrency rules, e.g. many operations will #GP fault if two
or more operations attempt to access common pages/structures.

To put it succinctly, paging in/out of the EPC requires coordinating
with the SGX driver where all of an enclave's tracking resides.  But,
simply shoving all reclaim logic into the driver is not desirable as
doing so has unwanted long term implications:

* Oversubscribing EPC to KVM guests, i.e. virtualizing SGX in KVM and
  swapping a guest's EPC pages (without the guest's cooperation) needs
  the same high level flows for reclaim but has painfully different
  semantics in the details.
* Accounting EPC, i.e. adding an EPC cgroup controller, is desirable
  as EPC is effectively a specialized memory type and even more scarce
  than system memory.  Providing a single touchpoint for EPC accounting
  regardless of end consumer greatly simplifies the EPC controller.
* Allowing the userspace-facing driver to be built as a loaded module
  is desirable, e.g. for debug, testing and development.  The cgroup
  infrastructure does not support dependencies on loadable modules.
* Separating EPC swapping from the driver once it has been tightly
  coupled to the driver is non-trivial (speaking from experience).

So, although the SGX driver is currently the sole consumer of EPC,
encapsulate EPC swapping in the driver to minimize the dependencies
between the core SGX code and driver, and do so in a way that can be
extended to an abstracted interface with minimal effort.

To that end, add functions to swap EPC pages to the driver.  The user
of these functions will be the core SGX subsystem, which will be enabled
in a future patch.

* sgx_encl_page_{get,put}() - Attempt to pin/unpin (the owner of) an EPC
  page so that it can be operated on by a reclaimer.
* sgx_encl_page_reclaim()   - Mark a page as being reclaimed. The
  page is considered reclaimable if it hasn't been accessed recently and
  it isn't reserved by the driver for other use.
* sgx_encl_page_block() - EBLOCK an EPC page
* sgx_encl_page_write() - Evict an EPC page to the regular memory via
  EWB.  Activates ETRACK (via sgx_encl_track()) if necessary.

Since we also need to be able to fault pages back into the EPC, add a
page fault handler to allocate an EPC page and ELDU a previously evicted
page.

Wire up the EPC manager's reclaim flow to the SGX driver's swapping
functionality.  In the long term there will be multiple users of the
EPC manager, e.g. SGX driver and KVM, thus the interface between the
EPC manager and the driver is fairly genericized and decoupled.  But
to avoid adding unusued infrastructure, do not add any indirection
between the EPC manager and the SGX driver.  This has the unfortunate
and odd side effect of preventing the SGX driver from being compiled
as a loadable module.  However, this should be a temporary situation
that is remedied when a second user of EPC is added, i.e. KVM.

The swapper thread ksgxswapd reclaims pages on the event when the number
of free EPC pages goes below %SGX_NR_LOW_PAGES up until it reaches
%SGX_NR_HIGH_PAGES.

Pages are reclaimed in LRU fashion from a 

[PATCH v21 11/28] x86/sgx: Add wrappers for ENCLS leaf functions

[Jarkko Sakkinen]

ENCLS is an umbrella instruction for a variety of cpl0 SGX functions.
The ENCLS function that is executed is specified in EAX, with each
function potentially having more leaf-specific operands beyond EAX.
ENCLS introduces its own (positive value) error codes that (some)
leafs use to return failure information in EAX.  Leafs that return
an error code also modify RFLAGS.  And finally, ENCLS generates
ENCLS-specific non-fatal #GPs and #PFs, i.e. a bug-free kernel may
encounter faults on ENCLS that must be handled gracefully.

Because of the complexity involved in encoding ENCLS and handling its
assortment of failure paths, executing any given leaf is not a simple
matter of emitting ENCLS.

To enable adding support for ENCLS leafs with minimal fuss, add a
two-layer macro system along with an encoding scheme to allow wrappers
to return trap numbers along ENCLS-specific error codes.  The bottom
layer of the macro system splits between the leafs that return an
error code and those that do not.  The second layer generates the
correct input/output annotations based on the number of operands for
each leaf function.

Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kernel/cpu/sgx/Makefile |   1 +
 arch/x86/kernel/cpu/sgx/encls.c  |  21 +++
 arch/x86/kernel/cpu/sgx/encls.h  | 244 +++
 3 files changed, 266 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/Makefile
 create mode 100644 arch/x86/kernel/cpu/sgx/encls.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encls.h

diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
new file mode 100644
index ..4432d935894e
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -0,0 +1 @@
+obj-y += encls.o
diff --git a/arch/x86/kernel/cpu/sgx/encls.c b/arch/x86/kernel/cpu/sgx/encls.c
new file mode 100644
index ..5045f1365e07
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encls.c
@@ -0,0 +1,21 @@
+#include 
+#include 
+#include "encls.h"
+#include "sgx.h"
+
+/**
+ * encls_failed() - Check if an ENCLS leaf function failed
+ * @ret:   the return value of an ENCLS leaf function call
+ *
+ * Check if an ENCLS leaf function failed. This is a condition where the leaf
+ * function causes a fault that is not caused by an EPCM conflict.
+ *
+ * Return: true if there was a fault other than an EPCM conflict
+ */
+bool encls_failed(int ret)
+{
+   int epcm_trapnr = boot_cpu_has(X86_FEATURE_SGX2) ?
+ X86_TRAP_PF : X86_TRAP_GP;
+
+   return encls_faulted(ret) && ENCLS_TRAPNR(ret) != epcm_trapnr;
+}
diff --git a/arch/x86/kernel/cpu/sgx/encls.h b/arch/x86/kernel/cpu/sgx/encls.h
new file mode 100644
index ..aea3b9d09936
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encls.h
@@ -0,0 +1,244 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+#ifndef _X86_ENCLS_H
+#define _X86_ENCLS_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "arch.h"
+
+/**
+ * ENCLS_FAULT_FLAG - flag signifying an ENCLS return code is a trapnr
+ *
+ * ENCLS has its own (positive value) error codes and also generates
+ * ENCLS specific #GP and #PF faults.  And the ENCLS values get munged
+ * with system error codes as everything percolates back up the stack.
+ * Unfortunately (for us), we need to precisely identify each unique
+ * error code, e.g. the action taken if EWB fails varies based on the
+ * type of fault and on the exact SGX error code, i.e. we can't simply
+ * convert all faults to -EFAULT.
+ *
+ * To make all three error types coexist, we set bit 30 to identify an
+ * ENCLS fault.  Bit 31 (technically bits N:31) is used to differentiate
+ * between positive (faults and SGX error codes) and negative (system
+ * error codes) values.
+ */
+#define ENCLS_FAULT_FLAG 0x4000
+
+/**
+ * Retrieve the encoded trapnr from the specified return code.
+ */
+#define ENCLS_TRAPNR(r) ((r) & ~ENCLS_FAULT_FLAG)
+
+/* Issue a WARN() about an ENCLS leaf. */
+#define ENCLS_WARN(r, name) {  \
+   do {\
+   int _r = (r);   \
+   WARN(_r, "sgx: %s returned %d (0x%x)\n", (name), _r,\
+_r);   \
+   } while (0);\
+}
+
+/**
+ * encls_faulted() - Check if ENCLS leaf function faulted
+ * @ret:   the return value of an ENCLS leaf function call
+ *
+ * Return: true if the fault flag is set
+ */
+static inline bool encls_faulted(int ret)
+{
+   return (ret & ENCLS_FAULT_FLAG) != 0;
+}
+
+/**
+ * encls_returned_code() - Check if an ENCLS leaf function returned a code
+ * @ret:   the return value of an ENCLS leaf function call
+ *
+ * Check if an ENCLS leaf function returned an error or information code.
+ *
+ * 

[PATCH v21 10/28] x86/sgx: Add SGX1 and SGX2 architectural data structures

[Jarkko Sakkinen]

Define the data structures used by various ENCLS functions needed for
Linux to support all SGX1 and SGX2 ENCLS leaf functions.  This is not
an exhaustive representation of all SGX data structures as several are
only consumed by ENCLU (userspace), e.g. REPORT and KEYREQUEST, while
others are only consumed by future features, e.g. RDINFO.

Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kernel/cpu/sgx/arch.h | 424 +
 1 file changed, 424 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/arch.h

diff --git a/arch/x86/kernel/cpu/sgx/arch.h b/arch/x86/kernel/cpu/sgx/arch.h
new file mode 100644
index ..39f731580ea8
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/arch.h
@@ -0,0 +1,424 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+ * Copyright(c) 2016-18 Intel Corporation.
+ *
+ * Contains data structures defined by the SGX architecture.  Data structures
+ * defined by the Linux software stack should not be placed here.
+ */
+#ifndef _ASM_X86_SGX_ARCH_H
+#define _ASM_X86_SGX_ARCH_H
+
+#include 
+
+#define SGX_CPUID  0x12
+#define SGX_CPUID_FIRST_VARIABLE_SUB_LEAF  2
+
+/**
+ * enum sgx_sub_leaf_types - SGX CPUID variable sub-leaf types
+ * %SGX_CPUID_SUB_LEAF_INVALID:Indicates this sub-leaf is 
invalid.
+ * %SGX_CPUID_SUB_LEAF_EPC_SECTION:Sub-leaf enumerates an EPC section.
+ */
+enum sgx_sub_leaf_types {
+   SGX_CPUID_SUB_LEAF_INVALID  = 0x0,
+   SGX_CPUID_SUB_LEAF_EPC_SECTION  = 0x1,
+};
+
+#define SGX_CPUID_SUB_LEAF_TYPE_MASK   GENMASK(3, 0)
+
+/**
+ * enum sgx_encls_leaves - ENCLS leaf functions
+ * %SGX_ECREATE:   Create an enclave.
+ * %SGX_EADD:  Add a page to an uninitialized enclave.
+ * %SGX_EINIT: Initialize an enclave, i.e. launch an enclave.
+ * %SGX_EREMOVE:   Remove a page from an enclave.
+ * %SGX_EDBGRD:Read a word from an enclve (peek).
+ * %SGX_EDBGWR:Write a word to an enclave (poke).
+ * %SGX_EEXTEND:   Measure 256 bytes of an added enclave page.
+ * %SGX_ELDB:  Load a swapped page in blocked state.
+ * %SGX_ELDU:  Load a swapped page in unblocked state.
+ * %SGX_EBLOCK:Change page state to blocked i.e. entering 
hardware
+ * threads cannot access it and create new TLB entries.
+ * %SGX_EPA:   Create a Version Array (VA) page used to store isvsvn
+ * number for a swapped EPC page.
+ * %SGX_EWB:   Swap an enclave page to the regular memory. Checks that
+ * all threads have exited that were in the previous
+ * shoot-down sequence.
+ * %SGX_ETRACK:Start a new shoot down sequence. Used to 
together with
+ * EBLOCK to make sure that a page is safe to swap.
+ * %SGX_EAUG:  Add a page to an initialized enclave.
+ * %SGX_EMODPR:Restrict an EPC page's permissions.
+ * %SGX_EMODT: Modify the page type of an EPC page.
+ */
+enum sgx_encls_leaves {
+   SGX_ECREATE = 0x00,
+   SGX_EADD= 0x01,
+   SGX_EINIT   = 0x02,
+   SGX_EREMOVE = 0x03,
+   SGX_EDGBRD  = 0x04,
+   SGX_EDGBWR  = 0x05,
+   SGX_EEXTEND = 0x06,
+   SGX_ELDB= 0x07,
+   SGX_ELDU= 0x08,
+   SGX_EBLOCK  = 0x09,
+   SGX_EPA = 0x0A,
+   SGX_EWB = 0x0B,
+   SGX_ETRACK  = 0x0C,
+   SGX_EAUG= 0x0D,
+   SGX_EMODPR  = 0x0E,
+   SGX_EMODT   = 0x0F,
+};
+
+#define SGX_MODULUS_SIZE 384
+
+/**
+ * enum sgx_miscselect - additional information to an SSA frame
+ * %SGX_MISC_EXINFO:   Report #PF or #GP to the SSA frame.
+ *
+ * Save State Area (SSA) is a stack inside the enclave used to store processor
+ * state when an exception or interrupt occurs. This enum defines additional
+ * information stored to an SSA frame.
+ */
+enum sgx_miscselect {
+   SGX_MISC_EXINFO = BIT(0),
+};
+
+#define SGX_MISC_RESERVED_MASK GENMASK_ULL(63, 1)
+
+#define SGX_SSA_GPRS_SIZE  182
+#define SGX_SSA_MISC_EXINFO_SIZE   16
+
+/**
+ * enum sgx_attributes - the attributes field in  sgx_secs
+ * %SGX_ATTR_INIT: Enclave can be entered (is initialized).
+ * %SGX_ATTR_DEBUG:Allow ENCLS(EDBGRD) and ENCLS(EDBGWR).
+ * %SGX_ATTR_MODE64BIT:Tell that this a 64-bit enclave.
+ * %SGX_ATTR_PROVISIONKEY:  Allow to use provisioning keys for remote
+ * attestation.
+ * %SGX_ATTR_KSS:  Allow to use key separation and sharing (KSS).
+ * %SGX_ATTR_EINITTOKENKEY:Allow to use token signing key that is used to
+ * sign cryptographic tokens that can be passed to
+ * EINIT as an authorization to run an enclave.
+ */
+enum 

[PATCH v21 14/28] x86/sgx: Add sgx_einit() for initializing enclaves

[Jarkko Sakkinen]

From: Sean Christopherson 

Add a helper function to perform ENCLS(EINIT) with the correct LE
hash MSR values.  ENCLS[EINIT] initializes an enclave, verifying the
enclave's measurement and preparing it for execution, i.e. the enclave
cannot be run until it has been initialized.  The measurement aspect
of EINIT references the MSR_IA32_SGXLEPUBKEYHASH* MSRs, with the CPU
comparing CPU compares the key (technically its hash) used to sign the
enclave[1] with the key hash stored in the MSRs, and will reject EINIT
if the keys do not match.

A per-cpu cache is used to avoid writing the MSRs as writing the MSRs
is extraordinarily expensive, e.g. 300-400 cycles per MSR.  Because
the cache may become stale, force update the MSRs and retry EINIT if
the first EINIT fails due to an "invalid token".  An invalid token
error does not necessarily mean the MSRs need to be updated, but the
cost of an unnecessary write is minimal relative to the cost of EINIT
itself.

[1] For EINIT's purposes, the effective signer of the enclave may be
the enclave's owner, or a separate Launch Enclave that has created
an EINIT token for the target enclave.  When using an EINIT token,
the key used to sign the token must match the MSRs in order for
EINIT to succeed.

Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/main.c | 51 ++
 arch/x86/kernel/cpu/sgx/sgx.h  |  2 ++
 2 files changed, 53 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 6b4727df72ca..d3ed742e90fe 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -17,6 +17,9 @@ EXPORT_SYMBOL_GPL(sgx_epc_sections);
 
 int sgx_nr_epc_sections;
 
+/* A per-cpu cache for the last known values of IA32_SGXLEPUBKEYHASHx MSRs. */
+static DEFINE_PER_CPU(u64 [4], sgx_lepubkeyhash_cache);
+
 static struct sgx_epc_page *sgx_section_get_page(
struct sgx_epc_section *section)
 {
@@ -106,6 +109,54 @@ void sgx_free_page(struct sgx_epc_page *page)
 }
 EXPORT_SYMBOL_GPL(sgx_free_page);
 
+static void sgx_update_lepubkeyhash_msrs(u64 *lepubkeyhash, bool enforce)
+{
+   u64 *cache;
+   int i;
+
+   cache = per_cpu(sgx_lepubkeyhash_cache, smp_processor_id());
+   for (i = 0; i < 4; i++) {
+   if (enforce || (lepubkeyhash[i] != cache[i])) {
+   wrmsrl(MSR_IA32_SGXLEPUBKEYHASH0 + i, lepubkeyhash[i]);
+   cache[i] = lepubkeyhash[i];
+   }
+   }
+}
+
+/**
+ * sgx_einit - initialize an enclave
+ * @sigstruct: a pointer a SIGSTRUCT
+ * @token: a pointer an EINITTOKEN (optional)
+ * @secs:  a pointer a SECS
+ * @lepubkeyhash:  the desired value for IA32_SGXLEPUBKEYHASHx MSRs
+ *
+ * Execute ENCLS[EINIT], writing the IA32_SGXLEPUBKEYHASHx MSRs according
+ * to @lepubkeyhash (if possible and necessary).
+ *
+ * Return:
+ *   0 on success,
+ *   -errno or SGX error on failure
+ */
+int sgx_einit(struct sgx_sigstruct *sigstruct, struct sgx_einittoken *token,
+ struct sgx_epc_page *secs, u64 *lepubkeyhash)
+{
+   int ret;
+
+   if (!boot_cpu_has(X86_FEATURE_SGX_LC))
+   return __einit(sigstruct, token, sgx_epc_addr(secs));
+
+   preempt_disable();
+   sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);
+   ret = __einit(sigstruct, token, sgx_epc_addr(secs));
+   if (ret == SGX_INVALID_EINITTOKEN) {
+   sgx_update_lepubkeyhash_msrs(lepubkeyhash, true);
+   ret = __einit(sigstruct, token, sgx_epc_addr(secs));
+   }
+   preempt_enable();
+   return ret;
+}
+EXPORT_SYMBOL(sgx_einit);
+
 static __init void sgx_free_epc_section(struct sgx_epc_section *section)
 {
struct sgx_epc_page *page;
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index 210510a28ce0..41d4130c33a2 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -67,5 +67,7 @@ int sgx_page_reclaimer_init(void);
 struct sgx_epc_page *sgx_alloc_page(void);
 int __sgx_free_page(struct sgx_epc_page *page);
 void sgx_free_page(struct sgx_epc_page *page);
+int sgx_einit(struct sgx_sigstruct *sigstruct, struct sgx_einittoken *token,
+ struct sgx_epc_page *secs, u64 *lepubkeyhash);
 
 #endif /* _X86_SGX_H */
-- 
2.20.1

[PATCH v21 13/28] x86/sgx: Add functions to allocate and free EPC pages

[Jarkko Sakkinen]

At this time there is no support for reclaiming pages prior to the
owner explicitly freeing the page.  As for freeing pages, because
freeing a page is expected to succeed in the vast majority of cases
and because most call sites will not be equipped to handle failure,
provide a variant for freeing a page that warns on failure, e.g. due
to ENCLS[EREMOVE] failing.

Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kernel/cpu/sgx/main.c | 90 ++
 arch/x86/kernel/cpu/sgx/sgx.h  |  4 ++
 2 files changed, 94 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index e2317f6e4374..6b4727df72ca 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include "arch.h"
+#include "encls.h"
 #include "sgx.h"
 
 struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
@@ -16,6 +17,95 @@ EXPORT_SYMBOL_GPL(sgx_epc_sections);
 
 int sgx_nr_epc_sections;
 
+static struct sgx_epc_page *sgx_section_get_page(
+   struct sgx_epc_section *section)
+{
+   struct sgx_epc_page *page;
+
+   if (!section->free_cnt)
+   return NULL;
+
+   page = list_first_entry(>page_list,
+   struct sgx_epc_page, list);
+   list_del_init(>list);
+   section->free_cnt--;
+   return page;
+}
+
+/**
+ * sgx_alloc_page - Allocate an EPC page
+ *
+ * Try to grab a page from the free EPC page list.
+ *
+ * Return:
+ *   a pointer to a  sgx_epc_page instance,
+ *   -errno on error
+ */
+struct sgx_epc_page *sgx_alloc_page(void)
+{
+   struct sgx_epc_section *section;
+   struct sgx_epc_page *page;
+   int i;
+
+   for (i = 0; i < sgx_nr_epc_sections; i++) {
+   section = _epc_sections[i];
+   spin_lock(>lock);
+   page = sgx_section_get_page(section);
+   spin_unlock(>lock);
+
+   if (page)
+   return page;
+   }
+
+   return ERR_PTR(-ENOMEM);
+}
+EXPORT_SYMBOL_GPL(sgx_alloc_page);
+
+/**
+ * __sgx_free_page - Free an EPC page
+ * @page:  pointer a previously allocated EPC page
+ *
+ * EREMOVE an EPC page and insert it back to the list of free pages.
+ *
+ * Return:
+ *   0 on success
+ *   SGX error code if EREMOVE fails
+ */
+int __sgx_free_page(struct sgx_epc_page *page)
+{
+   struct sgx_epc_section *section = sgx_epc_section(page);
+   int ret;
+
+   ret = __eremove(sgx_epc_addr(page));
+   if (ret)
+   return ret;
+
+   spin_lock(>lock);
+   list_add_tail(>list, >page_list);
+   section->free_cnt++;
+   spin_unlock(>lock);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__sgx_free_page);
+
+/**
+ * sgx_free_page - Free an EPC page and WARN on failure
+ * @page:  pointer to a previously allocated EPC page
+ *
+ * EREMOVE an EPC page and insert it back to the list of free pages, and WARN
+ * if EREMOVE fails.  For use when the call site cannot (or chooses not to)
+ * handle failure, i.e. the page is leaked on failure.
+ */
+void sgx_free_page(struct sgx_epc_page *page)
+{
+   int ret;
+
+   ret = __sgx_free_page(page);
+   WARN(ret > 0, "sgx: EREMOVE returned %d (0x%x)", ret, ret);
+}
+EXPORT_SYMBOL_GPL(sgx_free_page);
+
 static __init void sgx_free_epc_section(struct sgx_epc_section *section)
 {
struct sgx_epc_page *page;
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index 3009ec816339..210510a28ce0 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -64,4 +64,8 @@ extern int sgx_nr_epc_sections;
 
 int sgx_page_reclaimer_init(void);
 
+struct sgx_epc_page *sgx_alloc_page(void);
+int __sgx_free_page(struct sgx_epc_page *page);
+void sgx_free_page(struct sgx_epc_page *page);
+
 #endif /* _X86_SGX_H */
-- 
2.20.1

[PATCH v21 12/28] x86/sgx: Enumerate and track EPC sections

[Jarkko Sakkinen]

From: Sean Christopherson 

Enumerate Enclave Page Cache (EPC) sections via CPUID and add the data
structures necessary to track EPC pages so that they can be allocated,
freed and managed.  As a system may have multiple EPC sections, invoke
CPUID on SGX sub-leafs until an invalid leaf is encountered.

On NUMA systems, a node can have at most one bank. A bank can be at
most part of two nodes.  SGX supports both nodes with a single memory
controller and also sub-cluster nodes with severals memory controllers
on a single die.

For simplicity, support a maximum of eight EPC sections.  Current
client hardware supports only a single section, while upcoming server
hardware will support at most eight sections.  Bounding the number of
sections also allows the section ID to be embedded along with a page's
offset in a single unsigned long, enabling easy retrieval of both the
VA and PA for a given page.

Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Suresh Siddha 
Signed-off-by: Suresh Siddha 
Co-developed-by: Serge Ayoun 
Signed-off-by: Serge Ayoun 
---
 arch/x86/Kconfig  |  12 +++
 arch/x86/kernel/cpu/Makefile  |   1 +
 arch/x86/kernel/cpu/sgx/Makefile  |   2 +-
 arch/x86/kernel/cpu/sgx/main.c| 158 ++
 arch/x86/kernel/cpu/sgx/reclaim.c |  84 
 arch/x86/kernel/cpu/sgx/sgx.h |  67 +
 6 files changed, 323 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/cpu/sgx/main.c
 create mode 100644 arch/x86/kernel/cpu/sgx/reclaim.c
 create mode 100644 arch/x86/kernel/cpu/sgx/sgx.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dce10b18f4bc..815328adf561 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1933,6 +1933,18 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
 
  If unsure, say y.
 
+config INTEL_SGX
+   bool "Intel SGX core functionality"
+   depends on X86_64 && CPU_SUP_INTEL
+   ---help---
+ Intel(R) SGX is a set of CPU instructions that can be used by
+ applications to set aside private regions of code and data, referred
+ to as enclaves. An enclave's private memory can only be accessed by
+ code running within the enclave. Accesses from outside the enclave,
+ including other enclaves, are disallowed by hardware.
+
+ If unsure, say N.
+
 config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index d7a1e5a9331c..97deac5108df 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_X86_MCE) += mce/
 obj-$(CONFIG_MTRR) += mtrr/
 obj-$(CONFIG_MICROCODE)+= microcode/
 obj-$(CONFIG_X86_CPU_RESCTRL)  += resctrl/
+obj-$(CONFIG_INTEL_SGX)+= sgx/
 
 obj-$(CONFIG_X86_LOCAL_APIC)   += perfctr-watchdog.o
 
diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
index 4432d935894e..fa930e292110 100644
--- a/arch/x86/kernel/cpu/sgx/Makefile
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -1 +1 @@
-obj-y += encls.o
+obj-y += encls.o main.o reclaim.o
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
new file mode 100644
index ..e2317f6e4374
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-17 Intel Corporation.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "arch.h"
+#include "sgx.h"
+
+struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
+EXPORT_SYMBOL_GPL(sgx_epc_sections);
+
+int sgx_nr_epc_sections;
+
+static __init void sgx_free_epc_section(struct sgx_epc_section *section)
+{
+   struct sgx_epc_page *page;
+
+   while (!list_empty(>page_list)) {
+   page = list_first_entry(>page_list,
+   struct sgx_epc_page, list);
+   list_del(>list);
+   kfree(page);
+   }
+
+   while (!list_empty(>unsanitized_page_list)) {
+   page = list_first_entry(>unsanitized_page_list,
+   struct sgx_epc_page, list);
+   list_del(>list);
+   kfree(page);
+   }
+
+   memunmap(section->va);
+}
+
+static __init int sgx_init_epc_section(u64 addr, u64 size, unsigned long index,
+  struct sgx_epc_section *section)
+{
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+   struct sgx_epc_page *page;
+   unsigned long i;
+
+   section->va = memremap(addr, size, MEMREMAP_WB);
+   if (!section->va)
+   return -ENOMEM;
+
+   section->pa = addr;
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>page_list);
+   

[PATCH v21 07/28] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX

[Jarkko Sakkinen]

From: Sean Christopherson 

The PF_SGX bit is set if and only if the #PF is detected by the SGX
Enclave Page Cache Map (EPCM).  The EPCM is a hardware-managed table
that enforces accesses to an enclave's EPC pages in addition to the
software-managed kernel page tables, i.e. the effective permissions
for an EPC page are a logical AND of the kernel's page tables and
the corresponding EPCM entry.

The EPCM is consulted only after an access walks the kernel's page
tables, i.e.:

  a. the access was allowed by the kernel
  b. the kernel's tables have become less restrictive than the EPCM
  c. the kernel cannot fixup the cause of the fault

Noteably, (b) implies that either the kernel has botched the EPC
mappings or the EPCM has been invalidated (see below).  Regardless of
why the fault occurred, userspace needs to be alerted so that it can
take appropriate action, e.g. restart the enclave.  This is reinforced
by (c) as the kernel doesn't really have any other reasonable option,
i.e. signalling SIGSEGV is actually the least severe action possible.

Although the primary purpose of the EPCM is to prevent a malicious or
compromised kernel from attacking an enclave, e.g. by modifying the
enclave's page tables, do not WARN on a #PF w/ PF_SGX set.  The SGX
architecture effectively allows the CPU to invalidate all EPCM entries
at will and requires that software be prepared to handle an EPCM fault
at any time.  The architecture defines this behavior because the EPCM
is encrypted with an ephemeral key that isn't exposed to software.  As
such, the EPCM entries cannot be preserved across transitions that
result in a new key being used, e.g. CPU power down as part of an S3
transition or when a VM is live migrated to a new physical system.

Cc: Andy Lutomirski 
Cc: Dave Hansen 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/mm/fault.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 794f364cb882..117262676e93 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1198,6 +1198,19 @@ access_error(unsigned long error_code, struct 
vm_area_struct *vma)
if (error_code & X86_PF_PK)
return 1;
 
+   /*
+* Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
+* access is allowed by the PTE but not the EPCM.  This usually happens
+* when the EPCM is yanked out from under us, e.g. by hardware after a
+* suspend/resume cycle.  In any case, software, i.e. the kernel, can't
+* fix the source of the fault as the EPCM can't be directly modified
+* by software.  Handle the fault as an access error in order to signal
+* userspace, e.g. so that userspace can rebuild their enclave(s), even
+* though userspace may not have actually violated access permissions.
+*/
+   if (unlikely(error_code & X86_PF_SGX))
+   return 1;
+
/*
 * Make sure to check the VMA so that we do not perform
 * faults just to hit a X86_PF_PK as soon as we fill in a
-- 
2.20.1

[PATCH v21 09/28] x86/sgx: Add ENCLS architectural error codes

[Jarkko Sakkinen]

The SGX architecture defines an extensive set of error codes that are
used by ENCL{S,U,V} instructions to provide software with (somewhat)
precise error information.  Though they are architectural, define the
known error codes in a separate file from sgx_arch.h so that they can
be exposed to userspace.  For some ENCLS leafs, e.g. EINIT, returning
the exact error code on failure can enable userspace to make informed
decisions when an operation fails.

Signed-off-by: Jarkko Sakkinen 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
---
 arch/x86/include/uapi/asm/sgx_errno.h | 91 +++
 1 file changed, 91 insertions(+)
 create mode 100644 arch/x86/include/uapi/asm/sgx_errno.h

diff --git a/arch/x86/include/uapi/asm/sgx_errno.h 
b/arch/x86/include/uapi/asm/sgx_errno.h
new file mode 100644
index ..48b87aed58d7
--- /dev/null
+++ b/arch/x86/include/uapi/asm/sgx_errno.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
+/*
+ * Copyright(c) 2018 Intel Corporation.
+ *
+ * Contains the architecturally defined error codes that are returned by SGX
+ * instructions, e.g. ENCLS, and may be propagated to userspace via errno.
+ */
+
+#ifndef _UAPI_ASM_X86_SGX_ERRNO_H
+#define _UAPI_ASM_X86_SGX_ERRNO_H
+
+/**
+ * enum sgx_encls_leaves - return codes for ENCLS, ENCLU and ENCLV
+ * %SGX_SUCCESS:   No error.
+ * %SGX_INVALID_SIG_STRUCT:SIGSTRUCT contains an invalid value.
+ * %SGX_INVALID_ATTRIBUTE: Enclave is not attempting to access a resource
+ * for which it is not authorized.
+ * %SGX_BLKSTATE:  EPC page is already blocked.
+ * %SGX_INVALID_MEASUREMENT:   SIGSTRUCT or EINITTOKEN contains an incorrect
+ * measurement.
+ * %SGX_NOTBLOCKABLE:  EPC page type is not one which can be blocked.
+ * %SGX_PG_INVLD:  EPC page is invalid (and cannot be blocked).
+ * %SGX_EPC_PAGE_CONFLICT: EPC page in use by another SGX instruction.
+ * %SGX_INVALID_SIGNATURE: Enclave's signature does not validate with
+ * public key enclosed in SIGSTRUCT.
+ * %SGX_MAC_COMPARE_FAIL:  MAC check failed when reloading EPC page.
+ * %SGX_PAGE_NOT_BLOCKED:  EPC page is not marked as blocked.
+ * %SGX_NOT_TRACKED:   ETRACK has not been completed on the EPC page.
+ * %SGX_VA_SLOT_OCCUPIED:  Version array slot contains a valid entry.
+ * %SGX_CHILD_PRESENT: Enclave has child pages present in the EPC.
+ * %SGX_ENCLAVE_ACT:   Logical processors are currently executing
+ * inside the enclave.
+ * %SGX_ENTRYEPOCH_LOCKED: SECS locked for EPOCH update, i.e. an ETRACK is
+ * currently executing on the SECS.
+ * %SGX_INVALID_EINITTOKEN:EINITTOKEN is invalid and enclave signer's
+ * public key does not match IA32_SGXLEPUBKEYHASH.
+ * %SGX_PREV_TRK_INCMPL:   All processors did not complete the previous
+ * tracking sequence.
+ * %SGX_PG_IS_SECS:Target EPC page is an SECS and cannot be
+ * blocked.
+ * %SGX_PAGE_ATTRIBUTES_MISMATCH:  Attributes of the EPC page do not match
+ * the expected values.
+ * %SGX_PAGE_NOT_MODIFIABLE:   EPC page cannot be modified because it is in
+ * the PENDING or MODIFIED state.
+ * %SGX_PAGE_NOT_DEBUGGABLE:   EPC page cannot be modified because it is in
+ * the PENDING or MODIFIED state.
+ * %SGX_INVALID_COUNTER:   {In,De}crementing a counter would cause it to
+ * {over,under}flow.
+ * %SGX_PG_NONEPC: Target page is not an EPC page.
+ * %SGX_TRACK_NOT_REQUIRED:Target page type does not require tracking.
+ * %SGX_INVALID_CPUSVN:Security version number reported by CPU 
is less
+ * than what is required by the enclave.
+ * %SGX_INVALID_ISVSVN:Security version number of enclave is 
less than
+ * what is required by the KEYREQUEST struct.
+ * %SGX_UNMASKED_EVENT:An unmasked event, e.g. INTR, was 
received
+ * while the instruction was executing.
+ * %SGX_INVALID_KEYNAME:   Requested key is not supported by hardware.
+ */
+enum sgx_return_codes {
+   SGX_SUCCESS = 0,
+   SGX_INVALID_SIG_STRUCT  = 1,
+   SGX_INVALID_ATTRIBUTE   = 2,
+   SGX_BLKSTATE= 3,
+   SGX_INVALID_MEASUREMENT = 4,
+   SGX_NOTBLOCKABLE= 5,
+   SGX_PG_INVLD= 6,
+   SGX_EPC_PAGE_CONFLICT   = 7,
+   SGX_INVALID_SIGNATURE   = 8,
+   SGX_MAC_COMPARE_FAIL= 9,
+   SGX_PAGE_NOT_BLOCKED= 10,
+   

[PATCH v21 05/28] x86/msr: Add SGX Launch Control MSR definitions

[Jarkko Sakkinen]

From: Sean Christopherson 

Add a new IA32_FEATURE_CONTROL bit, SGX_LE_WR.  When set, SGX_LE_WR
allows software to write the SGXLEPUBKEYHASH MSRs (see below).  The
The existence of the bit is enumerated by CPUID as X86_FEATURE_SGX_LC.
Like all other flags in IA32_FEATURE_CONTROL, the MSR must be locked
for SGX_LE_WR to take effect.

Add four MSRs, SGXLEPUBKEYHASH{0,1,2,3}, or in human readable form,
the SGX Launch Enclave Public Key Hash MSRs.  These MSRs correspond to
the key that is used by the CPU to determine whether or not to allow
software to enter an enclave.  When ENCLS[EINIT] is executed, which is
a prerequisite to entering the enclave, the CPU compares the key
(technically its hash) used to sign the enclave with the key hash
stored in the MSRs, and will reject EINIT if the keys do not match.

Enclaves can also be blessed by proxy, in which case a Launch Enclave
generates and signs an EINIT TOKEN.  If a valid token is provided,
ENCLS[EINIT] compares the signer of the token against the MSRs instead
of the signer of the enclave.  The SGXLEPUBKEYHASH MSRs only exist on
CPUs that support SGX Launch Control, enumerated by X86_FEATURE_SGX_LC.
CPUs without Launch Control use a hardcoded key for the ENCLS[EINIT]
checks.  An internal hardcoded key is also used as the reset value for
the hash MSRs when they exist.

As a final note, the SGX_LEPUBKEYHASH MSRs can also be written by
pre-boot firmware prior to activating SGX (SGX activation is done by
setting bit 0 in MSR 0x7A).  Thus, firmware can lock the MSRs to a
non-Intel value by writing the MSRs and locking IA32_FEATURE_CONTROL
without setting SGX_LE_WR.

Signed-off-by: Sean Christopherson 
Co-developed-by: Haim Cohen 
Signed-off-by: Haim Cohen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/msr-index.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c006ba8187aa..24da5800b1c6 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -542,6 +542,7 @@
 #define FEATURE_CONTROL_LOCKED (1<<0)
 #define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX   (1<<1)
 #define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX  (1<<2)
+#define FEATURE_CONTROL_SGX_LE_WR  (1<<17)
 #define FEATURE_CONTROL_SGX_ENABLE (1<<18)
 #define FEATURE_CONTROL_LMCE   (1<<20)
 
@@ -555,6 +556,12 @@
 #define MSR_IA32_UCODE_WRITE   0x0079
 #define MSR_IA32_UCODE_REV 0x008b
 
+/* Intel SGX Launch Enclave Public Key Hash MSRs */
+#define MSR_IA32_SGXLEPUBKEYHASH0  0x008C
+#define MSR_IA32_SGXLEPUBKEYHASH1  0x008D
+#define MSR_IA32_SGXLEPUBKEYHASH2  0x008E
+#define MSR_IA32_SGXLEPUBKEYHASH3  0x008F
+
 #define MSR_IA32_SMM_MONITOR_CTL   0x009b
 #define MSR_IA32_SMBASE0x009e
 
-- 
2.20.1

[PATCH v21 08/28] x86/cpu/intel: Detect SGX support and update caps appropriately

[Jarkko Sakkinen]

From: Sean Christopherson 

Similar to other large Intel features such as VMX and TXT, SGX must be
explicitly enabled in IA32_FEATURE_CONTROL MSR to be truly usable.
Clear all SGX related capabilities if SGX is not fully enabled in
IA32_FEATURE_CONTROL or if the SGX1 instruction set isn't supported
(impossible on bare metal, theoretically possible in a VM if the VMM is
doing something weird).

Like SGX itself, SGX Launch Control must be explicitly enabled via a
flag in IA32_FEATURE_CONTROL. Clear the SGX_LC capability if Launch
Control is not fully enabled (or obviously if SGX itself is disabled).

Note that clearing X86_FEATURE_SGX_LC creates a bit of a conundrum
regarding the SGXLEPUBKEYHASH MSRs, as it may be desirable to read the
MSRs even if they are not writable, e.g. to query the configured key,
but clearing the capability leaves no breadcrum for discerning whether
or not the MSRs exist.  But, such usage will be rare (KVM is the only
known case at this time) and not performance critical, so it's not
unreasonable to require the use of rdmsr_safe().  Clearing the cap bit
eliminates the need for an additional flag to track whether or not
Launch Control is truly enabled, which is what we care about the vast
majority of the time.

Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/intel.c | 71 +
 1 file changed, 71 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8d6d92ebeb54..1503b251d10f 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -623,6 +623,72 @@ static void detect_tme(struct cpuinfo_x86 *c)
c->x86_phys_bits -= keyid_bits;
 }
 
+static void __maybe_unused detect_sgx(struct cpuinfo_x86 *c)
+{
+   unsigned long long fc;
+
+   rdmsrl(MSR_IA32_FEATURE_CONTROL, fc);
+   if (!(fc & FEATURE_CONTROL_LOCKED)) {
+   pr_err_once("sgx: The feature control MSR is not locked\n");
+   goto err_unsupported;
+   }
+
+   if (!(fc & FEATURE_CONTROL_SGX_ENABLE)) {
+   pr_err_once("sgx: SGX is not enabled in IA32_FEATURE_CONTROL 
MSR\n");
+   goto err_unsupported;
+   }
+
+   if (!cpu_has(c, X86_FEATURE_SGX1)) {
+   pr_err_once("sgx: SGX1 instruction set is not supported\n");
+   goto err_unsupported;
+   }
+
+   if (!(fc & FEATURE_CONTROL_SGX_LE_WR)) {
+   pr_info_once("sgx: The launch control MSRs are not writable\n");
+   goto err_msrs_rdonly;
+   }
+
+   return;
+
+err_unsupported:
+   setup_clear_cpu_cap(X86_FEATURE_SGX);
+   setup_clear_cpu_cap(X86_FEATURE_SGX1);
+   setup_clear_cpu_cap(X86_FEATURE_SGX2);
+
+err_msrs_rdonly:
+   setup_clear_cpu_cap(X86_FEATURE_SGX_LC);
+}
+
+static void init_intel_energy_perf(struct cpuinfo_x86 *c)
+{
+   u64 epb;
+
+   /*
+* Initialize MSR_IA32_ENERGY_PERF_BIAS if not already initialized.
+* (x86_energy_perf_policy(8) is available to change it at run-time.)
+*/
+   if (!cpu_has(c, X86_FEATURE_EPB))
+   return;
+
+   rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
+   if ((epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
+   return;
+
+   pr_warn_once("ENERGY_PERF_BIAS: Set to 'normal', was 'performance'\n");
+   pr_warn_once("ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)\n");
+   epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
+   wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
+}
+
+static void intel_bsp_resume(struct cpuinfo_x86 *c)
+{
+   /*
+* MSR_IA32_ENERGY_PERF_BIAS is lost across suspend/resume,
+* so reinitialize it properly like during bootup:
+*/
+   init_intel_energy_perf(c);
+}
+
 static void init_cpuid_fault(struct cpuinfo_x86 *c)
 {
u64 msr;
@@ -760,6 +826,11 @@ static void init_intel(struct cpuinfo_x86 *c)
if (cpu_has(c, X86_FEATURE_TME))
detect_tme(c);
 
+   if (IS_ENABLED(CONFIG_INTEL_SGX) && cpu_has(c, X86_FEATURE_SGX))
+   detect_sgx(c);
+
+   init_intel_energy_perf(c);
+
init_intel_misc_features(c);
 }
 
-- 
2.20.1

[PATCH v21 06/28] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit

[Jarkko Sakkinen]

From: Sean Christopherson 

The SGX bit is set in the #PF error code if and only if the fault is
detected by the Enclave Page Cache Map (EPCM), a hardware-managed
table that enforces the paging permissions defined by the enclave,
e.g. to prevent the kernel from changing the permissions of an
enclave's page(s).

Despite triggering a #PF, a #PF with PF_SGX has nothing to do with
paging.

Cc: Dave Hansen 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/traps.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 7d6f3f3fad78..c3e02912e9c7 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -171,5 +171,6 @@ enum x86_pf_error_code {
X86_PF_RSVD =   1 << 3,
X86_PF_INSTR=   1 << 4,
X86_PF_PK   =   1 << 5,
+   X86_PF_SGX  =   1 << 15,
 };
 #endif /* _ASM_X86_TRAPS_H */
-- 
2.20.1

[PATCH v21 03/28] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition

[Jarkko Sakkinen]

From: Sean Christopherson 

Add a new IA32_FEATURE_CONTROL bit, SGX_ENABLE, which must be set in
order to execute SGX instructions, i.e. ENCL{S,U,V}.  The existence of
the bit is enumerated by CPUID as X86_FEATURE_SGX.  Like all other
flags in IA32_FEATURE_CONTROL, the MSR must be locked for SGX_ENABLE
to take effect.

Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/msr-index.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 6b4fc2788078..c006ba8187aa 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -542,6 +542,7 @@
 #define FEATURE_CONTROL_LOCKED (1<<0)
 #define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX   (1<<1)
 #define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX  (1<<2)
+#define FEATURE_CONTROL_SGX_ENABLE (1<<18)
 #define FEATURE_CONTROL_LMCE   (1<<20)
 
 #define MSR_IA32_APICBASE  0x001b
-- 
2.20.1

[PATCH v21 04/28] x86/cpufeatures: Add Intel-defined SGX_LC feature bit

[Jarkko Sakkinen]

From: Kai Huang 

X86_FEATURE_SGX_LC reflects whether or not the CPU supports SGX Launch
Control, i.e. enumerates the existence of IA32_FEATURE_CONTROL's
SGX_LE_WR bit and the IA32_SGXLEPUBKEYHASH MSRs.

Signed-off-by: Kai Huang 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index c5582e766121..ca82226e25ec 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -355,6 +355,7 @@
 #define X86_FEATURE_CLDEMOTE   (16*32+25) /* CLDEMOTE instruction */
 #define X86_FEATURE_MOVDIRI(16*32+27) /* MOVDIRI instruction */
 #define X86_FEATURE_MOVDIR64B  (16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_SGX_LC (16*32+30) /* Software Guard Extensions 
Launch Control */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery 
support */
-- 
2.20.1

[PATCH v21 01/28] x86/cpufeatures: Add Intel-defined SGX feature bit

[Jarkko Sakkinen]

From: Kai Huang 

X86_FEATURE_SGX reflects whether or not the CPU supports Intel's
Software Guard eXtensions (SGX).

Signed-off-by: Kai Huang 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/cpufeatures.h   | 1 +
 arch/x86/include/asm/disabled-features.h | 8 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 998c2cc08363..fcc192098df7 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -236,6 +236,7 @@
 /* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
 #define X86_FEATURE_FSGSBASE   ( 9*32+ 0) /* RDFSBASE, WRFSBASE, 
RDGSBASE, WRGSBASE instructions*/
 #define X86_FEATURE_TSC_ADJUST ( 9*32+ 1) /* TSC adjustment MSR 0x3B */
+#define X86_FEATURE_SGX( 9*32+ 2) /* Software Guard 
Extensions */
 #define X86_FEATURE_BMI1   ( 9*32+ 3) /* 1st group bit 
manipulation extensions */
 #define X86_FEATURE_HLE( 9*32+ 4) /* Hardware Lock 
Elision */
 #define X86_FEATURE_AVX2   ( 9*32+ 5) /* AVX2 instructions */
diff --git a/arch/x86/include/asm/disabled-features.h 
b/arch/x86/include/asm/disabled-features.h
index a5ea841cc6d2..74de07d0f390 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -62,6 +62,12 @@
 # define DISABLE_PTI   (1 << (X86_FEATURE_PTI & 31))
 #endif
 
+#ifdef CONFIG_INTEL_SGX
+# define DISABLE_SGX_CORE  0
+#else
+# define DISABLE_SGX_CORE  (1 << (X86_FEATURE_SGX & 31))
+#endif
+
 /*
  * Make sure to add features to the correct mask
  */
@@ -74,7 +80,7 @@
 #define DISABLED_MASK6 0
 #define DISABLED_MASK7 (DISABLE_PTI)
 #define DISABLED_MASK8 0
-#define DISABLED_MASK9 (DISABLE_MPX|DISABLE_SMAP)
+#define DISABLED_MASK9 (DISABLE_MPX|DISABLE_SMAP|DISABLE_SGX_CORE)
 #define DISABLED_MASK100
 #define DISABLED_MASK110
 #define DISABLED_MASK120
-- 
2.20.1

[PATCH v21 02/28] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits)

[Jarkko Sakkinen]

From: Sean Christopherson 

CPUID_12_EAX is an Intel-defined feature bits leaf dedicated for SGX
that enumerates the SGX instruction sets that are supported by the
CPU, e.g. SGX1, SGX2, etc...  Because Linux currently only cares about
two bits (SGX1 and SGX2) and there are currently only four documented
bits in total, relocate the bits to Linux-defined word 8 to conserve
space.

But, keep the bit positions identical between the Intel-defined value
and the Linux-defined value, e.g. keep SGX1 at bit 0.  This allows KVM
to use its existing code for probing guest CPUID bits using Linux's
X86_FEATURE_* definitions.  To do so, shift around some existing bits
to effectively reserve bits 0-7 of word 8 for SGX sub-features.

Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/cpufeatures.h   | 22 --
 arch/x86/include/asm/disabled-features.h |  6 +-
 arch/x86/kernel/cpu/scattered.c  |  2 ++
 tools/arch/x86/include/asm/cpufeatures.h | 21 +++--
 4 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index fcc192098df7..c5582e766121 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -222,12 +222,22 @@
 #define X86_FEATURE_L1TF_PTEINV( 7*32+29) /* "" L1TF 
workaround PTE inversion */
 #define X86_FEATURE_IBRS_ENHANCED  ( 7*32+30) /* Enhanced IBRS */
 
-/* Virtualization flags: Linux defined, word 8 */
-#define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
-#define X86_FEATURE_VNMI   ( 8*32+ 1) /* Intel Virtual NMI */
-#define X86_FEATURE_FLEXPRIORITY   ( 8*32+ 2) /* Intel FlexPriority */
-#define X86_FEATURE_EPT( 8*32+ 3) /* Intel Extended 
Page Table */
-#define X86_FEATURE_VPID   ( 8*32+ 4) /* Intel Virtual Processor 
ID */
+/*
+ * Scattered Intel features: Linux defined, word 8.
+ *
+ * Note that the bit location of the SGX features is meaningful as KVM expects
+ * the Linux defined bit to match the Intel defined bit, e.g. X86_FEATURE_SGX1
+ * must remain at bit 0, SGX2 at bit 1, etc...
+ */
+#define X86_FEATURE_SGX1   ( 8*32+ 0) /* SGX1 leaf functions */
+#define X86_FEATURE_SGX2   ( 8*32+ 1) /* SGX2 leaf functions */
+/* Bits [0:7] are reserved for SGX */
+
+#define X86_FEATURE_TPR_SHADOW ( 8*32+ 8) /* Intel TPR Shadow */
+#define X86_FEATURE_VNMI   ( 8*32+ 9) /* Intel Virtual NMI */
+#define X86_FEATURE_FLEXPRIORITY   ( 8*32+10) /* Intel FlexPriority */
+#define X86_FEATURE_EPT( 8*32+11) /* Intel Extended 
Page Table */
+#define X86_FEATURE_VPID   ( 8*32+12) /* Intel Virtual Processor 
ID */
 
 #define X86_FEATURE_VMMCALL( 8*32+15) /* Prefer VMMCALL to VMCALL 
*/
 #define X86_FEATURE_XENPV  ( 8*32+16) /* "" Xen paravirtual guest 
*/
diff --git a/arch/x86/include/asm/disabled-features.h 
b/arch/x86/include/asm/disabled-features.h
index 74de07d0f390..926f9dc4d75a 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -34,12 +34,16 @@
 # define DISABLE_CYRIX_ARR (1<<(X86_FEATURE_CYRIX_ARR & 31))
 # define DISABLE_CENTAUR_MCR   (1<<(X86_FEATURE_CENTAUR_MCR & 31))
 # define DISABLE_PCID  0
+# define DISABLE_SGX1  0
+# define DISABLE_SGX2  0
 #else
 # define DISABLE_VME   0
 # define DISABLE_K6_MTRR   0
 # define DISABLE_CYRIX_ARR 0
 # define DISABLE_CENTAUR_MCR   0
 # define DISABLE_PCID  (1<<(X86_FEATURE_PCID & 31))
+# define DISABLE_SGX1  (1<<(X86_FEATURE_SGX1 & 31))
+# define DISABLE_SGX2  (1<<(X86_FEATURE_SGX2 & 31))
 #endif /* CONFIG_X86_64 */
 
 #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
@@ -79,7 +83,7 @@
 #define DISABLED_MASK5 0
 #define DISABLED_MASK6 0
 #define DISABLED_MASK7 (DISABLE_PTI)
-#define DISABLED_MASK8 0
+#define DISABLED_MASK8 (DISABLE_SGX1|DISABLE_SGX2)
 #define DISABLED_MASK9 (DISABLE_MPX|DISABLE_SMAP|DISABLE_SGX_CORE)
 #define DISABLED_MASK100
 #define DISABLED_MASK110
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index adf9b71386ef..9aea45c0b494 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -35,6 +35,8 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
{ X86_FEATURE_CDP_L2,   CPUID_ECX,  2, 0x0010, 2 },
{ X86_FEATURE_MBA,  CPUID_EBX,  3, 0x0010, 0 },
+   { X86_FEATURE_SGX1, CPUID_EAX,  0, 0x0012, 0 },
+   { X86_FEATURE_SGX2, CPUID_EAX,  1, 0x0012, 0 },
{ X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
{ X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
{ 

[PATCH v21 00/28] Intel SGX foundations

[Jarkko Sakkinen]

Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control.  In a way you can think that SGX provides inverted sandbox. It
protects the application from a malicious host.

There is a new hardware unit in the processor called Memory Encryption
Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define
one or many MEE regions that can hold enclave data by configuring them with
PRMRR registers.

The MEE automatically encrypts the data leaving the processor package to
the MEE regions. The data is encrypted using a random key whose life-time
is exactly one power cycle.

The current implementation requires that the firmware sets
IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can
decide what enclaves it wants run. The implementation does not create
any bottlenecks to support read-only MSRs later on.

You can tell if your CPU supports SGX by looking into /proc/cpuinfo:

cat /proc/cpuinfo  | grep sgx

v21:
* Check on mmap() that the VMA does cover an area that does not have
  enclave pages. Only mapping with PROT_NONE can do that to reserve
  initial address space for an enclave.
* Check om mmap() and mprotect() that the VMA permissions do not
  surpass the enclave permissions.
* Remove two refcounts from vma_close(): mm_list and encl->refcount.
  Enclave refcount is only need for swapper/enclave sync and we can
  remove mm_list refcount by destroying mm_struct when the process
  is closed. By not having vm_close() the Linux MM can merge VMAs.
* Do not naturally align MAP_FIXED address.
* Numerous small fixes and clean ups.
* Use SRCU for synchronizing the list of mm_struct's.
* Move to stack based call convention in the vDSO.

v20:
* Fine-tune Kconfig messages and spacing and remove MMU_NOTIFIER
  dependency as MMU notifiers are no longer used in the driver.
* Use mm_users instead of mm_count as refcount for mm_struct as mm_count
  only protects from deleting mm_struct, not removing its contents.
* Sanitize EPC when the reclaimer thread starts by doing EREMOVE for all
  of them. They could be in initialized state when the kernel starts
  because it might be spawned by kexec().
* Documentation overhaul.
* Use a device /dev/sgx/provision for delivering the provision token
  instead of securityfs.
* Create a reference to the enclave when already when opening
  /dev/sgx/enclave.  The file is then associated with this enclave only.
  mmap() can be done at free at any point and always get a reference to
  the enclave. To summarize the file now represents the enclave.

v19:
* Took 3-4 months but in some sense this was more like a rewrite of most
  of the corners of the source code. If I've forgotten to deal with some
  feedback, please don't shout me. Make a remark and I will fix it for
  the next version. Hopefully there won't be this big turnovers anymore.
* Validate SECS attributes properly against CPUID given attributes and
  against allowed attributes. SECS attributes are the ones that are
  enforced whereas SIGSTRUCT attributes tell what is required to run
  the enclave.
* Add KSS (Key Sharing Support) to the enclave attributes.
* Deny MAP_PRIVATE as an enclave is always a shared memory entity.
* Revert back to shmem backing storage so that it can be easily shared
  by multiple processes.
* Split the recognization of an ENCLS leaf failure by using three
  functions to detect it: encsl_faulted(), encls_returned_code() and
  sgx_failed(). encls_failed() is only caused by a spurious expections that
  should never happen. Thus, it is not defined as an inline function in
  order to easily insert a kprobe to it.
* Move low-level enclave management routines, page fault handler and page
  reclaiming routines from driver to the core. These cannot be separated
  from each other as they are heavily interdependent. The rationale is that
  the core does not call any code from the driver.
* Allow the driver to be compiled as a module now that it no code is using
  its routines and it only uses exported symbols. Now the driver is
  essentially just a thin ioctl layer.
* Reworked the driver to maintain a list of mm_struct's. The VMA callbacks
  add new entries to this list as the process is forked. Each entry has
  its own refcount because they have a different life-cycle as the enclave
  does. In effect @tgid and @mm have been removed from struct sgx_encl
  and we allow forking by removing VM_DONTCOPY from vm flags.
* Generate a cpu mask in the reclaimer from the cpu mask's of all
  mm_struct's. This will kick out the hardware threads out of the enclave
  from multiple processes. It is not a local variable because it would
  eat too much of the stack space but instead a field in struct
  sgx_encl.
* Allow forking i.e. remove VM_DONTCOPY. I did not change the API
  because the old API scaled to the workload that Andy 

Re: [PATCH] mm: sparse: Skip no-map regions in memblocks_present

[Wei Yang]

On Sat, Jul 13, 2019 at 01:53:25PM +, Raslan, KarimAllah wrote:
>On Fri, 2019-07-12 at 23:09 +, Wei Yang wrote:
>> On Fri, Jul 12, 2019 at 10:51:31AM +0200, KarimAllah Ahmed wrote:
>> > 
>> > Do not mark regions that are marked with nomap to be present, otherwise
>> > these memblock cause unnecessarily allocation of metadata.
>> > 
>> > Cc: Andrew Morton 
>> > Cc: Pavel Tatashin 
>> > Cc: Oscar Salvador 
>> > Cc: Michal Hocko 
>> > Cc: Mike Rapoport 
>> > Cc: Baoquan He 
>> > Cc: Qian Cai 
>> > Cc: Wei Yang 
>> > Cc: Logan Gunthorpe 
>> > Cc: linux...@kvack.org
>> > Cc: linux-kernel@vger.kernel.org
>> > Signed-off-by: KarimAllah Ahmed 
>> > ---
>> > mm/sparse.c | 4 
>> > 1 file changed, 4 insertions(+)
>> > 
>> > diff --git a/mm/sparse.c b/mm/sparse.c
>> > index fd13166..33810b6 100644
>> > --- a/mm/sparse.c
>> > +++ b/mm/sparse.c
>> > @@ -256,6 +256,10 @@ void __init memblocks_present(void)
>> >struct memblock_region *reg;
>> > 
>> >for_each_memblock(memory, reg) {
>> > +
>> > +  if (memblock_is_nomap(reg))
>> > +  continue;
>> > +
>> >memory_present(memblock_get_region_node(reg),
>> >   memblock_region_memory_base_pfn(reg),
>> >   memblock_region_memory_end_pfn(reg));
>> 
>> 
>> The logic looks good, while I am not sure this would take effect. Since the
>> metadata is SECTION size aligned while memblock is not.
>> 
>> If I am correct, on arm64, we mark nomap memblock in map_mem()
>> 
>> memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
>
>The nomap is also done by EFI code in ${src}/drivers/firmware/efi/arm-init.c
>
>.. and hopefully in the future by this:
>https://lkml.org/lkml/2019/7/12/126
>
>So it is not really striclty associated with the map_mem().
>
>So it is extremely dependent on the platform how much memory will end up 
>mapped??
>as nomap.
>
>> 
>> And kernel text area is less than 40M, if I am right. This means
>> memblocks_present would still mark the section present. 
>> 
>> Would you mind showing how much memory range it is marked nomap?
>
>We actually have some downstream patches that are using this nomap flag for
>more than the use-cases I described above which would enflate the nomap 
>regions??
>a bit :)
>

Thanks for your explanation.

If my understanding is correct, the range you mark nomap could not be used by
the system, it looks those ranges are useless for the system. Just curious
about how linux could use these memory after marking nomap?

>> 
>> > 
>> > -- 
>> > 2.7.4
>> 
>
>
>
>Amazon Development Center Germany GmbH
>Krausenstr. 38
>10117 Berlin
>Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>Sitz: Berlin
>Ust-ID: DE 289 237 879
>
>

-- 
Wei Yang
Help you, Help me

Re: [REGRESSION] Xorg segfaults on Asus Chromebook CP101 with Linux v5.2 (was Asus C101P Chromeboot fails to boot with Linux 5.2)

[Alex Dewar]

On 13/07/2019 16:17, Heiko Stuebner wrote:

Hi,

Am Samstag, 13. Juli 2019, 13:38:45 CEST schrieb Alex Dewar:

I initially thought my machine was failing to boot entirely, but it
turns out it was just failing to start the display manager. I managed to
escape to a tty by hammering the keyboard a bit.

I suspect the culprit is the rockchip_vpu driver (in staging/media),
which has been renamed to hantro in this merge window. When I run startx
from a terminal, X fails to start and Xorg segfaults (log here:
http://users.sussex.ac.uk/~ad374/xorg.log). X seems to work without any
issues in v5.1.


5.2 also has support for Panfrost (Mali-Midgard GPUs) but I'm not
sure if it already can support X11 yet and your X11 log mentions
libglamoregl in the segfault stack trace.

Apart from it bisect that Greg suggested you could also just try
blacklisting either panfrost or vpu kernel modules
/etc/udev/somewhere . This would prevent them from loading

Hope that helps
Heiko




Hi Heiko,

Thanks for this. I blacklisted the panfrost driver and X magically
started working again.

I'll try to do a bisect later to find the offending commit though.

In related news, it also seems that the sound and wifi drivers aren't
working either in 5.2 (although I need to do a bit more testing to
confirm the latter).

Best,
Alex

Re: [PATCH] mm/z3fold.c: Allow __GFP_HIGHMEM in z3fold_alloc

[Shakeel Butt]

On Fri, Jul 12, 2019 at 3:22 PM Henry Burns  wrote:
>
> One of the gfp flags used to show that a page is movable is
> __GFP_HIGHMEM.  Currently z3fold_alloc() fails when __GFP_HIGHMEM is
> passed.  Now that z3fold pages are movable, we allow __GFP_HIGHMEM. We
> strip the movability related flags from the call to kmem_cache_alloc()
> for our slots since it is a kernel allocation.
>
> Signed-off-by: Henry Burns 

Reviewed-by: Shakeel Butt 

> ---
>  mm/z3fold.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index e78f95284d7c..cb567ddf051c 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -193,7 +193,8 @@ static inline struct z3fold_buddy_slots 
> *alloc_slots(struct z3fold_pool *pool,
> gfp_t gfp)
>  {
> struct z3fold_buddy_slots *slots = kmem_cache_alloc(pool->c_handle,
> -   gfp);
> +   (gfp & 
> ~(__GFP_HIGHMEM
> +  | 
> __GFP_MOVABLE)));
>
> if (slots) {
> memset(slots->slot, 0, sizeof(slots->slot));
> @@ -844,7 +845,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
> size, gfp_t gfp,
> enum buddy bud;
> bool can_sleep = gfpflags_allow_blocking(gfp);
>
> -   if (!size || (gfp & __GFP_HIGHMEM))
> +   if (!size)
> return -EINVAL;
>
> if (size > PAGE_SIZE)
> --
> 2.22.0.510.g264f2c817a-goog
>

FRESH & NEW EMAIL LEADS TOOLS, RDP,EMAILS, SPYWARES, SMTP, MAILER, CVV

[CYBER GATES LTD]

DEAR CUSTOMERS
We are happy to inform you about our new SMTP SERVER
today I would like to introduce you to a page that provides services for 
UNLIMITED SENDER
We offer all the services that you desire now? 15x Domain Inbox SMTP
please check  
http://www.cybergatesltd.net/index.php?route=product/product_id=458

Unlimited SMTP (Cheap and Inbox)
Unlimited PHP Mailer (Cheap and Inbox)
Unlimited WebMail Sever ( Cheap And Inbox)
RDP With AMS 4.3 (Warranty Full Time and On Sales)
Email Leads (New and Fresh)
Unlimited Cpanel Hosting (Use For Scampage, botnet,etc...)
VPN
Linux Root
Hacking Tools
zeus trojan Hacking
ScamPage
CVV,
BANK LOGINS,
DATING SITES LOGIN
SPYWARES
ETC

Top Services  http://www.cybergatesltd.net
To impress the customers, so we decided to discout  price all products with 10% 
discount code: http://www.cybergatesltd.net

You can see more
Sale OFF 10% All Product
How can I enter discount code?
We also have 100 RDP WITH AMS program discounts to customers
Click here to Order Now, be quick, limited
http://www.cybergatesltd.net/index.php?route=product/category=93
Why is trusted by our customers?
We always provide the best service for our customers, we guarantee customers 
will be happy to have what they want, the first priority is to treat our 
customers as god
How to Order?
Payment Method?
We accept payment Via PerfectMoney
We will try to accept multiple payment gateways to serve customers better
Deliver
We Delivered Via Email Within 0-2 hour
You have any questions Other?
Click here for see more //
http://www.cybergatesltd.net/index.php?route=product/category=59
Are you ready to experience?
READY TO GET STARTED?
With us, you will not be disappointed, currently on the market there are many 
scam sites, selling quality goods, come to us, we will show you, Our service is 
best
Customer Care Services
Thank you for choosing cyber gates Store!
chat with the admin for more information
Perfect Money payments will be accepted using our LIVE CHAT payment processor.

skype( skytunnel1
chat ( rs...@yahoo.com
www.cybergatesltd.net

[PATCH v2] ARM: dts: msm8974-FP2: add reboot-mode node

[Luca Weiss]

This enables userspace to signal the bootloader to go into the
bootloader or recovery mode.

The magic values can be found in both the downstream kernel and the LK
kernel (bootloader).

Reviewed-by: Brian Masney 
Signed-off-by: Luca Weiss 
---
Changes v1 -> v2:
- Move the majority of the node into the board dts, just keep the magic
  values in the device-specific dts.

 arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts | 10 ++
 arch/arm/boot/dts/qcom-msm8974.dtsi  | 11 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts 
b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
index 643c57f84818..ff4a3e0aa746 100644
--- a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
@@ -338,6 +338,16 @@
};
};
};
+
+   imem@fe805000 {
+   status = "okay";
+
+   reboot-mode {
+   mode-normal = <0x77665501>;
+   mode-bootloader = <0x77665500>;
+   mode-recovery   = <0x77665502>;
+   };
+   };
 };
 
 _bus {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..1927430bded7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1085,6 +1085,17 @@
};
};
};
+
+   imem@fe805000 {
+   status = "disabled";
+   compatible = "syscon", "simple-mfd";
+   reg = <0xfe805000 0x1000>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x65c>;
+   };
+   };
};
 
smd {
-- 
2.22.0

[PATCH] power: reset: reboot-mode: Fix author email format

[Matwey V. Kornilov]

Closing angle bracket was missing.

Signed-off-by: Matwey V. Kornilov 
---
 drivers/power/reset/reboot-mode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
index 06ff035b57f5..b4076b10b893 100644
--- a/drivers/power/reset/reboot-mode.c
+++ b/drivers/power/reset/reboot-mode.c
@@ -190,6 +190,6 @@ void devm_reboot_mode_unregister(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_reboot_mode_unregister);
 
-MODULE_AUTHOR("Andy Yan ");
 MODULE_DESCRIPTION("System reboot mode core library");
 MODULE_LICENSE("GPL v2");
-- 
2.16.4

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

[Joel Fernandes]

On Sat, Jul 13, 2019 at 08:13:30AM -0700, Paul E. McKenney wrote:
> On Sat, Jul 13, 2019 at 10:20:02AM -0400, Joel Fernandes wrote:
> > On Sat, Jul 13, 2019 at 4:47 AM Byungchul Park
> >  wrote:
> > >
> > > On Fri, Jul 12, 2019 at 9:51 PM Joel Fernandes  
> > > wrote:
> > > >
> > > > On Fri, Jul 12, 2019 at 03:32:40PM +0900, Byungchul Park wrote:
> > > > > On Thu, Jul 11, 2019 at 03:58:39PM -0400, Joel Fernandes wrote:
> > > > > > Hmm, speaking of grace period durations, it seems to me the maximum 
> > > > > > grace
> > > > > > period ever is recorded in rcu_state.gp_max. However it is not read 
> > > > > > from
> > > > > > anywhere.
> > > > > >
> > > > > > Any idea why it was added but not used?
> > > > > >
> > > > > > I am interested in dumping this value just for fun, and seeing what 
> > > > > > I get.
> > > > > >
> > > > > > I wonder also it is useful to dump it in rcutorture/rcuperf to find 
> > > > > > any
> > > > > > issues, or even expose it in sys/proc fs to see what worst case 
> > > > > > grace periods
> > > > > > look like.
> > > > >
> > > > > Hi,
> > > > >
> > > > >   commit ae91aa0adb14dc33114d566feca2f7cb7a96b8b7
> > > > >   rcu: Remove debugfs tracing
> > > > >
> > > > > removed all debugfs tracing, gp_max also included.
> > > > >
> > > > > And you sounds great. And even looks not that hard to add it like,
> > > > >
> > > > > :)
> > > > >
> > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > index ad9dc86..86095ff 100644
> > > > > --- a/kernel/rcu/tree.c
> > > > > +++ b/kernel/rcu/tree.c
> > > > > @@ -1658,8 +1658,10 @@ static void rcu_gp_cleanup(void)
> > > > >   raw_spin_lock_irq_rcu_node(rnp);
> > > > >   rcu_state.gp_end = jiffies;
> > > > >   gp_duration = rcu_state.gp_end - rcu_state.gp_start;
> > > > > - if (gp_duration > rcu_state.gp_max)
> > > > > + if (gp_duration > rcu_state.gp_max) {
> > > > >   rcu_state.gp_max = gp_duration;
> > > > > + trace_rcu_grace_period(something something);
> > > > > + }
> > > >
> > > > Yes, that makes sense. But I think it is much better off as a readable 
> > > > value
> > > > from a virtual fs. The drawback of tracing for this sort of thing are:
> > > >  - Tracing will only catch it if tracing is on
> > > >  - Tracing data can be lost if too many events, then no one has a clue 
> > > > what
> > > >the max gp time is.
> > > >  - The data is already available in rcu_state::gp_max so copying it 
> > > > into the
> > > >trace buffer seems a bit pointless IMHO
> > > >  - It is a lot easier on ones eyes to process a single counter than 
> > > > process
> > > >heaps of traces.
> > > >
> > > > I think a minimal set of RCU counters exposed to /proc or /sys should 
> > > > not
> > > > hurt and could do more good than not. The scheduler already does this 
> > > > for
> > > > scheduler statistics. I have seen Peter complain a lot about new 
> > > > tracepoints
> > > > but not much (or never) about new statistics.
> > > >
> > > > Tracing has its strengths but may not apply well here IMO. I think a 
> > > > counter
> > > > like this could be useful for tuning of things like the 
> > > > jiffies_*_sched_qs,
> > > > the stall timeouts and also any other RCU knobs. What do you think?
> > >
> > > I prefer proc/sys knob for it to tracepoint. Why I've considered it is 
> > > just it
> > > looks like undoing what Paul did at ae91aa0ad.
> > >
> > > I think you're rational enough. I just wondered how Paul think of it.
> > 
> > I believe at least initially, a set of statistics can be made
> > available only when rcutorture or rcuperf module is loaded. That way
> > they are purely only for debugging and nothing needs to be exposed to
> > normal kernels distributed thus reducing testability concerns.
> > 
> > rcu_state::gp_max would be trivial to expose through this, but for
> > other statistics that are more complicated - perhaps
> > tracepoint_probe_register can be used to add hooks on to the
> > tracepoints and generate statistics from them. Again the registration
> > of the probe and the probe handler itself would all be in
> > rcutorture/rcuperf test code and not a part of the kernel proper.
> > Thoughts?
> 
> It still feels like you guys are hyperfocusing on this one particular
> knob.  I instead need you to look at the interrelating knobs as a group.

Thanks for the hints, we'll do that.

> On the debugging side, suppose someone gives you an RCU bug report.
> What information will you need?  How can you best get that information
> without excessive numbers of over-and-back interactions with the guy
> reporting the bug?  As part of this last question, what information is
> normally supplied with the bug?  Alternatively, what information are
> bug reporters normally expected to provide when asked?

I suppose I could dig out some of our Android bug reports of the past where
there were RCU issues but if there's any fires you are currently fighting do
send it our way as debugging homework 

[net-next 0/2] ipvs: speedup ipvs netns dismantle

[Haishuang Yan]

Implement exit_batch() method to dismantle more ipvs netns
per round.

Haishuang Yan (2):
  ipvs: batch __ip_vs_cleanup
  ipvs: batch __ip_vs_dev_cleanup

 include/net/ip_vs.h |  2 +-
 net/netfilter/ipvs/ip_vs_core.c | 49 +
 net/netfilter/ipvs/ip_vs_ctl.c  | 13 ---
 3 files changed, 41 insertions(+), 23 deletions(-)

-- 
1.8.3.1

[net-next 2/2] ipvs: batch __ip_vs_dev_cleanup

[Haishuang Yan]

It's better to batch __ip_vs_cleanup to speedup ipvs
devices dismantle.

Signed-off-by: Haishuang Yan 
---
 net/netfilter/ipvs/ip_vs_core.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index b4d79b7..58af24a 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2434,14 +2434,20 @@ static int __net_init __ip_vs_dev_init(struct net *net)
return ret;
 }
 
-static void __net_exit __ip_vs_dev_cleanup(struct net *net)
+static void __net_exit __ip_vs_dev_cleanup_batch(struct list_head *net_list)
 {
-   struct netns_ipvs *ipvs = net_ipvs(net);
+   struct netns_ipvs *ipvs;
+   struct net *net;
+   LIST_HEAD(list);
+
EnterFunction(2);
-   nf_unregister_net_hooks(net, ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
-   ipvs->enable = 0;   /* Disable packet reception */
-   smp_wmb();
-   ip_vs_sync_net_cleanup(ipvs);
+   list_for_each_entry(net, net_list, exit_list) {
+   ipvs = net_ipvs(net);
+   nf_unregister_net_hooks(net, ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
+   ipvs->enable = 0;   /* Disable packet reception */
+   smp_wmb();
+   ip_vs_sync_net_cleanup(ipvs);
+   }
LeaveFunction(2);
 }
 
@@ -2454,7 +2460,7 @@ static void __net_exit __ip_vs_dev_cleanup(struct net 
*net)
 
 static struct pernet_operations ipvs_core_dev_ops = {
.init = __ip_vs_dev_init,
-   .exit = __ip_vs_dev_cleanup,
+   .exit_batch = __ip_vs_dev_cleanup_batch,
 };
 
 /*
-- 
1.8.3.1

Re: [PATCH] [net-next] cxgb4: reduce kernel stack usage in cudbg_collect_mem_region()

[Arnd Bergmann]

On Sat, Jul 13, 2019 at 2:14 AM Joe Perches  wrote:
>
> On Fri, 2019-07-12 at 15:36 -0700, David Miller wrote:
> > From: Arnd Bergmann 
> > Date: Fri, 12 Jul 2019 11:06:33 +0200
> >
> > > The cudbg_collect_mem_region() and cudbg_read_fw_mem() both use several
> > > hundred kilobytes of kernel stack space.
>
> Several hundred 'kilo' bytes?
> I hope not.

Right, my mistake.

   Arnd

[net-next 1/2] ipvs: batch __ip_vs_cleanup

[Haishuang Yan]

It's better to batch __ip_vs_cleanup to speedup ipvs
connections dismantle.

Signed-off-by: Haishuang Yan 
---
 include/net/ip_vs.h |  2 +-
 net/netfilter/ipvs/ip_vs_core.c | 29 +
 net/netfilter/ipvs/ip_vs_ctl.c  | 13 ++---
 3 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 3759167..93e7a25 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1324,7 +1324,7 @@ static inline void ip_vs_control_del(struct ip_vs_conn 
*cp)
 void ip_vs_control_net_cleanup(struct netns_ipvs *ipvs);
 void ip_vs_estimator_net_cleanup(struct netns_ipvs *ipvs);
 void ip_vs_sync_net_cleanup(struct netns_ipvs *ipvs);
-void ip_vs_service_net_cleanup(struct netns_ipvs *ipvs);
+void ip_vs_service_nets_cleanup(struct list_head *net_list);
 
 /* IPVS application functions
  * (from ip_vs_app.c)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 46f06f9..b4d79b7 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2402,18 +2402,23 @@ static int __net_init __ip_vs_init(struct net *net)
return -ENOMEM;
 }
 
-static void __net_exit __ip_vs_cleanup(struct net *net)
+static void __net_exit __ip_vs_cleanup_batch(struct list_head *net_list)
 {
-   struct netns_ipvs *ipvs = net_ipvs(net);
-
-   ip_vs_service_net_cleanup(ipvs);/* ip_vs_flush() with locks */
-   ip_vs_conn_net_cleanup(ipvs);
-   ip_vs_app_net_cleanup(ipvs);
-   ip_vs_protocol_net_cleanup(ipvs);
-   ip_vs_control_net_cleanup(ipvs);
-   ip_vs_estimator_net_cleanup(ipvs);
-   IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen);
-   net->ipvs = NULL;
+   struct netns_ipvs *ipvs;
+   struct net *net;
+   LIST_HEAD(list);
+
+   ip_vs_service_nets_cleanup(net_list);   /* ip_vs_flush() with locks */
+   list_for_each_entry(net, net_list, exit_list) {
+   ipvs = net_ipvs(net);
+   ip_vs_conn_net_cleanup(ipvs);
+   ip_vs_app_net_cleanup(ipvs);
+   ip_vs_protocol_net_cleanup(ipvs);
+   ip_vs_control_net_cleanup(ipvs);
+   ip_vs_estimator_net_cleanup(ipvs);
+   IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen);
+   net->ipvs = NULL;
+   }
 }
 
 static int __net_init __ip_vs_dev_init(struct net *net)
@@ -2442,7 +2447,7 @@ static void __net_exit __ip_vs_dev_cleanup(struct net 
*net)
 
 static struct pernet_operations ipvs_core_ops = {
.init = __ip_vs_init,
-   .exit = __ip_vs_cleanup,
+   .exit_batch = __ip_vs_cleanup_batch,
.id   = _vs_net_id,
.size = sizeof(struct netns_ipvs),
 };
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 07e0967..c8e652b 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1607,14 +1607,21 @@ static int ip_vs_flush(struct netns_ipvs *ipvs, bool 
cleanup)
 
 /*
  * Delete service by {netns} in the service table.
- * Called by __ip_vs_cleanup()
+ * Called by __ip_vs_batch_cleanup()
  */
-void ip_vs_service_net_cleanup(struct netns_ipvs *ipvs)
+void ip_vs_service_nets_cleanup(struct list_head *net_list)
 {
+   struct netns_ipvs *ipvs;
+   struct net *net;
+   LIST_HEAD(list);
+
EnterFunction(2);
/* Check for "full" addressed entries */
mutex_lock(&__ip_vs_mutex);
-   ip_vs_flush(ipvs, true);
+   list_for_each_entry(net, net_list, exit_list) {
+   ipvs = net_ipvs(net);
+   ip_vs_flush(ipvs, true);
+   }
mutex_unlock(&__ip_vs_mutex);
LeaveFunction(2);
 }
-- 
1.8.3.1

Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section

[Joel Fernandes]

On Sat, Jul 13, 2019 at 07:41:08AM -0700, Paul E. McKenney wrote:
> On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> > On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) 
> > > > > > > wrote:
> > > > > > > > The rcu/sync code was doing its own check whether we are in a 
> > > > > > > > reader
> > > > > > > > section. With RCU consolidating flavors and the generic helper 
> > > > > > > > added in
> > > > > > > > this series, this is no longer need. We can just use the 
> > > > > > > > generic helper
> > > > > > > > and it results in a nice cleanup.
> > > > > > > > 
> > > > > > > > Cc: Oleg Nesterov 
> > > > > > > > Signed-off-by: Joel Fernandes (Google) 
> > > > > > > 
> > > > > > > Hi Oleg,
> > > > > > > Slightly unrelated to the patch,
> > > > > > > I tried hard to understand this comment below in 
> > > > > > > percpu_down_read() but no dice.
> > > > > > > 
> > > > > > > I do understand how rcu sync and percpu rwsem works, however the 
> > > > > > > comment
> > > > > > > below didn't make much sense to me. For one, there's no 
> > > > > > > readers_fast anymore
> > > > > > > so I did not follow what readers_fast means. Could the comment be 
> > > > > > > updated to
> > > > > > > reflect latest changes?
> > > > > > > Also could you help understand how is a writer not able to change
> > > > > > > sem->state and count the per-cpu read counters at the same time 
> > > > > > > as the
> > > > > > > comment tries to say?
> > > > > > > 
> > > > > > >   /*
> > > > > > >* We are in an RCU-sched read-side critical section, so the 
> > > > > > > writer
> > > > > > >* cannot both change sem->state from readers_fast and start 
> > > > > > > checking
> > > > > > >* counters while we are here. So if we see !sem->state, we 
> > > > > > > know that
> > > > > > >* the writer won't be checking until we're past the 
> > > > > > > preempt_enable()
> > > > > > >* and that once the synchronize_rcu() is done, the writer will 
> > > > > > > see
> > > > > > >* anything we did within this RCU-sched read-size critical 
> > > > > > > section.
> > > > > > >*/
> > > > > > > 
> > > > > > > Also,
> > > > > > > I guess we could get rid of all of the gp_ops struct stuff now 
> > > > > > > that since all
> > > > > > > the callbacks are the same now. I will post that as a follow-up 
> > > > > > > patch to this
> > > > > > > series.
> > > > > > 
> > > > > > Hello, Joel,
> > > > > > 
> > > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > > this week.  These patches get rid of the code that previously 
> > > > > > handled
> > > > > > RCU's multiple flavors.  Or are you looking at current mainline and
> > > > > > me just missing your point?
> > > > > > 
> > > > > 
> > > > > Hi Paul,
> > > > > You are right on point. I have a bad habit of not rebasing my trees. 
> > > > > In this
> > > > > case the feature branch of mine in concern was based on v5.1. 
> > > > > Needless to
> > > > > say, I need to rebase my tree.
> > > > > 
> > > > > Yes, this sync clean up patch does conflict when I rebase, but other 
> > > > > patches
> > > > > rebase just fine.
> > > > > 
> > > > > The 2 options I see are:
> > > > > 1. Let us drop this patch for now and I resend it later.
> > > > > 2. I resend all patches based on Linus's master branch.
> > > > 
> > > > Below is the updated patch based on Linus master branch:
> > > > 
> > > > ---8<---
> > > > 
> > > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > > From: "Joel Fernandes (Google)" 
> > > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for 
> > > > reader-section
> > > > 
> > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > section. With RCU consolidating flavors and the generic helper added in
> > > > this series, this is no longer need. We can just use the generic helper
> > > > and it results in a nice cleanup.
> > > > 
> > > > Cc: Oleg Nesterov 
> > > > Signed-off-by: Joel Fernandes (Google) 
> > > > ---
> > > >  include/linux/rcu_sync.h | 4 +---
> > > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > > 
> > > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > > index 9b83865d24f9..0027d4c8087c 100644
> > > > --- a/include/linux/rcu_sync.h
> > > > +++ b/include/linux/rcu_sync.h
> > > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > >   */
> > > >  static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > >  {
> > > > -   RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > > -   

Re: [PATCH] platform/x86: pcengines-apu2 needs gpiolib

[Arnd Bergmann]

On Sat, Jul 13, 2019 at 4:36 PM Enrico Weigelt, metux IT consult
 wrote:
> On 12.07.19 10:54, Arnd Bergmann wrote:
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index e869a5c760b6..cf48b9068843 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -1324,8 +1324,8 @@ config PCENGINES_APU2
> >   tristate "PC Engines APUv2/3 front button and LEDs driver"
> >   depends on INPUT && INPUT_KEYBOARD
> >   depends on LEDS_CLASS
> > - select GPIO_AMD_FCH
> > - select KEYBOARD_GPIO_POLLED
> > + select GPIO_AMD_FCH if GPIOLIB
> > + select KEYBOARD_GPIO_POLLED if GPIOLIB
> >   select LEDS_GPIO
> >   help
> > This driver provides support for the front button and LEDs on
>
> That might compile but the driver won't work, if KEYBOARD_GPIO_POLLED
> or GPIO_AMD_FCH isn't there.

Right, I agree it's a bit inconsistent. A better way would probably
be to turn all of the 'select' statements into 'depends on' here, or
possibly just remove them and document in the help text what others
are required.

Generally using 'select' in order to save users from thinking causes
more problems than it helps, as the build problems in this driver
have already illustrated.

  Arnd

Re: [GIT PULL] Driver core patches for 5.3-rc1

[Greg KH]

On Fri, Jul 12, 2019 at 02:43:28PM -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2019 at 2:37 PM Linus Torvalds
>  wrote:
> >
> > My bad. Will apply the fix properly.
> 
> Ok, _now_ your fix is finally in my tree. D'oh.

Thanks for fixing this up, sorry for the pain, this was a tough merge
for some reason...

greg k-h

Re: [PATCH 5.2 00/61] 5.2.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2019 at 03:45:14PM +0530, Shreeya Patel wrote:
> On Fri, 2019-07-12 at 14:19 +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.1 release.
> > There are 61 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied,
> > please
> > let me know.
> > 
> > Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> > stable-rc.git linux-5.2.y
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted successfully. No dmesg regressions.

thanks for testing!

Re: [PATCH 5.1 000/138] 5.1.18-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2019 at 08:46:15PM -0500, Jiunn Chang wrote:
> On Fri, Jul 12, 2019 at 02:17:44PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.18 release.
> > There are 138 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun 14 Jul 2019 12:14:36 PM UTC.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.18-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.1.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > -
> 
> Hello,
> 
> Compiled and booted fine.  No regressions on x86_64.

Thanks for testing!

Re: [REGRESSION] Xorg segfaults on Asus Chromebook CP101 with Linux v5.2 (was Asus C101P Chromeboot fails to boot with Linux 5.2)

[Heiko Stuebner]

Hi,

Am Samstag, 13. Juli 2019, 13:38:45 CEST schrieb Alex Dewar:
> I initially thought my machine was failing to boot entirely, but it
> turns out it was just failing to start the display manager. I managed to
> escape to a tty by hammering the keyboard a bit.
> 
> I suspect the culprit is the rockchip_vpu driver (in staging/media),
> which has been renamed to hantro in this merge window. When I run startx
> from a terminal, X fails to start and Xorg segfaults (log here:
> http://users.sussex.ac.uk/~ad374/xorg.log). X seems to work without any
> issues in v5.1.

5.2 also has support for Panfrost (Mali-Midgard GPUs) but I'm not
sure if it already can support X11 yet and your X11 log mentions
libglamoregl in the segfault stack trace.

Apart from it bisect that Greg suggested you could also just try
blacklisting either panfrost or vpu kernel modules
/etc/udev/somewhere . This would prevent them from loading

Hope that helps
Heiko

Re: [RFC PATCH v4 1/3] selftests/x86/sgx: Fix Makefile for SGX selftest

[Jarkko Sakkinen]

On Sat, 2019-07-13 at 18:10 +0300, Jarkko Sakkinen wrote:
> On Fri, 2019-07-12 at 23:51 -0700, Cedric Xing wrote:
> > The original x86/sgx/Makefile didn't work when "x86/sgx" was specified as 
> > the
> > test target, nor did it work with "run_tests" as the make target. Yet 
> > another
> > problem was that it breaks 32-bit only build. This patch fixes those 
> > problems,
> > along with adjustments to compiler/linker options and simplifications to the
> > build rules.
> > 
> > Signed-off-by: Cedric Xing 
> 
> You must split this in quite a few separate patches:
> 
> 1. One for each fix.
> 2. At least one patch for each change in compiler and linker options with a
>commit message clearly expalaining why the change was made.
> 3. One for each simplification.
> 
> We don't support 32-bit build:
> 
> config INTEL_SGX
>   bool "Intel SGX core functionality"
>   depends on X86_64 && CPU_SUP_INTEL

This is not to say that changes suck. This just in "unreviewable" state as far
as the kernel processes go...

/Jarkko

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

[Paul E. McKenney]

On Sat, Jul 13, 2019 at 10:20:02AM -0400, Joel Fernandes wrote:
> On Sat, Jul 13, 2019 at 4:47 AM Byungchul Park
>  wrote:
> >
> > On Fri, Jul 12, 2019 at 9:51 PM Joel Fernandes  
> > wrote:
> > >
> > > On Fri, Jul 12, 2019 at 03:32:40PM +0900, Byungchul Park wrote:
> > > > On Thu, Jul 11, 2019 at 03:58:39PM -0400, Joel Fernandes wrote:
> > > > > Hmm, speaking of grace period durations, it seems to me the maximum 
> > > > > grace
> > > > > period ever is recorded in rcu_state.gp_max. However it is not read 
> > > > > from
> > > > > anywhere.
> > > > >
> > > > > Any idea why it was added but not used?
> > > > >
> > > > > I am interested in dumping this value just for fun, and seeing what I 
> > > > > get.
> > > > >
> > > > > I wonder also it is useful to dump it in rcutorture/rcuperf to find 
> > > > > any
> > > > > issues, or even expose it in sys/proc fs to see what worst case grace 
> > > > > periods
> > > > > look like.
> > > >
> > > > Hi,
> > > >
> > > >   commit ae91aa0adb14dc33114d566feca2f7cb7a96b8b7
> > > >   rcu: Remove debugfs tracing
> > > >
> > > > removed all debugfs tracing, gp_max also included.
> > > >
> > > > And you sounds great. And even looks not that hard to add it like,
> > > >
> > > > :)
> > > >
> > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > index ad9dc86..86095ff 100644
> > > > --- a/kernel/rcu/tree.c
> > > > +++ b/kernel/rcu/tree.c
> > > > @@ -1658,8 +1658,10 @@ static void rcu_gp_cleanup(void)
> > > >   raw_spin_lock_irq_rcu_node(rnp);
> > > >   rcu_state.gp_end = jiffies;
> > > >   gp_duration = rcu_state.gp_end - rcu_state.gp_start;
> > > > - if (gp_duration > rcu_state.gp_max)
> > > > + if (gp_duration > rcu_state.gp_max) {
> > > >   rcu_state.gp_max = gp_duration;
> > > > + trace_rcu_grace_period(something something);
> > > > + }
> > >
> > > Yes, that makes sense. But I think it is much better off as a readable 
> > > value
> > > from a virtual fs. The drawback of tracing for this sort of thing are:
> > >  - Tracing will only catch it if tracing is on
> > >  - Tracing data can be lost if too many events, then no one has a clue 
> > > what
> > >the max gp time is.
> > >  - The data is already available in rcu_state::gp_max so copying it into 
> > > the
> > >trace buffer seems a bit pointless IMHO
> > >  - It is a lot easier on ones eyes to process a single counter than 
> > > process
> > >heaps of traces.
> > >
> > > I think a minimal set of RCU counters exposed to /proc or /sys should not
> > > hurt and could do more good than not. The scheduler already does this for
> > > scheduler statistics. I have seen Peter complain a lot about new 
> > > tracepoints
> > > but not much (or never) about new statistics.
> > >
> > > Tracing has its strengths but may not apply well here IMO. I think a 
> > > counter
> > > like this could be useful for tuning of things like the 
> > > jiffies_*_sched_qs,
> > > the stall timeouts and also any other RCU knobs. What do you think?
> >
> > I prefer proc/sys knob for it to tracepoint. Why I've considered it is just 
> > it
> > looks like undoing what Paul did at ae91aa0ad.
> >
> > I think you're rational enough. I just wondered how Paul think of it.
> 
> I believe at least initially, a set of statistics can be made
> available only when rcutorture or rcuperf module is loaded. That way
> they are purely only for debugging and nothing needs to be exposed to
> normal kernels distributed thus reducing testability concerns.
> 
> rcu_state::gp_max would be trivial to expose through this, but for
> other statistics that are more complicated - perhaps
> tracepoint_probe_register can be used to add hooks on to the
> tracepoints and generate statistics from them. Again the registration
> of the probe and the probe handler itself would all be in
> rcutorture/rcuperf test code and not a part of the kernel proper.
> Thoughts?

It still feels like you guys are hyperfocusing on this one particular
knob.  I instead need you to look at the interrelating knobs as a group.

On the debugging side, suppose someone gives you an RCU bug report.
What information will you need?  How can you best get that information
without excessive numbers of over-and-back interactions with the guy
reporting the bug?  As part of this last question, what information is
normally supplied with the bug?  Alternatively, what information are
bug reporters normally expected to provide when asked?

Thanx, Paul

Re: [PATCH] fTPM: fix PTR_ERR() usage

[Sasha Levin]

On Fri, Jul 12, 2019 at 06:34:24PM +0300, Jarkko Sakkinen wrote:

On Fri, 2019-07-12 at 13:49 +0200, Arnd Bergmann wrote:

A last minute change must have confused PTR_ERR() and ERR_PTR():

drivers/char/tpm/tpm_ftpm_tee.c:236:15: error: incompatible pointer to integer
conversion passing 'struct tee_context *' to parameter of type 'long' [-
Werror,-Wint-conversion]
if (ERR_PTR(pvt_data->ctx) == -ENOENT)
drivers/char/tpm/tpm_ftpm_tee.c:239:18: error: incompatible pointer to integer
conversion passing 'struct tee_context *' to parameter of type 'long' [-
Werror,-Wint-conversion]
return ERR_PTR(pvt_data->ctx);

Fixes: c975c3911cc2 ("fTPM: firmware TPM running in TEE")
Signed-off-by: Arnd Bergmann 


Arnd, thanks.

I squashed this to the associated commit.

I also fine-tuned the commit messages a bit (tag, imperative form).


Yes, thank you!


Started also wondering tha tpm_ftpm_tee is a too generic name given that
this is for ARM TZ only. Would it make sense to rename it as something
like tpm_ftpm_tee_arm? Other proposals are welcome. Just made something
up.


Hm, isn't the _tee part enough?

--
Thanks,
Sasha

Re: [RFC PATCH v4 1/3] selftests/x86/sgx: Fix Makefile for SGX selftest

[Jarkko Sakkinen]

On Fri, 2019-07-12 at 23:51 -0700, Cedric Xing wrote:
> The original x86/sgx/Makefile didn't work when "x86/sgx" was specified as the
> test target, nor did it work with "run_tests" as the make target. Yet another
> problem was that it breaks 32-bit only build. This patch fixes those problems,
> along with adjustments to compiler/linker options and simplifications to the
> build rules.
> 
> Signed-off-by: Cedric Xing 

You must split this in quite a few separate patches:

1. One for each fix.
2. At least one patch for each change in compiler and linker options with a
   commit message clearly expalaining why the change was made.
3. One for each simplification.

We don't support 32-bit build:

config INTEL_SGX
bool "Intel SGX core functionality"
depends on X86_64 && CPU_SUP_INTEL

/Jarkko