Re: [PATCH] cx18: Fix a sleep-in-atomic bug in snd_cx18_pcm_hw_free

2017-05-31 Thread kbuild test robot
Hi Jia-Ju,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc3 next-20170531]
[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/Jia-Ju-Bai/cx18-Fix-a-sleep-in-atomic-bug-in-snd_cx18_pcm_hw_free/20170601-131553
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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=xtensa 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media//pci/cx18/cx18-alsa-pcm.c: In function 'snd_cx18_pcm_hw_free':
>> drivers/media//pci/cx18/cx18-alsa-pcm.c:269:2: warning: 'dma_area' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
 vfree(dma_area);
 ^

vim +/dma_area +269 drivers/media//pci/cx18/cx18-alsa-pcm.c

   253 params_buffer_bytes(params));
   254  }
   255  
   256  static int snd_cx18_pcm_hw_free(struct snd_pcm_substream *substream)
   257  {
   258  struct snd_cx18_card *cxsc = snd_pcm_substream_chip(substream);
   259  unsigned long flags;
   260  unsigned char *dma_area;
   261  
   262  spin_lock_irqsave(>slock, flags);
   263  if (substream->runtime->dma_area) {
   264  dprintk("freeing pcm capture region\n");
   265  dma_area = substream->runtime->dma_area;
   266  substream->runtime->dma_area = NULL;
   267  }
   268  spin_unlock_irqrestore(>slock, flags);
 > 269  vfree(dma_area);
   270  
   271  return 0;
   272  }
   273  
   274  static int snd_cx18_pcm_prepare(struct snd_pcm_substream *substream)
   275  {
   276  struct snd_cx18_card *cxsc = snd_pcm_substream_chip(substream);
   277  

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


.config.gz
Description: application/gzip


Re: [PATCH] cx18: Fix a sleep-in-atomic bug in snd_cx18_pcm_hw_free

2017-05-31 Thread kbuild test robot
Hi Jia-Ju,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc3 next-20170531]
[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/Jia-Ju-Bai/cx18-Fix-a-sleep-in-atomic-bug-in-snd_cx18_pcm_hw_free/20170601-131553
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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=xtensa 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media//pci/cx18/cx18-alsa-pcm.c: In function 'snd_cx18_pcm_hw_free':
>> drivers/media//pci/cx18/cx18-alsa-pcm.c:269:2: warning: 'dma_area' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
 vfree(dma_area);
 ^

vim +/dma_area +269 drivers/media//pci/cx18/cx18-alsa-pcm.c

   253 params_buffer_bytes(params));
   254  }
   255  
   256  static int snd_cx18_pcm_hw_free(struct snd_pcm_substream *substream)
   257  {
   258  struct snd_cx18_card *cxsc = snd_pcm_substream_chip(substream);
   259  unsigned long flags;
   260  unsigned char *dma_area;
   261  
   262  spin_lock_irqsave(>slock, flags);
   263  if (substream->runtime->dma_area) {
   264  dprintk("freeing pcm capture region\n");
   265  dma_area = substream->runtime->dma_area;
   266  substream->runtime->dma_area = NULL;
   267  }
   268  spin_unlock_irqrestore(>slock, flags);
 > 269  vfree(dma_area);
   270  
   271  return 0;
   272  }
   273  
   274  static int snd_cx18_pcm_prepare(struct snd_pcm_substream *substream)
   275  {
   276  struct snd_cx18_card *cxsc = snd_pcm_substream_chip(substream);
   277  

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


.config.gz
Description: application/gzip


Re: [PATCH] ivtv: Fix a sleep-in-atomic bug in snd_ivtv_pcm_hw_free

2017-05-31 Thread kbuild test robot
Hi Jia-Ju,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc3 next-20170531]
[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/Jia-Ju-Bai/ivtv-Fix-a-sleep-in-atomic-bug-in-snd_ivtv_pcm_hw_free/20170601-131112
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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=xtensa 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media//pci/ivtv/ivtv-alsa-pcm.c: In function 'snd_ivtv_pcm_hw_free':
>> drivers/media//pci/ivtv/ivtv-alsa-pcm.c:274:2: warning: 'dma_area' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
 vfree(dma_area);
 ^

vim +/dma_area +274 drivers/media//pci/ivtv/ivtv-alsa-pcm.c

   258 params_buffer_bytes(params));
   259  }
   260  
   261  static int snd_ivtv_pcm_hw_free(struct snd_pcm_substream *substream)
   262  {
   263  struct snd_ivtv_card *itvsc = snd_pcm_substream_chip(substream);
   264  unsigned long flags;
   265  unsigned char *dma_area;
   266  
   267  spin_lock_irqsave(>slock, flags);
   268  if (substream->runtime->dma_area) {
   269  dprintk("freeing pcm capture region\n");
   270  dma_area = substream->runtime->dma_area;
   271  substream->runtime->dma_area = NULL;
   272  }
   273  spin_unlock_irqrestore(>slock, flags);
 > 274  vfree(dma_area);
   275  
   276  return 0;
   277  }
   278  
   279  static int snd_ivtv_pcm_prepare(struct snd_pcm_substream *substream)
   280  {
   281  struct snd_ivtv_card *itvsc = snd_pcm_substream_chip(substream);
   282  

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


.config.gz
Description: application/gzip


Re: [PATCH] ivtv: Fix a sleep-in-atomic bug in snd_ivtv_pcm_hw_free

2017-05-31 Thread kbuild test robot
Hi Jia-Ju,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc3 next-20170531]
[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/Jia-Ju-Bai/ivtv-Fix-a-sleep-in-atomic-bug-in-snd_ivtv_pcm_hw_free/20170601-131112
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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=xtensa 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media//pci/ivtv/ivtv-alsa-pcm.c: In function 'snd_ivtv_pcm_hw_free':
>> drivers/media//pci/ivtv/ivtv-alsa-pcm.c:274:2: warning: 'dma_area' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
 vfree(dma_area);
 ^

vim +/dma_area +274 drivers/media//pci/ivtv/ivtv-alsa-pcm.c

   258 params_buffer_bytes(params));
   259  }
   260  
   261  static int snd_ivtv_pcm_hw_free(struct snd_pcm_substream *substream)
   262  {
   263  struct snd_ivtv_card *itvsc = snd_pcm_substream_chip(substream);
   264  unsigned long flags;
   265  unsigned char *dma_area;
   266  
   267  spin_lock_irqsave(>slock, flags);
   268  if (substream->runtime->dma_area) {
   269  dprintk("freeing pcm capture region\n");
   270  dma_area = substream->runtime->dma_area;
   271  substream->runtime->dma_area = NULL;
   272  }
   273  spin_unlock_irqrestore(>slock, flags);
 > 274  vfree(dma_area);
   275  
   276  return 0;
   277  }
   278  
   279  static int snd_ivtv_pcm_prepare(struct snd_pcm_substream *substream)
   280  {
   281  struct snd_ivtv_card *itvsc = snd_pcm_substream_chip(substream);
   282  

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


.config.gz
Description: application/gzip


[RFC PATCH 02/10] objtool, x86: add several functions and files to the objtool whitelist

2017-05-31 Thread Josh Poimboeuf
In preparation for an objtool rewrite which will have broader checks,
whitelist functions and files which cause problems because they do
unusual things with the stack.

These whitelists serve as a TODO list for which functions and files
don't yet have undwarf unwinder coverage.  Eventually most of the
whitelists can be removed in favor of manual CFI hint annotations or
objtool improvements.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/crypto/Makefile   | 2 ++
 arch/x86/crypto/sha1-mb/Makefile   | 2 ++
 arch/x86/crypto/sha256-mb/Makefile | 2 ++
 arch/x86/kernel/Makefile   | 1 +
 arch/x86/kernel/acpi/Makefile  | 2 ++
 arch/x86/kernel/kprobes/opt.c  | 9 -
 arch/x86/kernel/reboot.c   | 2 ++
 arch/x86/kvm/svm.c | 2 ++
 arch/x86/kvm/vmx.c | 3 +++
 arch/x86/lib/msr-reg.S | 8 
 arch/x86/net/Makefile  | 2 ++
 arch/x86/platform/efi/Makefile | 1 +
 arch/x86/power/Makefile| 2 ++
 arch/x86/xen/Makefile  | 3 +++
 kernel/kexec_core.c| 4 +++-
 15 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 34b3fa2..9e32d40 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
$(comma)4)$(comma)%ymm2,yes,no)
diff --git a/arch/x86/crypto/sha1-mb/Makefile b/arch/x86/crypto/sha1-mb/Makefile
index 2f87563..2e14acc 100644
--- a/arch/x86/crypto/sha1-mb/Makefile
+++ b/arch/x86/crypto/sha1-mb/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
 $(comma)4)$(comma)%ymm2,yes,no)
 ifeq ($(avx2_supported),yes)
diff --git a/arch/x86/crypto/sha256-mb/Makefile 
b/arch/x86/crypto/sha256-mb/Makefile
index 41089e7..45b4fca 100644
--- a/arch/x86/crypto/sha256-mb/Makefile
+++ b/arch/x86/crypto/sha256-mb/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
 $(comma)4)$(comma)%ymm2,yes,no)
 ifeq ($(avx2_supported),yes)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4b99423..3c7c419 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,6 +29,7 @@ OBJECT_FILES_NON_STANDARD_head_$(BITS).o  := y
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
 OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
+OBJECT_FILES_NON_STANDARD_paravirt_patch_$(BITS).o := y
 
 # If instrumentation of this dir is enabled, boot hangs during first second.
 # Probably could be more selective here, but note that files related to irqs,
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 26b78d8..85a9e17 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,3 +1,5 @@
+OBJECT_FILES_NON_STANDARD_wakeup_$(BITS).o := y
+
 obj-$(CONFIG_ACPI) += boot.o
 obj-$(CONFIG_ACPI_SLEEP)   += sleep.o wakeup_$(BITS).o
 obj-$(CONFIG_ACPI_APEI)+= apei.o
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 901c640..69ea0bc 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -94,6 +95,7 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, 
unsigned long val)
 }
 
 asm (
+   "optprobe_template_func:\n"
".global optprobe_template_entry\n"
"optprobe_template_entry:\n"
 #ifdef CONFIG_X86_64
@@ -131,7 +133,12 @@ asm (
"   popf\n"
 #endif
".global optprobe_template_end\n"
-   "optprobe_template_end:\n");
+   "optprobe_template_end:\n"
+   ".type optprobe_template_func, @function\n"
+   ".size optprobe_template_func, 
.-optprobe_template_func\n");
+
+void optprobe_template_func(void);
+STACK_FRAME_NON_STANDARD(optprobe_template_func);
 
 #define TMPL_MOVE_IDX \
((long)_template_val - (long)_template_entry)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 2544700..67393fc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -123,6 +124,7 @@ void __noreturn 

[RFC PATCH 02/10] objtool, x86: add several functions and files to the objtool whitelist

2017-05-31 Thread Josh Poimboeuf
In preparation for an objtool rewrite which will have broader checks,
whitelist functions and files which cause problems because they do
unusual things with the stack.

These whitelists serve as a TODO list for which functions and files
don't yet have undwarf unwinder coverage.  Eventually most of the
whitelists can be removed in favor of manual CFI hint annotations or
objtool improvements.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/crypto/Makefile   | 2 ++
 arch/x86/crypto/sha1-mb/Makefile   | 2 ++
 arch/x86/crypto/sha256-mb/Makefile | 2 ++
 arch/x86/kernel/Makefile   | 1 +
 arch/x86/kernel/acpi/Makefile  | 2 ++
 arch/x86/kernel/kprobes/opt.c  | 9 -
 arch/x86/kernel/reboot.c   | 2 ++
 arch/x86/kvm/svm.c | 2 ++
 arch/x86/kvm/vmx.c | 3 +++
 arch/x86/lib/msr-reg.S | 8 
 arch/x86/net/Makefile  | 2 ++
 arch/x86/platform/efi/Makefile | 1 +
 arch/x86/power/Makefile| 2 ++
 arch/x86/xen/Makefile  | 3 +++
 kernel/kexec_core.c| 4 +++-
 15 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 34b3fa2..9e32d40 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
$(comma)4)$(comma)%ymm2,yes,no)
diff --git a/arch/x86/crypto/sha1-mb/Makefile b/arch/x86/crypto/sha1-mb/Makefile
index 2f87563..2e14acc 100644
--- a/arch/x86/crypto/sha1-mb/Makefile
+++ b/arch/x86/crypto/sha1-mb/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
 $(comma)4)$(comma)%ymm2,yes,no)
 ifeq ($(avx2_supported),yes)
diff --git a/arch/x86/crypto/sha256-mb/Makefile 
b/arch/x86/crypto/sha256-mb/Makefile
index 41089e7..45b4fca 100644
--- a/arch/x86/crypto/sha256-mb/Makefile
+++ b/arch/x86/crypto/sha256-mb/Makefile
@@ -2,6 +2,8 @@
 # Arch-specific CryptoAPI modules.
 #
 
+OBJECT_FILES_NON_STANDARD := y
+
 avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
 $(comma)4)$(comma)%ymm2,yes,no)
 ifeq ($(avx2_supported),yes)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4b99423..3c7c419 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,6 +29,7 @@ OBJECT_FILES_NON_STANDARD_head_$(BITS).o  := y
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
 OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
+OBJECT_FILES_NON_STANDARD_paravirt_patch_$(BITS).o := y
 
 # If instrumentation of this dir is enabled, boot hangs during first second.
 # Probably could be more selective here, but note that files related to irqs,
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 26b78d8..85a9e17 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,3 +1,5 @@
+OBJECT_FILES_NON_STANDARD_wakeup_$(BITS).o := y
+
 obj-$(CONFIG_ACPI) += boot.o
 obj-$(CONFIG_ACPI_SLEEP)   += sleep.o wakeup_$(BITS).o
 obj-$(CONFIG_ACPI_APEI)+= apei.o
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 901c640..69ea0bc 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -94,6 +95,7 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, 
unsigned long val)
 }
 
 asm (
+   "optprobe_template_func:\n"
".global optprobe_template_entry\n"
"optprobe_template_entry:\n"
 #ifdef CONFIG_X86_64
@@ -131,7 +133,12 @@ asm (
"   popf\n"
 #endif
".global optprobe_template_end\n"
-   "optprobe_template_end:\n");
+   "optprobe_template_end:\n"
+   ".type optprobe_template_func, @function\n"
+   ".size optprobe_template_func, 
.-optprobe_template_func\n");
+
+void optprobe_template_func(void);
+STACK_FRAME_NON_STANDARD(optprobe_template_func);
 
 #define TMPL_MOVE_IDX \
((long)_template_val - (long)_template_entry)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 2544700..67393fc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -123,6 +124,7 @@ void __noreturn machine_real_restart(unsigned 

[RFC PATCH 04/10] objtool: add undwarf debuginfo generation

2017-05-31 Thread Josh Poimboeuf
Now that objtool knows the states of all registers on the stack for each
instruction, it's straightforward to generate debuginfo for an unwinder
to use.

Instead of generating DWARF, generate a new format called undwarf, which
is more suitable for an in-kernel unwinder.  See
tools/objtool/Documentation/undwarf.txt for a more detailed description
of this new debuginfo format and why it's preferable to DWARF.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Build  |   2 +
 tools/objtool/Documentation/stack-validation.txt |  45 +---
 tools/objtool/Documentation/undwarf.txt  |  99 
 tools/objtool/builtin-check.c|   2 +-
 tools/objtool/builtin-undwarf.c  |  70 ++
 tools/objtool/builtin.h  |   1 +
 tools/objtool/check.c|  57 -
 tools/objtool/check.h|   7 +-
 tools/objtool/elf.c  | 224 +
 tools/objtool/elf.h  |   5 +
 tools/objtool/objtool.c  |   3 +-
 tools/objtool/undwarf-types.h| 100 
 tools/objtool/undwarf.c  | 308 +++
 tools/objtool/{builtin.h => undwarf.h}   |  19 +-
 14 files changed, 898 insertions(+), 44 deletions(-)
 create mode 100644 tools/objtool/Documentation/undwarf.txt
 create mode 100644 tools/objtool/builtin-undwarf.c
 create mode 100644 tools/objtool/undwarf-types.h
 create mode 100644 tools/objtool/undwarf.c
 copy tools/objtool/{builtin.h => undwarf.h} (64%)

diff --git a/tools/objtool/Build b/tools/objtool/Build
index 6f2e198..845c879 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,6 +1,8 @@
 objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
+objtool-y += builtin-undwarf.o
 objtool-y += check.o
+objtool-y += undwarf.o
 objtool-y += elf.o
 objtool-y += special.o
 objtool-y += objtool.o
diff --git a/tools/objtool/Documentation/stack-validation.txt 
b/tools/objtool/Documentation/stack-validation.txt
index 17c1195..e961971 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -11,9 +11,6 @@ analyzes every .o file and ensures the validity of its stack 
metadata.
 It enforces a set of rules on asm code and C inline assembly code so
 that stack traces can be reliable.
 
-Currently it only checks frame pointer usage, but there are plans to add
-CFI validation for C files and CFI generation for asm files.
-
 For each function, it recursively follows all possible code paths and
 validates the correct frame pointer state at each instruction.
 
@@ -23,6 +20,9 @@ alternative execution paths to a given instruction (or set of
 instructions).  Similarly, it knows how to follow switch statements, for
 which gcc sometimes uses jump tables.
 
+(Objtool also has an 'undwarf generate' subcommand which generates
+debuginfo for the undwarf unwinder.  See undwarf.txt for more details.)
+
 
 Why do we need stack metadata validation?
 -
@@ -93,37 +93,14 @@ a) More reliable stack traces for frame pointer enabled 
kernels
or at the very end of the function after the stack frame has been
destroyed.  This is an inherent limitation of frame pointers.
 
-b) 100% reliable stack traces for DWARF enabled kernels
-
-   (NOTE: This is not yet implemented)
-
-   As an alternative to frame pointers, DWARF Call Frame Information
-   (CFI) metadata can be used to walk the stack.  Unlike frame pointers,
-   CFI metadata is out of band.  So it doesn't affect runtime
-   performance and it can be reliable even when interrupts or exceptions
-   are involved.
-
-   For C code, gcc automatically generates DWARF CFI metadata.  But for
-   asm code, generating CFI is a tedious manual approach which requires
-   manually placed .cfi assembler macros to be scattered throughout the
-   code.  It's clumsy and very easy to get wrong, and it makes the real
-   code harder to read.
-
-   Stacktool will improve this situation in several ways.  For code
-   which already has CFI annotations, it will validate them.  For code
-   which doesn't have CFI annotations, it will generate them.  So an
-   architecture can opt to strip out all the manual .cfi annotations
-   from their asm code and have objtool generate them instead.
-
-   We might also add a runtime stack validation debug option where we
-   periodically walk the stack from schedule() and/or an NMI to ensure
-   that the stack metadata is sane and that we reach the bottom of the
-   stack.
-
-   So the benefit of objtool here will be that external tooling should
-   always show perfect stack traces.  And the same will be true for
-   kernel warning/oops traces if the architecture has a runtime DWARF
-   unwinder.
+b) Out-of-band debuginfo generation (undwarf)
+
+   As an alternative 

[RFC PATCH 03/10] objtool: stack validation 2.0

2017-05-31 Thread Josh Poimboeuf
This is a major rewrite of objtool.  Instead of only tracking frame
pointer changes, it now tracks all stack-related operations, including
all register saves/restores.

In addition to making stack validation more robust, this also paves the
way for undwarf generation.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Documentation/stack-validation.txt | 153 +++---
 tools/objtool/Makefile   |   2 +-
 tools/objtool/arch.h |  64 ++-
 tools/objtool/arch/x86/decode.c  | 400 +--
 tools/objtool/cfi.h  |  55 +++
 tools/objtool/check.c| 595 ++-
 tools/objtool/check.h|  18 +-
 tools/objtool/elf.c  |  23 +-
 tools/objtool/elf.h  |   3 +-
 tools/objtool/special.c  |   6 +-
 10 files changed, 1023 insertions(+), 296 deletions(-)
 create mode 100644 tools/objtool/cfi.h

diff --git a/tools/objtool/Documentation/stack-validation.txt 
b/tools/objtool/Documentation/stack-validation.txt
index 55a60d3..17c1195 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -127,28 +127,13 @@ b) 100% reliable stack traces for DWARF enabled kernels
 
 c) Higher live patching compatibility rate
 
-   (NOTE: This is not yet implemented)
-
-   Currently with CONFIG_LIVEPATCH there's a basic live patching
-   framework which is safe for roughly 85-90% of "security" fixes.  But
-   patches can't have complex features like function dependency or
-   prototype changes, or data structure changes.
-
-   There's a strong need to support patches which have the more complex
-   features so that the patch compatibility rate for security fixes can
-   eventually approach something resembling 100%.  To achieve that, a
-   "consistency model" is needed, which allows tasks to be safely
-   transitioned from an unpatched state to a patched state.
-
-   One of the key requirements of the currently proposed livepatch
-   consistency model [*] is that it needs to walk the stack of each
-   sleeping task to determine if it can be transitioned to the patched
-   state.  If objtool can ensure that stack traces are reliable, this
-   consistency model can be used and the live patching compatibility
-   rate can be improved significantly.
-
-   [*] https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com
+   Livepatch has an optional "consistency model", which is needed for
+   more complex patches.  In order for the consistency model to work,
+   stack traces need to be reliable (or an unreliable condition needs to
+   be detectable).  Objtool makes that possible.
 
+   For more details, see the livepatch documentation in the Linux kernel
+   source tree at Documentation/livepatch/livepatch.txt.
 
 Rules
 -
@@ -201,80 +186,84 @@ To achieve the validation, objtool enforces the following 
rules:
return normally.
 
 
-Errors in .S files
---
+Objtool warnings
+
 
-If you're getting an error in a compiled .S file which you don't
-understand, first make sure that the affected code follows the above
-rules.
+For asm files, if you're getting an error which doesn't make sense,
+first make sure that the affected code follows the above rules.
+
+For C files, the common culprits are inline asm statements and calls to
+"noreturn" functions.  See below for more details.
+
+Another possible cause for errors in C code is if the Makefile removes
+-fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options.
 
 Here are some examples of common warnings reported by objtool, what
 they mean, and suggestions for how to fix them.
 
 
-1. asm_file.o: warning: objtool: func()+0x128: call without frame pointer 
save/setup
+1. file.o: warning: objtool: func()+0x128: call without frame pointer 
save/setup
 
The func() function made a function call without first saving and/or
-   updating the frame pointer.
-
-   If func() is indeed a callable function, add proper frame pointer
-   logic using the FRAME_BEGIN and FRAME_END macros.  Otherwise, remove
-   its ELF function annotation by changing ENDPROC to END.
+   updating the frame pointer, and CONFIG_FRAME_POINTER is enabled.
 
-   If you're getting this error in a .c file, see the "Errors in .c
-   files" section.
+   If the error is for an asm file, and func() is indeed a callable
+   function, add proper frame pointer logic using the FRAME_BEGIN and
+   FRAME_END macros.  Otherwise, if it's not a callable function, remove
+   its ELF function annotation by changing ENDPROC to END, and instead
+   use the manual CFI hint macros in asm/undwarf.h.
 
+   If it's a GCC-compiled .c file, the error may be because the function
+   uses an inline asm() statement which has a "call" instruction.  An
+   asm() statement with a call 

[RFC PATCH 04/10] objtool: add undwarf debuginfo generation

2017-05-31 Thread Josh Poimboeuf
Now that objtool knows the states of all registers on the stack for each
instruction, it's straightforward to generate debuginfo for an unwinder
to use.

Instead of generating DWARF, generate a new format called undwarf, which
is more suitable for an in-kernel unwinder.  See
tools/objtool/Documentation/undwarf.txt for a more detailed description
of this new debuginfo format and why it's preferable to DWARF.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Build  |   2 +
 tools/objtool/Documentation/stack-validation.txt |  45 +---
 tools/objtool/Documentation/undwarf.txt  |  99 
 tools/objtool/builtin-check.c|   2 +-
 tools/objtool/builtin-undwarf.c  |  70 ++
 tools/objtool/builtin.h  |   1 +
 tools/objtool/check.c|  57 -
 tools/objtool/check.h|   7 +-
 tools/objtool/elf.c  | 224 +
 tools/objtool/elf.h  |   5 +
 tools/objtool/objtool.c  |   3 +-
 tools/objtool/undwarf-types.h| 100 
 tools/objtool/undwarf.c  | 308 +++
 tools/objtool/{builtin.h => undwarf.h}   |  19 +-
 14 files changed, 898 insertions(+), 44 deletions(-)
 create mode 100644 tools/objtool/Documentation/undwarf.txt
 create mode 100644 tools/objtool/builtin-undwarf.c
 create mode 100644 tools/objtool/undwarf-types.h
 create mode 100644 tools/objtool/undwarf.c
 copy tools/objtool/{builtin.h => undwarf.h} (64%)

diff --git a/tools/objtool/Build b/tools/objtool/Build
index 6f2e198..845c879 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,6 +1,8 @@
 objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
+objtool-y += builtin-undwarf.o
 objtool-y += check.o
+objtool-y += undwarf.o
 objtool-y += elf.o
 objtool-y += special.o
 objtool-y += objtool.o
diff --git a/tools/objtool/Documentation/stack-validation.txt 
b/tools/objtool/Documentation/stack-validation.txt
index 17c1195..e961971 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -11,9 +11,6 @@ analyzes every .o file and ensures the validity of its stack 
metadata.
 It enforces a set of rules on asm code and C inline assembly code so
 that stack traces can be reliable.
 
-Currently it only checks frame pointer usage, but there are plans to add
-CFI validation for C files and CFI generation for asm files.
-
 For each function, it recursively follows all possible code paths and
 validates the correct frame pointer state at each instruction.
 
@@ -23,6 +20,9 @@ alternative execution paths to a given instruction (or set of
 instructions).  Similarly, it knows how to follow switch statements, for
 which gcc sometimes uses jump tables.
 
+(Objtool also has an 'undwarf generate' subcommand which generates
+debuginfo for the undwarf unwinder.  See undwarf.txt for more details.)
+
 
 Why do we need stack metadata validation?
 -
@@ -93,37 +93,14 @@ a) More reliable stack traces for frame pointer enabled 
kernels
or at the very end of the function after the stack frame has been
destroyed.  This is an inherent limitation of frame pointers.
 
-b) 100% reliable stack traces for DWARF enabled kernels
-
-   (NOTE: This is not yet implemented)
-
-   As an alternative to frame pointers, DWARF Call Frame Information
-   (CFI) metadata can be used to walk the stack.  Unlike frame pointers,
-   CFI metadata is out of band.  So it doesn't affect runtime
-   performance and it can be reliable even when interrupts or exceptions
-   are involved.
-
-   For C code, gcc automatically generates DWARF CFI metadata.  But for
-   asm code, generating CFI is a tedious manual approach which requires
-   manually placed .cfi assembler macros to be scattered throughout the
-   code.  It's clumsy and very easy to get wrong, and it makes the real
-   code harder to read.
-
-   Stacktool will improve this situation in several ways.  For code
-   which already has CFI annotations, it will validate them.  For code
-   which doesn't have CFI annotations, it will generate them.  So an
-   architecture can opt to strip out all the manual .cfi annotations
-   from their asm code and have objtool generate them instead.
-
-   We might also add a runtime stack validation debug option where we
-   periodically walk the stack from schedule() and/or an NMI to ensure
-   that the stack metadata is sane and that we reach the bottom of the
-   stack.
-
-   So the benefit of objtool here will be that external tooling should
-   always show perfect stack traces.  And the same will be true for
-   kernel warning/oops traces if the architecture has a runtime DWARF
-   unwinder.
+b) Out-of-band debuginfo generation (undwarf)
+
+   As an alternative to frame pointers, 

[RFC PATCH 03/10] objtool: stack validation 2.0

2017-05-31 Thread Josh Poimboeuf
This is a major rewrite of objtool.  Instead of only tracking frame
pointer changes, it now tracks all stack-related operations, including
all register saves/restores.

In addition to making stack validation more robust, this also paves the
way for undwarf generation.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Documentation/stack-validation.txt | 153 +++---
 tools/objtool/Makefile   |   2 +-
 tools/objtool/arch.h |  64 ++-
 tools/objtool/arch/x86/decode.c  | 400 +--
 tools/objtool/cfi.h  |  55 +++
 tools/objtool/check.c| 595 ++-
 tools/objtool/check.h|  18 +-
 tools/objtool/elf.c  |  23 +-
 tools/objtool/elf.h  |   3 +-
 tools/objtool/special.c  |   6 +-
 10 files changed, 1023 insertions(+), 296 deletions(-)
 create mode 100644 tools/objtool/cfi.h

diff --git a/tools/objtool/Documentation/stack-validation.txt 
b/tools/objtool/Documentation/stack-validation.txt
index 55a60d3..17c1195 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -127,28 +127,13 @@ b) 100% reliable stack traces for DWARF enabled kernels
 
 c) Higher live patching compatibility rate
 
-   (NOTE: This is not yet implemented)
-
-   Currently with CONFIG_LIVEPATCH there's a basic live patching
-   framework which is safe for roughly 85-90% of "security" fixes.  But
-   patches can't have complex features like function dependency or
-   prototype changes, or data structure changes.
-
-   There's a strong need to support patches which have the more complex
-   features so that the patch compatibility rate for security fixes can
-   eventually approach something resembling 100%.  To achieve that, a
-   "consistency model" is needed, which allows tasks to be safely
-   transitioned from an unpatched state to a patched state.
-
-   One of the key requirements of the currently proposed livepatch
-   consistency model [*] is that it needs to walk the stack of each
-   sleeping task to determine if it can be transitioned to the patched
-   state.  If objtool can ensure that stack traces are reliable, this
-   consistency model can be used and the live patching compatibility
-   rate can be improved significantly.
-
-   [*] https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com
+   Livepatch has an optional "consistency model", which is needed for
+   more complex patches.  In order for the consistency model to work,
+   stack traces need to be reliable (or an unreliable condition needs to
+   be detectable).  Objtool makes that possible.
 
+   For more details, see the livepatch documentation in the Linux kernel
+   source tree at Documentation/livepatch/livepatch.txt.
 
 Rules
 -
@@ -201,80 +186,84 @@ To achieve the validation, objtool enforces the following 
rules:
return normally.
 
 
-Errors in .S files
---
+Objtool warnings
+
 
-If you're getting an error in a compiled .S file which you don't
-understand, first make sure that the affected code follows the above
-rules.
+For asm files, if you're getting an error which doesn't make sense,
+first make sure that the affected code follows the above rules.
+
+For C files, the common culprits are inline asm statements and calls to
+"noreturn" functions.  See below for more details.
+
+Another possible cause for errors in C code is if the Makefile removes
+-fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options.
 
 Here are some examples of common warnings reported by objtool, what
 they mean, and suggestions for how to fix them.
 
 
-1. asm_file.o: warning: objtool: func()+0x128: call without frame pointer 
save/setup
+1. file.o: warning: objtool: func()+0x128: call without frame pointer 
save/setup
 
The func() function made a function call without first saving and/or
-   updating the frame pointer.
-
-   If func() is indeed a callable function, add proper frame pointer
-   logic using the FRAME_BEGIN and FRAME_END macros.  Otherwise, remove
-   its ELF function annotation by changing ENDPROC to END.
+   updating the frame pointer, and CONFIG_FRAME_POINTER is enabled.
 
-   If you're getting this error in a .c file, see the "Errors in .c
-   files" section.
+   If the error is for an asm file, and func() is indeed a callable
+   function, add proper frame pointer logic using the FRAME_BEGIN and
+   FRAME_END macros.  Otherwise, if it's not a callable function, remove
+   its ELF function annotation by changing ENDPROC to END, and instead
+   use the manual CFI hint macros in asm/undwarf.h.
 
+   If it's a GCC-compiled .c file, the error may be because the function
+   uses an inline asm() statement which has a "call" instruction.  An
+   asm() statement with a call instruction must declare 

[RFC PATCH 05/10] objtool, x86: add facility for asm code to provide CFI hints

2017-05-31 Thread Josh Poimboeuf
Some asm (and inline asm) code does special things to the stack which
objtool can't understand.  (Nor can GCC or GNU assembler, for that
matter.)  In such cases we need a facility for the code to provide
annotations, so the unwinder can unwind through it.

This provides such a facility, in the form of CFI hints.  They're
similar to the GNU assembler .cfi* directives, but they give more
information, and are needed in far fewer places, because objtool can
fill in the blanks by following branches and adjusting the stack pointer
for pushes and pops.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/undwarf-types.h | 100 
 arch/x86/include/asm/undwarf.h   |  97 +++
 tools/objtool/Makefile   |   3 +
 tools/objtool/check.c| 176 ++-
 tools/objtool/check.h|   4 +-
 5 files changed, 373 insertions(+), 7 deletions(-)
 create mode 100644 arch/x86/include/asm/undwarf-types.h
 create mode 100644 arch/x86/include/asm/undwarf.h

diff --git a/arch/x86/include/asm/undwarf-types.h 
b/arch/x86/include/asm/undwarf-types.h
new file mode 100644
index 000..b624188
--- /dev/null
+++ b/arch/x86/include/asm/undwarf-types.h
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2017 Josh Poimboeuf 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#ifndef _UNDWARF_TYPES_H
+#define _UNDWARF_TYPES_H
+
+/*
+ * The UNDWARF_REG_* registers are base registers which are used to find other
+ * registers on the stack.
+ *
+ * The CFA (call frame address) is the value of the stack pointer on the
+ * previous frame, i.e. the caller's SP before it called the callee.
+ *
+ * The CFA is usually based on SP, unless a frame pointer has been saved, in
+ * which case it's based on BP.
+ *
+ * BP is usually either based on CFA or is undefined (meaning its value didn't
+ * change for the current frame).
+ *
+ * So the CFA base is usually either SP or BP, and the FP base is usually 
either
+ * CFA or undefined.  The rest of the base registers are needed for special
+ * cases like entry code and gcc aligned stacks.
+ */
+#define UNDWARF_REG_UNDEFINED  0
+#define UNDWARF_REG_CFA1
+#define UNDWARF_REG_DX 2
+#define UNDWARF_REG_DI 3
+#define UNDWARF_REG_BP 4
+#define UNDWARF_REG_SP 5
+#define UNDWARF_REG_R106
+#define UNDWARF_REG_R137
+#define UNDWARF_REG_BP_INDIRECT8
+#define UNDWARF_REG_SP_INDIRECT9
+#define UNDWARF_REG_MAX15
+
+/*
+ * UNDWARF_TYPE_CFA: Indicates that cfa_reg+cfa_offset points to the caller's
+ * stack pointer (aka the CFA in DWARF terms).  Used for all callable
+ * functions, i.e.  all C code and all callable asm functions.
+ *
+ * UNDWARF_TYPE_REGS: Used in entry code to indicate that cfa_reg+cfa_offset
+ * points to a fully populated pt_regs from a syscall, interrupt, or exception.
+ *
+ * UNDWARF_TYPE_REGS_IRET: Used in entry code to indicate that
+ * cfa_reg+cfa_offset points to the iret return frame.
+ *
+ * The CFI_HINT macros are only used for the undwarf_cfi_hints struct.  They
+ * are not used for the undwarf struct due to size and complexity constraints.
+ */
+#define UNDWARF_TYPE_CFA   0
+#define UNDWARF_TYPE_REGS  1
+#define UNDWARF_TYPE_REGS_IRET 2
+#define CFI_HINT_TYPE_SAVE 3
+#define CFI_HINT_TYPE_RESTORE  4
+
+#ifndef __ASSEMBLY__
+/*
+ * This struct contains a simplified version of the DWARF Call Frame
+ * Information standard.  It contains only the necessary parts of the real
+ * DWARF, simplified for ease of access by the in-kernel unwinder.  It tells
+ * the unwinder how to find the previous SP and BP (and sometimes entry regs)
+ * on the stack, given a code address (IP).
+ */
+struct undwarf {
+   int ip;
+   unsigned int len;
+   short cfa_offset;
+   short bp_offset;
+   unsigned cfa_reg:4;
+   unsigned bp_reg:4;
+   unsigned type:2;
+};
+
+/*
+ * This struct is used by asm and inline asm code to manually annotate the
+ * location of registers on the stack for the undwarf unwinder.
+ */
+struct undwarf_cfi_hint {
+   unsigned int ip;
+   short cfa_offset;
+   unsigned 

[RFC PATCH 06/10] x86/entry: add CFI hint undwarf annotations

2017-05-31 Thread Josh Poimboeuf
Add CFI hint undwarf annotations to entry_64.S.  This will enable the
undwarf unwinder to unwind through any location in the entry code
including syscalls, interrupts, and exceptions.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/entry/Makefile   |  1 -
 arch/x86/entry/calling.h  |  5 +
 arch/x86/entry/entry_64.S | 56 ++-
 3 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 9976fce..af28a8a 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the x86 low level entry code
 #
 
-OBJECT_FILES_NON_STANDARD_entry_$(BITS).o   := y
 OBJECT_FILES_NON_STANDARD_entry_64_compat.o := y
 
 CFLAGS_syscall_64.o+= $(call cc-option,-Wno-override-init,)
diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index 05ed3d3..bbec02e 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -1,4 +1,6 @@
 #include 
+#include 
+
 
 /*
 
@@ -112,6 +114,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq %rdx, 12*8+\offset(%rsp)
movq %rsi, 13*8+\offset(%rsp)
movq %rdi, 14*8+\offset(%rsp)
+   CFI_REGS offset=\offset extra=0
.endm
.macro SAVE_C_REGS offset=0
SAVE_C_REGS_HELPER \offset, 1, 1, 1, 1
@@ -136,6 +139,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq %r12, 3*8+\offset(%rsp)
movq %rbp, 4*8+\offset(%rsp)
movq %rbx, 5*8+\offset(%rsp)
+   CFI_REGS offset=\offset
.endm
 
.macro RESTORE_EXTRA_REGS offset=0
@@ -145,6 +149,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq 3*8+\offset(%rsp), %r12
movq 4*8+\offset(%rsp), %rbp
movq 5*8+\offset(%rsp), %rbx
+   CFI_REGS offset=\offset extra=0
.endm
 
.macro RESTORE_C_REGS_HELPER rstor_rax=1, rstor_rcx=1, rstor_r11=1, 
rstor_r8910=1, rstor_rdx=1
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 4a4c083..d280cbe 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 .code64
@@ -43,9 +44,10 @@
 
 #ifdef CONFIG_PARAVIRT
 ENTRY(native_usergs_sysret64)
+   CFI_EMPTY
swapgs
sysretq
-ENDPROC(native_usergs_sysret64)
+END(native_usergs_sysret64)
 #endif /* CONFIG_PARAVIRT */
 
 .macro TRACE_IRQS_IRETQ
@@ -134,6 +136,7 @@ ENDPROC(native_usergs_sysret64)
  */
 
 ENTRY(entry_SYSCALL_64)
+   CFI_EMPTY
/*
 * Interrupts are off on entry.
 * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON,
@@ -169,6 +172,7 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq   %r10/* pt_regs->r10 */
pushq   %r11/* pt_regs->r11 */
sub $(6*8), %rsp/* pt_regs->bp, bx, r12-15 not 
saved */
+   CFI_REGS extra=0
 
/*
 * If we need to do entry work or if we guess we'll need to do
@@ -223,6 +227,7 @@ entry_SYSCALL_64_fastpath:
movqEFLAGS(%rsp), %r11
RESTORE_C_REGS_EXCEPT_RCX_R11
movqRSP(%rsp), %rsp
+   CFI_EMPTY
USERGS_SYSRET64
 
 1:
@@ -315,6 +320,7 @@ syscall_return_via_sysret:
/* rcx and r11 are already restored (see code above) */
RESTORE_C_REGS_EXCEPT_RCX_R11
movqRSP(%rsp), %rsp
+   CFI_EMPTY
USERGS_SYSRET64
 
 opportunistic_sysret_failed:
@@ -342,6 +348,7 @@ ENTRY(stub_ptregs_64)
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
popq%rax
+   CFI_REGS extra=0
jmp entry_SYSCALL64_slow_path
 
 1:
@@ -350,6 +357,7 @@ END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
+   CFI_FUNC
leaq\func(%rip), %rax
jmp stub_ptregs_64
 END(ptregs_\func)
@@ -366,6 +374,7 @@ END(ptregs_\func)
  * %rsi: next task
  */
 ENTRY(__switch_to_asm)
+   CFI_FUNC
/*
 * Save callee-saved registers
 * This must match the order in inactive_task_frame
@@ -405,6 +414,7 @@ END(__switch_to_asm)
  * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
+   CFI_EMPTY
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
@@ -414,6 +424,7 @@ ENTRY(ret_from_fork)
 2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
+   CFI_REGS
TRACE_IRQS_ON   /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
@@ -439,10 +450,11 @@ END(ret_from_fork)
 ENTRY(irq_entries_start)
 vector=FIRST_EXTERNAL_VECTOR
 .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
+   CFI_IRET_REGS
pushq   $(~vector+0x80) /* Note: always in signed byte 
range */
-

[RFC PATCH 05/10] objtool, x86: add facility for asm code to provide CFI hints

2017-05-31 Thread Josh Poimboeuf
Some asm (and inline asm) code does special things to the stack which
objtool can't understand.  (Nor can GCC or GNU assembler, for that
matter.)  In such cases we need a facility for the code to provide
annotations, so the unwinder can unwind through it.

This provides such a facility, in the form of CFI hints.  They're
similar to the GNU assembler .cfi* directives, but they give more
information, and are needed in far fewer places, because objtool can
fill in the blanks by following branches and adjusting the stack pointer
for pushes and pops.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/undwarf-types.h | 100 
 arch/x86/include/asm/undwarf.h   |  97 +++
 tools/objtool/Makefile   |   3 +
 tools/objtool/check.c| 176 ++-
 tools/objtool/check.h|   4 +-
 5 files changed, 373 insertions(+), 7 deletions(-)
 create mode 100644 arch/x86/include/asm/undwarf-types.h
 create mode 100644 arch/x86/include/asm/undwarf.h

diff --git a/arch/x86/include/asm/undwarf-types.h 
b/arch/x86/include/asm/undwarf-types.h
new file mode 100644
index 000..b624188
--- /dev/null
+++ b/arch/x86/include/asm/undwarf-types.h
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2017 Josh Poimboeuf 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#ifndef _UNDWARF_TYPES_H
+#define _UNDWARF_TYPES_H
+
+/*
+ * The UNDWARF_REG_* registers are base registers which are used to find other
+ * registers on the stack.
+ *
+ * The CFA (call frame address) is the value of the stack pointer on the
+ * previous frame, i.e. the caller's SP before it called the callee.
+ *
+ * The CFA is usually based on SP, unless a frame pointer has been saved, in
+ * which case it's based on BP.
+ *
+ * BP is usually either based on CFA or is undefined (meaning its value didn't
+ * change for the current frame).
+ *
+ * So the CFA base is usually either SP or BP, and the FP base is usually 
either
+ * CFA or undefined.  The rest of the base registers are needed for special
+ * cases like entry code and gcc aligned stacks.
+ */
+#define UNDWARF_REG_UNDEFINED  0
+#define UNDWARF_REG_CFA1
+#define UNDWARF_REG_DX 2
+#define UNDWARF_REG_DI 3
+#define UNDWARF_REG_BP 4
+#define UNDWARF_REG_SP 5
+#define UNDWARF_REG_R106
+#define UNDWARF_REG_R137
+#define UNDWARF_REG_BP_INDIRECT8
+#define UNDWARF_REG_SP_INDIRECT9
+#define UNDWARF_REG_MAX15
+
+/*
+ * UNDWARF_TYPE_CFA: Indicates that cfa_reg+cfa_offset points to the caller's
+ * stack pointer (aka the CFA in DWARF terms).  Used for all callable
+ * functions, i.e.  all C code and all callable asm functions.
+ *
+ * UNDWARF_TYPE_REGS: Used in entry code to indicate that cfa_reg+cfa_offset
+ * points to a fully populated pt_regs from a syscall, interrupt, or exception.
+ *
+ * UNDWARF_TYPE_REGS_IRET: Used in entry code to indicate that
+ * cfa_reg+cfa_offset points to the iret return frame.
+ *
+ * The CFI_HINT macros are only used for the undwarf_cfi_hints struct.  They
+ * are not used for the undwarf struct due to size and complexity constraints.
+ */
+#define UNDWARF_TYPE_CFA   0
+#define UNDWARF_TYPE_REGS  1
+#define UNDWARF_TYPE_REGS_IRET 2
+#define CFI_HINT_TYPE_SAVE 3
+#define CFI_HINT_TYPE_RESTORE  4
+
+#ifndef __ASSEMBLY__
+/*
+ * This struct contains a simplified version of the DWARF Call Frame
+ * Information standard.  It contains only the necessary parts of the real
+ * DWARF, simplified for ease of access by the in-kernel unwinder.  It tells
+ * the unwinder how to find the previous SP and BP (and sometimes entry regs)
+ * on the stack, given a code address (IP).
+ */
+struct undwarf {
+   int ip;
+   unsigned int len;
+   short cfa_offset;
+   short bp_offset;
+   unsigned cfa_reg:4;
+   unsigned bp_reg:4;
+   unsigned type:2;
+};
+
+/*
+ * This struct is used by asm and inline asm code to manually annotate the
+ * location of registers on the stack for the undwarf unwinder.
+ */
+struct undwarf_cfi_hint {
+   unsigned int ip;
+   short cfa_offset;
+   unsigned char cfa_reg;
+   unsigned char type;

[RFC PATCH 06/10] x86/entry: add CFI hint undwarf annotations

2017-05-31 Thread Josh Poimboeuf
Add CFI hint undwarf annotations to entry_64.S.  This will enable the
undwarf unwinder to unwind through any location in the entry code
including syscalls, interrupts, and exceptions.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/entry/Makefile   |  1 -
 arch/x86/entry/calling.h  |  5 +
 arch/x86/entry/entry_64.S | 56 ++-
 3 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 9976fce..af28a8a 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the x86 low level entry code
 #
 
-OBJECT_FILES_NON_STANDARD_entry_$(BITS).o   := y
 OBJECT_FILES_NON_STANDARD_entry_64_compat.o := y
 
 CFLAGS_syscall_64.o+= $(call cc-option,-Wno-override-init,)
diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index 05ed3d3..bbec02e 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -1,4 +1,6 @@
 #include 
+#include 
+
 
 /*
 
@@ -112,6 +114,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq %rdx, 12*8+\offset(%rsp)
movq %rsi, 13*8+\offset(%rsp)
movq %rdi, 14*8+\offset(%rsp)
+   CFI_REGS offset=\offset extra=0
.endm
.macro SAVE_C_REGS offset=0
SAVE_C_REGS_HELPER \offset, 1, 1, 1, 1
@@ -136,6 +139,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq %r12, 3*8+\offset(%rsp)
movq %rbp, 4*8+\offset(%rsp)
movq %rbx, 5*8+\offset(%rsp)
+   CFI_REGS offset=\offset
.endm
 
.macro RESTORE_EXTRA_REGS offset=0
@@ -145,6 +149,7 @@ For 32-bit we have the following conventions - kernel is 
built with
movq 3*8+\offset(%rsp), %r12
movq 4*8+\offset(%rsp), %rbp
movq 5*8+\offset(%rsp), %rbx
+   CFI_REGS offset=\offset extra=0
.endm
 
.macro RESTORE_C_REGS_HELPER rstor_rax=1, rstor_rcx=1, rstor_r11=1, 
rstor_r8910=1, rstor_rdx=1
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 4a4c083..d280cbe 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 .code64
@@ -43,9 +44,10 @@
 
 #ifdef CONFIG_PARAVIRT
 ENTRY(native_usergs_sysret64)
+   CFI_EMPTY
swapgs
sysretq
-ENDPROC(native_usergs_sysret64)
+END(native_usergs_sysret64)
 #endif /* CONFIG_PARAVIRT */
 
 .macro TRACE_IRQS_IRETQ
@@ -134,6 +136,7 @@ ENDPROC(native_usergs_sysret64)
  */
 
 ENTRY(entry_SYSCALL_64)
+   CFI_EMPTY
/*
 * Interrupts are off on entry.
 * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON,
@@ -169,6 +172,7 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq   %r10/* pt_regs->r10 */
pushq   %r11/* pt_regs->r11 */
sub $(6*8), %rsp/* pt_regs->bp, bx, r12-15 not 
saved */
+   CFI_REGS extra=0
 
/*
 * If we need to do entry work or if we guess we'll need to do
@@ -223,6 +227,7 @@ entry_SYSCALL_64_fastpath:
movqEFLAGS(%rsp), %r11
RESTORE_C_REGS_EXCEPT_RCX_R11
movqRSP(%rsp), %rsp
+   CFI_EMPTY
USERGS_SYSRET64
 
 1:
@@ -315,6 +320,7 @@ syscall_return_via_sysret:
/* rcx and r11 are already restored (see code above) */
RESTORE_C_REGS_EXCEPT_RCX_R11
movqRSP(%rsp), %rsp
+   CFI_EMPTY
USERGS_SYSRET64
 
 opportunistic_sysret_failed:
@@ -342,6 +348,7 @@ ENTRY(stub_ptregs_64)
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
popq%rax
+   CFI_REGS extra=0
jmp entry_SYSCALL64_slow_path
 
 1:
@@ -350,6 +357,7 @@ END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
+   CFI_FUNC
leaq\func(%rip), %rax
jmp stub_ptregs_64
 END(ptregs_\func)
@@ -366,6 +374,7 @@ END(ptregs_\func)
  * %rsi: next task
  */
 ENTRY(__switch_to_asm)
+   CFI_FUNC
/*
 * Save callee-saved registers
 * This must match the order in inactive_task_frame
@@ -405,6 +414,7 @@ END(__switch_to_asm)
  * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
+   CFI_EMPTY
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
@@ -414,6 +424,7 @@ ENTRY(ret_from_fork)
 2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
+   CFI_REGS
TRACE_IRQS_ON   /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
@@ -439,10 +450,11 @@ END(ret_from_fork)
 ENTRY(irq_entries_start)
 vector=FIRST_EXTERNAL_VECTOR
 .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
+   CFI_IRET_REGS
pushq   $(~vector+0x80) /* Note: always in signed byte 
range */
-vector=vector+1
jmp 

[RFC PATCH 10/10] x86/unwind: add undwarf unwinder

2017-05-31 Thread Josh Poimboeuf
Add a new 'undwarf' unwinder which is enabled by
CONFIG_UNDWARF_UNWINDER.  It plugs into the existing x86 unwinder
framework.

It relies on objtool to generate the needed .undwarf section.

For more details on why undwarf is used instead of DWARF, see
tools/objtool/Documentation/undwarf.txt.

Signed-off-by: Josh Poimboeuf 
---
 arch/um/include/asm/unwind.h  |   7 +
 arch/x86/Kconfig  |   1 +
 arch/x86/Kconfig.debug|  26 +++
 arch/x86/include/asm/module.h |   8 +
 arch/x86/include/asm/unwind.h |  64 +++---
 arch/x86/kernel/Makefile  |   8 +-
 arch/x86/kernel/module.c  |   9 +-
 arch/x86/kernel/unwind_frame.c|  39 ++--
 arch/x86/kernel/unwind_guess.c|   5 +
 arch/x86/kernel/unwind_undwarf.c  | 402 ++
 include/asm-generic/vmlinux.lds.h |  14 ++
 lib/Kconfig.debug |   3 +
 scripts/Makefile.build|   3 +-
 scripts/link-vmlinux.sh   |   5 +
 14 files changed, 534 insertions(+), 60 deletions(-)
 create mode 100644 arch/um/include/asm/unwind.h
 create mode 100644 arch/x86/kernel/unwind_undwarf.c

diff --git a/arch/um/include/asm/unwind.h b/arch/um/include/asm/unwind.h
new file mode 100644
index 000..4e3f719
--- /dev/null
+++ b/arch/um/include/asm/unwind.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_UML_UNWIND_H
+#define _ASM_UML_UNWIND_H
+
+static inline void
+unwind_module_init(struct module *mod, void *undwarf, size_t size) {}
+
+#endif /* _ASM_UML_UNWIND_H */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4ccfacc..869fbc5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -151,6 +151,7 @@ config X86
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MIXED_BREAKPOINTS_REGS
+   select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI
select HAVE_OPROFILE
select HAVE_OPTPROBES
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index fcb7604..6717463 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -357,4 +357,30 @@ config PUNIT_ATOM_DEBUG
  The current power state can be read from
  /sys/kernel/debug/punit_atom/dev_power_state
 
+config UNDWARF_UNWINDER
+   bool "undwarf unwinder"
+   depends on X86_64
+   select STACK_VALIDATION
+   select SORTTABLE
+   ---help---
+ This option enables the "undwarf" unwinder for unwinding kernel stack
+ traces.  It uses a custom data format which is a simplified version
+ of the DWARF Call Frame Information standard.
+
+ This unwinder is more accurate across interrupt entry frames than the
+ frame pointer unwinder.  This also can enable a small performance
+ improvement across the entire kernel if CONFIG_FRAME_POINTER is
+ disabled.
+
+ Enabling this option will increase the kernel's runtime memory usage
+ by roughly 3-5MB, depending on the kernel config.
+
+config FRAME_POINTER_UNWINDER
+   def_bool y
+   depends on !UNDWARF_UNWINDER && FRAME_POINTER
+
+config GUESS_UNWINDER
+   def_bool y
+   depends on !UNDWARF_UNWINDER && !FRAME_POINTER
+
 endmenu
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index e3b7819..454eeea 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -2,6 +2,14 @@
 #define _ASM_X86_MODULE_H
 
 #include 
+#include 
+
+struct mod_arch_specific {
+#ifdef CONFIG_UNDWARF_UNWINDER
+   unsigned int num_undwarves;
+   struct undwarf *undwarf;
+#endif
+};
 
 #ifdef CONFIG_X86_64
 /* X86_64 does not define MODULE_PROC_FAMILY */
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index e667649..f06be3f 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -12,11 +12,13 @@ struct unwind_state {
struct task_struct *task;
int graph_idx;
bool error;
-#ifdef CONFIG_FRAME_POINTER
+#if defined(CONFIG_UNDWARF_UNWINDER)
+   unsigned long sp, bp, ip;
+   struct pt_regs *regs;
+#elif defined(CONFIG_FRAME_POINTER)
bool got_irq;
-   unsigned long *bp, *orig_sp;
+   unsigned long *bp, *orig_sp, ip;
struct pt_regs *regs;
-   unsigned long ip;
 #else
unsigned long *sp;
 #endif
@@ -24,41 +26,30 @@ struct unwind_state {
 
 void __unwind_start(struct unwind_state *state, struct task_struct *task,
struct pt_regs *regs, unsigned long *first_frame);
-
 bool unwind_next_frame(struct unwind_state *state);
-
 unsigned long unwind_get_return_address(struct unwind_state *state);
+unsigned long *unwind_get_return_address_ptr(struct unwind_state *state);
 
 static inline bool unwind_done(struct unwind_state *state)
 {
return state->stack_info.type == STACK_TYPE_UNKNOWN;
 }
 
-static inline
-void unwind_start(struct unwind_state *state, struct task_struct *task,
- struct pt_regs *regs, unsigned long *first_frame)
-{

[RFC PATCH 10/10] x86/unwind: add undwarf unwinder

2017-05-31 Thread Josh Poimboeuf
Add a new 'undwarf' unwinder which is enabled by
CONFIG_UNDWARF_UNWINDER.  It plugs into the existing x86 unwinder
framework.

It relies on objtool to generate the needed .undwarf section.

For more details on why undwarf is used instead of DWARF, see
tools/objtool/Documentation/undwarf.txt.

Signed-off-by: Josh Poimboeuf 
---
 arch/um/include/asm/unwind.h  |   7 +
 arch/x86/Kconfig  |   1 +
 arch/x86/Kconfig.debug|  26 +++
 arch/x86/include/asm/module.h |   8 +
 arch/x86/include/asm/unwind.h |  64 +++---
 arch/x86/kernel/Makefile  |   8 +-
 arch/x86/kernel/module.c  |   9 +-
 arch/x86/kernel/unwind_frame.c|  39 ++--
 arch/x86/kernel/unwind_guess.c|   5 +
 arch/x86/kernel/unwind_undwarf.c  | 402 ++
 include/asm-generic/vmlinux.lds.h |  14 ++
 lib/Kconfig.debug |   3 +
 scripts/Makefile.build|   3 +-
 scripts/link-vmlinux.sh   |   5 +
 14 files changed, 534 insertions(+), 60 deletions(-)
 create mode 100644 arch/um/include/asm/unwind.h
 create mode 100644 arch/x86/kernel/unwind_undwarf.c

diff --git a/arch/um/include/asm/unwind.h b/arch/um/include/asm/unwind.h
new file mode 100644
index 000..4e3f719
--- /dev/null
+++ b/arch/um/include/asm/unwind.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_UML_UNWIND_H
+#define _ASM_UML_UNWIND_H
+
+static inline void
+unwind_module_init(struct module *mod, void *undwarf, size_t size) {}
+
+#endif /* _ASM_UML_UNWIND_H */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4ccfacc..869fbc5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -151,6 +151,7 @@ config X86
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MIXED_BREAKPOINTS_REGS
+   select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI
select HAVE_OPROFILE
select HAVE_OPTPROBES
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index fcb7604..6717463 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -357,4 +357,30 @@ config PUNIT_ATOM_DEBUG
  The current power state can be read from
  /sys/kernel/debug/punit_atom/dev_power_state
 
+config UNDWARF_UNWINDER
+   bool "undwarf unwinder"
+   depends on X86_64
+   select STACK_VALIDATION
+   select SORTTABLE
+   ---help---
+ This option enables the "undwarf" unwinder for unwinding kernel stack
+ traces.  It uses a custom data format which is a simplified version
+ of the DWARF Call Frame Information standard.
+
+ This unwinder is more accurate across interrupt entry frames than the
+ frame pointer unwinder.  This also can enable a small performance
+ improvement across the entire kernel if CONFIG_FRAME_POINTER is
+ disabled.
+
+ Enabling this option will increase the kernel's runtime memory usage
+ by roughly 3-5MB, depending on the kernel config.
+
+config FRAME_POINTER_UNWINDER
+   def_bool y
+   depends on !UNDWARF_UNWINDER && FRAME_POINTER
+
+config GUESS_UNWINDER
+   def_bool y
+   depends on !UNDWARF_UNWINDER && !FRAME_POINTER
+
 endmenu
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index e3b7819..454eeea 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -2,6 +2,14 @@
 #define _ASM_X86_MODULE_H
 
 #include 
+#include 
+
+struct mod_arch_specific {
+#ifdef CONFIG_UNDWARF_UNWINDER
+   unsigned int num_undwarves;
+   struct undwarf *undwarf;
+#endif
+};
 
 #ifdef CONFIG_X86_64
 /* X86_64 does not define MODULE_PROC_FAMILY */
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index e667649..f06be3f 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -12,11 +12,13 @@ struct unwind_state {
struct task_struct *task;
int graph_idx;
bool error;
-#ifdef CONFIG_FRAME_POINTER
+#if defined(CONFIG_UNDWARF_UNWINDER)
+   unsigned long sp, bp, ip;
+   struct pt_regs *regs;
+#elif defined(CONFIG_FRAME_POINTER)
bool got_irq;
-   unsigned long *bp, *orig_sp;
+   unsigned long *bp, *orig_sp, ip;
struct pt_regs *regs;
-   unsigned long ip;
 #else
unsigned long *sp;
 #endif
@@ -24,41 +26,30 @@ struct unwind_state {
 
 void __unwind_start(struct unwind_state *state, struct task_struct *task,
struct pt_regs *regs, unsigned long *first_frame);
-
 bool unwind_next_frame(struct unwind_state *state);
-
 unsigned long unwind_get_return_address(struct unwind_state *state);
+unsigned long *unwind_get_return_address_ptr(struct unwind_state *state);
 
 static inline bool unwind_done(struct unwind_state *state)
 {
return state->stack_info.type == STACK_TYPE_UNKNOWN;
 }
 
-static inline
-void unwind_start(struct unwind_state *state, struct task_struct *task,
- struct pt_regs *regs, unsigned long *first_frame)
-{
-   first_frame 

[RFC PATCH 09/10] extable: add undwarf table sorting ability to sorttable script

2017-05-31 Thread Josh Poimboeuf
The undwarf table needs to be sorted at vmlinux link time, just like the
extable.  Extend sorttable's functionality to do so.

Signed-off-by: Josh Poimboeuf 
---
 init/Kconfig|   4 ++
 scripts/Makefile|   2 +-
 scripts/link-vmlinux.sh |   7 +-
 scripts/sorttable.c | 178 +---
 scripts/sorttable.h |  71 ++-
 5 files changed, 142 insertions(+), 120 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 1d3475f..4c096f0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -25,6 +25,10 @@ config IRQ_WORK
 
 config BUILDTIME_EXTABLE_SORT
bool
+   select SORTTABLE
+
+config SORTTABLE
+   bool
 
 config THREAD_INFO_IN_TASK
bool
diff --git a/scripts/Makefile b/scripts/Makefile
index a7b700f..99c05de 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -15,7 +15,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
-hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sorttable
+hostprogs-$(CONFIG_SORTTABLE)+= sorttable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
 hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 18dd369..f4eb9dc 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -154,7 +154,12 @@ mksysmap()
 
 sortextable()
 {
-   ${objtree}/scripts/sorttable ${1}
+   ${objtree}/scripts/sorttable ${1} extable
+}
+
+sortundwarf()
+{
+   ${objtree}/scripts/sorttable ${1} undwarf
 }
 
 # Delete output files in case of error
diff --git a/scripts/sorttable.c b/scripts/sorttable.c
index 17324dd..299db227 100644
--- a/scripts/sorttable.c
+++ b/scripts/sorttable.c
@@ -1,5 +1,5 @@
 /*
- * sorttable.c: Sort the kernel's exception table
+ * sorttable.c: Sort vmlinux tables
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
@@ -51,11 +51,10 @@
 #define EM_ARCV2   195
 #endif
 
-static int fd_map; /* File descriptor for file being modified. */
-static int mmap_failed; /* Boolean flag. */
+static int fd_map = -1;/* File descriptor for file being modified. */
+static int mmap_succeeded; /* Boolean flag. */
 static void *ehdr_curr; /* current ElfXX_Ehdr *  for resource cleanup */
 static struct stat sb; /* Remember .st_size, etc. */
-static jmp_buf jmpenv; /* setjmp/longjmp per-file error escape */
 
 /* setjmp() return values */
 enum {
@@ -64,20 +63,19 @@ enum {
SJ_SUCCEED
 };
 
+enum sectype {
+   SEC_TYPE_EXTABLE,
+   SEC_TYPE_UNDWARF,
+};
+
 /* Per-file resource cleanup when multiple files. */
 static void
 cleanup(void)
 {
-   if (!mmap_failed)
+   if (mmap_succeeded)
munmap(ehdr_curr, sb.st_size);
-   close(fd_map);
-}
-
-static void __attribute__((noreturn))
-fail_file(void)
-{
-   cleanup();
-   longjmp(jmpenv, SJ_FAIL);
+   if (fd_map >= 0)
+   close(fd_map);
 }
 
 /*
@@ -93,19 +91,20 @@ static void *mmap_file(char const *fname)
fd_map = open(fname, O_RDWR);
if (fd_map < 0 || fstat(fd_map, ) < 0) {
perror(fname);
-   fail_file();
+   return NULL;
}
if (!S_ISREG(sb.st_mode)) {
fprintf(stderr, "not a regular file: %s\n", fname);
-   fail_file();
+   return NULL;
}
addr = mmap(0, sb.st_size, PROT_READ|PROT_WRITE, MAP_SHARED,
fd_map, 0);
if (addr == MAP_FAILED) {
-   mmap_failed = 1;
fprintf(stderr, "Could not mmap file: %s\n", fname);
-   fail_file();
+   return NULL;
}
+   mmap_succeeded = 1;
+
return addr;
 }
 
@@ -166,7 +165,7 @@ static void (*w8)(uint64_t, uint64_t *);
 static void (*w)(uint32_t, uint32_t *);
 static void (*w2)(uint16_t, uint16_t *);
 
-typedef void (*table_sort_t)(char *, int);
+typedef void (*table_sort_t)(char *, size_t, size_t);
 
 /*
  * Move reserved section indices SHN_LORESERVE..SHN_HIRESERVE out of
@@ -194,7 +193,7 @@ static inline unsigned int get_secindex(unsigned int shndx,
 
 /* 32 bit and 64 bit are very similar */
 #include "sorttable.h"
-#define SORTEXTABLE_64
+#define SORTTABLE_64
 #include "sorttable.h"
 
 static int compare_relative_table(const void *a, const void *b)
@@ -209,36 +208,33 @@ static int compare_relative_table(const void *a, const 
void *b)
return 0;
 }
 
-static void x86_sort_relative_table(char *extab_image, int image_size)
+static void sort_relative_extable(char *image, size_t image_size, size_t 
entsize)
 {
int i;
 
+   /*
+* Do the same thing the runtime sort does, first normalize to
+* being relative to the start of the section.
+*/
i = 0;
while (i < image_size) {
-  

[RFC PATCH 09/10] extable: add undwarf table sorting ability to sorttable script

2017-05-31 Thread Josh Poimboeuf
The undwarf table needs to be sorted at vmlinux link time, just like the
extable.  Extend sorttable's functionality to do so.

Signed-off-by: Josh Poimboeuf 
---
 init/Kconfig|   4 ++
 scripts/Makefile|   2 +-
 scripts/link-vmlinux.sh |   7 +-
 scripts/sorttable.c | 178 +---
 scripts/sorttable.h |  71 ++-
 5 files changed, 142 insertions(+), 120 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 1d3475f..4c096f0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -25,6 +25,10 @@ config IRQ_WORK
 
 config BUILDTIME_EXTABLE_SORT
bool
+   select SORTTABLE
+
+config SORTTABLE
+   bool
 
 config THREAD_INFO_IN_TASK
bool
diff --git a/scripts/Makefile b/scripts/Makefile
index a7b700f..99c05de 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -15,7 +15,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
-hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sorttable
+hostprogs-$(CONFIG_SORTTABLE)+= sorttable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
 hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 18dd369..f4eb9dc 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -154,7 +154,12 @@ mksysmap()
 
 sortextable()
 {
-   ${objtree}/scripts/sorttable ${1}
+   ${objtree}/scripts/sorttable ${1} extable
+}
+
+sortundwarf()
+{
+   ${objtree}/scripts/sorttable ${1} undwarf
 }
 
 # Delete output files in case of error
diff --git a/scripts/sorttable.c b/scripts/sorttable.c
index 17324dd..299db227 100644
--- a/scripts/sorttable.c
+++ b/scripts/sorttable.c
@@ -1,5 +1,5 @@
 /*
- * sorttable.c: Sort the kernel's exception table
+ * sorttable.c: Sort vmlinux tables
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
@@ -51,11 +51,10 @@
 #define EM_ARCV2   195
 #endif
 
-static int fd_map; /* File descriptor for file being modified. */
-static int mmap_failed; /* Boolean flag. */
+static int fd_map = -1;/* File descriptor for file being modified. */
+static int mmap_succeeded; /* Boolean flag. */
 static void *ehdr_curr; /* current ElfXX_Ehdr *  for resource cleanup */
 static struct stat sb; /* Remember .st_size, etc. */
-static jmp_buf jmpenv; /* setjmp/longjmp per-file error escape */
 
 /* setjmp() return values */
 enum {
@@ -64,20 +63,19 @@ enum {
SJ_SUCCEED
 };
 
+enum sectype {
+   SEC_TYPE_EXTABLE,
+   SEC_TYPE_UNDWARF,
+};
+
 /* Per-file resource cleanup when multiple files. */
 static void
 cleanup(void)
 {
-   if (!mmap_failed)
+   if (mmap_succeeded)
munmap(ehdr_curr, sb.st_size);
-   close(fd_map);
-}
-
-static void __attribute__((noreturn))
-fail_file(void)
-{
-   cleanup();
-   longjmp(jmpenv, SJ_FAIL);
+   if (fd_map >= 0)
+   close(fd_map);
 }
 
 /*
@@ -93,19 +91,20 @@ static void *mmap_file(char const *fname)
fd_map = open(fname, O_RDWR);
if (fd_map < 0 || fstat(fd_map, ) < 0) {
perror(fname);
-   fail_file();
+   return NULL;
}
if (!S_ISREG(sb.st_mode)) {
fprintf(stderr, "not a regular file: %s\n", fname);
-   fail_file();
+   return NULL;
}
addr = mmap(0, sb.st_size, PROT_READ|PROT_WRITE, MAP_SHARED,
fd_map, 0);
if (addr == MAP_FAILED) {
-   mmap_failed = 1;
fprintf(stderr, "Could not mmap file: %s\n", fname);
-   fail_file();
+   return NULL;
}
+   mmap_succeeded = 1;
+
return addr;
 }
 
@@ -166,7 +165,7 @@ static void (*w8)(uint64_t, uint64_t *);
 static void (*w)(uint32_t, uint32_t *);
 static void (*w2)(uint16_t, uint16_t *);
 
-typedef void (*table_sort_t)(char *, int);
+typedef void (*table_sort_t)(char *, size_t, size_t);
 
 /*
  * Move reserved section indices SHN_LORESERVE..SHN_HIRESERVE out of
@@ -194,7 +193,7 @@ static inline unsigned int get_secindex(unsigned int shndx,
 
 /* 32 bit and 64 bit are very similar */
 #include "sorttable.h"
-#define SORTEXTABLE_64
+#define SORTTABLE_64
 #include "sorttable.h"
 
 static int compare_relative_table(const void *a, const void *b)
@@ -209,36 +208,33 @@ static int compare_relative_table(const void *a, const 
void *b)
return 0;
 }
 
-static void x86_sort_relative_table(char *extab_image, int image_size)
+static void sort_relative_extable(char *image, size_t image_size, size_t 
entsize)
 {
int i;
 
+   /*
+* Do the same thing the runtime sort does, first normalize to
+* being relative to the start of the section.
+*/
i = 0;
while (i < image_size) {
-   uint32_t *loc = 

[RFC PATCH 07/10] x86/asm: add CFI hint annotations to sync_core()

2017-05-31 Thread Josh Poimboeuf
This enables the unwinder to grok the iret in the middle of a C
function.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/processor.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 3cada99..9b90129 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -22,6 +22,7 @@ struct vm86;
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -676,6 +677,7 @@ static inline void sync_core(void)
unsigned int tmp;
 
asm volatile (
+   CFI_SAVE
"mov %%ss, %0\n\t"
"pushq %q0\n\t"
"pushq %%rsp\n\t"
@@ -685,6 +687,7 @@ static inline void sync_core(void)
"pushq %q0\n\t"
"pushq $1f\n\t"
"iretq\n\t"
+   CFI_RESTORE
"1:"
: "=" (tmp), "+r" (__sp) : : "cc", "memory");
 #endif
-- 
2.7.4



[RFC PATCH 08/10] extable: rename 'sortextable' script to 'sorttable'

2017-05-31 Thread Josh Poimboeuf
Soon it will be used to sort the undwarf table as well.

Signed-off-by: Josh Poimboeuf 
---
 Documentation/dontdiff | 2 +-
 scripts/.gitignore | 2 +-
 scripts/Makefile   | 4 ++--
 scripts/link-vmlinux.sh| 2 +-
 scripts/{sortextable.c => sorttable.c} | 8 
 scripts/{sortextable.h => sorttable.h} | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)
 rename scripts/{sortextable.c => sorttable.c} (98%)
 rename scripts/{sortextable.h => sorttable.h} (99%)

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 77b9222..b270d98 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -217,7 +217,7 @@ series
 setup
 setup.bin
 setup.elf
-sortextable
+sorttable
 sImage
 sm_tbl*
 split-include
diff --git a/scripts/.gitignore b/scripts/.gitignore
index e063daa..14b108e 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -9,7 +9,7 @@ ihex2fw
 recordmcount
 docproc
 check-lc_ctype
-sortextable
+sorttable
 asn1_compiler
 extract-cert
 sign-file
diff --git a/scripts/Makefile b/scripts/Makefile
index 1d80897..a7b700f 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -15,13 +15,13 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
-hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
+hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sorttable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
 hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
 hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert
 
-HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
+HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
 HOSTLOADLIBES_sign-file = -lcrypto
 HOSTLOADLIBES_extract-cert = -lcrypto
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c802913..18dd369 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -154,7 +154,7 @@ mksysmap()
 
 sortextable()
 {
-   ${objtree}/scripts/sortextable ${1}
+   ${objtree}/scripts/sorttable ${1}
 }
 
 # Delete output files in case of error
diff --git a/scripts/sortextable.c b/scripts/sorttable.c
similarity index 98%
rename from scripts/sortextable.c
rename to scripts/sorttable.c
index 365a907..17324dd 100644
--- a/scripts/sortextable.c
+++ b/scripts/sorttable.c
@@ -1,5 +1,5 @@
 /*
- * sortextable.c: Sort the kernel's exception table
+ * sorttable.c: Sort the kernel's exception table
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
@@ -193,9 +193,9 @@ static inline unsigned int get_secindex(unsigned int shndx,
 }
 
 /* 32 bit and 64 bit are very similar */
-#include "sortextable.h"
+#include "sorttable.h"
 #define SORTEXTABLE_64
-#include "sortextable.h"
+#include "sorttable.h"
 
 static int compare_relative_table(const void *a, const void *b)
 {
@@ -367,7 +367,7 @@ main(int argc, char *argv[])
int i;
 
if (argc < 2) {
-   fprintf(stderr, "usage: sortextable vmlinux...\n");
+   fprintf(stderr, "usage: sorttable vmlinux...\n");
return 0;
}
 
diff --git a/scripts/sortextable.h b/scripts/sorttable.h
similarity index 99%
rename from scripts/sortextable.h
rename to scripts/sorttable.h
index ba87004..0de9488 100644
--- a/scripts/sortextable.h
+++ b/scripts/sorttable.h
@@ -1,5 +1,5 @@
 /*
- * sortextable.h
+ * sorttable.h
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
-- 
2.7.4



[RFC PATCH 07/10] x86/asm: add CFI hint annotations to sync_core()

2017-05-31 Thread Josh Poimboeuf
This enables the unwinder to grok the iret in the middle of a C
function.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/processor.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 3cada99..9b90129 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -22,6 +22,7 @@ struct vm86;
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -676,6 +677,7 @@ static inline void sync_core(void)
unsigned int tmp;
 
asm volatile (
+   CFI_SAVE
"mov %%ss, %0\n\t"
"pushq %q0\n\t"
"pushq %%rsp\n\t"
@@ -685,6 +687,7 @@ static inline void sync_core(void)
"pushq %q0\n\t"
"pushq $1f\n\t"
"iretq\n\t"
+   CFI_RESTORE
"1:"
: "=" (tmp), "+r" (__sp) : : "cc", "memory");
 #endif
-- 
2.7.4



[RFC PATCH 08/10] extable: rename 'sortextable' script to 'sorttable'

2017-05-31 Thread Josh Poimboeuf
Soon it will be used to sort the undwarf table as well.

Signed-off-by: Josh Poimboeuf 
---
 Documentation/dontdiff | 2 +-
 scripts/.gitignore | 2 +-
 scripts/Makefile   | 4 ++--
 scripts/link-vmlinux.sh| 2 +-
 scripts/{sortextable.c => sorttable.c} | 8 
 scripts/{sortextable.h => sorttable.h} | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)
 rename scripts/{sortextable.c => sorttable.c} (98%)
 rename scripts/{sortextable.h => sorttable.h} (99%)

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 77b9222..b270d98 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -217,7 +217,7 @@ series
 setup
 setup.bin
 setup.elf
-sortextable
+sorttable
 sImage
 sm_tbl*
 split-include
diff --git a/scripts/.gitignore b/scripts/.gitignore
index e063daa..14b108e 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -9,7 +9,7 @@ ihex2fw
 recordmcount
 docproc
 check-lc_ctype
-sortextable
+sorttable
 asn1_compiler
 extract-cert
 sign-file
diff --git a/scripts/Makefile b/scripts/Makefile
index 1d80897..a7b700f 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -15,13 +15,13 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
-hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
+hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sorttable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
 hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
 hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert
 
-HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
+HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
 HOSTLOADLIBES_sign-file = -lcrypto
 HOSTLOADLIBES_extract-cert = -lcrypto
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c802913..18dd369 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -154,7 +154,7 @@ mksysmap()
 
 sortextable()
 {
-   ${objtree}/scripts/sortextable ${1}
+   ${objtree}/scripts/sorttable ${1}
 }
 
 # Delete output files in case of error
diff --git a/scripts/sortextable.c b/scripts/sorttable.c
similarity index 98%
rename from scripts/sortextable.c
rename to scripts/sorttable.c
index 365a907..17324dd 100644
--- a/scripts/sortextable.c
+++ b/scripts/sorttable.c
@@ -1,5 +1,5 @@
 /*
- * sortextable.c: Sort the kernel's exception table
+ * sorttable.c: Sort the kernel's exception table
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
@@ -193,9 +193,9 @@ static inline unsigned int get_secindex(unsigned int shndx,
 }
 
 /* 32 bit and 64 bit are very similar */
-#include "sortextable.h"
+#include "sorttable.h"
 #define SORTEXTABLE_64
-#include "sortextable.h"
+#include "sorttable.h"
 
 static int compare_relative_table(const void *a, const void *b)
 {
@@ -367,7 +367,7 @@ main(int argc, char *argv[])
int i;
 
if (argc < 2) {
-   fprintf(stderr, "usage: sortextable vmlinux...\n");
+   fprintf(stderr, "usage: sorttable vmlinux...\n");
return 0;
}
 
diff --git a/scripts/sortextable.h b/scripts/sorttable.h
similarity index 99%
rename from scripts/sortextable.h
rename to scripts/sorttable.h
index ba87004..0de9488 100644
--- a/scripts/sortextable.h
+++ b/scripts/sorttable.h
@@ -1,5 +1,5 @@
 /*
- * sortextable.h
+ * sorttable.h
  *
  * Copyright 2011 - 2012 Cavium, Inc.
  *
-- 
2.7.4



[RFC PATCH 00/10] x86: undwarf unwinder

2017-05-31 Thread Josh Poimboeuf
Create a new 'undwarf' unwinder, enabled by CONFIG_UNDWARF_UNWINDER, and
plug it into the x86 unwinder framework.  Objtool is used to generate
the undwarf debuginfo.  The undwarf debuginfo format is basically a
simplified version of DWARF CFI.  More details below.

The unwinder works well in my testing.  It unwinds through interrupts,
exceptions, and preemption, with and without frame pointers, across
aligned stacks and dynamically allocated stacks.  If something goes
wrong during an oops, it successfully falls back to printing the '?'
entries just like the frame pointer unwinder.

I'm not tied to the 'undwarf' name, other naming ideas are welcome.

Some potential future improvements:
- properly annotate or fix whitelisted functions and files
- reduce the number of base CFA registers needed in entry code
- compress undwarf debuginfo to use less memory
- make it easier to disable CONFIG_FRAME_POINTER
- add reliability checks for livepatch
- runtime NMI stack reliability checker

This code can also be found at:

  git://github.com/jpoimboe/linux undwarf-rfc

Here's the contents of the undwarf.txt file which explains the 'why' in
more detail:


Undwarf debuginfo generation


Overview


The kernel CONFIG_UNDWARF_UNWINDER option enables objtool generation of
undwarf debuginfo, which is out-of-band data which is used by the
in-kernel undwarf unwinder.  It's similar in concept to DWARF CFI
debuginfo which would be used by a DWARF unwinder.  The difference is
that the format of the undwarf data is simpler than DWARF, which in turn
allows the unwinder to be simpler.

Objtool generates the undwarf data by piggybacking on the compile-time
stack metadata validation work described in stack-validation.txt.  After
analyzing all the code paths of a .o file, it creates an array of
'struct undwarf's and writes them to the .undwarf section.

Then at vmlinux link time, the .undwarf section is sorted by the
sorttable script.  The resulting sorted array of undwarf structs is used
by the unwinder at runtime to correlate a given text address with its
stack state.


Why not just use DWARF?
---

Undwarf has some of the same benefits as DWARF.  Unlike frame pointers,
the debuginfo is out-of-band. so it has no effect on runtime
performance.  Another benefit is that it's possible to reliably unwind
across interrupts and exceptions.

Undwarf debuginfo's advantage over DWARF itself is that it's much
simpler.  It gets rid of the DWARF CFI state machine and also gets rid
of the tracking of unnecessary registers.  This allows the unwinder to
be much simpler, meaning fewer bugs, which is especially important for
mission critical oops code.

The simpler debuginfo format also enables the unwinder to be relatively
fast, which is important for perf and lockdep.

The undwarf format does have a few downsides.  The undwarf table takes
up extra memory -- something in the ballpark of 3-5MB, depending on the
kernel config.  In the future we may try to rearrange the data to
compress that a bit.

Another downside is that, as GCC evolves, it's conceivable that the
undwarf data may end up being *too* simple to describe the state of the
stack for certain optimizations.  Will we end up having to track the
state of more registers and eventually end up reinventing DWARF?

I think this is unlikely because GCC seems to save the frame pointer for
any unusual stack adjustments it does, so I suspect we'll really only
ever need to keep track of the stack pointer and the frame pointer
between call frames.  But even if we do end up having to track all the
registers DWARF tracks, at least we will still control the format, e.g.
no complex state machines.


Why generate undwarf with objtool?
--

It should be possible to generate the undwarf data with a simple tool
which converts DWARF to undwarf.  However, such a solution would be
incomplete due to the kernel's extensive use of asm, inline asm, and
special sections like exception tables.

That could be rectified by manually annotating those special code paths
using GNU assembler .cfi annotations in .S files, and homegrown
annotations for inline asm in .c files.  But asm annotations were tried
in the past and were found to be unmaintainable.  They were often
incorrect/incomplete and made the code harder to read and keep updated.
And based on looking at glibc code, annotating inline asm in .c files
might be even worse.

With compile-time stack metadata validation, objtool already follows all
the code paths and already has all the information it needs to be able
to generate undwarf data from scratch.  So it's an easy step to go from
stack validation to undwarf generation.

Objtool still needs a few annotations, but only in code which does
unusual things to the stack like entry code.  And even then, far fewer
annotations are needed than what DWARF would need, so it's much more
maintainable than DWARF CFI annotations.

So the advantages 

[RFC PATCH 01/10] objtool: move checking code to check.c

2017-05-31 Thread Josh Poimboeuf
In preparation for the new 'objtool undwarf generate' command, which
will rely on 'objtool check', move the checking code from
builtin-check.c to check.c where it can be used by other commands.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Build|1 +
 tools/objtool/builtin-check.c  | 1280 +---
 tools/objtool/{builtin-check.c => check.c} |   58 +-
 tools/objtool/check.h  |   52 ++
 4 files changed, 71 insertions(+), 1320 deletions(-)
 copy tools/objtool/{builtin-check.c => check.c} (95%)
 create mode 100644 tools/objtool/check.h

diff --git a/tools/objtool/Build b/tools/objtool/Build
index d6cdece..6f2e198 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,5 +1,6 @@
 objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
+objtool-y += check.o
 objtool-y += elf.o
 objtool-y += special.o
 objtool-y += objtool.o
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index 282a603..365c34e 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2015 Josh Poimboeuf 
+ * Copyright (C) 2015-2017 Josh Poimboeuf 
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -25,1286 +25,32 @@
  * For more information, see tools/objtool/Documentation/stack-validation.txt.
  */
 
-#include 
-#include 
 #include 
-
 #include "builtin.h"
-#include "elf.h"
-#include "special.h"
-#include "arch.h"
-#include "warn.h"
-
-#include 
-#include 
-
-#define STATE_FP_SAVED 0x1
-#define STATE_FP_SETUP 0x2
-#define STATE_FENTRY   0x4
-
-struct instruction {
-   struct list_head list;
-   struct hlist_node hash;
-   struct section *sec;
-   unsigned long offset;
-   unsigned int len, state;
-   unsigned char type;
-   unsigned long immediate;
-   bool alt_group, visited, dead_end;
-   struct symbol *call_dest;
-   struct instruction *jump_dest;
-   struct list_head alts;
-   struct symbol *func;
-};
-
-struct alternative {
-   struct list_head list;
-   struct instruction *insn;
-};
-
-struct objtool_file {
-   struct elf *elf;
-   struct list_head insn_list;
-   DECLARE_HASHTABLE(insn_hash, 16);
-   struct section *rodata, *whitelist;
-   bool ignore_unreachables, c_file;
-};
-
-const char *objname;
-static bool nofp;
-
-static struct instruction *find_insn(struct objtool_file *file,
-struct section *sec, unsigned long offset)
-{
-   struct instruction *insn;
-
-   hash_for_each_possible(file->insn_hash, insn, hash, offset)
-   if (insn->sec == sec && insn->offset == offset)
-   return insn;
-
-   return NULL;
-}
-
-static struct instruction *next_insn_same_sec(struct objtool_file *file,
- struct instruction *insn)
-{
-   struct instruction *next = list_next_entry(insn, list);
-
-   if (>list == >insn_list || next->sec != insn->sec)
-   return NULL;
-
-   return next;
-}
-
-static bool gcov_enabled(struct objtool_file *file)
-{
-   struct section *sec;
-   struct symbol *sym;
-
-   list_for_each_entry(sec, >elf->sections, list)
-   list_for_each_entry(sym, >symbol_list, list)
-   if (!strncmp(sym->name, "__gcov_.", 8))
-   return true;
-
-   return false;
-}
-
-#define for_each_insn(file, insn)  \
-   list_for_each_entry(insn, >insn_list, list)
-
-#define func_for_each_insn(file, func, insn)   \
-   for (insn = find_insn(file, func->sec, func->offset);   \
-insn && >list != >insn_list && \
-   insn->sec == func->sec &&   \
-   insn->offset < func->offset + func->len;\
-insn = list_next_entry(insn, list))
-
-#define func_for_each_insn_continue_reverse(file, func, insn)  \
-   for (insn = list_prev_entry(insn, list);\
->list != >insn_list && \
-   insn->sec == func->sec && insn->offset >= func->offset; \
-insn = list_prev_entry(insn, list))
-
-#define sec_for_each_insn_from(file, insn) \
-   for (; insn; insn = next_insn_same_sec(file, insn))
-
-
-/*
- * Check if the function has been manually whitelisted with the
- * STACK_FRAME_NON_STANDARD macro, or if it should be automatically whitelisted
- * due to its use of a context switching instruction.
- */
-static bool ignore_func(struct objtool_file *file, struct symbol *func)
-{
-   struct rela *rela;
-   struct instruction *insn;
-

[RFC PATCH 00/10] x86: undwarf unwinder

2017-05-31 Thread Josh Poimboeuf
Create a new 'undwarf' unwinder, enabled by CONFIG_UNDWARF_UNWINDER, and
plug it into the x86 unwinder framework.  Objtool is used to generate
the undwarf debuginfo.  The undwarf debuginfo format is basically a
simplified version of DWARF CFI.  More details below.

The unwinder works well in my testing.  It unwinds through interrupts,
exceptions, and preemption, with and without frame pointers, across
aligned stacks and dynamically allocated stacks.  If something goes
wrong during an oops, it successfully falls back to printing the '?'
entries just like the frame pointer unwinder.

I'm not tied to the 'undwarf' name, other naming ideas are welcome.

Some potential future improvements:
- properly annotate or fix whitelisted functions and files
- reduce the number of base CFA registers needed in entry code
- compress undwarf debuginfo to use less memory
- make it easier to disable CONFIG_FRAME_POINTER
- add reliability checks for livepatch
- runtime NMI stack reliability checker

This code can also be found at:

  git://github.com/jpoimboe/linux undwarf-rfc

Here's the contents of the undwarf.txt file which explains the 'why' in
more detail:


Undwarf debuginfo generation


Overview


The kernel CONFIG_UNDWARF_UNWINDER option enables objtool generation of
undwarf debuginfo, which is out-of-band data which is used by the
in-kernel undwarf unwinder.  It's similar in concept to DWARF CFI
debuginfo which would be used by a DWARF unwinder.  The difference is
that the format of the undwarf data is simpler than DWARF, which in turn
allows the unwinder to be simpler.

Objtool generates the undwarf data by piggybacking on the compile-time
stack metadata validation work described in stack-validation.txt.  After
analyzing all the code paths of a .o file, it creates an array of
'struct undwarf's and writes them to the .undwarf section.

Then at vmlinux link time, the .undwarf section is sorted by the
sorttable script.  The resulting sorted array of undwarf structs is used
by the unwinder at runtime to correlate a given text address with its
stack state.


Why not just use DWARF?
---

Undwarf has some of the same benefits as DWARF.  Unlike frame pointers,
the debuginfo is out-of-band. so it has no effect on runtime
performance.  Another benefit is that it's possible to reliably unwind
across interrupts and exceptions.

Undwarf debuginfo's advantage over DWARF itself is that it's much
simpler.  It gets rid of the DWARF CFI state machine and also gets rid
of the tracking of unnecessary registers.  This allows the unwinder to
be much simpler, meaning fewer bugs, which is especially important for
mission critical oops code.

The simpler debuginfo format also enables the unwinder to be relatively
fast, which is important for perf and lockdep.

The undwarf format does have a few downsides.  The undwarf table takes
up extra memory -- something in the ballpark of 3-5MB, depending on the
kernel config.  In the future we may try to rearrange the data to
compress that a bit.

Another downside is that, as GCC evolves, it's conceivable that the
undwarf data may end up being *too* simple to describe the state of the
stack for certain optimizations.  Will we end up having to track the
state of more registers and eventually end up reinventing DWARF?

I think this is unlikely because GCC seems to save the frame pointer for
any unusual stack adjustments it does, so I suspect we'll really only
ever need to keep track of the stack pointer and the frame pointer
between call frames.  But even if we do end up having to track all the
registers DWARF tracks, at least we will still control the format, e.g.
no complex state machines.


Why generate undwarf with objtool?
--

It should be possible to generate the undwarf data with a simple tool
which converts DWARF to undwarf.  However, such a solution would be
incomplete due to the kernel's extensive use of asm, inline asm, and
special sections like exception tables.

That could be rectified by manually annotating those special code paths
using GNU assembler .cfi annotations in .S files, and homegrown
annotations for inline asm in .c files.  But asm annotations were tried
in the past and were found to be unmaintainable.  They were often
incorrect/incomplete and made the code harder to read and keep updated.
And based on looking at glibc code, annotating inline asm in .c files
might be even worse.

With compile-time stack metadata validation, objtool already follows all
the code paths and already has all the information it needs to be able
to generate undwarf data from scratch.  So it's an easy step to go from
stack validation to undwarf generation.

Objtool still needs a few annotations, but only in code which does
unusual things to the stack like entry code.  And even then, far fewer
annotations are needed than what DWARF would need, so it's much more
maintainable than DWARF CFI annotations.

So the advantages 

[RFC PATCH 01/10] objtool: move checking code to check.c

2017-05-31 Thread Josh Poimboeuf
In preparation for the new 'objtool undwarf generate' command, which
will rely on 'objtool check', move the checking code from
builtin-check.c to check.c where it can be used by other commands.

Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/Build|1 +
 tools/objtool/builtin-check.c  | 1280 +---
 tools/objtool/{builtin-check.c => check.c} |   58 +-
 tools/objtool/check.h  |   52 ++
 4 files changed, 71 insertions(+), 1320 deletions(-)
 copy tools/objtool/{builtin-check.c => check.c} (95%)
 create mode 100644 tools/objtool/check.h

diff --git a/tools/objtool/Build b/tools/objtool/Build
index d6cdece..6f2e198 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,5 +1,6 @@
 objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
+objtool-y += check.o
 objtool-y += elf.o
 objtool-y += special.o
 objtool-y += objtool.o
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index 282a603..365c34e 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2015 Josh Poimboeuf 
+ * Copyright (C) 2015-2017 Josh Poimboeuf 
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -25,1286 +25,32 @@
  * For more information, see tools/objtool/Documentation/stack-validation.txt.
  */
 
-#include 
-#include 
 #include 
-
 #include "builtin.h"
-#include "elf.h"
-#include "special.h"
-#include "arch.h"
-#include "warn.h"
-
-#include 
-#include 
-
-#define STATE_FP_SAVED 0x1
-#define STATE_FP_SETUP 0x2
-#define STATE_FENTRY   0x4
-
-struct instruction {
-   struct list_head list;
-   struct hlist_node hash;
-   struct section *sec;
-   unsigned long offset;
-   unsigned int len, state;
-   unsigned char type;
-   unsigned long immediate;
-   bool alt_group, visited, dead_end;
-   struct symbol *call_dest;
-   struct instruction *jump_dest;
-   struct list_head alts;
-   struct symbol *func;
-};
-
-struct alternative {
-   struct list_head list;
-   struct instruction *insn;
-};
-
-struct objtool_file {
-   struct elf *elf;
-   struct list_head insn_list;
-   DECLARE_HASHTABLE(insn_hash, 16);
-   struct section *rodata, *whitelist;
-   bool ignore_unreachables, c_file;
-};
-
-const char *objname;
-static bool nofp;
-
-static struct instruction *find_insn(struct objtool_file *file,
-struct section *sec, unsigned long offset)
-{
-   struct instruction *insn;
-
-   hash_for_each_possible(file->insn_hash, insn, hash, offset)
-   if (insn->sec == sec && insn->offset == offset)
-   return insn;
-
-   return NULL;
-}
-
-static struct instruction *next_insn_same_sec(struct objtool_file *file,
- struct instruction *insn)
-{
-   struct instruction *next = list_next_entry(insn, list);
-
-   if (>list == >insn_list || next->sec != insn->sec)
-   return NULL;
-
-   return next;
-}
-
-static bool gcov_enabled(struct objtool_file *file)
-{
-   struct section *sec;
-   struct symbol *sym;
-
-   list_for_each_entry(sec, >elf->sections, list)
-   list_for_each_entry(sym, >symbol_list, list)
-   if (!strncmp(sym->name, "__gcov_.", 8))
-   return true;
-
-   return false;
-}
-
-#define for_each_insn(file, insn)  \
-   list_for_each_entry(insn, >insn_list, list)
-
-#define func_for_each_insn(file, func, insn)   \
-   for (insn = find_insn(file, func->sec, func->offset);   \
-insn && >list != >insn_list && \
-   insn->sec == func->sec &&   \
-   insn->offset < func->offset + func->len;\
-insn = list_next_entry(insn, list))
-
-#define func_for_each_insn_continue_reverse(file, func, insn)  \
-   for (insn = list_prev_entry(insn, list);\
->list != >insn_list && \
-   insn->sec == func->sec && insn->offset >= func->offset; \
-insn = list_prev_entry(insn, list))
-
-#define sec_for_each_insn_from(file, insn) \
-   for (; insn; insn = next_insn_same_sec(file, insn))
-
-
-/*
- * Check if the function has been manually whitelisted with the
- * STACK_FRAME_NON_STANDARD macro, or if it should be automatically whitelisted
- * due to its use of a context switching instruction.
- */
-static bool ignore_func(struct objtool_file *file, struct symbol *func)
-{
-   struct rela *rela;
-   struct instruction *insn;
-
-   /* check for STACK_FRAME_NON_STANDARD */
-   if 

Re: [PATCH v3 14/23] scsi: hisi_sas: add v3 cq interrupt handler

2017-05-31 Thread Christoph Hellwig
> + case SAS_PROTOCOL_SSP:
> + {
> + unsigned char op = task->ssp_task.cmd->cmnd[0];
> +
> + if (op == READ_6 || op == WRITE_6 ||
> + op == READ_10 || op == WRITE_10 ||
> + op == READ_12 || op == WRITE_12 ||
> + op == READ_16 || op == WRITE_16)
> + return true;
> + break;
> + }

Wee. why do you care?  What about 32-byte CDs or things like Write Same?


Re: [PATCH v3 14/23] scsi: hisi_sas: add v3 cq interrupt handler

2017-05-31 Thread Christoph Hellwig
> + case SAS_PROTOCOL_SSP:
> + {
> + unsigned char op = task->ssp_task.cmd->cmnd[0];
> +
> + if (op == READ_6 || op == WRITE_6 ||
> + op == READ_10 || op == WRITE_10 ||
> + op == READ_12 || op == WRITE_12 ||
> + op == READ_16 || op == WRITE_16)
> + return true;
> + break;
> + }

Wee. why do you care?  What about 32-byte CDs or things like Write Same?


Re: [PATCH v3 13/23] scsi: hisi_sas: add phy up/down/bcast and channel ISR

2017-05-31 Thread Christoph Hellwig
On Wed, May 31, 2017 at 10:33:05PM +0800, John Garry wrote:
> From: Xiang Chen 
> 
> Add code to initialise interrupts and add some interrupt handlers.
> 
> Signed-off-by: John Garry 
> Signed-off-by: Xiang Chen 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 281 
> +
>  1 file changed, 281 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
> b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> index 9651658..49f14d2 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> @@ -173,6 +173,13 @@ enum {
>   HISI_SAS_PHY_INT_NR
>  };
>  
> +static u32 hisi_sas_read32(struct hisi_hba *hisi_hba, u32 off)
> +{
> + void __iomem *regs = hisi_hba->regs + off;
> +
> + return readl(regs);
> +}
> +
>  static void hisi_sas_write32(struct hisi_hba *hisi_hba, u32 off, u32 val)
>  {
>   void __iomem *regs = hisi_hba->regs + off;
> @@ -397,6 +404,276 @@ static void sl_notify_v3_hw(struct hisi_hba *hisi_hba, 
> int phy_no)
>   hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL, sl_control);
>  }
>  
> +static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba)
> +{
> + int i, res = 0;
> + u32 context, port_id, link_rate, hard_phy_linkrate;
> + struct hisi_sas_phy *phy = _hba->phy[phy_no];
> + struct asd_sas_phy *sas_phy = >sas_phy;
> + struct device *dev = hisi_hba->dev;
> +
> + hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_PHY_ENA_MSK, 1);
> +
> + port_id = hisi_sas_read32(hisi_hba, PHY_PORT_NUM_MA);
> + port_id = (port_id >> (4 * phy_no)) & 0xf;
> + link_rate = hisi_sas_read32(hisi_hba, PHY_CONN_RATE);
> + link_rate = (link_rate >> (phy_no * 4)) & 0xf;
> +
> + if (port_id == 0xf) {
> + dev_err(dev, "phyup: phy%d invalid portid\n", phy_no);
> + res = IRQ_NONE;
> + goto end;
> + }
> + sas_phy->linkrate = link_rate;
> + hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
> + HARD_PHY_LINKRATE);
> + phy->maximum_linkrate = hard_phy_linkrate & 0xf;
> + phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
> + phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);
> +
> + /* Check for SATA dev */
> + context = hisi_sas_read32(hisi_hba, PHY_CONTEXT);
> + if (context & (1 << phy_no)) {
> + struct hisi_sas_initial_fis *initial_fis;
> + struct dev_to_host_fis *fis;
> + u8 attached_sas_addr[SAS_ADDR_SIZE] = {0};
> +
> + dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
> + initial_fis = _hba->initial_fis[phy_no];
> + fis = _fis->fis;
> + sas_phy->oob_mode = SATA_OOB_MODE;
> + attached_sas_addr[0] = 0x50;
> + attached_sas_addr[7] = phy_no;
> + memcpy(sas_phy->attached_sas_addr,
> +attached_sas_addr,
> +SAS_ADDR_SIZE);
> + memcpy(sas_phy->frame_rcvd, fis,
> +sizeof(struct dev_to_host_fis));
> + phy->phy_type |= PORT_TYPE_SATA;
> + phy->identify.device_type = SAS_SATA_DEV;
> + phy->frame_rcvd_size = sizeof(struct dev_to_host_fis);
> + phy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
> + } else {
> + u32 *frame_rcvd = (u32 *)sas_phy->frame_rcvd;
> + struct sas_identify_frame *id =
> + (struct sas_identify_frame *)frame_rcvd;
> +
> + dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
> + for (i = 0; i < 6; i++) {
> + u32 idaf = hisi_sas_phy_read32(hisi_hba, phy_no,
> +RX_IDAF_DWORD0 + (i * 4));
> + frame_rcvd[i] = __swab32(idaf);
> + }
> + sas_phy->oob_mode = SAS_OOB_MODE;
> + memcpy(sas_phy->attached_sas_addr,
> +>sas_addr,
> +SAS_ADDR_SIZE);
> + phy->phy_type |= PORT_TYPE_SAS;
> + phy->identify.device_type = id->dev_type;
> + phy->frame_rcvd_size = sizeof(struct sas_identify_frame);
> + if (phy->identify.device_type == SAS_END_DEVICE)
> + phy->identify.target_port_protocols =
> + SAS_PROTOCOL_SSP;
> + else if (phy->identify.device_type != SAS_PHY_UNUSED)
> + phy->identify.target_port_protocols =
> + SAS_PROTOCOL_SMP;
> + }
> +
> + phy->port_id = port_id;
> + phy->phy_attached = 1;
> + queue_work(hisi_hba->wq, >phyup_ws);
> +
> +end:
> + hisi_sas_phy_write32(hisi_hba, phy_no, CHL_INT0,
> +  CHL_INT0_SL_PHY_ENABLE_MSK);
> + hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_PHY_ENA_MSK, 0);

Re: [PATCH v3 13/23] scsi: hisi_sas: add phy up/down/bcast and channel ISR

2017-05-31 Thread Christoph Hellwig
On Wed, May 31, 2017 at 10:33:05PM +0800, John Garry wrote:
> From: Xiang Chen 
> 
> Add code to initialise interrupts and add some interrupt handlers.
> 
> Signed-off-by: John Garry 
> Signed-off-by: Xiang Chen 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 281 
> +
>  1 file changed, 281 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
> b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> index 9651658..49f14d2 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
> @@ -173,6 +173,13 @@ enum {
>   HISI_SAS_PHY_INT_NR
>  };
>  
> +static u32 hisi_sas_read32(struct hisi_hba *hisi_hba, u32 off)
> +{
> + void __iomem *regs = hisi_hba->regs + off;
> +
> + return readl(regs);
> +}
> +
>  static void hisi_sas_write32(struct hisi_hba *hisi_hba, u32 off, u32 val)
>  {
>   void __iomem *regs = hisi_hba->regs + off;
> @@ -397,6 +404,276 @@ static void sl_notify_v3_hw(struct hisi_hba *hisi_hba, 
> int phy_no)
>   hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL, sl_control);
>  }
>  
> +static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba)
> +{
> + int i, res = 0;
> + u32 context, port_id, link_rate, hard_phy_linkrate;
> + struct hisi_sas_phy *phy = _hba->phy[phy_no];
> + struct asd_sas_phy *sas_phy = >sas_phy;
> + struct device *dev = hisi_hba->dev;
> +
> + hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_PHY_ENA_MSK, 1);
> +
> + port_id = hisi_sas_read32(hisi_hba, PHY_PORT_NUM_MA);
> + port_id = (port_id >> (4 * phy_no)) & 0xf;
> + link_rate = hisi_sas_read32(hisi_hba, PHY_CONN_RATE);
> + link_rate = (link_rate >> (phy_no * 4)) & 0xf;
> +
> + if (port_id == 0xf) {
> + dev_err(dev, "phyup: phy%d invalid portid\n", phy_no);
> + res = IRQ_NONE;
> + goto end;
> + }
> + sas_phy->linkrate = link_rate;
> + hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
> + HARD_PHY_LINKRATE);
> + phy->maximum_linkrate = hard_phy_linkrate & 0xf;
> + phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
> + phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);
> +
> + /* Check for SATA dev */
> + context = hisi_sas_read32(hisi_hba, PHY_CONTEXT);
> + if (context & (1 << phy_no)) {
> + struct hisi_sas_initial_fis *initial_fis;
> + struct dev_to_host_fis *fis;
> + u8 attached_sas_addr[SAS_ADDR_SIZE] = {0};
> +
> + dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
> + initial_fis = _hba->initial_fis[phy_no];
> + fis = _fis->fis;
> + sas_phy->oob_mode = SATA_OOB_MODE;
> + attached_sas_addr[0] = 0x50;
> + attached_sas_addr[7] = phy_no;
> + memcpy(sas_phy->attached_sas_addr,
> +attached_sas_addr,
> +SAS_ADDR_SIZE);
> + memcpy(sas_phy->frame_rcvd, fis,
> +sizeof(struct dev_to_host_fis));
> + phy->phy_type |= PORT_TYPE_SATA;
> + phy->identify.device_type = SAS_SATA_DEV;
> + phy->frame_rcvd_size = sizeof(struct dev_to_host_fis);
> + phy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
> + } else {
> + u32 *frame_rcvd = (u32 *)sas_phy->frame_rcvd;
> + struct sas_identify_frame *id =
> + (struct sas_identify_frame *)frame_rcvd;
> +
> + dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
> + for (i = 0; i < 6; i++) {
> + u32 idaf = hisi_sas_phy_read32(hisi_hba, phy_no,
> +RX_IDAF_DWORD0 + (i * 4));
> + frame_rcvd[i] = __swab32(idaf);
> + }
> + sas_phy->oob_mode = SAS_OOB_MODE;
> + memcpy(sas_phy->attached_sas_addr,
> +>sas_addr,
> +SAS_ADDR_SIZE);
> + phy->phy_type |= PORT_TYPE_SAS;
> + phy->identify.device_type = id->dev_type;
> + phy->frame_rcvd_size = sizeof(struct sas_identify_frame);
> + if (phy->identify.device_type == SAS_END_DEVICE)
> + phy->identify.target_port_protocols =
> + SAS_PROTOCOL_SSP;
> + else if (phy->identify.device_type != SAS_PHY_UNUSED)
> + phy->identify.target_port_protocols =
> + SAS_PROTOCOL_SMP;
> + }
> +
> + phy->port_id = port_id;
> + phy->phy_attached = 1;
> + queue_work(hisi_hba->wq, >phyup_ws);
> +
> +end:
> + hisi_sas_phy_write32(hisi_hba, phy_no, CHL_INT0,
> +  CHL_INT0_SL_PHY_ENABLE_MSK);
> + hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_PHY_ENA_MSK, 0);
> +
> + return res;
> +}
> +
> +static int phy_down_v3_hw(int phy_no, 

RE: [PATCH v2] net: fec: add post PHY reset delay DT property

2017-05-31 Thread Andy Duan
From: Florian Fainelli  Sent: Thursday, June 01, 2017 
9:53 AM
>To: Andy Duan ; Rob Herring ;
>Quentin Schulz 
>Cc: mark.rutl...@arm.com; net...@vger.kernel.org;
>devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>thomas.petazz...@free-electrons.com
>Subject: Re: [PATCH v2] net: fec: add post PHY reset delay DT property
>
>Le 05/31/17 à 18:39, Andy Duan a écrit :
>> From: Rob Herring  Sent: Thursday, June 01, 2017
>> 12:44 AM
>>> On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
 Some PHY require to wait for a bit after the reset GPIO has been
 toggled. This adds support for the DT property
 `phy-reset-post-delay` which gives the delay in milliseconds to wait after
>reset.

 If the DT property is not given, no delay is observed. Post reset
 delay greater than 1000ms are invalid.

 Signed-off-by: Quentin Schulz 
 ---

 v2:
   - return -EINVAL when phy-reset-post-delay is greater than 1000ms
   instead of defaulting to 1ms,
   - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
   binding doc and commit log,
   - move phy-reset-post-delay property reading before
   devm_gpio_request_one(),

  Documentation/devicetree/bindings/net/fsl-fec.txt |  4 
  drivers/net/ethernet/freescale/fec_main.c | 16 +++-
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
 b/Documentation/devicetree/bindings/net/fsl-fec.txt
 index a1e3693cca16..6f55bdd52f8a 100644
 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
 +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
 @@ -15,6 +15,10 @@ Optional properties:
  - phy-reset-active-high : If present then the reset sequence using the
>GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
 +- phy-reset-post-delay : Post reset delay in milliseconds. If
 +present then
>>>
>>> This needs unit suffix minimally. It should also have a vendor prefix
>>> or be made generic.
>>>
>>> But really, this is a property of the phy and should be in the phy
>>> node as should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
>>>
>> Yes, it is better to make it general.
>> Last year, Uwe Kleine-König's patch "Commit da47b4572056 ("phy: add
>support for a reset-gpio specification")" did this, but it was reverted by
>commit 948350140ef0 (Revert "phy: add support for a reset-gpio
>specification").  And in all phy device driver, only at803x.c add the gpio 
>reset in
>currently.
>
>Getting the binding correct does not prevent us from later moving this reset
>code into PHYLIB where it's appropriate. In fact; a correct and generic binding
>proposed for FEC here could be used as a basis for all other MAC and PHY
>drivers.
>--
>Florian

I agree with your opinion. Just hope to add the general phy reset interface in 
phylib and special device driver.

Andy


RE: [PATCH v2] net: fec: add post PHY reset delay DT property

2017-05-31 Thread Andy Duan
From: Florian Fainelli  Sent: Thursday, June 01, 2017 
9:53 AM
>To: Andy Duan ; Rob Herring ;
>Quentin Schulz 
>Cc: mark.rutl...@arm.com; net...@vger.kernel.org;
>devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>thomas.petazz...@free-electrons.com
>Subject: Re: [PATCH v2] net: fec: add post PHY reset delay DT property
>
>Le 05/31/17 à 18:39, Andy Duan a écrit :
>> From: Rob Herring  Sent: Thursday, June 01, 2017
>> 12:44 AM
>>> On Tue, May 23, 2017 at 11:48:08AM +0200, Quentin Schulz wrote:
 Some PHY require to wait for a bit after the reset GPIO has been
 toggled. This adds support for the DT property
 `phy-reset-post-delay` which gives the delay in milliseconds to wait after
>reset.

 If the DT property is not given, no delay is observed. Post reset
 delay greater than 1000ms are invalid.

 Signed-off-by: Quentin Schulz 
 ---

 v2:
   - return -EINVAL when phy-reset-post-delay is greater than 1000ms
   instead of defaulting to 1ms,
   - remove `default to 1ms` when phy-reset-post-delay > 1000Ms from DT
   binding doc and commit log,
   - move phy-reset-post-delay property reading before
   devm_gpio_request_one(),

  Documentation/devicetree/bindings/net/fsl-fec.txt |  4 
  drivers/net/ethernet/freescale/fec_main.c | 16 +++-
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
 b/Documentation/devicetree/bindings/net/fsl-fec.txt
 index a1e3693cca16..6f55bdd52f8a 100644
 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
 +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
 @@ -15,6 +15,10 @@ Optional properties:
  - phy-reset-active-high : If present then the reset sequence using the
>GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
 +- phy-reset-post-delay : Post reset delay in milliseconds. If
 +present then
>>>
>>> This needs unit suffix minimally. It should also have a vendor prefix
>>> or be made generic.
>>>
>>> But really, this is a property of the phy and should be in the phy
>>> node as should phy-reset-gpios, phy-reset-active-high, phy-supply, etc.
>>>
>> Yes, it is better to make it general.
>> Last year, Uwe Kleine-König's patch "Commit da47b4572056 ("phy: add
>support for a reset-gpio specification")" did this, but it was reverted by
>commit 948350140ef0 (Revert "phy: add support for a reset-gpio
>specification").  And in all phy device driver, only at803x.c add the gpio 
>reset in
>currently.
>
>Getting the binding correct does not prevent us from later moving this reset
>code into PHYLIB where it's appropriate. In fact; a correct and generic binding
>proposed for FEC here could be used as a basis for all other MAC and PHY
>drivers.
>--
>Florian

I agree with your opinion. Just hope to add the general phy reset interface in 
phylib and special device driver.

Andy


linux-next: Tree for Jun 1

2017-05-31 Thread Stephen Rothwell
Hi all,

Changes since 20170531:

The net-next tree gained a conflict against the net tree.

The mfd tree still had its build failure so I used the version from
next-20170530.

The drivers-x86 tree lost its build failure.

The target-bva tree gained a conflict against the target-updates tree.

The rtc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3539
 3755 files changed, 144612 insertions(+), 78142 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 263 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d602fb684494 Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (a4da5b17736d arc: Set IO-coherency aperture base 
to LINUX_LINK_BASE)
Merging arm-current/fixes (9861991321ec ARM: 8677/1: boot/compressed: fix 
decompressor header layout for v7-M)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (7485af89a6fd arch/sparc: increase CONFIG_NODES_SHIFT on 
SPARC64 to 5)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c2e8471d98f0 mpls: fix clearing of dead nh_flags on link up)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (468b0df61a51 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (7a7c0a6438b8 mac80211: fix TX aggregation start/stop 
callback race)
Merging sound-current/for-linus (e49a14fa36ae ALSA: usb: Avoid VLA in 
mixer_us16x08.c)
Merging pci-current/for-linus (bd2df9b1e094 PCI: Make error code types 
consistent in pci_{read,write}_config_*)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (5ed02dbb4974 Linux 4.12-rc3)
Merging usb.current/usb-linus (b3addcf0d1f0 usb: musb: dsps: keep VBUS on for 
host-only mode)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (5ed02dbb4974 Linux 4.12-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (2fef826e45c6 Input: synaptics - tell users to 
report when they should be using rmi-smbus)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 id

linux-next: Tree for Jun 1

2017-05-31 Thread Stephen Rothwell
Hi all,

Changes since 20170531:

The net-next tree gained a conflict against the net tree.

The mfd tree still had its build failure so I used the version from
next-20170530.

The drivers-x86 tree lost its build failure.

The target-bva tree gained a conflict against the target-updates tree.

The rtc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3539
 3755 files changed, 144612 insertions(+), 78142 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 263 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d602fb684494 Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (a4da5b17736d arc: Set IO-coherency aperture base 
to LINUX_LINK_BASE)
Merging arm-current/fixes (9861991321ec ARM: 8677/1: boot/compressed: fix 
decompressor header layout for v7-M)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (7485af89a6fd arch/sparc: increase CONFIG_NODES_SHIFT on 
SPARC64 to 5)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c2e8471d98f0 mpls: fix clearing of dead nh_flags on link up)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (468b0df61a51 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (7a7c0a6438b8 mac80211: fix TX aggregation start/stop 
callback race)
Merging sound-current/for-linus (e49a14fa36ae ALSA: usb: Avoid VLA in 
mixer_us16x08.c)
Merging pci-current/for-linus (bd2df9b1e094 PCI: Make error code types 
consistent in pci_{read,write}_config_*)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (5ed02dbb4974 Linux 4.12-rc3)
Merging usb.current/usb-linus (b3addcf0d1f0 usb: musb: dsps: keep VBUS on for 
host-only mode)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (5ed02dbb4974 Linux 4.12-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (2fef826e45c6 Input: synaptics - tell users to 
report when they should be using rmi-smbus)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 id

[LINUX-KERNEL] Kernel hung for more than 120 seconds due to tee process

2017-05-31 Thread Rajesh Natarajan
Hi,

In debian wheezy system while writing logs to SSD using tee command , we are 
experiencing kernel hung problem.

Can anyone help in avoiding this problem ?

I haven't subscribed to kernel mailing list,so re-ponders please CC me in the 
reply.

Kernel trace :

kernel: [  960.964830] INFO: task tee:11324 blocked for more than 120 seconds.
kernel: [  960.966422]   Tainted: G   O  3.16.0-4-586 #1
kernel: [  960.967996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
kernel: [  960.969607] tee D 8803e29a5788 0 11324  1 
0x
kernel: [  960.969614]  818184a0 0086 00012ec0 
8803e29a5330
kernel: [  960.969628]  00012ec0 8803e2cdbfd8 00012ec0 
8803e29a5330
kernel: [  960.969632]  88040aef2800 88040b317828 fffe0002 
8803e29a5330
kernel: [  960.969640] Call Trace:
kernel: [  960.969654]  [] ? schedule_timeout+0x20a/0x270
kernel: [  960.969659]  [] ? pipe_read+0x23e/0x2f0
kernel: [  960.969665]  [] ? ldsem_down_read+0x119/0x210
kernel: [  960.969671]  [] ? tty_ldisc_ref_wait+0x1c/0x40
kernel: [  960.969674]  [] ? tty_write+0x7c/0x2b0
kernel: [  960.969678]  [] ? 
security_file_permission+0x2f/0xd0
kernel: [  960.969681]  [] ? redirected_tty_write+0x3a/0xd0
kernel: [  960.969685]  [] ? vfs_write+0xbf/0x200
kernel: [  960.969688]  [] ? SyS_write+0x50/0xb0
kernel: [  960.969693]  [] ? system_call_fastpath+0x1a/0x1f

SystemInfo

uname -a
Linux ACPU2 3.16.0-4-586 #1 SMP Tue Oct 13 13:56:57 CDT 2015 x86_64 GNU/Linux

free -m
 total   used   free sharedbuffers cached
Mem: 15866   7233   8633  0 73   3103
-/+ buffers/cache:   4056  11809
Swap:32772  0  32772

lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list:   0-7
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 1
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 58
Stepping:  9
CPU MHz:   1203.644
BogoMIPS:  4200.03
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  6144K
NUMA node0 CPU(s): 0-7

Thanks,
Rajesh Natarajan.


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."


[LINUX-KERNEL] Kernel hung for more than 120 seconds due to tee process

2017-05-31 Thread Rajesh Natarajan
Hi,

In debian wheezy system while writing logs to SSD using tee command , we are 
experiencing kernel hung problem.

Can anyone help in avoiding this problem ?

I haven't subscribed to kernel mailing list,so re-ponders please CC me in the 
reply.

Kernel trace :

kernel: [  960.964830] INFO: task tee:11324 blocked for more than 120 seconds.
kernel: [  960.966422]   Tainted: G   O  3.16.0-4-586 #1
kernel: [  960.967996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
kernel: [  960.969607] tee D 8803e29a5788 0 11324  1 
0x
kernel: [  960.969614]  818184a0 0086 00012ec0 
8803e29a5330
kernel: [  960.969628]  00012ec0 8803e2cdbfd8 00012ec0 
8803e29a5330
kernel: [  960.969632]  88040aef2800 88040b317828 fffe0002 
8803e29a5330
kernel: [  960.969640] Call Trace:
kernel: [  960.969654]  [] ? schedule_timeout+0x20a/0x270
kernel: [  960.969659]  [] ? pipe_read+0x23e/0x2f0
kernel: [  960.969665]  [] ? ldsem_down_read+0x119/0x210
kernel: [  960.969671]  [] ? tty_ldisc_ref_wait+0x1c/0x40
kernel: [  960.969674]  [] ? tty_write+0x7c/0x2b0
kernel: [  960.969678]  [] ? 
security_file_permission+0x2f/0xd0
kernel: [  960.969681]  [] ? redirected_tty_write+0x3a/0xd0
kernel: [  960.969685]  [] ? vfs_write+0xbf/0x200
kernel: [  960.969688]  [] ? SyS_write+0x50/0xb0
kernel: [  960.969693]  [] ? system_call_fastpath+0x1a/0x1f

SystemInfo

uname -a
Linux ACPU2 3.16.0-4-586 #1 SMP Tue Oct 13 13:56:57 CDT 2015 x86_64 GNU/Linux

free -m
 total   used   free sharedbuffers cached
Mem: 15866   7233   8633  0 73   3103
-/+ buffers/cache:   4056  11809
Swap:32772  0  32772

lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list:   0-7
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 1
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 58
Stepping:  9
CPU MHz:   1203.644
BogoMIPS:  4200.03
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  6144K
NUMA node0 CPU(s): 0-7

Thanks,
Rajesh Natarajan.


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."


Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

2017-05-31 Thread m . t

> m...@ox.io hat am 11. Mai 2017 um 07:38 geschrieben:
> 
> 
> 
> > Sinclair Yeh hat am 10. Mai 2017 um 18:46 geschrieben:
> > 
> > 
> > Hi,
> 
> Hi,
>  
> > On Wed, May 10, 2017 at 12:31:39PM +0200, m.t wrote:
> > > 
> > > > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben:
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for reporting.
> > > 
> > > I would have reported earlier if it had not taken 3 days on the vm to 
> > > bisect.
> > > 
> > > > I think there is a fix for this either in preparation or queued for
> > > > submission. Sinclair (CC'd) should know more.
> > > 
> > > If you point me to a patch I can test it.
> > 
> > please give this patch a try:
> > 
> > https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=324722b1e1582d45e865dcd2233a17edcfbd1638
> 
> Works fine. Thanks

Is there a chance that it makes it into 4.12?

> > If it doesn't work, then please send me the following:
> > 1. dmesg from the guest
> > 2. vmware.log from the host
> > 3. .vmx file for your VM
> > 
> > thanks,
> > 
> > Sinclair
> 
> you're welcome
> 
> Mark
>  
> > > 
> > > > Thanks,
> > > > Thomas
> > > 
> > > Mark
> > > 
> > > > 
> > > > On 05/10/2017 09:17 AM, m.t wrote:
> > > > > Hi,
> > > > > I don't have a mouse cursor in my virtual machine (vmware workstation 
> > > > > 12.5.5 
> > > > > build-5234757) with latest master from 
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_=DwICAg=uilaK90D4TOVoH58JNXRgQ=j2ey7nuAQ5d6NbMmCOnRsTIJfmv7blo3UCKagbsM9o2-No8JdlhkKK3ty481ErVu=DWnNRbcrxMhc78PIvembLdV3OsJi3vPwcdG03kqVpJo=mc7-KF2t4BktXs11MShGZBf9bzgxumqhmVQ0ocAIS0k=
> > > > >  
> > > > > kernel/git/torvalds/linux.git
> > > > >
> > > > > git bisect led me to 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b as 
> > > > > culprit.
> > > > >
> > > > > Regards 
> > > > > Mark
> > > > > ___
> > > > > Sent to linux-graphics-maintai...@vmware.com
> > > > 
> > > >


Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

2017-05-31 Thread m . t

> m...@ox.io hat am 11. Mai 2017 um 07:38 geschrieben:
> 
> 
> 
> > Sinclair Yeh hat am 10. Mai 2017 um 18:46 geschrieben:
> > 
> > 
> > Hi,
> 
> Hi,
>  
> > On Wed, May 10, 2017 at 12:31:39PM +0200, m.t wrote:
> > > 
> > > > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben:
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for reporting.
> > > 
> > > I would have reported earlier if it had not taken 3 days on the vm to 
> > > bisect.
> > > 
> > > > I think there is a fix for this either in preparation or queued for
> > > > submission. Sinclair (CC'd) should know more.
> > > 
> > > If you point me to a patch I can test it.
> > 
> > please give this patch a try:
> > 
> > https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=324722b1e1582d45e865dcd2233a17edcfbd1638
> 
> Works fine. Thanks

Is there a chance that it makes it into 4.12?

> > If it doesn't work, then please send me the following:
> > 1. dmesg from the guest
> > 2. vmware.log from the host
> > 3. .vmx file for your VM
> > 
> > thanks,
> > 
> > Sinclair
> 
> you're welcome
> 
> Mark
>  
> > > 
> > > > Thanks,
> > > > Thomas
> > > 
> > > Mark
> > > 
> > > > 
> > > > On 05/10/2017 09:17 AM, m.t wrote:
> > > > > Hi,
> > > > > I don't have a mouse cursor in my virtual machine (vmware workstation 
> > > > > 12.5.5 
> > > > > build-5234757) with latest master from 
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_=DwICAg=uilaK90D4TOVoH58JNXRgQ=j2ey7nuAQ5d6NbMmCOnRsTIJfmv7blo3UCKagbsM9o2-No8JdlhkKK3ty481ErVu=DWnNRbcrxMhc78PIvembLdV3OsJi3vPwcdG03kqVpJo=mc7-KF2t4BktXs11MShGZBf9bzgxumqhmVQ0ocAIS0k=
> > > > >  
> > > > > kernel/git/torvalds/linux.git
> > > > >
> > > > > git bisect led me to 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b as 
> > > > > culprit.
> > > > >
> > > > > Regards 
> > > > > Mark
> > > > > ___
> > > > > Sent to linux-graphics-maintai...@vmware.com
> > > > 
> > > >


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Wed, 31 May 2017 19:07:15 -0500
Larry Finger  wrote:

> On 05/31/2017 10:32 AM, Michael Büsch wrote:
> > On Wed, 31 May 2017 13:26:43 +0300
> > Kalle Valo  wrote:
> >   
> >> Jia-Ju Bai  writes:
> >>  
> >>> The driver may sleep under a spin lock, and the function call path is:
> >>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
> >>>b43legacy_synchronize_irq
> >>>  synchronize_irq --> may sleep
> >>>
> >>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
> >>> lock is acquired again after this function.
> >>>
> >>> Signed-off-by: Jia-Ju Bai 
> >>> ---
> >>>   drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
> >>> b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> index f1e3dad..31ead21 100644
> >>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >>> ieee80211_hw *hw,
> >>>   b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >>>   
> >>>   if (changed & BSS_CHANGED_BSSID) {
> >>> + spin_unlock_irqrestore(>irq_lock, flags);
> >>>   b43legacy_synchronize_irq(dev);
> >>> + spin_lock_irqsave(>irq_lock, flags);  
> >>
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>  
> > 
> > 
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.
> > We disabled the device interrupts just before this line.
> > 
> > However I think the synchronize_irq should be outside of the
> > conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> > two lines above)
> > I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> > is set.
> > 
> > 
> > On the other hand b43 does not have this irq-disabling foobar anymore.
> > So somebody must have removed it. Maybe you can find the commit that
> > removed this stuff from b43 and port it to b43legacy?
> > 
> > 
> > So I would vote for moving the synchronize_irq up outside of the
> > conditional and put the unlock/lock sequence around it.
> > And as a second patch on top of that try to remove this stuff
> > altogether like b43 did.  
> 
> The patch that removed it in b43 is
> 
> commit 36dbd9548e92268127b0c31b0e121e63e9207108
> Author: Michael Buesch 
> Date:   Fri Sep 4 22:51:29 2009 +0200

Damn it :D

>  b43: Use a threaded IRQ handler
> 
>  Use a threaded IRQ handler to allow locking the mutex and
>  sleeping while executing an interrupt.
>  This removes usage of the irq_lock spinlock, but introduces
>  a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
>  hard-irq handler. Sleeping busses (SDIO) will use mutex instead.
> 
>  Signed-off-by: Michael Buesch 
>  Tested-by: Larry Finger 
>  Signed-off-by: John W. Linville 
> 
> I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
> try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I 
> can 
> test in a PowerBook G4.
> 
> I agree with Michael that this is the way to go. Both of Jia-Ju's patches 
> should 
> be rejected.


I'm not sure if it's worth it. There is a risk that this would
introduce new bugs.
But sure, please feel free to try it. This way we can find out how big
this change becomes.

-- 
Michael


pgpGuuJkoasqH.pgp
Description: OpenPGP digital signature


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Wed, 31 May 2017 19:07:15 -0500
Larry Finger  wrote:

> On 05/31/2017 10:32 AM, Michael Büsch wrote:
> > On Wed, 31 May 2017 13:26:43 +0300
> > Kalle Valo  wrote:
> >   
> >> Jia-Ju Bai  writes:
> >>  
> >>> The driver may sleep under a spin lock, and the function call path is:
> >>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
> >>>b43legacy_synchronize_irq
> >>>  synchronize_irq --> may sleep
> >>>
> >>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
> >>> lock is acquired again after this function.
> >>>
> >>> Signed-off-by: Jia-Ju Bai 
> >>> ---
> >>>   drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
> >>> b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> index f1e3dad..31ead21 100644
> >>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >>> ieee80211_hw *hw,
> >>>   b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >>>   
> >>>   if (changed & BSS_CHANGED_BSSID) {
> >>> + spin_unlock_irqrestore(>irq_lock, flags);
> >>>   b43legacy_synchronize_irq(dev);
> >>> + spin_lock_irqsave(>irq_lock, flags);  
> >>
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>  
> > 
> > 
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.
> > We disabled the device interrupts just before this line.
> > 
> > However I think the synchronize_irq should be outside of the
> > conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> > two lines above)
> > I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> > is set.
> > 
> > 
> > On the other hand b43 does not have this irq-disabling foobar anymore.
> > So somebody must have removed it. Maybe you can find the commit that
> > removed this stuff from b43 and port it to b43legacy?
> > 
> > 
> > So I would vote for moving the synchronize_irq up outside of the
> > conditional and put the unlock/lock sequence around it.
> > And as a second patch on top of that try to remove this stuff
> > altogether like b43 did.  
> 
> The patch that removed it in b43 is
> 
> commit 36dbd9548e92268127b0c31b0e121e63e9207108
> Author: Michael Buesch 
> Date:   Fri Sep 4 22:51:29 2009 +0200

Damn it :D

>  b43: Use a threaded IRQ handler
> 
>  Use a threaded IRQ handler to allow locking the mutex and
>  sleeping while executing an interrupt.
>  This removes usage of the irq_lock spinlock, but introduces
>  a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
>  hard-irq handler. Sleeping busses (SDIO) will use mutex instead.
> 
>  Signed-off-by: Michael Buesch 
>  Tested-by: Larry Finger 
>  Signed-off-by: John W. Linville 
> 
> I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
> try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I 
> can 
> test in a PowerBook G4.
> 
> I agree with Michael that this is the way to go. Both of Jia-Ju's patches 
> should 
> be rejected.


I'm not sure if it's worth it. There is a risk that this would
introduce new bugs.
But sure, please feel free to try it. This way we can find out how big
this change becomes.

-- 
Michael


pgpGuuJkoasqH.pgp
Description: OpenPGP digital signature


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Thu, 01 Jun 2017 07:27:20 +0300
Kalle Valo  wrote:

> Michael Büsch  writes:
> 
> >> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >> > ieee80211_hw *hw,
> >> >  b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >> >  
> >> >  if (changed & BSS_CHANGED_BSSID) {
> >> > +spin_unlock_irqrestore(>irq_lock, flags);
> >> >  b43legacy_synchronize_irq(dev);
> >> > +spin_lock_irqsave(>irq_lock, flags);
> >> 
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>   
> >
> >
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.  
> 
> Sure, but IMHO in general I think the practise of releasing the lock
> like this in a middle of function is dangerous as one can easily miss
> that upper and lower halves of the function are not actually atomic
> anymore. And in this case that it's under a conditional makes it even
> worse.
> 


Yes in general I agree. Releasing and re-acquiring a lock is dangerous.
But I think in this special case here it might be harmless.
The irq_lock is used mostly (if not exclusively; I don't fully
remember) to protect against the IRQ top and bottom half.
But we disabled the device IRQs a line above and the purpose of this
synchronize is to make sure the handler will finish and thus make
dropping the lock save.
Of course it does not make sense to do this with the lock held :)

-- 
Michael


pgpzxV10ouNjW.pgp
Description: OpenPGP digital signature


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Michael Büsch
On Thu, 01 Jun 2017 07:27:20 +0300
Kalle Valo  wrote:

> Michael Büsch  writes:
> 
> >> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> >> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
> >> > ieee80211_hw *hw,
> >> >  b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
> >> >  
> >> >  if (changed & BSS_CHANGED_BSSID) {
> >> > +spin_unlock_irqrestore(>irq_lock, flags);
> >> >  b43legacy_synchronize_irq(dev);
> >> > +spin_lock_irqsave(>irq_lock, flags);
> >> 
> >> To me this looks like a fragile workaround and not a real fix. You can
> >> easily add new race conditions with releasing the lock like this.
> >>   
> >
> >
> > I think releasing the lock possibly is fine. It certainly is better than
> > sleeping with a lock held.  
> 
> Sure, but IMHO in general I think the practise of releasing the lock
> like this in a middle of function is dangerous as one can easily miss
> that upper and lower halves of the function are not actually atomic
> anymore. And in this case that it's under a conditional makes it even
> worse.
> 


Yes in general I agree. Releasing and re-acquiring a lock is dangerous.
But I think in this special case here it might be harmless.
The irq_lock is used mostly (if not exclusively; I don't fully
remember) to protect against the IRQ top and bottom half.
But we disabled the device IRQs a line above and the purpose of this
synchronize is to make sure the handler will finish and thus make
dropping the lock save.
Of course it does not make sense to do this with the lock held :)

-- 
Michael


pgpzxV10ouNjW.pgp
Description: OpenPGP digital signature


[PATCH 2/2] PCI: iproc: add device shutdown for PCI RC

2017-05-31 Thread Oza Pawandeep
PERST# must be asserted around ~500ms before
the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iProc based SoCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This happens because; Endpoint is expecting the clock for some amount of
time after PERST is asserted, which is not happening in our case
(Compare to Intel X86 boards, will have clocks running).
this cause NVMe to behave in undefined way.

Essentially clock will remain alive for 500ms with PERST# = 0
before reboot.

This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.

So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown is called, which issues safe PERST
assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 05a3647..e9afc63 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -608,31 +608,38 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
@@ -1310,7 +1317,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 0bbe2ea..a6b55ce 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -110,6 +110,7 @@ struct iproc_pcie {
 
 int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
 int iproc_pcie_remove(struct iproc_pcie *pcie);
+int iproc_pcie_shutdown(struct iproc_pcie *pcie);
 
 #ifdef CONFIG_PCIE_IPROC_MSI
 int 

[PATCH 2/2] PCI: iproc: add device shutdown for PCI RC

2017-05-31 Thread Oza Pawandeep
PERST# must be asserted around ~500ms before
the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iProc based SoCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This happens because; Endpoint is expecting the clock for some amount of
time after PERST is asserted, which is not happening in our case
(Compare to Intel X86 boards, will have clocks running).
this cause NVMe to behave in undefined way.

Essentially clock will remain alive for 500ms with PERST# = 0
before reboot.

This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.

So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown is called, which issues safe PERST
assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 05a3647..e9afc63 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -608,31 +608,38 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
@@ -1310,7 +1317,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 0bbe2ea..a6b55ce 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -110,6 +110,7 @@ struct iproc_pcie {
 
 int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
 int iproc_pcie_remove(struct iproc_pcie *pcie);
+int iproc_pcie_shutdown(struct iproc_pcie *pcie);
 
 #ifdef CONFIG_PCIE_IPROC_MSI
 int iproc_msi_init(struct iproc_pcie *pcie, struct device_node *node);
-- 
1.9.1



[PATCH 1/2] PCI: iproc: Retry request when CRS returned from EP

2017-05-31 Thread Oza Pawandeep
For Configuration Requests only, following reset
it is possible for a device to terminate the request
but indicate that it is temporarily unable to process
the Request, but will be able to process the Request
in the future – in this case, the Configuration Request
Retry Status 10 (CRS) Completion Status is used

SPDK user space NVMe driver reinitializes NVMe which
causes reset, while doing this some configuration requests
get NAKed by Endpoint (NVMe).
Current iproc PCI driver is agnostic about it.
PAXB will forward the NAKed response in stipulated AXI code.

NVMe spec defines this timeout in 500 ms units, and this
only happens if controller has been in reset, or with new firmware,
or in abrupt shutdown case.
Meanwhile config access could result into retry.

This patch fixes the problem, and attempts to read again in case
of PAXB forwarding the NAK.

It implements iproc_pcie_config_read which gets called for Stingray.
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..05a3647 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,47 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +543,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == IPROC_PCIE_PAXB_V2)
+   ret = iproc_pcie_config_read(bus, devfn, where, size, val);
+   else
+   ret = pci_generic_config_read32(bus, devfn, where, size, val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
-- 
1.9.1



[PATCH 1/2] PCI: iproc: Retry request when CRS returned from EP

2017-05-31 Thread Oza Pawandeep
For Configuration Requests only, following reset
it is possible for a device to terminate the request
but indicate that it is temporarily unable to process
the Request, but will be able to process the Request
in the future – in this case, the Configuration Request
Retry Status 10 (CRS) Completion Status is used

SPDK user space NVMe driver reinitializes NVMe which
causes reset, while doing this some configuration requests
get NAKed by Endpoint (NVMe).
Current iproc PCI driver is agnostic about it.
PAXB will forward the NAKed response in stipulated AXI code.

NVMe spec defines this timeout in 500 ms units, and this
only happens if controller has been in reset, or with new firmware,
or in abrupt shutdown case.
Meanwhile config access could result into retry.

This patch fixes the problem, and attempts to read again in case
of PAXB forwarding the NAK.

It implements iproc_pcie_config_read which gets called for Stingray.
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..05a3647 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,47 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +543,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == IPROC_PCIE_PAXB_V2)
+   ret = iproc_pcie_config_read(bus, devfn, where, size, val);
+   else
+   ret = pci_generic_config_read32(bus, devfn, where, size, val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
-- 
1.9.1



[PATCH 0/2] PCI: iproc: SOC specific fixes.

2017-05-31 Thread Oza Pawandeep
PCI: iproc: Retry request when CRS returned from EP

Above patch adds support for CRS in PCI RC driver,
otherwise if not handled at lower level, the user
space PMD (poll mode drivers) can timeout.

PCI: iproc: add device shutdown for PCI RC

This fixes the issue where certian PCI endpoints are
not getting detected on Stingray SOC after reboot.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 +++
 drivers/pci/host/pcie-iproc.c  | 125 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 115 insertions(+), 19 deletions(-)

-- 
1.9.1



[PATCH 0/2] PCI: iproc: SOC specific fixes.

2017-05-31 Thread Oza Pawandeep
PCI: iproc: Retry request when CRS returned from EP

Above patch adds support for CRS in PCI RC driver,
otherwise if not handled at lower level, the user
space PMD (poll mode drivers) can timeout.

PCI: iproc: add device shutdown for PCI RC

This fixes the issue where certian PCI endpoints are
not getting detected on Stingray SOC after reboot.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 +++
 drivers/pci/host/pcie-iproc.c  | 125 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 115 insertions(+), 19 deletions(-)

-- 
1.9.1



Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 05:05 +, Bart Van Assche wrote:
> On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> > but a weeks worth of list silence for your series doesn't mean
> > you're free to push un-reviewed stuff for drivers/target/ into
> > linux-next.
> 
> I think this is an example of the pot calling the kettle black.
> Your patch "target: Re-add check to reject control WRITEs with
> overflow data" has not been reviewed by anyone but was pushed
> into linux-next and sent to Linus anyway.

Heh, it fixed a regression you yourself pointed out.  :)

If your going to report a bug and not review the patch to address the
regression, I'm not going to let that regression slide to restore
existing behavior, just because you didn't bother to review the patch in
three plus weeks for the bug you reported.

Anyways, I'll get to your patches, but please get reviews on the list by
sending series that people want to review, instead of large unwieldy
series that intermix new features and random bug-fixes without any
context.

No wonder why people don't send time reviewing them!



Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 05:05 +, Bart Van Assche wrote:
> On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> > but a weeks worth of list silence for your series doesn't mean
> > you're free to push un-reviewed stuff for drivers/target/ into
> > linux-next.
> 
> I think this is an example of the pot calling the kettle black.
> Your patch "target: Re-add check to reject control WRITEs with
> overflow data" has not been reviewed by anyone but was pushed
> into linux-next and sent to Linus anyway.

Heh, it fixed a regression you yourself pointed out.  :)

If your going to report a bug and not review the patch to address the
regression, I'm not going to let that regression slide to restore
existing behavior, just because you didn't bother to review the patch in
three plus weeks for the bug you reported.

Anyways, I'll get to your patches, but please get reviews on the list by
sending series that people want to review, instead of large unwieldy
series that intermix new features and random bug-fixes without any
context.

No wonder why people don't send time reviewing them!



Re: [PATCH] rxe: Fix a sleep-in-atomic bug in post_one_send

2017-05-31 Thread Leon Romanovsky
On Thu, Jun 01, 2017 at 09:48:34AM +0800, Jia-Ju Bai wrote:
> The driver may sleep under a spin lock, and the function call path is:
> post_one_send (acquire the lock by spin_lock_irqsave)
>   init_send_wqe
> copy_from_user --> may sleep
>
> To fix it, the lock is released before copy_from_user, and the lock is
> acquired again after this function.
>
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 83d709e..6fb7e1a 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -725,7 +725,7 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>  {
>   int num_sge = ibwr->num_sge;
>   struct ib_sge *sge;
> - int i;
> + int i, err;
>   u8 *p;
>
>   init_send_wr(qp, >wr, ibwr);
> @@ -740,8 +740,11 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>
>   sge = ibwr->sg_list;
>   for (i = 0; i < num_sge; i++, sge++) {
> - if (qp->is_user && copy_from_user(p, (__user void *)
> - (uintptr_t)sge->addr, sge->length))
> + spin_unlock_irq(>sq.sq_lock);

In original spin_lock, the flags of irq were saved, hence it should be
restored here too, but it is unclear to me if spin_lock is needed here
and it can't be converted to mutex_lock.

> + err = copy_from_user(p, (__user void *)
> + (uintptr_t)sge->addr, sge->length);
> + spin_lock_irq(>sq.sq_lock);
> + if (qp->is_user && err)
>   return -EFAULT;
>
>   else if (!qp->is_user)
> --
> 1.7.9.5
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature


Re: [PATCH] rxe: Fix a sleep-in-atomic bug in post_one_send

2017-05-31 Thread Leon Romanovsky
On Thu, Jun 01, 2017 at 09:48:34AM +0800, Jia-Ju Bai wrote:
> The driver may sleep under a spin lock, and the function call path is:
> post_one_send (acquire the lock by spin_lock_irqsave)
>   init_send_wqe
> copy_from_user --> may sleep
>
> To fix it, the lock is released before copy_from_user, and the lock is
> acquired again after this function.
>
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/infiniband/sw/rxe/rxe_verbs.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
> b/drivers/infiniband/sw/rxe/rxe_verbs.c
> index 83d709e..6fb7e1a 100644
> --- a/drivers/infiniband/sw/rxe/rxe_verbs.c
> +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
> @@ -725,7 +725,7 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>  {
>   int num_sge = ibwr->num_sge;
>   struct ib_sge *sge;
> - int i;
> + int i, err;
>   u8 *p;
>
>   init_send_wr(qp, >wr, ibwr);
> @@ -740,8 +740,11 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
> ib_send_wr *ibwr,
>
>   sge = ibwr->sg_list;
>   for (i = 0; i < num_sge; i++, sge++) {
> - if (qp->is_user && copy_from_user(p, (__user void *)
> - (uintptr_t)sge->addr, sge->length))
> + spin_unlock_irq(>sq.sq_lock);

In original spin_lock, the flags of irq were saved, hence it should be
restored here too, but it is unclear to me if spin_lock is needed here
and it can't be converted to mutex_lock.

> + err = copy_from_user(p, (__user void *)
> + (uintptr_t)sge->addr, sge->length);
> + spin_lock_irq(>sq.sq_lock);
> + if (qp->is_user && err)
>   return -EFAULT;
>
>   else if (!qp->is_user)
> --
> 1.7.9.5
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] dt-bindings: timeriomem_rng: Add entropy quality property

2017-05-31 Thread Herbert Xu
On Mon, May 22, 2017 at 02:12:23PM -0700, Rick Altherr wrote:
> Signed-off-by: Rick Altherr 

Both patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Bart Van Assche
On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> but a weeks worth of list silence for your series doesn't mean
> you're free to push un-reviewed stuff for drivers/target/ into
> linux-next.

I think this is an example of the pot calling the kettle black.
Your patch "target: Re-add check to reject control WRITEs with
overflow data" has not been reviewed by anyone but was pushed
into linux-next and sent to Linus anyway.

Bart.

Re: [PATCH v2 1/2] dt-bindings: timeriomem_rng: Add entropy quality property

2017-05-31 Thread Herbert Xu
On Mon, May 22, 2017 at 02:12:23PM -0700, Rick Altherr wrote:
> Signed-off-by: Rick Altherr 

Both patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Bart Van Assche
On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> but a weeks worth of list silence for your series doesn't mean
> you're free to push un-reviewed stuff for drivers/target/ into
> linux-next.

I think this is an example of the pot calling the kettle black.
Your patch "target: Re-add check to reject control WRITEs with
overflow data" has not been reviewed by anyone but was pushed
into linux-next and sent to Linus anyway.

Bart.

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 04:59 +, Bart Van Assche wrote:
> On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> > Hi Bart,
> > 
> > Today's linux-next merge of the target-bva tree got a conflict in:
> > 
> >   drivers/target/target_core_transport.c
> > 
> > between commit:
> > 
> >   4ff83daa0200 ("target: Re-add check to reject control WRITEs with 
> > overflow data")
> > 
> > from the target-updates tree and commit:
> > 
> >   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> > Data-Out buffer")
> > 
> > from the target-bva tree.
> > 
> > I fixed it up (I think (guidance appreciated), see below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging.  You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> 
> Hello Stephen,
> 
> Thanks for having fixed this up. I hadn't noticed that Nic had queued up 
> patches
> that conflict with my patches. I will rebase my tree.
> 

Go ahead and get list review on drivers/target/ changes before pushing
them into linux-next, please.

Btw, I don't care if you queue up one's that do have at least two
Reviewed-bys into your tree, but everything that doesn't have
Reviewed-bys or Acked-by should not be going into linux-next.



Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 04:59 +, Bart Van Assche wrote:
> On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> > Hi Bart,
> > 
> > Today's linux-next merge of the target-bva tree got a conflict in:
> > 
> >   drivers/target/target_core_transport.c
> > 
> > between commit:
> > 
> >   4ff83daa0200 ("target: Re-add check to reject control WRITEs with 
> > overflow data")
> > 
> > from the target-updates tree and commit:
> > 
> >   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> > Data-Out buffer")
> > 
> > from the target-bva tree.
> > 
> > I fixed it up (I think (guidance appreciated), see below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging.  You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> 
> Hello Stephen,
> 
> Thanks for having fixed this up. I hadn't noticed that Nic had queued up 
> patches
> that conflict with my patches. I will rebase my tree.
> 

Go ahead and get list review on drivers/target/ changes before pushing
them into linux-next, please.

Btw, I don't care if you queue up one's that do have at least two
Reviewed-bys into your tree, but everything that doesn't have
Reviewed-bys or Acked-by should not be going into linux-next.



Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Bart Van Assche
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
> 
> Today's linux-next merge of the target-bva tree got a conflict in:
> 
>   drivers/target/target_core_transport.c
> 
> between commit:
> 
>   4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
> data")
> 
> from the target-updates tree and commit:
> 
>   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> Data-Out buffer")
> 
> from the target-bva tree.
> 
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Hello Stephen,

Thanks for having fixed this up. I hadn't noticed that Nic had queued up patches
that conflict with my patches. I will rebase my tree.

Bart.

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Bart Van Assche
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
> 
> Today's linux-next merge of the target-bva tree got a conflict in:
> 
>   drivers/target/target_core_transport.c
> 
> between commit:
> 
>   4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
> data")
> 
> from the target-updates tree and commit:
> 
>   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> Data-Out buffer")
> 
> from the target-bva tree.
> 
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Hello Stephen,

Thanks for having fixed this up. I hadn't noticed that Nic had queued up patches
that conflict with my patches. I will rebase my tree.

Bart.

[PATCH] ARM: dts: rk1108: change to "max-frequency" from "clock-freq-min-max"

2017-05-31 Thread Jaehoon Chung
"clock-freq-min-max" was deprecated. There is only using in rk1108.dtsi.
Use the "max-frequency" for removiing "clock-freq-min-max" in future.

Signed-off-by: Jaehoon Chung 
---
 arch/arm/boot/dts/rk1108.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
index 1297924..a9b5293 100644
--- a/arch/arm/boot/dts/rk1108.dtsi
+++ b/arch/arm/boot/dts/rk1108.dtsi
@@ -174,7 +174,7 @@
 
emmc: dwmmc@3011 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 15000>;
+   max-frequency = <15000>;
clocks = < HCLK_EMMC>, < SCLK_EMMC>,
 < SCLK_EMMC_DRV>, < SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -186,7 +186,7 @@
 
sdio: dwmmc@3012 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 15000>;
+   max-frequency = <15000>;
clocks = < HCLK_SDIO>, < SCLK_SDIO>,
 < SCLK_SDIO_DRV>, < SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -198,7 +198,7 @@
 
sdmmc: dwmmc@3013 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 1>;
+   max-frequency = <1>;
clocks = < HCLK_SDMMC>, < SCLK_SDMMC>,
 < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
-- 
2.10.2



[PATCH] ARM: dts: rk1108: change to "max-frequency" from "clock-freq-min-max"

2017-05-31 Thread Jaehoon Chung
"clock-freq-min-max" was deprecated. There is only using in rk1108.dtsi.
Use the "max-frequency" for removiing "clock-freq-min-max" in future.

Signed-off-by: Jaehoon Chung 
---
 arch/arm/boot/dts/rk1108.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
index 1297924..a9b5293 100644
--- a/arch/arm/boot/dts/rk1108.dtsi
+++ b/arch/arm/boot/dts/rk1108.dtsi
@@ -174,7 +174,7 @@
 
emmc: dwmmc@3011 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 15000>;
+   max-frequency = <15000>;
clocks = < HCLK_EMMC>, < SCLK_EMMC>,
 < SCLK_EMMC_DRV>, < SCLK_EMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -186,7 +186,7 @@
 
sdio: dwmmc@3012 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 15000>;
+   max-frequency = <15000>;
clocks = < HCLK_SDIO>, < SCLK_SDIO>,
 < SCLK_SDIO_DRV>, < SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
@@ -198,7 +198,7 @@
 
sdmmc: dwmmc@3013 {
compatible = "rockchip,rk1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
-   clock-freq-min-max = <40 1>;
+   max-frequency = <1>;
clocks = < HCLK_SDMMC>, < SCLK_SDMMC>,
 < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
-- 
2.10.2



Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Kalle Valo
Michael Büsch  writes:

>> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
>> > ieee80211_hw *hw,
>> >b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>> >  
>> >if (changed & BSS_CHANGED_BSSID) {
>> > +  spin_unlock_irqrestore(>irq_lock, flags);
>> >b43legacy_synchronize_irq(dev);
>> > +  spin_lock_irqsave(>irq_lock, flags);  
>> 
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>> 
>
>
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.

Sure, but IMHO in general I think the practise of releasing the lock
like this in a middle of function is dangerous as one can easily miss
that upper and lower halves of the function are not actually atomic
anymore. And in this case that it's under a conditional makes it even
worse.

-- 
Kalle Valo


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

2017-05-31 Thread Kalle Valo
Michael Büsch  writes:

>> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>> > @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
>> > ieee80211_hw *hw,
>> >b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>> >  
>> >if (changed & BSS_CHANGED_BSSID) {
>> > +  spin_unlock_irqrestore(>irq_lock, flags);
>> >b43legacy_synchronize_irq(dev);
>> > +  spin_lock_irqsave(>irq_lock, flags);  
>> 
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>> 
>
>
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.

Sure, but IMHO in general I think the practise of releasing the lock
like this in a middle of function is dangerous as one can easily miss
that upper and lower halves of the function are not actually atomic
anymore. And in this case that it's under a conditional makes it even
worse.

-- 
Kalle Valo


Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
> 
> Today's linux-next merge of the target-bva tree got a conflict in:
> 
>   drivers/target/target_core_transport.c
> 
> between commit:
> 
>   4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
> data")
> 
> from the target-updates tree and commit:
> 
>   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> Data-Out buffer")
> 
> from the target-bva tree.
> 
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 

Hi Bart,

The majority of this series hasn't been list reviewed, and shouldn't be
getting pushed in linux-next without some form of reviews.

I'll be getting back to v4.13 items now v4.12-rc fixes is out of the
way, but a weeks worth of list silence for your series doesn't mean
you're free to push un-reviewed stuff for drivers/target/ into
linux-next.



Re: linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Nicholas A. Bellinger
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
> 
> Today's linux-next merge of the target-bva tree got a conflict in:
> 
>   drivers/target/target_core_transport.c
> 
> between commit:
> 
>   4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
> data")
> 
> from the target-updates tree and commit:
> 
>   2c0df665 ("target: Fix overflow/underflow handling of commands with a 
> Data-Out buffer")
> 
> from the target-bva tree.
> 
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 

Hi Bart,

The majority of this series hasn't been list reviewed, and shouldn't be
getting pushed in linux-next without some form of reviews.

I'll be getting back to v4.13 items now v4.12-rc fixes is out of the
way, but a weeks worth of list silence for your series doesn't mean
you're free to push un-reviewed stuff for drivers/target/ into
linux-next.



[PATCH] doc/ko_KR/memory-barriers: Update control-dependencies example

2017-05-31 Thread SeongJae Park
This commit applies upstream change, commit b26cfc48e3e0 ("doc: Update
control-dependencies section of memory-barriers.txt"), to Korean
translation.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index d05d4c54e8f7..c6f4ead76ce7 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -786,7 +786,7 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 위의 코드를 아래와 같이 바꿔버릴 수 있습니다:
 
q = READ_ONCE(a);
-   WRITE_ONCE(b, 1);
+   WRITE_ONCE(b, 2);
do_something_else();
 
 이렇게 되면, CPU 는 변수 'a' 로부터의 로드와 변수 'b' 로의 스토어 사이의 순서를
-- 
2.13.0



[PATCH] doc/ko_KR/memory-barriers: Update control-dependencies example

2017-05-31 Thread SeongJae Park
This commit applies upstream change, commit b26cfc48e3e0 ("doc: Update
control-dependencies section of memory-barriers.txt"), to Korean
translation.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index d05d4c54e8f7..c6f4ead76ce7 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -786,7 +786,7 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 위의 코드를 아래와 같이 바꿔버릴 수 있습니다:
 
q = READ_ONCE(a);
-   WRITE_ONCE(b, 1);
+   WRITE_ONCE(b, 2);
do_something_else();
 
 이렇게 되면, CPU 는 변수 'a' 로부터의 로드와 변수 'b' 로의 스토어 사이의 순서를
-- 
2.13.0



[GIT PULL] target fixes for v4.12-rc4

2017-05-31 Thread Nicholas A. Bellinger
Hello Linus,

Here are the target-pending fixes for v4.12-rc4.  Please go ahead and
pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

This includes:

  - ibmviscsis ABORT_TASK handling fixes that missed the v4.12 merge 
window. (Bryant Ly and Michael Cyr)
  - Re-add a target-core check enforcing WRITE overflow reject that was 
relaxed in v4.3, to avoid unsupported iscsi-target immediate data 
overflow. (nab)
  - Fix a target-core-user OOPs during device removal. (MNC + Bryant Ly)
  - Fix a long standing iscsi-target potential issue where kthread exit 
did not wait for kthread_should_stop(). (Jiang Yi)
  - Fix a iscsi-target v3.12.y regression OOPs involving initial login 
PDU processing during asynchronous TCP connection close. (MNC + nab)

This is a little larger than usual for an -rc4, primarily due to the
iscsi-target v3.12.y regression OOPs bug-fix.

However, it's an important patch as MNC + Hannes where both able to
trigger it using a reduced iscsi initiator login timeout combined with a
backend taking a long time to complete I/Os during iscsi login driven
session reinstatement.

Note the trailing two patches have a recent CommitDate, as the second to
last was updated today to include MNC's tested-by and reviewed-by tags.
The patches themselves has not changed though, and both have been run
through manual and automated regression testing from multiple parties
over the last 7 days.

Thank you,

--nab

Bryant G. Ly (2):
  ibmvscsis: Clear left-over abort_cmd pointers
  ibmvscsis: Fix the incorrect req_lim_delta

Jiang Yi (1):
  iscsi-target: Always wait for kthread_should_stop() before kthread
exit

Mike Christie (1):
  tcmu: fix crash during device removal

Nicholas Bellinger (2):
  target: Re-add check to reject control WRITEs with overflow data
  iscsi-target: Fix initial login PDU asynchronous socket close OOPs

 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c  |  27 -
 drivers/target/iscsi/iscsi_target.c   |  30 -
 drivers/target/iscsi/iscsi_target_erl0.c  |   6 +-
 drivers/target/iscsi/iscsi_target_erl0.h  |   2 +-
 drivers/target/iscsi/iscsi_target_login.c |   4 +
 drivers/target/iscsi/iscsi_target_nego.c  | 194 --
 drivers/target/target_core_transport.c|  23 +++-
 drivers/target/target_core_user.c |  46 +--
 include/target/iscsi/iscsi_target_core.h  |   1 +
 9 files changed, 241 insertions(+), 92 deletions(-)



[GIT PULL] target fixes for v4.12-rc4

2017-05-31 Thread Nicholas A. Bellinger
Hello Linus,

Here are the target-pending fixes for v4.12-rc4.  Please go ahead and
pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

This includes:

  - ibmviscsis ABORT_TASK handling fixes that missed the v4.12 merge 
window. (Bryant Ly and Michael Cyr)
  - Re-add a target-core check enforcing WRITE overflow reject that was 
relaxed in v4.3, to avoid unsupported iscsi-target immediate data 
overflow. (nab)
  - Fix a target-core-user OOPs during device removal. (MNC + Bryant Ly)
  - Fix a long standing iscsi-target potential issue where kthread exit 
did not wait for kthread_should_stop(). (Jiang Yi)
  - Fix a iscsi-target v3.12.y regression OOPs involving initial login 
PDU processing during asynchronous TCP connection close. (MNC + nab)

This is a little larger than usual for an -rc4, primarily due to the
iscsi-target v3.12.y regression OOPs bug-fix.

However, it's an important patch as MNC + Hannes where both able to
trigger it using a reduced iscsi initiator login timeout combined with a
backend taking a long time to complete I/Os during iscsi login driven
session reinstatement.

Note the trailing two patches have a recent CommitDate, as the second to
last was updated today to include MNC's tested-by and reviewed-by tags.
The patches themselves has not changed though, and both have been run
through manual and automated regression testing from multiple parties
over the last 7 days.

Thank you,

--nab

Bryant G. Ly (2):
  ibmvscsis: Clear left-over abort_cmd pointers
  ibmvscsis: Fix the incorrect req_lim_delta

Jiang Yi (1):
  iscsi-target: Always wait for kthread_should_stop() before kthread
exit

Mike Christie (1):
  tcmu: fix crash during device removal

Nicholas Bellinger (2):
  target: Re-add check to reject control WRITEs with overflow data
  iscsi-target: Fix initial login PDU asynchronous socket close OOPs

 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c  |  27 -
 drivers/target/iscsi/iscsi_target.c   |  30 -
 drivers/target/iscsi/iscsi_target_erl0.c  |   6 +-
 drivers/target/iscsi/iscsi_target_erl0.h  |   2 +-
 drivers/target/iscsi/iscsi_target_login.c |   4 +
 drivers/target/iscsi/iscsi_target_nego.c  | 194 --
 drivers/target/target_core_transport.c|  23 +++-
 drivers/target/target_core_user.c |  46 +--
 include/target/iscsi/iscsi_target_core.h  |   1 +
 9 files changed, 241 insertions(+), 92 deletions(-)



Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-05-31 Thread Kalle Valo
Jia-Ju Bai  writes:

>> Did you actually observe the attempt to sleep under the spin lock,
>> or did you discover this using some tool? In other words, have
>> either of your patches been tested?
>
> In fact, my reported bugs are found by a static analysis tool written
> by me, and they are checked by my review of the driver code.

It's valuable information to add to the commit log how you found the
bug. If you check other wireless commits you can see comments like
"Found by spatch", "Coverity reported" quite frequently. So I recommend
that you also mention your tool in the commit log, makes understanding
the background of the patch easier.

-- 
Kalle Valo


Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-05-31 Thread Kalle Valo
Jia-Ju Bai  writes:

>> Did you actually observe the attempt to sleep under the spin lock,
>> or did you discover this using some tool? In other words, have
>> either of your patches been tested?
>
> In fact, my reported bugs are found by a static analysis tool written
> by me, and they are checked by my review of the driver code.

It's valuable information to add to the commit log how you found the
bug. If you check other wireless commits you can see comments like
"Found by spatch", "Coverity reported" quite frequently. So I recommend
that you also mention your tool in the commit log, makes understanding
the background of the patch easier.

-- 
Kalle Valo


linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Stephen Rothwell
Hi Bart,

Today's linux-next merge of the target-bva tree got a conflict in:

  drivers/target/target_core_transport.c

between commit:

  4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
data")

from the target-updates tree and commit:

  2c0df665 ("target: Fix overflow/underflow handling of commands with a 
Data-Out buffer")

from the target-bva tree.

I fixed it up (I think (guidance appreciated), see below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/target/target_core_transport.c
index 6025935036c9,6cd49fe578a7..
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@@ -1164,37 -1164,7 +1164,21 @@@ target_cmd_size_check(struct se_cmd *cm
" %u does not match SCSI CDB Length: %u for SAM Opcode:"
" 0x%02x\n", cmd->se_tfo->get_fabric_name(),
cmd->data_length, size, cmd->t_task_cdb[0]);
 +
 +  if (cmd->data_direction == DMA_TO_DEVICE) {
-   if (cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) {
-   pr_err_ratelimited("Rejecting 
underflow/overflow"
-  " for WRITE data CDB\n");
-   return TCM_INVALID_CDB_FIELD;
-   }
 +  /*
 +   * Some fabric drivers like iscsi-target still expect to
 +   * always reject overflow writes.  Reject this case 
until
 +   * full fabric driver level support for overflow writes
 +   * is introduced tree-wide.
 +   */
 +  if (size > cmd->data_length) {
 +  pr_err_ratelimited("Rejecting overflow for"
 + " WRITE control CDB\n");
 +  return TCM_INVALID_CDB_FIELD;
 +  }
 +  }
/*
-* Reject READ_* or WRITE_* with overflow/underflow for
-* type SCF_SCSI_DATA_CDB.
-*/
-   if (dev->dev_attrib.block_size != 512)  {
-   pr_err("Failing OVERFLOW/UNDERFLOW for LBA op"
-   " CDB on non 512-byte sector setup subsystem"
-   " plugin: %s\n", dev->transport->name);
-   /* Returns CHECK_CONDITION + INVALID_CDB_FIELD */
-   return TCM_INVALID_CDB_FIELD;
-   }
-   /*
 * For the overflow case keep the existing fabric provided
 * ->data_length.  Otherwise for the underflow case, reset
 * ->data_length to the smaller SCSI expected data transfer


linux-next: manual merge of the target-bva tree with the target-updates tree

2017-05-31 Thread Stephen Rothwell
Hi Bart,

Today's linux-next merge of the target-bva tree got a conflict in:

  drivers/target/target_core_transport.c

between commit:

  4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow 
data")

from the target-updates tree and commit:

  2c0df665 ("target: Fix overflow/underflow handling of commands with a 
Data-Out buffer")

from the target-bva tree.

I fixed it up (I think (guidance appreciated), see below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/target/target_core_transport.c
index 6025935036c9,6cd49fe578a7..
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@@ -1164,37 -1164,7 +1164,21 @@@ target_cmd_size_check(struct se_cmd *cm
" %u does not match SCSI CDB Length: %u for SAM Opcode:"
" 0x%02x\n", cmd->se_tfo->get_fabric_name(),
cmd->data_length, size, cmd->t_task_cdb[0]);
 +
 +  if (cmd->data_direction == DMA_TO_DEVICE) {
-   if (cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) {
-   pr_err_ratelimited("Rejecting 
underflow/overflow"
-  " for WRITE data CDB\n");
-   return TCM_INVALID_CDB_FIELD;
-   }
 +  /*
 +   * Some fabric drivers like iscsi-target still expect to
 +   * always reject overflow writes.  Reject this case 
until
 +   * full fabric driver level support for overflow writes
 +   * is introduced tree-wide.
 +   */
 +  if (size > cmd->data_length) {
 +  pr_err_ratelimited("Rejecting overflow for"
 + " WRITE control CDB\n");
 +  return TCM_INVALID_CDB_FIELD;
 +  }
 +  }
/*
-* Reject READ_* or WRITE_* with overflow/underflow for
-* type SCF_SCSI_DATA_CDB.
-*/
-   if (dev->dev_attrib.block_size != 512)  {
-   pr_err("Failing OVERFLOW/UNDERFLOW for LBA op"
-   " CDB on non 512-byte sector setup subsystem"
-   " plugin: %s\n", dev->transport->name);
-   /* Returns CHECK_CONDITION + INVALID_CDB_FIELD */
-   return TCM_INVALID_CDB_FIELD;
-   }
-   /*
 * For the overflow case keep the existing fabric provided
 * ->data_length.  Otherwise for the underflow case, reset
 * ->data_length to the smaller SCSI expected data transfer


Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Tobin C. Harding
On Thu, Jun 01, 2017 at 12:46:30PM +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> > Driver ks7010 does not currently have a maintainer.
> > 
> > Add maintainers entry for ks7010.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  MAINTAINERS | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9e98464..75250ee 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
> >  F: drivers/auxdisplay/ks0108.c
> >  F: include/linux/ks0108.h
> >  
> > +KS7010 KEYSTREAM DRIVER
> > +M:  Tobin Harding 
> > +L:  driverdev-de...@linuxdriverproject.org
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > +S:  Maintained
> > +F:  drivers/staging/ks7010/
> 
> All tabs please :)

Will fix in v2.

thanks,
Tobin.


Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Tobin C. Harding
On Thu, Jun 01, 2017 at 12:46:30PM +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> > Driver ks7010 does not currently have a maintainer.
> > 
> > Add maintainers entry for ks7010.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  MAINTAINERS | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9e98464..75250ee 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
> >  F: drivers/auxdisplay/ks0108.c
> >  F: include/linux/ks0108.h
> >  
> > +KS7010 KEYSTREAM DRIVER
> > +M:  Tobin Harding 
> > +L:  driverdev-de...@linuxdriverproject.org
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > +S:  Maintained
> > +F:  drivers/staging/ks7010/
> 
> All tabs please :)

Will fix in v2.

thanks,
Tobin.


Re: [RFC 1/3] staging: ks7010: move WEXT files to sub directory

2017-05-31 Thread Tobin C. Harding
On Thu, Jun 01, 2017 at 12:45:37PM +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:06PM +1000, Tobin C. Harding wrote:
> > Current driver implements the WEXT interface. WEXT is in maintenance
> > mode, we need to re-write the driver using cfg80211. The current
> > driver is handy as a reference for the new implementation, we can keep
> > it in tree for now.
> > 
> > Move WEXT driver to sub directory, add dummy Makefile and Kconfig so
> > build completes successfully but does not process any files from the
> > WEXT directory.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  drivers/staging/ks7010/Kconfig  |6 +-
> >  drivers/staging/ks7010/Makefile |3 -
> >  drivers/staging/ks7010/TODO |   36 -
> >  drivers/staging/ks7010/eap_packet.h |  144 --
> >  drivers/staging/ks7010/ks7010_sdio.c| 1079 --
> >  drivers/staging/ks7010/ks7010_sdio.h|  164 --
> >  drivers/staging/ks7010/ks_hostif.c  | 2638 ---
> >  drivers/staging/ks7010/ks_hostif.h  |  685 --
> >  drivers/staging/ks7010/ks_wlan.h|  514 -
> >  drivers/staging/ks7010/ks_wlan_ioctl.h  |   67 -
> >  drivers/staging/ks7010/ks_wlan_net.c| 2999 
> > ---
> >  drivers/staging/ks7010/michael_mic.c|  148 --
> >  drivers/staging/ks7010/michael_mic.h|   25 -
> >  drivers/staging/ks7010/wext/Kconfig |   10 +
> >  drivers/staging/ks7010/wext/Makefile|4 +
> >  drivers/staging/ks7010/wext/TODO|   36 +
> >  drivers/staging/ks7010/wext/eap_packet.h|  144 ++
> >  drivers/staging/ks7010/wext/ks7010_sdio.c   | 1079 ++
> >  drivers/staging/ks7010/wext/ks7010_sdio.h   |  164 ++
> >  drivers/staging/ks7010/wext/ks_hostif.c | 2638 +++
> >  drivers/staging/ks7010/wext/ks_hostif.h |  685 ++
> >  drivers/staging/ks7010/wext/ks_wlan.h   |  514 +
> >  drivers/staging/ks7010/wext/ks_wlan_ioctl.h |   67 +
> >  drivers/staging/ks7010/wext/ks_wlan_net.c   | 2999 
> > +++
> >  drivers/staging/ks7010/wext/michael_mic.c   |  148 ++
> >  drivers/staging/ks7010/wext/michael_mic.h   |   25 +
> >  26 files changed, 8514 insertions(+), 8507 deletions(-)
> >  delete mode 100644 drivers/staging/ks7010/TODO
> >  delete mode 100644 drivers/staging/ks7010/eap_packet.h
> >  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.c
> >  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.h
> >  delete mode 100644 drivers/staging/ks7010/ks_hostif.c
> >  delete mode 100644 drivers/staging/ks7010/ks_hostif.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan_ioctl.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan_net.c
> >  delete mode 100644 drivers/staging/ks7010/michael_mic.c
> >  delete mode 100644 drivers/staging/ks7010/michael_mic.h
> >  create mode 100644 drivers/staging/ks7010/wext/Kconfig
> >  create mode 100644 drivers/staging/ks7010/wext/Makefile
> >  create mode 100644 drivers/staging/ks7010/wext/TODO
> >  create mode 100644 drivers/staging/ks7010/wext/eap_packet.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.c
> >  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.c
> >  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_ioctl.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_net.c
> >  create mode 100644 drivers/staging/ks7010/wext/michael_mic.c
> >  create mode 100644 drivers/staging/ks7010/wext/michael_mic.h
> 
> Please use the -M option to 'git format-patch" so that we can just see
> file moves, not delete/add like you have here.

Point noted, will submit v2 using -M option. This is the second time
you have told me this, that means I have to buy you a beer doesn't it?

Will follow the 'wait a day before submitting next version' rule.

thanks,
Tobin.


Re: [RFC 1/3] staging: ks7010: move WEXT files to sub directory

2017-05-31 Thread Tobin C. Harding
On Thu, Jun 01, 2017 at 12:45:37PM +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:06PM +1000, Tobin C. Harding wrote:
> > Current driver implements the WEXT interface. WEXT is in maintenance
> > mode, we need to re-write the driver using cfg80211. The current
> > driver is handy as a reference for the new implementation, we can keep
> > it in tree for now.
> > 
> > Move WEXT driver to sub directory, add dummy Makefile and Kconfig so
> > build completes successfully but does not process any files from the
> > WEXT directory.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  drivers/staging/ks7010/Kconfig  |6 +-
> >  drivers/staging/ks7010/Makefile |3 -
> >  drivers/staging/ks7010/TODO |   36 -
> >  drivers/staging/ks7010/eap_packet.h |  144 --
> >  drivers/staging/ks7010/ks7010_sdio.c| 1079 --
> >  drivers/staging/ks7010/ks7010_sdio.h|  164 --
> >  drivers/staging/ks7010/ks_hostif.c  | 2638 ---
> >  drivers/staging/ks7010/ks_hostif.h  |  685 --
> >  drivers/staging/ks7010/ks_wlan.h|  514 -
> >  drivers/staging/ks7010/ks_wlan_ioctl.h  |   67 -
> >  drivers/staging/ks7010/ks_wlan_net.c| 2999 
> > ---
> >  drivers/staging/ks7010/michael_mic.c|  148 --
> >  drivers/staging/ks7010/michael_mic.h|   25 -
> >  drivers/staging/ks7010/wext/Kconfig |   10 +
> >  drivers/staging/ks7010/wext/Makefile|4 +
> >  drivers/staging/ks7010/wext/TODO|   36 +
> >  drivers/staging/ks7010/wext/eap_packet.h|  144 ++
> >  drivers/staging/ks7010/wext/ks7010_sdio.c   | 1079 ++
> >  drivers/staging/ks7010/wext/ks7010_sdio.h   |  164 ++
> >  drivers/staging/ks7010/wext/ks_hostif.c | 2638 +++
> >  drivers/staging/ks7010/wext/ks_hostif.h |  685 ++
> >  drivers/staging/ks7010/wext/ks_wlan.h   |  514 +
> >  drivers/staging/ks7010/wext/ks_wlan_ioctl.h |   67 +
> >  drivers/staging/ks7010/wext/ks_wlan_net.c   | 2999 
> > +++
> >  drivers/staging/ks7010/wext/michael_mic.c   |  148 ++
> >  drivers/staging/ks7010/wext/michael_mic.h   |   25 +
> >  26 files changed, 8514 insertions(+), 8507 deletions(-)
> >  delete mode 100644 drivers/staging/ks7010/TODO
> >  delete mode 100644 drivers/staging/ks7010/eap_packet.h
> >  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.c
> >  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.h
> >  delete mode 100644 drivers/staging/ks7010/ks_hostif.c
> >  delete mode 100644 drivers/staging/ks7010/ks_hostif.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan_ioctl.h
> >  delete mode 100644 drivers/staging/ks7010/ks_wlan_net.c
> >  delete mode 100644 drivers/staging/ks7010/michael_mic.c
> >  delete mode 100644 drivers/staging/ks7010/michael_mic.h
> >  create mode 100644 drivers/staging/ks7010/wext/Kconfig
> >  create mode 100644 drivers/staging/ks7010/wext/Makefile
> >  create mode 100644 drivers/staging/ks7010/wext/TODO
> >  create mode 100644 drivers/staging/ks7010/wext/eap_packet.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.c
> >  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.c
> >  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_ioctl.h
> >  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_net.c
> >  create mode 100644 drivers/staging/ks7010/wext/michael_mic.c
> >  create mode 100644 drivers/staging/ks7010/wext/michael_mic.h
> 
> Please use the -M option to 'git format-patch" so that we can just see
> file moves, not delete/add like you have here.

Point noted, will submit v2 using -M option. This is the second time
you have told me this, that means I have to buy you a beer doesn't it?

Will follow the 'wait a day before submitting next version' rule.

thanks,
Tobin.


Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Joe Perches
On Thu, 2017-06-01 at 12:46 +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> > Add maintainers entry for ks7010.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > @@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
> >  F: drivers/auxdisplay/ks0108.c
> >  F: include/linux/ks0108.h
> >  
> > +KS7010 KEYSTREAM DRIVER
> > +M:  Tobin Harding 
> > +L:  driverdev-de...@linuxdriverproject.org
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > +S:  Maintained
> > +F:  drivers/staging/ks7010/
> 
> All tabs please :)

Right.  Perhaps someone could do:

$ sed -r -i -e "s/^([A-Z]):\s*/\1:\t/" MAINTAINERS

For today's -next, that gives:
---
 MAINTAINERS | 122 ++--
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a4d082acb458..335a18e9785b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1080,7 +1080,7 @@ S:Maintained
 F: arch/arm/mach-meson/
 F: arch/arm/boot/dts/meson*
 F: arch/arm64/boot/dts/amlogic/
-F: drivers/pinctrl/meson/
+F: drivers/pinctrl/meson/
 F: drivers/mmc/host/meson*
 N: meson
 
@@ -3101,14 +3101,14 @@ S:  Supported
 F: drivers/mmc/host/cavium*
 
 CAVIUM LIQUIDIO NETWORK DRIVER
-M: Derek Chickles 
-M: Satanand Burla 
-M: Felix Manlunas 
-M: Raghu Vatsavayi 
-L: net...@vger.kernel.org
-W: http://www.cavium.com
-S: Supported
-F: drivers/net/ethernet/cavium/liquidio/
+M: Derek Chickles 
+M: Satanand Burla 
+M: Felix Manlunas 
+M: Raghu Vatsavayi 
+L: net...@vger.kernel.org
+W: http://www.cavium.com
+S: Supported
+F: drivers/net/ethernet/cavium/liquidio/
 
 CAVIUM OCTEON-TX CRYPTO DRIVER
 M: George Cherian 
@@ -4327,14 +4327,14 @@ F:  include/uapi/drm/i915_drm.h
 F: Documentation/gpu/i915.rst
 
 INTEL GVT-g DRIVERS (Intel GPU Virtualization)
-M:  Zhenyu Wang 
-M:  Zhi Wang 
-L:  intel-gvt-...@lists.freedesktop.org
-L:  intel-...@lists.freedesktop.org
-W:  https://01.org/igvt-g
-T:  git https://github.com/01org/gvt-linux.git
-S:  Supported
-F:  drivers/gpu/drm/i915/gvt/
+M: Zhenyu Wang 
+M: Zhi Wang 
+L: intel-gvt-...@lists.freedesktop.org
+L: intel-...@lists.freedesktop.org
+W: https://01.org/igvt-g
+T: git https://github.com/01org/gvt-linux.git
+S: Supported
+F: drivers/gpu/drm/i915/gvt/
 
 DRM DRIVERS FOR ATMEL HLCDC
 M: Boris Brezillon 
@@ -4933,10 +4933,10 @@ F:  drivers/edac/skx_edac.c
 
 EDAC-XGENE
 APPLIED MICRO (APM) X-GENE SOC EDAC
-M: Loc Ho 
-S: Supported
-F: drivers/edac/xgene_edac.c
-F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
+M: Loc Ho 
+S: Supported
+F: drivers/edac/xgene_edac.c
+F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
 
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
@@ -6778,11 +6778,11 @@ F:  drivers/net/ethernet/intel/
 F: drivers/net/ethernet/intel/*/
 
 INTEL RDMA RNIC DRIVER
-M: Faisal Latif 
-M: Shiraz Saleem 
-L: linux-r...@vger.kernel.org
-S: Supported
-F: drivers/infiniband/hw/i40iw/
+M: Faisal Latif 
+M: Shiraz Saleem 
+L: linux-r...@vger.kernel.org
+S: Supported
+F: drivers/infiniband/hw/i40iw/
 
 INTEL MERRIFIELD GPIO DRIVER
 M: Andy Shevchenko 
@@ -6867,7 +6867,7 @@ W:http://software.intel.com/en-us/mic-developer
 F: include/linux/mic_bus.h
 F: include/linux/scif.h
 F: include/uapi/linux/mic_common.h
-F: include/uapi/linux/mic_ioctl.h
+F: include/uapi/linux/mic_ioctl.h
 F: include/uapi/linux/scif_ioctl.h
 F: drivers/misc/mic/
 F: drivers/dma/mic_x100_dma.c
@@ -8393,10 +8393,10 @@ F:  drivers/leds/leds-mlxcpld.c
 F: Documentation/leds/leds-mlxcpld.txt
 
 MELLANOX PLATFORM DRIVER
-M:  Vadim Pasternak 
-L:  platform-driver-...@vger.kernel.org
-S:  Supported
-F:  drivers/platform/x86/mlx-platform.c
+M: Vadim Pasternak 
+L: platform-driver-...@vger.kernel.org
+S: Supported
+F: drivers/platform/x86/mlx-platform.c
 
 MELLANOX MLX CPLD HOTPLUG DRIVER
 M: Vadim Pasternak 
@@ -9677,11 +9677,11 @@ F:  

Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Joe Perches
On Thu, 2017-06-01 at 12:46 +0900, Greg KH wrote:
> On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> > Add maintainers entry for ks7010.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > @@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
> >  F: drivers/auxdisplay/ks0108.c
> >  F: include/linux/ks0108.h
> >  
> > +KS7010 KEYSTREAM DRIVER
> > +M:  Tobin Harding 
> > +L:  driverdev-de...@linuxdriverproject.org
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > +S:  Maintained
> > +F:  drivers/staging/ks7010/
> 
> All tabs please :)

Right.  Perhaps someone could do:

$ sed -r -i -e "s/^([A-Z]):\s*/\1:\t/" MAINTAINERS

For today's -next, that gives:
---
 MAINTAINERS | 122 ++--
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a4d082acb458..335a18e9785b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1080,7 +1080,7 @@ S:Maintained
 F: arch/arm/mach-meson/
 F: arch/arm/boot/dts/meson*
 F: arch/arm64/boot/dts/amlogic/
-F: drivers/pinctrl/meson/
+F: drivers/pinctrl/meson/
 F: drivers/mmc/host/meson*
 N: meson
 
@@ -3101,14 +3101,14 @@ S:  Supported
 F: drivers/mmc/host/cavium*
 
 CAVIUM LIQUIDIO NETWORK DRIVER
-M: Derek Chickles 
-M: Satanand Burla 
-M: Felix Manlunas 
-M: Raghu Vatsavayi 
-L: net...@vger.kernel.org
-W: http://www.cavium.com
-S: Supported
-F: drivers/net/ethernet/cavium/liquidio/
+M: Derek Chickles 
+M: Satanand Burla 
+M: Felix Manlunas 
+M: Raghu Vatsavayi 
+L: net...@vger.kernel.org
+W: http://www.cavium.com
+S: Supported
+F: drivers/net/ethernet/cavium/liquidio/
 
 CAVIUM OCTEON-TX CRYPTO DRIVER
 M: George Cherian 
@@ -4327,14 +4327,14 @@ F:  include/uapi/drm/i915_drm.h
 F: Documentation/gpu/i915.rst
 
 INTEL GVT-g DRIVERS (Intel GPU Virtualization)
-M:  Zhenyu Wang 
-M:  Zhi Wang 
-L:  intel-gvt-...@lists.freedesktop.org
-L:  intel-...@lists.freedesktop.org
-W:  https://01.org/igvt-g
-T:  git https://github.com/01org/gvt-linux.git
-S:  Supported
-F:  drivers/gpu/drm/i915/gvt/
+M: Zhenyu Wang 
+M: Zhi Wang 
+L: intel-gvt-...@lists.freedesktop.org
+L: intel-...@lists.freedesktop.org
+W: https://01.org/igvt-g
+T: git https://github.com/01org/gvt-linux.git
+S: Supported
+F: drivers/gpu/drm/i915/gvt/
 
 DRM DRIVERS FOR ATMEL HLCDC
 M: Boris Brezillon 
@@ -4933,10 +4933,10 @@ F:  drivers/edac/skx_edac.c
 
 EDAC-XGENE
 APPLIED MICRO (APM) X-GENE SOC EDAC
-M: Loc Ho 
-S: Supported
-F: drivers/edac/xgene_edac.c
-F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
+M: Loc Ho 
+S: Supported
+F: drivers/edac/xgene_edac.c
+F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
 
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
@@ -6778,11 +6778,11 @@ F:  drivers/net/ethernet/intel/
 F: drivers/net/ethernet/intel/*/
 
 INTEL RDMA RNIC DRIVER
-M: Faisal Latif 
-M: Shiraz Saleem 
-L: linux-r...@vger.kernel.org
-S: Supported
-F: drivers/infiniband/hw/i40iw/
+M: Faisal Latif 
+M: Shiraz Saleem 
+L: linux-r...@vger.kernel.org
+S: Supported
+F: drivers/infiniband/hw/i40iw/
 
 INTEL MERRIFIELD GPIO DRIVER
 M: Andy Shevchenko 
@@ -6867,7 +6867,7 @@ W:http://software.intel.com/en-us/mic-developer
 F: include/linux/mic_bus.h
 F: include/linux/scif.h
 F: include/uapi/linux/mic_common.h
-F: include/uapi/linux/mic_ioctl.h
+F: include/uapi/linux/mic_ioctl.h
 F: include/uapi/linux/scif_ioctl.h
 F: drivers/misc/mic/
 F: drivers/dma/mic_x100_dma.c
@@ -8393,10 +8393,10 @@ F:  drivers/leds/leds-mlxcpld.c
 F: Documentation/leds/leds-mlxcpld.txt
 
 MELLANOX PLATFORM DRIVER
-M:  Vadim Pasternak 
-L:  platform-driver-...@vger.kernel.org
-S:  Supported
-F:  drivers/platform/x86/mlx-platform.c
+M: Vadim Pasternak 
+L: platform-driver-...@vger.kernel.org
+S: Supported
+F: drivers/platform/x86/mlx-platform.c
 
 MELLANOX MLX CPLD HOTPLUG DRIVER
 M: Vadim Pasternak 
@@ -9677,11 +9677,11 @@ F:  Documentation/mn10300/
 F: arch/mn10300/
 
 PARALLEL LCD/KEYPAD PANEL DRIVER
-M:  Willy Tarreau 
-M:  Ksenija Stanojevic 
-S:  Odd Fixes
-F:  Documentation/misc-devices/lcd-panel-cgram.txt
-F:  drivers/misc/panel.c
+M: Willy Tarreau 
+M: Ksenija Stanojevic 
+S: Odd Fixes
+F: Documentation/misc-devices/lcd-panel-cgram.txt
+F: drivers/misc/panel.c
 
 PARALLEL PORT SUBSYSTEM
 M: Sudip Mukherjee 
@@ -10002,11 +10002,11 @@ F:
Documentation/devicetree/bindings/pci/rockchip-pcie.txt
 F: drivers/pci/host/pcie-rockchip.c
 
 PCIE DRIVER FOR QUALCOMM MSM
-M: Stanimir Varbanov 
-L: linux-...@vger.kernel.org
-L: 

[PATCH] rts5208: Fix a sleep-in-atomic bug in sd_power_off_card3v3

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
rtsx_exclusive_enter_ss (acquire the lock by spin_lock)
  rtsx_enter_ss
rtsx_power_off_card
  sd_power_off_card3v3
wait_timeout
  schedule_timeout --> may sleep

To fix it, "wait_timeout" is replaced with mdelay in sd_power_off_card3v3.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rts5208/sd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index bdd35b6..aa14454 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -5231,7 +5231,7 @@ int sd_power_off_card3v3(struct rtsx_chip *chip)
return STATUS_FAIL;
}
 
-   wait_timeout(50);
+   mdelay(50);
}
 
if (chip->asic_code) {
-- 
1.7.9.5




[PATCH] rts5208: Fix a sleep-in-atomic bug in sd_power_off_card3v3

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
rtsx_exclusive_enter_ss (acquire the lock by spin_lock)
  rtsx_enter_ss
rtsx_power_off_card
  sd_power_off_card3v3
wait_timeout
  schedule_timeout --> may sleep

To fix it, "wait_timeout" is replaced with mdelay in sd_power_off_card3v3.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rts5208/sd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index bdd35b6..aa14454 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -5231,7 +5231,7 @@ int sd_power_off_card3v3(struct rtsx_chip *chip)
return STATUS_FAIL;
}
 
-   wait_timeout(50);
+   mdelay(50);
}
 
if (chip->asic_code) {
-- 
1.7.9.5




Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Greg KH
On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> Driver ks7010 does not currently have a maintainer.
> 
> Add maintainers entry for ks7010.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9e98464..75250ee 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7429,6 +7429,13 @@ F: Documentation/auxdisplay/ks0108
>  F:   drivers/auxdisplay/ks0108.c
>  F:   include/linux/ks0108.h
>  
> +KS7010 KEYSTREAM DRIVER
> +M:  Tobin Harding 
> +L:  driverdev-de...@linuxdriverproject.org
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> +S:  Maintained
> +F:  drivers/staging/ks7010/

All tabs please :)


Re: [RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Greg KH
On Thu, Jun 01, 2017 at 01:27:08PM +1000, Tobin C. Harding wrote:
> Driver ks7010 does not currently have a maintainer.
> 
> Add maintainers entry for ks7010.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9e98464..75250ee 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7429,6 +7429,13 @@ F: Documentation/auxdisplay/ks0108
>  F:   drivers/auxdisplay/ks0108.c
>  F:   include/linux/ks0108.h
>  
> +KS7010 KEYSTREAM DRIVER
> +M:  Tobin Harding 
> +L:  driverdev-de...@linuxdriverproject.org
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> +S:  Maintained
> +F:  drivers/staging/ks7010/

All tabs please :)


Re: [RFC 1/3] staging: ks7010: move WEXT files to sub directory

2017-05-31 Thread Greg KH
On Thu, Jun 01, 2017 at 01:27:06PM +1000, Tobin C. Harding wrote:
> Current driver implements the WEXT interface. WEXT is in maintenance
> mode, we need to re-write the driver using cfg80211. The current
> driver is handy as a reference for the new implementation, we can keep
> it in tree for now.
> 
> Move WEXT driver to sub directory, add dummy Makefile and Kconfig so
> build completes successfully but does not process any files from the
> WEXT directory.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  drivers/staging/ks7010/Kconfig  |6 +-
>  drivers/staging/ks7010/Makefile |3 -
>  drivers/staging/ks7010/TODO |   36 -
>  drivers/staging/ks7010/eap_packet.h |  144 --
>  drivers/staging/ks7010/ks7010_sdio.c| 1079 --
>  drivers/staging/ks7010/ks7010_sdio.h|  164 --
>  drivers/staging/ks7010/ks_hostif.c  | 2638 ---
>  drivers/staging/ks7010/ks_hostif.h  |  685 --
>  drivers/staging/ks7010/ks_wlan.h|  514 -
>  drivers/staging/ks7010/ks_wlan_ioctl.h  |   67 -
>  drivers/staging/ks7010/ks_wlan_net.c| 2999 
> ---
>  drivers/staging/ks7010/michael_mic.c|  148 --
>  drivers/staging/ks7010/michael_mic.h|   25 -
>  drivers/staging/ks7010/wext/Kconfig |   10 +
>  drivers/staging/ks7010/wext/Makefile|4 +
>  drivers/staging/ks7010/wext/TODO|   36 +
>  drivers/staging/ks7010/wext/eap_packet.h|  144 ++
>  drivers/staging/ks7010/wext/ks7010_sdio.c   | 1079 ++
>  drivers/staging/ks7010/wext/ks7010_sdio.h   |  164 ++
>  drivers/staging/ks7010/wext/ks_hostif.c | 2638 +++
>  drivers/staging/ks7010/wext/ks_hostif.h |  685 ++
>  drivers/staging/ks7010/wext/ks_wlan.h   |  514 +
>  drivers/staging/ks7010/wext/ks_wlan_ioctl.h |   67 +
>  drivers/staging/ks7010/wext/ks_wlan_net.c   | 2999 
> +++
>  drivers/staging/ks7010/wext/michael_mic.c   |  148 ++
>  drivers/staging/ks7010/wext/michael_mic.h   |   25 +
>  26 files changed, 8514 insertions(+), 8507 deletions(-)
>  delete mode 100644 drivers/staging/ks7010/TODO
>  delete mode 100644 drivers/staging/ks7010/eap_packet.h
>  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.c
>  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.h
>  delete mode 100644 drivers/staging/ks7010/ks_hostif.c
>  delete mode 100644 drivers/staging/ks7010/ks_hostif.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan_ioctl.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan_net.c
>  delete mode 100644 drivers/staging/ks7010/michael_mic.c
>  delete mode 100644 drivers/staging/ks7010/michael_mic.h
>  create mode 100644 drivers/staging/ks7010/wext/Kconfig
>  create mode 100644 drivers/staging/ks7010/wext/Makefile
>  create mode 100644 drivers/staging/ks7010/wext/TODO
>  create mode 100644 drivers/staging/ks7010/wext/eap_packet.h
>  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.c
>  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.c
>  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_ioctl.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_net.c
>  create mode 100644 drivers/staging/ks7010/wext/michael_mic.c
>  create mode 100644 drivers/staging/ks7010/wext/michael_mic.h

Please use the -M option to 'git format-patch" so that we can just see
file moves, not delete/add like you have here.

thanks,

greg k-h


Re: [RFC 1/3] staging: ks7010: move WEXT files to sub directory

2017-05-31 Thread Greg KH
On Thu, Jun 01, 2017 at 01:27:06PM +1000, Tobin C. Harding wrote:
> Current driver implements the WEXT interface. WEXT is in maintenance
> mode, we need to re-write the driver using cfg80211. The current
> driver is handy as a reference for the new implementation, we can keep
> it in tree for now.
> 
> Move WEXT driver to sub directory, add dummy Makefile and Kconfig so
> build completes successfully but does not process any files from the
> WEXT directory.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  drivers/staging/ks7010/Kconfig  |6 +-
>  drivers/staging/ks7010/Makefile |3 -
>  drivers/staging/ks7010/TODO |   36 -
>  drivers/staging/ks7010/eap_packet.h |  144 --
>  drivers/staging/ks7010/ks7010_sdio.c| 1079 --
>  drivers/staging/ks7010/ks7010_sdio.h|  164 --
>  drivers/staging/ks7010/ks_hostif.c  | 2638 ---
>  drivers/staging/ks7010/ks_hostif.h  |  685 --
>  drivers/staging/ks7010/ks_wlan.h|  514 -
>  drivers/staging/ks7010/ks_wlan_ioctl.h  |   67 -
>  drivers/staging/ks7010/ks_wlan_net.c| 2999 
> ---
>  drivers/staging/ks7010/michael_mic.c|  148 --
>  drivers/staging/ks7010/michael_mic.h|   25 -
>  drivers/staging/ks7010/wext/Kconfig |   10 +
>  drivers/staging/ks7010/wext/Makefile|4 +
>  drivers/staging/ks7010/wext/TODO|   36 +
>  drivers/staging/ks7010/wext/eap_packet.h|  144 ++
>  drivers/staging/ks7010/wext/ks7010_sdio.c   | 1079 ++
>  drivers/staging/ks7010/wext/ks7010_sdio.h   |  164 ++
>  drivers/staging/ks7010/wext/ks_hostif.c | 2638 +++
>  drivers/staging/ks7010/wext/ks_hostif.h |  685 ++
>  drivers/staging/ks7010/wext/ks_wlan.h   |  514 +
>  drivers/staging/ks7010/wext/ks_wlan_ioctl.h |   67 +
>  drivers/staging/ks7010/wext/ks_wlan_net.c   | 2999 
> +++
>  drivers/staging/ks7010/wext/michael_mic.c   |  148 ++
>  drivers/staging/ks7010/wext/michael_mic.h   |   25 +
>  26 files changed, 8514 insertions(+), 8507 deletions(-)
>  delete mode 100644 drivers/staging/ks7010/TODO
>  delete mode 100644 drivers/staging/ks7010/eap_packet.h
>  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.c
>  delete mode 100644 drivers/staging/ks7010/ks7010_sdio.h
>  delete mode 100644 drivers/staging/ks7010/ks_hostif.c
>  delete mode 100644 drivers/staging/ks7010/ks_hostif.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan_ioctl.h
>  delete mode 100644 drivers/staging/ks7010/ks_wlan_net.c
>  delete mode 100644 drivers/staging/ks7010/michael_mic.c
>  delete mode 100644 drivers/staging/ks7010/michael_mic.h
>  create mode 100644 drivers/staging/ks7010/wext/Kconfig
>  create mode 100644 drivers/staging/ks7010/wext/Makefile
>  create mode 100644 drivers/staging/ks7010/wext/TODO
>  create mode 100644 drivers/staging/ks7010/wext/eap_packet.h
>  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.c
>  create mode 100644 drivers/staging/ks7010/wext/ks7010_sdio.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.c
>  create mode 100644 drivers/staging/ks7010/wext/ks_hostif.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_ioctl.h
>  create mode 100644 drivers/staging/ks7010/wext/ks_wlan_net.c
>  create mode 100644 drivers/staging/ks7010/wext/michael_mic.c
>  create mode 100644 drivers/staging/ks7010/wext/michael_mic.h

Please use the -M option to 'git format-patch" so that we can just see
file moves, not delete/add like you have here.

thanks,

greg k-h


[PATCH] rts5208: Fix a sleep-in-atomic bug in rtsx_exclusive_enter_ss

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
rtsx_exclusive_enter_ss (acquire the lock by spin_lock)
  rtsx_enter_ss
rtsx_power_off_card
  sd_cleanup_work
sd_stop_seq_mode
  sd_switch_clock
sd_ddr_tuning
  sd_ddr_pre_tuning_tx
sd_change_phase
  wait_timeout
schedule_timeout --> may sleep

To fix it, "wait_timeout" is replaced with mdelay in sd_change_phase.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rts5208/sd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index bdd35b6..76bd105 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -1057,7 +1057,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 
sample_point, u8 tune_dir)
 
rtsx_write_register(chip, SD_DCMPS_CTL, DCMPS_CHANGE, 0);
rtsx_write_register(chip, SD_VP_CTL, PHASE_CHANGE, 0);
-   wait_timeout(10);
+   mdelay(10);
sd_reset_dcm(chip, tune_dir);
return STATUS_FAIL;
 }
-- 
1.7.9.5




[PATCH] rts5208: Fix a sleep-in-atomic bug in rtsx_exclusive_enter_ss

2017-05-31 Thread Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
rtsx_exclusive_enter_ss (acquire the lock by spin_lock)
  rtsx_enter_ss
rtsx_power_off_card
  sd_cleanup_work
sd_stop_seq_mode
  sd_switch_clock
sd_ddr_tuning
  sd_ddr_pre_tuning_tx
sd_change_phase
  wait_timeout
schedule_timeout --> may sleep

To fix it, "wait_timeout" is replaced with mdelay in sd_change_phase.

Signed-off-by: Jia-Ju Bai 
---
 drivers/staging/rts5208/sd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index bdd35b6..76bd105 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -1057,7 +1057,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 
sample_point, u8 tune_dir)
 
rtsx_write_register(chip, SD_DCMPS_CTL, DCMPS_CHANGE, 0);
rtsx_write_register(chip, SD_VP_CTL, PHASE_CHANGE, 0);
-   wait_timeout(10);
+   mdelay(10);
sd_reset_dcm(chip, tune_dir);
return STATUS_FAIL;
 }
-- 
1.7.9.5




Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

2017-05-31 Thread Lu Baolu
Hi,

On 05/31/2017 05:38 PM, Vlastimil Babka wrote:
> On 05/31/2017 05:27 AM, Lu Baolu wrote:
>> Hi,
>>
>> On 05/30/2017 09:46 PM, Vlastimil Babka wrote:
>>> On 03/21/2017 09:01 AM, Lu Baolu wrote:
 XHCI debug capability (DbC) is an optional but standalone
 functionality provided by an xHCI host controller. Software
 learns this capability by walking through the extended
 capability list of the host. XHCI specification describes
 DbC in the section 7.6.

 This patch introduces the code to probe and initialize the
 debug capability hardware during early boot. With hardware
 initialized, the debug target (system on which this code is
 running) will present a debug device through the debug port
 (normally the first USB3 port). The debug device is fully
 compliant with the USB framework and provides the equivalent
 of a very high performance (USB3) full-duplex serial link
 between the debug host and target. The DbC functionality is
 independent of the xHCI host. There isn't any precondition
 from the xHCI host side for the DbC to work.

 One use for this feature is kernel debugging, for example
 when your machine crashes very early before the regular
 console code is initialized. Other uses include simpler,
 lockless logging instead of a full-blown printk console
 driver and klogd.

 Cc: Ingo Molnar 
 Cc: Mathias Nyman 
 Signed-off-by: Lu Baolu 
>>> ...
>>>
 +
 +#define XDBC_TRACE
 +#ifdef XDBC_TRACE
 +#define   xdbc_trace  trace_printk
>>> Did you forget to remove the #define XDBC_TRACE?
>>>
>>> Enabling this driver brings the "trace_printk() being used. Allocating
>>> extra memory. This means that this is a DEBUG kernel and it is unsafe
>>> for production use." message in 4.12-rcX dmesg.
>> This feature is only for a DEBUG kernel, should not be enabled for
>> any production kernel. This was the reason I enabled trace_printk()
>> by default.
> Hmm, but it seems we generally enable all these early printk
> features/drivers in our distro kernels. They are not active without a
> early_printk=X bootparam anyway, right? It's much more convenient to
> e.g. just tell customer to change a param when debugging something than
> to install a debug kernel. So I wouldn't agree that only a DEBUG kernel
> should have this compiled in.

Okay, I will try to find a fix.

Best regards,
Lu Baolu

>
> Thanks,
> Vlastimil
>
>> Best regards,
>> Lu Baolu
>>
>>> Thanks,
>>> Vlastimil
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

2017-05-31 Thread Lu Baolu
Hi,

On 05/31/2017 05:38 PM, Vlastimil Babka wrote:
> On 05/31/2017 05:27 AM, Lu Baolu wrote:
>> Hi,
>>
>> On 05/30/2017 09:46 PM, Vlastimil Babka wrote:
>>> On 03/21/2017 09:01 AM, Lu Baolu wrote:
 XHCI debug capability (DbC) is an optional but standalone
 functionality provided by an xHCI host controller. Software
 learns this capability by walking through the extended
 capability list of the host. XHCI specification describes
 DbC in the section 7.6.

 This patch introduces the code to probe and initialize the
 debug capability hardware during early boot. With hardware
 initialized, the debug target (system on which this code is
 running) will present a debug device through the debug port
 (normally the first USB3 port). The debug device is fully
 compliant with the USB framework and provides the equivalent
 of a very high performance (USB3) full-duplex serial link
 between the debug host and target. The DbC functionality is
 independent of the xHCI host. There isn't any precondition
 from the xHCI host side for the DbC to work.

 One use for this feature is kernel debugging, for example
 when your machine crashes very early before the regular
 console code is initialized. Other uses include simpler,
 lockless logging instead of a full-blown printk console
 driver and klogd.

 Cc: Ingo Molnar 
 Cc: Mathias Nyman 
 Signed-off-by: Lu Baolu 
>>> ...
>>>
 +
 +#define XDBC_TRACE
 +#ifdef XDBC_TRACE
 +#define   xdbc_trace  trace_printk
>>> Did you forget to remove the #define XDBC_TRACE?
>>>
>>> Enabling this driver brings the "trace_printk() being used. Allocating
>>> extra memory. This means that this is a DEBUG kernel and it is unsafe
>>> for production use." message in 4.12-rcX dmesg.
>> This feature is only for a DEBUG kernel, should not be enabled for
>> any production kernel. This was the reason I enabled trace_printk()
>> by default.
> Hmm, but it seems we generally enable all these early printk
> features/drivers in our distro kernels. They are not active without a
> early_printk=X bootparam anyway, right? It's much more convenient to
> e.g. just tell customer to change a param when debugging something than
> to install a debug kernel. So I wouldn't agree that only a DEBUG kernel
> should have this compiled in.

Okay, I will try to find a fix.

Best regards,
Lu Baolu

>
> Thanks,
> Vlastimil
>
>> Best regards,
>> Lu Baolu
>>
>>> Thanks,
>>> Vlastimil
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



Re: [PATCH] megaraid: Fix a sleep-in-atomic bug

2017-05-31 Thread Jia-Ju Bai

On 05/31/2017 06:18 PM, Sumit Saxena wrote:

-Original Message-
From: Jia-Ju Bai [mailto:baijiaju1...@163.com]
Sent: Wednesday, May 31, 2017 8:27 AM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: megaraidlinux@broadcom.com; linux-s...@vger.kernel.org; linux-
ker...@vger.kernel.org; Jia-Ju Bai
Subject: [PATCH] megaraid: Fix a sleep-in-atomic bug

The driver may sleep under a spin lock, and the function call path is:
mraid_mm_attach_buf (acquire the lock by spin_lock_irqsave)
  pci_pool_alloc(GFP_KERNEL) -->  may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai
---
drivers/scsi/megaraid/megaraid_mm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_mm.c
b/drivers/scsi/megaraid/megaraid_mm.c
index 4cf9ed9..c43afb8 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -574,7 +574,7 @@

kioc->pool_index = right_pool;
kioc->free_buf   = 1;
-   kioc->buf_vaddr  = pci_pool_alloc(pool->handle, GFP_KERNEL,
+   kioc->buf_vaddr  = pci_pool_alloc(pool->handle, GFP_ATOMIC,
>buf_paddr);
spin_unlock_irqrestore(>lock, flags);

This is very old driver and reached EOL. Did you face any issue because of
this bug or discover this through code review?
Anyways patch looks good to me.

Acked-by: Sumit Saxena


--
1.7.9.5


Hi,

This bug is found by a static analysis tool and my code review.

Jia-Ju Bai




Re: [PATCH] megaraid: Fix a sleep-in-atomic bug

2017-05-31 Thread Jia-Ju Bai

On 05/31/2017 06:18 PM, Sumit Saxena wrote:

-Original Message-
From: Jia-Ju Bai [mailto:baijiaju1...@163.com]
Sent: Wednesday, May 31, 2017 8:27 AM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: megaraidlinux@broadcom.com; linux-s...@vger.kernel.org; linux-
ker...@vger.kernel.org; Jia-Ju Bai
Subject: [PATCH] megaraid: Fix a sleep-in-atomic bug

The driver may sleep under a spin lock, and the function call path is:
mraid_mm_attach_buf (acquire the lock by spin_lock_irqsave)
  pci_pool_alloc(GFP_KERNEL) -->  may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai
---
drivers/scsi/megaraid/megaraid_mm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_mm.c
b/drivers/scsi/megaraid/megaraid_mm.c
index 4cf9ed9..c43afb8 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -574,7 +574,7 @@

kioc->pool_index = right_pool;
kioc->free_buf   = 1;
-   kioc->buf_vaddr  = pci_pool_alloc(pool->handle, GFP_KERNEL,
+   kioc->buf_vaddr  = pci_pool_alloc(pool->handle, GFP_ATOMIC,
>buf_paddr);
spin_unlock_irqrestore(>lock, flags);

This is very old driver and reached EOL. Did you face any issue because of
this bug or discover this through code review?
Anyways patch looks good to me.

Acked-by: Sumit Saxena


--
1.7.9.5


Hi,

This bug is found by a static analysis tool and my code review.

Jia-Ju Bai




Re: [v3 0/9] parallelized "struct page" zeroing

2017-05-31 Thread Pasha Tatashin

OK, so why cannot we make zero_struct_page 8x 8B stores, other arches
would do memset. You said it would be slower but would that be
measurable? I am sorry to be so persistent here but I would be really
happier if this didn't depend on the deferred initialization. If this is
absolutely a no-go then I can live with that of course.


Hi Michal,

This is actually a very good idea. I just did some measurements, and it 
looks like performance is very good.


Here is data from SPARC-M7 with 3312G memory with single thread performance:

Current:
memset() in memblock allocator takes: 8.83s
__init_single_page() take: 8.63s

Option 1:
memset() in __init_single_page() takes: 61.09s (as we discussed because 
of membar overhead, memset should really be optimized to do STBI only 
when size is 1 page or bigger).


Option 2:

8 stores (stx) in __init_single_page(): 8.525s!

So, even for single thread performance we can double the initialization 
speed of "struct page" on SPARC by removing memset() from memblock, and 
using 8 stx in __init_single_page(). It appears we never miss L1 in 
__init_single_page() after the initial 8 stx.


I will update patches with memset() on other platforms, and stx on SPARC.

My experimental code looks like this:

static void __meminit __init_single_page(struct page *page, unsigned 
long pfn, unsigned long zone, int nid)

{
__asm__ __volatile__(
"stx%%g0, [%0 + 0x00]\n"
"stx%%g0, [%0 + 0x08]\n"
"stx%%g0, [%0 + 0x10]\n"
"stx%%g0, [%0 + 0x18]\n"
"stx%%g0, [%0 + 0x20]\n"
"stx%%g0, [%0 + 0x28]\n"
"stx%%g0, [%0 + 0x30]\n"
"stx%%g0, [%0 + 0x38]\n"
:
:"r"(page));
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
page_cpupid_reset_last(page);

INIT_LIST_HEAD(>lru);
#ifdef WANT_PAGE_VIRTUAL
/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn << PAGE_SHIFT));
#endif
}

Thank you,
Pasha


Re: [v3 0/9] parallelized "struct page" zeroing

2017-05-31 Thread Pasha Tatashin

OK, so why cannot we make zero_struct_page 8x 8B stores, other arches
would do memset. You said it would be slower but would that be
measurable? I am sorry to be so persistent here but I would be really
happier if this didn't depend on the deferred initialization. If this is
absolutely a no-go then I can live with that of course.


Hi Michal,

This is actually a very good idea. I just did some measurements, and it 
looks like performance is very good.


Here is data from SPARC-M7 with 3312G memory with single thread performance:

Current:
memset() in memblock allocator takes: 8.83s
__init_single_page() take: 8.63s

Option 1:
memset() in __init_single_page() takes: 61.09s (as we discussed because 
of membar overhead, memset should really be optimized to do STBI only 
when size is 1 page or bigger).


Option 2:

8 stores (stx) in __init_single_page(): 8.525s!

So, even for single thread performance we can double the initialization 
speed of "struct page" on SPARC by removing memset() from memblock, and 
using 8 stx in __init_single_page(). It appears we never miss L1 in 
__init_single_page() after the initial 8 stx.


I will update patches with memset() on other platforms, and stx on SPARC.

My experimental code looks like this:

static void __meminit __init_single_page(struct page *page, unsigned 
long pfn, unsigned long zone, int nid)

{
__asm__ __volatile__(
"stx%%g0, [%0 + 0x00]\n"
"stx%%g0, [%0 + 0x08]\n"
"stx%%g0, [%0 + 0x10]\n"
"stx%%g0, [%0 + 0x18]\n"
"stx%%g0, [%0 + 0x20]\n"
"stx%%g0, [%0 + 0x28]\n"
"stx%%g0, [%0 + 0x30]\n"
"stx%%g0, [%0 + 0x38]\n"
:
:"r"(page));
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
page_cpupid_reset_last(page);

INIT_LIST_HEAD(>lru);
#ifdef WANT_PAGE_VIRTUAL
/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn << PAGE_SHIFT));
#endif
}

Thank you,
Pasha


Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

2017-05-31 Thread Lu Baolu
Hi,

On 05/31/2017 02:24 PM, Steven Rostedt wrote:
> On Wed, 31 May 2017 11:27:19 +0800
> Lu Baolu  wrote:
>
>   
 +
 +#define XDBC_TRACE
 +#ifdef XDBC_TRACE
 +#define   xdbc_trace  trace_printk  
>>> Did you forget to remove the #define XDBC_TRACE?
>>>
>>> Enabling this driver brings the "trace_printk() being used.
>>> Allocating extra memory. This means that this is a DEBUG kernel and
>>> it is unsafe for production use." message in 4.12-rcX dmesg.  
>> This feature is only for a DEBUG kernel, should not be enabled for
>> any production kernel. This was the reason I enabled trace_printk()
>> by default.
> Yes, it is perfectly fine to use trace_printk() for debug only configs.
> But if if you have it there and it is helpful to debug something that
> happens in a production system, you may want to look into creating a
> real tracepoint for the locations.

Yes. Good suggestion. I will try this.

Thank you!

Best regards,
Lu Baolu

>
> -- Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

2017-05-31 Thread Lu Baolu
Hi,

On 05/31/2017 02:24 PM, Steven Rostedt wrote:
> On Wed, 31 May 2017 11:27:19 +0800
> Lu Baolu  wrote:
>
>   
 +
 +#define XDBC_TRACE
 +#ifdef XDBC_TRACE
 +#define   xdbc_trace  trace_printk  
>>> Did you forget to remove the #define XDBC_TRACE?
>>>
>>> Enabling this driver brings the "trace_printk() being used.
>>> Allocating extra memory. This means that this is a DEBUG kernel and
>>> it is unsafe for production use." message in 4.12-rcX dmesg.  
>> This feature is only for a DEBUG kernel, should not be enabled for
>> any production kernel. This was the reason I enabled trace_printk()
>> by default.
> Yes, it is perfectly fine to use trace_printk() for debug only configs.
> But if if you have it there and it is helpful to debug something that
> happens in a production system, you may want to look into creating a
> real tracepoint for the locations.

Yes. Good suggestion. I will try this.

Thank you!

Best regards,
Lu Baolu

>
> -- Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



[RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Tobin C. Harding
Driver ks7010 does not currently have a maintainer.

Add maintainers entry for ks7010.

Signed-off-by: Tobin C. Harding 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e98464..75250ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
 F: drivers/auxdisplay/ks0108.c
 F: include/linux/ks0108.h
 
+KS7010 KEYSTREAM DRIVER
+M:  Tobin Harding 
+L:  driverdev-de...@linuxdriverproject.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
+S:  Maintained
+F:  drivers/staging/ks7010/
+
 L3MDEV
 M: David Ahern 
 L: net...@vger.kernel.org
-- 
2.7.4



[RFC 3/3] MAINTAINERS: add maintainer entry for ks7010

2017-05-31 Thread Tobin C. Harding
Driver ks7010 does not currently have a maintainer.

Add maintainers entry for ks7010.

Signed-off-by: Tobin C. Harding 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e98464..75250ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7429,6 +7429,13 @@ F:   Documentation/auxdisplay/ks0108
 F: drivers/auxdisplay/ks0108.c
 F: include/linux/ks0108.h
 
+KS7010 KEYSTREAM DRIVER
+M:  Tobin Harding 
+L:  driverdev-de...@linuxdriverproject.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
+S:  Maintained
+F:  drivers/staging/ks7010/
+
 L3MDEV
 M: David Ahern 
 L: net...@vger.kernel.org
-- 
2.7.4



[RFC 2/3] staging: ks7010: add cfg80211 files

2017-05-31 Thread Tobin C. Harding
We are in the process of re-writing the current WEXT driver to use the
cfg80211 configuration API. Currently driver root directory is
empty. First step is to implement all the firmware interface in a
single layer of abstraction, Firmware Interface Layer (FIL). We can
add a skeleton implementation for most of the rest of the driver at
the same time.

Add cfg80211 driver skeleton. Implement FIL.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/Makefile|6 +
 drivers/staging/ks7010/README.rst  |   73 ++
 drivers/staging/ks7010/TODO.rst|   17 +
 drivers/staging/ks7010/cfg80211.c  |   45 ++
 drivers/staging/ks7010/cfg80211.h  |9 +
 drivers/staging/ks7010/common.h|   10 +
 drivers/staging/ks7010/eap.h   |   36 +
 drivers/staging/ks7010/fil.c   | 1294 
 drivers/staging/ks7010/fil.h   |  527 +++
 drivers/staging/ks7010/fil_types.h |  845 +++
 drivers/staging/ks7010/hif.c   |  104 +++
 drivers/staging/ks7010/hif.h   |   23 +
 drivers/staging/ks7010/ks7010.h|   94 +++
 drivers/staging/ks7010/main.c  |  122 
 drivers/staging/ks7010/sdio.c  |  399 +++
 drivers/staging/ks7010/sdio.h  |   86 +++
 drivers/staging/ks7010/tx.c|   29 +
 17 files changed, 3719 insertions(+)
 create mode 100644 drivers/staging/ks7010/README.rst
 create mode 100644 drivers/staging/ks7010/TODO.rst
 create mode 100644 drivers/staging/ks7010/cfg80211.c
 create mode 100644 drivers/staging/ks7010/cfg80211.h
 create mode 100644 drivers/staging/ks7010/common.h
 create mode 100644 drivers/staging/ks7010/eap.h
 create mode 100644 drivers/staging/ks7010/fil.c
 create mode 100644 drivers/staging/ks7010/fil.h
 create mode 100644 drivers/staging/ks7010/fil_types.h
 create mode 100644 drivers/staging/ks7010/hif.c
 create mode 100644 drivers/staging/ks7010/hif.h
 create mode 100644 drivers/staging/ks7010/ks7010.h
 create mode 100644 drivers/staging/ks7010/main.c
 create mode 100644 drivers/staging/ks7010/sdio.c
 create mode 100644 drivers/staging/ks7010/sdio.h
 create mode 100644 drivers/staging/ks7010/tx.c

diff --git a/drivers/staging/ks7010/Makefile b/drivers/staging/ks7010/Makefile
index f58cf9a..29c46db 100644
--- a/drivers/staging/ks7010/Makefile
+++ b/drivers/staging/ks7010/Makefile
@@ -1 +1,7 @@
 obj-$(CONFIG_KS7010) += ks7010.o
+ks7010-y+= main.o
+ks7010-y+= tx.o
+ks7010-y+= sdio.o
+ks7010-y+= cfg80211.o
+ks7010-y+= fil.o
+ks7010-y+= hif.o
diff --git a/drivers/staging/ks7010/README.rst 
b/drivers/staging/ks7010/README.rst
new file mode 100644
index 000..5ce54f9
--- /dev/null
+++ b/drivers/staging/ks7010/README.rst
@@ -0,0 +1,73 @@
+=
+Key Stream SDIO Device Driver
+=
+
+Current Status
+--
+
+Firmware Interface Layer only.
+Skeleton implementation in all other files.
+
+Description
+---
+
+Driver conversion from WEXT interface to cfg80211 API.
+
+The current KeyStream SDIO wireless driver (drivers/staging/ks7010)
+implements the WEXT interface.
+
+This driver is based on source code from the Ben Nanonote extra repository [1]
+which is based on the original v007 release from Renesas [2].
+
+[1] 
http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/ks7010/src
+[2] http://downloads.qi-hardware.com/software/ks7010_sdio_v007.tar.bz2
+
+Extensive refactoring has been done to the driver whilst in staging
+and the current mainline tip is untested.
+
+WEXT driver files :-
+ - ks7010_sdio.[ch]- SDIO code.
+ - ks_hostif.[ch]  - Device interface.
+ - ks_wlan_net.c   - WEXT interface.
+ - mic.[ch]- Custom Michael MIC implementation.
+ - eap_packet.h- EAP headers.
+ - ks_wlan_ioctl.h - WEXT IOCTL.
+
+cfg80211 driver files :-
+ - main.c  - Main driver file (net_device_ops etc).
+ - ks7010.h- Main driver header file.
+ - common.h- Constant definitions and forward declarations.
+ - eap.h   - EAPOL structure descriptions.
+ - sdio.[ch]   - SDIO code.
+ - fil.[ch]- Firmware Interface Layer.
+ - fil_types.h - Internal FIL types.
+ - hif.[ch]- Host Interface Layer.
+ - cfg80211.c  - cfg80211 API implementation.
+ - tx.c- Transmit path functions.
+
+cfg80211 driver files to do :-
+ - mic.[ch]- Interface to the kernel Michael MIC implementation.
+ - rx.c- Recive path functions.
+
+Other Information
+=
+
+Hardware
+
+https://wikidevi.com/wiki/Spectec_SDW-821_(KeyStream)
+https://wikidevi.com/wiki/Spectec_SDW-823
+
+Kernel Config
+-
+http://cateee.net/lkddb/web-lkddb/KS7010.html
+
+also enable
+ - MMC_DEBUG
+
+Testing
+---
+http://elinux.org/Tests:SDIO-KS7010
+
+Writing SDIO Linux Drivers

[RFC 2/3] staging: ks7010: add cfg80211 files

2017-05-31 Thread Tobin C. Harding
We are in the process of re-writing the current WEXT driver to use the
cfg80211 configuration API. Currently driver root directory is
empty. First step is to implement all the firmware interface in a
single layer of abstraction, Firmware Interface Layer (FIL). We can
add a skeleton implementation for most of the rest of the driver at
the same time.

Add cfg80211 driver skeleton. Implement FIL.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/Makefile|6 +
 drivers/staging/ks7010/README.rst  |   73 ++
 drivers/staging/ks7010/TODO.rst|   17 +
 drivers/staging/ks7010/cfg80211.c  |   45 ++
 drivers/staging/ks7010/cfg80211.h  |9 +
 drivers/staging/ks7010/common.h|   10 +
 drivers/staging/ks7010/eap.h   |   36 +
 drivers/staging/ks7010/fil.c   | 1294 
 drivers/staging/ks7010/fil.h   |  527 +++
 drivers/staging/ks7010/fil_types.h |  845 +++
 drivers/staging/ks7010/hif.c   |  104 +++
 drivers/staging/ks7010/hif.h   |   23 +
 drivers/staging/ks7010/ks7010.h|   94 +++
 drivers/staging/ks7010/main.c  |  122 
 drivers/staging/ks7010/sdio.c  |  399 +++
 drivers/staging/ks7010/sdio.h  |   86 +++
 drivers/staging/ks7010/tx.c|   29 +
 17 files changed, 3719 insertions(+)
 create mode 100644 drivers/staging/ks7010/README.rst
 create mode 100644 drivers/staging/ks7010/TODO.rst
 create mode 100644 drivers/staging/ks7010/cfg80211.c
 create mode 100644 drivers/staging/ks7010/cfg80211.h
 create mode 100644 drivers/staging/ks7010/common.h
 create mode 100644 drivers/staging/ks7010/eap.h
 create mode 100644 drivers/staging/ks7010/fil.c
 create mode 100644 drivers/staging/ks7010/fil.h
 create mode 100644 drivers/staging/ks7010/fil_types.h
 create mode 100644 drivers/staging/ks7010/hif.c
 create mode 100644 drivers/staging/ks7010/hif.h
 create mode 100644 drivers/staging/ks7010/ks7010.h
 create mode 100644 drivers/staging/ks7010/main.c
 create mode 100644 drivers/staging/ks7010/sdio.c
 create mode 100644 drivers/staging/ks7010/sdio.h
 create mode 100644 drivers/staging/ks7010/tx.c

diff --git a/drivers/staging/ks7010/Makefile b/drivers/staging/ks7010/Makefile
index f58cf9a..29c46db 100644
--- a/drivers/staging/ks7010/Makefile
+++ b/drivers/staging/ks7010/Makefile
@@ -1 +1,7 @@
 obj-$(CONFIG_KS7010) += ks7010.o
+ks7010-y+= main.o
+ks7010-y+= tx.o
+ks7010-y+= sdio.o
+ks7010-y+= cfg80211.o
+ks7010-y+= fil.o
+ks7010-y+= hif.o
diff --git a/drivers/staging/ks7010/README.rst 
b/drivers/staging/ks7010/README.rst
new file mode 100644
index 000..5ce54f9
--- /dev/null
+++ b/drivers/staging/ks7010/README.rst
@@ -0,0 +1,73 @@
+=
+Key Stream SDIO Device Driver
+=
+
+Current Status
+--
+
+Firmware Interface Layer only.
+Skeleton implementation in all other files.
+
+Description
+---
+
+Driver conversion from WEXT interface to cfg80211 API.
+
+The current KeyStream SDIO wireless driver (drivers/staging/ks7010)
+implements the WEXT interface.
+
+This driver is based on source code from the Ben Nanonote extra repository [1]
+which is based on the original v007 release from Renesas [2].
+
+[1] 
http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/ks7010/src
+[2] http://downloads.qi-hardware.com/software/ks7010_sdio_v007.tar.bz2
+
+Extensive refactoring has been done to the driver whilst in staging
+and the current mainline tip is untested.
+
+WEXT driver files :-
+ - ks7010_sdio.[ch]- SDIO code.
+ - ks_hostif.[ch]  - Device interface.
+ - ks_wlan_net.c   - WEXT interface.
+ - mic.[ch]- Custom Michael MIC implementation.
+ - eap_packet.h- EAP headers.
+ - ks_wlan_ioctl.h - WEXT IOCTL.
+
+cfg80211 driver files :-
+ - main.c  - Main driver file (net_device_ops etc).
+ - ks7010.h- Main driver header file.
+ - common.h- Constant definitions and forward declarations.
+ - eap.h   - EAPOL structure descriptions.
+ - sdio.[ch]   - SDIO code.
+ - fil.[ch]- Firmware Interface Layer.
+ - fil_types.h - Internal FIL types.
+ - hif.[ch]- Host Interface Layer.
+ - cfg80211.c  - cfg80211 API implementation.
+ - tx.c- Transmit path functions.
+
+cfg80211 driver files to do :-
+ - mic.[ch]- Interface to the kernel Michael MIC implementation.
+ - rx.c- Recive path functions.
+
+Other Information
+=
+
+Hardware
+
+https://wikidevi.com/wiki/Spectec_SDW-821_(KeyStream)
+https://wikidevi.com/wiki/Spectec_SDW-823
+
+Kernel Config
+-
+http://cateee.net/lkddb/web-lkddb/KS7010.html
+
+also enable
+ - MMC_DEBUG
+
+Testing
+---
+http://elinux.org/Tests:SDIO-KS7010
+
+Writing SDIO Linux Drivers
+--

  1   2   3   4   5   6   7   8   9   10   >