[PATCH] usb: class: usblp: Fixed assignments inside if conditions

2017-05-12 Thread Alberto Ladron
Fixed coding style issues.

Signed-off-by: Alberto Ladron 
---
 drivers/usb/class/usblp.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index fb87c17..b1879ff 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -362,7 +362,8 @@ static int usblp_check_status(struct usblp *usblp, int err)
int error;
 
mutex_lock(>mut);
-   if ((error = usblp_read_status(usblp, usblp->statusbuf)) < 0) {
+   error = usblp_read_status(usblp, usblp->statusbuf);
+   if (error < 0) {
mutex_unlock(>mut);
printk_ratelimited(KERN_ERR
"usblp%d: error %d reading printer status\n",
@@ -735,14 +736,16 @@ static ssize_t usblp_write(struct file *file, const char 
__user *buffer, size_t
rv = -EINTR;
goto raise_biglock;
}
-   if ((rv = usblp_wwait(usblp, !!(file->f_flags & O_NONBLOCK))) < 0)
+   rv = usblp_wwait(usblp, !!(file->f_flags & O_NONBLOCK));
+   if (rv < 0)
goto raise_wait;
 
while (writecount < count) {
/*
 * Step 1: Submit next block.
 */
-   if ((transfer_length = count - writecount) > USBLP_BUF_SIZE)
+   transfer_length = count - writecount;
+   if (transfer_length > USBLP_BUF_SIZE)
transfer_length = USBLP_BUF_SIZE;
 
rv = -ENOMEM;
@@ -760,7 +763,8 @@ static ssize_t usblp_write(struct file *file, const char 
__user *buffer, size_t
spin_lock_irq(>lock);
usblp->wcomplete = 0;
spin_unlock_irq(>lock);
-   if ((rv = usb_submit_urb(writeurb, GFP_KERNEL)) < 0) {
+   rv = usb_submit_urb(writeurb, GFP_KERNEL);
+   if (rv < 0) {
usblp->wstatus = 0;
spin_lock_irq(>lock);
usblp->no_paper = 0;
@@ -835,8 +839,8 @@ static ssize_t usblp_read(struct file *file, char __user 
*buffer, size_t len, lo
rv = usblp_rwait_and_lock(usblp, !!(file->f_flags & O_NONBLOCK));
if (rv < 0)
return rv;
-
-   if ((avail = usblp->rstatus) < 0) {
+   avail = usblp->rstatus;
+   if (avail < 0) {
printk(KERN_ERR "usblp%d: error %d reading from printer\n",
usblp->minor, (int)avail);
usblp_submit_read(usblp);
@@ -851,7 +855,9 @@ static ssize_t usblp_read(struct file *file, char __user 
*buffer, size_t len, lo
goto done;
}
 
-   if ((usblp->readcount += count) == avail) {
+   usblp->readcount += count;
+
+   if (usblp->readcount == avail) {
if (usblp_submit_read(usblp) < 0) {
/* We don't want to leak USB return codes into errno. */
if (count == 0)
@@ -952,7 +958,8 @@ static int usblp_rwait_and_lock(struct usblp *usblp, int 
nonblock)
break;
}
set_current_state(TASK_INTERRUPTIBLE);
-   if ((rc = usblp_rtest(usblp, nonblock)) < 0) {
+   rc = usblp_rtest(usblp, nonblock);
+   if (rc < 0) {
mutex_unlock(>mut);
break;
}
@@ -1010,7 +1017,8 @@ static int usblp_submit_read(struct usblp *usblp)
usblp->readcount = 0; /* XXX Why here? */
usblp->rcomplete = 0;
spin_unlock_irqrestore(>lock, flags);
-   if ((rc = usb_submit_urb(urb, GFP_KERNEL)) < 0) {
+   rc = usb_submit_urb(urb, GFP_KERNEL);
+   if (rv < 0) {
dev_dbg(>intf->dev, "error submitting urb (%d)\n", rc);
spin_lock_irqsave(>lock, flags);
usblp->rstatus = rc;
@@ -1123,7 +1131,8 @@ static int usblp_probe(struct usb_interface *intf,
/* Malloc device ID string buffer to the largest expected length,
 * since we can re-query it on an ioctl and a dynamic string
 * could change in length. */
-   if (!(usblp->device_id_string = kmalloc(USBLP_DEVICE_ID_SIZE, 
GFP_KERNEL))) {
+   usblp->device_id_string = kmalloc(USBLP_DEVICE_ID_SIZE, GFP_KERNEL);
+   if (!usblp->device_id_string) {
retval = -ENOMEM;
goto abort;
}
@@ -1133,7 +1142,8 @@ static int usblp_probe(struct usb_interface *intf,
 * malloc both regardless of bidirectionality, because the
 * alternate setting can be changed later via an ioctl.
 */
-   if (!(usblp->readbuf = kmalloc(USBLP_BUF_SIZE_IN, GFP_KERNEL))) {
+   usblp->readbuf = kmalloc(USBLP_BUF_SIZE_IN, GFP_KERNEL);
+   if (!usblp->readbuf) {
retval = -ENOMEM;
goto abort;
}
-- 
2.9.3



[PATCH] usb: class: usblp: Fixed assignments inside if conditions

2017-05-12 Thread Alberto Ladron
Fixed coding style issues.

Signed-off-by: Alberto Ladron 
---
 drivers/usb/class/usblp.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index fb87c17..b1879ff 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -362,7 +362,8 @@ static int usblp_check_status(struct usblp *usblp, int err)
int error;
 
mutex_lock(>mut);
-   if ((error = usblp_read_status(usblp, usblp->statusbuf)) < 0) {
+   error = usblp_read_status(usblp, usblp->statusbuf);
+   if (error < 0) {
mutex_unlock(>mut);
printk_ratelimited(KERN_ERR
"usblp%d: error %d reading printer status\n",
@@ -735,14 +736,16 @@ static ssize_t usblp_write(struct file *file, const char 
__user *buffer, size_t
rv = -EINTR;
goto raise_biglock;
}
-   if ((rv = usblp_wwait(usblp, !!(file->f_flags & O_NONBLOCK))) < 0)
+   rv = usblp_wwait(usblp, !!(file->f_flags & O_NONBLOCK));
+   if (rv < 0)
goto raise_wait;
 
while (writecount < count) {
/*
 * Step 1: Submit next block.
 */
-   if ((transfer_length = count - writecount) > USBLP_BUF_SIZE)
+   transfer_length = count - writecount;
+   if (transfer_length > USBLP_BUF_SIZE)
transfer_length = USBLP_BUF_SIZE;
 
rv = -ENOMEM;
@@ -760,7 +763,8 @@ static ssize_t usblp_write(struct file *file, const char 
__user *buffer, size_t
spin_lock_irq(>lock);
usblp->wcomplete = 0;
spin_unlock_irq(>lock);
-   if ((rv = usb_submit_urb(writeurb, GFP_KERNEL)) < 0) {
+   rv = usb_submit_urb(writeurb, GFP_KERNEL);
+   if (rv < 0) {
usblp->wstatus = 0;
spin_lock_irq(>lock);
usblp->no_paper = 0;
@@ -835,8 +839,8 @@ static ssize_t usblp_read(struct file *file, char __user 
*buffer, size_t len, lo
rv = usblp_rwait_and_lock(usblp, !!(file->f_flags & O_NONBLOCK));
if (rv < 0)
return rv;
-
-   if ((avail = usblp->rstatus) < 0) {
+   avail = usblp->rstatus;
+   if (avail < 0) {
printk(KERN_ERR "usblp%d: error %d reading from printer\n",
usblp->minor, (int)avail);
usblp_submit_read(usblp);
@@ -851,7 +855,9 @@ static ssize_t usblp_read(struct file *file, char __user 
*buffer, size_t len, lo
goto done;
}
 
-   if ((usblp->readcount += count) == avail) {
+   usblp->readcount += count;
+
+   if (usblp->readcount == avail) {
if (usblp_submit_read(usblp) < 0) {
/* We don't want to leak USB return codes into errno. */
if (count == 0)
@@ -952,7 +958,8 @@ static int usblp_rwait_and_lock(struct usblp *usblp, int 
nonblock)
break;
}
set_current_state(TASK_INTERRUPTIBLE);
-   if ((rc = usblp_rtest(usblp, nonblock)) < 0) {
+   rc = usblp_rtest(usblp, nonblock);
+   if (rc < 0) {
mutex_unlock(>mut);
break;
}
@@ -1010,7 +1017,8 @@ static int usblp_submit_read(struct usblp *usblp)
usblp->readcount = 0; /* XXX Why here? */
usblp->rcomplete = 0;
spin_unlock_irqrestore(>lock, flags);
-   if ((rc = usb_submit_urb(urb, GFP_KERNEL)) < 0) {
+   rc = usb_submit_urb(urb, GFP_KERNEL);
+   if (rv < 0) {
dev_dbg(>intf->dev, "error submitting urb (%d)\n", rc);
spin_lock_irqsave(>lock, flags);
usblp->rstatus = rc;
@@ -1123,7 +1131,8 @@ static int usblp_probe(struct usb_interface *intf,
/* Malloc device ID string buffer to the largest expected length,
 * since we can re-query it on an ioctl and a dynamic string
 * could change in length. */
-   if (!(usblp->device_id_string = kmalloc(USBLP_DEVICE_ID_SIZE, 
GFP_KERNEL))) {
+   usblp->device_id_string = kmalloc(USBLP_DEVICE_ID_SIZE, GFP_KERNEL);
+   if (!usblp->device_id_string) {
retval = -ENOMEM;
goto abort;
}
@@ -1133,7 +1142,8 @@ static int usblp_probe(struct usb_interface *intf,
 * malloc both regardless of bidirectionality, because the
 * alternate setting can be changed later via an ioctl.
 */
-   if (!(usblp->readbuf = kmalloc(USBLP_BUF_SIZE_IN, GFP_KERNEL))) {
+   usblp->readbuf = kmalloc(USBLP_BUF_SIZE_IN, GFP_KERNEL);
+   if (!usblp->readbuf) {
retval = -ENOMEM;
goto abort;
}
-- 
2.9.3



[PATCH v5 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

2017-05-12 Thread Baoquan He
In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

Signed-off-by: Baoquan He 
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 15f79c2..60d69aa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2127,6 +2127,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is omitted, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2139,6 +2145,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5



[PATCH v5 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

2017-05-12 Thread Baoquan He
In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

Signed-off-by: Baoquan He 
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 15f79c2..60d69aa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2127,6 +2127,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is omitted, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2139,6 +2145,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5



[PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

2017-05-12 Thread Baoquan He
Option mem= will limit the max address a system can use and any memory
region above the limit will be removed.

Furthermore, memmap=nn[KMG] which has no offset specified has the same
behaviour as mem=.

KASLR needs to consider this when choosing the random position for
decompressing the kernel. Do it now.

Signed-off-by: Baoquan He 
Tested-by: Masayoshi Mizuma 
---
 arch/x86/boot/compressed/kaslr.c | 68 +---
 1 file changed, 50 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 106e13b..e0eba12 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -88,6 +88,10 @@ struct mem_vector {
 static bool memmap_too_large;
 
 
+/* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
+unsigned long long mem_limit = ULLONG_MAX;
+
+
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
MEM_AVOID_INITRD,
@@ -138,16 +142,23 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
return -EINVAL;
 
switch (*p) {
-   case '@':
-   /* Skip this region, usable */
-   *start = 0;
-   *size = 0;
-   return 0;
case '#':
case '$':
case '!':
*start = memparse(p + 1, );
return 0;
+   case '@':
+   /* memmap=nn@ss specifies usable region, should be skipped */
+   *size = 0;
+   /* Fall through */
+   default:
+   /*
+* If w/o offset, only size specified, memmap=nn[KMG] has the
+* same behaviour as mem=nn[KMG]. It limits the max address
+* system can use. Region above the limit should be avoided.
+*/
+   *start = 0;
+   return 0;
}
 
return -EINVAL;
@@ -173,9 +184,14 @@ static void mem_avoid_memmap(char *str)
if (rc < 0)
break;
str = k;
-   /* A usable region that should not be skipped */
-   if (size == 0)
+
+   if (start == 0) {
+   /* Store the specified memory limit if size > 0 */
+   if (size > 0)
+   mem_limit = size;
+
continue;
+   }
 
mem_avoid[MEM_AVOID_MEMMAP_BEGIN + i].start = start;
mem_avoid[MEM_AVOID_MEMMAP_BEGIN + i].size = size;
@@ -187,19 +203,15 @@ static void mem_avoid_memmap(char *str)
memmap_too_large = true;
 }
 
-
-/*
- * handle_mem_memmap will also cover 'mem=' issue in next patch. Will remove
- * this note later.
- */
 static int handle_mem_memmap(void)
 {
char *args = (char *)get_cmd_line_ptr();
size_t len = strlen((char *)args);
char *tmp_cmdline;
char *param, *val;
+   u64 mem_size;
 
-   if (!strstr(args, "memmap="))
+   if (!strstr(args, "memmap=") && !strstr(args, "mem="))
return 0;
 
tmp_cmdline = malloc(len + 1);
@@ -222,8 +234,20 @@ static int handle_mem_memmap(void)
return -1;
}
 
-   if (!strcmp(param, "memmap"))
+   if (!strcmp(param, "memmap")) {
mem_avoid_memmap(val);
+   } else if (!strcmp(param, "mem")) {
+   char *p = val;
+
+   if (!strcmp(p, "nopentium"))
+   continue;
+   mem_size = memparse(p, );
+   if (mem_size == 0) {
+   free(tmp_cmdline);
+   return -EINVAL;
+   }
+   mem_limit = mem_size;
+   }
}
 
free(tmp_cmdline);
@@ -460,7 +484,8 @@ static void process_e820_entry(struct boot_e820_entry 
*entry,
 {
struct mem_vector region, overlap;
struct slot_area slot_area;
-   unsigned long start_orig;
+   unsigned long start_orig, end;
+   struct boot_e820_entry cur_entry;
 
/* Skip non-RAM entries. */
if (entry->type != E820_TYPE_RAM)
@@ -474,8 +499,15 @@ static void process_e820_entry(struct boot_e820_entry 
*entry,
if (entry->addr + entry->size < minimum)
return;
 
-   region.start = entry->addr;
-   region.size = entry->size;
+   /* Ignore entries above memory limit */
+   end = min(entry->size + entry->addr, mem_limit);
+   if (entry->addr >= end)
+   return;
+   cur_entry.addr = entry->addr;
+   cur_entry.size = end - entry->addr;
+
+   region.start = cur_entry.addr;
+   region.size = cur_entry.size;
 
/* Give up if slot area array is full. */
while (slot_area_index < MAX_SLOT_AREA) {
@@ -489,7 +521,7 @@ static 

[PATCH v5 1/3] KASLR: Parse all memmap entries in command line

2017-05-12 Thread Baoquan He
In commit:

  f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")

... the memmap= option is parsed so that KASLR can avoid those reserved
regions. It uses cmdline_find_option() to get the value if memmap=
is specified, however the problem is that cmdline_find_option() can only
find the last entry if multiple memmap entries are provided. This
is not correct.

Address this by checking each command line token for a "memmap=" match
and parse each instance instead of using cmdline_find_option().

Signed-off-by: Baoquan He 
---
 arch/x86/boot/compressed/cmdline.c |   2 +-
 arch/x86/boot/compressed/kaslr.c   | 136 ++---
 arch/x86/boot/string.c |   8 +++
 3 files changed, 91 insertions(+), 55 deletions(-)

diff --git a/arch/x86/boot/compressed/cmdline.c 
b/arch/x86/boot/compressed/cmdline.c
index 73ccf63..9dc1ce6 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -13,7 +13,7 @@ static inline char rdfs8(addr_t addr)
return *((char *)(fs + addr));
 }
 #include "../cmdline.c"
-static unsigned long get_cmd_line_ptr(void)
+unsigned long get_cmd_line_ptr(void)
 {
unsigned long cmd_line_ptr = boot_params->hdr.cmd_line_ptr;
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 54c24f0..106e13b 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -9,16 +9,41 @@
  * contain the entire properly aligned running kernel image.
  *
  */
+
+/*
+ * isspace() in linux/ctype.h is expected by next_args() to filter
+ * out "space/lf/tab". While boot/ctype.h conflicts with linux/ctype.h,
+ * since isdigit() is implemented in both of them. Hence disable it
+ * here.
+ */
+#define BOOT_CTYPE_H
+
+/*
+ * _ctype[] in lib/ctype.c is needed by isspace() of linux/ctype.h.
+ * While both lib/ctype.c and lib/cmdline.c will bring EXPORT_SYMBOL
+ * which is meaningless and will cause compiling error in some cases.
+ * So do not include linux/export.h and define EXPORT_SYMBOL(sym)
+ * as empty.
+ */
+#define _LINUX_EXPORT_H
+#define EXPORT_SYMBOL(sym)
+
 #include "misc.h"
 #include "error.h"
-#include "../boot.h"
 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
+/* Macros used by the included decompressor code below. */
+#define STATIC
+#include 
+
+extern unsigned long get_cmd_line_ptr(void);
+
 /* Simplified build-specific string for starting entropy. */
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
@@ -62,6 +87,7 @@ struct mem_vector {
 
 static bool memmap_too_large;
 
+
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
MEM_AVOID_INITRD,
@@ -85,49 +111,14 @@ static bool mem_overlaps(struct mem_vector *one, struct 
mem_vector *two)
return true;
 }
 
-/**
- * _memparse - Parse a string with mem suffixes into a number
- * @ptr: Where parse begins
- * @retptr: (output) Optional pointer to next char after parse completes
- *
- * Parses a string into a number.  The number stored at @ptr is
- * potentially suffixed with K, M, G, T, P, E.
- */
-static unsigned long long _memparse(const char *ptr, char **retptr)
+char *skip_spaces(const char *str)
 {
-   char *endptr;   /* Local pointer to end of parsed string */
-
-   unsigned long long ret = simple_strtoull(ptr, , 0);
-
-   switch (*endptr) {
-   case 'E':
-   case 'e':
-   ret <<= 10;
-   case 'P':
-   case 'p':
-   ret <<= 10;
-   case 'T':
-   case 't':
-   ret <<= 10;
-   case 'G':
-   case 'g':
-   ret <<= 10;
-   case 'M':
-   case 'm':
-   ret <<= 10;
-   case 'K':
-   case 'k':
-   ret <<= 10;
-   endptr++;
-   default:
-   break;
-   }
-
-   if (retptr)
-   *retptr = endptr;
-
-   return ret;
+   while (isspace(*str))
+   ++str;
+   return (char *)str;
 }
+#include "../../../../lib/ctype.c"
+#include "../../../../lib/cmdline.c"
 
 static int
 parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
@@ -142,7 +133,7 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
return -EINVAL;
 
oldp = p;
-   *size = _memparse(p, );
+   *size = memparse(p, );
if (p == oldp)
return -EINVAL;
 
@@ -155,27 +146,21 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
case '#':
case '$':
case '!':
-   *start = _memparse(p + 1, );
+   *start = memparse(p + 1, );
return 0;
}
 
return -EINVAL;
 }
 
-static void mem_avoid_memmap(void)
+static void mem_avoid_memmap(char *str)
 {
-   char arg[128];
+   static int i;
int rc;
-   int i;
- 

[PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

2017-05-12 Thread Baoquan He
Option mem= will limit the max address a system can use and any memory
region above the limit will be removed.

Furthermore, memmap=nn[KMG] which has no offset specified has the same
behaviour as mem=.

KASLR needs to consider this when choosing the random position for
decompressing the kernel. Do it now.

Signed-off-by: Baoquan He 
Tested-by: Masayoshi Mizuma 
---
 arch/x86/boot/compressed/kaslr.c | 68 +---
 1 file changed, 50 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 106e13b..e0eba12 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -88,6 +88,10 @@ struct mem_vector {
 static bool memmap_too_large;
 
 
+/* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
+unsigned long long mem_limit = ULLONG_MAX;
+
+
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
MEM_AVOID_INITRD,
@@ -138,16 +142,23 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
return -EINVAL;
 
switch (*p) {
-   case '@':
-   /* Skip this region, usable */
-   *start = 0;
-   *size = 0;
-   return 0;
case '#':
case '$':
case '!':
*start = memparse(p + 1, );
return 0;
+   case '@':
+   /* memmap=nn@ss specifies usable region, should be skipped */
+   *size = 0;
+   /* Fall through */
+   default:
+   /*
+* If w/o offset, only size specified, memmap=nn[KMG] has the
+* same behaviour as mem=nn[KMG]. It limits the max address
+* system can use. Region above the limit should be avoided.
+*/
+   *start = 0;
+   return 0;
}
 
return -EINVAL;
@@ -173,9 +184,14 @@ static void mem_avoid_memmap(char *str)
if (rc < 0)
break;
str = k;
-   /* A usable region that should not be skipped */
-   if (size == 0)
+
+   if (start == 0) {
+   /* Store the specified memory limit if size > 0 */
+   if (size > 0)
+   mem_limit = size;
+
continue;
+   }
 
mem_avoid[MEM_AVOID_MEMMAP_BEGIN + i].start = start;
mem_avoid[MEM_AVOID_MEMMAP_BEGIN + i].size = size;
@@ -187,19 +203,15 @@ static void mem_avoid_memmap(char *str)
memmap_too_large = true;
 }
 
-
-/*
- * handle_mem_memmap will also cover 'mem=' issue in next patch. Will remove
- * this note later.
- */
 static int handle_mem_memmap(void)
 {
char *args = (char *)get_cmd_line_ptr();
size_t len = strlen((char *)args);
char *tmp_cmdline;
char *param, *val;
+   u64 mem_size;
 
-   if (!strstr(args, "memmap="))
+   if (!strstr(args, "memmap=") && !strstr(args, "mem="))
return 0;
 
tmp_cmdline = malloc(len + 1);
@@ -222,8 +234,20 @@ static int handle_mem_memmap(void)
return -1;
}
 
-   if (!strcmp(param, "memmap"))
+   if (!strcmp(param, "memmap")) {
mem_avoid_memmap(val);
+   } else if (!strcmp(param, "mem")) {
+   char *p = val;
+
+   if (!strcmp(p, "nopentium"))
+   continue;
+   mem_size = memparse(p, );
+   if (mem_size == 0) {
+   free(tmp_cmdline);
+   return -EINVAL;
+   }
+   mem_limit = mem_size;
+   }
}
 
free(tmp_cmdline);
@@ -460,7 +484,8 @@ static void process_e820_entry(struct boot_e820_entry 
*entry,
 {
struct mem_vector region, overlap;
struct slot_area slot_area;
-   unsigned long start_orig;
+   unsigned long start_orig, end;
+   struct boot_e820_entry cur_entry;
 
/* Skip non-RAM entries. */
if (entry->type != E820_TYPE_RAM)
@@ -474,8 +499,15 @@ static void process_e820_entry(struct boot_e820_entry 
*entry,
if (entry->addr + entry->size < minimum)
return;
 
-   region.start = entry->addr;
-   region.size = entry->size;
+   /* Ignore entries above memory limit */
+   end = min(entry->size + entry->addr, mem_limit);
+   if (entry->addr >= end)
+   return;
+   cur_entry.addr = entry->addr;
+   cur_entry.size = end - entry->addr;
+
+   region.start = cur_entry.addr;
+   region.size = cur_entry.size;
 
/* Give up if slot area array is full. */
while (slot_area_index < MAX_SLOT_AREA) {
@@ -489,7 +521,7 @@ static void process_e820_entry(struct 

[PATCH v5 1/3] KASLR: Parse all memmap entries in command line

2017-05-12 Thread Baoquan He
In commit:

  f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")

... the memmap= option is parsed so that KASLR can avoid those reserved
regions. It uses cmdline_find_option() to get the value if memmap=
is specified, however the problem is that cmdline_find_option() can only
find the last entry if multiple memmap entries are provided. This
is not correct.

Address this by checking each command line token for a "memmap=" match
and parse each instance instead of using cmdline_find_option().

Signed-off-by: Baoquan He 
---
 arch/x86/boot/compressed/cmdline.c |   2 +-
 arch/x86/boot/compressed/kaslr.c   | 136 ++---
 arch/x86/boot/string.c |   8 +++
 3 files changed, 91 insertions(+), 55 deletions(-)

diff --git a/arch/x86/boot/compressed/cmdline.c 
b/arch/x86/boot/compressed/cmdline.c
index 73ccf63..9dc1ce6 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -13,7 +13,7 @@ static inline char rdfs8(addr_t addr)
return *((char *)(fs + addr));
 }
 #include "../cmdline.c"
-static unsigned long get_cmd_line_ptr(void)
+unsigned long get_cmd_line_ptr(void)
 {
unsigned long cmd_line_ptr = boot_params->hdr.cmd_line_ptr;
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 54c24f0..106e13b 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -9,16 +9,41 @@
  * contain the entire properly aligned running kernel image.
  *
  */
+
+/*
+ * isspace() in linux/ctype.h is expected by next_args() to filter
+ * out "space/lf/tab". While boot/ctype.h conflicts with linux/ctype.h,
+ * since isdigit() is implemented in both of them. Hence disable it
+ * here.
+ */
+#define BOOT_CTYPE_H
+
+/*
+ * _ctype[] in lib/ctype.c is needed by isspace() of linux/ctype.h.
+ * While both lib/ctype.c and lib/cmdline.c will bring EXPORT_SYMBOL
+ * which is meaningless and will cause compiling error in some cases.
+ * So do not include linux/export.h and define EXPORT_SYMBOL(sym)
+ * as empty.
+ */
+#define _LINUX_EXPORT_H
+#define EXPORT_SYMBOL(sym)
+
 #include "misc.h"
 #include "error.h"
-#include "../boot.h"
 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
+/* Macros used by the included decompressor code below. */
+#define STATIC
+#include 
+
+extern unsigned long get_cmd_line_ptr(void);
+
 /* Simplified build-specific string for starting entropy. */
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
@@ -62,6 +87,7 @@ struct mem_vector {
 
 static bool memmap_too_large;
 
+
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
MEM_AVOID_INITRD,
@@ -85,49 +111,14 @@ static bool mem_overlaps(struct mem_vector *one, struct 
mem_vector *two)
return true;
 }
 
-/**
- * _memparse - Parse a string with mem suffixes into a number
- * @ptr: Where parse begins
- * @retptr: (output) Optional pointer to next char after parse completes
- *
- * Parses a string into a number.  The number stored at @ptr is
- * potentially suffixed with K, M, G, T, P, E.
- */
-static unsigned long long _memparse(const char *ptr, char **retptr)
+char *skip_spaces(const char *str)
 {
-   char *endptr;   /* Local pointer to end of parsed string */
-
-   unsigned long long ret = simple_strtoull(ptr, , 0);
-
-   switch (*endptr) {
-   case 'E':
-   case 'e':
-   ret <<= 10;
-   case 'P':
-   case 'p':
-   ret <<= 10;
-   case 'T':
-   case 't':
-   ret <<= 10;
-   case 'G':
-   case 'g':
-   ret <<= 10;
-   case 'M':
-   case 'm':
-   ret <<= 10;
-   case 'K':
-   case 'k':
-   ret <<= 10;
-   endptr++;
-   default:
-   break;
-   }
-
-   if (retptr)
-   *retptr = endptr;
-
-   return ret;
+   while (isspace(*str))
+   ++str;
+   return (char *)str;
 }
+#include "../../../../lib/ctype.c"
+#include "../../../../lib/cmdline.c"
 
 static int
 parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
@@ -142,7 +133,7 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
return -EINVAL;
 
oldp = p;
-   *size = _memparse(p, );
+   *size = memparse(p, );
if (p == oldp)
return -EINVAL;
 
@@ -155,27 +146,21 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
case '#':
case '$':
case '!':
-   *start = _memparse(p + 1, );
+   *start = memparse(p + 1, );
return 0;
}
 
return -EINVAL;
 }
 
-static void mem_avoid_memmap(void)
+static void mem_avoid_memmap(char *str)
 {
-   char arg[128];
+   static int i;
int rc;
-   int i;
-   char *str;
 
- 

[PATCH v5 0/3] Handle memmap and mem kernel options in boot stage kaslr

2017-05-12 Thread Baoquan He
People reported kernel panic occurs during system boots up with mem boot option.
After checking code, several problems are found about memmap= and mem= in boot 
stage
kaslr.

*) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only 
one memmap
   entry is considered and only the last one if multiple memmap entries are 
specified.

*) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max 
address
   of system. Kernel can't be randomized to be above the limit.

*) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.

This patchset tries to solve above issues, and it sits on top of
tip:x86/boot branch.

Changelog
v4->v5:
  1. Change patch log according to Thomas's comment.

  2. Put "Fall through" to the right place in parse_memmap() according
  to Kees's suggestion.

 
v3->v4:
  1. Code improved patch 1/3 according to Kees's suggestion.

  2. Add 'Fall through' in switch case of parse_memmap() which
  is suggestd by Kees.

v2->v3:
  No functionality change in this round.
  1. Use local static variable insted of global variable
  mem_avoid_memmap_index in patch 1/3.

  2. Fix a typo in patch 3/3.

v1->v2:
  1. The original patch 1/4 has been put in tip:x86/boot and no update,
  so it's not included in this post.

  2. Use patch log Ingo reorganized.

  3. lib/ctype.c and lib/cmdline.c are needed for kaslr.c, while those
  EXPORT_SYMBOL(x) contained caused failure of build on 32-bit allmodconfig:
  ..
  ld: -r and -shared may not be used together
  scripts/Makefile.build:294: recipe for target 
'arch/x86/boot/compressed/kaslr.o' failed
  ..
  Disabling the symbol exporting removes the build failure.

  4. Use dynamic allocation to allocate memory to contain copied kernel cmdline
  buffer, it's implemented in include/linux/decompress/mm.h.

Baoquan He (3):
  KASLR: Parse all memmap entries in command line
  KASLR: Handle memory limit specified by memmap and mem option
  Documentation/kernel-parameters.txt: Update 'memmap=' option
description

 Documentation/admin-guide/kernel-parameters.txt |   9 ++
 arch/x86/boot/compressed/cmdline.c  |   2 +-
 arch/x86/boot/compressed/kaslr.c| 190 
 arch/x86/boot/string.c  |   8 +
 4 files changed, 143 insertions(+), 66 deletions(-)

-- 
2.5.5



[PATCH v5 0/3] Handle memmap and mem kernel options in boot stage kaslr

2017-05-12 Thread Baoquan He
People reported kernel panic occurs during system boots up with mem boot option.
After checking code, several problems are found about memmap= and mem= in boot 
stage
kaslr.

*) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only 
one memmap
   entry is considered and only the last one if multiple memmap entries are 
specified.

*) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max 
address
   of system. Kernel can't be randomized to be above the limit.

*) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.

This patchset tries to solve above issues, and it sits on top of
tip:x86/boot branch.

Changelog
v4->v5:
  1. Change patch log according to Thomas's comment.

  2. Put "Fall through" to the right place in parse_memmap() according
  to Kees's suggestion.

 
v3->v4:
  1. Code improved patch 1/3 according to Kees's suggestion.

  2. Add 'Fall through' in switch case of parse_memmap() which
  is suggestd by Kees.

v2->v3:
  No functionality change in this round.
  1. Use local static variable insted of global variable
  mem_avoid_memmap_index in patch 1/3.

  2. Fix a typo in patch 3/3.

v1->v2:
  1. The original patch 1/4 has been put in tip:x86/boot and no update,
  so it's not included in this post.

  2. Use patch log Ingo reorganized.

  3. lib/ctype.c and lib/cmdline.c are needed for kaslr.c, while those
  EXPORT_SYMBOL(x) contained caused failure of build on 32-bit allmodconfig:
  ..
  ld: -r and -shared may not be used together
  scripts/Makefile.build:294: recipe for target 
'arch/x86/boot/compressed/kaslr.o' failed
  ..
  Disabling the symbol exporting removes the build failure.

  4. Use dynamic allocation to allocate memory to contain copied kernel cmdline
  buffer, it's implemented in include/linux/decompress/mm.h.

Baoquan He (3):
  KASLR: Parse all memmap entries in command line
  KASLR: Handle memory limit specified by memmap and mem option
  Documentation/kernel-parameters.txt: Update 'memmap=' option
description

 Documentation/admin-guide/kernel-parameters.txt |   9 ++
 arch/x86/boot/compressed/cmdline.c  |   2 +-
 arch/x86/boot/compressed/kaslr.c| 190 
 arch/x86/boot/string.c  |   8 +
 4 files changed, 143 insertions(+), 66 deletions(-)

-- 
2.5.5



Re: [PATCH v2] Add "shutdown" to "struct class".

2017-05-12 Thread Greg Kroah-Hartman
On Fri, May 12, 2017 at 04:38:31PM -0700, Josh Zimmerman wrote:
> The TPM class has some common shutdown code that must be executed for
> all drivers. This adds some needed functionality for that.
> 
> (In addition, update a comment to reflect an out-of-date path.)

Change that in a different patch please.

> 
> Signed-off-by: Josh Zimmerman 
> ---

What changed from v1?  Always put that below here.

And if you can also show how this will be used, that would be great, I
don't want to add new apis with no users.

thanks,

greg k-h


Re: [PATCH v2] Add "shutdown" to "struct class".

2017-05-12 Thread Greg Kroah-Hartman
On Fri, May 12, 2017 at 04:38:31PM -0700, Josh Zimmerman wrote:
> The TPM class has some common shutdown code that must be executed for
> all drivers. This adds some needed functionality for that.
> 
> (In addition, update a comment to reflect an out-of-date path.)

Change that in a different patch please.

> 
> Signed-off-by: Josh Zimmerman 
> ---

What changed from v1?  Always put that below here.

And if you can also show how this will be used, that would be great, I
don't want to add new apis with no users.

thanks,

greg k-h


Re: depmod gets stuck in symlink cycle in arch/arm/boot/dts/include

2017-05-12 Thread Yauheni Kaliuta
Hi, Omar!

> On Fri, 12 May 2017 15:23:07 -0700, Omar Sandoval  wrote:

 > Hi,
 > Linux kernel commit 4027494ae6e3 ("ARM: dts: add arm/arm64 include
 > symlinks") introduced a couple of symlink cycles:

 > $ ls -al arch/arm{,64}/boot/dts/include
 > arch/arm64/boot/dts/include:
 > total 12
 > drwxr-xr-x 1 osandov users  38 May 11 14:01 .
 > drwxr-xr-x 1 osandov users 320 Jan 25 20:44 ..
 > lrwxrwxrwx 1 osandov users  24 May 11 14:01 arm -> ../../../../arm/boot/dts
 > lrwxrwxrwx 1 osandov users   2 May 11 14:01 arm64 -> ..
 > lrwxrwxrwx 1 osandov users 34 Nov 23 12:07 dt-bindings ->
 > ../../../../../include/dt-bindings

 > arch/arm/boot/dts/include:
 > total 12
 > drwxr-xr-x 1 osandov users38 May 11 14:01 .
 > drwxr-xr-x 1 osandov users 63102 May 11 14:01 ..
 > lrwxrwxrwx 1 osandov users 2 May 11 14:01 arm -> ..
 > lrwxrwxrwx 1 osandov users26 May 11 14:01 arm64 -> 
 > ../../../../arm64/boot/dts
 > lrwxrwxrwx 1 osandov users 34 Nov 23 12:07 dt-bindings ->
 > ../../../../../include/dt-bindings

 > On my system, /lib/modules/$(uname -r)/kernel is a symlink to
 > /lib/modules/$(uname -r)/build, which is my built linux.git. depmod
 > doesn't like these symlink cycles and ends up in an infinite loop.

 > Maybe I shouldn't be symlinking kernel to build like this, but depmod
 > shouldn't be getting stuck like this either. I wonder if anything else
 > is going to barf on these symlink cycles, too.

depmod checks for special names "build" and "source" to skip them.

I wonder if it worth to implement full symlink loop check.

-- 
WBR,
Yauheni Kaliuta


Re: depmod gets stuck in symlink cycle in arch/arm/boot/dts/include

2017-05-12 Thread Yauheni Kaliuta
Hi, Omar!

> On Fri, 12 May 2017 15:23:07 -0700, Omar Sandoval  wrote:

 > Hi,
 > Linux kernel commit 4027494ae6e3 ("ARM: dts: add arm/arm64 include
 > symlinks") introduced a couple of symlink cycles:

 > $ ls -al arch/arm{,64}/boot/dts/include
 > arch/arm64/boot/dts/include:
 > total 12
 > drwxr-xr-x 1 osandov users  38 May 11 14:01 .
 > drwxr-xr-x 1 osandov users 320 Jan 25 20:44 ..
 > lrwxrwxrwx 1 osandov users  24 May 11 14:01 arm -> ../../../../arm/boot/dts
 > lrwxrwxrwx 1 osandov users   2 May 11 14:01 arm64 -> ..
 > lrwxrwxrwx 1 osandov users 34 Nov 23 12:07 dt-bindings ->
 > ../../../../../include/dt-bindings

 > arch/arm/boot/dts/include:
 > total 12
 > drwxr-xr-x 1 osandov users38 May 11 14:01 .
 > drwxr-xr-x 1 osandov users 63102 May 11 14:01 ..
 > lrwxrwxrwx 1 osandov users 2 May 11 14:01 arm -> ..
 > lrwxrwxrwx 1 osandov users26 May 11 14:01 arm64 -> 
 > ../../../../arm64/boot/dts
 > lrwxrwxrwx 1 osandov users 34 Nov 23 12:07 dt-bindings ->
 > ../../../../../include/dt-bindings

 > On my system, /lib/modules/$(uname -r)/kernel is a symlink to
 > /lib/modules/$(uname -r)/build, which is my built linux.git. depmod
 > doesn't like these symlink cycles and ends up in an infinite loop.

 > Maybe I shouldn't be symlinking kernel to build like this, but depmod
 > shouldn't be getting stuck like this either. I wonder if anything else
 > is going to barf on these symlink cycles, too.

depmod checks for special names "build" and "source" to skip them.

I wonder if it worth to implement full symlink loop check.

-- 
WBR,
Yauheni Kaliuta


[PATCH] lightnvm: pblk: fix bad free seq. on error path

2017-05-12 Thread Javier González
Braces around the error patch for metadata pre-allocation are wrongly
placed. This causes a memory leak in case of a memory allocation
failure. Fix it

Signed-off-by: Javier González 
---
 drivers/lightnvm/pblk-init.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index ae8cd6d5af8b..a2ee875aede3 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -604,12 +604,12 @@ static int pblk_lines_init(struct pblk *pblk)
l_mg->smeta_alloc_type = PBLK_KMALLOC_META;
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->sline_meta[i].meta = kmalloc(lm->smeta_len, GFP_KERNEL);
-   if (!l_mg->sline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->sline_meta[i].meta) {
+   while (--i >= 0)
kfree(l_mg->sline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail;
+   }
}
 
if (lm->emeta_len > KMALLOC_MAX_CACHE_SIZE) {
@@ -617,12 +617,12 @@ static int pblk_lines_init(struct pblk *pblk)
 
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->eline_meta[i].meta = vmalloc(lm->emeta_len);
-   if (!l_mg->eline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->eline_meta[i].meta) {
+   while (--i >= 0)
vfree(l_mg->eline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail_free_meta;
+   }
}
} else {
l_mg->emeta_alloc_type = PBLK_KMALLOC_META;
@@ -630,12 +630,12 @@ static int pblk_lines_init(struct pblk *pblk)
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->eline_meta[i].meta =
kmalloc(lm->emeta_len, GFP_KERNEL);
-   if (!l_mg->eline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->eline_meta[i].meta) {
+   while (--i >= 0)
kfree(l_mg->eline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail_free_meta;
+   }
}
}
 
-- 
2.7.4



[PATCH] lightnvm: pblk: fix bad free seq. on error path

2017-05-12 Thread Javier González
Braces around the error patch for metadata pre-allocation are wrongly
placed. This causes a memory leak in case of a memory allocation
failure. Fix it

Signed-off-by: Javier González 
---
 drivers/lightnvm/pblk-init.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index ae8cd6d5af8b..a2ee875aede3 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -604,12 +604,12 @@ static int pblk_lines_init(struct pblk *pblk)
l_mg->smeta_alloc_type = PBLK_KMALLOC_META;
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->sline_meta[i].meta = kmalloc(lm->smeta_len, GFP_KERNEL);
-   if (!l_mg->sline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->sline_meta[i].meta) {
+   while (--i >= 0)
kfree(l_mg->sline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail;
+   }
}
 
if (lm->emeta_len > KMALLOC_MAX_CACHE_SIZE) {
@@ -617,12 +617,12 @@ static int pblk_lines_init(struct pblk *pblk)
 
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->eline_meta[i].meta = vmalloc(lm->emeta_len);
-   if (!l_mg->eline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->eline_meta[i].meta) {
+   while (--i >= 0)
vfree(l_mg->eline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail_free_meta;
+   }
}
} else {
l_mg->emeta_alloc_type = PBLK_KMALLOC_META;
@@ -630,12 +630,12 @@ static int pblk_lines_init(struct pblk *pblk)
for (i = 0; i < PBLK_DATA_LINES; i++) {
l_mg->eline_meta[i].meta =
kmalloc(lm->emeta_len, GFP_KERNEL);
-   if (!l_mg->eline_meta[i].meta)
-   while (--i >= 0) {
+   if (!l_mg->eline_meta[i].meta) {
+   while (--i >= 0)
kfree(l_mg->eline_meta[i].meta);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   ret = -ENOMEM;
+   goto fail_free_meta;
+   }
}
}
 
-- 
2.7.4



Re: Is there an recommended way to refer to bitkeepr commits?

2017-05-12 Thread Eric W. Biederman
Rob Landley  writes:

> On 05/12/2017 09:45 AM, Eric W. Biederman wrote:
>> Thomas Gleixner  writes:
>> 
>>> On Fri, 12 May 2017, Michael Ellerman wrote:
   Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] 
 linux-2.5.66-signal-cleanup.patch")

 In your tree that is c3c107051660 ("[PATCH] 
 linux-2.5.66-signal-cleanup.patch"),
 but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision recorded
 anywhere that I can see.
>>>
>>> That's correct. I did not include the BK revisions when I imported the
>>> commits into the history git. I did not see any reason to do so. I still
>>> have no idea what the value would have been or why anyone wants to
>>> reference them at all.
>> 
>> Thomas your import seems to be significantly better than the one I got
>> my hands on years ago.
>> 
>> I just know that if were to do something similar today we would really
>> want to preserve the existing git sha1 hashes somewhere because we
>> refer to commits everywhere in the code.
>
> Which is why the https://landley.net/kdocs/fullhist tree uses "git
> graft", so the git commit numbers are the same.
>
> As Yoann Padioleau said:
>
>> It's built from 3 other git repositories:
>>  - the one from Dave Jones from 0.01 to 2.4.0,
>>  - the one from tglx from 2.4.0 to 2.6.12,
>>  - the one from Linus Torvalds from 2.6.12 to now.
>
> And the hashes in his tree were the same as in each of those trees, all
> three of which are on git.kernel.org. If you "git pull" the fullhist
> tree to current, it still uses the same hashes today. (I think you can
> still reproduce it localy using his scripts, which I mirrored. You'll
> have to manually re-tag those old commits from last message, and reset
> the "upstream" to pull current from.)

Which leaves me perplexed.  The hashes from tglx's current tree:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
on kernel.org and the hashes in your full history tree differ.
Given that they are in theory the same tree this distrubs me.

Case in point in the commit connected to:
"[PATCH] linux-2.5.66-signal-cleanup.patch"
in tglx's tree is:   da334d91ff7001d234863fc7692de1ff90bed57a
in the fullhist tree is: c3c107051660455a3e1ea3bde0278a75a0dc11e7

>> Compare the quotes lines above with what I have below.  Every tree
>> appears to have a different identifier.
>
> The commits in the fullhist tree have been stable since at least
> https://lwn.net/Articles/285366/ which was June 6, 2008. It's derived
> from earlier trees with the same commits, and kept those commit
> hashes.

*scratches my head*

Something appears to have changed somewhere.

Eric




Re: Is there an recommended way to refer to bitkeepr commits?

2017-05-12 Thread Eric W. Biederman
Rob Landley  writes:

> On 05/12/2017 09:45 AM, Eric W. Biederman wrote:
>> Thomas Gleixner  writes:
>> 
>>> On Fri, 12 May 2017, Michael Ellerman wrote:
   Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] 
 linux-2.5.66-signal-cleanup.patch")

 In your tree that is c3c107051660 ("[PATCH] 
 linux-2.5.66-signal-cleanup.patch"),
 but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision recorded
 anywhere that I can see.
>>>
>>> That's correct. I did not include the BK revisions when I imported the
>>> commits into the history git. I did not see any reason to do so. I still
>>> have no idea what the value would have been or why anyone wants to
>>> reference them at all.
>> 
>> Thomas your import seems to be significantly better than the one I got
>> my hands on years ago.
>> 
>> I just know that if were to do something similar today we would really
>> want to preserve the existing git sha1 hashes somewhere because we
>> refer to commits everywhere in the code.
>
> Which is why the https://landley.net/kdocs/fullhist tree uses "git
> graft", so the git commit numbers are the same.
>
> As Yoann Padioleau said:
>
>> It's built from 3 other git repositories:
>>  - the one from Dave Jones from 0.01 to 2.4.0,
>>  - the one from tglx from 2.4.0 to 2.6.12,
>>  - the one from Linus Torvalds from 2.6.12 to now.
>
> And the hashes in his tree were the same as in each of those trees, all
> three of which are on git.kernel.org. If you "git pull" the fullhist
> tree to current, it still uses the same hashes today. (I think you can
> still reproduce it localy using his scripts, which I mirrored. You'll
> have to manually re-tag those old commits from last message, and reset
> the "upstream" to pull current from.)

Which leaves me perplexed.  The hashes from tglx's current tree:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
on kernel.org and the hashes in your full history tree differ.
Given that they are in theory the same tree this distrubs me.

Case in point in the commit connected to:
"[PATCH] linux-2.5.66-signal-cleanup.patch"
in tglx's tree is:   da334d91ff7001d234863fc7692de1ff90bed57a
in the fullhist tree is: c3c107051660455a3e1ea3bde0278a75a0dc11e7

>> Compare the quotes lines above with what I have below.  Every tree
>> appears to have a different identifier.
>
> The commits in the fullhist tree have been stable since at least
> https://lwn.net/Articles/285366/ which was June 6, 2008. It's derived
> from earlier trees with the same commits, and kept those commit
> hashes.

*scratches my head*

Something appears to have changed somewhere.

Eric




[PATCH v3] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

2017-05-12 Thread Baoquan He
For EFI with 'efi=old_map' kernel option specified, Kernel will panic
when kaslr is enabled.

The back trace is:

BUG: unable to handle kernel paging request at 7febd57e
IP: 0x7febd57e
PGD 1025a067
PUD 0

Oops: 0010 [#1] SMP
[ ... ]
Call Trace:
 ? efi_call+0x58/0x90
 ? printk+0x58/0x6f
 efi_enter_virtual_mode+0x3c5/0x50d
 start_kernel+0x40f/0x4b8
 ? set_init_arg+0x55/0x55
 ? early_idt_handler_array+0x120/0x120
 x86_64_start_reservations+0x24/0x26
 x86_64_start_kernel+0x14c/0x16f
 start_cpu+0x14/0x14

The root cause is the ident mapping is not built correctly in old_map case.

For nokaslr kernel, PAGE_OFFSET is 0x8800 which is PGDIR_SIZE
aligned. We can borrow the pud table from direct mapping safely. Given a
physical address X, we have pud_index(X) == pud_index(__va(X)). However,
for kaslr kernel, PAGE_OFFSET is PUD_SIZE aligned. For a given physical
address X, pud_index(X) != pud_index(__va(X)). We can't only copy pgd entry
from direct mapping to build ident mapping, instead need copy pud entry
one by one from direct mapping.

Fix it.

Signed-off-by: Baoquan He 
Signed-off-by: Dave Young 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Thomas Garnier 
Cc: Kees Cook 
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
v2->v3:
1. Rewrite code to copy pud entry one by one so that code can be understood
better. Usually we only have less than 1TB or several TB memory, pud entry
copy one by one won't impact efficiency.

2. Adding p4d page table handling.

v1->v2:
Change code and add description according to Thomas's suggestion as below:

1. Add checking if pud table is allocated successfully. If not just break
the for loop.

2. Add code comment to explain how the 1:1 mapping is built in 
efi_call_phys_prolog

3. Other minor change

 arch/x86/platform/efi/efi_64.c | 69 +-
 1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c488625..c9dffec 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -71,11 +71,13 @@ static void __init early_code_mapping_set_exec(int 
executable)
 
 pgd_t * __init efi_call_phys_prolog(void)
 {
-   unsigned long vaddress;
-   pgd_t *save_pgd;
+   unsigned long vaddr, addr_pgd, addr_p4d, addr_pud;
+   pgd_t *save_pgd, *pgd_k, *pgd_efi;
+   p4d_t *p4d, *p4d_k, *p4d_efi;
+   pud_t *pud;
 
int pgd;
-   int n_pgds;
+   int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
save_pgd = (pgd_t *)read_cr3();
@@ -88,10 +90,44 @@ pgd_t * __init efi_call_phys_prolog(void)
n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
save_pgd = kmalloc_array(n_pgds, sizeof(*save_pgd), GFP_KERNEL);
 
+   /*
+* Build 1:1 ident mapping for old_map usage. It needs to be noticed
+* that PAGE_OFFSET is PGDIR_SIZE aligned with KASLR disabled, while
+* PUD_SIZE ALIGNED with KASLR enabled. So for a given physical
+* address X, the pud_index(X) != pud_index(__va(X)), we can only copy
+* pud entry of __va(X) to fill in pud entry of X to build 1:1 mapping
+* . Means here we can only reuse pmd table of direct mapping.
+*/
for (pgd = 0; pgd < n_pgds; pgd++) {
-   save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
-   vaddress = (unsigned long)__va(pgd * PGDIR_SIZE);
-   set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), 
*pgd_offset_k(vaddress));
+   addr_pgd = (unsigned long)(pgd * PGDIR_SIZE);
+   vaddr = (unsigned long)__va(pgd * PGDIR_SIZE);
+   pgd_efi = pgd_offset_k(addr_pgd);
+   save_pgd[pgd] = *pgd_efi;
+   p4d =  p4d_alloc(_mm, pgd_efi, addr_pgd);
+
+   if (!p4d) {
+   pr_err("Failed to allocate p4d table \n");
+   goto out;
+   }
+   for(i=0; i (max_pfn << PAGE_SHIFT))
+   break;
+   vaddr = (unsigned long)__va(addr_pud);
+
+   

[PATCH v3] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

2017-05-12 Thread Baoquan He
For EFI with 'efi=old_map' kernel option specified, Kernel will panic
when kaslr is enabled.

The back trace is:

BUG: unable to handle kernel paging request at 7febd57e
IP: 0x7febd57e
PGD 1025a067
PUD 0

Oops: 0010 [#1] SMP
[ ... ]
Call Trace:
 ? efi_call+0x58/0x90
 ? printk+0x58/0x6f
 efi_enter_virtual_mode+0x3c5/0x50d
 start_kernel+0x40f/0x4b8
 ? set_init_arg+0x55/0x55
 ? early_idt_handler_array+0x120/0x120
 x86_64_start_reservations+0x24/0x26
 x86_64_start_kernel+0x14c/0x16f
 start_cpu+0x14/0x14

The root cause is the ident mapping is not built correctly in old_map case.

For nokaslr kernel, PAGE_OFFSET is 0x8800 which is PGDIR_SIZE
aligned. We can borrow the pud table from direct mapping safely. Given a
physical address X, we have pud_index(X) == pud_index(__va(X)). However,
for kaslr kernel, PAGE_OFFSET is PUD_SIZE aligned. For a given physical
address X, pud_index(X) != pud_index(__va(X)). We can't only copy pgd entry
from direct mapping to build ident mapping, instead need copy pud entry
one by one from direct mapping.

Fix it.

Signed-off-by: Baoquan He 
Signed-off-by: Dave Young 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Thomas Garnier 
Cc: Kees Cook 
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
v2->v3:
1. Rewrite code to copy pud entry one by one so that code can be understood
better. Usually we only have less than 1TB or several TB memory, pud entry
copy one by one won't impact efficiency.

2. Adding p4d page table handling.

v1->v2:
Change code and add description according to Thomas's suggestion as below:

1. Add checking if pud table is allocated successfully. If not just break
the for loop.

2. Add code comment to explain how the 1:1 mapping is built in 
efi_call_phys_prolog

3. Other minor change

 arch/x86/platform/efi/efi_64.c | 69 +-
 1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c488625..c9dffec 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -71,11 +71,13 @@ static void __init early_code_mapping_set_exec(int 
executable)
 
 pgd_t * __init efi_call_phys_prolog(void)
 {
-   unsigned long vaddress;
-   pgd_t *save_pgd;
+   unsigned long vaddr, addr_pgd, addr_p4d, addr_pud;
+   pgd_t *save_pgd, *pgd_k, *pgd_efi;
+   p4d_t *p4d, *p4d_k, *p4d_efi;
+   pud_t *pud;
 
int pgd;
-   int n_pgds;
+   int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
save_pgd = (pgd_t *)read_cr3();
@@ -88,10 +90,44 @@ pgd_t * __init efi_call_phys_prolog(void)
n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
save_pgd = kmalloc_array(n_pgds, sizeof(*save_pgd), GFP_KERNEL);
 
+   /*
+* Build 1:1 ident mapping for old_map usage. It needs to be noticed
+* that PAGE_OFFSET is PGDIR_SIZE aligned with KASLR disabled, while
+* PUD_SIZE ALIGNED with KASLR enabled. So for a given physical
+* address X, the pud_index(X) != pud_index(__va(X)), we can only copy
+* pud entry of __va(X) to fill in pud entry of X to build 1:1 mapping
+* . Means here we can only reuse pmd table of direct mapping.
+*/
for (pgd = 0; pgd < n_pgds; pgd++) {
-   save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
-   vaddress = (unsigned long)__va(pgd * PGDIR_SIZE);
-   set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), 
*pgd_offset_k(vaddress));
+   addr_pgd = (unsigned long)(pgd * PGDIR_SIZE);
+   vaddr = (unsigned long)__va(pgd * PGDIR_SIZE);
+   pgd_efi = pgd_offset_k(addr_pgd);
+   save_pgd[pgd] = *pgd_efi;
+   p4d =  p4d_alloc(_mm, pgd_efi, addr_pgd);
+
+   if (!p4d) {
+   pr_err("Failed to allocate p4d table \n");
+   goto out;
+   }
+   for(i=0; i (max_pfn << PAGE_SHIFT))
+   break;
+   vaddr = (unsigned long)__va(addr_pud);
+
+   pgd_k = pgd_offset_k(vaddr);
+   p4d_k = p4d_offset(pgd_k, vaddr);
+   pud[j] = *pud_offset(p4d_k, vaddr);
+   }
+   }
}
 out:
__flush_tlb_all();
@@ -104,8 +140,11 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
/*
 * After the lock is released, the original page table is restored.
 */
-   int pgd_idx;
+   int pgd_idx, i;
int nr_pgds;
+   pgd_t *pgd;
+p4d_t *p4d;
+pud_t *pud;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
write_cr3((unsigned long)save_pgd);
@@ -115,9 +154,23 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
 
nr_pgds = 

[PATCH] devicetree: Move include prefixes from arch to separate directory

2017-05-12 Thread Olof Johansson
We use a directory under arch/$ARCH/boot/dts as an include path
that has links outside of the subtree to find dt-bindings from under
include/dt-bindings. That's been working well, but new DT architectures
haven't been adding them by default.

Recently there's been a desire to share some of the DT material between
arm and arm64, which originally caused developers to create symlinks or
relative includes between the subtrees. This isn't ideal -- it breaks
if the DT files aren't stored in the exact same hierarchy as the kernel
tree, and generally it's just icky.

As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
once, and allow DTS files to reference dtsi (and dts) files in other
architectures that way.

Original approach was to create these links under each architecture,
but it lead to the problem of recursive symlinks.

As a remedy, move the include link directories out of the architecture
trees into a common location. At the same time, they can now share one
directory and one dt-bindings/ link as well.

Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
Reported-by: Russell King 
Reported-by: Omar Sandoval 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Frank Rowand 
Cc: linux-arch 
Signed-off-by: Olof Johansson 
---
 arch/arm/boot/dts/include/arm | 1 -
 arch/arm/boot/dts/include/arm64   | 1 -
 arch/arm/boot/dts/include/dt-bindings | 1 -
 arch/arm64/boot/dts/include/arm   | 1 -
 arch/arm64/boot/dts/include/arm64 | 1 -
 arch/arm64/boot/dts/include/dt-bindings   | 1 -
 arch/cris/boot/dts/include/dt-bindings| 1 -
 arch/metag/boot/dts/include/dt-bindings   | 1 -
 arch/mips/boot/dts/include/dt-bindings| 1 -
 arch/powerpc/boot/dts/include/dt-bindings | 1 -
 scripts/Makefile.lib  | 2 +-
 scripts/dtc/include-prefixes/arc  | 1 +
 scripts/dtc/include-prefixes/arm  | 1 +
 scripts/dtc/include-prefixes/arm64| 1 +
 scripts/dtc/include-prefixes/c6x  | 1 +
 scripts/dtc/include-prefixes/cris | 1 +
 scripts/dtc/include-prefixes/dt-bindings  | 1 +
 scripts/dtc/include-prefixes/h8300| 1 +
 scripts/dtc/include-prefixes/metag| 1 +
 scripts/dtc/include-prefixes/microblaze   | 1 +
 scripts/dtc/include-prefixes/mips | 1 +
 scripts/dtc/include-prefixes/nios2| 1 +
 scripts/dtc/include-prefixes/openrisc | 1 +
 scripts/dtc/include-prefixes/powerpc  | 1 +
 scripts/dtc/include-prefixes/sh   | 1 +
 scripts/dtc/include-prefixes/xtensa   | 1 +
 26 files changed, 16 insertions(+), 11 deletions(-)
 delete mode 12 arch/arm/boot/dts/include/arm
 delete mode 12 arch/arm/boot/dts/include/arm64
 delete mode 12 arch/arm/boot/dts/include/dt-bindings
 delete mode 12 arch/arm64/boot/dts/include/arm
 delete mode 12 arch/arm64/boot/dts/include/arm64
 delete mode 12 arch/arm64/boot/dts/include/dt-bindings
 delete mode 12 arch/cris/boot/dts/include/dt-bindings
 delete mode 12 arch/metag/boot/dts/include/dt-bindings
 delete mode 12 arch/mips/boot/dts/include/dt-bindings
 delete mode 12 arch/powerpc/boot/dts/include/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/arc
 create mode 12 scripts/dtc/include-prefixes/arm
 create mode 12 scripts/dtc/include-prefixes/arm64
 create mode 12 scripts/dtc/include-prefixes/c6x
 create mode 12 scripts/dtc/include-prefixes/cris
 create mode 12 scripts/dtc/include-prefixes/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/h8300
 create mode 12 scripts/dtc/include-prefixes/metag
 create mode 12 scripts/dtc/include-prefixes/microblaze
 create mode 12 scripts/dtc/include-prefixes/mips
 create mode 12 scripts/dtc/include-prefixes/nios2
 create mode 12 scripts/dtc/include-prefixes/openrisc
 create mode 12 scripts/dtc/include-prefixes/powerpc
 create mode 12 scripts/dtc/include-prefixes/sh
 create mode 12 scripts/dtc/include-prefixes/xtensa

diff --git a/arch/arm/boot/dts/include/arm b/arch/arm/boot/dts/include/arm
deleted file mode 12
index a96aa0e..000
--- a/arch/arm/boot/dts/include/arm
+++ /dev/null
@@ -1 +0,0 @@
-..
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/arm64 b/arch/arm/boot/dts/include/arm64
deleted file mode 12
index 074a835..000
--- a/arch/arm/boot/dts/include/arm64
+++ 

[PATCH] devicetree: Move include prefixes from arch to separate directory

2017-05-12 Thread Olof Johansson
We use a directory under arch/$ARCH/boot/dts as an include path
that has links outside of the subtree to find dt-bindings from under
include/dt-bindings. That's been working well, but new DT architectures
haven't been adding them by default.

Recently there's been a desire to share some of the DT material between
arm and arm64, which originally caused developers to create symlinks or
relative includes between the subtrees. This isn't ideal -- it breaks
if the DT files aren't stored in the exact same hierarchy as the kernel
tree, and generally it's just icky.

As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
once, and allow DTS files to reference dtsi (and dts) files in other
architectures that way.

Original approach was to create these links under each architecture,
but it lead to the problem of recursive symlinks.

As a remedy, move the include link directories out of the architecture
trees into a common location. At the same time, they can now share one
directory and one dt-bindings/ link as well.

Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
Reported-by: Russell King 
Reported-by: Omar Sandoval 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Frank Rowand 
Cc: linux-arch 
Signed-off-by: Olof Johansson 
---
 arch/arm/boot/dts/include/arm | 1 -
 arch/arm/boot/dts/include/arm64   | 1 -
 arch/arm/boot/dts/include/dt-bindings | 1 -
 arch/arm64/boot/dts/include/arm   | 1 -
 arch/arm64/boot/dts/include/arm64 | 1 -
 arch/arm64/boot/dts/include/dt-bindings   | 1 -
 arch/cris/boot/dts/include/dt-bindings| 1 -
 arch/metag/boot/dts/include/dt-bindings   | 1 -
 arch/mips/boot/dts/include/dt-bindings| 1 -
 arch/powerpc/boot/dts/include/dt-bindings | 1 -
 scripts/Makefile.lib  | 2 +-
 scripts/dtc/include-prefixes/arc  | 1 +
 scripts/dtc/include-prefixes/arm  | 1 +
 scripts/dtc/include-prefixes/arm64| 1 +
 scripts/dtc/include-prefixes/c6x  | 1 +
 scripts/dtc/include-prefixes/cris | 1 +
 scripts/dtc/include-prefixes/dt-bindings  | 1 +
 scripts/dtc/include-prefixes/h8300| 1 +
 scripts/dtc/include-prefixes/metag| 1 +
 scripts/dtc/include-prefixes/microblaze   | 1 +
 scripts/dtc/include-prefixes/mips | 1 +
 scripts/dtc/include-prefixes/nios2| 1 +
 scripts/dtc/include-prefixes/openrisc | 1 +
 scripts/dtc/include-prefixes/powerpc  | 1 +
 scripts/dtc/include-prefixes/sh   | 1 +
 scripts/dtc/include-prefixes/xtensa   | 1 +
 26 files changed, 16 insertions(+), 11 deletions(-)
 delete mode 12 arch/arm/boot/dts/include/arm
 delete mode 12 arch/arm/boot/dts/include/arm64
 delete mode 12 arch/arm/boot/dts/include/dt-bindings
 delete mode 12 arch/arm64/boot/dts/include/arm
 delete mode 12 arch/arm64/boot/dts/include/arm64
 delete mode 12 arch/arm64/boot/dts/include/dt-bindings
 delete mode 12 arch/cris/boot/dts/include/dt-bindings
 delete mode 12 arch/metag/boot/dts/include/dt-bindings
 delete mode 12 arch/mips/boot/dts/include/dt-bindings
 delete mode 12 arch/powerpc/boot/dts/include/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/arc
 create mode 12 scripts/dtc/include-prefixes/arm
 create mode 12 scripts/dtc/include-prefixes/arm64
 create mode 12 scripts/dtc/include-prefixes/c6x
 create mode 12 scripts/dtc/include-prefixes/cris
 create mode 12 scripts/dtc/include-prefixes/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/h8300
 create mode 12 scripts/dtc/include-prefixes/metag
 create mode 12 scripts/dtc/include-prefixes/microblaze
 create mode 12 scripts/dtc/include-prefixes/mips
 create mode 12 scripts/dtc/include-prefixes/nios2
 create mode 12 scripts/dtc/include-prefixes/openrisc
 create mode 12 scripts/dtc/include-prefixes/powerpc
 create mode 12 scripts/dtc/include-prefixes/sh
 create mode 12 scripts/dtc/include-prefixes/xtensa

diff --git a/arch/arm/boot/dts/include/arm b/arch/arm/boot/dts/include/arm
deleted file mode 12
index a96aa0e..000
--- a/arch/arm/boot/dts/include/arm
+++ /dev/null
@@ -1 +0,0 @@
-..
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/arm64 b/arch/arm/boot/dts/include/arm64
deleted file mode 12
index 074a835..000
--- a/arch/arm/boot/dts/include/arm64
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm64/boot/dts
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/dt-bindings 
b/arch/arm/boot/dts/include/dt-bindings
deleted file mode 12
index 08c00e4..000
--- a/arch/arm/boot/dts/include/dt-bindings
+++ /dev/null
@@ -1 +0,0 @@
-../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/include/arm 

Re: [v6 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

2017-05-12 Thread Geetha Akula
On Sat, May 13, 2017 at 6:03 AM, kbuild test robot <l...@intel.com> wrote:
> Hi Linu,
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on v4.11 next-20170512]
> [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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> for-next/core
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>drivers/acpi/arm64/iort.c: In function 'arm_smmu_v3_init_resources':
>>> drivers/acpi/arm64/iort.c:777:21: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>>> undeclared (first use in this function)
>  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
> ^~~~
>drivers/acpi/arm64/iort.c:777:21: note: each undeclared identifier is 
> reported only once for each function it appears in
>
> vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +777 drivers/acpi/arm64/iort.c
>
>771  smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>772
>773  /*
>774   * Override the size, for Cavium ThunderX2 implementation
>775   * which doesn't support the page 1 SMMU register space.
>776   */
>  > 777  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
>778  size = SZ_64K;
>779
>780  res[num_res].start = smmu->base_address;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

As menctioned in cover letter this patchset is based on Robin' s latest
patch "Update SMMU models for IORT rev. C" .
 https://www.spinics.net/lists/arm-kernel/msg580728.html



Thank you,
Geetha.


Re: [v6 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

2017-05-12 Thread Geetha Akula
On Sat, May 13, 2017 at 6:03 AM, kbuild test robot  wrote:
> Hi Linu,
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on v4.11 next-20170512]
> [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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> for-next/core
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>drivers/acpi/arm64/iort.c: In function 'arm_smmu_v3_init_resources':
>>> drivers/acpi/arm64/iort.c:777:21: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>>> undeclared (first use in this function)
>  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
> ^~~~
>drivers/acpi/arm64/iort.c:777:21: note: each undeclared identifier is 
> reported only once for each function it appears in
>
> vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +777 drivers/acpi/arm64/iort.c
>
>771  smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>772
>773  /*
>774   * Override the size, for Cavium ThunderX2 implementation
>775   * which doesn't support the page 1 SMMU register space.
>776   */
>  > 777  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
>778  size = SZ_64K;
>779
>780  res[num_res].start = smmu->base_address;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

As menctioned in cover letter this patchset is based on Robin' s latest
patch "Update SMMU models for IORT rev. C" .
 https://www.spinics.net/lists/arm-kernel/msg580728.html



Thank you,
Geetha.


[PATCH] usb: gadget: f_fs: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/usb/gadget/function/f_fs.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 71dd27c..5754538 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3692,14 +3692,9 @@ static char *ffs_prepare_buffer(const char __user *buf, 
size_t len)
if (unlikely(!len))
return NULL;
 
-   data = kmalloc(len, GFP_KERNEL);
-   if (unlikely(!data))
-   return ERR_PTR(-ENOMEM);
-
-   if (unlikely(copy_from_user(data, buf, len))) {
-   kfree(data);
-   return ERR_PTR(-EFAULT);
-   }
+   data = memdup_user(buf, len);
+   if (unlikely(IS_ERR(data)))
+   return data;
 
pr_vdebug("Buffer from user space:\n");
ffs_dump_mem("", data, len);
-- 
2.9.3



[PATCH] usb: gadget: f_fs: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/usb/gadget/function/f_fs.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 71dd27c..5754538 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3692,14 +3692,9 @@ static char *ffs_prepare_buffer(const char __user *buf, 
size_t len)
if (unlikely(!len))
return NULL;
 
-   data = kmalloc(len, GFP_KERNEL);
-   if (unlikely(!data))
-   return ERR_PTR(-ENOMEM);
-
-   if (unlikely(copy_from_user(data, buf, len))) {
-   kfree(data);
-   return ERR_PTR(-EFAULT);
-   }
+   data = memdup_user(buf, len);
+   if (unlikely(IS_ERR(data)))
+   return data;
 
pr_vdebug("Buffer from user space:\n");
ffs_dump_mem("", data, len);
-- 
2.9.3



[PATCH] KEYS: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 security/keys/keyctl.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index dd0da25..ce1574a 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -326,14 +326,11 @@ long keyctl_update_key(key_serial_t id,
/* pull the payload in if one was supplied */
payload = NULL;
if (_payload) {
-   ret = -ENOMEM;
-   payload = kmalloc(plen, GFP_KERNEL);
-   if (!payload)
+   payload = memdup_user(_payload, plen);
+   if (IS_ERR(payload)) {
+   ret = PTR_ERR(payload);
goto error;
-
-   ret = -EFAULT;
-   if (copy_from_user(payload, _payload, plen) != 0)
-   goto error2;
+   }
}
 
/* find the target key (which must be writable) */
-- 
2.9.3



[PATCH] USB: iowarrior: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/usb/misc/iowarrior.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 7756953..816afad 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -368,14 +368,9 @@ static ssize_t iowarrior_write(struct file *file,
case USB_DEVICE_ID_CODEMERCS_IOWPV2:
case USB_DEVICE_ID_CODEMERCS_IOW40:
/* IOW24 and IOW40 use a synchronous call */
-   buf = kmalloc(count, GFP_KERNEL);
-   if (!buf) {
-   retval = -ENOMEM;
-   goto exit;
-   }
-   if (copy_from_user(buf, user_buffer, count)) {
-   retval = -EFAULT;
-   kfree(buf);
+   buf = memdup_user(user_buffer, count);
+   if (IS_ERR(buf)) {
+   retval = PTR_ERR(buf);
goto exit;
}
retval = usb_set_report(dev->interface, 2, 0, buf, count);
-- 
2.9.3



[PATCH] KEYS: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 security/keys/keyctl.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index dd0da25..ce1574a 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -326,14 +326,11 @@ long keyctl_update_key(key_serial_t id,
/* pull the payload in if one was supplied */
payload = NULL;
if (_payload) {
-   ret = -ENOMEM;
-   payload = kmalloc(plen, GFP_KERNEL);
-   if (!payload)
+   payload = memdup_user(_payload, plen);
+   if (IS_ERR(payload)) {
+   ret = PTR_ERR(payload);
goto error;
-
-   ret = -EFAULT;
-   if (copy_from_user(payload, _payload, plen) != 0)
-   goto error2;
+   }
}
 
/* find the target key (which must be writable) */
-- 
2.9.3



[PATCH] USB: iowarrior: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/usb/misc/iowarrior.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 7756953..816afad 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -368,14 +368,9 @@ static ssize_t iowarrior_write(struct file *file,
case USB_DEVICE_ID_CODEMERCS_IOWPV2:
case USB_DEVICE_ID_CODEMERCS_IOW40:
/* IOW24 and IOW40 use a synchronous call */
-   buf = kmalloc(count, GFP_KERNEL);
-   if (!buf) {
-   retval = -ENOMEM;
-   goto exit;
-   }
-   if (copy_from_user(buf, user_buffer, count)) {
-   retval = -EFAULT;
-   kfree(buf);
+   buf = memdup_user(user_buffer, count);
+   if (IS_ERR(buf)) {
+   retval = PTR_ERR(buf);
goto exit;
}
retval = usb_set_report(dev->interface, 2, 0, buf, count);
-- 
2.9.3



[PATCH] mmc: block: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/mmc/core/block.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 8273b07..47ccb2a 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -342,21 +342,15 @@ static struct mmc_blk_ioc_data 
*mmc_blk_ioctl_copy_from_user(
return idata;
}
 
-   idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
-   if (!idata->buf) {
-   err = -ENOMEM;
+   idata->buf = memdup_user((void __user *)(unsigned long)
+idata->ic.data_ptr, idata->buf_bytes);
+   if (IS_ERR(idata->buf)) {
+   err = PTR_ERR(idata->buf);
goto idata_err;
}
 
-   if (copy_from_user(idata->buf, (void __user *)(unsigned long)
-   idata->ic.data_ptr, idata->buf_bytes)) {
-   err = -EFAULT;
-   goto copy_err;
-   }
-
return idata;
 
-copy_err:
kfree(idata->buf);
 idata_err:
kfree(idata);
-- 
2.9.3



[PATCH] mmc: block: use memdup_user

2017-05-12 Thread Geliang Tang
Use memdup_user() helper instead of open-coding to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/mmc/core/block.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 8273b07..47ccb2a 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -342,21 +342,15 @@ static struct mmc_blk_ioc_data 
*mmc_blk_ioctl_copy_from_user(
return idata;
}
 
-   idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
-   if (!idata->buf) {
-   err = -ENOMEM;
+   idata->buf = memdup_user((void __user *)(unsigned long)
+idata->ic.data_ptr, idata->buf_bytes);
+   if (IS_ERR(idata->buf)) {
+   err = PTR_ERR(idata->buf);
goto idata_err;
}
 
-   if (copy_from_user(idata->buf, (void __user *)(unsigned long)
-   idata->ic.data_ptr, idata->buf_bytes)) {
-   err = -EFAULT;
-   goto copy_err;
-   }
-
return idata;
 
-copy_err:
kfree(idata->buf);
 idata_err:
kfree(idata);
-- 
2.9.3



Re: [PATCH 4.9 000/103] 4.9.28-stable review

2017-05-12 Thread Guenter Roeck

On 05/11/2017 07:11 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sat May 13 14:11:46 UTC 2017.
Anything received after that time might be too late.




Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter





Re: [PATCH 4.9 000/103] 4.9.28-stable review

2017-05-12 Thread Guenter Roeck

On 05/11/2017 07:11 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sat May 13 14:11:46 UTC 2017.
Anything received after that time might be too late.




Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter





HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-12 Thread PGNet Dev
I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.

HPET's enabled in BIOS, and apparently firmware table data is available.

But, hpet is not an available_clocksource.

Where's this need to be addressed/fixed?  In my config, in kernel code, &/or in 
BIOS?

info:

@ the mobo,

dmidecode
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
81 structures occupying 3317 bytes.
Table at 0x000EC200.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.0
Release Date: 05/26/2015
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 
13h)
3.5"/720 kB floppy services are supported (int 
13h)
3.5"/2.88 MB floppy services are supported (int 
13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

In BIOS, HPET's enabled.

On boot to Xen on linux64

xl info
release: 4.11.0-4.gcb15206-default
version: #1 SMP PREEMPT Thu May 11 07:36:09 UTC 
2017 (cb15206)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 3092
hw_caps: 
bfebfbff:77faf3ff:2c100800:0021:0001:27ab::0100
virt_caps  : hvm hvm_directio
total_memory   : 32493
free_memory: 25899
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 9
xen_extra  : .0_04-493
xen_version: 4.9.0_04-493
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p 
hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  :
xen_commandline: dom0_mem=4096M,max:4096M 
dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga 
console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug 
reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all 
guest_loglvl=all noreboot=false sync_console=true
cc_compiler: gcc (SUSE Linux) 4.8.5
cc_compile_by  : abuild
cc_compile_domain  : suse.de
cc_compile_date: Wed May 10 21:26:38 UTC 2017
build_id   : dde541fac1512c7b1ce17e7496aab57a
xend_config_format : 4

grep -i hpet /boot/config-4.11.0-4.gcb15206-default
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HPET_MMAP_DEFAULT=y


, dmesg reports

dmesg | grep -i hpet
[0.00] Command line: root=/dev/mapper/VG0_ROOT rd.shell 
rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off 
video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 
console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose 

HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-12 Thread PGNet Dev
I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.

HPET's enabled in BIOS, and apparently firmware table data is available.

But, hpet is not an available_clocksource.

Where's this need to be addressed/fixed?  In my config, in kernel code, &/or in 
BIOS?

info:

@ the mobo,

dmidecode
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
81 structures occupying 3317 bytes.
Table at 0x000EC200.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.0
Release Date: 05/26/2015
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 
13h)
3.5"/720 kB floppy services are supported (int 
13h)
3.5"/2.88 MB floppy services are supported (int 
13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

In BIOS, HPET's enabled.

On boot to Xen on linux64

xl info
release: 4.11.0-4.gcb15206-default
version: #1 SMP PREEMPT Thu May 11 07:36:09 UTC 
2017 (cb15206)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 3092
hw_caps: 
bfebfbff:77faf3ff:2c100800:0021:0001:27ab::0100
virt_caps  : hvm hvm_directio
total_memory   : 32493
free_memory: 25899
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 9
xen_extra  : .0_04-493
xen_version: 4.9.0_04-493
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p 
hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  :
xen_commandline: dom0_mem=4096M,max:4096M 
dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga 
console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug 
reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all 
guest_loglvl=all noreboot=false sync_console=true
cc_compiler: gcc (SUSE Linux) 4.8.5
cc_compile_by  : abuild
cc_compile_domain  : suse.de
cc_compile_date: Wed May 10 21:26:38 UTC 2017
build_id   : dde541fac1512c7b1ce17e7496aab57a
xend_config_format : 4

grep -i hpet /boot/config-4.11.0-4.gcb15206-default
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HPET_MMAP_DEFAULT=y


, dmesg reports

dmesg | grep -i hpet
[0.00] Command line: root=/dev/mapper/VG0_ROOT rd.shell 
rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off 
video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 
console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose 

[PATCH] ovl: Select EXPORTFS for exportfs_{en,de}code_fh

2017-05-12 Thread Florian Fainelli
fs/overlayfs/namei.c now calls exportfs_decode_fh() and
fs/overlayfs/copy_up.c calls exportfs_encode_fh() but misses an EXPORTFS
select which results in the following build error:

fs/built-in.o: In function `ovl_get_origin':
/home/florian/dev/linux/fs/overlayfs/namei.c:141: undefined reference to
`exportfs_decode_fh'
fs/built-in.o: In function `ovl_encode_fh':
/home/florian/dev/linux/fs/overlayfs/copy_up.c:253: undefined reference
to `exportfs_encode_fh'
Makefile:997: recipe for target 'vmlinux' failed

Fixes: a9d019573e88 ("ovl: lookup non-dir copy-up-origin by file handle")
Fixes: 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")
Signed-off-by: Florian Fainelli 
---
 fs/overlayfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
index 0daac5112f7a..c0c9683934b7 100644
--- a/fs/overlayfs/Kconfig
+++ b/fs/overlayfs/Kconfig
@@ -1,5 +1,6 @@
 config OVERLAY_FS
tristate "Overlay filesystem support"
+   select EXPORTFS
help
  An overlay filesystem combines two filesystems - an 'upper' filesystem
  and a 'lower' filesystem.  When a name exists in both filesystems, the
-- 
2.11.0



[PATCH] ovl: Select EXPORTFS for exportfs_{en,de}code_fh

2017-05-12 Thread Florian Fainelli
fs/overlayfs/namei.c now calls exportfs_decode_fh() and
fs/overlayfs/copy_up.c calls exportfs_encode_fh() but misses an EXPORTFS
select which results in the following build error:

fs/built-in.o: In function `ovl_get_origin':
/home/florian/dev/linux/fs/overlayfs/namei.c:141: undefined reference to
`exportfs_decode_fh'
fs/built-in.o: In function `ovl_encode_fh':
/home/florian/dev/linux/fs/overlayfs/copy_up.c:253: undefined reference
to `exportfs_encode_fh'
Makefile:997: recipe for target 'vmlinux' failed

Fixes: a9d019573e88 ("ovl: lookup non-dir copy-up-origin by file handle")
Fixes: 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")
Signed-off-by: Florian Fainelli 
---
 fs/overlayfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
index 0daac5112f7a..c0c9683934b7 100644
--- a/fs/overlayfs/Kconfig
+++ b/fs/overlayfs/Kconfig
@@ -1,5 +1,6 @@
 config OVERLAY_FS
tristate "Overlay filesystem support"
+   select EXPORTFS
help
  An overlay filesystem combines two filesystems - an 'upper' filesystem
  and a 'lower' filesystem.  When a name exists in both filesystems, the
-- 
2.11.0



Re: [patch v4 resend 2/2] kcmp: Add KCMP_EPOLL_TFD mode to compare epoll target files

2017-05-12 Thread Andrei Vagin
On Sat, May 13, 2017 at 01:53:40AM +0300, Cyrill Gorcunov wrote:
> On Sat, May 13, 2017 at 12:41:30AM +0200, Jann Horn wrote:
> > [resending as plaintext]
> > 
> > I realize that the existing kcmp code has the same issue, but:
> > 
> > Why are you not taking a reference to filp or filp_tgt? This can end up
> > performing a comparison between a pointer to a freed struct file and a
> > pointer to a struct file that was allocated afterwards, right? So it can
> > return a false "is equal" result when the two files aren't actually the same
> > if one of the target tasks is running? This looks like it unnecessarily
> > exposes information about whether an allocation reuses the memory of
> > a previously freed allocation.
> 
> It work with unlocked data on purpose for speed sake. Moreover even
> if we grap a reference it is valid _only_ during comparision operation,
> next we drop ref and it can be easily freed by os. Thus it's up to
> a caller to keep references to files/task and other resources used.

Looks like we can take rcu_read_lock() to guarantee that these objects
will not be freed, and rcu_read_lock() should not affect perfomance too much.

> 
>   Cyrill


Re: [patch v4 resend 2/2] kcmp: Add KCMP_EPOLL_TFD mode to compare epoll target files

2017-05-12 Thread Andrei Vagin
On Sat, May 13, 2017 at 01:53:40AM +0300, Cyrill Gorcunov wrote:
> On Sat, May 13, 2017 at 12:41:30AM +0200, Jann Horn wrote:
> > [resending as plaintext]
> > 
> > I realize that the existing kcmp code has the same issue, but:
> > 
> > Why are you not taking a reference to filp or filp_tgt? This can end up
> > performing a comparison between a pointer to a freed struct file and a
> > pointer to a struct file that was allocated afterwards, right? So it can
> > return a false "is equal" result when the two files aren't actually the same
> > if one of the target tasks is running? This looks like it unnecessarily
> > exposes information about whether an allocation reuses the memory of
> > a previously freed allocation.
> 
> It work with unlocked data on purpose for speed sake. Moreover even
> if we grap a reference it is valid _only_ during comparision operation,
> next we drop ref and it can be easily freed by os. Thus it's up to
> a caller to keep references to files/task and other resources used.

Looks like we can take rcu_read_lock() to guarantee that these objects
will not be freed, and rcu_read_lock() should not affect perfomance too much.

> 
>   Cyrill


[PATCH v2] staging: rtl8188eu: fix indentation error

2017-05-12 Thread Remco Verhoef
Fixes a 'code indent should use tabs where possible' checkpatch code
style error by changing whitespace into tabs.

Signed-off-by: Remco Verhoef 
---
Changes in v2:
  - More expressive commit message and subject

 drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
index d9fa290..636f445 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
@@ -58,7 +58,7 @@ static void process_link_qual(struct adapter *padapter,
 }
 
 void rtl8188e_process_phy_info(struct adapter *padapter,
-  struct recv_frame *precvframe)
+   struct recv_frame *precvframe)
 {
/*  Check RSSI */
process_rssi(padapter, precvframe);
-- 
1.9.1



[PATCH v2] staging: rtl8188eu: fix indentation error

2017-05-12 Thread Remco Verhoef
Fixes a 'code indent should use tabs where possible' checkpatch code
style error by changing whitespace into tabs.

Signed-off-by: Remco Verhoef 
---
Changes in v2:
  - More expressive commit message and subject

 drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
index d9fa290..636f445 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
@@ -58,7 +58,7 @@ static void process_link_qual(struct adapter *padapter,
 }
 
 void rtl8188e_process_phy_info(struct adapter *padapter,
-  struct recv_frame *precvframe)
+   struct recv_frame *precvframe)
 {
/*  Check RSSI */
process_rssi(padapter, precvframe);
-- 
1.9.1



Re: [PATCH V2] SMB2: Fix share type handling

2017-05-12 Thread Steve French
Merged into cifs-2.6.git for-next

On Fri, May 12, 2017 at 10:59 AM, Christophe JAILLET
 wrote:
> In fs/cifs/smb2pdu.h, we have:
> #define SMB2_SHARE_TYPE_DISK0x01
> #define SMB2_SHARE_TYPE_PIPE0x02
> #define SMB2_SHARE_TYPE_PRINT   0x03
>
> Knowing that, with the current code, the SMB2_SHARE_TYPE_PRINT case can
> never trigger and printer share would be interpreted as disk share.
>
> So, test the ShareType value for equality instead.
>
> Fixes: faaf946a7d5b ("CIFS: Add tree connect/disconnect capability for SMB2")
> Signed-off-by: Christophe JAILLET 
> ---
> V2: use a 'switch' instead of some 'if'
>
> The v1 and related comments are quite old. They can be found at:
>http://marc.info/?t=14797654181=1=4
> ---
>  fs/cifs/smb2pdu.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index e0517f499c38..e4afdaae743f 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1240,15 +1240,19 @@ SMB2_tcon(const unsigned int xid, struct cifs_ses 
> *ses, const char *tree,
> goto tcon_exit;
> }
>
> -   if (rsp->ShareType & SMB2_SHARE_TYPE_DISK)
> +   switch (rsp->ShareType) {
> +   case SMB2_SHARE_TYPE_DISK:
> cifs_dbg(FYI, "connection to disk share\n");
> -   else if (rsp->ShareType & SMB2_SHARE_TYPE_PIPE) {
> +   break;
> +   case SMB2_SHARE_TYPE_PIPE:
> tcon->ipc = true;
> cifs_dbg(FYI, "connection to pipe share\n");
> -   } else if (rsp->ShareType & SMB2_SHARE_TYPE_PRINT) {
> -   tcon->print = true;
> +   break;
> +   case SMB2_SHARE_TYPE_PRINT:
> +   tcon->ipc = true;
> cifs_dbg(FYI, "connection to printer\n");
> -   } else {
> +   break;
> +   default:
> cifs_dbg(VFS, "unknown share type %d\n", rsp->ShareType);
> rc = -EOPNOTSUPP;
> goto tcon_error_exit;
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [PATCH V2] SMB2: Fix share type handling

2017-05-12 Thread Steve French
Merged into cifs-2.6.git for-next

On Fri, May 12, 2017 at 10:59 AM, Christophe JAILLET
 wrote:
> In fs/cifs/smb2pdu.h, we have:
> #define SMB2_SHARE_TYPE_DISK0x01
> #define SMB2_SHARE_TYPE_PIPE0x02
> #define SMB2_SHARE_TYPE_PRINT   0x03
>
> Knowing that, with the current code, the SMB2_SHARE_TYPE_PRINT case can
> never trigger and printer share would be interpreted as disk share.
>
> So, test the ShareType value for equality instead.
>
> Fixes: faaf946a7d5b ("CIFS: Add tree connect/disconnect capability for SMB2")
> Signed-off-by: Christophe JAILLET 
> ---
> V2: use a 'switch' instead of some 'if'
>
> The v1 and related comments are quite old. They can be found at:
>http://marc.info/?t=14797654181=1=4
> ---
>  fs/cifs/smb2pdu.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index e0517f499c38..e4afdaae743f 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1240,15 +1240,19 @@ SMB2_tcon(const unsigned int xid, struct cifs_ses 
> *ses, const char *tree,
> goto tcon_exit;
> }
>
> -   if (rsp->ShareType & SMB2_SHARE_TYPE_DISK)
> +   switch (rsp->ShareType) {
> +   case SMB2_SHARE_TYPE_DISK:
> cifs_dbg(FYI, "connection to disk share\n");
> -   else if (rsp->ShareType & SMB2_SHARE_TYPE_PIPE) {
> +   break;
> +   case SMB2_SHARE_TYPE_PIPE:
> tcon->ipc = true;
> cifs_dbg(FYI, "connection to pipe share\n");
> -   } else if (rsp->ShareType & SMB2_SHARE_TYPE_PRINT) {
> -   tcon->print = true;
> +   break;
> +   case SMB2_SHARE_TYPE_PRINT:
> +   tcon->ipc = true;
> cifs_dbg(FYI, "connection to printer\n");
> -   } else {
> +   break;
> +   default:
> cifs_dbg(VFS, "unknown share type %d\n", rsp->ShareType);
> rc = -EOPNOTSUPP;
> goto tcon_error_exit;
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [PATCH] fs: cifs: transport: Use time_after for time comparison

2017-05-12 Thread Steve French
merged into cifs-2.6.git for-next

On Thu, May 11, 2017 at 6:53 PM, Karim Eshapa  wrote:
> Use time_after kernel macro for time comparison
> that has safety check.
>
> Signed-off-by: Karim Eshapa 
> ---
>  fs/cifs/transport.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
> index 4d64b5b..a7f5168 100644
> --- a/fs/cifs/transport.c
> +++ b/fs/cifs/transport.c
> @@ -94,7 +94,7 @@ DeleteMidQEntry(struct mid_q_entry *midEntry)
> now = jiffies;
> /* commands taking longer than one second are indications that
>something is wrong, unless it is quite a slow link or server */
> -   if ((now - midEntry->when_alloc) > HZ) {
> +   if (time_after(now, midEntry->when_alloc + HZ)) {
> if ((cifsFYI & CIFS_TIMER) && (midEntry->command != command)) 
> {
> pr_debug(" CIFS slow rsp: cmd %d mid %llu",
>midEntry->command, midEntry->mid);
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [PATCH] fs: cifs: transport: Use time_after for time comparison

2017-05-12 Thread Steve French
merged into cifs-2.6.git for-next

On Thu, May 11, 2017 at 6:53 PM, Karim Eshapa  wrote:
> Use time_after kernel macro for time comparison
> that has safety check.
>
> Signed-off-by: Karim Eshapa 
> ---
>  fs/cifs/transport.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
> index 4d64b5b..a7f5168 100644
> --- a/fs/cifs/transport.c
> +++ b/fs/cifs/transport.c
> @@ -94,7 +94,7 @@ DeleteMidQEntry(struct mid_q_entry *midEntry)
> now = jiffies;
> /* commands taking longer than one second are indications that
>something is wrong, unless it is quite a slow link or server */
> -   if ((now - midEntry->when_alloc) > HZ) {
> +   if (time_after(now, midEntry->when_alloc + HZ)) {
> if ((cifsFYI & CIFS_TIMER) && (midEntry->command != command)) 
> {
> pr_debug(" CIFS slow rsp: cmd %d mid %llu",
>midEntry->command, midEntry->mid);
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [v6 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

2017-05-12 Thread kbuild test robot
Hi Linu,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.11 next-20170512]
[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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers//iommu/arm-smmu-v3.c: In function 'acpi_smmu_get_options':
>> drivers//iommu/arm-smmu-v3.c:2605:15: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>> undeclared (first use in this function)
 if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
  ^~~~
   drivers//iommu/arm-smmu-v3.c:2605:15: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +2605 drivers//iommu/arm-smmu-v3.c

  2599  return 0;
  2600  }
  2601  
  2602  #ifdef CONFIG_ACPI
  2603  static void acpi_smmu_get_options(u32 model, struct arm_smmu_device 
*smmu)
  2604  {
> 2605  if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
  2606  smmu->options |= ARM_SMMU_OPT_PAGE0_REGS_ONLY;
  2607  
  2608  dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options);

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


.config.gz
Description: application/gzip


Re: [v6 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

2017-05-12 Thread kbuild test robot
Hi Linu,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.11 next-20170512]
[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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers//iommu/arm-smmu-v3.c: In function 'acpi_smmu_get_options':
>> drivers//iommu/arm-smmu-v3.c:2605:15: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>> undeclared (first use in this function)
 if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
  ^~~~
   drivers//iommu/arm-smmu-v3.c:2605:15: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +2605 drivers//iommu/arm-smmu-v3.c

  2599  return 0;
  2600  }
  2601  
  2602  #ifdef CONFIG_ACPI
  2603  static void acpi_smmu_get_options(u32 model, struct arm_smmu_device 
*smmu)
  2604  {
> 2605  if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
  2606  smmu->options |= ARM_SMMU_OPT_PAGE0_REGS_ONLY;
  2607  
  2608  dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options);

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


.config.gz
Description: application/gzip


[PATCH] sched: remove sched_find_first_bit()

2017-05-12 Thread Yury Norov
sched_find_first_bit() is in fact the unrolled version of
find_first_bit(), which is theoretically faster in some cases.
But in the kernel it is called only in couple places in 
kernel/sched/rt.c, and both of them are not looking like hot
paths that will doubtly achieve measurable benefit from using
unrolled version of find_first_bit() - there's no hard loops,
and the execution path is not really short.

This patch removes sched_find_first_bit() and deletes
include/asm-generic/bitops/sched.h as it declares only this
function.  Alpha has it's own implementation, very similar to
generic one, so it is also removed.

Signed-off-by: Yury Norov 
---
 arch/alpha/include/asm/bitops.h| 18 --
 arch/arc/include/asm/bitops.h  |  1 -
 arch/arm/include/asm/bitops.h  |  1 -
 arch/arm64/include/asm/bitops.h|  1 -
 arch/blackfin/include/asm/bitops.h |  1 -
 arch/c6x/include/asm/bitops.h  |  1 -
 arch/cris/include/asm/bitops.h |  2 --
 arch/frv/include/asm/bitops.h  |  1 -
 arch/h8300/include/asm/bitops.h|  1 -
 arch/hexagon/include/asm/bitops.h  |  1 -
 arch/ia64/include/asm/bitops.h |  2 --
 arch/m32r/include/asm/bitops.h |  1 -
 arch/m68k/include/asm/bitops.h |  1 -
 arch/metag/include/asm/bitops.h|  1 -
 arch/mips/include/asm/bitops.h |  2 --
 arch/mn10300/include/asm/bitops.h  |  1 -
 arch/openrisc/include/asm/bitops.h |  1 -
 arch/parisc/include/asm/bitops.h   |  1 -
 arch/powerpc/include/asm/bitops.h  |  2 --
 arch/s390/include/asm/bitops.h |  1 -
 arch/sh/include/asm/bitops.h   |  1 -
 arch/sparc/include/asm/bitops_32.h |  1 -
 arch/sparc/include/asm/bitops_64.h |  1 -
 arch/tile/include/asm/bitops.h |  1 -
 arch/x86/include/asm/bitops.h  |  2 --
 arch/xtensa/include/asm/bitops.h   |  1 -
 include/asm-generic/bitops.h   |  1 -
 include/asm-generic/bitops/sched.h | 31 ---
 kernel/sched/rt.c  |  4 ++--
 29 files changed, 2 insertions(+), 82 deletions(-)
 delete mode 100644 include/asm-generic/bitops/sched.h

diff --git a/arch/alpha/include/asm/bitops.h b/arch/alpha/include/asm/bitops.h
index 4bdfbd444e63..9e4d5309c27f 100644
--- a/arch/alpha/include/asm/bitops.h
+++ b/arch/alpha/include/asm/bitops.h
@@ -433,24 +433,6 @@ static inline unsigned int __arch_hweight8(unsigned int w)
 
 #ifdef __KERNEL__
 
-/*
- * Every architecture must define this function. It's the fastest
- * way of searching a 100-bit bitmap.  It's guaranteed that at least
- * one of the 100 bits is cleared.
- */
-static inline unsigned long
-sched_find_first_bit(const unsigned long b[2])
-{
-   unsigned long b0, b1, ofs, tmp;
-
-   b0 = b[0];
-   b1 = b[1];
-   ofs = (b0 ? 0 : 64);
-   tmp = (b0 ? b0 : b1);
-
-   return __ffs(tmp) + ofs;
-}
-
 #include 
 
 #include 
diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index 8da87feec59a..5db132568926 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -425,7 +425,6 @@ static inline __attribute__ ((const)) int __ffs(unsigned 
long x)
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index e943e6cee254..8498a8e3e76a 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -311,7 +311,6 @@ static inline unsigned long __ffs(unsigned long x)
 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 9c19594ce7cb..a3ca26e459e1 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -42,7 +42,6 @@ extern int test_and_change_bit(int nr, volatile unsigned long 
*p);
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/blackfin/include/asm/bitops.h 
b/arch/blackfin/include/asm/bitops.h
index b298b654a26f..6babd3ad7204 100644
--- a/arch/blackfin/include/asm/bitops.h
+++ b/arch/blackfin/include/asm/bitops.h
@@ -20,7 +20,6 @@
 #error only  can be included directly
 #endif
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/c6x/include/asm/bitops.h b/arch/c6x/include/asm/bitops.h
index f0ab012401b6..d828299a8e3c 100644
--- a/arch/c6x/include/asm/bitops.h
+++ b/arch/c6x/include/asm/bitops.h
@@ -85,7 +85,6 @@ static inline int ffs(int x)
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/cris/include/asm/bitops.h b/arch/cris/include/asm/bitops.h
index 8062cb52d343..e8b5d7ce010f 100644
--- a/arch/cris/include/asm/bitops.h
+++ b/arch/cris/include/asm/bitops.h
@@ -43,8 +43,6 @@
 
 #include 
 
-#include 
-
 #endif /* __KERNEL__ */
 
 #endif /* _CRIS_BITOPS_H */
diff --git a/arch/frv/include/asm/bitops.h b/arch/frv/include/asm/bitops.h
index 0df8e95e3715..97e95cfc3f2d 100644
--- a/arch/frv/include/asm/bitops.h
+++ b/arch/frv/include/asm/bitops.h
@@ -312,7 +312,6 @@ int __ilog2_u64(u64 n)
return bit;
 }
 

[PATCH] sched: remove sched_find_first_bit()

2017-05-12 Thread Yury Norov
sched_find_first_bit() is in fact the unrolled version of
find_first_bit(), which is theoretically faster in some cases.
But in the kernel it is called only in couple places in 
kernel/sched/rt.c, and both of them are not looking like hot
paths that will doubtly achieve measurable benefit from using
unrolled version of find_first_bit() - there's no hard loops,
and the execution path is not really short.

This patch removes sched_find_first_bit() and deletes
include/asm-generic/bitops/sched.h as it declares only this
function.  Alpha has it's own implementation, very similar to
generic one, so it is also removed.

Signed-off-by: Yury Norov 
---
 arch/alpha/include/asm/bitops.h| 18 --
 arch/arc/include/asm/bitops.h  |  1 -
 arch/arm/include/asm/bitops.h  |  1 -
 arch/arm64/include/asm/bitops.h|  1 -
 arch/blackfin/include/asm/bitops.h |  1 -
 arch/c6x/include/asm/bitops.h  |  1 -
 arch/cris/include/asm/bitops.h |  2 --
 arch/frv/include/asm/bitops.h  |  1 -
 arch/h8300/include/asm/bitops.h|  1 -
 arch/hexagon/include/asm/bitops.h  |  1 -
 arch/ia64/include/asm/bitops.h |  2 --
 arch/m32r/include/asm/bitops.h |  1 -
 arch/m68k/include/asm/bitops.h |  1 -
 arch/metag/include/asm/bitops.h|  1 -
 arch/mips/include/asm/bitops.h |  2 --
 arch/mn10300/include/asm/bitops.h  |  1 -
 arch/openrisc/include/asm/bitops.h |  1 -
 arch/parisc/include/asm/bitops.h   |  1 -
 arch/powerpc/include/asm/bitops.h  |  2 --
 arch/s390/include/asm/bitops.h |  1 -
 arch/sh/include/asm/bitops.h   |  1 -
 arch/sparc/include/asm/bitops_32.h |  1 -
 arch/sparc/include/asm/bitops_64.h |  1 -
 arch/tile/include/asm/bitops.h |  1 -
 arch/x86/include/asm/bitops.h  |  2 --
 arch/xtensa/include/asm/bitops.h   |  1 -
 include/asm-generic/bitops.h   |  1 -
 include/asm-generic/bitops/sched.h | 31 ---
 kernel/sched/rt.c  |  4 ++--
 29 files changed, 2 insertions(+), 82 deletions(-)
 delete mode 100644 include/asm-generic/bitops/sched.h

diff --git a/arch/alpha/include/asm/bitops.h b/arch/alpha/include/asm/bitops.h
index 4bdfbd444e63..9e4d5309c27f 100644
--- a/arch/alpha/include/asm/bitops.h
+++ b/arch/alpha/include/asm/bitops.h
@@ -433,24 +433,6 @@ static inline unsigned int __arch_hweight8(unsigned int w)
 
 #ifdef __KERNEL__
 
-/*
- * Every architecture must define this function. It's the fastest
- * way of searching a 100-bit bitmap.  It's guaranteed that at least
- * one of the 100 bits is cleared.
- */
-static inline unsigned long
-sched_find_first_bit(const unsigned long b[2])
-{
-   unsigned long b0, b1, ofs, tmp;
-
-   b0 = b[0];
-   b1 = b[1];
-   ofs = (b0 ? 0 : 64);
-   tmp = (b0 ? b0 : b1);
-
-   return __ffs(tmp) + ofs;
-}
-
 #include 
 
 #include 
diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index 8da87feec59a..5db132568926 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -425,7 +425,6 @@ static inline __attribute__ ((const)) int __ffs(unsigned 
long x)
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index e943e6cee254..8498a8e3e76a 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -311,7 +311,6 @@ static inline unsigned long __ffs(unsigned long x)
 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 9c19594ce7cb..a3ca26e459e1 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -42,7 +42,6 @@ extern int test_and_change_bit(int nr, volatile unsigned long 
*p);
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/blackfin/include/asm/bitops.h 
b/arch/blackfin/include/asm/bitops.h
index b298b654a26f..6babd3ad7204 100644
--- a/arch/blackfin/include/asm/bitops.h
+++ b/arch/blackfin/include/asm/bitops.h
@@ -20,7 +20,6 @@
 #error only  can be included directly
 #endif
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/c6x/include/asm/bitops.h b/arch/c6x/include/asm/bitops.h
index f0ab012401b6..d828299a8e3c 100644
--- a/arch/c6x/include/asm/bitops.h
+++ b/arch/c6x/include/asm/bitops.h
@@ -85,7 +85,6 @@ static inline int ffs(int x)
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/cris/include/asm/bitops.h b/arch/cris/include/asm/bitops.h
index 8062cb52d343..e8b5d7ce010f 100644
--- a/arch/cris/include/asm/bitops.h
+++ b/arch/cris/include/asm/bitops.h
@@ -43,8 +43,6 @@
 
 #include 
 
-#include 
-
 #endif /* __KERNEL__ */
 
 #endif /* _CRIS_BITOPS_H */
diff --git a/arch/frv/include/asm/bitops.h b/arch/frv/include/asm/bitops.h
index 0df8e95e3715..97e95cfc3f2d 100644
--- a/arch/frv/include/asm/bitops.h
+++ b/arch/frv/include/asm/bitops.h
@@ -312,7 +312,6 @@ int __ilog2_u64(u64 n)
return bit;
 }
 
-#include 
 #include 
 #include 
 

Re: [git pull] uaccess-related bits of vfs.git

2017-05-12 Thread Linus Torvalds
So I should have asked earlier, but I was feeling rather busy during
the early merge window..

On Sun, Apr 30, 2017 at 8:45 PM, Al Viro  wrote:
> uaccess unification pile.  It's _not_ the end of uaccess work, but
> the next batch of that will go into the next cycle.  This one mostly takes
> copy_from_user() and friends out of arch/* and gets the zero-padding behaviour
> in sync for all architectures.
> Dealing with the nocache/writethrough mess is for the next cycle;
> fortunately, that's x86-only.

So I'm actually more interested to hear if you have any pending work
on cleaning up the __get/put_user() mess we have. Is that on your
radar at all?

In particular, right now, both __get_user() and __put_user() are nasty
and broken interfaces.

It *used* to be that they were designed to just generate a single
instruction. That's not what they currently do at all, due to the
whole SMAP/PAN on x86 and arm.

For example, on x86, right now a single __put_user() call ends up
generating something like

#APP
# 58 "./arch/x86/include/asm/smap.h" 1
661:

662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
 .long 661b - .
 .long 6641f - .
 .word ( 9*32+20)
 .byte 663b-661b
 .byte 6651f-6641f
 .byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
.byte 0x0f,0x01,0xcb
6651:
.popsection
# 0 "" 2
#NO_APP
xorl%eax, %eax  # __pu_err
#APP
# 269 "fs/readdir.c" 1

1:  movq %rcx,8(%rdi)   # offset, MEM[(struct __large_struct *)_16]
2:
.section .fixup,"ax"
3:  mov $-14,%eax   #, __pu_err
jmp 2b
.previous
 .pushsection "__ex_table","a"
 .balign 4
 .long (1b) - .
 .long (3b) - .
 .long (ex_handler_default) - .
 .popsection

# 0 "" 2
# 52 "./arch/x86/include/asm/smap.h" 1
661:

662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
 .long 661b - .
 .long 6641f - .
 .word ( 9*32+20)
 .byte 663b-661b
 .byte 6651f-6641f
 .byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
.byte 0x0f,0x01,0xca
6651:
.popsection
# 0 "" 2
#NO_APP

and while much of that is out-of-line and in different sections, it
basically means that it's insane how we inline these things.

Yes, yes, the inlined part of the above horror-story ends up being just

clac
xor%eax,%eax
mov%rcx,0x8(%rdi)
stac

and everything else is just boiler-plate for the alt-instruction
handling and the exception handling.

But even that small thing is rather debatable from a performance
angle: the actual cost of __put_user() these days is not the function
call, but the clac/stac (on modern x86) and the PAN bit games (on
arm).

So I'm actually inclined to just say "We should make
__get_user/__put_user() just be aliases for the normal
get_user/put_user() model".

The *correct* way to do fast user space accesses when you hoist error
checking outside is to use

if (!access_ok(..))
goto efault;
user_access_begin();
..
... loop over or otherwise do multiple "raw" accessess ...
unsafe_get/put_user(c, ptr, got_fault);
unsafe_get/put_user(c, ptr, got_fault);
...
user_access_end();
return 0;

got_fault:
user_access_end();
efault:
return -EFAULT;

which is more boilerplate, but ends up generating much better code.
And for "unsafe_put_user()" in particular, we actually could teach gcc
to use "asm goto" to really improve code generation. I have patches
for that if you want to look.

I'm attaching an example patch for "filldir()" that does that modern
thing. It almost had the right form as-is anyway, and under some loads
(eg "find") filldir actually shows up in profiles too.\

And just from a code generation standpoint, look at what the attached
patch does:

[torvalds@i7 linux]$ diff -u fs/readdir.s ~/readdir.s | diffstat
 readdir.s |  548 ++
 1 file changed, 201 insertions(+), 347 deletions(-)

just from getting rid of that crazy repeated SMAP overhead.

Yeah, yeah, doing diffstat on generated assembly files is all kinds of
crazy, but it's an example of what kind of odd garbage we currently
generate.

But the *first* thing I'd like to do would be to just get rid of
__get_user/__put_user as a thing. It really does generate nasty code,
and we might as well just make it do that function call.

Because what we do now isn't right. If we care about performance, the
"__xyz_user" versions are wrong (use unsafe_xyz_user() instead). And
if you don't care about performance, you should use the 

Re: [git pull] uaccess-related bits of vfs.git

2017-05-12 Thread Linus Torvalds
So I should have asked earlier, but I was feeling rather busy during
the early merge window..

On Sun, Apr 30, 2017 at 8:45 PM, Al Viro  wrote:
> uaccess unification pile.  It's _not_ the end of uaccess work, but
> the next batch of that will go into the next cycle.  This one mostly takes
> copy_from_user() and friends out of arch/* and gets the zero-padding behaviour
> in sync for all architectures.
> Dealing with the nocache/writethrough mess is for the next cycle;
> fortunately, that's x86-only.

So I'm actually more interested to hear if you have any pending work
on cleaning up the __get/put_user() mess we have. Is that on your
radar at all?

In particular, right now, both __get_user() and __put_user() are nasty
and broken interfaces.

It *used* to be that they were designed to just generate a single
instruction. That's not what they currently do at all, due to the
whole SMAP/PAN on x86 and arm.

For example, on x86, right now a single __put_user() call ends up
generating something like

#APP
# 58 "./arch/x86/include/asm/smap.h" 1
661:

662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
 .long 661b - .
 .long 6641f - .
 .word ( 9*32+20)
 .byte 663b-661b
 .byte 6651f-6641f
 .byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
.byte 0x0f,0x01,0xcb
6651:
.popsection
# 0 "" 2
#NO_APP
xorl%eax, %eax  # __pu_err
#APP
# 269 "fs/readdir.c" 1

1:  movq %rcx,8(%rdi)   # offset, MEM[(struct __large_struct *)_16]
2:
.section .fixup,"ax"
3:  mov $-14,%eax   #, __pu_err
jmp 2b
.previous
 .pushsection "__ex_table","a"
 .balign 4
 .long (1b) - .
 .long (3b) - .
 .long (ex_handler_default) - .
 .popsection

# 0 "" 2
# 52 "./arch/x86/include/asm/smap.h" 1
661:

662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
 .long 661b - .
 .long 6641f - .
 .word ( 9*32+20)
 .byte 663b-661b
 .byte 6651f-6641f
 .byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
.byte 0x0f,0x01,0xca
6651:
.popsection
# 0 "" 2
#NO_APP

and while much of that is out-of-line and in different sections, it
basically means that it's insane how we inline these things.

Yes, yes, the inlined part of the above horror-story ends up being just

clac
xor%eax,%eax
mov%rcx,0x8(%rdi)
stac

and everything else is just boiler-plate for the alt-instruction
handling and the exception handling.

But even that small thing is rather debatable from a performance
angle: the actual cost of __put_user() these days is not the function
call, but the clac/stac (on modern x86) and the PAN bit games (on
arm).

So I'm actually inclined to just say "We should make
__get_user/__put_user() just be aliases for the normal
get_user/put_user() model".

The *correct* way to do fast user space accesses when you hoist error
checking outside is to use

if (!access_ok(..))
goto efault;
user_access_begin();
..
... loop over or otherwise do multiple "raw" accessess ...
unsafe_get/put_user(c, ptr, got_fault);
unsafe_get/put_user(c, ptr, got_fault);
...
user_access_end();
return 0;

got_fault:
user_access_end();
efault:
return -EFAULT;

which is more boilerplate, but ends up generating much better code.
And for "unsafe_put_user()" in particular, we actually could teach gcc
to use "asm goto" to really improve code generation. I have patches
for that if you want to look.

I'm attaching an example patch for "filldir()" that does that modern
thing. It almost had the right form as-is anyway, and under some loads
(eg "find") filldir actually shows up in profiles too.\

And just from a code generation standpoint, look at what the attached
patch does:

[torvalds@i7 linux]$ diff -u fs/readdir.s ~/readdir.s | diffstat
 readdir.s |  548 ++
 1 file changed, 201 insertions(+), 347 deletions(-)

just from getting rid of that crazy repeated SMAP overhead.

Yeah, yeah, doing diffstat on generated assembly files is all kinds of
crazy, but it's an example of what kind of odd garbage we currently
generate.

But the *first* thing I'd like to do would be to just get rid of
__get_user/__put_user as a thing. It really does generate nasty code,
and we might as well just make it do that function call.

Because what we do now isn't right. If we care about performance, the
"__xyz_user" versions are wrong (use unsafe_xyz_user() instead). And
if you don't care about performance, you should use the regular
xyz_user() functions 

Re: [PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

2017-05-12 Thread Steve French
merged into cifs-2.6.git for-next

On Tue, May 9, 2017 at 11:26 PM, Shirish Pargaonkar
 wrote:
> Looks correct.
>
> Acked-by: Shirish Pargaonkar 
>
> On Sun, May 7, 2017 at 3:31 AM, Joe Perches via samba-technical
>  wrote:
>> Create an ops variable to store tcon->ses->server->ops and cache
>> indirections and reduce code size a trivial bit.
>>
>> $ size fs/cifs/cifsacl.o*
>>textdata bss dec hex filename
>>5338 136   85482156a fs/cifs/cifsacl.o.new
>>5371 136   85515158b fs/cifs/cifsacl.o.old
>>
>> Signed-off-by: Joe Perches 
>> ---
>>  fs/cifs/cifsacl.c | 30 ++
>>  1 file changed, 14 insertions(+), 16 deletions(-)
>>
>> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
>> index 15bac390dff9..b98436f5c7c7 100644
>> --- a/fs/cifs/cifsacl.c
>> +++ b/fs/cifs/cifsacl.c
>> @@ -1135,20 +1135,19 @@ cifs_acl_to_fattr(struct cifs_sb_info *cifs_sb, 
>> struct cifs_fattr *fattr,
>> u32 acllen = 0;
>> int rc = 0;
>> struct tcon_link *tlink = cifs_sb_tlink(cifs_sb);
>> -   struct cifs_tcon *tcon;
>> +   struct smb_version_operations *ops;
>>
>> cifs_dbg(NOISY, "converting ACL to mode for %s\n", path);
>>
>> if (IS_ERR(tlink))
>> return PTR_ERR(tlink);
>> -   tcon = tlink_tcon(tlink);
>>
>> -   if (pfid && (tcon->ses->server->ops->get_acl_by_fid))
>> -   pntsd = tcon->ses->server->ops->get_acl_by_fid(cifs_sb, pfid,
>> - );
>> -   else if (tcon->ses->server->ops->get_acl)
>> -   pntsd = tcon->ses->server->ops->get_acl(cifs_sb, inode, path,
>> -   );
>> +   ops = tlink_tcon(tlink)->ses->server->ops;
>> +
>> +   if (pfid && (ops->get_acl_by_fid))
>> +   pntsd = ops->get_acl_by_fid(cifs_sb, pfid, );
>> +   else if (ops->get_acl)
>> +   pntsd = ops->get_acl(cifs_sb, inode, path, );
>> else {
>> cifs_put_tlink(tlink);
>> return -EOPNOTSUPP;
>> @@ -1181,23 +1180,23 @@ id_mode_to_cifs_acl(struct inode *inode, const char 
>> *path, __u64 nmode,
>> struct cifs_ntsd *pnntsd = NULL; /* modified acl to be sent to 
>> server */
>> struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
>> struct tcon_link *tlink = cifs_sb_tlink(cifs_sb);
>> -   struct cifs_tcon *tcon;
>> +   struct smb_version_operations *ops;
>>
>> if (IS_ERR(tlink))
>> return PTR_ERR(tlink);
>> -   tcon = tlink_tcon(tlink);
>> +
>> +   ops = tlink_tcon(tlink)->ses->server->ops;
>>
>> cifs_dbg(NOISY, "set ACL from mode for %s\n", path);
>>
>> /* Get the security descriptor */
>>
>> -   if (tcon->ses->server->ops->get_acl == NULL) {
>> +   if (ops->get_acl == NULL) {
>> cifs_put_tlink(tlink);
>> return -EOPNOTSUPP;
>> }
>>
>> -   pntsd = tcon->ses->server->ops->get_acl(cifs_sb, inode, path,
>> -   );
>> +   pntsd = ops->get_acl(cifs_sb, inode, path, );
>> if (IS_ERR(pntsd)) {
>> rc = PTR_ERR(pntsd);
>> cifs_dbg(VFS, "%s: error %d getting sec desc\n", __func__, 
>> rc);
>> @@ -1224,13 +1223,12 @@ id_mode_to_cifs_acl(struct inode *inode, const char 
>> *path, __u64 nmode,
>>
>> cifs_dbg(NOISY, "build_sec_desc rc: %d\n", rc);
>>
>> -   if (tcon->ses->server->ops->set_acl == NULL)
>> +   if (ops->set_acl == NULL)
>> rc = -EOPNOTSUPP;
>>
>> if (!rc) {
>> /* Set the security descriptor */
>> -   rc = tcon->ses->server->ops->set_acl(pnntsd, secdesclen, 
>> inode,
>> -path, aclflag);
>> +   rc = ops->set_acl(pnntsd, secdesclen, inode, path, aclflag);
>> cifs_dbg(NOISY, "set_cifs_acl rc: %d\n", rc);
>> }
>> cifs_put_tlink(tlink);
>> --
>> 2.10.0.rc2.1.g053435c
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

2017-05-12 Thread Steve French
merged into cifs-2.6.git for-next

On Tue, May 9, 2017 at 11:26 PM, Shirish Pargaonkar
 wrote:
> Looks correct.
>
> Acked-by: Shirish Pargaonkar 
>
> On Sun, May 7, 2017 at 3:31 AM, Joe Perches via samba-technical
>  wrote:
>> Create an ops variable to store tcon->ses->server->ops and cache
>> indirections and reduce code size a trivial bit.
>>
>> $ size fs/cifs/cifsacl.o*
>>textdata bss dec hex filename
>>5338 136   85482156a fs/cifs/cifsacl.o.new
>>5371 136   85515158b fs/cifs/cifsacl.o.old
>>
>> Signed-off-by: Joe Perches 
>> ---
>>  fs/cifs/cifsacl.c | 30 ++
>>  1 file changed, 14 insertions(+), 16 deletions(-)
>>
>> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
>> index 15bac390dff9..b98436f5c7c7 100644
>> --- a/fs/cifs/cifsacl.c
>> +++ b/fs/cifs/cifsacl.c
>> @@ -1135,20 +1135,19 @@ cifs_acl_to_fattr(struct cifs_sb_info *cifs_sb, 
>> struct cifs_fattr *fattr,
>> u32 acllen = 0;
>> int rc = 0;
>> struct tcon_link *tlink = cifs_sb_tlink(cifs_sb);
>> -   struct cifs_tcon *tcon;
>> +   struct smb_version_operations *ops;
>>
>> cifs_dbg(NOISY, "converting ACL to mode for %s\n", path);
>>
>> if (IS_ERR(tlink))
>> return PTR_ERR(tlink);
>> -   tcon = tlink_tcon(tlink);
>>
>> -   if (pfid && (tcon->ses->server->ops->get_acl_by_fid))
>> -   pntsd = tcon->ses->server->ops->get_acl_by_fid(cifs_sb, pfid,
>> - );
>> -   else if (tcon->ses->server->ops->get_acl)
>> -   pntsd = tcon->ses->server->ops->get_acl(cifs_sb, inode, path,
>> -   );
>> +   ops = tlink_tcon(tlink)->ses->server->ops;
>> +
>> +   if (pfid && (ops->get_acl_by_fid))
>> +   pntsd = ops->get_acl_by_fid(cifs_sb, pfid, );
>> +   else if (ops->get_acl)
>> +   pntsd = ops->get_acl(cifs_sb, inode, path, );
>> else {
>> cifs_put_tlink(tlink);
>> return -EOPNOTSUPP;
>> @@ -1181,23 +1180,23 @@ id_mode_to_cifs_acl(struct inode *inode, const char 
>> *path, __u64 nmode,
>> struct cifs_ntsd *pnntsd = NULL; /* modified acl to be sent to 
>> server */
>> struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
>> struct tcon_link *tlink = cifs_sb_tlink(cifs_sb);
>> -   struct cifs_tcon *tcon;
>> +   struct smb_version_operations *ops;
>>
>> if (IS_ERR(tlink))
>> return PTR_ERR(tlink);
>> -   tcon = tlink_tcon(tlink);
>> +
>> +   ops = tlink_tcon(tlink)->ses->server->ops;
>>
>> cifs_dbg(NOISY, "set ACL from mode for %s\n", path);
>>
>> /* Get the security descriptor */
>>
>> -   if (tcon->ses->server->ops->get_acl == NULL) {
>> +   if (ops->get_acl == NULL) {
>> cifs_put_tlink(tlink);
>> return -EOPNOTSUPP;
>> }
>>
>> -   pntsd = tcon->ses->server->ops->get_acl(cifs_sb, inode, path,
>> -   );
>> +   pntsd = ops->get_acl(cifs_sb, inode, path, );
>> if (IS_ERR(pntsd)) {
>> rc = PTR_ERR(pntsd);
>> cifs_dbg(VFS, "%s: error %d getting sec desc\n", __func__, 
>> rc);
>> @@ -1224,13 +1223,12 @@ id_mode_to_cifs_acl(struct inode *inode, const char 
>> *path, __u64 nmode,
>>
>> cifs_dbg(NOISY, "build_sec_desc rc: %d\n", rc);
>>
>> -   if (tcon->ses->server->ops->set_acl == NULL)
>> +   if (ops->set_acl == NULL)
>> rc = -EOPNOTSUPP;
>>
>> if (!rc) {
>> /* Set the security descriptor */
>> -   rc = tcon->ses->server->ops->set_acl(pnntsd, secdesclen, 
>> inode,
>> -path, aclflag);
>> +   rc = ops->set_acl(pnntsd, secdesclen, inode, path, aclflag);
>> cifs_dbg(NOISY, "set_cifs_acl rc: %d\n", rc);
>> }
>> cifs_put_tlink(tlink);
>> --
>> 2.10.0.rc2.1.g053435c
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve


Re: [PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

2017-05-12 Thread Brian Norris
On Sat, May 13, 2017 at 12:53:57AM +0100, Ian Campbell wrote:
> It not necessary and counter to how all the other files are done.
> 
> It also happens to break the build in the split device tree repo
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> 
> Signed-off-by: Ian Campbell 
> Cc: Brian Norris 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> index 658bb9dc9dfd..7bd31066399b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> @@ -44,7 +44,7 @@
>  
>  /dts-v1/;
>  #include "rk3399-gru.dtsi"
> -#include 
> +#include 

Whoops, didn't catch that when porting this to mainline. Thanks!

Reviewed-by: Brian Norris 

>  
>  /*
>   * Kevin-specific things
> -- 
> 2.11.0
> 


Re: [PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

2017-05-12 Thread Brian Norris
On Sat, May 13, 2017 at 12:53:57AM +0100, Ian Campbell wrote:
> It not necessary and counter to how all the other files are done.
> 
> It also happens to break the build in the split device tree repo
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> 
> Signed-off-by: Ian Campbell 
> Cc: Brian Norris 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> index 658bb9dc9dfd..7bd31066399b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> @@ -44,7 +44,7 @@
>  
>  /dts-v1/;
>  #include "rk3399-gru.dtsi"
> -#include 
> +#include 

Whoops, didn't catch that when porting this to mainline. Thanks!

Reviewed-by: Brian Norris 

>  
>  /*
>   * Kevin-specific things
> -- 
> 2.11.0
> 


Re: [PATCH v3 1/9] arm: dts: mt7623: add mt7623-mt6323.dtsi file

2017-05-12 Thread Fengguang Wu

On Fri, May 12, 2017 at 05:46:06PM +0200, Matthias Brugger wrote:



On 12/05/17 12:46, kbuild test robot wrote:

Hi John,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11 next-20170512]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]


Mediatek dts patches should be tested against this branch:
https://github.com/mbgg/linux-mediatek.git for-next


OK. I just send a patch for that.


Thanks for maintaining the kbuild test robot.


You are welcome!

Thanks,
Fengguang



url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/arm-dts-extend-mt7623-support/20170512-165138
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:33.1-7 Label or path pwrap not found
Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:261.1-6 Label or path mmc0 not found
Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:266.1-6 Label or path mmc1 not found

FATAL ERROR: Syntax error parsing input tree

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



Re: [PATCH v3 1/9] arm: dts: mt7623: add mt7623-mt6323.dtsi file

2017-05-12 Thread Fengguang Wu

On Fri, May 12, 2017 at 05:46:06PM +0200, Matthias Brugger wrote:



On 12/05/17 12:46, kbuild test robot wrote:

Hi John,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11 next-20170512]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]


Mediatek dts patches should be tested against this branch:
https://github.com/mbgg/linux-mediatek.git for-next


OK. I just send a patch for that.


Thanks for maintaining the kbuild test robot.


You are welcome!

Thanks,
Fengguang



url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/arm-dts-extend-mt7623-support/20170512-165138
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:33.1-7 Label or path pwrap not found
Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:261.1-6 Label or path mmc0 not found
Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:266.1-6 Label or path mmc1 not found

FATAL ERROR: Syntax error parsing input tree

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



Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings

2017-05-12 Thread Julia Lawall


On Fri, 12 May 2017, Florian Fainelli wrote:

> On 05/12/2017 09:22 AM, David Miller wrote:
> > From: Julia Lawall 
> > Date: Fri, 12 May 2017 22:54:23 +0800 (SGT)
> >
> >> Device node iterators put the previous value of the index variable, so an
> >> explicit put causes a double put.
> >  ...
> >> @@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
> >>if (r) {
> >>mdiobus_free(cb->mii_bus);
> >>devm_kfree(dev, cb);
> >> -  of_node_put(child_bus_node);
> >>} else {
> >
> > I think we're instead simply missing a break; statement here.
>
> It's kind of questionable, if we have an error initializing one of our
> child MDIO bus controller (child from the perspective of the MDIO mux,
> boy this is getting complicated...), should we keep on going, or should
> we abort entirely and rollback what we have successfully registered?
>
> I don't think Julia's patch makes thing worse, in that if we had to
> rollback, we would not be doing this correctly now anyway.

Just to be clear, if you want the break instead, then you need to keep the
put.

julia

>
> Jon, what do you think?
> --
> Florian
>


Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings

2017-05-12 Thread Julia Lawall


On Fri, 12 May 2017, Florian Fainelli wrote:

> On 05/12/2017 09:22 AM, David Miller wrote:
> > From: Julia Lawall 
> > Date: Fri, 12 May 2017 22:54:23 +0800 (SGT)
> >
> >> Device node iterators put the previous value of the index variable, so an
> >> explicit put causes a double put.
> >  ...
> >> @@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
> >>if (r) {
> >>mdiobus_free(cb->mii_bus);
> >>devm_kfree(dev, cb);
> >> -  of_node_put(child_bus_node);
> >>} else {
> >
> > I think we're instead simply missing a break; statement here.
>
> It's kind of questionable, if we have an error initializing one of our
> child MDIO bus controller (child from the perspective of the MDIO mux,
> boy this is getting complicated...), should we keep on going, or should
> we abort entirely and rollback what we have successfully registered?
>
> I don't think Julia's patch makes thing worse, in that if we had to
> rollback, we would not be doing this correctly now anyway.

Just to be clear, if you want the break instead, then you need to keep the
put.

julia

>
> Jon, what do you think?
> --
> Florian
>


Re: [v6 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

2017-05-12 Thread kbuild test robot
Hi Linu,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.11 next-20170512]
[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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/acpi/arm64/iort.c: In function 'arm_smmu_v3_init_resources':
>> drivers/acpi/arm64/iort.c:777:21: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>> undeclared (first use in this function)
 if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
^~~~
   drivers/acpi/arm64/iort.c:777:21: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +777 drivers/acpi/arm64/iort.c

   771  smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
   772  
   773  /*
   774   * Override the size, for Cavium ThunderX2 implementation
   775   * which doesn't support the page 1 SMMU register space.
   776   */
 > 777  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
   778  size = SZ_64K;
   779  
   780  res[num_res].start = smmu->base_address;

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


.config.gz
Description: application/gzip


Re: [v6 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

2017-05-12 Thread kbuild test robot
Hi Linu,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.11 next-20170512]
[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/Geetha-sowjanya/Cavium-ThunderX2-SMMUv3-errata-workarounds/20170513-065956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/acpi/arm64/iort.c: In function 'arm_smmu_v3_init_resources':
>> drivers/acpi/arm64/iort.c:777:21: error: 'ACPI_IORT_SMMU_CAVIUM_CN99XX' 
>> undeclared (first use in this function)
 if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
^~~~
   drivers/acpi/arm64/iort.c:777:21: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ACPI_IORT_SMMU_CAVIUM_CN99XX +777 drivers/acpi/arm64/iort.c

   771  smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
   772  
   773  /*
   774   * Override the size, for Cavium ThunderX2 implementation
   775   * which doesn't support the page 1 SMMU register space.
   776   */
 > 777  if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
   778  size = SZ_64K;
   779  
   780  res[num_res].start = smmu->base_address;

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


.config.gz
Description: application/gzip


[PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

2017-05-12 Thread Ian Campbell
It not necessary and counter to how all the other files are done.

It also happens to break the build in the split device tree repo
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Brian Norris 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658bb9dc9dfd..7bd31066399b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,7 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
-#include 
+#include 
 
 /*
  * Kevin-specific things
-- 
2.11.0



[PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

2017-05-12 Thread Ian Campbell
It not necessary and counter to how all the other files are done.

It also happens to break the build in the split device tree repo
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Brian Norris 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658bb9dc9dfd..7bd31066399b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,7 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
-#include 
+#include 
 
 /*
  * Kevin-specific things
-- 
2.11.0



Re: [PATCH] pinctrl: use non-devm kmalloc versions for free functions

2017-05-12 Thread André Przywara
On 12/05/17 18:14, Tony Lindgren wrote:
> * Tony Lindgren  [170512 08:39]:
>> * Linus Walleij  [170512 02:28]:
>>> On Thu, May 11, 2017 at 4:20 PM, Andre Przywara  
>>> wrote:
 Linus, can you shed some light if this array creation serves some purpose?
>>>
>>> Tony [author of this function] can you look at this?
>>>
>>> The code in pinctrl_generic_free_groups() does look a bit weird,
>>> allocating these indices just to remove the radix tree.
>>> Do you think we can clean it up?
>>
>> Yup indeed it seems totally pointless. Also the same code can be
>> removed from pinmux_generic_free_functions().
>>
>> It must be left over code from my initial attempts to to add
>> generic pinctrl groups and functions when I still though we need
>> to keep a static array around for the indices to keep pinctrl
>> happy. Then I probably did some robotic compile fixes after
>> updating things to use just the radix tree and added indices
>> locally to both functions..
> 
> Hmm no that, can't be, I think I figured it out.. See the patch
> below.
> 
> Regards,
> 
> Tony
> 
> 8< ---
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren 
> Date: Fri, 12 May 2017 08:47:57 -0700
> Subject: [PATCH] pinctrl: core: Fix warning by removing bogus code
> 
> Andre Przywara  noticed that we can get the
> following warning with -EPROBE_DEFER:
> 
> "WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349
> driver_probe_device+0x2ac/0x2e8"
> 
> Let's fix the issue by removing the indices as suggested by
> Tejun Heo . All we have to do here is kill the radix
> tree.
> 
> I probably ended up with the indices after grepping for removal
> of all entries using radix_tree_for_each_slot() and the first
> match found was gmap_radix_tree_free(). Anyways, no need for
> indices here, and we can just do remove all the entries using
> radix_tree_for_each_slot() along how the item_kill_tree() test
> case does.

Yeah, I was hoping for exactly that!

> Fixes: c7059c5ac70a ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Fixes: a76edc89b100 ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Reported-by: Andre Przywara 

Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara 

Thanks!
Andre

> Signed-off-by: Tony Lindgren 
> ---
>  drivers/pinctrl/core.c   | 20 +++-
>  drivers/pinctrl/pinmux.c | 21 -
>  2 files changed, 7 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -680,30 +680,16 @@ EXPORT_SYMBOL_GPL(pinctrl_generic_remove_group);
>   * pinctrl_generic_free_groups() - removes all pin groups
>   * @pctldev: pin controller device
>   *
> - * Note that the caller must take care of locking.
> + * Note that the caller must take care of locking. The pinctrl groups
> + * are allocated with devm_kzalloc() so no need to free them here.
>   */
>  static void pinctrl_generic_free_groups(struct pinctrl_dev *pctldev)
>  {
>   struct radix_tree_iter iter;
> - struct group_desc *group;
> - unsigned long *indices;
>   void **slot;
> - int i = 0;
> -
> - indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
> -pctldev->num_groups, GFP_KERNEL);
> - if (!indices)
> - return;
>  
>   radix_tree_for_each_slot(slot, >pin_group_tree, , 0)
> - indices[i++] = iter.index;
> -
> - for (i = 0; i < pctldev->num_groups; i++) {
> - group = radix_tree_lookup(>pin_group_tree,
> -   indices[i]);
> - radix_tree_delete(>pin_group_tree, indices[i]);
> - devm_kfree(pctldev->dev, group);
> - }
> + radix_tree_delete(>pin_group_tree, iter.index);
>  
>   pctldev->num_groups = 0;
>  }
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -826,30 +826,17 @@ EXPORT_SYMBOL_GPL(pinmux_generic_remove_function);
>   * pinmux_generic_free_functions() - removes all functions
>   * @pctldev: pin controller device
>   *
> - * Note that the caller must take care of locking.
> + * Note that the caller must take care of locking. The pinctrl
> + * functions are allocated with devm_kzalloc() so no need to free
> + * them here.
>   */
>  void pinmux_generic_free_functions(struct pinctrl_dev *pctldev)
>  {
>   struct radix_tree_iter iter;
> - struct function_desc *function;
> - unsigned long *indices;
>   void **slot;
> - int i = 0;
> -
> - indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
> -pctldev->num_functions, GFP_KERNEL);
> - if (!indices)
> -   

Re: [PATCH] pinctrl: use non-devm kmalloc versions for free functions

2017-05-12 Thread André Przywara
On 12/05/17 18:14, Tony Lindgren wrote:
> * Tony Lindgren  [170512 08:39]:
>> * Linus Walleij  [170512 02:28]:
>>> On Thu, May 11, 2017 at 4:20 PM, Andre Przywara  
>>> wrote:
 Linus, can you shed some light if this array creation serves some purpose?
>>>
>>> Tony [author of this function] can you look at this?
>>>
>>> The code in pinctrl_generic_free_groups() does look a bit weird,
>>> allocating these indices just to remove the radix tree.
>>> Do you think we can clean it up?
>>
>> Yup indeed it seems totally pointless. Also the same code can be
>> removed from pinmux_generic_free_functions().
>>
>> It must be left over code from my initial attempts to to add
>> generic pinctrl groups and functions when I still though we need
>> to keep a static array around for the indices to keep pinctrl
>> happy. Then I probably did some robotic compile fixes after
>> updating things to use just the radix tree and added indices
>> locally to both functions..
> 
> Hmm no that, can't be, I think I figured it out.. See the patch
> below.
> 
> Regards,
> 
> Tony
> 
> 8< ---
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren 
> Date: Fri, 12 May 2017 08:47:57 -0700
> Subject: [PATCH] pinctrl: core: Fix warning by removing bogus code
> 
> Andre Przywara  noticed that we can get the
> following warning with -EPROBE_DEFER:
> 
> "WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349
> driver_probe_device+0x2ac/0x2e8"
> 
> Let's fix the issue by removing the indices as suggested by
> Tejun Heo . All we have to do here is kill the radix
> tree.
> 
> I probably ended up with the indices after grepping for removal
> of all entries using radix_tree_for_each_slot() and the first
> match found was gmap_radix_tree_free(). Anyways, no need for
> indices here, and we can just do remove all the entries using
> radix_tree_for_each_slot() along how the item_kill_tree() test
> case does.

Yeah, I was hoping for exactly that!

> Fixes: c7059c5ac70a ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Fixes: a76edc89b100 ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Reported-by: Andre Przywara 

Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara 

Thanks!
Andre

> Signed-off-by: Tony Lindgren 
> ---
>  drivers/pinctrl/core.c   | 20 +++-
>  drivers/pinctrl/pinmux.c | 21 -
>  2 files changed, 7 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -680,30 +680,16 @@ EXPORT_SYMBOL_GPL(pinctrl_generic_remove_group);
>   * pinctrl_generic_free_groups() - removes all pin groups
>   * @pctldev: pin controller device
>   *
> - * Note that the caller must take care of locking.
> + * Note that the caller must take care of locking. The pinctrl groups
> + * are allocated with devm_kzalloc() so no need to free them here.
>   */
>  static void pinctrl_generic_free_groups(struct pinctrl_dev *pctldev)
>  {
>   struct radix_tree_iter iter;
> - struct group_desc *group;
> - unsigned long *indices;
>   void **slot;
> - int i = 0;
> -
> - indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
> -pctldev->num_groups, GFP_KERNEL);
> - if (!indices)
> - return;
>  
>   radix_tree_for_each_slot(slot, >pin_group_tree, , 0)
> - indices[i++] = iter.index;
> -
> - for (i = 0; i < pctldev->num_groups; i++) {
> - group = radix_tree_lookup(>pin_group_tree,
> -   indices[i]);
> - radix_tree_delete(>pin_group_tree, indices[i]);
> - devm_kfree(pctldev->dev, group);
> - }
> + radix_tree_delete(>pin_group_tree, iter.index);
>  
>   pctldev->num_groups = 0;
>  }
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -826,30 +826,17 @@ EXPORT_SYMBOL_GPL(pinmux_generic_remove_function);
>   * pinmux_generic_free_functions() - removes all functions
>   * @pctldev: pin controller device
>   *
> - * Note that the caller must take care of locking.
> + * Note that the caller must take care of locking. The pinctrl
> + * functions are allocated with devm_kzalloc() so no need to free
> + * them here.
>   */
>  void pinmux_generic_free_functions(struct pinctrl_dev *pctldev)
>  {
>   struct radix_tree_iter iter;
> - struct function_desc *function;
> - unsigned long *indices;
>   void **slot;
> - int i = 0;
> -
> - indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
> -pctldev->num_functions, GFP_KERNEL);
> - if (!indices)
> - return;
>  
>   radix_tree_for_each_slot(slot, >pin_function_tree, , 0)
> - indices[i++] = iter.index;
> -
> - for (i = 0; i < pctldev->num_functions; i++) {
> - function = 

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

2017-05-12 Thread Steven Rostedt
On Sat, 13 May 2017 00:15:03 +0200 (CEST)
Thomas Gleixner  wrote:

> On Fri, 12 May 2017, Steven Rostedt wrote:
> >  void get_online_cpus(void)
> >  {
> > +#ifdef CONFIG_LOCKDEP
> > +   if (current->goc_depth++)
> > +   return;  
> 
> This must be unconditional and not depend on lockdep. The percpu rwsem is
> going to deadlock silently otherwise when a writer is waiting 
> 

After I sent the updated changes to Paul, I realized this. But didn't
update it as I turned my attention to seeing if we can still get it
done without it.

But I'm not convinced that we can yet. I'll reply to Peter's email
again later.

-- Steve



Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

2017-05-12 Thread Steven Rostedt
On Sat, 13 May 2017 00:15:03 +0200 (CEST)
Thomas Gleixner  wrote:

> On Fri, 12 May 2017, Steven Rostedt wrote:
> >  void get_online_cpus(void)
> >  {
> > +#ifdef CONFIG_LOCKDEP
> > +   if (current->goc_depth++)
> > +   return;  
> 
> This must be unconditional and not depend on lockdep. The percpu rwsem is
> going to deadlock silently otherwise when a writer is waiting 
> 

After I sent the updated changes to Paul, I realized this. But didn't
update it as I turned my attention to seeing if we can still get it
done without it.

But I'm not convinced that we can yet. I'll reply to Peter's email
again later.

-- Steve



Re: [PATCH 4/5] dt-bindings: phy: Modify Broadcom NS USB 3.0 PHY binding to use MDIO

2017-05-12 Thread Rob Herring
On Thu, May 11, 2017 at 03:29:24PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Thanks to work done by Broadcom explaining their USB 3.0 PHY details we
> know it's attached to the MDIO bus. Use this knowledge to update the
> binding: make it a subnode to the MDIO bus and rework way of specifying
> required registers.

Please document here that you are breaking compatibility and why you 
think that is okay.

> 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../devicetree/bindings/phy/bcm-ns-usb3-phy.txt| 27 
> +++---
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt 
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> index 09aeba94538d..32f057260351 100644
> --- a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> @@ -3,9 +3,10 @@ Driver for Broadcom Northstar USB 3.0 PHY
>  Required properties:
>  
>  - compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
> -- reg: register mappings for DMP (Device Management Plugin) and ChipCommon B
> -   MMI.
> -- reg-names: "dmp" and "ccb-mii"
> +- reg: address of MDIO bus device
> +- usb3-dmp-syscon: phandle to syscon with DMP (Device Management Plugin)
> +registers
> +- #phy-cells: must be 0
>  
>  Initialization of USB 3.0 PHY depends on Northstar version. There are 
> currently
>  three known series: Ax, Bx and Cx.
> @@ -15,9 +16,19 @@ Known B1: BCM4707 rev 6
>  Known C0: BCM47094 rev 0
>  
>  Example:
> - usb3-phy {
> - compatible = "brcm,ns-ax-usb3-phy";
> - reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
> - reg-names = "dmp", "ccb-mii";
> - #phy-cells = <0>;
> + mdio: mdio@0 {
> + reg = <0x0>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + usb3-phy@10 {
> + compatible = "brcm,ns-ax-usb3-phy";
> + reg = <0x10>;
> + usb3-dmp-syscon = <_dmp>;
> + #phy-cells = <0>;
> + };
> + };
> +
> + usb3_dmp: syscon@18105000 {
> + reg = <0x18105000 0x1000>;
>   };
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/5] dt-bindings: phy: Modify Broadcom NS USB 3.0 PHY binding to use MDIO

2017-05-12 Thread Rob Herring
On Thu, May 11, 2017 at 03:29:24PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Thanks to work done by Broadcom explaining their USB 3.0 PHY details we
> know it's attached to the MDIO bus. Use this knowledge to update the
> binding: make it a subnode to the MDIO bus and rework way of specifying
> required registers.

Please document here that you are breaking compatibility and why you 
think that is okay.

> 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../devicetree/bindings/phy/bcm-ns-usb3-phy.txt| 27 
> +++---
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt 
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> index 09aeba94538d..32f057260351 100644
> --- a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> @@ -3,9 +3,10 @@ Driver for Broadcom Northstar USB 3.0 PHY
>  Required properties:
>  
>  - compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
> -- reg: register mappings for DMP (Device Management Plugin) and ChipCommon B
> -   MMI.
> -- reg-names: "dmp" and "ccb-mii"
> +- reg: address of MDIO bus device
> +- usb3-dmp-syscon: phandle to syscon with DMP (Device Management Plugin)
> +registers
> +- #phy-cells: must be 0
>  
>  Initialization of USB 3.0 PHY depends on Northstar version. There are 
> currently
>  three known series: Ax, Bx and Cx.
> @@ -15,9 +16,19 @@ Known B1: BCM4707 rev 6
>  Known C0: BCM47094 rev 0
>  
>  Example:
> - usb3-phy {
> - compatible = "brcm,ns-ax-usb3-phy";
> - reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
> - reg-names = "dmp", "ccb-mii";
> - #phy-cells = <0>;
> + mdio: mdio@0 {
> + reg = <0x0>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + usb3-phy@10 {
> + compatible = "brcm,ns-ax-usb3-phy";
> + reg = <0x10>;
> + usb3-dmp-syscon = <_dmp>;
> + #phy-cells = <0>;
> + };
> + };
> +
> + usb3_dmp: syscon@18105000 {
> + reg = <0x18105000 0x1000>;
>   };
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] dt-bindings: Document STM32 I2S bindings

2017-05-12 Thread Rob Herring
On Thu, May 11, 2017 at 11:45:02AM +0200, olivier moysan wrote:
> Add documentation of device tree bindings for STM32 SPI/I2S.
> 
> Signed-off-by: olivier moysan 
> ---
>  .../devicetree/bindings/sound/st,stm32-i2s.txt | 68 
> ++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt 
> b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> new file mode 100644
> index 000..67b854a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> @@ -0,0 +1,68 @@
> +STMicroelectronics STM32 SPI/I2S Controller
> +
> +The SPI/I2S block supports I2S/PCM protocols when configured on I2S mode.
> +Only some SPI instances support I2S.
> +
> +Required properties:
> +  - compatible: Must be "st,stm32h7-i2s"
> +  - reg: Offset and length of the device's register set.
> +  - interrupts: Must contain the interrupt line id.
> +  - clocks: Must contain phandle and clock specifier pairs for each entry
> + in clock-names.
> +  - clock-names: Must contain "i2sclk", "pclk", "x8k" and "x11k".
> + "i2sclk": clock which feeds the internal clock generator
> + "pclk": clock which feeds the peripheral bus interface
> + "x8k": I2S parent clock for sampling rates multiple of 8kHz.
> + "x11k": I2S parent clock for sampling rates multiple of 11.025kHz.
> +  - dmas: DMA specifiers for tx and rx dma.
> +See Documentation/devicetree/bindings/dma/stm32-dma.txt.
> +  - dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
> +  - pinctrl-names: should contain only value "default"
> +  - pinctrl-0: see 
> Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> +
> +Optional properties:
> +  - resets: Reference to a reset controller asserting the reset controller
> +
> +The device node should contain one 'port' child node with one child 
> 'endpoint'
> +node, according to the bindings defined in Documentation/devicetree/bindings/
> +graph.txt.
> +
> +Example:
> +sound_card {
> + compatible = "audio-graph-card";
> + dais = <_port 0>;

What is the 0 representing?

> +};
> +
> +i2s2: audio-controller@40003800 {
> + compatible = "st,stm32h7-i2s";
> + #sound-dai-cells = <0>;

Should be dropped.

> + reg = <0x40003800 0x400>;
> + interrupts = <36>;
> + clocks = < PCLK1>, < SPI2_CK>, < PLL1_Q>, < PLL2_P>;
> + clock-names = "pclk", "i2sclk",  "x8k", "x11k";
> + dmas = < 2 39 0x400 0x1>,
> +   < 3 40 0x400 0x1>;
> + dma-names = "rx", "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2s2>;
> +
> + i2s2_port: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;

This shouldn't even compile. You don't need these because because you 
have no reg property in the endpoint. 

You have a unit-address here w/o a reg property. You don't need a reg 
prop because you only have 1 port.

> +
> + cpu_endpoint: endpoint {
> + remote-endpoint = <_endpoint>;
> + format = "i2s";
> + bitclock-master = <_endpoint>;
> + frame-master = <_endpoint>;
> + };
> + };
> +};
> +
> +audio-codec {
> + codec_port: port@0 {
> + codec_endpoint: endpoint {
> + remote-endpoint = <_endpoint>;
> + };
> + };
> +};
> -- 
> 1.9.1
> 


Re: [PATCH v3 1/3] dt-bindings: Document STM32 I2S bindings

2017-05-12 Thread Rob Herring
On Thu, May 11, 2017 at 11:45:02AM +0200, olivier moysan wrote:
> Add documentation of device tree bindings for STM32 SPI/I2S.
> 
> Signed-off-by: olivier moysan 
> ---
>  .../devicetree/bindings/sound/st,stm32-i2s.txt | 68 
> ++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt 
> b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> new file mode 100644
> index 000..67b854a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> @@ -0,0 +1,68 @@
> +STMicroelectronics STM32 SPI/I2S Controller
> +
> +The SPI/I2S block supports I2S/PCM protocols when configured on I2S mode.
> +Only some SPI instances support I2S.
> +
> +Required properties:
> +  - compatible: Must be "st,stm32h7-i2s"
> +  - reg: Offset and length of the device's register set.
> +  - interrupts: Must contain the interrupt line id.
> +  - clocks: Must contain phandle and clock specifier pairs for each entry
> + in clock-names.
> +  - clock-names: Must contain "i2sclk", "pclk", "x8k" and "x11k".
> + "i2sclk": clock which feeds the internal clock generator
> + "pclk": clock which feeds the peripheral bus interface
> + "x8k": I2S parent clock for sampling rates multiple of 8kHz.
> + "x11k": I2S parent clock for sampling rates multiple of 11.025kHz.
> +  - dmas: DMA specifiers for tx and rx dma.
> +See Documentation/devicetree/bindings/dma/stm32-dma.txt.
> +  - dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
> +  - pinctrl-names: should contain only value "default"
> +  - pinctrl-0: see 
> Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> +
> +Optional properties:
> +  - resets: Reference to a reset controller asserting the reset controller
> +
> +The device node should contain one 'port' child node with one child 
> 'endpoint'
> +node, according to the bindings defined in Documentation/devicetree/bindings/
> +graph.txt.
> +
> +Example:
> +sound_card {
> + compatible = "audio-graph-card";
> + dais = <_port 0>;

What is the 0 representing?

> +};
> +
> +i2s2: audio-controller@40003800 {
> + compatible = "st,stm32h7-i2s";
> + #sound-dai-cells = <0>;

Should be dropped.

> + reg = <0x40003800 0x400>;
> + interrupts = <36>;
> + clocks = < PCLK1>, < SPI2_CK>, < PLL1_Q>, < PLL2_P>;
> + clock-names = "pclk", "i2sclk",  "x8k", "x11k";
> + dmas = < 2 39 0x400 0x1>,
> +   < 3 40 0x400 0x1>;
> + dma-names = "rx", "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2s2>;
> +
> + i2s2_port: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;

This shouldn't even compile. You don't need these because because you 
have no reg property in the endpoint. 

You have a unit-address here w/o a reg property. You don't need a reg 
prop because you only have 1 port.

> +
> + cpu_endpoint: endpoint {
> + remote-endpoint = <_endpoint>;
> + format = "i2s";
> + bitclock-master = <_endpoint>;
> + frame-master = <_endpoint>;
> + };
> + };
> +};
> +
> +audio-codec {
> + codec_port: port@0 {
> + codec_endpoint: endpoint {
> + remote-endpoint = <_endpoint>;
> + };
> + };
> +};
> -- 
> 1.9.1
> 


[v1 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM

2017-05-12 Thread Thang Q. Nguyen
XHCI specification 1.1 does not require xHCI 1.0 compliant controllers
to always enable hardware USB2 LPM.
However, the current xHCI driver always enable it by setting HLE=1 when
seeing HLC=1. This makes certain xHCI controllers that have broken USB2
HW LPM fail to work as there is no way to disable this feature.
This patch adds support to control disabling USB2 Hardware LPM via
DT/ACPI attribute.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |1 +
 drivers/usb/host/xhci-plat.c   |3 +++
 drivers/usb/host/xhci.c|7 ++-
 drivers/usb/host/xhci.h|1 +
 4 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 2d80b60..b5da569 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -26,6 +26,7 @@ Required properties:
 
 Optional properties:
   - clocks: reference to a clock
+  - usb2-hle-disable: disable USB2 LPM for hardware does not support it
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 7c2a9e7..7d316bc 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
 
+   if (device_property_read_bool(>dev, "usb2-hle-disable"))
+   xhci->quirks |= XHCI_HLE_DISABLE;
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2d13102..4ad243a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4055,6 +4055,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
unsigned long   flags;
int hird, exit_latency;
int ret;
+   int disable_hle = 0;
 
if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support ||
!udev->lpm_capable)
@@ -4079,7 +4080,11 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd 
*hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
 
-   if (enable) {
+   /* Check for optional disable HLE if XHCI 1.0 */
+   if ((xhci->quirks & XHCI_HLE_DISABLE) && (xhci->hci_version == 0x100))
+   disable_hle = 1;
+
+   if (enable && !disable_hle) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..44ca323 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,7 @@ struct xhci_hcd {
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
+#define XHCI_HLE_DISABLE   (1 << 27)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
1.7.1



[v1 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM

2017-05-12 Thread Thang Q. Nguyen
XHCI specification 1.1 does not require xHCI 1.0 compliant controllers
to always enable hardware USB2 LPM.
However, the current xHCI driver always enable it by setting HLE=1 when
seeing HLC=1. This makes certain xHCI controllers that have broken USB2
HW LPM fail to work as there is no way to disable this feature.
This patch adds support to control disabling USB2 Hardware LPM via
DT/ACPI attribute.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |1 +
 drivers/usb/host/xhci-plat.c   |3 +++
 drivers/usb/host/xhci.c|7 ++-
 drivers/usb/host/xhci.h|1 +
 4 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 2d80b60..b5da569 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -26,6 +26,7 @@ Required properties:
 
 Optional properties:
   - clocks: reference to a clock
+  - usb2-hle-disable: disable USB2 LPM for hardware does not support it
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 7c2a9e7..7d316bc 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
 
+   if (device_property_read_bool(>dev, "usb2-hle-disable"))
+   xhci->quirks |= XHCI_HLE_DISABLE;
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2d13102..4ad243a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4055,6 +4055,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
unsigned long   flags;
int hird, exit_latency;
int ret;
+   int disable_hle = 0;
 
if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support ||
!udev->lpm_capable)
@@ -4079,7 +4080,11 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd 
*hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
 
-   if (enable) {
+   /* Check for optional disable HLE if XHCI 1.0 */
+   if ((xhci->quirks & XHCI_HLE_DISABLE) && (xhci->hci_version == 0x100))
+   disable_hle = 1;
+
+   if (enable && !disable_hle) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..44ca323 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,7 @@ struct xhci_hcd {
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
+#define XHCI_HLE_DISABLE   (1 << 27)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
1.7.1



Re: [RESEND PATCH v4 4/5] dt-bindings: usb: DT bindings documentation for Broadcom IPROC USB Device controller.

2017-05-12 Thread Rob Herring
On Wed, May 10, 2017 at 06:48:08PM +0530, Raviteja Garimella wrote:
> The device node is used for UDCs integrated into Broadcom's
> iProc family of SoCs'. The UDC is based on Synopsys Designware
> Cores AHB Subsystem USB Device Controller IP.
> 
> Signed-off-by: Raviteja Garimella 
> ---
>  Documentation/devicetree/bindings/usb/iproc-udc.txt | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/iproc-udc.txt

Acked-by: Rob Herring 


Re: [RESEND PATCH v4 4/5] dt-bindings: usb: DT bindings documentation for Broadcom IPROC USB Device controller.

2017-05-12 Thread Rob Herring
On Wed, May 10, 2017 at 06:48:08PM +0530, Raviteja Garimella wrote:
> The device node is used for UDCs integrated into Broadcom's
> iProc family of SoCs'. The UDC is based on Synopsys Designware
> Cores AHB Subsystem USB Device Controller IP.
> 
> Signed-off-by: Raviteja Garimella 
> ---
>  Documentation/devicetree/bindings/usb/iproc-udc.txt | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/iproc-udc.txt

Acked-by: Rob Herring 


Re: [PATCH v5 14/17] dt-bindings: slave-device: add current-speed property

2017-05-12 Thread Rob Herring
On Wed, May 10, 2017 at 10:53:25AM +0200, Stefan Wahren wrote:
> This adds a new DT property to define the current baud rate of the
> slave device.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  Documentation/devicetree/bindings/serial/slave-device.txt | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Rob Herring 


Re: [PATCH v5 14/17] dt-bindings: slave-device: add current-speed property

2017-05-12 Thread Rob Herring
On Wed, May 10, 2017 at 10:53:25AM +0200, Stefan Wahren wrote:
> This adds a new DT property to define the current baud rate of the
> slave device.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  Documentation/devicetree/bindings/serial/slave-device.txt | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Rob Herring 


Re: [PATCH v6 3/4] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 12:47:02PM -0700, Bjorn Andersson wrote:
> Introduce a binding for the Qualcomm APCS global block, exposing a
> mailbox for invoking interrupts on remote processors in the system.
> 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v5:
> - None
> 
>  .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt

Acked-by: Rob Herring 


Re: [PATCH v6 3/4] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 12:47:02PM -0700, Bjorn Andersson wrote:
> Introduce a binding for the Qualcomm APCS global block, exposing a
> mailbox for invoking interrupts on remote processors in the system.
> 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v5:
> - None
> 
>  .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt

Acked-by: Rob Herring 


Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> This adds a binding for the Maxim/Dallas DS1374 MFD.
> 
> Signed-off-by: Moritz Fischer 
> ---
> 
> Hi all,
> 
> I'm not entirely sure aobut the binding, does anyone
> have a better suggestion for the remap-wdt-reset property?
> 
> Thanks,
> 
> Moritz
> 
> ---
>  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> ++
>  .../devicetree/bindings/trivial-devices.txt|  1 -
>  drivers/rtc/Kconfig|  2 +
>  3 files changed, 65 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> b/Documentation/devicetree/bindings/mfd/ds1374.txt
> new file mode 100644
> index 000..b22396f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> @@ -0,0 +1,63 @@
> +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> +
> +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> +watchdog or alarm, as well as trickle charger.
> +
> +The DS1374 is connected via I2C.
> +
> +Required properties:
> +- compatible: "dallas,ds1374"
> +- reg: I2C slave address
> +- dallas,ds1374-mode: Should be one of the following values:

Just "dallas,mode" is sufficient.

> + <0> for RTC
> + <1> for RTC + Alarm (Interrupt)
> + <2> for RTC + Watchdog
> +
> +Required child:
> +A single available child device of type matching the "dallas,ds1374-mode"
> +property.
> +
> +Optional properties (watchdog):
> +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> +  on the device is used as interrupt for
> +  the alarm

Isn't presence of the interrupt property or not enough? It would be 
kind of useless to have no interrupt and also not do anything on 
timeout.

> +
> +See ../watchdog/* for generic watchdog bindings.
> +
> +Optional properties (real time clock):
> +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> +
> +See ../rtc/* for generic rtc bindings.
> +
> +Optional properties (trickle-charger):
> +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> + Values usable for ds1374 are 250, 2000, 4000
> + Should be given if trickle charger should be enabled
> +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> + Should be given if internal trickle charger diode should be disabled
> +
> +Example for rtc with alarm mode and interrupt:
> +
> +i2c@12ca {
> + rtc@68 {
> + compatible = "ds1374";
> + reg = <0x68>;
> + interrupts = < 62>;
> + dallas,ds1374-mode = <2>
> +
> + dallas,trickle-resistor-ohms = <250>;
> + dallas,trickle-diode-disable;
> + };
> +};
> +
> +Example for rtc with watchdog and reset on timeout, with reset remapped
> +to the INT pin:
> +
> +i2c@12ca {
> + rtc@68 {
> + compatible = "ds1374";
> + reg = <0x68>;
> + dallas,ds1374-mode = <2>
> + dallas,ds1374-remap-wdt-reset;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> b/Documentation/devicetree/bindings/trivial-devices.txt
> index 3e0a34c..f7a50e5 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> @@ -29,7 +29,6 @@ cirrus,cs42l51  Cirrus Logic CS42L51 audio codec
>  dallas,ds130764 x 8, Serial, I2C Real-Time Clock
>  dallas,ds1338I2C RTC with 56-Byte NV RAM
>  dallas,ds1340I2C RTC with Trickle Charger
> -dallas,ds1374I2C, 32-Bit Binary Counter Watchdog RTC with 
> Trickle Charger and Reset Input/Output
>  dallas,ds1631High-Precision Digital Thermometer
>  dallas,ds1682Total-Elapsed-Time Recorder with Alarm
>  dallas,ds1775Tiny Digital Thermometer and Thermostat
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 8d3b957..e6763fe 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
>  
>  config RTC_DRV_DS1374
>   tristate "Dallas/Maxim DS1374"
> + depends on MFD_DS1374
> + depends on REGMAP_I2C
>   help
> If you say yes here you get support for Dallas Semiconductor
> DS1374 real-time clock chips. If an interrupt is associated
> -- 
> 2.7.4
> 


Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> This adds a binding for the Maxim/Dallas DS1374 MFD.
> 
> Signed-off-by: Moritz Fischer 
> ---
> 
> Hi all,
> 
> I'm not entirely sure aobut the binding, does anyone
> have a better suggestion for the remap-wdt-reset property?
> 
> Thanks,
> 
> Moritz
> 
> ---
>  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> ++
>  .../devicetree/bindings/trivial-devices.txt|  1 -
>  drivers/rtc/Kconfig|  2 +
>  3 files changed, 65 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> b/Documentation/devicetree/bindings/mfd/ds1374.txt
> new file mode 100644
> index 000..b22396f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> @@ -0,0 +1,63 @@
> +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> +
> +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> +watchdog or alarm, as well as trickle charger.
> +
> +The DS1374 is connected via I2C.
> +
> +Required properties:
> +- compatible: "dallas,ds1374"
> +- reg: I2C slave address
> +- dallas,ds1374-mode: Should be one of the following values:

Just "dallas,mode" is sufficient.

> + <0> for RTC
> + <1> for RTC + Alarm (Interrupt)
> + <2> for RTC + Watchdog
> +
> +Required child:
> +A single available child device of type matching the "dallas,ds1374-mode"
> +property.
> +
> +Optional properties (watchdog):
> +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> +  on the device is used as interrupt for
> +  the alarm

Isn't presence of the interrupt property or not enough? It would be 
kind of useless to have no interrupt and also not do anything on 
timeout.

> +
> +See ../watchdog/* for generic watchdog bindings.
> +
> +Optional properties (real time clock):
> +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> +
> +See ../rtc/* for generic rtc bindings.
> +
> +Optional properties (trickle-charger):
> +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> + Values usable for ds1374 are 250, 2000, 4000
> + Should be given if trickle charger should be enabled
> +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> + Should be given if internal trickle charger diode should be disabled
> +
> +Example for rtc with alarm mode and interrupt:
> +
> +i2c@12ca {
> + rtc@68 {
> + compatible = "ds1374";
> + reg = <0x68>;
> + interrupts = < 62>;
> + dallas,ds1374-mode = <2>
> +
> + dallas,trickle-resistor-ohms = <250>;
> + dallas,trickle-diode-disable;
> + };
> +};
> +
> +Example for rtc with watchdog and reset on timeout, with reset remapped
> +to the INT pin:
> +
> +i2c@12ca {
> + rtc@68 {
> + compatible = "ds1374";
> + reg = <0x68>;
> + dallas,ds1374-mode = <2>
> + dallas,ds1374-remap-wdt-reset;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> b/Documentation/devicetree/bindings/trivial-devices.txt
> index 3e0a34c..f7a50e5 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> @@ -29,7 +29,6 @@ cirrus,cs42l51  Cirrus Logic CS42L51 audio codec
>  dallas,ds130764 x 8, Serial, I2C Real-Time Clock
>  dallas,ds1338I2C RTC with 56-Byte NV RAM
>  dallas,ds1340I2C RTC with Trickle Charger
> -dallas,ds1374I2C, 32-Bit Binary Counter Watchdog RTC with 
> Trickle Charger and Reset Input/Output
>  dallas,ds1631High-Precision Digital Thermometer
>  dallas,ds1682Total-Elapsed-Time Recorder with Alarm
>  dallas,ds1775Tiny Digital Thermometer and Thermostat
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 8d3b957..e6763fe 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
>  
>  config RTC_DRV_DS1374
>   tristate "Dallas/Maxim DS1374"
> + depends on MFD_DS1374
> + depends on REGMAP_I2C
>   help
> If you say yes here you get support for Dallas Semiconductor
> DS1374 real-time clock chips. If an interrupt is associated
> -- 
> 2.7.4
> 


Re: [PATCH] dt-bindings: Document optional "reserved-names" property

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 10:18:47AM -0700, Florian Fainelli wrote:
> Define an optional string property: "reserved-names" which can be used
> by the client program to tag/identify reserved memory regions.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt | 4 
> 
>  1 file changed, 4 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 3da0ebdba8d9..bd3c9485f637 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -64,6 +64,10 @@ reusable (optional) - empty property
>system can use that region to store volatile or cached data that
>can be otherwise regenerated or migrated elsewhere.
>  
> +reserved-names (optional)
> +- Provides a named tag to the client program to help pretty 
> print/identify
> +  the reserved memory region.

*-names is normally on the client side. I'd like to keep that 
consistent.

Second, I don't see the need for this. The compatible is not enough?

Rob


Re: [PATCH] dt-bindings: Document optional "reserved-names" property

2017-05-12 Thread Rob Herring
On Tue, May 09, 2017 at 10:18:47AM -0700, Florian Fainelli wrote:
> Define an optional string property: "reserved-names" which can be used
> by the client program to tag/identify reserved memory regions.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt | 4 
> 
>  1 file changed, 4 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 3da0ebdba8d9..bd3c9485f637 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -64,6 +64,10 @@ reusable (optional) - empty property
>system can use that region to store volatile or cached data that
>can be otherwise regenerated or migrated elsewhere.
>  
> +reserved-names (optional)
> +- Provides a named tag to the client program to help pretty 
> print/identify
> +  the reserved memory region.

*-names is normally on the client side. I'd like to keep that 
consistent.

Second, I don't see the need for this. The compatible is not enough?

Rob


Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

2017-05-12 Thread Andy Lutomirski
On Fri, May 12, 2017 at 7:34 AM,   wrote:
>>Yes, mostly.  I've written the patch, but I was planning to target it
>>at 4.12 or 4.13 but not -stable.  It's mostly just a cleanup and has
>>no real power saving benefit since the RSTe timeouts are so absurdly
>>conservative that I doubt PS4 will happen in practical usage.
> OK.
>
>>Perhaps
>>in suspend-to-idle?  (For suspend-to-idle, I suspect we should really
>>be using D3 instead.  Do we already do that?)
>
> Well I think this will depend upon what the SSD "will" support.

I thought it was basically impossible for the SSD to fail to support
D3.  Afterall, cutting the power due to runtime D3 is more or less the
same thing (from the SSD's POV) as cutting the power during S3 or full
power off.

I've contemplated adding runtime D3 support to the nvme driver, but it
would probably be barely a win and quite slow.

When Linux suspends-to-idle, does it call driver suspend callbacks and
kick devices into D3?  It should work, but I don't know what actually
happens.


Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

2017-05-12 Thread Andy Lutomirski
On Fri, May 12, 2017 at 7:34 AM,   wrote:
>>Yes, mostly.  I've written the patch, but I was planning to target it
>>at 4.12 or 4.13 but not -stable.  It's mostly just a cleanup and has
>>no real power saving benefit since the RSTe timeouts are so absurdly
>>conservative that I doubt PS4 will happen in practical usage.
> OK.
>
>>Perhaps
>>in suspend-to-idle?  (For suspend-to-idle, I suspect we should really
>>be using D3 instead.  Do we already do that?)
>
> Well I think this will depend upon what the SSD "will" support.

I thought it was basically impossible for the SSD to fail to support
D3.  Afterall, cutting the power due to runtime D3 is more or less the
same thing (from the SSD's POV) as cutting the power during S3 or full
power off.

I've contemplated adding runtime D3 support to the nvme driver, but it
would probably be barely a win and quite slow.

When Linux suspends-to-idle, does it call driver suspend callbacks and
kick devices into D3?  It should work, but I don't know what actually
happens.


[PATCH v2] Add "shutdown" to "struct class".

2017-05-12 Thread Josh Zimmerman
The TPM class has some common shutdown code that must be executed for
all drivers. This adds some needed functionality for that.

(In addition, update a comment to reflect an out-of-date path.)

Signed-off-by: Josh Zimmerman 
---
 drivers/base/core.c| 5 +
 include/linux/device.h | 4 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..5c1648875e94 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2667,6 +2667,11 @@ void device_shutdown(void)
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
 
+   if (dev->class && dev->class->shutdown) {
+   if (initcall_debug)
+   dev_info(dev, "shutdown\n");
+   dev->class->shutdown(dev);
+   }
if (dev->bus && dev->bus->shutdown) {
if (initcall_debug)
dev_info(dev, "shutdown\n");
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..a150f8d3b3f1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
  * @suspend:   Used to put the device to sleep mode, usually to a low power
  * state.
  * @resume:Used to bring the device from the sleep mode.
+ * @shutdown:  Called at shut-down time to quiesce the device.
  * @ns_type:   Callbacks so sysfs can detemine namespaces.
  * @namespace: Namespace of the device belongs to this class.
  * @pm:The default device power management operations of this 
class.
@@ -407,6 +408,7 @@ struct class {
 
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
+   int (*shutdown)(struct device *dev);
 
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
@@ -1228,7 +1230,7 @@ static inline int devtmpfs_delete_node(struct device 
*dev) { return 0; }
 static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
 #endif
 
-/* drivers/base/power/shutdown.c */
+/* drivers/base/core.c */
 extern void device_shutdown(void);
 
 /* debugging and troubleshooting/diagnostic helpers. */
-- 
2.13.0.rc2.291.g57267f2277-goog



[PATCH v2] Add "shutdown" to "struct class".

2017-05-12 Thread Josh Zimmerman
The TPM class has some common shutdown code that must be executed for
all drivers. This adds some needed functionality for that.

(In addition, update a comment to reflect an out-of-date path.)

Signed-off-by: Josh Zimmerman 
---
 drivers/base/core.c| 5 +
 include/linux/device.h | 4 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..5c1648875e94 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2667,6 +2667,11 @@ void device_shutdown(void)
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
 
+   if (dev->class && dev->class->shutdown) {
+   if (initcall_debug)
+   dev_info(dev, "shutdown\n");
+   dev->class->shutdown(dev);
+   }
if (dev->bus && dev->bus->shutdown) {
if (initcall_debug)
dev_info(dev, "shutdown\n");
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..a150f8d3b3f1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
  * @suspend:   Used to put the device to sleep mode, usually to a low power
  * state.
  * @resume:Used to bring the device from the sleep mode.
+ * @shutdown:  Called at shut-down time to quiesce the device.
  * @ns_type:   Callbacks so sysfs can detemine namespaces.
  * @namespace: Namespace of the device belongs to this class.
  * @pm:The default device power management operations of this 
class.
@@ -407,6 +408,7 @@ struct class {
 
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
+   int (*shutdown)(struct device *dev);
 
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
@@ -1228,7 +1230,7 @@ static inline int devtmpfs_delete_node(struct device 
*dev) { return 0; }
 static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
 #endif
 
-/* drivers/base/power/shutdown.c */
+/* drivers/base/core.c */
 extern void device_shutdown(void);
 
 /* debugging and troubleshooting/diagnostic helpers. */
-- 
2.13.0.rc2.291.g57267f2277-goog



[PATCH] Add "shutdown" to "struct class".

2017-05-12 Thread Josh Zimmerman
The TPM class has some common shutdown code that must be executed for
all drivers. This adds some needed functionality for that.

(In addition, update a comment to reflect an out-of-date path.)
---
 drivers/base/core.c| 5 +
 include/linux/device.h | 4 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..5c1648875e94 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2667,6 +2667,11 @@ void device_shutdown(void)
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
 
+   if (dev->class && dev->class->shutdown) {
+   if (initcall_debug)
+   dev_info(dev, "shutdown\n");
+   dev->class->shutdown(dev);
+   }
if (dev->bus && dev->bus->shutdown) {
if (initcall_debug)
dev_info(dev, "shutdown\n");
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..a150f8d3b3f1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
  * @suspend:   Used to put the device to sleep mode, usually to a low power
  * state.
  * @resume:Used to bring the device from the sleep mode.
+ * @shutdown:  Called at shut-down time to quiesce the device.
  * @ns_type:   Callbacks so sysfs can detemine namespaces.
  * @namespace: Namespace of the device belongs to this class.
  * @pm:The default device power management operations of this 
class.
@@ -407,6 +408,7 @@ struct class {
 
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
+   int (*shutdown)(struct device *dev);
 
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
@@ -1228,7 +1230,7 @@ static inline int devtmpfs_delete_node(struct device 
*dev) { return 0; }
 static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
 #endif
 
-/* drivers/base/power/shutdown.c */
+/* drivers/base/core.c */
 extern void device_shutdown(void);
 
 /* debugging and troubleshooting/diagnostic helpers. */
-- 
2.13.0.rc2.291.g57267f2277-goog



[PATCH] Add "shutdown" to "struct class".

2017-05-12 Thread Josh Zimmerman
The TPM class has some common shutdown code that must be executed for
all drivers. This adds some needed functionality for that.

(In addition, update a comment to reflect an out-of-date path.)
---
 drivers/base/core.c| 5 +
 include/linux/device.h | 4 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..5c1648875e94 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2667,6 +2667,11 @@ void device_shutdown(void)
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
 
+   if (dev->class && dev->class->shutdown) {
+   if (initcall_debug)
+   dev_info(dev, "shutdown\n");
+   dev->class->shutdown(dev);
+   }
if (dev->bus && dev->bus->shutdown) {
if (initcall_debug)
dev_info(dev, "shutdown\n");
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..a150f8d3b3f1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
  * @suspend:   Used to put the device to sleep mode, usually to a low power
  * state.
  * @resume:Used to bring the device from the sleep mode.
+ * @shutdown:  Called at shut-down time to quiesce the device.
  * @ns_type:   Callbacks so sysfs can detemine namespaces.
  * @namespace: Namespace of the device belongs to this class.
  * @pm:The default device power management operations of this 
class.
@@ -407,6 +408,7 @@ struct class {
 
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
+   int (*shutdown)(struct device *dev);
 
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
@@ -1228,7 +1230,7 @@ static inline int devtmpfs_delete_node(struct device 
*dev) { return 0; }
 static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
 #endif
 
-/* drivers/base/power/shutdown.c */
+/* drivers/base/core.c */
 extern void device_shutdown(void);
 
 /* debugging and troubleshooting/diagnostic helpers. */
-- 
2.13.0.rc2.291.g57267f2277-goog



[PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

2017-05-12 Thread Mahesh Bandewar
From: Mahesh Bandewar 

A process inside random user-ns should not load a module, which is
currently possible. As demonstrated in following scenario -

  Create namespaces; especially a user-ns and become root inside.
  $ unshare -rfUp -- unshare -unm -- bash

  Try to load the bridge module. It should fail and this is expected!
  #  modprobe bridge
  WARNING: Error inserting stp 
(/lib/modules/4.11.0-smp-DEV/kernel/net/802/stp.ko): Operation not permitted
  FATAL: Error inserting bridge 
(/lib/modules/4.11.0-smp-DEV/kernel/net/bridge/bridge.ko): Operation not 
permitted

  Verify bridge module is not loaded.
  # lsmod | grep bridge
  #

  Now try to create a bridge inside this newly created net-ns which would
  mean bridge module need to be loaded.
  # ip link add br0 type bridge
  # echo $?
  0
  # lsmod | grep bridge
  bridge110592  0
  stp16384  1 bridge
  llc16384  2 bridge,stp
  #

  After this patch -
  # ip link add br0 type bridge
  RTNETLINK answers: Operation not supported
  # echo $?
  2
  # lsmod | grep bridge
  #

Signed-off-by: Mahesh Bandewar 
---
 kernel/kmod.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 563f97e2be36..ac30157169b7 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -133,6 +133,9 @@ int __request_module(bool wait, const char *fmt, ...)
 #define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
static int kmod_loop_msg;
 
+   if (!capable(CAP_SYS_MODULE))
+   return -EPERM;
+
/*
 * We don't allow synchronous module loading from async.  Module
 * init may invoke async_synchronize_full() which will end up
-- 
2.13.0.rc2.291.g57267f2277-goog



[PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

2017-05-12 Thread Mahesh Bandewar
From: Mahesh Bandewar 

A process inside random user-ns should not load a module, which is
currently possible. As demonstrated in following scenario -

  Create namespaces; especially a user-ns and become root inside.
  $ unshare -rfUp -- unshare -unm -- bash

  Try to load the bridge module. It should fail and this is expected!
  #  modprobe bridge
  WARNING: Error inserting stp 
(/lib/modules/4.11.0-smp-DEV/kernel/net/802/stp.ko): Operation not permitted
  FATAL: Error inserting bridge 
(/lib/modules/4.11.0-smp-DEV/kernel/net/bridge/bridge.ko): Operation not 
permitted

  Verify bridge module is not loaded.
  # lsmod | grep bridge
  #

  Now try to create a bridge inside this newly created net-ns which would
  mean bridge module need to be loaded.
  # ip link add br0 type bridge
  # echo $?
  0
  # lsmod | grep bridge
  bridge110592  0
  stp16384  1 bridge
  llc16384  2 bridge,stp
  #

  After this patch -
  # ip link add br0 type bridge
  RTNETLINK answers: Operation not supported
  # echo $?
  2
  # lsmod | grep bridge
  #

Signed-off-by: Mahesh Bandewar 
---
 kernel/kmod.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 563f97e2be36..ac30157169b7 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -133,6 +133,9 @@ int __request_module(bool wait, const char *fmt, ...)
 #define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
static int kmod_loop_msg;
 
+   if (!capable(CAP_SYS_MODULE))
+   return -EPERM;
+
/*
 * We don't allow synchronous module loading from async.  Module
 * init may invoke async_synchronize_full() which will end up
-- 
2.13.0.rc2.291.g57267f2277-goog



Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Andy Lutomirski
On Fri, May 12, 2017 at 12:15 AM, Al Viro  wrote:

> Folks, seriously, have you even looked through that zoo?  I have, and it's
> really, really not fun.  Sure, we can say "fuck 'em, no need to allow
> splice() on random crap".  Would be perfectly reasonable, expect that
> it's not the only place doing kernel_write() and its ilk...

Can you clarify this?  I think we really may be able to do exactly
this.  From Christoph's list, there are only two things that need
kernel_read/kernel_write to user-supplied fds that may come from a
variety of sources: splice and exec.  If you're execing a chardev from
a crappy driver, something is seriously wrong.  And returning -EINVAL
from splice() to or from files that use ->read and ->write seems find
(and splice(2) even documents -EINVAL as meaning that the target
doesn't support splicing).

--Andy


Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Andy Lutomirski
On Fri, May 12, 2017 at 12:15 AM, Al Viro  wrote:

> Folks, seriously, have you even looked through that zoo?  I have, and it's
> really, really not fun.  Sure, we can say "fuck 'em, no need to allow
> splice() on random crap".  Would be perfectly reasonable, expect that
> it's not the only place doing kernel_write() and its ilk...

Can you clarify this?  I think we really may be able to do exactly
this.  From Christoph's list, there are only two things that need
kernel_read/kernel_write to user-supplied fds that may come from a
variety of sources: splice and exec.  If you're execing a chardev from
a crappy driver, something is seriously wrong.  And returning -EINVAL
from splice() to or from files that use ->read and ->write seems find
(and splice(2) even documents -EINVAL as meaning that the target
doesn't support splicing).

--Andy


Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Andy Lutomirski
On Mon, May 8, 2017 at 1:48 PM, Al Viro  wrote:
> On Mon, May 08, 2017 at 04:06:35PM +0200, Jann Horn wrote:
>
>> I think Kees might be talking about
>> https://bugs.chromium.org/p/project-zero/issues/detail?id=822, fixed in
>> commit e6978e4bf181fb3b5f8cb6f71b4fe30fbf1b655c. The issue was that
>> perf code that can run in pretty much any context called access_ok().
>
> And that commit has *NOT* solved the problem.  perf_callchain_user()
> can be called synchronously, without passing through that code.
> Tracepoint shite...
>
> That set_fs() should be done in get_perf_callchain(), just around the call of
> perf_callchain_user().  Along with pagefault_disable(), actually.
>

Even that's not quite enough because of a different issue: perf nmis
can hit during scheduling or when we're in lazy mm, leading to the
entirely wrong set of page tables being used.  We need
nmi_uaccess_begin() and nmi_uaccess_end(), and the former needs to be
allowed to fail.

AFAIK this isn't presently a security problem because it mainly
affects kernel threads, and you need to be root to profile them, but
maybe there's some race where it does matter.


Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Andy Lutomirski
On Mon, May 8, 2017 at 1:48 PM, Al Viro  wrote:
> On Mon, May 08, 2017 at 04:06:35PM +0200, Jann Horn wrote:
>
>> I think Kees might be talking about
>> https://bugs.chromium.org/p/project-zero/issues/detail?id=822, fixed in
>> commit e6978e4bf181fb3b5f8cb6f71b4fe30fbf1b655c. The issue was that
>> perf code that can run in pretty much any context called access_ok().
>
> And that commit has *NOT* solved the problem.  perf_callchain_user()
> can be called synchronously, without passing through that code.
> Tracepoint shite...
>
> That set_fs() should be done in get_perf_callchain(), just around the call of
> perf_callchain_user().  Along with pagefault_disable(), actually.
>

Even that's not quite enough because of a different issue: perf nmis
can hit during scheduling or when we're in lazy mm, leading to the
entirely wrong set of page tables being used.  We need
nmi_uaccess_begin() and nmi_uaccess_end(), and the former needs to be
allowed to fail.

AFAIK this isn't presently a security problem because it mainly
affects kernel threads, and you need to be root to profile them, but
maybe there's some race where it does matter.


Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Al Viro
On Fri, May 12, 2017 at 05:47:55PM -0400, Rik van Riel wrote:

> > Seriously, look at these beasts.  Overwriting ->addr_limit is nowhere
> > near
> > the top threat.  If attacker can overwrite thread_info, you have
> > lost.
> 
> That is why THREAD_INFO_IN_TASK exists. It moves
> the struct thread_info to a location away from the
> stack, which means a stack overflow will not overwrite
> the thread_info.

... in which case such attacks on ->addr_limit also become a non-issue.

AFAICS, we are mixing several unrelated issues here:
* amount of places where set_fs() is called.  Sure, reducing it
is a good idea and we want to move to primitives like kernel_write() et.al.
Fewer users => lower odds of screwing it up.
* making sure that remaining callers are properly paired.  Ditto.
* switching to ->read_iter()/->write_iter() where it makes sense.
Again, no problem with that.
* providing sane environment for places like perf/oprofile.  Again,
a good idea, and set_fs(USER_DS) is only a part of what's needed there.
* switching _everything_ to ->read_iter()/->write_iter().  Flat-out
insane and AFAICS nobody is signing up for that.
* getting rid of set_fs() entirely.  I'm afraid that it's not feasible
without the previous one and frankly, I don't see much point.
* sanity-checking on return to userland.  Maybe useful, maybe not.
* taking thread_info out of the way of stack overflows.  Reasonable,
but has very little to do with the rest of that.
* protecting against Lovecraftian horrors slithering in from the outer
space only to commit unspeakable acts against ->addr_limit and ignoring much
tastier targets next to it, but then what do you expect from degenerate
spawn of Great Old Ones - sanity?


Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

2017-05-12 Thread Al Viro
On Fri, May 12, 2017 at 05:47:55PM -0400, Rik van Riel wrote:

> > Seriously, look at these beasts.  Overwriting ->addr_limit is nowhere
> > near
> > the top threat.  If attacker can overwrite thread_info, you have
> > lost.
> 
> That is why THREAD_INFO_IN_TASK exists. It moves
> the struct thread_info to a location away from the
> stack, which means a stack overflow will not overwrite
> the thread_info.

... in which case such attacks on ->addr_limit also become a non-issue.

AFAICS, we are mixing several unrelated issues here:
* amount of places where set_fs() is called.  Sure, reducing it
is a good idea and we want to move to primitives like kernel_write() et.al.
Fewer users => lower odds of screwing it up.
* making sure that remaining callers are properly paired.  Ditto.
* switching to ->read_iter()/->write_iter() where it makes sense.
Again, no problem with that.
* providing sane environment for places like perf/oprofile.  Again,
a good idea, and set_fs(USER_DS) is only a part of what's needed there.
* switching _everything_ to ->read_iter()/->write_iter().  Flat-out
insane and AFAICS nobody is signing up for that.
* getting rid of set_fs() entirely.  I'm afraid that it's not feasible
without the previous one and frankly, I don't see much point.
* sanity-checking on return to userland.  Maybe useful, maybe not.
* taking thread_info out of the way of stack overflows.  Reasonable,
but has very little to do with the rest of that.
* protecting against Lovecraftian horrors slithering in from the outer
space only to commit unspeakable acts against ->addr_limit and ignoring much
tastier targets next to it, but then what do you expect from degenerate
spawn of Great Old Ones - sanity?


Re: [PATCH v3 1/2] selinux: add brief info to policydb

2017-05-12 Thread William Roberts
On Fri, May 12, 2017 at 3:22 PM, Paul Moore  wrote:
>
> On Thu, May 11, 2017 at 4:45 PM, Casey Schaufler  
> wrote:
> > On 5/11/2017 1:22 PM, Stephen Smalley wrote:
> >> On Thu, 2017-05-11 at 08:56 -0700, Casey Schaufler wrote:
> >>> On 5/11/2017 5:59 AM, Sebastien Buisson wrote:
>  Add policybrief field to struct policydb. It holds a brief info
>  of the policydb, in the following form:
>  <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
>  Policy brief is computed every time the policy is loaded, and when
>  enforce or checkreqprot are changed.
> 
>  Add security_policy_brief hook to give access to policy brief to
>  the rest of the kernel. Lustre client makes use of this information
>  to detect changes to the policy, and forward it to Lustre servers.
>  Depending on how the policy is enforced on Lustre client side,
>  Lustre servers can refuse connection.
> 
>  Signed-off-by: Sebastien Buisson 
>  ---
>   include/linux/lsm_hooks.h   | 16 
>   include/linux/security.h|  7 
>   security/security.c |  6 +++
>   security/selinux/hooks.c|  7 
>   security/selinux/include/security.h |  2 +
>   security/selinux/selinuxfs.c|  2 +
>   security/selinux/ss/policydb.c  | 76
>  +
>   security/selinux/ss/policydb.h  |  2 +
>   security/selinux/ss/services.c  | 62
>  ++
>   9 files changed, 180 insertions(+)
> 
>  diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>  index 080f34e..9cac282 100644
>  --- a/include/linux/lsm_hooks.h
>  +++ b/include/linux/lsm_hooks.h
>  @@ -1336,6 +1336,20 @@
>    * @inode we wish to get the security context of.
>    * @ctx is a pointer in which to place the allocated
>  security context.
>    * @ctxlen points to the place to put the length of @ctx.
>  + *
>  + * Security hooks for policy brief
>  + *
>  + * @policy_brief:
>  + *
>  + * Returns a string containing a brief info of the
>  policydb, in the
>  + * following form:
>  + * <0 or 1 for enforce>:<0 or 1 for
>  checkreqprot>:=
> >>>
> >>> This sure looks like SELinux specific information. If the Spiffy
> >>> security module has multiple values for enforcement (e.g. off,
> >>> soft and hard) this interface definition does not work. What is a
> >>> "checkreqprot", and what is it for?
> >>>
> >>> I expect that you have no interest (or incentive) in supporting
> >>> security modules other than SELinux, and that's OK. What's I'm
> >>> after is an interface that another security module could use if
> >>> someone where interested (or inspired) to do so.
> >>>
> >>> Rather than a string with predefined positional values (something
> >>> I was taught not to do when 1 MIPS and 1 MEG was a big computer)
> >>> you might use
> >>> "enforce=:checkreqprot=:hashalg="
> >>
> >> No objection to the above, although it makes his updating code for
> >> enforce/checkreqprot a bit uglier.
> >
> > Sure, but can you imagine trying to use find(1) if the
> > options where positional?
>
> Perhaps I'm suffering from audit induced PTSD, but I think we need to
> operate under the assumption that we are going to need to augment this
> at some point in the future (no good feature goes un-abused) and I'd
> much rather have some sort of name-value pairing to keep my sanity.  I
> also feel rather strongly that we should make it very explicit in the
> comments that the ordering of the fields in the string may change.
>
> >>> for SELinux and define @policy_brief as
> >>>
> >>>  A string containing colon separated name and value pairs
> >>>  that will be parsed and interpreted by the security module
> >>>  or modules.
> >>
> >> Actually, I'm not clear it will be parsed or interpreted by the
> >> security module(s).  I think he is just fetching it and then doing a
> >> simple comparison to check for inconsistencies between clients and the
> >> server, and optionally admins/users can read it and interpret it as
> >> they see fit.
> >
> > OK, in which case human eyes *need* the name as well as the value.
> > That, and strcmp(value, "enforce=0") is no harder than strcmp(value, "0").
>
> The initial use case may not require parsing the string, but who knows
> what will end up using this five years from now.  Once again, I agree
> with Casey, let's make sure it easily parsed and readable by admins;
> imagine this as the output of a file under /proc or /sys.
>
> >>> You already have it right for the "hashalg" field. If you want to
> >>> be really forward looking you could use names field names that
> >>> identify the security module that uses them, such as
> >>>
> >>>  "selinux/enforce=1:selinux/checkreqprot=0:selinux/MD5=8675309"
> >> That seems a bit 

Re: [PATCH v3 1/2] selinux: add brief info to policydb

2017-05-12 Thread William Roberts
On Fri, May 12, 2017 at 3:22 PM, Paul Moore  wrote:
>
> On Thu, May 11, 2017 at 4:45 PM, Casey Schaufler  
> wrote:
> > On 5/11/2017 1:22 PM, Stephen Smalley wrote:
> >> On Thu, 2017-05-11 at 08:56 -0700, Casey Schaufler wrote:
> >>> On 5/11/2017 5:59 AM, Sebastien Buisson wrote:
>  Add policybrief field to struct policydb. It holds a brief info
>  of the policydb, in the following form:
>  <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
>  Policy brief is computed every time the policy is loaded, and when
>  enforce or checkreqprot are changed.
> 
>  Add security_policy_brief hook to give access to policy brief to
>  the rest of the kernel. Lustre client makes use of this information
>  to detect changes to the policy, and forward it to Lustre servers.
>  Depending on how the policy is enforced on Lustre client side,
>  Lustre servers can refuse connection.
> 
>  Signed-off-by: Sebastien Buisson 
>  ---
>   include/linux/lsm_hooks.h   | 16 
>   include/linux/security.h|  7 
>   security/security.c |  6 +++
>   security/selinux/hooks.c|  7 
>   security/selinux/include/security.h |  2 +
>   security/selinux/selinuxfs.c|  2 +
>   security/selinux/ss/policydb.c  | 76
>  +
>   security/selinux/ss/policydb.h  |  2 +
>   security/selinux/ss/services.c  | 62
>  ++
>   9 files changed, 180 insertions(+)
> 
>  diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>  index 080f34e..9cac282 100644
>  --- a/include/linux/lsm_hooks.h
>  +++ b/include/linux/lsm_hooks.h
>  @@ -1336,6 +1336,20 @@
>    * @inode we wish to get the security context of.
>    * @ctx is a pointer in which to place the allocated
>  security context.
>    * @ctxlen points to the place to put the length of @ctx.
>  + *
>  + * Security hooks for policy brief
>  + *
>  + * @policy_brief:
>  + *
>  + * Returns a string containing a brief info of the
>  policydb, in the
>  + * following form:
>  + * <0 or 1 for enforce>:<0 or 1 for
>  checkreqprot>:=
> >>>
> >>> This sure looks like SELinux specific information. If the Spiffy
> >>> security module has multiple values for enforcement (e.g. off,
> >>> soft and hard) this interface definition does not work. What is a
> >>> "checkreqprot", and what is it for?
> >>>
> >>> I expect that you have no interest (or incentive) in supporting
> >>> security modules other than SELinux, and that's OK. What's I'm
> >>> after is an interface that another security module could use if
> >>> someone where interested (or inspired) to do so.
> >>>
> >>> Rather than a string with predefined positional values (something
> >>> I was taught not to do when 1 MIPS and 1 MEG was a big computer)
> >>> you might use
> >>> "enforce=:checkreqprot=:hashalg="
> >>
> >> No objection to the above, although it makes his updating code for
> >> enforce/checkreqprot a bit uglier.
> >
> > Sure, but can you imagine trying to use find(1) if the
> > options where positional?
>
> Perhaps I'm suffering from audit induced PTSD, but I think we need to
> operate under the assumption that we are going to need to augment this
> at some point in the future (no good feature goes un-abused) and I'd
> much rather have some sort of name-value pairing to keep my sanity.  I
> also feel rather strongly that we should make it very explicit in the
> comments that the ordering of the fields in the string may change.
>
> >>> for SELinux and define @policy_brief as
> >>>
> >>>  A string containing colon separated name and value pairs
> >>>  that will be parsed and interpreted by the security module
> >>>  or modules.
> >>
> >> Actually, I'm not clear it will be parsed or interpreted by the
> >> security module(s).  I think he is just fetching it and then doing a
> >> simple comparison to check for inconsistencies between clients and the
> >> server, and optionally admins/users can read it and interpret it as
> >> they see fit.
> >
> > OK, in which case human eyes *need* the name as well as the value.
> > That, and strcmp(value, "enforce=0") is no harder than strcmp(value, "0").
>
> The initial use case may not require parsing the string, but who knows
> what will end up using this five years from now.  Once again, I agree
> with Casey, let's make sure it easily parsed and readable by admins;
> imagine this as the output of a file under /proc or /sys.
>
> >>> You already have it right for the "hashalg" field. If you want to
> >>> be really forward looking you could use names field names that
> >>> identify the security module that uses them, such as
> >>>
> >>>  "selinux/enforce=1:selinux/checkreqprot=0:selinux/MD5=8675309"
> >> That seems a bit verbose, particularly the duplicated selinux/ bit.
> >
> > True 

  1   2   3   4   5   6   7   8   9   10   >