Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume

[Andrey Ryabinin]

On 12/02/2016 08:42 PM, Josh Poimboeuf wrote:
> Resuming from a suspend operation is showing a KASAN false positive
> warning:
> 
>   BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at 
> addr 8803867d7878
>   Read of size 8 by task pm-suspend/7774
>   page:ea000e19f5c0 count:0 mapcount:0 mapping:  (null) index:0x0
>   flags: 0x200()
>   page dumped because: kasan: bad access detected
>   CPU: 0 PID: 7774 Comm: pm-suspend Tainted: GB   4.9.0-rc7+ #8
>   Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS 
> F5 03/07/2016
>   Call Trace:
> dump_stack+0x63/0x82
> kasan_report_error+0x4b4/0x4e0
> ? acpi_hw_read_port+0xd0/0x1ea
> ? kfree_const+0x22/0x30
> ? acpi_hw_validate_io_request+0x1a6/0x1a6
> __asan_report_load8_noabort+0x61/0x70
> ? unwind_get_return_address+0x11d/0x130
> unwind_get_return_address+0x11d/0x130
> ? unwind_next_frame+0x97/0xf0
> __save_stack_trace+0x92/0x100
> save_stack_trace+0x1b/0x20
> save_stack+0x46/0xd0
> ? save_stack_trace+0x1b/0x20
> ? save_stack+0x46/0xd0
> ? kasan_kmalloc+0xad/0xe0
> ? kasan_slab_alloc+0x12/0x20
> ? acpi_hw_read+0x2b6/0x3aa
> ? acpi_hw_validate_register+0x20b/0x20b
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? memcpy+0x45/0x50
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? kasan_unpoison_shadow+0x36/0x50
> kasan_kmalloc+0xad/0xe0
> kasan_slab_alloc+0x12/0x20
> kmem_cache_alloc_trace+0xbc/0x1e0
> ? acpi_get_sleep_type_data+0x9a/0x578
> acpi_get_sleep_type_data+0x9a/0x578
> acpi_hw_legacy_wake_prep+0x88/0x22c
> ? acpi_hw_legacy_sleep+0x3c7/0x3c7
> ? acpi_write_bit_register+0x28d/0x2d3
> ? acpi_read_bit_register+0x19b/0x19b
> acpi_hw_sleep_dispatch+0xb5/0xba
> acpi_leave_sleep_state_prep+0x17/0x19
> acpi_suspend_enter+0x154/0x1e0
> ? trace_suspend_resume+0xe8/0xe8
> suspend_devices_and_enter+0xb09/0xdb0
> ? printk+0xa8/0xd8
> ? arch_suspend_enable_irqs+0x20/0x20
> ? try_to_freeze_tasks+0x295/0x600
> pm_suspend+0x6c9/0x780
> ? finish_wait+0x1f0/0x1f0
> ? suspend_devices_and_enter+0xdb0/0xdb0
> state_store+0xa2/0x120
> ? kobj_attr_show+0x60/0x60
> kobj_attr_store+0x36/0x70
> sysfs_kf_write+0x131/0x200
> kernfs_fop_write+0x295/0x3f0
> __vfs_write+0xef/0x760
> ? handle_mm_fault+0x1346/0x35e0
> ? do_iter_readv_writev+0x660/0x660
> ? __pmd_alloc+0x310/0x310
> ? do_lock_file_wait+0x1e0/0x1e0
> ? apparmor_file_permission+0x18/0x20
> ? security_file_permission+0x73/0x1c0
> ? rw_verify_area+0xbd/0x2b0
> vfs_write+0x149/0x4a0
> SyS_write+0xd9/0x1c0
> ? SyS_read+0x1c0/0x1c0
> entry_SYSCALL_64_fastpath+0x1e/0xad
>   Memory state around the buggy address:
>8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   >8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
>   ^
>8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00
> 
> KASAN instrumentation poisons the stack when entering a function and
> unpoisons it when exiting the function.  However, in the suspend path,
> some functions never return, so their stack never gets unpoisoned,
> resulting in stale KASAN shadow data which can cause later false
> positive warnings like the one above.
> 
> Reported-by: Scott Bauer 
> Signed-off-by: Josh Poimboeuf 

Acked-by: Andrey Ryabinin 

Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume

[Andrey Ryabinin]

On 12/02/2016 08:42 PM, Josh Poimboeuf wrote:
> Resuming from a suspend operation is showing a KASAN false positive
> warning:
> 
>   BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at 
> addr 8803867d7878
>   Read of size 8 by task pm-suspend/7774
>   page:ea000e19f5c0 count:0 mapcount:0 mapping:  (null) index:0x0
>   flags: 0x200()
>   page dumped because: kasan: bad access detected
>   CPU: 0 PID: 7774 Comm: pm-suspend Tainted: GB   4.9.0-rc7+ #8
>   Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS 
> F5 03/07/2016
>   Call Trace:
> dump_stack+0x63/0x82
> kasan_report_error+0x4b4/0x4e0
> ? acpi_hw_read_port+0xd0/0x1ea
> ? kfree_const+0x22/0x30
> ? acpi_hw_validate_io_request+0x1a6/0x1a6
> __asan_report_load8_noabort+0x61/0x70
> ? unwind_get_return_address+0x11d/0x130
> unwind_get_return_address+0x11d/0x130
> ? unwind_next_frame+0x97/0xf0
> __save_stack_trace+0x92/0x100
> save_stack_trace+0x1b/0x20
> save_stack+0x46/0xd0
> ? save_stack_trace+0x1b/0x20
> ? save_stack+0x46/0xd0
> ? kasan_kmalloc+0xad/0xe0
> ? kasan_slab_alloc+0x12/0x20
> ? acpi_hw_read+0x2b6/0x3aa
> ? acpi_hw_validate_register+0x20b/0x20b
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? memcpy+0x45/0x50
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? kasan_unpoison_shadow+0x36/0x50
> kasan_kmalloc+0xad/0xe0
> kasan_slab_alloc+0x12/0x20
> kmem_cache_alloc_trace+0xbc/0x1e0
> ? acpi_get_sleep_type_data+0x9a/0x578
> acpi_get_sleep_type_data+0x9a/0x578
> acpi_hw_legacy_wake_prep+0x88/0x22c
> ? acpi_hw_legacy_sleep+0x3c7/0x3c7
> ? acpi_write_bit_register+0x28d/0x2d3
> ? acpi_read_bit_register+0x19b/0x19b
> acpi_hw_sleep_dispatch+0xb5/0xba
> acpi_leave_sleep_state_prep+0x17/0x19
> acpi_suspend_enter+0x154/0x1e0
> ? trace_suspend_resume+0xe8/0xe8
> suspend_devices_and_enter+0xb09/0xdb0
> ? printk+0xa8/0xd8
> ? arch_suspend_enable_irqs+0x20/0x20
> ? try_to_freeze_tasks+0x295/0x600
> pm_suspend+0x6c9/0x780
> ? finish_wait+0x1f0/0x1f0
> ? suspend_devices_and_enter+0xdb0/0xdb0
> state_store+0xa2/0x120
> ? kobj_attr_show+0x60/0x60
> kobj_attr_store+0x36/0x70
> sysfs_kf_write+0x131/0x200
> kernfs_fop_write+0x295/0x3f0
> __vfs_write+0xef/0x760
> ? handle_mm_fault+0x1346/0x35e0
> ? do_iter_readv_writev+0x660/0x660
> ? __pmd_alloc+0x310/0x310
> ? do_lock_file_wait+0x1e0/0x1e0
> ? apparmor_file_permission+0x18/0x20
> ? security_file_permission+0x73/0x1c0
> ? rw_verify_area+0xbd/0x2b0
> vfs_write+0x149/0x4a0
> SyS_write+0xd9/0x1c0
> ? SyS_read+0x1c0/0x1c0
> entry_SYSCALL_64_fastpath+0x1e/0xad
>   Memory state around the buggy address:
>8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   >8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
>   ^
>8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00
> 
> KASAN instrumentation poisons the stack when entering a function and
> unpoisons it when exiting the function.  However, in the suspend path,
> some functions never return, so their stack never gets unpoisoned,
> resulting in stale KASAN shadow data which can cause later false
> positive warnings like the one above.
> 
> Reported-by: Scott Bauer 
> Signed-off-by: Josh Poimboeuf 

Acked-by: Andrey Ryabinin 

Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

[kbuild test robot]

Hi Michael,

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.9-rc7]
[cannot apply to next-20161202]
[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/Michael-Ellerman/lkdtm-Add-tests-for-LIST_POISON-and-ZERO_SIZE_PTR/20161203-124958
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/cache.h:4:0,
from include/linux/printk.h:8,
from include/linux/kernel.h:13,
from drivers/misc/lkdtm.h:6,
from drivers/misc/lkdtm_bugs.c:7:
   drivers/misc/lkdtm_bugs.c: In function 'test_poison_ptr':
>> drivers/misc/lkdtm_bugs.c:160:20: error: 'CONFIG_DEFAULT_MMAP_MIN_ADDR' 
>> undeclared (first use in this function)
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~
   drivers/misc/lkdtm_bugs.c:160:20: note: each undeclared identifier is 
reported only once for each function it appears in
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~

vim +/CONFIG_DEFAULT_MMAP_MIN_ADDR +160 drivers/misc/lkdtm_bugs.c

 1  /*
 2   * This is for all the tests related to logic bugs (e.g. bad 
dereferences,
 3   * bad alignment, bad loops, bad locking, bad scheduling, deep stacks, 
and
 4   * lockups) along with other things that don't fit well into existing 
LKDTM
 5   * test source files.
 6   */
   > 7  #include "lkdtm.h"
 8  #include 
 9  #include 
10  #include 
11  #include 
12  
13  /*
14   * Make sure our attempts to over run the kernel stack doesn't trigger
15   * a compiler warning when CONFIG_FRAME_WARN is set. Then make sure we
16   * recurse past the end of THREAD_SIZE by default.
17   */
18  #if defined(CONFIG_FRAME_WARN) && (CONFIG_FRAME_WARN > 0)
19  #define REC_STACK_SIZE (CONFIG_FRAME_WARN / 2)
20  #else
21  #define REC_STACK_SIZE (THREAD_SIZE / 8)
22  #endif
23  #define REC_NUM_DEFAULT ((THREAD_SIZE / REC_STACK_SIZE) * 2)
24  
25  static int recur_count = REC_NUM_DEFAULT;
26  
27  static DEFINE_SPINLOCK(lock_me_up);
28  
29  static int recursive_loop(int remaining)
30  {
31  char buf[REC_STACK_SIZE];
32  
33  /* Make sure compiler does not optimize this away. */
34  memset(buf, (remaining & 0xff) | 0x1, REC_STACK_SIZE);
35  if (!remaining)
36  return 0;
37  else
38  return recursive_loop(remaining - 1);
39  }
40  
41  /* If the depth is negative, use the default, otherwise keep parameter. 
*/
42  void __init lkdtm_bugs_init(int *recur_param)
43  {
44  if (*recur_param < 0)
45  *recur_param = recur_count;
46  else
47  recur_count = *recur_param;
48  }
49  
50  void lkdtm_PANIC(void)
51  {
52  panic("dumptest");
53  }
54  
55  void lkdtm_BUG(void)
56  {
57  BUG();
58  }
59  
60  void lk

Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

[kbuild test robot]

Hi Michael,

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.9-rc7]
[cannot apply to next-20161202]
[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/Michael-Ellerman/lkdtm-Add-tests-for-LIST_POISON-and-ZERO_SIZE_PTR/20161203-124958
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/cache.h:4:0,
from include/linux/printk.h:8,
from include/linux/kernel.h:13,
from drivers/misc/lkdtm.h:6,
from drivers/misc/lkdtm_bugs.c:7:
   drivers/misc/lkdtm_bugs.c: In function 'test_poison_ptr':
>> drivers/misc/lkdtm_bugs.c:160:20: error: 'CONFIG_DEFAULT_MMAP_MIN_ADDR' 
>> undeclared (first use in this function)
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~
   drivers/misc/lkdtm_bugs.c:160:20: note: each undeclared identifier is 
reported only once for each function it appears in
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~

vim +/CONFIG_DEFAULT_MMAP_MIN_ADDR +160 drivers/misc/lkdtm_bugs.c

 1  /*
 2   * This is for all the tests related to logic bugs (e.g. bad 
dereferences,
 3   * bad alignment, bad loops, bad locking, bad scheduling, deep stacks, 
and
 4   * lockups) along with other things that don't fit well into existing 
LKDTM
 5   * test source files.
 6   */
   > 7  #include "lkdtm.h"
 8  #include 
 9  #include 
10  #include 
11  #include 
12  
13  /*
14   * Make sure our attempts to over run the kernel stack doesn't trigger
15   * a compiler warning when CONFIG_FRAME_WARN is set. Then make sure we
16   * recurse past the end of THREAD_SIZE by default.
17   */
18  #if defined(CONFIG_FRAME_WARN) && (CONFIG_FRAME_WARN > 0)
19  #define REC_STACK_SIZE (CONFIG_FRAME_WARN / 2)
20  #else
21  #define REC_STACK_SIZE (THREAD_SIZE / 8)
22  #endif
23  #define REC_NUM_DEFAULT ((THREAD_SIZE / REC_STACK_SIZE) * 2)
24  
25  static int recur_count = REC_NUM_DEFAULT;
26  
27  static DEFINE_SPINLOCK(lock_me_up);
28  
29  static int recursive_loop(int remaining)
30  {
31  char buf[REC_STACK_SIZE];
32  
33  /* Make sure compiler does not optimize this away. */
34  memset(buf, (remaining & 0xff) | 0x1, REC_STACK_SIZE);
35  if (!remaining)
36  return 0;
37  else
38  return recursive_loop(remaining - 1);
39  }
40  
41  /* If the depth is negative, use the default, otherwise keep parameter. 
*/
42  void __init lkdtm_bugs_init(int *recur_param)
43  {
44  if (*recur_param < 0)
45  *recur_param = recur_count;
46  else
47  recur_count = *recur_param;
48  }
49  
50  void lkdtm_PANIC(void)
51  {
52  panic("dumptest");
53  }
54  
55  void lkdtm_BUG(void)
56  {
57  BUG();
58  }
59  
60  void lk

3.5%LOAN OFFER

[DIRECT LOANS.]

APPLY 3.5%LOAN.pdf
Description: Adobe PDF document


Application Form.pdf
Description: Adobe PDF document

3.5%LOAN OFFER

[DIRECT LOANS.]

APPLY 3.5%LOAN.pdf
Description: Adobe PDF document


Application Form.pdf
Description: Adobe PDF document

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-s1-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   mm/built-in.o: In function `zs_unregister_cpu_notifier':
>> zsmalloc.c:(.text.unlikely+0xc7e): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
   nmi_timer_int.c:(.text+0x1c7d): undefined reference to 
`__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2319): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-s1-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   mm/built-in.o: In function `zs_unregister_cpu_notifier':
>> zsmalloc.c:(.text.unlikely+0xc7e): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
   nmi_timer_int.c:(.text+0x1c7d): undefined reference to 
`__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2319): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

[x86/asm] cdfac81296: kernel_BUG_at_arch/x86/kernel/alternative.c

[kernel test robot]

FYI, we noticed the following commit:

commit: cdfac8129693572ef91b9e7022d6ae07f1c8cc38 ("x86/asm: Rewrite sync_core() 
to use IRET-to-self")
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/boot

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 256M

caused below changes:


+-+++
| | 535a025bb9 | cdfac81296 |
+-+++
| boot_successes  | 6  | 0  |
| boot_failures   | 0  | 4  |
| kernel_BUG_at_arch/x86/kernel/alternative.c | 0  | 4  |
| invalid_opcode:#[##]SMP | 0  | 4  |
| EIP_is_at_apply_alternatives| 0  | 4  |
| Kernel_panic-not_syncing:Fatal_exception| 0  | 4  |
+-+++



[0.429066] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.447516] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.455310] [ cut here ]
[0.459612] kernel BUG at arch/x86/kernel/alternative.c:386!
[0.465842] invalid opcode:  [#1] SMP
[0.469305] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.9.0-rc7-00027-gcdfac81 #1
[0.476137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.483617] task: c84cb040 task.stack: c84c4000
[0.486773] EIP: 0060:[] EFLAGS: 00210246 CPU: 0
[0.490857] EIP is at apply_alternatives+0xa5/0x7e3
[0.494426] EAX: d83b0ff0 EBX: c84abb75 ECX:  EDX: 00ae
[0.499509] ESI: 0004 EDI: c84c5eb6 EBP: c84c5fbc ESP: c84c5e90
[0.503883]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[0.508031] CR0: 80050033 CR2:  CR3: 089df000 CR4: 0690
[0.512150] Stack:
[0.514412]  c69f2b7c 0003 0004 fbfb 0ff0ae0f 0089 c84abb81 
d83b6984
[0.529825]  e58900e8 cf49340f c84c5eec 0002 c888dba0 c84c5f74 c84c5ed4 
c683cc1e
[0.537271]  c84c5f00 c84c5f14 c683d4f7 c84c5f00 002b c84c5f60 0143 
03c0003f
[0.545924] Call Trace:
[0.548885]  [] ? __kmem_cache_create+0x37d/0x5c7
[0.552895]  [] ? __cpuid+0x1a/0x2e
[0.556362]  [] ? cpuid4_cache_lookup_regs+0x4ad/0x52f


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.9.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y

[x86/asm] cdfac81296: kernel_BUG_at_arch/x86/kernel/alternative.c

[kernel test robot]

FYI, we noticed the following commit:

commit: cdfac8129693572ef91b9e7022d6ae07f1c8cc38 ("x86/asm: Rewrite sync_core() 
to use IRET-to-self")
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/boot

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 256M

caused below changes:


+-+++
| | 535a025bb9 | cdfac81296 |
+-+++
| boot_successes  | 6  | 0  |
| boot_failures   | 0  | 4  |
| kernel_BUG_at_arch/x86/kernel/alternative.c | 0  | 4  |
| invalid_opcode:#[##]SMP | 0  | 4  |
| EIP_is_at_apply_alternatives| 0  | 4  |
| Kernel_panic-not_syncing:Fatal_exception| 0  | 4  |
+-+++



[0.429066] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.447516] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.455310] [ cut here ]
[0.459612] kernel BUG at arch/x86/kernel/alternative.c:386!
[0.465842] invalid opcode:  [#1] SMP
[0.469305] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.9.0-rc7-00027-gcdfac81 #1
[0.476137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.483617] task: c84cb040 task.stack: c84c4000
[0.486773] EIP: 0060:[] EFLAGS: 00210246 CPU: 0
[0.490857] EIP is at apply_alternatives+0xa5/0x7e3
[0.494426] EAX: d83b0ff0 EBX: c84abb75 ECX:  EDX: 00ae
[0.499509] ESI: 0004 EDI: c84c5eb6 EBP: c84c5fbc ESP: c84c5e90
[0.503883]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[0.508031] CR0: 80050033 CR2:  CR3: 089df000 CR4: 0690
[0.512150] Stack:
[0.514412]  c69f2b7c 0003 0004 fbfb 0ff0ae0f 0089 c84abb81 
d83b6984
[0.529825]  e58900e8 cf49340f c84c5eec 0002 c888dba0 c84c5f74 c84c5ed4 
c683cc1e
[0.537271]  c84c5f00 c84c5f14 c683d4f7 c84c5f00 002b c84c5f60 0143 
03c0003f
[0.545924] Call Trace:
[0.548885]  [] ? __kmem_cache_create+0x37d/0x5c7
[0.552895]  [] ? __cpuid+0x1a/0x2e
[0.556362]  [] ? cpuid4_cache_lookup_regs+0x4ad/0x52f


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.9.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas  wrote:
>
> On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
> > Hi Bjorn, Duc, Mark,
> >
> > I switched my brain to the on mode and went and read some specs, and a few
> > tables, so here's my 2 cents on this...
> >
> > On 12/01/2016 06:22 PM, Duc Dang wrote:
> > > On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
> > >> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
> >
> > > The SoC provide some number of RC bridges, each with a different base
> > > for some mmio registers. Even if segment is legitimate in MCFG, there
> > > is still a problem if a platform doesn't use the segment ordering
> > > implied by the code. But the PNP0A03 _CRS does have this base address
> > > as the first memory resource, so we could get it from there and not
> > > have hard-coded addresses and implied ording in the quirk code.
> > 
> >  I'm confused.  Doesn't the current code treat every item in PNP0A03
> >  _CRS as a window?  Do you mean the first resource is handled
> >  differently somehow?  The Consumer/Producer bit could allow us to do
> >  this by marking the RC MMIO space as "Consumer", but I didn't think
> >  that strategy was quite working yet.
> >
> > Let's see if I summarized this correctly...
> >
> > 1. The MMIO registers for the host bridge itself need to be described
> >somewhere, especially if we need to find those in a quirk and poke
> >them. Since those registers are very much part of the bridge device,
> >it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> >
> > 2. The address space covering these registers MUST be described as a
> >ResourceConsumer in order to avoid accidentally exposing them as
> >available for use by downstream devices on the PCI bus.
> >
> > 3. The ACPI specification allows for resources of the type "Memory32Fixed".
> >This is a macro that doesn't have the notion of a producer or consumer.
> >HOWEVER various interpretations seem to be that this could/should
> >default to being interpreted as a consumed region.
>
> I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> and FixedIO should all be for consumed resources, not for bridge
> windows, since they don't have the notion of producer.
>
> I'm pretty sure there's x86 firmware in the field that uses these for
> windows, so I think we have to accept that usage, at least on x86.
>
> > 4. At one point, a regression was added to the kernel:
> >
> >63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
> >host bridge itself")
> >
> >Which lead to a series on conversations about what should happen
> >for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
> >
> > 5. This resulted in the following commit reverting point 4:
> >
> >2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
> >available on PCI bus")
> >
> >Which also stated that:
> >
> >"This solution will also ease the way to consolidate ACPI PCI host
> > bridge common code from x86, ia64 and ARM64"
> >
> > End of summary.
> >
> > So it seems that generally there is an aversion to having bridge resources
> > be described in this manner and you would like to require that they be
> > described e.g. using QWordMemory with a ResourceConsumer type?
>
> Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
> descriptors.  In bridge devices on x86, I think we have to treat them as
> producers (windows) because that's how they've been typically used.
>
> > BUT if we were to do that, it would break existing shipping systems since
> > there are quirks out there that use this form to find the base CSR:
> >
> >if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> > fixed32 = _res->data.fixed_memory32;
> > port->csr_base = ioremap(fixed32->address,
> >  fixed32->address_length);
> > return AE_CTRL_TERMINATE;
> > }
>
> I think this is a valid usage of FixedMemory32 in terms of the spec.
> Linux currently handles this as a window if it appears in a PNP0A03
> device because some x86 firmware used it that way.
>
> We might be able to handle it differently on arm64, e.g., by making an
> arm64 version of pci_acpi_root_prepare_resources() that checks for
> IORESOURCE_WINDOW.
>
> > 2. What would happen if we had a difference policy on arm64 for such
> >resources. x86 has an "exception" for accessing the config space
> >using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
> >we can make the rules for a new platform (i.e. actually prescribe
> >exactly what the behavior is, rather than have it not be defined).
> >This is of course terrible in that existing BIOS vendors and so on
> >won't necessarily know this when working on ARM ACPI later on.
>
> > Indeed. And 

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas  wrote:
>
> On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
> > Hi Bjorn, Duc, Mark,
> >
> > I switched my brain to the on mode and went and read some specs, and a few
> > tables, so here's my 2 cents on this...
> >
> > On 12/01/2016 06:22 PM, Duc Dang wrote:
> > > On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
> > >> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
> >
> > > The SoC provide some number of RC bridges, each with a different base
> > > for some mmio registers. Even if segment is legitimate in MCFG, there
> > > is still a problem if a platform doesn't use the segment ordering
> > > implied by the code. But the PNP0A03 _CRS does have this base address
> > > as the first memory resource, so we could get it from there and not
> > > have hard-coded addresses and implied ording in the quirk code.
> > 
> >  I'm confused.  Doesn't the current code treat every item in PNP0A03
> >  _CRS as a window?  Do you mean the first resource is handled
> >  differently somehow?  The Consumer/Producer bit could allow us to do
> >  this by marking the RC MMIO space as "Consumer", but I didn't think
> >  that strategy was quite working yet.
> >
> > Let's see if I summarized this correctly...
> >
> > 1. The MMIO registers for the host bridge itself need to be described
> >somewhere, especially if we need to find those in a quirk and poke
> >them. Since those registers are very much part of the bridge device,
> >it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> >
> > 2. The address space covering these registers MUST be described as a
> >ResourceConsumer in order to avoid accidentally exposing them as
> >available for use by downstream devices on the PCI bus.
> >
> > 3. The ACPI specification allows for resources of the type "Memory32Fixed".
> >This is a macro that doesn't have the notion of a producer or consumer.
> >HOWEVER various interpretations seem to be that this could/should
> >default to being interpreted as a consumed region.
>
> I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> and FixedIO should all be for consumed resources, not for bridge
> windows, since they don't have the notion of producer.
>
> I'm pretty sure there's x86 firmware in the field that uses these for
> windows, so I think we have to accept that usage, at least on x86.
>
> > 4. At one point, a regression was added to the kernel:
> >
> >63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
> >host bridge itself")
> >
> >Which lead to a series on conversations about what should happen
> >for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
> >
> > 5. This resulted in the following commit reverting point 4:
> >
> >2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
> >available on PCI bus")
> >
> >Which also stated that:
> >
> >"This solution will also ease the way to consolidate ACPI PCI host
> > bridge common code from x86, ia64 and ARM64"
> >
> > End of summary.
> >
> > So it seems that generally there is an aversion to having bridge resources
> > be described in this manner and you would like to require that they be
> > described e.g. using QWordMemory with a ResourceConsumer type?
>
> Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
> descriptors.  In bridge devices on x86, I think we have to treat them as
> producers (windows) because that's how they've been typically used.
>
> > BUT if we were to do that, it would break existing shipping systems since
> > there are quirks out there that use this form to find the base CSR:
> >
> >if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> > fixed32 = _res->data.fixed_memory32;
> > port->csr_base = ioremap(fixed32->address,
> >  fixed32->address_length);
> > return AE_CTRL_TERMINATE;
> > }
>
> I think this is a valid usage of FixedMemory32 in terms of the spec.
> Linux currently handles this as a window if it appears in a PNP0A03
> device because some x86 firmware used it that way.
>
> We might be able to handle it differently on arm64, e.g., by making an
> arm64 version of pci_acpi_root_prepare_resources() that checks for
> IORESOURCE_WINDOW.
>
> > 2. What would happen if we had a difference policy on arm64 for such
> >resources. x86 has an "exception" for accessing the config space
> >using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
> >we can make the rules for a new platform (i.e. actually prescribe
> >exactly what the behavior is, rather than have it not be defined).
> >This is of course terrible in that existing BIOS vendors and so on
> >won't necessarily know this when working on ARM ACPI later on.
>
> > Indeed. And in the case of m400, it is currently 

Re: [PATCH] staging: Replaced BUG_ON with warnings

[Allen]

On Sat, Dec 3, 2016 at 12:32 PM, Shilpa Puttegowda  wrote:
> From: Shilpa P 
>
> Don't crash the Kernel for driver errors
>
> Signed-off-by: Shilpa P 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>

Acked-by: Allen Pais 

Re: [PATCH] staging: Replaced BUG_ON with warnings

[Allen]

On Sat, Dec 3, 2016 at 12:32 PM, Shilpa Puttegowda  wrote:
> From: Shilpa P 
>
> Don't crash the Kernel for driver errors
>
> Signed-off-by: Shilpa P 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>

Acked-by: Allen Pais 

[PATCH] staging: Replaced BUG_ON with warnings

[Shilpa Puttegowda]

From: Shilpa P 

Don't crash the Kernel for driver errors

Signed-off-by: Shilpa P 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 4d9bd02..05f5918 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1538,7 +1538,11 @@ static int bcm2048_parse_rt_match_c(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
 
-   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+   if ((index + 2) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return 0;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1561,7 +1565,11 @@ static void bcm2048_parse_rt_match_d(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
 
-   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+   if ((index + 4) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
-- 
1.9.1

[PATCH] staging: Replaced BUG_ON with warnings

[Shilpa Puttegowda]

From: Shilpa P 

Don't crash the Kernel for driver errors

Signed-off-by: Shilpa P 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 4d9bd02..05f5918 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1538,7 +1538,11 @@ static int bcm2048_parse_rt_match_c(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
 
-   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+   if ((index + 2) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return 0;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1561,7 +1565,11 @@ static void bcm2048_parse_rt_match_d(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
 
-   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+   if ((index + 4) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
-- 
1.9.1

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[hpa]

On December 2, 2016 9:49:50 PM PST, Ingo Molnar  wrote:
>
>* Boris Ostrovsky  wrote:
>
>> > It is tricky to do so safely, because at this stage almost nothing
>of the C 
>> > execution environment has been set up.
>
>Yeah - but we do have a fair amount of early C code though.
>
>> I can still give it a try but I'd rather not tie it to this (Xen PVH)
>patch 
>> series. Which would leave me with two options: either keep what this
>patch does, 
>> leaving it as assembly (requires your ack), or have Xen code build
>the pages on 
>> its own.
>
>If you give it a try in a subsequent patch (please Cc: me) then it's OK
>to me:
>
>  Acked-by: Ingo Molnar 
>
>Feel free to carry it in the Xen tree.
>
>Thanks,
>
>   Ingo

It's true that it is now possible to run pre-paging C code.  It would be so 
much better if Xen could simply go though the normal code path like any 
civilized machine.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[hpa]

On December 2, 2016 9:49:50 PM PST, Ingo Molnar  wrote:
>
>* Boris Ostrovsky  wrote:
>
>> > It is tricky to do so safely, because at this stage almost nothing
>of the C 
>> > execution environment has been set up.
>
>Yeah - but we do have a fair amount of early C code though.
>
>> I can still give it a try but I'd rather not tie it to this (Xen PVH)
>patch 
>> series. Which would leave me with two options: either keep what this
>patch does, 
>> leaving it as assembly (requires your ack), or have Xen code build
>the pages on 
>> its own.
>
>If you give it a try in a subsequent patch (please Cc: me) then it's OK
>to me:
>
>  Acked-by: Ingo Molnar 
>
>Feel free to carry it in the Xen tree.
>
>Thanks,
>
>   Ingo

It's true that it is now possible to run pre-paging C code.  It would be so 
much better if Xen could simply go though the normal code path like any 
civilized machine.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH] btrfs: limit async_work allocation and worker func duration

[Maxim Patlasov]

Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |8 
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..29f6252 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,14 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   int thresh = wq->normal->thresh != NO_THRESHOLD ?
+   wq->normal->thresh : num_possible_cpus();
+
+   return atomic_read(>normal->pending) > thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND ||
+   btrfs_workqueue_normal_congested(fs_info->delayed_workers))
return 0;
 
async_work = kmalloc(sizeof(*async_work), GFP_NOFS);

[PATCH] btrfs: limit async_work allocation and worker func duration

[Maxim Patlasov]

Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |8 
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..29f6252 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,14 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   int thresh = wq->normal->thresh != NO_THRESHOLD ?
+   wq->normal->thresh : num_possible_cpus();
+
+   return atomic_read(>normal->pending) > thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND ||
+   btrfs_workqueue_normal_congested(fs_info->delayed_workers))
return 0;
 
async_work = kmalloc(sizeof(*async_work), GFP_NOFS);

[PATCH] Fix style issues in kernel/cpu.c

[Thomas Casey]

This patch fixes style issues in kernel/cpu.c such as wrapping an 80
character line, calling EXPORT_SYMBOL() immediately after a function is
defined, and whitespace and spacing issues.

Signed-off-by: Thomas Casey 
---
 kernel/cpu.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 29de1a9..15a90ba 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -228,7 +228,8 @@ static struct {
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map", 
_hotplug.dep_map),
+   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
+   _hotplug.dep_map),
 #endif
 };
 
@@ -304,7 +305,7 @@ void cpu_hotplug_begin(void)
mutex_lock(_hotplug.lock);
prepare_to_wait(_hotplug.wq, , TASK_UNINTERRUPTIBLE);
if (likely(!atomic_read(_hotplug.refcount)))
-   break;
+   break;
mutex_unlock(_hotplug.lock);
schedule();
}
@@ -353,6 +354,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
 int register_cpu_notifier(struct notifier_block *nb)
 {
int ret;
+
cpu_maps_update_begin();
ret = raw_notifier_chain_register(_chain, nb);
cpu_maps_update_done();
@@ -363,6 +365,7 @@ int __register_cpu_notifier(struct notifier_block *nb)
 {
return raw_notifier_chain_register(_chain, nb);
 }
+EXPORT_SYMBOL(__register_cpu_notifier);
 
 static int __cpu_notify(unsigned long val, unsigned int cpu, int nr_to_call,
int *nr_calls)
@@ -661,7 +664,6 @@ void __init cpuhp_threads_init(void)
 
 #ifdef CONFIG_HOTPLUG_CPU
 EXPORT_SYMBOL(register_cpu_notifier);
-EXPORT_SYMBOL(__register_cpu_notifier);
 void unregister_cpu_notifier(struct notifier_block *nb)
 {
cpu_maps_update_begin();
@@ -1250,7 +1252,7 @@ static struct cpuhp_step cpuhp_bp_states[] = {
.teardown.single= NULL,
},
 #ifdef CONFIG_SMP
-   [CPUHP_CREATE_THREADS]= {
+   [CPUHP_CREATE_THREADS] = {
.name   = "threads:prepare",
.startup.single = smpboot_create_threads,
.teardown.single= NULL,
@@ -1366,7 +1368,8 @@ static struct cpuhp_step cpuhp_ap_states[] = {
.teardown.single= rcutree_dying_cpu,
},
/* Entry state on starting. Interrupts enabled from here on. Transient
-* state for synchronsization */
+* state for synchronsization
+*/
[CPUHP_AP_ONLINE] = {
.name   = "ap:online",
},
-- 
2.10.2

[PATCH] Fix style issues in kernel/cpu.c

[Thomas Casey]

This patch fixes style issues in kernel/cpu.c such as wrapping an 80
character line, calling EXPORT_SYMBOL() immediately after a function is
defined, and whitespace and spacing issues.

Signed-off-by: Thomas Casey 
---
 kernel/cpu.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 29de1a9..15a90ba 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -228,7 +228,8 @@ static struct {
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map", 
_hotplug.dep_map),
+   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
+   _hotplug.dep_map),
 #endif
 };
 
@@ -304,7 +305,7 @@ void cpu_hotplug_begin(void)
mutex_lock(_hotplug.lock);
prepare_to_wait(_hotplug.wq, , TASK_UNINTERRUPTIBLE);
if (likely(!atomic_read(_hotplug.refcount)))
-   break;
+   break;
mutex_unlock(_hotplug.lock);
schedule();
}
@@ -353,6 +354,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
 int register_cpu_notifier(struct notifier_block *nb)
 {
int ret;
+
cpu_maps_update_begin();
ret = raw_notifier_chain_register(_chain, nb);
cpu_maps_update_done();
@@ -363,6 +365,7 @@ int __register_cpu_notifier(struct notifier_block *nb)
 {
return raw_notifier_chain_register(_chain, nb);
 }
+EXPORT_SYMBOL(__register_cpu_notifier);
 
 static int __cpu_notify(unsigned long val, unsigned int cpu, int nr_to_call,
int *nr_calls)
@@ -661,7 +664,6 @@ void __init cpuhp_threads_init(void)
 
 #ifdef CONFIG_HOTPLUG_CPU
 EXPORT_SYMBOL(register_cpu_notifier);
-EXPORT_SYMBOL(__register_cpu_notifier);
 void unregister_cpu_notifier(struct notifier_block *nb)
 {
cpu_maps_update_begin();
@@ -1250,7 +1252,7 @@ static struct cpuhp_step cpuhp_bp_states[] = {
.teardown.single= NULL,
},
 #ifdef CONFIG_SMP
-   [CPUHP_CREATE_THREADS]= {
+   [CPUHP_CREATE_THREADS] = {
.name   = "threads:prepare",
.startup.single = smpboot_create_threads,
.teardown.single= NULL,
@@ -1366,7 +1368,8 @@ static struct cpuhp_step cpuhp_ap_states[] = {
.teardown.single= rcutree_dying_cpu,
},
/* Entry state on starting. Interrupts enabled from here on. Transient
-* state for synchronsization */
+* state for synchronsization
+*/
[CPUHP_AP_ONLINE] = {
.name   = "ap:online",
},
-- 
2.10.2

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Ingo Molnar]

* Boris Ostrovsky  wrote:

> > It is tricky to do so safely, because at this stage almost nothing of the C 
> > execution environment has been set up.

Yeah - but we do have a fair amount of early C code though.

> I can still give it a try but I'd rather not tie it to this (Xen PVH) patch 
> series. Which would leave me with two options: either keep what this patch 
> does, 
> leaving it as assembly (requires your ack), or have Xen code build the pages 
> on 
> its own.

If you give it a try in a subsequent patch (please Cc: me) then it's OK to me:

  Acked-by: Ingo Molnar 

Feel free to carry it in the Xen tree.

Thanks,

Ingo

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Ingo Molnar]

* Boris Ostrovsky  wrote:

> > It is tricky to do so safely, because at this stage almost nothing of the C 
> > execution environment has been set up.

Yeah - but we do have a fair amount of early C code though.

> I can still give it a try but I'd rather not tie it to this (Xen PVH) patch 
> series. Which would leave me with two options: either keep what this patch 
> does, 
> leaving it as assembly (requires your ack), or have Xen code build the pages 
> on 
> its own.

If you give it a try in a subsequent patch (please Cc: me) then it's OK to me:

  Acked-by: Ingo Molnar 

Feel free to carry it in the Xen tree.

Thanks,

Ingo

Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks

[Xiaolong Zhang]

On 二, 11月 29, 2016 at 01:10:54下午 -0800, Stephen Boyd wrote:
> On 11/24, Xiaolong Zhang wrote:
> > On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote:
> > 
> > > We're really off track now though. Can you please point to some
> > > code that needs this change? If we're using DT then we should be
> > > able to use the of_clk_*() path to find the clk.
> > >
> > 
> > Actually, the requirement is raised by our GPU driver. In the
> > early stage of the GPU DT driver, the GPU driver use the
> > clk_get(NULL, con_id) to get the clock instance for compatible
> > with non-DT GPU driver. The new driver have used the of_clk_get()
> > instead of the clk_get. And we reserved the modification in clock.
> > 
> 
> Ok the non-DT version of the GPU driver should be modified to
> call clk_get() and pass in the device. The con_id argument there
> should be something specific to the GPU device, and not a global
> name of a clock on the system. When the clkdev lookup is
> populated on the non-DT board make sure to set the dev_id string
> to match the device name of the GPU device.
>
Ok, Thanks sBoyd!
>
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks

[Xiaolong Zhang]

On 二, 11月 29, 2016 at 01:10:54下午 -0800, Stephen Boyd wrote:
> On 11/24, Xiaolong Zhang wrote:
> > On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote:
> > 
> > > We're really off track now though. Can you please point to some
> > > code that needs this change? If we're using DT then we should be
> > > able to use the of_clk_*() path to find the clk.
> > >
> > 
> > Actually, the requirement is raised by our GPU driver. In the
> > early stage of the GPU DT driver, the GPU driver use the
> > clk_get(NULL, con_id) to get the clock instance for compatible
> > with non-DT GPU driver. The new driver have used the of_clk_get()
> > instead of the clk_get. And we reserved the modification in clock.
> > 
> 
> Ok the non-DT version of the GPU driver should be modified to
> call clk_get() and pass in the device. The con_id argument there
> should be something specific to the GPU device, and not a global
> name of a clock on the system. When the clkdev lookup is
> populated on the non-DT board make sure to set the dev_id string
> to match the device name of the GPU device.
>
Ok, Thanks sBoyd!
>
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-r0-201648 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
>> nmi_timer_int.c:(.text+0x238b): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2793): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-r0-201648 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
>> nmi_timer_int.c:(.text+0x238b): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2793): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()

[Al Viro]

FWIW, I've folded that pile into vfs.git#work.autofs.

Problems:
* (fixed) __path_is_mountpoint() should _not_ treat NULL from
__lookup_mnt() as "nothing's mounted there" until it has checked
that mount_lock hadn't been touched - mount --move on something unrelated
can race with lockless hash lookup and lead to false negatives.
* linux/mount.h might be the wrong place for path_is_mountpoint().
Or it shouldn't be inlined.  I don't like the includes you've added there.
* path_has_submounts() is broken.  At the very least, it's
AB-BA between mount_lock and rename_lock.  I would suggest trying to
put read_seqlock_excl(_lock) around the call of d_walk() in there,
and using __lookup_mnt() in the callback (without retries on the mount_lock,
of course - read_seqlock_excl done on the outside is enough).  I'm not sure
if it won't cause trouble with contention, though; that needs testing.  As
it is, that function is broken in #work.autofs, same as it is in -mm and
-next.
* the last one (propagation-related) is too ugly to live - at the
very least, its pieces should live in fs/pnode.c; exposing propagate_next()
is simply wrong.  I hadn't picked that one at all, and I would suggest
coordinating anything in that area with ebiederman - he has some work
around fs/pnode.c and you risk stepping on his toes.

Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()

[Al Viro]

FWIW, I've folded that pile into vfs.git#work.autofs.

Problems:
* (fixed) __path_is_mountpoint() should _not_ treat NULL from
__lookup_mnt() as "nothing's mounted there" until it has checked
that mount_lock hadn't been touched - mount --move on something unrelated
can race with lockless hash lookup and lead to false negatives.
* linux/mount.h might be the wrong place for path_is_mountpoint().
Or it shouldn't be inlined.  I don't like the includes you've added there.
* path_has_submounts() is broken.  At the very least, it's
AB-BA between mount_lock and rename_lock.  I would suggest trying to
put read_seqlock_excl(_lock) around the call of d_walk() in there,
and using __lookup_mnt() in the callback (without retries on the mount_lock,
of course - read_seqlock_excl done on the outside is enough).  I'm not sure
if it won't cause trouble with contention, though; that needs testing.  As
it is, that function is broken in #work.autofs, same as it is in -mm and
-next.
* the last one (propagation-related) is too ugly to live - at the
very least, its pieces should live in fs/pnode.c; exposing propagate_next()
is simply wrong.  I hadn't picked that one at all, and I would suggest
coordinating anything in that area with ebiederman - he has some work
around fs/pnode.c and you risk stepping on his toes.

Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes

[Bjorn Andersson]

On Tue 22 Nov 09:02 PST 2016, Stanimir Varbanov wrote:

> Add linux/sizes.h to prevent build failure on non ARM architectures
> as:
> 
> CC [M]  drivers/remoteproc/qcom_mdt_loader.o
> In file included from include/linux/cache.h:4:0,
>  from include/linux/printk.h:8,
>  from include/linux/kernel.h:13,
>  from include/asm-generic/bug.h:13,
>  from arch/x86/include/asm/bug.h:35,
>  from include/linux/bug.h:4,
>  from include/linux/thread_info.h:11,
>  from arch/x86/include/asm/elf.h:7,
>  from include/linux/elf.h:4,
>  from drivers/remoteproc/qcom_mdt_loader.c:18:
> drivers/remoteproc/qcom_mdt_loader.c: In function ‘qcom_mdt_parse’:
> drivers/remoteproc/qcom_mdt_loader.c:90:52: error: ‘SZ_4K’ undeclared
> (first use in this function)
> 
> Signed-off-by: Stanimir Varbanov 

Applied

Thanks,
Bjorn

> ---
>  drivers/remoteproc/qcom_mdt_loader.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/remoteproc/qcom_mdt_loader.c 
> b/drivers/remoteproc/qcom_mdt_loader.c
> index 114e8e4cef67..2ff18cd6c096 100644
> --- a/drivers/remoteproc/qcom_mdt_loader.c
> +++ b/drivers/remoteproc/qcom_mdt_loader.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "remoteproc_internal.h"
> -- 
> 2.7.4
> 

Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes

[Bjorn Andersson]

On Tue 22 Nov 09:02 PST 2016, Stanimir Varbanov wrote:

> Add linux/sizes.h to prevent build failure on non ARM architectures
> as:
> 
> CC [M]  drivers/remoteproc/qcom_mdt_loader.o
> In file included from include/linux/cache.h:4:0,
>  from include/linux/printk.h:8,
>  from include/linux/kernel.h:13,
>  from include/asm-generic/bug.h:13,
>  from arch/x86/include/asm/bug.h:35,
>  from include/linux/bug.h:4,
>  from include/linux/thread_info.h:11,
>  from arch/x86/include/asm/elf.h:7,
>  from include/linux/elf.h:4,
>  from drivers/remoteproc/qcom_mdt_loader.c:18:
> drivers/remoteproc/qcom_mdt_loader.c: In function ‘qcom_mdt_parse’:
> drivers/remoteproc/qcom_mdt_loader.c:90:52: error: ‘SZ_4K’ undeclared
> (first use in this function)
> 
> Signed-off-by: Stanimir Varbanov 

Applied

Thanks,
Bjorn

> ---
>  drivers/remoteproc/qcom_mdt_loader.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/remoteproc/qcom_mdt_loader.c 
> b/drivers/remoteproc/qcom_mdt_loader.c
> index 114e8e4cef67..2ff18cd6c096 100644
> --- a/drivers/remoteproc/qcom_mdt_loader.c
> +++ b/drivers/remoteproc/qcom_mdt_loader.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "remoteproc_internal.h"
> -- 
> 2.7.4
> 

[PATCH] remoteproc: Remove "experimental" warning

[Bjorn Andersson]

Warning users that remoteproc and it's binary format are under
development doesn't serve much of a purpose. Different drivers support
different image formats and the resource table has a version field that
would need to be bumped when incompatible changes are introduced.

So lets drop this warning to clean up the kernel log.

Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/remoteproc_core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index f0f6ec1ab12b..fc2ebff7d332 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1298,9 +1298,6 @@ int rproc_add(struct rproc *rproc)
 
dev_info(dev, "%s is available\n", rproc->name);
 
-   dev_info(dev, "Note: remoteproc is still under development and 
considered experimental.\n");
-   dev_info(dev, "THE BINARY FORMAT IS NOT YET FINALIZED, and backward 
compatibility isn't yet guaranteed.\n");
-
/* create debugfs entries */
rproc_create_debug_dir(rproc);
ret = rproc_add_virtio_devices(rproc);
-- 
2.5.0

[PATCH] remoteproc: Remove "experimental" warning

[Bjorn Andersson]

Warning users that remoteproc and it's binary format are under
development doesn't serve much of a purpose. Different drivers support
different image formats and the resource table has a version field that
would need to be bumped when incompatible changes are introduced.

So lets drop this warning to clean up the kernel log.

Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/remoteproc_core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index f0f6ec1ab12b..fc2ebff7d332 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1298,9 +1298,6 @@ int rproc_add(struct rproc *rproc)
 
dev_info(dev, "%s is available\n", rproc->name);
 
-   dev_info(dev, "Note: remoteproc is still under development and 
considered experimental.\n");
-   dev_info(dev, "THE BINARY FORMAT IS NOT YET FINALIZED, and backward 
compatibility isn't yet guaranteed.\n");
-
/* create debugfs entries */
rproc_create_debug_dir(rproc);
ret = rproc_add_virtio_devices(rproc);
-- 
2.5.0

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Ben Hutchings]

On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the
> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc
> symbol gets dropped, and any module trying to use it will fail to
> load.
> 
> This sets the weak CRC symbol to zero explicitly, making it defined
> in vmlinux, which in turn lets us load the modules referring to
> that CRC.
> 
> The comment above the __CRC_SYMBOL macro suggests that this was
> always the intention, although it also seems that all symbols
> defined in C have a correct CRC these days, and only the exports
> that are now done in assembly need this.
> 
> > Signed-off-by: Arnd Bergmann 
> ---
> Not sure if this is the correct way of doing it, but this seems trivial
> enough and lets me build the kernel with missing CRCs with any binutils
> version.

I tried this along with Adam's patch on x86_64, with Debian's binutils
2.27.51.20161127.  The result was that the kernel's __kcrctab held 0
for several symbols, even though there was type information in asm-
prototypes.h and Module.symvers and the modules had a non-zero CRC for
those symbols.  With just Adam's patch, the kernel and modules agreed.

Ben.

> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 63554e9..59a3b2f 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name):
>  KSYM(__kcrctab_\name):
> >     __put KSYM(__crc_\name)
> >     .weak KSYM(__crc_\name)
> > +   .set KSYM(__crc_\name), 0
> >     .previous
>  #endif
>  #endif
> 
-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Ben Hutchings]

On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the
> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc
> symbol gets dropped, and any module trying to use it will fail to
> load.
> 
> This sets the weak CRC symbol to zero explicitly, making it defined
> in vmlinux, which in turn lets us load the modules referring to
> that CRC.
> 
> The comment above the __CRC_SYMBOL macro suggests that this was
> always the intention, although it also seems that all symbols
> defined in C have a correct CRC these days, and only the exports
> that are now done in assembly need this.
> 
> > Signed-off-by: Arnd Bergmann 
> ---
> Not sure if this is the correct way of doing it, but this seems trivial
> enough and lets me build the kernel with missing CRCs with any binutils
> version.

I tried this along with Adam's patch on x86_64, with Debian's binutils
2.27.51.20161127.  The result was that the kernel's __kcrctab held 0
for several symbols, even though there was type information in asm-
prototypes.h and Module.symvers and the modules had a non-zero CRC for
those symbols.  With just Adam's patch, the kernel and modules agreed.

Ben.

> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 63554e9..59a3b2f 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name):
>  KSYM(__kcrctab_\name):
> >     __put KSYM(__crc_\name)
> >     .weak KSYM(__crc_\name)
> > +   .set KSYM(__crc_\name), 0
> >     .previous
>  #endif
>  #endif
> 
-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] blk-stat: fix a typo

[Jens Axboe]

On 12/02/2016 08:16 PM, Jens Axboe wrote:
> On 12/02/2016 06:13 PM, Shaohua Li wrote:
>> Signed-off-by: Shaohua Li 
>> ---
>>  block/blk-stat.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/block/blk-stat.c b/block/blk-stat.c
>> index 688c958..4d01185 100644
>> --- a/block/blk-stat.c
>> +++ b/block/blk-stat.c
>> @@ -12,7 +12,7 @@
>>  static void blk_stat_flush_batch(struct blk_rq_stat *stat)
>>  {
>>  const s32 nr_batch = READ_ONCE(stat->nr_batch);
>> -const s32 nr_samples = READ_ONCE(stat->nr_batch);
>> +const s32 nr_samples = READ_ONCE(stat->nr_samples);
>>  
>>  if (!nr_batch)
>>  return;
>>
> 
> Gah, that sucks. Thanks, added for 4.10.

BTW, this was added right before inclusion, all the previously posted
versions were not broken in this way. So thanks for spotting this!

-- 
Jens Axboe

Re: [PATCH] blk-stat: fix a typo

[Jens Axboe]

On 12/02/2016 08:16 PM, Jens Axboe wrote:
> On 12/02/2016 06:13 PM, Shaohua Li wrote:
>> Signed-off-by: Shaohua Li 
>> ---
>>  block/blk-stat.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/block/blk-stat.c b/block/blk-stat.c
>> index 688c958..4d01185 100644
>> --- a/block/blk-stat.c
>> +++ b/block/blk-stat.c
>> @@ -12,7 +12,7 @@
>>  static void blk_stat_flush_batch(struct blk_rq_stat *stat)
>>  {
>>  const s32 nr_batch = READ_ONCE(stat->nr_batch);
>> -const s32 nr_samples = READ_ONCE(stat->nr_batch);
>> +const s32 nr_samples = READ_ONCE(stat->nr_samples);
>>  
>>  if (!nr_batch)
>>  return;
>>
> 
> Gah, that sucks. Thanks, added for 4.10.

BTW, this was added right before inclusion, all the previously posted
versions were not broken in this way. So thanks for spotting this!

-- 
Jens Axboe

Re: [PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"

[Jeff Mahoney]

Whoops, the [PATCH] line should've specified more clearly:  This only
applies to linux-stable, 3.12.y.

Sorry for any confusion.

-Jeff

On 12/2/16 10:21 PM, Jeff Mahoney wrote:
> This reverts commit 644d10716875b24388680925d6c7502420987bfe.
> 
> The original patch for mainline, 6f8960541b1 (Btrfs: don't delay
> inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try
> not to ENOSPC on log replay) as the only pre-3.18 dependency, but it
> also depends on 67de11769bd (Btrfs: introduce the delayed inode ref
> deletion for the single link inode), which was introduced in 3.14
> and isn't in 3.12.y.
> 
> The -stable commit added the check to btrfs_delayed_update_inode,
> which may look similar to btrfs_delayed_delete_inode_ref, but it's
> only superficial.  The tops of both functions handle typical
> delayed node boilerplate.  The upshot is that the patch is harmless
> since the caller already checks to see if we're doing log recovery,
> so we're not breaking anything.  It should be reverted because it
> makes it appear as if this issue was fixed for users who did
> backport 67de11769bd, when it is not.
> 
> Signed-off-by: Jeff Mahoney 
> ---
>  fs/btrfs/delayed-inode.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
> index 34f33e1..269ac79 100644
> --- a/fs/btrfs/delayed-inode.c
> +++ b/fs/btrfs/delayed-inode.c
> @@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct 
> btrfs_trans_handle *trans,
>   struct btrfs_delayed_node *delayed_node;
>   int ret = 0;
>  
> - /*
> -  * we don't do delayed inode updates during log recovery because it
> -  * leads to enospc problems.  This means we also can't do
> -  * delayed inode refs
> -  */
> - if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
> - return -EAGAIN;
> -
>   delayed_node = btrfs_get_or_create_delayed_node(inode);
>   if (IS_ERR(delayed_node))
>   return PTR_ERR(delayed_node);
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"

[Jeff Mahoney]

Whoops, the [PATCH] line should've specified more clearly:  This only
applies to linux-stable, 3.12.y.

Sorry for any confusion.

-Jeff

On 12/2/16 10:21 PM, Jeff Mahoney wrote:
> This reverts commit 644d10716875b24388680925d6c7502420987bfe.
> 
> The original patch for mainline, 6f8960541b1 (Btrfs: don't delay
> inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try
> not to ENOSPC on log replay) as the only pre-3.18 dependency, but it
> also depends on 67de11769bd (Btrfs: introduce the delayed inode ref
> deletion for the single link inode), which was introduced in 3.14
> and isn't in 3.12.y.
> 
> The -stable commit added the check to btrfs_delayed_update_inode,
> which may look similar to btrfs_delayed_delete_inode_ref, but it's
> only superficial.  The tops of both functions handle typical
> delayed node boilerplate.  The upshot is that the patch is harmless
> since the caller already checks to see if we're doing log recovery,
> so we're not breaking anything.  It should be reverted because it
> makes it appear as if this issue was fixed for users who did
> backport 67de11769bd, when it is not.
> 
> Signed-off-by: Jeff Mahoney 
> ---
>  fs/btrfs/delayed-inode.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
> index 34f33e1..269ac79 100644
> --- a/fs/btrfs/delayed-inode.c
> +++ b/fs/btrfs/delayed-inode.c
> @@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct 
> btrfs_trans_handle *trans,
>   struct btrfs_delayed_node *delayed_node;
>   int ret = 0;
>  
> - /*
> -  * we don't do delayed inode updates during log recovery because it
> -  * leads to enospc problems.  This means we also can't do
> -  * delayed inode refs
> -  */
> - if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
> - return -EAGAIN;
> -
>   delayed_node = btrfs_get_or_create_delayed_node(inode);
>   if (IS_ERR(delayed_node))
>   return PTR_ERR(delayed_node);
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

[Brendan Gregg]

On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot
 wrote:
>
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same CPU instead of other CPUs, which have similar runnable load but a
> lower load_avg.
>
> When the runnable_load_avg of 2 CPUs are close, we now take into account
> the amount of blocked load as a 2nd selection factor. There is now 3 zones
> for the runnable_load of the rq:
> -[0 .. (runnable_load - imbalance)] : Select the new rq which has
> significantly less runnable_load
> -](runnable_load - imbalance) .. (runnable_load + imbalance)[ : The
> runnable load are close so we use load_avg to chose between the 2 rq
> -[(runnable_load + imbalance) .. ULONG_MAX] : Keep the current rq which
> has significantly less runnable_load
>

For background, is this from the "A decade of wasted cores" paper's
patches? What's the expected typical gain? Thanks,

Brendan

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

[Brendan Gregg]

On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot
 wrote:
>
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same CPU instead of other CPUs, which have similar runnable load but a
> lower load_avg.
>
> When the runnable_load_avg of 2 CPUs are close, we now take into account
> the amount of blocked load as a 2nd selection factor. There is now 3 zones
> for the runnable_load of the rq:
> -[0 .. (runnable_load - imbalance)] : Select the new rq which has
> significantly less runnable_load
> -](runnable_load - imbalance) .. (runnable_load + imbalance)[ : The
> runnable load are close so we use load_avg to chose between the 2 rq
> -[(runnable_load + imbalance) .. ULONG_MAX] : Keep the current rq which
> has significantly less runnable_load
>

For background, is this from the "A decade of wasted cores" paper's
patches? What's the expected typical gain? Thanks,

Brendan

[PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"

[Jeff Mahoney]

This reverts commit 644d10716875b24388680925d6c7502420987bfe.

The original patch for mainline, 6f8960541b1 (Btrfs: don't delay
inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try
not to ENOSPC on log replay) as the only pre-3.18 dependency, but it
also depends on 67de11769bd (Btrfs: introduce the delayed inode ref
deletion for the single link inode), which was introduced in 3.14
and isn't in 3.12.y.

The -stable commit added the check to btrfs_delayed_update_inode,
which may look similar to btrfs_delayed_delete_inode_ref, but it's
only superficial.  The tops of both functions handle typical
delayed node boilerplate.  The upshot is that the patch is harmless
since the caller already checks to see if we're doing log recovery,
so we're not breaking anything.  It should be reverted because it
makes it appear as if this issue was fixed for users who did
backport 67de11769bd, when it is not.

Signed-off-by: Jeff Mahoney 
---
 fs/btrfs/delayed-inode.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 34f33e1..269ac79 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct btrfs_trans_handle 
*trans,
struct btrfs_delayed_node *delayed_node;
int ret = 0;
 
-   /*
-* we don't do delayed inode updates during log recovery because it
-* leads to enospc problems.  This means we also can't do
-* delayed inode refs
-*/
-   if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
-   return -EAGAIN;
-
delayed_node = btrfs_get_or_create_delayed_node(inode);
if (IS_ERR(delayed_node))
return PTR_ERR(delayed_node);
-- 
2.7.1


-- 
Jeff Mahoney
SUSE Labs

[PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"

[Jeff Mahoney]

This reverts commit 644d10716875b24388680925d6c7502420987bfe.

The original patch for mainline, 6f8960541b1 (Btrfs: don't delay
inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try
not to ENOSPC on log replay) as the only pre-3.18 dependency, but it
also depends on 67de11769bd (Btrfs: introduce the delayed inode ref
deletion for the single link inode), which was introduced in 3.14
and isn't in 3.12.y.

The -stable commit added the check to btrfs_delayed_update_inode,
which may look similar to btrfs_delayed_delete_inode_ref, but it's
only superficial.  The tops of both functions handle typical
delayed node boilerplate.  The upshot is that the patch is harmless
since the caller already checks to see if we're doing log recovery,
so we're not breaking anything.  It should be reverted because it
makes it appear as if this issue was fixed for users who did
backport 67de11769bd, when it is not.

Signed-off-by: Jeff Mahoney 
---
 fs/btrfs/delayed-inode.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 34f33e1..269ac79 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct btrfs_trans_handle 
*trans,
struct btrfs_delayed_node *delayed_node;
int ret = 0;
 
-   /*
-* we don't do delayed inode updates during log recovery because it
-* leads to enospc problems.  This means we also can't do
-* delayed inode refs
-*/
-   if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
-   return -EAGAIN;
-
delayed_node = btrfs_get_or_create_delayed_node(inode);
if (IS_ERR(delayed_node))
return PTR_ERR(delayed_node);
-- 
2.7.1


-- 
Jeff Mahoney
SUSE Labs

Re: [PATCH] blk-stat: fix a typo

[Jens Axboe]

On 12/02/2016 06:13 PM, Shaohua Li wrote:
> Signed-off-by: Shaohua Li 
> ---
>  block/blk-stat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block/blk-stat.c b/block/blk-stat.c
> index 688c958..4d01185 100644
> --- a/block/blk-stat.c
> +++ b/block/blk-stat.c
> @@ -12,7 +12,7 @@
>  static void blk_stat_flush_batch(struct blk_rq_stat *stat)
>  {
>   const s32 nr_batch = READ_ONCE(stat->nr_batch);
> - const s32 nr_samples = READ_ONCE(stat->nr_batch);
> + const s32 nr_samples = READ_ONCE(stat->nr_samples);
>  
>   if (!nr_batch)
>   return;
> 

Gah, that sucks. Thanks, added for 4.10.

-- 
Jens Axboe

Re: [PATCH] blk-stat: fix a typo

[Jens Axboe]

On 12/02/2016 06:13 PM, Shaohua Li wrote:
> Signed-off-by: Shaohua Li 
> ---
>  block/blk-stat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block/blk-stat.c b/block/blk-stat.c
> index 688c958..4d01185 100644
> --- a/block/blk-stat.c
> +++ b/block/blk-stat.c
> @@ -12,7 +12,7 @@
>  static void blk_stat_flush_batch(struct blk_rq_stat *stat)
>  {
>   const s32 nr_batch = READ_ONCE(stat->nr_batch);
> - const s32 nr_samples = READ_ONCE(stat->nr_batch);
> + const s32 nr_samples = READ_ONCE(stat->nr_samples);
>  
>   if (!nr_batch)
>   return;
> 

Gah, that sucks. Thanks, added for 4.10.

-- 
Jens Axboe

Re: [mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c

[Eric W. Biederman]

kernel test robot  writes:

> FYI, we noticed the following commit:
>
> commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under 
> others instead of creating shadow/side mounts.")
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
> for-testing
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
>
> caused below changes:

Bah.  Obvious in hind site...

Thank you testing robot,

Eric

Re: [mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c

[Eric W. Biederman]

kernel test robot  writes:

> FYI, we noticed the following commit:
>
> commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under 
> others instead of creating shadow/side mounts.")
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
> for-testing
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
>
> caused below changes:

Bah.  Obvious in hind site...

Thank you testing robot,

Eric

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Marek Vasut]

On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
> Hi Rob,

Hi!

> 2016-12-03 1:26 GMT+09:00 Rob Herring :
> 
>>>
>>>
>>> (Plan A)
>>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family 
>>> variant)
>>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family 
>>> variant)
>>>
>>> (Plan B)
>>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family 
>>> variant)
>>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family 
>>> variant)
> 
>> Let the Altera folks worry about their stuff. At least for soft IP in
>> FPGA, it's a bit of a special case. The old string can remain as bad
>> as it is.
> 
> 
> Hmm, I am not sure if this IP would fit in FPGA
> (to use it along with NIOS-II?)
> 
> (even if it happened, nothing of this IP would be customizable on users' side.
> When buying the IP, SoC vendors submit a list of desired features.
> Denali (now Cadence) generates the RTL according to the configuration sheet.
> The function is fixed at this point. So, generic compatible would be
> useless anyway.)
> 
> 
> If we are talking about SOCFPGA,
> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
> It consists of two parts:
> [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
> USB, SD, NAND, ...)
> [2] FPGA part (User design logic)
> 
> The Denali NAND controller is included in [1].
> So, as far as we talk about the Denali on SOCFPGA,
> it is as hard-wired as Intel, Socionext's ones.

That's correct, the Denali NAND IP in altera socfpga is a hardware
block. You can make it available to the fabric too, but by default
it's used by the ARM part of the chip, so for this discussion, you
can forget that the FPGA part exists altogether.

I would be in favor of plan B, since it seems to be the more often
taken approach. A nice example is ci-hdrc:

$ git grep compatible drivers/usb/chipidea/

>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>> The fact that it is denali is part of the documentation.
>>
> 
> Let me think about this.
> 
> Socionext bought two version of Denali IP,
> and we are now re-using the newer one (v5b) for several SoCs.
> Socionext has some more product lines other than Uniphier SoC family,
> perhaps wider re-use might happen in the future.
> 
> At first, I included "uniphier" in compatible, but I am still wondering
> if such a specific string is good or not.
> 
> Also, comments from Altera engineers are appreciated.

Adding a few more on Cc

-- 
Best regards,
Marek Vasut

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Marek Vasut]

On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
> Hi Rob,

Hi!

> 2016-12-03 1:26 GMT+09:00 Rob Herring :
> 
>>>
>>>
>>> (Plan A)
>>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family 
>>> variant)
>>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family 
>>> variant)
>>>
>>> (Plan B)
>>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family 
>>> variant)
>>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family 
>>> variant)
> 
>> Let the Altera folks worry about their stuff. At least for soft IP in
>> FPGA, it's a bit of a special case. The old string can remain as bad
>> as it is.
> 
> 
> Hmm, I am not sure if this IP would fit in FPGA
> (to use it along with NIOS-II?)
> 
> (even if it happened, nothing of this IP would be customizable on users' side.
> When buying the IP, SoC vendors submit a list of desired features.
> Denali (now Cadence) generates the RTL according to the configuration sheet.
> The function is fixed at this point. So, generic compatible would be
> useless anyway.)
> 
> 
> If we are talking about SOCFPGA,
> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
> It consists of two parts:
> [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
> USB, SD, NAND, ...)
> [2] FPGA part (User design logic)
> 
> The Denali NAND controller is included in [1].
> So, as far as we talk about the Denali on SOCFPGA,
> it is as hard-wired as Intel, Socionext's ones.

That's correct, the Denali NAND IP in altera socfpga is a hardware
block. You can make it available to the fabric too, but by default
it's used by the ARM part of the chip, so for this discussion, you
can forget that the FPGA part exists altogether.

I would be in favor of plan B, since it seems to be the more often
taken approach. A nice example is ci-hdrc:

$ git grep compatible drivers/usb/chipidea/

>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>> The fact that it is denali is part of the documentation.
>>
> 
> Let me think about this.
> 
> Socionext bought two version of Denali IP,
> and we are now re-using the newer one (v5b) for several SoCs.
> Socionext has some more product lines other than Uniphier SoC family,
> perhaps wider re-use might happen in the future.
> 
> At first, I included "uniphier" in compatible, but I am still wondering
> if such a specific string is good or not.
> 
> Also, comments from Altera engineers are appreciated.

Adding a few more on Cc

-- 
Best regards,
Marek Vasut

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Masahiro Yamada]

Hi Rob,

2016-12-03 1:26 GMT+09:00 Rob Herring :

>>
>>
>> (Plan A)
>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family variant)
>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family variant)
>>
>> (Plan B)
>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant)
>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant)

> Let the Altera folks worry about their stuff. At least for soft IP in
> FPGA, it's a bit of a special case. The old string can remain as bad
> as it is.


Hmm, I am not sure if this IP would fit in FPGA
(to use it along with NIOS-II?)

(even if it happened, nothing of this IP would be customizable on users' side.
When buying the IP, SoC vendors submit a list of desired features.
Denali (now Cadence) generates the RTL according to the configuration sheet.
The function is fixed at this point. So, generic compatible would be
useless anyway.)


If we are talking about SOCFPGA,
SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
It consists of two parts:
[1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
USB, SD, NAND, ...)
[2] FPGA part (User design logic)

The Denali NAND controller is included in [1].
So, as far as we talk about the Denali on SOCFPGA,
it is as hard-wired as Intel, Socionext's ones.


> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
> The fact that it is denali is part of the documentation.
>

Let me think about this.

Socionext bought two version of Denali IP,
and we are now re-using the newer one (v5b) for several SoCs.
Socionext has some more product lines other than Uniphier SoC family,
perhaps wider re-use might happen in the future.

At first, I included "uniphier" in compatible, but I am still wondering
if such a specific string is good or not.

Also, comments from Altera engineers are appreciated.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Masahiro Yamada]

Hi Rob,

2016-12-03 1:26 GMT+09:00 Rob Herring :

>>
>>
>> (Plan A)
>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family variant)
>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family variant)
>>
>> (Plan B)
>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant)
>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant)

> Let the Altera folks worry about their stuff. At least for soft IP in
> FPGA, it's a bit of a special case. The old string can remain as bad
> as it is.


Hmm, I am not sure if this IP would fit in FPGA
(to use it along with NIOS-II?)

(even if it happened, nothing of this IP would be customizable on users' side.
When buying the IP, SoC vendors submit a list of desired features.
Denali (now Cadence) generates the RTL according to the configuration sheet.
The function is fixed at this point. So, generic compatible would be
useless anyway.)


If we are talking about SOCFPGA,
SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
It consists of two parts:
[1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
USB, SD, NAND, ...)
[2] FPGA part (User design logic)

The Denali NAND controller is included in [1].
So, as far as we talk about the Denali on SOCFPGA,
it is as hard-wired as Intel, Socionext's ones.


> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
> The fact that it is denali is part of the documentation.
>

Let me think about this.

Socionext bought two version of Denali IP,
and we are now re-using the newer one (v5b) for several SoCs.
Socionext has some more product lines other than Uniphier SoC family,
perhaps wider re-use might happen in the future.

At first, I included "uniphier" in compatible, but I am still wondering
if such a specific string is good or not.

Also, comments from Altera engineers are appreciated.


-- 
Best Regards
Masahiro Yamada

[PATCH linux-firmware 1/2] WHENCE: Add new amdgpu firmware

[Ben Hutchings]

Missed in commit 9c011a98a94ab1320f6c073ae500ae4dc33ce838.

Signed-off-by: Ben Hutchings 
---
Please run 'make check' before committing to catch this sort of error.

Ben.

 WHENCE | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/WHENCE b/WHENCE
index e731c68f309d..a7fc762dff64 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1837,6 +1837,7 @@ Licence: Redistributable. See LICENSE.radeon for details.
 Driver: amdgpu - AMD Radeon
 
 File: amdgpu/topaz_ce.bin
+File: amdgpu/topaz_k_smc.bin
 File: amdgpu/topaz_mc.bin
 File: amdgpu/topaz_me.bin
 File: amdgpu/topaz_mec2.bin
@@ -1847,6 +1848,7 @@ File: amdgpu/topaz_sdma1.bin
 File: amdgpu/topaz_sdma.bin
 File: amdgpu/topaz_smc.bin
 File: amdgpu/tonga_ce.bin
+File: amdgpu/tonga_k_smc.bin
 File: amdgpu/tonga_mc.bin
 File: amdgpu/tonga_me.bin
 File: amdgpu/tonga_mec2.bin



signature.asc
Description: Digital signature

[PATCH linux-firmware 1/2] WHENCE: Add new amdgpu firmware

[Ben Hutchings]

Missed in commit 9c011a98a94ab1320f6c073ae500ae4dc33ce838.

Signed-off-by: Ben Hutchings 
---
Please run 'make check' before committing to catch this sort of error.

Ben.

 WHENCE | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/WHENCE b/WHENCE
index e731c68f309d..a7fc762dff64 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1837,6 +1837,7 @@ Licence: Redistributable. See LICENSE.radeon for details.
 Driver: amdgpu - AMD Radeon
 
 File: amdgpu/topaz_ce.bin
+File: amdgpu/topaz_k_smc.bin
 File: amdgpu/topaz_mc.bin
 File: amdgpu/topaz_me.bin
 File: amdgpu/topaz_mec2.bin
@@ -1847,6 +1848,7 @@ File: amdgpu/topaz_sdma1.bin
 File: amdgpu/topaz_sdma.bin
 File: amdgpu/topaz_smc.bin
 File: amdgpu/tonga_ce.bin
+File: amdgpu/tonga_k_smc.bin
 File: amdgpu/tonga_mc.bin
 File: amdgpu/tonga_me.bin
 File: amdgpu/tonga_mec2.bin



signature.asc
Description: Digital signature

Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures

[Bhumika Goyal]

On Sat, Dec 3, 2016 at 2:09 AM, Larry Finger  wrote:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>>
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declared as const.
>> Done using Coccinelle:
>>
>> @r1 disable optional_qualifier @
>> identifier i;
>> position p;
>> @@
>> static struct rate_control_ops i@p = {...};
>>
>> @ok1@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_register(@p)
>>
>> @ok2@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_unregister(@p)
>>
>> @bad@
>> position p!={r1.p,ok1.p,ok2.p};
>> identifier r1.i;
>> @@
>> i@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> static
>> +const
>> struct rate_control_ops i={...};
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> +const
>> struct rate_control_ops i;
>>
>> File size before:
>>textdata bss dec hex filename
>>1991 104   02095 82f wireless/realtek/rtlwifi/rc.o
>>
>> File size after:
>>textdata bss dec hex filename
>>2095   0   02095 wireless/realtek/rtlwifi/rc.o
>>
>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> index ce8621a..107c13c 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> @@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
>> kfree(rate_priv);
>>  }
>>
>> -static struct rate_control_ops rtl_rate_ops = {
>> +static const struct rate_control_ops rtl_rate_ops = {
>> .name = "rtl_rc",
>> .alloc = rtl_rate_alloc,
>> .free = rtl_rate_free,
>>
>
> The content of your patch is OK; however, your subject is not. By
> convention, "net: wireless: realtek:" is assumed. We do, however, include
> "rtlwifi:" to indicate which part of drivers/net/wireless/realtek/ is
> referenced.
>
Ok, I will send a v2 with the correct subject. Thanks for the input.

Thanks,
Bhumika

> NACK
>
> Larry
>

Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures

[Bhumika Goyal]

On Sat, Dec 3, 2016 at 2:09 AM, Larry Finger  wrote:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>>
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declared as const.
>> Done using Coccinelle:
>>
>> @r1 disable optional_qualifier @
>> identifier i;
>> position p;
>> @@
>> static struct rate_control_ops i@p = {...};
>>
>> @ok1@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_register(@p)
>>
>> @ok2@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_unregister(@p)
>>
>> @bad@
>> position p!={r1.p,ok1.p,ok2.p};
>> identifier r1.i;
>> @@
>> i@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> static
>> +const
>> struct rate_control_ops i={...};
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> +const
>> struct rate_control_ops i;
>>
>> File size before:
>>textdata bss dec hex filename
>>1991 104   02095 82f wireless/realtek/rtlwifi/rc.o
>>
>> File size after:
>>textdata bss dec hex filename
>>2095   0   02095 wireless/realtek/rtlwifi/rc.o
>>
>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> index ce8621a..107c13c 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> @@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
>> kfree(rate_priv);
>>  }
>>
>> -static struct rate_control_ops rtl_rate_ops = {
>> +static const struct rate_control_ops rtl_rate_ops = {
>> .name = "rtl_rc",
>> .alloc = rtl_rate_alloc,
>> .free = rtl_rate_free,
>>
>
> The content of your patch is OK; however, your subject is not. By
> convention, "net: wireless: realtek:" is assumed. We do, however, include
> "rtlwifi:" to indicate which part of drivers/net/wireless/realtek/ is
> referenced.
>
Ok, I will send a v2 with the correct subject. Thanks for the input.

Thanks,
Bhumika

> NACK
>
> Larry
>

[PATCH linux-firmware 2/2] WHENCE: Add new snd_intel_sst_core

[Ben Hutchings]

Missed in commit 128052ee31f7023b07c5d65c2212abce6e52076c.

Signed-off-by: Ben Hutchings 
---
Please run 'make check' before committing to catch this sort of error.

Ben.

 WHENCE | 1 +
 1 file changed, 1 insertion(+)

diff --git a/WHENCE b/WHENCE
index a7fc762dff64..d021c40c5169 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3039,6 +3039,7 @@ License: Redistributable. See LICENCE.IntcSST2 for details
 Driver: snd_intel_sst_core
 
 File: intel/fw_sst_0f28.bin
+File: intel/fw_sst_0f28_ssp0.bin
 
 License: Redistributable. See LICENCE.fw_sst_0f28 for details
 


signature.asc
Description: Digital signature

[PATCH linux-firmware 2/2] WHENCE: Add new snd_intel_sst_core

[Ben Hutchings]

Missed in commit 128052ee31f7023b07c5d65c2212abce6e52076c.

Signed-off-by: Ben Hutchings 
---
Please run 'make check' before committing to catch this sort of error.

Ben.

 WHENCE | 1 +
 1 file changed, 1 insertion(+)

diff --git a/WHENCE b/WHENCE
index a7fc762dff64..d021c40c5169 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3039,6 +3039,7 @@ License: Redistributable. See LICENCE.IntcSST2 for details
 Driver: snd_intel_sst_core
 
 File: intel/fw_sst_0f28.bin
+File: intel/fw_sst_0f28_ssp0.bin
 
 License: Redistributable. See LICENCE.fw_sst_0f28 for details
 


signature.asc
Description: Digital signature

[mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under 
others instead of creating shadow/side mounts.")
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-testing

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

caused below changes:


+--+++
|  | f84df2a6f2 
| 81e3bb1b6f |
+--+++
| boot_successes   | 14 
| 3  |
| boot_failures| 0  
| 13 |
| BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c | 0  
| 12 |
| calltrace:SyS_mount  | 0  
| 12 |
| invoked_oom-killer:gfp_mask=0x   | 0  
| 1  |
| Mem-Info | 0  
| 1  |
+--+++



[   11.335778] rc.local[3455]: 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/lkp/lkp/src/bin
 Starting Login Service...
[   12.095031] random: fast init done
[   12.107647] BUG: sleeping function called from invalid context at 
fs/dcache.c:757
[   12.109075] in_atomic(): 1, irqs_disabled(): 0, pid: 3475, name: mount
[   12.109967] 4 locks held by mount/3475:
[   12.110636]  #0: 
[   12.110834]  (
>s_type->i_mutex_key
[   12.111598] #2
){++}
[   12.112265] , at: 
[   12.112834] [] lock_mount+0x2f/0xf6
[   12.113591]  #1: 
[   12.113786]  (
namespace_sem
[   12.122117] ){++}
, at: 
[   12.122794] [] lock_mount+0x5b/0xf6
[   12.123608]  #2: 
[   12.123803]  (
mount_lock
[   12.124468] ){+.+...}
, at: 
[   12.125163] [] attach_recursive_mnt+0xb8/0x2c1
[   12.126030]  #3: 
[   12.126242]  (
mount_lock
[   12.126898] #2
){+.+...}
[   12.127565] , at: 
[   12.128142] [] graft_tree+0x54/0x56
[   12.128894] CPU: 0 PID: 3475 Comm: mount Not tainted 
4.9.0-rc6-5-g81e3bb1 #1
[   12.130158] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   12.131500]  c90002b17d18 8158eef7 88003e1cc040 
02f5
[   12.132936]  c90002b17d40 810cbb24 82226d44 
02f5
[   12.134378]   c90002b17d68 810cbbae 
88003376a7b8
[   12.135825] Call Trace:
[   12.136385]  [] dump_stack+0x86/0xc0
[   12.137151]  [] ___might_sleep+0x1fa/0x20d
[   12.137941]  [] __might_sleep+0x77/0x7e
[   12.138723]  [] dput+0x38/0x357
[   12.139457]  [] path_put+0x16/0x21
[   12.140204]  [] mnt_change_mountpoint+0xc2/0xcf
[   12.141019]  [] attach_recursive_mnt+0x1eb/0x2c1
[   12.141853]  [] graft_tree+0x54/0x56
[   12.142613]  [] do_add_mount+0xab/0xca
[   12.143393]  [] do_mount+0xaa7/0xb06
[   12.144162]  [] ? copy_mount_options+0x2e/0x117
[   12.144975]  [] SyS_mount+0x77/0x9f
[   12.145735]  [] entry_SYSCALL_64_fastpath+0x1f/0xc2


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#

[mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under 
others instead of creating shadow/side mounts.")
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-testing

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

caused below changes:


+--+++
|  | f84df2a6f2 
| 81e3bb1b6f |
+--+++
| boot_successes   | 14 
| 3  |
| boot_failures| 0  
| 13 |
| BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c | 0  
| 12 |
| calltrace:SyS_mount  | 0  
| 12 |
| invoked_oom-killer:gfp_mask=0x   | 0  
| 1  |
| Mem-Info | 0  
| 1  |
+--+++



[   11.335778] rc.local[3455]: 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/lkp/lkp/src/bin
 Starting Login Service...
[   12.095031] random: fast init done
[   12.107647] BUG: sleeping function called from invalid context at 
fs/dcache.c:757
[   12.109075] in_atomic(): 1, irqs_disabled(): 0, pid: 3475, name: mount
[   12.109967] 4 locks held by mount/3475:
[   12.110636]  #0: 
[   12.110834]  (
>s_type->i_mutex_key
[   12.111598] #2
){++}
[   12.112265] , at: 
[   12.112834] [] lock_mount+0x2f/0xf6
[   12.113591]  #1: 
[   12.113786]  (
namespace_sem
[   12.122117] ){++}
, at: 
[   12.122794] [] lock_mount+0x5b/0xf6
[   12.123608]  #2: 
[   12.123803]  (
mount_lock
[   12.124468] ){+.+...}
, at: 
[   12.125163] [] attach_recursive_mnt+0xb8/0x2c1
[   12.126030]  #3: 
[   12.126242]  (
mount_lock
[   12.126898] #2
){+.+...}
[   12.127565] , at: 
[   12.128142] [] graft_tree+0x54/0x56
[   12.128894] CPU: 0 PID: 3475 Comm: mount Not tainted 
4.9.0-rc6-5-g81e3bb1 #1
[   12.130158] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   12.131500]  c90002b17d18 8158eef7 88003e1cc040 
02f5
[   12.132936]  c90002b17d40 810cbb24 82226d44 
02f5
[   12.134378]   c90002b17d68 810cbbae 
88003376a7b8
[   12.135825] Call Trace:
[   12.136385]  [] dump_stack+0x86/0xc0
[   12.137151]  [] ___might_sleep+0x1fa/0x20d
[   12.137941]  [] __might_sleep+0x77/0x7e
[   12.138723]  [] dput+0x38/0x357
[   12.139457]  [] path_put+0x16/0x21
[   12.140204]  [] mnt_change_mountpoint+0xc2/0xcf
[   12.141019]  [] attach_recursive_mnt+0x1eb/0x2c1
[   12.141853]  [] graft_tree+0x54/0x56
[   12.142613]  [] do_add_mount+0xab/0xca
[   12.143393]  [] do_mount+0xaa7/0xb06
[   12.144162]  [] ? copy_mount_options+0x2e/0x117
[   12.144975]  [] SyS_mount+0x77/0x9f
[   12.145735]  [] entry_SYSCALL_64_fastpath+0x1f/0xc2


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#

[PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

[Davidlohr Bueso]

The use of any kind of wait queue is an overkill for pcpu-rwsems.
While one option would be to use the less heavy simple (swait)
flavor, this is still too much for what pcpu-rwsems needs. For one,
we do not care about any sort of queuing in that the only (rare) time
writers (and readers, for that matter) are queued is when trying to
acquire the regular contended rw_sem. There cannot be any further
queuing as writers are serialized by the rw_sem in the first place.

This patch, therefore, implements custom wait/wake, with an rcu-aware
writer task pointer. The only time this is !nil is when a writer is
determining if it is going to block, and reset as soon as we know that
the percpu_down_write() call has succeeded. All this is obviously done while
holding the regular rw_sem. As such, we can avoid the queue handling and
locking overhead (although we currently end up taking the waitqueue
spinlock fastpath, so it wouldn't be a very big an impact).

Signed-off-by: Davidlohr Bueso 
---
include/linux/percpu-rwsem.h  |  5 ++---
kernel/locking/percpu-rwsem.c | 26 +-
2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 5b2e6159b744..9942b7e8bde8 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -4,7 +4,6 @@
#include 
#include 
#include 
-#include 
#include 
#include 

@@ -12,7 +11,7 @@ struct percpu_rw_semaphore {
struct rcu_sync rss;
unsigned int __percpu   *read_count;
struct rw_semaphore rw_sem;
-   wait_queue_head_t   writer;
+   struct task_struct  *writer; /* blocked writer */
int readers_block;
};

@@ -22,7 +21,7 @@ static struct percpu_rw_semaphore name = {
\
.rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC),\
.read_count = &__percpu_rwsem_rc_##name,\
.rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
-   .writer = __WAIT_QUEUE_HEAD_INITIALIZER(name.writer),   \
+   .writer = NULL, \
}

extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index ce182599cf2e..7856a77396d3 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -1,7 +1,6 @@
#include 
#include 
#include 
-#include 
#include 
#include 
#include 
@@ -18,7 +17,7 @@ int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
/* ->rw_sem represents the whole percpu_rw_semaphore for lockdep */
rcu_sync_init(>rss, RCU_SCHED_SYNC);
__init_rwsem(>rw_sem, name, rwsem_key);
-   init_waitqueue_head(>writer);
+   sem->writer = NULL;
sem->readers_block = 0;
return 0;
}
@@ -94,6 +93,8 @@ EXPORT_SYMBOL_GPL(__percpu_down_read);

void __percpu_up_read(struct percpu_rw_semaphore *sem)
{
+   struct task_struct *writer;
+
smp_mb(); /* B matches C */
/*
 * In other words, if they see our decrement (presumably to aggregate
@@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem)
 */
__this_cpu_dec(*sem->read_count);

+   rcu_read_lock();
+   writer = rcu_dereference(sem->writer);
+
/* Prod writer to recheck readers_active */
-   wake_up(>writer);
+   if (writer)
+   wake_up_process(writer);
+   rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(__percpu_up_read);

@@ -159,8 +165,18 @@ void percpu_down_write(struct percpu_rw_semaphore *sem)
 * will wait for them.
 */

-   /* Wait for all now active readers to complete. */
-   wait_event(sem->writer, readers_active_check(sem));
+   WRITE_ONCE(sem->writer, current);
+   for (;;) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+
+   if (readers_active_check(sem))
+   break;
+
+   schedule();
+   }
+
+   rcu_assign_pointer(sem->writer, NULL);
+   __set_current_state(TASK_RUNNING);
}
EXPORT_SYMBOL_GPL(percpu_down_write);

--
2.6.6

[PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

[Davidlohr Bueso]

The use of any kind of wait queue is an overkill for pcpu-rwsems.
While one option would be to use the less heavy simple (swait)
flavor, this is still too much for what pcpu-rwsems needs. For one,
we do not care about any sort of queuing in that the only (rare) time
writers (and readers, for that matter) are queued is when trying to
acquire the regular contended rw_sem. There cannot be any further
queuing as writers are serialized by the rw_sem in the first place.

This patch, therefore, implements custom wait/wake, with an rcu-aware
writer task pointer. The only time this is !nil is when a writer is
determining if it is going to block, and reset as soon as we know that
the percpu_down_write() call has succeeded. All this is obviously done while
holding the regular rw_sem. As such, we can avoid the queue handling and
locking overhead (although we currently end up taking the waitqueue
spinlock fastpath, so it wouldn't be a very big an impact).

Signed-off-by: Davidlohr Bueso 
---
include/linux/percpu-rwsem.h  |  5 ++---
kernel/locking/percpu-rwsem.c | 26 +-
2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 5b2e6159b744..9942b7e8bde8 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -4,7 +4,6 @@
#include 
#include 
#include 
-#include 
#include 
#include 

@@ -12,7 +11,7 @@ struct percpu_rw_semaphore {
struct rcu_sync rss;
unsigned int __percpu   *read_count;
struct rw_semaphore rw_sem;
-   wait_queue_head_t   writer;
+   struct task_struct  *writer; /* blocked writer */
int readers_block;
};

@@ -22,7 +21,7 @@ static struct percpu_rw_semaphore name = {
\
.rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC),\
.read_count = &__percpu_rwsem_rc_##name,\
.rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
-   .writer = __WAIT_QUEUE_HEAD_INITIALIZER(name.writer),   \
+   .writer = NULL, \
}

extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index ce182599cf2e..7856a77396d3 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -1,7 +1,6 @@
#include 
#include 
#include 
-#include 
#include 
#include 
#include 
@@ -18,7 +17,7 @@ int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
/* ->rw_sem represents the whole percpu_rw_semaphore for lockdep */
rcu_sync_init(>rss, RCU_SCHED_SYNC);
__init_rwsem(>rw_sem, name, rwsem_key);
-   init_waitqueue_head(>writer);
+   sem->writer = NULL;
sem->readers_block = 0;
return 0;
}
@@ -94,6 +93,8 @@ EXPORT_SYMBOL_GPL(__percpu_down_read);

void __percpu_up_read(struct percpu_rw_semaphore *sem)
{
+   struct task_struct *writer;
+
smp_mb(); /* B matches C */
/*
 * In other words, if they see our decrement (presumably to aggregate
@@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem)
 */
__this_cpu_dec(*sem->read_count);

+   rcu_read_lock();
+   writer = rcu_dereference(sem->writer);
+
/* Prod writer to recheck readers_active */
-   wake_up(>writer);
+   if (writer)
+   wake_up_process(writer);
+   rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(__percpu_up_read);

@@ -159,8 +165,18 @@ void percpu_down_write(struct percpu_rw_semaphore *sem)
 * will wait for them.
 */

-   /* Wait for all now active readers to complete. */
-   wait_event(sem->writer, readers_active_check(sem));
+   WRITE_ONCE(sem->writer, current);
+   for (;;) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+
+   if (readers_active_check(sem))
+   break;
+
+   schedule();
+   }
+
+   rcu_assign_pointer(sem->writer, NULL);
+   __set_current_state(TASK_RUNNING);
}
EXPORT_SYMBOL_GPL(percpu_down_write);

--
2.6.6

Re: [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure

[Rafael J. Wysocki]

On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
 wrote:
> Rafael, Mark, Suravee,
>
> On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
>> On DT based systems, the of_dma_configure() API implements DMA
>> configuration for a given device. On ACPI systems an API equivalent to
>> of_dma_configure() is missing which implies that it is currently not
>> possible to set-up DMA operations for devices through the ACPI generic
>> kernel layer.
>>
>> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
>> calls that for now are just wrappers around arch_setup_dma_ops() and
>> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
>> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>>
>> Since acpi_dma_configure() is used to configure DMA operations, the
>> function initializes the dma/coherent_dma masks to sane default values
>> if the current masks are uninitialized (also to keep the default values
>> consistent with DT systems) to make sure the device has a complete
>> default DMA set-up.
>
> I spotted a niggle that unfortunately was hard to spot (and should not
> be a problem per se but better safe than sorry) and I am not comfortable
> with it.
>
> Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
> device coherency") in acpi_bind_one() we check if the acpi_device
> associated with a device just added supports DMA, first it was
> done with acpi_check_dma() and then commit 1831eff876bd ("device
> property: ACPI: Make use of the new DMA Attribute APIs") changed
> it to acpi_get_dma_attr().
>
> The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
> on _any_ acpi device we pass to acpi_bind_one() on x86, which was
> fine because we used it to call arch_setup_dma_ops(), which is a nop
> on x86. On ARM64 a _CCA method is required to define if a device
> supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
>
> Now, acpi_bind_one() is used to bind an acpi_device to its physical
> node also for pseudo-devices like cpus and memory nodes. For those
> objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
>
> So far so good, because on x86 arch_setup_dma_ops() is empty code.
>
> With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
> to call acpi_dma_configure() which is basically a nop on x86 except
> that it sets up the dma_mask/coherent_dma_mask to a sane default value
> (after all we are setting up DMA for the device so it makes sense to
> initialize the masks there if they were unset since we are configuring
> DMA for the device in question) for the given device.
>
> Problem is, as per the explanation above, we are also setting the
> default dma masks for pseudo-devices (eg CPUs) that were previously
> untouched, it should not be a problem per-se but I am not comfortable
> with that, honestly it does not make much sense.
>
> An easy "fix" would be to move the default dma masks initialization out
> of acpi_dma_configure() (as it was in previous patch versions of this
> series - I moved it to acpi_dma_configure() just a consolidation point
> for initializing the masks instead of scattering them in every
> acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
> we think that's the right thing to do (or I can send it to Rafael later
> when the code is in the merged depending on the timing) just let me
> know please.

Why can't arch_setup_dma_ops() set those masks too?

Thanks,
Rafael

Re: [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure

[Rafael J. Wysocki]

On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
 wrote:
> Rafael, Mark, Suravee,
>
> On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
>> On DT based systems, the of_dma_configure() API implements DMA
>> configuration for a given device. On ACPI systems an API equivalent to
>> of_dma_configure() is missing which implies that it is currently not
>> possible to set-up DMA operations for devices through the ACPI generic
>> kernel layer.
>>
>> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
>> calls that for now are just wrappers around arch_setup_dma_ops() and
>> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
>> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>>
>> Since acpi_dma_configure() is used to configure DMA operations, the
>> function initializes the dma/coherent_dma masks to sane default values
>> if the current masks are uninitialized (also to keep the default values
>> consistent with DT systems) to make sure the device has a complete
>> default DMA set-up.
>
> I spotted a niggle that unfortunately was hard to spot (and should not
> be a problem per se but better safe than sorry) and I am not comfortable
> with it.
>
> Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
> device coherency") in acpi_bind_one() we check if the acpi_device
> associated with a device just added supports DMA, first it was
> done with acpi_check_dma() and then commit 1831eff876bd ("device
> property: ACPI: Make use of the new DMA Attribute APIs") changed
> it to acpi_get_dma_attr().
>
> The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
> on _any_ acpi device we pass to acpi_bind_one() on x86, which was
> fine because we used it to call arch_setup_dma_ops(), which is a nop
> on x86. On ARM64 a _CCA method is required to define if a device
> supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
>
> Now, acpi_bind_one() is used to bind an acpi_device to its physical
> node also for pseudo-devices like cpus and memory nodes. For those
> objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
>
> So far so good, because on x86 arch_setup_dma_ops() is empty code.
>
> With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
> to call acpi_dma_configure() which is basically a nop on x86 except
> that it sets up the dma_mask/coherent_dma_mask to a sane default value
> (after all we are setting up DMA for the device so it makes sense to
> initialize the masks there if they were unset since we are configuring
> DMA for the device in question) for the given device.
>
> Problem is, as per the explanation above, we are also setting the
> default dma masks for pseudo-devices (eg CPUs) that were previously
> untouched, it should not be a problem per-se but I am not comfortable
> with that, honestly it does not make much sense.
>
> An easy "fix" would be to move the default dma masks initialization out
> of acpi_dma_configure() (as it was in previous patch versions of this
> series - I moved it to acpi_dma_configure() just a consolidation point
> for initializing the masks instead of scattering them in every
> acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
> we think that's the right thing to do (or I can send it to Rafael later
> when the code is in the merged depending on the timing) just let me
> know please.

Why can't arch_setup_dma_ops() set those masks too?

Thanks,
Rafael

[PATCH] net: ethernet: ti: cpdma: use desc_read in chan_process instead of raw read

[Ivan Khoronzhuk]

There is desc_read() macros to read desc fields, so no need to
use __raw_readl();

Signed-off-by: Ivan Khoronzhuk 
---
Based on net-next/master

 drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index c776e45..d96dca5 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -1132,7 +1132,7 @@ static int __cpdma_chan_process(struct cpdma_chan *chan)
}
desc_dma = desc_phys(pool, desc);
 
-   status  = __raw_readl(>hw_mode);
+   status = desc_read(desc, hw_mode);
outlen  = status & 0x7ff;
if (status & CPDMA_DESC_OWNER) {
chan->stats.busy_dequeue++;
-- 
2.7.4

[PATCH] net: ethernet: ti: cpdma: use desc_read in chan_process instead of raw read

[Ivan Khoronzhuk]

There is desc_read() macros to read desc fields, so no need to
use __raw_readl();

Signed-off-by: Ivan Khoronzhuk 
---
Based on net-next/master

 drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index c776e45..d96dca5 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -1132,7 +1132,7 @@ static int __cpdma_chan_process(struct cpdma_chan *chan)
}
desc_dma = desc_phys(pool, desc);
 
-   status  = __raw_readl(>hw_mode);
+   status = desc_read(desc, hw_mode);
outlen  = status & 0x7ff;
if (status & CPDMA_DESC_OWNER) {
chan->stats.busy_dequeue++;
-- 
2.7.4

Re: [PATCH v2] ACPI: Document _OSI and _REV for Linux BIOS writers

[Rafael J. Wysocki]

On Friday, December 02, 2016 09:14:48 PM Lukas Wunner wrote:
> On Wed, Nov 30, 2016 at 11:00:30PM -0500, Len Brown wrote:
> > From: Len Brown 
> > 
> > Based on a recent session at the Linux Plumber's Conference,
> > we need to be more clear about how a BIOS should use _OSI
> > to properly support Linux.
> > 
> > Signed-off-by: Len Brown 
> 
> Reviewed-by: Lukas Wunner 

Applied.

Thanks,
Rafael

Re: [PATCH v2] ACPI: Document _OSI and _REV for Linux BIOS writers

[Rafael J. Wysocki]

On Friday, December 02, 2016 09:14:48 PM Lukas Wunner wrote:
> On Wed, Nov 30, 2016 at 11:00:30PM -0500, Len Brown wrote:
> > From: Len Brown 
> > 
> > Based on a recent session at the Linux Plumber's Conference,
> > we need to be more clear about how a BIOS should use _OSI
> > to properly support Linux.
> > 
> > Signed-off-by: Len Brown 
> 
> Reviewed-by: Lukas Wunner 

Applied.

Thanks,
Rafael

Re: include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

[Andy Ritger]

This seems consistent with the spirit of DEBUG_MUTEX in non-RT kernels,
so hopefully this is acceptable to the RT maintainers.

Reviewed-by: Andy Ritger 

Thanks,
- Andy

On Tue, Oct 25, 2016 at 07:03:51PM -0700, Alex Goins wrote:
> mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When
> mutex_destroy is indirectly used by non-GPL kernel modules that use inline
> functions such as reservation_object_fini(), users can use a kernel with
> DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol
> mutex_destroy.
> 
> The RT Linux patches replace mutex_destroy with rt_mutex_destroy.
> Currently, rt_mutex_destroy is GPL_ONLY irrespective of whether mutex
> debugging is enabled.
> 
> This patch aligns rt_mutex_destroy with mutex_destroy by using the same
> no-op inline technique. This allows non-GPL modules to access the same
> functionality with RT Linux as with regular Linux.
> 
> Signed-off-by: Alex Goins 
> ---
>  include/linux/rtmutex.h  | 7 ++-
>  kernel/locking/rtmutex.c | 5 ++---
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
> index 1abba5c..741e844 100644
> --- a/include/linux/rtmutex.h
> +++ b/include/linux/rtmutex.h
> @@ -56,6 +56,12 @@ struct hrtimer_sleeper;
>  #endif
>  
>  #ifdef CONFIG_DEBUG_RT_MUTEXES
> + extern void rt_mutex_destroy(struct rt_mutex *lock);
> +#else
> + static inline void rt_mutex_destroy(struct rt_mutex *lock) {}
> +#endif
> +
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
>  # define __DEBUG_RT_MUTEX_INITIALIZER(mutexname) \
>   , .name = #mutexname, .file = __FILE__, .line = __LINE__
>  # define rt_mutex_init(mutex)__rt_mutex_init(mutex, 
> __func__)
> @@ -87,7 +93,6 @@ static inline int rt_mutex_is_locked(struct rt_mutex *lock)
>  }
>  
>  extern void __rt_mutex_init(struct rt_mutex *lock, const char *name);
> -extern void rt_mutex_destroy(struct rt_mutex *lock);
>  
>  extern void rt_mutex_lock(struct rt_mutex *lock);
>  extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 1ec0f48..8d3a80e 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1513,6 +1513,7 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex 
> *lock,
>   return rt_mutex_slowunlock(lock, wqh);
>  }
>  
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
>  /**
>   * rt_mutex_destroy - mark a mutex unusable
>   * @lock: the mutex to be destroyed
> @@ -1524,12 +1525,10 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex 
> *lock,
>  void rt_mutex_destroy(struct rt_mutex *lock)
>  {
>   WARN_ON(rt_mutex_is_locked(lock));
> -#ifdef CONFIG_DEBUG_RT_MUTEXES
>   lock->magic = NULL;
> -#endif
>  }
> -
>  EXPORT_SYMBOL_GPL(rt_mutex_destroy);
> +#endif
>  
>  /**
>   * __rt_mutex_init - initialize the rt lock

Re: include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

[Andy Ritger]

This seems consistent with the spirit of DEBUG_MUTEX in non-RT kernels,
so hopefully this is acceptable to the RT maintainers.

Reviewed-by: Andy Ritger 

Thanks,
- Andy

On Tue, Oct 25, 2016 at 07:03:51PM -0700, Alex Goins wrote:
> mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When
> mutex_destroy is indirectly used by non-GPL kernel modules that use inline
> functions such as reservation_object_fini(), users can use a kernel with
> DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol
> mutex_destroy.
> 
> The RT Linux patches replace mutex_destroy with rt_mutex_destroy.
> Currently, rt_mutex_destroy is GPL_ONLY irrespective of whether mutex
> debugging is enabled.
> 
> This patch aligns rt_mutex_destroy with mutex_destroy by using the same
> no-op inline technique. This allows non-GPL modules to access the same
> functionality with RT Linux as with regular Linux.
> 
> Signed-off-by: Alex Goins 
> ---
>  include/linux/rtmutex.h  | 7 ++-
>  kernel/locking/rtmutex.c | 5 ++---
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
> index 1abba5c..741e844 100644
> --- a/include/linux/rtmutex.h
> +++ b/include/linux/rtmutex.h
> @@ -56,6 +56,12 @@ struct hrtimer_sleeper;
>  #endif
>  
>  #ifdef CONFIG_DEBUG_RT_MUTEXES
> + extern void rt_mutex_destroy(struct rt_mutex *lock);
> +#else
> + static inline void rt_mutex_destroy(struct rt_mutex *lock) {}
> +#endif
> +
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
>  # define __DEBUG_RT_MUTEX_INITIALIZER(mutexname) \
>   , .name = #mutexname, .file = __FILE__, .line = __LINE__
>  # define rt_mutex_init(mutex)__rt_mutex_init(mutex, 
> __func__)
> @@ -87,7 +93,6 @@ static inline int rt_mutex_is_locked(struct rt_mutex *lock)
>  }
>  
>  extern void __rt_mutex_init(struct rt_mutex *lock, const char *name);
> -extern void rt_mutex_destroy(struct rt_mutex *lock);
>  
>  extern void rt_mutex_lock(struct rt_mutex *lock);
>  extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 1ec0f48..8d3a80e 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1513,6 +1513,7 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex 
> *lock,
>   return rt_mutex_slowunlock(lock, wqh);
>  }
>  
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
>  /**
>   * rt_mutex_destroy - mark a mutex unusable
>   * @lock: the mutex to be destroyed
> @@ -1524,12 +1525,10 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex 
> *lock,
>  void rt_mutex_destroy(struct rt_mutex *lock)
>  {
>   WARN_ON(rt_mutex_is_locked(lock));
> -#ifdef CONFIG_DEBUG_RT_MUTEXES
>   lock->magic = NULL;
> -#endif
>  }
> -
>  EXPORT_SYMBOL_GPL(rt_mutex_destroy);
> +#endif
>  
>  /**
>   * __rt_mutex_init - initialize the rt lock

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner  wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner 
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

Looks like Ben had a patch:

https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs=711da2570cd3302d0cb9f2489a101e4a7c966a6c

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner  wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner 
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

Looks like Ben had a patch:

https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs=711da2570cd3302d0cb9f2489a101e4a7c966a6c

Re: [PATCH] clk: uniphier: Fix build with gcc-4.4.

[Masahiro Yamada]

Hi Vinson,

2016-12-03 9:37 GMT+09:00 Vinson Lee :
> gcc-4.4 has issues with anonymous unions in initializers.
>
>   CC  drivers/clk/uniphier/clk-uniphier-sys.o
> drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ‘factor’ 
> specified in initializer
>
> Fixes: 1574d5722636 ("clk: uniphier: remove unneeded member name for union")
> Signed-off-by: Vinson Lee 


This driver has COMPILE_TEST option, but kbuild test robot
did not mention about this.



This is a bad way of fixing, I think.
(what if a new member is inserted before the union in the future?)

Rather, please revert the bad commit.


> .name = "sd" #ch "-sel",\
> .type = UNIPHIER_CLK_TYPE_MUX,  \
> .idx = -1,  \
> -   .mux = {\
> +   { .mux = {  \
> .parent_names = {   \
> "sd-44m",   \
> "sd-33m",   \
> @@ -63,7 +63,7 @@
> 0x1200, \
> 0x1300, \
> },  \
> -   },  \
> +   } },\
> },  \


No, please do not do this.






-- 
Best Regards
Masahiro Yamada

Re: [PATCH] clk: uniphier: Fix build with gcc-4.4.

[Masahiro Yamada]

Hi Vinson,

2016-12-03 9:37 GMT+09:00 Vinson Lee :
> gcc-4.4 has issues with anonymous unions in initializers.
>
>   CC  drivers/clk/uniphier/clk-uniphier-sys.o
> drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ‘factor’ 
> specified in initializer
>
> Fixes: 1574d5722636 ("clk: uniphier: remove unneeded member name for union")
> Signed-off-by: Vinson Lee 


This driver has COMPILE_TEST option, but kbuild test robot
did not mention about this.



This is a bad way of fixing, I think.
(what if a new member is inserted before the union in the future?)

Rather, please revert the bad commit.


> .name = "sd" #ch "-sel",\
> .type = UNIPHIER_CLK_TYPE_MUX,  \
> .idx = -1,  \
> -   .mux = {\
> +   { .mux = {  \
> .parent_names = {   \
> "sd-44m",   \
> "sd-33m",   \
> @@ -63,7 +63,7 @@
> 0x1200, \
> 0x1300, \
> },  \
> -   },  \
> +   } },\
> },  \


No, please do not do this.






-- 
Best Regards
Masahiro Yamada

Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'

[kbuild test robot]

Hi Arnd,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/liquidio-imply-ptp-instead-of-select/20161203-084019
config: x86_64-allmodconfig
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
make ARCH=x86_64  allmodconfig
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [allmodconfig] Error 1
   make[1]: *** [allmodconfig] Error 2
   make: *** [sub-make] Error 2
--
>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [oldconfig] Error 1
   make[1]: *** [oldconfig] Error 2
   make: *** [sub-make] Error 2
--
>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [olddefconfig] Error 1
   make[2]: Target 'oldnoconfig' not remade because of errors.
   make[1]: *** [oldnoconfig] Error 2
   make: *** [sub-make] Error 2

vim +81 drivers/net/ethernet/cavium/Kconfig

d07a147f David Daney 2016-03-14  74   port on Cavium Networks' 
Octeon CN57XX, CN56XX, CN55XX,
d07a147f David Daney 2016-03-14  75   CN54XX, CN52XX, and CN6XXX 
chips.
d07a147f David Daney 2016-03-14  76  
111fc64a Raghu Vatsavayi 2016-11-28  77  config LIQUIDIO_VF
111fc64a Raghu Vatsavayi 2016-11-28  78 tristate "Cavium LiquidIO VF 
support"
111fc64a Raghu Vatsavayi 2016-11-28  79 depends on 64BIT && PCI_MSI
2d6e65ca Arnd Bergmann   2016-12-03 @80 imply PTP_1588_CLOCK
111fc64a Raghu Vatsavayi 2016-11-28 @81 ---help---
111fc64a Raghu Vatsavayi 2016-11-28  82   This driver supports Cavium 
LiquidIO Intelligent Server Adapter
111fc64a Raghu Vatsavayi 2016-11-28  83   based on CN23XX chips.
111fc64a Raghu Vatsavayi 2016-11-28  84  

:: The code at line 81 was first introduced by commit
:: 111fc64a237f231bc2d3187bdf8358eb7966e6a9 liquidio CN23XX: VF registration

:: TO: Raghu Vatsavayi 
:: CC: David S. Miller 

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

Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'

[kbuild test robot]

Hi Arnd,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/liquidio-imply-ptp-instead-of-select/20161203-084019
config: x86_64-allmodconfig
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
make ARCH=x86_64  allmodconfig
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [allmodconfig] Error 1
   make[1]: *** [allmodconfig] Error 2
   make: *** [sub-make] Error 2
--
>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [oldconfig] Error 1
   make[1]: *** [oldconfig] Error 2
   make: *** [sub-make] Error 2
--
>> drivers/net/ethernet/cavium/Kconfig:81: syntax error
>> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply"
   make[2]: *** [olddefconfig] Error 1
   make[2]: Target 'oldnoconfig' not remade because of errors.
   make[1]: *** [oldnoconfig] Error 2
   make: *** [sub-make] Error 2

vim +81 drivers/net/ethernet/cavium/Kconfig

d07a147f David Daney 2016-03-14  74   port on Cavium Networks' 
Octeon CN57XX, CN56XX, CN55XX,
d07a147f David Daney 2016-03-14  75   CN54XX, CN52XX, and CN6XXX 
chips.
d07a147f David Daney 2016-03-14  76  
111fc64a Raghu Vatsavayi 2016-11-28  77  config LIQUIDIO_VF
111fc64a Raghu Vatsavayi 2016-11-28  78 tristate "Cavium LiquidIO VF 
support"
111fc64a Raghu Vatsavayi 2016-11-28  79 depends on 64BIT && PCI_MSI
2d6e65ca Arnd Bergmann   2016-12-03 @80 imply PTP_1588_CLOCK
111fc64a Raghu Vatsavayi 2016-11-28 @81 ---help---
111fc64a Raghu Vatsavayi 2016-11-28  82   This driver supports Cavium 
LiquidIO Intelligent Server Adapter
111fc64a Raghu Vatsavayi 2016-11-28  83   based on CN23XX chips.
111fc64a Raghu Vatsavayi 2016-11-28  84  

:: The code at line 81 was first introduced by commit
:: 111fc64a237f231bc2d3187bdf8358eb7966e6a9 liquidio CN23XX: VF registration

:: TO: Raghu Vatsavayi 
:: CC: David S. Miller 

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

[PATCH 20/22] staging: lustre: osc: set lock data for readahead lock

[James Simmons]

From: Jinshan Xiong 

If osc_io_readahead() finds a lock that belongs to the previous
instance of osc_object, the lock data pointer will be null. It has
to instantiate with new instance otherwise those pages won't be
destroyed at lock cancel, and then finally hit the assertion in
osc_req_attr_set().

This patch revised dlmlock_at_pgoff() to call osc_match_base() to
find caching locks for readahead. And new osc_object will be set
to the lock if it doesn't have one yet.

Signed-off-by: Jinshan Xiong 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8005
Reviewed-on: http://review.whamcloud.com/19453
Reviewed-by: Bobi Jam 
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/osc/osc_io.c  |1 +
 drivers/staging/lustre/lustre/osc/osc_lock.c|7 +--
 drivers/staging/lustre/lustre/osc/osc_request.c |   49 ++
 3 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_io.c 
b/drivers/staging/lustre/lustre/osc/osc_io.c
index 369761f..d96f4f2 100644
--- a/drivers/staging/lustre/lustre/osc/osc_io.c
+++ b/drivers/staging/lustre/lustre/osc/osc_io.c
@@ -88,6 +88,7 @@ static int osc_io_read_ahead(const struct lu_env *env,
 
dlmlock = osc_dlmlock_at_pgoff(env, osc, start, 0);
if (dlmlock) {
+   LASSERT(dlmlock->l_ast_data == osc);
if (dlmlock->l_req_mode != LCK_PR) {
struct lustre_handle lockh;
 
diff --git a/drivers/staging/lustre/lustre/osc/osc_lock.c 
b/drivers/staging/lustre/lustre/osc/osc_lock.c
index 130460d..001fe75 100644
--- a/drivers/staging/lustre/lustre/osc/osc_lock.c
+++ b/drivers/staging/lustre/lustre/osc/osc_lock.c
@@ -1205,10 +1205,9 @@ struct ldlm_lock *osc_dlmlock_at_pgoff(const struct 
lu_env *env,
 * with a uniq gid and it conflicts with all other lock modes too
 */
 again:
-   mode = ldlm_lock_match(osc_export(obj)->exp_obd->obd_namespace,
-  flags, resname, LDLM_EXTENT, policy,
-  LCK_PR | LCK_PW | LCK_GROUP, ,
-  dap_flags & OSC_DAP_FL_CANCELING);
+   mode = osc_match_base(osc_export(obj), resname, LDLM_EXTENT, policy,
+ LCK_PR | LCK_PW | LCK_GROUP, , obj, ,
+ dap_flags & OSC_DAP_FL_CANCELING);
if (mode != 0) {
lock = ldlm_handle2lock();
/* RACE: the lock is cancelled so let's try again */
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index bc698d3..0977127 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -1813,16 +1813,11 @@ int osc_build_rpc(const struct lu_env *env, struct 
client_obd *cli,
return rc;
 }
 
-static int osc_set_lock_data_with_check(struct ldlm_lock *lock,
-   struct ldlm_enqueue_info *einfo)
+static int osc_set_lock_data(struct ldlm_lock *lock, void *data)
 {
-   void *data = einfo->ei_cbdata;
int set = 0;
 
-   LASSERT(lock->l_blocking_ast == einfo->ei_cb_bl);
-   LASSERT(lock->l_resource->lr_type == einfo->ei_type);
-   LASSERT(lock->l_completion_ast == einfo->ei_cb_cp);
-   LASSERT(lock->l_glimpse_ast == einfo->ei_cb_gl);
+   LASSERT(lock);
 
lock_res_and_lock(lock);
 
@@ -1836,21 +1831,6 @@ static int osc_set_lock_data_with_check(struct ldlm_lock 
*lock,
return set;
 }
 
-static int osc_set_data_with_check(struct lustre_handle *lockh,
-  struct ldlm_enqueue_info *einfo)
-{
-   struct ldlm_lock *lock = ldlm_handle2lock(lockh);
-   int set = 0;
-
-   if (lock) {
-   set = osc_set_lock_data_with_check(lock, einfo);
-   LDLM_LOCK_PUT(lock);
-   } else
-   CERROR("lockh %p, data %p - client evicted?\n",
-  lockh, einfo->ei_cbdata);
-   return set;
-}
-
 static int osc_enqueue_fini(struct ptlrpc_request *req,
osc_enqueue_upcall_f upcall, void *cookie,
struct lustre_handle *lockh, enum ldlm_mode mode,
@@ -2016,7 +1996,7 @@ int osc_enqueue_base(struct obd_export *exp, struct 
ldlm_res_id *res_id,
ldlm_lock_decref(, mode);
LDLM_LOCK_PUT(matched);
return -ECANCELED;
-   } else if (osc_set_lock_data_with_check(matched, einfo)) {
+   } else if (osc_set_lock_data(matched, einfo->ei_cbdata)) {
*flags |= LDLM_FL_LVB_READY;
/* We already have a lock, and it's referenced. */
(*upcall)(cookie, 

[PATCH 20/22] staging: lustre: osc: set lock data for readahead lock

[James Simmons]

From: Jinshan Xiong 

If osc_io_readahead() finds a lock that belongs to the previous
instance of osc_object, the lock data pointer will be null. It has
to instantiate with new instance otherwise those pages won't be
destroyed at lock cancel, and then finally hit the assertion in
osc_req_attr_set().

This patch revised dlmlock_at_pgoff() to call osc_match_base() to
find caching locks for readahead. And new osc_object will be set
to the lock if it doesn't have one yet.

Signed-off-by: Jinshan Xiong 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8005
Reviewed-on: http://review.whamcloud.com/19453
Reviewed-by: Bobi Jam 
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/osc/osc_io.c  |1 +
 drivers/staging/lustre/lustre/osc/osc_lock.c|7 +--
 drivers/staging/lustre/lustre/osc/osc_request.c |   49 ++
 3 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_io.c 
b/drivers/staging/lustre/lustre/osc/osc_io.c
index 369761f..d96f4f2 100644
--- a/drivers/staging/lustre/lustre/osc/osc_io.c
+++ b/drivers/staging/lustre/lustre/osc/osc_io.c
@@ -88,6 +88,7 @@ static int osc_io_read_ahead(const struct lu_env *env,
 
dlmlock = osc_dlmlock_at_pgoff(env, osc, start, 0);
if (dlmlock) {
+   LASSERT(dlmlock->l_ast_data == osc);
if (dlmlock->l_req_mode != LCK_PR) {
struct lustre_handle lockh;
 
diff --git a/drivers/staging/lustre/lustre/osc/osc_lock.c 
b/drivers/staging/lustre/lustre/osc/osc_lock.c
index 130460d..001fe75 100644
--- a/drivers/staging/lustre/lustre/osc/osc_lock.c
+++ b/drivers/staging/lustre/lustre/osc/osc_lock.c
@@ -1205,10 +1205,9 @@ struct ldlm_lock *osc_dlmlock_at_pgoff(const struct 
lu_env *env,
 * with a uniq gid and it conflicts with all other lock modes too
 */
 again:
-   mode = ldlm_lock_match(osc_export(obj)->exp_obd->obd_namespace,
-  flags, resname, LDLM_EXTENT, policy,
-  LCK_PR | LCK_PW | LCK_GROUP, ,
-  dap_flags & OSC_DAP_FL_CANCELING);
+   mode = osc_match_base(osc_export(obj), resname, LDLM_EXTENT, policy,
+ LCK_PR | LCK_PW | LCK_GROUP, , obj, ,
+ dap_flags & OSC_DAP_FL_CANCELING);
if (mode != 0) {
lock = ldlm_handle2lock();
/* RACE: the lock is cancelled so let's try again */
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index bc698d3..0977127 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -1813,16 +1813,11 @@ int osc_build_rpc(const struct lu_env *env, struct 
client_obd *cli,
return rc;
 }
 
-static int osc_set_lock_data_with_check(struct ldlm_lock *lock,
-   struct ldlm_enqueue_info *einfo)
+static int osc_set_lock_data(struct ldlm_lock *lock, void *data)
 {
-   void *data = einfo->ei_cbdata;
int set = 0;
 
-   LASSERT(lock->l_blocking_ast == einfo->ei_cb_bl);
-   LASSERT(lock->l_resource->lr_type == einfo->ei_type);
-   LASSERT(lock->l_completion_ast == einfo->ei_cb_cp);
-   LASSERT(lock->l_glimpse_ast == einfo->ei_cb_gl);
+   LASSERT(lock);
 
lock_res_and_lock(lock);
 
@@ -1836,21 +1831,6 @@ static int osc_set_lock_data_with_check(struct ldlm_lock 
*lock,
return set;
 }
 
-static int osc_set_data_with_check(struct lustre_handle *lockh,
-  struct ldlm_enqueue_info *einfo)
-{
-   struct ldlm_lock *lock = ldlm_handle2lock(lockh);
-   int set = 0;
-
-   if (lock) {
-   set = osc_set_lock_data_with_check(lock, einfo);
-   LDLM_LOCK_PUT(lock);
-   } else
-   CERROR("lockh %p, data %p - client evicted?\n",
-  lockh, einfo->ei_cbdata);
-   return set;
-}
-
 static int osc_enqueue_fini(struct ptlrpc_request *req,
osc_enqueue_upcall_f upcall, void *cookie,
struct lustre_handle *lockh, enum ldlm_mode mode,
@@ -2016,7 +1996,7 @@ int osc_enqueue_base(struct obd_export *exp, struct 
ldlm_res_id *res_id,
ldlm_lock_decref(, mode);
LDLM_LOCK_PUT(matched);
return -ECANCELED;
-   } else if (osc_set_lock_data_with_check(matched, einfo)) {
+   } else if (osc_set_lock_data(matched, einfo->ei_cbdata)) {
*flags |= LDLM_FL_LVB_READY;
/* We already have a lock, and it's referenced. */
(*upcall)(cookie, , ELDLM_LOCK_MATCHED);
@@ -2128,19 +2108,18 @@ int osc_match_base(struct obd_export *exp, struct 
ldlm_res_id *res_id,
rc |= 

[PATCH 14/22] staging: lustre: obd: add callback for llog_cat_process_or_fork

[James Simmons]

From: Alexander Boyko 

Currently llog_process_or_fork() is hard coded to
always pass the function pointer llog_cat_process_cb().
Change llog_cat_process_or_fork() to pass in any
function pointer which will allow us more options
for llog_cat callback routines in the future.

Signed-off-by: Alexander Boyko 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7156
Seagate-bug-id: MRP-2383
Reviewed-on: http://review.whamcloud.com/16416
Reviewed-by: Andreas Dilger 
Reviewed-by: Nathaniel Clark 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/llog_cat.c |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/llog_cat.c 
b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
index ce8e2f6..de9d01d 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog_cat.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
@@ -188,7 +188,8 @@ static int llog_cat_process_cb(const struct lu_env *env,
 
 static int llog_cat_process_or_fork(const struct lu_env *env,
struct llog_handle *cat_llh,
-   llog_cb_t cb, void *data, int startcat,
+   llog_cb_t cat_cb, llog_cb_t cb,
+   void *data, int startcat,
int startidx, bool fork)
 {
struct llog_process_data d;
@@ -209,18 +210,15 @@ static int llog_cat_process_or_fork(const struct lu_env 
*env,
 
cd.lpcd_first_idx = llh->llh_cat_idx;
cd.lpcd_last_idx = 0;
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , , fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , , fork);
if (rc != 0)
return rc;
 
cd.lpcd_first_idx = 0;
cd.lpcd_last_idx = cat_llh->lgh_last_idx;
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , , fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , , fork);
} else {
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , NULL, fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , NULL, fork);
}
 
return rc;
@@ -229,7 +227,7 @@ static int llog_cat_process_or_fork(const struct lu_env 
*env,
 int llog_cat_process(const struct lu_env *env, struct llog_handle *cat_llh,
 llog_cb_t cb, void *data, int startcat, int startidx)
 {
-   return llog_cat_process_or_fork(env, cat_llh, cb, data, startcat,
-   startidx, false);
+   return llog_cat_process_or_fork(env, cat_llh, llog_cat_process_cb, cb,
+   data, startcat, startidx, false);
 }
 EXPORT_SYMBOL(llog_cat_process);
-- 
1.7.1

[PATCH 14/22] staging: lustre: obd: add callback for llog_cat_process_or_fork

[James Simmons]

From: Alexander Boyko 

Currently llog_process_or_fork() is hard coded to
always pass the function pointer llog_cat_process_cb().
Change llog_cat_process_or_fork() to pass in any
function pointer which will allow us more options
for llog_cat callback routines in the future.

Signed-off-by: Alexander Boyko 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7156
Seagate-bug-id: MRP-2383
Reviewed-on: http://review.whamcloud.com/16416
Reviewed-by: Andreas Dilger 
Reviewed-by: Nathaniel Clark 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/llog_cat.c |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/llog_cat.c 
b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
index ce8e2f6..de9d01d 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog_cat.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
@@ -188,7 +188,8 @@ static int llog_cat_process_cb(const struct lu_env *env,
 
 static int llog_cat_process_or_fork(const struct lu_env *env,
struct llog_handle *cat_llh,
-   llog_cb_t cb, void *data, int startcat,
+   llog_cb_t cat_cb, llog_cb_t cb,
+   void *data, int startcat,
int startidx, bool fork)
 {
struct llog_process_data d;
@@ -209,18 +210,15 @@ static int llog_cat_process_or_fork(const struct lu_env 
*env,
 
cd.lpcd_first_idx = llh->llh_cat_idx;
cd.lpcd_last_idx = 0;
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , , fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , , fork);
if (rc != 0)
return rc;
 
cd.lpcd_first_idx = 0;
cd.lpcd_last_idx = cat_llh->lgh_last_idx;
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , , fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , , fork);
} else {
-   rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- , NULL, fork);
+   rc = llog_process_or_fork(env, cat_llh, cat_cb, , NULL, fork);
}
 
return rc;
@@ -229,7 +227,7 @@ static int llog_cat_process_or_fork(const struct lu_env 
*env,
 int llog_cat_process(const struct lu_env *env, struct llog_handle *cat_llh,
 llog_cb_t cb, void *data, int startcat, int startidx)
 {
-   return llog_cat_process_or_fork(env, cat_llh, cb, data, startcat,
-   startidx, false);
+   return llog_cat_process_or_fork(env, cat_llh, llog_cat_process_cb, cb,
+   data, startcat, startidx, false);
 }
 EXPORT_SYMBOL(llog_cat_process);
-- 
1.7.1

[PATCH] blk-stat: fix a typo

[Shaohua Li]

Signed-off-by: Shaohua Li 
---
 block/blk-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-stat.c b/block/blk-stat.c
index 688c958..4d01185 100644
--- a/block/blk-stat.c
+++ b/block/blk-stat.c
@@ -12,7 +12,7 @@
 static void blk_stat_flush_batch(struct blk_rq_stat *stat)
 {
const s32 nr_batch = READ_ONCE(stat->nr_batch);
-   const s32 nr_samples = READ_ONCE(stat->nr_batch);
+   const s32 nr_samples = READ_ONCE(stat->nr_samples);
 
if (!nr_batch)
return;
-- 
2.9.3

[PATCH] blk-stat: fix a typo

[Shaohua Li]

Signed-off-by: Shaohua Li 
---
 block/blk-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-stat.c b/block/blk-stat.c
index 688c958..4d01185 100644
--- a/block/blk-stat.c
+++ b/block/blk-stat.c
@@ -12,7 +12,7 @@
 static void blk_stat_flush_batch(struct blk_rq_stat *stat)
 {
const s32 nr_batch = READ_ONCE(stat->nr_batch);
-   const s32 nr_samples = READ_ONCE(stat->nr_batch);
+   const s32 nr_samples = READ_ONCE(stat->nr_samples);
 
if (!nr_batch)
return;
-- 
2.9.3

Re: [PATCH] usb: dwc2: fix flags for DMA descriptor allocation in dwc2_hsotg_ep_enable

[John Youn]

On 12/1/2016 1:02 AM, Marek Szyprowski wrote:
> dwc2_hsotg_ep_enable can be called from interrupt context, so all
> allocations should be done with GFP_ATOMIC flags. This fixes following
> issue on ARM architecture:
> 
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x74/0x94)
> [] (dump_stack) from [] (__warn+0xd4/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (smp_call_function_many+0xcc/0x2a4)
> [] (smp_call_function_many) from [] 
> (on_each_cpu_mask+0x38/0xa8)
> [] (on_each_cpu_mask) from [] 
> (start_isolate_page_range+0x134/0x1b8)
> [] (start_isolate_page_range) from [] 
> (alloc_contig_range+0xac/0x2f8)
> [] (alloc_contig_range) from [] (cma_alloc+0xe0/0x1a8)
> [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xe0)
> [] (__alloc_from_contiguous) from [] 
> (cma_allocator_alloc+0x30/0x38)
> [] (cma_allocator_alloc) from [] (__dma_alloc+0x1c0/0x2c8)
> [] (__dma_alloc) from [] (arm_dma_alloc+0x3c/0x48)
> [] (arm_dma_alloc) from [] 
> (dwc2_hsotg_ep_enable+0xec/0x46c)
> [] (dwc2_hsotg_ep_enable) from [] 
> (usb_ep_enable+0x2c/0x3c)
> [] (usb_ep_enable) from [] (ecm_set_alt+0xa8/0x154)
> [] (ecm_set_alt) from [] (composite_setup+0xd74/0x1540)
> [] (composite_setup) from [] 
> (dwc2_hsotg_complete_setup+0xb8/0x370)
> [] (dwc2_hsotg_complete_setup) from [] 
> (usb_gadget_giveback_request+0xc/0x10)
> [] (usb_gadget_giveback_request) from [] 
> (dwc2_hsotg_complete_request+0x78/0x128)
> [] (dwc2_hsotg_complete_request) from [] 
> (dwc2_hsotg_epint+0x69c/0x81c)
> [] (dwc2_hsotg_epint) from [] (dwc2_hsotg_irq+0xfc/0x748)
> [] (dwc2_hsotg_irq) from [] 
> (__handle_irq_event_percpu+0x58/0x140)
> [] (__handle_irq_event_percpu) from [] 
> (handle_irq_event_percpu+0x1c/0x58)
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x38/0x5c)
> [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xc4/0x19c)
> [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x18/0x28)
> [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x6c/0xe4)
> [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x50/0x9c)
> [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8)
> 
> Fixes: 5f54c54b0ba83 ("usb: dwc2: gadget: Add DDMA chain pointers to
> dwc2_hsotg_ep structure")
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/dwc2/gadget.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index b95930f20d90..c55db4aa54d6 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3753,7 +3753,7 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
>   hs_ep->desc_list = dma_alloc_coherent(hsotg->dev,
>   MAX_DMA_DESC_NUM_GENERIC *
>   sizeof(struct dwc2_dma_desc),
> - _ep->desc_list_dma, GFP_KERNEL);
> + _ep->desc_list_dma, GFP_ATOMIC);
>   if (!hs_ep->desc_list) {
>   ret = -ENOMEM;
>   goto error2;
> 

Acked-by: John Youn 

Regards,
John

Re: [PATCH] usb: dwc2: fix flags for DMA descriptor allocation in dwc2_hsotg_ep_enable

[John Youn]

On 12/1/2016 1:02 AM, Marek Szyprowski wrote:
> dwc2_hsotg_ep_enable can be called from interrupt context, so all
> allocations should be done with GFP_ATOMIC flags. This fixes following
> issue on ARM architecture:
> 
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x74/0x94)
> [] (dump_stack) from [] (__warn+0xd4/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (smp_call_function_many+0xcc/0x2a4)
> [] (smp_call_function_many) from [] 
> (on_each_cpu_mask+0x38/0xa8)
> [] (on_each_cpu_mask) from [] 
> (start_isolate_page_range+0x134/0x1b8)
> [] (start_isolate_page_range) from [] 
> (alloc_contig_range+0xac/0x2f8)
> [] (alloc_contig_range) from [] (cma_alloc+0xe0/0x1a8)
> [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xe0)
> [] (__alloc_from_contiguous) from [] 
> (cma_allocator_alloc+0x30/0x38)
> [] (cma_allocator_alloc) from [] (__dma_alloc+0x1c0/0x2c8)
> [] (__dma_alloc) from [] (arm_dma_alloc+0x3c/0x48)
> [] (arm_dma_alloc) from [] 
> (dwc2_hsotg_ep_enable+0xec/0x46c)
> [] (dwc2_hsotg_ep_enable) from [] 
> (usb_ep_enable+0x2c/0x3c)
> [] (usb_ep_enable) from [] (ecm_set_alt+0xa8/0x154)
> [] (ecm_set_alt) from [] (composite_setup+0xd74/0x1540)
> [] (composite_setup) from [] 
> (dwc2_hsotg_complete_setup+0xb8/0x370)
> [] (dwc2_hsotg_complete_setup) from [] 
> (usb_gadget_giveback_request+0xc/0x10)
> [] (usb_gadget_giveback_request) from [] 
> (dwc2_hsotg_complete_request+0x78/0x128)
> [] (dwc2_hsotg_complete_request) from [] 
> (dwc2_hsotg_epint+0x69c/0x81c)
> [] (dwc2_hsotg_epint) from [] (dwc2_hsotg_irq+0xfc/0x748)
> [] (dwc2_hsotg_irq) from [] 
> (__handle_irq_event_percpu+0x58/0x140)
> [] (__handle_irq_event_percpu) from [] 
> (handle_irq_event_percpu+0x1c/0x58)
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x38/0x5c)
> [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xc4/0x19c)
> [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x18/0x28)
> [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x6c/0xe4)
> [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x50/0x9c)
> [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8)
> 
> Fixes: 5f54c54b0ba83 ("usb: dwc2: gadget: Add DDMA chain pointers to
> dwc2_hsotg_ep structure")
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/dwc2/gadget.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index b95930f20d90..c55db4aa54d6 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3753,7 +3753,7 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
>   hs_ep->desc_list = dma_alloc_coherent(hsotg->dev,
>   MAX_DMA_DESC_NUM_GENERIC *
>   sizeof(struct dwc2_dma_desc),
> - _ep->desc_list_dma, GFP_KERNEL);
> + _ep->desc_list_dma, GFP_ATOMIC);
>   if (!hs_ep->desc_list) {
>   ret = -ENOMEM;
>   goto error2;
> 

Acked-by: John Youn 

Regards,
John

[PATCH 07/22] staging: lustre: obdclass: lu_site_purge() to handle purge-all

[James Simmons]

From: Alex Zhuravlev 

if the callers wants to purge all objects, then scanning
should start from the first bucket.

Signed-off-by: Alex Zhuravlev 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7038
Reviewed-on: http://review.whamcloud.com/18505
Reviewed-by: Mike Pershin 
Reviewed-by: Faccini Bruno 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/lu_object.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c 
b/drivers/staging/lustre/lustre/obdclass/lu_object.c
index 43868ed..a02aaa3 100644
--- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
@@ -338,7 +338,7 @@ int lu_site_purge(const struct lu_env *env, struct lu_site 
*s, int nr)
struct cfs_hash_bd  bd2;
struct list_head   dispose;
int   did_sth;
-   unsigned int start;
+   unsigned int start = 0;
int   count;
int   bnr;
unsigned int i;
@@ -351,7 +351,8 @@ int lu_site_purge(const struct lu_env *env, struct lu_site 
*s, int nr)
 * Under LRU list lock, scan LRU list and move unreferenced objects to
 * the dispose list, removing them from LRU and hash table.
 */
-   start = s->ls_purge_start;
+   if (nr != ~0)
+   start = s->ls_purge_start;
bnr = (nr == ~0) ? -1 : nr / (int)CFS_HASH_NBKT(s->ls_obj_hash) + 1;
  again:
/*
-- 
1.7.1

[PATCH 07/22] staging: lustre: obdclass: lu_site_purge() to handle purge-all

[James Simmons]

From: Alex Zhuravlev 

if the callers wants to purge all objects, then scanning
should start from the first bucket.

Signed-off-by: Alex Zhuravlev 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7038
Reviewed-on: http://review.whamcloud.com/18505
Reviewed-by: Mike Pershin 
Reviewed-by: Faccini Bruno 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/lu_object.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c 
b/drivers/staging/lustre/lustre/obdclass/lu_object.c
index 43868ed..a02aaa3 100644
--- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
@@ -338,7 +338,7 @@ int lu_site_purge(const struct lu_env *env, struct lu_site 
*s, int nr)
struct cfs_hash_bd  bd2;
struct list_head   dispose;
int   did_sth;
-   unsigned int start;
+   unsigned int start = 0;
int   count;
int   bnr;
unsigned int i;
@@ -351,7 +351,8 @@ int lu_site_purge(const struct lu_env *env, struct lu_site 
*s, int nr)
 * Under LRU list lock, scan LRU list and move unreferenced objects to
 * the dispose list, removing them from LRU and hash table.
 */
-   start = s->ls_purge_start;
+   if (nr != ~0)
+   start = s->ls_purge_start;
bnr = (nr == ~0) ? -1 : nr / (int)CFS_HASH_NBKT(s->ls_obj_hash) + 1;
  again:
/*
-- 
1.7.1

Re: [RFC][PATCH 1/3] phy: phy-hi6220-usb: Wire up extconn support to hikey's phy driver

[John Youn]

On 12/1/2016 12:12 PM, John Stultz wrote:
> On Thu, Dec 1, 2016 at 12:23 AM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Wednesday 23 November 2016 09:16 AM, John Stultz wrote:
>>> This wires extconn support to hikey's phy driver, and
>>> connects it to the usb UDC layer via a usb_phy structure.
>>>
>>> Not sure if this is the right way to connect phy -> UDC,
>>> but I'm lacking a clear example.
>>>
>>> Cc: Wei Xu 
>>> Cc: Guodong Xu 
>>> Cc: Amit Pundir 
>>> Cc: Rob Herring 
>>> Cc: John Youn 
>>> Cc: Douglas Anderson 
>>> Cc: Chen Yu 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: Felipe Balbi 
>>> Cc: Greg Kroah-Hartman 
>>> Cc: linux-...@vger.kernel.org
>>> Signed-off-by: John Stultz 
>>> ---
>>>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi |  11 +++
>>>  drivers/phy/Kconfig   |   2 +
>>>  drivers/phy/phy-hi6220-usb.c  | 139 
>>> ++
>>>  3 files changed, 152 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
>>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> index 17839db..171fbb2 100644
>>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> @@ -732,10 +732,21 @@
>>>   regulator-always-on;
>>>   };
>>>
>>> + usb_vbus: usb-vbus {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = < 6 1>;
>>> + };
>>> +
>>> + usb_id: usb-id {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = < 5 1>;
>>> + };
>>> +
>>>   usb_phy: usbphy {
>>>   compatible = "hisilicon,hi6220-usb-phy";
>>>   #phy-cells = <0>;
>>>   phy-supply = <_5v_hub>;
>>> + extcon = <_vbus>, <_id>;
>>>   hisilicon,peripheral-syscon = <_ctrl>;
>>>   };
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index fe00f91..76f4f17 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -254,8 +254,10 @@ config PHY_MT65XX_USB3
>>>  config PHY_HI6220_USB
>>>   tristate "hi6220 USB PHY support"
>>>   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
>>> + depends on EXTCON
>>>   select GENERIC_PHY
>>>   select MFD_SYSCON
>>> + select USB_PHY
>>>   help
>>> Enable this to support the HISILICON HI6220 USB PHY.
>>>
>>> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
>>> index b2141cb..89d8475 100644
>>> --- a/drivers/phy/phy-hi6220-usb.c
>>> +++ b/drivers/phy/phy-hi6220-usb.c
>>> @@ -12,7 +12,12 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>  #include 
>>> +#include 
>>>
>>>  #define SC_PERIPH_CTRL4  0x00c
>>>
>>> @@ -44,9 +49,21 @@
>>>
>>>  #define EYE_PATTERN_PARA 0x7053348c
>>>
>>> +
>>> +struct hi6220_usb_cable {
>>> + struct notifier_block   nb;
>>> + struct extcon_dev   *extcon;
>>> + int state;
>>> +};
>>> +
>>>  struct hi6220_priv {
>>>   struct regmap *reg;
>>>   struct device *dev;
>>> + struct usb_phy phy;
>>> +
>>> + struct delayed_work work;
>>> + struct hi6220_usb_cable vbus;
>>> + struct hi6220_usb_cable id;
>>>  };
>>>
>>>  static void hi6220_phy_init(struct hi6220_priv *priv)
>>> @@ -112,23 +129,85 @@ static int hi6220_phy_exit(struct phy *phy)
>>>   return hi6220_phy_setup(priv, false);
>>>  }
>>>
>>> +
>>>  static struct phy_ops hi6220_phy_ops = {
>>>   .init   = hi6220_phy_start,
>>>   .exit   = hi6220_phy_exit,
>>>   .owner  = THIS_MODULE,
>>>  };
>>>
>>> +static void hi6220_detect_work(struct work_struct *work)
>>> +{
>>> + struct hi6220_priv *priv =
>>> + container_of(to_delayed_work(work), struct hi6220_priv, work);
>>> + struct usb_otg *otg = priv->phy.otg;
>>> +
>>> + if (!IS_ERR(priv->vbus.extcon))
>>> + priv->vbus.state = extcon_get_cable_state_(priv->vbus.extcon,
>>> +  EXTCON_USB);
>>> + if (!IS_ERR(priv->id.extcon))
>>> + priv->id.state = extcon_get_cable_state_(priv->id.extcon,
>>> +  EXTCON_USB_HOST);
>>> + if (otg->gadget) {
>>> + if (priv->id.state)
>>> + usb_gadget_vbus_connect(otg->gadget);
>>> + else
>>> + usb_gadget_vbus_disconnect(otg->gadget);
>>> + }
>>> +}
>>> +
>>> +static int hi6220_otg_vbus_notifier(struct 

Re: [RFC][PATCH 1/3] phy: phy-hi6220-usb: Wire up extconn support to hikey's phy driver

[John Youn]

On 12/1/2016 12:12 PM, John Stultz wrote:
> On Thu, Dec 1, 2016 at 12:23 AM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Wednesday 23 November 2016 09:16 AM, John Stultz wrote:
>>> This wires extconn support to hikey's phy driver, and
>>> connects it to the usb UDC layer via a usb_phy structure.
>>>
>>> Not sure if this is the right way to connect phy -> UDC,
>>> but I'm lacking a clear example.
>>>
>>> Cc: Wei Xu 
>>> Cc: Guodong Xu 
>>> Cc: Amit Pundir 
>>> Cc: Rob Herring 
>>> Cc: John Youn 
>>> Cc: Douglas Anderson 
>>> Cc: Chen Yu 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: Felipe Balbi 
>>> Cc: Greg Kroah-Hartman 
>>> Cc: linux-...@vger.kernel.org
>>> Signed-off-by: John Stultz 
>>> ---
>>>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi |  11 +++
>>>  drivers/phy/Kconfig   |   2 +
>>>  drivers/phy/phy-hi6220-usb.c  | 139 
>>> ++
>>>  3 files changed, 152 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
>>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> index 17839db..171fbb2 100644
>>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> @@ -732,10 +732,21 @@
>>>   regulator-always-on;
>>>   };
>>>
>>> + usb_vbus: usb-vbus {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = < 6 1>;
>>> + };
>>> +
>>> + usb_id: usb-id {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = < 5 1>;
>>> + };
>>> +
>>>   usb_phy: usbphy {
>>>   compatible = "hisilicon,hi6220-usb-phy";
>>>   #phy-cells = <0>;
>>>   phy-supply = <_5v_hub>;
>>> + extcon = <_vbus>, <_id>;
>>>   hisilicon,peripheral-syscon = <_ctrl>;
>>>   };
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index fe00f91..76f4f17 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -254,8 +254,10 @@ config PHY_MT65XX_USB3
>>>  config PHY_HI6220_USB
>>>   tristate "hi6220 USB PHY support"
>>>   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
>>> + depends on EXTCON
>>>   select GENERIC_PHY
>>>   select MFD_SYSCON
>>> + select USB_PHY
>>>   help
>>> Enable this to support the HISILICON HI6220 USB PHY.
>>>
>>> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
>>> index b2141cb..89d8475 100644
>>> --- a/drivers/phy/phy-hi6220-usb.c
>>> +++ b/drivers/phy/phy-hi6220-usb.c
>>> @@ -12,7 +12,12 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>  #include 
>>> +#include 
>>>
>>>  #define SC_PERIPH_CTRL4  0x00c
>>>
>>> @@ -44,9 +49,21 @@
>>>
>>>  #define EYE_PATTERN_PARA 0x7053348c
>>>
>>> +
>>> +struct hi6220_usb_cable {
>>> + struct notifier_block   nb;
>>> + struct extcon_dev   *extcon;
>>> + int state;
>>> +};
>>> +
>>>  struct hi6220_priv {
>>>   struct regmap *reg;
>>>   struct device *dev;
>>> + struct usb_phy phy;
>>> +
>>> + struct delayed_work work;
>>> + struct hi6220_usb_cable vbus;
>>> + struct hi6220_usb_cable id;
>>>  };
>>>
>>>  static void hi6220_phy_init(struct hi6220_priv *priv)
>>> @@ -112,23 +129,85 @@ static int hi6220_phy_exit(struct phy *phy)
>>>   return hi6220_phy_setup(priv, false);
>>>  }
>>>
>>> +
>>>  static struct phy_ops hi6220_phy_ops = {
>>>   .init   = hi6220_phy_start,
>>>   .exit   = hi6220_phy_exit,
>>>   .owner  = THIS_MODULE,
>>>  };
>>>
>>> +static void hi6220_detect_work(struct work_struct *work)
>>> +{
>>> + struct hi6220_priv *priv =
>>> + container_of(to_delayed_work(work), struct hi6220_priv, work);
>>> + struct usb_otg *otg = priv->phy.otg;
>>> +
>>> + if (!IS_ERR(priv->vbus.extcon))
>>> + priv->vbus.state = extcon_get_cable_state_(priv->vbus.extcon,
>>> +  EXTCON_USB);
>>> + if (!IS_ERR(priv->id.extcon))
>>> + priv->id.state = extcon_get_cable_state_(priv->id.extcon,
>>> +  EXTCON_USB_HOST);
>>> + if (otg->gadget) {
>>> + if (priv->id.state)
>>> + usb_gadget_vbus_connect(otg->gadget);
>>> + else
>>> + usb_gadget_vbus_disconnect(otg->gadget);
>>> + }
>>> +}
>>> +
>>> +static int hi6220_otg_vbus_notifier(struct notifier_block *nb,
>>> + unsigned long event, void *ptr)
>>> +{
>>> + struct hi6220_usb_cable *vbus = container_of(nb,
>>> + struct hi6220_usb_cable, nb);
>>> + struct hi6220_priv *priv = 

[PATCH 21/22] staging: lustre: remove set but unused variables

[James Simmons]

From: Yang Sheng 

Remove set but unused variables in nidstring.c
and osc_request.c as reported by make W=1.

Signed-off-by: Yang Sheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8378
Reviewed-on: http://review.whamcloud.com/23221
Reviewed-by: Bob Glossman 
Reviewed-by: Emoly Liu 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lnet/lnet/nidstrings.c   |2 --
 drivers/staging/lustre/lustre/osc/osc_request.c |3 +--
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index e1f1ca8..a9fe3e6 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -247,10 +247,8 @@ struct addrrange {
 {
struct cfs_lstr addrrange;
struct cfs_lstr net;
-   struct cfs_lstr tmp;
struct nidrange *nr;
 
-   tmp = *src;
if (!cfs_gettok(src, '@', ))
goto failed;
 
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index 0977127..0c50225 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -933,7 +933,6 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
int i = 0;
struct cfs_crypto_hash_desc *hdesc;
unsigned int bufsize;
-   int err;
unsigned char cfs_alg = cksum_obd2cfs(cksum_type);
 
LASSERT(pg_count > 0);
@@ -975,7 +974,7 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
}
 
bufsize = sizeof(cksum);
-   err = cfs_crypto_hash_final(hdesc, (unsigned char *), );
+   cfs_crypto_hash_final(hdesc, (unsigned char *), );
 
/* For sending we only compute the wrong checksum instead
 * of corrupting the data so it is still correct on a redo
-- 
1.7.1

[PATCH 17/22] staging: lustre: clio: remove mtime check in vvp_io_fault_start()

[James Simmons]

From: Bobi Jam 

In fault IO initialization, inode's mtime is saved, and after
getting locks, when the IO is about to start, vvp_io_fault_start()
checks the mtime's intactness.

It's a false alarm, since the timestamp from MDS could be stale,
we maintain mtime mainly on OST objects, and if the check in
vvp_io_fault_start() happens before mtime on OST objects are merged,
it will get wrong timestamp from the inode, even the timestamp it
fetched in vvp_io_fault_init() could be wrong in the first place.

This patch remove the mtime check in vvp_io_fault_start().

Signed-off-by: Bobi Jam 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7198
Reviewed-on: http://review.whamcloud.com/19162
Reviewed-by: Andreas Dilger 
Reviewed-by: Jinshan Xiong 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/vvp_io.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/vvp_io.c 
b/drivers/staging/lustre/lustre/llite/vvp_io.c
index 114906d..0b6d388 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_io.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_io.c
@@ -1064,12 +1064,6 @@ static int vvp_io_fault_start(const struct lu_env *env,
loff_t size;
pgoff_t  last_index;
 
-   if (fio->ft_executable &&
-   inode->i_mtime.tv_sec != vio->u.fault.ft_mtime)
-   CWARN("binary "DFID
- " changed while waiting for the page fault lock\n",
- PFID(lu_object_fid(>co_lu)));
-
down_read(>lli_trunc_sem);
 
/* offset of the last byte on the page */
-- 
1.7.1

[PATCH 18/22] staging: lustre: import: don't reconnect during connect interpret

[James Simmons]

From: Mikhal Pershin 

The import connect flags might be cleared by ptlrpc_connect_import()
wrongly if there is still connect interpret function is running.

Use imp_connected boolean variable to indicate that we are still
interpretting connect reply and don't try to reconnect until it ends.

Signed-off-by: Mikhal Pershin 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7558
Reviewed-on: http://review.whamcloud.com/19312
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../staging/lustre/lustre/include/lustre_import.h  |4 +++-
 drivers/staging/lustre/lustre/ptlrpc/import.c  |   16 +++-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h 
b/drivers/staging/lustre/lustre/include/lustre_import.h
index 4499c69..f0c931c 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -299,7 +299,9 @@ struct obd_import {
   */
  imp_force_reconnect:1,
  /* import has tried to connect with server */
- imp_connect_tried:1;
+ imp_connect_tried:1,
+/* connected but not FULL yet */
+imp_connected:1;
__u32imp_connect_op;
struct obd_connect_data   imp_connect_data;
__u64imp_connect_flags_orig;
diff --git a/drivers/staging/lustre/lustre/ptlrpc/import.c 
b/drivers/staging/lustre/lustre/ptlrpc/import.c
index 66f5b49..e828019 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/import.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/import.c
@@ -622,7 +622,8 @@ int ptlrpc_connect_import(struct obd_import *imp)
spin_unlock(>imp_lock);
CERROR("already connected\n");
return 0;
-   } else if (imp->imp_state == LUSTRE_IMP_CONNECTING) {
+   } else if (imp->imp_state == LUSTRE_IMP_CONNECTING ||
+  imp->imp_connected) {
spin_unlock(>imp_lock);
CERROR("already connecting\n");
return -EALREADY;
@@ -971,6 +972,13 @@ static int ptlrpc_connect_interpret(const struct lu_env 
*env,
ptlrpc_maybe_ping_import_soon(imp);
goto out;
}
+
+   /*
+* LU-7558: indicate that we are interpretting connect reply,
+* pltrpc_connect_import() will not try to reconnect until
+* interpret will finish.
+*/
+   imp->imp_connected = 1;
spin_unlock(>imp_lock);
 
LASSERT(imp->imp_conn_current);
@@ -1194,12 +1202,18 @@ static int ptlrpc_connect_interpret(const struct lu_env 
*env,
   obd2cli_tgt(imp->imp_obd),
   imp->imp_connection->c_remote_uuid.uuid);
ptlrpc_connect_import(imp);
+   spin_lock(>imp_lock);
+   imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+   spin_unlock(>imp_lock);
return 0;
}
 
 out:
+   spin_lock(>imp_lock);
+   imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+   spin_unlock(>imp_lock);
 
if (rc != 0) {
IMPORT_SET_STATE(imp, LUSTRE_IMP_DISCON);
-- 
1.7.1

[PATCH 21/22] staging: lustre: remove set but unused variables

[James Simmons]

From: Yang Sheng 

Remove set but unused variables in nidstring.c
and osc_request.c as reported by make W=1.

Signed-off-by: Yang Sheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8378
Reviewed-on: http://review.whamcloud.com/23221
Reviewed-by: Bob Glossman 
Reviewed-by: Emoly Liu 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lnet/lnet/nidstrings.c   |2 --
 drivers/staging/lustre/lustre/osc/osc_request.c |3 +--
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index e1f1ca8..a9fe3e6 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -247,10 +247,8 @@ struct addrrange {
 {
struct cfs_lstr addrrange;
struct cfs_lstr net;
-   struct cfs_lstr tmp;
struct nidrange *nr;
 
-   tmp = *src;
if (!cfs_gettok(src, '@', ))
goto failed;
 
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index 0977127..0c50225 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -933,7 +933,6 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
int i = 0;
struct cfs_crypto_hash_desc *hdesc;
unsigned int bufsize;
-   int err;
unsigned char cfs_alg = cksum_obd2cfs(cksum_type);
 
LASSERT(pg_count > 0);
@@ -975,7 +974,7 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
}
 
bufsize = sizeof(cksum);
-   err = cfs_crypto_hash_final(hdesc, (unsigned char *), );
+   cfs_crypto_hash_final(hdesc, (unsigned char *), );
 
/* For sending we only compute the wrong checksum instead
 * of corrupting the data so it is still correct on a redo
-- 
1.7.1

[PATCH 17/22] staging: lustre: clio: remove mtime check in vvp_io_fault_start()

[James Simmons]

From: Bobi Jam 

In fault IO initialization, inode's mtime is saved, and after
getting locks, when the IO is about to start, vvp_io_fault_start()
checks the mtime's intactness.

It's a false alarm, since the timestamp from MDS could be stale,
we maintain mtime mainly on OST objects, and if the check in
vvp_io_fault_start() happens before mtime on OST objects are merged,
it will get wrong timestamp from the inode, even the timestamp it
fetched in vvp_io_fault_init() could be wrong in the first place.

This patch remove the mtime check in vvp_io_fault_start().

Signed-off-by: Bobi Jam 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7198
Reviewed-on: http://review.whamcloud.com/19162
Reviewed-by: Andreas Dilger 
Reviewed-by: Jinshan Xiong 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/vvp_io.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/vvp_io.c 
b/drivers/staging/lustre/lustre/llite/vvp_io.c
index 114906d..0b6d388 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_io.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_io.c
@@ -1064,12 +1064,6 @@ static int vvp_io_fault_start(const struct lu_env *env,
loff_t size;
pgoff_t  last_index;
 
-   if (fio->ft_executable &&
-   inode->i_mtime.tv_sec != vio->u.fault.ft_mtime)
-   CWARN("binary "DFID
- " changed while waiting for the page fault lock\n",
- PFID(lu_object_fid(>co_lu)));
-
down_read(>lli_trunc_sem);
 
/* offset of the last byte on the page */
-- 
1.7.1

[PATCH 18/22] staging: lustre: import: don't reconnect during connect interpret

[James Simmons]

From: Mikhal Pershin 

The import connect flags might be cleared by ptlrpc_connect_import()
wrongly if there is still connect interpret function is running.

Use imp_connected boolean variable to indicate that we are still
interpretting connect reply and don't try to reconnect until it ends.

Signed-off-by: Mikhal Pershin 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7558
Reviewed-on: http://review.whamcloud.com/19312
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../staging/lustre/lustre/include/lustre_import.h  |4 +++-
 drivers/staging/lustre/lustre/ptlrpc/import.c  |   16 +++-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h 
b/drivers/staging/lustre/lustre/include/lustre_import.h
index 4499c69..f0c931c 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -299,7 +299,9 @@ struct obd_import {
   */
  imp_force_reconnect:1,
  /* import has tried to connect with server */
- imp_connect_tried:1;
+ imp_connect_tried:1,
+/* connected but not FULL yet */
+imp_connected:1;
__u32imp_connect_op;
struct obd_connect_data   imp_connect_data;
__u64imp_connect_flags_orig;
diff --git a/drivers/staging/lustre/lustre/ptlrpc/import.c 
b/drivers/staging/lustre/lustre/ptlrpc/import.c
index 66f5b49..e828019 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/import.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/import.c
@@ -622,7 +622,8 @@ int ptlrpc_connect_import(struct obd_import *imp)
spin_unlock(>imp_lock);
CERROR("already connected\n");
return 0;
-   } else if (imp->imp_state == LUSTRE_IMP_CONNECTING) {
+   } else if (imp->imp_state == LUSTRE_IMP_CONNECTING ||
+  imp->imp_connected) {
spin_unlock(>imp_lock);
CERROR("already connecting\n");
return -EALREADY;
@@ -971,6 +972,13 @@ static int ptlrpc_connect_interpret(const struct lu_env 
*env,
ptlrpc_maybe_ping_import_soon(imp);
goto out;
}
+
+   /*
+* LU-7558: indicate that we are interpretting connect reply,
+* pltrpc_connect_import() will not try to reconnect until
+* interpret will finish.
+*/
+   imp->imp_connected = 1;
spin_unlock(>imp_lock);
 
LASSERT(imp->imp_conn_current);
@@ -1194,12 +1202,18 @@ static int ptlrpc_connect_interpret(const struct lu_env 
*env,
   obd2cli_tgt(imp->imp_obd),
   imp->imp_connection->c_remote_uuid.uuid);
ptlrpc_connect_import(imp);
+   spin_lock(>imp_lock);
+   imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+   spin_unlock(>imp_lock);
return 0;
}
 
 out:
+   spin_lock(>imp_lock);
+   imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+   spin_unlock(>imp_lock);
 
if (rc != 0) {
IMPORT_SET_STATE(imp, LUSTRE_IMP_DISCON);
-- 
1.7.1

[PATCH 16/22] staging: lustre: llite: Invoke file_update_time in page_mkwrite

[James Simmons]

From: Yang Sheng 

Only update file times if page_mkwrite is not set. So we
need call file_update_time by ourselves.

Signed-off-by: Yang Sheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1118
Reviewed-on: http://review.whamcloud.com/18683
Reviewed-by: Andreas Dilger 
Reviewed-by: Niu Yawei 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/llite_mmap.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c 
b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index f50b6c1..ee01f20 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -369,6 +369,7 @@ static int ll_page_mkwrite(struct vm_area_struct *vma, 
struct vm_fault *vmf)
bool retry;
int result;
 
+   file_update_time(vma->vm_file);
do {
retry = false;
result = ll_page_mkwrite0(vma, vmf->page, );
-- 
1.7.1

[PATCH 15/22] staging: lustre: rpc: increase bulk size

[James Simmons]

From: Jinshan Xiong 

To make the ptlrpc be able to size 16MB IO

Signed-off-by: Jinshan Xiong 
Signed-off-by: Gu Zheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7990
Reviewed-on: http://review.whamcloud.com/19366
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../lustre/lustre/include/lustre/lustre_idl.h  |6 +-
 drivers/staging/lustre/lustre/include/lustre_net.h |8 ++--
 drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 ++
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index b9f333b..20f55b7 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1683,8 +1683,12 @@ struct obd_ioobj {
__u32   ioo_bufcnt; /* number of niobufs for this object */
 };
 
+/*
+ * NOTE: IOOBJ_MAX_BRW_BITS defines the _offset_ of the max_brw field in
+ * ioo_max_brw, NOT the maximum number of bits in PTLRPC_BULK_OPS_BITS.
+ * That said, ioo_max_brw is a 32-bit field so the limit is also 16 bits.
+ */
 #define IOOBJ_MAX_BRW_BITS 16
-#define IOOBJ_TYPE_MASK((1U << IOOBJ_MAX_BRW_BITS) - 1)
 #define ioobj_max_brw_get(ioo) (((ioo)->ioo_max_brw >> IOOBJ_MAX_BRW_BITS) + 1)
 #define ioobj_max_brw_set(ioo, num)\
 do { (ioo)->ioo_max_brw = ((num) - 1) << IOOBJ_MAX_BRW_BITS; } while (0)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h 
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 2be135d..411eb0d 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -69,13 +69,17 @@
 #define PTLRPC_MD_OPTIONS  0
 
 /**
- * Max # of bulk operations in one request.
+ * log2 max # of bulk operations in one request: 2=4MB/RPC, 5=32MB/RPC, ...
  * In order for the client and server to properly negotiate the maximum
  * possible transfer size, PTLRPC_BULK_OPS_COUNT must be a power-of-two
  * value.  The client is free to limit the actual RPC size for any bulk
  * transfer via cl_max_pages_per_rpc to some non-power-of-two value.
+ * NOTE: This is limited to 16 (=64GB RPCs) by IOOBJ_MAX_BRW_BITS.
  */
-#define PTLRPC_BULK_OPS_BITS   2
+#define PTLRPC_BULK_OPS_BITS   4
+#if PTLRPC_BULK_OPS_BITS > 16
+#error "More than 65536 BRW RPCs not allowed by IOOBJ_MAX_BRW_BITS."
+#endif
 #define PTLRPC_BULK_OPS_COUNT  (1U << PTLRPC_BULK_OPS_BITS)
 /**
  * PTLRPC_BULK_OPS_MASK is for the convenience of the client only, and
diff --git a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c 
b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
index f50f487..e12eb83 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
@@ -1576,6 +1576,8 @@ void lustre_assert_wire_constants(void)
 (long long)(int)offsetof(struct obd_ioobj, ioo_bufcnt));
LASSERTF((int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt) == 4, "found 
%lld\n",
 (long long)(int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt));
+   LASSERTF(IOOBJ_MAX_BRW_BITS == 16, "found %lld\n",
+(long long)IOOBJ_MAX_BRW_BITS);
 
/* Checks for union lquota_id */
LASSERTF((int)sizeof(union lquota_id) == 16, "found %lld\n",
-- 
1.7.1

[PATCH 22/22] staging: lustre: libcfs: remove lnet upcall code

[James Simmons]

From: Alexander Zarochentsev 

Removing lnet upcall infrastructure completely
as nobody uses it anymore. The upcall causes a delay
before calling BUG() and might even cause a hang
making getting a crash dump unreliable or containing
outdated info.

Signed-off-by: Alexander Zarochentsev 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8418
Seagate-bug-id: MRP-2939
Reviewed-on: http://review.whamcloud.com/21440
Reviewed-by: Andreas Dilger 
Reviewed-by: James Simmons 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../staging/lustre/include/linux/libcfs/libcfs.h   |1 -
 .../lustre/include/linux/libcfs/libcfs_private.h   |2 -
 .../staging/lustre/lnet/libcfs/linux/linux-debug.c |   54 
 drivers/staging/lustre/lnet/libcfs/module.c|8 ---
 4 files changed, 0 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 70eb08e..cc2c0e9 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -125,7 +125,6 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
 /**
  * The path of debug log dump upcall script.
  */
-extern char lnet_upcall[1024];
 extern char lnet_debug_log_upcall[1024];
 
 extern struct cfs_wi_sched *cfs_sched_rehash;
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
index 41a651f..aab15d8 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
@@ -169,8 +169,6 @@
 #define ntohs(x) ___ntohs(x)
 #endif
 
-void libcfs_run_upcall(char **argv);
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msg);
 void libcfs_debug_dumplog(void);
 int libcfs_debug_init(unsigned long bufsize);
 int libcfs_debug_cleanup(void);
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c 
b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
index d8a9894..39a72e3 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
@@ -57,7 +57,6 @@
 
 #include 
 
-char lnet_upcall[1024] = "/usr/lib/lustre/lnet_upcall";
 char lnet_debug_log_upcall[1024] = "/usr/lib/lustre/lnet_debug_log_upcall";
 
 /**
@@ -92,58 +91,6 @@ void libcfs_run_debug_log_upcall(char *file)
}
 }
 
-void libcfs_run_upcall(char **argv)
-{
-   int rc;
-   int argc;
-   static const char * const envp[] = {
-   "HOME=/",
-   "PATH=/sbin:/bin:/usr/sbin:/usr/bin",
-   NULL
-   };
-
-   argv[0] = lnet_upcall;
-   argc = 1;
-   while (argv[argc])
-   argc++;
-
-   LASSERT(argc >= 2);
-
-   rc = call_usermodehelper(argv[0], argv, (char **)envp, 1);
-   if (rc < 0 && rc != -ENOENT) {
-   CERROR("Error %d invoking LNET upcall %s %s%s%s%s%s%s%s%s; 
check /sys/kernel/debug/lnet/upcall\n",
-  rc, argv[0], argv[1],
-  argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
-  argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
-  argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
-  argc < 6 ? "" : ",...");
-   } else {
-   CDEBUG(D_HA, "Invoked LNET upcall %s %s%s%s%s%s%s%s%s\n",
-  argv[0], argv[1],
-  argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
-  argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
-  argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
-  argc < 6 ? "" : ",...");
-   }
-}
-
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msgdata)
-{
-   char *argv[6];
-   char buf[32];
-
-   snprintf(buf, sizeof(buf), "%d", msgdata->msg_line);
-
-   argv[1] = "LBUG";
-   argv[2] = (char *)msgdata->msg_file;
-   argv[3] = (char *)msgdata->msg_fn;
-   argv[4] = buf;
-   argv[5] = NULL;
-
-   libcfs_run_upcall(argv);
-}
-EXPORT_SYMBOL(libcfs_run_lbug_upcall);
-
 /* coverity[+kill] */
 void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
 {
@@ -158,7 +105,6 @@ void __noreturn lbug_with_loc(struct libcfs_debug_msg_data 
*msgdata)
dump_stack();
if (!libcfs_panic_on_lbug)
libcfs_debug_dumplog();
-   libcfs_run_lbug_upcall(msgdata);
if (libcfs_panic_on_lbug)
panic("LBUG");
set_task_state(current, TASK_UNINTERRUPTIBLE);
diff --git a/drivers/staging/lustre/lnet/libcfs/module.c 
b/drivers/staging/lustre/lnet/libcfs/module.c
index 5884a33..161e042 100644
--- a/drivers/staging/lustre/lnet/libcfs/module.c
+++ 

[PATCH 16/22] staging: lustre: llite: Invoke file_update_time in page_mkwrite

[James Simmons]

From: Yang Sheng 

Only update file times if page_mkwrite is not set. So we
need call file_update_time by ourselves.

Signed-off-by: Yang Sheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1118
Reviewed-on: http://review.whamcloud.com/18683
Reviewed-by: Andreas Dilger 
Reviewed-by: Niu Yawei 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/llite_mmap.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c 
b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index f50b6c1..ee01f20 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -369,6 +369,7 @@ static int ll_page_mkwrite(struct vm_area_struct *vma, 
struct vm_fault *vmf)
bool retry;
int result;
 
+   file_update_time(vma->vm_file);
do {
retry = false;
result = ll_page_mkwrite0(vma, vmf->page, );
-- 
1.7.1

[PATCH 15/22] staging: lustre: rpc: increase bulk size

[James Simmons]

From: Jinshan Xiong 

To make the ptlrpc be able to size 16MB IO

Signed-off-by: Jinshan Xiong 
Signed-off-by: Gu Zheng 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7990
Reviewed-on: http://review.whamcloud.com/19366
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../lustre/lustre/include/lustre/lustre_idl.h  |6 +-
 drivers/staging/lustre/lustre/include/lustre_net.h |8 ++--
 drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 ++
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index b9f333b..20f55b7 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1683,8 +1683,12 @@ struct obd_ioobj {
__u32   ioo_bufcnt; /* number of niobufs for this object */
 };
 
+/*
+ * NOTE: IOOBJ_MAX_BRW_BITS defines the _offset_ of the max_brw field in
+ * ioo_max_brw, NOT the maximum number of bits in PTLRPC_BULK_OPS_BITS.
+ * That said, ioo_max_brw is a 32-bit field so the limit is also 16 bits.
+ */
 #define IOOBJ_MAX_BRW_BITS 16
-#define IOOBJ_TYPE_MASK((1U << IOOBJ_MAX_BRW_BITS) - 1)
 #define ioobj_max_brw_get(ioo) (((ioo)->ioo_max_brw >> IOOBJ_MAX_BRW_BITS) + 1)
 #define ioobj_max_brw_set(ioo, num)\
 do { (ioo)->ioo_max_brw = ((num) - 1) << IOOBJ_MAX_BRW_BITS; } while (0)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h 
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 2be135d..411eb0d 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -69,13 +69,17 @@
 #define PTLRPC_MD_OPTIONS  0
 
 /**
- * Max # of bulk operations in one request.
+ * log2 max # of bulk operations in one request: 2=4MB/RPC, 5=32MB/RPC, ...
  * In order for the client and server to properly negotiate the maximum
  * possible transfer size, PTLRPC_BULK_OPS_COUNT must be a power-of-two
  * value.  The client is free to limit the actual RPC size for any bulk
  * transfer via cl_max_pages_per_rpc to some non-power-of-two value.
+ * NOTE: This is limited to 16 (=64GB RPCs) by IOOBJ_MAX_BRW_BITS.
  */
-#define PTLRPC_BULK_OPS_BITS   2
+#define PTLRPC_BULK_OPS_BITS   4
+#if PTLRPC_BULK_OPS_BITS > 16
+#error "More than 65536 BRW RPCs not allowed by IOOBJ_MAX_BRW_BITS."
+#endif
 #define PTLRPC_BULK_OPS_COUNT  (1U << PTLRPC_BULK_OPS_BITS)
 /**
  * PTLRPC_BULK_OPS_MASK is for the convenience of the client only, and
diff --git a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c 
b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
index f50f487..e12eb83 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
@@ -1576,6 +1576,8 @@ void lustre_assert_wire_constants(void)
 (long long)(int)offsetof(struct obd_ioobj, ioo_bufcnt));
LASSERTF((int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt) == 4, "found 
%lld\n",
 (long long)(int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt));
+   LASSERTF(IOOBJ_MAX_BRW_BITS == 16, "found %lld\n",
+(long long)IOOBJ_MAX_BRW_BITS);
 
/* Checks for union lquota_id */
LASSERTF((int)sizeof(union lquota_id) == 16, "found %lld\n",
-- 
1.7.1

[PATCH 22/22] staging: lustre: libcfs: remove lnet upcall code

[James Simmons]

From: Alexander Zarochentsev 

Removing lnet upcall infrastructure completely
as nobody uses it anymore. The upcall causes a delay
before calling BUG() and might even cause a hang
making getting a crash dump unreliable or containing
outdated info.

Signed-off-by: Alexander Zarochentsev 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8418
Seagate-bug-id: MRP-2939
Reviewed-on: http://review.whamcloud.com/21440
Reviewed-by: Andreas Dilger 
Reviewed-by: James Simmons 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../staging/lustre/include/linux/libcfs/libcfs.h   |1 -
 .../lustre/include/linux/libcfs/libcfs_private.h   |2 -
 .../staging/lustre/lnet/libcfs/linux/linux-debug.c |   54 
 drivers/staging/lustre/lnet/libcfs/module.c|8 ---
 4 files changed, 0 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 70eb08e..cc2c0e9 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -125,7 +125,6 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
 /**
  * The path of debug log dump upcall script.
  */
-extern char lnet_upcall[1024];
 extern char lnet_debug_log_upcall[1024];
 
 extern struct cfs_wi_sched *cfs_sched_rehash;
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
index 41a651f..aab15d8 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
@@ -169,8 +169,6 @@
 #define ntohs(x) ___ntohs(x)
 #endif
 
-void libcfs_run_upcall(char **argv);
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msg);
 void libcfs_debug_dumplog(void);
 int libcfs_debug_init(unsigned long bufsize);
 int libcfs_debug_cleanup(void);
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c 
b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
index d8a9894..39a72e3 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
@@ -57,7 +57,6 @@
 
 #include 
 
-char lnet_upcall[1024] = "/usr/lib/lustre/lnet_upcall";
 char lnet_debug_log_upcall[1024] = "/usr/lib/lustre/lnet_debug_log_upcall";
 
 /**
@@ -92,58 +91,6 @@ void libcfs_run_debug_log_upcall(char *file)
}
 }
 
-void libcfs_run_upcall(char **argv)
-{
-   int rc;
-   int argc;
-   static const char * const envp[] = {
-   "HOME=/",
-   "PATH=/sbin:/bin:/usr/sbin:/usr/bin",
-   NULL
-   };
-
-   argv[0] = lnet_upcall;
-   argc = 1;
-   while (argv[argc])
-   argc++;
-
-   LASSERT(argc >= 2);
-
-   rc = call_usermodehelper(argv[0], argv, (char **)envp, 1);
-   if (rc < 0 && rc != -ENOENT) {
-   CERROR("Error %d invoking LNET upcall %s %s%s%s%s%s%s%s%s; 
check /sys/kernel/debug/lnet/upcall\n",
-  rc, argv[0], argv[1],
-  argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
-  argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
-  argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
-  argc < 6 ? "" : ",...");
-   } else {
-   CDEBUG(D_HA, "Invoked LNET upcall %s %s%s%s%s%s%s%s%s\n",
-  argv[0], argv[1],
-  argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
-  argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
-  argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
-  argc < 6 ? "" : ",...");
-   }
-}
-
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msgdata)
-{
-   char *argv[6];
-   char buf[32];
-
-   snprintf(buf, sizeof(buf), "%d", msgdata->msg_line);
-
-   argv[1] = "LBUG";
-   argv[2] = (char *)msgdata->msg_file;
-   argv[3] = (char *)msgdata->msg_fn;
-   argv[4] = buf;
-   argv[5] = NULL;
-
-   libcfs_run_upcall(argv);
-}
-EXPORT_SYMBOL(libcfs_run_lbug_upcall);
-
 /* coverity[+kill] */
 void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
 {
@@ -158,7 +105,6 @@ void __noreturn lbug_with_loc(struct libcfs_debug_msg_data 
*msgdata)
dump_stack();
if (!libcfs_panic_on_lbug)
libcfs_debug_dumplog();
-   libcfs_run_lbug_upcall(msgdata);
if (libcfs_panic_on_lbug)
panic("LBUG");
set_task_state(current, TASK_UNINTERRUPTIBLE);
diff --git a/drivers/staging/lustre/lnet/libcfs/module.c 
b/drivers/staging/lustre/lnet/libcfs/module.c
index 5884a33..161e042 100644
--- a/drivers/staging/lustre/lnet/libcfs/module.c
+++ b/drivers/staging/lustre/lnet/libcfs/module.c
@@ -365,14 +365,6 @@ static int proc_cpt_table(struct ctl_table *table, int 
write,
.mode = 0444,